* r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
@ 2006-07-28 10:11 Lennert Buytenhek
2006-07-28 10:49 ` Francois Romieu
2006-08-18 21:28 ` [PATCH,RFC] " Lennert Buytenhek
0 siblings, 2 replies; 19+ messages in thread
From: Lennert Buytenhek @ 2006-07-28 10:11 UTC (permalink / raw)
To: romieu; +Cc: netdev, tbm
Hi!
We're currently working on getting the Thecus n2100 supported in 2.6.
http://www.thecus.com/products_over.php?cid=1&pid=1
Amongst other nice goodies, it has two on-board RTL8110SB gigabit
controllers. The realtek-supplied 'r1000' driver kind of sort of works,
if you don't mind the machine hanging or crashing if you unplug the cable
at the wrong moment.
The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work
initially, but they don't actually seem to transmit any packets on the
wire, nor do they receive any.
Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC
address for eth1 being incorrect (boot loader bug, being worked on)
there don't seem to be any strange messages or errors.
It doesn't seem to be a PHY configuration issue -- with a custom program
to dump the MDIO registers (is there any reason r8169 doesn't support
mii-tool, by the way? will you take a patch to add that?), we get the
following results, with only minor differences that shouldn't be causing
this issue:
r1000
0000 1000 796d 001c c913 0de1 45e1 0007 2001
0008 45e1 0300 0000 0000 1007 f880 0000 3000
0010 0060 6c00 0000 2d40 0060 0000 0400 2108
0018 2740 8c00 0040 0162 846c 0000 0123 0000
r8169
0000 1000 796d 001c c913 0de1 45e1 0007 2001
0008 45e1 0200 0000 0000 1007 f880 0000 3000
0010 0060 6c00 0000 2c40 0060 0000 0400 2108
0018 2740 8c00 0040 0162 846c 0000 0123 0000
Just wondering if you've seen this kind of behavior before before I dig
into it further? I'm pretty sure the hardware is okay, since r1000 works,
and the on-board SATA and UHCI/EHCI USB work fine as well.
cheers,
Lennert
2.6.18-rc2, r8169
=================
Using base address 0x00218000 and length 0x0017e3a8
Uncompressing Linux.............................................................
Linux version 2.6.18-rc2 (buytenh@psi.wantstofly.org) (gcc version 4.0.1) #6 We6
CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=0000397f
Machine: Thecus N2100
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists. Total pages: 32768
Kernel command line: console=ttyS0,115200 root=/dev/nfs ip=bootp mem=128M
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126592KB available (2681K code, 459K data, 104K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
PCI: bus0: Fast back to back transfers disabled
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
NetWinder Floating Point Emulator V0.97 (double precision)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
SGI XFS with ACLs, security attributes, no debug enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xfe800000 (irq = 0) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Intel(R) PRO/1000 Network Driver - version 7.1.9-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
r8169 Gigabit Ethernet driver 2.2LK loaded
eth0: RTL8169 at 0xc8850200, 00:14:fd:10:27:72, IRQ 27
r8169 Gigabit Ethernet driver 2.2LK loaded
eth1: RTL8169 at 0xc8852300, 00:14:fd:10:00:00, IRQ 28
physmap platform flash device: 01000000 at f0000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset 0xfe0000
6 RedBoot partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00d40000 : "ramdisk"
0x00d40000-0x00ea0000 : "kernel"
0x00ea0000-0x00fc0000 : "user"
0x00fc0000-0x00fc1000 : "RedBoot config"
0x00fe0000-0x01000000 : "FIS directory"
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
r8169: eth0: link down
r8169: eth1: link down
r8169: eth0: link up
Sending BOOTP requests ......
[ nothing happens, it never sends or receives any packets ]
2.6.17, r1000 (r1000 debug enabled)
=============
Linux version 2.6.17 (Debian 2.6.17-5) (maks@sternwelten.at) (gcc version 4.1.2 20060727 (prerelease)) #12 Fri Jul 28 08:21:17 UTC 2006
CPU: XScale-IOP8032x Family [69052e30] revision 0 (ARMv5TE)
Machine ID: 1101 (0x44d)
Machine: Thecus N2100
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:7
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/sda3 mem=128M@0xa0000000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 127232KB available (2008K code, 475K data, 88K init)
Calibrating delay loop... 593.10 BogoMIPS (lpj=2965504)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
PCI: bus0: Fast back to back transfers disabled
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
NetWinder Floating Point Emulator V0.97 (double precision)
audit: initializing netlink socket (disabled)
audit(0.450:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0xfe800000 (irq = 28) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
r1000: --------------------------
r1000: dev->mtu = 1500
r1000: priv->curr_mtu_size = 1500
r1000: priv->tx_pkt_len = 1514
r1000: priv->rx_pkt_len = 1514
r1000: priv->hw_rx_pkt_len = 1522
r1000: --------------------------
eth0: Identified chip type is 'RTL8169SB/8110SB'.
eth0: r10001.02, the Linux device driver for Realtek Ethernet Controllers at 0xfe000000, 00:14:fd:10:27:74, IRQ 27
r1000: priv->mcfg=4, priv->pcfg=3
r1000: Set MAC Reg C+CR Offset 0x82h = 0x01h
eth0: Auto-negotiation Enabled.
eth0: 100Mbps Full-duplex operation.
r1000: priv->linkstatus = 0x08
Realtek RTL8169/8110 Family Gigabit Ethernet Network Adapter
Driver version:1.02
Released date:2006/02/23
Link Status:Linked
Link Speed:100Mbps
Duplex mode:Full-Duplex
I/O Base:0xFE000000(I/O port)
IRQ:27
r1000: --------------------------
r1000: dev->mtu = 1500
r1000: priv->curr_mtu_size = 1500
r1000: priv->tx_pkt_len = 1514
r1000: priv->rx_pkt_len = 1514
r1000: priv->hw_rx_pkt_len = 1522
r1000: --------------------------
eth1: Identified chip type is 'RTL8169SB/8110SB'.
eth1: r10001.02, the Linux device driver for Realtek Ethernet Controllers at 0xfe000400, 00:14:fd:10:00:00, IRQ 28
r1000: priv->mcfg=4, priv->pcfg=3
r1000: Set MAC Reg C+CR Offset 0x82h = 0x01h
eth1: Auto-negotiation Enabled.
r1000: priv->linkstatus = 0x04
Realtek RTL8169/8110 Family Gigabit Ethernet Network Adapter
Driver version:1.02
Released date:2006/02/23
Link Status:Not Linked
I/O Base:0xFE000400(I/O port)
IRQ:28
libata version 1.20 loaded.
sata_sil 0000:00:03.0: version 0.9
ata1: SATA max UDMA/100 cmd 0xC885E080 ctl 0xC885E08A bmdma 0xC885E000 irq 29
ata2: SATA max UDMA/100 cmd 0xC885E0C0 ctl 0xC885E0CA bmdma 0xC885E008 irq 29
ata1: SATA link down (SStatus 0)
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f69 84:4773 85:7c69 86:3e01 87:4763 88:207f
ata2: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
Vendor: ATA Model: Maxtor 6V300F0 Rev: VA11
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 > sda3
sd 1:0:0:0: Attached scsi disk sda
i2c /dev entries driver
NET: Registered protocol family 26
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 88K
Adding 506008k swap on /dev/sda5. Priority:-1 extents:1 across:506008k
EXT3 FS on sda3, internal journal
r1000: Set MAC Reg C+CR Offset 0xE0: bit-3.
r1000: FIX PCS -> r1000_request_timer
r1000: request_timer at 0xc7d402d0
r1000: eth0: r1000_open() alloc_rxskb_cnt = 1024
r1000: r1000_start_xmit: TX pkt_size = 342
r1000: r1000_rx_interrupt: RX pkt_size = 590
r1000: r1000_start_xmit: TX pkt_size = 342
r1000: r1000_rx_interrupt: RX pkt_size = 590
r1000: r1000_start_xmit: TX pkt_size = 42
r1000: r1000_rx_interrupt: RX pkt_size = 60
r1000: r1000_start_xmit: TX pkt_size = 67
r1000: r1000_rx_interrupt: RX pkt_size = 142
r1000: r1000_start_xmit: TX pkt_size = 67
r1000: r1000_rx_interrupt: RX pkt_size = 142
r1000: r1000_start_xmit: TX pkt_size = 67
r1000: r1000_rx_interrupt: RX pkt_size = 142
r1000: r1000_start_xmit: TX pkt_size = 67
r1000: r1000_rx_interrupt: RX pkt_size = 142
2.6.17, r8169
=============
Linux version 2.6.17 (Debian 2.6.17-5) (maks@sternwelten.at) (gcc version 4.1.2 20060727 (prerelease)) #17 Fri Jul 28 09:07:36 UTC 2006
CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE)
Machine ID: 1101 (0x44d)
Machine: Thecus N2100
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:7
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/sda3 mem=128M@0xa0000000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 127232KB available (2012K code, 477K data, 88K init)
Calibrating delay loop... 593.10 BogoMIPS (lpj=2965504)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
PCI: bus0: Fast back to back transfers disabled
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
NetWinder Floating Point Emulator V0.97 (double precision)
audit: initializing netlink socket (disabled)
audit(0.560:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0xfe800000 (irq = 28) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
r8169 Gigabit Ethernet driver 2.2LK loaded
r8169: mac_version == Unknown
r8169: phy_version == RTL_GIGA_PHY_VER_D (0000)
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: RTL8169 at 0xc885e200, 00:14:fd:10:27:74, IRQ 27
r8169: mac_version == Unknown
r8169: phy_version == RTL_GIGA_PHY_VER_D (0000)
r8169: MAC version != 0 && PHY version == 0 or 1
r8169: Do final_reg2.cfg
r8169: Set MAC Reg C+CR Offset 0x82h = 0x01h
r8169 Gigabit Ethernet driver 2.2LK loaded
r8169: mac_version == Unknown
r8169: phy_version == RTL_GIGA_PHY_VER_D (0000)
eth1: Identified chip type is 'RTL8169s/8110s'.
eth1: RTL8169 at 0xc8860300, 00:14:fd:10:00:00, IRQ 28
r8169: mac_version == Unknown
r8169: phy_version == RTL_GIGA_PHY_VER_D (0000)
r8169: MAC version != 0 && PHY version == 0 or 1
r8169: Do final_reg2.cfg
r8169: Set MAC Reg C+CR Offset 0x82h = 0x01h
libata version 1.20 loaded.
sata_sil 0000:00:03.0: version 0.9
sata_sil 0000:00:03.0: Applying R_ERR on DMA activate FIS errata fix
ata1: SATA max UDMA/100 cmd 0xC8862080 ctl 0xC886208A bmdma 0xC8862000 irq 29
ata2: SATA max UDMA/100 cmd 0xC88620C0 ctl 0xC88620CA bmdma 0xC8862008 irq 29
ata1: SATA link down (SStatus 0)
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f69 84:4773 85:7c69 86:3e01 87:4763 88:007f
ata2: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
Vendor: ATA Model: Maxtor 6V300F0 Rev: VA11
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 > sda3
sd 1:0:0:0: Attached scsi disk sda
i2c /dev entries driver
NET: Registered protocol family 26
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 88K
Adding 506008k swap on /dev/sda5. Priority:-1 extents:1 across:506008k
EXT3 FS on sda3, internal journal
r8169: eth0: link up
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 10:11 r8169 driver problem with RTL8110SB chip (on iop3xx ARM board) Lennert Buytenhek
@ 2006-07-28 10:49 ` Francois Romieu
2006-07-28 11:15 ` Lennert Buytenhek
2006-08-18 21:28 ` [PATCH,RFC] " Lennert Buytenhek
1 sibling, 1 reply; 19+ messages in thread
From: Francois Romieu @ 2006-07-28 10:49 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, tbm
Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> We're currently working on getting the Thecus n2100 supported in 2.6.
>
> http://www.thecus.com/products_over.php?cid=1&pid=1
I should really write some wish-list one day...
> Amongst other nice goodies, it has two on-board RTL8110SB gigabit
> controllers. The realtek-supplied 'r1000' driver kind of sort of works,
Ok. That's good to know.
> The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work
> initially, but they don't actually seem to transmit any packets on the
> wire, nor do they receive any.
>
> Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC
> address for eth1 being incorrect (boot loader bug, being worked on)
> there don't seem to be any strange messages or errors.
Can you send:
- the output of 'lspci -vvx'
- the content of /proc/interrupts
- an ethtool dump of the registers. I don't know if Realtek's driver support
but it can help even the in-kernel driver
> It doesn't seem to be a PHY configuration issue -- with a custom program
> to dump the MDIO registers (is there any reason r8169 doesn't support
> mii-tool, by the way? will you take a patch to add that?), we get the
I had written it once, with some rework of the mii functions in the driver.
It was hit by conflicts generated by various changes as well as higher
priority bugs/features requests. You can send your code or I can resurrect
it at your option.
[...]
> Just wondering if you've seen this kind of behavior before before I dig
> into it further? I'm pretty sure the hardware is okay, since r1000 works,
> and the on-board SATA and UHCI/EHCI USB work fine as well.
I have had a few success reports with the 8110 (and failures too, see
http://bugzilla.kernel.org/show_bug.cgi?id=5284) but I have not received
reports for this behavior lately. Complete lack of Rx/Tx activity have
been observed due to some irq problems. It does not seem to be the issue
here.
--
Ueimor
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 10:49 ` Francois Romieu
@ 2006-07-28 11:15 ` Lennert Buytenhek
2006-07-28 11:52 ` Martin Michlmayr
2006-07-28 12:28 ` Jamal Hadi Salim
0 siblings, 2 replies; 19+ messages in thread
From: Lennert Buytenhek @ 2006-07-28 11:15 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, tbm
On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote:
> > The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work
> > initially, but they don't actually seem to transmit any packets on the
> > wire, nor do they receive any.
> >
> > Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC
> > address for eth1 being incorrect (boot loader bug, being worked on)
> > there don't seem to be any strange messages or errors.
>
> Can you send:
> - the output of 'lspci -vvx'
0000:00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
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: 0 (1000ns min, 250ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 27
Region 0: I/O ports at fe000000 [size=256]
Region 1: Memory at 800a0200 (32-bit, non-prefetchable) [size=256]
Expansion ROM at 80080000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Vital Product Data
00: ec 10 69 81 47 01 30 c2 10 00 00 02 08 00 00 00
10: 01 00 00 90 00 02 0a 40 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81
30: 00 00 fc dd dc 00 00 00 00 00 00 00 1b 01 04 01
0000:00:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
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: 0 (1000ns min, 250ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 28
Region 0: I/O ports at fe000400 [size=256]
Region 1: Memory at 800a0300 (32-bit, non-prefetchable) [size=256]
Expansion ROM at 80090000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Vital Product Data
00: ec 10 69 81 47 01 38 02 10 00 00 02 08 00 00 00
10: 01 04 00 90 00 03 0a 40 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81
30: 00 00 98 56 dc 00 00 00 00 00 00 00 1c 01 04 01
0000:00:03.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3512 [SATALink/SATARaid] Serial ATA Controller
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: 0, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 29
Region 0: I/O ports at fe000850 [size=8]
Region 1: I/O ports at fe000860 [size=4]
Region 2: I/O ports at fe000858 [size=8]
Region 3: I/O ports at fe000864 [size=4]
Region 4: I/O ports at fe000840 [size=16]
Region 5: Memory at 800a0000 (32-bit, non-prefetchable) [size=512]
Expansion ROM at 80000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 95 10 12 35 47 01 b0 02 01 00 80 01 08 00 00 00
10: 51 08 00 90 61 08 00 90 59 08 00 90 65 08 00 90
20: 41 08 00 90 00 00 0a 40 00 00 00 00 95 10 12 35
30: 00 00 00 00 60 00 00 00 00 00 00 00 1d 01 00 00
0000:00:04.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
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: 22, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 28
Region 4: I/O ports at fe000800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 38 30 47 01 10 02 61 00 03 0c 08 16 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 08 00 90 00 00 00 00 00 00 00 00 06 11 38 30
30: 00 00 00 00 80 00 00 00 00 00 00 00 0c 01 00 00
0000:00:04.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
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: 22, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin B routed to IRQ 27
Region 4: I/O ports at fe000820 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 38 30 47 01 10 02 61 00 03 0c 08 16 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 21 08 00 90 00 00 00 00 00 00 00 00 06 11 38 30
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 02 00 00
0000:00:04.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) (prog-if 20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
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: 22, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin C routed to IRQ 29
Region 0: Memory at 800a0400 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 04 31 57 01 10 02 63 20 03 0c 08 16 80 00
10: 00 04 0a 40 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 04 31
30: 00 00 00 00 80 00 00 00 00 00 00 00 1d 03 00 00
> - the content of /proc/interrupts
CPU0
9: 560468 IOP32X Timer Tick
27: 76294 uhci_hcd:usb3, eth0
28: 0 uhci_hcd:usb2
29: 0 ehci_hcd:usb1
Err: 0
> - an ethtool dump of the registers. I don't know if Realtek's driver
> support but it can help even the in-kernel driver
I'm running with the Realtek driver right now which doesn't support
ethtool, and I'm running off NFS root so I can't boot with r8169 for the
moment (-ENOSATADISK.) I'll ask someone else with the same board to do
the test and will post the results.
> > It doesn't seem to be a PHY configuration issue -- with a custom program
> > to dump the MDIO registers (is there any reason r8169 doesn't support
> > mii-tool, by the way? will you take a patch to add that?), we get the
>
> I had written it once, with some rework of the mii functions in the
> driver. It was hit by conflicts generated by various changes as well
> as higher priority bugs/features requests. You can send your code or
> I can resurrect it at your option.
My 'code' is just a userland program that maps /dev/mem and does
essentially this:
static unsigned short phy_read(void *rtl, int reg)
{
volatile unsigned int *phyar;
phyar = (volatile unsigned int *)(rtl + 0x60);
*phyar = reg << 16;
while (!(*phyar & 0x80000000))
;
return *phyar & 0xffff;
}
If you have code for MII already, it would be great if you could merge
that at some point.
> > Just wondering if you've seen this kind of behavior before before I dig
> > into it further? I'm pretty sure the hardware is okay, since r1000 works,
> > and the on-board SATA and UHCI/EHCI USB work fine as well.
>
> I have had a few success reports with the 8110 (and failures too, see
> http://bugzilla.kernel.org/show_bug.cgi?id=5284) but I have not received
> reports for this behavior lately. Complete lack of Rx/Tx activity have
> been observed due to some irq problems. It does not seem to be the issue
> here.
IRQ routing appears to be okay here. The relevant PCI INTx <-> CPU XINTx
pin routing is specified by hand on this platform, see n2100_pci_map_irq()
in the file:
http://svn.wantstofly.org/iop3xx/99-thecus.diff
I'll get back to you about the ethtool dump. Anything else I can do in
the meanwhile?
cheers,
Lennert
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 11:15 ` Lennert Buytenhek
@ 2006-07-28 11:52 ` Martin Michlmayr
2006-07-28 19:49 ` Francois Romieu
2006-07-28 12:28 ` Jamal Hadi Salim
1 sibling, 1 reply; 19+ messages in thread
From: Martin Michlmayr @ 2006-07-28 11:52 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: Francois Romieu, netdev
* Lennert Buytenhek <buytenh@wantstofly.org> [2006-07-28 13:15]:
> > - an ethtool dump of the registers. I don't know if Realtek's
> > driver support but it can help even the in-kernel driver
>
> I'll ask someone else with the same board to do the test and will
> post the results.
Here's the output using the r8169 driver:
RealTek RTL-8110 registers:
------------------------------
0x00: MAC Address 00:14:fd:10:27:74
0x08: Multicast Address Filter 0x00000000 0x00000000
0x10: Dump Tally Counter Command 0xd7bbfec0 0xfb74b6fb
0x20: Tx Normal Priority Ring Addr 0x00000000 0x00000000
0x28: Tx High Priority Ring Addr 0xfffc3f00 0xfef7f6ad
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x00
Rx off, Tx off
0x3C: Interrupt Mask 0x0000
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x10000000
0x44: Rx Configuration 0x00000002
0x48: Timer count 0x95887845
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x00
0x51: Config 0 0x04
0x52: Config 1 0x1f
0x53: Config 2 0x10
0x54: Config 3 0x20
0x55: Config 4 0x80
0x56: Config 5 0x01
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80001000
0x64: TBI control and status 0x00000000
0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x6b
0x84: PM wakeup frame 0 0xbcfeef7f 0xdffffe9f
0x8C: PM wakeup frame 1 0xabf7cf3f 0xfffbdbbf
0x94: PM wakeup frame 2 (low) 0xdfbbfedf 0xbfbffffd
0x9C: PM wakeup frame 2 (high) 0xaa75befc 0xcb5feaf9
0xA4: PM wakeup frame 3 (low) 0xbbdf6fdf 0xff7e75b7
0xAC: PM wakeup frame 3 (high) 0xbbdffbf9 0xfbfcffff
0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbffa7f
0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x32c8bbff
0xC4: Wakeup frame 0 CRC 0x9aff
0xC6: Wakeup frame 1 CRC 0xfdbf
0xC8: Wakeup frame 2 CRC 0xaeff
0xCA: Wakeup frame 3 CRC 0x6bfe
0xCC: Wakeup frame 4 CRC 0xdc2f
0xDA: RX packet maximum size 0x3fff
0xE0: C+ Command 0x2028
RX checksumming
PCI Multiple RW
0xE2: Interrupt Mitigation 0x0000
TxTimer: 0
TxPackets: 0
RxTimer: 0
RxPackets: 0
0xE4: Rx Ring Addr 0x07bd4000 0x00000000
0xEC: Early Tx threshold 0x3f
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 11:15 ` Lennert Buytenhek
2006-07-28 11:52 ` Martin Michlmayr
@ 2006-07-28 12:28 ` Jamal Hadi Salim
1 sibling, 0 replies; 19+ messages in thread
From: Jamal Hadi Salim @ 2006-07-28 12:28 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: Francois Romieu, netdev, tbm
On Fri, 2006-28-07 at 13:15 +0200, Lennert Buytenhek wrote:
> On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote:
>
> > > The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work
> > > initially, but they don't actually seem to transmit any packets on the
> > > wire, nor do they receive any.
> > >
> > > Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC
> > > address for eth1 being incorrect (boot loader bug, being worked on)
> > > there don't seem to be any strange messages or errors.
> >
> > Can you send:
> > - the output of 'lspci -vvx'
>
Since you mention an incorrect MAC address: The one thing that has
bitten me in the past(twice) is misprograming of the eeprom (where
typically the MAC address would sit as well). Vendor in a hurry to put
out the NIC/board forgets to do something at manufacturing time. The
most recent was about 9 months back where the same chip was used in the
board but in one port copper was used and in another hooking up via
serdes. The eeprom claimed both to be copper. It worked for sometime
until you pulled a link and then plugged it back in. A little ethtool
magic to change the device id to match 0x107B
(E1000_DEV_ID_82546GB_SERDES) instead of 0x1079
(E1000_DEV_ID_82546GB_COPPER) fixed it.
cheers,
jamal
PS:- That box looks interesting - priced correctly i may even buy
one ;->
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 11:52 ` Martin Michlmayr
@ 2006-07-28 19:49 ` Francois Romieu
2006-07-28 20:34 ` Martin Michlmayr
0 siblings, 1 reply; 19+ messages in thread
From: Francois Romieu @ 2006-07-28 19:49 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: Lennert Buytenhek, netdev
Martin Michlmayr <tbm@cyrius.com> :
[...]
> Here's the output using the r8169 driver:
>
> RealTek RTL-8110 registers:
> ------------------------------
The (untested) patch below should apply to the source code that Realtek
included in linux-r1000(103).zip, wherence supporting the extraction
of the same info.
--- r1000/src/r1000_ioctl.c 2006-07-28 21:35:25.000000000 +0200
+++ r1000/src/r1000_ioctl.c 2006-07-28 21:38:17.000000000 +0200
@@ -4,6 +4,27 @@ extern int R1000_READ_GMII_REG(unsigned
extern int R1000_WRITE_GMII_REG(unsigned long ioaddr, int RegAddr, int value);
extern int r1000_set_speed_duplex(unsigned long ioaddr, unsigned long anar, unsigned long gbcr, unsigned long bmcr);
+#define R1000_REGS_SIZE 256
+
+static int r1000_get_regs_len(struct net_device *dev)
+{
+ return R1000_REGS_SIZE;
+}
+
+static void r1000_get_regs(struct net_device *dev, struct ethtool_regs *regs,
+ void *p)
+{
+ struct r1000_private *priv = netdev_priv(dev);
+ unsigned long flags;
+
+ if (regs->len > R1000_REGS_SIZE)
+ regs->len = R1000_REGS_SIZE;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ memcpy_fromio(p, (void __iomem *)priv->ioaddr, regs->len);
+ spin_unlock_irqrestore(&priv->lock, flags);
+}
+
static int ethtool_get_settings(struct net_device *netdev,struct ethtool_cmd *ecmd){
struct r1000_private *priv = (struct r1000_private *)(netdev->priv);
unsigned long ioaddr = priv->ioaddr;
@@ -136,6 +157,8 @@ int ethtool_ioctl(struct ifreq *ifr){
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,0)
struct ethtool_ops r1000_ethtool_ops = {
+ .get_regs_len = r1000_get_regs_len,
+ .get_regs = r1000_get_regs,
.get_settings = ethtool_get_settings,
.set_settings = ethtool_set_settings,
};
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 19:49 ` Francois Romieu
@ 2006-07-28 20:34 ` Martin Michlmayr
[not found] ` <20060802180244.GA32235@deprecation.cyrius.com>
0 siblings, 1 reply; 19+ messages in thread
From: Martin Michlmayr @ 2006-07-28 20:34 UTC (permalink / raw)
To: Francois Romieu; +Cc: Lennert Buytenhek, netdev
* Francois Romieu <romieu@fr.zoreil.com> [2006-07-28 21:49]:
> The (untested) patch below should apply to the source code that Realtek
> included in linux-r1000(103).zip, wherence supporting the extraction
> of the same info.
Note quite. I also had to add the patch below but now it's working:
Offset Value
-------- -----
00 0x00
01 0x14
02 0xfd
03 0x10
04 0x27
05 0x74
06 0x00
07 0x00
08 0x00
09 0x00
10 0x00
11 0x80
12 0x00
13 0x00
14 0x00
15 0x00
16 0xc0
17 0xfe
18 0xbb
19 0xdf
20 0x7b
21 0xb6
22 0x74
23 0xff
24 0x00
25 0x00
26 0x00
27 0x00
28 0x00
29 0x00
30 0x00
31 0x00
32 0x00
33 0x80
34 0x20
35 0x07
36 0x00
37 0x00
38 0x00
39 0x00
40 0x00
41 0x3f
42 0xfc
43 0xff
44 0xac
45 0xf7
46 0xf7
47 0xfe
48 0x00
49 0x00
50 0x00
51 0x00
52 0x00
53 0x00
54 0x08
55 0x0c
56 0x00
57 0x00
58 0x00
59 0x00
60 0x7f
61 0x00
62 0x00
63 0x00
64 0x00
65 0x07
66 0x00
67 0x13
68 0x0e
69 0xe7
70 0x00
71 0x00
72 0x24
73 0x57
74 0xaf
75 0x31
76 0x00
77 0x00
78 0x00
79 0x00
80 0x00
81 0x04
82 0x1f
83 0x10
84 0x20
85 0x80
86 0x03
87 0x00
88 0x00
89 0x00
90 0x00
91 0x00
92 0x00
93 0x00
94 0x10
95 0x00
96 0x6d
97 0x79
98 0x01
99 0x80
100 0x00
101 0x00
102 0x00
103 0x00
104 0x00
105 0x00
106 0x00
107 0x00
108 0x6b
109 0x00
110 0x00
111 0x00
112 0xff
113 0xfd
114 0xfb
115 0xff
116 0xfc
117 0x03
118 0x00
119 0x00
120 0x00
121 0xff
122 0xff
123 0xff
124 0x00
125 0x00
126 0x00
127 0x00
128 0x00
129 0x00
130 0x00
131 0x00
132 0x7f
133 0xef
134 0xfe
135 0xfc
136 0x9f
137 0xfe
138 0xff
139 0xdf
140 0x3f
141 0xcf
142 0xf7
143 0xab
144 0xbf
145 0xdb
146 0xfb
147 0xff
148 0xdf
149 0xff
150 0xfa
151 0xdf
152 0xfd
153 0xbf
154 0xbf
155 0xbf
156 0xfc
157 0xbe
158 0x75
159 0xaa
160 0xf9
161 0xea
162 0x5f
163 0xcb
164 0xdf
165 0x6f
166 0xdf
167 0xfb
168 0xb7
169 0x75
170 0x7e
171 0xff
172 0xfd
173 0xfb
174 0xdf
175 0xbb
176 0xff
177 0xff
178 0x7c
179 0xff
180 0x9f
181 0xde
182 0x3b
183 0x7f
184 0x7f
185 0xfa
186 0xbf
187 0xbb
188 0xcd
189 0xfd
190 0x9f
191 0xae
192 0xff
193 0xbb
194 0xc8
195 0x36
196 0xef
197 0xda
198 0xff
199 0xff
200 0xff
201 0xae
202 0xfe
203 0x6a
204 0x2f
205 0xdc
206 0x00
207 0x00
208 0x00
209 0x00
210 0x00
211 0x00
212 0x00
213 0x00
214 0x00
215 0x00
216 0x00
217 0x00
218 0xf2
219 0x05
220 0x00
221 0x00
222 0x00
223 0x00
224 0x08
225 0x20
226 0x00
227 0x00
228 0x00
229 0x00
230 0x79
231 0x07
232 0x00
233 0x00
234 0x00
235 0x00
236 0x3f
237 0x00
238 0x00
239 0x00
240 0x00
241 0x80
242 0x00
243 0x00
244 0x00
245 0x00
246 0x00
247 0x00
248 0x02
249 0x00
250 0x00
251 0x00
252 0x00
253 0x00
254 0x00
255 0x00
--- r1000_ioctl.c~ 2006-07-28 20:32:58.027267250 +0000
+++ r1000_ioctl.c 2006-07-28 20:33:18.600553000 +0000
@@ -6,6 +6,16 @@
#define R1000_REGS_SIZE 256
+static void r1000_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ struct r1000_private *priv = netdev_priv(dev);
+
+ strcpy(info->driver, MODULENAME);
+ strcpy(info->version, R1000_VERSION);
+ strcpy(info->bus_info, pci_name(priv->pci_dev));
+}
+
static int r1000_get_regs_len(struct net_device *dev)
{
return R1000_REGS_SIZE;
@@ -157,6 +167,7 @@
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,0)
struct ethtool_ops r1000_ethtool_ops = {
+ .get_drvinfo = r1000_get_drvinfo,
.get_regs_len = r1000_get_regs_len,
.get_regs = r1000_get_regs,
.get_settings = ethtool_get_settings,
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
[not found] ` <20060802180244.GA32235@deprecation.cyrius.com>
@ 2006-08-02 22:16 ` Francois Romieu
[not found] ` <20060802222623.GA27185@xi.wantstofly.org>
2006-08-03 13:53 ` Martin Michlmayr
0 siblings, 2 replies; 19+ messages in thread
From: Francois Romieu @ 2006-08-02 22:16 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: Lennert Buytenhek, netdev
Martin Michlmayr <tbm@cyrius.com> :
[...]
> Sorry, to pester you, but I was wondering if you had a chance to look
> at the register dump.
No problem. It would have been easier with a decoded output of the register
dump though (see Lennert dump below).
Lines prefixed by '>' come from Realtek's driver. I have outlined the
differences which seem relevant to me.
0x00: MAC Address 00:14:fd:10:27:74
> 00 0x00
> 01 0x14
> 02 0xfd
> 03 0x10
> 04 0x27
> 05 0x74
> 06 0x00
> 07 0x00
0x08: Multicast Address Filter 0x00000000 0x00000000
> 08 0x00
> 09 0x00
> 10 0x00
> 11 0x80
^^
/me scratches head
> 12 0x00
> 13 0x00
> 14 0x00
> 15 0x00
0x10: Dump Tally Counter Command 0xd7bbfec0 0xfb74b6fb
> 16 0xc0
> 17 0xfe
> 18 0xbb
> 19 0xdf
> 20 0x7b
> 21 0xb6
> 22 0x74
> 23 0xff
> 24 0x00
> 25 0x00
> 26 0x00
> 27 0x00
> 28 0x00
> 29 0x00
> 30 0x00
> 31 0x00
0x20: Tx Normal Priority Ring Addr 0x00000000 0x00000000
> 32 0x00
> 33 0x80
> 34 0x20
> 35 0x07
> 36 0x00
> 37 0x00
> 38 0x00
> 39 0x00
0x28: Tx High Priority Ring Addr 0xfffc3f00 0xfef7f6ad
> 40 0x00
> 41 0x3f
> 42 0xfc
> 43 0xff
> 44 0xac
> 45 0xf7
> 46 0xf7
> 47 0xfe
0x30: Flash memory read/write 0x00000000
> 48 0x00
> 49 0x00
> 50 0x00
> 51 0x00
0x34: Early Rx Byte Count 0
> 52 0x00
> 53 0x00
0x36: Early Rx Status 0x00
> 54 0x08
0x37: Command 0x00
Rx off, Tx off
> 55 0x0c
^^ -> CmdRxEnb | CmdTxEnb
If ChipCmd is not set, the driver will hardly work.
Lennert, your dump was taken while the kernel driver was down, right ?
> 56 0x00
> 57 0x00
> 58 0x00
> 59 0x00
0x3C: Interrupt Mask 0x0000
> 60 0x7f
^^
> 61 0x00
RxFIFOOver = 0x40,
LinkChg = 0x20,
RxOverflow = 0x10,
TxErr = 0x08,
TxOK = 0x04,
RxErr = 0x02,
RxOK = 0x01,
0x0000 is typical of rtl8169_irq_mask_and_ack().
The device seems down.
0x3E: Interrupt Status 0x0000
> 62 0x00
> 63 0x00
0x40: Tx Configuration 0x10000000
> 64 0x00
> 65 0x07
^^
Realtek's driver uses an unlimited DMA burst (7) instead
of 1024 (6, see TX_DMA_BURST). Probably harmless.
> 66 0x00
> 67 0x13
0x44: Rx Configuration 0x00000002
> 68 0x0e
^^
These bit should be set by the kernel driver through
rtl8169_set_rx_mode() when the device is brought up
The exact same value would require to replace (in rtl8169_set_rx_mode):
rx_mode = AcceptBroadcast | AcceptMyPhys;
by:
rx_mode = AcceptBroadcast | AcceptMulticast | AcceptMyPhys;
> 69 0xe7
> 70 0x00
> 71 0x00
0x48: Timer count 0x95887845
> 72 0x24
> 73 0x57
> 74 0xaf
> 75 0x31
0x4C: Missed packet counter 0x000000
> 76 0x00
> 77 0x00
> 78 0x00
> 79 0x00
0x50: EEPROM Command 0x00
> 80 0x00
0x51: Config 0 0x04
> 81 0x04
0x52: Config 1 0x1f
> 82 0x1f
0x53: Config 2 0x10
> 83 0x10
0x54: Config 3 0x20
> 84 0x20
0x55: Config 4 0x80
> 85 0x80
0x56: Config 5 0x01
> 86 0x03
> 87 0x00
0x58: Timer interrupt 0x00000000
> 88 0x00
> 89 0x00
> 90 0x00
> 91 0x00
0x5C: Multiple Interrupt Select 0x0000
> 92 0x00
> 93 0x00
> 94 0x10
> 95 0x00
0x60: PHY access 0x80001000
> 96 0x6d
> 97 0x79
> 98 0x01
> 99 0x80
0x64: TBI control and status 0x00000000
> 100 0x00
> 101 0x00
> 102 0x00
> 103 0x00
0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
> 104 0x00
> 105 0x00
0x6A: TBI Link partner ability (LPAR) 0x0000
> 106 0x00
> 107 0x00
0x6C: PHY status 0x6b
> 108 0x6b
> 109 0x00
> 110 0x00
> 111 0x00
> 112 0xff
> 113 0xfd
> 114 0xfb
> 115 0xff
> 116 0xfc
> 117 0x03
> 118 0x00
> 119 0x00
> 120 0x00
> 121 0xff
> 122 0xff
> 123 0xff
> 124 0x00
> 125 0x00
> 126 0x00
> 127 0x00
> 128 0x00
> 129 0x00
> 130 0x00
> 131 0x00
0x84: PM wakeup frame 0 0xbcfeef7f 0xdffffe9f
> 132 0x7f
> 133 0xef
> 134 0xfe
> 135 0xfc
> 136 0x9f
> 137 0xfe
> 138 0xff
> 139 0xdf
0x8C: PM wakeup frame 1 0xabf7cf3f 0xfffbdbbf
> 140 0x3f
> 141 0xcf
> 142 0xf7
> 143 0xab
> 144 0xbf
> 145 0xdb
> 146 0xfb
> 147 0xff
0x94: PM wakeup frame 2 (low) 0xdfbbfedf 0xbfbffffd
> 148 0xdf
> 149 0xff
> 150 0xfa
> 151 0xdf
> 152 0xfd
> 153 0xbf
> 154 0xbf
> 155 0xbf
0x9C: PM wakeup frame 2 (high) 0xaa75befc 0xcb5feaf9
> 156 0xfc
> 157 0xbe
> 158 0x75
> 159 0xaa
> 160 0xf9
> 161 0xea
> 162 0x5f
> 163 0xcb
0xA4: PM wakeup frame 3 (low) 0xbbdf6fdf 0xff7e75b7
> 164 0xdf
> 165 0x6f
> 166 0xdf
> 167 0xfb
> 168 0xb7
> 169 0x75
> 170 0x7e
> 171 0xff
0xAC: PM wakeup frame 3 (high) 0xbbdffbf9 0xfbfcffff
> 172 0xfd
> 173 0xfb
> 174 0xdf
> 175 0xbb
> 176 0xff
> 177 0xff
> 178 0x7c
> 179 0xff
0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbffa7f
> 180 0x9f
> 181 0xde
> 182 0x3b
> 183 0x7f
> 184 0x7f
> 185 0xfa
> 186 0xbf
> 187 0xbb
0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x32c8bbff
> 188 0xcd
> 189 0xfd
> 190 0x9f
> 191 0xae
> 192 0xff
> 193 0xbb
> 194 0xc8
> 195 0x36
0xC4: Wakeup frame 0 CRC 0x9aff
> 196 0xef
> 197 0xda
0xC6: Wakeup frame 1 CRC 0xfdbf
> 198 0xff
> 199 0xff
0xC8: Wakeup frame 2 CRC 0xaeff
> 200 0xff
> 201 0xae
0xCA: Wakeup frame 3 CRC 0x6bfe
> 202 0xfe
> 203 0x6a
0xCC: Wakeup frame 4 CRC 0xdc2f
> 204 0x2f
> 205 0xdc
> 206 0x00
> 207 0x00
> 208 0x00
> 209 0x00
> 210 0x00
> 211 0x00
> 212 0x00
> 213 0x00
> 214 0x00
> 215 0x00
> 216 0x00
> 217 0x00
0xDA: RX packet maximum size 0x3fff
> 218 0xf2
^^
> 219 0x05
^^
Probably harmless: 1522 bytes max instead of max jumbo.
> 220 0x00
> 221 0x00
> 222 0x00
> 223 0x00
0xE0: C+ Command 0x2028
RX checksumming
PCI Multiple RW
> 224 0x08
Rx checksum is disabled in Realtek's driver. Probably harmless.
> 225 0x20
0xE2: Interrupt Mitigation 0x0000
TxTimer: 0
TxPackets: 0
RxTimer: 0
RxPackets: 0
> 226 0x00
> 227 0x00
0xE4: Rx Ring Addr 0x07bd4000 0x00000000
> 228 0x00
> 229 0x00
> 230 0x79
> 231 0x07
> 232 0x00
> 233 0x00
> 234 0x00
> 235 0x00
0xEC: Early Tx threshold 0x3f
> 236 0x3f
> 237 0x00
> 238 0x00
> 239 0x00
> 240 0x00
> 241 0x80
> 242 0x00
> 243 0x00
> 244 0x00
> 245 0x00
> 246 0x00
> 247 0x00
> 248 0x02
> 249 0x00
> 250 0x00
> 251 0x00
> 252 0x00
> 253 0x00
> 254 0x00
> 255 0x00
--
Ueimor
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
[not found] ` <20060803081023.GA7502@electric-eye.fr.zoreil.com>
@ 2006-08-03 10:31 ` Martin Michlmayr
0 siblings, 0 replies; 19+ messages in thread
From: Martin Michlmayr @ 2006-08-03 10:31 UTC (permalink / raw)
To: Francois Romieu; +Cc: Lennert Buytenhek, netdev
* Francois Romieu <romieu@fr.zoreil.com> [2006-08-03 10:10]:
> If so I would welcome the same dump that Martin sent on 2006/07/28 (
> Message-ID: <20060728115237.GF21733@deprecation.cyrius.com>) applied to
> the kernel r8169 driver after it has been ifconfiged up.
I'm not sure what the state of the interface was last time, but this
time I made sure it was up - however, it doesn't make any difference:
ChipCmd is still not set. Any idea?
dhcppc3:~# ifconfig | head -2
eth0 Link encap:Ethernet HWaddr 00:14:FD:10:27:74
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
RealTek RTL-8110 registers:
------------------------------
0x00: MAC Address 00:14:fd:10:27:74
0x08: Multicast Address Filter 0x00000000 0x00000000
0x10: Dump Tally Counter Command 0xd7bbfac0 0xf754b27b
0x20: Tx Normal Priority Ring Addr 0x00000000 0x00000000
0x28: Tx High Priority Ring Addr 0xeffc2f00 0x7ef5f68c
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x00
Rx off, Tx off
0x3C: Interrupt Mask 0x0000
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x10000000
0x44: Rx Configuration 0x00000002
0x48: Timer count 0x1c7c67d2
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x00
0x51: Config 0 0x04
0x52: Config 1 0x1f
0x53: Config 2 0x10
0x54: Config 3 0x20
0x55: Config 4 0x80
0x56: Config 5 0x01
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80001000
0x64: TBI control and status 0x00000000
0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x0b
0x84: PM wakeup frame 0 0xbcfa6f7f 0xd7fffe8f
0x8C: PM wakeup frame 1 0xa3f6cb3f 0xff7bdbbd
0x94: PM wakeup frame 2 (low) 0xdfbaefd7 0xbdbfbffd
0x9C: PM wakeup frame 2 (high) 0xaa71befc 0xc35aeab9
0xA4: PM wakeup frame 3 (low) 0xbbdf67df 0xf77e65b3
0xAC: PM wakeup frame 3 (high) 0xbbdef9b1 0xff7c7fff
0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbefa7c
0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x36c8bbff
0xC4: Wakeup frame 0 CRC 0xdaaf
0xC6: Wakeup frame 1 CRC 0xffbf
0xC8: Wakeup frame 2 CRC 0xaebf
0xCA: Wakeup frame 3 CRC 0x2ffe
0xCC: Wakeup frame 4 CRC 0xdc23
0xDA: RX packet maximum size 0x3fff
0xE0: C+ Command 0x2028
RX checksumming
PCI Multiple RW
0xE2: Interrupt Mitigation 0x0000
TxTimer: 0
TxPackets: 0
RxTimer: 0
RxPackets: 0
0xE4: Rx Ring Addr 0x07422000 0x00000000
0xEC: Early Tx threshold 0x3f
diff to the output from last time doesn't show any significant
changes:
--- r1 2006-08-03 12:24:07.000000000 +0200
+++ r2 2006-08-03 12:26:29.000000000 +0200
@@ -2,9 +2,9 @@
------------------------------
0x00: MAC Address 00:14:fd:10:27:74
0x08: Multicast Address Filter 0x00000000 0x00000000
-0x10: Dump Tally Counter Command 0xd7bbfec0 0xfb74b6fb
+0x10: Dump Tally Counter Command 0xd7bbfac0 0xf754b27b
0x20: Tx Normal Priority Ring Addr 0x00000000 0x00000000
-0x28: Tx High Priority Ring Addr 0xfffc3f00 0xfef7f6ad
+0x28: Tx High Priority Ring Addr 0xeffc2f00 0x7ef5f68c
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
@@ -16,7 +16,7 @@
0x40: Tx Configuration 0x10000000
0x44: Rx Configuration 0x00000002
-0x48: Timer count 0x95887845
+0x48: Timer count 0x1c7c67d2
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x00
0x51: Config 0 0x04
@@ -31,20 +31,20 @@
0x64: TBI control and status 0x00000000
0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
0x6A: TBI Link partner ability (LPAR) 0x0000
-0x6C: PHY status 0x6b
-0x84: PM wakeup frame 0 0xbcfeef7f 0xdffffe9f
-0x8C: PM wakeup frame 1 0xabf7cf3f 0xfffbdbbf
-0x94: PM wakeup frame 2 (low) 0xdfbbfedf 0xbfbffffd
-0x9C: PM wakeup frame 2 (high) 0xaa75befc 0xcb5feaf9
-0xA4: PM wakeup frame 3 (low) 0xbbdf6fdf 0xff7e75b7
-0xAC: PM wakeup frame 3 (high) 0xbbdffbf9 0xfbfcffff
-0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbffa7f
-0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x32c8bbff
-0xC4: Wakeup frame 0 CRC 0x9aff
-0xC6: Wakeup frame 1 CRC 0xfdbf
-0xC8: Wakeup frame 2 CRC 0xaeff
-0xCA: Wakeup frame 3 CRC 0x6bfe
-0xCC: Wakeup frame 4 CRC 0xdc2f
+0x6C: PHY status 0x0b
+0x84: PM wakeup frame 0 0xbcfa6f7f 0xd7fffe8f
+0x8C: PM wakeup frame 1 0xa3f6cb3f 0xff7bdbbd
+0x94: PM wakeup frame 2 (low) 0xdfbaefd7 0xbdbfbffd
+0x9C: PM wakeup frame 2 (high) 0xaa71befc 0xc35aeab9
+0xA4: PM wakeup frame 3 (low) 0xbbdf67df 0xf77e65b3
+0xAC: PM wakeup frame 3 (high) 0xbbdef9b1 0xff7c7fff
+0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbefa7c
+0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x36c8bbff
+0xC4: Wakeup frame 0 CRC 0xdaaf
+0xC6: Wakeup frame 1 CRC 0xffbf
+0xC8: Wakeup frame 2 CRC 0xaebf
+0xCA: Wakeup frame 3 CRC 0x2ffe
+0xCC: Wakeup frame 4 CRC 0xdc23
0xDA: RX packet maximum size 0x3fff
0xE0: C+ Command 0x2028
RX checksumming
@@ -54,5 +54,5 @@
TxPackets: 0
RxTimer: 0
RxPackets: 0
-0xE4: Rx Ring Addr 0x07bd4000 0x00000000
+0xE4: Rx Ring Addr 0x07422000 0x00000000
0xEC: Early Tx threshold 0x3f
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-08-02 22:16 ` Francois Romieu
[not found] ` <20060802222623.GA27185@xi.wantstofly.org>
@ 2006-08-03 13:53 ` Martin Michlmayr
[not found] ` <20060803142309.GA17166@deprecation.cyrius.com>
1 sibling, 1 reply; 19+ messages in thread
From: Martin Michlmayr @ 2006-08-03 13:53 UTC (permalink / raw)
To: Francois Romieu; +Cc: Lennert Buytenhek, netdev
* Francois Romieu <romieu@fr.zoreil.com> [2006-08-03 00:16]:
> 0x37: Command 0x00
> Rx off, Tx off
> > 55 0x0c
> ^^ -> CmdRxEnb | CmdTxEnb
>
> If ChipCmd is not set, the driver will hardly work.
I put in a printk and ChipCmd is definitely being set but when I query
it with ethtool later it is 0x00. What might reset it?
CmdTxEnb: 0x4
CmdTxEnb: 0x8
ChipCmd (before): 0x0
ChipCmd (after): 0xc
r8169: eth0: link up
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
[not found] ` <20060803150556.GA9433@electric-eye.fr.zoreil.com>
@ 2006-08-03 15:48 ` Martin Michlmayr
2006-08-03 16:21 ` Martin Michlmayr
1 sibling, 0 replies; 19+ messages in thread
From: Martin Michlmayr @ 2006-08-03 15:48 UTC (permalink / raw)
To: Francois Romieu; +Cc: Lennert Buytenhek, netdev
* Francois Romieu <romieu@fr.zoreil.com> [2006-08-03 17:05]:
> > >From 192.168.1.2 icmp_seq=62 Destination Host Unreachable
> > >From 192.168.1.2 icmp_seq=63 Destination Host Unreachable
> > NETDEV WATCHDOG: eth0: transmit timed out
> > CmdTxEnb: 0x4
> > CmdTxEnb: 0x8
> > ChipCmd (before): 0x0
> > ChipCmd (after): 0xc
> > trying again...
> > ChipCmd: 0xc
> > >From 192.168.1.2 icmp_seq=64 Destination Host Unreachable
> > >From 192.168.1.2 icmp_seq=65 Destination Host Unreachable
> > >From 192.168.1.2 icmp_seq=66 Destination Host Unreachable
>
> Did you take the dump right after 'ifconfig ... up' ? Otherwise, the
> watchdog may quickly come into play.
Oh, yes, when I do
ifup eth0 ; ethtool -d eth0
I get better results.
RealTek RTL-8110 registers:
------------------------------
0x00: MAC Address 00:14:fd:10:27:74
0x08: Multicast Address Filter 0x00000000 0x00000000
0x10: Dump Tally Counter Command 0xdfbbfac0 0xff74b67b
0x20: Tx Normal Priority Ring Addr 0x00000000 0x00000000
0x28: Tx High Priority Ring Addr 0xeffc2b00 0x7ef5f6ac
0x30: Flash memory read/write 0x00000000
0x34: Early Rx Byte Count 0
0x36: Early Rx Status 0x00
0x37: Command 0x0c
Rx on, Tx on
0x3C: Interrupt Mask 0x807f
SERR RxFIFO LinkChg RxNoBuf TxErr TxOK RxErr RxOK
0x3E: Interrupt Status 0x0000
0x40: Tx Configuration 0x13000600
0x44: Rx Configuration 0x0000e60e
0x48: Timer count 0x00630fd8
0x4C: Missed packet counter 0x000000
0x50: EEPROM Command 0x00
0x51: Config 0 0x04
0x52: Config 1 0x1f
0x53: Config 2 0x10
0x54: Config 3 0x20
0x55: Config 4 0x80
0x56: Config 5 0x01
0x58: Timer interrupt 0x00000000
0x5C: Multiple Interrupt Select 0x0000
0x60: PHY access 0x80001000
0x64: TBI control and status 0x00000000
0x68: TBI Autonegotiation advertisement (ANAR) 0x0000
0x6A: TBI Link partner ability (LPAR) 0x0000
0x6C: PHY status 0x0b
0x84: PM wakeup frame 0 0xbcfe6f7f 0xdffffe8f
0x8C: PM wakeup frame 1 0xabf6cb3f 0xff7bdbbd
0x94: PM wakeup frame 2 (low) 0xdfbaeed7 0xbdbfbffd
0x9C: PM wakeup frame 2 (high) 0xaa75befc 0xcb5feab9
0xA4: PM wakeup frame 3 (low) 0xbbdf67df 0xff7e65b3
0xAC: PM wakeup frame 3 (high) 0xbbdffbb1 0xff7c7fff
0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbffa7d
0xBC: PM wakeup frame 4 (high) 0x2e9ffdcd 0x36c8bbff
0xC4: Wakeup frame 0 CRC 0x9abf
0xC6: Wakeup frame 1 CRC 0xffbf
0xC8: Wakeup frame 2 CRC 0xaebf
0xCA: Wakeup frame 3 CRC 0x2ffe
0xCC: Wakeup frame 4 CRC 0xdc23
0xDA: RX packet maximum size 0x3fff
0xE0: C+ Command 0x2028
RX checksumming
PCI Multiple RW
0xE2: Interrupt Mitigation 0x0000
TxTimer: 0
TxPackets: 0
RxTimer: 0
RxPackets: 0
0xE4: Rx Ring Addr 0x06ff1000 0x00000000
0xEC: Early Tx threshold 0x3f
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
[not found] ` <20060803150556.GA9433@electric-eye.fr.zoreil.com>
2006-08-03 15:48 ` Martin Michlmayr
@ 2006-08-03 16:21 ` Martin Michlmayr
1 sibling, 0 replies; 19+ messages in thread
From: Martin Michlmayr @ 2006-08-03 16:21 UTC (permalink / raw)
To: Francois Romieu; +Cc: Lennert Buytenhek, netdev
* Francois Romieu <romieu@fr.zoreil.com> [2006-08-03 17:05]:
> Btw, can you pass the module a 'debug=32767' option when it is loaded to
> increase its verbosity.
That doesn't give me much more messages but now I get one error
message that is probably significant:
eth0: PCI error (cmd = 0x0157, status = 0x6238).
Full log:
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
mac_version == Unknown
phy_version == RTL_GIGA_PHY_VER_D (0000)
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: RTL8169 at 0xc885e200, 00:14:fd:10:27:74, IRQ 27
mac_version == Unknown
phy_version == RTL_GIGA_PHY_VER_D (0000)
MAC version != 0 && PHY version == 0 or 1
Do final_reg2.cfg
Set MAC Reg C+CR Offset 0x82h = 0x01h
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
mac_version == Unknown
phy_version == RTL_GIGA_PHY_VER_D (0000)
eth1: Identified chip type is 'RTL8169s/8110s'.
eth1: RTL8169 at 0xc8860300, 00:14:fd:10:00:00, IRQ 28
mac_version == Unknown
phy_version == RTL_GIGA_PHY_VER_D (0000)
MAC version != 0 && PHY version == 0 or 1
Do final_reg2.cfg
Set MAC Reg C+CR Offset 0x82h = 0x01h
libata version 1.20 loaded.
...
Freeing init memory: 88K
Adding 506008k swap on /dev/sda5. Priority:-1 extents:1
across:506008k
EXT3 FS on sda3, internal journal
r8169: eth0: link up
eth0: PCI error (cmd = 0x0157, status = 0x6238).
NETDEV WATCHDOG: eth0: transmit timed out
eth0: PCI error (cmd = 0x0157, status = 0x6238).
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-07-28 10:11 r8169 driver problem with RTL8110SB chip (on iop3xx ARM board) Lennert Buytenhek
2006-07-28 10:49 ` Francois Romieu
@ 2006-08-18 21:28 ` Lennert Buytenhek
2006-08-20 21:35 ` Francois Romieu
1 sibling, 1 reply; 19+ messages in thread
From: Lennert Buytenhek @ 2006-08-18 21:28 UTC (permalink / raw)
To: romieu; +Cc: netdev, tbm
On Fri, Jul 28, 2006 at 12:11:09PM +0200, Lennert Buytenhek wrote:
> We're currently working on getting the Thecus n2100 supported in 2.6.
>
> http://www.thecus.com/products_over.php?cid=1&pid=1
>
> Amongst other nice goodies, it has two on-board RTL8110SB gigabit
> controllers. The realtek-supplied 'r1000' driver kind of sort of works,
> if you don't mind the machine hanging or crashing if you unplug the cable
> at the wrong moment.
>
> The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work
> initially, but they don't actually seem to transmit any packets on the
> wire, nor do they receive any.
The hack patch below makes it work. There's two issues here:
1. Writing zero to the upper part of the TxDescStartAddr register (via
the MMIO region) somehow also clears the lower part, and writing the
upper and lower halves the other way round fixes it. The RxDescAddr
register doesn't seem to suffer from this problem.
The Realtek r1000 driver writes the two halves in the same order as
r8169, but it doesn't happen there, which is a bit of a mystery to
me.
2. SYSErr asserts pretty soon after upping eth0, and the PCI status
register reports a parity error when this happens. In this case,
the restart logic seems to make things worse, and in fact, when
commenting it out, things work a lot better.
Have you ever seen these issues before? Any suggestions on how to
cleanly fix these issues?
cheers,
Lennert
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Index: linux-2.6.18-rc2/drivers/net/r8169.c
===================================================================
--- linux-2.6.18-rc2.orig/drivers/net/r8169.c
+++ linux-2.6.18-rc2/drivers/net/r8169.c
@@ -484,7 +488,7 @@ static int rtl8169_poll(struct net_devic
#endif
static const u16 rtl8169_intr_mask =
- SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
+ LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
static const u16 rtl8169_napi_event =
RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr;
static const unsigned int rtl8169_rx_config =
@@ -1825,8 +1829,8 @@ rtl8169_hw_start(struct net_device *dev)
*/
RTL_W16(IntrMitigate, 0x0000);
- RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK));
RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32));
+ RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK));
RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK));
RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32));
RTL_W8(Cfg9346, Cfg9346_Lock);
@@ -2527,10 +2531,12 @@ rtl8169_interrupt(int irq, void *dev_ins
if (!(status & rtl8169_intr_mask))
break;
+#if 0
if (unlikely(status & SYSErr)) {
rtl8169_pcierr_interrupt(dev);
break;
}
+#endif
if (status & LinkChg)
rtl8169_check_link_status(dev, tp, ioaddr);
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-08-18 21:28 ` [PATCH,RFC] " Lennert Buytenhek
@ 2006-08-20 21:35 ` Francois Romieu
2006-09-04 22:07 ` Lennert Buytenhek
2006-09-04 22:27 ` Lennert Buytenhek
0 siblings, 2 replies; 19+ messages in thread
From: Francois Romieu @ 2006-08-20 21:35 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, tbm
Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> The hack patch below makes it work. There's two issues here:
>
> 1. Writing zero to the upper part of the TxDescStartAddr register (via
> the MMIO region) somehow also clears the lower part, and writing the
> upper and lower halves the other way round fixes it. The RxDescAddr
> register doesn't seem to suffer from this problem.
>
> The Realtek r1000 driver writes the two halves in the same order as
> r8169, but it doesn't happen there, which is a bit of a mystery to
> me.
>
> 2. SYSErr asserts pretty soon after upping eth0, and the PCI status
> register reports a parity error when this happens. In this case,
> the restart logic seems to make things worse, and in fact, when
> commenting it out, things work a lot better.
>
> Have you ever seen these issues before? Any suggestions on how to
> cleanly fix these issues?
1 - unknown so far. Realtek's driver actually use IO, not MM. I do not see
why it would make a difference as long as posteed writes are correctly
taken care of.
2 - I have already experienced SYSErr storms on startup. If memory serves me
right, they were "cured" simply by disabling a bit in the irq mask
(not sure if it was SYSErr, RxOverflow or RxFIFOOver though).
Can you try against -rc4:
1) the serie at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc4/r8169
There is a minor difference in the init of Realtek's driver for the 8110sb
(patch 011). It could hurt different chipset but it should do no harm to
the 8110sb.
2) same as 1) + your hunk below:
@@ -484,7 +488,7 @@ static int rtl8169_poll(struct net_devic
#endif
static const u16 rtl8169_intr_mask =
- SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
+ LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
static const u16 rtl8169_napi_event =
RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr;
static const unsigned int rtl8169_rx_config =
3) same as 2) + your TxDesc change.
If it does not break anything else, I'll push your magic. I'd rather avoid
completely disabling rtl8169_pcierr_interrupt() though.
--
Ueimor
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-08-20 21:35 ` Francois Romieu
@ 2006-09-04 22:07 ` Lennert Buytenhek
2006-09-08 20:23 ` Francois Romieu
2006-09-04 22:27 ` Lennert Buytenhek
1 sibling, 1 reply; 19+ messages in thread
From: Lennert Buytenhek @ 2006-09-04 22:07 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, tbm
On Sun, Aug 20, 2006 at 11:35:58PM +0200, Francois Romieu wrote:
> > 1. Writing zero to the upper part of the TxDescStartAddr register (via
> > the MMIO region) somehow also clears the lower part, and writing the
> > upper and lower halves the other way round fixes it. The RxDescAddr
> > register doesn't seem to suffer from this problem.
> >
> > The Realtek r1000 driver writes the two halves in the same order as
> > r8169, but it doesn't happen there, which is a bit of a mystery to
> > me.
> >
> > [snip]
>
> 1 - unknown so far. Realtek's driver actually use IO, not MM. I do not see
> why it would make a difference as long as posteed writes are correctly
> taken care of.
I suspect it's a chip bug. I rechecked with I/O space, and that works
okay, so this artifact (bug) only manifests itself when you do the upper
write in MMIO space.
Are there any plans to switch r8169 to the iomap API? Would you take
a patch if I'd write one?
cheers,
Lennert
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-08-20 21:35 ` Francois Romieu
2006-09-04 22:07 ` Lennert Buytenhek
@ 2006-09-04 22:27 ` Lennert Buytenhek
2006-09-08 20:38 ` Francois Romieu
1 sibling, 1 reply; 19+ messages in thread
From: Lennert Buytenhek @ 2006-09-04 22:27 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, tbm
On Sun, Aug 20, 2006 at 11:35:58PM +0200, Francois Romieu wrote:
> > 2. SYSErr asserts pretty soon after upping eth0, and the PCI status
> > register reports a parity error when this happens. In this case,
> > the restart logic seems to make things worse, and in fact, when
> > commenting it out, things work a lot better.
>
> [snip]
>
> 2 - I have already experienced SYSErr storms on startup. If memory serves me
> right, they were "cured" simply by disabling a bit in the irq mask
> (not sure if it was SYSErr, RxOverflow or RxFIFOOver though).
>
> Can you try against -rc4:
> 1) the serie at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc4/r8169
> There is a minor difference in the init of Realtek's driver for the 8110sb
> (patch 011). It could hurt different chipset but it should do no harm to
> the 8110sb.
> 2) same as 1) + your hunk below:
> @@ -484,7 +488,7 @@ static int rtl8169_poll(struct net_devic
> #endif
>
> static const u16 rtl8169_intr_mask =
> - SYSErr | LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
> + LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK;
> static const u16 rtl8169_napi_event =
> RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr;
> static const unsigned int rtl8169_rx_config =
> 3) same as 2) + your TxDesc change.
I tried your series from step (1) plus my TxDesc change (so I didn't
include the hunk from (2)), and that seems to work fine. I.e. I don't
need to disable error interrupts anymore to keep it working.
So really the only thing that would need addressing would be the TXDesc
MMIO bug (either by using I/O accesses, or doing the top/bottom writes
the other way round) and we can dump the vendor driver.
Thanks a lot!
cheers,
Lennert
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-09-04 22:07 ` Lennert Buytenhek
@ 2006-09-08 20:23 ` Francois Romieu
2006-09-08 21:37 ` Lennert Buytenhek
0 siblings, 1 reply; 19+ messages in thread
From: Francois Romieu @ 2006-09-08 20:23 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, tbm
Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> I suspect it's a chip bug. I rechecked with I/O space, and that works
> okay, so this artifact (bug) only manifests itself when you do the upper
> write in MMIO space.
>
> Are there any plans to switch r8169 to the iomap API? Would you take
> a patch if I'd write one?
Given the current state of the r8169 driver, I do not see a lot of
benefit from the iomap() API in itself.
It could make the switch to I/O read/write easier for strange bugs
like your but I have an epidermic defiance against I/O ops (much too
synchronizing for me: people forget that MMIO will post). I may
change my mind if bugs start poping up like mushrooms but we are
hopefully not there yet.
An ordered write with a big sign in front of it to comment the issue
is good enough for me.
Don't hesitate to protest if you think that I need a clue.
--
Ueimor
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-09-04 22:27 ` Lennert Buytenhek
@ 2006-09-08 20:38 ` Francois Romieu
0 siblings, 0 replies; 19+ messages in thread
From: Francois Romieu @ 2006-09-08 20:38 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, tbm
Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> I tried your series from step (1) plus my TxDesc change (so I didn't
> include the hunk from (2)), and that seems to work fine. I.e. I don't
> need to disable error interrupts anymore to keep it working.
>
> So really the only thing that would need addressing would be the TXDesc
> MMIO bug (either by using I/O accesses, or doing the top/bottom writes
> the other way round) and we can dump the vendor driver.
I'll turn the top/bottom write the other way around for it looks
like the less intrusive option so far.
The current r8169 serie stood long enough in -mm that I can ask Jeff
to pull it. The link management of the 8136 needs more work but it is
not a showstopper.
--
Ueimor
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH,RFC] Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
2006-09-08 20:23 ` Francois Romieu
@ 2006-09-08 21:37 ` Lennert Buytenhek
0 siblings, 0 replies; 19+ messages in thread
From: Lennert Buytenhek @ 2006-09-08 21:37 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, tbm
On Fri, Sep 08, 2006 at 10:23:36PM +0200, Francois Romieu wrote:
> > I suspect it's a chip bug. I rechecked with I/O space, and that
> > works okay, so this artifact (bug) only manifests itself when you
> > do the upper write in MMIO space.
> >
> > Are there any plans to switch r8169 to the iomap API? Would you
> > take a patch if I'd write one?
>
> Given the current state of the r8169 driver, I do not see a lot of
> benefit from the iomap() API in itself.
>
> It could make the switch to I/O read/write easier for strange bugs
> like your but I have an epidermic defiance against I/O ops (much too
> synchronizing for me: people forget that MMIO will post). I may
> change my mind if bugs start poping up like mushrooms but we are
> hopefully not there yet.
>
> An ordered write with a big sign in front of it to comment the issue
> is good enough for me.
>
> Don't hesitate to protest if you think that I need a clue.
What you say makes sense -- in my case it would have been useful to
have a knob to switch the driver to use I/O ops (since that is what
the vendor driver uses, and the vendor driver works), but bugs like
these are generally rare anyway. and so the added benefit isn't too
big. OK.
cheers,
Lennert
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2006-09-08 21:37 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-28 10:11 r8169 driver problem with RTL8110SB chip (on iop3xx ARM board) Lennert Buytenhek
2006-07-28 10:49 ` Francois Romieu
2006-07-28 11:15 ` Lennert Buytenhek
2006-07-28 11:52 ` Martin Michlmayr
2006-07-28 19:49 ` Francois Romieu
2006-07-28 20:34 ` Martin Michlmayr
[not found] ` <20060802180244.GA32235@deprecation.cyrius.com>
2006-08-02 22:16 ` Francois Romieu
[not found] ` <20060802222623.GA27185@xi.wantstofly.org>
[not found] ` <20060803081023.GA7502@electric-eye.fr.zoreil.com>
2006-08-03 10:31 ` Martin Michlmayr
2006-08-03 13:53 ` Martin Michlmayr
[not found] ` <20060803142309.GA17166@deprecation.cyrius.com>
[not found] ` <20060803150556.GA9433@electric-eye.fr.zoreil.com>
2006-08-03 15:48 ` Martin Michlmayr
2006-08-03 16:21 ` Martin Michlmayr
2006-07-28 12:28 ` Jamal Hadi Salim
2006-08-18 21:28 ` [PATCH,RFC] " Lennert Buytenhek
2006-08-20 21:35 ` Francois Romieu
2006-09-04 22:07 ` Lennert Buytenhek
2006-09-08 20:23 ` Francois Romieu
2006-09-08 21:37 ` Lennert Buytenhek
2006-09-04 22:27 ` Lennert Buytenhek
2006-09-08 20:38 ` Francois Romieu
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).