Re: d80211 deadlock with wpa_supplicant and rmmod

On 7/12/07, John W. Linville [off-list ref] wrote:

On Thu, Jul 12, 2007 at 12:17:35AM +0100, seventh guardian wrote:

quoted

Hello,
First of all I'm fairly new to this list (in all, this is my first
message), so please be gentle.. I promise I will try not to waste your
precious time.

quoted

I believe we have a deadlock in d80211.

I have it too. But I'm using iwl3945 driver, in-kernel mac80211, and a
gentoo kernel (basically a patched vanilla-2.6.22.1). My machine is a
x86_64 core 2 duo.

quoted

The following triggers it on my 2way SMT machine with preempt.

modprobe bcm43xx-d80211
add sta0
ifconfig sta0 up
start wpa_supplicant on the interface
rmmod bcm43xx-d80211

After that rmmod hangs spinning and wpa_supplicant
stays in D state.

If I first kill wpa_supplicant and then rmmod the module,
it does not deadlock.

I can trigger this way:

modprobe iwl3945
ifconfig wlan0 up
start wpa_supplicant
do some wpa_supplicant work (for instance issue a scan)
stop wpa_supplicant

Then it will deadlock (that is, wpa_supplicant will refuse to be
killed). The same thing happens if I try to modprobe the module out
(modprobe will "hang spinning" as you said). I have to ultimately
hard-shutdown my machine to bring it back to normal.

It seems you are replying to a very old original message.  Since that
message was sent, linux-wireless@vger.kernel.org has become the
primary forum for wireless discussion.

Oh sorry..

Any chance you are savvy enough with git to try the wireless-dev kernel?

        git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git

Can you replicate the problem using those sources?  If so, you may
want to attach your .config in your reply (just in case the exact
config makes a difference).

Yes I can, except the "reproducibilty" reduces a bit. It's fairly easy
to reproduce though. The config will go on annex.

I've found out one interesting thing: if I modprobe -r the iwl3945
module while wpa_supplicant is running it doesn't trigger a hang like
on bcm (original message). On the contrary, it prevents a hang if then
I modprobe iwl3945 again and kill wpa_supplicant.

One time I managed to get the kernel to spit out something, but it was
on the gentoo kernel. I hope this is relevant, there was no hang when
this was spit out:

------------[ cut here ]------------
kernel BUG at kernel/workqueue.c:258!
invalid opcode: 0000 [1] SMP
CPU 1
Modules linked in:<7>wlan0: Trigger new scan to find an IBSS to join
 iwl3945 mac80211<3>iwl3945: U iwl_scan_initiate Starting scan...
 cfg80211 rfcomm l2cap snd_pcm_oss snd_mixer_oss snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device acpi_cpufreq asus_laptop
nvidia(P) i2c_core snd_hda_intel snd_pcm snd_timer snd snd_page_alloc
yenta_socket rsrc_nonstatic pcmcia_core sdhci mmc_core hci_usb
bluetooth tpm_infineon gspca
Pid: 2660, comm: iwl3945 Tainted: P       2.6.22-gentoo #1
RIP: 0010:[<ffffffff8023df87>]  [<ffffffff8023df87>] run_workqueue+0x73/0x10b
RSP: 0018:ffff8100747fded0  EFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff810074fb1d40 RCX: ffff8100748f19d0
RDX: ffff8100748f19d0 RSI: ffff8100747fdef0 RDI: ffff8100748f19c8
RBP: ffffffff880bf3a2 R08: ffff8100747fc000 R09: ffff8100740679d8
R10: 0000000000000000 R11: ffffffff8043d14e R12: ffff81007407bbd0
R13: ffffffffffffffff R14: ffffffff806445a0 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff81007ff00f40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 000000000060e788 CR3: 0000000074679000 CR4: 00000000000006e0
Process iwl3945 (pid: 2660, threadinfo ffff8100747fc000, task ffff81007f4daf60)
Stack:  ffff810074fb1d40 ffff810074fb1d40 ffffffff8023e7ff ffffffff8023e8d9
 0000000000000000 ffff81007f4daf60 ffffffff802415f0 ffff8100747fdf08
 ffff8100747fdf08 0000000000000000 ffff810074fb1d40 ffffffff802414de
Call Trace:
 [<ffffffff8023e7ff>] worker_thread+0x0/0xe4
 [<ffffffff8023e8d9>] worker_thread+0xda/0xe4
 [<ffffffff802415f0>] autoremove_wake_function+0x0/0x2e
 [<ffffffff802414de>] kthread+0x47/0x75
 [<ffffffff8020a3b8>] child_rip+0xa/0x12
 [<ffffffff80241497>] kthread+0x0/0x75
 [<ffffffff8020a3ae>] child_rip+0x0/0x12


Code: 0f 0b eb fe f0 0f ba 71 f8 00 ff d5 65 48 8b 04 25 10 00 00
RIP  [<ffffffff8023df87>] run_workqueue+0x73/0x10b
 RSP <ffff8100747fded0>

Thanks,

John
--
John W. Linville
linville@tuxdriver.com

Thank you!
  Renato Caldas