Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
I tested with 2.6.37-rc3. Nothing changes. Still the same kind of crashes. I also played with all combinations of ACPI and APM but no change. I searched a while and noticed the error already exists: Bug#454747 Bug#11663 Bug#584724 As pointed out though, the original scheduling while atomics oops of this bug number seems to be solved. Narcel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0211b4.4030...@gmx.net
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
dmesg output [ 861.86] WARNING: at /build/buildd-linux-2.6_2.6.32-27-i386-c5N4Hf/linux-2.6-2.6.32/debian/build/source_i386_none/net/sched/sch_generic.c:261 dev_watchdog+0xdb/0x170() [ 861.000115] NETDEV WATCHDOG: eth1 (via-rhine): transmit queue 0 timed out [ 861.000129] Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables tun rfcomm sco bridge stp bnep l2cap crc16 fuse arc4 ath5k mac80211 ath cfg80211 led_class hwmon_vid loop snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq ecb snd_timer snd_seq_device aes_i586 aes_generic snd btusb geode_aes bluetooth soundcore rfkill evdev cdc_acm ac geode_rng processor button pcspkr snd_page_alloc rng_core cs5535_gpio usbhid hid usb_storage ext3 jbd mbcache nbd sd_mod crc_t10dif ata_generic pata_cs5536 ohci_hcd pata_amd ehci_hcd libata via_rhine thermal usbcore thermal_sys mii scsi_mod nls_base [last unloaded: scsi_wait_scan] [ 861.000473] Pid: 0, comm: swapper Not tainted 2.6.32-5-486 #1 [ 861.000487] Call Trace: [ 861.000515] [c1022479] ? warn_slowpath_common+0x5e/0x8a [ 861.000539] [c11cc5c7] ? dev_watchdog+0x0/0x170 [ 861.000563] [c10224d7] ? warn_slowpath_fmt+0x26/0x2a [ 861.000587] [c11cc6a2] ? dev_watchdog+0xdb/0x170 [ 861.000619] [c10064fa] ? pit_next_event+0x18/0x1c [ 861.000645] [c103c995] ? clockevents_program_event+0xbd/0xcb [ 861.000672] [c103d5f0] ? tick_dev_program_event+0x1e/0x80 [ 861.000703] [c102b3fe] ? run_timer_softirq+0x156/0x1cd [ 861.000735] [c10269fb] ? __do_softirq+0x8e/0x130 [ 861.000761] [c1026acd] ? do_softirq+0x30/0x3b [ 861.000785] [c1026b8c] ? irq_exit+0x25/0x53 [ 861.000808] [c1004211] ? do_IRQ+0x66/0x76 [ 861.000832] [c1003790] ? common_interrupt+0x30/0x40 [ 861.000858] [c1013d28] ? native_safe_halt+0x2/0x3 [ 861.000881] [c1007758] ? default_idle+0x37/0x55 [ 861.000903] [c1002363] ? cpu_idle+0x6a/0x83 [ 861.000927] [c1366714] ? start_kernel+0x2ea/0x2ef [ 861.000943] ---[ end trace 30d26edd26f93a3c ]--- [ 861.001106] eth1: Transmit timed out, status , PHY status 786d, resetting... [ 861.001924] eth1: link up, 100Mbps, full-duplex, lpa 0x4DE1 Looks like Ubuntu has the same issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454747 Bug seems to exist for a long time now. Should be fixed before Squeeze gets out officially! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf11d31.1010...@gmx.net
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
Marcel Langner marcel.lang...@gmx.net writes: Bug seems to exist for a long time now. Should be fixed before Squeeze gets out officially! 1) Are the scheduling while atomic and transmit timed out different bugs? 2) Have you tried if this occurs with mainline kernel from kernel.org? I have a geode box with $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 498.106 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow bogomips: 996.21 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: and via-rhine $ dpkg-query -W linux-image-2.6.32-5-486 linux-image-2.6.32-5-4862.6.32-27 that sometimes goes to an odd state. Under lenny: fomalhaut:~$ ping -i 0.2 garfield 64 bytes from garfield.lan (10.7.3.37): icmp_seq=15 ttl=64 time=0.366 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=1 ttl=64 time=2914 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=2 ttl=64 time=2705 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=3 ttl=64 time=2497 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=4 ttl=64 time=2289 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=5 ttl=64 time=2081 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=6 ttl=64 time=1874 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=7 ttl=64 time=1666 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=8 ttl=64 time=1458 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=9 ttl=64 time=1250 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=10 ttl=64 time=1042 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=11 ttl=64 time=834 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=12 ttl=64 time=626 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=13 ttl=64 time=418 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=14 ttl=64 time=210 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=16 ttl=64 time=9344 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=17 ttl=64 time=9137 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=18 ttl=64 time=8929 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=19 ttl=64 time=8721 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=20 ttl=64 time=8513 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=21 ttl=64 time=8305 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=22 ttl=64 time=8098 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=23 ttl=64 time=7890 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=24 ttl=64 time=7681 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=25 ttl=64 time=7474 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=26 ttl=64 time=7266 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=27 ttl=64 time=7058 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=28 ttl=64 time=6850 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=29 ttl=64 time=6642 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=30 ttl=64 time=6434 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=31 ttl=64 time=6226 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=32 ttl=64 time=6018 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=33 ttl=64 time=5811 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=34 ttl=64 time=5603 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=35 ttl=64 time=5395 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=36 ttl=64 time=5186 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=37 ttl=64 time=4979 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=38 ttl=64 time=4771 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=39 ttl=64 time=4563 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=40 ttl=64 time=4355 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=41 ttl=64 time=4147 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=42 ttl=64 time=3939 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=43 ttl=64 time=3732 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=44 ttl=64 time=3524 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=45 ttl=64 time=3316 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=46 ttl=64 time=3108 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=47 ttl=64 time=2900 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=48 ttl=64 time=2692 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=49 ttl=64 time=2484 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=50 ttl=64 time=2276 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=51 ttl=64 time=2068 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=52 ttl=64 time=1860 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=53 ttl=64 time=1652 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=54
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
Marcel Langner marcel.lang...@gmx.net writes: Does a report exists for this transmit timeout problem already? I don't know. I have hit the issue only twice and it is difficult to debug so I did not report it yet. No I have not. Do you think it makes sense to try it? It's a long time since I compiled my own kernel. I think that is needed. If it works with mainline kernel then we can start looking for the patch that fixed it. If it doesn't work then you can report the bug upstream. btw, always keep 575...@bugs.debian.org in Cc so that the bug discussion is not lost. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/847hfyn49g@sauna.l.org
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
I think that is needed. If it works with mainline kernel then we can start looking for the patch that fixed it. If it doesn't work then you can report the bug upstream. I guess I will then. Thanks for sharing. Nice to know, there are others with the same rare issues. Marcel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf12eec.7080...@gmx.net
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
Network just crashed again. I will compile/install the new kernel first and try copying again. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf13f71.2030...@gmx.net
