wpa_supplicant (Was: Re: wpi not working on today's current (r208626))

[Doug Barton]

On 05/29/10 03:54, b. f. wrote:
> On 5/29/10, Rui Paulo<rpaulo at freebsd.org>  wrote:
>>
>> On 29 May 2010, at 05:39, b. f. wrote:
>>
>>> On 5/28/10, Doug Barton<dougb at freebsd.org>  wrote:
>>>> On 5/28/2010 4:50 PM, b. f. wrote:
>>>>>
>>>>> I can't see any problems when using WPA2 with AES on r208606 i386 with
>>>>> uath(4).  I'm updating this machine to r208630 tonight, and if I
>>>>> encounter problems with the later revision, I'll let you know.
>>>>
>>>> Ok, thanks.
>>>>
>>>>> Are
>>>>> you saying that you experienced problems when trying to use a r207134
>>>>> base with a r208626 kernel?  If that's the case, I would recommend
>>>>> updating the base to the same revision as the kernel, and then
>>>>> retesting.
>>>>
>>>> Yes, that's what I'm doing I actually tried running the newly built
>>>> wpa_supplicant but that didn't work. I'm kind of hesitant to do the full
>>>> upgrade since I'm having kernel problems with the nvidia driver, but if
>>>> I'm sure wpa_supplicant will work then I suppose I can bite the bullet.
>>>>
>>>
>>> It appears that something is wrong.  My wireless stick no longer
>>> associates with the network with r208630.  I'll do some tinkering.
>>
>> That's odd. The only way for that to happen would be caused bug in the
>> taskqueue stuff that zml committed, I think, but that's a long shot.
>>
>> Regards,
>> --
>> Rui Paulo
>
> Yes, that was also my suspicion, and after seeing, via top(1), that
> ifconfig is stuck in the   "*taskq" state while attempting to set up
> the wlan, I believe either r208623, or r208624, or both, is
> responsible for the regression.

Reverting those two changes allows wpa_supplicant to work again. Thanks 
for the hint bf.

Zach?

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/