Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)

[Marc Tardif]

During the installation process of the Tribe-3 alternate CD, the video output become corrupted on some laptops when installing the packages. The installation proceeds successfully, but the usual blue background with the status bar becomes a black background with some garbage colors instead of the status bar.

The issue still exists in Tribe 4.

[Marc Tardif (cr3)]

Here's the lspci output of another laptop experiencing the same problem.

[Marc Tardif (cr3)]

And here's the lspci output of yet another laptop experiencing the same problem.

[Brian Murray (brian-murray)]

Do you have anyway to take a picture of this? Also it looks like all the systems have an i945 graphics chipset. Is that correct?

[Michael Gorven (mgorven)]

Just tried to install Gutsy from Tribe 3 Alternate CD, and got this exact problem. Also have an i945 graphics chipset.

[Albert Damen (albrt)]

I had the same issue with Gutsy tribe 3 and tribe 4 (alternate amd64). See bug #130131

For me the workaround is to add vga=771 as boot option (via F6). With this boot option the display was good during the complete installation.

I have Intel GM965, with 1280x800 display.

[Albert Damen (albrt)]

Without vga boot option, the problem is still present in Tribe 5.

[Henrik Nilsen Omma (henrik)]

Bryce, are these attachments sufficient; would a picture be useful?

[Albert Damen (albrt)]

Marked bug 136441 as duplicate of this bug.
Please note bug 136441 has pictures attached: http://launchpadlibrarian.net/9080539/P1000782.JPG and http://launchpadlibrarian.net/9080541/P1000783.JPG

[Bryce Harrington (bryce)]

Looking through all the duplicates for this bug, it appears pretty much everyone's hardware is amd64 and gm965. The issues appears to have all been noticed in August, around tribe3/tribe4.

Looking at the xresprobe changelog, this appears to coincide with a change made by Matthew Garrett to add support for the Intel driver. This didn't *cause* the bug, but probably just revealed it; prior to this, xresprobe wouldn't be able to deal with -intel. However, my guess is that the root issue is in the intel driver, not in xresprobe itself; xresprobe simply triggers it.

Can anyone reproduce the issue after installation by running 'xresprobe intel'? If so, could you then try running 'xrandr --output TV --off' and then 'xresprobe intel' and see if that makes it go away?

There are reports upstream with this chipset that the TV out detection can confuse the resolution detection algorithms. If this is the case here, then we need to ensure tv out is disabled for this card. See https://bugs.freedesktop.org/show_bug.cgi?id=11366 for the patch. It can also be turned off in xorg.conf:

Section "Monitor"
   Identifier "TVOutput"
   Option "Disable" "true"
EndSection

Then in the Device section add:

  Option "monitor-TV" "TVOutput"

If it can be determined that TV-out is not the cause of this issue, then we should probably report it upstream; I could not find other reports of this behavior in the xorg or debian bug trackers.

[Albert Damen (albrt)]

In my system the TV output is already disabled (without the above lines in xorg.conf). Running xresprobe intel does not give the colored blocks.
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right)
LVDS connected 1280x800+0+0 (normal left inverted right) 331mm x 207mm
   1280x800 59.9*+ 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TV disconnected (normal left inverted right)

I did find something in the logfiles: the installation uses framebuffer and loads modules fbcon and vga16fb (+ some depending modules). My installed system does not use these modules.

When I do the installation without any additional boot option, I get the colored blocks
when I do the installation with boot option vga=771 or fb=false, I don't get the colored blocks.
Could this mean the problem is caused by using framebuffer with the intel driver?

I also found a way to reproduce the problem manually: I don't answer the question about language support in the installation but switch to tty2. When I just install xresprobe and xserver-xorg-video-intel manually, the colored blocks show (no boot-option).
Could I retrieve more information by doing this manual install with some special options?

[Kyle McMartin (kyle)]

TV out certainly isn't the cause of this bug. It seems to be a bogus interaction with vga16fb and ddcprobe.

[Kyle McMartin (kyle)]

This also seems to happen on both i386 and amd64. Likely this is related to vbetool segfaulting instead of properly POSTing the card on resume from suspend. (And hence the backlight not coming back on 965GM.)

[Kevin Wang (kevin-xuepu-wang)]

the issue happends on i386 version on santa rosa as well and I didn't see this issue with Weybridge platform.

I agree with Albert, the TV out is already disable, seems the issue related to framebuffer, when I do the installation with vga setting 640x480, everything is OK.

[Bryce Harrington (bryce)]

I notice this patch which fixes something that sounds vaguely similar:
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=265a633cf1fcbf497d6916d9e22403dffdde2e07

[Bryce Harrington (bryce)]

Here is a deb including the aforementioned patch, could someone test this?

http://people.ubuntu.com/~bryce/Testing/bug127008/xserver-xorg-core-dbg_1.3.0.0.dfsg-12ubuntu7~ppa1_i386.deb

Since this occurs during installation, I'm not sure how easy this is going to be to test... Possibly switch to a terminal early in the installer, install the deb, and then continue the installation? If someone knows of a better procedure for testing, please share it here.

The description of the patch is, "Screen size changing should leave FB alone when X is inactive." I'm just making a wild guess that perhaps at some point during installation, one of the packages does a screen size change before X has been made active, which then affects the framebuffer which for this hardware results in the screen corruption described in this bug.

[Albert Damen (albrt)]

I have done a series of installations, trying to find the offending package.

First run the installation up to the question about language support, then switch to tty2 and use apt-install/apt-setup to manually install packages.

Test 1
install and setup xresprobe: no problem, then install intel: colored blocks (setup intel was not needed to get the blocks)

Test 2
install and setup intel: no problem, then install and setup xresprobe: still no problem

Test 3
install and setup xresprobe: no problem, then install and setup xserver-xorg-core (from tribe 5 cd): still no problem, then install and setup intel: still no problem.

I have done test 1 and 3 earlier this week, with the same result.

So I think I would need to use a set of smaller X packages, with less dependencies, to test the patch correctly.

[Santiago Urueña (suruena)]

I've this problem with gutsy daily built 2007-09-22 for i386. But the graphics card of my laptop is a 945GM (lspci attached). Adding vga=771 as boot option resolves the problem, though.

[Albert Damen (albrt)]

As nobody seems to have a clever idea how to test the suggested patch, I used brute force to do it:

- patched and build xserver-xorg-core (for amd64, in pbuilder)
- modified the tribe 5 cd to include the new .deb

Unfortunately I got the colored blocks again during installation.

After the installation was complete and the system was rebooted, I verified the right xserver-xorg-core was installed (ubuntu7) and the changelog included my change entry.

[Albert Damen (albrt)]

915GM is affected as well, see bug 144726 (marked as duplicate)

[Albert Damen (albrt)]

Installation of the Beta release gives the same results as before.

[Bryce Harrington (bryce)]

I got a desktop system with a 965GM chipset and installed the Beta release on it without reproducing this issue.

[Albert Damen (albrt)]

It looks like most of the affected systems are laptops.
My screen is reported as LVDS. Bryce, what do xresprobe and xrandr say about your display?
Could there be a difference between how LVDS and other types of displays are treated?
I tried to test my system with external monitor, but unfortunately I cannot switch off the internal display and xresprobe still reported lvds/lcd.

[Bryce Harrington (bryce)]

On my 965gm desktop (detected as 82G965), which is connected to a crt through a kvm, xresprobe reports it as a "crt" display. I'll test it with a directly connected lcd as well...

Btw, I've posted a .deb for a fix for bug 144956 at http://people.ubuntu.com/~bryce/Testing/xorg-server/. From what I can tell, it is not related to this bug as it's issue only appeared after Tribe 5, but might be worth testing in case I am wrong.

Since it sounds like this might be a laptop-only issue, could those of you experiencing this issue run the 'laptop-detect' command right after the question about language support? By design, it should be returning 0 if running on a laptop, 1 if not, and 2 if there's an error. Perhaps for whatever reason, it's screwing up?

[Xiaoyang Yu (xiaoyang-yu)]

I retested it on T61 using 25 Sep daily build IA32e alternate version, and the bug still exists.

[Bryce Harrington (bryce)]

Odd; I connected an lcd widescreen to the 965gm desktop, but xresprobe still reports it as a "crt". I'm proceeding through an installation, so far without any issue.

[Albert Damen (albrt)]

xresprobe seems to work different for laptop and crt/lcd. For laptop it seems to do DDC and xprobe, for lcd/crt only DDC.

If I run xresprobe with XRESPROBE_DEBUG=1 set, I get:
laptop: yes; ddc:
attempting an X probe
forking Xorg
id:
res: 1024x768
freq:
disptype: lcd/lvds
id:
res: 1024x768
freq:
disptype: lcd/lvds
not removing temporary xprobe directory /tmp/xprobe.8963; please do this by hand.
(and a lot of empty lines)

I think the x probe is only done if $RES is not set? Would that make your patch for bug 144956 more relevant?

[Albert Damen (albrt)]

During installation:
chroot target, then laptop-detect returns nothing
laptop-detect -v returns: we're a laptop (dmidecode returns notebook)

I tested the patch for bug 144956. The colored blocks still appear. However, after reboot my laptop came up with 1280x800 as it should. Previously it came up with 1024x768.
(I rebuilt the patch for amd64 and customized the beta CD)

After installation and with debug enabled, xresprobe still shows it probes X. Same output as above, except for the now correct resolution of 1280x800.

I guess if the ddc probe in xresprobe would find the right resolution for my laptop, the x probe would not be needed and the problem would be solved. I am not sure if the ddc probe in xresprobe is the same as ddcprobe, but this is what sudo ddcprobe gives (after 1st reboot):
vbe: VESA 3.0 detected.
oem: Intel(r)Crestline Graphics Chip Accelerated VGA BIOS
vendor: Intel Corporation
product: Intel(r)Crestline Graphics Controller Hardware Version 0.0
memory: 7616kb
mode: 1280x1024x256
mode: 1280x1024x64k
mode: 1280x1024x16m
mode: 1024x768x256
mode: 1024x768x64k
mode: 1024x768x16m
mode: 640x480x16m
mode: 800x600x64k
mode: 800x600x16m
mode: 640x480x256
mode: 800x600x256
mode: 640x480x64k
edid:
edid: 1 3
id: db00
eisa: LPLdb00
serial: 00000000
manufacture: 0 2006
input: analog signal.
screensize: 33 21
gamma: 2.200000
dpms: RGB, no active off, no suspend, no standby
dtiming: 1280x800@59
monitorid: LGPhilipsLCD
monitorid: LP154WX4-TLC

[Bryce Harrington (bryce)]

Aha, I figured out how to reproduce it on my desktop:

Boot with the alternate CD, go through the installation until it has reformatted the drive and started installing things to /target. Next `chroot /target`, then wait until the file /usr/share/xresprobe/xprobe.sh is present, and then invoke it:

 /usr/share/xresprobe/xprobe.sh laptop

Boom, colored squares.

Essentially what this script is doing, is running

 /usr/bin/Xorg :67 -ac -probeonly -logfile "<logfile>" -config "<config>"

using the xorg.conf from /usr/share/xresprobe/xorg.conf, with "intel" specified as the driver.

So... one solution could be to disable running xprobe.sh for driver "intel". I've attached a patch for this.

However, I think this risks ending up with an improperly configured graphics system. Let me experiment more and see if I can come up with a better solution.

[Albert Damen (albrt)]

I used a slightly different patch to prevent doing the x probe. I enabled the ddc probe when the driver is intel.
$RES gets set and prevents the x probe.
I made a new CD and the installation went OK. The screen was readable during the complete installation, no more colored blocks.

After installation the system rebooted normally and X was started with the correct resolution (still using the patched xserver-xorg-core from bug 144956)

[Bryce Harrington (bryce)]

Awesome, that looks like an acceptable solution to me.

I did a bit more experimentation, and I found that after installation has completed (even before rebooting), the issue cannot be reproduced using the steps I outlined. So it is only occurring during a very specific point of time, after /target is mounted, but before installation has completed. I did a `modprobe vga16fb fbcon` to turn on the installation environment's framebuffer, but that was not sufficient, so there is something more unique about that environment than just the vga16fb. I wonder if packages are in an inconsistent state or something... (Maybe there's a mismatch between what's in memory and what's on disk?)

Anyway, since I couldn't find anything more enlightening that way, I think your patch is going to be the best way to go. I'll roll it out directly. Good work!

[Rolla Selbak (rolla-n-selbak)]

Yes, thank you for all the work on this, very appreciated!

Me and my team will gladly validate as soon as the xresprobe fix is in...thanks again!

[Bryce Harrington (bryce)]

.deb for this change is here:

 http://people.ubuntu.com/~bryce/Testing/xserver/

I'll upload once someone can do a doublecheck that this does fix it. I only used the first part of the proposed patch, since if ddcprobe is getting $RES okay, then the second portion is unneeded. So I'd like to have someone sanity check me that this is in fact the case.

Thanks

[Rolla Selbak (rolla-n-selbak)]

I think you mean http://people.ubuntu.com/~bryce/Testing/xresprobe/ correct?

I'll get my team on it, thanks Bryce

[Albert Damen (albrt)]

Bryce, I have done the check with only the forced ddcprobe successfully.
I just thought leaving your patch in would be a safety belt, in case there is any hardware where ddcprobe cannot set $RES.
I must admit I have no idea how likely that would be.

[Bryce Harrington (bryce)]

Rolla, sorry yes that's correct.

albert, thanks for the confirm! Actually I think if we're confident ddcprobe will catch it for this case, we should rely only on that. My patch could have side effects on other hardware, and so if we don't think we need it, we should leave it out and avoid those effects. We can always add it later if needed.

One thing I've wondered is other laptops with different gfx chipsets may be experiencing problems like these (but with different symptoms.) So, it'd be good to keep an eye out for any bugs that are occurring for non-intel laptops doing the alternate text install and appearing late in the install process; we could expand this patch to include those cases as well.

Anyway, I've posted the source package for upload here, will shoot for getting it out tomorrow:
http://people.ubuntu.com/~bryce/Uploads/

[Bryce Harrington (bryce)]

xresprobe (0.4.24ubuntu5) gutsy; urgency=low

  * xorg.conf: Fix xprobe.sh failure caused by missing type1 module;
    this was dropped by Debian for xserver 1.3 since it's obsolete and
    has some security issues. (Addresses portion of fix for 127008)
  * xresprobe: Fix issue in alternate installation for Intel gfx laptops
    resulting in screen to be replaced by flashing colored blocks, by
    making xresprobe use ddcprobe instead of xprobe for laptops using
    the -intel driver. (Closes LP: #127008 and many, many duplicates)
  * ddcprobe.sh: Fix resolution detection error where LCD's would get
    configured to use one resolution less than their maximum because
    ddcprobe cannot tell the difference between an analog attached LCD
    and a CRT. (Closes LP: #27667)

 -- Bryce Harrington <email address hidden> Thu, 27 Sep 2007 17:57:22 -0700

[Aaron Whitehouse (aaron-whitehouse)]

I'm having this happen in Gutsy Beta. Did this fix make it onto the Beta CD, or is the problem that I am seeing the one that was fixed?

[Brian Murray (brian-murray)]

This fix was made after the Beta CD was released. You could test with a daily CD from http://cdimage.ubuntu.com to verify the fix as that should have the new version of xresprobe.

[Dave Morley (davmor2)]

Brian this fix seems to of worked I now have a res of 1280x800 :) Many thanks.

[Dave Morley (davmor2)]

Guys this is still broken in Kubuntu. Screen res is correct but everything else is just so wrong. Also I noticed the the font size on the login screen is about an inch high still and doesn't actually fit in the little text window.

[Soren Hansen (soren)]

This still happens on my Thinkpad X40. For me, it looks precisely like this: http://launchpadlibrarian.net/9080539/P1000782.JPG

PCI ID of my graphics card is 8086:3582.

[Soren Hansen (soren)]

I don't expect this is new information, but it occurs right after syslog shows that it's setting up xserver-xorg.

[Dave Morley (davmor2)]

Photo's are linked below.
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247564230314514
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247581410183714
http://picasaweb.google.com/davmor2/UbuntuScreenshots/photo#5119247602885020210

[Soren Hansen (soren)]

davmor2: Er, no, that's not what it looks like at all.

[Albert Damen (albrt)]

Soren, can you please advise which CD exactly you used? i.e which Ubuntu type, i386 or amd64 and which day? We know the problem was not fixed in beta yet, so I am assuming you used one of the daily CD's.
Secondly, can you confirm your graphics card is an 855GM? Can you see from your logs which video driver was used?

[Bryce Harrington (bryce)]

davmor2, what you're experiencing clearly is not this bug, but something unrelated. Please report separately.

Soren, we need confirmation and more detailed info from you that you were testing a Daily ISO, and not just gutsy -beta. I'm assuming you were testing -beta, since I'm quite confident this fix should resolve the original issue.

[Soren Hansen (soren)]

Sorry about the lack of detail when I reopened. It was with the 20071009 daily i386 alternate image, so it had the new xresprobe package (0.4.24ubuntu5). What else do you need?

[Bryce Harrington (bryce)]

Since the bug is confirmed fixed for the others that reported it, there's something different about your system.

Basically, we need to know if either a) your system somehow fails with the same bug with ddcprobe as with xprobe.sh, or b) for whatever reason on your system xprobe.sh gets called instead of ddcprobe. See my comment 30 for how to get into a testable environment.

The pci id 8086:3582 is 82852/855GM Integrated Graphics Device. I see it is a device that used to be blacklisted to use -i810 rather than -intel. So I agree albert's question about whether -intel is being used or perhaps i810 is relevant. If -intel is being used, maybe this simply means we need to re-blacklist your laptop to stay with i810. I recall we had troubles with getting -intel on it at the sprint in london.

[Soren Hansen (soren)]

I did a little digging. xresprobe calls ddcprobe.sh. If that doesn't give it a valid resolution, it calls xprobe.sh, too. Indeed, on my system, ddcprobe (not ddcprobe.sh) says "edidfail", so ddcprobe.sh just returns with no output, and hence xresprobe calls xprobe.sh and smashes my screen.

At the sprint in July we discovered that the new xrandr magic had hugely better effect if I was using the -intel driver. I'd be sad to see it go, but I'd also like to get this bug fixed :)

[Vincenzo Ampolo (vincenzo-ampolo)]

i'm going to test it with a daily build. i'll send you a feedback

[Vincenzo Ampolo (vincenzo-ampolo)]

Testing right now. The problem is still there even with the daily build from http://cdimage.ubuntu.com/daily/current/
it occurs when it's installing the packages...

[Bryce Harrington (bryce)]

Soren,

Ah, well an edidfail could explain it. This doesn't leave us too many options, but possibly the best of the worst is to simply skip xprobe.sh entirely for Intel laptops. I suspect this may result in various other issues, but all much less severe than a hang during installation.

Here is a debdiff and .deb for this. Can you test this to verify it fixes the hang issue, using the approach from comment 30?

http://people.ubuntu.com/~bryce/Testing/xresprobe/

As to the edidfail issue, bug 94994 already describes that. My suspicion is that there are multiple versions of EDID, and ddcprobe only supports one version. However, that's something that I'm going to have to leave til later to sort out.

[Falk Pauser (falk-pauser)]

same problem here doing a fresh install on a IBM X40 (gutsy alternate rc iso, booting from usb using hd-media from "[..]/current/[..]/hd-media"):
installation goes fine till xorg is installed (textmode terminal), then the terminal switches to graphics-mode and these colorized unreadable blocks are displayed (the before posted screenshot shows it).

this is a showstopper!

[Albert (albertm1121)]

I just experience (an hour ago) the same problem during the installation of xubuntu-7.10-alternate-i386.iso (release date: 09-Oct-2007 21:36), on my ibm r50e laptop with Intel 855GM video chipset. The trick is to wait for the hard drive & cd-rom drive activity to stop and just press enter.

[Bryce Harrington (bryce)]

Soren confirmed through IRC that this solves the issue adequately.

The regression risk for this bug is low. The code is invoked only for cards where autodetection failed, and attempts a second autodetection. This change skips this second autodetection for Intel cards; at least some proportion of Intel cards (maybe all) suffer from screen corruption during installation, making it extremely hard to complete installation. The effect is that users will have to manually provide some extra information during installation.

So the worst case regression here is that laptop users with Intel graphics that fail the primary autodetection, but would normally be autodetected by xprobe.sh, will now instead receive a prompt for resolution. However, I suspect this is going to be a vanishingly small number of cases. In any case, the harm of the regression is small, whereas the harm of not including the fix is much higher.

[Bryce Harrington (bryce)]

Ready for upload: http://people.ubuntu.com/~bryce/Uploads/

[Bryce Harrington (bryce)]

xresprobe (0.4.24ubuntu7) gutsy; urgency=low

  * Expanding the previous xprobe.sh fix, to prevent calling
    xprobe.sh for -intel even if the ddcprobe failed.
    (Re-closes LP: #127008)

 -- Bryce Harrington <email address hidden> Mon, 15 Oct 2007 00:18:33 -0700

[unggnu (unggnu)]

How to check the new behavior after install or are there still daily isos? I guess I will get not the native resolution with my laptop 1366x768 which works fine with RC but of course I am not sure.

[Pjotr12345 (computertip)]

Same problem here! With the installation of the daily build of October 15, with the Alternate CD of Gutsy.

During the second half of the installation, the screen becomes completely unreadable.
Video card: Intel videocard.

[unggnu (unggnu)]

Ok, I have tested it with the daily build of the 16th. It losses the ability to save any resolution in xorg.conf (there is no resolution saved) but thanks to xrandr I guess I get the correct native resolution and it works fine out of the box. Since all the Intel cards are shipped with the new Intel driver and if no other app has problems with an xorg.conf without a resolution it would be fine.
Btw. this was the first time that the usplash doesn't break up before X starts. Maybe that has something to do with it too.