You are not logged in.
pacman -Q linux-firmware
linux-firmware 20100807-1
With this update, wireless connection drops every ~5 minutes and auto-reconnects. kernel log is filled with:
iwlagn 0000:04:00.0: BA scd_flow 0 does not match txq_id 10
A little googling resulted in this: https://patchwork.kernel.org/patch/112837/
So, anybody have a solution for this? Should I open a bug report?
Last edited by .:B:. (2010-08-21 05:46:38)
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
Which model of card do you have? My machine has an Intel wireless-N 1000 card, and I've had no iwlagn problems with the latest firmware you mentioned (no messages of the kind you seem to be getting in kernel.log). I see that the bug report you linked to mentions the 5300 and 5350 models, so it may be specific to those cards and not to the driver in general.
Offline
lspci | grep -i wifi
04:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
Well, it appears that linux-firmware is not to blame. Maybe 2.6.35 kernel? Here are the packages updated in the last 2 days:
[2010-08-19 09:58] upgraded kernel26-headers (2.6.34.3-1 -> 2.6.35.2-1)
[2010-08-19 10:07] upgraded gstreamer0.10 (0.10.29-1 -> 0.10.30-1)
[2010-08-19 10:07] upgraded gstreamer0.10-base (0.10.29-1 -> 0.10.30-1)
[2010-08-19 10:07] upgraded gstreamer0.10-base-plugins (0.10.29-1 -> 0.10.30-1)
[2010-08-19 10:07] upgraded gstreamer0.10-good (0.10.23-1 -> 0.10.24-1)
[2010-08-19 10:07] upgraded linux-firmware (20100623-2 -> 20100807-1)
[2010-08-19 10:08] upgraded kernel26 (2.6.34.3-1 -> 2.6.35.2-1)
[2010-08-19 10:08] upgraded libdatrie (0.2.3-1 -> 0.2.4-1)
[2010-08-19 10:08] upgraded mplayer-vaapi (20100713-4 -> 31774-1)
[2010-08-19 10:08] upgraded poppler-data (0.4.2-1 -> 0.4.3-1)
[2010-08-19 10:08] upgraded powertop (1.11-2 -> 1.13-1)
[2010-08-19 10:08] upgraded xf86-input-evdev (2.4.0-1 -> 2.4.0-2)
[2010-08-19 10:08] upgraded xfconf (4.6.2-1 -> 4.6.2-2)
[2010-08-19 10:08] upgraded xfdesktop (4.6.2-1 -> 4.6.2-2)
[2010-08-20 09:33] upgraded avahi (0.6.25-3 -> 0.6.27-2)
[2010-08-20 09:33] upgraded filezilla (3.3.3-1 -> 3.3.4.1-1)
[2010-08-20 09:33] upgraded gnome-keyring (2.30.3-1 -> 2.30.3-2)
[2010-08-20 09:33] upgraded libgnome-keyring (2.30.1-1 -> 2.30.1-2)
[2010-08-20 09:33] upgraded mdadm (3.1.2-2 -> 3.1.3-1)
[2010-08-20 09:33] upgraded pycairo (1.8.8-1 -> 1.8.10-1)
[2010-08-20 09:33] upgraded pygtk (2.17.0-1 -> 2.17.0-2)
[2010-08-20 09:33] upgraded udev (160-1 -> 161-1)
[2010-08-20 09:33] upgraded usbutils (0.87-1 -> 0.90-1)
[2010-08-20 09:33] upgraded vlc (1.1.2-2 -> 1.1.3-1)
[2010-08-20 21:17] upgraded linux-firmware (20100807-1 -> 20100623-2)
Does anyone have any idea, at all?
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
My knowledge is pretty limited, but my guess is that it's more likely a kernel/driver issue than a firmware issue. At least according to Intel's site, the iwlwifi-5000 microcode files are over a year old, so Arch's latest linux-firmware package likely contains exactly the same firmware for the 5000 series as the previous Arch linux-firmware package:
http://intellinuxwireless.org/?n=downloads
Far more likely, it seems, is that there is something in the new version of the kernel, and in its version of the iwlagn driver, that is affecting the 5100 card (and perhaps others, though as I said above, my 1000 card seems unaffected since the 2.6.35 update). Beyond that, someone with more technical knowledge will have to weigh in, since I am already wading into speculative territory...
Offline
Some more googling agrees with your thinking. Reverting the firmware didn't help, but reverting the kernel (and headers) did. I hope this gets solved in 2.6.36.
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
http://bugs.archlinux.org/task/20492
maybe you want to add more informations, like the link to the patch
Give what you have. To someone, it may be better than you dare to think.
Offline
I've seen that bug, but I'm not sure they are the same problem. They are both about the iwlagn driver, so it's likely they are related but I couldn't be sure so I opened another bug report: http://bugs.archlinux.org/task/20542
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
I edited your topic title, you make it look like the latest kernel breaks iwlagn across the board, while it has been working fine for my IPW4965 for example - and I haven't seen lots of people report it either. If people open this topic in 6 months, they'll have a hard time finding out which kernel exactly you're talking about as well.
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline
I've submitted this to upstream: https://bugzilla.kernel.org/show_bug.cgi?id=16691
@B: It might be fine with your IPW4965, but I believe a lot changed in the iwlagn driver in 2.6.35 see [1]. The reason there aren't many reports yet, is that only a handful distros have switched to 2.6.35.x.
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
For what it's worth, I've had similar problems with my 5100 on iwlagn dropping connectivity and feel like I have a work around for now.
First, this may be machine specific (I'm on a ThinkPad x100e). The x100e doesn't like clocksource=hpet right now (stalls on poweroff till keypress, for instance).
I was exploring consoleblank timing and trying to understand how the kernel handles screen blanking in general and noted that, at least on the x100e, when I let the unit go into consoleblank mode after the default 10 minutes, it would take ~10-15 seconds to come out of consoleblank mode.
A look at dmesg output showed that iwlagn was throwing hundreds of error messages the instant that consoleblank activated.
This led me to some questions, specifically whether consoleblank has any relation to other powersaving code. I still don't know, but I did manage to workaround this problem.
Only by accident I switched over from my clocksource=hpet to clocksource=jiffies and noticed that wakeup from consoleblank timeout was now instant. Also, iwlagn no longer started its cascade of error messages upon consoleblank.
Second, I use pm-powersave and noticed that as soon as pm-powersave put the intel 5100 into powersave mode, it began having serious connectivity errors.
I'd like to troubleshoot and tweak that further (there may be some timeout settings I could play with) but for now my solution was to simply make a null "wireless" handler in /etc/pm/power.d/ and keep pm-powersave from touching the wireless powersave state. Unfortunately this increases power consumption by at least a watt.
So two workarounds for the time being:
1: clocksource=jiffies kernel boot option
2. prevent wifi card from going into powersave
It's been very stable so far, but I'd like to hear if other folks have success like this or have other ideas on how to address the connectivity related to powersaving.
Note: another option if you'd like to double check powersaving state manually:
# iwconfig wlan0
(to check powersaving state)
# iwconfig wlan0 power off
(to turn off powersaving)
new arch*.org acct: altercation
Offline
I seem to be having the same or similar problem - lspci | grep -i wifi returns this:
02:00.0 Network controller: Intel Corporation WiFi Link 6000 Series (rev 35)
Offline
I think I have same problem too. It is really annoying as it disconnects me from network from time to time.
lspci:
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
dmesg:
iwlagn 0000:03:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:03:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:03:00.0: low ack count detected, restart firmware
iwlagn 0000:03:00.0: On demand firmware reload
iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
It all started yesterday when I upgraded kernel and bought new router, which supports N standard and I think that the latter might be a problem, what do you think?
/edit: 11n_disable=1 parameter seems to fix the problem...
Last edited by Krzesimir (2010-11-01 08:43:07)
Offline