Failure to get past a PCI bridge

[John Baldwin]

On Thursday 04 June 2009 10:16:29 am Josef Moellers wrote:
> John Baldwin wrote:
> > On Tuesday 02 June 2009 3:19:54 am Josef Moellers wrote:
> >   
> >> Hi,
> >>
> >> (I've posted this to freebsd-questions before. Ian Smith redirected me 
> >> to this list).
> >>
> >> I'm trying to install 7.2-RELEASE on a pretty new system (a Fujitsu 
> >> RX300S5).
> >> The first obstacle was the fact that while the system has an 
> >> AT-Keyboard-Controller, it ist not used (keyboard and mouse are 
> >> connected via USB) and I have found that I can get past that by 
specifying
> >>
> >> set hint.atkbd.0.disabled=1
> >> set hint.atkbdc.0.disabled=1
> >>
> >> The install kernel then boots properly and reaches the "Country 
Selection".
> >> At that point, no keyboard input is accepted. An optical mouse is off, 
> >> so I assume the USB power to be off.
> >>
> >> I have hooked up a serial connection to log the kernel's output (some 
> >> 1000+ lines):
> >>
> >> set boot_serial=1
> >> set boot_verbose=1
> >> set boot_multicons=1
> >> set console="comconsole vidconsole"
> >>
> >> The following lines make me wonder if the kernel fails to get past PCI 
> >> bridges and thus can't reach the UHCI controllers:
> >>
> >> pcib0: <ACPI Host-PCI bridge> on acpi0
> >> pcib0: could not get PCI interrupt routing table for \_SB_.CPU0 - 
> >> AE_NOT_FOUND
> >> :
> >> pcib1: <ACPI Host-PCI bridge> on acpi0
> >> pcib1: could not get PCI interrupt routing table for \_SB_.CPU1 - 
> >> AE_NOT_FOUND
> >> :
> >> pcib2: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> >> pcib2: couldn't find _ADR
> >> pcib2: trying bus number 2
> >> pci2: <ACPI PCI bus> on pcib2
> >> pci2: domain=0, physical bus=2
> >>
> >> I talked to the guy who does the BIOS for the machine and he says that 
> >> it makes no sense for the kernel to try and find the _PRT for \_SB_.CPU0 
> >> or \_SB_.CPU1!
> >>     
> >
> > Can you get an acpidump?  It seems that the BIOS has the wrong _HID for 
the 
> > CPU objects and has marked them as Host-PCI bridges instead.  Although 
CPUs 
> > should be Processor objects and not Device objects anyway.  Sounds like a 
> > very busted BIOS.
> >   
> Does this help?

Hmm, not quite.  Can you do 'acpidump -d -t > foo' instead?

-- 
John Baldwin