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.
>
> Now that I have disabled both dnet and ohci, system suspends, and I can
> wake it up from suspend entered via "uadmin 3 20" using the ps/2 keyboard.
Cool!!!
I see that you also found out about the vgatext_force_suspend. Does
your display come back if you use this? Are you aware of a
BIOS/ACPI/SMBIOS function that can be used to see if the hardware will
re-POST on S3 resume?
>
>
>> 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.
Reading through some of the email, only shows how little information we
were getting about PCI and IDE device interaction upon suspend. It looks
as if pci-ide should either not be using the parent ctlops definition on
suspend, or there should be better parent facilities. We may want to
raise this awareness with the PCI team in Los Angeles (Garrett- if you
get a chance, give Jimmy.V a call and see if he can shed more light based
on Juergen's research).
<snip>
>>>>>
>>>>> So far I had to:
>>>>>
>>>>> - add a line "S3-support enable" to /etc/power.conf
So I had thought I sent an email with some descriptions of items that
can/should be set, but this is one of them. I highly suggest also
adding/changing 'autopm disable' as well, as some drivers don't autopm
well yet (and ata is one of them).
>>>>>
>>>>> - 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
The problem with setting this variable, is that the vgatext driver knows
nothing about getting the framebuffer back online. If the laptop/computer
does a re-POST on S3 resume, this is OK, otherwise you come up to a blank
screen (what happends on the Ferrari 3400). But this is good for driver
testing, using serial consoles, or suspending via 'uadmin 3 22' (which
doesn't actually power off the machine), or in the case as mentioned
before, a BIOS that will re-POST on resume.
>>>>>
>>>>> 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:
This does explain a bit more, and it does seem like the pci-ide driver
needs some updating. As I don't know the IDE devices that well (or the
PCI bus spec, for that matter), should we be rethinking how the
ide/ata/nvsata devices deal with their space?
>>>>>
>>>>> 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);
>>>>> }
>>>>> ...
>>>>> }
I think there is an outstanding bug for this loop as well. Jimmy.V had
a fix for us, but it made the problem worse (and there are several places
in the kernel where we do the capabilitiy scan, instead of a single macro
or function).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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?
This was intentional, but from the sounds of it, misguided.
---- Randy
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
