Re: How to debug a 2.4.4 tulip problem?

Re: How to debug a 2.4.4 tulip problem?

[Manfred Spraul]

> 
> What information should I gather when the card is wedged to aid in 
> debugging? Is 'lspci -xxx' enough? Any suggestions would be welcome. 
>
tulip-diag from www.scyld.com.

Do you know if transmit or receive is slow? tcpdump on both ends of the
ping might help.

Re: How to debug a 2.4.4 tulip problem?

[Wayne Whitney]

On Sat, 5 May 2001, Manfred Spraul wrote:

> Do you know if transmit or receive is slow? tcpdump on both ends of
> the ping might help.

Sorry, I don't currently know.

OK, the next time I see this, I'll give tulip-diag a whirl and report
back.  Until then, I can't really provide any more details.

Thanks, Wayne

Re: How to debug a 2.4.4 tulip problem?

[Wayne Whitney]

OK, I captured some tulip-diag info about my tulip problem.  Again,
intermittently my tulip card gets "slow", so that, for example, pinging it
from another machine on the same segment takes on the order of seconds,
rather than milliseconds (this time it was 0.4 seconds instead of the
usual 0.19 milliseconds).

Below is a unified diff of the output of "tulip-diag -aaf -mm"
(actually, -aaf and -mm separately, then merged by hand when I saw most of
the output was the same), both before and during the problem.  I'm happy
to provide any more information that would be helpful; I didn't yet have a
chance to figure out whether the delay occurs during send or receive or
both, but the next time it happens I will endeavor to do so.

Note that this is the PCI rev 32 version of the card; I also have a rev 33
version of the card on the same network, which I think does not have the
have the problem.

I should mention that this data was collected under kernel 2.4.4 with
MOSIX 1.0.0, but I have observed the same problem under kernels 2.2.x and
2.4.x.

Cheers,
Wayne

--- tulip card is working OK
+++ tulip card is "slow"
[whitney]$ tulip-diag -aaf -mm
 tulip-diag.c:v2.07 3/31/2001 Donald Becker (becker@scyld.com)
  http://www.scyld.com/diag/index.html
 Index #1: Found a Lite-On 82c168 PNIC adapter at 0xb800.
 Lite-On 82c168 PNIC chip registers at 0xb800:
- 0x00: 00008000 01ff0000 10450008 378a2000 378a2200 02660010 810c2202 0001fbef
- 0x40: 00000000 00000000 378a22d0 26eb685c 00000020 00000000 00000000 10000001
+ 0x00: 00008000 01ff0007 10450008 33acb000 33acb200 026e0010 810c2202 0001fbef
+ 0x40: 00000000 00000000 33acb250 338a48a0 00000020 00000000 00000000 10000001
  Extended registers:
  80: 00000000 00000000 00000000 00000000 f0022646 f0022646 000000bf 000000bf
- a0: 60fe0000 60fe0000 378a2090 378a2090 26f2d010 26f2d010 0201f978 0201f978
+ a0: 609645e1 609645e1 33acb000 33acb000 3387f840 3387f840 0201f978 0201f978
  c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  Port selection is MII, full-duplex.
  Transmit started, Receive started, full-duplex.
-  The Rx process state is 'Waiting for packets'.
+  The Rx process state is 'Transferring Rx frame into memory'.
   The Tx process state is 'Idle'.
   The transmit threshold is 128.
  MII PHY found at address 1, status 0x782d.
  MII PHY #1 transceiver registers:
    3100 782d 0302 d008 01e1 45e1 0005 2001
    0000 0000 0000 0000 0000 0000 0000 0000
-   0000 0001 0000 0000 0000 003f 0000 8062
+   0000 0001 0000 0001 0000 0150 0000 8062
    0000 04a1 0000 0000 0039 0000 0000 0000.

How to debug a 2.4.4 tulip problem?

[Wayne Whitney]

Hello,

I'm having a small intermittent problem with the tulip driver in linux
2.4.4, and I'm looking for some guidance on how to debug it.

What happens is that on one of my boxes the card ocasionally gets wedged.
That is, network traffic gets painfully slow, e.g. pinging another host on
the same segment causes each ping to take (almost exactly) 1 second,
rather than the usual 200 usecs or so.  Executing ifup/ifdown unwedges the
card.

Some relevant details about this box:
 eth0: Lite-On 82c168 PNIC rev 32 at 0xb800, 00:C0:F0:2D:3D:8A, IRQ 17.
 MSI-6321 motherboard (VIA Apollo Pro)

Now I have a similar box that I think does not show the problem (not 100%
sure).  It has:
 eth0: Lite-On 82c168 PNIC rev 33 at 0xe800, 00:A0:CC:3F:33:32, IRQ 18.
 Tekram P6B40D-A5 motherboard (Intel 440BX)

As a wild guess, it seems like when the card is wedged, some interrupt is
getting lost, so that the transmit or send doesn't occur until a timer
times out.  Perhaps there is a bug in rev 32 of this card that is not in
rev 33.

What information should I gather when the card is wedged to aid in
debugging?  Is 'lspci -xxx' enough?  Any suggestions would be welcome.

Cheers,
Wayne