problem with libertas driver, Marvell W8686, and PXA270 on 2.6.27-rc7

[Dan Williams]

On Thu, 2008-10-02 at 10:17 -0400, Jeff Sutherland wrote:
> I'm seeking some insight into the structure of the command flow when 
> communicating with a Murata wifi module using the W8686 chip connected via 
> SDIO on a PXA270-based system.  On about 2 out of 3 boot ups, and 
> occasionally when configuring the network interface by hand after the system 
> is up and running, the kernel will oops from the BUG() instruction at line 
> 147 of drivers/net/wireless/libertas/if_sdio.c.  When this happens, the value 
> of priv->resp_len[resp_idx] is always sitting at 142.  It's almost as if the 
> command processing in drivers/net/wireless/libertas/main.c is missing a 
> command somehow.  Curiously, this only seems to happen when the interface is 

Hmm, could well be.  The flow is supposed to be that the interface code
puts responses into the unused slot and wakes up the main thread, and
the main thread processes the response.  Could be that if a second
command response comes back from the card too soon the main thread
wouldn't be woken up to process it yet.

Everything I've seen and read indicates that commands are serialized and
thus we can only have one command outstanding at any one time.  Thus we
can probably rule out fundamental problems with the implementation, but
instead focus on bugs and/or quirks.

Could you by any chance minimally parse the command response in
if_sdio_handle_cmd() with something like:

diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index b54e2ea..024a81e 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -144,6 +144,18 @@ static int if_sdio_handle_cmd(struct if_sdio_card *card,
        spin_lock_irqsave(&priv->driver_lock, flags);
 
        i = (priv->resp_idx == 0) ? 1 : 0;
+
+if (priv->resp_len[i])
+{
+struct cmd_header *resp = (void *) buffer;
+uint16_t respcmd = le16_to_cpu(resp->command);
+uint16_t result = le16_to_cpu(resp->result);
+uint16_t seqnum = le16_to_cpu(resp->seqnum);
+
+lbs_deb_sdio("CMD_RESP: response 0x%04x, result 0x%04x, seq %d, size %d\n",
+            respcmd, result, seqnum, size);
+}
+
        BUG_ON(priv->resp_len[i]);
        priv->resp_len[i] = size;
        memcpy(priv->resp_buf[i], buffer, size);

that coupled with turning on LBS_DEB_CMD and LBS_DEB_SDIO would be quite
interesting to see the results of and should help narrow down what's
going on.  I'm especially interested in the sequence number to see if if
the before-BUG_ON response is the same sequence # as the BUG_ON
response.

Dan

> configured to use WEP or WPA security.  I haven't seen the problem occur when 
> trying to configure an interface associated with an open A/P.  Also I note 
> from my a/p's web page that the module does in fact associate fine every 
> time, as key loading and other configuration occurs early on, and the a/p is 
> currently using WEP plus mac filtering.  It's just things go belly up when 
> the startup scripts try to bring up the interface.  This happens regardless 
> of the firmware version used.  I've tried v7, v8, and v9 firmware with 
> several different kernels from 2.6.25 through to the latest dev stuff from 
> John Linville's wireless-testing git repo.
> 
> There are some issues with the pxa mmc controller hardware as we are painfully 
> aware of, but note that once the interface is successfully configured the 
> network stays up solidly, there don't appear to be any problems once it is 
> configured.  From looking at the code, I suspect a race condition somewhere 
> in the SDIO layer that's causing things to get out of sequence when it comes 
> time to configure the network interface.  A printk placed in certain places 
> causes the driver to fail 100% of the time at that same point in the code 
> with the same value of response length, so something must be on the hairy 
> edge someplace when it does work.
> 
> Regards,
> -Jeff