Description of problem: Unexpected system error as a result of running "powertop --auto-tune" under kernel-core-4.20.8-200.fc29. N.B. The same powertop has worked perfectly with earlier releases of the kernel. On the gnome terminal that ran powertop, it leaves various messages untidily laid out (probably lacking carriage returns) relating to powertop and memory mapping (if I remember rightly), then leaves the said terminal unresponsive.. What follows is what ABRT reports. The backtrace does not contain enough meaningful function frames to be reported. It is annoying, but it does not necessary signalise a problem with your computer. ABRT will not allow you to create a report in a bug tracking system, but you can contact kernel maintainers via e-mail. traps: powertop[3065] general protection fault ip:557a58e3d55b sp:7ffe78743840 error:0 in powertop[557a58e03000+5d000] BOOT_IMAGE=/boot/vmlinuz-4.20.8-200.fc29.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet resume=/dev/mapper/fedora-swap xhci_hcd.quirks=262144 LANG=en_GB.UTF-8 Version-Release number of selected component (if applicable): kernel-core-4.20.8-200.fc29 when powertop from package powertop-2.9-9.fc29 is run. powertop crashes with powertop killed by SIGSEGV powertop has never crashed with previous kernel releases. How reproducible: Steps to Reproduce: 1. Boot from kernel vmlinuz-4.20.8-200.fc29.x86_64 2. Run powertop --auto-tune from a terminal window 3. Actual results: System. System failure. Unexpected system error. powertop. Application crash. powertop quit unexpectedly. Expected results: Should all work fine as with previous kernel releases. It is fine with kernel vmlinuz-4.20.7-200.fc29.x86_64 and previous kernels. Additional info: Workaround: Go back to using kernel vmlinuz-4.20.7-200.fc29.x86_64.
This appears to be the same bug, so I suggest changing the component to "powertop": Bug 1677895 - [abrt] powertop: perf_event::process(): powertop killed by SIGSEGV
However, I suspect, because of the fact that powertop is fine with all earlier kernel releases, plus the fact that the gnome terminal became unresponsive (I had to close it and open a new one), that the problem lies with kernel 4.20.8 and NOT with powertop. I am currently using kernel 4.20.7, and there is no problem running powertop (nor any earlier kernel releases). My opinion is that this is a regression in kernel 4.20.8.
(In reply to Daibhidh from comment #2) > However, I suspect, because of the fact that powertop is fine with all > earlier kernel releases, plus the fact that the gnome terminal became > unresponsive (I had to close it and open a new one), that the problem lies > with kernel 4.20.8 and NOT with powertop. I am currently using kernel > 4.20.7, and there is no problem running powertop (nor any earlier kernel > releases). My opinion is that this is a regression in kernel 4.20.8. OK. There appears to be two bugs. See: Bug 1677858 - powertop crash 1. Powertop is crashing when a file is missing. 2. The file /sys/bus/i2c/devices/i2c-5/power/runtime_suspended_time is missing. Could you post the output from this command for both 4.20.7 and 4.20.8: # ls /sys/bus/i2c/devices/i2c*/power/
I reproduced the problem with: $ uname -r 4.20.8-100.fc28.x86_64 $ rpm -q powertop powertop-2.9-8.fc28.x86_64 # strace -o powertop-1.strace powertop # tail -10 powertop-1.strace close(63) = 0 openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-3/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-1/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-6/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-4/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-2/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-0/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/sys/bus/i2c/devices/i2c-5/power/runtime_suspended_time", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} --- +++ killed by SIGSEGV (core dumped) +++
After installing symbols: # gdb powertop ... (gdb) run ... Program received signal SIGSEGV, Segmentation fault. 0x000055555559967b in perf_event::process (this=0x5555557f4bb0, cookie=cookie@entry=0x5555557f4ca0) at perf/perf.cpp:233 233 if (perf_fd < 0) (gdb) bt #0 0x000055555559967b in perf_event::process (this=0x5555557f4bb0, cookie=cookie@entry=0x5555557f4ca0) at perf/perf.cpp:233 #1 0x000055555559a3f1 in perf_bundle::process (this=0x5555557f4c50) at perf/perf_bundle.cpp:326 #2 0x0000555555573625 in process_cpu_data () at cpu/cpu.cpp:1024 #3 0x000055555556da3a in one_measurement (seconds=-4, sample_interval=<optimized out>, workload=0x0) at main.cpp:254 #4 0x000055555556365f in main (argc=1, argv=0x7fffffffe3a8) at main.cpp:538 (gdb) l 228 229 void perf_event::process(void *cookie) 230 { 231 struct perf_event_header *header; 232 233 if (perf_fd < 0) 234 return; 235 236 while (pc->data_tail != pc->data_head ) { 237 while (pc->data_tail >= (unsigned int)bufsize * getpagesize()) (gdb) print perf_fd $1 = 55 (gdb)
I suggest you update the bug summary to mention "powertop": "powertop SIGSEGV with 4.20.8, but not with 4.20.7"
(In reply to Steve from comment #3) > (In reply to Daibhidh from comment #2) > > However, I suspect, because of the fact that powertop is fine with all > > earlier kernel releases, plus the fact that the gnome terminal became > > unresponsive (I had to close it and open a new one), that the problem lies > > with kernel 4.20.8 and NOT with powertop. I am currently using kernel > > 4.20.7, and there is no problem running powertop (nor any earlier kernel > > releases). My opinion is that this is a regression in kernel 4.20.8. > > OK. There appears to be two bugs. See: > > Bug 1677858 - powertop crash > > 1. Powertop is crashing when a file is missing. > > 2. The file /sys/bus/i2c/devices/i2c-5/power/runtime_suspended_time is > missing. > > Could you post the output from this command for both 4.20.7 and 4.20.8: > > # ls /sys/bus/i2c/devices/i2c*/power/ Here are my results from doing the above command for both kernels. [root@dels-and-daves-notebook bugzilla]# more 4.20.7 /sys/bus/i2c/devices/i2c-0/power/: /sys/bus/i2c/devices/i2c-1/power/: /sys/bus/i2c/devices/i2c-2/power/: /sys/bus/i2c/devices/i2c-3/power/: /sys/bus/i2c/devices/i2c-4/power/: /sys/bus/i2c/devices/i2c-5/power/: /sys/bus/i2c/devices/i2c-6/power/: /sys/bus/i2c/devices/i2c-7/power/: [root@dels-and-daves-notebook bugzilla]# more 4.20.8 /sys/bus/i2c/devices/i2c-0/power/: /sys/bus/i2c/devices/i2c-1/power/: /sys/bus/i2c/devices/i2c-2/power/: /sys/bus/i2c/devices/i2c-3/power/: /sys/bus/i2c/devices/i2c-4/power/: /sys/bus/i2c/devices/i2c-5/power/: /sys/bus/i2c/devices/i2c-6/power/: /sys/bus/i2c/devices/i2c-7/power/: [root@dels-and-daves-notebook bugzilla]# diff 4.20.7 4.20.8 [root@dels-and-daves-notebook bugzilla]# As far as I can tell, both are identical, and both have "/sys/bus/i2c/devices/i2c-5/power/runtime_suspended_time" missing.
(In reply to Daibhidh from comment #2) > However, I suspect, because of the fact that powertop is fine with all > earlier kernel releases, plus the fact that the gnome terminal became > unresponsive (I had to close it and open a new one), that the problem lies > with kernel 4.20.8 and NOT with powertop. I am currently using kernel > 4.20.7, and there is no problem running powertop (nor with any earlier kernel > releases). My opinion is that this is a regression in kernel 4.20.8.
(In reply to Steve from comment #5) > After installing symbols: > > # gdb powertop > ... > (gdb) run > ... > Program received signal SIGSEGV, Segmentation fault. > 0x000055555559967b in > perf_event::process (this=0x5555557f4bb0, > cookie=cookie@entry=0x5555557f4ca0) at perf/perf.cpp:233 > 233 if (perf_fd < 0) > (gdb) bt > #0 0x000055555559967b in perf_event::process (this=0x5555557f4bb0, > cookie=cookie@entry=0x5555557f4ca0) at perf/perf.cpp:233 > #1 0x000055555559a3f1 in perf_bundle::process (this=0x5555557f4c50) at > perf/perf_bundle.cpp:326 > #2 0x0000555555573625 in process_cpu_data () at cpu/cpu.cpp:1024 > #3 0x000055555556da3a in one_measurement (seconds=-4, > sample_interval=<optimized out>, workload=0x0) at main.cpp:254 > #4 0x000055555556365f in main (argc=1, argv=0x7fffffffe3a8) at main.cpp:538 > (gdb) l > 228 > 229 void perf_event::process(void *cookie) > 230 { > 231 struct perf_event_header *header; > 232 > 233 if (perf_fd < 0) > 234 return; > 235 > 236 while (pc->data_tail != pc->data_head ) { > 237 while (pc->data_tail >= (unsigned int)bufsize * getpagesize()) > (gdb) print perf_fd > $1 = 55 > (gdb) I get a shorter version of the above (presumably shorter because of lack of symbols) when I run powertop under 4.20.8 ... Program received signal SIGSEGV, Segmentation fault. 0x000055555559a55b in perf_event::process (this=0x555555732050, cookie=cookie@entry=0x555555732140) at perf/perf.cpp:233 233 if (perf_fd < 0) (gdb)
(In reply to Daibhidh from comment #9) > (In reply to Steve from comment #5) > > After installing symbols: > > > > # gdb powertop > > ... > > (gdb) run > > ... > > Program received signal SIGSEGV, Segmentation fault. > > 0x000055555559967b in > > perf_event::process (this=0x5555557f4bb0, > > cookie=cookie@entry=0x5555557f4ca0) at perf/perf.cpp:233 > > 233 if (perf_fd < 0) > > (gdb) bt > > #0 0x000055555559967b in perf_event::process (this=0x5555557f4bb0, > > cookie=cookie@entry=0x5555557f4ca0) at perf/perf.cpp:233 > > #1 0x000055555559a3f1 in perf_bundle::process (this=0x5555557f4c50) at > > perf/perf_bundle.cpp:326 > > #2 0x0000555555573625 in process_cpu_data () at cpu/cpu.cpp:1024 > > #3 0x000055555556da3a in one_measurement (seconds=-4, > > sample_interval=<optimized out>, workload=0x0) at main.cpp:254 > > #4 0x000055555556365f in main (argc=1, argv=0x7fffffffe3a8) at main.cpp:538 > > (gdb) l > > 228 > > 229 void perf_event::process(void *cookie) > > 230 { > > 231 struct perf_event_header *header; > > 232 > > 233 if (perf_fd < 0) > > 234 return; > > 235 > > 236 while (pc->data_tail != pc->data_head ) { > > 237 while (pc->data_tail >= (unsigned int)bufsize * getpagesize()) > > (gdb) print perf_fd > > $1 = 55 > > (gdb) > > > I get a shorter version of the above (presumably shorter because of lack of > symbols) when I run powertop under 4.20.8 ... > > Program received signal SIGSEGV, Segmentation fault. > 0x000055555559a55b in > perf_event::process (this=0x555555732050, > cookie=cookie@entry=0x555555732140) at perf/perf.cpp:233 > 233 if (perf_fd < 0) > (gdb) But when I do gdb powertop then (gdb) r --auto-tune Starting program: /usr/sbin/powertop --auto-tune Missing separate debuginfos, use: dnf debuginfo-install glibc-2.28-26.fc29.x86_64 warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [Detaching after fork from child process 6559] modprobe cpufreq_stats failed[Detaching after fork from child process 6561] Loaded 750 prior measurements RAPL device for cpu 0 RAPL Using PowerCap Sysfs : Domain Mask f RAPL device for cpu 0 RAPL Using PowerCap Sysfs : Domain Mask f Devfreq not enabled glob returned GLOB_ABORTED failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) failed to mmap with 12 (Cannot allocate memory) Program received signal SIGSEGV, Segmentation fault. 0x000055555559a55b in perf_event::process (this=0x555555732050, cookie=cookie@entry=0x555555732140) at perf/perf.cpp:233 233 if (perf_fd < 0) (gdb) There are many memory map failure messages also. Oddly enough, there is no corresponding system failure tied to this, but there have been two system failures earlier today from kernel 4.20.8 recorded in abrt problem reporting ... traps: powertop[1015] general protection fault ip:55606256055b sp:7ffebd684800 error:0 in powertop[556062526000+5d000]
i try using kernel 4.20.10 in testing and on arch too same issue i am facing i think it is fixed in mainline kernel or 4.20.11 https://bbs.archlinux.org/viewtopic.php?id=244225
(In reply to Rai from comment #11) > i try using kernel 4.20.10 in testing and on arch too same issue i am facing > i think it is fixed in mainline kernel or 4.20.11 > > https://bbs.archlinux.org/viewtopic.php?id=244225 Thanks. The commit in the kernel git stable repo is here: perf/core: Fix impossible ring-buffer sizes warning https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.20.y&id=d26f63553b274355a18c515b891927b916beeba5 From the git log, the commit is in v4.20.11. Fedora updates have been submitted for testing: F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7bdeed7fc5 F28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-16de0047d4
(In reply to Steve from comment #12) > (In reply to Rai from comment #11) > > i try using kernel 4.20.10 in testing and on arch too same issue i am facing > > i think it is fixed in mainline kernel or 4.20.11 > > > > https://bbs.archlinux.org/viewtopic.php?id=244225 > > Thanks. The commit in the kernel git stable repo is here: > > perf/core: Fix impossible ring-buffer sizes warning > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/ > ?h=linux-4.20.y&id=d26f63553b274355a18c515b891927b916beeba5 > > From the git log, the commit is in v4.20.11. Fedora updates have been > submitted for testing: > > F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7bdeed7fc5 > F28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-16de0047d4 I have installed kernel 4.20.11 from koji, and can confirm that segmentation violation (happened with # powertop) and memory mapping failure messages + segmentation violation (happened with # powertop --auto-tune) do not occur with this kernel, and the system message System. System failure. Unexpected system error and the subsequent unresponsive gnome terminal do not occur with this kernel. Running powertop under gdb now produces [root@dels-and-daves-notebook ~]# gdb powertop GNU gdb (GDB) Fedora 8.2-6.fc29 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from powertop...Reading symbols from /usr/lib/debug/usr/sbin/powertop-2.9-9.fc29.x86_64.debug...done. done. (gdb) r --auto-tune Starting program: /usr/sbin/powertop --auto-tune warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [Detaching after fork from child process 4898] modprobe cpufreq_stats failed[Detaching after fork from child process 4900] Loaded 750 prior measurements RAPL device for cpu 0 RAPL Using PowerCap Sysfs : Domain Mask f RAPL device for cpu 0 RAPL Using PowerCap Sysfs : Domain Mask f Devfreq not enabled glob returned GLOB_ABORTED Leaving PowerTOP [Inferior 1 (process 4888) exited normally] (gdb) q However ls /sys/bus/i2c/devices/i2c*/power/ still shows empty directories, which I take may be relevant to some other problem. /sys/bus/i2c/devices/i2c-0/power/: /sys/bus/i2c/devices/i2c-1/power/: /sys/bus/i2c/devices/i2c-2/power/: /sys/bus/i2c/devices/i2c-3/power/: /sys/bus/i2c/devices/i2c-4/power/: /sys/bus/i2c/devices/i2c-5/power/: /sys/bus/i2c/devices/i2c-6/power/: /sys/bus/i2c/devices/i2c-7/power/: So, the problem reported here appears fixed for me in kernel 4.20.11, so thanks for that.
(In reply to Daibhidh from comment #13) ... > I have installed kernel 4.20.11 from koji, and can confirm that segmentation > violation (happened with # powertop) and memory mapping failure messages + > segmentation violation (happened with # powertop --auto-tune) do not occur > with this kernel, > and the system message > System. System failure. Unexpected system error > and the subsequent unresponsive gnome terminal > do not occur with this kernel. Thanks for testing. > Running powertop under gdb now produces ... > However > ls /sys/bus/i2c/devices/i2c*/power/ > still shows empty directories, which I take may be relevant to some other > problem. ... OK. Those empty directories appear to have been a red herring. And you were right -- it was a kernel problem. :-) > So, the problem reported here appears fixed for me in kernel 4.20.11, so > thanks for that. If you want to, you could post karma here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7bdeed7fc5
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora XX has now been rebased to 5.0.6 Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
(In reply to Laura Abbott from comment #15) > We apologize for the inconvenience. There is a large number of bugs to go > through and several of them have gone stale. Due to this, we are doing a > mass bug update across all of the Fedora 29 kernel bugs. > > Fedora XX has now been rebased to 5.0.6 Please test this kernel update (or > newer) and let us know if you issue has been resolved or if it is still > present with the newer kernel. > > If you have moved on to Fedora 30, and are still experiencing this issue, > please change the version to Fedora 30. > > If you experience different issues, please open a new bug report for those. I did state in comment #13 that the problem appeared fixed in kernel 4.20.11, and also posted karma as suggested by Steve in comment #14. I can also state that the problem has not recurred since, that is, up to and including kernel 5.0.6-200.fc29.x86_64 :-).
thanks for letting us know