Well, this is embarrassing.
I downgraded to 0.91o and it is no faster. I could have sworn it got
slower when I upgraded to 0.91r... But maybe I am just crazy and it
was never as fast as I remember.
I apologize for the false alarm.
- Pat
It sounds like you guys managed to figure this out (thanks, Tom!).
Can I get a copy of a new kernel to try? When/where?
Thanks!
- Pat
P.S. http://freedos.sourceforge.net/kernel/README.html is
inaccessible.
---
This SF.Net email is
Erwin Veermans [EMAIL PROTECTED] writes:
Wild guess:
Did you try switches=/E in config.sys?
Some people were reporting issues with latest kernel that
could be reverted with the /E-switch. Browse this list
for more info ...
No effect. Also, this happens with both the 2.0.33 and 2.0.34
Johnson Lam [EMAIL PROTECTED] writes:
You report faster than me.
I got the same problem when trying MSCLIENT, it does work under
FDXXMS+UMBPCI (try it), but fail with HIMEM+EMM386. I'm quite sure the
memory manager and hardware not so compatible especially Network
Interface Card.
I tried
In the last major release of my project
(http://unattended.sourceforge.net/), I changed my network boot disk
to use FreeDOS instead of MS-DOS.
Now, my users are reporting that the boot disk no longer works on
machines which have Intel gigabit (PRO/1000) networking hardware.
I have one machine
Michael Devore [EMAIL PROTECTED] writes:
Since you're failing without HIMEM or EMM386 loaded, you have to be
hitting a kernel compatibility, agreed? It can't be a UMB conflict
or a p-mode conflict or something failing in EMS/XMS/VCPI/DPMI
calls. That actually narrows the field of suspects
Michael Devore [EMAIL PROTECTED] writes:
I don't do kernel work, but depending on how much you want to dig in
the guts of the problem, you might want to grab the 386SWAT debugger
and load it immediately after the driver, with nothing else. It
should catch the exception and throw you into the
Blaauw,Bernd B. [EMAIL PROTECTED] writes:
(are you using UNDI driver btw for PXE, instead of DOS network drivers?)
I am using 3com's universal NDIS-over-UNDI driver. But I am not even
getting that far...
could you leave everything identical on the bootdisk but use a MSDOS
kernel on that
Eric Auer [EMAIL PROTECTED] writes:
Hi Pat, your patches and/or MEMDISK have the problem that they do
not DETECT which A20 setting styles work and which not!
- PS/2: port 92h - or 2 to enable, and ~2 to disable A20
- 8042: command d1 / port 60 ... here, too, ONLY bit 1 should be messed
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.
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
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
Michael Devore [EMAIL PROTECTED] writes:
Logically this fails as a false analogy.
Actually, it is quite sound. Every objection you raise has nothing to
do with the logic of the analogy, which is to show how restricting
your freedom can enhance everybody else's.
But fine, forget driving. Pick
14 matches
Mail list logo
