Recovering from broken userland after removing compat80 package

[coypu]

Hi all,

If you are using this package from pkgsrc-current, and running NetBSD
9.0, please unpack a base tarball before removing the compat80 package.

I haven't realized this package replaces base libraries if they already
exist, so my addition of libterminfo.so.1 to the package for the benefit
of netbsd-current meant that removing the package will delete your BASE
libraries.

If you have the bad version of compat80 installed:

su
cd /
ftp 
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/base.tar.xz

pkg_delete compat80
env PATH=/rescue tar xzpf base.tar.xz

Should be a safe way of removing it.

If you have removed compat80 and now dynamic programs fail, and don't
have a root shell:
1. Drop to boot prompt at the boot menu
2. Type 'boot -as' and press enter to boot.
3. When asked which shell to run, pick /rescue/sh
4. export PATH=/rescue
5. cd /
6. ftp 
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/sets/base.tar.xz
7. tar xzpf base.tar.xz
8. ^D to resume boot normally.

Sorry for the breakage. Hopefully very few people will be affected.

uefi-installimage

[coypu]

hi,

this image is now gone. (it became the regular installimage, and serves
both uefi and bios boot).

panic: kernel diagnostic assertion "(i * BITMAP_SIZE) < pp->pr_itemsperpage" failed: file "sys/kern/subr_pool.c", line 408

[coypu]

For those keeping track at home, running -current as of Feb 9 2020.
(Lightly patched, but not ffs/namei)

panic: kernel diagnostic assertion "(i * BITMAP_SIZE) < pp->pr_itemsperpage" 
failed: file "sys/kern/subr_pool.c", line 408
cpu10: Begin traceback...
vpanic() at netbsd:vpanic+0x178
kern_assert() at netbsd:kern_assert+0x48
pool_get() at netbsd:pool_get+0x4b8
allocbuf() at netbsd:allocbuf+0xe4
getblk() at netbsd:getblk+0x143
bio_doread() at netbsd:bio_doread+0x1d
bread() at netbsd:bread+0x18
ffs_init_vnode() at netbsd:ffs_init_vnode+0x9d
ffs_loadvnode() at netbsd:ffs_loadvnode+0x53
vcache_get() at netbsd:vcache_get+0x21a
ufs_lookup() at netbsd:ufs_lookup+0x9dc
VOP_LOOKUP() at netbsd:VOP_LOOKUP+0x4f
lookup_once() at netbsd:lookup_once+0x266
namei_tryemulroot() at netbsd:namei_tryemulroot+0x2b9
namei() at netbsd:namei+0x29
vn_open() at netbsd:vn_open+0x9a
do_open() at netbsd:do_open+0x113
do_sys_openat() at netbsd:do_sys_openat+0x72
sys_open() at netbsd:sys_open+0x24
syscall() at netbsd:syscall+0x299
--- syscall (number 5) ---
73fc44a42c3a:
cpu10: End traceback...

assertion (pinned->l_flag & LW_RUNNING) != 0 failed

[coypu]

hi folks,

-current is getting even less reliable at booting for me.

I think the thing I'm doing unusual is having an Android phone connected
by USB. It's pretty chatty at boot compared to my other USB devices.

It's hitting this assertion (in kern_softint.c:854).

It seems to be new, but I haven't upgraded -current in a while.

Request for testing: i915 + suspend, or i915 heavy use

[coypu]

hi folks,

I applied an upstream security fix to i915. It's pretty big.

It touches the suspend codepath, and I can't test that on my machine.

Additionally I am looking for confirmation that i915 is fine in the last
week. My testing wasn't very intensive.

Any -current later than Dec 6 2019.

Thanks.

Re: Mesa update

[coypu]

LGTM, by the way, I just compare to pkgsrc MesaLib as the canonical
version :-)


On Mon, Apr 22, 2019 at 08:48:05AM +0200, Yorick Hardy wrote:
> On 2019-04-18, co...@sdf.org wrote:
> > LD_PRELOAD=/usr/lib/libpthread.so fixes it.
> > It's the libc stubs. I don't know what to link against libpthread but
> > pkgsrc is cheating by having glmark2 linked with libpthread.
> 
> Thank you for updating Mesa, it is much appreciated. SDL2 applications
> which load libGL.so seem to fail due to missing symbols, I had to add
> some dependencies as below. Is this correct?
> 
> -- 
> Kind regards,
> 
> Yorick Hardy
> 
> Index: external/mit/xorg/lib/Makefile
> ===
> RCS file: /cvsroot/src/external/mit/xorg/lib/Makefile,v
> retrieving revision 1.49
> diff -u -u -r1.49 Makefile
> --- external/mit/xorg/lib/Makefile16 Apr 2019 21:20:51 -  1.49
> +++ external/mit/xorg/lib/Makefile22 Apr 2019 06:43:24 -
> @@ -20,10 +20,12 @@
>  .endif
>  SUBDIR+=libxcb \
>   .WAIT
> +SUBDIR+=libX11 \
> + .WAIT
>  .if !defined(MLIBDIR)
>  SUBDIR+=${EXTRA_DRI_DIRS} dri${OLD_PREFIX} gallium${OLD_PREFIX}
>  .endif
> -SUBDIR+=fontconfig libSM libX11 \
> +SUBDIR+=fontconfig libSM \
>   .WAIT \
>   libXcomposite libXdamage libXext libXfixes libXt \
>   libxkbfile libepoxy \
> Index: external/mit/xorg/lib/gallium/Makefile
> ===
> RCS file: /cvsroot/src/external/mit/xorg/lib/gallium/Makefile,v
> retrieving revision 1.25
> diff -u -u -r1.25 Makefile
> --- external/mit/xorg/lib/gallium/Makefile16 Apr 2019 17:29:09 -  
> 1.25
> +++ external/mit/xorg/lib/gallium/Makefile22 Apr 2019 06:43:24 -
> @@ -957,6 +957,9 @@
>  LIBDPLIBS+=  terminfo${.CURDIR}/../../../../../lib/libterminfo
>  LIBDPLIBS+=  z   ${.CURDIR}/../../../../../lib/libz
>  LIBDPLIBS+=  execinfo${.CURDIR}/../../../../../lib/libexecinfo
> +LIBDPLIBS+=  xcb ${.CURDIR}/../libxcb/libxcb
> +LIBDPLIBS+=  xcb-dri2${.CURDIR}/../libxcb/dri2
> +LIBDPLIBS+=  X11-xcb ${.CURDIR}/../libX11/libX11-xcb
>  
>  # gallium drivers requiring LLVM
>  .if ${BUILD_LLVMPIPE} == 1 || ${BUILD_RADEON} == 1

kernel panic in genfs_deadunlock

[coypu]

hi folks,
while testing a very recent kernel, and waiting for it to reboot, I got this:

Crash version 8.99.37, image version 8.99.37.
System panicked: lock error: Reader / writer lock: rw_vector_exit,454: 
assertion failed: RW_COUNT(rw) != 0: lock 0xed5bd50116b0 cpu 3 lwp 
0xed5f70a20ae0
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
ostype() at ostype+0xb7290
vpanic() at vpanic+0x169
snprintf() at snprintf
lockdebug_abort() at lockdebug_abort+0xe7
rw_vector_exit() at rw_vector_exit+0xce
genfs_deadunlock() at genfs_deadunlock+0x14
VOP_UNLOCK() at VOP_UNLOCK+0x51
cnclose() at cnclose+0x7e
cdev_close() at cdev_close+0xbc
spec_close() at spec_close+0x199
VOP_CLOSE() at VOP_CLOSE+0x4c
vn_close() at vn_close+0x34
closef() at closef+0x6d
fd_close() at fd_close+0x1f4
sys_close() at sys_close+0x20
syscall() at syscall+0x173
--- syscall (number 6) ---
755abfa42bea:


If it helps anyone. I have no idea :-)

Re: Mesa update

[coypu]

I checked with pkgsrc xorg, and it aborts with it too.
so it's not my fault here, probably.

Re: Mesa update

[coypu]

LD_PRELOAD=/usr/lib/libpthread.so fixes it.
It's the libc stubs. I don't know what to link against libpthread but
pkgsrc is cheating by having glmark2 linked with libpthread.

Re: Mesa update

[coypu]

On Thu, Apr 18, 2019 at 11:33:09AM +0100, Patrick Welche wrote:
> Add gl, egl and glx loader using GLAD.
> 
> Instead of hard linking against libGL, libEGL and libGLESv2 we can
> load the entry points at runtime. Loading dynamically is more
> flexible across different platforms.
> 
> Note that the glad loaders are licensed under public domain.
> 
> Preparation for Windows support in Issue #9.
> 

I know that EGL needs the same treatment, at least...

Re: Mesa update

[coypu]

> I wonder why you don't see this too...

fwiw, I am using pkgsrc glmark2.

Re: Mesa update

[coypu]

On Thu, Apr 11, 2019 at 04:49:09PM +, co...@sdf.org wrote:
> argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
> complicating testing :_/

Ah, disregard, I had the old libGL.so.3.0 (because I unpacked sets, but
for this manipulation I only re-linked libGL.so.

Putting libGL.so that is linked against pthread makes it work as befor.e

Re: Mesa update

[coypu]

argh. now I see it too. I had pkgsrc xorg in the middle and in the RPATH
complicating testing :_/

Re: Mesa update

[coypu]

This avoids the crash but it crashes on exit too

Index: Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/libGL/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- Makefile9 Apr 2019 14:31:06 -   1.24
+++ Makefile11 Apr 2019 10:00:04 -
@@ -191,7 +191,8 @@
xcb-dri2${.CURDIR}/../libxcb/dri2 \
xcb-glx ${.CURDIR}/../libxcb/glx \
expat   ${NETBSDSRCDIR}/external/mit/expat/lib/libexpat 
\
-   m   ${NETBSDSRCDIR}/lib/libm
+   m   ${NETBSDSRCDIR}/lib/libm \
+   pthread ${NETBSDSRCDIR}/lib/libpthread
 
 MKLINT=no
 

Re: Mesa update

[coypu]

glmark2 aborts for me, but I don't understand why.

> gdb -q (which glmark2)
Reading symbols from /usr/pkg/bin/glmark2...done.
(gdb) r
Starting program: /usr/pkg/bin/glmark2 
[New LWP 1 of process 27174]

Thread 2 received signal SIGABRT, Aborted.
0x74c647e427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12
(gdb) info registers
rax0x0  0
rbx0x74c64a457900   128394998413568
rcx0x74c647e427ca   128394958481354
rdx0x0  0
rsi0x7f7fff33f090   140187719168144
rdi0x3  3
rbp0x74c64a4ac0e0   0x74c64a4ac0e0
rsp0x7f7fff33f038   0x7f7fff33f038
r8 0x74c64a4adb38   128394998766392
r9 0x74c644400900   128394897393920
r100x0  0
r110x202514
r120x0  0
r130x74c64a4ab120   128394998755616
r140x0  0
r150x   -1
rip0x74c647e427ca   0x74c647e427ca <_sys___sigprocmask14+10>
eflags 0x202[ IF ]
cs 0x47 71
ss 0x3f 63
ds 0x23 35
es 0x23 35
fs 0x0  0
gs 0x0  0
(gdb) bt
#0  0x74c647e427ca in _sys___sigprocmask14 () from /usr/lib/libc.so.12
#1  0x74c642e096ee in pthread_sigmask () from /usr/lib/libpthread.so.1
#2  0x74c643628eee in util_queue_init () from 
/usr/X11R7/lib/modules/dri/i965_dri.so
#3  0x74c643627c8b in disk_cache_create () from 
/usr/X11R7/lib/modules/dri/i965_dri.so
#4  0x74c643626b1c in brw_disk_cache_init () from 
/usr/X11R7/lib/modules/dri/i965_dri.so
#5  0x74c6434e9091 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so
#6  0x74c643939da7 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so
#7  0x74c649247956 in ?? () from /usr/X11R7/lib/libGL.so.3
#8  0x74c64922e576 in __glXInitialize () from /usr/X11R7/lib/libGL.so.3
#9  0x74c64923013a in glXQueryVersion () from /usr/X11R7/lib/libGL.so.3
#10 0x00408cdd in GLStateGLX::check_glx_version 
(this=this@entry=0x7f7fff340100) at ../src/gl-state-glx.cpp:160
#11 0x0040904f in GLStateGLX::ensure_glx_fbconfig 
(this=this@entry=0x7f7fff340100) at ../src/gl-state-glx.cpp:241
#12 0x00409329 in GLStateGLX::gotNativeConfig (this=0x7f7fff340100, 
vid=@0x7f7fff33ff5c: 0) at ../src/gl-state-glx.cpp:128
#13 0x00407268 in CanvasGeneric::resize_no_viewport 
(this=this@entry=0x7f7fff340150, width=800, height=600) at 
../src/canvas-generic.cpp:225
#14 0x00408739 in CanvasGeneric::reset (this=0x7f7fff340150) at 
../src/canvas-generic.cpp:56
#15 0x004cdfa3 in main (argc=, argv=) at 
../src/main.cpp:198
(gdb) disas
Dump of assembler code for function _sys___sigprocmask14:
   0x74c647e427c0 <+0>: mov$0x125,%eax
   0x74c647e427c5 <+5>: mov%rcx,%r10
   0x74c647e427c8 <+8>: syscall 
=> 0x74c647e427ca <+10>:jb 0x74c647e427cd <_sys___sigprocmask14+13>
   0x74c647e427cc <+12>:retq   
   0x74c647e427cd <+13>:jmpq   0x74c647f999e0 <__cerror>
End of assembler dump.

Re: Mesa update

[coypu]

... but maybe we want to define -DPTHREADS?

Re: Mesa update

[coypu]

On Tue, Apr 09, 2019 at 12:17:46PM +0100, Patrick Welche wrote:
> On Tue, Apr 09, 2019 at 10:38:14AM +, co...@sdf.org wrote:
> > thanks to jmcneill for suggesting dlerror();
> > 
> > perhaps we need to remove -DGLX_USE_TLS. it otherwise uses TLS via
> > pthread.
> > 
> > /usr/X11R7/lib/libGL.so: Use of initialized Thread Local Storage with model 
> > initial-exec and dlopen is not supported
> > 
> > I'm going to test
> 
> Thanks!
> 
> (This might end up being "interesting":
> 
>   https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson.build#L346
> 
> so AFAICT the "default" meson build defines GLX_USE_TLS no matter what...)
> 
> 
> Cheers,
> 
> Patrick

There's a bunch of patches in the pkgsrc mesalib18, I'll give them a
try.

patch-src_glx_glxclient.h
patch-src_glx_glxcurrent.c
patch-src_mapi_entry__x86-64__tls.h
patch-src_mapi_entry__x86__tls.h
patch-src_mapi_u__current.c
patch-src_mapi_u__current.h

 (they apply with some fuzz)

Re: Mesa update

[coypu]

thanks to jmcneill for suggesting dlerror();

perhaps we need to remove -DGLX_USE_TLS. it otherwise uses TLS via
pthread.

/usr/X11R7/lib/libGL.so: Use of initialized Thread Local Storage with model 
initial-exec and dlopen is not supported

I'm going to test
Index: libmesa.mk
===
RCS file: /cvsroot/src/external/mit/xorg/lib/libmesa.mk,v
retrieving revision 1.6
diff -u -r1.6 libmesa.mk
--- libmesa.mk  3 Apr 2019 15:26:34 -   1.6
+++ libmesa.mk  9 Apr 2019 10:37:54 -
@@ -521,7 +521,6 @@
-DHAVE_LIBDRM -DGLX_USE_DRM \
-DGLX_INDIRECT_RENDERING \
-DGLX_DIRECT_RENDERING \
-   -DGLX_USE_TLS \
-DHAVE_X11_PLATFORM \
-DHAVE_DRM_PLATFORM \
-DENABLE_SHADER_CACHE \
Index: libGL/Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/libGL/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- libGL/Makefile  10 Mar 2019 10:51:58 -  1.23
+++ libGL/Makefile  9 Apr 2019 10:37:55 -
@@ -164,7 +164,7 @@
-DHAVE_FUNC_ATTRIBUTE_NORETURN=1 -DHAVE_ENDIAN_H=1 -DHAVE_DLADDR=1 \
-DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 \
-DHAVE_PTHREAD=1 -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 \
-   -DHAVE_TIMESPEC_GET -DGLX_USE_TLS
+   -DHAVE_TIMESPEC_GET
 
 .include "../asm.mk"
 
Index: libglapi/Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib/libglapi/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- libglapi/Makefile   10 Mar 2019 10:51:58 -  1.4
+++ libglapi/Makefile   9 Apr 2019 10:37:55 -
@@ -68,7 +68,6 @@
-DGLX_USE_DRM \
-DGLX_INDIRECT_RENDERING \
-DGLX_DIRECT_RENDERING \
-   -DGLX_USE_TLS \
-DHAVE_X11_PLATFORM \
-DHAVE_DRM_PLATFORM \
-DENABLE_SHADER_CACHE \

Mesa update

[coypu]

hi current-users,

-current is now going to use mesa 18.3.4, and on x86, LLVM for radeon
and software acceleration. It's faster and supports more modern OpenGL
functionality. Software raster on x86 is now done using the faster
llvmpipe.
(Thanks to mrg@ and joerg@).

This will increase your build times dramatically if you build Xorg on
x86, from building LLVM libraries.

If you would like to do an update build, you will likely have to remove
many directories in OBJDIR/external/mit/xorg/lib/*.
I didn't test this, sorry.

Let me know if there are any situations for which this fails to work. We
got really good testing of things before committing it so I don't expect
much trouble.

Re: failed to create llentry

[coypu]

Apparentlysome of the route table entries are special and should not be
deleted.
After flushing them and attempting to add a default route, I get these
messages over and over again.

ifconfig iwm0 10.0.0.1 delete
ifconfig iwm0 10.0.0.1

re-creates the magical route stuff so I can add a default route again

Re: failed to create llentry

[coypu]

I just don't want to need to set wpa_supplicant_flags, I don't
need set a billion flags for other programs, so why that one.
It won't even read the canonical config location unless I tell it to...

Re: failed to create llentry

[coypu]

On Wed, Nov 21, 2018 at 09:03:20PM +, Roy Marples wrote:
> On 21/11/2018 19:51, co...@sdf.org wrote:
> > -B -M -c /etc/wpa_supplicant.conf -s seem like really good flags,
> > thanks.
> > (are they good enough to be a default? right now anyone using wifi has
> > to have wpa_supplicant_flags set, so we can't break their usage)
> 
> Yes and no.
> We would need to ship a default wpa_supplicant.conf - probably enabling the
> default socket so wpa_cli(8) just works and commented out entries for
> connecting to any open ap and a specific ap with psk.
> 
> We might want to enable (but commented out maybe to start with) the ability
> instructions over the control socket to configure wpa_supplicant.conf as
> well.
> This would be handy for applications like dhcpcd-{gtk,qt}
> 
> Then, the user just has to set wpa_supplicant=YES in rc.conf and voila,
> wireless network setup with X11 and a systray application becomes a lot
> easier for the end user to setup.
> 
> > I can't unplug my card because it's PCI.
> > 
> > I'll try to investigate next time it happens
> 
> Another way of restarting things is to down/up the interface.
> 
> ifconfig urtwn down up
> 
> Does wonders - both wpa_supplicant and dhcpcd will react to this.
> There should be no need to kill anything with prejudice.

Yes a reboot usually does the trick, but savecore takes a while. It
would be faster to type 'reboot'

Re: failed to create llentry

[coypu]

-B -M -c /etc/wpa_supplicant.conf -s seem like really good flags,
thanks.
(are they good enough to be a default? right now anyone using wifi has
to have wpa_supplicant_flags set, so we can't break their usage)

I can't unplug my card because it's PCI.

I'll try to investigate next time it happens

Re: failed to create llentry

[coypu]

I don't like debugging problems with daemonized processes.
wpa_supplicant for example prints nothing to syslog. the messages it
gives to stdout are informative.

I'm quite grumpy about networking in netbsd in general.

Re: failed to create llentry

[coypu]

On Wed, Nov 21, 2018 at 11:56:23AM -0500, Greg Troxel wrote:
> co...@sdf.org writes:
> 
> > What are these messages about?
> > whenever my connection doesn't work, I need to tinker with manual
> > configuration and it prints a lot of that in dmesg.
> >
> > I am using wifi from a distance.
> 
> ARP (IPv4) and NDP (IPv6) data is stored in the routing table with the L
> flag.  I have seen llentry (or llinfo?) errors before, when the address
> resolution code is not able to create the routing able entry it wants.
> Perhaps this is because there is another entry with the same key
> already, but a different type.
> 
> If you want to send me full routing table dumps (netstat -nr) and
> ifconfig, I can look at it.  But I wonder if you are doing something odd
> (basically, anything other than configuring an address/prefix on one
> interface, and a default route, and letting routing/resolution deal with
> the rest).  In particular, I wonder if you are running anything like
> olsr.

I use wpa_supplicant and dhcpcd. When dhcpcd fails to configure the
network I start doing it manually. I don't really pay attention to when
the errors occur but I'll try to keep a closer track about when they
start.

dhcpcd will mysteriously fail while I am connected with wpa_supplicant,
so I'd kill it and do:
pkill -9 dhcpcd
route -n flush
route -n flushall
ifconfig iwm0 local-ip-i-should-have
route add default gateway

Usually when these problems happen one of the following occurs too:
- wpa_supplicant will complain it can't assign an address every hour or
  so, and network traffic will stop for a bit
- I'll accidentally restart wpa_supplicant before killling all network
  traffic and get a kernel panic

I guess wpa_supplicant does more than I want to do and run into
conflicts with manual setup.

failed to create llentry

[coypu]

What are these messages about?
whenever my connection doesn't work, I need to tinker with manual
configuration and it prints a lot of that in dmesg.

I am using wifi from a distance.

undefined reference to `logf@GLIBCXX_3.4' fix

[coypu]

If you are seeing this error, which affects only -current, it is because
the libstdc++ configuration was slightly wrong for a few months.
Fixing involved removing a symbol, so you get an undefined reference.

If you see:
/usr/pkgobj/graphics/gimp/work/.buildlink/lib/libexiv2.so: undefined reference 
to `logf@GLIBCXX_3.4'

Do:
pkg_info -Fe /usr/pkg/lib/libexiv2.so
To find which package is affected by the ABI breakage, and rebuild it to
get correct references.

Subtle memory issue?

[coypu]

Hi,

I was debugging a random crash in irssi, which is usually good about not
segfaulting except in very unusual circumstances.

While debugging this, I managed to get:
/usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/utils.c:1079: 
internal-error: virtual memory exhausted.

(gdb 7.12, before the massive changes by christos).

Did someone/something subtly break memory again?
I have SVS disabled.
NetBSD localhost 8.99.12 NetBSD 8.99.12 (GENERIC) #3: Fri Jan 12 16:43:01 IST 
2018 fly@localhost:/home/fly/obj/sys/arch/amd64/compile/GENERIC amd64

drm/ttm assert

[coypu]

Hi folks,

I don't have the time/energy to tackle this now,
in case anyone needs a data point (I haven't seen similar complaints)

2017-12-9 kernel, starting p Xorg/firefox. No heavy use.

panic: kernel diagnostic assertion "!ISSET(ttm->page_flags, 
TTM_PAGE_FLAG_SWAPPED)" failed: file 
"/usr/src/sys/external/bsd/drm2/dist/drm/ttm/t
tm_tt.c", line 418
ttm_tt_unwire() at netbsd:ttm_tt_unwire+0xc5
ttm_bus_dma_populate() at netbsd:ttm_bus_dma_populate+0x14f
ttm_tt_bind() at netbsd:ttm_tt_bind+0x26
ttm_bo_handle_move_mem() at netbsd:ttm_bo_handle_move_mem+0x61a
ttm_bo_validate() at netbsd:ttm_bo_validate+0x238
ttm_bo_init() at netbsd:ttm_bo_init+0x213
nouveau_bo_new() at netbsd:nouveau_bo_new+0x200
nouveau_gem_new() at netbsd:nouveau_gem_new+0x53
nouveau_gem_ioctl_new() at netbsd:nouveau_gem_ioctl_new+0x9d
drm_ioctl() at netbsd:drm_ioctl+0x11e
sys_ioctl() at netbsd:sys_ioctl+0x101
yscall() at netbsd:syscall+0x1d8
--- syscall (number 54) ---

Re: pool_grow hangs (Re: CVS commit: src/sys)

[coypu]

On Fri, Dec 29, 2017 at 03:41:42PM +0100, Tobias Nygren wrote:
> The machine has survived for 30+ minutes where it previously hung after
> just 20 seconds.

Do you mean "30+ minutes so far" or does it still hang somewhere? where?

Re: Autoexpand of root file system after image copy - need something better

[coypu]

On Tue, Dec 26, 2017 at 12:15:16AM -0500, Alan Corey wrote:
> Seems like a simple solution would be to expand it to the size of the
> partition, or if there's no partition maybe ask.  So you use your
> fdisk or gparted or whatever first if you know you want other things
> in part of the space.  Then have the expansion respect the partition
> size.  OpenBSD setup asks early on if you want to use the whole medium
> space.  Same idea, this is when creating a disklabel I think.  It also
> simplifies replacing the contents of a partition with part of another
> operation system for instance.

rpi.img isn't an installer though, and we probably should not assume
that the user has an interactive setup and can provide input.

you can shrink a filesystem, though resize_ffs doesn't allow it on FFSv2
for some unclear reason.

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[coypu]

I still think that we should remove offensive quotes, and if people
cannot agree on it, all of fortune.

Don't confuse my interest in de-escalation with giving up.

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[coypu]

I had the commit message written out and everything.
I'm not sure why we have such a lengthy discussion about a game.

If we care so much about games, I'm gonna plug my pkgsrc games wishlist:
https://github.com/SuperV1234/SSVOpenHexagon
https://github.com/ppy/osu

They should be really good.

Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]

[coypu]

On Sun, Nov 19, 2017 at 05:58:12PM +0100, Marc Balmer wrote:
> You should grow some balls.  Not in the biological sense, of course.

I did, that's why I went ahead and removed them. christos reverted my
commit.

Re: Ralink usb not working in Netbsd 8 (RPI2 and SUNXI)

[coypu]

One of the possible causes is changes in the driver itself, too.
We've synced the source with the version of the code in another BSD.

Which card is it?

Re: CVS commit: src

[coypu]

I've heard of how some legacy systems powering the world. Like
Melbourne's train network which runs on Windows XP ... emulating a
PDP-11. There's certainly a real world need for it.

But if someone wants to do things like that with NetBSD, it can't be a
default and he needs to be proactive about handling bugs. Now we are at
a point people who don't see a benefit to it are fixing bugs, and that
is a point where it should become a deletion candidate, not a disable
candidate.

Re: CVS commit: src

[coypu]

Someone recently tried pkgsrc on SCO OpenServer5. I'm pretty new so I
haven't heard of these operating systems before. It was an interesting
experience.

pkgsrc/bootstrap/README.OpenServer5 has the instructions.

You start with the all-shiny GCC 2.99.3, patched. then use it to build
a patched GCC 4.2, which is the last version to support SCO/x86.

(GCC 4.8 is almost the minimum version for an acceptable pkgsrc
experience, as C++11 is pretty widespread)

After the GCC hurdle, be sure to replace rm with a version that supports
deleting files over 2GB. when I looked up what is wrong with it, I
found this remarkable response, suggesting that for the sake of
compatibility, it shouldn't be fixed, or anything, ever.
http://lists.celestial.com/pipermail/sco-misc/2007-September/010474.html
(Spoiler alert from the next message: it wasn't because of compat)

So, it's not just SCO, but that was my first impression of the system. I
find it really hard to believe this system can run anything currently
useful.

Re: Using NET_MPSAFE

[coypu]

On Tue, Aug 08, 2017 at 04:53:11PM -0700, Brian Buhrow wrote:
>   We also use pf(4) extensively.  Unfortunately, npf(4) doesn't have all
> the functionality we need to implement the configurations we use.

Could you mention which functionality you are lacking? (to add to a list)

Thanks.

Re: cross-compiling kernel

[coypu]

./build.sh -U -u -m i386 kernel=CONFNAME doesn't work?

Re: How to run X11 on ATI Radeon 9000?

[coypu]

On Wed, Aug 02, 2017 at 06:44:00PM +0200, Adam Ciarciński wrote:
> And I not able to compile a kernel with 'radeondrm' driver.

To do this, you need to disable the new drm drivers too.
old drm conflicts with new.

Re: file system panic on -current (amd64)

[coypu]

On Fri, Jul 28, 2017 at 07:23:30PM +0800, Paul Goyette wrote:

> (manually transcribed - my USB keyboard attached via XHCI doesn't
> play nicely with ddb):

Sometimes I disable all uhci, ehci, xhci to get activity in ddb based on
PS/2 emulation. I think it worked once...

sysctl -w ddb.onpanic=0 will dump core, which is probably preferable.
And if it fails, it's sometimes visible in dmesg scrollback.

>   wapbl_stop
>   wapbl_begin + 0x5b
>   genfs_do_putpages + x1014
>   VOP_PUTPAGES + 0x3a
>   ffs_full_fsync + 0xe5
>   ffs_fsync + 0x3a
>   VOP_FSYNC + 0x3a
>   sched_sync + 0x198

What's the panic reason?
Do you have a netbsd.gdb for line numbers (especially of the last part)?

Thanks,

Re: compiler segfault building audio/musicpd

[coypu]

On Sat, Jul 22, 2017 at 07:34:41PM +, co...@sdf.org wrote:
> I'm putting my money on this being the cause:
> https://github.com/NetBSD/src/commit/effc84a293b4ecbe2ff7b2d54c54dee1e7e90c7a

Reverting this commit fixes the ICE.

Re: compiler segfault building audio/musicpd

[coypu]

I'm putting my money on this being the cause:
https://github.com/NetBSD/src/commit/effc84a293b4ecbe2ff7b2d54c54dee1e7e90c7a

Re: nouveau reboot

[coypu]

(in case you missed it)
Kernel lock error: _kernel_lock,216: spinout < it's stuck

Not a locking issue

Re: How to get started with pkgsrc, or is it sh bug?

[coypu]

On Fri, Jul 21, 2017 at 07:14:44AM +, Thomas Mueller wrote:
> sh: /usr/pkg/sbin/pkg_info: not found
> sh: /usr/pkg/sbin/pkg_admin: not found

run 'which make' and mv /etc/mk.conf /etc/mk.conf.old
make should probably be /usr/bin/make but things can get weird with
(partial?) bootstrap.

Re: nouveau reboot

[coypu]

On Thu, Jul 13, 2017 at 09:49:32AM +0100, Patrick Welche wrote:
> or "new" reboot: just updated a working 3rd July amd64
> kernel with this morning's source, and the computer reboots after
> printing nouveau, but before drm. Haven't had a chance to dig (won't
> until tonight) - any first guesses?

Must be unrelated to nouveau. no changes in sys/external/bsd/drm2 since
June 1.

Re: netbsd-8 broken: sbin/fsck_lfs/lfs.c:369:4: error: 'struct inode' has no member named 'i_flag'

[coypu]

I renamed i_flag to i_state in -current after the -8 branch.
It looks like -current headers being used for building -8.

Re: Xen/i386 HEAD fails

[coypu]

On Sun, Jun 25, 2017 at 12:21:56AM +0200, Manuel Bouyer wrote:
> The problem is that ddb isn't working any more so I can't get a stack trace,
> which would be very helpfull. But I suspect the ddb problem is
> much older than that (and is also present in netbsd-8).

fwiw ddb works fine on my (non-xen) amd64 machine.

Re: Xen/i386 HEAD fails

[coypu]

Try bisect

Re: Xen/i386 HEAD fails

[coypu]

I suspect this might be a PAE problem, and not many people use PAE.
There were lots of changes to x86 code that day.

I would personally start with trying to see if reverting this commit
helps:
http://mail-index.netbsd.org/source-changes/2017/06/14/msg085330.html

I think endext=MAXIOMEM+1 may be wrong for PAE.

Note some of it went into -8, so fixes need to be pulled up too.

Re: heads-up: sh changes (perhaps fragility)

[coypu]

UPDATE: Not so fast!  I tried the update on amd64 and found the
resulting kernel broke dhcpcd and dhclient in combination with re(4)
driver, making it impossible to access the Internet.


That was the opencrypto stuff. I made kern/52277 for it. under heavier
load it would panic, but running dhcpcd as-is would hang in
rand_add_uint32 or so.
I think it's fine now, but haven't tested since I moved around.

Re: heads-up: sh changes (perhaps fragility)

[coypu]

Hi kre,
I'm your tester today!

$ whoami; file /home/fly/.Xresources; file ~/.Xresources
fly
/home/fly/.Xresources: ASCII text
~/.Xresources: cannot open `~/.Xresources' (No such file or directory)

~ does not expand as before.
I believe that I tested with the latest, too.

Thanks for working on sh

Re: X Server struggle

[coypu]

On Sun, Apr 30, 2017 at 02:44:27PM -0500, Robert Nestor wrote:
> Tried “Xorg” and then looked at the Xorg.0.log file and find “No screens”. 

I seem to recall the various X commands aren't all the same. I use 'startx',
I'm not sure what additional things it does.

Also, what hardware is it?

Re: Packages crashing on -current

[coypu]

On Fri, Apr 21, 2017 at 05:31:12PM -0400, Michael wrote:
> Midori ( and likely everything else using webkit ) has a similar problem
> - it doesn't crash, but javascript doesn't work until all the mprotect
> stuff is disabled.
> 

I've adjusted the package, thanks!

someone mentioned the implementation detail is that we downgrade RWX
mappings to RW silently, so it isn't midori being clever, but
arch-specific stuff. which arch is it?

do we want/can make all archs to behave the same?

Packages crashing on -current

[coypu]

Hi,

mprotect (and ASLR) are security measures that not all pkgsrc packages
can survive, so some packages had NOT_PAX_MPROTECT_SAFE set for some
binaries, to disable it.

However the condition for using NOT_PAX_MPROTECT_SAFE was incorrectly
only done for NetBSD/amd64.

The outcome should've been things like (only on -current, stable is
unaffected as it doesn't have pax mprotect enabled):
- Firefox crashes
- Libreoffice segfaults during build
etc.

You can test if mprotect is disabled e.g. for firefox using file:
> file /usr/pkg/lib/firefox/firefox
/usr/pkg/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 
(SYSV), dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 
7.99.65, PaX: -mprotect, 
BuildID[sha1]=577897fd2966e904de0c47df56c5af86b3d9312b, stripped

Noteworthy part: PaX: -mprotect

Newly built packages will disable it on a per-file basis (now not only
on amd64), but unfortunately there are many files to adjust.
If you just want it fixed now, a quick workaround is disabling mprotect
globally:
  # sysctl -w security.pax.mprotect.enabled=0

You can disable it on a per-file basis, which is what all new packages
will do now, using:
  # paxctl +m /path/to/binary

Re: No console

[coypu]

Use 'userconf disable nouveau
userconf disable nouveaufb'

Re: OSS audio and version #s

[coypu]

oss was accidentially bumped and reverted.

Re: x86 firefox build failure

[coypu]

Often that'd be because of running out of memory.
The bottom of dmesg should say things like "... killed, out of swap".

Is that what happened?

Re: Can't build current on old version of NetBSD

[coypu]

I wonder if the build.sh command has to do with it.
For the record, I use a command like so (no other steps):
  ./build.sh -U -u -j20 -m amd64 -O ../obj release

Re: Keyboard freeze on new laptop

[coypu]

I have exactly the same issue after resume from
suspend on a Dell Inspiron n4030. I made xsrc/51390
as a bug report for it.

I wonder whether something sleeping is a cause, since
it is related to suspend/resume in my case.

No immediate suggestions though.

Re: re(4) bpf-related assert

[coypu]

On Fri, Feb 17, 2017 at 07:50:26PM +0900, Ryota Ozaki wrote:
> 
> Sorry, I forgot to make re use the deferred if_start mechanism.
> 
> Could you try the patch?
>   ozaki-r
> 
> diff --git a/sys/dev/ic/rtl8169.c b/sys/dev/ic/rtl8169.c
> index 691afa4..d262af1 100644
> --- a/sys/dev/ic/rtl8169.c
> +++ b/sys/dev/ic/rtl8169.c
> @@ -869,6 +869,7 @@ re_attach(struct rtk_softc *sc)
>  * Call MI attach routine.
>  */
> if_attach(ifp);
> +   if_deferred_start_init(ifp, NULL);
> ether_ifattach(ifp, eaddr);
> 
> rnd_attach_source(>rnd_source, device_xname(sc->sc_dev),
> @@ -1496,8 +1497,8 @@ re_intr(void *arg)
> }
> }
> 
> -   if (handled && !IFQ_IS_EMPTY(>if_snd))
> -   re_start(ifp);
> +   if (handled)
> +   if_schedule_deferred_start(ifp);
> 
> rnd_add_uint32(>rnd_source, status);

I will, thanks!
I hope I can reproduce it.

re(4) bpf-related assert

[coypu]

Hi,

I'm using:
re0 at pci8 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 
0x06)

while using -current I got:
System panicked: kernel diagnostic assertion "!cpu_intr_p()" failed: file 
"/usr/src/sys/net/bpf.c", line 1577 

_KERNEL_OPT_NARCNET() at 0
?() at 80001d563000
vpanic() at vpanic+0x149
ch_voltag_convert_in() at ch_voltag_convert_in
_bpf_mtap() at _bpf_mtap+0x48f
re_start() at re_start+0x3d8
re_intr() at re_intr+0x176
intr_biglock_wrapper() at intr_biglock_wrapper+0x1d
Xintr_ioapic_edge18() at Xintr_ioapic_edge18+0xee
--- interrupt ---
Xspllower() at Xspllower+0xe
callout_softclock() at callout_softclock+0x41c
softint_dispatch() at softint_dispatch+0xda

how should bpf_mtap callers be adjusted in this case?

thanks.

Re: audio/moc dumps core in libcurses

[coypu]

Hi,

I've applied a patch to audio/moc. It works on my end now.
It was attempting set_escdelay (25); very early, before setting
up a window.

On nbcurses it was:_cursesi_screen->ESCDELAY = escdelay;
which was a null deref.

for ncurses, it was returning an error, but it was ignoring it.

I've moved the call a bit later in the setup.

Re: -current MKTPM=1 build failure

[coypu]

Please put sys/stat.h first though.
(as per share/misc/style)

otherwise lgtm, xtos had to add dozens of these.

Re: i915 hangs after 201612251500Z changes

[coypu]

Hi,

Can you bisect to find the offending commit?
It should only take a few attempts to tell, and only
kernel has to be rebuilt probably.

Nothing sticks out as being i915 related, maybe uvm
changes.

Thanks.

Re: evbarm builds failing

[coypu]

My motivation was preventing the builds from breaking down
for long periods of time until someone bumps a size every
time firmware gets added.

It doesn't sound like a frequent thing, but wifi devices
are pretty terrible about it. Realtek has some per-region
devices with each having its own firmware.

As long as it was useful to someone, that's fine. I didn't
know the earliest RPI didn't have an ethernet port, and I
can imagine someone not having an ethernet port on a second
machine, too.

Re: evbarm builds failing

[coypu]

I've only seen INSTALL stuff being super-duper
minimal thus far. the LOONGSON INSTALL kernel doesn't
even have 'dmesg'.

A tiny install was great for quickly loading over the
network.

RPI has another much nicer option for installing, which
is dd'ing rpi.img to an SD card. comes with everything,
all the sets, etc.

Re: evbarm builds failing

[coypu]

On Thu, Dec 29, 2016 at 03:13:57PM +0100, Martin Husemann wrote:
> I have also seen my alpha's root disk overflow recently, and of course
> it can't use any of this (I did not yet get around to install the TC-USB
> adaptor).
> 
> Maybe we should put firmware in different sets based on the bus the
> device "usually" attaches to?
> 

Doesn't alpha have radeon? or does only the newer radeon
need firmware?

Most of it is wifi, which tends to PCI and USB.

Unrelated, rtwn/urtwn are basically the same driver (we're
behind on deduping them), and have separate firmware
currently.

evbarm builds failing

[coypu]

Hi,

evbarm builds have been failing for the past
11 days. I think this is because of this single
line in src/distrib/evbarm/instkernel/sshramdisk/Makefile,

IMAGEPREBUILD=  ${TOOL_PAX} -rw -pp ${DESTDIR}/libdata/firmware ${WORKDIR}

It copies *all* of the firmware files for the install
kernels, and someone added one, and now:


--- netbsd-RPI2_INSTALL ---
got symbols from netbsd-RPI2_INSTALL.tmp
root @ 0x5706a8/15204352
armv7--netbsdelf-eabihf-mdsetimage: fs image (2048 bytes) too big for 
buffer (15204352 bytes)

the install kernels tend to be small and minimal... all of the
firmware in ${DESTDIR}/libdata/firmware is for wifi and for
radeon, I don't think it's absolutely essential. it's not
standard hardware for RPI.

Should it not install this firmware at all?

Re: Build fix for sh3 - only built tested

[coypu]

cherry committed something that probably works.

Build fix for sh3 - only built tested

[coypu]

Hi, the following seems to fix the build of
sh3 and doesn't seem to invasive.

feel free to use it, or any other solution.

I have no sh3 hardware to test it.
Index: sh3/pmap.c
===
RCS file: /cvsroot/src/sys/arch/sh3/sh3/pmap.c,v
retrieving revision 1.79
diff -u -p -u -r1.79 pmap.c
--- sh3/pmap.c  23 Dec 2016 07:15:28 -  1.79
+++ sh3/pmap.c  23 Dec 2016 18:20:43 -
@@ -128,7 +128,7 @@ vaddr_t
 pmap_steal_memory(vsize_t size, vaddr_t *vstart, vaddr_t *vend)
 {
int npage;
-   paddr_t pa;
+   paddr_t start;
vaddr_t va;
uvm_physseg_t bank;
 
@@ -147,9 +147,9 @@ pmap_steal_memory(vsize_t size, vaddr_t 
KDASSERT(uvm_physseg_valid_p(bank));
 
/* Steal pages */
-   pa = ptoa(uvm_physseg_get_start(bank));
+   start = uvm_physseg_get_start(bank);
uvm_physseg_unplug(start, npage);
-   va = SH3_PHYS_TO_P1SEG(pa);
+   va = SH3_PHYS_TO_P1SEG(ptoa(start));
memset((void *)va, 0, size);
 
return (va);

Re: Automated report: NetBSD-current/i386 build failure

[coypu]

Fixed

Re: Automated report: NetBSD-current/i386 build failure

[coypu]

On Thu, Dec 22, 2016 at 01:45:39PM +, NetBSD Test Fixture wrote:
> --
> ./usr/share/man/html9/uvm_hotplug.html
> ./usr/share/man/man9/uvm_hotplug.9
> =  end of 2 extra files  ===
> *** [checkflist] Error code 1
> nbmake[2]: stopped in 
> /tmp/bracket/build/2016.12.22.11.46.48-i386/src/distrib/sets
> 1 error

I already committed a fix for this.

Re: please test i915 (nvidia alignment fix)

[coypu]

Thanks! No need for more testing, I was only
paranoid I broke something in a horrible way.

please test i915 (nvidia alignment fix)

[coypu]

Hi!

I've committed something that is supposed to help
with the console appearing broken on most nvidia
hardware here:
http://mail-index.netbsd.org/source-changes/2016/12/12/msg079782.html

The code is shared with i915 (but not radeon, at
least not yet). I'd really love if someone
confirmed that i915 is not horribly broken, so
it could be pulled up to netbsd-7 (I have no
Intel graphics hardware).

radeon should be unaffected.

Thanks.

Re: xorg.conf is read but not acted on correctly

[coypu]

On Sat, Dec 10, 2016 at 08:45:29PM +0100, Tom Ivar Helbekkmo wrote:
> co...@sdf.org writes:
> 
> > (I dunno why it would be different on NetBSD than linux...
> > the xorg bits are identical).
> 
> It's probably at a lower level.  NetBSD fails to display the (text)
> console correctly with the nouveau driver, so I have to wait anxiously
> for the psychedelic, misaligned scan lines to eventually be replaced by
> a proper xdm login screen...  :)
> 

Try this:

Index: drmfb.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/drm/drmfb.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 drmfb.c
--- drmfb.c 9 Nov 2015 23:11:18 -   1.2
+++ drmfb.c 10 Dec 2016 19:47:16 -
@@ -105,7 +105,7 @@ drmfb_attach(struct drmfb_softc *sc, con
prop_dictionary_set_uint8(dict, "depth", sizes->surface_bpp);
prop_dictionary_set_uint16(dict, "linebytes",
roundup2((sizes->surface_width * howmany(sizes->surface_bpp, 8)),
-   64));
+   256));
prop_dictionary_set_uint32(dict, "address", 0); /* XXX >32-bit */
CTASSERT(sizeof(uintptr_t) <= sizeof(uint64_t));
prop_dictionary_set_uint64(dict, "virtual_address",

Re: xorg.conf is read but not acted on correctly

[coypu]

Sorry that I'm not giving the 'right' answer that is
xorg.conf, I just spent so much time in the past
trying to make it work and it was always a huge pain
and I want more people to enjoy this welcome change.

Re: xorg.conf is read but not acted on correctly

[coypu]

On Sat, Dec 10, 2016 at 08:15:55PM +0100, Tom Ivar Helbekkmo wrote:
> I just tried attaching an external monitor to my old Dell Latitude E6400
> laptop.  The plug is VGA style. Linux happily tells me I have two
> monitors, with different resolutions, and it finds the correct maximum
> resolution of the external monitor.  NetBSD (using the nouveau driver)
> decides to run both in parallel, and since it can't figure out the
> resolution of the external monitor, it selects 640x480 for the pair.
> 
> Is there a simple xorg.conf I can create to help resolve this?
> 

xrandr is an option for setting resolution of monitors
(with x11/arandr able to generate a viable command, it's
not the most user friendly command). This is assuming it
recognises a higher resolution.

specifically for nouveau on NetBSD, there's a bug with
setting resolutions, for drmfb I've been able to workaround
it by rounding to the nearest 256 byte (nvidia hardware
requires this alignment), I guess the same is needed in
Xorg too but I still haven't found the place to put it.
(I dunno why it would be different on NetBSD than linux...
the xorg bits are identical).

It's not really the 'old' way, but it has a huge upside:
you can change resolution without restarting X (assuming
you managed to cobble together a viable xorg.conf).

Re: xorg.conf is read but not acted on correctly

[coypu]

On Sat, Dec 10, 2016 at 04:53:46PM +, Dave Tyson wrote:
> I normally don't bother creating a /etc/X11/xorg.conf file as the built-in 
> defaults generally work OK. I just tried to create one using X -configure and 
> then edited it to (a) allow for ms-ttf font and (b) set the keyboard layout 
> "uk"
> 

Not that your way should be broken, but the recommendation today
and possibly easier path is, for setting e.g. keyboard layout:

  setxkbmap -option grp:alt_shift_toggle us,il &
(From my ~/.xinitrc)

ms-ttf is a pkgsrc package (fonts/ms-ttf), and I reckon it'd
put it at a recognised path without needing to adjust configs.

W^X mmap

[coypu]

Hi!

Why doesn't the following code get rejected by pax mprotect?

#include 
#include 

int main() {
int * a;
a = mmap(NULL, BUFSIZ, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANON, 
-1, 2);
if (a == MAP_FAILED)
printf("mmap failed\n");
return 0;
}


thanks.

Re: Weird results from nmap

[coypu]

On Sat, Nov 12, 2016 at 11:11:34AM +0100, Martin Husemann wrote:
> What exactly are you testing? It seems to work fine for me; typical output
> from nmap -v $one_of_my_servers:

Hmm, might be an oddity of my own network.
It works fine with localhost, but not on random external servers.

Weird results from nmap

[coypu]

Hi,

I noticed that if I use nmap, it will always say that a port is open.
(nmap -O will even say it cannot find a single closed port)
Which is obviously not true for some of the servers I've checked.. I think.

The functionality itself is not important to me, perhaps it's indicating
that some network functionality was broken.

Re: 7.99.42/Nov 2 panic: kernel diagnostic assertion "l->l_md.md_gc_ptp == NULL" failed

[coypu]

49691

Re: Lenovo T410, enabling C3 state works perfect

[coypu]

On Sun, Nov 06, 2016 at 11:32:21AM +0100, kue...@posteo.de wrote:
> 40 while idle, with fan spinning down. Suspend and resume works fine, I only
> have to switch
> manually to X by using Strg+Alt+F5 after resume, but this was the case with
> the standard

Out of curiosity, does your touchpad show up as pms or ums? I've had
some issues related to that on resume.

Re: ffs_newvnode: inode has non zero blocks

[coypu]

On Wed, Nov 02, 2016 at 10:50:51PM +0200, Andreas Gustafsson wrote:
> co...@sdf.org wrote:
> > There was recently an issue with resize_ffs mishandling a non zero
> > filled expansion of FFSv2 (PR 51116). I wonder if this is similar.
> > 
> > i.e., does zeroing out the disk help?
> 
> If I read the code of the test case correctly, it involves growing a
> file system image stored in a file, causing the file to grow
> correspondingly.  Since the expansion does not even exist in the image
> file prior before resize_ffs is run, there is no way for it to have
> non-zero content.
> -- 
> Andreas Gustafsson, g...@gson.org

The lengthy problem description is not very important as it was fixed
I am just wondering about the setup of the tests, if there's a
possibility of bad data being left over (reuse of image, etc.)

Re: ffs_newvnode: inode has non zero blocks

[coypu]

On Wed, Nov 02, 2016 at 07:39:01PM +0200, Andreas Gustafsson wrote:
> 
> The strange thing is that this problem seems to have started soon
> after your report, not before it as I would expect if it were also the
> cause of your crash.  The filesystems involved are all newly created
> in each test run.
> -- 
> Andreas Gustafsson, g...@gson.org

Hi,

There was recently an issue with resize_ffs mishandling a non zero
filled expansion of FFSv2 (PR 51116). I wonder if this is similar.

i.e., does zeroing out the disk help?

Re: ffs_newvnode: inode has non zero blocks

[coypu]

On Sat, Oct 29, 2016 at 06:06:18PM +, Christos Zoulas wrote:
> In article <20161029175845.ga6...@sdf.org>,   wrote:
> >Hi,
> >
> >I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to
> >accumulate a problem:
> >
> >  ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero
> >blocks 980 or size 0
> >  panic: ffs_newvnode: dirty filesystem?
> >
> >It appears that fsck is not able to clear it.
> >
> >Do you we have a tool for such circumstances?
> 
> This means that you are on ffsv1, which makes it weird. There is clri
> and fsdb for that.
> 
> christos

Cool, thanks!

I do appear to have some franken-filesystem, half FFSv2, half FFSv1.

file system: /dev/rwd0a
format  FFSv1
endian  little-endian
magic   11954   timeSat Oct 29 21:16:21 2016
superblock location 8192id  [ 56f77746 7e87473b ]
cylgrp  dynamic inodes  4.4BSD  sblock  FFSv2   fslevel 4
...

ffs_newvnode: inode has non zero blocks

[coypu]

Hi,

I'm pretty 'abusive' to my machine. unsurprisingly, I've managed to accumulate 
a problem:

  ffs_newvnode: ino=20681997 on /: gen 5ae8a721/5ae8a721 has non zero blocks 
980 or size 0
  panic: ffs_newvnode: dirty filesystem?

It appears that fsck is not able to clear it.

Do you we have a tool for such circumstances?

Re: libc_fp* entries for mips debug set?

[coypu]

On Fri, Oct 21, 2016 at 05:18:44AM -0500, John D. Baker wrote:
> On Fri, 21 Oct 2016, Martin Husemann wrote:
> 
> > On Thu, Oct 20, 2016 at 06:50:22PM -0500, John D. Baker wrote:
> > > Entries for these files crept into "distrib/sets/lists/debug/ad.mips":
> > > 
> > > ./usr/lib/64/libc_fp_g.a
> > > ./usr/lib/libc_fp_g.a
> > > ./usr/lib/o32/libc_fp_g.a
> > > 
> > > but these files currently don't get built, breaking MKDEBUG_LIB=yes
> > > builds.
> > 
> > They are marked softfloat and arch64, which looks correct to me, and my
> > evbmips64-eb build with MKDEBUG and MKDEBUGLIB just worked fine.
> > 
> > For what machine/arch do you get the failure exactly?
> 
> This is evbmips-mips64el for my Lemote YeeLoong.
> 
> I had to remove the entries for those files to allow my build to
> complete, otherwise it complained about files in flist but missing
> from DESTDIR.
> 
> Perhaps it's an issue with running an update build?
> 

Possibly, the libc_fp inclusion required some Makefile changes.
I imagine that those don't trigger a rebuild of the relevant parts.

Try a clean build?

Assert on shutdown

[coypu]

In case this is interesting.
I'm not sure if I can reproduce it yet

acpibut0: power button pressed, shutting down!
syncing disks... 4 done
unmounted /dev/sd2a on /mnt type msdos
unmounted tmpfs on /var/shm type tmpfs
unmounted procfs on /proc type procfs
unmounted kernfs on /kern type kernfs
sd0: detached
scsibus0: detached
cd0: detached
atapibus0: detached
audio0: detached
atabus1: detached
pci6: detached
pci5: detached
pci2: detached
sysbeep0: detached
midi0: detached
ppb5: detached
ppb4: detached
ppb1: detached
audio1: detached
forcefully unmounted ptyfs on /dev/pts type ptyfs
forcefully unmounted tmpfs on /tmp type tmpfs
Skipping crash dump on recursive panic
panic: kernel diagnostic assertion "offset != 0 && offset < softint_bytes" 
failed: file "/usr/src/sys/kern/kern_softint.c", line 484 0 8192
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
cd_play_msf() at netbsd:cd_play_msf
softint_schedule() at netbsd:softint_schedule+0x7e
audio_pint() at netbsd:audio_pint+0x39e
hdafg_stream_intr() at netbsd:hdafg_stream_intr+0xc2
hdaudio_intr() at netbsd:hdaudio_intr+0x9e
Xintr_ioapic_level4() at netbsd:Xintr_ioapic_level4+0xf2
--- interrupt ---
x86_pause() at netbsd:x86_pause+0x2
sleepq_block() at netbsd:sleepq_block+0x1c5
cv_timedwait_sig() at netbsd:cv_timedwait_sig+0x107
ttysleep() at netbsd:ttysleep+0x7c
ttread() at netbsd:ttread+0x296
cdev_read() at netbsd:cdev_read+0x70
spec_read() at netbsd:spec_read+0xc3
VOP_READ() at netbsd:VOP_READ+0x37
vn_read() at netbsd:vn_read+0x94
dofileread() at netbsd:dofileread+0x8f
sys_read() at netbsd:sys_read+0x5f
syscall() at netbsd:syscall+0x15b
--- syscall (number 3) ---
7db7c203da7a:
cpu0: End traceback...
rebooting...
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
..

Re: new panic: trap.c line 314

[coypu]

On Sun, Oct 02, 2016 at 09:21:45AM +0200, Thomas Klausner wrote:
> Hi!
> 
> I just had a new panic with a 7.99.39/amd64. Light load, just some
> network + disk.
> 
> panic: kernel diagnostic assertion "onfault == kcopy_fault || rcr2() < 
> VM_MAXUSER_ADDRESS" failed: file ".../src/sys/arch/amd64/amd64/trap.c", line 
> 314
> 
> crashdump available.
> 
> Any ideas?
>  Thomas

maxv already reverted this, I believe.
http://mail-index.netbsd.org/source-changes/2016/09/25/msg077983.html

Re: Shutdown hangs if umass(4) media still mounted

[coypu]

Hi, I'm seeing a similar issue with using wireless (internal card is USB)
on a lemote yeeloong w/ 7.99.39..

After some time, it will cease to work, and dmesg will show:
ehci_sync_hc: cv_timedwait() = 35
..

If I attempt to use it.

It did work successfully for a few hours though.

Was wireless working for more than a few hours in the past?

Pointers welcome :-)

building with -march=native

[coypu]

hi,
how do I use -march=native for building netbsd? I'm running into errors:

--- consttime_memequal.po ---
error: the 'sse' unit is not supported with this instruction set
--- clock_subr.po ---
error: the 'sse' unit is not supported with this instruction set
--- clock_subr.pico ---
error: the 'sse' unit is not supported with this instruction set

am using clang because gcc doesn't support -march=native (it's
linux-only now)

thanks

Re: bind -> unbound/nsd

[coypu]

On Sun, Aug 21, 2016 at 03:07:18PM -0700, John Nemeth wrote:
>  There are regular pullups for security issues.  Thus your list
> would only be correct for 6.0 itself, and not for subsequent 6.x
> releases.  And, if one didn't update from 6.0 at all, there would
> be plenty of other issues (both OpenSSL and OpenSSH regularly get
> CVEs for example).
> 

Would we update for security reasons despite the license change?

Re: bind -> unbound/nsd

[coypu]

On Thu, Aug 18, 2016 at 11:10:18AM -0400, Christos Zoulas wrote:
> 
> Hello,
> 
> The recent change of ISC/bind licensing from BSD to MPL for the
> next release has provided us with an opportunity to re-evaluate
> the preferred daemon status for NetBSD and DNS resolution. Board/Core
> have decided not to import the next version of bind, and instead
> import the current version of unbound/nsd.
> 
> If you feel that this creates problems for you, let us know.
> Also you should be able to use newer versions of bind from pkgsrc.
> We are not planning to de-support or remove bind for NetBSD-8.
> 
> Best,
> 
> christos

Hi,

This may not be 100% factually correct (I'm trying my best, but not too
familiar with BIND):

NetBSD 6.0 was released in Oct 2012. If we had done such a decision
several months before the release, the version of BIND we would have in
base for 6.x is ~9.9.0.

This is a list of the vulnerabilities that our 6.x base BIND would
contain in this scenario, which would resemble what we will see towards
the end of the 8.x supported life.

#   CVE Number  Short Description
75  2016-2775   A query name which is too long can cause a segmentation 
fault in lwresd
73  2016-1286   A problem parsing resource record signatures for DNAME 
resource records can lead to an assertion failure in resolver.c or db.c
72  2016-1285   An error parsing input received by the rndc control 
channel can cause an assertion failure in sexpr.c or alist.c
69  2015-8704   Specific APL data could trigger an INSIST in apl_42.c
67  2015-8000   Responses with a malformed class attribute can trigger 
an assertion failure in db.c
65  2015-5722   Parsing malformed keys may cause BIND to exit due to a 
failed assertion in buffer.c
64  2015-5477   An error in handling TKEY queries can cause named to 
exit with a REQUIRE assertion failure
63  2015-4620   Specially Constructed Zone Data Can Cause a Resolver to 
Crash when Validating
62  2015-1349   A Problem with Trust Anchor Management Can Cause named 
to Crash
60  2014-8500   A Defect in Delegation Handling Can Be Exploited to 
Crash BIND
57  2014-0591   A Crafted Query Against an NSEC3-signed Zone Can Crash 
BIND
56  2013-6230   A Winsock API Bug can cause a side-effect affecting 
BIND ACLs
55  2013-4854   A specially crafted query can cause BIND to terminate 
abnormally
53  2013-2266   A Maliciously Crafted Regular Expression Can Cause 
Memory Exhaustion in named
52  2012-5689   BIND 9 with DNS64 enabled can unexpectedly terminate 
when resolving domains in RPZ
51  2012-5688   BIND 9 servers using DNS64 can be crashed by a crafted 
query
50  2012-5166   Specially crafted DNS data can cause a lockup in named
49  2012-4244   A specially crafted Resource Record could cause named 
to terminate
48  2012-3868   High TCP query load can trigger a memory leak
47  2012-3817   Heavy DNSSEC validation load can cause a "bad cache" 
assertion failure
46  2012-1667   Handling of zero length rdata can cause named to 
terminate unexpectedly

Obtained from 
https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html

Re: Mangled file system directory panic

[coypu]

On Thu, Aug 11, 2016 at 03:37:08PM +0200, Jarle Greipsland wrote:
> [ Followups to port-i386, please ]
> I wrote[1]:
> > I have a system where I can almost deterministally provoke a
> > kernel panic by doing a 'tar -zxpf comp.tgz'.
> > 
> > The panic messages reported by crash is something like:
> > System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name [] i=0, 
> > namlen=4
> > 
> [ ... ]
> > NetBSD 7.99.34 (DARLING) #1: Sat Jul 30 20:01:15 CEST 2016
> > ja...@singsaker.uninett.no:/usr/obj/sys/arch/i386/compile/DARLING
> > total memory = 127 MB
> > avail memory = 120 MB
> > timecounter: Timecounters tick every 10.000 msec
> > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> > Generic PC
> > mainbus0 (root)
> > cpu0 at mainbus0
> > cpu0: Intel 486-class
> > eisa0 at mainbus0
> > isa0 at mainbus0
> [ ... ]
> 
> I have since managed to pin-point where things started to go
> wrong -- CVS commit-wise.  A -current kernel from CVS with tag
> '2016.04.03.03.00.00' works just fine, while a kernel with tag
> '2016.04.03.07.00.00' panics.  The only significant commit in
> that interval is a change of compiler for the i386 port to GCC
> 5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html).
> 
> Are there known bugs in our compiler for (plain) i486 systems?
> 
>   -jarle
> 
> [1]: http://mail-index.netbsd.org/current-users/2016/07/30/msg029876.html
> --
> You are in a dark room with a compiler, emacs, an internet connection,
> and a thermos of coffee.
> Your move ?   -- David A. Honig

Is that PR/51094?

Re: Building on OS X - how?

[coypu]

There shouldn't be anything special about building from OS X.
You just ran into a setup that happens to not work with it.

It'd be good to file a bug report for it, or at least mention where it
fails.

Re: drmkms panic

[coypu]

On Tue, Aug 02, 2016 at 07:04:14PM +, co...@sdf.org wrote:
> On Tue, Aug 02, 2016 at 08:58:56PM +0200, Stefan Hertenberger wrote:
> > Hello,
> > 
> > i hope this dump's are more useful, latest sources compiled with debug
> > symbols.
> > 
> > https://www.alarum.de/netbsd/netbsd.2.gz
> > https://www.alarum.de/netbsd/netbsd.2.core.gz
> > 
> > the kernel with debug symbols, not sure this is needed
> > https://www.alarum.de/netbsd/netbsd.gdb.gz
> > 
> > regards,
> > 
> > Stefan Hertenberger
> 
> 
> The problem is pretty obvious. netbsd kmem_alloc doesn't like allocating
> zero-sized things, whereas linux kmalloc does.
> 
> Now for patching the code to return a sane value provided a zero size...

Going by your last post anyway... I haven't downloaded this one.

Re: drmkms panic

[coypu]

On Tue, Aug 02, 2016 at 08:58:56PM +0200, Stefan Hertenberger wrote:
> Hello,
> 
> i hope this dump's are more useful, latest sources compiled with debug
> symbols.
> 
> https://www.alarum.de/netbsd/netbsd.2.gz
> https://www.alarum.de/netbsd/netbsd.2.core.gz
> 
> the kernel with debug symbols, not sure this is needed
> https://www.alarum.de/netbsd/netbsd.gdb.gz
> 
> regards,
> 
> Stefan Hertenberger


The problem is pretty obvious. netbsd kmem_alloc doesn't like allocating
zero-sized things, whereas linux kmalloc does.

Now for patching the code to return a sane value provided a zero size...

Re: "l->l_md.md_gc_ptp == NULL" failed: file "../../../../arch/x86/x86/vm_machdep.c", line 262

[coypu]

On Sat, Jul 23, 2016 at 05:13:54PM +0900, Ryo ONODERA wrote:
> Hi,
> 
> I am working on Chromium web browser for NetBSD in pkgsrc-wip/chromium-new
> package.
> https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=tree;f=chromium-new
> 
> The biggest problem of the current package is kernel panic while exiting
> chromium web browser.
> It is mostly reproducible and I feel it is as same as
> http://gnats.netbsd.org/49691
> and
> https://mail-index.netbsd.org/netbsd-users/2015/10/18/msg017106.html .
> Both have no reply from anyone.
> 
> My environment is NetBSD/amd64 7.99.34 of 2016-07-21.
> 
> How to debug this problem?
> 
> Thank you.
> 
> P.S.
> If you would like to test this problem with chromium-new,
> please build it on NetBSD current. It uses sysctl argument which
> is implemented in NetBSD current only now.
> 
> --
> Ryo ONODERA // ryo...@yk.rim.or.jp
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

I think this is also PR/42663.