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]
Date:	Sun, 08 Mar 2009 11:27:11 +0100
From:	Tom Weber <l_linux-kernel@...l2news.4t2.com>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	Michael Büker <m.bueker@...lin.de>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.27.19 + 28.7: network timeouts for r8169 and 8139too

[sorry if you get duplicates, my first try got blocked by vger because
my mailer jumped into stupid HTML mode]

Am Mittwoch, den 04.03.2009, 23:43 +0100 schrieb Francois Romieu: 
> Michael Büker <m.bueker@...lin.de> :
> [...]
> > With both 2.6.27.19 and 2.6.28.7, I am experiencing "transmit timed out" 
> > errors as reported by the netdev watchdog, for both my PCMCIA Ethernet 
> > adapters, using the r8169 and 8139too drivers respectively.
> 
> Can you describe the symptoms a bit more specifically ?
> 
> The kernel displays a scary warning, I can guess that it is almost surely
> associated with some loss of network connectivity for a few seconds at the
> very least but it is a bit hard to figure the real scale of your problem.
> 
> Please scare me. :o)

I'm also experiencing these transmit time outs with the r8169 Driver on
an Asus M3A-H/HDMI Board - 32bit mode.

Happens at least with 2.6.28, 2.6.28.4, 2.6.28.6 and 2.6.29-rc7.

This is a diskless box (on NFS) on GigE LAN, used for DVB-S
recordings/playback with vdr. I first suspected problems with the DVB
Stuff since I have minor issues there too, but now that I've digged
around in the list I think that's unrelated.

Every once in while, more likely with heavy usage of the vdr stuff (like
recording two shows and/or cutting a recording) these show up. Of course
the impact is realy bad on a diskless system. It takes the system from
10 seconds to 3 minutes to recover.

With 2.6.29-rc7 i just tried to trigger this by moving data (dd from and
to NFS. rsync via ssh). All I managed to get was one 
[61534.002671] r8169: eth0: link up
in dmesg while moving around 20GB.

I've found a couple of other, similar r8169 related bugreports here and
I don't know whats the progress there. If I can help with more
information or testing, just tell me what to do.

this is with 2.6.29-rc7: 
[44469.085035] nfs: server 192.168.1.8 not responding, still trying
[44469.677055] nfs: server 192.168.1.8 not responding, still trying
[44529.997057] ------------[ cut here ]------------
[44529.997065] WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0x1f1/0x200()
[44529.997071] Hardware name: System Product Name
[44529.997075] NETDEV WATCHDOG: eth0 (r8169): transmit timed out
[44529.997079] Modules linked in: autofs4 powernow_k8 cpufreq_stats cpufreq_ondemand cpufreq_conservative cpufreq_performance freq_table pci_slot sbs ac battery video backlight output sbshc container sbp2 loop lnbp21 stv0299 snd_hda_codec_atihdmi snd_seq_dummy snd_hda_codec_realtek snd_seq_oss snd_seq_midi snd_hda_intel snd_rawmidi snd_hda_codec snd_pcm_oss snd_seq_midi_event snd_mixer_oss dvb_ttpci dvb_core snd_seq snd_pcm saa7146_vv saa7146 videobuf_dma_sg rtc_cmos videobuf_core videodev snd_seq_device rtc_core snd_timer v4l1_compat rtc_lib evdev ttpci_eeprom wmi serio_raw snd psmouse k8temp button i2c_piix4 pcspkr soundcore i2c_core snd_page_alloc af_packet pata_acpi ata_generic sg sr_mod cdrom pata_atiixp ehci_hcd ahci ohci1394 ohci_hcd ieee1394 libata scsi_mod usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_snapshot dm_mod thermal processor fan thermal_sys hwmon fuse
[44529.997208] Pid: 0, comm: swapper Not tainted 2.6.29-rc7 #1
[44529.997213] Call Trace:
[44529.997226]  [<c0229587>] warn_slowpath+0x87/0xe0
[44529.997233]  [<c024a779>] tick_program_event+0x39/0x50
[44529.997241]  [<c024230e>] hrtimer_interrupt+0xee/0x250
[44529.997250]  [<c021cbf0>] place_entity+0x40/0xb0
[44529.997255]  [<c021eb7f>] enqueue_entity+0x11f/0x190
[44529.997261]  [<c021ee1e>] enqueue_task_fair+0x2e/0x90
[44529.997268]  [<c0243d5d>] sched_clock_cpu+0x14d/0x1a0
[44529.997276]  [<c04b0bfd>] _spin_lock+0xd/0x30
[44529.997283]  [<c0369d1f>] strlcpy+0x1f/0x60
[44529.997289]  [<c0419711>] dev_watchdog+0x1f1/0x200
[44529.997294]  [<c021db7e>] __wake_up+0x3e/0x60
[44529.997302]  [<c0232f8d>] cascade+0x5d/0x80
[44529.997308]  [<c0233160>] run_timer_softirq+0x130/0x1f0
[44529.997314]  [<c0419520>] dev_watchdog+0x0/0x200
[44529.997320]  [<c0419520>] dev_watchdog+0x0/0x200
[44529.997326]  [<c022ec3f>] __do_softirq+0x7f/0x130
[44529.997332]  [<c022ed45>] do_softirq+0x55/0x60
[44529.997337]  [<c022ef45>] irq_exit+0x75/0x90
[44529.997346]  [<c0212eb7>] smp_apic_timer_interrupt+0x67/0xa0
[44529.997353]  [<c0203b00>] apic_timer_interrupt+0x28/0x30
[44529.997360]  [<c0209292>] default_idle+0x42/0x50
[44529.997367]  [<c020941f>] c1e_idle+0x2f/0xf0
[44529.997372]  [<c0202353>] cpu_idle+0x63/0xa0
[44529.997381]  [<c04ac293>] start_secondary+0x19e/0x2eb
[44529.997386] ---[ end trace 41b1e5c0ec95bcd1 ]---
[44530.008513] nfs: server 192.168.1.8 OK
[44530.008984] r8169: eth0: link up
[44540.508051] nfs: server 192.168.1.8 not responding, still trying
[44568.832060] nfs: server 192.168.1.8 not responding, still trying
[44650.011418] nfs: server 192.168.1.8 OK
[44650.012137] nfs: server 192.168.1.8 OK

attached is the config, dmesg after booting and lspci -vx

  Tom



View attachment "config" of type "text/plain" (79790 bytes)

View attachment "dmesg" of type "text/plain" (36679 bytes)

View attachment "lspci_vx" of type "text/plain" (15516 bytes)

Powered by blists - more mailing lists