ath9k very unstable and kills file-system.

ath9k very unstable and kills file-system.

[Ben Greear]

It's been another frustrating week for using ath9k.

With a patched wpa_supplicant (found here:
https://github.com/greearb/hostap-ct/tree/)
I can reliably cause ath9k to spew all sorts of DMA warnings
and evidently crash the hard-drive controller and/or corrupt the
file system so bad that fsck cannot fix it.  (Back up anything you
want to keep before attempting to reproduce this.)

The test case is simply create 30 or so STA interfaces, run one instance
of the patched wpa_supplicant to control the 30 interfaces, and send
a bit of traffic across the interfaces.  It's not even needed to send
any significant data...probably just the supplicant associate logic
is enough.

You'll want the xmit locking patch Felix posted or it will likely spew
lockdep warnings and/or lockup before it gets a chance to crash your
hard drive.

There are no other /n NICs that can do virtual stations, so I must
either get ath9k functional or give up on that feature set entirely.

If anyone wants to help with this and cannot easily reproduce it,
please let me know and I'll furnish scripts etc to make it easier
to reproduce.

I'm also happy to help test patches.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k very unstable and kills file-system.

[Luis R. Rodriguez]

On Fri, Nov 19, 2010 at 5:13 PM, Ben Greear <greearb@candelatech.com> wrote:
> It's been another frustrating week for using ath9k.
>
> With a patched wpa_supplicant (found here:
> https://github.com/greearb/hostap-ct/tree/)
> I can reliably cause ath9k to spew all sorts of DMA warnings
> and evidently crash the hard-drive controller and/or corrupt the
> file system so bad that fsck cannot fix it.  (Back up anything you
> want to keep before attempting to reproduce this.)
>
> The test case is simply create 30 or so STA interfaces, run one instance
> of the patched wpa_supplicant to control the 30 interfaces, and send
> a bit of traffic across the interfaces.  It's not even needed to send
> any significant data...probably just the supplicant associate logic
> is enough.
>
> You'll want the xmit locking patch Felix posted or it will likely spew
> lockdep warnings and/or lockup before it gets a chance to crash your
> hard drive.
>
> There are no other /n NICs that can do virtual stations, so I must
> either get ath9k functional or give up on that feature set entirely.
>
> If anyone wants to help with this and cannot easily reproduce it,
> please let me know and I'll furnish scripts etc to make it easier
> to reproduce.
>
> I'm also happy to help test patches.

If you can provide scripts it will help. The easier it is to reproduce
the easier it can get fixed.

 Luis

Re: ath9k very unstable and kills file-system.

[Felix Fietkau]

On 2010-11-20 2:13 AM, Ben Greear wrote:
> It's been another frustrating week for using ath9k.
> 
> With a patched wpa_supplicant (found here:
> https://github.com/greearb/hostap-ct/tree/)
> I can reliably cause ath9k to spew all sorts of DMA warnings
> and evidently crash the hard-drive controller and/or corrupt the
> file system so bad that fsck cannot fix it.  (Back up anything you
> want to keep before attempting to reproduce this.)
The rx dma warnings went away on my devices with my patch
"ath9k: fix timeout on stopping rx dma"
Please try that one and see if it helps with your corruption issues.

- Felix

Re: ath9k very unstable and kills file-system.

[Björn Smedman]

On Sat, Nov 20, 2010 at 2:13 AM, Ben Greear <greearb@candelatech.com> wrote:
> There are no other /n NICs that can do virtual stations, so I must
> either get ath9k functional or give up on that feature set entirely.

Ben, I for one really appreciate the work you've put into testing
ath9k. I'm quite sure that the fixes found through your efforts have
increased ath9k quality a great deal, also for more common use-cases.

For the sake of all our hard-drives, please don't give up. ;)

/Björn