[opensuse-kernel] non-Fatal kernel:stable boot warning/trace "WARNING: CPU: 1 PID: 1777 at lib/sbitmap.c:485 __sbitmap_queue_get_shallow+0x85/0xb0" ?
I'm upgrading a few older machines around here. They all: (1) Run Leap 15 (2) have Kernel:Stable installed; currently: uname -rm 5.0.5-lp150.2.g0fb0b14-default x86_64 (3) have NVidia video cards. Load the NVidia proprietary blobs, built ,for the specific kernel version nvidia-settings -v nvidia-settings: version 418.56 lsmod | grep nvidia nvidia_drm 53248 5 nvidia_modeset 1089536 12 nvidia_drm nvidia 17641472 506 nvidia_modeset drm_kms_helper 204800 1 nvidia_drm drm 499712 8 drm_kms_helper,nvidia_drm ipmi_msghandler 65536 2 ipmi_devintf,nvidia (4) all have AMD cpus Specific video cards, mobos & CPUs differ. For a couple of older machines, since ~ kernel 5.0.3 (now @ 5.0.5), I'm seeing these traces in dmesg boot logs: -------------------------------- ... [ 26.854038] systemd[1726]: Startup finished in 386ms. [ 27.438037] WARNING: CPU: 1 PID: 1777 at lib/sbitmap.c:485 __sbitmap_queue_get_shallow+0x85/0xb0 [ 27.438042] Modules linked in: xhci_pci xhci_hcd lockd grace iscsi_ibft iscsi_boot_sysfs bnep cachefiles fscache vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) hwmon_vid sch_fq_codel tcp_bbr squashfs loop nvidia_drm(POE) nvidia_modeset(POE) btusb ir_rc5_decoder rc_streamzap btrtl btbcm btintel bluetooth streamzap nvidia(POE) rc_core ecdh_generic rfkill drm_kms_helper drm edac_mce_amd kvm_amd ipmi_devintf ccp ipmi_msghandler kvm fb_sys_fops syscopyarea sysfillrect sp5100_tco sysimgblt irqbypass i2c_piix4 asus_atk0110 pcc_cpufreq acpi_cpufreq pcspkr button snd_hda_codec_hdmi snd_hda_codec_via snd_usb_audio snd_hda_codec_generic snd_usbmidi_lib ledtrig_audio snd_rawmidi snd_seq_device snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore hid_generic sr_mod cdrom usbhid raid1 md_mod ata_generic serio_raw sata_sil r8169 pata_atiixp realtek ohci_pci ohci_hcd libphy sunrpc dm_mirror dm_region_hash dm_log usbcore k10temp msr sg nbd dm_multipath dm_mod [ 27.438131] scsi_dh_rdac scsi_dh_emc scsi_dh_alua [ 27.438143] CPU: 1 PID: 1777 Comm: cp Tainted: P OE 5.0.5-lp150.2.g0fb0b14-default #1 openSUSE Tumbleweed (unreleased) [ 27.438145] Hardware name: System manufacturer System Product Name/M3A78-CM, BIOS 2801 08/23/2010 [ 27.438152] RIP: 0010:__sbitmap_queue_get_shallow+0x85/0xb0 [ 27.438157] Code: 11 48 83 c4 08 5b 5d 41 5c c3 48 8b 53 18 65 c7 02 00 00 00 00 48 83 c4 08 5b 5d 41 5c c3 31 ed 45 85 e4 75 09 65 89 28 eb 9a <0f> 0b eb 87 89 74 24 04 e8 6e c2 fa ff 31 d2 8b 74 24 04 41 f7 f4 [ 27.438160] RSP: 0018:ffffb5cf823cba28 EFLAGS: 00010282 [ 27.438164] RAX: ffff92ad6e2f8780 RBX: ffff92ad6e2f8790 RCX: ffff92ad6e2f8790 [ 27.438167] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff92ad6e2f8790 [ 27.438169] RBP: ffff92ad6e2f8790 R08: 0000000000000000 R09: 0000000000000000 [ 27.438172] R10: 0000000000001000 R11: 0000000000001000 R12: ffff92ad5fdc5400 [ 27.438175] R13: 0000000000000000 R14: ffff92ad6023e400 R15: dead000000000100 [ 27.438179] FS: 00007f196b935580(0000) GS:ffff92ad6ec40000(0000) knlGS:0000000000000000 [ 27.438181] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.438184] CR2: 000055d2b14b0368 CR3: 000000020d2b0000 CR4: 00000000000006e0 [ 27.438187] Call Trace: [ 27.438199] blk_mq_get_tag+0x260/0x2c0 [ 27.438206] ? wait_woken+0x80/0x80 [ 27.438213] blk_mq_get_request+0x108/0x420 [ 27.438217] blk_mq_make_request+0x112/0x4e0 [ 27.438222] ? generic_make_request_checks+0x2d0/0x660 [ 27.438227] generic_make_request+0x177/0x3d0 [ 27.438237] flush_bio_list+0x48/0xe0 [raid1] [ 27.438245] raid1_unplug+0xc2/0xe0 [raid1] [ 27.438250] blk_flush_plug_list+0xa1/0xd0 [ 27.438256] blk_finish_plug+0x21/0x2e [ 27.438262] ext4_writepages+0x63c/0xef0 [ 27.438268] ? ext4_set_acl+0x18c/0x1e0 [ 27.438277] ? do_writepages+0x31/0xb0 [ 27.438281] do_writepages+0x31/0xb0 [ 27.438286] ? setxattr+0x137/0x1b0 [ 27.438293] ? _copy_to_user+0x26/0x30 [ 27.438298] __filemap_fdatawrite_range+0xa0/0xd0 [ 27.438304] ext4_release_file+0x6c/0xa0 [ 27.438311] __fput+0xb4/0x230 [ 27.438317] task_work_run+0x9f/0xc0 [ 27.438324] exit_to_usermode_loop+0xf5/0x100 [ 27.438330] do_syscall_64+0xe2/0x110 [ 27.438336] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 27.438342] RIP: 0033:0x7f196ae5d354 [ 27.438346] Code: eb 89 e8 0f fa 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 da f4 2c 00 48 63 ff 85 c0 75 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 f3 c3 66 90 48 83 ec 18 48 89 7c 24 08 e8 [ 27.438348] RSP: 002b:00007ffd8206c578 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 27.438352] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00007f196ae5d354 [ 27.438354] RDX: 000055e0356e6020 RSI: 0000000000000002 RDI: 0000000000000004 [ 27.438357] RBP: 00007ffd8206c950 R08: 0000000000000000 R09: 0000000000000001 [ 27.438359] R10: 00000000000006b4 R11: 0000000000000246 R12: 00007ffd8206cb30 [ 27.438362] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffd8206ef08 [ 27.438367] ---[ end trace eab731cf613cea20 ]--- [ 32.772490] systemd[1]: Created slice User Slice of sddm. ... -------------------------------- It _appears_ this has to do with the 'blk_mq' code. I'm apparently not alone: https://www.google.com/search?q=+__sbitmap_queue_get_shallow%2B0x85%2F0xb0 It's not fatal; boot completes without further noticed problem. Fwiw, my cmd line includes: "... scsi_mod.use_blk_mq=1 elevator=bfq ..." AND I've got this udev rule in place: cat /etc/udev/rules.d/60-sched.rules # set deadline scheduler for non-rotating disks ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline" # set deadline scheduler for rotating disks ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq" Comments from IRC##kernel, " ... __sbitmap_queue_get_shallow was called by blk_mq_get_tag, which was called by wait_token (i'm not sure what the question mark means so i'm not sure about this), which was called by blk_mq_get_request, etc. ... it's probably best to ask in the support channel's of your kernel's provider (which seems to be openSUSE) ... " Is this issue known, &/or unique, to Opensuse kernel? I'm certainly no expert on kernel/schedule debugging :-/ I can provide additional info on specific request.
participants (1)
-
PGNet Dev