January 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1180917] kernel BUG at mm/huge_memory.c:2144!
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180917 https://bugzilla.suse.com/show_bug.cgi?id=1180917#c9 --- Comment #9 from LTC BugProxy <bugproxy(a)us.ibm.com> --- ------- Comment From geraldsc(a)de.ibm.com 2021-01-19 09:45 EDT------- (In reply to comment #13) [...] > > Is there any other means of kernel source access for openSUSE Tumbleweed, > > ideally a git repo like for SLES? Seems hard to believe that "open"SUSE > > kernel source is harder to find / access than SLES code... > > It is not hard to find at all. All you need to know is, that the different > flavors of kernels all depend on a central package called kernel-source, > which has an own mechanics to integrate patches depending on a variety of > conditions. The source can be found in the package > http://download.opensuse.org/ports/zsystems/tumbleweed/repo/oss/noarch/ > kernel-source-5.10.5-1.1.noarch.rpm Hmm, almost right, you also need to know that the kernel-source.noarch.rpm does not contain the full source, and that you need the kernel-devel.noarch.rpm on top (e.g. for arch code). This is the same for SLES, so fortunately I knew it, but of course for SLES it is much less annoying because you also have a proper public git for both kernel source tree and also kernel-source src.rpm content, so you don't really need to bother about knowing which rpms contain what... Anyway, back to the bug, from the kernel source for 5.10.5-1-default I see that it happens on the BUG_ON(!pte_none(*pte)) in __split_huge_pmd_locked(). This is very strange / interesting, because those are the ptes from the pre-allocated and deposited pagetable, which was withdrawn just shortly before that BUG_ON, with pgtable_trans_huge_withdraw(). The pre-allocated pagetables are initialized with empty (invalid) ptes before deposit, so they should of course all (still) be pte_none() after withdrawal. If a pte is !pte_none, then this means that either the pre-allocated pagetable got corrupted while it was deposited, or maybe that pgtable_trans_huge_withdraw() returns something that is not really a pagetable at all. E.g. in theory it could return NULL, if there were more withdrawals than deposits, IIUC the list handling code there correctly. Of course, such a thing should never happen (i.e. it would be a bug), but I am a bit confused why the common code does not also check this with a BUG_ON check. Having a system dump could help to see more of what was going on. Any chance that kdump generated a dump after the BUG_ON? From the backtrace and register output, and a kernel disassembly, one can at least see that in %r1 we have the pte value that did not pass the !pte_none check: 00000000b2b40215. This actually looks like a valid pte, with present / young / read / write-protect set, so one could assume that this is not the "NULL returnend" case, but rather really a pre-allocated pagetable, which somehow got corrupted by someone having it in active access and filling it with valid ptes. Of course, such a thing should also never happen, the pre-allocated and deposited pagetables can not be used until they are withdrawn, very strange. We do actually have an own implementation of the deposit/withdraw functions, because we cannot use the generic versions. On s390, we have 2K pagetables, and two of them within one 4K page, so we cannot use the generic logic that operates on struct pages for (4K) pagetable pages. The pgtable_t is therefore also not a struct page on s390, but rather a direct pointer to the pagetable. For maintainig the list of pre-allocatced pagetables, we put a list_head directly into the pageteables, at the beginning, instead of using page->lru of the struct page associated with the pagetable like it is donr in the generic case. Then, on withdraw, and after list_del, the first two ptes will be cleared so that the list_head gets overwritten and the whole pagetable should be empty again. That is at least suspicious, and it could could explain why you only see this on s390 (do you really?). However, I do not really see how our implementation would change anything that allows the deposited pagetables to change before withdrawing them. It is really the same logic as in generic code, only that we put the list_head somewhere else. I still suspect some race in common code, e.g. some concurrent withdrawals w/o proper locking, but I could not yet find anything suspicious in the code... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180928] New: Drop CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE from kernel 5.10+
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180928 Bug ID: 1180928 Summary: Drop CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE from kernel 5.10+ Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- With kernel 5.10, there is a new option CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE which should be disabled to drop support of outdated cipher pieces. The only known user would have been iwd/ell which are new enough already to not require it anymore thanks to the following commits: * https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=1db8a85a… * https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2 * https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1181111] New: Dynamic Debugging (dyndbg) query at boot fails on module acpi_cpufreq
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1181111 Bug ID: 1181111 Summary: Dynamic Debugging (dyndbg) query at boot fails on module acpi_cpufreq 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: giovanni.gherdovich(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 845262 --> http://bugzilla.opensuse.org/attachment.cgi?id=845262&action=edit "acpi_cpufreq.dyndbg= file drivers/cpufreq/acpi-cpufreq.c +mpf" (dmesg | grep dyndbg) The following dyndbg query, added to the kernel command line (kernel version v5.11-rc3) doesn't produce the expected debugging logs: "acpi_cpufreq.dyndbg= file drivers/cpufreq/acpi-cpufreq.c +mpf" The following output shows that the query is partially understood, but it's been noted that it should not say "acpi_cpufreq_exit =_", but rather "acpi_cpufreq_exit =mpf" # cat /sys/kernel/debug/dynamic_debug/control | grep acpi-cpufreq drivers/cpufreq/acpi-cpufreq.c:980 [acpi_cpufreq]acpi_cpufreq_exit =_ "%s\012" drivers/cpufreq/acpi-cpufreq.c:959 [acpi_cpufreq]acpi_cpufreq_init =_ "CPB unsupported, do not expose it\012" drivers/cpufreq/acpi-cpufreq.c:943 [acpi_cpufreq]acpi_cpufreq_init =_ "%s\012" drivers/cpufreq/acpi-cpufreq.c:906 [acpi_cpufreq]acpi_cpufreq_boost_init =_ "Boost capabilities not present in the processor\012" drivers/cpufreq/acpi-cpufreq.c:870 [acpi_cpufreq]acpi_cpufreq_resume =_ "%s\012" drivers/cpufreq/acpi-cpufreq.c:845 [acpi_cpufreq]acpi_cpufreq_cpu_exit =_ "%s\012" drivers/cpufreq/acpi-cpufreq.c:817 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ " %cP%d: %d MHz, %d mW, %d uS\012" drivers/cpufreq/acpi-cpufreq.c:811 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "CPU%u - ACPI performance management activated.\012" drivers/cpufreq/acpi-cpufreq.c:748 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "Unknown addr space %d\012" drivers/cpufreq/acpi-cpufreq.c:731 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "HARDWARE addr space\012" drivers/cpufreq/acpi-cpufreq.c:725 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "SYSTEM IO addr space\012" drivers/cpufreq/acpi-cpufreq.c:721 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "AMD K8 systems must use native drivers.\012" drivers/cpufreq/acpi-cpufreq.c:707 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "No P-States\012" drivers/cpufreq/acpi-cpufreq.c:645 [acpi_cpufreq]acpi_cpufreq_cpu_init =_ "%s\012" drivers/cpufreq/acpi-cpufreq.c:565 [acpi_cpufreq]acpi_cpufreq_early_init =_ "Memory allocation error for acpi_perf_data.\012" drivers/cpufreq/acpi-cpufreq.c:561 [acpi_cpufreq]acpi_cpufreq_early_init =_ "%s\012" drivers/cpufreq/acpi-cpufreq.c:447 [acpi_cpufreq]acpi_cpufreq_target =_ "%s (%d)\012" drivers/cpufreq/acpi-cpufreq.c:430 [acpi_cpufreq]acpi_cpufreq_target =_ "Already at target state (P%d)\012" drivers/cpufreq/acpi-cpufreq.c:426 [acpi_cpufreq]acpi_cpufreq_target =_ "Called after resume, resetting to P%d\012" drivers/cpufreq/acpi-cpufreq.c:387 [acpi_cpufreq]get_cur_freq_on_cpu =_ "cur freq = %u\012" drivers/cpufreq/acpi-cpufreq.c:367 [acpi_cpufreq]get_cur_freq_on_cpu =_ "%s (%d)\012" drivers/cpufreq/acpi-cpufreq.c:355 [acpi_cpufreq]get_cur_val =_ "%s = %u\012" drivers/cpufreq/acpi-cpufreq.c:134 [acpi_cpufreq]set_boost =_ "CPU %*pbl: Core Boosting %sabled.\012" A snippet of the boot log using dynamic_debug.verbose=2 is attached. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1181104] Unplugging TeVII DVB-S2 USB adapter crashes kernel
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1181104 https://bugzilla.suse.com/show_bug.cgi?id=1181104#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- The Oops itself looks like the NULL dereference at dvb_usb_device_exit(), and it's the part: if (d != NULL && d->desc != NULL) { strscpy(name, d->desc->name, sizeof(name)); So adding the NULL check of d->desc->name should paper over it, e.g. if (d != NULL && d->desc != NULL && d->desc->name != NULL) { strscpy(name, d->desc->name, sizeof(name)); (It's better to rewrite the if condition without "!= NULL", though.) However, this doesn't explain why d->desc->name can be NULL. My wild guess is that this is use-after-free, the properties object got already released at disconnection, but this needs to be checked by the upstream. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180711] External monitor DEAD after logging in - works in console / SDDM since updating to 20210106
by bugzilla_noreply＠suse.com 18 Jan '21

18 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180711 https://bugzilla.suse.com/show_bug.cgi?id=1180711#c9 --- Comment #9 from robert spitzenpfeil <rs.opensuse(a)spitzenpfeil.org> --- Let's close it. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1181026] New: Cannot boot any kernel version starting from 5.10...
by bugzilla_noreply＠suse.com 18 Jan '21

18 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1181026 Bug ID: 1181026 Summary: Cannot boot any kernel version starting from 5.10... Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: hehe_br-opensuse(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 845210 --> http://bugzilla.opensuse.org/attachment.cgi?id=845210&action=edit lspci I cannot boot any kernel version starting from 5.10... Problem started with the kernel update from Tumbleweed 20201223. All later updates are of no help. System does not boot with the workaround suggested https://bugzilla.opensuse.org/show_bug.cgi?id=1180344. It also does not leave log messages in journalctl even in recovery mode. Running fine with: Linux version 5.9.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 10.2.1 20201117 [revision 98ba03ffe0b9f37b4916ce6238fad754e00d720b], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.35.1.20201112-1) #1 SMP Mon Nov 23 09:08:45 UTC 2020 (b7c3768) BOOT_IMAGE=/boot/vmlinuz-5.9.10-1-default root=UUID=n resume=/dev/disk/by-uuid/n splash=silent quiet showopts amdgpu.si_support=1 radeon.si_support=0 acpi_backlight=amdgpu_bl0 tumbleweed installed: 20210107 kernel-default-5.10.4-1.1.x86_64 kernel-default-5.10.3-1.2.x86_64 kernel-default-5.9.10-1.1.x86_64 ASUS X550IU, BIOS X550IU.308 04/19/2019 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1180742] [amdgpu]An AMD Vega series GPU randomly crashes
by bugzilla_noreply＠suse.com 18 Jan '21

18 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180742 https://bugzilla.suse.com/show_bug.cgi?id=1180742#c3 --- Comment #3 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Iakov Karpov from comment #2) > (In reply to Takashi Iwai from comment #1) > > It's some GPU hang that leads to the real kernel crash.... which happened on > > others sometimes, too. Unfortunately there is no fix for this and likely > > not for Leap 15.2 kernel. > > > > Could you try the kernel in OBS Kernel:stable or SLE15-SP3 kernel in OBS > > Kernel:SLE15-SP3? The latter contains the backport of DRM stack up to 5.9.x. > > kernel 5.3.18-100.g3524980 of Kernel:SLES15-SP3 won't boot on this machine > (stuck right after bootloader, not even a single line after "loading initrd" > on screen. That's bad. Do you have the secure boot enabled? If so, disable it when you test a kernel from OBS repo that is other than the official release. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180711] External monitor DEAD after logging in - works in console / SDDM since updating to 20210106
by bugzilla_noreply＠suse.com 18 Jan '21

18 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180711 https://bugzilla.suse.com/show_bug.cgi?id=1180711#c8 --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- So, does everything work now as expected? Or do you see any issues to be fixed now? If not, let's close the bug. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180591] Display backlight stuck at 100%
by bugzilla_noreply＠suse.com 18 Jan '21

18 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180591 https://bugzilla.suse.com/show_bug.cgi?id=1180591#c15 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(maurizio.galli@gm | |ail.com) | --- Comment #15 from Takashi Iwai <tiwai(a)suse.com> --- Thanks. I checked briefly between v5.7 and v5.8, but there is no change in either driver/acpi/video_detect.c or drivers/acpi/acpi_video.c. So the ACPI code (in those areas) didn't change, and something else (also in ACPI) must be the cause of the regression. It's hard to tell for now. And, I looked at the backlight support on Apple machines and they are... well... messy. There is apple-gmux driver that supports things on some devices but it's only for ACPI APP000B, which isn't enabled on yours. At this moment, the best thing we can do is to git bisect. But of course it takes time (and patience). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180962] New: Kernel did not see the status numlock from bios.
by bugzilla_noreply＠suse.com 18 Jan '21

18 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180962 Bug ID: 1180962 Summary: Kernel did not see the status numlock from bios. 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: virex(a)mail.ru QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Kernel did not see the status numlock from bios. After several updates I found what the numlock status is off by default. Checking the setting in BIOS. It is on by default With settings KBD_NUMLOCK="bios" in /etc/sysconfig/keyboard it is always off. -- You are receiving this mail because: You are the assignee for the bug.

1 7