System Environment: -------------------------- Arch: i386 Platform: 945 Kernel: (drm-intel-next-queued)d7697eea3eec74c561d12887d892c53ac4380c00 Bug detailed description: ------------------------- It aborted on 945 with drm-intel-next-queued kernel and drm-intel-fixes kernel. I can't find out a good commit. output: main:197 failed, ret=-1, errno=28 Aborted (core dumped) dmesg: [ 546.366407] [drm:i915_driver_open], [ 546.366435] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 546.366441] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 546.366445] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 546.366450] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 546.366461] [drm:i915_driver_open], [ 580.858576] [drm:i915_driver_open], [ 580.858600] [drm:i915_driver_open], [ 581.230673] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 581.230683] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 581.230687] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 581.230692] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 601.056073] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 [ 601.334035] [drm:i9xx_pfit_disable], disabling pfit, current: 0x00000008 [ 601.334040] [drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) A: 28 [ 601.334042] [drm:i9xx_get_fifo_size], FIFO size - (0x00001d9c) B: 31 [ 601.334044] [drm:i9xx_update_wm], FIFO watermarks - A: 26, B: 29 [ 601.334047] [drm:i9xx_update_wm], Setting FIFO watermarks - A: 26, B: 29, C: 2, SR 1 [ 601.334049] [drm:i9xx_update_wm], memory self refresh disabled [ 601.334054] [drm:intel_modeset_check_state], [ENCODER:6:LVDS-6] [ 601.334057] [drm:intel_modeset_check_state], [ENCODER:12:DAC-12] [ 601.334059] [drm:intel_modeset_check_state], [CRTC:3] [ 601.334062] [drm:intel_modeset_check_state], [CRTC:4] [ 601.334896] [drm:intel_panel_get_max_backlight], max backlight PWM = 20828 Reproduce steps: ---------------- 1. ./gem_lut_handle
ENOSPC. I guess we should scale the workload a bit ;-)
commit f1e9e300fa82181182e2e92ccce078682829a3a2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 5 11:10:04 2013 +0100 gem_lut_handle: Make the error checking explicit for LUT handling What this test is interested in is the handling of the LUT for very large arrays, irrespective of whether such batch are actually executable. So adjust the pass/fail checks to be explicit in the error they are looking for, so that we do not conflate memory/aperture pressure as a failure in the LUT API. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65391 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It still core dumped. output: gem_lut_handle: gem_lut_handle.c:209: main: Assertion `((many_exec(fd, handle, i-1, i-1, 0 | 0x2)) == -1 && (*__errno_location ()) == 2)' failed. Aborted (core dumped) dmesg: [ 45.123866] [drm:i915_driver_open], [ 45.123904] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 45.123913] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 45.123919] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 45.123927] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 45.123945] [drm:i915_driver_open], [ 45.124221] [drm:i915_getparam], Unknown parameter 22 [ 87.786595] [drm:i915_driver_open], [ 87.786619] [drm:i915_driver_open], [ 87.786672] [drm:i915_getparam], Unknown parameter 22 [ 88.101987] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 88.101996] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 88.102001] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 88.102006] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4]
Let's try that again after fixing up the test... commit 9d8fc1957c8cccb6875264334cd67bb24c6e7c54 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 7 11:44:40 2013 +0100 gem_lut_handle: Avoid using a valid handle when testing BROKEN
It still happens. gem_lut_handle: gem_lut_handle.c:206: main: Assertion `((many_exec(fd, handle, i-1, i-1, 0 | 0x2)) == -1 && (*__errno_location ()) == 2)' failed. Aborted (core dumped)
Keeping Chris busy ...
Can you please tell me what the output is after commit e56754965fad7c53130cecd26a91b841e22a8ab9 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 19 14:19:07 2013 +0100 gem_lut_handle: Print some more information upon failure References: https://bugs.freedesktop.org/show_bug.cgi?id=65391 ?
It still happens on latest branch. output: main:213 failed, errno=28 Aborted (core dumped) dmesg: [ 53.452655] [drm:i915_driver_open], [ 53.452692] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 53.452701] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 53.452708] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 53.452716] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 53.452734] [drm:i915_driver_open], [ 95.915179] [drm:i915_driver_open], [ 95.915203] [drm:i915_driver_open], [ 96.468476] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 96.468486] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 96.468490] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 96.468495] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4]
And again, as the kernel should not be getting as far as an ENOSPC (at least wrt to i915_gem_execbuffer.c) commit 60e3930987134ff855cb24dd1021eb5225b18857 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jun 24 13:53:44 2013 +0100 tests/gem_lut_handle: Simplify creation of broken handles Limit the broken handles to UINT32_MAX-4096 so that we can be sure that they do not alias with a valid handle. References: https://bugs.freedesktop.org/show_bug.cgi?id=65391 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #9) > And again, as the kernel should not be getting as far as an ENOSPC (at least > wrt to i915_gem_execbuffer.c) > > commit 60e3930987134ff855cb24dd1021eb5225b18857 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Mon Jun 24 13:53:44 2013 +0100 > > tests/gem_lut_handle: Simplify creation of broken handles > > Limit the broken handles to UINT32_MAX-4096 so that we can be sure that > they do not alias with a valid handle. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=65391 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> It still happens. output: main:211 failed, errno=28 Aborted (core dumped) dmesg: [ 71.103735] [drm:i915_driver_open], [ 71.103772] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 71.103781] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 71.103788] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 71.103796] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 71.103814] [drm:i915_driver_open], [ 71.103894] [drm:i915_getparam], Unknown parameter 22 [ 113.220557] [drm:i915_driver_open], [ 113.220581] [drm:i915_driver_open], [ 113.220634] [drm:i915_getparam], Unknown parameter 22 [ 113.810475] [drm:intel_crtc_set_config], [CRTC:3] [NOFB] [ 113.810484] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4] [ 113.810488] [drm:intel_crtc_set_config], [CRTC:4] [FB:14] #connectors=1 (x y) (0 0) [ 113.810493] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:4]
commit ebfd01908f787876040a679fc7895828b23d268d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 27 19:58:57 2013 +0100 tests/gem_lut_handle: Quit when we hit ENOSPC I'd been working under the falsehood that we would always generate an error for an invalid reloc->target_handle before reserving any object. However, only the execlist is checked up front for validity before reservation so ENOSPC is a genuine error condition raised by the test. Fix it so that we stop reporting that limit as a test failure. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65391
Verified.Fixed.
So closed
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.