Re: [2.6.27] overlapping early reservations [was: early exception - lockdep related?]

[Ingo Molnar <mingo@elte.hu>]

* Luca Tettamanti <kronos.it@gmail.com> wrote:

> On Fri, Sep 5, 2008 at 10:18 PM, H. Peter Anvin <hpa@kernel.org> wrote:
> > Peter Zijlstra wrote:
> >>
> >> On Fri, 2008-09-05 at 21:17 +0200, Luca Tettamanti wrote:
> >>>
> >>> On Thu, Sep 4, 2008 at 10:51 PM, Luca Tettamanti <kronos.it@gmail.com>
> >>> wrote:
> >>>>
> >>>> On Thu, Sep 4, 2008 at 4:25 PM, Peter Zijlstra <peterz@infradead.org>
> >>>> wrote:
> >>>>>
> >>>>> Sadly your config just boots, albeit not to userspace due to missing
> >>>>> drivers.
> >>>>
> >>>> Yes, I managed to boot it with qemu... I tried kgdb - without luck -
> >>>> kernel dies too early.
> >>>> I also managed to get a stack trace :D
> >>>>
> >>>> http://img151.imageshack.us/my.php?image=tracedm1.jpg
> >>>>
> >>>> It seems that lockdep is an innocent bystander... the kernel died with
> >>>> panic() in __reserve_early, and then took another exception while
> >>>> printing the panic (I guess).
> >>>> Will add further debug stuff to see wtf is going on.
> >>>
> >>> Hum, kernel says:
> >>>
> >>> http://img177.imageshack.us/my.php?image=overlappingus2.jpg
> >>>
> >>> Overlapping early reservations b98000-eff266 RAMDISK to 200000-d09cf7
> >>> TEXT DATA BSS
> >>>
> >>> It would appear that the initramfs is overlapping the kernel itself,
> >>> is the boot loader (LILO) doing something stupid?
> >>
> >> Suppose it is, lets ask hpa..
> >>
> >
> > It definitely looks like it.
> 
> Is there anything that the kernel could to do confuse lilo? The issue 
> started appearing with 2.6.27 and the outcome of the boot process 
> varies between versions and seems sensitive to configuration changes 
> (though a "bad" kernel consistently fails).

good question. Does your successful 2.6.26 bootup actually _depend_ on 
the initrd? Or does it perhaps have enough built-in drivers that make it 
boot just fine?

in that case v2.6.26 might just have stomped on the initrd silently, 
corrupted it (during kernel decompress), and the initrd unpacker saw the 
corruption and ignored it. Userspace wouldnt care as the kernel had all 
the drivers it needed.

or perhaps something made your v2.6.27 bzImage larger so that the 
overlap happens - while it didnt before.

> Orthogonal to my problem: the panic() in reserve_early is useless for 
> debugging since the output won't reach the screen or the serial 
> console (even worse: the kernel takes an exception while trying to 
> execute the panic). Is it acceptable to replace it with an 
> early_printk + hlt?

very much so. I was wondering about that already.

In any case it would make sense to turn that particular overlap 
situation into a warning message and disable initrd decompress - and try 
to boot with whatever is built-in the kernel.

	Ingo