Sam Leffler wrote: > 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. > > 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. I did a little more debugging. Commenting out the ath_hal_setpower() call solves it (as you suggested). The interesting thing is that it doesn't hang right when that call is made (in ath_stop_locked()) or when the ATH_LOCK is dropped (in ath_stop()), but before the ath_suspend() function returns. That does seem to indicate that it is an interrupt occurring and not some other kernel subsystem accessing its config registers. I'll look at the irq handler next. Shouldn't a flag be set before returning from ath_stop() that says "ignore interrupts without touching hw"? Perhaps sc->sc_invalid? -- NateReceived on Sat Jul 15 2006 - 19:57:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC