Juergen Keil wrote:
> 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.
>
Interesting.
>
> I also had to disable the uhci driver with "-B disable-uhci=true", that
> was the next driver not implementing suspend.
>
Yes, we know about that. I'll be working it later this week.
>
> 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?
>
Hmm... the uadmin 3 20 test point probably was intended to have a timer
set somewhere... Randy is the expert on that code, and he's not online
today.
I wonder if a uadmin 3 8 would actually go all the way to S3. I confess
while I was the one to setup the project, I have not actually tested it
myself on x86 (SPARC of course I have). I'll be working on this a bit
more later this week. (I wanted to hit a milestone on my SDcard drivers
first.)
-- Garrett
>
>
>> 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
