Re: [PATCH] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit (ping)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



LILO memory usage:

000600 - 001000 BIOS data check area. Okay to overwrite. LILO usage suppressed with command line "nobd" option. There's also a config file option to suppress usage.

LILO typically loads at 9000:0000 up to the top of the EBDA. Top of EBDA is determined by "int 12h." Some BIOS's on add-in cards do not properly allocate the EBDA. Use LILO Makefile option "BUG_SI_EBDA" to allocate extra EBDA for the BIOS. If the BIOS data check area is created at boot time by LILO, then:

   >  lilo -T ebda

will tell you where LILO is loaded on your system.

--John


At 02:39 PM  Sunday 8/27/2006, H. Peter Anvin wrote:
Andi Kleen wrote:
On Sunday 27 August 2006 21:32, H. Peter Anvin wrote:
Andi Kleen wrote:
Just increasing that constant caused various lilo setups to not boot
anymore. I don't know who is actually to blame, just wanting to
point out that this "obvious" patch isn't actually that obvious.
How would that even be possible (unless you recompiled LILO with the new headers)? There would be no difference in the memory image at the point LILO hands off to the kernel.
AFAIK the problem was that some EDD data got overwritten.

In order to reproduce this we need some details about your "various LILO setups", or this will remain as a source of cargo cult programming.
You can search the mailing list archives, it's all in there if you don't
belive me.

Found the references. This seems to imply that EDD overwrites the area used by LILO 22.6.1. LILO 22.6.1 uses the new boot protocol, with the full pointer, and seems to obey the spec as far as I can read the code. I'm going to try to run it in simulation and observe the failure that way.

However, something is still seriously out of joint. The EDD data actually overlays the setup code, not the bootsect code, and thus there "shouldn't" be any way that this could interfere. My best guess at this time is that either the EDD code or LILO uses memory it's not supposed to use, and the simulation should hopefully reveal that.

Sorry if I seem snarky on this, but if we can't get to the bottom of this we can't ever fix it.

        -hpa


        PGP KeyID: 6781C9C8  (good until 31-Dec-2008)
        Keyserver at  ldap://keyserver.pgp.com  OR  http://pgp.mit.edu
        LILO links at http://freshmeat.net/projects/lilo
        and Help link at http://lilo.go.dyndns.org


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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux