Hi!
13--2004 17:43 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD Oh, a final question for you: do you know if any of the Linux code listed
MD is even remotely tied up with all that SCO garbage? Obviously SCO's case is
MD utterly bogus, but as you know, unlike IBM we cannot
Hello Bernd,
BB HIMEM is still under GPL, correct?
HIMEM is under Artistic License.
BB derived from FDXMS, which is GPL.
derived from FDXMS 0.2, which is free.
tom
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux
On Wed, 14 Apr 2004, tom ehlert wrote:
Hello Michael,
MD Additionally, if any port 92h related
MD lockups happen, I'll move always-on to top the A20 test list,
MD see if they go away.
*** PRO 'always-on' ***
I think always on here refers to machines that *boot* with A20 enabled.
In that
At 09:31 AM 4/14/2004 +0200, tom ehlert wrote:
*** my conclusion ***
I hate A20 anyway - use always on if found to be on on startup
Good enough for me, I'll move an initial A20 always-on test to front of the method
line on next release.
At 04:58 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
Although the new A20 test code should work, as it does fine in many
machines and the logic is sound.
I still think instruction reordering is a potential issue.
It might be, it's hard to be
Michael Devore [EMAIL PROTECTED] writes:
We're still running into a shortage of testers and I think the best
approach may be to soon release a cleaned-up version of the HIMEM we
have into the wild, then modify as necessary afterwards.
Sounds perfectly reasonable to me.
Oh, a final question
Michael Devore [EMAIL PROTECTED] writes:
Great. Now that HIMEM is getting wider distribution to the eager
hundreds or thousands, I've additionally collected problem reports
with buggy BIOS support for BIOS method and a failing A20 always on
method. It's like a dam busted somewhere upstream.
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
Michael Devore [EMAIL PROTECTED] writes:
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.
Like the test_a20 code failing...
The
At 02:46 PM 4/8/2004 -0400, Patrick J. LoPresti wrote:
Michael Devore [EMAIL PROTECTED] writes:
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
At 03:10 PM 4/8/2004 -0500, Michael Devore wrote:
I'm not sure FreeDOS can assume HIMEM has the first shot at machine hardware in its
initial state. It certainly doesn't under VMware, which we have do FreeDOS users
running under. Does VMware reset A20 back to known disabled state at startup
Michael Devore [EMAIL PROTECTED] writes:
Of course, I should say enabled here, rather than disabled.
I think disabled is correct, assuming disabled is a synonym for
closed. (As in, the gate is closed, so it does not pass anything,
so the A20 line is disabled and fixed at 0.) Actually, I think
Great. Now that HIMEM is getting wider distribution to the eager hundreds or
thousands, I've additionally collected problem reports with buggy BIOS support for
BIOS method and a failing A20 always on method. It's like a dam busted somewhere
upstream.
For all those asking, reverting to the
13 matches
Mail list logo
