FS#46978 - [linux-lts] /proc/<pid>/stat reports 0 cpu usage for all tasks
Attached to Project:
Arch Linux
Opened by François Guerraz (kubrick) - Thursday, 05 November 2015, 15:53 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 16 November 2015, 12:24 GMT
Opened by François Guerraz (kubrick) - Thursday, 05 November 2015, 15:53 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 16 November 2015, 12:24 GMT
|
Details
Description:
/proc/<pid>/stat reports 0 cpu usage for all tasks leading to broken top/ps/system-monitor display and, seemingly, scheduling issues. Additional info: * 4.1.12-1-lts and 4.1.11-1-lts tried * works fine with 4.2.x Steps to reproduce: on my machine, just try to boot an lts kernel and display any process' cpu usage. |
This task depends upon
Closed by Doug Newgard (Scimmia)
Monday, 16 November 2015, 12:24 GMT
Reason for closing: Not a bug
Additional comments about closing: Faulty firmware
Monday, 16 November 2015, 12:24 GMT
Reason for closing: Not a bug
Additional comments about closing: Faulty firmware
1 (systemd) S 0 1 1 0 -1 4202752 31229 667037 47 849 277 330 15937 18222 20 0 1 0 5 43966464 1282 18446744073709551615 1 1 0 0 0 0 671173123 4096 1260 18446744073709551615 0 0 17 0 0 0 12 0 0 0 0 0 0 0 0 0 0
top/htop seem to work well here.
[andyrtr@server64 ~]$ uname -a
Linux server64 4.1.12-1-lts #1 SMP Tue Oct 27 17:21:25 CET 2015 x86_64 GNU/Linux
However, all afternoon I've been trying to make sense of it, this is what it returned for firefox for example:
2192 (firefox) S 1 1766 1766 1028 1766 4202496 711217 1982 96 0 0 0 0 0 20 0 73 0 26811 1637974016 116050 18446744073709551615 4194304 4349588 140727103555392 140727103548976 140561097208205 0 0 16781312 33572079 18446744073709551615 0 0 17 1 0 0 30 0 0 6447104 6449496 28581888 140727103556345 140727103556380 140727103556380 140727103557589 0
I'm sure you'll agree that the "0 0 0 0 0" sequence is impossible for a program like firefox.
Any suggestion on how I could provide some useful information to debug it if/when it happens again?
[francois@compute ~]$ uname -a
Linux compute 4.1.12-1-lts #1 SMP Tue Oct 27 17:21:25 CET 2015 x86_64 GNU/Linux
[francois@compute ~]$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=98a1284f-5c8c-484d-8cc1-22744f26bbea rw nomodeset quiet
F.
[francois@compute ~]$ cat /proc/$(pidof darktable)/stat
1807 (darktable) S 1 1108 1108 1026 1108 4202496 912012 355 187 0 0 0 0 0 20 0 120 0 5828 65427787776 985056 18446744073709551615 4194304 4197204 140737328101040 140737328100576 140499532743053 0 0 16781312 1024 18446744073709551615 0 0 17 5 0 0 94 0 0 6295000 6295632 20594688 140737328102227 140737328102237 140737328102237 140737328103397 0
...
I'll do more checks to see what triggers that (locking the screen?).
I have updated my BIOS/UEFI on Saturday morning to the latest beta version (F10d http://www.gigabyte.com/products/product-page.aspx?pid=5124#bios , I was using the latest stable before that)
Although the very sporadic changelog doesn't mention anything related to my problem, it looks like it has completely fixed it.
F.