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 with such hardware, and I can confirm that Intel's DOS network driver (e1000.dos) appears to be incompatible with FreeDOS. You can download the latest version of this driver from Intel's site: http://downloadfinder.intel.com/scripts-df/File_Filter.asp?FileName=PRODOS2.EXE Or you can download my boot disk itself as a 1.44M floppy image: http://unattended.sourceforge.net/testing/ e1000.img Although the problem is only reproducible if you have PRO/1000 network hardware... Here is what I have observed. If I use a config.sys which is empty except for "DEVICE=\net\ifshlp.sys", the driver loads fine. But when the boot disk tries to use the driver to obtain a DHCP lease, it gets an illegal opcode followed by a reboot. The reboot happens too quickly for me to record the hex values. If I add these lines to config.sys: DOS=HIGH,UMB DEVICE=himem64.exe The same thing happens. If I further add: DEVICE=emm386.exe NOEMS (where HIMEM64 and EMM386 were downloaded from <ftp://ftp.devoresoft.com/downloads/> yesterday) ...it still happens, only I see this: Illegal Instruction occurred CS=3046 IP=08CC SS=00CF SP=08B8 DS=0000 ES=DC11 EAX=00000000 EBX=00000F8C ECX=00000003 EDX=00000AE4 ESI=00000000 EDI=0000000F EBP=00000000 Opcodes @CS:IP 63 20 00 00 00 00 00 00 Aborting program ...and it hangs, letting me record the values. Finally, if I change the emm386.exe invocation in config.sys like this: DEVICE=emm386.exe ...then the e1000.dos driver refuses to load at all! It probes the hardware correctly (printing the MAC address etc.), but then it says: Error: Unsuppored Memory Manager Present Unable to initialize protected mode services Action: -Remove all memory managers from this configuration Failure: Driver did not load, NDIS environment invalid (By the way, the same thing happens if I only load himem64.exe and load cwsdpmi before loading the driver. Obviously, the e1000.dos driver does not play nicely with DPMI providers.) This behavior is with the FreeDOS kernel from ke2033_32. I tried one or two of the above permutations under ke2034_32 with the same results. Obviously, the e1000.dos driver is doing something very strange. However, the exact same boot disk used to work fine under MS-DOS (with or without himem.sys), so from my point of view this is a FreeDOS bug. Any ideas? If I were to offer to send someone a PRO/1000 card to experiment with, would any of you be interested? Or do you have any other suggestions? Thanks! - Pat ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
