daily CVS update output

2015-01-15 Thread NetBSD source update

Updating src tree:
P src/doc/3RDPARTY
P src/external/gpl3/gcc/dist/gcc/ChangeLog
P src/external/gpl3/gcc/dist/gcc/rtlanal.c
P src/external/gpl3/gcc/usr.bin/gcc/arch/alpha/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/arm/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/armeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/coldfire/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earm/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhf/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmhfeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv4eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hf/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv6hfeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7hf/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/earmv7hfeb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/hppa/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/i386/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/m68000/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/m68k/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mips64eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mips64el/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mipseb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/mipsel/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/or1k/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/powerpc/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/powerpc64/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/riscv32/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/riscv64/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sh3eb/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sh3el/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sparc/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/sparc64/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/vax/configargs.h
P src/external/gpl3/gcc/usr.bin/gcc/arch/x86_64/configargs.h
P src/sys/net/bpfjit.c
P src/tools/gcc/gcc-version.mk

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Fri Jan 16 03:05:41 2015
SUP Scan for current completed at Fri Jan 16 03:06:34 2015
SUP Scan for mirror starting at Fri Jan 16 03:06:34 2015
SUP Scan for mirror completed at Fri Jan 16 03:08:44 2015




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  48814072 Jan 16 03:10 ls-lRA.gz


how to use MKDEBUGLIB=yes with gdb ?

2015-01-15 Thread Manuel Bouyer
Hello,
I've compiled a netbsd-7 release with MKDEBUGLIB=YES MKDEBUG=YES and
extracted the debug and xdebug sets. gdb finds the debug information
for the binary, but not for the dynamic libraries:
comore:/home/bouyer>gdb /usr/X11R7/bin/glxgears
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486--netbsdelf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/X11R7/bin/glxgears...Reading symbols from 
/usr/libdata/debug//usr/X11R7/bin/glxgears.debug...done.
done.
(gdb) run
Starting program: /usr/X11R7/bin/glxgears 

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1]
0xdf00 in glLightfv () from /usr/X11R7/lib/libGL.so.2
(gdb) where
#0  0xdf00 in glLightfv () from /usr/X11R7/lib/libGL.so.2
#1  0x0804ac34 in init ()
at 
/dsk/l1/misc/bouyer/netbsd-7/src/../xsrc/external/mit/mesa-demos/dist/src/xdemos/glxgears.c:398
#2  main (argc=1, argv=0xbfbfec28)
at 
/dsk/l1/misc/bouyer/netbsd-7/src/../xsrc/external/mit/mesa-demos/dist/src/xdemos/glxgears.c:790


How can I tell gdb to use /usr/libdata/debug/usr/X11R7/lib/libGL.so.2.0.debug
to get extra informations ? I tried a few things but none did work
as expected.

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


build -current/i386 with gcc45 yet?

2015-01-15 Thread John D. Baker
I had an interest in building -current/i386 with gcc45 (mainly just to
get "intel_drv.so" that correctly renders stippled regions on i810e
graphics devices).  I run into the following:

[...]
--- bpfjit.o ---
#   compile  libbpfjit/bpfjit.o
/d0/build/current-gcc45/tools/i386/bin/i486--netbsdelf-gcc -O2   -std=gnu99
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-sign-compare  -Wno-traditional  -Wa,--fatal-warnings -Wreturn-type 
-Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter 
-Wno-sign-compare -Wsign-compare -Wformat=2  -Wno-format-zero-length  -Werror   
  --sysroot=/d0/build/current-gcc45/DEST/i386 
-I/x/current/src/sys/external/bsd/sljit/dist/sljit_src  -c
/x/current/src/sys/net/bpfjit.c -o bpfjit.o
cc1: warnings being treated as errors
/x/current/src/sys/net/bpfjit.c: In function 'emit_moddiv':
/x/current/src/sys/net/bpfjit.c:1151:13: error: declaration of 'div' shadows a 
global declaration
*** [bpfjit.o] Error code 1
nbmake[6]: stopped in /x/current/src/lib/libbpfjit
1 error
nbmake[6]: stopped in /x/current/src/lib/libbpfjit
*** [dependall] Error code 2
nbmake[5]: stopped in /x/current/src/lib/libbpfjit
1 error
nbmake[5]: stopped in /x/current/src/lib/libbpfjit
*** Failed target:  dependall-libbpfjit
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift; 
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="lib/"; 
real="/x/current/src/lib" ;; *) this="lib/${dir}/"; 
real="/x/current/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target} ===> 
${show%/}${1:+ (with: $@)}"; cd "${real}" && 
/d0/build/current-gcc45/tools/i386/bin/nbmake _THISDIR_="${this}" "$@" 
${target}; }; _makedirtarget libbpfjit dependall
*** Error code 2
Stop.
[...]


Although, I suppose all I really need is to use the appropriate tool
wrappers to build the bits I want rather than the whole distribution.

-- 
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645



Re: alc(4): add support for 816x devices (and request for review)

2015-01-15 Thread Christos Zoulas
On Jan 15,  4:18pm, iaml...@gmail.com (Leonardo Taccari) wrote:
-- Subject: Re: alc(4): add support for 816x devices (and request for review)

| Christos Zoulas writes:
| > Or we can just define IFM_UNKNOWN and use it.
| Done. I have added it to if_alcreg.h. According to  that
| the max subtype can be 31. I have chosen this value (that does not
| conflict with the ones defined in ... If someday there
| will be more subtype the "31" used for the local IFM_UNKNOWN may become
| problematic! :)).
| 
| So IFM_UNKNOWN is used were appropiate as an argument for alc_aspm().

Ok.

| > Yes, look for PCI_SUBSYS_ID_REG in /usr/src/sys/dev/pci on how to
| > get the subvendor/subdevice with pci_conf_read... Perhaps we should
| > grow convenience functions for those too.
| Thank you a lot for this information! I have added it too without the
| subvendor part that does not seems useful, please correct me if I am
| wrong (FreeBSD's VENDORID_ATHEROS or NetBSD's PCI_VENDOR_ATTANSIC is
| ATM the only vendor for all the ethernet cards supported by alc(4)).

I think that SUBSYS_ID_REG returns a 32 bit value that contains both
the vendor and the product id, so you need to mask the product id to compare
against just the id (look at the macros in pcireg.h).

| I will attach the new patches in this email. Apart the previous two
| parts discussed in this email I have also introduced various cosmetic
| fix in order to reduce the diff with the present if_alc.c (alc_attach()
| variables definitions and initializations).

LGTM...

| It would be nice if someone with an alc(4) ethernet card (especially a
| 813x) can test if I did not broke anything.

That would be great indeed.

| After I will receive an ok I will then open a PR attaching these patches
| with also various man pages improvements (I will do my best in trying to
| avoid wizd(8) invocation ;)).

Ok :-) I will take care of it from there...

christos


Re: sysinst and network install

2015-01-15 Thread Manuel Bouyer
On Thu, Jan 15, 2015 at 03:33:32PM +0100, Martin Husemann wrote:
> On Thu, Jan 15, 2015 at 03:28:48PM +0100, Manuel Bouyer wrote:
> > Has anyone else noticed this ?
> 
> Is this install/49440 ?

The second point looks like install/49440, yes (but I'm using http not
ftp). But there is also the dhcp problem.

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


Re: sysinst and network install

2015-01-15 Thread Andreas Gustafsson
Manuel Bouyer wrote:
> - then, back to the http menu, I selected "get distribution" which did
>   bring me back to the previous menu instead of downloading and installing
>   sets. I had to go to the http menu again and select "get distribution"
>   again to have it start the installation.
> 
> Has anyone else noticed this?

I have noticed this also and found it highly confusing.  And
install/49440 does look like the same thing.

I have not run into the other problem you reported, but then I haven't
done any installs using DHCP configuration lately.
-- 
Andreas Gustafsson, g...@gson.org


Re: sysinst and network install

2015-01-15 Thread Martin Husemann
On Thu, Jan 15, 2015 at 03:28:48PM +0100, Manuel Bouyer wrote:
> Has anyone else noticed this ?

Is this install/49440 ?

Martin


sysinst and network install

2015-01-15 Thread Manuel Bouyer
Hello,
today I've done a network install of netbsd-7/i386 (over http) and it was
not straitforward. In the http menu, I selected the right server and path,
then choose "configure network". Here things did start to go wrong:
- I choose to configure wm0 with dhcp. dhcpcd did find the network
  parameters, including host and domain names. Then sysinst apparently
  decided to flush routes and remove the dhcp-configured address and
  network was not working after that. I had to do a static network config
  to get network working again
- then, back to the http menu, I selected "get distribution" which did
  bring me back to the previous menu instead of downloading and installing
  sets. I had to go to the http menu again and select "get distribution"
  again to have it start the installation.

Has anyone else noticed this ?

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