You are not logged in.
jamesbroadhead wrote:6h30 uptime here with a patched 3.3.2.
Could you elaborate a bit more on that? what patches did you applied to the stable 3.3.2 kernel source?
thx!
Unfortunately, these 2 patches are not present in the 3.3.1 :
http://git.kernel.org/?p=linux/kernel/g … 37359577d2
http://git.kernel.org/?p=linux/kernel/g … 7a1ddb9b0b
These ones
Edit: 29h with working wifi now -- I think that the patches worked.
Last edited by jamesbroadhead (2012-04-16 18:34:37)
Offline
29h with working wifi now -- I think that the patches worked.
Cheers for the stat, james. I'm not courageous enough to apply the patches and test, myself, but do you reckon we can consider this [Solved]?
@archun: Intel® Core™ i5-4210M • [GPU] Intel® HD Graphics 4600 • [Kernel] linux-ck-haswell
Handmade.Network • GitLab
The Life and Times of Miblo del Carpio
Offline
Last edited by Montague (2015-07-28 02:47:38)
Offline
I pinned my kernel (3.2.14) in pacman.conf and I will just wait until we have some indication that this is resolved in 3.4. I'm too lazy to worry about trying to build a patched kernel at this point, and I'm OK for now with what I have.
@Miblo: I vote /not/ to mark this thread [Solved] until we have a stock kernel that works, for what little my vote would count.
--
/ron
Offline
Sure, folks, I'll leave the thread title as it is. I've just put a note in the first post to summarise the situation.
@archun: Intel® Core™ i5-4210M • [GPU] Intel® HD Graphics 4600 • [Kernel] linux-ck-haswell
Handmade.Network • GitLab
The Life and Times of Miblo del Carpio
Offline
Got the same Problem here (Atheros WLAN card, ath5k module).
My WLAN-Connection brokes after a few hours and I got the same "gain calibration timeout" message.
I used on my 3.3.1 Arch Kernel this solution: https://bbs.archlinux.org/viewtopic.php … 0#p1085620
And now everythink works correctly (more than 2 days uptime, no problems with my WLAN).
I didn't test the 3.3.2 Kernel, but i had read that it solves only the problem with ath9k modules, not ath5k.
Offline
I have a workaround that seemed to work, maybe. Well, there were two things.
I suspended my laptop (lid)
I unsuspended it
I presumed it was still broken (perhaps the unsuspend fixed it?)
I did the following:
# rmmod ath5k
# rmmod ath
# rmmod mac80211
# rmmod cfg80211
# modprobe ath5k
# /etc/rc.d/net-auto-wireless restart
Then it worked again. I don't know if this will replicate, but I'll certainly try it the next time I get the calibration error.
I used "lsmod | grep ath" to get the list of modules. Kernel 3.3.2-1, stock.
Offline
Using linux 3.3.2. Same issue...
Offline
I patched the kernel and I still get the callibration issue , but less often I think.
edit:
I gathered this info after wlan0 got disconnected.
[15305.840007] ath5k phy0: gain calibration timeout (2437MHz)
[15306.192551] ath5k phy0: calibration of channel 6 failed
[15307.498965] wlan0: moving STA 00:1e:e5:76:ad:07 to state 2
[15307.498970] wlan0: moving STA 00:1e:e5:76:ad:07 to state 1
[15307.498972] wlan0: moving STA 00:1e:e5:76:ad:07 to state 0
[15307.500150] cfg80211: Calling CRDA to update world regulatory domain
[15308.184150] ath5k phy0: gain calibration timeout (2412MHz)
...
[15326.109050] net_ratelimit: 1 callbacks suppressed
$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 128923 bytes 19110807 (18.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 128923 bytes 19110807 (18.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 metric 1
ether 00:15:af:1a:f7:12 txqueuelen 1000 (Ethernet)
RX packets 496933 bytes 726477967 (692.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 301488 bytes 27370925 (26.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether f6:63:e6:61:04:00 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 00:15:af:1a:f7:12 brd ff:ff:ff:ff:ff:ff
after modprobe -r ath5k && modprobe ath5k:
[22136.888595] cfg80211: Calling CRDA to update world regulatory domain
[22136.919111] ath5k 0000:03:00.0: registered as 'phy0'
[22137.461991] ath: EEPROM regdomain: 0x60
[22137.461995] ath: EEPROM indicates we should expect a direct regpair map
[22137.462000] ath: Country alpha2 being used: 00
[22137.462002] ath: Regpair used: 0x60
[22137.463328] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[22137.467422] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
[22169.776387] ath5k phy0: gain calibration timeout (2412MHz)
[22170.140205] ath5k phy0: gain calibration timeout (2412MHz)
[22170.140795] ADDRCONF(NETDEV_UP): wlan0: link is not ready
I believe wlan works fine until I manually reconnect to the internet through the router ppoe web interface, after that there is no way to get the wireless adapter to connect to the router.
Last edited by zwa (2012-04-20 02:38:34)
Offline
I understand this is an upstream bug, but maybe IMHO we are not getting the necessary testing in [testing] in relation to wireless stuff so they can be more safely moved to [core], and I especially mean this in relation to ath5k and ath9k devices (atheros).
Offline
It seems the problem persist with latest 3.3.5-1-ARCH kernel. Maybe it will be fixed in 3.4?
Offline
Problem still persists in 3.3.6-1.
Offline
There have been a lot of 3.3.x updates since this problem occurred. Does anybody know why this fix isn't being applied to one of those? Or even how much longer until 3.4 is ready? I'm still on 3.2.14-1 and will need to be until this is fixed. It makes me a bit nervous to be ignoring so many kernel updates.
Offline
There have been a lot of 3.3.x updates since this problem occurred. Does anybody know why this fix isn't being applied to one of those?
+1
It makes me a bit nervous to be ignoring so many kernel updates.
You might want to look into, at least temporarily, utilizing the linux-lts kernel (v3.0.31).
http://www.archlinux.org/packages/core/i686/linux-lts
http://www.archlinux.org/packages/core/x86_64/linux-lts
Offline
I can confirm that wireless is working as it should with linux-mainline kernel compiled from aur.
Offline
I can confirm that wireless is working as it should with linux-mainline kernel compiled from aur.
I see from here: https://aur.archlinux.org/packages.php? … _Search=Go
kernels linux-mainline 3.4rc7-1 42 The Linux Kernel and modules (mainline) miffe
kernels linux-mainline-ux31e 3.3rc7-1 4 Mainline kernel for Asus Zenbook UX31e. Also works for UX21E. Intel RC6 fix and ath9k fix is now included upstream. This kernel fixes bluetooth and sentelic touchpads.
But I see no mention of ath5k. Is that an oversight in that ath5k wasn't fixed as well or just an oversight in this description?
Last edited by shariebeth (2012-05-21 13:28:07)
Offline
But I see no mention of ath5k. Is that an oversight in that ath5k wasn't fixed as well or just an oversight in this description?
Ath5k fixes will be merged at v3.4.x. That aur package does not include them.
Offline
But I see no mention of ath5k. Is that an oversight in that ath5k wasn't fixed as well or just an oversight in this description?
Ath5k fixes will be merged at v3.4.x. That aur package does not include them.
Great! Thanks for the clarification.
Offline
No, it's not fixed - I've just installed 3.4 from testing:
the same gain calibration timeout occurs and I cannot connect to certain networks...
Offline
No, it's not fixed - I've just installed 3.4 from testing:
the same gain calibration timeout occurs and I cannot connect to certain networks...
Cheers, aragats. Not that I distrust you, but I probably ought to get some more results before putting another update in the first post.
@archun: Intel® Core™ i5-4210M • [GPU] Intel® HD Graphics 4600 • [Kernel] linux-ck-haswell
Handmade.Network • GitLab
The Life and Times of Miblo del Carpio
Offline
Last edited by Montague (2015-07-28 02:48:07)
Offline
Hi Miblo : if I may, I have a suggestion for your first post : if it gets confirmed that linux-3.4 indeed does not fix this ath5k issue, you could add a third option (in addition to patching a old kernel, or waiting for a working kernel) :
— Users can simply use linux-lts-3.0 from the core repo (this has actually already been suggested by zero2cx in post #40 above) ; it’s a very easy workaround to this wireless issue (users uncomfortable with patching and/or downgrading their kernel can simply “ pacman -S linux-lts ” and update their /boot/grub/menu.lst accordingly).
I’ve been using the linux-lts-ck kernel for the past month and a half or so, with very satisfactory performance, wireless has worked flawlessly for me.
Great idea, Montague. I'll do just that if it's confirmed that linux-3.4 doesn't fix it. Cheers!
As a side-note, perhaps we'll be better able to judge it once 3.4 gets moved to [core].
@archun: Intel® Core™ i5-4210M • [GPU] Intel® HD Graphics 4600 • [Kernel] linux-ck-haswell
Handmade.Network • GitLab
The Life and Times of Miblo del Carpio
Offline
...and update their /boot/grub/menu.lst accordingly).
Ehh. Would this be correct?
Current:
# (0) Arch Linux
title Arch Linux [/boot/vmlinuz-linux]
root (hd0,0)
kernel /vmlinuz-linux root=/dev/sda3 ro
initrd /initramfs-linux.img
Do I change it to this?
# (0) Arch Linux
title Arch Linux [/boot/vmlinuz-linux-lts]
root (hd0,0)
kernel /vmlinuz-linux-lts root=/dev/sda3 ro
initrd /initramfs-linux-lts.img
Also I hope this wouldn't get classified as [SOLVED] this way.
Of course let us all hope the kernel devs didn't forget about us again and this is a moot point.
Last edited by shariebeth (2012-05-30 15:07:10)
Offline
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.
Also I hope this wouldn't get classified as [SOLVED] this way.
Of course let us all hope the kernel devs didn't forget about us again and this is a moot point.
No, if linux-3.4 doesn't solve the problem, I won't mark it as [Solved].
Last edited by Miblo (2012-05-30 15:27:40)
@archun: Intel® Core™ i5-4210M • [GPU] Intel® HD Graphics 4600 • [Kernel] linux-ck-haswell
Handmade.Network • GitLab
The Life and Times of Miblo del Carpio
Offline