I received this bug report on ath9k:
On Thu, 2011-04-14 at 14:39 +0200, Gunnar Stahl wrote:
> Package: linux-2.6
> Version: 2.6.38-3
> Severity: important
>
> Since linux-image-2.6.38-2-amd64 the wlan connections on this machine is 1)
> slow to connection and 2) slows down to a crawl and 3) dies after some seconds
> / mintes and becomes completely unusable.
>
> Connecting over standard eth0 makes no problems at all. Only the wlan is
> affected.
>
> Booting the same machine again with linux-image-2.6.32-5-amd64 turns the wlan
> back to normal again.
[...]
> 02:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
> Subsystem: AzureWave Device [1a3b:1089]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 17
> Region 0: Memory at feaf0000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: <access denied>
> Kernel driver in use: ath9k
[...]
Further system details at <http://bugs.debian.org/622753>.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Am 14.04.2011 14:53, schrieb Ben Hutchings:
> I received this bug report on ath9k:
>
> On Thu, 2011-04-14 at 14:39 +0200, Gunnar Stahl wrote:
>> Package: linux-2.6
>> Version: 2.6.38-3
>> Severity: important
>>
>> Since linux-image-2.6.38-2-amd64 the wlan connections on this machine is 1)
>> slow to connection and 2) slows down to a crawl and 3) dies after some seconds
>> / mintes and becomes completely unusable.
>>
>> Connecting over standard eth0 makes no problems at all. Only the wlan is
>> affected.
>>
>> Booting the same machine again with linux-image-2.6.32-5-amd64 turns the wlan
>> back to normal again.
> [...]
>> 02:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
>> Subsystem: AzureWave Device [1a3b:1089]
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>> Latency: 0, Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 17
>> Region 0: Memory at feaf0000 (64-bit, non-prefetchable) [size=64K]
>> Capabilities:<access denied>
>> Kernel driver in use: ath9k
> [...]
>
> Further system details at<http://bugs.debian.org/622753>.
>
> Ben.
>
https://bugzilla.kernel.org/show_bug.cgi?id=31452
--
Regards,
Richard Schütz
On Thu, 2011-04-14 at 14:56 +0200, Richard Schütz wrote:
> Am 14.04.2011 14:53, schrieb Ben Hutchings:
> > I received this bug report on ath9k:
> >
> > On Thu, 2011-04-14 at 14:39 +0200, Gunnar Stahl wrote:
> >> Package: linux-2.6
> >> Version: 2.6.38-3
> >> Severity: important
> >>
> >> Since linux-image-2.6.38-2-amd64 the wlan connections on this machine is 1)
> >> slow to connection and 2) slows down to a crawl and 3) dies after some seconds
> >> / mintes and becomes completely unusable.
[...]
> https://bugzilla.kernel.org/show_bug.cgi?id=31452
Thanks, I've set our bug tracker to follow that bug.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Hi Ben,
since sunday I am running kernel 2.6.38-2-amd64 (uname -a) (dselect version 2.6.38-5). The wlan module works now almost
perfect. The "almost" is due to the fact that connection the machine to the android hotspot somehow fails. But all other
hotspots I used until now work as expected.
Huge thank-you from me!
Yt,
Gunnar
Am 17.05.2011 05:45, schrieb Ben Hutchings:
> On Fri, 2011-04-15 at 15:52 +0800, Adrian Chadd wrote:
>> On 15 April 2011 12:00, Ben Hutchings<[email protected]> wrote:
>> [...]
>> > https://bugzilla.kernel.org/show_bug.cgi?id=31452
>>
>>
>> Thanks, I've set our bug tracker to follow that bug.
>>
>> Has it been established that it's the same bug though?
>>
>> I had a brief read of that and I'm not so sure. There's so many things
>> that could impact TX throughput.
>>
>> I don't have this problem on FreeBSD on my AR9285 NICs and I've ported
>> almost all of the (non-power saving) related code from ath9k. They
>> happily sit at the expected TX/RX speeds in 11g and 11n modes.
>>
>> Is someone who is experiencing the problem able to do some kernel
>> version bisecting between the known good and known bad kernel?
> The bug fix from the report on Bugzilla has been included in stable
> release 2.6.38.5 and Debian's version 2.6.38-5.
>
> Does this version fix the problem for you?
>
> Ben.
>
On Fri, 2011-04-15 at 15:52 +0800, Adrian Chadd wrote:
> On 15 April 2011 12:00, Ben Hutchings <[email protected]> wrote:
> [...]
> > https://bugzilla.kernel.org/show_bug.cgi?id=31452
>
>
> Thanks, I've set our bug tracker to follow that bug.
>
> Has it been established that it's the same bug though?
>
> I had a brief read of that and I'm not so sure. There's so many things
> that could impact TX throughput.
>
> I don't have this problem on FreeBSD on my AR9285 NICs and I've ported
> almost all of the (non-power saving) related code from ath9k. They
> happily sit at the expected TX/RX speeds in 11g and 11n modes.
>
> Is someone who is experiencing the problem able to do some kernel
> version bisecting between the known good and known bad kernel?
The bug fix from the report on Bugzilla has been included in stable
release 2.6.38.5 and Debian's version 2.6.38-5.
Does this version fix the problem for you?
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.