Qubes 4.0.x - Linux kernel 4.19.15 package available in testing repository
570 views
Skip to first unread message
Marek Marczykowski-Górecki
Jan 19, 2019, 7:57:48 PM1/19/19
to qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
There is updated "kernel" package available in current-testing
repository - it's a Linux long term support 4.19.x series, as an update
over 4.14.x before. Since the upgrade switches to the next major LTS
branch, I'll keep it in current-testing repository longer than usual 1-2
weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
Please report new issues the usual way, at qubes-issues[1], or
simply by replying here. In either case, please mark it clearly it
happens after updating to 4.19, preferably including a link to the
update:
https://github.com/QubesOS/updates-status/issues/850
4.19.x kernel was already available as kernel-latest package for some
time. Users of kernel-latest will see the update to 4.19.15 too, but
kernel-latest soon will carry 4.20.x kernel version.
[1] https://github.com/QubesOS/qubes-issues/issues
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxDx4YACgkQ24/THMrX
1ywtlgf9HE/mQmGQIZtymeLHdeAP6FnpBhGrbaJESWM2AhFxRFIQpGLEBIIrpKvH
K6aFYqbFPNHYPE2DnboHmHebP1But8krrSbi4Ig5Z6E1pTFIk9XTrPQSbyY8jei9
hGY6Y8NRdTB3ljAbQpdLmfvmq9LksBQox9V5v+7lbNd6IhFOuqYnfcjz/P6PWO/F
Np/orRT2QEB5Hzuqgm8dnfKUY1NBiwE1Nbxe2vl9OqrEkpceo4sKpBhEpF3LX7Z4
aTjroOnfk4Hrb2souyTKuVhRaBdHP3wxxof+xNcsakFQNp96Jeh/2b/+im6CSaEa
9BUaPC82RwFT//o8TvYwyybX8wuLpg==
=nKaU
-----END PGP SIGNATURE-----
Hash: SHA256
Hi all,
There is updated "kernel" package available in current-testing
repository - it's a Linux long term support 4.19.x series, as an update
over 4.14.x before. Since the upgrade switches to the next major LTS
branch, I'll keep it in current-testing repository longer than usual 1-2
weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
Please report new issues the usual way, at qubes-issues[1], or
simply by replying here. In either case, please mark it clearly it
happens after updating to 4.19, preferably including a link to the
update:
https://github.com/QubesOS/updates-status/issues/850
4.19.x kernel was already available as kernel-latest package for some
time. Users of kernel-latest will see the update to 4.19.15 too, but
kernel-latest soon will carry 4.20.x kernel version.
[1] https://github.com/QubesOS/qubes-issues/issues
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxDx4YACgkQ24/THMrX
1ywtlgf9HE/mQmGQIZtymeLHdeAP6FnpBhGrbaJESWM2AhFxRFIQpGLEBIIrpKvH
K6aFYqbFPNHYPE2DnboHmHebP1But8krrSbi4Ig5Z6E1pTFIk9XTrPQSbyY8jei9
hGY6Y8NRdTB3ljAbQpdLmfvmq9LksBQox9V5v+7lbNd6IhFOuqYnfcjz/P6PWO/F
Np/orRT2QEB5Hzuqgm8dnfKUY1NBiwE1Nbxe2vl9OqrEkpceo4sKpBhEpF3LX7Z4
aTjroOnfk4Hrb2souyTKuVhRaBdHP3wxxof+xNcsakFQNp96Jeh/2b/+im6CSaEa
9BUaPC82RwFT//o8TvYwyybX8wuLpg==
=nKaU
-----END PGP SIGNATURE-----
Achim Patzner
Jan 20, 2019, 7:05:00 AM1/20/19
to Marek Marczykowski-Górecki, qubes-users
Well... Keep it. All CPUs are coming up and for the first time since
the 4.0 release touchpad and track point are working on Lenovo P52. And
all of the things that got successively worse to 4.19.12 are gone.
Achim
the 4.0 release touchpad and track point are working on Lenovo P52. And
all of the things that got successively worse to 4.19.12 are gone.
Achim
gold...@riseup.net
Jan 20, 2019, 7:49:37 AM1/20/19
to Marek Marczykowski-Górecki, qubes-users
The only minor bug I've noticed is: the encrypted disk password gui
screen is missing at login. However, login remain available via terminal
seshu
Jan 20, 2019, 1:52:56 PM1/20/19
to qubes-users
Since the templates and qubes are working fine, would that indicate the new kernel would work fine on dom0? Just wondering if I should give it a try or not.
Frédéric Pierret
Jan 24, 2019, 8:21:56 AM1/24/19
to seshu, qubes-users
The kernel in dom0 and VM is working fine, at least for me as I tested it several days, but there is no reason now it should not.
For the bug with graphical boot we are looking at what is the
problem. It appears again if you try to boot directly on the linux
kernel like you would do in Fedora for example but it disappears
in normal boot xen kernel.
Frédéric
On 1/20/19 7:52 PM, seshu wrote:
> On Sunday, January 20, 2019 at 12:57:48 AM UTC, Marek Marczykowski-Górecki wrote:
> On Sunday, January 20, 2019 at 12:57:48 AM UTC, Marek Marczykowski-Górecki wrote:
Hi all,
There is updated "kernel" package available in current-testing
repository - it's a Linux long term support 4.19.x series, as an update
over 4.14.x before. Since the upgrade switches to the next major LTS
branch, I'll keep it in current-testing repository longer than usual 1-2
weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
Please report new issues the usual way, at qubes-issues[1], or
simply by replying here. In either case, please mark it clearly it
happens after updating to 4.19, preferably including a link to the
update:
https://github.com/QubesOS/updates-status/issues/850
4.19.x kernel was already available as kernel-latest package for some
time. Users of kernel-latest will see the update to 4.19.15 too, but
kernel-latest soon will carry 4.20.x kernel version.
[1] https://github.com/QubesOS/qubes-issues/issues
Patrik Hagara
Jan 24, 2019, 11:18:41 AM1/24/19
to Marek Marczykowski-Górecki, qubes-users
On 1/20/19 1:57 AM, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> There is updated "kernel" package available in current-testing
> repository - it's a Linux long term support 4.19.x series, as an update
> over 4.14.x before. Since the upgrade switches to the next major LTS
> branch, I'll keep it in current-testing repository longer than usual 1-2
> weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
> Please report new issues the usual way, at qubes-issues[1], or
> simply by replying here. In either case, please mark it clearly it
> happens after updating to 4.19, preferably including a link to the
> update:
> https://github.com/QubesOS/updates-status/issues/850
>
> 4.19.x kernel was already available as kernel-latest package for some
> time. Users of kernel-latest will see the update to 4.19.15 too, but
> kernel-latest soon will carry 4.20.x kernel version.
>
> [1] https://github.com/QubesOS/qubes-issues/issues
>
>
I get weird graphical artifacts with the new kernel after ~an hour of
> Hi all,
>
> There is updated "kernel" package available in current-testing
> repository - it's a Linux long term support 4.19.x series, as an update
> over 4.14.x before. Since the upgrade switches to the next major LTS
> branch, I'll keep it in current-testing repository longer than usual 1-2
> weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
> Please report new issues the usual way, at qubes-issues[1], or
> simply by replying here. In either case, please mark it clearly it
> happens after updating to 4.19, preferably including a link to the
> update:
> https://github.com/QubesOS/updates-status/issues/850
>
> 4.19.x kernel was already available as kernel-latest package for some
> time. Users of kernel-latest will see the update to 4.19.15 too, but
> kernel-latest soon will carry 4.20.x kernel version.
>
> [1] https://github.com/QubesOS/qubes-issues/issues
>
>
usage. Windows from AppVMs turn all white sometimes when switching
workspaces in i3wm. Events like mousing over an interactive table rows
in a browser (when the current row gets highlighted) return that
particular section of the window back to normal (but not the whole
window, for that I need to trigger a repaint of the whole window by eg.
making it full-screen and immediately switching back to non-full-screen).
Haven't had to time to debug this issue yet, will look closer over the
next weekend or two. For now I've reverted to using the old kernel from
stable repo and the issue went away.
Cheers,
Patrik
Patrik Hagara
Jan 25, 2019, 7:59:04 AM1/25/19
to Marek Marczykowski-Górecki, qubes-users
On 1/24/19 5:18 PM, Patrik Hagara wrote:
> On 1/20/19 1:57 AM, Marek Marczykowski-Górecki wrote:
>> Hi all,
>>
>> There is updated "kernel" package available in current-testing
>> repository - it's a Linux long term support 4.19.x series, as an update
>> over 4.14.x before. Since the upgrade switches to the next major LTS
>> branch, I'll keep it in current-testing repository longer than usual 1-2
>> weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
>> Please report new issues the usual way, at qubes-issues[1], or
>> simply by replying here. In either case, please mark it clearly it
>> happens after updating to 4.19, preferably including a link to the
>> update:
>> https://github.com/QubesOS/updates-status/issues/850
>>
>> 4.19.x kernel was already available as kernel-latest package for some
>> time. Users of kernel-latest will see the update to 4.19.15 too, but
>> kernel-latest soon will carry 4.20.x kernel version.
>>
>> [1] https://github.com/QubesOS/qubes-issues/issues
>>
>>
>
> I get weird graphical artifacts with the new kernel after ~an hour of
> usage. Windows from AppVMs turn all white sometimes when switching
> workspaces in i3wm. Events like mousing over an interactive table rows
> in a browser (when the current row gets highlighted) return that
> particular section of the window back to normal (but not the whole
> window, for that I need to trigger a repaint of the whole window by eg.
> making it full-screen and immediately switching back to non-full-screen).
The only error message I've been able to find so far is in dom0 Xorg log:
> On 1/20/19 1:57 AM, Marek Marczykowski-Górecki wrote:
>> Hi all,
>>
>> There is updated "kernel" package available in current-testing
>> repository - it's a Linux long term support 4.19.x series, as an update
>> over 4.14.x before. Since the upgrade switches to the next major LTS
>> branch, I'll keep it in current-testing repository longer than usual 1-2
>> weeks. This also applies to kernel package for VMs: kernel-qubes-vm.
>> Please report new issues the usual way, at qubes-issues[1], or
>> simply by replying here. In either case, please mark it clearly it
>> happens after updating to 4.19, preferably including a link to the
>> update:
>> https://github.com/QubesOS/updates-status/issues/850
>>
>> 4.19.x kernel was already available as kernel-latest package for some
>> time. Users of kernel-latest will see the update to 4.19.15 too, but
>> kernel-latest soon will carry 4.20.x kernel version.
>>
>> [1] https://github.com/QubesOS/qubes-issues/issues
>>
>>
>
> I get weird graphical artifacts with the new kernel after ~an hour of
> usage. Windows from AppVMs turn all white sometimes when switching
> workspaces in i3wm. Events like mousing over an interactive table rows
> in a browser (when the current row gets highlighted) return that
> particular section of the window back to normal (but not the whole
> window, for that I need to trigger a repaint of the whole window by eg.
> making it full-screen and immediately switching back to non-full-screen).
> (EE) intel(0): Failed to submit rendering commands (Bad address),
disabling acceleration.
Duckduckgo-ing the error message yielded a few [1][2] Arch Linux bug
reports describing the same symptoms. The first bug report also has a
kernel patch [3] linked, which supposedly fixes the issue (haven't tried
it).
[1] https://bugs.archlinux.org/task/43143
[2] https://bugs.archlinux.org/task/55732
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91
Cheers,
Patrik
Marek Marczykowski-Górecki
Jan 25, 2019, 9:16:18 AM1/25/19
to Patrik Hagara, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
user-space issue, but the only thing changed is the kernel version... It
may be also that some kernel API have changed and the driver is using
parts that weren't there before.
Anyway, I've looked into 'intel' X driver sources and the version we
currently have (2.99.917) is the latest one. On the other hand, there
was over 800 commits since that release and some of them may be related.
For example maybe this: https://bugs.freedesktop.org/show_bug.cgi?id=105886
This suggests you may want to try enabling or disabling composition, if
i3wm supports it.
> Duckduckgo-ing the error message yielded a few [1][2] Arch Linux bug
> reports describing the same symptoms. The first bug report also has a
> kernel patch [3] linked, which supposedly fixes the issue (haven't tried
> it).
> [1] https://bugs.archlinux.org/task/43143
> [2] https://bugs.archlinux.org/task/55732
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91
>
> Cheers,
> Patrik
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxLGisACgkQ24/THMrX
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yyRKwf9G9TX89Bh2aePabdq7k40zDEHK68sKmsbL7xcm0JpfsdXHK/MuM+B4AyJ
BT7PrEIr8n1wXc++EArbtwapIPldICAhnBRK4fFdazHmtgAeW5S1GztAFisa4EaD
w0AWDoLLVg4DR7AcwFi1EXse4jgT0/CSYkHIENM0QRl4uevEV6lKlpN4lS8Rgjm8
cUCXajC5RCLT3RVDUTzufUOxLLt/syRzGVtBsgJqCwvVdnOxArZqlEJgSI7wq9lN
HR6OSv1ETGdlubxegn2LsAtqLvHXD+vnV11hgT4EvSZhHTfcbOI8FJdsnU8YxNY1
vsHV3L772QpTm3+jZ05X8AxJLEYrHA==
=XaRm
-----END PGP SIGNATURE-----
donoban
Jan 26, 2019, 6:41:00 AM1/26/19
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 1/24/19 5:18 PM, Patrik Hagara wrote:
> I get weird graphical artifacts with the new kernel after ~an hour
> of usage. Windows from AppVMs turn all white sometimes when
> switching workspaces in i3wm. Events like mousing over an
> interactive table rows in a browser (when the current row gets
> highlighted) return that particular section of the window back to
> normal (but not the whole window, for that I need to trigger a
> repaint of the whole window by eg. making it full-screen and
> immediately switching back to non-full-screen).
>
> Haven't had to time to debug this issue yet, will look closer over
> the next weekend or two. For now I've reverted to using the old
> kernel from stable repo and the issue went away.
>
I am also getting graphical artifacts with KDE. Although I think that
> of usage. Windows from AppVMs turn all white sometimes when
> switching workspaces in i3wm. Events like mousing over an
> interactive table rows in a browser (when the current row gets
> highlighted) return that particular section of the window back to
> normal (but not the whole window, for that I need to trigger a
> repaint of the whole window by eg. making it full-screen and
> immediately switching back to non-full-screen).
>
> Haven't had to time to debug this issue yet, will look closer over
> the next weekend or two. For now I've reverted to using the old
> kernel from stable repo and the issue went away.
>
I also had some in the past now they appear very soon. Sometimes I
have to close and reopen a window because it stops redrawing except I
move or resize it.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlxMRz8ACgkQFBMQ2OPt
CKWgIA/+ISduFIH5euTsqOzUGnoaxC0xK4PG/tdkMoIHEnIwOt6Zd0hTkNhDSXwv
YelHOiL3WVlNvVxG4ZAahJsDrUdA7MR98nHd4rDlc53htmH+7ZhD6rVEJMRzEbIU
zbT0Ipwv0I5lsd/cXKY0bZq4Dp8scdpm4qF9hVBRayDynU4w6KrqbMzvhSMbV84d
Wz/34eGUAO0EHaYC8RFAqF84bpsdEALnJFQppIaPuj1wmFyiB4vURvNor5hYxmwi
OYKiQrRr+QVN/eUJghXmbnruV9X1YtbZmTHD7+hQkWWRZ02nIsnQHJoHhGyDhGJd
BNhnbpjAmZWMKe9UUiuVllWHgPre4s4e9T5EQBvf3dSmuVWKNASJkNDOe3sLLbKh
zchsS+opGsKIo/wIojJQ0JsyRbwxgBlMmYbeiNHDyQVKb5/O1T4/8Q3iYO0sMD9D
XuJUtD9Ip4/xH/H9QSL9kyiYEuoK2Pl8GWyeoCK6171IPJlwgvm7oxbIqYS5ckH2
/0NDnFJfhOG0PylCsIbLYBsPeYJ+yy8m7D22v8WkNSPfGtlqSwTUS7U8cOe8pX1r
xZrs7rqJ/c+8wmy6ZIRZk8lYLMGXSf1LyCpJQJC9mDHDp1CoP/WV3HVDXBuovYye
wWZdoxvh2jtdAkZOFAC9iw0EiUeDc9O3uccW/z+N8h+utC4XYx0=
=f+V0
-----END PGP SIGNATURE-----
Patrik Hagara
Jan 29, 2019, 5:33:30 AM1/29/19
to Marek Marczykowski-Górecki, donoban, qubes-users
Managed to get rid of the error (and more importantly, the annoying
artifacts) by forcing Xorg to use the generic modesetting driver instead
of i915/i965.
Steps (all commands in dom0):
1) check the driver currently in use (`xrandr --listproviders`), it's
the last string (should be "name:Intel" now)
2) create file /etc/X11/xorg.conf.d/20-intel.conf (as root) with the
following contents (also make sure there are no other files in that
directory with "Device" "Driver" set to "intel"):
> Section "Device"
> Identifier "Intel Graphics"
> Driver "modesetting"
> Option "AccelMethod" "glamor"
> Option "DRI" "3"
> EndSection
3) restart the X server (eg. using `sudo systemctl restart lightdm`)
4) use the same xrandr command as in step 1, the driver should now be
"modesetting" and you should see no errors in /var/log/Xorg.0.log, nor
any graphical artifacts
As a side note, I discovered a reliable reproducer for the issue: run
`glxgears` in dom0 and then start thunderbird in some appvm. For me,
this always triggered the i915 bug (logged in /var/log/Xorg.0.log) and
the gears stopped turning (due to the acceleration being disabled, I guess).
My hardware (sorry for not mentioning this earlier): Lenovo T480s with
i7-8650U, no discrete GPU.
Pages that have been helpful:
* https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX
*
https://ask.fedoraproject.org/en/question/130414/enabling-glamordri3-fedora-29-gnome-xorg/
*
https://www.reddit.com/r/Fedora/comments/5uo6ta/modesetting_driver_fedora_25/
*
https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch
Cheers,
Patrik
donoban
Jan 29, 2019, 10:48:57 AM1/29/19
to qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 1/29/19 11:33 AM, Patrik Hagara wrote:
>
> Update!
>
> Managed to get rid of the error (and more importantly, the
> annoying artifacts) by forcing Xorg to use the generic modesetting
> driver instead of i915/i965.
>
>
> Update!
>
> Managed to get rid of the error (and more importantly, the
> annoying artifacts) by forcing Xorg to use the generic modesetting
> driver instead of i915/i965.
>
> Pages that have been helpful: *
> https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX *
> https://ask.fedoraproject.org/en/question/130414/enabling-glamordri3-f
edora-29-gnome-xorg/
>
>
*
> https://www.reddit.com/r/Fedora/comments/5uo6ta/modesetting_driver_fed
ora_25/
>
>
*
> https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-
DDX-Switch
>
>
Great! Very nice :)
> https://wiki.gentoo.org/wiki/Intel#Modesetting_DDX *
> https://ask.fedoraproject.org/en/question/130414/enabling-glamordri3-f
edora-29-gnome-xorg/
>
>
*
> https://www.reddit.com/r/Fedora/comments/5uo6ta/modesetting_driver_fed
ora_25/
>
>
*
> https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-
DDX-Switch
>
>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlxQdd8ACgkQFBMQ2OPt
CKU3dxAAuf/KxeuXzvscYiAIbehsJ3Z2h+t4DofMtwDCGECetUx0h3LSnrqaLxVL
1hC8q8psqGZfEhnnQ8XymLQMIUbBF0dIl7GGOEm7a/YBrr3e6/sewbPUy4OYZeZf
4dFv/vxTLbOhv/k2RnkW/BefF37O5Y779+uheafbhgAYjXCSQSZYiEYLaiiyzTc+
qEBC8teu0Eg9ljnXEfW+Ukm2UilEaP/uGIqM3Gv8Z5mu6/tsAczHFxwmQKc4jnCV
3bFOFw+ck8mLGIb85IdgErwi8chRMprtJQi20TfxQMokkmob+7qlspCg0LOr7+qi
R7FyuPeADDuoTWrotebtiyt8+KVBK6TASllSa2ipuYWFKHII5VS8JIK3vVgcYyTb
X0KwMz8c4cFHqPHZHu/90njVEr9FHLoVXdyXDXoTg19fS/CNZKrkGOqFwLxIx68T
/LSlvOgB+xBzlEmntG4feJxXOTQIVydzXTU/8o5J/xsOWBGZfNR4ToHDokMLB9cI
j/ij6mUv6/LOO20g1u2BHfUyNEj11QV2rYuDf4/Osqf+vjPhU6g+tN0OjkQtSYIO
REK7Mdpc1icPzG5KE1pXw0reMFbOdNzQY/JgjU/Cx75c2OFBU5jDE9QuRyyeo+4R
kEJEvPbyQdgFXiGQNflb51Ynqq5AWJaMlA/AtszC3lYRAdUWUrA=
=q2fJ
-----END PGP SIGNATURE-----
Michał "rysiek" Woźniak
Sep 26, 2019, 7:50:34 AM9/26/19
to qubes...@googlegroups.com
Hey,
On 1/29/19 10:33 AM, Patrik Hagara wrote:
> Managed to get rid of the error (and more importantly, the annoying
> artifacts) by forcing Xorg to use the generic modesetting driver instead
> of i915/i965.
>
> Steps (all commands in dom0):
>
> 1) check the driver currently in use (`xrandr --listproviders`), it's
> the last string (should be "name:Intel" now)
>
> 2) create file /etc/X11/xorg.conf.d/20-intel.conf (as root) with the
> following contents (also make sure there are no other files in that
> directory with "Device" "Driver" set to "intel"):
>
>> Section "Device"
>> Identifier "Intel Graphics"
>> Driver "modesetting"
>> Option "AccelMethod" "glamor"
>> Option "DRI" "3"
>> EndSection
>
> 3) restart the X server (eg. using `sudo systemctl restart lightdm`)
>
> 4) use the same xrandr command as in step 1, the driver should now be
> "modesetting" and you should see no errors in /var/log/Xorg.0.log, nor
> any graphical artifacts
After this procedure, do you get hardware acceleration? In my case, I do
get `name:modesetting`, but I also get these in Xorg.0.log (and no
hardware acceleration, obviously):
[ 29.654] EGL_MESA_drm_image required.
[ 29.654] (EE) modeset(G0): glamor initialization failed
(...)
[ 29.728] (EE) AIGLX: reverting to software rendering
Did you install/remove any packages? Can you share the output you get
from `dnf list mesa* libdrm* xorg*`?
> My hardware (sorry for not mentioning this earlier): Lenovo T480s with
> i7-8650U, no discrete GPU.
I'm on a T490. Will also test on a T470 later.
--
Best
r
On 1/29/19 10:33 AM, Patrik Hagara wrote:
> Managed to get rid of the error (and more importantly, the annoying
> artifacts) by forcing Xorg to use the generic modesetting driver instead
> of i915/i965.
>
> Steps (all commands in dom0):
>
> 1) check the driver currently in use (`xrandr --listproviders`), it's
> the last string (should be "name:Intel" now)
>
> 2) create file /etc/X11/xorg.conf.d/20-intel.conf (as root) with the
> following contents (also make sure there are no other files in that
> directory with "Device" "Driver" set to "intel"):
>
>> Section "Device"
>> Identifier "Intel Graphics"
>> Driver "modesetting"
>> Option "AccelMethod" "glamor"
>> Option "DRI" "3"
>> EndSection
>
> 3) restart the X server (eg. using `sudo systemctl restart lightdm`)
>
> 4) use the same xrandr command as in step 1, the driver should now be
> "modesetting" and you should see no errors in /var/log/Xorg.0.log, nor
> any graphical artifacts
get `name:modesetting`, but I also get these in Xorg.0.log (and no
hardware acceleration, obviously):
[ 29.654] EGL_MESA_drm_image required.
[ 29.654] (EE) modeset(G0): glamor initialization failed
(...)
[ 29.728] (EE) AIGLX: reverting to software rendering
Did you install/remove any packages? Can you share the output you get
from `dnf list mesa* libdrm* xorg*`?
> My hardware (sorry for not mentioning this earlier): Lenovo T480s with
> i7-8650U, no discrete GPU.
--
Best
r
donoban
Sep 26, 2019, 7:59:28 AM9/26/19
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 2019-09-26 13:50, Michał "rysiek" Woźniak wrote:
> Hey,
>
> On 1/29/19 10:33 AM, Patrik Hagara wrote:
>> Managed to get rid of the error (and more importantly, the
>> annoying artifacts) by forcing Xorg to use the generic
>> modesetting driver instead of i915/i965. ... ...
> Hey,
>
> On 1/29/19 10:33 AM, Patrik Hagara wrote:
>> Managed to get rid of the error (and more importantly, the
>> annoying artifacts) by forcing Xorg to use the generic
> After this procedure, do you get hardware acceleration? In my case,
> I do get `name:modesetting`, but I also get these in Xorg.0.log
> (and no hardware acceleration, obviously):
>
> [ 29.654] EGL_MESA_drm_image required. [ 29.654] (EE)
> modeset(G0): glamor initialization failed (...) [ 29.728] (EE)
> AIGLX: reverting to software rendering
>
I did same steps and I have acceleration working fine.
> I do get `name:modesetting`, but I also get these in Xorg.0.log
> (and no hardware acceleration, obviously):
>
> [ 29.654] EGL_MESA_drm_image required. [ 29.654] (EE)
> modeset(G0): glamor initialization failed (...) [ 29.728] (EE)
> AIGLX: reverting to software rendering
>
> Did you install/remove any packages? Can you share the output you
> get from `dnf list mesa* libdrm* xorg*`?
>
>> My hardware (sorry for not mentioning this earlier): Lenovo T480s
>> with i7-8650U, no discrete GPU.
>
> I'm on a T490. Will also test on a T470 later.
>
dnf output.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAl2MqBMACgkQFBMQ2OPt
CKWG+Q/+Iu4u8f5FHZ7+grxRpxlZ3d8M4TUpVaBRVnhJwHVgpr6x99NGsXR7c7fK
LdhHv4oES1uYwvksATXlYcKwpQs7bLZo8+UOXAWhgrMrzy+YZTdbmvOWCrSo/Cys
idoNM6P8N8ByzXZ/TwLx5Zoco2dE5vwHorSpvkDBASG4OL4CgpQcdUOQcJApS4+v
fAV6nn5rukkb7svrvF7UJVJNrMPikWQbeJRtkwIHKcyX7qNc2oOCs+3yBn9vIOEA
AZux704wCdzJnMnKG16raA2HhMZCikijefUMzDc4ihdMKAcpaBebuUU1wc7zIHKS
hF73jnUzEX5QmOwC6UEoHAYsgETpbSnAwxBToZRVjlqdZ4jy825XcWwZQ6qwKkSF
lFTvB4p296xoAsTbZB+867YsS/GVCG+/eBIew/9lPYLTTTh14zWqPujuUs9cD6U+
JlrAnFEqBCQ+Ky2520Q++yb8UsrlxqQ/uTWAtAlOToP30EXHkmG7T0QEevGISU+0
FTK87h8lFEkjOjQ7/906/YhL2lTLO7oWwgrgA6JIGgTj5yiuOwW0SPDkVg/0BvXp
cTbMrtbhI3R8KWtKV0avet4Ckv4xmwKO4Nxci6bn0az4e/u3+Mylmc1jSjavZ7cc
RhHdDcGd0Oh0nj1YXUn1XB6ZzV1jtTxEGhyUTPDjtrOqK1MuZp0=
=nr5J
-----END PGP SIGNATURE-----
Michał "rysiek" Woźniak
Sep 26, 2019, 8:31:52 AM9/26/19
to qubes...@googlegroups.com
On 9/26/19 11:59 AM, donoban wrote:
>> On 1/29/19 10:33 AM, Patrik Hagara wrote:
>>> Managed to get rid of the error (and more importantly, the
>>> annoying artifacts) by forcing Xorg to use the generic
>>> modesetting driver instead of i915/i965. ... ...
>>>
>> After this procedure, do you get hardware acceleration? In my case,
>> I do get `name:modesetting`, but I also get these in Xorg.0.log
>> (and no hardware acceleration, obviously):
> (...)
>> On 1/29/19 10:33 AM, Patrik Hagara wrote:
>>> Managed to get rid of the error (and more importantly, the
>>> annoying artifacts) by forcing Xorg to use the generic
>>> modesetting driver instead of i915/i965. ... ...
>>>
>> After this procedure, do you get hardware acceleration? In my case,
>> I do get `name:modesetting`, but I also get these in Xorg.0.log
>> (and no hardware acceleration, obviously):
> I did same steps and I have acceleration working fine.
Right. Just tried on a T470 (i5-7200U) and it worked! Many thanks.
So it's the T490 Intel chipset that refuses to cooperate. R4.1 will have
Fedora 29 in dom0, so I guess that should fix it too.
--
Best,
r
Jinoh Kang
Dec 23, 2020, 9:21:31 PM12/23/20
to qubes-users, qubes-devel, Marek Marczykowski-Górecki, donoban, Patrik Hagara
When using some Intel integrated graphic cards on Qubes R4.0, screen
glitches may manifest after switching VTs or entering suspend mode.
A known workaround does exist for this bug, which is to add a
configuration file with the following contents within
/etc/X11/xorg.conf.d:
> Section "Device"
> Identifier "Intel Graphics"
> Driver "modesetting"
> Option "AccelMethod" "glamor"
> Option "DRI" "3"
> EndSection
However, the X11 modesetting driver version in Fedora 25 has its own
drawbacks:
* It freezes briefly when re-configuring monitors (e.g. plugging in an
external monitor or changing screen resolution)
* XRandR keystone support is buggy
To remediate this, I've patched the Linux i915 driver and it has been
working fine for months. Only the patch for Linux 4.19 has been tested.
If anyone is affected by the issue, please feel free to test the
follow-up patches and give some feedback here.
See also:
* https://github.com/QubesOS/qubes-issues/issues/5244
* https://github.com/QubesOS/qubes-issues/issues/5377
* https://github.com/QubesOS/qubes-issues/issues/5460
Cheers,
Jinoh Kang
glitches may manifest after switching VTs or entering suspend mode.
A known workaround does exist for this bug, which is to add a
configuration file with the following contents within
/etc/X11/xorg.conf.d:
> Section "Device"
> Identifier "Intel Graphics"
> Driver "modesetting"
> Option "AccelMethod" "glamor"
> Option "DRI" "3"
> EndSection
drawbacks:
* It freezes briefly when re-configuring monitors (e.g. plugging in an
external monitor or changing screen resolution)
* XRandR keystone support is buggy
To remediate this, I've patched the Linux i915 driver and it has been
working fine for months. Only the patch for Linux 4.19 has been tested.
If anyone is affected by the issue, please feel free to test the
follow-up patches and give some feedback here.
See also:
* https://github.com/QubesOS/qubes-issues/issues/5244
* https://github.com/QubesOS/qubes-issues/issues/5377
* https://github.com/QubesOS/qubes-issues/issues/5460
Cheers,
Jinoh Kang
Jinoh Kang
Dec 23, 2020, 9:24:11 PM12/23/20
to qubes-users, qubes-devel, Marek Marczykowski-Górecki, donoban, Patrik Hagara
If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
returned only when the object is actually bound.
The xf86-video-intel userspace driver cannot differentiate this
condition, and marks the GPU as wedged. This disables graphics
acceleration and may cripple other functionalities such as VT switch.
Solve this by "prefaulting" user pages on GEM object creation, testing
whether all pages are eligible for get_user_pages() in the process.
On failure, return -EFAULT so that userspace can fallback to software
bliting.
This behavior can be controlled by using a new modparam
"gem_userptr_prefault", which is true by default.
The only known use for this patch is Qubes OS's GUI virtualization.
Userspace is expected to resort to DMA-BUF whenever possible.
Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 36 +++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_params.c | 3 +++
drivers/gpu/drm/i915/i915_params.h | 1 +
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 961abb6ea18e..c1e680cf037d 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -748,6 +748,34 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
.release = i915_gem_userptr_release,
};
+static int i915_gem_userptr_prefault(unsigned long start,
+ unsigned long nr_pages,
+ bool readonly)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned int gup_flags = (readonly ? 0 : FOLL_WRITE) | FOLL_NOWAIT;
+ int err = 0;
+
+ down_read(&mm->mmap_sem);
+ while (nr_pages) {
+ long ret;
+
+ ret = get_user_pages(start, nr_pages, gup_flags, NULL, NULL);
+ if (ret < 0) {
+ err = (int)ret;
+ break;
+ }
+ if (ret == 0)
+ ret = 1; /* skip this page */
+
+ start += ret << PAGE_SHIFT;
+ nr_pages -= ret;
+ }
+ up_read(&mm->mmap_sem);
+
+ return err;
+}
+
/*
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -815,6 +843,14 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
(char __user *)(unsigned long)args->user_ptr, args->user_size))
return -EFAULT;
+ if (READ_ONCE(i915_modparams.gem_userptr_prefault)) {
+ ret = i915_gem_userptr_prefault((unsigned long)args->user_ptr,
+ args->user_size >> PAGE_SHIFT,
+ args->flags & I915_USERPTR_READ_ONLY);
+ if (ret)
+ return ret;
+ }
+
if (args->flags & I915_USERPTR_READ_ONLY) {
struct i915_hw_ppgtt *ppgtt;
diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
index 295e981e4a39..702163d85921 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -174,6 +174,9 @@ i915_param_named(enable_dpcd_backlight, bool, 0600,
i915_param_named(enable_gvt, bool, 0400,
"Enable support for Intel GVT-g graphics virtualization host support(default:false)");
+i915_param_named(gem_userptr_prefault, bool, 0600,
+ "Prefault pages when userptr GEM object is created (default:true)");
+
static __always_inline void _print_param(struct drm_printer *p,
const char *name,
const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 6c4d4a21474b..86915d1fc303 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,6 +66,7 @@ struct drm_printer;
param(bool, disable_display, false) \
param(bool, verbose_state_checks, true) \
param(bool, nuclear_pageflip, false) \
+ param(bool, gem_userptr_prefault, true) \
param(bool, enable_dp_mst, true) \
param(bool, enable_dpcd_backlight, false) \
param(bool, enable_gvt, false)
--
2.26.2
returned only when the object is actually bound.
The xf86-video-intel userspace driver cannot differentiate this
condition, and marks the GPU as wedged. This disables graphics
acceleration and may cripple other functionalities such as VT switch.
Solve this by "prefaulting" user pages on GEM object creation, testing
whether all pages are eligible for get_user_pages() in the process.
On failure, return -EFAULT so that userspace can fallback to software
bliting.
This behavior can be controlled by using a new modparam
"gem_userptr_prefault", which is true by default.
The only known use for this patch is Qubes OS's GUI virtualization.
Userspace is expected to resort to DMA-BUF whenever possible.
Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 36 +++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_params.c | 3 +++
drivers/gpu/drm/i915/i915_params.h | 1 +
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 961abb6ea18e..c1e680cf037d 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -748,6 +748,34 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
.release = i915_gem_userptr_release,
};
+static int i915_gem_userptr_prefault(unsigned long start,
+ unsigned long nr_pages,
+ bool readonly)
+{
+ struct mm_struct *mm = current->mm;
+ unsigned int gup_flags = (readonly ? 0 : FOLL_WRITE) | FOLL_NOWAIT;
+ int err = 0;
+
+ down_read(&mm->mmap_sem);
+ while (nr_pages) {
+ long ret;
+
+ ret = get_user_pages(start, nr_pages, gup_flags, NULL, NULL);
+ if (ret < 0) {
+ err = (int)ret;
+ break;
+ }
+ if (ret == 0)
+ ret = 1; /* skip this page */
+
+ start += ret << PAGE_SHIFT;
+ nr_pages -= ret;
+ }
+ up_read(&mm->mmap_sem);
+
+ return err;
+}
+
/*
* Creates a new mm object that wraps some normal memory from the process
* context - user memory.
@@ -815,6 +843,14 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
(char __user *)(unsigned long)args->user_ptr, args->user_size))
return -EFAULT;
+ if (READ_ONCE(i915_modparams.gem_userptr_prefault)) {
+ ret = i915_gem_userptr_prefault((unsigned long)args->user_ptr,
+ args->user_size >> PAGE_SHIFT,
+ args->flags & I915_USERPTR_READ_ONLY);
+ if (ret)
+ return ret;
+ }
+
if (args->flags & I915_USERPTR_READ_ONLY) {
struct i915_hw_ppgtt *ppgtt;
diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
index 295e981e4a39..702163d85921 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -174,6 +174,9 @@ i915_param_named(enable_dpcd_backlight, bool, 0600,
i915_param_named(enable_gvt, bool, 0400,
"Enable support for Intel GVT-g graphics virtualization host support(default:false)");
+i915_param_named(gem_userptr_prefault, bool, 0600,
+ "Prefault pages when userptr GEM object is created (default:true)");
+
static __always_inline void _print_param(struct drm_printer *p,
const char *name,
const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 6c4d4a21474b..86915d1fc303 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,6 +66,7 @@ struct drm_printer;
param(bool, disable_display, false) \
param(bool, verbose_state_checks, true) \
param(bool, nuclear_pageflip, false) \
+ param(bool, gem_userptr_prefault, true) \
param(bool, enable_dp_mst, true) \
param(bool, enable_dpcd_backlight, false) \
param(bool, enable_gvt, false)
--
2.26.2
Jinoh Kang
Dec 23, 2020, 9:24:50 PM12/23/20
to qubes-users, qubes-devel, Marek Marczykowski-Górecki, donoban, Patrik Hagara
If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
returned only when the object is actually bound.
The xf86-video-intel userspace driver cannot differentiate this
condition, and marks the GPU as wedged. This disables graphics
acceleration and may cripple other functionalities such as VT switch.
Solve this by "prefaulting" user pages on GEM object creation, testing
whether all pages are eligible for get_user_pages() in the process.
On failure, return -EFAULT so that userspace can fallback to software
bliting.
This behavior can be controlled by using a new modparam
"gem_userptr_prefault", which is true by default.
The only known use for this patch is Qubes OS's GUI virtualization.
Userspace is expected to resort to DMA-BUF whenever possible.
Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 36 +++++++++++++++++++++
returned only when the object is actually bound.
The xf86-video-intel userspace driver cannot differentiate this
condition, and marks the GPU as wedged. This disables graphics
acceleration and may cripple other functionalities such as VT switch.
Solve this by "prefaulting" user pages on GEM object creation, testing
whether all pages are eligible for get_user_pages() in the process.
On failure, return -EFAULT so that userspace can fallback to software
bliting.
This behavior can be controlled by using a new modparam
"gem_userptr_prefault", which is true by default.
The only known use for this patch is Qubes OS's GUI virtualization.
Userspace is expected to resort to DMA-BUF whenever possible.
Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
---
drivers/gpu/drm/i915/i915_params.c | 3 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
3 files changed, 40 insertions(+)
index 6d0cc90401c0..c86862a6f592 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -739,6 +739,34 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
if (!access_ok((char __user *)(unsigned long)args->user_ptr, args->user_size))
return -EFAULT;
+ if (READ_ONCE(i915_modparams.gem_userptr_prefault)) {
+ ret = i915_gem_userptr_prefault((unsigned long)args->user_ptr,
+ args->user_size >> PAGE_SHIFT,
+ args->flags & I915_USERPTR_READ_ONLY);
+ if (ret)
+ return ret;
+ }
+
if (args->flags & I915_USERPTR_READ_ONLY) {
struct i915_address_space *vm;
+ if (READ_ONCE(i915_modparams.gem_userptr_prefault)) {
+ ret = i915_gem_userptr_prefault((unsigned long)args->user_ptr,
+ args->user_size >> PAGE_SHIFT,
+ args->flags & I915_USERPTR_READ_ONLY);
+ if (ret)
+ return ret;
+ }
+
if (args->flags & I915_USERPTR_READ_ONLY) {
diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..90a03cb8ca57 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -178,6 +178,9 @@ i915_param_named(enable_gvt, bool, 0400,
"Enable support for Intel GVT-g graphics virtualization host support(default:false)");
#endif
+i915_param_named(gem_userptr_prefault, bool, 0600,
+ "Prefault pages when userptr GEM object is created (default:true)");
+
static __always_inline void _print_param(struct drm_printer *p,
const char *name,
const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -76,6 +76,7 @@ struct drm_printer;
param(bool, disable_display, false) \
param(bool, verbose_state_checks, true) \
param(bool, nuclear_pageflip, false) \
+ param(bool, gem_userptr_prefault, true) \
param(bool, enable_dp_mst, true) \
param(bool, enable_gvt, false)
param(bool, verbose_state_checks, true) \
param(bool, nuclear_pageflip, false) \
+ param(bool, gem_userptr_prefault, true) \
param(bool, enable_dp_mst, true) \
--
2.26.2
Jinoh Kang
Dec 23, 2020, 9:25:09 PM12/23/20
to qubes-users, qubes-devel, Marek Marczykowski-Górecki, donoban, Patrik Hagara
If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
returned only when the object is actually bound.
The xf86-video-intel userspace driver cannot differentiate this
condition, and marks the GPU as wedged. This disables graphics
acceleration and may cripple other functionalities such as VT switch.
Solve this by "prefaulting" user pages on GEM object creation, testing
whether all pages are eligible for get_user_pages() in the process.
On failure, return -EFAULT so that userspace can fallback to software
bliting.
This behavior can be controlled by using a new modparam
"gem_userptr_prefault", which is true by default.
The only known use for this patch is Qubes OS's GUI virtualization.
Userspace is expected to resort to DMA-BUF whenever possible.
Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 36 +++++++++++++++++++++
drivers/gpu/drm/i915/i915_params.c | 3 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index f2eaed6aca3d..65596d2b284f 100644
returned only when the object is actually bound.
The xf86-video-intel userspace driver cannot differentiate this
condition, and marks the GPU as wedged. This disables graphics
acceleration and may cripple other functionalities such as VT switch.
Solve this by "prefaulting" user pages on GEM object creation, testing
whether all pages are eligible for get_user_pages() in the process.
On failure, return -EFAULT so that userspace can fallback to software
bliting.
This behavior can be controlled by using a new modparam
"gem_userptr_prefault", which is true by default.
The only known use for this patch is Qubes OS's GUI virtualization.
Userspace is expected to resort to DMA-BUF whenever possible.
Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 36 +++++++++++++++++++++
drivers/gpu/drm/i915/i915_params.c | 3 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -712,6 +712,34 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
if (!access_ok((char __user *)(unsigned long)args->user_ptr, args->user_size))
return -EFAULT;
+ if (READ_ONCE(i915_modparams.gem_userptr_prefault)) {
+ ret = i915_gem_userptr_prefault((unsigned long)args->user_ptr,
+ args->user_size >> PAGE_SHIFT,
+ args->flags & I915_USERPTR_READ_ONLY);
+ if (ret)
+ return ret;
+ }
+
if (args->flags & I915_USERPTR_READ_ONLY) {
/*
return -EFAULT;
+ if (READ_ONCE(i915_modparams.gem_userptr_prefault)) {
+ ret = i915_gem_userptr_prefault((unsigned long)args->user_ptr,
+ args->user_size >> PAGE_SHIFT,
+ args->flags & I915_USERPTR_READ_ONLY);
+ if (ret)
+ return ret;
+ }
+
if (args->flags & I915_USERPTR_READ_ONLY) {
* On almost all of the older hw, we cannot tell the GPU that
diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..c39766adeda2 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -197,6 +197,9 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
"Fake LMEM start offset (default: 0)");
#endif
+i915_param_named(gem_userptr_prefault, bool, 0600,
+ "Prefault pages when userptr GEM object is created (default:true)");
+
static __always_inline void _print_param(struct drm_printer *p,
const char *name,
const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
index 330c03e2b4f7..1169a610a73c 100644
+i915_param_named(gem_userptr_prefault, bool, 0600,
+ "Prefault pages when userptr GEM object is created (default:true)");
+
static __always_inline void _print_param(struct drm_printer *p,
const char *name,
const char *type,
diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -79,6 +79,7 @@ struct drm_printer;
param(bool, disable_display, false, 0400) \
param(bool, verbose_state_checks, true, 0) \
param(bool, nuclear_pageflip, false, 0400) \
+ param(bool, gem_userptr_prefault, true) \
param(bool, enable_dp_mst, true, 0600) \
param(bool, enable_gvt, false, 0400)
--
2.26.2
Marek Marczykowski-Górecki
Jan 10, 2021, 5:23:20 PM1/10/21
to Jinoh Kang, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Thu, Dec 24, 2020 at 02:24:59AM +0000, Jinoh Kang wrote:
> If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
> returned only when the object is actually bound.
>
> The xf86-video-intel userspace driver cannot differentiate this
> condition, and marks the GPU as wedged. This disables graphics
> acceleration and may cripple other functionalities such as VT switch.
>
> Solve this by "prefaulting" user pages on GEM object creation, testing
> whether all pages are eligible for get_user_pages() in the process.
> On failure, return -EFAULT so that userspace can fallback to software
> bliting.
>
> This behavior can be controlled by using a new modparam
> "gem_userptr_prefault", which is true by default.
>
> The only known use for this patch is Qubes OS's GUI virtualization.
> Userspace is expected to resort to DMA-BUF whenever possible.
>
> Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
Thanks for the path. I've tried this one on 5.10.5, and it needs a
> If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
> returned only when the object is actually bound.
>
> The xf86-video-intel userspace driver cannot differentiate this
> condition, and marks the GPU as wedged. This disables graphics
> acceleration and may cripple other functionalities such as VT switch.
>
> Solve this by "prefaulting" user pages on GEM object creation, testing
> whether all pages are eligible for get_user_pages() in the process.
> On failure, return -EFAULT so that userspace can fallback to software
> bliting.
>
> This behavior can be controlled by using a new modparam
> "gem_userptr_prefault", which is true by default.
>
> The only known use for this patch is Qubes OS's GUI virtualization.
> Userspace is expected to resort to DMA-BUF whenever possible.
>
> Signed-off-by: Jinoh Kang <jinoh....@gmail.com>
couple fixes to build, see below.
But then, it seems to fix the issue with VT switch and disabling
acceleration.
Independently, starting with 5.9.x (without the patch) the system freezes
with specific monitor configuration (two monitors side by side, but one
scaled x1.5). It happens immediately after configuring the second
display (and I still got the message about it in Xorg.0.log). Not
setting scaling on the monitor workarounds the issue.
Switching to modesetting driver fixes it. This issue wasn't here on
5.8.x or earlier and looks to be unrelated to this patch. I'm not sure
whether it's purely kernel driver issue, or some kernel<->Xorg
incompatibility.
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 36 +++++++++++++++++++++
> drivers/gpu/drm/i915/i915_params.c | 3 ++
> drivers/gpu/drm/i915/i915_params.h | 1 +
> 3 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index f2eaed6aca3d..65596d2b284f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -712,6 +712,34 @@ static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
> .release = i915_gem_userptr_release,
> };
>
> +static int i915_gem_userptr_prefault(unsigned long start,
> + unsigned long nr_pages,
> + bool readonly)
> +{
> + struct mm_struct *mm = current->mm;
> + unsigned int gup_flags = (readonly ? 0 : FOLL_WRITE) | FOLL_NOWAIT;
> + int err = 0;
> +
> + down_read(&mm->mmap_sem);
> + while (nr_pages) {
> + long ret;
> +
> + ret = get_user_pages(start, nr_pages, gup_flags, NULL, NULL);
> + if (ret < 0) {
> + err = (int)ret;
> + break;
> + }
> + if (ret == 0)
> + ret = 1; /* skip this page */
> +
> + start += ret << PAGE_SHIFT;
> + nr_pages -= ret;
> + }
> + up_read(&mm->mmap_sem);
> param(bool, enable_dp_mst, true, 0600) \
> param(bool, enable_gvt, false, 0400)
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl/7fkwACgkQ24/THMrX
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yyJ+Qf+Kp1NqR/RruBKW3pKbNEZy2Y92viOcKkMcOq96fjLEn/boRevpQHjBpjQ
bdBa5wZasgk0aHV6UTGB1GrLMQupbupMcI2kffmJnvo0/uleRdad1QgPqlcWhO+x
Y0CtPioefWLEwBNITIJGr1emtyM/pO7NpVkFJt3jjei7DfG/jFEkmD36oKb/ea+P
GVmug75CpJKPpmYZT39RzqfoI6ZwCq7Lq70I+/kjQBNiyo2N5/xTKiBkt7NDkQas
lmrtBXAQRn0UGps7SU2tfsdkU/vYJWohNGK7NzLTSN4jyBsH8CBTyJ0x6DxTvYox
W9BPiiLAjBSYJ6jeZ4x8Ly89s0rw8Q==
=EF0b
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jan 11, 2021, 6:03:17 PM1/11/21
to Jinoh Kang, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Thu, Dec 24, 2020 at 02:21:22AM +0000, Jinoh Kang wrote:
> When using some Intel integrated graphic cards on Qubes R4.0, screen
> glitches may manifest after switching VTs or entering suspend mode.
>
> A known workaround does exist for this bug, which is to add a
> configuration file with the following contents within
> /etc/X11/xorg.conf.d:
>
> > Section "Device"
> > Identifier "Intel Graphics"
> > Driver "modesetting"
> > Option "AccelMethod" "glamor"
> > Option "DRI" "3"
> > EndSection
>
> However, the X11 modesetting driver version in Fedora 25 has its own
> drawbacks:
>
> * It freezes briefly when re-configuring monitors (e.g. plugging in an
> external monitor or changing screen resolution)
> * XRandR keystone support is buggy
>
> To remediate this, I've patched the Linux i915 driver and it has been
> working fine for months. Only the patch for Linux 4.19 has been tested.
>
> If anyone is affected by the issue, please feel free to test the
> follow-up patches and give some feedback here.
So, I can confirm the (fixed) 5.10 patch also improves the situation.
> When using some Intel integrated graphic cards on Qubes R4.0, screen
> glitches may manifest after switching VTs or entering suspend mode.
>
> A known workaround does exist for this bug, which is to add a
> configuration file with the following contents within
> /etc/X11/xorg.conf.d:
>
> > Section "Device"
> > Identifier "Intel Graphics"
> > Driver "modesetting"
> > Option "AccelMethod" "glamor"
> > Option "DRI" "3"
> > EndSection
>
> However, the X11 modesetting driver version in Fedora 25 has its own
> drawbacks:
>
> * It freezes briefly when re-configuring monitors (e.g. plugging in an
> external monitor or changing screen resolution)
> * XRandR keystone support is buggy
>
> To remediate this, I've patched the Linux i915 driver and it has been
> working fine for months. Only the patch for Linux 4.19 has been tested.
>
> If anyone is affected by the issue, please feel free to test the
> follow-up patches and give some feedback here.
Have you sent it upstream? I do consider including it in our standard
kernel package, but I'd like to see i915 driver maintainer opinion
first.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yz/XQf9GbeTq3KJpoO/smK7tLJ+EE8Q61G+nejAm5d7VZ+IBofLjWxds2cEn4kJ
xjEpjXxiqTL40cBRa1NkXoLLW7Dcesb/G/7MW+73qYm2DjVYyDQFAQOmnJDXT30L
Vdai3tXb1miTQ6gAme/Zaffe6RLsLzp1Qrq1ieEpQIjJk+tBSWRVTKyNKQAZDkt3
siznMtbre3te7XybIbShUpgXoiwCqpnjZwEmMJg93nFAre5K6XukIksZg+w3Nt1T
/INdhTR6DebTGLtn+pkV9PTGFDRLL+bmWQGallNI2tQnttWogolH9BfEKhkZq+Ja
KUIDySAOIjDhj1UfaGM6m73oIcRc9A==
=TSr5
-----END PGP SIGNATURE-----
Jinoh Kang
Jan 13, 2021, 8:23:25 AM1/13/21
to Marek Marczykowski-Górecki, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 1/11/21 11:03 PM, Marek Marczykowski-Górecki wrote:
> So, I can confirm the (fixed) 5.10 patch also improves the situation.
Sounds good. Thanks for testing!
> So, I can confirm the (fixed) 5.10 patch also improves the situation.
> Have you sent it upstream?
posted this.
I guess chances of these patches being merged upstream would not be
that great.
After all, we're not going to need it with Qubes R4.1.
> I do consider including it in our standard
> kernel package, but I'd like to see i915 driver maintainer opinion
> first.
Tested-by: and/or Reviewed-by: lines for the trailer from you.
I'm fine as well if you'd rather just submit it yourself.
Otherwise I suppose I shall only CC' the maintainers and not the list?
Cheers,
Jinoh Kang
-----BEGIN PGP SIGNATURE-----
iQJMBAEBCAA2FiEEzGktrvc/U3kFXd9AGlqQRGyEq/UFAl/+860YHGppbm9oLmth
bmcua3JAZ21haWwuY29tAAoJEBpakERshKv1WEMQAMKzWpjyis08x3Ph8VVYVhbY
I+GjDaU29Y9xF5lJ8lSvJn1mWUwEiLMyz2ypW4xQE7Z5fC1TgDuz2VS2Bju5SSWv
m1gpsxT3rkydn3Cgr9gl8wmL/HgRltz3HB/zd3aoivqKBK7EUY/McDOqGo/Ntat6
1WogjRZwSQgy5X1oXee7Sn+Uo3Sz6sG/+aszT+oaS4hgrKccp6ImeJtDfH8axJKQ
Ud7BCNZTPHKaX7hw5YYA4IdSebceLWzzIL+Znz5M8g3Rf8Sqn6kuVPu/Q84NESBi
m5RxcZ0AFNINiQLlGDubys36vqPlPcUoitCDAa7sYC7LtKtuuuvaQb9wG7IS/OpG
XsiiLxGwSQ3mOzw2izfz42FjycNjIZ0nMBpFibqzg6aanWP2DWWJlo2L/AtxKUb1
463lJKEomBreAmO0YK3RQUkz6hZ12iOdCfay53X7T2tCNfgC4c7NgpEHhICiBwVL
DQpq1khCswyh+zb/boC/FQr3kp3kDQvtWAf5QTrZ24uM+SK1pd9IqRULuewuz/+r
+c4q9NSlMR8GxK7pXWxpowtWM/54ByeLMayXNYAIISkshN1cHRyIFDQ6OJ2ke7hr
rkRR8DdeR2M3ncZUJ5aWzVERlThzk2oJNIp41dTa2X6nh0A0XFfYLbLAnl6psf7f
/QjQTzjzVsSie06PTwzT
=SeI1
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jan 13, 2021, 10:25:39 AM1/13/21
to Jinoh Kang, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Wed, Jan 13, 2021 at 01:21:51PM +0000, Jinoh Kang wrote:
> On 1/11/21 11:03 PM, Marek Marczykowski-Górecki wrote:
> > So, I can confirm the (fixed) 5.10 patch also improves the situation.
>
> Sounds good. Thanks for testing!
>
> > Have you sent it upstream?
>
> No, qubes-users and qubes-devel are the only mailing list where I
> posted this.
>
> I guess chances of these patches being merged upstream would not be
> that great.
If that bug indeed affects only Qubes OS, there is a greater chance to
> On 1/11/21 11:03 PM, Marek Marczykowski-Górecki wrote:
> > So, I can confirm the (fixed) 5.10 patch also improves the situation.
>
> Sounds good. Thanks for testing!
>
> > Have you sent it upstream?
>
> No, qubes-users and qubes-devel are the only mailing list where I
> posted this.
>
> I guess chances of these patches being merged upstream would not be
> that great.
accept the patch, if the option defaults to false.
> After all, we're not going to need it with Qubes R4.1.
may be necessary. On the other hand, your patch description suggests
it's just any VM-mapped window triggers the faulty path in the
xf86-video-intel driver, that later affects all of the output.
> > I do consider including it in our standard
> > kernel package, but I'd like to see i915 driver maintainer opinion
> > first.
>
> If you mean you'd prefer to have it upstreamed, I'd appreciate some
> Tested-by: and/or Reviewed-by: lines for the trailer from you.
(5.11-rc3, or recent 5.10)? I'll re-test and add my Tested-by:.
> I'm fine as well if you'd rather just submit it yourself.
>
> Otherwise I suppose I shall only CC' the maintainers and not the list?
lists, which do include some mailing lists. I highly recommend using
scripts/get_maintainer.pl script for that purpose (if you use git
send-email, that's as easy as --cc-cmd=scripts/get_maintainer.pl).
PS The other (independent) issue I mentioned seems to be
https://bugzilla.suse.com/show_bug.cgi?id=1180543, which is supposed to
be already fixed in >=5.10.6. I've already uploaded 5.10.7, but haven't
tested it on this particular machine yet.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yxXWgf8DkpeBlpx3kQgXn+FFPsQGpLLkX9O3arm4WEcU71y02J0wmOml8XUj1oZ
4y3p6Wmk1KT8nC74SgG4igkCqcb7ay1m1L0D8AjrY8o4CaaJmErnd0kxYXJMfrnN
T2js+Hlh/kax0y7iphCCpX1IGH1QSPHThDKuMs/40blvKMIDLmymkq8BtoduVEwQ
nZzquV2vRZSFYgl79xWtnxr0QF8yzisIwbYgeEgl256G+ivtmhqLlej6eCUZe6FH
U6j7UwalfXTjWVTnUdtuvmt2rgsV8jZ69eUBJuqqBPfkt3XqMGxNKkAd0hFTBGoZ
f9XtU34qHMwk1vxZCddjsJYi/EPERg==
=teyW
-----END PGP SIGNATURE-----
Jinoh Kang
Jan 15, 2021, 11:14:47 AM1/15/21
to Marek Marczykowski-Górecki, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 1/13/21 3:25 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 13, 2021 at 01:21:51PM +0000, Jinoh Kang wrote:
>> On 1/11/21 11:03 PM, Marek Marczykowski-Górecki wrote:
>>> So, I can confirm the (fixed) 5.10 patch also improves the situation.
>
>> Sounds good. Thanks for testing!
>
>>> Have you sent it upstream?
>
>> No, qubes-users and qubes-devel are the only mailing list where I
>> posted this.
>
>> I guess chances of these patches being merged upstream would not be
>> that great.
>
> If that bug indeed affects only Qubes OS, there is a greater chance to
> accept the patch, if the option defaults to false.
>
>> After all, we're not going to need it with Qubes R4.1.
>
> Are you sure?
Now that I think about it, I just realised that we are still going to
> On Wed, Jan 13, 2021 at 01:21:51PM +0000, Jinoh Kang wrote:
>> On 1/11/21 11:03 PM, Marek Marczykowski-Górecki wrote:
>>> So, I can confirm the (fixed) 5.10 patch also improves the situation.
>
>> Sounds good. Thanks for testing!
>
>>> Have you sent it upstream?
>
>> No, qubes-users and qubes-devel are the only mailing list where I
>> posted this.
>
>> I guess chances of these patches being merged upstream would not be
>> that great.
>
> If that bug indeed affects only Qubes OS, there is a greater chance to
> accept the patch, if the option defaults to false.
>
>> After all, we're not going to need it with Qubes R4.1.
>
> Are you sure?
this patch in Qubes R4.1, while migrating old VMs still using MFNDUMP.
But then, Fedora has moved away from xf86-video-intel to modesetting, so
we aren't going to need this patch either way (unless we are going to
switch to Wayland tomorrow)?
I believe everything else has been covered in qubes-issues#5909 [1].
> The issue affects dom0 windows, which suggests it still
> may be necessary.
> On the other hand, your patch description suggests
> it's just any VM-mapped window triggers the faulty path in the
> xf86-video-intel driver, that later affects all of the output.
>
>>> I do consider including it in our standard
>>> kernel package, but I'd like to see i915 driver maintainer opinion
>>> first.
>
>> If you mean you'd prefer to have it upstreamed, I'd appreciate some
>> Tested-by: and/or Reviewed-by: lines for the trailer from you.
>
> Can you send a fixed patch (that builds), rebased on top of recent Linux
> (5.11-rc3, or recent 5.10)? I'll re-test and add my Tested-by:.
>
>> I'm fine as well if you'd rather just submit it yourself.
>
>> Otherwise I suppose I shall only CC' the maintainers and not the list?
>
> Generally, Linux patches should be sent to whoever MAINTAINERS file
> lists, which do include some mailing lists. I highly recommend using
> scripts/get_maintainer.pl script for that purpose (if you use git
> send-email, that's as easy as --cc-cmd=scripts/get_maintainer.pl).
first stage my changes in my local IMAP daemon's mbox and bounce it via
Thunderbird. This is admittedly very annoying, and perhaps I should
tinker with (neo)mutt + gmail-oauth2-tools some time. Or maybe switch
to a "real" mail account. This will also explain my past embedded PGP
signing mistake. Sorry about that...;(
>
> PS The other (independent) issue I mentioned seems to be
> https://bugzilla.suse.com/show_bug.cgi?id=1180543, which is supposed to
> be already fixed in >=5.10.6. I've already uploaded 5.10.7, but haven't
> tested it on this particular machine yet.
- --
[1] https://github.com/QubesOS/qubes-issues/issues/5909
- --
Sincerely,
Jinoh Kang
-----BEGIN PGP SIGNATURE-----
iQJMBAEBCAA2FiEEzGktrvc/U3kFXd9AGlqQRGyEq/UFAmABvzEYHGppbm9oLmth
-----BEGIN PGP SIGNATURE-----
bmcua3JAZ21haWwuY29tAAoJEBpakERshKv1MIcQAI3TZ5Lp1kfIxEW9EasMgLQH
lKu+YH/ca5iWkoMGn3/uJKvKF2gEkuJp0u85nAu+ns7DWrBjggJnZ+A0y/uZtAFN
FcFQy4OMdURRwPVUTwAOr5WJkkpm04PEhNLZJrgD+8crb/fTYiwu5Ii3XO7egFPd
PQB71cxS4rzWoi+Dz8WVrhn1/wIg/jqL15//iXYM44NXLs8355lWI/QT5/L0dfn1
7g4vPJkbpeMUdjCo5xGyDDc59VUyyzauCPskRW7+G0y6JagzFi8wOI4b6kkoABau
YUgsC/CPGu+JKYPqbtROmA6M5+Mp8McA3oX2DbyIeYfTK58qd32/+bLI0Q6PY14r
8MGXzLFvN8kBA+e9mGCxX2SdX4sb6bYwlAaUs64B37Eo7ybugapUz6GUpL1U64+o
yyQIVoSZ1Hd4zA8KXMP0uocBuH1zrePU0EJ6nlp33X5HPOJXyPdMIFk+CJmPR6yk
3yDmGnQeXxOA+j8uXhH4yOF+zcwyE3+BDOsTKhsVxr99A24TYW92pVUXhN2KTkZQ
3dIYZfaYH2TySA67Z3n9bQ7aoyxe00Q8UcGuO87bFU8vGzUeRGlwyfMYKUzd6Nuz
E+w9g8DYfYfT7HXP1TfzMgAoF9hJfMLN3IQb56BBsIU2je5/A1HgF5kRcmulVKU4
CHThsvFTdVjydLZPuPuR
=8295
-----END PGP SIGNATURE-----
Jinoh Kang
Jan 15, 2021, 12:30:07 PM1/15/21
to Marek Marczykowski-Górecki, qubes-users, qubes-devel, donoban, Patrik Hagara
Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
--
Sincerely,
Jinoh Kang
--
Sincerely,
Jinoh Kang
Marek Marczykowski-Górecki
Jan 15, 2021, 3:06:50 PM1/15/21
to Jinoh Kang, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Fri, Jan 15, 2021 at 05:29:43PM +0000, Jinoh Kang wrote:
> Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
Something like this. In fact the current (Fedora) package is already
> Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
built from git snapshot.
We do backport this package from newer Fedora already:
https://github.com/QubesOS/qubes-linux-dom0-updates
But I would prefer to get it upstream anyway (and then possibly build
xorg-x11-drv-intel from newer git snapshot).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yxNRgf7B2nc2Qomgnqi2/lwiUmv0Mqx7e54cl2zQNtQl57TsVuDu+mWEbef15Ry
gtSBg9c8uXuDq8acbGTP5sqRAJmKlCtWyDdGf5jiZEWATCpZXcVyao/9b8pkuDkY
PZSaTEQU+GekWzSrbuoxHJj4HlrPGRxR4CrGGtaqCyqTzJ3V8rV39jbhG5+hxpdF
HBS0XBxZUHd1Lzxl0l/qbXkyiMSTJvuJ0a6Hl7rvPCbmNbaIAhXru4zM6ZCVTxC9
W00+hUyirnqz0lfXEhBUD2w42rwfO6Hs67yn8Te2/u9QnE9XxFKSVaRVZqfH6EUw
zrh+5BaGaAt4TeyiPxb9FdBdo8/wqQ==
=iNFz
-----END PGP SIGNATURE-----
Jinoh Kang
Jan 15, 2021, 8:49:50 PM1/15/21
to Marek Marczykowski-Górecki, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 1/15/21 8:06 PM, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 15, 2021 at 05:29:43PM +0000, Jinoh Kang wrote:
>> Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
>
> Something like this. In fact the current (Fedora) package is already
> built from git snapshot.
Here's the catch: Fedora hasn't been bumping gitdate for almost a year,
> On Fri, Jan 15, 2021 at 05:29:43PM +0000, Jinoh Kang wrote:
>> Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
>
> Something like this. In fact the current (Fedora) package is already
> built from git snapshot.
as seen in Pagure [1].
> We do backport this package from newer Fedora already:
> https://github.com/QubesOS/qubes-linux-dom0-updates
>
> But I would prefer to get it upstream anyway (and then possibly build
> xorg-x11-drv-intel from newer git snapshot).
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 6a35067c..8a7af809 100644
- --- a/src/sna/kgem.c
+++ b/src/sna/kgem.c
@@ -7023,6 +7023,8 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
struct kgem_bo *bo;
uintptr_t first_page, last_page;
uint32_t handle;
+ struct drm_i915_gem_set_domain set_domain;
+ bool move_to_gtt = false;
assert(MAP(ptr) == ptr);
@@ -7043,20 +7045,10 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
read_only);
if (handle == 0) {
if (read_only && kgem->has_wc_mmap) {
- - struct drm_i915_gem_set_domain set_domain;
- -
handle = gem_userptr(kgem->fd,
(void *)first_page, last_page-first_page,
false);
- -
- - VG_CLEAR(set_domain);
- - set_domain.handle = handle;
- - set_domain.read_domains = I915_GEM_DOMAIN_GTT;
- - set_domain.write_domain = 0;
- - if (do_ioctl(kgem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain)) {
- - gem_close(kgem->fd, handle);
- - handle = 0;
- - }
+ move_to_gtt = true;
}
if (handle == 0) {
DBG(("%s: import failed, errno=%d\n", __FUNCTION__, errno));
@@ -7064,6 +7056,21 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
}
}
+ VG_CLEAR(set_domain);
+ set_domain.handle = handle;
+ if (move_to_gtt) {
+ set_domain.read_domains = I915_GEM_DOMAIN_GTT;
+ set_domain.write_domain = 0;
+ } else {
+ set_domain.read_domains = I915_GEM_DOMAIN_CPU;
+ set_domain.write_domain = I915_GEM_DOMAIN_CPU;
+ }
+ if (do_ioctl(kgem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain)) {
+ gem_close(kgem->fd, handle);
+ DBG(("%s: set_domain in import failed, errno=%d\n", __FUNCTION__, errno));
+ return NULL;
+ }
+
bo = __kgem_bo_alloc(handle, (last_page - first_page) / PAGE_SIZE);
if (bo == NULL) {
gem_close(kgem->fd, handle);
- ---
[1] https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/master/f/xorg-x11-drv-intel.spec#_3
- --
Sincerely,
Jinoh Kang
-----BEGIN PGP SIGNATURE-----
bmcua3JAZ21haWwuY29tAAoJEBpakERshKv1rUcP/iymJetru96CXG3m0PTDLH37
fUenxVbuSc6J9xjPCzV7p39QBziQ2LBaIA6uL4csp7scaw+AHqKqQhxSSFb7Z4x0
zyiax7UyYuH5yGx6+Jn9E5Bf/sWarWw5fq3v61vgTs/0VUQs7tm3zKCj3uhyR4rG
pdhQEaFtqKFZVB26qNBiUsDwv1hibi0dqVvy+LHgXQqhsR39pCSBzrYFwLgf+7C8
9uD+Kbl1/CVmq+bQR9eYmRUQlkibmzzwGgtGrfHUT3dwYrGM+Q3VgsVHr9lOWQa5
F+AET7KkGLqq/iq81BWvJOOKBwPEpczp4TK1DBbI60RR/xIwShHMBxsTxRbvITIw
3ezYdRj7ArROA7XBkLw2LZo09jctG2BqO8USmWdif2wah82LLJrUmswTEWWE3R1Z
lxVnQKEA8LgNc+RICMr3bfN8+MxMErMs4rByF+Od7UUye8u/TjJvTMITvDpnskLW
L9kRrzCL5CZQoklyysvbIgyIwdb+n4OsIUhZ2guMGPly7rksmKOhfXmqFMCCMQCm
EXMDJ7mYQqVN+ajDKOWyQVUlMX9IsD37QtMLhGAA7+uvQJVGGUWiXeF+fgdtiE2v
wBC+EwuEFCnUV1Ich9T9+dBiXB3BX9gKkWJa9+YPLfw0yEwHziiBSMF10V7V/A4k
or2d3f2JMHUnVT4yJBES
=Edlh
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jan 15, 2021, 8:53:45 PM1/15/21
to Jinoh Kang, qubes-users, qubes-devel, donoban, Patrik Hagara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sat, Jan 16, 2021 at 01:49:25AM +0000, Jinoh Kang wrote:
> On 1/15/21 8:06 PM, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 15, 2021 at 05:29:43PM +0000, Jinoh Kang wrote:
> >> Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
> >
> > Something like this. In fact the current (Fedora) package is already
> > built from git snapshot.
>
> Here's the catch: Fedora hasn't been bumping gitdate for almost a year,
> as seen in Pagure [1].
>
> > We do backport this package from newer Fedora already:
> > https://github.com/QubesOS/qubes-linux-dom0-updates
>
> That one from Fedora 28 is a bit behind, too.
>
> >
> > But I would prefer to get it upstream anyway (and then possibly build
> > xorg-x11-drv-intel from newer git snapshot).
>
> Something like this? (haven't built it yet, will fix later)
I guess, yes.
> On 1/15/21 8:06 PM, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 15, 2021 at 05:29:43PM +0000, Jinoh Kang wrote:
> >> Is qubes-xorg-x11-drv-intel an option? Upstream hasn't released for years after all...
> >
> > Something like this. In fact the current (Fedora) package is already
> > built from git snapshot.
>
> Here's the catch: Fedora hasn't been bumping gitdate for almost a year,
> as seen in Pagure [1].
>
> > We do backport this package from newer Fedora already:
> > https://github.com/QubesOS/qubes-linux-dom0-updates
>
> That one from Fedora 28 is a bit behind, too.
>
> >
> > But I would prefer to get it upstream anyway (and then possibly build
> > xorg-x11-drv-intel from newer git snapshot).
>
> Something like this? (haven't built it yet, will fix later)
> diff --git a/src/sna/kgem.c b/src/sna/kgem.c
> index 6a35067c..8a7af809 100644
> --- a/src/sna/kgem.c
> +++ b/src/sna/kgem.c
> @@ -7023,6 +7023,8 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
> struct kgem_bo *bo;
> uintptr_t first_page, last_page;
> uint32_t handle;
> + struct drm_i915_gem_set_domain set_domain;
> + bool move_to_gtt = false;
>
> assert(MAP(ptr) == ptr);
>
> @@ -7043,20 +7045,10 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
> read_only);
> if (handle == 0) {
> if (read_only && kgem->has_wc_mmap) {
> - struct drm_i915_gem_set_domain set_domain;
> +++ b/src/sna/kgem.c
> @@ -7023,6 +7023,8 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
> struct kgem_bo *bo;
> uintptr_t first_page, last_page;
> uint32_t handle;
> + struct drm_i915_gem_set_domain set_domain;
> + bool move_to_gtt = false;
>
> assert(MAP(ptr) == ptr);
>
> @@ -7043,20 +7045,10 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
> read_only);
> if (handle == 0) {
> if (read_only && kgem->has_wc_mmap) {
> -
> handle = gem_userptr(kgem->fd,
> (void *)first_page, last_page-first_page,
> false);
> -
> - VG_CLEAR(set_domain);
> handle = gem_userptr(kgem->fd,
> (void *)first_page, last_page-first_page,
> false);
> -
> - set_domain.handle = handle;
> - set_domain.read_domains = I915_GEM_DOMAIN_GTT;
> - set_domain.write_domain = 0;
> - if (do_ioctl(kgem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain)) {
> - gem_close(kgem->fd, handle);
> - if (do_ioctl(kgem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain)) {
> - handle = 0;
> - }
> - }
> + move_to_gtt = true;
> }
> if (handle == 0) {
> DBG(("%s: import failed, errno=%d\n", __FUNCTION__, errno));
> @@ -7064,6 +7056,21 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
> }
> }
>
> + VG_CLEAR(set_domain);
> + set_domain.handle = handle;
> + if (move_to_gtt) {
> + set_domain.read_domains = I915_GEM_DOMAIN_GTT;
> + set_domain.write_domain = 0;
> + } else {
> + set_domain.read_domains = I915_GEM_DOMAIN_CPU;
> + set_domain.write_domain = I915_GEM_DOMAIN_CPU;
> + }
> + if (do_ioctl(kgem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain)) {
> + gem_close(kgem->fd, handle);
> + DBG(("%s: set_domain in import failed, errno=%d\n", __FUNCTION__, errno));
> + return NULL;
> + }
> +
> bo = __kgem_bo_alloc(handle, (last_page - first_page) / PAGE_SIZE);
> if (bo == NULL) {
> gem_close(kgem->fd, handle);
>
> }
> if (handle == 0) {
> DBG(("%s: import failed, errno=%d\n", __FUNCTION__, errno));
> @@ -7064,6 +7056,21 @@ struct kgem_bo *kgem_create_map(struct kgem *kgem,
> }
> }
>
> + VG_CLEAR(set_domain);
> + set_domain.handle = handle;
> + if (move_to_gtt) {
> + set_domain.read_domains = I915_GEM_DOMAIN_GTT;
> + set_domain.write_domain = 0;
> + } else {
> + set_domain.read_domains = I915_GEM_DOMAIN_CPU;
> + set_domain.write_domain = I915_GEM_DOMAIN_CPU;
> + }
> + if (do_ioctl(kgem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain)) {
> + gem_close(kgem->fd, handle);
> + DBG(("%s: set_domain in import failed, errno=%d\n", __FUNCTION__, errno));
> + return NULL;
> + }
> +
> bo = __kgem_bo_alloc(handle, (last_page - first_page) / PAGE_SIZE);
> if (bo == NULL) {
> gem_close(kgem->fd, handle);
>
> ---
>
> [1] https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/master/f/xorg-x11-drv-intel.spec#_3
>
- --
>
> [1] https://src.fedoraproject.org/rpms/xorg-x11-drv-intel/blob/master/f/xorg-x11-drv-intel.spec#_3
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmACRyEACgkQ24/THMrX
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1ywP6wgAlKaJitGmJHIgzkCpdGqEh3XjoqS2QOyIvsnzkn98v9E/cWrIrCMgrYAC
U2IIYx4e9vrqAW1JwyNLii7ws5/+yI1Y2H7r7In237hedWQ7rCWJRs0UYsAGrtJx
p/rNlxDhDBDWc2IWyZHE21bdEb1eKhl2W3EUzxsUGJ7ZxVDX8J8EgKS3PvZGLdC2
JdT2rcsy9ZWZ8YEmwm7k9GxHmuFMbAXJzgIVv3NxVWBQ4IJeNOfJrHrW1RFUMoyC
BtdkHNUzBtsMLNlGczRMMPE3LdL6n9E8KnXX6RqXgudsDibdm8ixAagas5E6Cvxq
zPgbcftI5MvpDHYdb4QZsCF6kFVxbQ==
=R/oj
-----END PGP SIGNATURE-----
Jinoh Kang
Jan 27, 2021, 7:02:43 PM1/27/21
to donoban, qubes...@googlegroups.com
To try it, just enable the current-testing repo and upgrade
xorg-x11-drv-intel to at least v2.99.917-49.20210126.
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xorg-x11-drv-intel
Discussion: https://github.com/QubesOS/qubes-issues/issues/6356#issuecomment-765952048
>
> Regards.
>
--
Sincerely,
Jinoh Kang
donoban
Jan 28, 2021, 2:57:58 PM1/28/21
to qubes...@googlegroups.com
On 1/28/21 1:02 AM, Jinoh Kang wrote:
> No, but this patch has been superseded by the latest intel xorg driver.
> To try it, just enable the current-testing repo and upgrade
> xorg-x11-drv-intel to at least v2.99.917-49.20210126.
>
> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xorg-x11-drv-intel
>
> Discussion: https://github.com/QubesOS/qubes-issues/issues/6356#issuecomment-765952048
>
Hi,
> No, but this patch has been superseded by the latest intel xorg driver.
> To try it, just enable the current-testing repo and upgrade
> xorg-x11-drv-intel to at least v2.99.917-49.20210126.
>
> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xorg-x11-drv-intel
>
> Discussion: https://github.com/QubesOS/qubes-issues/issues/6356#issuecomment-765952048
>
It seems that I had it already installed with standard dom0 updates.
Since I was on doubt, I started running 5.4.91 and I felt some
strange visual effects compared to 5.4.83 which I was using
previously. Also I had a crash when waking up from suspend (I did not
have one in months or maybe never on this laptop). After the crash I did
three or four suspend/resume cycles without problems.
Today I am testing 5.10.8 and it seems working smooth, better than
5.4.83. Sadly I tried to suspend/resume before sending this email and it
crashed. Then I did it again 4 o 5 five times without problems.
There are some kernel warnings that maybe help. First does not seem
related with graphics, it only appears on 5.10.x versions and I think
that there are one per each processor:
https://share.riseup.net/#100I-6k6jsi4spX0BhGkzA
The other appears both on 5.4/5.10 with pretty different call trace:
https://share.riseup.net/#X55SR3mgJPqOndr8Be_IQQ
Regards.
Jinoh Kang
Jan 29, 2021, 10:36:33 AM1/29/21
to donoban, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 1/28/21 7:57 PM, donoban wrote:
> On 1/28/21 1:02 AM, Jinoh Kang wrote:
>> No, but this patch has been superseded by the latest intel xorg driver.
>> To try it, just enable the current-testing repo and upgrade
>> xorg-x11-drv-intel to at least v2.99.917-49.20210126.
>>
>> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xorg-x11-drv-intel
>>
>> Discussion: https://github.com/QubesOS/qubes-issues/issues/6356#issuecomment-765952048
>>
>
> Hi,
>
> It seems that I had it already installed with standard dom0 updates.
>
> Since I was on doubt, I started running 5.4.91 and I felt some
> strange visual effects compared to 5.4.83 which I was using
> previously.
FWIW this patch only fixes the issue related to the "failed to submit
> On 1/28/21 1:02 AM, Jinoh Kang wrote:
>> No, but this patch has been superseded by the latest intel xorg driver.
>> To try it, just enable the current-testing repo and upgrade
>> xorg-x11-drv-intel to at least v2.99.917-49.20210126.
>>
>> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xorg-x11-drv-intel
>>
>> Discussion: https://github.com/QubesOS/qubes-issues/issues/6356#issuecomment-765952048
>>
>
> Hi,
>
> It seems that I had it already installed with standard dom0 updates.
>
> Since I was on doubt, I started running 5.4.91 and I felt some
> strange visual effects compared to 5.4.83 which I was using
> previously.
rendering commands (Bad address)" message and nothing more.
If the issue starts to manifest without such message in the Xorg server
log, then it is highly likely to be platform-specific.
> Also I had a crash when waking up from suspend (I did not
> have one in months or maybe never on this laptop). After the crash I did
> three or four suspend/resume cycles without problems.
If not, can you post it there?
>
> Today I am testing 5.10.8 and it seems working smooth, better than
> 5.4.83. Sadly I tried to suspend/resume before sending this email and it
> crashed. Then I did it again 4 o 5 five times without problems.
CONFIG_EFI_VARS_PSTORE enabled. If you don't already have one, you may
build qubes-linux-kernel via qubes-builder with the following line
added to `config-qubes`:
CONFIG_EFI_VARS_PSTORE=y
After booting the kernel, subsequent panic and oops will be recorded
in EFI variables, which will then appear as /sys/fs/pstore/dmesg-efi-*
at the next boot. Also note that the logs may be split into multiple
parts that are numbered in a reversed order. For more information, see
https://www.kernel.org/doc/html/latest/admin-guide/pstore-blk.html
>
> There are some kernel warnings that maybe help. First does not seem
> related with graphics, it only appears on 5.10.x versions and I think
> that there are one per each processor:
> https://share.riseup.net/#100I-6k6jsi4spX0BhGkzA
>
> The other appears both on 5.4/5.10 with pretty different call trace:
> https://share.riseup.net/#X55SR3mgJPqOndr8Be_IQQ
>
> Regards.
>
- --
Sincerely,
Jinoh Kang
-----BEGIN PGP SIGNATURE-----
iQJMBAEBCAA2FiEEzGktrvc/U3kFXd9AGlqQRGyEq/UFAmAUKyMYHGppbm9oLmth
- --
Sincerely,
Jinoh Kang
-----BEGIN PGP SIGNATURE-----
bmcua3JAZ21haWwuY29tAAoJEBpakERshKv1UoUP/3ySXnKaoRBrctvFPMgsKX37
/tNf2P8Py0iGJs0fvvau1GQ/oTsIacu4VWZbf0ysvwOt9mGhL86wXh2Vb2AbgItK
zxY50pGIngFUIq7Qm36WyHACUSiWW4IJOGKIKp+Lzu6kX24Z22Z54G5Sf0w1YcGt
KRAFZkNmtMt1FAjBpuWM4R88Ps/hxw0h7alGfJId/XUwzRd8yBye0fiKsn+LwtzQ
dQFXr39hj0ife9xYQp3/MuorXniyMJFCTRd83BN4r+k9Eubdir5ZqqkbtfaoqGmZ
knbMxeii/6qTQ6HWLAI7YdbIH4s02/v9K5cx6skcHENmFfGeqX9Do17yLSGjvL69
qAIHC4u2M52GGD3gAjPWoHmr4Kd0ExniYdonyrMELrcacONpNhWOwOeMDlcWP3ix
3nXs0ynyxBK+RHlV++9RMYsCOLOfy7WY/KFb1V5qBvM4DgN2gia4NRMNOQojHbGv
7uj9EPg30yotSSzAB5Z861qPFQGPQZEYN4QiWMuSfyzvQ21RXR34CTCB7ApBNmbE
HxsY2lyG+7liViMvGrwDEY6mIbvayaFCi1Q0Kyh8D3/+Y26af9zZ9oMFUDpCd9HY
84hQ2ZbAJxebyNp5MxplWDA6KR/aKV9t6uMIS4LVRK2s13yfW5lyL5nW86xyz0aK
5b4n/wUkC57CXBV1Cs1h
=JU95
-----END PGP SIGNATURE-----
donoban
Jan 30, 2021, 7:07:53 AM1/30/21
to qubes...@googlegroups.com
On 1/29/21 4:35 PM, Jinoh Kang wrote:
> FWIW this patch only fixes the issue related to the "failed to submit
> rendering commands (Bad address)" message and nothing more.
>
> If the issue starts to manifest without such message in the Xorg server
> log, then it is highly likely to be platform-specific.
I am not really sure if experimented that problem before the patch.
> FWIW this patch only fixes the issue related to the "failed to submit
> rendering commands (Bad address)" message and nothing more.
>
> If the issue starts to manifest without such message in the Xorg server
> log, then it is highly likely to be platform-specific.
>> Also I had a crash when waking up from suspend (I did not
>> have one in months or maybe never on this laptop). After the crash I did
>> three or four suspend/resume cycles without problems.
>
> This is a news to me. Has this issue been submitted to the tracker?
> If not, can you post it there?
will wait when I have some reliable way for reproducing and some useful log.
>> Today I am testing 5.10.8 and it seems working smooth, better than
>> 5.4.83. Sadly I tried to suspend/resume before sending this email and it
>> crashed. Then I did it again 4 o 5 five times without problems.
>
> You can collect panic and oops logs with a kernel that has
> CONFIG_EFI_VARS_PSTORE enabled. If you don't already have one, you may
> build qubes-linux-kernel via qubes-builder with the following line
> added to `config-qubes`:
>
> CONFIG_EFI_VARS_PSTORE=y
>
> After booting the kernel, subsequent panic and oops will be recorded
> in EFI variables, which will then appear as /sys/fs/pstore/dmesg-efi-*
> at the next boot. Also note that the logs may be split into multiple
> parts that are numbered in a reversed order. For more information, see
> https://www.kernel.org/doc/html/latest/admin-guide/pstore-blk.html
>
I am running 5.4.91 (which I guess that has it disabled) and I can see
an empty '/sys/fs/pstore/' directory.
I will try to run the latest kernel again and look for when a crash occurs.
donoban
Jan 31, 2021, 5:28:49 AM1/31/21
to qubes...@googlegroups.com
On 1/29/21 4:35 PM, Jinoh Kang wrote:
> You can collect panic and oops logs with a kernel that has
> CONFIG_EFI_VARS_PSTORE enabled. If you don't already have one, you may
> build qubes-linux-kernel via qubes-builder with the following line
> added to `config-qubes`:
>
> CONFIG_EFI_VARS_PSTORE=y
>
> After booting the kernel, subsequent panic and oops will be recorded
> in EFI variables, which will then appear as /sys/fs/pstore/dmesg-efi-*
> at the next boot. Also note that the logs may be split into multiple
> parts that are numbered in a reversed order. For more information, see
> https://www.kernel.org/doc/html/latest/admin-guide/pstore-blk.html
Hi, after booting again 5.10.8 kernel (with 5.10.11 I can't start any VM
> CONFIG_EFI_VARS_PSTORE enabled. If you don't already have one, you may
> build qubes-linux-kernel via qubes-builder with the following line
> added to `config-qubes`:
>
> CONFIG_EFI_VARS_PSTORE=y
>
> After booting the kernel, subsequent panic and oops will be recorded
> in EFI variables, which will then appear as /sys/fs/pstore/dmesg-efi-*
> at the next boot. Also note that the logs may be split into multiple
> parts that are numbered in a reversed order. For more information, see
> https://www.kernel.org/doc/html/latest/admin-guide/pstore-blk.html
but I think Marek is already aware) I can see the dmesg-efi "files".
Here is the concatenation of all files (probably in reverse or wrong order):
blob:https://share.riseup.net/3360675c-292f-4114-a109-c410e2518295
Jinoh Kang
Jan 31, 2021, 8:56:49 PM1/31/21
to donoban, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
- --
Sincerely,
Jinoh Kang
-----BEGIN PGP SIGNATURE-----
bmcua3JAZ21haWwuY29tAAoJEBpakERshKv17/cQAJT4RXGKz/Ag8fTsmPA7/ha0
cN31JpPBHuKHV2+jq/Yf7lAKMnufNnAjw8tq7lC/JYISnElmZgppQtSH1nRepqZZ
r67ZPY9L4cP3uWIVqd5usVDK6MvfEv6JWVCA0cEzI9fW0VIjwYRX800XYnw5ae5N
PSF5T3DphIH8hwpBNcD9VswJYn9CJsrwlsdRDLudKmRpRqCFTIPqx319kApZvIK9
FrILahkLH70wibcu/74gYz8rOi1+cmn1B682HGpgkbxah5VdgoJ5vsb3ubbtXmL7
V7RsgDiueQSc2WnlZR+Jvh3nOKKKSGeAvzV0Wx7J3NxwqDbEHVSTn9sd3S5tjz2O
hdQ4ck7gA5RcDDoGqBwA5vsV4Okk8/6heTskl52aW4YTFmziuwAivyceDQa4Qs6/
cIQXhHa8YHd1DdALRx4JmUeef1t3uGEeYp0nT+fLYHDAlbOJd/2/rXQvy/0JMR28
xAP6kj8wOwErJKhVci1kW5tPjoO3qio2yBO2klQ5bQ8cCIYeI0LeJsuFDIbm8kB3
xUpHcxcCirm3ReQ2uR2PfIgXVqNqUye478iAbGsTSe7tOCXPJODbMhXNHNZe+zKP
opWyNN6RVr4IvMx3PCoo4VE1paky+h+n7r79T8lAiAAFKCwEMCk+0SA9sWDpG/R7
SNmQAkqW6Hb1eRfO9XYk
=XlUF
-----END PGP SIGNATURE-----
donoban
Feb 1, 2021, 4:37:55 AM2/1/21
to qubes...@googlegroups.com
On 2/1/21 2:56 AM, Jinoh Kang wrote:>> Here is the concatenation of all
'View in Browser'). But it seems that the blob url points to something
local in memory after decrypting conent from the main url.
Here I pasted again: https://share.riseup.net/#FsOrmx0lsWG4vZdcZi8ROg
files (probably in reverse or wrong order):
>> blob:https://share.riseup.net/3360675c-292f-4114-a109-c410e2518295
>
> That's a wrong URL (blob:). Maybe copy it again?
Ouch, I felt that it was more readable in raw format (if you click on
>> blob:https://share.riseup.net/3360675c-292f-4114-a109-c410e2518295
>
> That's a wrong URL (blob:). Maybe copy it again?
'View in Browser'). But it seems that the blob url points to something
local in memory after decrypting conent from the main url.
Here I pasted again: https://share.riseup.net/#FsOrmx0lsWG4vZdcZi8ROg
haaber
Feb 7, 2021, 1:57:07 PM2/7/21
to qubes...@googlegroups.com, jinoh....@gmail.com, donoban
>
> No, but this patch has been superseded by the latest intel xorg driver.
> To try it, just enable the current-testing repo and upgrade
> xorg-x11-drv-intel to at least v2.99.917-49.20210126.
>
> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade xorg-x11-drv-intel
>
> Discussion: https://github.com/QubesOS/qubes-issues/issues/6356#issuecomment-765952048
if it is linked. It happens almost sure in any video-conf, often while
browsing. And 5x day ...
Thank you!
Feb 07 11:06:45 dom0 kernel: ------------[ cut here ]------------
Feb 07 11:06:45 dom0 kernel: i915 0000:00:02.0: drm_WARN_ON((val & (1 <<
30)) ==
0)
Feb 07 11:06:45 dom0 kernel: WARNING: CPU: 3 PID: 3538 at
/home/user/rpmbuild/BU
ILD/kernel-latest-5.10.13/linux-5.10.13/drivers/gpu/drm/i915/display/intel_cdclk
.c:850 skl_get_cdclk+0x22b/0x2
Feb 07 11:06:45 dom0 kernel: Modules linked in: binfmt_misc loop
ebtable_filter
ebtables ip6table_filter ip6_tables iptable_filter vfat fat
snd_hda_codec_hdmi s
nd_soc_skl snd_soc_sst_ipc snd
Feb 07 11:06:45 dom0 kernel: xen_acpi_processor xenfs ip_tables
dm_thin_pool dm
_persistent_data dm_bio_prison dm_crypt hid_multitouch rtsx_pci_sdmmc
mmc_core c
rct10dif_pclmul crc32_pclmul c
Feb 07 11:06:45 dom0 kernel: CPU: 3 PID: 3538 Comm: Xorg Tainted: G
W
5.10.13-1.fc25.qubes.x86_64 #1
Feb 07 11:06:45 dom0 kernel: Hardware name: Dell Inc. Latitude
7390/09386V, BIOS
1.5.1 07/12/2018
Feb 07 11:06:45 dom0 kernel: RIP: e030:skl_get_cdclk+0x22b/0x2b0 [i915]
Feb 07 11:06:45 dom0 kernel: Code: 8b 6f 50 4d 85 ed 0f 84 88 00 00 00
e8 3e 57
56 c1 48 c7 c1 08 ac 3d c0 4c 89 ea 48 89 c6 48 c7 c7 a5 2b 40 c0 e8 e5
70 e0 c0
<0f> 0b 8b 53 04 e9 11 fe ff
Feb 07 11:06:45 dom0 kernel: RSP: e02b:ffffc90001ebb9e0 EFLAGS: 00010286
Feb 07 11:06:45 dom0 kernel: RAX: 0000000000000000 RBX: ffffc90001ebba0c
RCX: 00
00000000000027
Feb 07 11:06:45 dom0 kernel: RDX: 0000000000000000 RSI: ffff888135cd8a80
RDI: ffff888135cd8a88
Feb 07 11:06:45 dom0 kernel: RBP: ffff888107ca0000 R08: 0000000000000003
R09: 0000000000000001
Feb 07 11:06:45 dom0 kernel: R10: 0000000000000000 R11: ffffc90001ebb7d8
R12: ffff888107ca0808
Feb 07 11:06:45 dom0 kernel: R13: ffff888100da3350 R14: 0000000000000000
R15: ffff888107ca0000
Feb 07 11:06:45 dom0 kernel: FS: 000078d3e66a9a40(0000)
GS:ffff888135cc0000(0000) knlGS:0000000000000000
Feb 07 11:06:45 dom0 kernel: CS: e030 DS: 0000 ES: 0000 CR0:
0000000080050033
Feb 07 11:06:45 dom0 kernel: CR2: 00007e6aae2db518 CR3: 000000012049e000
CR4: 0000000000050660
Feb 07 11:06:45 dom0 kernel: Call Trace:
Feb 07 11:06:45 dom0 kernel: gen9_disable_dc_states+0x67/0x260 [i915]
Feb 07 11:06:45 dom0 kernel: intel_power_well_enable+0x3e/0x50 [i915]
Feb 07 11:06:45 dom0 kernel:
__intel_display_power_get_domain.part.24+0x6f/0x90 [i915]
Feb 07 11:06:45 dom0 kernel: intel_display_power_get+0x49/0x60 [i915]
Feb 07 11:06:45 dom0 kernel: __gt_unpark+0x2c/0x70 [i915]
Feb 07 11:06:45 dom0 kernel: __intel_wakeref_get_first+0x3b/0x80 [i915]
Feb 07 11:06:45 dom0 kernel: i915_gem_do_execbuffer+0x170a/0x1e80 [i915]
Feb 07 11:06:45 dom0 kernel: ? unix_stream_read_generic+0x97e/0xa00
Feb 07 11:06:45 dom0 kernel: ? kmem_cache_free+0x2bd/0x2e0
Feb 07 11:06:45 dom0 kernel: ? unix_stream_read_generic+0x97e/0xa00
Feb 07 11:06:45 dom0 kernel: ? kmem_cache_free+0x2bd/0x2e0
Feb 07 11:06:45 dom0 kernel: i915_gem_execbuffer2_ioctl+0xea/0x200 [i915]
Feb 07 11:06:45 dom0 kernel: ? i915_gem_execbuffer_ioctl+0x2d0/0x2d0 [i915]
Feb 07 11:06:45 dom0 kernel: drm_ioctl_kernel+0xb6/0x100 [drm]
Feb 07 11:06:45 dom0 kernel: drm_ioctl+0x329/0x3b0 [drm]
Feb 07 11:06:45 dom0 kernel: ? i915_gem_execbuffer_ioctl+0x2d0/0x2d0 [i915]
Feb 07 11:06:45 dom0 kernel: __x64_sys_ioctl+0x8e/0xd0
Feb 07 11:06:45 dom0 kernel: ? syscall_trace_enter.isra.18+0x163/0x1b0
Feb 07 11:06:45 dom0 kernel: do_syscall_64+0x33/0x40
Feb 07 11:06:45 dom0 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Feb 07 11:06:45 dom0 kernel: RIP: 0033:0x78d3e3d3d6a7
Feb 07 11:06:45 dom0 kernel: Code: 00 00 00 48 8b 05 e1 27 2c 00 64 c7
00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8
10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3
Feb 07 11:06:45 dom0 kernel: RSP: 002b:00007fff95e584a8 EFLAGS: 00000246
ORIG_RAX: 0000000000000010
Feb 07 11:06:45 dom0 kernel: RAX: ffffffffffffffda RBX: 000000000000000e
RCX: 000078d3e3d3d6a7
Feb 07 11:06:45 dom0 kernel: RDX: 00007fff95e584e0 RSI: 0000000040406469
RDI: 000000000000000e
Feb 07 11:06:45 dom0 kernel: RBP: 00007fff95e584e0 R08: 000000000000000c
R09: 000078d3e6770020
Feb 07 11:06:45 dom0 kernel: R10: 0000000000003fd0 R11: 0000000000000246
R12: 000078d3dd779000
Feb 07 11:06:45 dom0 kernel: R13: 0000000000001000 R14: 00007fff95e584e0
R15: 00000000021b9730
Feb 07 11:06:45 dom0 kernel: ---[ end trace 528bf252a0c1a39e ]---
Reply all
Reply to author
Forward
0 new messages