OS/2, eCS & ArcaOS - Technical > Storage
JFS failing in a disastrous way - without the user knowing
Dariusz Piatkowski:
Lars, everyone...
--- Quote from: Lars on December 02, 2022, 07:10:45 am ---Sorry, but this is ridiculous.
...
But I am not the master of disaster. That is AN. They have the source code. And of course, it's closed source
--- End quote ---
Ahh, you see, and therein lies part of the challenge that causes majority of us to take a more pragmatic approach to dealing with these issues.
Yes, you are absolutely right about this being ridiculous, however, what other choice do we really have? There certainly isn't much ability for any of us to action it, even folks like yourself who have the technical know-how are finding themselves having their hands tied.
Sooo...instead of continuing the risk exposure I will do the best I can, with the tools/controls available to me today, to avoid that risk.
Lars:
--- Quote from: Andi B. on December 02, 2022, 12:59:15 pm ---
--- Quote ---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.
--- End quote ---
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.
--- Quote ---Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...
--- End quote ---
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.
--- End quote ---
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.
Lars:
--- Quote from: Martin Iturbide on December 02, 2022, 02:19:34 pm ---
--- Quote from: Lars on December 02, 2022, 07:10:45 am ---...
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.
...
--- End quote ---
Hi
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.
Regards
--- End quote ---
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).
Andi B.:
--- Quote ---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).
--- End quote ---
That would be a very good work around. (Solution would be putting back unicode.sys into config.sys when it's not before jfs.ifs). Such 30s delay would be also very useful for ACPI or USB test versions when they outdate. A problem testers are bitten every now and then. F.i. even Keith at his presentation in Colonge...
Martin Iturbide:
Hi
I had added the suggestion on the Arca Noae Ticketing System.
- https://mantis.arcanoae.com/view.php?id=3364
If it is not clear enough, I will appreciate if someone (with access) can add more information to the ticket.
Regards
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version