Ubuntu

ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"

Reported by gene on 2009-03-12
118
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Bugzilla
Invalid
Undecided
Unassigned
Linux
Fix Released
Medium
Fedora
In Progress
Unknown
linux (Baltix)
Undecided
Unassigned
linux (Ubuntu)
High
Manoj Iyer

Bug Description

After upgrading to jaunty I started experiencing frequent system/x server freezes.
Happens all of a sudden with X session completely frozen with no keys working, including SysRq. Hard reboot is necessary.
It is hard to tell what is the reason. Tried to examine the logs - doesn't give me a clue.
There are a number of suspicious entries in the /var/log/dmesg* though
All of them except for the current and the oldest ones are all ENDING with this:

  vmap allocation failed: use vmalloc=<size> to increase size.

Like:

~$ zgrep 'vmap' /var/log/dmesg* -A5
/var/log/dmesg.0:[ 35.911114] vmap allocation failed: use vmalloc=<size> to increase size.
/var/log/dmesg.1.gz:[ 31.707600] vmap allocation failed: use vmalloc=<size> to increase size.
/var/log/dmesg.2.gz:[ 38.358206] vmap allocation failed: use vmalloc=<size> to increase size.
/var/log/dmesg.3.gz:[ 91.715889] vmap allocation failed: use vmalloc=<size> to increase size.

Also I can recall that my memory icon in the gnome-system-monitor was filled (light and dark green ) at the time of crashes.

uname -a
Linux jenshen 2.6.28-8-generic #28-Ubuntu SMP Thu Mar 5 21:49:36 UTC 2009 i686 GNU/Linux

I will also attach some files like dmesg, and logs if needed

Thanks in advance

gene (eugenios) wrote :

Here's some attachments and also more lines (with -B4 option) of the dmesg logs

zgrep 'vmap' /var/log/dmesg* -A5 -B3; grep /var/log/dmesg*
/var/log/dmesg.0:[ 26.044801] type=1505 audit(1236820482.928:8): operation="profile_load" name="/usr/sbin/cupsd" name2="default" pid=2542
/var/log/dmesg.0:[ 26.164472] type=1505 audit(1236820483.051:9): operation="profile_load" name="/usr/sbin/tcpdump" name2="default" pid=2546
/var/log/dmesg.0:[ 35.748265] ppdev: user-space parallel port driver
/var/log/dmesg.0:[ 35.911114] vmap allocation failed: use vmalloc=<size> to increase size.
/var/log/dmesg.1.gz:[ 21.507996] type=1505 audit(1236806936.359:8): operation="profile_load" name="/usr/sbin/cupsd" name2="default" pid=2492
/var/log/dmesg.1.gz:[ 21.602293] type=1505 audit(1236806936.456:9): operation="profile_load" name="/usr/sbin/tcpdump" name2="default" pid=2496
/var/log/dmesg.1.gz:[ 31.402372] ppdev: user-space parallel port driver
/var/log/dmesg.1.gz:[ 31.707600] vmap allocation failed: use vmalloc=<size> to increase size.
/var/log/dmesg.2.gz:[ 28.180910] type=1505 audit(1236796504.056:8): operation="profile_load" name="/usr/sbin/cupsd" name2="default" pid=2585
/var/log/dmesg.2.gz:[ 28.260747] type=1505 audit(1236796504.139:9): operation="profile_load" name="/usr/sbin/tcpdump" name2="default" pid=2589
/var/log/dmesg.2.gz:[ 29.389626] apm: BIOS not found.
/var/log/dmesg.2.gz:[ 38.358206] vmap allocation failed: use vmalloc=<size> to increase size.
/var/log/dmesg.3.gz:[ 22.647052] type=1505 audit(1236739192.535:8): operation="profile_load" name="/usr/sbin/cupsd" name2="default" pid=2529
/var/log/dmesg.3.gz:[ 22.734347] type=1505 audit(1236739192.622:9): operation="profile_load" name="/usr/sbin/tcpdump" name2="default" pid=2533
/var/log/dmesg.3.gz:[ 83.344921] apm: BIOS not found.
/var/log/dmesg.3.gz:[ 91.715889] vmap allocation failed: use vmalloc=<size> to increase size.

gene (eugenios) wrote :

I also tried to examine all entries prior to the system boots by grep '0\.000000' /var/log/* -B10 | grep -v '0\.000000' -A4
I attach its output
Thanks

Since I have been experiencing a bunch of other problems with my video card from ATI ( RC410 [Radeon Xpress 200M] [1002:5a62]) , the problem could be related to it. I will attach my xorg.conf

gene (eugenios) wrote :

Forgot to mention that:
In the time of crash when attempting to ssh to the machine from another computer I get "no host to route" message
Another thing is that the whole desktop seems completely frozen (gnome widgets etc), however the screen does not get blank

Changed in linux:
status: Unknown → Confirmed
gene (eugenios) wrote :

Yesterday I made an attempt to bring my system to crash by putting it under stress. I simultaneously opened about 500 tabs with both firefox and konqueror (1000 together). The memory was all occupied, making the system to start swapping .
System slowed down and even I thought it was it: it stopped for about a minute or so. But then it was back. NO CRASH here

However, this morning It woke up from the suspend and I noticed that nm-applet was trying to connect. I clicked on it and there you go I got my favorite crash. System solidified. I could see the time Mar 13 10:17.

So I grep-ed the logs and saw ath5k module in use by the kernel.

Could it be it. I remember that I could not install intrepid on another computer (compaq) because of the faulty atheros module. One had to blacklist it in order to install and substitute by another module to be able to use wireless.

I attach the log file below.

I did not see vmap error message in dmesg this time

gene (eugenios) wrote :

Hello all,
I have a question. Does anybody care at all? If not, what's the purpose of installing alpha in the first place?
I report a very important problem that might be jeopardizing the release of jaunty itself.... and still talking to myself

It is not a problem of impossibility to use eye-candy compiz features or some other laughable issues. It is the system crash all of a sudden! Kernel is dead. This what makes M$ Windows Windows....

When I converted to Linux/Unix, I hardly can recall of any crashes (Fedora Core 4). Nowadays it is pretty occasional. I understand that it mostly concerns video and other hardware drivers, mostly proprietary or back-engineered ones.

So could I get some sort of feedback at least? How do I debug the kernel? How do I debug some of its suspicious modules at least? Hope to hear from anyone...

Thanks in advance

Changed in bugzilla:
status: Unknown → Confirmed

Hi Gene,

Thanks for taking the time to report this bug and helping to make Ubuntu better. The reason this bug was likely getting overlooked was because it was assigned to the entire Ubuntu project as a whole rather than against the specific kernel package (linux). It is important to make sure bugs are filed against a specific package to help ensure it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I'll go ahead and reassign this to the "linux" kernel package.

If you could please attach your entire dmesg output to this report that would be great. Also, after you experience this freeze and need to reboot, can you take a look and see if anything like a kernel oops or a kernel panic is logged to /var/log/kern.log.0 ? You also mention you think this may be related to your wireless driver. What happens if you unload the driver?

sudo rmmod ath5k

Are you able to reproduce the crash/freeze? Please let us know your results. Thanks.

Changed in linux:
status: New → Incomplete
gene (eugenios) wrote :

Hi Leann,
Thanks a lot for your response! This is what I hoped for.

I will do as you suggest. There were no "oops" messages in any log files. I came across the bug description against the bugzill.kernel (http://bugzilla.kernel.org/show_bug.cgi?id=12647) project which I linked to. No suspicious entries like "kernel panic/oops/crash". ALL of the crashes though end with "ath5k phy0: noise floor calibration timeout" This is how I found this bug description.

I will see what I can do myself. There is a patch at http://bugzilla.kernel.org/show_bug.cgi?id=12647 I should study it more carefully.

I tried to unload the module by "sudo modprobe -r ath5k" but I had to go back to "-i" in order to get wireless working. What is ath9k there?
Thank you much again and hope I will be of any help to Ubuntu and GNU/Linux!

gene (eugenios) wrote :
gene (eugenios) wrote :

I do not know how o reproduce the bug. It happens out of blue... seemingly. Like I said I will study what other people did at bugzilla.kernel and let you know.

Should I switch to ethernet interface though...

Thanks

Changed in linux:
status: Confirmed → Unknown
Changed in bugzilla:
importance: Unknown → Undecided
status: Confirmed → New
status: New → Invalid
Changed in linux:
status: Unknown → Confirmed

Hi gene,

If you want switch to testing with just the wired ethernet for a while just to try to confirm this is related to wifi that would be great. Additionally, you may want to try installing linux-backports-modules-jaunty as it contains an updated compat-wireless stack. Thanks.

gene (eugenios) wrote :

Thanks Leann,
You just anticipated my exact question!

I've been using ethernet for about 2 days. No crashes so far. As well as entries like the logs: "ath5k phy0: noise floor calibration timeout"

I have read some of the related bug threads where you advised to use backports. I will try installing that as well.

Thank you!

gene (eugenios) wrote :
Download full text (5.4 KiB)

Hi Leann,
I installed backport modules a couple days ago. Since then no system lock-ups so far.
However, I noticed somewhat worse performance of wireless. Sometimes, when I try to connect via ssh/sft/http I fail. But when switching to the ethernet- everything goes smooth again.
I also started seeing my "favorite" entry in the kernel log:

  grep ath5k /var/log/kern.log | grep 'Mar 16'
Mar 16 00:08:46 jenshen kernel: [ 2485.843137] ath5k 0000:09:04.0: PCI INT A disabled
Mar 16 00:08:46 jenshen kernel: [ 2487.464146] ath5k 0000:09:04.0: restoring config space at offset 0xf (was 0x1c0a0100, writing 0x1c0a010a)
Mar 16 00:08:46 jenshen kernel: [ 2487.464179] ath5k 0000:09:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xc0110000)
Mar 16 00:08:46 jenshen kernel: [ 2487.464187] ath5k 0000:09:04.0: restoring config space at offset 0x3 (was 0x0, writing 0xa808)
Mar 16 00:08:46 jenshen kernel: [ 2487.464197] ath5k 0000:09:04.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900016)
Mar 16 00:08:46 jenshen kernel: [ 2487.480025] ath5k 0000:09:04.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Mar 16 11:20:58 jenshen kernel: [ 3984.021196] ath5k 0000:09:04.0: PCI INT A disabled
Mar 16 11:20:58 jenshen kernel: [ 3985.524776] ath5k 0000:09:04.0: restoring config space at offset 0xf (was 0x1c0a0100, writing 0x1c0a010a)
Mar 16 11:20:58 jenshen kernel: [ 3985.524809] ath5k 0000:09:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xc0110000)
Mar 16 11:20:58 jenshen kernel: [ 3985.524817] ath5k 0000:09:04.0: restoring config space at offset 0x3 (was 0x0, writing 0xa808)
Mar 16 11:20:58 jenshen kernel: [ 3985.524828] ath5k 0000:09:04.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900016)
Mar 16 11:20:58 jenshen kernel: [ 3985.540647] ath5k 0000:09:04.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Mar 16 11:24:15 jenshen kernel: [ 4183.354295] ath5k phy0: noise floor calibration timeout (2447MHz)
Mar 16 12:10:37 jenshen kernel: [ 5242.196583] ath5k 0000:09:04.0: PCI INT A disabled
Mar 16 12:10:37 jenshen kernel: [ 5243.784165] ath5k 0000:09:04.0: restoring config space at offset 0xf (was 0x1c0a0100, writing 0x1c0a010a)
Mar 16 12:10:37 jenshen kernel: [ 5243.784198] ath5k 0000:09:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xc0110000)
Mar 16 12:10:37 jenshen kernel: [ 5243.784205] ath5k 0000:09:04.0: restoring config space at offset 0x3 (was 0x0, writing 0xa808)
Mar 16 12:10:37 jenshen kernel: [ 5243.784216] ath5k 0000:09:04.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900016)
Mar 16 12:10:37 jenshen kernel: [ 5243.800043] ath5k 0000:09:04.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Mar 16 17:58:24 jenshen kernel: [25687.813949] ath5k 0000:09:04.0: PCI INT A disabled
Mar 16 17:58:24 jenshen kernel: [25689.404166] ath5k 0000:09:04.0: restoring config space at offset 0xf (was 0x1c0a0100, writing 0x1c0a010a)
Mar 16 17:58:24 jenshen kernel: [25689.404200] ath5k 0000:09:04.0: restoring config space at offset 0x4 (was 0x0, writing 0xc0110000)
Mar 16 17:58:24 jenshen kernel: [25689.404207] ath5k 0000:09:04.0: restoring config space at offset 0x3 (was 0x0, writing 0xa808)
...

Read more...

gene (eugenios) wrote :

I noticed I can't ssh from my machine with wireless. Apparently, when using wireless, I have a zero upload and a descent download rate equal to that on wired connection.
On ethernet, there is no problem with upload. I can test the same router with another laptop running Ubuntu 8.10 - no problem with the wireless there.

gene (eugenios) wrote :

I noticed I can't ssh from my machine with wireless. Apparently, when using wireless, I have a zero upload and a descent download rate equal to that on wired connection.
On ethernet, there is no problem with upload. I can test the same router with another laptop running Ubuntu 8.10 - no problem with the wireless there.
Actually, I could not save changes to this post without using the wired connection

gene (eugenios) wrote :

Let me know if I should file another bug here
Thanks

xtknight (xt-knight) wrote :

Yes, ath5k hard-freezes my entire system. Even Magic SysRq won't work. Very frustrating. It didn't used to do this.

If you don't need wireless, simply blacklist ath5k in any of the /etc/modprobe.d/blacklist* files to stop it from loading on bootup.

gene (eugenios) wrote :

I do not have to blacklist it. But I do need wireless. With the latest kernel *28-11 and backports it does not seem to hurt my system anymore.

There is another problem introduced here though.

I noticed that when using WEP encryption I have problems with connection. At the moment I think I have a zero upload rate.

And here I ask again, do I have to report this as a separate bug? I do see the same entries in the dmesg and kernel logs.

gene (eugenios) wrote :

I got an update here.
Not only that ath5k does not so any job (with WEP) it still crashes my system. I had it once again! So the updated kernel and ath5k driver do not get together still.
As I have mentioned many times before, the kernel log complains about ath5k. Especially, before its own "death"....
Let me know if you want this log from me

gene (eugenios) wrote :

Hi Leann,
So what do we do next?
Thanks

gene (eugenios) wrote :
Download full text (3.7 KiB)

Dear Leann,
I got yet another crash today after just a few hours of fresh session. I was using wireless with no encryption. I do not have ethernet here.
The agonizing kernel entries of the kernel log are these (followed by the boot messages):
Mar 22 19:12:06 jenshen kernel: [28185.688033] wlan0: associate with AP f61b66a8
Mar 22 19:12:06 jenshen kernel: [28185.689771] wlan0: RX AssocResp from c9ba202a (capab=0x401 status=12 aid=0)
Mar 22 19:12:06 jenshen kernel: [28185.689779] wlan0: AP denied association (code=12)
Mar 22 19:12:06 jenshen kernel: [28185.888048] wlan0: association with AP f61b66a8 timed out
Mar 22 19:12:34 jenshen kernel: [28214.066629] wlan0: authenticate with AP f61b66a8
Mar 22 19:12:34 jenshen kernel: [28214.071865] wlan0: authenticated
Mar 22 19:12:34 jenshen kernel: [28214.071875] wlan0: associate with AP f61b66a8
Mar 22 19:12:34 jenshen kernel: [28214.074175] wlan0: RX AssocResp from f6f8902a (capab=0x401 status=12 aid=0)
Mar 22 19:12:34 jenshen kernel: [28214.074184] wlan0: AP denied association (code=12)
Mar 22 19:12:35 jenshen kernel: [28214.268063] wlan0: associate with AP f61b66a8
Mar 22 19:12:35 jenshen kernel: [28214.269934] wlan0: RX AssocResp from de4cc02a (capab=0x401 status=12 aid=0)
Mar 22 19:12:35 jenshen kernel: [28214.269943] wlan0: AP denied association (code=12)
Mar 22 19:12:35 jenshen kernel: [28214.468612] wlan0: associate with AP f61b66a8
Mar 22 19:12:35 jenshen kernel: [28214.470933] wlan0: RX AssocResp from de4ce02a (capab=0x401 status=12 aid=0)
Mar 22 19:12:35 jenshen kernel: [28214.470942] wlan0: AP denied association (code=12)
Mar 22 19:12:35 jenshen kernel: [28214.668048] wlan0: association with AP f61b66a8 timed out
Mar 22 19:12:38 jenshen kernel: [28217.883610] wlan0: authenticate with AP f61b66a8
Mar 22 19:12:38 jenshen kernel: [28217.883666] wlan0: authenticate with AP f61b66a8
Mar 22 19:12:38 jenshen kernel: [28217.885783] wlan0: authenticated
Mar 22 19:12:38 jenshen kernel: [28217.885791] wlan0: associate with AP f61b66a8
Mar 22 19:12:38 jenshen kernel: [28217.889754] wlan0: RX AssocResp from dfd5202a (capab=0x401 status=0 aid=2)
Mar 22 19:12:38 jenshen kernel: [28217.889762] wlan0: associated
Mar 22 19:15:44 jenshen kernel: [28403.419054] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 19:21:24 jenshen kernel: [28743.435328] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 19:25:24 jenshen kernel: [28983.423238] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 19:29:24 jenshen kernel: [29223.490565] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 19:33:12 jenshen kernel: [29451.473833] ath5k phy0: unsupported jumbo
Mar 22 19:41:24 jenshen kernel: [29943.427415] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 19:45:24 jenshen kernel: [30183.414603] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 19:51:24 jenshen kernel: [30543.431222] ath5k phy0: noise floor calibration timeout (2462MHz)
Mar 22 20:09:25 jenshen kernel: Inspecting /boot/System.map-2.6.28-11-generic
Mar 22 20:09:25 jenshen kernel: Cannot find map file.
Mar 22 20:09:25 jenshen kernel: Loaded 55383 symbols from 43 modules.
Mar 22 20:09:25 jenshen ker...

Read more...

gene (eugenios) wrote :

I am not making it up, or am I?

Changed in linux:
status: Incomplete → Confirmed
Romain1101 (romainmadala) wrote :

Hi,

I just updated my system this afternoon and now it gets freezing sometimes without any obvious reason.

my system :

Linux MadPrt-010909 2.6.28-11-generic #36-Ubuntu -- with KDE "kubuntu" jaunty
pkg : linux-image version 2.6.28.11.13

I put this here as I'm not sure to be able to determine the right pkg affected

Furthermore I can't succeed in retreiving any stack trace or bug report from my system.

I just remarked something strange in my kernel log but can't explain it:

----------------------------------------------------------------------------------------------

If someone may help me, he's welcome !

Romain1101 (romainmadala) wrote :

Now I may succeed in reproduce it :

using skype then launching skysentials.py ( released tool on skype project to send sms)

and then appears in kern.log :
Mar 23 20:42:40 MadPrt-010909 kernel: [ 8722.832729] process `skype' is using obsolete setsockopt SO_BSDCOMPAT

Then system freezes, blackscreen ! Using Ctrl+Alt+XXX doesn't work anymore
I cannot even come back to a console using ctrl+alt+F#.

Maybe could have a link with some python compatibility.

Someone know how to check what are the exact packages I updated this afternoon ?Is there any log of adept of aptitude ?

Romain1101 (romainmadala) wrote :

Well It's not only linked to skype

Trying now to attach my file I forgot to put in my first post comes to the same bad result -> blackscreen with a working-like system and no responses to actions on the keyboard.

I'm gonna post this and then try to attach my file :-)

gene (eugenios) wrote :

Romain,
Check if you get similar entries in the /var/log/kern.log, like,
ath5k phy0: noise floor calibration timeout (2462MHz)
Otherwise, it is a different issue.
If it is, the very last entries in your logs before the crash might tell you what went wrong, like in my case.

Changed in linux (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
Romain1101 (romainmadala) wrote :
Download full text (5.0 KiB)

No I haven't any similar entry !

The most surprising part in my kern.log ( which I can't succeed to attach because when it start opening location select window it freezes!) is that one :

-----------------------------------
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641774] irq 11: nobody cared (try booting with the "irqpoll" option)
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641782] Pid: 6, comm: events/0 Not tainted 2.6.28-11-generic #36-Ubuntu
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641785] Call Trace:
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641793] [<c0500ab1>] ? printk+0x18/0x1f
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641799] [<c017fc47>] __report_bad_irq+0x27/0x90
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641803] [<c017fe0e>] note_interrupt+0x15e/0x1a0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641807] [<c017e9d9>] ? handle_IRQ_event+0x39/0x70
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641811] [<c0180823>] handle_level_irq+0xc3/0xf0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641816] [<c010684e>] do_IRQ+0x7e/0xa0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641819] [<c01051f3>] common_interrupt+0x23/0x30
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641823] [<c017e9b6>] ? handle_IRQ_event+0x16/0x70
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641827] [<c01807d4>] handle_level_irq+0x74/0xf0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641830] [<c010684e>] do_IRQ+0x7e/0xa0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641835] [<c0127c7d>] ? update_curr+0x8d/0x1e0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641838] [<c01051f3>] common_interrupt+0x23/0x30
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641842] [<c012007b>] ? hpet_rtc_timer_init+0xfb/0x100
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641847] [<c0502d4d>] ? _spin_unlock_irqrestore+0x1d/0x40
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641855] [<e0900a5c>] set_phy_reg+0x7c/0xc0 [ohci1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641860] [<e090099b>] ? get_phy_reg+0x7b/0xc0 [ohci1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641880] [<e08bcf5d>] ? csr1212_fill_cache+0xdd/0x160 [ieee1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641891] [<e08b5640>] ? delayed_reset_bus+0x0/0xd0 [ieee1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641896] [<e090128e>] ohci_devctl+0x14e/0x200 [ohci1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641908] [<e08b3019>] hpsb_reset_bus+0x19/0x20 [ieee1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641918] [<e08b56d3>] delayed_reset_bus+0x93/0xd0 [ieee1394]
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641923] [<c014af4d>] run_workqueue+0x8d/0x150
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641927] [<c014eeaa>] ? prepare_to_wait+0x3a/0x70
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641931] [<c014b1c8>] worker_thread+0x88/0xf0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641934] [<c014ec50>] ? autoremove_wake_function+0x0/0x50
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641938] [<c014b140>] ? worker_thread+0x0/0xf0
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641941] [<c014e8ac>] kthread+0x3c/0x70
Mar 23 16:12:08 MadPrt-010909 kernel: [ 5.641945] [<c014e870>] ? kthread+0x0/0x70
...

Read more...

gene (eugenios) wrote :

Romain,
Check those, that predate the entries 0.000000 (with big numbers before "."). Are you sure your kernel gets dead?
Also, in order to make sure you have none of my headaches:

$grep ath5k /var/log/kern.log

Then you will see if there is anything.

I suspect in your situation, you got a metacity problem. So you should look for similar symptoms on the net and/or here. And you might want to report a separate bug. Try ssh-ing to your machine when you experience the problem.

Hope it helps.

gene (eugenios) wrote :

I would google this ominous entry in your ker.log:

"Mar 23 16:10:35 MadPrt-010909 kernel: [ 921.661361] kwalletmanager[3215]: segfault at 0 ip b674a840 sp bfc4bd10 error 4 in libQtCore.so.4.5.0[b65e0000+238000]"
It might be related to gtk (if it is, or qt, if its kde ) +skype, since things crash when you manipulate a window

It tells you that it segfaults, this hurts. However, this might easier to troubleshoot than in my case. Ne segfault entries.

If you can't find it on the launchpad, I suggest you open a new bug.
Alternatively, deinstall skype and use linphone or gnome-meeting :)

Good luck!

Download full text (4.1 KiB)

Thanks gene !

Indeed that line in kern.log is strange and therefore interesting but It does not occurs
everytime with my failure whereas that paragraph about the IRQ11 - which already provided troobles
to me in previous versions of ubuntu because of my ethernet card - really is.

Furthermore...I updated my system this morning with the new linux-image pkg
and I may have understood something, which i'm gonna explain to you :
I've been experiencing for weeks a reboot of my X server...sometimes, dont know whether it's kde, plasma
or xorg but something crashes and then I'm sent back to the KDE login screen.
And I think this is the same bug, and that the problem yesterday was simply that my xserver couldn't restart on its own!
Because as you says, I think I just lose the interface with the system - that the system keeps working.
I'll try to ssh my system from outside, I guess we will be right.

Do you know if there is a mean ( a shell command ) to inspect the tty output used
you by default kde uses the #7 and then you can go back to a pure console using ctrl+alt+F#
because I have the impression that my all problem comes from either kde or plasma ( who knows maybe deeply from qtcore)
and comes to log on a diferent tty ? As well just to check, could you remind me a shell command which permits to
check the memory status of my system in real time ?

I'll try as well launch a session by my own so as to get back some trace...
Do you have any idea how I could better get back some traces ?
Because I didn't succeed to get some when my xserver reboots...never succeed to know why !!

about ath5, I don't understand your query because my wireless driver is ipw2200 with an intel card ?

----- Mail Original -----
De: "gene" <email address hidden>
À: <email address hidden>
Envoyé: Mardi 24 Mars 2009 14h51:07 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: [Bug 341952] Re: ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"

I would google this ominous entry in your ker.log:

"Mar 23 16:10:35 MadPrt-010909 kernel: [ 921.661361] kwalletmanager[3215]: segfault at 0 ip b674a840 sp bfc4bd10 error 4 in libQtCore.so.4.5.0[b65e0000+238000]"
It might be related to gtk (if it is, or qt, if its kde ) +skype, since things crash when you manipulate a window

It tells you that it segfaults, this hurts. However, this might easier
to troubleshoot than in my case. Ne segfault entries.

If you can't find it on the launchpad, I suggest you open a new bug.
Alternatively, deinstall skype and use linphone or gnome-meeting :)

Good luck!

--
ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"
https://bugs.launchpad.net/bugs/341952
You received this bug notification because you are a direct subscriber
of the bug.

Status in The Bugzilla Bug Tracking System: Invalid
Status in The Linux Kernel: Confirmed
Status in “linux” source package in Ubuntu: Triaged
Status in Fedora: Confirmed

Bug description:
After upgrading to jaunty I started experiencing frequent system/x server freezes.
Happens all of a sudden with X session completely frozen with no keys working, including SysRq. Hard reboot is necessary.
It is...

Read more...

Romain1101 (romainmadala) wrote :
Download full text (6.4 KiB)

Well,

The failure keeps occuring ! My screen freezes, only the mouse can move but keep its current icon when occurs the failure and neither keyboard nor mouse respond to events!
The only thing I am able to do is a hard reboot of the machine.

Well the failure may be witnessed on the .xsession-error log.

Please help, or at least can someone tell me what package I have to link to this bug?

----- Mail Original -----
De: "Romain1101" <email address hidden>
À: <email address hidden>
Envoyé: Mardi 24 Mars 2009 16h10:40 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [Bug 341952] Re: ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"

Thanks gene !

Indeed that line in kern.log is strange and therefore interesting but It does not occurs
everytime with my failure whereas that paragraph about the IRQ11 - which already provided troobles
to me in previous versions of ubuntu because of my ethernet card - really is.

Furthermore...I updated my system this morning with the new linux-image pkg
and I may have understood something, which i'm gonna explain to you :
I've been experiencing for weeks a reboot of my X server...sometimes, dont know whether it's kde, plasma
or xorg but something crashes and then I'm sent back to the KDE login screen.
And I think this is the same bug, and that the problem yesterday was simply that my xserver couldn't restart on its own!
Because as you says, I think I just lose the interface with the system - that the system keeps working.
I'll try to ssh my system from outside, I guess we will be right.

Do you know if there is a mean ( a shell command ) to inspect the tty output used
you by default kde uses the #7 and then you can go back to a pure console using ctrl+alt+F#
because I have the impression that my all problem comes from either kde or plasma ( who knows maybe deeply from qtcore)
and comes to log on a diferent tty ? As well just to check, could you remind me a shell command which permits to
check the memory status of my system in real time ?

I'll try as well launch a session by my own so as to get back some trace...
Do you have any idea how I could better get back some traces ?
Because I didn't succeed to get some when my xserver reboots...never succeed to know why !!

about ath5, I don't understand your query because my wireless driver is
ipw2200 with an intel card ?

----- Mail Original -----
De: "gene" <email address hidden>
À: <email address hidden>
Envoyé: Mardi 24 Mars 2009 14h51:07 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: [Bug 341952] Re: ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"

I would google this ominous entry in your ker.log:

"Mar 23 16:10:35 MadPrt-010909 kernel: [ 921.661361] kwalletmanager[3215]: segfault at 0 ip b674a840 sp bfc4bd10 error 4 in libQtCore.so.4.5.0[b65e0000+238000]"
It might be related to gtk (if it is, or qt, if its kde ) +skype, since things crash when you manipulate a window

It tells you that it segfaults, this hurts. However, this might easier
to troubleshoot than in my case. Ne segfault entries.

If you can't find it on the launchpad, I suggest you open a ne...

Read more...

unggnu (unggnu) wrote :

I think I can confirm this. The driver ath5k seems to be very bad in Jaunty. System freezes regularly especially when downloading something and if you use ping many packets get lost.

This seems to be fixed in 2.6.29 but this kernel version breaks the suspend and the driver can't be backported so easily.

unggnu (unggnu) wrote :

I am not sure if all have the same bug. I can confirm mine easily through the follow three steps.

1.While downloading the 2.6.29 source code to get the driver my system freezes two times. So starting a big download.
2.Ping your router. Most of the time at least 10% of the packets got lost with 2.6.28. No lost ping with 2.6.29 so far while one or two packets are pretty normal for wlan I guess.
3.Check if the freezes are gone with 2.6.29 kernel from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29/ .

Linux linux 2.6.29-020629-generic #020629 SMP Tue Mar 24 11:23:53 UTC 2009 x86_64 GNU/Linux

04:01.0 Ethernet controller [0200]: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter [168c:0013] (rev 01)
 Subsystem: Atheros Communications Inc. Device [168c:2051]
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 19
 Region 0: Memory at e7100000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [44] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=2 PME-
 Kernel driver in use: ath5k
 Kernel modules: ath5k
 Kernel driver in use: ath5k
 Kernel modules: ath5k

gene (eugenios) wrote :

I noticed it too, that besides regular system crashes ath5k gets "sluggish", as I it seems to have 0 upload and OK download (compared to wired connection).
The problem occurs though not right away, one just needs to wait a day or so....
Tried pinging and got 0% packets lost so far
I will now try to download a heavy file.
Let you know
My question to unggnu is though, do you see in your kern.log stuff like

"ath5k phy0: noise floor calibration timeout"
If you do, you can read this thread linux-kernel-bugs #12647

gene (eugenios) wrote :

Yes ath5k barely works. I could not save the previos comment on it.

As a result of my test I downloaded http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29/linux-image-2.6.29-020629-generic_2.6.29-020629_i386.deb

in 9.7 sec on the wired connection (2.32MB/s)
in 49 secs on the wireless connection (468 KB/s)
And I cannot blame my router, since it can easily handle 2.7MB/s (with madwifi driver)

gene (eugenios) wrote :

Yes ath5k barely works. I could not save the previos comment on it.

As a result of my test I downloaded http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29/linux-image-2.6.29-020629-generic_2.6.29-020629_i386.deb with wget

in 9.7 sec on the wired connection (2.32MB/s)
in 49 secs on the wireless connection (468 KB/s)
And I cannot blame my router, since it can easily handle 2.7MB/s (with madwifi driver)

gene (eugenios) wrote :

the same file in 21 secs on wireless without encryption (1.06 MB/s)

unggnu (unggnu) wrote :

No, I don't get the message so I have to open a new bug report for it I guess.

unggnu (unggnu) wrote :

Installing the linux backport modules seem to fix my problem. I think the newer ath5k should be integrated in the Ubuntu kernel instead of putting it into a separate package because of the huge impact.
Btw. the ath5k from backport modules can't use channel 12/13 but the default and the 2.6.29 can.

gene (eugenios) wrote :

Got another crash, although I barely use ath5k. I used to be able to connect to some open wireless networks at home, now I can't but it still kills my kernel once in a while.

I think that ath5k should not be allowed in the release of jaunty, since it so buggy and may crash the system.
I have had a bad experience with it already, when I could not install Ubuntu 8.10 on a Compaq laptop. One had to blacklist it.
I will try to go back to madwifi. It is a pity, it is not open source, however it works and does not freeze my system all of a sudden.
As I figured from this thread https://bugzilla.redhat.com/show_bug.cgi?id=489078, people do not realize how faulty ath5k is (blaming wifi card and so). At the same time I think people here at Ubuntu do not seem to help them to point to this problem.

gene (eugenios) wrote :

Sorry, I meant the kernel bugs thread http://bugzilla.kernel.org/show_bug.cgi?id=12647, not redhat

unggnu (unggnu) wrote :

Because of the difference I have created a new bug report for my problem under Bug #350137.

You could try installing the package "linux-backports-modules-jaunty". It worked at least in my case. I guess this is similar to the ath5k module shipped with 2.6.29.

Changed in linux:
status: Confirmed → Fix Released
Manoj Iyer (manjo) on 2009-04-03
Changed in bugzilla:
assignee: nobody → manjo
Mark Cariaga (mzc) wrote :

Bug has resurfaced after April 14 updates: "ath5k phy0: noise floor calibration timeout"

device: Acer aspire one 110 8gb ssd 1.5gb ram

Atheros wifi card. i will try to install backports module.

coubi64 (frederic-valentin) wrote :

Same problem for me:

[ 13.036246] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
[ 131.523793] wlan0: authenticate with AP a2:65:1e:8f:18:18
[ 131.526314] wlan0: authenticated
[ 131.526321] wlan0: associate with AP a2:65:1e:8f:18:18
[ 131.529580] wlan0: RX AssocResp from a2:65:1e:8f:18:18 (capab=0x411 status=0 aid=1)
[ 131.529588] wlan0: associated
[ 131.532307] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 132.168341] padlock: VIA PadLock not detected.
[ 441.123475] ath5k phy0: unsupported jumbo
[ 695.067573] ath5k phy0: noise floor calibration timeout (2462MHz)
[ 1278.935026] ath5k phy0: unsupported jumbo
frederic@frederic-desktop:~$ uname -a
Linux frederic-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
frederic@frederic-desktop:~$

mp (m-p) wrote :

I came to this bug report, because I also experience systems freezes / crashes. Never happened on this laptop with neither Hardy nor Intrepid, but with Jaunty it has happened three times already. Just now it happened with Wifi disabled in NM and with the hardware button in OFF. (Which doesnt mean that it can't be WIFI related, of course).

I have examined dmesg logs, but there isn't anything obvious to me.

There are definite problems with the ATI Open Source driver and I am using the same video card as the bug reporter (X200m). The Live-CD would only run in Safe Graphics Mode, from where I had to install. Then I had to log in to Recovery Mode and modify Xorg.conf (change driver option from MESA to ati). After that the system booted, but without the Gnome panels and with a dead desktop (no right clicking etc.). Then via ALT+F2 I called up gnome-system-settings and went to display and activated the screen, which was greyed out in the dialog window, by clicking on it. After another reboot the the desktop loaded OK and I could, finally, set the right screen resolution. Quite a task to get this thing up and running. Also, if I log out of the sessionm, the screen just blinks and goes black for a few seconds, then logs me back in.

mp (m-p) wrote :
Giovanni Bajo (giovannibajo) wrote :

I have the same problem with ath5k. This is an excrept of my dmesg:

[ 66.178325] ath5k phy0: noise floor calibration timeout (2442MHz)
[ 66.285455] ath5k phy0: noise floor calibration failed (2447MHz)
[ 66.393691] ath5k phy0: noise floor calibration failed (2452MHz)
[ 66.532438] ath5k phy0: noise floor calibration failed (2457MHz)

This is the ping to my router:

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=26.3 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=30.2 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=28.5 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=24.9 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=21.7 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=73.1 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=67.9 ms

(should be < 1ms).

I have installed linux-backports-modules-jaunty (2.6.28.11.15) but nothing changed.

Linux ozzu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

Just upgraded to Jaunty... :(

gene (eugenios) wrote :

My suggestion is to use ath_pci (madwifi). Although it is not 100% FOSS, it is not known to crash the whole system. I haven't had any problems with that since installed madwifi on the beta jaunty.

Giovanni Bajo (giovannibajo) wrote :

I don't have lockup problems but serious performance problems. I tried all of the following:

 * Installing linux-jaunty-backports-generic
 * Installing madwifi SVN trunk as of today (and activating it with jockey)
 * Installing madwifi snapshot of 22 April 2009

I get this horrible ping to my gateway:

--- 192.168.1.1 ping statistics ---
20 packets transmitted, 18 received, 10% packet loss, time 19057ms
rtt min/avg/max/mdev = 1.906/33.707/343.094/76.057 ms

With a ethernet cable:

--- 192.168.1.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6000ms
rtt min/avg/max/mdev = 0.436/0.461/0.594/0.056 ms

Before upgrading to Jaunty, I had a perfect flat ping with atheros as well.

gene (eugenios) wrote :

I remember having these problems too. With the better performance, can you tell if it was the ath5k driver module or ath_pci? Nevertheless, you could try madwifi anyways. Just check the restricted drivers (or hardware drivers).

gene (eugenios) wrote :
Download full text (3.1 KiB)

Sorry, did not notice you did have installed ath_pci. But can you compare ath5k vs. ath_pci ping performance. When I get toping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=1 ttl=240 time=40.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=2 ttl=240 time=40.4 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=3 ttl=240 time=40.2 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=4 ttl=240 time=40.1 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=5 ttl=240 time=40.2 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=6 ttl=240 time=39.9 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=7 ttl=240 time=40.3 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=8 ttl=240 time=40.1 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=9 ttl=240 time=40.3 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=10 ttl=240 time=39.9 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=11 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=12 ttl=240 time=39.8 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=13 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=14 ttl=240 time=39.8 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=15 ttl=240 time=39.8 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=16 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=17 ttl=240 time=39.9 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=18 ttl=240 time=40.2 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=19 ttl=240 time=40.8 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=20 ttl=240 time=40.2 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=21 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=22 ttl=240 time=40.0 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=23 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=24 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=25 ttl=240 time=40.0 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=26 ttl=240 time=40.1 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=27 ttl=240 time=39.7 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=28 ttl=240 time=40.1 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=29 ttl=240 time=40.2 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=30 ttl=240 time=40.2 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=31 ttl=240 time=40.0 ms
^C
--- google.com ping statistics ---
31 packets transmitted, 31 received, 0% packet loss, time 30044ms
rtt min/avg/max/mdev = 39.709/40.080/40.829/0.357 ms
, I most of the time see 0% loss.

Sometimes though, I get up to 5%. I do not see much difference between them now. I had, when noticing almost 0 upload rate on ath5k. This might have been fix...

Read more...

Giovanni Bajo (giovannibajo) wrote :

I noticed that, immediately after booting the computer, ath_pci (madwifi) works correctly, but then it starts degrading in performance (both latency and bandwidth) and in a few minutes it's back to a horrible state like this:

--- 192.168.1.1 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17026ms
rtt min/avg/max/mdev = 2.530/5.401/12.738/2.476 ms

(notice: this is the gateway and it's always been stable < 1ms in ubuntu hardy usually). Speed tests go from an optimum 6/1 Mbit (which is my nominal speed) to 1/0.128.

$ lsmod | grep ath
ath_rate_sample 21888 1
ath_pci 224832 0
wlan 259232 5 wlan_tkip,wlan_scan_sta,ath_rate_sample,ath_pci
ath_hal 339088 3 ath_rate_sample,ath_pci
multipath 16512 0

I'm using this snapshot: madwifi-hal-0.10.5.6-r4016-20090429.

Can somebody please certify which exact driver was being used by Ubuntu Hardy? Was it MadWifi? If so, which exact version/snapshot? I would like to test with that exact driver. Otherwise, I'll have to assume that running "ath5" once on my card misconfigured it in a way that madwifi is not able to recover anymore.

Victor (psycovic) wrote :

Hi,

I've been having freezing problems also, even after switching from ath5 to madwifi. Not only that, but sometimes Amarok just starts skipping a little bit, but I'm not sure if this is from the wireless driver. I don't have the bad performance though (unless I'm just used to shitty internet). Any ideas as to how to see what's causing Amarok to skip?

gene (eugenios) wrote :

Victor,
I do not think, ath5k has to do with your amarok poor performance. You gotta be kidding, but I have similar problems with xmms and mplayer. It is is barely noticeable, though annoying. I have never experienced this before jaunty. Another thing that could be related to this, I think, sometimes the systems seems to freeze for a second. Could both be related to power management and/or snd_hda_intel module?
In any case, we should file a separate bug. Would you like to do this? I will do it if you wouldn't
Thanks

gene (eugenios) wrote :

Giovanni,
I do not remember the madwifi setup in hardy or 8.10 . However, I do agree about the deteriorated performance of wifi on jaunty. I did not do pings then, so I do not have the figures. Nevertheless, I remember to be able to connect to some open networks at home to which I now cannot. This both with ath_pci and ath5k. It does not seem to be plausible that setup is messed up now. I think this could be something else in the kernel or/and the wifi modules themselves. Can you try running an old kernel which you had with 8.10 or 8.04? Some of your updated modules might not be able to load with that though...

This particular bug was filed due to ath5k crashed the my system.

Can we file another bug here?

Thanks

Victor (psycovic) wrote :

Gene,

Yea, after looking around for a while, I can only guess it's Jaunty's Pulseaudio being screwy. I'm going to try a fresh install in a few days, but I don't expect much out of it. As for it being hda_intel module, I have no clue, but if you know a way to check, I'll gladly post results. And I think a separate bug would be a good idea, but I've never filed anything before, so if you want to do it, that'd be great.

I hope a fix for this is coming soon. I bought an Atheros-based card for my new system specifically because I heard reports that it was working well with Ubuntu... but I get a hard lock whenever ath5k is enabled, either as soon as I try connecting to my AP, or randomly within a couple hours after. I have never had my machine up for more than a couple hours without it hard locking, except when the atheros driver is disabled. Since Wifi provides my only access to the internet, it has rendered my new system useless (unless I boot XP...).
I also have the "unsupported jumbo" message from ath5k in my kernel log.

gene (eugenios) wrote :

series8217,
As a partial "fix" you could try madwifi driver. This an alternative for at5k, which is mostly Open Source but uses some proprietary code (HAL).

Just go to the System->Administration->Hardware Drivers Menu and enable it.

gene (eugenios) wrote :

series8217,
As a partial "fix" you could try madwifi driver. This an alternative for ath5k and is mostly Open Source but uses some proprietary code (HAL).

Just go to the System->Administration->Hardware Drivers Menu and enable it.

Manoj Iyer (manjo) wrote :

Can you please test the kernel in http://people.ubuntu.com/~manjo/lp341952-jaunty/ and report back here if it fixes you problem or not ?

Jamie Lokier (jamie-shareable) wrote :

Since installing Jaunty, I'm getting lockups every few days on my laptop and I *don't* use ath5k. X freezes, no mouse movement, no keyboard, no Alt-F1 to switch to console.

So the lockup might have nothing to do with ath5k.

One time when it happened, the mouse kept moving though nothing happened under it and the keyboard didn't work, and I was able to login over the network. I looked at the last kernel messages with "dmesg" and saw something about DRI. So it may be DRI is to blame. I don't have Compiz turned on, though.

I have an Intel 945GM graphics chipset here, and my wi-fi is iwl3945 (which works very well).

I was using a Jaunty kernel before it was released, but with an Intrepid distribution otherwise (except for essential packages needing to match the kernel).

With an Intrepid distribution running on top of a Jaunty kernel, I didn't experience any of these lockups. So it's quite likely that it's either not a kernel bug, or a kernel bug which depends on the newer userspace to trigger it.

Due to the DRI message I saw once, I vaguely suspect the X server and/or DRI code.

Manoj Iyer (manjo) wrote :

Jamie Lokier, please open a separate bug with complete details including logfiles, dmesg, and lspci/hw info.

gene, series8217, can you kindly try the kernel in http://people.ubuntu.com/~manjo/lp341952-jaunty/ and verify if it works ? I can SRU this fix for Jaunty.

Changed in linux (Ubuntu):
status: Triaged → In Progress
gene (eugenios) wrote :

Thanks Manoj,
I will try tha when I get a chance.

Manoj> I will try it right now.

Unfortunately even with that kernel my system is still hard locking as soon as I connect to my AP.
I'm using ath_pci for now which works just fine.

Amit Kucheria (amitk) wrote :

I guess this isn't a Bugzilla bug and this is what Manjo intended.

Changed in linux (Ubuntu):
assignee: nobody → Manoj Iyer (manjo)
Changed in bugzilla:
assignee: Manoj Iyer (manjo) → nobody
Frank Zwart (fzwart) wrote :

Hi,

I've been encountering problems also with the ath5k module, for example:

May 16 20:35:26 VIA kernel: [ 291.994295] ath5k phy0: noise floor calibration timeout (2442MHz)
May 16 20:35:27 VIA NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
May 16 20:35:27 VIA kernel: [ 293.229718] wlan0: No ProbeResp from current AP (my AP here) - assume out of range
May 16 20:35:28 VIA NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
May 16 20:35:28 VIA kernel: [ 293.380920] ath5k phy0: failed to wakeup the MAC Chip
May 16 20:35:28 VIA kernel: [ 293.380944] ath5k phy0: can't reset hardware (-5)

Resulting in a disconnect from the AP, and no way to reconnect (except a reboot).

I've been testing with the kernel Manoj supplied ( http://people.ubuntu.com/~manjo/lp341952-jaunty/ ) and the problems seem to have dissapeared.

I'm having a similar problem.

I'm using an Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01) with the ath5k module. Every now and then, my system freezes, but I don't know if that's the wireless's fault. However, it DOES always happen right when I'm trying to connect, so I think I have reasonable suspicion.

Furthermore, every so often, my ethernet simply refuses to connect. It will detect the networks, but it won't be able to connect to any of them, and I get the same messages that you posted. When this happens, resetting only makes the problem worse: all of the networks become invisible.

The ONLY way that I have found to fix this problem is to restart, hook the computer up to a network physically, log in, wait for the network to connect, and then unplug. Then, for some reason, my network works again.

cologic (cologic) wrote :

I experience this locking up on a desktop if I don't blacklist the ath5k module. It's new in Jaunty as well. Whilst it did first appear sometime around Jaunty moving from the beta to the release candidate, I also tried the Ubuntu kernel PPA release of 2.6.30rc4 ( http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc4/ ), but the same issues occur. I'm running no non-free or restricted kernel modules.

Finally, I encountered noise floor calibration issues in dmesg fairly frequently (I didn't save any of the logs to check) - it was akin to what's reported in https://bugzilla.redhat.com/show_bug.cgi?id=452491 however, in particular having that error message ("noise floor calibration timeout") I believe verbatim. It spammed dmesg so much that the boot messages in dmesg were gone within a few hours. However, I don't remember whether this also occurred in the working-(Ubuntu-Jaunty-beta)-kernel or whether its appearance correlates with the hard locks starting.

relevant dpkg output:
ii linux-image-2.6.28-11-generic 2.6.28-11.42 Linux kernel image for version 2.6.28 on x86
ii linux-image-2.6.30-020630rc4-generic 2.6.30-020630rc4 Linux kernel image for version 2.6.30 on x86
ii linux-image-generic 2.6.28.11.15 Generic Linux kernel image
ii linux-restricted-modules-2.6.28-11-generic 2.6.28-11.15 Non-free Linux kernel modules for version 2.
ii linux-restricted-modules-common 2.6.28-11.15 Non-free Linux 2.6.28 modules helper script
ii linux-restricted-modules-generic 2.6.28.11.15 Restricted Linux modules for generic kernels

Abridged lspci information:
05:00.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
 Subsystem: Netgear Device 5a00
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 64 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 10
 Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: [44] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=2 PME-
 Kernel modules: ath5k

chef (adotei) wrote :

Manjo, I tried your kernel packages. The good news is they worked. I didn't get any timeout messages or freezes at boot time. The bad news is I couldn't get Virtualbox to work on it or compile the module for this kernel (something about kernel version, etc. not being set).

Thanks for your help

chef (adotei) wrote :

Hi again, earlier on, before trying out your kernel packages I upgraded my kernel to the latest ubuntu release "2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux". That still kept on giving me the ath5k floor calibration and timeout error.

However, after installing Manoj's kernel packages and uninstalling them, I went back to this ubuntu kernel release. For some reason, it is now working and booting up as normal without any errors.

For some reason, ath5k does not seem to be causing any freezes or errors for now.

Dan (daniel-sittig) wrote :

I've got the same problem with locked up ath5k driver. Since the 7th of May patch apparently did not went into .13 subrelease - as reported by the chef and also confirmed by myself - is it now scheduled to be in the .14 ? Any testing ?

Best regards

dmarchetti (diegomarchetti) wrote :

I have the same problem. But I found that works or not, depending on the position in which the laptop is located, with respect to the wifi router. It is as if there were cones in the shadows that Atheros does not communicate with the router. Especially being close. It works best to be several meters (3 to 8 meters).
I hope that this contribution is helpful. Sorry, but my English is very bad.
Greetings

Tengo el mismo problema. Pero he detectado que funciona o no, según la posición en que se ubique la laptop, con respecto al router wifi. Es como si hubiera conos de sombras en las que la atheros no se comunica con el router. Sobre todo estando cerca. Funciona mejor estando a varios metros de distancia (entre 3 y 8 metros).
Espero que sirva este aporte. Disculpen pero mi inglés es muy malo.
Saludos

dmarchetti (diegomarchetti) wrote :

To add to previous post: The router is a Linksys WRT160N. When you configure the router so that the transmission speed is 1-2 Mbps (for use with wireless technology, old and not "All", which the router can transmit at all speeds wireless) connection improves and The Atheros responds faster and no packets are lost.
Greetings.

Para agregar al post anterior: El router es un Linksys WRT160N. Cuando configuro el router para que la velocidad de transmisión sea de 1-2 Mbps (para su uso con tecnología inalámbrica antigua, y NO con "Todas", con la que el router puede transmitir a todas las velocidades inalámbricas) la conexión mejora notablemente y la atheros responde más rapidamente y no se pierden paquetes.
Saludos.

Alexandros (alexandros-t) wrote :

Does anyone know when the update that fixes this bug comes out?

Alexandros (alexandros-t) wrote :

Fix available via Update Manager, marking as Fix Released.

Changed in linux (Ubuntu):
status: In Progress → Fix Released
Alexandros (alexandros-t) wrote :

My laptop got locked up again this morning. I checked kern.log and noticed:
Aug 23 08:02:34 ubuntu kernel: [ 285.148879] ath5k phy0: noise floor calibration timeout (2437MHz)
I don't think this bug has been fixed, so reverting to Fix Released.

Changed in linux (Ubuntu):
status: Fix Released → In Progress
Jose Gonzalez (jose.g) wrote :

Hello,

I have an Acer Aspire One and get kernel panics using the default ath5k. I'm currently using an Atheros AR242x Wireless Adapter.

I can connect without problem to the wireless router. However, any 100mb downloads or Bittorrent use would either cause a cease in network activity or a kernel panic.

I have tried using the latest madwifi drivers, the linux backport modules, and ndiswrapper. All of them cause network activity to cease from prolong use or a kernel panic.

I am currently using an archived ath5k module, specifically dated 2009-07-31. I still lose network activity or even get a few disconnects when downloading >100mb or using Bittorrent. On the other hand, with this module, I don't get any kernel panics as of now.

By using the archived module, I don't have to be wary of getting a kernel panic, which is a serious problem. I just think it would help as a very loose remedy currently until its fixed.

gene (eugenios) wrote :

Long time no see!
I think ath5k froze once again. I have been with the latest kernel 2.6.31-17 for quite some time. I know that ath5k was known not like my wireless device for some time. Recently, I thought it changed... Well I did not have obvious problems/hangs using the wireless interface. A problem occurred when the ethernet was used.
What I had was a machine hang happened according to the kernlog around 3am, when I was asleep. Here is what I subsequently found in the log:
Jan 12 03:54:51 jenshen kernel: [218922.914225] wlan0: Creating new IBSS network, BSSID 02:0c:7e:7c:79:7a
Jan 12 03:54:53 jenshen kernel: [218925.000046] wlan0: Trigger new scan to find an IBSS to join
Jan 12 03:54:56 jenshen kernel: [218927.988070] wlan0: Trigger new scan to find an IBSS to join
Jan 12 03:54:59 jenshen kernel: [218930.989267] wlan0: Trigger new scan to find an IBSS to join
Jan 12 03:55:00 jenshen kernel: [218931.914443] wlan0: Creating new IBSS network, BSSID c2:df:cf:48:12:52
Jan 12 03:55:02 jenshen kernel: [218934.002002] wlan0: Trigger new scan to find an IBSS to join
Jan 12 03:55:05 jenshen kernel: [218936.988074] wlan0: Trigger new scan to find an IBSS to join
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Jan 12 07:15:23 jenshen kernel: imklog 4.2.0, log source = /var/run/rsyslog/kmsg started.

The last message appears to be very popular in that log (about 66% of it consists of this line!)

wc -l /var/log/kern.log
15632 /var/log/kern.log
grep 'wlan0: Trigger new scan to find an IBSS to join' /var/log/kern.log | wc -l
10870

gene (eugenios) wrote :

One thing that stands out is the garbled entries in the log. I had it before - very consistently since the upgrade to 9.10! There might be other reasons for these "nice" messages. I think it is just symptoms, not the culprit. I am on my custom kernel now,against which I compiled madwifi, which used to be more friendly to me in the past.
I do realize that this issue might not be directly related this bug. What is wlan0 interface in this case? I am sure it was at the time when ath5k was in use not ath_pci

Jeremy Foshee (jeremyfoshee) wrote :

gene,
    I'd appreciate very much your testing on Karmic and Lucid. I see that the upstream bug report is Fix Released.

Thanks in advance for your testing,

-JFo

Jeremy Foshee (jeremyfoshee) wrote :

I neglected to mention, If you do conduct testing via Karmic ot Lucid, would you mind running apport-collect -p linux 341952

Thanks,

-JFo

Changed in linux (Ubuntu):
status: In Progress → Incomplete
gene (eugenios) wrote :

Hello Jeremy. I do not have a chance right now to test it, I currently use only ethernet. Please, see my last post. Last time I used ath5k with 2.6.31-17 I had a system freeze. Since the upgrade to Karmic various freezes I get do not tend to leave any traces in the logs: they just spit a some garbled text. This might be a rsyslog issue... The reason, I blamed ath5k was the following: 60% of all the entries (about 10 870 out of 16034 lines) was the this:

 wlan0: Trigger new scan to find an IBSS to join

The hardwired connection was in use, though the wireless interface was on.
Let me know if need more info

Hi,

I think you have sent this to the wrong person.

Regards,

Jeremy Foshee wrote:
> I neglected to mention, If you do conduct testing via Karmic ot Lucid,
> would you mind running apport-collect -p linux 341952
>
> Thanks,
>
> -JFo
>
> ** Changed in: linux (Ubuntu)
> Status: In Progress => Incomplete
>
>

gene (eugenios) wrote :

#84 is mysterious to me. Who is a "wrong person"? If I understand it correctly, messages are sent to the people that enjoy this beautiful bug and had subscribed to this page.???

iskywalker (iskywalker) wrote :

I had a lod d-link dwl-g122 which was ok, but i thought with an antenna and a pci-card i could incread my connection from 52% to something higher (hopped for 80% since my router is only 15 meters and there is no direct wall between), anyway since i put the Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01), and ath5k it keeps crashing, freezing. I can't see find out why. In the logs there is nothing suspicous, no warning. I am trying now madwifi but instead of 60% I have 40%!!! even my 54mbit dropped to a 24mbit... Anyone has a hint?
Ubuntu ver: Linux 2.6.31-20-generic-pae #58-Ubuntu SMP Fri Mar 12 06:25:51 UTC 2010 i686 GNU/Linux

astenorh (mparusinski) wrote :

I don't know if what I got is the same bug.

I have an atheros card, and I am using lucid lynx beta. The bug only started affecting after I upgraded. It seems it occurs when I am using system intensive applications such as games, or flash videos. Although I might be wrong. My internet slows down and phy0 starts using about 80 % of the CPU, the uptime gets really high about 4 ~ 5 for a dual core system (AMD Turion X2). I suppose that happens because it involves entering the kernel a lot thus blocking the rest of the system causing a huge load. After just a few minutes on the virtual kernel I get lots of message about ath5k. (Unfortunately I don't have the output right now). The bug always occured when I was not using a VM. Not saying that VMs prevents the bug but simply it is independent from it.

If I kill phy0 using command "sudo killalll phy0" it seems to fix the problem mostly but nm-applet will get stuck trying to get still using some CPU power, so I disable the wireless as well. Killing phy0 always stops the wireless (not suprising).

If this is a different problem please tell me so I will send a report!

Luca Ferretti (elle.uca) wrote :

I'm also experiencing many freezes after plugging a new wifi pci card using ath5k driver in 10.04 (lucid).

Jeremy, I could collect data and attach to this bug, but it seems there is nothing useful in /var/log :(
Any suggestions about how to test it? Another question: should I've to install backport modules?

PS shouldn't mention this in 10.04 release notes/know issues and propose a workaround (if available)?

Luca Ferretti (elle.uca) wrote :

Should we add a remote watch on this?
https://bugzilla.kernel.org/show_bug.cgi?id=14342

Victor (psycovic) wrote :

I can also confirm a regression from previous kernels on Lucid. It seems like the 2.6.31 kernels were okay, but not .32.

Luca Ferretti (elle.uca) wrote :

Update: it seems the kernel issue was fixed upstream in 2.6.36

gene (eugenios) wrote :

I see it again in 10.4 since 2.6.32.27. I had a hard lock with no ReqSys keys working. Will try to jump over to the latest stable kernel.

Changed in linux:
importance: Unknown → Medium
gene (eugenios) wrote :

It has resurfaced again in 2.6.32.2[78] I cannot run these anymore and to switch to unstable ones with other issues!

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
gene (eugenios) wrote :

Ok, once again. The bug is in the wild. It freezes my laptop quite regularly. What is more interesting, on the kernel 2.6.37* freezes happen too, however, there is no "unsupported jumbo .." stuff in the logs. What I see is:

atkbd serio0: Use 'setkeycodes 55 <keycode>' to make it known.
atkbd serio0: Unknown key pressed (translated set 2, code 0x55 on isa0060/serio0).

The connection gets laggy, so I guess it is the same sort of issue that crashes the system.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.