Juergen Keil wrote: > Pawel Wojcik wrote: >> Dan Mick wrote: >>> Juergen Keil wrote: >>>> How is a driver supposed to behave in such a case, when it has sucessfully >>>> suspended the device but the interrupt handler is still invoked because it >>>> is sharing the interrupt with some other device that is not yet suspended? >>>> >>>> Shouldn't ohci set some flag in its softstate when ohci_detach(DDI_SUSPEND) >>>> has run, and just return with DDI_INTR_UNCLAIMED from ohci_intr() when >>>> ohci_intr is invoked for such a suspended device? >>> Certainly return without doing damage, yes, and DDI_INTR_UNCLAIMED seems >>> like the best possible way... >>> >>> I'm surprised suspendable drivers don't do this as a matter of course. >> If there is no one actually handling the interrupt, i.e. clearing the >> interrupt on the hardware that is asserting it, wouldn't it cause an >> endless invocation of the interrupt? > > Apparently that is happening on my ASUS P2B-LS box with an ALI USB 2.0 card > when I try to enter S3 suspend-to-ram state. After one pci instance of the > ohci hardware is suspended, the machine is in a loop calling ohci_intr() and > seems to make no more progress. > > But I think the loop is uts/common/io/avintr.c av_dispatch_autovect(), because > we're calling the interrupt handler for the suspended ohci device and this one > always returns "DDI_INTR_CLAIMED", so at the end of loop we should have > "numcalled == 2" (two interrupt handlers still installed) and "claimed != 0", > so it runs through the autovect[vec].avh_link list over and over again...
No one should be returning "CLAIMED" unless they've handled a source of the interrupt. _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
