а если заменить драйвер на i810? хотя у меня 3 машины на 945G и ничего 
подобного не замечал

Заменял. Виснет точно так же.

а при отключенном dri?

Я пробовал
Option "DRI" "no"
Option "NoAccel" "yes"
в такой комбинации, висло всё равно.

Откатился пока на старый X.org (от начала сентября), работает.

На самом деле виснет, даже если откатиться на июньский X.org.
Из этого я делаю вывод, что бага где-то в другом месте, и, следовательно, для
ксорга она INVALID.
Извините за беспокойство.

Если это на этой машинке у тебя ещё кучка проблем вылезла (кажется, raorn@
предлагал память проверить) -- действительно попробуй стрельнуть/поменять память
или хотя бы прогнать ночью memtest86.

О, эврика.
Поставил с нуля Desktop Lite, завёл X-ы -- всё работает как часы.
Обновил libgtk+2 и libpango до сизифных.
После этого X.org стал виснуть в вышеуказанных ситуациях, иногда до степени
неубиваемости (так что требуется Ctrl-Alt-SysRq-B).

Откатил libgtk+2 (на 2.10) и libpango -- работает опять.

X.org всё это время бранчевый, с которым Desktop Lite собирается. Как мы помним,
сизифный X.org тоже вешался.

Я считаю, что это в любом случае бага X.org. Не должен он позволять себя вешать
независимо от кривизны клиентской библиотеки. Впрочем, ktirf может что-нибудь
подсказать о том, что изменилось в GTK+ 2.12 :-).

сходите еще повесьте багу на ядро - не должно оно позволять вешать машину не 
зависимо от кривизны загруженныхмодулей/железа 

Валер, отмазка -- INVALID.  Железо бывает кривым совсем по-другому, чем
клиентские библиотеки.  А история с тем, что в Xorg ломают нафиг XRENDER и
взрывается всякое Cairo -- не нова.

Лучше им передать эту информацию, раз уж ты собираешь xorg в сизиф из git, а не
релизами.  Иначе смысл тестировать на коллегах, а багрепорты закрывать?

(а если некогда/влом/неудобно -- давай сидеть на релизах тогда и не выпендриваться)

(In reply to comment #4)
> Option "NoAccel" "yes"
А RenderAccel?  Попробуй погуглить xorg cairo hang, кажется, это не новая история.

> Лучше им передать эту информацию, раз уж ты собираешь xorg в сизиф из git, а 
не
> релизами.

о каком git'e речь? Мишь, не уподобляйся Костику, заглядывай в src.rpm, прежде 
чем сказать что то подобное на людях

>  Иначе смысл тестировать на коллегах, а багрепорты закрывать?
> 
> (а если некогда/влом/неудобно -- давай сидеть на релизах тогда и не 
выпендриваться)

см. выше. я не видел сломанных иксами gtk+2 и иже с ним и если уж вешать баги 
то на виновника сего, но никак не на то что оно убивает

продолжаем разговор. это проявляется массово на разных конфигурациях или это 
единичный случай? я не использую ни icewm, ни xfce, как это воспроизвести?

Я читаю cybertalk@ и относительно пакетов xorg-x11-* и libX* зачастую вижу там
упоминания коммитов, из которых они собраны.

Понимаешь, оно хорошо -- тестировать до релиза, но если нет возможности доносить
фидбэк до апстрима (например, его сваливается слишком много, разнообразного, на
русском, а там хотят сжато и воспроизводимо) -- то может быть лучше и не
тестировать на своих пользователях.

Спроси ldv@ насчёт опыта по такому взаимодействию?

PS: я бы вряд ли конкретно xorg собирал из git, а скорее руководствуясь правилом
"X.Y.1 или позже".  Потому что им -- не доверяю.  А вот monit можно вслепую
собирать, как показывает практика...

PPS: где-то между 2006 и 2007 ловил фризы иксов, которые упёрлись в
cairo/xrender.  Не помню, на чём именно (сам на wmaker, киоски на icewm, коллеги
на kde).

(In reply to comment #13)
> Я читаю cybertalk@ и относительно пакетов xorg-x11-* и libX* зачастую вижу
> там упоминания коммитов, из которых они собраны.
а каким образом это стыкуется с тем что с libgtk+2-2.10.14 все работает как 
часы, а с libgtk+2-2.12.1 все вешается?

из переписки:

> 2 sr: не припомнишь грабель, описанных в #13299?
Нет, но по исходникам - виноват DRI вкупе с драйвером, драйвер
на ошибке DRI не должен лажаться
И по исходникам 'Option "DRI" "no"' должно помочь

И, если я правильно понимаю политику партии, то лажа возникает в
i830_dri.c:I830DRITransitionTo2d() на вызове
I830DRISetVBlankInterrupt(pScrn, FALSE)
Он не обрабатывает ошибку
Да собственно, ошибка I830DRISetVBlankInterrupt() нигде не обрабатывается
Можно вот это попробовать, но фиг знает,

--- i830_dri.c- 2007-11-06 22:12:04 +0200
+++ i830_dri.c  2007-11-06 22:15:23 +0200
@@ -1588,10 +1588,13 @@
                       
    I830DRISetPfMask(pScreen, 0);

-   sPriv->pf_enabled = 0;
-
    pI830->want_vblank_interrupts = FALSE;
-   I830DRISetVBlankInterrupt(pScrn, FALSE);
+   if( !I830DRISetVBlankInterrupt(pScrn, FALSE))
+   {
+      pI830->want_vblank_interrupts = TRUE;
+      if( !I830DRISetVBlankInterrupt(pScrn, TRUE))
+         xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "[drm] Ну, блин! Ну,
не знаю, какая-то задница случилась.\n");
+   }
 }

 #if DRI_SUPPORTS_CLIP_NOTIFY

(In reply to comment #14)
> а каким образом это стыкуется с тем что с libgtk+2-2.10.14 все работает как 
> часы, а с libgtk+2-2.12.1 все вешается?
Подозреваю, что 2.10 не дёргало что-то, что дёргает 2.12.  В той истории,
которую припоминал -- было то же самое, это когда gtk на рендеринг через cairo
перетаскивали.  Кажется, тогда вышло, что раньше проблема тоже была, но на неё
просто не наступали.

Попробовал на двух машинах в офисе: десктоп на i945G и ноутбук ThinkPad на
i945GM. Не воспроизводится.

memtest гонял (без ошибок). DRI отключал (сообщение об ошибке исчезает).

Воспроизвести можно попробовать с помощью OpenOffice. Убить живой Writer с
документом, запустить его снова и попробовать восстановить документ. У меня виснет.

виснет что?

Иксы.

Кстати, научился воспроизводить всё это на офисной машине с i945G (но только в
Xfce). Делается так: 0) ставим Desktop Lite + gtk 2.12, 1) запускаем Firefox и 2
копии xterm'а, 2) переключаемся в Firefox с помощью Alt-Tab, 3) переключаемся
обратно в какой-нибудь xterm с помощью taskbar'а. После этого всё перестаёт
реагировать на мышь и клавиатуру, экран не обновляется.

Desktop Lite + updates работает?
Desktop Lite полностью обновленный до сизифа работает?

Причина нашлась (по крайней мере причина интересовавшей меня части бага).
Виноват xfwm4, в апстриме это исправили, у нас #13388.
Валерий, ещё раз извините за шум.

P.S. Первый раз вторично закрываю собственную багу как INVALID :-\.