Created attachment 4227 [details] полный лог Х при установке нового модуля, Х не стартовал ни на 2.6.32-un-def-alt5 ни на 2.6.30-std-def-alt15 (все i586) железо - нетбук/// в логах $ cat /var/log/Xorg.0.log.bug |tail -20 (WW) Falling back to old probe method for v4l (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (EE) intel(0): No kernel modesetting driver detected. (II) UnloadModule: "intel" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Please consult the The X.Org Foundation support at https://bugzilla.altlinux.org/ for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. немного вылечилось $ cat /etc/modprobe.d/local.conf # i945GE fix for normal work X options i915 modeset=1 #options i915 gem_enable=0 "немного" - потомучто на подключенном вторым мониторе все стало расплываться... и названия устройств для xranrd - изменились. было LVDS - стало LVDS1 VGA - VGA1
но приведенное решение (options i915 modeset=1) не панацея. потом валяться ошибки о переполднении буфера и Х уже просто показывают оставшуюся картинку... статично... можно попробовать перейти в консоль - но там тодже ничего не работает... лог к сожалению не сохранился... поймаю - покажу...
у меня такие строчки: kernel: [586544.845505] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged
(В ответ на комментарий №2) > у меня такие строчки: > kernel: [586544.845505] [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged во, точно... у меня такие же были...
2shrek: Перевешивать свои баги на других -- это непрофессионально.
2ldv: xorg-drv-intel требует KMS. KMS выключен в ядре. как лечить xorg-drv-intel?
проблема в этом? cat config-2.6.32-un-def-alt6 | grep 915 | grep KMS # CONFIG_DRM_I915_KMS is not set
(In reply to comment #5) > 2ldv: xorg-drv-intel требует KMS. KMS выключен в ядре. как лечить > xorg-drv-intel? Раньше xorg-drv-intel не требовал KMS в ядре. Надо было, наверное, отправлять в Сизиф xorg-drv-intel, заточенный на KMS, предварительно убедившись, что в Сизифе есть ядро, реализующее KMS. Есть ещё одна мысль: добавить в xorg-drv-intel %pre-скрипт, который проверит, есть ли в работающем ядре поддержка KMS, и, если не найдёт, то напишет диагностику и завершится с exit 1.
(В ответ на комментарий №6) > проблема в этом? > cat config-2.6.32-un-def-alt6 | grep 915 | grep KMS > # CONFIG_DRM_I915_KMS is not set именно
(В ответ на комментарий №7) > (In reply to comment #5) > > 2ldv: xorg-drv-intel требует KMS. KMS выключен в ядре. как лечить > > xorg-drv-intel? > > Раньше xorg-drv-intel не требовал KMS в ядре. > Надо было, наверное, отправлять в Сизиф xorg-drv-intel, заточенный на KMS, > предварительно убедившись, что в Сизифе есть ядро, реализующее KMS. проблема в том что xorg-drv-intel-2.9.1 фактически конфликтует с ядром 2.6.32 и выше, т.к. всю логику управления режимами и т.п. перенесли в drm > > Есть ещё одна мысль: добавить в xorg-drv-intel %pre-скрипт, который проверит, > есть ли в работающем ядре поддержка KMS, и, если не найдёт, то напишет > диагностику и завершится с exit 1. и dist-upgrade обломится на полпути
(В ответ на комментарий №9) > > добавить в xorg-drv-intel %pre-скрипт, который проверит, > > есть ли в работающем ядре поддержка KMS, и, если не найдёт, то напишет > > диагностику и завершится с exit 1. > и dist-upgrade обломится на полпути У нас уже есть возможность запускать скрипты после всей транзакции. Было бы здорово иметь возможность до.
(In reply to comment #9) > проблема в том что xorg-drv-intel-2.9.1 фактически конфликтует с ядром 2.6.32 > и выше, т.к. всю логику управления режимами и т.п. перенесли в drm Проблема не столько в этом, сколько в том, что и, наоборот, xorg-drv-intel-2.10.0 фактически несовместим со всеми предыдущими ядрами. > > Есть ещё одна мысль: добавить в xorg-drv-intel %pre-скрипт, который проверит, > > есть ли в работающем ядре поддержка KMS, и, если не найдёт, то напишет > > диагностику и завершится с exit 1. > > и dist-upgrade обломится на полпути dist-upgrade не обломится по пути, однако новый xorg-drv-intel не будет установлен.
(В ответ на комментарий №11) > (In reply to comment #9) > > проблема в том что xorg-drv-intel-2.9.1 фактически конфликтует с ядром 2.6.32 > > и выше, т.к. всю логику управления режимами и т.п. перенесли в drm > > Проблема не столько в этом, сколько в том, что и, наоборот, > xorg-drv-intel-2.10.0 фактически несовместим со всеми предыдущими ядрами. на 2.6.30 с включенным KMS он работает > > > > Есть ещё одна мысль: добавить в xorg-drv-intel %pre-скрипт, который проверит, > > > есть ли в работающем ядре поддержка KMS, и, если не найдёт, то напишет > > > диагностику и завершится с exit 1. > > > > и dist-upgrade обломится на полпути > > dist-upgrade не обломится по пути, однако новый xorg-drv-intel не будет > установлен. есть вероятность что он не будет установлен никогда
(In reply to comment #9) > проблема в том что xorg-drv-intel-2.9.1 фактически конфликтует с ядром 2.6.32 и > выше, т.к. всю логику управления режимами и т.п. перенесли в drm Ну так синхронизироваться ж надо и анонсировать. Сейчас прям рэкет какой-то выходит -- "а ну-ка, boyarsh@, поддерживай единственное ядро в сизифе, с которым интеловское видео заработает у тех, кто его догадается поставить". > > Есть ещё одна мысль: добавить в xorg-drv-intel %pre-скрипт, который проверит, > > есть ли в работающем ядре поддержка KMS, и, если не найдёт, то напишет > > диагностику и завершится с exit 1. > и dist-upgrade обломится на полпути "А если ты не выстрелишь в шарик, тогда испорчусь я!" (c) (In reply to comment #10) > У нас уже есть возможность запускать скрипты после всей транзакции. > Было бы здорово иметь возможность до. Да, это позволило бы от многих неприятностей подстраховаться.
(В ответ на комментарий №13) > > Было бы здорово иметь возможность до. > Да, это позволило бы от многих неприятностей подстраховаться. Я фигню написал. Чтоб до, нужно установить его до :-)
2ldv: примерно так? %pre if ! grep -q "CONFIG_DRM_I915_KMS=y" /boot/config-$(uname -r); then exit 1 fi
так тоже нельзя. Лучше всего сделать runtime проверку и не запускать xorg, пока пользователь не поставить нужного ядра. Мне так кажется, а вам ?
2mike: во первых читай выше, во вторых #19137 FAILED sisyphus/silicium kernel-image.git=kernel-image-std-pae-2.6.32-alt1... #19136 FAILED sisyphus/silicium kernel-image.git=kernel-image-std-def-2.6.32-alt1... #19145 DONE sisyphus/shrek xorg-drv-intel.git=2.10.0-alt1 сравни номера тасков
(В ответ на комментарий №16) > так тоже нельзя. > > Лучше всего сделать runtime проверку и не запускать xorg, пока пользователь не > поставить нужного ядра. > > Мне так кажется, а вам ? лучше исправить ядра. или забить на все и ничего не обновлять, пусть протухает. или поставить xorg-drv-i810, что равносильно "протухает"
[14:16:19] <gns___> я не понял в чём драма с ксорг-дрв-интел и зачем пересобирать ядро ещё и .32 [14:16:34] <gns___> если достаточно в cmdline i915.modeset=1 или в /etc/modprobe.d/ [14:16:42] <wRAR> угу. [14:16:49] <wRAR> просто это недистрибутивно [14:17:26] <gns> дистрибутивно, это в пакете xorg-drv-intel принести файлик /etc/modprobe.d/i915
это костыльно. если в lilo.conf будет vesafb ему все равно поплохеет
> Лучше всего сделать runtime проверку и не запускать xorg, пока пользователь не поставить нужного ядра. Как же пользователь его поставит, если у него интернет подключался через NetworkManager?
(В ответ на комментарий №14) > Я фигню написал. Чтоб до, нужно установить его до :-) Либо выкачивать такие скрипты с хешами apt из заголовков rpm, но это вряд ли кто будет реализовывать.
(In reply to comment #15) > 2ldv: примерно так? > %pre > if ! grep -q "CONFIG_DRM_I915_KMS=y" /boot/config-$(uname -r); then > exit 1 > fi Примерно так. Можно ещё проверить + /proc/cmdline на предмет i915.modeset=1 + вывод modprobe -c на предмет options i915 modeset=1 Кстати, а если запаковать /etc/modprobe.d/i915, как тут предложили, хуже ведь не станет?
с vga!=normal станет
(In reply to comment #24) > с vga!=normal станет В какой момент?
как оно себя поведет с бутсплешом не знаю, иксы расколбасит когда они полезут не в тот /dev/fb*
Хм, а в Debian таки запакован i915-kms.conf в пакете с иксодрайвером.
да без проблем
xorg-drv-intel-5:2.10.0-alt2 -> sisyphus: * Fri Feb 05 2010 Valery Inozemtsev <shrek@altlinux> 5:2.10.0-alt2 - /etc/modprobe.d/i915-kms.conf: enabled KMS (closes: #22828)
(В ответ на комментарий №29) > xorg-drv-intel-5:2.10.0-alt2 -> sisyphus: > > * Fri Feb 05 2010 Valery Inozemtsev <shrek@altlinux> 5:2.10.0-alt2 > > - /etc/modprobe.d/i915-kms.conf: enabled KMS (closes: #22828) Q: стали за запускаться Х (суть этого бага)? A: да, багу можно закрыть... Q: Стали ли лучше "картинка"? A: однозначно - стало хуже картинка... но на втором мониторе, не первом - все ОК. конфигурация - нетбук, подключенный второй моник 19" tft. так на нем картинка - ужас... представте себе crt моник, пузатый еще, который до вас проработал лет пять-десять... на нем уже нет фокуса... все плывет, все буквы не четкие, все размыто, глаза начинают болеть минут через 15... именно такая картинка сейчас с новым драйвером при выводе картинки через LVDS (после i915-kms - нумерация сбилась... vga -> vga1, lvds -> lvds1) я попробовал с разными настройками xorg.conf ... что было у меня, с новым сгенерированым - ситуация не меняется - картинка "размыта".
