[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X
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-
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-
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.
Related branches
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #2 |
Created an attachment (id=30729)
Ouput of intel_gpu_dump (before resoluation change)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #3 |
Created an attachment (id=30730)
Ouput of intel_gpu_dump (after resolution change)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #4 |
Created an attachment (id=30731)
Xorg.0.log
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #5 |
Created an attachment (id=30732)
Screenshot
In freedesktop.org Bugzilla #24748, Carl Worth (cworth) wrote : | #6 |
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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #7 |
(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?
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #8 |
(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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #9 |
(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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #10 |
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.
In freedesktop.org Bugzilla #24748, Michael Fu (michael-fu-intel) wrote : | #11 |
ping Chris...
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #12 |
(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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #13 |
Created an attachment (id=32515)
Output of dmesg (linux-2.6.32.2)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #14 |
Created an attachment (id=32516)
Xorg.0.log (linux-2.6.32.2)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #15 |
Created an attachment (id=32517)
Output of intel_reg_dumper (linux-2.6.32.2)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #16 |
(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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #17 |
Hi,
any news...?
regards
Christian
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #18 |
(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://
BTW: the patch 1 can be skipped as it is already shipped in 2.6.33-rc5 kernel.
Thanks.
Yakui
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #19 |
(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://
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
In freedesktop.org Bugzilla #24748, Michael Fu (michael-fu-intel) wrote : | #20 |
(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
>
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #21 |
(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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #22 |
(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://
>
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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #23 |
d) 2.6.33-rc7 (vanilla, w/o your patches)
Results:
d) Same as b)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #24 |
(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
In freedesktop.org Bugzilla #24748, Mr. Anderson (walch-martin) wrote : | #25 |
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 8ece6cf5afa1bb0
-- 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.
In freedesktop.org Bugzilla #24748, Mr. Anderson (walch-martin) wrote : | #26 |
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
362a49e71fc4154
-- xserver: Server 1.7.6
-- mesa: git snapshot from one day ago (last commit
9eaadfeaa54d15f
-- libdrm: 2.4.19
-- kernel: 2.6.31-gentoo-r10
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #27 |
(In reply to comment #26)
> changes that happended to my system configuration:
>
> -- xf86-video-intel: git snapshot from one day ago (last commit
> 362a49e71fc4154
> -- xserver: Server 1.7.6
> -- mesa: git snapshot from one day ago (last commit
> 9eaadfeaa54d15f
> -- 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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #28 |
> >
> 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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #29 |
Created an attachment (id=34533)
dmesg (for comment #28)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #30 |
Created an attachment (id=34534)
xrandr -q --verbose (for comment #28)
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #31 |
(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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #32 |
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.
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #33 |
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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #34 |
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://
In freedesktop.org Bugzilla #24748, Mr. Anderson (walch-martin) wrote : | #35 |
(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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #36 |
(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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #37 |
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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #38 |
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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #39 |
(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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #40 |
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:
> [drm:intel_
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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #41 |
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://
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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #42 |
Created an attachment (id=34820)
xrandr -q --verbose (for comment #41)
xrandr -q --verbose with HP LP2065 TFT connected via VGA
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #43 |
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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #44 |
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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #45 |
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
In freedesktop.org Bugzilla #24748, yakuizhao (yakui-zhao) wrote : | #46 |
(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
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #47 |
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
Torsten Spindler (tspindler) wrote : changing resolution results in non working X | #48 |
Binary package hint: xserver-
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-
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.
Bryce Harrington (bryce) wrote : | #49 |
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 |
Torsten Spindler (tspindler) wrote : | #50 |
Torsten Spindler (tspindler) wrote : | #51 |
- Xorg.0.log.old Edit (42.8 KiB, application/x-trash)
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.
Torsten Spindler (tspindler) wrote : | #52 |
$ apport-collect 586325
Error connecting to Launchpad: 'NoneType' object has no attribute 'makefile'
You can reset the credentials by removing the file "/u/m500369/
Torsten Spindler (tspindler) wrote : | #53 |
tags: | removed: needs-xorglog |
tags: | removed: needs-lspci-vvnn |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Incomplete → Confirmed |
Torsten Spindler (tspindler) wrote : | #54 |
- lspci-vvnn-working Edit (19.6 KiB, text/plain)
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.
Torsten Spindler (tspindler) wrote : | #55 |
Torsten Spindler (tspindler) wrote : | #56 |
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 |
tags: | added: hardy |
Torsten Spindler (tspindler) wrote : Re: Fujitsu Siemens Esprimo E: changing resolution results in non working X | #57 |
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.
Stenten (stenten) wrote : | #58 |
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 |
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 |
tags: | added: resolution |
tags: | added: hardy |
Torsten Spindler (tspindler) wrote : Re: [Bug 586325] Re: Fujitsu Siemens Esprimo E: changing resolution results in non working X | #59 |
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?
Stenten (stenten) wrote : Re: [965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X | #60 |
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.
Torsten Spindler (tspindler) wrote : Re: [Bug 586325] Re: [965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X | #61 |
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?
Hans-Gerd van Schelve (van-schelve) wrote : Re: [965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X | #62 |
Hans-Gerd van Schelve (van-schelve) wrote : | #63 |
Hans-Gerd van Schelve (van-schelve) wrote : | #64 |
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.
Hans-Gerd van Schelve (van-schelve) wrote : | #65 |
- IMG_0569.MOV Edit (831.3 KiB, video/quicktime)
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.
summary: |
- [965q] Fujitsu Siemens Esprimo E: changing resolution results in non + [i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X |
Pedro Villavicencio (pedro) wrote : | #66 |
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 |
Chris Halse Rogers (raof) wrote : | #67 |
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.
Hans-Gerd van Schelve (van-schelve) wrote : | #68 |
Hans-Gerd van Schelve (van-schelve) wrote : | #69 |
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | Incomplete → Confirmed |
Chris Halse Rogers (raof) wrote : | #70 |
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_
Jun 9 08:31:07 c399693 kernel: [ 60.921844] [drm:drm_
…
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.
In freedesktop.org Bugzilla #24748, Chris Halse Rogers (raof) wrote : | #71 |
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:/
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://
lspci:
http://
Xorg log:
http://
If you have something which needs more testing, just ask.
Chris Halse Rogers (raof) wrote : | #72 |
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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #73 |
(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
In freedesktop.org Bugzilla #24748, Daniel Stone (daniels) wrote : | #74 |
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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #75 |
(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
In freedesktop.org Bugzilla #24748, Daniel Stone (daniels) wrote : | #76 |
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.
Torsten Spindler (tspindler) wrote : | #77 |
Here the output of get-edid from an affected system and display:#
http://
Here the parse-edid output:
http://
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.
Torsten Spindler (tspindler) wrote : | #78 |
The problem is also present in Ubuntu 9.10, tested with the live CD.
Torsten Spindler (tspindler) wrote : | #79 |
The problem also exists on todays (2010-06-29) Maverick image.
Hans-Gerd van Schelve (van-schelve) wrote : | #80 |
Torsten Spindler (tspindler) wrote : | #81 |
The log comes from this RPM package's intel driver on RHEL5: xorg-x11-
Torsten Spindler (tspindler) wrote : | #82 |
We tested today a patched kernel driver from http://
Chris Halse Rogers (raof) wrote : | #83 |
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.
Torsten Spindler (tspindler) wrote : | #84 |
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
Torsten Spindler (tspindler) wrote : | #85 |
A test with Ubuntu 8.04.4 live CD showed a similar behaviour. The screen flickered in white and brown.
Torsten Spindler (tspindler) wrote : | #86 |
Calling xrandr from the command line with 60 Hertz did work:
$ xrandr -s 1024x768 --rate 60
Torsten Spindler (tspindler) wrote : | #87 |
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-
Torsten Spindler (tspindler) wrote : | #88 |
Hypothesis is, that using xrandr on the command line is more robust than using gnome-display-
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-
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
Torsten Spindler (tspindler) wrote : | #89 |
- dmesg.working Edit (48.9 KiB, text/plain)
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.
Torsten Spindler (tspindler) wrote : | #90 |
In freedesktop.org Bugzilla #24748, Chris Halse Rogers (raof) wrote : | #91 |
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.
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #92 |
Wow, never would have suspected that. The next step would seem to be to test disabling the cursor around modesetting.
Chris Halse Rogers (raof) wrote : | #93 |
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.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #94 |
(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://
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
In freedesktop.org Bugzilla #24748, Chris Halse Rogers (raof) wrote : | #95 |
Yup, just disabling the cursor around modesetting works.
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #96 |
(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
In freedesktop.org Bugzilla #24748, Chris Halse Rogers (raof) wrote : | #97 |
(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?
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #98 |
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.
Chris Halse Rogers (raof) wrote : | #99 |
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.
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #100 |
Created an attachment (id=36828)
Unset cursor if out of bounds.
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #101 |
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...
In freedesktop.org Bugzilla #24748, Chris Halse Rogers (raof) wrote : | #102 |
(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>
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #103 |
(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
Chris Halse Rogers (raof) wrote : | #104 |
Moving this to the kernel. There's a kernel patch available https:/
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 |
Chris Halse Rogers (raof) wrote : | #105 |
- git commit for Lucid 2.6.32-24 Edit (8.3 KiB, text/plain)
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 |
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #106 |
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!
In freedesktop.org Bugzilla #24748, Chris Halse Rogers (raof) wrote : | #107 |
The patch is still slightly broken:
In intel_crtc_
...
if (crtc->fb) {
base = intel_crtc-
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.
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #108 |
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...
In freedesktop.org Bugzilla #24748, Chris Wilson (ickle) wrote : | #109 |
(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."
tags: |
added: kernel-candidate kernel-reviewed removed: kernel-needs-review |
Chris Halse Rogers (raof) wrote : | #110 |
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.
description: | updated |
tags: | added: patch |
Chris Halse Rogers (raof) wrote : | #111 |
Ok. There was a problem with a signed/unsigned comparison in the initial patch. I'm testing the revised patch now.
Chris Halse Rogers (raof) wrote : | #112 |
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.
Chris Halse Rogers (raof) wrote : | #113 |
I've added my Reviewed-by and Tested-by to the revised patch on the intel-gfx mailing list here: http://
tags: | removed: kernel-candidate |
Changed in linux (Ubuntu): | |
status: | Confirmed → Triaged |
In freedesktop.org Bugzilla #24748, Jesse Barnes (jbarnes-virtuousgeek) wrote : | #114 |
I think this one is fixed now.
Chris Halse Rogers (raof) wrote : | #115 |
This is now in Airlied's drm-next branch, commit http://
Chris Halse Rogers (raof) wrote : | #116 |
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://
Changed in linux (Ubuntu): | |
status: | Triaged → Fix Released |
tags: | added: upstream-stable-patch |
Andy Whitcroft (apw) wrote : | #117 |
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 |
Torsten Spindler (tspindler) wrote : | #118 |
Can this bug fix be applied to Lucid per SRU? The customer would like to use the standard kernel again.
Andy Whitcroft (apw) wrote : | #119 |
@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://
Please test and report back here. Thanks!
Torsten Spindler (tspindler) wrote : | #120 |
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.
Hans-Gerd van Schelve (van-schelve) wrote : | #121 |
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.
description: | updated |
Martin Pitt (pitti) wrote : Please test proposed package | #122 |
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:/
Changed in linux (Ubuntu Lucid): | |
status: | Triaged → Fix Committed |
tags: | added: verification-needed |
Torsten Spindler (tspindler) wrote : | #123 |
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.
Hans-Gerd van Schelve (van-schelve) wrote : | #124 |
Running the kernel since friday on my Lenovo x61 without any problems. Looks good.
Jean-Baptiste Lallement (jibel) wrote : | #125 |
Thanks for testing. Marking as verification-done.
tags: |
added: verification-done removed: verification-needed |
Launchpad Janitor (janitor) wrote : | #126 |
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_
- 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 |
In freedesktop.org Bugzilla #24748, Ceggers (ceggers) wrote : | #127 |
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:/
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
In freedesktop.org Bugzilla #24748, Bo Nygaard Bai (bai-v) wrote : | #128 |
I can confirm that the same problem, or something very similar, has returned in Debian Wheezy.
Created an attachment (id=30728)
Output of dmesg