On Tue, 30 Oct 2007, Randy wrote
> On Tue, 30 Oct 2007, Juergen Keil wrote:
>
> >
> > It probably wasn't fully suspended in S3, it seems.
> > It might have been hanging after (or while) detaching the ohci driver.
> > So I added ohci to the list of drivers not to load. That got me to the dnet
> > driver not supporting suspend.
>
> ohci had been problamatic even on the U20. If someone can file a bug
> that it wasn't allowing power-off, maybe it can get fixed.
One strange thing I just observed with ohci:
The USB 2.0 card I'm using here has three ohci pci functions.
Two of them (ohci#1 and ohci#2) share one pci interrupt line,
both end up on the cpu's irq#10 vector.
When trying to S3-STR the box, ohci#1 gets suspended first;
during ohci_detach(dip = "ohci#1", DDI_SUSPEND) the interrupt handler
is *not* removed, but interrupts are disable in the hardware
and ohci#1 should be shut down at this point.
Now the next time we get an interrupt on irq#10 (most likely because
the instance ohci#2 is still active and enabled), the interrupt handlers
for both devices sharing the interrupt line (ohci#1 and ohci#2) are called.
ohci_intr() for device instance #2 is accessing the hardware's registers
of the *suspended* ohci controller, and for this reason the cpu reads
0xffffffff values on the x86 platform. The ohci drivers thinks the device
has just received all sort of strange overflow and error interrupts,
when in fact the device is just in suspended state:
uts/common/io/usb/hcd/openhci/ohci.c, line 7695:
* Now read the Interrupt Status & Interrupt enable register
* to determine the exact interrupt events.
*/
intr = ohci_intr_sts->ohci_curr_intr_sts =
(Get_OpReg(hcr_intr_status) & Get_OpReg(hcr_intr_enable));
The above reads hcr_intr_status 0xffffffff and hcr_intr_enable 0xffffffff,
so we have 32 different enabled interrupt sources, and all 32 fired at
once 8-)
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?
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
