rhyde@ucrmath.ucr.edu (randy hyde) (06/24/91)
MINIX isn't dead on my machine! I just brought it up. Now I've got lots
of questions.
(1) If I compile/assemble MINIX straight out of the box, I get no errors.
(I use the make file provided and generate the distribution code with
the DEBUG but no OMTI flag).
(2) I load the code into memory and set it up to run it just as though I
were booting minix for the first time. I set up the dwords for the
ram disk and set the breakpoint at the proper address (verified against
minix.nm)
(3) The Program starts out fine, but barfs when it hits the breakpoint. I get
a ">" prompt and the machine is frozen. I have to press the reset button
*three times* (this is consistent) to reset the machine.
Has anyone seen this problem before?
On a related topic, what, exactly, do I have to do to apply the hybrid 1.5
diffs. I tried running patch as follows:
patch -p0 <fs_cd
while inside the fs directory. Things choked. I got a weird error message
that said "R.: no found" or something like that. Any comments?
Last question: I get a bus error when running certain programs (compress is
a big problem). Is tthis a memory parity error?
Thanks
Randy Hyde
.culberts@hplwbc.hpl.hp.COM (Bruce Culbertson) (06/25/91)
> MINIX isn't dead on my machine! Glad to hear it! > (3) The Program starts out fine, but barfs when it hits the breakpoint. I get > a ">" prompt and the machine is frozen. I have to press the reset button > *three times* (this is consistent) to reset the machine. Here's my guess. Minix configures the UART as it boots. If the terminal was initially talking to the monitor and then Minix put the UART into a different configuration, this could explain the symptoms you are seeing. Nothing I am aware of prints a ">" as a prompt. Perhaps the monitor's prompt, when "viewed" at the wrong baudrate, looks like a ">". Unless you have changed it, Minix sets the baudrate to 9600. (See DEF_BAUD in rs.c.) When the machine is frozen, you might try experimenting with your terminal's baudrate to see if you can find one which can talk to the monitor. > On a related topic, what, exactly, do I have to do to apply the hybrid 1.5 > diffs. I tried running patch as follows: > patch -p0 <fs_cd > while inside the fs directory. Things choked. I got a weird error message > that said "R.: no found" or something like that. Any comments? The patch executable which I distributed with 1.3 is broken, due to a bug in the compiler I used to compile it. I can send you a new patch or you can get it from willow.cs.wwu.edu. > Last question: I get a bus error when running certain programs (compress is > a big problem). Is tthis a memory parity error? This is wierd. I remember you said you have similar problems with xemacs. I have never seen this on my system. A parity error should cause an NMI, which would drop you into the monitor; it wouldn't cause a bus error. You might check the crc of you compress executable. It should be: 63799 14840 ./bin/compress Good luck! Bruce Culbertson
bdale@col.hp.COM (Bdale Garbee) (06/25/91)
> (3) The Program starts out fine, but barfs when it hits the breakpoint. I get > a ">" prompt and the machine is frozen. I have to press the reset button > *three times* (this is consistent) to reset the machine. You have to unset the breakpoint before you continue. Bruce neglected to mention that in the release notes. > On a related topic, what, exactly, do I have to do to apply the hybrid 1.5 > diffs. I tried running patch as follows: > patch -p0 <fs_cd > while inside the fs directory. Do these all from the root directory for the sources (just above fs, mm, etc). > Last question: I get a bus error when running certain programs (compress is > a big problem). Is tthis a memory parity error? Implies a memory error of some kind, maybe a pointer walking off a list causing a VM violation. Bdale