public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* lilo, initrd and RAM > 1GB
@ 2001-12-30 19:11 Andreas Haumer
  2002-01-02  1:03 ` H. Peter Anvin
  0 siblings, 1 reply; 2+ messages in thread
From: Andreas Haumer @ 2001-12-30 19:11 UTC (permalink / raw)
  To: linux-kernel; +Cc: johninsd

Hi!

I found a problem booting with lilo 22.1, linux-2.2.20 and
initrd on a machine with more than 1GB of physical memory!

The kernel is configured with CONFIG_2GB set and lilo is
called with the following parameters in /etc/lilo.conf:

[...]
boot = /dev/scsi/host0/bus0/target0/lun0/disc
install = /boot/boot.b
timeout = 100
verbose = 1
prompt
read-only
lba32

image = /boot/vmlinuz
  label = linux
  root = /dev/scsi/host0/bus0/target0/lun0/part3
  initrd = /boot/initrd.gz
  append = "apm=power-off"
  vga = 1
[...]

With this setting, the system boots fine if I have 1GB - epsilon
of RAM installed.

As soon as I put more than 1GB of physical memory into
the machine (for example: 1.5GB), the kernel itself recognizes
the correct amount of memory, but tells me at boot time:

[...]
initrd overwritten (0x80f30000 < 0x8115af08) - disabling it
[...]

It boots fine, if I boot it with "linux mem=960M"...

I tried the same kernel and initrd image with the syslinux
bootloader (version 1.65), and here linux boots fine even
with 1.5GB RAM installed.

I've put a printk statement into init/main.c to get the 
initrd_start address in this case, and it says:

[...]
start_kernel: initrd_start = 0xb7f30000
[...]

I then called lilo again on the 1.5GB system booted with
syslinux, but this didn't help: initrd was still loaded
at address 0x80f30000 and thus got overwritten at boot time...

This behaviour is reproducable on a different system, too.

To me it looks like lilo get's the initrd start address
wrong if there is more than 1GB of RAM in the system.
I haven't found anything in the lilo documentation how to 
solve this problem. 

Is this a lilo or a user bug?
Any idea, anyone?

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: lilo, initrd and RAM > 1GB
  2001-12-30 19:11 lilo, initrd and RAM > 1GB Andreas Haumer
@ 2002-01-02  1:03 ` H. Peter Anvin
  0 siblings, 0 replies; 2+ messages in thread
From: H. Peter Anvin @ 2002-01-02  1:03 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <3C2F66FF.13BD2A19@xss.co.at>
By author:    Andreas Haumer <andreas@xss.co.at>
In newsgroup: linux.dev.kernel
> 
> To me it looks like lilo get's the initrd start address
> wrong if there is more than 1GB of RAM in the system.
> I haven't found anything in the lilo documentation how to 
> solve this problem. 
> 

The initrd end address should be obtained via the following algorithm:

        # high_addr here is the highest byte that can be occupied by
        # the initrd

	if ( bootproto >= 0x203 ) {
	   high_addr := header->ramdisk_max
        } else {
           high_addr := 0x37ffffff
        }

        high_addr := min(memsize-1, high_addr)


The "magic constant" 0x37ffffff was widely believed to have been
0x3bffffff (which it might have originally been); this value, however,
doesn't work with most kernels.

This is why the ramdisk ceiling needs to be explicitly reported by the
kernel, as is done in the 2.03 boot protocol.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-01-02  1:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-12-30 19:11 lilo, initrd and RAM > 1GB Andreas Haumer
2002-01-02  1:03 ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox