Forwarding to the bug log. Will respond in a separate message.
--- Begin Message ---
Thanks but I haven't seen this in a while and my initial report is now a year
old, almost to the day. So, forget it and close this up I guess, thanks for
the follow up!
Jeffrey
Jeffrey Thomas (please, not 'Jeff')
Senior Systems Technician
Technical Operations
The Nerdery
(952) 567.6346 // office
(952) 948.1611 // fax
http://nerdery.com/Jt
=== === ===
When we all ██████, what could possibly go wrong?
On Thursday, February 09, 2012 05:52:40 PM you wrote:
> Hi Jeffrey,
>
> Jeffrey G Thomas wrote:
>
> > Running linux-image-2.6.32-5-686-bigmem but also when reverting back
> > to older kernels (including, I believe, 2.6.30-2-686) I have lost
> > networking a number of times over the last 2 days. In every
> > instance but one, I had this (or similar) in my 'dmesg' output
> > (sorry, i only saved one so far):
> [...]
> > [ 127.550661] hda-intel: IRQ timing workaround is activated for card #1.
> > Suggest a bigger bdl_pos_adj.
> > [ 2214.170019] atl1c 0000:03:00.0: irq 27 for MSI/MSI-X
> >
> > [ 2214.170084] atl1c 0000:03:00.0: atl1c: br0 NIC Link is Up<100 Mbps Full
> > Duplex>
> > [ 2223.964017] ------------[ cut here ]------------
> >
> > [ 2223.964024] WARNING: at
> > /build/buildd-linux-2.6_2.6.32-9-i386-0BnCTJ/linux-2.6-2.6.32/debian/build/source_i386_none/net/sched/sch_generic.c:261
> > dev_watchdog+0xbd/0x15d()
> > [ 2223.964027] Hardware name: System Product Name
> >
> > [ 2223.964029] NETDEV WATCHDOG: br0 (atl1c): transmit queue 0 timed out
> >
> [...]
> > 03:00.0 Ethernet controller [0200]: Atheros Communications AR8131 Gigabit
> > Ethernet [1969:1063] (rev c0)
>
> Thanks for reporting it. I think our best hope of solving this would
> be to report it upstream.
>
> So:
>
> - can you reproduce this?
> - can you reproduce this with a 3.x.y kernel from sid or experimental?
> (The only packages needed for such a test from outside squeeze should
> be the kernel image itself, linux-base, and initramfs-tools.)
> - please attach full "dmesg" output from booting an affected kernel
> (and reproducing the problem, if possible).
>
> If the problem is present in 3.x.y kernels, we can check if there are
> any relevant fixes upstream newer than the kernel you test (there
> probably won't be) and pass this upstream. If it isn't present in
> 3.x.y, we can try some kernels halfway between to narrow down when the
> fix was introduced and try applying the same patch to squeeze.
>
> Hope that helps,
> Jonathan
>
--- End Message ---
