lkml.org 
[lkml]   [2003]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectThe 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/
\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.066 / U:1.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site