[comp.os.minix] Reboot solved?

AJB@dlvh.daresbury.ac.uk (07/07/90)

Well, my reboot problems seem to be solved. To remind you all of the
problem...

1) I'd upgraded to 1.5.10 on a 1040ST ... whenever I CTRL-ALT-DEL'd
   (CAD'd) to reboot the machine all I got was a whining b&w monitor
   and a hung system (although to be fair on 1.5.10 it happened as
   well on 1.5.3-5 after upgrading to TOS1.4).

2) I changed machine to a 2Mb STE and the problem went away!

3) I then decided to make my RFS 720K (loaded as usual from /dev/hd3);
   this involved to usual mkfs and restoring the partition from the
   ramdisc......  The whining reboot problem came back.

SOLUTION: I've just rebuilt the kernel and all is well again .... and
  NO, my MINIX.IMG was not corrupted! Anyone got any ideas what was
  going on?

Incidentally, the reboot routine in STMPX.S is defined as

     movea.l	4,a0
     jmp	(a0)

 ... wouldn't it be safer, to ensure a COLD boot to have it defined as

     clr.l	0x426		! Force COLD start
     movea.l	0,a7		! Load correct value for SSP on reset
     movea.l	4,a0
     jmp	(a0)

I've incorporated this in my own kernel (maybe thats why the problem
has gone away :-) ?).

Other matters:
What do I need to modify to get the KEYPAD keys returning their correct
values (instead of the CTRL P's & Q's I get at present)?

WOULD SOME KIND SOUL ***PLEASE*** MAIL ME A COPY OF stterm/term.c WITH
THE CORRECT 1.5.10 crc (repeated request).


Alan Bleasby


PS Interesting titbit for STE owners. Looking in the ROMs the least
   significant byte of PHYSBASE is loaded into $FFFF820D (the two
   middle-order bytes are at FFFF8201 and FFFF8203 as in the ST).

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/11/90)

Oh, no! The real problem is the memory allocation in the systask.
There is a static variable been_here that gets Memory from a TOS variable.
When you reboot, the next request for memory fails.
On my mc68000 MINIX box, when I do CTRL-ALT-DEL, the boot message appears
and MINIX asks for inserting the Floppy containing the root file system.
Then, MM says: no memory left.

I have not tried, but a solution is to make been_here in this context
global and clear it on reboot.

Your solution simply was to have a root filesystem that is less than half
the memory size, so you can request the memory twice.
C.v.W.

meulenbr@cst.philips.nl (Frans Meulenbroeks) (07/12/90)

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes:

>Oh, no! The real problem is the memory allocation in the systask.
>There is a static variable been_here that gets Memory from a TOS variable.
>When you reboot, the next request for memory fails.
>On my mc68000 MINIX box, when I do CTRL-ALT-DEL, the boot message appears
>and MINIX asks for inserting the Floppy containing the root file system.
>Then, MM says: no memory left.

>I have not tried, but a solution is to make been_here in this context
>global and clear it on reboot.

>Your solution simply was to have a root filesystem that is less than half
>the memory size, so you can request the memory twice.
>C.v.W.

Umm. I don't think I completely understand this. 
This is maybe due to the fact that I did not see a previous article
on which this should be a reply. 

I've written the beenhere stuff, long time ago, late in the evening.
What happens is the following: 
when minix boots mm asks for the available memory to the systask.
This is asked repeatedly until m_ptr->COUNT = 0;
The reason mm asks, is because on PC's memory need not te be
contiguous.
On the ST we only have one chunk of memory, so the static var beenhere
keeps track whether or not we got such a request. 
If not, I return the value of some TOS var (I believe phystop).
If yes, we're done, so return count=0.
Notice that the value of phystop is never changed by me!

Now whenever I reboot, be it with CTRL-ALT-DEL, CTRL-ALT-SHIFT-DEL (tos
1.4 only), or pressing the reset key, the system reloads the operating
system from disk and everything starts again fine.

I've done this zillions of times, and I really don't understand the
message before. I hope someone can explain this to me.
I hope I gave an explanation which answers at least part of the
question.

regards,
--
Frans Meulenbroeks        (meulenbr@cst.philips.nl)
	Centre for Software Technology
	( or try: ...!mcsun!phigate!prle!cst!meulenbr)

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/13/90)

I was not aware that the system is rebooted from diskette.
On my homemade system, when I do ctrl-alt-del, reboot() is called,
and this just restarts MINIX at the entry point, start.

This means, my reset vector points to the entry of MINIX, and the
data section remains unchanged.

In this case, been_here remains set and when MM requests memoryl,
the systask rejects the request.

Excuse me, I will never answer to questions that might have to do
with ATARI-specifics or hardware.
I made two such nonos the last weeks, my MINIX is ATARI-compatible,
but obviously not the boot process.......

Christoph van Wuellen.

meulenbr@cst.philips.nl (Frans Meulenbroeks) (07/16/90)

On the ST doing ctrl-alt-del reloads minix from disk. 
This is caused by the fact that bytes 0-7 of the ST memory are
not writable hardware locations. If you look in tools/boot.s you'll
see that the first 8 bytes are not copied to low mem.

In order to get ctrl-alt-del working as expected the 
been_here problem should be solved and line 330 of 
kernel/stmpx.s should be changed from
        jmp     (a0)
to       
        jmp     _start
Perhaps this should be accompanied by an #ifdef. 
I don't know exactly what the amiga and mac ports of minix will
do or use from this file.
 
--
Frans Meulenbroeks        (meulenbr@cst.philips.nl)
	Centre for Software Technology
	( or try: ...!mcsun!phigate!prle!cst!meulenbr)