[8829] in linux-scsi channel archive
Re: aha1542 vs. DAT vs. kernel 2.0.x
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Wed May 17 07:11:04 2000
Message-ID: <001b01bfbff0$6017c510$4d0310ac@fairfax.datafocus.com>
From: "Eric Youngdale" <eric@andante.org>
To: "Steven S. Dick" <ssd@nevets.oau.org>
Cc: "Linux-scsi" <linux-scsi@vger.rutgers.edu>
Date: Wed, 17 May 2000 07:09:31 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0018_01BFBFCE.D8EDBB10"
This is a multi-part message in MIME format.
------=_NextPart_000_0018_01BFBFCE.D8EDBB10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> I have a number of devices on my 1542 bus. Several of them are =
cdroms,
> and if I can manage to trigger behavior that slows them down enough,
> I get bus resets. Actually, I get bus resets on anything that should
> probably have been an I/O error. I've never seen an I/O error, =
however.
> Things don't return after a bus reset to give an I/O error.
One of the bugs I fixed in the patchset that I mailed out would =
cause the error handling code to incorrectly try and issue bus resets in =
the event of a media error. After some number of retries, it should =
just pass the I/O error up to the upper level driver and be done with =
it. Instead it was waking up the error handler, and as I recall it =
started trying to reset the bus. Pretty pointless.
> I think perhaps there are at least two bugs here--the one that caused
> the (unnecessary?) reset, and the one that didn't properly clean up
> the device after the reset.
The first one I think I already got. The second one I don't know =
about. That is why I was thinking I should try adding a disk to the bus =
with the screwy cdrom, and see whether the disk is usable after the =
cdrom is taken offline.
> (BTW: the changer dies randomly if I stick in certain commercial mixed
> multisession cd's. It seems to get confused; it works if I read =
things
> in a certain order, but just thrashes forever trying to find the TOC =
if I
> ask for the wrong thing first. The bus reset DOES reset it. =
Sometimes.)
-Eric
------=_NextPart_000_0018_01BFBFCE.D8EDBB10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV> </DIV>
<DIV>> I have a number of devices on my 1542 bus. Several of =
them are=20
cdroms,<BR>> and if I can manage to trigger behavior that slows them =
down=20
enough,<BR>> I get bus resets. Actually, I get bus resets on =
anything=20
that should<BR>> probably have been an I/O error. I've never =
seen an=20
I/O error, however.<BR>> Things don't return after a bus reset to =
give an I/O=20
error.<BR></DIV>
<DIV> One of the bugs I fixed in the patchset that I =
mailed=20
out would cause the error handling code to incorrectly try and issue bus =
resets=20
in the event of a media error. After some number of retries, it =
should=20
just pass the I/O error up to the upper level driver and be done with =
it. =20
Instead it was waking up the error handler, and as I recall it started =
trying to=20
reset the bus. Pretty pointless.</DIV>
<DIV><BR>> I think perhaps there are at least two bugs here--the one =
that=20
caused<BR>> the (unnecessary?) reset, and the one that didn't =
properly clean=20
up<BR>> the device after the reset.<BR></DIV>
<DIV> The first one I think I already got. The =
second=20
one I don't know about. That is why I was thinking I should try =
adding a=20
disk to the bus with the screwy cdrom, and see whether the disk is =
usable after=20
the cdrom is taken offline.</DIV>
<DIV><BR>> (BTW: the changer dies randomly if I stick in certain =
commercial=20
mixed<BR>> multisession cd's. It seems to get confused; it =
works if I=20
read things<BR>> in a certain order, but just thrashes forever trying =
to find=20
the TOC if I<BR>> ask for the wrong thing first. The bus reset =
DOES=20
reset it. Sometimes.)<BR></DIV>
<DIV>-Eric</DIV></FONT></DIV></BODY></HTML>
------=_NextPart_000_0018_01BFBFCE.D8EDBB10--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
