panic: vinvalbuf: dirty bufs
Attached is the stack...
I was trying to back up a DVD (acd0) to a file-system (on ad8). According to
the ``systat 1 -vm'' window frozen on my screen, the system was processing an
awful lot of interrupts, when it paniced.
I have the entire vmcore. Attached is the debugger's stack of it. The kernel
is 6.3-PRERELEASE as of Dec 30th.
Please, advise. Thanks,
-mi
Unread portion of the kernel message buffer:
panic: vinvalbuf: dirty bufs
cpuid = 0
Uptime: 7d3h6m7s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 (CTRL-C to abort) (CTRL-C to abort)
(CTRL-C to abort) 687 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort)
671 655 639 623 607 591 575 559 543 527 511 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
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 amd64-marcel-freebsd...
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x802b9a47 in boot (howto=260)
at /var/src/sys/kern/kern_shutdown.c:409
#3 0x802ba0e1 in panic (fmt=0xff00597f54c0 )
at /var/src/sys/kern/kern_shutdown.c:565
#4 0x80324a3f in bufobj_invalbuf (bo=0xff0016f58910, flags=1,
td=0xff00597f54c0, slpflag=0, slptimeo=0)
at /var/src/sys/kern/vfs_subr.c:1032
#5 0x80327657 in vgonel (vp=0xff0016f587c0)
at /var/src/sys/kern/vfs_subr.c:2453
#6 0x803286ae in vgone (vp=0xff0016f587c0)
at /var/src/sys/kern/vfs_subr.c:2408
#7 0x80267fad in devfs_delete (dm=0xff0005bf2900,
de=0xff0012557d00, vp_locked=0)
at /var/src/sys/fs/devfs/devfs_devs.c:265
#8 0x80268576 in devfs_populate_loop (dm=0xff0005bf2900,
cleanup=0) at /var/src/sys/fs/devfs/devfs_devs.c:384
#9 0x802685d9 in devfs_populate (dm=0xff0005bf2900)
at /var/src/sys/fs/devfs/devfs_devs.c:486
#10 0x8026ace4 in devfs_lookup (ap=0x0)
at /var/src/sys/fs/devfs/devfs_vnops.c:587
#11 0x8046838d in VOP_LOOKUP_APV (vop=0x805e6900,
a=0xd52f68a0) at vnode_if.c:99
#12 0x8031d9b5 in lookup (ndp=0xd52f6a20) at vnode_if.h:56
#13 0x8031e6e5 in namei (ndp=0xd52f6a20)
at /var/src/sys/kern/vfs_lookup.c:216
#14 0x8032fe04 in kern_stat (td=0xff00597f54c0, path=0x0,
pathseg=UIO_USERSPACE, sbp=0xd52f6af0)
at /var/src/sys/kern/vfs_syscalls.c:2077
#15 0x8032ff87 in stat (td=0x0, uap=0xd52f6bc0)
at /var/src/sys/kern/vfs_syscalls.c:2061
#16 0x8041e431 in syscall (frame=
{tf_rdi = 4620026, tf_rsi = 140737488350224, tf_rdx = 1200063540, tf_rcx
= 34378002812, tf_r8 = -2141280448, tf_r9 = 140737488350168, tf_rax = 188,
tf_rbx = 0, tf_rbp = 5763328, tf_r10 = -1098187407360, tf_r11 = 582, tf_r12 =
140737488350224, tf_r13 = 1200063360, tf_r14 = 0, tf_r15 = 0, tf_trapno = 22,
tf_addr = 0, tf_flags = 140737488247792, tf_err = 2, tf_rip = 34378002748,
tf_cs = 43, tf_rflags = 582, tf_rsp = 140737488350200, tf_ss = 35})
at /var/src/sys/amd64/amd64/trap.c:807
#17 0x80403938 in Xfast_syscall ()
at /var/src/sys/amd64/amd64/exception.S:287
#18 0x00080116b13c in ?? ()
(kgdb) ___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: vinvalbuf: dirty bufs
I was ripping one CD (SCSI CD-drive) and inserting another CD into an ATA CD-DRIVE. Suddenly the machine paniced... Although I have the crash dump, it seems corrupted -- kgdb can't print out the stack. The panic is: vinvalbuf: dirty bufs. Please, advise. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic(): vinvalbuf: dirty bufs: perhaps a ffs_syncvnode bug?
On Thu, Nov 16, 2006 at 09:24:07AM +0100, Rink Springer wrote: Over the night, we reset the shelf in order to activate its new management IP address, causing the /dev/da[12] devices to be temporarily unavailable. This resulted in the following panic on the rather busy mailstorage server (the other server has minor load and was fine): --- (da0:isp0:0:1:0): lost device (da0:isp0:0:1:0): removing device entry (da1:isp0:0:2:0): lost device g_vfs_done():da1s1[WRITE(offset=292316823552, length=16384)]error = 6 g_vfs_done():da1s1[WRITE(offset=240287318016, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=12175362048, length=2048)]error = 6 g_vfs_done():da1s1[WRITE(offset=240287318016, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=18370689024, length=2048)]error = 6 g_vfs_done():da1s1[READ(offset=25829486592, length=512)]error = 6 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 78035 (lmtpd) g_vfs_done():da1s1[WRITE(offset=240287318016, length=1638(da1:isp0:0:2:0): Invalidating pack 4)]error = 6 g_vfs_done():da1s1[READ(offset=13768671232, length=6144)]error = 6 g_vfs_done():da1s1[READ(offset=102126977024, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=13768671232, length=6144)]error = 6 g_vfs_dpone():da1s1[READ(offset=102319669248, length=16384)]error = 6a nic: vinvalbuf: dirty bufs cpuid = 2 Uptime: 54d15h48m38s When looking at the source code of vinvalbuf(), which calls bufobj_invalbuf(), it seems that this panic is raised after a bufobj still contains dirty data after waiting for it to complete without error. The code can be found at /sys/kern/vfs_subr.c Note that this panic can only occur if vinvalbuf() is called with V_SAVE (save modified data first). The exact condition for the panic is better described as: a bufobj still contains dirty data or still has output in progress after a successful synchronous BO_SYNC operation. bufobj_wwait() cannot return an error unless msleep() fails (e.g. interruptible sleep requested via slpflag and signal occured). If the I/O has failed, bufobj_wwait() will return success. The sync routine called eventually translates to bufsync(), as in /sys/kern/vfs_bio.c, which calls the filesystem's sync routine. It seems as if the return status of vfs_bio_awrite() in ffs_syncvnode() is not checked; all the other parts are checked. I believe this could provoke this panic. There does not seem much point in checking an asynchronous write result anyway, as the I/O is not completed yet. I don't understand well what the code is doing with async writes. For all but the last pass (see further), it will call bawrite() on the buffer, which sets B_ASYNC then calls bwrite(). For the last pass, it calls bwrite() directly (has something cleared B_ASYNC?), and returns an error if it fails. bwrite() itself is an inline function defined in /sys/sys/buf.h, which calls BO_WRITE after some KASSERTs. As the machine is in production use, it was instantly rebooted by a collegue and thus I have no vmcore, backtrace or anything. I therefore hope the information provided here is adequate. Can someone with more FreeBSD-VFS knowledge please look at this? There is another possible problem, from this comment in /sys/ufs/ffs/ffs_vnops.c ffs_syncvnode(): /* * Block devices associated with filesystems may * have new I/O requests posted for them even if * the vnode is locked, so no amount of trying will * get them clean. Thus we give block devices a * good effort, then just give up. For all other file * types, go around and try again until it is clean. */ Actually it just does NIADDR + 1 (four) passes and then gives up. If DIAGNOSTIC is enabled, it will then print the affected vnode, if it is not a disk. This failure is not reflected in ffs_syncvnode()'s return value, so if it occurs when ffs_syncvnode() is called from bufobj_invalbuf(), a panic will result. Suppose ffs_syncvnode() would be changed to return some error in this case. bufobj_invalbuf()/vinvalbuf() will handle a BO_SYNC/ffs_syncvnode() error by aborting with an error return. It seems that in most cases this will cause the operation invoking the vinvalbuf() to fail. However, in at least one case (vm_object_terminate()), the error will be ignored; this may cause old garbage/dangling references? -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic(): vinvalbuf: dirty bufs: perhaps a ffs_syncvnode bug?
Hi people, At work, some storage is put on a SUN StorEdge 3510 FibreChannel array; the disks are divided into two volumes, which are mounted using isp(4) controllers. Two seperate machines each mount a single volume (this is, box1 mounts the first volume (/dev/da1), and box2 mounts the second volume (/dev/da2)). Both volumes are formatted using UFS2. Over the night, we reset the shelf in order to activate its new management IP address, causing the /dev/da[12] devices to be temporarily unavailable. This resulted in the following panic on the rather busy mailstorage server (the other server has minor load and was fine): --- (da0:isp0:0:1:0): lost device (da0:isp0:0:1:0): removing device entry (da1:isp0:0:2:0): lost device g_vfs_done():da1s1[WRITE(offset=292316823552, length=16384)]error = 6 g_vfs_done():da1s1[WRITE(offset=240287318016, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=12175362048, length=2048)]error = 6 g_vfs_done():da1s1[WRITE(offset=240287318016, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=18370689024, length=2048)]error = 6 g_vfs_done():da1s1[READ(offset=25829486592, length=512)]error = 6 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 78035 (lmtpd) g_vfs_done():da1s1[WRITE(offset=240287318016, length=1638(da1:isp0:0:2:0): Invalidating pack 4)]error = 6 g_vfs_done():da1s1[READ(offset=13768671232, length=6144)]error = 6 g_vfs_done():da1s1[READ(offset=102126977024, length=16384)]error = 6 g_vfs_done():da1s1[READ(offset=13768671232, length=6144)]error = 6 g_vfs_dpone():da1s1[READ(offset=102319669248, length=16384)]error = 6a nic: vinvalbuf: dirty bufs cpuid = 2 Uptime: 54d15h48m38s kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x56 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0681303 stack pointer = 0x28:0xe8d973f0 frame pointer = 0x28:0xe8d973f8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 78066 (lmtpd) trap number = 12 --- When looking at the source code of vinvalbuf(), which calls bufobj_invalbuf(), it seems that this panic is raised after a bufobj still contains dirty data after waiting for it to complete without error. The code can be found at /sys/kern/vfs_subr.c The sync routine called eventually translates to bufsync(), as in /sys/kern/vfs_bio.c, which calls the filesystem's sync routine. It seems as if the return status of vfs_bio_awrite() in ffs_syncvnode() is not checked; all the other parts are checked. I believe this could provoke this panic. As the machine is in production use, it was instantly rebooted by a collegue and thus I have no vmcore, backtrace or anything. I therefore hope the information provided here is adequate. Can someone with more FreeBSD-VFS knowledge please look at this? Thanks! -- Rink P.W. Springer- http://rink.nu It's you isn't it? THE BASTARD OPERATOR FROM HELL! In the flesh, on the phone and in your account... - BOFH #3 smime.p7s Description: S/MIME cryptographic signature
Re: panic: vinvalbuf: dirty bufs on 6.1-RC
On Tue, 2006-Apr-11 16:28:18 -0400, Kris Kennaway wrote: Don't do that :( It's a well-known limitation that FreeBSD doesn't handle devices with mounted filesystems spontaneously disappearing. Patches to fix this would be welcomed with open arms. -- Peter Jeremy pgpm0U529E6AX.pgp Description: PGP signature
panic: vinvalbuf: dirty bufs on 6.1-RC
Hello,
I have faced a panic when I use external HDD with USB interface after
disconnect mounted drive:
# uname -a
FreeBSD hius.citrin.ru 6.1-RC FreeBSD 6.1-RC #0: Sun Apr 9 11:51:55 MSD 2006
[EMAIL PROTECTED]:/data/usr/obj/data/usr/src/sys/NK i386
# kgdb -c /var/crash/vmcore.0 kernel.debug
[...]
Unread portion of the kernel message buffer:
panic: vinvalbuf: dirty bufs
Uptime: 1d11h18m11s
(da0:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status ==
0x0
Dumping 125 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 125MB (31984 pages) 109 93 77 61 45 29 13
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
During symbol reading, Incomplete CFI data; unspecified registers at 0xc050c371.
#1 0xc050c879 in boot (howto=0x104) at
/data/usr/src/sys/kern/kern_shutdown.c:402
#2 0xc050cb54 in panic (fmt=0xc06a6812 vinvalbuf: dirty bufs) at
/data/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc056a246 in bufobj_invalbuf (bo=0xc1b90a50, flags=0x1, td=0xc17d3780,
slpflag=0x0, slptimeo=0x0)
at /data/usr/src/sys/kern/vfs_subr.c:1011
#4 0xc056a4bd in vinvalbuf (vp=0xc1b90990, flags=0x1, td=0xc17d3780,
slpflag=0x0, slptimeo=0x0)
at /data/usr/src/sys/kern/vfs_subr.c:1078
#5 0xc056d03d in vgonel (vp=0xc1b90990) at
/data/usr/src/sys/kern/vfs_subr.c:2432
#6 0xc056cf56 in vgone (vp=0xc1b90990) at
/data/usr/src/sys/kern/vfs_subr.c:2387
#7 0xc04b8140 in devfs_delete (dm=0xc1628080, de=0xc1a74b00) at
/data/usr/src/sys/fs/devfs/devfs_devs.c:244
#8 0xc04b8374 in devfs_populate_loop (dm=0xc1628080, cleanup=0x0) at
/data/usr/src/sys/fs/devfs/devfs_devs.c:352
#9 0xc04b85da in devfs_populate (dm=0xc1628080) at
/data/usr/src/sys/fs/devfs/devfs_devs.c:448
#10 0xc04ba54b in devfs_lookupx (ap=0x0) at
/data/usr/src/sys/fs/devfs/devfs_vnops.c:512
#11 0xc04ba6a7 in devfs_lookup (ap=0xcc3859c8) at
/data/usr/src/sys/fs/devfs/devfs_vnops.c:576
#12 0xc0684723 in VOP_LOOKUP_APV (vop=0xc06cd780, a=0xcc3859c8) at vnode_if.c:99
#13 0xc0564315 in lookup (ndp=0xcc385bcc) at vnode_if.h:56
#14 0xc0563b86 in namei (ndp=0xcc385bcc) at
/data/usr/src/sys/kern/vfs_lookup.c:203
#15 0xc0578ddb in vn_open_cred (ndp=0xcc385bcc, flagp=0xcc385ccc, cmode=0x100,
cred=0xc1a1ce00, fdidx=0x3)
at /data/usr/src/sys/kern/vfs_vnops.c:125
#16 0xc0578d6e in vn_open (ndp=0x0, flagp=0xcc385ccc, cmode=0x100, fdidx=0x3)
at /data/usr/src/sys/kern/vfs_vnops.c:91
#17 0xc0570f1c in kern_open (td=0xc17d3780, path=0x0, pathseg=UIO_USERSPACE,
flags=0x602, mode=0x1b6)
at /data/usr/src/sys/kern/vfs_syscalls.c:1002
#18 0xc0570e1a in open (td=0xc17d3780, uap=0xcc385d04) at
/data/usr/src/sys/kern/vfs_syscalls.c:968
#19 0xc067225b in syscall (frame=
{tf_fs = 0x3b, tf_es = 0x3b, tf_ds = 0x3b, tf_edi = 0x2, tf_esi =
0x806716c, tf_ebp = 0xbfbfebb8, tf_isp = 0xcc385d64, tf_ebx = 0x80670b0, tf_edx
= 0xbfbfebd0, tf_ecx = 0x0, tf_eax = 0x5, tf_trapno = 0xc, tf_err = 0x2, tf_eip
= 0x28198383, tf_cs = 0x33, tf_eflags = 0x246, tf_esp = 0xbfbfeb1c, tf_ss =
0x3b}) at /data/usr/src/sys/i386/i386/trap.c:981
#20 0xc065fc7f in Xint0x80_syscall () at
/data/usr/src/sys/i386/i386/exception.s:200
#21 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
I can provide further information if need.
--
WBR,
Anton Yuzhaninov.
Re: panic: vinvalbuf: dirty bufs on 6.1-RC
On Tue, Apr 11, 2006 at 08:59:01PM +0400, Anton Yuzhaninov wrote: Hello, I have faced a panic when I use external HDD with USB interface after disconnect mounted drive: Don't do that :( It's a well-known limitation that FreeBSD doesn't handle devices with mounted filesystems spontaneously disappearing. Kris pgpyseVDEXeA1.pgp Description: PGP signature
6-STABLE: panic: vinvalbuf: dirty bufs
Hi guys, [ please Cc: me in your replies as I am not subscribed to this list ] I have a 6-STABLE box : % FreeBSD obiwan.tataz.chchile.org 6.0-STABLE FreeBSD 6.0-STABLE #0: Mon Nov 7 11:50:33 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 I got a panic as stated in the subject. In order to not overload the mailing list, I put the dmesg extracted from the core as well as the kgdb(1) backtrace in the following files on my webserver. Note that the dmesg contains errors I got just before the box panic()'ed. http://jeremie.le-hen.org/~tataz/dumps/dmesg.panic.vinvalbuf-dirty_bufs.txt http://jeremie.le-hen.org/~tataz/dumps/kgdb.panic.vinvalbuf-dirty_bufs.txt If you need it, here is a dmesg of an alive system : http://jeremie.le-hen.org/~tataz/dumps/dmesg.no_panic.txt I hope this will help to sweep out the bug. In case you need more things, such as a full backtrace or verbose boot dmesg, please, let me know. FWIW, does the following error means my disk is dead ? % unknown: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=487055103 Thank you. Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RC3 Kernel Panic: vinvalbuf: dirty bufs (backtrace included)
Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): DATA PROTECT asc:27,0 (da1:umass-sim0:0:0:0): Write protected (da1:umass-sim0:0:0:0): Unretryable error umass0: at uhub4 port 1 (addr 2) disconnected (da1:umass-sim0:0:0:0): lost device (da1:umass-sim0:0:0:0): removing device entry umass0: detached umass0: BUFFALO ClipDrive, rev 2.00/2.00, addr 2 da1 at umass-sim0 bus 0 target 0 lun 0 da1: BUFFALO ClipDrive 2.00 Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retries Exhausted Opened disk da1 - 6 (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) panic: vinvalbuf: dirty bufs Uptime: 1d6h1m42s Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RC3 #0: Thu Apr 21 00:11:58 EEST 2005 hostname removed before posting:/usr/obj/usr/src/sys/ATA Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2605.92-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1073414144 (1023 MB) avail memory = 1040875520 (992 MB) ACPI APIC Table: A M I OEMAPIC ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci1: display at device 0.1 (no driver attached) uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xef00-0xef1f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xef20-0xef3f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub
5.4-RC3 Kernel Panic: vinvalbuf: dirty bufs (backtrace included)
) disconnected (da1:umass-sim0:0:0:0): lost device (da1:umass-sim0:0:0:0): removing device entry umass0: detached umass0: BUFFALO ClipDrive, rev 2.00/2.00, addr 2 da1 at umass-sim0 bus 0 target 0 lun 0 da1: BUFFALO ClipDrive 2.00 Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retries Exhausted Opened disk da1 - 6 (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da1:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da1:umass-sim0:0:0:0): Retrying Command (per Sense Data) panic: vinvalbuf: dirty bufs Uptime: 1d6h1m42s Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RC3 #0: Thu Apr 21 00:11:58 EEST 2005 hostname removed before posting:/usr/obj/usr/src/sys/ATA Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2605.92-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 1073414144 (1023 MB) avail memory = 1040875520 (992 MB) ACPI APIC Table: A M I OEMAPIC ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci1: display at device 0.1 (no driver attached) uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xef00-0xef1f irq 16 at device 29.0 on pci0 usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xef20-0xef3f irq 19 at device 29.1 on pci0 usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xef40-0xef5f irq 18 at device 29.2 on pci0 usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev
