linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ath5k deadlock w/ blob transfer
@ 2010-05-07 10:50 Nils Radtke
  2010-05-08  1:18 ` Bob Copeland
  0 siblings, 1 reply; 3+ messages in thread
From: Nils Radtke @ 2010-05-07 10:50 UTC (permalink / raw)
  To: linux-wireless; +Cc: linux-kernel

  Hi,

  Guess, this is better suited in here:

>   - ath5k: when starting a blob transfer eg. ssh summer.jpg to the
>     notebook with the ath5k driver running, the wNIC freezes almost
>     immediately! Dead device. This is unfortunately too easily reproducible.
>     In fact, this is a blocker, wireless blob transfer via ssh (other means
>     not tested) is not possible w/o locking it up.

But wait! I just remembered another case. Using the (incomprehensibly) "obsolete"
madwifi diver (note aside: this driver _does_ reduce the _felt_ deadlock frequency 
or kernel panics, referenced by http://lkml.org/lkml/2010/5/3/229, but not 
entirely make them go away). It evenly locks the wireless NIC while transferring
blobs. 

So where should I be posting this? When both drivers deadlock it's either a common 
base in the wireless driver premisses or yet up the path somewhere in the kernel code.

Ideas?


  Thanks,

    Nils


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ath5k deadlock w/ blob transfer
  2010-05-07 10:50 ath5k deadlock w/ blob transfer Nils Radtke
@ 2010-05-08  1:18 ` Bob Copeland
  2010-05-08 14:11   ` Nils Radtke
  0 siblings, 1 reply; 3+ messages in thread
From: Bob Copeland @ 2010-05-08  1:18 UTC (permalink / raw)
  To: Nils Radtke; +Cc: linux-wireless, linux-kernel

On Fri, May 7, 2010 at 6:50 AM, Nils Radtke <lkml@think-future.de> wrote:
>  Hi,
>
>  Guess, this is better suited in here:
>>   - ath5k: when starting a blob transfer eg. ssh summer.jpg to the
>>     notebook with the ath5k driver running, the wNIC freezes almost
>>     immediately! Dead device. This is unfortunately too easily reproducible.

> So where should I be posting this?

You're in the right place...

> When both drivers deadlock it's either a common
> base in the wireless driver premisses or yet up the path somewhere in the
> kernel code.

(Or hardware.  madwifi doesn't use mac80211 so it is probably not
common code, but ath5k could have inherited a bug from it.)

> Ideas?

I missed the first email.  What type of machine?  System lockup
or the connection drops?  Do you get any output on the console or
in dmesg? (try switching to a text console before your scp test.)
If not, any output after lockup booting with nmi_watchdog=1?

-- 
Bob Copeland %% www.bobcopeland.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ath5k deadlock w/ blob transfer
  2010-05-08  1:18 ` Bob Copeland
@ 2010-05-08 14:11   ` Nils Radtke
  0 siblings, 0 replies; 3+ messages in thread
From: Nils Radtke @ 2010-05-08 14:11 UTC (permalink / raw)
  To: Bob Copeland; +Cc: linux-kernel, linux-wireless

  Hi,

> I missed the first email.  What type of machine?  System lockup
> or the connection drops?  Do you get any output on the console or
> in dmesg? (try switching to a text console before your scp test.)
> If not, any output after lockup booting with nmi_watchdog=1?

IRC, no system lockup, only driver lockup. But I avoided using wireless for
blob transfer for the reliability of the lockups, so it's a couple of months
since I deliberately crashed it.. Maybe once in a while it lead to a complete
system lockup, but treat this as rumble in my memories (and could be due to
the other BUGs reported, also)..

notebook: ACER Extensa 5220
kernels since  Linux host 2.6.32.2 #4 PREEMPT Wed Dec 30 15:19:58 CET 2009 i686 and even before
lspci:
04:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
        Subsystem: Device 1a32:0105
        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-
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>

There's another bugreport for this machine, w/ hw info: http://lkml.org/lkml/2010/2/18/104

Ok, trying to lockup the machine once more, will report back then.

  Thanks,

  Nils


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-05-08 14:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-07 10:50 ath5k deadlock w/ blob transfer Nils Radtke
2010-05-08  1:18 ` Bob Copeland
2010-05-08 14:11   ` Nils Radtke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).