SDIO stability [was Re: SDIO Performance once again]

Sven Neumann s.neumann at
Wed Feb 11 05:55:39 EST 2009


On Tue, 2009-02-10 at 16:26 +0100, Sven Neumann wrote:

> > You'd see error messages and MMC/SD host register dumps if stuff starts
> > going wrong.  If you don't see anything that looks suspicious, then it
> > may not be the host controller.
> I guess we can rule that out then as I don't see anything suspicious in
> the MMC debug output.

Perhaps that was wrong. I am pretty new to all this kernel stuff and I
might have missed some output because I didn't have klogd running. Now
that I changed that, I noticed the following output before the libertas
driver starts to break down:

user.debug kernel: mmc1:0001: error -84 reading SDIO_CCCR_INTx

Immidiately followed by:

user.warn kernel: ------------[ cut here ]------------
user.warn kernel: WARNING: at net/sched/sch_generic.c:226 dev_watchdog+0x260/0x280() kernel: NETDEV WATCHDOG: eth1 (libertas_sdio): transmit timed out
user.warn kernel: Modules linked in: libertas_sdio libertas lib80211 wm97xx_ts pxamci mmc_core snd_soc_cm_x300 snd_soc_wm9712 snd_soc_pxa2xx_ac97 snd_soc_pxa2xx snd_pxa2xx_lib snd_soc_core ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc
user.warn kernel: [<c027f830>] (dump_stack+0x0/0x14) from [<c0042bb0>] (warn_slowpath+0x68/0x9c)
user.warn kernel: [<c0042b48>] (warn_slowpath+0x0/0x9c) from [<c021a490>] (dev_watchdog+0x260/0x280)
user.warn kernel:  r3:c39e8000 r2:c0314f20
user.warn kernel:  r7:00000000 r6:c39e8000 r5:c03a66f8 r4:c033ad80
user.warn kernel: [<c021a230>] (dev_watchdog+0x0/0x280) from [<c004caec>] (run_timer_softirq+0x1ac/0x238)
user.warn kernel:  r7:c021a230 r6:c0333ea0 r5:00000100 r4:c039af00
user.warn kernel: [<c004c940>] (run_timer_softirq+0x0/0x238) from [<c0047fd4>] (__do_softirq+0x7c/0x128)
user.warn kernel: [<c0047f58>] (__do_softirq+0x0/0x128) from [<c00480c8>] (irq_exit+0x48/0x50)
user.warn kernel: [<c0029000>] (__exception_text_start+0x0/0x74) from [<c0029ad0>] (__irq_svc+0x30/0xc0)
user.warn kernel: Exception stack(0xc0333f40 to 0xc0333f88)
user.warn kernel: 3f40: 00000001 c381a8a0 00000000 60000013 c002b50c c0332000 c002b50c c0358c68 
user.warn kernel: 3f60: a00221e8 69056881 a0022180 c0333f94 c0333f98 c0333f88 c002b560 c002b56c 
user.warn kernel: 3f80: 60000013 ffffffff                                                       
user.warn kernel:  r6:04000000 r5:c0333f74 r4:ffffffff
user.warn kernel: [<c002b50c>] (default_idle+0x0/0x68) from [<c002b4f0>] (cpu_idle+0x44/0x60)
user.warn kernel: [<c002b4ac>] (cpu_idle+0x0/0x60) from [<c027d094>] (rest_init+0x54/0x68)
user.warn kernel:  r7:c0336408 r6:c0023ea8 r5:c0358824 r4:c039d910
user.warn kernel: [<c027d040>] (rest_init+0x0/0x68) from [<c0008af4>] (start_kernel+0x21c/0x2b8)
user.warn kernel: [<c00088d8>] (start_kernel+0x0/0x2b8) from [<a0008034>] (0xa0008034)
user.warn kernel:  r6:c00242ac r5:c0358ccc r4:0000397d
user.warn kernel: ---[ end trace 25c330c9338b889e ]---
user.err kernel: libertas: tx watch dog timeout kernel: libertas: command 0x001f timed out kernel: libertas: requeueing command 0x001f due to timeout (#1)

Note that I didn't run into the "problem fetching packet from firmware"
during this test. So there might be two separate problems here. I will
run some more tests and try to gather more insight by adding some more
debug output in critical places...

Thanks for your patience,

More information about the libertas-dev mailing list