Messages in this thread | | | From | (david parsons) | Subject | Re: Memory detection is still broken in 2.3.36 | Date | 6 Jan 2000 16:27:04 -0800 |
| |
In article <linux.kernel.20000106173356.B1730@pcep-jamie.cern.ch>, Jamie Lokier <lkd@tantalophile.demon.co.uk> wrote:
>Jan 6 05:03:56 thefinal kernel: e820: 0009fc00 @ 00000000 (usable) >Jan 6 05:03:56 thefinal kernel: e820: 00000400 @ 0009fc00 (reserved) >Jan 6 05:03:56 thefinal kernel: e820: 00004000 @ 000e8000 (usable) >Jan 6 05:03:56 thefinal kernel: e820: 00010000 @ 000f0000 (reserved) >Jan 6 05:03:56 thefinal kernel: e820: 03ee0000 @ 00100000 (usable) >Jan 6 05:03:56 thefinal kernel: e820: 00010000 @ 03fe0000 (ACPI data) >Jan 6 05:03:56 thefinal kernel: e820: 00010000 @ 03ff0000 (reserved) >Jan 6 05:03:56 thefinal kernel: e820: 00016e00 @ 100a0000 (reserved) >Jan 6 05:03:56 thefinal kernel: e820: 00000200 @ 100b6e00 (ACPI NVS) >Jan 6 05:03:56 thefinal kernel: e820: 00049000 @ 100b7000 (reserved) >Jan 6 05:03:56 thefinal kernel: e820: 00080000 @ fff80000 (reserved) > >The map looks plausible to me. How do I tell which page ranges the >kernel is using for memory allocation?
The (usable) pages, like, oh...
>Jan 6 05:03:56 thefinal kernel: e820: 00004000 @ 000e8000 (usable)
... which is most likely the guilty party that's making your system die.
Try the patch I've put on the lkml and see if that makes a difference (this is the memory detection part of the monster memory patch than Nathan Zook and I have been batting about for the past few weeks; one of the things it does is ignore e820 regions that live in the 640k-1mb region, where several bioses cheerfully LIE and report exists.)
____ david parsons \bi/ and you've got a bios that politely sorts all the \/ e820 regions. How unfortunate that it should slip one little whopper on in.
- 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/
| |