news@daver.bungi.com (02/22/91)
After spending the night playing about with Marc's '532, we've gotten to the
stage where Minix hangs just a few seconds after start up. The sequence of
events leading to a hang are as follows:
Command (? for help): read d'364544 2000 400 2
Command (? for help): run 2000
Minix 1.3 kernel version: Wed Jun 06 18:35:42 PDT 1990
Pages of user memory: 985
Start user pages: 0x33000
<disk light blips here>
<hang>
The pages of user memory and start address are relatively random; that is,
they take on certain values, and in no particular order (that I can tell).
These value pairs are 985,0x33000 993,0x33000 1027,0x33000 7123,0x34000
12132,0x35000 13682,0x36000 43816,0x3d000 and 65469,0x43000, although
985,0x33000 and 43816,0x3d000 are by far the most common.
The problem seems to happen at an SVC instruction at address 0xb825.
We're reasonably sure that the kernel is configured properly - the partition
table, drive table and root_dev are set correctly.
The '532s has 4M RAM, one terminal connected to duart0 - conn3 running at
9600 baud, 8N1, and a Miniscribe 9380S.
Does anyone have any ideas? Apologies if something simple has been missed
from the newsgroup, but there isn't enough hard disk space on eyrie to
uncompress the group to scan through.
--
Simon Burge - snark@eyrie.img.uu.oz.augeorge@wombat.bungi.COM (George Scolaro) (02/25/91)
[In the message entitled "re: Minix hangs at start up" on Feb 25, 12:25, Jordan K. Hubbard writes:] > > > Gary's board also hung booting Minix in the same place, but had a good > ICU (he didn't get his from the original kit run) - something that had > us really stumped for awhile until we tried pulling out his extra 4MB > of memory just for a lark. Now all works fine. Still a mystery as to > why 8MB should cause MINIX to fail, anyone want to expand on this? > My guess is that the memory sizing code in the rom/minix may not quite handle the case of both banks correctly. With only one bank of dram the code will detect the lack of ram in the next bank as an address range that when written to will return incorrect data. With both banks of memory the end of the 2nd bank will wrap into the beginning of the 1st bank (the pc532 does not decode all the address lines - too many of 'em!), i.e. the sizing code would overwrite the 1st bank... Anyhow, just a thought. best regards, -- George Scolaro george@wombat.bungi.com [37 20 51 N / 122 03 07 W]
bdale@col.hp.com (Bdale Garbee) (02/26/91)
> Now all works fine. Still a mystery as to why 8MB should cause MINIX to > fail, anyone want to expand on this? I recall Bruce or someone posting a patch to the mailing list ages ago to fix this. It related I think to the memory sizing code not being perfect in the case of 8meg, mostly because noone had that much RAM in their machine during testing... I can dig through my archives if need be, email me directly if so... Bdale
phil@cs.wwu.edu (Phil Nelson) (02/26/91)
>Still a mystery as to >why 8MB should cause MINIX to fail, anyone want to expand on this? For those of you new to MINIX, the 8MB problem was due to "broken" algorithm for finding the end of ram. Since the memory appears several times in the address space, 8MB appeared as a large memory space without any breaks. The 4MB appeared with holes. This has been fixed and the 1.5 hybrid version works well in 8MB. That is what I am running and I have 8MB in my machine. So, if your problem is the 8MB, pull out 4. Get MINIX running. Upgrade to the 1.5 MINIX, put back the 4 and you should be running great. --Phil
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (02/27/91)
> ... In my case it turned out to be due to > my having 8 MB installed (Minix can't hack this much memory). We discovered this problem and fixed it last fall. Pc532-minix disks have included the patch since last fall. If you need the patch, send me mail. Sorry about the inconvenience. Bruce