Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lars

Pages: [1] 2 3 ... 69
Applications / Re: Netlabs EPMD Startup Freeze
« on: Today at 01:17:17 pm »
I am seeing this in POPUPLOG:

Code: [Select]
12-06-2022  19:36:33  SYS3179  PID 003d  TID 0001  Slot 0033
EAX=00086038  EBX=00086050  ECX=00000c7f  EDX=00000005
ESI=1a2174f4  EDI=00086134 
DS=0053  DSACC=d0f3  DSLIM=5fffffff 
ES=0053  ESACC=d0f3  ESLIM=5fffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1fb7e1d4  CSACC=d0df  CSLIM=5fffffff
SS:ESP=0053:00085fec  SSACC=d0f3  SSLIM=5fffffff
EBP=00086024  FLG=00010202

PMMERGE.DLL 0004:0004e1d4

This is very strange. As David pointed out, it is the Floating Point Control Word (FCW) that controls if and what floating point unit (FPU) exceptions are masked (or not) when certain floating point related problems occur.
The FCW is a global register. In order for applications to be able to use different settings, the OS will save and restore the FCW whenever you switch from one application (thread) to another application (thread).
Typically, C compilers produce code where on program start, they mask all FPU exceptions and let the application override this when it needs something different.
So, one application should NEVER influence the FPU exception masking of another application.
However, there is one case of unexpected problem and that is the use of DLLs. If an application loads a DLL, the DLL code executes as part of that application and if that DLL changes the FCW, then an FPU exception might trigger that the application did not expect.
I would conclude that it is not Firefox influencing EPM but rather EPM loading a DLL that manipulates the FCW. And I remember from some webpage I cannot find anymore that the WATCOM compiler produces DLL startup code that changes the FCW. I don't know about GCC compiler.
I think updating to all the latest libraries (libc for example) is therefore a good suggestion.

EDIT: regarding WATCOM, look here:

Multimedia / Re: XHCI and USB Audio perspectives
« on: Today at 07:31:47 am »
That could either be the audio class driver (USBAUDIO, usbaud2) or the HC driver (USBXHCD). If you can, borrow a USB 2.0 (ehci) plug-in card from someone and see if that makes a difference (don't forget to add the USBEHCD driver to config.sys). If yes, it's the HC driver. If not, it's the audio class driver.

EDIT: I just tried on my system (using USBEHCD HC driver, no XHCI). I can swap sound file play (using different sample rate and resolution) without a problem, meaning, I can start playing one file, interrupting by playing another file with different sample rate and bit resolution and once that second file has finished playing, automatically resuming playing the first file. I have no distortion, glitch or anything else.

But that might also depend on the USB audio HW (not all USB audio HW behaves the very same way even though there are standards ...).

It would be interesting if that Trap E always occurs at the very same location (the lowest 4 hex digits of EIP having the same value would be a good indication, I don't have access to ticket 1223).

The trap is due to an attempt to write data to a non-present page. Taking the value displayed for CR2, I would think a NULL pointer being accessed (with an offset of 0x38). It's difficult to say what would have caused that but a NULL pointer check should be added in JFS.IFS.
Since JFS.IFS dynamically allocates memory from an internal pool whenever that is necessary, maybe all memory was depleted and a NULL pointer returned. Since it seems to depend on file size, it may have something to do with allocating "inode" management data.

General Discussion / Re: SCOUG
« on: December 04, 2022, 11:34:47 am »
Try to sacrifice a black cat at midnight, maybe that helps.
Just kidding, I don't want an innocent black cat do die...

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 04, 2022, 11:31:36 am »
Being an OS/2 user is a little bit like being a drug addict:
you know that it's bad for your health but you just can't let go.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 03, 2022, 10:32:26 am »
You can. Until you end up with a system where you can no longer remove directories where directory names were manipulated without UNICODE.SYS being loaded. That messes up the unicode character string on a very basic filesystem level. And then, DFSee is your last resort to rectify that.

If you always use en_US locale, you will very likely NEVER run into this problem, because codepage 437 is the default for about anything that relates to an ASCII string in OS/2. This is about people that either have to use a different codepage or where the OS installation installs a different codepage as the primary codepage. For a german OS/2, codepage 850 is installed as the default (with 437 as a secondary codepage) even though codepage 437 would also do for most of the things (german umlauts are also supported with codepage 437 and even have the same byte value as in codepage 850).
In short, for a few special characters, codepage 437 and 850 are identical. For the lower 128 characters, 437 and 850 are also identical (and that includes 0-9 a-z A-Z : \ .).
For a french codepage this will be comparable but certainly not for any cyrillic codepage.
Which also makes it clear why no modern operating system is using codepages anymore.

I repeat: this is an absolute NOGO for a commercial operating system.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 03:48:55 pm »
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.


I agree that it should be very useful for JFS.IFS to display a warning message if UNICODE.SYS is not loaded. For what I know UNICODE is very important for JFS. But I'm not complete sure about if had to pause the boot process forcing the user to hit "return".

But I think I can open the ticket and let the implementation decisions to Arca Noae, since it is their product.

By the way, as far as it was discussed AN JFS.IFS is closed source and they treat the IBM source code base of it as the IBM DDK license.


Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 03:44:46 pm »
There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.
Yes it is a problem with other drivers too. That's why I'm think about. Specifically with ethernet drivers I often observed this when f.i. they do not find the correct chip. But other drivers too. I think PAUSEONERROR (or similar) can prevent stop the boot process. But using this is no good solution too because you probably wouldn't recognize the error message then as it flies away much to fast on current (< 10 years :-) ) hardware.

Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...
It does as long as something (ACPI, USB, ...?) very early in the boot process takes over control until the time when all the USB stuff, including usbhid is initialized (very late). In any case there is a big window during boot where USB keyboards do not work. From all what I understand and all the discussions about that (testers list, AN tickets) this window (non working usb keyboard) can not be eliminated. I never figured out how to sort config.sys to make this window as small a possible. But I got the impression it's impossible to cover all these places where device drivers may fire up this "hit return" message. We have to life with this when we want (or have) to use USB keyboards instead PS/2.

1) it's not PAUSEONERROR that influences the driver behaviour. It is what error code a driver returns from its INIT routine. It can report either "OK" or "NON_CRITICAL_ERROR" or "SOME_ERROR" (various different errors). "OK" and "NON_CRITICAL_ERROR" means to continue without interruption, "SOME_ERROR" means to stop and wait for keypress.
Obviously, the idea is that a severe error should prevent booting from continuing without the user noticing.

2) I don' t have a long time window of USB not working. I have a short time window of USB not working where the OS/2 HC drivers are loading and turning off legacy USB (start of time window) and finally have taken over the HC HW and the relevant USB devices mouse/keyboard have been enumerated (end of time window). On my system, that time window is about 5 seconds, keyboard works before and after that time window (that is, in particular during the bootup process where the video is in text mode). But I am using my USB drivers and I don't know if the AN drivers have a different behaviour.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 12:11:39 pm »
It may have a sense to convert UNICODE.SYS from "DEVICE" to "BASEDEV".

That is only going to remove the ordering dependency (UNICODE.SYS has to come before JFS.IFS). I can live with that ordering dependency but I cannot live with data loss because a vital driver wasn't loaded.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 12:10:00 pm »
I wouldn't call it ridiculous. I would say this is another shortcoming/bug/problem/nuisance of one part/program of our platform. Of course it may be easy to improve this situation with Lars proposed changes. No clue if David will implement it when Lars creates a ticket.

It's good that Lars shares his experience here to tell others about some problems and how to circumvent it. That's what a forum is good for.

But I also see a lot of other shortcomings. And when I were in the position to give priorities, this one would have a low priority. We only can wait and see what David says about this. Or is there any chance to get access to the latest JFS sources?

display a warning message and even force the user to hit Return to continue boot process
I fear this can be a problem with USB keyboards. The systems I have do not serve USB keyboards (with OS/2) until the end of the boot process. Every such "hit return to continue" condition while booting (while loading all the drivers from config.sys) needs the old PS/2 keyboard which luckily is also attached to step over. Here there is no chance to respond to such messages with the USB keyboard.

There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.
Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...

By the way: I cannot create a ticket as I am no paying AN customer. Somebody with an AN license would need to do that.

Hardware / Re: panorama not remembering monotor resolution
« on: December 02, 2022, 08:18:15 am »
I have a very annoying problem.  If I boot the computer without the monitor being on panorama reverts to something like 640 x 480 which is stupid on my 1920 x 1200 28 inch monitor. 
Is there a way to make panorama remember the monitor resolution?  I have no problems like this with Linux on the same monitor via a kvm switch.

Same happens for me. I doubt that there is an easy way to circumvent that.

Multimedia / Re: Rebuilds of MM Audio Pack
« on: December 02, 2022, 07:26:19 am »
That is already supported with installing USBAUDIO package. It adds the necessary SPI info so that MMPM can understand this new Samplerate/numchannels/bit depth format.

Here is a list of what formats have been added by now:

Code: [Select]
/* additional Subtypes for DATATYPE_WAVEFORM:*/
#define    WAVE_FORMAT_32M16        0x0011L   /*  32.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_48M16        0x0012L   /*  48.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_64M16        0x0013L   /*  64.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_882M16       0x0014L   /*  88.2kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_96M16        0x0015L   /*  96.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_1764M16      0x0016L   /* 176.4kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_192M16       0x0017L   /* 192.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_3528M16      0x0018L   /* 352.8kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_384M16       0x0019L   /* 384.0kHz  , Mono, 16-bit*/

#define    WAVE_FORMAT_32S16        0x001AL   /*  32.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_48S16        0x001BL   /*  48.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_64S16        0x001CL   /*  64.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_882S16       0x001DL   /*  88.2kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_96S16        0x001EL   /*  96.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_1764S16      0x001FL   /* 176.4kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_192S16       0x0020L   /* 192.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_3528S16      0x0021L   /* 352.8kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_384S16       0x0022L   /* 384.0kHz  , Stereo, 16-bit*/

#define    WAVE_FORMAT_32M24        0x0023L   /*  32.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_4M24         0x0024L   /*  44.1kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_48M24        0x0025L   /*  48.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_64M24        0x0026L   /*  64.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_882M24       0x0027L   /*  88.2kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_96M24        0x0028L   /*  96.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_1764M24      0x0029L   /* 176.4kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_192M24       0x002AL   /* 192.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_3528M24      0x002BL   /* 352.8kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_384M24       0x002CL   /* 384.0kHz  , Mono, 24-bit*/

#define    WAVE_FORMAT_32S24        0x002DL   /*  32.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_4S24         0x002EL   /*  44.1kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_48S24        0x002FL   /*  48.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_64S24        0x0030L   /*  64.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_882S24       0x0031L   /*  88.2kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_96S24        0x0032L   /*  96.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_1764S24      0x0033L   /* 176.4kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_192S24       0x0034L   /* 192.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_3528S24      0x0035L   /* 352.8kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_384S24       0x0036L   /* 384.0kHz  , Stereo, 24-bit*/

#define    WAVE_FORMAT_32M32        0x0037L   /*  32.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_4M32         0x0038L   /*  44.1kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_48M32        0x0039L   /*  48.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_64M32        0x003AL   /*  64.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_882M32       0x003BL   /*  88.2kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_96M32        0x003CL   /*  96.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_1764M32      0x003DL   /* 176.4kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_192M32       0x003EL   /* 192.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_3528M32      0x003FL   /* 352.8kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_384M32       0x0040L   /* 384.0kHz  , Mono, 32-bit*/

#define    WAVE_FORMAT_32S32        0x0041L   /*  32.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_4S32         0x0042L   /*  44.1kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_48S32        0x0043L   /*  48.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_64S32        0x0044L   /*  64.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_882S32       0x0045L   /*  88.2kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_96S32        0x0046L   /*  96.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_1764S32      0x0047L   /* 176.4kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_192S32       0x0048L   /* 192.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_3528S32      0x0049L   /* 352.8kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_384S32       0x004AL   /* 384.0kHz  , Stereo, 32-bit*/

#define    WAVE_FORMAT_12M16        0x004BL   /*  12.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_16M16        0x004CL   /*  16.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_24M16        0x004DL   /*  24.0kHz  , Mono, 16-bit*/

#define    WAVE_FORMAT_12S16        0x004EL   /*  12.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_16S16        0x004FL   /*  16.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_24S16        0x0050L   /*  24.0kHz  , Stereo, 16-bit*/

#define    WAVE_FORMAT_8M24         0x0051L   /*   8.0kHz  , Mono,   24-bit*/
#define    WAVE_FORMAT_8S24         0x0052L   /*   8.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_8M32         0x0053L   /*   8.0kHz  , Mono,   32-bit*/
#define    WAVE_FORMAT_8S32         0x0054L   /*   8.0kHz  , Stereo, 32-bit*/

Additionally, of course, the sound driver has to understand the format. For the USB audio drivers, Wim implemented a (lengthy) routine to convert sample rate/num channels/bit depth to the closest match of what the USB audio HW supports. Works perfectly.
As far as I can tell UNIAUD typically supports 8000 Hz, 11025 Hz, 22050 Hz, 44100 Hz, 48000 Hz (cannot remember what bit depths are typically supported). The support depends on the actual audio HW as UNIAUD is a generic driver covering all sorts of different audio HW.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 07:10:45 am »
Sorry, but this is ridiculous.
If JFS.IFS can easily fail in a catastrophic way, then it is necessary to prevent that or at least to mediate the risk.
A new user would have no clue of what is going on. But maybe everyone has already accepted that there will be no new users...

Anyway, after thinking about it a bit more:
JFS.IFS can attempt to attach to UNICODE.SYS via a dehelp call and that can already be done on FS_INIT (call for initializing JFS.IFS) which is executed already on bootup.
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.
That takes around 10 lines of code in JFS.IFS.
But I am not the master of disaster. That is AN. They have the source code. And of course, it's closed source

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 01, 2022, 04:29:15 pm »

I quickly installed "" with Warpin 1.0.24 (ArcaOS 5.0.6) and I confirm it removed UNICODE.SYS from my config.sys.

Reverted everything, upgraded to WarpIn 1.0.26 and I got the same thing. UNICODE.SYS gets removed.

I also don't see anything strange on the CPUTEMP WarpIn script, just the "CONFIGSYS="DEVICE=?:\OS2\rdmsr.sys | UNIQUE" which should not remove UNICODE.SYS.

Should it be reported as WarpIn bug?


Warpin is working as it should based on discussion on the testers list. What happens is if rdmsr.sys is not installed, it matches up with the first *.sys in config.sys and replaces that with rdmsr.sys. Usually it is unicode.sys at the top of config.sys.

That is a very unfortunate side effect of specifying UNIQUE when "DEVICE" is the key string to look for because "DEVICE" will typically occur multiple times in config.sys. WarpIn should better be changed to do nothing if UNIQUE is specified and the key string is found multiple times. That is at least safe behaviour.
And if UNIQUE(xxxx) is specified, it should be changed to create the target string if no matching source string statement is found.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 01, 2022, 04:22:45 pm »
Thanks for the feedback.

The second thing.
Will it makes sense to request Arca Noae to put a "Boot Warning Text" for JFS.IFS if it does not find UNICODE.SYS loaded ? Does it makes sense? Can it be possible in boot time to detect this for JFS.IFS?


Yes, that would definitely make sense.

I would need to check the OpenJFS source code, but I would think that JFS.IFS uses the KEE API calls "KernCreateUConvObject", "KernStrToUCS" and "KernStrFromUCS" to create a UConv object, convert from an ASCII string to a Unicode string (taking into account active system codepage), convert from a Unicode string to an ASCII string, respectively.

I would suspect that "KernCreateUConvObject" is called very early, in the IFS loading/initialization stage (but not already on FS_INIT as that executes in Ring 3 whereas calling "KernCreateUConvObject" requires executing in Ring 0). The call will definitely return with an error if UNICODE.SYS is not loaded (these KEE API calls are the ones that require UNICODE.SYS to be loaded !!!) and that would be the indirect way to find out.

If it is not possible to already display a message on boot, then there are options:
1) have a daemon executing that could show a warning message. But that requires to implement a daemon interface in JFS.IFS and also to start the daemon application itself which of course can also go wrong.
2) Another, potentially better option is to write to the system log (the syslog.exe thing that nobody ever uses ...) because that would be a persistent logging (logging happens to a file) but that in turn also requires an additional device driver and daemon (log.sys and logdaem.exe) when the logging is to be done from a device driver or IFS. I also do not know if that conflicts with the role of the IFS giving access to files (if log.sys buffers to memory and logdaem.exe writing much later in the process, then that could work). In that case, AN should ensure that LOG.SYS and LOGAEM.EXE are always added to config.sys on each install.
3) last but not least to use the low level file system device driver calls to write a file in the root directory (say with fixed string: "Attention: UNICODE.SYS NOT LOADED !"). I guess that is the best option as it requires no further components to be up and running. But I seem to remember that also requires ring 0 execution which again would mean, you'd need to delay the logging until the first IFS call executing in Ring0 and also after the filesystem has been mounted (obviously).

But the problem should be solvable.

Pages: [1] 2 3 ... 69