Messages in this thread Patch in this message | | | Date | Fri, 22 Jan 1999 23:28:03 +0200 (IST) | From | Gadi Oxman <> | Subject | Re: Still ide-scsi problem with 2.2.0-final |
| |
Meelis,
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/
| |