Maxim Levitsky wrote:
> I recently bought an acer aspire 5720G, and wireless didn't work with
> standard ubuntu 2.6.24 kernel.
>
> I found that specifying the above option 'fixes' the driver
> but I also noticed that list of available access points shrinks
> to just one (the connected) point.
>
> Moreover there is a trouble in changing a access point, it just hangs.
> the button that toggles wireless does work, but doesn't blink.
>
> I then installed latest -git kernel (~ 2.6.26-rc4) and got this:
>
> * I still have to use disable_hw_scan=1
> * Wireless led works thanks to acer-wmi
> * If I disable wireless with the button, I _can't_ re-enable it unless
> I reload the module.
>
> * List of access points doesn't shrink, and I can switch between those points.
>
>
> When I omit disable_hw_scan=1, I get errors about REPLY_SCAN_CMD
> I will send detailed debug info later.
>
> Best regards,
> Maxim Levitsky
I found why I can't reenable wireless with wireless button.
It turns out that iwlwifi doesn't enable the wireless function after a
R/F kill switch was enabled ether by the button or explicitly.
I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
in linus tree.
Best regards,
Maxim Levitsky
On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>
> I found why I can't reenable wireless with wireless button.
>
> It turns out that iwlwifi doesn't enable the wireless function after a
> R/F kill switch was enabled ether by the button or explicitly.
>
> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
> in linus tree.
The card will receive an interrupt when you disable the rf kill switch
anyway whatever the wireless function is enabled or not. So the driver
will enable the wireless function again. Please check if the interface
(wlan0) is up when you disable the rf kill switch later. If it is not,
you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
wireless function. Otherwise please provide the dmesg with
debug=0x20000.
Thanks,
-yi
On Thu, 2008-06-12 at 15:48 +0300, Maxim Levitsky wrote:
> Zhu Yi wrote:
> > On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
> >> I found why I can't reenable wireless with wireless button.
> >>
> >> It turns out that iwlwifi doesn't enable the wireless function after a
> >> R/F kill switch was enabled ether by the button or explicitly.
> >>
> >> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
> >> in linus tree.
> >
> > The card will receive an interrupt when you disable the rf kill switch
> > anyway whatever the wireless function is enabled or not. So the driver
> > will enable the wireless function again. Please check if the interface
> > (wlan0) is up when you disable the rf kill switch later. If it is not,
> > you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
> > wireless function. Otherwise please provide the dmesg with
> > debug=0x20000.
> >
> > Thanks,
> > -yi
> >
>
> Why didn't I thought about this before...
> This is exactly what happens, so this isn't a bug.
>
> What happens is the Network manager brings wlan0 down is it detects that
> there is no link, but this now removes the firmware.
>
> I guess that the right solution is to listen to the wireless button (via
> input layer), and turn card on manually.
>
> If I remember correctly there is something like that in kernel, I try to
> enable this.
>
> Otherwise this can be implemented in userspace.
The right solution is for NM to not take the device down (essentially
doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off. However,
that's not possible right now, because HAL doesn't provide enough
information about the killswitches to distinguish between a software
rfkill (which means we can turn the power back on) and a hardware rfkill
(which means the user has to flip something). On ipw2100, 2200, and
2915, setting the TX power off looks exactly like a hardware kill to
HAL, so if you chose unchecked "Enable Wireless" in the nm applet, you'd
never be able to turn wireless back on, because HAL and NM think there's
a hardware kill active.
The kernel rfkill layer needs to be supported in all drivers, and second
we need to figure out the HW vs. SW kill thing whether that happens in
rfkill or not.
Dan
On Do, 12 Jun 2008, Maxim Levitsky wrote:
> Nope 3945 doesn't support rfkill via new rfkill subsystem.
Any chance to get this working, too?
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Vienna University of Technology
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
KENTUCKEY (adv.)
Fitting exactly and satisfyingly. The cardboard box that slides neatly
into an exact space in a garage, or the last book which exactly fills
a bookshelf, is said to fit 'real nice and kentuckey'.
--- Douglas Adams, The Meaning of Liff
On Fri, 2008-06-13 at 10:45 -0400, Dan Williams wrote:
> SW rfkill doesn't necessarily kill the device. Input-only switches
> (like Fn+F5 on thinkpads for exampel) aren't handled by the kernel
> rfkill system and thus something in userspace needs to handle them
> instead. It's probably worth checking the radio state when the event
> comes in and only if the radio isn't already disabled, then set tx
> power off.
OK. That makes sense.
Thanks,
-yi
Zhu Yi wrote:
> On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>> I found why I can't reenable wireless with wireless button.
>>
>> It turns out that iwlwifi doesn't enable the wireless function after a
>> R/F kill switch was enabled ether by the button or explicitly.
>>
>> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
>> in linus tree.
>
> The card will receive an interrupt when you disable the rf kill switch
> anyway whatever the wireless function is enabled or not. So the driver
> will enable the wireless function again. Please check if the interface
> (wlan0) is up when you disable the rf kill switch later. If it is not,
> you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
> wireless function. Otherwise please provide the dmesg with
> debug=0x20000.
>
> Thanks,
> -yi
>
Why didn't I thought about this before...
This is exactly what happens, so this isn't a bug.
What happens is the Network manager brings wlan0 down is it detects that
there is no link, but this now removes the firmware.
I guess that the right solution is to listen to the wireless button (via
input layer), and turn card on manually.
If I remember correctly there is something like that in kernel, I try to
enable this.
Otherwise this can be implemented in userspace.
Best regards,
Maxim Levitsky
Maxim Levitsky wrote:
> Zhu Yi wrote:
>> On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>>> I found why I can't reenable wireless with wireless button.
>>>
>>> It turns out that iwlwifi doesn't enable the wireless function after a
>>> R/F kill switch was enabled ether by the button or explicitly.
>>>
>>> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
>>> in linus tree.
>>
>> The card will receive an interrupt when you disable the rf kill switch
>> anyway whatever the wireless function is enabled or not. So the driver
>> will enable the wireless function again. Please check if the interface
>> (wlan0) is up when you disable the rf kill switch later. If it is not,
>> you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the
>> wireless function. Otherwise please provide the dmesg with
>> debug=0x20000.
>>
>> Thanks,
>> -yi
>>
>
> Why didn't I thought about this before...
> This is exactly what happens, so this isn't a bug.
>
> What happens is the Network manager brings wlan0 down is it detects that
> there is no link, but this now removes the firmware.
>
> I guess that the right solution is to listen to the wireless button (via
> input layer), and turn card on manually.
>
> If I remember correctly there is something like that in kernel, I try to
> enable this.
>
> Otherwise this can be implemented in userspace.
>
> Best regards,
> Maxim Levitsky
Nope 3945 doesn't support rfkill via new rfkill subsystem.
On Fri, 2008-06-13 at 10:00 +0800, Zhu Yi wrote:
> On Thu, 2008-06-12 at 11:02 -0400, Dan Williams wrote:
> > > I guess that the right solution is to listen to the wireless button
> > (via
> > > input layer), and turn card on manually.
> > >
> > > If I remember correctly there is something like that in kernel, I
> > try to
> > > enable this.
> > >
> > > Otherwise this can be implemented in userspace.
> >
> > The right solution is for NM to not take the device down (essentially
> > doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off.
> > However,
> > that's not possible right now, because HAL doesn't provide enough
> > information about the killswitches to distinguish between a software
> > rfkill (which means we can turn the power back on) and a hardware
> > rfkill
> > (which means the user has to flip something). On ipw2100, 2200, and
> > 2915, setting the TX power off looks exactly like a hardware kill to
> > HAL, so if you chose unchecked "Enable Wireless" in the nm applet,
> > you'd never be able to turn wireless back on, because HAL and NM think
> > there's a hardware kill active.
>
> I think who takes the interface down is responsible to bring it up. Even
> if the driver receives a rf_kill switch disabled interrupt, it should
> keep the current IFF_UP status. It should never bring it up or down
> itself. (Think about the carrier on/off in ethernet).
>
> I wonder why NM need to ifdown or "txpower off" when rf_kill switch
> (both for SW and HW) is enabled. The driver already handles it. Could it
> save more power?
SW rfkill doesn't necessarily kill the device. Input-only switches
(like Fn+F5 on thinkpads for exampel) aren't handled by the kernel
rfkill system and thus something in userspace needs to handle them
instead. It's probably worth checking the radio state when the event
comes in and only if the radio isn't already disabled, then set tx power
off.
Dan
On Thu, 2008-06-12 at 11:02 -0400, Dan Williams wrote:
> > I guess that the right solution is to listen to the wireless button
> (via
> > input layer), and turn card on manually.
> >
> > If I remember correctly there is something like that in kernel, I
> try to
> > enable this.
> >
> > Otherwise this can be implemented in userspace.
>
> The right solution is for NM to not take the device down (essentially
> doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off.
> However,
> that's not possible right now, because HAL doesn't provide enough
> information about the killswitches to distinguish between a software
> rfkill (which means we can turn the power back on) and a hardware
> rfkill
> (which means the user has to flip something). On ipw2100, 2200, and
> 2915, setting the TX power off looks exactly like a hardware kill to
> HAL, so if you chose unchecked "Enable Wireless" in the nm applet,
> you'd never be able to turn wireless back on, because HAL and NM think
> there's a hardware kill active.
I think who takes the interface down is responsible to bring it up. Even
if the driver receives a rf_kill switch disabled interrupt, it should
keep the current IFF_UP status. It should never bring it up or down
itself. (Think about the carrier on/off in ethernet).
I wonder why NM need to ifdown or "txpower off" when rf_kill switch
(both for SW and HW) is enabled. The driver already handles it. Could it
save more power?
Thanks,
-yi
On Thu, Jun 12, 2008 at 4:26 AM, Zhu Yi <[email protected]> wrote:
> On Wed, 2008-06-11 at 18:47 +0300, Maxim Levitsky wrote:
>>
>> I found why I can't reenable wireless with wireless button.
>>
>> It turns out that iwlwifi doesn't enable the wireless function after a
>> R/F kill switch was enabled ether by the button or explicitly.
>>
>> I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e
>> in linus tree.
>
> The card will receive an interrupt when you disable the rf kill switch
> anyway [...]
It does? I thought thats only true for 4965 ... 3945 uses an ucode
event for that thats why it does not detect the rfkill state when the
interface is down.
On Thu, 2008-06-12 at 08:42 +0200, drago01 wrote:
> > The card will receive an interrupt when you disable the rf kill
> switch
> > anyway [...]
> It does? I thought thats only true for 4965 ... 3945 uses an ucode
> event for that thats why it does not detect the rfkill state when the
> interface is down.
I was wrong. The card won't receive interrupt if the interface is down
since we have disable the device. So the driver does nothing when you
disable the rf_kill switch when the interface is down. But if you do so
and then issue an `ifconfig wlan0 up`, the iwl3945_up() will read the
hardware rf_kill register CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW before
load the ucode and initialize everything. This is both true for 3945 and
4965.
Thanks,
-yi