Description of problem:
Possible Zip drive bug with kernel-2.4.20-13.9.i586.rpm
Think there might be a bug with the above kernel. When mounting a zip
drive, (an ancient parallel port zip drive at that), get an invalid block
device error along with unable to read partition table. Went back to
kernel-2.4.20-6 and have no problems.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Giving to someone on the kernel team.
*** Bug 91171 has been marked as a duplicate of this bug. ***
*** Bug 91001 has been marked as a duplicate of this bug. ***
I am pasting this from another response i got from my post about
the external zip drive problem..maybe this will help you guys out.
PLEASE read the following about what was discovered by a fellow redhat user:
Progress! I think :-) I looked into this and the problem seems to be in the
kernel source file '/usr/src/linux-2.4/drivers/scsi/scsi_error.c'. A line was
added between the 2.4.20-8 and 2.4.20-13.9 kernel versions.
In the file starting at line 464 we have:
/* Last chance to have valid sense data */
memcpy((void *) SCpnt->sense_buffer,
if (scsi_result != &scsi_result0 && scsi_result != NULL)
* When we eventually call scsi_finish, we really wish to complete
* the original request, so let's restore the original data. (DB)
memcpy((void *) SCpnt->cmnd, (void *) SCpnt->data_cmnd,
SCpnt->result = saved_result;
SCpnt->request_buffer = SCpnt->buffer;
SCpnt->request_bufflen = SCpnt->bufflen;
SCpnt->use_sg = SCpnt->old_use_sg;
SCpnt->cmd_len = SCpnt->old_cmd_len;
SCpnt->sc_data_direction = SCpnt->sc_old_data_direction;
SCpnt->underflow = SCpnt->old_underflow;
==> memset(SCpnt->sense_buffer, 0, sizeof(SCpnt->sense_buffer));
The last line was added. I removed this line and rebuilt the kernel, and the zip
drive worked fine. Put it back in, and the drive fails again.
As can be seen the first part of this code snippet states that if the sense data
is invalid then it tries to set it valid using a memcpy. This however gets
overwritten (it seems) by the added memset. Since the intermediate statements
seem to be just assignments and not subroutine/function calls, so the value of
the sense buffer has not (I assume!) been changed since the initial memcpy.
To me this then looks wrong. The sense buffer is set, then overwritten (I think
I read that setting values to 0 make it invalid). From then onwards it seems
that the scsi error handler cannot resolve the 'problem' with the drive so
eventually takes it offline. Of course why the zip drive has invalid sense data
to start with is beyond me, but the 'Last chance' to correct it obviously works
since the zip drive works okay in the 2.4.20-8 kernel. Likewise I assume the
memset was added for a reason, so just removing it will probably break something
else! :-) I could not tell from the kernel changelog why the change was made.
I think this is as far as I can go with this. I hope the RedHat people can make
more sense of it for us :-)
i am using the IMM module for the zip drive. the above mentioned post i had
previously posted the person was also using the imm module..
*** Bug 97177 has been marked as a duplicate of this bug. ***
I have checked the scsi_error.c file from the redhat kernel with the
scsi_error.c file of the tar.gz kernel package from www.kernel.org
and the line commented out that is mentioned above IS NOT in the tar.gz kernel
file from www.kernel.org.
so for some reason redhat has added that line in that file...
i dont think its a bug ...but redhat has some sort of reason why
they added that line....so i think im going to comment out the line so i can
use my zip drive.
Reverting the line seems correct. It was fixing a bug but that bug seems to
actually be in a different driver not the core.
since commenting the line out and recompiling my kernel, my system
has been up and running with no problems for 1 week now...
Just wanted to give an update on my progress..So I believe
that the line should be taken out of upcoming kernels to fix
this problem...It might also help with the other zip problems
also...be it IDE and also with the SMP problems that I
have read on bugzilla about this problem
Would you agree Alan?
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/