Messages in this thread | | | Date | Fri, 18 Sep 1998 11:41:22 +0900 | From | Ishikawa <> | Subject | Re: Panic in scsi.c ( and a fix) |
| |
Hello,
I am still trying to get to the bottom of the problem caused by the two dd copy commands running in parallel against two CDs in Nakamichi SCSI CD changer device.
Ishikawa wrote:
> (4) THE SAME CHANGE NECESSARY(?): request_device() in scsi.c >
All the previous references to request_device() are typos: I meant request_queueable().
> The fix for allocate_device() changes the checking logic slightly. > It turns out that the request_device() somewhere above the > allocate_device() in scsi.c has EXACTLY the same loop. > Shouldn't allocate_device() be changed in a similar manner? > > I temporaily modified the allocate_device() routine in a similar > manner. The mods don't seem to have adverse effect at all. > (I mean I tested this for an hour so with "ls -lR" on mounted > CDs in paralle, etc..) >
I think I found a potential problem in allocate_device(). The variable found is initialized to NULL at the beginning of function. The general flow of the main loop of allocate_device() is as follows. I wonder if `found' ought to be re-initialized to NULL before entering in the "while loop on SCpnt"? [It could be that the initialization value may have to be dependent on the previous value of `found' and target_busy value in Waltham patch.]
... found = NULL; /* initial value */
while(1==1) { if(!single_lun) { ... } else {
/* Should we re-initialize `found' here? */
while loop on SCpnt {
} ... } ... }
Observation: Before, the testing using
dd if=/dev/scd2 of=/dev/null & dd if=/dev/scd3 of=/dev/null
always made the system hung.
After a temporary patch to re-initialize found to "NULL" in the above mentioned place, I tested the above command sequence 5 times. At one time, the system didn't get hung, but proceeded to copy data as expected [I deduced this since the CD media access took place as expected. When the system got hung, nothing happened.] However, even in this single case, when I interrupted the dd with control-C to avoid seeing the excessive amount of printk() output on the console, after the ^C was typed, it seemed that the SCSI sub-system again entered problematic state where the tight-loop in the allocate_device() stopped the kernel. [This was with Waltham patch and the patch of request_queueable() as mentioned before.]
I hope this information will be helpful for someone who knows the innards of the scsi subsystem in figuroing out the real cause of the problem.
Happy Hacking
Chiaki Ishikawa
- 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/
| |