Dual Opteron system will not run SMP

Doug White dwhite at gumbysoft.com
Fri Jun 9 21:50:33 UTC 2006


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:
>
> none0 at pci0: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.

> none1 at pci0: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
> none2 at pci0: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
> none3 at pci0: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.

> none4 at pci3: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
dwhite at gumbysoft.com          |  www.FreeBSD.org


More information about the freebsd-stable mailing list