linux-backports-modules-2.6.24-21-generic causes kernel panic when unloading Intel Wireless driver

I second that.

Verbose mode at kernel panic says its the IPW 3945.

I'm on a Sony Vaio TZ21MN/N with an up-to-date Ubuntu Hardy Heron.

Also seeing this after upgrading to 2.6.24-20-generic. Booting with 2.6.24-19-generic results in successful suspend again.

Laptop is a Dell Vostro 1710, fully updated Hardy w/ linux-backports-modules-hardy installed.

Panic screenshot attached.

Same thing with iwl4965, i can't suspend since yesterday !

The same problem here on Acer 5920.

Like Jeremy said, using previous kernel version doesn't have any problem to suspend.

What could be the problem?

It is a iwlwifi problem I think because last update concern only iwlwifi update ...

Could be, I'm using iwl3945 too.

Same here, on a dell D630 laptop, with ipw 3945. I started noticing this problem yesterday. Before that, it worked fine (but I also noticed that wake-up was taking increasingly long time, since three or four days).

I don't recall the exact message I get, but it is something like "kernel panic: not syncing fatal exception ..."

Cyril

Same thing here...

Dell Vostro 1400, incl. Intel wireless card...

I'm using iwl3945, but I compiled my own from the compat-wireless project...

I've just checked, when booting on 2.6.24-19, the suspend to ram works OK (althoug wake-up is a bit slow, like 20-30 seconds I'd say). with 2.6.24-20, I got a kernel panic immediatly.

Cyril

For the slow wake up problems in earlier kernels, try commenting out the
'auto eth0' line in /etc/network/interfaces. That dramatically improved
things for me. https://bugs.launchpad.net/bugs/217846 is the bug that
had that fix listed.

--
Jon-o Addleman - http://www.redowl.ca

More information on what see to be the same issue.

The kernel panics during the shorewall initialization during boot.

The laptop is a Thinkpad X60S.

Relevant packages installed:
$ dpkg -l |grep 2.6.24-20
ii linux-backports-modules-2.6.24-20-generic 2.6.24-20.20 Ubuntu supplied Linux modules
for version 2.
ii linux-headers-2.6.24-20 2.6.24-20.37 Header files related to Linux kernel version
ii linux-headers-2.6.24-20-generic 2.6.24-20.37 Linux kernel headers for version 2.6.24 on x
ii linux-image-2.6.24-20-generic 2.6.24-20.37 Linux kernel image for version 2.6.24 on x86
ii linux-libc-dev 2.6.24-20.37 Linux Kernel Headers for development
ii linux-restricted-modules-2.6.24-20-generic 2.6.24.14-20.46 Non-free Linux 2.6.24 modules on x86/x86_64
ii linux-ubuntu-modules-2.6.24-20-generic 2.6.24-20.29 Ubuntu supplied Linux modules for version 2.

Attached lspci -vv output.

I don't have a dmesg from 2.6.24-20 because it seems like the syslog isn't enabled before the panic or disk didn't sync.

I could get more information if I find a null modem cable and enable serial console.

I will keep you posted.

Jeremy

Confirm that on a Thinkpad T60. 2.6.24-19 suspends, 2.6.24-20 doesn't.

for me confirm that on a Thinkpad T61.
kernel 2.6.24-19 suspends and hibernate working,
kernel 2.6.24-20 doesn't.

I'll try to do a photo of the beginning of the kernel panic message. If somebody wants to do it before I do : boot with "vga=792" parameter in order to use the frame buffer. You won't have the end of the kernel panic message, but you'll have the beginning, that says (if I remember correctly) that the system is trying to access a bad pointer (at 00000001c).

Doing what Mathieu suggested: Here's a screenshot of the full kernel panic message (forgive the poor quality...)

The first line does indeed read "BUG: unable to handle kernel NULL pointer dereference at virtual address 0000001c"

Thank you for doing it tentotwo :-)

I can confirm that this picture shows the whole error message, hope it will help the developpers :-)

Try installing linux-backports-modules-hardy which has the 2.6.26 upstream version of the iwlwifi drivers.

sudo apt-get install linux-backports-modules-hardy

Alternatively, if you already have LBM installed, then try removing it.

Trying what Tim said:

Previous behavior:

On 2.6.24-19 kernel, with linux-backports-modules-2.6.24-19 installed:
sudo modprobe -r iwl3945 --> The module is correctly unloaded
sudo modprobe iwl3945 --> The module is correctly loaded

On 2.6.24-20 kernel, with linux-backports-modules-2.6.24-20 installed:
sudo modprobe -r iwl3945 --> kernel panic (I have an Intel 3945 wifi chipset)

--- I uninstalled linux-backports-modules-2.6.24-20 and rebooted ---

New behavior:

On 2.6.24-19 kernel, with linux-backports-modules-2.6.24-19 installed :
sudo modprobe -r iwl3945 --> The module is correctly unloaded
sudo modprobe iwl3945 --> The module is correctly loaded

On 2.6.24-20 kernel, with linux-backports-modules-2.6.24-20 NOT installed :
sudo modprobe -r iwl3945 --> The module is correctly unloaded
sudo modprobe iwl3945 --> The module is correctly loaded

So this bug is definitely related to the Intel WiFi driver that is in the linux-backports-modules-2.6.24-20

Working back for with the last linux-backports-modules-2.6.24-20-generic update (2.6.24-20.21)

Confirming that it's working again with the latest update of linux-backports-modules-2.6.24-20-generic (2.6.24-20.21)

Changed status to "Fix Released" based on previous two comments.

For me, it doesn't crash anymore. But I can't connect to my home network. Network manager shows no wifi networks (I have two) and manually entering a network and key doesn't authenticate. iwl4965

Does "sudo iwlist wlan0 scan" return any network? And (stupid thing, but we never know ^^) is the WiFi turned on on your computer ;-)

 extract from kern.log when I have the new backport module loaded. I didn't see your iwlist question until now.
But yes, I have wifi turned on.

Aug 2 22:40:41 u400 kernel: [ 35.913614] PM: Writing back config space on device 0000:08:00.0 at offset 1 (was 100002, writing 100006)
Aug 2 22:40:41 u400 kernel: [ 35.992128] iwl4965: iwlwifi-4965-2.ucode firmware file req failed: Reason -2
Aug 2 22:40:41 u400 kernel: [ 35.992139] iwl4965: Could not read microcode: -2
Aug 2 22:40:41 u400 kernel: [ 35.992222] ACPI: PCI interrupt for device 0000:08:00.0 disabled

I opened a new bug report since it is now a new module version.
https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/+bug/254344

I'm also getting a kernel panic when unloading module iwl3945. I discovered it when I tired to hibernate my laptop.

I'm attaching a picture of part of the trace, if it's of any help ..

Some versions (hardy-proposed enabled):
linux-libc-dev 2.6.24-21.40
linux-image-2.6.24-21-generic 2.6.24-21.40
linux-backports-modules-2.6.24-21-generic 2.6.24-21.24
linux-ubuntu-modules-2.6.24-21-generic 2.6.24-21.30
linux-backports-modules-hardy-generic 2.6.24.21.23
linux-image-generic 2.6.24.21.23
linux-restricted-modules-common 2.6.24.14-21.47
linux-restricted-modules-2.6.24-21-generic 2.6.24.14-21.47
linux-restricted-modules-generic 2.6.24.21.23
linux-generic 2.6.24.21.23
linux-headers-2.6.24-21 2.6.24-21.40
linux-headers-2.6.24-21-generic 2.6.24-21.40
linux-headers-generic 2.6.24.21.23

I'd say this is pretty critical .....

The panic codes that are not completely visible on the image (to the right) are:
.. 89 c6
.. 52 1c

Is a fix supposed to be relased for this ? Still panics in the latest kernel update from proposed (including backports-modules update).

Reopening since the problem is here again with 2.6.24-21

Confirmed reappearance with 2.6.24-21 on Sony Vaio TZ21MN/N and the Intel 3945 driver.

How long is it going to take before the (old) fix provided by the backports-module enters main? It sucks downloading new kernels and always having to blacklist them until the backport-module comes along to save the day...

I mean, its not like only five people on this planet are using Intel-drivers... :(

Confirming that this has re-occured with an upgrade to 2.6.24-21.

Same issue here... BTW did anyone else notice the WLAN led not lightning up anymore?

Confirming that this has re-occured with an upgrade to 2.6.24-21 in Thinkpad T61

# Sandro Mani wrote:
# Same issue here... BTW did anyone else notice the WLAN led not lightning up anymore?

Wow! I didn't notice it up until now... but you're right! Damn!

Confirm this on a Thinkpad R61 with the 2.6.24-21, wifi LED also gone.

Re: Same issue here... BTW did anyone else notice the WLAN led not lightning up anymore?

Yup, I noticed WLAN led is suddenly completely dead, like it used to be without the linux-backports-modules installed.

Same problem here: suspend works with 2.6.24-20.38; with 2.6.24-21.40, it causes a kernel panic. I'm using the generic images on my Inspiron 6400 with Intel wifi and NVidia graphics. A hw profile is attached.

My LED is also not working. Interestingly, the "Hardware Drivers" utility says the wifi card is "Not in use" even though I'm connected and using it right now.

Hi,
Same problem on Vaio SZ3 using Intel 3945ABG chipset and iwl3945 driver with 2.6.24.21 kernel.
Kernel panic occurs when unloading iwl3945 driver, either manually (modprobe -r) or on hibernation.
Kernel 2.6.24.19 working alright.

LED not working neither since after kernel 2.6.24.19.

Does anybody know of a work-around for the panic ?

Workaround to get suspend working: don't remove the network modules on suspend. To achieve that, copy /usr/lib/pm-utils/sleep.d/50modules to /etc/pm/sleep.d/, and edit the copy and comment out the unload_network call.

# Marius Gedminas wrote:
# Workaround to get suspend working: don't remove the network modules on suspend.

What's the drawback of this workaround? More power-consumption during s3-sleep? Will network-mananger be cluttered with old wireless-signals that aren't present anymore?

I'd really like to have a good overview over the pros & cons before proceeding. Thanks!

The "cleanest" workaround is removing linux-backports-modules-2.6.24-21-generic until this bug is fixed again.

Mathieu is correct; the best solution would be to remove l-b-m. I, however, need l-b-m to fix bug 259904.

The downsides of editing the sleep.d hook are two-fold:

  * Buggy network drivers may be unable to handle suspending and may cause all kinds of problems (from network no longer working after a resume to system crashes). It depends on the drivers loaded, which depend on your hardware. In my case I have two network drivers loaded: e1000 and iwl3945. Both appear to handle suspend correctly without unloading and reloading the module. Actually, I haven't tried using wired network after a resume, but at least there are no crashes on suspend.

  * Having a modified sleep.d hook may cause problems in the future when you upgrade your OS. Your modified hook will override whatever the new Ubuntu version ship, which may cause suspend problems. This is not very likely, but possible, and something to keep in mind. It'd be best to remove the copy in /etc/pm/sleep.d before you upgrade to 8.10. Actually, it's best to remove it as soon as you no longer need it -- i.e. when a new linux-backports-modules release fixes the kernel panic on rmmod.

(Somewhat ironically, removing of network modules before suspending is also a workaround, and not a proper solution, AFAIU. Drivers are supposed to handle suspend correctly by putting the hardware into the appropriate sleep state etc. Except that buggy ones don't, and so far it's easier to make suspend work by removing the modules rather than debugging and fixing all the buggy drivers.)

Re: Workaround to get suspend working: don't remove the network modules on suspend. .....

Thanks, that worked, now I can hibernate again. And the wireless network still works fine after resume, so looks like ipw3945 can handle it.

I just wanted to add that it's not just the l-b-m package, but the iwl drivers from the compat-wireless project too... Have we identified whether this is a kernel issue or a backports-modules problem?

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

thanks Leann

seems linux-image-2.6.27-1-generic having conflict with the firmware, im trying with the 2.6.26-5.17 first while waiting for 2.6.27-3 in the repo .. ill update here after im finish upgrade mine to 2.6.26-5.17

My Summary :

2.6.26-5.17 = blank screen after boot splash
2.6.27-1 = conflict with the firmware

Is it only me having the problem ? anyone else ?

Currently im in Hardy Heron in Thinkpad T61

I tried with 2.6.27-1, also noticed the firmware conflict.
Also, though my laptop did suspend, I got a kernel panic on resume.

I'm in Hardy on a Inspiron 1720.

I have posted [1] the syslog messages related to iwlwifi-3945 driver using kernel 2.6.27-1.

Is this what you're calling the "firmware conflict" ?

    ...
    iwlwifi-3945-1.ucode firmware file req failed: Reason -2
    [ 32.773576] iwl3945: Could not read microcode: -2
    ...

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/250211

#Is this what you're calling the "firmware conflict" ?
#
# ...
# iwlwifi-3945-1.ucode firmware file req failed: Reason -2
# [ 32.773576] iwl3945: Could not read microcode: -2
# ...

Yes in my case, those were the messages I noticed.

To fix the firmware error -
# iwlwifi-3945-1.ucode firmware file req failed: Reason -2
# [ 32.773576] iwl3945: Could not read microcode: -2

 just copy the firmware files from any of the other kernel directories
cp /lib/firmware/???/iwl* /lib/firmware/2.6.27-2-generic/

This let's the modules load and the driver works OK (not kernel panic at startup)
- have not tested suspend resume cycle with it yet.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Knowles wrote:
> To fix the firmware error -
> # iwlwifi-3945-1.ucode firmware file req failed: Reason -2
> # [ 32.773576] iwl3945: Could not read microcode: -2
>
> just copy the firmware files from any of the other kernel directories
> cp /lib/firmware/???/iwl* /lib/firmware/2.6.27-2-generic/
>
> This let's the modules load and the driver works OK (not kernel panic at startup)
> - have not tested suspend resume cycle with it yet.
>

Alternatively, installing Intrepid's linux-restricted-modules-common will give you all the required
firmware.

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIuSL14LFcUo8CpBERAunTAJ9vxsL0T+K31h5J+Eh/2IleBRsckQCg0mZc
Wir7YZF3nwe6cs8ECdaKBIc=
=XtFL
-----END PGP SIGNATURE-----

This doesn't seem to be specific to the reporters hardware... I have another bug that I just marked as high - confirmed with the same problem... I am reluctant to mark it as a dup though until I am sure.

The one I just marked was bug is #258026... If bug-control thinks it's a dup please mark it as such as I am new to this issue as of 30 min ago...

Thanks

iwl3945 also cause kernel panic in 2.6.27-4 (Intrepid alpha6). I was not able to identify the conditions when it occurs. It can be after several unload/reload of the kernel module, or at the shutdown of the computer.

I still have the same problem with my Lenovo Thinkpad R61. Using the latest Hardy (backports) kernel or the latest Intrepid kernel is causing a kernel panic when I remove the iwl3945 module. With the Intrepid kernel I can load/reload the module at least one or two times.

Accepted into -proposed, please test.

 linux-backports-modules-2.6.24 (2.6.24-21.27) hardy-proposed; urgency=low
 .
   [Tim Gardner]
 .
   * Update to use compat-wireless-2.6-old
   * iwlwifi backport from Intel
   * Fix symbol collision issues with the iwlwifi backport
   * Fix compat-wireless build warnings.
   * Add LUM header dependencies.
   * Updated to compat-wireless-old cd7615b4e5ad9793c20fb19cdd4e7525e9dd07b7
   * Munge the ucode file names used by the iwlwifi drivers.
   * Disable IWL modules in compat-wireless, use Intel's backported drivers instead
     since the versions in compat-wireless don't work with NetworkManager.
     Should also fix suspend crash.
     - LP: #251252

Re: [Accepted into -proposed, please test.] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/251252/comments/60

I would test right away, but the interesting builds are in dependency-wait state :)
https://launchpad.net/ubuntu/hardy/+source/linux-backports-modules-2.6.24/2.6.24-21.27

I built the new backports-release myself, since the i386-build isn't available from Launchpad, yet.

Observations after some quick testing:
* Wireless LED works again (and blinks on traffic).
* No kernel panic when module iwl3945 is removed.
* Wireless works fine in general.

Ubuntu Hardy x86, Lenovo Thinkpad Z61m, Intel PRO wireless 3945 chipset.

Thanks ! :)

Øyvind, thank you for testing!

I mailed Tim about the build problem, we'll sort it out soon.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Is there a reason why the wireless LED blinks on traffic? Personally,
it drives me nuts since my LED is right below my screen. Any way to
give users an option to either have it say on steady or blink on traffic?

David

Øyvind Stegard wrote:
> I built the new backports-release myself, since the i386-build isn't
> available from Launchpad, yet.
>
> Observations after some quick testing:
> * Wireless LED works again (and blinks on traffic).
> * No kernel panic when module iwl3945 is removed.
> * Wireless works fine in general.
>
> Ubuntu Hardy x86, Lenovo Thinkpad Z61m, Intel PRO wireless 3945 chipset.
>
> Thanks ! :)
>
>

ti., 07.10.2008 kl. 14.24 +0000, skrev Diggs808:
> Is there a reason why the wireless LED blinks on traffic? Personally,
> it drives me nuts since my LED is right below my screen. Any way to
> give users an option to either have it say on steady or blink on traffic?
<snip>

Well, blinking on traffic is pretty much standard behaviour for wireless
LEDs and network activity indicators in general, no ? Anyway, the rate
of blinking is not very high, at least on my hardware. I remember when I
used the older ipw3945-driver, the blinking-rate was totally
out-of-whack sometimes, so it's an improvement. I have the light below
my screen, but it's almost next to the HD-led anyway, so it's just
another bulb added to the X-mas-light party and my mind easily ignores
it.

As for disabling the led blinking, I see no options for that in the
iwl3945 module, nor any of the modules it directly depends on.

Øyvind

On Tue, Oct 7, 2008 at 4:12 PM, Øyvind Stegard <email address hidden> wrote:
> ti., 07.10.2008 kl. 14.24 +0000, skrev Diggs808:
>> Is there a reason why the wireless LED blinks on traffic? Personally,
>> it drives me nuts since my LED is right below my screen. Any way to
>> give users an option to either have it say on steady or blink on traffic?
> <snip>
>
> Well, blinking on traffic is pretty much standard behaviour for wireless
> LEDs and network activity indicators in general, no ? Anyway, the rate
> of blinking is not very high, at least on my hardware. I remember when I
> used the older ipw3945-driver, the blinking-rate was totally
> out-of-whack sometimes, so it's an improvement. I have the light below
> my screen, but it's almost next to the HD-led anyway, so it's just
> another bulb added to the X-mas-light party and my mind easily ignores
> it.
>
> As for disabling the led blinking, I see no options for that in the
> iwl3945 module, nor any of the modules it directly depends on.
>

For the record the LED on my Toshiba Satellite A100 doesn't blink, yet
uses the iwl/ipw3945 drivers. I guess it's a hardware thing.

PS. Thanks for the apparent fix on this bug... I'm waiting until the
issues with the package get resolved and then I'll be testing it :)

Matthew.

MattJ wrote:
> On Tue, Oct 7, 2008 at 4:12 PM, Øyvind Stegard <SNIPPED MY EMAIL> wrote:
> [...]
<snip>

Bah, you just published my email-address in plain text at Launchpad so
all the email-address-harvester-spam-bots can get at it :) .. No
worries, though, I've got excellent filtering in place. But please
remember to strip the actual address from the body next time you reply
to something by email, since it all gets published on the web. Some
people are desperately trying to reduce the amount of incoming spam, a
hopeless task, but still :) ..

Øyvind

On Tue, Oct 7, 2008 at 8:31 PM, Øyvind Stegard wrote:
> MattJ wrote:
>> On Tue, Oct 7, 2008 at 4:12 PM, Øyvind Stegard <SNIPPED MY EMAIL> wrote:
>> [...]
> <snip>
>
> Bah, you just published my email-address in plain text at Launchpad so
> all the email-address-harvester-spam-bots can get at it :) .. No
> worries, though, I've got excellent filtering in place. But please
> remember to strip the actual address from the body next time you reply
> to something by email, since it all gets published on the web. Some
> people are desperately trying to reduce the amount of incoming spam, a
> hopeless task, but still :) ..
>

Hmm, my apologies. Personally I have never seen a system that copies
emails to the web before without protecting email addresses, even
mailman does this. Perhaps a bug should be filed.

Matthew.

Luckilly for both of you, Launcpad *does* hide e-mail addresses from anyone
that is not logged in, and it does this automatically. Øyvind, until I
logged in, instead of your e-mail address I saw "<email address hidden>".

Back on-topic:

1) I would like to test this out but am not confident in my compiling
abilities; I will wait until the appropriate packages are ready.

2) @ MattJ: Your current non-blinking status is actually "not as intended";
one of the fixes here is making the LED blink like it is "supposed" to. As
to whether or not it *should* blink, when Øyvind said that blinking was the
default, he meant from the manufacturer. Their intention is that the LED
would blink during transfer. As such, under Linux, the LED should blink
during transfer. I agree with you in that this could be an option, however
this adds more or less un-needed complexity. You could always make the
relevent changes in the source and re-compile for yourself. Having an actual
option is only worth it if there are a lot of people that would prefer the
LED not to blink.

-Scott

On Tue, Oct 7, 2008 at 4:14 PM, MattJ <email address hidden> wrote:

> On Tue, Oct 7, 2008 at 8:31 PM, Øyvind Stegard wrote:
> > MattJ wrote:
> >> On Tue, Oct 7, 2008 at 4:12 PM, Øyvind Stegard <SNIPPED MY EMAIL> wrote:
> >> [...]
> > <snip>
> >
> > Bah, you just published my email-address in plain text at Launchpad so
> > all the email-address-harvester-spam-bots can get at it :) .. No
> > worries, though, I've got excellent filtering in place. But please
> > remember to strip the actual address from the body next time you reply
> > to something by email, since it all gets published on the web. Some
> > people are desperately trying to reduce the amount of incoming spam, a
> > hopeless task, but still :) ..
> >
>
> Hmm, my apologies. Personally I have never seen a system that copies
> emails to the web before without protecting email addresses, even
> mailman does this. Perhaps a bug should be filed.
>
> Matthew.
>
> --
> linux-backports-modules-2.6.24-21-generic causes kernel panic when
> unloading Intel Wireless driver
> https://bugs.launchpad.net/bugs/251252
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Scott Armitage, B.A.Sc., M.A.Sc. candidate
Space Flight Laboratory
University of Toronto Institute for Aerospace Studies
4925 Dufferin Street, Toronto, Ontario, Canada, M3H 5T6

On Tue, Oct 7, 2008 at 9:50 PM, Scott Armitage
<email address hidden> wrote:
> Luckilly for both of you, Launcpad *does* hide e-mail addresses from anyone
> that is not logged in, and it does this automatically. Øyvind, until I
> logged in, instead of your e-mail address I saw "<email address hidden>".
>

Ha, great, all is as it should be :)

> Back on-topic:
>
> 1) I would like to test this out but am not confident in my compiling
> abilities; I will wait until the appropriate packages are ready.
>

Same here. Plus if I compile it and it doesn't work, I'll not know
whether to blame myself or the driver :)

> 2) @ MattJ: Your current non-blinking status is actually "not as intended";
> one of the fixes here is making the LED blink like it is "supposed" to. As
> to whether or not it *should* blink, when Øyvind said that blinking was the
> default, he meant from the manufacturer. Their intention is that the LED
> would blink during transfer. As such, under Linux, the LED should blink
> during transfer. I agree with you in that this could be an option, however
> this adds more or less un-needed complexity. You could always make the
> relevent changes in the source and re-compile for yourself. Having an actual
> option is only worth it if there are a lot of people that would prefer the
> LED not to blink.
>

I believe it is though. I am quite sure it doesn't blink under
Windows. Been a while since I used that though.

If this update suddenly gives me a blinking LED, put me on the list of
people who want it optional :)

Matthew.

Scott Armitage wrote:
> Luckilly for both of you, Launcpad *does* hide e-mail addresses from anyone
> that is not logged in, and it does this automatically. Øyvind, until I
> logged in, instead of your e-mail address I saw "<email address hidden>".

Scott A, thanks for pointing this out :)

My apologies to you, MattJ, I didn't know Launchpad did automatic email address protection. I guess you learn something new every day. And sorry for the noise, this is about bugs, and not email-addresses.

Looks good now. No problems with linux-backports-modules 2.6.24-21.27 on my Lenovo Thinkpad R61 8943-DMG so far. Unloading/loading seems to work as well as flashing the LED. I like it. Thanks.

It's working here just fine as well. The flashing LED is a lot slower than it used to be (back in gutsy, I believe) but it is working. I much preferred the faster blink though - it used to also indicate (with a very fast flicker) when it was trying to associate to an AP. Now there's just the constant, slow blinking when there's any activity of any kind. I do like that it blinks, but I wish it would go back to the original behaviour!

Working here too. No flashing LED for me, because I don't think mine is supposed to :p

Glad to see this got fixed. Thanks for all the hard work!

Also working here, however when I resume from suspend, my wireless no longer works and the led is off. The icon says networking disabled, and trying to enable it doesn't do anything.

mellery wrote:
> Also working here, however when I resume from suspend, my wireless no longer works and the led is off.
> The icon says networking disabled, and trying to enable it doesn't do anything.

You are fortunate :) I have *never* *ever* gotten suspend working in Hardy, no matter what tweaks I've tried. If anyone else owns a Lenovo Thinkpad Z61m and suspend works in Hardy, please let me know how you did it :).

Now, back on topic, you could try the old trick of removing and re-inserting the kernel module (iwl3945 if you have the 3945-chipset):
As root:
$ rmmod iwl3945; modprobe iwl3945

Also:
$ dmesg
may tell you something or give some hints as to why the wireless has been disabled after resume.

PS.
Is there any proper way of replying to comments in the Launchpad interface, with automatic quoting of the original comment, etc ?

Hey, upgrading to the latest version of linux-backports-modules-2.6.24-21-generic fixed this bug completely for me. Plus, now I get to be mesmerized by the little blinking wireless LED.

Thanks, everyone! You all rock.

Hi @all,

S2R it really works now, flawlessly.

But as stated before, the blinking LED is also driving me nuts. My WLAN LED is blue an directly beneath my screen (it's more or less a 2nd WLAN LED, also known as the LED-lighted killswitch touchbutton (HP 6510b). Before the update the LED was NOT blinking, and it is also not blinking in Windows XP.

As this is really annoying, please fix it (at least for the HP models with touchbuttons)..

suspend to ram now works OK on my dell D630.

Resume from suspend still takes a bit of time (I'd say more than 30s), but I can make it resume almost instantly by switching to the graphic terminal manually (CTRL+ALT+F7). However, after a few seconds, the screen turns briefly black (and comes back to the gnome desktop. But this is a minor annoyance.

Thank you for fixing this bug.

Cyril

After the upgrade to linux-backports-modules-2.6.24-21-generic 2.6.24-21.27, suspend and resume, network manager did not see any network devices. I could not start any new X processed from within X (although Ctrl+Alt+F1 and DISPLAY=:0 xterm workded), running ifconfig -a or ip -a hung, running sudo -s hung, trying to suspend again didn't work (blank text-mode screen with backlight on and a blinking cursor, also a blinking thinkpad moon led; I could abort the suspend by pressing a key).

dmesg didn't show anything suspicious or iwl3945-related, but /var/log/kern.log showed the dmesg buffer was filled with ACPI error messages and the beginning was truncated:

  Oct 12 03:08:37 platonas kernel: [27278.472517] eth1: deauthenticate(reason=3)

was the last message before suspend, and this is the first ones after:

  Oct 12 13:05:48 platonas kernel: [27278r GPE[ D], disabling event [20070126]
  Oct 12 13:05:48 platonas kernel: [ 0.964529] ACPI Error (evgpe-0705): No handler or method for GPE[ D], disabling event [20070126]
  Oct 12 13:05:48 platonas kernel: [ 0.964553] ACPI Error (evgpe-0705): No handler or method for GPE[ D], disabling event [20070126]
  ...

I've seen these errors before upgrading linux-backports-modules. I vaguely remember them being related to snd-hda-intel, however sound worked fine.

I still have my hack in place which prevents rmmod iwl3945 on suspend; I'll remove it and see if things get better.

Unloading the module before suspending helped: I see no problems after a resume.

I got the same error of Buttay on an Asus F3Jc:
I have to manually switch to ctrl+alt+f7 in order to see the graphical terminal and the network manager do not reactivate automatically the network, I have do click on it and do "enable network".

I have an external monitor attached to my laptop and in the second monitor before switching to the graphical terminal I can see those error messages:
i8042 kbd 00:04: activation failed
i8042 aux 00:05: activation failed
hub 5-0:1.0: over-current change on port 7

Hoping this can help in some way

I am experiencing the same problem after upgrading to kernel 2.6.24-21 this morning. I posted a question (48094) seeking a solution for this issue. It has never happened in previous upgrades. Below is a copy of my question:

When I ran update manager this morning (10-15-08) my system upgraded to the kernel 2.6.24-21. Upon reboot my athi wifi card was no longer working so I reinstalled the madwifi files & rebooted again. When the system rebooted it stoped just short of the end on the status bar & the Caps Lock key light began to flash.

FYI-I am able to boot up using an earlier kernel (2.6.24-19) so this problem appears to be related to the kernel upgrade. This problem is also described in Bug 251252 but I saw no resolution as this is a new one problem due to the recent upgrade.

I am running 8.04 on a Compaq Presario 700 notebook.

Below are the steps & outputs (where indicated):

- Ran Update Mananger
- Rebooted into the latest kernel (2.6.24-21)
- Repaired athi card access using the following steps:
  - cd madwifi-ng-r2756+ar5007
  - make
  - sudo make install
  - sudo modprobe ath_pci
  - sudo reboot
- This is where the system locked up during the reboot process & where the Caps Lock light began to flash. The mouse pad light also goes from inactive to active. The system hangs in this mode indefinitely.

- Rebooted into 2.6.24-21-generic (recovery mode)
- Ran repair package option (dpkg)
- Rebooted and experienced the same problem
- Rebooted again into the 2.6.24-21-generic (recovery mode) to see what errors were occurring. Got the following message: kernel panic - not syncing fatal exception in intrupt

Is there a way to fix this issue or is a patch required? Thanks in advance for any help given in resolving this issue!

marcus

Marcus,
I read the same problem in Ubuntu-es forum, with that kernel update in Hardy and a Compaq Presario F700 (with Atheros AR5007EG).
The aparently solution is:
- Boot in recovery into kernel 2.6.24-21-generic
- Uninstall de madwifi driver with:
   - cd madwifi_directory (madwifi-ng-r2756+ar5007 or another version, like madwifi-hal-0.10.5.6)
   - sudo make uninstall
- Then install de linux-backports-modules for your kernel version. With this package you can use the wifi using the ath5k driver: run
- sudo modprobe ath5k
if it's necesary.

New ipw3945-driver seems to handle radio-killswitch rather poorly. When enabling the kill-switch, my system log gets spammed with the following message every two minutes:
...
Oct 20 13:42:58 blackelf kernel: [10667.455406] iwl3945: Radio disabled by HW RF Kill switch
Oct 20 13:42:58 blackelf kernel: [10667.455512] ACPI: PCI interrupt for device 0000:03:00.0 disabled
Oct 20 13:45:00 blackelf kernel: [10789.412748] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
...

Also, I've gotten problems with hibernate that seem related to new ipw3945, but nothing conclusive there, yet. I will file a new bug report. Just thought I'd get the initial feed-back in here, since many people are watching this.

I'm getting lots of this now, with kill-switch enabled:
[21624.503938] iwl3945: Radio disabled by HW RF Kill switch
[21624.503958] ACPI: PCI interrupt for device 0000:03:00.0 disabled
[21770.513386] irq 216, desc: c0418a80, depth: 0, count: 0, unhandled: 0
[21770.513397] ->handle_irq(): c01686a0, handle_bad_irq+0x0/0x290
[21770.513410] ->chip(): c03f48e0, no_irq_chip+0x0/0x40
[21770.513419] ->action(): 00000000
[21770.513422] IRQ_DISABLED set
[21770.513425] IRQ_MASKED set
[21770.513428] unexpected IRQ trap at vector d8
[21781.999634] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 21
[21781.999777] PM: Writing back config space on device 0000:03:00.0 at offset 1 (was 100102, writing 100106)

And I experience frequent hangs/lags while this is going on. Anyone else get this with the new iwl3945 driver from backports while using the radio kill-switch ?

Speaking as a new user to Ubuntu - I am using a preinstalled Thinkpad R61i. Are users like myself going to be officially notified when it is safe to go ahead with the update? I don't want to be in a position where I have to send my laptop back to my vendor (Linux Emporium) to get it fixed...

I have NOT updated yet - still running the -19 release, and switched off Recommended updates in Software Sources until it's confirmed fixed... and safe.

I have only ever run with Security and Recommended enabled.

I wouldn't have a clue as to how to resolve it...

on., 22.10.2008 kl. 06.00 +0000, skrev Alex Cockell:
> I have NOT updated yet - still running the -19 release, and switched off
> Recommended updates in Software Sources until it's confirmed fixed...
> and safe.
>
> I have only ever run with Security and Recommended enabled.
>
> I wouldn't have a clue as to how to resolve it...
>

I had to uninstall the latest backports-modules because the new
iwl3945-driver (wireless) included is just too buggy, breaks radio kill
switch, breaks hibernate, causes weird interrupts errors, and so on.. At
least on my hardware. Went back to the older one included with the
standard kernel, and it really works fine, so there is no reason for me
to install backports (guess I'm lucky) ..

Regards,
Øyvind

I'm also having issues with the -21 release.
I'm on an Acer Aspire 5720z.
problems started after I reloaded my wireless card driver.

I hope 8.10 is better than this.

On Tue, 2008-10-28 at 04:03 +0000, ArrrghJ wrote:
> I'm also having issues with the -21 release.
> I'm on an Acer Aspire 5720z.
> problems started after I reloaded my wireless card driver.
>
> I hope 8.10 is better than this.
>
8.10 uses the 2.6.27 kernel, and doesn't have this problem.
--
Chow Loong Jin

Hi Everyone,

This bug was originally about a kernel panic when unloading the iwl3945 driver. Based on numerous comments (comment 62, 72, 73, 75, 76, 78, 79, and 80) this appears to be resolved so I am marking it as such. If you are experiencing any other issues, please open a new report(s). It's helpful to the kernel team if bugs target one specific issue against a specific set of hardware. Some of you may also want to track bug 250211 regarding the led constantly blinking. I'll also close the "linux" task opened here as comment 92 (currently the last comment) notes this not being an issue for Intrepid. Thanks.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.