For what it is worth, I was testing the new queueing code in the 2.3
kernels using a 1542 and an old scratched up CDROM that gives lots of sector
errors. For this category of errors, eventually I started getting into the
timeout code, and this would abort, and ultimately reset the bus.
Eventually device got into such a weird state that the error handling code
took the device offline. Once this took place, the machine was back to
normal (the root filesystem was on a SCSI disk on a different bus
(aic7xxx)).
I think I should test with an additional device on the 1542 bus,
however. I would like to see if the 1542 and the other device are still
functional after all of this abuse to the cdrom. This is something it only
recently occurred to me that I could test.
-Eric
----- Original Message -----
From: "Uncle George" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 15, 2000 10:52 AM
Subject: Re: aha1542 vs. DAT vs. kernel 2.0.x
> My experience with aha et al ( i know of no other - I have aha1542cf, and
2 of
> the 29xx series which is aha777x drivers) is that scsi bus time-outs, once
> reported onto syslogd, you just never recover at all. sometimes the scsi
bus is
> so hosed that a warm boot will not recover. I am not sure who is
captivating
> the bus, but only a power down will do. On my alpha, my bus just doesnt
get
> hosed, but those timeouts, once they occure, do not stop at all!
>
> Andries Brouwer wrote:
>
> > On Mon, May 15, 2000 at 01:39:33AM -0400, Steven S. Dick wrote:
> > > Alan Cox wrote:
> >
> > > >This fixed the crash on reset cases I was seeing. Im sure the entire
> > > >reset problem is not fixed though
> > >
> > > I'm also sure it did not fix the reset problem.
> > > I think there are other resources that are not freed after a reset.
> > >
> > > My experience is that once a device causes a reset, it never recovers,
> >
> > I agree completely.
> >
> > > The AHA1542 is a very good ISA card. It's hard to beat for ISA.
However,
> > > the 2.2 linux drivers for it are substandard. The drivers in 1.0 were
> > > much more stable.
> >
> > Here I think I disagree. On the one hand I recall precisely
> > the same problems from the 1.0 times (indeed, 1.0 would panic).
> > On the other hand I think that the driver has been essentially
> > unmodified all this time, so it would be surprising if there was
> > significant change in behaviour.
> >
> > Can you find a driver version that you proclaim relatively stable?
> > More stable than the current one?
> >
> > Andries
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to [EMAIL PROTECTED]
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
