[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#613874: [2.6.32.y atl1c] Network crashes and doesn't recover



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



Reply to: