Nate Lawson wrote: > I've seen a recent regression in the past few months when suspending my > laptop. When I have an ath0 card inserted in a cardbus slot and then > press the sleep button, the system hangs. If I eject the card, it > continues going into suspend and everything works as normal. > > If the card is up (ifconfig up), this process hangs. If it's down, no > hang and it suspends normally. I did some debugging by starting the > suspend, waiting for the hang, hitting "break to ddb", and then ejecting > the card. The eject causes an interrupt which causes ddb to be entered. > With ps, I can see that the thread on the acpi_taskq is running the > button event and then calling bus_generic_suspend(), which eventually > calls cbb_detach(), which then calls a power routine in pccbb.c. This > routine calls tsleep() (wchan "cbbP3") which never wakes up. > > Any idea why tsleep() is not waking up now? It seems tsleep() calls > mi_switch() and never returns. > A more likely scenario is that ath_stop is putting the card into "deep sleep". At that point you cannot touch any of the PCI domain registers for the card w/o bringing it out of sleep. If you do then the pci/cardbus will hang. Ejecting the card removes the device from the bus and allows things to continue. I walked through this scenario with Ed Maste when he mentioned it to me and we tried to catch ath being entered after it set the card to sleep but failed. Note that something as simple as checking for ath_intrpend at the top of ath_intr can cause this but after shuffling code to ensure this does not occur we still couldn't catch what was going on. My suggestion is you work under the above assumption and try to catch entry to the ath driver. I still think the problem is a shared irq interrupting after ath_stop puts the card to sleep. SamReceived on Wed Jul 12 2006 - 23:32:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC