Messages in this thread | | | From | Siegfried Hempfer <> | Subject | Problems with base memory | Date | Thu, 20 May 1999 10:49:09 +0200 |
| |
Kernel Version: 2.2.5 (it's the same with 2.2.9) Distribution SuSe 6.1
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/
| |