Re: amdgpu laptops with 10 & current?

[Robert Swindells]

nia  wrote:
> The ThinkPad A485 looks pretty interesting for use with NetBSD.
>
> - 1st Gen AMD Ryzen Mobile
> - 32 GiB DDR4 2400 MHz
> - AMD Radeon Vega 6, 8 or 10
>
> Usually I prefer the smaller X series, but they've made them
> non-upgradable and harder to repair...

Prompted by abs@, I got a reconditioned T495S.

> ethernet is re0, this is different from the intel models that are
> usually wm0. internal dev chatter would point to wm(4) being the
> better driver, but probably not enough to matter for my purposes
> (100mbit/s DSL). I usually use ethernet at home.

The T495S needs a Lenovo specific dongle to use the re(4) device, it was
cheaper to get an axen(4) device to use in the USB-C port so haven't
tried the re(4).

> Anyone using amdgpu with a device like this? I'm sure llvmpipe
> is okay(tm), would be nice to have the runtime configuration
> advantages of modesetting though.

It doesn't really work with amdgpu, fails to attach maybe 9 times out
of 10 and hangs whenever I try to use it. Have seen a report that
Linux 5.6 doesn't work either but later revisions do, not spotted
anything obvious in later DRM drivers to try though.

The integrated camera doesn't work on the T495S, I think this is a
limitation of our xhci driver.

Thinkpad battery status

[Robert Swindells]

My Thinkpad T495s didn't work with acpibat(4) so I tried adding support
for the ACPI 3.0 (and later) Battery Information Extended status call.

Patch here:

Re: new "compat" sets have really made sets harder to manage.

[Robert Swindells]

nia  wrote:
> I've thought about this a bit more and I want to write a separate
> script for generating the compat set lists, the current one is a
> little confusing (it tries to do a lot of things) and isn't really
> suited to generating a list based on another list.
>
> I'll work on this when I have time.

Do you want people to hold off committing any changes to the current set
lists?

Re: gcc 12 question

[Robert Swindells]

Patrick Welche  wrote:
> I'm trying to build a release on amd64 using
>
> HAVE_MESA_VER=21
> HAVE_GCC=12

What does pkgsrc graphics/MesaLib do if built using gcc 12?

Re: How to raise iwm0?

[Robert Swindells]

"Lizbeth Mutterhunt, Ph.D"  wrote:
> As axen0 fails to connect

Have you tried any of the patches suggested in the current email thread
on the axen(4) driver?

> I want to try the wlan0, but it won’t be able to make a wlan0. I can’t
> find the iwm module in kernel config. Does it be named differently (I’ve
> got it from FreeBSD) or is just the hardware bad. I mean it’s
> unsupported, because I killed a Chromebook to an EFI machine. It’s a
> Gemini Lake.

I think you will need to provide more information on your hardware for
anyone to be able to help with this.

What is the PCI ID of the wireless device?

Re: sys/dev/usb/if_axen.c

[Robert Swindells]

Makoto Fujiwara  wrote:
> I have following device:
>  -
>  axen0 at uhub3 port 1
>  axen0: ASIX (0x0b95) AX88179A (0x1790), rev 2.10/2.00, addr 3
>  axen0: AX88179
>  ukphy0 at axen0 phy 3: OUI 0x00e038, model 0x0006, rev. 1
>  ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
>  axen0: Ethernet address 
>  -
> And running 10.99.10,
> it emits following lines
>
> Nov 13 20:24:54 beebox-03 /netbsd: [ 154.8236912] axen0:
> autoconfiguration error: invalid buffer(pkt#1), continue

Please could you try the patch I posted here:



There seems to be a difference in behaviour between the AX88179 and
AX88179A, the driver in the tree is reported to work for the AX88179.

I think we need a change to the driver to detect the chip revision and
choose between two different receive functions.

Re: modesetting vs intel in 10.0

[Robert Swindells]

Brian Stuart  wrote:
> Am I correct that even with all the improvements, there are still
> Intel video systems that aren't supported?  On a Dell Latitude 7420,
> dmesg shows:
>
> [ 1.051227] pchb0 at pci0 dev 0 function 0: Intel Tiger Lake (UP3
> 4Core) Host (rev. 0x01)
> [ 1.051227] i915drmkms: preliminary hardware support disabled

The NetBSD driver code tests the require_force_probe member of the
pci_device_id struct, it prints the message above and doesnt attach the
DRM driver if it is set.

This is set for Elkhart Lake and Tiger Lake GPUs in the version of the
DRM code in the tree, which is from Linux 5.6-rc3, later GPUs are not
detected at all.

The equivalent Linux probe function doesn't do very much if this flag
is set, you could try just removing the test to see what happens using
the patch below.

If people have got the i915drmkms driver to attach then it would be
helpful if they could try the new native MesaLib, I don't have any
recent Intel systems to test it on. To build new MesaLib set
HAVE_MESA_VER=21 in your /etc/mk.conf before running build.sh.

Index: i915_pci_autoconf.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/i915drm/i915_pci_autoconf.c,v
retrieving revision 1.14
diff -u -r1.14 i915_pci_autoconf.c
--- i915_pci_autoconf.c 15 Oct 2022 15:20:06 -  1.14
+++ i915_pci_autoconf.c 29 Aug 2023 12:55:27 -
@@ -108,11 +108,12 @@
const struct intel_device_info *const info =
(struct intel_device_info *)ent->driver_data;
 
+#if 0
if (info->require_force_probe) {
printf("i915drmkms: preliminary hardware support disabled\n");
return NULL;
}
-
+#endif
return ent;
 }
 

Re: modesetting vs intel in 10.0

[Robert Swindells]

nia  wrote:
> After some testing on a Skylake machine, I've concluded
> that xf86-video-modesetting is far superior to xf86-video-intel
> on that generation of Intel hardware - the most obvious thing
> is that modesetting has functional VSync and superior 3D performance
> with less tearing.
>
> Only problem is that we default to intel, modesetting you need
> to choose explicitly through xorg.conf.

Another option could be to just have a shell script that will
rename intel_drv.so to something that xorg won't find.

We have had multiple builds of ati and intel installed at the
same time that needed to be renamed to pick the one you wanted.

> I also found similar problems in "radeon", but found that
> modesetting would somehow pick a display mode that the monitor
> didn't support. Maybe this is actually a drmkms bug - I'm not
> sure.

One reason for using radeon is that it will make use of 2D hardware
on older cards, newer ones are 3D only.

> But maybe modesetting is mature enough (and intel bad enough)
> to warrant being the default for Intel GPUs.

I don't have a feel for which generations of Intel GPU have 2D or
video HW.

What Mesa settings are you using with all of this?

Re: /usr/bin/ftp crash on -current (10.00.4) aarch64

[Robert Swindells]

Chavdar Ivanov  wrote:
> The weird and suspicious thing is that /usr/bin/ftp is linked to both
> existing libcrypto.so versions:
>
> ldd /usr/bin/ftp
> /usr/bin/ftp:
>-ledit.3 => /usr/lib/libedit.so.3
>-lterminfo.2 => /usr/lib/libterminfo.so.2
>-lc.12 => /usr/lib/libc.so.12
>-lssl.15 => /usr/lib/libssl.so.15
>-lcrypto.14 => /usr/lib/libcrypto.so.14
>-lcrypt.1 => /lib/libcrypt.so.1
>-lcrypto.15 => /usr/lib/libcrypto.so.15

I'm guessing you did an update build not a clean one. Also, did you use
the -j flag to build in parallel?

Do a clean build and everything should work.

Re: Difference between i915drm and i915drmkms

[Robert Swindells]

matthew green  wrote:
> the old drm code for i915 is probably extremely obsolete at this
> point.  i don't think it works on anything that current does
> (or least, before the latest refresh -- i think there are still
> a couple of blank screens, but i think newer than this code would
> support anyway.)

The old i915 drm code expects to work with the xf86-video-intel-old
driver that is in xsrc.

I only got part way through getting the old driver to build against
the xorg-server that is in xsrc, the xf86-video-intel driver and
i915drmkms kernel code seemed to be working fine for everyone at the
time so I stopped working on the old driver.

I would guess problems seen now are because i915drmkms is taken from
Linux 5.6rc3 and doesn't support newer hardware.

Re: issue building current kernel fails, stripattach

[Robert Swindells]

Riccardo Mottola  wrote:
> to debug nouveau I need to build a current kernel, as advised on 
> netbsd-users.
>
> I got sources snapshot, updated with "cvs -q update -dPA". Did it 
> twice to be sure not to have gotten a bad release.
> To do this, I need current tooIs: I built tools  using "./build.sh -U 
> -j2 tools" .
>
> However, building the kernel fails
>
> #  link  Aspire/netbsd
> /usr/src/obj/tooldir.NetBSD-9.3-i386/bin/i486--netbsdelf-ld -Map 
> netbsd.map --cref -T netbsd.ldscript -Ttext c010 -e start -X -o 
> netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o 
> swapnetbsd.o
> /usr/src/obj/tooldir.NetBSD-9.3-i386/bin/i486--netbsdelf-ld: 
> ioconf.o:(.rodata+0xa0): undefined reference to `stripattach'

Remove "pseudo-device strip" from your kernel config.

Re: Usable Notebook for NetBSD-current wanted

[Robert Swindells]

Frank Kardel  wrote:
>On 09/09/22 16:03, Robert Swindells wrote:
>> Frank Kardel  wrote:
>>> I am still looking for a notebook that can be used with NetBSD-current.
>>> I need to replace a 10+ year old W510 that is dying a slow agonizing
>>> thermal death.
>>>
>>> So far I have not been able to find a usable solution.
>>>
>>> Are there ANY recommendations on available notebooks that
>>> NetBSD-current can handle ?
>>
>> People fix the hardware that they have.
>>
>> My newest amd64 laptop is an ASUS from 2005 with an NVIDIA GPU, it works
>> fine with NetBSD-current from last week.
>
> Maybe I should start looking on auction sites for vintage notebooks from 
> 2005 :-)

If we don't have an overlap between people with recent hardware and
people who could and want to make that hardware work then we have a
problem.

Re: Usable Notebook for NetBSD-current wanted

[Robert Swindells]

Frank Kardel  wrote:
> I am still looking for a notebook that can be used with NetBSD-current. 
> I need to replace a 10+ year old W510 that is dying a slow agonizing 
> thermal death.
>
> So far I have not been able to find a usable solution.
>
> Are there ANY recommendations on available notebooks that
> NetBSD-current can handle ?

People fix the hardware that they have.

My newest amd64 laptop is an ASUS from 2005 with an NVIDIA GPU, it works
fine with NetBSD-current from last week.

Re: legacy DRM UMS vs. "options DRM_LEGACY"

[Robert Swindells]

"John D. Baker"  wrote:
> Well, 3 out of 4 kernels built when the above procedure was followed.
> the following config still fails when the old DRM drivers are enabled:

Your RACKMOUNT config builds fine for me (apart from plip but I will fix
that), are you sure that the link errors you are seeing are from the
kernel and not from a module?

Re: legacy DRM UMS vs. "options DRM_LEGACY"

[Robert Swindells]

"John D. Baker"  wrote:
>On Sat, 3 Sep 2022, Robert Swindells wrote:
>> You look to be mixing drm and drm2 in your build, you don't want to do
>> that, you want one or the other.
>
>_I_ am not.  It's the result of whatever was changed with the introduction
>of "options DRM_LEGACY".  I've built kernels with these configs since
>NetBSD 5 with only minor tweaks to elide drivers for non-existent
>hardware.  The last time I was able to successfully build these kernels
>was 29 July 2022.
>
>I seem to recall a mention that at present only "viadrmums" works with
>the DRM_LEGACY option and indeed, I have a machine which uses that and
>it builds fine.  I was hoping there was a way around that for the other
>legacy DRM drivers, but unless/until they are adapted, I'll have to do
>without.

The DRM_LEGACY option is just for drm2, if you want to build a kernel
with drm drivers then don't enable DRM_LEGACY.

Post a kernel config that you are trying to build, without that people
won't be able to work out what is going wrong.

Re: legacy DRM UMS vs. "options DRM_LEGACY"

[Robert Swindells]

"John D. Baker"  wrote:
> I have several custom kernels for i386 machines which I can no-longer
> build since the introduction of "options DRM_LEGACY".
>
> These kernels are for machines with
>
>   ATI mach64, rage128, and/or old radeon (R100)
>
> As such, these kernels have all the DRMKMS drivers disabled and one
> or more of the legacy DRM (UMS) drivers:
>
>  mach64drm* at drm?
>  r128drm*   at drm?
>  radeondrm* at drm?
>
> enabled.



> How may I get these kernels to build again?

Do you really need to run X11 on these machines?

You look to be mixing drm and drm2 in your build, you don't want to do
that, you want one or the other.

Re: NetBSD 9.2 installer can't detect disk of some Hetzner VPSes

[Robert Swindells]

Mayuresh  wrote:
> Basically I do not know their motivation to switch over to Q35.

At a guess, it is closer in configuration to the host hardware so has
a lower overhead.

>It's just a perspective to convince a provider to give a setup that works
>for us, since there is no other way till NetBSD supports Q35, and we don't
>know when will that be. At last that's the impression I got from this
>thread.

You, or someone else who wants to use a Hetzner VPS, could do the
experiment that I suggested.

If "qemu -machine q35" fails to boot NetBSD in the same way then it will
be a lot easier to resolve this.

Re: NetBSD 9.2 installer can't detect disk of some Hetzner VPSes

[Robert Swindells]

Mayuresh  wrote:
>Hetzner maintains this issue to be a "bug in NetBSD", while we might try
>and convey a position that they are using configurations that are "less
>portable".

I don't think we can claim that their configuration is "less portable",
q35 has been in qemu since 2017.

Does using -machine q35 with qemu to boot NetBSD give the same results
as seen with a Hetzner VPS?

Re: i915 observations (UXA attempt)

[Robert Swindells]

Frank Kardel  wrote:
>Sadly no luck here. I blindly used X -configure, removed references to 
>the NVIDIA card,
>
>set Option "AccelMethod" "UXA" and started kdm.
>
>When startingI was greeted with:
>
>[89.357] (II) IGLX: Loaded and initialized swrast
>[89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0
>[89.357] (II) Initializing extension XFree86-VidModeExtension
>[89.358] (II) Initializing extension XFree86-DGA
>[89.358] (II) Initializing extension XFree86-DRI
>[89.358] (II) Initializing extension DRI2
>[89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer 
>object does not match constraints: size=8388608, must be greater than 
>8294400, but less than 4194304
>[89.361] (EE)
>
>and in my simple world is it hard to provide a solution for 8294400 < X 
>< 4194304.

The 4194304 number is derived from the AGP aperture size.

Is this on NetBSD/amd64 or NetBSD/i386?

Re: FYI: new X server in -current, among other X things

[Robert Swindells]

Martin Husemann  wrote:
>
> Does anyone happen to have firefox-102.0.1nb1 installed and not yet
> updated the X server and Xlib?

Have rebuilt firefox-102.0.1, works fine with the old X stack.

Re: FYI: new X server in -current, among other X things

[Robert Swindells]

I wrote:
> It looks like not all the functions are getting setup in the glamor
> struct by load_glamor(), I'm guessing because those functions are
> not exported by libglamoregl.so.
>
> Do we need to add more source files to this:
>
> src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile

Adding all of the glamor modules to libglamoregl.so makes it stop
crashing for me.

Re: FYI: new X server in -current, among other X things

[Robert Swindells]

matthew green  wrote:
>
> with a normal build, you should at least be able to get
> a stack trace with function names, if not line numbers.

The last function name that I get is drmmode_init().

Comparing the updated source with the working version shows this:

 {
 #ifdef GLAMOR_HAS_GBM
 ScreenPtr pScreen = xf86ScrnToScreen(pScrn);
+modesettingPtr ms = modesettingPTR(pScrn);
 
 if (drmmode->glamor) {
-if (!glamor_init(pScreen, GLAMOR_USE_EGL_SCREEN)) {
+if (!ms->glamor.init(pScreen, GLAMOR_USE_EGL_SCREEN)) {
 return FALSE;
 }
 #ifdef GBM_BO_WITH_MODIFIERS
-glamor_set_drawable_modifiers_func(pScreen, get_drawable_modifiers);
+ms->glamor.set_drawable_modifiers_func(pScreen, 
get_drawable_modifiers);
 #endif
 }
 #endif

It looks like not all the functions are getting setup in the glamor
struct by load_glamor(), I'm guessing because those functions are
not exported by libglamoregl.so.

Do we need to add more source files to this:

src/external/mit/xorg/server/xorg-server/hw/xfree86/glamor_egl/Makefile

Re: FYI: new X server in -current, among other X things

[Robert Swindells]

I wrote:
>
>>> [   378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5]
>>> [   378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465]
>>> [   378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) 
>>> [0x75b46379c930]
>>> [   378.034] (EE) 
>>> [   378.034] (EE) Segmentation fault at address 0x0
>>> 
>>> This happens with ctwm as part of the base installation, as well as with
>>> other pre-existing window managers and such from pkgsrc built against
>>> 9.99.97.
>>
>>can you configure X to generate a core dump or run it
>>under GDB and get the real stack trace?  i thought we'd
>>fixed this problem in libexecinfo, but it's still not
>>tracing through the SEGV above, so finding what is
>>crashing where is what we need next.
>
>FWIW, I get the same on my Pinebook with a lima kernel, this may not be
>i915 specific.
>
>Doing a full debug build now.

Building with MKDEBUG=yes stops it crashing, but it also stops glamor
from working.

I guess it is back to printf().

Re: FYI: new X server in -current, among other X things

[Robert Swindells]

>> [   378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5]
>> [   378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465]
>> [   378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) 
>> [0x75b46379c930]
>> [   378.034] (EE) 
>> [   378.034] (EE) Segmentation fault at address 0x0
>> 
>> This happens with ctwm as part of the base installation, as well as with
>> other pre-existing window managers and such from pkgsrc built against
>> 9.99.97.
>
>can you configure X to generate a core dump or run it
>under GDB and get the real stack trace?  i thought we'd
>fixed this problem in libexecinfo, but it's still not
>tracing through the SEGV above, so finding what is
>crashing where is what we need next.

FWIW, I get the same on my Pinebook with a lima kernel, this may not be
i915 specific.

Doing a full debug build now.

Re: nouveau: back in text console after switch to graphical one

[Robert Swindells]

Thomas Klausner  wrote:
> Did either of you install any firmware files?

My one nouveau system is old enough that it doesn't need a firmware
file.

I needed to keep adding printf statements to the code until I found
out where it was going wrong. The "autoconfiguration" stage should be
early in the driver initialization.

Re: nouveau: back in text console after switch to graphical one

[Robert Swindells]

Paul Goyette  wrote:
>On Wed, 8 Jun 2022, Cygnus X-1 wrote:
>
>8< snip >8
>
>> I wonder if nouveau has been actually working for anybody on HEAD, or if
>>> the driver is in a completely broken state.  ...
>
>Yup. At least with 9.99.97 my nouveau is running great on my Geforce
>GTX 1050 Ti

Working fine for me too, but on a fairly old laptop.

I do have one local patch for my display. The nouveau code makes a guess
on which PCI BAR is for the display memory and which for the chip
registers, it gets it wrong on my system.

Non-HDMI audio

[Robert Swindells]

What do I need to do to get non-HDMI audio to work again?

% mixerctl -a -v
outputs.dacsel=HDMI00  { HDMI00 }

radeon0 at pci1 dev 0 function 0: vendor 1002 product 68f9 (rev. 0x00)
hdaudio0 at pci1 dev 0 function 1: HD Audio Controller
hdaudio0: interrupting at ioapic0 pin 19
hdaudio0: HDA ver. 1.0, OSS 1, ISS 0, BSS 0, SDO 1, 64-bit
hdafg0 at hdaudio0: vendor 1002 product aa01
hdafg0: HDMI00 2ch: Digital Out [Jack]
hdafg0: 2ch/0ch 32000Hz 44100Hz 48000Hz PCM16 AC3
audio0 at hdafg0: playback
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
hdaudio1 at pci0 dev 20 function 2: HD Audio Controller
hdaudio1: interrupting at ioapic0 pin 16
hdaudio1: HDA ver. 1.0, OSS 4, ISS 4, BSS 0, SDO 1, 64-bit
hdafg1 at hdaudio1: vendor 10ec product 0887
hdafg1: DAC00 2ch: Speaker [Jack] 
hdafg1: DAC01 2ch: HP Out [Jack]
hdafg1: DIG02 2ch: SPDIF Out [Built-In]
hdafg1: ADC03 2ch: Line In [Jack], Mic In [Jack]
hdafg1: ADC04 2ch: Mic In [Jack]
hdafg1: 2ch/2ch 32000Hz 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz PCM16 PCM20 PCM
24 AC3
audio1 at hdafg1: playback, capture, full duplex, independent
audio1: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
audio1: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording

It worked fine on 9.99.93.

Re: uvideo uvm_fault panic

[Robert Swindells]

Patrick Welche  wrote:
>Logged in to zoom.us using firefox on 9.99.96/amd64 from Tuesday and
>got the following panic:

I get a similar panic using mplayer on my Pinebook.

This is with some local pkgsrc patches to mplayer.

Re: well-supported card for new DRM?

[Robert Swindells]

Thomas Klausner  wrote:
>
>I got a Geforce GTX 1050 Ti and it works fine.
>
>However, the X server doesn't go higher than 1920x1080.  I tried
>playing around with xrandr but that didn't change anything.
>
>I see a line
>
>  resize called 1920 1080
>
>in the X.org log file. Where does that come from?

Seems to be from the xf86-video-nouveau driver in this source file:

  xf86-video-nouveau/dist/src/drmmode_display.c

Re: linux clone issue

[Robert Swindells]

Manuel Bouyer  wrote:
>I'm trying to run a binary-only linux program under NetBSD 9.2.
>From what I found, the binary was built on Ubuntu 16.04
>
>The program dies at at specific point and it seems to be a bug in our
>emulation:

  8992   8992 mylinuxprog CALL  set_robust_list(0x7f7ff7ef5a20,0x18)
  8992   8992 mylinuxprog RET   set_robust_list 0

This is doing futex stuff which isn't in -9, it doesn't work in -current
either but thorpej@ has an improved version on a branch.

Re: lang/mono or futex problem

[Robert Swindells]

Thomas Klausner  wrote:
>I've just tried updating the .net program 'torrentzip'
>(archivers/torrentzip) to the latest version. The current pkgsrc
>version can be run by calling 'mono' on it (the package installs a
>wrapper), but the updated version is a Linux binary.

[snip]

>But i'm not sure if that means there is a problem with futex() or if
>that is already in the error handling.

The futex() implementation in -current doesn't work correctly, so I
would suspect that first.

There is a newer version in the thorpej-futex branch, it works better
with Linux OpenJDK but still fails to wake up some threads when
expected.

Re: Problem reports for version control systems

[Robert Swindells]

Lloyd Parkes  wrote:
>The network is a 1Gb/s LAN through to a smaller NetBSD router running 
>NPF with MSS clamping enabled so that I can get Netflix. My ISP does not 
>use CGN for my IPv4 connection. My IPv6 connection is tunnelled through 
>to Hurricane Electric in Sydney, Australia.

Have you tried disabling IPv6 or explicitly connecting using IPv4 ?

I don't see any problems using IPv6 through NPF to update cvs but I have
native IPv6 and can use a 1500 byte MTU. I'm also using cvs.n.o instead
of anoncvs.n.o but they have adjacent IPv4 addresses.

I'm guessing that your IPv6 tunnel has a lower MTU than your IPv4
connection to your ISP.

Re: VirtualBox guest additions build failure

[Robert Swindells]

Chavdar Ivanov  wrote:
>I switched early today my VirtualBox NetBSD-current guest; as usual, I
>rebuilt the additions (it works without them, but it is better to have
>them - e.g. without them the X cursor is almost invisible). There are
>a couple of patches I always have to apply under -current, which I
>did; it failed further with an error due to implicit function
>declaration
>
>...
>src/VBox/Additions/common/VBoxGuest/VBoxGuest-netbsd.c:419:25: error:
>implicit declaration of function ‘config_found_ia’; did you mean
>‘config_found’? [-Werror=implicit-function-declaration]
>...
>
>I replaced all
>   -Werror-implicit-function-delcaration
>in Config.kmk with
>   -Wno-error=implicit-function-declaration

I wouldn't expect it to work with an undefined function, you will need
to replace the call to config_found_ia() with one to config_found() and
change the arguments, there are examples in the tree to copy.

Re: vether vs. tap, initialization order, etc

[Robert Swindells]

nia  wrote:
>I just updated our home router from 9.1 to -current because a
>roommate wanted to use wg(4).
>
>I use tap as a bridge endpoint for two NICs that are used for
>the LAN.
>
>I thought I'd be able to copy the configs and do a straightforward
>subtitution from tap to vether but this doesn't work.
>/etc/rc.d/network fails to "up" the bridge on boot.
>
>The bridge was previously initialized in /etc/ifconfig.tap0,
>like so, now /etc/ifconfig.vether0:
>
>create
>inet 10.0.1.1 netmask 255.255.255.0
>!brconfig bridge0 add $int add re1 add re2 up

If vether(4) is like other network devices then I would expect to have
to bring it up as well, I don't see anything in your ifconfig.vether0
to do that.

I have usually brought up the bridge explicitly in /etc/ifconfig.bridge0
rather than from brconfig(8) but don't know if it makes a difference.

Re: IPv6 default route flapping

[Robert Swindells]

Joerg Sonnenberger  wrote:
>On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
>> On Apr 20, 21:13, Joerg Sonnenberger wrote:
>> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
>> } > It seems as if what is happening, is that the router is sending RA's with
>> } > the source-link addr option, which isn't being added to the neighbour
>> } > cache.
>> } > 
>> } > Then NetBSD is doing a NS to discover the address it ignored from the RA,
>> } > but instead of replying with a ND as would perhaps be expected, the 
>> router
>> } > is simply sending another RA (containing the relevant addr info, which 
>> would
>> } > answer the NS if processed).
>> } 
>> } I'm not entirely sure that the behavior of sending a RA as "answer" to a
>> } NS is valid under RFC 4861, but I also don't understand why the existing
>> } code (nd6_rtr_cache) doesn't cover this. That would be a good place to
>> } debugging this.
>> } 
>> } > I'd suggest putting RA processing back into the kernel to avoid this kind
>> } > of issue.
>> } 
>> } Except of course that it introduces back all the reasons for why it was
>> } removed in first place and ignores that it shouldn't happen.
>> 
>>  RA processing is fundamental to the operation of IPv6.  Removing
>> it was extremely stupid and not well thought out.  The decision
>> should be reverted.  I didn't have a problem with a sysctl to
>> disable it, but I have a huge problem with removing it completely.
>
>RA processing is not time-sensitive. It doesn't require any special
>interfaces. A correct and useful implementation requires non-trivial
>policy decisions. There are a lot of reasons for why it should not be
>part of the kernel and very few of why it should be. In fact, other
>systems never implemented it in the kernel or have similary moved it for
>pretty much the same reason.

One subsystem that made use of RA processing being in the kernel is
MobileIPv6, it used notifications from the kernel to work out that a
node has moved, I did get a suggestion from roy@ on an alternative way
to do this but haven't implemented it yet.

Think we need to make dhcpcd work with rump if it is the only way to do
RA processing.

Re: -current tar(1) breakage

[Robert Swindells]

Hauke Fath  wrote:
>On Sun, 28 Mar 2021 14:28:52 +0100, Robert Swindells wrote:
>> The unmodified package builds fine for me over NFS, with -current as
>> both client and server.
>
>Interesting. Is that net-booted, or just the pkgsrc tree over nfs?

Just pkgsrc over NFS.

Does your netbooted machine have a swapfile on NFS ?

Re: -current tar(1) breakage

[Robert Swindells]

On Fri, 26 Mar 2021 15:16:13 +0100, Hauke Fath wrote:
> building editors/xemacs-nox11 on a -current machine (net-booted, if it 
> matters) fails [...]

Have you stated anywhere in the thread what the NFS server is running ?

The unmodified package builds fine for me over NFS, with -current as
both client and server.

Robert Swindells

Re: firefox in VNC: firefox.core

[Robert Swindells]

I wrote:
>Thomas Klausner  wrote:
>>For a couple days/weeks now, whenever I start firefox
>>86.0.1/NetBSD-9.99.81/amd64 in a vnc window, I see:
>>
>>Crash Annotation GraphicsCriticalError: [0][GFX1-]: No GPUs detected via PCI 
>>(t=0.228558) [GFX-1]: No GPUs detected via PCI
>>Crash Annotation Graphicscriticalerror: [0][GFX1-]: No GPUs detected via PCI 
>>(t=0.228558) [1][GFX1-]: glxtest: process failed (received signal 11) 
>>(t=0.228639) [GFX1-]: glxtest: process failed (received signal 11)
>>
>>Except for that warning (and the core dump), firefox seems to work fine.
>
>The glxtest() function gets run in a forked copy of Firefox, it is the
>fork that is dumping core.
>
>Maybe our pthreads implementation doesn't work across a fork(2).
>
>I thought that use of TLS had been turned off in Mesa though.
>
>I had some local patches to disable all of this but the source changed
>so they would no longer apply, they disabled WebGL completely.

Another approach could be to patch Firefox to disable the call to
glxtest() but hard-code it to thinking that the test succeded.

Re: firefox in VNC: firefox.core

[Robert Swindells]

Thomas Klausner  wrote:
>For a couple days/weeks now, whenever I start firefox
>86.0.1/NetBSD-9.99.81/amd64 in a vnc window, I see:
>
>Crash Annotation GraphicsCriticalError: [0][GFX1-]: No GPUs detected via PCI 
>(t=0.228558) [GFX-1]: No GPUs detected via PCI
>Crash Annotation Graphicscriticalerror: [0][GFX1-]: No GPUs detected via PCI 
>(t=0.228558) [1][GFX1-]: glxtest: process failed (received signal 11) 
>(t=0.228639) [GFX1-]: glxtest: process failed (received signal 11)
>
>Except for that warning (and the core dump), firefox seems to work fine.

The glxtest() function gets run in a forked copy of Firefox, it is the
fork that is dumping core.

Maybe our pthreads implementation doesn't work across a fork(2).

I thought that use of TLS had been turned off in Mesa though.

I had some local patches to disable all of this but the source changed
so they would no longer apply, they disabled WebGL completely.

Re: -current tar(1) breakage

[Robert Swindells]

Hauke Fath  wrote:
>On Fri, 26 Mar 2021 14:38:08 +0000, Robert Swindells wrote:
>>> The workaround was to symlink /usr/pkg/bin/gtar to .tools/bin/tar. Is 
>>> there any pkgsrc magic for making gtar pose as tar(1), or am I on my 
>>> own?
>> 
>> You can put a line in the pkgsrc Makefile of:
>> 
>> EXTRACT_USING=  gtar
>
>I've seen (and used) EXTRACT_USING. But does this just cover extracts 
>by the pkgsrc framework, or also any invocations of tar by the 
>package's build system?

Don't know.

The package builds fine for me on -current, what is unusual about your
build host ?

Re: -current tar(1) breakage

[Robert Swindells]

Hauke Fath  wrote:
>building editors/xemacs-nox11 on a -current machine (net-booted, if it 
>matters) fails with

[snip]

>The workaround was to symlink /usr/pkg/bin/gtar to .tools/bin/tar. Is 
>there any pkgsrc magic for making gtar pose as tar(1), or am I on my 
>own?

You can put a line in the pkgsrc Makefile of:

EXTRACT_USING=  gtar

or:

EXTRACT_USING=  bsdtar

I think the 'bsdtar' option will build it from pkgsrc not use tar(1)
from the base OS.

Re: extra files in DESTDIR

[Robert Swindells]

Bch  wrote:
>
>I've been getting this (and worse) for a while, and just living with it:
>
>===  1 extra files in DESTDIR  =
>Files in DESTDIR but missing from flist.
>File is obsolete or flist is out of date ?
>--
>./usr/libexec/ld.elf_so
>=  end of 1 extra files  ===
>
>It *was* worse when I had errant cvs tags in effect, and so part
>of the tree was updated differently than the rest, but thats sorted
>out now.

I think your tree is still messed up.

That file should be a symlink to /libexec/ld.elf_so, what is it in the
DESTDIR that you have built ?

The flist entry should be the final line of
src/distrib/sets/lists/base/shl.mi.

Re: WireGuard in NetBSD

[Robert Swindells]

Taylor R Campbell  wrote:
>Back in 2018, ozaki-r@ wrote an in-kernel implementation of WireGuard
> for NetBSD -- a point-to-point roaming-
>capable virtual private network tunnel with modern cryptography.

Does it work for IPv6 ?

Wondering if it might be used instead of ipsec as the signalling
channel for MobileIPv6.

Re: Strange behavior with CVS

[Robert Swindells]

Arthur Barlow  wrote:
>I'm using amd64 current 9.99.69.  I noticed recently that when I update src
>with "cvs -q update -dP", that sometimes the screen will freeze.  I run X
>with gkrellm and I notice all the monitors freeze.  Also during this time
>there doesn't seem to be any transmission through the router as no lights
>flash.  If I walk away for a few minutes, it eventually comes back, but
>I've never seen this behavior before.

Is the filesystem that your CVS tree is on mounted with the 'log'
option ?

Re: Failure to build gobject-introspection

[Robert Swindells]

I wrote:
>What is wrong with the idea that you have run out of memory ?

OTOH, running top(1) at the same time as building it doesn't show
any particularly large processes.

Re: Failure to build gobject-introspection

[Robert Swindells]

Riccardo Mottola  wrote:
>m...@netbsd.org wrote:
 distutils.errors.CompileError: command 'cpp' terminated by signal 11
>>> Usually any GCC crashes on widely used architectures are running out of
>>> RAM.
>> See  `dmesg |tail` to see some messages related to out-of-RAM GCC
>> components killed.
>
>dmesg does not report anything suspect since boot.. and I did try to 
>rerun the build twice, so I should see two crashes.
>The laptop has 4GB of ram and the same swap this even is enough to 
>build geck and more or less rust... what's with gobject?

What have you set MAKE_JOBS to ?

>any better ideas? :-)

What is wrong with the idea that you have run out of memory ?

Other people can build gobject-introspection fine, me included.

Re: build failure when optimizing

[Robert Swindells]

os...@fessel.org wrote:
> Am 24.05.2020 um 01:06 schrieb Tobias Nygren :
> 
> On Sat, 23 May 2020 22:25:55 +0200
> os...@fessel.org wrote:
> 
>> I just tried to build release with optimisation for my little xeon server.
>> That fails, but I don?t understand why it seems to build some 386 32bit libs.
> 
> You can build with MKCOMPAT=no to avoid this problem if you don't need
> 32-bit compatibility libs.

>Thanks again, MKCOMPAT really is case-sensitive, so no is better than
>NO, but nevertheless, im still not getting through the build process:

[snip]

>how comes?  And what can I do?

You could just use the default compiler settings, I wouldn't expect it
to make much difference on x86_64.

Maybe try this (not tested):

Index: Makefile
===
RCS file: /cvsroot/src/libexec/ld.elf_so/Makefile,v
retrieving revision 1.143
diff -u -r1.143 Makefile
--- Makefile9 Feb 2020 09:11:59 -   1.143
+++ Makefile26 May 2020 21:31:22 -
@@ -51,7 +51,7 @@
 LDFLAGS+=  -Wl,--warn-shared-textrel
 LDFLAGS+=  -Wl,-Map=${.TARGET}.map
 
-COPTS+=-fvisibility=hidden
+COPTS= -fvisibility=hidden
 
 # Adds SRCS, CPPFLAGS, LDFLAGS, etc.  Must go first so MD startup source
 # is first.

Re: Problem with Linux emulation [was Re: CVS commit: src/sys]

[Robert Swindells]

On Apr 27, 2020, at 8:50 AM, Thomas Klausner  wrote:
> 
> I think this commit broke lang/oracle8-jre:

Linux Java doesn't crash now for me but doesn't do much, top(1) shows it
to be waiting on a futex.

Tried doing "java -version" and running larger things.

Re: Problem with Linux emulation [was Re: CVS commit: src/sys]

[Robert Swindells]

Jason Thorpe  wrote:
>> On Apr 27, 2020, at 8:50 AM, Thomas Klausner  wrote:
>> 
>> I think this commit broke lang/oracle8-jre:
>
>This is a Linux binary running under COMPAT_LINUX?  It would be strange
>if it broke it because it essentially makes the whole system do what the
>Linux emulation was already doing.

Has anything changed around where the initial stack gets put in VM ?

The Linux build of OpenJDK uses this to work out whether it is using
the initial thread or another one.

Re: build failure in libz

[Robert Swindells]

Martin Husemann  wrote:
>On Wed, Apr 22, 2020 at 09:27:44PM +0900, Rin Okuyama wrote:
>> Seems fixed now. Thank you!
>
>No quite sure what happened, but every file affected by the re-adding
>that was from a vendor branch and unchanged on the wifi branch got
>its default branch set to trunk (instead of the vendor branch).

Do we need to do anything special to fix it in our checked out trees, or
will just a 'cvs update' do it ?

Re: init's MAKEDEV vs. postinstall fix (old tty nodes)

[Robert Swindells]

On 2020-03-27 07:36, Thomas Klausner wrote:


With a tmpfs /dev init calls:

 "MAKEDEV -MM init"

(see sbin/init/init.c starting from line 1704)

which calls
makedev all opty

of which opty does

opty)
# Create 16 device nodes, [pt]typ0 to [pt]typf
...
mkdev ttyp$j c 5 $jn 666
mkdev ptyp$j c 6 $jn 666


On the other hand, "postinstall fix" does:

ptyfsoldnodes fix:
Removed legacy device node /dev/ptyp0
...
Removed legacy device node /dev/ttypf


So my question is: if "postinstall fix" removes these devices on an
upgrade, why does init still create them?

This looks inconsistent. Which of the two should be changed?


Maybe not change either.

Running 'postinstall check' on a system that isn't using ptyfs doesn't 
flag the legacy
nodes as needing deleting. I don't use ptyfs, and haven't tried telling 
postinstall to

fix things other than those that 'postinstall check' recommends.

Does the tmpfs /dev have a ptyfs mounted below it at the time MAKEDEV is 
run ?

Re: xen & uefi

[Robert Swindells]

Patrick Welche  wrote:
>On Fri, Mar 20, 2020 at 10:11:13AM -0400, Brad Spencer wrote:
>> Patrick Welche  writes:
>> 
>> > Is booting into xen from uefi meant to work?
>> >
>> > I have a slightly unorthdox set up, but get:
>> >
>> >>> NetBSD/x86 EFI Boot (x64), Revision 1.1 (Tue Jan 28 13:49:42 UTC 2020) 
>> >>> (from)
>> > ...
>> > Start @ 0xce60 [1=0xce982000-0xce9820ec]...
>> > Trampoline space cannot be allocated; will try fallback.
>> 
>> I didn't think that a DOM0 + UEFI worked anywhere very well at this
>> point or at least was not a default...
>> 
>> See https://wiki.xenproject.org/wiki/Xen_EFI for example...
>> or ... https://ubuntuforums.org/showthread.php?t=2413434

>Thanks - that makes more sense. From boot(8)
>
>multiboot kernel [arguments]
>   Boot the specified kernel, using the "multiboot" protocol
>   instead of the native NetBSD boot protocol...

The man page doesn't really describe the different things that could
happen.

The old 32-bit bootloader used the older multiboot protocol to talk to
a kernel.

There is multiboot2 support in efiboot, it will be running in 64-bit
mode when it calls into whatever kernel it has been told to load.

>Would that be different to the "multiboot2" mentioned in
>
>  https://patchwork.kernel.org/patch/9572493/

Yes, that is a patch to get Linux to work when loaded by a multiboot2
bootloader.

You care about what support is in Xen for this, which could also depend
on how pkgsrc builds the xen kernel.

Whichever bootloader is used it won't call into the DOM0, only the Xen
kernel.

Build failure

[Robert Swindells]

Is anyone else having problems doing a clean build ?

It is stopping for me in src/lib/libtelnet with this:

#create  libtelnet/sra.d
CC=/u8/build/aarch64-tools/bin/aarch64--netbsd-gcc /u8/build/aarch64-tools/bin/n
bmkdep -f sra.d.tmp  --   -std=gnu99   --sysroot=/var/obj/aarch64 -DHAS_CGETENT
-I/u1/src/lib/libtelnet -DENCRYPTION -DAUTHENTICATION -DDES_ENCRYPTION -DKRB5 -D
SRA /u1/src/lib/libtelnet/sra.c &&  mv -f sra.d.tmp sra.d
/u1/src/lib/libtelnet/sra.c:51:10: fatal error: security/pam_appl.h: No such fil
e or directory
 #include 
  ^

The $DESTDIR/usr/include/security directory isn't populated at this
point.

This was with -j 10 if that makes a difference.

Robert Swindells

Re: Panic on aarch64

[Robert Swindells]

Andrew Doran  wrote:
>On Tue, Mar 03, 2020 at 10:03:38PM +0000, Robert Swindells wrote:
>> 
>> I just got this:
>> 
>> panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool
>> cpu0: Begin traceback...
>> trace fp ffc0405efc90
>> fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160
>> fp ffc0405efd20 panic() at ffc000240974 netbsd:panic+0x44
>> fp ffc0405efdb0 pool_cache_put_paddr() at ffc00023e858 
>> netbsd:pool_cache_put_paddr+0x110
>> fp ffc0405efde0 vrelel() at ffc00028b058 netbsd:vrelel+0x208
>
>What file systems do you have in use?

It is using ffs, msdosfs,tmpfs, kernfs, procfs & nfs.

It was just reading from the main ffs partition when it paniced.

Can plug the eMMC into an extender and check it on another machine if it
will help.

Panic on aarch64

[Robert Swindells]

I just got this:

panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool
cpu0: Begin traceback...
trace fp ffc0405efc90
fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160
fp ffc0405efd20 panic() at ffc000240974 netbsd:panic+0x44
fp ffc0405efdb0 pool_cache_put_paddr() at ffc00023e858 
netbsd:pool_cache_put_paddr+0x110
fp ffc0405efde0 vrelel() at ffc00028b058 netbsd:vrelel+0x208
fp ffc0405efe20 vrecycle() at ffc00028b90c netbsd:vrecycle+0x6c
fp ffc0405efe50 vdrain_thread() at ffc00028bf54 
netbsd:vdrain_thread+0x2ac
address 0x100 is invalid
address 0xe8 is invalid
cpu0: End traceback...

I didn't have it set to enter ddb on panic and don't have enough swap
on the eMMC disk to dump to.

Have enabled DDB now.

Re: USB deadlock?

[Robert Swindells]

Thomas Klausner  wrote:
>I'm doing my backups to USB disks. Last month this worked fine, with
>9.99.48/amd64 the backup process (unison) hung twice, only
>force-reboot got me out of the first one.
>
>The process is hung in ps "D+". top says "uvn_fp".

I don't have an answer to the hang but had been meaning to submit a
patch for review that might help with tracking it down.

There are two candidates for this wait point but the first six
characters of the names are the same, I just took out one character
so that top(1) could tell them apart.

I haven't seen any problems using it.

Index: uvm_vnode.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.107
diff -u -r1.107 uvm_vnode.c
--- uvm_vnode.c 27 Feb 2020 22:12:54 -  1.107
+++ uvm_vnode.c 3 Mar 2020 12:49:55 -
@@ -314,7 +314,7 @@
return 0;
}
rw_exit(uobj->vmobjlock);
-   uvm_wait("uvn_fp1");
+   uvm_wait("uvnfp1");
uvm_page_array_clear(a);
rw_enter(uobj->vmobjlock, RW_WRITER);
continue;
@@ -339,7 +339,7 @@
UVMHIST_LOG(ubchist, "wait %#jx (color %ju)",
(uintptr_t)pg, VM_PGCOLOR(pg), 0, 0);
UVM_UNLOCK_AND_WAIT_RW(pg, uobj->vmobjlock, 0,
-  "uvn_fp2", 0);
+  "uvnfp2", 0);
uvm_page_array_clear(a);
rw_enter(uobj->vmobjlock, RW_WRITER);
continue;

Re: Display glitches with radeon display

[Robert Swindells]

Thomas Klausner  wrote:
>On Wed, Feb 19, 2020 at 03:51:55PM +0000, Robert Swindells wrote:
>> 
>> Is anyone else seeing black boxes and distorted bitmap text when using
>> an older radeon display in -current.
>> 
>> I last updated this machine in early Jan and everything was fine then.
>
>No, but for me mpv doesn't like the default method any longer, I need
>to switch to 'xv' to make it play videos.

Playing videos works fine for me with mplayer.

What do you mean by the "default method" ?

I do have local changes to mplayer and libv4l but I don't think they
would make a difference.

This is on NetBSD/amd64, I didn't mention that in the original email.

Display glitches with radeon display

[Robert Swindells]

Is anyone else seeing black boxes and distorted bitmap text when using
an older radeon display in -current.

I last updated this machine in early Jan and everything was fine then.

Re: userland build failure in libgomp

[Robert Swindells]

Riccardo Mottola  wrote:
>I confirm the peristent build failure, even if starting totally from 
>scratch (clean obj dir) and no -u flag.
>Built tools first, then distribution. Same error, on amd64
>
>could it be that the combination
>MKLLVM = no
>HAVE_LLVM=no
>MKLLVMRT = no
>
>is not supported?

You could test this by building without those options, you should get a
gcc toolchain.

I use MKLLVMRT=no for several architectures and did a full build a
couple of days ago.

You also shouldn't need to build the tools as a separate step, just do a
clean build of the distribution target. Delete the old tools first.

Re: failure to build current on amd64

[Robert Swindells]

Greg Troxel  wrote:
>Edgar Pettijohn  writes:
>
>> I have tried the MKXXX=NO for lots of stuff and they always fail, so
>> I'm not sure what the correct way to use them is.
>
>I suspect that they fail because they are non-deafult.   The right way
>is to debug them and send a patch :-)   But seriously, reporting
>problems is helpful.

I use a mix of them on different architectures to speed up the build and
they seem to work. I'm not seeing clang built for amd64.

Is the test for the value case-sensitive ? 

Re: build fails for amd64, i386 kernels w/legacy DRM (UMS) support

[Robert Swindells]

"John D. Baker"  wrote:
>Kernels w/o DRMKMS but with the older DRM UMS drivers fail with:
>
>[...]
>#  link  VERTHANDI/netbsd
>/r0/build/current/tools/amd64/bin/i486--netbsdelf-ld -Map netbsd.map --cref -T 
>netbsd.ldscript -Ttext c010 -e start -X -o netbsd 
>${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
>/r0/build/current/tools/amd64/bin/i486--netbsdelf-ld: drm_stub.o: in function 
>`drm_ioctl':
>/x/current/src/sys/external/bsd/drm2/drm/drm_stub.c:41: multiple definition of 
>`drm_ioctl'; 
>drm_drv.o:/x/current/src/sys/external/bsd/drm/dist/bsd-core/drm_drv.c:962: 
>first defined here
>*** [netbsd] Error code 1

>I noticed the following commit:
>
>  http://mail-index.netbsd.org/source-changes/2019/11/16/msg110862.html
>
>Can this be adjusted to accomodate legacy DRM?

Does this work ?

Index: files.drmkms
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/drm/files.drmkms,v
retrieving revision 1.31
diff -u -r1.31 files.drmkms
--- files.drmkms16 Nov 2019 04:10:33 -  1.31
+++ files.drmkms18 Nov 2019 16:42:00 -
@@ -100,4 +100,4 @@
 file   external/bsd/drm2/dist/drm/drm_trace_points.c   drmkms
 file   external/bsd/drm2/drm/drm_vm.c  drmkms
 file   external/bsd/drm2/drm/drm_vma_manager.c drmkms
-file   external/bsd/drm2/drm/drm_stub.c!drmkms
+file   external/bsd/drm2/drm/drm_stub.c!drmkms & !drmbase

Re: self-hosting on small-ish i386 boxen?

[Robert Swindells]

"John D. Baker"  wrote:
>The combination of LLVM 10.0 and GCC 8 on i386 makes self-hosting on at
>least one i386 machine challenging.

Which GPU ?

If it isn't a radeon then you might want to try with MKLLVMRT=no.

Re: xfwm4 crashes on NetBSD 9.99.17 (was "Re: firefox dumping core after NetBSD upgrade")

[Robert Swindells]

"David H. Gutteridge"  wrote:
>On Wed, 2019-10-16 at 12:10 +0100, Chavdar Ivanov wrote:
> On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge  > wrote:
> 
> > FWIW, aside from Firefox (where I also see this issue), I've found
> > since the recent Mesa upgrade, Xfce4's window manager consistently
> > crashes during startup. These's a correlation with Firefox in the
> > backtrace:
> >
> > #3  0x79f26fa5e256 in _mesa_GetString (name=7937) at
> > /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/getstring.c:124
> > ctx = 0x79f288ae5898
> > vendor = 0x79f271833414 "Brian Paul"
> > renderer = 0x79f2718214ab "Mesa"
> > #4  0x0041b1b5 in ?? ()
> > No symbol table info available.
> > #5  0x00442bb8 in ?? ()
> > No symbol table info available.
> > [...]

If you still have the core dump for this, or can generate another, it
could be helpful to examine the ctx variable in _mesa_GetString() using
gdb.

If it is like firefox then I think you will find that not all of the
structure is in mapped memory.

Can only think of two ways this could happen, either the ctx pointer
itself is garbage or the size given to calloc() to allocate the context
was too small. Have been trying to work out where this gets allocated
but not found it yet.

I have got some patches to firefox that let me display Google Maps but
they basically just disable the use of OpenGL.

Re: xfwm4 crashes on NetBSD 9.99.17 (was "Re: firefox dumping core after NetBSD upgrade")

[Robert Swindells]

Chavdar Ivanov  wrote:
>On Sun, 27 Oct 2019 at 16:25, Robert Swindells  wrote:
>>
>> Chavdar Ivanov  wrote:
>> >I do not have MesaLib installed on this v/b guest at all.
>>
>> Are you running modular or native xorg ?
>
>Native.

Ok, so either you have MesaLib from xsrc installed or you have deleted
it yourself.

Re: xfwm4 crashes on NetBSD 9.99.17 (was "Re: firefox dumping core after NetBSD upgrade")

[Robert Swindells]

Chavdar Ivanov  wrote:
>I do not have MesaLib installed on this v/b guest at all.

Are you running modular or native xorg ?

Re: current kernel crashes while building userland

[Robert Swindells]

Riccardo Mottola  wrote:
>On 24/10/2019 22:06, Robert Swindells wrote:
>> You maybe need some changes to the ata disk driver that went in on the
>> 23rd.
>
>bad luck. I upgraded kernel and modules, installed and it crashes during 
>userland build, so no progress at all.
>
>Still a crash in compat_90_sys_fstatvfs1() at compat_90_sys_fstatvfs1
>
>Could it be that it is actually a compatibility issue, where userland 
>calls somethingin the kernel that crashes? I wonder that it is compat_90

The recommended build process is to do the userland first then use the
new toolchain to build the kernel.

This is a clean build isn't it ? The amd64 port switched to gcc 8.3 on
the 22nd.

Re: current kernel crashes while building userland

[Robert Swindells]

Riccardo Mottola  wrote:
>I upgraded to 9.99.17 22nd October. I built kernel + modules, rebooted.
>on amd64
>
>Then I started a distribution build... and after some hours, the machine 
>resets.
>I restarted again (without doing an update build)... and it reboots again.
>
>I just find the machine rebooted, I can't read any message.
>
>in /var/crash however I find the two gzipped files, too big to post 
>public here. Each crash has its own.
>
>Can I send them somebody? How can I give more information?
>
>This machine is running netbsd current since a long time and has always 
>been very stable (many other issues, but never reboots during builds)

You maybe need some changes to the ata disk driver that went in on the
23rd.

Also you could look at a description of how to use gdb on crash dumps
here:

Re: built-in vs loadable modules and userconf

[Robert Swindells]

Rhialto  wrote:
>On Sat 19 Oct 2019 at 08:16:02 -0700, Paul Goyette wrote:
>> If the module is built-in, it will never be loaded from the *.kmod file.
>> But as I pointed out above, disabling in userconf does NOT disable the
>> module, and does not prevent the module's initialization code from
>> executing.
>
>Side-thought: maybe userconf can benefit from a way to disable modules?

Not quite what you are asking for but I have local patches to the
bootloader to allow autoloading to be disabled from boot.conf.

Re: firefox dumping core after NetBSD upgrade

[Robert Swindells]

I wrote:
>>>From the stack trace that Paul Goyette provided it looks to me like
>>>a Firefox bug is triggering one in Mesa.
>>
>>I have now got a debug system and firefox build with debug-info, a
>>firefox build with debug wouldn't display an URL.
>>
>>I commented out the locking code to see what happened:
>
>Commented out some more debug testing code in errors.c.
>
>It now crashes in _mesa_error when doing this:
>
>   /* Set the GL context error state for glGetError. */
>==>if (ctx->ErrorValue == GL_NO_ERROR)
>  ctx->ErrorValue = error;
>
>Trying to examine ctx->ErrorValue in gdb fails as it is an invalid
>address. I can examine fields of ctx that are nearer the start of
>the structure. The DebugMutex field is after ErrorValue.

The value of ctx has been retrieved from TLS, but Firefox has done a
fork() just before running the glxtest() function.

Is there something that Firefox should be doing to clear the TLS
after the fork ?

Re: firefox dumping core after NetBSD upgrade

[Robert Swindells]

I wrote:
>>From the stack trace that Paul Goyette provided it looks to me like
>>a Firefox bug is triggering one in Mesa.
>
>I have now got a debug system and firefox build with debug-info, a
>firefox build with debug wouldn't display an URL.
>
>I commented out the locking code to see what happened:

Commented out some more debug testing code in errors.c.

It now crashes in _mesa_error when doing this:

   /* Set the GL context error state for glGetError. */
==>if (ctx->ErrorValue == GL_NO_ERROR)
  ctx->ErrorValue = error;

Trying to examine ctx->ErrorValue in gdb fails as it is an invalid
address. I can examine fields of ctx that are nearer the start of
the structure. The DebugMutex field is after ErrorValue.

The gl_context struct is included in a GPU specific context struct,
so the allocation of it needs to be done by the driver.

I'm using a radeon GPU, do some GPU families work ?

Re: firefox dumping core after NetBSD upgrade

[Robert Swindells]

I wrote:
>From the stack trace that Paul Goyette provided it looks to me like
>a Firefox bug is triggering one in Mesa.

I have now got a debug system and firefox build with debug-info, a
firefox build with debug wouldn't display an URL.

I commented out the locking code to see what happened:

Index: errors.c
===
RCS file: /cvsroot/xsrc/external/mit/MesaLib/dist/src/mesa/main/errors.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 errors.c
--- errors.c24 Sep 2019 18:10:11 -  1.1.1.4
+++ errors.c15 Oct 2019 10:57:17 -
@@ -306,6 +306,7 @@
 
do_output = should_output(ctx, error, fmtString);
 
+#if 0
simple_mtx_lock(>DebugMutex);
if (ctx->Debug) {
   do_log = _mesa_debug_is_message_enabled(ctx->Debug,
@@ -318,6 +319,9 @@
   do_log = GL_FALSE;
}
simple_mtx_unlock(>DebugMutex);
+#else
+   do_log = GL_FALSE;
+#endif
 
if (do_output || do_log) {
   char s[MAX_DEBUG_MESSAGE_LENGTH], s2[MAX_DEBUG_MESSAGE_LENGTH];


The it now crashes here (also errors.c):

static GLboolean
should_output(struct gl_context *ctx, GLenum error, const char *fmtString)
{
   static GLint debug = -1;

   /* Check debug environment variable only once:
*/
   if (debug == -1) {
  const char *debugEnv = getenv("MESA_DEBUG");

#ifdef DEBUG
  if (debugEnv && strstr(debugEnv, "silent"))
 debug = GL_FALSE;
  else
 debug = GL_TRUE;
#else
  if (debugEnv)
 debug = GL_TRUE;
  else
==>  debug = GL_FALSE;
#endif

Is there some problem with writing to static variables defined in a
shlib ?

I also think that it is a bug in Firefox for it to be triggering this
assertion:

 ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, NULL);

It is within a call to glGetString(GL_VERSION) in glxtest().

Re: i386 9.99.17 build fails for NET4501 kernel

[Robert Swindells]

"John D. Baker" 
>Building the NET4501 kernel with 9.99.17 sources fails with:
>
>/x/current/src/sys/arch/x86/x86/vm_machdep.c: In function 'cpu_lwp_fork':
>/x/current/src/sys/arch/x86/x86/vm_machdep.c:134:21: error: variable 'pcb2' 
>might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered]
>  struct pcb *pcb1, *pcb2;
> ^~~~

My custom amd64 kernels fail too, there was a failure report from
someone else but it doesn't seem to be in the archive yet.

The amd64 GENERIC config does build though.

Re: firefox dumping core after NetBSD upgrade

[Robert Swindells]

m...@netbsd.org wrote:
>On Sat, Oct 12, 2019 at 10:49:58AM +0100, Robert Swindells wrote:
>> 
>> m...@netbsd.org wrote:
>> >
>> >Firefox works great. The discussion here isn't about firefox being
>> >broken on netbsd, it's being broken across an update. That usually
>> >happens due to some kind of binary incompatibility being introduced.
>> 
>> I'm not sure this is down to a binary incompatibility.
>> 
>> I started seeing the same thing recently too even when Firefox and all
>> its dependencies have been rebuilt from source.
>> 
>> Google Maps triggers it for me.
>
>You've also stated that glxgears crashes, so it might be the same
>problem.  Are you building netbsd in a special way?

I only get crashes from glxgears on aarch64, it works fine on the
amd64 desktop machine that I'm running Firefox on.

>From the stack trace that Paul Goyette provided it looks to me like
a Firefox bug is triggering one in Mesa.

The crash is within _mesa_error() but this is called because of an
assertion near the start of _mesa_GetString().

_mesa_GetString( GLenum name )
{
   GET_CURRENT_CONTEXT(ctx);
   static const char *vendor = "Brian Paul";
   static const char *renderer = "Mesa";

   if (!ctx)
  return NULL;
   
   ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL(ctx, NULL);

Re: firefox dumping core after NetBSD upgrade

[Robert Swindells]

m...@netbsd.org wrote:
>On Sat, Oct 12, 2019 at 08:41:49AM +0100, Sad Clouds wrote:
>> On Fri, 11 Oct 2019 11:05:57 -0700
>> bch  wrote:
>> 
>> > I quit running Firefox on my (-current) laptop months ago because the
>> > build process (rust, esp) was so brutal. Have there been any
>> > community efforts to organize the build artifacts from bleeding-edge
>> > environments to avoid repeating (and failing, in my case) this most
>> > horrible build?
>> 
>> What's the alternative, I've not used NetBSD for desktop tasks for a
>> while now, but I wish recent Opera browser was available for NetBSD. I
>> suppose you could run it with Linux emulation, but not sure how well it
>> works on NetBSD. Last time I tried, which was years ago, there were
>> some display issues, i.e. scrolling text up/down would produce these
>> annoying lagging artefacts, etc.
>
>Firefox works great. The discussion here isn't about firefox being
>broken on netbsd, it's being broken across an update. That usually
>happens due to some kind of binary incompatibility being introduced.

I'm not sure this is down to a binary incompatibility.

I started seeing the same thing recently too even when Firefox and all
its dependencies have been rebuilt from source.

Google Maps triggers it for me.

Re: retiring arm oabi support for new things

[Robert Swindells]

matthew green  wrote:
>netbsd 9 will ship without any targets with oabi as the
>default, and most of the existing ports were already
>switched to eabi (epoc32 and acorn32 only.)
>
>as part of this, i'm going to stop providing the ability
>to build any arm with oabi -- turn off the MKCOMPAT for
>all arm ports, so the oabi libraries are not provided
>anymore, turn off the oabi ld.elf.so, etc.

Are you going to change the compiler target name as part of this ?

I'm currently struggling with an autoconf script that is getting
confused by the -eabihf part of the armv7--netbsdelf-eabihf name.

I have been building arm targets with MKCOMPAT=no for a long time now so
no problem with the proposed change.

Re: Can't set volume options during install?

[Robert Swindells]

Martin Husemann  wrote:
>On Fri, Aug 23, 2019 at 06:13:30PM +, John Klos wrote:
>> How are people supposed to set the block and fragment sizes in the NetBSD
>> installer? If it's still possible, it certainly isn't easy to find.
>
>Is it usefull anywhere?

What do they default to ?

>But is it really needed?

Someone using a disk with 4k blocks might want to set the fragment size
to that and the block size to a multiple.

Re: 'postinstall' vs local configuration: how to preserve automatically?

[Robert Swindells]

"John D. Baker"  wrote:
>On Fri, 2 Aug 2019, Robert Swindells wrote:
>
>> >  /var/chroot/spamd
>> 
>
>> If you have local changes to your source tree then the files under
>> src/distrib/sets/lists need to match that.
>> 
>> If the two files that are being removed are from outside your NetBSD
>> source tree then it might be worth renaming them so that they don't
>> match actual obsolete files.
>
>I only ever install "mail/spamd" from pkgsrc.  I have no local changes
>to my source trees regarding "spamd".  I didn't know it was ever created
>as part of the system build at some time in the past.

It was removed in 2005, according to the logs.

I would argue that this is a pkgsrc issue, mail/spamd should use
different pathnames from the older version that was in base.

>The "fontconfig"-related files/links ARE part of the base system build.
>Since base (xbase?) fontconfig is considered new enough to be used by
>packages in recent pkgsrc branches, I need to set the symbolic link for
>"../conf.avail/70-no-bitmaps.conf" in "/etc/fonts/conf.d" in order to
>print legible hardcopy of some web pages.

You are probably using pkgsrc fontconfig but that doesn't make a
difference here.

>At some time during the 8.99.* period, this link began to be declared
>obsolete and removed if "fix"ed.  Not too long ago, it started tripping
>up the "fontconfig" check, ISTR it threw up an "unknown file" complaint.
>
>(On netbsd-8, the 'postinstall' checks ignore the extra symlink.  However
>on netbsd-8, pkgsrc fontconfig is used and I can set its symbolic link
>for "../conf.avail/70-no-bitmaps.conf" appropriately without issue--even
>when updating pkgsrc fontconfig.)

I think the answer to this part is to remove the whole entry in xetc/mi
for 70-no-bitmaps.conf, it was only made part of the build for one day.

Re: 'postinstall' vs local configuration: how to preserve automatically?

[Robert Swindells]

"John D. Baker"  wrote:
>Recent-ish updates to 'postinstall' now cause more grief with local
>configuration than before.
>
>Specifially, in the past the "obsolete" check would declare
>
>  /var/chroot/spamd

Things get declared as obsolete when they are removed from the build,
the examples you give were part of the build at one point, postinstall
won't remove things that it doesn't recognize.

If you have local changes to your source tree then the files under
src/distrib/sets/lists need to match that.

If the two files that are being removed are from outside your NetBSD
source tree then it might be worth renaming them so that they don't
match actual obsolete files.

Re: NFS Mount error - 8.99.51 - ***new

[Robert Swindells]

Chavdar Ivanov  wrote:
>NFS server - 8.99.51 amd64, /etc/exports contains:
>
>/home/sysbuild/release -maproot=0:10 -network 192.168.0/24
>
>
>NFS client - an hour ago it was 8.99.50 from about a week ago and worked
>fine, I was able to NFS mount the release directory and perform the
>usual sysupgrade dance.
>
>Now the client and the server run exactly the same NetBSD version:
>
>uname -a
>NetBSD tarkus 8.99.51 NetBSD 8.99.51 (GENERIC) #49: Sun Jul 21 14:17:51
>BST 2019 
>sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
>amd64
>
>
>
>If I try to mount the same directory, now I get:
>
>~ mount /mnt/release
>mount_nfs: bad MNT RPC: RPC: Authentication error; why = Client
>credential too weak
>
>and it never exits or mounts anything.

Default /etc/group doesn't have anything for group 10, have you added it ?

What do you have in /etc/fstab for /mnt/release ?

I have updated some NFS clients to 8.99.51 but not done an NFS server
yet.

Re: run(4) fails to scan

[Robert Swindells]

Martin Husemann  wrote:
>On Mon, Jul 15, 2019 at 07:25:45PM +0200, Manuel Bouyer wrote:
>> Hello,
>> I'm trying to use this wifi USB adapter:
>> run0 at uhub7 port 1
>> run0: Ralink (0x148f) 802.11 n WLAN (0x5370), rev 2.00/1.01, addr 3
>> run0: MAC/BBP RT5390 (rev 0x0502), RF RT5592 (MIMO 1T1R), address 
>> e8:4e:e8:4e:af:44
>> run0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
>> run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>> run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
>> 36Mbps 48Mbps 54Mbps
>> 
>> (tested on 8.1 and HEAD).
>> wpa_supplicant doesn't find any AP (it finds dozens with the internal
>> wpi(4)) and wiconfig fails with:
>> rochebonne# wiconfig run0 -D
>> scanning .wiconfig: ioctl: Operation now in progress
>> 
>> (the same command with wpi0 finds 12).
>> 
>> Is anyone using such an adapter with NetBSD ?
>
>I have:
>
>run0 at uhub4 port 2
>run0: Ralink (0x148f) 802.11 n WLAN (0x5370), rev 2.00/1.01, addr 5
>run0: MAC/BBP RT5390 (rev 0x0502), RF RT5592 (MIMO 1T1R), address 
>3c:33:3c:33:70:96
>run0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
>run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
>36Mbps 48Mbps 54Mbps
>
>and it fails to scan as well.
>
>OpenBSD works fine, and there are quite a few differences for this variant
>in the driver.

Maybe try the patch here:



I had a patch based on a newer version of the OpenBSD driver in 2015 but
that got broken by a commit of code from FreeBSD.

Re: libva looks for non-existent hw-specific libraries?

[Robert Swindells]

"John D. Baker"  wrote:
>On Wed, 3 Jul 2019, Robert Swindells wrote:
>
>> "John D. Baker"  wrote:
>> >Seems my just-built 'vlc' exhibits the same issue.
>> 
>> That looks like a different issue to me.
>> 
>> You haven't got a VA-API driver.
>
>It would appear so.  The paths it is searching do not exist.  There
>is no "/usr/X11R7/lib/dri" nor "/usr/pkg/lib/dri".  There is a
>"/usr/X11R7/lib/modules/dri" but there are no "*_drv_video.so" files
>there.

>I take this to mean that pkgsrc/modular Xorg is required.

I don't think this is true.

Have you tried building multimedia/intel-vaapi-driver ?

Re: firefox52 crashes w/o coredump on -current (8.99.49)

[Robert Swindells]

"John D. Baker"  wrote:
>Seems my just-built 'vlc' exhibits the same issue.

That looks like a different issue to me.

You haven't got a VA-API driver.

Re: device-specific "vdpau" support?

[Robert Swindells]

Rhialto  wrote:
>On Sat 29 Jun 2019 at 20:55:16 +, m...@netbsd.org wrote:
>> Supposedly it's even more efficient video decoding, but I didn't do a
>> comparison (It would be pretty easy to do, since pkgsrc mesa does build
>> VDPAU).
>
>With the Linux I now have on my Pinebook, there are vdpau drivers for
>the graphics chipset, but no "regular" acceleration. As a result, video
>players can play 1080p videos perfectly, as long as you don't try to use
>anything GUI-ish, because that is still slow as molasses...

Linux on the Pinebook should be able to have accelerated graphics. You
may need to add some binary blobs for the GPU to enable it.

The Pinebook SoC has video decoder hardware that is separate from the
Mali GPU. We probably need to decide which API to support for it.

I suspect the efficiency depends on whether you are doing both decode
and display in hardware or GPU software or whether the main CPU is doing
the decode part.

Latest x11 has broken accelerated video playback on my one Intel GPU
system, it used to have a working XV driver.

Might be worth documenting which GPU models use particular acceleration
methods to know what has been tested.

Re: recurring tstile hangs on -current

[Robert Swindells]

Thomas Klausner  wrote:
>I've set up a new machine for bulk building. I have tried various
>things, but in the end it always hangs in tstile.
>
>First try was what I currently use: tmpfs sandboxes with nullfs
>mounted /bin, /lib, ... When it hung, the suspicion was that it's
>nullfs' fault. (The same setup works fine on my current machine.)
>
>The second try was tmpfs with copied-in /bin, /lib, ... and
>NFS-mounted packages/distfiles/pkgsrc (from localhost). That also
>hung. So the suspicion was that tmpfs or NFS are broken.
>
>The last try was building in the root file system, i.e. not even a
>sandbox (chroot). The only tmpfs is in /dev. distfiles/pkgsrc/packages
>are on spinning rust, / is on an ld@nvme. With 8 MAKE_JOBS this
>finished one pkgsrc build (where some packages didn't build because of
>missing distfiles, or because they randomly break like rust). When I
>restarted the bulk build with 24 MAKE_JOBS, it hung after ~4 hours.

Is a bulk build trying to make packages in parallel ?

If so, then I'm guessing that the multiple instances of cp(1) are
putting the package tarball into the same directory somewhere.

Re: aarch64 rust install failure

[Robert Swindells]

Ron Georgia  wrote:
>I have a Pinebook 1080P. I tried to build firefox on it and after three
>days of building I got the error listed below. I tried to install rustup
>but got an error; no evbarm. I added evbarm to the rust-init.sh switch
>statement. Another error I keep running into is libstdc++.so.8 not
>found.

This isn't really a problem with -current, rust bugs should go to
pkgsrc-us...@netbsd.org or raise a PR. You will probably get a better
response to ARM questions on port-arm too.

Someone needs to rebuild the bootstrap rust on a newer system to get
rid of the libstdc++ error. You shouldn't need to run rust-init.sh.

If you want a browser then firefox52 is easier to build on aarch64 as it
doesn't use rust. You will also want LIBRSVG_TYPE=c in /etc/mk.conf if
you go this route.

Re: What to do with base X11 for netbsd-9 ?

[Robert Swindells]

Patrick Welche  wrote:
>On Mon, Jun 10, 2019 at 05:36:37PM +0200, Michael van Elst wrote:
>> On Mon, Jun 10, 2019 at 03:42:10PM +0100, Patrick Welche wrote:
>> > It doesn't seem to help. Another difference is that consdev com0 works
>> > for the biosboot, but not for efiboot, which means I can't be sure
>> > where nouveau gets stuck.
>> 
>> Maybe EFI doesn't initialize com0. With e.g.
>> 
>> consdev com,0x3f8,9600
>> 
>> this is done by the bootloader and might work.
>
>I didn't notice a difference. When I run consdev, the screen clears
>and I get a new prompt, but still on the screen. (Tried with and without
>the 0x, and tried 2f8)
>
>I noticed that when pressing the power switch, the computer powered down
>immediately, so there is probably more to it than a happy computer with
>no screen display.

Does the keyboard work ? And can you choose which boot method is used
from the same installation ?

If the keyboard works you could use DDB to flush the dmesg to disk
before rebooting.

>From memory that is how I got nouveau working on one of my systems, it
would panic after clearing the screen.

Re: What to do with base X11 for netbsd-9 ?

[Robert Swindells]

Paul Goyette  wrote:
>I am curious why we need to apparently build all of the LLVM stuff for a
>release?  If LLVM is needed as part of the build, it should be built as
>host tools;  I don't understand why we _also_ need to build LLVM for the
>target machine.  (And, if the answer to this is YES, we should probably
>find a way to build-and-install a minimal subset, not the whole thing!)

LLVM generates code that runs on the GPU, it is only used on the target
machine.

It is already fairly stripped down, only a couple of the code generation
targets are built. I don't know if we could leave out X86 as well if
doing a gcc build.

It doesn't help that we build it twice for amd64, building with
MKCOMPAT=no will be faster.

Re: What to do with base X11 for netbsd-9 ?

[Robert Swindells]

Martin Husemann  wrote:
>I would like to get your feedback about the current state of the base X11,
>as there have been lots of threads about various issues and I have lost
>the overview of what works in -current and what does not.

>We *really* need to branch netbsd-9 very soon now, and it is unclear (at
>least to me) what should happen to the in-tree X11 version.

> - we have very obvious display bugs at first sight in xdm
> - self hosting builds on 4 GB amd64 machines are not really possible
>   any more (due to LLVM runtime dependencies, which can not even be
>   disabled at build time right now)
> - reports here (and on other lists) about display problems and success
>   stories have no clear winner (but probably due to me losing track)

>So what is you story/opinion: is base X11 usable in -current? If not,
>what needs to be done or what hardware needs fixes?

I'm typing this using radeon on -current, don't see any problems but
only have an old CEDAR GPU. Get errors on firefox startup of:

  libGL error: unable to load driver: r600_dri.so
  libGL error: driver pointer missing
  libGL error: failed to load driver: r600
  libGL error: unable to load driver: swrast_dri.so
  libGL error: failed to load driver: swrast

Intel - Only have an i915 machine, display itself seems fine but no
HW acceleration for video playback. Wondering if the driver expects a
different SW stack between the video player and itself. Video playback
was fine with both the older driver and the intel.old one.

NVidia - Only have an old laptop with an NV44. Seems to be using the
nouveau driver. Video playback works but looks like it is SW only.
Don't see any display problems, glxgears runs.

I don't use xdm on any of these systems. I just start X11 as a normal
user, did try starting it as root on my pinebook to verify a bug report
and got a black desktop instead of the standard pattern.

I did agree to try to update the radeon microcode in the tree but ran
into a problem that there are two versions of some files, one named in
uppercase the other lowercase, not tracked down yet how & why they
differ.

Re: Pinebook and NetBSD 8.99.39

[Robert Swindells]

On 2019-05-14 14:59, Ron Georgia wrote:

I just received my new 1080P 11inch (27.94 cm) Pinebook. It was
pre-loaded with Ubuntu and KDE. While I like KDE, it seems a bit
heavy. Ubuntu is ... ok, but I would rather have NetBSD and LXDE or
Mate. I attempted to install NetBSD but ran into some problems. Most
likely due to my incomplete understanding (see tag line below).


[snip]


Questions:
1. Is there a way to make the keyboard a standard keyboard?


Have you tried power cycling it ? I have seen the same problem a few
times.


2. Once booted, now do I "reflash" the internal drive to boot NetBSD
without having to boot from the micro SD card?


Just write the same image to the eMMC device that you put on the SD 
card, it

will resize on first boot.

Re: BFD .. invalid string offset .. for section `.strtab'

[Robert Swindells]

Mayuresh  wrote:
># uname -a
>NetBSD pi 8.99.37 NetBSD 8.99.37 (RPI2) #1: Thu Apr 25 16:01:51 UTC 2019
>root@pi:/usr/src/sys/arch/evbarm/compile/RPI2 evbarm
>
>BFD: /usr/pkg/lib/libpango-1.0.so.0: invalid string offset 12338 >= 11106 for 
>section `.strtab'
>BFD: /usr/pkg/lib/libfribidi.so.0: invalid string offset 1447 >= 1158 for 
>section `.strtab'

[snip]

Been like that for a while:



>Please advise.

Raise a PR.

Re: Jemalloc fallout on sandpoint

[Robert Swindells]

On 2019-04-09 01:26, Jason Thorpe wrote:

On Apr 8, 2019, at 2:40 PM, Julian Coleman  wrote:

Hi all,

Upgraded my QNAP TS-201 (sandpoint) to current, and all binaries crash 
with:


What kind of CPU is in this device?  It's possible that jemalloc is
making a page size assumption that isn't true for this particular
powerpc CPU (I think there were other issues like this on another
port...).


Do powerpc kernels have a sysctl for page size ? I'm fairly sure that 
arm does.

Re: VFS panic

[Robert Swindells]

"J. Hannken-Illjes"  wrote:
>> On 21. Feb 2019, at 00:18, Robert Swindells  wrote:
>> 
>> I'm getting a panic at startup on an evbearmv7hf-el system:

[snip]

>> This is a -current kernel from sources updated about an hour ago,
>> userland is a couple of days old.
>
>Please try again with sys/kern/vfs_trans.c Rev. 1.55

Works now, thanks.

VFS panic

[Robert Swindells]

I'm getting a panic at startup on an evbearmv7hf-el system:

...
Starting sshd.
Starting inetd.
Starting cron.
Wed Feb 20 21:23:46 GMT 2019
panic: kernel diagnostic assertion "mp != dead_rootmount" failed: file 
"../../../../kern/vfs_trans.c", line 680 
cpu1: Begin traceback...
0x9ac8dd54: netbsd:db_panic+0x14
0x9ac8dd6c: netbsd:vpanic+0x194
0x9ac8dd84: netbsd:__aeabi_uldivmod
0x9ac8ddbc: netbsd:vfs_suspend+0x1b8
0x9ac8dddc: netbsd:vrevoke_suspend_next+0x3c
0x9ac8de14: netbsd:vrevoke+0xc4
0x9ac8de24: netbsd:genfs_revoke+0x20
0x9ac8de4c: netbsd:VOP_REVOKE+0x40
0x9ac8df14: netbsd:dorevoke+0x94
0x9ac8df34: netbsd:sys_revoke+0x44
0x9ac8dfac: netbsd:syscall+0x12c
cpu1: End traceback...
Undefined instruction 0xe7ff in kernel at 0x80023534 (LR 0x80265358 SP 0x9ac
8dd58)
Stopped in pid 621.1 (getty) at netbsd:cpu_Debugger:und 0xe7ff
db{1}>

This is a -current kernel from sources updated about an hour ago,
userland is a couple of days old.

Re: openssl problem

[Robert Swindells]

Chavdar Ivanov  wrote:
>When I try to configure the self-signed certificate for nginx ...

Why not get a real certificate.

Re: upgrading via source from 7.1.2 dependencies

[Robert Swindells]

Greg Troxel  wrote:
>  [need xsrc to build]
>
>I am guessing that the tool build is trying to build some X tools, even
>if later they will not be used.  If this is right, I see two options for
>you
>
>1) conditionalize the tools build to not build the x tools if MKX11 is
>off.

It looks to be conditional to me.

src/tools/Makefile has:

.if ${MKX11} != "no" 
SUBDIR+=makestrs
SUBDIR+=makekeys
.endif

Re: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Robert Swindells]

"Thomas Mueller"  wrote:
>I may need to buy parts for a new computer because of malfunctions on
>current motherboard and CPU (Intel Sandy Bridge dating to May 2011).

[snip]

>I tried replacing the thermal paste and installing a new case fan to
>replace one that had quit, but CPU temperature still shows and stays at
>97 C.
>
>Now I have a replacement Arctic Cooler heatsink and fan on order to
>replace the original Intel heatsink and fan whose connectors were
>damaged in taking out and struggling to get back in.

I just replaced the original AMD heatsink on my main build machine with
an Arctic one and it is working really well. Maybe just try the new
cooler first.

I even had to turn off a BIOS alarm for low fan speed as the fan is off
most of the time.

# envstat
   Current  CritMax  WarnMax  WarnMin  CritMin  Unit
[aibs0]
  CPU FAN Speed: 0  7200  600RPM
  CHASSIS FAN Speed: 0  7200  600RPM
CPU Temperature:38.000   95.000   60.000degC
 MB Temperature:34.000   75.000   45.000degC
  Vcore Voltage: 0.9241.600  0.850 V
   +3.3 Voltage: 3.3243.630  2.970 V
 +5 Voltage: 5.0105.500  4.500 V
+12 Voltage:11.878   13.800 10.200 V
[amdtemp0]
   cpu0 temperature:20.000  degC

Re: build.sh distribution failure for evbarm

[Robert Swindells]

Chavdar Ivanov  wrote:
>With sources from about an hour ago I cannot complete distribution
>build for evbarm:
>---
>ymir% pwd
>/home/sysbuild/evbarm/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC
>ymir%  CC=/home/sysbuild/evbarm/tools/bin/arm--netbsdelf-eabi-gcc
   ^

What did you provide for the 'mach' parameter to build.sh ?

If you are building it to run on your Zynq system then you should set it
to evbearmv7hf-el.

Re: X server being killed a lot

[Robert Swindells]

Izumi Tsutsui  wrote:
>> Do we know what combination of things is causing X to be killed ?
>
>I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating
>4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images).

How is your X server configured ? Is it operating on a framebuffer in
main memory or VRAM on a separate graphics card ?

The sizes shown in top(1) for X on my system are smaller than several
other processes. This is with an AMD Radeon GPU with 1GB VRAM.

Re: X server being killed a lot

[Robert Swindells]

Izumi Tsutsui  wrote:
>> Izumi Tsutsui  wrote:
>> >> Do we know what combination of things is causing X to be killed ?
>> >
>> >I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating
>> >4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images).
>> 
>> How is your X server configured ? Is it operating on a framebuffer in
>> main memory or VRAM on a separate graphics card ?
>
>My machine has RADEON HD 5450 so it has own VRAM, I think

I think I have the same model.

>> The sizes shown in top(1) for X on my system are smaller than several
>> other processes. This is with an AMD Radeon GPU with 1GB VRAM.

I guess I'm not getting to the point where anything has been paged out:

Memory: 9017M Act, 1400M Inact, 9400K Wired, 345M Exec, 7679M File, 2156M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME PRI NICE   SIZE   RES STATE  TIME   WCPUCPU COMMAND
16605 rjs   430  2964M 1328M parked/0 230:45  6.88%  6.88% firefox
  634 rjs   850   182M   61M select/0 296:32  0.59%  0.59% X
18233 rjs   850  5840M  699M futex/3   84:31  0.00%  0.00% java
  711 rjs   850   301M  179M select/5  12:10  0.00%  0.00% emacs
  615 rjs   85065M 6332K select/5   2:21  0.00%  0.00% mwm
21786 rjs   850  1182M  202M select/1   0:51  0.00%  0.00% sbcl
22344 rjs   85097M   33M select/3   0:10  0.00%  0.00% xpdf
 1028 rjs   850   135M 7872K wait/0 0:00  0.00%  0.00% eclipse

My memory summary line looks similar to what wiz@ reported in the
original message though.

Re: X server being killed a lot

[Robert Swindells]

Do we know what combination of things is causing X to be killed ?

I have never seen it happen and am running X, Firefox and several other
big packages as well as doing builds on the same machine.

Robert Swindells