--- On Tue, 25/8/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:

Hin-Tak Leung wrote:

quoted

--- On Tue, 25/8/09, Larry Finger <Larry.Finger@lwfinger.net>

wrote:

quoted

quoted

quoted

[PATCH] rtl8187: fix circular locking

(rtl8187_stop/rtl8187_work)

This patch fixes the problem. You can add a

Tested-by to

quoted

quoted

it.

Hmm, I am still wondering about why NM insists on if

up'ing the device. I read bits of things and apparently hal
is supposed to know the device is rfkill'ed and let NM know.
But lshal is not listing the device as having an killswitch.
I don't know how hal is supposed to work out that info
though. 

quoted

also I noted that

/sys/class/rfkill_backport/rfkill0/state goes from 1 to 2
when I slide the switch to the 'off' position. Some says it
should be 0?

quoted

Don't know if hal is affected by its being

rfkill_backport (compat-wireless) rather than rfkill (stock
vendor kernel). well, it should look there if it isn't :-).

quoted

It looks like it is a hal problem...

The interpretation is as follows:
0 - blocked by software such as 'rfkill block 1'
1 - unblocked
2 - blocked by hardware

Your state is doing exactly what I would expect. When NM
brings the
device up, does the above state change? Does dmesg show
anything?

dmesg and rfkill/state corresponds exactly to what the sliding switch does (in the on position, dmesg says it is on, states says 2, in the off position, dmesg says it is off, state says 1). NM basically ignores rfkill/state, and just if'up the device whenever it notices the device has gone down.

hal is supposed to have knowledge of the rfkill state (which it hasn't, from what I see of the lshal output - there is no killswitch entry in there), and let NM through dbus know to not bother the device. At the moment I think it is somewhere in hal that's not working properly.