Shell auf Backtrack 4 "hakt"

Moin :)

Vorgeschichte:
Habe mir Backtrack 4 auf mein Lenovo Ideapad S10e installiert.
Nach etlichen Versuchen die Treiber der WLAN Karte [Broadcom BCM4312] zu installierten gescheitert sind [B43, Linux-STA (wl)], habe ich ein Kernelupdate gemacht [von 2.6.26.x zu 2.6.32.x]. Das B43 Treibermodule wird ohne Fehler geladen.

Problem:
Wenn ich "startx" ausführe und in der grafischen Oberfläche dann eine Shell öffne "hakt" diese regelmäßig alle paar Sekunden, was ziemlich nervig ist.
"Haken" heißt in dem Fall das Tastatureingaben für ein paar Sekunden nicht sichtbar sind, jedoch angenommen werden und dann wenn die Konsole wieder reagiert angezeigt bzw. bei "Enter" ausgeführt werden.

Sonstige Hinweise:
Dieser Kernel wird offiziel nicht von Backtrack 4 unterstützt und deswegen bekomme ich im zugehörigem Forum kein Support.

Ich hoffe mir kann jemand helfen.
Falls keiner eine Idee hat, werde ich versuchen den Kernel noch weiter zu "updaten".

MFG
bl0xx :P
 
Danke für deine Antwort. :)

Das Lustige ist, dass dieses Problem seit jetzt gerade nicht mehr besteht. [5min reibungslos Befehle eingetippt]
Das Netbook wurde seit dem letzten Auftreten des Fehlers nicht mehr gestartet, nur gerade zum gucken was in der Xorg.0.log steht.

Hoffentlich bleibt es nicht bei einem "Vorführungseffekt".
Teste das nochmal ausgiebig und halte dich/euch auf dem Laufendem.

Erkennst du irgendwelche Probleme in dem log? [als .txt angehangen]

MFG
bl0xx
 
Zuletzt bearbeitet:
Ja - sollte dir aber als bt4 user keine Probleme bereiten das selbst in dem logfile zu finden :D:D

Bin ja nicht so:
Code:
grep EE /var/log/Xorg.0.log
gibt dir die nötigen Infos.

Danke, sehr gnädig ;) Also besteht ein Problem mit dem DMA Treiber von Intel ?! Dann werde ich mich mal auf machen und googeln :) Habe herrausgefunden, dass dieses haken erst auftritt nachdem ich mit dem Befehl "iwlist scanning" versuche nach WLAN-Netzen zu scannen. Nach Auführen des Befehl entsteht ein Prozess mit Status D (uninterruptable). Diesen kann ich auch wegen seinem Status auch nicht mit "kill" beenden. Nach ca. 10 Minuten verschwindet der Prozess und die Shell läuft wieder flüssig. Bin mir auch nicht sicher ob der Treiber jetzt überhaupt funktioniert, denn Scannen kann ich ja offensichtlich nciht. Hab die interessanten Logs mal als Anhänge hinzugefügt.
 
Zurück
Oben