Re: i915 observations
On Tue, Jan 17, 2023 at 11:14:39PM +, RVP wrote: > So, SNA is needed on both Linux and NetBSD. Yes, just that it works on Linux and not on NetBSD! I do not know if it's a kernel driver level problem or xorg driver level problem. I am suspecting it's the former. There is a PR. Let's see. -- Mayuresh
Re: i915 observations
On Thu, 29 Dec 2022, Mayuresh wrote:
On Mon, Dec 19, 2022 at 09:32:14PM +0530, Mayuresh wrote:
I have captured all the information on Linux and NetBSD, dmseg and
Xorg.log on this PR.
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57143
[ 1056.874094] i915drmkms0: notice: Resetting rcs0 for preemption time out
[ 1056.874094] i915drmkms0: notice: firefox[1585] context reset due to GPU hang
[ 1056.874094] {drm:netbsd:__i915_request_reset+0x47b} context firefox[1585]:
guilty 1, banned
[ 1056.874094] {drm:netbsd:__i915_request_reset+0x564} client firefox[1585]:
gained 4 ban score, now 4
[ 1061.824127] i915drmkms0: notice: Resetting rcs0 for preemption time out
[ 1061.824127] i915drmkms0: notice: firefox[1585] context reset due to GPU hang
[ 1061.824127] {drm:netbsd:__i915_request_reset+0x47b} context firefox[1585]:
guilty 1, banned
[ 1061.824127] {drm:netbsd:__i915_request_reset+0x564} client firefox[1585]:
gained 4 ban score, now 8
[ 1062.934133] i915drmkms0: notice: Resetting rcs0 for preemption time out
[ 1062.934133] i915drmkms0: notice: firefox[1585] context reset due to GPU hang
[ 1062.934133] {drm:netbsd:__i915_request_reset+0x47b} context firefox[1585]:
guilty 1, banned
[ 1062.934133] {drm:netbsd:__i915_request_reset+0x564} client firefox[1585]:
gained 4 ban score, now 12
This looks like a DRM issue :(
- If I try UXA acceleration on Linux, it shows all the problems mentioned
above on Linux as well.
So, SNA is needed on both Linux and NetBSD.
On Sat, 7 Jan 2023 you wrote:
I find that firefox 105 or 107 are almost unusable on a laptop running
NetBSD 10.0 BETA.
Following is a top snapshot:
1615 guest 850 3223M 414M poll/0 0:47 58.46% 54.35%
firefox
[...]
On the other hand, wonder why firefox has to start so many processes and
occupy so much of RAM in the first place. This is just a pristine
installation without any extensions or plugins and top snapshot when
nothing is opened in the browser as yet - just a single and blank tab.
Probably the Pocket extension. Or the stuff downloaded as part of
Settings > Privacy & Security > Firefox Data Collection and Use +
Security.
You can turn Pocket off in Settings or about:config.
-RVP
Re: i915 observations
Just reviving this thread in the new year. Story so far for my laptop is: - On Linux both eDP and HDMI work fine, even with rotation. Linux uses intel driver with SNA acceleration. - On NetBSD 10.0 BETA, only intel driver works, only with UXA acceleration. No other driver or no other acceleration for intel driver works. In this mode rotation slows down refreshes on eDP alone as well as on HDMI (alone or together with eDP) - If I try UXA acceleration on Linux, it shows all the problems mentioned above on Linux as well. I have experimented with various options with UXA and SNA; using both native and modular X11 servers. None have helped so far. So, on the verge of giving up... That means once again no NetBSD on my laptop for indefinite time. Any suggestions are most welcome. -- Mayuresh
Re: i915 observations
On Mon, Dec 19, 2022 at 09:32:14PM +0530, Mayuresh wrote: I have captured all the information on Linux and NetBSD, dmseg and Xorg.log on this PR. http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57143 -- Mayuresh
Re: i915 observations
On Mon, 19 Dec 2022, Mayuresh wrote: I tried using Linux's xorg.conf on NetBSD as well as the other way round. - Both work on the system they are taken from, but both don't work on the other system. - Both use the driver intel, but still when they use the other's file they both give the same error Driver not found : intel. Not surprising that you can't use the xorg.conf from NetBSD on Linux, or vice-versa. If you look at the full x.org.conf that's being used you'll see many OS-specific things in there. Eg. references to the "wheel" group in the NetBSD config, and to "/dev/input/*" devices in the Linux one. Other critical things like ModulePath are different too. Really, just use the xorg.conf fragments and let the X server use its defaults for the rest. On Linux: If I do NOT have xorg.conf startx works. But if I generate one using X -configure then it doesn't (no matter I set UXA or not). Backtrace: 0: /usr/libexec/Xorg (xorg_backtrace+0x7d) [0x55bec268d9cd] 1: /usr/libexec/Xorg (0x55bec2549000+0x14f9b5) [0x55bec26989b5] 2: /usr/lib/libpthread.so.0 (0x7f976534f000+0x13900) [0x7f9765362900] 3: /usr/libexec/Xorg (xf86OptionValue+0x7) [0x55bec26a4cf7] 4: /usr/lib64/xorg/modules/extensions/libvnc.so (0x7f9764862000+0x362c0) [0x7f97648982c0] 5: /usr/libexec/Xorg (InitExtensions+0x89) [0x55bec2590329] 6: /usr/libexec/Xorg (0x55bec2549000+0x3aa3e) [0x55bec2583a3e] 7: /usr/lib/libc.so.6 (__libc_start_main+0xea) [0x7f9764e61e0a] 8: /usr/libexec/Xorg (_start+0x2a) [0x55bec2584e0a] Segmentation fault at address 0x10011 Caught signal 11 (Segmentation fault). Server aborting I think what's happening here is that the full xorg.conf file generated using `-configure' tried to load the "vnc" module which is what's segfaulting. The correct one (when it works on Linux) is attached now. The internally autogenerated one (in the absence of a xorg.conf file), does not load the "vnc" module. In both instance, the "intel" driver is loaded with "SNA" as the AccelMethod. Also on Linux, since the DRI module failed to load the software GL rasterizer is used as a fallback: ``` [ 428.237] (EE) AIGLX error: dlopen of /usr/lib64/dri/i965_dri.so failed (/usr/lib64/dri/i965_dri.so: cannot open shared object file: No such file or directory) [ 428.237] (EE) AIGLX error: unable to load driver i965 [ 428.295] (II) IGLX: Loaded and initialized swrast [ 428.295] (II) GLX: Initialized DRISWRAST GL provider for screen 0 ``` On NetBSD, prsumably the `i965_dri.so' DRI module loads (but, I haven't seen the Xorg.0.log from NetBSD yet.) You can make NetBSD behave like Linux here by disabling DRI as I suggested before: ``` Option "DRI" "off" ``` With above settings, after connecting hdmi monitor and running xrandr rotate the system instantly rebooted! Well, OK, after a bit of experimentation I've _finally_ got both "modesetting" and "intel" working on my card which is a: ``` i915drmkms0 at pci0 dev 2 function 0: Intel Ivy Bridge Integrated Graphics Device (rev. 0x09) ``` As I reported before, both previously either hung the X server process, or produced horribly slow screen updates coupled with streaky screen effects. I can make all my problems vanish (a Christmas Miracle?) by _not doing_ either of these things: 1. Adding `gop 0' to /boot.cfg. ie. use the default BIOS video mode (1024x768) That was something I've always had in the config. Now removed since you don't need it with the DRMKMS driver. 2. Adding a non-default FONT to the kernel config. For example, I'd had this for a long time: ``` #optionsFONT_BOLD8x16 #optionsFONT_BOLD16x32 options FONT_SPLEEN12x24 ``` This too, bizarrely, caused my issue. (I noticed this last year[1].) [1]: https://mail-index.netbsd.org/current-users/2022/01/04/msg041887.html So, a) remove `gop 0' from /boot.cfg, and b) leave the standard fonts alone! BTW, the working xorg.conf fragments are the standard ones, ie: ``` Section "Device" Identifier "Card0" Driver "modesetting" # or, "intel" EndSection ``` Of course, YMMV. See you folks next year! -RVP
Re: i915 observations
On Mon, Dec 19, 2022 at 09:26:33PM +0530, Mayuresh wrote: > On Mon, Dec 19, 2022 at 09:20:53PM +0530, Mayuresh wrote: > > I do not know if there is a way to make a running X dump its conf. I > > searched for it, though could not find. > > On Linux, when X11 works (i.e. when xorg.conf is absent) I am attaching > its log - just in case if there is any way to figure out which driver and > options it might be using. Apologies.. Attached a wrong log to the previous mail. The correct one (when it works on Linux) is attached now. -- Mayuresh [ 1597.889] X.Org X Server 1.21.1.4 X Protocol Version 11, Revision 0 [ 1597.889] Current Operating System: Linux asus2 6.0.10_1 #1 SMP PREEMPT_DYNAMIC Mon Nov 28 03:42:58 UTC 2022 x86_64 [ 1597.889] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.10_1 root=UUID=4147e9fb-400b-449c-a1b0-a64b6b720900 ro loglevel=4 [ 1597.889] [ 1597.889] Current version of pixman: 0.40.0 [ 1597.889]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1597.889] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1597.890] (==) Log file: "/var/log/Xorg.1.log", Time: Mon Dec 19 21:28:53 2022 [ 1597.890] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1597.890] (==) No Layout section. Using the first Screen section. [ 1597.890] (==) No screen section available. Using defaults. [ 1597.890] (**) |-->Screen "Default Screen Section" (0) [ 1597.890] (**) | |-->Monitor "" [ 1597.890] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1597.891] (==) Automatically adding devices [ 1597.891] (==) Automatically enabling devices [ 1597.891] (==) Automatically adding GPU devices [ 1597.891] (==) Automatically binding GPU devices [ 1597.891] (==) Max clients allowed: 256, resource mask: 0x1f [ 1597.891] (WW) The directory "/usr/share/fonts/X11/OTF" does not exist. [ 1597.891]Entry deleted from font path. [ 1597.891] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/TTF, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi [ 1597.891] (==) ModulePath set to "/usr/lib64/xorg/modules" [ 1597.891] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1597.891] (II) Module ABI versions: [ 1597.891]X.Org ANSI C Emulation: 0.4 [ 1597.891]X.Org Video Driver: 25.2 [ 1597.891]X.Org XInput driver : 24.4 [ 1597.891]X.Org Server Extension : 10.0 [ 1597.891] (II) xfree86: Adding drm device (/dev/dri/card0) [ 1597.891] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/card0 [ 1597.910] (--) PCI:*(0@0:2:0) 8086:3184:1043:1232 rev 6, Mem @ 0xa000/16777216, 0x9000/268435456, I/O @ 0xf000/64, BIOS @ 0x/131072 [ 1597.910] (II) Open ACPI successful (/var/run/acpid.socket) [ 1597.910] (II) LoadModule: "glx" [ 1597.910] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 1597.912] (II) Module glx: vendor="X.Org Foundation" [ 1597.912]compiled for 1.21.1.4, module version = 1.0.0 [ 1597.912]ABI class: X.Org Server Extension, version 10.0 [ 1597.912] (==) Matched intel as autoconfigured driver 0 [ 1597.912] (==) Matched modesetting as autoconfigured driver 1 [ 1597.912] (==) Matched fbdev as autoconfigured driver 2 [ 1597.912] (==) Matched vesa as autoconfigured driver 3 [ 1597.912] (==) Assigned the driver to the xf86ConfigLayout [ 1597.912] (II) LoadModule: "intel" [ 1597.912] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 1597.913] (II) Module intel: vendor="X.Org Foundation" [ 1597.913]compiled for 1.21.1.3, module version = 2.99.917 [ 1597.913]Module class: X.Org Video Driver [ 1597.913]ABI class: X.Org Video Driver, version 25.2 [ 1597.913] (II) LoadModule: "modesetting" [ 1597.913] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 1597.913] (II) Module modesetting: vendor="X.Org Foundation" [ 1597.913]compiled for 1.21.1.4, module version = 1.21.1 [ 1597.913]Module class: X.Org Video Driver [ 1597.913]ABI class: X.Org Video Driver, version 25.2 [ 1597.913] (II) LoadModule: "fbdev" [ 1597.913] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 1597.914] (II) Module fbdev: vendor="X.Org Foundation" [ 1597.914]compiled for 1.21.1.3, module version = 0.5.0 [ 1597.914]Module class: X.Org Video Driver [ 1597.914]ABI class: X.Org Video Driver, version 25.2 [ 1597.914] (II) LoadModule: "vesa" [ 1597.914] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 1597.914] (II) Module vesa: vendor="X.Org Foundation" [ 1597.914]
Re: i915 observations
On Mon, Dec 19, 2022 at 09:20:53PM +0530, Mayuresh wrote: > I do not know if there is a way to make a running X dump its conf. I > searched for it, though could not find. On Linux, when X11 works (i.e. when xorg.conf is absent) I am attaching its log - just in case if there is any way to figure out which driver and options it might be using. -- Mayuresh [ 142.152] X.Org X Server 1.21.1.4 X Protocol Version 11, Revision 0 [ 142.158] Current Operating System: Linux asus2 6.0.10_1 #1 SMP PREEMPT_DYNAMIC Mon Nov 28 03:42:58 UTC 2022 x86_64 [ 142.158] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.10_1 root=UUID=4147e9fb-400b-449c-a1b0-a64b6b720900 ro loglevel=4 [ 142.163] [ 142.165] Current version of pixman: 0.40.0 [ 142.170]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 142.170] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 142.180] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 20 02:34:34 2022 [ 142.180] (II) Module ABI versions: [ 142.180]X.Org ANSI C Emulation: 0.4 [ 142.180]X.Org Video Driver: 25.2 [ 142.180]X.Org XInput driver : 24.4 [ 142.180]X.Org Server Extension : 10.0 [ 142.181] (II) xfree86: Adding drm device (/dev/dri/card0) [ 142.181] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/card0 [ 142.198] (--) PCI:*(0@0:2:0) 8086:3184:1043:1232 rev 6, Mem @ 0xa000/16777216, 0x9000/268435456, I/O @ 0xf000/64, BIOS @ 0x/131072 [ 142.200] List of video drivers: [ 142.201]amdgpu [ 142.201]ati [ 142.202]dummy [ 142.203]intel [ 142.204]nouveau [ 142.205]radeon [ 142.206]vmware [ 142.208]modesetting [ 142.210]fbdev [ 142.211]vesa [ 142.211] (II) LoadModule: "amdgpu" [ 142.231] (II) Loading /usr/lib64/xorg/modules/drivers/amdgpu_drv.so [ 142.314] (II) Module amdgpu: vendor="X.Org Foundation" [ 142.314]compiled for 1.21.1.3, module version = 22.0.0 [ 142.314]Module class: X.Org Video Driver [ 142.314]ABI class: X.Org Video Driver, version 25.2 [ 142.314] (II) LoadModule: "ati" [ 142.315] (II) Loading /usr/lib64/xorg/modules/drivers/ati_drv.so [ 142.331] (II) Module ati: vendor="X.Org Foundation" [ 142.331]compiled for 1.21.1.3, module version = 19.1.0 [ 142.331]Module class: X.Org Video Driver [ 142.331]ABI class: X.Org Video Driver, version 25.2 [ 142.331] (II) LoadModule: "dummy" [ 142.332] (II) Loading /usr/lib64/xorg/modules/drivers/dummy_drv.so [ 142.345] (II) Module dummy: vendor="X.Org Foundation" [ 142.345]compiled for 1.21.1.3, module version = 0.3.8 [ 142.345]Module class: X.Org Video Driver [ 142.345]ABI class: X.Org Video Driver, version 25.2 [ 142.345] (II) LoadModule: "intel" [ 142.345] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 142.393] (II) Module intel: vendor="X.Org Foundation" [ 142.393]compiled for 1.21.1.3, module version = 2.99.917 [ 142.393]Module class: X.Org Video Driver [ 142.393]ABI class: X.Org Video Driver, version 25.2 [ 142.393] (II) LoadModule: "nouveau" [ 142.393] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so [ 142.395] (II) Module nouveau: vendor="X.Org Foundation" [ 142.395]compiled for 1.21.1.3, module version = 1.0.17 [ 142.395]Module class: X.Org Video Driver [ 142.395]ABI class: X.Org Video Driver, version 25.2 [ 142.395] (II) LoadModule: "radeon" [ 142.395] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so [ 142.414] (II) Module radeon: vendor="X.Org Foundation" [ 142.414]compiled for 1.21.1.3, module version = 19.1.0 [ 142.414]Module class: X.Org Video Driver [ 142.414]ABI class: X.Org Video Driver, version 25.2 [ 142.414] (II) LoadModule: "vmware" [ 142.414] (II) Loading /usr/lib64/xorg/modules/drivers/vmware_drv.so [ 143.631] (II) Module vmware: vendor="X.Org Foundation" [ 143.631]compiled for 1.21.1.4, module version = 13.3.0 [ 143.631]Module class: X.Org Video Driver [ 143.631]ABI class: X.Org Video Driver, version 25.2 [ 143.631] (II) LoadModule: "modesetting" [ 143.631] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 143.649] (II) Module modesetting: vendor="X.Org Foundation" [ 143.649]compiled for 1.21.1.4, module version = 1.21.1 [ 143.649]Module class: X.Org Video Driver [ 143.649]ABI class: X.Org Video Driver, version 25.2 [ 143.649] (II) LoadModule: "fbdev" [ 143.649] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 143.650] (II) Module fbdev: vendor="X.Org Foundation" [ 143.650]compiled for 1.21.1.3, module version = 0.5.0 [ 143.650]Module class: X.Org Video Driver [ 143.650]ABI class: X.Org
Re: i915 observations
On Sun, Dec 18, 2022 at 11:35:26PM +, RVP wrote: > In any case, do your tests after forcing `UXA' on Linux too. Following things are weird: On Linux: If I do NOT have xorg.conf startx works. But if I generate one using X -configure then it doesn't (no matter I set UXA or not). I do not know if there is a way to make a running X dump its conf. I searched for it, though could not find. Attaching log, with xorg.conf present on Linux. This is grep -w EE of the log with up to EE) trimmed to keep it short AIGLX error: dlopen of /usr/lib64/dri/i965_dri.so failed (/usr/lib64/dri/i965_dri.so: cannot open shared object file: No such file or directory) AIGLX error: unable to load driver i965 Backtrace: 0: /usr/libexec/Xorg (xorg_backtrace+0x7d) [0x55bec268d9cd] 1: /usr/libexec/Xorg (0x55bec2549000+0x14f9b5) [0x55bec26989b5] 2: /usr/lib/libpthread.so.0 (0x7f976534f000+0x13900) [0x7f9765362900] 3: /usr/libexec/Xorg (xf86OptionValue+0x7) [0x55bec26a4cf7] 4: /usr/lib64/xorg/modules/extensions/libvnc.so (0x7f9764862000+0x362c0) [0x7f97648982c0] 5: /usr/libexec/Xorg (InitExtensions+0x89) [0x55bec2590329] 6: /usr/libexec/Xorg (0x55bec2549000+0x3aa3e) [0x55bec2583a3e] 7: /usr/lib/libc.so.6 (__libc_start_main+0xea) [0x7f9764e61e0a] 8: /usr/libexec/Xorg (_start+0x2a) [0x55bec2584e0a] Segmentation fault at address 0x10011 Caught signal 11 (Segmentation fault). Server aborting Please also check the log file at "/var/log/Xorg.1.log" for additional information. Server terminated with error (1). Closing log file. BTW /usr/lib64/dri/i965_dri.so is actually present. I'd rather not chase Linux specific issues. I'd use Linux to the extent of differentially diagnosing the problems with X11 on NetBSD, but looks like it's not helping much in that and adding its own mysteries that may digress us. -- Mayuresh [ 428.190] X.Org X Server 1.21.1.4 X Protocol Version 11, Revision 0 [ 428.191] Current Operating System: Linux asus2 6.0.10_1 #1 SMP PREEMPT_DYNAMIC Mon Nov 28 03:42:58 UTC 2022 x86_64 [ 428.191] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.10_1 root=UUID=4147e9fb-400b-449c-a1b0-a64b6b720900 ro loglevel=4 [ 428.193] [ 428.193] Current version of pixman: 0.40.0 [ 428.195]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 428.195] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 428.198] (==) Log file: "/var/log/Xorg.1.log", Time: Mon Dec 19 21:09:23 2022 [ 428.199] (==) Using config file: "/etc/X11/xorg.conf" [ 428.199] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 428.200] (==) ServerLayout "X.org Configured" [ 428.200] (**) |-->Screen "Screen0" (0) [ 428.200] (**) | |-->Monitor "Monitor0" [ 428.200] (**) | |-->Device "Card0" [ 428.200] (**) |-->Input Device "Mouse0" [ 428.200] (**) |-->Input Device "Keyboard0" [ 428.200] (==) Automatically adding devices [ 428.200] (==) Automatically enabling devices [ 428.200] (==) Automatically adding GPU devices [ 428.200] (==) Automatically binding GPU devices [ 428.200] (==) Max clients allowed: 256, resource mask: 0x1f [ 428.200] (WW) The directory "/usr/share/fonts/X11/OTF" does not exist. [ 428.200]Entry deleted from font path. [ 428.200] (WW) The directory "/usr/share/fonts/X11/OTF" does not exist. [ 428.200]Entry deleted from font path. [ 428.200] (**) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/TTF, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/TTF, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi [ 428.200] (**) ModulePath set to "/usr/lib64/xorg/modules" [ 428.200] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 428.200] (WW) Disabling Mouse0 [ 428.200] (WW) Disabling Keyboard0 [ 428.200] (II) Module ABI versions: [ 428.200]X.Org ANSI C Emulation: 0.4 [ 428.200]X.Org Video Driver: 25.2 [ 428.200]X.Org XInput driver : 24.4 [ 428.200]X.Org Server Extension : 10.0 [ 428.201] (II) xfree86: Adding drm device (/dev/dri/card0) [ 428.201] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/card0 [ 428.219] (--) PCI:*(0@0:2:0) 8086:3184:1043:1232 rev 6, Mem @ 0xa000/16777216, 0x9000/268435456, I/O @ 0xf000/64, BIOS @ 0x/131072 [ 428.219] (II) Open ACPI successful (/var/run/acpid.socket) [ 428.219] (II) "glx" will be loaded. This was enabled by default and also specified in the config file. [ 428.219] (II) LoadModule: "glx"
Re: i915 observations
On Mon, Dec 19, 2022 at 12:04:42AM +, RVP wrote: > b) xrandr (rotation--tested, multiple displays--can't test) works. With above settings, after connecting hdmi monitor and running xrandr rotate the system instantly rebooted! This is 9.99.108 -- Mayuresh
Re: i915 observations
On Sun, 18 Dec 2022, Ron Georgia wrote: All configurations were a bust. Then I copied all linux-firmware/intel to /libdata/firmware/intel/ That is the wrong directory, I think, so very likely those firmware blobs aren't being picked up. My Device section of my xorg.conf looks like this: Section "Device" Option "Accel" "True" You don't need this--it's the default. BusID "PCI:0:2:0" Also not needed. The Xorg server will almost always correctly figure this out. (BusID is really only useful when you have multiple graphics cards.) EndSection Everything works! Well, the response is a little sluggish and firefox takes forever to load, but the video is solid. I do have a lot of "heartbeat" messages in dmesg. I also see this with dmesg: [ 1633.783213] heartbeat On hold?: 0 [ 1633.783213] heartbeat MMIO base: 0x2000 [ 1633.783213] heartbeat CCID: 0x01b5610d [ 1633.783213] heartbeat RING_START: 0x7fffb000 [ 1633.783213] heartbeat RING_HEAD: 0x0798 [ 1633.783213] heartbeat RING_TAIL: 0x0bb0 [ 1633.783213] heartbeat RING_CTL: 0x3001 [ 1633.783213] heartbeat RING_MODE: 0x4000 [ 1633.783213] heartbeat RING_IMR: fffe [ 1633.783213] heartbeat ACTHD: 0x_01b0731c [ 1633.783213] heartbeat BBADDR: 0x_01b0731d [ 1633.783213] heartbeat DMA_FADDR: 0x_01b07500 [ 1633.783213] heartbeat IPEIR: 0x [ 1633.783213] heartbeat IPEHR: 0x7a03 [ 1633.783213] heartbeat PP_DIR_BASE: 0x0221 [ 1633.783213] heartbeat PP_DIR_BASE_READ: 0x [ 1633.783213] heartbeat PP_DIR_DCLV: 0x [ 1633.783213] heartbeat E 2:350a5*- @ 5950ms: firefox[13741] [ 1633.783213] heartbeat E 2:350a6- @ 5940ms: X[1020] [ 1633.783213] heartbeat E 2:350a7 @ 5920ms: firefox[13741] [ 1633.783213] heartbeat E 2:350a8 @ 5920ms: X[1020] [ 1633.783213] heartbeat E 2:350a9 @ 5920ms: X[1020] [ 1633.783213] heartbeat E 2:350aa @ 3000ms: [i915][ 1633.783213] heartbeat * [ 1633.783213] heartbeat Idle? no [ 1633.783213] heartbeat Signals: [ 1633.783213] heartbeat [2:350a5*] @ 5950ms [ 1633.783213] heartbeat [2:350a6] @ 5940ms [ 1633.783213] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0 [ 1633.783213] i915drmkms0: notice: firefox[13741] context reset due to GPU hang Yeah. those heartbeat messages triggered by GPU hangs are what I see with most of the standard configs. "modesetting", "intel", "intel" + "UXA" all lock-up the Xorg process. With both "modesetting" and "intel" and "AccelMethod" "none", the screen contents are extremely slow to update, and have a very streaky look when the update is going on. What this looks like can be seen in the video here: http://mail-index.NetBSD.org/current-users/2022/11/10/msg043195.html Alrighty, now for what _works_ for me (latest -HEAD): ``` $ cat /etc/X11/xorg.conf.d/display.conf Section "Device" Identifier "Card0" Driver "intel" Option "AccelMethod" "blt" Option "DRI" "off" EndSection $ ``` This is SNA + the "blt" engine, and DRI turned off. This is a step up from `wsfb' because: a) the system runs ~10C cooler. b) xrandr (rotation--tested, multiple displays--can't test) works. Hope this helps, -RVP
Re: i915 observations
On Sun, 18 Dec 2022, Mayuresh wrote: I tried using Linux's xorg.conf on NetBSD as well as the other way round. - Both work on the system they are taken from, but both don't work on the other system. - Both use the driver intel, but still when they use the other's file they both give the same error Driver not found : intel. Shouldn't happen. This `intel.conf' file works on both NetBSD and Ubuntu 19.04: ``` $ cat /etc/X11/xorg.conf.d/intel.conf Section "Device" Identifier "Card0" Driver "intel" Option "AccelMethod" "UXA" EndSection $ ``` (Of course, on NetBSD, the X server hangs soon afterwards.) In any case, do your tests after forcing `UXA' on Linux too. Attaching both. Attach the Xorg.0.log files from both too. -RVP
Re: i915 observations
I had the same issues with current and with 10_beta. The single line with wsfb as driver and the tearing with intel and modesetting. But now, for me, it works. This is what I did. I did a git clone of https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git and copied all the files from linux-firmware/i915 to /libdata/firmware/i915drmkms/i915/. I stuck my xorg.conf in /etc/X11/xorg.conf.d/. I edited the xorg.conf trying the following Option "Accel" "True" Option "AccelMethod" "SNA" -- OR -- Option "AccelMethod" "UXA" -- OR -- Option "AccelMethod" "none" With Identifier "Card0" Driver "intel" or "modesetting BusID "PCI:0:2:0" All configurations were a bust. Then I copied all linux-firmware/intel to /libdata/firmware/intel/ My Device section of my xorg.conf looks like this: Section "Device" Option "Accel" "True" Option "AccelMethod" "UXA" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection Everything works! Well, the response is a little sluggish and firefox takes forever to load, but the video is solid. I do have a lot of "heartbeat" messages in dmesg. I also see this with dmesg: [ 1633.783213] heartbeat On hold?: 0 [ 1633.783213] heartbeat MMIO base: 0x2000 [ 1633.783213] heartbeat CCID: 0x01b5610d [ 1633.783213] heartbeat RING_START: 0x7fffb000 [ 1633.783213] heartbeat RING_HEAD: 0x0798 [ 1633.783213] heartbeat RING_TAIL: 0x0bb0 [ 1633.783213] heartbeat RING_CTL: 0x3001 [ 1633.783213] heartbeat RING_MODE: 0x4000 [ 1633.783213] heartbeat RING_IMR: fffe [ 1633.783213] heartbeat ACTHD: 0x_01b0731c [ 1633.783213] heartbeat BBADDR: 0x_01b0731d [ 1633.783213] heartbeat DMA_FADDR: 0x_01b07500 [ 1633.783213] heartbeat IPEIR: 0x [ 1633.783213] heartbeat IPEHR: 0x7a03 [ 1633.783213] heartbeat PP_DIR_BASE: 0x0221 [ 1633.783213] heartbeat PP_DIR_BASE_READ: 0x [ 1633.783213] heartbeat PP_DIR_DCLV: 0x [ 1633.783213] heartbeat E 2:350a5*- @ 5950ms: firefox[13741] [ 1633.783213] heartbeat E 2:350a6- @ 5940ms: X[1020] [ 1633.783213] heartbeat E 2:350a7 @ 5920ms: firefox[13741] [ 1633.783213] heartbeat E 2:350a8 @ 5920ms: X[1020] [ 1633.783213] heartbeat E 2:350a9 @ 5920ms: X[1020] [ 1633.783213] heartbeat E 2:350aa @ 3000ms: [i915][ 1633.783213] heartbeat * [ 1633.783213] heartbeat Idle? no [ 1633.783213] heartbeat Signals: [ 1633.783213] heartbeat [2:350a5*] @ 5950ms [ 1633.783213] heartbeat [2:350a6] @ 5940ms [ 1633.783213] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0 [ 1633.783213] i915drmkms0: notice: firefox[13741] context reset due to GPU hang I have no idea what heartbeat is a reference to, but for now things are working. % uname -mpr 10.0_BETA amd64 x86_64 On 12/12/22 21:58, Mayuresh wrote: On Mon, Dec 12, 2022 at 10:37:37PM +, RVP wrote: Welcome to the club... You'll find the rest of the gang here already: https://mail-index.netbsd.org/current-users/2022/07/21/msg042710.html Please post to that thread: Merging the thread here. Uncomment the `Option "AccelMethod" "none"' in the config. fragment I sent you. Then see if modesetting(4) comes up. For the intel(4) driver, try `Option "AccelMethod" "UXA"', or even `"none"' as a last resort. The intelfb(4) manpage lists other options which you can turn off or disable with the SNA or UXA accel-methods. modesetting - none and intel - none combinations start the display with a very poor refresh rate. They appear garbled and settle down slowly. intel - UXA is kind of working now. Finally some X11 on the device! I'll test some video playing etc. and report back. Thanks for your help!
Re: i915 observations
On Sat, Dec 17, 2022 at 11:36:17PM +, RVP wrote: > On Sat, 17 Dec 2022, Mayuresh wrote: > > > On Linux it works with intel driver and without any AccelMethod explicitly > > set. > > [...] > > isn't it i915 driver that must be making a difference? > > > > Yes, which is why you should use the same config. file as on NetBSD: so > that we can have an apples-to-apples comparison--same driver; same config. I tried using Linux's xorg.conf on NetBSD as well as the other way round. - Both work on the system they are taken from, but both don't work on the other system. - Both use the driver intel, but still when they use the other's file they both give the same error Driver not found : intel. Attaching both. -- Mayuresh Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/pkg/lib/xorg/modules" FontPath "/usr/pkg/share/fonts/X11/misc" FontPath "/usr/pkg/share/fonts/X11/TTF" FontPath "/usr/pkg/share/fonts/X11/OTF" FontPath "/usr/pkg/share/fonts/X11/Type1" FontPath "/usr/pkg/share/fonts/X11/100dpi" FontPath "/usr/pkg/share/fonts/X11/75dpi" FontPath "/usr/pkg/share/fonts/X11/cyrillic" FontPath "/usr/pkg/lib/X11/fonts/misc" FontPath "/usr/pkg/lib/X11/fonts/TTF" FontPath "/usr/pkg/lib/X11/fonts/OTF" FontPath "/usr/pkg/lib/X11/fonts/Type1" FontPath "/usr/pkg/lib/X11/fonts/100dpi" FontPath "/usr/pkg/lib/X11/fonts/75dpi" FontPath "/usr/pkg/lib/X11/fonts/cyrillic" EndSection Section "Module" Load "dri" Load "dri2" Load "glx" EndSection Section "DRI" Group "wheel" Mode 0660 EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "wsmouse" Option "Device" "/dev/wsmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "Accel" # [] #Option "AccelMethod" # #Option "Backlight" # #Option "CustomEDID"# #Option "DRI" # #Option "Present" # [] #Option "ColorKey" # #Option "VideoKey" # #Option "Tiling"# [] #Option "LinearFramebuffer" # [] #Option "HWRotation"# [] #Option "VSync" # [] #Option "PageFlip" # [] #Option "SwapbuffersWait" # [] #Option "TripleBuffer" # [] #Option "XvPreferOverlay" # [] #Option "HotPlug" # [] #Option "ReprobeOutputs"# [] #Option "XvMC" # [] #Option "ZaphodHeads" # #Option "VirtualHeads" # #Option "TearFree" # [] #Option "PerCrtcPixmaps"# [] #Option "FallbackDebug" # [] #Option "DebugFlushBatches" # [] #Option "DebugFlushCaches" # [] #Option "DebugWait" # [] #Option "BufferCache" # [] Identifier "Card0" #Driver "wsfb" #Driver "modesetting" #Option "AccelMethod" "none" Option "AccelMethod""UXA" #Driver "vesa" Driver "intel" #Driver "nouveau" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0
Re: i915 observations
On Sat, 17 Dec 2022, Mayuresh wrote: On Linux it works with intel driver and without any AccelMethod explicitly set. [...] isn't it i915 driver that must be making a difference? Yes, which is why you should use the same config. file as on NetBSD: so that we can have an apples-to-apples comparison--same driver; same config. -RVP
Re: i915 observations
On Wed, Dec 14, 2022 at 11:14:31PM +, RVP wrote: > xrandr rotation on my laptop display worked fine on Linux. (On NetBSD, > I have to use wsfb--the other drivers are either unusable or hang the > system.) On Linux it works with intel driver and without any AccelMethod explicitly set. On NetBSD it works with intel driver and with UXA but only in default mode of eDP1. Mode change on eDP1 or any mode on HDMI work sluggishly. Assuming x11 world may not differ much on both OSes (I am using modular x11), isn't it i915 driver that must be making a difference? -- Mayuresh
Re: i915 observations
On Wed, 14 Dec 2022, Mayuresh wrote: The only time when above problem doesn't trigger is, if I do 'xrandr --same-as' to have hdmi a mirror of eDP. I like to use a vertical hdmi monitor, so above option isn't suitable for my usage. In fact, with hdmi completely out of the picture, if I do 'xrandr --rotate' on eDP screen, just to see what happens, the slow refresh occurs on eDP also. xrandr rotation on my laptop display worked fine on Linux. (On NetBSD, I have to use wsfb--the other drivers are either unusable or hang the system.) Does it mean the acceleration works only in certain mode(s)? That used to be the case a long time ago if I recall this correctly. Even on a single display, rotation implied no accel. But, all this should've been fixed now. Try it on Linux. Install the xf86-video-intel package if needed, then copy the xorg.conf file over from NetBSD. -RVP
Re: i915 observations
On Tue, Dec 13, 2022 at 11:06:24PM +, RVP wrote: > Is this on the eDP or HDMI? Collect a blind dmesg (or better, ssh into > the laptop) after `boot -vx'. Another one where the display stays on > for comparison. Unluckily (rather luckily) with boot -vx the display always comes up! (I don't mind settling for it as a workaround!) Without -vx it's random. But when the display doesn't come up, the network doesn't come up either. I tried typing commands to save dmesg output. But may be it wasn't taking those. May be it had crashed where it was accepting only reboot command. -- Mayuresh
Re: i915 observations
On Tue, Dec 13, 2022 at 11:06:24PM +, RVP wrote: > > (Will get back on above points.) > Hmm. Don't know about this. Might be that UXA + HDMI doesn't work so well. > > a) Try out different output drivers with mpv(1): use `--vo=help' > > b) For DVD playback, see the XvMC-related options mentioned in intel(4). The problem is not only with videos. Even catting a file or opening vi updates the screen slowly, almost line by line left to right. The only time when above problem doesn't trigger is, if I do 'xrandr --same-as' to have hdmi a mirror of eDP. I like to use a vertical hdmi monitor, so above option isn't suitable for my usage. In fact, with hdmi completely out of the picture, if I do 'xrandr --rotate' on eDP screen, just to see what happens, the slow refresh occurs on eDP also. Does it mean the acceleration works only in certain mode(s)? So far intel-UXA is the only combination that has somewhat worked. *-none starts but is not usable. intel-SNA doesn't work, modestting/wsfb with defaults don't even start. -- Mayuresh
Re: i915 observations
On Tue, 13 Dec 2022, Mayuresh wrote: Now the only problem left is this: During boot when the display switches mode, sometimes it manages to remain on, some other times it goes blank. [...] Once in a few reboots the display holds on and then I can reach all the way to X11. Is this on the eDP or HDMI? Collect a blind dmesg (or better, ssh into the laptop) after `boot -vx'. Another one where the display stays on for comparison. As a work around, you could try `Option "ReprobeOutputs" "on"' then see if the X server turns your display (which?) back on again when it starts. Update: HDMI output has a slow refresh problem though eDP works fine. Can't play videos on hdmi, even command line usage is jittery. Tried experimenting with modes, including low resolutions, but the problem persists. Hmm. Don't know about this. Might be that UXA + HDMI doesn't work so well. a) Try out different output drivers with mpv(1): use `--vo=help' b) For DVD playback, see the XvMC-related options mentioned in intel(4). -RVP
Re: i915 observations
On Tue, Dec 13, 2022 at 08:28:08AM +0530, Mayuresh wrote: > I'll test some video playing etc. and report back. Thanks to compat90 I was able to test immediately. Yeah, they seem to work alright. Even HDMI output seems fine and xrandr also seems to work. Now the only problem left is this: During boot when the display switches mode, sometimes it manages to remain on, some other times it goes blank. This is random. There are 4 gop values, all of which work sometimes and don't work some other times. I do not know exactly what happens when the display goes blank. I enter root username and password and type reboot and that seems to be rebooting it. Once in a few reboots the display holds on and then I can reach all the way to X11. -- Mayuresh
Re: i915 observations
On Tue, Dec 13, 2022 at 08:50:38AM +0530, Mayuresh wrote: > Even HDMI output seems fine Update: HDMI output has a slow refresh problem though eDP works fine. Can't play videos on hdmi, even command line usage is jittery. Tried experimenting with modes, including low resolutions, but the problem persists. -- Mayuresh
Re: i915 observations
On Mon, Dec 12, 2022 at 10:37:37PM +, RVP wrote: > Welcome to the club... You'll find the rest of the gang here already: > https://mail-index.netbsd.org/current-users/2022/07/21/msg042710.html > Please post to that thread: Merging the thread here. > Uncomment the `Option "AccelMethod" "none"' in the config. fragment I > sent you. Then see if modesetting(4) comes up. For the intel(4) driver, > try `Option "AccelMethod" "UXA"', or even `"none"' as a last resort. The > intelfb(4) manpage lists other options which you can turn off or disable > with the SNA or UXA accel-methods. modesetting - none and intel - none combinations start the display with a very poor refresh rate. They appear garbled and settle down slowly. intel - UXA is kind of working now. Finally some X11 on the device! I'll test some video playing etc. and report back. Thanks for your help! -- Mayuresh
Re: i915 observations
Hi! Topic: i915 observations; was: Acer Aspire XC-895 Problem Acer Revo RN86 Box: OK screen with i915drmkms (without install, in this case only boot from installation image) https://disk.yandex.ru/d/3od-FVeT-2u8kw
Re: i915 observations (UXA attempt)
Hi Robert NetBSD/amd64 -current ~2 days ago Frank On 07/22/22 11:40, Robert Swindells wrote: Frank Kardel wrote: Sadly no luck here. I blindly used X -configure, removed references to the NVIDIA card, set Option "AccelMethod" "UXA" and started kdm. When startingI was greeted with: [89.357] (II) IGLX: Loaded and initialized swrast [89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [89.357] (II) Initializing extension XFree86-VidModeExtension [89.358] (II) Initializing extension XFree86-DGA [89.358] (II) Initializing extension XFree86-DRI [89.358] (II) Initializing extension DRI2 [89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer object does not match constraints: size=8388608, must be greater than 8294400, but less than 4194304 [89.361] (EE) and in my simple world is it hard to provide a solution for 8294400 < X < 4194304. The 4194304 number is derived from the AGP aperture size. Is this on NetBSD/amd64 or NetBSD/i386?
Re: i915 observations (UXA attempt)
Frank Kardel wrote: >Sadly no luck here. I blindly used X -configure, removed references to >the NVIDIA card, > >set Option "AccelMethod" "UXA" and started kdm. > >When startingI was greeted with: > >[89.357] (II) IGLX: Loaded and initialized swrast >[89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0 >[89.357] (II) Initializing extension XFree86-VidModeExtension >[89.358] (II) Initializing extension XFree86-DGA >[89.358] (II) Initializing extension XFree86-DRI >[89.358] (II) Initializing extension DRI2 >[89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer >object does not match constraints: size=8388608, must be greater than >8294400, but less than 4194304 >[89.361] (EE) > >and in my simple world is it hard to provide a solution for 8294400 < X >< 4194304. The 4194304 number is derived from the AGP aperture size. Is this on NetBSD/amd64 or NetBSD/i386?
Re: i915 observations (UXA attempt)
Hi John ! Sadly no luck here. I blindly used X -configure, removed references to the NVIDIA card, set Option "AccelMethod" "UXA" and started kdm. When startingI was greeted with: [89.357] (II) IGLX: Loaded and initialized swrast [89.357] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [89.357] (II) Initializing extension XFree86-VidModeExtension [89.358] (II) Initializing extension XFree86-DGA [89.358] (II) Initializing extension XFree86-DRI [89.358] (II) Initializing extension DRI2 [89.360] (EE) intel(0): intel_uxa_set_pixmap_bo: size of buffer object does not match constraints: size=8388608, must be greater than 8294400, but less than 4194304 [89.361] (EE) and in my simple world is it hard to provide a solution for 8294400 < X < 4194304. Did I miss something in the configuration? Configuration, log and dmesg -v -x is attached. Frank UXA.tar.gz Description: application/gzip
Re: i915 observations
Hi John ! Yes the next line is: [41.126] (WW) intel(0): Unknown chipset It is part if the CPU which is: Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz https://www.intel.com/content/www/us/en/products/sku/201837/intel-core-i710750h-processor-12m-cache-up-to-5-00-ghz/specifications.html I'll check UXA in a few hours. On 07/22/22 01:01, John D. Baker wrote: [...] Somewhere in here, not too much after the above messages, there should be a line that tells exactly what graphics device was found. For example, on my machine, it will say: [...] Up to this point, a real i82915 and earlier were observed to work fine with SNA, i82945 through at least i82Q45 do not work with SNA and the various "*well" and "*Bridge" devices again worked with SNA. I have only i82810e, i82845, i82915, i8294[56], i82G41 and i82Q45 based systems so that limits how far I was able to test things. Frank
Re: i915 observations
Hi John ! I think you might be onto something there. From Xorg.0.log (selected lines). [41.004] (--) PCI:*(0@0:2:0) 8086:9bc4:17aa:22a7 rev 5, Mem @ 0x604000/16777216, 0x40/268435456, I/O @ 0x4000/64 Thats for the CPU [41.104] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 [41.105] (II) intel: Driver for Intel(R) HD Graphics [41.105] (II) intel: Driver for Intel(R) Iris(TM) Graphics [41.105] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics [41.105] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [41.106] (II) VESA: driver for VESA chipsets: vesa [41.106] (II) wsfb: driver for wsdisplay framebuffer: wsfb [41.106] (--) Using wscons driver on /dev/ttyE4 in pcvt compatibility mode (version 3.32) [41.106] (--) using VT number 5 [41.124] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20200114 [41.125] (WW) Falling back to old probe method for modesetting [41.126] (WW) Falling back to old probe method for wsfb [41.126] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support ### there is also an unsupported NVIDIA Card in there. [41.144] (II) intel(0): SNA initialized with disabled backend [41.144] (==) intel(0): Backing store enabled [41.144] (==) intel(0): Silken mouse enabled [41.147] (II) intel(0): HW Cursor enabled [41.153] (==) intel(0): DPMS enabled [41.157] (II) intel(0): Textured video not supported on this hardware or backend [41.157] (WW) intel(0): loading DRI2 whilst acceleration is disabled. and yes SNA is enabled. I'll try with UXA tomorrow when I am back at the machine. Thanks for the hint. Frank On 07/21/22 23:10, John D. Baker wrote: The description of the phenomena sounds a lot like what I observed when the intel driver from 2019 was imported and SNA acceleration (the default) was used on some older intel graphics devices. Using the "modesetting" driver or setting UXA acceleration with the intel driver "fixed" (sidestepped?) the problem. The default for the affected range of devices (as far as was known at the time) was later changed to UXA. What device(s) are used in the affected machines and are they trying to use SNA acceleration?
Re: i915 observations
On Thu, Jul 21, 2022 at 09:29:36PM +0200, Tobias Nygren wrote: > > Eventu?lly, the image tends to converge to the intended one (except > > maybe for the clock itself, which tends to lag behind all the time). > > I believe the effect you see is framebuffer contents written to > the CPU cache but not flushed out to memory. This is why the artefacts > lazily repair themselves when background jobs that cause frequent cache > line misses are run. (Note how the artefacts are always 1 pixel high, > 64-bytes wide and seemingly randomly positioned.) Why, yes, that sounds like a probable cause. I remember that the repairs were quicker when the system was under load, but I initially thought it was due to the copious output being displayed. Your explanation fits my observation that the repairs are still quick even if the terminal running the demanding command is hidden, or when the output is redirected to /dev/null. My conjecture was that the problem is connected with some power-saving states.
Re: i915 observations
On Thu, Jul 21, 2022 at 10:51:15AM +0200, Frank Kardel wrote: > Where do we collect i915 (-current) issues? We don't seem > to have many PRs in that area. I have a data point with a > Thinkpad T15p where i915 almost works but has flickering > dark dashes and massively delayed keyboard input. > Unfortunately I have to pass the notebook on to a > college. I believe I may have the same issue with ASUS EeeBox PC EB1037, which I’m not going to part with any time soon, although I would describe it differently. In my case, the dashes don’t flicker. I think the image is updated through seemingly randomly placed short horizontal segments. The less of the screen needs updating, the slower the update becomes. Full-screen updates are devoid of such glitches. I also wouldn’t call the keyboard input delayed. I would say that visual effects of keyboard input usually were delayed due to the fact that they tend to require just a small part of the screen updated. This is most visible when logging in with xdm. Once logged in, I have a clock displayed, which enforces an update every second, which also updates some of the remaining dashes. Eventuąlly, the image tends to converge to the intended one (except maybe for the clock itself, which tends to lag behind all the time). Perhaps such descriptions don’t illustrate the symptom well. I may try to record a screencast to see if it captures the glitches.
Re: i915 observations
> I also wouldn?t call the keyboard input delayed. I would say > that visual effects of keyboard input usually were delayed due > to the fact that they tend to require just a small part of the > screen updated. This is most visible when logging in with xdm. > > Once logged in, I have a clock displayed, which enforces an update > every second, which also updates some of the remaining dashes. > Eventu?lly, the image tends to converge to the intended one (except > maybe for the clock itself, which tends to lag behind all the time). I believe the effect you see is framebuffer contents written to the CPU cache but not flushed out to memory. This is why the artefacts lazily repair themselves when background jobs that cause frequent cache line misses are run. (Note how the artefacts are always 1 pixel high, 64-bytes wide and seemingly randomly positioned.)
Re: i915 observations
Hi Mateusz, your description matches what I see. So this is not an isolated scenario. Frank On 07/21/22 20:56, Mateusz Poszwa wrote: On Thu, Jul 21, 2022 at 10:51:15AM +0200, Frank Kardel wrote: Where do we collect i915 (-current) issues? We don't seem to have many PRs in that area. I have a data point with a Thinkpad T15p where i915 almost works but has flickering dark dashes and massively delayed keyboard input. Unfortunately I have to pass the notebook on to a college. I believe I may have the same issue with ASUS EeeBox PC EB1037, which I’m not going to part with any time soon, although I would describe it differently. In my case, the dashes don’t flicker. I think the image is updated through seemingly randomly placed short horizontal segments. The less of the screen needs updating, the slower the update becomes. Full-screen updates are devoid of such glitches. I also wouldn’t call the keyboard input delayed. I would say that visual effects of keyboard input usually were delayed due to the fact that they tend to require just a small part of the screen updated. This is most visible when logging in with xdm. Once logged in, I have a clock displayed, which enforces an update every second, which also updates some of the remaining dashes. Eventuąlly, the image tends to converge to the intended one (except maybe for the clock itself, which tends to lag behind all the time). Perhaps such descriptions don’t illustrate the symptom well. I may try to record a screencast to see if it captures the glitches.
i915 observations
Hi ! Where do we collect i915 (-current) issues? We don't seem to have many PRs in that area. I have a data point with a Thinkpad T15p where i915 almost works but has flickering dark dashes and massively delayed keyboard input. Unfortunately I have to pass the notebook on to a college. Frank
