Ok, returning with DDI_SUCCESS when usr/src/uts/common/io/pci-ide/pci-ide.c
pciide_ddi_ctlops() is called with DDI_CTLOPS_ATTACH/DDI_CTLOPS_DETACH
avoids the endless loop / hang.
I also had to disable the uhci driver with "-B disable-uhci=true", that
was the next driver not implementing suspend.
With these changes the P2B-LS might be able to switch to suspended state
now; it writes "Saving system state. Please wait..." and spins down the hdd.
I can't break into kmdb any more, though. The PS/2 keyboard seems to be
powered off, too. But the box is still powered on. Question is: how
do we wake up the box from suspended state?
> You may be hitting a known bug.
>
> Certainly, it doesn't seem that in the CTLOPS_DETACH ata should be doing
> PCI suspend.
>
> Probably it shouldn't be passing this up to the parent. I need to
> investigate further.
>
> - Garrett
>
> Juergen Keil wrote:
> > Garrett wrote:
> >
> >
> >> Device power management is a bit different... it uses the power(9e)
> >> entry point.
> >>
> >> However, there are test entry points in the suspend/resume framework
> >> that let you test drivers for suspend/resume functionality. One of them
> >> is uadmin 3 20, the others are uadmin 3 25 and uadmin 3 8.
> >>
> >> The uadmin 3 8 works today on SPARC desktops (and has since Solaris 8.)
> >>
> >> The other two are new, and may require setting up some debug variables.
> >> Maybe Randy or Jay can provide some assistance here.
> >>
> >> (The differences in these are,
> >>
> >> uadmin 3 8 does a real suspend followed by a real resume
> >> uadmin 3 20 does a test suspend, but doesn't actually do the suspend...
> >> it only exercises driver entry points.
> >> uadmin 3 25 does a test suspend to ram, followed by a resume
> >>
> >
> >
> > I started to experiment with suspending an old Pentium-II box (ASUS P2B-LS).
> >
> > So far I had to:
> >
> > - add a line "S3-support enable" to /etc/power.conf
> >
> > - boot kernel with option "-B disable-fdc=true", so avoid using the
> > PS/2 floppy controller driver (which doesn't support suspend/resume
> > at this time)
> >
> > - patch "vgatext_force_suspend/W 1", otherwise the vgatext driver refuses to
> > suspend; and that would prevent the suspend operation
> >
> >
> >
> >
> >
> > An "uadmin 3 20" starts a suspend, but it hangs in an endless loop
> > inside pci_save_config_regs(dip = "ata#0"). That seems to be bug
> > 6533720 (system hung after print out "pci_save_config_regs ata:2").
> >
> > In my case this is called during a devi_detach(dip = "ata#0", DDI_SUSPEND);
> > pciide_ddi_ctlops(dip = "pci-ide#0", rdip = "ata#0", DDI_CTLOPS_DETACH)
doesn't
> > handle the DDI_CTLOPS_DETACH command and passes it up to the parent device
> > pci_ctlops(dip = "pci#0", rdip = "ata#0", DDI_CTLOPS_DETACH), and
> > from there we call pci_post_suspend(rdip = "ata#0").
> >
> >
> > The ata driver node isn't a PCI device, and when we call
> > pci_save_config_regs(dip = "ata#0") from pci_post_suspend(dip = "ata#0")
> > for a non-pci device, all sort of strange things happen. Instead of
> > accessing pci configuration space, pci_save_config_regs() is accessing
> > random I/O ports (0x1f0 + offset), reads back 0xff values, which ends
> > with an endless loop in usr/src/uts/common/os/sunpci.c:
> >
> > pci_save_config_regs(dev_info_t *dip)
> > {
> > ...
> > /*
> > * Determine if it is a pci express device. If it is, save entire
> > * 4k config space treating it as a array of 32 bit integers.
> > * If it is not, do it in a usual PCI way.
> > */
> > cap_ptr = pci_config_get8(confhdl, PCI_BCNF_CAP_PTR);
> > /*
> > * Walk the capabilities searching for pci express capability
> > */
> > while (cap_ptr != PCI_CAP_NEXT_PTR_NULL) {
> > cap_id = pci_config_get8(confhdl,
> > cap_ptr + PCI_CAP_ID);
> > if (cap_id == PCI_CAP_ID_PCI_E) {
> > pcie = 1;
> > break;
> > }
> > cap_ptr = pci_config_get8(confhdl,
> > cap_ptr + PCI_CAP_NEXT_PTR);
> > }
> > ...
> > }
> >
> >
> >
> >
> > Who's fault is this? Is it ok that usr/src/uts/common/io/pci-ide/pci-ide.c
> > pciide_ddi_ctlops() doesn't handle DDI_CTLOPS_DETACH, and passes it to the
> > standard ddi_ctlops() function which forwards the detach op to the parent
> > device node?
> >
> > _______________________________________________
> > driver-discuss mailing list
> > [email protected]
> > http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
