[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Michael Gruber]

Hi,

I have a problem with my Atheros AR928X: It randomly disconnects and
once it does then it will not reconnect for quite some time, while
printing lots of "DMA failed to stop in 10 ms" errors (see log). Is
there some way to fix this? I tried installing latest
compat-wireless-2009-08-12 but with that one I got an awful connection
performance and the log was spammed with "ath9k:
AR_INTR_SYNC_LOCAL_TIMEOUT" and "ath9k: receive FIFO overrun
interrupt".

dmesg output:
http://pastebin.ca/1527337

lspci information:
http://pastebin.ca/1527342

I really need a stable and fast wlan connection. Is this problem
solvable or should I consider buying a different wireless card? Intel
5300 comes to mind; does that one have better support?

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Pavel Roskin]

On Thu, 2009-08-13 at 03:16 +0200, Michael Gruber wrote:
> Hi,
> 
> I have a problem with my Atheros AR928X: It randomly disconnects and
> once it does then it will not reconnect for quite some time, while
> printing lots of "DMA failed to stop in 10 ms" errors (see log). Is
> there some way to fix this? I tried installing latest
> compat-wireless-2009-08-12 but with that one I got an awful connection
> performance and the log was spammed with "ath9k:
> AR_INTR_SYNC_LOCAL_TIMEOUT" and "ath9k: receive FIFO overrun
> interrupt".

I'm getting the same AR_INTR_SYNC_LOCAL_TIMEOUT message with the current
wireless-testing.  As soon as I start the connection, those messages
start appearing.

Since it's trivial to reproduce, I could bisect it tomorrow.  I think
it's something that appeared recently, perhaps in the last two weeks.

I'm also using AR9280.

-- 
Regards,
Pavel Roskin

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Sujith]

Pavel Roskin wrote:
> On Thu, 2009-08-13 at 03:16 +0200, Michael Gruber wrote:
> > Hi,
> >
> > I have a problem with my Atheros AR928X: It randomly disconnects and
> > once it does then it will not reconnect for quite some time, while
> > printing lots of "DMA failed to stop in 10 ms" errors (see log). Is
> > there some way to fix this? I tried installing latest
> > compat-wireless-2009-08-12 but with that one I got an awful connection
> > performance and the log was spammed with "ath9k:
> > AR_INTR_SYNC_LOCAL_TIMEOUT" and "ath9k: receive FIFO overrun
> > interrupt".
> 
> I'm getting the same AR_INTR_SYNC_LOCAL_TIMEOUT message with the current
> wireless-testing.  As soon as I start the connection, those messages
> start appearing.
> 
> Since it's trivial to reproduce, I could bisect it tomorrow.  I think
> it's something that appeared recently, perhaps in the last two weeks.
> 
> I'm also using AR9280.

The commit which exposed this message was:
ath9k: Change DEBUG level for certain interrupt

This error message was suppressed all these days.
Not sure as to why this is being generated in such large numbers.
Still debugging.

Sujith

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Pavel Roskin]

On Thu, 2009-08-13 at 09:24 +0530, Sujith wrote:

> The commit which exposed this message was:
> ath9k: Change DEBUG level for certain interrupt

Yes, I found that already.

> This error message was suppressed all these days.
> Not sure as to why this is being generated in such large numbers.
> Still debugging.

sync_cause is always 0x2000 when that message is printed, so there are
no other causes.

As a side note, please consider removing AR_INTR_SYNC_CAUSE_CLR and use
AR_INTR_SYNC_CAUSE instead.  It's confusing when the same register is
accessed under different names.

-- 
Regards,
Pavel Roskin

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Sujith]

Pavel Roskin wrote:
> sync_cause is always 0x2000 when that message is printed, so there are
> no other causes.

SYNC_LOCAL_TIMEOUT is generated when the PCIe core hangs, unable to complete
a DMA transfer. I am able to see this with 9280, 9281 and 9287.
So this seems to be a fundamental issue.

Sujith

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Pavel Roskin]

On Thu, 2009-08-13 at 10:51 +0530, Sujith wrote:
> Pavel Roskin wrote:
> > sync_cause is always 0x2000 when that message is printed, so there are
> > no other causes.
> 
> SYNC_LOCAL_TIMEOUT is generated when the PCIe core hangs, unable to complete
> a DMA transfer. I am able to see this with 9280, 9281 and 9287.
> So this seems to be a fundamental issue.

Such issues are notoriously hard :-(

If any ath9k version in the past didn't have that problem, I suggest
bisection.

Note that Michael noticed the performance degradation.  That's another
target for bisection, whether it's related or not.

-- 
Regards,
Pavel Roskin

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

Seems to be happening with AR9285 in my HP laptop as well.

I was about to write a msg to this list with the same performance issues when 
I saw this thread.

Kunal

On Thursday 13 Aug 2009 10:51:54 am Sujith wrote:
> Pavel Roskin wrote:
> > sync_cause is always 0x2000 when that message is printed, so there are
> > no other causes.
>
> SYNC_LOCAL_TIMEOUT is generated when the PCIe core hangs, unable to
> complete a DMA transfer. I am able to see this with 9280, 9281 and 9287.
> So this seems to be a fundamental issue.
>
> Sujith
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

On Thursday 13 Aug 2009 11:10:42 am Pavel Roskin wrote:
> On Thu, 2009-08-13 at 10:51 +0530, Sujith wrote:
> > Pavel Roskin wrote:
> > > sync_cause is always 0x2000 when that message is printed, so there are
> > > no other causes.
> >
> > SYNC_LOCAL_TIMEOUT is generated when the PCIe core hangs, unable to
> > complete a DMA transfer. I am able to see this with 9280, 9281 and 9287.
> > So this seems to be a fundamental issue.
>
> Such issues are notoriously hard :-(
>
> If any ath9k version in the past didn't have that problem, I suggest
> bisection.
>
> Note that Michael noticed the performance degradation.  That's another
> target for bisection, whether it's related or not.

Any way we can help debug this issue?
It gets really annoying when the driver goes berserk in the middle of a big 
file transfer - even on LAN. :(

rmmod'ing and modprobe'ing the driver again seems to get it working; but, as 
the network load increases, the driver again starts faltering.

The problem starts especially under load on the network - say, while 
transferring ISOs from desktop to laptop, or updating ubuntu packages.

When the driver exhibits the problem, the ping times on the LAN also go 
berserk - ranging from ~1ms to ~700ms while sitting next to the wireless 
router (Linksys WRT54GL running OpenWRT Kamikaze 8.09) with packets lost.
The router is working fine because my other laptop (IBM Thinkpad R51 running 
ipw2200) never has any problems with the WLAN.

I'm using linux kernel 2.6.31-4-generic (x86_64) on kubuntu jaunty on this new 
HP laptop (dv6 series). The kernel is built by myself from ubuntu-karmic.git 
(git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git)

Config options related to ath9k in the kernel:

kunal at plutonium:/boot$ grep 'CONFIG_ATH9K' config-2.6.31-4-generic
CONFIG_ATH9K=m
CONFIG_ATH9K_DEBUG=y

The device info from 'lspci -vnn':
08:00.0 Network controller [0280]: Atheros Communications Inc. AR9285 Wireless 
Network Adapter (PCI-Express) [168c:002b] (rev 01)                               
        Subsystem: Hewlett-Packard Company Device [103c:3040]
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at d1200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- 
Queue=0/0Enable-
        Capabilities: [60] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting <?>
        Capabilities: [140] Virtual Channel <?>
        Capabilities: [160] Device Serial Number 12-14-24-ff-ff-17-15-00
        Capabilities: [170] Power Budgeting <?>
        Kernel driver in use: ath9k
        Kernel modules: ath9k

Please let me know if I can help in debugging.
Any patches that you might want me to try, I would be glad to give it a go.

Thanks,
-- 
Kunal

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Pavel Roskin]

On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
> > Note that Michael noticed the performance degradation.  That's another
> > target for bisection, whether it's related or not.
> 
> Any way we can help debug this issue?
> It gets really annoying when the driver goes berserk in the middle of a big 
> file transfer - even on LAN. :(

If an older driver didn't have that problem, you can use the git bisect
command to find which change introduced the slowdown, provided that you
can detect it reliably.

-- 
Regards,
Pavel Roskin

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Luis R. Rodriguez]

On Tue, Aug 18, 2009 at 2:04 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
>> > Note that Michael noticed the performance degradation. ?That's another
>> > target for bisection, whether it's related or not.
>>
>> Any way we can help debug this issue?
>> It gets really annoying when the driver goes berserk in the middle of a big
>> file transfer - even on LAN. :(
>
> If an older driver didn't have that problem, you can use the git bisect
> command to find which change introduced the slowdown, provided that you
> can detect it reliably.

But note: wireless-testing sucks for bisecting, so you may want to
reproduce on the wireless-next-2.6 tree.

http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=summary

  Luis

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Pavel Roskin]

On Tue, 2009-08-18 at 14:07 -0700, Luis R. Rodriguez wrote:
> On Tue, Aug 18, 2009 at 2:04 PM, Pavel Roskin<proski@gnu.org> wrote:
> > On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
> >> > Note that Michael noticed the performance degradation.  That's another
> >> > target for bisection, whether it's related or not.
> >>
> >> Any way we can help debug this issue?
> >> It gets really annoying when the driver goes berserk in the middle of a big
> >> file transfer - even on LAN. :(
> >
> > If an older driver didn't have that problem, you can use the git bisect
> > command to find which change introduced the slowdown, provided that you
> > can detect it reliably.
> 
> But note: wireless-testing sucks for bisecting, so you may want to
> reproduce on the wireless-next-2.6 tree.
> 
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=summary

It's described as "Linville's 2.6.26 wireless networking development
tree", but the Makefile indicates 2.6.31-rc5.  Perhaps the description
needs updating?

Anyway, why is it better for bisecting?

-- 
Regards,
Pavel Roskin

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Luis R. Rodriguez]

On Tue, Aug 18, 2009 at 2:15 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Tue, 2009-08-18 at 14:07 -0700, Luis R. Rodriguez wrote:
>> On Tue, Aug 18, 2009 at 2:04 PM, Pavel Roskin<proski@gnu.org> wrote:
>> > On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
>> >> > Note that Michael noticed the performance degradation. ?That's another
>> >> > target for bisection, whether it's related or not.
>> >>
>> >> Any way we can help debug this issue?
>> >> It gets really annoying when the driver goes berserk in the middle of a big
>> >> file transfer - even on LAN. :(
>> >
>> > If an older driver didn't have that problem, you can use the git bisect
>> > command to find which change introduced the slowdown, provided that you
>> > can detect it reliably.
>>
>> But note: wireless-testing sucks for bisecting, so you may want to
>> reproduce on the wireless-next-2.6 tree.
>>
>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=summary
>
> It's described as "Linville's 2.6.26 wireless networking development
> tree", but the Makefile indicates 2.6.31-rc5. ?Perhaps the description
> needs updating?

Adding John, John it seems your linux-next-2.6 tree discription is
stuck on 2.6.26.

> Anyway, why is it better for bisecting?

Because to help developers not have to do:

git branch -m poo
git checkout -b master origin/master
# Then apply patches manually

Instead of the better rebasing:

git branch -m save-my-stuff
git checkout -b master origin/master
git checkout save-my-stuff
git rebase master

john reverts his patches on wireless-testing before rebasing to Linus'
tree. There may be some other added benefit other than helping us
rebase cleanly, not sure. But I do remember before that I never was
able to rebase my patches, and now rebasing works quite nicely.

  Luis

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Pavel Roskin]

On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:

> > Anyway, why is it better for bisecting?
> 
> Because to help developers not have to do:
> 
> git branch -m poo
> git checkout -b master origin/master
> # Then apply patches manually
> 
> Instead of the better rebasing:
> 
> git branch -m save-my-stuff
> git checkout -b master origin/master
> git checkout save-my-stuff
> git rebase master

I use STGit, so perhaps I miss all that fun.  I have never had any
trouble tracking wireless-testing while keeping my patches.

> john reverts his patches on wireless-testing before rebasing to Linus'
> tree. There may be some other added benefit other than helping us
> rebase cleanly, not sure. But I do remember before that I never was
> able to rebase my patches, and now rebasing works quite nicely.

You mean it's better to track wireless-next-2.6 for those of us trying
to stay on top of the wireless development?  I must have missed the
memo.  Indeed, wireless-next-2.6 has a couple of commits that
wireless-testing doesn't have yet.

I agree that having to bisect through reverts is not fun, and it takes
one or two extra iterations.

-- 
Regards,
Pavel Roskin

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Luis R. Rodriguez]

On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote:
> On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
> 
> > > Anyway, why is it better for bisecting?
> >
> > Because to help developers not have to do:
> >
> > git branch -m poo
> > git checkout -b master origin/master
> > # Then apply patches manually
> >
> > Instead of the better rebasing:
> >
> > git branch -m save-my-stuff
> > git checkout -b master origin/master
> > git checkout save-my-stuff
> > git rebase master
> 
> I use STGit, so perhaps I miss all that fun.  I have never had any
> trouble tracking wireless-testing while keeping my patches.

Oh this was a long time ago, pre ath5k I think.

> > john reverts his patches on wireless-testing before rebasing to Linus'
> > tree. There may be some other added benefit other than helping us
> > rebase cleanly, not sure. But I do remember before that I never was
> > able to rebase my patches, and now rebasing works quite nicely.
> 
> You mean it's better to track wireless-next-2.6 for those of us trying
> to stay on top of the wireless development?

No, not at all, I meant wireless-next-2.6 is best for bisecting.

wireless-testing is indeed the place to look at for development.

> I must have missed the
> memo.

I don't think we ever really publized this much, because technically
the reverting won't happen unless John rebases and typically between
rebases to a next RC kernel you *could* technically bisect an issue.
But not all the times.

> Indeed, wireless-next-2.6 has a couple of commits that
> wireless-testing doesn't have yet.
> 
> I agree that having to bisect through reverts is not fun, and it takes
> one or two extra iterations.

Right, which is why I wanted to mention it, will extend the info on
the wiki on the development section once John ACKs/NACKs this.

  Luis

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Sujith]

Kunal Gangakhedkar wrote:
> Any way we can help debug this issue?
> It gets really annoying when the driver goes berserk in the middle of a big
> file transfer - even on LAN. :(
> 
> rmmod'ing and modprobe'ing the driver again seems to get it working; but, as
> the network load increases, the driver again starts faltering.
> 
> The problem starts especially under load on the network - say, while
> transferring ISOs from desktop to laptop, or updating ubuntu packages.
> 
> When the driver exhibits the problem, the ping times on the LAN also go
> berserk - ranging from ~1ms to ~700ms while sitting next to the wireless
> router (Linksys WRT54GL running OpenWRT Kamikaze 8.09) with packets lost.
> The router is working fine because my other laptop (IBM Thinkpad R51 running
> ipw2200) never has any problems with the WLAN.
> 
> I'm using linux kernel 2.6.31-4-generic (x86_64) on kubuntu jaunty on this new
> HP laptop (dv6 series). The kernel is built by myself from ubuntu-karmic.git
> (git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git)
> 
> Config options related to ath9k in the kernel:
> 
> kunal at plutonium:/boot$ grep 'CONFIG_ATH9K' config-2.6.31-4-generic
> CONFIG_ATH9K=m
> CONFIG_ATH9K_DEBUG=y

Can you load the driver with the modparam 'debug=0x200' and post the kernel
log when this issue happens ? Thanks.

Sujith

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[John W. Linville]

On Tue, Aug 18, 2009 at 02:57:48PM -0700, Luis R. Rodriguez wrote:
> On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote:
> > On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
> > 
> > > > Anyway, why is it better for bisecting?
> > >
> > > Because to help developers not have to do:
> > >
> > > git branch -m poo
> > > git checkout -b master origin/master
> > > # Then apply patches manually
> > >
> > > Instead of the better rebasing:
> > >
> > > git branch -m save-my-stuff
> > > git checkout -b master origin/master
> > > git checkout save-my-stuff
> > > git rebase master
> > 
> > I use STGit, so perhaps I miss all that fun.  I have never had any
> > trouble tracking wireless-testing while keeping my patches.
> 
> Oh this was a long time ago, pre ath5k I think.
> 
> > > john reverts his patches on wireless-testing before rebasing to Linus'
> > > tree. There may be some other added benefit other than helping us
> > > rebase cleanly, not sure. But I do remember before that I never was
> > > able to rebase my patches, and now rebasing works quite nicely.
> > 
> > You mean it's better to track wireless-next-2.6 for those of us trying
> > to stay on top of the wireless development?
> 
> No, not at all, I meant wireless-next-2.6 is best for bisecting.
> 
> wireless-testing is indeed the place to look at for development.
> 
> > I must have missed the
> > memo.
> 
> I don't think we ever really publized this much, because technically
> the reverting won't happen unless John rebases and typically between
> rebases to a next RC kernel you *could* technically bisect an issue.
> But not all the times.
> 
> > Indeed, wireless-next-2.6 has a couple of commits that
> > wireless-testing doesn't have yet.
> > 
> > I agree that having to bisect through reverts is not fun, and it takes
> > one or two extra iterations.
> 
> Right, which is why I wanted to mention it, will extend the info on
> the wiki on the development section once John ACKs/NACKs this.

It should not be necessary to bisect through reverts.  I maintain
different tags for such purposes.

Always use the lastest merge-* tag as the base for bisection.
This should be equivalent to whichever -rc release from Linus is the
current base for wireless-testing.  If you need to go any earlier
than that, you should be using linux-2.6.

So for example with current tree:

	git bisect start
	git bisect bad master-2009-08-19
	git bisect good merge-2009-08-14

This should include all of the current wireless patches in
wireless-testing but not in the base linux-2.6 kernel.

I haven't tracked-down this thread in the archives...am I addressing
the issue correctly?

Hth!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

[ath9k-devel] bisecting with wireless-testing

[Luis R. Rodriguez]

Renaming subject and adding linux-wireless.

On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:
> On Tue, Aug 18, 2009 at 02:57:48PM -0700, Luis R. Rodriguez wrote:
> > On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote:
> > > On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
> > >
> > > > > Anyway, why is it better for bisecting?

Just for reference for linux-wireles readers here I had indicated
wireless-next-2.6 was better for bisecting than wireless-testing.

> > > >
> > > > Because to help developers not have to do:
> > > >
> > > > git branch -m poo
> > > > git checkout -b master origin/master
> > > > # Then apply patches manually
> > > >
> > > > Instead of the better rebasing:
> > > >
> > > > git branch -m save-my-stuff
> > > > git checkout -b master origin/master
> > > > git checkout save-my-stuff
> > > > git rebase master
> > >
> > > I use STGit, so perhaps I miss all that fun.  I have never had any
> > > trouble tracking wireless-testing while keeping my patches.
> >
> > Oh this was a long time ago, pre ath5k I think.
> >
> > > > john reverts his patches on wireless-testing before rebasing to Linus'
> > > > tree. There may be some other added benefit other than helping us
> > > > rebase cleanly, not sure. But I do remember before that I never was
> > > > able to rebase my patches, and now rebasing works quite nicely.
> > >
> > > You mean it's better to track wireless-next-2.6 for those of us trying
> > > to stay on top of the wireless development?
> >
> > No, not at all, I meant wireless-next-2.6 is best for bisecting.
> >
> > wireless-testing is indeed the place to look at for development.
> >
> > > I must have missed the
> > > memo.
> >
> > I don't think we ever really publized this much, because technically
> > the reverting won't happen unless John rebases and typically between
> > rebases to a next RC kernel you *could* technically bisect an issue.
> > But not all the times.
> >
> > > Indeed, wireless-next-2.6 has a couple of commits that
> > > wireless-testing doesn't have yet.
> > >
> > > I agree that having to bisect through reverts is not fun, and it takes
> > > one or two extra iterations.
> >
> > Right, which is why I wanted to mention it, will extend the info on
> > the wiki on the development section once John ACKs/NACKs this.
> 
> It should not be necessary to bisect through reverts.  I maintain
> different tags for such purposes.
>
> Always use the lastest merge-* tag as the base for bisection.
> This should be equivalent to whichever -rc release from Linus is the
> current base for wireless-testing.  If you need to go any earlier
> than that, you should be using linux-2.6.
>
> So for example with current tree:
> 
>         git bisect start
>         git bisect bad master-2009-08-19
>         git bisect good merge-2009-08-14
> 
> This should include all of the current wireless patches in
> wireless-testing but not in the base linux-2.6 kernel.

This does indeed help alot. Just to be clear let me provide an
example. So say git tag -l | grep merge | tail -3 yields:

merge-2009-07-24
merge-2009-08-03
merge-2009-08-14

I believe what you are indicating if you are bisecting using to avoid
running into the reverts you'd have to ensure then that you bisect between
a bad commit and the next dated merge tag. So if you ran into a snag say
on master-2009-08-06, you should test if merge-2009-08-03 is good first,
and if its not then consider using linux-2.6.git ? If so wouldn't
the code on master-2009-08-06 not yet be available on linux-2.6.git?

> I haven't tracked-down this thread in the archives...am I addressing
> the issue correctly?

Indeed! Thanks a lot.

  Luis

Re: bisecting with wireless-testing

[Luis R. Rodriguez]

Renaming subject and adding linux-wireless.

On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:
> On Tue, Aug 18, 2009 at 02:57:48PM -0700, Luis R. Rodriguez wrote:
> > On Tue, Aug 18, 2009 at 02:45:00PM -0700, Pavel Roskin wrote:
> > > On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
> > >
> > > > > Anyway, why is it better for bisecting?

Just for reference for linux-wireles readers here I had indicated
wireless-next-2.6 was better for bisecting than wireless-testing.

> > > >
> > > > Because to help developers not have to do:
> > > >
> > > > git branch -m poo
> > > > git checkout -b master origin/master
> > > > # Then apply patches manually
> > > >
> > > > Instead of the better rebasing:
> > > >
> > > > git branch -m save-my-stuff
> > > > git checkout -b master origin/master
> > > > git checkout save-my-stuff
> > > > git rebase master
> > >
> > > I use STGit, so perhaps I miss all that fun.  I have never had any
> > > trouble tracking wireless-testing while keeping my patches.
> >
> > Oh this was a long time ago, pre ath5k I think.
> >
> > > > john reverts his patches on wireless-testing before rebasing to Linus'
> > > > tree. There may be some other added benefit other than helping us
> > > > rebase cleanly, not sure. But I do remember before that I never was
> > > > able to rebase my patches, and now rebasing works quite nicely.
> > >
> > > You mean it's better to track wireless-next-2.6 for those of us trying
> > > to stay on top of the wireless development?
> >
> > No, not at all, I meant wireless-next-2.6 is best for bisecting.
> >
> > wireless-testing is indeed the place to look at for development.
> >
> > > I must have missed the
> > > memo.
> >
> > I don't think we ever really publized this much, because technically
> > the reverting won't happen unless John rebases and typically between
> > rebases to a next RC kernel you *could* technically bisect an issue.
> > But not all the times.
> >
> > > Indeed, wireless-next-2.6 has a couple of commits that
> > > wireless-testing doesn't have yet.
> > >
> > > I agree that having to bisect through reverts is not fun, and it takes
> > > one or two extra iterations.
> >
> > Right, which is why I wanted to mention it, will extend the info on
> > the wiki on the development section once John ACKs/NACKs this.
> 
> It should not be necessary to bisect through reverts.  I maintain
> different tags for such purposes.
>
> Always use the lastest merge-* tag as the base for bisection.
> This should be equivalent to whichever -rc release from Linus is the
> current base for wireless-testing.  If you need to go any earlier
> than that, you should be using linux-2.6.
>
> So for example with current tree:
> 
>         git bisect start
>         git bisect bad master-2009-08-19
>         git bisect good merge-2009-08-14
> 
> This should include all of the current wireless patches in
> wireless-testing but not in the base linux-2.6 kernel.

This does indeed help alot. Just to be clear let me provide an
example. So say git tag -l | grep merge | tail -3 yields:

merge-2009-07-24
merge-2009-08-03
merge-2009-08-14

I believe what you are indicating if you are bisecting using to avoid
running into the reverts you'd have to ensure then that you bisect between
a bad commit and the next dated merge tag. So if you ran into a snag say
on master-2009-08-06, you should test if merge-2009-08-03 is good first,
and if its not then consider using linux-2.6.git ? If so wouldn't
the code on master-2009-08-06 not yet be available on linux-2.6.git?

> I haven't tracked-down this thread in the archives...am I addressing
> the issue correctly?

Indeed! Thanks a lot.

  Luis

[ath9k-devel] bisecting with wireless-testing

[John W. Linville]

On Wed, Aug 19, 2009 at 11:34:16AM -0700, Luis R. Rodriguez wrote:
> Renaming subject and adding linux-wireless.
> 
> On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:

> > It should not be necessary to bisect through reverts.  I maintain
> > different tags for such purposes.
> >
> > Always use the lastest merge-* tag as the base for bisection.
> > This should be equivalent to whichever -rc release from Linus is the
> > current base for wireless-testing.  If you need to go any earlier
> > than that, you should be using linux-2.6.
> >
> > So for example with current tree:
> > 
> >         git bisect start
> >         git bisect bad master-2009-08-19
> >         git bisect good merge-2009-08-14
> > 
> > This should include all of the current wireless patches in
> > wireless-testing but not in the base linux-2.6 kernel.
> 
> This does indeed help alot. Just to be clear let me provide an
> example. So say git tag -l | grep merge | tail -3 yields:
> 
> merge-2009-07-24
> merge-2009-08-03
> merge-2009-08-14
> 
> I believe what you are indicating if you are bisecting using to avoid
> running into the reverts you'd have to ensure then that you bisect between
> a bad commit and the next dated merge tag. So if you ran into a snag say
> on master-2009-08-06, you should test if merge-2009-08-03 is good first,
> and if its not then consider using linux-2.6.git ? If so wouldn't
> the code on master-2009-08-06 not yet be available on linux-2.6.git?

If you look, merge-2009-08-03 is identical to 2.6.31-rc5:

	git diff merge-2009-08-03..v2.6.31-rc5

So if you have a problem in master-2009-08-06, then either the
problem exists in v2.6.31-rc5 or it is between merge-2009-08-03 and
master-2009-08-06.  (Read the tags carefully, they look similar.)

The point is, it never makes sense to use a good marker any
farther back than the most recent merge-* tag when trying to bisect
wireless-testing.  Otherwise, all the reverts and such will cause
confusion.  If the problem still exists at the most recent merge-*
tag, then the problem is in linux-2.6 and should be bisected there.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville at tuxdriver.com			might be all we have.  Be ready.

Re: bisecting with wireless-testing

[John W. Linville]

On Wed, Aug 19, 2009 at 11:34:16AM -0700, Luis R. Rodriguez wrote:
> Renaming subject and adding linux-wireless.
> 
> On Wed, Aug 19, 2009 at 10:58:09AM -0700, John W. Linville wrote:

> > It should not be necessary to bisect through reverts.  I maintain
> > different tags for such purposes.
> >
> > Always use the lastest merge-* tag as the base for bisection.
> > This should be equivalent to whichever -rc release from Linus is the
> > current base for wireless-testing.  If you need to go any earlier
> > than that, you should be using linux-2.6.
> >
> > So for example with current tree:
> > 
> >         git bisect start
> >         git bisect bad master-2009-08-19
> >         git bisect good merge-2009-08-14
> > 
> > This should include all of the current wireless patches in
> > wireless-testing but not in the base linux-2.6 kernel.
> 
> This does indeed help alot. Just to be clear let me provide an
> example. So say git tag -l | grep merge | tail -3 yields:
> 
> merge-2009-07-24
> merge-2009-08-03
> merge-2009-08-14
> 
> I believe what you are indicating if you are bisecting using to avoid
> running into the reverts you'd have to ensure then that you bisect between
> a bad commit and the next dated merge tag. So if you ran into a snag say
> on master-2009-08-06, you should test if merge-2009-08-03 is good first,
> and if its not then consider using linux-2.6.git ? If so wouldn't
> the code on master-2009-08-06 not yet be available on linux-2.6.git?

If you look, merge-2009-08-03 is identical to 2.6.31-rc5:

	git diff merge-2009-08-03..v2.6.31-rc5

So if you have a problem in master-2009-08-06, then either the
problem exists in v2.6.31-rc5 or it is between merge-2009-08-03 and
master-2009-08-06.  (Read the tags carefully, they look similar.)

The point is, it never makes sense to use a good marker any
farther back than the most recent merge-* tag when trying to bisect
wireless-testing.  Otherwise, all the reverts and such will cause
confusion.  If the problem still exists at the most recent merge-*
tag, then the problem is in linux-2.6 and should be bisected there.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

On Wednesday 19 Aug 2009 2:34:50 am Pavel Roskin wrote:
> On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
> > > Note that Michael noticed the performance degradation.  That's another
> > > target for bisection, whether it's related or not.
> >
> > Any way we can help debug this issue?
> > It gets really annoying when the driver goes berserk in the middle of a
> > big file transfer - even on LAN. :(
>
> If an older driver didn't have that problem, you can use the git bisect
> command to find which change introduced the slowdown, provided that you
> can detect it reliably.

Unfortunately, this is the only version I have tried.

I decided to buy this laptop only after looking that the h/w is mostly 
supported in linux kernel >= 2.6.29 - which is where the ath9k got support for 
9285, IIRC. After installing base kubuntu jaunty on it, I cloned the ubuntu-
karmic git tree which is based on >= 2.6.30 so that I'd get both the ath9k for 
9285 as well as radeonhd driver for the ATi Radeon HD 4650 that the laptop 
comes with.

So, I don't know whether support for 9285 was working in earlier versions at 
all. :(

If you can provide me with the starting pointers, I'll try to dig deeper.

Thanks,
-- 
Kunal

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

On Wednesday 19 Aug 2009 9:21:13 am Sujith wrote:
> Kunal Gangakhedkar wrote:
> > Any way we can help debug this issue?
> > It gets really annoying when the driver goes berserk in the middle of a
> > big file transfer - even on LAN. :(
> >
> > rmmod'ing and modprobe'ing the driver again seems to get it working; but,
> > as the network load increases, the driver again starts faltering.
> >
> > The problem starts especially under load on the network - say, while
> > transferring ISOs from desktop to laptop, or updating ubuntu packages.
> >
> > When the driver exhibits the problem, the ping times on the LAN also go
> > berserk - ranging from ~1ms to ~700ms while sitting next to the wireless
> > router (Linksys WRT54GL running OpenWRT Kamikaze 8.09) with packets lost.
> > The router is working fine because my other laptop (IBM Thinkpad R51
> > running ipw2200) never has any problems with the WLAN.
> >
> > I'm using linux kernel 2.6.31-4-generic (x86_64) on kubuntu jaunty on
> > this new HP laptop (dv6 series). The kernel is built by myself from
> > ubuntu-karmic.git (git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git)
> >
> > Config options related to ath9k in the kernel:
> >
> > kunal at plutonium:/boot$ grep 'CONFIG_ATH9K' config-2.6.31-4-generic
> > CONFIG_ATH9K=m
> > CONFIG_ATH9K_DEBUG=y
>
> Can you load the driver with the modparam 'debug=0x200' and post the kernel
> log when this issue happens ? Thanks.
>
> Sujith

I'll post the logs over the weekend - right now, tied up with work :(

Thanks,
-- 
Kunal

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

On Wednesday 19 Aug 2009 9:21:13 am Sujith wrote:
> Kunal Gangakhedkar wrote:
> > Any way we can help debug this issue?
> > It gets really annoying when the driver goes berserk in the middle of a
> > big file transfer - even on LAN. :(
> >
> > rmmod'ing and modprobe'ing the driver again seems to get it working; but,
> > as the network load increases, the driver again starts faltering.
> >
> > The problem starts especially under load on the network - say, while
> > transferring ISOs from desktop to laptop, or updating ubuntu packages.
> >
> > When the driver exhibits the problem, the ping times on the LAN also go
> > berserk - ranging from ~1ms to ~700ms while sitting next to the wireless
> > router (Linksys WRT54GL running OpenWRT Kamikaze 8.09) with packets lost.
> > The router is working fine because my other laptop (IBM Thinkpad R51
> > running ipw2200) never has any problems with the WLAN.
> >
> > I'm using linux kernel 2.6.31-4-generic (x86_64) on kubuntu jaunty on
> > this new HP laptop (dv6 series). The kernel is built by myself from
> > ubuntu-karmic.git (git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git)
> >
> > Config options related to ath9k in the kernel:
> >
> > kunal at plutonium:/boot$ grep 'CONFIG_ATH9K' config-2.6.31-4-generic
> > CONFIG_ATH9K=m
> > CONFIG_ATH9K_DEBUG=y
>
> Can you load the driver with the modparam 'debug=0x200' and post the kernel
> log when this issue happens ? Thanks.
>
> Sujith

Attaching the gzipped log with ath9k loaded with modparam "debug=0x200".
The commands I used to get the logs are:
$ grep -P "(ath(9k)?|wlan)" /var/log/kern.log > ~/ath9k.log
$ gzip -9 ath9k.log

Please let me know if anything more is needed.

Kunal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath9k.log.gz
Type: application/x-gzip
Size: 159081 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090825/8a11631e/attachment-0001.bin 

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

Hi Sujith,

Any update on this problem?
I tried it on .31-rc9 (using ubuntu's ubuntu-karmic.git - which is
rebased to -rc9) again, and the problem still exists.

As I mentioned earlier, the driver absolutely drops the WLAN
connection when subjected to network IO (apparently, anything >10MiB
cannot be transferred over the network without rmmod + modprobe
exercise a couple of times).

Last night, I tried to scp a 60MiB tar from desktop to laptop - I had
to rmmod + modprobe the driver twice.
It gives good speeds when the transfer starts initially; but as it
progresses, the transfer speed keeps dropping to really unusable
levels - just a few (<10) KiB's per second. :(

The same file when scp'ed from Vista (pre-installed on the laptop) has
absolutely no problems - gets over in ~1min - maybe even less - I
didn't see the actual clock time; but it's measurably low wrt linux.

Are there any patches that you'd like me to try on top of the
mainline/ubuntu's tree?

Thanks,
Kunal



On Tue, Aug 25, 2009 at 2:28 AM, Kunal Gangakhedkar
<kunal.gangakhedkar@gmail.com> wrote:
> On Wednesday 19 Aug 2009 9:21:13 am Sujith wrote:
>> Kunal Gangakhedkar wrote:
>> > Any way we can help debug this issue?
>> > It gets really annoying when the driver goes berserk in the middle of a
>> > big file transfer - even on LAN. :(
>> >
>> > rmmod'ing and modprobe'ing the driver again seems to get it working; but,
>> > as the network load increases, the driver again starts faltering.
>> >
>> > The problem starts especially under load on the network - say, while
>> > transferring ISOs from desktop to laptop, or updating ubuntu packages.
>> >
>> > When the driver exhibits the problem, the ping times on the LAN also go
>> > berserk - ranging from ~1ms to ~700ms while sitting next to the wireless
>> > router (Linksys WRT54GL running OpenWRT Kamikaze 8.09) with packets lost.
>> > The router is working fine because my other laptop (IBM Thinkpad R51
>> > running ipw2200) never has any problems with the WLAN.
>> >
>> > I'm using linux kernel 2.6.31-4-generic (x86_64) on kubuntu jaunty on
>> > this new HP laptop (dv6 series). The kernel is built by myself from
>> > ubuntu-karmic.git (git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git)
>> >
>> > Config options related to ath9k in the kernel:
>> >
>> > kunal at plutonium:/boot$ grep 'CONFIG_ATH9K' config-2.6.31-4-generic
>> > CONFIG_ATH9K=m
>> > CONFIG_ATH9K_DEBUG=y
>>
>> Can you load the driver with the modparam 'debug=0x200' and post the kernel
>> log when this issue happens ? Thanks.
>>
>> Sujith
>
> Attaching the gzipped log with ath9k loaded with modparam "debug=0x200".
> The commands I used to get the logs are:
> $ grep -P "(ath(9k)?|wlan)" /var/log/kern.log > ~/ath9k.log
> $ gzip -9 ath9k.log
>
> Please let me know if anything more is needed.
>
> Kunal
>

[ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

On Wednesday 16 Sep 2009 7:56:40 am you wrote:
> Hi Kunal,
> I read your mails on ath9k-devel, have you tried using an ath9k build
> from September recently?
>
> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6
>.tar.bz2
>
> My Asus is using an AR9285,too, and my wifi was dropping every 1-30
> minutes on 2.6.30 and 2.6.31, but now using the ath9k build 09-15-2009,
> my signal is gone up from <50% to ~90% and the connection is rock-stable
> =)
> Maybe give it a try, hope this issue is still current for you
>
> regards
> chris

Hi Chris,

I tested today's compat-wireless - compat-wireless-2009-09-16.
Unfortunately, I still seem to have problems with the ath9k driver.

While pinging my wireless router - which is just next to where I'm sitting - I 
consistently have 2 packets dropped after every 3 packets.

The details of compat-wireless tree:

kunal at plutonium:~/work/my_work/compat-wireless-2009-09-16$ cat git-describe
wireless-testing.git
v2.6.31-38254-g2953d61

kunal at plutonium:~/work/my_work/compat-wireless-2009-09-16$ cat compat-release
master-2009-09-04-1-g10f3185

kunal at plutonium:~/work/my_work/compat-wireless-2009-09-16$ cat master-tag
master-2009-09-14

modinfo ath9k output for the compat-wireless driver (indicated by updates/ in 
the path):
kunal at plutonium:~/work/my_work/compat-wireless-2009-09-16$ modinfo ath9k
filename:       /lib/modules/2.6.31-10-
generic/updates/drivers/net/wireless/ath/ath9k/ath9k.ko
license:        Dual BSD/GPL
description:    Support for Atheros 802.11n wireless LAN cards.
author:         Atheros Communications
srcversion:     7524C955935F75022BC1C31
alias:          pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends:        mac80211,led-class,ath,cfg80211
vermagic:       2.6.31-10-generic SMP mod_unload modversions
parm:           debug:uint
parm:           nohwcrypt:Disable hardware encryption (int)


ping output to my router:
kunal at plutonium:~/work/my_work/compat-wireless-2009-09-16$ ping openwrt
PING openwrt.lan (192.168.10.1) 56(84) bytes of data.
64 bytes from openwrt (192.168.10.1): icmp_seq=1 ttl=64 time=2.54 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=5 ttl=64 time=1182 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=6 ttl=64 time=177 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=9 ttl=64 time=3.32 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=10 ttl=64 time=3.62 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=11 ttl=64 time=3.58 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=14 ttl=64 time=3.97 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=15 ttl=64 time=5.26 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=16 ttl=64 time=7.54 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=19 ttl=64 time=4.57 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=20 ttl=64 time=2.49 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=21 ttl=64 time=2.73 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=24 ttl=64 time=3.40 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=26 ttl=64 time=3.40 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=29 ttl=64 time=2.02 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=30 ttl=64 time=3.08 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=31 ttl=64 time=2.32 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=34 ttl=64 time=2.94 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=35 ttl=64 time=3.54 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=36 ttl=64 time=3.97 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=39 ttl=64 time=3.55 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=40 ttl=64 time=3.07 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=41 ttl=64 time=3.37 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=44 ttl=64 time=2028 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=45 ttl=64 time=1020 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=46 ttl=64 time=10.6 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=49 ttl=64 time=3.51 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=50 ttl=64 time=3.61 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=51 ttl=64 time=2.94 ms
^C
--- openwrt.lan ping statistics ---
53 packets transmitted, 29 received, 45% packet loss, time 52212ms
rtt min/avg/max/mdev = 2.022/155.337/2028.724/450.597 ms, pipe 3

As can be seen from the icmp_seq nos., most of the times, I get 2 packets 
dropped after every 3 packets.

And I'm running this entire exercise sitting right next to the router - which 
is a Linksys WRT54GL running OpenWRT Kamikaze (8.09) release.

The rest of the setup on the laptop is plain standard Kubuntu setup - no 
modifications done to any other file.

I'm including both ath9k-devel and linux-wireless mailing lists in Cc: - 
maybe, someone from there might have a clue about what's going on.

Kunal

Re: [ath9k-devel] Disconnect problem (DMA failed to stop in 10 ms)

[Kunal Gangakhedkar]

On Wednesday 16 Sep 2009 7:56:40 am you wrote:
> Hi Kunal,
> I read your mails on ath9k-devel, have you tried using an ath9k build
> from September recently?
>
> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6
>.tar.bz2
>
> My Asus is using an AR9285,too, and my wifi was dropping every 1-30
> minutes on 2.6.30 and 2.6.31, but now using the ath9k build 09-15-2009,
> my signal is gone up from <50% to ~90% and the connection is rock-stable
> =)
> Maybe give it a try, hope this issue is still current for you
>
> regards
> chris

Hi Chris,

I tested today's compat-wireless - compat-wireless-2009-09-16.
Unfortunately, I still seem to have problems with the ath9k driver.

While pinging my wireless router - which is just next to where I'm sitting - I 
consistently have 2 packets dropped after every 3 packets.

The details of compat-wireless tree:

kunal@plutonium:~/work/my_work/compat-wireless-2009-09-16$ cat git-describe
wireless-testing.git
v2.6.31-38254-g2953d61

kunal@plutonium:~/work/my_work/compat-wireless-2009-09-16$ cat compat-release
master-2009-09-04-1-g10f3185

kunal@plutonium:~/work/my_work/compat-wireless-2009-09-16$ cat master-tag
master-2009-09-14

modinfo ath9k output for the compat-wireless driver (indicated by updates/ in 
the path):
kunal@plutonium:~/work/my_work/compat-wireless-2009-09-16$ modinfo ath9k
filename:       /lib/modules/2.6.31-10-
generic/updates/drivers/net/wireless/ath/ath9k/ath9k.ko
license:        Dual BSD/GPL
description:    Support for Atheros 802.11n wireless LAN cards.
author:         Atheros Communications
srcversion:     7524C955935F75022BC1C31
alias:          pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends:        mac80211,led-class,ath,cfg80211
vermagic:       2.6.31-10-generic SMP mod_unload modversions
parm:           debug:uint
parm:           nohwcrypt:Disable hardware encryption (int)


ping output to my router:
kunal@plutonium:~/work/my_work/compat-wireless-2009-09-16$ ping openwrt
PING openwrt.lan (192.168.10.1) 56(84) bytes of data.
64 bytes from openwrt (192.168.10.1): icmp_seq=1 ttl=64 time=2.54 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=5 ttl=64 time=1182 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=6 ttl=64 time=177 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=9 ttl=64 time=3.32 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=10 ttl=64 time=3.62 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=11 ttl=64 time=3.58 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=14 ttl=64 time=3.97 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=15 ttl=64 time=5.26 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=16 ttl=64 time=7.54 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=19 ttl=64 time=4.57 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=20 ttl=64 time=2.49 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=21 ttl=64 time=2.73 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=24 ttl=64 time=3.40 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=26 ttl=64 time=3.40 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=29 ttl=64 time=2.02 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=30 ttl=64 time=3.08 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=31 ttl=64 time=2.32 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=34 ttl=64 time=2.94 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=35 ttl=64 time=3.54 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=36 ttl=64 time=3.97 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=39 ttl=64 time=3.55 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=40 ttl=64 time=3.07 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=41 ttl=64 time=3.37 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=44 ttl=64 time=2028 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=45 ttl=64 time=1020 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=46 ttl=64 time=10.6 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=49 ttl=64 time=3.51 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=50 ttl=64 time=3.61 ms
64 bytes from openwrt (192.168.10.1): icmp_seq=51 ttl=64 time=2.94 ms
^C
--- openwrt.lan ping statistics ---
53 packets transmitted, 29 received, 45% packet loss, time 52212ms
rtt min/avg/max/mdev = 2.022/155.337/2028.724/450.597 ms, pipe 3

As can be seen from the icmp_seq nos., most of the times, I get 2 packets 
dropped after every 3 packets.

And I'm running this entire exercise sitting right next to the router - which 
is a Linksys WRT54GL running OpenWRT Kamikaze (8.09) release.

The rest of the setup on the laptop is plain standard Kubuntu setup - no 
modifications done to any other file.

I'm including both ath9k-devel and linux-wireless mailing lists in Cc: - 
maybe, someone from there might have a clue about what's going on.

Kunal