https://bugzilla.suse.com/show_bug.cgi?id=1188889
Bug ID: 1188889
Summary: crash is failing with 5.13 kernels
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: hare(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When trying to run crash on a 5.13 or later kernel dump I get the error
message:
crash: invalid structure member offset: task_struct_state
FILE: task.c LINE: 5916 FUNCTION: task_state()
[/usr/bin/crash] error trace: 559027f7b785 => 559027f7b54d => 559027fffe94
=> 559027fffe0d
This has been fixed by upstream commit
d6b4f36d6b22b70fb14e692f36d20910ef5563c1.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1184718
Bug ID: 1184718
Summary: systemtap simple helloworld script execution fails in
Tumbleweed
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: vasilios.anastasiadis(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 848350
--> https://bugzilla.suse.com/attachment.cgi?id=848350&action=edit
Related errors
Unable to run a simple systemtap helloworld.stp example script (provided with
systemtap-docs) in Tumbleweed. It works fine in SLE versions 12sp2-15sp3.
Steps to reproduce:
- Install systemtap, systemtap-docs, kernel-default-devel
- Run: stap /usr/share/doc/packages/systemtap/examples/general/helloworld.stp
See attached file for errors.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1188712
Bug ID: 1188712
Summary: VDSO change on PPC causes random segfaults in Go
applications
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: PowerPC-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: fvogt(a)suse.com
QA Contact: qa-bugs(a)suse.de
CC: jkowalczyk(a)suse.com
Found By: ---
Blocker: ---
https://lwn.net/ml/linux-kernel/cover.1601365869.git.christophe.leroy@csgro…
changed the implementation of the VDSO from a PowerPC specific one to the
generic C version.
Apparently executables built with Go before 1.17 implicitly relied on the fact
that the VDSO did not mangle r30, but with the generic C implementation it now
does. This leads to random crashes in Go executables.
This is fixed with https://go-review.googlesource.com/c/go/+/334410/1 and I
submitted this to our go1.16 package with
https://build.opensuse.org/request/show/907807.
However, all executables built with a compiler which doesn't include that will
not work on kernel >= 5.13. This probably affects containerized workloads as
well. So it might be useful to raise awareness of this issue.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203767
Bug ID: 1203767
Summary: Backport AMD ACPI processor idle dummy wait fix
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: dmueller(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Old, circa 2002 chipsets have a bug: they don't go idle when they are
supposed to. So, a workaround was added to slow the CPU down and
ensure that the CPU waits a bit for the chipset to actually go idle.
This workaround is ancient and has been in place in some form since
the original kernel ACPI implementation.
But, this workaround is very painful on modern systems. The "inl()"
can take thousands of cycles (see Link: for some more detailed
numbers and some fun kernel archaeology).
First and foremost, modern systems should not be using this code.
Typical Intel systems have not used it in over a decade because it is
horribly inferior to MWAIT-based idle.
Despite this, people do seem to be tripping over this workaround on
AMD system today.
Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD
systems from tripping over the workaround. Remotely modern Intel
systems use intel_idle instead of this code and will, in practice,
remain unaffected by the dummy wait.
Reported-by: K Prateek Nayak <kprateek.nayak(a)amd.com>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak(a)amd.com>
Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/
Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com
git commit e400ad8b7e6a1b9102123c6240289a811501f7d9
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1200461
Bug ID: 1200461
Summary: Dracut locks computer, fails to generate initrd file
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: mfdemicco(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 859545
--> http://bugzilla.opensuse.org/attachment.cgi?id=859545&action=edit
Photo of screen at moment of freeze
When I update to kernel 5.18.1-1 or 5.18.2.1, Dracut locks up my system
requiring a power button reboot when creating the initrd file. I also tried
installing the latest version of Tumbleweed to another partition, and the
installation locked up the computer about 50% into the installation with no
creation of the initrd file. The computer freezes at:
Dracut: *** Including module: kernel-modules ***
When I look in my /boot folder, everything for the kernel is created except for
the initrd file I've done a search and can't find anyone that has the same
problem. The system runs file with the older kernel 5.17.4-1. I have a legacy
BIOS system.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1188954
Bug ID: 1188954
Summary: black screen on initial X open on Kaveri Radeon R7,
/dev/dri/card0: No such file or directory with
radeon.cik_support=0 amdgpu.cik_support=1
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: mrmazda(a)earthlink.net
QA Contact: qa-bugs(a)suse.de
CC: sndirsch(a)suse.com
Found By: ---
Blocker: ---
Created attachment 851460
--> http://bugzilla.opensuse.org/attachment.cgi?id=851460&action=edit
Xorg.0.log and dmesg
Initial summary:
black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such
file or directory with radeon.cik_support=0 amdgpu.cik_support=1
To reproduce:
1-boot with included on kernel cmdline radeon.cik_support=0
amdgpu.cik_support=1
2-wait for X to fail to start
3-login on a tty
4-systemctl restart xdm
Actual behavior:
1-X fails to start, finding no /dev/dri/card0, leaving login prompt on tty1 on
display screen
2-X starts normally using amdgpu DDX driver
Expected behavior:
1-X starts normally using amdgpu DDX driver
Tested with kernels 5.12.13, 5.11.16, 5.7.11
# inxi -SGIay
System:
Host: asa88 Kernel: 5.12.13-1-default x86_64 bits: 64 compiler: gcc
v: 11.1.1
parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=tvgp07stw noresume
ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0
radeon.cik_support=0 amdgpu.cik_support=1 video=1024x768@60
video=1440x900@60 drm.debug=0x1e log_buf_len=1M
Console: tty pts/0 DM: TDM Distro: openSUSE Tumbleweed 20210730
Graphics:
Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu
v: kernel alternate: radeon bus-ID: 00:01.0 chip-ID: 1002:130f
class-ID: 0300
Display: server: X.org 1.20.12 driver: loaded: vesa
unloaded: fbdev,modesetting alternate: ati
Message: Advanced graphics data unavailable for root.
Info:...inxi: 3.3.06
Comments:
1-without radeon.cik_support=0 amdgpu.cik_support=1 on cmdline, X cannot be
coaxed into using amdgpu DDX driver via /etc/X11/xorg.conf.d/*conf
2-without radeon.cik_support=0 amdgpu.cik_support=1, greeter startup completes
(normally, on first try) using modesetting DIX driver
--
You are receiving this mail because:
You are the assignee for the bug.