Madwifi-Treiber + Kismet = Kernel Panic?!

[-hanky-]

Hi,

ich habe unter Gentoo folgendes Problem:

Meine 54mbit-WLAN-PCMCIA-Karte mit Atheros-Chipsatz funktioniert im Normalbetrieb einwandfrei, doch sobald ich Kismet verwenden möchte bleibt das Programm stehen bei:



Source 0 (atheros): Enabling monitor mode for madwifi_g source interface ath0 channel 6



Danach reagiert der Laptop auf keinerlei Tastatureingaben mehr, wenn ich die Karte aus dem PCMCIA-Slot entferne erhalte ich einen Kernelpanic.

Die Madwifi-Treiber liegen in der aktuellsten Version vor ( CVS vom 14.7 ), ich habe ebenfalls bereits die Versionen aus dem Portage versucht - gleicher Effekt.

Kismet ist Version 2005.04.1-r2, der Kernel ist Version 2.6.12-gentoo-r4. pcmcia-cs liegt in Version 3.2.8-r2 vor.

Mit der Centrino-Karte ( ipw2100 ) habe ich keinerlei Probleme, sie funktioniert im Zusammenhang mit Kismet einwandfrei.

In der kismet.conf ist unter sources eingetragen:

madwifi_g,ath0, atheros

Ich würde die Kernel-Meldung gerne posten, nur leider schmiert der Laptop wie erwähnt ab :(

Auf meinem alten Laptop konnte ich die Karte problemlos unter Kismet nutzen.

-hanky-

[zyrusthc]

Ich würde die Kernel-Meldung gerne posten, nur leider schmiert der Laptop wie erwähnt ab
Na dann schau doch mal in den logs nach . /var/log/messages !
Ob der Kernel da was reingeflüstert hat ;)

gruss Oli

[-hanky-]

Na dann schau doch mal in den logs nach . /var/log/messages !
Ob der Kernel da was reingeflüstert hat ;)

gruss Oli

Nope, nix zu finden :(

-hanky-

[-hanky-]

So,

ich habe mich jetzt nochmal etwas mit dem Problem auseinandergesetzt.

Zunächst habe ich meinen Kernel mit Support für Magic Sysrq kompiliert, um wenigstens die Möglichkeit zu haben den Laptop halbwegs sauber herunterzufahren.

Leider nur mit einem Teilerfolg ( siehe Erläuterung ).

Ich habe daraufhin die Karte eingesteckt und Kismet gestartet, wie erwartet fror der Laptop ein. Ich konnte ihn dann per Sysrq dazu überreden wenigstens die Tastatur freizugeben und in einem Fall sogar dazu, Kismet abzuschiessen. Danach lief der Laptop problemlos weiter, auch ein Aus- und Wiedereinstecken der Karte hatte keine ( negative ) Auswirkung.

Nach dem Abschiessen von Kismet sah ich, dass das Kernellog nur so überquoll vor Meldungen der Art:



ath0: hardware error; resetting


Diese Meldung kam dutzende Male hintereinander, mitgezählt habe ich nicht mehr.

Bei weiteren Versuchen gelang es mir leider nicht, per Sysrq einen Reboot zu verhindern.

Ich habe mittlerweile auch testweise versucht, die Karte vor dem Start von Kismet in den Monitor-Modus zu versetzen und den passenden Kanal selbst einzustellen - leider ohne Erfolg. Kismet fror dann kurz darauf ein.

Das Problem ist ja nicht mal, dass Kismet absemmelt - das Problem ist vielmehr, dass es das ganze System mit reisst! Sobald Kismet hängt habe ich nur noch die Möglichkeit, die Karte aus dem PCMCIA-Slot zu entfernen - und dies führt unweigerlich zum Kernel Panic.

Die neueste, per portage verfügbare, Kismetversion bringt auch keine Abhilfe, ebenso wie sämtliche per portage verfügbaren Madwifi-Versionen ( sowohl aus dem Stable wie auch aus dem unstable-Zweig ).

Mittlerweile ist guter Rat teuer, ich weiß nicht mehr was ich noch machen soll. Im Normalbetrieb funktioniert die Karte zum Glück einwandfrei, für Kismet habe ich notfalls auch noch eine Netgear WG511 ( mit prism54-Chipsatz ) bzw. eine IPW2100.

Auf meinem Barebone, welcher einen PCMCIA-Adapter hat, funktionieren Kismet + Kernel 2.6.12 + Madwifi wunderbar.

Insofern kann das Problem eigentlich nicht mit zwischen Kernel und Madwifi-Treibern bestehen, dagegen spricht wie gesagt die Tatsache dass es auf dem Barebone wunderbar funktioniert und die Tatsache, dass auch ältere Kernelversionen keine Abhilfe schaffen.

Es muss also ein gentoo-spezifisches Problem sein.

Unter [1] habe ich einen konkreten Hinweis gefunden; doch auch ein Abschalten von cpufreq brachte keine Abhilfe, und ein komplettes Entfernen von CPU Frequency Scaling ist nun wirklich keine Alternative auf einem mobilen Computer.

Über Google bekam ich noch den Hinweis, eventuell ACPI zu deaktivieren - leider auch keine mögliche Lösung, da ich ACPI+cpufreq in Kombination verwende und ganz generell nicht auf ACPI verzichten möchte.

-hanky-

[1] http://madwifi.sourceforge.net/dokuwiki/doku.php?id=gentoo&DokuWiki=311534998dd39e9a6f7743fcf48d91f3