Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Christos Zoulas 
On Oct 14,  9:02pm, mayur...@acm.org (Mayuresh) wrote:
-- Subject: Re: NetBSD 7.0 i386 panic during boot

| On Wed, Oct 14, 2015 at 11:07:08AM -0400, Christos Zoulas wrote:
| > Add some printfs to vmem_alloc? This is happening way too early.
| 
| I tried enabling following option to see whether trace shows source level
| info. But it didn't.
| 
| makeoptions DEBUG="-g" 
| 
| Is there any way to get source level debug info in ddb trace?

No, you have to use gdb on a kernel core file.

christos

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Mayuresh 
On Wed, Oct 14, 2015 at 11:07:08AM -0400, Christos Zoulas wrote:
> Add some printfs to vmem_alloc? This is happening way too early.

Is there a way to read source level info (line number etc) in the trace?
May be, if that doesn't give a clue, I'll get into printfs?

Mayuresh.

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Christos Zoulas 
On Oct 14,  8:18pm, mayur...@acm.org (Mayuresh) wrote:
-- Subject: Re: NetBSD 7.0 i386 panic during boot

| That apart. Now I get the trace, mentioning the function names:

Add some printfs to vmem_alloc? This is happening way too early.

christos

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Mayuresh 
On Wed, Oct 14, 2015 at 11:07:08AM -0400, Christos Zoulas wrote:
> Add some printfs to vmem_alloc? This is happening way too early.

I tried enabling following option to see whether trace shows source level
info. But it didn't.

makeoptions DEBUG="-g" 

Is there any way to get source level debug info in ddb trace?

Mayuresh

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Mayuresh 
On Tue, Oct 13, 2015 at 08:20:23AM -0400, Christos Zoulas wrote:
> So you have a usb keyboard and it does not work for you?
> Comment out the following lines:
> 
> #pckbc*  at acpi?# PC keyboard controller
> #pckbc0  at isa? # pc keyboard controller
> #pckbd*  at pckbc?   # PC keyboard
> #pms*at pckbc?   # PS/2 mouse for wsmouse  
> #wskbd*  at pckbd? console ? 
> #wsmouse*at pms? mux 0

Tried these, but it did not enable the keyboard on panic.

However in man pages I saw this and set
DDB_COMMANDONENTER="trace"

Surprisingly this option is not present in the GENERIC template
configuration. May be not all options appear there...

That apart. Now I get the trace, mentioning the function names:

vmem_alloc
uvm_km_kmem_alloc
kmem_intr_alloc
kmem_intr_zalloc
mpbios_scan
mainbus_attach
config_attach_loc
config_rootfound
cpu_configure
main


(This is with acpi disabled.)

Mayuresh

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Christos Zoulas 
On Oct 14,  8:52pm, mayur...@acm.org (Mayuresh) wrote:
-- Subject: Re: NetBSD 7.0 i386 panic during boot

| On Wed, Oct 14, 2015 at 11:07:08AM -0400, Christos Zoulas wrote:
| > Add some printfs to vmem_alloc? This is happening way too early.
| 
| Is there a way to read source level info (line number etc) in the trace?
| May be, if that doesn't give a clue, I'll get into printfs?

You can use addr2line if you have the address or use gdb on the core file
with netbsd.gdb.

christos

panic in if_arp.c

2015-10-14 Thread Thomas Klausner 
Hi!

I've upgraded my kernel from a version of end of September (28th or
30th, not quite sure) to one from yesterday, Oct 12.

Since then I've had two panics, both in:

panic: kernel diagnostic assertion "rw_write_held(&(la)->lle_lock)" failed: 
file "...sys/netinet/if_arp.c", line 931

The second was this morning. The machine had been idle after the
previous panic, I started vncserver, and in that filezilla and
transmission, and it immediately paniced.

The backtrace is:

(gdb) target kvm netbsd.88.core
0x80119755 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at 
/archive/foreign/src/sys/arch/amd64/amd64/machdep.c:671
671 dumpsys();
(gdb) bt
#0  0x80119755 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at 
/archive/foreign/src/sys/arch/amd64/amd64/machdep.c:671
#1  0x80811da4 in vpanic (fmt=0x80d38b08 "kernel %sassertion 
\"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xfe813bf7b6f8)
at /archive/foreign/src/sys/kern/subr_prf.c:342
#2  0x80a86303 in kern_assert (fmt=fmt@entry=0x80d38b08 "kernel 
%sassertion \"%s\" failed: file \"%s\", line %d ")
at /archive/foreign/src/sys/lib/libkern/kern_assert.c:51
#3  0x808cf369 in arpresolve (ifp=ifp@entry=0x80003b2ec058, 
rt=rt@entry=0xfe8826534118, m=0xfe88174e0e00, 
dst=dst@entry=0xfe8827d2d8b0,
desten=desten@entry=0xfe813bf7b7c2 
"��\377\377\377\377\030AS&�\376\377\377r\253\202\245\347\063\"�\030AS&�\376\377\377��\322'�\376\377\377\030AS&�\376\377\377\060�\367;�\376\377\377�6T�\377\377\377\377")
 at /archive/foreign/src/sys/netinet/if_arp.c:931
#4  0x8089c80c in ether_output (ifp0=0x80003b2ec058, m0=, dst=0xfe8827d2d8b0, rt=0xfe8826534118)
at /archive/foreign/src/sys/net/if_ethersubr.c:245
#5  0x805436b3 in klock_if_output (rt=0xfe8826534118, 
dst=0xfe8827d2d8b0, m=0xfe88174e0e00, ifp=0x80003b2ec058)
at /archive/foreign/src/sys/netinet/ip_output.c:189
#6  ip_hresolv_output (ifp0=, m=0xfe88174e0e00, 
dst=dst@entry=0xfe8827d2d8b0, rt00=rt00@entry=0xfe8826534118)
at /archive/foreign/src/sys/netinet/ip_output.c:314
#7  0x80544e1e in ip_output (m0=m0@entry=0xfe88174e0e00) at 
/archive/foreign/src/sys/netinet/ip_output.c:749
#8  0x8054f323 in tcp_output (tp=0xfe882578c000) at 
/archive/foreign/src/sys/netinet/tcp_output.c:1627
#9  0x8055863b in tcp_shutdown (so=0xfe882582f498) at 
/archive/foreign/src/sys/netinet/tcp_usrreq.c:931
#10 tcp_shutdown_wrapper (a=0xfe882582f498) at 
/archive/foreign/src/sys/netinet/tcp_usrreq.c:2471
#11 0x8071484b in nfs_disconnect (nmp=0xfe882554e008) at 
/archive/foreign/src/sys/nfs/nfs_socket.c:410
#12 0x807156d1 in nfs_reconnect (rep=rep@entry=0xfe880d6e92d8) at 
/archive/foreign/src/sys/nfs/nfs_socket.c:355
#13 0x806fe473 in nfs_receive (l=0xfe880aab3ba0, 
mp=0xfe813bf7bc28, aname=0xfe813bf7bc30, rep=0xfe880d6e92d8)
at /archive/foreign/src/sys/nfs/nfs_clntsocket.c:278
#14 nfs_reply (lwp=0xfe880aab3ba0, myrep=0xfe880d6e92d8) at 
/archive/foreign/src/sys/nfs/nfs_clntsocket.c:352
#15 nfs_request (np=np@entry=0xfe8825d92e38, mrest=0xfe8826c9e800, 
procnum=procnum@entry=18, lwp=lwp@entry=0xfe880aab3ba0, 
cred=cred@entry=0xfe880d70d180,
mrp=mrp@entry=0xfe813bf7bd50, mdp=mdp@entry=0xfe813bf7bd58, 
dposp=dposp@entry=0xfe813bf7bd40, rexmitp=rexmitp@entry=0x0)
at /archive/foreign/src/sys/nfs/nfs_clntsocket.c:688
#16 0x8071d74a in nfs_statvfs (mp=0xfe8825e03008, 
sbp=0xfe880d472008) at /archive/foreign/src/sys/nfs/nfs_vfsops.c:202
#17 0x80859948 in VFS_STATVFS (mp=mp@entry=0xfe8825e03008, 
a=a@entry=0xfe880d472008) at /archive/foreign/src/sys/kern/vfs_subr.c:1339
#18 0x8085d123 in dostatvfs (mp=mp@entry=0xfe8825e03008, 
sp=sp@entry=0xfe880d472008, l=l@entry=0xfe880aab3ba0, 
flags=flags@entry=1, root=root@entry=0)
at /archive/foreign/src/sys/kern/vfs_syscalls.c:1101
#19 0x8085d4cf in do_sys_getvfsstat (l=0xfe880aab3ba0, 
sfsp=0x7f7ff5d41290, bufsize=, flags=1, 
copyfn=0x80113c40 ,
entry_sz=entry_sz@entry=2256, retval=0xfe813bf7beb8) at 
/archive/foreign/src/sys/kern/vfs_syscalls.c:1254
#20 0x8085d60b in sys_getvfsstat (l=, uap=, retval=) at 
/archive/foreign/src/sys/kern/vfs_syscalls.c:1306
#21 0x8013cdbe in sy_call (rval=0xfe813bf7beb8, 
uap=0xfe813bf7bf00, l=0xfe880aab3ba0, sy=0x8110c500 
)
at /archive/foreign/src/sys/sys/syscallvar.h:65
#22 sy_invoke (code=356, rval=0xfe813bf7beb8, uap=0xfe813bf7bf00, 
l=0xfe880aab3ba0, sy=0x8110c500 ) at 
/archive/foreign/src/sys/sys/syscallvar.h:94
#23 syscall (frame=0xfe813bf7bf00) at 
/archive/foreign/src/sys/arch/x86/x86/syscall.c:156
#24 0x80100691 in Xsyscall ()

Any ideas?

Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)

2015-10-14 Thread Stephan 
Just a side note: The official Pi folks have been working on
optimizations specific to the Pi / armv6 architecture:

http://blog.barisione.org/2014-09/rpi-browser/

Among these are "JavaScript JIT fixes for ARMv6". Perhaps that version
works better (also in terms of performace and stability), though I
don´t know where the source code is. Fixes solving our issues might
even be included in a more recent version of webkit-gtk, so it might
make sense to check that first.


2015-10-14 7:56 GMT+02:00 Stephan :
> 2015-10-13 21:34 GMT+02:00 Nick Hudson :
>> On 10/13/15 17:58, Stephan wrote:
>>
>>>
>>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>>> /usr/pkg/lib/libglib-2.0.so.0
>>> (gdb) i r $r12
>>> r120x7fffb8c8   2147465416
>>>
>>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>>> /usr/pkg/lib/libglib-2.0.so.0
>>> (gdb) i r $r12
>>> r120x7fffb870   2147465328
>>>
>>> Contrary, sp is broken in the non-working case:
>>>
>>> (gdb) i r $r12
>>> r120x7fffa414   2147460116
>>>
>>> Unfortunately, the call trace is incomplete in that case:
>>
>> r13 is sp.
>
> Sure. When I use gdb, I set a breakpoint on . In practise,
> the breakpoint hits after the stack frame was set up by that function,
> e.g. when sp was already lowered to allocate space for local variables
> (or the stack pointer was potentially aligned like gcc on x86 does).
> On gcc/ARM, ip (r12) gets a copy of sp on the first instruction of the
> function prologue. That´s why I monitored r12 (another solution could
> be to break on *function+0, but I haven´t tested that).
>
>>
>> debug symbols (compile flag -g) will help a lot here.
>>
>
> Uff... ATM it looks like Webkit is at fault. It took 2 days to compile
> on the RPI2 so it could take a long time to get the symbols ready.
> Also the last thing I´ve seen yesterday was that the frame where gdb
> stopped being able to follow the stack was special. Basically
> speaking, I think the condition that makes this crash happen is when a
> new tab/page is supposed to open from a JavaScript event - so it´s
> likely that the JS interpreter is on the call trace. The code to the
> said frame where gdb stops was executable memory (rwx) residing in an
> [anon] region. I´m not sure whether symbols can help in this case nor
> what else can... ;)
>
>>
>> Nick

Re: Killing a zombie process?

2015-10-14 Thread J. Hannken-Illjes 

On 14 Oct 2015, at 00:20, Rhialto  wrote:

> I may have something similar; with 7.0/amd64 GENERIC kernel.
> 
> I've been doing builds in pkg_comp with the chroot directory and /usr/pkgsrc
> mounted over nfs. After some packages, some processes simply don't terminate.
> 
> Some of my processes are now (after trying to exit pkg_comp which hangs)
> 
> UID   PID  PPID  CPU PRI NIVSZ   RSS WCHAN   STAT TTY   TIME COMMAND
>   0   402 10  85  0  15360  1428 waitIpts/2  0:00.00 /bin/sh 
> -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l 
> -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f
> 1000   683  29070  85  0  13224  2588 waitIs   pts/2  0:00.03 -bash
>   0  2847   683  257 117  0  13304  1576 tstile  D+   pts/2  0:00.02 /bin/sh 
> /usr/pkg/sbin/pkg_comp chroot
>   0 14284 10  85  0  15360  1428 waitIpts/2  0:00.00 /bin/sh 
> -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l 
> -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f
>   0 26291   402  708 117  0  15360  1004 tstile  Dpts/2  0:00.00 /bin/sh 
> -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l 
> -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f
>   0 28266 142840 116  0  15360  1004 netio   Dpts/2  0:00.01 /bin/sh 
> -c set -e; /usr/bin/find /pkg_comp/packages/*/lame-3.99.5nb3.tgz -type l 
> -print\t 2>/dev/null | /usr/bin/xargs /bin/rm -f
> 
> No zombies involved, though.

Looks like a deadlock, two threads in tstile.

Please take a backtrace (with arguments) of these threads.

--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Mayuresh 
On Tue, Oct 13, 2015 at 05:24:31PM +0530, Mayuresh wrote:
> On Sun, Oct 11, 2015 at 01:13:42PM -0400, Christos Zoulas wrote:
> > | > This looks like a NULL pointer dereference. Do you have a backtrace?
> > | 
> > | Unfortunately the keyboard stops working when db prompt appears. So cannot
> > | gather complete trace.
> > 
> > Compile a kernel with
> > options DDB_ONPANIC 2
> > (man 4 options)
> 
> Did just that, make depend and make. Copied the kernel to bootable USB and
> tried to boot from it. Get the panic error but not stack trace.

On a healthy system I tried triggering ddb with above kernel (with
DDB_ONPANIC set), with Ctrl-Alt-Esc. It did not print trace.

To cross check that the option is effective I did this:

$sysctl ddb.onpanic
ddb.onpanic = 2

Also commented out the following line in /etc/sysctl.conf as below to
ensure that it is not overriding the compiled option.
#ddb.onpanic?=1

So looks like my procedure was alright. Is there anything else needed to
make kernel print trace on entering ddb, when keyboard can't be used?

Mayuresh.

GOOD DAY

2015-10-14 Thread Mr.Thabo Woolen 



--
Respond immediately to confirm recipt of this message ,it is vital and
demands you urgent attention

--
This message was sent from Bitnet Webmail, http://mail.bit.net.id



Mr. Thabo Woolen.pdf
Description: Adobe PDF document

Re: panic in if_arp.c

2015-10-14 Thread Ryota Ozaki 
Hi,

roy@ and I have been working on the issue and have had a fix for it.
The fix will be committed by roy@ (or me) soon.

I'm sorry for the inconvenience,
  ozaki-r

On Tue, Oct 13, 2015 at 4:04 PM, Thomas Klausner  wrote:
> Hi!
>
> I've upgraded my kernel from a version of end of September (28th or
> 30th, not quite sure) to one from yesterday, Oct 12.
>
> Since then I've had two panics, both in:
>
> panic: kernel diagnostic assertion "rw_write_held(&(la)->lle_lock)" failed: 
> file "...sys/netinet/if_arp.c", line 931
>
> The second was this morning. The machine had been idle after the
> previous panic, I started vncserver, and in that filezilla and
> transmission, and it immediately paniced.
>
> The backtrace is:
>
> (gdb) target kvm netbsd.88.core
> 0x80119755 in cpu_reboot (howto=howto@entry=260, 
> bootstr=bootstr@entry=0x0) at 
> /archive/foreign/src/sys/arch/amd64/amd64/machdep.c:671
> 671 dumpsys();
> (gdb) bt
> #0  0x80119755 in cpu_reboot (howto=howto@entry=260, 
> bootstr=bootstr@entry=0x0) at 
> /archive/foreign/src/sys/arch/amd64/amd64/machdep.c:671
> #1  0x80811da4 in vpanic (fmt=0x80d38b08 "kernel %sassertion 
> \"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xfe813bf7b6f8)
> at /archive/foreign/src/sys/kern/subr_prf.c:342
> #2  0x80a86303 in kern_assert (fmt=fmt@entry=0x80d38b08 
> "kernel %sassertion \"%s\" failed: file \"%s\", line %d ")
> at /archive/foreign/src/sys/lib/libkern/kern_assert.c:51
> #3  0x808cf369 in arpresolve (ifp=ifp@entry=0x80003b2ec058, 
> rt=rt@entry=0xfe8826534118, m=0xfe88174e0e00, 
> dst=dst@entry=0xfe8827d2d8b0,
> desten=desten@entry=0xfe813bf7b7c2 
> "��\377\377\377\377\030AS&�\376\377\377r\253\202\245\347\063\"�\030AS&�\376\377\377��\322'�\376\377\377\030AS&�\376\377\377\060�\367;�\376\377\377�6T�\377\377\377\377")
>  at /archive/foreign/src/sys/netinet/if_arp.c:931
> #4  0x8089c80c in ether_output (ifp0=0x80003b2ec058, 
> m0=, dst=0xfe8827d2d8b0, rt=0xfe8826534118)
> at /archive/foreign/src/sys/net/if_ethersubr.c:245
> #5  0x805436b3 in klock_if_output (rt=0xfe8826534118, 
> dst=0xfe8827d2d8b0, m=0xfe88174e0e00, ifp=0x80003b2ec058)
> at /archive/foreign/src/sys/netinet/ip_output.c:189
> #6  ip_hresolv_output (ifp0=, m=0xfe88174e0e00, 
> dst=dst@entry=0xfe8827d2d8b0, rt00=rt00@entry=0xfe8826534118)
> at /archive/foreign/src/sys/netinet/ip_output.c:314
> #7  0x80544e1e in ip_output (m0=m0@entry=0xfe88174e0e00) at 
> /archive/foreign/src/sys/netinet/ip_output.c:749
> #8  0x8054f323 in tcp_output (tp=0xfe882578c000) at 
> /archive/foreign/src/sys/netinet/tcp_output.c:1627
> #9  0x8055863b in tcp_shutdown (so=0xfe882582f498) at 
> /archive/foreign/src/sys/netinet/tcp_usrreq.c:931
> #10 tcp_shutdown_wrapper (a=0xfe882582f498) at 
> /archive/foreign/src/sys/netinet/tcp_usrreq.c:2471
> #11 0x8071484b in nfs_disconnect (nmp=0xfe882554e008) at 
> /archive/foreign/src/sys/nfs/nfs_socket.c:410
> #12 0x807156d1 in nfs_reconnect (rep=rep@entry=0xfe880d6e92d8) at 
> /archive/foreign/src/sys/nfs/nfs_socket.c:355
> #13 0x806fe473 in nfs_receive (l=0xfe880aab3ba0, 
> mp=0xfe813bf7bc28, aname=0xfe813bf7bc30, rep=0xfe880d6e92d8)
> at /archive/foreign/src/sys/nfs/nfs_clntsocket.c:278
> #14 nfs_reply (lwp=0xfe880aab3ba0, myrep=0xfe880d6e92d8) at 
> /archive/foreign/src/sys/nfs/nfs_clntsocket.c:352
> #15 nfs_request (np=np@entry=0xfe8825d92e38, mrest=0xfe8826c9e800, 
> procnum=procnum@entry=18, lwp=lwp@entry=0xfe880aab3ba0, 
> cred=cred@entry=0xfe880d70d180,
> mrp=mrp@entry=0xfe813bf7bd50, mdp=mdp@entry=0xfe813bf7bd58, 
> dposp=dposp@entry=0xfe813bf7bd40, rexmitp=rexmitp@entry=0x0)
> at /archive/foreign/src/sys/nfs/nfs_clntsocket.c:688
> #16 0x8071d74a in nfs_statvfs (mp=0xfe8825e03008, 
> sbp=0xfe880d472008) at /archive/foreign/src/sys/nfs/nfs_vfsops.c:202
> #17 0x80859948 in VFS_STATVFS (mp=mp@entry=0xfe8825e03008, 
> a=a@entry=0xfe880d472008) at /archive/foreign/src/sys/kern/vfs_subr.c:1339
> #18 0x8085d123 in dostatvfs (mp=mp@entry=0xfe8825e03008, 
> sp=sp@entry=0xfe880d472008, l=l@entry=0xfe880aab3ba0, 
> flags=flags@entry=1, root=root@entry=0)
> at /archive/foreign/src/sys/kern/vfs_syscalls.c:1101
> #19 0x8085d4cf in do_sys_getvfsstat (l=0xfe880aab3ba0, 
> sfsp=0x7f7ff5d41290, bufsize=, flags=1, 
> copyfn=0x80113c40 ,
> entry_sz=entry_sz@entry=2256, retval=0xfe813bf7beb8) at 
> /archive/foreign/src/sys/kern/vfs_syscalls.c:1254
> #20 0x8085d60b in sys_getvfsstat (l=, uap= out>, retval=) at 
> /archive/foreign/src/sys/kern/vfs_syscalls.c:1306
> #21 0x8013cdbe in sy_call (rval=0xfe813bf7beb8, 
> uap=0xfe813bf7bf00, l=0xfe880aab3ba0,

Re: Killing a zombie process?

2015-10-14 Thread Rhialto 
On Thu 15 Oct 2015 at 00:21:55 +0200, Rhialto wrote:
> I've got a whole lot more in tstile, and that is even just from running
> pkg_comp in the chroot. I didn't try to interrupt anything yet.

I forgot to mention that this is with a kernel cvs'ed about 24 hours
ago. So this issue isn't the same as the zombie-counting issue.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


pgppbtv6tsBL9.pgp
Description: PGP signature

Set list problems with MKDEBUG, MKDEBUGLIB

2015-10-14 Thread Thomas Klausner 
Hi!

I've tried switching from DBG="-O2 -g" to MKDEBUG=yes MKDEBUGLIB=yes,
but I had the following set list problems then:

===  2 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/lib/i386/libc++_g.a
./usr/lib/libc++_g.a
=  end of 2 extra files  ===
==  14 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/X11R7/lib/modules/extensions/libdbe_g.a
./usr/X11R7/lib/modules/extensions/libdri2_g.a
./usr/X11R7/lib/modules/extensions/libdri_g.a
./usr/X11R7/lib/modules/extensions/libextmod_g.a
./usr/X11R7/lib/modules/extensions/libglx_g.a
./usr/X11R7/lib/modules/extensions/librecord_g.a
./usr/X11R7/lib/modules/extensions/libshadow_g.a
./usr/X11R7/lib/modules/libexa_g.a
./usr/X11R7/lib/modules/libfb_g.a
./usr/X11R7/lib/modules/libint10_g.a
./usr/X11R7/lib/modules/libshadowfb_g.a
./usr/X11R7/lib/modules/libvbe_g.a
./usr/X11R7/lib/modules/libvgahw_g.a
./usr/X11R7/lib/modules/libxaa_g.a

Can someone please fix these?

Thanks,
 Thomas

-current build failure: table has too many members

2015-10-14 Thread Thomas Klausner 
I haven't seen this one before, but just now it popped up:


--- glapi_gentable.po ---
ERROR: glapi_gentable.c: sou _glapi_table has too many members: 1155 > 1023
Removing glapi_gentable.po
*** [glapi_gentable.po] Error code 1

nbmake[6]: stopped in /archive/foreign/src/external/mit/xorg/lib/libGL
--- glapi_gentable.o ---
/archive/build/tools.gcc/bin/nbctfconvert -g -L VERSION -g glapi_gentable.o
ERROR: glapi_gentable.c: sou _glapi_table has too many members: 1155 > 1023
Removing glapi_gentable.o
*** [glapi_gentable.o] Error code 1

This was in a gcc build with MKDTRACE, MKCTF, HAVE_LIBGCC_EH=no and
DBG="-O2 -g".

Any ideas?
 Thomas

Re: NetBSD 7.0 i386 panic during boot

2015-10-14 Thread Mayuresh 
On Wed, Oct 14, 2015 at 07:51:53AM -0400, Christos Zoulas wrote:
> | $sysctl ddb.onpanic
> | ddb.onpanic = 2
> | 
> | So looks like my procedure was alright. Is there anything else needed to
> | make kernel print trace on entering ddb, when keyboard can't be used?
> 
> Did the instructions I posted to make the kernel accept keyboard input work?

Sorry, if I missed your mail. I thought ddb.onpanic=2 would print the trace
automatically on panic, thus not requiring keyboard. No? If there were
more instructions to enable keyboard could you please repost? I don't seem
to find them.

Mayuresh

daily CVS update output

2015-10-14 Thread NetBSD source update 

Updating src tree:
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/man/mi
P src/distrib/sets/lists/tests/mi
P src/external/bsd/am-utils/dist/include/am_utils.h
P src/external/bsd/blacklist/bin/internal.h
P src/external/bsd/dhcp/dist/includes/dhcpd.h
P src/external/bsd/dhcp/dist/includes/omapip/omapip_p.h
P src/external/bsd/dhcpcd/dist/common.h
P src/external/bsd/ntp/dist/include/ntp_stdlib.h
P src/external/bsd/ntp/dist/ntpd/refclock_jupiter.c
P src/external/bsd/ntp/dist/ntpd/refclock_oncore.c
P src/external/bsd/openpam/dist/include/security/openpam.h
P src/external/gpl3/gcc/dist/gcc/c-family/c-format.c
P src/external/gpl3/gcc/dist/gcc/c-family/c-format.h
P src/external/gpl3/gcc/dist/gcc/config/netbsd.h
P src/external/gpl3/gcc.old/dist/gcc/c-family/c-format.c
P src/external/gpl3/gcc.old/dist/gcc/c-family/c-format.h
P src/external/gpl3/gcc.old/dist/gcc/config/netbsd.h
P src/lib/libwrap/diag.c
P src/lib/libwrap/tcpd.h
P src/libexec/identd/identd.h
P src/sbin/init/init.c
P src/share/man/man4/Makefile
U src/share/man/man4/valz.4
U src/sys/arch/mips/ingenic/ingenic_efuse.c
P src/sys/dev/pci/if_wm.c
P src/sys/dev/pci/virtio.c
P src/sys/net/bpf.c
P src/sys/netinet/if_arp.c
P src/sys/sys/cdefs.h
P src/sys/sys/syslog.h
P src/tests/usr.bin/xlint/lint1/Makefile
U src/tests/usr.bin/xlint/lint1/d_c99_anon_struct.c
P src/usr.bin/xlint/lint1/err.c
P src/usr.bin/xlint/lint1/tree.c
P src/usr.sbin/lpr/lpd/recvjob.c
P src/usr.sbin/tcpdchk/inetcf.c

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Thu Oct 15 03:08:08 2015
SUP Scan for current completed at Thu Oct 15 03:08:26 2015
SUP Scan for mirror starting at Thu Oct 15 03:08:26 2015
SUP Scan for mirror completed at Thu Oct 15 03:14:35 2015




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  54317592 Oct 15 03:24 ls-lRA.gz

Re: Killing a zombie process?

2015-10-14 Thread Robert Elz 
Date:Thu, 15 Oct 2015 00:21:55 +0200
From:Rhialto 
Message-ID:  <20151014222155.ga25...@falu.nl>

First, I agree this has nothing at all do do with the zombie refcount
issue (nothing to do with zombies, or process lists or anything slightly
related).

I do wonder about ...

  | procfs on /usr/pkg/emul/linux32/proc type procfs (read-only, local)
  | procfs on /usr/pkg/emul/linux32/proc type procfs (local)

Especially since some of the tstile processes you showed are doing
lookups under namei_tryemulroot()

Do you really need that mounted twice like that, and if not, can you try
with one of them missing and see if the problem remains ?

kre