sd8686 linux system hang when associating to access point
jic23 at cam.ac.uk
Wed Jun 10 07:19:22 EDT 2009
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.
>>>> 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 126.96.36.199 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;
> 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.
More information about the libertas-dev