On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat <[email protected]> wrote:
> Myles Watson escribió: > > > > On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat <[email protected]> wrote: > >> >> but I haven't changed anything but inserting some printk_spew into "void >> dev_initialize(void)" to see where exactly jumps the exception out. >> > Did you try increasing the stack size? When you inserted the printk > statements, were there any warnings about format strings not matching the > number of arguments? Have you tried disabling the siblings yet? > > Thanks, > Myles > > > Hello, > > yes increasing stack size helped with the printks. > How big did you make it? Try making it bigger until it doesn't make a difference any more. > And yes I tried to disable siblings by adding uses > CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the > Options.lb file but it complains at building time that this options is > unkown so I uses LOGICAL_CPUS instead (is it the same?) without results. > You found the right one. Sorry I steered you wrong. All the processors get initialized even with CONFIG_LOGICAL_CPUS=0? That's not good. > Now I know that the the exception comes up in the corresponding init(dev) > for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it > just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot > times, it stucks at the same place. > I don't think the init function is the problem. It's more likely that something is going wrong much earlier, and just catches up to you there. I would leave the device enabled. Thanks, Myles
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
