Messages in this thread | | | Date | Fri, 26 Dec 2003 13:12:42 -0500 | From | Willem Riede <> | Subject | The survival of ide-scsi in 2.6.x |
| |
I know that many feel that ide-scsi is useless, and should go away. And you are probably tired of message threads talking about it. Yet I ask respectfully that you hear me out, and give me feedback.
I need ide-scsi to survive. Why? I maintain osst, a driver for OnStream tape drives, which need special handling. These drives exist in SCSI, ATAPI, USB and IEEE1394 versions.
One high-level driver, osst, handles all of them, and that's how it should be, right? For ATAPI, it relies on ide-scsi.
(By the way, ide-tape contains code for the ATAPI version, the DI-30, but that code is old and has serveral known problems - I'd like to see it removed - or at least deprecated - I will do that myself later if people want me to.)
So can we agree to keep ide-scsi? I know it is not desired any more for cd writers. To avoid the problem reports from people who don't realize that and select ide-scsi anyway, we can refuse to attach to a cd-type device (today it just warns). And/or make a new explicit module parameter to tell ide-scsi exactly which drives to attach to.
Today, ide-scsi is buggy, and that needs fixing. The underlying problem is that ide-scsi stands with one leg in the IDE world and one leg in the SCSI world, which creates the challenge to make the IDE error recovery work in sync with, and under the direction of the SCSI error handler.
Example bug reports are [1], [2], [3], [4], [5], and [6].
A recurring problem is scheduling while atomic, see [1], [5], [7]. Linus points bluntly to the problem in [7]. I plead guilty to having introduced that code segment in [8]. I later attempted to improve on the error handling in [9], but that patch was not accepted (and wouldn't have fixed that particular problem).
[6] is different, and has me baffled - what can evoke a page fault in idescsi_transfer_pc?
In the spirit of cleaning up one's own mess, I am working on a new patch, to hopefully alleviate the problems. I've made liberal use of the attachments to the osdl bug reports [1]-[4] created by Mike Christie and a patch from Philip Auld [10], to give credit where it is due. I've also looked at ide-cd to see what it does differently.
Please look at the attachment (looking past the touch-ups that I made while I was at it...). Am I moving in the right direction? Specific changes I need advise on: 1) timer expiry attachments to [1]-[4] and [10] suggest using it. Is it useful to buy some more time? I don't see the point to wait longer. By returning 0, I let ide_timer_expiry do its thing to handle lost (dma) interrupts. By seeting the PC_TIMEDOUT flag, I tell our end_request function to return DID_TIME_OUT to the scsi system. 2) ide (atapi) abort/error By providing ide-scsi's own error/abort functions, I defer all errror handling to the scsi error handlers. I have nagging doubts about totally removing ide_do_reset() calls from them though :-( 3) scsi (eh) abort/error These take much inspiration from Mike Christie's work on [1]-[4] The eh_abort gets called first, and takes an opportunistic approach (if the problem resolves itslf, great). The eh_error pulls the carpet from under the request, and does the ide_do_reset(). I hope I've not introduced any new locking/scheduling issues :-)
I've tested the patched ide-scsi with 2.6.0 - and it works fine. Too good actually, meaning the new error routines have not been adequately exercised. Any hints as to how to simulate errors at the ide subsystem level? Something like Stephen Tweedie's testdrive [11] perhaps (if applicable to char device), but for 2.6?
Linus states in [7] that ide-scsi needs a maintainer. I haven't seen anyone step forward, so that leads me to believe I may be the only person that depends enough on ide-scsi to be motivated?
If people will have me, I am prepared to take on that responsibility. I am just concerned that I may not have enough of a variety of devices to be able to thoroughly test it (unless the DI-30 is the only one :-)). What do people see as the requirements to be able to maintain ide-scsi?
OK, let me have it... Thanks, Willem Riede.
References: [1] http://bugme.osdl.org/show_bug.cgi?id=393 [2] http://bugme.osdl.org/show_bug.cgi?id=829 [3] http://bugme.osdl.org/show_bug.cgi?id=1335 [4] http://bugme.osdl.org/show_bug.cgi?id=1381 [5] http://marc.theaimsgroup.com/?l=linux-kernel&m=107103475609592&w=2 [6] http://marc.theaimsgroup.com/?l=linux-scsi&m=105334942001271&w=2 [7] http://marc.theaimsgroup.com/?l=linux-kernel&m=107150176124047&w=2 [8] http://marc.theaimsgroup.com/?l=linux-scsi&m=104051080518591&w=2 [9] http://marc.theaimsgroup.com/?l=linux-scsi&m=104361480527780&w=2 [10] http://marc.theaimsgroup.com/?l=linux-scsi&m=107115248030218&w=2 [11] http://people.redhat.com/sct/patches/testdrive/
| |