gelegentlicher Kernel failure

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
bremer
Beiträge: 49
Registriert: 18.03.2012 16:59:02

gelegentlicher Kernel failure

Beitrag von bremer » 04.04.2012 23:51:13

Gelegentlich erhalte ich einen Kernel failure, was zu deaktiviertem LAN führt. Ich nutze Squeeze fast in seiner ursprünglichen Form. Ich habe kaum etwas geändert außer ein aktuelles Flash-Paket zu installieren.

Gelegentlich heißt, an einem Tag funktioniert es und dann wieder nicht. Ich konnte kein Muster erkennen.
Kernel failure message 1:

------------[ cut here ]------------

WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/net/sched/sch_generic.c:261 dev_watchdog+0xbd/0x15d()

Hardware name: A3G

NETDEV WATCHDOG: eth0 (8139too): transmit queue 0 timed out

Modules linked in: acpi_cpufreq cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave ppdev lp sco bridge stp bnep l2cap crc16 bluetooth rfkill binfmt_misc fuse loop firewire_sbp2 snd_intel8x0m snd_intel8x0 radeon ttm snd_ac97_codec pcmcia ac97_bus 8139too firewire_ohci drm_kms_helper yenta_socket firewire_core usbhid 8139cp snd_pcm rsrc_nonstatic hid drm crc_itu_t pcmcia_core mii i2c_algo_bit snd_seq snd_timer snd_seq_device joydev snd i2c_i801 sg uhci_hcd ipw2200 libipw i2c_core lib80211 soundcore shpchp snd_page_alloc rng_core sr_mod parport_pc video cdrom ehci_hcd usbcore nls_base pci_hotplug parport psmouse output processor button asus_laptop led_class ac battery pcspkr evdev serio_raw ext3 jbd mbcache sd_mod crc_t10dif ata_generic ata_piix libata thermal fan thermal_sys scsi_mod

Pid: 0, comm: swapper Not tainted 2.6.32-5-686 #1

Call Trace:

[<c10309b1>] ? warn_slowpath_common+0x5e/0x8a

[<c11e9988>] ? dev_watchdog+0x0/0x15d

[<c1030a0f>] ? warn_slowpath_fmt+0x26/0x2a

[<c11e9a45>] ? dev_watchdog+0xbd/0x15d

[<c10417a6>] ? insert_work+0x71/0x78

[<c1041b1f>] ? delayed_work_timer_fn+0x0/0x28

[<c103b26c>] ? run_timer_softirq+0x16a/0x1eb

[<c1035afa>] ? __do_softirq+0xaa/0x156

[<c1035bd7>] ? do_softirq+0x31/0x3c

[<c1035cb1>] ? irq_exit+0x26/0x58

[<c10144dd>] ? smp_apic_timer_interrupt+0x6c/0x76

[<c1003b35>] ? apic_timer_interrupt+0x31/0x38

[<c10400e0>] ? sys_setpriority+0x11b/0x1af

[<c101aad4>] ? native_safe_halt+0x2/0x3

[<f7e62de2>] ? acpi_idle_do_entry+0x2d/0x4c [processor]

[<f7e62e59>] ? acpi_idle_enter_c1+0x58/0x97 [processor]

[<c11c7409>] ? cpuidle_idle_call+0x68/0xbb

[<c1002377>] ? cpu_idle+0x89/0xa2

[<c13bb7fc>] ? start_kernel+0x318/0x31d

---[ end trace bc68f0954dbd176b ]---
Gibt es irngendwelche Handbücher, in denen die Bedeutungen der jeweiligen Meldungen hinterlegt sind?

chb
Beiträge: 107
Registriert: 27.02.2012 21:01:28
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Frankfurt am Main

Re: gelegentlicher Kernel failure

Beitrag von chb » 06.04.2012 01:20:36

Hallo bremer,
nach kurzem Zwiegespräch mit Dr. Google scheint mir Deine Situation leider nicht allzu rosig ... seit 2003(!) haben sich wohl viele Benutzer der verschiedensten Linux-Distributionen an diesem Problem abgearbeitet. Der Realtek8139 -Chipsatz (u.l einige ähnliche) sind vermutl. etwas buggy /merkwürdig, die Treibermodule des Kernels anscheinend auch. Dass sinnloser Weise beide Module geladen werden (8139cp und 8139too), wird als typisches Symptom berichtet. 8139cp zu blacklisten scheint alleine aber nicht zu helfen.

Einige Leute hatten Erfolg mit Veränderung NIC-bezogener BIOS-Parameter, andere mit diversen apic /acpi Bootparametern ... evtl hilft dieser Thread [1] oder dieser [2] weiter...Versuch macht kluch.

Interessant scheint dabei, dass (zumindest im Rahmen meiner oberflächlichen Betrachtung) unter den vielen Google-Treffern kein entsprechender Beitrag war, bei dem ein 3.xer Kernel erwähnt wurde - was heißen könnte, dass das Problem mit 8139too.ko mittlerweile behoben ist. Ein Test mit einem möglichst neuen 3.2 oder 3.3er Kernel hört sich imho sinnvoll an, evtl. von einer Live-CD.

Ausserdem gibt es einen Patch für 8139cp.ko von Philip Prindeville [3] [4], da müsstest Du Dich denn ggf. einlesen.

[1] http://www.rootforum.org/forum/viewtopi ... 80&t=45388
[2] http://www.linuxquestions.org/questions ... page2.html
[3] http://www.mail-archive.com/openwrt-dev ... 12370.html
[4] https://dev.openwrt.org/browser/trunk/t ... mode.patch

bremer
Beiträge: 49
Registriert: 18.03.2012 16:59:02

Re: gelegentlicher Kernel failure

Beitrag von bremer » 09.04.2012 03:29:33

Was für ein Bug...

Ich kann das nicht testen, da es nicht reproduzierbar ist. In den jüngeren Bug-Berichten von Ubuntu steht, dass er nicht behoben wird, da die Hardware nicht mehr unterstützt wird.

Apic ab zu stellen, kommt nicht in Frage, soll aber manchmal funktionieren.

Es gibt diverse Berichte, dass der Bug behoben wäre, da er nicht mehr auftauche, aber jene Berichte wurden bis mindestens zur Kernel-Versio 2.6.34 widerlegt.

chb
Beiträge: 107
Registriert: 27.02.2012 21:01:28
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Frankfurt am Main

Re: gelegentlicher Kernel failure

Beitrag von chb » 09.04.2012 08:31:15

Scheinbar hast Du Dich über die wenig erbaulichen Umstände informiert... wenn Die Möglichkeit besteht(?), wäre ein Umstieg auf andere, 'known-to-work' Netzwerkhardware wahrscheinlich die sicherste und stressärmste Lösung...

bremer
Beiträge: 49
Registriert: 18.03.2012 16:59:02

Re: gelegentlicher Kernel failure

Beitrag von bremer » 09.04.2012 15:39:20

Ich warte lieber, ob er wieder auftaucht und wenn ja, dann probier ich's mit 'nem 3.x Kernel.

Habe noch andere OS installiert. Ein Notfall tritt also nicht ein.


Nachtrag:

Ich habe noch dies gefunden: http://ubuntuforums.org/archive/index.p ... 66921.html

Jemand hatte das selbe Problem, da er Windows ebenfalls betrieb. Jenes deaktiviert die NIC um Wake-On-Lan zu deaktivieren. Der Linux-Treiber kann sie aber vielleicht nicht selbst aktivieren.

Um das Problem zu umgehen, soll man Wake-On-Lan nach Herunterfahren im Geräte-Manager aktivieren oder indem man Onboard Lan Boot ROM im BIOS aktiviert. Integrated Peripherals -> Onboard Device -> Onboard Lan Boot ROM.

Da der Fehler zunächst nicht wieder auftgetreten ist, habe ich es aber noch nicht wieder testen können.

Antworten