[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X

Bug #586325 reported by Torsten Spindler
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Medium
linux (Ubuntu)
Fix Released
Medium
Unassigned
Lucid
Fix Released
Undecided
Unassigned

Bug Description

SRU Justification

Impact: when changing resolution X hangs due to GPU hangs

Fix Description: handles the case where the cursor is off the active area, ensuring the cursor ends up valid; an invalid cursor can lead to a GPU hang

Patch: TBA

Risks: non-affected systems may be impacted by the change which is in generic i915 code.

TEST CASE: Place the cursor in the bottom right and reduce resolution

===

NOTE: the machine is not necessarily hung as in some cases the use reports being able to see the logout dialog from the power button (albeit all corrupted), there are also results of ssh'ing into the machine.

===

Binary package hint: xserver-xorg-video-intel

When changing the resolution on a Fujitsu Siemens Esprimo and a Fulitsu Siemens 24" display, the X server is hung with colored graphic blocks.

Steps to reproduce:
1) Open gnome-display-properties
2) Select 1680x1050 or 1024x768 (instead of 1900x1200)
3) Screen may either turn black or start to flicker or both happens after each other

From the system itself only a hard power off is possible. It may be accessible via ssh but it cannot be tested because of a restricted testing environment.

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=30728)
Output of dmesg

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=30729)
Ouput of intel_gpu_dump (before resoluation change)

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=30730)
Ouput of intel_gpu_dump (after resolution change)

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=30731)
Xorg.0.log

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=30732)
Screenshot

Revision history for this message
In , Carl Worth (cworth) wrote :

Hi Christian,

Thanks for the bug report. I'm curious if the output of "xrandr --verbose" is
different between when things work and when things don't. Could you look at
that and perhaps attach the output if different.

I'll assign this bug to <email address hidden> who has some experience in this
area.

Thanks,

-Carl

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #6)
Hi Carl,

> Hi Christian,
>
> Thanks for the bug report. I'm curious if the output of "xrandr --verbose" is
> different between when things work and when things don't. Could you look at
> that and perhaps attach the output if different.

does xrandr work over ssh? How can I get the information when the graphics output is disturbed?

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #6)
> I'm curious if the output of "xrandr --verbose" is
> different between when things work and when things don't. Could you look at
> that and perhaps attach the output if different.

The output is nearly identical for both cases. Only the two lines with "Timestamp:" have different values.

For me it looks like the chance that resolution switching does not work is a little bit higher when I use krandrtray instead of xrandr.

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #6)
> I'll assign this bug to <email address hidden> who has some experience in this
> area.

Hi Carl,

is there any progress with this issue? Can I expect that this bug will be fixed in the near future? My housemate told me that he has similar problems on his laptop so I assume that more people are suffering from this error.

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Hi, Christian
     Sorry for the late response.
     Will you please try the latest linux kernel(for example:2.6.32.2) and see whether the issue still exists?(Please add the boot option of "drm.debug=0x06" and boot the system with KMS enabled).
     Will you please add the "modedebug" option in xorg.conf and attach the output of Xorg.0.log?
     >Option "modedebug" "True"

     It will be great if you can attach the output of intel_reg_dumper when the issue happens.

Thanks.

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

ping Chris...

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #11)
> ping Chris...
>

Sorry, I was on holiday for the previous days...

Unfortunately it's difficult for me to test with a particular Kernel/Xorg-Driver because I made the investigations with a Live-CD of my Linux-Distro. My real working environment is a little bit outdated an I think it might be difficult to update all components.

My housemate uses Gentoo, so for him it should be much easier to make the tests on his Laptop. Unfortunately he's also on holiday until the 8. January...

Do you know whether there's another Live-CD available which uses the versions of Kernel/xorg-driver which I shall test for you? I could also install the most recent Kernel on my machine but I think it would be difficult to update the X-Server and other required components...

regards
Christian

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=32515)
Output of dmesg (linux-2.6.32.2)

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=32516)
Xorg.0.log (linux-2.6.32.2)

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=32517)
Output of intel_reg_dumper (linux-2.6.32.2)

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #10)
> Will you please try the latest linux kernel(for example:2.6.32.2) and see
> whether the issue still exists?(Please add the boot option of "drm.debug=0x06"
> and boot the system with KMS enabled).
> Will you please add the "modedebug" option in xorg.conf and attach the
> output of Xorg.0.log?
> >Option "modedebug" "True"
>
> It will be great if you can attach the output of intel_reg_dumper when the
> issue happens.

In the meantime I've installed openSUSE 11.2 on hard disk. I hope I can respond faster now if you need further input.

Also after upgrading to 2.6.32.2 ("SUSE Kernel Of The Day"), the problem still persists (perhaps the possibility that the problem happens on mode switching may be even higher!). The same result is for the second PC (Laptop with Gentoo).

regards
Christian

Revision history for this message
In , Ceggers (ceggers) wrote :

Hi,

any news...?

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

(In reply to comment #17)
> Hi,
> any news...?
> regards
> Christian

Sorry for the late response.

Can you try the following patch set on 2.6.33-rc5 kernel and see whether
the issue still exists?
    >http://lists.freedesktop.org/archives/intel-gfx/2010-January/005505.html

BTW: the patch 1 can be skipped as it is already shipped in 2.6.33-rc5 kernel.

Thanks.
   Yakui

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #18)
> Can you try the following patch set on 2.6.33-rc5 kernel and see whether
> the issue still exists?
> >http://lists.freedesktop.org/archives/intel-gfx/2010-January/005505.html

Dear Yakui,

kernel compilation stressed my hard drive a little bit. Maybe I'll have to replace it...

I hope I can continue testing the next days and can give you the result end of this week.

For now I've tested with "vanilla" 2.6.33-rc5+your patches. With i915.modeset=1 the monitor goes to standby mode in the middle of the boot process (maybe when X starts).

regards
Christian

Revision history for this message
In , Michael Fu (michael-fu-intel) wrote :

(In reply to comment #16)
> (In reply to comment #10)
> Also after upgrading to 2.6.32.2 ("SUSE Kernel Of The Day"), the problem still
> persists (perhaps the possibility that the problem happens on mode switching
> may be even higher!). The same result is for the second PC (Laptop with
> Gentoo).
>

Do you mean you have same problem another PC (laptop with Gentoo)? What's it HW configuration ? Is it the same as the first PC? thanks.

> regards
> Christian
>

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #20)
Dear Michael,
>
> Do you mean you have same problem another PC (laptop with Gentoo)? What's it HW
> configuration ? Is it the same as the first PC? thanks.

1st PC: Intel mainboard with i965G chipset
2nd PC: Laptop with GM965 (X3100) chipset

All test outputs are generated on the first system, but the symptoms are the same on the second system.

I'll try to test with kernel 2.6.33-RC5 the next days after replacing my defective hard drive.

regards
Christian

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #18)
> Can you try the following patch set on 2.6.33-rc5 kernel and see whether
> the issue still exists?
> >http://lists.freedesktop.org/archives/intel-gfx/2010-January/005505.html
>
After serious hard drive problems I've reinstalled everything and tested 3 configurations (on System "1"):

a) 2.6.31 (openSUSE, w/o your patches)
b) 2.6.33-rc5 (vanilla, w/o your patches)
c) 2.6.33-rc5 (vanilla, w/ your patches)

Results:
a) Problems when resolutions is changed with krandrtray (original problem, looks like "lost of sync" on crts)
b) Similar to a), but usually the monitor enters standby mode instead of showing the "lost of sync" pattern)
c) The monitor enters standby mode during booting. It seems that this happens when the i915 module is loaded (not when starting X as previously guessed). So I could not test what happens when resolution is changed with krandrtray.

So something has changed between 2.6.31 and 2.6.33, but this doesn't solve the problem. And unfortunately your patches also didn't help.

regards
Christian

I'll be on vacation between Feb. 12 and Feb. 28

Revision history for this message
In , Ceggers (ceggers) wrote :

d) 2.6.33-rc7 (vanilla, w/o your patches)

Results:
d) Same as b)

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #23)
2.6.33 (final) also doesn't work.

Is there any chance that this bug will be fixed in the near future?

regards
Christian

Revision history for this message
In , Mr. Anderson (walch-martin) wrote :

If it helps in any way: I have the same problem with

System environment:
 -- chipset: G965
 -- system architecture: x86_64
 -- xf86-video-intel: git snapshot with last commit 8ece6cf5afa1bb0d8d9328696422f42f3c3adbd6 from Sat Mar 6 14:09:12 2010 -0500
 -- xserver: Server 1.7.5
 -- mesa: 7.7
 -- libdrm: 2.4.17
 -- kernel: 2.6.31-gentoo-r6
 -- Linux distribution: Gentoo
 -- Machine or mobo model: Intel DG965SS
 -- Display connector: VGA/DE-15

I have *two* working resolutions with a monitor "Captiva E1902W" (cheap flatscreen): 1440x900@59,9 and 1280x1024@75.0. I can switch between these two modes and everything works fine. For any other tested mode (1024x768, 800x600, 640x480), I encounter the same out-of-sync problem as descried above. From that state, the only way to recover I have found is a reboot. Switching back to a working mode does not help: the screen stays corrupted. Switching to a VT makes things even worse (black screen, sometimes freeze when afterwards switching back to X).

Please let me know if you need any further information from me.

Revision history for this message
In , Mr. Anderson (walch-martin) wrote :

I have tested this again with a recent git snapshot of xf86-video-intel, but with a different monitor (acer AL1917). As far as I remember, this problem existed with both monitors, the Captiva E1902W and the acer AL1917.

However, with the acer monitor, I just made about 20 mode switches and I did not experience any problems. Maybe this has been fixed during the last weeks?

I will check with the Captiva monitor as soon as I get my hands on it again. :)

changes that happended to my system configuration:

-- xf86-video-intel: git snapshot from one day ago (last commit
362a49e71fc41541b6dc121660d98e29da4b14e8)
-- xserver: Server 1.7.6
-- mesa: git snapshot from one day ago (last commit
9eaadfeaa54d15fc3eb90d4137795ace4f920b2f)
-- libdrm: 2.4.19
-- kernel: 2.6.31-gentoo-r10

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #26)
> changes that happended to my system configuration:
>
> -- xf86-video-intel: git snapshot from one day ago (last commit
> 362a49e71fc41541b6dc121660d98e29da4b14e8)
> -- xserver: Server 1.7.6
> -- mesa: git snapshot from one day ago (last commit
> 9eaadfeaa54d15fc3eb90d4137795ace4f920b2f)
> -- libdrm: 2.4.19
> -- kernel: 2.6.31-gentoo-r10
>
I've updated my openSUSE 11.2 to the following package versions:
-- xf86-video-intel: git snapshot from 2010-03-10
-- xserver: Server 1.8.0 RC2
-- mesa: 7.7.99
-- libdrm: 2.4.19
-- kernel: 2.6.33

Result: No changes. The problem is still present as before. Btw: Does it make any sense to update components other than the kernel?

> However, with the acer monitor, I just made about 20 mode switches and I did
> not experience any problems. Maybe this has been fixed during the last weeks?

This doesn't surprise me. Sometimes everything seems to work, but I only need to reboot once and the problem is present again.

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

> >
> I've updated my openSUSE 11.2 to the following package versions:
> -- xf86-video-intel: git snapshot from 2010-03-10
> -- xserver: Server 1.8.0 RC2
> -- mesa: 7.7.99
> -- libdrm: 2.4.19
> -- kernel: 2.6.33
>
> Result: No changes. The problem is still present as before. Btw: Does it make
> any sense to update components other than the kernel?

Sorry for the late response.
Can you add the boot option of "drm.debug=0x04" and attach the output of dmesg, xrandr -q --verbose?

Do you have an opportunity to try another monitor and see whether the issue still can be reproduced?

Thanks.

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34533)
dmesg (for comment #28)

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34534)
xrandr -q --verbose (for comment #28)

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #28)
> Sorry for the late response.
> Can you add the boot option of "drm.debug=0x04" and attach the output of dmesg,
> xrandr -q --verbose?
Done

> Do you have an opportunity to try another monitor and see whether the issue
> still can be reproduced?

Same problem with Monitor A, B and A+B.

A: HP LP2065, 20.1" LCD, DVI-D (SDVO card), 9.2 kg
B: Viewsonic E790, 19" CRT, VGA, 22.5 kg (~30 kg when moving from/to the basement)

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Created an attachment (id=34537)
try the debug patch that updates the self-refresh watermark on 965 platform

From the log in comment #29 it seems that the SR watermark is 1. It is incorrect.

Will you please try the attached debug patch on 2.6.33 kernel and see whether the issue still exists?

thanks.

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Created an attachment (id=34538)
try the debug patch that updates the self-refresh watermark on 965 platform

Sorry for the typo.

Please try the updated patch.

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34575)
dmesg (for comment #33)

Applied you patch to 2.6.33. Result is (at least nearly) the same: After switching resolution from 1600x1200 to 1024x768, the monitor went to standby mode. After a few seconds I pressed ESC and krandrtray switched back to the previous settings.

Then I tried another mode change which produced the "out of sync" pattern. Some other guy has posted a screenshot which shows the result [1]. Reverting to the previous mode didn't work anymore.

After that I tried to switch to console which filled the screen completely which a single color (also the same behavior as before).

[1]
http://lists.freedesktop.org/archives/intel-gfx/2009-September/004362.html

Revision history for this message
In , Mr. Anderson (walch-martin) wrote :

(In reply to comment #27)
> This doesn't surprise me. Sometimes everything seems to work, but I only need
> to reboot once and the problem is present again.

You are right. A reboot broke things again. I made a lot of reboots now and I have not seen any pattern in when things break and when not.

I compared the dmesg output with drm.debug=0x04 from a working case and from a broken case: I did not see any differences besides minor changes in detected cpu frequency, BogoMIPS and the order of some lines about hard disks and network interfaces.

However, I guess I am missing something in my kernel configuration, because I see far less drm output than in the log file in comment #29.

$ grep drm dmesg
Command line: root=/dev/sdb1 drm.debug=0x04
Kernel command line: root=/dev/sdb1 drm.debug=0x04
[drm] Initialized drm 1.1.0 20060810
[drm] DAC-6: set mode 1280x1024 17
[drm] fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #35)
> You are right. A reboot broke things again. I made a lot of reboots now and I
> have not seen any pattern in when things break and when not.

Did you use krandrtray or xrandr? Please try "xrandr -q --verbose" and then switch through all available modes

# xrandr --output DVI1 --mode 0x45
# xrandr --output DVI1 --mode 0x44
# xrandr --output DVI1 --mode 0x46
...

In my case, for instance mode 0x49 (1024x768@85Hz) doesn't work. But this mode is chosen by xrandr when no explicit refresh rate is given. With xrandr I could successfully revert to the previous (working) mode by blindly using the bash history.

Assumptions:
- Maybe that krandrtray (which I used for nearly all previous tests) also choses 85Hz for 1024x768 regardless of the refresh rate which is actually selected by the user.

- Maybe that krandrtray has a bug in the "restore to the previous mode" function.

Could you please check this?

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Hi, Christian
     From the dmesg log it seems that the VESA fb driver is also loaded.
    > vesafb: framebuffer at 0x80000000, mapped to 0xffffc90008980000, using 7500k, total 7616k
     > vesafb: mode is 1600x1200x16, linelength=3200, pages=1

     And after the i915 driver is loaded, the following message is complained:
     >fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver

     Can you disable the vesa fb driver in kernel configuration and see whether the issue still exists?

Thanks.

     I

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34795)
dmesg (for comment #38)

> Can you disable the vesa fb driver in kernel configuration and see whether the issue still exists?

Without the vesa fb driver there no big difference, only the "vga=" kernel parameter doesn't work anymore. The display switches from text mode to higher resolution later when the i915 module is loaded.

Yesterday I had again the situation where I could NOT recover from a "bad mode" (0x49) to a working one. After running "xrandr --output DVI1 --mode 0x49" the monitor went to standby mode. Then I tried to revert to mode 0x43, which resulted in the "out of sync" pattern (see attached dmesg).

Intermediary result:
At least some modes which are shown by "xrandr -q --verbose" are "bad". Switching to these modes puts the monitor in standby mode. Sometimes it's possible to switch back to a working mode by blindly using the shell history. Other times this causes the "out of sync" pattern.

For the moment I'm not sure whether the problem can only happen with specific "bad modes" or also with other ones.

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

(In reply to comment #38)
> Created an attachment (id=34795) [details]
> dmesg (for comment #38)
>
> > Can you disable the vesa fb driver in kernel configuration and see whether the issue still exists?
>

Thanks for the testing.

> Without the vesa fb driver there no big difference, only the "vga=" kernel
> parameter doesn't work anymore. The display switches from text mode to higher
> resolution later when the i915 module is loaded.

It seems that the issue still exists after removing the vesa fb driver.

>
> Yesterday I had again the situation where I could NOT recover from a "bad mode"
> (0x49) to a working one. After running "xrandr --output DVI1 --mode 0x49" the
> monitor went to standby mode. Then I tried to revert to mode 0x43, which
> resulted in the "out of sync" pattern (see attached dmesg).

The message of "out of sync" is related with SDVO DVI. I am not sure whether the issue is related with SDVO.

Can you connect this monitor by using VGA connector and see whether the issue can also be reproduced?

Thanks
   Yakui

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Created an attachment (id=34811)
try the debug patch that dumps the output pixel clock range of sdvo device

From the dmesg log we can get one message related with SDVO.
    >drm:intel_sdvo_debug_write], SDVOB: W: 16 48 3F 40 30 62 B0 32 40 (SDVO_CMD_SET_OUTPUT_TIMINGS_PART1)
    > [drm:intel_sdvo_debug_response], SDVOB: R: (Not supported)

    It seems that this SDVO device can't support the command of setting the output timing of SDVO device. I am not sure whether the high resolution is supported by this SDVO device.

    Will you please try the debug patch and attach the output of dmesg?

Thanks.
   Yakiu

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34819)
dmesg (for comment #41)

(In reply to comment #39)
> The message of "out of sync" is related with SDVO DVI. I am not sure whether
> the issue is related with SDVO.

Sorry, this may be a misunderstanding. "out of sync" is no kernel message, it is a description of the distortion of my screen content. It looks similar to this: http://lists.freedesktop.org/archives/intel-gfx/attachments/20090925/bf583987/attachment-0001.png

When I press any key or move the mouse, the content starts moving very quickly which looks similar to "out of sync" problems on very old crts. If you need, I can try to take a picture with my camera.

> Can you connect this monitor by using VGA connector and see whether the issue
> can also be reproduced?
Done. I've connected the same monitor to the vga connector instead of dvi. The result is the same, but with this configuration the output of xrandr shows different mode entries (see next attachment). This time the 0x4a was the "bad" mode.

I'll test comment #40 in the next minutes...

regards
Christian

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34820)
xrandr -q --verbose (for comment #41)

xrandr -q --verbose with HP LP2065 TFT connected via VGA

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34821)
dmesg (for comment #43)

(In reply to comment #40)

> Will you please try the debug patch and attach the output of dmesg?

Done

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

Created an attachment (id=34906)
try the debug patch that disable memory self-refresh on 965 desktop platform

Will you please try the attached debug patch and see whether the issue still exists?

Thanks.

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34924)
dmesg (for comment #45)

(In reply to comment #44)

It seems that your patch changed the behavior a little bit. Now I need more mode switches to get an error. When the error happens, the whole screen is white and flickers a little bit. It is not possible to recover from this state by switching back to the previous state.

Do we have two independent errors?

regards
Christian

Revision history for this message
In , yakuizhao (yakui-zhao) wrote :

(In reply to comment #45)
> Created an attachment (id=34924) [details]
> dmesg (for comment #45)
>
> (In reply to comment #44)
>
> It seems that your patch changed the behavior a little bit. Now I need more
> mode switches to get an error. When the error happens, the whole screen is
> white and flickers a little bit. It is not possible to recover from this state
> by switching back to the previous state.

It seems that you still use the DVI to connector the monitor. How about using VGA?

thanks.
>
> Do we have two independent errors?
>
> regards
> Christian

Revision history for this message
In , Ceggers (ceggers) wrote :

Created an attachment (id=34948)
dmesg (for comment #47)

(In reply to comment #46)

> It seems that you still use the DVI to connector the monitor.
This is correct. I use VGA only if requested.

> How about using VGA?
Result is very similar compared to DVI:

- With VGA, mode 0x4a puts the monitor to standby mode which can usually be undo be switching back the previous mode (0x49 in my test). Mode 0x4d causes the "flickering white screen". Sometimes the white screen is about half a second and then it works. But when I switch the second time to this mode the error stays and I can not switch to a working mode again.

- With DVI I have the same results but with mode 0x49 and 0x4c instead of 0x4a and 0x4b.

regards
Christian

Revision history for this message
Torsten Spindler (tspindler) wrote : changing resolution results in non working X

Binary package hint: xserver-xorg-video-intel

When changing the resolution on a Fujitsu Siemens Esprimo and a Fulitsu Siemens 24" display, the X server is hung with colored graphic blocks.

Steps to reproduce:
1) Open gnome-display-properties
2) Select 1680x1050 or 1024x768 (instead of 1900x1200)
3) Screen may either turn black or start to flicker or both happens after each other

From the system itself only a hard power off is possible. It may be accessible via ssh but it cannot be tested because of a restricted testing environment.

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Torsten,

Please run the command 'apport-collect BUGNUMBER', which will attach several files we need for debugging.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Incomplete
Revision history for this message
Torsten Spindler (tspindler) wrote :

Output of report-hw

Revision history for this message
Torsten Spindler (tspindler) wrote :

Xorg.0.log.old from the computer.

@ Bryce: The system is behind a firewall, it can only reach the Internet via proxy. AFAIK apport won't run in this situation.

Revision history for this message
Torsten Spindler (tspindler) wrote :

$ apport-collect 586325
Error connecting to Launchpad: 'NoneType' object has no attribute 'makefile'
You can reset the credentials by removing the file "/u/m500369/.cache/apport/launchpad.credentials"

Revision history for this message
Torsten Spindler (tspindler) wrote :
Bryce Harrington (bryce)
tags: removed: needs-xorglog
tags: removed: needs-lspci-vvnn
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Torsten Spindler (tspindler) wrote :

On another esprimo model the resolution change works. I'll attach the output of lspci --vvnn and report-hw for the working system as well.

Revision history for this message
Torsten Spindler (tspindler) wrote :
Revision history for this message
Torsten Spindler (tspindler) wrote :

The dmidecode says that the non working system is an Esprimo E, the working system is an Esprimo E5730. I will update the bug description to reflect this.

summary: - changing resolution results in non working X
+ Fujitsu Siemens Esprimo E: changing resolution results in non working X
Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
Torsten Spindler (tspindler) wrote : Re: Fujitsu Siemens Esprimo E: changing resolution results in non working X

Oops, the problem occurs on Lucid - I guess I filed it against the wrong package as it's now part of the kernel stack. Sorry.

Revision history for this message
Stenten (stenten) wrote :

Does the capslock light work? Can you REISUB?

Are you sure it's actually freezing and not just blacking out the screen? If you play music or something, does it continue after the screen shuts off? The two resolutions you mentioned are different ratios than the 1900x1200, so that might be it.

tags: added: 965q i386 lucid
removed: hardy
Stenten (stenten)
summary: - Fujitsu Siemens Esprimo E: changing resolution results in non working X
+ [965q] Fujitsu Siemens Esprimo E: changing resolution results in non
+ working X
Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Incomplete
Bryce Harrington (bryce)
tags: added: resolution
Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
Torsten Spindler (tspindler) wrote : Re: [Bug 586325] Re: Fujitsu Siemens Esprimo E: changing resolution results in non working X

On Sat, 2010-05-29 at 05:26 +0000, Stenten wrote:
> Does the capslock light work? Can you REISUB?

What does REISUB mean here?

> Are you sure it's actually freezing and not just blacking out the
> screen?

I'm confident it is blacking out/flickering the screen, not freezing the
complete system. E.g. when it is flickering one can see the power off
dialogue popping up when pressing the power button.

> If you play music or something, does it continue after the
> screen shuts off?

We have to test this. @ Hans-Gerd: can you try this on the Esprimo E?

Revision history for this message
Stenten (stenten) wrote : Re: [965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X

Please reboot your system and then reproduce the issue. Then type Ctrl+Alt+F1. Login and then type "cat /var/log/Xorg.0.log Xorg.0.log.txt". Also run "cat /var/log/dmesg dmesg.txt. These will create two log files named "Xorg.0.log.txt" and "dmesg.txt" in your home folder.

Restart X by running "startx". If that doesn't work, just reboot your computer by typing "sudo reboot". Then attach the two log files and explain what you did to reproduce the issue (which resolution you chose, etc).

It would be nice if you could pinpoint exactly what makes the screen go blank and what makes it flicker. Does it matter which resolution you choose? etc.

Revision history for this message
Torsten Spindler (tspindler) wrote : Re: [Bug 586325] Re: [965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X

On Mon, 2010-05-31 at 09:23 +0000, Stenten wrote:
> Please reboot your system and then reproduce the issue. Then type
> Ctrl+Alt+F1.

Unfortunately the virtual console is no longer available due to the
graphics problem, e.g. no reaction upon crtl-alt-f1. @ Hans-Gerd: can
you use your Esprimo E and ssh to it to get the needed debug output?

Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote : Re: [965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X
Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :
Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :

To answer the open questions:

- power the monitor off and on again still seeing the effect
- playing music continues while the display is powered off

I have attached a .mov file that show's what happens.

Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :

To answer the open questions:

- power the monitor off and on again still seeing the effect
- playing music continues while the display is powered off

I have attached a .mov file that show's what happens.

Stenten (stenten)
summary: - [965q] Fujitsu Siemens Esprimo E: changing resolution results in non
+ [i965q] Fujitsu Siemens Esprimo E: changing resolution results in non
working X
Revision history for this message
Pedro Villavicencio (pedro) wrote :

since the requested information was provided to the bug report I'm marking this as confirmed, thanks all.

Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Low
status: Incomplete → Confirmed
Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Chris Halse Rogers (raof) wrote :

Looking at the video it's obvious that parts of the framebuffer are getting displayed, but clearly this is something more than just setting a bad display mode - otherwise the system would return to the working resolution after the “Do you want to keep these settings” timeout elapsed. Indeed, from the most recent Xorg log it looks like the timeout *has* elapsed, and the driver has reset the framebuffer size to 1920x1200.

Since the logs, particularly the dmesg, don't contain any errors, it would be very useful if you could reboot, append “drm.debug=0x06” to the kernel command line, and reproduce this. That will make the intel kernel module (which is likely to be the problem here) print a lot of debugging information into dmesg, which should be recorded in /var/log/kern.log. If you could attach your /var/log/Xorg.0.log and /var/log/kern.log after reproducing with drm.debug=0x06, that would be great.

Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :
Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :
Changed in xserver-xorg-video-intel (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Chris Halse Rogers (raof) wrote :

Thanks for those logs. The interesting part appears here, when you attempt to switch resolutions:

Jun 9 08:31:07 c399693 kernel: [ 60.921838] [drm:drm_mode_debug_printmodeline], Modeline 27:"1920x1200" 60 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9
Jun 9 08:31:07 c399693 kernel: [ 60.921844] [drm:drm_mode_debug_printmodeline], Modeline 31:"" 0 65000 1024 1048 1184 1344 768 771 777 806 0x0 0xa

Modeline 31 is not on the list of probed modelines from the EDID, but is almost the same as the 1024x768 modeline. Similarly, when trying to switch back it switches to another modeline which isn't listed in the EDID probe, but is almost the same as the 1920x1200 modeline.

I'll poke through the code to see what might be happening here.

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

Created an attachment (id=36274)
dmesg for 2.6.33.2 drm

I think that we're also seeing this bug in Ubuntu. I've attached the relevant dmesg from our bug https://bugs.edge.launchpad.net/bugs/586325 .

In this case it's failing on the i965q card found in the Fujitsu Siemens Esprimo E. For several monitors mode switching from the initial preferred resolution fails, and switching back does not restore correct behaviour. Apparently for some monitors mode switching works fine.

Video of mode switch failure is here:
http://launchpadlibrarian.net/49431241/IMG_0569.MOV
lspci:
http://launchpadlibrarian.net/49203360/lspci-vvnn
Xorg log:
http://launchpadlibrarian.net/49994258/Xorg.0.log

If you have something which needs more testing, just ask.

Revision history for this message
Chris Halse Rogers (raof) wrote :

I've had a look through all the modesetting codepaths and those suspicious modelines are entirely benign. The codepaths for both the working system and the non-working systems appear to be the same, so this is going to be a subtle bug.

I'll forward this bug upstream.

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #48)
Thank you for contributing to my bug report. Unfortunately it has been a little bit quiet here for some time.

I hope that the developers at Intel are able AND willing to fix this. I think that changing the screen resolution is a "basic" feature which should be implemented correctly by any graphics driver. Particularly laptop users might want to connect external beamers/displays to their devices without crashing their whole graphical system. I'm quite sure that on other platforms this would have been repaired much earlier.

I've spent many hours providing test feedback for this bug (among other things this required to buy another hard disk and to install "unstable" versions of several packages). It seems that nobody was able to get the real error from my descriptions.

I suggest that some paid developer at Intel should get a board/laptop which is affected and try for him-/herself. When he/she was successful in reproducing and fixing the error I'm inclined to test again...

regards
Christian

Revision history for this message
In , Daniel Stone (daniels) wrote :

On Tue, Jun 15, 2010 at 10:05:01AM -0700, <email address hidden> wrote:
> Thank you for contributing to my bug report. Unfortunately it has been a
> little bit quiet here for some time.

It's been four days since Yakui last offered a patch, of which two were
the weekend.

> I hope that the developers at Intel are able AND willing to fix this. I think
> that changing the screen resolution is a "basic" feature which should be
> implemented correctly by any graphics driver. Particularly laptop users might
> want to connect external beamers/displays to their devices without crashing
> their whole graphical system. I'm quite sure that on other platforms this would
> have been repaired much earlier.

Actually, I know of very, very few other operating system vendors who
will take a bug report from the general public (particularly if that
person has paid $0 for it), and have a suggested fix prepared within a
couple of days.

Of course, if you have experience of OS X or Windows teams having fixed
a bug you've reported quicker than that, please let me know. Else, just
sit tight and wait.

> I've spent many hours providing test feedback for this bug (among other things
> this required to buy another hard disk and to install "unstable" versions of
> several packages). It seems that nobody was able to get the real error from my
> descriptions.

If all bugs could be magically solved by looking at a single logfile,
then half of us would be out of a job.

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #50)
> On Tue, Jun 15, 2010 at 10:05:01AM -0700, <email address hidden>
> wrote:
>
> It's been four days since Yakui last offered a patch, of which two were
> the weekend.

4 days? For me it looks more like 2 months and 4 days. And 12th of April was a Monday...

> Actually, I know of very, very few other operating system vendors who
> will take a bug report from the general public (particularly if that
> person has paid $0 for it), and have a suggested fix prepared within a
> couple of days.

Does Intel sell operating systems? Are you offering me to fix this for money?

> Of course, if you have experience of OS X or Windows teams having fixed
> a bug you've reported quicker than that, please let me know. Else, just
> sit tight and wait.

The initial bug report has been created more than half a year ago. What do you think is an adequate time for a hardware vendor to fix a driver bug? I've bought a mainboard with Intel graphic because I wanted to have good Linux support. So now I'm at least irritated that such a basic function doesn't work properly.

> If all bugs could be magically solved by looking at a single logfile,
> then half of us would be out of a job.

I know that it is at least difficult to fix this bug. Therefore I've proposed that the developer(s) at Intel should get a mainboard from stock instead of trying to solve such complicated things remotely.

May I ask how you are related to this bug, because I have never seen you contributing anything to this topic before.

regards
Christian

Revision history for this message
In , Daniel Stone (daniels) wrote :

On Tue, Jun 15, 2010 at 12:53:58PM -0700, <email address hidden> wrote:
> --- Comment #51 from Christian Eggers <email address hidden> 2010-06-15 12:53:58 PDT ---
> (In reply to comment #50)
> > On Tue, Jun 15, 2010 at 10:05:01AM -0700, <email address hidden>
> > wrote:
> >
> > It's been four days since Yakui last offered a patch, of which two were
> > the weekend.
>
> 4 days? For me it looks more like 2 months and 4 days. And 12th of April was a
> Monday...

Oops, misread the date. My point remains, however. (The last time I
reported a bug on OS X, by the way, was 2003. It was still unfixed as
of 2008, at least. And this was something I actually paid money for!)

> > Actually, I know of very, very few other operating system vendors who
> > will take a bug report from the general public (particularly if that
> > person has paid $0 for it), and have a suggested fix prepared within a
> > couple of days.
>
> Does Intel sell operating systems? Are you offering me to fix this for money?

No, I'm not. If you paid anyone for it, I recommend you contact them
for a full refund.

> > If all bugs could be magically solved by looking at a single logfile,
> > then half of us would be out of a job.
>
> I know that it is at least difficult to fix this bug. Therefore I've proposed
> that the developer(s) at Intel should get a mainboard from stock instead of
> trying to solve such complicated things remotely.
>
> May I ask how you are related to this bug, because I have never seen you
> contributing anything to this topic before.

Mainly, I just sit on <email address hidden> and respond whenever someone
with an overdeveloped sense of entitlement starts flaming people for
daring to not have their bug (which is one of quite a large number)
fixed yet.

Revision history for this message
Torsten Spindler (tspindler) wrote :

Here the output of get-edid from an affected system and display:#
http://pastebin.ubuntu.com/456801/

Here the parse-edid output:
http://pastebin.ubuntu.com/456799/

It seems that the get-edid program does not cope well with the information:

*********** Something special has happened!
Please contact the author, Matthew Kern
E-mail: <email address hidden>
Please include full output from this program (especially that to stderr)

I will contact the author.

Revision history for this message
Torsten Spindler (tspindler) wrote :

The problem is also present in Ubuntu 9.10, tested with the live CD.

Revision history for this message
Torsten Spindler (tspindler) wrote :

The problem also exists on todays (2010-06-29) Maverick image.

Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :
Revision history for this message
Torsten Spindler (tspindler) wrote :

The log comes from this RPM package's intel driver on RHEL5: xorg-x11-drv-i810-1.6.5-9.19.el5

Revision history for this message
Torsten Spindler (tspindler) wrote :

We tested today a patched kernel driver from http://cooperteam.net/linux-image-2.6.32-23-generic_2.6.32-23.38~965NoSelfRefresh_i386.deb, unfortunately the problem was not solved. The display flashed in white.

Revision history for this message
Chris Halse Rogers (raof) wrote :

Hrm. I don't seem to have asked whether this bug is still present when kernel modesetting is disabled, which is a bit of an oversight! Has disabling kernel modesetting and reverting to user modesetting been tried?

Adding “nomodeset” to the kernel command line will disable kernel modesetting. This will give a slightly worse boot experience - the splash screen will not be high-resolution, and will not seamlessly transition to X, but should otherwise function as normal.

If that sets the resolution correctly then we've got a workaround and a successful codepath to compare to.

Revision history for this message
Torsten Spindler (tspindler) wrote :

Unfortunately the nomodeset option does not improve the situation.

1) Change resolution
2) Screen turns black, starts to flicker
3) Screen reverts to previous settings and stays completely black, no more flickering

Revision history for this message
Torsten Spindler (tspindler) wrote :

A test with Ubuntu 8.04.4 live CD showed a similar behaviour. The screen flickered in white and brown.

Revision history for this message
Torsten Spindler (tspindler) wrote :

Calling xrandr from the command line with 60 Hertz did work:
$ xrandr -s 1024x768 --rate 60

Revision history for this message
Torsten Spindler (tspindler) wrote :

It seems the system is not corrupted at all times - right now I can change the resolution without ill effect, be it via xrandr (comment 33), be it with gnome-display-properties.

Revision history for this message
Torsten Spindler (tspindler) wrote :

Hypothesis is, that using xrandr on the command line is more robust than using gnome-display-properties:

Series of 10 tests,
this sequence repeated 5 times per test:
xrandr -s 1024x768 --rate 60
xrandr -s 1920x1200

Results:
working: x x x xxxx
broken : X X X
          broke during 3rd attempt when going to 1024x768, flickering screen
            broke during 2nd attempt when going to 1024x768, flickering screen
              broke during 5th attempt when going to 1920x1200, display slept

Observation: after resolution change to 1920x1200 pixel errors where observed
on the lower right screen, looking like a gradient developing from lower right
to center of screen. This happened some, but not all times.

Series of 5 tests,
using gnome-display-properties

Results:
working:
broken: XXXXX
         broke during 1st attempt when going to 1024x768, flickering screen
          same as 1st test
           same as 1st test
            same as 1st test
             same as 1st test

Revision history for this message
Torsten Spindler (tspindler) wrote :

Attached are two dmesg outputs, given with drm debug set to 4. One is where the xrandr -s 1024x768 --rate 60 worked, the other one where it failed.

Revision history for this message
Torsten Spindler (tspindler) wrote :
Revision history for this message
In , Chris Halse Rogers (raof) wrote :

Created an attachment (id=36780)
Break the mouse cursor, fix resolution changing

I suspect that the resolution changes are only a part of this problem. Now that I've got some hardware to test on I noticed that moving the mouse changes the behaviour of the broken screen, so I suspected that the hardware cursor might be involved.

Investigating this, I came up with the attached patch which simply causes all calls to set the cursor to set a null cursor. This fixes resolution changing for me - I can cycle through the xrandr mode list to my heart's content.

Of course, this patch also ensures that you can never see a mouse cursor, so it's hardly a fix.

Revision history for this message
In , Chris Wilson (ickle) wrote :

Wow, never would have suspected that. The next step would seem to be to test disabling the cursor around modesetting.

Revision history for this message
Chris Halse Rogers (raof) wrote :

I've now got a Q965 system to test locally, and my isn't this bug fun!

I've come to suspect that this might be a hardware-cursor issue. For me, when this bug gets triggered, moving the mouse up and down changes the piece of the framebuffer that's displayed, and moving the mouse left and right changes how fast it flickers - to the point where moving the mouse to a certain x-position results in a stable (albeit vertically shifted) display.

I'll test whether fiddling with this cursor code makes a difference.

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #53)
> Created an attachment (id=36780) [details]
> Break the mouse cursor, fix resolution changing
>
Thank you for giving the hint for the real source of the problem:

http://fstatic1.mtb-news.de/img/photos/3/3/8/8/0/_/large/ScheeseamAbgrund.JPG

The bike is the cursor, the cliff is your screen. Now reduce the size of the cliff about 10-50% without moving the bike...

How can we move the bike BEFORE reducing the size of the cliff?

regards
Christian

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

Yup, just disabling the cursor around modesetting works.

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #56)
> Yup, just disabling the cursor around modesetting works.

Does this also work when the cursor is in an area which will be "outside" the new resolution? Where will the cursor be positioned when it's re-enabled after switching?

Instead of disabling the cursor it may be sufficient to ensure that the cursor will not be outside the new resolution. I "parked" my cursor on the upper left of the screen and cycled resolution about fifty times without any problems.

I'll be on vacation from Thursday until Sunday, 18th. If you would provide a patch, I'll test either today or in the week after my vacation.

regards
Christian

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

(In reply to comment #57)
> (In reply to comment #56)
> > Yup, just disabling the cursor around modesetting works.
>
> Does this also work when the cursor is in an area which will be "outside" the
> new resolution? Where will the cursor be positioned when it's re-enabled after
> switching?

It does indeed work - until you move the pointer.

>
> Instead of disabling the cursor it may be sufficient to ensure that the cursor
> will not be outside the new resolution. I "parked" my cursor on the upper left
> of the screen and cycled resolution about fifty times without any problems.
>

I've also just noticed this. So, the problem manifests when the pointer is outside the framebuffer and gets touched. Is this as simple as the cursor scribbling on memory it's not meant to?

Revision history for this message
In , Chris Wilson (ickle) wrote :

Created an attachment (id=36827)
Unset cursor if out of bounds.

Following on from Christopher's hint is this patch that should disable the cursor on a mode change if it results in an invalid cursor position.

Revision history for this message
Chris Halse Rogers (raof) wrote :

Fiddling with the cursor code does indeed make a difference. Hiding the cursor before changing resolution and showing it afterwards fixes this for me.

Once I've got a driver that does this properly (currently it unconditionally re-shows the cursor after mode switch) I'll attach it here for testing.

The changes should be small and self-contained, making this appropriate for an SRU.

Revision history for this message
In , Chris Wilson (ickle) wrote :

Created an attachment (id=36828)
Unset cursor if out of bounds.

Revision history for this message
In , Chris Wilson (ickle) wrote :

I scanned through the docs I have on hand and the only caveat for cursor positioning is that the VGA popup cursor must entirely be within the bounds of the pipe. Since we don't use that cursor...

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

(In reply to comment #61)
> I scanned through the docs I have on hand and the only caveat for cursor
> positioning is that the VGA popup cursor must entirely be within the bounds of
> the pipe. Since we don't use that cursor...

It's in the X/Y sign bit register documentation for CURAPOS and CURBPOS - “For normal high resolution display modes, the cursor must have at least a single pixel positioned over the active screen.” (p143, p148 of the hardware registers docs).

(In reply to comment #60)
> Created an attachment (id=36828) [details]
> Unset cursor if out of bounds.

Ding! This works. Thanks for fixing this while I slept :)

Tested-by: Christopher Halse Rogers <email address hidden>

Revision history for this message
In , Ceggers (ceggers) wrote :

(In reply to comment #60)
> Created an attachment (id=36828) [details]
> Unset cursor if out of bounds.

Thank you!!!

This patch works great for xrandr but not for krandrtray. With krandrtray the problem is still present when the mouse cursor is outside the new resolution.

When I move the control bar (and systray) to the upper left of the screen, everything is fine. When the kdrandrtray icon is on the bottom right, the graphic crashes.

Perhaps there's a bug in krandrtray, because even if the graphics doesn't crash, the window sizes are not adjusted to the new resolution (in contrast to xrandr). But even in this case that should not provoke a crash of the graphics.

I'll be on vacation for the next 10 days, so I can not provide any test feedback during this time. If the problem with krandrtray is too complicated, I suggest to apply the current patch immediately in treat the krandrtray problem as a different bug.

regards
Christian

Revision history for this message
Chris Halse Rogers (raof) wrote :

Moving this to the kernel. There's a kernel patch available https://bugs.freedesktop.org/attachment.cgi?id=36828 which I've tested fixes this, and corresponds with what the hardware docs say.

I'll get in contact with the kernel team to get this moving on their end.

affects: xserver-xorg-video-intel (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Low → Medium
Revision history for this message
Chris Halse Rogers (raof) wrote :

The upstream patch needs a tiny bit of futzing to apply to the 2.6.33 drm we've got in Lucid's 2.6.32-24 kernel. Attached is a git commit applying it to our kernel tree.

tags: added: kernel-graphics kernel-needs-review
Revision history for this message
In , Chris Wilson (ickle) wrote :

Christian, I've seen other reports where kdrandrtray behaves differently than xrandr, so I'm inclined to believe that therein lies a few other bugs.

I'll send this off to Eric with the tested-by, thanks!

Revision history for this message
In , Chris Halse Rogers (raof) wrote :

The patch is still slightly broken:

In intel_crtc_update_cursor you have
...
if (crtc->fb) {
 base = intel_crtc->cursor_addr;
 if (x > crtc->fb->width)
  base = 0;
...
with x a signed int and crtc->fb->width an unsigned integer, and similarly for y and height. This makes the cursor disappear near the far left and top of the screen (as (unsigned)-1 > 1440) - there's no guarantee the hot point is the top-left of the image, and indeed for me it's not.

Also, reading the docs it seems that it's required that CUR*BASE be written to update any of the cursor regs (vol 3, p142). I presume that I'm reading it incorrectly, since the cursor appears to update fine without doing that.

Revision history for this message
In , Chris Wilson (ickle) wrote :

I forgot to check whether fb->width was signed or not. Hmm, should check with sparse more often I guess. Thanks for spotting that.

CURAPOS:
"This register specifies the physical memory address at which the cursor image data is located. Writes to this register acts like a trigger that enables atomic updates of the cursor registers. When updating the cursor registers, this register should be written last in the sequence. This register should be written even if the actual contents did not change to allow the holding registers to move to the active registers on the next VBLANK."

Hmm, but if the cursor is enabled first with an invalid position what happens? Yes, the update to base and the pos updated is buffered until the next vblank, but that smells like a race and elsewhere the docs say that CUR*BASE should be written last to trigger the updates...

Revision history for this message
In , Chris Wilson (ickle) wrote :

(In reply to comment #66)
> CURAPOS:

Idiot left in charge of keyboard, again. This is CURABASE:

> "This register specifies the physical memory address at which the cursor image
> data is located. Writes to this register acts like a trigger that enables
> atomic updates of the cursor registers. When updating the cursor registers,
> this register should be written last in the sequence. This register should be
> written even if the actual contents did not change to allow the holding
> registers to move to the active registers on the next VBLANK."

CURAPOS:

"This register can be loaded atomically (requires that the base address be
written) and is double buffered."

Andy Whitcroft (apw)
tags: added: kernel-candidate kernel-reviewed
removed: kernel-needs-review
Revision history for this message
Chris Halse Rogers (raof) wrote :

As noted on the upstream bug this patch does not quite completely resolve this. I've only managed to reproduce this once, but it seems that there's probably an off-by-one error in the bounds checking.

I'm tracking this down now.

Andy Whitcroft (apw)
description: updated
tags: added: patch
Revision history for this message
Chris Halse Rogers (raof) wrote :

Ok. There was a problem with a signed/unsigned comparison in the initial patch. I'm testing the revised patch now.

Revision history for this message
Chris Halse Rogers (raof) wrote :

The revised patch also has problems - the cursor will sometimes be replaced with a corrupted pixmap when it's unhidden. I think I've identified where it behaves differently to the existing code, and I haven't yet found any problems with the new patch.

Revision history for this message
Chris Halse Rogers (raof) wrote :

I've added my Reviewed-by and Tested-by to the revised patch on the intel-gfx mailing list here: http://lists.freedesktop.org/archives/intel-gfx/2010-July/007379.html . This should now go into the mainline kernel and the stable trees, and we could pick it up as an SRU.

tags: removed: kernel-candidate
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

I think this one is fixed now.

Revision history for this message
Chris Halse Rogers (raof) wrote :
Revision history for this message
Chris Halse Rogers (raof) wrote :

And is now in linux-stable¹, in 2.6.35.1, so this is fixed in Maverick.

Can we get this patch also applied to Lucid?

1: git commit is http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-allstable.git;a=commit;h=5078304217e1e87bc7ffe8d7a4076e4cb0c0a318

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Andy Whitcroft (apw)
tags: added: upstream-stable-patch
Revision history for this message
Andy Whitcroft (apw) wrote :

The patch suggested above has hit v2.6.35.1 stable.

Changed in linux (Ubuntu Lucid):
status: New → Triaged
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
Torsten Spindler (tspindler) wrote :

Can this bug fix be applied to Lucid per SRU? The customer would like to use the standard kernel again.

Revision history for this message
Andy Whitcroft (apw) wrote :

@Torsten -- the patch has now come back down from stable to v2.6.35.x. I have backported it to v2.6.33 drm that we have in Lucid but that did involve some manual application. Could you test the kernels at the URL below and confirm whether they work ok for you:

    http://people.canonical.com/~apw/lp586325-lucid/

Please test and report back here. Thanks!

Revision history for this message
Torsten Spindler (tspindler) wrote :

I have the kernel up and running on an Fujitsu-Siemens Esprimo E and a Lenovo Thinkpad T61. On both systems I can change the screen resolution without any problems. I also tested suspend/resume and it continues to work fine. I've asked the customer to test the kernel as well.

Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :

I also tested the given kernel on a Fujitsu-Siemens Esprimo E and it looks good. I was able to change the resolution without any problem.

Andy Whitcroft (apw)
description: updated
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted linux into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in linux (Ubuntu Lucid):
status: Triaged → Fix Committed
tags: added: verification-needed
Revision history for this message
Torsten Spindler (tspindler) wrote :

Running the kernel since last week on my laptop (nvidia graphics though) without detecting any regressions.

Testing the kernel on an Fuj-Siemens Esprimo E today for 1.5 hours, doing a loop over xrandr:
while true
do
   xrandr -s 1024x768
   sleep 30
   xrandr -s 1920x1200
   sleep 30
done

During the loop I move the mouse from time to time and from edge to edge. All resolution changes work.

Revision history for this message
Hans-Gerd van Schelve (van-schelve) wrote :

Running the kernel since friday on my Lenovo x61 without any problems. Looks good.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Thanks for testing. Marking as verification-done.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (18.8 KiB)

This bug was fixed in the package linux - 2.6.32-26.47

---------------
linux (2.6.32-26.47) lucid-proposed; urgency=low

  [ Steve Conklin ]

  * Revert "SAUCE: ALSA: HDA: Enable internal mic on Dell E6410 and Dell
    E6510"
  * Revert "[Config] Added be2net, be2scsi to udebs"

  [ Upstream Kernel Changes ]

  * Revert "(ore-stable) ALSA: hda - Apply ALC269 VAIO fix-up to all Sony
    laptops with ALC269"
  * Revert "(pre-stable) ALSA: HDA: Correctly apply position_fix quirks for
    ATI and VIA controllers"
  * Revert "ALSA: hda: Use LPIB for another mainboard"
  * Revert "ALSA: hda: Use LPIB for ASUS M2V"
  * Revert "ALSA: hda: Use LPIB for an ASUS device"
  * Buglink Fixup for reverted unverified fixes

linux (2.6.32-26.46) lucid-proposed; urgency=low

  [ Brad Figg ]

  * SAUCE: ALSA: HDA: Enable internal mic on Dell E6410 and Dell E6510
    - See: #605047, #628961

  [ Tim Gardner ]

  * [Config] Added be2net, be2scsi to udebs
    - See: #628776

  [ Upstream Kernel Changes ]

  * Revert "(pre-stable) drm/i915: add PANEL_UNLOCK_REGS definition"
    - LP: #645444
  * Revert "(pre-stable) drm/i915: make sure we shut off the panel in eDP
    configs"
    - LP: #645444
  * Revert "(pre-stable) drm/i915: make sure eDP panel is turned on"
    - LP: #645444
  * Revert "(pre-stable) drm/radeon/kms: initialize set_surface_reg reg for
    rs600 asic"
    - LP: #645371
  * Revert "drm/nouveau: Fix fbcon corruption with font width not divisible
    by 8"
    - LP: #663176
  * mmc: fix all hangs related to mmc/sd card insert/removal during
    suspend/resume
    - LP: #477106
  * mmc: build fix: mmc_pm_notify is only available with CONFIG_PM=y
    - LP: #477106
  * hwmon: (k8temp) Differentiate between AM2 and ASB1
    - LP: #644694
  * xen: handle events as edge-triggered
    - LP: #644694
  * xen: use percpu interrupts for IPIs and VIRQs
    - LP: #644694
  * ALSA: hda - Rename iMic to Int Mic on Lenovo NB0763
    - LP: #605101, #644694
  * sata_mv: fix broken DSM/TRIM support (v2)
    - LP: #644694
  * x86, tsc, sched: Recompute cyc2ns_offset's during resume from sleep
    states
    - LP: #644694
  * PCI: MSI: Remove unsafe and unnecessary hardware access
    - LP: #644694
  * PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
    - LP: #644694
  * sched: kill migration thread in CPU_POST_DEAD instead of CPU_DEAD
    - LP: #644694
  * sched: revert stable c6fc81a sched: Fix a race between ttwu() and
    migrate_task()
    - LP: #644694
  * staging: hv: Fix missing functions for net_device_ops
    - LP: #644694
  * staging: hv: Fixed bounce kmap problem by using correct index
    - LP: #644694
  * staging: hv: Fixed the value of the 64bit-hole inside ring buffer
    - LP: #644694
  * staging: hv: Increased storvsc ringbuffer and max_io_requests
    - LP: #644694
  * staging: hv: Fixed lockup problem with bounce_buffer scatter list
    - LP: #644694
  * fuse: flush background queue on connection close
    - LP: #644694
  * ath9k_hw: fix parsing of HT40 5 GHz CTLs
    - LP: #644694
  * ocfs2: Fix incorrect checksum validation error
    - LP: #644694
  * USB: ehci-ppc-of: problems in unwind
    - LP: #644694
  * USB: Fix kernel oo...

Changed in linux (Ubuntu Lucid):
status: Fix Committed → Fix Released
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
tags: added: testcase
Revision history for this message
In , Ceggers (ceggers) wrote :

Unfortunately it seems that with openSUSE 12.2 (kernel 3.4.11) the problem (or a similar one) is present again. Switching to another mode crashes the graphics system with a possibility of 90 percent!

I've filled a new bug report here:
https://bugs.freedesktop.org/show_bug.cgi?id=59066

Unfortunately there hasn't been much progress in the last weeks so I hope someone who has been related to this bug could help.

Could somebody please check whether there's at least a chance to fix it, or it would be more wise to purchase another graphics adapter?

Thank you very much
Christian

Revision history for this message
In , Bo Nygaard Bai (bai-v) wrote :

I can confirm that the same problem, or something very similar, has returned in Debian Wheezy.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.