Re: [arch-general] short hangs
On Wed, Jul 3, 2013 at 10:13 PM, Scott Lawrence byt...@gmail.com wrote: My experience is that freezes are almost always associated with the hard drive having spun down, and needing to spin up before something can be read from the disk. (It just happened, as I was typing that sentence.) Tweak power settings to make spin-downs more rare, or banish them altogether if you're willing to take a minor hit to power consumption. I run the laptop from AC power almost all the time, so I disabled most of the powersafer stuff that would hit the performance. The HDD never spins down, but even if it does, the arch system is on an SSD. I have to emphasis, the system itself remains perfectly responsive. If music plays in the background, I can start/stop with keyboard shortcuts and it responds instatnly. Only the picture freezes, and even then the mousecursos moves smoothly! This is not a system-responsiveness bug. -- János
Re: [arch-general] short hangs
On 2013-07-04 01:23:00, coderkun wrote: Date: Thu, 04 Jul 2013 01:23:00 +0200 From: coderkun o...@coderkun.de To: arch-general@archlinux.org Subject: Re: [arch-general] short hangs X-Mailer: Evolution 3.8.3 Am Mittwoch, den 03.07.2013, 16:13 -0400 schrieb Scott Lawrence: My experience is that freezes are almost always associated with the hard drive having spun down, and needing to spin up before something can be read from the disk. (It just happened, as I was typing that sentence.) Tweak power settings to make spin-downs more rare, or banish them altogether if you're willing to take a minor hit to power consumption. This my experience, too. I had similar symtoms on my machine and suspected the Gnome-Shell. But then I found out that my harddrive doesn’t support the “min_power” policy (only “medium_power”) which I had activated through an udev rule. I have the almost same issue about several months. When this happen, ssh to the machine and run cat /proc/`pidof X`/stack, it shows that the X sever has been stucked. For me, it will last about 3--5 minutes. This bug has been reported to freedesktop: https://bugs.freedesktop.org/show_bug.cgi?id=65276 [a050d83c] radeon_fence_wait_seq+0x1dc/0x600 [radeon] [a050e26b] radeon_fence_wait+0x2b/0x60 [radeon] [a050e941] radeon_sync_obj_wait+0x11/0x20 [radeon] [a046b811] ttm_bo_wait+0x91/0x190 [ttm] [a046eefc] ttm_bo_move_accel_cleanup+0x9c/0x350 [ttm] [a050ee22] radeon_move_blit.isra.7+0xc2/0x160 [radeon] [a050f70a] radeon_bo_move+0xaa/0x1e0 [radeon] [a046d065] ttm_bo_handle_move_mem+0x255/0x5f0 [ttm] [a046d592] ttm_bo_evict+0x192/0x360 [ttm] [a046d8be] ttm_mem_evict_first+0x15e/0x200 [ttm] [a046dc11] ttm_bo_mem_space+0x2b1/0x360 [ttm] [a046e26a] ttm_bo_move_buffer+0xca/0x150 [ttm] [a046e38a] ttm_bo_validate+0x9a/0x110 [ttm] [a046e6b9] ttm_bo_init+0x2b9/0x3d0 [ttm] [a0510160] radeon_bo_create+0x180/0x250 [radeon] [a0521f9b] radeon_gem_object_create+0x9b/0x160 [radeon] [a05223b0] radeon_gem_create_ioctl+0x60/0x140 [radeon] [a03fb1c1] drm_ioctl+0x4d1/0x580 [drm] [8119d135] do_vfs_ioctl+0x2e5/0x4d0 [8119d3a1] sys_ioctl+0x81/0xa0 [814da1dd] system_call_fastpath+0x1a/0x1f [] 0x Maybe my info can help the community Regards, coderkun
Re: [arch-general] short hangs
On Thu, Jul 4, 2013 at 1:23 AM, coderkun o...@coderkun.de wrote: This my experience, too. I had similar symtoms on my machine and suspected the Gnome-Shell. But then I found out that my harddrive doesn’t support the “min_power” policy (only “medium_power”) which I had activated through an udev rule. Again, this is an SSD. But never heard of this one so I checked this policy: cat /sys/class/scsi_host/host*/link_power_management_policy max_performance max_performance max_performance max_performance max_performance max_performance -- János
Re: [arch-general] short hangs
On Wed, Jul 3, 2013 at 11:09 AM, János Illés ija...@gmail.com wrote: Here's the symptoms: Everything freeze. It takes 5-15 seconds and everything goes back to normal. But, the freeze is only visual, sound/music playback works continously, I can ssh to the machine, even the mouse moves and changes (!) accordingly if I hover something. Only the displayed content freezes, sometimes in the middle of an animation. I would check cpupower, laptop-mode-tools, or other power-saving tools; I have the same thing happen on my system, but only when running on battery when all the power-saving stuff is active. Regards, ~Celti
Re: [arch-general] short hangs
On Wed, 3 Jul 2013, Patrick Burroughs (Celti) wrote: On Wed, Jul 3, 2013 at 11:09 AM, János Illés ija...@gmail.com wrote: Here's the symptoms: Everything freeze. It takes 5-15 seconds and everything goes back to normal. But, the freeze is only visual, sound/music playback works continously, I can ssh to the machine, even the mouse moves and changes (!) accordingly if I hover something. Only the displayed content freezes, sometimes in the middle of an animation. I would check cpupower, laptop-mode-tools, or other power-saving tools; I have the same thing happen on my system, but only when running on battery when all the power-saving stuff is active. My experience is that freezes are almost always associated with the hard drive having spun down, and needing to spin up before something can be read from the disk. (It just happened, as I was typing that sentence.) Tweak power settings to make spin-downs more rare, or banish them altogether if you're willing to take a minor hit to power consumption. -- Scott Lawrence Linux baidar 3.9.7-1-ARCH #1 SMP PREEMPT Thu Jun 20 22:45:32 CEST 2013 x86_64 GNU/Linux
Re: [arch-general] short hangs
Am Mittwoch, den 03.07.2013, 16:13 -0400 schrieb Scott Lawrence: My experience is that freezes are almost always associated with the hard drive having spun down, and needing to spin up before something can be read from the disk. (It just happened, as I was typing that sentence.) Tweak power settings to make spin-downs more rare, or banish them altogether if you're willing to take a minor hit to power consumption. This my experience, too. I had similar symtoms on my machine and suspected the Gnome-Shell. But then I found out that my harddrive doesn’t support the “min_power” policy (only “medium_power”) which I had activated through an udev rule. Regards, coderkun
