|Summary:||Misdetection of the TV output|
|Component:||Video(DRI - Intel)||Assignee:||Wang, Zhenyu Z (zhenyu.z.wang)|
|Severity:||normal||CC:||ajax, chris, daniel, jbarnes, meijer.o, pcjc2, riccardo.magliocchetti, rjw, tiwai, yakui.zhao, zhenyuw|
|Bug Depends on:|
dmesg output with a normal console
remove tv hotplug status check
2.6.33-rc2 dmesg output with "drm.debug=0x06"
2.6.33-rc2+revert(27dfaf4f582) dmesg output with "drm.debug=0x06"
2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a good console
24627: 2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a "bad" console
try the debug patch that uses the bios mechanism to detect TV
try the updated patch
the updated patch that Clear the TV sense state bits on cantiga to make TV detection reliable
Description Santi 2009-12-12 13:28:32 UTC
Created attachment 24162 [details] dmesg output with a normal console Hello, I've tested the lastes drm-2.6/drm-linus tree (v2.6.32-207-gd1ede14) now included in linus' tree (what will be 2.6.33-rc1) and found that it misdetects the TV output and I get a much smaller console. The first bad commit is: v2.6.32-rc6-285-g27dfaf4 commit 27dfaf4f5825a119305db1bc63bef30ed400e376 Author: Adam Jackson <email@example.com> Date: Fri Nov 20 06:22:44 2009 drm/i915: disable the interrupt hotplug for integrated TV output Otherwise, I'd get stuck in a loop where (afaict) output scan would trigger a TV interrupt, which would trigger a scan, etc. TV load detection not being the fastest thing in the world, X would process requests very slowly. https://bugs.freedesktop.org/show_bug.cgi?id=24404 Signed-off-by: Adam Jackson <firstname.lastname@example.org> Acked-by: Zhao Yakui <email@example.com> Signed-off-by: Eric Anholt <firstname.lastname@example.org> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 120c77d..6b59602 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -877,7 +877,6 @@ HDMID_HOTPLUG_INT_EN | \ SDVOB_HOTPLUG_INT_EN | \ SDVOC_HOTPLUG_INT_EN | \ - TV_HOTPLUG_INT_EN | \ CRT_HOTPLUG_INT_EN) ------------------------- and here you can find the dmesg (drm) differences between before and after that patch: diff --git a/2.6.32-rc6-00284-g28cf798_20091212_1351/dmesg b/2.6.32-rc6-00285-g27dfaf4_20091212_1348/dmesg --- a/2.6.32-rc6-00284-g28cf798_20091212_1351/dmesg +++ b/2.6.32-rc6-00285-g27dfaf4_20091212_1348/dmesg @@ -466,8 +466,9 @@ ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected String at index 1 ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected String at index 12 (20090903/nsrepair-132) ACPI: Battery Slot [BAT0] (battery present) [drm] TV-21: set mode NTSC 480i 0 -[drm] LVDS-8: set mode 1440x900 c -Console: switching to colour frame buffer device 180x56 +[drm] TV-21: set mode 848x480 2b +[drm] LVDS-8: set mode 1440x900 2c +Console: switching to colour frame buffer device 106x30 fb0: inteldrmfb frame buffer device registered panic notifier acpi device:3b: registered as cooling_device2 @@ -747,13 +748,9 @@ EXT3-fs: mounted filesystem with ordered data mode. tg3 0000:09:00.0: irq 30 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready iwlagn 0000:0c:00.0: firmware: requesting iwlwifi-5000-2.ucode -[drm] TV-21: set mode NTSC 480i 0 iwlagn 0000:0c:00.0: loaded firmware version 184.108.40.206 -[drm] TV-21: set mode NTSC 480i 0 Registered led device: iwl-phy0::radio Registered led device: iwl-phy0::assoc Registered led device: iwl-phy0::RX Registered led device: iwl-phy0::TX ADDRCONF(NETDEV_UP): wlan0: link is not ready -[drm] TV-21: set mode NTSC 480i 0 -[drm] TV-21: set mode NTSC 480i 0 I have a Dell Latitude E5400 with an intel card: with an intel card: 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) This bug is very similar to another fixed one that I also reported: http://bugzilla.kernel.org/show_bug.cgi?id=13462 Just tell me if you need more info or you want me to try a patch. Thanks, Santi
Comment 1 zhenyuw 2009-12-28 03:28:13 UTC
Created attachment 24323 [details] remove tv hotplug status check Not sure if this is related, but we should remove tv status check after removing tv hotplug.
Comment 2 Santi 2009-12-29 00:17:21 UTC
There is no change with the patch from Comment #1. One more thing I've noticed is that it works ok if the i915 driver is a module, not builtin (at least with your additional patch, I'll check also with a clean mainline linux).
Comment 3 Santi 2010-01-01 11:43:05 UTC
It also happens (works ok if built as a module, but not if builtin) with a clean mainline linux, 2.6.33-rc2. And following Rafael's request I confirm that the bug still happens with the lastest release candidate, namely 2.6.33-rc2. Santi
Comment 4 ykzhao 2010-01-05 01:15:18 UTC
Hi, Santi Will you please add the boot option of "drm.debug=0x06" on 2.6.33-rc2 and attach the output of dmesg? Thanks.
Comment 5 Santi 2010-01-05 09:00:32 UTC
Created attachment 24440 [details] 2.6.33-rc2 dmesg output with "drm.debug=0x06"
Comment 6 ykzhao 2010-01-15 08:31:23 UTC
HI, Santi Will you please revert the commit(27dfaf4f5825a119305db1bc63bef30ed400e376) on the 2.6.33-rc2 and attach the output of dmesg? Please also add the boot option of "drm.debug=0x06". thanks.
Comment 7 Santi 2010-01-15 17:04:44 UTC
Created attachment 24574 [details] 2.6.33-rc2+revert(27dfaf4f582) dmesg output with "drm.debug=0x06" Hi ykzhao, here you have the requested output, 2.6.33-rc2+revert(27dfaf4f582) dmesg output with "drm.debug=0x06". Thanks, Santi
Comment 8 Santi 2010-01-19 08:56:21 UTC
Created attachment 24627 [details] 2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a good console Hi, occasionally the console boots OK. I'll send two dmesg outputs with the same kernel image (2.6.33-rc4-00189-g6ccf80e), one with a good console and the other with a "bad" console. HTH, Santi
Comment 9 Santi 2010-01-19 08:58:05 UTC
Created attachment 24628 [details] 24627: 2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a "bad" console
Comment 10 Rafael J. Wysocki 2010-01-26 12:10:49 UTC
Handled-By : Zhao Yakui <email@example.com> First-Bad-Commit : 27dfaf4f5825a119305db1bc63bef30ed400e376 Does everything work correctly if you revert commit 27dfaf4f5825a119305db1bc63bef30ed400e376?
Comment 11 Santi 2010-01-26 12:59:01 UTC
(In reply to comment #10) > Handled-By : Zhao Yakui <firstname.lastname@example.org> > First-Bad-Commit : 27dfaf4f5825a119305db1bc63bef30ed400e376 > > Does everything work correctly if you revert commit > 27dfaf4f5825a119305db1bc63bef30ed400e376? The problem is that it is no longer possible to revert this commit, as the HOTPLUG_EN_MASK macro was removed in commit b01f2c3a4a37d09a47ad73ccbb46d554d21cfeb0. Thanks, Santi P.D.: The bug still exists in v2.6.33-rc5.
Comment 12 Jesse Barnes 2010-02-05 18:25:17 UTC
I'm confused by comment #3. Do things work well if you build i915 modular? Or do you still get the lower resolution in that case? Also, can you set a higher resolution later on after the kernel has started up? Or does the kernel or xrandr report fewer modes on the TV output than before?
Comment 13 Santi 2010-02-05 23:05:22 UTC
(In reply to comment #12) > I'm confused by comment #3. Do things work well if you build i915 modular? Yes. > Or > do you still get the lower resolution in that case? No, I get the maximum resolution. But I would not call it lower resolution, as I think the resolution is the same, only that there is empty space on the right and below the text. > Also, can you set a higher > resolution later on after the kernel has started up? X always uses the maximum resolution, even when the console is using the lower resolution. I don't know how to change the console mode at runtime. It seems I only have one console mode, either $ cat /sys/class/graphics/fb0/modes U:848x480p-0 or $ cat /sys/class/graphics/fb0/modes U:1440x900p-0 > Or does the kernel or > xrandr report fewer modes on the TV output than before? I have nothing in attached on the TV output, so I don't know. But now without connecting the TV output I get this: $ xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm x 190mm 1440x900 60.0*+ 59.9 40.0 1360x768 59.8 1152x864 100.0 85.1 85.0 75.0 75.0 70.0 60.0 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 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) TV1 connected (normal left inverted right x axis y axis) 848x480 30.0 + 640x480 30.0 + 1024x768 30.0 800x600 30.0 while I don't get TV1 modes when the console is OK. HTH, Santi
Comment 14 Jesse Barnes 2010-02-05 23:30:16 UTC
Wow it's interesting that the TV would report different modes when modular vs. builtin. But this really sounds like a TV detect bug. Maybe the patch in https://bugs.freedesktop.org/show_bug.cgi?id=25913 helps?
Comment 15 Santi 2010-02-06 10:36:03 UTC
(In reply to comment #14) > Wow it's interesting that the TV would report different modes when modular > vs. > builtin. > > But this really sounds like a TV detect bug. Yes, this is why the title is "Misdetection of the TV output" ;-) > Maybe the patch in > https://bugs.freedesktop.org/show_bug.cgi?id=25913 helps? Yes, thanks. I've restarted the machine five times in a row and the console (and xrandr output) are OK. Thanks, Santi
Comment 16 Jesse Barnes 2010-02-19 20:28:35 UTC
Zhenyu, since you're our TV out expert, can you take a look? Thanks, Jesse
Comment 17 Rafael J. Wysocki 2010-03-21 12:35:32 UTC
Comment 18 ykzhao 2010-03-25 03:18:46 UTC
Sorry for the late response. I also get one Dell e5400 laptop and reproduce this issue on this box. I will look at the TV detection. thanks.
Comment 19 ykzhao 2010-03-26 09:47:00 UTC
Created attachment 25722 [details] try the debug patch that uses the bios mechanism to detect TV Hi, Santi Will you please try the attached patch and see whether the issue can be fixed? Thanks.
Comment 20 Santi 2010-03-28 21:23:13 UTC
Hi, I can confirm that I no longer have this bug (testing on top of 2.6.33 and latest v2.6.34-rc2-219-ge1ee65d). But I cannot test if the TVout actually works. Thanks, Santi
Comment 21 ykzhao 2010-03-31 05:31:16 UTC
thanks for the testing. It is good news that the issue of TV misdetection is gone after applying the patch in comment #19. I will try to push the patch in comment #19. Thanks. Yakui
Comment 22 ykzhao 2010-04-02 07:01:25 UTC
Created attachment 25815 [details] try the updated patch Hi, Santi Will you please try the updated patch and see whether the issue can be fixed? Thanks.
Comment 23 Santi 2010-04-02 22:45:25 UTC
Hi Yakui, I've tried the update patch on top of v2.6.34-rc2-219-ge1ee65d and it works. Thanks, Santi
Comment 24 ykzhao 2010-04-07 00:30:00 UTC
Created attachment 25887 [details] the updated patch that Clear the TV sense state bits on cantiga to make TV detection reliable Hi, Santi thanks for the testing. The attached is the updated patch. There is no functional change. It will look clearer. thanks.
Comment 25 Takashi Iwai 2010-04-21 14:09:14 UTC
The patch in comment 24 also fixes a problem on an HP laptop with GM45 here, too. Tested-by: Takashi Iwai <email@example.com>
Comment 26 Rafael J. Wysocki 2010-04-21 15:46:56 UTC
Patch : https://bugzilla.kernel.org/attachment.cgi?id=25887 Handled-By : Zhao Yakui <firstname.lastname@example.org>
Comment 27 Santi 2010-09-03 16:42:28 UTC
Hello, I've tested latest mainline kernel 2.6.36-rc3 and it is fixed. I've bisected it and found that the following patch fixes the problem: commit 9d0498 (v2.6.35-5842-g9d0498a) Author: Jesse Barnes <email@example.com> Date: Wed Aug 18 22:20:54 2010 drm/i915: wait for actual vblank, not just 20ms Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling). This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141. Signed-off-by: Jesse Barnes <firstname.lastname@example.org> Signed-off-by: Eric Anholt <email@example.com> Thanks, Santi
Comment 28 Santi 2010-09-08 22:17:29 UTC
Hi *, unfortunately it is no longer fixed. I've tested: v2.6.36-rc3-185-gd56557a (Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6, 2010-09-07) and all the symptoms reappeared. It was fixed in v2.6.36-rc3. I think it is because there is a partial revert: commit 4f233eff6f32745f8894eb513bc59851213c7833 Author: Pekka Enberg <firstname.lastname@example.org> Date: Sat Sep 4 18:24:04 2010 i915: Fix spurious TV detection after 9d0498a2bf + 9559fcdbff Partial revert of 9d0498a2bf. Signed-off-by: Pekka Enberg <email@example.com> Tested-by: Hugh Dickins <firstname.lastname@example.org> Tested-by: Sven Joachim <email@example.com> Signed-off-by: Chris Wilson <firstname.lastname@example.org> Santi
Comment 29 Chris Wilson 2010-09-11 09:11:04 UTC
That's ok, it just means the code is still just as broken as it always was and no longer hidden by an even bigger bug.
Comment 30 Peter Clifton 2010-11-25 01:00:21 UTC
The patch in comment 24 has always fixed the problem for me, and I routinely re-patch it on top of drm-intel-next. Can somone at intel get at the non-public HW docs and confirm Zhao Yakui's comments relating to buggy hardware? Tested-by: Peter Clifton <email@example.com>
Comment 31 o. meijer 2010-12-11 11:56:44 UTC
I encounter the same (sort of) bug with the same hardware. I can confirm that the patch in comment 24 always fixes the problem for me. (kernel 220.127.116.11 still contains the bug) My bug report can be found here. https://bugzilla.kernel.org/show_bug.cgi?id=16236 (I am fairly sure that this is caused by the same bug, as the same patch fixes it) I hope that this bug can be solved soon. best regards, otto meijer
Comment 32 Takashi Iwai 2012-03-02 08:35:30 UTC
FWIW, I've still seen this problem even on 3.0, 3.1 and 3.2 kernels with multiple machines (HP and Acer). The bug rate is fairly rare, less than 1/20, though.
Comment 33 Daniel Vetter 2012-03-27 14:06:32 UTC
*** Bug 16236 has been marked as a duplicate of this bug. ***