Re: [coreboot] [workaround found] locking...
So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. I think you are right. So, we really need to get some sort of printk locking in there so that we can diagnose what's going on with less guesswork. There's this comment in src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c: /* wait for all the APs core0 started by finalize_node_setup. */ /* FIXME: A bunch of cores are going to start output to serial at once. * It would be nice to fixup prink spinlocks for ROM XIP mode. * I think it could be done by putting the spinlock flag in the cache * of the BSP located right after sysinfo. */ wait_all_core0_started(); I got a little lost in the whole locking discussion; is the above a way to ungarble the output in this particular case? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Ugh, I spoke too soon. Booting with CONFIG_AP_CODE_IN_CAR off reduced me to 1 core. Sigh. Patrick, I'm really interested in figuring out why you are seeing none of these problems with the K8 boards you tested 4315 on. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 03:05:26PM -0400, Ward Vandewege wrote: On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote: So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the APs don't stumble over one another, and the machine boots just fine. Here's the boot log: http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap You'll see a couple garbled lines, but I think that's just each of the APs saying they are ready. I'm glad it works, but it still looks broken to me. Those lines look like ... TrainDQS RdWrPos1: ... in there. Ugh, I spoke too soon. Booting with CONFIG_AP_CODE_IN_CAR off reduced me to 1 core. Sigh. Disregard that - caused by something else. All cores are visible. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [workaround found] locking...
On Wed, Jun 24, 2009 at 1:05 PM, Ward Vandewege w...@gnu.org wrote: Patrick, I'm really interested in figuring out why you are seeing none of these problems with the K8 boards you tested 4315 on. Has anyone else seen these garbled messages? Your 4314 logs had them too. This looks like an unrelated problem that got exposed by the change to me. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
