At 10:52 AM 4/8/2004 -0400, Patrick J. LoPresti wrote: >It sounds like you cannot trust the BIOS status code, so you need to >test whether it really enabled/disabled the gate. Or, just tell the >user their BIOS is buggy and to get a new machine. :-)
I added enable/disable test, but the report was that it still fails, after working for the startup test. Which either means the BIOS is bugged and fails under stress, or there is something very weird going on. >What do you mean by "failing A20 always on method"? Do you mean that >A20 is always on but it is not detected as such? (Would that imply >that the test_a20 procedure is broken?) This happens if all other method tests fail and the A20 is detected enabled at the end of the test chain. Won't have details on the problem machines until next week, but there are at least a couple of scenarios that could trigger this. One scenario is that an A20 method test fails under HIMEM's stricter error-checking, but the method actually does work and is expected to be used (e.g. sloppy BIOS work), then a later application/driver uses that method. A second, more likely, scenario is that the machine uses PS/2 port 92h, but doesn't show support via INT 15h function 2403h, and doesn't flag as an MCA machine. That's my current choice for what's happening. The solution for second situation is to try port 92h without the MCA check. Unfortunately there are machines reliably documented as locking up if you goof with port 92h when they don't support that method. If the port 92h test comes at the tail end of the test chain, maybe it doesn't matter because you're going to fail if it fails anyway. The big issue would be if a machine is A20 always on (which comes at the end of the test chain, too), but crashes on unsupported port 92h access. Can't get a recovery plan on that one. >This is not too surprising. The Linux kernel initialization code >enables A20. Granted that it only has to enable A20 and it only runs >once, but it is known to work on millions of machines... In HIMEM64 >parlance, the Linux code tries "always on", BIOS, KBC-2, and "fast", >in that order. I don't know how else to test "always on" other than to try other methods first, unless there's another BIOS call for it -- which apparently we can't always trust based on the failure of the BIOS method for other machines. I may drop KBC, but should test with more people. Hopefully a wider test can confirm/deny need for it and that "Vectra" doesn't come back from the dead too. >There are some slight differences. Linux tests the actual state of >A20 for every method. In KBC-2, Linux has a longer (or at least >different) delay where you have "pulse output port". Pulse output port was lifted from working DOS extender of code at least eight years old, actually think it's closer to twelve years now. Unofficially, and I have NOT seen the sources myself, I am told Microsoft does exactly the same thing in their leaked DOS source. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
