From: drew@bigwig.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Questions and suggestions
Keywords: linux
Organization: University of Colorado at Boulder
Date: Tue, 14 Apr 1992 21:13:14 GMT

In article <1992Apr14.143326.3281@arbi.informatik.uni-oldenburg.de> Adrian.Wallaschek@arbi.informatik.uni-oldenburg.de (Adrian Wallaschek) writes:
>Hi everybody!
>
>I've got some questions:
>
>	- under DOS there is a package called FDREAD which makes it possible to
>	  write 1.44 MB on 5.25"-floppies without problems. I think it should be
>	  possible to modify the floppy driver that way, it could handle those
>	  disks. (Perhaps you'd like some extra 240k on your distribution disk)
>	  Is there a nearer description on the floppy-devices, esp. the minor
>	  device-numbers ?

It definately is possible, it's just a question of finding someone to do it.

>	- how soon can we expect a pre^n-release of the new filesystem? (We
>	  are working with three users on a 386/33 and even though we have
>	  fast SCSI (Adaptec) the system actually pauses every user if we
>	  e.g. untar a file of 300k!)
>

That's not a file system problem, it's a SCSI driver thing

Only the kernel is scheduled when Linux is in the strategy routine
of a device driver.  

With the SCSI drivers, there are two possible interfaces between
the midlevel driver and the lowlevel host specific driver.  One 
provides a generic interupt driven interface, and expects that a 
completion function will be called when the SCSI host is done doing
its thing, and that the command function will return immediately,
allowing the strategy routine in sd.c to exit immediately,
and other tasks to be scheduled.  With this interface, 
you won't have that problem.

The other interface is mostly there to ease development,
and to support brain dead hardware that 
can't cope with interrupts well.  It
calls a command function that doesn't exit until
command completion.  

Since the command() is called 
from scsi_do_cmnd(), which is called from the strategy routine
of the sd driver, when this interface to the SCSI drivers is used,
the strategy routine doesn't exit until the command completes,
and user tasks aren't scheduled until exit.

On the Adaptec drivers, code is there supporting the queue_command()
interface, but there are bugs in the {compiler, kernel, adaptec low level driver
, midlevel SCSI driver, gcc} that keep it from working correctly.  

The Seagate adapters have severe hardware restrictions that 
led to me to use the command() interface.  

I think 
the current Ultrastor driver used this approach for ease 
of development, and in anticipation of the new interface 
designed to work with multiple outstanding commands, 
out there because of multiple devices and disconnect / reconnect,
the support for multiple outstanding commands for a single LUN
under SCSI2, and inteligent host adapters that queue commands 
internally and send them out in an optimal order.

So - no one has done much work with the queue_command() interface,
and since there are no other implementations other than
the one in the Adaptec driver, I can't tell if the bug
is there, in my code, the reset of the kernel, etc.

This situation will be rectified permanantly when 
1.  Some one else takes care of it.

2.  Some one donates / loans me a better SCSI host more friendly 
	to this interface,  like an Adaptec, with
	full technical documentation. 

3.  I get time to implement a hack to deal with the seagate 
	hardware in this mode, which means either 
	disconnecting and reconnecting on an interrupt
	(which can only be triggered by a device on
	the BUS asserting SEL),
	and personally starting to use queue_command(), 
	or doing something more bletcherous.

	
A temporary fix may be to call schedule() from 
within the wait loop in the low level driver, but 
I haven't looked at the side effects this will have.

Linus?

From: fries@hpspkla.spk.hp.com (Keith L. Fries)
Date: Tue, 7 Apr 1992 15:34:02 GMT
Subject: Linux & Ultra 12F ESDI?
Organization: Hewlett Packard Company, Spokane, Wa.