Date: Fri, 9 Apr 2004 17:06:56 -0500 From: Vladimir Egorin <vladimir@math.uic.edu> To: "M. Warner Losh" <imp@bsdimp.com> Cc: current@freebsd.org Subject: Re: HEADS UP: PCI Chnages Message-ID: <20040409220656.GA1993@math.uic.edu> In-Reply-To: <20040409.095635.32718566.imp@bsdimp.com> References: <20040409.095635.32718566.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 09, 2004 at 09:56:35AM -0600, M. Warner Losh wrote: > I just committed some rather extensive changes to the pci bus layer. > These changes should help people that need better suspend/resume > support, better resource allocation and resource collision avoidance. > > There's only one known issue with this code, which I'll address > shortly. If you detach a pci device, the BARs are still live, so > there can be interference. > > I'm especially interested in people who have no pci bridges in them, > but whose BIOSes don't assign resources correctly and don't have > ACPI. > > Let me know how well/poorly this works. Thanks > > Warner > > P.S. commit message > > imp 2004/04/09 08:44:34 PDT > > FreeBSD src repository > > Modified files: > sys/dev/pci pci.c pci_pci.c pci_private.h > sys/dev/acpica acpi_pci.c acpi_pcib_acpi.c > Log: > Omnibus PCI commit: > o Save and restore bars for suspend/resume as well as for D3->D0 > transitions. > o preallocate resources that the PCI devices use to avoid resource > conflicts > o lazy allocation of resources not allocated by the BIOS. > o set unattached drivers to state D3. Set power state to D0 > before probe/attach. Right now there's two special cases > for this (display and memory devices) that need work in other > areas of the tree. > > Please report any bugs to me. > > Revision Changes Path > 1.11 +2 -2 src/sys/dev/acpica/acpi_pci.c > 1.31 +22 -1 src/sys/dev/acpica/acpi_pcib_acpi.c > 1.238 +294 -58 src/sys/dev/pci/pci.c > 1.31 +2 -2 src/sys/dev/pci/pci_pci.c > 1.12 +2 -0 src/sys/dev/pci/pci_private.h I hoped to get ACPI suspend/resume working on a machine with ASUS P4B533 motherboard. Until today, the machine would resume from a suspend for a couple of seconds, but then lock up or go into debugger if it is enabled in the kernel. After today's build, it doesn't come back at all -- video stays off, and no reaction to the keyboard. What can I do to help with debugging this problem? -- Vladimir
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040409220656.GA1993>