netdev - Re: 3.4-rc: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <loom.20120611T175322-643@post.gmane.org>
Date:	Mon, 11 Jun 2012 15:55:55 +0000 (UTC)
From:	Tomas Papan <tomas.papan@...il.com>
To:	netdev@...r.kernel.org
Subject: Re: 3.4-rc: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

Stefan Richter <stefanr <at> s5r6.in-berlin.de> writes:

> 
> On May 03 Stefan Richter wrote:
> > On May 01 Francois Romieu wrote:
> > [...]
> > > Can you apply the patch below on top of current ethtool
> > > (git://git.kernel.org/pub/scm/network/ethtool/ethtool.git) and see
> > > if it is enough to compare the register dumps (ethtool -d eth0).
> > [...]
> > > This is a firmware free chipset anyway. Nothing strange in the interface
> > > stats (ethtool -S eth0) ?
> > > 
> > > You may have to narrow things. Can you check if the r8169.c at
> > > 036dafa28da1e2565a8529de2ae663c37b7a0060 behaves the same ?
> > 
> > I will follow up on this eventually, but it may take quite some time due
> > to interfering work.
> > 
> > Thank you for looking into it and giving directions,
> 
> I haven't had time to look further into it yet.  Just two minor findings:
> 
> (a) After update from 3.4-rc5 to 3.4, the problem persisted.
> 
> (b) Later I noticed that silent file corruptions on FireWire disks happened
> and happen under 3.4-rc5 and 3.4, so I reverted into 3.3.1 which fixed
> that issue.  Furthermore, since 6 days uptime of 3.3.1, the eth0 (r8169)
> transmit queue time-out did never occur.
> 
> I have no idea whether the FireWire and networking issues might be somehow
> connected, and I still lack time to investigate these issues (using Linux
> only at home, not at work), but I will eventually get back to it.


Hi,

I have the same problem on 3.4.1 and 3.4.2 (3.2.x is fine)
interestingly enough, the problem occurs only once, then it is running fine
(3.4.1 and six days uptime)


WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x16b/0x20f()
[ 2839.337554] Pid: 0, comm: swapper/3 Not tainted 3.4.2 #1
[ 2839.337556] Call Trace:
[ 2839.337559]  <IRQ>  [<ffffffff81026881>] ? warn_slowpath_common+0x78/0x8c
[ 2839.337571]  [<ffffffff81026936>] ? warn_slowpath_fmt+0x45/0x4a
[ 2839.337576]  [<ffffffff81042fc2>] ? scheduler_tick+0xaf/0xc3
[ 2839.337582]  [<ffffffff812535a0>] ? dev_watchdog+0x16b/0x20f
[ 2839.337588]  [<ffffffff8102f3ae>] ? run_timer_softirq+0x177/0x209
[ 2839.337594]  [<ffffffff8103e7b3>] ? hrtimer_interrupt+0x100/0x19b
[ 2839.337599]  [<ffffffff81253435>] ? qdisc_reset+0x35/0x35
[ 2839.337605]  [<ffffffff8102b256>] ? __do_softirq+0x7f/0x106
[ 2839.337611]  [<ffffffff812e298c>] ? call_softirq+0x1c/0x30
[ 2839.337616]  [<ffffffff81003376>] ? do_softirq+0x31/0x67
[ 2839.337621]  [<ffffffff8102b503>] ? irq_exit+0x44/0x75
[ 2839.337625]  [<ffffffff810032b5>] ? do_IRQ+0x94/0xad
[ 2839.337631]  [<ffffffff812e10a7>] ? common_interrupt+0x67/0x67
[ 2839.337634]  <EOI>  [<ffffffff81163f07>] ? intel_idle+0xde/0x103
[ 2839.337645]  [<ffffffff81163ee3>] ? intel_idle+0xba/0x103
[ 2839.337652]  [<ffffffff81220bfa>] ? cpuidle_idle_call+0x7e/0xc4
[ 2839.337659]  [<ffffffff81008e92>] ? cpu_idle+0x53/0x7c
[ 2839.337663] ---[ end trace 04a2b9c09e9d7860 ]---
[ 2839.341697] r8169 0000:01:00.0: eth1: link up

Regards
Tomas


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html