> 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
configurations)
> 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
=======================================================
campbell@torque.net
Check http://www.torque.net/parport 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/