On 07/01/2011 01:10 AM, Johannes Berg wrote:
Very little significant changes in this area, but I've a non-related
proprietary module loaded, and patches to various other parts of the
networking code.
The full tree is here if you want to take a look, or I can send
you a full unified diff:
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux.wireless-testing-ct.ct/.git;a=summary
Fair enough, I don't see anything there that would impact this bug.
Seems a tricky timing related bug, possibly we're only hitting it because
we're testing on an older C3 processor system that is significantly slower
than our normal test systems.
Hm. That seems odd. I didn't see anything that lacked locking either.
I think the detail that we need to investigate is what you said before:
configured for in-kernel authentication,
re-configure them for supplicant, let them associate, delete one of
them.
but I don't see anything there either right now.
Well, would you accept a patch that checked for null bssid, and did a WARN_ON
and bailed out if found? Seems little harm, and we verified that the system
otherwise remained stable with such a patch added...
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
