I had trouble getting Linux to run on one of my machines (frequent
reboots/crashes without reason) until I found the following: the
base memory of the machine in question is not 640K (0xA0000) but
only 630K (0x9D800; some devices like multiprocessor support extend
the BIOS area downwards).
After some searching I found the following code in
arch/i386/mm/init.c (line 417), which looked like someone else
had trouble in that area, too:
//------------------------------------------------------------------
* IBM messed up *AGAIN* in their thinkpad: 0xA0000 -> 0x9F000.
* They seem to have done something stupid with the floppy
* controller as well..
*/
while (start_low_mem < 0x9f000+PAGE_OFFSET) {
clear_bit(PG_reserved,
&mem_map[MAP_NR(start_low_mem)].flags);
start_low_mem += PAGE_SIZE;
}
//------------------------------------------------------------------
After I modified the 0x9f000 to read 0x9d000 everything worked fine.
Now I remember from my MSDOS days that the exact value to use in this
loop could be extracted from int 12 or the bios data area 40:13.
Is there a special reason this limit has been hardcoded?
Would getting the limit from the BIOS solve the problem or are
there any side effects that I'm not aware of?
I'm not that much of a kernel hacker; so sorry for not posting a
patch here (I'm not quite sure how to access the BIOS within this
function).
Please CC me on comments/answers since I'm not subscribed to this
list (someone from comp.os.linux.development.system directed me to
this list).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/