Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Jul 2009 12:51:33 -0400
From:      Jesse Kempf <jkempf@davisvision.com>
To:        freebsd-acpi@freebsd.org
Subject:   SunFire x4275
Message-ID:  <17574_1247071910_4A54CEA6_17574_42_1_4A54CE95.4090503@davisvision.com>

next in thread | raw e-mail | index | archive | help
Hi,
We recently got in a SunFire x4275, one of Sun's new Nehalem boxes. The 
full server architecture whitepaper is here: 
https://www.sun.com/offers/details/X4x70_server_architecture.html 
(requires registration).

The upshot of the system is that there are a pair of "intelligent" 
risers in the machine, which take a x8 PCIe link and mux it to a pair of 
x8 PCIe links. Sun uses the IDT PES24T6G2 PCIe switch to do the muxing.

FreeBSD, when it boots, can't see past the risers. This holds for both 
7.2p1 and 8-CURRENT. It can see the IDT PCIe switches, and if a PCIe 
card is moved off the intelligent riser, to the one dumb riser in the 
machine, the card can be seen. Interestingly, when I boot FreeBSD with 
ACPI turned off, all the devices past the risers can be seen, but device 
attachment fails spectacularly.

I've tried setting debug.acpi.disabled for individual subsystems that 
make sense, and have not been able to come up with a combination that 
allows the system to boot as well as see past the risers. From what I 
understand, this is not too surprising.

When I say "can't see past the risers", I mean:

pcib9: <ACPI PCI-PCI bridge> at device 0.0 on pci25
pcib9:   domain            0
pcib9:   secondary bus     26
pcib9:   subordinate bus   38
pcib9:   I/O decode        0x8000-0x9fff
pcib9:   memory decode     0xfaa00000-0xfabfffff
pcib9:   no prefetched decode
device_attach: pcib9 attach returned 6

is what the kernel spits out when I do a verbose boot. None of the PCI 
buses past the riser are enumerated. I dumped the ACPI AML block and 
decompiled it. The only errors that iasl spit out when I recompiled it 
was use of the reserved variables '_T_0' and '_T_1'. Switching them to 
'LOL0' and 'LOL1', recompiling, and telling the loader where to find the 
new blob did not help.

I am, at this point, at a loss for what to do next.

Here's the dmesg from the verbose boot:
http://www.cs.rpi.edu/~kempfj2/x4275.dmesg (GENERIC-DMESG simply ups the 
kernel message buffer to 100 pages from 10 so that I could capture 
everything into /var/run/boot.dmesg).

The ASL:
http://www.cs.rpi.edu/~kempfj2/x4275.asl

And pciconf -vl:
http://www.cs.rpi.edu/~kempfj2/x4275pci.txt

sysctl hw.acpi:
http://www.cs.rpi.edu/~kempfj2/x4275hw.acpi

Boot -v with ACPI disabled explodes on discovering igb0 with a page 
fault in kernel mode:
http://www.cs.rpi.edu/~kempfj2/x4275.verbose-noacpi

And this is a non-verbose boot with acpi disabled:
http://www.cs.rpi.edu/~kempfj2/x4275.noacpi


What's the next step in debugging this, and how can I be of assistance?

Thanks,
-Jesse Kempf



------------------------------------------------------------------------
The information contained in this communication is intended
only for the use of the recipient(s) named above. It may
contain information that is privileged or confidential, and
may be protected by State and/or Federal Regulations. If
the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,
distribution, or copying of this communication, or any of
its contents, is strictly prohibited. If you have received
this communication in error, please return it to the sender
immediately and delete the original message and any copy
of it from your computer system. If you have any questions
concerning this message, please contact the sender.
------------------------------------------------------------------------




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17574_1247071910_4A54CEA6_17574_42_1_4A54CE95.4090503>