This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF8D6A.682EBDE0 Content-Type: text/plain As a result of an 82559ER initialization problem, continuous "flow control paused" interrupts were causing our Linux system to hang. The eepro100 driver does not acknowledge the flow control paused interrupts. Another symptom of the initialization problem was that the 82559ER was reporting a status which indicated "no resources" and "No Rx bufs". The initialization problem was fixed by modifying the speedo_resume() routine slightly. After each call to "wait_for_cmd_done()" we added a call to uwait() to delay 30 microseconds. This ensures that the NIC has a little extra time to examine the System Control Block General Pointer before the driver changes it in preparation for sending the next command. Apparently, the 82559 was reporting "no Rx bufs" as a result of obtaining a bogus pointer to the Rx Ring because the real Rx ring was known to be properly initialized and Rx resources were definitely available. The cure described above was difficult to find because small changes to the eepro100 driver or other parts of the Linux kernel would cause the symptom to go away. The symptom would also go away by simply re-ordering the object file names in the kernel/drivers/net/Makefile. Roeland Krawl > -----Original Message----- > From: Andrey Savochkin [SMTP:saw@saw.sw.com.sg] > Sent: Monday, March 13, 2000 2:44 AM > To: Krawl, Roeland; 'linux-eepro100@beowulf.gsfc.nasa.gov' > Subject: Re: Possible flaw in the eepro100 driver version 1.09t > > On Sat, Mar 11, 2000 at 12:09:02AM -0700, Krawl, Roeland wrote: > > This seems to be the only forum for reporting eepro100 version 1.09t > driver > > bugs and getting any kind of feedback (hopefully). The author of this > driver > > has been unreachable for weeks therefore feedback from device driver > > programmers who have intimate knowledge of this driver would be > appreciated. > > Other possible problems not mentioned here could be discussed also. > > > > To properly acknowledge "early receive" and "flow control paused" > > interrupts, it appears that the status mask should be 0xF300 instead of > > 0xFC00. > > I suspect that the driver acknowledges interrupts that have a clear > meaning > and were well-documented at the beginning of driver development. > All these "early receive" and "flow control paused" thing look fairly > obscure > at least for me. > > Do you have a clear description of what these kind of interrupts mean and > when they're supposed to be triggered? > > Best regards > Andrey V. > Savochkin > ------------------------------------------------------------------- > To unsubscribe send a message body containing "unsubscribe" > to linux-eepro100-request@beowulf.org ------_=_NextPart_001_01BF8D6A.682EBDE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">RE: Possible flaw in the eepro100 driver version 1.09t As a result of an = 82559ER initialization problem, continuous "flow control = paused" interrupts were causing our Linux system to hang. The = eepro100 driver does not acknowledge the flow control paused = interrupts. Another symptom of the initialization problem was that the = 82559ER was reporting a status which indicated "no resources" = and "No Rx bufs".
The initialization = problem was fixed by modifying the speedo_resume() routine slightly. = After each call to "wait_for_cmd_done()" we added a call to = uwait() to delay 30 microseconds. This ensures that the NIC has a = little extra time to examine the System Control Block General Pointer = before the driver changes it in preparation for sending the next = command.
Apparently, the = 82559 was reporting "no Rx bufs" as a result of obtaining a = bogus pointer to the Rx Ring because the real Rx ring was known to be = properly initialized and Rx resources were definitely available. =
The cure described = above was difficult to find because small changes to the eepro100 = driver or other parts of the Linux kernel would cause the symptom to go = away. The symptom would also go away by simply re-ordering the object = file names in the kernel/drivers/net/Makefile.
Roeland = Krawl
-----Original Message-----
From: Andrey Savochkin =
[SMTP:saw@saw.sw.com.sg]
Sent: Monday, March 13, 2000 2:44 AM
To: Krawl, Roeland; =
'linux-eepro100@beowulf.gsfc.nasa.gov'
Subject: =
Re: Possible flaw in the eepro100 =
driver version 1.09t
On Sat, Mar 11, 2000 at 12:09:02AM =
-0700, Krawl, Roeland wrote:
> This seems to be the only forum =
for reporting eepro100 version 1.09t driver
> bugs and getting any kind of =
feedback (hopefully). The author of this driver
> has been unreachable for weeks =
therefore feedback from device driver
> programmers who have intimate =
knowledge of this driver would be appreciated.
> Other possible problems not =
mentioned here could be discussed also.
>
> To properly acknowledge =
"early receive" and "flow control paused"
> interrupts, it appears =
that the status mask should be 0xF300 instead of
> 0xFC00.
I suspect that the driver acknowledges =
interrupts that have a clear meaning
and were well-documented at the =
beginning of driver development.
All these "early receive" =
and "flow control paused" thing look fairly obscure
at least for me.
Do you have a clear description of =
what these kind of interrupts mean and
when they're supposed to be =
triggered?
Best regards
=
=
=
=
Andrey V.
=
=
=
=
Savochkin
---------------------------------------------------------=
----------
To unsubscribe send a message body =
containing "unsubscribe"
to =
linux-eepro100-request@beowulf.org