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
