On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat knuku@gap.upv.es wrote:
Myles Watson escribió:
On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat knuku@gap.upv.es 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