On Thu, 2010-04-22 at 11:10 -0700, Dana Goyette wrote: > On 04/22/2010 08:44 AM, Dan Williams wrote: > > On Wed, 2010-04-21 at 18:49 -0600, Jim Cromie wrote: > > > > Yes, for a number of reasons. First, we can't usually figure out which > > killswitch is for which wifi device. It's often just not possible, plus > > "platform" killswitches provided by your laptop BIOS aren't tied to a > > specific wifi device. > > > > Dan > > On a similar vein, I have issues every time I resume from suspend with > my HP laptop. I have both a platform rfkill and a phy0 rfkill, and > soft-blocking the platform rfkill hard-blocks the phy0 rfkill. > > Since NetworkManager refuses to try to unblock ANY rfkill if one is > hard-blocked, I end up having to manually "rfkill unblock wifi" at > resume. Is there any way to get NetworkManger to ignore the phy0 rfkill?
Not really; because if the phy is hardblocked, it really is *dead* and it won't be usable at all until that hardblock is removed (by unblocking the platform device). NM doesn't actually *write* to rfkill, it simply reads it. You'll want to use the hardware killswitch (or the platform one, whatever you have) to unblock your wifi when needed. > The assumption that we can't tell what wifi device the platform rfkill > applies to, is not quite true, at least for HP: I think it would be a > relatively safe bet that the hp-wifi rfkill applies to whatever wifi > card is internal (that is, on a non-hotpluggable PCI or PCIe port). Ah, but how do you know which cards are actually internal? It's a bit easier for PCI devices, but we certainly don't know for USB devices (and not all USB devices are external, especially bluetooth and WWAN, but also many wifi devices). Also realize that the platform driver has a huge impact here. There can be bugs in the platform driver (hp-wmi, thinkpad-acpi, acer-wmi, asus-laptop, fujitsu-laptop, etc) that make rfkill perform badly. It might also be the case that the autoload magic isn't present in the platform driver for your specific laptop model. I have the same setup on my daily machine (HP 2530p). iwlagn phy killswitch, and an hp-wmi platform killswitch which hardblocks the phy one. There are some ways we can deal with this, but they are complicated and hard to get right. They also include UI changes, because to actually unblock wifi, you have to do something like this: 1) try to unblock each wifi killswitch 2) after doing this, if any killswitches are still blocked, try to unblock any blocked switches again 3) and try it again 4) if any switches are still blocked, the operation has failed, and you somehow alert the user 5) if all switches are unblocked, success This is because the platform killswitch will often hardblock the phy killswitch, so we can't use a hardblock state in the UI anywhere. That also means that we can't tell whether there's actually a hardblock anywhere that has to be fixed by sliding a switch, because we can't trust any phy hardblock (there are some ways around this). Second, not all phy switches are controlled by platform switches. And there's simply no way to tell which platform switches control phy switches, because that's all internal to BIOS and not exposed to the OS. There are some things we can do here, but everyone needs to realize that it's complicated and will take some time to get right. We don't want to deploy a solution that breaks 50% of laptop. Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list