Hi all,
I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
description:
Kernels: 2.6.30.[5,6] 2.6.31
Hardware: HP EliteBook 6930p
Behaviour: once a working wireless is killed activating the rfkill button,
there is no way to turn off the rfkill and riactivate wifi network. Even a
reboot is not able to reset the situation; to get again the control of rfkill
button is to reboot under windows xp and activate wifi. After that I can boot
inder linux with wifi active and kill it with rfkill button and the loop
starts again :)
I'm pretty sure that this issue is present since some kernel before the one
I've reported, but I'm not sure about the versions.
I don't know if this is iwlagn or acpi related bug (or my fault), I'm
available for any test.
HW:
Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network
Connection
Subsystem: Intel Corporation Device 1211
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
Kernel driver in use: iwlagn
Kernel modules: iwlagn
Let me know if more information are needed.
Thanks for any answer (I'm not subscribed to this list, so please CC me on
answers, thanks)
From: John W. Linville <hidden> Date: 2009-09-16 13:30:31
Is the hp-wmi module loaded?
On Wed, Sep 16, 2009 at 03:21:15PM +0200, Fabio Coatti wrote:
Hi all,
I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
description:
Kernels: 2.6.30.[5,6] 2.6.31
Hardware: HP EliteBook 6930p
Behaviour: once a working wireless is killed activating the rfkill button,
there is no way to turn off the rfkill and riactivate wifi network. Even a
reboot is not able to reset the situation; to get again the control of rfkill
button is to reboot under windows xp and activate wifi. After that I can boot
inder linux with wifi active and kill it with rfkill button and the loop
starts again :)
I'm pretty sure that this issue is present since some kernel before the one
I've reported, but I'm not sure about the versions.
I don't know if this is iwlagn or acpi related bug (or my fault), I'm
available for any test.
HW:
Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network
Connection
Subsystem: Intel Corporation Device 1211
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
Kernel driver in use: iwlagn
Kernel modules: iwlagn
Let me know if more information are needed.
Thanks for any answer (I'm not subscribed to this list, so please CC me on
answers, thanks)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
Thanks for the answer;
In fact, it wasn't loaded.
I've inserted that module and the behaviour changed: now the rfkill switch
reacts in the correct way and I'm able to turn on and off bluetooth system.
But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
my side). Basically if the laptop starts with wifi enabled (rfkill off)
wpa_supplicant can establish a connection, that can be killed by rfkill switch
(both wifi and bluetooth seems to be killed). But when I turn off rfkill
switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
can see activity in bt stack, but no messages regarding wlan0.
Any suggestion?
dmeIn data mercoledì 16 settembre 2009 15:25:49, John W. Linville ha scritto:
Is the hp-wmi module loaded?
On Wed, Sep 16, 2009 at 03:21:15PM +0200, Fabio Coatti wrote:
quoted
Hi all,
I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
description:
Kernels: 2.6.30.[5,6] 2.6.31
Hardware: HP EliteBook 6930p
Behaviour: once a working wireless is killed activating the rfkill
button, there is no way to turn off the rfkill and riactivate wifi
network. Even a reboot is not able to reset the situation; to get again
the control of rfkill button is to reboot under windows xp and activate
wifi. After that I can boot inder linux with wifi active and kill it with
rfkill button and the loop starts again :)
I'm pretty sure that this issue is present since some kernel before the
one I've reported, but I'm not sure about the versions.
I don't know if this is iwlagn or acpi related bug (or my fault), I'm
available for any test.
HW:
Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh]
Network Connection
Subsystem: Intel Corporation Device 1211
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
Kernel driver in use: iwlagn
Kernel modules: iwlagn
Let me know if more information are needed.
Thanks for any answer (I'm not subscribed to this list, so please CC me
on answers, thanks)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Fabio,
On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
my side). Basically if the laptop starts with wifi enabled (rfkill off)
wpa_supplicant can establish a connection, that can be killed by rfkill switch
(both wifi and bluetooth seems to be killed). But when I turn off rfkill
switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
can see activity in bt stack, but no messages regarding wlan0.
I think at this point you need to bring the interface back up. When you
enable rfkill the interface is brought down, the opposite (bringing
interface up) is not done automatically when you disable rfkill.
Reinette
In data mercoledì 16 settembre 2009 18:30:19, reinette chatre ha scritto:
On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
quoted
But the behaviour of wifi sybsystem is still weird, (maybe for some
faults on my side). Basically if the laptop starts with wifi enabled
(rfkill off) wpa_supplicant can establish a connection, that can be
killed by rfkill switch (both wifi and bluetooth seems to be killed). But
when I turn off rfkill switch wpa_supplicant is unable to connect again;
looking at syslog/dmesg I can see activity in bt stack, but no messages
regarding wlan0.
I think at this point you need to bring the interface back up. When you
enable rfkill the interface is brought down, the opposite (bringing
interface up) is not done automatically when you disable rfkill.
Ok, I understand your point. In fact I can bring up the interface using
"ip link set wlan0 up"
but this leads me to another question: I fail to see how restart the interface
automatically when rfkill switch is turned off.
The expected behaviour in this case should be, imho, that wpa_supplicant wakes
up and restarts the connection.
IIRC netplug doesn't work with wireless connections and this leaves me
wondering how I can have wireless la to wake up after turning off rfkill
switch :)
On Wed, Sep 16, 2009 at 11:05 PM, Fabio Coatti [off-list ref] wrote:
In data mercoledì 16 settembre 2009 18:30:19, reinette chatre ha scritto:
quoted
On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
quoted
But the behaviour of wifi sybsystem is still weird, (maybe for some
faults on my side). Basically if the laptop starts with wifi enabled
(rfkill off) wpa_supplicant can establish a connection, that can be
killed by rfkill switch (both wifi and bluetooth seems to be killed). But
when I turn off rfkill switch wpa_supplicant is unable to connect again;
looking at syslog/dmesg I can see activity in bt stack, but no messages
regarding wlan0.
I think at this point you need to bring the interface back up. When you
enable rfkill the interface is brought down, the opposite (bringing
interface up) is not done automatically when you disable rfkill.
Ok, I understand your point. In fact I can bring up the interface using
"ip link set wlan0 up"
but this leads me to another question: I fail to see how restart the interface
automatically when rfkill switch is turned off.
The expected behaviour in this case should be, imho, that wpa_supplicant wakes
up and restarts the connection.
IIRC netplug doesn't work with wireless connections and this leaves me
wondering how I can have wireless la to wake up after turning off rfkill
switch :)
Hmm, I recently looked to the interaction between rfkill and hal, and
may be able to answer that. The kernel rfkill module also exports its
state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
on kernel version; I think /dev/rfkill is new to
2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
devicekit (again, depend on distro/kernel version) monitors those, and
informs NetworkManager via d-bus messaging when the rkfill state
changes. NetworkManager then if up/down the device and tell
wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
to happen automatically, if hald/devicekit works and talk to
NetworkManager.
i.e. the waking-up should happen automatically if you have the
combination of hald/devicekit and networkmanager.
Does this answer your question?
Hmm, I recently looked to the interaction between rfkill and hal, and
may be able to answer that. The kernel rfkill module also exports its
state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
on kernel version; I think /dev/rfkill is new to
2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
devicekit (again, depend on distro/kernel version) monitors those, and
informs NetworkManager via d-bus messaging when the rkfill state
changes. NetworkManager then if up/down the device and tell
wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
to happen automatically, if hald/devicekit works and talk to
NetworkManager.
i.e. the waking-up should happen automatically if you have the
combination of hald/devicekit and networkmanager.
Does this answer your question?
Indeed; it's a good explanation of what's going on. Now I'll follow each step
of your descripiton and I'll try to find out where the chain breaks :)
Many thanks for your help.
On Thu, Sep 17, 2009 at 10:16 AM, Fabio Coatti [off-list ref] wrote:
I
quoted
Hmm, I recently looked to the interaction between rfkill and hal, and
may be able to answer that. The kernel rfkill module also exports its
state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
on kernel version; I think /dev/rfkill is new to
2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
devicekit (again, depend on distro/kernel version) monitors those, and
informs NetworkManager via d-bus messaging when the rkfill state
changes. NetworkManager then if up/down the device and tell
wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
to happen automatically, if hald/devicekit works and talk to
NetworkManager.
i.e. the waking-up should happen automatically if you have the
combination of hald/devicekit and networkmanager.
Does this answer your question?
Indeed; it's a good explanation of what's going on. Now I'll follow each step
of your descripiton and I'll try to find out where the chain breaks :)
Many thanks for your help.
On my system - hal knows about the killswitch:
$lshal |grep -i killswitch
info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
info.capabilities = {'killswitch'} (string list)
info.category = 'killswitch' (string)
info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
info.product = 'phy0 wlan Killswitch' (string)
killswitch.access_method = 'rfkill' (string)
killswitch.name = 'phy0' (string)
killswitch.state = 1 (0x1) (int)
killswitch.type = 'wlan' (string)
and NM also wrote to syslog saying it found the switch, and other
stuff when the switch is turned on and off:
#grep kill /var/log/message
...
Sep 16 00:08:48 localhost NetworkManager: <info> Wireless now
disabled by radio killswitch
Sep 16 00:10:09 localhost NetworkManager: <info> Wireless now enabled
by radio killswitch
Sep 16 01:40:18 localhost NetworkManager: <info> Found radio
killswitch /org/freedesktop/Hal/devices/usb_device_XXXXXXX_if0_rfkill_phy0_wlan
...