Path: utzoo!utgpu!attcan!uunet!uvm-gen!ackerman
From: ackerman@uvm-gen.UUCP (Steve Ackerman)
Newsgroups: comp.os.minix
Subject: Help! Minix 1.3 & PS/2 Model 80
Message-ID: <1023@uvm-gen.UUCP>
Date: 15 Jan 89 22:57:06 GMT
Organization: EMBA Computer Facility, Univ. of Vermont, Burlington.
Lines: 100


Hello!

	I'm trying to get Minix 1.3 running on an IBM PS/2 Model 80
with not too much luck.  With Dr. Tanenbaum, Stephen Ligett, and
Gary Craig's help, I've been trying different methods of attack.
Right now, I have an AT&T 6300 with Minix 1.3 connected via serial
to the Model 80.  I installed Gary Craig's floppy.c diffs and I'm
working from there.  First, some semi-hard results (semi-hard because
I don't want to put my foot in my mouth! :-) ):

	1)  It appears that there will be a need for an MCA type
	    variable since the MODEL 80 crashes sooner with ps = 1
	    than it does with ps = 0

	2)  I can't see any noticeable difference between the old floppy.c
	    and the new floppy.c (as yet) - meaning I think that
	    there is another problem besides the ones the new floppy.c fixes.

	3)  There is no difference (as yet) with pc_at = 1, and pc_at = 0.

	4)  By putting printk's in the kernel/proc.c interrupt() function,
	    I've found that a MASSIVE amount of interrupts are
	    being received for the FLOPPY task.  This is after the floppy
            task starts the motor, issues a recalibrate command to
	    Floppy disk controller, and then does a
	    receive(HARDWARE).  A printk placed right after the receive in
	    the Floppy task never gets executed.  Leading me to
	    believe that the system appears to hang because all its
	    doing is servicing disk interrupts.  Also, once the
	    the first disk interrupt is received, the message is sent to FS.
	    Thereafter, all the other messages fail on the call to
	    mini_send since the FS is marked as not waiting.

        5)  By placing this statement in interrupt():

            /* TEST: mask any further disk interrupts
             * Note: Gary Craig's code will undo this after receive(HARDWARE)
             *       in floppy task
             */

            if (task == FLOPPY)  port_out(INT_CTLMASK, 0x40);

            I was able to continue execution until the system decided it 
            had an Invalid Root File System (even though it didn't).  The
	    message "Type space to reboot" appeared.  I did, and it received
	    the SPACE key interrupt and rebooted (in)correctly.
	    I think that the reason Minix came up with a bad file system
	    error was probably because the other receive(HARDWARE)s were
	    receiving the initial interrupt cause by the recalibrate command.

        
	6)  With masking the disk interrupt off, I can then hit F1/F2
	    and get a dump (meaning at least the KEYBOARD interrupt works).
	    However, I'm not sure the clock works.  If my memory serves,
	    at first I forgot to do a test to see if the interrupt was
	    coming from the clock before I did a:

	       printk("Hello from interrupt! task = %d\n", task); 

	    in the interrupt routine.  I noticed this a while later -
	    certainly after I had tried the boot image on the Model 80
	    once or twice, and I don't remember being bombarded
            with lots of:  "Hello from interrupt! task = -3" meaning	
            a clock interrupt was received.

This brings me to my question.  Recently, Scott Wiesner posted
this message:

>PS/2's with microchannel architectures use level triggered rather than
>edge triggered interrupts.  The pic(s) much be programmed at initialization
>time for level triggered interrupts.
>
>The normal interrupt acknowledgment for a PC is not sufficient to lower
>the interrupt for a device.  All the devices on a PS/2 have some operation
>that causes an interrupt to be cleared..  Most devices have their interrupt
>line lowered as a result of an operation that would normally be done at
>interrupt time anyway such as reading from the device.  For the floppy
>drives, you must issue a sense interrupt status command to the controller.
>For the clock, you've got to set the high bit at io address 0x61.  (Don't
>remember what this is.  Some kind of misc. control register I think.  I
>believe this is a read/modify/write operation.)  I think these were the
>only two that required anything special.


Does anyone (maybe Scott??) know what the value of the "sense interrupt
status" command is?  I would greatly appreciate it if some one could
post that information so I can attempt sending a "sense interrupt status"
command to the FDC in interrupt().

Dr. Tanenbaum and I have concluded that the 8259A controller should
be set appropriately for level triggered interrupts by BIOS.  Since
the keyboard interrupt is being detected correctly, I think the problem
lies mainly with the Floppy Disk Controller not "shutting up" after 
sending one interrupt.  If anyone has some more suggestions about
what may be wrong, please post!  I need all the help I can get.
Thanks.


Steve