Re: scsi code and jiffy wraps

Andrea Arcangeli (
Wed, 2 Dec 1998 01:50:23 +0100 (CET)

On Wed, 2 Dec 1998, David Campbell wrote:

>What exactly are you trying to achieve here Andrea?, reset the drive (that is
>easy) or get the mid-level driver to ask for a reset. How about a /proc entry

The second.

>so that the next SCSI command fails horribly requiring a reset?
>Something like "cat 'fail=0x1234' > /proc/scsi/ppa/0" where the number will be
>used as the high 16 bits of the cmd->result for the next immediate SCSI command
>that the interface recieves. This will allow the error processing to work and
>hopefully clean itself up.

I' ll try to look into it tomorrow. Thanks for the tip ;).

>Will look into this shortly. The problem is that the ppa/imm only support an

Don' t worry, it' s really not hurgent (because only eata and u14-34f
seems to have an kernel _option_ to use the new scsi code and we are a lot
far from removing scsi_obsolete.c ;).

>Sorry, I haven't kept up with the latest SCSI changes in the kernel. I thought
>the old scsi_command() was obsolete and the scsi_queuecommand() was the entry
>to use?

This is what I understood some time ago too.

>As far as scsi_command() [or ppa_command() as in the ppa driver] it can quietly
>vanish from the kernel. The ppa_command() ONLY exists due to historical reasons
>and is not used at all. I think I removed it in the last patch to Linus.

No it' s still there. I agree to remove it though since the check for
can_queue it' s only slowing down a bit the system and if a driver still
use the ->command interface, it' s trivial to fix it, because it has only
to use the ->queuecommand and run scsi_done (passed as parameter) before
return ;). Probably it' s still there only to assure 100% source code
backwards compatibility.

Andrea Arcangeli

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at