>
> * 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.
