Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Is DMESG trace report significant?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
ipic
Apprentice
Apprentice


Joined: 29 Dec 2003
Posts: 298
Location: UK

PostPosted: Mon Apr 13, 2020 6:00 pm    Post subject: Is DMESG trace report significant? Reply with quote

Since changing motherboard, cpu and main memory recently, I've been paying a lot more attention to DMESG contents. Having sorted out all the various niggles, and got UEFI mode booting working (first time ever, I'm so proud of myself :-) ), I have noticed that this snippet is appearing consistently at every boot, in the same place in DMESG output:
Code:

[    0.764837] NetLabel:  unlabeled traffic allowed by default
[    0.764841] ------------[ cut here ]------------
[    0.764841] !bucket->tasks
[    0.764841] WARNING: CPU: 10 PID: 218 at kernel/sched/core.c:1000 deactivate_task+0x215/0x350
[    0.764841] Modules linked in:
[    0.764841] CPU: 10 PID: 218 Comm: watchdogd Not tainted 5.6.4-gentoo #1
[    0.764841] Hardware name: System manufacturer System Product Name/ROG STRIX B450-F GAMING, BIOS 2901 10/16/2019
[    0.764841] RIP: 0010:deactivate_task+0x215/0x350
[    0.764841] Code: ff 80 3d 2a 42 89 01 00 0f 85 dc fe ff ff 48 c7 c7 75 07 fa 94 48 89 54 24 08 89 4c 24 04 c6 05 0d 42 89 01 01 e8 5b 0a fd ff <0f> 0b 48 8b 54 24 08 48 63 4c 24 04 48 f7 42 48 00 f8 ff ff 0f 84
[    0.764841] RSP: 0018:ffffb8d24070be18 EFLAGS: 00010086
[    0.764841] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[    0.764841] RDX: 0000000000000003 RSI: ffffffff959b50ee RDI: 00000000ffffffff
[    0.764841] RBP: ffff952fd84b96c0 R08: ffffffff959b50e0 R09: 000000000000000e
[    0.764841] R10: 0000000000000000 R11: 0720072007200720 R12: ffff952fdeaa2680
[    0.764841] R13: 0000000000000009 R14: 0000000000000000 R15: ffff952fdeaa26c0
[    0.764841] FS:  0000000000000000(0000) GS:ffff952fdea80000(0000) knlGS:0000000000000000
[    0.764841] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.764841] CR2: 0000000000000000 CR3: 000000089540a000 CR4: 00000000003406e0
[    0.764841] Call Trace:
[    0.764841]  __schedule+0xea/0x6c0
[    0.764841]  ? __switch_to_asm+0x40/0x70
[    0.764841] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.764841] hpet0: 3 comparators, 32-bit 14.318180 MHz counter
[    0.764841]  schedule+0x41/0xf0
[    0.764841]  kthread_worker_fn+0x114/0x1a0
[    0.764841]  kthread+0xf1/0x130
[    0.764841]  ? __kthread_init_worker+0x50/0x50
[    0.764841]  ? kthread_park+0x80/0x80
[    0.764841]  ret_from_fork+0x22/0x40
[    0.764841] ---[ end trace bede0dc6d748a59a ]---
[    0.766703] clocksource: Switched to clocksource tsc-early
[    0.766763] VFS: Disk quotas dquot_6.6.0


An educated guess by me would be that this is something to do with the clock source. This comes from the two hpet lines at the top of the trace, and the fact that the next "valid" DMESG entry says "clocksource: Switched to clocksource tsc-early". However, I've been wrong before. (Often, actually.)

The "[ cut here ]" bit implies to me that someone would like this reported, but there are no instructions to do so that I can find anywhere.
I cannot see any adverse effect in the running system - all is well and functioning.

My question is whether I should just ignore this, and if not, could anyone give me some pointers on what to do?

Many thanks.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6491

PostPosted: Mon Apr 13, 2020 7:54 pm    Post subject: Reply with quote

Looking at the source it seems like a harmless warning for a rare edge condition, though I can't say why it's triggering it in the first place. But if you want it to go away try changing CONFIG_UCLAMP_BUCKETS_COUNT.
Back to top
View user's profile Send private message
ipic
Apprentice
Apprentice


Joined: 29 Dec 2003
Posts: 298
Location: UK

PostPosted: Tue Apr 14, 2020 6:53 pm    Post subject: Reply with quote

Many thanks for the suggestion.

I had a good read of all the help around UCLAMP, and decided to disable it all, so now I have:
Code:
an2 ~ # zcat /proc/config.gz | grep UCLAMP
# CONFIG_UCLAMP_TASK is not set
ian2 ~ #


On the following reboot the trace output in DMESG does not appear. So the two would appear top be related.

I said I read all the help around UCLAMP - I can't say I fully understood it, or the implications of not having it. So I'll monitor this system for any new or odd behaviours for a while.

Thanks again.
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6491

PostPosted: Tue Apr 14, 2020 7:07 pm    Post subject: Reply with quote

It's an optional feature meant to make the system run more deterministically under load. If you're not doing live audio work you probably don't need it.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum