eepro100 failure at boot: no resources

Krawl, Roeland RKrawl@microtest.com
Thu Apr 27 15:04:52 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_01BFB07B.63873750
Content-Type: text/plain

If your boot problem occurs when no network cable is attached (to your
Ethernet card) then obviously your "No RX buffers" message is not caused as
a result of receiving too many packets.

Your boot problem is similar to a problem that I (and a co-worker) found in
the eepro100.c driver (version 1.09t) when controlling an 82559ER chip.

The problem was:
The "wait_for_cmd_done()" routine (in the eepro100 driver) falsely gives the
impression that the routine waits for command completion. 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.
 

I doubt that the above problem has been fixed in the version you are using.
I tried to report the problem and a suggested fix however Donald Becker did
not respond to any of the emails sent to him. Andy Savochkin kindly
responded to a recent email and is aware of the problem report and suggested
fix.

Another problem in the driver that is worthy of mention here is:
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:	Orion Poplawski [SMTP:OPoplawski@cqg.com]
> Sent:	26. april 2000 14:56
> To:	linux-eepro100@beowulf.org
> Subject:	eepro100 failure at boot: no resources
> 
> About 50% of the time at boot on of my eepro100 interfaces fails with the
> following two messages being repeated over and over, effectively kiiling
> the
> system:
> 
> eth2: card reports no resources.
> eth2: card reports no RX buffers.
> 
> I'm going to take a stab at the cause of the problem and say it's because
> of
> the large about of broadcast traffic on that particular network.  I'm seen
> similar problems with Intel nics under UnixWare7.
> 
> Here are the boot messages from a normal boot:
> 
> eepro100.c:v1.09j-t 9/29/99 Donald Becker
> http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
> eepro100.c: $Revision: 1.20.2.3 $ 2000/03/02 Modified by Andrey V.
> Savochkin
> <saw@saw.sw.com.sg> and others
> eth0: OEM i82557/i82558 10/100 Ethernet at 0xc383d000, 00:50:8B:66:06:BD,
> IRQ 11.
>   Board assembly 703555-006, Physical connectors present: RJ45
>   Primary interface chip i82555 PHY #1.
>   General self-test: passed.
>   Serial sub-system self-test: passed.
>   Internal registers self-test: passed.
>   ROM checksum self-test: passed (0x24c9f043).
>   Receiver lock-up workaround activated.
> eth1: OEM i82557/i82558 10/100 Ethernet at 0xc383f000, 00:50:8B:66:06:BC,
> IRQ 10.
>   Board assembly 703555-006, Physical connectors present: RJ45
>   Primary interface chip i82555 PHY #1.
>   General self-test: passed.
>   Serial sub-system self-test: passed.
>   Internal registers self-test: passed.
>   ROM checksum self-test: passed (0x24c9f043).
>   Receiver lock-up workaround activated.
> eth2: Intel PCI EtherExpress Pro100 at 0xc3841000, 00:D0:B7:58:62:DB, IRQ
> 9.
>   Board assembly 000000-000, Physical connectors present: RJ45
>   Primary interface chip i82555 PHY #1.
>   General self-test: passed.
>   Serial sub-system self-test: passed.
>   Internal registers self-test: passed.
>   ROM checksum self-test: passed (0x04f4518b).
>   Receiver lock-up workaround activated.
> 
> Any suggestions greatly appreciated.
> 
> - Orion
> 
> -------------------------------------------------------------------
> To unsubscribe send a message body containing "unsubscribe"
> to linux-eepro100-request@beowulf.org

------_=_NextPart_001_01BFB07B.63873750
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

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



RE: eepro100 failure at boot: no resources




If your boot problem =
occurs when no network cable is attached (to your Ethernet card) then =
obviously your "No RX buffers" message is not caused as a =
result of receiving too many packets.



Your boot problem is =
similar to a problem that I (and a co-worker) found in the eepro100.c =
driver (version 1.09t) when controlling an 82559ER chip.



The problem =
was:

The =
"wait_for_cmd_done()" routine (in the eepro100 driver) =
falsely gives the impression that the routine waits for command =
completion. 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.



 




I doubt that the =
above problem has been fixed in the version you are using. I tried to =
report the problem and a suggested fix however Donald Becker did not =
respond to any of the emails sent to him. Andy Savochkin kindly =
responded to a recent email and is aware of the problem report and =
suggested fix.



Another problem in =
the driver that is worthy of mention here is:

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_01BFB07B.63873750--
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-eepro100-request@beowulf.org