Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
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 sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
Bart, Int21/IoControl XYZ -- driver -- Int21/GetVect, Setvect the problem with this is that int28 handlers will now end up on the error stack instead of the disk api stack. So if an int28-TSR such as THELP causes a critical error, the critical error will end up on its own stack... I new there was a problem, but was too much in a hurry (read: too lazy) to think about it. Can you confirm this works (not applying the above?). All this does is to move the 0x25 and 0x35 handlers to int21_syscall, as far as I can see they are SS != DS safe. this works as well. it still might be a good idea to have some kind of 'this stack is in use, use the error stack' for cases, where some stupid 'DOS get upper case', get DBCS xyz, or similar is implemented reentrant in MSDOS, but not in freedos but the urgent problem is solved by your patch as well. tom --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
On Sat, 1 May 2004, tom ehlert wrote:
Problem:
Intel PRO1000 network driver E1000.DOS does
Int21/IoControl XYZ
-- driver
-- Int21/GetVect, Setvect
this will reuse the same DOS stack and crash immediately.
this issue might be also closed by making GetVect/SetVect true reintrant,
but it's a good idea to protect the stack anyway.
+cmp byte [_InDOS],0
+jne int21_onerrorstack
the problem with this is that int28 handlers will now end up on the error
stack instead of the disk api stack. So if an int28-TSR such as THELP
causes a critical error, the critical error will end up on its own
stack...
So I couldn't implement this easily. Instead just make 0x25/0x35
re-entrant. After all DR-DOS can get away with that too (according to
RBIL)
Can you confirm this works (not applying the above?). All this does is to
move the 0x25 and 0x35 handlers to int21_syscall, as far as I can see they
are SS != DS safe.
Bart
--- entry.asm.~1.24.~ Tue Apr 13 21:41:15 2004
+++ entry.asm Sun May 2 16:10:08 2004
@@ -232,7 +232,11 @@
mov dx,[cs:_DGROUP_]
mov ds,dx
+cmp ah,25h
+je int21_user
cmp ah,33h
+je int21_user
+cmp ah,35h
je int21_user
cmp ah,50h
je int21_user
--- inthndlr.c.~1.73.~ Mon Apr 26 19:53:08 2004
+++ inthndlr.c Sun May 2 16:20:01 2004
@@ -69,6 +69,11 @@
switch (irp-AH)
{
+/* Set Interrupt Vector */
+case 0x25:
+ setvec(irp-AL, MK_FP(irp-DS, irp-DX));
+ break;
+
/* DosVars - get/set dos variables */
case 0x33:
switch (irp-AL)
@@ -139,6 +144,15 @@
}
break;
+/* Get Interrupt Vector */
+case 0x35:
+{
+ intvec p = getvec(irp-AL);
+ irp-ES = FP_SEG(p);
+ irp-BX = FP_OFF(p);
+ break;
+}
+
/* Set PSP */
case 0x50:
cu_psp = irp-BX;
@@ -638,9 +652,7 @@
break;
/* Set Interrupt Vector */
-case 0x25:
- setvec(lr.AL, FP_DS_DX);
- break;
+ /* case 0x25: handled above (re-entrant)*/
/* Dos Create New Psp */
case 0x26:
@@ -788,13 +800,7 @@
break;
/* Get Interrupt Vector */
- case 0x35:
- {
-intvec p = getvec((COUNT) lr.AL);
-lr.ES = FP_SEG(p);
-lr.BX = FP_OFF(p);
- }
- break;
+ /* case 0x35: handled above (reentrant) */
/* Dos Get Disk Free Space */
case 0x36:
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
Now, my users are reporting that the boot disk no longer works on machines which have Intel gigabit (PRO/1000) networking hardware. Problem: Intel PRO1000 network driver E1000.DOS does Int21/IoControl XYZ -- driver -- Int21/GetVect, Setvect this will reuse the same DOS stack and crash immediately. this issue might be also closed by making GetVect/SetVect true reintrant, but it's a good idea to protect the stack anyway. [entry.asm, 286] ; call number. Finally, all others run on the disk stack. ; They are evaluated in that order. +cmp byte [_InDOS],0 +jne int21_onerrorstack cmp byte [_ErrorMode],0 je int21_2 int21_onerrorstack: mov cx,_error_tos better solution would protect the both stacks individually. left as exercise to the reader Or you can download my boot disk itself as a 1.44M floppy image: http://unattended.sourceforge.net/testing/ e1000.img one floppy for each adapter - how boring ;) see http://www.nu2.nu/bootdisk/network how this should be done. http://www.drivesnapshot.de/en/makebootdisk.htm is another example ;) tom --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)
Johnson Lam schreef: 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. try HIMEM + UMBPCI (there's even a 3.57beta7 version at the UMBPCI page), just to narrow it down to EMM386. Patrick mentioned E1000.DOS does not like protected mode. UMBPCI avoids protected mode, so there you won't experience any troubles. your email To/CC is a mess, btw. (same message 3 times..) Bernd --- 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
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)
Hello Johnson, JL I got the same problem when trying MSCLIENT, it does work under JL FDXXMS+UMBPCI (try it), but fail with HIMEM+EMM386. I'm quite sure the JL memory manager and hardware not so compatible especially Network JL Interface Card. Freedos EMM386 doesn't support VDS yet, and NET.EXE tries 'auto load high' try LH /L: NET INIT to force loading of network driver into low memory. tom --- 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
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
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 kernel releases. - 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
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)
On Mon, 26 Apr 2004 09:27:31 +0200, you wrote: Hello Tom, try LH /L: NET INIT to force loading of network driver into low memory. Thank you Tom, now the MSCLIENT work, you are really a genius :-) Rgds, Johnson. --- 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/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
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 00CF 0070 0800 04B0 0005 0005 01EC 04B0 143F Invalid opcode at 0212 A73B 0886 0202 0E9E 1038 347F 0012 0001 0033 0001 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
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)
On 25 Apr 2004 18:10:17 -0400, you wrote: Hi Patrick, 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. 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 just finished trying all combination including NOEMS, EMS, VDS ... still not working, and I'm better than you. The 3COM 3c905tx-b only fail to BIND and report hardware error. I can still access FreeDOS without hangup. Rgds, Johnson. --- 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/?cpg297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
