July 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c15 --- Comment #15 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Thomas Blume from comment #14) > (In reply to Fabian Vogt from comment #12) > > - Touch did-setup in the "# no ip option directed at our interface?" case > > after successful do_dhcp > > > > 0b998beebc008f2dda2eed8a36d59f4a258cb27a introduced the code to handle the > > latter, but: > > - It also runs in cases where the do_dhcp in this block wasn't actually run > > (like in this bug report) > > - The $? it checks is meaningless at this point due to the ifs > > Hm, did you check the latest code? > There is: > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > the leasinfo file won't be there if there was no dhcp setup. Yes, but the use of $? there is still wrong AFAICT. > > In the "rd.neednet=1 bootdev=eth0" case it actually runs do_dhcp twice for > > the interface, as both > > "# No ip ..." blocks apply. Maybe those blocks should be merged? > > Those parameters are a bit different, bootdev is documented as: > --> > bootdev=<interface> > specify network interface to use routing and netroot information > from. Required if multiple ip= lines are used. > --< > > So it is bound to the netroot case and a specific interface, whereas > rd.neednet does the network setup unconditionally. That seems to be working with netroot, but not depend on netroot. It doesn't say that bootdev can only be specified if multiple ip= options are set, but only that it is mandatory in that case. > Also, the code for evaluating rd.neednet isn't in ifup.sh but in > net-genrules.sh. > > Considering the duplicate run of do_dhcp, I'd blame this at the missing > check for netroot as outlined above. Not tested, but would that just move the "dhcp twice" case to netroot only? There's nothing which prevents the "# no ip option directed at our interface?" block from running after "# No ip lines default to dhcp" as the former doesn't touch /tmp/net.${netif}.up, does it? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c14 --- Comment #14 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Fabian Vogt from comment #12) > (In reply to Thomas Blume from comment #11) > > Can you please give the dracut package at: > > > > https://build.opensuse.org/package/binaries/home:tsaupe:branches:openSUSE: > > Factory:dracut-bsc1173402/dracut/openSUSE_Factory > > > > a try? > > Works! > > Looking at this again, this is quite the mess... > AFAICT, touching the did-setup file after a successful "do_dhcp" is > generally the right way. > > This is currently not done, which lead to > https://github.com/tblume/dracut/commit/ > 0b998beebc008f2dda2eed8a36d59f4a258cb27a adding another path to create > did-setup. > This new path was broken by > https://github.com/tblume/dracut/commit/ > 28be2f3692d6a641c841f636c03e45c5f3c4ec6b, which you now fixed with > https://github.com/tblume/dracut/commit/ > 487fb167b82c88871e6d1ace21ccdb0a48e9032d. > > What should be done IMO: > > - Touch did-setup in the "# No ip lines default to dhcp" case after > successful do_dhcp The code there really looks wrong: --> if [ -z "$NO_AUTO_DHCP" ] && [ -z "$ip" ]; then if [ "$netroot" = "dhcp6" ]; then do_dhcp -6 else do_dhcp -4 fi --< That runs do_dhcp -4 in any case if there is no ip= line and dhcp isn't explicitly disabled. But that code is apparently for the netroot case, so it needs to be checked whether $netroot is filled. After this, a did-setup is indeed appropriate IMHO. > - Touch did-setup in the "# no ip option directed at our interface?" case > after successful do_dhcp > > 0b998beebc008f2dda2eed8a36d59f4a258cb27a introduced the code to handle the > latter, but: > - It also runs in cases where the do_dhcp in this block wasn't actually run > (like in this bug report) > - The $? it checks is meaningless at this point due to the ifs Hm, did you check the latest code? There is: if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then the leasinfo file won't be there if there was no dhcp setup. > In the "rd.neednet=1 bootdev=eth0" case it actually runs do_dhcp twice for > the interface, as both > "# No ip ..." blocks apply. Maybe those blocks should be merged? Those parameters are a bit different, bootdev is documented as: --> bootdev=<interface> specify network interface to use routing and netroot information from. Required if multiple ip= lines are used. --< So it is bound to the netroot case and a specific interface, whereas rd.neednet does the network setup unconditionally. Also, the code for evaluating rd.neednet isn't in ifup.sh but in net-genrules.sh. Considering the duplicate run of do_dhcp, I'd blame this at the missing check for netroot as outlined above. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174278] kernel-firmware-amdgpu 20200702 breaks video on Picasso
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174278 https://bugzilla.suse.com/show_bug.cgi?id=1174278#c7 --- Comment #7 from Takashi Iwai <tiwai(a)suse.com> --- Thanks! I'm building the updated kernel-firmware package including the revert of amdgpu in OBS home:tiwai:branches:Kernel:HEAD repo. Please give it a try later to confirm that the revert works properly. (Check the rpm changelog before testing; I committed the updated package without the revert at first.) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] Your Bugzilla bug list needs attention.
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://bugzilla.suse.com/) that require attention. All of these bugs are in either the CONFIRMED, NEW, or REOPENED state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reset Assignee to default" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Ignore this email until you are actively working on this bug, when you should set the status to IN_PROGRESS. To get a list of all affected bugs, you can use this URL (bookmark it if you like!): http://bugzilla.suse.com/buglist.cgi?bug_status=CONFIRMED&bug_status=NEW&bu… Or, you can use the general query page, at http://bugzilla.suse.com/query.cgi Appended below are the individual URLs to get to all of your affected bugs that haven't been touched for 7 days or more. You will get this message once a week until you've dealt with these bugs! Raise default file descriptor limits to meet Valve Proton requirements -> http://bugzilla.suse.com/show_bug.cgi?id=1107525 Screen flickering on latest Dell XPS 7390 with kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun -> http://bugzilla.suse.com/show_bug.cgi?id=1161843 System hung - nouveau 0000:01:00.0: plasmashell[2512]: channel 7 killed! -> http://bugzilla.suse.com/show_bug.cgi?id=1165790 Harmonize kernel modules in JeOS leap 15.1 with TW and leap 15.2 -> http://bugzilla.suse.com/show_bug.cgi?id=1166342 test bug for assignee change -> http://bugzilla.suse.com/show_bug.cgi?id=1172181 Support for 64-bot processors on motherboards with 32-bit UEFI -> http://bugzilla.suse.com/show_bug.cgi?id=1172292 usb message shown on console even with "quiet splash=silent" -> http://bugzilla.suse.com/show_bug.cgi?id=1172322 Random screen flashing after suspend on KDE -> http://bugzilla.suse.com/show_bug.cgi?id=1172475 Mysterious crashes with kernel 5.6.14, suspect KVM -> http://bugzilla.suse.com/show_bug.cgi?id=1172541 kdump: fails to create dump as dump-capture kernel boots into systemd emergency mode -> http://bugzilla.suse.com/show_bug.cgi?id=1172670 Videoconferencing apps on openSUSE --> much higher CPU and heat than Clear Linux -> http://bugzilla.suse.com/show_bug.cgi?id=1172900 Kernel 5.7.1 does not boot -> http://bugzilla.suse.com/show_bug.cgi?id=1173071 zypper dup from 15.1 shows mok screen on reboot -> http://bugzilla.suse.com/show_bug.cgi?id=1173115 iwlwifi: TX on unused queue 5 WARNING: tx.c:2346 iwl_trans_pcie_tx+0xa1e/0x1150 -> http://bugzilla.suse.com/show_bug.cgi?id=1173294 BUG: kernel NULL pointer dereference, address: 0000000d during install on i686 notebook -> http://bugzilla.suse.com/show_bug.cgi?id=1173891 -- To unsubscribe, e-mail: kernel-bugs+unsubscribe(a)opensuse.org To contact the owner, e-mail: kernel-bugs+owner(a)opensuse.org

1 0

[kernel-bugs] [Bug 1174278] kernel-firmware-amdgpu 20200702 breaks video on Picasso
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174278 https://bugzilla.suse.com/show_bug.cgi?id=1174278#c6 --- Comment #6 from Adam Reichold <adam.reichold(a)t-online.de> --- (In reply to Takashi Iwai from comment #5) > Can anyone report the regression to upstream? e.g. on > gitlab.freedesktop.org issues. Reported upstream at https://gitlab.freedesktop.org/drm/amd/-/issues/1229 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174278] kernel-firmware-amdgpu 20200702 breaks video on Picasso
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174278 https://bugzilla.suse.com/show_bug.cgi?id=1174278#c5 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com Flags| |needinfo? --- Comment #5 from Takashi Iwai <tiwai(a)suse.com> --- Can anyone report the regression to upstream? e.g. on gitlab.freedesktop.org issues. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174281] Kernel 5.7.7 amdgpu mode switch causing hang/black screen
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174281 https://bugzilla.suse.com/show_bug.cgi?id=1174281#c3 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |tiwai(a)suse.com Resolution|--- |DUPLICATE --- Comment #3 from Takashi Iwai <tiwai(a)suse.com> --- . *** This bug has been marked as a duplicate of bug 1174278 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174278] kernel-firmware-amdgpu 20200702 breaks video on Picasso
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174278 https://bugzilla.suse.com/show_bug.cgi?id=1174278#c4 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |greeneg(a)tolharadys.net --- Comment #4 from Takashi Iwai <tiwai(a)suse.com> --- *** Bug 1174281 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174281] New: Kernel 5.7.7 amdgpu mode switch causing hang/black screen
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1174281 Bug ID: 1174281 Summary: Kernel 5.7.7 amdgpu mode switch causing hang/black screen Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: greeneg(a)tolharadys.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On boot with any kernel greater than 5.7.5, the system hangs and cannot boot beyond the point in system initialization for Kernel mode switching. Setting nomodeset lets the system boot, with degraded graphical capabilities. Unfortunately, I don't have a copy of the RPM for 5.7.5, so system is unusable at this time under openSUSE. Am willing to assist in any way I can to get this working again. Hardware: - HP Envy x360 Convertable 15m-ds0011dx - AMD Ryzen 5 3500U with Radeon Vega Mobile - 32GB RAM -- You are receiving this mail because: You are the assignee for the bug.

1 2

[kernel-bugs] [Bug 1174047] New: Weird load behaviour with kernel-5.3.18-lp152.20.7-default
by bugzilla_noreply＠suse.com 19 Jul '20

19 Jul '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1174047 Bug ID: 1174047 Summary: Weird load behaviour with kernel-5.3.18-lp152.20.7-default Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jurriaan(a)xenophobia.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 839613 --> http://bugzilla.opensuse.org/attachment.cgi?id=839613&action=edit load graph When I updated the new kernel I experienced weird load behaviour. The load kept climbing and within 2 days I saw a load of 90 while no processes were really active. One of the processes (a KVM virtual machine) which had some CPU usage in top I killed but the load didn't really go down. -- top - 07:48:10 up 1 day, 15:13, 8 users, load average: 89.73, 89.36, 88.64 Tasks: 371 total, 2 running, 369 sleeping, 0 stopped, 0 zombie %Cpu(s): 4.4 us, 0.7 sy, 0.8 ni, 93.6 id, 0.5 wa, 0.0 hi, 0.1 si, 0.0 st -- My process list without inactive processes was this: -- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6535 qemu 20 0 12.781g 8.198g 24108 S 25.17 26.11 277:43.92 qemu-system-x86 5613 qemu 20 0 2521260 1.689g 23968 S 3.311 5.381 135:35.22 qemu-system-x86 8066 qemu 20 0 3088768 2.190g 23936 S 2.649 6.977 49:15.60 qemu-system-x86 7859 qemu 20 0 3037224 2.188g 24064 S 1.987 6.969 56:20.74 qemu-system-x86 7979 qemu 20 0 1985716 1.189g 24116 S 1.656 3.789 187:19.17 qemu-system-x86 3318 icinga 20 0 2964888 36880 18684 S 0.993 0.112 13:03.10 icinga2 2486 influxdb 20 0 6815940 451780 49600 S 0.662 1.372 60:54.26 influxd 2498 redis 20 0 91632 24292 4716 S 0.662 0.074 13:44.69 redis-server 3532 postgres 20 0 1204624 46252 42568 S 0.662 0.141 5:11.47 postgres 29529 root 20 0 50272 4380 3452 R 0.662 0.013 0:00.08 top 29568 root 20 0 130144 4104 2736 S 0.662 0.012 0:00.02 sshd 2584 root 20 0 925036 60684 47496 S 0.331 0.184 2:40.19 fail2ban-server 2750 root 20 0 1275024 68076 16780 S 0.331 0.207 2:48.57 salt-minion 3048 named 20 0 872640 236812 7388 S 0.331 0.719 5:10.92 named 3415 icinga 20 0 692592 6660 4732 S 0.331 0.020 1:42.88 icinga2 26938 root 20 0 0 0 0 I 0.331 0.000 0:00.14 kworker/6:0-events 27676 root 20 0 0 0 0 I 0.331 0.000 0:00.08 kworker/u16:8-events_unbound -- Not really troublesome I would say. I have attached a graph of the load of the machine over the last 2 days. It clearly shows the moment the machine was rebooted. I reverted back to the GM kernel (5.3.18-lp152.19-default) and had no issues with the load anymore. I am seeing this on a hardware machine (Intel(R) Atom(TM) CPU C3758 @ 2.20GHz). Virtual machines don't seem to be that impacted. I had a load of 3 on one VM with the 5.3.18-lp152.20.7-default kernel and 0,06 with the 5.3.18-lp152.19-default kernel. Not as high as the hardware machine but there is something different. Please let me know what more information you need to diagnose this issue. Thanks in advance. -- You are receiving this mail because: You are the assignee for the bug.

1 3