https://bugzilla.suse.com/show_bug.cgi?id=1189283
Bug ID: 1189283
Summary: kernel-obs-build needs af_alg
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: fvogt(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
libkcapi got updated to 1.3.1 (https://build.opensuse.org/request/show/910806)
and apparently gnutls picks that up now and enables support for it.
It seems like that depends on AF_ALG sockets though, which are currently not
enabled in kernel-obs-build (missing af_alg module), so various builds (libzip,
libvirt) fail with
libkcapi - Error: AF_ALG: socket syscall failed (errno: -97)
I'm not sure whether just af_alg is enough, it might need some other modules as
well.
--
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=1189791
Bug ID: 1189791
Summary: btrfs filesystem corruptions with HyperPAV
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: S/390-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: azouhr(a)opensuse.org
QA Contact: qa-bugs(a)suse.de
CC: ada.lovelace(a)gmx.de
Found By: ---
Blocker: ---
For a proof of concept, I created a machine with 22 3390-54 Disks attached to a
single btrfs, cylinder 0 excluded as minidisks. This happened in certain junks
of disks (at least 4 at a time). After adding devices, I always did a rebalance
of the btrfs.
When I added disk 15-18, I also enabled hyperpav (without cylinder 0 on the
base devices) as available as feature for z/VM 7.2 (feature also has been added
to z/VM). The definition looks like this in the directory:
COMMAND DEFINE HYPERPAVALIAS 01C0 FOR BASE 0100
I also added alias devices at addresses 01C1-01C7.
However, later on when copying data from that disk, I found quite a number of
corruptions within btrfs. After a while the server even crashed, and is now
running without hyperpav. Corruptions that already happened are obviously still
there, but besides that, the system works without the hangs I experienced
before.
By chance (don't think that would be the issue), the first disk with
corruptions is the 16th disk in the system (including the system disk). And
while thinking about this, the disk with number 100 has not been enabled on the
system, although all disks are defined to the same control unit. HyperPAV has
been used during rebalance of the last 8 disks because dasdstat displayed
workload on the PAV device.
# btrfs device stats /srv | grep corruption_errs
[/dev/dasdb1].corruption_errs 0
[/dev/dasdc1].corruption_errs 0
[/dev/dasdd1].corruption_errs 0
[/dev/dasde1].corruption_errs 0
[/dev/dasdk1].corruption_errs 0
[/dev/dasdj1].corruption_errs 0
[/dev/dasdh1].corruption_errs 0
[/dev/dasdm1].corruption_errs 0
[/dev/dasdf1].corruption_errs 0
[/dev/dasdg1].corruption_errs 0
[/dev/dasdl1].corruption_errs 0
[/dev/dasdi1].corruption_errs 0
[/dev/dasdn1].corruption_errs 0
[/dev/dasdo1].corruption_errs 0
[/dev/dasdp1].corruption_errs 331
[/dev/dasdq1].corruption_errs 303
[/dev/dasds1].corruption_errs 302
[/dev/dasdv1].corruption_errs 399
[/dev/dasdr1].corruption_errs 356
[/dev/dasdt1].corruption_errs 206
[/dev/dasdw1].corruption_errs 279
[/dev/dasdu1].corruption_errs 218
# dmesg | tail
[ 6616.004750] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off
1818624 csum 0x8941f998 expected csum 0x99cae683 mirror 1
[ 6616.004755] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0,
flush 0, corrupt 401, gen 0
[ 6616.005008] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off
3637248 csum 0x8941f998 expected csum 0xe55a18c7 mirror 1
[ 6616.005013] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0,
flush 0, corrupt 402, gen 0
[ 6616.005238] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off
1818624 csum 0x8941f998 expected csum 0x99cae683 mirror 1
[ 6616.005244] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0,
flush 0, corrupt 403, gen 0
[ 6616.005513] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off
1818624 csum 0x8941f998 expected csum 0x99cae683 mirror 1
[ 6616.005565] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0,
flush 0, corrupt 404, gen 0
[ 6616.882699] BTRFS warning (device dasdb1): csum failed root 5 ino 40224 off
10055680 csum 0x8941f998 expected csum 0x26222530 mirror 1
[ 6616.882715] BTRFS error (device dasdb1): bdev /dev/dasdu1 errs: wr 0, rd 0,
flush 0, corrupt 249, gen 0
# uname -a
Linux zlxusr1020 5.12.12-1-default #1 SMP Fri Jun 18 11:07:46 UTC 2021
(0e46a2c) s390x s390x s390x GNU/Linux
--
You are receiving this mail because:
You are the assignee for the bug.
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.
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.
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.
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.
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.
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.