Re: Turbulence in head @r282676.

2015-05-11 Thread David Wolfskill
On Mon, May 11, 2015 at 11:17:03AM -0500, Mark Felder wrote:
> 
> 
> On Sun, May 10, 2015, at 12:39, Alan Cox wrote:
> > This is fixed in r282706.
> > 
> > 
> 
> The r282694 snapshots (amd64 at least) are useless because of this bug
> and was causing me constant crashing.
> ...

On a positive note, my update this morning from r282719 to r282766 for
amd64 was sufficiently uneventful to qualify as "fairly boring" -- which
I consider A Good Thing. :-}

On a less-positive note, the most recent head/i386 that I have been able
to boot was r282623 -- r282676, r282719, and r282766 all panic in the
HDA device attach code with:

Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex hdac1 (HDA driver mutex) r = 0 (0xcfef...  
src/sys/dev/sound/pci/hda/hdaa.c:1571

as cited in .

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp99fHgG93DW.pgp
Description: PGP signature


Re: Turbulence in head @r282676.

2015-05-11 Thread Mark Felder


On Sun, May 10, 2015, at 12:39, Alan Cox wrote:
> This is fixed in r282706.
> 
> 

The r282694 snapshots (amd64 at least) are useless because of this bug
and was causing me constant crashing.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Turbulence in head @r282676.

2015-05-10 Thread Alan Cox
This is fixed in r282706.


On Sun, May 10, 2015 at 10:19 AM, David Wolfskill 
wrote:

> As noted yesterday, my laptop panicked trying to boot head/i386
> @r282676, but seemed OK withe head/amd64.
>
> That turns out to have been a bit optimistic: today, while performing a
> src update on the laptop from head/amd64 from r282676 to r282719, the
> laptop locked up.  While I was able to reproduce the overall symptoms, I
> don't know how good the match was, as I'm not sure exactly where in the
> processing the machine was each of the 3 times.  (After that, I gave up,
> and booted the previous day's kernel (@r282623); that permitted a
> complete build of sources @r282719.)
>
> And my build machine (which is only i386) didn't have the panic (as it
> hasn't any HDA sound), but while it was running head/i386 @r282676,
> builoding head/i386 @r282719, I found it sitting at a "db> " prompt.
>
> This appears to be a kassert_panic() in head/i386 @r282676.
>
> I have a crash dump and a text excerpt; here are excerpts from that
> excerpt:
>
> Sun May 10 08:05:58 PDT 2015
>
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1829
> r282676M/282676:1100073: Sat May  9 07:34:18 PDT 2015
>  r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386
>
> panic: object 0xc9dbb750 ref_count = 1
> ...
> Unread portion of the kernel message buffer:
> panic: object 0xc9dbb750 ref_count = 1
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper(c11db478,0,c11b0e6c,202,f4e0e740,...) at
> db_trace_self_wrapper+0x2a/frame 0xf4e0e710
> kdb_backtrace(c13a164b,1,c1216514,f4e0e7dc,1,...) at
> kdb_backtrace+0x2d/frame 0xf4e0e778
> vpanic(c1216514,f4e0e7dc,c1216514,f4e0e7dc,f4e0e7dc,...) at
> vpanic+0x117/frame 0xf4e0e7ac
> kassert_panic(c1216514,c9dbb750,1,c1f558c0,f4e0e828,...) at
> kassert_panic+0xe9/frame 0xf4e0e7d0
> vm_object_zdtor(c9dbb750,9c,0,8,10,...) at vm_object_zdtor+0x75/frame
> 0xf4e0e7e8
> uma_zfree_arg(c1f558c0,c9dbb750,0) at uma_zfree_arg+0x61/frame 0xf4e0e828
> vm_object_destroy(c9dbb750,0,c1218fa3,ef,f4e0e884,...) at
> vm_object_destroy+0x75/frame 0xf4e0e840
> vnode_pager_alloc(c9dad470,1015,0,0,0,...) at vnode_pager_alloc+0x68/frame
> 0xf4e0e880
> vnode_create_vobject(c9dad470,1015,0,c890d000,c14730b4,...) at
> vnode_create_vobject+0x1f8/frame 0xf4e0e93c
> ufs_open(f4e0e9d0,c75f4c40,c84a0400,0,d3,...) at ufs_open+0x70/frame
> 0xf4e0e95c
> VOP_OPEN_APV(c1472a90,f4e0e9d0,100,c6d83178,f4e0e9f4,...) at
> VOP_OPEN_APV+0xfe/frame 0xf4e0e988
> vn_open_vnode(c9dad470,1,c88d1700,c890d000,c7b16b60,...) at
> vn_open_vnode+0x1e5/frame 0xf4e0ea00
> vn_open_cred(f4e0eb40,f4e0ebcc,0,0,c88d1700,c7b16b60) at
> vn_open_cred+0x32a/frame 0xf4e0ead0
> vn_open(f4e0eb40,f4e0ebcc,0,c7b16b60,2adcfdd4,...) at vn_open+0x3d/frame
> 0xf4e0eaf8
> kern_openat(c890d000,ff9c,2adcfdd4,0,0,0) at kern_openat+0x2ec/frame
> 0xf4e0ebf0
> sys_openat(c890d000,f4e0eca8,c11cfcd9,4,c105e827,...) at
> sys_openat+0x3a/frame 0xf4e0ec18
> syscall(f4e0ece8) at syscall+0x33b/frame 0xf4e0ecdc
> Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf4e0ecdc
> --- syscall (499, FreeBSD ELF32, sys_openat), eip = 0xa1298ff, esp =
> 0xbfbfa910, ebp = 0xbfbfa928 ---
> KDB: enter: panic
>
> Reading symbols from /boot/kernel/tmpfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/tmpfs.ko.symbols
> #0  doadump (textdump=0) at pcpu.h:205
> 205 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0  doadump (textdump=0) at pcpu.h:205
> #1  0xc05311f1 in db_dump (dummy=-1061584035, dummy2=0, dummy3=-1,
> dummy4=0xf4e0e4bc "") at /usr/src/sys/ddb/db_command.c:533
> #2  0xc0530d9f in db_command (cmd_table=)
> at /usr/src/sys/ddb/db_command.c:440
> #3  0xc05309e0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493
> #4  0xc053337b in db_trap (code=)
> at /usr/src/sys/ddb/db_main.c:251
> #5  0xc0b98ac7 in kdb_trap (tf=)
> at /usr/src/sys/kern/subr_kdb.c:654
> #6  0xc10568ff in trap (frame=)
> at /usr/src/sys/i386/i386/trap.c:693
> #7  0xc10427fc in calltrap () at /usr/src/sys/i386/i386/exception.s:169
> #8  0xc0b9835d in kdb_enter (why=0xc11d6ba9 "panic",
> msg=) at cpufunc.h:60
> #9  0xc0b5a1b7 in vpanic (fmt=, ap= out>)
> at /usr/src/sys/kern/kern_shutdown.c:737
> #10 0xc0b5a079 in kassert_panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:634
> #11 0xc0e1ea45 in vm_object_zdtor (mem=0xc9dbb750, size=156, arg=0x0)
> at /usr/src/sys/vm/vm_object.c:169
> #12 0xc0e0a691 in uma_zfree_arg (zone=0xc1f558c0, item= out>,
> udata=0x10) at /usr/src/sys/vm/uma_core.c:2723
> #13 0xc0e20195 in vm_object_destroy (object=0xc9dbb750) at uma.h:364
> #14 0xc0e326d8 in vnode_pager_alloc (handle=0xc9dad470, size=4117,
> prot=0 '\0', offset=0, cred=0xc88d1700)
> at /usr/src/sys/vm/vnode_pager.c:240
> #15 0xc0e330d8 in vnode_create_vobject (vp=0xc9dad470,
> isize=, td=0xc890d000)
> at /usr/src/sys/vm/vnode_pager.c:144
> #16 0xc0dfd510 in ufs_open (ap=)
> at /usr/src/sys/ufs/ufs/ufs_vn

Turbulence in head @r282676.

2015-05-10 Thread David Wolfskill
As noted yesterday, my laptop panicked trying to boot head/i386
@r282676, but seemed OK withe head/amd64.

That turns out to have been a bit optimistic: today, while performing a
src update on the laptop from head/amd64 from r282676 to r282719, the
laptop locked up.  While I was able to reproduce the overall symptoms, I
don't know how good the match was, as I'm not sure exactly where in the
processing the machine was each of the 3 times.  (After that, I gave up,
and booted the previous day's kernel (@r282623); that permitted a
complete build of sources @r282719.)

And my build machine (which is only i386) didn't have the panic (as it
hasn't any HDA sound), but while it was running head/i386 @r282676,
builoding head/i386 @r282719, I found it sitting at a "db> " prompt.

This appears to be a kassert_panic() in head/i386 @r282676.

I have a crash dump and a text excerpt; here are excerpts from that
excerpt:

Sun May 10 08:05:58 PDT 2015

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1829  
r282676M/282676:1100073: Sat May  9 07:34:18 PDT 2015 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386

panic: object 0xc9dbb750 ref_count = 1
...
Unread portion of the kernel message buffer:
panic: object 0xc9dbb750 ref_count = 1
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper(c11db478,0,c11b0e6c,202,f4e0e740,...) at 
db_trace_self_wrapper+0x2a/frame 0xf4e0e710
kdb_backtrace(c13a164b,1,c1216514,f4e0e7dc,1,...) at kdb_backtrace+0x2d/frame 
0xf4e0e778
vpanic(c1216514,f4e0e7dc,c1216514,f4e0e7dc,f4e0e7dc,...) at vpanic+0x117/frame 
0xf4e0e7ac
kassert_panic(c1216514,c9dbb750,1,c1f558c0,f4e0e828,...) at 
kassert_panic+0xe9/frame 0xf4e0e7d0
vm_object_zdtor(c9dbb750,9c,0,8,10,...) at vm_object_zdtor+0x75/frame 0xf4e0e7e8
uma_zfree_arg(c1f558c0,c9dbb750,0) at uma_zfree_arg+0x61/frame 0xf4e0e828
vm_object_destroy(c9dbb750,0,c1218fa3,ef,f4e0e884,...) at 
vm_object_destroy+0x75/frame 0xf4e0e840
vnode_pager_alloc(c9dad470,1015,0,0,0,...) at vnode_pager_alloc+0x68/frame 
0xf4e0e880
vnode_create_vobject(c9dad470,1015,0,c890d000,c14730b4,...) at 
vnode_create_vobject+0x1f8/frame 0xf4e0e93c
ufs_open(f4e0e9d0,c75f4c40,c84a0400,0,d3,...) at ufs_open+0x70/frame 0xf4e0e95c
VOP_OPEN_APV(c1472a90,f4e0e9d0,100,c6d83178,f4e0e9f4,...) at 
VOP_OPEN_APV+0xfe/frame 0xf4e0e988
vn_open_vnode(c9dad470,1,c88d1700,c890d000,c7b16b60,...) at 
vn_open_vnode+0x1e5/frame 0xf4e0ea00
vn_open_cred(f4e0eb40,f4e0ebcc,0,0,c88d1700,c7b16b60) at 
vn_open_cred+0x32a/frame 0xf4e0ead0
vn_open(f4e0eb40,f4e0ebcc,0,c7b16b60,2adcfdd4,...) at vn_open+0x3d/frame 
0xf4e0eaf8
kern_openat(c890d000,ff9c,2adcfdd4,0,0,0) at kern_openat+0x2ec/frame 
0xf4e0ebf0
sys_openat(c890d000,f4e0eca8,c11cfcd9,4,c105e827,...) at sys_openat+0x3a/frame 
0xf4e0ec18
syscall(f4e0ece8) at syscall+0x33b/frame 0xf4e0ecdc
Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf4e0ecdc
--- syscall (499, FreeBSD ELF32, sys_openat), eip = 0xa1298ff, esp = 
0xbfbfa910, ebp = 0xbfbfa928 ---
KDB: enter: panic

Reading symbols from /boot/kernel/tmpfs.ko.symbols...done.
Loaded symbols for /boot/kernel/tmpfs.ko.symbols
#0  doadump (textdump=0) at pcpu.h:205
205 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:205
#1  0xc05311f1 in db_dump (dummy=-1061584035, dummy2=0, dummy3=-1, 
dummy4=0xf4e0e4bc "") at /usr/src/sys/ddb/db_command.c:533
#2  0xc0530d9f in db_command (cmd_table=)
at /usr/src/sys/ddb/db_command.c:440
#3  0xc05309e0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493
#4  0xc053337b in db_trap (code=)
at /usr/src/sys/ddb/db_main.c:251
#5  0xc0b98ac7 in kdb_trap (tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6  0xc10568ff in trap (frame=)
at /usr/src/sys/i386/i386/trap.c:693
#7  0xc10427fc in calltrap () at /usr/src/sys/i386/i386/exception.s:169
#8  0xc0b9835d in kdb_enter (why=0xc11d6ba9 "panic", 
msg=) at cpufunc.h:60
#9  0xc0b5a1b7 in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:737
#10 0xc0b5a079 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:634
#11 0xc0e1ea45 in vm_object_zdtor (mem=0xc9dbb750, size=156, arg=0x0)
at /usr/src/sys/vm/vm_object.c:169
#12 0xc0e0a691 in uma_zfree_arg (zone=0xc1f558c0, item=, 
udata=0x10) at /usr/src/sys/vm/uma_core.c:2723
#13 0xc0e20195 in vm_object_destroy (object=0xc9dbb750) at uma.h:364
#14 0xc0e326d8 in vnode_pager_alloc (handle=0xc9dad470, size=4117, 
prot=0 '\0', offset=0, cred=0xc88d1700)
at /usr/src/sys/vm/vnode_pager.c:240
#15 0xc0e330d8 in vnode_create_vobject (vp=0xc9dad470, 
isize=, td=0xc890d000)
at /usr/src/sys/vm/vnode_pager.c:144
#16 0xc0dfd510 in ufs_open (ap=)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:284
#17 0xc10849de in VOP_OPEN_APV (vop=, a=0xf4e0e9d0)
at vnode_if.c:467
#18 0xc0c23bb5 in vn_open_vnode (vp=0xc9dad470, fmode=, 
cred=, fp=) at vnode_if.h:196
#19 0xc0c237da in vn_open_cred (ndp=0xf4e0eb40, flagp=, 
vn_open_flags=, fp=)
at /usr/src/sys