Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Jul 2009 16:10:34 +0200
From:      Thomas Backman <serenity@exscape.org>
To:        Andriy Gapon <avg@icyb.net.ua>
Cc:        freebsd-fs@FreeBSD.org, FreeBSD current <freebsd-current@FreeBSD.org>, Pawel Jakub Dawidek <pjd@FreeBSD.org>
Subject:   Re: zfs: Fatal trap 12: page fault while in kernel mode
Message-ID:  <5918824D-A67C-43E6-8685-7B72A52B9CAE@exscape.org>
In-Reply-To: <4A7054E1.5060402@icyb.net.ua>
References:  <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <F4F82B3E-C119-40EF-9AA4-937052876D1E@exscape.org> <4A7030B6.8010205@icyb.net.ua> <97D5950F-4E4D-4446-AC22-92679135868D@exscape.org> <4A7048A9.4020507@icyb.net.ua> <52AA86CB-6C06-4370-BA73-CE19175467D0@exscape.org> <4A705299.8060504@icyb.net.ua> <D3491B77-DA5C-4E10-BE1D-D6EF8CFB112E@exscape.org> <4A7054E1.5060402@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jul 29, 2009, at 15:55, Andriy Gapon wrote:

> on 29/07/2009 16:52 Thomas Backman said the following:
>>>
>>> It would be useful to get line number in frame 13 and examine sx
>>> object in frame
>>> 11, esp. sx_lock field.
>>>
>>> --  
>>> Andriy Gapon
>> The "this" (above) was referring to variable values not being  
>> available
>> in a vmcore. :)
>>
>> The zfs module appears to be built with symbols, and the symbols  
>> appear
>> to be loaded in kgdb:
>>
>> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
>> /bootdir/boot/kernel/zfs.ko.symbols...done. done.
>> Loaded symbols for /boot/kernel/zfs.ko
>> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols  
>> from
>> /bootdir/boot/kernel/opensolaris.ko.symbols...done. done.
>> Loaded symbols for /boot/kernel/opensolaris.ko
>>
>> I didn't build the module(s) individually, either; in the previous
>> cases, it was a clean buildworld/buildkernel (even with rm -rf
>> /usr/obj/* beforehand), and in this case "just" a buildkernel (no  
>> manual
>> cleaning, but no -DNO_CLEAN either).
>
> Got it. No idea unfortunately :(
> Could you still please examine sx in frame 11?

Maybe... ;)
If this isn't right, just tell me how:

(kgdb) fr 11
#11 0xffffffff80342b99 in _sx_xlock_hard (sx=0xffffff00090d5018,  
tid=18446742974952890368, opts=Variable "opts" is not available.
)
     at /usr/src/sys/kern/kern_sx.c:575
575                             owner = (struct thread *)SX_OWNER(x);
(kgdb) list
570                      * chain lock.  If so, drop the sleep queue  
lock and try
571                      * again.
572                      */
573                     if (!(x & SX_LOCK_SHARED) &&
574                         (sx->lock_object.lo_flags & SX_NOADAPTIVE)  
== 0) {
575                             owner = (struct thread *)SX_OWNER(x);
576                             if (TD_IS_RUNNING(owner)) {
577                                     sleepq_release(&sx- 
 >lock_object);
578                                     continue;
579                             }
(kgdb) p sx
$3 = (struct sx *) 0xffffff00090d5018
(kgdb) x/x sx
0xffffff00090d5018:     0xffffffff80b5634c
(kgdb) p *sx
$8 = {lock_object = {lo_name = 0xffffffff80b5634c "zp->z_lock",  
lo_flags = 40894464 [0x2700000, btw], lo_data = 0, lo_witness = 0x0},
   sx_lock = 6}

... as you might notice, I'm mostly clueless as to what I'm doing  
here. :o
Hope that helps (a bit), though.

Regards,
Thomas



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5918824D-A67C-43E6-8685-7B72A52B9CAE>