| 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
| ||
|
Message-Id: <1236508032.14878.1.camel@morgoth.abyss.4t2.com> 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