Re: Firefox with webcam

[maya]

On Mon, Mar 11, 2024 at 10:15:25AM +0100, Hauke Fath (SPG) wrote:
> Hi,
> 
> has anybody had any recent success in using a webcam with Firefox?
> 
> Sites like  claim to detect the webcam (it's a
> logitech whatzit, attached as uvideo0), but are missing access permissions.
> 
> Firefox (123.0.1 here), OTOH, never asks for permissions; it does not log
> any related errors, either.

fixed with firefox 123.0.1nb1

For future reference to myself: when debugging firefox, I keep
forgetting it has ample logging and spits out the occasional function
name giving you pointers for where to start reading the code. You can
do this with either the MOZ_LOG environment variable or about:logging
page.

firefox's ktrace, meanwhile, is an endless stream of queries getting
the current time of day and polling.

Re: Firefox with webcam

[maya]

On Mon, Mar 11, 2024 at 10:15:25AM +0100, Hauke Fath (SPG) wrote:
> Hi,
> 
> has anybody had any recent success in using a webcam with Firefox?
> 
> Sites like  claim to detect the webcam (it's a
> logitech whatzit, attached as uvideo0), but are missing access permissions.
> 
> Firefox (123.0.1 here), OTOH, never asks for permissions; it does not log
> any related errors, either.
> 
> Cheerio,
> Hauke
> 
> -- 
>  The ASCII Ribbon CampaignHauke Fath
> () No HTML/RTF in email   Institut für Nachrichtentechnik
> /\ No Word docs in email TU Darmstadt
>  Respect for open standards  Ruf +49-6151-16-21344


I updated my firefox and can say:
firefox 121.0 - worked fine with my webcam
firefox 123.0.1 - failed with my webcam

seems like it's a recent regression. I might have a look at it too...

Re: amdgpu kernel module

[maya]

This requires the latest current

Build source with /etc/mk.conf containing:
MKAMDGPUFIRMWARE=yes

Adding the line:
SUBDIR+= amdgpu

to sys/modules/Makefile

Unpack gpu firmware and modules in / (or all sets)

and then edit the first entry in /boot.cfg:
Change:
-boot netbsd
+load amdgpu; boot netbsd

No need to make any changes to the kernel.

On Mon, Jul 25, 2022 at 01:58:59PM +0300, Riza Dindir wrote:
> Hello all,
> 
> I have tried to enable the amdgpu module/driver in the kernel
> configuration. Disabling the radeon driver module. The kernel did not
> recognize the graphics devices on my laptop.
> 
> How can we use the amdgpu kernel driver?
> 
> Does the amdgpu kernel driver support these graphics drivers with pci ids
> 0x1002 0x1309 (Kaveri [Radeon R6/R7 Graphics]) and 0x1002 0x6604 (Opal XT
> [Radeon R7
> M265/M365X/M465])?
> 
> In the driver source it lists these devices on the net. But my sources
> (have version 9.2) does list the 0x1309 device but not the 0x6604 device?
> 
> Does anyone know the status if the amdgpu kernel driver?
> 
> Kind regards
> Riza
> 
> On Fri, Jul 22, 2022, 17:58 Riza Dindir  wrote:
> 
> > Hello All,
> >
> > There is also an amdgpu kernel driver in the netbsd kernel source.
> > What is the status of that driver?
> >
> > My laptop has graphics devices with pci ids 0x1002 0x1309 (Kaveri
> > [Radeon R6/R7 Graphics]) and 0x1002 0x6604 (Opal XT [Radeon R7
> > M265/M365X/M465]). Would this driver *amdgpu) support both these
> > cards?
> >
> > Kind regards,
> > Riza
> >

Re: Question about nouveau, and also about bell/alert

[maya]

On Sat, Dec 04, 2021 at 11:44:03PM -0800, Andras Farkas wrote:
> Hello!
> 
> Is it normal for nouveau not to work with an Nvidia GTX 970?  I
> unfortunately have an Nvidia video card.
> I have hardware reports, in case more details are needed:
> https://bsd-hardware.info/?probe=14907c62f1
> https://bsd-hardware.info/?probe=8f18868bb4
> https://linux-hardware.org/?probe=7a7abd7af2

I would expect this to work with new drm code that is coming real soon
(once we resolve a few issues with ARM DRM drivers).

If you try it now you will need to find firmware yourself, and slightly
patch the code.

git clone https://github.com/riastradh/netbsd-src -b re4drm56
Delete these two lines:
https://github.com/riastradh/netbsd-src/blob/re4drm56/sys/external/bsd/drm2/nouveau/nouveau_pci.c#L131-L132


And install your own firmware from linux-firmware:

git clone 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
mv /libdata/firmware/nouveau/nvidia /libdata/firmware/nouveau/nvidia.old
cp -pR linux-firmware/nvidia /libdata/firmware/nouveau/

(Note this runs a -current kernel, but you can update just the kernel
and run the same userland)

Re: is there a NOACPI GENERIC kernel for NetBSD-9.2_STABLE?

[maya]

Drop to boot prompt and type "boot -2". The -2 flag disables ACPI and
doesn't require a new build.
(A kernel without ACPI would require all ACPI code everywhere to be
conditional, and it might be a non-trivial effort to get there).

Re: OpenGL issues - glxgears failure or segfault

[maya]

Hi Riccardo,

My guess for this failure is that your GPU hangs too often, which
results in refusing GPU workloads.

probably execbuffer2 ioctl fails with EIO ->
probably i915_gem_validate_context fails with
hs = >hang_stats;
if (hs->banned) {
DRM_DEBUG("Context %u tried to submit while banned\n", ctx_id);
return ERR_PTR(-EIO);
}

This happens when "context hanging too fast" or "gpu hanging too fast".

It's worth investigating why this is happening, but note that we are
currently in the middle of updating the DRM code. I wonder if the new
code already resolves your problem.

You can find the branch for the update here:
https://github.com/riastradh/netbsd-src/tree/reredrm56
If you'd like to give it a shot.


On Tue, Aug 24, 2021 at 07:23:17PM +0200, Riccardo Mottola wrote:
> Hi,
> 
> I traced down my WebGL problems to core OpenGL issues.
> If I run glxgears I get bad results.
> The display does not show rotating gears but either two images vibrating
> between (strobo-effect like) or even just one frozen image.
> 
> Sometimes I get a crash, like this:
> $ glxgears
> Running synchronized to the vertical refresh.  The framerate should be
> approximately the same as the monitor refresh rate.
> i965: Failed to submit batchbuffer: Input/output error
...

> [  8185.721137] kern error: 
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start]
> *ERROR* Potential atomic update failure on pipe A: -35
> [ 24956.434454] kern error: 
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start]
> *ERROR* Potential atomic update failure on pipe A: -35
> [ 25038.667770] kern error: 
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start]
> *ERROR* Potential atomic update failure on pipe A: -35
> [ 25866.454467] kern error: 
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c:132)intel_pipe_update_start]
> *ERROR* Potential atomic update failure on pipe A: -35
> 
> now, If I rerun glxgears, I get a segfault:
> $ glxgears
> Running synchronized to the vertical refresh.  The framerate should be
> approximately the same as the monitor refresh rate.
> [1]   Segmentation fault (core dumped) glxgears
> 
> Thread 1 "" received signal SIGSEGV, Segmentation fault.
> 0x717487fe5850 in brw_workaround_depthstencil_alignment () from
> /usr/X11R7/lib/modules/dri/i965_dri.so
> (gdb) bt
> #0  0x717487fe5850 in brw_workaround_depthstencil_alignment () from
> /usr/X11R7/lib/modules/dri/i965_dri.so
> #1  0x717487fa34d5 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so
> #2  0x00017f001f8a in draw ()
> #3  0x00017f00353d in main ()
> 
> doesn't look nice!!
> 
> Riccardo
> 
> 

Re: epoll

[maya]

On Mon, Jan 25, 2021 at 04:52:04PM +0100, r0ller wrote:
> Hi All,
> 
> I tried to wrap in the linux syscalls an epoll implementation that seems to 
> support NetBSD-9.1
> 
> https://github.com/jiixyj/epoll-shim
> 
> but as I've never done such a thing  before, it failed of course.
> 
> First, I copied its source in the external/mit/epoll-shim directory and tried 
> to include epoll.h via absolute path in linux_misc.c to support the epoll 
> calls. This is definitely not the right way to do as when running build.sh it 
> failed to find stdint.h (used in epoll.h) on the first try.
> 
> I tried to find some docs about pulling in external sources but I haven't 
> found anything that would describe how to do it.
> 
> Can anyone give me any hint on this?

pkgsrc-wip/libepoll-shim

Re: Build problem with NetBSD 9_Stable amd64 (tools/nbmakestrs?)

[maya]

On Mon, Dec 14, 2020 at 03:14:38PM -, ya...@sdf.org wrote:
> Since about last Friday (Dec.11) I am encountering an error building the
> distribution for amd64 NetBSD 9_Stable branch from latest sources.
> 
> Tracking stable branch via:
> cvs -q up -rnetbsd-9 -PAd src
> 
> Building tools itself with:
> ./build.sh -O ../obj -T ../tools -u tools
> completes without error, which seems confusing...
> 
> I had previously built successfully, first had the error when trying to
> update sources, then started with clean tools and obj directory, but have
> same error.
> 
> Using build.sh with command:
> ./build.sh -x -O ../obj -T ../tools -u distribution
> 
> [stuff that seems normal deleted]
> #create  makestrs/.depend
> rm -f .depend
> /usr/src/../tools/bin/nbhost-mkdep -s .lo\ .ln\ .d -d -f .depend makestrs.d
> /usr/src/../tools/bin/nbhost-mkdep: Ignoring makestrs.d
> #  link  makestrs/nbmakestrs
> cc -O -I/usr/src/../tools/include/compat -I/usr/src/tools/compat
> -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I.   -o nbmakestrs
> makestrs.lo -L/usr/src/../tools/lib -lnbcompat -lrt -lz
> cc: error: makestrs.lo: No such file or directory

remove -x or have xsrc

Re: sponsor NetBSD for 2020 https://github.com/sponsors/NetBSD

[maya]

On Tue, Nov 10, 2020 at 06:59:32PM +, Sad Clouds wrote:
> On Tue, 10 Nov 2020 18:25:09 +
> m...@netbsd.org wrote:
> 
> > As for sun4v, I believe Palle is doing work on this sometimes.
> 
> Yes, I've seen from the posts on sparc64 mailing list that some people
> are working on it, but often developers have other commitments and bills
> to pay, so the progress can be very slow. Paying those developers to
> work part or full time on various features would 1) help them pay the
> bills, and 2) move features forward quicker.
> 
> I suspect NetBSD users would be more willing to sponsor the features
> that they can directly benefit from. In fact, this mode of software
> development (pay per feature) should be encouraged. I appreciate that
> NetBSD is a non-profit organization, but relying on other people to
> donate their development time for free is not always the best approach,
> i.e. feature development can drag on indefinitely.

This is what I'm doing:
http://mail-index.netbsd.org/tech-kern/2020/11/02/msg026882.html
http://mail-index.netbsd.org/tech-pkg/2020/05/19/msg023185.html

If you are interested on doing the same with sun4v, I think a good first
step is to write completion criteria. With GNOME3, I preferred to write
the coherent "GDM works" rather than the more nebulous "GNOME3" because
it's not clear what the list of GNOME3 programs is.

Also, I strongly recommend offering a bounty for smaller units of work,
even when you want a bigger one. It avoids problems with people dividing
the work.

If you would like this to be curated "officially" we can create a wiki
page to coordinate the most up to date version of this.

Re: sponsor NetBSD for 2020 https://github.com/sponsors/NetBSD

[maya]

On Tue, Nov 10, 2020 at 04:02:55PM +, Sad Clouds wrote:
> On Tue, 10 Nov 2020 08:32:29 -0500
> matthew sporleder  wrote:
> 
> > Indeed -- casting a wide net is in our interest.  I hope you are able
> > to use one of our many potential donation offerings -- paypal, stripe,
> > amazon smile, github sponsorship.. any I am missing?
> 
> I think what may be missing is sponsorship for specific features.
> NetBSD foundation normally decide where to spend the resources. It may
> be used for worthwhile projects, but for different people some features
> are more tangible than others.
> 
> For example, I'd be interested in sponsoring NetBSD on sun4v
> architecture with support for LDOMs. OpenBSD have done a lot of work in
> this area and there may be a lot of potential for porting their code.
> Some of their developers could be interested in doing it if NetBSD
> agreed a full-time paid project.
> 
> 1. Identify the scope and cost.
> 2. If cost is feasible, setup project sponsorship page.
> 3. If enough money is raised over a set period of time, project goes
> ahead, otherwise money is returned to the sponsors.
> 4. NetBSD oversee the delivery and quality of the project.
> 
> This approach is more targeted and allows the sponsors to have a say in
> how their money is spent. If nobody is interested in a project and not
> enough money is raised, then - c'est la vie...

The usual way that TNF funding of projects work is that a developer will
come to TNF with a proposal for the project to fund their work.
Actively seeking out developers when nobody has come forward is a
challenge, because the sums of money are usually too little to have
consulting firms interested.

In the absence of any framework, I've shamelessly posted that I am
offering a bounty for some netbsd/pkgsrc related work on
tech-pkg/tech-kern and it was successful (IMO). We can write down all
the names & offers if there are too many, but this is not the case now.

As for sun4v, I believe Palle is doing work on this sometimes.

Re: netbsd 9 upgrade experience

[maya]

On Tue, Jun 23, 2020 at 03:10:19PM +0200, Hauke Fath wrote:
> On Sat, 20 Jun 2020 20:19:08 + (GMT), r0ller wrote:
> > 3) xorg still crashes when it gets a little stress as it did in 8.1 
> > with i915drmkms enabled tough I hoped that upgrading to 9 will solve 
> > it. See xdm.log and Xorg.0.log attached.
> 
> You might be better off with wip/xf86-video-intel-git - it fixed 
> similar problems for me on a HP EliteBook.
> 
> But I don't know if you can run a pkgsrc X server alongside base X11, 
> or if you need to build all things X from pkgsrc.

Just installing it as a package won't work out. But base Xorg isn't
using a release of xf86-video-intel either, and is using some git
snapshot. We can update it if it helps.

Re: distributed file system

[maya]

On Tue, May 19, 2020 at 11:43:46AM +0300, Dima Veselov wrote:
> Greetings.
> 
> I want to utilize unused slots in both NetBSD and Linux servers
> to fill them with old terabyte disks to build big, robust and 
> redundant data storage natively accessible mostly on NetBSD.
> 
> Is there any experience of using dsitributed file systems on
> NetBSD as a server and as a client in production? Maybe any
> thoughts on what will or will not work?

Never tried to use it, but the first filesystem I'd try in this position
would be pkgsrc/filesystems/glusterfs

Seems like manu@ has been doing a lot of work towards it and it has had
netbsd support for a while.

Re: System slowness and graphics-card

[maya]

On Tue, Apr 07, 2020 at 10:11:24AM -0400, 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
>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?
> Is there a way to fix this; or is it a matter of having support for my 
> chip-set?
> 
> I find this interesting to know.

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.

Re: Generating static htmls with interactive plots

[maya]

On Mon, Apr 06, 2020 at 03:00:15PM +0530, Mayuresh 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.
> 
> I hear nodejs has a collection of packages for this. But not sure about
> ability to generate a static html.
> 
> Came across python plotly and it seems to have the ability to generate
> static htmls the way I want.
> 
> Just wanted to know if there are more options to explore if someone has
> tried in similar situations.
> 
> Mayuresh

To generate SVG:

> cat infile
1,1
2,4
4,16
5,25

gnuplot> set datafile separator ','
gnuplot> set term svg
gnuplot> set output 'out.svg'
gnuplot> plot 'infile' using 1:2 with lines, ''

However I don't know if it's even possible to make it zoom "correctly"
with just SVG. Certainly the default from gnuplot does not do this.

So after experimenting I think d3.js might be a better choice...

Re: X broken after upgrade to 9.0

[maya]

On Tue, Mar 03, 2020 at 10:15:06PM +0100, Jörn Clausen wrote:
> Hi!
> 
> I just upgraded my NetBSD desktop machine (ASRock mainboard with
> Celeron J1900 CPU) from 8.1/adm64 to 9.0. It ran X11 without any
> problems before, but now I have glitches. Lines of pixels are not
> updated correctly, as if parts of the screen are constantly XORed.
> It's hard to describe...
> 
> The onboard graphics seems to be detected correctly:
> 
> Mar  3 21:40:51 itix /netbsd: [   7.7395065] i915drmkms0: interrupting
> at ioapic0 pin 16 (i915drmkms0)
> Mar  3 21:40:51 itix /netbsd: [   7.8195601] intelfb0 at i915drmkms0
> Mar  3 21:40:51 itix /netbsd: [   7.8295675] intelfb0: framebuffer at
> 0xa200636dc000, size 1280x1024, depth 32, stride 5120
> 
> A little bit later in /var/log/messages, this pops up:
> 
> Mar  3 21:39:58 itix /netbsd: [  34.0453419] kern info: [drm] stuck on
> blitter ring
> Mar  3 21:39:58 itix /netbsd: [  34.0453419] kern info: [drm] GPU
> HANG: ecode 7:2:0x96fbfff7, reason: Ring hung, action: reset
> Mar  3 21:39:58 itix /netbsd: [  34.0453419] kern error:
> [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c:3196)i915_context_is_banned]
> *ERROR* gpu hanging too fast, banning!
> Mar  3 21:39:58 itix /netbsd: [  34.0653569] 000125a8 :  0230
> Mar  3 21:39:58 itix /netbsd: [  34.0653569] 000125ac :  
> Mar  3 21:39:58 itix /netbsd: [  34.0653569] 000125b0 :  0220
> Mar  3 21:39:58 itix /netbsd: [  34.0653569] 000125b4 :  
> Mar  3 21:39:58 itix /netbsd: [  34.0653569] 000125b8 :  026e
> 
> I also saw something about "i915 GPU crashed, file a bug report" for a
> brief moment in the console window of XDM, just before logging in. I
> can't find it in any of the files in /var/log/, so I am not even sure
> about the full text or who I am supposed to contact.
> 
> Any idea how to fix this? Should I give modular X from pkgsrc a try?
> 
> -- 
> Joern Clausen
> https://www.oe-files.de/photography/

One way to workaround some of these issues is to force the less
demanding uxa accel method for i915, modesetting driver, or wsfb driver.
e.g. an xorg.conf like this:

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "AccelMethod" "uxa"
EndSection

Re: pkgsrc binary packages security with pkgin

[maya]

On Sat, Jan 25, 2020 at 01:34:34AM +0100, yarl-bau...@mailoo.org wrote:
> Hello,
> 
> May I ask how is safe the use pkgsrc binary packages. For example using 
> pkgin. Does libfetch is doing fine with https? Any thoughts?
> 
> Is the authenticity and integrity of packages installed this way is 
> guaranteed assuming no bugs in software involved?

No.

> 
> Is it safer to compile by yourself?

Yes.

This is a very unfortunate case.

Re: Xorg from Base or pkgsrc - recommendations?

[maya]

On Mon, Jan 06, 2020 at 06:46:58PM +, nia wrote:
> On Sat, Jan 04, 2020 at 04:20:42PM +, m...@netbsd.org wrote:
> > On Fri, Jan 03, 2020 at 09:58:29PM +0100, Matthias Petermann wrote:
> > > The pkgsrc version led to segmentation faults on my Thinkpad X220 with 
> > > Intel
> > > graphics, while the version from NetBSD worked without any problems.
> > 
> > I think that xf86-video-intel on pkgsrc needs to be updated to the
> > latest git. Intel stopped doing releases for it.
> > 
> > Additionally it has some undefined behaviour that clang strongly
> > disapproves of, we are patching it in base.
> > 
> 
> Isn't pkgsrc x using the modesetting driver on x86 and arm now?
> I copied the patches from xsrc that cause it to be matched.

The xsrc patches should still prefer intel over modesetting.
It was a good choice since GLAMOR doesn't work on base xsrc, so
modesetting is dramatically worse. I suspect it works better with pkgsrc
xorg.

I'm not sure. The Intel people said the modesetting driver might be the
way to go. If GLAMOR works you can remove the intel driver from the
build to get the same effect.

Re: Xorg from Base or pkgsrc - recommendations?

[maya]

On Fri, Jan 03, 2020 at 09:58:29PM +0100, Matthias Petermann wrote:
> The pkgsrc version led to segmentation faults on my Thinkpad X220 with Intel
> graphics, while the version from NetBSD worked without any problems.

I think that xf86-video-intel on pkgsrc needs to be updated to the
latest git. Intel stopped doing releases for it.

Additionally it has some undefined behaviour that clang strongly
disapproves of, we are patching it in base.

Re: How to determine supported languages in a particular installation of gcc?

[maya]

On Mon, Sep 16, 2019 at 10:25:37AM +, m...@netbsd.org wrote:
> I would only count on base GCC for C and C++.
> It should do Objective-C, but as someone who has never written that, I
> couldn't get it to not-crash.

^ Normally, enable-languages is fine. NetBSD base GCC is built in an
unusual way, though.

Re: How to determine supported languages in a particular installation of gcc?

[maya]

I would only count on base GCC for C and C++.
It should do Objective-C, but as someone who has never written that, I
couldn't get it to not-crash.

regular pkgsrc GCC has most of the other languages:
Fortran: default enabled
Ada: separate package (gcc5-aux), as it requires binary bootstrap
Java: older GCC
Go: default disabled in pkgsrc GCC, as an option
D: only available since GCC 9, and I only did amd64, might need to
separately work on i386. GCC 9 is not a package yet, I put a snapshot in
wip at the time though.

Re: State of ZFS in 9.0_BETA

[maya]

On Sat, Aug 10, 2019 at 09:12:23PM +0100, Chavdar Ivanov wrote:
> I was thinking that if ZFS were in the kernel, it might be easier to
> get ZFS root.


You don't need to build ZFS into the kernel to boot it as a root mount
(same for FFS). The code to load modules from the bootloader already
exists. You do, however, need to write/port the functionality to
do a root mount, and teach the bootloader to read ZFS to find the
kernel (unless you use EFI boot, then maybe put the kernel on the FAT
partition).

Re: Finding Raspberry Pi images on the site

[maya]

On Wed, Jun 26, 2019 at 10:11:21AM -0400, Greg Troxel wrote:
> Perhaps, but that's solving a problem we are trying to get rid of, which
> is needing different builds for each hardware flavor.

jared's images are applying a different u-boot/vendor firmware to each
image, the netbsd side of things is the same.

Re: Laptop Recommendations for NetBSD?

[maya]

I don't recommend my laptops because I can name the list of things not
working on them (I want to fix them at some point).

I can tell you what is missing in a Dell XPS 9550 but given that I have
graphical acceleration, external monitor and internal wifi, it's an OK
recent laptop for netbsd'ing.

https://dmesgd.nycbug.org/index.cgi?do=view=3729

Re: gcc issues when compiling ArcticFox browser

[maya]

www/firefox has this, I forget what the issue was, but I think it's the same.

.if !empty(MACHINE_PLATFORM:MNetBSD-[0-7]**-*) || \
!empty(MACHINE_PLATFORM:MNetBSD-8.[0-8]*-*)
USE_PKGSRC_GCC_RUNTIME= yes
.endif

Re: Install NetBSD 8.1 : Can not load Radeon DRM properly

[maya]

On Thu, Jun 06, 2019 at 12:51:39PM +0800, JingYuan Chen wrote:
> Hello,
> 
> My laptop's GPU is Radeon (TURKS). When using NetBSD 8.1 amd64 ISO to boot,
> I encounter this kind of problem, radeon_get_bios: Unable to locate a BIOS
> ROM. But it can boot smoothly without UEFI.
> 
> If I followed the steps of installation on UEFI system guide to install it,
> I wonder whether the same problem will be resolved or not.
> 
> Is it necessary to boot with UEFI ?
> 
> Any advice would be appreciated.
> 
> 
> Regards,
> Chingyuan

The last patch in http://gnats.netbsd.org/54147 might be a big help.
Not committed yet, so hard to test it.

UEFI is not necessary for current machines.

Re: How does pulseaudio work?

[maya]

On Fri, May 10, 2019 at 03:42:18PM -0400, Bob Bernstein wrote:
> Epiphany built very nicely from pkgsrc, and in the process built 
> qt5-qtmultimedia, and pulseaudio. However epiphany doesn't seem able 
> to play any audio. I can play wav files just tine from the command 
> prompt using audioplay.
> 
> Clearly I am a few pepperoni short of a pizza. How do I implemnet 
> pulseaudio in its role as audio server? (If that is even the 
> pertinent question to be asking...)
> 
> Thank youse,
> 
> -- 
> What can be asserted without evidence can be 
> dismissed without evidence.
>  Hitchens' Razor



I think you need dbus running.
/usr/pkg/share/examples/rc.d/dbus onestart

Re: t_kcov missing

[maya]

cd src/tests/modules
make distclean USETOOLS=no

It's probably built the objects in this directory already, instead of in
OBJDIR.

Re: RISC-V port ?

[maya]

On Tue, Jan 22, 2019 at 07:26:05PM +, Richard Ibbotson wrote:
> 
> On 22/01/2019 19:20, Chris Hanson wrote:
> > > https://www.youtube.com/watch?v=gQYAS7A2LD0
> > 
> > Can you summarize the points you’re trying to make by referencing these 
> > videos and conference talks for those of us without the time to watch them?
> 
> 
> This probably isn't the right media to submit a 2 to 5 page A4 essay about
> the subject of RISC-V.  Most of us don't have the time to write such things.
> Most of us do have the time to watch TV or a video. That's the way that
> large parts of the population of this planet actually receive their
> information.
> 
> 
> -- 
> Richard

Hi,

I imagine most people hanging around netbsd do know what RISC-V is.
Even going over the list of contributors to RISC-V, you'll find some
familiar names.

NetBSD doesn't have a full RISC-V port yet because it is difficult to
create a new port and takes time, and people might not have the free
time & energy to work on it, or rank other things as more important to
them personally.

zmcgrew is doing a lot of work on it, but it is still not complete. Help
is welcome, of course.

Re: ArcticFox crash on startup (OOM)

[maya]

Make sure you use `paxctl +m 
obj-x86_64-unknown-netbsd8.99.26/dist/bin/arcticfox`
browsers and JITs don't get along with W^X.

(In some exterme circumstances, you might also need paxctl +a)

Re: apm command netbsd 8

[maya]

On Sat, Nov 10, 2018 at 07:22:04AM -0600, Michael Jensen wrote:
> 
> Has the old apm command been removed in NetBSD 8? If not what do I need to
> get it back. Also the apm api is needed for asbatt in pkgsrc can this be
> made to work with newer versions?

envstat gives battery information for ACPI and others. Not sure what
asbatt is.  Is it really APM and not ACPI?

Re: suspend-to-RAM intel-x86 issues and tests

[maya]

On Tue, Oct 09, 2018 at 05:32:57PM +, m...@netbsd.org wrote:
> Invalid TSS (this might be the right one)

It's probably not! it's probably "invalid TSS" :-)

Re: suspend-to-RAM intel-x86 issues and tests

[maya]

On Wed, Sep 26, 2018 at 11:33:49PM +0200, Riccardo Mottola wrote:
> T43 "new": does go to sleep, but does not resume (while stock 8 does).

Better strategy: since we you have a machine that worked at some point,
you should try to bisect it. it's a somewhat tedious process of testing
~13 different kernels, but it is easier to do.

1. do a full clone of the netbsd git mirror:
git clone https://github.com/netbsd/src
git checkout 219a1cc39c1610407f456c7a08a21d6e951cfb1c # netbsd-8 branch

Do a build of this and confirm it works.

git checkout trunk
git bisect start
git bisect bad HEAD # HEAD doesn't work
git bisect good 219a1cc39c1610407f456c7a08a21d6e951cfb1c

Now, you are bisecting, you need to do a clean build of tools and kernel
most of the time.
use ./build.sh ... -O ~/obj tools kernel=GENERIC
and delete ~/obj between attempts.

If a change can suspend, use 'git bisect good'.
If it fails, 'git bisect bad'
If it fails to build, use 'git bisect skip'

Personally my first 2-3 attempts at bisect I confused something and got
to the wrong commit, but when it worked, it really did pinpoint the
problem very efficiently.

Re: suspend-to-RAM intel-x86 issues and tests

[maya]

On Tue, Oct 09, 2018 at 01:12:31AM +0200, Riccardo Mottola wrote:
> yet on sleep it crashes. I was able to catch the error.
> I add that even if it says "flushing disk" at the next reboot, the
> filesystem is dirty.
> 

That's expected: I think we write a bit to the filesystem at mount and
only un-write it on a clean unmount. Flushing to disk is to clear
anything in RAM to disk, but it isn't an unmount (reboot isn't
expected!)

But your filesystem should be unaffected.

Re: suspend-to-RAM intel-x86 issues and tests

[maya]

On Tue, Oct 09, 2018 at 01:12:31AM +0200, Riccardo Mottola wrote:
> acpi0: entering state S3
> flushing disk caches: 16 done
> fatal protection fault in supervisor mode
> trap type 4 code 0 eip 0xc0135ea3 cd 0x8 eflags 0x210046 cr2 0xdac2b0c4
> ilevel 0x8 esp 0xc1210c80
> curlwp 0xc36422c0 pid 658 lid 1 lowest kstack 0xdb8702c0
> panic: trap
> cpu0 Begin traceback...
> vpanic (.) at netbsd:vpanic+0x132
> snprintf() at netbsd:snprintf
> trap_tss() at netbsd:trap_tss
> --- trap via task gate ---
> netbsd: cpu_info_primary:

Hey, useful info!
cpu_info_primary isn't a function though, which is weird.
eip 0xc0135ea3 is also an interesting thing to note and we should search
by hand if it is in a function too

what does
gdb /path/to/netbsd
gdb> disas 0xc0135ea3

say?

osdev wiki says:

Invalid TSS (this might be the right one)

An Invalid TSS exception occurs when an invalid segment selector is referenced 
as part of a task which, or as a result of a control transfer through a gate 
descriptor, which results in an invalid stack-segment reference using an SS 
selector in the TSS.
When the exception occurred before loading the segment selectors from the TSS, 
the saved instruction pointer points to the instruction which caused the 
exception. Otherwise, and this is more common, it points to the first 
instruction in the new task.

Error code: The Invalid TSS exception sets an error code, which is a selector 
index. 

so that says it's expected that the eip won't be useful. I'm currently
trying to see (with my limited x86 clue) what code is touching tss.

does anyone have a better clue how to debug this?

Re: NBSD8.0 Macbook Pro install

[maya]

On Sat, Oct 06, 2018 at 08:26:10PM +, John Halfpenny wrote:
> Hi All
> 
> Found myself installing NetBSD8.0 64bit on a MBP8,1 (Intel i7) and ran 
> into trouble. Apologies if I missed a post on this elsewhere.
> 
> AMD64 uefi USB installer reports uvm_fault and drops me to db{0}>
> 
> CD installation reports piixide0:1:0: lost interrupt and hangs.
> 
> This isn't urgent at all, but if anyone has any ideas what to try I'd 
> appreciate the advice. I took a couple of screenshots for anyone 
> interested:
> 
> https://www.dropbox.com/s/x7nb6pezheb43mm/20181005_224231.jpg?dl=0
> https://www.dropbox.com/s/dko72lz6pnbvzh7/20181005_223718.jpg?dl=0
> 
> Best
> John
> 
> -- 
> j...@sdf.org
> SDF Public Access UNIX System - http://sdf.org

I'm guessing the amount of RAM it detects is wrong, too.
the piixide failure brings up https://gnats.netbsd.org/47592 as a
related bug report.

Re: suspend-to-RAM intel-x86 issues and tests

[maya]

While trying to figure out why my own laptop fails to resume, it was
just rebooting on resume. To pin it down, I wrote down a list of all the
drivers that attach, and try to disable as many of them as possible and
then trying suspend, under the assumption that one of the netbsd drivers
is causing problems.

it was a very long list, I 'userconf disable ...' a lot of stuff, then
boot. it was time consuming but I got it down to one problematic driver
that was fixed.

I should do it again at some point.

In theory, we can also 'drvctl -S hdaudio0; drvctl -R hdaudio0' but
unfortunately my own bug at the time wasn't discoverable in this way.

Re: i915

[maya]

On Sat, Sep 22, 2018 at 11:02:32PM +0200, Cayo Puigdefabregas wrote:
> Hello,
> I have a problem with xorg that I don't found any solution.
> The problem is that I have a i915 card I have a x1 carbon 5º gen.
> When I start netbsd is loaded the module *i915* DRMKMS
> I use the xorg.conf that is created with X -configure.
> In this file exits as driver card "intel"
> everything seems correct, but when I start the X, xorg throws and error
> (EE)
> Fatal server error:
> (EE) no screens found(EE)
> (EE)
> 
> someone has an idea of where to start
> 
> Thanks you
> 
> Cayo

If you are using netbsd-current, it will probably have support, but xorg
needs some workarounds for now:
- Build pkgsrc xorg deleting old packages, setting X11_TYPE=modular,
  build meta-pkg/modular-xorg and start /usr/pkg/bin/startx.
- Get pkgsrc-wip, and build wip/xf86-video-intel-git to replace
  x11/xf86-video-intel.
- Now it will work

Alternatively, for the quickest way for things to work, you can disable
the i915 driver and just use vesa (this is slower, but less work)
- In the bootloader, drop to boot prompt
- type "userconf disable i915drmkms"
- "boot"

we'll try to make sure base xorg, pkgsrc xorg etc. all work, but it won't
be right away.

Re: pkgin repo change

[maya]

On Tue, Sep 18, 2018 at 08:59:55PM -0400, Eric Hawicz wrote:
> On 9/18/2018 4:37 AM, Pedro Pinho wrote:
> > This morning trying to update/upgrade my system I got the following,
> > |~$ sudo pkgin update Password: processing remote summary
> > (http://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/8.0 pkgin:
> > Could not fetch
> > http://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All|
> > Looking closer at the problem, I found that the repo has changed
> > yesterday at 06:25, and the correct URL should now be
> > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0_2018Q2/All/
> > 
> > This is not an issue, as I only had to edit
> > /usr/pkg/etc/pkgin/repositories.conf on my system and everything is good
> > again.
> > I'm new to NetBSD and I'm wondering where/if such changes are usually
> > not announced.
> 
> That sounds to me like a "8.0" symlink was lost.  We have symlinks for
> various other releases, and 8.0 symlinks for other architectures, so I'm
> guessing this is just a mistake.
> I'm cc'ing the pkgsrc releng team, who can probably do something to fix
> this.

now there's
7.1 -> 7.1_2018Q2
7.1.1 -> 7.1
7.1.2 -> 7.1
7.2 -> 7.1
8.0 -> 8.0_2018Q2
for NetBSD/{i386,amd64}.

Hopefully nobody has a script to set it to some weird configuration.

Re: git https issue

[maya]

On Tue, Sep 18, 2018 at 01:19:10PM +0200, Riccardo Mottola wrote:
> Hi Edgar,
> 
> 
> On 08/19/2018 09:28 PM, ed...@pettijohn-web.com wrote:
> > > > Thread 1 received signal SIGILL, Illegal instruction.
> > > > 0xb66f3d50 in gcm_ghash_4bit_mmx () from /usr/lib/libcrypto.so.12
> > > > 
> > > > 
> > > > (gdb) bt
> > > > #0  0xb66f3d50 in gcm_ghash_4bit_mmx () from /usr/lib/libcrypto.so.12
> > > > #1  0x in ?? ()
> > > > 
> > > > very nice:)
> > > > 
> > > > now I don't remember if this CPU has MMX or not...
> > > > cpu0 at mainbus0
> > > > cpu0: Intel 586-class, 232MHz, id 0x581
> > > > cpu0: package 0, core 0, smt 0
> > > > 
> > > > It should though, according 
> > > > to:https://www.thinkwiki.org/wiki/Category:600
> > > > 
> > > > 
> > > > Riccardo
> > > Looks like you found the issue.
> > There was a thread on tech I believe talking about something very similar 
> > not too long ago. Might be worth looking through the archives.
> 
> 
> I took the time to browse through the archives, going back a couple of
> months, but couldn't find anything regarding this.
> 
> I wonder if there is a "solution", but also know exactly what the issue is.
> At first I thought it was using MMX without CPU supporting it, but it is
> not. Then I searched further and found this thread, which I ignored at first
> because I have "genuine intel"
> 
> https://www.mail-archive.com/tech-userlevel@netbsd.org/msg01643.html
> 
> It really looks a crash in the same place and MMX using actually on SSE
> which my cpu (and probably many others) do not have.
> 
> I tried the trick of setting
> 
> export OPENSSL_ia32cap=~0x80
> 
> and it works.
> 
> Reading the discussion it appears to be an issue on how NetBSD builds
> libcrypto and that it has been fixed by a commit by Christos.
> 
> I wonder if I can get a "new" libcrypto binary somehow, e.g. by a test
> build, and replace mine? some update without updating the whole system to
> unstable?

I assume (but not sure) it was backported to netbsd-8, it includes
a small amount of changes since the 8.0 release and will become 8.1.

You can download the builds for netbsd-8 from:
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-8/latest/

Re: Why is TERM=vt100 on the console?

[maya]

On Sat, Sep 15, 2018 at 12:15:55AM +0200, Johnny Billquist wrote:
> And the wording you use make me feel that you are person to is easy to
> dislike. Why are you trying to abuse people and act a jerk?

Fair 'nuff. While I am explicitly disinterested in winning any
popularity contests, I shouldn't have argued in such a disrespectful
way. I assume there's some console correctness he's arguing for.

Sorry, uwe.

Re: Why is TERM=vt100 on the console?

[maya]

On Sat, Sep 15, 2018 at 12:15:55AM +0200, Johnny Billquist wrote:
> On 2018-09-14 22:07, m...@netbsd.org wrote:
> > On Fri, Sep 14, 2018 at 11:08:29AM +, Valery Ushakov wrote:
> > > m...@netbsd.org wrote:
> > > 
> > > > Every time we have this discussion someone ends up saying that yes,
> > > > everything being terrible and not supporting anything modern is a
> > > > great default. they like it that way.
> > > 
> > > /etc/ttys uses wsvt25 on all ttyE* for a long long time.  It only uses
> > > vt100 for console, which may be a serial console, so vt100 is a safe
> > > default there.  If you know you don't use serial console you can edit
> > > 1 (one) line in ttys.  Do you really think this is "terrible"?
> > 
> > etc.sparc64/ttys:console"/usr/libexec/getty suncons"wsvt25 on secure
> > 
> > Why is sparc{,64} exempt from having shitty defaults? because people who
> > use it don't have to ask netbsd-users if they happen to use sufficiently
> > shitty hardware to justify shitty defaults?
> > 
> > x86 hardware doesn't even have console 99% of the time!
> > sysinst isn't a solution because sysinst barely supports amd64.
> 
> If you don't even have a console, why are you complaining?

Because the default terminal on amd64 is the vt100 console one.

Re: Why is TERM=vt100 on the console?

[maya]

On Fri, Sep 14, 2018 at 11:08:29AM +, Valery Ushakov wrote:
> m...@netbsd.org wrote:
> 
> > Every time we have this discussion someone ends up saying that yes,
> > everything being terrible and not supporting anything modern is a
> > great default. they like it that way.
> 
> /etc/ttys uses wsvt25 on all ttyE* for a long long time.  It only uses
> vt100 for console, which may be a serial console, so vt100 is a safe
> default there.  If you know you don't use serial console you can edit
> 1 (one) line in ttys.  Do you really think this is "terrible"?

etc.sparc64/ttys:console"/usr/libexec/getty suncons"wsvt25 on secure

Why is sparc{,64} exempt from having shitty defaults? because people who
use it don't have to ask netbsd-users if they happen to use sufficiently
shitty hardware to justify shitty defaults?

x86 hardware doesn't even have console 99% of the time!
sysinst isn't a solution because sysinst barely supports amd64.

Re: Why is TERM=vt100 on the console?

[maya]

Every time we have this discussion someone ends up saying that yes,
everything being terrible and not supporting anything modern is a great
default. they like it that way.

Re: string_view and clang

[maya]

On Tue, Jun 12, 2018 at 12:32:30PM +0100, Patrick Welche wrote:
> Great news!
> 
> In the meantime, to try things out, I installed pkgsrc/lang/gcc8 and see:
> 
> $ make
> rm -f .gdbinit
> touch .gdbinit
> #   compile  ts/net.o
> c++  -O2 -fPIE -Werror -std=c++14 -fPIC   
> -I/usr/src/local/networking-ts-impl/include  -cnet.cpp
> #  link  ts/net
> c++-lpthread  -pie  -shared-libgcc  -o net  net.o  
> -Wl,-rpath-link,/lib  -L=/lib 
> /usr/bin/ld: /usr/pkg/gcc8/lib/gcc/x86_64--netbsd/8.1.0/crtbegin.o: 
> relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used 
> when making a shared object
> /usr/bin/ld: /usr/pkg/gcc8/lib/gcc/x86_64--netbsd/8.1.0/crtend.o: relocation 
> R_X86_64_32 against `.ctors' can not be used when making a shared object; 
> recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status

I got the same problem and reported upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87221

seems like I don't get it with gcc<8, at least.

Re: Portable curses

[maya]

On Thu, Aug 16, 2018 at 07:44:11AM +0930, Brett Lymn wrote:
> On Tue, Aug 14, 2018 at 01:07:29PM +, m...@netbsd.org wrote:
> > pkgsrc should be better about using base curses now, but it's creating a
> > lot of problems.
> > 
> 
> It is good that things are improving.  I do understand that pkgsrc is a
> complex beast and sometimes the decisions made can be a bit opaque which
> is why I tried not to be critical of the work done in pkgsrc, I know the
> decisions made are done for good reasons.
> 
> > 
> > Maybe FAKE_NCURSES=yes is the answer?
> > 
> 
> I don't know - doing pkgsrc hurts my head :)  

I assume if someone was enthusiastic about getting it, it will be done.

Re: Portable curses

[maya]

pkgsrc should be better about using base curses now, but it's creating a
lot of problems.

pkgsrc tries to hide some of the installed system with wrappers, but
isn't hiding things well enough from cmake. The wrappers only allow
linking to things added by buildlink3.mk, or things in /usr/lib.

so if you have an ncurses package installed, cmake will find parts of
it, so it will decide to use ncurses.

then, it fails to link with the ncurses library due to pkgsrc wrappers
(which try to hide ncurses).

So packages will suddenly begin failing to build with netbsd curses if
you have ncurses installed. Especially cmake ones.

To make matters worse, I could make packages that work with netbsd
curses prefer curses from /usr/lib, but pkgsrc doesn't hide anything in
/usr/lib (it's always possible to link against libraries there), and
then if you have an OS which also ships a base curses but doens't want
to use it, I can't stop it being used. This is the case for illumos.

Maybe FAKE_NCURSES=yes is the answer?

On Tue, Aug 14, 2018 at 01:32:36AM -0400, Dan LaBell wrote:
> Sounds like somewhere  some one started with a strong MSM-linux bias IMO
> 
> Fact is, according to Computer Science, one can't have an O.S. w/o some form
> of Package System.  I know and love those few unique things about BSD that
> can be done with ed and vi, esp. with a rescue slice.
> BUT ANYWAY
> PKGSRC is strongly -- it is in fact -- biased toward ncurses,
> It's like it's the deliberate choice of Researchers to tweak the particular
> "make dot conf" or m-k dot conf syntax,(*) to make, damn, sure either, one
> learns  the syntax, rather than just enjoy reading it, or like ncurses will
> be downloaded, and built, if not the 1st day, in  the 1st week, for sure,
> with, like four nines!
> Seriously.
> Here's an example, that will, both suck in ncurses, and prove U DONT need
> ncurses,
> just for color.  So build vms-empire via pkgsrc, then cd to the work
> directory, and then apply this attached ed-script, or just look at the
> attached picture.



> 
> (*) every so often
> 
> 
> > 
> > I think it should be more widespread. There's already a third-party
> > port (https://github.com/sabotage-linux/netbsd-curses), maybe there
> > should be a tarball somewhere on NetBSD.org?
> 
> 
> 
> 
> > ncurses is available in pkgsrc for those who need/desire it.
> > 
> > Having it in base... well, I know I am biassed but it does mean that we
> > potentially have a monoculture when it comes to curses.
> > 
> > I wouldn't really term it "portable" more like "the same bugs
> > everywhere" which is not really the same :)
> > 
> > 
> > 
> > - Original Message -
> > From:
> > "Cág" 
> > 
> > To:
> > 
> > Cc:
> > 
> > Sent:
> > Tue, 07 Aug 2018 14:19:36 -0500
> > Subject:
> > Portable curses
> > 
> > 
> > 
> > --
> > caóc
> > 
> 

Re: NetBSD reboots if hdmi monitor is switched off

[maya]

On Sun, Aug 12, 2018 at 03:34:13PM +0530, Mayuresh wrote:
> On NetBSD asusnetbsd 8.0_RC1 NetBSD 8.0_RC1 (GENERIC.201804191727Z) amd64
> 
> If I switch off hdmi monitor by pressing power button on the monitor, I
> find that netbsd reboots.
> 
> There are files saved in /var/crash. I saw the instructions at
> https://wiki.netbsd.org/panic/. But I do not have a debug mode kernel
> (/netbsd.gdb as mentioned on above page).
> 
> I can build one, but in the meantime is there any information I can share
> that will help analyze this?

This works:
# cd /var/crash
# gunzip netbsd.N.* # if the latest is called N
# crash -M netbsd.N.core -N netbsd.N
crash> bt

And type all the output starting from 'crash'.

This is often sufficient to tell what the problem is without a debug
kernel. But more debug is always nicer when you're debugging.

> PS: Sorry, I am still on RC1, in case the problem is fixed in the main
> release. There is some inertia involved in upgrading.

No worries. I doubt it.

Re: Some questions about NetBSD

[maya]

On Sun, Aug 12, 2018 at 10:15:10AM -0400, alec wrote:
> Q3: What happens if a security vulnerability is found in the base
> system? Do I really have to fetch things from CVS and recompile them? Or
> is there some way to get updates?

You can unpack new sets on top of old sets. There's daily builds on:
https://nycdn.netbsd.org/pub/NetBSD-daily

You can cd /; tar xzpf /path/to/set.tgz

It will leave a small amount of things behind, postinstall can collect
them, as long as you keep upgrading.
It isn't safe to run postinstall on a downgrade.

For RPI, your kernel is on another partition and not /netbsd, so it's a
bit more involved, but I think you can mount it with mount -t msdos and
replace it.

Re: Portable curses

[maya]

On Tue, Aug 07, 2018 at 02:19:36PM -0500, Cág wrote:
> "NetBSD is one of the last operating systems (or even the last one?)
> not using ncurses."

Illumos is not using ncurses either.
https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/libcurses/screen

Re: panic after sysupgrade update to NetBSD8.0

[maya]

On Tue, Jul 24, 2018 at 05:42:34PM +, m...@netbsd.org wrote:
> On Tue, Jul 24, 2018 at 04:39:17PM +0200, Kamil Rytarowski wrote:
> > On 24.07.2018 15:44, Miwa Susumu wrote:
> > > Hi all.
> > > 
> > > I try update to NetBSD 8.0 from about six months ago current.
> > > by sysupgrade.
> > > 
> > 
> > This would a downgrade and it's not fully supported and can brick your
> > setup. It might be easier to reinstall unless you know what you are doing.
> > 
> > > after reboot then panic. at modules...?
> > > https://imgur.com/a/LRuTSNs
> > > 
> > > sysupgrade support update from stable ? (e.g 7.1.2)
> > > 
> > > 
> > 
> > sysupgrade is for upgrades and 7.1.2 -> 8.0 shall work.
> > 
> 
> I've booted 7.1.x and 8.0 kernels on a -current userland. while I don't
> expect everything to work, it doesn't panic. I'd probably still regard
> it as a bug if it did.

Never mind, I can see, the panic is init dying. It's dynamically linked,
and postinstall probably removed an "older" library that init is linked
against, so it won't run.

You can still boot with:
boot -a (in boot prompt)
and select /rescue/init
/rescue/sh
export PATH=/rescue # now you can use regular commands from rescue

and unpack sets on top. This should work fine. it's postinstall that has
somewhat simple logic.

Re: panic after sysupgrade update to NetBSD8.0

[maya]

On Tue, Jul 24, 2018 at 04:39:17PM +0200, Kamil Rytarowski wrote:
> On 24.07.2018 15:44, Miwa Susumu wrote:
> > Hi all.
> > 
> > I try update to NetBSD 8.0 from about six months ago current.
> > by sysupgrade.
> > 
> 
> This would a downgrade and it's not fully supported and can brick your
> setup. It might be easier to reinstall unless you know what you are doing.
> 
> > after reboot then panic. at modules...?
> > https://imgur.com/a/LRuTSNs
> > 
> > sysupgrade support update from stable ? (e.g 7.1.2)
> > 
> > 
> 
> sysupgrade is for upgrades and 7.1.2 -> 8.0 shall work.
> 

I've booted 7.1.x and 8.0 kernels on a -current userland. while I don't
expect everything to work, it doesn't panic. I'd probably still regard
it as a bug if it did.

Re: Extremely poor disk performance on ProLiant DL360 G5 RAID

[maya]

On Thu, Jul 19, 2018 at 12:03:29PM +0200, Frank Wille wrote:
> ...and two 550 GB SAS RAID-1 disks, configured via the BIOS and appearing
> as a single SCSI disk:
> ciss0 at pci7 dev 0 function 0: HP Smart Array 3
> ciss0: interrupting at ioapic0 pin 16
> ciss0: 1 LD, HW rev 3, FW 5.20/5.20, 64bit fifo
> scsibus0 at ciss0: 1 target, 1 lun per target

This might be relevant:
https://v4.freshbsd.org/commit/netbsd/src/a5QCd7STkggvNCqA

Re: Zotac ZBOX nano

[maya]

For context:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-j-series-datasheet-spec-update.pdf

APL30 A Store Instruction May Not Wake up MWAIT
Problem: 
One use of the MONITOR/MWAIT instruction pair is to allow a logical processor 
to wait 
in a sleep state until a store to the armed address range occurs. Due to this 
erratum, 
stores to the armed address range may not trigger MWAIT to resume execution.
Implication : 
The logical processor that executed the MWAIT instruction may not resume 
execution 
until it receives an interrupt. Software that does not rely on stores to the 
armed 
address range to wake a logical processor from an MWAIT sleep state is not 
affected 
by this erratum.
Workaround :  
Software needs to use interrupts to wake processors from MWAIT-induced sleep 
states.

I got the hint from a reddit comment:
https://www.reddit.com/r/PFSENSE/comments/76qag8/240_not_booting_due_to_hpet/dogx84x/

It says you can turn it off in BIOS too, if you don't feel like changing
the kernel.

Re: Zotac ZBOX nano

[maya]

Matching 8.0RC2 kernel with this change:
https://ftp.netbsd.org/pub/NetBSD/misc/maya/netbsd-less-mwait

Re: Zotac ZBOX nano

[maya]

Does this diff help

Index: x86/cpu.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/cpu.c,v
retrieving revision 1.158
diff -u -r1.158 cpu.c
--- x86/cpu.c   22 Jun 2018 06:22:37 -  1.158
+++ x86/cpu.c   26 Jun 2018 13:25:18 -
@@ -877,23 +877,9 @@
 * interrupts off.
 */
while ((ci->ci_flags & CPUF_GO) == 0) {
-   if ((cpu_feature[1] & CPUID2_MONITOR) != 0) {
-   x86_monitor(>ci_flags, 0, 0);
-   if ((ci->ci_flags & CPUF_GO) != 0) {
-   continue;
-   }
-   x86_mwait(0, 0);
-   } else {
-   /*
-* XXX The loop repetition count could be a lot higher, but
-* XXX currently qemu emulator takes a _very_long_time_ to
-* XXX execute the pause instruction.  So for now, use a low
-* XXX value to allow the cpu to hatch before timing out.
-*/
for (i = 50; i != 0; i--) {
x86_pause();
}
-   }
}
 
/* Because the text may have been patched in x86_patch(). */

Re: Did netbsd ever support force remount readonly for root?

[maya]

You don't need to remount to make / read-only, because the initial mount
is already read-only. This is the scenario in a single-user boot.

in /etc/fstab you specify "please upgrade / to read-write"

It used to be possible to remount rw->ro but it was buggy.
https://gnats.netbsd.org/30525
hannken fixed this recently.

Re: How to specify userconf kernel options on armv7

[maya]

does drvctl -d ulpt0 work better?
(with netbsd running)

Re: Status of run0 on armv7 NetBSD 8.0_RC1 rpi2

[maya]

On Mon, Jun 11, 2018 at 09:19:05PM +0530, Mayuresh wrote:
> # wpa_cli status
> Selected interface 'run0'
> 20:31:07.754: wpa_state=SCANNING
> address=00:c1:00:c1:94:b6
> 
> wpa_cli status always shows scanning only.

You can make wpa more informative by running it like this:
wpa_supplicant -i run0 -c /etc/wpa_supplicant.conf # -d extra noisy and
probably not needed

Most notably, I have this problem if people setup the AP in 802.11n only
mode. It is visible only when scanning but authentication times out.
NetBSD does not support 802.11n yet. I've had to change APs to
"802.11b/g/n compatibility mode" a few times.

Re: wip/virtualbox vs emulators/qemu vs xen performance comparison?

[maya]

On Wed, Jun 06, 2018 at 10:19:00AM +0200, Manuel Bouyer wrote:
> On Wed, Jun 06, 2018 at 07:30:38AM +0530, Mayuresh wrote:
> > On Tue, Jun 05, 2018 at 07:56:50PM +0200, Manuel Bouyer wrote:
> > > If you want to run on a desktop you'll probably run into graphic drivers
> > > issues with NetBSD/Xen.
> > > 
> > > qemu on NetBSD is a plain emulator, no hardware speedup.
> > > 
> > > I'm not sure what virtualbox would do on a NetBSD host. AFAIK this would
> > > need some kernel support which we don't have.
> > 
> > Thanks. I think virtualbox might not be an option while qemu may be ruled
> > out due to being too slow for this application.
> > 
> > The leaves only Xen as an option.
> > 
> > I do not have any high end graphics requirements (3D etc). Could Xen still
> > be a problem. Here is a link to hardware specification:
> 
> No idea. Maybe vesa could work. I've not tried startx on a Xen dom0 for
> a long time, all my Xen hosts use serial console.
> 
> -- 
> Manuel Bouyer 
>  NetBSD: 26 ans d'experience feront toujours la difference
> --

vesa works but only if you assign like 3GB RAM to dom0.
More will reboot.
I assume netbsd/xen uses memory that vesa thinks it hsould not like with
dmidecode

Re: 8.0_RC1 amd64 crash during boot

[maya]

On Sun, May 20, 2018 at 10:36:27PM +0530, Mayuresh wrote:
> I have been using 8.0_RC1 amd64 for several days, though first time there
> was a crash during boot, which is not reproducible. If at all, it may
> relate to my connecting USB kbd/mouse while it was booting, not sure.
> 
> I noticed following files, as indicated in boot messages:
> 
> # ls -l /var/crash/
> total 24296
> -rw---  1 root  wheel 2 May 20 22:31 bounds
> -rw---  1 root  wheel 5 Apr 20 00:15 minfree
> -rw---  1 root  wheel  24019696 May 20 22:31 netbsd.0.core.gz
> -rw---  1 root  wheel747336 May 20 22:31 netbsd.0.gz
> 
> 
> I suppose these should have information about what happened. Please help
> me with what information to extract from these and how so that I can
> provide more problem details.
> 
> Mayuresh

Hi Mayuresh.

The way to use these files is:

# gunzip netbsd.0.*
# crash -M netbsd.0.core -N netbsd.0
> bt
> dmesg
(and so on)


-- Less generally useful, more advanced usage info below --
Alternatively, for rare cases you want some specific capabilities from gdb:
gdb netbsd.0
(gdb) target kvm netbsd.0.core
(gdb) bt full
(and so on)

I'm quite a big fan of gdb for reproducible crashes, I'll build a kernel
with -O0 -ggdb3 or so and then 'bt full' will give all the variables in
a function, which is much nicer than printfs.

The different kernel is so you won't get mostly  values.

Re: Gah... How usable is www/firefox on NetBSD?

[maya]

PR lib/53273 being fixed would solve the actual issue, although we can
implement things differently (someone tried, but it doesn't work).

In the meantime disable multiprocessor firefox. I am searching how to
properly do this in the package but now my attempt failed.

Re: edgerouter lite

[maya]

On Mon, May 07, 2018 at 05:39:28PM -0400, C?g wrote:
> Maya wrote:
> 
> > MIPS has* fixed size instructions, so 64bit instructions are very big,
> > and so it runs a 32bit userland that only runs on 64bit CPUs, kinda
> > like the amd64 x32 ABI.
> > * They now made a variant which isn't like this
> 
> Are you talking about the Warrior series?

I think only this super new nanoMIPS stuff:
https://www.anandtech.com/show/12699/mips-announces-i7200-32bit-cpu-with-new-nanomips-isa

And warrior is MIPSnnR6

But I haven't been following super closely!

Re: edgerouter lite

[maya]

On Mon, May 07, 2018 at 06:51:42AM -0500, ed...@pettijohn-web.com wrote:
> Appreciate your response. I feel confident I can install. More curious about 
> what isn't supported yet. Such as multiple processors, altq, and the like.

yeah, SMP is what isn't working. I don't know what makes it eventually
panic, though it does make it to multiuser in -current.
Modules also won't work, you will need everything as a builtin.

MIPS has* fixed size instructions, so 64bit instructions are very big,
and so it runs a 32bit userland that only runs on 64bit CPUs, kinda like
the amd64 x32 ABI.

Most architectures don't have as good a reason to do it, so MIPS is the
'official 32bit compat tester'. Most bugs of missing features were
actually missing 32bit compat. I suspect we forgot to backport some
things.

I have an ERLITE, but I don't use it as a router, so I can't tell you
how well it does. MIPS is just my favourite architecture.
Other netbsd people do use it as a router though.

* They now made a variant which isn't like this

Re: edgerouter lite

[maya]

On Mon, May 07, 2018 at 04:46:41AM +, m...@netbsd.org wrote:
> Attach console cable and ethernet cable.
> On host, configure it to a known IP, e.g. I use
> ifconfig re0 192.168.0.1
> enable tftp via uncommenting the /etc/inetd.conf entry and restarting
> inetd.
> in /tftpboot, place ERLITE INSTALL kernel.
> e.g. /tftpboot/erlite-install
> 
> cu -s 115200 -l /dev/ttyU0
> 
> On u-boot console (not in linux):
> set serverip 192.168.0.1
> set ipaddr 192.168.0.5
> tftp $loadaddr erlite-install
> bootoctlinux
> 
> netbsd should boot fine. ignore the installer.
> In the msdos filesystem, replace vmlinux.64 with a netbsd ERLITE kernel
> (not INSTALL).
> replace the ext4 filesystem with a better root filesysttem for
> netbsd,like FFSv2.
> 
> Configure networking to fetch the sets from the host. Use mips64eb sets.
> ifconfig cnmac0 192.168.0.5
> route add default 192.168.0.1
> 
> scp myhostusername@192.168.0.1:/path/to/sets/*.tgz .
> cd /
cd /targetroot
> for i in *.tgz; do tar xzpf $i; done
cd /targetroot/dev
sh MAKEDEV all
echo "rc_configured=YES" >> /targetroot/etc/rc.conf
Adjust /etc/fstab

> 
> Reboot.
> 
> It works, but some things are not supported as good as e.g. amd64.

Re: edgerouter lite

[maya]

Attach console cable and ethernet cable.
On host, configure it to a known IP, e.g. I use
ifconfig re0 192.168.0.1
enable tftp via uncommenting the /etc/inetd.conf entry and restarting
inetd.
in /tftpboot, place ERLITE INSTALL kernel.
e.g. /tftpboot/erlite-install

cu -s 115200 -l /dev/ttyU0

On u-boot console (not in linux):
set serverip 192.168.0.1
set ipaddr 192.168.0.5
tftp $loadaddr erlite-install
bootoctlinux

netbsd should boot fine. ignore the installer.
In the msdos filesystem, replace vmlinux.64 with a netbsd ERLITE kernel
(not INSTALL).
replace the ext4 filesystem with a better root filesysttem for
netbsd,like FFSv2.

Configure networking to fetch the sets from the host. Use mips64eb sets.
ifconfig cnmac0 192.168.0.5
route add default 192.168.0.1

scp myhostusername@192.168.0.1:/path/to/sets/*.tgz .
cd /
for i in *.tgz; do tar xzpf $i; done

Reboot.

It works, but some things are not supported as good as e.g. amd64.

Re: Gah... How usable is www/firefox on NetBSD?

[maya]

On Tue, May 01, 2018 at 05:31:20PM +, m...@netbsd.org wrote:
> Hi Mayuresh.
> 
> I set:
> browser.remote.autostart = false
> 
> to avoid the crashes.

Sorry, that's browser.tabs.remote.autostart=false and might wantto
change .2 too.

And it is in about:config.

Re: Gah... How usable is www/firefox on NetBSD?

[maya]

Hi Mayuresh.

I set:
browser.remote.autostart = false

to avoid the crashes.

Re: Any Guide/resource to port broadcom (bcm43142) wifi driver?

[maya]

On Sun, Apr 29, 2018 at 07:10:05PM +, m...@netbsd.org wrote:
> disregard the above, I didn't realize wl is open source and MIT
> licensed. I guess it's doable then.

...Except for the giant LICENSE file that looks nothing like an open
source license I know. 

Re: Any Guide/resource to port broadcom (bcm43142) wifi driver?

[maya]

disregard the above, I didn't realize wl is open source and MIT
licensed. I guess it's doable then.

Re: Any Guide/resource to port broadcom (bcm43142) wifi driver?

[maya]

On Sun, Apr 29, 2018 at 05:58:14PM +0700, Wean Irdeh wrote:
> https://www.broadcom.com/support/download-search/?pf=Wireless+LAN+Infrastructure
> 
> My laptop contain bcm43142 wifi pcie card, which is not supported by
> NetBSD, so I'm looking for porting the driver on the link above to NetBSD,
> any guide/resource is appreciated.
> 
> Thank you

>From the looks of things, even linux doesn't have an open source driver
for this card. It would be very hard, unless you are lucky and it is
similar to cards supported by open drivers.

I'd consider buying another card instead of this.

Re: boot issues

[maya]

After paying more attention:

things think that libc.so. is in  /usr/lib sometimes, e.g.
/usr/bin/login:
-lutil.7 => /usr/lib/libutil.so.7
-lc.12 => /usr/lib/libc.so.12
-lcrypt.1 => /usr/lib/libcrypt.so.1
-lpam.4 => /usr/lib/libpam.so.4


/usr/lib/libc.so.12 is a symlink to the one in /lib, but that is where
the binary thinks it should be.

Re: boot issues

[maya]

My go to for broken setups of any kind:
drop to boot prompt
type "boot -as" (ask, single user)

then pick /rescue/init as your init, and otherwise normal.
export PATH=/rescue

if you have a working /rescue that is all you need. it's a single
statically linked binary that can recover your setup, there is even
/rescue/ftp and /rescue/ifconfig.

Re: Issue when compining __SHIFTIN in cdefs.h

[maya]

On Tue, Apr 03, 2018 at 12:00:49PM +0530, Ajay Garg wrote:
> I am compiling src-netbsd, with the following setup :
> 
>  * Host-Machine ==  Ubuntu 16.04 on a x86_64
>  * (Cross) Compiler ==  aarch64-linux-gnu-gcc
^^^ That is an odd choice, what are you trying to do?

You might be building netbsd libc with some of the linux headers from
this setup, which shouldn't work.

Re: 7.1.2 installer hangs on boot

[maya]

On Thu, Mar 22, 2018 at 04:01:06PM +0100, Fekete Zolt?n wrote:
> boot: 

Use netbsd-8
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-8/201803200350Z/images/NetBSD-8.0_BETA-amd64-install.img.gz

(You need xhci)

Re: NetBSD disk performance on VirtualBox

[maya]

On Mon, Mar 19, 2018 at 02:58:06PM +0100, Fekete Zolt?n wrote:
> Any setting which influence the test and I didn't apply?

yes, need to figure out what to make GNU dd behave the same.
It has different defaults.

Re: NetBSD 7.1.1 instability - hangs

[maya]

You can confirm this by reading /var/log/messages

It will look like:
UVM pid 123 (X) killed: out of swap

Re: NetBSD 7.1.1 instability - hangs

[maya]

I strongly suspect you are running out of RAM due to lang/rust not
respecting MAKE_JOBS and linking in parallel, killing Xorg.

I've seen the same.

You can tell if normal shutdown works fine and you get a message in UVM
about Xorg being killed

So it's three bugs:

- lang/rust doesn't respect MAKE_JOBS
- Xorg being killed like so is exceptionally fatal, we don't recover from it
  ... this should be possible to fix now.
- We could try to avoid killing Xorg in these circumstances

(this behaviour is caused by something called 'memory overcommit')

as a short term solution:
- Add more swap, so it doesn't blow up

Re: bozohttpd

[maya]

On Wed, Feb 28, 2018 at 04:41:57PM +, Patrick Welche wrote:
> /usr/libexec/httpd -d -d -d -d -P /tmp/foo.pid -i 127.0.0.1 -b -s /var/www

works for me.

easier to debug:
 /usr/libexec/httpd -d -d -d -d -P /tmp/foo.pid -i 127.0.0.1 -b -f /var/www

NetBSD taking part in Google Summer of Code 2018

[maya]

Hi, lists!

If you, or someone you know, wanted to dive deep into NetBSD or pkgsrc,
are currently a student, google's summer of code is a great opportunity.

You can get a stipend (paid for by Google) and spend a few months getting
to know and improving the insides of NetBSD or pkgsrc.

The schedule is:
12-27 March Applying
23 AprilFind out if you were accepted
14 May - 22 August  Do the project!

We have some suggestions for suitable projects:
- ARM EFI bootloader
- Using libFuzzer on base tools
- Refactoring ALTQ (QoS implementation) and integrating with NPF
- Testsuite for libcurses
- Improve pkgin

Other suggestions and details are at:
https://wiki.netbsd.org/projects/gsoc/

These projects are suggestions; you can come up with your own.
Suggestions for other suitable projects are welcome.

Note that NetBSD is not the only project participating, you can see
the others that do here:
https://summerofcode.withgoogle.com/organizations/

Feel free to contact, or chat around on IRC:
irc.freenode.org #netbsd #netbsd-code #pkgsrc

- Maya

Re: Spectra/meltdown vulnerability

[maya]

On Mon, Jan 08, 2018 at 02:12:42PM -0500, Derrick Lobo wrote:
> Are there any updates with regards to Spectra/meltdown. 

Hi Derrick,

maxv is working on some changes to mitigate it on x86.
http://mail-index.netbsd.org/tech-kern/2018/01/06/msg022883.html
http://mail-index.netbsd.org/source-changes/2018/01/07/msg090952.html
http://mail-index.netbsd.org/source-changes/2018/01/07/msg090945.html

etc.

Unfortunately it's not a small change. It will be a while before it is
complete, and longer until it is backported to stable branches.

I don't know if we have support for the ARM Cortex-A75 yet.

Re: Some problems moving to new hardware with NetBSD-8/i386

[maya]

On Sat, Nov 18, 2017 at 05:55:11AM -0700, Andy Ruhl wrote:
> boot -1 -2 (disable SMP, disable ACPI)
> 
> 5. It "feels" generally slow. Slower than my 8 or so year old AMD
> system with 1 gig of memory. But I'm not sure if this is real.

I assume these are the cause and effect, why do you need to disable SMP
and ACPI?

Re: Netbsd-7/i386 won't boot on new motherboard/CPU

[maya]

On Wed, Nov 15, 2017 at 08:02:44AM -0700, Andy Ruhl wrote:
> 
> http://acruhl.freeshell.org/netbsd_wont_boot2.jpg
> 
> (last message is kern.module.path=/stand/i386/8.0/modules)
> 
> I don't know what's happening at this point.

Hi Andy,

If you have a PS/2 keyboard you should be able to use ddb
(ctrl+alt+escape), and see where it's stuck.

Another option is boot -d (in the boot prompt) if I'm wrong about the
string to enter ddb.

Re: [pkgsrc] ICU needs configure CFLAGS='-03'

[maya]

On Tue, Nov 14, 2017 at 03:21:47PM +0100, tlaro...@polynum.com wrote:
> On Tue, Nov 14, 2017 at 03:08:29PM +0100, Benny Siegert wrote:
> > Can you post the entire config.log?
> > 
> 
> Attached.
> 
> (Indeed there is the info: libssp not found---what is it?)
> 

Hi,

SSP is a compiler security mitigation.
In C are some functions which are more prone to buffer overflows, and
while there are better functions to use, they still exist in a lot of
code (and are easier to use).

I think the compiler inserts fake values to the end of buffers and
checks if it has been modified, and so it can terminate the program if
an overflow had happened (as opposed to possibly allowing code
execution).

netbsd did not want to supply libssp, an independent library from GCC,
and so provides the same in libc. GCC had to be taught not to build
libssp on netbsd, but didn't in the past.

The problem you have is likely an older gcc48/49 package that does not
contain the fixes not to think netbsd built with -lssp and
-lssp_nonshared.  Others have fixed some more changes.

Re: NetBSD-8 and graphics cards

[maya]

On Thu, Nov 09, 2017 at 09:30:13PM +, Sad Clouds wrote:
> I've gone back to an old PCI card with ATI Rage 128, but this also
> doesn't work with Xorg

rage128:
You might want to build a kernel with all the new DRMKMS drivers
disabled, and old ones enabled. someone previously made a bug report for
it*, it might need "r128drm* at drm?" and commenting out all the
other DRMKMS drivers.

(It would be the old DRM code. there's new DRM code for rage128, just
nobody made it build/work yet).

quadro:
Did you update Xorg to netbsd-8 too? older netbsd Xorg lacks a nouveau
Xorg driver.

gt710: probably just too new. but would be interesting to see the panic
backtrace

netbsd doesn't support amdgpu (yet), I think pre-GCN cards have a chance
of working well and maybe some GCN1.

I don't recommend nvidia in general. comparing to a proprietary driver
in linux I got 0.2* the result in glxgears.
I use a GTX 770 but I heard of another 700 series that didn't work.

* http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=52496

Re: [NetBSD 8.0_BETA] Panic on amd64

[maya]

On Wed, Jul 05, 2017 at 09:02:12AM +0200, BERTRAND Jo?l wrote:
> filt_sowdetach() at filt_sowdetach+0x3f
> knote_detach() at knote_detach+0x70
> kevent1() at kevent1+0x686
> sys___kevent50() at sys___kevent50+0x33

This is likely fixed by:
https://mail-index.netbsd.org/source-changes/2017/07/01/msg085934.html

Re: distcc for pkgsrc issue

[maya]

On Fri, Jun 30, 2017 at 07:32:54AM +, John Halfpenny wrote:
>   # file test.o
>   test.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
> 

I think that's the output it gives for a linux object file. compare:
$ GOOS=linux go build hello.go; file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, 
not stripped, with debug_info
$ GOOS=netbsd go build hello.go; file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (NetBSD), statically 
linked, for NetBSD 5.99, not stripped, with debug_info

Re: wpa_supplicant error on mac

[maya]

On Wed, Jun 28, 2017 at 11:37:54PM +0700, Gua Chung Lim wrote:
> % ifconfig wm0
> wm0: flags=8843 mtu 1500

wm0 is a wired driver (you can see what it is for by 'man 4 wm' - Intel
ethernet cards).

I suspect NetBSD doesn't support the network card on your laptop, most
Broadcom wifi cards do not work. but if they do, it is with the 'bwi'
driver which requires manually downloading the firmware (as it cannot be
legally redistributed by NetBSD), and instructions are in the bwi man
page. But that driver is mostly for older cards.

I"ve personally replaced the card in my laptop with another one, and
previously used a slim USB one, due to a similar issue.

Sorry