Hi, my system has some annoying visual glitches and I have no idea how to determine which software is causing it. 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. There is nothing in the journal, nothing in dmesg, no spikes in the CPU usage, no IO spikes. And it happens rarely, only 5-10 times a day. My guess would be a gnome-shell or an open source radeon driver bug, but how can I be sure or test it? Bisecting package versions is nearly impossible, there are too many of them and I cannot reproduce the freeze, it just happens. I hoped it would go away but it is happening for more than a month now, and according to my searches no other arch user experience similar issue. I'm open to ideas. My full hardware spec is here: https://gist.github.com/ijanos/5a84c0c40d58410a87d7 -- János
On Wed, Jul 3, 2013 at 11:09 AM, János Illés <ijanos@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
On Wed, 3 Jul 2013, Patrick Burroughs (Celti) wrote:
On Wed, Jul 3, 2013 at 11:09 AM, János Illés <ijanos@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
On Wed, Jul 3, 2013 at 10:13 PM, Scott Lawrence <bytbox@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
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
On 2013-07-04 01:23:00, coderkun wrote:
Date: Thu, 04 Jul 2013 01:23:00 +0200 From: coderkun <olli@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 [<ffffffffa050d83c>] radeon_fence_wait_seq+0x1dc/0x600 [radeon] [<ffffffffa050e26b>] radeon_fence_wait+0x2b/0x60 [radeon] [<ffffffffa050e941>] radeon_sync_obj_wait+0x11/0x20 [radeon] [<ffffffffa046b811>] ttm_bo_wait+0x91/0x190 [ttm] [<ffffffffa046eefc>] ttm_bo_move_accel_cleanup+0x9c/0x350 [ttm] [<ffffffffa050ee22>] radeon_move_blit.isra.7+0xc2/0x160 [radeon] [<ffffffffa050f70a>] radeon_bo_move+0xaa/0x1e0 [radeon] [<ffffffffa046d065>] ttm_bo_handle_move_mem+0x255/0x5f0 [ttm] [<ffffffffa046d592>] ttm_bo_evict+0x192/0x360 [ttm] [<ffffffffa046d8be>] ttm_mem_evict_first+0x15e/0x200 [ttm] [<ffffffffa046dc11>] ttm_bo_mem_space+0x2b1/0x360 [ttm] [<ffffffffa046e26a>] ttm_bo_move_buffer+0xca/0x150 [ttm] [<ffffffffa046e38a>] ttm_bo_validate+0x9a/0x110 [ttm] [<ffffffffa046e6b9>] ttm_bo_init+0x2b9/0x3d0 [ttm] [<ffffffffa0510160>] radeon_bo_create+0x180/0x250 [radeon] [<ffffffffa0521f9b>] radeon_gem_object_create+0x9b/0x160 [radeon] [<ffffffffa05223b0>] radeon_gem_create_ioctl+0x60/0x140 [radeon] [<ffffffffa03fb1c1>] drm_ioctl+0x4d1/0x580 [drm] [<ffffffff8119d135>] do_vfs_ioctl+0x2e5/0x4d0 [<ffffffff8119d3a1>] sys_ioctl+0x81/0xa0 [<ffffffff814da1dd>] system_call_fastpath+0x1a/0x1f [<ffffffffffffffff>] 0xffffffffffffffff Maybe my info can help the community
Regards, coderkun
On Thu, Jul 4, 2013 at 1:23 AM, coderkun <olli@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
participants (5)
-
coderkun
-
goodmenzy＠gmail.com
-
János Illés
-
Patrick Burroughs (Celti)
-
Scott Lawrence