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