Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!rutgers!njin!princeton!notecnirp!nfs
From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Interrupt problems
Summary: I could use some advice!
Keywords: Toshiba 5100 disk controller interrupt
Message-ID: <16570@princeton.Princeton.EDU>
Date: 24 Apr 89 05:41:56 GMT
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 46

My copy of Minix 1.3 just arrived from P-H and I am trying to get it 
working.  Most everything seems to run fine, except the hard disk
driver.  Snooping around indicates that the 5100 has a disk controller
that's too clever by half.  In particular, I have reason to believe
that the controller caches an entire track when asked for a sector.

When setting up the WINCHESTER task at boot time, Minix reads things
off the disk (in particular, the first thing read is the partition table).
Because the disk has 512 byte sectors, and Minix uses 1Kb blocks, the
driver asks for two sectors from the beginning of the disk.  Then the
following occurs, in quick succession:

	- an interrupt is received from the controller
	- the routine "interrupt" starts running; the first thing it
	  does is reenable the 8259 PIC
	- the controller interrupts again(!)
	- interrupt processing starts all over again, saving the
	  second message and setting the appropriate bit in the
	  bitmap saying a message is pending for WINCHESTER
	- interrupt processing resumes on the first interrupt,
	  saving the first message over the second and setting
	  the WINCHESTER bit again
	- WINCHESTER finally does a RECEIVE(HARDWARE,..)
	- "interrupt" sends WINCHESTER a message successfully and
	  clears its message pending bit
	- WINCHESTER looks for the second sector by doing another
	  RECEIVE(HARDWARE,..) and goes off to never never land

I have fixed this by changing w_transfer in WINCHESTER to do a series
of single sector reads to fill out a block, which works.  Performance
seems somewhat awful however.

Now the question:  Should I be patching WINCHESTER for this?  Arguments
in favor include localizing the changes to one routine, but I have a
fundamental objection to the fact that the interrupt handler can lose
interrupts in this way.  I will admit that my machine may be unusual, but
it seems that similar problems would occur in a machine with two or more
hard disks, since one could easily have multiple requests pending on 
multiple disks.  My gut feeling is that proc.c should be rewritten to
handle this.  As this is somewhat philosophical, perhaps ast could comment.

In addition, I would be happy to receive suggestions on improving the
hard disk performance I am seeing.  Does 1.4 address either the correctness
or performance issues?

Norbert