Re: Loading firmware for USB device after boot

2014-06-12 Thread Thomas Mueller
 On Fri, Jun 06, 2014 at 04:27:00AM +, Thomas Mueller wrote:
  Is it possible to load firmware for a USB device subsequent to boot?

 This is the drivers responsability (via the firmload(9) API).

  In this case, the USB device is a wireless network adapter, Atheros
  AR9271, on motherboard but apparently the boot process is too
  impatient.  Sometimes the firmware is loaded, but most of the time not.

 Please file a PR with useable details, this is a driver bug.

 Martin

I lost the needed dmesg.boot message because I used the USB-stick installations 
of NetBSD-current amd64 and i386 to install NetBSD-current on the new 
replacement hard drive on the other computer, but finally got back to it.

Does the firmload(9) API give up too soon, before the device has time to 
respond?

Again, sending this is delayed now by the FreeBSD wireless connection, Hiro 
H50191 USB-stick wireless adapter, device rsu, bugging out.

But sometimes athn0 loads and connects successfully with

ifconfig athn0 up
wpa_supplicant -B -i athn0 -c /etc/wpa_supplicant.conf
dhcpcd athn0

I am now at 6.99.43

I notice there was no reference at all to athn0 on the live USB built from 
source 6.99.13, so I don't know when this was added, couldn't find it in 
CHANGES file.

When athn firmware fails to load, message is

athn0: could not load firmware (35)

I can also say I'm having difficulty with this message because of flaky USB: 
messages about keyboard and mouse being disconnected even when the pkysical USB 
connection is fully intact.  This can happen in FreeBSD too, but apparently not 
Linux.

Tom



Scroll Lock on NetBSD-current amd64 and i386: different behavior

2014-06-12 Thread Thomas Mueller
I've tried, at a text console, Scroll Lock, which then permits scrolling back 
some way with PageUp key on NetBSD-current i386, just like in FreeBSD, except 
that in FreeBSD, up- and down-arrow keys also work.

But this does not work at all in NetBSD-current amd64.

Is that a bug?  I wouldn't think the different behavior is by design.

Tom



Finding version from src tree in HEAD

2014-06-12 Thread Thomas Mueller
How do you find the NetBSD version to be built, like 6.99.43 or whatever it 
happens to be at the time, from the source tree?

I know it must be somewhere, since the build log quickly finds it.

Tom



Re: Finding version from src tree in HEAD

2014-06-12 Thread Thomas Klausner
On Thu, Jun 12, 2014 at 12:43:53AM -0700, Thomas Mueller wrote:
 How do you find the NetBSD version to be built, like 6.99.43 or whatever it 
 happens to be at the time, from the source tree?

grep ^.define.*NetBSD_Version /usr/src/sys/sys/param.h

 Thomas


Re: DESTDIR support for etcupdate?

2014-06-12 Thread Alan Barrett

On Mon, 09 Jun 2014, Thomas Mueller wrote:

Is there any way to run etcupdate for NetBSD on other than the current root?


Please try revision 1.56 of etcupdate, which now takes a -d destdir
option.

--apb (Alan Barrett)


Automated report: NetBSD-current/i386 build failure

2014-06-12 Thread NetBSD Test Fixture
This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host,
using sources from CVS date 2014.06.12.14.49.02.

An extract from the build.sh output follows:

: ctfconvert -g -L VERSION agp_amd64.o
--- agp_i810.o ---
#   compile  XEN3PAE_DOM0/agp_i810.o
/tmp/bracket/build/2014.06.12.14.49.02-i386/tools/bin/i486--netbsdelf-gcc 
-ffreestanding -fno-zero-initialized-in-bss -O2 -fstack-protector 
-Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing -fno-common 
-std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith 
-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch 
-Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign 
-Wno-attributes -Wno-sign-compare -march=i686 
--sysroot=/tmp/bracket/build/2014.06.12.14.49.02-i386/destdir -Di386 -I. 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/obj/sys/arch/i386/compile/XEN3PAE_DOM0/xen-ma
 -I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/../common/include 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/arch 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys -nostdinc 
-DMSGBUFSIZE=24576 -DDIAGNOSTIC -DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT 
-std=gnu99 -I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/lib
 /libkern/../../../common/lib/libc/quad 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/lib/libkern/../../../common/lib/libc/string
 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string
 -D_FORTIFY_SOURCE=2 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/external/bsd/ipf 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/external/isc/atheros_hal/dist
 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/external/isc/atheros_hal/ic
 
-I/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/external/bsd/acpica/dist/include
 -c /tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/dev/pci/agp_i810.c
/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/dev/pci/agp_i810.c: In 
function 'agp_i810_attach':

/tmp/bracket/build/2014.06.12.14.49.02-i386/src/sys/dev/pci/agp_i810.c:395:3: 
error: large integer implicitly truncated to unsigned type [-Werror=overflow]
   gtt_off = ~(bus_addr_t)0; /* XXXGCC */
   ^
cc1: all warnings being treated as errors
*** [agp_i810.o] Error code 1
nbmake[2]: stopped in 
/tmp/bracket/build/2014.06.12.14.49.02-i386/obj/sys/arch/i386/compile/XEN3PAE_DOM0
1 error

The following commits were made between the last successful build and the 
failed build:

2014.06.12.12.09.47 msaitoh src/sys/dev/mii/brgphy.c,v 1.69
2014.06.12.12.09.47 msaitoh src/sys/dev/mii/brgphyreg.h,v 1.7
2014.06.12.12.09.47 msaitoh src/sys/dev/pci/if_bnx.c,v 1.52
2014.06.12.12.13.36 alnsn src/sys/arch/amd64/conf/GENERIC,v 1.389
2014.06.12.13.31.47 apb src/usr.sbin/etcupdate/etcupdate,v 1.52
2014.06.12.13.33.43 apb src/usr.sbin/etcupdate/etcupdate,v 1.53
2014.06.12.13.40.43 apb src/usr.sbin/etcupdate/etcupdate,v 1.54
2014.06.12.13.42.05 apb src/usr.sbin/etcupdate/etcupdate,v 1.55
2014.06.12.13.47.58 christos src/share/man/man4/ddb.4,v 1.156
2014.06.12.13.56.32 apb src/usr.sbin/etcupdate/etcupdate,v 1.56
2014.06.12.13.56.32 apb src/usr.sbin/etcupdate/etcupdate.8,v 1.21
2014.06.12.14.07.13 apb src/usr.sbin/etcupdate/etcupdate.8,v 1.22
2014.06.12.14.48.17 riastradh src/sys/dev/pci/agp_i810.c,v 1.97
2014.06.12.14.49.02 riastradh src/sys/dev/pci/agp_i810.c,v 1.98

Log files can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2014.06.html#2014.06.12.14.49.02


Re: Finding version from src tree in HEAD

2014-06-12 Thread Aleksej Saushev
Thomas Mueller mueller6...@bellsouth.net writes:

 How do you find the NetBSD version to be built, like 6.99.43 or whatever it 
 happens to be at the time, from the source tree?

 I know it must be somewhere, since the build log quickly finds it.

echo __NetBSD_Version__ | cpp -include sys/param.h | tail -n 1

?

-- 
HE CE3OH...



out of threads

2014-06-12 Thread Thomas Klausner
Something changed in -current or firefox recently. Other programs like
unrar or go or gnome programs sometimes don't start because no threads
are available. When I quit firefox, the problem is solved.

This happens also when firefox only has 5 tabs open, so my first
assumption is a thread leak (if that makes sense?) in firefox. I've
seen it with both firefox 29 and 30; I don't think it happened with
older versions. But perhaps it's a NetBSD issue instead.

Has anyone else seen this?
Ideas?
 Thomas


Re: out of threads

2014-06-12 Thread Matt Thomas

On Jun 12, 2014, at 2:11 PM, Thomas Klausner t...@giga.or.at wrote:

 Something changed in -current or firefox recently. Other programs like
 unrar or go or gnome programs sometimes don't start because no threads
 are available. When I quit firefox, the problem is solved.
 
 This happens also when firefox only has 5 tabs open, so my first
 assumption is a thread leak (if that makes sense?) in firefox. I've
 seen it with both firefox 29 and 30; I don't think it happened with
 older versions. But perhaps it's a NetBSD issue instead.
 
 Has anyone else seen this?

ulimit -r?