--- scsi_scan.c.save Wed Mar 14 20:58:21 2001
+++ scsi_scan.c Wed Mar 14 21:10:28 2001
@@ -557,6 +557,23 @@
}
/*
+ * If we are offline and we are on a LUN != 0, then skip this entry.
+ * If we are on a BLIST_FORCELUN device this will stop the scan at
+ * the first offline LUN (typically the correct thing to do). If
+ * we are on a BLIST_SPARSELUN device then this won't stop the scan,
+ * but it will keep us from having false entries in our device
+ * array. DL
+ *
+ * NOTE: Need to test this to make sure it doesn't cause problems
+ * with tape autoloaders, multidisc CD changers, and external
+ * RAID chassis that might use sparse luns or multiluns... DL
+ */
+ if (lun != 0 && (scsi_result[0] >> 5) == 1) {
+ scsi_release_request(SRpnt);
+ return 0;
+ }
+
+ /*
* Get any flags for this device.
*/
bflags = get_device_flags (scsi_result);
@@ -776,11 +793,26 @@
*
* FIXME(eric) - perhaps this should be a kernel configurable?
*/
+ /*
if (*max_dev_lun < shpnt->max_lun)
*max_dev_lun = shpnt->max_lun;
else if ((max_scsi_luns >> 1) >= *max_dev_lun)
*max_dev_lun += shpnt->max_lun;
else *max_dev_lun = max_scsi_luns;
+ */
+ /*
+ * Blech...the above code is broken. When you have a device
+ * that is present, and it is a SPARSELUN device, then we
+ * need to scan *all* the luns on that device. Besides,
+ * skipping the scanning of LUNs is a false optimization.
+ * Scanning for a LUN on a present device is a very fast
+ * operation, it's scanning for devices that don't exist that
+ * is expensive and slow (although if you are truly scanning
+ * through MAX_SCSI_LUNS devices that would be bad, I hope
+ * all of the controllers out there set a reasonable value
+ * in shpnt->max_lun). DL
+ */
+ *max_dev_lun = shpnt->max_lun;
*sparse_lun = 1;
return 1;
}
@@ -795,11 +827,26 @@
* I think we need REPORT LUNS in future to avoid scanning
* of unused LUNs. But, that is another item.
*/
+ /*
if (*max_dev_lun < shpnt->max_lun)
*max_dev_lun = shpnt->max_lun;
else if ((max_scsi_luns >> 1) >= *max_dev_lun)
*max_dev_lun += shpnt->max_lun;
else *max_dev_lun = max_scsi_luns;
+ */
+ /*
+ * Blech...the above code is broken. When you have a device
+ * that is present, and it is a FORCELUN device, then we
+ * need to scan *all* the luns on that device. Besides,
+ * skipping the scanning of LUNs is a false optimization.
+ * Scanning for a LUN on a present device is a very fast
+ * operation, it's scanning for devices that don't exist that
+ * is expensive and slow (although if you are truly scanning
+ * through MAX_SCSI_LUNS devices that would be bad, I hope
+ * all of the controllers out there set a reasonable value
+ * in shpnt->max_lun). DL
+ */
+ *max_dev_lun = shpnt->max_lun;
return 1;
}
/*
>
> I applied the first hunk to version 2.4.3-pre4, as by email with Doug.
> The output for the scsi devices follows and is identical with and
> without the patch. Maybe someone can explain the meaning of the illegal
> requests at the end. Nevertheless, I can use the drive fine.
>
If your testing Doug's patch, it might be a good idea to run with/without
your adapter built as a module, as the kernel is inconsistent in its setting
of "online" in scsi.c: it sets online TRUE after an attach in
scsi_register_device_module(), but leaves online as is after an
attach in scsi_register_host().
So, if the scan_scsis set online FALSE, it sometimes is set back to TRUE;
otherwise, I don't think any other code will set online to TRUE (once it
is set to FALSE after its scanned, no one can even open the device, not even sg).
The online = TRUE should probably be removed from scsi_register_device_module(),
as disks with peripheral qualifier 1 (like Doug's the Clariion storage)
ususally complain when sent a READ CAPACITY. I got such errors when running with
a Clariion DASS (DGC RAID/DISK, scsi attached disk array).
Doug - did you try running with/without your adapter built as a module? I'd
expect you to get a READ CAPACITY failure for each LUN with PQ 1.
-- Patrick Mansfield
> Date: Wed, 14 Mar 2001 21:28:14 -0500
> From: Doug Ledford <[email protected]>
> A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> sees multiple identical luns in different scenarios) was not a bug in the
> qla2x00 driver. [...]
> The bug is that we were detecting offline devices and linking
> them into the device list.
Why is this a bug? What would happen when I telnet into the
the RAID box and enable my volumes on those LUNs?
> But, some devices (at least the Clariion raid
> chassis) report luns that don't currently have any device bound to them as
> present but offline. This meant if we truly scanned all luns then we got
> something like 100+ devices on one ID from this chassis when only 1 might be
> valid:-(
16384 LUNs for Fibre Channel. As you see, scanning is out of the
question. You must issue REPORT LUNs and fall back on scanning
if the device reports a check condition. I did that when I worked
in Sun Storage with A5000/A3500/T3 arrays couple of years ago.
-- Pete
Pete Zaitcev wrote:
>
> > Date: Wed, 14 Mar 2001 21:28:14 -0500
> > From: Doug Ledford <[email protected]>
>
> > A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> > sees multiple identical luns in different scenarios) was not a bug in the
> > qla2x00 driver. [...]
> > The bug is that we were detecting offline devices and linking
> > them into the device list.
>
> Why is this a bug? What would happen when I telnet into the
> the RAID box and enable my volumes on those LUNs?
Then they would be legitimate devices and you would do:
echo "scsi-add-single-device a b c d" > /proc/scsi/scsi
to add them to the device chain. Before then, they aren't anything (at least
not in the case of the Clariion array).
> > But, some devices (at least the Clariion raid
> > chassis) report luns that don't currently have any device bound to them as
> > present but offline. This meant if we truly scanned all luns then we got
> > something like 100+ devices on one ID from this chassis when only 1 might be
> > valid:-(
>
> 16384 LUNs for Fibre Channel. As you see, scanning is out of the
> question. You must issue REPORT LUNs and fall back on scanning
> if the device reports a check condition. I did that when I worked
> in Sun Storage with A5000/A3500/T3 arrays couple of years ago.
Patches welcomed. The one I sent already works on a fiber channel setup (the
qla2x00 in question is fc and so is the Clariion array it's connected to, no
detrimental side effects from scanning the box) and so I'm not inclined to add
a REPORT LUNs section to the code unless absolutely necessary.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Doug Ledford wrote:
> Patches welcomed. The one I sent already works on a fiber channel setup (the
> qla2x00 in question is fc and so is the Clariion array it's connected to, no
> detrimental side effects from scanning the box) and so I'm not inclined to add
> a REPORT LUNs section to the code unless absolutely necessary.
Clarification, I think REPORT LUNS support is a 2.5 thing, not a stick it in
now thing.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
On Wed, Mar 14, 2001 at 09:35:43PM -0500, Pete Zaitcev wrote:
> 16384 LUNs for Fibre Channel. As you see, scanning is out of the
> question. You must issue REPORT LUNs and fall back on scanning
> if the device reports a check condition. I did that when I worked
Why wait for a check condition? There's an INQUIRY field bit that
indicates whether REPORT LUNs is supported.
--
Bob Frey
[email protected]
Bob Frey wrote:
>
> On Wed, Mar 14, 2001 at 09:35:43PM -0500, Pete Zaitcev wrote:
> > 16384 LUNs for Fibre Channel. As you see, scanning is out of the
> > question. You must issue REPORT LUNs and fall back on scanning
> > if the device reports a check condition. I did that when I worked
> Why wait for a check condition? There's an INQUIRY field bit that
> indicates whether REPORT LUNs is supported.
And I'm all for using it in the 2.5 kernel SCSI stack ;-)
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Hi,
I have an "old" Nakamichi CD changer.
("old" might be important consideration here. )
Should I test the patch submitted and report what I found ?
(Or maybe I don't have to bother at this stage at all
and simply wait for the 2.5 development and debugging cycle?)
Ishikawa wrote:
>
> Hi,
>
> I have an "old" Nakamichi CD changer.
> ("old" might be important consideration here. )
>
> Should I test the patch submitted and report what I found ?
> (Or maybe I don't have to bother at this stage at all
> and simply wait for the 2.5 development and debugging cycle?)
It would still be helpful because this problem has to be fixed before 2.5.
The only question is whether to fix it with a simple patch such as I just
submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
is how my simple patch works on your device.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Doug, could you check how this patch works if you have the qla2x00 installed in an
Alpha box? I'm hoping this is part of the source of my problems, but I'm not
positive. (I'd do it, but my system is running benchmarks for the next several
days.) Thanks!
- Pete
Doug Ledford wrote:
> Ishikawa wrote:
> >
> > Hi,
> >
> > I have an "old" Nakamichi CD changer.
> > ("old" might be important consideration here. )
> >
> > Should I test the patch submitted and report what I found ?
> > (Or maybe I don't have to bother at this stage at all
> > and simply wait for the 2.5 development and debugging cycle?)
>
> It would still be helpful because this problem has to be fixed before 2.5.
> The only question is whether to fix it with a simple patch such as I just
> submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
> is how my simple patch works on your device.
>
> --
>
> Doug Ledford <[email protected]> http://people.redhat.com/dledford
> Please check my web site for aic7xxx updates/answers before
> e-mailing me about problems
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I applied the first hunk to version 2.4.3-pre4, as by email with Doug.
The output for the scsi devices follows and is identical with and
without the patch. Maybe someone can explain the meaning of the illegal
requests at the end. Nevertheless, I can use the drive fine.
Loading module aic7xxx_old ...
Using /lib/modules/2.4.3-pre4/kernel/drivers/scsi/aic7xxx_old.o
(scsi0) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/14/1
(scsi0) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 383 instructions downloaded
(scsi1) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/14/0
(scsi1) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 383 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7895 Ultra SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7895 Ultra SCSI host adapter>
(scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.
Vendor: SEAGATE Model: ST39173LW Rev: 6246
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
(scsi1:0:2:0) Synchronous at 10.0 Mbyte/sec, offset 15.
Vendor: SEAGATE Model: ST15150N Rev: 4611
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sdb at scsi1, channel 0, id 2, lun 0
(scsi1:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15.
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 4, lun 0
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 4, lun 1
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr2 at scsi1, channel 0, id 4, lun 2
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr3 at scsi1, channel 0, id 4, lun 3
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr4 at scsi1, channel 0, id 4, lun 4
(scsi1:0:5:0) Synchronous at 10.0 Mbyte/sec, offset 15.
Vendor: TEAC Model: CD-R56S4 Rev: 1.0P
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr5 at scsi1, channel 0, id 5, lun 0
sr0: scsi3-mmc drive: 16x/16x xa/form2 changer
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
sr1: scsi3-mmc drive: 16x/16x xa/form2 changer
sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
sr2: scsi3-mmc drive: 16x/16x xa/form2 changer
sr2: CDROM (ioctl) reports ILLEGAL REQUEST.
sr3: scsi3-mmc drive: 16x/16x xa/form2 changer
sr3: CDROM (ioctl) reports ILLEGAL REQUEST.
sr4: scsi3-mmc drive: 16x/16x xa/form2 changer
sr4: CDROM (ioctl) reports ILLEGAL REQUEST.
sr5: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB)
sda: sda1 sda2 sda3 sda4
SCSI device sdb: 8388315 512-byte hdwr sectors (4295 MB)
sdb: sdb1
--
Rafael
"Rafael E. Herrera" wrote:
>
> I applied the first hunk to version 2.4.3-pre4, as by email with Doug.
> The output for the scsi devices follows and is identical with and
> without the patch.
Thank you Rafael. This is what I suspected. I'm not sure when we starting
considering devices with a peripheral qualifier of 1 as being valid, but I
suspect it happened when the scsi_scan.c code was separated out of scsi.c. In
any case, I'm pretty positive that it is the wrong thing to do. This report
at least alleviates one of my fears about broken device possibilities and
starts to confirm my position.
> Maybe someone can explain the meaning of the illegal
> requests at the end. Nevertheless, I can use the drive fine.
As to the illegal request messages, I'm not sure what those are about ;-)
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
"Rafael E. Herrera" wrote:
>
> sr0: scsi3-mmc drive: 16x/16x xa/form2 changer
> sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
> sr1: scsi3-mmc drive: 16x/16x xa/form2 changer
> sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
> sr2: scsi3-mmc drive: 16x/16x xa/form2 changer
> sr2: CDROM (ioctl) reports ILLEGAL REQUEST.
> sr3: scsi3-mmc drive: 16x/16x xa/form2 changer
> sr3: CDROM (ioctl) reports ILLEGAL REQUEST.
> sr4: scsi3-mmc drive: 16x/16x xa/form2 changer
> sr4: CDROM (ioctl) reports ILLEGAL REQUEST.
> sr5: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
> SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB)
> sda: sda1 sda2 sda3 sda4
> SCSI device sdb: 8388315 512-byte hdwr sectors (4295 MB)
> sdb: sdb1
My guess is, ILLEGAL REQUEST is caused by the sr driver issuing
"Mechanism Status" (0xbd) command to the CDROM drives sr0, sr1, sr2, sr3
and sr4. The reason sr driver is issuing this command is because the
loading mechanism type field in CD-ROM capabilities page is set to 0x4
(changer). Does the Nakamichi drive put the changer mechanism on a
separate LUN, e.g. 1? If so, maybe the "Mechanism Status" commnad should
go to LUN 1 but cdrom_read_mech_status() does not set the LUN field in
cgc.cmd[1] to any value other than 0. Could this be the reason for
ILLEGAL REQUEST?
--
Khalid
====================================================================
Khalid Aziz Linux Development Laboratory
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Patrick Mansfield wrote:
> If your testing Doug's patch, it might be a good idea to run with/without
> your adapter built as a module, as the kernel is inconsistent in its setting
> of "online" in scsi.c: it sets online TRUE after an attach in
> scsi_register_device_module(), but leaves online as is after an
> attach in scsi_register_host().
Grrr...I hate these kinds of inconsistencies. They don't belong there.
Whether a driver is a module or compiled in should not effect whether or not
an attached device is considered valid.
> So, if the scan_scsis set online FALSE, it sometimes is set back to TRUE;
> otherwise, I don't think any other code will set online to TRUE (once it
> is set to FALSE after its scanned, no one can even open the device, not even sg).
This is the case for what I was seeing (but, all of the offline entries used
up all 40 SCSI disk structs that were available for use, so if I brought
another controller online there would be no available disk slots).
> The online = TRUE should probably be removed from scsi_register_device_module(),
> as disks with peripheral qualifier 1 (like Doug's the Clariion storage)
> ususally complain when sent a READ CAPACITY. I got such errors when running with
> a Clariion DASS (DGC RAID/DISK, scsi attached disk array).
>
> Doug - did you try running with/without your adapter built as a module? I'd
> expect you to get a READ CAPACITY failure for each LUN with PQ 1.
All modular, but none of the disks on mine ever got the error you are
mentioning. Could possibly be because my root disk is on an aic7xxx and the
array on a qla2x00 that I did *not* let be included in the initrd so I could
bring it up after the rest of the boot was complete. This, of course, implies
that sd_mod was loaded well before the qla2x00 and if I read your above
comments correctly, that means it scanned the array from someplace other than
scsi_register_device_module() and hence didn't get hit by the problem you are
referring to. In fact, I would guess the problem you are referring to only
happens when a driver module is loaded prior to sd_mod.o, and that reversing
the order will solve the problem (but, I haven't looked so I could easily be
wrong ;-)
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
Doug Ledford wrote:
> It would still be helpful because this problem has to be fixed before 2.5.
> The only question is whether to fix it with a simple patch such as I just
> submitted, or a more complex patch that uses REPORT LUNs. Part of that answer
> is how my simple patch works on your device.
Hi, I applied the patch, and found no ill-effect.
The multi-lun devices I have only supports non-hard disk drive types.
On dc390 adaptor(tmscsim):
target:5 Two (2) Lun device. Matsushita (panasonic)
CD/PD combo.
target:6 Seven(7) lun device.
Nakamichi MBR Cd changer.
These devices seem to report all LUN's as available even
if the media is not in the drive.
The driver, tmscsim.o, is compiled as module and is inserted during boot
(using Debian's /etc/module mechanism).
Eg.
Device config.
ishikawa@duron$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: HITACHI Model: DK318H-91WS Rev: B2BQ
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 05 Lun: 00
Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111
Type: Optical Device ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 05 Lun: 01
Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 01
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 03
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 04
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 05
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 06
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
ishikawa@duron$
----------------------------------------
>From dmesg output: I deleted devfs debug messages from below.
----------------------------------------
Linux version 2.4.2 (root@duron) (gcc version 2.95.2 20000220 (Debian GNU/Linux)
) #35 Sat Mar 17 10:35:57 JST 2001
...
Kernel command line: devfs=mount,dmod,dreg,dilookup root=/dev/sda6 ro
scsihosts= sym53c8xx:tmscsim BOOT_IMAGE=242-doug.pat Initializing
CPU#0
...
...
DC390: 1 adapters found
scsi1 : Tekram DC390/AM53C974 V2.0f 2000-12-20
Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111
Type: Optical Device ANSI SCSI revision: 02
Detected scsi removable disk sdb at scsi1, channel 0, id 5, lun 0
Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A111
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NRC Model: MBR-7 Rev: 110
Type: CD-ROM ANSI SCSI revision: 02
sg_init called: 1
...
... The following is reported since the
... target : 5 , lun : 0 is an optical PD drive and
... it seemed to be treated as if it were a removable hard disk.
... Since no media was in the tray when the system booted
... the error is repoted.
... (Note that /dev/sda is Hitachi hard disk.)
sdb : READ CAPACITY failed.
sdb : status = 1, message = 00, host = 0, driver = 28
sdb : extended sense code = 2
sdb : block size assumed to be 512 bytes, disk size 1GB.
/dev/scsi/host1/bus0/target5/lun0: I/O error: dev 08:10, sector 0
unable to read partition table
...
... I ran "modprobe sr_mod"
...
init_sr: pid=425 [comm=modprobe] ppid=424 [comm=bash]
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 5, lun 1
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 6, lun 0
Detected scsi CD-ROM sr2 at scsi1, channel 0, id 6, lun 1
Detected scsi CD-ROM sr3 at scsi1, channel 0, id 6, lun 2
Detected scsi CD-ROM sr4 at scsi1, channel 0, id 6, lun 3
Detected scsi CD-ROM sr5 at scsi1, channel 0, id 6, lun 4
Detected scsi CD-ROM sr6 at scsi1, channel 0, id 6, lun 5
Detected scsi CD-ROM sr7 at scsi1, channel 0, id 6, lun 6
sr_init called: sr_template.dev_noticed = 8
sr_init going to register if not yet.
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
sr1: scsi-1 drive
sr2: scsi-1 drive
sr3: scsi-1 drive
sr4: scsi-1 drive
sr5: scsi-1 drive
sr6: scsi-1 drive
sr7: scsi-1 drive
PS: Oh, wait a second. Doesn't ANSI revision 02 mean SCSI-2 drive, at least?
Why did the CD-ROM driver report scsi-1 drives then?
This has nothing to do with the scsi_scan problem, I think, though.
[end of memo]
Patrick Mansfield wrote:
>
> If your testing Doug's patch, it might be a good idea to run with/without
> your adapter built as a module, as the kernel is inconsistent in its setting
> of "online" in scsi.c: it sets online TRUE after an attach in
> scsi_register_device_module(), but leaves online as is after an
> attach in scsi_register_host().
>
> So, if the scan_scsis set online FALSE, it sometimes is set back to TRUE;
> otherwise, I don't think any other code will set online to TRUE (once it
> is set to FALSE after its scanned, no one can even open the device, not even sg).
>
> The online = TRUE should probably be removed from scsi_register_device_module(),
> as disks with peripheral qualifier 1 (like Doug's the Clariion storage)
> ususally complain when sent a READ CAPACITY. I got such errors when running with
> a Clariion DASS (DGC RAID/DISK, scsi attached disk array).
In my first post everything but the aic7xxx_old driver was builtin. With
it built into the kernel the output is as follows:
SCSI subsystem driver Revision: 1.00
(scsi0) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/14/1
(scsi0) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 383 instructions downloaded
(scsi1) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/14/0
(scsi1) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 383 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7895 Ultra SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7895 Ultra SCSI host adapter>
(scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.
Vendor: SEAGATE Model: ST39173LW Rev: 6246
Type: Direct-Access ANSI SCSI revision: 02
(scsi1:0:2:0) Synchronous at 10.0 Mbyte/sec, offset 15.
Vendor: SEAGATE Model: ST15150N Rev: 4611
Type: Direct-Access ANSI SCSI revision: 02
(scsi1:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15.
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Vendor: NAKAMICH Model: MJ-5.16S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
(scsi1:0:5:0) Synchronous at 10.0 Mbyte/sec, offset 15.
Vendor: TEAC Model: CD-R56S4 Rev: 1.0P
Type: CD-ROM ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Detected scsi disk sdb at scsi1, channel 0, id 2, lun 0
SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB)
sda: sda1 sda2 sda3 sda4
SCSI device sdb: 8388315 512-byte hdwr sectors (4295 MB)
sdb: sdb1
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 4, lun 0
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 4, lun 1
Detected scsi CD-ROM sr2 at scsi1, channel 0, id 4, lun 2
Detected scsi CD-ROM sr3 at scsi1, channel 0, id 4, lun 3
Detected scsi CD-ROM sr4 at scsi1, channel 0, id 4, lun 4
Detected scsi CD-ROM sr5 at scsi1, channel 0, id 5, lun 0
sr0: scsi3-mmc drive: 16x/16x xa/form2 changer
sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
sr1: scsi3-mmc drive: 16x/16x xa/form2 changer
sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
sr2: scsi3-mmc drive: 16x/16x xa/form2 changer
sr2: CDROM (ioctl) reports ILLEGAL REQUEST.
sr3: scsi3-mmc drive: 16x/16x xa/form2 changer
sr3: CDROM (ioctl) reports ILLEGAL REQUEST.
sr4: scsi3-mmc drive: 16x/16x xa/form2 changer
sr4: CDROM (ioctl) reports ILLEGAL REQUEST.
sr5: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
--
Rafael
PS. By the way, it's not necessary to cc me.