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 quite a lot.
Yes. > Just to be sure, you've tried the bare driver CONFIG.SYS on an > MS-DOS system and it worked correctly? The info is a required data > point in case the driver normally requires or expects HIMEM, etc. I just double-checked, even booting from physical floppies instead of network boot + memdisk. (Wow, floppies are slow...) My config.sys has: LASTDRIVE=Z DEVICEHIGH=\net\ifshlp.sys FILES=30 (Since I am not loading any memory manager, I presume DEVICEHIGH=... is equivalent to DEVICE=... ?) With MS-DOS, the e1000.dos driver works fine. With FreeDOS (ke2034_32), it crashes as I described: The driver loads, but when tinyrfc.exe tries to obtain a DHCP lease, it gets an invalid opcode. Actually, I think it may successfully obtain the lease; it pauses for a while before crashing. And the floppy itself spins up again. This time, the system did not reboot; instead, it printed the following three messages with about 2-3 seconds between each: Invalid opcode at FFA7 1100 0212 0000 00CF 0070 0800 04B0 0005 0005 01EC 04B0 143F Invalid opcode at 0212 A73B 0886 0202 0E9E 1038 0000 347F 0012 0001 0033 0001 0000 Invalid opcode at 0032 0800 0093 00F3 3D72 B4C3 2851 11B0 1A92 2851 3CFA 4688 2851 At this point I pressed ctrl+pause, and after that the machine was non-responsive (even to ctrl+alt+del). > 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 386SWAT debugger. > I know you know assembly language pretty well, plus I can walk you > through some basic tests there (obviously a suboptimal situation, > but better than nothing). I can (usuall) read other people's code and make trivial changes. It would be a lot nicer if someone intimate with FreeDOS internals could look at this... But I will do what I have to, time permitting. > I could test a card here, but since the FreeDOS machine isn't > normally hooked into any network, I'm not sure it would do much > good. Yeah, the problems don't start until after you actuall use the driver. > (Weird about about failing with EMM386 without NOEMS, though. But > we can maybe fix that later.) Maybe, but some Google searching suggests that the same thing happens with MS EMM386. The e1000.dos driver really does not like seeing a DPMI provider. Who knows why. - 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
