Re: [Intel-gfx] Oops with i915
Hi Ville,
On Mon, Jun 18, 2018 at 03:09:15PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 07, 2018 at 11:06:33AM +0100, Sudip Mukherjee wrote:
> > Hi All,
> >
> > We are running v4.14.47 kernel and recently in one of our test cycle
> > we saw the below trace. I know this is not the usual way to raise a
> > BUG report, but since this was seen only once in one of the automated
> > test cycle so I donot have anything else apart from this trace.
> > Is this a known issue? Will appreciate any help in understanding what
> > the problem might be.
> >
> > [ 1176.909543] BUG: unable to handle kernel paging request at 8298fb0a
> > [ 1176.916565] IP: queued_spin_lock_slowpath+0xfc/0x142
> > [ 1176.922111] *pdpt = 3367a001 *pde =
> > [ 1176.928534] Oops: 0002 [#1] PREEMPT SMP
> > [ 1177.002434] CPU: 2 PID: 24688 Comm: kworker/u8:4 Tainted: G U O
> > 4.14.47-20180606-a6b8390e8cc1de032b8314d1a5b193fe9e21f325 #1
> > [ 1177.024120] Workqueue: events_unbound intel_atomic_commit_work
> > [ 1177.030630] task: ef2ee200 task.stack: efbf4000
> > [ 1177.035685] EIP: queued_spin_lock_slowpath+0xfc/0x142
> > [ 1177.041327] EFLAGS: 00010087 CPU: 2
> > [ 1177.045212] EAX: 8298fb0a EBX: 3ba0 ECX: ee82489c EDX: f4656fc0
> > [ 1177.052215] ESI: 000c EDI: 0001 EBP: efbf5e88 ESP: efbf5e78
> > [ 1177.059217] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
> > [ 1177.065239] CR0: 80050033 CR2: 8298fb0a CR3: 2e8ed320 CR4: 001006f0
> > [ 1177.072240] Call Trace:
> > [ 1177.074973] _raw_spin_lock_irqsave+0x28/0x2d
> > [ 1177.079840] complete_all+0x12/0x36
> > [ 1177.083737] drm_atomic_helper_commit_hw_done+0x3c/0x43
> > [ 1177.089576] intel_atomic_commit_tail+0xa5f/0xbd9
> > [ 1177.094832] ? wait_woken+0x5a/0x5a
> > [ 1177.098727] ? wait_woken+0x5a/0x5a
> > [ 1177.102622] intel_atomic_commit_work+0xb/0xd
> > [ 1177.107489] ? intel_atomic_commit_work+0xb/0xd
> > [ 1177.112551] process_one_work+0x109/0x1ee
> > [ 1177.117029] worker_thread+0x1a4/0x257
> > [ 1177.121215] kthread+0xee/0xf3
> > [ 1177.124625] ? rescuer_thread+0x207/0x207
> > [ 1177.129103] ? kthread_create_on_node+0x1a/0x1a
> > [ 1177.134165] ret_from_fork+0x2e/0x38
> > [ 1177.138156] Code: 12 09 de 89 f0 89 75 f0 c1 e8 10 66 87 41 02 89 c3 c1
> > e3 10 74 51 83 e0 03 c1 eb 12 6b c0 0c 05 c0 1f 7e c1 03 04 9d d8 b1 6c c1
> > <89> 10 8b 42 04 85 c0 75 04 f3 90 eb f5 8b 1a 85 db 74 03 0f 0d
> > [ 1177.159204] EIP: queued_spin_lock_slowpath+0xfc/0x142 SS:ESP:
> > 0068:efbf5e78
> > [ 1177.166983] CR2: 8298fb0a
>
> Presumably a use after free in atomic. Possibly 21a01abbe32a
> ("drm/atomic: Fix freeing connector/plane state too early by tracking
> commits, v3.") But there may have been other similar fixes.
Thanks for your reply. I also thought so as the stacktrace showed it was
using an invalid memory for the old_state. And so I applied:
21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by
tracking commits, v3.")
on top of v4.14.47. It also needed:
1) f46640b931e5 ("drm/atomic: Return commit in drm_crtc_commit_get for better
annotation")
2) 163bcc2c74a2 ("drm/atomic: Move drm_crtc_commit to drm_crtc_state, v4.")
to apply cleanly. But after that the occurance rate increased.
Did I miss something else also?
Will apprecate your help in finding a fix to this.
--
Regards
Sudip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Oops with i915
On Thu, Jun 07, 2018 at 11:06:33AM +0100, Sudip Mukherjee wrote: > Hi All, > > We are running v4.14.47 kernel and recently in one of our test cycle > we saw the below trace. I know this is not the usual way to raise a > BUG report, but since this was seen only once in one of the automated > test cycle so I donot have anything else apart from this trace. > Is this a known issue? Will appreciate any help in understanding what > the problem might be. > > [ 1176.909543] BUG: unable to handle kernel paging request at 8298fb0a > [ 1176.916565] IP: queued_spin_lock_slowpath+0xfc/0x142 > [ 1176.922111] *pdpt = 3367a001 *pde = > [ 1176.928534] Oops: 0002 [#1] PREEMPT SMP > [ 1177.002434] CPU: 2 PID: 24688 Comm: kworker/u8:4 Tainted: G U O > 4.14.47-20180606-a6b8390e8cc1de032b8314d1a5b193fe9e21f325 #1 > [ 1177.024120] Workqueue: events_unbound intel_atomic_commit_work > [ 1177.030630] task: ef2ee200 task.stack: efbf4000 > [ 1177.035685] EIP: queued_spin_lock_slowpath+0xfc/0x142 > [ 1177.041327] EFLAGS: 00010087 CPU: 2 > [ 1177.045212] EAX: 8298fb0a EBX: 3ba0 ECX: ee82489c EDX: f4656fc0 > [ 1177.052215] ESI: 000c EDI: 0001 EBP: efbf5e88 ESP: efbf5e78 > [ 1177.059217] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 > [ 1177.065239] CR0: 80050033 CR2: 8298fb0a CR3: 2e8ed320 CR4: 001006f0 > [ 1177.072240] Call Trace: > [ 1177.074973] _raw_spin_lock_irqsave+0x28/0x2d > [ 1177.079840] complete_all+0x12/0x36 > [ 1177.083737] drm_atomic_helper_commit_hw_done+0x3c/0x43 > [ 1177.089576] intel_atomic_commit_tail+0xa5f/0xbd9 > [ 1177.094832] ? wait_woken+0x5a/0x5a > [ 1177.098727] ? wait_woken+0x5a/0x5a > [ 1177.102622] intel_atomic_commit_work+0xb/0xd > [ 1177.107489] ? intel_atomic_commit_work+0xb/0xd > [ 1177.112551] process_one_work+0x109/0x1ee > [ 1177.117029] worker_thread+0x1a4/0x257 > [ 1177.121215] kthread+0xee/0xf3 > [ 1177.124625] ? rescuer_thread+0x207/0x207 > [ 1177.129103] ? kthread_create_on_node+0x1a/0x1a > [ 1177.134165] ret_from_fork+0x2e/0x38 > [ 1177.138156] Code: 12 09 de 89 f0 89 75 f0 c1 e8 10 66 87 41 02 89 c3 c1 e3 > 10 74 51 83 e0 03 c1 eb 12 6b c0 0c 05 c0 1f 7e c1 03 04 9d d8 b1 6c c1 <89> > 10 8b 42 04 85 c0 75 04 f3 90 eb f5 8b 1a 85 db 74 03 0f 0d > [ 1177.159204] EIP: queued_spin_lock_slowpath+0xfc/0x142 SS:ESP: 0068:efbf5e78 > [ 1177.166983] CR2: 8298fb0a A gentile ping on this issue. Can anyone please help me on this. -- Regards Sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Oops with i915
Hi All, We are running v4.14.47 kernel and recently in one of our test cycle we saw the below trace. I know this is not the usual way to raise a BUG report, but since this was seen only once in one of the automated test cycle so I donot have anything else apart from this trace. Is this a known issue? Will appreciate any help in understanding what the problem might be. [ 1176.909543] BUG: unable to handle kernel paging request at 8298fb0a [ 1176.916565] IP: queued_spin_lock_slowpath+0xfc/0x142 [ 1176.922111] *pdpt = 3367a001 *pde = [ 1176.928534] Oops: 0002 [#1] PREEMPT SMP [ 1177.002434] CPU: 2 PID: 24688 Comm: kworker/u8:4 Tainted: G U O 4.14.47-20180606-a6b8390e8cc1de032b8314d1a5b193fe9e21f325 #1 [ 1177.024120] Workqueue: events_unbound intel_atomic_commit_work [ 1177.030630] task: ef2ee200 task.stack: efbf4000 [ 1177.035685] EIP: queued_spin_lock_slowpath+0xfc/0x142 [ 1177.041327] EFLAGS: 00010087 CPU: 2 [ 1177.045212] EAX: 8298fb0a EBX: 3ba0 ECX: ee82489c EDX: f4656fc0 [ 1177.052215] ESI: 000c EDI: 0001 EBP: efbf5e88 ESP: efbf5e78 [ 1177.059217] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 1177.065239] CR0: 80050033 CR2: 8298fb0a CR3: 2e8ed320 CR4: 001006f0 [ 1177.072240] Call Trace: [ 1177.074973] _raw_spin_lock_irqsave+0x28/0x2d [ 1177.079840] complete_all+0x12/0x36 [ 1177.083737] drm_atomic_helper_commit_hw_done+0x3c/0x43 [ 1177.089576] intel_atomic_commit_tail+0xa5f/0xbd9 [ 1177.094832] ? wait_woken+0x5a/0x5a [ 1177.098727] ? wait_woken+0x5a/0x5a [ 1177.102622] intel_atomic_commit_work+0xb/0xd [ 1177.107489] ? intel_atomic_commit_work+0xb/0xd [ 1177.112551] process_one_work+0x109/0x1ee [ 1177.117029] worker_thread+0x1a4/0x257 [ 1177.121215] kthread+0xee/0xf3 [ 1177.124625] ? rescuer_thread+0x207/0x207 [ 1177.129103] ? kthread_create_on_node+0x1a/0x1a [ 1177.134165] ret_from_fork+0x2e/0x38 [ 1177.138156] Code: 12 09 de 89 f0 89 75 f0 c1 e8 10 66 87 41 02 89 c3 c1 e3 10 74 51 83 e0 03 c1 eb 12 6b c0 0c 05 c0 1f 7e c1 03 04 9d d8 b1 6c c1 <89> 10 8b 42 04 85 c0 75 04 f3 90 eb f5 8b 1a 85 db 74 03 0f 0d [ 1177.159204] EIP: queued_spin_lock_slowpath+0xfc/0x142 SS:ESP: 0068:efbf5e78 [ 1177.166983] CR2: 8298fb0a -- Regards Sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 with valleyview
On Mon, May 09, 2016 at 11:19:16AM +0300, Jani Nikula wrote: > On Fri, 06 May 2016, Sudip Mukherjee <sudipm.mukher...@gmail.com> wrote: > > On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote: > >> Hi Daniel, > >> I am trying to use i915 in one of our board which has Intel ATOM E3840. > >> I know Intel has released emgd driver for this cpu to use i915 but emgd > >> is not supported on v4.5 (or v4.6). The board is having SFI (simple > >> firmware interface) and maybe for that i915 is not finding the VBIOS and > >> other required information. > > > > I have been looking more into it and looks like it is supposed to use > > dsi but since there is no vbt so has_mipi is never set and dsi is never > > initialized. > > Can you please point me to somewhere or maybe give some idea how i can > > use i915 in a board where there is no vbt. > > Hate to say it, but the i915 DSI support heavily relies on the VBT being > present. Basically all the configuration is there. I haven't got a clue > how emgd handles it. Maybe Matt does? emgd has a config file where we have to specify the configuration for it to work. > > Basically you'd either have to figure out the configuration for the > panel from somewhere and feed it to intel_dsi_panel_vbt.c, or write a > panel specific driver of your own. and i guess i will also need to modify intel_dsi_init() as that is also taking some of the information from the VBT. Thanks for the information. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 with valleyview
On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote: > Hi Daniel, > I am trying to use i915 in one of our board which has Intel ATOM E3840. > I know Intel has released emgd driver for this cpu to use i915 but emgd > is not supported on v4.5 (or v4.6). The board is having SFI (simple > firmware interface) and maybe for that i915 is not finding the VBIOS and > other required information. I have been looking more into it and looks like it is supposed to use dsi but since there is no vbt so has_mipi is never set and dsi is never initialized. Can you please point me to somewhere or maybe give some idea how i can use i915 in a board where there is no vbt. Regards Sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915 with valleyview
Hi Daniel, I am trying to use i915 in one of our board which has Intel ATOM E3840. I know Intel has released emgd driver for this cpu to use i915 but emgd is not supported on v4.5 (or v4.6). The board is having SFI (simple firmware interface) and maybe for that i915 is not finding the VBIOS and other required information. I have turned on drm debugging and some parts of it are: [0.390846] [drm] Initialized drm 1.1.0 20060810 [0.390875] i915 :00:02.0: PCI->APIC IRQ transform: INT A -> IRQ 16 [0.391595] [drm:i915_dump_device_info] i915 device info: gen=7, pciid=0x0f31 rev=0x0a flags=is_mobile,need_gfx_hws,is_valleyview,has_hotplug, [0.391615] [drm:intel_detect_pch] No PCH found. [0.391760] [drm] Memory usable by graphics device = 2048M [0.391764] [drm:i915_gem_gtt_init] GMADR size = 256M [0.391767] [drm:i915_gem_gtt_init] GTT stolen size = 64M [0.391770] [drm:sanitize_enable_ppgtt] disabling PPGTT on pre-B3 step VLV I can see that four connectors are registered. But I am also seeing- [2.143214] [drm:intel_crt_detect] [CONNECTOR:29:VGA-1] force=1 [2.143216] [drm:intel_power_well_enable] enabling display [2.149314] [drm:i915_redisable_vga_power_on] Something enabled VGA plane, disabling it [2.149627] [drm:intel_power_well_enable] enabling dpio-common [2.157670] [drm:valleyview_crt_detect_hotplug] trigger hotplug detect cycle: adpa=0x4 [2.161690] [drm:valleyview_crt_detect_hotplug] valleyview hotplug adpa=0x4, result 0 [2.161692] [drm:intel_crt_detect] CRT not detected via hotplug [2.168780] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter i915 gmbus vga [2.168782] [drm:intel_crt_detect_ddc] CRT not detected via DDC:0x50 [no valid EDID found] [2.168783] [drm:intel_power_well_disable] disabling dpio-common [2.176832] [drm:intel_power_well_disable] disabling display [2.186894] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:29:VGA-1] disconnected Same thing happens for all the other connectors. I will greatly appreciate any help or pointer to something which can make i915 work in this scenario. Maybe there is some option where I can provide the configuration to i915 manually rather than depending on hotplog/edid or some other way which I am missing. Regards Sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 2/3] drm/i915: check for return value
On Thu, Oct 08, 2015 at 04:29:31PM +0200, Daniel Vetter wrote: > On Thu, Oct 08, 2015 at 07:28:00PM +0530, Sudip Mukherjee wrote: > > We were not checking the return value of drm_encoder_init() which can > > fail. And if it fails then we will be working with an uninitialized > > encoder. > > > > Cc: Daniel Vetter <daniel.vet...@intel.com> > > Cc: Jani Nikula <jani.nik...@linux.intel.com> > > Signed-off-by: Sudip Mukherjee <su...@vectorindia.org> > > Queued for -next, thanks for the patch. > -Daniel Hi Daniel, It is still not there in linux-next. Still applies cleanly on next-20151209. regards sudip > > > --- > > > > Sent on 27/07/2015 > > > > drivers/gpu/drm/i915/intel_dp.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index 18bcfbe..2a8b47e 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -6174,8 +6174,9 @@ intel_dp_init(struct drm_device *dev, int output_reg, > > enum port port) > > intel_encoder = _dig_port->base; > > encoder = _encoder->base; > > > > - drm_encoder_init(dev, _encoder->base, _dp_enc_funcs, > > -DRM_MODE_ENCODER_TMDS); > > + if (drm_encoder_init(dev, _encoder->base, _dp_enc_funcs, > > +DRM_MODE_ENCODER_TMDS)) > > + goto err_encoder_init; > > > > intel_encoder->compute_config = intel_dp_compute_config; > > intel_encoder->disable = intel_disable_dp; > > @@ -6224,6 +6225,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, > > enum port port) > > > > err_init_connector: > > drm_encoder_cleanup(encoder); > > +err_encoder_init: > > kfree(intel_connector); > > err_connector_alloc: > > kfree(intel_dig_port); > > -- > > 1.9.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 1/3] drm/i915: use error path
Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Signed-off-by: Sudip Mukherjee <su...@vectorindia.org>
---
Sent on 27/07/2015
drivers/gpu/drm/i915/intel_dp.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8d34ca7..18bcfbe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6168,10 +6168,8 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
return;
intel_connector = intel_connector_alloc();
- if (!intel_connector) {
- kfree(intel_dig_port);
- return;
- }
+ if (!intel_connector)
+ goto err_connector_alloc;
intel_encoder = _dig_port->base;
encoder = _encoder->base;
@@ -6219,11 +6217,18 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
dev_priv->hotplug.irq_port[port] = intel_dig_port;
- if (!intel_dp_init_connector(intel_dig_port, intel_connector)) {
- drm_encoder_cleanup(encoder);
- kfree(intel_dig_port);
- kfree(intel_connector);
- }
+ if (!intel_dp_init_connector(intel_dig_port, intel_connector))
+ goto err_init_connector;
+
+ return;
+
+err_init_connector:
+ drm_encoder_cleanup(encoder);
+ kfree(intel_connector);
+err_connector_alloc:
+ kfree(intel_dig_port);
+
+ return;
}
void intel_dp_mst_suspend(struct drm_device *dev)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND 2/3] drm/i915: check for return value
We were not checking the return value of drm_encoder_init() which can fail. And if it fails then we will be working with an uninitialized encoder. Cc: Daniel Vetter <daniel.vet...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> Signed-off-by: Sudip Mukherjee <su...@vectorindia.org> --- Sent on 27/07/2015 drivers/gpu/drm/i915/intel_dp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 18bcfbe..2a8b47e 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -6174,8 +6174,9 @@ intel_dp_init(struct drm_device *dev, int output_reg, enum port port) intel_encoder = _dig_port->base; encoder = _encoder->base; - drm_encoder_init(dev, _encoder->base, _dp_enc_funcs, -DRM_MODE_ENCODER_TMDS); + if (drm_encoder_init(dev, _encoder->base, _dp_enc_funcs, +DRM_MODE_ENCODER_TMDS)) + goto err_encoder_init; intel_encoder->compute_config = intel_dp_compute_config; intel_encoder->disable = intel_disable_dp; @@ -6224,6 +6225,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, enum port port) err_init_connector: drm_encoder_cleanup(encoder); +err_encoder_init: kfree(intel_connector); err_connector_alloc: kfree(intel_dig_port); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: load driver even if debugfs fails
On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote: debugfs files are not necessary for the usual operation of the driver and the device. No need to check for the return values from the debugfs file creation. Even if one debugfs file fails to create we try with the next debugfs file and ultimately return success always so that the driver continues to load. cleanup will clean all the created debugfs files as the list of file that are created are maintained in minor-debugfs_list. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- A gentle ping. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: load driver even if debugfs fails
On Mon, Aug 03, 2015 at 12:54:33PM +0200, Daniel Vetter wrote: On Mon, Aug 03, 2015 at 02:56:42PM +0530, Sudip Mukherjee wrote: On Thu, Jul 23, 2015 at 07:36:12PM +0530, Sudip Mukherjee wrote: debugfs files are not necessary for the usual operation of the driver and the device. No need to check for the return values from the debugfs file creation. Even if one debugfs file fails to create we try with the next debugfs file and ultimately return success always so that the driver continues to load. Does this even happen? realistically - I don't think it can happen. Even if it happens then there will be more serious problem like memory crunch or filesystem problem and in those cases there is no point in continuing to load the driver. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: check for return value
We were not checking the return value of drm_encoder_init() which can fail. And if it fails then we will be working with an uninitialized encoder. Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- drivers/gpu/drm/i915/intel_dp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index c084bca..69946b7 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5870,8 +5870,9 @@ intel_dp_init(struct drm_device *dev, int output_reg, enum port port) intel_encoder = intel_dig_port-base; encoder = intel_encoder-base; - drm_encoder_init(dev, intel_encoder-base, intel_dp_enc_funcs, -DRM_MODE_ENCODER_TMDS); + if (drm_encoder_init(dev, intel_encoder-base, intel_dp_enc_funcs, +DRM_MODE_ENCODER_TMDS)) + goto err_encoder_init; intel_encoder-compute_config = intel_dp_compute_config; intel_encoder-disable = intel_disable_dp; @@ -5919,6 +5920,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, enum port port) err_init_connector: drm_encoder_cleanup(encoder); +err_encoder_init: kfree(intel_connector); err_connector_alloc: kfree(intel_dig_port); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: use error path
Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/gpu/drm/i915/intel_dp.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..c084bca 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5864,10 +5864,8 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
return;
intel_connector = intel_connector_alloc();
- if (!intel_connector) {
- kfree(intel_dig_port);
- return;
- }
+ if (!intel_connector)
+ goto err_connector_alloc;
intel_encoder = intel_dig_port-base;
encoder = intel_encoder-base;
@@ -5914,11 +5912,18 @@ intel_dp_init(struct drm_device *dev, int output_reg,
enum port port)
intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
dev_priv-hotplug.irq_port[port] = intel_dig_port;
- if (!intel_dp_init_connector(intel_dig_port, intel_connector)) {
- drm_encoder_cleanup(encoder);
- kfree(intel_dig_port);
- kfree(intel_connector);
- }
+ if (!intel_dp_init_connector(intel_dig_port, intel_connector))
+ goto err_init_connector;
+
+ return;
+
+err_init_connector:
+ drm_encoder_cleanup(encoder);
+ kfree(intel_connector);
+err_connector_alloc:
+ kfree(intel_dig_port);
+
+ return;
}
void intel_dp_mst_suspend(struct drm_device *dev)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: load driver even if debugfs fails
debugfs files are not necessary for the usual operation of the driver
and the device. No need to check for the return values from the debugfs
file creation. Even if one debugfs file fails to create we try with the
next debugfs file and ultimately return success always so that the
driver continues to load.
cleanup will clean all the created debugfs files as the list of file
that are created are maintained in minor-debugfs_list.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
v1 was drm/i915: add error path
drivers/gpu/drm/i915/i915_debugfs.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index caf1382..8b1a42a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5138,29 +5138,22 @@ void intel_display_crc_init(struct drm_device *dev)
int i915_debugfs_init(struct drm_minor *minor)
{
- int ret, i;
+ int i;
- ret = i915_forcewake_create(minor-debugfs_root, minor);
- if (ret)
- return ret;
+ i915_forcewake_create(minor-debugfs_root, minor);
- for (i = 0; i ARRAY_SIZE(i915_pipe_crc_data); i++) {
- ret = i915_pipe_crc_create(minor-debugfs_root, minor, i);
- if (ret)
- return ret;
- }
+ for (i = 0; i ARRAY_SIZE(i915_pipe_crc_data); i++)
+ i915_pipe_crc_create(minor-debugfs_root, minor, i);
- for (i = 0; i ARRAY_SIZE(i915_debugfs_files); i++) {
- ret = i915_debugfs_create(minor-debugfs_root, minor,
- i915_debugfs_files[i].name,
- i915_debugfs_files[i].fops);
- if (ret)
- return ret;
- }
+ for (i = 0; i ARRAY_SIZE(i915_debugfs_files); i++)
+ i915_debugfs_create(minor-debugfs_root, minor,
+ i915_debugfs_files[i].name,
+ i915_debugfs_files[i].fops);
+
+ drm_debugfs_create_files(i915_debugfs_list, I915_DEBUGFS_ENTRIES,
+minor-debugfs_root, minor);
- return drm_debugfs_create_files(i915_debugfs_list,
- I915_DEBUGFS_ENTRIES,
- minor-debugfs_root, minor);
+ return 0;
}
void i915_debugfs_cleanup(struct drm_minor *minor)
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add error path
If any of the debug file creation fails we were just returning the
error code to the drm layer. But the debug files that we created in the
process were not removed. And debugfs files are not automatically
cleaned up.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
Hi Daniel,
Whom should i keep Cc: for this patch? Original code was from 2009, then
more codes have been added and changed in it.
drivers/gpu/drm/i915/i915_debugfs.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index caf1382..24b04f9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5147,7 +5147,7 @@ int i915_debugfs_init(struct drm_minor *minor)
for (i = 0; i ARRAY_SIZE(i915_pipe_crc_data); i++) {
ret = i915_pipe_crc_create(minor-debugfs_root, minor, i);
if (ret)
- return ret;
+ goto err_pipe_crc;
}
for (i = 0; i ARRAY_SIZE(i915_debugfs_files); i++) {
@@ -5155,12 +5155,34 @@ int i915_debugfs_init(struct drm_minor *minor)
i915_debugfs_files[i].name,
i915_debugfs_files[i].fops);
if (ret)
- return ret;
+ goto err_debugfs;
}
return drm_debugfs_create_files(i915_debugfs_list,
I915_DEBUGFS_ENTRIES,
minor-debugfs_root, minor);
+
+err_debugfs:
+ while (--i = 0) {
+ struct drm_info_list *info_list =
+ (struct drm_info_list *)i915_debugfs_files[i].fops;
+
+ drm_debugfs_remove_files(info_list, 1, minor);
+ }
+
+err_pipe_crc:
+ if (i == -1)
+ i = ARRAY_SIZE(i915_pipe_crc_data);
+
+ while (--i = 0) {
+ struct drm_info_list *info_list =
+ (struct drm_info_list *)i915_pipe_crc_data[i];
+ drm_debugfs_remove_files(info_list, 1, minor);
+ }
+ drm_debugfs_remove_files((struct drm_info_list *)i915_forcewake_fops,
+1, minor);
+
+ return ret;
}
void i915_debugfs_cleanup(struct drm_minor *minor)
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add error path
On Wed, Jul 22, 2015 at 12:39:37PM +0100, Chris Wilson wrote: On Wed, Jul 22, 2015 at 04:58:47PM +0530, Sudip Mukherjee wrote: If any of the debug file creation fails we were just returning the error code to the drm layer. But the debug files that we created in the process were not removed. And debugfs files are not automatically cleaned up. Just handle the failure to add gracefully by only removing the ones we add during debugfs cleanup. One thing we do not actually want to do here is return an error - not setting up every file in debugfs shouldn't stop the driver from loading. Ok, I will send the v2 day after tomorrow. Today and tomorrow I will horribly busy in my dayjob. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: remove unnecessary null test
On Mon, Jul 20, 2015 at 05:33:50PM +0200, Daniel Vetter wrote: On Mon, Jul 20, 2015 at 08:36:01PM +0530, Sudip Mukherjee wrote: While creating the debugfs file we are setting the inode-i_private to dev. That same dev is passed to these functions as private of struct seq_file via single_open(). So at this point it can never be NULL. Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- v1 was drm/i915: fix possible null pointer dereference There's still one left in i915_displayport_test_active_write. I left it out intentionally as it was not used via single_open(). Will include that and send v3. Also please mention the commit that introduced these and Cc: the author. Also please Cc: Chris since he's commented on v1 of this patch. sure, Chris was Cc: in v2 and will Cc: him in v3 also. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915: remove redundant if check
The extra check for connector_type is not required as we are already
checking for connector_type != DRM_MODE_CONNECTOR_DisplayPort.
The check was added by commit eb3394faeb97 (drm/i915: Add debugfs test
control files for Displayport compliance testing)
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
v3: It is new. Submitting together in a series as the changes are in the
same part of the code.
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ffce62e..caf1382 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4059,9 +4059,7 @@ static ssize_t i915_displayport_test_active_write(struct
file *file,
DRM_MODE_CONNECTOR_DisplayPort)
continue;
- if (connector-connector_type ==
- DRM_MODE_CONNECTOR_DisplayPort
- connector-status == connector_status_connected
+ if (connector-status == connector_status_connected
connector-encoder != NULL) {
intel_dp = enc_to_intel_dp(connector-encoder);
status = kstrtoint(input_buffer, 10, val);
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915: remove unnecessary null test
While creating the debugfs file we are setting the inode-i_private to
dev. That same dev is passed to these functions as private of struct
seq_file via single_open(). Moreover single_open is setting
file-private_data-private to dev.
So at this point it can never be NULL.
This check was added by commit eb3394faeb97 (drm/i915: Add debugfs test
control files for Displayport compliance testing)
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
v3: removed the check in i915_displayport_test_active_write also
v2: removed null check
v1 was drm/i915: fix possible null pointer dereference
drivers/gpu/drm/i915/i915_debugfs.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bc817da..ffce62e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4028,24 +4028,14 @@ static ssize_t
i915_displayport_test_active_write(struct file *file,
{
char *input_buffer;
int status = 0;
- struct seq_file *m;
struct drm_device *dev;
struct drm_connector *connector;
struct list_head *connector_list;
struct intel_dp *intel_dp;
int val = 0;
- m = file-private_data;
- if (!m) {
- status = -ENODEV;
- return status;
- }
- dev = m-private;
+ dev = ((struct seq_file *)file-private_data)-private;
- if (!dev) {
- status = -ENODEV;
- return status;
- }
connector_list = dev-mode_config.connector_list;
if (len == 0)
@@ -4103,9 +4093,6 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
struct list_head *connector_list = dev-mode_config.connector_list;
struct intel_dp *intel_dp;
- if (!dev)
- return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
@@ -4150,9 +4137,6 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
struct list_head *connector_list = dev-mode_config.connector_list;
struct intel_dp *intel_dp;
- if (!dev)
- return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
@@ -4192,9 +4176,6 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
struct list_head *connector_list = dev-mode_config.connector_list;
struct intel_dp *intel_dp;
- if (!dev)
- return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: remove unnecessary null test
On Tue, Jul 21, 2015 at 03:51:40PM +0200, Daniel Vetter wrote: On Tue, Jul 21, 2015 at 05:36:45PM +0530, Sudip Mukherjee wrote: While creating the debugfs file we are setting the inode-i_private to dev. That same dev is passed to these functions as private of struct seq_file via single_open(). Moreover single_open is setting file-private_data-private to dev. So at this point it can never be NULL. This check was added by commit eb3394faeb97 (drm/i915: Add debugfs test control files for Displayport compliance testing) Still missing Cc: Chris Wilson ... Cc: Todd Previte ... here to make sure reviewers/original authors are in the loop. Anyway this is a simple enough patch, so I just pulled them both in. Sorry. did you mean to put Cc: here before the Signed-off-by: ? I have put them in Cc list of the patches. For my next patch you will not get these issues. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix possible null pointer dereference
We were dereferencing dev first and then checking if it is NULL. Lets
check for NULL first and then dereference.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bc817da..f316e49 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4100,12 +4100,13 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
{
struct drm_device *dev = m-private;
struct drm_connector *connector;
- struct list_head *connector_list = dev-mode_config.connector_list;
+ struct list_head *connector_list;
struct intel_dp *intel_dp;
if (!dev)
return -ENODEV;
+ connector_list = dev-mode_config.connector_list;
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix possible null pointer dereference
On Mon, Jul 20, 2015 at 01:38:46PM +0100, Chris Wilson wrote: On Mon, Jul 20, 2015 at 05:59:29PM +0530, Sudip Mukherjee wrote: We were dereferencing dev first and then checking if it is NULL. Lets check for NULL first and then dereference. The code is bonkers. Testing for a lack of a correctly constructed debugfs seq_file inside the debugfs seq_file callback is inane. I missed seeing before sending this patch that there are some more places where this has been done. Then are you suggesting to remove the test? regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: remove unnecessary null test
While creating the debugfs file we are setting the inode-i_private to
dev. That same dev is passed to these functions as private of struct
seq_file via single_open(). So at this point it can never be NULL.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
v1 was drm/i915: fix possible null pointer dereference
drivers/gpu/drm/i915/i915_debugfs.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bc817da..63cb886 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4103,9 +4103,6 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
struct list_head *connector_list = dev-mode_config.connector_list;
struct intel_dp *intel_dp;
- if (!dev)
- return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
@@ -4150,9 +4147,6 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
struct list_head *connector_list = dev-mode_config.connector_list;
struct intel_dp *intel_dp;
- if (!dev)
- return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
@@ -4192,9 +4186,6 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
struct list_head *connector_list = dev-mode_config.connector_list;
struct intel_dp *intel_dp;
- if (!dev)
- return -ENODEV;
-
list_for_each_entry(connector, connector_list, head) {
if (connector-connector_type !=
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG/REGRESSION] Screen flickering
On Wed, May 13, 2015 at 01:27:06PM +0200, Thomas Gummerer wrote: Sudip Mukherjee sudipm.mukher...@gmail.com writes: On Wed, May 13, 2015 at 11:53:19AM +0200, Jan Niehusmann wrote: http://patchwork.freedesktop.org/patch/46071/ Thank you for the pointer, but this seems to be an unrelated issue. I tried applying the patch, but it doesn't fix the issues that I'm experiencing. thanks for confirming. I am out of this thread now :) regards sudip regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG/REGRESSION] Screen flickering
On Wed, May 13, 2015 at 01:10:11PM +0200, Jan Niehusmann wrote: On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote: What I'm missing in the report, are some log entries I'm seeing on my notebook: Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun hi, I also have the similar entries in my dmesg, though my problem is a little different from yours and my bisect lead to another commit. And that also is still not fixed (last tested with 4.0). (Please note that I didn't do a bisect - that was Thomas. I only noted that I can confirm his observations and that his patch helps to prevent or hide the issue.) Perhaps these are two completely unrelated issues? yes, maybe unrelated issue. since I am also having similar errors in dmesg and also having a similar type of problem so replied here. regards sudip Jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert drm/i915: Performed deferred clflush inside set-cache-level
On Wed, Apr 01, 2015 at 10:01:50AM +0530, Sudip Mukherjee wrote: On Tue, Mar 31, 2015 at 04:35:49PM +0100, Chris Wilson wrote: On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote: This reverts commit 0f71979ab7fbd0c71c41c2798de3d33937915434. my display was getting garbled for a moment very frequently. it looked like when the screen was getting refreshed then something was going wrong. git bisect gave this as the first bad commit, and after reverting it now display is not having that problem. Hmm, I fear you would be just papering over a bug. Could you please file a bug on bugs.freedesktop.org so that we can root cause this? -Chris filed at https://bugs.freedesktop.org/show_bug.cgi?id=89857 since this patch workes perfectly for me, i guess i need to apply it to every new release till you are able to root cause and fix it. I am having the same problem with v4.0 also. Though I guess there is some improvement as now the problem is not appearing as frequently as it used to be. And reverting the patch again completely removed the problem. regards sudip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert drm/i915: Performed deferred clflush inside set-cache-level
On Tue, Mar 31, 2015 at 04:35:49PM +0100, Chris Wilson wrote: On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote: This reverts commit 0f71979ab7fbd0c71c41c2798de3d33937915434. my display was getting garbled for a moment very frequently. it looked like when the screen was getting refreshed then something was going wrong. git bisect gave this as the first bad commit, and after reverting it now display is not having that problem. Hmm, I fear you would be just papering over a bug. Could you please file a bug on bugs.freedesktop.org so that we can root cause this? -Chris filed at https://bugs.freedesktop.org/show_bug.cgi?id=89857 since this patch workes perfectly for me, i guess i need to apply it to every new release till you are able to root cause and fix it. regards sudip -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert drm/i915: Performed deferred clflush inside set-cache-level
This reverts commit 0f71979ab7fbd0c71c41c2798de3d33937915434.
my display was getting garbled for a moment very frequently. it looked
like when the screen was getting refreshed then something was going
wrong.
git bisect gave this as the first bad commit, and after reverting it
now display is not having that problem.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
my system is x86_64.
lspci -k gives:
VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor Graphics Controller (rev 09)
Subsystem: Foxconn International, Inc. Device 0d74
Kernel driver in use: i915
This is my bisect log:
# bad: [e42391cd048809d903291d07f86ed3934ce138e9] Linux 4.0-rc6
# good: [b7392d2247cfe6771f95d256374f1a8e6a6f48d6] Linux 3.19-rc2
git bisect start 'v4.0-rc6' 'v3.19-rc2' '--' 'drivers/gpu/drm/i915/'
# good: [d2182a660808d9053a605e3ebc8c46a323ec6e5d] drm/i915: Don't register
HDMI connectors for eDP ports on VLV/CHV
git bisect good d2182a660808d9053a605e3ebc8c46a323ec6e5d
# bad: [36d21f4c557a2b18ed7c9d254060d4ca07a6c5c7] drm/i915/dsi: remove
unnecessary dsi device callbacks
git bisect bad 36d21f4c557a2b18ed7c9d254060d4ca07a6c5c7
# good: [72f95afa5faaf899f7344879b6ccd5f0cb271b28] drm/i915: Removed duplicate
members from submit_request
git bisect good 72f95afa5faaf899f7344879b6ccd5f0cb271b28
# good: [2844a9214759901f382086644842e39ad6f7d894] drm/i915: Use pipe_name() in
the get_plane_config() functions
git bisect good 2844a9214759901f382086644842e39ad6f7d894
# bad: [1b842c89bd8eb0e9619e1aba071c9a5529b7a179] drm/i915: Fix kzalloc()
smatch warnings in get_initial_plane_config()
git bisect bad 1b842c89bd8eb0e9619e1aba071c9a5529b7a179
# good: [8d360dffd6d8634868e433128d5178bea14cc42c] drm/i915: Specify bsd rings
through exec flag
git bisect good 8d360dffd6d8634868e433128d5178bea14cc42c
# good: [1197b4f230fb7c8fe3a9b549596fe130b09a0db2] drm/i915: Balance context
pinning on reset cleanup
git bisect good 1197b4f230fb7c8fe3a9b549596fe130b09a0db2
# bad: [0f71979ab7fbd0c71c41c2798de3d33937915434] drm/i915: Performed deferred
clflush inside set-cache-level
git bisect bad 0f71979ab7fbd0c71c41c2798de3d33937915434
# good: [a7cbedec8317a5cacecb567674fdbc1c3fb22de8] drm/i915: Rename unpin_count
to pin_count
git bisect good a7cbedec8317a5cacecb567674fdbc1c3fb22de8
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 31 ++-
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..abe6c16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2054,7 +2054,6 @@ struct drm_i915_gem_object {
*/
unsigned long gt_ro:1;
unsigned int cache_level:3;
- unsigned int cache_dirty:1;
unsigned int has_dma_mapping:1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 27ea6bd..e9341e9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3647,14 +3647,11 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj,
* snooping behaviour occurs naturally as the result of our domain
* tracking.
*/
- if (!force cpu_cache_is_coherent(obj-base.dev, obj-cache_level)) {
- obj-cache_dirty = true;
+ if (!force cpu_cache_is_coherent(obj-base.dev, obj-cache_level))
return false;
- }
trace_i915_gem_object_clflush(obj);
drm_clflush_sg(obj-pages);
- obj-cache_dirty = false;
return true;
}
@@ -3836,11 +3833,27 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
vma-node.color = cache_level;
obj-cache_level = cache_level;
- if (obj-cache_dirty
- obj-base.write_domain != I915_GEM_DOMAIN_CPU
- cpu_write_needs_clflush(obj)) {
- if (i915_gem_clflush_object(obj, true))
- i915_gem_chipset_flush(obj-base.dev);
+ if (cpu_write_needs_clflush(obj)) {
+ u32 old_read_domains, old_write_domain;
+
+ /* If we're coming from LLC cached, then we haven't
+* actually been tracking whether the data is in the
+* CPU cache or not, since we only allow one bit set
+* in obj-write_domain and have been skipping the clflushes.
+* Just set it to the CPU cache for now.
+*/
+ i915_gem_object_retire(obj);
+ WARN_ON(obj-base.write_domain ~I915_GEM_DOMAIN_CPU);
+
+ old_read_domains = obj-base.read_domains;
+ old_write_domain = obj-base.write_domain;
+
+ obj-base.read_domains = I915_GEM_DOMAIN_CPU;
+ obj-base.write_domain = I915_GEM_DOMAIN_CPU;
+
+ trace_i915_gem_object_change_domain(obj,
+ old_read_domains
Re: [Intel-gfx] WARNING: at drivers/gpu/drm/i915/intel_display.c:11375 [i915] in 3.19-rc2
On Thu, Jan 01, 2015 at 05:22:15PM +0300, Andrey Skvortsov wrote: Hi, this warning does not exist in 3.19-rc1, but it happens every boot in 3.19-rc2. If you need any other information or data, I would be glad to help to debug it. mine is also i915, but i am not seeing any warning. if you send me your .config, then i can try booting using that. the current kernel version is : 3.19.0-rc2-next-20141231+ thanks sudip [ 12.848428] [ cut here ] [ 12.848479] WARNING: CPU: 1 PID: 328 at drivers/gpu/drm/i915/intel_display.c:11375 intel_crtc_set_config+0x3de/0xb36 [i915]() [ 12.848649] ---[ end trace da6972fb56a05968 ]--- -- Best regards, Andrey Skvortsov Secure e-mail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
