Rmmod

[Tisham Candella]

Im working with a large embedded software (ARM processor, embedded linux 2.6.31, busybox) involving both kernel and user space code. There's a kernel module normally loaded first, and daemon establishing netlink socket with the module.

I'm not sure what's exactly happening there. I think the root cause is somewhere in the daemon that opens connections to the module and obviously something else and doesn't correctly close/clean-up on exit (apparently some references/locks are not released?)

First of all you should be a superuser to do this. Also you can use rmmod -f but this option can be extremely dangerous: it has no effect unless CONFIG_MODULE_FORCE_UNLOAD was set when the kernel was compiled. With this option, you can remove modules which are being used, or which are not designed to be removed, or have been marked as unsafe.

Also, you can attempt to force the kernel to remove the module with rmmod -f lcd_module. Cautionary note: This can cause system failure depending on what kind of resources your module has a hold of and what state its in when you try to force the removal.

A USB serial UART uses the same chip. The driver will be the same, though I suppose the means of the system learning of the driver might be different. How is the chip wired to the Jetson? Is it a custom carrier board? Is it going to a header pin on the regular dev board?

So, for reference, I just tested the FTDI sample code on a stock Ubuntu 14.04 machine and it worked fine. I unpacked the FTDI bundle, copied the libraries, built the samples, made the rmmod calls, and it the demo application worked on the first try.

in most linux distros it is possible to generate /etc/modprobe.d/blacklist.conf which prevents listed kernel modules from being loaded at boot time and thus not having to resort to the drastic measure of removing the module entirely.

Because often people ask about a specific "how" because they believe this "how" to be necessary to solve their real problem. Often enough, the real problem has solutions that do not require to solve the specific "how". Been there, witnessed that from both sides. Also on the internet nobody needs to answer anything so a person asking questions should be friendly towards all responders, even if unhelpful, they are spending their time on your problem, at least acknowledge that. (That does not mean that you need to agree, but IMHO calls to "stay on topic" are not merited, as you can simply ignore answers you deem unhelpful; if an answer is rude, that is a different issue meriting calling it out)

There is no mentioning of a "problem" and I do not comprehend why this lingual characteristic is being introduced/utilized/argued by either of you? It is a straightforward question which has been exhaustively responded to - making it clear what can and what cannot be done.

Not sure what you are getting exited about and unnecessary heating the thread with such statements? Your telling of what one should do or not could be easily mistaken as patronizing. And I am afraid that is not the first time such mannerism is on display.

-f, --force This option can be extremely dangerous: it has no effect unless CONFIG_MODULE_FORCE_UNLOAD was set when the kernel was compiled. With this option, you can remove modules which are being used, or which are not designed to be removed, or have been marked as unsafe (see lsmod(8)).

Yes, this is part of the issue, people in this forum are quite happy to help solve problems, so if you have a problem come forward. If however you have no acute problem, why waste everybody's time?

Most folks here know, that OpenWrt being a linux distribution tailored to low-end devices does not offer everything big Linux distributions offer, so enumerating all differences seems moot unless such a difference causes real problems ;), but then it helps if the problem is stated along with the difference that makes solutions for "normal" linux distributions inapplicable for OpenWrt.

The why is missing, someone less conscious of the dangers of removing a piece of kernel code where other parts of the same kernel might still hold references to than you, might get wrong ideas about when calling rmmod --force my_module is reasonable. (I admit that modprobe -r seems less dangerous in that it tries to also remove the reference holding modules, but that is subtle).

Look, I am not the forum admin, just a user voicing my own opinion, so I try not to talk about can and shall, but rather could and should. IMHO asking a specific question is fine, but even better if accompanied by a description of why the question is relevant. If you have no problem, maybe do not ask a question in the first place?

Sure, that certainly helps, (except all answers are comments even the off-topic ones ). But this is an open forum, as long as the tone stays friendly you can post almost every question, it is just that people will be better to help if they understand the scope of the question better.

Running the rmmod command fixes (a), but not (b), while blacklisting the module fixes them both, though at the expense of very high CPU utilization(!) that renders the whole system pretty much unusable. At this point, it looks to me that running the rmmod command is the best compromise in this matter.

I inspected into the code, and found the brcmf_blhs_is_bootloader_ready() will be called on both pre-firmware-download and post-watchdog-reset. The first blhs timeout was on rmmod brcmfmac, and the second timeout was on insmod brcmfmac.

3a8082e126