If I try to mount a write protected zip disk[1] 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. I am using csi zip drive (internal) with a scsi card (Adaptec ava-2904) and zip-100 disks. 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 Here is a stack trace: 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 rx0, 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 Note: the zip disk I have used are msdosfs formatted, if that matters. Note2: disks that aren't write protected work fine. References: 1) http://en.wikipedia.org/wiki/Iomega_Zip_drive Fix: none known to submitter at this time. How-To-Repeat: Try to mount a write protected zip disk without the '-r' flag on the mount command.
I once had a quite similar (but somewhat different) issue with FreeBSD 6.2-RELEASE-p6 amd64. The following happened: 1. I inserted into a USB card-reader a write-protected ("locked") miniSD card. 2. Tried to mount it (read-write) and that failed, the following messages appeared in the system log: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 1 19 0 0 8 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): DATA PROTECT csi:0,aa,55,61 asc:27,0 (da0:umass-sim0:0:0:0): Write protected field replaceable unit: 1 (da0:umass-sim0:0:0:0): Unretryable error g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 13 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 0 0 0 1 19 0 0 8 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): DATA PROTECT csi:0,aa,55,61 asc:27,0 (da0:umass-sim0:0:0:0): Write protected field replaceable unit: 1 (da0:umass-sim0:0:0:0): Unretryable error g_vfs_done():da0s1[WRITE(offset=16384, length=4096)]error = 13 fsync: giving up on dirty 0xffffff0020f7f7c0: tag devfs, type VCHR usecount 1, writecount 0, refcount 487 mountedhere 0xffffff00265a5400 flags () v_object 0xffffff00254ef0e0 ref 0 pages 485 dev da0s1 3. Removed the card from the reader and got instant crash. Crash info: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff801e554c stack pointer = 0x10:0xffffffffb17c3a30 frame pointer = 0x10:0xffffffffb17c3a70 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 41 (syncer) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: kdb_backtrace() at 0xffffffff8024f9e7 = kdb_backtrace+0x37 panic() at 0xffffffff80230861 = panic+0x1d1 trap_fatal() at 0xffffffff803b7588 = trap_fatal+0x3a8 trap_pfault() at 0xffffffff803b71ac = trap_pfault+0x24c trap() at 0xffffffff803b6dd3 = trap+0x2f3 calltrap() at 0xffffffff803a158b = calltrap+0x5 --- trap 0xc, rip = 0xffffffff801e554c, rsp = 0xffffffffb17c3a30, rbp = 0xffffffffb17c3a70 --- g_io_request() at 0xffffffff801e554c = g_io_request+0x2c g_vfs_strategy() at 0xffffffff801e8628 = g_vfs_strategy+0x58 bufwrite() at 0xffffffff8028a68c = bufwrite+0x12c bawrite() at 0xffffffff8028adb5 = bawrite+0x15 vop_stdfsync() at 0xffffffff802948e0 = vop_stdfsync+0x1d0 devfs_fsync() at 0xffffffff801ce25b = devfs_fsync+0x2b VOP_FSYNC_APV() at 0xffffffff803f7a7c = VOP_FSYNC_APV+0x4c sync_vnode() at 0xffffffff8029fb02 = sync_vnode+0x192 sched_sync() at 0xffffffff8029fe9c = sched_sync+0x2bc fork_exit() at 0xffffffff80211b0a = fork_exit+0xaa fork_trampoline() at 0xffffffff803a18ee = fork_trampoline+0xe (kgdb) bt #0 doadump () at pcpu.h:172 #1 0xffffffff80230459 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xffffffff80230924 in panic (fmt=0xffffff00799d3720 "\b\032\ry") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xffffffff803b7588 in trap_fatal (frame=0xffffffffb17c3980, eva=0) at /usr/src/sys/amd64/amd64/trap.c:660 #4 0xffffffff803b71ac in trap_pfault (frame=0xffffffffb17c3980, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:573 #5 0xffffffff803b6dd3 in trap (frame= {tf_rdi = -1097678795608, tf_rsi = -1098524564864, tf_rdx = -1098524564816, tf_rcx = 0, tf_r8 = -1317259312, tf_r9 = -1613966144, tf_rax = 2, tf_rbx = -1097678795608, tf_rbp = -1317258640, tf_r10 = 0, tf_r11 = 140737488348584, tf_r12 = -1098524564864, tf_r13 = 0, tf_r14 = -1098958506048, tf_r15 = 2097170, tf_trapno = 12, tf_addr = 0, tf_flags = -1098885697312, tf_err = 0, tf_rip = -2145495732, tf_cs = 8, tf_rflags = 66178, tf_rsp = -1317258688, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:352 #6 0xffffffff803a158b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #7 0xffffffff801e554c in g_io_request (bp=0xffffff006d3ecca8, cp=0xffffff003ad56280) at /usr/src/sys/geom/geom_io.c:299 #8 0xffffffff801e8628 in g_vfs_strategy (bo=0xffffff006d3ecca8, bp=0xffffffff9fcd9d80) at /usr/src/sys/geom/geom_vfs.c:106 #9 0xffffffff8028a68c in bufwrite (bp=0xffffffff9fcd9d80) at buf.h:426 #10 0xffffffff8028adb5 in bawrite (bp=0xffffff006d3ecca8) at buf.h:410 #11 0xffffffff802948e0 in vop_stdfsync (ap=0xffffffffb17c3b80) at /usr/src/sys/kern/vfs_default.c:431 #12 0xffffffff801ce25b in devfs_fsync (ap=0xffffffffb17c3b80) at /usr/src/sys/fs/devfs/devfs_vnops.c:379 #13 0xffffffff803f7a7c in VOP_FSYNC_APV (vop=0x2, a=0xffffff003ad56280) at vnode_if.c:1020 #14 0xffffffff8029fb02 in sync_vnode (bo=0xffffff0020f7f910, td=0xffffff00799d3720) at vnode_if.h:537 #15 0xffffffff8029fe9c in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1698 #16 0xffffffff80211b0a in fork_exit (callout=0xffffffff8029fbe0 <sched_sync>, arg=0x0, frame=0xffffffffb17c3c50) at /usr/src/sys/kern/kern_fork.c:821 #17 0xffffffff803a18ee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 (kgdb) fr 7 #7 0xffffffff801e554c in g_io_request (bp=0xffffff006d3ecca8, cp=0xffffff003ad56280) at /usr/src/sys/geom/geom_io.c:299 299 g_trace(G_T_BIO, "bio_request(%p) from %p(%s) to %p(%s) cmd %d", (kgdb) p pp $5 = (struct g_provider *) 0x0 I think this is a crash that could have been avoided, because it seems that there are no data corruption, only an unchecked situation. -- Andriy Gapon
Responsible Changed From-To: freebsd-i386->freebsd-fs Over to maintainer.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Keyword: crash – in lieu of summary line prefix: [panic] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
^Triage: I'm sorry that this PR did not get addressed in a timely fashion. By now, the version that it was created against is long out of support. Please re-open if it is still a problem on a supported version.