unfähig zu "rmmod" das Modul

Ich arbeite mit einer großen Embedded-Software (ARM-Prozessor, Embedded Linux 2.6.31, Busybox) mit Kernel-und User-Space-Code. Es gibt ein Kernelmodul, das normalerweise zuerst geladen wird, und ein Daemon, der netlink Socket mit dem Modul einrichtet.unfähig zu "rmmod" das Modul

Das Problem hierbei ist, dass der Dämon nach der Tötung, ich bin nicht mehr in der Lage das Modul aus dem Speicher zu entfernen:

% rmmod _module.ko 
% rmmod: _module.ko: Resource temporarily unavailable

Analyse, dass Fehler gezeigt hat (Rückgabewert -11, dh EAGAIN?) wird von try_stop_module() zurückgegeben in syscall delete_module() Definition in kernel/module.c. Die Funktion try_stop_module() wiederum ruft stop_machine() auf und hier bin ich stecken geblieben, wie

Ich bin mir nicht sicher, was genau dort passiert. Ich denke, die Ursache ist irgendwo im Daemon, der Verbindungen zum Modul und offensichtlich etwas anderes öffnet und beim Beenden nicht korrekt schließt/aufräumt (anscheinend werden einige Referenzen/Sperren nicht freigegeben?)

Hat jemand Irgendeine Idee, was sonst noch zu sehen und zu prüfen?

Quelle

2012-12-12 Mark

Nur eine blöde Idee ... rmmod -f ... das Entladen erzwingen? –

Zuerst sollten Sie ein Superuser sein, um dies zu tun. Sie können auch rmmod -f verwenden, aber diese Option kann extrem gefährlich sein: Sie hat keine Auswirkungen, es sei denn, wurde festgelegt, als der Kernel kompiliert wurde. Mit dieser Option können Sie Module entfernen, die verwendet werden oder die nicht entfernt werden sollen oder als unsicher markiert wurden.

Lesen Sie auch man rmmod.

Quelle

2012-12-13 10:51:18 ymn

danke für Kommentare. Ich bin mir bewusst, "erzwungenen" Modus, aber auf meiner Plattform busybox rmmod ist nicht mit dieser Option kompiliert, und mein Ziel ist es herauszufinden, welche Deskriptoren noch gehalten werden und es zu beheben, das ist offensichtlich ein Fehler im Modul oder/und der Daemon. – Mark

Noch eine Sache - das Hauptproblem hier ist, dass die Anzahl der Verweise auf das Modul, dh wie viele Prozesse das Modul benutzen (das 3. Feld von/proc/net/modules), nicht Null ist und somit das Modul kann nicht entladen werden. Bevor der Daemon ausgeführt wird, ist der Referenzzähler 0, nach dem Start des Daemon geht der Zähler auf 6 hoch, obwohl ich nur 3 erwarten würde, dass er drei Sockets öffnet. Nachdem der Damon getötet wurde, sinkt der Zähler auf 3 und das Modul kann nicht entladen werden. Gibt es irgendwelche Möglichkeiten zu erfassen, welche anderen Deskriptoren etc. offengehalten werden? – Mark

Überprüfen Sie, ob alle zu Ihrem Modul gehörenden Schnittstellen nicht "up" sind.

Wenn eine der Schnittstellen zu Ihrem Modul 'up' ist, schlägt rmmod fehl und kehrt mit -11 zurück.

Also, bevor rmmod Aufruf die aktiven Schnittstellen überprüfen Befehl ‚netcfg‘. dann mit ifconfig, machen Sie Ihre Schnittstelle als 'ifconfig <interface_name> down'

dann versuchen, rmmod <module_name> ausführen. wird es funktionieren !!

1.netcfg <lists out all interfaces> 
2.ifconfig <interface_name> down 
3.rmmod <module_name>

Quelle

2014-09-02 16:06:12

unfähig zu "rmmod" das Modul

Antwort

Verwandte Themen