Created attachment 210284 [details]
lsmod output (requested by dcbw)

Created attachment 210285 [details]
lspci -vv output (requested by dcbw)

Created attachment 210286 [details]
'nmcli nm' output before trying anything (wifi is on) (requested by dcbw)

Created attachment 210293 [details]
'nmcli nm' output after turning wifi off (as root, with 'nmcli nm wifi off'): remains exactly the same after trying 'nmcli nm wifi on'

The output is exactly the same after trying to turn wifi back on.

Created attachment 210294 [details]
/var/log/messages excerpt from turning off wifi then attempting to turn it back on, with debug loglevel and the NM scratch build

Ok, diagnosed; the problem here is that there are two killswitches, and one depends on the other.  NM internally needs to try unblocking killswitches when requested *even if the hardware state is hardblocked*.  This is somewhat confusing since a hardblock means "a physical switch is in off position" but it turns out that some switches simply aren't physical, but are controlled by other switches that also aren't physical.

So the problem here is that when wifi is turned off, sony-wifi is softblocked, and that in turn (in the BIOS) hardblocks phy0.  Since there's a hardblock, NM assumes that a toggle switch is in the off position, and thus we can't unblock wifi in software because hardware can't phyiscally change the position of a toggle switch.  But, of course, there is no physical phy0 switch and of course the kernel doesn't know that, so we *can* unblock phy0's hardblock by un-softblocking sony-wifi.

The code in manager_radio_user_toggled() ANDs the requested state with the hardware enabled state, which of course is 'off' since one of the killswitches is hardkilled.  Thus we don't even try to enable wifi.

What we should be doing here is *not* ANDing the requested state with the current hardware_enabled state, but instead assuming that sometimes we can actually change the start of hardblocked devices.

A rough fix would be soemthing like:

old_enabled = radio_enabled_for_rstate (rstate, TRUE);
rstate->user_enabled = enabled;
if (enabled != old_enabled) {
	guint i, numks;

	/* For WiFi only (for now) set the actual kernel rfkill state */
	if (rstate->rtype == RFKILL_TYPE_WLAN) {
		/* Platform killswitch softblock state often controls the hardblock
		 * state of wifi cards.  Thus we have to attempt to unblock WiFi
		 * as many times as there are killswitches to ensure that all
		 * switches have had a chance to affect the other switches, since
		 * the kernel has no idea about dependencies between the switches.
		 */
		numks = nm_udev_manager_get_num_killswitches_for_type (priv->udev_manager, rstate->rtype);
		for (i = 0; i < numks; i++)
			rfkill_change_wifi (rstate->desc, enabled);

		/* Let actual radio enabled/disabled state be changed when the udev
		 * event for killswitch change comes through.
		 */
	} else {
		manager_update_radio_enabled (self, rstate, enabled);
	}
}

but we need to review the udev side of things and ensure for all cases that a state change will actually come through and that manager_update_radio_enabled() will get called at some point to really enable the devices.

As far as the kernel is concerned, you shouldn't need the outer loop.  The soft-blocked state can be changed even when the device is hard-blocked.

I think we fixed this in NM a while ago by classifying killswitches into platform and physical ones.  If a platform switch exists for a radio class, then NM will basically ignore the physical switch state.  So if the platform switch is "soft-blocked" and the physical switch is hard-blocked, NM will allow the user to turn wifi back on, which unblocks the platform switch, which hopefully also unblocks the physical switch.

Adam, if this is still an issue with F18 or F19 please re-open.  Thanks!

I'll try and check it quickly today, thanks. The laptop is on current F18.

Yup, it works fine in current F18. Thanks!