[Solved] linux-3.3.1-1 breaks ath5k

shariebeth · 2012-05-30 15:46:04

Miblo wrote:

shariebeth wrote:
Montague wrote:
...and update their /boot/grub/menu.lst accordingly).
Ehh. Would this be correct? …
Looks good to me, shariebeth. So long as you've got your *falback.img in place, you should be safe to try booting into this updated grub entry.

I guess I have to figure out how to put that in menu.lst too, as that was removed when the kernel went to 3.x. I'm really not understanding the logic behind some of these "updates".

Thank you much for the advice, miblo.

aragats · 2012-05-30 15:51:24

Yesterday, when I restarted my ThinkPad R61 after installing 3.4 kernel a bunch of "ath5k phy0: gain calibration timeout" messages appeared. I had no time to experiment at my workplace and just switched to a wired network. Then I went home and wifi worked fine, today at workplace it works too. I did not restart the computer - just suspended twice. I've checked dmesg - no errors appeared from that first time after restarting.

However, I do not have "old" statistics for the issue - with 3.3.x it happened from time to time primarily with my workplace network.

Miblo · 2012-05-30 15:56:04

shariebeth wrote:

Miblo wrote:
shariebeth wrote:
Ehh. Would this be correct? …
Looks good to me, shariebeth. So long as you've got your *falback.img in place, you should be safe to try booting into this updated grub entry.
I guess I have to figure out how to put that in menu.lst too, as that was removed when the kernel went to 3.x. I'm really not understanding the logic behind some of these "updates".
Thank you much for the advice, miblo.

Yeah, I just spotted that my /boot/grub/menu.lst.pacnew doesn't have a fallback entry. Bad practice, I know, having .pacnew files lying around. My fallback entry reads thus:

# (1) Arch Linux
title  Arch Linux Fallback
root   (hd0,0)
kernel /vmlinuz-linux root=/dev/disk/by-uuid/f6cd38f5-5380-4c01-b916-ecfa9445aa76 ro
initrd /initramfs-linux-fallback.img

Those files – /vmlinuz-linux and /initramfs-linux-fallback.img – are located in /boot/ so as long as your entry corresponds with what you have in /boot/ you should be okay.

shariebeth · 2012-05-30 16:03:26

Hmmm miblo, looking at your entry, you are saying the kernel line does not get changed, only the initrd line does?

Miblo · 2012-05-30 16:15:44

aragats wrote:

[…] I did not restart the computer - just suspended twice. I've checked dmesg - no errors appeared from that first time after restarting.

When you suspend, aragats, is your system powered down? I've never tried suspending, you see, only shutting down and rebooting. I found that to get my wireless working properly again after downgrading from 3.3.1-1 back to 3.2.14-1, I had to power down completely. Could linux-3.4 perhaps have solved our problem after all?

Miblo · 2012-05-30 16:29:21

shariebeth wrote:

Hmmm miblo, looking at your entry, you are saying the kernel line does not get changed, only the initrd line does?

Yeah, I presume this is correct because I didn't do it myself. There's no /boot/vmlinuz-linux-fallback file in my system, at least, yet /boot/initramfs-linux-fallback.img is present. If you'd like some extra assurance, instead of modifying your original entry for Arch Linux [/boot/vmlinuz-linux], you could create a new one underneath it for Arch Linux LTS [/boot/vmlinuz-linux-lts]. That way, you would be sure of having at least one bootable grub entry.

aragats · 2012-05-30 17:35:41

Miblo wrote:

When you suspend, aragats, is your system powered down? I've never tried suspending, you see, only shutting down and rebooting. I found that to get my wireless working properly again after downgrading from 3.3.1-1 back to 3.2.14-1, I had to power down completely. Could linux-3.4 perhaps have solved our problem after all?

Well, when suspended it still consumes power at least to hold the RAM content, I would think it should power down everything else, but not sure. Anyway, I'll experiment with both suspend and power off - wil report later today.

But the fact it's already failed for me at least once means the issue is not solved completely...

Miblo · 2012-05-30 18:40:30

aragats wrote:

Miblo wrote:
When you suspend, aragats, is your system powered down? I've never tried suspending, you see, only shutting down and rebooting. I found that to get my wireless working properly again after downgrading from 3.3.1-1 back to 3.2.14-1, I had to power down completely. Could linux-3.4 perhaps have solved our problem after all?
Well, when suspended it still consumes power at least to hold the RAM content, I would think it should power down everything else, but not sure. Anyway, I'll experiment with both suspend and power off - wil report later today.
But the fact it's already failed for me at least once means the issue is not solved completely...

Ah… cheers, aragats. Good luck with your experiments.

Montague · 2012-05-30 19:27:09

Last edited by Montague (2015-07-28 02:55:29)

shariebeth · 2012-05-30 20:15:15

Excellent Montague, kernels 101 made simple. You also helped me figure out why the lts kernel was always updated, built, and installed but I never saw the option at boot for it so I never realized how to get to it or where it was "hidden". Heh. Unexpected valuable tool learned today, beyond the problematic ath5k issue. Thank you very much.

And thank you Miblo as well, you both have been very helpful.

Miblo · 2012-05-31 10:12:35

My pleasure, shariebeth.

Some good news over here: I installed linux-3.4.0-1 from [testing] last night, powered down for ~2mins and booted into the new kernel. Six hours and 2.4GB of network traffic later, there's no sign of "gain calibration timeout" issues and the wireless is ticking along nicely. Not sure if we ruled out bsdard's idea of its being a 'counter wrap-around issue as it seems to depend on the uptime somehow', but if my wireless is still up come this time tomorrow, this would feel [Solved] to me.

How's it going with you, aragats?

aragats · 2012-05-31 15:00:13

Miblo, I believe I have good news too.

I tried both power down and suspend several times with two different networks with no problem.

Then I took my laptop and started moving away from the access point continuously pinging a host and checking dmesg. At about 70m distance ping failed, then I moved back, dmesg showed "wlan0: associated" and no gain calibration errors at all.

I suspect that the very first time after I installed 3.4 kernel the issue's arisen again because I simply did a restart, but not power off - so the device probably staid in that "bad" state.

Summarizing all the facts I would consider the issue solved.

shariebeth · 2012-05-31 15:09:44

aragats wrote:

Then I took my laptop and started moving away from the access point continuously pinging a host and checking dmesg. At about 70m distance ping failed, then I moved back, dmesg showed "wlan0: associated" and no gain calibration errors at all.

My question here is, at what distance were you able to stay connected before the 3.3.x kernel updates? (Before we started having this problem).
I wouldn't call anything solved if we have less quality/distance than before.
(Also I'd expect at least a 24 hour test before calling it "good" as it generally took that long for me to start getting the calibration errors.)
I guess I'll load up 3.4 from testing, I don't consider myself qualified yet to use testing accurately or report back accurately but seems not too many others are so I'll give it a go.

Edit: Ok so far so good, on 3.4-1 from testing. Will report back later.

Last edited by shariebeth (2012-05-31 15:58:57)

aragats · 2012-05-31 15:48:29

shariebeth wrote:

My question here is, at what distance were you able to stay connected before the 3.3.x kernel updates?

Well, as I've reported in one of previous messages, I do not have statistics for older kernels. Hopefully I'll find time today to check the distance with 3.3.x and 3.0.x kernels.

shariebeth wrote:

Also I'd expect at least a 24 hour test before calling it "good" as it generally took that long for me to start getting the calibration errors.

For me it works already 48 hours. As I told, I'm using two networks each day: at home and at the workplace. The calibration errors very rarely happened at home, but every day at the workplace.

shariebeth · 2012-05-31 15:58:12

aragats wrote:

shariebeth wrote:
My question here is, at what distance were you able to stay connected before the 3.3.x kernel updates?
Well, as I've reported in one of previous messages, I do not have statistics for older kernels. Hopefully I'll find time today to check the distance with 3.3.x and 3.0.x kernels.

I had no idea what you meant by "statistics", it's rather a vague term. I didn't mean exact numbers, just whether or not you were forced to move closer to the router to stay connected or not with 3.4-1 compared to before this trouble started.

Anyway, 48 hours is a good start.

Miblo · 2012-05-31 16:14:58

aragats wrote:

Miblo, I believe I have good news too.
[…]
Summarizing all the facts I would consider the issue solved.

Wonderful! This is great news, aragats. You know, I could probably mark this as [Solved] right now – my own gain calibration timeout issues would have begun already on 3.3 – but had better wait to see how shariebeth (and everyone else) gets on, just to be absolutely sure.

aragats · 2012-05-31 16:32:47

shariebeth wrote:

I had no idea what you meant by "statistics", it's rather a vague term.

http://dictionary.com

statistics
.....
2. the numerical facts or data themselves.

shariebeth wrote:

I didn't mean exact numbers, just whether or not you were forced to move closer to the router to stay connected or not with 3.4-1 compared to before this trouble started.

To compare something you DO need numerical data: closer or farther is eventually measured in meters, feet etc.

I'll report the results later today.

aragats · 2012-06-01 03:03:50

...I have compared wifi ranges for kernels: 3.1.1, 3.3.6 and 3.4.0. It wasn't a scientific measurement, I've just walked three times with my laptop (pinging a host) away from my house. There was no significant difference between kernels, however, with kernel 3.1.1 the ping failed at 100m, whereas 3.3.6 and 3.4.0 showed 90m result - but again, a single measurement cannot validate such а "degradation".

Miblo · 2012-06-01 10:01:13

1¼ days uptime and my Wi-Fi's going strong. Regarding signal quality comparison, I don't see any appreciable difference either way. This feels [Solved] to me.

If we're agreed, I'll put a note in the first post.

aragats · 2012-06-01 12:28:51

I agree, no issues noticed. I've done a few additional sleep-wake cycles with subsequent assicoiation with the same or a different wifi network - works perfectly.

shariebeth · 2012-06-01 17:09:33

25+ hours and still testing. Everything seems in apple pie order, and no apparent loss of quality or distance.
Personally I don't think it should be marked solved in the title until 3.4 is in core. After all, we are told not to mess with testing unless we know what we're doing. In my opinion, that means it would not be solved for everyone. Maybe a [solved-pending core release] or something similar.

Miblo · 2012-06-01 19:01:15

shariebeth wrote:

Personally I don't think it should be marked solved in the title until 3.4 is in core.

Mmm… yeah, I know what you mean. Another one of those updates in the first post should be okay, though, no? Just something to the effect that 3.4 in [testing] is being reported to fix the issue, and give folk the option to enable said repo and install or else wait until it's in [core].

shariebeth · 2012-06-01 20:18:30

Agreed.

Montague · 2012-06-10 02:12:45

Last edited by Montague (2015-07-28 03:00:26)

Miblo · 2012-06-11 03:07:39

Montague wrote:

…I recently installed repo-ck/linux-ck-kx-3.4…

Cheers for this, Montague. I'd never heard of Con Kolivas, but am now trying out his linux-ck-atom-3.4.2-1. Can confirm that wireless is also fine here (after 2½ hours). Previously, on testing/linux-3.4.0-1, wireless had been up for days and days.

Arch Linux

#51 2012-05-30 15:46:04

Re: [Solved] linux-3.3.1-1 breaks ath5k

#52 2012-05-30 15:51:24

Re: [Solved] linux-3.3.1-1 breaks ath5k

#53 2012-05-30 15:56:04

Re: [Solved] linux-3.3.1-1 breaks ath5k

#54 2012-05-30 16:03:26

Re: [Solved] linux-3.3.1-1 breaks ath5k

#55 2012-05-30 16:15:44

Re: [Solved] linux-3.3.1-1 breaks ath5k

#56 2012-05-30 16:29:21

Re: [Solved] linux-3.3.1-1 breaks ath5k

#57 2012-05-30 17:35:41

Re: [Solved] linux-3.3.1-1 breaks ath5k

#58 2012-05-30 18:40:30

Re: [Solved] linux-3.3.1-1 breaks ath5k

#59 2012-05-30 19:27:09

Re: [Solved] linux-3.3.1-1 breaks ath5k

#60 2012-05-30 20:15:15

Re: [Solved] linux-3.3.1-1 breaks ath5k

#61 2012-05-31 10:12:35

Re: [Solved] linux-3.3.1-1 breaks ath5k

#62 2012-05-31 15:00:13

Re: [Solved] linux-3.3.1-1 breaks ath5k

#63 2012-05-31 15:09:44

Re: [Solved] linux-3.3.1-1 breaks ath5k

#64 2012-05-31 15:48:29

Re: [Solved] linux-3.3.1-1 breaks ath5k

#65 2012-05-31 15:58:12

Re: [Solved] linux-3.3.1-1 breaks ath5k

#66 2012-05-31 16:14:58

Re: [Solved] linux-3.3.1-1 breaks ath5k

#67 2012-05-31 16:32:47

Re: [Solved] linux-3.3.1-1 breaks ath5k

#68 2012-06-01 03:03:50

Re: [Solved] linux-3.3.1-1 breaks ath5k

#69 2012-06-01 10:01:13

Re: [Solved] linux-3.3.1-1 breaks ath5k

#70 2012-06-01 12:28:51

Re: [Solved] linux-3.3.1-1 breaks ath5k

#71 2012-06-01 17:09:33

Re: [Solved] linux-3.3.1-1 breaks ath5k

#72 2012-06-01 19:01:15

Re: [Solved] linux-3.3.1-1 breaks ath5k

#73 2012-06-01 20:18:30

Re: [Solved] linux-3.3.1-1 breaks ath5k

#74 2012-06-10 02:12:45

Re: [Solved] linux-3.3.1-1 breaks ath5k

#75 2012-06-11 03:07:39

Re: [Solved] linux-3.3.1-1 breaks ath5k

Board footer