October 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1177595] many device resets and I/O errors during mdadm scrub
by bugzilla_noreply＠suse.com 15 Oct '20

15 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1177595 https://bugzilla.suse.com/show_bug.cgi?id=1177595#c1 --- Comment #1 from Coly Li <colyli(a)suse.com> --- (In reply to Peter van Hoof from comment #0) > We have a disk server with a Supermicro S3008 L8e SAS controller and 6 SAS > drives of 12 TB each in an mdadm RAID5 software raid configuration. When > starting a scrub of the RAID array with > > echo check > /sys/block/md0/md/sync_action > > after about 0.5 - 1.5 hours of running the scrub, a lot of error messages > start appearing in the syslog. Mostly there are lots of cryptic messages > like this: > > kernel: mpt3sas_cm0: log_info(0x3112011a): originator(PL), code(0x12), > sub_code(0x011a) > > these are interspersed with other error messages about device resets and I/O > errors: > > kernel: sd 6:0:2:0: Power-on or device reset occurred > > kernel: blk_update_request: I/O error, dev sdc, sector 5160938280 op > 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 > kernel: sd 6:0:2:0: [sdc] tag#1073 CDB: Read(10) 28 00 26 73 b5 65 00 00 01 > 00 > kernel: sd 6:0:2:0: [sdc] tag#1073 FAILED Result: hostbyte=DID_SOFT_ERROR > driverbyte=DRIVER_OK > > These errors happen on all 6 disks in the RAID array (only sdc is shown > here, but the problems on the other disks are essentially identical). > > I have also seen I/O errors in the output of smartctl -a (while the scrub > was ongoing), but that may simply be due to the device being reset during > the call... > > Initially we thought these were hardware problems and we had the server > thoroughly checked by the manufacturer. They swapped out all the hardware, > but the problems would not go away. They concluded that it must be a > software (i.e., driver) issue. I cannot be completely certain, but it looks > like the problems started after upgrading openSUSE 15.1 -> 15.2. The kernel > was fully patched at the time we detected the problems on 29 September. Test > showed that the previous installed kernel version also showed the same > problem. It is likely that all kernel versions shipped with openSUSE 15.2 > show this problem. > > We currently mount the RAID5 array in read-only mode to prevent the I/O > errors from corrupting the file system. This severely limits the > functionality of the server. I used to hear of similar issue situation when the hard drive was device-managed SMR. What are the exact models of these hard drives ? Thanks. Coly Li -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1177718] New: systemd[1]: Caught <SEGV>, dumped core as pid
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1177718 Bug ID: 1177718 Summary: systemd[1]: Caught <SEGV>, dumped core as pid Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: novell(a)regproctor.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With all latest updates I got this: Broadcast message from systemd-journald@quark (Wed 2020-10-14 12:57:36 MST): systemd[1]: Caught <SEGV>, dumped core as pid 28687. Broadcast message from systemd-journald@quark (Wed 2020-10-14 12:57:36 MST): systemd[1]: Freezing execution. When trying to shutdown I got this: 0 quark:/home/reg # init 6 Segmentation fault (core dumped) 0 quark:/home/reg # init 0 Segmentation fault (core dumped) 0 quark:/home/reg # I had to power off. KDE disappeared so that all my screens were just black although my apps were still there. My boot loader looks like this: splash=silent resume=/dev/disk/by-uuid/6f7781f5-5caf-4dd9-aa59-00f9ec46136c quiet pci=noaer acpi_enforce_resources=lax amdgpu.si_support=1 radeon.si_support=0 Not that just a few days ago I moved over to amdgpu from radeon which has solved a lot of problems. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[kernel-bugs] [Bug 1177618] External monitor connected via HDMI only works with 640x480 resolution due to invalid EDID detected
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1177618 http://bugzilla.opensuse.org/show_bug.cgi?id=1177618#c11 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #11 from Takashi Iwai <tiwai(a)suse.com> --- It seems that quite a few ASUS monitors are badly detected by amdgpu driver, e.g. the upstream report https://bugzilla.kernel.org/show_bug.cgi?id=201497 My wild guess is that some unstable I2C transfer for DDC, and we might see what data got corrupted when comparing between good and bad read EDID values. But it's definitely device-specific, and hard to debug by others than the hardware owner. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1177695] kernel: parport_pc: `none' invalid for parameter `dma' on openSUSE MicroOS
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1177695 https://bugzilla.suse.com/show_bug.cgi?id=1177695#c2 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #2 from Takashi Iwai <tiwai(a)suse.com> --- It's the expected behavior. After the kernel lockdown, the parameter changes to certain drivers are restricted, and parport is one of them. (Admittedly the message is misleading, though.) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1177618] External monitor connected via HDMI only works with 640x480 resolution due to invalid EDID detected
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1177618 http://bugzilla.opensuse.org/show_bug.cgi?id=1177618#c10 --- Comment #10 from Stefan Dirsch <sndirsch(a)suse.com> --- This is inconsistent. In kernel log it's HDMI-A-1 (there is no HDMI-A-0), but in X log it's vice versa. Anyway, you could try to workaround the issue with kernel command line option video=HDMI-A-1:1920x1080@60e or if this doesn't work this video=HDMI-A-1:1920x1080@60e but well, you already gave up ... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1177618] External monitor connected via HDMI only works with 640x480 resolution due to invalid EDID detected
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1177618 http://bugzilla.opensuse.org/show_bug.cgi?id=1177618#c9 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X.Org |Kernel Assignee|gfx-bugs(a)suse.de |kernel-bugs(a)opensuse.org Summary|External monitor connected |External monitor connected |via HDMI only works with |via HDMI only works with |640x480 resolution |640x480 resolution due to | |invalid EDID detected QA Contact|gfx-bugs(a)suse.de |qa-bugs(a)suse.de Flags|needinfo?(teo8976(a)gmail.com | |) | --- Comment #9 from Stefan Dirsch <sndirsch(a)suse.com> --- Thanks. Xorg.0.log: [...] [ 9.990] (II) AMDGPU(0): EDID for output HDMI-A-0 [ 9.990] (II) AMDGPU(0): Printing probed modes for output HDMI-A-0 [ 9.991] (II) AMDGPU(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) dmesg: [ 4.170779] amdgpu 0000:05:00.0: HDMI-A-1: EDID is invalid: [ 4.170781] [00] BAD 00 ff ff ff ff ff ff 00 04 69 d2 23 52 1d 01 00 [ 4.170782] [00] BAD 18 16 01 03 80 33 1d 78 2a d9 45 a2 55 4d a0 27 [ 4.170782] [00] BAD 00 50 54 b7 ef 00 d1 c0 81 40 81 80 95 00 b3 00 [ 4.170782] [00] BAD 71 4f 81 c0 81 00 02 3a 80 18 71 38 2d 40 58 2c [ 4.170783] [00] BAD 45 00 fd 1e 11 00 00 1e 00 00 00 ff 00 43 36 4c [ 4.170783] [00] BAD 4d 54 46 30 37 33 30 34 32 0a 00 00 00 fd 00 32 [ 4.170783] [00] BAD 4b 18 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc [ 4.170784] [00] BAD 00 41 53 55 53 20 56 53 32 33 39 0a 20 20 01 62 [ 4.170910] [drm:dc_link_detect_helper [amdgpu]] *ERROR* EDID checksum invalid. No wonder, everything falls back to 640x480 resolution. Since this is working with different Kernels and on other operating systems my current guess is, that there exists workarounds for this monitor in different Kernel/OSes. Reassigning to kernel component. Indeed this is a rather new GPU, so things may improve in the future. [ 9.781] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x15d8) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1177695] kernel: parport_pc: `none' invalid for parameter `dma' on openSUSE MicroOS
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1177695 https://bugzilla.suse.com/show_bug.cgi?id=1177695#c1 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt(a)suse.com Component|MicroOS |Kernel Assignee|kubic-bugs(a)opensuse.org |kernel-bugs(a)opensuse.org --- Comment #1 from Fabian Vogt <fvogt(a)suse.com> --- Looks like this is defined in /etc/modprobe.d/00-system.conf, from suse-module-tools. Reassigning. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1177060] New: drm_calc_timestamping_constants error
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1177060 Bug ID: 1177060 Summary: drm_calc_timestamping_constants error 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: therapon(a)netzero.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Dell Precision M4800 laptop nVidia GK107GLM [Quadro K1100M] Nouveau 20.1.8-264.1 driver Once it starts happening, the following line is printed to the journald log: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 50: Can't calculate constants, dotclock = 0! It's a continuous stream as long as the mouse is moving. After just a few hours there are thousands of these lines in the log. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[kernel-bugs] [Bug 1173115] kernel updates lead to showing mok screen on reboot
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1173115 https://bugzilla.suse.com/show_bug.cgi?id=1173115#c52 --- Comment #52 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2020:2917-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1173115 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Module for Basesystem 15-SP2 (src): mokutil-0.4.0-4.3.1 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 1177428] AMDGPU resume fail
by bugzilla_noreply＠suse.com 14 Oct '20

14 Oct '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1177428 http://bugzilla.opensuse.org/show_bug.cgi?id=1177428#c62 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? | --- Comment #62 from Takashi Iwai <tiwai(a)suse.com> --- Cleaning the directory can be dangerous at upgrading, so I'd like to avoid the hackish way. The hardlink was established by fdupes call for the duplicated files, and this seems causing problems. As mentioned in the above, now I changed the call with -s option to use symlink instead of hardlink, and this must work around the pitfall. The fixed package is on its way to TW. So, let's go back to the original issue, the resume failure. If the boot hang still happens with the next update package, please open another bug and track there. Thanks. -- You are receiving this mail because: You are the assignee for the bug.

1 0