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

[Luca Tettamanti]

On Fri, Sep 5, 2008 at 10:18 PM, H. Peter Anvin <hpa@xxxxxxxxxx> 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@xxxxxxxxx>
>>> wrote:
>>>>
>>>> On Thu, Sep 4, 2008 at 4:25 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>>>> 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).

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?

Luca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/