Created attachment 35481 [details] dmesg with debug=0x06 Information about my system: $ uname -a Linux pyttis 2.6.33-gentoo-r2 #1 SMP PREEMPT Tue May 4 09:10:05 CEST 2010 i686 Intel(R) Core(TM) Duo CPU T2350 @ 1.86GHz GenuineIntel GNU/Linux $ lspci -s 00:02 -nnvv 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller]) Subsystem: AOPEN Inc. Device [a0a0:0632] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fde80000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at ff00 [size=8] Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at fdf80000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) Subsystem: AOPEN Inc. Device [a0a0:0632] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at fdf00000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- x11-libs/libdrm-2.4.20 media-libs/mesa-7.7.1 x11-base/xorg-server-1.7.7 x11-drivers/xf86-video-intel-2.9.1 System Information Manufacturer: FUJITSU SIEMENS Product Name: ESPRIMO Q5010 Base Board Information Manufacturer: AOpen Product Name: D2544-B1 The connectors on the systen are 1 DVI and 1 S-Video I am running Gentoo, but I can reproduce this just by booting a Fedora13-beta liveusb or a Ubuntu 10.04 liveusb and watch the corruption on the TV as the system boots. I have a computer which I only use to provide contents to a TV. It is only connected to that old TV trough S-Video. The IGP is a 945GM. It currently runs kernel 2.6.32.2 and xf86-video-intel-2.9.1 and xorg-server-1.7.6 I have tried with kernels from linus git tree (up to at least 2.6.34-rc6), with and without drm-intel-next merged on top, and with newer xf86-video-intel (both 2.10 and 2.11). When I start my computer using KMS, both before and when X has started I see the picture on my TV "jumping" horizontally. I can only reproduce it with KMS and it seems dependent on the workload of the computer, as preventing X from start when I boot (leaving you with an almost stable console), ssh into the box and start for example compiling a kernel you will notice the console jumping faster and faster as the computer starts to work harder, and almost stops again when the compilation ends. However if I created a new mode with a much higher Mhz, say instead of: 640x480 (0x44) 11.3MHz +preferred h: width 640 start 641 end 704 total 736 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz I use: mine (0x106) 25.0MHz *current h: width 640 start 641 end 704 total 736 skew 0 clock 34.0KHz v: height 480 start 481 end 512 total 513 clock 66.2Hz The picture becomes stable. As I do not know how and why this hits me I turn to you for help on how to debug this further and maybe fix it.
Created attachment 35482 [details] output from xrandr --verbose of a clean (no xorg.conf) X, no other X programs
Created attachment 35483 [details] output from intel reg dumper If there is anything more I can provide, please feel free to ask for it.
This day I tried out TV-out on an Acer TravelMate 5310, smolt-profile: http://www.smolts.org/client/show/pub_3e4e08ab-39e6-44c3-8771-1aa97500b7b7 and this did not work on that machine either. How to reproduce: 1. Install a clean Fedora13 on you machine or run a Fedora13 LiveCD/LiveUSB 2. connect a TV to an S-video out on you computer 3. run xrandr --output TV1 --auto 4. do anything (opening and closing a gnome-menu, run glxgears, as long as the picture out is a static picture the corruption is minimal) 5. watch the TV and watch the corruption Changing clocks fixed the problems, however as I do not know what values the clock is supposed to have I am afraid to fry something, so I do not even consider that as a workaround until someone tells me otherwise.
The registers look consistent with the modelines, so I am guessing it's a case of garbage-in, garbage-out. Peter, do you still have 2.9.1+ums paths available to compare and contrast, in particular the xrandr verbose output and intel_reg_dumper?
Created attachment 37266 [details] xrandr-verbose-kms All following are from the same system, a Gentoo machine running xorg-server-1.7.7, xf86-video-intel-2.9.1 and a 2.6.34-kernel: on the kernelcmd: i915.modeset=0 vga=0x314 video=640x480 # cat /etc/X11/xorg.conf Section "Monitor" Identifier "TV" Option "PreferredMode" "640x480" Option "TV_Connector" "S-video" EndSection Section "Device" Identifier "GFX" Driver "intel" Option "monitor-TV1" "TV" EndSection Only differences between runs where if I had modeset=1 or modeset=0 on the kernelcmd
Created attachment 37267 [details] xrandr-verbose-ums $ diff -u xrandr-verbose-kms xrandr-verbose-ums --- xrandr-verbose-kms 2010-07-21 18:35:51.816451592 +0200 +++ xrandr-verbose-ums 2010-07-21 18:35:51.817451698 +0200 @@ -1,7 +1,7 @@ -Screen 0: minimum 320 x 200, current 640 x 480, maximum 4096 x 4096 -VGA1 disconnected (normal left inverted right x axis y axis) +Screen 0: minimum 320 x 200, current 640 x 480, maximum 2048 x 2048 +VGA disconnected (normal left inverted right x axis y axis) Identifier: 0x41 - Timestamp: 83614 + Timestamp: 39086 Subpixel: unknown Clones: CRTCs: 0 1 @@ -9,9 +9,9 @@ 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: -DVI1 disconnected (normal left inverted right x axis y axis) +TMDS-1 disconnected (normal left inverted right x axis y axis) Identifier: 0x42 - Timestamp: 83614 + Timestamp: 39086 Subpixel: horizontal rgb Clones: CRTCs: 0 1 @@ -19,9 +19,9 @@ 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: -TV1 connected 640x480+0+0 (0x44) normal (normal left inverted right x axis y axis) 0mm x 0mm +TV connected 640x480+0+0 (0x44) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x43 - Timestamp: 83614 + Timestamp: 39086 Subpixel: unknown Clones: CRTC: 0 @@ -30,24 +30,26 @@ 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: - bottom margin: 37 (0x00000025) range: (0,100) - right margin: 46 (0x0000002e) range: (0,100) - top margin: 36 (0x00000024) range: (0,100) - left margin: 54 (0x00000036) range: (0,100) - mode: NTSC-M + HUE: -1221836800 (0xb72c4000) range: (0,255) + SATURATION: -1221836704 (0xb72c4060) range: (0,255) + CONTRAST: -1221836704 (0xb72c4060) range: (0,255) + BRIGHTNESS: -1221836672 (0xb72c4080) range: (0,255) + BOTTOM: 37 (0x00000025) range: (0,100) + RIGHT: 46 (0x0000002e) range: (0,100) + TOP: 36 (0x00000024) range: (0,100) + LEFT: 54 (0x00000036) range: (0,100) + TV_FORMAT: NTSC-M supported: NTSC-M NTSC-443 NTSC-J PAL-M - PAL-N PAL 480p@59.94Hz 480p@60Hz - 576p 720p@60Hz 720p@59.94Hz 720p@50Hz - 1080i@50Hz 1080i@60Hz 1080i@59.94H + PAL-N PAL 640x480 (0x44) 11.3MHz *current +preferred h: width 640 start 641 end 704 total 736 skew 0 clock 15.4KHz v: height 480 start 481 end 512 total 513 clock 30.0Hz - 848x480 (0x45) 14.5MHz +preferred - h: width 848 start 849 end 912 total 944 skew 0 clock 15.4KHz - v: height 480 start 481 end 512 total 513 clock 30.0Hz - 1024x768 (0x46) 26.9MHz + 1024x768 (0x45) 26.9MHz h: width 1024 start 1025 end 1088 total 1120 skew 0 clock 24.0KHz v: height 768 start 769 end 800 total 801 clock 30.0Hz - 800x600 (0x47) 17.0MHz + 800x600 (0x46) 17.0MHz h: width 800 start 801 end 864 total 896 skew 0 clock 19.0KHz v: height 600 start 601 end 632 total 633 clock 30.0Hz + 848x480 (0x47) 14.5MHz + h: width 848 start 849 end 912 total 944 skew 0 clock 15.4KHz + v: height 480 start 481 end 512 total 513 clock 30.0Hz
Created attachment 37268 [details] diff -u intel_reg_dumper-kms intel_reg_dumper-ums > intel_reg_dumper-diff This is a diff between intel_reg_dumper for kms vs. ums, the files themselves where to big to attach. If you want me to attach them zipped just tell me.
(In reply to comment #7) > Created an attachment (id=37268) [details] > diff -u intel_reg_dumper-kms intel_reg_dumper-ums > intel_reg_dumper-diff Looks more like a intel_gpu_dump output, can you double check. From the xrandr output it appears that the modelines are the same so we have not regressed in parsing the EDID. So presumably we are programming the output differently and now incompatibly with your display.
Created attachment 37269 [details] intel_reg_dumper-diff I was certain I used intel_reg_dumper, but seems I was wrong for some reason... Here is the correct diff, if you want the full files I ca attach them too.
Just to check, you used two different modes right? 800x600 in the first dump and 640x480 in the second? And the dual output was disabled in the second run. The only other thing of real significance is that FrameBuffer Compression is only enabled in the second pass, that is for ums and not for kms. Weird. Peter, can you confirm the sequence of ums vs kms and check that you are capturing the registers for the troublesome modes? Thanks.
Created attachment 37275 [details] xrandr-verbose-kms My brain apparently does not work well when I am too warm, here I had attached the wrong file, but the diff in my comment above still stands. In both tests I dumped while running X in 640x480 (as far as I know, and xrandr confirms it, defined in kernelcmd and xorg.conf as stated above). In a clean X glxgears rolls clearly during kms but not during ums with this resolution. The test system itself does only have one output currently, one S-Video cable. Nothing connected to the DVI port and no other connector/screen. No dual output at all, and according to xrandr everything but TV is disconnected in both cases. fbcompression may come from vesafb being used with ums, but not with kms?
Ok, read you comment again, realized some stuff and took some other tests: (In reply to comment #10) > Just to check, you used two different modes right? 800x600 in the first dump > and 640x480 in the second? And the dual output was disabled in the second run. > Both are running X in 640x480. The 800x600 seems to come from vga=0x314. If I change that to 0x311 that part of the output from intel_reg_dumper for kms changes too 640x480 too. No dual displays any of the runs, only a S-video TV connected to the computer. > Peter, can you confirm the sequence of ums vs kms and check that you are > capturing the registers for the troublesome modes? Thanks. It is the right sequence, the one I named kms seems to show kms, and the one named ums seems to show ums (ran intel_reg_dumper again and confirmed the output).
Ah, the TV out swapped pipes between kms and ums, that was confusing me. So the PLL timings for kms are: FPA0: 0x00020e08 (n = 2, m1 = 14, m2 = 8) and for ums: FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8) which says that we were allocating more lanes and more bandwidth to drive the TV under ums than now under kms. That correlates well with the observation that increasing the pixel clock improves the output. As a test do you mind grabbing an intel_reg_dumper with the forced mode? If I am on the right track, we should see a similar change in FPA0.
Actually no. I had to change machine and distribution because for some reason xrandr --addmode did not add the mode on the Gentoo machine. This time around it is a laptop running Fedora 13. Same chipset, same problem. I did four testes with LVDS1 turned off on that machine so only TV1 was active. I did about four test and evey time the output from intel_reg_dumper between "640x480" and "mine" (as I named my displaymode) did differ but newer ever on the same location. I also really confirmed that with "640x480" the screen rolled and with "mine" it became stable.
Got xrandr --newmode to work on the Gentoo machine. Same result there. Every time I change the clock the picture goes stable, but the differences in the output from intel_reg_dumper is random.
Looked at the Gentoo dumps ad they where less random then the Fedora13 ones. These are not clean X sessions (having only xbmc running), if you want dumps with clean X I can create those later today. In between the dumps where done, nothing was changed except shifting between 640x480 and "mine" (which I called my mode with the doubled Mhz). the one with 640 in the name is the original mode, these with "mine" in the name is the working ones. pyttis ~ # diff -u regs-640-2 regs-mine-2 --- regs-640-2 2010-07-22 13:37:44.548133195 +0200 +++ regs-mine-2 2010-07-22 13:37:37.852291496 +0200 @@ -3,8 +3,8 @@ EXCC: 0x00000000 HWS_PGA: 0x370d6000 IPEIR: 0x00000000 - IPEHR: 0x01800002 - INST_DONE: 0x7fffffc1 + IPEHR: 0x7d880000 + INST_DONE: 0x7f800081 NOPID: 0x00000000 HWSTAM: 0xfffceffe SCPD0: 0x00000000 @@ -74,7 +74,7 @@ DSPATILEOFF: 0x00000000 PIPEACONF: 0x80000000 (enabled, single-wide) PIPEASRC: 0x027f01df (640, 480) - PIPEASTAT: 0x00000100 (status: DLINE_COMPARE_STATUS) + PIPEASTAT: 0x00000000 (status:) PIPEA_GMCH_DATA_M: 0x00000000 PIPEA_GMCH_DATA_N: 0x00000000 PIPEA_DP_LINK_M: 0x00000000 pyttis ~ # diff -u regs-640-3 regs-mine-3 --- regs-640-3 2010-07-22 13:39:11.904792973 +0200 +++ regs-mine-3 2010-07-22 13:39:05.141438457 +0200 @@ -3,8 +3,8 @@ EXCC: 0x00000000 HWS_PGA: 0x370d6000 IPEIR: 0x00000000 - IPEHR: 0x01800002 - INST_DONE: 0x7fffffc1 + IPEHR: 0x7f80000c + INST_DONE: 0x7f000081 NOPID: 0x00000000 HWSTAM: 0xfffceffe SCPD0: 0x00000000 @@ -74,7 +74,7 @@ DSPATILEOFF: 0x00000000 PIPEACONF: 0x80000000 (enabled, single-wide) PIPEASRC: 0x027f01df (640, 480) - PIPEASTAT: 0x00000100 (status: DLINE_COMPARE_STATUS) + PIPEASTAT: 0x00000000 (status:) PIPEA_GMCH_DATA_M: 0x00000000 PIPEA_GMCH_DATA_N: 0x00000000 PIPEA_DP_LINK_M: 0x00000000
See also bug 23899.
Please retest with at least v3.3-rc4 kernel (or newer). That one contains fixes for the TV-out timings and clocks.
Reporter seems to have disappeared and the bug is presumably fixed by the TV clock fixes in 3.3. Closing, please reopen if this is not the case.
(In reply to comment #19) > Reporter seems to have disappeared and the bug is presumably fixed by the TV > clock fixes in 3.3. Closing, please reopen if this is not the case. Yeah, sorry about that. RL got me again. I had to repurpose that machine, since it became too much work getting things working. So I currently have no easy access to a machine with which I can test this. If I get the chance to test this I will report back then.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.