> HAL itself doesn't load or unload any modules. > What exactly do you mean by "the module is disabled"? > Is this the rfkill_switch state? What exactly does this "disable=0" > option do? >
> > Michael First of all, thank for you answer Michael. I know that HAL doesn't load any module. This is made automatically at boot time. The point is that once the module is loaded it is disabled by HAL. The option disable=0 means that the wifi card must be active when the module is loaded and thus the output of cat /sys/module/iwl3945/drivers/pci\:iwl3945/0000\:06\:00.0/rf_kill should be 0. And that is. > Does the rfkill state work correctly under 2.6.25.x? I don't know how to answer properly to this question, please, give me an hint how to tell this information to you. If you are asking if I can manipulate its value the answer is yes, I can. Issuing "echo 0 (or 1, 2) > /sys/module/iwl3945/drivers/pci\:iwl3945/0000\:06\:00.0/rf_kill" gives a change of the state. However it doesn't work always even if HAL is disabled. Hmmm. > Do you also have network-manager running? NM checks the rfkill state, > and if your driver is buggy and reports an incorrect state, this might > be the real problem. Yes I do, but I check the state of the card using always cat /sys/module/iwl3945/drivers/pci\:iwl3945/0000\:06\:00.0/rf_kill, so I don't bother about what nm is reporting to me. The result of cat command is 0 before loading HAL and 1 after having loaded it. I must rmmod and modprobe iwl3945 several times before getting by chance that reloading HAL, HAL doesn't change the state of rf_kill to 1. After this I can connect using nm as usual. I think what is happening to me is similar to a bugreport in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/193970 It seems they have decided it is a bug in the kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
