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.