Re: Fwd: Re: WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x277/0x280()

(Resending to netdev@vger.kernel.org since previous attempt was rejected as spam)

El 03/05/12 10:39, Alex Villací­s Lasso escribió:

Alex Villací­s Lasso[off-list ref]  :
[...]

quoted

 I am currently away from the target computer. How should I check for this? lspci?

lspci can not tell much. Use 'dmesg | grep XID' instead.

[alex@karlalex linux-git]$ dmesg | grep -i xid
[   10.647557] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 0xffffc90000352000, 00:22:68:44:17:2f, XID 98500000 IRQ 43

A complete dmesg would be welcome.

It could help to know a few things :
- does the problem qualify as a regression since some kernel version ?
   If so which one ?

I have only seen these messages since 3.4-rc1. Vanilla kernels up to 3.3, and stock Fedora 16 kernels (kernel-3.3.2-6.fc16.x86_64) did not display this problem. However, I cannot confirm that the latest stock kernel is free from the message, since I prefer 
to run the latest RC kernel on my home machine.

- can it be reproduced with a kernel that has not been vbox tainted ?

I will check this. However, since the message only appears after an hour of so of moderate bittorrent traffic, it might take a while to confirm.

- does networking recover ?

It does recover, after a few seconds.

Thanks.

-- 
Ueimor

El 04/05/12 09:57, Alex Villací­s Lasso escribió:

(Resending to netdev@vger.kernel.org since previous attempt was 
rejected as spam)

El 03/05/12 10:39, Alex Villací­s Lasso escribió:

quoted

Alex Villací­s Lasso[off-list ref]  :
[...]

quoted

 I am currently away from the target computer. How should I check 

for this? lspci?

lspci can not tell much. Use 'dmesg | grep XID' instead.

[alex@karlalex linux-git]$ dmesg | grep -i xid
[   10.647557] r8169 0000:02:00.0: eth0: RTL8168b/8111b at 
0xffffc90000352000, 00:22:68:44:17:2f, XID 98500000 IRQ 43

It happened again, on a non-tainted kernel. The dmesg log is attached.

Alex Villacís Lasso [off-list ref] :
[...]

It happened again, on a non-tainted kernel. The dmesg log is attached.

It sucks.

Can you do a poor man's bisection of the r8169 driver between v3.3 and
v3.4-rc1  (aka 'git cat-file -p $some_rev:drivers/net/ethernet/realtek/r8169.c')

I'd try 1e874e041fc7c222cbd85b20c4406070be1f687a then
8027aa245bbd125350f6a78c5a78771d143aba55 if it does not fail.

-- 
Ueimor

El 05/05/12 18:01, Francois Romieu escribió:

Alex Villacís Lasso[off-list ref]  :
[...]

quoted

It happened again, on a non-tainted kernel. The dmesg log is attached.

It sucks.

Can you do a poor man's bisection of the r8169 driver between v3.3 and
v3.4-rc1  (aka 'git cat-file -p $some_rev:drivers/net/ethernet/realtek/r8169.c')

I'd try 1e874e041fc7c222cbd85b20c4406070be1f687a then
8027aa245bbd125350f6a78c5a78771d143aba55 if it does not fail.

I tried a bisection around the drivers/net/ethernet/realtek directory. I am confident about the bad selections, but not so much about the good selections, even though I waited a full day with the bittorrent client on the background before marking a commit 
as good.

According to my bisection, the first bad commit is 036dafa28da1e2565a8529de2ae663c37b7a0060 . Here is my bisection log:

git bisect start '--' 'drivers/net/ethernet/realtek'
# bad: [dd775ae2549217d3ae09363e3edb305d0fa19928] Linux 3.4-rc1
git bisect bad dd775ae2549217d3ae09363e3edb305d0fa19928
# good: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
git bisect good c16fa4f2ad19908a47c63d8fa436a1178438c7e7
# good: [eeb69aa443e8cdc945405c48f21ce03f5a3b1f86] 8139too: Support RX-FCS flag.
git bisect good eeb69aa443e8cdc945405c48f21ce03f5a3b1f86
# bad: [e27566ed370da09e3b812d3d76dce002915a5bdd] r8169: move the driver removal method to the end of the driver file.
git bisect bad e27566ed370da09e3b812d3d76dce002915a5bdd
# bad: [036dafa28da1e2565a8529de2ae663c37b7a0060] r8169: add byte queue limit support.
git bisect bad 036dafa28da1e2565a8529de2ae663c37b7a0060
# good: [79d0c1d26e1eac0dc5b201e66b65cc5e4e706743] r8169: Support RX-FCS flag.
git bisect good 79d0c1d26e1eac0dc5b201e66b65cc5e4e706743
# good: [8027aa245bbd125350f6a78c5a78771d143aba55] r8169: add 64bit statistics.
git bisect good 8027aa245bbd125350f6a78c5a78771d143aba55

Alex Villací­s Lasso [off-list ref] :
[...]

According to my bisection, the first bad commit is 036dafa28da1e2565a8529de2ae663c37b7a0060 . Here is my bisection log:

There would be something wrong with bql support.

Can you apply the attached patches on top of 3.4 or later then
send the kernel log output whent the bug happens ?

Thanks.

-- 
Ueimor

El 26/05/12 05:11, Francois Romieu escribió:

Alex Villací­s Lasso[off-list ref]  :
[...]

quoted

According to my bisection, the first bad commit is 036dafa28da1e2565a8529de2ae663c37b7a0060 . Here is my bisection log:

There would be something wrong with bql support.

Can you apply the attached patches on top of 3.4 or later then
send the kernel log output whent the bug happens ?

Thanks.

Attached.