November 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1163592] kernel packaging problem: RPM group = %group
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1163592 https://bugzilla.suse.com/show_bug.cgi?id=1163592#c33 --- Comment #33 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-SU-2020:3326-1: An update that solves 7 vulnerabilities, contains one feature and has 47 fixes is now available. Category: security (moderate) Bug References: 1055014,1058115,1061843,1065600,1065729,1066382,1077428,1112178,1114648,1131277,1134760,1157424,1163592,1167030,1170415,1171558,1172538,1173432,1174748,1175520,1175721,1176354,1176485,1176560,1176723,1176907,1176946,1177086,1177101,1177271,1177281,1177410,1177411,1177470,1177719,1177740,1177749,1177750,1177753,1177754,1177755,1177766,1177855,1177856,1177861,1178003,1178027,1178166,1178185,1178187,1178188,1178202,1178234,1178330 CVE References: CVE-2020-0430,CVE-2020-14351,CVE-2020-16120,CVE-2020-25285,CVE-2020-25656,CVE-2020-25705,CVE-2020-8694 JIRA References: SLE-10886 Sources used: SUSE Linux Enterprise Live Patching 12-SP5 (src): kernel-default-4.12.14-122.51.2, kgraft-patch-SLE12-SP5_Update_12-1-8.5.2 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1161867] kernel 5.3.18-lp152.1 : Interrupts enabled after mce_syscore_resume
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1161867 https://bugzilla.suse.com/show_bug.cgi?id=1161867#c10 Miroslav Bene�� <mbenes(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Miroslav Bene�� <mbenes(a)suse.com> --- No response, so let me close as duplicate of bug 1164813, because it really looks the same. *** This bug has been marked as a duplicate of bug 1164813 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1142370] Untested laptop multimedia keys, please report success or failure to eric.piel@tremplin-utc.net
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1142370 https://bugzilla.suse.com/show_bug.cgi?id=1142370#c19 Miroslav Bene�� <mbenes(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NORESPONSE --- Comment #19 from Miroslav Bene�� <mbenes(a)suse.com> --- No response, closing then. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173819] 'BUG: workqueue lockup' on ThunderX2 machines with kernel 4.12.14 in OBS
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1173819 https://bugzilla.suse.com/show_bug.cgi?id=1173819#c6 Miroslav Bene�� <mbenes(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jack(a)suse.com, | |mbenes(a)suse.com --- Comment #6 from Miroslav Bene�� <mbenes(a)suse.com> --- Forgotten... There are earlier bugs in both obs-arm-8 and -9 logs. Somewhere in ext4 code. Workqueue lockups could be just consequences. Adrian pointed that out. Anyway, it was reported against 15.1. Is it still happening on 15.2? CCing Jack, so that he is aware (it may have been reported against SLES as well), but I don't think this is worth pursuing. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1107525] Raise default file descriptor limits to meet Valve Proton requirements
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1107525 https://bugzilla.suse.com/show_bug.cgi?id=1107525#c10 Miroslav Bene�� <mbenes(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Basesystem Assignee|kernel-bugs(a)opensuse.org |screening-team-bugs(a)suse.de Flags|needinfo?(tiwai(a)suse.com) | --- Comment #10 from Miroslav Bene�� <mbenes(a)suse.com> --- I was not talking about workarounds. It is a configuration issue in my opinion. Yes, the defaults may be different, but that is for someone else to decide. Not a kernel issue. I am not sure which component is the correct one, so changing back to Basesystem. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1107525] Raise default file descriptor limits to meet Valve Proton requirements
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1107525 https://bugzilla.suse.com/show_bug.cgi?id=1107525#c9 --- Comment #9 from Daniel Noga <noga.dany(a)gmail.com> --- (In reply to Miroslav Bene�� from comment #8) > What is really the problem here? I took my Leap 15.2 default installation > and "ulimit -Hn" indeed shows 4096 (TW has a much bigger default). It can be > easily changed in systemd configuration files and the github link from the > description even shows how. So I'm wondering... Yes, workaround exists and works for me. But it is not expected to need to read github, when someone want to play some game on Steam. If I need to install some enterprise Oracle or SAP, I expect tunings could be needed before it runs, but not for this. Both upstream and downstream agreed, that higher limit is better. openSUSE Leap is probably the last distribution with low defaults. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1163592] kernel packaging problem: RPM group = %group
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1163592 https://bugzilla.suse.com/show_bug.cgi?id=1163592#c32 --- Comment #32 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-SU-2020:1906-1: An update that solves 7 vulnerabilities and has 65 fixes is now available. Category: security (important) Bug References: 1055014,1055186,1061843,1065600,1065729,1066382,1077428,1129923,1134760,1149032,1152489,1163592,1164648,1166146,1166166,1167030,1170415,1174748,1174969,1175052,1175306,1175749,1175898,1176354,1176485,1176713,1177086,1177281,1177353,1177410,1177411,1177470,1177739,1177749,1177750,1177754,1177755,1177765,1177766,1177799,1177801,1177814,1177817,1177854,1177855,1177856,1177861,1178002,1178079,1178123,1178166,1178173,1178175,1178176,1178177,1178183,1178184,1178185,1178186,1178190,1178191,1178246,1178255,1178307,1178330,1178393,1178395,1178461,1178579,1178581,1178584,1178585 CVE References: CVE-2020-14351,CVE-2020-16120,CVE-2020-25285,CVE-2020-25656,CVE-2020-25668,CVE-2020-25704,CVE-2020-8694 JIRA References: Sources used: openSUSE Leap 15.2 (src): kernel-debug-5.3.18-lp152.50.1, kernel-default-5.3.18-lp152.50.1, kernel-docs-5.3.18-lp152.50.1, kernel-kvmsmall-5.3.18-lp152.50.1, kernel-obs-build-5.3.18-lp152.50.1, kernel-obs-qa-5.3.18-lp152.50.1, kernel-preempt-5.3.18-lp152.50.1, kernel-source-5.3.18-lp152.50.1, kernel-syms-5.3.18-lp152.50.1 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1107525] Raise default file descriptor limits to meet Valve Proton requirements
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1107525 https://bugzilla.suse.com/show_bug.cgi?id=1107525#c8 --- Comment #8 from Miroslav Bene�� <mbenes(a)suse.com> --- What is really the problem here? I took my Leap 15.2 default installation and "ulimit -Hn" indeed shows 4096 (TW has a much bigger default). It can be easily changed in systemd configuration files and the github link from the description even shows how. So I'm wondering... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1172900] Videoconferencing apps on openSUSE --> much higher CPU and heat than Clear Linux
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1172900 Miroslav Bene�� <mbenes(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mbenes(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178762] New: Slow down in OBS since kernel 5.6.0 on 32bit
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1178762 Bug ID: 1178762 Summary: Slow down in OBS since kernel 5.6.0 on 32bit Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jack(a)suse.com QA Contact: qa-bugs(a)suse.de CC: adrian.schroeter(a)suse.com, bpetkov(a)suse.com, dimstar(a)opensuse.org, fvogt(a)suse.com, jack(a)suse.com, jroedel(a)suse.com, jslaby(a)suse.com, kernel-performance-bugs(a)suse.de, ro(a)suse.com, tiwai(a)suse.com Depends on: 1169774 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1169774 +++ We noticed an increase of build time by factor 5 on some OBS workers. Exmaple: # eosc jobhistory openSUSE:Factory installation-images -M openSUSE standard i586 The goat & sheep systems suddenly need 2.5h instead of 0.5h build time for the same package. This is 32bit/i586 only. These systems used to be fine before, it seems the guest kernel update to 5.6.0 did trigger it (time matches). The slowed odwn goat and sheep systems are AMD Epyc 3.01/3.02. While the un-affected lamb systems are AMD Opteron systems. The host systems did stay on openSUSE Leap 15.1. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[kernel-bugs] [Bug 1170696] Dell Latitude 7490 freezes with 15.2
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1170696 https://bugzilla.suse.com/show_bug.cgi?id=1170696#c20 --- Comment #20 from Adrian Schr�ter <adrian.schroeter(a)suse.com> --- after some more googling, can you confirm that this is most likely a long standing issue with intel firmware? Unlikely to get solved? I would request new hardware then... https://linuxreviews.org/Linux_Kernel_5.5_Will_Not_Fix_The_Frequent_Intel_G… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1170696] Dell Latitude 7490 freezes with 15.2
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1170696 https://bugzilla.suse.com/show_bug.cgi?id=1170696#c19 --- Comment #19 from Adrian Schr�ter <adrian.schroeter(a)suse.com> --- it is our official company notebook model for some time after all ... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1170696] Dell Latitude 7490 freezes with 15.2
by bugzilla_noreply＠suse.com 13 Nov '20

13 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1170696 https://bugzilla.suse.com/show_bug.cgi?id=1170696#c18 --- Comment #18 from Adrian Schr�ter <adrian.schroeter(a)suse.com> --- kernel-default-5.10.rc3-1.1.ge72caa5.x86_64 from Kernel:Head project changed the behaviour slightly in the way the crash/freeze happens earlier. I also updated the BIOS firmware to latest version from last month btw. I boot the system in runlevel 3 meanwhile for testing. It is crashing immediatly after initializing the framebuffer now (last line is i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device (typed manually, but checked for typos). Afterwards the crash LED is blinking for a few seconds until it stops and the entire system keeps frozen. I did not found any way yet to get a kernel trace in this situation. Can you suggest any way? The linux kernel 4.x from openSUSE 15.1 is still stable on that 15.2 installation. (except that it seems to have suspend issues with that system and I need to boot first a 5.x kernel after power off, wait for the crash before I boot the 4.x one. Otherwise the wlan has a high chance of not being initialized). I would really appreciate in any help to get my main workstation notebook in a usable state. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c47 --- Comment #47 from Larry Finger <Larry.Finger(a)gmail.com> --- (In reply to Stefan Hundhammer from comment #42) > virtualbox-kmp-default rebuilds the kernel module in its post-install script > (and recreates the initrd with dracut). Is it possible or plausible that in > certain situations it does that with the wrong kernel headers or something > like that? Using the ones of the currently running kernel rather than the > one that is also being installed in the same "zypper dup" run? If you build a kernel module with the wrong headers, the resulting code will simply not load, thus your supposition is wrong! > > Is it plausible that this might be only a missing dependency in the > virtualbox .spec file; or a post-install script being executed at an > inappropriate time, before the complete upgrade process is complete? The VirtualBox modules do not need to be in the initrd as they are not loaded until the file system is up and running. Nonetheless, the install system puts them in initrd. The spec process is rather complicated; however, I think it is doing the right thing otherwise. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1163592] kernel packaging problem: RPM group = %group
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1163592 https://bugzilla.suse.com/show_bug.cgi?id=1163592#c31 --- Comment #31 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-SU-2020:1901-1: An update that solves 7 vulnerabilities and has 44 fixes is now available. Category: security (important) Bug References: 1055014,1058115,1061843,1065600,1065729,1066382,1077428,1112178,1131277,1134760,1163592,1167030,1170415,1171558,1173432,1174748,1176354,1176485,1176560,1176713,1176723,1176907,1177086,1177101,1177271,1177281,1177410,1177411,1177470,1177687,1177719,1177740,1177749,1177750,1177753,1177754,1177755,1177766,1177855,1177856,1177861,1178027,1178123,1178166,1178185,1178187,1178188,1178202,1178234,1178330,936888 CVE References: CVE-2020-0430,CVE-2020-14351,CVE-2020-16120,CVE-2020-25285,CVE-2020-25656,CVE-2020-25668,CVE-2020-8694 JIRA References: Sources used: openSUSE Leap 15.1 (src): kernel-debug-4.12.14-lp151.28.79.1, kernel-default-4.12.14-lp151.28.79.1, kernel-docs-4.12.14-lp151.28.79.2, kernel-kvmsmall-4.12.14-lp151.28.79.1, kernel-obs-build-4.12.14-lp151.28.79.1, kernel-obs-qa-4.12.14-lp151.28.79.1, kernel-source-4.12.14-lp151.28.79.1, kernel-syms-4.12.14-lp151.28.79.1, kernel-vanilla-4.12.14-lp151.28.79.1 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c46 --- Comment #46 from Larry Finger <Larry.Finger(a)gmail.com> --- (In reply to Takashi Iwai from comment #38) > > BTW, no VB package is provided on SLE. I do ensure that the VB packages will build on SLE. Thus if a user wants to install VMs using VB, it would work. They would, of course, blow their warranty. Unfortunately, VB is rather insecure! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c45 --- Comment #45 from Larry Finger <Larry.Finger(a)gmail.com> --- (In reply to Stefan Hundhammer from comment #40) > A complete shot in the dark (and, as noted before, I know nothing about > kernel stuff and how all that works): > > https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/ > fixes_for_5.9.patch?expand=1 I am the author of that patch. All of those changes are needed because the kernel developers changed the API in a number of places in the 5.9 kernel. Without those changes, the modules would not build. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c44 --- Comment #44 from Larry Finger <Larry.Finger(a)gmail.com> --- (In reply to Stefan Hundhammer from comment #42) > virtualbox-kmp-default rebuilds the kernel module in its post-install script > (and recreates the initrd with dracut). Is it possible or plausible that in > certain situations it does that with the wrong kernel headers or something > like that? Using the ones of the currently running kernel rather than the > one that is also being installed in the same "zypper dup" run? If you build a kernel module with the wrong headers, the resulting code will simply not load, thus your supposition is wrong! > > Is it plausible that this might be only a missing dependency in the > virtualbox .spec file; or a post-install script being executed at an > inappropriate time, before the complete upgrade process is complete? The VirtualBox modules do not need to be in the initrd as they are not loaded until the file system is up and running. Nonetheless, the install system puts them in initrd. The spec process is rather complicated; however, I think it is doing the right thing otherwise. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c43 --- Comment #43 from Stefan Hundhammer <shundhammer(a)suse.com> --- The installation / upgrade sequence of those four critical packages was: kernel-default-5.9.1-2.2.x86_64 Do 12 Nov 2020 15:09:09 CET virtualbox-kmp-default-6.1.14_k5.9.1_2-2.8.x86_64 Do 12 Nov 2020 15:09:46 CET virtualbox-guest-x11-6.1.14-2.1.x86_64 Do 12 Nov 2020 15:11:03 CET virtualbox-guest-tools-6.1.14-2.1.x86_64 Do 12 Nov 2020 15:11:04 CET This resulted in a correctly working system. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c42 --- Comment #42 from Stefan Hundhammer <shundhammer(a)suse.com> --- It keeps getting weirder and weirder. I did more experiments with kernel-default locked and doing "zypper dup" for all the rest. I had not realized that this would also install kernel-default-base which zypper installed to resolve the dependencies of virtualbox-kmp. That lead to being restricted to a 640x480 (standard VGA) screen resolution because virtualbox-kmp could not be properly initialized: Nov 12 14:21:12 localhost kernel: vboxvideo: Unknown symbol ttm_bo_mmap (err -2) vboxvideo: Unknown symbol ttm_bo_manager_func (err -2) vboxvideo: Unknown symbol ttm_bo_glob (err -2) vboxvideo: Unknown symbol ttm_bo_device_release (err -2) vboxvideo: Unknown symbol ttm_bo_kunmap (err -2) vboxvideo: Unknown symbol ttm_bo_device_init (err -2) vboxvideo: Unknown symbol ttm_bo_init_mm (err -2) vboxvideo: Unknown symbol ttm_bo_dma_acc_size (err -2) vboxvideo: Unknown symbol ttm_tt_init (err -2) vboxvideo: Unknown symbol ttm_bo_kmap (err -2) vboxvideo: Unknown symbol ttm_bo_init (err -2) vboxvideo: Unknown symbol ttm_bo_validate (err -2) vboxvideo: Unknown symbol ttm_bo_move_to_lru_tail (err -2) vboxvideo: Unknown symbol ttm_bo_put (err -2) vboxvideo: Unknown symbol ttm_tt_fini (err -2) vboxvideo: Unknown symbol ttm_bo_eviction_valuable (err -2) But there was no pixel garbage. Later I unlocked kernel-default, uninstalled kernel-default-base (which also uninstalled the virtualbox-* packages) and then force-reinstalled the new kernel and the virtualbox-* packages: zypper in --force kernel-default virtualbox-guest-x11 virtualbox-guest-tools virtualbox-kmp-default ...and now everything is working again: No pixel garbage, not restricted to 640x480. Somehow I feel this is a bootstrap problem of the involved packages or a binary compatibility problem: Just like previously, upgrading the packages step by step appears to work fine, while upgrading everything at once has weird side effects. virtualbox-kmp-default rebuilds the kernel module in its post-install script (and recreates the initrd with dracut). Is it possible or plausible that in certain situations it does that with the wrong kernel headers or something like that? Using the ones of the currently running kernel rather than the one that is also being installed in the same "zypper dup" run? Is it plausible that this might be only a missing dependency in the virtualbox .spec file; or a post-install script being executed at an inappropriate time, before the complete upgrade process is complete? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c41 --- Comment #41 from Stefan Hundhammer <shundhammer(a)suse.com> --- My last good snapshot (who which I reverted in the meantime) runs with Linux balrog-tw-dev.fritz.box 5.9.1-1-default #1 SMP Mon Oct 26 07:02:23 UTC 2020 (435e92d) x86_64 x86_64 x86_64 GNU/Linux i.e. kernel-default-5.9.1-1.2.x86_64 "zypper dup" would update to kernel-default-5.9.1-2.2.x86_64 . -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c40 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #40 from Stefan Hundhammer <shundhammer(a)suse.com> --- A complete shot in the dark (and, as noted before, I know nothing about kernel stuff and how all that works): https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/fi… Index: VirtualBox-6.1.14/src/VBox/Additions/linux/drm/vbox_ttm.c =================================================================== --- VirtualBox-6.1.14.orig/src/VBox/Additions/linux/drm/vbox_ttm.c +++ VirtualBox-6.1.14/src/VBox/Additions/linux/drm/vbox_ttm.c @@ -445,7 +445,11 @@ err_free_vboxbo: static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo) { +#if RTLNX_VER_MAX(5, 9, 0) return bo->bo.offset; +#else + return bo->offset; +#endif } This affects an offset, and the function name suggests it's related to the GPU. That might be a hint. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c39 --- Comment #39 from Stefan Hundhammer <shundhammer(a)suse.com> --- (In reply to Takashi Iwai from comment #38) > What happened between your comment 11 and comment 12? Another "zypper dup" with more updated packages. > You showed the > problem was introduced (again) there. What packages have been updated > exactly and what action done? Unfortunately, I only have a partial package list of the previous state (see comment #0). For the new state, it's the attachment from comment #13. The attachment from comment #14 contains the output of "rpm -qa --last" which includes timestamps, however: https://bugzilla.opensuse.org/attachment.cgi?id=843466 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

https://bugzilla.suse.com/show_bug.cgi?id=1178360 https://bugzilla.suse.com/show_bug.cgi?id=1178360#c38 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com Flags| |needinfo?(shundhammer@suse. | |com) --- Comment #38 from Takashi Iwai <tiwai(a)suse.com> --- What happened between your comment 11 and comment 12? You showed the problem was introduced (again) there. What packages have been updated exactly and what action done? The information until now doesn't show whether it's a problem in the kernel update itself or the VB module. BTW, no VB package is provided on SLE. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1178360] X11 Pixel Garbage in VirtualBox
by bugzilla_noreply＠suse.com 12 Nov '20

12 Nov '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c37 --- Comment #37 from Stefan Hundhammer <shundhammer(a)suse.com> --- Please look at that screenshot again: https://bugzilla.opensuse.org/attachment.cgi?id=843222 The first green pixel line starts with a black portion. That is exactly how much the rest of the X11 screen is offset to the right. In the vertical dimension, the black part is exactly how much it's offset downwards. When you look at the visible part of the Xfce screenshot utility at the bottom part of that X11 screen, you will see that the screenshot it took inside that VM is correct; there is no pixel garbage, and the icons are lined up correctly at the left top corner. So for the X server inside the VM, everything is alright (AFAICS). It must be somewhere in the communication protocol between the VM guest and the host. -- You are receiving this mail because: You are the assignee for the bug.

1 0