pci buses missing from suspend/resume powerstate
I've been looking at why some devices do not work after ACPI suspend/resume sequence on a laptop here, and have discovered that two of the system's four PCI buses are not being powered down and up again during the ACPI suspend/resume sequence. This is, I'm guessing, why the devices on those buses no longer work after the resume. Devices on the other PCI buses that are being powered down/up do work OK after the resume. Why would entire PCI buses be omitted from the: acpi_pci_set_powerstate_method power down/up sequence? Laptop has device tree: nexus0 ram0 cryptosoft0 apic0 acpi0 cpu0 hwpstate0 acpi_perf0 cpufreq0 cpu1 acpi_perf1 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 scpm0 acpi_video0 drm0 hdac1 pcm2 pcib2 pci2 ath0 pcib3 pci3 re0 miibus0 rgephy0 If I instrument acpi_pci_set_powerstate_method, it is being called on the suspend/resume for pci0 and pci1 but NOT for pci2 or pci3. After the resume, devices ath0 and re0 no longer work. Any thoughts? Lots more info (devinfo, dmesg, dsdt, verbose boot, pciconf, etc) here: http://opal.com/jr/toshiba_l675d/ -jr ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: pci buses missing from suspend/resume powerstate
On Sat, 2 Apr 2011 11:29:58 -0400, J.R. Oldroyd f...@opal.com wrote: [suspend/resume of network cards] pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 scpm0 acpi_video0 drm0 hdac1 pcm2 pcib2 pci2 ath0 pcib3 pci3 re0 miibus0 rgephy0 ... I had been working from this: on suspend: kernel: pci0:1:5:0: Transition from D0 to D3# vgapci kernel: pci0:1:5:1: Transition from D0 to D3# hdac1 kernel: pci0:2:0:0: Transition from D0 to D3# ath0 kernel: pci0:3:0:0: Transition from D0 to D3# re0 kernel: pci0:0:18:2: Transition from D0 to D3 # ohci0 kernel: pci0:0:19:2: Transition from D0 to D3 # ohci1 kernel: pci0:0:20:2: Transition from D0 to D3 # hdac0 but on resume, only: kernel: pci0:0:18:2: Transition from D3 to D0 kernel: pci0:0:19:2: Transition from D3 to D0 which had led me to think the buses were not being resumed. Looking further at this, two things come to light: - they ARE being suspended using set_powerstate to D3, but after the resume, their powerstate still shows as D0, so set_powerstate is not being re-invoked to actually set D0 again - the PCI-PCI bridges pcib1, pcib2, pcib3 have hdrtype==1 and so are also excluded from the set_powerstate (don't know if that's OK or not) But, overriding those checks and forcing set_powerstate D0 to be invoked for all devices still doesn't get ath0 or re0 working after the resume. I have an older but similar laptop model with the same configuration of ath0 and re0 also on secondary PCI buses pci2 and pci3 and that one does suspend/resume properly. But on the newer laptop: kernel: ath0: unable to reset hardware; hal status 3 kernel: re0: reset never completed! kernel: re0: PHY write failed last message repeated 4 times So this problem is specific to this newer hardware. Perhaps related to the PCI-PCI bridges? pcib2 and pcib3 are both devid=96xx1022... perhaps some odd quirk handling is needed here? -jr ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: pci buses missing from suspend/resume powerstate
On 4/2/2011 2:34 PM, J.R. Oldroyd wrote: On Sat, 2 Apr 2011 11:29:58 -0400, J.R. Oldroyd f...@opal.com wrote: [suspend/resume of network cards] pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 scpm0 acpi_video0 drm0 hdac1 pcm2 pcib2 pci2 ath0 pcib3 pci3 re0 miibus0 rgephy0 ... I had been working from this: on suspend: kernel: pci0:1:5:0: Transition from D0 to D3 # vgapci kernel: pci0:1:5:1: Transition from D0 to D3 # hdac1 kernel: pci0:2:0:0: Transition from D0 to D3 # ath0 kernel: pci0:3:0:0: Transition from D0 to D3 # re0 kernel: pci0:0:18:2: Transition from D0 to D3 # ohci0 kernel: pci0:0:19:2: Transition from D0 to D3 # ohci1 kernel: pci0:0:20:2: Transition from D0 to D3 # hdac0 but on resume, only: kernel: pci0:0:18:2: Transition from D3 to D0 kernel: pci0:0:19:2: Transition from D3 to D0 which had led me to think the buses were not being resumed. Looking further at this, two things come to light: - they ARE being suspended using set_powerstate to D3, but after the resume, their powerstate still shows as D0, so set_powerstate is not being re-invoked to actually set D0 again - the PCI-PCI bridges pcib1, pcib2, pcib3 have hdrtype==1 and so are also excluded from the set_powerstate (don't know if that's OK or not) But, overriding those checks and forcing set_powerstate D0 to be invoked for all devices still doesn't get ath0 or re0 working after the resume. I have an older but similar laptop model with the same configuration of ath0 and re0 also on secondary PCI buses pci2 and pci3 and that one does suspend/resume properly. But on the newer laptop: kernel: ath0: unable to reset hardware; hal status 3 kernel: re0: reset never completed! kernel: re0: PHY write failed last message repeated 4 times So this problem is specific to this newer hardware. Perhaps related to the PCI-PCI bridges? pcib2 and pcib3 are both devid=96xx1022... perhaps some odd quirk handling is needed here? I suspect something in the ASL is different. -- Nate ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: pci buses missing from suspend/resume powerstate
On Sat, 02 Apr 2011 17:39:30 -0700, Nate Lawson n...@root.org wrote: I suspect something in the ASL is different. The L305D suspends/resumes fine and all devices work after. On the L675D, ath0 and re0 are dead after resume. ASLs: http://opal.com/jr/toshiba_l305d/toshiba_l305d.dsdt http://opal.com/jr/toshiba_l305d/toshiba_l305d.devinfo pci0/pcib3/pci3/re0 pci0/pcib4/pci4/ath0 http://opal.com/jr/toshiba_l675d/toshiba_l675d.dsdt http://opal.com/jr/toshiba_l675d/toshiba_l675d.devinfo pci0/pcib2/pci2/ath0 pci0/pcib3/pci3/re0 -jr ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
