[8937] in linux-scsi channel archive
Re: 2.4.0-test1-ac7 & aic7xxx
daemon@ATHENA.MIT.EDU (Jens Axboe)
Fri Jun 2 21:21:18 2000
Date: Sat, 3 Jun 2000 01:31:26 +0200
From: Jens Axboe <axboe@suse.de>
To: "Stephen J. Gowdy" <gowdy@mh1.lbl.gov>
Cc: linux-scsi@vger.rutgers.edu
Message-ID: <20000603013126.G2114@suse.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="kfjH4zxOES6UT95V"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.03.10006021024350.887-200000@antonia.wins.lbl.gov>; from gowdy@mh1.lbl.gov on Fri, Jun 02, 2000 at 10:38:12AM -0700
--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Fri, Jun 02 2000, Stephen J. Gowdy wrote:
> My problem is that when I boot with the new kernel it gets as far
> as loading the aic7xxx module and then just times out on the INQUIRE
> command, it says it is doing bus reset and then trying harder (but to no
> avail). My drive is an IBM UltraStore 9ES (only scsi device) and the SCSI
> adapter is an Adaptec AIC7895 (use first channel). The motherboard is a
> Gigabyte GA-6BXDS if that is relevant.
This is because the initial TEST_UNIT_READY command we used to send
prior to INQUIRY is gone in later -ac kernels, as it was in violation.
This broke the aic7xxx driver for some reason, I hope that Doug will
fix this soon. For now you can just reinstane the TUR command, if
you wish to use 2.4.0-test1-ac7. Note - this is not a fix, just
a temporary work-around.
--
* Jens Axboe <axboe@suse.de>
* Linux CD/DVD-ROM, SuSE Labs
* http://kernel.dk
--kfjH4zxOES6UT95V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="scsi_scan-ac5.diff"
--- /opt/kernel/linux-2.4.0-test1-ac6/drivers/scsi/scsi_scan.c Wed May 31 00:14:25 2000
+++ drivers/scsi/scsi_scan.c Wed May 31 00:14:18 2000
@@ -483,7 +483,38 @@
SDpnt->expecting_cc_ua = 0;
SDpnt->starved = 0;
+ scsi_cmd[0] = TEST_UNIT_READY;
+ scsi_cmd[1] = lun << 5;
+ scsi_cmd[2] = scsi_cmd[3] = scsi_cmd[4] = scsi_cmd[5] = 0;
+
SRpnt = scsi_allocate_request(SDpnt);
+
+ SRpnt->sr_data_direction = SCSI_DATA_NONE;
+ scsi_wait_req (SRpnt, (void *) scsi_cmd,
+ (void *) NULL,
+ 0, SCSI_TIMEOUT + 4 * HZ, 5);
+
+ SCSI_LOG_SCAN_BUS(3, printk("scsi: scan_scsis_single id %d lun %d. Return code 0x%08x\n",
+ dev, lun, SRpnt->sr_result));
+ SCSI_LOG_SCAN_BUS(3, print_driverbyte(SRpnt->sr_result));
+ SCSI_LOG_SCAN_BUS(3, print_hostbyte(SRpnt->sr_result));
+ SCSI_LOG_SCAN_BUS(3, printk("\n"));
+
+ if (SRpnt->sr_result) {
+ if (((driver_byte(SRpnt->sr_result) & DRIVER_SENSE) ||
+ (status_byte(SRpnt->sr_result) & CHECK_CONDITION)) &&
+ ((SRpnt->sr_sense_buffer[0] & 0x70) >> 4) == 7) {
+ if (((SRpnt->sr_sense_buffer[2] & 0xf) != NOT_READY) &&
+ ((SRpnt->sr_sense_buffer[2] & 0xf) != UNIT_ATTENTION) &&
+ ((SRpnt->sr_sense_buffer[2] & 0xf) != ILLEGAL_REQUEST || lun > 0)) {
+ scsi_release_request(SRpnt);
+ return 1;
+ }
+ } else {
+ scsi_release_request(SRpnt);
+ return 0;
+ }
+ }
/*
* We used to do a TEST_UNIT_READY before the INQUIRY but that was
--kfjH4zxOES6UT95V--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
