Updating src tree:
P src/distrib/sets/lists/modules/mi
P src/doc/3RDPARTY
P src/external/bsd/byacc/bin/yacc.1
P src/external/bsd/libarchive/dist/libarchive/libarchive-formats.5
P src/external/gpl2/groff/dist/tmac/groff_mdoc.man
P
src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common/sanitizer_
In article <8e911ed8-0fc3-ab57-6be0-11aa5e23e...@rk.phys.keio.ac.jp>,
Rin Okuyama wrote:
>Note that -fsanitize=address is not yet working on 32bit big-endian
>machines, although it does not fall into SEGV. For example, Report()
>does not work as return values of __syscall(SYS_write) and strlen(3)
In article <86442cf7-1763-9b78-0c4e-173e4e27e...@rk.phys.keio.ac.jp>,
Rin Okuyama wrote:
>I found two problems on libasan of gcc 5.3.
>
>(1) build fails on arm:
>
>http://releng.netbsd.org/builds/HEAD/201606061330Z/
>
>As we use dwarf EH, we must disable __arm__ specific codes in
>sanitizer_unwin
Hi,
I'm sorry that I forgot to let you know the fix.
On 2016/06/07 3:33, John D. Baker wrote:
> Now using if_wm.c r1.411.
Thank you for rechecking. I'm glad the revision fixes almost
system problem.
> The amd64-class systems I've tested so far:
>
snip
> Dell PowerEdge SC430, PCI/PCIe busses:
>
install-info: No such file or directory for
/usr/src/obj/tooldir.NetBSD-7.99.30-amd64/info/make.info
NOT REBUILDING /usr/src/tools/gmake/../../external/gpl2/gmake/dist/config.h.in
NOT REBUILDING /usr/src/tools/gmake/../../external/gpl2/gmake/dist/configure
if cc -DLOCALEDIR=\"/usr/src/obj/tooldir.N
Sorry for bothering you many times. I carelessly considered this is
the problem only for 32bit big-endian, but it also affects 64bit
machines. A trivial example is the case where a return value of a
syscall is int32_t.
On 2016/06/07 5:46, Rin Okuyama wrote:
Note that -fsanitize=address is not ye
Note that -fsanitize=address is not yet working on 32bit big-endian
machines, although it does not fall into SEGV. For example, Report()
does not work as return values of __syscall(SYS_write) and strlen(3)
are not consistent due to a similar problem to (2). Should we use
syscall(2) rather than __s
I found two problems on libasan of gcc 5.3.
(1) build fails on arm:
http://releng.netbsd.org/builds/HEAD/201606061330Z/
As we use dwarf EH, we must disable __arm__ specific codes in
sanitizer_unwind_posix_libcdep.cc, cf. gcc.old version of
sanitizer_netbsd.cc:
https://nxr.netbsd.org/xref/sr
Now using if_wm.c r1.411.
The amd64-class systems I've tested so far:
Dell Optiplex 760 with:
PCI-Express built-in:
wm0 at pci0 dev 25 function 0: 82567LM-3 LAN Controller (rev. 0x02)
Has been working fine building packages during my test period (about
48 hours). Previously, would hang.
PCI a
Additionally, this was committed as src/sys/dev/usb/motg.c 1.17.
On Mon, Jun 06, 2016 at 12:38:33PM +0200, Thomas Klausner wrote:
> netbsd-bugs is just for the GNATS traffic, please use current-users@
> instead (cc'ed).
>
> Thanks,
> Thomas
>
> On Sun, Jun 05, 2016 at 01:56:46PM +0300, Artturi
netbsd-bugs is just for the GNATS traffic, please use current-users@
instead (cc'ed).
Thanks,
Thomas
On Sun, Jun 05, 2016 at 01:56:46PM +0300, Artturi Alm wrote:
> Hi,
>
> copypaste bug?
>
> -Artturi
>
> --- motg.cSun Jun 5 13:35:13 2016
> +++ motg.cSun Jun 5 13:39:51 2016
> @@ -123
On 04/06/2016 16:15, Stephen Borrill wrote:
> On Fri, 3 Jun 2016, Michael van Elst wrote:
>> net...@precedence.co.uk (Stephen Borrill) writes:
>>
>>> Does it run at a sensible temperature? Mine runs very hot and runs the
>>> battery down very quickly.
>>
>> Probably needs some cleaning and/or there
12 matches
Mail list logo
