Josh Carroll wrote: >> Actually, it likely doesn't. > > Ok, something else then. My second guess (and what I thought prior to > seeing this mail thread) was that it was perhaps address space > reserved for the kernel? Off topic for this thread I suppose, I can > ask elsewhere. > >> All systems reserve the top 256MB of the address space for PCI >> memory and chipset registers. Modern systems have started >> reserving even more than that for other new PCI functionality. >> Note that this is address space, not RAM. The RAM is likely >> being remapped to some place above the 4GB barrier. > > That makes sense. But is there a way to correlate where the physical > memory is mapped with the memory ranges listed in memcontrol list > output then? Or how would someone check if they are, in fact, affected > by this sort of BIOS bug? > The SMAP table, printed early during boot when bootverbose is set, will tell you what is mapped where. >>> I'll have to play with memcontrol to see if I can set those two large >>> ranges as cacheable. So this is a BIOS bug? The board in question is >>> an Asus P5K-E with BIOS revision 1102, which uses an Intel P35 >>> chipset. >> At best, nothing will happen. But more likely, your box won't boot. > > So I'd be stepping on/trashing memory ranges used for PCI device > mappings? I guess I probably just started a ticking time bomb then, > huh? :) No, you'd made PCI registers be cachable, making any reads from them unreliable and useless. ScottReceived on Wed Sep 03 2008 - 21:03:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:34 UTC