November 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1192807] Kernel 5.16 rc1: Unable to suspend: DEAD callback error for CPU1
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192807 https://bugzilla.suse.com/show_bug.cgi?id=1192807#c4 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #4 from Takashi Iwai <tiwai(a)suse.com> --- A known bug of powercap driver, I also hit and debugged yesterday :) An upstream fix is found in linux-next 4d1cd1443db3d5605ebcde8672869b1944ade92d powercap: DTPM: Fix suspend failure and kernel warning The patch was submitted at https://lore.kernel.org/r/20211108062345.273855-1-daniel.lezcano@linaro.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192809] New: [RPi4] tc358743-based HDMI input does not work with kernel-default; works with kernel from raspberry foundation
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1192809 Bug ID: 1192809 Summary: [RPi4] tc358743-based HDMI input does not work with kernel-default; works with kernel from raspberry foundation 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: marmarek(a)mimuw.edu.pl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 853822 --> http://bugzilla.opensuse.org/attachment.cgi?id=853822&action=edit dmesg, opensuse kernel with dtoverlay=tc358743 I've spent quite some time trying to get tc358743 on RPi4 to work with OpenSUSE Tumbleweed. Besides `config.txt` entries (where I hit https://bugzilla.opensuse.org/show_bug.cgi?id=1192047), there needs to be a kernel module. tc358743 itself is present, but I still can't get `/dev/video0`. The best I've got is: ``` [ 19.841631] Registered IR keymap rc-cec [ 19.841804] rc rc2: 10-000f as /devices/platform/soc/fe205000.i2c/i2c-22/i2c-10/10-000f/rc/rc2 [ 19.842070] input: 10-000f as /devices/platform/soc/fe205000.i2c/i2c-22/i2c-10/10-000f/rc/rc2/input2 [ 19.845518] tc358743 10-000f: tc358743 found @ 0x1e (i2c-22-mux (chan_id 1)) ``` with no `start_x=1` but with `dtoverlay=tc358743` in config.txt. But still no /dev/video0 (or any other /dev/video*). I do have `videodev` module loaded. I'm attaching full dmesg and lsmod outputs. This all is with kernel-default-5.14.14-1.1.aarch64. The whole thing _does_ work with a kernel built from raspberry foundation's tree, with the config attached. And with `start_x=1` in config.txt. I'm attaching dmesg and lsmod from this too (rpi-* files). I suspect the issue is some part of the video stack not available yet in the upstream kernel (bcm2835-unicam module specifically), but I was told to report the issue anyway. Some hints to that from the working setup: ``` localhost:/home/pi # ls -l /sys/class/video4linux/video0/device/driver lrwxrwxrwx 1 root root 0 Oct 15 00:00 /sys/class/video4linux/video0/device/driver -> ../../../../bus/platform/drivers/unicam localhost:/home/pi # ls -l /sys/class/video4linux/video0/device/driver/module lrwxrwxrwx 1 root root 0 Nov 18 03:12 /sys/class/video4linux/video0/device/driver/module -> ../../../../module/bcm2835_unicam ``` Some more information is at those two links: https://forums.raspberrypi.com/viewtopic.php?f=38&t=281972 https://www.raspberrypi.com/documentation/accessories/camera.html#camera-se… I've also seen https://en.opensuse.org/HCL:Raspberry_Pi_Camera_Modules but that didn't helped me getting it working with default kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1192758] Kernel Crash for i915 GPU driver
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192758 https://bugzilla.suse.com/show_bug.cgi?id=1192758#c8 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Flags|needinfo?(noslin005(a)gmail.c | |om) | --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- I pushed the fix for merging, so it'll be included likely in the next update, at latest in December. Until then, you can keep my test kernel (and report back if other problem happens with it). Let's close for now. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192758] New: Kernel Crash for i915 GPU driver
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1192758 Bug ID: 1192758 Summary: Kernel Crash for i915 GPU driver Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: noslin005(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 853784 --> http://bugzilla.opensuse.org/attachment.cgi?id=853784&action=edit crash message for i915 driver I notice a frequent kernel crash assotiated with i915 GPU driver on MSI MS-7D16/H510I PRO WIFI (MS-7D16), BIOS 1.30 09/09/2021. [ 2.558990] ------------[ cut here ]------------ [ 2.558990] i915 0000:00:02.0: drm_WARN_ON(enabled_irq_mask & ~interrupt_mask) [ 2.559023] WARNING: CPU: 5 PID: 330 at ../drivers/gpu/drm/i915/i915_irq.c:434 ibx_display_interrupt_update+0xb9/0x110 [i915] [ 2.559023] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec xhci_pci rc_core xhci_hcd drm ahci libahci usbcore libata nvme nvme_core crc32c_intel t10_pi video wmi pinctrl_tigerlake sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod msr efivarfs If I boot with 'nomodeset', the crash does not happen, but I can not get the front audio to work. For more details, refer to the logs uploaded here https://linux-hardware.org/?probe=d50547de1f -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c31 --- Comment #31 from Frank Kr�ger <fkrueger(a)mailbox.org> --- (In reply to Art Hemming from comment #30) > (In reply to Oliver Neukum from comment #28) > > Test kernel abuilding at: > > > > https://build.opensuse.org/project/monitor/home:oneukum:bsc1191795_20211117a > > > > Please test > > This is a dumb question, but are there videos somewhere of how to use the > OBS service to test a kernel for (this and similar) bugs? Or documentation? > > I find myself at present unable to contribute due to a sheer lack of knowing > what to do, for which I apologize. > > Have a lovely day! One possibility is to add https://download.opensuse.org/repositories/home:/oneukum:/bsc1191795_202111… as an additional repo and install the corresponding kernel or use the 1-click-installation via https://software.opensuse.org/ymp/home:oneukum:bsc1191795_20211117a/ARM/ker… (the latter does not work for me). Hope this helps. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c30 --- Comment #30 from Art Hemming <cameron.cn(a)yagowap.com> --- (In reply to Oliver Neukum from comment #28) > Test kernel abuilding at: > > https://build.opensuse.org/project/monitor/home:oneukum:bsc1191795_20211117a > > Please test This is a dumb question, but are there videos somewhere of how to use the OBS service to test a kernel for (this and similar) bugs? Or documentation? I find myself at present unable to contribute due to a sheer lack of knowing what to do, for which I apologize. Have a lovely day! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c29 --- Comment #29 from Frank Kr�ger <fkrueger(a)mailbox.org> --- (In reply to Oliver Neukum from comment #28) > Test kernel abuilding at: > > https://build.opensuse.org/project/monitor/home:oneukum:bsc1191795_20211117a > > Please test Unfortunately, your kernel version does not work for me. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192767] Kernel boot logging gets mixed up when bringing up CPUs on SMP system
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c6 --- Comment #6 from Archie Cobbs <archie.cobbs(a)gmail.com> --- > #1 I understand - you're not the only one who's looking at warning-level > messages - people do care about them. But our booting is already very > fragile so fixing stuff only for the formatting's sake is not worth the > effort and complexity. In an ideal world both bugs would be fixed but practically speaking I agree #1 is both easier to fix and higher priority. So let's start there. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192767] Kernel boot logging gets mixed up when bringing up CPUs on SMP system
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c5 --- Comment #5 from Borislav Petkov <bpetkov(a)suse.com> --- (In reply to Archie Cobbs from comment #4) > #1 Bogus promotion from INFO to WARN That is probably a bug... > #2 Broken formatting if there are any per-CPU log messages ... but I can't call this a bug frankly. > Both bugs should be fixed. For #2 I can see where the problem comes from... > when you have 127 CPU's and there are no warnings emitted, it's nicer to > have them listed all on one or two lines. But of course, you don't want to > stop any per-CPU log messages from being emitted, so if they are emitted, > they get emitted "in the middle" of the single, in-progress log line for > that node. Pretty much. > Given the simplistic way kernel logging works, to give proper formatting > when there is a possibility of any CPU startup emitting a warning AND have > each CPU listed in "real time", you would be forced to log each CPU on its > own line. The reason it was done this way is to save dmesg space. Imagine you had 9K CPUs. Because there are boxes like that. That's 9K lines of dmesg log ring buffer wasted. Or on a slow serial line. 9K seconds only for the cores if it takes a second to issue a line. > Alternatively, if you don't care about "real time" logging (would probably > be a bad idea to give this up) then you could wait until all CPU's are done > to log the results... I don't care if the logging is interleaved by some message during a logical thread's initialization. dmesg message format is not an ABI but a best-effort thing, roughly speaking. #1 I understand - you're not the only one who's looking at warning-level messages - people do care about them. But our booting is already very fragile so fixing stuff only for the formatting's sake is not worth the effort and complexity. HTH. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192767] Kernel boot logging gets mixed up when bringing up CPUs on SMP system
by bugzilla_noreply＠suse.com 17 Nov '21

17 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c4 --- Comment #4 from Archie Cobbs <archie.cobbs(a)gmail.com> --- > The purpose of the "meaningless log messages" is to show the CPU configuration of the machine. Understood - apologies for calling them meaningless. But to be clear there are two bugs here... #1 Bogus promotion from INFO to WARN #2 Broken formatting if there are any per-CPU log messages Both bugs should be fixed. For #2 I can see where the problem comes from... when you have 127 CPU's and there are no warnings emitted, it's nicer to have them listed all on one or two lines. But of course, you don't want to stop any per-CPU log messages from being emitted, so if they are emitted, they get emitted "in the middle" of the single, in-progress log line for that node. Given the simplistic way kernel logging works, to give proper formatting when there is a possibility of any CPU startup emitting a warning AND have each CPU listed in "real time", you would be forced to log each CPU on its own line. For example, that might look like this (if only CPU#3 had a problem): x86: Booting SMP configuration: .... node #0 CPU #1 .... node #0 CPU #2 .... node #0 CPU #3 core: CPUID marked event: 'cpu cycles' unavailable .... node #0 CPU #4 smp: Brought up 1 node, 4 CPUs Alternatively, if you don't care about "real time" logging (would probably be a bad idea to give this up) then you could wait until all CPU's are done to log the results... x86: Booting SMP configuration: .... node #0 CPU #3: core: CPUID marked event: 'cpu cycles' unavailable smp: Brought up 1 node, 4 CPUs This would require some new trickery with the logging infrastructure to allow configuring an thread-local "log prefix" (in this case, the ".... node #0 CPU #3: " part). Right now the code is trying to have it both ways and it's not working... -- You are receiving this mail because: You are the assignee for the bug.

1 0