[2340] in linux-scsi channel archive
Re: "read defect list" with 2.0.30-pre7 and patch Aug19
daemon@ATHENA.MIT.EDU (Ulrich Windl)
Mon Aug 25 04:58:23 1997
From: "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de>
To: Gerard Roudier <groudier@club-internet.fr>
Date: Mon, 25 Aug 1997 10:53:22 +0200
Cc: Doug Ledford <dledford@dialnet.net>, linux-scsi@vger.rutgers.edu
In-reply-to: <Pine.LNX.3.95.970825100502.647B-100000@localhost>
On 25 Aug 97 at 10:20, Gerard Roudier wrote:
>
> Hmmm... The linux aic7xxx driver seems to have severe problems on
> data overrun, but such a situation in indeed very rare and in my
> opinion the culprit is the scsi ioctl code.
>
> This code just truncates the user data size without updating the size
> that will be sent to the device. I remember that the same problem
> affects the sg driver code. The difference is that the sg driver allows
> some big buffer to be used. The fix is obviously not to update the size
> in the scsi command but to allows to transfer up to the user wished size.
> I've got this problem years ago with my first SCSI disk that was an
> IBM S12.
>
> Large defect lists are not uncommon nowadays with large capacity disks.
> The current linux scsi ioctl and generic code must should be stated as
> 'not useable' for getting defect lists in my opinion.
Well, that's why I reported the problem. I think the system call
should return an error instead of killing the system. But still, I
would not object if I could finally read my entire defect list.
Being not SCSI expert I can't see why this problem is only related to
read defects list. Aren't there other generic SCSI calls that would
have the same problem?
The original intention WHY I wanted to read the defect list is to
check for grown defects. HP does this in an automated job every
night, and we had a really bad series of ST15150W (8 of 16 disks
replaced within one year).
Ulrich
