Can't suspend F23 due to mate-settings-daemon and mate-multiload-applet
by Kevin Cummings
Have anyone else noticed this?
If I boot any of the recent 4.7 kernels, I can immediately suspend my
laptop without incident. If I leave the system up for some reasonable
amount of time, then everytime I try to suspend, it fails. journalctl
shows that 2 Mate daemons refuse to Freeze:
Here is just one exert from my journal:
> Oct 26 12:43:04 kjclap4 kernel: PM: Preparing system for sleep (freeze)
> Oct 26 12:43:04 kjclap4 kernel: Freezing user space processes ...
> Oct 26 12:43:04 kjclap4 kernel: Freezing of tasks failed after 20.004 seconds (2 tasks refusing to freeze, wq_busy=0):
> Oct 26 12:43:04 kjclap4 kernel: mate-settings-d D ffff8800aed2fc20 0 1419 1192 0x00000004
> Oct 26 12:43:04 kjclap4 kernel: ffff8800aed2fc20 ffff8800aed68000 ffff880119ddba80 ffff8800aed2fc00
> Oct 26 12:43:04 kjclap4 kernel: ffff8800aed30000 ffff8800aed2fc50 ffff8800befae260 ffff880095e7c000
> Oct 26 12:43:04 kjclap4 kernel: fffffffffffffe00 ffff8800aed2fc38 ffffffffad7e0c65 ffff8800befae190
> Oct 26 12:43:04 kjclap4 kernel: Call Trace:
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e0c65>] schedule+0x35/0x80
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087879b>] request_wait_answer+0x15b/0x250 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad0e2d80>] ? wake_atomic_t_function+0x70/0x70
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b61>] __fuse_request_send+0x71/0x80 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b97>] fuse_request_send+0x27/0x30 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087be4c>] fuse_simple_request+0xcc/0x1a0 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0886251>] fuse_statfs+0xe1/0x150 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad27936c>] statfs_by_dentry+0x6c/0x90
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2793ab>] vfs_statfs+0x1b/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad279488>] user_statfs+0x58/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2794f7>] SYSC_statfs+0x27/0x60
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2796de>] SyS_statfs+0xe/0x10
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e4f72>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> Oct 26 12:43:04 kjclap4 kernel: mate-multiload- D ffff8800a8c4bc20 0 1698 1 0x00000004
> Oct 26 12:43:04 kjclap4 kernel: ffff8800a8c4bc20 ffff8800a72b3a80 ffff8800abfb1d40 ffff8800a8c4bc00
> Oct 26 12:43:04 kjclap4 kernel: ffff8800a8c4c000 ffff8800a8c4bc50 ffff8800befae0d0 ffff880095e7c000
> Oct 26 12:43:04 kjclap4 kernel: fffffffffffffe00 ffff8800a8c4bc38 ffffffffad7e0c65 ffff8800befae000
> Oct 26 12:43:04 kjclap4 kernel: Call Trace:
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e0c65>] schedule+0x35/0x80
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087879b>] request_wait_answer+0x15b/0x250 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad0e2d80>] ? wake_atomic_t_function+0x70/0x70
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b61>] __fuse_request_send+0x71/0x80 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0878b97>] fuse_request_send+0x27/0x30 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc087be4c>] fuse_simple_request+0xcc/0x1a0 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffc0886251>] fuse_statfs+0xe1/0x150 [fuse]
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad27936c>] statfs_by_dentry+0x6c/0x90
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2793ab>] vfs_statfs+0x1b/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad279488>] user_statfs+0x58/0xa0
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2794f7>] SYSC_statfs+0x27/0x60
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad2796de>] SyS_statfs+0xe/0x10
> Oct 26 12:43:04 kjclap4 kernel: [<ffffffffad7e4f72>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> Oct 26 12:43:04 kjclap4 kernel:
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: The canary thread is apparently starving. Taking action.
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Demoting known real-time threads.
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Successfully demoted thread 1545 of process 1460 (/usr/bin/pulseaudio).
> Oct 26 12:43:04 kjclap4 kernel: Restarting tasks ... done.
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Successfully demoted thread 1533 of process 1460 (/usr/bin/pulseaudio).
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Successfully demoted thread 1460 of process 1460 (/usr/bin/pulseaudio).
> Oct 26 12:43:04 kjclap4 rtkit-daemon[657]: Demoted 3 threads.
> Oct 26 12:43:04 kjclap4 kernel: video LNXVIDEO:01: Restoring backlight state
Can anyone shed some light on this? It continues through kernel 4.7.9.
(I have not yet booted 4.7.10.)
If I try and suspend, it fails, and restores the kernel to a fully
running state, usually on battery, and usually with the laptop fan
continuing to run, expelling heat into my laptop case if I don't notice it!
--
Kevin J. Cummings
kjchome(a)verizon.net
cummings(a)kjchome.homeip.net
cummings(a)kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)
7 years, 4 months
Re: WD My Passport Ultra 3T usb drive problem
by George R Goffe
Hi,
This situation sounds a lot like the problems I had when I went from 2tb drives to 3tb -> 6tb drives connected via USB 2/3 to docking stations. 2tb drives worked well. 3tb drives were all screwed up. It turns out that the firmware in the Kwin dual drive docking station could NOT support > 2tb drives. Something to do with the number of bits. I went to SIIG usb3 dual port docking stations and poof, the size of the drive didn't matter any more. The SIIG product has been removed from the market I think. Other issues: fans get noisy after a short period of time and my favorite bug. The drives in a station drop ready (for lack of a better word) under heavy i/o load. I suspect that they still draw power from the usb interface even though they are powered themselves. The drive(s) get busy, draw more power... past a threshold and the drive drops away... the system sees the drive go... i/o stops... the power draw goes down... drive comes back... possibly at a different drive letter... A REAL PAIN.
Most of my big drives are 1 partition but some have several due to performance issues with large numbers of files in a 6tb file system.
All systems are various Fedora... I'm on Fedora 25 now... still have the power drop with heavy i/o problem and the performance problem with # of files in one big partition. ext4 fs type and even tried xfs... found bugs... went back.
I guess the newer systems have usb ports with > 32bit capable interfaces (I don't think this is the right word though). The interface handles drives > 2tb is what I mean.
Hope this helps.
George...
7 years, 5 months