Hi,

I have 2 Dell EISA machines with > 16MB, but NetBSD only
sees 16MB.  The problem is that the CMOS extended memory
values are incorrectly updated on the Dell.  I complained
to Dell, and their response is attached below.  Basically
it looks like the correct way to do it is to probe for
the actual RAM instead of trusting the CMOS.  I notice
there is a comment in machdep.c that says probing breaks
certain AT relics.  Is there any way to have a kernel
config file option that for "BROKEN_AT_RELIC" that uses
the CMOS values, but by default it probes? (or the opposite)

Here's what Dell said:

>I forwarded your message to our Unix support group and here is what they 
>sent back.  If you need to contact them, they can be reached at 
>1-800-727-8649.
>
>
>FreeBSD and NetBSD will have the same problem that BSD/I has without a 
>patch, or knowledge of how to hard code the RAM amount so the OS can use 
>it.   The BSD/I is a commercial product, with FreeBSD and NetBSD being 
>gotten off of a CD-ROM, or media sent by a firm supporting such, or from 
>the Internet.  There is a significant lack of understanding though of a 
>problem with ISA SCSI controlers- they have trouble with some UNIX drivers 
>if using MORE than 16MB. Well, the FreeBSD that I am about to install at 
>home has that same limitation- if you are using an Adaptec 1542B (or 
>similar Adaptec, or another vendor's (I can't remember the name)) then you 
>can NOT use it if you have more than 16MB system RAM.
>
>On a case I had late last year, BSD/I could not see more than 16MB system 
>RAM in an Omniplex; the customer got an official patch that resolved this 
>from the BSD/I company in Colorado.  However, the other method is to edit 
>a text file that is on the sytem (I don't know the location of the path to 
>it nor the name) and to 'inform' the OS just how much RAM is actually 
>there then cold-boot; this has to be done every time the RAM actuall 
>changes so the OS can utilize what new RAM configuration one has.  The 
>FreeBSD and NetBSD will have the same problem and the same type of 
>workaround (fix the datafile for amount of actual RAM and cold-boot).  The 
>Internet community may have another more practical solution like a real 
>patch though so the customer should consult the Internet news groups and 
>user groups and whoever is out there officially trying to make money 
>providing support for those two free BSD's.
>
>I read the info below and it matches another complaint I saw some time ago 
>and I've been expecting complaints from the BSD community (Free/Net).  
>However, Dell 3.2, Dell 4.0, Solaris x86 2.1 and 2.4, UnixWare 1.1 and 
>2.0, SCO UNIX 3.2 all correctly calculate system RAM on Dell computers.  
>Those are commercial packages, and the BSD/I is also a commercial Berkeley 
>UNIX and BSD/I distributed an official patch; the distributors and the 
>Internet, and possibly some support groups for FreBSD and NetBSD are the 
>only sources for redress
>for these customers.  The proper way to investigate RAM is to test for it 
>by probing, not look in certain locations in CMOS etc.  However, in our 
>earlier EISA systems, the only way for SCO and Dell UNIX to utilize new 
>additional system RAM was for the customer to boot to EISA configuration, 
>save and cold-boot; EISA had to be updated before the RAM was recognized; 
>and I know that was over 16MB on most of those cases so EISA is consulted 
>at least by those two OS's; for the last two years though, I've seen EISA 
>*NOT* having to be updated before the UNIX sees the new RAM.
>
>
>
>-- 
>John Richards
>Dell Online Services

-Andrew

-- 
==========================================================
Andrew Gillham                       gillham@andrews.edu
LAN/WAN/Netware/Unix Analyst
Resume -> http://www.cs.andrews.edu/~gillham/resume.html