Red Hat Bugzilla – Bug 91480
unable to mount external parallel zip disk sda4 not valid block device
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: i am unable to mount a parrallel port zip disk after i upgraded to the newest kernel, which is 2.4.20-13.9 i was able to mount it previous kernel i had installed 2.4.20-8? i believe... after i insert the proper module into the kernel and try to mount the zip drive i get the following error /dev/sda4 not valid block device Version-Release number of selected component (if applicable): kernel 2.4.20-13.9 How reproducible: Always Steps to Reproduce: 1. if kernel doesnt detech zip disk type following modprobe imm, being that i cant use ppa.o module..i have a newer zip disk that requires the imm.o module 2. mount /dev/sda4 -t vfat /mnt/zip250.0 3. Actual Results: mount: /dev/sda4 is not a valid block device Expected Results: zip drive should mount Additional info:
This is what was listed when i ran dmesg | more I am using a new disk ...so i dont understand why the last line says that i cant read partition table when i first loaded imm..and ran dmesg | more it didnt mention that it couldnt read the partition table SCSI subsystem driver Revision: 1.00 parport0: PC-style at 0x378 [PCSPP,TRISTATE] parport0: device reported incorrect length field (61, should be 62) parport0 (addr 0): SCSI adapter, IMG VP1 imm: Version 2.05 (for Linux 2.4.0) imm: Found device at ID 6, Attempting to use EPP 32 bit imm: Found device at ID 6, Attempting to use PS/2 imm: Communication established at 0x378 with ID 6 using PS/2 scsi0 : Iomega VPI2 (imm) interface Vendor: IOMEGA Model: ZIP 250 Rev: J.45 Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi0, channel 0, id 6, lun 0 scsi: device set offline - not ready or command retry failed after bus reset: ho st 0 channel 0 id 6 lun 0 SCSI device sda: 489532 512-byte hdwr sectors (251 MB) sda: Write Protect is off sda: I/O error: dev 08:00, sector 0 I/O error: dev 08:00, sector 0 unable to read partition table
I can confirm this with an external Iomega zip 100MB drive as well. Confirmed last night: The drive works fine under 2.4.20-8 (the initial redhat linux 9 kernel). The zip disk contained the new '2.4.20-13.9 kernel!; installed new kernel from zip disk; rebooted. Zip drive detected (as seen in dmesg), but trying to access the disk gave the errors reported above. Physically ejected the disk; rebooted to 2.4.20-8; re-inserted disk; tried to access disk and it worked fine. It is definitely a change in the kernel or imm module.
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 :-)
changing component to util-linux.
All the info so far points at the kernel.
Just tried this with the latest released kernel 2.4.20-19.9 and it works fine mounting/unmounting a parallel port zip drive.
this bug has been fixed..by updating to latest kernel
Confirming that it is indeed fixed with the newest errata kernels -19.9/-20.9. It's funny - I just thought my parallel port zip drive had bit the dust. Glad it didn't get discarded!
This bug can now be closed. Fixed after updating to latest kernel.