Bug 17292 - (vaio_lvds_blank) [GM45 965GM] bad htotal causes panel startup failure
(vaio_lvds_blank)
[GM45 965GM] bad htotal causes panel startup failure
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
7.4 (2008.09)
x86-64 (AMD64) Linux (All)
: high critical
Assigned To: Jesse Barnes
Xorg Project Team
: NEEDINFO
: GreyGeek 18342 18582 (view as bug list)
Depends on:
Blocks: intel-2.5 18858
  Show dependency treegraph
 
Reported: 2008-08-25 03:04 UTC by Claudio Camacho
Modified: 2009-03-26 18:30 UTC (History)
20 users (show)

See Also:


Attachments
Xorg log output. (184.73 KB, text/plain)
2008-08-25 03:04 UTC, Claudio Camacho
no flags Details
Here is my xorg.conf (just in case) (2.89 KB, text/plain)
2008-08-25 03:05 UTC, Claudio Camacho
no flags Details
Linux 2.6.27-rc4 dmesg output. (30.94 KB, application/octet-stream)
2008-08-25 03:07 UTC, Claudio Camacho
no flags Details
xorg.0.log (21.37 KB, text/x-log)
2008-08-31 20:36 UTC, Jos van Wolput
no flags Details
lspci -vvmm (3.81 KB, text/plain)
2008-09-08 14:21 UTC, Claudio Camacho
no flags Details
get-edid error output (897 bytes, text/plain)
2008-09-09 09:06 UTC, Giovanni Pellerano
no flags Details
Xorg.0.log (xorg 1.5.99 + xf86-video-intel 2.5) (18.83 KB, text/plain)
2008-10-09 13:35 UTC, Claudio Camacho
no flags Details
Xorg.0.log with --enable-debug and ModeDebug (69.38 KB, text/plain)
2008-10-10 16:01 UTC, Justyn Butler
no flags Details
VBEBIOS ROM.BIN [VAIO SR19XN, VAIO SR11M) (64.00 KB, application/octet-stream)
2008-10-11 00:32 UTC, Giovanni Pellerano
no flags Details
Video ROM of SR19XN (64.00 KB, application/octet-stream)
2008-10-11 01:19 UTC, Justyn Butler
no flags Details
xorg log | kernel 2.6.27 git 7 (15.32 KB, text/plain)
2008-10-17 13:52 UTC, Giovanni Pellerano
no flags Details
Xorg.0.log-2.6.27-git8 (16.12 KB, text/plain)
2008-10-18 00:58 UTC, Claudio Camacho
no flags Details
output of monitor-probe -v vesa on Sony VAIO VGN-FW140E/H laptop (4.31 KB, text/plain)
2008-10-19 12:14 UTC, Jerry L Kreps
no flags Details
Xorg.0.log from Mandriva 2009 pwp running on Sony VAIO VGN-FW140E/H (35.54 KB, text/plain)
2008-10-19 13:38 UTC, Jerry L Kreps
no flags Details
Xorg.0.log-2.6.27-git10 (15.92 KB, text/plain)
2008-10-21 13:28 UTC, Claudio Camacho
no flags Details
Xorg.0.log-2.6.28-rc1 (15.71 KB, text/plain)
2008-10-24 00:49 UTC, Claudio Camacho
no flags Details
gm45-quirk-sony-vaio-vgn-sr11m.patch (559 bytes, patch)
2008-10-30 09:24 UTC, Ugo Viti
no flags Details | Splinter Review
intel_reg_dumper output on SR19XN using external monitor (6.98 KB, text/plain)
2008-11-10 16:37 UTC, Justyn Butler
no flags Details
intel_reg_dumper output without monitor (6.86 KB, text/plain)
2008-11-10 16:38 UTC, Justyn Butler
no flags Details
intel_reg_dumper output using VESA driver (6.93 KB, text/plain)
2008-11-10 16:40 UTC, Justyn Butler
no flags Details
intel_reg_dumper output on VGN-FW140E, using vesa driver on the lcd display at 1024x768 (without monitor) (6.85 KB, text/plain)
2008-11-11 11:01 UTC, jelle foks
no flags Details
intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), while the non-working blank screen is seen (7.10 KB, text/plain)
2008-11-11 12:59 UTC, jelle foks
no flags Details
intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), after switching back to the console (ctrl-alt-f1) (6.89 KB, text/plain)
2008-11-11 13:02 UTC, jelle foks
no flags Details
intel_reg_dumper of Sony Vaio VGN-SR11M (7.92 KB, text/plain)
2008-11-11 15:35 UTC, Ugo Viti
no flags Details
Xorg.log with Modeline described in Comment #112 (24.76 KB, text/x-log)
2008-11-14 03:02 UTC, Raphael Thierjung
no flags Details
Xorg.0.log with Modeline 1280x800_60 (36.18 KB, text/x-log)
2008-11-14 03:45 UTC, Ugo Viti
no flags Details
xorg.conf used to test Modeline 1280x800_60 (716 bytes, application/octet-stream)
2008-11-14 03:49 UTC, Ugo Viti
no flags Details
Xorg.0.log with Modeline "1280x800_60" 68.88 1280 1296 1344 1410 800 804 808 815 -hsync -vsync (48.33 KB, text/x-log)
2008-11-14 16:07 UTC, Ugo Viti
no flags Details
sony-vaio-vgn-sr11m-rom.bin (64.00 KB, application/octet-stream)
2008-11-14 16:31 UTC, Ugo Viti
no flags Details
Xorg.0.log with Modeline "1280x800_60" 68.9 1280 1292 1340 1440 800 804 807 823 +hsync +vsync (46.41 KB, text/x-log)
2008-11-15 04:09 UTC, Ugo Viti
no flags Details
intel-vaio-lvds.patch (546 bytes, patch)
2008-11-17 02:12 UTC, Ugo Viti
no flags Details | Splinter Review
delay after panel off (291 bytes, patch)
2008-11-25 16:20 UTC, Jesse Barnes
no flags Details | Splinter Review
intel_reg_dumper on working lcd with if(!on) hack (6.85 KB, text/plain)
2008-12-18 20:49 UTC, jelle foks
no flags Details
Failing log of Sony VAIO VGN-FW235 with intel driver and LVDS screen (4500MHD) (18.10 KB, text/plain)
2008-12-19 06:20 UTC, Kevin Dodge
no flags Details
Try LVDS write protect (2.24 KB, patch)
2008-12-28 17:51 UTC, Wang Zhenyu
no flags Details | Splinter Review
The only known way to work around this bug... Use: Option "lvdshack" "True" (2.01 KB, patch)
2008-12-29 00:40 UTC, jelle foks
no flags Details | Splinter Review
avoid power cycling the panel at startup (3.47 KB, patch)
2008-12-30 10:24 UTC, Jesse Barnes
no flags Details | Splinter Review
2.6.28-git14 KMS dmesg (38.11 KB, application/octet-stream)
2009-01-10 14:24 UTC, Claudio Camacho
no flags Details
2.6.28-git14 (KMS) + Xorg 7.4 (12.68 KB, application/octet-stream)
2009-01-10 14:28 UTC, Claudio Camacho
no flags Details
Make sure h & vblank end come *after* h & vsync end (842 bytes, patch)
2009-01-12 16:56 UTC, Jesse Barnes
no flags Details | Splinter Review
check VBT timing sanity at BIOS init time (645 bytes, patch)
2009-01-26 12:39 UTC, Jesse Barnes
no flags Details | Splinter Review
Xorg.log with BO depth buffer error (15.20 KB, text/plain)
2009-01-27 11:45 UTC, Karsten Heiken
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claudio Camacho 2008-08-25 03:04:08 UTC
Created attachment 18499 [details]
Xorg log output.

I have a Sony Vaio SR11M with a Intel Cantiga Integrated Graphics (aka G45) chipset, and I am using Xorg 7.3 with xserver-xorg-video-intel 2.4.0.

When starting the Xorg (using the 'Xorg' command), the display goes blank. The Xorg server is running, however the built-in LCD of the laptop won't show anything, it remains blank.

I discovered that the xserver initializes two pipes: Pipe A and Pipe B. The log says that the pipe A is ON an connected to the VGA output, whereas the pipe B is ON and connected to the LVDS (presumably the built-in LCD display of the laptop).

When the Xorg is loaded, it starts to spit out the same error over and over again:
(EE) intel(0): underrun on pipe B!

When switching to a normal tty, it will stop spitting out that error. And, obviously, when going back to X, it will start throwing up the underrun error again.

I know there have been some similar issues around in i386 architectures but in pipe A, typically with single-pipe old cards. I believe this is a problem of quirks, where the driver doesn't initialize properly the pipes and hence the built-in LCD panel is not enabled for displaying the X-window system.

My system is a Debian GNU/Linux running on a 2.6.27-rc4 kernel. The intel driver is at 2.4.0 version, whereas the Xorg server is at version 1.4.99.906.

Please find enclosed my Xorg.0.log.

Best regards,
Comment 1 Claudio Camacho 2008-08-25 03:05:45 UTC
Created attachment 18500 [details]
Here is my xorg.conf (just in case)
Comment 2 Claudio Camacho 2008-08-25 03:07:57 UTC
Created attachment 18501 [details]
Linux 2.6.27-rc4 dmesg output.
Comment 3 Gordon Jin 2008-08-31 18:03:26 UTC
I guess it might have been fixed in the latest 2.4.2 release. Worth trying.
Comment 4 Jos van Wolput 2008-08-31 20:33:40 UTC
(In reply to comment #3)
> I guess it might have been fixed in the latest 2.4.2 release. Worth trying.
> 

System: linux 2.6.26-1-686 (x86)
Chipset: "852GM/855GM"
xserver-xorg 1.4.99.906

I compiled the latest git (sept. 01) and get the following errors in xorg.log: 
(EE) intel(0): underrun on pipe A!
(EE) intel(0): underrun on pipe B!
Comment 5 Jos van Wolput 2008-08-31 20:36:12 UTC
Created attachment 18607 [details]
xorg.0.log
Comment 6 Claudio Camacho 2008-08-31 23:53:28 UTC
Hi Gordon Jin,

Thank you for taking your time with my report. I'm at the job right now, but as soon as I get home, I will try to compile the xserver-xorg-video-intel-2.4.2 on my Debian and let you know if it works or not.
Comment 7 Gordon Jin 2008-09-01 05:41:08 UTC
(In reply to comment #4)
> I compiled the latest git (sept. 01) and get the following errors in xorg.log: 
> (EE) intel(0): underrun on pipe A!
> (EE) intel(0): underrun on pipe B!

Jos, are you seeing blank screen issue too? Just having the error messages doesn't hurt.
Comment 8 Jos van Wolput 2008-09-01 09:45:54 UTC
bugzilla-daemon@freedesktop.org wrote:
> Jos, are you seeing blank screen issue too? Just having the error messages doesn't hurt.

No black screen, no other problem, only the error messages (which don't always appear).
So I should not worry about this driver!

Cheers & thanks,
Jos v.W.
-----
Debian GNU/Linux: the Universal Operating System
Comment 9 Julien Cristau 2008-09-01 10:44:42 UTC
> --- Comment #3 from Gordon Jin <gordon.jin@intel.com>  2008-08-31 18:03:26 PST ---
> I guess it might have been fixed in the latest 2.4.2 release. Worth trying.
> 
The error message and LVDS flickering were reintroduced for me by
48d4b0ae50affd7fa442271046eefba74de7ff2c, so 2.4.0 and 2.4.2 have the
bug, and 2.4.1 doesn't.

Cheers,
Julien
Comment 10 Jos van Wolput 2008-09-01 17:11:36 UTC
(In reply to comment #9)
> so 2.4.0 and 2.4.2 have the bug, and 2.4.1 doesn't.

I am sorry but 2.4.1 too (sometimes) shows the error message, moreover it produces horizontal stripes on the background of my desktop!

Cheers,
Jos v.W.
Comment 11 Claudio Camacho 2008-09-02 01:36:08 UTC
Hi again,

I didn't have time to try out the 2.4.2 on my Debian-amd64 yet, but I know the bug has been around for me since 2.3.2. However, I have noticed that *sometimes* there is no message about the underrun, but I still get a blank screen.

Also, I have noticed that, when switching from console to graphics mode, the display lights up a little bit (from black to dark navy blue) and there are several dark bars which appear horizontally (something like denoting the display is initializing) but one can hardly see them. These bars disappear in less than a two seconds and the dark navy blue screen (blank screen but lightened up) remains. In this case, no underrun messages are seen in the log file.

This is quite strange, and I don't know anymore if it belongs to the intel driver or to the kernel, but it looks to me that is a problem with new laptops (using LVDS) and concretely with the Intel X4500.

I don't have time to compile the bunch of git sources for the 2.4.2, is there anyway I can do it easily? Otherwise, I will have to wait for the Debian people to include it in experimental (probably a few days still).
Comment 12 Julien Cristau 2008-09-02 04:39:24 UTC
On Tue, Sep  2, 2008 at 01:36:10 -0700, bugzilla-daemon@freedesktop.org wrote:

> I don't have time to compile the bunch of git sources for the 2.4.2, is there
> anyway I can do it easily? Otherwise, I will have to wait for the Debian people
> to include it in experimental (probably a few days still).
> 
version 2:2.4.1-1 in experimental is actually 2.4.2, only difference is
the version bump.  sorry about that.
Comment 13 Claudio Camacho 2008-09-03 06:06:07 UTC
I tried, just now, the xserver-xorg-video-intel 2.4.2 along with xserver-xorg-core 1.4.906 and still I have the same problem. There is nothing on the LCD display of my laptop.

However, the "underrun" message has gone away. It seems that the LCD (LVDS) cannot be initalized or backlit, I don't know anymore what could cause this.
Comment 14 Jos van Wolput 2008-09-03 23:43:51 UTC
(In reply to comment #13)
> 
> However, the "underrun" message has gone away. 

I keep getting lots of errors with 2.4.2 (compiled for 1.4.99.906):
not only 'underrun' but also 
(EE) intel(0): tried to update DSPARB with both planes enabled!
----
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): underrun on pipe B!
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): underrun on pipe B!
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "CRTDDC_A:ddc2" removed.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): tried to update DSPARB with both planes enabled!
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
(EE) intel(0): underrun on pipe B!
-----
The Xorg.log becoming longer and longer!
Comment 15 Claudio Camacho 2008-09-06 15:32:47 UTC
Hi,

I just tried the Xorg 7.4 (xserver-1.5.0) with the xserver-xorg-video-intel-2.4.2 in Debian Sid and still I have same problem: my screen is ligthened up but the screen is totally blank.

No message errors, the log says that VGA is connected to pipe A (which is off) and LVDS is connected to pipe B (which is on).

My frustration grows, I hope there is not a big problem with the new Intel X4500.

Good night!
Comment 16 Claudio Camacho 2008-09-08 14:20:23 UTC
Hi,

I have visited #xorg-devel (at irc.freenode.net) and, after a lot of testing on my Vaio SR11M, I have noticed that Xorg is running properly even with the blank screen. Even I can run glxgears and other applications with no problems.

Therefore, the last possibility to fix this is concerning a probable quirk that is needed, since the output of Xorg goes to a wrong place, whereas it should go to the LVDS TFT of the laptop.

Please find enclosed an lspci -vvmm.
Comment 17 Claudio Camacho 2008-09-08 14:21:27 UTC
Created attachment 18752 [details]
lspci -vvmm

Hopefully you can add a quirk looking at the lspci -vvmm.
Comment 18 Claudio Camacho 2008-09-09 00:30:37 UTC
UPDATE: I connected a VGA monitor and the DRI is working.

So this confirms that the problem is in defaulting the output to the laptop's monitor (LVDS), where I only see a blank screen.

By the way, glxgears shows poor performance and gives this error:

Failed to initialize TTM buffer manager.  Falling back to classic.


Here is the glxinfo output (that I can only see from the VGA monitor):

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, 
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_visual_select_group
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset 20061102
OpenGL version string: 1.4 Mesa 7.1 rc3
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, 
    GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture, 
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, 
    GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shadow, 
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, 
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, 
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_clip_volume_hint, GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array, 
    GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
    GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, 
    GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, 
    GL_EXT_rescale_normal, GL_EXT_secondary_color, 
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, 
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, 
    GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, 
    GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1, 
    GL_APPLE_client_storage, GL_APPLE_packed_pixels, 
    GL_ATI_blend_equation_separate, GL_ATI_separate_stencil, 
    GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, 
    GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, 
    GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, 
    GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection, 
    GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format, 
    GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, 
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, 
    GL_SUN_multi_draw_arrays

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x22 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x71 32 tc  0 16  0 r  .  .  5  6  5  0  0  0  0  0  0  0  0  0 0 None


Good luck!
Comment 19 Giovanni Pellerano 2008-09-09 09:06:07 UTC
Created attachment 18786 [details]
get-edid error output
Comment 20 Giovanni Pellerano 2008-09-09 09:18:52 UTC
I think the problem is with a bugged edid/vbe.

I've attached the output of the command 'get-edid';
The command fail with:

    The EDID data should not be trusted as the VBE call failed
    Error: output block unchanged


I've seen the same thing using the tool vbetest (lrmi packet), cause of a different vbetest output using vesa or intelfb for the framebuffer;

anyhow using the framebuffer i can get 1280x800 using vesa vga=866, and using X i can get 1280x800 using vesa with the modeline:

Modeline    "1280x800_76.00"  108.77  1280 1360 1496 1712  800 801 804 836  -HSync +Vsync


The intel X driver probes also this modeline with no success:
(II) intel(0): Not using mode "1280x800_76.00" (vrefresh out of range)
(EE) intel(0): Output LVDS enabled but has no modes
(EE) intel(0): No valid modes.
(II) UnloadModule: "intel"


I think the solution is using something like the IGNOREEDID options, but it don't work, so i think it does not exist for intel driver (as I read from the man page)
Comment 21 Fortunato Latella 2008-09-12 06:42:00 UTC
I've got this problem too.
My notebook is ths vaio SR11m
Comment 22 Giovanni Pellerano 2008-09-13 03:44:06 UTC
i've searched a lot and i've found some useful information;

i've found a ubuntu user having no problem with ubuntu and x4500 [sony bz] and i'm trying to contact him;

and i've found that the problem is solved [i think in ubunut: https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel

read about LVDS in the page!
Comment 23 Claudio Camacho 2008-09-13 08:24:19 UTC
I changed the topic of the bug, since it is now clear that the problem is a missing quirk for this kind of laptop: Sony Vaio SR11M.

On Ubuntu, some users reported that they get a blank screen using the xserver-xorg-video-intel driver (new laptops with LVDS displays and X4500). The Ubuntu developers added a few quirks for certain laptops to fix their users problems. I am using Debian GNU/Linux, but I tried Ubuntu with the latest quirks and still I get a blank screen using the intel driver.

Therefore, I assume that my blank screen is just an issue with the LVDS, thus needing a quirk for this laptop.

Please, contact me or send me any email with testing instructions, since developers may not have (and probably won't) this specific model from Sony Vaio.

Looking forward to hearing from you.
Comment 24 Fortunato Latella 2008-09-14 09:18:37 UTC
I'm not too expert in linux but I've installed Debian in my Desktop PC from 1 year so if someone want to send me some instructions I'll be happy to help fixing this bug.
To be exact i got a black (not blank) screen when the graphic server start, but i think it's the same problem. I've just tried to install Fedora, Ubuntu, Kubuntu and BackTrack3 but when the graphical installe begin i got a black screen.

Waiting for instructions (and hoping s'one find a solution :))
Comment 25 elupus 2008-09-18 11:17:16 UTC
I suspect this bug and #16638 are related, which sounds like it isn't a quirk needed at all. But i'm not sure.
Comment 26 Claudio Camacho 2008-09-18 22:52:35 UTC
I believe this is not related to #16638, since the problem on my laptop has nothing to do with pipes. In the beginning, I had some missconfiguration problems with pipes, but now Pipe A and Pipe B are well configured and there are no underrun messages at all.

Furthermore, on #16638, there is an external display connected to Pipe A. I have tested an external display connected to my VGA output and it works (Pipe A). Pipe B is also enabled and my laptop's display is connected to the Pipe B, however nothing is seen on the laptop's display (whereas the Xorg is shown on Pipe A, my VGA external monitor, and 3D works although it is crappy, glxgears shows only 700FPS).

So here the main problem is that Pipe B is enabled and the LVDS display is connected to Pipe B, but nothing is on the display when Xorg is started.
Comment 27 mathieu.taillefumier 2008-09-22 06:48:42 UTC
Hello,

I have the same problem on the sony vgnSZ71-E/B with the 2.4.97 drivers but the 2.4.2 drivers are working fine. So I think that it is a problem with sony laptops in general but I mind be wrong. 

regards

M. T.
Comment 28 Aurélien ROUGEMONT 2008-09-22 09:24:15 UTC
Hello there,

I am currently using an up to date ubuntu intrepid alpha 5. meaning 2.4.1 driver package. I did try x86 and amd64 install, and I did try the git drivers with some simple git-clone commands. So far, i am getting the exact same problem as Claudio.

The intel driver works just fine, but only on the VGA connector. If i don't connect the VGA cord, i can hear the gdm sounds. My guess is the intel driver starts without any problem. I still get the black screen on laptop's display.

If anyone has something to test, any idea that could be working, i'll try it.

Aurélien
Comment 29 Jesse Barnes 2008-09-22 14:04:49 UTC
Jos, I'm pretty sure you have a totally separate issue.  Please file another bug report for it after testing with a more recent driver (2.2.0 is missing several fixes for LVDS detection).

Claudio's bug really does seem like a pipe programming issue; after 2.4.0 I think we fixed some Cantiga related problems there (we're not supposed to program DSPARB or FW_BLC on those chips iirc), but apparently newer drivers are busted too?  Hmm...  I'll go look at some of the referenced URLs.
Comment 30 Giovanni Pellerano 2008-09-22 15:38:44 UTC
Jesse, i've the same hardware of Claudio,;
can you expose some test to use we can do helping you to fix the issue ?

thanks for the attention 

Giovanni Pellerano
Comment 31 Jesse Barnes 2008-09-22 17:58:39 UTC
Well, you could try commenting out the call to i830_update_dsparb to see if that makes the problem go away... If so at least we'll have narrowed it down.
Comment 32 Giovanni Pellerano 2008-09-22 23:30:13 UTC
can you explain it;

where i've to comment it?

On Tue, Sep 23, 2008 at 2:58 AM, <bugzilla-daemon@freedesktop.org> wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=17292
>
>
>
>
>
> --- Comment #31 from Jesse Barnes <jbarnes@virtuousgeek.org>  2008-09-22
> 17:58:39 PST ---
> Well, you could try commenting out the call to i830_update_dsparb to see if
> that makes the problem go away... If so at least we'll have narrowed it
> down.
>
>
> --
> Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 33 Giovanni Pellerano 2008-09-22 23:38:42 UTC
can you explain it;

where i've to comment it? 
Comment 34 Aurélien ROUGEMONT 2008-09-23 02:00:58 UTC
jesse,

i have made the test you've asked for, still the same problem, plus i can't ctrl+alt+FXX to any other terminal it makes the xorg server crash.

src/i830_display.c (1473à

	/*
    if (!DSPARB_HWCONTROL(pI830))
	i830_update_dsparb(pScrn);
	*/

is that what you've asked for ?
Comment 35 Jesse Barnes 2008-09-23 10:02:19 UTC
Yeah that's the line, thanks for testing.  On G45 DSPARB_HWCONTROL should be true, and looks like it probably is in your case, which means we have a bug elsewhere.  So 2.4.0 and 2.4.97 are broken but 2.4.2 works for everyone?  Maybe one of you could use 'git bisect' to figure out where things got fixed between 2.4.0 and 2.4.2?  That should give me a clue about what needs fixing in 2.4.97...
Comment 36 Claudio Camacho 2008-09-23 10:55:24 UTC
Hi Jesse,

As I said in my comment #13, I have already tried 2.4.2 and I got the same result. In fact, xserver-xorg-video-intel-2.4.2 is now on Debian and I have it installed, but the blank screen won't disappear.

Is there anywhere else where this bug could have been introduced? 

By the way, who said it is working with 2.4.2? For me it hasn't worked never, since 2.3.2 until 2.4.2.
Comment 37 Jesse Barnes 2008-09-23 11:18:00 UTC
I was looking at comment #27; that must be a separate issue then.

It would be harder to bisect between 2.3.2 and 2.4.2, but it's worth a try...  The 'git help bisect' man page is pretty good, care to give it a shot?
Comment 38 Claudio Camacho 2008-09-29 22:41:01 UTC
Ok, I see that nobody says nothing here and we all have a serious problem with the intel driver. Therefore:

Jesse, I am an average user and didn't get the bisect thing. Even more, I haven't got any driver working with my X4500 from 2.3.2 to 2.4.2, but still, I will ask you a couple of questions and then I'll try to find some time to help you with the bisect, since I need 3D at my studies and in daily life, and I guess many people would like it too (vesa is kind of thick on our laptops). My questions are:

I am using Debian Sid with Xorg 7.4 and vesa driver. For the intel driver, can I just checkout with git and 'make install' from the directory? I mean, should I checkout the revision 2.3.2 and the revision 2.4.2, then try both separately and then bisect?

Because I don't know if checking out the video-intel driver, will require also to checkout the whole Xorg, since there are dependencies with libdrm (I presume) and maybe other libraries. Could you please instruct me a little bit more so that we can finally close this ticket?

P.S.- Giovanni pointed out an interesting fact also in comment #20, where the EDID are not definitely correct and there might be a problem with the modes when starting the xserver. And that could also lead the LVDS to be blank, since the xserver doesn't accept any mode with the intel driver.
Comment 39 Jesse Barnes 2008-09-30 13:35:26 UTC
(In reply to comment #38)
> Ok, I see that nobody says nothing here and we all have a serious problem with
> the intel driver. Therefore:
> 
> Jesse, I am an average user and didn't get the bisect thing. Even more, I
> haven't got any driver working with my X4500 from 2.3.2 to 2.4.2, but still, I
> will ask you a couple of questions and then I'll try to find some time to help
> you with the bisect, since I need 3D at my studies and in daily life, and I
> guess many people would like it too (vesa is kind of thick on our laptops). My
> questions are:
> 
> I am using Debian Sid with Xorg 7.4 and vesa driver. For the intel driver, can
> I just checkout with git and 'make install' from the directory? I mean, should
> I checkout the revision 2.3.2 and the revision 2.4.2, then try both separately
> and then bisect?

Right.  If you want to try an even newer version (like the master branch from git) you'll also need to build libdrm from git.  See http://wiki.x.org/wiki/Development/git for some instructions on grabbing & building the drm tree.

> Because I don't know if checking out the video-intel driver, will require also
> to checkout the whole Xorg, since there are dependencies with libdrm (I
> presume) and maybe other libraries. Could you please instruct me a little bit
> more so that we can finally close this ticket?

It should just depend on libdrm; building against a 1.5 X server *should* work fine.

> P.S.- Giovanni pointed out an interesting fact also in comment #20, where the
> EDID are not definitely correct and there might be a problem with the modes
> when starting the xserver. And that could also lead the LVDS to be blank, since
> the xserver doesn't accept any mode with the intel driver.

Yeah, it may be that we have to get the panel info for this machine from the VBIOS.  I recently pushed some fixes for other machines that might help here too.  Let me know if you have trouble building the driver; testing the latest git bits would be a good first step.

Comment 40 Claudio Camacho 2008-10-01 09:35:52 UTC
Hi Jesse,

Trying to build the xf86-video-intel from git gives an error:

checking for DRM... configure: error: Package requirements (libdrm >= 2.3.0) were not met:

No package 'libdrm' found


I already git cloned the libdrm and did make and make install. I also set the PKG_CONFIG_PATH to /opt/xtest (where I installed the libdrm from git), but it won't help.

Any clue? (I'm quite dummy in this matter)
Comment 41 Jesse Barnes 2008-10-01 10:16:42 UTC
PKG_CONFIG_PATH should be set to /opt/xorg-test/lib/pkgconfig for example (you have to point at the actual pkgconfig dir not just the top level prefix).  Hope that helps.
Comment 42 Claudio Camacho 2008-10-01 12:01:58 UTC
Thank you very much, now it builds.

However, there is some error about UXA and the compilation doesn't go till the end:

../doltcompile gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/include/xorg -I/usr/include/pixman-1    -I/opt/xtest/include -I/opt/xtest/include/drm   -Wall -Wpointer-arith -Wstrict-prototypes 	-Wmissing-prototypes -Wmissing-declarations 	-Wnested-externs -fno-strict-aliasing -I/usr/include/xorg -I/usr/include/pixman-1    -g -O2 -MT uxa-glyphs.lo -MD -MP -MF .deps/uxa-glyphs.Tpo -c -o uxa-glyphs.lo uxa-glyphs.c
uxa-glyphs.c: In function ‘uxa_glyphs_init’:
uxa-glyphs.c:85: warning: implicit declaration of function ‘dixLookupPrivate’
uxa-glyphs.c:85: warning: nested extern declaration of ‘dixLookupPrivate’
uxa-glyphs.c:85: warning: cast to pointer from integer of different size
uxa-glyphs.c: In function ‘uxa_unrealize_glyph_caches’:
uxa-glyphs.c:116: warning: cast to pointer from integer of different size
uxa-glyphs.c: In function ‘uxa_realize_glyph_caches’:
uxa-glyphs.c:156: warning: cast to pointer from integer of different size
uxa-glyphs.c:189: error: too many arguments to function ‘pScreen->CreatePixmap’
uxa-glyphs.c: In function ‘uxa_glyphs_fini’:
uxa-glyphs.c:237: warning: cast to pointer from integer of different size
uxa-glyphs.c: In function ‘uxa_glyph_cache_hash_lookup’:
uxa-glyphs.c:253: error: ‘struct _Glyph’ has no member named ‘sha1’
uxa-glyphs.c:260: error: ‘struct _Glyph’ has no member named ‘sha1’
uxa-glyphs.c:260: error: ‘struct _Glyph’ has no member named ‘sha1’
uxa-glyphs.c: In function ‘uxa_glyph_cache_hash_insert’:
uxa-glyphs.c:277: error: ‘struct _Glyph’ has no member named ‘sha1’
uxa-glyphs.c:277: error: ‘struct _Glyph’ has no member named ‘sha1’
uxa-glyphs.c:279: error: ‘struct _Glyph’ has no member named ‘sha1’
uxa-glyphs.c: In function ‘uxa_glyph_cache_upload_glyph’:
uxa-glyphs.c:359: warning: cast to pointer from integer of different size
uxa-glyphs.c:360: warning: implicit declaration of function ‘GlyphPicture’
uxa-glyphs.c:360: warning: nested extern declaration of ‘GlyphPicture’
uxa-glyphs.c:360: error: subscripted value is neither array nor pointer
uxa-glyphs.c: In function ‘uxa_glyph_cache_buffer_glyph’:
uxa-glyphs.c:465: error: subscripted value is neither array nor pointer
uxa-glyphs.c: In function ‘uxa_buffer_glyph’:
uxa-glyphs.c:504: warning: cast to pointer from integer of different size
uxa-glyphs.c:505: error: subscripted value is neither array nor pointer
uxa-glyphs.c:539: error: subscripted value is neither array nor pointer
uxa-glyphs.c: In function ‘uxa_glyphs’:
uxa-glyphs.c:803: error: ‘CREATE_PIXMAP_USAGE_SCRATCH’ undeclared (first use in this function)
uxa-glyphs.c:803: error: (Each undeclared identifier is reported only once
uxa-glyphs.c:803: error: for each function it appears in.)
uxa-glyphs.c:803: error: too many arguments to function ‘pScreen->CreatePixmap’
uxa-glyphs.c:842: error: subscripted value is neither array nor pointer
make[2]: *** [uxa-glyphs.lo] Error 1
make[2]: Leaving directory `/root/xf86-video-intel/uxa'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/xf86-video-intel'
make: *** [all] Error 2


I hope it can be avoided or fixed somehow to continue with the process. We have to discover what's going so that at last we can use the X4500 properly :-)

I'll wait for you answer and continue working on the compilation. Thanks again.
Comment 43 Claudio Camacho 2008-10-07 00:03:18 UTC
Hi Jesse,

I updated the xf86-video-intel with the latest git revision (7th October, at 10:00 o'clock). Now UXA compiles, but there is a problem in linking, and I think is that I'm doing something wrong.

After the whole compilation of the sources, there is a linking error like this:

/usr/bin/ld: cannot find -ldrm_intel
collect2: ld returned 1 exit status
make[4]: *** [intel_drv.la] Error 1
make[4]: Leaving directory `/root/xf86-video-intel/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/root/xf86-video-intel/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/root/xf86-video-intel/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/xf86-video-intel'
make: *** [all] Error 2


I exported the variable PKG_CONFIG_PATH and I used
./autogen.sh --prefix=/opt/xtest, where I have my copy of the libdrm built from git.

Can you please help me with this? Once it is linked, I could test the fresh xf86-video-intel and hopefully we'll finally fix it.
Comment 44 Jesse Barnes 2008-10-07 10:17:04 UTC
How recent is your DRM build?  You should have a /opt/xtest/lib/libdrm_intel.so in there somewhere.  If you do but it's still not linking your configure must not be picking up the right paths...
Comment 45 Justyn Butler 2008-10-07 17:24:42 UTC
I am having exactly the same issue with X4500MHD on a new Sony VGN-SR19XN.

I am watching intently to see if Claudio and Jesse can fix the bug.
Comment 46 Claudio Camacho 2008-10-07 21:26:10 UTC
Yes, I have the libdrm_intel.so in /opt/xtest/lib, but the configure doesn't pick it up when building the Intel driver.

Any clue?
Comment 47 Julien Cristau 2008-10-08 03:01:13 UTC
> --- Comment #46 from Claudio Camacho <claudiomkd@gmail.com>  2008-10-07 21:26:10 PST ---
> Yes, I have the libdrm_intel.so in /opt/xtest/lib, but the configure doesn't
> pick it up when building the Intel driver.
> 
> Any clue?
> 
presumably 'pkg-config --libs libdrm' includes -L/opt/xtest/lib?
@DRM_LIBS@ should be used whenever -ldrm_intel is, so this looks like a
bug in src/Makefile.am.
Comment 48 Aurélien ROUGEMONT 2008-10-08 03:06:01 UTC
well i can compile drivers without any problem, but i don't understand how git-bisect work. If you have any instruction, i could be quite helpful i guess.
Comment 49 Claudio Camacho 2008-10-09 11:19:42 UTC
Hi Jesse,

Now I compiled it. I had to manually edit the Makefile, but now they link.

Now, the matter is different. I only checked out the libdrm and xf86-video-intel from git, but no other modules. So, when I do like this:

~# export $LD_LIBRARY_PATH=/opt/xtest/lib
~# Xorg

The Xorg loads the old libdrm under /usr/lib and the old intel driver under /usr and not under /opt.

Do I have to download the whole xorg source and compile all modules to test the xf86-video-intel? Or there is another way to test only the driver and the libdrm without building everything from scratch?
Comment 50 Claudio Camacho 2008-10-09 13:32:09 UTC
Alright, to sum up:

I downloaded the whole Xorg source. I compiled and placed it at /opt/gfx-test. Then I exported $LD_LIBRARY_PATH=/opt/gfx-test/lib and run with this:

~$ startx -- /opt/gfx-test/bin/Xorg -verbose

The result is still the same :-(

I get a blank screen. However, maybe it is worthy to mention that now the screen pops up the gray background of the empty Xorg for some tenths of second and then it gets blank as usual.

Please find enclosed my fresh Xorg.0.log for more details.
Comment 51 Claudio Camacho 2008-10-09 13:35:07 UTC
Created attachment 19542 [details]
Xorg.0.log (xorg 1.5.99 + xf86-video-intel 2.5)

Xorg log generated from the whole Xorg sources from git as of 2008/10/10 22:00.
Comment 52 Justyn Butler 2008-10-09 14:45:38 UTC
Hi Claudio, if you're able to get on #xorg-devel we could try and work through this bug. Nick is "justyn".

I certainly concur with your thoughts that it is an EDID error. You can see that the EDID call is failing.

One (of the many) things I don't understand is why X doesn't spit out a proper error when it fails to get the necessary info about the LVDS over EDID. It just carries on regardless.
Comment 53 Justyn Butler 2008-10-09 16:48:39 UTC
Thinking some more, I don't think the EDID error can be the cause, I think it must be a symptom instead.

If Xorg doesn't get EDID data it will use whatever parameters are already set up or try and grab some from the BIOS.

But EDID only really specifies things like resolution and refresh rate, so how could the absence of any of these parameters cause the LVDS to display nothing at all?
Comment 54 Claudio Camacho 2008-10-09 21:24:59 UTC
I am a GNU/Linux user but I am quite a rookie. However, I will try to be on xorg-devel (maybe this evening or during the weekend) and we can discuss about the bug.
Comment 55 Justyn Butler 2008-10-10 16:01:16 UTC
Created attachment 19581 [details]
Xorg.0.log with --enable-debug and ModeDebug

Don't misunderstand, I'm not very experienced with Xorg hacking either!

Anyway, I compiled Xorg 1.5.1 (not the Intel driver) with --enable-debug because there are some debug statements in the DDC, EDID etc code that I hoped might be interesting.

I've run it on the SR19XN I have here (I think it is the same model as your laptop but an international variant). It doesn't seem to tell us anything new - just that it is not getting EDID data for the panel.

I'll attach the Xorg log.
It shows both debug output from Xorg through --enable-debug and debug output from the Intel driver from setting ModeDebug in the device section of xorg.conf.

Here is the output from around where the problem seems to be occurring:


(II) intel(0): Output VGA using monitor section Configured Monitor
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): Output LVDS has no monitor section
(II) intel(0): I2C bus "LVDSDDC_C" initialized.
(II) intel(0): Attempting to determine panel fixed mode.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
Error reading EDID block
Error reading EDID block
Error reading EDID block
Error reading EDID block
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
No EDID block returned
(II) intel(0): found backlight control method /sys/class/backlight/acpi_video0
Mapping VGAMem
base: a0000, realBase: a0000, alignOff: 0 
base: b77bc000 aligned base: b77bc000
Unmapping VGAMem
alignment offset: 0
(II) intel(0): EDID for output VGA
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
Error reading EDID block
Error reading EDID block
Error reading EDID block
Error reading EDID block
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
No EDID block returned
(II) intel(0): EDID for output LVDS
(II) intel(0): Not using default mode "1152x864" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x960" (exceeds panel dimensions)
(II) intel(0): Not using default mode "1280x960" (exceeds panel dimensions)

........and so on.
Comment 56 Justyn Butler 2008-10-10 16:21:23 UTC
I'm feeling pretty stuck at this point.

Could a dev weigh in with what we should be looking at/doing next?

Also, if the only problem is that Xorg isn't getting EDID from the laptop screen, surely it *must* be possible to get it displaying something by specifying the parameters manually.

Is that a correct assumption? Because I've been trying but with no luck.

The vesa driver does work and display ok on the panel. It defaults to the wrong resolution (1024x768) but you can force it to 1280x800 and it's fine with that.
Comment 57 Jesse Barnes 2008-10-10 22:00:57 UTC
(In reply to comment #56)
> I'm feeling pretty stuck at this point.
> 
> Could a dev weigh in with what we should be looking at/doing next?
> 
> Also, if the only problem is that Xorg isn't getting EDID from the laptop
> screen, surely it *must* be possible to get it displaying something by
> specifying the parameters manually.
> 
> Is that a correct assumption? Because I've been trying but with no luck.
> 
> The vesa driver does work and display ok on the panel. It defaults to the wrong
> resolution (1024x768) but you can force it to 1280x800 and it's fine with that.
> 

It looks like the EDID failure is normal though; several laptops don't have EDID info available since they expose panel timing in the VBIOS instead.  Since you're getting a valid mode list back, I don't think a lack of mode information is the problem here.  It seems like we're doing something else wrong when programming the panel, though I'm not sure what.  Did I already ask one of you for a copy of your video ROM (I don't seem to have a copy on this machine at least)?  It should be available in your sysfs directory:
  # cd /sys/devices/pci0000\:00/0000\:00\:02.0/
  # echo 1 > rom
  # cat rom > /tmp/rom.bin
  # echo 0 > rom
then attach your rom.bin to this bug.
Comment 58 Giovanni Pellerano 2008-10-11 00:30:55 UTC
> It looks like the EDID failure is normal though; several laptops don't have
> EDID info available since they expose panel timing in the VBIOS instead.

Yes i think it's the vbebios buggy :(

Since you're getting a valid mode list back, 

we don't get valid mode list back; it says that all modes are out of vert refresh range; no one of us know modes that works with the intel driver becouse no one has success with it; all the sr work with vesa Modeline    "1280x800_76.00"  108.77  1280 1360 1496 1712  800 801 804 836  -HSync +Vsync

but the intel driver says that i'ts out of range too.



I don't think a lack of mode information
> is the problem here.  It seems like we're doing something else wrong when
> programming the panel, though I'm not sure what.  Did I already ask one of you
> for a copy of your video ROM (I don't seem to have a copy on this machine at
> least)?  It should be available in your sysfs directory:
>   # cd /sys/devices/pci0000\:00/0000\:00\:02.0/
>   # echo 1 > rom
>   # cat rom > /tmp/rom.bin
>   # echo 0 > rom
> then attach your rom.bin to this bug.
> 


i'm going to attach it;

Comment 59 Giovanni Pellerano 2008-10-11 00:32:55 UTC
Created attachment 19583 [details]
VBEBIOS ROM.BIN [VAIO SR19XN, VAIO SR11M)
Comment 60 Justyn Butler 2008-10-11 01:19:59 UTC
Created attachment 19584 [details]
Video ROM of SR19XN

Bsdiff shows that there are some differences between my video ROM from an SR19XN and Giovanni's (from SR11M?).
For completeness I attach mine too.
Comment 61 Justyn Butler 2008-10-11 09:26:14 UTC
Giovanni, it doesn't say *all* modes are out of range, at least on mine.

If you look at my attachment two comments back, "Xorg.0.log with --enable-debug and ModeDebug", you can see that after rejecting 40 modes it prints out 18 probed modes without errors. The top one of these is the correct panel resolution, 1280x800.

That's assuming I'm not vastly misunderstanding something.
Comment 62 Karsten Heiken 2008-10-13 09:51:10 UTC
Okay, I'm at the university right now, so I can't say much right now.
But I do have the same problem with my Sony Vaio SR19XN.
The external screen works like a charm, and the internal display stays dark.
Well, not exactly dark. The panel-backlight is active, but the screen is black.
I can hear the Gnome-sounds, so the X-Server starts up normal.

There are some warnings listed in the Xorg.log:
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x55018a00 to 0xfc00e700
(WW) intel(0): ESR is 0x00000011, page table error
(WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE
(WW) intel(0): Existing errors found in hardware state.

As far as I remember, there are no error-messages - "only" these warnings.
Comment 63 Gordon Jin 2008-10-14 20:21:35 UTC
Could you test with git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next branch and xf86-video-intel master branch?
There're new GM45/G4X fixes and hope that could fix this problem as well.
Comment 64 Justyn Butler 2008-10-15 14:53:11 UTC
I can't manage to compile the drm-intel-next branch.
When I run, ie "make drivers/gpu" or "make include/drm" it just comes back with:
make: Nothing to be done for include/drm.

Any pointers? How do I compile just the required modules without building the whole kernel et al from scratch, or is that not possible?
Comment 65 Giovanni Pellerano 2008-10-17 13:48:51 UTC
With the kernel 2.6.27 git7 something thifferent happens.

Ive attached the full log;

i got a system freeze;

in the log i can read: 

(==) intel(0): Backing store disabled
(==) intel(0): Silken mouse enabled
(II) intel(0): Initializing HW Cursor
(II) intel(0): [DRI] installation complete
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x07f7f000 (pgoffset 32639)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
        at offset 0x7f7f000 failed (Invalid argument)

Fatal server error:
Couldn't bind memory for HW status

Comment 66 Giovanni Pellerano 2008-10-17 13:52:03 UTC
Created attachment 19728 [details]
xorg log | kernel 2.6.27 git 7
Comment 67 Claudio Camacho 2008-10-18 00:57:11 UTC
Hi, I tried 2.6.27-git8, because there are fixes in the i915 and especially for the GM45 series, and I get the same problem as Giovanni with -git7.

The screen does not get however blank this time. The Xorg tries to start, the screen goes blank for a second, then it comes back with the console cursor, and it stays there. At that point the Xorg is hanged, and only a blank console with the cursor (not blinking) on the top left corner is shown. I can press power button and shut down the computer, but Xorg still won't work.

Please find enclosed my Xorg.0.log for 2.6.27-git8 using xserver 1.5 and xf86-video-intel-2.4.2.
Comment 68 Claudio Camacho 2008-10-18 00:58:15 UTC
Created attachment 19733 [details]
Xorg.0.log-2.6.27-git8

Xorg.0.log from Xorg -verbose using 2.6.27-git8, xserver 1.5 and intel-2.4.2.
Comment 69 Giovanni Pellerano 2008-10-18 01:00:22 UTC
i get the same;

:(

so there is the need to contact some kernel developer i think;
Comment 70 Claudio Camacho 2008-10-18 04:12:21 UTC
Hi Giovanni,

I don't think that it is totally about the kernel. Just notice that the LVDS does something strange that is difficult to see because it is really dark, and then it gets blank. Moreover, the vesa driver works, so I think it is a thing with the xf86-video-intel driver.

I also tested the xorg from git with the -git8, and the same result: blank screen :(
Comment 71 Gordon Jin 2008-10-19 02:41:52 UTC
*** Bug 18107 has been marked as a duplicate of this bug. ***
Comment 72 Jerry L Kreps 2008-10-19 12:14:17 UTC
Created attachment 19747 [details]
output of monitor-probe -v vesa on Sony VAIO VGN-FW140E/H laptop

I am adding the output of monitor-probe -v vesa because it seems to point to a firmware BIOS problem, specifically a wrong checksum:

probing EDID                                       
probing EDID using VBE (port 0)                    
vbe: BIOS chksum wrong                             
  vbe: int 10h points to c000:0014: e9 65 21 db 40 00 e0 0a
VBE version: 3.0, oem version = 1.0                        
Memory: 131008k                                            
OEM name: Intel(r)Cantiga Graphics Chip Accelerated VGA BIOS
Vendor name: Intel Corporation                              
Product name: Intel(r)Cantiga Graphics Controller           
Product revision: Hardware Version 0.0                      
EDID: Error (0x4f15): 0x014f                                
Retrying with old LRMI interface                            
VBE version: 3.0, oem version = 1.0                         
Memory: 131008k                                             
OEM name:                                                   
Vendor name:                                                
Product name:                                               
Product revision:                                           
EDID: Error (0x4f15): 0x014f                                
vbe: BIOS chksum wrong                                      
  vbe: int 10h points to c000:0014: e9 65 21 db 40 00 e0 0a 
VBE version: 3.0, oem version = 1.0                         
Memory: 131008k                         

and it repeats several more times with similar results.
I don't know if this is of any help but it could suggest a problem with all Sony laptops using the GM45 driver.
Comment 73 Jerry L Kreps 2008-10-19 13:38:21 UTC
Created attachment 19748 [details]
Xorg.0.log from Mandriva 2009 pwp running on Sony VAIO VGN-FW140E/H
Comment 74 Jesse Barnes 2008-10-20 15:33:28 UTC
Ok, so the panel info in your vbios looks good:
*       panel type 00: 1280x800 clock 68200000                                  
                info:                                                           
                  LVDS: 0x42000300                                              
                  PP_ON_DELAYS: 0x01000900                                      
                  PP_OFF_DELAYS: 0x00800900                                     
                  PP_DIVISOR: 0x00270f06                                        
                  PFIT: 0x20000000                                              
                timings: 1280 128 50 356 800 8 2 2

But I wonder if we have the right PP_* values.  Can one of you attach the output of the 'intel_reg_dumper' program?

Also, it looks like the most recent logs contain other bugs, related to memory management, can you update your git trees and try again?  It's probably worth running the latest kernel bits as well, pull down Eric's DRM tree at git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel and check out the drm-intel-next branch.  That has all the latest fixes.

                   
Comment 75 Adam Williamson 2008-10-20 17:51:54 UTC
Jesse, just to let you know - Jerry is a poor innocent end-user running Mandriva 2009 who I directed into you guys' evil clutches, he is probably not going to be able to start running bleeding-edge kernel, Mesa, libdrm and intel git builds just to test fixes for this issue :). If a possible fix can be made available for the 2.4 branch I can build it into a test package for him, but otherwise he may not be able to help with testing much.
Comment 76 Claudio Camacho 2008-10-20 21:33:35 UTC
Hi Jesse,

First, thanks for all the time you are dedicating to this. Then, I would like to ask how to pull the drm-intel tree and patch it against a kernel, since I am not very confident in using latest kernel bits.

Do I have to checkout a -gitN vesion from kernel.org and the git drm-intel to patch against? Or do I just git clone the whole kernel and then git update somewhere inside a directory to update the to the latest drm-intel?

Sorry for my ignorance.
Comment 77 Claudio Camacho 2008-10-21 13:14:02 UTC
Hi again,

I just tried xorg from git (including xf86-video-inetl 2.5.0) on the top of linux-2.6.27-git10 (which includes the latest patches from drm-intel), and there is a similar situation as before, blank screen of course.

However, the Xorg.0.log is different from the previous one, so please check out the file Xorg.0.log-2.6.27-git10, because there are many differences concerning the LVDS output and the intel driver.
Comment 78 Claudio Camacho 2008-10-21 13:28:13 UTC
Created attachment 19792 [details]
Xorg.0.log-2.6.27-git10

Xorg.0.log-2.6.27-git10 with xf86-video-intel 2.5.0 and the whole Xorg from git as of 200810212320.
Comment 79 Claudio Camacho 2008-10-24 00:48:14 UTC
Hi,

Same story with 2.6.28-rc1 (includes the latest patches from Airlie and E. Anholt) and the today's checkout from xorg-git. Please find enclosed the Xorg.0.log-2.6.28-rc1.

Have a nice weekend..

P.S.- I won't without my Intel graphics :_(
Comment 80 Claudio Camacho 2008-10-24 00:49:20 UTC
Created attachment 19845 [details]
Xorg.0.log-2.6.28-rc1

Xorg.0.log-2.6.28-rc1 (latest patches for i915) + whole Xorg from git as of 200810241039.
Comment 81 Raphael Thierjung 2008-10-24 12:59:53 UTC
Good Evening guys,
I use a Sony Vaio SR19XN and have same problems as described here. Graphic works fine on an external display with full Desktop Effect support. The Display of the Notebook only works using VESA drivers. 

I am currently using the Intrepid RC released today. Following interested your comments for further solutions.

Greets
Raphael
Comment 82 Claudio Camacho 2008-10-27 14:52:18 UTC
Hi again,

For what is worth, I installed FreeBSD 7.1-BETA2-amd64 on my Vaio SR11M, which runs a xserver-1.4.2 with intel-2.4.2. The result is the same.

This clearly remarks the fact that the Linux kernel has not much to do with this bug, and it is obviously a missing quirk for the very LVDS of this laptop series. To fix the bug, I would even risk sending my laptop overseas, keep it in mind.

How can we know how to add such a quirk? I have been reading commit logs where quirks are added, and they seem very simple, since the only necessary thing is adding the hardware ID for the LVDS.

Any ideas?
Comment 83 Claudio Camacho 2008-10-29 11:25:04 UTC
Hi,

Here is more information, although a little bit Off-Topic. I plugged an external monitor (through VGA) to perform some tests, but the results made me quite sad, since the GM45 should outperform many old graphics cards, but it doesn't, take a look at this:

ATI Radeon 9600 M10: glxgears -> 1900FPS
Intel GM45: glxgears -> 680FPS

ATI Radeon 9600 M10: quake3 timedemo -> 127FPS
Intel GM45: quake3 timedemo -> 73FPS


I just read information from the Intel site and the benchmarks list at notebookcheck.com and the GM45 should be much better than the Radeon 9600 M10, but it doesn't seem to be like that.

So, besides the LVDS problem, I am also worried that the performance of the GM45 is not what I was expecting from the product details. Does anyone else have this poor performance?

Is this poor performance due to the current drivers and the lack of support?
Comment 84 Jerry L Kreps 2008-10-29 13:23:11 UTC
(In reply to comment #83)
> Hi,
> 
> Here is more information, although a little bit Off-Topic. I plugged an
> external monitor (through VGA) to perform some tests, but the results made me
> quite sad, since the GM45 should outperform many old graphics cards, but it
> doesn't, take a look at this:
> 
> ATI Radeon 9600 M10: glxgears -> 1900FPS
> Intel GM45: glxgears -> 680FPS
> 
> ATI Radeon 9600 M10: quake3 timedemo -> 127FPS
> Intel GM45: quake3 timedemo -> 73FPS
> 
> 
> I just read information from the Intel site and the benchmarks list at
> notebookcheck.com and the GM45 should be much better than the Radeon 9600 M10,
> but it doesn't seem to be like that.
> 
> So, besides the LVDS problem, I am also worried that the performance of the
> GM45 is not what I was expecting from the product details. Does anyone else
> have this poor performance?
> 
> Is this poor performance due to the current drivers and the lack of support?
> 

I found it interesting that when I couldn't get the Intel 2.4.2 driver to load the X4500 (G45) chip on this Sony I tried several others and found that when I used the Xorg|vesa driver I appeared to get some form of acceleration!
Both gears and glxgears gives me about 1300FPS, which is fast enough to run Google or Stellarium without much of a problem, although it is not fast enough to run SecondLife adequately.

I wasn't aware that the VESA driver could give an accelerated screen so perhaps this points to another aspect of the problem?
Comment 85 Ugo Viti 2008-10-29 13:30:43 UTC
Hi,

Today I purchased a new Sony Vaio VGN-SR11M, and I'm experiencing the same issue with the graphic drivers.

this problem exist with kernel 2.6.27.4 and intel 2.5.0 drivers.

my laptop display works only using the vesa drivers.

tested with Fedora 10 (rawhide) on a x86_64 installed machine:

kernel-2.6.27.4-61.fc10.x86_64
xorg-x11-drv-i810-2.5.0-1.fc10.x86_64

I'm experiencing an other bug (related?) too:
if I hot connect external TFT monitor, the system crash completely, reboot needed.
if I power-on the laptop with monitor already connected, the system boot cleanly and the external monitors works with intel drivers too, but if I hot remove the monitor vga cable, the system hang.

let's me know if you need others info.

Best Regards
Comment 86 Ugo Viti 2008-10-30 09:24:45 UTC
Created attachment 19963 [details] [review]
gm45-quirk-sony-vaio-vgn-sr11m.patch

Hi,

today I looked more deeply into LVDS blank display problem, I checked out latest release of xf86-video-intel:

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel

compiled and installed without problems, but the laptop display continue to not works.

I also tried all available quirks into src/i830_quirks.c, (to demonstrate  that my laptop get recognised by i831_quirks I made and attached a patch that disable completely LVDS for the VGN-SR11M model, but xorg doesn't start any more of course... so it's very useless :))

in order I tried:

quirk_ignore_tv
quirk_ignore_lvds
quirk_ignore_macmini_lvds
quirk_pipea_force
quirk_ivch_need_dvob
quirk_reset_modes
quirk_pfit_safe

none worked.

the SONY VAIO VGN-SR11M graphic driver is detected with PCI_CHIP_GM45_GM, 0x104d, 0x9033

I don't know if the problem is into src/i830_lvds.c

I tried any possible and imaginable xorg.conf option (tacked from man intel).

parsing out Xorg.0.log from warrning I get:

cat /var/log/Xorg.0.log | grep WW
		(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(WW) Open ACPI failed (/var/run/acpid.socket) (Connection refused)
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00440206 to 0x00440000
(WW) intel(0): PIPEBSTAT before: status: LBLC_EVENT_ENABLE SVBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
(WW) intel(0): PIPEBSTAT after: status: LBLC_EVENT_ENABLE SVBLANK_INT_ENABLE
(WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x24000500 to 0x22000300
(WW) intel(0): ESR is 0x00000011, page table error
(WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): Existing errors found in hardware state.
(WW) SynPS/2 Synaptics TouchPad can't grab event device, errno=16

Any help here is appreciated.

Best Regards.
Comment 87 martin.p.kemp 2008-11-08 06:34:10 UTC
Hi - just adding my name to the list people experiencing this issue (mine's a Sony SR19XN)

I can see the thread has been dead for a few days - any updates from anyone?

Many thanks

Martin
Comment 88 Claudio Camacho 2008-11-08 23:57:43 UTC
Hi Martin,

Thanks for joining the cause. I think Jesse Barnes is quite busy writing new patches for KMS (kernel mode-setting) and GEM (graphics execution manager). And that's why this thread has been inactive for several days.

Please be patient, and, I hope, when Jesse has time, we can get this fixed, because the bug is very tiny, but so weird that nobody can guess what it is related with.
Comment 89 martin.p.kemp 2008-11-09 02:49:28 UTC
(In reply to comment #88)
Great thank you for the update Claudio.

Good luck Jesse!

Martin
Comment 90 Jesse Barnes 2008-11-10 14:34:28 UTC
Thanks for your patience everyone, sounds like this is a popular type of platform. :)

I still need the output from 'intel_reg_dumper' attached to this bug.  It would be best if someone could start up X with a VGA monitor attached, then capture the register dump from an xterm or whatever on that window.  That should tell me what the LVDS and other registers are set to...

It could be that something else in our LVDS programming is off somewhere; the register dump should help me to prove or disprove that theory.
Comment 91 Giovanni Pellerano 2008-11-10 14:49:22 UTC
ok i'm going to do it now;

i'm a sony vaio sr-19xn, the same model it has only the fingerprint
reader also.

will it work also for me?
Comment 92 Giovanni Pellerano 2008-11-10 14:57:50 UTC
arg ... for tonight i cant try this cause on my gentoo libpciaccess need
xorg 1.5.2 that's masked;

is there an other way to do it or i can do it only with that program?

any one other can do it? claudio ?


thanks
Comment 93 Justyn Butler 2008-11-10 16:37:23 UTC
Created attachment 20197 [details]
intel_reg_dumper output on SR19XN using external monitor

Here is the intel_reg_dumper output running Ubuntu 8.10 with a monitor plugged in.
The machine is a Sony Vaio VGN-SR19XN.
Comment 94 Justyn Butler 2008-11-10 16:38:44 UTC
Created attachment 20198 [details]
intel_reg_dumper output without monitor

Here is intel_reg_dumper without any monitor plugged in, obtained using a VT.
Comment 95 Justyn Butler 2008-11-10 16:40:45 UTC
Created attachment 20199 [details]
intel_reg_dumper output using VESA driver

Same machine (SR19XN) this time booted without a monitor attached, using the laptop LVDS display and the VESA driver (with some extra parameters in xorg.conf to get correct resolution).
Comment 96 jelle foks 2008-11-11 11:01:00 UTC
Created attachment 20222 [details]
intel_reg_dumper output on VGN-FW140E, using vesa driver on the lcd display at 1024x768 (without monitor)
Comment 97 Jesse Barnes 2008-11-11 11:22:06 UTC
Thanks for the dumps.  It looks like they were captured with a driver that didn't have the clock gating fixes though.  Can someone give the latest git tree a try?  There have been some fixes affecting GM45 committed there recently; if they help I can spin a 2.5.x release that includes them.  Other than that, the registers look pretty good, so I'm hoping one of the recently pushed fixes will end up correcting this bug.
Comment 98 jelle foks 2008-11-11 12:59:05 UTC
Created attachment 20225 [details]
intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), while the non-working blank screen is seen

(this is with xorg from ubuntu 8.10, I'll try to checkout & build git, but have not done that before so I'll probably need a little time to check it out etc)
Comment 99 jelle foks 2008-11-11 13:02:26 UTC
Created attachment 20226 [details]
intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), after switching back to the console (ctrl-alt-f1)
Comment 100 Ugo Viti 2008-11-11 14:32:49 UTC
Hi Jesse,

I just compiled and tested the latest git of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (kernel 2.6.28-rc3) but after enabling the intel driver into xorg.conf the LVDS display remain blank like previous versions. Moreover with this version I get a kernel panic (not blocking the system) into dmesg:

[drm] Initialized i915 1.6.0 20080730 on minor 0
resource map sanity check conflict: 0xc0000000 0xcfffffff 0xc0000000 0xc7feffff vesafb
------------[ cut here ]------------
WARNING: at arch/x86/mm/ioremap.c:226 __ioremap_caller+0xc7/0x299()
Modules linked in: i915 drm ipt_MASQUERADE xt_multiport ipt_ULOG xt_limit nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_ma
ngle iptable_nat nf_nat bridge ipv6 stp bnep sco l2cap bluetooth tun fuse cpufreq_ondemand acpi_cpufreq freq_table uinput arc4 ecb iwlagn iwlcore snd_hda_intel rfkill mac80211 snd_pcm uvcvideo snd_timer snd_pag
e_alloc snd_hwdep sdhci_pci sdhci snd firewire_ohci compat_ioctl32 firewire_core i2c_i801 video serio_raw mmc_core pcspkr videodev v4l1_compat battery output crc_itu_t joydev sony_laptop i2c_core sky2 cfg80211 
soundcore ac [last unloaded: microcode]
Pid: 2947, comm: Xorg Not tainted 2.6.28-rc3-jugin #3
Call Trace:
 [<ffffffff81046831>] warn_on_slowpath+0x58/0x7d
 [<ffffffff81030959>] ? change_page_attr_set_clr+0x136/0x304
 [<ffffffff8134eb29>] ? printk+0x3c/0x43
 [<ffffffff81351143>] ? _read_unlock+0x2b/0x36
 [<ffffffff8102f9bb>] __ioremap_caller+0xc7/0x299
 [<ffffffffa03808d6>] ? i915_gem_entervt_ioctl+0x470/0x505 [i915]
 [<ffffffff8102fc7f>] ioremap_wc+0x1b/0x24
 [<ffffffffa03808d6>] i915_gem_entervt_ioctl+0x470/0x505 [i915]
 [<ffffffffa0363b85>] drm_ioctl+0x1d6/0x25e [drm]
 [<ffffffffa0380466>] ? i915_gem_entervt_ioctl+0x0/0x505 [i915]
 [<ffffffff810d4ddd>] vfs_ioctl+0x5f/0x78
 [<ffffffff810d5199>] do_vfs_ioctl+0x3a3/0x3d5
 [<ffffffff810d5220>] sys_ioctl+0x55/0x77
 [<ffffffff8101123a>] system_call_fastpath+0x16/0x1b
---[ end trace b498a1936775def4 ]---

I don't know if it's related, but when starting xorg with intel driver using the previous stock fedora rawhide kernel 2.6.27.5 I get:

i915_driver_load "failed to enable MSI"

I'm using libdrm 2.4.1 and xf86-video-intel 2.5.0-trunk (updated 7 nov)

my laptop is a Sony Vaio VGN-SR11M
Comment 101 jelle foks 2008-11-11 14:48:47 UTC
Ok, I upgraded the libdrm to the git version and compiled a new intel_drv.so from git:

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel

and the Xorg.0.log now says 'module version = 2.4.97' (was 'module version =
2.4.1'), but the behaviour is unchanged.

Other notable, maybe interesting (?) changes in the Xorg.0.log are:

+(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB

and

 (II) intel(0): 0x10000000:            end of aperture
+(WW) intel(0): ESR is 0x00000001
+(WW) intel(0): Existing errors found in hardware state.
 (II) intel(0): using SSC reference clock of 100 MHz

Comment 102 jelle foks 2008-11-11 15:04:39 UTC
I guess I used an older git tree than Ugo?

I don't get an oops on it though, but I do get possibly interesting messages in dmesg: (the 63-66 messages are from xorg startup and 72+ after 'ctrl-alt-f1'):

[   63.686660] mtrr: no MTRR for c0000000,7ff0000 found
[   65.378118] [drm] Initialized drm 1.1.0 20060810
[   65.383059] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   65.383069] pci 0000:00:02.0: setting latency timer to 64
[   65.383327] [drm] Initialized i915 1.6.0 20060119 on minor 0
[   65.383919] [drm:i915_getparam] *ERROR* Unknown parameter 5
[   66.379546] set status page addr 0x07fff000
[   72.743051] [drm:i915_getparam] *ERROR* Unknown parameter 5
[   73.502327] set status page addr 0x07fff000

Comment 103 Ugo Viti 2008-11-11 15:21:51 UTC
Jelle, I get the oops only using the latest drm-intel kernel tree (2.6.28-rc3) from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.

however I get the opps only after first VT switch or Xorg logout.

If I boot with VGA monitor connected I get Xorg full accelerated in the external monitor, and it's seem more fast/responsive on 2.6.28-rc3-drm-intel-next than kernel 2.6.27.

However if I hot plug the VGA monitor after system boot, I get a hard crash of the system, reboot needed.

just updated also xf86-video-intel to latest commit (Default to FULL_ASPECT panel fitting - Jesse Barnes), but LVDS remain blank.
Comment 104 Ugo Viti 2008-11-11 15:26:31 UTC
However the latest xf86-video-intel git is marked as version 2.4.97?

this is my Xorg.0.log:

(II) Loading /usr/lib64/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
        compiled for 1.5.2, module version = 2.4.97
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 4.1
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
        i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
        E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
        965GM, 965GME/GLE, G33, Q35, Q33,
        Mobile Intel® GM45 Express Chipset,
        Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
(II) Primary Device is: PCI 00@00:02:0
(II) resource ranges after xf86ClaimFixedResources() call:
        [0] -1  0       0xffffffff - 0xffffffff (0x1) MX[B]
        [1] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
        [2] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
        [3] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [4] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
        [5] -1  0       0x00000000 - 0x00000000 (0x1) IX[B]
(II) resource ranges after probing:
        [0] -1  0       0xffffffff - 0xffffffff (0x1) MX[B]
        [1] -1  0       0x000f0000 - 0x000fffff (0x10000) MX[B]
        [2] -1  0       0x000c0000 - 0x000effff (0x30000) MX[B]
        [3] -1  0       0x00000000 - 0x0009ffff (0xa0000) MX[B]
        [4] 0   0       0x000a0000 - 0x000affff (0x10000) MS[B]
        [5] 0   0       0x000b0000 - 0x000b7fff (0x8000) MS[B]
        [6] 0   0       0x000b8000 - 0x000bffff (0x8000) MS[B]
        [7] -1  0       0x0000ffff - 0x0000ffff (0x1) IX[B]
        [8] -1  0       0x00000000 - 0x00000000 (0x1) IX[B]
        [9] 0   0       0x000003b0 - 0x000003bb (0xc) IS[B]
        [10] 0  0       0x000003c0 - 0x000003df (0x20) IS[B]
Comment 105 Ugo Viti 2008-11-11 15:35:13 UTC
Created attachment 20231 [details]
intel_reg_dumper of Sony Vaio VGN-SR11M

System: Sony Vaio VGN-SR11M
Kernel: 2.6.28-rc3 x86_64

intel_reg_dumper using intel driver with external VGA monitor connected and LVDS blank
Comment 106 jelle foks 2008-11-11 15:53:42 UTC
ah, 2.4.97 is what I see too when I use the intel_drv.so that I compiled from git. I'm using the latest 2.6.27-7-generic kernel that comes with ubuntu 8.10 (intrepid, 32-bit).

devs: How else can we help debug this? Is there any type of documentation from Intel (or others?) about these chips?

Do the register dumps have any useful info? I don't know what the registers are, but for example a register named DSPCLK_GATE_D is the same for vesa xorg and text console, but has a different value in the 'blank screen' state of the intel driver, then perhaps it's worth trying to find out why (clock gating? -> parts of the chip maybe not activated)... Or is this a totally wrong place to look?

Can we make such register dumps from a working system with an alternative os?
Comment 107 Claudio Camacho 2008-11-12 10:11:43 UTC
****ck!

No way. I've been more than 3 hours trying to get the Xorg compiled, and when I got it, there is some problem with a symbol in intel_drv.so and the Xorg crashes before showing anything, this is the error:

/opt/gfx-test/bin/Xorg: symbol lookup error: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so: undefined symbol: intel_bufmgr_gem_init


The Xorg is 1.5.99.1 built on the top of a 2.6.28-rc4. The git pull is from 3 hours ago, that is very very fresh, with the latest drm and mesa code, including the latest patches added to xf86-video-intel during today.

Really, I'm getting frustrated about this, maybe I should just sell the laptop :P

Hope you guys have better luck testing these latest patches for Jesse.

Good luck!
Comment 108 Jesse Barnes 2008-11-12 10:41:27 UTC
Yeah, that's annoying.  xf86-video-intel depends on libdrm, which just had all its names change recently.  So you'll need to:
  1) update libdrm
  2) rebuild Mesa
  3) rebuild xf86-video-intel
before things will fully work again (if you want to live on the bleeding edge anyway).
Comment 109 Claudio Camacho 2008-11-12 22:23:58 UTC
Hi Jesse,

Thanks for the guidance (and the patience). Anyways, I am quite a bit fed up already.

Yesterday I tried updating libdrm and rebuilding mesa and xf86-video-intel, but the compilation gives some errors, libdrm cannot be fully installed because libtool complains about directories not ending in /usr/local/lib, which I don't understand at all. For instance it says:

libtool: error: install: cannot copy 'libdrm_intel.la' into a directory not ending in '/usr/local/lib'


I tried building and installing both on /opt/gfx-test, where I have everything for testing, and even I tried a fresh distribution on a new partition of my laptop where there was no Xorg at all and I downloaded the whole Xorg and built from scratch, with the prefix /usr, trying to get it working there too.

But also in the latter I got many errors, such as aclocal complaining about paths and libtool still complaining about directories not ending in /usr/local/lib, so I don't know anymore what to do.

And since I use Debian, it will be quite a long time before I get any 2.5.x driver on the distribution package, which sets me up even more.

I hope someone else is testing and is more capable of fixing this building errors with paths, and I really hope we are really close to fixing this stupid bug.

Good luck and thanks again!
Comment 110 Michael Fu 2008-11-13 22:13:03 UTC
could someone try this modeline?

Modeline    "1280x800_60"  68.88 1280 1296 1344 1410 800 816 820 848 
-HSync +Vsync

, and please also attach your xorg.log to verify. thanks.

Comment 111 Raphael Thierjung 2008-11-13 22:59:28 UTC
with vesa or intel drivers?

Comment 112 Michael Fu 2008-11-13 23:43:44 UTC
(In reply to comment #111)
> with vesa or intel drivers?
> 

sorry, pls try this modeline instead:

"1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848    -hsync -vsync

intel driver.

thanks,
Michael
Comment 113 Raphael Thierjung 2008-11-14 03:02:32 UTC
Created attachment 20300 [details]
Xorg.log with Modeline described in Comment #112
Comment 114 Raphael Thierjung 2008-11-14 03:04:01 UTC
Comment on attachment 20300 [details]
Xorg.log with Modeline described in Comment #112

Xorg.log with Modeline described above. Laptop Display still not working :-/
Comment 115 Ugo Viti 2008-11-14 03:45:15 UTC
Created attachment 20301 [details]
Xorg.0.log with Modeline 1280x800_60

Attached my Xorg.0.log running with Modeline "1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848 -hsync -vsync, LVDS still not working of course :-)

The following errors can cause the LVDS blank problem?

(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB

and these?

(WW) intel(0): ESR is 0x00000011, page table error
(WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): Existing errors found in hardware state.
(II) intel(0): using SSC reference clock of 100 MHz
(II) intel(0): Selecting standard 18 bit TMDS pixel format.
(II) intel(0): Output configuration:
(II) intel(0):   Pipe A is off
(II) intel(0):   Display plane A is now disabled and connected to pipe A.
(II) intel(0):   Pipe B is on
(II) intel(0):   Display plane B is now enabled and connected to pipe B.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output LVDS is connected to pipe B


LVDS should be connected to pipe A? or B is the correct pipe?
Comment 116 Ugo Viti 2008-11-14 03:49:15 UTC
Created attachment 20302 [details]
xorg.conf used to test Modeline 1280x800_60
Comment 117 Michael Fu 2008-11-14 15:51:03 UTC
(In reply to comment #112)
> (In reply to comment #111)
> > with vesa or intel drivers?
> > 
> 
> sorry, pls try this modeline instead:
> 
> "1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848    -hsync -vsync
> 
> intel driver.
> 
> thanks,
> Michael
> 

I'm sorry,  how about this

"1280x800_60" 68.88 1280 1296 1344 1410 800 804 808 815    -hsync -vsync
Comment 118 Ugo Viti 2008-11-14 16:07:52 UTC
Created attachment 20313 [details]
Xorg.0.log with Modeline "1280x800_60" 68.88 1280 1296 1344 1410 800 804 808 815 -hsync -vsync

same result: LVDS blank :-(
Comment 119 Ugo Viti 2008-11-14 16:31:54 UTC
Created attachment 20314 [details]
sony-vaio-vgn-sr11m-rom.bin

If can help, I attached my Sony Vaio VGN-SR11M GM45 ROM, using the following procedure:

  $ cd /sys/devices/pci0000\:00/0000\:00\:02.0/
  $ echo 1 > rom
  $ cat rom > ~/Desktop/sony-vaio-vgn-sr11m-rom.bin
  $ echo 0 > rom

A question about display initialization:

I noted that booting with external VGA connected and intel driver, the gnome-display-properties shipped with Fedora 10, detect 2 Monitor: Laptop Display and the external monitor, but, it identify my external monitor as "Laptop Display"... I don't know if this can be the cause of this bug, because the intel driver doesn't detect correctly the LVDS display?
Comment 120 Michael Fu 2008-11-15 03:38:09 UTC
ok. try last one:

"1280x800" 68.9 1280 1292 1340 1440 800 804 807 823 +hsync +vsync

thanks.
Comment 121 Ugo Viti 2008-11-15 04:09:01 UTC
Created attachment 20320 [details]
Xorg.0.log with Modeline  "1280x800_60" 68.9  1280 1292 1340 1440 800 804 807 823 +hsync +vsync

same results :(

with Modeline  "1280x800_60" 68.9  1280 1292 1340 1440 800 804 807 823 +hsync +vsync

intel driver: LVDS blank display

vesa driver: works good
Comment 122 jelle foks 2008-11-16 23:33:47 UTC
Good news everyone: I have picture!

Posting this using the intel driver working fine on my laptop display...

The 'blank display' to me looks like the panel isn't active (the slow white-to-clouds change that happens when you leave it on for more than a couple of seconds looks like charge leaking from the display elements).

After reading more docs, and staring at the register dumps even more and getting nowhere, I decided it might be a good idea to enable the OUTREG debugging in the driver and looking at the log...

After doing that, I saw that there were multiple calls to i830SetLVDSPanelPower() changing PP_CONTROL from 1 to 0 and back (display on and off) during xorg startup... 

That stroke me as a little silly, so I decided to add a 'if (!on) return;' to the beginning of that function (in i830_lvds.c), recompiled and copied the driver and woa and behold: I saw the kde login prompt.

My xorg crashed soon after that though (signal 11), but that may have been the result of combining the default ubuntu xorg server with the latest git intel driver (and/or that whole libdrm stuff)...

So I tried the same patch to the ubuntu intrepid source package (for which Xorg.0.log says 'module version 2.4.1'), and it works too, without segfaults...

Whee...

Jesse, am I right in assuming that's enough info for you or other xorg devs to get this working for everyone els?

Comment 123 Karsten Heiken 2008-11-16 23:55:41 UTC
(In reply to comment #122)
> Good news everyone: I have picture!

Yeah! Me too!

Your fix did the job here.
I used the current 2.5.0 release: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.5.0.tar.bz2

The latest git-release crashed after a few seconds, but the 2.5.0 works (for now ;)).

In xf86-video-intel-2.5.0/src/i830_lvds.c, around line 390 ( before if(on) { ) a simple line
if (!on) return;
did the job.

Thanks mate! :)
Comment 124 Ugo Viti 2008-11-17 02:12:26 UTC
Created attachment 20365 [details] [review]
intel-vaio-lvds.patch

Very good work Jelle!

You have found the problem! you are very very great :-) 

finally I can use the LVDS display with accelerated intel driver :-)

I attached your suggested patch to this post.

Now some xf86-intel-driver developer should be look into the code to verify if this is the right method to fix our problem and make a patch upstream :-)

Thank you all for looking into this bug.

Best Regards.
Comment 125 Mihai Dumitrescu 2008-11-17 05:26:29 UTC
Thank you Jelle! A lot!
And thanks for the xf86-video-intel-2.5.0 link Karsten.
(it isn't patched though)
I managed to get the intel driver to work on a Sony Vaio VGN-FW140E running Ubuntu 8.10. 
Since i am kinda a beginner in Linux I had some problems compiling/installing though. Had to install all the packages from:

http://ubuntuforums.org/showthread.php?p=1646660

And then xorg couldn't find the driver module so i had to copy everything from:

/usr/local/lib/xorg/modules/drivers 
to
/usr/lib/xorg/modules/drivers

weird. Anyway, it works so i'm happy.

Btw, i'm getting ~700fps in glxgears. A bit low i think. Anyway, it doesn't matter:D.

Thanks again,
Mihai

PS: get it upstream so many can enjoy it:).
Comment 126 Claudio Camacho 2008-11-17 11:21:39 UTC
Hi Jelle,

Thank you very much for discovering the problem. Now we hope that Jesse can examine how this could be done without affecting the general code of the driver for the rest of workstations.

Hopefully we see some patch for a Christmas present! :D

Congrats again!
Comment 127 Shady Zayat 2008-11-19 04:10:23 UTC
I just want to confirm that this fix worked for me on my Sony Vaio VGN-FW170J with kubuntu-8.10-amd64 installed
I used the source package for xserver-xorg-video-intel from ubuntu repositories ( 2:2.4.1-1ubuntu10 ) and applied the patch. The display is on now.

The login screen has two vertical strips with "noise" at the sides, but the display is ok once kde starts.

As for the backlight, the control buttons doesn't work, it's always set to it's maximum value.

The following lines are written to Xorg.0.log almost every 10 seconds:
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.

Although direct rendering is on, glxgears outputs: 3610 frames in 5.0 seconds = 721.848 FPS, which is way lower than what I expects from this card.

X crashed when I tried to change the resolution from systemsettings.
Comment 128 Claudio Camacho 2008-11-19 08:09:34 UTC
Hello guys!

I manually patched the driver (version 2.4.2-1 from Debian Sid repositories) and now it is working, although it is a little bit rudimentary and glxgears and also any GLX program show very "strange" as well as low performance.

I created the .deb file for Debian Sid amd64, so if it helps, here is the link to it:

http://www.claudiocamacho.org/files/xserver-xorg-video-intel_2.4.2-1_amd64.deb


Meanwhile we get a proper driver release, you can try that and have some nice experiences using Xv for video playback or any GLX application :)

I'll keep researching.

Comment 129 Claudio Camacho 2008-11-19 08:18:48 UTC
BTW,

I just tried the 2.4.2-1 patched with a different kernel (2.6.28-rc4) and the system totally froze.

So, it works with 2.6.27.5, but not with 2.6.28-rc4.

Besides, glxgears shows only 60fps, while Quake 3 Arena runs nicely but only at 59fps with low detail, which should be around 100fps and more than 1500fps for glxgears.

Xvideo seems to work without any major problem.
Comment 130 Julien Cristau 2008-11-19 09:49:18 UTC
> --- Comment #129 from Claudio Camacho <claudiomkd@gmail.com>  2008-11-19 08:18:48 PST ---
> Besides, glxgears shows only 60fps, while Quake 3 Arena runs nicely but only at
> 59fps with low detail, which should be around 100fps and more than 1500fps for
> glxgears.
> 
if your refresh rate is 60Hz, then 60fps is expected.
Comment 131 jelle foks 2008-11-19 16:08:26 UTC
fyi, I also get the 'junk' on the sides on the kde login screen (it looks like uninitialized pixels) and after logging in that's gone and the full screen is used.

The display brightness hotkeys also don't work for me, but I'm not sure if that is something for this driver, because I can change it using the sys filesystem:

 echo 1 >/sys/class/backlight/acpi_video0/brightness

Comment 132 Shady Zayat 2008-11-19 17:30:47 UTC
yeah I'm sorry for the backlight thing, it's definitely not the video driver's fault ( I installed xbacklight and it works )
Comment 133 Claudio Camacho 2008-11-20 01:29:11 UTC
Actually, about the refresh rate..

With my previous laptop, the refresh rate was 60Hz, but glxgears showed up to 2300fps and Quake 3 Arena was giving a 143fps peak.

Now, with the Vaio LVDS, the refresh rete is set at 59.9Hz (at least using 2.6.27.5 + xserver-xorg-video-intel-2.4.2), and _everything_ shows up to 60fps. However, all glx programs and games perform well (they usually don't go below 60fps, but they don't show more either). I don't know if this is a mistake, or if I should wait for 2.5.1+2.6.28.

If anyone has some information, please post it here :)
Comment 134 Jerry L Kreps 2008-11-20 08:29:09 UTC
(In reply to comment #133)
> Actually, about the refresh rate..
> 
> With my previous laptop, the refresh rate was 60Hz, but glxgears showed up to
> 2300fps and Quake 3 Arena was giving a 143fps peak.
> 
> Now, with the Vaio LVDS, the refresh rete is set at 59.9Hz (at least using
> 2.6.27.5 + xserver-xorg-video-intel-2.4.2), and _everything_ shows up to 60fps.
> However, all glx programs and games perform well (they usually don't go below
> 60fps, but they don't show more either). I don't know if this is a mistake, or
> if I should wait for 2.5.1+2.6.28.
> 
> If anyone has some information, please post it here :)
> 


glxgears "fps" are dependent on the size of the window in which the gears are displaying.  If I shrink that window to the smallest it can be my "fps" rate goes up to around 2800.  If I make that window the full size of my display it drops to only 68 "fps" and the wheels do not rotate smoothly.

I am presently using XOrg's vesa driver to get by until this blank screen  solution is passed down to the users.  Supposedly, vesa isn't supposed to offer  acceleration and glxgears should not work at all.  The MCC display configuration tool says that 3D is not available, yet I get good performance on GoogleEarth and sluggish but acceptable performance on Stellarium.   
Comment 135 Gordon Jin 2008-11-22 18:34:33 UTC
(In reply to comment #133)
> Actually, about the refresh rate..
> 
> With my previous laptop, the refresh rate was 60Hz, but glxgears showed up to
> 2300fps and Quake 3 Arena was giving a 143fps peak.
> 
> Now, with the Vaio LVDS, the refresh rete is set at 59.9Hz (at least using
> 2.6.27.5 + xserver-xorg-video-intel-2.4.2), and _everything_ shows up to 60fps.
> However, all glx programs and games perform well (they usually don't go below
> 60fps, but they don't show more either). I don't know if this is a mistake, or
> if I should wait for 2.5.1+2.6.28.
> 
> If anyone has some information, please post it here :)
> 

As Julien said, 60fps is expected.

http://intellinuxgraphics.org/community_testing.html lists this issue:
- vblank: the new mesa code changes the default setting to sync'ing to vblank. So now it's not a surprise to see glxgears reports 60FPS. But this introduces some bugs (like bug#17967), and setting vblank_mode back to 0 works around it.
Comment 136 Michael Fu 2008-11-22 22:33:41 UTC
*** Bug 18582 has been marked as a duplicate of this bug. ***
Comment 137 elupus 2008-11-23 09:44:31 UTC
(In reply to comment #134)

> glxgears "fps" are dependent on the size of the window in which the gears are
> displaying.  If I shrink that window to the smallest it can be my "fps" rate
> goes up to around 2800.  If I make that window the full size of my display it
> drops to only 68 "fps" and the wheels do not rotate smoothly.

This is a common problem with these intel chipset, from what i've been told it is a problem with the memory preassure with a large amount of writes to the backbuffer. I.e. the card has power, but the memory bus can't keep up. 

There are supposed to be feature supported by the chipset which supposedly should improve this, but it's not yet implemented in the intel linux drivers. Supposedly it is in the windows drivers, but i've not been able to find any better performance there. I've not tested that much thou.

Comment 138 Claudio Camacho 2008-11-24 13:53:12 UTC
Hello again,

I just tried xf86-video-intel-2.5.1 on Debian Sid, using the dirty patch on i830_lvds.c, and I was using the kernel 2.6.28-rc6, to try how the performance is (due to the GEM). However, I noticed that Xorg crashes after 5 minutes of usage.

In fact, any GLX application (TORCS, Quake3, or even KDE4 OpenGL composite manager) will make the Xorg crash in a few minutes. The mouse can be moved, but the rest of the screen and they keyboard are frozen.

Please notice that using 2.6.27 + xf86-video-intel-2.5.1 is not a problem at all, so this is related to the GEM and therefore out of this topic, but I just mention it here, since we are talking about the GM45.

I hope we can see some real patch soon.
Comment 139 Daniel FitzGibbons 2008-11-24 15:22:40 UTC
(In reply to comment #138)

Actually, I have this issue with Fedora 10 (while running kwin's compositor), which is running a 2.6.27 kernel, so it might not be GEM related (unless Fedora brought GEM back to 2.6.27...).  I haven't had the issue in Kubuntu 8.10 or Mandriva 2009 though, which use the 2.4 driver, so maybe it's just 2.5 in general?
Comment 140 Jesse Barnes 2008-11-24 15:42:13 UTC
Claudio, it sounds like your crashes are probably a separate bug from this one, please file a new bug with all the info you can collect.

As for Ugo's patch, it definitely provides an important clue here: it looks like touching the panel registers (at least the way we do) on this platform can cause bad behavior.  So I don't think the patch is perfect as-is, but it will definitely help us come up with a more complete fix.  I'm pulling down the latest docs now to see what might be the problem in this code path.

There could be a problem in the way we turn off the panel, or maybe in the way we try to turn it back on, hopefully I'll know more after reading over things.
Comment 141 Ugo Viti 2008-11-24 15:48:44 UTC
(In reply to comment #140)

> As for Ugo's patch, it definitely provides an important clue here: it looks
> like touching the panel registers (at least the way we do) on this platform can
> cause bad behavior.  So I don't think the patch is perfect as-is, but it will
> definitely help us come up with a more complete fix.  I'm pulling down the
> latest docs now to see what might be the problem in this code path.
> 
> There could be a problem in the way we turn off the panel, or maybe in the way
> we try to turn it back on, hopefully I'll know more after reading over things.

Jesse,

thank you very much in looking deeper on this bug.
Comment 142 Claudio Camacho 2008-11-24 22:19:39 UTC
Ok Jesse,

I just have to thank you for taking so much time in discovering how to fix this bug, and I will experiment with 2.6.28-rc6 + 2.5.1 in order to place a new bug for this GLX crashes.

Please, remember to ask from us anything you might need, because I feel quite useless since I don't have any knowledge that could apply in fixing this bug.

Thanks once again and good luck.
Comment 143 Jesse Barnes 2008-11-25 16:20:04 UTC
Created attachment 20587 [details] [review]
delay after panel off

On the theory that we're not waiting long enough after the panel powers off before turning it on again, this patch adds a delay after the panel off sequence.  Can someone give it a try?

It looks like the PP_DIVISOR we're using doesn't match what's in the VBIOS, so if this patch works we can try using a different value there...
Comment 144 Claudio Camacho 2008-11-25 21:51:15 UTC
Hi Jesse,

I just tried with the delay (usleep()) and it doesn't help. The LVDS takes longer to "initialize" (until the backlight is ON), however the blank screen is there.

But, obviously, the problem is with the LVDS and concretely with the LVDSPanelPower() function, and I am glad that this is getting closer and closer.

Thank you very much for your efforts.
Comment 145 Thomas 2008-11-28 16:23:18 UTC
Thanks Guys

I had this problem on my sony VGN-FW248J using Ubuntu & Fedora after finding your posts I compiled 
DRM from GIT and downloaded the xf86-video-intel-2.5.1 and added the 

if(!no) return; around line 390 and compiled. 

moved modules from /usr/local/lib/xorg/modules/drivers
to /usr/lib/xorg/modules/drivers

also had to move /usr/local/lib/libdrm_intel.* to /usr/lib/

now all seems to work. glxgears is giving me 753.566 FPS 

Thanks

Comment 146 Karsten Heiken 2008-11-29 03:45:49 UTC
(In reply to comment #143)
> Created an attachment (id=20587) [details]
> delay after panel off
> 
> On the theory that we're not waiting long enough after the panel powers off
> before turning it on again, this patch adds a delay after the panel off
> sequence.  Can someone give it a try?
> 
> It looks like the PP_DIVISOR we're using doesn't match what's in the VBIOS, so
> if this patch works we can try using a different value there...
> 

First of all: thanks for your work Jesse!

But this patch doesn't fix the bug.
I also tried to increase the value to "1500*500" - still nothing.

But i noticed the following:
When starting the X-server, the screen turns off completely. And with your patch it stays off even longer. And with my increased value - you guessed it - it's off even longer.
But after that time the panel is switched on again (the backlight gets activated), but the screen remains black.
So to me, this timeout-thing is not the problem. But I'm not really an expert in what you guys are doing there :D
Comment 147 Colin Guthrie 2008-12-02 13:13:21 UTC
Adding to CC so I can track Mdv bug: https://qa.mandriva.com/show_bug.cgi?id=45427
Comment 148 Kevin "Yeaux" Dupuy 2008-12-06 20:39:15 UTC
I'm also seeing the "gray-screen" bug, Sony Vaio VGN-FW190 w/ Intel GMA 4500MHD. Going to try and apply the fix, to see if it works.
Comment 149 jelle foks 2008-12-08 08:37:38 UTC
Jesse, 

I don't think the problem is that the panel is powered on or off to fast, but it's doing it too often. 

The panel is already on when xorg starts up, but still I saw multiple calls to i830SetLVDSPanelPower() to turn it on, off, on, off, on, etc...

The problem is probably caused by doing that at all, not by doing it too fast. Why turn it off if you're going to turn it back on in a few microseconds (milli?) anyway?

Comment 150 jelle foks 2008-12-10 20:17:24 UTC
changing summary title back ('checking for DRM' does not describe the issue better)...
Comment 151 Jesse Barnes 2008-12-17 15:51:34 UTC
Well, yes, we do power the panel up and down more than we should, but as long as we do it correctly we should be able to do it all day w/o glitches.

Also, in order to change modes, the panel generally has to be off, so we really do need to cycle it.

On GM45 chips, there's a new bit to indicate when the other panel related registers are all set up, meaning that the panel can be turned on.  We don't check it yet and that could be a problem.  The (untested, still messing with my GM45 machine) patch below tries to do that; no idea if it'll have any effect though...

diff --git a/src/i810_reg.h b/src/i810_reg.h                                    
index e2ffba1..912f042 100644                                                   
--- a/src/i810_reg.h                                                            
+++ b/src/i810_reg.h                                                            
@@ -896,6 +896,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.      
                                                                                
 #define PP_STATUS      0x61200                                                 
 # define PP_ON                                 (1 << 31)                       
+# define PP_ASSETS_READY                       (1 << 30) /* GM45+ */           
 /**
  * Indicates that all dependencies of the panel are on:
  *
diff --git a/src/i830_lvds.c b/src/i830_lvds.c
index 239bc89..3f79b29 100644
--- a/src/i830_lvds.c
+++ b/src/i830_lvds.c
@@ -403,6 +403,16 @@ i830SetLVDSPanelPower(xf86OutputPtr output, Bool on)
            dev_priv->backlight_duty_cycle == 0)
            dev_priv->backlight_duty_cycle = dev_priv->backlight_max;

+       /*
+        * On G45+ we should wait for "asset status" before turning on the
+        * panel
+        */
+       if (IS_GM45(pI830)) {
+           do {
+               pp_status = INREG(PP_STATUS);
+           } while (!(pp_status & PP_ASSETS_READY))
+       }
+
        OUTREG(PP_CONTROL, INREG(PP_CONTROL) | POWER_TARGET_ON);
        do {
            pp_status = INREG(PP_STATUS);
Comment 152 Jesse Barnes 2008-12-17 16:38:28 UTC
Oh, asset ready is an old bit actually, but it's still worth looking at.
Comment 153 jelle foks 2008-12-17 20:44:12 UTC
That one didn't seem to work for me. I started from a fresh source, applied the patch (added the semicolon in the 'while' line), build, install, and restart xorg, and the 'clouds' effect was back. I double-checked with md5sum that I was using the intel_drv.so that I just built with that patch.

xorg did startup a little slower (black screen laster just a little longer), but the bug was still there.
Comment 154 Jesse Barnes 2008-12-18 12:38:25 UTC
Looking at the dumps again, two things stick out between the working vesa case and the broken intel case:

--- sony-panel.fail     2008-12-18 12:11:52.000000000 -0800
+++ sony-panel.vesa     2008-12-18 12:12:05.000000000 -0800
@@ -25,7 +25,7 @@
 (II):          DVOC_SRCDIM: 0x00000000
 (II):           PP_CONTROL: 0x00000001 (power target: on)
 (II):            PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
-(II):         PFIT_CONTROL: 0xa0000000
+(II):         PFIT_CONTROL: 0x20000000
 (II):      PFIT_PGM_RATIOS: 0x08000800
 (II):      PORT_HOTPLUG_EN: 0x00000120
 (II):    PORT_HOTPLUG_STAT: 0x00000000
@@ -76,7 +76,7 @@
 (II):    VCLK_DIVISOR_VGA0: 0x00031108
 (II):    VCLK_DIVISOR_VGA1: 0x00031406
 (II):        VCLK_POST_DIV: 0x00020002
-(II):             VGACNTRL: 0x22c4008e (enabled)
+(II):             VGACNTRL: 0xa2c4008e (disabled)
 (II):               TV_CTL: 0x00000010
 (II):               TV_DAC: 0x70000000
 (II):             TV_CSC_Y: 0x00000000

So both the VGA plane and panel fitting are enabled.  Neither should be in this case, so that's one bug.

Jelle, can you capture dumps both with and w/o your patch?  Since some registers should be locked with your patch applied we can see what else might be changing...
Comment 155 jelle foks 2008-12-18 20:46:57 UTC
Ok, the dump without my patch is the attachment id=20225 that I added here on 2008-11-11 12:59 PST " intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), while the non-working blank screen is seen", filename intel_reg_dumper-vgn-fw140e-intel-1600-900-white.txt

I'll add the dump output of my current, working screen (with the 'if(!on)' hack) next.

Here is the diff btw:

$ diff -U0 intel_reg_dumper-vgn-fw140e-intel-1600-900-w*txt
--- intel_reg_dumper-vgn-fw140e-intel-1600-900-white.txt        2008-11-11 15:49:22.000000000 -0500
+++ intel_reg_dumper-vgn-fw140e-intel-1600-900-working_ifnotonhack.txt  2008-12-18 23:40:03.000000000 -0500
@@ -12 +12 @@                                                                                              
-(II):                SDVOC: 0x00000898 (disabled, pipe A, stall disabled, not detected)                   
+(II):                SDVOC: 0x00000018 (disabled, pipe A, stall disabled, not detected)                   
@@ -22 +22 @@                                                                                              
-(II):                 DVOC: 0x00000898 (disabled, pipe A, no stall, +hsync, +vsync)                       
+(II):                 DVOC: 0x00000018 (disabled, pipe A, no stall, +hsync, +vsync)                       
@@ -30 +30 @@                                                                                              
-(II):      PORT_HOTPLUG_EN: 0x38000120                                                                    
+(II):      PORT_HOTPLUG_EN: 0x38000020                                                                    
@@ -32,2 +32,2 @@                                                                                          
-(II):             DSPACNTR: 0x58000400 (disabled, pipe A)                                                 
-(II):           DSPASTRIDE: 0x00001a00 (6656 bytes)                                                       
+(II):             DSPACNTR: 0x00000000 (disabled, pipe A)                                                 
+(II):           DSPASTRIDE: 0x00000000 (0 bytes)                                                          
@@ -37 +37 @@                                                                                              
-(II):             DSPASURF: 0x00100000                                                                    
+(II):             DSPASURF: 0x00000000                                                                    
@@ -41,2 +41,2 @@                                                                                          
-(II):            PIPEASTAT: 0x00020206 (status: VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS)
-(II):                 FPA0: 0x00021108 (n = 2, m1 = 17, m2 = 8)                                                         
+(II):            PIPEASTAT: 0x00020000 (status: VBLANK_INT_ENABLE)                                                      
+(II):                 FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)                                                         
@@ -44,8 +44,8 @@                                                                                                        
-(II):               DPLL_A: 0x14800000 (disabled, non-dvo, default clock, DAC/serial mode, p1 = 8, p2 = 10)             
-(II):            DPLL_A_MD: 0x00000000                                                                                  
-(II):             HTOTAL_A: 0x033f027f (640 active, 832 total)                                                          
-(II):             HBLANK_A: 0x033f027f (640 start, 832 end)
-(II):              HSYNC_A: 0x02bf0297 (664 start, 704 end)
-(II):             VTOTAL_A: 0x020701df (480 active, 520 total)
-(II):             VBLANK_A: 0x020701df (480 start, 520 end)
-(II):              VSYNC_A: 0x01ea01e8 (489 start, 491 end)
+(II):               DPLL_A: 0x04020c00 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 2, p2 = 10)
+(II):            DPLL_A_MD: 0x00000003
+(II):             HTOTAL_A: 0x031f027f (640 active, 800 total)
+(II):             HBLANK_A: 0x03170287 (648 start, 792 end)
+(II):              HSYNC_A: 0x02ef028f (656 start, 752 end)
+(II):             VTOTAL_A: 0x020c01df (480 active, 525 total)
+(II):             VBLANK_A: 0x020401e7 (488 start, 517 end)
+(II):              VSYNC_A: 0x01eb01e9 (490 start, 492 end)
@@ -63,2 +63,2 @@
-(II):            PIPEBSTAT: 0x00020246 (status: VBLANK_INT_ENABLE VSYNC_INT_STATUS LBLC_EVENT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS)
-(II):                 FPB0: 0x00021007 (n = 2, m1 = 16, m2 = 7)
+(II):            PIPEBSTAT: 0x00020000 (status: VBLANK_INT_ENABLE)
+(II):                 FPB0: 0x00021107 (n = 2, m1 = 17, m2 = 7)
@@ -66,2 +66,2 @@
-(II):               DPLL_B: 0x98026000 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14)
-(II):            DPLL_B_MD: 0x00000000
+(II):               DPLL_B: 0x98026c00 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14)
+(II):            DPLL_B_MD: 0x00000003
@@ -69 +69 @@
-(II):             HBLANK_B: 0x0665063f (1600 start, 1638 end)
+(II):             HBLANK_B: 0x065f063f (1600 start, 1632 end)
@@ -114 +114 @@
-(II):         FBC_CFB_BASE: 0x00020000
+(II):         FBC_CFB_BASE: 0x00000000
@@ -116,2 +116,2 @@
-(II):          FBC_CONTROL: 0x20000080
-(II):          FBC_COMMAND: 0x08c80032
+(II):          FBC_CONTROL: 0x00000000
+(II):          FBC_COMMAND: 0x00000000
@@ -120 +120 @@
-(II):        FBC_FENCE_OFF: 0x4d006900
+(II):        FBC_FENCE_OFF: 0x00009200
@@ -147,4 +147,2 @@
-(II): SDVO phase shift 0 out of range -- probobly not an issue.
-(II): pipe A dot 31500 n 2 m1 17 m2 8 p1 8 p2 10
-(II): SDVO phase shift 0 out of range -- probobly not an issue.
-(II): pipe B dot 88392 n 2 m1 16 m2 7 p1 2 p2 14
+(II): pipe A dot 100800 n 3 m1 17 m2 8 p1 2 p2 10
+(II): pipe B dot 92857 n 2 m1 17 m2 7 p1 2 p2 14
Comment 156 jelle foks 2008-12-18 20:49:42 UTC
Created attachment 21291 [details]
intel_reg_dumper on working lcd with if(!on) hack

intel_reg_dumper on working lcd with if(!on) hack

note: this is after a restore from suspend to ram (which works fine btw).
Comment 157 Kevin Dodge 2008-12-19 06:20:46 UTC
Created attachment 21320 [details]
Failing log of Sony VAIO VGN-FW235 with intel driver and LVDS screen (4500MHD)

To be honest, I'm not sure what this means. I applied the previously suggested patches and compiled, and now instead of the white screen with grey blobs, the screen is shut off completely. The keyboard becomes unresponsive, and the screen won't turn back on, but I can still access the computer via SSH and, for instance, change the backlight brightness.
Comment 158 jelle foks 2008-12-19 07:38:04 UTC
I've seen a black screen once or twice too, but I don't remember the exact circumstances to trigger it. Don't know if it's the same you saw, but I've always been able to get the picture back by switching to vc1 (ctrl-alt-f1), where you see the text login prompt, then back to vc7 (alt-f7).
Comment 159 Kevin Dodge 2008-12-19 08:34:47 UTC
(In reply to comment #158)
> I've seen a black screen once or twice too, but I don't remember the exact
> circumstances to trigger it. Don't know if it's the same you saw, but I've
> always been able to get the picture back by switching to vc1 (ctrl-alt-f1),
> where you see the text login prompt, then back to vc7 (alt-f7).
> 

X itself crashes, but it never turns the screen back on so I'm basically stuck with the blank screen until I reboot. One time it magically came back on tty1 but I haven't been able to reproduce that.
Comment 160 Kevin Dodge 2008-12-19 20:01:14 UTC
(In reply to comment #159)
> (In reply to comment #158)
> > (In reply to comment #157)


Disregard all of this, after some debugging I found it was an issue with mesa. The laptop works great, 70FPS in glxgears, and I'm very grateful for the patches Jesse made. :)
Comment 161 Jesse Barnes 2008-12-20 09:09:03 UTC
So can you narrow down which patch makes things work for you?  I know Jelle's patch will work around the brokenness, but I'd like to find a fix that allows us to correctly power up/down the panel.
Comment 162 Wang Zhenyu 2008-12-28 17:51:08 UTC
Created attachment 21526 [details] [review]
Try LVDS write protect

Over 150 comments is horrible. What I can see from this problem is LVDS can't be lighten up. So here's a patch trying to turn write protect off before modesetting, and on after it. I'd like to make it a big hammer patch as so many patches flowing around here, but it might be missing Jesse's patch in comment #151. Please take a fresh driver and test with this one.
Comment 163 Wang Zhenyu 2008-12-28 17:52:32 UTC
*** Bug 17508 has been marked as a duplicate of this bug. ***
Comment 164 jelle foks 2008-12-29 00:27:42 UTC
I tried i830-lvds-write-protect-test.patch on ubuntu intrepid and it does not fix the bug (looks completely unchanged to me). PS: the first chunk got rejected by patch, because the "RestoreHWState(pScrn);" line already isn't there in that version (2.4.1).

Comment 165 jelle foks 2008-12-29 00:40:00 UTC
Created attachment 21544 [details] [review]
The only known way to work around this bug... Use: Option  "lvdshack" "True"

Since the real fix for this bug has been elusive, I hereby attach a patch for the only known way to make this driver work on this hardware. I added it as an xorg.conf option that is default off. The hack only gets activated when you add the line 

Option      "lvdshack" "True"

in the 'Device' section of your /etc/X11/xorg.conf

Perhaps the distro maintainers, for now, can temporarily include this patch in their builds, so that end users can at least use the 3d accelerated intel driver on their laptops after a relatively simple xorg.conf edit...

(patch is against xserver-xorg-video-intel-2.4.1 from Ubuntu 8.10).
Comment 166 Giovanni Pellerano 2008-12-29 00:53:30 UTC
Wang, thanks for the attempt but i've tried the patch too on the 2.5.1 and it does not work =( . I give the same black lightened screen. 
Comment 167 jelle foks 2008-12-29 00:57:26 UTC
Perhaps interesting is the difference in the Xorg.0.log with the hack disabled/enabled:

Without the hack (display 'clouds', unusable):
(II) intel(0): Comparing regs from server start up to After PreInit
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x80020206 to 0x00020206
(WW) intel(0): PIPEBSTAT before: status: FIFO_UNDERRUN VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
(WW) intel(0): PIPEBSTAT after: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
(WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to 0x4d003800
(==) Depth 24 pixmap format is 32 bpp

With the hack (display working fine):
(II) intel(0): Comparing regs from server start up to After PreInit
(WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00020206 to 0x80020206
(WW) intel(0): PIPEBSTAT before: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
(WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
(WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to 0x4d003800
(==) Depth 24 pixmap format is 32 bpp

What I found interesting is that the PIPEBSTAT before and after appear swapped... I haven't tried to find out what that means, but perhaps it rings a bell for one of you guys? Maybe it also matters that when it's working it doesn't say that PP_STATUS has changed?

Comment 168 Jesse Barnes 2008-12-29 13:25:56 UTC
(In reply to comment #167)
> Without the hack (display 'clouds', unusable):
> (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to
> 0xd000000a
> (WW) intel(0): PP_STATUS before: on, ready, sequencing idle
> (WW) intel(0): PP_STATUS after: on, ready, sequencing on
> (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x80020206 to
> 0x00020206
> (WW) intel(0): PIPEBSTAT before: status: FIFO_UNDERRUN VBLANK_INT_ENABLE
> VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
> (WW) intel(0): PIPEBSTAT after: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS
> SVBLANK_INT_STATUS VBLANK_INT_STATUS
> (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to
> 0x4d003800
> (==) Depth 24 pixmap format is 32 bpp
> 
> With the hack (display working fine):
> (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00020206 to
> 0x80020206
> (WW) intel(0): PIPEBSTAT before: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS
> SVBLANK_INT_STATUS VBLANK_INT_STATUS
> (WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VBLANK_INT_ENABLE
> VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS
> (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to
> 0x4d003800
> (==) Depth 24 pixmap format is 32 bpp
> 
> What I found interesting is that the PIPEBSTAT before and after appear
> swapped... I haven't tried to find out what that means, but perhaps it rings a
> bell for one of you guys? Maybe it also matters that when it's working it
> doesn't say that PP_STATUS has changed?

Well we'd expect PP_* to be different, since with the hack applied the panel status no longer changes at server startup time.  The PIPEBSTAT changes are a bit of a concern though; it normal operation I'd expect to see one FIFO_UNDERRUN, so this could be normal (and earlier comments indicated that the bug causing flood of "pipe b underrun" messages has been fixed), but it could also be part of the problem.  Do you still see the flood of underrun errors in your log?
Comment 169 jelle foks 2008-12-29 14:13:02 UTC
"Do you still see the flood of underrun errors in your log?"

No I don't see that, nor do I think I ever saw them.
Comment 170 Jesse Barnes 2008-12-29 16:40:03 UTC
I tried to reproduce this on my T61 (older chipset, but should still be possible since it really seems related to panel startup) but wasn't able to, even after really messing with the setpanelpower function.

However, in looking at the old i915 docs, it seems that we don't actually need to power off the panel in most cases.  There are only two cases where it's really necessary: when coming from a native VGA mode or when coming from a centered VGA mode with panel fitting enabled.  Neither of these seem to be common default configurations, so we may be able to use something like Jelle's patch, but it'll need to check for those two conditions before refusing to power off the panel.

I'd still like to understand the root cause better though too, so I'll ping the chipset guys while I spin a new patch.
Comment 171 Jesse Barnes 2008-12-30 10:24:37 UTC
Created attachment 21567 [details] [review]
avoid power cycling the panel at startup

In many cases, we don't actually have to shut down the panel.  This patch tries to avoid it the most common case: mode setting at startup.  We still need to cycle sometimes though, like when we change panel fitting status or mode timings.  This doesn't address the DPMS issue though; in that case your panel will still go off and probably not come back (still talking with the chipset guys about that).
Comment 172 jelle foks 2009-01-03 20:36:47 UTC
I tried that latest patch, Jesse. It doesn't work with that patch, but it does change the behavious a little bit. When starting X from a console vt, it now first looks a little different (more grey, some specks, and some dotted-vertical lines), then goes on to the exact same effect as without any patches.

Comment 173 Claudio Camacho 2009-01-10 14:23:38 UTC
Happy new 2009, and bad news guys!

I was quiet since I though that maybe KMS would bring some changes to this situation. I just tried 2.6.28-git14 (which already included the KMS patches) along with xf86-video-intel 2.5.1.

The situation now is ugly. The kernel boots normally (all the messages are seen on the console with my Debian), but when the display manager (slim, in my case) starts, the screen goes off, then on, but it remains blank, just like at the beginning of this bug.

I tried 2.5.1 both with the hack (if (!on) return) and without it, and the situation is the same. The X server doesn't crash, since I am able to log in, to change to the console VT and perform commands, however the screen is blank all the times, so I am afraid we have the problem even bigger now with KMS.

I attach now the dmesg and the Xorg.log.0, so you can analyze them. I hope someone knows why KMS brought this issue.
Comment 174 Claudio Camacho 2009-01-10 14:24:55 UTC
Created attachment 21873 [details]
2.6.28-git14 KMS dmesg
Comment 175 Claudio Camacho 2009-01-10 14:28:58 UTC
Created attachment 21874 [details]
2.6.28-git14 (KMS) + Xorg 7.4

By the way, I forgot to list the versions of my packages I am using for libdrm and mesa, just in case, here they are:

libdrm-intel1              2.4.3+git+20090105+a8c5480-1
libdrm2                    2.4.3+git+20090105+a8c5480-1
libgl1-mesa-dri            7.2+git20081209.a0d5c3cf-0ubuntu4
libgl1-mesa-glx            7.2+git20081209.a0d5c3cf-0ubuntu4
mesa-utils                 7.2+git20081209.a0d5c3cf-0ubuntu4
xserver-xorg               7.4~4
xserver-xorg-core          1.5.3-1
xserver-xorg-video-intel   2.5.1-1

I hope this clarifies things out.
Comment 176 Jerry L Kreps 2009-01-10 15:11:12 UTC
By the amount of guesswork being done the dev guys are obviously having trouble getting the GM45 chipsets to work.

This is supposed to be an Intel supported chipset.  Isn't Intel supplying specification details to Linux developers that explain how the display is turned on and off, and other critical details? 

Or, is this primarily a Sony problem?

http://intellinuxgraphics.org/download.html
Comment 177 Jesse Barnes 2009-01-10 15:56:07 UTC
It's definitely a driver problem, but panel power sequencing can be tricky.  Some panels are more picky than others; and in this case Sony didn't really care of Linux worked out of the box before they shipped, so they didn't do any testing, validation or bug fixing beforehand.

I'm talking with our hardware folks about how we might improve our panel power sequencing code, and we have some similar bugs open against a few other platforms (like #18342); I'm hoping they share the same root cause.  Unlike this bug though, Dell is actively involved in 18342 and have just sent me some of the problematic hardware.

But as usual, bug your platform vendor when Linux stuff doesn't work well.  They're in the best position to change their processes and make sure things work well at ship time.
Comment 178 jelle foks 2009-01-10 20:42:37 UTC
I also upgraded to ubuntu jaunty, which runs newer xorg and 2.6.28 kernel, and I did get is to work, with a similar patch as the last one I posted here ('option lvdshack').

It didn't work with libdsm 2.4.3, and xorg now crashes right after coming back from a suspend (I see the screenlock password dialog, then it crashes). So while that's also a step backwards in usability, it's not yet completely unusable ;-)... I hope they figure this out soon.

These are my package versions (the xserver-xorg-video-intel is a patched one with the 'if (!on)' hack...

$ uname -r ; dpkg -l libdrm-intel1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx mesa-utils xserver-xorg xserver-xorg-core xserver-xorg-video-intel
2.6.28-4-generic
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                       Version                    Description
+++-==========================-==========================-====================================================================
ii  libdrm-intel1              2.4.1-0ubuntu9             Userspace interface to intel-specific kernel DRM services -- runtime
ii  libdrm2                    2.4.1-0ubuntu9             Userspace interface to kernel DRM services -- runtime
ii  libgl1-mesa-dri            7.2+git20081209.a0d5c3cf-0 A free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx            7.2+git20081209.a0d5c3cf-0 A free implementation of the OpenGL API -- GLX runtime
ii  mesa-utils                 7.2+git20081209.a0d5c3cf-0 Miscellaneous Mesa GL utilities
ii  xserver-xorg               1:7.4~5ubuntu9             the X.Org X server
ii  xserver-xorg-core          2:1.5.99.3-0ubuntu4        Xorg X server - core server
ii  xserver-xorg-video-intel   2:2.5.1-1ubuntu7           X.Org X server -- Intel i8xx, i9xx display driver
Comment 179 jelle foks 2009-01-12 08:56:59 UTC
Additional note to my last posting, xorg does not crash when coming back from suspend when compositing is off, and with it on (and only then), I sometimes see the contents of (parts of) the wrong windows. So, all that may all be related to the recent graphical memory management changes.

So, in summary the 'lvdshack' still works for me with 2.6.18 and the 2.5.1 intel driver, as long as I don't use compositing, and the issues with compositing are probably not relevant for this particular bug.

Comment 180 Claudio Camacho 2009-01-12 14:32:07 UTC
Hi,

I've been reading (after my frustration) on the error I get in the Xorg.0.log with KMS enabled in 2.6.29-rc1, and I found that usually this error is due to the fact that old monitors do not support as big resolution as it is specified in the xorg.conf.

However, in this case, I have an empty xorg.conf (since I use i915), and I don't understand why this happens.

Moreover, if I disable the KMS by default, then 2.6.29-rc1 boots normally, but the Xorg is not accelerated (glxinfo | grep render, this returns Software Rasterizer), since glxgears shows 150fps and the CPU gets to 100%.

Further, if I try to run 2.6.28 with 2.5.1 using libdrm-2.4.3 + mesa 7.3rc1, any GLX application gives segmentation fault. I guess this does not belong to this bug.

The important thing here is that why KMS-enabled kernel cannot give any screen and therefore Xorg fails to show anything on the screen, and hence the VTs get blank also (since KMS makes everything graphical).

P.S.- I haven't tried 2.6.0-rc2 yet (no way to get it compiled in Debian).
Comment 181 Jesse Barnes 2009-01-12 15:22:06 UTC
Jelle and Claudio, can you guys file separate bugs for your KMS and acceleration problems?  I don't want to make this one any bigger than it already is! :)
Comment 182 Jesse Barnes 2009-01-12 16:56:42 UTC
Created attachment 21910 [details] [review]
Make sure h & vblank end come *after* h & vsync end

Can you give this a try?  Seems to fix #18342 for me.
Comment 183 Claudio Camacho 2009-01-12 23:52:43 UTC
Hi Jesse,

Thanks for that patch. My Xorg was fine anyway, but I've noticed something with the H & Vblank patch.

Only when using KDM (slim and GDM were OK), before, I got black and white stripes (I don't know if it really relates #18342, because there they say the screen was unusable, and I could use it since the stripes went away after login) before KDM was initiated.

Now with this patch, GDM and slim are still the same (everything OK) and the white stripes before KDM are gone. However, when logging in, there is a time where the screen gets black (and some dirt on the top) and then I see the desktop (maybe it has to do with the fact that I don't use KDE fully, but KDM to test the patch and then Openbox at login, I don't know).

To sum up, this patch didn't hurt my Xorg, and it got rid of the white stripes before KDM start, so the patch is functional. I tested it with 2.6.29-rc1 (KMS disabled), mesa 7.3rc1 and libdrm 2.4.3.

On what it respects to GEM+KMS, I will check a couple of things more and soon I will create a new bug report to see if this DRM problem can get fixed, sorry for mixing up here, it must be frustration :-/

Thank you once again.
Comment 184 Jesse Barnes 2009-01-13 08:51:45 UTC
(In reply to comment #183)
> Thanks for that patch. My Xorg was fine anyway, but I've noticed something with
> the H & Vblank patch.
> 
> Only when using KDM (slim and GDM were OK), before, I got black and white
> stripes (I don't know if it really relates #18342, because there they say the
> screen was unusable, and I could use it since the stripes went away after
> login) before KDM was initiated.

Claudio, thanks for testing.  Just to confirm: you applied my patch to an unmodified xf86-video-intel and the panel came up correctly?

> On what it respects to GEM+KMS, I will check a couple of things more and soon I
> will create a new bug report to see if this DRM problem can get fixed, sorry
> for mixing up here, it must be frustration :-/

No worries, thanks. :)  We like to keep issues separated to make testing & tracking easier.

Jelle, have you had a chance to check out my patch?
Comment 185 Claudio Camacho 2009-01-13 09:16:12 UTC
> Claudio, thanks for testing.  Just to confirm: you applied my patch to an
> unmodified xf86-video-intel and the panel came up correctly?

No, I applied the patch to xf86-video-intel-2.5.1 with the previous hack (if (!on) return;) from Jelle. I mean, I did the hack plus your new patch. Therefore, the panel lights up properly, but due to the old hack.
Comment 186 Claudio Camacho 2009-01-13 09:29:48 UTC
GREAT NEWS EVERYBODY!!!

(In reply to comment #185)
> > Claudio, thanks for testing.  Just to confirm: you applied my patch to an
> > unmodified xf86-video-intel and the panel came up correctly?

Actually!!! I removed the if (!on) return; hack, and it still comes up correctly. I mean, if you take an unmodified xf86-video-intel-2.5.1 and patch with your h&vblank patch, the panel comes up properly in my Vaio SR11M.

I cannot believe that this day has come! Jesse you are a genius!!

I am quite happy right now. I hope this patch is definitive and can go into 2.6.0.

Please if you read this message, tell me as soon as possible if I should test something else, so that we can clear out that it works in general for every display and hence you can enter it into the upcoming 2.6.0.

Yeeeeahhh! Thank you very very much for all the work everybody has done here! I cannot explain how happy I am just now (:

Now I'm going to test DRM stuff with KMS and put another bug report for the Mesa people (:
Comment 187 Jesse Barnes 2009-01-13 09:37:31 UTC
(In reply to comment #186)
> GREAT NEWS EVERYBODY!!!
> 
> (In reply to comment #185)
> > > Claudio, thanks for testing.  Just to confirm: you applied my patch to an
> > > unmodified xf86-video-intel and the panel came up correctly?
> 
> Actually!!! I removed the if (!on) return; hack, and it still comes up
> correctly. I mean, if you take an unmodified xf86-video-intel-2.5.1 and patch
> with your h&vblank patch, the panel comes up properly in my Vaio SR11M.
> 
> I cannot believe that this day has come! Jesse you are a genius!!

Excellent, thanks a lot for testing.

> I am quite happy right now. I hope this patch is definitive and can go into
> 2.6.0.

If it doesn't make it into 2.6.0 it'll be in 2.6.1.  But at least I know what the problem is now (having some hardware w/this problem helps :)...

> Now I'm going to test DRM stuff with KMS and put another bug report for the
> Mesa people (:

Now I have to fix the KMS stuff too :)
Comment 188 Jesse Barnes 2009-01-13 09:40:04 UTC
*** Bug 18342 has been marked as a duplicate of this bug. ***
Comment 189 jelle foks 2009-01-13 22:37:54 UTC
Confirmed. That last patch from you on a pristine 2.5.1 as included in ubuntu jaunty fixes the bug!!! (does not need the lvdshack 'if (!on)' workaround anymore).

Great work Jesse, thank you very much for your persistence!

My excuses about the late response.

About the other issues I mentioned earlier, they may simply be something just for my install, because there is something with how ubuntu/debian package the libdrm headers that don't make sense to me (https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/308387), and I needed to edit libdrm includes from the ubuntu packages to get the driver to compile, plus I really don't know how any details how libdrm, the drm.ko kernel module and this driver interact, so I could very well have done something wrong there. I can imagine there are many ways how there could be some sort of api mismatch in there somewhere...

Comment 190 Claudio Camacho 2009-01-14 23:08:06 UTC
Oops,

I noticed one problem with the last patch. Everything works properly, BUT the brightness of the display is set to its maximum every time the Xorg is restarted.

For instance, when I boot up, I always set my brightness to value 6 (ranging from 0 to 8 in this laptop) in /sys/class/backlight/acpi_video0/brightness. However, after booting, when Xorg starts, the Intel driver sets the brightness to the maximum (8).

Again, if during Xorg I change the brightness, and then restart the Xorg, the brightness is set back to the maximum.

Could you please check this issue?

Thank you in advance.
Comment 191 Claudio Camacho 2009-01-14 23:32:00 UTC
Another thing (by the way),

I am trying to compile 2.5.99.2 in Debian (I fetched the sources from experimental), but I have a versioning problem with libdrm (I think Jelle had similar problems in Ubuntu).

./configure tells me that libdrm required must be >= 2.4.3, but 2.4.1 was found.

However, in my system, I have libdrm-2.4.3, so I don't understand where is the catch:

claudio@silver:~$ dpkg -l | grep drm | awk '{print $2" "$3}'
libdrm-dev 2.4.3+git+20090105+a8c5480-1
libdrm-intel1 2.4.3+git+20090105+a8c5480-1
libdrm2 2.4.3+git+20090105+a8c5480-1

Jelle, do you have a clue? How can I tamper with things in /usr/include in order to get it built??
Comment 192 Claudio Camacho 2009-01-14 23:36:20 UTC
(In reply to comment #191)
> Another thing (by the way),
> 
> I am trying to compile 2.5.99.2 in Debian (I fetched the sources from
> experimental), but I have a versioning problem with libdrm (I think Jelle had
> similar problems in Ubuntu).
> 
> ./configure tells me that libdrm required must be >= 2.4.3, but 2.4.1 was
> found.

I actually don't know how the Debian repository could possibly build 2.5.99.2 automatically if their latest libdrm-dev package is 2.4.3 but it shows 2.4.1, the repository build should give the same error I got. I am really confused now.
Comment 193 jelle foks 2009-01-15 00:51:50 UTC
Claudio,

My LCD brightness is also at max level, however I can't change it. I had been using keyboard shortcuts for the 'Guidance Power Manager' (via the kde 'System Settings'), but they have no effect with the latest driver+kernel. My /sys/class/backlight/sys/class/backlight has no files or subdirectories in it... I don't know why that is.

I think the xserver-xorg-video-intel package in Debian and Ubuntu is probably built against the 2.6.27 kernel package, and has not been rebuilt since the introduction of 2.6.28, because there has been no trigger for it to need to happen (no new xserver-xorg-video-intel update, and no other dependency trigger has occured).

This is how I understand those packages are made in Debian and Ubuntu: Parts of the libdrm include files are added to the linux kernel source package. When that is built, besides the kernel and kernel headers, one of the .deb's you get is 'linux-libc-dev', which is the one that includes the libdrm include files. The libdrm-dev package does not supply the libdrm include files on a debian/ubuntu install.

So, when you build xserver-xorg-video-intel, the libdrm includes from linux-libc-dev need to be compatible with the libdrm that xserver-xorg-video-intel is expecting. Even though xserver-xorg-video-intel has build-dependencies on libdrm-dev and libdrm-intel1, those dependencies are not complete because the libdrm include files are not available in the libdrm-dev debian package. There is no version numbering link of any kind between libdrm and linux-libc-dev, so afaics it is not possible to specify the correct dependency in the xserver-xorg-video-intel package.

So. in debian and ubuntu, the libdrm include files are supplied by the linux-libc-dev package, which is part of the kernel source package... They end up there through manual patching by the people involved with making those packages.

What I think is that the linux-libc-dev from 2.6.27 probably _does_ have libdrm include files that allow xserver-xorg-video-intel to be built (but I did not verify that), and since there is no dependency link, the xserver-xorg-video-intel package will not break until the package is rebuilt by its maintainer after switching to 2.6.28...

I don't know why they do it like that, but that is how (it looks to me) they do it. It doesn't look like the right way to me, but it's quite possible that I simply don't know enough about the intricacies of everything involved on that subject...

Anyway, I built the xserver-xorg-video-intel that I'm using right now with linux-libc-dev (and kernel) package version 2.6.28-4.10 and the 2.4.1 version of the various libdrm packages, plus manually adding the missing struct to the one include file that I mention in the ubuntu bug ticket (that I mentioned in my previous posting). The only package that I built myself is the xserver-xorg-video-intel package, the rest are all the latest ubuntu jaunty official packages.

But, of course, the fact that it built and somewhat works (crashes after resume, and sometimes shows the wrong window content (both only if compositing is on)), that does not mean that I did it completely right... I don't know if the drm.ko, and/or libdrm library from the ubuntu packages and/or my hand-edited libdrm includes are correct for the xserver-xorg-video-intel that I built. afaics, that is because of how the libdrm includes are currently handled, it is not possible to have complete dependencies and build dependencies for the xserver-xorg-video-intel package (I had all dependencies satisfied but it still didn't build because of the linux-libc-dev and libdrm include-file intermixing...).

I just know it compiled and somewhat works... I hope the libdrm-dev and linux-kernel package maintainers of debian and ubuntu get this straightened out.

Claudio, I hope this answers your questions.
Comment 194 Tormod Volden 2009-01-15 01:03:49 UTC
> ./configure tells me that libdrm required must be >= 2.4.3, but 2.4.1 was
> found.

AFAIK configure picks up the version from /usr/lib/pkgconfig/libdrm.pc which is shipped by libdrm-dev. Maybe you have something laying around from older custom builds. The libdrm-dev package you mention contains correctly 2.4.3.
Comment 195 Tormod Volden 2009-01-15 01:11:46 UTC
BTW, I am building intel (trunk) packages on top of 2.6.28 in the Launchpad "personal package archive" https://launchpad.net/~xorg-edgers/+archive (the Jaunty packages). The source packages should also build fine on Debian (modulo needed kernel headers).
Comment 196 Claudio Camacho 2009-01-15 01:21:19 UTC
(In reply to comment #193)
> Claudio,
> 
> My LCD brightness is also at max level, however I can't change it. I had been
> using keyboard shortcuts for the 'Guidance Power Manager' (via the kde 'System
> Settings'), but they have no effect with the latest driver+kernel. My
> /sys/class/backlight/sys/class/backlight has no files or subdirectories in
> it... I don't know why that is.

The file /sys/class/backlight gets created with the following kernel options:

CONFIG_ACPI_SYSFS_POWER
CONFIG_ACPI_VIDEO
CONFIG_BACKLIGHT_LCD_SUPPORT
CONFIG_LCD_CLASS_DEVICE
CONFIG_LCD_PLATFORM
CONFIG_BACKLIGHT_GENERIC

After that, you should be able to write a number between 0 and 8 into /sys/class/backlight/acpi_video0/brightness.

With older kernels than 2.6.28, you can use /sys/class/sony-laptop/backlight/brightness (AFAIR), but ACPI does all the work already with those options I told you. The problem with the Intel driver (at least on 2.5.1) is that it resets the brightness value to 8 (maximum) every time the Xorg is (re)started.

About the explanations, thank you, you really took the time to explain everything in detail. Anyway, I don't know which version of Intel driver are you building, I was trying to build 2.5.99.2, because 2.5.1 builds without problem.

However, about the Debian versioning, I think that probably Debian people built against 2.6.26 headers. But then, I am confused again, since intel-2.6.0 needs certain definitions that are only in 2.6.29, which are not provided in the linux-libc-dev-2.6.26 (Debian). I, nevertheless, manually installed the linux-libc-dev-2.6.28 from Ubuntu but still I get problems.

I guess I have to wait a little bit more still, not everything can be fixed at once.

Thank you Jelle for being so focused on the thing :)
Comment 197 Julien Cristau 2009-01-16 00:10:45 UTC
> --- Comment #196 from Claudio Camacho <claudiomkd@gmail.com>  2009-01-15 01:21:19 PST ---
> However, about the Debian versioning, I think that probably Debian people built
> against 2.6.26 headers. But then, I am confused again, since intel-2.6.0 needs
> certain definitions that are only in 2.6.29, which are not provided in the
> linux-libc-dev-2.6.26 (Debian). I, nevertheless, manually installed the
> linux-libc-dev-2.6.28 from Ubuntu but still I get problems.
> 
ubuntu gets the drm headers from the kernel.  debian still uses those
from libdrm for now, so there's no need to update the kernel headers.
Comment 198 Claudio Camacho 2009-01-20 13:58:36 UTC
Hi Jesse,

For what is worth, the brightness is totally respected now with 2.6.0. So, using your last patch about h&vblank after h&vsync, this bug is closed.

I checked the brightness issue that I reported early but it is all gone with xf86-intel-2.6.0.

Thank you for everything, and I hope you can let us know if this patch is going to be included in 2.6.1 or, if not, in which one.
Comment 199 Jesse Barnes 2009-01-20 14:07:32 UTC
(In reply to comment #198)
> Hi Jesse,
> 
> For what is worth, the brightness is totally respected now with 2.6.0. So,
> using your last patch about h&vblank after h&vsync, this bug is closed.
> 
> I checked the brightness issue that I reported early but it is all gone with
> xf86-intel-2.6.0.
> 
> Thank you for everything, and I hope you can let us know if this patch is going
> to be included in 2.6.1 or, if not, in which one.

Thanks for testing.  Yeah I'm hoping my fix will make it into 2.6.1.  I haven't received a satisfactory answer from the Windows guys on how they deal with this, which makes me a little worried, but we can certainly add the workaround anyway and fix it up later if/when they get back to me with something useful.

I'll close this bug with a reference to the commit once I push it.
Comment 200 Jesse Barnes 2009-01-26 12:39:08 UTC
Created attachment 22255 [details] [review]
check VBT timing sanity at BIOS init time

I'd appreciate if someone could test this patch for me as it's the one I'd like to push upstream for 2.6.2.  Thanks.
Comment 201 Claudio Camacho 2009-01-26 14:04:41 UTC
Hi Jesse,

Good news! This last patch works.

Actually, because I didn't know if I had to test using the previous patch also, I tested in both ways: once using only this last patch, and another test with both patches. I have to say that both work similarly.

If you let me (I am an ignorant), I think that using only the last patch that you just uploaded, the screen goes off and then on when switching from VT to X.

With both patches applied, the screen never goes off at all, but just blank, between VT and X switch. This is, obviously, with KMS disabled, since there would be not mode change and, besides, you know that KMS still doesn't work for me.

To sum up, the patch works. So please, put it into the 2.6.2, I would like to use the Intel driver without recompiling every time ^_^

Thank you very much for everything :-)
Comment 202 Jesse Barnes 2009-01-26 15:01:53 UTC
Thanks for confirming, Claudio, and everyone for all your testing and effort in this bug.  Fix pushed as 

commit 57a02b50c60c10a25ff0f3cd93af9f37fa0d1b11
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Jan 26 14:58:28 2009 -0800

    Fixup bogus VBT modes when detected
Comment 203 Aurélien ROUGEMONT 2009-01-27 09:02:10 UTC
I have just upgraded to the latest version available on git (your latest patch was already included).

Feedback about the driver :

Good:
  - LVDS display is working perfectly fine (including suspend and so on)
  - Slightly better performance (compared to 2.4.1)

Bad:
  - Black screen occurs again when an external VGA monitor is connected
  - System freeze when a VGA screen is plugged or unplugged while X running

Linux arwen 2.6.28-5-generic #15-Ubuntu SMP Thu Jan 22 21:21:04 UTC 2009 i686 GNU/Linux

if you need any other info that i could provide, feel free to ask here !
Comment 204 Karsten Heiken 2009-01-27 09:31:35 UTC
(In reply to comment #203)

I had no chance to test this newest patch, but in response to Aurélien:
>   - System freeze when a VGA screen is plugged or unplugged while X running

Actually, that also happens when using the VESA-driver.
It also happens when the X-server is not even loaded.
At least on my Sony VAIO VGN SR19XN.
I have this problem since I bought it.
Only workaround for me: Quick jump into standby; attatch the monitor; wake up.
So I don't think, the intel-devs can change anything on this behavior.
That must be some general fuck-up from Sony.
Seems like they use to do this kind of stuff when it comes to linux-compatibility.

I'll test the patch asap.
Thanks in advance!
Comment 205 Jesse Barnes 2009-01-27 11:15:59 UTC
Ah no!  /me kills the zombie bug returning from the dead

Please file a separate bug for the VGA hotplug issue.  Sounds like Sony tries to do something smart at VGA hotplug time.  There may be a way to disable it on your platform (try the ACPI DOS settings in /proc/acpi), but really it's a separate issue from the mode timing bug here.
Comment 206 Aurélien ROUGEMONT 2009-01-27 11:20:29 UTC
(In reply to comment #205)
> Ah no!  /me kills the zombie bug returning from the dead
> 
> Please file a separate bug for the VGA hotplug issue.  Sounds like Sony tries
> to do something smart at VGA hotplug time.  There may be a way to disable it on
> your platform (try the ACPI DOS settings in /proc/acpi), but really it's a
> separate issue from the mode timing bug here.
> 

i understand about the vga "hotplug" thing, but the "can't connect my laptop to a vga monitor" is really related to this patch
Comment 207 Jesse Barnes 2009-01-27 11:41:44 UTC
Are you sure?  There's also a VGA plane patch that's been causing trouble for some people (db9f5915ce812144ffd9d2aa42e8ba856129c35e in case you want to try reverting).  Anyway, please file a separate bug describing the symptoms and include the logs, etc.  Thanks.
Comment 208 Karsten Heiken 2009-01-27 11:45:04 UTC
Created attachment 22279 [details]
Xorg.log with BO depth buffer error

Alright.
I just installed the latest git-commit.
But there was this one thing I forgot.
I can't use 2.5.0+ in general.

xorg.log says:
>>(EE) intel(0): Failed to pin depth buffer: Cannot allocate memory
>>Fatal server error:
>>Couldn't bind memory for BO depth buffer

I just attached the whole Xorg.log
I know - it's not related to this bugreport.
That's just my way to say: I would like to test the patch but I can't ;-).
Comment 209 Jesse Barnes 2009-01-27 12:06:59 UTC
(In reply to comment #208)
> Created an attachment (id=22279) [details]
> Xorg.log with BO depth buffer error
> 
> Alright.
> I just installed the latest git-commit.
> But there was this one thing I forgot.
> I can't use 2.5.0+ in general.
> 
> xorg.log says:
> >>(EE) intel(0): Failed to pin depth buffer: Cannot allocate memory
> >>Fatal server error:
> >>Couldn't bind memory for BO depth buffer

Do you already have a bug open for this problem?  If not, please file one and attach the log (kernel log too, but make them text/plain this time :).
Comment 210 Bryce Harrington 2009-01-28 01:11:57 UTC
Jesse, fwiw after putting the patch into Intrepid to get some testing for you, one regression did show up, where the display gets scrambled on an i915:

    https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/320893

He reports

"""
The difference I see in the xorg logs is this, when broken:
(EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error

instead of this, when working:
(EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x768 - internal error
"""

I can file a new bug on this if it'd be preferred.
Comment 211 Bryce Harrington 2009-01-28 01:26:10 UTC
I should add, the above was with the patch in comment #182 rather than from #200, if that matters.
Comment 212 Chris Carlin 2009-01-28 04:40:31 UTC
While I'm adding myself to the CC list I should mention that there are at least three people reporting the regression Bryce linked to. Should be enough for testing.
Comment 213 Jesse Barnes 2009-01-28 10:01:59 UTC
Can you file a new bug for it and close this one again?  Also can you try the more recent patch (the one I pushed into xf86-video-intel)?  And make double sure it's just this single patch that causes the new regression, as opposed to something else in the update.
Comment 214 Giovanni Pellerano 2009-02-02 12:43:09 UTC
Well done Jesse.

I'm using the 2.6.0, with your latest patch.

I'm using it with xorg 7.3, and libdrm 2.4.4 and kernel 2.6.29-rc3-git3

but I don't know why it does not work with kms, any assumption ? 
Comment 215 Jesse Barnes 2009-02-02 13:04:09 UTC
I still need to apply the same patch to the KMS code; until then it'll fail like the old 2D driver. :)
Comment 216 Claudio Camacho 2009-02-02 21:23:36 UTC
(In reply to comment #215)
> I still need to apply the same patch to the KMS code; until then it'll fail
> like the old 2D driver. :)
> 

Could you plesae inform us when you include the patch in the kernel, I can't wait to test KMS on my GM45 (:
Comment 217 Jesse Barnes 2009-02-03 11:55:20 UTC
Here's the equivalent KMS patch, pushing now.

diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
index 4ca82a0..f42e2ff 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -111,6 +111,12 @@ parse_panel_data(struct drm_i915_private *dev_priv, struct
        panel_fixed_mode->clock = dvo_timing->clock * 10;
        panel_fixed_mode->type = DRM_MODE_TYPE_PREFERRED;

+       /* Some VBTs have bogus h/vtotal values */
+       if (panel_fixed_mode->hsync_end > panel_fixed_mode->htotal)
+               panel_fixed_mode->htotal = panel_fixed_mode->hsync_end + 1;
+       if (panel_fixed_mode->vsync_end > panel_fixed_mode->vtotal)
+               panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end + 1;
+
        drm_mode_set_name(panel_fixed_mode);

        dev_priv->vbt_mode = panel_fixed_mode;
Comment 218 Claudio Camacho 2009-02-03 22:44:54 UTC
That's nice :)

Hoping it goes into -rc4 and I can test it on my machine.

Thank you, Jesse, for all the good work you are doing (:
Comment 219 jelle foks 2009-02-10 09:12:14 UTC
fwiw, ubuntu jaunty now has 2.6.1, but it doesn't have the "Some VBTs have bogus h/vtotal values" patch to i830_bios.c from comment #200. I got the broken display again until I added it and recompiled.
Comment 220 Giovanni Pellerano 2009-03-05 00:32:14 UTC
Great work man;

I got kms worked with intel 2.6.1 and kernel 2.6.29-rc7 but i got a strange debug message:

glxgears
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.

what does it mean? 
Comment 221 Gordon Jin 2009-03-05 00:48:34 UTC
Don't reopen an old bug just because new issue. See comment#181.
Comment 222 Kevin "Yeaux" Dupuy 2009-03-25 21:06:29 UTC
I just tested a live CD of openSUSE Factory w/ 2.6.3 and it still leaves me with a blank screen (Sony Vaio VGN-FW190). The only difference being the screen is black, not grey! I'll leave the bug as closed, but is this an issue with the patch?
Comment 223 Jerry L Kreps 2009-03-26 18:30:03 UTC
(In reply to comment #222)
> I just tested a live CD of openSUSE Factory w/ 2.6.3 and it still leaves me
> with a blank screen (Sony Vaio VGN-FW190). The only difference being the screen
> is black, not grey! I'll leave the bug as closed, but is this an issue with the
> patch?
> 

I am running a Sony VAIO VGN-FW140E/H laptop.  While running Mandriva 2009 PWP I consistently got a grey screen, not a black one.  I used VESA for several months as a workaround.  Strangly, it allowed me a slightly accelerated video.  GoogleEarth and Stellarium were jumpy, but usable.   

I was waiting for the fix to trickle down to Mandriva when I noticed that Kunbuntu 9.04 was featuring KDE 4.2, so I decided to give the LiveCD a try.  Imagine my surprise when it gave me a fully functional 3D accelerated video.  Stellarium give 67 fps and GoogleEarth is as smooth as silk!  It uses the 2.6.28-11-generic kernel and i915 video driver. 
The video chip is:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)