linux-kernel - Re: Weird behaviour on iwl3945 module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6de6b1650811011557j3469581wf01b264ed307e1e3@mail.gmail.com>
Date:	Sat, 1 Nov 2008 20:57:25 -0200
From:	"Rafael Almeida" <almeidaraf@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Weird behaviour on iwl3945 module

On Fri, Oct 31, 2008 at 5:39 AM, Rafael Cunha de Almeida
<almeidaraf@...il.com> wrote:
> Hello,
>
> I'm using Debian lenny (linux 2.6.26) and I have a iwl3945 wireless
> card. My laptop is a lenovo r61i. I've notice that, when I turn off
> the wireles/bluetooth switch the wireless module isn't removed, the
> kernel even displays a few warnings:
>
> % dmesg | tail -n11
> [ 1219.735652] iwl3945: Radio Frequency Kill Switch is On:
> [ 1219.735652] Kill switch must be turned off for wireless networking to work.
> [ 1219.787767] usb 1-1: USB disconnect, address 2
> [ 1221.291865] iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
> [ 1221.294246] iwl3945: MAC is in deep sleep!
> [ 1221.341983] iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
> [ 1221.345953] iwl3945: MAC is in deep sleep!
> [ 1221.405968] iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
> [ 1221.450835] iwl3945: MAC is in deep sleep!
> [ 1221.612230] iwl3945: WARNING: Requesting MAC access during RFKILL wakes up NIC
> [ 1221.632612] ACPI: PCI interrupt for device 0000:03:00.0 disabled
>
> So, when I turn the switch back on, my wireless card is not
> operational. I have to manually remove and then reinstall the iwl3945
> module in order to the device to resume working. The bluetooth device
> doesn't have that issue.
>
> Is that an expected behaviour? Would it be impossible or undesirable
> to the kernel to behave differently? Is it already fixed in the newest
> kernel version (or on the -mm branch)? I am willing to hack into the
> kernel code in order to fix that problem, if someone would give me
> pointers of where to start.
>
> []'s
> Rafael
>

In order to give the issue some closure, I've recently had the chance
of running linux 2.6.28-rc2. The kill switch works fine on the new
version :-). I suggest anyone that's having problems with this
wireless card to upgrade their kernels, as things seems to have
changed recently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/