Nabble - netbsd-bugs

port-xen/42467: opensolaris DOMU

2009-12-17T08:20:01Z

>Number: 42467
>Category: port-xen
>Synopsis: opensolaris DOMU
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: port-xen-maintainer
>State: open
>Class: support
>Submitter-Id: net
>Arrival-Date: Thu Dec 17 16:20:00 +0000 2009
>Originator: fincombank
>Release: netbsd 5 stable, updated
>Organization:

fincombank
>Environment:
NetBSD NetBSD 5.0.1 NetBSD 5.0.1 (XEN3_DOM0) #0: Wed Dec 16 12:28:10 EET 2009 peter@NetBSD:/usr/src/sys/arch/i386/compile/XEN3_DOM0 i386

the kernel compiled without PAE.
>Description:
hello

xen version:
xentools3-3.1.4nb4 Userland Tools for Xen
xenkernel3-3.1.4nb3 Xen3 Kernel

im using x86 arch. and here is my config file of opensolaris domu:

kernel = "/home/peter/xm/Solaris/unix"
ramdisk = '/home/peter/xm/Solaris/x86.microroot'
# for a 64-bit guest
#extra = '/platform/i86xpv/kernel/amd64/unix - nowin -B install_media=cdrom'
# for a 32-bit guest
extra = "/platform/i86xpv/kernel/unix - nowin -B install_media=cdrom"
memory = 1024
name = "SOLARIS"
cpu = "3"
vcpus = 1
cpu_cap = 100
disk = [ 'file:/home/peter/xm/Solaris/solaris.iso,6:cdrom,r' ]
disk = [ 'file:/mnt/solaris/solaris.img,0,w' ]
vif = [ 'bridge=bridge0' ]

when im running the domain it stopes on the following message:

[18:13][xen]#xm create SOLARIS -c
Using config file "./SOLARIS".
Started domain SOLARIS
v3.1.4 chgset 'unavailable'
SunOS Release 5.11 Version snv_86 32-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: opensolaris
Remounting root read/write
Probing for device nodes ...
Preparing live image for use

------------------
thank you, good bye.

>How-To-Repeat:

>Fix:

PR/42466 CVS commit: src/lib/libc/stdio

2009-12-17T07:20:07Z

The following reply was made to PR bin/42466; it has been noted by GNATS.

From: Christos Zoulas <christos@...>
To: gnats-bugs@...
Cc:
Subject: PR/42466 CVS commit: src/lib/libc/stdio
Date: Thu, 17 Dec 2009 10:19:49 -0500

Module Name: src
Committed By: christos
Date: Thu Dec 17 15:19:49 UTC 2009

Modified Files:
src/lib/libc/stdio: vsnprintf_ss.c

Log Message:
PR/42466: Yasuoka Masahiko: vsnprintf_ss() causes infinite loop

To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/lib/libc/stdio/vsnprintf_ss.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: bin/42466: vsnprintf_ss() causes infinite loop

2009-12-17T05:55:03Z

The following reply was made to PR bin/42466; it has been noted by GNATS.

From: Yasuoka Masahiko <yasuoka@...>
To: gnats-bugs@..., gnats-admin@...
Cc:
Subject: Re: bin/42466: vsnprintf_ss() causes infinite loop
Date: Thu, 17 Dec 2009 22:54:17 +0900 (JST)

On Thu, 17 Dec 2009 22:33:30 +0900 (JST)
Yasuoka Masahiko <yasuoka@...> wrote:
>>Description:
>
> Programs using vsnprintf_ss() cause a infinite loop.
>
> lib/libc/stdio/vsnprintf.c 1.21

Sorry, the filename should be 'lib/libc/stdio/vsnprintf_ss.c'.

--yasuoka

bin/42466: vsnprintf_ss() causes infinite loop

2009-12-17T05:35:01Z

>Number: 42466
>Category: bin
>Synopsis: vsnprintf_ss() causes infinite loop
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 17 13:35:00 +0000 2009
>Originator: yasuoka@...
>Release: NetBSD 5.0.1
>Organization:

Internet Initiative Japan Inc.
>Environment:
System: NetBSD yasuoka-nb.iij.ad.jp 5.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 01:39:11 UTC 2009 builds@...:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:

Programs using vsnprintf_ss() cause a infinite loop.

lib/libc/stdio/vsnprintf.c 1.21

113 #define PUTCHAR(C) do { \
114 if (sbuf < tailp) \
115 *sbuf++ = (C); \
116 } while (/*CONSTCOND*/0)

(snip)

164 for (;;) {
165 while (*fmt != '%' && *fmt) {
166 ret++;
167 PUTCHAR(*fmt++);
168 }

To break 'while' at 165, 'fmt' must be incremeted in every loop. But
PUTCHAR(C) is a macro fuction, it doesn't increment the macro value
'C' in case 'sbuf >= tailp'. This causes a infinite loop.

>How-To-Repeat:

Below test program (archived by shar(1)) can repeat the problem on
NetBSD 5.0.1/i386.

# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# vsnprintf/Makefile
# vsnprintf/vsnprintf_test.c
#
echo x - vsnprintf/Makefile
sed 's/^X//' >vsnprintf/Makefile << 'END-of-vsnprintf/Makefile'
XNOMAN= #
XPROG= vsnprintf_test
X
X.include <bsd.prog.mk>
END-of-vsnprintf/Makefile
echo x - vsnprintf/vsnprintf_test.c
sed 's/^X//' >vsnprintf/vsnprintf_test.c << 'END-of-vsnprintf/vsnprintf_test.c'
X#include <sys/types.h>
X#include <stdlib.h>
X#include <string.h>
X
Xint snprintf_ss(char *, size_t size, const char *, ...);
X
Xint
Xmain(int argc, char *argv[])
X{
X char buf0[32], buf1[32];
X
X memset(buf1, 'A', sizeof(buf1));
X buf1[31] = '\0';
X
X snprintf_ss(buf0, sizeof(buf0), "%sZZZZ", buf1);
X
X exit(EXIT_SUCCESS);
X}
X
X
END-of-vsnprintf/vsnprintf_test.c
exit

>Fix:

Index: vsnprintf_ss.c
===================================================================
RCS file: /cvsroot/NetBSD/src/lib/libc/stdio/vsnprintf_ss.c,v
retrieving revision 1.8
diff -b -u -p -r1.8 vsnprintf_ss.c
--- vsnprintf_ss.c 25 Oct 2009 20:44:13 -0000 1.8
+++ vsnprintf_ss.c 17 Dec 2009 13:07:08 -0000
@@ -164,7 +164,8 @@ vsnprintf_ss(char *sbuf, size_t slen, co
for (;;) {
while (*fmt != '%' && *fmt) {
ret++;
- PUTCHAR(*fmt++);
+ PUTCHAR(*fmt);
+ fmt++;
}
if (*fmt == 0)
goto done;

bin/42465: bmake doesn't check for unclosed curly brace in ${VARNAME

2009-12-17T03:55:00Z

>Number: 42465
>Category: bin
>Synopsis: bmake doesn't check for unclosed curly brace in ${VARNAME
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 17 11:55:00 +0000 2009
>Originator: Aleksey Cheusov
>Release: doesn't matter
>Organization:

home
>Environment:
bmake-20091118 (wip/netbsd-make)

>Description:
0 ~> cat ~/tmp/2.mk
all:
echo ${VARNAME
0 ~> nbmake -f ~/tmp/2.mk
echo

0 ~>

In the above code I expect a syntax error.

>How-To-Repeat:

>Fix:

bin/42464: timed interoperability has been broken since 2001

2009-12-16T22:05:01Z

>Number: 42464
>Category: bin
>Synopsis: timed interoperability has been broken since 2001
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 17 06:05:00 +0000 2009
>Originator: Timothy McIntosh
>Release: 5.0
>Organization:

Green Dome Software
>Environment:
NetBSD hoth.astro.net 5.0 NetBSD 5.0 (GENERIC32_IP2x) #0: Mon Apr 27 06:08:08 UTC 2009 builds@...:/home/builds/ab/netbsd-5-0-RELEASE/sgimips/200904260229Z-obj/home/builds/ab/netbsd-5-0-RELEASE/src/sys/arch/sgimips/compile/GENERIC32_IP2x sgimips
>Description:
timed interoperability has been broken since the patch described in FreeBSD SA-01:28 was implemented in 2001:

http://security.freebsd.org/patches/SA-01:28/timed.patch
http://security.freebsd.org/advisories/FreeBSD-SA-01:28.timed.asc

This patch erroneously forces all TSP packets to be maximally sized. This is in violation of the time synchronization protocol definition, which defines the Machine Name field as a zero-terminated string from 1 to 256 ASCII characters in length (including the terminating NUL character).

http://docs.freebsd.org/44doc/smm/12.timed/paper.pdf

Not all timed implementations send maximally-sized messages, as this implementation does. One such system is Tru64 UNIX version 4.0F, where MAXHOSTNAMELEN is defined as 64. The current timed implementation fails to communicate with such a system, producing messages such as the following in the system log:

Dec 16 22:52:38 hoth timed[364]: short packet (76/268 bytes) from 10.0.1.213

Note: In the 4.3BSD TSP definition, the tsp_name field was 32 characters in size:

http://www.eecs.berkeley.edu/Pubs/TechRpts/1985/CSD-85-250.pdf
>How-To-Repeat:
Attempt to use timed with a system that does not send maximally-sized TSP messages.
>Fix:
I have applied the following patch locally to the timed on my Mac OS X 10.5.8 (Darwin 9.8.0) system, and confirms that it resolves the interoperability issue. The NetBSD 5 timed code is essentially the same, so the same approach would apply there, but I have not ported the patch as of this time:

diff -ur remote_cmds-13.0.2/timed.tproj/timed.tproj/globals.h remote_cmds-13.0.2-patched/timed.tproj/timed.tproj/globals.h
--- remote_cmds-13.0.2/timed.tproj/timed.tproj/globals.h 1999-05-01 22:57:34.000000000 -0500
+++ remote_cmds-13.0.2-patched/timed.tproj/timed.tproj/globals.h 2009-12-15 01:33:17.000000000 -0600
@@ -70,6 +70,7 @@
#include <errno.h>
#include <limits.h>
#include <netdb.h>
+#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
diff -ur remote_cmds-13.0.2/timed.tproj/timed.tproj/readmsg.c remote_cmds-13.0.2-patched/timed.tproj/timed.tproj/readmsg.c
--- remote_cmds-13.0.2/timed.tproj/timed.tproj/readmsg.c 2006-02-07 00:23:04.000000000 -0600
+++ remote_cmds-13.0.2-patched/timed.tproj/timed.tproj/readmsg.c 2009-12-15 01:37:12.000000000 -0600
@@ -231,15 +231,16 @@
continue;
}
length = sizeof(from);
+ bzero(&msgin, sizeof msgin);
if ((n = recvfrom(sock, (char *)&msgin, sizeof(struct tsp), 0,
(struct sockaddr*)&from, &length)) < 0) {
syslog(LOG_ERR, "recvfrom: %m");
exit(1);
}
- if (n < (ssize_t)sizeof(struct tsp)) {
+ if (n <= (ssize_t)offsetof(struct tsp, tsp_name)) {
syslog(LOG_NOTICE,
"short packet (%u/%u bytes) from %s",
- n, sizeof(struct tsp),
+ n, offsetof(struct tsp, tsp_name)+1,
inet_ntoa(from.sin_addr));
continue;
}

Re: install/23548 (fdisk in sysinst, off by one.)

2009-12-16T17:22:05Z

Synopsis: fdisk in sysinst, off by one.

State-Changed-From-To: open->closed
State-Changed-By: ahoka@...
State-Changed-When: Thu, 17 Dec 2009 01:22:04 +0000
State-Changed-Why:
Was fixed in 2003 according the CVS.

Re: install/9582 (sysinst doesn't allow source or pkgsrc installation)

2009-12-16T17:19:23Z

Synopsis: sysinst doesn't allow source or pkgsrc installation

Responsible-Changed-From-To: install-manager->ahoka
Responsible-Changed-By: ahoka@...
Responsible-Changed-When: Thu, 17 Dec 2009 01:19:22 +0000
Responsible-Changed-Why:
Im working on something like this.

Re: install/38453 (install crash)

2009-12-16T17:14:48Z

Synopsis: install crash

State-Changed-From-To: open->closed
State-Changed-By: ahoka@...
State-Changed-When: Thu, 17 Dec 2009 01:14:48 +0000
State-Changed-Why:
Looks invalid, not a NetBSD issue, but some disk writing problem.

Re: port-alpha/38941 (4.99.64 hangs on alpha during boot)

2009-12-16T17:00:50Z

Synopsis: 4.99.64 hangs on alpha during boot

State-Changed-From-To: open->closed
State-Changed-By: ahoka@...
State-Changed-When: Thu, 17 Dec 2009 01:00:49 +0000
State-Changed-Why:
The bug disappeared a few versions later when i have tried again.

bin/42463: Bizarre behavior in awk with invalid numeric constants

2009-12-16T13:10:00Z

>Number: 42463
>Category: bin
>Synopsis: Bizarre behavior in awk with invalid numeric constants
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 16 21:10:00 +0000 2009
>Originator: David A. Holland
>Release: NetBSD 5.99.22 (20091208)
>Organization:
>Environment:

System: NetBSD tanaqui 5.99.22 NetBSD 5.99.22 (TANAQUI) #31: Tue Dec 8 22:53:35 EST 2009 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386
Architecture: i386
Machine: i386
>Description:

awk does bizarrely random things when you write invalid numbers in the
program text.

This is not so surprising, although one would expect it to generate a
syntax error (recall that awk doesn't handle hex integer constants...)

% awk </dev/null 'END { printf "%d\n", 0xblegh }'
0

This, however, is very strange:

% awk </dev/null 'END { printf "%c\n", 0xblegh }'
0

If 0xblegh is a number, that should print a NUL, not a literal zero.
So ok, maybe it's being treated as a string constant, so let's try %s:

% awk </dev/null 'END { printf "%s\n", 0xblegh }'
0

...nope. But wait, it gets weirder. Let's try forcing a conversion to
a number:

% awk </dev/null 'END { printf "%s\n", (0xblegh + 0) }'
00
% awk </dev/null 'END { printf "%s\n", (0xblegh + 3) }'
03
% awk </dev/null 'END { printf "%s\n", (0xblegh - 5) }'
0-5

Huh?

gawk also behaves in a similar way:

% gawk < /dev/null 'END { printf "%d\n", 0xblegh }'
11
% gawk < /dev/null 'END { printf "%c\n", 0xblegh }'
1
% gawk < /dev/null 'END { printf "%s\n", 0xblegh }'
11
% gawk < /dev/null 'END { printf "%s\n", (0xblegh + 0) }'
110

In fact, modulo gawk treating the number as 11 (0xb) because it
accepts hex constants, the behavior is identical. Furthermore, this
whole thing came to light because of this bug filed on mawk:

http://www.mail-archive.com/ubuntu-bugs@.../msg1266528.html

I find this disturbing, especially the way in which + mystically turns
into string concatenation. Is there some strange way in which this
behavior is mandated by the awk specification?

>How-To-Repeat:

as above.

>Fix:

reject invalid numbers up front?

NetBSD Nightly Trouble Ticket Report

2009-12-16T12:01:04Z

There are 4821 non-confidential bugs in 50 categories.

Category critical serious non-crit TOTAL Median TTC
bin 18 223 329 570 27d 22:35:47
install 19 43 48 110 7m 24d 10:35:04
kern 235 852 495 1582 2m 10d 15:32:15
lib 4 73 92 169 19d 14:28:27
misc 5 37 134 176 10d 00:50:27
pkg 110 606 683 1399 11d 15:18:36
port-acorn26 0 2 2 4 12:28:42
port-acorn32 1 3 3 7 1y 4m 28d 05:06:42
port-alpha 18 36 18 72 5m 22d 13:02:30
port-amd64 6 11 7 24 3m 5d 21:57:28
port-amiga 2 7 8 17 1m 4d 23:54:21
port-arc 0 1 0 1 3y 4m 25d 19:05:35
port-arm 1 5 2 8 3m 6d 22:45:01
port-atari 2 2 3 7 15d 02:38:37
port-cats 0 2 0 2 3m 23d 06:15:06
port-evbarm 1 1 4 6 8m 9d 16:19:15
port-evbmips 0 3 3 6 2m 24d 18:32:41
port-evbppc 3 0 0 3 4m 19d 14:47:50
port-hp300 1 0 1 2 18d 05:04:38
port-hp700 1 1 0 2 7m 6d 11:44:41
port-hpcarm 3 1 2 6 4m 28d 01:42:18
port-hpcmips 5 6 9 20 25d 10:54:43
port-hpcsh 1 1 2 4 4m 1d 17:29:07
port-i386 35 83 68 186 6m 9d 02:46:17
port-ia64 0 0 1 1 n/a
port-ibmnws 1 0 0 1 n/a
port-iyonix 1 0 0 1 n/a
port-m68k 3 2 0 5 2m 3d 11:28:15
port-mac68k 4 14 7 25 21d 06:25:09
port-macppc 10 24 12 46 7m 24d 07:25:16
port-mips 1 2 1 4 6m 16d 10:47:33
port-mipsco 1 1 0 2 1y 11m 4d 00:07:00
port-newsmips 1 0 0 1 29d 02:42:14
port-next68k 0 0 3 3 1m 26d 17:28:26
port-playstation2 0 1 1 2 3y 7m 1d 09:59:47
port-pmax 0 1 0 1 1m 1d 18:05:29
port-powerpc 1 5 3 9 3m 10d 13:40:34
port-prep 1 0 0 1 1y 3m 27d 03:56:26
port-sgimips 1 3 3 7 3m 28d 19:02:49
port-shark 0 3 2 5 3m 5d 09:45:56
port-sparc 16 21 12 49 2m 18d 13:56:45
port-sparc64 5 13 2 20 2m 7d 21:38:23
port-sun2 0 0 1 1 16d 22:09:29
port-sun3 0 1 3 4 1m 22d 03:04:54
port-vax 3 8 6 17 5m 24d 09:08:34
port-xen 2 8 4 14 24d 02:53:33
security 1 2 7 10 1m 23d 00:00:26
standards 1 10 28 39 1m 19d 15:22:20
toolchain 14 46 43 103 3m 11d 10:36:11
xsrc 7 31 29 67 12d 19:03:45
TOTAL 545 2195 2081 4821

bin/42462: proplib should give a parse error on

2009-12-16T09:05:00Z

>Number: 42462
>Category: bin
>Synopsis: proplib should give a parse error on <real>
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 16 17:05:00 +0000 2009
>Originator: Matthew Sporleder
>Release: 5.0.1
>Organization:

mspo.com
>Environment:
NetBSD fester 5.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 01:39:11 UTC 2009 builds@...:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386
>Description:
Using a <real> element in a property list causes silent failure. A parse error, or something, would be really helpful in this situation.
>How-To-Repeat:
#include <stdio.h>
#include <prop/proplib.h>

int main (int argc, char *argv[])
{
prop_dictionary_t pl;
pl = prop_dictionary_internalize_from_file( argv[1] );
if ( pl == NULL ) { return 1; }
prop_dictionary_externalize_to_file( pl, argv[2] );
return 0;
}

----

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSNavSidebarWidth</key>
<real>120</real>
<key>NSTableView Columns NSNavOutlineColumnSettings.v1</key>
<array>
<data>
foo
</data>
<string>118</string>
</array>
<key>enableCheckForUpdates</key>
<true/>
<key>enableLogToConsole</key>
<false/>
</dict>
</plist>

---

./pl ./broken.plist ./out.plist

echo $?
1

???
>Fix:

kern/42461: ale(4) very choosy about Ethernet switch

2009-12-16T05:55:00Z

>Number: 42461
>Category: kern
>Synopsis: ale(4) only works in certain switches with certain speeds
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 16 13:55:00 +0000 2009
>Originator: Stephen Borrill
>Release: NetBSD 5.0_STABLE and -current
>Organization:

>Environment:

System: NetBSD 5.99.22 (MONOLITHIC)
Architecture: i386
Machine: i386
>Description:
The ale(4) interface on my EeePC 900A does not detect a carrier on all
switches and speeds.

When plugged into a gigabit port on a Linksys SRW224 switch, the switch
shows a link (not full-speed of course), but ifconfig shows no carrier.
DHCP cannot get an address.

When plugged into a 10/100 port on the same Linksys switch, the connection
works.

When plugged into a cheap 10/100 switch, the link light on the switch goes
out during the kernel autoconf messages and does not recover until the
switch itself is powercycled. When connected to this switch I get the
following errors:
ale0: DMA read error ! -- resetting
ale0: could not disable Tx/Rx MAC(0x000000008)!

I'm network booting in all cases, so pxeboot is talking to the network happily.
Linux also works fine in all cases.

Device is (hand copied):
ale0 at pci3 dev 0 function 0: Attansic/Atheros L1E Ethernet
al0: AR8113 (L2E RevA), ioapic0 pin 19
atphy0 at ale0 phy 0: L1 10/100/1000 PHY, rev.9

>How-To-Repeat:
Try an Asus EeePC 900A with various switches
>Fix:

>Unformatted:

Re: toolchain/38983 (sendmail doesn't compile on i386-current)

2009-12-16T05:48:07Z

Synopsis: sendmail doesn't compile on i386-current

State-Changed-From-To: analyzed->closed
State-Changed-By: jnemeth@...
State-Changed-When: Wed, 16 Dec 2009 13:48:06 +0000
State-Changed-Why:
The sendmail package has been modified to work around this problem.
Although, I still believe this to be a toolchain problem, it is unlikely
to ever be fixed.

Since only one define is needed, I chose a much simpler way then the
one's in the patches provided. I also didn't bother with STRL since that
doesn't really add much in the way of security.

PR/41919 CVS commit: [netbsd-4] src/sys/sys

2009-12-16T03:20:04Z

The following reply was made to PR lib/41919; it has been noted by GNATS.

From: Stephen Borrill <sborrill@...>
To: gnats-bugs@...
Cc:
Subject: PR/41919 CVS commit: [netbsd-4] src/sys/sys
Date: Wed, 16 Dec 2009 11:17:40 +0000

Module Name: src
Committed By: sborrill
Date: Wed Dec 16 11:17:40 UTC 2009

Modified Files:
src/sys/sys [netbsd-4]: stat.h

Log Message:
Pull up the following revisions(s) (requested by dholland in ticket #1371):
sys/sys/stat.h: revision 1.59

Parenthesize S_IS*() macro arguments to prevent breakage with certain
arguments. Addresses PR/41919.

To generate a diff of this commit:
cvs rdiff -u -r1.54 -r1.54.18.1 src/sys/sys/stat.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

PR/39657 CVS commit: [netbsd-4] src/etc/defaults

2009-12-16T03:05:03Z

The following reply was made to PR misc/39657; it has been noted by GNATS.

From: Stephen Borrill <sborrill@...>
To: gnats-bugs@...
Cc:
Subject: PR/39657 CVS commit: [netbsd-4] src/etc/defaults
Date: Wed, 16 Dec 2009 11:01:01 +0000

Module Name: src
Committed By: sborrill
Date: Wed Dec 16 11:01:01 UTC 2009

Modified Files:
src/etc/defaults [netbsd-4]: rc.conf

Log Message:
Pull up the following revisions(s) (requested by dholland in ticket #1370):
etc/defaults/rc.conf: revision 1.107

Make rtsold_flags default to -a. Closes PR/39657.

To generate a diff of this commit:
cvs rdiff -u -r1.81.2.2 -r1.81.2.3 src/etc/defaults/rc.conf

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

bin/42460: build of tools fails in binutils on netbsd-4/i386

2009-12-15T15:50:01Z

>Number: 42460
>Category: bin
>Synopsis: build of tools fails in binutils on netbsd-4/i386
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Dec 15 23:50:00 +0000 2009
>Originator: Greg A. Woods
>Release: current 2009/12/15-23hZ
>Organization:

Planix, Inc.; Toronto, Ontario; Canada
>Environment:
Build-System: NetBSD 4.0_STABLE
Build-Architecture: i386
Build-Machine: i386
Target-System: NetBSD-current
Target-Architecture: evbmips-eb
Target-Machine: mips-eb
>Description:

Attempting to build tools for netbsd/current evbmips-eb fails on
a NetBSD-4 host system.

>How-To-Repeat:

build.sh -m evbmips-eb [[...]] tools

--- cache.lo ---
libtool: compile: cc -DHAVE_CONFIG_H -I. -I/rest/work/woods/m-NetBSD-current/tools/binutils/../../external/gpl3/binutils/dist/bfd -I. -I. -I/rest/work/woods/m-NetBSD-current/tools/binutils/../../external/gpl3/binutils/dist/bfd -I/rest/work/woods/m-NetBSD-current/tools/binutils/../../external/gpl3/binutils/dist/bfd/../include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -pipe -O2 -march=pentiumpro -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -g -c /rest/work/woods/m-NetBSD-current/tools/binutils/../../external/gpl3/binutils/dist/bfd/cache.c -o cache.o
cc1: warnings being treated as errors
/rest/work/woods/m-NetBSD-current/tools/binutils/../../external/gpl3/binutils/dist/bfd/cache.c: In function 'cache_bread':
/rest/work/woods/m-NetBSD-current/tools/binutils/../../external/gpl3/binutils/dist/bfd/cache.c:320: warning: pointer of type 'void *' used in arithmetic

>Fix:

this should fix things well enough

Index: external/gpl3/binutils/dist/bfd/cache.c
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/external/gpl3/binutils/dist/bfd/cache.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 cache.c
--- external/gpl3/binutils/dist/bfd/cache.c 18 Aug 2009 09:23:32 -0000 1.1.1.1
+++ external/gpl3/binutils/dist/bfd/cache.c 15 Dec 2009 23:32:34 -0000
@@ -317,7 +317,7 @@
if (chunk_size > max_chunk_size)
chunk_size = max_chunk_size;

- chunk_nread = cache_bread_1 (abfd, buf + nread, chunk_size);
+ chunk_nread = cache_bread_1 (abfd, (char *) buf + nread, chunk_size);

/* Update the nread count.

NetBSD Nightly Trouble Ticket Report

2009-12-15T12:01:04Z

There are 4819 non-confidential bugs in 50 categories.

Category critical serious non-crit TOTAL Median TTC
bin 17 223 328 568 27d 22:35:47
install 19 43 48 110 7m 24d 10:35:04
kern 235 851 495 1581 2m 10d 15:32:15
lib 4 73 92 169 19d 14:28:27
misc 5 37 134 176 10d 00:50:27
pkg 110 606 683 1399 11d 15:18:36
port-acorn26 0 2 2 4 12:28:42
port-acorn32 1 3 3 7 1y 4m 28d 05:06:42
port-alpha 18 36 18 72 5m 22d 13:02:30
port-amd64 6 11 7 24 3m 5d 21:57:28
port-amiga 2 7 8 17 1m 4d 23:54:21
port-arc 0 1 0 1 3y 4m 25d 19:05:35
port-arm 1 5 2 8 3m 6d 22:45:01
port-atari 2 2 3 7 15d 02:38:37
port-cats 0 2 0 2 3m 23d 06:15:06
port-evbarm 1 1 4 6 8m 9d 16:19:15
port-evbmips 0 3 3 6 2m 24d 18:32:41
port-evbppc 3 0 0 3 4m 19d 14:47:50
port-hp300 1 0 1 2 18d 05:04:38
port-hp700 1 1 0 2 7m 6d 11:44:41
port-hpcarm 3 1 2 6 4m 28d 01:42:18
port-hpcmips 5 6 9 20 25d 10:54:43
port-hpcsh 1 1 2 4 4m 1d 17:29:07
port-i386 35 83 68 186 6m 9d 02:46:17
port-ia64 0 0 1 1 n/a
port-ibmnws 1 0 0 1 n/a
port-iyonix 1 0 0 1 n/a
port-m68k 3 2 0 5 2m 3d 11:28:15
port-mac68k 4 14 7 25 21d 06:25:09
port-macppc 10 24 12 46 7m 24d 07:25:16
port-mips 1 2 1 4 6m 16d 10:47:33
port-mipsco 1 1 0 2 1y 11m 4d 00:07:00
port-newsmips 1 0 0 1 29d 02:42:14
port-next68k 0 0 3 3 1m 26d 17:28:26
port-playstation2 0 1 1 2 3y 7m 1d 09:59:47
port-pmax 0 1 0 1 1m 1d 18:05:29
port-powerpc 1 5 3 9 3m 10d 13:40:34
port-prep 1 0 0 1 1y 3m 27d 03:56:26
port-sgimips 1 3 3 7 3m 28d 19:02:49
port-shark 0 3 2 5 3m 5d 09:45:56
port-sparc 16 21 12 49 2m 18d 13:56:45
port-sparc64 5 13 2 20 2m 7d 21:38:23
port-sun2 0 0 1 1 16d 22:09:29
port-sun3 0 1 3 4 1m 22d 03:04:54
port-vax 3 8 6 17 5m 24d 09:08:34
port-xen 2 8 4 14 24d 02:53:33
security 1 2 7 10 1m 23d 00:00:26
standards 1 10 28 39 1m 19d 15:22:20
toolchain 15 46 43 104 3m 11d 00:32:51
xsrc 7 31 29 67 12d 19:03:45
TOTAL 545 2194 2080 4819

Re: bin/42410 (Bug in makefs gives unhandled exception on MIPS Magnum R4000)

2009-12-15T10:25:03Z

The following reply was made to PR bin/42410; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui@...>
To: gnats-bugs@...
Cc: gnats-admin@..., netbsd-bugs@..., tsutsui@...,
hpoussin@...
Subject: Re: bin/42410 (Bug in makefs gives unhandled exception on MIPS Magnum
R4000)
Date: Wed, 16 Dec 2009 03:22:21 +0900

> cd9660.c:cd9660_compute_record_size() should round size variable.
> -current was already fixed on changes for RISC OS metadata support
> and netbsd-5 and netbsd-5-0 branches need a patch for this PR.

The following patch (from rev 1.25) should fix this PR.
I'll send a pullup request later.

---
Index: usr.sbin/makefs/cd9660.c
===================================================================
RCS file: /cvsroot/src/usr.sbin/makefs/cd9660.c,v
retrieving revision 1.22.2.1
diff -u -r1.22.2.1 cd9660.c
--- usr.sbin/makefs/cd9660.c 2 Feb 2009 03:32:34 -0000 1.22.2.1
+++ usr.sbin/makefs/cd9660.c 15 Dec 2009 18:17:18 -0000
@@ -1759,6 +1759,7 @@

if (diskStructure.rock_ridge_enabled)
size += node->susp_entry_size;
+ size += size & 1;
return size;
}

---
Izumi Tsutsui

Re: bin/42410 (Bug in makefs gives unhandled exception on MIPS Magnum R4000)

2009-12-15T10:22:21Z

> cd9660.c:cd9660_compute_record_size() should round size variable.
> -current was already fixed on changes for RISC OS metadata support
> and netbsd-5 and netbsd-5-0 branches need a patch for this PR.

The following patch (from rev 1.25) should fix this PR.
I'll send a pullup request later.

---
Index: usr.sbin/makefs/cd9660.c
===================================================================
RCS file: /cvsroot/src/usr.sbin/makefs/cd9660.c,v
retrieving revision 1.22.2.1
diff -u -r1.22.2.1 cd9660.c
--- usr.sbin/makefs/cd9660.c 2 Feb 2009 03:32:34 -0000 1.22.2.1
+++ usr.sbin/makefs/cd9660.c 15 Dec 2009 18:17:18 -0000
@@ -1759,6 +1759,7 @@

if (diskStructure.rock_ridge_enabled)
size += node->susp_entry_size;
+ size += size & 1;
return size;
}

---
Izumi Tsutsui

Re: bin/42410 (Bug in makefs gives unhandled exception on MIPS Magnum R4000)

2009-12-15T10:06:56Z

Synopsis: Bug in makefs gives unhandled exception on MIPS Magnum R4000

Responsible-Changed-From-To: bin-bug-people->tsutsui
Responsible-Changed-By: tsutsui@...
Responsible-Changed-When: Wed, 16 Dec 2009 03:06:55 +0900
Responsible-Changed-Why:
I'll check this one for more possible NetBSD/arc users..

State-Changed-From-To: open->analyzed
State-Changed-By: tsutsui@...
State-Changed-When: Wed, 16 Dec 2009 03:06:55 +0900
State-Changed-Why:
cd9660.c:cd9660_compute_record_size() should round size variable.
-current was already fixed on changes for RISC OS metadata support
and netbsd-5 and netbsd-5-0 branches need a patch for this PR.

Re: kern/42450: 5.0.1 system fails to config kernel

2009-12-15T08:05:04Z

The following reply was made to PR kern/42450; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui@...>
To: gnats-bugs@..., dholland-bugs@...
Cc: kern-bug-people@..., gnats-admin@..., netbsd-bugs@...,
girokompas@..., tsutsui@...
Subject: Re: kern/42450: 5.0.1 system fails to config kernel
Date: Wed, 16 Dec 2009 01:04:47 +0900

> http://www.netbsd.org/docs/current/ may also be helpful.

http://www.NetBSD.org/docs/guide/en/chap-updating.html
would be better, though we have to mention about
kernel modules and MONOLITHIC kernel on i386..
---
Izumi Tsutsui

Re: kern/42450: 5.0.1 system fails to config kernel

2009-12-15T08:04:47Z

> http://www.netbsd.org/docs/current/ may also be helpful.

http://www.NetBSD.org/docs/guide/en/chap-updating.html
would be better, though we have to mention about
kernel modules and MONOLITHIC kernel on i386..
---
Izumi Tsutsui

Re: install/42146 (sparc install floppy overflow)

2009-12-15T07:57:45Z

Synopsis: sparc install floppy overflow

State-Changed-From-To: open->pending-pullups
State-Changed-By: tsutsui@...
State-Changed-When: Wed, 16 Dec 2009 00:57:44 +0900
State-Changed-Why:
Should be pulled up to both netbsd-5 and netbsd-5-0, but once after
PRs port-sparc/42192 and port-sparc/42193 are also fixed.

kern/42455: tstile hang with nfs

2009-12-15T01:40:01Z

>Number: 42455
>Category: kern
>Synopsis: tstile hang with nfs
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Dec 15 09:40:01 +0000 2009
>Originator: Christoph Egger
>Release: NetBSD 5.99.22
>Organization:
>Environment:

NetBSD 5.99.22/Xen amd64
>Description:

The Dom0 has guest images on nfs.
The DomUs do IO on vnd(4). They suddenly freeze while they do IO.

When this happens, commands like 'ls' still work in the Dom0
but comands like 'sync' hang in tstile then and don't give the
shell prompt back.

>How-To-Repeat:

Boot Xen Dom0 and launch a DomU. The guest image for the DomU
must be on nfs.

Do heavy IO in the DomU and wait for the freeze (may take a few
minutes, may also take a few hours).

You notice the freeze when the DomU doesn't react on interrupts
anymore.

Then in the Dom0, commands like 'ls' in the nfs mount works, but
'sync' hangs in tstile.

>Fix:

Re: kern/42450: 5.0.1 system fails to config kernel

2009-12-14T22:20:04Z

The following reply was made to PR kern/42450; it has been noted by GNATS.

From: David Holland <dholland-bugs@...>
To: gnats-bugs@...
Cc:
Subject: Re: kern/42450: 5.0.1 system fails to config kernel
Date: Tue, 15 Dec 2009 06:18:43 +0000

On Mon, Dec 14, 2009 at 07:55:00PM +0000, girokompas@... wrote:
> ../../../../conf/files:4: your sources require a newer version of config(1) -- please rebuild it.
> *** Stop.
> # cd /usr/src/tools/config
> # make
> # yacc config/gram.c
> /usr/src/tooldir.NetBSD-5.0.1-i386/bin/nbyacc -d -o gram.c /usr/src/tools/config/../../usr.bin/config/gram.y
> make: exec(/usr/src/tooldir.NetBSD-5.0.1-i386/bin/nbyacc) failed (No such file or directory)
> *** Error code 1

Use "./build.sh tools && ./build.sh kernel=GENERIC" from the top level
of the source tree. Or, if you want to get more deeply into it, set
USETOOLS=no or USETOOLS=never on the make command line.

See src/BUILDING for further info.

http://www.netbsd.org/docs/current/ may also be helpful.

--
David A. Holland
dholland@...

Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

2009-12-14T13:05:03Z

Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

2009-12-14T13:02:46Z

Tobias Nygren <tnn@...> wrote:
> With some local patches I've been able to reduce the panics to a
> deadlock waiting for kva that never becomes availabe. It looks like
> the underlying problem is in fact a resource leak.

Cool. Although before fixing this, it would be good to fix locking issues
in KVA reclamation.

> POOL CACHE ksiginfo: size 72, align 8, ioff 0, roflags 0x00000040
> alloc 0xffffffff80d42f20
> minitems 0, minpages 0, maxpages 4294967295, npages 264334
> itemsperpage 56, nitems 21, nout 14802683, hardlimit 4294967295
> nget 14809537, nfail 13, nput 6854
> npagealloc 264337, npagefree 3, hiwat 264334, nidle 0
> cpu layer hits 5450561 misses 14853292
> cache layer hits 43741 misses 14809551
> cache layer entry uncontended 14853283 contended 9
> cache layer empty groups 0 full groups 0
>
> Are we aware of any issues related to ksiginfo leakage in 5.0/current?

In conversation with ad@ some time ago, he mentioned some possible ksiginfo
leak. I will check few code paths with ksiginfo_cache later..

--
Mindaugas

Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

2009-12-14T13:00:07Z

On Mon, Dec 14, 2009 at 02:55:01PM +0000, Tobias Nygren wrote:

> The following reply was made to PR port-amd64/39283; it has been noted by GNATS.
>
> From: Tobias Nygren <tnn@...>
> To: gnats-bugs@...
> Cc:
> Subject: Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950
> Date: Mon, 14 Dec 2009 15:50:54 +0100
>
> With some local patches I've been able to reduce the panics to a
> deadlock waiting for kva that never becomes availabe. It looks like
> the underlying problem is in fact a resource leak.
>
> From ddb I've identified the following pool cache whose resource usage
> looks highly suspicious to me.
>
> POOL CACHE ksiginfo: size 72, align 8, ioff 0, roflags 0x00000040
> alloc 0xffffffff80d42f20
> minitems 0, minpages 0, maxpages 4294967295, npages 264334
> itemsperpage 56, nitems 21, nout 14802683, hardlimit 4294967295
> nget 14809537, nfail 13, nput 6854
> npagealloc 264337, npagefree 3, hiwat 264334, nidle 0
> cpu layer hits 5450561 misses 14853292
> cache layer hits 43741 misses 14809551
> cache layer entry uncontended 14853283 contended 9
> cache layer empty groups 0 full groups 0
>
> Are we aware of any issues related to ksiginfo leakage in 5.0/current?

No one has mentioned any, but I do recall something about signals being
queued to apps (rather than just being a bitmask). If something is
looping generating signals maybe there is a path which causes an
indefinite number to be queued (ksiginfo sounds like the item being queued!)

Perhaps something has ignored SIGSEGV!

David

--
David Laight: david@...

Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

2009-12-14T13:00:07Z

The following reply was made to PR port-amd64/39283; it has been noted by GNATS.

From: David Laight <david@...>
To: gnats-bugs@...
Cc: port-amd64-maintainer@..., gnats-admin@...,
netbsd-bugs@..., fredrik@...
Subject: Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950
Date: Mon, 14 Dec 2009 21:00:07 +0000

On Mon, Dec 14, 2009 at 02:55:01PM +0000, Tobias Nygren wrote:
> The following reply was made to PR port-amd64/39283; it has been noted by GNATS.
>
> From: Tobias Nygren <tnn@...>
> To: gnats-bugs@...
> Cc:
> Subject: Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950
> Date: Mon, 14 Dec 2009 15:50:54 +0100
>
> With some local patches I've been able to reduce the panics to a
> deadlock waiting for kva that never becomes availabe. It looks like
> the underlying problem is in fact a resource leak.
>
> From ddb I've identified the following pool cache whose resource usage
> looks highly suspicious to me.
>
> POOL CACHE ksiginfo: size 72, align 8, ioff 0, roflags 0x00000040
> alloc 0xffffffff80d42f20
> minitems 0, minpages 0, maxpages 4294967295, npages 264334
> itemsperpage 56, nitems 21, nout 14802683, hardlimit 4294967295
> nget 14809537, nfail 13, nput 6854
> npagealloc 264337, npagefree 3, hiwat 264334, nidle 0
> cpu layer hits 5450561 misses 14853292
> cache layer hits 43741 misses 14809551
> cache layer entry uncontended 14853283 contended 9
> cache layer empty groups 0 full groups 0
>
> Are we aware of any issues related to ksiginfo leakage in 5.0/current?

No one has mentioned any, but I do recall something about signals being
queued to apps (rather than just being a bitmask). If something is
looping generating signals maybe there is a path which causes an
indefinite number to be queued (ksiginfo sounds like the item being queued!)

Perhaps something has ignored SIGSEGV!

David

--
David Laight: david@...

Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

2009-12-14T12:55:03Z

The following reply was made to PR port-amd64/39283; it has been noted by GNATS.

From: Mindaugas Rasiukevicius <rmind@...>
To: Tobias Nygren <tnn@...>
Cc: gnats-bugs@..., gnats-admin@..., netbsd-bugs@...,
fredrik@...
Subject: Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950
Date: Mon, 14 Dec 2009 20:54:02 +0000

Hello,

Tobias Nygren <tnn@...> wrote:
> It tripped over again. Backtrace is similar to before but not identical.
> Looks like lock recursion now (notice the bnx interrupt).
> Would it be possible (and safe?) to return immediately without doing any
> work if mutex_owned()?

Now this is a locking bug. Do you mean using mutex_owned() to make locking
decisions? In such case - no, it would be very wrong, and would also not
work on spin-mutex.

> panic: lock error
> cpu_Debugger() at netbsd:cpu_Debugger+0x9
> panic() at netbsd:panic+0x1f6
> lockdebug_abort() at netbsd:lockdebug_abort+0x8f
> mutex_abort() at netbsd:mutex_abort+0x29
> mutex_vector_enter() at netbsd:mutex_vector_enter+0x1c4
> pool_cache_invalidate() at netbsd:pool_cache_invalidate+0x23
> pool_reclaim() at netbsd:pool_reclaim+0x69
> pool_reclaim_callback() at netbsd:pool_reclaim_callback+0x41
> callback_run_roundrobin() at netbsd:callback_run_roundrobin+0x100
> ...

From the backtrace, it seems there are three paths competing on the same
thing, basically - reclaim on VA cache of kmem_map (since more layers are
involved, like vmem quantum cache, it goes through pool subsystem couple
times). The following interrupt happens (3rd path) while reclaiming, and
it tries to reclaim again from interrupt context and probably locks against
oneself ("lock error" would be meaningful with LOCKDEBUG, in this case):

> bnx_intr() at netbsd:bnx_intr+0xf1
> intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x1d
> Xintr_ioapic_level1() at netbsd:Xintr_ioapic_level1+0xf4
> --- interrupt ---
> mutex_enter() at netbsd:mutex_enter+0x11
> pool_reclaim() at netbsd:pool_reclaim+0x69
> pool_reclaim_callback() at netbsd:pool_reclaim_callback+0x41

This is a bit confusing. Since kmem_map is VM_MAP_INTRSAFE, pool should be
interrupt-safe too i.e. run at IPL_VM and that mutex should be a spin-lock,
blocking bnx_intr() as it runs at IPL_NET (== IPL_VM).

Unfortunately, I had not have time yet to figure out more, but can add some
KASSERT()s if you are OK to crash machine a little bit more? :)

--
Mindaugas

Re: port-amd64/39283: Kernel crash on Dell Poweredge 2950

2009-12-14T12:54:02Z

Hello,

Tobias Nygren <tnn@...> wrote:
> It tripped over again. Backtrace is similar to before but not identical.
> Looks like lock recursion now (notice the bnx interrupt).
> Would it be possible (and safe?) to return immediately without doing any
> work if mutex_owned()?

Now this is a locking bug. Do you mean using mutex_owned() to make locking
decisions? In such case - no, it would be very wrong, and would also not
work on spin-mutex.

> panic: lock error
> cpu_Debugger() at netbsd:cpu_Debugger+0x9
> panic() at netbsd:panic+0x1f6
> lockdebug_abort() at netbsd:lockdebug_abort+0x8f
> mutex_abort() at netbsd:mutex_abort+0x29
> mutex_vector_enter() at netbsd:mutex_vector_enter+0x1c4
> pool_cache_invalidate() at netbsd:pool_cache_invalidate+0x23
> pool_reclaim() at netbsd:pool_reclaim+0x69
> pool_reclaim_callback() at netbsd:pool_reclaim_callback+0x41
> callback_run_roundrobin() at netbsd:callback_run_roundrobin+0x100
> ...

From the backtrace, it seems there are three paths competing on the same
thing, basically - reclaim on VA cache of kmem_map (since more layers are
involved, like vmem quantum cache, it goes through pool subsystem couple
times). The following interrupt happens (3rd path) while reclaiming, and
it tries to reclaim again from interrupt context and probably locks against
oneself ("lock error" would be meaningful with LOCKDEBUG, in this case):

> bnx_intr() at netbsd:bnx_intr+0xf1
> intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x1d
> Xintr_ioapic_level1() at netbsd:Xintr_ioapic_level1+0xf4
> --- interrupt ---
> mutex_enter() at netbsd:mutex_enter+0x11
> pool_reclaim() at netbsd:pool_reclaim+0x69
> pool_reclaim_callback() at netbsd:pool_reclaim_callback+0x41

This is a bit confusing. Since kmem_map is VM_MAP_INTRSAFE, pool should be
interrupt-safe too i.e. run at IPL_VM and that mutex should be a spin-lock,
blocking bnx_intr() as it runs at IPL_NET (== IPL_VM).

Unfortunately, I had not have time yet to figure out more, but can add some
KASSERT()s if you are OK to crash machine a little bit more? :)

--
Mindaugas

NetBSD Nightly Trouble Ticket Report

2009-12-14T12:01:04Z

There are 4812 non-confidential bugs in 50 categories.

Category critical serious non-crit TOTAL Median TTC
bin 17 223 328 568 27d 22:35:47
install 19 43 48 110 7m 24d 10:35:04
kern 234 851 495 1580 2m 10d 15:32:15
lib 4 73 92 169 19d 14:28:27
misc 5 37 134 176 10d 00:50:27
pkg 110 602 681 1393 11d 15:18:36
port-acorn26 0 2 2 4 12:28:42
port-acorn32 1 3 3 7 1y 4m 28d 05:06:42
port-alpha 18 36 18 72 5m 22d 13:02:30
port-amd64 6 11 7 24 3m 5d 21:57:28
port-amiga 2 7 8 17 1m 4d 23:54:21
port-arc 0 1 0 1 3y 4m 25d 19:05:35
port-arm 1 5 2 8 3m 6d 22:45:01
port-atari 2 2 3 7 15d 02:38:37
port-cats 0 2 0 2 3m 23d 06:15:06
port-evbarm 1 1 4 6 8m 9d 16:19:15
port-evbmips 0 3 3 6 2m 24d 18:32:41
port-evbppc 3 0 0 3 4m 19d 14:47:50
port-hp300 1 0 1 2 18d 05:04:38
port-hp700 1 1 0 2 7m 6d 11:44:41
port-hpcarm 3 1 2 6 4m 28d 01:42:18
port-hpcmips 5 6 9 20 25d 10:54:43
port-hpcsh 1 1 2 4 4m 1d 17:29:07
port-i386 35 83 68 186 6m 9d 02:46:17
port-ia64 0 0 1 1 n/a
port-ibmnws 1 0 0 1 n/a
port-iyonix 1 0 0 1 n/a
port-m68k 3 2 0 5 2m 3d 11:28:15
port-mac68k 4 14 7 25 21d 06:25:09
port-macppc 10 24 12 46 7m 24d 07:25:16
port-mips 1 2 1 4 6m 16d 10:47:33
port-mipsco 1 1 0 2 1y 11m 4d 00:07:00
port-newsmips 1 0 0 1 29d 02:42:14
port-next68k 0 0 3 3 1m 26d 17:28:26
port-playstation2 0 1 1 2 3y 7m 1d 09:59:47
port-pmax 0 1 0 1 1m 1d 18:05:29
port-powerpc 1 5 3 9 3m 10d 13:40:34
port-prep 1 0 0 1 1y 3m 27d 03:56:26
port-sgimips 1 3 3 7 3m 28d 19:02:49
port-shark 0 3 2 5 3m 5d 09:45:56
port-sparc 16 21 12 49 2m 18d 13:56:45
port-sparc64 5 13 2 20 2m 7d 21:38:23
port-sun2 0 0 1 1 16d 22:09:29
port-sun3 0 1 3 4 1m 22d 03:04:54
port-vax 3 8 6 17 5m 24d 09:08:34
port-xen 2 8 4 14 24d 02:53:33
security 1 2 7 10 1m 23d 00:00:26
standards 1 10 28 39 1m 19d 15:22:20
toolchain 15 46 43 104 3m 11d 00:32:51
xsrc 7 31 29 67 12d 19:03:45
TOTAL 544 2190 2078 4812

kern/42450: 5.0.1 system fails to config kernel

2009-12-14T11:55:00Z

>Number: 42450
>Category: kern
>Synopsis: 5.0.1 system fails to config kernel
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Dec 14 19:55:00 +0000 2009
>Originator: Vyacheslav Karpenko
>Release: NetBSD-5.0.1
>Organization:
>Environment:

NetBSD Designer 5.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 01:39:11 UTC 2009 builds@...:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386

>Description:
New 5.0.1 system installed from scratch. src.tar.gz loaded from ftp.netbsd.org.
# cd /usr/src/sys/arch/i386/conf
# config GENERIC
../../../../conf/files:4: your sources require a newer version of config(1) -- please rebuild it.
*** Stop.
# cd /usr/src/tools/config
# make
# yacc config/gram.c
/usr/src/tooldir.NetBSD-5.0.1-i386/bin/nbyacc -d -o gram.c /usr/src/tools/config/../../usr.bin/config/gram.y
make: exec(/usr/src/tooldir.NetBSD-5.0.1-i386/bin/nbyacc) failed (No such file or directory)
*** Error code 1

Stop.
make: stopped in /usr/src/tools/config
# cd ../../usr.bin/conf
# make
# yacc config/gram.c
/usr/src/tooldir.NetBSD-5.0.1-i386/bin/nbyacc -d -o gram.c gram.y
make: exec(/usr/src/tooldir.NetBSD-5.0.1-i386/bin/nbyacc) failed (No such file or directory)
*** Error code 1

Stop.
make: stopped in /usr/src/usr.bin/config

>How-To-Repeat:
load NetBSD-current src.tar.gz from ftp and try to make it.
>Fix:
Unknown.