AP: ath5k + hostapd occasionally sulks
I pulled compat-wireless from GIT last night (or about 1:30am mountain, really) and rebuilt a 2.6.27.29 kernel.
I'm seeing a lot of:
Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
one every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
00:11.0 Ethernet controller: Atheros Communications Inc. AR5413 802.11abg NIC (rev 01)
Subsystem: Atheros Communications Inc. EnGenius EMP-8602 (400mw) or Compex WLM54AG
Flags: bus master, medium devsel, latency 168, IRQ 15
Memory at a0010000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Kernel driver in use: ath5k
Kernel modules: ath5k
Is this a known issue? Jon posted the same question, but I didn't see an answer to his question...
And like him, I'm also using hostapd (but I pulled a GIT at the same time last night).
I'll probably have to reboot regularly, since this is on an embedded box with limited CF filesystem, and I can't overflow my /var partition...
Thanks,
-Philip
Philip Prindeville
Quoted 9 lines · <[email protected]> writes:
I pulled compat-wireless from GIT last night (or about 1:30am mountain, really) and rebuilt a 2.6.27.29 kernel.
I'm seeing a lot of:
Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packetIs this a known issue? Jon posted the same question, but I didn't see an answer to his question...
Most of the time it works and I don't see anything in the logs, so your problem is worse than mine... I'm now running compat-wireless-2009-09-07, but I doubt if that's any different.
Signature · 1 line
Jón Fairbairn [email protected]
Quoted 9 lines · Philip Prindeville
I pulled compat-wireless from GIT last night (or about 1:30am mountain, really) and rebuilt a 2.6.27.29 kernel.
I'm seeing a lot of:
Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
one every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
Ok, the timing information is useful. This is probably something (beacon sending?) racing with the periodic calibration, which temporarily stops all of the tx traffic and frees the tx buffers, then starts it all up again. In short, apart from the logging this shouldn't cause any problems, but we should probably disable the beacon tasklet during this time.
If this only appeared all of a sudden in recent compat snapshots, it would be useful to know the last one that worked normally.
Quoted 2 lines
I'll probably have to reboot regularly, since this is on an embedded box with limited CF filesystem, and I can't overflow my /var partition...
Ouch. For now, just take it out or demote it to debug.
As for the original problem, I don't know offhand why a large download would trigger a cascade of these errors. The best way to track it down is to try to come up with a case that reproduces it and sprinkle printks throughout the driver, especially when we free and allocate the tx buffers.
Signature · 1 line
Bob Copeland %% www.bobcopeland.com
Quoted 14 lines · Bob Copeland
Quoted 10 lines · Philip Prindeville
I pulled compat-wireless from GIT last night (or about 1:30am mountain, really) and rebuilt a 2.6.27.29 kernel.
I'm seeing a lot of:
Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packetone every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
Quoted 7 lines
Ok, the timing information is useful. This is probably something (beacon sending?) racing with the periodic calibration, which temporarily stops all of the tx traffic and frees the tx buffers, then starts it all up again. In short, apart from the logging this shouldn't cause any problems, but we should probably disable the beacon tasklet during this time.
Alas it is causing problems. I have a Windows 7 client with an Atheros card (I forget which... it's the mini-PCIe card that comes with Zotac ION mini-itx motherboards).
I either can't associate, or associate but don't get a DHCP address or don't pass traffic... I forget which.
I can do more testing tomorrow...
Quoted 3 lines
If this only appeared all of a sudden in recent compat snapshots, it would be useful to know the last one that worked normally.
I could walk it backwards, I suppose... 2009-08-23 was definitely working with an 9K board.
I've not tried it with a 5K board (I'm not at this location very often).
Quoted 13 lines
Quoted 3 lines
I'll probably have to reboot regularly, since this is on an embedded box with limited CF filesystem, and I can't overflow my /var partition...
Ouch. For now, just take it out or demote it to debug.
As for the original problem, I don't know offhand why a large download would trigger a cascade of these errors. The best way to track it down is to try to come up with a case that reproduces it and sprinkle printks throughout the driver, especially when we free and allocate the tx buffers.
Quoted 40 lines · Philip Prindeville
Quoted 15 lines · Bob Copeland
Quoted 11 lines · Philip Prindeville
I pulled compat-wireless from GIT last night (or about 1:30am mountain, really) and rebuilt a 2.6.27.29 kernel.
I'm seeing a lot of:
Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packetone every 10 seconds, in fact. This is with an Engenius EMP-8062+ card:
Quoted 8 lines
Ok, the timing information is useful. This is probably something (beacon sending?) racing with the periodic calibration, which temporarily stops all of the tx traffic and frees the tx buffers, then starts it all up again. In short, apart from the logging this shouldn't cause any problems, but we should probably disable the beacon tasklet during this time.
Alas it is causing problems. I have a Windows 7 client with an Atheros card (I forget which... it's the mini-PCIe card that comes with Zotac ION mini-itx motherboards).
I either can't associate, or associate but don't get a DHCP address or don't pass traffic... I forget which.
I can do more testing tomorrow...
Quoted 4 lines
If this only appeared all of a sudden in recent compat snapshots, it would be useful to know the last one that worked normally.
Quoted 5 lines
I could walk it backwards, I suppose... 2009-08-23 was definitely working with an 9K board.
I've not tried it with a 5K board (I'm not at this location very often).
FYI: The Windows 7 box associates and runs just fine with 9K driver with 2009-09-07. So it seems to be an issue with the 5K driver.
I'll set up a second WAP with a 5K card...
-Philip
Quoted 16 lines
Quoted 16 lines
Quoted 6 lines
I'll probably have to reboot regularly, since this is on an embedded box with limited CF filesystem, and I can't overflow my /var partition...
Ouch. For now, just take it out or demote it to debug.
As for the original problem, I don't know offhand why a large download would trigger a cascade of these errors. The best way to track it down is to try to come up with a case that reproduces it and sprinkle printks throughout the driver, especially when we free and allocate the tx buffers.
Quoted 2 lines · Philip A. Prindeville
FYI: The Windows 7 box associates and runs just fine with 9K driver with 2009-09-07. So it seems to be an issue with the 5K driver.
Okay, probably so. Multicast buffering may be broken again.
Signature · 1 line
Bob Copeland %% www.bobcopeland.com