Possible flaw in the eepro100 driver version 1.09t

Krawl, Roeland RKrawl@microtest.com
Mon Mar 13 23:05:11 2000


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


------_=_NextPart_001_01BF8D6A.682EBDE0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org