What they are trying to say, it's not LM or Linux that's at fault. Linux
politely asks the BIOS how much memory and it got an answer. It wasn't
right, but it got an answer. some other OS's ask in a different way and get
the right answer more often. Linux is not a very mature OS from my point of
view and there is a lot of strange hardware out there and it's not 100%
compatible with it.
It's really a retorical question, but who is at fault, Linux or hardware
when it gets a wrong answer?
It used to be a big problem for many OS's. They have been around for a long
time and have figured out the hardware side of it, but then most of them are
commerical OS's also.
Lyle
-----Original Message-----
From: Adrian Saidac [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 04, 2000 8:07 PM
To: [EMAIL PROTECTED]
Subject: Re: [expert] 128 mb mem
I agree with all of you flame or not.
I really need an answer not a status of other systems.
Given the fact that Red Hat/Mandrake is keeping a long silence about
this make me believe that there is a problem somewhere. Why is showing
only on certain systems - THAT'S the mystery!!
Civileme wrote:
>
> John Aldrich wrote:
>
> > On Thu, 03 Feb 2000, you wrote:
> > > Well, Jean-Louis,
> > > It happend that the box has a brand new ASUS board (BIOS 11/99)
> > > If I will set the BIOS for OS/2 I am getting only 14M. Go figure!!
> > > Again I think that thre is something wrong with the code itself -
there
> > > are too many people complainig about the same thing - LINUX IS NOT
ABLLE
> > > TO RECOGNIZE MORE THAN 64M
> > > It looks like the intruction code is made to recognize only a 16Bit
> > > integer.
> > >
> > Wrong. I've got 192 megs of ram here and I didn't do ANYTHING to
> > make it see all that RAM. One thing I recall reading is that
> > overclocking will cause Linux to see less than maximum RAM. If you're
> > overclocking, try setting it back to the "real" clock speed and see
> > what it reports.
> > Here's the output of my "free" command:
> > total used free shared buffers
cached
> > Mem: 192848 181820 11028 55492 22740
79616
> > -/+ buffers/cache: 79464 113384
> > Swap: 102744 5708 97036
> >
> > Keep in mind that I'm running two instances of RC5DES and an instance
> > of SETI@HOME on this machine at all times...
> > John
>
> Hmmmm. I think the conclusion about a halfword for memory size might be
> premature.
>
> Set the BIOS for OS/2 and you have made a HOLE in the memory picture and
all
> the BIOS will report is 15M--the memory hole is 15M to 16M. Why are you
> getting 14? Most likely your video BIOS shadowing is enabled, effectively
> eliminating the first M from the picture.
>
> I have 17 machines with either 128M(15) or 256M(2) and I never used the
> append "mem=xyzM" on any of then. One is running Caldera OpenLinux 2.3,
15
> are running LM 6.1 (Helios) and one is running LM 6.0 (Venus) UPtimes as
> long as 96 days (on the server) exist now, and some of the others have
been
> on since I implemented Helios on them, 12-63 days.
>
> Now at home I have a couple of those cheapie boards that have the AGP and
the
> sound built-in and each of them uses 8M of main for the video mem. Linux
> reports 120M/119M on them, which is correct. Again, no special settings.
>
> Here is the output of free
> total used free
> shared buffers cached
> Mem: 119840 63836 56004
> 45456 2900 33768
> -/+ buffers/cache 27168 92672
> Swap: 168672 0 168672
>
> So look at the BIOS and erase the memory hole at 15M and change the
setting
> for OS/2 for >64M and Linux will see your memory too.
>
> Civileme
>
> --
> experimentation involving more than 500 trials with an
> ordinary slice of bread and a tablespoon of peanut butter
> has determined that the probability a random toss will
> land sticky side down (SSD) is approximately .98
