Как исследовать блокировку дисплея после переключения Alt-Tab? [закрыто]

Запуск Kubuntu 12.10 на Dell Latitude E6500 с бесплатным драйвером NVIDIA для моего дисплея. Если я нажимаю alt-tab, чтобы переключаться между окнами слишком быстро, дисплей блокируется, и единственный способ разблокировать его - это перезагрузить компьютер, либо жестко выключить окно, либо подключиться по SSH и перезагрузиться. Все остальные службы и приложения продолжают работать. Ничего не блокируется или вылетает, никаких других сообщений, только блокировка дисплея.

Есть идеи, с чего начать устранение неполадок?

2
задан 13 July 2014 в 01:30

1 ответ

Это - ошибка, таким образом, я предполагаю, что Вы спрашиваете, как собрать необходимую информацию для создания отчетов об этом. (Иначе этот вопрос, вероятно, вне темы; посмотрите FAQ и этот meta вопрос.)

Консультируйтесь с документацией создания отчетов ошибки сначала

Вы сказали:

Я выполняю Неон Проекта ppa и когда я вхожу в систему с пользователем asscocatied w/, что у меня, кажется, нет тупиков.

Я предполагаю, что средство, когда Вы входите в систему рабочего стола KDE, проблема, не происходит, но что действительно происходит, когда Вы входите в dekstop, не обеспеченный пакетами от Неона Проекта PPA.

Однако, если это происходит в GUI, обеспеченном Неоном Проекта, удостоверьтесь, что Вы считали это тщательно и следуете его инструкциям при сообщении об ошибке.

Является ли это ошибкой в программном обеспечении Project Neon, я настоятельно рекомендую чтение этого полностью через прежде, чем сообщить об ошибках в Ubuntu. Для Kubuntu я рекомендую все еще читать, что, но также и это (и смотрят на эту страницу портала). Этим вопросом является также полезный ресурс. И вот некоторый хороший общий совет создания отчетов ошибки.

Если Вы уже считали все это и понимаете, как сообщить об ошибках, можно перескочить...

Фигура, какой пакет, вероятно, затронут

Если Вы сообщаете об ошибке против неправильного пакета, при условии, что отчет в других отношениях хорош и имеет всю необходимую информацию, это обычно может вычисляться triager или разработчиком, и отчет об ошибках может быть довольно легко перенастроен к другому пакету.

Однако, так как большая часть важной технической информации в отчете об ошибках Ubuntu часто предоставляется путем выполнения Apport, и Apport выясняет, что отправить, на основе какого пакета против ошибки сообщают, хорошо приложить первоначальное усилие для выбора правильного, специально для видео, звука, драйвера или проблем ядра, где Apport может часто отправлять большую очень ценную информацию.

Экранное замораживание, вероятно, должно или к или по крайней мере тесно связано с, X-сервер или менеджер окон.

X-сервер

В экране входа в систему можно выбрать между различными интерфейсами. Все они используют тот же X-сервер, но некоторое использование различные менеджеры окон.

Если Вы испытываете это со всеми опциями, то эта ошибка, вероятно, касается X-сервера, и по этому можно сообщить xserver-xorg путем выполнения ubuntu-bug xserver-xorg. Но лучше работать ubuntu-bug с PID выполнения Xorg процесс, который может неправильно функционировать. ubuntu-bug $(pidof Xorg) должен сделать это.

(См. ниже для объяснения того, как работать ubuntu-bug когда Ваш экран замораживается.)

Менеджер окон

Однако это звучит от того, что Вы сказали, что дело обстоит не так - что по крайней мере одна опция (входящий в систему с рабочим столом, обеспеченным Неоном Проекта), работает.

Менеджер окон Kubuntu kwin, если kde-window-manager пакет. Для сообщения об ошибке против него можно работать ubuntu-bug kde-window-manager, но лучше работать ubuntu-bug с PID выполнения kwin процесс, который может неправильно функционировать. ubuntu-bug $(pidof kwin) должен сделать это.

Если проблема характерна для 3D сессии Единицы, выполнение менеджера окон, когда это происходит, compiz.

  • ubuntu-bug compiz хорошо. ubuntu-bug $(pidof compiz) лучше

С другой стороны, если это просто происходит в 2D Единице (и сессия Классика/Нейтрализации GNOME), менеджер окон metacity:

  • ubuntu-bug metacity хорошо. ubuntu-bug $(pidof metacity) лучше.

Если это происходит в рабочем столе GNOME 3 рабочий GNOME Shell (не Единица), менеджер окон mutter.

  • ubuntu-bug mutter хорошо. ubuntu-bug $(pidof mutter) лучше.

Если это происходит в рабочем столе Xubuntu, менеджер окон xfwm4.

  • ubuntu-bug xfwm4 хорошо. ubuntu-bug $(pidof xfwm4) лучше.

Если это происходит в рабочем столе LXDE, менеджер окон openbox.

  • ubuntu-bug openbox хорошо. ubuntu-bug $(pidof openbox) лучше.

Пользовательская специфика

Если у Вас есть одна учетная запись пользователя, которая загружается к одному UI по умолчанию и другой учетной записи пользователя, которая загружается к другому UI по умолчанию, и ошибка происходит в одной, но не другом, то (так как это - ошибка UI) различие UI, вероятно, что важно.

Но Вы уверенный удостоверяетесь, так как иногда конфигурации определенного пользователя удается инициировать ошибку. Необходимо проверить, что это происходит с учетной записью пользователя, зарегистрированной с одним UI, и с той же учетной записью пользователя вошел в систему другого UI.

Необходимо также видеть, являются ли шаблоны использования тем, что инициировало ошибку. Например, посмотрите, относится ли количество окон, Вы - Alt+Tabing через, для того, происходит ли ошибка. (Если это происходит только с одним окном, это особенно интересно.) Этот вид информации должен быть включен в Ваш отчет об ошибках.

Другие пакеты

Возможно, что ошибка находится в некотором пакете кроме X-сервера или менеджера окон.

  • Это могло быть высокоуровневым (то есть, большая часть проблемы могла бы происходить в процессе, который работает сверху GUI, который только инициировал другую ошибку в менеджере окон или X-сервере).
  • Или это могло ниже находиться на одном уровне. Вероятно, не ошибка в самом ядре (Ваша система все еще хорошо работает, Вы можете SSH в). Но это могла быть проблема видеодрайвера.

В любом случае сообщение об ошибке или против менеджера окон или против X-сервера, в зависимости от которого кажется более вероятным, будет обычно заставлять Apport загружать достаточно правильной информации что, если ошибка будет в чем-то еще, которое может быть вычислено.

Сообщение об ошибке, в то время как ошибка делает себя трудно для создания отчетов

Вы нашли, что можете SSH в. Таким образом, кажется вероятным, что можно получить доступ к виртуальной консоли с Ctrl+Alt+F1, Ctrl+Alt+F2, и т.д, до F6.

(Для переключения назад на GUI используйте Alt+F7.)

Если это работает, можно сообщить об ошибке от виртуальной консоли, в то время как GUI все еще работает и неправильно функционирует. ubuntu-bug, когда выполнено в виртуальной консоли, должен обнаружить нет никакого GUI и выполнения в текстовом режиме вместо этого. Или если Вы предпочитаете использовать apport-cli команда вместо этого, которая работает также.

SSHing в сообщить об этом, вероятно, легче, хотя, поскольку затем можно скопировать URL Панели запуска, обеспеченный ubuntu-bug/apport-cli и вставьте его в графический веб-браузер на клиенте SSH.

Кроме того, Вы могли бы рассмотреть использование ssh -X соединяться. Затем можно запустить программы GUI на неправильно функционирующей машине (что Вы - SSHed в), и сделайте их интерфейсы (их окна) появляются на клиенте SSH. Вы могли затем работать ubuntu-bug графически и сообщите об ошибке от графического веб-браузера, который работает на неправильно функционирующей машине, которая является сервером SSH, но отображается на правильно функционирующей машине, которая является клиентом SSH.

Больше способов найти процесс влияния PID

В зависимости от природы ошибки могло бы быть особенно полезно работать ubuntu-bug (или apport-cli) с PID ошибочного процесса, а не только с названием пакета. Это будет автоматически включать информацию о состоянии выполнения процесса в файлах, загруженных на Панель запуска Apport.

Итак, если ubuntu-bug $(pidof processname) не работает или не получает правильный процесс, Вы можете также:

  • Выполненный pidof вручную и посмотрите то, что Вы получаете. Если Вы ничего не получаете, это означает, что никакой процесс тем именем не работает.

  • Выполненный pgrep, который показывает PID всех процессов, соответствующих аргументу как регулярное выражение (а не чьи имена равны аргументу, как pidof делает).

  • Используйте проверенную, классическую технику (ps, переданный по каналу к grep):

    ps ax | grep -v grep | grep processname

    Это обеспечивает более подробную информацию - она дает список имени, PID и состояний любых процессов соответствия.

Файлы для проверки присоединяются

Удостовериться /var/log/Xorg.0.log и (если это существует), /var/log/Xorg.0.log.old присоединяются.

Точно так же удостоверьтесь ~/.xsession-errors и (если это существует), ~/.xsession-errors.old присоединяются. (~ представляет Вашу домашнюю папку.) Dotfiles не показывают в Наутилусе по умолчанию, поэтому если Вы хотите видеть их в окне браузера графических файлов, сделать Ctrl+H (или Представление> Выставочные Скрытые файлы).

Когда Вы сообщите об ошибке на Панели запуска, Apport автоматически отправит много файлов, которые будут присоединены. Можно также присоединить еще один файл. Для присоединения различных файлов отправьте отчет об ошибках сначала - затем можно присоединить их.

3
ответ дан 13 July 2014 в 01:30

Другие вопросы по тегам:

Похожие вопросы: