WLAN Broadcom BCM4313, NDIS, Kernel Panic

V

Vril

Well-Known Member
Da es leider für bcm4313 keine Treiber gibt habe ich versucht
mit ndisgen etwas Brauchbares aus den Windows-Treibern zu
basteln ( FreeBSD 11.0-RELEASE )

Das Laden des damit fabrizierten Kernel-Moduls crasht das System
( panic: IRQL_NOT_GREATER_THAN )

Mit diesem Problem bin ich lt. google nicht alleine -
es gibt Tipps für FreeBSD 10, dass man statt ndisgen
den NDISulator
https://github.com/NDISulator/ndisulator
zum Treiber-friemeln nutzen soll.

Hat da schon jemand Erfahrungen, ob dann was 'Stabiles'
dabei entsteht?

Gruss walter
 
Das panic(9)[/code] ist ein Resultat, dass eine Komponente im Kontext eines Interruptes bzw. Ressourcen (im Kontext zum "Treiber" bzw. Devices) zur Laufzeit beanspruche, auf die die Komponente im Kontext zur Diensterbringung nicht zugreifen duerfe, da (moeglicherweise) irgenwo ein anderer Kernel Thread einen sogenannten [url=https://www.freebsd.org/cgi/man.cgi?query=locking&sektion=9&manpath=FreeBSD+10.3-RELEASE+and+Ports]Lock im Konttext einer Mutual Exclusion beansprucht bzw. hielte, d. h. verschiedene Kernel Threads fordern in diesem Kontext Diensterbringung seitens des Devices
Code: 
void
KfLowerIrql(uint8_t oldirql)
{
   if (oldirql == DISPATCH_LEVEL)
        return;

    if (KeGetCurrentIrql() != DISPATCH_LEVEL)
       panic("IRQL_NOT_GREATER_THAN");

    mtx_unlock(&disp_lock[curthread->td_oncpu]);
    sched_unpin();
}
bzw.
Code: 
uint8_t
KeGetCurrentIrql()
{
    if (mtx_owned(&disp_lock[curthread->td_oncpu]))
        return (DISPATCH_LEVEL);
    return (PASSIVE_LEVEL);
}
Hierbei verhaelt es sich wie mit einer sogenannten "Herdplatte", denn der die o. g. Funktion aufrufende Thread verbrennt sich gewaltig die Finger an dieser, da er nicht berechtigt sei diese anzufassen, wenn er denn einen "Lock" halten wuerde, da die Mutual Exclusion dem Dienstnehmer 9moeglicherweise) zusichere, dass die Herdplatte nicht gluehen wuerde. Eine alternative "Analogie" waer' das Bildnis vom Staffellaeufer, der einen Stab halten wuerde.

Ich denke mal, irgendwo hat sich moeglicherweise ein sich rekursiv verhaltener Lock "eingeschlichen", welcher nicht mit mtx_unlock(9) (vor dem Aufruf von mtx_lock(9)) aufgeloest bzw. freigegeben wurde, denn in den Zieten von SMP ist es halt ein bisschen "stuermischer" geworden bzgl. dem Implementieren von Komponenten, die im Kernel Space residieren.

Fazit des von mir dargebotenen "Ri-Ra-Rate-Spieles": um diesen Stoerfall zu debuggen, empfiehlt sich LOCK_PROFILING(9) zu realisieren, wenn viel Zeit und Geduld (bzw. Nervenkostuem, denn bei derartigen Ereignissen entstehen oftmals "grosze" emotionale Gefuehls- und Stimmungslagen) vorhanden waeren.

Btw, *imho* empfiehlt es sich vielleicht das NDIS basierte Device durch ein alternatives Device zu ersetzen?[/url]
 
*btw* Ich habe mich beim korrigieren, kurz vor Ablauf von Callout bzgl. 1. Url "vertippt", denn statt _url_ habe ich _code_ im "bb-code-closing-tag" eingegeben, als ich panic(9) mit einen Verweis auf panic(9) "verschoenern" wollte. Ist es vielleicht moeglich das zu aendern und dann diesen (der auf dieses "Missgeschick" verweisendes) Posting zu loeschen?

Korrektur:

Im 3. Absatz enthaltener Phrase
... wenn er denn einen "Lock" halten wuerde, ...
Zum Vergrößern anklicken....
meinte ich
... wenn er denn keinen "Lock" halten wuerde, ...
Zum Vergrößern anklicken....

Sorry, ich habe eine leichte Lese- / Rechtschreibschwaeche. :ugly:
 
FreeBSD hat 11.0 native Unterstützung für diverse neuere Broadcom-WLAN-Chips. Allerdings steht der Code unter der GPLv2, da er aus dem Linux-Kernel übernommen wurde. Entsprechend ist er nicht Teil des normalen Builds und die Nutzung ist frickelig:
  1. Man braucht die Sourcen in /usr/src
  2. cd /usr/src/sys/modules/bwn
  3. In der Makefile die auskommentierten Zeilen (da steht ein Kommentar drüber) einkommentieren
  4. make obj ; make depend ; make ; make install
  5. if_bwn.ko (neu) laden
Dabei aber beachten, dass man sich GPLv2-Code in seinen Kernel linkt. Mit allen Folgen. Privat ist das sicher kein Problem, im kommerziellen Einsatz aber eventuell schon. Vielleicht hilft es uns mittelfristig, dass Broadcom (eigentlich Avago nach Umbenennung) das Wi-Fi Geschäft an Cypress verkauft hat. Die sehen es mit Spezifikationen und freien Treibern etwas lockerer.
 
Yamagi schrieb:
FreeBSD hat 11.0 native Unterstützung für diverse neuere Broadcom-WLAN-Chips. Allerdings steht der Code unter der GPLv2, da er aus dem Linux-Kernel übernommen wurde.,,,
Zum Vergrößern anklicken....


Danke für den Tipp Yamagi ... es funktioniert auch gut, dank Deiner ausführlichen Beschreibung -
aber leider ist bcm4313 nicht dabei :-(

Gruss walter

ps
allerdings habe ich inzwischen noch ein paar Hinweise gefunden, wie die Kernel-Panic beim Laden des mit ndisgen gebildeten
Moduls abzustellen sein könnte ... werde ich am WE mal probieren
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben