[lkml]   [1999]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCSI Broken after 2.2.10 for Adaptec 7xxx ???
"George R. Kasica" wrote:
> On Sun, 5 Dec 1999 20:27:13 -0500 (EST), you wrote:
> >On Sun, 5 Dec 1999, George R. Kasica wrote:
> >
> >> Hello:
> >>
> >> I think something got broken after 2.2.10 in the SCSI code for the
> >> Adaptec 7XXX adapters....Below is my boot up info for 2.2.10 (last one
> >> that appears to work) and then 2.2.11, 2.2.12 and 2.2.13 all fail
> >> similarly. They were complied with the same options using
> >
> >> Dec 5 09:50:55 eagle kernel: scsi : 1 host.
> >> Dec 5 09:50:55 eagle kernel: Vendor: SEAGATE Model: ST32550N
> >> Rev:0021
> >> Dec 5 09:50:55 eagle kernel: Type: Direct-Access
> >> ANSISCSI revision: 02
> >> Dec 5 09:50:55 eagle kernel: Detected scsi disk sda at scsi0, channel
> >
> >>
> >> Under 2.2.11,2.2.12 or 2.2.13 I get the following error:
> >> --------------------------------------------------------
> >> scsi: Aborting Command due to timeout pid 11,scsi0,channel 0,id3,lun 0
> >> Testing Unit Ready 00 00 00 00 00
> >>
> >> and it just keeps repeating and the system will not boot.
> >
> >I saw the same problem with an older Seagate drive here. A Barracuda
> >ST15150W just would not work on a 7890-based controller under any of
> >Doug's newer drivers. If I reverted back to the driver of circa-2.2.9 (I
> >think it was aic7xxx 5.1.10) it was just fine. This only occurred on a
> >7890 controller. The drive's previous home was in an older box with 2940A
> >controller (7880 chipset), where it worked (and continues to work) fine.
> >
> >Steve
> >
> Steve:
> OK...maybe its too late here or I'm too stupid, but what do I do to
> fix this??? CAn I change the driver version that runs with 2.2.11,12
> or 13 and if so how? OR what are my options.....

Try reducing the sync negotiation speed for the tape drive in the Adaptec
BIOS. It may be that the driver is trying to negotiate 20 MByte/s speed which
the tape doesn't support and it is getting in an SDTR loop (which is a
separate bug I need to fix, this is just a workaround until I do though). The
deal is that in order to get devices to negotiate at 80MByte/s on all the U2W
controllers out there, I had to interpret several different variations of
speed bits in the SEEPROM as 80MByte/s. The problem was that some versions of
the BIOS would set 80MByte/s to the same thing as 11.4MByte/s on other BIOSes
and 10MByte/s on other BIOSes. Dealing with all of these various bit settings
has forced me to interpret all the possible 80MByte/s settings as 80, and that
means some other settings get bumped up with the new settings. Now, that
still shouldn't cause an SDTR loop on your device, so this is a separate bug,
but by setting things to a lower speed, you should be able to avoid the loop
and get things to work until the next version comes out and fixes the SDTR
loop (I guess now I got to figure out how to duplicate the loop here...).

Doug Ledford <>
Opinions expressed are my own, but
they should be everybody's.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.067 / U:6.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site