Created attachment 26497 [details] full Xorg.0.log Copied from the Mandriva-Bug with a little bit more version details In case you need other info, please ask. Description of problem: Trying to switch the TV_FORMAT for the S-Video connector from the default NTSC-M to PAL instantly crashes the X-Server Version-Release number of selected component (if applicable): Mandriva 2009.1 with current updates x11-driver-video-intel-2.7.1 X.Org X Server 1.6.1 Release Date: 2009-4-14 libdrm 2.4.11 How reproducible: always Steps to Reproduce: 1. Boot to X 2. "xrandr --verbose" → notice TV_FORMAT is set to NTSC-M 3. use "xrandr --output TV --set TV_FORMAT PAL" → X crashes/restarts The only way to switch to PAL is to connect to a TV, enable TV-output in NTSC mode, and then switch to PAL - despite that workaround still major severity, since already caused data-loss for me and it is easy to forget to stick to the sequence to not have it crash Details: $ lspcidrake -v |grep -i Graphics unknown : Intel Corporation|Mobile GM965/GL960 Integrated Graphics Controller [DISPLAY_OTHER] (vendor:8086 device:2a03 subv:1734 subd:110f) Card:Intel 810 and later: Intel Corporation|Mobile GM965/GL960 Integrated Graphics Controller [DISPLAY_VGA] (vendor:8086 device:2a02 subv:1734 subd:110f) In /var/log/messages: Jun 6 18:35:49 esprimo klogd: [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 In /var/log/Xorg.0.log: Backtrace: 0: /etc/X11/X(xorg_backtrace+0x37) [0x8136207] 1: /etc/X11/X(xf86SigHandler+0x56) [0x80d1fd6] 2: [0xffffe400] 3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7a08538] 4: /etc/X11/X(RRChangeOutputProperty+0x294) [0x816c6a4] 5: /etc/X11/X(ProcRRChangeOutputProperty+0x1a5) [0x816c965] 6: /etc/X11/X [0x8164f13] 7: /etc/X11/X(Dispatch+0x34f) [0x808971f] 8: /etc/X11/X(main+0x39d) [0x806d2fd] 9: /lib/i686/libc.so.6(__libc_start_main+0xe5) [0xb7bd56a5] 10: /etc/X11/X [0x806c7d1] Fatal server error: Caught signal 11. Server aborting
Haien, can you reproduce this?
Hi Christian, I use s-video connector and change tv format from NTSC-M to PAL, but the system work normally, so could you please update your driver from our master tree? Thanks Ma Ling
Christian, FYI there is a recent git master package for mdv available via http://kenobi.mandriva.com/~colin/intel-2009.1/ That may make it easier for you to test :)
I'll test with the test-package, but just to make sure: The crash occurs when the TV is /not/ already connected. When it is connected/displaying via NTSC-M, I can switch to PAL without a crash as well (the workaround mentioned in the initial description).
(In reply to comment #1) > Haien, can you reproduce this? > I just test 915gm and switching TV_FORMAT works well with our Q2-rc1: Libdrm: (master)3d4bfe8c893d016ef43d1ebf28e4607aa1f540a4 Mesa: (mesa_7_5_branch)cfff2a6189b38f1ee8c8ca204e223574a5abf760 Xserver: (server-1.6-branch)5cd5a01259ba349f1868ca4af04207cf120d69e4 Xf86_video_intel: (master)66ceedc0cc123e5c9f85f708b2e56d943f00e4b9 Kernel: (for-linus)0e7ddf7eeeef5aea85412120539ab5369577faeb
(In reply to comment #4) > I'll test with the test-package, but just to make sure: > The crash occurs when the TV is /not/ already connected. > When it is connected/displaying via NTSC-M, I can switch to PAL without a crash > as well (the workaround mentioned in the initial description). Yeah !, I run into the issue, I will fix it. Thanks Ma Ling
I have found the root cause, I will paste patch ASAP. Thanks Ma Ling
Created attachment 26846 [details] please try the debug patch on your machine, thanks
(In reply to comment #8) > Created an attachment (id=26846) [details] > please try the debug patch on your machine, thanks The patch only try to resolve crash issue when no outputs are available, doesn't fix your issue. So with the patch X server still will stop, could you please upload your log file with modedebug option on. Thanks Ma Ling
@Colin: could you provide a rpm with the patch for me? Otherwise not sure whether the modedeubg log without the patch will help as well, but will attach it nevertheless.
Created attachment 26870 [details] log with modedebug - crash when not connected to TV when setting TV_FORMAT to PAL
Created attachment 26871 [details] log with modedebug - crash when TV is cconnected when attempting to set TV_FORMAT to PAL
it is hard for us to provide rpm, could you please download our latest driver from http://xorg.freedesktop.org/archive/individual/driver/, with the patch in comments #8, and then upload your xorg log file with modedebug option on. Thanks for your help. Ma Ling
(In reply to comment #13) > it is hard for us to provide rpm, could you please download our latest driver > from http://xorg.freedesktop.org/archive/individual/driver/, with the patch in > comments #8, and then upload your xorg log file with modedebug option on. The comment about a package was aimed at me :) I've just not had a chance to put this together yet. I'll try and get it done on Sunday, but not 100% sure yet I'll have time.
(In reply to comment #14) > (In reply to comment #13) > > it is hard for us to provide rpm, could you please download our latest driver > > from http://xorg.freedesktop.org/archive/individual/driver/, with the patch in > > comments #8, and then upload your xorg log file with modedebug option on. > The comment about a package was aimed at me :) > I've just not had a chance to put this together yet. I'll try and get it done > on Sunday, but not 100% sure yet I'll have time. ping & thanks for your help :)
(In reply to comment #15) > ping & thanks for your help :) Sorry, I didn't get a chance to do anything this w/e so no packages for our test user. I'll try and find time tonight :)
(In reply to comment #16) > (In reply to comment #15) > > ping & thanks for your help :) > Sorry, I didn't get a chance to do anything this w/e so no packages for our > test user. I'll try and find time tonight :) ping ~
Since no response from Colin :-/ I did bite the bullet and setup a build-environment and compiled myself. Although with no success at all- means: The behaviour is unchanged, X still crashes when setting the TV_FORMAT to PAL - both when the cable is connected, as well as prior to connecting the cable (see logs). Still the only way to use pal is to enable the display using NTSC and then switch to PAL while it displaying with NTSC.
Created attachment 27345 [details] modedebug log when switching to PAL with no cable connected (2.7.99.901 + patch)
Created attachment 27347 [details] modedebug log with cable connected when switching to PAL (2.7.99.901 + patch)
ok, let me clarify the issue here: this issue have two root causes: 1. our current code doesn't support PAL mode 2. when no mode available, xserver crash from NULL pointer cause 1, it is duplicate with bugs #21533 cause 2, the patch in comments #8 will resolve it. Thanks Ma Ling
Sorry, but I don't get your comment. The driver supports PAL. I can switch and use pal after I enabled TV output in the default NTSC mode. Switching to pal or not makes a big difference in display quality on my TV. So why "1. our current code doesn't support PAL mode"? From my understanding, it /does/ support it. The problem is I cannot switch to PAL mode before activating the display via TV-output. (well, not being able to switch before would not be a big deal, the real problem is that when I try to do it, X crashes) And 2: when no mode available, xserver crash from NULL pointer Is /not/ solved with the patch from this issue (or I'm completely misunderstanding). No matter whether there is a cable connected from the notebook to the tv, or whether there is a cable between the two, it still crashes X. And when the cable is connected, it /has/ modes available. See the cableconnected log. When connecting the cable it uses NTSC-Modes and prints them to the log: (II) intel(0): EDID for output TMDS-1 (II) intel(0): Mode for pipe A: (II) intel(0): Modeline "NTSC 480i"x0.0 107.52 1280 1368 1496 1712 1024 1027 1034 1104 (62.8 kHz) (II) intel(0): Adjusted mode for pipe A: (II) intel(0): Modeline "NTSC 480i"x0.0 108.00 1280 1368 1496 1712 1024 1027 1034 1104 (63.1 kHz) (II) intel(0): chosen: dotclock 108000 vco 2160000 ((m 90, m1 14, m2 8), n 2, (p 20, p1 2, p2 10)) [...] (II) intel(0): Detected S-Video TV connection [...] (II) intel(0): Printing probed modes for output TV (II) intel(0): Modeline "1024x768"x30.0 26.89 1024 1025 1088 1120 768 769 800 801 (24.0 kHz) (II) intel(0): Modeline "800x600"x30.0 17.00 800 801 864 896 600 601 632 633 (19.0 kHz) (II) intel(0): Modeline "848x480"x30.0 14.51 848 849 912 944 480 481 512 513 (15.4 kHz) (II) intel(0): Modeline "640x480"x30.0 11.31 640 641 704 736 480 481 512 513 (15.4 kHz) [...] And when requesting switch to pal, right before the crash it prints the pal modes: (II) intel(0): Printing probed modes for output TV (II) intel(0): Modeline "1024x768"x25.0 22.43 1024 1025 1088 1120 768 769 800 801 (20.0 kHz) (II) intel(0): Modeline "800x600"x25.0 14.18 800 801 864 896 600 601 632 633 (15.8 kHz) (II) intel(0): Modeline "848x480"x25.0 12.11 848 849 912 944 480 481 512 513 (12.8 kHz) (II) intel(0): Modeline "640x480"x25.0 9.44 640 641 704 736 480 481 512 513 (12.8 kHz) So I absolutely don't understand your last comment.
Christian, sorry I mistake your tv as sdvo tv, but it is integrated TV ! For SDVO_TV we currently only support NTSC. the problem seem to be tv detection. After using our latest driver from master tree, integrated tv can work as expected(I have tested from NTSC to PAL, PAL- M ,PAL-N). So could you please update your driver from our master tree. Thanks Ma Ling
> the problem seem to be tv detection. I still disagree. It crashes without a TV connected in the first place, so the driver cannot detect what is not there. And when the cable is connected, it did detect the S-Video connection. (I'm already using the latest released tarball, and the changes since then don't look to me as related with the issue) If you could provide a tarball of the current master (or Colin a built rpm), I'll check, but honestly I doubt that the crash is fixed. Again the problem CRASHES on switching to PAL from the default NTSC when: * no TV connected at all, i.e. no cable between notebook and TV * Connected to TV, but display via TV not activated yet No crash/WORKING PAL output when: * TV is connected and already displaying using NTSC
(In reply to comment #24) > > the problem seem to be tv detection. > > I still disagree. It crashes without a TV connected in the first place, so the > driver cannot detect what is not there. And when the cable is connected, it did > detect the S-Video connection. > > (I'm already using the latest released tarball, and the changes since then > don't look to me as related with the issue) > > If you could provide a tarball of the current master (or Colin a built rpm), > I'll check, but honestly I doubt that the crash is fixed. > > Again the problem > CRASHES on switching to PAL from the default NTSC when: > * no TV connected at all, i.e. no cable between notebook and TV Christian, when on TV connected, you should no be able to see any modeline or tv format in xrandr, and xrandr should just tell you it's "disconnected". could you please confirm this? Would you please attach a xrandr output here? > * Connected to TV, but display via TV not activated yet Not sure about what do you mean of "TV not activated". If you have TV connected before boot, it should automatically be light up by xserver after system up, isn't it? did you disable it in xorg.conf or something? And, I didn't find what's your machine's model in the bug report. Would you please tell us as well? thanks. > > No crash/WORKING PAL output when: > * TV is connected and already displaying using NTSC >
> Christian, when on TV connected, you should no be able to see any modeline > or tv format in xrandr, and xrandr should just tell you it's "disconnected". Yes. verbose output will be attached, here regular output: $ xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096 VGA disconnected (normal left inverted right x axis y axis) LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm 1280x800 59.8*+ 1024x768 85.0 75.0 70.1 60.0 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 TMDS-1 disconnected (normal left inverted right x axis y axis) TV disconnected (normal left inverted right x axis y axis) >> * Connected to TV, but display via TV not activated yet > > Not sure about what do you mean of "TV not activated". Just that: Cable is connecting the notebook and the TV, but nothing is displayed on TV yet, no signal is sent to the TV (--output TV --off) > If you have TV connected before boot, Not sure why you think I have it connected at boot. No, it is not connected while booting. I boot with no cable plugged in. But doesn't matter IMHO, since when I plug in the cable, xrandr/X notice the TV: (again verbose output will be attached) $ xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096 VGA disconnected (normal left inverted right x axis y axis) LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm 1280x800 59.8*+ 1024x768 85.0 75.0 70.1 60.0 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 TMDS-1 disconnected (normal left inverted right x axis y axis) TV connected (normal left inverted right x axis y axis) 1024x768 30.0 800x600 30.0 848x480 30.0 640x480 30.0 As you can tell already from the refresh-rate: it defaults to NTSC. If I now try to switch to PAL with $ xrandr --output TV --set TV_FORMAT PAL it crashes (I originally wanted to set TV_FORMAT, overscan and activate it at the same time: xrandr --output TV --set LEFT 20 --set RIGHT 20 --set BOTTOM 15 --set TOP 20 --set TV_FORMAT PAL --mode 1024x768, but as trying to switch TV_FORMAT is enough to trigger the crash, just focus on that now) When I instead activate output with the default NTSC mode with $ xrandr --output TV --mode 1024x768 (It then sends NTSC signal to the TV = "activated" output) I can switch to PAL (and set overscan borders) $ xrandr --output TV --set TV_FORMAT PAL (no crash, and signal sent to TV is PAL) > And, I didn't find what's your machine's model in the bug report. It is a Fujitsu Siemens Esprimo Mobile U9200
Created attachment 27468 [details] xrandr --verbose output, prior to connecting TV and notebook
Created attachment 27469 [details] xrandr --verbose output after connecting TV and notebook with S-Video cable
As expected, the current release-tarball (...902) didn't solve the problem. I fear that now this issue is on the blue-sky pile (i.e. not making any progress anymore since apparently you cannot reproduce yourself). If I can do anything to drive this issue, please let me know.
(In reply to comment #29) > As expected, the current release-tarball (...902) didn't solve the problem. > > I fear that now this issue is on the blue-sky pile (i.e. not making any > progress anymore since apparently you cannot reproduce yourself). If I can do > anything to drive this issue, please let me know. > actually we can reproduce now with your detailed description. Ling should be able to provide the patch soon. :) thanks.
Created attachment 27933 [details] [review] pleaset try the patch on your machine in UMS mode, thanks. The root cause is output crtc is not available before crtc is assigned to tv output. In this patch we append one condtion to avoid system crash, so we should use "xrandr --output TV --mode xxx or xrandr --output TV --auto" to assigne one crtc to TV before deal with it. Thanks Ma Ling
I'm a little confused, and was waiting for some additional file. All that the attached patch does is to add a log-message. And as such it doesn't solve the problem unfortunately. The message "(EE) intel(0): Set TV Format Property error CRTC is not available" is printed to the log, but that's the only difference.
(In reply to comment #32) > I'm a little confused, and was waiting for some additional file. > All that the attached patch does is to add a log-message. > And as such it doesn't solve the problem unfortunately. > The message "(EE) intel(0): Set TV Format Property error CRTC is not available" > is printed to the log, but that's the only difference. hi Christian The root cause is user should not set tv property before assigning real crtc to output. So After plugging TV cable, please use "xrandr --output TV --auto " or "xrandr --output TV --mode xxx" command to make TV light up(essentially assigned crtc to output) before setting TV format. Thanks Ma Ling
I disagree, after all that setting is a xorg.conf option and I'm sure X is still meant to start even without a TV output enabled, even without a TV connected at all. But anyway, even with this artificial limitation a wrong sequence should not cause X to crash. A error-message in the log doesn't prevent the crash, and is not really helpful to the user. But what I really don't understand is why connecting the TV (only via cable, not yet activating the output) is not enough. Xrandr/X then see the s-video connection, list modes. But well, when it wouldn't crash anymore, I can live with the workaround.
(In reply to comment #34) > But well, when it wouldn't crash anymore, I can live > with the workaround. > so do you still see crashing with ling's patch in comment# 31?
Sorry for being unclear on this. Yes, it still crashes with the patch from comment #31 It still crashes when no cable plugged in, and it also still crashes when a cable is plugged in. So apart from the new line in the log, there's no difference.
Created attachment 28133 [details] pleaset try the patch on your machine in UMS mode, thanks. Sorry, this patch will return false if we set property before enable TV
Created attachment 28136 [details] pleaset try the patch on your machine in UMS mode, thanks. When TV is not connected and X start, after plugging TV cable again, system will crash because output crtc is NULL. This patch will return, do not handle crtc immediately, meanwhile set value will be effective until user really enable output by xrandr command.i.e xrandr --output TV --auto or xrandr --otuput TV --mode xxx. thanks Ma Ling
Thanks a lot :-) with the current patch it doesn't crash anymore, (and I can switch TV on, set to PAL and set borders all at the same time which was what I actually wanted to do). The only tiny problem that is left is that xrandr --verbose still lists the TV_FORMAT as NTSC after switching to PAL (but the frequencies/modelines are the PAL ones), it only switches when actually activating the output. To illustrate: 0) boot, no TV connected xrandr --verbose lists TV_FROMAT: NTSC-M 1a) xrandr --output TV --set TV_FORMAT PAL no crash - hooray :-) xrandr --verbose still lists TV_FORMAT: NTSC-M 2a) connect TV with cable xrandr --verbose still lists TV_FORMAT: NTSC-M, but the modelines are PAL ones (i.e. 25Hz vrefresh) 3) activate output xrandr --output TV --mode 1024x768 hooray, TV is displaying, and it is using PAL :-) xrandr --verbose now lists TV_FORMAT: PAL (and displays PAL-modes) 1b) connect TV with cable xrandr --verbose lists TV_FORMAT: NTSC-M and the corresponding NTSC-modes (i.e. 30Hz vrefresh) 2b) xrandr --output TV --set TV_FORMAT PAL hooray, no crash :-) xrandr --verbose lists TV_FORMAT: NTSC-M with the corresponding PAL modes (25Hz vrefresh) So I'm very happy, and the wrong display in xrandr --verbose is the only thing left (but not sure whether it is worth fixing). So feel free to resolve the issue as "FIXED" and thank you very much for the quick responses and of course for the fix.
Thanks for the test. It seems that the issue can be fixed by the patch in comment #38. I will try to push it. thanks.
Yakui, any update?
(In reply to comment #41) > Yakui, any update? There is no such issue in KMS. This only exists in UMS mode. And the Zhenyu will help us to push it. Thanks. >
sorry, really pushed out this time. commit 7ae1d0dde6cef3437b67dbc21384cb179616a6c0 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Mon Aug 31 13:51:01 2009 +0800 Skip setting tv format property if output crtc is NULL When TV is not connected and X start, after plugging TV cable again, system will crash because output crtc is NULL. This patch will return, do not handle crtc immediately, meanwhile set value will be effective until user really enable output by xrandr command. Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
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.