Date: Tue, 06 Nov 2007 09:18:09 -0800 From: Sam Leffler <sam@errno.com> To: Frank Staals <frankstaals@gmx.net> Cc: freebsd-current <freebsd-current@freebsd.org>, Benjamin Close <Benjamin.Close@clearchain.com> Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) Message-ID: <4730A1D1.8020607@errno.com> In-Reply-To: <473082C5.5080700@gmx.net> References: <472A6708.9030109@clearchain.com> <472B779B.9060002@gmx.net> <472B9597.2050108@clearchain.com> <473082C5.5080700@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Frank Staals wrote:
> Benjamin Close wrote:
>> Frank Staals wrote:
> <snip>
>>>
>>>
>>>
>>> Everything works fine with the connection itself. Allthough
>>> sometimes when switching from tty9 to tty0 and back the system locks
>>> up. I've had it before when switching from tty1 to tty0. Anyone
>>> with the same problems ?
>>>
>>> Anyway; Great work on the driver so far :D
>>>
>> I've similar issues and believe it might be due to the amount of
>> kernel printfs that are happening. Can you sysctl debug.wpi=0 and
>> see if the problem still exists?
>> By chance are you using ZFS? I caught a memory modified after free
>> panic in zfs the other day pid was from syslogd. I'm trying to work
>> out if it's related.
>>
>> Cheers,
>> Benjamin
>>
> When setting debug.wpi to 0 it seems like the problem is gone. I'm not
> using ZFS by the way. I did have a problem connecting to the AP at my
> university though; the driver wouldn't assosicate whatever I tried. I
> didn't have a chance to do some extensive testing though. It might be
> because of the WEP+wpa_supplicant + ca certificate method that is
> required to authenticate. Anyway I'll let it know if there is an
> actual problem with the driver itself
Rule of thumb in debugging wireless issues (and most others for that
matter): simplify your config if at all possible. In this case try
checking things out w/o wpa_supplicant (i.e. no crypto).
When debugging, start at the top and work your way down to rule out
problems at each layer. In this case collect a wpa_supplicant debug log
first, then check for issues at the net80211 layer (wlandebug,
wlanstats, etc.), then finally check at the driver level.
Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4730A1D1.8020607>