Bug 10471 - iwl3945 in 2.6.25 ignores state of hardware RF kill switch
Summary: iwl3945 in 2.6.25 ignores state of hardware RF kill switch
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-17 14:17 UTC by Thoralf Dassler
Modified: 2008-08-14 11:02 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.25
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Thoralf Dassler 2008-04-17 14:17:50 UTC
Latest working kernel version: 2.6.24.3 (possibly 2.6.24.4, but have not had it)
Earliest failing kernel version: 2.6.25
Distribution: Slackware 12
Hardware Environment: Toshiba Satellite P200
Software Environment: n/a
Problem Description: With the 2.6.25 kernel, iwl3945 sees the state of the hardware RF kill switch, but ignores the state. This causes long boot delays because the adapter tries to make a connection when the switch is in the OFF position.

Steps to reproduce:
boot up the system; none of the following showed with 2.6.24.3


messages during boot:
-----------------------------------
SIOCSIFFLAGS: No such device
[3 lines of irrelevant output on my iwl3945]
SIOCSIFFLAGS: No such device


dmesg:
-----------
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PM: Writing back config space on device 0000:04:00.0 at offset 1 (was 100002, writing 100006)
iwl3945: Radio disabled by HW RF Kill switch
[message repeated 7 more times]
Comment 1 Anonymous Emailer 2008-04-17 14:30:05 UTC
Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).


On Thu, 17 Apr 2008 14:17:51 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=10471
> 
>            Summary: iwl3945 in 2.6.25 ignores state of hardware RF kill
>                     switch
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.25
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: network-wireless
>         AssignedTo: drivers_network-wireless@kernel-bugs.osdl.org
>         ReportedBy: thoralf.dassler@gmail.com
> 
> 
> Latest working kernel version: 2.6.24.3 (possibly 2.6.24.4, but have not had
> it)
> Earliest failing kernel version: 2.6.25
> Distribution: Slackware 12
> Hardware Environment: Toshiba Satellite P200
> Software Environment: n/a
> Problem Description: With the 2.6.25 kernel, iwl3945 sees the state of the
> hardware RF kill switch, but ignores the state. This causes long boot delays
> because the adapter tries to make a connection when the switch is in the OFF
> position.
> 
> Steps to reproduce:
> boot up the system; none of the following showed with 2.6.24.3
> 
> 
> messages during boot:
> -----------------------------------
> SIOCSIFFLAGS: No such device
> [3 lines of irrelevant output on my iwl3945]
> SIOCSIFFLAGS: No such device
> 
> 
> dmesg:
> -----------
> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
> PM: Writing back config space on device 0000:04:00.0 at offset 1 (was 100002,
> writing 100006)
> iwl3945: Radio disabled by HW RF Kill switch
> [message repeated 7 more times]
> 

Yeah, I got bitten by that too.  Apparently it's deliberate and other
wireless drivers will start to do the same thing soon.

It's totally dumb that the initscritps pause *at all* when the kill switch
is in "kill" mode.  Hopefully one day userspace will get fixed (I assume
the problem is in userspace).
Comment 2 Thoralf Dassler 2008-04-18 01:53:48 UTC
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yeah, it seems dumb that the init scripts pause, but I don't understand
why this started with the 2.6.25 kernel, whereas it was fine before.<br>
<br>
Andrew Morton wrote:
<blockquote cite="mid:20080417142934.be2bdd27.akpm@linux-foundation.org"
 type="cite">
  <pre wrap="">(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).


On Thu, 17 Apr 2008 14:17:51 -0700 (PDT)
<a class="moz-txt-link-abbreviated" href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap=""><a class="moz-txt-link-freetext" href="http://bugzilla.kernel.org/show_bug.cgi?id=10471">http://bugzilla.kernel.org/show_bug.cgi?id=10471</a>

           Summary: iwl3945 in 2.6.25 ignores state of hardware RF kill
                    switch
           Product: Drivers
           Version: 2.5
     KernelVersion: 2.6.25
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: network-wireless
        AssignedTo: <a class="moz-txt-link-abbreviated" href="mailto:drivers_network-wireless@kernel-bugs.osdl.org">drivers_network-wireless@kernel-bugs.osdl.org</a>
        ReportedBy: <a class="moz-txt-link-abbreviated" href="mailto:thoralf.dassler@gmail.com">thoralf.dassler@gmail.com</a>


Latest working kernel version: 2.6.24.3 (possibly 2.6.24.4, but have not had
it)
Earliest failing kernel version: 2.6.25
Distribution: Slackware 12
Hardware Environment: Toshiba Satellite P200
Software Environment: n/a
Problem Description: With the 2.6.25 kernel, iwl3945 sees the state of the
hardware RF kill switch, but ignores the state. This causes long boot delays
because the adapter tries to make a connection when the switch is in the OFF
position.

Steps to reproduce:
boot up the system; none of the following showed with 2.6.24.3


messages during boot:
-----------------------------------
SIOCSIFFLAGS: No such device
[3 lines of irrelevant output on my iwl3945]
SIOCSIFFLAGS: No such device


dmesg:
-----------
ACPI: PCI Interrupt 0000:04:00.0[A] -&gt; GSI 17 (level, low) -&gt; IRQ 17
PM: Writing back config space on device 0000:04:00.0 at offset 1 (was 100002,
writing 100006)
iwl3945: Radio disabled by HW RF Kill switch
[message repeated 7 more times]

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yeah, I got bitten by that too.  Apparently it's deliberate and other
wireless drivers will start to do the same thing soon.

It's totally dumb that the initscritps pause *at all* when the kill switch
is in "kill" mode.  Hopefully one day userspace will get fixed (I assume
the problem is in userspace).



  </pre>
</blockquote>
<br>
</body>
</html>
Comment 3 Anonymous Emailer 2008-04-18 02:01:44 UTC
Reply-To: akpm@linux-foundation.org

On Fri, 18 Apr 2008 09:52:46 +0000 Thoralf Da__ler <thoralf.dassler@gmail.com> wrote:

> Yeah, it seems dumb that the init scripts pause, but I don't understand why
> this started with the 2.6.25 kernel, whereas it was fine before.

You have removed from Cc: the people who can explain it.  I restored them.

> Andrew Morton wrote:(switched to email.  Please respond via emailed
> reply-to-all, not via the
> bugzilla web interface).
> 
> 
> On Thu, 17 Apr 2008 14:17:51 -0700 (PDT)
> bugme-daemon@bugzilla.kernel.org wrote:
> 
>   http://bugzilla.kernel.org/show_bug.cgi?id=10471
> 
Comment 4 drago01 2008-04-18 08:58:28 UTC
On Fri, Apr 18, 2008 at 11:01 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 18 Apr 2008 09:52:46 +0000 Thoralf Da__ler
> <thoralf.dassler@gmail.com> wrote:
>
>  > Yeah, it seems dumb that the init scripts pause, but I don't understand
>  why this started with the 2.6.25 kernel, whereas it was fine before.
>
>  You have removed from Cc: the people who can explain it.  I restored them.
>
>  > Andrew Morton wrote:(switched to email.  Please respond via emailed
>  reply-to-all, not via the
>
> > bugzilla web interface).

iwl3945 was loading the ucode (firmware) during probe but then changed
to do this on ifup.
for 4965 this does not cause such problems because the rfkill state is
reported via an interrupt; while for 3965 its an ucode event...
no ucode means no ucode event ;) (but it should be able to read the
current state after an ifup)
Comment 5 Reinette Chatre 2008-04-18 09:28:08 UTC
First to address the subject of this bug, the driver does not ignore the
state of the hardware RF kill switch. More below.

On , Andrew Morton  wrote:

> On Thu, 17 Apr 2008 14:17:51 -0700 (PDT)
> bugme-daemon@bugzilla.kernel.org wrote:
> 

>> 
>> 
>> messages during boot:
>> -----------------------------------
>> SIOCSIFFLAGS: No such device
>> [3 lines of irrelevant output on my iwl3945]
>> SIOCSIFFLAGS: No such device

This is exactly the error returned by the driver when it detects that
the hardware RF kill switch is set. With several message like above in
your logs - could it be a user app that keeps trying to bring the
interface up even when it returns an error?


>> dmesg:
>> -----------
>> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
>> PM: Writing back config space on device 0000:04:00.0 at offset 1
>> (was 100002, writing 100006) iwl3945: Radio disabled by HW RF Kill
>> switch [message repeated 7 more times]

It is right after printing this message that the driver returns
"ENODEV".

From what I can tell the driver is doing the right thing. What is the
expected behavior in this scenario?

Reinette
Comment 6 conraid 2008-04-22 05:40:57 UTC
I have the same error.
Slackware -current and Compaq 6710s


> It's totally dumb that the initscritps pause *at all* when the kill switch
> is in "kill" mode.  Hopefully one day userspace will get fixed (I assume
> the problem is in userspace).

rf_kill value not change with 2.6.25
with 2.6.24.4 is all ok


>  With the 2.6.25 kernel, iwl3945 sees the state of the
> hardware RF kill switch, but ignores the state.

In my case RF kill switch state not change
Comment 7 John W. Linville 2008-08-14 11:02:22 UTC
This should be fixed already.

Note You need to log in before you can comment on or make changes to this bug.