[coreboot] locking...

Ward Vandewege ward at gnu.org
Sun Jun 21 03:45:35 CEST 2009


On Sun, Jun 21, 2009 at 02:39:31AM +0200, Carl-Daniel Hailfinger wrote:
> On 20.06.2009 20:08, Ward Vandewege wrote:
> > [...] but I'll still have APs and
> > BSP talking all at once, which I'm also seeing on K10.
> >   
> 
> So mangled printk problem is visible on K8 and Fam10?

Yes. Here's a K8 boot that works reliably on h8dme (r4314) but has some
garbled output. Check right after it says "Clearing initial memory region:
Done".

  http://ward.vandewege.net/coreboot/h8dme/minicom-20090618q.cap

And here's a K10 boot that does not boot because there's something going on
with the latest microcode for this cpu (but that's another issue I think). It
has the garbled output right after "Start node 01 done." and eventually
soft resets:

  http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-am.cap

> I just read through the M57SLI early code path again and it seems we
> really have a race condition which causes stack corruption on SMP,
> possibly only visible if there is more than one AP. Or caches of each
> core are independent during early startup and the "every AP can use RAM"
> line of thought needs to be revised.

Interesting. The K8 machine above is a supermicro h8dme with 2x dual core,
and the K10 machine is a supermicro h8dmr with 2x quad core. The m57sli only
has one cpu socket of course but I use it regularly with dual core cpus, and
I have never noticed garbled output. I could be overlooking it of course,
it's relatively subtle in the K8 example.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator




More information about the coreboot mailing list