kernel 2.2.15 pcmcia 3.1.14 I have a Genius MF3000 network adapter that gets identified as
May 16 21:26:29 debian1 cardmgr[155]: initializing socket 0 May 16 21:26:29 debian1 cardmgr[155]: socket 0: Tulip-based CardBus Fast Ethernet May 16 21:26:29 debian1 kernel: cs: cb_alloc(bus 32): vendor 0x1011, device 0x0019 May 16 21:26:29 debian1 kernel: ROM image dump: May 16 21:26:29 debian1 kernel: image 0: 0x000000-0x0001ff, signature PCIR May 16 21:26:29 debian1 cardmgr[155]: executing: 'insmod /lib/modules/2.2.15/pcmcia/cb_enabler.o' May 16 21:26:29 debian1 cardmgr[155]: executing: 'insmod /lib/modules/2.2.15/pcmcia/tulip_cb.o' May 16 21:26:29 debian1 kernel: cs: cb_config(bus 32) May 16 21:26:29 debian1 kernel: fn 0 bar 1: io 0x200-0x27f May 16 21:26:29 debian1 kernel: fn 0 bar 2: mem 0x600c0000-0x600c03ff May 16 21:26:29 debian1 kernel: fn 0 rom: mem 0x60080000-0x600bffff May 16 21:26:29 debian1 kernel: cs: cb_enable(bus 32) May 16 21:26:29 debian1 kernel: bridge io map 0 (flags 0x21): 0x200-0x27f May 16 21:26:29 debian1 kernel: bridge mem map 0 (flags 0x1): 0x60080000-0x600c0fff May 16 21:26:29 debian1 kernel: tulip_reap() May 16 21:26:29 debian1 kernel: tulip_attach(bus 32, function 0) May 16 21:26:29 debian1 kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov (modified by danilo@cs.uni-magdeburg.de for XIRCOM CBE, fixed by Doug Ledford) May 16 21:26:29 debian1 kernel: eth0: Digital DS21143 Tulip rev 65 at 0x200, 00: A0:0C:90:6D:9A, IRQ 10. May 16 21:26:29 debian1 kernel: eth0: EEPROM default media type Autosense. May 16 21:26:29 debian1 kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. May 16 21:26:29 debian1 kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2) block. May 16 21:26:29 debian1 kernel: eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. May 16 21:26:29 debian1 kernel: eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4) block. May 16 21:26:29 debian1 cardmgr[155]: executing: './network start eth0' Once the network interface is up and running I can use NFS and ssh successfully. However transferring large files with scp or network printing does not work--the transfer stalls. Setting the tulip_cb debug option I see Transmit errors:
May 16 20:42:04 debian1 kernel: In tulip_rx(), entry 13 005a0320. May 16 20:42:04 debian1 kernel: eth0: In tulip_rx(), entry 13 005a0320. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: exiting interrupt, csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: exiting interrupt, csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0670040 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: In tulip_rx(), entry 14 005a0320. May 16 20:42:04 debian1 kernel: eth0: In tulip_rx(), entry 14 005a0320. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: exiting interrupt, csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: Transmit error, Tx status 7fffb200. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: exiting interrupt, csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. May 16 20:42:04 debian1 kernel: eth0: Transmit error, Tx status 7fffb200. May 16 20:42:04 debian1 kernel: eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. When this happens the tulip_diag program reports:
tulip-diag.c:v1.19 10/2/99 Donald Becker (becker@cesdis.gsfc.nasa.gov) Index #1: Found a Digital DS21143 Tulip adapter at 0x200. Port selection is 100mbps-SYM/PCS 100baseTx scrambler, 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 128. The NWay status register is 45e1d2cd. Internal autonegotiation state is 'Negotiation complete'. An strace of the scp process shows it stalled in a write():
write(6, "\376\f\0\211\300PW\350\370&\375\377\203\304\20\350\20,"..., 4096) = 4096
read(3, "\350\37\34\375\377\350\312\37\375\377\215\266\0\0\0\0\213"..., 4096) = 4096
write(6, "\350\37\34\375\377\350\312\37\375\377\215\266\0\0\0\0\213"..., 4096) = 4096
read(3, "\350\17\r\375\377\203\304\20\203\304\370\203\304\364\213"..., 4096) = 4096
write(6, "\350\17\r\375\377\203\304\20\203\304\370\203\304\364\213"..., 4096) = 4096
read(3, "\203\304\364\213E\10\203\300\4P\350Q\2\24\0\203\304\20"..., 4096) = 4096
write(6, "\203\304\364\213E\10\203\300\4P\350Q\2\24\0\203\304\20"..., 4096) = 4096
read(3, "\354\24S\213]\10\307\3|\236 \10\203\304\370j\2\215C\20"..., 4096) = 4096
write(6, "\354\24S\213]\10\307\3|\236 \10\203\304\370j\2\215C\20"..., 4096
^it hangs here
If I cancel the scp file transfer I can then do an NFS copy at several Mb/second. I also have a 3Com 3CCFEM556B which works fine, so the problem would appear to lie with the tulip driver. Any ideas? Philip
|
Messages