Date: Thu, 8 Jul 2010 15:12:37 +1200 From: Andrew Thompson <thompsa@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Sam Leffler <sam@freebsd.org>, PseudoCylon <moonlightakkiy@yahoo.ca>, freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers Message-ID: <AANLkTinSyE91xkoBObKKMZ9Z88-FnyS1QKhRhKNfCBeB@mail.gmail.com> In-Reply-To: <201007072113.16320.hselasky@c2i.net> References: <201007072113.16320.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 July 2010 07:13, Hans Petter Selasky <hselasky@c2i.net> wrote: > Hi, > > When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID, > I have seen kernel panics several times when using USB based WLAN dongles. > When only supplying a valid password, no panic has been seen. > > How to reproduce: > > 1) configure invalid password > 2) wpa_cli: reconfigure > 3) configure valid password > 4) wpa_cli: reconfigure > 5) goto 1 > > The USB commands which are executed inside the newstate callback usually take > very little time, but still not as little time as PCI read/writes. I've forced > slower operation in the newstate callback, and can reproduce warning printouts > from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your > USB code: > > http://p4web.freebsd.org/@@180604?ac=10 > > In my opinion the deferring of all states to a single task is wrong. There > should be at least one task per possible state, and the queuing mechanism > should follow the last-queued is last executed rule. This is not the case with > the task-queue mechanism in the kernel. You dont say why it should be this way, do you have an example of a problem this fixes? I think the single state thread is correct. The whole thing works on state transitions, you dont just set a state. > > Description of panics. I didn't have core dump enabled on this box, so please > bear over with the following hand-written notes: > > 1) A vap->iv_bss == NULL, inside ratectl task in RUM driver. > > 2) A memcpy() fails inside the iee80211...newstate_cb() > > 3) This and similar printouts are seen: > > wlan0: ieee80211_new_state_locked: pending AUTH -> ASSOC transition lost Can you see if you can get a core dump, or at least a DDB trace and the output from `show vap <addr>` Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinSyE91xkoBObKKMZ9Z88-FnyS1QKhRhKNfCBeB>