On Wed, 7 Jun 2006, Pete French wrote:
If just non-ACPI isnt sufficient, the other thing SAFE does is turn
off disk DMA. I have an as-yet unreleased system that has this
same type of issue, and the problem is that two PCI device ID's
are not recognized, so maybe that will be your problem.
So, I got around to booting the system without ACPI and there are quite
a number of 'unknown' reports at boot, viz:
unknown: <PNP0c01> can't assign resources (memory)
unknown: <PNP0303> can't assign resources (port)
unknown: <PNP0f13> can't assign resources (irq)
unknown: <PNP0501> can't assign resources (port)
unknown: <PNP0501> can't assign resources (port)
unknown: <PNP0700> can't assign resources (port)
unknown: <PNP0400> can't assign resources (port)
These are normal motherboard resources that FreeBSD reserves via other
methods. They can be safely ignored.
pciconf -l gives me 5 devices without drivers attached, these being:
[EMAIL PROTECTED]:7:2: class=0x0c0500 card=0x13101462 chip=0x746a1022 rev=0x02
hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-8111 SMBus 2.0 Controller'
class = serial bus
subclass = SMBus
You need to load a device driver to attach to this function; I believe its
called amdpm. It is only needed if you want to inquiry devices on SMBus.
[EMAIL PROTECTED]:7:3: class=0x068000 card=0x13101462 chip=0x746b1022 rev=0x05
hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-8111 ACPI System Management Controller'
class = bridge
[EMAIL PROTECTED]:10:1: class=0x080010 card=0x13101462 chip=0x74511022
rev=0x01 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-8131 PCI-X IOAPIC'
class = base peripheral
subclass = interrupt controller
[EMAIL PROTECTED]:11:1: class=0x080010 card=0x13101462 chip=0x74511022
rev=0x01 hdr=0x00
vendor = 'Advanced Micro Devices (AMD)'
device = 'AMD-8131 PCI-X IOAPIC'
class = base peripheral
subclass = interrupt controller
FreeBSD detects and attaches these through ACPI and not through the PCI
bus. In the non-ACPI case (which BTW is not exactly kosher for amd64,
since ACPI is a required part of the platform spec), IOAPICs are
enumerated and attached through MPTable.
The fact that the IOAPICs have PCI bus attachments at all is an
implementation detail. They didn't back in the Pentium Pro days.
[EMAIL PROTECTED]:6:0: class=0x030000 card=0x13101462 chip=0x47521002 rev=0x27
hdr=0x00
vendor = 'ATI Technologies Inc'
device = 'Rage XL PCI'
class = display
subclass = VGA
This usually gets grabbed either by the agp driver or by the DRM (Direct
Rendering Module) appropriate for the chip. The console uses generic VGA
register accesses and doesn't need the PCI attachment to figure that out.
If you don't run X then this is normal.
My recommendation for problems with amd64 boards:
1. Upgrade to the latest release BIOS from the vendor. This is really,
really, really important; the latest BIOS often has revised memory and bus
timings that improve compatibility. The Tyan S2892 in particular needs it
to avoid lockups if any PCI cards are installed.
2. Lockups at the SCSI detection phase are usually due to interrupt
routing issues (an interrupt gets stuck on and won't clear since we can't
figure out who's triggering it). If you have PCI cards installed try
moving them to different slots or removing them entirely. Also disconnect
any USB peripherals you may have connected.
3. You could have a defective IOAPIC, or other device, on your system
board. Very rare, but possible.
--
Doug White | FreeBSD: The Power to Serve
[EMAIL PROTECTED] | www.FreeBSD.org
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
