Messages in this thread | | | From | "David Campbell" <> | Date | Wed, 2 Dec 1998 08:25:17 +0800 | Subject | Re: scsi code and jiffy wraps |
| |
Date sent: Wed, 2 Dec 1998 00:53:24 +0100 (CET) From: Andrea Arcangeli <andrea@e-mind.com> 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 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/
| |