Cameron, Steve wrote:
> Noticed in scsi_scan.c (2.6.15.2 kernel...)
>
> 1336 static void __scsi_scan_target(struct device *parent, unsigned int chann el,
> 1337 unsigned int id, unsigned int lun, int rescan)
> 1338 {
> 1339 struct Scsi_Host *shost = dev_to_shost(parent);
> 1340 int bflags = 0;
> 1341 int res;
> 1342 struct scsi_target *starget;
> 1343
> 1344 if (shost->this_id == id)
> 1345 /*
> 1346 * Don't scan the host adapter
> 1347 */
> 1348 return;
> 1349
>
> There exist some target devices which depend on the adapter being
> able to do self selection. The HP MSA30 presents a processor device
> at ID 7, for instance.
>
> The processor device at ID 7 will generally not be accessible, because
> the HBA is generally at this ID. The processor device doesn't care that the
> HBA is at id 7. He says, "hmm, the adapter is talking to himself,
> that means, he's talking to me." It's just a way to put a processor
> device on the bus without really "using up" a scsi id, since there
> are only a few of them.
>
> This used to work, I'm pretty sure. Could do
> "echo scsi add-single-device 0 0 7 0 > /proc/scsi/scsi" and
> the processor device would show up. Now it doesn't.
Steve,
I suppose the lk 2.6 equivalent of:
# echo "0 7 0" > /sys/class/scsi_host/host<n>/scan
doesn't work either? [The reason I ask is that the
new technique works for finding "well known" lus.]
Doug Gilbert
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
