Okay, now I am not the only developer with this problem.
New 2.4 kernel having problems with determining INITRD_START
Semes that it reports differently on 2.4 kernels vs 2.2. I got some real
good feedback here, and he makes some really good points.
Seems like there are some other RAM issues out there too.
---------- Forwarded Message ----------
Subject: Re: INITRD/SYSLINUX fails on 32M (2.4)
Date: Thu, 24 Aug 2000 20:31:02 -0400 (EDT)
From: "Richard B. Johnson"
To: Michael Peddemors <michael@wizard.ca>
On Thu, 24 Aug 2000, Michael Peddemors wrote:
> On Thu, 24 Aug 2000, you wrote:
>
> Okay, and why was the change made from the historical method and the new
> method? Was it an accidental or intentional change that causes the newer
> kernel to break when the older didn't. Liked the older way better.
> And if we have to stay with the new method, isn't there some kind of a
> patch that should be applied to the kernel to distinguish this if it breaks
> previous installs?
> My distro is being installed in LOTS of 486's et al, and they are more
> likely to run across this condition. IF there is no expected fix, rollback
> of this NEW method of using RAM, then I will not follow up on this anymore,
> and instead look to see if the bootloaders (IN my case syslinux) can
> acurately snoop this info to pass to the kernel.
I think the problem is that it was tested by the person(s) who changed
the boot-code (It's always being changed -- I haven't kept up with the
reasons why). The results tested correctly for their BIOS and their
interpretation of what the BIOS is supposed to report.
Then, you (and others) have a different BIOS... the trouble starts.
That's why we should not trust the BIOS for anything except getting the
kernel loaded above 1 megabyte. We trust it for that only because we
don't have any choice.
There are lots of problems with BIOS. The most obvious is the wrong
way PCI memory and I/O address space is being allocated by many/most
BIOS. The kernel should completely reprogram the PCI devices, rather
than using the I/O and memory address space that the BIOS provided.
For instance, if you need N megabytes of address space for a board
(Screen-card comes to mind), the address chosen MUST lie on a
N megabyte boundary. Often, this is not the case so the AGP or PCI
screen-card BIOS has to re-program that. Since the screen BIOS doesn't
know about SCSI controllers, etc., because it's the first to be
initialized, and since the board BIOS doesn't know that the screen BIOS
changed the address-space the screen-card allocated, it is likely to
put the SCSI-card address-space at a conflicting location. So, Linux
keeps all this stuff as though God programmed it. Everything works
until X-Windows starts to use the allocated memory space and... guess
what, your SCSI file-systems get dorked.
I have seen a lot of such horror stories. If we even get a stable
version of a kernel, that also has initrd working (so I cam justify
working on it on company time), I will at least submit a patch that
finds the amount of memory available early in the boot process.
Then, when that works, it will always work. At least until somebody
else comes along and decides that they don't like assembly in the
kernel or something else....
The kernel has a very good PCI/AGP interface. It should be improved to
completely do it's own address-space allocation from scratch. Doing
the basic PCI setup is the easiest part of setting up PCI devices.
Since it was so easy, nobody did it. I guess the assumption was that
it was so easy, the BIOS must have done it right.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
--------------------------------------------------------
Michael Peddemors - Senior Consultant
Unix Administration - WebSite Hosting
Network Services - Programming
Wizard Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604) 589-0037 Beautiful British Columbia, Canada
--------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:15 EST