Re: scsi code and jiffy wraps

David Campbell (
Wed, 2 Dec 1998 08:25:17 +0800

Date sent: Wed, 2 Dec 1998 00:53:24 +0100 (CET)
From: Andrea Arcangeli <>
Subject: scsi code and jiffy wraps

> Eric, I am trying to fix the last_reset problem in the scsi code. The
> problem is that last_reset == 0 can' t be considered a special value
> (because jiffy first or before will wrap around). This is my latest code
> against 2.1.130. I would like if you could comment or find problems in it.
> I am going to hack ppa.c (my only scsi host) to generate custom scsi reset
> and so have a way to test the code... (David any hint btw ? ;).

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
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 also seen the new scsi_done() that should fix the scsi_done() stack
> recursion issue (because the new command will be sent from a bh handler if
> I interpret correctly the mark_bh()...). I seen also the new nice scsi
> error handler kernel thread. Unfortunately there are no device that are
> using the new inteface yet ;))..

*cough quietly*

I must admit that I may not of cleaned up all the SCSI error processing
routines for ppa/imm. I might of fixed them around 2.1.126, but the last time I
looked one driver was OK the other used the old scsi_obsolete error handling.
Will look into this shortly. The problem is that the ppa/imm only support an
entire bus reset not a per-device reset. This is not such a big drama since
there is normally only one device (except for some Iomega Jaz Traveller

> The stack recursion was a really bad thing for device driver no irq driven
> as ppa (that would like to use the ppa_command callback). Unfortunately
> ppa will still have to use the queuecommand and the ppa_interrupt()
> (software) using bh handlers (or better timers) to run "light", because
> sending a single scsi command via parallel port is a long task and we can'
> t hog the CPU for so much time ;).

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?

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.

David Campbell


Check for all Linux parallel port solutions.

Current project list:
a) Madly fixing up web pages....
b) Maintain Linux ZIP drivers (need to update docs)
c) Create Linux chipset specific parport drivers

Any assistance to clearing this list most welcome

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