I observed strange behavior from the ipw3945 wireless on resume from hibernate-ram, using suspend2-sources-2.4.20-r3. I wasn't sure what was causing it, but then I came across bug #167420, and I noticed hibernate-script uses rmmod module unloading command as opposed to modprobe -r which causes problems with driver unloading and loading due to the daemon dependency. Is there a fix for this either through modification of the hibernate-script or a hibernate-ram.conf option that would automatically unload and reload the driver correctly during hibernation? Reproducible: Always Steps to Reproduce: 1.Execute hibernate-ram 2.Resume from hibernation 3. Actual Results: Wireless connection fails to reconnect. Driver must be manually unload with modprobe -r ipw3945 and reload modprobe ipw3945 to restart the interface. Expected Results: Wireless connection successfully reactivates after resume.
Yup, the bug is in hibernate-script -- I'll attach a patch shortly.
Created attachment 116580 [details, diff] /home/jkt/hibernate-script.patch
This should be probably reported upstream as well. Sorry for bugspam, I should learn how to CC myself :).
From CHANGELOG: 1.06 (4 April 2005) - Use rmmod, not modprobe -r. (Ivo Prikryl) I recheck it, and it unloads all dependencies. Please reopen if you see dependencies not unloaded.
(In reply to comment #4) > I recheck it, and it unloads all dependencies. > Please reopen if you see dependencies not unloaded. Because it doesn't call modprobe, it doesn't process /etc/modprobe.conf, so it doesn't start/stop ipw3945d upon module load/unload. If it isn't stopped & started, wireless connectivity doesn't work.
Please read the FindModuleDeps() function in /usr/share/hibernate/scriptlets.d/modules You will notice that it parses /proc/modules in order to do the job. The problem is with the wireless daemon... I've provided correct configuration in bug#158420. If you believe this function is incorrect, then I will fix it... Please close as soon as you test it.
Created attachment 116830 [details] deps In order to help you attached a shell script of this function.
(In reply to comment #6) > You will notice that it parses /proc/modules in order to do the job. There's no problem with module dependancies, I was probably unclear on that. > The problem is with the wireless daemon... I've provided correct configuration > in bug#158420. Well, some time ago, ipw3934/ipw3945d ebuilds were changed to configure modprobe to execute `/etc/init.d/ipw3945d start` when the ipw3945 module is loaded and call `/etc/init.d/ipw3945d stop` when it's unloaded. ipw3945 is fancy HW whose kernel driver needs user-space daemon to work properly. From a user's POV, everything works -- when the module gets loaded (be it via udev, modules.autoload.d or by hand), daemon starts for him, when the module is about to be unloaded, regulatory daemon is stopped just before. All that works *only* if user uses `modprobe -r` for unloading. If he runs `rmmod`, stuff breaks. See /usr/portage/net-wireless/ipw3945d/files/ipw3945d-1.7.22-modprobe.conf for details about what's going on here. Surely we can use hibernate-script's hooks to unload the module by hand, but why? There's already one place to specify such actions, modprobe uses it and supports it very well. There's really no need for users to configure yet another item... It's a bad idea to mix `insmod` with `modprobe -r` or `rmmod` with `modprobe`. Udev uses `modprobe`, hiebrnate-script mixes them.
There was probably a good reason why upstream dropped modprobe -r. So I think it is better to have a specific configuration for ipw3495, until the new driver (the one which does not use the daemon) will be ready.
BTW: Why does udev behaves any different if rmmod or modprobe -r? Shouldn't it a udev bug?!?!?!
(In reply to comment #7) > Created an attachment (id=116830) [edit] > deps > > In order to help you attached a shell script of this function. > Thanks for the patch Alon. I apologize for not being to test this sooner. Another beginner question, how do I apply the patch?
(In reply to comment #9) > There was probably a good reason why upstream dropped modprobe -r. I've mailed hibernate-devel. > So I think it is better to have a specific configuration for ipw3495, until the > new driver (the one which does not use the daemon) will be ready. I disagree. ipw3945 uses well-known modprobe functionality. If hibernate-script doesn't support it, it's hiebrnate-script that should be fixed, not module. (In reply to comment #10) > BTW: Why does udev behaves any different if rmmod or modprobe -r? > Shouldn't it a udev bug?!?!?! Nothing's broken with udev. It's hibernate-script's `rmmod` that leaves crap behind. CCing kernel as they're probably best people to know about how we should deal with modules :).
(In reply to comment #12) > (In reply to comment #10) > > BTW: Why does udev behaves any different if rmmod or modprobe -r? > > Shouldn't it a udev bug?!?!?! > > Nothing's broken with udev. It's hibernate-script's `rmmod` that leaves crap > behind. Got no real answer here. I don't beleive udev should behave any different if a module is unloaded by different ways. The rule should be simple, if a module is loaded, run the daemon, if it unloaded unload the daemon. Why does it care how the module is loaded/unloaded?
Well, did not get any response. When a gentoo developer opens and reopen a bug (especially gentoo developer 0, I expect some cooperation. Closing this again, until someone can explain me why it is really needed.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > BTW: Why does udev behaves any different if rmmod or modprobe -r? > > > Shouldn't it a udev bug?!?!?! > > > > Nothing's broken with udev. It's hibernate-script's `rmmod` that leaves crap > > behind. > > Got no real answer here. > I don't beleive udev should behave any different if a module is unloaded by > different ways. The rule should be simple, if a module is loaded, run the > daemon, if it unloaded unload the daemon. > Why does it care how the module is loaded/unloaded? Not sure what are you asking about, sorry. Perhaps you can try to rephrase your question a bit? Udev doesn't use any special magical way to remove module, it "just" calls `modprobe -r`, which reads its configuration file and stops the respective daemon. OTOH, `rmmod` doesn't read any modprobe's configuration files, so it leaves the daemon running. (In reply to comment #14) > Well, did not get any response. > When a gentoo developer opens and reopen a bug (especially gentoo developer > 0, I expect some cooperation. As I stated in comment #12, I've mailed the upstream of hibernate script. You're on that list as well so I guess you read my request as well as Nigel's reply in which he states that he's willing to change it to `modprobe -r` if nobody objects. As some time has passde by now, I'll remind him and try to get this merged upstream. > Closing this again, until someone can explain me why it is really needed. I've tried to address that in my earlier responses, but let me do it once again: We have a daemon that *must* be started right after you load some module and stopped just before you unload the module. You can load module in two ways, either by `modprobe` or by `insmod`, "insmod" being the older way. You can unload it in another two ways -- either by `rmmod` or by `modprobe`. Modprobe has some new features like dependancy resolving and also its configuration file where you can ask it to run a specific action upon module load/unload. This action is executed by the modprobe process, so if you use insmod/rmmod, it won't be executed, unless you do it manually. Now suppose you use `modprobe` for module loading and `rmmod` for module unloading and your modprobe conf specifies that you want to run `foo start` upon module load and `foo stop` upon unload of the module in question. `modprobe foo; rmmod foo; modprobe foo; rmmod foo` effectively results in `foo start; modprobe foo; rmmod foo; foo start; modprobe foo; rmmod foo`. See that the "foo start" is actually executed twice and never stopped? As a side note, expecting a reply in three days is, er, unreallistic in Gentoo land.
> As a side note, expecting a reply in three days is, er, unreallistic in Gentoo > land. 3 days? since comment#10???? Come-on.
(In reply to comment #16) > 3 days? since comment#10???? Come-on. Nope, three days between #13 and #14. I tried to answer your question in comment #12. I'm sorry if I answered something else, but I have problems parsing comment #10. I'm still not sure what you mean by it, sorry. It's my fault that I wasn't clear and brought udev to this discussion -- udev doesn't unload modules. I just tried to address the issue of mixing `modprobe` (from both udev & hibernate-sciprt for module loading) and `rmmod` (from hibernate-script for module unloading) calls. Comment #15 should be understandable enough, but if you show up on IRC, I'll happily elaborate on it.
I regret to say that you still did not answer my question. Why can't you create a udev rule to execute and stop the daemon when a specific module is loaded or unloaded? I almost sure that this can be done. And if it can be done, it is better, since you won't care if anyone use rmmod or modprobe -r.
(In reply to comment #18) > Why can't you create a udev rule to execute and stop the daemon when a specific > module is loaded or unloaded? Thanks for rephrasing, now I finnaly understand what are you asking about. > And if it can be done, it is better, since you won't care if anyone use rmmod > or modprobe -r. False. My aim is to tie up two things together: a) module load & service start b) module unload & service stop Surely I could ask udev to load the module and then start the daemon, but that wouldn't solve the problem of module unload. I'd have to stop the service by hand and restart it later. And when I want to use ipw3945 again after that, I'd have to load the module and then start the daemon. The other way to solve this problem is by using modprobe *only* and preventing any possible issues.
Hi all. The reason the hibernate script uses rmmod is so that it can end up with the same modules loaded post-resume as were loaded pre-suspend. I believe there are really two problems here. The first is (as already said) that modprobe -r runs scripts where as rmmod doesn't. The other is that modprobe -r unconditionally removes now unused modules upon which the modprobe -r'd module depends. I think a correct solution would be to give modprobe -r an option to not do this additional unloading, and make rmmod equivalent to modprobe -r (or modprobe -r with this other new option).
(In reply to comment #20) > The reason the hibernate script uses rmmod is so that it can end up with the > same modules loaded post-resume as were loaded pre-suspend. Thanks for clarification. Is this really needed? If `modprobe -r` really removes only unneeded modules that current module depends on, they'd be loaded back upon next module load anyway (ie. when resuming), wouldn't they?
I thought you might ask that :) For real devices, yeah, I don't think it matters so much. But this is the area where I'm not an expert and therefore wanted the input of others. Leaving things as they were seems safest, and even if we end up agreeing that rmmod is wrong, I'd still argue that having different behaviour is wrong. Where I know it does matter is the code that loads and unloads the Suspend2 modules. We really want to leave that as it was because if you rmmod suspend_core, all of the sysfs entries disappear. Since the userspace utils (apart from the hibernate script) don't yet (and maybe won't ever) know to try modprobe suspend_core in checking for Suspend2 support, if we don't leave things as they are, a first attempt at suspending might work, but a second might fail just because modules aren't loaded that need to be loaded. Having said that, these uses of rmmod and insmod are separate to the others.
I must say I agree with Nigel. And since there is a quick workaround for this specific ipw3945 issue, I am for leaving things as they are now.
(In reply to comment #22) > For real devices, yeah, I don't think it matters so much. But this is the area > where I'm not an expert and therefore wanted the input of others. Bither am I, but I'd say "hey, be brave and try the change. If you get bugreports, revert back while they are anre't fixed", but I can understand you might not like it :). > Leaving > things as they were seems safest, and even if we end up agreeing that rmmod is > wrong, I'd still argue that having different behaviour is wrong. OTOH, one could also think that if modprobe's authors decided to implement this "auto-cleanup" functionality and haven't bothered to provide a switch to turn it off, they probably had a reason for it and *this* behavior is the "right one" ;). > Where I know it does matter is the code that loads and unloads the Suspend2 > modules. We really want to leave that as it was because if you rmmod > suspend_core, all of the sysfs entries disappear. I might be completely wrong here, but why would one attempt to remove this module? `modprobe -r` wouldn't remove it when trying to remove regular modules, would it? (In reply to comment #23) > And since there is a quick workaround for this specific ipw3945 issue, I am for > leaving things as they are now. Just for the record, the workaround is (according to Thomas De Schampheleire <patrickdepinguin@gmail.com>) this: OnSuspend 20 modprobe -r ipw3945 OnResume 20 modprobe ipw3945 If hibernate-script doesn't switch to `modprobe -r`, we'll probably have to ask users to add this to the common.conf on their own, which means yet another step in getting their wifi card to work.
(In reply to comment #24) >> For real devices, yeah, I don't think it matters so much. But this is the area >> where I'm not an expert and therefore wanted the input of others. > >Bither am I, but I'd say "hey, be brave and try the change. If you get >bugreports, revert back while they are anre't fixed", but I can understand you >might not like it :). >> Leaving >> things as they were seems safest, and even if we end up agreeing that rmmod is >> wrong, I'd still argue that having different behaviour is wrong. >OTOH, one could also think that if modprobe's authors decided to implement this >"auto-cleanup" functionality and haven't bothered to provide a switch to turn >it off, they probably had a reason for it and *this* behavior is the "right >one" ;). Possibly, but if we can question the logic in having it this way in the hibernate script, surely we can also question the modprobe authors' logic too? >> Where I know it does matter is the code that loads and unloads the Suspend2 >> modules. We really want to leave that as it was because if you rmmod >> suspend_core, all of the sysfs entries disappear. >I might be completely wrong here, but why would one attempt to remove this >module? `modprobe -r` wouldn't remove it when trying to remove regular modules, >would it? We autoload the suspend_* modules in preparation for suspending. If we later try to modprobe -r the ones that are loaded, and (for example) the core was the only module loaded at the start, it will get unloaded too. (In reply to comment #23) >> And since there is a quick workaround for this specific ipw3945 issue, I am for >> leaving things as they are now. >Just for the record, the workaround is (according to Thomas De Schampheleire ><patrickdepinguin@gmail.com>) this: > >OnSuspend 20 modprobe -r ipw3945 >OnResume 20 modprobe ipw3945 > >If hibernate-script doesn't switch to `modprobe -r`, we'll probably have to ask >users to add this to the common.conf on their own, which means yet another step >in getting their wifi card to work. Yeah, I don't like this either. I would suggest that we go to the maintainers of modprobe/rmmod and discuss the issue with them.
As per Bernard response. Not a Gentoo issue. If modprobe will be fixed this issue will just go away.
I submitted a patch to module-init-tools' upstream to support non-recursive behaviour. No response yet though. http://dmesg.printk.net/pipermail/mit-devel/2007-May/000016.html
*** Bug 199650 has been marked as a duplicate of this bug. ***
*** Bug 213438 has been marked as a duplicate of this bug. ***
