On Tuesday 10 November 2009 17:55:34 Guido Trentalancia wrote: > Dear Michael, > > I got the following oops while using the b43 driver from the > compat-wireless-2.6.32-rc6 package: > > BUG: scheduling while atomic: compirq/10-b43/1779/0x00000100 > Modules linked in: ip6t_REJECT nf_conntrack_ipv6 ip6table_filter > ip6_tables aes_i586 aes_generic ipt_MASQUERADE iptable_nat nf_nat sunrpc > ipv6 dm_multipath uinput arc4 ecb crypto_blkcipher b43 rng_core mac80211 > cfg80211 rfkill_backport ssb ppdev snd_cs4281 snd_rawmidi snd_ac97_codec > ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq > snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_opl3_lib > snd_seq_device snd_timer snd_hwdep pcspkr i2c_piix4 snd soundcore > i2c_core ftdi_sio usbserial rtl8150 parport_pc parport yenta_socket > rsrc_nonstatic ata_generic pata_acpi [last unloaded: microcode] > Pid: 1779, comm: compirq/10-b43 Not tainted 2.6.27.26-gt #1 > [<c0722efd>] ? printk+0x18/0x1b > [<c042639d>] __schedule_bug+0x7d/0x90 > [<c072354d>] schedule+0x46d/0x4a0 > [<c0423131>] ? __wake_up+0x81/0x90 > [<c0723e4b>] __mutex_lock_slowpath+0x5b/0x90 > [<cca09900>] ? b43_op_beacon_set_tim+0x0/0x40 [b43] > [<c0723ce6>] mutex_lock+0x16/0x20 > [<cca0991a>] b43_op_beacon_set_tim+0x1a/0x40 [b43] > [<cc9d5317>] __sta_info_clear_tim_bit+0x57/0x70 [mac80211] > [<cc9d536f>] sta_info_clear_tim_bit+0x3f/0x80 [mac80211] > [<cc9e5055>] ieee80211_invoke_rx_handlers+0xe35/0x2000 [mac80211] > [<c054f8bb>] ? rb_insert_color+0xdb/0x110 > [<c0423f8e>] ? enqueue_entity+0xde/0x350 > [<c0403f73>] ? restore_nocheck_notrace+0x0/0xe > [<c0424665>] ? check_preempt_wakeup+0x165/0x280 > [<cc9e3a6a>] ? prepare_for_handlers+0x2a/0x380 [mac80211] > [<cc9e6442>] __ieee80211_rx_handle_packet+0x222/0x360 [mac80211] > [<cc9e69e8>] ieee80211_rx+0x188/0x6e0 [mac80211] > [<cca1db37>] b43_rx+0x3a7/0x680 [b43] > [<cca229a7>] ? setup_rx_descbuffer+0x37/0x260 [b43] > [<cca23f58>] b43_dma_rx+0x248/0x3b0 [b43] > [<cca2258c>] ? b43_dma_handle_txstatus+0x16c/0x3c0 [b43] > [<c0403f73>] ? restore_nocheck_notrace+0x0/0xe > [<cca0d3a8>] b43_do_interrupt_thread+0x4b8/0x960 [b43] > [<c0423aa4>] ? dequeue_entity+0x14/0x170 > [<cca0d868>] b43_interrupt_thread_handler+0x18/0x30 [b43] > [<cca0900f>] compat_irq_work+0xf/0x20 [b43] > [<c043d2ad>] run_workqueue+0x7d/0x140 > [<cca09000>] ? compat_irq_work+0x0/0x20 [b43] > [<c043d70f>] worker_thread+0x7f/0xe0 > [<c0440da0>] ? autoremove_wake_function+0x0/0x40 > [<c043d690>] ? worker_thread+0x0/0xe0 > [<c0440b1a>] kthread+0x3a/0x70 > [<c0440ae0>] ? kthread+0x0/0x70 > [<c0404a93>] kernel_thread_helper+0x7/0x14 > ======================= > > It appears that the driver wants to lock a mutex in interrupt context. > As far as I know, code executing in interrupt context cannot acquire a > mutex and therefore a spinlock should be used. > > If irqs are enabled spin_lock_irqsave() should be used instead of > spin_lock() and anyway, it is always safer to use spin_lock_irqsave().
The patch is wrong. We cannot simply replace the lock by an unrelated one and hope that it magically works. However, a workaround for this problem has already been sent upstream. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
