SCSI Tape driver problem
hello all,
I noticed a bug in the scsi tape class driver in kernel 2.2.16/2.4.x.
This is the test that i ran.
1. I have two scsi-fc tape devices
2. I insert the hba driver, so that both the tape devices are enabled and map to st0 and st1
3. I remove the device that maps to st0 using
echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi
4. Now, if i try to do an open("/dev/st1",..), the process hangs as the open call never returns.
The problem seems to be in the callback function st_sleep_done() where the following comparison is being made
if ((st_nbr = TAPE_NR(SCpnt->request.rq_dev)) < st_template.nr_dev)
{
...
}
This comparision fails for the above test since nr_dev will be 1 and TAPE_NR() will also be 1 for /dev/st1. Hence the semaphore SCpnt->request.sem never gets released and open waits forever.
Can somebody please let me know why this comparison is needed ?
regards
vijay
Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/
Quoted 16 lines · vijay srinath
hello all,
I noticed a bug in the scsi tape class driver in kernel 2.2.16/2.4.x.
This is the test that i ran.
1. I have two scsi-fc tape devices
2. I insert the hba driver, so that both the tape devices are enabled and map to st0 and st1
3. I remove the device that maps to st0 using
echo "scsi remove-single-device 0 0 0 0" >/proc/scsi/scsi
4. Now, if i try to do anopen("/dev/st1",..), the process hangs as the open call never returns.The problem seems to be in the callback function
st_sleep_done()where the following comparison is being made
if ((st_nbr=TAPE_NR(SCpnt->request.rq_dev)) < st_template.nr_dev)
{
...
}
Quoted 7 lines
This comparision fails for the above test since
nr_devwill be 1 andTAPE_NR()will also be 1 for/dev/st1. Hence the semaphoreSCpnt->request.semnever gets released and open waits forever.Can somebody please let me know why this comparison is needed ?
The test was inserted a long time ago to be an additional safeguard against problems in the code. In normal operation the interrupt function should never be called with an illegal argument. It seems that the world around the test has evolved so that the test is not working properly any more.
You can just remove the test. I will prepare a patch to fix this bug and send the patch to Linus.
Kai