#456: spinlock lockup in AP mode, revisions 1408 to 1468 and more
-----------------------------------+----------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: madwifi: other | Version:
Resolution: | Keywords:
Patch_attached: 0 |
-----------------------------------+----------------------------------------
Comment (by [EMAIL PROTECTED]):
So, is this happening to anybody else ?
I was reading up on spinlocks here:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-
locking/index.html
Looks to me like
ath_rx_tasklet is a softirq
and
ath_intr is a hardirq
Here's what I have found them to do:
ath_rx_tasklet
calls ieee80211_find_rxnode <-- lock_bh/unlock_bh on node_table
calls ieee80211_input_all
calls ieee80211_input <-- lock_bh/unlock_bh on node_table
calls ieee80211_free_node <-- lock_bh/unlock_bh on ic_comlock and
node_table
ath_intr
calls ath_beacon_send
calls ath_beacon_generate
calls ieee80211_beacon_update <-- lock_irqsave on ic_comlock
--- LOCKUPs here (??)
I think because the softirq doesn't disable the hardirq, we get into a
case where we're already holding a lock ?
I am currently running a version that changes the calls of
IEEE80211_LOCK/IEEE80211_UNLOCK to spin_lock_irq()/spin_unlock_irq() which
hasn't crashed on me yet (1741 secs into the iperf data transfer, where
normally it would've crashed at around 800 secs)
No patches for this yet, I want to make sure its rock solid.
And, I'm sure there's going to be some timing performance hits with the
changed calls.
Any comments ?
--
Ticket URL: <http://madwifi.org/ticket/456>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
