https://bugzilla.suse.com/show_bug.cgi?id=1189881
Bug ID: 1189881
Summary: warning:
/var/tmp/weak-modules2.7WPIFB/symvers-5.13.12-2-defaul
t not available
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: gp(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Running zypper dup on my Tumbleweed machine, I noticed the following in
the logs:
(121/203) Installing: kernel-default-5.13.12-2.1.x86_64 ....[done]
Additional rpm output:
warning: /var/tmp/weak-modules2.7WPIFB/symvers-5.13.12-2-default not available
It is probably benign, but still a bit confusing/worrisome. What do we
want to tell users here (that would be actionable)?
And/or is this indicative of some problem with the upgrade as such?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1188940
Bug ID: 1188940
Summary: bluetooth adapter fails to power on
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: msuchanek(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
hramrach@naga:~> bluetoothctl
Agent registered
[CHG] Controller 00:E0:3C:87:B8:03 Pairable: yes
[bluetooth]# power on
Failed to set power on: org.bluez.Error.Failed
[bluetooth]# power on
Failed to set power on: org.bluez.Error.Busy
[bluetooth]# power on
Failed to set power on: org.bluez.Error.Busy
[bluetooth]# power on
Failed to set power on: org.bluez.Error.Busy
[bluetooth]#
--
You are receiving this mail because:
You are the assignee for the bug.
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.
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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191244
Bug ID: 1191244
Summary: USB speaker working when plugged while system is up
but not on reboot
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.3
Hardware: aarch64
OS: openSUSE Leap 15.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: peter.stark(a)storck.net
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I have multiple raspberry PI 4Bs with openSUSE Leap 15.3 and some with raspbian
9. I got a USB speaker (e2b7:0811) which I connected to the 4Bs using Leap
15.3.
This speaker works fine when I plug it in when the PI is already running:
rpi15:~ # uname -a
Linux rpi15 5.3.18-59.24-default #1 SMP Mon Sep 13 15:06:42 UTC 2021 (2f872ea)
aarch64 aarch64 aarch64 GNU/Linux
rpi15:~ # lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 03eb:2013 Atmel Corp. iAQ Stick
Bus 001 Device 007: ID e2b7:0811 Jie Li CD002
Bus 001 Device 003: ID 044f:b351 ThrustMaster, Inc. F16 MFD 1
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
rpi15:~ # dmesg -T|grep 1-1.2
[Sa Okt 2 10:56:09 2021] usb 1-1.2: USB disconnect, device number 4
[Sa Okt 2 10:56:17 2021] usb 1-1.2: new full-speed USB device number 6 using
xhci_hcd
[Sa Okt 2 10:56:17 2021] usb 1-1.2: device descriptor read/64, error -32
[Sa Okt 2 10:56:17 2021] usb 1-1.2: device descriptor read/64, error -32
[Sa Okt 2 10:56:17 2021] usb 1-1.2: new full-speed USB device number 7 using
xhci_hcd
[Sa Okt 2 10:56:17 2021] usb 1-1.2: config 1 has an invalid interface number:
3 but max is 2
[Sa Okt 2 10:56:17 2021] usb 1-1.2: config 1 has no interface number 0
[Sa Okt 2 10:56:17 2021] usb 1-1.2: New USB device found, idVendor=e2b7,
idProduct=0811, bcdDevice= 1.00
[Sa Okt 2 10:56:17 2021] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=1
[Sa Okt 2 10:56:17 2021] usb 1-1.2: Product: CD002
[Sa Okt 2 10:56:17 2021] usb 1-1.2: Manufacturer: CD002
[Sa Okt 2 10:56:17 2021] usb 1-1.2: SerialNumber: CD002
[Sa Okt 2 10:56:17 2021] usb 1-1.2: 9:1: bogus dB values (-12800/-12700),
disabling dB reporting
[Sa Okt 2 10:56:17 2021] input: CD002 CD002 as
/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:E2B7:0811.0003/input/input1
However, after a reboot with the device still connected (no change) the kernel
boots and does not even see the device.
rpi15:~ # lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 03eb:2013 Atmel Corp. iAQ Stick
Bus 001 Device 003: ID 044f:b351 ThrustMaster, Inc. F16 MFD 1
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
rpi15:~ # dmesg -T|grep 1-1.2
rpi15:~ #
I have tried the same USB speaker on another PI4B with Leap 15.3 with the same
result. So, it doesn't seem to be that PI.
When I connect the speaker to a PI3 with raspbian 9, it works as expected.
root@rpi13:~# dmesg -T |grep 1-1.3
[Sa Okt 2 10:33:08 2021] usb 1-1.3: new full-speed USB device number 4 using
dwc_otg
[Sa Okt 2 10:33:08 2021] usb 1-1.3: config 1 has an invalid interface number:
3 but max is 2
[Sa Okt 2 10:33:08 2021] usb 1-1.3: config 1 has no interface number 0
[Sa Okt 2 10:33:08 2021] usb 1-1.3: New USB device found, idVendor=e2b7,
idProduct=0811
[Sa Okt 2 10:33:08 2021] usb 1-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=1
[Sa Okt 2 10:33:08 2021] usb 1-1.3: Product: CD002
[Sa Okt 2 10:33:08 2021] usb 1-1.3: Manufacturer: CD002
[Sa Okt 2 10:33:08 2021] usb 1-1.3: SerialNumber: CD002
[Sa Okt 2 10:33:08 2021] input: CD002 CD002 as
/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.3/0003:E2B7:0811.0001/input/input0
[Sa Okt 2 10:42:57 2021] usb 1-1.3: reset full-speed USB device number 4 using
dwc_otg
[Sa Okt 2 10:42:58 2021] usb 1-1.3: USB disconnect, device number 4
[Sa Okt 2 10:42:58 2021] usb 1-1.3: 9:1: cannot get min/max values for control
2 (id 9)
[Sa Okt 2 10:43:04 2021] usb 1-1.3: new full-speed USB device number 6 using
dwc_otg
[Sa Okt 2 10:43:04 2021] usb 1-1.3: device descriptor read/64, error -32
[Sa Okt 2 10:43:04 2021] usb 1-1.3: config 1 has an invalid interface number:
3 but max is 2
[Sa Okt 2 10:43:04 2021] usb 1-1.3: config 1 has no interface number 0
[Sa Okt 2 10:43:04 2021] usb 1-1.3: New USB device found, idVendor=e2b7,
idProduct=0811
[Sa Okt 2 10:43:04 2021] usb 1-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=1
[Sa Okt 2 10:43:04 2021] usb 1-1.3: Product: CD002
[Sa Okt 2 10:43:04 2021] usb 1-1.3: Manufacturer: CD002
[Sa Okt 2 10:43:04 2021] usb 1-1.3: SerialNumber: CD002
[Sa Okt 2 10:43:04 2021] input: CD002 CD002 as
/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.3/0003:E2B7:0811.0002/input/input1
I noticed that the raspbian uses dwc_otg vs. xhci_hcd on Leap. However, dwc_otg
doesn't seem to be a separate module in raspbian nor it is available on leap.
As the speaker is working when I un-plug and plug it in again, I wonder what
may causes this strange behavior. Especially as I do not see the device via
lsusb after reboot, though it is still connected.
Any ideas on how to fix it?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1189946
Bug ID: 1189946
Summary: [trackerbug] Ancient patch cleanup
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: jeffm(a)suse.com
QA Contact: qa-bugs(a)suse.de
CC: jeffm(a)suse.com, mkubecek(a)suse.com
Found By: ---
Blocker: ---
This is the tracker bug for cleaning up old patches in the master branch.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1193599
Bug ID: 1193599
Summary: ntel_dp_detect [i915]] *ERROR* LSPCON init failed on
port D
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: x86-64
OS: openSUSE Leap 15.4
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: opendreas(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
The following errors appear at boot
broken atomic modeset userspace detected, disabling atomic
[drm spcon_init [i915]] *ERROR* Failed to probe lspcon
[drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
[drm spcon_init [i915]] *ERROR* Failed to probe lspcon
[drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
[drm spcon_init [i915]] *ERROR* Failed to probe lspcon
[drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
[drm spcon_init [i915]] *ERROR* Failed to probe lspcon
[drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
Full log
https://paste.opensuse.org/83436185
Hardware
Dell Precision 7530
CPU: Intel Xeon E-2186M
GPU: Intel P630 / Nvidia Quadro P3200
--
You are receiving this mail because:
You are the assignee for the bug.