r8169, 3.5.0, does't work at all

r8169, 3.5.0, does't work at all

[Denys Fedoryshchenko]

Just pushed new kernel to test cluster and got this:

[    1.604470] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.604709] r8169 0000:02:00.0: irq 43 for MSI/MSI-X
[    1.605211] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xf8604000, 
00:08:54:57:7a:54, XID 18000000 IRQ 43
[    1.605364] r8169 0000:02:00.0: eth0: jumbo features [frames: 4080 
bytes, tx checksumming: ko]
[    1.605549] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    1.605780] r8169 0000:03:00.0: irq 44 for MSI/MSI-X
[    1.606212] r8169 0000:03:00.0: eth1: RTL8168b/8111b at 0xf8606000, 
00:08:54:57:7a:33, XID 18000000 IRQ 44
[    1.606366] r8169 0000:03:00.0: eth1: jumbo features [frames: 4080 
bytes, tx checksumming: ko]
....
[   20.406090]     input device check on
[   20.406177]     Actions configured
[   21.526836] r8169 0000:02:00.0: eth0: link up
[   28.038386] ------------[ cut here ]------------
[   28.038438] WARNING: at net/sched/sch_generic.c:255 
dev_watchdog+0xd6/0x12a()
[   28.038489] Hardware name:
[   28.038534] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed 
out
[   28.038584] Modules linked in: cls_flow cls_u32 em_meta cls_basic 
xt_dscp ts_bm xt_string xt_hl ifb cls_fw sch_tbf sch_htb act_ipt 
act_mirred ipt_REDIRECT ipt_REJECT xt_TCPMSS xt_DSCP xt_mark 
iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack 
nf_defrag_ipv4 iptable_filter 8021q garp stp llc loop usb_storage mei 
lpc_ich mfd_core ahci libahci libata sr_mod cdrom tulip r8169 sky2 
via_velocity via_rhine sis900 ne2k_pci 8390 skge tg3 libphy 8139too 
e1000 e100 usbhid ohci_hcd uhci_hcd ehci_hcd usbcore usb_common [last 
unloaded: usb_storage]
[   28.038616] Pid: 4, comm: kworker/0:0 Not tainted 3.5.0-build-0063 
#4
[   28.038617] Call Trace:
[   28.038620]  [<c0127962>] warn_slowpath_common+0x77/0x8c
[   28.038623]  [<c02f507e>] ? dev_watchdog+0xd6/0x12a
[   28.038625]  [<c02f507e>] ? dev_watchdog+0xd6/0x12a
[   28.038628]  [<c01279f3>] warn_slowpath_fmt+0x2e/0x30
[   28.038630]  [<c02f507e>] dev_watchdog+0xd6/0x12a
[   28.038633]  [<c0131c45>] run_timer_softirq+0x1ab/0x254
[   28.038635]  [<c0131bc9>] ? run_timer_softirq+0x12f/0x254
[   28.038638]  [<c015d181>] ? trace_hardirqs_on_caller+0xf5/0x13f
[   28.038640]  [<c02f4fa8>] ? netif_tx_unlock+0x41/0x41
[   28.038643]  [<c012d38e>] __do_softirq+0x7b/0x118
[   28.038644]  [<c012d313>] ? local_bh_enable+0xd/0xd
[   28.038645]  <IRQ>  [<c012d5a9>] ? irq_exit+0x41/0x91
[   28.038650]  [<c0118ac0>] ? smp_apic_timer_interrupt+0x64/0x71
[   28.038652]  [<c023054c>] ? trace_hardirqs_off_thunk+0xc/0x10
[   28.038655]  [<c0353977>] ? apic_timer_interrupt+0x2f/0x34
[   28.038661]  [<f85f7e9f>] ? rtl_slow_event_work+0x14/0x1a2 [r8169]
[   28.038664]  [<c0351898>] ? mutex_lock_nested+0x20/0x22
[   28.038667]  [<f85f49d1>] ? rtl_task+0x49/0x5f [r8169]
[   28.038670]  [<c013992a>] ? process_one_work+0x1a1/0x2ab
[   28.038672]  [<c01398b9>] ? process_one_work+0x130/0x2ab
[   28.038675]  [<f85f4988>] ? rtl8169_set_features+0x39/0x39 [r8169]
[   28.038678]  [<c013a3be>] ? worker_thread+0xd1/0x14c
[   28.038680]  [<c013a2ed>] ? manage_workers.clone.20+0x14e/0x14e
[   28.038682]  [<c013d3ec>] ? kthread+0x67/0x6c
[   28.038685]  [<c0350000>] ? migration_call+0x10/0x189
[   28.038687]  [<c013d385>] ? __init_kthread_worker+0x47/0x47
[   28.038689]  [<c03542fa>] ? kernel_thread_helper+0x6/0xd
[   28.038690] ---[ end trace 9701f577e9a74181 ]---
[   28.043532] r8169 0000:02:00.0: eth0: link up
[   34.043357] r8169 0000:02:00.0: eth0: link up
[   40.043202] r8169 0000:02:00.0: eth0: link up
[   46.043052] r8169 0000:02:00.0: eth0: link up
[   52.042893] r8169 0000:02:00.0: eth0: link up
[   58.042739] r8169 0000:02:00.0: eth0: link up
[   64.042584] r8169 0000:02:00.0: eth0: link up
[   70.042430] r8169 0000:02:00.0: eth0: link up
[   76.042276] r8169 0000:02:00.0: eth0: link up
[   82.042123] r8169 0000:02:00.0: eth0: link up
[   88.041968] r8169 0000:02:00.0: eth0: link up
[   94.041813] r8169 0000:02:00.0: eth0: link up

---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.

Re: r8169, 3.5.0, does't work at all

[Francois Romieu]

Denys Fedoryshchenko <denys@visp.net.lb> :
> Just pushed new kernel to test cluster and got this:
[...]
> [    1.606212] r8169 0000:03:00.0: eth1: RTL8168b/8111b at
> 0xf8606000, 00:08:54:57:7a:33, XID 18000000 IRQ 44
> [    1.606366] r8169 0000:03:00.0: eth1: jumbo features [frames:
> 4080 bytes, tx checksumming: ko]
> ....
> [   20.406090]     input device check on
> [   20.406177]     Actions configured
> [   21.526836] r8169 0000:02:00.0: eth0: link up
> [   28.038386] ------------[ cut here ]------------
> [   28.038438] WARNING: at net/sched/sch_generic.c:255
> dev_watchdog+0xd6/0x12a()
> [   28.038489] Hardware name:
> [   28.038534] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed

Right at startup.

Which kernel did you previously use ?

This is exactly the primary device I use to access my test computer.

.config and .dmesg will be welcome as well.

-- 
Ueimor

Re: r8169, 3.5.0, does't work at all

[Denys Fedoryshchenko]

On 2012-07-26 22:56, Francois Romieu wrote:
> Denys Fedoryshchenko <denys@visp.net.lb> :
>> Just pushed new kernel to test cluster and got this:
> [...]
>> [    1.606212] r8169 0000:03:00.0: eth1: RTL8168b/8111b at
>> 0xf8606000, 00:08:54:57:7a:33, XID 18000000 IRQ 44
>> [    1.606366] r8169 0000:03:00.0: eth1: jumbo features [frames:
>> 4080 bytes, tx checksumming: ko]
>> ....
>> [   20.406090]     input device check on
>> [   20.406177]     Actions configured
>> [   21.526836] r8169 0000:02:00.0: eth0: link up
>> [   28.038386] ------------[ cut here ]------------
>> [   28.038438] WARNING: at net/sched/sch_generic.c:255
>> dev_watchdog+0xd6/0x12a()
>> [   28.038489] Hardware name:
>> [   28.038534] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed
>
> Right at startup.
>
> Which kernel did you previously use ?
>
> This is exactly the primary device I use to access my test computer.
>
> .config and .dmesg will be welcome as well.
http://www.nuclearcat.com/dmesg.txt
http://www.nuclearcat.com/config.txt

There ifplugd also running, and udhcpc, both from busybox.
Now machine are deployed to production , working fine with 3.4.6 
kernel. I can do limited tests on it,
and i can search for more machines with similar cards.

---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.

Re: r8169, 3.5.0, does't work at all

[Francois Romieu]

Denys Fedoryshchenko <denys@visp.net.lb> :
[...]
> and i can search for more machines with similar cards.

Thanks.

There seems to be a more recent bios for this motherboard. Is the second
8168b an add-on or is it a dual-port DH61HO ?

You are using x86 32 with PAE and slub where I use x86 64 with slab.
I am building a x86 32 bits test configuration for a 8168b right now.

Let's see what happened during the 3.4 .. 3.5 cycle in the r8169 driver:

- You may revert 7dbb491878a2c51d372a8890fa45a8ff80358af1 ("r8169: avoid NAPI
  scheduling delay.")

  I can see a napi rtl8169_poll failing to schedule rtl_slow_event_work
  when it is already scheduled on a different cpu, said rtl_slow_event_work
  running while rtl8169_poll is delayed and rtl8169_poll stomping on the
  IntrMask after rtl_slow_event_work did.

  It does not tell why the device does not recover after the netdev watchdog
  but it could be worth trying.

- You may revert 851e60221926a53344b4227879858bef841b0477 ("r8169: Config1 is
  read-only on 8168c and later.") as well.

  It changes the PMEEnable write ordering for the 8168b (RTL_GIGA_MAC_VER_17)
  and a few others chipset.

-- 
Ueimor