-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Friday, May 08, 2009 9:18 PM To: Myles Watson Cc: coreboot Subject: Re: [coreboot] Debug help
On Fri, May 8, 2009 at 8:14 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, May 8, 2009 at 9:08 PM, ron minnich rminnich@gmail.com wrote:
The only thing that occurs right off is that configuraitons are just different on the one missing an opteron.
I should have been clearer. It's the same board. They both have the same module installed. In one case the module doesn't respond to configuration cycles and is disabled in hardware (recognized as an open socket.)
understood. But one board I worked on had a full I/O bus on each opteron, which meant the pci config space changed radically with one removed.
Sorry. I don't know what a full I/O bus means. Do you mean each one had its own 16-bit I/O space? In that case no. This one just uses the normal k8 allocation code.
How is HT wired up on this board? Some boards have a completely independent IO bus on each socket.
The Opteron is connected to: Link 0: Nvidia ck804 Link 1: Opteron socket / FPGA Link 2: Amd 8132
The strange thing is that the missing/garbled messages are during resource allocation on LInk 0. I'll probably ignore it for a while longer if there's no way to track it down. I'm just worried that something is trashing memory, and that some time it will be a message that I need to see :)
is it possible that the the act of allocating resources puts some config space registers into a state such that 0x3f8 is inaccessible or pointing to some other device? I hope this question even makes sense -- it's been a long day.
It makes sense and it's possible, but if it's happening there is a really nasty bug somewhere. There are config-space registers in the Opteron that direct configuration accesses to specific links.
I don't think I'm seeing that here because at the end it is all set up correctly. There is just data corruption at the serial port. I guess it's possible that it is something much less sinister. Is there some way that the serial port could be misconfigured so that if you write to it too quickly you overflow the buffer and lose output?
Thanks, Myles