Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I really appreciate everyones feedback on this. I'll do some more experiments next week, what's most important to me is that I can create a box that has 8G and 16G usable, I'll just have to do reboots to find out what the correct mem= is for each. -Tim On Fri, Sep 13, 2013 at 11:50 PM, Bill Bogstad <bogstad at pobox.com> wrote: > On Fri, Sep 13, 2013 at 10:10 PM, Richard Pieri <richard.pieri at gmail.com> > wrote: > > Bill Bogstad wrote: > >> > >> It would still be nice to know where the memory is being used. > > > > > > Some Googling about lead me to the PCI memory hole: > > http://en.wikipedia.org/wiki/PCI_hole > > Thanks. I've read it now. > > >... > > As to why mem=16G leaves the system with only 9GB detected? Dunnow. If > > mem=8G yields ~6GB useable then mem=16G should yield ~14GB usable on that > > box. There could be some kind of memory mapping weirdness between the PCI > > allocations and the kernel RAM constraints. > > Ahh the kernel does figure into this. :-) Particularily since losing > 6G when the entire 32-bit PCI space is only 4G does seem a bit odd. > I also can't imagine that people buying Windows servers would be happy > to see 38% of the RAM they purchased (6G/16G) just disappear. Maybe > Windows and the BIOS have some way to communicate about memory > availability that Linux doesn't understand. I would call that a bug > (or at least a deficiency) in Linux. > > Bill Bogstad > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://lists.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |