Hi Adrian, On Thu, Sep 29, 2011 at 06:33:42PM +0800, Adrian Chadd wrote: > > Has someone figured out which ISR bits are being triggered? No. I tried to move the SC_OP_INVALID check until after the call to ath9k_hw_getisr in ath_isr. But that caused the kernel to freeze IIRC. What I also tried and failed to do a hardware reset before request_irq gets called. For ath9k_hw_reset I need an initialized ath_hw struct, but that's done after request_irq in ath9k_init_device. I remember I tried to delay request_irq, but for some reason that did not work out either. > If not, I can likely whip up a patch which adds some relevant > printk's. I think it's worth establishing: > > * is it a sync/async interrupt; > * is it a fatal interrupt (eg something like a PCI bus error or > transaction timeout) or is it a normal ISR bit that keeps firing; > * .. and which one is firing. If you have an idea how to do this, I think that would be most helpful. Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
