Failure to get past a PCI bridge

[Josef Moellers]

John Baldwin wrote:
> On Monday 08 June 2009 4:09:11 am Josef Moellers wrote:
>   
>> 'morning,
>>
>> John Baldwin wrote:
>>     
>>> On Friday 05 June 2009 10:51:44 am Josef Moellers wrote:
>>>   
>>>       
>>>> Hello,
>>>>
>>>> Thanks for the help!
>>>>
>>>> John Baldwin wrote:
>>>>     
>>>>         
>>>>> On Friday 05 June 2009 5:17:25 am Josef Moellers wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Difficult, since I can't boot properly.
>>>>>> However, I have managed to get the dsdt using a SuSE Linux and have run 
>>>>>> that through acpidump -d on a 7.2 running on a XEN virtual machine. 
>>>>>> Here's the result.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Hmm, your BIOS is certainly hosed.  First, it does have separate 
>>>>>           
> processor
>   
>>>>> objects:
>>>>>       
>>>>>           
>>>> [...]
>>>>
>>>> I'll show this to our BIOS people. When I talked to them before, they 
>>>> claimed that everything were OK, since the OSes we support do come up 
>>>> properly.
>>>>     
>>>>         
>>> I think your BIOS is actually ok, sorry my e-mail was a bit of a stream of 
>>> conciousness.
>>>   
>>>       
>> That's what my colleague confirmed ;-)
>> However, being the nice guy that he is, he provided me with a 
>> preliminary extra special test version (he was on the brink of going on 
>> holiday!), which presents the bridges in their numerical order (0, 1, 2, 
>> 0xfe, 0xff). With that BIOS, I finally got access to the keyboard and 
>> RAID controller and all and I'm installing FBSD as I'm writing this.
>>
>> So, maybe the algorithm shouldn't be "if we find a bridge with number 0 
>> which is not the first one, give it another number" shouldn't this be 
>> "if we find *a* *second* bridge with number 0, give it another number"?
>>     
>
> Yes, that's bascially what my patch does.
>   
I promise to do my best to read mails in the future ;-)
Yes, you're obviously right. Shame on me.
>   
>>> Ah, if you have a working machine where you can build a kernel, you can 
>>>       
> build 
>   
>>> an new CD using an existing ISO as a template.  Simply build a GENERIC 
>>>       
> kernel 
>   
>>> and install it into some DESTDIR=/foo and mount the ISO image using 
>>>       
> mdconfig 
>   
>>> to /dist.  Then do something like 'mkisofs -o new.iso -r -J -b 
>>> boot/cdboot -no-emul-boot -x /dist/boot/kernel /dist /foo'.  If that 
>>> complains about duplicate 'boot/kernel' then you may need to copy all 
>>> of /dist/boot to /foo/boot, install the new kernel into /foo, and 
>>> use '-x /dist/boot /dist /foo'.
>>>
>>> Also, if this machine supports PXE boot at all, that can be a way to boot 
>>>       
> a 
>   
>>> test kernel as well.
>>>       
>> Maybe that's what we'll have to do after all.
>>     
>
> Ok, let me know if it works.  Thanks.
Yepp! Works like a charm. I had been able to boot the original kernel 
with the modified BIOS and apply your patch.
Then I rebooted with that kernel (on the modified BIOS, i.e. the one 
with the 0 254 255 bus numbers) and it booted OK. Then I flashed the 
BIOS back to a release version (i.e. one with 255 254 0 bus numbers) and 
the patched kernel booted OK and the non-patched kernel (kernel.old) 
crashed because it did not find its root FS.

BTW As I understand it, the 254 and 255 busses are on-chip Nehalem 
busses which provide access to certain chip registers.

Will this make its way into a future release? 8.0?

Josef

-- 
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
	If failure had no penalty success would not be a prize (T.  Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html