thr3ads.net - freebsd stable - trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) [Aug 2008]

If this information is useful, please help other people find it:
Share via:

Torfinn Ingolfsen

2008-Aug-15 21:55 UTC

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

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@music1# uname -a
FreeBSD music1.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 15
12:56:35 CEST 2008     root@music1.kg4.no:/usr/obj/usr/src/sys/GENERIC
i386

root@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@music1# dmesg | grep aic
aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs

root@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@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@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

John Baldwin

2008-Aug-18 14:47 UTC

head link

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

On Friday 15 August 2008 05:55:23 pm Torfinn Ingolfsen
wrote:> 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@music1# uname -a
> FreeBSD music1.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #0: Fri Aug 15
> 12:56:35 CEST 2008     root@music1.kg4.no:/usr/obj/usr/src/sys/GENERIC
> i386
>
> root@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@music1# dmesg | grep aic
> aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs
>
> root@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@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@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?
Can you get the stack trace?
> References:
> 1) http://en.wikipedia.org/wiki/Zip_drive
> 2) http://tingox.googlepages.com/dp-ep-c400_freebsd


-- 
John Baldwin

Torfinn Ingolfsen

2008-Aug-18 17:44 UTC

head link

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

On Mon, 18 Aug 2008 10:33:05 -0400
John Baldwin <jhb@freebsd.org> wrote:
> 
> Can you get the stack trace?
Like this?
root@music1# kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details. This GDB was configured as "i386-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0737b19
stack pointer           = 0x28:0xceb9cbcc
frame pointer           = 0x28:0xceb9cbf8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 42 (syncer)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 24m34s
Physical memory: 307 MB
Dumping 58 MB: 43 27 11

Reading symbols from /boot/kernel/acpi.ko...Reading symbols
from /boot/kernel/acpi.ko.symbols...done. done.
Loaded symbols for /boot/kernel/acpi.ko
#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r"
(td));
(kgdb) 
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0xc078eed7 in boot (howto=260)
#at /usr/src/sys/kern/kern_shutdown.c:418 2  0xc078f199 in panic
#(fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:572
#3  0xc0a9efbc in trap_fatal (frame=0xceb9cb8c, eva=0)
#at /usr/src/sys/i386/i386/trap.c:899 4  0xc0a9f240 in trap_pfault
#(frame=0xceb9cb8c, usermode=0, eva=0)
#at /usr/src/sys/i386/i386/trap.c:812 5  0xc0a9fbec in trap
#(frame=0xceb9cb8c) at /usr/src/sys/i386/i386/trap.c:490 6  0xc0a859ab
#in calltrap () at /usr/src/sys/i386/i386/exception.s:139 7  0xc0737b19
#in g_io_request (bp=0xc299ba50, cp=0xc29b2e00)
#at /usr/src/sys/geom/geom_io.c:364 8  0xc073c116 in g_vfs_strategy
#(bo=0xc29881d4, bp=0xc88efc24) at /usr/src/sys/geom/geom_vfs.c:107 9
#0xc07f97b0 in bufwrite (bp=0xc88efc24) at buf.h:429 10 0xc07f2618 in
#bawrite (bp=0xc88efc24) at buf.h:417 11 0xc07fddaa in vop_stdfsync
#(ap=0xceb9ccd4) at /usr/src/sys/kern/vfs_default.c:479 12 0xc071cbbe
#in devfs_fsync (ap=0xceb9ccd4)
#at /usr/src/sys/fs/devfs/devfs_vnops.c:395 13 0xc0ab3ce2 in
#VOP_FSYNC_APV (vop=0xc0bcf040, a=0xceb9ccd4) at vnode_if.c:1007 14
#0xc080dff8 in sched_sync () at vnode_if.h:538 15 0xc076bc59 in
#fork_exit (callout=0xc080d8f0 <sched_sync>, arg=0x0, frame=0xceb9cd38)
    at /usr/src/sys/kern/kern_fork.c:781
#16 0xc0a85a20 in fork_trampoline ()
#at /usr/src/sys/i386/i386/exception.s:205

Let me know if it was wrong, or if you need something else.
-- 
Regards, 
Torfinn Ingolfsen

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

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

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

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