I can't remember if this was the behavior with older versions, the last time I had a drive fail on FreeBSD. But it seems to me that the I/O request should just fail and things go on as usual, especially on a non-system drive. So, is this a bug or correct behavior? With 6.2-PRERELEASE and a separate data only ata(4) drive, it continuously panics when it encounters a bad block on the drive. I had dumps turned on, so here's a backtrace when inspecting the coredump. [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol "ps_pglobal_lookup"] 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: panic: vinvalbuf: dirty bufs cpuid = 1 Uptime: 50m21s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130784 pages) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x21310004 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0448701 stack pointer = 0x28:0xd44b2c78 frame pointer = 0x28:0xd44b2ca4 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 = 16 (swi2: cambio) trap number = 12 panic: page fault cpuid = 1 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc053cd31 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:409 #2 0xc053d124 in panic (fmt=0xc07c1ebe "vinvalbuf: dirty bufs") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc05aacc3 in bufobj_invalbuf (bo=0xc362fb60, flags=1, td=0x0, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1028 #4 0xc05ab032 in vinvalbuf (vp=0xc362faa0, flags=0, td=0x0, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1095 #5 0xc05ae374 in vgonel (vp=0xc362faa0) at /usr/src/sys/kern/ vfs_subr.c:2449 #6 0xc05ae248 in vgone (vp=0xc362faa0) at /usr/src/sys/kern/ vfs_subr.c:2404 #7 0xc04de056 in devfs_delete (dm=0xc359be00, de=0xc35a3380) at /usr/src/sys/fs/devfs/devfs_devs.c:244 #8 0xc04de2ca in devfs_populate_loop (dm=0xc359be00, cleanup=0) at /usr/src/sys/fs/devfs/devfs_devs.c:352 #9 0xc04de575 in devfs_populate (dm=0xc359be00) at /usr/src/sys/fs/devfs/devfs_devs.c:448 #10 0xc04e07f2 in devfs_lookupx (ap=0x0) at /usr/src/sys/fs/devfs/devfs_vnops.c:512 #11 0xc04e098e in devfs_lookup (ap=0xd5d00998) at /usr/src/sys/fs/devfs/devfs_vnops.c:576 #12 0xc078df94 in VOP_LOOKUP_APV (vop=0xc07f2340, a=0xd5d00998) at vnode_if.c:99 #13 0xc05a386b in lookup (ndp=0xd5d00bc0) at vnode_if.h:56 ---Type <return> to continue, or q <return> to quit--- #14 0xc05a2fd8 in namei (ndp=0xd5d00bc0) at /usr/src/sys/kern/ vfs_lookup.c:211 #15 0xc05bbecd in vn_open_cred (ndp=0xd5d00bc0, flagp=0xd5d00cc0, cmode=420, cred=0xc35cd680, fdidx=9) at /usr/src/sys/kern/vfs_vnops.c:126 #16 0xc05bbe53 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:91 #17 0xc05b2998 in kern_open (td=0xc344b480, path=0x0, pathseg=UIO_USERSPACE, flags=522, mode=438) at /usr/src/sys/kern/vfs_syscalls.c:1005 #18 0xc05b2886 in open (td=0x0, uap=0xd5d00d04) at /usr/src/sys/kern/vfs_syscalls.c:969 #19 0xc0778e20 in syscall (frame= {tf_fs = 672661563, tf_es = 146604091, tf_ds = -1078001605, tf_edi = 8, tf_esi = 674142680, tf_ebp = -1077941592, tf_isp = -707785372, tf_ebx = 674051392, tf_edx = 0, tf_ecx = 0, tf_eax = 5, tf_trapno = 0, tf_err = 2, tf_eip = 673930243, tf_cs = 51, tf_eflags = 518, tf_esp = -1077941636, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #20 0xc07619df in Xint0x80_syscall () at /usr/src/sys/i386/i386/ exception.s:200 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)Received on Thu Nov 30 2006 - 02:46:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:03 UTC