Adaptec 2940U2W and new 2.110 bios

Doug Ledford dledford at redhat.com
Sat Apr 24 10:07:10 PDT 1999


Michael Nelson wrote:
> 
> I should have known to leave well enough alone, but...
> 
> My 2940U2W has been working fine.  No problems.  No timeouts.  Yesterday I
> downloaded the latest bios for it from adaptec and installed it (u2w2110.exe).
> 
> Since installing it, I get timeout errors during boot.  Sometimes it times
> out and resets successfully, other times it panics.  Here are some messages
> from a successful boot:
> 
> Apr 23 07:28:01 seahunt kernel: (scsi0) <Adaptec AHA-294X Ultra2 SCSI host
> adapter> found at PCI 11/0
> Apr 23 07:28:01 seahunt kernel: (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
> Apr 23 07:28:01 seahunt kernel: (scsi0) Downloading sequencer code... 374
> instructions downloaded
> Apr 23 07:28:01 seahunt kernel: (scsi1) <Adaptec AHA-294X Ultra SCSI host
> adapter> found at PCI 12/0
> Apr 23 07:28:01 seahunt kernel: (scsi1) Narrow Channel, SCSI ID=7, 16/255 SCBs
> Apr 23 07:28:01 seahunt kernel: (scsi1) Downloading sequencer code... 413
> instructions downloaded
> Apr 23 07:28:01 seahunt kernel: scsi0 : Adaptec AHA274x/284x/294x
> (EISA/VLB/PCI-Fast SCSI) 5.1.14/3.2.4
> Apr 23 07:28:01 seahunt kernel:        <Adaptec AHA-294X Ultra2 SCSI host
> adapter>
> Apr 23 07:28:01 seahunt kernel: scsi1 : Adaptec AHA274x/284x/294x
> (EISA/VLB/PCI-Fast SCSI) 5.1.14/3.2.4
> Apr 23 07:28:01 seahunt kernel:        <Adaptec AHA-294X Ultra SCSI host
> adapter>
> Apr 23 07:28:01 seahunt kernel: scsi : 2 hosts.
> Apr 23 07:28:01 seahunt kernel: scsi : aborting command due to timeout : pid
> 0, scsi0, channel 0, id 0, lun 0 Tes
> t Unit Ready 00 00 00 00 00
> Apr 23 07:28:01 seahunt kernel: SCSI host 0 abort (pid 0) timed out -
> resetting
> Apr 23 07:28:01 seahunt kernel: SCSI bus is being reset for host 0 channel 0.
> Apr 23 07:28:01 seahunt kernel: SCSI host 0 channel 0 reset (pid 0) timed
> out - trying harder
> Apr 23 07:28:01 seahunt kernel: SCSI bus is being reset for host 0 channel 0.
> Apr 23 07:28:01 seahunt kernel: (scsi0:0:0:0) Synchronous at 80.0 Mbyte/sec,
> offset 15.
> Apr 23 07:28:01 seahunt kernel: scsi : aborting command due to timeout : pid
> 1, scsi0, channel 0, id 0, lun 0 Inq
> uiry 00 00 00 ff 00
> Apr 23 07:28:01 seahunt kernel:   Vendor: IBM       Model: DRVS09V
> Rev: 00F0
> Apr 23 07:28:01 seahunt kernel:   Type:   Direct-Access
> ANSI SCSI revision: 03
> Apr 23 07:28:01 seahunt kernel: Detected scsi disk sda at scsi0, channel 0,
> id 0, lun 0
> Apr 23 07:28:01 seahunt kernel: (scsi1:0:1:0) Synchronous at 20.0 Mbyte/sec,
> offset 15.
> Apr 23 07:28:01 seahunt kernel:   Vendor: QUANTUM   Model: VIKING 2.3 NSE
> Rev: 8808
> Apr 23 07:28:01 seahunt kernel:   Type:   Direct-Access
> ANSI SCSI revision: 02
> Apr 23 07:28:01 seahunt kernel: Detected scsi disk sdb at scsi1, channel 0,
> id 1, lun 0
> Apr 23 07:28:01 seahunt kernel: (scsi1:0:4:0) Synchronous at 6.67 Mbyte/sec,
> offset 15.
> Apr 23 07:28:01 seahunt kernel:   Vendor: ARCHIVE   Model: Python 28388-XXX
> Rev: 5.45
> Apr 23 07:28:01 seahunt kernel:   Type:   Sequential-Access
> ANSI SCSI revision: 02
> Apr 23 07:28:01 seahunt kernel: (scsi1:0:5:0) Synchronous at 20.0 Mbyte/sec,
> offset 15.
> Apr 23 07:28:01 seahunt kernel:   Vendor: SGI       Model: QUANTUM XP34550W
> Rev: LXY4
> Apr 23 07:28:01 seahunt kernel:   Type:   Direct-Access
> ANSI SCSI revision: 02
> Apr 23 07:28:01 seahunt kernel: Detected scsi disk sdc at scsi1, channel 0,
> id 5, lun 0
> Apr 23 07:28:01 seahunt kernel: scsi : detected 3 SCSI disks total.
> Apr 23 07:28:01 seahunt kernel: SCSI device sda: hdwr sector= 512 bytes.
> Sectors= 17928698 [8754 MB] [8.8 GB]
> Apr 23 07:28:01 seahunt kernel: SCSI device sdb: hdwr sector= 512 bytes.
> Sectors= 4446801 [2171 MB] [2.2 GB]
> Apr 23 07:28:01 seahunt kernel: SCSI device sdc: hdwr sector= 512 bytes.
> Sectors= 8888543 [4340 MB] [4.3 GB]
> 
> Note that I have also tried with the no_reset option and it's just as flaky
> either way.  Once it finds that IBM drive and gets it reset, the system is
> OK, no more timeout problems, but it's about a 75% chance it won't make it
> through BOOT at all without panicing.
> 
> The same hardware boots fine with the 2.2.2 kernel with the 5.1.10 aic driver,
> and this hardware also worked fine with 2.2.6 and the 5.1.15 driver UNTIL
> the card's bios was updated yesterday.  The previous adaptec bios was 2.10.

I'm not sure what you did, but the boot log above is from the 5.1.14
driver and it has a known bug in relation to the handling of PPR
messages between the IBM drive and the driver.  It was fixed in 5.1.15. 
I think you need to find out how/why you aren't using a kernel with the
5.1.15 driver and then update to it and your problem should go away.

-- 
  Doug Ledford   <dledford at redhat.com>
   Opinions expressed are my own, but
      they should be everybody's.


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




More information about the aic7xxx mailing list