Created attachment 73631 [details] dmesg System Environment: -------------------------- Arch: i386 Platform: Pineview Kernel: (drm-intel-fixes)4518f611ba21ba165ea3714055938a8984a44ff9 Bug detailed description: ------------------------- It fails on Pineview with -queued kernel and -fixes kernel. I can't catch a good commit. output: Using monotonic timestamps running testcase: absolute-wf_vblank could not find requested crtc 3 Beginning absolute-wf_vblank on crtc 4, connector 5 1024x600 60 1024 1048 1184 1438 600 603 604 628 0xa 0x48 54200 .select timed out or error (ret 0) # echo $? 1 Reproduce steps: ---------------- 1. ./kms_flip --run-subtest absolute-wf_vblank
What happens on -nightly? That contains the reworked locking and a few other patches which are only in drm-next thus far.
It also happens on -nightly kernel. Kernel: (drm-intel-nightly)2d039f65e28be0be6ef765f6da45df6b3c4efef2 Merge: ef13e7f 735dc0d
The subcase "flip-vs-absolute-wf_vblank" on pnv also exist this problem.And there are same std out.
Hm, do you see the "select timed out" failure also on other machines or only on pnv?
(In reply to comment #4) > Hm, do you see the "select timed out" failure also on other machines or only > on pnv? Only on Pineview.
Can you please retest with the following patch applied to latest -nightly? https://patchwork.kernel.org/patch/2709081/
(In reply to comment #6) > Can you please retest with the following patch applied to latest -nightly? > > https://patchwork.kernel.org/patch/2709081/ I applied the patch on nightly top, I find this sub case worked very well, it passed and return value is 0.
It's a drm core patch. I'll close the bug as soon the patch has landed in upstream drm branch and is merged into -nightly.
Ok, the patch was finally merged to drm-fixes and so can be tested in drm-intel-nightly: commit e91abf80a0998f326107874c88d549f94839f13c Author: Michel Dänzer <michel.daenzer@amd.com> Date: Wed Jun 12 11:58:44 2013 +0200 drm: Don't pass negative delta to ktime_sub_ns()
Run it on latest -nightly kernel(3477e5ea598c88d21f24c00f8fcdfd7f4e837b59), the first cycle is pass, the 2nd cycle will reproduce this fail. [root@x-pnv2 tests]# ./kms_flip --run-subtest absolute-wf_vblank Using monotonic timestamps running testcase: absolute-wf_vblank no crtc with a compatible encoder (crtc_idx_mask 00000001) Beginning absolute-wf_vblank on crtc 4, connector 5 1024x600 60 1024 1072 1104 1200 600 603 609 625 0xa 0x48 45000 ............................................................. absolute-wf_vblank on crtc 4, connector 5: PASSED [root@x-pnv2 tests]# ./kms_flip --run-subtest absolute-wf_vblank Using monotonic timestamps running testcase: absolute-wf_vblank no crtc with a compatible encoder (crtc_idx_mask 00000001) Beginning absolute-wf_vblank on crtc 4, connector 5 1024x600 60 1024 1072 1104 1200 600 603 609 625 0xa 0x48 45000 .select timed out or error (ret 0)
Created attachment 83877 [details] dmesg on nightly 3477e5
The bug seems to have been neglected a bit. Is this still an issue on current -nightly and igt? Please attach current dmesg if it is. Thanks.
The output info shows success, but it causes call trace. output: Using monotonic timestamps Beginning absolute-wf_vblank on crtc 4, connector 5 1024x600 60 1024 1072 1104 1200 600 603 609 625 0xa 0x48 45000 .................................................................................................................................................................................... absolute-wf_vblank on crtc 4, connector 5: PASSED Subtest absolute-wf_vblank: SUCCESS Call trace: [ 2.440626] WARNING: CPU: 1 PID: 1208 at drivers/gpu/drm/i915/intel_panel.c:342 intel_panel_compute_brightness+0x27/0x4b [i915]() [ 2.440635] Modules linked in: i915(+) video button drm_kms_helper drm [ 2.440640] CPU: 1 PID: 1208 Comm: udevd Not tainted 3.13.0-rc7_drm-intel-nightly_24ed7d_20140113+ #2757 [ 2.440642] Hardware name: MICRO-STAR INTERNATIONAL CO., LTD MS-N014/MS-N014, BIOS EN014IMS.10B 11/30/2009 [ 2.440650] 00000000 c0890ccc 00000000 c022b5df f82e47e6 00000000 f5970000 f587c000 [ 2.440657] 00000293 c022b5ff 00000009 00000000 f82e47e6 f5970000 f587c000 f587d2d4 [ 2.440663] f82e483d 00000002 f831569e f8308adc f8315686 00000000 00000000 f5970000 [ 2.440665] Call Trace: [ 2.440673] [<c0890ccc>] ? dump_stack+0x3e/0x4e [ 2.440680] [<c022b5df>] ? warn_slowpath_common+0x61/0x74 [ 2.440740] [<f82e47e6>] ? intel_panel_compute_brightness+0x27/0x4b [i915] [ 2.440746] [<c022b5ff>] ? warn_slowpath_null+0xd/0x10 [ 2.440806] [<f82e47e6>] ? intel_panel_compute_brightness+0x27/0x4b [i915] [ 2.440867] [<f82e483d>] ? intel_panel_actually_set_backlight+0x33/0x43 [i915] [ 2.440929] [<f82e584a>] ? intel_panel_disable_backlight+0x58/0x6a [i915] [ 2.440986] [<f82d5cb1>] ? intel_disable_lvds+0x35/0x110 [i915] [ 2.441011] [<f82ca647>] ? i9xx_crtc_disable+0x50/0x20c [i915] [ 2.441011] [<f82d0237>] ? __intel_set_mode+0xbd6/0xf82 [i915] [ 2.441011] [<c024f907>] ? down_trylock+0x1b/0x23 [ 2.441011] [<c025727c>] ? console_trylock+0xb/0x43 [ 2.441011] [<f82d1ea1>] ? intel_set_mode+0x11/0x25 [i915] [ 2.441011] [<f82d24b7>] ? intel_crtc_set_config+0x551/0x72a [i915] [ 2.441011] [<f810b974>] ? drm_mode_set_config_internal+0x36/0x8c [drm] [ 2.441011] [<f812bf55>] ? drm_fb_helper_set_par+0x46/0x7c [drm_kms_helper] [ 2.441011] [<c04b270a>] ? fbcon_init+0x2c3/0x3a3 [ 2.441011] [<c04f60e5>] ? visual_init+0x97/0xe9 [ 2.441011] [<c04f7758>] ? do_bind_con_driver+0x16e/0x275 [ 2.441011] [<c04f796b>] ? do_take_over_console+0x10c/0x134 [ 2.441011] [<c04b1ece>] ? do_fbcon_takeover+0x49/0x88 [ 2.441011] [<c0897e62>] ? notifier_call_chain+0x20/0x42 [ 2.441011] [<c0241074>] ? __blocking_notifier_call_chain+0x34/0x4b [ 2.441011] [<c0241094>] ? blocking_notifier_call_chain+0x9/0xc [ 2.441011] [<c04aa838>] ? register_framebuffer+0x1f6/0x248 [ 2.441011] [<f812be8a>] ? drm_fb_helper_initial_config+0x33c/0x3c1 [drm_kms_helper] [ 2.441011] [<f82acf19>] ? i915_driver_load+0x927/0xb64 [i915] [ 2.441011] [<f81075a1>] ? drm_dev_register+0xb1/0x113 [drm] [ 2.441011] [<f8108f6e>] ? drm_get_pci_dev+0xdd/0x176 [drm] [ 2.441011] [<c049cd81>] ? pci_device_probe+0x4e/0x95 [ 2.441011] [<c050f36b>] ? driver_probe_device+0x79/0x168 [ 2.441011] [<c050f49e>] ? __driver_attach+0x44/0x5f [ 2.441011] [<c050e177>] ? bus_for_each_dev+0x37/0x61 [ 2.441011] [<c050f03e>] ? driver_attach+0x11/0x13 [ 2.441011] [<c050f45a>] ? driver_probe_device+0x168/0x168 [ 2.441011] [<c050ed7b>] ? bus_add_driver+0xad/0x167 [ 2.441011] [<c050f8f2>] ? driver_register+0x6b/0x99 [ 2.441011] [<f8148000>] ? 0xf8147fff [ 2.441011] [<c02003d4>] ? do_one_initcall+0x6d/0xe9 [ 2.441011] [<c0897e62>] ? notifier_call_chain+0x20/0x42 [ 2.441011] [<c024107d>] ? __blocking_notifier_call_chain+0x3d/0x4b [ 2.441011] [<c026d0a9>] ? load_module+0x140b/0x16e5 [ 2.441011] [<c0897e35>] ? __do_page_fault+0x45d/0x45d [ 2.441011] [<c026d3f5>] ? SyS_init_module+0x72/0x8a [ 2.441011] [<c089991a>] ? sysenter_do_call+0x12/0x22 [ 2.441011] ---[ end trace c424884943f003b3 ]---
Created attachment 91921 [details] dmesg
Is this still an issue with current kernels? It's been a while since there was any input on this. Looking at the code though, the call trace is from here: WARN_ON(panel->backlight.max == 0); I'll see what else I can dig up, but I don't have a PNV system to investigate this on.
(In reply to comment #15) > Looking at the code though, the call trace is from here: > WARN_ON(panel->backlight.max == 0); At least this shouldn't happen on current nightly.
It works well on latest -nightly kernel. Close it.
Verified.Fixed.
Closing old verified.
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.