Re: webserver with PHP support

[Mike Pumford]

On 24/04/2024 15:11, Justin Parrott wrote:

I mean that this works:
     /usr/libexec/httpd -b -U nobody -C .php
/usr/pkg/libexec/cgi-bin/php /var/www/

and this does not:
     /usr/libexec/httpd -b -U nobody -C .php /usr/pkg/bin/php /var/www/

-- 
best regards, Alexey

https://alexeyka.zantsev.com/ 


You can do PHP with cgi but its far more efficient to use the php-fpm 
package which runs PHP using the fastCGI protocol which is supported by 
most web servers. I use apache, but any HTTP server supporting the 
protocol should work.


Mike

NetBSD 9.x-STABLE amd64 build sets problem?

[Mike Pumford]

Getting this trying to build a fresh 9.x stable build with the bind update:

13:15:35 ===  1 extra files in DESTDIR  =
13:15:35 Files in DESTDIR but missing from flist.
13:15:35 File is obsolete or flist is out of date ?
13:15:35 --
13:15:35 ./usr/libdata/debug/usr/lib/named
13:15:35 =  end of 1 extra files  ===
13:15:35 --- checkflist ---
13:15:35 *** [checkflist] Error code 1
13:15:35

Something slightly off in a set definition?

Mike

Re: RC4 still gives me trouble with i915

[Mike Pumford]

On 08/02/2024 16:08, Jörn Clausen wrote:

Hello!

For the last RCs, I've tested the live image for amd64 on my desktop 
machine, that has been running 9.x with X for years now. Whenever I 
start X11, either via "startx" or "/etc/rc.d/xdm onestart", the display 
gets unusable. I see fragments of ctwm and an Xterm in the first case, 
and parts of the login display in the second, but the sessions are 
otherwise broken.


Is this expected behaviour with the live image, or should the correct 
configuration get picked up? I see no warning in the Xorg.log, 
everything seems to get detected fine. Please let me know if someone 
needs debug information beyond the following:


The CPU is

cpu0: "Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz"
cpu0: Intel Atom E3000, Z3[67]00 (686-class), 2000.22 MHz
cpu0: family 0x6 model 0x37 stepping 0x8 (id 0x30678)

These are some parts from the messages log:

[     5.009976] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[     5.009976] [drm] Driver supports precise vblank timestamp query.
[     5.009976] i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0)
[     5.079724] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on 
minor 0

[     5.099724] intelfb0 at i915drmkms0
[     5.099724] [drm] DRM_I915_DEBUG enabled
[     5.099724] [drm] DRM_I915_DEBUG_GEM enabled
[     5.099724] intelfb0: framebuffer at 0xc002, size 1280x1024, 
depth 32, stride 5120


I had a similar problem but the fix that resolved it for me went in just 
before RC3 so RC4 should have it.


However I do know it didn't fix the issue for everyone as it depends 
just exactly what Intel display chip you have. If you can grap the 
/var/log/Xorg.log output that often identifies the chip. Mine for 
example says:


[361580.187] (II) intel(0): SNA initialized with Haswell (gen7.5, gt2) 
backend


This is with the intel driver. The modesetting driver which is the 
alternative is less helpful in this respect.


Mike

Re: X11: db of working/not working

[Mike Pumford]

On 07/12/2023 10:15, tlaro...@kergis.com wrote:

[If the intention was not clear: this is just my data, and others
could perhaps add their data too, for users---searching what
works---and developers. "i915" or "radeon" doesn't mean a lot: there is
a huge variety of variants masquerading behing these generic names.]


NetBSD 10.0-RC1 with patch applied to fix kern/57268. Base system X.

Integrated GPU:
[ 1.002270] i915drmkms0 at pci0 dev 2 function 0: Intel Haswell 
Integrated Graphics Device (rev. 0x06)

[ 6.127714] i915drmkms0: interrupting at msi8 vec 0 (i915drmkms0)
[ 6.135164] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on 
minor 0

[ 6.306164] intelfb0 at i915drmkms0

Dual monitor (identical monitors) connected by a dual HDMI KVM:
1xHDMI - EDID 1920x1080
1xDVI - EDID 1920x1080

Until X starts the console is mirrored on both displays as is the 
bootloader output.


Xorg.conf overrides keyboard layout and selects the modesetting driver 
over the intel one. Used to work with the intel driver so I suspect it 
does now I've patched the kernel issue that was common to both. I apply 
one xrandr setup on boot so that the monitor layout is correct as I 
don't run a desktop environment that controls that.


See some display artifact that look like failure to flush caches before 
assigning the memory to the screen. These appear mostly when rendering 
or scrolling text areas and the mouse pointer and dissapear when the 
system is under heavy load (bulk pkgsrc builds or parallel OS builds). 
Most clear within 1-2 seconds on an idle system but sometimes it takes a 
little longer for the cursor to catch up.


Worst offenders for text artifacts are Firefox and Thunderbird. Emacs 
and xterm never have them. The mouse pointer issue impacts everything.


All of this behaviour matches 100% what I had with the earlier DRM code 
from 9.3 as well although there I was using the intel driver rather than 
modesetting.


I do occasionally get a disappearing monitor when switching between KVM 
imputs but that's a KVM issue and impacts all the machines attached to 
it of various types.


Mike

Re: NetBSD-10.0RC

[Mike Pumford]

On 07/12/2023 16:58, tlaro...@kergis.com wrote:

On Thu, Dec 07, 2023 at 11:26:34AM -0500, Todd Gruhn wrote:

HMM , I solved prob? ...


tlarnde mentioned  change  --   chmod 640 card0  .
So I did this. It looks like many errors in /var/log/messages went away.


It is the reverse. For me, the problem was that the /dev/dri/card0 had 640 as
permissions. Should be 660...

I have 660 permissions as well and I've never knowingly changed it as I 
knew my problems were down to code changes rather than being a config 
problem as my DRI went from working on 9.x to broken on 10.0. Thankfully 
I've found a kernel patch that fixes my issued (and yes I have attached 
it to the bug report I raised for my failure :) )


Looking at /dev/MAKEDEV 660 is the correct permissions as thats what it 
would get created with.


Mike

Re: NetBSD-10.0RC

[Mike Pumford]

On 05/12/2023 19:50, g...@duzan.org wrote:

" What does print this ?"

Funny -- I had a screen widget floating across the screen.
The error " Recommended Mode 1920x1081 "  was inside of this.


Perhaps that is your monitor saying that it doesn't like the resolution
of the signal it is getting?

It probably is. I get that during boot until the kernel sets the mode 
from the monitor EDID data. There is a menu option in the monitor 
settings to turn it off but it appears so rarely I've never bothered.


Mike

pthread_sigmask unexpected error return

[Mike Pumford]

I'm getting some odd aborts of node when starting processes with spawn.

Debugging the resultant core the abort is coming from the following 
section of code in libuv (1.47) Line 817:


  /* Start the child with most signals blocked, to avoid any issues 
before we

   * can reset them, but allow program failures to exit (and not hang). */
  sigfillset();
  sigdelset(, SIGKILL);
  sigdelset(, SIGSTOP);
  sigdelset(, SIGTRAP);
  sigdelset(, SIGSEGV);
  sigdelset(, SIGBUS);
  sigdelset(, SIGILL);
  sigdelset(, SIGSYS);
  sigdelset(, SIGABRT);
  if (pthread_sigmask(SIG_BLOCK, , ) != 0)
abort();

The core shows that the abort in the last line of this snippet is firing.

Looking at both the man page for pthread_sigmask and also the kernel 
code in 10-STABLE this doesn't seem like unreasonable code as the only 
documented error is EINVAL which can't apply here. POSIX explicitly says 
EINTR isn't allowed (and I can't see how that would happen in the kernel 
code) or any other error values coming out of the kernel but I could be 
missing something.


One further oddity is that this doesn't happen at all if the process 
being spawned is a non-setuid executable but I can't see why that would 
matter as this code is before the fork anyway. Telling node spawn to use 
a shell to start the process makes this even less deterministic. 
Sometimes it will abort and sometimes it won't.


Any ideas on how to fix this (preferably without having to cook up a 
modified libuv :)


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 25/11/2023 21:39, Brett Lymn wrote:

On Thu, Nov 23, 2023 at 08:44:10PM +, Mike Pumford wrote:





I will clear out my debug statements and post a diff.  They are pretty hacky 
but we can
clean it up if they work for you.  My research at the moment is there is no 
real work around
list for GPUs below gen 8 but I find it hard to believe that all the issues 
listed are
unique to gen 8 and above as that would indicate a totally new product instead 
of an
iteration on a previous one.

The workrounds for below gen8 and below are a bit scattered around the 
code in the 5.6 codebase. In newer codebases they have moved into the 
file where the later chips have.


From the reading of the code and commit comments I came away with the 
impression that they couldn't be moved in the 5.6 codebase due to 
needing different trigger points for the workround and also the 
workround engine couldn't handle writes to some of the registers without 
some structural changes.


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 24/11/2023 16:28, Patrick Welche wrote:

I notice that my artifacts (8th gen) disappear really quickly /
hardly exist if the system is under load. Otherwise, they also self
clear after about a second. Someone (tnn? rvp?) mentioned the
possibility of cache lines not being flushed in this context.

That matches my experience exactly. They completely disappear if the 
system is under any sort of load. I'd always assumed it was a cache 
thing and got exactly the same behaviour on 9-STABLE as well.


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 23/11/2023 17:52, Rhialto wrote:


I will check
https://github.com/freebsd/drm-kmod/blob/master/drivers/gpu/drm/i915/i915_pci.c
whco does show some differences in the GEN4_FEATURES macro. The first
thing I checked was however some completely new field, so that would
probably be irrelevant. Still, there may be hope...

Try the 5.6 release branch. The changes there are much closer to whats 
in our tree so you don't spend so much time dealing with structural 
differences.


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 23/11/2023 06:15, Brett Lymn wrote:

On Wed, Nov 22, 2023 at 08:34:22PM +, Mike Pumford wrote:



Yes! This makes X work for me too.  I had gone down the rabbit hole of
trying to get the drmkms to apply the workarounds for gen 8 to my gen 7
GPU in the hope that it would work - it did once but never again.  I
still have those work arounds applied, there are only a couple that are
reported to not stick but I haven't noticed any issues yet.  Suspend and
resume works.


Great
.
Not likely to suspend and resume on my system (its a desktop development 
and build box) but its good to know that it works.

Oddly, the backlight comes up at minimum brightness on resume but
intel_backlight from pkgsrc sorts that.

I can clean up the debug rubbish and send a diff if you are interested
to try to see if that fixes the artifacts you are seeing.

Absolutely. If I could get rid of the artifacts it would be perfect. 
They self clear after about a second but they are occasionally 
irritating and anything we can do to improve things is a good idea.


I'm going to keep tracking my way through the drm-kmod 5.6 branch for 
fixes as well. I'll also be on the lookout for gen4 related fixes as 
well.  The patch I found referenced a bug report in the freedesktop 
bugtracker. So if that's in any way searchable I'll see if I can work 
that the other way as well.


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 23/11/2023 08:51, Martin Husemann wrote:

On Thu, Nov 23, 2023 at 09:47:21AM +0100, tlaro...@kergis.com wrote:

Smart move and great initiative! Please do send patches to
tech-k...@netbsd.org in order for the developers working with drmkms
to see them and, hopefully, apply them to the cvs sources.


Adding them to the PR is good enough.

That I've already done :). If this discussion yields any more I'll get 
them onto tech-kern though.


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 18/11/2023 11:34, tlaro...@kergis.com wrote:

On Sat, Nov 18, 2023 at 11:14:12AM +, Mike Pumford wrote:
Yes, there has been a major refactoring in the Linux code regarding
headers for example. The whole Linux drm-kms is a (fast) moving
target...
I found a better source for patch inspiration :). The FreeBSD drm_kmod 
repositories. I've had some success by looking at the 5.6 branch there 
which is a nice close match to what NetBSD 10 has.


Found this change:

https://github.com/freebsd/drm-kmod/commit/1e9cdf6cddb369f7f5ad14203c4bb487520369f7

And translated it into the patch attached to this message. A kernel with 
this patch boots and runs X successfully Still see a little bit of cache 
tearing but its better than it was on 9.x (and there are some other 
patches I've found that might address those).


So this fixes kern/57268 (which I raised). I'll send the patch to that 
later but I thought I'd share as I know a couple of you are also 
suffering with similar issues that this might fix




Snippet from Xorg.0.log
[30.585]ABI class: X.Org ANSI C Emulation, version 0.4
[30.623] (II) modeset(0): glamor X acceleration enabled on Mesa DRI 
Intel(R) Haswell Desktop

[30.623] (II) modeset(0): glamor initialized

Tested both firefox and thunderbird including video playback in firefox 
with no issues.


Mike? sys/external/bsd/drm2/dist/drm/i915/gt/intel_workarounds-mp.c
? sys/external/bsd/drm2/dist/drm/i915/gt/intel_workarounds_linux.c
Index: sys/external/bsd/drm2/dist/drm/i915/i915_pci.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/i915/i915_pci.c,v
retrieving revision 1.4
diff -u -r1.4 i915_pci.c
--- sys/external/bsd/drm2/dist/drm/i915/i915_pci.c  19 Dec 2021 01:44:49 
-  1.4
+++ sys/external/bsd/drm2/dist/drm/i915/i915_pci.c  22 Nov 2023 20:32:34 
-
@@ -442,7 +442,7 @@
.has_rc6 = 1, \
.has_rc6p = 1, \
.has_rps = true, \
-   .ppgtt_type = INTEL_PPGTT_FULL, \
+   .ppgtt_type = INTEL_PPGTT_ALIASING, \
.ppgtt_size = 31, \
IVB_PIPE_OFFSETS, \
IVB_CURSOR_OFFSETS, \
@@ -499,7 +499,7 @@
.has_rps = true,
.display.has_gmch = 1,
.display.has_hotplug = 1,
-   .ppgtt_type = INTEL_PPGTT_FULL,
+   .ppgtt_type = INTEL_PPGTT_ALIASING,
.ppgtt_size = 31,
.has_snoop = true,
.has_coherent_ggtt = false,

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 18/11/2023 11:34, tlaro...@kergis.com wrote:

On Sat, Nov 18, 2023 at 11:14:12AM +, Mike Pumford wrote:



On 17/11/2023 21:57, Brett Lymn wrote:


Very interested in the results of this.  I haven't had decent X since I 
updated. Vesa works
but the resolution is pathetic and suspend/resume does not work.


Well my first attempt failed but reading the code a bit more I've just found
a whole pile of extra workrounds I missed so I'm working on adding those. It
doesn't help that in the newer DRM code that the macros that test for
specific versions are completely different :(


Yes, there has been a major refactoring in the Linux code regarding
headers for example. The whole Linux drm-kms is a (fast) moving
target...

Looks like workrounds is quite significantly different.

Between 5.6 rc3 (which is where NetBSD-10 is) and the current code a lot 
of the workrounds have moved into gt/intel_workround.c from other places 
(which makes sense).


Prior to that all the workrounds for any hardware version older than v8 
were scattered throughout the source code. So NetBSD 10 DOES have 
workrounds for older hardware but they are just not in the same place as 
the ones for newer hardware.


This is the commit that moved them.
https://github.com/torvalds/linux/commit/380f0423180768f4a2f368c3ee3d417e255de176

And sure enough if I go to intel_ring_submission.c the workrounds for 
older hardware ARE there. So the missing workrounds was a red herring so 
whatever is causing this breakage is somewhere else. :(


Still at least something has been eliminated.

Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 17/11/2023 21:57, Brett Lymn wrote:


Very interested in the results of this.  I haven't had decent X since I 
updated. Vesa works
but the resolution is pathetic and suspend/resume does not work.

Well my first attempt failed but reading the code a bit more I've just 
found a whole pile of extra workrounds I missed so I'm working on adding 
those. It doesn't help that in the newer DRM code that the macros that 
test for specific versions are completely different :(


Mike

Re: X on 10.0 RC1 is unusable on my laptop

[Mike Pumford]

On 14/11/2023 21:22, Brett Lymn wrote:

On Tue, Nov 14, 2023 at 08:13:22AM +0100, tlaro...@kergis.com wrote:



Just a note that i915drmkms won't apply workarounds to any generation
below gen 8, it will probe and attach early versions but it is a bit hit
and miss whether it will work or not due to hitting hardware errors.

The drm driver appears to be missing some gen 7 devices - like the one
in my laptop so you may get a probe failure with that.

Ooh. Haven't come across that before. I also get exactly the same ring 
heartbeat issue on my system and looking at the latest linux DRM code 
the gen7/gen6 workround code is pretty tiny and trivial to backport.


I've just popped it into my local tree and I'm giving it a try :)

Here's hoping.

Mike

Re: zfs pool behavior - is it ever freed?

[Mike Pumford]

On 27/07/2023 13:47, Michael van Elst wrote:


Swapping out userland pages is done much earlier, so with high ZFS
utilization you end with a system that has a huge part of real memory
allocated to the kernel. When you run out of swap (and processes
already get killed), then you see some effects on kernel data.

Now I might be reading it wrong but that suggest to me that it would be 
an awful idea to run ZFS on a system that needs memory for things other 
than filesystem caching as there is no way for those memory needs to 
force ZFS to give up its pool usage.


If I've read it right there needs to be a mechanism for memory pressure 
to force ZFS to release memory. Doing it after all the processes have 
been swapped to disk is way too late as the chances are the system will 
become non-responsive by then. From memory this was a problem FreeBSD 
had to solve as well.


Even with the conventional BSD FFS I have to set vm.filemin and 
vm.filemax to quite low values to stop the kernel prioritizing file 
system cache over process memory and thats on a system with 16GB of RAM. 
Without that tuning I'd regularly have processes effectively rendered 
unresponsive as they were completely swapped out in favor of FS cache.


What's the equivalent lever for ZFS?

Mike

Re: Talk to mouse || ID a mouse

[Mike Pumford]

On 15/07/2023 09:30, Todd Gruhn wrote:

UH KAY.


Found this:

 port 7 addr 9: full speed, power 98 mA, config 1, USB
Receiver(0xc52b), Logitech(0x046d), rev 12.11(0x1211)
 port 8 powered
 port 9 powered
 port 10 powered
 port 11 addr 10: full speed, power 98 mA, config 1, USB
Receiver(0xc52b), Logitech(0x046d), rev 12.03(0x1203)
 port 12 powered

Unless its very unusual you should have ended up with something like 
this in your dmesg:


[ 1631769.331114] uhidev1: Logitech (0x046d) USB Receiver (0xc534), rev 
2.00/29.01, addr 17, iclass 3/1

[ 1631769.334114] uhidev1: 17 report ids
[ 1631769.334114] ums0 at uhidev1 reportid 2: 16 buttons, W and Z dirs
[ 1631769.334114] wsmouse0 at ums0 mux 0

You can also do:
usbdevs -vd
Which will give you the output above and should also list the device 
drivers attached by the OS (usbhid hopefully).


From memory you can reference a specific mouse as /dev/wsmouse0 or 
/dev/wsmouse1 but there is also a /dev/wsmouse that merges all the mouse 
inputs together. /dev/wsmouse is normally what the X server references 
which allows you to use any mouse on the system.


I'd be astonished if this didn't just work assuming you have USB HID 
support compiled into your kernel (its in GENERIC and has been for 
years). Most USB mice are of this type (wired and wireless) as it means 
they work out of the box on pretty much every operating system under the 
sun.


Other things to check:

1. Is the mouse turned on? (they usually have a sneaky power switch on 
the underside).

2. Is the battery inside the mouse okay?

From a quick check with mine I still get the ums device even with the 
mouse turned off but obviously it doesn't make the pointer move.


Mike

Re: npf NAT stops working on external interface IP changed

[Mike Pumford]

On 16/01/2023 19:01, Jeremy C. Reed wrote:

Then it was offered a new IP, added route, changed default route.

I did a "sudo npfctl reload" to get NAT to work again.

How can I get it to automatically reload on external interface changes?
The man page for ifwatchd suggests it can do what you want given the 
right options as it can run scripts when addresses are added/removed 
from an interface.


Mike

Re: APC UPS hid driver

[Mike Pumford]

On 10/07/2022 19:31, Greg Troxel wrote:


Dima Veselov  writes:


Greetings,

I am using NetBSD 9_STABLE and I would like to connect UPS via USB serial
port. UPS is detected as ugen device

  port 2 addr 3: low speed, self powered, config 1, Smart-UPS 750 FW:651.13.I 
USB FW:7.3(0x0002), American Power Conversion(0x051d), rev 0.06(0x0006), serial 
AS0714242055


Are you using the ups-nut package?  If so it will be user "nut".  CHeck
that this user can read/write the ugen device.  I use serial and have
the port symlinked to a stable name and chowned.


sysutils/ups-nut-usb can't detect UPS and my question is:

Is it neccesary for UPS to be detected as a hid device and this means that
kernel miss something or it is a problem of usbhid-ups/libusb ?


I really don't know as I have never used a hid UPS.  See uhid(4) but I
would more or less expect (without knowing or understanding) that it
could use libusb for this.


Don't know about nut but apcupsd detects non-hid APC UPS's just fine. My 
current one reports as:


ugen0 at uhub0 port 2
ugen0: American Power Conversion (0x51d) Back-UPS XS 1400U  FW:926.T2 .I 
USB FW:T2 (0x02), rev 1.10/1.06, addr 2


Looking at the nut documentation you can then access the UPS via apcupsd 
for those UPS's it can't talk to directly.


If the UPS was a HID device I'd expected a uhid attachment as well but 
from memory there might be some logic in the kernel blocking that as 
libusb needs a ugen attachment to work.


Mike

Re: how to limit /etc/daily to local only, and cleasring bad nfs

[Mike Pumford]

On 18/06/2022 14:33, Steve Blinkhorn wrote:

Some off-list discussion has clarified matters.  The fundamental problem is 
that nfs
mounts are not restored automatically when an nfs server is rebooted - and that
may happen automatically so the sysadmin is unaware.

Ah that's probably why I don't run into it. I have one server that's 
rarely down. So even if the client hit the mount points after it had 
been down the connection is likely to re-establish quickly in my setup.


Good to know. Thanks.

Mike

Re: how to limit /etc/daily to local only, and cleasring bad nfs mounts

[Mike Pumford]

On 27/05/2022 17:18, Steve Blinkhorn wrote:

1. How to limit /etc/daily,weekly,monthly so they do not cross nfs mount
points?  One of my development systems crashes occasionally when left
running a long job after hours.  It reboots itself, but nfs
connections to it are not restored.  What I don't notice is that
/etc/daily now hangs on a public-facing machine.  Gradually the humber
of processes increases day by day until I have numerous find, tee,
sendmail and sh proceses all stuck.


What paths have you got NFS mounted on the client?

I've got 2 BSD system both 9.2-STABLE one of which provides an NFS /home 
and a few other odd paths as well to the other. The /etc/daily process 
on the client isn't scanning the server filesystems in my setup and I'm 
not aware of any specific setting I had to turn on to get that behaviour.


Mike

Re: mpv and estd and --vo=xv

[Mike Pumford]

On 13/07/2021 22:41, RVP wrote:


     When the processor is operating below these limits and the user's
     workload demands additional performance, the processor frequency will
     dynamically increase until the upper limit of frequency is reached.

But boost only scales up from the top clock speed to above the top speed 
it cant scale down or at least it can't on older generations of 
processor. To scale down for increased power saving on these older 
system you need a software clock control.


Later Intel CPUs gained the ability to do automatic clock scaling across 
the entire frequency range but I've never looked into how it has to be 
controlled. The only CPUs I've got that do it run Windows.


They keyword is Speed Shift as opposed to turbo boost. Only that can 
auto clock down/power down the core. Not sure if AMD have an equivalent 
but I'd be surprised if they dont.


I wasn't aware NetBSD had support for that.

Mike

Re: mpv and estd and --vo=xv

[Mike Pumford]

On 11/07/2021 20:59, RVP wrote:

On Sun, 11 Jul 2021, Rhialto wrote:


I also use estd to dymamically throttle down the cpu freqency when the
system is not so busy. So most of the time it is set to 800 MHz, the
lowest possible value.



 From what nia@ tells me (and this is also in the guide: section 11.1.4.),
you shouldn't need estd at all:

     Many modern hardware supports an "automatic adjustment" frequency,
     usually this will be a reported frequency that ends in 1. On systems
     without this functionality, sysutils/estd can be installed from
     pkgsrc to perform automatic adjustment depending on load in software,
     although it will be less efficient than hardware scaling.

Ah thats good info that I DIDN'T know. Sadly all my BSD hardware is from 
the generations before the full 'auto adjust' was added. I think that's 
intel core gen 6 and mine is gen5. So in my case I really do need estd :(


On older hardware the xxx1 frequency in my hardware enables the turbo 
boost clocks which overclocks cores beyond the max. 4GHz to 4.4GHz in my 
case I think. I didn't realise that had been repurposed in newer cores 
to be (let the CPU adjust across all speeds) I sort of assumed that 
would be reported differently.


I do know that estd makes a significant different to temperature and 
power consumption when my system is idle vs when its busy.



Mike

Re: mpv and estd and --vo=xv

[Mike Pumford]

On 11/07/2021 14:13, Rhialto wrote:

I keep having weird things with graphics performance. I got myself a new
box ("Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz") with 6 cores. I got a
"new" old Radeon HD-5450 because at least that chipset is supported for
dri/drm.

I also use estd to dymamically throttle down the cpu freqency when the
system is not so busy. So most of the time it is set to 800 MHz, the
lowest possible value.

I'm not sure estd defaults work if you have a lot of cores. From reading 
the manual page (and based on experiments here) it seems to work based 
on overall cpu time so you have to adjust the parameters so that 1 core 
at 100% CPU is enough to keep it from dropping the clock speed. So for 
my 8 core i7 system I use:


estd_flags="-a -l 12 -h 25"

in rc.conf. So it needs a brief burst of 2 core load to get things to 
ramp up but then it won't ramp down as long as 1 core is maxed out. This 
seems to be match the reality when doing builds. Even when the a build 
goes single core as long as that core stays at 100% the core clock stays 
at maximum. This did seem to help with in browser video playback 
smoothness as well but I'm on the onboard graphics of my CPU rather than 
an external card.


Mike

Re: IPF rules

[Mike Pumford]

On 02/07/2021 13:38, Rhialto wrote:

On Fri 02 Jul 2021 at 07:39:20 -0400, Todd Gruhn wrote:

I started NetBSD, and shutoff IPF. Pinging mail.google.com and
gsuite.google.com both got immediate
results. If I left IPF down, and start FireFox, and goto
mail.google.com, I get the "Critical Security Alert" popup,
and the mouse gets frozen. I need to press the button, and reboot.

How much of this prob is IPF and how much is Google?


IPF doesn't do popups of any sort, so that is easy.

Yes. I've stopped using IPF in favour of NPF since I switch to 9.x but 
that was because I could see that eventually support for it was going to 
stagnate. Inever had any real problems with performance before I did 
switch.


I run my firewall on NetBSD so traffic from all the devices in my house 
flows through NPF (and used to go through IPF) with no obvious 
performance impact. Happy to help out troubleshooting either your 
existing IPF ruleset or working out how to do what you need with NPF.



Have you tried installing an ad blocker? uBlock Origin is good; I
use it with some extra filter lists enabled. A javascript blocker, such
as NoScript, is also good for safety, but a bit more annoying in
practical usage, because there are so many web pages that use javascript
where they totally shouldn't.



The firefox addon module has got a bit grumpy about displaying add-ons 
on netbsd but you can get past that and they work fine. :)


Without adblocking the web is a pretty nasty place for that sort of 
horrible popup. I always spot how rubbish the web is when I'm forced out 
of Firefox into Chrome on my mobile where you can't install add blocking 
add ons. I never cared about the adverts on sites until they started 
attacking my PC. I see an adblocking add on not as an anti-commercial 
statement but a security statement.


I did just do a test access of my gmail account via firefox on 9.2 
stable (but with a few months out of date firefox-84 package. Apart from 
the small delay while I dealt with the 2 factor auth popup on my phone 
the access was pretty quick.


Mike

Re: Network very very slow... was iSCSI and jumbo frames

[Mike Pumford]

On 04/02/2021 23:54, RVP wrote:


2. Try disabling `estd'. Since iSCSI is somewhat CPU-bound also,
    `estd' keeping the CPU freq. low will make a difference with
    read/write throughput.


> My CPU was always at 800MHz even when all these tests were going
> on. Throughput increased by a few MB with the CPU speed set to max.

Another possibility is to tune the estd parameters a bit. As far as I 
can tell estd looks at TOTAL CPU consumption to decide when to ramp up.
This is based on experimentation on my 8 core system and with 1 CPU core 
maxed out it doesn't seem to be that keen to ramp up the clock rate with 
the default parameters.


I run with:

-l 12 -h 25

added to the estd_flags in rc.conf. This seems to allow estd to keep the 
CPU ramped even for a single core load. I think estd might need some 
reworking for the now hugely multi-core processors in modern systems as 
average CPU is no longer a useful way to make an optimum performance 
decision on a multi-core system.


This estd observation is based on observation of behaviour rather than 
an actual examination of the code.


Mike

Re: Custom pet projects compiling for NetBSD n00bs

[Mike Pumford]

On 08/01/2021 13:03, Lord Vader wrote:
I'm trying to compile my pet C project under NetBSD (using 9.1 in i386 
flavour).


Specifically, I need libpng and libconfig. Both are installed using 
pkg_add, both seem to have .so and includes under /usr/pkg path.


Then, when I try to compile my code simply as gcc -c filename.c 
filename.o, it fails at #include .
Further examination of gcc with `gcc -xc -E -v -` shows it doesn't have 
default include path that point into /usr/pkg/include
I managed to add them via -I or via CPATH env var, then I've managed to 
do the same for linking via -L or LIBRARY_PATH, then I even got the 
executable. Which again was unable to find .so under the /ust/pkg/lib , 
unless I also use LD_LIBRARY_PATH for running it.
I have experience with different linux distros, including ubuntu and 
gentoo where everything seems to work off-the-box (provided I `apt 
install` or `emerge` appropriate packages), but here I fail and probably 
I do smth terribly wrong.

Any suggestions?

That's because linux dumps everything in /usr/lib whereas only system 
libraries live there on NetBSD.


The linker option you need is -rpath=/usr/pkg/lib.

So you can do:

cc -o myprojects myfile.o -L/usr/pkg/lib -Wl,-rpath=/usr/pkg/lib -lpng 
-lconfig


You can specify a path in /etc/ld.so.conf but using rpath is how pkgsrc 
packages normally do this.


Mike

Re: postfix for 2 domains on 1 vps 1 ip

[Mike Pumford]

On 05/01/2021 11:02, Pierre-Philipp Braun wrote:

I get 2 public ips from the cloud provider - one is ipv4 and one ipv6.
Besides, to solve the forward-confirmed-reverse-dns issue, I would also 
KISS over there and use a single and IPREV FQDN for both v4 and v6 IPs, 
be it delivered as a host from one of the two domains you are targeting, 
or simply another domain of yours that they would share an MX record 
from.  As a side-note, it's possible to have a CNAME as an MX record, 
but it's just simpler and safer to point to the MX who's hosting those 
domain's email, directly.


I thought CNAME in an MX record was considered naughty. Bind zone 
validation used to warn about it but did accept it. I know it was 
frowned on the last time I read the various e-mail RFCs but that could 
easily have changed since then ;)


Mike

Re: radeon card on 9.1

[Mike Pumford]

On 11/12/2020 10:57, RVP wrote:


9.1 and -current have good ones:

https://man.netbsd.org/NetBSD-9.1/amd64/boot.cfg.5
https://man.netbsd.org/amd64/boot.cfg.5

Yes that's significantly better than what used to be there. :) I may 
have flagged it up at the time but its so long ago now I can't remember.


Mike

Re: radeon card on 9.1

[Mike Pumford]

On 11/12/2020 08:04, nia wrote:
serconf disable i915drmkms" at the boot prompt should force the

kernel to stop seeing the integrated graphics and use the radeon
card for everything.


If that works you can put it into boot.cfg like so:

menu=Boot normally:rndseed /var/db/entropy-file;userconf disable 
i915drmkms;boot netbsd


Reason I'm posting that unsolicited is that it took me ages to actually 
work out how to embed the correct command in boot.cfg as the manual page 
was stunningly lacking in examples.


Mike

Re: mod_ssl warning with apache-2.4.46nb1

[Mike Pumford]

On 10/12/2020 17:36, Greg Troxel wrote:


Mike Pumford  writes:


On 10/12/2020 17:15, Greg Troxel wrote:


In this case, it seems you are using old NetBSD and pkgsrc is built
against a newer version than 9.0 because there are some bugs ixed that
matter tor other things (rust, not apache AFAIK).


Rust is a PITA. As someone that does my own local builds for pkgin I
have a lot of sympathy for that decision.


While I am sympathetic to the point of view that rust is troublesome, in
this case there was an actual bug in NetBSD that was found because of
rust and the bug was fixed.  So this particular issue is not rust's
fault at all.

Yes I kept running into it all the time until it was fixed. And given 
how much difference it makes to the build time for rust its perfectly 
rational to use 9.1 for package builds.



A very good point that it is only probabalistically safe in theory.  We
do try not to do things that cause mix/match along branches to be
trouble, but you are right that new openssl having a symbol that old
doesn't is not an ABI break.

No. And that's the only way I can see a binary built with a newer ssl 
failing on an older system. After all the library major version didn't 
change so any dynamically linked program built on 9.0 could end up using 
the 9.1 dynamic library anyway. If that breaks anything then it would be 
a bug that would need to be fixed.


Mike

Re: mod_ssl warning with apache-2.4.46nb1

[Mike Pumford]

On 10/12/2020 17:15, Greg Troxel wrote:


In this case, it seems you are using old NetBSD and pkgsrc is built
against a newer version than 9.0 because there are some bugs ixed that
matter tor other things (rust, not apache AFAIK).

Rust is a PITA. As someone that does my own local builds for pkgin I 
have a lot of sympathy for that decision.



Also, openssl 1.1.1g really ought to be binary compatible with 1.1.1d.
If not that's an openssl bug, and it's a bug in NetBSD that we applied
it on the branch.  But, my best guest is that it's toally fine.

I'd expect it to be safe as well. The biggest risk would be if the newer 
modssl used a symbol that didn't exist in the old library but that would 
blow up completely at module load time.



Entirely separately from compat, you should be running recent openssl
anyway, as a matter of security best practices.

This is very true in this case. I'm fairly certain at least one of the 
openssl bugfixes in 9.1 relates to TLS handshake issues that could 
impact an server offering https.


Mike

9.1-amd64 console spam when running i386 binaries

[Mike Pumford]

I run chroot package builds for i386 in my amd64 system (using i386 
userland/libc).


After a build run I end up with lots of:

netbsd32_mmap: retval out of range: 0xfe995000

in my dmesg and on the console. Is there any way to stop that? Is it 
actually causing failures?


Mike

Re: Mapping kbd layout to connected) usb keyboard?

[Mike Pumford]

On 26/10/2020 13:00, Hauke Fath wrote:

Hi,

I helped my self to a fancy keyboard (Keyboardio Atreus). It comes with 
US layout, which I am trying to get used to, unlike my old DE IBM kbd.


Is there a way to automatically set the wscons keyboard layout depending 
on the keyboard attached? What about X11?


Not sure that's something any OS supports. I've not seen auto layout 
detection even in windows or linux as I'm not sure the keyboards can 
communicate that even over USB.


Normally there is an input selection widget in the UI to switch input 
keyboard layouts. Not sure if the X11 versions of those work in NetBSD.


Mike

Re: [Q] 9.1 amd64 openJDK11 error on certificates

[Mike Pumford]

On 25/10/2020 07:56, Michael van Elst wrote:

ts1...@rad2know.net (ts1000) writes:


But that first step is not working on netBSD-9.1 amd64
I tried with pkgin, as well as building openjdk11 from source.
Error is the same.



I also installed, with pkgin,
ca-certificates-20200601
mozilla-rootcerts-1.0.20200529nb1


The mozilla certificates aren't used by Java. You probably have to
import them with keytool or similar.

That's true they are not. Java 8 builds its own cert store when it 
builds. Looking at my Java 11 pkgsrc build from last week it appears to 
import the mozilla root certs into its keystore as part of the build 
process.


However at the end of the build process the openjdk8 package installs 
the certificate in the install phase but the openjdk11 package does not!


No I know that some NetBSD people are against auto cert install but 
given the pain of doing it for java it should probably be at least a 
package option and in the absence of an option it seems to me that 
mimicing openjdk8 and installing the certs is a good idea.


I'd be strongly against not installing the certs on openjdk8 as that 
would mean I'd have to manually fix that up every time I did a package 
update.


Mike

Re: fwohci users, anyone ?

[Mike Pumford]

On 21/10/2020 16:47, Michael van Elst wrote:

mpumf...@mudcovered.org.uk (Mike Pumford) writes:

I'm trying it with a Sparc workstation running -current. It doesn't
look very stable there. It would be interesting to find a hardware
combination where it does work reliably.

Okay. I'll see if I can remember where I've got that disk enclosure 
tucked away and test it this weekend.


Mike

Re: fwohci users, anyone ?

[Mike Pumford]

On 21/10/2020 14:29, Michael van Elst wrote:

Is anyone using firewire hardware ? In particular for mass storage ?

I'm not using it on a regular basis but I do have systems with hardware 
and a mass storage enclosure I could attach to them. Currently the 
firewire equipped systems are 8.2-STABLE amd64 and I think 9.0-STABLE 
i386. I can easily try current on the i386 system but I'd be more 
reluctant to do so on the amd64 one as its my primary file server.


Mike

Re: A single-board computer for NetBSD

[Mike Pumford]

On 26/08/2020 20:48, Staffan Thomén wrote:

Mike Pumford wrote:


Here's a third recommendation for the APU2 systems. They are very nice 
(although I am annoyed by the bios resetting my (real) serial terminal 
every time it hands over to the operating system, making the terminal go 
through it's boot-up reset cycle, but that's coreboot).


coreboot isn't perfect but at least its being actively maintained and 
developed for the APU. I had a soekris box in the past and once they 
went out the door bios updates were few and far between.


Mike

Re: A single-board computer for NetBSD

[Mike Pumford]

On 26/08/2020 13:12, Greg Troxel wrote:





My recommendation to the broader question of "router box to run NetBSD"
is the PC Engines apu2.  This is a fanless system with a 4-core
amd64-compatible processor:

I'll second this recomendation. I'm also using one as my gateway 
firewall. Currently running NetBSD 8.2-STABLE as an npf firewall.


I've successfully rewritten the BIOS on mine using flashrom on linux and 
the brief test I did of the NetBSD version of flashrom suggests it ought 
to work. It does correctly identify the BIOS flash chip successfully.



In addition to the technical stuff, PC Engines has been great to deal
with.  The ordering process is slightly unusual: you basically submit a
list of what you want and they email you an invoice with actual shipping
(because international shipping is hard to figure out, but it's totally
reasonable).  You then pay and they ship; delivery to the US was fast
enough I wasn't bothered by it (1-2 weeks?).  (In EU you have to buy
from an in-country distributor due to recyling rules, but in non-EU you
can order from them direct.)

Didn't realise that but I got mine from linitx.com in the UK and then 
just added an off the shelf mSATA SSD from Amazon as the ones sold with 
the devices are tiny ;)


One other thing to note is that the apu2 case is part of the heatsink so 
its not a good idea to put other kit directly on top of it. I found this 
out the hard way as it caused my VDSL modem (which was sitting on top) 
to occasionally disconnect and reconnect when the ambient temperature 
reached 30degC.


Mike

Re: dhcpcd refreshing lease very often.

[Mike Pumford]

On 12/08/2020 18:29, Roy Marples wrote:

Maybe some other process is listening on the bootpc port?
If you stop dhcpcd and do `netstat -laf inet | grep bootpc` is anything 
listed?

That command produced no output when dhcpdc was stopped.

When dhcpcd is running I see the following from that command:

udp0  0  *.bootpc   *.*


If you start dhcpcd again does the port then show?

I'm guessing you are expecting the port number to show up in the ps 
output? Is that code in the 9.0-stable dhcpcd? Apart from the pid 
changing the ps output was identical:


 6777 ?  Ss 0:00.01 dhcpcd: [master] [ip4] [ip6]

Mike

Re: dhcpcd refreshing lease very often.

[Mike Pumford]

On 12/08/2020 17:04, Roy Marples wrote:


Interesting. You can post the output of `ps ax | grep dhcpcd` please?

12897 ?  Is 0:00.75 dhcpcd: [master] [ip4] [ip6]

During all the IPv4 requests the IPv6 logic worked perfectly. I didn't 
see any wm link events in the debug log and I can also check the logs in 
the managed switch the machine is attached to.


Could you test net/dhcpcd from pkgsrc please? I'm curious if that fixes 
the issue.



Yes but that might take me a little while.

Roy

Re: dhcpcd refreshing lease very often.

[Mike Pumford]

On 11/08/2020 21:14, Mike Pumford wrote:

Aug 11 21:09:55 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.3 seconds
Aug 11 21:11:00 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.0 seconds



This cycle was finally stopped by this:
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: failed to renew DHCP, rebinding
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: expire in 5400 seconds
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0x68dace9d), next in 3.0 seconds
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: acknowledged 192.168.1.2 
from 192.168.1.9
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: leased 192.168.1.2 for 43200 
seconds
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: renew in 21600 seconds, 
rebind in 37800 seconds
Aug 12 11:53:56 trigati dhcpcd[12897]: wm0: writing lease 
`/var/db/dhcpcd/wm0.lease'


So it looks like the renew code is not seeing and processing the ack 
from the server in the renew path.


This will happen every renewal cycle so I can capture packet traces and 
share them if that helps.


Just in case its relevent the client interface is configured as follows:
wm0: flags=0x8843 mtu 1500
capabilities=7ff80
capabilities=7ff80
capabilities=7ff80
enabled=7ff80
enabled=7ff80
enabled=7ff80
ec_capabilities=17
ec_enabled=2
address: 10:c3:7b:95:20:ed
media: Ethernet autoselect (1000baseT full-duplex)
status: active

Mike

Re: dhcpcd refreshing lease very often.

[Mike Pumford]

On 10/08/2020 12:49, Roy Marples wrote:

On 10/08/2020 12:00, Mike Pumford wrote:
I've also noticed its intermittent. So its clearly being triggered by 
some network activity.
dhcpcd will renew if the carrier goes down/up or you issue `dhcpcd -n` 
on the command line. Those are the only early triggers.



Finally have some debug output the repeated requests start from a renewal:

Aug 11 20:48:50 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64

Aug 11 20:53:56 trigati dhcpcd[12897]: wm0: renewing lease of 192.168.1.2
Aug 11 20:53:56 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 4.5 seconds
Aug 11 20:54:01 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 9.0 seconds
Aug 11 20:54:10 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 16.8 seconds
Aug 11 20:54:26 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 32.8 seconds
Aug 11 20:54:59 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.0 seconds
Aug 11 20:56:00 trigati dhcpcd[12897]: wm0: Router Advertisement from 
fe80::20d:b9ff:fe4a:7230
Aug 11 20:56:00 trigati dhcpcd[12897]: wm0: adding address 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 20:56:00 trigati dhcpcd[12897]: wm0: pltime 604800 seconds, 
vltime 2592000 seconds
Aug 11 20:56:00 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 20:56:00 trigati dhcpcd[12897]: wm0: executing 
`/libexec/dhcpcd-run-hooks' ROUTERADVERT
Aug 11 20:56:01 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 20:56:01 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 20:56:02 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.8 seconds
Aug 11 20:57:07 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.4 seconds
Aug 11 20:58:11 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.8 seconds
Aug 11 20:59:15 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.7 seconds
Aug 11 21:00:19 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.2 seconds
Aug 11 21:01:09 trigati dhcpcd[12897]: wm0: Router Advertisement from 
fe80::20d:b9ff:fe4a:7230
Aug 11 21:01:09 trigati dhcpcd[12897]: wm0: adding address 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:01:09 trigati dhcpcd[12897]: wm0: pltime 604800 seconds, 
vltime 2592000 seconds
Aug 11 21:01:09 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:01:09 trigati dhcpcd[12897]: wm0: executing 
`/libexec/dhcpcd-run-hooks' ROUTERADVERT
Aug 11 21:01:10 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:01:10 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:01:22 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.0 seconds
Aug 11 21:02:25 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.3 seconds
Aug 11 21:03:29 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.2 seconds
Aug 11 21:04:33 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 63.6 seconds
Aug 11 21:05:37 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.8 seconds
Aug 11 21:06:41 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.8 seconds
Aug 11 21:07:46 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 65.0 seconds
Aug 11 21:08:51 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.2 seconds
Aug 11 21:09:28 trigati dhcpcd[12897]: wm0: Router Advertisement from 
fe80::20d:b9ff:fe4a:7230
Aug 11 21:09:28 trigati dhcpcd[12897]: wm0: adding address 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:09:28 trigati dhcpcd[12897]: wm0: pltime 604800 seconds, 
vltime 2592000 seconds
Aug 11 21:09:28 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:09:28 trigati dhcpcd[12897]: wm0: executing 
`/libexec/dhcpcd-run-hooks' ROUTERADVERT
Aug 11 21:09:29 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:09:29 trigati dhcpcd[12897]: wm0: sending NA for 
2001:8b0:84:1:12c3:7bff:fe95:20ed/64
Aug 11 21:09:55 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.3 seconds
Aug 11 21:11:00 trigati dhcpcd[12897]: wm0: sending REQUEST (xid 
0xc8152c37), next in 64.0 seconds


I've run tcpdump and the dhcp response is making it back to the client 
so its not packet loss.


Mike

Re: dhcpcd refreshing lease very often.

[Mike Pumford]

On 10/08/2020 11:19, Roy Marples wrote:

Hi Mike


Anything I need to look at to help with debugging this?


You could start by adding the debug directive to dhcpcd.conf and 
restarting dhcpcd.
Then examine syslog and see why it's refreshing so quickly - all the 
reasons should be logged.



Done.

I've also noticed its intermittent. So its clearly being triggered by 
some network activity. I did also forget to mention its also handling 
slaac IPv6 address assignment based on router advertisements.


Will report back once I get some debug data to work with.

Mike

dhcpcd refreshing lease very often.

[Mike Pumford]

Running 9.0-STABLE buit July 26th.

Machine is refreshing its least approximately once a minute. Despite the 
DHCP server being configured with a lease time as follows:

max-lease-time 43200;
default-lease-time 43200;

Server is NetBSD 8.2-STABLE isc dhcpd and this is the only host of many 
on the network refreshing that often.


Only non default option on the client is
slaac hwaddr as I don't actually want the machine to have a privacy 
address as it just makes life hard from an RDNS perspective.


Anything I need to look at to help with debugging this?

Mike

Re: NetBSD/Xen samba performance low (compared to NetBSD/amd64)

[Mike Pumford]

On 04/08/2020 05:08, Matthias Petermann wrote:

But there is one detail I have just now become aware of... when I bought 
these NUCs a few years ago, I installed hybrid hard disks (Seagate 
Firecuda SSHD 2TB). This type has a mechanical/magnetic mass storage and 
a (relatively small) SSD on the side. But from the point of view of the 

We had a batch of office laptop with drives like this (although older 
and smaller) and they have some awful performance quirks if you do a lot 
of IO that effectively downgraded the performance to that of a standard 
2.5in drive and sometimes even slower.


Just done some read performance tests on my samba server here. This is 
all on gigabit ethernet and using the transfer speed reported by windows 
explorer:


Read performance from SATA SSD():
70MB/s

Read performance from SATA HD(2x raidframe raid1):
Started at 50MB/s rose to 70MB/s by the end of the transfer.

CPU is:
Intel(R) Core(TM)2 Quad CPUQ6600  @ 2.40GHz

and the SATA controllers have max link speed of 3Gb. Ethernet controller is:
Intel i82541PI 1000BASE-T Ethernet

So this gives you something non-xen to compare to.

Mike

Re: NetBSD/Xen samba performance low (compared to NetBSD/amd64)

[Mike Pumford]

On 03/08/2020 17:48, Sad Clouds wrote:


I believe Samba is single threaded, so can't take advantage of multiple
CPUs for a single stream. I'm not a Xen expert, however I'm not sure
running this in Dom0 is a representative test. I imagine most workloads
would be done within a DomU, while Dom0 is just a control domain and
allocates CPU and memory resources, so you may have additional
overheads + latencies.

Samba uses multiple processes for parallelism. So there is a separate 
smbd process for each connection. So for a single share to a single 
client its single threaded. Multiple clients or multiple shares will 
spawn additional smbd processes.


Mike

Re: Sysinst creates gaps between GPT partitions - why?

[Mike Pumford]

On 03/08/2020 11:22, Greg Troxel wrote:

Martin Husemann  writes:


On Mon, Aug 03, 2020 at 11:08:22AM +0200, Matthias Petermann wrote:

2  32 Pri GPT table
   342014 Unused


That part is expected...


Not to me, entirely.

I get it why 0, 1 and 2-33 are GPT.

I get it why we don't align to 63 (because there is no good reason,
and because it doesn't line up with 4K physical sectors).

The forced choice these days is 8, because of 4K sectors.  I can see why
picking 8 for alignment isn't future-proof against the disk announced
next week with 8K or 32K physical sectors (yes, I'm making that up, but
I would not be shocked to see that over the next 10 years)..

SSD's also add another complexity. The underlying flash media may have a 
sector size way larger than 4kB. Based on the NAND flash devices I've 
used in embedded projects sector sizes of 64kB or larger could be what 
the SSD is actually using. So this larger alignment might be helpful in 
this scenario as well.


Mike

Re: OT: User-friendly /bin/sh

[Mike Pumford]

On 31/07/2020 20:11, Jordan Geoghegan wrote:
>> Can some Good Samaritan please point me to a HOW-TO that would provide
>> the needed basic instructions?
>>
>> Thank you.
>>
>
set -E
Enable emacs style command line editing. There is a Vi style one as well.

set -o tabcomplete
Turn on tab completion for filenames.

With both of these set sh has file completion, history and editing.

All found through judicious searching of the output of man sh. ;)

Only slightly counterintuitive bit is that set -o tabcomplete turns it 
on and set +o tabcomplete turns it off.


Running set -o with no additional arguments displays the options that 
can be set.


Mike

Re: setup for English/Japanese

[Mike Pumford]

On 28/07/2020 12:58, Steve Blinkhorn wrote:
> I would welcome advice on the sequence of steps needed to get vim to
> work on files that are mixed English and Japanese, utf-8.  I run stock
> NetBSD 7.0 on amd64, and habitually (it's a long-standing habit) use
> csh.  There are several vim versions in pkgsrc; there
> is a tutorial document on netbsd.org that seems to recommend using
> urxvt, and makes mentions a few shells but not csh.
>
> I've spent half a day trying to get things to work without success (on
> MS Windows I just call up gvim and it works out of the box, but that's
> very inconvenient in other ways).  Is there a step-by-step guide
> anywhere?
>
I copied the following from Linux setups with working UTF8 to BSD:

Export the following:
LC_ALL=en_US.UTF8
or
LC_ALL=en_GB.UTF8
Since you seem to be UK based.

That seems to be all it takes to get applications to recognise and emit 
unicode.


For xterm you also need:

XTerm*locale: true

In your X resources.

This is all on NetBSD 9.0-STABLE amd64.

Havent tried this with Japanese though. I'm also not sure if the wscons 
console is capable of UTF8. I always use SSH connections via PuTTY or xterm.


Mike

Re: pkgsrc build server

[Mike Pumford]

On 04/07/2020 21:57, Greg A. Woods wrote:

At Sat, 4 Jul 2020 21:01:26 +0300, Dima Veselov  
wrote:
Subject: Re: pkgsrc build server


What I want is to run "make install" on fast real production server
with lot of resources once and then have all of those packages built in
NFS DISTDIR so any VM can just install them.


Yes, you can do that, provided the fast server runs the same OS that
will run on the target VM.  I share my /build FS from the build
server(s) and install binary packages built there on production systems.

With libkver its possible to set up chroots for other versions as long 
as the binaries will run on the current kernel. libkver allows you to 
lie about kernel version and arch (as long as the arch is compatible 
with the kernel).


On 9.0-STABLE amd64 I build binary packages for 9.0 amd64, 8.2 amd64 and 
also for 8.2 i386 and 9.x i386. I do this with home grown scripts based 
around libkver + chroot. libkver is in pkgsrc. I do this for exactly the 
reasons the original poster flagged.


I don't want my pkgsrc builds taking down a server and I want my target 
systems to only have runtime dependencies install rather than all the 
build ones as well. pkg_comp1 supports most of this but I found its 
internal package building logic a little bit inflexible for my needs 
which is what led to the homegrown scripts. A pbulk based chroot using 
libkver may be better if working from in pkgsrc components.


Mike

Re: does anyone have a working mozilla firefox-74.0 on 9.0 amd64?

[Mike Pumford]

On 03/07/2020 16:31, Mayuresh wrote:

On Fri, Jul 03, 2020 at 03:47:41PM +0100, Sad Clouds wrote:

I've lost count of how many times I open a page and wait for JavaScript
bloat to load up with CPU spinning 100% for about 20 seconds. And it is
getting worse, as people are moving everything into web browsers.


Agree. But I think that's usually a result of poor design and poor coding
than a fault of using web for an application (vs desktop). (Of course,
there would be exceptions to that where you should rather use a desktop.)

Yep. I actually still test my own personal web apps on a single core 
i386 NetBSD 9 laptop.



For 90% of my browser usage (reading, searching, general browsing) I have
been using elinks for years. Turn to firefox only when there is no option.
At times I disable javascript in firefox as well.

To be fair I use firefox with an ad-blocker by default. Deals with most 
of the awful JS on most pages anyway ;)


Mike

Re: does anyone have a working mozilla firefox-74.0 on 9.0 amd64?

[Mike Pumford]

On 03/07/2020 13:15, Sad Clouds wrote:

On Fri, 3 Jul 2020 10:17:03 +0100
Mike Pumford  wrote:

I wouldn't go that far in praising web browsers and the technology they
are built on. It's so clunky, bloated and buggy, it's not even funny.
On a daily basis, I'm forced to use crappy and slow web apps - agile
boards, code review boards, development wiki, bug reporting, etc. All of
them are just awful and laggy. Has anyone tried using VMWare vSphere
cloud app, it's too painful to describe the experience.

I have some sympathy for that. Its possible to write bad code everywhere 
an web apps are a good example of that. There are an awful lot of really 
bad developers in that space.


Also I used the vSphere windows app and that was a painful experience as 
well so that's more down to vSphere than the platform as well ;)


That said it is entirely possible to write fast and useful applications 
that run in the browser and its far easier to reach across platforms 
that way than using a toolkit like GTK or Qt (which are your cross 
platform graphical alternatives).



The current trend of moving native desktop applications to cloud and
web browsers, simply frustrates and infuriates me. Yes you could build
a house out of Weetabix, but that doesn't mean that you should.

Done right there is no reason the app has to be either bloated or slow, 
that's down to the skill of the developer. So you are being put off by 
bad examples rather than a bad platform. Is it a perfect platform? No, 
but its not particularly worse than any other GUI framework I've used 
(which includes GTK, MFC and Win32). However you don't tend to see the 
REALLY BAD native apps as they never escape outside the organisation 
that wrote them most of the time. The really bad web apps escape all the 
time :(


If I'm honest I'd rather write an app that sources data from remote 
services in Typescript using a framework like Vue or Angular rather than 
attempt to do the same in Java, Rust, C or C++ and I say that as someone 
with 15+ years of C, C++ experience. Its a different picture if you only 
support 1 platform and if you don't have to do any sort of remote data 
gathering or control.


Mike

Re: does anyone have a working mozilla firefox-74.0 on 9.0 amd64?

[Mike Pumford]

On 03/07/2020 10:17, Mike Pumford wrote:



On 03/07/2020 03:52, Mayuresh wrote:

On Wed, Jul 01, 2020 at 05:34:11PM -0700, Greg A. Woods wrote:

So, does anyone have a working mozilla firefox-74.0 on 9.0 amd64?


Also to answer this question. My NetBSD 9.0-STABLE amd64 system is 
currently running firefox 77.0.1 built from source. I always build a 
complete package set in a chroot and its rare that I end up with a 
non-working firefox as long as the build succeeds.


I'm struggling to build it on i386 as I keep getting out of memory 
errors from LLVM. I only have one system I want that for and I don't use 
it much so I've not really looked too much into fixing it.


Mike

Re: does anyone have a working mozilla firefox-74.0 on 9.0 amd64?

[Mike Pumford]

On 03/07/2020 03:52, Mayuresh wrote:

On Wed, Jul 01, 2020 at 05:34:11PM -0700, Greg A. Woods wrote:

So, does anyone have a working mozilla firefox-74.0 on 9.0 amd64?


I haven't upgraded from NetBSD 8 to 9 and news on firefox just adds to my
inertia to upgrade.

Just curious. Which factors have led to firefox being such a mess:

- Is it firefox itself? Badly written, non portable code etc?

- Is it the rust language or libraries?

- Or is it the rust compiler?

- Or is it LLVM / CLang etc.

- Any other factors / combinations of factors.

Fundamentally you would have the same problem with any web browser 
trying to keep up with modern web standards. They are amongst the 
largest applications in terms of dependencies and features that most 
people use on a daily basis.


The reason firefox looks bad is that its the goto browser for most 
people on non-Windows systems. If webkit or chromium has the same level 
of scrutiny you would see the same level of problems and the problem 
they both have is that they are really just the rendering engine and 
need wrapping with other code to produce a functional browser.


I think Rust makes it marginally worse but thats actually down to rust 
running into bugs in NetBSD (the ld.so lock bugs) rather than rust 
itself being a poor idea. The rust compiler is no more memory intensive 
than modern GCC or LLVM.


Rust does limit the platforms that firefox can be built for but the 
chances are the platforms rust doesn't support would lack the resources 
to run firefox (it and most browsers) have a memory footprint that makes 
GCC look frugal on memory. Yoo also have to bear in mind that in many 
cases modern GCC doesn't support all NetBSD platforms out of the box. 
Its only thanks to the NetBSD team keeping the code from older versions 
integrated that keeps those platforms alive.


A full featured modern web browser has to support:

Rendering and layout engine supporting 2D & 3D graphics.
2D layout is flexible enough that you can write entire applications in 
it (e.g googledocs, office365) with the same level of functionality as 
the native desktop versions.


3D rendering engine is capable enough for quite a few games.

To support all that you have a complete javascript language environment. 
Because that environment supports downloading untrusted code in the 
internet it needs complex sandboxing to protect the local system. That 
language environment support JIT compilation and the core language 
library isn't small. On top of that you also have WebAssembly (not sure 
if firefox supports that yet). Which gives you another runtime and one 
that is supposed to be as fast as compiled code. Its a support LLVM 
backend which means you now have a runtime for compiled applications as 
well.


Sandboxing also bites again for actual web content the content it 
processes is untrusted it runs each tab in a separate process to prevent 
leakage between tabs. This would still be a requirement even if there

was much more limited scripting capability

There are many people that hate the fact that this level of development 
in a browser is possible but the is no denying its usefulness as its a 
cross system platform for writing applications that far outweighs 
anything else I've ever had access to. Its so powerful that you can 
actually incredibly common to build a web app, bundle it with a web 
rendering engine and ship it as a native app.


The size and scale of the browser runtime and its dependencies is 
something I spotted as browser runtimes became more common in embedded 
systems. When I first started making images of that type the toolchain 
was the slowest part of the system build. Once things like webkit or 
chromium crept in their build time (and their dependencies) dwarfed the 
time taken to build the toolchain and were the thing that took the 
majority of the time to build.


Mike

Panic on 9.0-STABLE (built and checked out 23 May 2020)

[Mike Pumford]

Backtrace is as follows:

[ 2364420.854318] fatal page fault in supervisor mode
[ 2364420.854318] trap type 6 code 0x2 rip 0x80227d4c cs 0x8 
rflags 0x10

246 cr2 0x50 ilevel 0x8 rsp 0x80013b4f1ee8
[ 2364420.854318] curlwp 0xa37c4b8e4b00 pid 0.58 lowest kstack 
0x80013b4

ef2c0
[ 2364420.854318] panic: trap
[ 2364420.854318] cpu7: Begin traceback...
[ 2364420.854318] vpanic() at netbsd:vpanic+0x160
[ 2364420.854318] snprintf() at netbsd:snprintf
[ 2364420.854318] startlwp() at netbsd:startlwp
[ 2364420.854318] alltraps() at netbsd:alltraps+0xbb
[ 2364420.854318] nvme_ns_dobio() at netbsd:nvme_ns_dobio+0xa2
[ 2364420.854318] ld_nvme_start() at netbsd:ld_nvme_start+0x6e
[ 2364420.854318] ld_diskstart() at netbsd:ld_diskstart+0x7d
[ 2364420.854318] dk_start() at netbsd:dk_start+0x102
[ 2364420.854318] nvme_q_complete() at netbsd:nvme_q_complete+0xd6
[ 2364420.854318] softint_dispatch() at netbsd:softint_dispatch+0xab
[ 2364420.864322] cpu7: End traceback...


Based on the datestamp of the crash the system is likely to have been 
doing a couple of pkgsrc builds in chroot environments.


I've got the crashdump from the failure so if someone wants additional 
information I should be able to get it.


If this has already been fixed let me know and I'll update to a new 
9.0-STABLE :)


Mike

Re: pkgin refresh vs. upgrade?

[Mike Pumford]

On 17/06/2020 07:39, Lars-Johan Liman wrote:

Hi!


This is all based on observation rather than documentation.


When running pkgin to upgrade one or more packages, it often says "X
packages to refresh, Y packages to upgrade".

Refresh means the version hasn't changed but the package has been 
rebuilt since you last installed it from the repository.



What's the difference between a refresh and an upgrade of a package?


Upgrade indicates a version change.

And where is it documented? ;-)

That I don't know. Reason I know the answer is that I build my own 
binary packages and because my build method builds everything every time 
I see a lot more refreshes that I suspect would happen with packages 
coming from a bulk build.


Mike

Re: Postfix and local mail delivery - still relevant in 2020?

[Mike Pumford]

On 06/06/2020 16:54, Sad Clouds wrote:

I've been wondering - why have Postfix in the base system and why have
it enabled by default?

Its an invalid assumption to assume those reports are delivered locally 
perhaps? Postfix is also needed for sending mail.


I have multiple BSD machines so I have all my systems delivering their 
daily/weekly report message to one server. You also need postfix to send 
mail as well as receive it. Also I suspect send-pr might not work 
without it or some other MTA and we want people to be able to report bugs.


Mike

Re: zfs wedges

[Mike Pumford]

On 02/06/2020 17:36, Michael van Elst wrote:


Another method is to export and import the zpool. Importing scans disks
for ZFS labels and doesn't need the cached device paths. That's similar
to how LVM works.


Oddly enought I was curious and went googling and found:

https://forums.freebsd.org/threads/zfs-confused-by-renamed-devices.51234/

That seems to suggest exporting and re-importing as well.  :)

Mike

Re: zfs wedges

[Mike Pumford]

On 02/06/2020 17:14, Patrick Welche wrote:

How does one tell a zpool that the wedge it was on has been renumbered?

e.g., I just replaced a disklabel with a gpt, which created some wedges.
I created a zpool on one of the wedges. I rebooted, so the wedges renumbered
(which is normal), but then:
 NAME   STATE READ WRITE CKSUM
 ssdpoolUNAVAIL  0 0 0
   5276238111042164986  UNAVAIL  0 0 0  was /dev/dk26

which is true, it is just that /dev/dk26 is now called /dev/dk19.

Any ideas?

Don't know how to fix this as I've not played around with ZFS yet. 
Probably will next time my fileserver needs a capacity bump :). Is it 
possible to persuade ZFS to look for the gpt partition by its 
name(assuming it has one). This seems to be the solution for renumbering 
taken by /etc/fstab for other filesystems. That way it would keep 
finding it regardless of device name.



Mike

9.0-STABLE crash

[Mike Pumford]

Got this kernel panic while doing an unattented pkgsrc build. Sadly the 
dump is corrupt so I don't have the kernel crashdump to poke around in.


[ 133522.766252] uvm_fault(0xc5c4f4a49730, 0x0, 2) -> e
[ 133522.766252] fatal page fault in supervisor mode
[ 133522.766252] trap type 6 code 0x2 rip 0x80227d4c cs 0x8 
rflags 0x10246 cr2 0x50 ilevel 0x8 rsp 0x8b8140a32258
[ 133522.766252] curlwp 0xc5c5381d6760 pid 14643.7 lowest kstack 
0x8b8140a302c0

[ 133522.766252] panic: trap
[ 133522.766252] cpu6: Begin traceback...
[ 133522.766252] vpanic() at netbsd:vpanic+0x160
[ 133522.766252] snprintf() at netbsd:snprintf
[ 133522.766252] startlwp() at netbsd:startlwp
[ 133522.766252] alltraps() at netbsd:alltraps+0xbb
[ 133522.766252] nvme_ns_dobio() at netbsd:nvme_ns_dobio+0xa2
[ 133522.766252] ld_nvme_start() at netbsd:ld_nvme_start+0x6e
[ 133522.766252] ld_diskstart() at netbsd:ld_diskstart+0x7d
[ 133522.766252] dk_start() at netbsd:dk_start+0x102
[ 133522.766252] spec_strategy() at netbsd:spec_strategy+0xa7
[ 133522.766252] VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x6c
[ 133522.766252] dkstart() at netbsd:dkstart+0x184
[ 133522.776256] spec_strategy() at netbsd:spec_strategy+0xa7
[ 133522.776256] VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x6c
[ 133522.776256] genfs_do_io() at netbsd:genfs_do_io+0x18b
[ 133522.776256] genfs_gop_write() at netbsd:genfs_gop_write+0x52
[ 133522.776256] genfs_do_putpages() at netbsd:genfs_do_putpages+0xbf7
[ 133522.776256] VOP_PUTPAGES() at netbsd:VOP_PUTPAGES+0x53
[ 133522.776256] ffs_write() at netbsd:ffs_write+0x258
[ 133522.776256] VOP_WRITE() at netbsd:VOP_WRITE+0x50
[ 133522.776256] vn_rdwr() at netbsd:vn_rdwr+0xd9
[ 133522.776256] coredump_write() at netbsd:coredump_write+0x56
[ 133522.776256] coredump_elf32() at netbsd:coredump_elf32+0x6ea
[ 133522.776256] coredump() at netbsd:coredump+0x58a
[ 133522.776256] sigexit() at netbsd:sigexit+0x2f4
[ 133522.776256] sendsig() at netbsd:sendsig
[ 133522.776256] lwp_userret() at netbsd:lwp_userret+0x149
[ 133522.776256] netbsd32_syscall() at netbsd:netbsd32_syscall+-0x1f13d3
[ 133522.776256] cpu6: End traceback...
[ 133522.776256] uvm_fault(0xc5c65df71a38, 0x0, 2) -> e
[ 133522.776256] fatal page fault in supervisor mode
[ 133522.776256] trap type 6 code 0x2 rip 0x80957bd8 cs 0x8 
rflags 0x10246 cr2 0x84 ilevel 0x8 rsp 0x8b813d79abe0
[ 133522.776256] curlwp 0xc5c603568760 pid 9885.1 lowest kstack 
0x8b813d7982c0


[ 133522.776256] dumping to dev 168,2 (offset=33809639, size=4162403):
[ 133522.776256] dump [   1.000] Copyright (c) 1996, 1997, 1998, 
1999, 2000, 2001, 2002, 2003, 2004, 2005,


The dump is so corrupt I can't even clear it. I get:
# savecore -c
savecore: /dev/rdk2: kvm_dump_inval: invalid translation (invalid level 
3 PDE)

Wierd console output 9.0 stable

[Mike Pumford]

Seeing the following super cryptic console output:
[ 17359.879562] 00016888 :  00012050
[ 17359.879562] 0001688c :  00010001
[ 17359.879562] 00016890 :  00022050
[ 17359.879562] 00016894 :  00010001
[ 17359.879562] 00016898 :  0001a050
[ 17359.879562] 0001689c :  00010001
[ 17359.879562] 000168a0 :  
[ 17359.879562] 000168a4 :  0c00
[ 17359.879562] 000168a8 :  010d
[ 17359.879562] 000168ac :  
[ 17359.879562] 000168b0 :  1105
[ 17359.879562] 000168b4 :  00012050
[ 17359.879562] 000168b8 :  0001
[ 17359.879562] 000168bc :  00022050
[ 17359.879562] 000168c0 :  0001
[ 17359.879562] 000168c4 :  0001a050
[ 17359.879562] 000168c8 :  0001
[ 17359.879562] 000168cc :  0401
[ 17359.879562] 000168d0 :  18802100
[ 17359.879562] 000168d4 :  7fde4000
[ 17359.879562] 000168d8 :  7a02
[ 17359.879562] 000168dc :  001010a1
[ 17359.879562] 000168e0 :  00332080
[ 17359.879562] 000168e4 :  
[ 17359.879562] 000168e8 :  1101
[ 17359.879562] 000168ec :  00012044
[ 17359.879562] 000168f0 :  00015734
[ 17359.879562] 000168f4 :  1101
[ 17359.879562] 000168f8 :  00022040
[ 17359.879562] 000168fc :  00015734
[ 17359.879562] 00016900 :  1101
[ 17359.879562] 00016904 :  0001a044
[ 17359.879562] 00016908 :  00015734
[ 17359.879562] 0001690c :  
[ 17359.879562] 00016910 :  1081
[ 17359.879562] 00016914 :  00c0
[ 17359.879562] 00016918 :  00015734
[ 17359.879562] 0001691c :  0100
[ 17359.879562] 00016920 :  0b160001
[ 17359.879562] 00016924 :  00015735
[ 17359.879562] 00016928 :  
[ 17359.879562] 0001692c :  
[ 17359.879562] 00016930 :  7a02
[ 17359.879562] 00016934 :  0012
[ 17359.879562] 00016938 :  
[ 17359.879562] 0001693c :  
Where is this coming from. It looks like some escaped debug output.

And also the less cryptic:
 76522.436074] netbsd32_mmap: retval out of range: 0xff403000
[ 76522.436074] netbsd32_mmap: retval out of range: 0xff403000
[ 76522.436074] netbsd32_mmap: retval out of range: 0xff403000
[ 76525.017045] netbsd32_mmap: retval out of range: 0xffe41000
[ 76525.017045] netbsd32_mmap: retval out of range: 0xffe41000

Mike

Re: Slow read(2) and write(2) syscalls

[Mike Pumford]

On 29/04/2020 15:37, Sad Clouds wrote:

On Wed, 29 Apr 2020 09:17:54 +0100
Chavdar Ivanov  wrote:


On my VirtualBox 6.1.6 guest running -current amd64 I get:

$  time cat 80mb > /dev/null
cat 80mb > /dev/null  0.00s user 0.02s system 98% cpu 0.021 total


dd if=/dev/zero of=out bs=1m count=1

do you get similar I/O throughput on NetBSD and Linux guests?

Make sure you use the fdatasync option on linux when using dd for 
writing. Otherwise it just writes as much as it can to cache and then 
returns without actually waiting for the write to complete falsely 
inflating the performance.


I haven't tried with anything later than 7 but I use virtual box hosted 
on windows a lot with ahci storage emulation. In the last tests I did I 
was getting 100MB/s write performance with both Ubuntu (kernel 4.4) and 
NetBSD 7.  For reference the underlying disk in that case was a 2TB ATA 
attached to an AHCI controller.


I can spin up a 9.x VM and test that relatively easily. current would 
take a little longer as I'd have to build it first :)


Mike

Re: Booting from a USB disk

[Mike Pumford]

On 28/04/2020 11:23, Ilia Zykov wrote:

I had such a case. The efi of my old server(it was Intel MB) only
supported a 16 bit vfat boot partition. And if during installation I
selected it over 128MiB, then the installer formatted it at 32 bit vfat
and I could not boot in EFI mode. See the default parameters
“mkfs.vfat –F”.

That could be a difference. I was migrating an existing install onto a 
new disk so all my EFI partitions were created manually so I might well 
have overridden default arguments if thats what the instructions I was 
following said to do. It could also be dependent on the age of the EFI 
BIOS. With newer ones being more flexible about VFAT format.


Mike

Re: Booting from a USB disk

[Mike Pumford]

On 28/04/2020 09:26, Martin Husemann wrote:


Now you deleted the FreeBSD boot stuff, and everything worked fine.

Should be totally unrelated to the partition size.
There is no limitation in NetBSD. My 9 STABLE machine EFI booting off an 

nvme device has a 256MB EFI partition and boots with no issue.

Mike

Re: !Playing video on integrade intel graphic card

[Mike Pumford]

On 27/04/2020 10:22, John m0t wrote:

Hi;
Playing video on T9300 CPU and Intel integrated GPU causes choppy and sluggish 
video playback.
This effect is that much worse that causes system hang and restart.
Only mpv is able to play the video but mplayer just plays sound and vlc would 
segfault.

  > mpv Downloads/Saturday_Night_Live_S41E03_480p_HDTV_Hiva.mkv.part
[mkv] mkv metadata beyond end of file - incomplete file?
  (+) Video --vid=1 (*) (h264 848x480 29.970fps)
  (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
AO: [oss] 48000Hz stereo 2ch s32
VO: [gpu] 848x480 => 853x480 yuv420p
AV: 00:00:00 / 01:05:33 (0%) A-V: -0.008 Dropped: 15

Well based on that output the inconsistent behaviour and crashing is 
reasonable. You are playing an incomplete file. If the file is being 
downloaded with a torrent tool that could also explain the choppy as 
there could be incomplete data at various points in the file. Although 
based on the .part extension I'm guessing its a web browser download.


That doesn't mean there isn't a problem with the xorg video playback but 
it would be good to verify with a complete file.


Mike

Re: GEFORCE GTX 1660

[Mike Pumford]

On 24/04/2020 12:50, Todd Gruhn wrote:

I stumbled on this:

https://www.nvidia.com/Download/driverResults.aspx/159361/en-us

It has source code, and is for FreeBSD.

I have run commercial software that was compiled for FreeBSD on NetBSD
(just have to add "Binary Compatibility" to the kernel config.

Any thoughts/ideas here?


If only it were that simple. :(

X display drivers have kernel mode components and its not remotely easy 
to take a kernel module from FreeBSD and drop it into NetBSD they are 
very different. The binary compatibility only extends to application 
components not kernel components.


Mike

Re: Linux compat and swap

[Mike Pumford]

On 23/04/2020 11:48, tlaro...@polynum.com wrote:

[Please forgive me to give supplementary information gathered for all
answers and "before". And thank you to all for answering.]

To be more precise:

The node is not a desktop node but a server one (so there is no X11
running, so no firefox or whatever), with two main functions:

1) A file server;
2) A processing node for data (GIS) manipulations, since there can be
huge amounts of data to process, so it is more efficient to process
where it is saved due to the network capabilities.

In my case the build machines main purpose is as a build server (hence 
the jenkins server which is a java process). I use it as a desktop when 
developing things as its my most powerful BSD build machine and its 
easier to develop when you can use a browser to check API references etc 
so its desktop use is intermittent. So they were just examples of memory 
hungry processes that got swapped out unexpectedly rather than the only 
ones.



The node' uptime is 225 days (since some disk replacements) serving
during office time files to 2 to 6 nodes. And it is processing data
(sometimes during office time; generally outside office time).

It has 3862 MB of avail memory.

When using a program to convert coordinates, this program being a Linux
binary, the program bailed out, 3 times in a row, after processing 20M
records. Splitting the input data under this amount, I managed to
process everything.

Could you be running into the data size limits for the process? ulimit 
-d is data size, -s is stack size. If a process hits those limits it may 
be killed even if there IS memory available to protect the rest of the 
system.


Here's a comparison from the bash ulimit on BSD and linux:

BSD system has 2GB of RAM:
$ ulimit -a
number of threads   (-T) 1024
socket buffer size   (bytes, -b) unlimited
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) 524288
file size   (blocks, -f) unlimited
max locked memory   (kbytes, -l) 669921
max memory size (kbytes, -m) 2009764
open files  (-n) 2048
pipe size(512 bytes, -p) 1
stack size  (kbytes, -s) 4096
cpu time   (seconds, -t) unlimited
max user processes  (-u) 300
virtual memory  (kbytes, -v) unlimited

Ubuntu 18 Linux (VM with 8GB of RAM):
$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 31721
max locked memory   (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 31721
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Note the fact that linux has datasize unlimited by default. That BSD 
datasize does not scale with system memory. Its still 512MB even on my 
system with 16GB of RAM. All my build wrappers for pkgsrc do ulimit -d 
to allow for the compile processes to grow really large (which they do :( )



=> This is why I jumped to the conclusion that the program had memory
leak because processing should be one line of input at a time so
whatever the number of lines, I fail to see why it would need more
memory for more records.

Perhaps its badly written. ;) As I said in an earlier e-mail I had a log 
crunching program that leaked in the same sort of way. It did store 
small amounts of data for each line processed but the leak was actually 
caused by a logic error in a core loop than inadvertently caused memory 
to be kept around for every line processed.

I found, afterwards, in /var/log/messages, that this program was killed
because "out of swap".


Concerning my sentence "RAM is not exhausted", my assumption (another
one...) was that when memory for processing was getting scarced, file
caching was reduced since there seems to be a basic "page" device for
files: the file on disk. So for me, when there was still a huge amount
of memory for file caching there was still a huge amount of memory as
spare for programs at the detriment of file caching hence speed.

See above about process limits. you might find ulimit -d unlimited will 
let the process use more RAM and possibly even run to completion.


Mike

Re: Linux compat and swap

[Mike Pumford]

On 23/04/2020 08:18, Sad Clouds wrote:

On Wed, 22 Apr 2020 20:46:08 +0200
tlaro...@polynum.com wrote:


(This can be also simply a memory leak in the program but since the
RAM is not exhausted...).


Without much detail about how much memory, swap, etc your system is
using, it's anyone's guess really. You say "RAM is not exhausted" but
that why would the system be swapping? Maybe you're not looking at it
at the right time, it is possible for a process to malloc() large
amount of memory and then quickly release it, by the time you look at
it, some processes got swapped out, but the memory got released to the
system.

I agree with all this but I'd add one more thing to the mix that might 
help your system ride out this better.


If you have both memory intensive and filesystem intensive processes 
running on a NetBSD system the kernel filesystem cache can end up 
evicting programs running in the background that are inactive which then 
take a LONG time to recover. For a system with a reasonable amount of 
memory I found the vm.filemin and vm.filemax needed to be tweaked so 
that filesystem cache was more likely to be tweaked than program code.


I set:
vm.filemax=10
vm.filemin=1
in /etc/sysctl.conf for a system with 16GB of RAM.

Before I made those changes pkgsrc builds of things like rust and 
firefox would end up with over 60% of the RAM dedicated to FS cache 
forcing the swap out of the jenkins server process that was running the 
build! It would also do the same to live firefox/thunderbird processes 
running on the same system and pretty much the only way back was a 
reboot as these processes could never swap themselves back in in a sane 
amount of time :(


I've also seen the same sort of odd memory consumption behaviour in 
scripts that 'just' process text files. I once managed to write a perl 
script that parsed firewall logs that ended up consuming all ram on the 
system for a reasonable sized log. I never noticed it on FreeBSD and 
NetBSD (I just put the disk activity down to the fact it was crunching a 
large log file). However when I tried to run the same script on Linux it 
would never complete as Linux wasn't able to deal with its memory hog 
nature at the time (this was years ago on Linux kernel 2.0).


Mike

Mike

Re: DNSSEC vs netbsd-8/sparc?

[Mike Pumford]

On 21/04/2020 17:38, John D. Baker wrote:


I seem to recall the real issue there was "dnssec-lookaside auto" being
set in "named.conf" and the "dlv.isc.org." key in "bind.keys" being
expired.  The canned root keys in the file are valid (at least the second
one).  If one has the latest updates to netbsd-{7,8,9,current}, the
"bind.keys" file are all up-to-date and identical aside from RCS IDs.

The solution was to comment-out or remove the "dnssec-lookaside" option.
The latter has been done for netbsd-{8,9,current}.

Yes. That was certainly what blew up my DNSSEC nameservers running on 
8-stable/amd64. Once I took away the lookaside option dnssec resolution 
started working (and I was able to get at the protonmail domain that 
triggered the change).

I have no idea if the present problem is related to that or not - just
asking if it was a "netbsd-8 on amd64 works, fails on sparc" clear case.


I have 2 DNS servers running netbsd-8/amd64 and DNSEC both wit the 
following DNSSEC options setup:


options {
directory "/etc/namedb";
dnssec-enable yes;
dnssec-validation yes;
#dnssec-lookaside auto;
managed-keys-directory "keys";
bindkeys-file "bind.keys";
}
These are the primary and secondary recursive resolvers for my local 
network and I don't see any problems resolving domains. So it is likely 
to be a architecture specific issue.


Mike

Re: mDNS in base image

[Mike Pumford]

On 20/04/2020 17:23, Greg Troxel wrote:

Things are occasionally removed from base if there is broad consensus
that the overall NetBSD user community would be better off within them
in base.   So far, I see no reason to think mdnsd is one of them.

In the case of mdns not having it in base would prevent base components 
from using it. Which might then just lead to people having to install 
even more stuff from pkgsrc to replace base versions just because they 
want mdns support in them.


Mike

Re: SMTP servers receiving from gmail

[Mike Pumford]

On 17/04/2020 19:44, ignat...@cs.uni-bonn.de wrote:

On Fri, Apr 17, 2020 at 10:52:37AM -0700, Greg A. Woods wrote:



I doubt they demand either.


You many not care about delivery to sites that do care but I've 
certainly had e-mail bounced or classified as spam due to the lack of a 
PTR record or SPF. Since I can't choose who my friends pick as their 
e-mail provider its down to me to resolve issues so I can send them 
messages.



I looked at their cryptic web pages referenced in the error, and
links therein, and it seemed to me that they do. They probably do a
statistics per address range dance on top of it. (All from memory.)

Yes if you have a static IP that hasn't changed forever and has never 
sent a spam message chances are it won't really care. If you have a 
newer IP thats known to be in a DSL assigned range (even if its static) 
they might well be more picky. If I'm honest I've no idea if google care 
about SPF for my domain. Daft as it may seem to some people SPF works 
for my mail domain as I can make sure all the messages come from a small 
set of allowed IPs very easily and it was an easy way to stop e-mail 
from my domain being classed as spam by AOL.


Mike

Re: Patch to update Exim to 4.93.0.4

[Mike Pumford]

On 16/04/2020 12:32, Thomas Klausner wrote:

On Thu, Apr 16, 2020 at 12:17:02PM +0100, Mike Pumford wrote:

Looks like I need to pull more fixes from the 4.93+fixes branch upstream.
How do I ensure that the patches get applied in a particular order as from
the research I've done thats important.


We don't want to maintain exim on a git level in pkgsrc - I suggest
requesting a release from upstream.

I can sympathise with that but without these patches exim can randomly 
crash or stop delivering mail due to really bad assumptions about how 
the heap allocator works and then tries to detect when those assumptions 
break. I can maintain them as local patches if necessary but exim from 
pkgsrc is going to be a risky proposition without them.


The exim policy isn't actually to release these branches but provide 
bugfixes as git patches for package maintainers. Even the 4.93.0.4 
release is an anomaly because of the really crazy bugs. Going to 
4.93.0.4 has improved things but I'm still seeing random crashes or 
queue stalls. FreeBSD ports does have the patches (named alphabetically 
so that they are applied in order). I



As for your question: if we add the patches in pkgsrc in the patches/
directory, they should be one-patch-per-source-file, so all
modifications for one file combined into one patch.

That may not be possible without a LOT of extra work. I'm going to try a 
the patch series as local patches first and see what happens. They have 
to be applied in order as there are multiple patches that touch the same 
file.


Mike

Re: How to set font size of xterm

[Mike Pumford]

On 16/04/2020 06:20, Fekete Zoltán wrote:

The first approach I recommend is to start program xfontsel. There 
select a font you like, and copy its description.

Then try it out like this:
$ xterm -font *-fixed-*-*-*-18-*

xterm also works with the true type fonts provided both in the core X 
distribution and pkgsrc via fontconfig.


e.g
XTerm*faceName:DejaVu Sans Mono
XTerm*faceSize:10

These are anti-aliased which tends to look better if you have a graphics 
card capable of doing the processing. It might however be slow on a 
non-accellerated setup in which case the recomendations above are better.


Mike

Re: SMTP servers receiving from gmail

[Mike Pumford]

On 16/04/2020 08:14, ignat...@cs.uni-bonn.de wrote:

It might help to have a PTR record for the smtp clients' outgoing address;
last time I had that problem with Google it had gone lost when switching
nameserver machines and the backup wasn't up-to-date. However, SPF seems
to work to pacify Google and isn't very difficult to setup.

I'd forgotten that. I do have that set up correctly and thankfully my v4 
and v6 allocations have never changed.


Mike

Re: SMTP servers receiving from gmail

[Mike Pumford]

On 15/04/2020 21:55, Rhialto wrote:

On Tue 14 Apr 2020 at 18:44:54 +0100, Mike Pumford wrote:
I have the reverse problem, more or less. When sending mail to a google
server, it doesn't want to receive it. At least, when I'm using IPv6.
In the past, it helped to force it to use IPv4 instead, but I haven't
looked recently if that still worked.

Just sent one to gmail using v6 and it went through. Only thing I've 
done for my domain is set up an SPF record. I set that up a while back 
as quite a few big providers seem to require it. The gmail headers do 
indicate that it recognised my SPF record.


Mike

SMTP servers receiving from gmail

[Mike Pumford]

I've been tracking a problem where my NetBSD SMTP server was unable to 
receive e-mail from google getting failures reported as:


read error: FAILED_PRECONDITION: read error (0): error

Tracking it through with tcpdump showed that the google servers were 
making the connection, doing the STARTTLS SSL handshake and then 
disconnecting without sending the message.


Turns out that if you have opportunistic STARTTLS turned on you had 
better have an SSL crypto setup that google are happy with. For exim I 
had to set the following options:



#dhparam downloaded from: https://ssl-config.mozilla.org/ffdhe2048.txt
tls_dhparam = /usr/pkg/etc/exim/dhparam

# intermediate configuration
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
tls_require_ciphers = 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:

ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-P
OLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM
-SHA384

This came from:
https://ssl-config.mozilla.org/#server=exim=4.93=intermediate=1.1.1d=5.4

which also has a config that would suit the base system postfix.

Just wanted to get this out there in case anyone else was being baffled 
by a similar problem and couldn't find any clues on google as its taken 
me nearly 2 weeks to figure this out :(


Mike

Re: System-slowness and graphics cards

[Mike Pumford]

On 09/04/2020 19:59, Todd Gruhn wrote:

here is a portion of me Xorg.log.0 file:

Does "No monitor specified ... " have anything to do with the slow X startup?

I recalled that 10yrs ago I set a MODELINE to my X config, and X came up much
faster. ANY CONNECTION?

Not really. Mode stuff tends to be a lot more automatic even with the 
VESA driver which is what your setup is using. Vesa would be slow if you 
have applications that use render acceleration. Sadly I think in this 
day and age this includes xterm by default. You may find it better to 
configure xterm to use one of the older fixed pitch X fonts rather than 
the newer anti-aliased ones that I think are the default now.


Other than that I can't think of any other ways to improve it. :(

Mike

Re: System slowness and graphics-card

[Mike Pumford]

On 09/04/2020 14:33, m...@netbsd.org wrote:

I had the same issue before getting nouveau to work. Had a theory I
never tested that it might be the xf86-video-nv driver causing these
issues. I imagine the best experience you could have is by forcing genfb
somehow and using the x wsfb driver. one way to do it is by selecting
one of the vesa modes in the bootloader, another (I think) is the uefi
bootloader.

I'd be slightly astonished if nv would even recognise a card that new. 
The nv driver is even older than the NetBSD kernel KMS layer (which 
doesn't support that card).


Mike

Re: NetBeans Unexpected error: the trustAnchors parameter must be non-empty

[Mike Pumford]

On 08/04/2020 13:45, Greg Troxel wrote:

However, many complicated systems don't use the system list of
pre-trusted root certificates, but instead have their own scheme.
firefox is like this.  I have no idea about java, but I would not be
surprised because java has a "we are the single consistent world and the
OS is just here to run java" mentality.   Given the Ubuntu package is
called java-cet, I would guess that it does something to configure the
jre.

JDK8 certainly does do that. The NetBSD jdk8 package depends on 
mozilla-rootcerts and bakes them into the JDK trust anchors.


Mike

Re: System slowness and graphics-card

[Mike Pumford]

On 07/04/2020 15:11, Todd Gruhn wrote:

The system I am using was assembled and purchase back in Aug 2019.

Some things I noticed:
   1) The graphics card (nVidia GEFORCE GTX 1660)  needs to be booted using
   boot -c ; disable nouveau; quit
Okay this means you are disabling the KMS driver which means no 
acceleration in X.
After a quick google this is a TU116 chip which isn't supported in 9.0 
stable. You might have to disable nouveau if you were running the 
original 9.0 release as the patch to auto disable came down the pipe 
after the release was cut.



2) When I compile a package -- and X Windows is NOT RUNNING -- this thing
flies
3) When I start X (using MWM) -- builds are extremely slow;
When I do "su root" checking the root passwd takes about 3 minutes
 > Is there a connection between X, my graphics card, and system slowness?
Seems likely I'd guess X has no driver so is doing everything in 
software using the vesa driver. Without the nouveau kernel driver you 
can't use the new X driver and the old pre-KMS nv driver will also not 
support the card.
I do find it a bit surprisping that an X setup with mwm would be slow as 
thats a fairly lightweight window manager so even in vesa mode I'd 
expect any reasonable cpu to perform okay although that does depend on 
what you are doing in X. What things are you trying to run?




Is there a way to fix this; or is it a matter of having support for my chip-set?

There isn't newer support even in current so you either need an older NV 
card or an older AMD card to get supported hardware. This may of course 
be limiting in other ways if you dual boot the system and play games. :(



Mike

Re: Looking for java an android devs on netbsd environment

[Mike Pumford]

On 07/04/2020 08:17, John m0t wrote:


https://0bin.net/paste/U0nua5ZwZOVrRE6f#B6ogE0SlRptwkE6WObF4KywuFVU+sSV3C0dhJjvIrSH

On my previous NetBSD 9.0 install, I pkgin all the full suse emulation 
package(s) and I managed to even run idea-IU-193.6911.18 with its own JBR 
version. (man the font rendering was awesome there). but the same error was 
present there too. the IDEA can't even compile simple hello world. with that 
the same error)

I ran into a similar (but not the same) problem when doing certain 
things with jenkins on openjdk8. That error looks like its wanting a 
native binding for a particular API set.


In my case I was able to find a patch in FreeBSD pkgsrc that resolved 
the problem and with a bit of help from one of the pkgsrc developers got 
it applied to the NetBSD JDK package. The FreeBSD patches tend to get 
upstreamed as the versions move forward so you may have to look in their 
revision history to find the relevent patch.


Mike

Re: Generating static htmls with interactive plots

[Mike Pumford]

On 06/04/2020 11:30, g...@duzan.org wrote:

=> I have a NetBSD based web server which serves mainly static contents and
=> files. There is one requirement to include some time series plots with
=> some monthly data points - so, the plots do not need to take any
=> parameters from a browser and can be statically generated.
=>
=> Only requirement is for the plots to have some interactivity, such as
=> zooming, panning, mouseover text and so on.
=>

IF you can provide the data as a static file (say in json format) you 
can use plotly.js on the browser side to turn that into a graph. The 
plotly.js library supports zooming/panning and other functionality all 
without refetching the data from the server.


I use this as part of a full vuejs application (with nodejs backed) for 
displaying server monitoring data but its not particularly hard to load 
the data into plotly on the browser side and use it stand alone. This is 
what I did in my early experimental phases.


If you want I can provide some of my simple js test code to help you out.

Mike

Re: Looking for java an android devs on netbsd environment

[Mike Pumford]

On 03/04/2020 15:49, Greg Troxel wrote:

"John m0t"  writes:




c. eclipse

eclipse ought to work its a java application although I have no direct 
experience on NetBSD I've always found its ui so frustrating when I'm 
forced to use it that I'd never use it voluntarily (which covers all my 
NetBSD tools).



d.intellij idea


NetBSD has linux emulation, so the above might actually work.  Sort of
on my list to do this eventually, but I don't have anything useful to
say.


e. qt creator


I suspect that works fine.


f. java (oracle java vs OpenJDK)(which version/versions? 1.8? 11?)


openjdk8 runs fine on netbsd-8/amd64 - I have successfully run josm and
mkgmap from openstreetmap, and unifi from Ubiquiti.  openjdk11 builds
and I believe works.

I'm also using openjdk8 successfully on 9.0/amd64 to run jenkins. I 
didn't have a lot of luck running jenkins on opendjk 11 but that could 
have been jenkins rather than openjdk11 and I've not had the time to 
revisit it since.


 Mike

Re: DNS Failures - All of a sudden today 20200325

[Mike Pumford]

On 25/03/2020 20:56, Havard Eidnes wrote:

My caching dns failed unexpectedly today, apparently I was not alone:
https://www.mail-archive.com/bind-users@lists.isc.org/msg28624.html
 From ISC: "We apparently let our signatures on dlv.isc.org expire."


Ouch!


I fixed this temporarily by adding:
   dnssec-accept-expired yes;
Which feels risky...


Yes, I would not do that.


Another user on the ISC list suggested setting
   dnssec-lookaside no;
Which also feels risky.


No, that's not risky at all!

Not only that putting dnssec back to auto and removing dnssec-lookaside 
and everything works:

$ ping6 www.google.com
PING6(56=40+8+8 bytes) 2001:8b0:84:1::1 --> 2a00:1450:4009:819::2004
16 bytes from 2a00:1450:4009:819::2004, icmp_seq=0 hlim=58 time=13.812 ms
16 bytes from 2a00:1450:4009:819::2004, icmp_seq=1 hlim=58 time=13.589 ms
16 bytes from 2a00:1450:4009:819::2004, icmp_seq=2 hlim=58 time=13.519 ms

And even:
$ ping protonmail.ch
PING protonmail.ch (185.70.41.32): 56 data bytes
64 bytes from 185.70.41.32: icmp_seq=0 ttl=55 time=34.651610 ms
64 bytes from 185.70.41.32: icmp_seq=1 ttl=55 time=34.876867 ms
64 bytes from 185.70.41.32: icmp_seq=2 ttl=55 time=34.690384 ms

So this fixes the protonmail.ch problem as well which I could reproduce 
as well.


Mike

Re: trouble resolving protonmail.ch, dnssec, seems netbsd-specific maybe

[Mike Pumford]

On 24/03/2020 09:57, Havard Eidnes wrote:


which doesn't match.

This has just got a lot worse. As of about 20 minutes ago I've had to 
completely disable dnssec validation on my NetBSD 8.1-stable servers as 
I had a complete loss of name resolution. Every domain was failing to 
resolve (e.g www.google.com). This was with dnssec-validation set to 
auto. After setting this to off all dns resolution immediately started 
working again.


Mike

Re: trouble resolving protonmail.ch, dnssec, seems netbsd-specific maybe

[Mike Pumford]

On 25/03/2020 16:58, Havard Eidnes wrote:

This has just got a lot worse. As of about 20 minutes ago I've had to
completely disable dnssec validation on my NetBSD 8.1-stable servers
as I had a complete loss of name resolution. Every domain was failing
to resolve (e.g www.google.com). This was with dnssec-validation set
to auto. After setting this to off all dns resolution immediately
started working again.


I can't fully explain that, I'm afraid.  The /etc/named.conf shipped
in netbsd-8 also contains the "new" root key which is still in use to
this day, so that part should be OK.

Auto seems to download new keys that replace the keys distributed. Its 
possible something has gone wrong with the key distribution 
infrastructure and my current keys expired and I wasn't able to get new 
ones. I need it to work for a few hours so I'll have to run with it 
turned off for a few hours at least.


I will experiment with re-enabling auto (and also trying yes) and seeing 
what happens later on once I'm not on the work clock.



The only similar thing I have experienced is that if your local clock
is way off you can get similar symptoms (yes, the coin cell keeping my
RTC running is apparently "out of juice" on at least one of my old
machines), since DNSSEC signatures have validity intervals which
relate to "real timestamps", and if your clock is outside of the
validity interval, DNS name resolution (and in particular DNSSEC
validation) will fail with SERVFAIL being returned as the error code
to the client.

Both DNS servers have ntpd running and I would have got a nagios alert 
had either of them dropped out of sync so I can at least eliminate that one.


Mike

Re: Hundreds of crypto file descriptors for Apache httpd

[Mike Pumford]

On 10/03/2020 10:57, Frank Wille wrote:

Michael van Elst wrote:




But is it normal to create more than 200 crypto file descriptors for each
httpd process? Then I would have to recompile PHP with a larger FD_SETSIZE,
as it seems?

That seems excessive. My admittedly lightly loaded SSL server here has 6 
crypto filehandles open. One for each httpd process. Doesn't seem to go 
up at all when I push some traffic through it so could it be a 
configuration oddity?


I seem to recall having to enable ssl session caching:
#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism
#   to use and second the expiring timeout (in seconds).
#SSLSessionCache "dbm:/var/run/ssl_scache"
SSLSessionCache"shmcb:/var/run/ssl_scache(512000)"
SSLSessionCacheTimeout  300

And:
SSLUseStapling On

#   Define a relatively small cache for OCSP Stapling using
#   the same mechanism that is used for the SSL session cache
#   above.  If stapling is used with more than a few certificates,
#   the size may need to be increased.  (AH01929 will be logged.)
SSLStaplingCache "shmcb:/var/run/ssl_stapling(32768)"

#   Seconds before valid OCSP responses are expired from the cache
SSLStaplingStandardCacheTimeout 3600

#   Seconds before invalid OCSP responses are expired from the cache
SSLStaplingErrorCacheTimeout 600

From memory neither of these were on my default but I don't know what 
impact that would have on crypto filehandle usage.


Mike

Re: Fwd: NetBSD 9.0 randomly boots

[Mike Pumford]

On 21/02/2020 18:10, Maxime Villard wrote:

Le 21/02/2020 à 10:57, BERTRAND Joël a écrit :

Maxime Villard a écrit :

Hi,

1) How much ram does your system have?


16 GB


2) If you add "#define NO_X86_ASLR" at the top of
sys/arch/x86/x86/pmap.c, does
    the system boot fine?


I cannot try. Maybe the next week.


Actually, you don't need to try this; I had a sudden doubt yesterday, but
in the end it is fine and there is no problem.


I have tried to reboot this server and I cannot obtain panic anymore
(?). But kernel randomly enters in loop :

[ 1.004775] pciide0: primary channel configured to native-PCI mode
[ 1.004775] pciide0: using ioapic0 pin 18 for native-PCI interrupt
[ 1.004775] atabus2 at pciide0 channel 0
[ 1.004775] pciide0: secondary channel configured to native-PCI mode
[ 1.004775] atabus3 at pciide0 channel 1
[ 1.004775] i915drmkms0 at pci0 dev 2 function 0: vendor 8086
product 0412 (rev. 0x06)
[ 1.004775] hdaudio0 at pci0 dev 3 function 0: HD Audio Controller
[ 1.004775] hdaudio0: interrupting at msi1 vec 0
[ 1.004775] hdaudio0: autoconfiguration error: unsol: codec id 0x01
not valid
[ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout
[ 1.004775] hdaudio0: autoconfiguration error: RIRB timeout
[ 1.004775] unknown at hdaudio0 not configured
I see that as well on my 9.0 system fairly regularly. For me it doesn't 
panic very often and usually makes it out of the loop and boots. I can 
reproduce quite easily and I'm in a position to add debug and reboot the 
machine in question to reproduce if someone guides me on where it needs 
to go. :)


Mike

Re: Problems with C++ compiler on 9.0_RC2

[Mike Pumford]

On 2020-02-10 12:46, Marc Baudoin wrote:

Martin Husemann  écrit :

On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote:



lrwxr-xr-x  1 martin  wheel  12 Jan 31 13:19 
./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h
-rwxr-xr-x  1 martin  wheel   0 Jan 31 13:19 
./updated/usr/include/g++/bits/gthr-default.h*


Indeed, I have an empty (executable)
/usr/include/g++/bits/gthr-default.h regular file.  Replacing it
with a symbolic link to gthr-posix.h seems to work (at least your
previous example compiles now).


Sounds like a bsdtar bug :-(  which also explains why it did not happen
for your beta updates.


Then it would be nice to have it fixed before 9.0.


Is /usr/bin/tar bsdtar on 9.0?

Reason I'm asking is that I'm able to compile c++ quite happily in 
chroot environments created by un-tarring all the sets into the chroot. 
using tar zpxf . So it could be a sysinst upgrade bug.


Mike

Re: Problems with C++ compiler on 9.0_RC2

[Mike Pumford]

On 06/02/2020 23:30, Mike Pumford wrote:

I'm not building 9.0-RC packages on i386 yet but I can say that on amd64 
with 9.0 pkgsrc current from 02 Feb 0710am UTC and 9.0RC1 01 Feb 0745 
UTC that cmake certainly works. These are builds in a chroot so they are 
guaranteed to have a totally clean tree to start with. I've just kicked 
off some fresh 9.0RC system builds for i386 and amd64 and I'll follow 
that with a pkgsrc-current run and see if I can reproduce.


Okay. My last build was a RC2 userland with an RC1 kernel from a week 
ago. I'll upgrade and go straight to the pkgsrc builds ;)


Mike

Re: Problems with C++ compiler on 9.0_RC2

[Mike Pumford]

On 06/02/2020 11:40, Manuel Bouyer wrote:

On Thu, Feb 06, 2020 at 12:13:31PM +0100, Marc Baudoin wrote:

[...]
I can't because I gave up on C++ some 20 years ago.  Anyway,
trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler
fails every time for me as indicated in my previous message.

It could also be a pthreads problem.  But it's definitely linked
to 9.0_RC2 as I didn't have it with 8.1.


I guess it's from pkgsrc-current ?
I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did build
fine.

I'm not building 9.0-RC packages on i386 yet but I can say that on amd64 
with 9.0 pkgsrc current from 02 Feb 0710am UTC and 9.0RC1 01 Feb 0745 
UTC that cmake certainly works. These are builds in a chroot so they are 
guaranteed to have a totally clean tree to start with. I've just kicked 
off some fresh 9.0RC system builds for i386 and amd64 and I'll follow 
that with a pkgsrc-current run and see if I can reproduce.


Mike

Re: Device timeout reading fsbn ...

[Mike Pumford]

On 01/10/2019 14:36, Thomas Mueller wrote:


Do you know when (what version) NCQ was introduced to NetBSD?  Was it before or 
after 7.99.1?

It went in after NetBSD 8.x was branched so I'd guess it would be 
somewhere in the 8.99.xx versions. It is in the 9.0_BETA branch as well.



What is atatctl?  "which atatctl" shows nothing.  Is atatctl part of 
smartmontools?

I don't have smartmontools installed but could run it from the System Rescue CD 
or build in NetBSD (or FreeBSD or Linux?) on the Hitachi hard drive.

Firmware or driver bug could explain why the Western Digital Green hard drive 
might be adversely affected but not all other hard drives.

I believe Western Digital discontinued the Green hard drives because of 
technical or performance problems.

The fact that the drives were deliberately designed to spin themselves 
down behind the back of the operating system and ATA driver meaning that 
the next time the OS tried to do an IO the operation would timeout and 
have to be retried after the disk had spun back up. This tended to 
trigger the type of fsbn errors you are seeing.


All the extra spin up/spin down cycles played havoc with performance and 
I think also took its toll on the drive electronics. The whole idea was 
fairly flawed as spinning up a drive uses more power than at any other 
time in drive operation so doing it more often costs power unless you 
are confident that the drive can be down long enough to offset that usage.


I thought they did finally produce a version of the firmware where you 
could at least turn that ridiculous behaviour off but I've no idea where 
you can find it. The other way to avoid it is to ensure the OS does a 
disk operation often enough to inhibit the spindown.


Mike

Re: named limits

[Mike Pumford]

On 24/07/2019 12:24, Manuel Bouyer wrote:


Maybe:
start_precmd="set_limits"
set_limits()
{
 ulimit -s 131072
 named_precmd
}

Or use the daemon class in login.conf if you are comfortable with the 
limits being raised for all things started by etc/rc.d scripts.


Mike

Re: sudden appearance of timekeeping problems with netbsd-8 just after 8.1

[Mike Pumford]

On 19/06/2019 14:10, Greg Troxel wrote:

Patrick Welche  writes:


On Tue, Jun 18, 2019 at 04:56:33PM -, Michael van Elst wrote:

g...@lexort.com (Greg Troxel) writes:


  -timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
  +timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000



  -timecounter: Timecounter "TSC" frequency 2800071320 Hz quality 3000
  +timecounter: Timecounter "TSC" frequency 3920113160 Hz quality 3000
THIS is the problem. The kernel has mis-identified your TSC frequency 
massively somehow. You have a 2.8GHz process which means the invariant 
TSC should be running at 2.8GHZ. There is a capability bit for invariant 
TSC and if your processor doesn't have that capability bit set NetBSD 
sets the TSC quality to a very low number (might even be negative).



which if accurate gives us a small window for bisecting.


Bad news is I've seen this come and go since NetBSD 6 on i386 :(

I will try the older kernel, and then see if I can search.  I wonder if
somehow with different code the cpu/tsc is being configured so that tsc
doesn't do what it used to.

Is anyone else seeing this problem?

I've seen it come and go with the SAME kernel on laptop hardware which 
has a known to be invariant TSC. I think NetBSD might be assuming that 
the CPU is running at a particular speed to calculate the frequency so 
if your BIOS starts the CPU at a lower speed (e.g laptop on battery) you 
can get wild results.


I didn't use BSD on the machine where it happened very often so I went 
with the sysctl workround and never really chased it. Sorry. :(


Mike

Re: amd64 SBCs on which NetBSD would run ?

[Mike Pumford]

On 07/05/2019 13:23, David Brownlee wrote:

On Sat, 4 May 2019 at 18:16, Mike Pumford  wrote:


On 04/05/2019 15:30, Mayuresh wrote:

On Sat, May 04, 2019 at 05:49:58PM +0800, Travis Paul wrote:

You mentioned that you were looking for an amd64 board.  Have you looked
at the PCEngines APU2 boards[1]? I have not personally tried them but
perhaps they fit your needs.



Thanks. Looks interesting though I could not find A. international
availability / shipping B. Whether NetBSD would run on it.


NetBSD 8 runs nicely on them and as far as I can tell everything is
supported. No reason why current wouldn't work either although I've not
actually booted it.


Last I checked I don't think the front LEDs were supported, and I
can't confirm the onboard mSSD (as I have a few running on SD cards as
drop in replacements for the older PCEngines boards).

Just installed an mSATA SSD in mine which was my plan all along. I'd 
been temporarily booting of an SD card while experimenting.


Excert from dmesg:
NetBSD  8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Sat Apr 13 
09:22:12 BST 2019   amd64


ahcisata0 at pci0 dev 17 function 0: vendor 1022 product 7800 (rev. 0x40)
ahcisata0: interrupting at ioapic0 pin 19
ahcisata0: 64-bit DMA
ahcisata0: AHCI revision 1.30, 2 ports, 32 slots, CAP 
0xf733ff01

atabus0 at ahcisata0 channel 0
atabus1 at ahcisata0 channel 1
wd0 at atabus0 drive 0
wd0: 
wd0: drive supports 1-sector PIO transfers, LBA48 addressing
wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 
(Ultra/133) (using DMA)


Write speed is about 150MB/s, read speed is about 250MB/s

These are not as fast as the claimed performance numbers for the SSD but 
they are good enough for me. :)


Kernel build date reflects when the 8-stable source was pulled from CVS.

For comparison a net6501 using 7.2-STABLE gets about 100MB/s read and a 
sad 20MB/s write out of the following:


ahcisata0 at pci2 dev 6 function 0: vendor 0x8086 product 0x880b (rev. 0x02)
ahcisata0: interrupting at ioapic0 pin 17
ahcisata0: AHCI revision 1.10, 2 ports, 32 slots, CAP 
0x6f26ff81

atabus0 at ahcisata0 channel 0
atabus1 at ahcisata0 channel 1
wd0 at atabus0 drive 0
wd0: 
wd0: drive supports 1-sector PIO transfers, LBA48 addressing
wd0: 232 GB, 484521 cyl, 16 head, 63 sec, 512 bytes/sect x 488397168 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 
(Ultra/133) (using DMA)


The net6501 has really bad ATA write performance. No more than 20MB/s 
under any OS even on disks capable of far more. This was one of my 
motivating factors for changing as it makes running things like rrdtool 
really bad when there is a lot of data to update to disk.


Mike

Re: why 2 mails every time?

[Mike Pumford]

On 22/04/2019 06:11, Mayuresh Kathe wrote:

why do i get 2 emails every time there's a reply to any email by me or
to me? earlier i thought it was my mail client (mailx) which was doing
something crazy, but it isn't so, a simply reply to netbsd-users goes
out and sends me 2 copies of that same mail. like clock-work.

Because when people hit reply all the default behaviour in most clients 
is to send to both the author and the mailing list. So one is directly 
sent to you and the second copy then comes from the list.


It can be useful if you want to cc someone not on the list but if I'm 
confident the user is on the list I tend to edit out the personal 
address (as I've done with this message. :) ).


If check the full mail headers you will see that one hasn't gone via the 
NetBSD servers.


Mike

Re: The state of SAS

[Mike Pumford]

On 11/03/2019 15:11, Staffan Thomén wrote:
Flashing sounds dangerous, and I expect I'd need at least a second card 
to get the existing data off my RAID sets unless there are firmwares 
that do both RAID and passthru.


Yes you would lose access to the raid sets managed by the card and would 
have to use raidframe and software raid to get the raid behaviour back 
which would involve reconstructing the filesystems from scratch. If you 
are getting a second card it might be easier to just use that for the 
tape drive and leave the existing working card alone. I also seem to 
recall that there was a way to unbrick a card if something goes wrong 
but my memory could be faulty. Its easy to be blase about this sort of 
thing when the cards you are potentially bricking can be fixed by your 
client if something goes wrong.


Does LSI provide official images or is it a question of someone grabbing 
firmware images of another card that just happens to work?


Last time I looked (which was about 12 months ago) LSI did offer firmwre 
downloads from their website. Its entirely possible that a newer raid 
firmware might allow passthrough of the tape drive so that's also worth 
considering as well. Ultimately with the LSI cards device discovery is 
entirely in the hands of the card firmware (which it then passes to the OS).


Mike

Re: The state of SAS

[Mike Pumford]

Lets try that again with the quoting done right :)


On 09/03/2019 23:57, Mike Pumford wrote:



On 09/03/2019 22:57, Staffan Thomén wrote:

Hello list
The machine has a SuperMicro-branded LSI MegaRAID 2108 card and it 
works fine with the mfi driver, although I don't seem to have any way 
of configuring it from a running system (bioctl can list the volumes 
and that's about it) which is a bit of a drag.




Configuration is probably done through the BIOS interface. I've always
used the cards in non-RAID mode so I'm not really sure.

I also recently got a SAS tape drive, and connected it to the system 
and nothing happened. This might of course be because either a) the 
raid controller card does not support tape drives or b) they have to 
be configured and the card bios does not do it automatically.




Its possible a card in RAID mode can't handle a stand alone device.
Never had access to a SAS tape drive so thats outside my area of knowledge.


My questions then are;

How does SAS really work (in NetBSD); specifically tape drives? Is it 
completely transport agnostic and st(4) will just attach?




SAS should be fully hotplug aware so the appropriate sd/st devices
should come and go as you plug and unplug them.



Can I scan the scsibus and expect things Just Work like with SCSI?

Should be no need for scans the devices should just appear as they are 
plugged in. It certainly worked that way on NetBSD when I did some 
testing with a SAS disk enclosure a while back.



What about with a non-raid HBA?

The LSI raid HBAs can usually be flashed with non-RAID firmware if you 
want to use them in that mode. I've not yet come across any generation 
of LSI card that this can't be done up to and including the current SAS3 
chips. Firmware is typically flashed with lsiutil. Not sure if that runs 
on NetBSD but it certainly does on linux so a quick boot off a live 
filesystem linux CD should let you experiment with that. lsiutil also 
provides other diagnostics like bus topology which might help work out 
why your tape drive isn't working.


Mike