May 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1177288] New: Raspberry pi3 (model b) crashes with network gadget
by bugzilla_noreply＠suse.com 03 Jul '22

03 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1177288 Bug ID: 1177288 Summary: Raspberry pi3 (model b) crashes with network gadget Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: coolo(a)suse.com QA Contact: qa-bugs(a)suse.de CC: guillaume.gardet(a)arm.com, nsaenzjulienne(a)suse.com Found By: --- Blocker: --- I use the official Leap 15.2 Jeos image on a pi3b and have a USB network device attached to it (a very special one, https://www.fibrecode.com/fc602-usb-oabr-broadr-reach-100base-t1-stick.html) and it crashes the kernel pretty reliably with the following crash dump. [ 86.184109] usb 1-1.3: USB disconnect, device number 5 [ 86.184427] cdc_ether 1-1.3:1.0 eth2: unregister 'cdc_ether' usb-3f980000.usb-1.3, CDC Ethernet Device [ 99.795717] usb 1-1.3: new high-speed USB device number 7 using dwc2 [ 99.926758] usb 1-1.3: New USB device found, idVendor=152a, idProduct=857b, bcdDevice= 2.24 [ 99.926780] usb 1-1.3: New USB device strings: Mfr=2, Product=1, SerialNumber=3 [ 99.926788] usb 1-1.3: Product: FibreCode FC602 Stick [ 99.926796] usb 1-1.3: Manufacturer: FibreCode [ 99.926804] usb 1-1.3: SerialNumber: FC01330000018a69 [ 99.930380] cdc_ether 1-1.3:1.0 eth1: register 'cdc_ether' at usb-3f980000.usb-1.3, CDC Ethernet Device, fc:c2:3d:1f:7f:ad [ 99.949857] cdc_ether 1-1.3:1.0 eth2: renamed from eth1 [ 740.880346] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown [ 740.880360] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04400001 [ 741.461843] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown [ 741.461858] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x06400001 [ 741.880374] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but reason is unknown [ 741.880386] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04400001 [ 741.880395] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 741.880573] WARNING: CPU: 0 PID: 0 at ../drivers/usb/dwc2/hcd.c:2683 dwc2_assign_and_init_hc+0x664/0xa10 [dwc2] [ 741.880578] Modules linked in: af_packet iscsi_ibft iscsi_boot_sysfs vc4 drm_kms_helper drm btsdio snd_soc_core bluetooth snd_compress snd_bcm2835(C) nls_iso8859_1 ac97_bus nls_cp437 snd_pcm_dmaengine ecdh_generic snd_pcm bcm2835_v4l2(C) ecc vfat v4l2_common snd_timer fat videobuf2_vmalloc brcmfmac videobuf2_memops videobuf2_v4l2 snd videobuf2_common videodev mc brcmutil cpufreq_dt soundcore fb_sys_fops cfg80211 syscopyarea sysfillrect microchip sysimgblt rfkill ftdi_sio cdc_ether usbnet lan78xx usbserial mii raspberrypi_hwmon bcm2835_thermal raspberrypi_cpufreq vchiq(C) bcm2835_rng bcm2835_wdt crct10dif_ce uio_pdrv_genirq uio leds_gpio ext4 mbcache jbd2 mmc_block dwc2 udc_core usbcore sdhci_iproc sdhci_pltfm sdhci bcm2835 gpio_raspberrypi_exp mmc_core clk_raspberrypi i2c_bcm2835 bcm2835_dma fixed phy_generic dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod efivarfs [ 741.880754] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 5.3.18-lp152.36-default #1 openSUSE Leap 15.2 (unreleased) [ 741.880759] Hardware name: raspberrypi rpi/rpi, BIOS 2020.01 06/02/2020 [ 741.880765] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 741.880799] pc : dwc2_assign_and_init_hc+0x664/0xa10 [dwc2] [ 741.880834] lr : dwc2_hcd_select_transactions+0x104/0x1a0 [dwc2] [ 741.880838] sp : ffff000010003c60 [ 741.880842] x29: ffff000010003c60 x28: ffff3bd997683dc0 [ 741.880849] x27: ffffa6ec7c4c4000 x26: ffff3bd997679000 [ 741.880857] x25: 0000000000000008 x24: ffffa6ec7c6a55e0 [ 741.880864] x23: ffffa6ec6bbc5080 x22: ffffa6ec77d12830 [ 741.880871] x21: ffffa6ec79871600 x20: ffffa6ec7c6a5080 [ 741.880878] x19: ffffa6ec6bbc50c8 x18: ffffffffffffffff [ 741.880885] x17: 0000000000000001 x16: 0000000000000007 [ 741.880891] x15: ffff3bd997679708 x14: ffff3bd9978cfa28 [ 741.880898] x13: ffff3bd9978cf67e x12: ffff3bd9976a2000 [ 741.880905] x11: 0000000000000000 x10: ffff3bd9978ce000 [ 741.880912] x9 : 0000000000000000 x8 : 0000000000000003 [ 741.880919] x7 : 0000000000000176 x6 : ffff3bd9978cec90 [ 741.880925] x5 : 0000000000000001 x4 : ffffa6ec79871698 [ 741.880932] x3 : 0000000000000000 x2 : 00000000000005ee [ 741.880939] x1 : 0000000000000000 x0 : 0000000000000002 [ 741.880946] Call trace: [ 741.880984] dwc2_assign_and_init_hc+0x664/0xa10 [dwc2] [ 741.881018] dwc2_hcd_select_transactions+0x104/0x1a0 [dwc2] [ 741.881052] dwc2_release_channel+0xfc/0x280 [dwc2] [ 741.881087] dwc2_halt_channel+0xac/0x158 [dwc2] [ 741.881121] dwc2_hc_n_intr+0x860/0x8c0 [dwc2] [ 741.881155] dwc2_handle_hcd_intr+0x38c/0x450 [dwc2] [ 741.881188] _dwc2_hcd_irq+0x20/0x30 [dwc2] [ 741.881278] usb_hcd_irq+0x3c/0x60 [usbcore] [ 741.881291] __handle_irq_event_percpu+0x74/0x268 [ 741.881299] handle_irq_event_percpu+0x40/0x98 [ 741.881307] handle_irq_event+0x50/0xa8 [ 741.881314] handle_level_irq+0xd4/0x178 [ 741.881321] generic_handle_irq+0x34/0x50 [ 741.881332] bcm2836_chained_handle_irq+0x4c/0x70 [ 741.881339] generic_handle_irq+0x34/0x50 [ 741.881346] __handle_domain_irq+0x68/0xc0 [ 741.881354] bcm2836_arm_irqchip_handle_irq+0x78/0xe0 [ 741.881360] el1_irq+0xcc/0x180 [ 741.881369] arch_cpu_idle+0x40/0x1c0 [ 741.881377] default_idle_call+0x24/0x44 [ 741.881385] do_idle+0x1dc/0x2c0 [ 741.881392] cpu_startup_entry+0x28/0x30 [ 741.881400] rest_init+0xc4/0xd0 [ 741.881409] arch_call_rest_init+0x14/0x1c [ 741.881414] start_kernel+0x4e8/0x51c [ 741.881419] ---[ end trace 29007ab7897c5716 ]--- [ 742.880425] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown [ 742.880437] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 742.880445] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 743.880453] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason is unknown [ 743.880465] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 743.880474] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 744.880491] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown [ 744.880505] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 744.880514] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 745.880537] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd set, but reason is unknown [ 745.880549] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 745.880557] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 746.880564] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but reason is unknown [ 746.880576] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 746.880585] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 747.880601] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown [ 747.880612] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 747.880621] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 748.880641] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd set, but reason is unknown [ 748.880654] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600009 [ 748.880664] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 749.880675] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown [ 749.880686] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001 [ 749.880695] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length [ 750.880718] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1184804] New: move kernel out of /boot
by bugzilla_noreply＠suse.com 24 May '22

24 May '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1184804 Bug ID: 1184804 Summary: move kernel out of /boot 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea. Having the kernel installed via rpm in /boot also causes issues with eg snapshots if /boot is on a separate partition. So it make sense to store the rpm provided parts of the kernel packages where the rest of the OS is and manage /boot separately. Looking at Fedora they install files like vmlinuz that used to be named /boot/$name-$kver as (/usr)/lib/modules/$kver/$name instead. They include /boot/$name-$kver as %ghost. -- You are receiving this mail because: You are the assignee for the bug.

1 28

[Bug 1184767] New: Several firmwares missing when installing MicroOS
by bugzilla_noreply＠suse.com 16 Mar '22

16 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1184767 Bug ID: 1184767 Summary: Several firmwares missing when installing MicroOS 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: dfaggioli(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After finishing installing MicroOS on my laptop, I have this in dmesg: dario@Palanthas-eth:~> dmesg |grep firmware [ 0.073533] Spectre V2 : Enabling Restricted Speculation for firmware calls [ 2.964996] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 2.964998] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 2.964999] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git… [ 66.877346] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 66.928640] r8152 4-1.4:1.0: Direct firmware load for rtl_nic/rtl8153a-3.fw failed with error -2 [ 66.928646] r8152 4-1.4:1.0: unable to load firmware patch rtl_nic/rtl8153a-3.fw (-2) [ 67.153449] bluetooth hci0: Direct firmware load for qca/rampatch_usb_00000302.bin failed with error -2 [ 67.906512] ath10k_pci 0000:3a:00.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA6174/hw3.0: -2 [ 67.906552] ath10k_pci 0000:3a:00.0: could not fetch firmware files (-2) And WiFi and Bluetooth are not working. All the firmware related messages go away if I install the following packages: - kernel-firmware-iwlwifi - kernel-firmware-realtek - kernel-firmware-i915 - kernel-firmware-bluetooth - kernel-firmware-ath10k The message about regulatory.db goes away if I install the crda package This is related to bug 1184403 with the only difference that there the missing firmware is in kernel-firmware-iwlwifi. Also, it looks like this shouldn't happen, according to bug 1174521, as it's marked as fixed, but the problem seems to still be there -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1180316] New: [Build 20201222] openQA test fails in kdump_and_crash
by bugzilla_noreply＠suse.com 15 Mar '22

15 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180316 Bug ID: 1180316 Summary: [Build 20201222] openQA test fails in kdump_and_crash Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1523048/modules/kdum p_and_crash/steps/58 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-kvm-and-xen-x86_64-jeos-extra@64bit_virtio-2G fails in [kdump_and_crash](https://openqa.opensuse.org/tests/1523048/modules/kdump_an… After the update to kernel 5.10, kdump_and_crash fails crash: cannot determine length of symbol: log_end ## Test suite description Same as jeos, plus some more tests. ## Reproducible Fails since (at least) Build [20190311](https://openqa.opensuse.org/tests/877894) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1184782] New: Emergency mode during boot with "mount(2) system call failed: Cannot allocate memory"
by bugzilla_noreply＠suse.com 11 Mar '22

11 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1184782 Bug ID: 1184782 Summary: Emergency mode during boot with "mount(2) system call failed: Cannot allocate memory" 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: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Just had this problem when starting my workstation this morning. May or may not be related to bug 1184779, which I encountered simultaneously. > [ 105.589905] apollon systemd[1]: Mounting /var/spool... > [ 105.610706] apollon systemd[1]: Mounting /var/tmp... > [ 105.612009] apollon systemd[1]: Starting File System Check on /dev/disk/by-label/git... > ... > [ 105.626645] apollon mount[1975]: mount: /var/tmp: mount(2) system call failed: Cannot allocate memory. > [ 105.636377] apollon systemd[1]: Finished Load/Save Screen Backlight Brightness of leds:dell::kbd_backlight. > [ 105.638474] apollon systemd[1]: Mounted /.snapshots. > [ 105.640099] apollon systemd[1]: Mounted /boot/efi. > ... > [ 105.666824] apollon systemd[1]: Failed to mount /var/tmp. > [ 105.668645] apollon systemd[1]: Dependency failed for Local File Systems. > [ 105.668705] apollon systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. After entering emergency mode, I simply typed "mount /var/tmp", and had no issue. Bug 1184779 persisted though (see there). /var/tmp is just a btrfs subvolume. # btrfs subvol list / ID 257 gen 930369 top level 5 path @ ID 258 gen 1432317 top level 257 path @/.snapshots ID 260 gen 1427487 top level 257 path @/boot/grub2/x86_64-efi ID 261 gen 1432361 top level 257 path @/opt ID 262 gen 1427487 top level 257 path @/srv ID 263 gen 18 top level 257 path @/tmp ID 264 gen 1432300 top level 257 path @/usr/local ID 265 gen 1432339 top level 257 path @/var/cache ID 266 gen 1427487 top level 257 path @/var/crash ID 267 gen 1427487 top level 257 path @/var/lib/mailman ID 268 gen 1427487 top level 257 path @/var/lib/mariadb ID 269 gen 1427487 top level 257 path @/var/lib/mysql ID 270 gen 1427487 top level 257 path @/var/lib/named ID 271 gen 1427487 top level 257 path @/var/lib/pgsql ID 272 gen 1432392 top level 257 path @/var/log ID 273 gen 1427487 top level 257 path @/var/opt ID 274 gen 1432391 top level 257 path @/var/spool ID 275 gen 1432366 top level 257 path @/var/tmp ID 276 gen 1427487 top level 257 path @/var/lib/machines ID 1650 gen 1432304 top level 257 path @/var/lib/systemd/coredump ID 1893 gen 1432387 top level 258 path @/.snapshots/1113/snapshot ID 2158 gen 1418255 top level 258 path @/.snapshots/1271/snapshot ID 2159 gen 1424575 top level 258 path @/.snapshots/1272/snapshot ID 2163 gen 1427385 top level 258 path @/.snapshots/1273/snapshot ID 2164 gen 1429845 top level 258 path @/.snapshots/1274/snapshot ID 2165 gen 1429883 top level 258 path @/.snapshots/1275/snapshot ID 2166 gen 1429959 top level 258 path @/.snapshots/1276/snapshot ID 2167 gen 1429963 top level 258 path @/.snapshots/1277/snapshot It's listed in fstab like any other subvols. > UUID=ad544c37-37f9-44a4-9798-d29d3cb5db44 /var/tmp btrfs subvol=@/var/tmp 0 0 > UUID=ad544c37-37f9-44a4-9798-d29d3cb5db44 /.snapshots btrfs subvol=(a)/.snapshots 0 0 > UUID=ad544c37-37f9-44a4-9798-d29d3cb5db44 /var/lib/machines btrfs subvol=@/var/lib/machines 0 0 Full boot log is attached. systemd-246.13-1.1.x86_64 kernel-default-5.11.11-1.2.x86_64 libmount1-2.36.2-1.3.x86_64 util-linux-2.36.2-1.3.x86_64 The system has 8BiB RAM. It seems highly unlikely that the system went out of memory this early during boot. After boot and graphical user login, mem usage is like this: # free total used free shared buff/cache available Mem: 7897336 3457336 642880 767688 3797120 3305920 Swap: 8383484 23040 8360444 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1183990] New: I think I found the cause of a kernel lock when attempting hibernation
by bugzilla_noreply＠suse.com 10 Mar '22

10 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1183990 Bug ID: 1183990 Summary: I think I found the cause of a kernel lock when attempting hibernation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: carlos.e.r(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, For months I have been experiencing a kernel "trouble" in _some_ of my attempts to hibernate. Sometimes the hibernation would stall and not proceed. Issuing "systemctl hibernate" replied that there was one in progress, but there was no progress. I would attempt to halt the machine, but this would also stall at some point. If I pressed ctrl-alt-del several times, fast, I would see the message that it had detected the keys seven times and would halt immediately, but it did not. I had no way out but hit the power switch, and suffer the long fsck the next morning. Nothing in the logs whatsoever. Well, one day I noticed in "atop" that one of my disks went to 100% busy when this happened. So I left running another instance of gkrellm, displaying the i/o state of all my partitions in /dev/sdc, and experimenting with "sync" I noticed it was sdc9 which was active, at something like 400 Kbps. I noticed that "sync" would take sometimes a minute to complete. /dev/sdc9 is a reiserfs, and has several bind mounts: /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl) bind mounts: /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /var/spool/news type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl) Now, the directory that is active is "/var/spool/news". I use leafnode nntp proxy server. It contains 1.2 million files in about 3 GB of space. I found that if I run this sequence: time sync time sync && systemctl hibernate the machine hibernates successfully - 13 days so far, a record. Most days it takes a minute to sync, but one day, I noticed it took several minutes. Why? Well, it happened that at the same time "/usr/sbin/texpire" was working (a cronjob triggers it). This task runs for about half an hour daily expunging old posts, meaning it examines a million files. Maybe with this (tentative) report you can improve the kernel response so that it doesn't stall when trying to hibernate, assumedly when taking too long to sync. Me would think that the kernel should stop tasks before doing the sync :-? At least, running sync manually I can detect the situation and kill the busy task before suffering the crash. On the other hand, maybe there is an issue on reiserfs with "lazytime" (which is default), delaying the writes of "something" till forced to. My wild guess, it delays the timestamp that registers a file was touched. Each time I read a post, or Thunderbird scans a post, the timestamp (sorry, I don't remember which exact timestamp it is) is written, but it is not actually written but delayed "for ever". I use reiserfs for this mount because in theory it should work better than others with millions of small files. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[kernel-bugs] [Bug 1177624] New: watchdog: BUG: soft lockup - CPU#16 stuck for 23s! [qemu-system-aar:4554]
by bugzilla_noreply＠suse.com 08 Mar '22

08 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1177624 Bug ID: 1177624 Summary: watchdog: BUG: soft lockup - CPU#16 stuck for 23s! [qemu-system-aar:4554] Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- Created attachment 842562 --> http://bugzilla.opensuse.org/attachment.cgi?id=842562&action=edit dmesg.log The D05 machine used as a worker for openqa.opensuse.org have been upgraded from Leap 15.1 to Leap 15.2 and shows lots of performance problems. Lots of mistyping in qemu, few screen corruptions. Checking the kernel log (in attachment), we can see some traces related to the watchdog. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1182304] New: Integrated USB3 port / hub only works with AC adapter connected
by bugzilla_noreply＠suse.com 01 Mar '22

01 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1182304 Bug ID: 1182304 Summary: Integrated USB3 port / hub only works with AC adapter connected 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: rs.opensuse(a)spitzenpfeil.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Kernel: 5.10.12-1-default Yet again I'm having issues with my laptops integrated USB3 port / hub. One of the USB-3 + USB-C ports only works with the AC adapter plugged in. Pulling the plug with devices connected leads to stuckage. Same hardware as in: https://bugzilla.opensuse.org/show_bug.cgi?id=1167146 -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1180742] New: [amdgpu]An AMD Vega series GPU randomly crashes
by bugzilla_noreply＠suse.com 28 Feb '22

28 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180742 Bug ID: 1180742 Summary: [amdgpu]An AMD Vega series GPU randomly crashes Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: srid(a)rkmail.ru QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844970 --> http://bugzilla.opensuse.org/attachment.cgi?id=844970&action=edit partial kernel log The AMDGPU kernel driver randomly crashes GPU, usually under load, with Radeon VII hardware. The GPU hang is relatively hard to hit, as it usually takes 5 to 7 days before it crashes. After a hang it attempts to reset the GPU, but sometimes the reset fails and system stays sort of unresponsive. You can still access it over network, and there's some sort of reaction on keyboard events, but display stays dead. Also, it seems to bring PCIe bus down to 1.0 mode, and it stays that until reboot. There's an upstream bug open that may have something to do about it: https://gitlab.freedesktop.org/drm/amd/-/issues/716 That particular GPU works fine on Windows machine openSUSE Leap 15.2, kernel 5.3.18-lp152.57-default #1 SMP Fri Dec 4 07:27:58 UTC 2020 (7be5551) -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 1180380] New: Blank external monitor after resume from suspend
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1180380 Bug ID: 1180380 Summary: Blank external monitor after resume from suspend Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jack(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844706 --> https://bugzilla.suse.com/attachment.cgi?id=844706&action=edit dmesg from the system After resuming from suspend to RAM the external display connected through DVI port on the docking station remains blank. Internal display is fine. I can use xrandr to make the monitor work like: xrandr --output DP1-1 --mode some-other-mode xrandr --output DP1-1 --mode original-mode -- You are receiving this mail because: You are the assignee for the bug.

1 12