trying to mount a write prptected zip disk panics the machine (unless the -r flag is used)

Torfinn Ingolfsen torfinn.ingolfsen at broadpark.no
Fri Aug 15 21:55:26 UTC 2008


Hello,

Do you remember the zip[1] disks? The original 100 Mbyte ones? well
recently, I got a scsi zip drive (internal) with a scsi card (Adaptec
ava-2904) and some zip-100 disks, and a request to try to copy the data
from those disks. I found a cable, installed the card and zip drive
in a machine[2] running FreeBSd 7.0-stable, and luckily the zip disks could
be read.

But during this process I discovered one thing; if I try to mount a
write protected zip disk without using the '-r' flag to the mount
command, my machine will panic a few seconds later. As there is no visual
indication to tell you that a zip disk is  write protected, it is quite easy to forget
mounting it read only.

Note: using zip disks that aren't write protected works fine.

Details:
root at music1# uname -a
FreeBSD music1.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 15
12:56:35 CEST 2008     root at music1.kg4.no:/usr/obj/usr/src/sys/GENERIC
i386

root at music1# dmesg | grep ahc
ahc0: <Adaptec 2902/04/10/15/20C/30C SCSI adapter> port 0x1400-0x14ff mem 0x5c100000-0x5c100fff irq 10 at device 15.0 on pci0
ahc0: Host Adapter Bios disabled.  Using default SCSI device parameters
ahc0: [ITHREAD]
da0 at ahc0 bus 0 target 5 lun 0
root at music1# dmesg | grep aic
aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs

root at music1# dmesg | grep da0
da0 at ahc0 bus 0 target 5 lun 0
da0: <IOMEGA ZIP 100 E.08> Removable Direct Access SCSI-2 device 
da0: 3.300MB/s transfers
da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C)

This is what I got on the console (and in /var/log/messages) when I tried to mount the disk:
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): WRITE(06). CDB: a 0 0 21 8 0 
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): CAM Status: SCSI Status Error
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Write protected
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error
Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, length=4096)]error = 13
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): WRITE(06). CDB: a 0 0 21 8 0 
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): CAM Status: SCSI Status Error
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): SCSI Status: Check Condition
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): DATA PROTECT asc:27,0
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Write protected
Aug 15 20:14:33 music1 kernel: (da0:ahc0:0:5:0): Unretryable error
Aug 15 20:14:33 music1 kernel: g_vfs_done():da0s4[WRITE(offset=512, length=4096)]error = 13
Aug 15 20:14:33 music1 kernel: fsync: giving up on dirty
Aug 15 20:14:33 music1 kernel: 0xc2988114: tag devfs, type VCHR
Aug 15 20:14:33 music1 kernel: usecount 1, writecount 0, refcount 27 mountedhere 0xc2617700
Aug 15 20:14:33 music1 kernel: flags ()
Aug 15 20:14:33 music1 kernel: v_object 0xc299707c ref 0 pages 25
Aug 15 20:14:33 music1 kernel: 
Aug 15 20:14:33 music1 kernel: dev da0s4
Aug 15 20:14:34 music1 kernel: GEOM_LABEL: Label for provider da0s4 is msdosfs/DIPLOM.

A few seconds went by, and then the machine panic'ed with apage fault:
root at music1# more /var/crash/info.0
Dump header from device /dev/ad0s1b
  Architecture: i386
  Architecture Version: 2
  Dump Length: 60837888B (58 MB)
  Blocksize: 512
  Dumptime: Fri Aug 15 20:15:03 2008
  Hostname: music1.kg4.no
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 7.0-STABLE #0: Fri Aug 15 12:56:35 CEST 2008
    root at music1.kg4.no:/usr/obj/usr/src/sys/GENERIC
  Panic String: page fault
  Dump Parity: 2682527093
  Bounds: 0
  Dump Status: good

(crash dump, 58 Mbyte, available on request).

Is this how it is supposed to be, or should I file a PR?

References:
1) http://en.wikipedia.org/wiki/Zip_drive
2) http://tingox.googlepages.com/dp-ep-c400_freebsd
-- 
Regards,
Torfinn Ingolfsen,
Norway



More information about the freebsd-stable mailing list