Getting ATAPI ZIP drive to work under FreeBSD

T

tuclogicguy

I have a 100 MB Zip drive that is connected as a slave device on the secondary IDE channel. When I boot up FreeBSD, I see these messages in /var/log/messages
Code: 
Jun 23 05:05:21 TESTPC kernel: da0 at ata1 bus 0 scbus1 target 1 lun 0
Jun 23 05:05:21 TESTPC kernel: da0: <IOMEGA ZIP 100 03.H> Removable Direct Access SCSI-0 device 
Jun 23 05:05:21 TESTPC kernel: da0: 13.300MB/s transfers (WDMA1, ATAPI 12bytes, PIO 65534bytes)
Jun 23 05:05:21 TESTPC kernel: da0: Attempt to query device size failed: NOT READY, Medium not present

I haven't added anything to /etc/fstab yet because I am still trying to figure out what to put there.

If I just shove a Zip disk into the drive, almost immediately a bunch of message go flying by in the root console. Like these:
Code: 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Error 5, Retries exhausted

Any suggestions on how to get this Zip drive to work?

This is an older machine with a Pentium III processor and 512 MB of memory.
Code: 
uname -a
FreeBSD TESTPC 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 UTC 2012     root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 
tuclogicguy said:
I have a 100 MB ZIP drive that is connected as a slave device on the secondary IDE channel.
Click to expand...
I'll spare you any snide comments about why you'd want to use a 100 MB Zip drive in 2013 - I assume you have a need to recover data from the cartridges or generate new cartridges for some piece of old equipment. However, if this is a one-time thing I'd suggest booting an equally old operating system (MS-DOS 6.22, Windows 95, etc.) as it is probably more tolerant of the Zip drive's many quirks. As modern drivers (regardless of operating system) expanded to handle much newer devices, the code paths that older devices took did not get a lot of regression testing.

When I boot up FreeBSD, I see these messages in /var/log/messages
Code: 
Jun 23 05:05:21 TESTPC kernel: da0: Attempt to query device size failed: NOT READY, Medium not present
Click to expand...
This is perfectly normal. FreeBSD does a "how many of you are in there and how big are you?" inquiry to just about anything with removable media (CD-ROM and newer optical drives, tape drives and libraries, and so on). The message might be a little less scary if "failed" was removed, giving:
Code: 
kernel: da0: Attempt to query device size: NOT READY, Medium not present

I haven't added anything to /etc/fstab yet because I am still trying to figure out what to put there.
Click to expand...
It seems that the (up to 4) MS-DOS partitions will be /dev/da0s1 through /dev/da0s4. You can leave them out of fstab for now - you can always do something like:
Code: 
mount -t msdosfs /dev/da0s1 /mnt
once you get the underlying hardware working.

If I just shove a Zip disk into the drive, almost immediately a bunch of message go flying by in the root console. Like these:
Code: 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Error 5, Retries exhausted
Click to expand...
Ahhh. I think you may be running into something similar to what I alluded to with old code paths above. ATAPI is an emulated SCSI-over-ATA protocol originally intended for CD-ROM devices. Any "SCSI" in there is virtual/emulated SCSI. Which brings up the question, "how can you have a parity error on something that's not real?"

Note that there were external Zip drives with actually semi-unstandard SCSI ports - these were mostly targeted at Mac users, as back then they had a 25-pin equally semi-unstandard port. I believe there was an ISA bridge board for those who wanted to use a SCSI Zip drive on a PC.

Any suggestions on how to get this Zip drive to work?
Click to expand...
Try an old operating system like MS-DOS or Windows 95 on equally old hardware and see if it works there. That will rule out a hardware problem inside the device. These drives were notorious for failing and then destroying any media that was inserted into them - do a search for "click of death".
 
This prompted me to dig out an old IDE Zip drive. The problem there is that it's becoming increasingly difficult to find something with an IDE controller. Connected to a USB to IDE adapter, it is detected but a disk device is not created in /dev.
 
The Zip drive works under Windows 98, Puppy Linux and Knoppix. The question is how to get it working under FreeBSD. When I enter that mount command, I get
Code: 
mount -t msdosfs /dev/da0s1 /mnt
mount_msdosfs: /dev/da0s1: No such file or directory

Any other suggestions? I wonder if I need to compile a custom kernel?
 
tuclogicguy said:
The Zip drive works under Windows 98, Puppy Linux and Knoppix. The question is how to get it working under FreeBSD. When I enter that mount command, I get
Code: 
mount -t msdosfs /dev/da0s1 /mnt
mount_msdosfs: /dev/da0s1: No such file or directory

Any other suggestions? I wonder if I need to compile a custom kernel?
Click to expand...
As @wblock@ noted, just above:
Connected to a USB to IDE adapter, it is detected but a disk device is not created in /dev.
Click to expand...
Which translates exactly to:
Code: 
mount_msdosfs: /dev/da0s1: No such file or directory
ls /dev will show you what/which devices actually exist at the moment you issue that command. But those listings (devices, in this case) are dynamic. Meaning; devices are created on an as-needed/as attached basis. I have found that re-issuing that same mount(8) command again, sometimes will result in a successful mount. Often with old, or "flakey"/unsupported devices. FreeBSD device drivers will attempt (successfully) to create something that will work. But be warned; in these circumstances, data integrity should, at best, be circumspect (not trusted).

HTH

--chris
 
Last edited by a moderator:
I also have that rarest of rare things, a USB Zip drive. It did create a da0 device, but went into an endless cycle of read errors and retries when a disk was loaded.

Amazingly, on a Windows XP system it reads the disk fine, showing stuff I put there in 2000. So the disk is good. If I can find a working IDE controller to put in that machine, I can try the IDE drive.

The IDE Zip drive worked fine on a Windows XP machine also. It may be the prehistoric Zip drives just need some quirks added.

Booting mfsBSD on the system with the IDE Zip drive directly connected has the drive working. It created the da0 device immediately. After loading a disk, # true > /dev/da0 forced retasting of the device, and the disk could be mounted and viewed.
 
ls /dev doesn't show any devices with da0xxx, so apparently just /dev/da0 is the device name I should use. Every time I issue mount -t msdosfs /dev/da0 /mnt/zip I get a slew of these messages:
Code: 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Retrying command (per sense data)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): READ(6). CDB: 8 0 0 0 9 0 
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): CAM status: SCSI Status Error
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI status: Check Condition
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
Jul 16 16:22:31 TESTPC kernel: (da0:ata1:0:1:0): Error 5, Retries exhausted
followed by
Code: 
mount_msdosfs: /dev/da0: Input/output error
Issuing the mount command multiple times doesn't help.

Issuing true > /dev/da0, followed by some more mount attempts, didn't work either.

I wonder if there is some parameter/attribute/whatever I can feed to the kernel to tell it not to even check parity on this device.

I wonder if I would have better luck with the 8.4 kernel. (I am using 9.1-RELEASE.)
 
so apparently just /dev/da0 is the device name I should use
Click to expand...
Actually, da0 is the root (not as in mount point) device for the attached devices. Not unlike usb connectors, which are treated/considered "hubs", for all the devices plugged-in/connected-to. So until a drive is recognized, and the proper driver is then loaded for it. You will not see the additional appendages to the root device da0; as in da0s1.

As memory serves, @wblock@ runs a 9.x system. Perhaps he'll be able to chime in, and share his method for accomplishing it.

--chris
 
Last edited by a moderator:
I'm doing some work on current compatibility for Zip drives (on the basis people might want to recover data) but I can't test your scenario right now. What might be worth noting is that the SCSI Zip drive Terry mentioned with the weird 25-pin connectors do actually work on things other than a Mac without the need for an adapter - it's standard SCSI. All you need to do is wire the 25-way D plug to a standard 50-way. (Yes, I did it!). There are a couple of switches on the back; one switches in terminating resistors and the other selects one of two IDs (not the full eight). I found it worked best as the last device in the chain.

Iomega did have a cheap AT-bus SCSI host adapter with a 25-pin connector for using it with a PC - IIRC it was an basically an Adaptec 1510. If I find an AT-bus PC to test it with I'll met you know :)
 
Here's what I did:

  • Install Promise Ultra66 on a Dell Optiplex 330, because it has no native IDE.
  • Connect IDE Zip drive jumpered for cable select with 80-wire IDE cable.
  • Connect external power supply with Molex connector to Zip drive because Dell could not be bothered to include a single Molex connector.
  • PXE boot mfsBSD, the FreeBSD 9.1-RELEASE amd64 version.
From dmesg(8):
Code: 
da0: <IOMEGA ZIP 100 13.A> Removable Direct Access SCSI-0 device
da0: 3.300MB/s transfers (PIO0, ATAPI 12bytes, PIO 65534bytes)
da0: Attempt to query device size failed: NOT READY, Medium not present

/dev/da0 exists.

Load a disk, # true > /dev/da0 to force retasting.

ls /dev/da0*
Code: 
/dev/da0        /dev/da0s4

# file -s /dev/da0s4
Code: 
/dev/da0s4: x86 boot sector, Microsoft Windows 98 Bootloader IO.SYS+MSDOS.SYS, code offset 0x3c, OEM-ID "**X`~IHC" cached by Windows 9M, sectors/cluster 4, root
 entries 512, Media descriptor 0xf8, sectors/FAT 192, heads 64, hidden sectors 32, sectors 196576 (volumes > 32 MB) , serial number 0x14f5391b, label: "ZIP-100   ", FAT (16 bit)

It can be mounted or used normally, no problems.

This is the same IDE drive that could not be used with a USB to IDE adapter. Same disk, too.
 
I have an ATAPI Zip drive running under FreeBSD 9.1. If nothing else, something about partition detection misses these drives. If I want to use a Zip disk under FreeBSD, I place the disk in the drive, then boot FreeBSD. I can remove the disk, too, but the partition mapping stays the same, at least according to the entries in /dev.

Note that I'm avoiding the CAM and ATAPICAM stuff in the kernel so I can play audio CDs without the PC halting to a Trap 12 or something like that. In other words, I'm using older drivers, accessing the hard drive by ad0 instead of ada0 and the like. It may make a difference. Try the first idea a few times before going the extreme route, though.
 
Partitions are only read when the drive is initially probed or on retasting. That's what # true > /dev/da0 does. It opens the drive for write, but doesn't write anything. GEOM then retastes the media, updating the partition information for it in /dev.

CAM and ATAPICAM should not cause problems, and certainly not enough to go back to using outdated drivers. If there are repeatable problems, please enter a PR to get them fixed.
 
I jumpered my IDE Zip drive for cable select and moved it to the slave position on the primary IDE channel, where it is slave to the hard disk. Both devices are on an 80-wire IDE cable. /var/log/messages shows:
Code: 
da0 at ata0 bus 0 scbus0 target 1 lun 0
da0: <IOMEGA ZIP 100 03.H> Removable Direct Access SCSI-0 device
da0: 13.300MB/s transfers (WDMA1, ATAPI 12bytes, PIO 65534bytes)
da0: Attempt to query device size failed: NOT READY, Medium not present
These are essentially the messages I was getting before, except the Zip drive is now on ata0 bus0 instead of ata1 bus0, as expected.

I shove in a Zip disk. Lots of messages go flying by:
Code: 
(da0:ata0:0:1:0): READ(6). CDB: 8 0 0 0 4 0 
(da0:ata0:0:1:0): CAM status: SCSI Status Error
(da0:ata0:0:1:0): SCSI status: Check Condition
(da0:ata0:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
(da0:ata0:0:1:0): Retrying command (per sense data)
(da0:ata0:0:1:0): READ(6). CDB: 8 0 0 0 4 0 
(da0:ata0:0:1:0): CAM status: SCSI Status Error
(da0:ata0:0:1:0): SCSI status: Check Condition
(da0:ata0:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
(da0:ata0:0:1:0): Retrying command (per sense data)
(da0:ata0:0:1:0): READ(6). CDB: 8 0 0 0 4 0 
(da0:ata0:0:1:0): CAM status: SCSI Status Error
(da0:ata0:0:1:0): SCSI status: Check Condition
(da0:ata0:0:1:0): SCSI sense: HARDWARE FAILURE asc:47,0 (SCSI parity error)
...
ls /dev/da0* returns just
Code: 
/dev/da0
I try true > /dev/da0. More of the "SCSI sense: HARDWARE FAILURE" messages go flying by. ls /dev/da0* still returns just
Code: 
/dev/da0

This is with a Pentium III processor in an Intel D815EEA2 motherboard. Some differences between my setup and @wblock@'s are that I'm using the i386 OS version (obviously) and am using the onboard IDE controller.

I wonder if I would have better luck with the 8.4-RELEASE version with this old hardware?
 
Last edited by a moderator:
It may just be a bad disk. And as far as I remember, that "click of death" could spread. A bad disk would ruin a drive, which would then ruin other disks, and so on.
 
Well, I'm finally making some progress. In addition to the Pentium III machine, where I was trying to get FreeBSD to work, I also have a Pentium 4 machine, which also has an IDE Zip drive. I downloaded and tried mfsbsd-8.3-RELEASE-i386. I tried booting it on both the P3 and P4 machines. It wouldn't recognize the Zip drive on either machine at all. No /dev/da0 device got defined.

Next, I tried mfsbsd-9.1-RELEASE-p2-i386. I booted it on the P4 machine. It recognized the Zip drive. I shoved in a Zip disk. No error messages. I tried true > /dev/da0. I could hear some activity in the Zip drive, no error messages to the console, and when I did ls /dev/da0*, it showed two devices:
Code: 
/dev/da0     /dev/da0s4
I tried to mount /dev/da0s4 and that worked. I could access the contents of the Zip disk.

I tried the same mfsbsd-9.1-RELEASE-p2-i386 CD in my P3 machine and it behaved the same as my hard disk installation. Lots of errors messages to the console when I try to mount a Zip disk.

So, which is the culprit? The P4 machine vs. the P3 machine, or one Zip drive vs. the other? I tried swapping Zip drives between the two machines. Now the Zip drive works under FreeBSD on the P3 machine and fails on the P4 machine. Strange... that same Zip drive works fine under Windows 98, Windows XP, Puppy Linux, Knoppix, SystemRescueCD, etc., but not FreeBSD. But, at least I have a hardware combination that works now.

(Now, if I could just get the Radeon video driver to work on that P3 machine... See my other thread over in the Xorg forum, if anybody's interested.)
 
Possibly a hardware or firmware revision is not quite supported on the bad drive. It's kind of amazing that these drives are over a decade old, and let's face it, were not the greatest thing even in their day, and yet they still work. Mine had not been run in at least five or six years, maybe since 2002 or so.
 
To add a bit to the things already discussed. My last run with a Zip drive was under FreeBSD 7.0-STABLE (I still keep the machine in case I find more Zip disks to recover). The Zip drive I use is the SCSI version, connected to an Adaptec AVA-2904 controller card.

My work process looks like this: boot with a Zip disk in the drive (in order to get the /dev/da0s? nodes created). To use a Zip disk do:
  1. physically insert a Zip disk in the drive
  2. camcontrol load da0
  3. camcontrol tur da0 (repeat until you get "unit ready")
  4. mount -r -t msdosfs /dev/da0s4 /mnt
After you're done with the disk do:
  1. umount /mnt
  2. camcontrol eject da0
That's all.
 
I remember that the IDE Zip drives were notoriously difficult to get working on motherboards that didn't have Intel CPUs and Intel chipsets.
 
wblock@ said:
Possibly a hardware or firmware revision is not quite supported on the bad drive.
Click to expand...

Aha! Comparing my bad and good Zip drives with pictures of various Zip drives being sold on eBay, it appears that my Zip drive that doesn't work under FreeBSD was originally built for a Mac. So, yes, maybe the firmware is different.
 
I wonder if there is a way to get this IDE Zip drive to be recognized by the 8.4 version of the kernel. Some option to feed to the kernel when booting? Load an extra module? Recompile the kernel for my particular hardware?
 
You must log in or register to reply here.
Back
Top