Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 04:41:37PM +0100, Chavdar Ivanov wrote: > And still --- in -current at least, if the trackpad is a Synaptics, I have > > hw.synaptics.gesture_length = 20 > > So you have a great many knobs to play with. So, I had this problem on 2 laptops. On both, I am trying out -current right now. On one of them the touchpad gets detected as Synaptics and setting gesture_length to 0 solves the issue I was facing. I do not know what else it might affect though. The other one is not detected as Synaptics. As I shared on the thread, in older Linux versions it used to be detected as Synaptics and now it's libinput, but Synaptics used to work back then (on Linux). It was suggested that I should try PMSDEBUG to see why it's not getting detected as Synaptics. Will try that. Any other hints would be valuable. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Mon, Apr 12, 2021 at 10:10:23PM -, Michael van Elst wrote: > mayur...@acm.org (Mayuresh) writes: > > >pms0: synaptics_probe: Not synaptics. > > >It's not synaptics, but in an older log that I shared Linux did treat it > >as so. > > You could replace the pms_synaptics_probe_init() function with something > that just sets the capabilities flags that you assume to be right. If you > do, build the kernel with PMSDEBUG option to get the protocol dumped to > the console. > > But I doubt it will work. > > Yes, I doubt it will work too. That error means the trackpad did not respond with the right value when asked to identify itself. Setting PMSDEBUG would be very helpful to see what is going on. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
mayur...@acm.org (Mayuresh) writes: >pms0: synaptics_probe: Not synaptics. >It's not synaptics, but in an older log that I shared Linux did treat it >as so. You could replace the pms_synaptics_probe_init() function with something that just sets the capabilities flags that you assume to be right. If you do, build the kernel with PMSDEBUG option to get the protocol dumped to the console. But I doubt it will work.
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Mon, Apr 12, 2021 at 06:21:29AM -, Michael van Elst wrote: > You can boot a kernel with '-x' option to enable debug messages. > A failed synaptics detection then should print: > > pms0: synaptics_probe: Not synaptics > > A successful synaptics detection prints (also without debug) e.g.: > > pms0: Synaptics touchpad version 7.2 > > But if further initialization goes wrong you also get > > pms0: synaptics_probe: Failed to query capabilities. With -x: $ grep ^pms dmesg.boot pms0 at pckbc2 (aux slot) pms0: synaptics_probe: Not synaptics. pms0: reset 0 0xaa 0x00 It's not synaptics, but in an older log that I shared Linux did treat it as so. So not sure it's kind-of-compatible-but-not-fully or so. And is there any way to try this hypothesis out? -- Mayuresh
Re: NetBSD 9.1 VPS: Too many dhclient XMT: solicit messages
On 11/04/2021 19:19, Mayuresh wrote: Such messages are appearing every 2 minutes 2s. Apr 11 23:32:35 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110920ms. Apr 11 23:34:27 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 115560ms. Apr 11 23:36:22 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 117380ms. Apr 11 23:38:20 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 119250ms. Apr 11 23:40:19 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 109500ms. Apr 11 23:42:09 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 124470ms. Apr 11 23:44:14 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110970ms. Anything to look out for? There is no DHCP (probably DHCPv6, but unsure) server on the other end of vioif0 or there is an issue with it replying like say a firewall. 2 minutes is quite a short upper limit for solicits - the RFC standard for both DHCP and DHCPv6 is one hour. I would advise using dhcpcd instead, but I doubt you'll see any different - maybe less noise in the logs by default. Roy
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Mon, Apr 12, 2021 at 09:23:23AM -, Michael van Elst wrote: > I'm not sure if that was really the same device. It sounds more like > Focaltech producing devices that are Synaptics compatible and devices > that are not. Rest assured it was the same laptop running debian at that time, choosing the driver as synaptics. Now it is running ubuntu 20 and choosing libinput driver. Back then NetBSD8 and now 9.1 have the same issue with oversensitive touchpad. PS: A few hours back Linux installation on that laptop has crashed and I am completely dependent on the NetBSD installation now. Looking forward to some workaround to this, preferably without external mouse. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
mayur...@acm.org (Mayuresh) writes: >Seems so now. I have posted a link to my 2017 post where Linux was also >using synaptics for the same device and it was working fine. So worth a >try if it works even partly (+ whatever we can achieve with sysctl option >tuning). I'm not sure if that was really the same device. It sounds more like Focaltech producing devices that are Synaptics compatible and devices that are not. It is even possible that this depends on some device firmware. Since we don't upload any firmware, that would then be a matter of the BIOS/UEFI version. Lots of things that may be responsible for the failure.
Re: NetBSD 9.1 VPS: Too many dhclient XMT: solicit messages
On Mon, Apr 12, 2021 at 09:14:04AM +0100, Roy Marples wrote: > There is no DHCP (probably DHCPv6, but unsure) server on the other end of > vioif0 or there is an issue with it replying like say a firewall. The pid's command appears as this dhclient -6 -i vioif0 I do not recollect how it would have started. rc.conf says: dhcpcd=YES dhcpcd_flags="-qM vioif0" I have killed it manually now. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Mon, Apr 12, 2021 at 06:21:29AM -, Michael van Elst wrote: > A kernel can have the config embedded, and 'config -x' will dump that > config. Got it, thanks. Confirmed that it's compiled in. > The sysctl nodes however are only created if the driver actually > finds a synaptics touchpad. I have been through a situation for USB scanners, where 'ulpt' needs to be commented out for 'ugen' to become operational. Not sure whether that is the scenario here. > You can boot a kernel with '-x' option to enable debug messages. > A failed synaptics detection then should print: Thanks. Will try. > Linux has a dedicated Focaltech mouse/touchpad driver. Seems so now. I have posted a link to my 2017 post where Linux was also using synaptics for the same device and it was working fine. So worth a try if it works even partly (+ whatever we can achieve with sysctl option tuning). -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
mayur...@acm.org (Mayuresh) writes: >On Mon, Apr 12, 2021 at 05:16:37AM -, Michael van Elst wrote: >> >options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads >> >> It's a compile-time option for the pms driver to include code that >> handles Synaptics Touchpads. >So I can assume synaptics support is compiled in. So why doesn't sysctl -a >show the synaptics options mentioned in man pms? Is there any alternative >way to cross check whether option is compiled into the running kernel? A kernel can have the config embedded, and 'config -x' will dump that config. config -x | grep SYNAP options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads ident will extract compiled-in RCS/CVS tags from a binary. ident /netbsd | grep synap $NetBSD: synaptics.c,v 1.70 2020/10/01 17:13:19 nia Exp $ nm will reveal linker symbols nm /netbsd | grep synap | grep T 8042a04c T pms_synaptics_enable 80428d7a T pms_synaptics_probe_init 8042a18c T pms_synaptics_resume The sysctl nodes however are only created if the driver actually finds a synaptics touchpad. You can boot a kernel with '-x' option to enable debug messages. A failed synaptics detection then should print: pms0: synaptics_probe: Not synaptics A successful synaptics detection prints (also without debug) e.g.: pms0: Synaptics touchpad version 7.2 But if further initialization goes wrong you also get pms0: synaptics_probe: Failed to query capabilities. then you also do not get the sysctl nodes. You can see how it works in the pms_synaptics_probe_init() function. My guess is that the Focaltech touchpad which isn't a Synaptics touchpad is not compatible enough to be treated like one. Google returns lots of hits of Windows and Linux users that have a similar issue (i.e. Focaltech not being Synaptics compatible so that Synaptics tools and drivers don't work). Linux has a dedicated Focaltech mouse/touchpad driver. It's possible that this reveals enough information to add support to our mouse driver just like we support devices from Synaptics, Elan and ALPS. Greetings,
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Mon, Apr 12, 2021 at 05:16:37AM -, Michael van Elst wrote: > >options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads > > It's a compile-time option for the pms driver to include code that > handles Synaptics Touchpads. So I can assume synaptics support is compiled in. So why doesn't sysctl -a show the synaptics options mentioned in man pms? Is there any alternative way to cross check whether option is compiled into the running kernel? -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
mayur...@acm.org (Mayuresh) writes:
>On Sun, Apr 11, 2021 at 08:15:03PM +0200, Martin Husemann wrote:
>> grep '^pms' /var/run/dmesg.boot
>pms0 at pckbc2 (aux slot)
>wsmouse0 at pms0 mux 0
>But the following line in the kernel config is enabled. How is it supposed
>to play a role? The name Synaptics comes only on 'options' line and not
>like a device line (e.g. like 'wsmouse*at pms? mux 0').
>options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads
It's a compile-time option for the pms driver to include code that
handles Synaptics Touchpads.
There is:
defflag opt_pms.h PMS_SYNAPTICS_TOUCHPAD
defflag opt_pms.h PMS_ELANTECH_TOUCHPAD
defflag opt_pms.h PMS_ALPS_TOUCHPAD
and
filedev/pckbport/synaptics.cpms & pms_synaptics_touchpad
filedev/pckbport/elantech.c pms & pms_elantech_touchpad
filedev/pckbport/alps.c pms & pms_alps_touchpad
in the included files.pckbport config file. The upper case defflags
are used as lower case condition names to optionally include source
files.
opt_pms.h is created by the config program and includes definitions
for the flags that are enabled by the option statement. E.g.
#define PMS_SYNAPTICS_TOUCHPAD 1
#ifdef _LOCORE
.ifndef _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD
.global _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD
.equiv _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD,0x1
.endif
#else
__asm(" .ifndef _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD\n .global
_KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD\n .equiv
_KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD,0x1\n .endif");
#endif
C code can just use the macro PMS_SYNAPTICS_TOUCHPAD, assembler code
can evaluate the global symbol _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD.
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 08:15:03PM +0200, Martin Husemann wrote: > grep '^pms' /var/run/dmesg.boot pms0 at pckbc2 (aux slot) wsmouse0 at pms0 mux 0 But the following line in the kernel config is enabled. How is it supposed to play a role? The name Synaptics comes only on 'options' line and not like a device line (e.g. like 'wsmouse*at pms? mux 0'). options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads -- Mayuresh
NetBSD 9.1 VPS: Too many dhclient XMT: solicit messages
Such messages are appearing every 2 minutes 2s. Apr 11 23:32:35 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110920ms. Apr 11 23:34:27 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 115560ms. Apr 11 23:36:22 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 117380ms. Apr 11 23:38:20 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 119250ms. Apr 11 23:40:19 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 109500ms. Apr 11 23:42:09 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 124470ms. Apr 11 23:44:14 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110970ms. Anything to look out for? -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, 11 Apr 2021 at 18:57, Mayuresh wrote: > > On Sun, Apr 11, 2021 at 11:18:48PM +0530, Mayuresh wrote: > > Or may be it has to be enabled. man pms shows this: > > > > options PMS_SYNAPTICS_TOUCHPAD > > > > May be compiling this in the kernel should be the first thing to try. > > I checked the GENERIC kernel configuration file and above line is already > uncommented there. So, shouldn't it have shown the snyaptics options in > sysctl -a (as per man pms)? What am I missing? > Well, it is not Synaptics. On my other NetBSD laptop - an Hewlett-Packard HP EliteBook 8570w - I also do not have any mentioning of Synaptics from sysctl hw, although the machine certainly has one. Unfortunately I can't even try any windowing system on it, as the FirePro graphics adapter it has has a hardware problem and any attempt to initialize it results in a hard reset. > -- > Mayuresh --
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:27:15PM +0530, Mayuresh wrote: > I checked the GENERIC kernel configuration file and above line is already > uncommented there. So, shouldn't it have shown the snyaptics options in > sysctl -a (as per man pms)? What am I missing? If grep '^pms' /var/run/dmesg.boot does not show anything mentioning "Synaptics touchpad" the device was not recognized as one. Martin
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:18:48PM +0530, Mayuresh wrote: > Or may be it has to be enabled. man pms shows this: > > options PMS_SYNAPTICS_TOUCHPAD > > May be compiling this in the kernel should be the first thing to try. I checked the GENERIC kernel configuration file and above line is already uncommented there. So, shouldn't it have shown the snyaptics options in sysctl -a (as per man pms)? What am I missing? -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:05:53PM +0530, Mayuresh wrote: > BTW on NetBSD 9.1 Synaptics properties don't seem to be present > # sysctl -a | grep -i syna > # Or may be it has to be enabled. man pms shows this: options PMS_SYNAPTICS_TOUCHPAD May be compiling this in the kernel should be the first thing to try. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:05:53PM +0530, Mayuresh wrote: > Thanks. Based on the following I do not know how to decide whether it is > Synaptics. > > $ grep Touch /var/log/Xorg.0.log > [ 899.721] (II) Using input driver 'libinput' for 'FocalTechPS/2 FocalTech > Touchpad' It seems to be using libinput on Linux. I don't find anything equivalent of that - neither in base nor in pkg - on NetBSD; except that there is one wip/libinput - not sure about its state. Its PLIST is not having libinput_drv.so. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 04:41:37PM +0100, Chavdar Ivanov wrote: > And still --- in -current at least, if the trackpad is a Synaptics, I have Thanks. Based on the following I do not know how to decide whether it is Synaptics. This [1] old thread shows, on Linux it was recognized as Synaptics on the same hardware back then. Today on a recent Linux it does not show so: $ grep Touch /var/log/Xorg.0.log [ 899.721] (II) config/udev: Adding input device FocalTechPS/2 FocalTech Touchpad (/dev/input/event5) [ 899.721] (**) FocalTechPS/2 FocalTech Touchpad: Applying InputClass "libinput touchpad catchall" [ 899.721] (II) Using input driver 'libinput' for 'FocalTechPS/2 FocalTech Touchpad' [ 899.721] (**) FocalTechPS/2 FocalTech Touchpad: always reports core events [ 899.725] (II) event5 - FocalTechPS/2 FocalTech Touchpad: is tagged by udev as: Touchpad [ 899.726] (II) event5 - FocalTechPS/2 FocalTech Touchpad: no resolution or size hints, assuming a size of 69x50mm [ 899.728] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device is a touchpad [ 899.728] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device removed [ 899.761] (II) XINPUT: Adding extended input device "FocalTechPS/2 FocalTech Touchpad" (type: TOUCHPAD, id 14) [ 899.768] (**) FocalTechPS/2 FocalTech Touchpad: (accel) selected scheme none/0 [ 899.768] (**) FocalTechPS/2 FocalTech Touchpad: (accel) acceleration factor: 2.000 [ 899.768] (**) FocalTechPS/2 FocalTech Touchpad: (accel) acceleration threshold: 4 [ 899.772] (II) event5 - FocalTechPS/2 FocalTech Touchpad: is tagged by udev as: Touchpad [ 899.773] (II) event5 - FocalTechPS/2 FocalTech Touchpad: no resolution or size hints, assuming a size of 69x50mm [ 899.776] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device is a touchpad [ 899.778] (II) config/udev: Adding input device FocalTechPS/2 FocalTech Touchpad (/dev/input/mouse0) [ 918.079] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device removed BTW on NetBSD 9.1 Synaptics properties don't seem to be present # sysctl -a | grep -i syna # [1] https://mail-index.netbsd.org/netbsd-users/2017/06/16/msg019731.html -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat, 10 Apr 2021, Rhialto wrote: > I have a laptop of about 10 years old with an Intel "GM45"(?) chipset > (or i965 is mentioned in some places). I have a G41 chipset in my primary workstation machine and I see frequent references to i965 for dri-related things (and that the i965 vdpau module is not present in NetBSD's Xorg/OpenGL--as noted by mplayer, mpv, vlc, etc.). > It worked fine up to NetBSD 8.x. But now on 9.1, if I run x64 (from > package emulators/vice) on it for a while I get errors in my xterm > "i965: Failed to submit batchbuffer: Input/output error", > and the kernel crashes sometimes a short time later. I've seen/experienced these as well, mostly when trying to play videos through firefox (firefox52, actually). IIRC, the workaround has been to set "LIBGL_ALWAYS_INDIRECT=1". I do it in a wrapper script for firefox, but if other things trigger it, perhaps it should be set/exported in .xsession (or other display-manager session configuration/startup file). > The config file is mostly the auto-detected stuff, enhanced with some > preferences from my previous xorg.conf file. For some reason, 2 cards > were detected, Card0 and Card1 and I just copied that, just in case it > is important. > > 000:02:0: Intel 82GM45 Integrated Graphics Device (VGA display, revision > 0x07) [i915drmkms0] > 000:02:1: Intel 82GM45 Integrated Graphics Device (miscellaneous display, > revision 0x07) Function 0, according to the device ID reported in your Xorg.0.log and matched in "i915pciids.h" is a GM45_G. You said it's a laptop, so I suppose it's the "Mobile" variant of the G45. Function 1 is not listed. I wonder what "miscellaneous display" means? Before the gen 3/4/5 chips were defaulted to UXA, the only xorg.conf I needed was to set AccelMethod UXA. Since the default to UXA, the auto-detection works properly and I don't need xorg.conf anymore. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sun 11 Apr 2021 at 08:07:20 -0500, John D. Baker wrote: > I've seen/experienced these as well, mostly when trying to play videos > through firefox (firefox52, actually). IIRC, the workaround has been > to set "LIBGL_ALWAYS_INDIRECT=1". I do it in a wrapper script for > firefox, but if other things trigger it, perhaps it should be set/exported > in .xsession (or other display-manager session configuration/startup file). I tried setting this and it certainly has some effect but not yet the one I hoped for :) All programs I tried didn't like it: most terminate with some error. mpv runs, but simply doesn't paint its window. LIBGL_ALWAYS_INDIRECT certainly has interesting effects :) Grepping for this string I found /usr/xsrc/external/mit/MesaLib/dist/docs/envvars.html which gave me some other things to try. I could get extensive debugging output for example with INTEL_DEBUG=all. But that was unfortunately so much detail that it didn't mean much to me. I did find a more interesting part of the kernel messages though (related to the original problem I'd say). I'm including them for the record, in case it means anything to somebody who could fix it. Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] kern info: [drm] stuck on render ring Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] kern info: [drm] GPU HANG: ecode 4:0:0x86fefffc, reason: Ring hung, action: reset Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] 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! Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] drm/i915: Resetting chip after gpu hang Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_irq.c:2703)i915_handle_error] *ERROR* Error state: Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] GPU HANG: ecode 4:0:0x86fd, reason: Ring hung, action: reset Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Time: 1618159400 s 39278 us Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Kernel: 90100 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Reset count: 0 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Suspend count: 0 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] PCI ID: 0x2a42 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IOMMU enabled?: -1 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] EIR: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IER: 0x02028053 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] PGTBL_ER: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] FORCEWAKE: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] DERRMR: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] CCID: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Missed interrupts: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[0] = bc205c50cd Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[1] = bd70bd400d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[2] = bdb0bd800d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[3] = ef60c7704d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[4] = f3e0f2301d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[5] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[6] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[7] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[8] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[9] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[10] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[11] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[12] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[13] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[14] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[15] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_0: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_1: 0xbfdc Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_2: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_3: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] render command stream: Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] START: 0x3000 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] HEAD: 0x00014ef8 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] TAIL: 0x00014f60 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] CTL: 0x0001f001 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] HWS: 0x1000 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] ACTHD: 0x 1f2632b4 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IPEIR: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IPEHR: 0x7902 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] BBADDR: 0x 1f2632b3
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sat, 10 Apr 2021 at 11:22, Chavdar Ivanov wrote: > > On Sat, 10 Apr 2021 at 10:51, Mayuresh wrote: > > > > Seems an old issue [1][2] where the touchpad gestures happen inadvertently > > while typing on keyboard with slightest of touch. > > > > Is there any solution in sight, such as even by conceding some > > functionality? Tried the settings suggested in [1], that did not solve it. > > > > [1] https://mail-index.netbsd.org/netbsd-users/2018/05/07/msg020740.html > > [2] https://mail-index.netbsd.org/netbsd-users/2017/06/12/msg019686.html > > Running -current, usually. I used to always attach a USB mouse when I > was booting NetBSD on my laptop; recently - say, the last two months - > this seems no longer needed; although the trackpad is still a bit > oversensitive, I am able to use it reasonably well. > > Still, with the mouse is better I think... And still --- in -current at least, if the trackpad is a Synaptics, I have hw.synaptics.up_down_emulation = 3 hw.synaptics.up_down_motion_delta = 1 hw.synaptics.gesture_move = 200 hw.synaptics.gesture_length = 20 hw.synaptics.edge_left = 1632 hw.synaptics.edge_right = 5312 hw.synaptics.edge_top = 4288 hw.synaptics.edge_bottom = 1568 hw.synaptics.edge_motion_delta = 32 hw.synaptics.finger_high = 35 hw.synaptics.finger_low = 20 hw.synaptics.two_fingers_emulation = 0 hw.synaptics.scale_x = 4 hw.synaptics.scale_y = 4 hw.synaptics.scale_z = 32 hw.synaptics.max_speed_x = 32 hw.synaptics.max_speed_y = 32 hw.synaptics.max_speed_z = 2 hw.synaptics.movement_threshold = 4 hw.synaptics.movement_enable = 1 hw.synaptics.button_boundary = 2288 hw.synaptics.button2_edge = 2858 hw.synaptics.button3_edge = 4085 hw.synaptics.finger_scroll-min = 13 hw.synaptics.finger_scroll-max = 14 hw.synaptics.finger_scroll-hysteresis = 30 hw.synaptics.aux_mid_button_scroll = 1 (sysctl sh.synaptics) So you have a great many knobs to play with. > > > > > -- > > Mayuresh > > > > -- > --
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat, Apr 10, 2021 at 01:58:33PM -0500, John D. Baker wrote: > I should note that I do not and cannot speak for NetBSD developers, but > merely an interested user who has dealt with this issue in the recent > past and all of my affected systems are handled satisfactorily. Appreciate your help. Given the background you have, if you have any idea about the 'touchpad' issue (see a separate thread) please do share your views. The display issue was solved, thanks to Jörn's post. But touchpad proved to be a show stopper. Had to revert to Linux on that device. -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat, Apr 10, 2021 at 01:53:48PM -0500, John D. Baker wrote: > As this is a USB-stick installation, I presume you expect to be able to > boot it on any machine you encounter? Other systems with intel graphics > devices may be just fine with SNA, so you may want to move the "xorg.conf" > aside on those systems. Of course, you won't know for sure until you > try it each way. I have tried this USB stick installation on 1 more laptop where it worked fine with default xorg configuration. But it's a different chipset. On this other m/c, on Linux: # lspci -vvv -s 0:1.0 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] (rev ea) (prog-if 00 [VGA controller]) Subsystem: Lenovo Stoney [Radeon R2/R3/R4/R5 Graphics] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag+ RBE+ FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR- 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt+, EETLPPrefix+, MaxEETLPPrefixes 1 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled AtomicOpsCtl: ReqEn- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee01004 Data: 4026 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [270 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn-, PerformEqu- LaneErrStat: 0 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable-, Smallest Translation Unit: 00 Capabilities: [2c0 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 0020, Page Request Allocation: Capabilities: [2d0 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 10 PASIDCtl: Enable- Exec- Priv- Kernel driver in use: amdgpu Kernel modules: amdgpu I have 1 more machine, which is not with me right now. Can try it some other day if it is going to help get any idea. -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
Linux is using the "modesetting" driver rather than the "intel" driver. This is an option on NetBSD as well, although ISTR that OpenGL doesn't yet work with the "modesetting" driver currently in NetBSD's Xorg sources. (Or was it something else that was not ready for prime time?) As such, it doesn't directly identify the video device but does provide: > [ 898.950] (--) PCI:*(0@0:2:0) 8086:0f31:1043:15bd rev 14, Mem @ > 0xd000/4194304, 0xc000/268435456, I/O @ 0xf080/8, BIOS @ > 0x/131072 Under Linux 'lspci' for the device at bus 0, device 2, function 0 should show more information--possibly even a chipset name/number. More "-v"s for more verbosity if needed. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: NetBSD 9.1 amd64, base X11: garbled display
I should note that I do not and cannot speak for NetBSD developers, but merely an interested user who has dealt with this issue in the recent past and all of my affected systems are handled satisfactorily. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: NetBSD 9.1 amd64, base X11: garbled display
Based on the PCI DeviceID (0x0f31), this appears to be a "Valleyview (Baytail)" device (as described in "intel_module.c" in the xf86-video-intel sources. This is considered a generation 7.1 device and as such currently defaults to SNA rather than UXA (gen 3.1-5.0 inclusive). I suppose we need more data from Atom users to see if this is a common enough situation to warrant an additional device default to UXA. As this is a USB-stick installation, I presume you expect to be able to boot it on any machine you encounter? Other systems with intel graphics devices may be just fine with SNA, so you may want to move the "xorg.conf" aside on those systems. Of course, you won't know for sure until you try it each way. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: NetBSD 9.1 amd64, base X11: garbled display
Could you post some details about which intel video device/chipset the affected system is using? There are some newer chips that can use AccelMethod SNA, but also require Option TearFree (which IIRC is now on by default). Otherwise, the screen is garbled much as you describe. There some older chips (e.g., i845, i855(?), i915) that work with AccelMethod SNA and don't require Option TearFree (and need to disable it to save the performance penalty). Then there are some in the middle (e.g., i945, i946, G41, Q45) that don't work with SNA at all (garbled screen much as you describe) and require AccelMethod UXA. We thought we'd figured out the non-working range of chip generations and had them default to UXA and pulled that up to netbsd-9 quite some months ago. Sounds like you've found an outlier? If you could move your "xorg.conf" aside, restart X, and post the resulting "/var/log/Xorg.0.log", that might shed some light on which chip is not covered by the above cases. Thanks. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat 10 Apr 2021 at 21:17:31 +0200, Rhialto wrote: > "i965: Failed to submit batchbuffer: Input/output error", > and the kernel crashes sometimes a short time later. /usr/pkg/libexec/xscreensaver/carousel reliably provokes that error message. The kernel log contains then lots of hexdump, and stuff like Apr 10 21:33:31 vargaz /netbsd: [ 3749.9252610] 000117cc : 00c0 Apr 10 21:33:31 vargaz /netbsd: [ 3749.9252610] 000117d0 : b6ff Apr 10 21:33:31 vargaz /netbsd: [ 3749.9252610] 000117d4 : 0100 ... Apr 10 21:33:31 vargaz /netbsd: [ 3749.9352668] 00013368 : 0200 Apr 10 21:33:31 vargaz /netbsd: [ 3749.9352668] 0001336c : Apr 10 21:33:31 vargaz /netbsd: [ 3749.9352668] 0001337 Apr 10 21:33:37 vargaz /netbsd: [ 3755.9180155] kern info: [drm] stuck on render ring Apr 10 21:33:37 vargaz /netbsd: [ 3755.9180155] kern info: [drm] GPU HANG: ecode 4:0:0x86fefffc, reason: Ring hung, action: reset Apr 10 21:33:37 vargaz /netbsd: [ 3755.9180155] 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! Apr 10 21:33:37 vargaz /netbsd: [ 3755.9180155] kern info: [drm] stuck on render ringng Apr 10 21:33:37 vargaz /netbsd: [ 3756.1181094] 000117cc : 00c0 Apr 10 21:33:37 vargaz /netbsd: [ 3756.1181094] 000117d0 : b6ff Apr 10 21:33:37 vargaz /netbsd: [ 3756.1181094] 000117d4 : 0100 ... I can switch to the "modesetting" driver, but that is too slow to play movies, so it's useless. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat 10 Apr 2021 at 11:48:07 -0500, John D. Baker wrote: > Sounds like you've found an outlier? I have a laptop of about 10 years old with an Intel "GM45"(?) chipset (or i965 is mentioned in some places). It worked fine up to NetBSD 8.x. But now on 9.1, if I run x64 (from package emulators/vice) on it for a while I get errors in my xterm "i965: Failed to submit batchbuffer: Input/output error", and the kernel crashes sometimes a short time later. The config file is mostly the auto-detected stuff, enhanced with some preferences from my previous xorg.conf file. For some reason, 2 cards were detected, Card0 and Card1 and I just copied that, just in case it is important. 000:02:0: Intel 82GM45 Integrated Graphics Device (VGA display, revision 0x07) [i915drmkms0] 000:02:1: Intel 82GM45 Integrated Graphics Device (miscellaneous display, revision 0x07) $ sudo crash -M netbsd.0.core -N netbsd.0 Crash version 9.1, image version 9.1. System panicked: trap Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NARCNET() at 0 ?() at a00066edb000 vpanic() at vpanic+0x169 snprintf() at snprintf startlwp() at startlwp calltrap() at calltrap+0x11 i915_capture_error_state() at i915_capture_error_state+0xef1 i915_handle_error() at i915_handle_error+0x89 linux_workqueue_thread() at linux_workqueue_thread+0x14e crash> dmesg [ 3668.2570634] 00012844 : ff808080 [ 3668.2570634] 00012848 : ff808080 [ 3668.2570634] 0001284c : ff808080 [ 3668.2570634] 00012850 : ff808080 ... [ 3668.2670701] 00014374 : ff808080 [ 3668.2670701] 00014378 : ff808080 [ 3668.2670701] 0001437c : [ 3704.2637605] kern info: [drm] stuck on render ring [ 3704.2637605] uvm_fault(0x8151f6e0, 0xa00066ed2000, 1) -> e [ 3704.2637605] fatal page fault in supervisor mode [ 3704.2637605] trap type 6 code 0 rip 0x80abea38 cs 0x8 rflags 0x10206 cr2 0xa00066ed2628 ilevel 0x6 rsp 0xa00066eddd10 [ 3704.2637605] curlwp 0xe8a6c151b740 pid 0.77 lowest kstack 0xa00066edb 2c0 [ 3704.2637605] panic: trap [ 3704.2637605] cpu0: Begin traceback... [ 3704.2637605] vpanic() at netbsd:vpanic+0x160 [ 3704.2637605] snprintf() at netbsd:snprintf [ 3704.2637605] startlwp() at netbsd:startlwp [ 3704.2637605] alltraps() at netbsd:alltraps+0xbb [ 3704.2737715] i915_capture_error_state() at netbsd:i915_capture_error_state+0x ef1 [ 3704.2737715] i915_handle_error() at netbsd:i915_handle_error+0x89 [ 3704.2737715] linux_workqueue_thread() at netbsd:linux_workqueue_thread+0x14e [ 3704.2737715] cpu0: End traceback... [ 3704.2737715] dumping to dev 0,1 (offset=199775, size=1023726): [ 3704.2737715] dump Xorg.0.log: [23.826] X.Org X Server 1.20.5 X Protocol Version 11, Revision 0 [23.826] Build Operating System: NetBSD/amd64 9.1 - The NetBSD Foundation, Inc. [23.826] Current Operating System: NetBSD vargaz.falu.nl 9.1 NetBSD 9.1 (GENERIC) #0: Sun Oct 18 19:24:30 UTC 2020 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 [23.827] Build Date: 03 March 2019 07:11:23AM [23.827] [23.840] Current version of pixman: 0.38.4 [23.840]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [23.840] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [23.840] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 10 20:31:25 2021 [23.868] (==) Using config file: "/etc/X11/xorg.conf" [23.879] (==) ServerLayout "X.org Configured" [23.879] (**) |-->Screen "Screen0" (0) [23.879] (**) | |-->Monitor "Monitor0" [23.880] (**) | |-->Device "Card0" [23.880] (**) |-->Screen "Screen1" (1) [23.880] (**) | |-->Monitor "Monitor1" [23.881] (**) | |-->Device "Card1" [23.882] (**) |-->Input Device "Mouse0" [23.882] (**) |-->Input Device "Keyboard0" [23.882] (==) Not automatically adding devices [23.882] (==) Not automatically enabling devices [23.882] (==) Not automatically adding GPU devices [23.896] (==) Max clients allowed: 256, resource mask: 0x1f [23.918] (**) FontPath set to: /usr/X11R7/lib/X11/fonts/misc/, /usr/X11R7/lib/X11/fonts/TTF/, /usr/X11R7/lib/X11/fonts/Speedo/, /usr/X11R7/lib/X11/fonts/Type1/, /usr/X11R7/lib/X11/fonts/CID/, /usr/X11R7/lib/X11/fonts/75dpi/, /usr/X11R7/lib/X11/fonts/100dpi/, /usr/X11R7/lib/X11/fonts/misc/, /usr/X11R7/lib/X11/fonts/TTF/, /usr/X11R7/lib/X11/fonts/Type1/, /usr/X11R7/lib/X11/fonts/75dpi/, /usr/X11R7/lib/X11/fonts/100dpi/ [23.918] (**) ModulePath set to "/usr/X11R7/lib/modules" [23.918] (II) Loa
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat, Apr 10, 2021 at 01:01:32PM -0500, John D. Baker wrote: > Under Linux 'lspci' for the device at bus 0, device 2, function 0 should > show more information--possibly even a chipset name/number. Here it is: # lspci -vvv -s 0:2.0 00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Atom Processor Z36xxx/Z37xxx Series Graphics & Display Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat, Apr 10, 2021 at 11:48:07AM -0500, John D. Baker wrote: > If you could move your "xorg.conf" aside, restart X, and post the > resulting "/var/log/Xorg.0.log", that might shed some light on which > chip is not covered by the above cases. Currently the system is in use on Linux. So I am posting the Xorg log from Linux, which may still be useful. If it is going to help further I'll share the log on NetBSD later, when I get to reboot the system. [Let me know.] [As noted earlier Option "AccelMethod" "uxa" of intel driver fixes the display issue. But as shared on a separate thread, I am unable to use NetBSD on the laptop due to sensitive touchpad issue.] -- Mayuresh [ 898.854] X.Org X Server 1.20.9 X Protocol Version 11, Revision 0 [ 898.864] Build Operating System: Linux 4.15.0-130-generic x86_64 Ubuntu [ 898.867] Current Operating System: Linux asus 5.8.0-41-generic #46~20.04.1-Ubuntu SMP Mon Jan 18 17:52:23 UTC 2021 x86_64 [ 898.867] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-41-generic root=UUID=a775ffbe-42df-4474-9bb1-965468166243 ro text [ 898.873] Build Date: 17 January 2021 09:13:31AM [ 898.877] xorg-server 2:1.20.9-2ubuntu1.2~20.04.1 (For technical support please see http://www.ubuntu.com/support) [ 898.880] Current version of pixman: 0.38.4 [ 898.887]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 898.887] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 898.900] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Mar 14 15:04:07 2021 [ 898.904] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 898.907] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 898.908] (==) No Layout section. Using the first Screen section. [ 898.908] (==) No screen section available. Using defaults. [ 898.908] (**) |-->Screen "Default Screen Section" (0) [ 898.908] (**) | |-->Monitor "" [ 898.909] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 898.909] (==) Automatically adding devices [ 898.909] (==) Automatically enabling devices [ 898.909] (==) Automatically adding GPU devices [ 898.909] (==) Automatically binding GPU devices [ 898.909] (==) Max clients allowed: 256, resource mask: 0x1f [ 898.909] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 898.909]Entry deleted from font path. [ 898.909] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [ 898.909]Entry deleted from font path. [ 898.909] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [ 898.909]Entry deleted from font path. [ 898.909] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [ 898.909]Entry deleted from font path. [ 898.909] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [ 898.909]Entry deleted from font path. [ 898.909] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, built-ins [ 898.909] (==) ModulePath set to "/usr/lib/xorg/modules" [ 898.909] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 898.909] (II) Loader magic: 0x5638c7e49020 [ 898.909] (II) Module ABI versions: [ 898.909]X.Org ANSI C Emulation: 0.4 [ 898.909]X.Org Video Driver: 24.1 [ 898.909]X.Org XInput driver : 24.1 [ 898.909]X.Org Server Extension : 10.0 [ 898.913] (--) using VT number 2 [ 898.913] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 898.919] (II) xfree86: Adding drm device (/dev/dri/card0) [ 898.950] (--) PCI:*(0@0:2:0) 8086:0f31:1043:15bd rev 14, Mem @ 0xd000/4194304, 0xc000/268435456, I/O @ 0xf080/8, BIOS @ 0x/131072 [ 898.950] (II) LoadModule: "glx" [ 898.950] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 898.952] (II) Module glx: vendor="X.Org Foundation" [ 898.952]compiled for 1.20.9, module version = 1.0.0 [ 898.952]ABI class: X.Org Server Extension, version 10.0 [ 898.952] (==) Matched modesetting as autoconfigured driver 0 [ 898.952] (==) Matched fbdev as autoconfigured driver 1 [ 898.952] (==) Matched vesa as autoconfigured driver 2 [ 898.952] (==) Assigned the driver to the xf86ConfigLayout [ 898.952] (II) LoadModule: "modesetting" [ 898.952] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 898.953] (II) Module modesetting: vendor="X.Org Foundation" [ 898.953]compiled for 1.20.9, module version = 1.20.9 [ 898.953]Module class: X.Org Video Driver [ 898.953]ABI class: X.Org Video Driver, version 24.1 [ 898.953
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sat, 10 Apr 2021 at 10:51, Mayuresh wrote: > > Seems an old issue [1][2] where the touchpad gestures happen inadvertently > while typing on keyboard with slightest of touch. > > Is there any solution in sight, such as even by conceding some > functionality? Tried the settings suggested in [1], that did not solve it. > > [1] https://mail-index.netbsd.org/netbsd-users/2018/05/07/msg020740.html > [2] https://mail-index.netbsd.org/netbsd-users/2017/06/12/msg019686.html Running -current, usually. I used to always attach a USB mouse when I was booting NetBSD on my laptop; recently - say, the last two months - this seems no longer needed; although the trackpad is still a bit oversensitive, I am able to use it reasonably well. Still, with the mouse is better I think... > > -- > Mayuresh --
NetBSD 9.1 amd64 base X11: hypersensitive touchpad
Seems an old issue [1][2] where the touchpad gestures happen inadvertently while typing on keyboard with slightest of touch. Is there any solution in sight, such as even by conceding some functionality? Tried the settings suggested in [1], that did not solve it. [1] https://mail-index.netbsd.org/netbsd-users/2018/05/07/msg020740.html [2] https://mail-index.netbsd.org/netbsd-users/2017/06/12/msg019686.html -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
On Fri, Apr 09, 2021 at 11:25:47PM +0200, Jörn Clausen wrote: > Someone on this list suggested this change to me (also using i915drmkms0) > + Option "AccelMethod" "uxa" Excellent find! It solved my problem. Thank you very much for sharing and to one who found it. -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
Someone on this list suggested this change to me (also using i915drmkms0) --- /etc/X11/xorg.conf 2020/04/01 20:12:03 1.1 +++ /etc/X11/xorg.conf 2020/04/01 20:16:15 @@ -75,7 +75,8 @@ #Option "DebugWait"# [] #Option "BufferCache" # [] Identifier "Card0" - Driver "wsfb" + Driver "intel" + Option "AccelMethod" "uxa" BusID "PCI:0:2:0" EndSection and X11 is fairly usable for me. Every now and then I see messages like 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 but X11 is stable and I don't have any visual artefacts. On Fri, Apr 9, 2021 at 9:04 PM Mayuresh wrote: > Recently installed NetBSD 9.1 amd64 on USB stick and booting a laptop. > > x11 is starting, but the screen looks garbled. Even xinit xterm opens > xterm but even the prompt doesn't appear correctly. (Looks something like > video synchronization going wrong.) > > X -configure shows driver as "intel". Tried changing it to "vesa", but > that doesn't start. > > dmesg shows it as i915drmkms0. > > Would prefer base x11 to work. > > Let me know if any more information would help. > > -- > Mayuresh > -- Joern Clausen https://www.oe-files.de/photography/
NetBSD 9.1 amd64, base X11: garbled display
Recently installed NetBSD 9.1 amd64 on USB stick and booting a laptop. x11 is starting, but the screen looks garbled. Even xinit xterm opens xterm but even the prompt doesn't appear correctly. (Looks something like video synchronization going wrong.) X -configure shows driver as "intel". Tried changing it to "vesa", but that doesn't start. dmesg shows it as i915drmkms0. Would prefer base x11 to work. Let me know if any more information would help. -- Mayuresh
Re: Installing NetBSD 9.1 on USB stick, not booting
On Tue, Apr 06, 2021 at 12:09:29PM +0530, Mayuresh wrote: > I think NetBSD, to a larger extent than others, used to be agnostic to a > specific hardware it is installed on, which IMHO was a great feature. It still is - on the same architecture and using the same boot method. For amd64 you can even create boot method agnostic setups (like the USB images are), but it is extra effort, may waste some space, and is not what the installer aims at. Martin
Re: Installing NetBSD 9.1 on USB stick, not booting
On Tue, Apr 06, 2021 at 07:48:31AM +0200, Martin Husemann wrote: > The installer is supposed to run on the target machine and it tries to > avoid many questions by checking the machine instead of asking > the user. > > Also the results may differ significantly and the "generic" solution > could be wastefull, so optimizing for the real machine makes sense > to me. It's not an uncommon view. For example Linux has initramfs etc which 'ties' it to the machine. Windows is just too much tied to the specific hardware that it doesn't tolerate even a slight change. I think NetBSD, to a larger extent than others, used to be agnostic to a specific hardware it is installed on, which IMHO was a great feature. (It's not a this vs that argument, it's more about the extent. Lesser you infer from the target machine the better, I think.) Opinions on this may vary. -- Mayuresh
Re: Installing NetBSD 9.1 on USB stick, not booting
On Tue, Apr 06, 2021 at 11:13:06AM +0530, Mayuresh wrote: > BTW isn't it good for the installer to not assume anything about the > target machine? It makes the installation more resilient to hardware > changes. The installer is supposed to run on the target machine and it tries to avoid many questions by checking the machine instead of asking the user. Also the results may differ significantly and the "generic" solution could be wastefull, so optimizing for the real machine makes sense to me. Martin
Re: Installing NetBSD 9.1 on USB stick, not booting
On Tue, Apr 06, 2021 at 07:22:22AM +0200, Martin Husemann wrote: > A device booted via UEFI (as you are apparently setting up) will not > need any bootsector installed, so the installer does not ask for anything > but just puts the proper file(s) into the EFI partition. > > If you are preparing the stick for another machine (that does not boot > via UEFI but uses BIOS) the installer (assuming it runs on the target > machine and can use all characteristics of the current machine to set up > the installation) will not work. Thanks a lot. I found that the device I am booting had BIOS option of 'Legacy' and 'UEFI'. Choosing the latter helped boot. BTW isn't it good for the installer to not assume anything about the target machine? It makes the installation more resilient to hardware changes. -- Mayuresh
Re: Installing NetBSD 9.1 on USB stick, not booting
On Tue, Apr 06, 2021 at 07:41:39AM +0530, Mayuresh wrote: > Device Boot Start End Sectors Size Id Type > /dev/sdb1 64 262207 262144 128M ef EFI (FAT-12/16/32) > /dev/sdb2 *262272 30031871 29769600 14.2G a9 NetBSD A device booted via UEFI (as you are apparently setting up) will not need any bootsector installed, so the installer does not ask for anything but just puts the proper file(s) into the EFI partition. If you are preparing the stick for another machine (that does not boot via UEFI but uses BIOS) the installer (assuming it runs on the target machine and can use all characteristics of the current machine to set up the installation) will not work. There might be subtle differences in the setup (e.g. default partition sizes vary depending on available memory and disk size), but on typical amd64 machines they should be negliable. If this happens in this direction (perparation on UEFI machine, target machine might use BIOS) all that should be needed is an additional installboot call. In the other direction you are basically lost due to the missing EFI partition. However, I totaly fail to see *why* you are trying to do this instead of starting with the USB image and modifying that after boot to your liking (after it once resized the root partition). Martin
Re: Installing NetBSD 9.1 on USB stick, not booting
On Mon, Apr 05, 2021 at 04:14:50PM -0400, Bob Bernstein wrote: > https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/ I think in earlier versions of installers, the installation process used to do the needful. But may be I do not recollect well enough. The installation is already done on the stick, and right now from Linux host I can see that the partition's Boot flag is set. # This is fdisk -l on Linux. Will have to boot using installable to use # NetBSD disklabel. Disk /dev/sdb: 14.33 GiB, 15376318464 bytes, 30031872 sectors Disk model: Cruzer Blade Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x Device Boot Start End Sectors Size Id Type /dev/sdb1 64 262207 262144 128M ef EFI (FAT-12/16/32) /dev/sdb2 *262272 30031871 29769600 14.2G a9 NetBSD So is it only the following command that I require now? (It will be sd1 in my case.) # installboot -v -o timeout=1 /dev/rsd0a /usr/mdec/bootxx_ffsv1 -- Mayuresh
Re: Installing NetBSD 9.1 on USB stick, not booting
On Mon, Apr 05, 2021 at 08:55:28PM +0200, Matthias Petermann wrote: > I recently set up a NetBSD 9.1 for my NAS with BIOS boot in the same way. My > problem was that both the installer USB stick and the target USB stick for > the installation were connected at the same time during the installation > (logical ;-)). During the installation, the target USB stick was detected as > unit sd1, and the installer as sd0. When booting without the installer after > the installation, the target USB stick then takes the place of the installer > USB stick and becomes sd0 itself. As a result, the root filesystem could not > be mounted because the entry in fstab was still set to sd1. Since then I > mount the target partition again r/w before the first reboot and correct the > fstab if necessary. I don't know if this helps you. As partitioning scheme I > used disklabel. In this case at least the bootloader was installed. I did > not try with GPT. Thanks. I might face this issue as well. But I think that comes into picture after boot. The installer did not offer bootcode transfer (forgot what wording it exactly used to use). So the stick is not booting. Once I go past this I'll change sd1 to sd0 in fstab. -- Mayuresh
Re: Installing NetBSD 9.1 on USB stick, not booting
On Mon, 5 Apr 2021, Mayuresh wrote: What exactly do I need to do to make it bootable. I don't need it to work with the hdd of the host or grub etc. Just need plain simple bootable usb stick that would boot into NetBSD. It's a small world. I just got through reading this about an hour ago: https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/ The making-bootable is, if an amateur may say so, non-trivial, but from days long gone by it all looks very familiar. 9-) Best, -- RSB
Re: Installing NetBSD 9.1 on USB stick, not booting
Hi Mayuresh, I recently set up a NetBSD 9.1 for my NAS with BIOS boot in the same way. My problem was that both the installer USB stick and the target USB stick for the installation were connected at the same time during the installation (logical ;-)). During the installation, the target USB stick was detected as unit sd1, and the installer as sd0. When booting without the installer after the installation, the target USB stick then takes the place of the installer USB stick and becomes sd0 itself. As a result, the root filesystem could not be mounted because the entry in fstab was still set to sd1. Since then I mount the target partition again r/w before the first reboot and correct the fstab if necessary. I don't know if this helps you. As partitioning scheme I used disklabel. In this case at least the bootloader was installed. I did not try with GPT. Many greetings Matthias On 05.04.21 19:36, Mayuresh wrote: I have installed NetBSD 9.1 on a USB stick. I think earlier installers used to ask about bootcode. 9.1 installer didn't ask me about it. The installation seems fine but the stick is not booting. I tried manually setting the boot manager (fdisk -B) though it didn't work. I do not have a trace of all my attempts but finally it rendered the USB stick read-only. Wasn't able to make it writable again, also tried on Linux. I got a new replacement stick now and I am back into the same situation - installation is complete, but it won't boot. What exactly do I need to do to make it bootable. I don't need it to work with the hdd of the host or grub etc. Just need plain simple bootable usb stick that would boot into NetBSD. smime.p7s Description: S/MIME Cryptographic Signature
Installing NetBSD 9.1 on USB stick, not booting
I have installed NetBSD 9.1 on a USB stick. I think earlier installers used to ask about bootcode. 9.1 installer didn't ask me about it. The installation seems fine but the stick is not booting. I tried manually setting the boot manager (fdisk -B) though it didn't work. I do not have a trace of all my attempts but finally it rendered the USB stick read-only. Wasn't able to make it writable again, also tried on Linux. I got a new replacement stick now and I am back into the same situation - installation is complete, but it won't boot. What exactly do I need to do to make it bootable. I don't need it to work with the hdd of the host or grub etc. Just need plain simple bootable usb stick that would boot into NetBSD. -- Mayuresh
Re: Where is NetBSD-9.1-amd64-install.img.gz
On Fri, Mar 19, 2021 at 08:23:05PM -0400, Bob Bernstein wrote: > I believe this is the file I want to put on my USB stick. The ftp looked to > be taking over a half an hour at ftp.netbsd.org. Is there a better site for > a simple download? Use https://cdn.NetBSD.org/... where ... is the same path you used with ftp. For your file that would be: https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/images/NetBSD-9.1-amd64-install.img.gz for the official 9.1 release, or if you want to try the latest 9.1_STABLE version: https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/images/NetBSD-9.1_STABLE-amd64-install.img.gz (note the different hostname) Martin
Where is NetBSD-9.1-amd64-install.img.gz
I believe this is the file I want to put on my USB stick. The ftp looked to be taking over a half an hour at ftp.netbsd.org. Is there a better site for a simple download? Thank you. -- RSB
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Just a "me too" comment. I'm using openjdk8 on NetBSD/amd64 for a wildfly gradle project in IntelliJ. Any attempt to use openjdk11 fails - wildfly starts but cannot accept any http connections - gradle build hangs - intellij randomly hangs/cannot connect debugger to running java
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
You could also try sdkman (link below) https://sdkman.io/ I have found that to work fairly consistently. On Tue, 12 Jan 2021, 2:54 pm ts1000, wrote: > Nope, did not try that yet. > My goal is to create a development environment > for java backend work > > That encompasses gradle, openJDK11 (cannot use openjdk8 for my project, > openJDK8 works with gradle by the way), IntelliJ IDE, postgres 12. > > Stuck on gradle at the moment. I tried kdump to see if I can pick up > anything, but the complexity and depth of interaction amongst OS, C/C++ > libraries, OpenJDK11, Gradle is just staggering. > > At this point, I know that OpenJDK8 works with gradle. > I also know that OpenJDK11 can run other java programs (eg KeyExplorer). > But Gradle is probably using something in OpenJDK11 that does not have a > correct implementation somewhere below. > > > On 2021-01-11 23:27, Martin wrote: > > Hey, > > Have you tried running Java through NetBSD's Linux compatibility > > layer. >
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Hey, Have you tried running Java through NetBSD's Linux compatibility layer. I believe it's Suse Linux. I don't remember if NetBSD does it by default or not using pkgin, I know that FreeBSD will if your installing it via their package manager. On Tue, 12 Jan 2021, 6:57 am ts1000, wrote: > Sorry meant NetBSD9.1 not NetBSD9.2 > > On 2021-01-11 19:16, ts1000 wrote: > > FYI, if somebody is still interested in the openjdk11+gradle conundrum > > I retested today: OpenJDK11+Gradle still, unfortunately, does not work > > on NetBSD9.1 with most reset package release Q4-2020 > > > > > > On 2020-11-20 01:59, ts1000 wrote: > >> Hello, > >> wanted to bump up my question to see if anybody could help. > >> Also, if I may, I wanted to ask if this group is the right question > >> about using NetBSD as a development environment (using OpenJDK11 in my > >> case). Or if there are other forums more specialized for this topic. > >> > >> thank you in advance > >> > >> On 2020-11-07 18:08, ts1000 wrote: > >>> Wanted to check if anybody has gradle working with OpenJDK 11 on > >>> OpenBSD 9.1 > >>> I cannot get it to work at all. > >>> > >>> not even: > >>> > >>> gradle status > >>> or > >>> gradle init > >>> > >>> I have tried going back to Gradle versions that are over 1 year old, > >>> and still same issue > >>> > >>> > >>> [... ] >
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Nope, did not try that yet. My goal is to create a development environment for java backend work That encompasses gradle, openJDK11 (cannot use openjdk8 for my project, openJDK8 works with gradle by the way), IntelliJ IDE, postgres 12. Stuck on gradle at the moment. I tried kdump to see if I can pick up anything, but the complexity and depth of interaction amongst OS, C/C++ libraries, OpenJDK11, Gradle is just staggering. At this point, I know that OpenJDK8 works with gradle. I also know that OpenJDK11 can run other java programs (eg KeyExplorer). But Gradle is probably using something in OpenJDK11 that does not have a correct implementation somewhere below. On 2021-01-11 23:27, Martin wrote: Hey, Have you tried running Java through NetBSD's Linux compatibility layer.
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Sorry meant NetBSD9.1 not NetBSD9.2 On 2021-01-11 19:16, ts1000 wrote: FYI, if somebody is still interested in the openjdk11+gradle conundrum I retested today: OpenJDK11+Gradle still, unfortunately, does not work on NetBSD9.1 with most reset package release Q4-2020 On 2020-11-20 01:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue [... ]
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
FYI, if somebody is still interested in the openjdk11+gradle conundrum I retested today: OpenJDK11+Gradle still, unfortunately, does not work on NetBSD9.2 with most reset package release Q4-2020 On 2020-11-20 01:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue [... ]
No HDMI audio with NetBSD 9.1 on NUC7i5DNKE
Hello all, my new NUC7i5DNKE is not providing audio output at the moment. The built-in sound chip is recognised as hdaudio and apparently also (partially) configured. Nevertheless, I do not get any usable audio devices displayed with audiocfg list. The NUC7i5DNKE has no line-out output. The only way to get audio out of it is through the HDMI interface. I have read elsewhere that HDAUDIO_ENABLE_HDMI must first be enabled as an option in a custom kernel. I did that, in parallel with the option HDAUDIOVERBOSE. Unfortunately, audiocfg still lists no usable audio devices. The relevant part of the kernel log I do post below. Do I have an obvious problem here? In which direction would I have to research? I would be very happy to receive some tips on this. Kind regards Matthias [ 1,008964] hdaudio0 at pci0 dev 31 function 3: HD Audio Controller [ 1,008964] hdaudio0: interrupting at msi4 vec 0 [ 1,008964] hdaudio0: High Definition Audio version 1.0 [ 1,008964] hdaudio0: OSS 9 ISS 7 BSS 0 SDO 1 64-bit [ 1,008964] hdaudio0: using 1024 byte CORB (cap 4) [ 1,008964] hdaudio0: using 2048 byte RIRB (cap 4) [ 1,008964] hdaudio0: cmd : request 0F00 (00) [ 1,008964] hdaudio0: cmd : response 8086280B 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0004 (00) [ 1,008964] hdaudio0: cmd : response 00010001 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0002 (00) [ 1,008964] hdaudio0: cmd : response 0010 0002 [ 1,008964] hdaudio0: Codec02: 8086:280B HDA 1.0 rev 0 stepping 0 [ 1,008964] hdaudio0: cmd : request 0F00 0005 (01) [ 1,008964] hdaudio0: cmd : response 0001 0002 [ 1,008964] hdafg0 at hdaudio0: Intel product 280b [ 1,008964] hdafg0: parsing widgets [ 1,008964] hdaudio0: cmd : request 0F00 0004 (01) [ 1,008964] hdaudio0: cmd : response 00020002 0002 [ 1,008964] hdafg0: afg start 02 end 04 nwidgets 2 [ 1,008964] hdafg0: powering up widgets [ 1,008964] hdaudio0: cmd : request 0705 (01) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0705 (02) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0705 (03) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0008 (01) [ 1,008964] hdaudio0: cmd : response 0004 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000B (01) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000A (01) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0012 (01) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000D (01) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000F (01) [ 1,008964] hdaudio0: cmd : response C009 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0011 (01) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdafg0: afg widgets 0xe866eb2afa00-0xe866eb2afc30 [ 1,008964] hdaudio0: cmd : request 0F00 0009 (02) [ 1,008964] hdaudio0: cmd : response 6611 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0009 (03) [ 1,008964] hdaudio0: cmd : response 0040778D 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0009 (02) [ 1,008964] hdaudio0: cmd : response 6611 0002 [ 1,008964] hdaudio0: cmd : request 0F1C (02) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000E (02) [ 1,008964] hdaudio0: cmd : response 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000B (02) [ 1,008964] hdaudio0: cmd : response 0005 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000A (02) [ 1,008964] hdaudio0: cmd : response 001A07F0 0002 [ 1,008964] hdaudio0: cmd : request 0F00 0009 (03) [ 1,008964] hdaudio0: cmd : response 0040778D 0002 [ 1,008964] hdaudio0: cmd : request 0F1C (03) [ 1,008964] hdaudio0: cmd : response 18560010 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000E (03) [ 1,008964] hdaudio0: cmd : response 0001 0002 [ 1,008964] hdaudio0: cmd : request 0F02 (03) [ 1,008964] hdaudio0: cmd : response 0002 0002 [ 1,008964] hdafg0: add connection 03->02 [ 1,008964] hdaudio0: cmd : request 0F00 0012 (03) [ 1,008964] hdaudio0: cmd : response 8000 0002 [ 1,008964] hdaudio0: cmd : request 0F00 000C (03) [ 1,008964] hdaudio0: cmd : response 0994
Re: RPI 1 and Netbsd 9.1
On Mon, Dec 07, 2020 at 07:13:55PM -0500, Clark Chapman wrote: > I have an RPI1 running Netbsd 8.1. I tried to install release 9.1 using the > earmv6hf install image. After the installer starts to create the filesystems > I get > > Command Failed > /sbin/newfs_msdos /dev/rlb0d > > and > > execvp /sbin/newfs_msdos > No such file or directory. > > Does anyone have an idea what is wrong? You best bet are the bootable images from armbsd.org (for a new install) or manually updating an existing installation. The evbarm port unfortunately is by an order of magnitude the worst port due to the manifold of different boot environments and required firmware setups, and the installer has not been tested on many of them. Martin
RPI 1 and Netbsd 9.1
I have an RPI1 running Netbsd 8.1. I tried to install release 9.1 using the earmv6hf install image. After the installer starts to create the filesystems I get Command Failed /sbin/newfs_msdos /dev/rlb0d and execvp /sbin/newfs_msdos No such file or directory. Does anyone have an idea what is wrong?
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 22.11.2020 23:50, ts1000 wrote: Thank you. I noticed that when building openJDK11 there was an option to enable 'dtrace' support. I thought that dtrace is not ktrace, so I did not enable it. Should I first rebuild OpenJDK11 with dtrace support ? Not needed for sure. Dtrace is just there in system $ sudo dtrace -l | wc -l 52623 $ and not so bad compared to OpenIndiana $ sudo dtrace -l | wc -l │[19:37:58:322] [4591:0002] [INFO][com.freerdp.client.x11] - Closed from X1 83420 $ that stuff in OpenJDK can be additional support for probes and developers or specific Java probes as mentioned here on FBSD https://forums.freebsd.org/threads/dtrace-openjdk12.71470/ and here is related info too https://github.com/AdoptOpenJDK/openjdk-build/issues/1242 BTW it is a tool you have available on NetBSD, FreeBSDm OpenIndiana, Illumos, SmartOS, Apple (Xcode/Instruments), Solaris 10,11 and probably soon even on Windows https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace I found even some good material working even on Gradle, but not sure how much of that is applicable here, still Java comes from Sun/Oracle as well as Dtrace so not everything may be there https://www.oracle.com/technetwork/systems/hands-on-labs/hol-uncover-jdk8-secrets-dtrace-2798366.html On 2020-11-22 19:47, Bodie wrote: On 22.11.2020 06:56, ts1000 wrote: Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. DTrace for the victory I would say ;-) Start with this one http://dlc.openindiana.org/docs/osol/20090715/DYNMCTRCGGD/html/chp-intro-5.html That example for rw.d works just fine at least on NetBSD current (but I think on 9.1 stable too) Those system calls to lwp are covered by available providers: $ sudo dtrace -l -P syscall | grep lwp 812syscall _lwp_create entry 813syscall _lwp_create return 814syscall _lwp_exit entry 815syscall _lwp_exit return 816syscall _lwp_self entry 817syscall _lwp_self return 818syscall _lwp_wait entry 819syscall _lwp_wait return 820syscall_lwp_suspend entry 821syscall_lwp_suspend return 822syscall _lwp_continue entry 823syscall _lwp_continue return 824syscall _lwp_wakeup entry 825syscall _lwp_wakeup return 826syscall _lwp_getprivate entry 827syscall _lwp_getprivate return 828syscall _lwp_setprivate entry 829syscall _lwp_setprivate return 830syscall _lwp_kill entry 831syscall _lwp_kill return 832syscall _lwp_detach entry 833syscall _lwp_detach return 834syscall compat_50__lwp_park entry 835syscall compat_50__lwp_park return 836syscall _lwp_unpark entry 837syscall _lwp_unpark return 838syscall _lwp_unpark_all entry 839syscall
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Thank you. I noticed that when building openJDK11 there was an option to enable 'dtrace' support. I thought that dtrace is not ktrace, so I did not enable it. Should I first rebuild OpenJDK11 with dtrace support ? On 2020-11-22 19:47, Bodie wrote: On 22.11.2020 06:56, ts1000 wrote: Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. DTrace for the victory I would say ;-) Start with this one http://dlc.openindiana.org/docs/osol/20090715/DYNMCTRCGGD/html/chp-intro-5.html That example for rw.d works just fine at least on NetBSD current (but I think on 9.1 stable too) Those system calls to lwp are covered by available providers: $ sudo dtrace -l -P syscall | grep lwp 812syscall _lwp_create entry 813syscall _lwp_create return 814syscall _lwp_exit entry 815syscall _lwp_exit return 816syscall _lwp_self entry 817syscall _lwp_self return 818syscall _lwp_wait entry 819syscall _lwp_wait return 820syscall_lwp_suspend entry 821syscall_lwp_suspend return 822syscall _lwp_continue entry 823syscall _lwp_continue return 824syscall _lwp_wakeup entry 825syscall _lwp_wakeup return 826syscall _lwp_getprivate entry 827syscall _lwp_getprivate return 828syscall _lwp_setprivate entry 829syscall _lwp_setprivate return 830syscall _lwp_kill entry 831syscall _lwp_kill return 832syscall _lwp_detach entry 833syscall _lwp_detach return 834syscall compat_50__lwp_park entry 835syscall compat_50__lwp_park return 836syscall _lwp_unpark entry 837syscall _lwp_unpark return 838syscall _lwp_unpark_all entry 839syscall _lwp_unpark_all return 840syscall_lwp_setname entry 841syscall_lwp_setname return 842syscall_lwp_getname entry 843syscall_lwp_getname return 844syscall_lwp_ctl entry 845syscall_lwp_ctl return 1062syscall compat_60__lwp_park entry 1063syscall compat_60__lwp_park return 1150syscall _lwp_park entry 1151syscall _lwp_park return $ With predicate like /errno = 60/ you can get for start at least how many times it happens during your run without modifying anything and soon you will learn way more how to get details which will be very usable in your work anyway. Sure you can somewhat get some of the results with ktrace/ktruss, but as you
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 22.11.2020 06:56, ts1000 wrote: Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. DTrace for the victory I would say ;-) Start with this one http://dlc.openindiana.org/docs/osol/20090715/DYNMCTRCGGD/html/chp-intro-5.html That example for rw.d works just fine at least on NetBSD current (but I think on 9.1 stable too) Those system calls to lwp are covered by available providers: $ sudo dtrace -l -P syscall | grep lwp 812syscall _lwp_create entry 813syscall _lwp_create return 814syscall _lwp_exit entry 815syscall _lwp_exit return 816syscall _lwp_self entry 817syscall _lwp_self return 818syscall _lwp_wait entry 819syscall _lwp_wait return 820syscall_lwp_suspend entry 821syscall_lwp_suspend return 822syscall _lwp_continue entry 823syscall _lwp_continue return 824syscall _lwp_wakeup entry 825syscall _lwp_wakeup return 826syscall _lwp_getprivate entry 827syscall _lwp_getprivate return 828syscall _lwp_setprivate entry 829syscall _lwp_setprivate return 830syscall _lwp_kill entry 831syscall _lwp_kill return 832syscall _lwp_detach entry 833syscall _lwp_detach return 834syscall compat_50__lwp_park entry 835syscall compat_50__lwp_park return 836syscall _lwp_unpark entry 837syscall _lwp_unpark return 838syscall _lwp_unpark_all entry 839syscall _lwp_unpark_all return 840syscall_lwp_setname entry 841syscall_lwp_setname return 842syscall_lwp_getname entry 843syscall_lwp_getname return 844syscall_lwp_ctl entry 845syscall_lwp_ctl return 1062syscall compat_60__lwp_park entry 1063syscall compat_60__lwp_park return 1150syscall _lwp_park entry 1151syscall _lwp_park return $ With predicate like /errno = 60/ you can get for start at least how many times it happens during your run without modifying anything and soon you will learn way more how to get details which will be very usable in your work anyway. Sure you can somewhat get some of the results with ktrace/ktruss, but as you saw digging out of those million lines is not exactly fun On 2020-11-22 03:02, Kamil Rytarowski wrote: I just ran into it independently on NetBSD/amd64 current 9.99.x. On 20.11.2020 02:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. On 2020-11-22 03:02, Kamil Rytarowski wrote: I just ran into it independently on NetBSD/amd64 current 9.99.x. On 20.11.2020 02:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue https://github.com/gradle/gradle/issues/15087 I am thinking that something might be wrong with my sysctl.conf or login.conf or something else. If there are suggestions on what to look for next, would very much appreciate. -- my sysctl.conf -- nbsd1$ cat /etc/sysctl.conf #!/sbin/sysctl -f # # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ # # sysctl(8) variables to set at boot time. # Default on panic: dump core and reboot. See savecore(8) for information. # Switch this to 1 if you want to enter the kernel debugger on crashes # instead. See ddb(4) for an introduction and also try the "help" command # at the db> prompt. # If you understand the implication and want to change the behaviour before # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see options(4). ddb.onpanic?=0 # Default core name template: #kern.defcorename=%n.core # Number of kernel threads to use for NFS client #vfs.nfs.iothreads=4 # Default tty/pty character queue sizes. Should be bumped to 32K or so if # used in networking (ppp/pppoe) kern.tty.qsize=32000 #v-start kern.ipc.shmmaxpgs=32768 kern.sbmax=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.init_win=10 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.init_win_local=10 net.inet.tcp.congctl.selected=cubic #this is invalid net.inet.ip.ifq.maxlen = 4096 net.inet.tcp.delack_ticks=5 kern.maxfiles = 10 kern.maxproc = 10044 kern.posix.semmax = 10128 #v-endnbsd1$ -- my login .conf -- staff:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=1024M:\ :maxproc-max=1044:\ :maxproc-cur=1024:\ :openfiles-cur=512:\ :openfiles-max=104512:\ :stacksize-cur=128M: :copyright=/dev/null: :ignorenologin:\ :requirehome@: -- ulimit -a -- time (-t seconds ) unlimited file (-f blocks ) unlimited data (-d kbytes ) 1048576 stack (-s kbytes ) 114688 coredump (-c blocks ) unlimited memory (-m kbytes ) 8022248 locked memory (-l kbytes ) 2674082 thread (-r threads ) 1024 process (-p processes ) 1024 nofiles (-n descriptors) 512 vmemory (-v kbytes ) unlimited sbsize (-b bytes ) unlimited -- java -version -- $ java -version openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
I just ran into it independently on NetBSD/amd64 current 9.99.x. On 20.11.2020 02:59, ts1000 wrote: > Hello, > wanted to bump up my question to see if anybody could help. > Also, if I may, I wanted to ask if this group is the right question > about using NetBSD as a development environment (using OpenJDK11 in my > case). Or if there are other forums more specialized for this topic. > > thank you in advance > > On 2020-11-07 18:08, ts1000 wrote: >> Wanted to check if anybody has gradle working with OpenJDK 11 on >> OpenBSD 9.1 >> I cannot get it to work at all. >> >> not even: >> >> gradle status >> or >> gradle init >> >> I have tried going back to Gradle versions that are over 1 year old, >> and still same issue >> >> https://github.com/gradle/gradle/issues/15087 >> >> >> I am thinking that something might be wrong with my sysctl.conf or >> login.conf or something else. >> If there are suggestions on what to look for next, would very much >> appreciate. >> >> >> -- my sysctl.conf -- >> >> nbsd1$ cat /etc/sysctl.conf >> #!/sbin/sysctl -f >> # >> # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ >> # >> # sysctl(8) variables to set at boot time. >> >> # Default on panic: dump core and reboot. See savecore(8) for >> information. >> # Switch this to 1 if you want to enter the kernel debugger on crashes >> # instead. See ddb(4) for an introduction and also try the "help" command >> # at the db> prompt. >> # If you understand the implication and want to change the behaviour >> before >> # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see >> options(4). >> ddb.onpanic?=0 >> >> # Default core name template: >> #kern.defcorename=%n.core >> >> # Number of kernel threads to use for NFS client >> #vfs.nfs.iothreads=4 >> >> # Default tty/pty character queue sizes. Should be bumped to 32K or so if >> # used in networking (ppp/pppoe) >> kern.tty.qsize=32000 >> >> #v-start >> kern.ipc.shmmaxpgs=32768 >> >> kern.sbmax=8388608 >> net.inet.tcp.sendspace=3217968 >> net.inet.tcp.recvspace=3217968 >> >> net.inet.tcp.init_win=10 >> >> >> >> net.inet.tcp.recvbuf_auto=1 >> net.inet.tcp.sendbuf_auto=1 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> >> >> net.inet.tcp.init_win_local=10 >> >> >> net.inet.tcp.congctl.selected=cubic >> #this is invalid net.inet.ip.ifq.maxlen = 4096 >> net.inet.tcp.delack_ticks=5 >> >> kern.maxfiles = 10 >> kern.maxproc = 10044 >> kern.posix.semmax = 10128 >> #v-endnbsd1$ >> >> -- my login .conf -- >> >> >> staff:\ >> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin >> /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ >> :umask=022:\ >> :datasize-max=infinity:\ >> :datasize-cur=1024M:\ >> :maxproc-max=1044:\ >> :maxproc-cur=1024:\ >> :openfiles-cur=512:\ >> :openfiles-max=104512:\ >> :stacksize-cur=128M: >> :copyright=/dev/null: >> :ignorenologin:\ >> :requirehome@: >> >> >> >> >> -- ulimit -a -- >> >> time (-t seconds ) unlimited >> file (-f blocks ) unlimited >> data (-d kbytes ) 1048576 >> stack (-s kbytes ) 114688 >> coredump (-c blocks ) unlimited >> memory (-m kbytes ) 8022248 >> locked memory (-l kbytes ) 2674082 >> thread (-r threads ) 1024 >> process (-p processes ) 1024 >> nofiles (-n descriptors) 512 >> vmemory (-v kbytes ) unlimited >> sbsize (-b bytes ) unlimited >> >> -- java -version -- >> $ java -version >> openjdk version "11.0.8-internal" 2020-07-14 >> OpenJDK Runtime Environment (build >> 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) >> OpenJDK 64-Bit Server VM (build >> 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed >> mode) signature.asc Description: OpenPGP digital signature
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
ts1000 writes: > It seems that gradle is: > placing a lock on a file somewhere in ~/.gradle directory > then, I presume it writes to it. > > Then it tries to remove the lock, and then close the file. > > Somewhere there there seem to be an error. That sounds promising. > There is also an error about a file missing: > > 15850 25 java NAMI "/usr/share/nls/nls.alias.db" > > I am not sure what this file represents or if it is relevant. This is unlikely to be important. > > And from there on, I see timeouts.. i am presuming that because that > file is not properly closed >15850 17 java RET ___lwp_park60 -1 errno 60 Connection > timed out In the kdump output, you can find a file descriptor when a file gets opened, and then that same value in subsequent calls. The goal is to find the system call that either has clearly bad arguments or an unexpected return value. In this case, this is thread 17, and a return of -1 errno 60 means that the time given in _lwp_park expired before wakup. You can give the -T flag to kdump and see the times of all the calls. I did not mean to suggest this is easy to resolve, but I think you are making progress. You might try to find the code that is doing the locking/closing and see what syscalls are made and then go read the POSIX specs for those and make sure the usage is legal.
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc790) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL _lwp_unpark_all(0x7db1b64c10f8,1,0x7db1b9668140) 15850 12 java RET _lwp_unpark_all 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 14 java RET ___lwp_park60 0 15850 12 java RET __clock_gettime50 0 15850 14 java CALL __gettimeofday50(0x7db1980efd30,0) 15850 14 java RET __gettimeofday50 0 15850 14 java CALL ___lwp_park60(0,1,0x7db1980efd60,0,0x7db1b9668140,0x7db1b9668140) 15850 12 java CALL __clock_gettime50(3,0x7db1989df880) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989df970) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dfd40) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __gettimeofday50(0x7db1989dfbd0,0) 15850 12 java RET __gettimeofday50 0 15850 12 java CALL ___lwp_park60(0,1,0x7db1989dfc00,0,0x7db1b9667340,0x7db1b9667340) 15850 17 java RET ___lwp_park60 -1 errno 60 Connection timed out 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __clock_gettime50(3,0x7db1976efde0) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __gettimeofday50(0x7db1976efd40,0) 15850 17 java RET __gettimeofday50 0 15850 17 java CALL ___lwp_park60(0,1,0x7db1976efd70,0,0x7db1b87f6440,0x7db1b87f6440) 15850 17 java RET ___lwp_park60 -1 errno 60 Connection timed out 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 On 2020-11-21 06:10, Bodie wrote: On 21.11.2020 03:49, ts1000 wrote: Thank you for the follow up in regards to gradle on openjdk11 with NetBSD 9.1 0) Running NetBSD 9.1 amd64 within Virtual Box on windows host. Allocated to it the box 8gb and 4 cores the underlying disk (that vbox is using is an Intel SSD) 1) following your suggestion I installed openJDK8 from binary packages (I use pkgin) and: gradle status worked with that older version of the openJDK (I tried both the most recent gradle 6.7 and older gradle 5.4 .. both work) 2) OpenJDK11 from binary packages the above command does not work 3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not work either it basically hangs as I described earlier, the full message dump is: nbsd1$ gradle -d status - My openJDK11 version (compiled from pkgsrc) openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
java CALL __clock_gettime50(3,0x7db1989de180) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc790) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL _lwp_unpark_all(0x7db1b64c10f8,1,0x7db1b9668140) 15850 12 java RET _lwp_unpark_all 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 14 java RET ___lwp_park60 0 15850 12 java RET __clock_gettime50 0 15850 14 java CALL __gettimeofday50(0x7db1980efd30,0) 15850 14 java RET __gettimeofday50 0 15850 14 java CALL ___lwp_park60(0,1,0x7db1980efd60,0,0x7db1b9668140,0x7db1b9668140) 15850 12 java CALL __clock_gettime50(3,0x7db1989df880) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989df970) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dfd40) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __gettimeofday50(0x7db1989dfbd0,0) 15850 12 java RET __gettimeofday50 0 15850 12 java CALL ___lwp_park60(0,1,0x7db1989dfc00,0,0x7db1b9667340,0x7db1b9667340) 15850 17 java RET ___lwp_park60 -1 errno 60 Connection timed out 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __clock_gettime50(3,0x7db1976efde0) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __gettimeofday50(0x7db1976efd40,0) 15850 17 java RET __gettimeofday50 0 15850 17 java CALL ___lwp_park60(0,1,0x7db1976efd70,0,0x7db1b87f6440,0x7db1b87f6440) 15850 17 java RET ___lwp_park60 -1 errno 60 Connection timed out 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 On 2020-11-21 06:10, Bodie wrote: On 21.11.2020 03:49, ts1000 wrote: Thank you for the follow up in regards to gradle on openjdk11 with NetBSD 9.1 0) Running NetBSD 9.1 amd64 within Virtual Box on windows host. Allocated to it the box 8gb and 4 cores the underlying disk (that vbox is using is an Intel SSD) 1) following your suggestion I installed openJDK8 from binary packages (I use pkgin) and: gradle status worked with that older version of the openJDK (I tried both the most recent gradle 6.7 and older gradle 5.4 .. both work) 2) OpenJDK11 from binary packages the above command does not work 3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not work either it basically hangs as I described earlier, the full message dump is: nbsd1$ gradle -d status - My openJDK11 version (compiled from pkgsrc) openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
5850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc790) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL _lwp_unpark_all(0x7db1b64c10f8,1,0x7db1b9668140) 15850 12 java RET _lwp_unpark_all 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dc7f0) 15850 14 java RET ___lwp_park60 0 15850 12 java RET __clock_gettime50 0 15850 14 java CALL __gettimeofday50(0x7db1980efd30,0) 15850 14 java RET __gettimeofday50 0 15850 14 java CALL ___lwp_park60(0,1,0x7db1980efd60,0,0x7db1b9668140,0x7db1b9668140) 15850 12 java CALL __clock_gettime50(3,0x7db1989df880) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989df970) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dfd40) 15850 12 java RET __clock_gettime50 0 15850 12 java CALL __gettimeofday50(0x7db1989dfbd0,0) 15850 12 java RET __gettimeofday50 0 15850 12 java CALL ___lwp_park60(0,1,0x7db1989dfc00,0,0x7db1b9667340,0x7db1b9667340) 15850 17 java RET ___lwp_park60 -1 errno 60 Connection timed out 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __clock_gettime50(3,0x7db1976efde0) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 15850 17 java CALL __gettimeofday50(0x7db1976efd40,0) 15850 17 java RET __gettimeofday50 0 15850 17 java CALL ___lwp_park60(0,1,0x7db1976efd70,0,0x7db1b87f6440,0x7db1b87f6440) 15850 17 java RET ___lwp_park60 -1 errno 60 Connection timed out 15850 17 java CALL __clock_gettime50(3,0x7db1976efe30) 15850 17 java RET __clock_gettime50 0 On 2020-11-21 06:10, Bodie wrote: On 21.11.2020 03:49, ts1000 wrote: Thank you for the follow up in regards to gradle on openjdk11 with NetBSD 9.1 0) Running NetBSD 9.1 amd64 within Virtual Box on windows host. Allocated to it the box 8gb and 4 cores the underlying disk (that vbox is using is an Intel SSD) 1) following your suggestion I installed openJDK8 from binary packages (I use pkgin) and: gradle status worked with that older version of the openJDK (I tried both the most recent gradle 6.7 and older gradle 5.4 .. both work) 2) OpenJDK11 from binary packages the above command does not work 3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not work either it basically hangs as I described earlier, the full message dump is: nbsd1$ gradle -d status - My openJDK11 version (compiled from pkgsrc) openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 21.11.2020 03:49, ts1000 wrote:
Thank you for the follow up in regards to gradle on openjdk11 with
NetBSD 9.1
0) Running NetBSD 9.1 amd64 within Virtual Box on windows host.
Allocated to it the box 8gb and 4 cores
the underlying disk (that vbox is using is an Intel SSD)
1) following your suggestion I installed openJDK8 from binary packages
(I use pkgin)
and:
gradle status
worked with that older version of the openJDK (I tried both the most
recent gradle 6.7 and older gradle 5.4 .. both work)
2) OpenJDK11 from binary packages the above command does not work
3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not
work either
it basically hangs as I described earlier, the full message dump is:
nbsd1$ gradle -d status
2020-11-21T02:11:20.275+ [DEBUG]
[org.gradle.internal.nativeintegration.services.NativeServices]
Native-platform is not available.
2020-11-21T02:11:20.549+ [INFO]
[org.gradle.internal.nativeintegration.services.NativeServices]
Initialized native services in: /home/v/.gradle/native
2020-11-21T02:11:20.623+ [LIFECYCLE]
[org.gradle.launcher.cli.DebugLoggerWarningAction]
#
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
WARNING
Debug level logging will leak security sensitive information!
https://docs.gradle.org/6.7/userguide/logging.html#sec:debug_security
#
2020-11-21T02:11:21.000+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Native-platform file system integration is not available. Continuing
with fallback.
2020-11-21T02:11:21.108+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Using Jdk7Symlink implementation as symlink.
2020-11-21T02:11:22.275+ [DEBUG]
[org.gradle.launcher.daemon.client.DaemonClient] Executing build
04bc315f-ebb4-4e65-b3f9-60b4eb16d648 in daemon client {pid=6432}
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface lo0
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? true
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding
loopback address /127.0.0.1
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface wm0
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? false
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote
address /10.0.2.15
2020-11-21T02:11:22.387+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.408+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.424+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.434+ [DEBUG]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Getting
daemon stop events
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.441+ [INFO]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry]
Removing 0 daemon stop events from registry
2020-11-21T02:11:22.448+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
exclusive lock on daemon addresses registry.
2020-11-21T02:11:22.454+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.467+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.476+ [LIFECYCLE]
[org.gradle.launcher.daemon.client.DefaultDaemonConnector] Starting a
Gradle Daemon (subsequent builds will be faster)
2020-11-21T02:11:22.657+ [DEBUG]
[org.gradle.launcher.daemon.client.DefaultDaemonStarter] Using daemon
args: [/usr/pkg/java/openjdk11/bin/java, --add-opens,
java.base/java.util=ALL-UNNAMED, --add-opens,
java.base/java.lang=ALL-UNNAMED, --add-opens,
java.base/java.lang.invoke=ALL-UNNAMED, --add-opens,
java.prefs/java.util.prefs=ALL-UNNAMED, -XX:MaxMetaspaceSize=256m,
-XX:+HeapDumpOnOutOfMemoryError, -Xms256m, -Xmx512m,
-Dfile.encoding=US-ASCII, -Duser.country=US
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Thank you for the follow up in regards to gradle on openjdk11 with
NetBSD 9.1
0) Running NetBSD 9.1 amd64 within Virtual Box on windows host.
Allocated to it the box 8gb and 4 cores
the underlying disk (that vbox is using is an Intel SSD)
1) following your suggestion I installed openJDK8 from binary packages
(I use pkgin)
and:
gradle status
worked with that older version of the openJDK (I tried both the most
recent gradle 6.7 and older gradle 5.4 .. both work)
2) OpenJDK11 from binary packages the above command does not work
3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not
work either
it basically hangs as I described earlier, the full message dump is:
nbsd1$ gradle -d status
2020-11-21T02:11:20.275+ [DEBUG]
[org.gradle.internal.nativeintegration.services.NativeServices]
Native-platform is not available.
2020-11-21T02:11:20.549+ [INFO]
[org.gradle.internal.nativeintegration.services.NativeServices]
Initialized native services in: /home/v/.gradle/native
2020-11-21T02:11:20.623+ [LIFECYCLE]
[org.gradle.launcher.cli.DebugLoggerWarningAction]
#
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
WARNING
Debug level logging will leak security sensitive information!
https://docs.gradle.org/6.7/userguide/logging.html#sec:debug_security
#
2020-11-21T02:11:21.000+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Native-platform file system integration is not available. Continuing
with fallback.
2020-11-21T02:11:21.108+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Using Jdk7Symlink implementation as symlink.
2020-11-21T02:11:22.275+ [DEBUG]
[org.gradle.launcher.daemon.client.DaemonClient] Executing build
04bc315f-ebb4-4e65-b3f9-60b4eb16d648 in daemon client {pid=6432}
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface lo0
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? true
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding loopback
address /127.0.0.1
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface wm0
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? false
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote
address /10.0.2.15
2020-11-21T02:11:22.387+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.408+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.424+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.434+ [DEBUG]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Getting
daemon stop events
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.441+ [INFO]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Removing
0 daemon stop events from registry
2020-11-21T02:11:22.448+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
exclusive lock on daemon addresses registry.
2020-11-21T02:11:22.454+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.467+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.476+ [LIFECYCLE]
[org.gradle.launcher.daemon.client.DefaultDaemonConnector] Starting a
Gradle Daemon (subsequent builds will be faster)
2020-11-21T02:11:22.657+ [DEBUG]
[org.gradle.launcher.daemon.client.DefaultDaemonStarter] Using daemon
args: [/usr/pkg/java/openjdk11/bin/java, --add-opens,
java.base/java.util=ALL-UNNAMED, --add-opens,
java.base/java.lang=ALL-UNNAMED, --add-opens,
java.base/java.lang.invoke=ALL-UNNAMED, --add-opens,
java.prefs/java.util.prefs=ALL-UNNAMED, -XX:MaxMetaspaceSize=256m,
-XX:+HeapDumpOnOutOfMemoryError, -Xms256m, -Xmx512m,
-Dfile.encoding=US-ASCII
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
ts1000 writes: > wanted to bump up my question to see if anybody could help. > Also, if I may, I wanted to ask if this group is the right question > about using NetBSD as a development environment (using OpenJDK11 in my > case). Or if there are other forums more specialized for this topic. This is the right place. Perhaps people didn't reply because your original message said OpenBSD, and perhaps because nobody else is trying to use this. I would suggest trying with all the JDKs you can. There are 6 in pkgsrc. My other suggestions use ktrace try to understand what kind of shared memory is needed and perhaps incrase that explain what you did exactly. You didn't address if this is from pkgsrc or where you got JDK and gradle. signature.asc Description: PGP signature
Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue https://github.com/gradle/gradle/issues/15087 I am thinking that something might be wrong with my sysctl.conf or login.conf or something else. If there are suggestions on what to look for next, would very much appreciate. -- my sysctl.conf -- nbsd1$ cat /etc/sysctl.conf #!/sbin/sysctl -f # # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ # # sysctl(8) variables to set at boot time. # Default on panic: dump core and reboot. See savecore(8) for information. # Switch this to 1 if you want to enter the kernel debugger on crashes # instead. See ddb(4) for an introduction and also try the "help" command # at the db> prompt. # If you understand the implication and want to change the behaviour before # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see options(4). ddb.onpanic?=0 # Default core name template: #kern.defcorename=%n.core # Number of kernel threads to use for NFS client #vfs.nfs.iothreads=4 # Default tty/pty character queue sizes. Should be bumped to 32K or so if # used in networking (ppp/pppoe) kern.tty.qsize=32000 #v-start kern.ipc.shmmaxpgs=32768 kern.sbmax=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.init_win=10 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.init_win_local=10 net.inet.tcp.congctl.selected=cubic #this is invalidnet.inet.ip.ifq.maxlen = 4096 net.inet.tcp.delack_ticks=5 kern.maxfiles = 10 kern.maxproc = 10044 kern.posix.semmax = 10128 #v-endnbsd1$ -- my login .conf -- staff:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=1024M:\ :maxproc-max=1044:\ :maxproc-cur=1024:\ :openfiles-cur=512:\ :openfiles-max=104512:\ :stacksize-cur=128M: :copyright=/dev/null: :ignorenologin:\ :requirehome@: -- ulimit -a -- time (-t seconds) unlimited file (-f blocks ) unlimited data (-d kbytes ) 1048576 stack (-s kbytes ) 114688 coredump (-c blocks ) unlimited memory(-m kbytes ) 8022248 locked memory (-l kbytes ) 2674082 thread(-r threads) 1024 process (-p processes ) 1024 nofiles (-n descriptors) 512 vmemory (-v kbytes ) unlimited sbsize(-b bytes ) unlimited -- java -version -- $ java -version openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
[q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue https://github.com/gradle/gradle/issues/15087 I am thinking that something might be wrong with my sysctl.conf or login.conf or something else. If there are suggestions on what to look for next, would very much appreciate. -- my sysctl.conf -- nbsd1$ cat /etc/sysctl.conf #!/sbin/sysctl -f # # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ # # sysctl(8) variables to set at boot time. # Default on panic: dump core and reboot. See savecore(8) for information. # Switch this to 1 if you want to enter the kernel debugger on crashes # instead. See ddb(4) for an introduction and also try the "help" command # at the db> prompt. # If you understand the implication and want to change the behaviour before # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see options(4). ddb.onpanic?=0 # Default core name template: #kern.defcorename=%n.core # Number of kernel threads to use for NFS client #vfs.nfs.iothreads=4 # Default tty/pty character queue sizes. Should be bumped to 32K or so if # used in networking (ppp/pppoe) kern.tty.qsize=32000 #v-start kern.ipc.shmmaxpgs=32768 kern.sbmax=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.init_win=10 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.init_win_local=10 net.inet.tcp.congctl.selected=cubic #this is invalidnet.inet.ip.ifq.maxlen = 4096 net.inet.tcp.delack_ticks=5 kern.maxfiles = 10 kern.maxproc = 10044 kern.posix.semmax = 10128 #v-endnbsd1$ -- my login .conf -- staff:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=1024M:\ :maxproc-max=1044:\ :maxproc-cur=1024:\ :openfiles-cur=512:\ :openfiles-max=104512:\ :stacksize-cur=128M: :copyright=/dev/null: :ignorenologin:\ :requirehome@: -- ulimit -a -- time (-t seconds) unlimited file (-f blocks ) unlimited data (-d kbytes ) 1048576 stack (-s kbytes ) 114688 coredump (-c blocks ) unlimited memory(-m kbytes ) 8022248 locked memory (-l kbytes ) 2674082 thread(-r threads) 1024 process (-p processes ) 1024 nofiles (-n descriptors) 512 vmemory (-v kbytes ) unlimited sbsize(-b bytes ) unlimited -- java -version -- $ java -version openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
Hi Bertrand, BERTRAND Joël wrote: > Just a question. Is it a Seagate disk ? On all servers I used this kind > of disks, Hardware ECC Recovered was always high (and in constant > increase). I have seen this issue on Linux and *BSD. And of course, I > considere Seagate as the worst disks that I can buy today. yes it is a Seagate disk, the code starts with "ST" in dmesg :) Riccardo
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
On Tue, 3 Nov 2020 11:48:41 +1030 Brett Lymn wrote: > On Mon, Nov 02, 2020 at 12:34:27PM +0100, BERTRAND Jol wrote: > > > > I refuse Seagate, Samsung and other WD in my servers or > > workstations, and I refuse SMR technology also. > > > > I have heard this sort of thing from many people over the years, they > get bitten by a few disk failures and form a bias based on that. I > used to do this too but found that it seems to change from model to > model. Here are some interesting stats from a large scale HDD > deployment: Which probably also depends on the actual disk usage - sequential vs random I/O, ambient temperature, etc. I don't trust any of those statistics, because I don't know if those disks were used under exactly the same conditions. There is also a big difference between consumer and enterprise disks, you get what you pay for.
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
On Mon, Nov 02, 2020 at 12:34:27PM +0100, BERTRAND Jol wrote: > > I refuse Seagate, Samsung and other WD in my servers or workstations, > and I refuse SMR technology also. > I have heard this sort of thing from many people over the years, they get bitten by a few disk failures and form a bias based on that. I used to do this too but found that it seems to change from model to model. Here are some interesting stats from a large scale HDD deployment: https://www.backblaze.com/blog/backblaze-hard-drive-stats-q2-2020/ Indeed, from these numbers, hitachi seem to be doing well overall but for the other manufacturers it really depends on the model you buy. As for SMR - it is not a big deal as long as you are aware of it (some manufacturers were caught out hiding the fact that a disk was SMR) and use the disk accordingly, there are some applications that SMR is particularly bad for - you don't want to use them for ZFS but for a NTFS/FFS file system they seem to be fine. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
On Mon 02 Nov 2020 at 08:39:00 +, Riccardo Mottola wrote: > I checked SMART status, it looks a little worrying: > SMART supported, SMART enabled > id value thresh crit collect reliability description raw > 5 100 36 yes online positiveReallocated sector count13 In my experience, the raw value for Reallocated sector count is typically indeed the count, and 13 (or anything other than 0) is quite worryingi in my mind. Once the disk starts going bad in one place, it will go in the rest too. I'd start the process of replacing the disk. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
On Mon, Nov 02, 2020 at 11:13:01AM +0100, BERTRAND Joël wrote: > Riccardo Mottola a écrit : > > Then this is the data for the third day (each time I did a power-off > > reboot, so it is not continuous operation, I shut down the laptop at night) > > > > SMART supported, SMART enabled > > id value thresh crit collect reliability description raw > > 1 60 34 yes online positive Raw read error rate > > 73875073 > > 3 96 0 yes online positive Spin-up time 0 > > 4 95 20 no online positive Start/stop count 6088 > > 5 100 36 yes online positive Reallocated sector count 13 > > 7 81 30 yes online positive Seek error rate > > 127050561 > > 9 95 0 no online positive Power-on hours count 4771 > > 10 100 34 yes online positive Spin retry count 0 > > 12 98 20 no online positive Device power cycle count 2793 > > 192 99 0 no online positive Power-off retract count 2794 > > 193 17 0 no online positive Load cycle count 166675 > > 194 28 0 no online positive Temperature 28 > > Lifetime min/max 0/11 > > 195 60 0 no online positive Hardware ECC Recovered > > 73875073 > > 197 100 0 no online positive Current pending sector 0 > > 198 100 0 no offline positive Offline uncorrectable 0 > > 199 200 0 no online positive Ultra DMA CRC error count 0 > > 200 100 0 no offline positive Write error rate 0 > > 202 100 0 no online positive Data address mark errors 0 > > > > The number of read errors skyrocketed! > > > > The number of reallocated sector remains the same and this is the > > only... reassuring thing. > > Hello, > > Just a question. Is it a Seagate disk ? On all servers I used this kind > of disks, Hardware ECC Recovered was always high (and in constant > increase). I have seen this issue on Linux and *BSD. And of course, I > considere Seagate as the worst disks that I can buy today. > FWIW, I had the same experience with file servers. Seagate comes last when I have to order the list of manufacturers from which to buy. Western Digital, it depends on the series---but if a disk is bad, it is bad from the very beginning (unusable on arrival). I had good experience with Hitachi perhaps because IIRC they inherited IBM technology, but also more limited experience with their disks (more difficult to get here depending on the retailers or the size of the disk). This above represents just my experience with a limited number of disks (I'm not Google...). -- Thierry Laronde http://www.kergis.com/ http://www.kergis.com/kertex.html http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: >Hardware ECC Recovered was always high (and in constant increase). That's a feature of modern high capacity drives. The only difference is if and how such things are reported. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
riccardo.mott...@libero.it (Riccardo Mottola) writes: >> Also use atactl to check the smart status of the disk. >How reliable is that data? It's what the manufacturer tells you. > 1 58 34 yes online positiveRaw read error rate 27218486 >195 580 no online positiveHardware ECC Recovered 27218486 > 1 59 34 yes online positiveRaw read error rate 232650323 >195 590 no online positiveHardware ECC Recovered 232650323 > 1 60 34 yes online positiveRaw read error rate 73875073 >195 600 no online positiveHardware ECC Recovered 73875073 >The number of read errors skyrocketed! There is no number of read errors given. The raw values only have a vendor specific meaning, can be anything. Some vendors document the raw values. You have a value of 58, then 59, then 60 and a threshold of 34. When the value reaches the treshold (from above!) or sinks below, the drive will flag an error. smartmontools can show some more details, e.g.: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 113 099 006Pre-fail Always - 58007672 195 Hardware_ECC_Recovered 0x001a 027 027 000Old_age Always - 58007672 This also shows some undecipherable raw value, but also a "worst case" datum for the drive. So, the raw read error rate isn't a count, but some kind of average for how frequent read errors occurred. And apparently the numbers of read errors and ECC recovery events seem to be correlated. Modern drives produce a huge amount of correctable ECC errors and some report such confusing SMART data. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
> FWIW, I had the same experience with file servers. Seagate comes last > when I have to order the list of manufacturers from which to buy. > Western Digital, it depends on the series---but if a disk is bad, > it is bad from the very beginning (unusable on arrival). I had good > experience with Hitachi perhaps because IIRC they inherited IBM > technology, but also more limited experience with their disks > (more difficult to get here depending on the retailers or the size > of the disk). > > This above represents just my experience with a limited number of disks > (I'm not Google...). In my case, I only work with : - IBM, now HGST - Fujitsu, now Toshiba. I refuse Seagate, Samsung and other WD in my servers or workstations, and I refuse SMR technology also. Regards, JKB
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
Riccardo Mottola a écrit : > Then this is the data for the third day (each time I did a power-off > reboot, so it is not continuous operation, I shut down the laptop at night) > > SMART supported, SMART enabled > id value thresh crit collect reliability description raw > 1 60 34 yes online positive Raw read error rate > 73875073 > 3 96 0 yes online positive Spin-up time 0 > 4 95 20 no online positive Start/stop count 6088 > 5 100 36 yes online positive Reallocated sector count 13 > 7 81 30 yes online positive Seek error rate > 127050561 > 9 95 0 no online positive Power-on hours count 4771 > 10 100 34 yes online positive Spin retry count 0 > 12 98 20 no online positive Device power cycle count 2793 > 192 99 0 no online positive Power-off retract count 2794 > 193 17 0 no online positive Load cycle count 166675 > 194 28 0 no online positive Temperature 28 > Lifetime min/max 0/11 > 195 60 0 no online positive Hardware ECC Recovered > 73875073 > 197 100 0 no online positive Current pending sector 0 > 198 100 0 no offline positive Offline uncorrectable 0 > 199 200 0 no online positive Ultra DMA CRC error count 0 > 200 100 0 no offline positive Write error rate 0 > 202 100 0 no online positive Data address mark errors 0 > > The number of read errors skyrocketed! > > The number of reallocated sector remains the same and this is the > only... reassuring thing. Hello, Just a question. Is it a Seagate disk ? On all servers I used this kind of disks, Hardware ECC Recovered was always high (and in constant increase). I have seen this issue on Linux and *BSD. And of course, I considere Seagate as the worst disks that I can buy today. Best regards, JKB
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
Hi Martin, On 2020-10-30 14:51:28 + Martin Husemann wrote: On Fri, Oct 30, 2020 at 03:41:55PM +0100, Riccardo Mottola wrote: A lot of errors and the system is not bootable anymore! I get: NetBSD MBR boot Non-System disk or disk error This is very early MBR boot sector failure, it should not be related to the fsck issue - but maybe your disk starts to act up? could be... the boot part should not be affected by a kernel/filesystem error, right? (except something very bad like out-of-partition access or such). The disk should be pretty new, but read below. I would start checking fdisk output for the disk - is it still as expected? Does it show a NetBSD partition with expected size? Disk: /dev/wd0 NetBSD disklabel disk geometry: cylinders: 155061, heads: 16, sectors/track: 63 (1008 sectors/cylinder) total sectors: 156301488, bytes/sector: 512 BIOS disk geometry: cylinders: 1022, heads: 240, sectors/track: 63 (15120 sectors/cylinder) total sectors: 156301488 Partitions aligned to 15120 sector boundaries, offset 63 Partition table: 0: NetBSD (sysid 169) start 64, size 156301424 (76319 MB, Cyls 0/1/2-10337/95/63), Active 1: 2: 3: Bootselector disabled. First active partition: 0 Drive serial number: 0 (0x) disklabel: 4 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 15117372864 4.2BSD 0 0 0 # (Cyl. 0*- 149973) b: 5127696 151173792 swap # (Cyl. 149974 - 155060) c: 15630142464 unused 0 0# (Cyl. 0*- 155060) d: 156301488 0 unused 0 0# (Cyl. 0 - 155060) offset ad size of c matches with the partition table. Is that fine enough? Then compare the disklabel output, does it match? If that is ok, install bootloader again. I Installed anyway and got the machine booting again.. then did all the chekcs. All important data is backed up, the only inconvenience is the typical setup-reinstall, etc. Also use atactl to check the smart status of the disk. How reliable is that data? I checked SMART status, it looks a little worrying: SMART supported, SMART enabled id value thresh crit collect reliability description raw 1 58 34 yes online positiveRaw read error rate 27218486 3 960 yes online positiveSpin-up time0 4 95 20 no online positiveStart/stop count 6082 5 100 36 yes online positiveReallocated sector count13 7 81 30 yes online positiveSeek error rate 125626383 9 950 no online positivePower-on hours count 4752 10 100 34 yes online positiveSpin retry count0 12 98 20 no online positiveDevice power cycle count 2790 192 990 no online positivePower-off retract count 2791 193 180 no online positiveLoad cycle count 165436 194 370 no online positiveTemperature 37 Lifetime min/max 0/11 195 580 no online positiveHardware ECC Recovered 27218486 197 1000 no online positiveCurrent pending sector 0 198 1000 no offline positiveOffline uncorrectable 0 199 2000 no online positiveUltra DMA CRC error count 0 200 1000 no offline positiveWrite error rate0 202 1000 no online positiveData address mark errors0 13 reallocated sectors, if one of them is on the MBR, who knows? But also the number of cycles and power-on is high, but reasonable. The read & Seek look incredibily high. So I thought of writing this to a file, checking the next day and then today again, just do see what increases. The day after: SMART supported, SMART enabled id value thresh crit collect reliability description raw 1 59 34 yes online positiveRaw read error rate 232650323 3 960 yes online positiveSpin-up time0 4 95 20 no online positiveStart/stop count 6088 5 100 36 yes online positiveReallocated sector count13 7 81 30 yes online positiveSeek error rate 126691967 9 950 no online positivePower-on hours count 4762 10 100 34 yes online positiveSpin retry count0 12 98 20 no online positiveDevice power cycle count 2793 192 990 no online positivePower-off retract count 2794 193 170 no online positiveLoad cycle count 166041 194 290 no online positiveTemperature 29 Lifetime min/max 0/11 195 590 no online positiveHardware ECC Recovered 232650323 197 1000 no online positiveCurrent pending sector 0 198 1000 no offline pos
Re: NetBSD 9.1 upgrade and file system crash - reboot fails
On Fri, Oct 30, 2020 at 03:41:55PM +0100, Riccardo Mottola wrote: > A lot of errors and the system is not bootable anymore! I get: > NetBSD MBR boot > Non-System disk or disk error This is very early MBR boot sector failure, it should not be related to the fsck issue - but maybe your disk starts to act up? I would start checking fdisk output for the disk - is it still as expected? Does it show a NetBSD partition with expected size? Then compare the disklabel output, does it match? If that is ok, install bootloader again. Also use atactl to check the smart status of the disk. Martin
NetBSD 9.1 upgrade and file system crash - reboot fails
Hi! I just updated to NetBSD 9.1! Yay, it was smooth, CD in, upgrade, then pkgin... and be happy. Genuine amd64 laptop. Use it 10 minutes, launch an intensive disk task (git pull) and Bam! I get kernel panic because of ufs (free list.. soemthing about something already free). I am unable to take a screeshot and the laptop reboots Once it reboots, the filesystem checks fail: Starting root file systems check: 15526 DUP I=155 /dev/rwd0a: UNEXPECTED INCONSITENCY; RUN fsck_ffs MANUALLY. ouch so I had a panick and the filesystem is so bad? I did run then "fsck_ffs -y /dev/rwd0a" A lot of errors and the system is not bootable anymore! I get: NetBSD MBR boot Non-System disk or disk error so bad?? If I boot from the CD I can mount the target filesystem disk and see most of my files. What now? Upgrade in place second time? reinstall boot loader? I did run on this machine 9.99 kernel on 9.0 userland for some time (testing some patches that made it indeed into release or it wouldn't have booted) and it was quite stable even under high load, building, etc. Riccardo
Re: NetBSD-9.1
>It does hurt; it's an incorrect warning about something that isn't a bad >thing to do, and it causes people to think they shoudl do something else >an search for what to do. That's exactly what I ment. Personally, I know that's no issue and everything works but, a new user might just go somewhere else when confronted by these. >Actually I think our amd64 packages are built on 9_STABLE and labeled >9.0 so the kernel has a threading fix necessary for >rust to run properly; see lang/rust for pointers if interesteed. Don't know what others do but, the packages I merge are for sure built on 9.0_STABLE. Or, rather were, now they are built on 9.1_STABLE. >Someone will need to make a patch for pkg_add and friends. Hmm... don't know if I dare but, if I find sometime I might look at it. Thanks for the hints. Den mån 26 okt. 2020 kl 18:59 skrev Greg Troxel : > > Pedro Pinho writes: > > > Yes, I know but, they shouldn't be there. > > Someone will need to make a patch for pkg_add and friends. > > Basically there is more or less consensus that on NetBSD this should > only match on major version. Other OSes may have different rules. > > I don't think there is any objection or other barrier other than > ENOPATCH. >
Re: NetBSD-9.1
Ottavio Caruso writes: > > > On Mon, 26 Oct 2020 at 14:55, Pedro Pinho wrote: >> >> Yes, I know but, they shouldn't be there. > > Why not? > > It's extra information that doesn't hurt. It does hurt; it's an incorrect warning about something that isn't a bad thing to do, and it causes people to think they shoudl do something else an search for what to do. 9.0 and 9.1 (and 9_STABLE) have the same ABI and packages built on one work on the other. Actually I think our amd64 packages are built on 9_STABLE and labeled 9.0 so the kernel has a threading fix necessary for rust to run properly; see lang/rust for pointers if interesteed. signature.asc Description: PGP signature
Re: NetBSD-9.1
On Mon, 26 Oct 2020 at 14:55, Pedro Pinho wrote: > > Yes, I know but, they shouldn't be there. Why not? It's extra information that doesn't hurt. -- Ottavio Caruso A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: NetBSD-9.1
Pedro Pinho writes: > Yes, I know but, they shouldn't be there. Someone will need to make a patch for pkg_add and friends. Basically there is more or less consensus that on NetBSD this should only match on major version. Other OSes may have different rules. I don't think there is any objection or other barrier other than ENOPATCH. signature.asc Description: PGP signature
Re: NetBSD-9.1
Yes, I know but, they shouldn't be there. Den mån 26 okt. 2020 15:46Ottavio Caruso skrev: > On 26/10/2020 14:34, Pedro Pinho wrote: > > Hi all, > > > > First of all, thanks for 9.1, its great and it runs like a charm. > > > > Now,... > > > > Quoting the release notes > > > > "As usual, this release is fully compatible with packages and other > binaries for > > NetBSD 9.0." > > > > While, this is true and the packages run just fine, > > '/var/db/pkgin/pkg_install-err.log' gets floaded with Warnings, > > > > == > > ... > > ---Oct 26 12:51:27: installing sowm-1.6... > > pkg_add: Warning: package `sowm-1.6' was built for a platform: > > pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) > > pkg_add: Warning: package `st-term-0.8.4nb1' was built for a platform: > > pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) > > ---Oct 26 12:51:27: installing st-term-0.8.4nb1... > > pkg_add: Warning: package `st-term-0.8.4nb1' was built for a platform: > > pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) > > pkg_add: Warning: package `ncurses-6.2nb2' was built for a platform: > > pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) > > ... > > == > > > > It doesn't look very pleasing... > > Can something be done to avoid such warnings in future releases? > > You can ignore those warnings. > > -- > Ottavio Caruso >
Re: NetBSD-9.1
On 26/10/2020 14:34, Pedro Pinho wrote: Hi all, First of all, thanks for 9.1, its great and it runs like a charm. Now,... Quoting the release notes "As usual, this release is fully compatible with packages and other binaries for NetBSD 9.0." While, this is true and the packages run just fine, '/var/db/pkgin/pkg_install-err.log' gets floaded with Warnings, == ... ---Oct 26 12:51:27: installing sowm-1.6... pkg_add: Warning: package `sowm-1.6' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) pkg_add: Warning: package `st-term-0.8.4nb1' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) ---Oct 26 12:51:27: installing st-term-0.8.4nb1... pkg_add: Warning: package `st-term-0.8.4nb1' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) pkg_add: Warning: package `ncurses-6.2nb2' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) ... == It doesn't look very pleasing... Can something be done to avoid such warnings in future releases? You can ignore those warnings. -- Ottavio Caruso
NetBSD-9.1
Hi all, First of all, thanks for 9.1, its great and it runs like a charm. Now,... Quoting the release notes "As usual, this release is fully compatible with packages and other binaries for NetBSD 9.0." While, this is true and the packages run just fine, '/var/db/pkgin/pkg_install-err.log' gets floaded with Warnings, == ... ---Oct 26 12:51:27: installing sowm-1.6... pkg_add: Warning: package `sowm-1.6' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) pkg_add: Warning: package `st-term-0.8.4nb1' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) ---Oct 26 12:51:27: installing st-term-0.8.4nb1... pkg_add: Warning: package `st-term-0.8.4nb1' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) pkg_add: Warning: package `ncurses-6.2nb2' was built for a platform: pkg_add: NetBSD/x86_64 9.0 (pkg) vs. NetBSD/x86_64 9.1_STABLE (this host) ... == It doesn't look very pleasing... Can something be done to avoid such warnings in future releases? Best Regards
Re: ctwm craches in NetBSD 9.1 if move cursor from up to down to apps pictogram on intel driver
On Sat, Oct 24, 2020 at 08:22:54AM +0100, Sad Clouds wrote: > Also, a very long time ago I tried ctwm on NetBSD sparc64 and it was > dying due to misaligned memory access, or similar. Not sure if this has > been fixed over the years, I haven't yet tried NetBSD-9.1 Hmm, good point - I need to test that locally. Martin
ctwm craches in NetBSD 9.1 if move cursor from up to down to apps pictogram on intel driver
(some problem with e-mail) I will use wsfb driver, thanks! > what gen of intel hardware is this? This is Intel Pentium N3700 (Braswell ex-Atom) Intel HD Graphics Gen. 8. --- best regards, Dmitrii Postolov dposto...@yandex.ru
Re: ctwm craches in NetBSD 9.1 if move cursor from up to down to apps pictogram on intel driver
On Sat, Oct 24, 2020 at 08:22:54AM +0100, Sad Clouds wrote: > On Sat, 24 Oct 2020 06:01:36 +0500 > Dmitrii Postolov wrote: > > > In NetBSD 9.1 and ctwm: if move mouse cursor to Applications and move > > it from left to right to pictogram then all OK, but if move cursor > > from up to down to Applications pictogram, then ctwm craches. > > Also, a very long time ago I tried ctwm on NetBSD sparc64 and it was > dying due to misaligned memory access, or similar. Not sure if this has > been fixed over the years, I haven't yet tried NetBSD-9.1 This is almost certainly a bug in xf86-video-intel rather than ctwm. Since xf86-video-intel is terrible magic and mostly unmaintained upstream I don't know if there's much we can do until the drm3 update in NetBSD 10 Ideas: use the wsfb driver if it satisfies you, use a compositor like xcompmgr to perform double buffering and elminate the rendering issues you saw when tweaking the options to avoid crashes... what gen of intel hardware is this?
Re: ctwm craches in NetBSD 9.1 if move cursor from up to down to apps pictogram on intel driver
On Sat, 24 Oct 2020 06:01:36 +0500 Dmitrii Postolov wrote: > In NetBSD 9.1 and ctwm: if move mouse cursor to Applications and move > it from left to right to pictogram then all OK, but if move cursor > from up to down to Applications pictogram, then ctwm craches. Also, a very long time ago I tried ctwm on NetBSD sparc64 and it was dying due to misaligned memory access, or similar. Not sure if this has been fixed over the years, I haven't yet tried NetBSD-9.1
A big thanks for NetBSD 9.1 release
Thanks to all the developers for the release of NetBSD 9.1. It works great for me and the default ctwm desktop is really nice. Good Work! Clay
ctwm craches in NetBSD 9.1 if move cursor from up to down to apps pictogram on intel driver
Hi! Sorry for my bad English... I probably found a strange bug in ctwm and NetBSD 9.1. Hardware: Intel NUC5PPYH SoC Intel N3700 Braswell, 4GB RAM (ex-Atom). I am using the following settings for xorg.conf: Option "Accel" "false" Option "AccelMethod" "uxa" ... Driver "intel" If not use Option "Accel" "false" then X don't start, but if use "Accel" "false" and not use "AccelMethod" "uxa" then artifacts on screen (parts of horizontal lines). In NetBSD 9.1 and ctwm: if move mouse cursor to Applications and move it from left to right to pictogram then all OK, but if move cursor from up to down to Applications pictogram, then ctwm craches. Video of ctwm crash: https://yadi.sk/i/JV5F6jab_DdICA This problem is observed only with "intel" video driver. If use "wsfb" video driver then all OK. --- Part of NetBSD 9.1 boot log: kern info: [drm] Memory usable by graphics device = 2048M kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013) kern info: [drm] Driver supports precise vblank timestamp query kern info: [drm] failed to find VBIOS tables i915drmkms0: interrupting at ioapic0 pin 16 (i915drmkms0) intelfb0 at i915drmkms0 intelfb0: framebuffer at 0xd5806315d000, size 1920x1080, depth 32, stride 7680 wsdisplay0 at intelfb0 kbmux 1: console (default, vt100 emulation), using wskbd0 Errors on screen if ctwm craches: (EE) (EE) Backtrace: (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x3f) [0x5bb4953] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x72) [0x5bb0b59] (EE) 2: /usr/lib/libc.so.12 (_sigtramp_siginfo_2+0x0) [0x7c947ea1d50] (EE) (EE) Segmentation fault at adress 0x374120 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault) Server aborting (EE) (EE) X connection to :0 broken (explicit kill or server shutdown) xinit: connection to X server lost --- best regards, Dmitrii Postolov dposto...@yandex.ru
