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.
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=1201963
Bug ID: 1201963
Summary: 11th Gen Intel(R) Core(TM) i5-1145G7 throttling to
400MHz from 70�C until it reaches 54�C
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: gryffus(a)hkfree.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 860458
--> https://bugzilla.suse.com/attachment.cgi?id=860458&action=edit
Turbostat log output
I have a Dell Latitude 5420 laptop and i am experiencing CPU slowdown when
using any graphical / CPU demanding application.
The laptop contains 11th Gen Intel(R) Core(TM) i5-1145G7 which can do 4,4GHz on
turbo.
When the system reaches about 70�C, all cores switch to 400MHz and stay there
until temperature hits 53-54�C.
I can see this behavior especially in Vulkan graphics applications, but not
only in them, it just happens almost instantly there, since the 70�C is reached
within about 30 seconds there.
I would want to raise the temperature limits to at least 80-90�C or disable
throttling completely (at my own responsibility of cooking it). But throttling
from 70�C seems as a complete nonsense to me - the CPU package gets to this
temperature in 10-20 seconds under load, so i basically never make use of the
4,4GHz.
What i have tried:
1) Kernel 5.19 from Kernel:HEAD - no change
2) installed throttled ( https://github.com/erpalma/throttled ) - no change
3) blacklisted intel_powerclamp, intel_rapl_msr, processor_thermal_rapl,
intel_rapl_common kernel modules - no change
4) cpupower frequency-set -g performance - no change
# cat /sys/devices/platform/*/uuids/current_uuid
INVALID
# cat /sys/devices/platform/*/uuids/available_uuids
UNKNOWN
# cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 4.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 4.40 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.16 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
# cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
Number of idle states: 4
Available idle states: POLL C1_ACPI C2_ACPI C3_ACPI
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Usage: 265266
Duration: 8068126
C1_ACPI:
Flags/Description: ACPI FFH MWAIT 0x0
Latency: 1
Usage: 10617293
Duration: 1984558460
C2_ACPI:
Flags/Description: ACPI FFH MWAIT 0x31
Latency: 253
Usage: 273458
Duration: 261649941
C3_ACPI:
Flags/Description: ACPI FFH MWAIT 0x60
Latency: 1048
Usage: 206150
Duration: 509227956
# cpupower info
analyzing CPU 0:
perf-bias: 0
Turbostat debug log attached.
Some further reading with probably related reports:
https://www.dell.com/community/Latitude/Latitude-5420-7420-7520-CPU-Throttl…https://github.com/intel/thermal_daemon/issues/341https://github.com/intel/thermal_daemon/issues/293https://github.com/erpalma/throttled
Any clues?
--
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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191933
Bug ID: 1191933
Summary: Kernel can not update on Secure boot envirnment
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: kokeko(a)mac.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Current 20211012, update to 20211016 or 20211019.
Kernel-default update failed by fallowing error.
subprocess error, secure boot enabled.
Is it something change?
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1200781
Bug ID: 1200781
Summary: xhci stop working. Works briefly after reboot, or
remove and load xhci_pci & xhci_hcd.
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: x86-64
OS: openSUSE Leap 15.4
Status: NEW
Severity: Major
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: publio.escipion.el.africano(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
openSuSE Leap 15.4 x86_64, kernel 4.14.21-150400.22-default, in a Lenovo
IdeaPad 3 15ADA05:
https://psref.lenovo.com/syspool/Sys/PDF/IdeaPad/IdeaPad_3_15ADA05/IdeaPad_…
An external mouse stops working after a brief period of time, after login into
KDE, or after removing and loading xhci_pci & xhci_hcd.
System complaints of:
�xhci_hcd 0000:02:00.3 WARNIGN: Host System Error�
and:
�usb 2-3: device not accepting address 2, error -108�
I've tried two bluetooth mice, and a standard cord mouse. The same result.
It seems that it's the USB controllers are the only components affected, so
far. Mousepad works properly, but I'm not use to it.
I have to constantly remove and load xhci_pci & xhci_hcd, as root.
rmmod xhci_pci
rmmod xhci_hcd
modprobe xhci_pci
modprobe xhci_hcd
Mouse works after that for a short time.
Nota bene: Devices work properly under openSuSE Leap 15.2 x86_64, kernel
5.3.18-lp152.106-default (old HP Pavillion).
This bug resembles https://bugzilla.opensuse.org/show_bug.cgi?id=1193652
--
You are receiving this mail because:
You are the assignee for the bug.