Skip to contentSkip to conversation

System pauses with iwl3945 AP associate. RFKill unpauses.

DISCUSSION Robin Holt 1 participant 1 message Oct 3, 2008 5 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

Robin Holt

author
#5 lore raw
Quoted 3 lines · Robin Holt

OK. I think I have convinced myself this is an issue with sta_info_debugfs_add_work(). I am going to turn off CONFIG_MAC80211_DEBUGFS and see if that makes things better.

Appear to be on the right track here. With CONFIG_MAC80211_DEBUGFS=y, I could only suspend/resume approx 4 times without iwl3945 hanging. I had worked around that by modprobe -r iwl3945 and waiting a while before suspending. Now with CONFIG_MAC80211_DEBUGFS=n, I have done 6 suspends with the machine suspended for 5 minutes before resuming and it has not hung. That has not occurred before. I will continue to test this for the next few days.

Thanks,
Robin

Quoted 38 lines

Thanks,
Robin

Quoted 33 lines · Robin Holt
Quoted 4 lines · Robin Holt

I do have KDB installed as well and one other thing I noticed is we are adding work to a workqueue at the time of the hang. Not sure if this is accurate and I forgot that I only have a VGA console so there is no record of the KDB output.

OK. In KDB. Here goes...

events/0 process is on cpu0 with the following stack.

_spin_unlock_irqrestore+0x10
[mac80211]sta_info_debugfs_add_work+0x82
run_workqueue+0xd4
worker_thread+0x88
kthread+0x42

I few times later, I got:
_cond_resched+0x10
[mac80211]sta_info_destroy+0x10
[mac80211]sta_info_debugfs_add_work+0xee
run_workqueue+0xd4
worker_thread+0x88
kthread+0x42

I am transposing these from screen to this email so I reserve the right to be slightly off, but these appear to be the call traces.

It looks to me like this add_work loop is truly an infinite loop and preventing interrupts from being processed on cpu0.

Thanks,
Robin