[eepro100] card reports no resources / RX buffers

Krawl, Roeland RKrawl@microtest.com
Mon, 24 Jul 2000 11:33:12 -0700 

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_01BFF59D.9FB5FFE0
Content-Type: text/plain


If the "No resources" and "No Rx buffers" messages occur occasionally during
driver initialization (even when no network cable is attached) then that is
the symptom that I reported to this mail list and Andrey in March 2000.
Donald Becker did not respond to any of the emails sent to him. 

The following is a summary of the symptom and fix that was posted to this
list in March 2000.

With no network cable attached, then obviously the "No RX buffers" message
is not caused as
 a result of receiving too many packets. In our case, it was the result of
the eepro100 ver. 1.09t driver
 not properly initializing the 82559ER chip.

The "wait_for_cmd_done()" routine (in the eepro100 driver) falsely gives the
impression that the
 routine waits for command completion. After each call to
"wait_for_cmd_done()" 
we added an additional delay to ensure that the command has been completed
before
changing the contents of the System Control Block General Pointer in
preparation for the next command.
 
Apparently, the 82559ER 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. 

As a result of improper initialization, continuous "flow control paused"
interrupts were causing our Linux system to hang. I believe that the
eepro100 driver does not acknowledge the flow control paused interrupts due
to an incorrect status mask. 

The driver is using a SCB status mask of 0xFC00. The Linux driver from Intel
(recently released) correctly uses a status mask of  0xF300. The status mask
of 0xFC00 prevents the driver from acknowledging the flow control and early
receive interrupts in the 82559 chip.


> -----Original Message-----
> From:	Fredrik Persson P (QRA) [SMTP:Fredrik.P.Persson@era.ericsson.se]
> Sent:	Monday, July 24, 2000 1:03 AM
> To:	'eepro100@scyld.com'
> Subject:	RE: [eepro100] card reports no resources / RX buffers
> 
> This is a known bug. As I recall, Andrey S, maintainer of eepro100.c (not
> Donald, at least I *think* so) stated the 20:th this month on this list
> that he is aware of this bug and that he will fix it. You might want to
> try the driver that intel published. I've heard about people beeing
> successful with that one.
> 
> Here is the link (which you might have, but I provide it anyway):
> 
> http://support.intel.com/support/network/adapter/pro100/30504.htm
> 
> /Fredrik Persson
> 
> > -----Original Message-----
> > From:	Andreas.Fey@t-online.de [SMTP:Andreas.Fey@t-online.de]
> > Sent:	den 24 juli 2000 09:28
> > To:	eepro100@scyld.com
> > Subject:	[eepro100] card reports no resources / RX buffers
> > 
> > Hi,
> > 
> > I have problems using two Pro / 100 + Cards (Board assembly 721383-009)
> on Redhat 6.2 with kernel 2.2.16
> > 
> > The error in syslog is:
> > 
> > kernel: eth0: card reports no resources.
> > kernel: eth0: card reports no RX buffers.
> > 
> > After one or more reboots, the cards seem to work until the next reboot.
> > 
> > Probably there is a problem with the driver ? BTW, should I use the
> intel driver instead of Donald Beckers' one ?
> > 
> > Thanx, Andy.
> > 
> > 
> > 
> > _______________________________________________
> > eepro100 mailing list
> > eepro100@scyld.com
> > http://www.scyld.com/mailman/listinfo/eepro100
> 
> 
> _______________________________________________
> eepro100 mailing list
> eepro100@scyld.com
> http://www.scyld.com/mailman/listinfo/eepro100

------_=_NextPart_001_01BFF59D.9FB5FFE0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



RE: [eepro100] card reports no resources / RX buffers






If the "No =
resources" and "No Rx buffers" messages occur =
occasionally during driver initialization (even when no network cable =
is attached) then that is the symptom that I reported to this mail list =
and Andrey in March 2000.



Donald Becker did =
not respond to any of the emails sent to him.=20




The following is a =
summary of the symptom and fix that was posted to this list in March =
2000.




With no network cable attached, then =
obviously the "No RX buffers" message is not caused as

 a result of receiving too many =
packets. In our case, it was the result of the eepro100 ver. 1.09t =
driver

 not properly initializing the =
82559ER chip.




The "wait_for_cmd_done()" =
routine (in the eepro100 driver) falsely gives the impression that =
the

 routine waits for command =
completion. After each call to "wait_for_cmd_done()" 

we added an additional delay to =
ensure that the command has been completed before

changing the contents of the System =
Control Block General Pointer in

preparation for the next =
command.

 

Apparently, the =
82559ER 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. =




As a result of =
improper initialization, continuous "flow control paused" =
interrupts were causing our Linux system to hang. I believe that the =
eepro100 driver does not acknowledge the flow control paused interrupts =
due to an incorrect status mask. 



The driver is using =
a SCB status mask of 0xFC00. The Linux driver from Intel (recently =
released) correctly uses a status mask of  0xF300. The status mask =
of 0xFC00 prevents the driver from acknowledging the flow control and =
early receive interrupts in the 82559 chip.





------_=_NextPart_001_01BFF59D.9FB5FFE0--