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... _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
