[Freedos-kernel] Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)

2004-04-25 Thread Johnson Lam
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Re: [Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS

2004-04-25 Thread Michael Devore
At 07:08 PM 4/25/2004 -0400, Patrick J. LoPresti wrote:
>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 386SWAT debugger.
>
>After paring down my boot disk, I got 386SWAT to fit (with 2K to
>spare).  And by invoking it with "DEVICE=A:\386swat.lod TRAPINV", I
>actually get thrown into the debugger where I used to get invalid
>opcode + reboot.
>
>So it's a start.  But I really have no idea what I am looking at...

First thing to look at is the register values, which are across the top line.   We 
need those values.  Then look at the failing CPU instruction line which is highlighted 
in the main window.  That together with the register values should give the immediate 
reason for failure.  The EFL flags value right above the main window would be good 
info to know, too.




---
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


[Freedos-kernel] Re: Intel PRO/1000 driver fails under FreeDOS

2004-04-25 Thread Patrick J. LoPresti
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 386SWAT debugger.

After paring down my boot disk, I got 386SWAT to fit (with 2K to
spare).  And by invoking it with "DEVICE=A:\386swat.lod TRAPINV", I
actually get thrown into the debugger where I used to get invalid
opcode + reboot.

So it's a start.  But I really have no idea what I am looking at...

 - 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


Re: [Freedos-kernel] cvs refresh

2004-04-25 Thread Jim Hall
Arkady V.Belousov wrote:
Hi!

24-Апр-2004 17:05 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> Date: Sat, 24 Apr 2004 17:05:18 +0100 (BST)

When latest patches will be reflected in CVS snapshot on site
(kernel.tgz?)? I wish to check how they are applied "in complete".
BO> every day at 10am GMT

 How GMT relates to UTC (which TZ)? I mean, how GMT relates to my MSK TZ
(which is currently +4 to UTC)?
Arkady:

Your time zone is GMT+0400.  So at 10am GMT, it is 2pm in your TZ.

-jh

--
_
This email message has been automatically encrypted using ROT-26.
---
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


[Freedos-kernel] Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS

2004-04-25 Thread Patrick J. LoPresti
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


[Freedos-kernel] Intel PRO/1000 driver fails under FreeDOS

2004-04-25 Thread Patrick J. LoPresti
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
 yesterday)

...it still happens, only I see this:

  Illegal Instruction occurred
  CS=3046  IP=08CC  SS=00CF  SP=08B8  DS=  ES=DC11
  EAX=  EBX=0F8C  ECX=0003  EDX=0AE4
  ESI=  EDI=000F  EBP=

  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


Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22

2004-04-25 Thread Alain
wcc (wpp neither) can't compile multiple files at the sametime. You can
only try to decrease the load time of wcc.exe Maybe compressing it or
binding with a dos extender helps. Maybe not.
I use it in RAM-DISK (with xmsdsk), allong with all .H files and some 
more ;-)

Alain



---
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