eepro100 failure at boot: no resources

Krawl, Roeland RKrawl@microtest.com
Thu Apr 27 19:52:40 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_01BFB0A3.98854DA0
Content-Type: text/plain

Orion,

I suggested that you try removing the network cable before you attempt to
boot so that there is no chance of receiving
any packets whatsoever. Do you then get into the "No Rx bufs" state? 

The following information supplements my previous reply just in case it was
not clearly understood.
 
Your problem is similar to the problem that I identified and fixed if 1 and
2 are true below.

     1. As a result of 10 boot attempts, you have at least one successful
boot and one or more unsuccessful
         boot attempts which result in the "No Rx bufs" and "No resources"
state. In our case, it made no difference
         whether the network cable was attached. The "No Rx bufs" symptom
was caused as a result of improper 82559
         initialization due to a flaw in the "wait_for_cmd_done()" routine.
That routine DOES NOT really wait for command
         done and as a consequence, the 82559 can be improperly initialized.

      2. Your machine appears hung. If your machine hangs, then very
possibly it is due to unserviced NIC interrupts
          which keep the machine so busy that it cant do its real work. In
our case it was unserviced Flow Control
          interrupts which occurred even when no network cable was attached
as a result of improper 82559
          initialization.
          I first modified the interrupt service routine to properly service
flow control interrupts so the machine did not hang.
          (see previous reply about using a status mask of F300H instead of
FC00H).
          To fix the flaw in the "wait_for_cmd_done() routine it was
necessary to modify the routine so that it REALLY DID
           wait for the command to finish. See my previous reply for
additional information.

Roeland Krawl

 
> -----Original Message-----
> From:	Orion Poplawski [SMTP:OPoplawski@cqg.com]
> Sent:	27. april 2000 15:52
> To:	Krawl, Roeland; linux-eepro100@beowulf.org
> Subject:	RE: eepro100 failure at boot: no resources
> 
> If I remove the network cable after I see the stream of errors on the
> console, the errors stop.  Can't access the console afterwards though -
> probably in a bad state.
> 
> I suppose I may give the Intel driver a try.  Anyone have any experience
> with it?
> 
> -----Original Message-----
> From: owner-linux-eepro100@beowulf.org
> [mailto:owner-linux-eepro100@beowulf.org]On Behalf Of Krawl, Roeland
> Sent: Thursday, April 27, 2000 1:04 PM
> To: 'Orion Poplawski'; linux-eepro100@beowulf.org
> Subject: 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.
> 

------_=_NextPart_001_01BFB0A3.98854DA0
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



Orion,

I suggested that you = try removing the network cable before you attempt to boot so that there = is no chance of receiving
any packets = whatsoever. Do you then get into the "No Rx bufs" state? =

The following = information supplements my previous reply just in case it was not = clearly understood.
 
Your problem is = similar to the problem that I identified and fixed if 1 and 2 are true = below.

     1. As a result of 10 boot = attempts, you have at least one successful boot and one or more = unsuccessful
         boot = attempts which result in the "No Rx bufs" and "No = resources" state. In our case, it made no difference
         whether = the network cable was attached. The "No Rx bufs" symptom was = caused as a result of improper 82559
         = initialization due to a flaw in the "wait_for_cmd_done()" = routine. That routine DOES NOT really wait for command

         done = and as a consequence, the 82559 can be improperly initialized.

      2. Your machine appears = hung. If your machine hangs, then very possibly it is due to unserviced = NIC interrupts
          = which keep the machine so busy that it cant do its real work. In our = case it was unserviced Flow Control
          = interrupts which occurred even when no network cable was attached as a = result of improper 82559
          = initialization.
          I = first modified the interrupt service routine to properly service flow = control interrupts so the machine did not hang.

          = (see previous reply about using a status mask of F300H instead of = FC00H).
          = To fix the flaw in the "wait_for_cmd_done() routine it was = necessary to modify the routine so that it REALLY DID

         &nb= sp; wait for the command to finish. See my previous reply for = additional information.

Roeland Krawl

 

------_=_NextPart_001_01BFB0A3.98854DA0-- ------------------------------------------------------------------- To unsubscribe send a message body containing "unsubscribe" to linux-eepro100-request@beowulf.org