* Realtek 8111C transmit timed out
@ 2008-08-05 1:12 John P Poet
2008-08-05 2:00 ` John P Poet
0 siblings, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-05 1:12 UTC (permalink / raw)
To: netdev
I recently bought a new motherboard with Realtek 8111C nics. The nic
is detected as:
dmesg:
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:06:00.0 to 64
eth0: RTL8168c/8111c at 0xffffc2000063e000, 00:1f:d0:20:01:57, XID
3c4000c0 IRQ 2292
lspci -v:
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: Giga-byte Technology Unknown device e000
Flags: bus master, fast devsel, latency 0, IRQ 2292
I/O ports at b000 [size=256]
Memory at de010000 (64-bit, prefetchable) [size=4K]
Memory at de000000 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at de020000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
Capabilities: [d0] Vital Product Data <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 78-56-34-12-78-56-34-12
Kernel driver in use: r8169
Kernel modules: r8169
I have been having two problems with this nic:
1) On a cold boot, the nic is not brought up correctly. It seems to
stay at 100mbit instead of going into gbit mode, and it fails to ping
the router even though it seems to get a valid IP address. If I then
warm boot the computer, then then nic comes up in gbit just fine, and
generally works.
2) I am getting a lot of timeouts:
Aug 4 17:49:35 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 4 17:49:35 saphire kernel: r8169: eth0: link up
Aug 4 17:50:05 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 4 17:50:05 saphire kernel: r8169: eth0: link up
...
Aug 4 18:52:17 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 4 18:52:17 saphire kernel: r8169: eth0: link up
...
Aug 4 18:55:59 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 4 18:55:59 saphire kernel: r8169: eth0: link up
...
Aug 4 18:57:47 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 4 18:57:47 saphire kernel: r8169: eth0: link up
While the booting problem is annoying, the timeouts are actually even
more so. I am a mythtv users, and those timeouts cause my video/audio
streaming to fail.
Is there anything I can do about these problems?
Thank you,
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-05 1:12 Realtek 8111C transmit timed out John P Poet
@ 2008-08-05 2:00 ` John P Poet
2008-08-05 3:42 ` John P Poet
0 siblings, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-05 2:00 UTC (permalink / raw)
To: netdev
On Mon, Aug 4, 2008 at 7:12 PM, John P Poet <jppoet@gmail.com> wrote:
> I recently bought a new motherboard with Realtek 8111C nics. The nic
> is detected as:
>
> dmesg:
> r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
> ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 18 (level, low) -> IRQ 18
> PCI: Setting latency timer of device 0000:06:00.0 to 64
> eth0: RTL8168c/8111c at 0xffffc2000063e000, 00:1f:d0:20:01:57, XID
> 3c4000c0 IRQ 2292
>
> lspci -v:
> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
> Subsystem: Giga-byte Technology Unknown device e000
> Flags: bus master, fast devsel, latency 0, IRQ 2292
> I/O ports at b000 [size=256]
> Memory at de010000 (64-bit, prefetchable) [size=4K]
> Memory at de000000 (64-bit, prefetchable) [size=64K]
> [virtual] Expansion ROM at de020000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/1 Enable+
> Capabilities: [70] Express Endpoint, MSI 01
> Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
> Capabilities: [d0] Vital Product Data <?>
> Capabilities: [100] Advanced Error Reporting <?>
> Capabilities: [140] Virtual Channel <?>
> Capabilities: [160] Device Serial Number 78-56-34-12-78-56-34-12
> Kernel driver in use: r8169
> Kernel modules: r8169
>
> I have been having two problems with this nic:
>
> 1) On a cold boot, the nic is not brought up correctly. It seems to
> stay at 100mbit instead of going into gbit mode, and it fails to ping
> the router even though it seems to get a valid IP address. If I then
> warm boot the computer, then then nic comes up in gbit just fine, and
> generally works.
>
> 2) I am getting a lot of timeouts:
>
> Aug 4 17:49:35 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 4 17:49:35 saphire kernel: r8169: eth0: link up
> Aug 4 17:50:05 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 4 17:50:05 saphire kernel: r8169: eth0: link up
> ...
> Aug 4 18:52:17 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 4 18:52:17 saphire kernel: r8169: eth0: link up
> ...
> Aug 4 18:55:59 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 4 18:55:59 saphire kernel: r8169: eth0: link up
> ...
> Aug 4 18:57:47 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 4 18:57:47 saphire kernel: r8169: eth0: link up
>
> While the booting problem is annoying, the timeouts are actually even
> more so. I am a mythtv users, and those timeouts cause my video/audio
> streaming to fail.
>
> Is there anything I can do about these problems?
I probably should have mentioned that I am running the 2.6.26 kernel.
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-05 2:00 ` John P Poet
@ 2008-08-05 3:42 ` John P Poet
2008-08-05 21:42 ` Francois Romieu
0 siblings, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-05 3:42 UTC (permalink / raw)
To: netdev
On Mon, Aug 4, 2008 at 8:00 PM, John P Poet <jppoet@gmail.com> wrote:
> On Mon, Aug 4, 2008 at 7:12 PM, John P Poet <jppoet@gmail.com> wrote:
>> I recently bought a new motherboard with Realtek 8111C nics. The nic
>> is detected as:
>>
>> dmesg:
>> r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
>> ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 18 (level, low) -> IRQ 18
>> PCI: Setting latency timer of device 0000:06:00.0 to 64
>> eth0: RTL8168c/8111c at 0xffffc2000063e000, 00:1f:d0:20:01:57, XID
>> 3c4000c0 IRQ 2292
>>
>> lspci -v:
>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
>> Subsystem: Giga-byte Technology Unknown device e000
>> Flags: bus master, fast devsel, latency 0, IRQ 2292
>> I/O ports at b000 [size=256]
>> Memory at de010000 (64-bit, prefetchable) [size=4K]
>> Memory at de000000 (64-bit, prefetchable) [size=64K]
>> [virtual] Expansion ROM at de020000 [disabled] [size=64K]
>> Capabilities: [40] Power Management version 3
>> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
>> Queue=0/1 Enable+
>> Capabilities: [70] Express Endpoint, MSI 01
>> Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
>> Capabilities: [d0] Vital Product Data <?>
>> Capabilities: [100] Advanced Error Reporting <?>
>> Capabilities: [140] Virtual Channel <?>
>> Capabilities: [160] Device Serial Number 78-56-34-12-78-56-34-12
>> Kernel driver in use: r8169
>> Kernel modules: r8169
>>
>> I have been having two problems with this nic:
>>
>> 1) On a cold boot, the nic is not brought up correctly. It seems to
>> stay at 100mbit instead of going into gbit mode, and it fails to ping
>> the router even though it seems to get a valid IP address. If I then
>> warm boot the computer, then then nic comes up in gbit just fine, and
>> generally works.
>>
>> 2) I am getting a lot of timeouts:
>>
>> Aug 4 17:49:35 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
>> Aug 4 17:49:35 saphire kernel: r8169: eth0: link up
>> Aug 4 17:50:05 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
>> Aug 4 17:50:05 saphire kernel: r8169: eth0: link up
>> ...
>> Aug 4 18:52:17 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
>> Aug 4 18:52:17 saphire kernel: r8169: eth0: link up
>> ...
>> Aug 4 18:55:59 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
>> Aug 4 18:55:59 saphire kernel: r8169: eth0: link up
>> ...
>> Aug 4 18:57:47 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
>> Aug 4 18:57:47 saphire kernel: r8169: eth0: link up
>>
>> While the booting problem is annoying, the timeouts are actually even
>> more so. I am a mythtv users, and those timeouts cause my video/audio
>> streaming to fail.
>>
>> Is there anything I can do about these problems?
>
> I probably should have mentioned that I am running the 2.6.26 kernel.
I just tried applying ALL the patches found here:
http://userweb.kernel.org/~romieu/r8169/2.6.27-rc1/20080803.tar.bz2
against 2.6.26.1. Worked for a while, I then I got:
Aug 4 21:23:24 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 4 21:23:24 saphire kernel: ------------[ cut here ]------------
Aug 4 21:23:24 saphire kernel: WARNING: at
net/sched/sch_generic.c:222 dev_watchdog+0xb6/0x116()
Aug 4 21:23:24 saphire kernel: Modules linked in: hdpvr videodev
v4l1_compat v4l2_common nfs nfsd lockd nfs_acl auth_rpcgss exportfs
autofs4 coretemp hwmon fuse sunrpc ipv6 acpi_cpufreq xfs dm_mirror
dm_log dm_multipath dm_mod raid456 async_xor async_memcpy async_tx xor
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
sr_mod snd_seq_device i2c_i801 serio_raw i2c_core snd_pcm_oss pcspkr
cdrom snd_mixer_oss snd_pcm snd_timer snd_page_alloc r8169 snd_hwdep
snd mii pl2303 usbserial soundcore sg button sata_mv sata_sil24 ahci
libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
[last unloaded: microcode]
Aug 4 21:23:24 saphire kernel: Pid: 12472, comm: cc1plus Not tainted
2.6.26.1 #1
Aug 4 21:23:24 saphire kernel:
Aug 4 21:23:24 saphire kernel: Call Trace:
Aug 4 21:23:24 saphire kernel: <IRQ> [<ffffffff81031fa8>]
warn_on_slowpath+0x58/0x86
Aug 4 21:23:24 saphire kernel: [<ffffffff8103a78e>] ? __mod_timer+0xc1/0xd3
Aug 4 21:23:24 saphire kernel: [<ffffffff81041458>] ?
queue_delayed_work_on+0xc3/0xd6
Aug 4 21:23:24 saphire kernel: [<ffffffff81216891>] ? dev_watchdog+0x0/0x116
Aug 4 21:23:24 saphire kernel: [<ffffffff810414a7>] ?
queue_delayed_work+0x21/0x23
Aug 4 21:23:24 saphire kernel: [<ffffffff810414c2>] ?
schedule_delayed_work+0x19/0x1b
Aug 4 21:23:24 saphire kernel: [<ffffffffa00f70d2>] ?
:r8169:rtl8169_schedule_work+0x23/0x25
Aug 4 21:23:24 saphire kernel: [<ffffffff81216947>] dev_watchdog+0xb6/0x116
Aug 4 21:23:24 saphire kernel: [<ffffffff8103a230>]
run_timer_softirq+0x16c/0x1e1
Aug 4 21:23:24 saphire kernel: [<ffffffff81036a93>] __do_softirq+0x57/0xc7
Aug 4 21:23:24 saphire kernel: [<ffffffff8100d06c>] call_softirq+0x1c/0x28
Aug 4 21:23:24 saphire kernel: [<ffffffff8100e7b6>] do_softirq+0x34/0x72
Aug 4 21:23:24 saphire kernel: [<ffffffff81036a3a>] irq_exit+0x3f/0x41
Aug 4 21:23:24 saphire kernel: [<ffffffff8101a078>]
smp_apic_timer_interrupt+0x8b/0xa7
Aug 4 21:23:24 saphire kernel: [<ffffffff8100cb16>]
apic_timer_interrupt+0x66/0x70
Aug 4 21:23:24 saphire kernel: <EOI>
Aug 4 21:23:24 saphire kernel: ---[ end trace 0d5c00894ac85a19 ]---
Aug 4 21:23:24 saphire kernel: r8169: eth0: link up
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-05 3:42 ` John P Poet
@ 2008-08-05 21:42 ` Francois Romieu
2008-08-06 5:21 ` John P Poet
2008-08-06 14:57 ` Indan Zupancic
0 siblings, 2 replies; 23+ messages in thread
From: Francois Romieu @ 2008-08-05 21:42 UTC (permalink / raw)
To: John P Poet; +Cc: netdev
(please Cc: the maintainer)
John P Poet <jppoet@gmail.com> :
[...]
> I just tried applying ALL the patches found here:
>
> http://userweb.kernel.org/~romieu/r8169/2.6.27-rc1/20080803.tar.bz2
>
> against 2.6.26.1. Worked for a while, I then I got:
Try to add 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch
from http://userweb.kernel.org/~romieu/r8169/2.6.26/20080717/
It is in 2.6.27-rc1 as 77332894c21165404496c56763d7df6c15c4bb09.
--
Ueimor
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-05 21:42 ` Francois Romieu
@ 2008-08-06 5:21 ` John P Poet
2008-08-06 19:03 ` Francois Romieu
2008-08-06 14:57 ` Indan Zupancic
1 sibling, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-06 5:21 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Tue, Aug 5, 2008 at 3:42 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> (please Cc: the maintainer)
>
> John P Poet <jppoet@gmail.com> :
> [...]
>> I just tried applying ALL the patches found here:
>>
>> http://userweb.kernel.org/~romieu/r8169/2.6.27-rc1/20080803.tar.bz2
>>
>> against 2.6.26.1. Worked for a while, I then I got:
>
> Try to add 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch
> from http://userweb.kernel.org/~romieu/r8169/2.6.26/20080717/
>
> It is in 2.6.27-rc1 as 77332894c21165404496c56763d7df6c15c4bb09.
>
> --
> Ueimor
>
Thank you for the response. That DOES seem to fix the cold-boot issue.
Unfortunately, it does not fix the timeout problem. I am still
experiencing transmittion problems:
===================================================================
Aug 5 22:42:31 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 5 22:42:31 saphire kernel: ------------[ cut here ]------------
Aug 5 22:42:31 saphire kernel: WARNING: at
net/sched/sch_generic.c:222 dev_watchdog+0xb6/0x116()
Aug 5 22:42:31 saphire kernel: Modules linked in: hdpvr videodev
v4l1_compat v4l2_common nfs nfsd lockd nfs_acl auth_rpcgss exportfs
autofs4 coretemp hwmon fuse sunrpc ipv6 acpi_cpufreq xfs dm_mirror
dm_log dm_multipath dm_mod raid456 async_xor async_memcpy async_tx xor
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event i2c_i801
snd_seq serio_raw pcspkr sr_mod i2c_core cdrom snd_seq_device
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep
r8169 snd pl2303 usbserial soundcore sg button sata_mv sata_sil24 ahci
libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
[last unloaded: microcode]
Aug 5 22:42:31 saphire kernel: Pid: 0, comm: swapper Not tainted 2.6.26.1b #1
Aug 5 22:42:31 saphire kernel:
Aug 5 22:42:31 saphire kernel: Call Trace:
Aug 5 22:42:31 saphire kernel: <IRQ> [<ffffffff81031fa8>]
warn_on_slowpath+0x58/0x86
Aug 5 22:42:31 saphire kernel: [<ffffffff8103a78e>] ? __mod_timer+0xc1/0xd3
Aug 5 22:42:31 saphire kernel: [<ffffffff81041458>] ?
queue_delayed_work_on+0xc3/0xd6
Aug 5 22:42:31 saphire kernel: [<ffffffff81216891>] ? dev_watchdog+0x0/0x116
Aug 5 22:42:31 saphire kernel: [<ffffffff810414a7>] ?
queue_delayed_work+0x21/0x23
Aug 5 22:42:31 saphire kernel: [<ffffffff810414c2>] ?
schedule_delayed_work+0x19/0x1b
Aug 5 22:42:31 saphire kernel: [<ffffffffa00ec0d2>] ?
:r8169:rtl8169_schedule_work+0x23/0x25
Aug 5 22:42:31 saphire kernel: [<ffffffff81216947>] dev_watchdog+0xb6/0x116
Aug 5 22:42:31 saphire kernel: [<ffffffff8103a230>]
run_timer_softirq+0x16c/0x1e1
Aug 5 22:42:31 saphire kernel: [<ffffffff81036a93>] __do_softirq+0x57/0xc7
Aug 5 22:42:31 saphire kernel: [<ffffffff8100d06c>] call_softirq+0x1c/0x28
Aug 5 22:42:31 saphire kernel: [<ffffffff8100e7b6>] do_softirq+0x34/0x72
Aug 5 22:42:31 saphire kernel: [<ffffffff81036a3a>] irq_exit+0x3f/0x41
Aug 5 22:42:31 saphire kernel: [<ffffffff8101a078>]
smp_apic_timer_interrupt+0x8b/0xa7
Aug 5 22:42:31 saphire kernel: [<ffffffff8100cb16>]
apic_timer_interrupt+0x66/0x70
Aug 5 22:42:31 saphire kernel: <EOI> [<ffffffff81174ada>] ?
acpi_safe_halt+0x2b/0x3e
Aug 5 22:42:31 saphire kernel: [<ffffffff811e88b3>] ?
cpuidle_idle_call+0x0/0xa1
Aug 5 22:42:31 saphire kernel: [<ffffffff81174b99>] ?
acpi_idle_enter_c1+0xac/0x10a
Aug 5 22:42:31 saphire kernel: [<ffffffff811e8923>] ?
cpuidle_idle_call+0x70/0xa1
Aug 5 22:42:31 saphire kernel: [<ffffffff811e88b3>] ?
cpuidle_idle_call+0x0/0xa1
Aug 5 22:42:31 saphire kernel: [<ffffffff8100ac02>] ? cpu_idle+0x75/0x93
Aug 5 22:42:31 saphire kernel: [<ffffffff8127356d>] ? rest_init+0x61/0x63
Aug 5 22:42:31 saphire kernel:
Aug 5 22:42:31 saphire kernel: ---[ end trace de25ab7d23456abe ]---
Aug 5 22:42:31 saphire kernel: r8169: eth0: link up
...
Aug 5 22:45:07 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 5 22:45:07 saphire kernel: r8169: eth0: link up
...
Aug 5 22:49:37 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 5 22:49:37 saphire kernel: r8169: eth0: link up
Aug 5 22:50:49 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 5 22:50:49 saphire kernel: r8169: eth0: link up
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: Giga-byte Technology Unknown device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 2292
Region 0: I/O ports at 9000 [size=256]
Region 2: Memory at e0010000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at e0000000 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at e0020000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable+
Address: 00000000fee0200c Data: 41d1
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <512ns, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 78-56-34-12-78-56-34-12
Kernel driver in use: r8169
Kernel modules: r8169
===================================================================
I tried applying that patch along with the others I had already
grabbed from your directory and I still had the timeout problem. I
unpacked a fresh copy of linux-2.6.26.1 and just applied that one
patch to it and still have the timeout problem.
Again, in case it helps:
===================================================================
lspci -vv
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: Giga-byte Technology Unknown device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 2292
Region 0: I/O ports at 9000 [size=256]
Region 2: Memory at e0010000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at e0000000 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at e0020000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable+
Address: 00000000fee0200c Data: 41d1
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <512ns, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 78-56-34-12-78-56-34-12
Kernel driver in use: r8169
Kernel modules: r8169
===================================================================
I have run memtest86+ on this machine for 12 hours, and it did not
find any problems.
Is there anything else I can try?
Thanks,
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-05 21:42 ` Francois Romieu
2008-08-06 5:21 ` John P Poet
@ 2008-08-06 14:57 ` Indan Zupancic
2008-08-06 18:12 ` Francois Romieu
1 sibling, 1 reply; 23+ messages in thread
From: Indan Zupancic @ 2008-08-06 14:57 UTC (permalink / raw)
To: netdev
Francois Romieu <romieu <at> fr.zoreil.com> writes:
>
> (please Cc: the maintainer)
>
> John P Poet <jppoet <at> gmail.com> :
> [...]
> > I just tried applying ALL the patches found here:
> >
> > http://userweb.kernel.org/~romieu/r8169/2.6.27-rc1/20080803.tar.bz2
> >
> > against 2.6.26.1. Worked for a while, I then I got:
>
> Try to add 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch
> from http://userweb.kernel.org/~romieu/r8169/2.6.26/20080717/
>
> It is in 2.6.27-rc1 as 77332894c21165404496c56763d7df6c15c4bb09.
>
I'm running a git version just before 2.6.27-rc2 and while the card
worked fine in 2.6.26, after a resume from suspend to ram I now get:
[ 8367.073701] r8169 0000:01:00.0: restoring config space at offset 0x1
(was 0x100007, writing 0x100407)
[ 8367.073863] sd 2:0:0:0: [sda] Starting disk
[ 8367.077786] r8169: eth0: link up
[ 8367.265653] ata4.01: configured for UDMA/100
[ 8371.953804] ata3.00: configured for UDMA/133
[ 8371.964803] sd 2:0:0:0: [sda] 390721968 512-byte hardware sectors (200050 MB)
[ 8371.964833] sd 2:0:0:0: [sda] Write Protect is off
[ 8371.964836] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8371.964883] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 8371.975538] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 8371.975545] pci 0000:00:02.0: setting latency timer to 64
[ 8371.977770] PM: Finishing wakeup.
[ 8371.977772] Restarting tasks ... done.
[ 8397.700577] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[ 8397.700590] ------------[ cut here ]------------
[ 8397.700592] WARNING: at
/home/indan/src/git/linux-2.6/net/sched/sch_generic.c:219
dev_watchdog+0xfa/0x14a()
[ 8397.700594] Modules linked in: i915 drm
[ 8397.700600] Pid: 0, comm: swapper Not tainted 2.6.27-rc1 #8
[ 8397.700602]
[ 8397.700602] Call Trace:
[ 8397.700604] <IRQ> [<ffffffff80235512>] warn_on_slowpath+0x51/0x77
[ 8397.700612] [<ffffffff80236043>] printk+0x4e/0x56
[ 8397.700615] [<ffffffff804cda7d>] _spin_lock_irqsave+0x18/0x3a
[ 8397.700619] [<ffffffff8023dd61>] lock_timer_base+0x26/0x4c
[ 8397.700622] [<ffffffff804cdd80>] _spin_unlock_irqrestore+0x2d/0x39
[ 8397.700625] [<ffffffff8023deee>] __mod_timer+0xbb/0xcd
[ 8397.700628] [<ffffffff8022869a>] calc_delta_fair+0x1a/0x34
[ 8397.700632] [<ffffffff8024448a>] queue_delayed_work_on+0xaa/0xba
[ 8397.700635] [<ffffffff8047d14c>] dev_watchdog+0x0/0x14a
[ 8397.700637] [<ffffffff8047d246>] dev_watchdog+0xfa/0x14a
[ 8397.700641] [<ffffffff8024916e>] hrtimer_hres_active+0x1a/0x30
[ 8397.700643] [<ffffffff8023d806>] run_timer_softirq+0x16e/0x1e9
[ 8397.700647] [<ffffffff8024c478>] getnstimeofday+0x33/0x6e
[ 8397.700651] [<ffffffff80239e88>] __do_softirq+0x60/0xab
[ 8397.700654] [<ffffffff8020c73c>] call_softirq+0x1c/0x28
[ 8397.700657] [<ffffffff8020e981>] do_softirq+0x2c/0x6b
[ 8397.700660] [<ffffffff80239d83>] irq_exit+0x36/0x8d
[ 8397.700664] [<ffffffff8021c014>] smp_apic_timer_interrupt+0x7b/0x86
[ 8397.700667] [<ffffffff8020c186>] apic_timer_interrupt+0x66/0x70
[ 8397.700668] <EOI> [<ffffffff80211af2>] read_tsc+0x0/0x1c
[ 8397.700674] [<ffffffff80212380>] mwait_idle+0x35/0x38
[ 8397.700677] [<ffffffff80209e94>] cpu_idle+0x76/0xbc
[ 8397.700679]
[ 8397.700680] ---[ end trace 8c87f3ce26ef3799 ]---
[ 8397.726489] r8169: eth0: link up
[ 8409.700338] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[ 8409.704926] r8169: eth0: link up
[ 8421.700095] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[ 8421.727525] r8169: eth0: link up
[ 8433.699859] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[ 8433.704200] r8169: eth0: link up
Earlier in boot I have:
[ 0.205570] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 0.205622] r8169 0000:01:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 0.205678] r8169 0000:01:00.0: setting latency timer to 64
[ 0.206002] eth0: RTL8101e at 0xffffc2000002a000, 00:19:66:5c:94:a7, XID
34200000 IRQ 221
Greetings,
Indan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 14:57 ` Indan Zupancic
@ 2008-08-06 18:12 ` Francois Romieu
2008-08-06 19:37 ` Indan Zupancic
0 siblings, 1 reply; 23+ messages in thread
From: Francois Romieu @ 2008-08-06 18:12 UTC (permalink / raw)
To: Indan Zupancic; +Cc: netdev
Indan Zupancic <indan@nul.nu> :
[...]
> I'm running a git version just before 2.6.27-rc2 and while the card
> worked fine in 2.6.26, after a resume from suspend to ram I now get:
You cab try to revert the four (4) r8169.c related patches that went
in between 2.6.26 and 2.6.27-rc1. I doubt it will make a difference
though.
Is a git bisect an option ?
--
Ueimor
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 5:21 ` John P Poet
@ 2008-08-06 19:03 ` Francois Romieu
2008-08-07 5:51 ` John P Poet
0 siblings, 1 reply; 23+ messages in thread
From: Francois Romieu @ 2008-08-06 19:03 UTC (permalink / raw)
To: John P Poet; +Cc: netdev
John P Poet <jppoet@gmail.com> :
[...]
> Thank you for the response. That DOES seem to fix the cold-boot issue.
>
> Unfortunately, it does not fix the timeout problem. I am still
> experiencing transmittion problems:
Does the patch below (on top of the current pile) make a difference ?
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index c421bf6..348846f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -874,12 +874,9 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
- if ((tp->mac_version == RTL_GIGA_MAC_VER_12) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_17)) {
- /* Vendor specific (0x1f) and reserved (0x0e) MII registers. */
- mdio_write(ioaddr, 0x1f, 0x0000);
- mdio_write(ioaddr, 0x0e, 0x0000);
- }
+ /* Vendor specific (0x1f) and reserved (0x0e) MII registers. */
+ mdio_write(ioaddr, 0x1f, 0x0000);
+ mdio_write(ioaddr, 0x0e, 0x0000);
tp->phy_auto_nego_reg = auto_nego;
tp->phy_1000_ctrl_reg = giga_ctrl;
--
Ueimor
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 18:12 ` Francois Romieu
@ 2008-08-06 19:37 ` Indan Zupancic
2008-08-06 19:50 ` Francois Romieu
0 siblings, 1 reply; 23+ messages in thread
From: Indan Zupancic @ 2008-08-06 19:37 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
Hello,
On Wed, August 6, 2008 20:12, Francois Romieu wrote:
> Indan Zupancic <indan@nul.nu> :
> [...]
>> I'm running a git version just before 2.6.27-rc2 and while the card
>> worked fine in 2.6.26, after a resume from suspend to ram I now get:
>
> You cab try to revert the four (4) r8169.c related patches that went
> in between 2.6.26 and 2.6.27-rc1. I doubt it will make a difference
> though.
"git log drivers/net/r8169.c" shows only two commits since May 11:
r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06
r8169: multicast register update
Then at May 11 comes:
r8169: remove non-napi code
But I think that was in 2.6.26 already.
Reverting the first two didn't help, so I guess it's messed up
somewhere else.
Are two patches missing or didn't they touch r8169.c?
I tried manually reverting patch
0004-r8169-new-phy-init-parameters-for-the-8168b.patch
(misread your mail), and it didn't seem applied yet.
> Is a git bisect an option ?
Yes, but it takes quite a lot of time and I'm busy at the moment,
so I'll wait till rc2 to see if it's fixed then. If it isn't I'll
start digging.
Greetings,
Indan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 19:37 ` Indan Zupancic
@ 2008-08-06 19:50 ` Francois Romieu
2008-08-06 22:50 ` Indan Zupancic
2008-08-23 13:51 ` Indan Zupancic
0 siblings, 2 replies; 23+ messages in thread
From: Francois Romieu @ 2008-08-06 19:50 UTC (permalink / raw)
To: Indan Zupancic; +Cc: netdev
Indan Zupancic <indan@nul.nu> :
[...]
> "git log drivers/net/r8169.c" shows only two commits since May 11:
$ git rev-list v2.6.26..v2.6.27-rc1 -- drivers/net/r8169.c
77332894c21165404496c56763d7df6c15c4bb09
f887cce8de019bb32917789379af89ae4c0294ee
865c652d6be9929927cabdc54b137b7541eb6612
1087f4f4af302e6e2fa40dd741f306444d90bece
> r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06
>
> r8169: multicast register update
>
> Then at May 11 comes:
>
> r8169: remove non-napi code
>
> But I think that was in 2.6.26 already.
No. :o)
[...]
> Yes, but it takes quite a lot of time and I'm busy at the moment,
> so I'll wait till rc2 to see if it's fixed then. If it isn't I'll
> start digging.
Ok.
--
Ueimor
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 19:50 ` Francois Romieu
@ 2008-08-06 22:50 ` Indan Zupancic
2008-08-23 13:51 ` Indan Zupancic
1 sibling, 0 replies; 23+ messages in thread
From: Indan Zupancic @ 2008-08-06 22:50 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Wed, August 6, 2008 21:50, Francois Romieu wrote:
> Indan Zupancic <indan@nul.nu> :
> [...]
>> "git log drivers/net/r8169.c" shows only two commits since May 11:
>
> $ git rev-list v2.6.26..v2.6.27-rc1 -- drivers/net/r8169.c
> 77332894c21165404496c56763d7df6c15c4bb09
> f887cce8de019bb32917789379af89ae4c0294ee
> 865c652d6be9929927cabdc54b137b7541eb6612
> 1087f4f4af302e6e2fa40dd741f306444d90bece
>
>> r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06
>>
>> r8169: multicast register update
>>
>> Then at May 11 comes:
>>
>> r8169: remove non-napi code
>>
>> But I think that was in 2.6.26 already.
>
> No. :o)
Oh...
I tried 2.6.27-rc2 with that patch reverted and NAPI disabled,
but that didn't work either, so it seems it's something a level
higher. (No way that that last patch could cause this...)
You said off-list that I may want to check if there is any aspm
related message in dmesg. Well, I get this:
Pre-1.1 PCIe device detected, disable ASPM for 0000:00:1c.1.
It can be enabled forcedly with 'pcie_aspm=force'
So I guess it's unlikely that it causes any problems, except
if the driver assumes it's always enabled. Booting with
pcie_aspm=force didn't change anything (though strangely
enough I still get the same message as above).
All in all I'll wait till rc3 and see how things are then.
Thank you for the help,
Indan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 19:03 ` Francois Romieu
@ 2008-08-07 5:51 ` John P Poet
2008-08-07 22:31 ` Francois Romieu
0 siblings, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-07 5:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Wed, Aug 6, 2008 at 1:03 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> John P Poet <jppoet@gmail.com> :
> [...]
>> Thank you for the response. That DOES seem to fix the cold-boot issue.
>>
>> Unfortunately, it does not fix the timeout problem. I am still
>> experiencing transmittion problems:
>
> Does the patch below (on top of the current pile) make a difference ?
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index c421bf6..348846f 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -874,12 +874,9 @@ static int rtl8169_set_speed_xmii(struct net_device *dev,
>
> auto_nego |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
>
> - if ((tp->mac_version == RTL_GIGA_MAC_VER_12) ||
> - (tp->mac_version == RTL_GIGA_MAC_VER_17)) {
> - /* Vendor specific (0x1f) and reserved (0x0e) MII registers. */
> - mdio_write(ioaddr, 0x1f, 0x0000);
> - mdio_write(ioaddr, 0x0e, 0x0000);
> - }
> + /* Vendor specific (0x1f) and reserved (0x0e) MII registers. */
> + mdio_write(ioaddr, 0x1f, 0x0000);
> + mdio_write(ioaddr, 0x0e, 0x0000);
>
> tp->phy_auto_nego_reg = auto_nego;
> tp->phy_1000_ctrl_reg = giga_ctrl;
> --
> Ueimor
>
That does not make any difference.
I will say, that the problem seems to be reduced by this patch (or the
0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch).
Before, I was getting failures two or three times an hour. With
either of these patches applied, the failure rate has dropped to one
every two to four hours.
Thanks for trying.
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-07 5:51 ` John P Poet
@ 2008-08-07 22:31 ` Francois Romieu
2008-08-07 22:51 ` John P Poet
2008-08-08 3:28 ` John P Poet
0 siblings, 2 replies; 23+ messages in thread
From: Francois Romieu @ 2008-08-07 22:31 UTC (permalink / raw)
To: John P Poet; +Cc: netdev
John P Poet <jppoet@gmail.com> :
[...]
> That does not make any difference.
>
> I will say, that the problem seems to be reduced by this patch (or the
> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch).
>
> Before, I was getting failures two or three times an hour. With
> either of these patches applied, the failure rate has dropped to one
> every two to four hours.
I have updated the kit at http://userweb.kernel.org/~romieu/r8169/2.6.27-rc2
Can you give it a try ?
--
Ueimor
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-07 22:31 ` Francois Romieu
@ 2008-08-07 22:51 ` John P Poet
2008-08-08 3:28 ` John P Poet
1 sibling, 0 replies; 23+ messages in thread
From: John P Poet @ 2008-08-07 22:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Thu, Aug 7, 2008 at 4:31 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> John P Poet <jppoet@gmail.com> :
> [...]
>> That does not make any difference.
>>
>> I will say, that the problem seems to be reduced by this patch (or the
>> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch).
>>
>> Before, I was getting failures two or three times an hour. With
>> either of these patches applied, the failure rate has dropped to one
>> every two to four hours.
>
> I have updated the kit at http://userweb.kernel.org/~romieu/r8169/2.6.27-rc2
>
> Can you give it a try ?
*Instead* of the previous patches, right?
I will try applying 20080807-r8169-test.patch to the new 2.6.26.2 source.
Thanks,
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-07 22:31 ` Francois Romieu
2008-08-07 22:51 ` John P Poet
@ 2008-08-08 3:28 ` John P Poet
2008-08-08 3:51 ` John P Poet
2008-08-22 19:55 ` John P Poet
1 sibling, 2 replies; 23+ messages in thread
From: John P Poet @ 2008-08-08 3:28 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Thu, Aug 7, 2008 at 4:31 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> John P Poet <jppoet@gmail.com> :
> [...]
>> That does not make any difference.
>>
>> I will say, that the problem seems to be reduced by this patch (or the
>> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch).
>>
>> Before, I was getting failures two or three times an hour. With
>> either of these patches applied, the failure rate has dropped to one
>> every two to four hours.
>
> I have updated the kit at http://userweb.kernel.org/~romieu/r8169/2.6.27-rc2
>
> Can you give it a try ?
At first I *just* applied 20080807-r8169-test.patch, but the NIC did
not initialize during boot. So, I also applied
0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch. After
that, it booted okay.
However, in general use it is much worse. May just be bad luck (or
something in the 2.26.2 kernel?), but the timeout message are rampant:
Aug 7 21:14:58 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug 7 21:14:58 saphire kernel: r8169: eth0: link up
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-08 3:28 ` John P Poet
@ 2008-08-08 3:51 ` John P Poet
2008-08-12 5:42 ` David Madsen
2008-08-22 19:55 ` John P Poet
1 sibling, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-08 3:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Thu, Aug 7, 2008 at 9:28 PM, John P Poet <jppoet@gmail.com> wrote:
> On Thu, Aug 7, 2008 at 4:31 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
>> John P Poet <jppoet@gmail.com> :
>> [...]
>>> That does not make any difference.
>>>
>>> I will say, that the problem seems to be reduced by this patch (or the
>>> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch).
>>>
>>> Before, I was getting failures two or three times an hour. With
>>> either of these patches applied, the failure rate has dropped to one
>>> every two to four hours.
>>
>> I have updated the kit at http://userweb.kernel.org/~romieu/r8169/2.6.27-rc2
>>
>> Can you give it a try ?
>
> At first I *just* applied 20080807-r8169-test.patch, but the NIC did
> not initialize during boot. So, I also applied
> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch. After
> that, it booted okay.
>
> However, in general use it is much worse. May just be bad luck (or
> something in the 2.26.2 kernel?), but the timeout message are rampant:
>
> Aug 7 21:14:58 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 7 21:14:58 saphire kernel: r8169: eth0: link up
Hmmm. Not just "much worse", but much, much, much, much, much worse!
I am getting several timeouts every minute.
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-08 3:51 ` John P Poet
@ 2008-08-12 5:42 ` David Madsen
2008-08-12 20:18 ` Francois Romieu
0 siblings, 1 reply; 23+ messages in thread
From: David Madsen @ 2008-08-12 5:42 UTC (permalink / raw)
To: John P Poet; +Cc: Francois Romieu, netdev
> 2) I am getting a lot of timeouts:
>
> Aug 4 17:49:35 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 4 17:49:35 saphire kernel: r8169: eth0: link up
...
>
> While the booting problem is annoying, the timeouts are actually even
> more so. I am a mythtv users, and those timeouts cause my video/audio
> streaming to fail.
I also have a Realtek GigE card that was quite stable running on
2.6.24. I recently updated my kernel briefly to 2.6.25.10 then
ultimately to 2.6.26.2 and started seeing similar timeouts in both
kernel versions. My configuration didn't change much between the
kernels, but I do remember enabling MSI when I rebuit the kernel. I
have not yet had a chance to disable MSI to see if that fixes the
timeouts but I thought I'd post what info I have in case that might
steer the debug in the right direction. The frequency of the timeouts
has been quite low, and once the interface comes back up everything
seems to continue to function properly. I haven't applied any of the
discussed patches yet, but I have set up the machine to disable MSI
the next time I am able to reboot it. Prior to the kernel update from
2.6.24, MSI was diabled and I did not have any issues with timeouts on
the interface. Let me know if I can provide any more information that
may help with this debug.
Here is the initialization:
Aug 6 17:02:13 [kernel] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
Aug 6 17:02:13 [kernel] ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16
(level, low) -> IRQ 16
Aug 6 17:02:13 [kernel] PCI: Setting latency timer of device 0000:04:00.0 to 64
Aug 6 17:02:13 [kernel] eth0: RTL8168b/8111b at 0xf881e000,
00:1a:4d:53:cd:0f, XID 38000000 IRQ 218
Several days later the first timeout:
NETDEV WATCHDOG: eth0: transmit timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:222 dev_watchdog+0xfd/0x110()
Modules linked in: xfs nfs coretemp it87 hwmon_vid eeprom nfsd lockd
sunrpc exportfs snd_pcm_oss snd_mixer_oss snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device fuse raid0 raid456 async_xor
async_memcpy async_tx xor md_mod raw1394 or51132 usbhid cx88_dvb
cx88_vp3054_i2c videobuf_dvb dvb_core tuner_simple tuner_types tda9887
tda8290 tuner tvaudio nvidia(P) msp3400 cx8800 cx88_alsa cx8802 cx88xx
bttv firmware_class compat_ioctl32 videodev v4l1_compat ir_common
i2c_algo_bit ehci_hcd v4l2_common videobuf_dma_sg ohci1394
videobuf_core btcx_risc ieee1394 uhci_hcd usbcore r8169 snd_hda_intel
evdev snd_pcm snd_timer tveeprom snd soundcore snd_page_alloc i2c_i801
i2c_core
Pid: 0, comm: swapper Tainted: P 2.6.26.2 #1
[<c012258f>] warn_on_slowpath+0x5f/0x90
[<c01191cb>] __wake_up_common+0x4b/0x80
[<c011a38e>] __wake_up+0x3e/0x60
[<c0122d6b>] wake_up_klogd+0x3b/0x40
[<c0123431>] vprintk+0x2f1/0x380
[<c012b857>] lock_timer_base+0x27/0x60
[<c012b996>] __mod_timer+0x96/0xb0
[<c013261b>] queue_delayed_work_on+0x7b/0xb0
[<c02af9bd>] dev_watchdog+0xfd/0x110
[<c012b2c0>] run_timer_softirq+0x120/0x190
[<c013f264>] tick_program_event+0x44/0x70
[<c02af8c0>] dev_watchdog+0x0/0x110
[<c01275c2>] __do_softirq+0x82/0x100
[<c0127677>] do_softirq+0x37/0x40
[<c0127785>] irq_exit+0x75/0x90
[<c0112787>] smp_apic_timer_interrupt+0x57/0x90
[<c0103a7c>] apic_timer_interrupt+0x28/0x30
[<c01093c2>] mwait_idle+0x32/0x40
[<c0109390>] mwait_idle+0x0/0x40
[<c0101a9d>] cpu_idle+0x4d/0xb0
=======================
---[ end trace 3239fda7c0460ac6 ]---
r8169: eth0: link up
lspci output (a few hours after the timout occurred):
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown
device 8168 (rev 01)
Subsystem: Giga-byte Technology Unknown device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 218
Region 0: I/O ports at d000 [size=256]
Region 2: Memory at ed000000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at 40000000 [disabled] [size=128K]
Capabilities: [40] 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: [48] Vital Product Data
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable+
Address: 00000000fee0100c Data: 4132
Capabilities: [60] Express Endpoint IRQ 0
Device: Supported: MaxPayload 1024 bytes, PhantFunc 0, ExtTag+
Device: Latency L0s <128ns, L1 unlimited
Device: AtnBtn+ AtnInd+ PwrInd+
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [84] Vendor Specific Information
Capabilities: [100] Advanced Error Reporting
Capabilities: [12c] Virtual Channel
Capabilities: [148] Device Serial Number 68-81-ec-10-00-00-00-00
Capabilities: [154] Power Budgeting
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-12 5:42 ` David Madsen
@ 2008-08-12 20:18 ` Francois Romieu
2008-08-12 21:44 ` John Patrick Poet
2008-08-13 0:39 ` David Madsen
0 siblings, 2 replies; 23+ messages in thread
From: Francois Romieu @ 2008-08-12 20:18 UTC (permalink / raw)
To: David Madsen; +Cc: John P Poet, netdev
David Madsen <david.madsen@gmail.com> :
[...]
> I also have a Realtek GigE card that was quite stable running on
> 2.6.24. I recently updated my kernel briefly to 2.6.25.10 then
> ultimately to 2.6.26.2 and started seeing similar timeouts in both
> kernel versions.
Please note that the kernel complains more loudly about the watchdog
than it used to. Does it allow traffic to flow afterwards ?
--
Ueimor
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-12 20:18 ` Francois Romieu
@ 2008-08-12 21:44 ` John Patrick Poet
2008-08-13 0:39 ` David Madsen
1 sibling, 0 replies; 23+ messages in thread
From: John Patrick Poet @ 2008-08-12 21:44 UTC (permalink / raw)
To: Francois Romieu; +Cc: David Madsen, John P Poet, netdev
On Tuesday 12 August 2008 02:18:47 pm Francois Romieu wrote:
> David Madsen <david.madsen@gmail.com> :
> [...]
>
> > I also have a Realtek GigE card that was quite stable running on
> > 2.6.24. I recently updated my kernel briefly to 2.6.25.10 then
> > ultimately to 2.6.26.2 and started seeing similar timeouts in both
> > kernel versions.
>
> Please note that the kernel complains more loudly about the watchdog
> than it used to. Does it allow traffic to flow afterwards ?
When one of these "hick-ups" happen while I am streaming video from my Myth
backend to my Myth frontend, it kills the playback, and I have to re-start
it. It takes 5 to 10 seconds before I can re-start the playback, but it does
work without having to take any special action on my part.
So, to answer your question, yes traffic does flow afterwards.
John
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-12 20:18 ` Francois Romieu
2008-08-12 21:44 ` John Patrick Poet
@ 2008-08-13 0:39 ` David Madsen
1 sibling, 0 replies; 23+ messages in thread
From: David Madsen @ 2008-08-13 0:39 UTC (permalink / raw)
To: netdev
>
> Please note that the kernel complains more loudly about the watchdog
> than it used to. Does it allow traffic to flow afterwards ?
>
Likewise for me, the connection does come back up and continues to
function. Prior to the upgrade and switch to MSI though I never had
any glitches like these that are occurring now. Hopefully I'll be
able to disable MSI sometime this week to test out that theory. Since
these timeouts are not easily forced (seems to be unaffected by
traffic load) It may take a while to confirm whether that fixes the
problem or not.
--David Madsen
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-08 3:28 ` John P Poet
2008-08-08 3:51 ` John P Poet
@ 2008-08-22 19:55 ` John P Poet
2008-08-24 22:09 ` Francois Romieu
1 sibling, 1 reply; 23+ messages in thread
From: John P Poet @ 2008-08-22 19:55 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Thu, Aug 7, 2008 at 9:28 PM, John P Poet <jppoet@gmail.com> wrote:
> On Thu, Aug 7, 2008 at 4:31 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
>> John P Poet <jppoet@gmail.com> :
>> [...]
>>> That does not make any difference.
>>>
>>> I will say, that the problem seems to be reduced by this patch (or the
>>> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch).
>>>
>>> Before, I was getting failures two or three times an hour. With
>>> either of these patches applied, the failure rate has dropped to one
>>> every two to four hours.
>>
>> I have updated the kit at http://userweb.kernel.org/~romieu/r8169/2.6.27-rc2
>>
>> Can you give it a try ?
>
> At first I *just* applied 20080807-r8169-test.patch, but the NIC did
> not initialize during boot. So, I also applied
> 0002-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch. After
> that, it booted okay.
>
> However, in general use it is much worse. May just be bad luck (or
> something in the 2.26.2 kernel?), but the timeout message are rampant:
>
> Aug 7 21:14:58 saphire kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Aug 7 21:14:58 saphire kernel: r8169: eth0: link up
>
>
> John
Any other ideas on this problem? I am wondering if most people are
not complaining about it, because it is probably not noticeable for
web browsing (web browsing naturally has latencies involved). It is a
killer for streaming stuff in "real time" between two machines,
though.
On my current machine with a 8111C NIC, I have disabled that NIC and
bought an Intel e1000 PCIe NIC. That has solved the problem on that
computer, but I want to build another computer, and it seems like all
the new motherboards have the Realtek 8111C on them.
Should I try the "official" driver from Realtek? How hard is it to integrate?
Thanks,
John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-06 19:50 ` Francois Romieu
2008-08-06 22:50 ` Indan Zupancic
@ 2008-08-23 13:51 ` Indan Zupancic
1 sibling, 0 replies; 23+ messages in thread
From: Indan Zupancic @ 2008-08-23 13:51 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
On Wed, August 6, 2008 21:50, Francois Romieu wrote:
> Indan Zupancic <indan@nul.nu> :
> [...]
>> Yes, but it takes quite a lot of time and I'm busy at the moment,
>> so I'll wait till rc2 to see if it's fixed then. If it isn't I'll
>> start digging.
>
> Ok.
Running 2.6.27-rc3 now and that works fine. :-)
(Of course the next day rc4 came out...)
Let's use this opportunity to say a big thank you to all
you wonderful people who keep things running. The world
wouldn't be the same without you.
Greetings,
Indan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Realtek 8111C transmit timed out
2008-08-22 19:55 ` John P Poet
@ 2008-08-24 22:09 ` Francois Romieu
0 siblings, 0 replies; 23+ messages in thread
From: Francois Romieu @ 2008-08-24 22:09 UTC (permalink / raw)
To: John P Poet; +Cc: netdev
John P Poet <jppoet@gmail.com> :
[...]
> Should I try the "official" driver from Realtek ?
Yes, it would be interesting to know if it performs better.
Could you send the output of 'mii-tool -vv' ? I am curious to know how
to identify your PHY.
> How hard is it to integrate ?
It is supposed to build as an external module.
--
Ueimor
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2008-08-24 22:09 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-05 1:12 Realtek 8111C transmit timed out John P Poet
2008-08-05 2:00 ` John P Poet
2008-08-05 3:42 ` John P Poet
2008-08-05 21:42 ` Francois Romieu
2008-08-06 5:21 ` John P Poet
2008-08-06 19:03 ` Francois Romieu
2008-08-07 5:51 ` John P Poet
2008-08-07 22:31 ` Francois Romieu
2008-08-07 22:51 ` John P Poet
2008-08-08 3:28 ` John P Poet
2008-08-08 3:51 ` John P Poet
2008-08-12 5:42 ` David Madsen
2008-08-12 20:18 ` Francois Romieu
2008-08-12 21:44 ` John Patrick Poet
2008-08-13 0:39 ` David Madsen
2008-08-22 19:55 ` John P Poet
2008-08-24 22:09 ` Francois Romieu
2008-08-06 14:57 ` Indan Zupancic
2008-08-06 18:12 ` Francois Romieu
2008-08-06 19:37 ` Indan Zupancic
2008-08-06 19:50 ` Francois Romieu
2008-08-06 22:50 ` Indan Zupancic
2008-08-23 13:51 ` Indan Zupancic
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).