Bug 91480 - unable to mount external parallel zip disk sda4 not valid block device
unable to mount external parallel zip disk sda4 not valid block device
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-22 22:34 EDT by chrisw
Modified: 2005-10-31 17:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-16 20:40:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description chrisw 2003-05-22 22:34:06 EDT
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:
Comment 1 chrisw 2003-05-23 00:25:04 EDT
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
Comment 2 John Horne 2003-05-29 06:02:08 EDT
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.
Comment 3 John Horne 2003-06-05 05:59:55 EDT
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 :-)


Comment 4 Brian Brock 2003-07-14 11:55:56 EDT
changing component to util-linux.
Comment 5 Elliot Lee 2003-07-14 13:29:54 EDT
All the info so far points at the kernel.
Comment 6 John Horne 2003-07-24 05:50:20 EDT
Just tried this with the latest released kernel 2.4.20-19.9 and it works fine
mounting/unmounting a parallel port zip drive.
Comment 7 chrisw 2003-08-20 16:59:26 EDT
this bug has been fixed..by updating to latest kernel
Comment 8 Michael Lee Yohe 2003-08-22 12:06:44 EDT
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!
Comment 9 chrisw 2003-09-03 12:44:31 EDT
This bug can now be closed. Fixed after updating to latest kernel.

Note You need to log in before you can comment on or make changes to this bug.