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): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 */ if (!scsi_sense_valid(SCpnt)) memcpy((void *) SCpnt->sense_buffer, SCpnt->request_buffer, sizeof(SCpnt->sense_buffer)); if (scsi_result != &scsi_result0[0] && scsi_result != NULL) kfree(scsi_result); /* * 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, sizeof(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 persists. 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/