Same old story, bugger still does it. Have to set the link down/up to
get it running again. I had to reset two systems tonight, one up for
~60 days, one up for two days. Both have this card. Unrelated traffic.
This is kernel 2.4.0-test13-pre4
00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
Subsystem: Unknown device 1385:f004
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 set
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at f800
Region 1: Memory at fdfffc00 (32-bit, non-prefetchable)
-d
David wrote:
>
> Same old story, bugger still does it. Have to set the link down/up to
> get it running again.
>
> 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
> 20)
>
I missed your earlier mails, could you resend the details?
I'm interested in the output from
tulip-diag -m -a -f
before and after a link failure.
I'm aware that the tulip drivers doesn't handle cable disconnects and
reconnects with MII pnic cards. I have a patch for that problem, but it
affects _all_ MII tulip cards, and thus it won't be included soon. If
tulip-diag says "10mbps-serial", then you have run into that bug.
--
Manfred
Manfred wrote:
> David wrote:
> >
> > Same old story, bugger still does it. Have to set the link down/up to
> > get it running again.
> >
> > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
> > 20)
> >
>
> I missed your earlier mails, could you resend the details?
> I'm interested in the output from
>
> tulip-diag -m -a -f
>
> before and after a link failure.
>
> I'm aware that the tulip drivers doesn't handle cable disconnects and
> reconnects with MII pnic cards. I have a patch for that problem, but it
> affects _all_ MII tulip cards, and thus it won't be included soon. If
> tulip-diag says "10mbps-serial", then you have run into that bug.
>
> --
> Manfred
Here's the before, when the after happens..
# ./tulip-diag -m -a -f
tulip-diag.c:v2.04 9/26/2000 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xf800.
Lite-On 82c168 PNIC chip registers at 0xf800:
00008000 01ff0000 00450008 0118f000 0118f200 02660010 814c2202 0001ebef
00000000 00000000 0118f2d0 01e3a88c 00000020 00000000 00000000 10000001
00000000 00000000 f0041385 000000bf 609641e1 0118f110 00c99010 0001e978
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 Tx process state is 'Idle'.
The transmit threshold is 72.
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
3000 782d 0040 6212 01e1 41e1 0003 0000
0000 0000 0000 0000 0000 0000 0000 0000
5000 032b 0002 0046 0000 01cd 0100 0000
003f f53e 0f00 ff00 002f 4000 80a0 000b.
This particular one is on a crossover @ 100 FD with a pcmcia tulip
card...which works fine.
The other machine I had reset tonight was on a crossover w/ cisco 3640
iirc.
-d
On Thu, Dec 28, 2000 at 12:26:06PM +0100, Manfred wrote:
> David wrote:
> >
> > Same old story, bugger still does it. Have to set the link down/up to
> > get it running again.
> >
> > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
> > 20)
> >
>
> I missed your earlier mails, could you resend the details?
> I'm interested in the output from
>
> tulip-diag -m -a -f
>
> before and after a link failure.
>
>
> I'm aware that the tulip drivers doesn't handle cable disconnects and
> reconnects with MII pnic cards. I have a patch for that problem, but it
> affects _all_ MII tulip cards, and thus it won't be included soon. If
> tulip-diag says "10mbps-serial", then you have run into that bug.
I have the same transmit timeout problem, but with a D-Link via rhine
board. I'm running -test10, and it seems to happen under high
(interrupt?) load with both heavy disk and network
activity. Interestingly, it appears to happen more often when the other
end of the network activity is a 10BaseT link. I'm using a Netgear
dual-speed hub.
Do you think these might be related?