Skip to contentSkip to conversation

New: iwl3945 in 2.6.25 ignores state of hardware RF kill switch

Bugme-new Andrew Morton 3 participants 4 messages Apr 17, 2008 – Apr 18, 2008 2 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

#1 lore raw

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

Quoted 40 lines · On Thu, 17 Apr 2008 14:17:51 -0700 (PDT) [email protected] 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: [email protected]
        ReportedBy: [email protected]

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

Quoted 8 lines

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).

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw
Quoted 1 line · On Fri, 18 Apr 2008 09:52:46 +0000 Thoralf Da__ler <[email protected]>…

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.

Quoted 9 lines

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)
[email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=10471

#4 lore raw
Quoted 9 lines · Andrew Morton
Quoted 1 line · On Fri, 18 Apr 2008 09:52:46 +0000 Thoralf Da__ler <[email protected]>…

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.

Quoted 3 lines

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)

#5 lore raw
In reply to Andrew Morton

First to address the subject of this bug, the driver does not ignore the state of the hardware RF kill switch. More below.

Quoted 11 lines · Andrew Morton
Quoted 7 lines · On Thu, 17 Apr 2008 14:17:51 -0700 (PDT) [email protected] 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?

Quoted 6 lines
Quoted 6 lines

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".

Quoted 1 line

From what I can tell the driver is doing the right thing. What is the

expected behavior in this scenario?

Reinette