users November 2016

users@lists.fedoraproject.org

151 participants
152 discussions

Can't suspend F23 due to mate-settings-daemon and mate-multiload-applet
by Kevin Cummings 01 Nov '16

01 Nov '16

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/)

1 0

Re: WD My Passport Ultra 3T usb drive problem
by George R Goffe 01 Nov '16

01 Nov '16

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...

1 0

Jump to page: