sd8686 linux system hang when associating to access point

[Jonathan Cameron]

Wood, Brian J wrote:
>> -----Original Message-----
>> From: Jonathan Cameron [mailto:jic23 at cam.ac.uk]
>> Sent: Tuesday, June 09, 2009 11:41 AM
>> To: Wood, Brian J
>> Subject: Re: sd8686 linux system hang when associating to access point
>>
>> Wood, Brian J wrote:
>>>> -----Original Message-----
>>>> From: Jonathan Cameron [mailto:jic23 at cam.ac.uk]
>>>> Sent: Tuesday, June 09, 2009 11:31 AM
>>>> To: Dario Vlah
>>>> Cc: Wood, Brian J; Philip Rakity; libertas-dev at lists.infradead.org
>>>> Subject: Re: sd8686 linux system hang when associating to access point
>>>>
>>>> Dario Vlah wrote:
>>>>> I got the wireless-testing driver to work on JAX10 after I applied the
>>>>> patch that James Cameron posted a while ago on this mailing list.
>>>>> (attached).  Before that it was crashing as you describe; IIRC there was
>>>>> some memory corruption due to calling GET_LOG in the wrong context.
>>>>>
>>>>> --dario
>>>>>
>>>>>
>>>> Oops, that one is still sat in my patches to clean up list.
>>>>
>>>> I didn't think that a GET_LOG call occurred in association but if you
>>>> hit it whilst trying to associate, my guess is something has changed
>>>> in wireless tools.
>>>>
>>>> The patch in question was meant to address some issues when getting
>>>> signal strength readings but I never really considered what else might
>>>> trigger it.
>>> I just applied the patch to the 2.6.29.4 kernel and its complaining when I recompile that wext.c
>> still has two calls to the "log" structure present (must have been inserted after your branch):
>>> priv->wstats.discard.code = le32_to_cpu(log.wepundecryptable);
>>> priv->wstats.discard.misc = le32_to_cpu(log.ackfailure);
>>>
>>> Do you happen to know what I can change these to?
>>>
>>> Thank you, Brian.
>> As a quick sanity check to see if this is your problem, set them to  0 (claim no errors ;)
>>
>> We can clean up what they should actually be as and when resubmitting that patch.
> 
> 
> Hi Jonathan, 
> 
> I set those calls to 0 (and had to set some more inside cmdresp.c), recompiled the kernel and tested...still hangs on association to an accesspoint. 
 
> I also tried to Philip's suggestion of replacing:
> sz = ((sz +3)/4)*4;
> with:
> sz = ((sz + 63)/64)*64;
> inside the function mmc_align_data_size() inside the core.c file...same hang during the association. 
Sorry, I've no idea what else could be going on.

We did have a problem at one point with the driver hanging if we attempted to associate with a non existent
essid, but I've just verified that no longer happens.

I guess you are going to be adding a lot of debug info to try and isolate where exactly it is dying.

Jonathan