Screen gets garbled during boot in Ubutu 10.04 and 10.10
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Expired
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: xorg
Since I have moved from Karmic to Lucid, I am facing problems with the screen display. The Screen gets garbled. There are horizontal and vertical lines all over the screen and the System freezes. I had to restart the system to get over it.Sometimes it happens during boot and sometimes after Ubuntu has started After searching online I found a number of people are facing this problem. I read on the following link about incompatability of intel graphic drivers https:/
Though i have a Intel 945 GM graphics driver but still one of the solutions i.e downgrading a kernel worked for me
aashish@
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
now i have installed a different kernel i.e.
aashish@
2.6.31-9-rt
This kernel though is working fine but still i am not able to use higher kernels and also i am not able to install some updates.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: xorg 1:7.5+6ubuntu3
ProcVersionSign
Uname: Linux 2.6.31-9-rt i686
Architecture: i386
DRM.card0.LVDS.1:
status: connected
enabled: enabled
dpms: On
modes: 1280x800
edid-base64: AP/////
DRM.card0.VGA.1:
status: disconnected
enabled: disabled
dpms: On
modes:
edid-base64:
Date: Sun Oct 17 16:32:03 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386 (20100901.1)
MachineType: TOSHIBA Satellite M200
PccardctlIdent:
Socket 0:
no product info available
PccardctlStatus:
Socket 0:
no card
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
LANG=en_IN
SHELL=/bin/bash
SourcePackage: xorg
Symptom: display
Title: Xorg freeze
dmi.bios.date: 05/15/2007
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 1.10
dmi.board.name: CAPELL VALLEY(NAPA) CRB
dmi.board.vendor: Intel Corporation
dmi.board.version: Not Applicable
dmi.chassis.
dmi.chassis.type: 1
dmi.chassis.vendor: No Enclosure
dmi.chassis.
dmi.modalias: dmi:bvnPhoenixT
dmi.product.name: Satellite M200
dmi.product.
dmi.sys.vendor: TOSHIBA
glxinfo: Error: [Errno 2] No such file or directory
system:
distro: Ubuntu
codename: maverick
architecture: i686
kernel: 2.6.31-9-rt
affects: | xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu) |
tags: | added: corruption |
tags: | added: karmic lucid |
Hi,
Thanks for reporting this X gpu lockup bug in Ubuntu maverick.
In my opinion GPU lockups are one of the most frustrating kinds of bugs, both as a user and a developer. I want take a few moments of your time to explain the situation with these types of bugs.
For some reason, -intel has been plagued with these freeze bugs for a long time. In the past -intel has had options to switch to legacy memory or rendering technologies as workarounds, but Intel tends to drop obsolete code pretty aggressively and unfortunately in maverick these workarounds are not available.
As a policy, Intel engineers look only at bugs that are seen in the most recent release of their drivers. With older versions of their drivers, such as the version in maverick, we're on our own.
On the plus side, they provide good tools for gathering debug data about the bugs, such as the intel_gpu_dump too. Unfortunately, the version of Apport in maverick doesn't capture the dmesg or X logs correctly (it collects the files at the time of freeze, but then overwrites them with clean, unhelpful versions when it goes to file the report for you.)
The version of these diagnostic tools in natty has been fixed up, and is allowing us to analyze GPU lockups a lot easier. This has helped us solve several of the bugs, and given us a handle on some of the more challenging ones.
Backporting these fixes may not be feasible though; by their nature the fixes for these type of bugs tend to be very low level, esoteric, and risky of causing something else to regress. Because the freezes are often hard to reproduce, it's not always possible to verify fixes anyway. It may be that our best bet is to focus on natty.
But for now, since these freezes typically require kernel patches to solve, I'm moving your bug report to the kernel package. They may be able to point you to a newer kernel likely to help with this issue.