[coreboot] Debug help

Myles Watson mylesgw at gmail.com
Sat May 9 05:26:13 CEST 2009

> -----Original Message-----
> From: ron minnich [mailto:rminnich at 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 at gmail.com> wrote:
> > On Fri, May 8, 2009 at 9:08 PM, ron minnich <rminnich at 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?


More information about the coreboot mailing list