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 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
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
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) Loader magic: 0x6488ea60 [23.918] (II) Module ABI versions: [23.918]X.Org ANSI C Emulation: 0.4 [23.918]X.Org Video Driver: 24.0 [23.918]X.Org XInput driver :
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 [
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 --
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/
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
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
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
