How to force a bus reset?

[Ard van Breemen]

On Sun, 10 Jan 1999, Randy Gobbel wrote:
> On  8-Jan-99 at 13:00, Doug Ledford (dledford at redhat.com) wrote:
> > Randy Gobbel wrote:
> > 
> > > the other messages from tape drive owners, many different types of
> > > sequential-access devices are having problems--so there's definitely a
> > > bug in that version of the aic7xxx driver. 
> > 
> > It's not the aic7xxx driver, it's the st.c driver.  It fails to clear and
> > error condition once encountered in certain versions of the kernel.  I
> > would know more, but I no longer have a tape drive and don't really have
> > any means of testing changes I might make.  I'll try and wrestle a tape
> > drive from somewhere....
> 
> The problem doesn't arise at all with earlier versions of the aic7xxx driver. 
> I've run into this problem with a recent development kernel, and then seen
> everything work fine with a 2.0.35 kernel.  Did someone break st.c?
All problems that I've seen with the aic7xxx are somehow related to the
upper scsi layers. All be it st.c or sg.c. At first I thought it was
something aic7xxx specific, but it really seems upper scsi layer specific
since the aha152x driver seems to exhibit the same behaviour: unable to
clear almost any error. I had no troubles with scsi disks however. I have
had scsi disk troubles, but they seem to magically dissappear when I
hot-corrected the problem. (I.E.: not turning off the disks, just
disconnecting  the faulty scsi box in the middle of the chain to my root
disk. Faulty read/write actions were retried, and I did not lose a
single block!). Bad recovery behaviour can be easily exhibited by turning
of parity on a device, and connecting it to a parity scsi-bus. Do the
scsi-add-single-device, and off goes the reset show.
 --
 intel1: 5:09pm up 2 days, 22:50, 4 users, load average: 0.21, 0.16, 0.05


To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message