SDIO Performance once again

Dan Williams dcbw at
Mon Feb 9 10:59:18 EST 2009

On Mon, 2009-02-09 at 13:51 +0100, Sven Neumann wrote:
> Hi,
> On Sun, 2009-02-08 at 17:56 +0100, Dominik S. Herwald wrote:
> > right now I am testing Marvell 8686 based Modules connected to the SDIO
> > Controller of a Blackfin BF548.
> > 
> > Basically the libertas driver works just fine and stable.  
> > But the Performance... :-/ 
> Interesting. We are having the contrary experience here. Running a
> CM-X300 board, which is a PXA 300 featuring a Marvell 8686 module
> connected to the SDIO controller, we are seeing a performance of about
> 13 Mbits/sec.
> Unfortunately this is not stable. Sometimes (rarely on one of the two
> boards we have, frequently on the other), there are errors:
> libertas: tx watch dog timeout

Either hung firmware, or missed interrupts from Libertas -> host.

> When this happens it usually takes about six seconds for the module to
> recover. During this period nothing is transmitted. At some point,
> sooner or later, the following errors shows up:
> libertas: command 0x001f timed out
> libertas: requeueing command 0x001f due to timeout (#1)
> libertas: command 0x001f timed out
> libertas: requeueing command 0x001f due to timeout (#2)
> libertas: command 0x001f timed out
> libertas: requeueing command 0x001f due to timeout (#3)
> libertas: tx watch dog timeout
> libertas: command 0x001f timed out
> libertas: Excessive timeouts submitting command 0x001f

Same thing; hung firmware or missed interrupts.  Something is getting
out of sync.

> At this point the module stops to work completely and I haven't found a
> way to recover from this. The system then needs to be restarted.

Right; there isn't a known good way to force-reset the chip yet; all you
can do right now really is hook a GPIO up to toggle the power of the SD
slot (or if not a slot, the card).  Reset mechanisms are apparently
pretty controller-dependent.  Philip (see last weeks mails) had a method
that might work, involving sending the SDIO ABORT command to kick the
card in the face.  That might work.

> We are using linux-2.6.29-rc4 currently, but observed the same problems
> with linux-2.6.26. The firmware version is 8.73.7p3. I have also tried
> the 9.70.3 firmware, that didn't help either.
> Has anyone experienced similar problems? Any ideas what I could try to
> get some more debug output from the driver?

You might try using the MMC debug options to see what's actually
happening at the SDIO level, and see if there are errors even below the
libertas code.  If the MMC/SDIO stack and the card are having problems
talking, obviously the libertas driver is going to have problems too.
However, if we could find a good way of resetting the card on-the-fly,
then we could find out if the firmware is likely getting wedged, or if
the host controller is more likely having the issues.


More information about the libertas-dev mailing list