* de2104x problems (and perhaps a clue as to why)
@ 2003-11-26 12:41 Rask Ingemann Lambertsen
2003-12-09 15:20 ` Rask Ingemann Lambertsen
0 siblings, 1 reply; 2+ messages in thread
From: Rask Ingemann Lambertsen @ 2003-11-26 12:41 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Hi.
I'm trying to get the de2104x driver to work with a DE450 board. It looks
like something is wrong with either the code to start/stop the chip. This is
with 2.6.0-test10 with your 2.6.0-test9-bk24-netdrv-exp1 patch and the
de2104x fixes posted in the last few days.
$ modprobe -k de2104x
$ ethtool -s eth0 port bnc
$ tulip-diag -faa
tulip-diag.c:v2.17 5/6/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x2080.
Digital DC21041 Tulip chip registers at 0x2080:
0x00: ffe00000 ffffffff ffffffff 016dc000 016dc400 fc000000 7ffc0040 fffe0000
0x40: fffe0000 ffff4bf8 ffffffff fffe0000 000000c4 ffff0000 ffffffff ffff0000
Port selection is half-duplex.
Transmit stopped, Receive stopped.
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
The transmit unit is set to store-and-forward.
The NWay status register is 000000c4.
100baseTx link good.
10baseT link good.
Internal autonegotiation state is 'Autonegotiation disabled'.
$ ifconfig eth0 up
$ tulip-diag -faa
tulip-diag.c:v2.17 5/6/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x2080.
Digital DC21041 Tulip chip registers at 0x2080:
0x00: ffe00000 ffffffff ffffffff 014c5000 014c5400 fc660000 7ffc2002 ffffb0d5
0x40: fffe0000 ffff03ff ffffffff fffe0000 000020c4 ffffef09 fffff7fd ffff0006
Port selection is half-duplex.
Transmit started, Receive started.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit unit is set to store-and-forward.
The NWay status register is 000020c4.
100baseTx link good.
10baseT link good.
Internal autonegotiation state is 'Ability detect'.
$ ifconfig eth0 down
$ tulip-diag -faa
tulip-diag.c:v2.17 5/6/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x2080.
Digital DC21041 Tulip chip registers at 0x2080:
0x00: ffe00000 ffffffff ffffffff 014c5000 014c5400 fc000000 7ffc0000 fffe0000
0x40: fffe0000 ffff4bf8 ffffffff fffe0000 000020c4 ffffef09 fffff7fd ffff0006
Port selection is half-duplex.
Transmit stopped, Receive stopped.
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
The transmit unit is set to store-and-forward.
The NWay status register is 000020c4.
100baseTx link good.
10baseT link good.
Internal autonegotiation state is 'Ability detect'.
So far so good. Now, if I try to bring the interface up again, the trouble
starts:
$ ifconfig eth0 up
$ tulip-diag -faa
tulip-diag.c:v2.17 5/6/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x2080.
Digital DC21041 Tulip chip registers at 0x2080:
0x00: ffe00000 ffffffff ffffffff 0171a000 0171a400 fc120000 7ffc2002 ffffb0d5
0x40: fffe0000 ffff03ff ffffffff fffe0000 000020c4 ffffef09 fffff7fd ffff0006
Port selection is half-duplex.
Transmit started, Receive started.
The Rx process state is 'Reading a Rx descriptor'.
The Tx process state is 'Reading a Tx descriptor'.
The transmit unit is set to store-and-forward.
The NWay status register is 000020c4.
100baseTx link good.
10baseT link good.
Internal autonegotiation state is 'Ability detect'.
Taking the interface down no longer works either:
$ ifconfig eth0 down
eth0: timeout expired stopping dma
$ tulip-diag -faa
tulip-diag.c:v2.17 5/6/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x2080.
Digital DC21041 Tulip chip registers at 0x2080:
0x00: ffe00000 ffffffff ffffffff 0171a000 0171a400 fc120000 7ffc0000 fffe0000
0x40: fffe0000 ffff4bf8 ffffffff fffe0000 000020c4 ffffef09 fffff7fd ffff0006
Port selection is half-duplex.
Transmit stopped, Receive stopped.
The Rx process state is 'Reading a Rx descriptor'.
The Tx process state is 'Reading a Tx descriptor'.
The transmit unit is set to store-and-forward.
The NWay status register is 000020c4.
100baseTx link good.
10baseT link good.
Internal autonegotiation state is 'Ability detect'.
The chip appears to get stuck reading the descriptors. Reloading the module
is necessary to make the interface work again.
The de4x5 driver works fine.
$ rmmod de2104x
$ modprobe -k de4x5
$ ifconfig eth0 up
$ ifconfig eth0 down
$ ifconfig eth0 up
$ tulip-diag -faa
tulip-diag.c:v2.17 5/6/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x2080.
Digital DC21041 Tulip chip registers at 0x2080:
0x00: ffe08400 ffffffff ffffffff 0139a000 0139a080 fc660000 7ffc2002 ffff8065
0x40: fffe0000 ffff03ff ffffffff fffe0000 000000c4 ffffef09 fffff73d ffff0006
Port selection is half-duplex.
Transmit started, Receive started.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit unit is set to store-and-forward.
The NWay status register is 000000c4.
100baseTx link good.
10baseT link good.
Internal autonegotiation state is 'Autonegotiation disabled'.
lspci dug up something interesting:
$ modprobe -k de2104x
$ ethtool -s eth0 port bnc
$ ifconfig eth0 up
$ ifconfig eth0 down
$ ifconfig eth0 up
$ lspci -vvv
[...]
00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 11)
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-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 2080 [size=128]
Region 1: Memory at 42200000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=256K]
[...]
Say what? It says "BusMaster-", which means busmaster DMA is disabled,
right? Then of course it won't work. Is this because de_close() calls
pci_disable_device() and de_open() doesn't not reenable the device?
--
Regards,
Rask Ingemann Lambertsen
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: de2104x problems (and perhaps a clue as to why)
2003-11-26 12:41 de2104x problems (and perhaps a clue as to why) Rask Ingemann Lambertsen
@ 2003-12-09 15:20 ` Rask Ingemann Lambertsen
0 siblings, 0 replies; 2+ messages in thread
From: Rask Ingemann Lambertsen @ 2003-12-09 15:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
On Wed, Nov 26, 2003 at 01:41:40PM +0100, Rask Ingemann Lambertsen wrote:
[snip]
> lspci dug up something interesting:
> $ modprobe -k de2104x
> $ ethtool -s eth0 port bnc
> $ ifconfig eth0 up
> $ ifconfig eth0 down
> $ ifconfig eth0 up
> $ lspci -vvv
> [...]
> 00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 11)
> 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-
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at 2080 [size=128]
> Region 1: Memory at 42200000 (32-bit, non-prefetchable) [size=128]
> Expansion ROM at <unassigned> [disabled] [size=256K]
> [...]
>
> Say what? It says "BusMaster-", which means busmaster DMA is disabled,
> right? Then of course it won't work. Is this because de_close() calls
> pci_disable_device() and de_open() doesn't not reenable the device?
Indeed pci_disable_device() disables busmaster DMA, so this needs to be
reenabled by dev->open(). This patch seems to fix the problem by reenabling
the device and busmaster DMA in de_init_hw():
--- linux-2.6.0-test8/drivers/net/tulip/de2104x.c~ Wed Nov 26 13:37:17 2003
+++ linux-2.6.0-test8/drivers/net/tulip/de2104x.c Wed Nov 26 13:37:17 2003
@@ -1253,6 +1253,10 @@ static int de_init_hw (struct de_private
struct net_device *dev = de->dev;
int rc;
+ rc = pci_enable_device(de->pdev);
+ if (rc)
+ return (rc);
+ pci_set_master(de->pdev);
de_adapter_wake(de);
de->macmode = dr32(MacMode) & ~MacModeClear;
But this causes pci_enable_device() and pci_set_busmaster() to be called
twice when the interface is brought up for the first time after loading the
module. The documentation does not say that doing so is OK. Perhaps we should
simply remove the pci_disable_device() call from dev->close()? de2104x is a
bit unusual in calling pci_disable_device() from dev-close(). Jeff?
--
Regards,
Rask Ingemann Lambertsen
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-12-09 15:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-26 12:41 de2104x problems (and perhaps a clue as to why) Rask Ingemann Lambertsen
2003-12-09 15:20 ` Rask Ingemann Lambertsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).