Joseph Jezak wrote:
Can you provide the details to the list? I'll look into getting
SoftMAC fixed if you do.
sure
the basic issue is that bcm43xx does it's rx processing in a softirq, and
holds the bcm->irq_lock during that time. The rx processing calls into the
softmac layer, which in turn calls into netlink.
With this you can get a deadlock that looks like this
cpu 0: user context |cpu1: softirq context
netlink_table_grab takes nl_table_lock as |take bcm->irq_lock in
write_lock_bh, but leaves irqs enabled |bcm43xx_interrupt_tasklet()
|which then in a few steps
|leads to a call to
|bcm43xx_rx
hardirq comes in and the isr tries to take |in bcm43xx_rx, call
bcm->irq_lock but has to wait on cpu 1 |ieee80211_rx_mgt which
|leads to a call to
|wireless_send_event which
|tries to take nl_table_lock
|for read but has to wait
|for cpu0
according to Michael Buesch, the softmac layer should queue the packet
internally for another softirq, similar to what DeviceScape does, so that
the rx softirq can just drop all packets quickly and drop its locks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
