> On Sat, Sep 6, 2008 at 7:51 AM, Ingo Molnar <mingo@elte.hu> wrote:
>>
>> * 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.
>
> console=uart8250,io,0x3f8,115200n8
> could help
