home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / bsd / 2685 < prev    next >
Encoding:
Text File  |  1992-07-23  |  5.6 KB  |  139 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!gatech!destroyer!caen!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!gateway.novell.com!ithaca!terry
  3. From: terry@ithaca.npd.Novell.COM (Terry Lambert)
  4. Subject: Satanic boot problem tracked to CMOS, wd.c
  5. Message-ID: <1992Jul23.152046.13374@gateway.novell.com>
  6. Keywords: 386bsd wd.c boot CMOS satan
  7. Sender: terry@ithaca (Terry Lambert)
  8. Nntp-Posting-Host: ithaca.eng.sandy.novell.com
  9. Organization: Novell NPD -- Sandy, UT
  10. Date: Thu, 23 Jul 1992 15:20:46 GMT
  11. Lines: 126
  12.  
  13.  
  14.     Well, curiousity got the better of me... and I found what I believe
  15. to be *the* boot problem... well, several boot problems, actually.
  16.  
  17.  
  18.     The magic file? usr/src/sys.386bsd/i386/i386/machdep.c!
  19.  
  20.  
  21. 1)    The value of 'maxmem' is global.  This should result in it being
  22.     auto-initialized to 0, if the compiler is a compiler.  If either
  23.     the 'biosbasemem' or 'biosextmem' is "invalid", then the value
  24.     of maxmem is set by "maxmem = min (maxmem, 640/4);" to zero.
  25.     This will result in 0, which is clearly incorrect, as the boot
  26.     code is obviously running in RAM somewhere... besides, maxmem
  27.     is calculated off 'Maxmem' directly after the if statement,
  28.     blowing the value to 0-1, which puts us at 0xffffffff for our
  29.     amount of memory.
  30.  
  31.     Correction:  First, this is incorrect; the value being set in
  32.     the default case should be 'Maxmem', not 'maxmem'.  It is very
  33.     arguable that the min of 0 and anything will be zero; why is
  34.     the 'min()' function called at all in this case?  It is also
  35.     arguable that a base memory of less than 640K is unable to boot
  36.     386BSD, so the forced default should be 640K in the "bad CMOS"
  37.     case.  If the machine actually has less than 640K, it will fail
  38.     anyway; but if the thing *has* 640K, this will allow it to boot.
  39.  
  40. 2)    If the amount of extended memory is not greater than 0, or the
  41.     biosbasemem is not equal to 640, 'Maxmem' is *never* set.  This
  42.     is the missing "not handled" case which would more correctly be
  43.     the second "else".
  44.     
  45.     Correction: I suggest propmting the user for the amount of memory
  46.     in the machine at this point, and jumping to just after the
  47.     "#endif" for "NDDB" to avoid reiterating the boundry check code.
  48.  
  49.  
  50.     I suspect that one of these two (fatal) cases are being triggered
  51. by my CMOS having "incorrect" values.  There are several reasons this
  52. might occur:
  53.  
  54. 1)    The CMOS truly has "incorrect" values.  A diagnostic to this effect,
  55.     along with what the values retrieved were, and a "Hit any key to
  56.     continue" message immediately following the "degraded mode" message
  57.     would greatly help debugging this.  This is, I believe, the case,
  58.     although the reason the values are "incorrect" is that "_rtcin" is
  59.     broken.
  60.  
  61. 2)    The CMOS has the correct values, but the read of the CMOS fails
  62.     due to timing; most likely, this is related to the reset rate of
  63.     various items on my bus.  I suspect that the longest delay reset
  64.     items, specifically the built-in bus mouse, are the most likely
  65.     suspects if this is indeed the cause.  Again, the modified
  66.     machdep.c would help me narrow this.
  67.  
  68.  
  69.     The HP Vectra problems could easily be realted.  Dollars to donuts
  70. says that my AT&T machines and the Vectra store their CMOS values in a
  71. strange place, unexpected by BSDI.  There is code to the effect that
  72. "probing breaks certain 386 AT relics"; I suppose *NOT* probing is the
  73. cause of our problems.  I suspect that only one location is being used,
  74. and that the entire memory is being listed there.  Again, without a boot
  75. diagnostic with suffucuent delay, I have no way of telling.
  76.  
  77.  
  78.     Additional notes on boundry conditions:
  79.  
  80.     I would suggest that the expression "maxmem = Maxmem - 1;" be
  81. checked for a minimum and maxum bounds (it immediately follows the "if"
  82. on line 876 of machdep.c).  This is more likely to be the intent of the
  83. misuse of the "min()" expression for the first case of the "if".
  84.  
  85.  
  86.  
  87.     What I suspect: '_rtcin' in locore.s is broken.  Specifically,
  88. it reads as follows:
  89.  
  90.         .globl  _rtcin
  91.     _rtcin: movl    4(%esp),%eax
  92.         outb    %al,$0x70
  93.         subl    %eax,%eax       # clr eax
  94.         inb     $0x71,%al       # Compaq SystemPro
  95.         ret
  96.  
  97.  
  98.     This should probably look like the following to guarantee that it
  99. is more generic (and therefore more likely to work):
  100.  
  101.         .globl  _rtcin
  102.     _rtcin: movl    4(%esp),%eax
  103.         outb    %al,$0x70
  104.         inb     $0x71,%al               # Compaq SystemPro/ATT/HP
  105.         andl    $0x000000ff, %eax       # Fix big nasty bug
  106.         ret
  107.  
  108.  
  109.     I believe that the zeroing of eax is detrimental, and have removed
  110. it; only a byte of the value returned is defined... the rest is undefined,
  111. and is set by the setup program to whatever.
  112.  
  113.  
  114. One of the reasons I need these fixes is to rebuild the kernel: the machine
  115. 386BSD currently runs on at Weber State University (1 whole box) has a
  116. problem with both memory and disk space.  The machine I was doing file
  117. system developement on 0.0 has been confiscated to teach NetWare classes on
  118. (somewhat ironic, considering that I work for Novell), and this has brought
  119. me to a halt.  My cross-compilation environment has died on a couple of the
  120. new header files; I really can't justify the time to fix this until I have
  121. 386bsd up on at least one real box, and I can't get it up on a real box until
  122. I have fixed binaries 8-(.
  123.  
  124.  
  125.     Any of the partial (machdep.c) or full (locore.s) fixes suggested
  126. on a dist.fs disk would be greatly appreciated!  I'm sure that this would be
  127. very helpful in diagnosing the HP Vectra problem, if it didn't fix it
  128. outright, and would certainly serve to expose a lot of internals students
  129. to BSD as well as System V.
  130.  
  131.  
  132.                     Regards,
  133.                     Terry Lambert
  134.                     terry_lambert@gateway.novell.com
  135.                     terry@icarus.weber.edu
  136. ---
  137. Disclaimer:  Any opinions in this posting are my own and not those of
  138. my present or previous employers.
  139.