daily CVS update output

2013-09-11 Thread NetBSD source update

Updating src tree:
P src/crypto/external/bsd/heimdal/lib/libasn1/Makefile
P src/crypto/external/bsd/heimdal/lib/libhdb/Makefile
P src/crypto/external/bsd/heimdal/lib/libheimntlm/Makefile
P src/crypto/external/bsd/heimdal/lib/libkadm5clnt/Makefile
P src/crypto/external/bsd/heimdal/lib/libkadm5srv/Makefile
P src/crypto/external/bsd/heimdal/lib/libkafs/Makefile
P src/crypto/external/bsd/heimdal/lib/libkdc/Makefile
P src/crypto/external/bsd/heimdal/lib/libkrb5/Makefile
P src/crypto/external/bsd/libsaslc/lib/Makefile
P src/crypto/external/bsd/netpgp/lib/verify/Makefile
P src/external/bsd/bind/lib/Makefile
P src/external/bsd/bind/lib/libbind9/Makefile
P src/external/bsd/bind/lib/libdns/Makefile
P src/external/bsd/bind/lib/libisccc/Makefile
P src/external/bsd/bind/lib/libisccfg/Makefile
P src/external/bsd/dhcpcd/dist/net.c
P src/external/bsd/libdwarf/lib/Makefile
P src/external/bsd/libevent/lib/Makefile
P src/external/bsd/libevent/lib/libevent_openssl/Makefile
P src/external/bsd/libevent/lib/libevent_pthreads/Makefile
P src/external/bsd/openldap/bin/Makefile.inc
P src/external/bsd/pkg_install/dist/lib/pkg_signature.c
P src/external/cddl/osnet/lib/Makefile
P src/external/cddl/osnet/lib/libzfs/Makefile
P src/external/cddl/osnet/lib/libzpool/Makefile
P src/external/gpl2/lvm2/lib/libdevmapper/Makefile
P src/external/gpl3/binutils/dist/binutils/readelf.c
P src/external/gpl3/binutils/dist/include/elf/common.h
P src/external/ibm-public/postfix/Makefile.inc
P src/external/mit/lua/lib/liblua/Makefile
P src/lib/Makefile
P src/lib/libdm/Makefile
P src/lib/libisns/Makefile
P src/lib/libp2k/Makefile
P src/lib/libppath/Makefile
P src/lib/libukfs/Makefile
P src/lib/npf/mod.mk
P src/share/mk/bsd.lua.mk
P src/sys/arch/arm/include/proc.h
P src/sys/arch/sparc64/include/pmap.h
P src/sys/arch/sparc64/sparc64/pmap.c
P src/sys/netinet6/in6.c
P src/sys/uvm/uvm_mmap.c

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Thu Sep 12 03:03:26 2013
SUP Scan for current completed at Thu Sep 12 03:03:43 2013
SUP Scan for mirror starting at Thu Sep 12 03:03:43 2013
SUP Scan for mirror completed at Thu Sep 12 03:05:55 2013




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  40106308 Sep 12 03:09 ls-lRA.gz


Re: WDCTL_RST failed

2013-09-11 Thread Chavdar Ivanov
On 11 September 2013 19:01, Manuel Bouyer  wrote:
> On Wed, Sep 11, 2013 at 06:32:29PM +0100, Patrick Welche wrote:
>> Dying disk or ahcisata quirk?
>>
>> Just odd that the failing reset happens first, then the timeout.
>
> I guess it's because the ahci driver reports a timeout to the upper level
> (which is basically that: we waited for WDCTL_RST to clear and
> it didn't clear).
>
> It's either a dying disk or a cabling issue.

I've got similar messages on my latest NetBSD box:

--
Sep 11 03:22:55 uksup1 /netbsd: pdcsata0:1:0: lost interrupt
Sep 11 03:22:55 uksup1 /netbsd: type: ata tc_bcount: 16384 tc_skip: 0
Sep 11 03:24:26 uksup1 /netbsd: pdcsata0:0:0: lost interrupt
Sep 11 03:24:26 uksup1 /netbsd: type: ata tc_bcount: 49152 tc_skip: 0
Sep 11 03:24:26 uksup1 /netbsd: pdcsata0:0:0: device timeout,
c_bcount=49152, c_skip0
Sep 11 03:24:26 uksup1 /netbsd: wd4a: device timeout reading fsbn
55132608 of 55132608-55132703 (wd4 bn 55132671; cn 54695 tn 1 sn 48),
retrying
Sep 11 03:24:36 uksup1 /netbsd: pdcsata0:0:0: lost interrupt
Sep 11 03:24:36 uksup1 /netbsd: type: ata tc_bcount: 49152 tc_skip: 0
Sep 11 03:24:36 uksup1 /netbsd: wd4: soft error (corrected)
Sep 11 03:25:28 uksup1 /netbsd: pdcsata0:1:0: lost interrupt
Sep 11 03:25:38 uksup1 /netbsd: type: ata tc_bcount: 49152 tc_skip: 0
Sep 11 03:25:38 uksup1 /netbsd: pdcsata0:1:0: device timeout,
c_bcount=49152, c_skip0
Sep 11 03:25:38 uksup1 /netbsd: wd5a: device timeout reading fsbn
58539232 of 58539232-58539327 (wd5 bn 58539295; cn 58074 tn 11 sn 10),
retrying
Sep 11 03:25:38 uksup1 /netbsd: pdcsata0:1:0: lost interrupt
Sep 11 03:25:38 uksup1 /netbsd: type: ata tc_bcount: 49152 tc_skip: 0
Sep 11 03:25:38 uksup1 /netbsd: wd5: soft error (corrected)
---

wd4 and wd5 are members of a root RAID1 array, they always appear
together for wd4 and wd5, so it is not very likely to be a dying disk.
Cabling issue is possible, though. It doesn't seem to cause any
problem to the system so far.



>
> --
> Manuel Bouyer 
>  NetBSD: 26 ans d'experience feront toujours la difference
> --

Chavdar



-- 



Re: WDCTL_RST failed

2013-09-11 Thread Manuel Bouyer
On Wed, Sep 11, 2013 at 06:32:29PM +0100, Patrick Welche wrote:
> Dying disk or ahcisata quirk?
> 
> Just odd that the failing reset happens first, then the timeout.

I guess it's because the ahci driver reports a timeout to the upper level
(which is basically that: we waited for WDCTL_RST to clear and
it didn't clear).

It's either a dying disk or a cabling issue.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--


WDCTL_RST failed

2013-09-11 Thread Patrick Welche
Dying disk or ahcisata quirk?

Just odd that the failing reset happens first, then the timeout.

Cheers,

Patrick

Sep 11 17:36:22 quantz /netbsd: ahcisata0 channel 2: clearing WDCTL_RST failed 
for drive 0
Sep 11 17:36:22 quantz /netbsd: wd2d: device timeout writing fsbn 1324281600 of 
1324281600-1324281631 (wd2 bn 1324281600; cn 1313771 tn 6 sn 54), retrying
Sep 11 17:36:22 quantz /netbsd: wd2: soft error (corrected)
Sep 11 17:36:54 quantz /netbsd: wd2d: device timeout writing fsbn 1328735104 of 
1328735104-1328735135 (wd2 bn 1328735104; cn 1318189 tn 9 sn 25), retrying
Sep 11 17:36:54 quantz /netbsd: wd2: soft error (corrected)
Sep 11 17:45:53 quantz /netbsd: ahcisata0 channel 2: clearing WDCTL_RST failed 
for drive 0
Sep 11 17:45:53 quantz /netbsd: wd2d: device timeout writing fsbn 1445792896 of 
1445792896-1445792927 (wd2 bn 1445792896; cn 1434318 tn 5 sn 37), retrying

wd2: 



NetBSD Security Advisory 2013-009: user settable small BPF buffer can cause a panic

2013-09-11 Thread NetBSD Security Officer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

NetBSD Security Advisory 2013-009
=

Topic:  user settable small BPF buffer can cause a panic


Version:NetBSD-current: source prior to Sept 10th, 2013
NetBSD 6.1: affected
NetBSD 6.0: affected
NetBSD 5.1: affected
NetBSD 5.2: affected

Severity:   Local DoS

Fixed:  NetBSD-current: Sept 9th, 2013
NetBSD-6-0 branch:  Sept 11th, 2013
NetBSD-6-1 branch:  Sept 11th, 2013
NetBSD-6 branch:Sept 11th, 2013
NetBSD-5-1 branch:  Sept 11th, 2013
NetBSD-5-2 branch:  Sept 11th, 2013
NetBSD-5 branch:Sept 11th, 2013

Please note that NetBSD releases prior to 5.1 are no longer supported.
It is recommended that all users upgrade to a supported release.


Abstract


Setting the bpf buffer size manually to be less than the required
number of bytes to store the bpf header will crash the system.


Technical Details
=

On NetBSD with 64-bit bpf_timeval, the minimum allowed BPF buffer size
is the same size as the size of struct bpf_hdr. When BPF reports a
packet, it will add the link-layer-type header and the bpf_hdr to the
buffer it was supplied, and then add captured data in the remaining
bytes.

Setting the buffer size via ioctl BIOCSBLEN checks against
BPF_MINBUFSIZE, but this test is not adequate since it does not
include the size of the link layer header. As the link layer header
size can change, no check there would be adequate.

When calculating the size left for captured data (buffer size minus
the sum of the size of the two headers) it may thus get a negative
size.

It will proceed to use this length e.g. to copy data into the buffer,
but the copying routine will use an unsigned variable for the size of
the buffer to copy to, and thus get a very large number. When the copy
routine copies captured data to the buffer, it will leave the bounds
of the buffer, and a panic will result.


Solutions and Workarounds
=

Workaround:
/dev/bpf* usually can only be read by root. If you have not changed
this default: avoid running bpf programs that try to use a buffer size
smaller than 36 on ethernet and 120 on wifi.

Fix:
Install a kernel containing the fix.

The fastest way to do that, if you are running or can run a standard
kernel built as part of the NetBSD release process, is to obtain the
corresponding kernel from the daily NetBSD autobuild output and
install it on your system.

You can obtain such kernels from http://nyftp.netbsd.org/pub/NetBSD-daily/
where they are sorted by NetBSD branch, date, and architecture.  To
fix a system running e.g. NetBSD 6.0 or the stable NetBSD 6.0 branch,
the most appropriate kernel will be the "netbsd-6-0" kernel.

To fix a system running NetBSD-current, the "HEAD" kernel should be
used.  In all cases, a kernel from an autobuild dated newer than the
fix date for the branch you are using must be used to fix the problem.

If you cannot use the autobuilt kernels, then for all affected NetBSD
versions, you need to obtain fixed kernel sources, rebuild and install
the new kernel, and reboot the system.

The fixed source may be obtained from the NetBSD CVS repository.
The following instructions briefly summarise how to upgrade your
kernel.  In these instructions, replace:

  ARCHwith your architecture (from uname -m), and
  KERNCONFwith the name of your kernel configuration file.
  NEWVERSION  with the CVS version of the fix

Versions of src/sys/net/bpf.c:
Branch  NEWVERSION
---
HEAD1.176
netbsd-61.168.2.1
netbsd-6-1  1.168.8.1
netbsd-6-0  1.168.6.1
netbsd-51.141.6.3
netbsd-5-2  1.141.6.2.2.1
netbsd-5-1  1.141.6.1.6.1

To update from CVS, re-build, and re-install the kernel:

# cd src
# cvs update -rNEWVERSION sys/net/bpf.c
# ./build.sh kernel=KERNCONF
# mv /netbsd /netbsd.old
# cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd 
# shutdown -r now

For more information on how to do this, see:

   http://www.NetBSD.org/guide/en/chap-kernel.html


Thanks To
=

Thanks to Peter Bex, who found and analyzed the problem,
and Christos Zoulas, who created the fix.


Revision History


2013-09-11  Initial release


More Information


Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at 
  http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-009.txt.asc

Information about NetBSD and NetBSD security can be found at
http://www.N

Build broken on evbppc64?

2013-09-11 Thread Paul Goyette
With recent sources, I am seeing the following when running an UPDATE 
"build.sh release"


#  link  bc/bc
/build/netbsd-local/tools/x86_64/evbppc64/bin/powerpc64--netbsd-gcc
--sysroot=/build/netbsd-local/dest/evbppc64 -o bc  bc.o execute.o global.o 
load.o main.o number.o scan.o storage.o util.o  
-Wl,-rpath-link,/build/netbsd-local/dest/evbppc64/lib  -L=/lib -ll -ledit 
-lterminfo
/build/netbsd-local/dest/evbppc64/usr/lib/../lib/crt0.o: In function 
`.___start':(.text+0x15c): undefined reference to `._init'
collect2: ld returned 1 exit status


-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-