Solving the first problem will probably take time, as we'll need
to dive into the error recovery paths of ide-scsi and the SCSI
subsystem.
Regarding the second problem, please test the attached patch. ide-scsi
maintains two "SCSI-6" to "SCSI-10" on/off command translation states:
1. Translation for access through /dev/sg -- off by default.
2. Translation for the high level SCSI code -- on by default.
ide-scsi is using:
if (MAJOR(cmd->request.rq_dev) == SCSI_GENERIC_MAJOR)
return test_bit(IDESCSI_SG_TRANSFORM, &scsi->transform);
to test if a SCSI command originated in /dev/sg. sg.c is setting
SCpnt->request.rq_dev = devt = inode->i_rdev;
after calling scsi_allocate_device() (so that we'll identify such
a command as originating from the sg driver). What I suspect is
happening, though, is that after you use cdrecord, the same SCSI
command structures are being recycled for use by the SCSI cdrom
driver, and that when the MODE_SENSE_6 command is issued, the rq_dev
field will still contain the rq_dev from the old structure, and
ide-scsi will therefore not enable the command translation to
MODE_SENSE_10. Ejecting the cdrom might work around the problem,
as it might result in another command structure allocated for the
MODE_SENSE command, which doesn't contain the sg signature in rq_dev.
The following patch will default rq_dev to 0 when allocating a
new command structure. This can potentially create a side effect,
though, and we'll perhaps have to run on all the places which
allocate a command structure with a NULL parameter to reqp, and
update the rq_dev field to reflect the driver in which the request
originated.
Even if the patch won't work, try to change should_transform()
in drivers/scsi/ide-scsi.c to unconditionally return 1 on your
system, so that we'll at least establish that a missing command
translation is really the cause of the second problem.
Gadi
--- linux/drivers/scsi/scsi.c~ Mon Jan 11 19:56:56 1999
+++ linux/drivers/scsi/scsi.c Fri Jan 22 23:14:49 1999
@@ -1204,6 +1204,7 @@
SCpnt->request.rq_status = RQ_SCSI_BUSY;
SCpnt->request.sem = NULL; /* And no one is waiting for this
* to complete */
+ SCpnt->request.rq_dev = 0;
}
atomic_inc(&SCpnt->host->host_active);
SCSI_LOG_MLQUEUE(5, printk("Activating command for device %d (%d)\n",
On Fri, 22 Jan 1999, Meelis Roos wrote:
> For my HP 8100 nothing has changed in 2.2.0-final.
> The first problem - insmod hangs with multi-lun probing enabled - is still
> there:
>
> root@roos:~>modprobe ide-scsi
> scsi0 : SCSI host adapter emulation for IDE ATAPI devices
> scsi : 1 host.
> Vendor: HP Model: CD-Writer+ 8100 Rev: 1.0g
> Type: CD-ROM ANSI SCSI revision: 02
> scsi0 channel 0 : resetting for second half of retries.
> SCSI bus is being reset for host 0 channel 0.
> scsi : aborting command due to timeout : pid 2, scsi0, channel 0, id 0, lun 1 Request Sense 20 00 00 10 00
> root@roos:~>mount /mnt/cdrom/
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
>
> (and here insmod hangs in D state while loading sr_mod). Disabling
> multilun probing helps as a workaround.
>
> The other problem - after using scsi generic with cdrecord, the driver is
> confused and when loading sr_mod in this state it shows random garbage as
> cd drive info - is also still there. I remember having a crash in this
> confused state too but I can't reproduce it any more. I'm ejecting and
> reinsering the cd as a workaround so this problem is not fatal.
>
> scsi dumps are available on request. Gadi Oxman suspected this is a
> problem with enabling/disabling command translation.
>
> --
> Meelis Roos (mroos@tartu.cyber.ee)
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/