HEADS UP: PCI Chnages

Vladimir Egorin vladimir at math.uic.edu
Fri Apr 9 15:07:01 PDT 2004


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


More information about the freebsd-current mailing list