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

Bug #341952 reported by gene
118
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Bugzilla
Invalid
Undecided
Unassigned
Linux
Fix Released
Medium
Fedora
Won't Fix
High
linux (Baltix)
New
Undecided
Unassigned
linux (Ubuntu)
Won't Fix
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

Revision history for this message
In , sangu (sangu-redhat-bugs) wrote :
Download full text (3.2 KiB)

Description of problem:
$ dmesg | grep vmap
vmap allocation for size 4198400 failed: use vmalloc=<size> to increase size.
vmap allocation for size 4198400 failed: use vmalloc=<size> to increase size.
vmap allocation for size 2101248 failed: use vmalloc=<size> to increase size.
vmap allocation for size 1052672 failed: use vmalloc=<size> to increase size.
vmap allocation for size 528384 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 520192 failed: use vmalloc=<size> to increase size.
vmap allocation for size 303104 failed: use vmalloc=<size> to increase size.
vmap allocation for size 303104 failed: use vmalloc=<size> to increase size.
vmap allocation for size 303104 failed: use vmalloc=<size> to increase size.
vmap allocation for size 303104 failed: use vmalloc=<size> to increase size.
vmap allocation for size 303104 failed: use vmalloc=<size> to increase size.
vmap allocation for size 303104 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size.
vmap allocation for size 7880704 failed: use vmalloc=<size> to increase size

Version-Release number of selected component (if applicable):
2.6.29-0.207.rc7.fc11

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:
Xorg doesn't start
Swap partition doesn't...

Read more...

Revision history for this message
In , sangu (sangu-redhat-bugs) wrote :

Created attachment 334383
dmesg

95 comments hidden view all 108 comments
Revision history for this message
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.

Revision history for this message
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

Revision history for this message
gene (eugenios) wrote : Re: system freeze/crash in jaunty (maybe related to "vmap allocation failed" error message)

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

Revision history for this message
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
Revision history for this message
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

Revision history for this message
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
Revision history for this message
Leann Ogasawara (leannogasawara) wrote : Re: system freeze/crash in jaunty - "ath5k phy0: unsupported jumbo/ath5k phy0: noise floor calibration timeout"

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
Revision history for this message
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!

Revision history for this message
gene (eugenios) wrote :
Revision history for this message
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
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

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.

Revision history for this message
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!

85 comments hidden view all 108 comments
Revision history for this message
In , sangu (sangu-redhat-bugs) wrote :

This bug still happens in kernel-PAE-2.6.29-0.252.rc8.fc11.i686.

No problem in 2.6.29-0.157.rc6.git2.fc11.i686.PAE and recent all x86_64 kernel.

< hw profile : http://www.smolts.org/show?uuid=pub_63e477cc-5ada-41f1-b36d-074ad08f0636 >

84 comments hidden view all 108 comments
Revision history for this message
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...

85 comments hidden view all 108 comments
Revision history for this message
In , sangu (sangu-redhat-bugs) wrote :

9800 GT and 8300 mGPU in my linux box.

Disabling mGPU (in mainboard) -> This problem doesn't appear.

Revision history for this message
In , sangu (sangu-redhat-bugs) wrote :

(In reply to comment #3)
> 9800 GT and 8300 mGPU in my linux box.

> Disabling mGPU (in mainboard) -> This problem doesn't appear.
swap partition is mounted. then gdm doesn't start.
So, after disabling nouveau kernel module, starting X works well.

nouveau kernel module conflicts with nvidia (proprietary) driver in i686(x86).

85 comments hidden view all 108 comments
Revision history for this message
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.

Revision history for this message
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

Revision history for this message
gene (eugenios) wrote :

Let me know if I should file another bug here
Thanks

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
gene (eugenios) wrote :

Hi Leann,
So what do we do next?
Thanks

Revision history for this message
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...

Revision history for this message
gene (eugenios) wrote :

I am not making it up, or am I?

Changed in linux:
status: Incomplete → Confirmed
Revision history for this message
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 !

Revision history for this message
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 ?

Revision history for this message
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 :-)

Revision history for this message
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
Revision history for this message
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...

Revision history for this message
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.

Revision history for this message
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!

Revision history for this message
Romain1101 (romainmadala) wrote : Re: [Bug 341952] Re: ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"
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...

Revision history for this message
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...

69 comments hidden view all 108 comments
Revision history for this message
In , Ben (ben-redhat-bugs) wrote :

With two G8x series cards nouveau will be using a lot (at least 96MiB between both cards) of vmalloc space. How do things go if you take the advice the kernel gives and add "vmalloc=256M" to your kernel commandline?

I'll also look into ways we can reduce the amount of vmalloc space we consume.

68 comments hidden view all 108 comments
Revision history for this message
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.

Revision history for this message
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

68 comments hidden view all 108 comments
Revision history for this message
In , sangu (sangu-redhat-bugs) wrote :

(In reply to comment #5)
>How do things go if you take the advice the
> kernel gives and add "vmalloc=256M" to your kernel commandline?

After adding vmalloc=256M in kernel commandline, 2 gpu work well in kernel-PAE-2.6.29-0.267.rc8.git4.fc11.i686.

$ dmesg | grep vmalloc
Kernel command line: ro root=UUID=7fb39964-2a89-4978-87a5-deca9f9b732b vmalloc=256M
    vmalloc : 0xef7fe000 - 0xff7fe000 ( 256 MB)
swap_cgroup: uses 1008 bytes of vmalloc for pointer array space and 1032192 bytes to hold mem_cgroup pointers on swap

67 comments hidden view all 108 comments
Revision history for this message
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

Revision history for this message
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)

Revision history for this message
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)

Revision history for this message
gene (eugenios) wrote :

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

Revision history for this message
unggnu (unggnu) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Changed in linux:
status: Confirmed → Fix Released
Manoj Iyer (manjo)
Changed in bugzilla:
assignee: nobody → manjo
Manoj Iyer (manjo)
Changed in linux (Ubuntu):
status: Triaged → In Progress
Amit Kucheria (amitk)
Changed in linux (Ubuntu):
assignee: nobody → Manoj Iyer (manjo)
Changed in bugzilla:
assignee: Manoj Iyer (manjo) → nobody
28 comments hidden view all 108 comments
Revision history for this message
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

33 comments hidden view all 108 comments
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

32 comments hidden view all 108 comments
Revision history for this message
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

Revision history for this message
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.

32 comments hidden view all 108 comments
Revision history for this message
In , Mike (mike-redhat-bugs) wrote :

I encountered the same problem with my Dell XPS m1330 laptop. It has the nVidia Geforce 8400 GS 128MB video card.

I was able to load X just fine when using the default 'nv' driver, but attempting to use the latest NVIDIA-Linux-x86-185.18.14-pkg1.run driver, or the kmod-nvidia-PAE packaged version, X wouldn't load and I'd end up with a black screen.

This is with a clean install of F11 32bit (using the official DVD install released 20090609).

Kernel: 2.6.29.4-167.fc11.i686.PAE

Adding "vmalloc=128MB" to /etc/grub.conf followed by a reboot got things working. X loaded and glxinfo indicates that direct rendering is enabled.

Revision history for this message
In , Mike (mike-redhat-bugs) wrote :

I suppose I should state that my laptop has a single GPU

32 comments hidden view all 108 comments
Revision history for this message
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

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
Alexandros (alexandros-t) wrote :

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

Revision history for this message
Alexandros (alexandros-t) wrote :

Fix available via Update Manager, marking as Fix Released.

Changed in linux (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
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
28 comments hidden view all 108 comments
Revision history for this message
In , Ben (ben-redhat-bugs) wrote :

Any update from either of you guy as to whether this works by default in F11? I believe for your cases it should've been fixed before release, I reduced our vmalloc space usage as much as possible. Any further issues are unavoidable, NVIDIA cards simply have very large register apertures and chew a lot of address space.

27 comments hidden view all 108 comments
Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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

Revision history for this message
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

Revision history for this message
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
Revision history for this message
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

Revision history for this message
flying_kangaroo (flying-kangaroo) wrote : Re: [Bug 341952] Re: ath5k locks up system in jaunty - "ath5k phy0: noise floor calibration timeout"

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

Revision history for this message
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.???

Revision history for this message
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

Revision history for this message
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!

19 comments hidden view all 108 comments
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

18 comments hidden view all 108 comments
Revision history for this message
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)?

Revision history for this message
Luca Ferretti (elle.uca) wrote :

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

Revision history for this message
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.

17 comments hidden view all 108 comments
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

16 comments hidden view all 108 comments
Revision history for this message
Luca Ferretti (elle.uca) wrote :

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

Revision history for this message
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
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

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
Changed in fedora:
importance: Unknown → High
status: In Progress → Won't Fix
Displaying first 40 and last 40 comments. View all 108 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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