* 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: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)
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
* [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-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-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
* 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: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
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).