Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jan 2006 21:23:13 -0600 (CST)
From:      Greg Rivers <gcr+freebsd-stable@tharned.org>
To:        Don Lewis <truckman@FreeBSD.org>
Cc:        freebsd-stable@FreeBSD.org, Kirk McKusick <freebsd@McKusick.COM>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: Recurring problem: processes block accessing UFS file system
Message-ID:  <20060104204821.X798@nc8000.tharned.org>
In-Reply-To: <200601041326.k04DQMfu009506@gw.catspoiler.org>
References:  <200601041326.k04DQMfu009506@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Jan 2006, Don Lewis wrote:

>>> How about "show buffer 0xdc76fe30"?
>>>
>>
>> db> show buffer 0xdc76fe30
>> buf at 0xdc76fe30
>> b_flags = 0x200000a0<vmio,delwri,cache>
>> b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0
>> b_bufobj = (0xc8985610), b_data = 0xe1d6b000, b_blkno = 365086368
>> lockstatus = 0, excl count = 0, excl owner 0xffffffff
>> b_npages = 4, pages(OBJ, IDX, PA): (0xc8984108, 0x2b858d4, 0xa8de1000),(0xc8984108, 0x2b858d5, 0xa8c62000),(0xc8984108, 0x2b858d6, 0xa8de3000),(0xc8984108, 0x2b858d7, 0xa8e64000)
>> db>
>
> Hmn, it would be nice if DDB printed b_vflags so that we would know the
> state of BV_BKGRDINPROG and BV_BKGRDWAIT.  As it is, we don't know if
> the background write got lost or if we missed the wakeup.
>
> At this point, I think it might be easier to do post-mortem debugging on
> a core file with kgdb and kernel.debug.  Unless there is an obvious race
> condition, I suspect this will be a tough slog.
>

I attempted to get a core, but "panic" wedged the machine.  I'll try again 
next time this happens.  Thanks again for looking at this.

-- 
Greg


db> continue
#

(free up a partition and set up a dump device...)

# sync;sync
# sync;sync
# sync;sync
# KDB: enter: Line break on console
[thread pid 13 tid 100003 ]
Stopped at      kdb_enter+0x30: leave 
db> panic
panic: from debugger
cpuid = 0
KDB: stack backtrace:
kdb_backtrace(c0625783,0,c060c2d4,e70c5a20,c043bb58) at kdb_backtrace+0x2f
panic(c060c2d4,e70c5ad8,c043aaec,c04d13c9,0) at panic+0x129
db_command_loop(c04d13c9,0,ffffffff,e70c5a4c,e70c5a48) at db_command_loop
db_command(c06549e4,c062efa0,c0629aa8,c0629aac,e70c5b44) at db_command+0x2a4
db_command_loop(c04d13c9,0,0,0,0) at db_command_loop+0x6a
db_trap(3,0,3,c8522a80,e70c5b94) at db_trap+0xe2
kdb_trap(3,0,e70c5b9c,f2db0257,0) at kdb_trap+0xb6
trap(c8710008,28,e70c0028,f9,c8714c00) at trap+0x4d1
calltrap() at calltrap+0x5
--- trap 0x3, eip = 0xc04d13c9, esp = 0xe70c5bdc, ebp = 0xe70c5be4 ---
kdb_enter(c0622c7f,679ed6d4,36,c8522a80,c8714c00) at kdb_enter+0x30
siointr1(c8714c00,37f86c,e5857050,c8522a80,c8522a80) at siointr1+0xd1
siointr(c8714c00,2,0,4,c8522a80) at siointr+0x76
intr_execute_handlers(c851a490,e70c5c68,e70c5cac,c05da733,34) at intr_execute_handlers+0x8c
lapic_handle_intr(34) at lapic_handle_intr+0x3b
Xapic_isr1() at Xapic_isr1+0x33
--- interrupt, eip = 0xc078427a, esp = 0xe70c5cac, ebp = 0xe70c5cac ---
acpi_cpu_c1(37f867,43d0eea4,7b70cdc0,e70c5ce0,37f867) at acpi_cpu_c1+0x5
acpi_cpu_idle(e70c5d04,c049a72a,1,0,0) at acpi_cpu_idle+0x18a
cpu_idle(1,0,0,0,0) at cpu_idle+0x29
idle_proc(0,e70c5d38,0,0,0) at idle_proc+0xad
fork_exit(c049a67d,0,e70c5d38) at fork_exit+0x7b
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe70c5d6c, ebp = 0 ---
Uptime: 42d10h54m36s
GEOM_MIRROR: Device gm1: provider mirror/gm1 destroyed.
pid 13: corrected slot count (0->1)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060104204821.X798>