Re: [Intel-gfx] [PATCH v2 11/14] HID: picoLCD: constify fb ops
On Thu, 5 Dec 2019, Jani Nikula wrote:
> >> Now that the fbops member of struct fb_info is const, we can start
> >> making the ops const as well.
> >>
> >> v2: fixtypo (Christophe de Dinechin)
> >
> > Fine with me.
> > I don't think going through drm-misc would trigger any conflict, but
> > adding Jiri to CC for the case there was any preference.
> >
> > Acked-by: Bruno Prémont
>
> No response, may I proceed with merging this through drm-misc please?
I have been off the grid the past week, sorry for belated response. Feel
free to add
Acked-by: Jiri Kosina
and take it through your tree.
--
Jiri Kosina
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)
On Sat, 30 Dec 2017, Jiri Kosina wrote: > Seems like disabling RC6 on the kernel command line works this around, and > I can dock / undock several times in a row with the image always coming > up properly on the external display. > > On the first undock, the WARN_ONCE() below triggers, so I believe each > undock leaks memory. > > [ 38.755084] Failed to release pages: bind_count=1, pages_pin_count=1, > pin_global=0 > [ 38.755138] WARNING: CPU: 3 PID: 96 at > ../drivers/gpu/drm/i915/i915_gem_userptr.c:89 cancel_userptr+0xe5/0xf0 [i915] OK, I am seeing this warning with current Linus' tree (5aa90a845) even without any attempt to dock/undock, so it's probably unrelated to external outputs and it only by coincidence appeared originally at the same time I docked the machine. So there are two separate issues on this machine with latest kernel (neither of them probably being regression): - I have to disable i915 RC6 at the kernel cmdline, otherwise external (dock) display gets output only randomly (seems like always only on first dock) - the warning, which triggers at not really deterministic time after boot, but usually rather quickly -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)
On Fri, 29 Dec 2017, Jiri Kosina wrote: > When I dock my thinkpad x270 [1] and run xrandr --auto, image correctly > appears on external display. > > After undocking and docking again, the image on external display doesn't > appear any more, and this pops up in dmesg > > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B > FIFO underrun > > After restarting X (no need to reboot), I am able to dock again and get > image on external display. > > I don't think this is a regression, I tried a few older kernels up to > something around 4.11, and nothing worked. > > In case any more information is needed to debug this, please let me know, > I'll happily provide it. Seems like disabling RC6 on the kernel command line works this around, and I can dock / undock several times in a row with the image always coming up properly on the external display. On the first undock, the WARN_ONCE() below triggers, so I believe each undock leaks memory. [ 38.755084] Failed to release pages: bind_count=1, pages_pin_count=1, pin_global=0 [ 38.755138] WARNING: CPU: 3 PID: 96 at ../drivers/gpu/drm/i915/i915_gem_userptr.c:89 cancel_userptr+0xe5/0xf0 [i915] [ 38.755140] Modules linked in: ccm fuse af_packet tun ip6table_mangle nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_mangle xt_DSCP xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c bnep iptable_filter ip_tables x_tables msr dm_crypt algif_skcipher af_alg uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev btusb btrtl btbcm btintel bluetooth ecdh_generic snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_soc_acpi snd_soc_core snd_compress snd_pcm_dmaengine arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc nls_iso8859_1 nls_cp437 [ 38.755167] vfat fat iwlmvm iTCO_wdt iTCO_vendor_support wmi_bmof intel_wmi_thunderbolt mac80211 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer aesni_intel aes_x86_64 crypto_simd glue_helper cryptd thinkpad_acpi iwlwifi snd e1000e rtsx_pci_ms cfg80211 ptp memstick joydev mei_me soundcore i2c_i801 tpm_crb pps_core shpchp pcspkr intel_pch_thermal wmi thermal rfkill mei battery ac tpm_tis tpm_tis_core tpm acpi_pad rtsx_pci_sdmmc mmc_core xhci_pci serio_raw xhci_hcd i915 video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops rtsx_pci usbcore button drm sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 38.755198] CPU: 3 PID: 96 Comm: kworker/u8:1 Tainted: G U 4.15.0-rc5-1.g9fcc9f1-default #1 [ 38.755199] Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 [ 38.755228] Workqueue: i915-userptr-release cancel_userptr [i915] [ 38.755245] RIP: 0010:cancel_userptr+0xe5/0xf0 [i915] [ 38.755246] RSP: 0018:b92e41073e80 EFLAGS: 00010282 [ 38.755248] RAX: 0046 RBX: 9d0d742a4600 RCX: 0006 [ 38.755249] RDX: 0007 RSI: 0086 RDI: 9d0daf58f190 [ 38.755250] RBP: 9d0d742a47a8 R08: R09: 0334 [ 38.755251] R10: R11: 992d6aed R12: [ 38.755252] R13: R14: 09d0d07c1c70 R15: 9d0da3d58540 [ 38.755254] FS: () GS:9d0daf58() knlGS: [ 38.755255] CS: 0010 DS: ES: CR0: 80050033 [ 38.755256] CR2: 7ff861a41c38 CR3: 00017cc09004 CR4: 003606e0 [ 38.755257] Call Trace: [ 38.755264] process_one_work+0x1de/0x410 [ 38.755267] worker_thread+0x2b/0x3d0 [ 38.755269] ? process_one_work+0x410/0x410 [ 38.755270] kthread+0x111/0x130 [ 38.755272] ? kthread_create_worker_on_cpu+0x50/0x50 [ 38.755275] ret_from_fork+0x24/0x30 [ 38.755277] Code: 92 4f ff ff eb c4 8b 93 c8 01 00 00 8b 8b a4 01 00 00 48 c7 c7 70 25 5e c0 8b b3 9c 01 00 00 c6 05 84 d5 14 00 01 e8 6b f9 b6 d7 <0f> ff eb b7 0f 1f 80 00 00 00 00 0f 1f 44 00 00 41 57 41 56 ba -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)
On Fri, 29 Dec 2017, Jiri Kosina wrote: > When I dock my thinkpad x270 [1] and run xrandr --auto, image correctly > appears on external display. > [1] 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07) > After undocking and docking again, the image on external display doesn't > appear any more, and this pops up in dmesg > > [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B > FIFO underrun > > After restarting X (no need to reboot), I am able to dock again and get > image on external display. > > I don't think this is a regression, I tried a few older kernels up to > something around 4.11, and nothing worked. Forgot to mention: I'm observing this on (and up to) 4.15-rc5 Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)
When I dock my thinkpad x270 [1] and run xrandr --auto, image correctly appears on external display. After undocking and docking again, the image on external display doesn't appear any more, and this pops up in dmesg [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun After restarting X (no need to reboot), I am able to dock again and get image on external display. I don't think this is a regression, I tried a few older kernels up to something around 4.11, and nothing worked. In case any more information is needed to debug this, please let me know, I'll happily provide it. Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/16] drm/i915: Reinstate GMBUS and AUX interrupts on gen4/g4x
On Fri, 18 Aug 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> Now that we're not using MSI anymore on gen4 we can start
> using GMBUS and AUX interrupts again. These were disable on
> account of them causing the hardware to somehow generate
> legacy interrupts even when MSI was enabled.
>
> See commit c12aba5aa0e6 ("drm/i915: stop using GMBUS IRQs on Gen4
> chips") and commit 4e6b788c3f23 ("drm/i915: Disable dp aux irq on
> g4x") for more details.
I unfortunately don't have the HW where I used to reproduce the spurious
IRQs any more. It was thinkpad x200s, 7470-BN2 model.
--
Jiri Kosina
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Paper over locking inversion after registration rework
On Thu, 4 Aug 2016, Daniel Vetter wrote:
> drm_connector_register_all requires a few too many locks because our
> connector_list locking is busted. Add another FIXME+hack to work
> around this. This should address the below lockdep splat:
[ ... snip ... ]
> v2: Rebase onto the right branch (hand-editing patches ftw) and add more
> reporters.
>
> Reported-by: Imre Deak <imre.d...@intel.com>
> Cc: Imre Deak <imre.d...@intel.com>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Acked-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Reported-by: Jiri Kosina <ji...@kernel.org>
Although I have no idea why this is safe thing to do :) I can confirm that
it removes the lockdep complaint on my system. So in that regard,
Tested-by: Jiri Kosina <jkos...@suse.cz>
Thanks,
--
Jiri Kosina
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] backlight: Avoid double fbcon backlight handling
On Thu, 30 Jun 2016, Chris Wilson wrote:
> Backlights controlled by i915.ko and only associated with its connectors
> and also only associated with the intel_drmfb fbcon, controlled by
> i915.ko. In this situation, we already handle adjusting the backlight
> when the fbcon is blanked/unblanked and do not require backlight trying
> to do the same.
>
> Attempting to register with the fbdev as a client causes lockdep to warn
> about a dependency cycle:
[ ... snip ... ]
> drivers/hid/hid-picolcd_backlight.c | 3 ++-
For this one:
Acked-by: Jiri Kosina <jkos...@suse.cz>
--
Jiri Kosina
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X
On Thu, 7 Apr 2016, Bjørn Mork wrote: > > after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on > > thinkpad x200s notebook with > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series > > Chipset Integrated Graphics Controller (rev 07) > > > > closing and opening the lid freezes the computer completely (after opening > > the LID, I can see either the complete original contents of the screen, or > > silouhette of xscreensaver window decorations, but the machine is dead by > > then (neither ctrl-alt-backspace-backspace nor switching to text console > > doesn't work). > > > > It definitely worked with older kernels, but I unfortunately don't have > > all the data needed for bisection, as the old kernels have been wiped off > > the machine in the meantime. > > > > Is this a known issue? > > Yup. Fix is queued: https://lkml.org/lkml/2016/3/30/151 Excellent. FWIW Tested-by: Jiri Kosina <jkos...@suse.cz> > Good to see that I'm not the only one running rc's on ancient laptops :) Indeed many i915 Gen4 bugs have been discovered on this particular notebook. I like it, there is no way I am getting rid of it :) Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X
Hi, after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on thinkpad x200s notebook with 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) closing and opening the lid freezes the computer completely (after opening the LID, I can see either the complete original contents of the screen, or silouhette of xscreensaver window decorations, but the machine is dead by then (neither ctrl-alt-backspace-backspace nor switching to text console doesn't work). It definitely worked with older kernels, but I unfortunately don't have all the data needed for bisection, as the old kernels have been wiped off the machine in the meantime. Is this a known issue? Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
constants, dotclock = 0! [55787.948272] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! [82084.602344] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! This is mostly around suspend/resume cycles, but there are exceptions, for example the ones between 25220.245033 and 47064.983235 are contiguous and don't contain any other message in between (i.e. no suspend/resume happening either). Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
Hi, since I've updated on my thinkpad x200s to latest Linus' tree (3235031), I am getting a lot of [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! googling revealed this patch: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/67471 is there any reason why it's not present upstream? Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm/i915/3.17] panic in i915_digport_work_func
On Mon, 1 Sep 2014, Daniel Vetter wrote: From d407c946fbf5c48f30160591f5bd71fbe158aeb4 Mon Sep 17 00:00:00 2001 From: Dave Airlie airl...@redhat.com Date: Mon, 1 Sep 2014 16:58:12 +1000 Subject: [PATCH] drm/i915: handle G45/GM45 pulse detection connected state. In the HPD pulse handler we check for long pulses if the port is actually connected, however we do that for IBX, but we use the pulse handling code on GM45 systems as well, so we need to use a diffent check. This patch refactors the digital port connected check out of the g4x detection path and reuses it in the hpd pulse path. Should fix: Message-ID: 1409382202.5141.36.ca...@marge.simpson.net Reported-by: Mike Galbraith umgwanakikb...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch I was just about to start bisecting, as my thinkpad x200s with Gen4 chip wouldn't ocassionally boot with -rc3, but this patch seems to be the cure for me as well. FWIW Tested-by: Jiri Kosina jkos...@suse.cz -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-intel-fixes
On Fri, 8 Aug 2014, Daniel Vetter wrote: Big fix is the duct-tape for ring init on g4x platforms, we seem to have found the magic again to make those machines as happy as before (not perfect though unfortunately, but that was never the case). I unfortunately don't agree with the last part; there are older kernels (such as 3.7) where I have never ever seen this ring initialization failure, despite it being excercised very heavily (hundreds of suspend/resume cycles on the machine I am debugging this problem on). As I said in the bugzilla already, the affected machine will be physically present in my bag at the Kernel Summit, in case it helps you guys from Intel to debug it. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc: regression in suspend
On Fri, 11 Jul 2014, Pavel Machek wrote: Ok, so I have set up machines for ktest / autobisect, and found out that 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun, anyway... I am still seeing the problem with 3.16-rc2. I'm confused now. Is the bisect result commit 773875bfb6737982903c42d1ee88cf60af80089c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Mon Jan 27 10:00:30 2014 +0100 drm/i915: Don't set the 8to6 dither flag when not scaling now the culprit or not? Or do we have 2 different bugs at hand here? Three different issues, it seems. Two ring initialization problems, one went away in 3.16 (for me), second did not (suspend for jikos), third -- trivial issue with 8to6 dither. The patch below seems to finally cure the problem at my system; I've just attached it to freedesktop bugzilla, but sending it to this thread as well to hopefully get as much testing coverage by affected people as possible. I am going on with testing whether it really completely fixes the problem or just made it less likely. From: Jiri Kosina jkos...@suse.cz Subject: [PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce ordering Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ff8804 tail start 000e4000 Signed-off-by: Jiri Kosina jkos...@suse.cz --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 279488a..7add7ee 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -517,6 +517,9 @@ static int init_ring_common(struct intel_engine_cs *ring) else ring_setup_phys_status_page(ring); + /* Enforce ordering by reading HEAD register back */ + I915_READ_HEAD(ring); + /* Initialize the ring. This must happen _after_ we've cleared the ring * registers with the above sequence (the readback of the HEAD registers * also enforces ordering), otherwise the hw might lose the new ring -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc: regression in suspend
On Thu, 7 Aug 2014, Jiri Kosina wrote: The patch below seems to finally cure the problem at my system; I've just attached it to freedesktop bugzilla, but sending it to this thread as well to hopefully get as much testing coverage by affected people as possible. I am going on with testing whether it really completely fixes the problem or just made it less likely. Okay, after 31 suspend-resume cycles, the problem appeared again (while without the patch, it triggers with 100% reliability). So it's not a complete fix, it just makes the problem much less visible. Going back to bugzilla discussion. From: Jiri Kosina jkos...@suse.cz Subject: [PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce ordering Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ff8804 tail start 000e4000 Signed-off-by: Jiri Kosina jkos...@suse.cz --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 279488a..7add7ee 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -517,6 +517,9 @@ static int init_ring_common(struct intel_engine_cs *ring) else ring_setup_phys_status_page(ring); + /* Enforce ordering by reading HEAD register back */ + I915_READ_HEAD(ring); + /* Initialize the ring. This must happen _after_ we've cleared the ring * registers with the above sequence (the readback of the HEAD registers * also enforces ordering), otherwise the hw might lose the new ring -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce ordering
Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ff8804 tail start 000e4000 This is not a complete fix, but it is verified to make the ring initialization failures during resume much less likely. We were not able to root-cause this bug (likely HW-specific to Gen4 chips) yet. This is therefore used as a ducttape before problem is fully understood and proper fix created, so that people don't suffer from completely unusable systems in the meantime. The discussion and debugging is happening at https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Jiri Kosina jkos...@suse.cz --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 279488a..7add7ee 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -517,6 +517,9 @@ static int init_ring_common(struct intel_engine_cs *ring) else ring_setup_phys_status_page(ring); + /* Enforce ordering by reading HEAD register back */ + I915_READ_HEAD(ring); + /* Initialize the ring. This must happen _after_ we've cleared the ring * registers with the above sequence (the readback of the HEAD registers * also enforces ordering), otherwise the hw might lose the new ring -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc: regression in suspend
On Fri, 11 Jul 2014, Pavel Machek wrote: Ok, so I have set up machines for ktest / autobisect, and found out that 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun, anyway... I am still seeing the problem with 3.16-rc2. I'm confused now. Is the bisect result commit 773875bfb6737982903c42d1ee88cf60af80089c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Mon Jan 27 10:00:30 2014 +0100 drm/i915: Don't set the 8to6 dither flag when not scaling now the culprit or not? Or do we have 2 different bugs at hand here? Three different issues, it seems. Two ring initialization problems, one went away in 3.16 (for me), second did not (suspend for jikos), third -- trivial issue with 8to6 dither. That's correct assesment. The ring initialization failure I reported is still there. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.16-rc2
On Tue, 8 Jul 2014, Chris Wilson wrote: I actually tried to introduce rather large delays between individual I915_WRITE() calls in the ring initialization sequence a couple weeks ago already, but it resulted in complete machine lockup (which is worse than my usual symptoms) during resume. Therefore I probably lack the knowledge of internal workings of the HW that would allow me to guess what the reasonable timeout value should be. Willing to test any patches. Are you using the extra patches on bug 76554? If not, try Just for debugging. diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index e18ed05dc0d5..48326f9628d4 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -526,6 +526,9 @@ static int init_ring_common(struct intel_engine_cs *ring) ((ringbuf-size - PAGE_SIZE) RING_NR_PAGES) | RING_VALID); + I915_WRITE_HEAD(ring, 0); + (void)I915_READ_HEAD(ring); + /* If the head is still not zero, the ring is dead */ if (wait_for((I915_READ_CTL(ring) RING_VALID) != 0 I915_READ_START(ring) == i915_gem_obj_ggtt_offset(obj) Tried on top of current Linus' tree, and no improvement. ring initialization failure upon resume, and window redrawing hosed. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.16-rc2
On Tue, 8 Jul 2014, Chris Wilson wrote: Tried on top of current Linus' tree, and no improvement. ring initialization failure upon resume, and window redrawing hosed. Which error during ring-init are you hitting? It's still the same I reported in bugs.freedesktop.org/show_bug.cgi?id=76554 [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 (valid? 1) head 000f645c tail start 000e4000 [expected 000e4000] [drm:__i915_drm_thaw] *ERROR* failed to re-initialize GPU, declaring wedged! -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.16-rc2
On Mon, 7 Jul 2014, Daniel Vetter wrote: this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram regression go away on my machine: Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts? For the record, commenting out the code in stop_ring() the way Thomas did doesn't fix my problem (the one reported in [1]). [1] https://bugs.freedesktop.org/show_bug.cgi?id=76554 -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.16-rc2
On Mon, 7 Jul 2014, Chris Wilson wrote: this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram regression go away on my machine: Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts? As different machines favour different w/a, I think the issue is mostly timing related. It could be sequence of register writes, but we tried different orders early on. The next experiment I guess would be to insert small delays between each write to see if that helps. Or to write each register twice. I actually tried to introduce rather large delays between individual I915_WRITE() calls in the ring initialization sequence a couple weeks ago already, but it resulted in complete machine lockup (which is worse than my usual symptoms) during resume. Therefore I probably lack the knowledge of internal workings of the HW that would allow me to guess what the reasonable timeout value should be. Willing to test any patches. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc: regression in suspend
On Thu, 26 Jun 2014, Pavel Machek wrote: Ok, so I have set up machines for ktest / autobisect, and found out that 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun, anyway... I am still seeing the problem with 3.16-rc2. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc: regression in suspend
On Mon, 9 Jun 2014, Pavel Machek wrote: Strange. It seems 3.15 with the patch reverted only boots in 30% or so cases... And I've seen resume failure, too, so maybe I was just lucky that it worked for a while. git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about the 5th report or so that claims this is the culprit but it's something else. The above code is definitely not used in i915 so bogus bisect result. Note I did not do the bisect, I only attempted revert and test. And did three boots of successful s2ram.. only to find out that it does not really fix s2ram, I was just lucky :-(. Unfortunately, this means my s2ram problem will be tricky/impossible to bisect :-(. Welcome to the situation I have been in for past several months. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X
On Thu, 24 Apr 2014, Pavel Machek wrote: [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 2034 tail start 0012f000 Jiri has been seeing a similar issue creep in during resume, but it is not reliable enough to bisect. Is your boot failure reliable enough to bisect? Also drm-intel-nightly should mitigate this failure and allow i915.ko to continue to load and run X, which would be worth testing to make sure that works as intended. Oh right, g4x going beserk :( Apparently something changed in 3.15 somewhere which made this much more likely, but like Chris said in Jiri's case it's too unreliable to reproduce for a bisect. We've had this comego pretty much ever since kms support was merged and never tracked it down. So far I went back to 3.14, and yes, graphics works there. Back to 3.15, put it to smaller monitor. This time, top 30% of screen works, and last working scanline is copied to the rest 60% of screen. [With the exception of mouse cursor, that somehow affects that magically.] The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554 Like Chris said please test latest drm-intel-nighlty from http://cgit.freedesktop.org/drm-intel to make sure that the recently merged mitigation measures work properly. But those won't get your gpu back, only the display and it's only for 3.16. We're still hunting a proper fix for 3.15. So you know where the bug is or not? No, but there is a workaround for cases kernel finds out that it cannot execute GPU commands (because the rings failed to initialize), and instead it falls back to CPU rendering directly into the framebuffer. So it's highly sub-optimal, but works around the complete wreckage. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.15-rc2: i915 regression: only top 20% of screen works in X
On Thu, 24 Apr 2014, Pavel Machek wrote: That says that i915.ko failed to initialise the GPU (or rather the GPU wasn't responding) and bailed during module load. The key line here is [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 2034 tail start 0012f000 Actually, I'm not using modules -- everything is build-in. Can you try that config? Perhaps you can then reproduce the failure. Jiri has been seeing a similar issue creep in during resume, but it is not reliable enough to bisect. Is your boot failure reliable enough to bisect? Also drm-intel-nightly should mitigate this failure and allow i915.ko to continue to load and run X, which would be worth testing to make sure that works as intended. So far it failed 100% of time, but this is my main machine, so bringing it down for extended periods is no-no. Greetings to Prague :-). Jiri, do you have i915 a module or build-in? Hi there Pavel, long time no see :) I have i915 built as a module. The thing is, that I can't really bisect this; the problem is, that I've started seeing this quite a long time ago, but only very sporadically (something like once in 40 resumes). But it was getting gradually worse and worse with newer kernels, and with current tree (both Linus' tree and drm-intel-testing), I am getting it 100% reproducibly on every resume. This makes bisection completely impossible though. -- Jiri Kosina ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [bisect result] Re: 3.15-rc2: i915 regression: only top 20% of screen works in X
On Fri, 25 Apr 2014, Pavel Machek wrote: And we have a winner here :-) Ok, it was not as painfull as I feared. It does not revert cleanly, but doing it by hand was not that bad. Oh my. That is bizarre, can you check whether you have commit 9991ae787a0c87fe7c783b4b6f4754c3cdbb6213 Yes, with that commit, graphics is back to working state. Please push it to mainline soon -- it fixes a regression. Feel free to add Alright, most of my testing has been done with that commit present (obviously, as I've been using Chris' branch that has this incorporated), so I have a different ring initialization problem than Pavel had. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 resume-from-hibernation problems on resume with current Linus' tree
On Fri, 21 Mar 2014, Daniel Vetter wrote: So I am still seeing this with current Linus' tree rather regularly (but it's not deterministic enough for a reliable bisect). Unfortunately I haven't received any patches to test; what do you propose? Would reporting this on bugs.freedesktop.org instead of ranting here change anything? Yeah, filing a bug on fdo to keep track of this should help. Please add a [gm45 regression] tag to the summary so that it shows up in our queries at the right spot ;-) One thing to test would be to give -nightly (or drm-intel-testing as of today) a shot. We've merged a few patches recently to slightly improve the ring init sequence in the generic code, they might actually help here. Sorry for not correlating them with your patch when I've merged them, only just realized this now. I just tested current Linus' tree + drm-intel-testing (HEAD == 14347c2 (drm-intel-nightly: 2014y-03m-21d-16h-13m-30s integration manifest)), and on 3rd suspend-resume cycle I got the ring initialization failure again, with Xorg going crazy afterwards. So unfortunately it's still unfixed. Now submitted as https://bugs.freedesktop.org/show_bug.cgi?id=76554 as well. Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 resume-from-hibernation problems on resume with current Linus' tree
On Wed, 5 Mar 2014, Daniel Vetter wrote: Maybe I should say that I'm booting the box with [ 0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14.0-rc5+ root=/dev/sdb2 ro root=/dev/sdb2 ignore_loglevel log_buf_len=10M resume=/dev/sdb1 i915.i915_enable_rc6=4 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.powersave=1 From looking at http://lkml.kernel.org/r/1394011994-30604-1-git-send-email-daniel.vet...@ffwll.ch it looks like I should stop using the rc6/fbc settings? :-) Indeed. If going back to defaults fixes your issues, then it's not a real bug. There are reasons the defaults are as-is ... Let's not have the issues mixed. The one originally reported in this thread *ERROR* render ring initialization failed ctl 0001f001 head 3004 tail start 3000 and subsequent resume busted is there even with the default i915 driver settings. Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 resume-from-hibernation problems on resume with current Linus' tree
On Thu, 27 Feb 2014, Jiri Kosina wrote: Hi, first things first: this is hard to bisect, because it doesn't happen reliably and I don't really know what is the first good version, as I had a delay in following Linus' tree. I think that I should've been clearer about the versions here -- I don't recall seeing this problem with 3.13, and I had trouble running early 3.14 rcs because of 4e6b788c3f on this machine. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] WARNING at intel_display.c:9948 during suspend
I am getting this during suspend with latest Linus' git (HEAD == af91706). [ cut here ] WARNING: CPU: 0 PID: 5397 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x4a/0x50 [i915]() Modules linked in: ctr ccm af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm cpufreq_conservative bnep cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support kvm_intel kvm snd_hda_codec_conexant iwldvm mac80211 thinkpad_acpi snd_seq sg iwlwifi snd_seq_device snd_hda_intel snd_hda_codec snd_hwdep btusb bluetooth cfg80211 pcspkr snd_pcm i2c_i801 lpc_ich mfd_core rfkill snd_timer ehci_pci snd_page_alloc e1000e snd ptp pps_core wmi battery soundcore ac tpm_tis tpm acpi_cpufreq autofs4 uhci_hcd ehci_hcd i915 usbcore usb_common drm_kms_helper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys CPU: 0 PID: 5397 Comm: kworker/u8:3 Not tainted 3.13.0-rc2-1-gaf91706 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 Workqueue: events_unbound async_run_entry_fn 26dc 8800229c1ab8 8158f73b 8800229c1af8 8104d527 8800229c1b08 880035f8b4c0 880079558000 880037cbc000 880035f8b4c0 8800229c1b08 Call Trace: [8158f73b] dump_stack+0x72/0x87 [8104d527] warn_slowpath_common+0x87/0xb0 [8104d565] warn_slowpath_null+0x15/0x20 [a0173cda] intel_get_pipe_from_connector+0x4a/0x50 [i915] [a019c32b] intel_panel_disable_backlight+0x2b/0x1a0 [i915] [a0186cce] intel_disable_lvds+0x4e/0x190 [i915] [a017ca49] i9xx_crtc_disable+0x2a9/0x3b0 [i915] [a013d0da] i915_drm_freeze+0xda/0x160 [i915] [a013d1a8] i915_pm_freeze+0x28/0x50 [i915] [813209f8] pci_pm_freeze+0x58/0xd0 [813209a0] ? pci_pm_poweroff+0xf0/0xf0 [813e932f] dpm_run_callback+0x4f/0xa0 [813e958f] __device_suspend+0xef/0x280 [813ead6a] async_suspend+0x1a/0xa0 [81078765] async_run_entry_fn+0x45/0x140 [8106b194] process_one_work+0x204/0x470 [8106b0e3] ? process_one_work+0x153/0x470 [81591940] ? __mutex_unlock_slowpath+0xf0/0x180 [8106c596] worker_thread+0x126/0x3b0 [8109b0ed] ? trace_hardirqs_on+0xd/0x10 [8106c470] ? manage_workers+0x1a0/0x1a0 [810726ed] kthread+0xed/0x100 [81072600] ? __init_kthread_worker+0x70/0x70 [8159d8bc] ret_from_fork+0x7c/0xb0 [81072600] ? __init_kthread_worker+0x70/0x70 ---[ end trace 8a2e5e8955c55372 ]--- PM: freeze of devices complete after 407.505 msecs PM: late freeze of devices complete after 2.719 msecs PM: noirq freeze of devices complete after 3.789 msecs Disabling non-boot CPUs ... kvm: disabling virtualization on CPU1 smpboot: CPU 1 is now offline PM: Creating hibernation image: PM: Need to copy 164506 pages -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HPD flood warning since b8f102e8b
On Mon, 21 Oct 2013, Egbert Eich wrote: On Thu, 3 Oct 2013, Daniel Vetter wrote: Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... A bit difficult ... I originally thought that it was reliably reproducible, but now I didn't get it after 10 suspend/resume cycles. Will keep following it, and once it appears, will send you the dmesg. Could you check if you get any messages regarding HPD storms after suspend/resume ie messages like: [drm] HPD interrupt storm detected on connector HDMI-A-1 but without the annouing warn messages? I have this: [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: switching from hotplug detection to polling It appeared in the log approximately 5 seconds after resume has been completed. Thanks, -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HPD flood warning since b8f102e8b
On Thu, 24 Oct 2013, Jiri Kosina wrote: I have this: [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: switching from hotplug detection to polling It appeared in the log approximately 5 seconds after resume has been completed. Okay, and it just happened during resume from RAM (it was a very long series of repeating the same trace, I am putting here just the last portion): [362634.813953] [ cut here ] [362634.813980] WARNING: CPU: 0 PID: 666 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [362634.813981] Received HPD interrupt although disabled [362634.814021] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_helper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [362634.814028] CPU: 0 PID: 666 Comm: rs:main Q:Reg Tainted: GW 3.12.0-rc4-6-g162bdaf-dirty #1 [362634.814029] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [362634.814033] 03e9 88007c203d18 81583863 88007c203d58 [362634.814035] 8104d297 88007c203d98 0010 0002 [362634.814038] 88003718 0005 88003718 88007c203db8 [362634.814039] Call Trace: [362634.814044] IRQ [81583863] dump_stack+0x7a/0x97 [362634.814048] [8104d297] warn_slowpath_common+0x87/0xb0 [362634.814051] [8104d361] warn_slowpath_fmt+0x41/0x50 [362634.814067] [a00c7be2] i965_irq_handler+0x492/0x680 [i915] [362634.814072] [810a41bc] handle_irq_event_percpu+0xac/0x220 [362634.814074] [810a4379] handle_irq_event+0x49/0x70 [362634.814077] [810a7bef] handle_edge_irq+0x7f/0x150 [362634.814080] [81004a89] handle_irq+0x59/0x150 [362634.814083] [81052b06] ? irq_enter+0x16/0x90 [362634.814085] [8100403b] do_IRQ+0x5b/0xe0 [362634.814089] [81589def] common_interrupt+0x6f/0x6f [362634.814093] EOI [810bc850] ? lock_acquire+0x110/0x130 [362634.814096] [8158dae0] ? notifier_call_chain+0xa0/0xa0 [362634.814098] [8158db4a] __atomic_notifier_call_chain+0x6a/0xc0 [362634.814101] [8158dae0] ? notifier_call_chain+0xa0/0xa0 [362634.814103] [8158dbb1] atomic_notifier_call_chain+0x11/0x20 [362634.814106] [813b607f] do_con_write+0x22f/0xa10 [362634.814109] [81585e6f] ? mutex_lock_nested+0x2ef/0x370 [362634.814111] [810bb2bd] ? trace_hardirqs_on_caller+0x13d/0x1e0 [362634.814115] [8139df7d] ? process_output_block+0x3d/0x1e0 [362634.814118] [813b68b9] con_write+0x19/0x30 [362634.814120] [8139e010] process_output_block+0xd0/0x1e0 [362634.814123] [8139ee0b] n_tty_write+0x18b/0x370 [362634.814126] [810834a0] ? try_to_wake_up+0x240/0x240 [362634.814129] [8139c67c] do_tty_write+0xbc/0x200 [362634.814131] [8139ec80] ? n_tty_ioctl+0x110/0x110 [362634.814134] [8139c884] tty_write+0xc4/0xf0 [362634.814137] [81190bf7] vfs_write+0xe7/0x190 [362634.814139] [81191560] SyS_write+0x60/0xb0 [362634.814142] [81591fa2] system_call_fastpath+0x16/0x1b [362634.814144] ---[ end trace f54ed427593b8ca0 ]--- [362634.894446] [ cut here ] [362634.894476] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [362634.894479] Received HPD interrupt although disabled [362634.894481] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 uhci_hcd ehci_hcd usbcore usb_common
Re: [Intel-gfx] HPD flood warning since b8f102e8b
On Thu, 24 Oct 2013, Egbert Eich wrote: Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... A bit difficult ... I originally thought that it was reliably reproducible, but now I didn't get it after 10 suspend/resume cycles. Will keep following it, and once it appears, will send you the dmesg. Could you check if you get any messages regarding HPD storms after suspend/resume ie messages like: [drm] HPD interrupt storm detected on connector HDMI-A-1 but without the annouing warn messages? I have this: [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: switching from hotplug detection to polling It appeared in the log approximately 5 seconds after resume has been completed. :( You seem to get this on different connector. Any chance for a 'lspci -n' output? 00:00.0 0600: 8086:2a40 (rev 07) 00:02.0 0300: 8086:2a42 (rev 07) 00:02.1 0380: 8086:2a43 (rev 07) 00:03.0 0780: 8086:2a44 (rev 07) 00:03.2 0101: 8086:2a46 (rev 07) 00:03.3 0700: 8086:2a47 (rev 07) 00:19.0 0200: 8086:10f5 (rev 03) 00:1a.0 0c03: 8086:2937 (rev 03) 00:1a.1 0c03: 8086:2938 (rev 03) 00:1a.2 0c03: 8086:2939 (rev 03) 00:1a.7 0c03: 8086:293c (rev 03) 00:1b.0 0403: 8086:293e (rev 03) 00:1c.0 0604: 8086:2940 (rev 03) 00:1c.1 0604: 8086:2942 (rev 03) 00:1c.3 0604: 8086:2946 (rev 03) 00:1d.0 0c03: 8086:2934 (rev 03) 00:1d.1 0c03: 8086:2935 (rev 03) 00:1d.2 0c03: 8086:2936 (rev 03) 00:1d.7 0c03: 8086:293a (rev 03) 00:1e.0 0604: 8086:2448 (rev 93) 00:1f.0 0601: 8086:2917 (rev 03) 00:1f.2 0106: 8086:2929 (rev 03) 00:1f.3 0c05: 8086:2930 (rev 03) 03:00.0 0280: 8086:4237 I (and the computer in question) am in Edinburgh till friday, in case someone wants to have a look. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HPD flood warning since b8f102e8b
On Thu, 3 Oct 2013, Daniel Vetter wrote: Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... OK, I haven't been able to reproduce this any more for ~week ... so please disregard this, and I'll report back if it comes back (will be running with full drm debug output for some time). -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] HPD flood warning since b8f102e8b
During resume from hibernation, I started to see the warning below since commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich e...@suse.de Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) the system is otherwise working properly, and so far it seems to happen only during hibernation resume. [13766.703229] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [13766.703230] Received HPD interrupt although disabled [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm bn ep btusb bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi snd_seq iwldvm mac80211 sg snd_timer iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_he lper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.12.0-rc3 #1 [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [13766.703350] 03e9 88007c283d18 81583013 88007c283d58 [13766.703357] 8104d297 88007c283d98 000c 0002 [13766.703365] 880037158000 0004 880037158000 88007c283db8 [13766.703367] Call Trace: [13766.703375] IRQ [81583013] dump_stack+0x7a/0x97 [13766.703382] [8104d297] warn_slowpath_common+0x87/0xb0 [13766.703388] [8104d361] warn_slowpath_fmt+0x41/0x50 [13766.703425] [a00c7be2] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [810a40fc] handle_irq_event_percpu+0xac/0x220 [13766.703442] [810a42b9] handle_irq_event+0x49/0x70 [13766.703449] [810a7b2f] handle_edge_irq+0x7f/0x150 [13766.703454] [81004a89] handle_irq+0x59/0x150 [13766.703461] [8158d371] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [8100403b] do_IRQ+0x5b/0xe0 [13766.703474] [815895af] common_interrupt+0x6f/0x6f [13766.703482] EOI [8146cf74] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [8146cf70] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [8146d37a] cpuidle_idle_call+0x10a/0x160 [13766.703503] [8100b7b9] arch_cpu_idle+0x9/0x30 [13766.703509] [810a35cb] cpu_idle_loop+0x8b/0x270 [13766.703515] [810a37ce] cpu_startup_entry+0x1e/0x20 [13766.703522] [8103115e] start_secondary+0x8e/0x90 It's not a single occurence, it's quite a flood within the same second, ending with [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from hotplug detection to pollin If this really needs to be enabled unconditionally by default (?), having it to warn only once would be nice. If there is anything else I could do to make this go away, please let me know. I don't want to be running Tainted: W kernel from now forever on :) This is a standard x200s thinkpad, no fancy development HW. -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HPD flood warning since b8f102e8b
On Thu, 3 Oct 2013, Daniel Vetter wrote: Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... A bit difficult ... I originally thought that it was reliably reproducible, but now I didn't get it after 10 suspend/resume cycles. Will keep following it, and once it appears, will send you the dmesg. Cheers, Daniel On Thu, Oct 3, 2013 at 11:46 AM, Jiri Kosina jkos...@suse.cz wrote: During resume from hibernation, I started to see the warning below since commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich e...@suse.de Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) the system is otherwise working properly, and so far it seems to happen only during hibernation resume. [13766.703229] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [13766.703230] Received HPD interrupt although disabled [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm bn ep btusb bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi snd_seq iwldvm mac80211 sg snd_timer iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_he lper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.12.0-rc3 #1 [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [13766.703350] 03e9 88007c283d18 81583013 88007c283d58 [13766.703357] 8104d297 88007c283d98 000c 0002 [13766.703365] 880037158000 0004 880037158000 88007c283db8 [13766.703367] Call Trace: [13766.703375] IRQ [81583013] dump_stack+0x7a/0x97 [13766.703382] [8104d297] warn_slowpath_common+0x87/0xb0 [13766.703388] [8104d361] warn_slowpath_fmt+0x41/0x50 [13766.703425] [a00c7be2] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [810a40fc] handle_irq_event_percpu+0xac/0x220 [13766.703442] [810a42b9] handle_irq_event+0x49/0x70 [13766.703449] [810a7b2f] handle_edge_irq+0x7f/0x150 [13766.703454] [81004a89] handle_irq+0x59/0x150 [13766.703461] [8158d371] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [8100403b] do_IRQ+0x5b/0xe0 [13766.703474] [815895af] common_interrupt+0x6f/0x6f [13766.703482] EOI [8146cf74] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [8146cf70] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [8146d37a] cpuidle_idle_call+0x10a/0x160 [13766.703503] [8100b7b9] arch_cpu_idle+0x9/0x30 [13766.703509] [810a35cb] cpu_idle_loop+0x8b/0x270 [13766.703515] [810a37ce] cpu_startup_entry+0x1e/0x20 [13766.703522] [8103115e] start_secondary+0x8e/0x90 It's not a single occurence, it's quite a flood within the same second, ending with [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from hotplug detection to pollin If this really needs to be enabled unconditionally by default (?), having it to warn only once would be nice. If there is anything else I could do to make this go away, please let me know. I don't want to be running Tainted: W kernel from now forever on :) This is a standard x200s thinkpad, no fancy development HW. -- Jiri Kosina SUSE Labs -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Flush writes to GMBUS registers
On Mon, 18 Mar 2013, Chris Wilson wrote: If we do not complete the writes to the GMBUS registers, they remain active for an indefinite period of time afterwards, even causing spurious interrupts on gm45. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Link: http://lkml.kernel.org/r/alpine.lnx.2.00.1303151424140.9...@pobox.suse.cz Cc: Shawn Starr shawn.st...@rogers.com Cc: Jiri Kosina jkos...@suse.cz Cc: Daniel Vetter daniel.vet...@ffwll.ch Unfortunately I can't provide my Tested-by or Acked-by for this, as I am still seeing the nobody cared for irq 16 with this patch applied. --- drivers/gpu/drm/i915/intel_i2c.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index acf8aec..ca6c17e 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -64,6 +64,7 @@ intel_i2c_reset(struct drm_device *dev) struct drm_i915_private *dev_priv = dev-dev_private; I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0); I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0); + POSTING_READ(dev_priv-gpio_mmio_base + GMBUS4); } static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable) @@ -232,6 +233,7 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv, finish_wait(dev_priv-gmbus_wait_queue, wait); I915_WRITE(GMBUS4 + reg_offset, 0); + POSTING_READ(GMBUS4 + reg_offset); if (gmbus2 GMBUS_SATOER) return -ENXIO; @@ -257,6 +259,7 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv) ret = wait_event_timeout(dev_priv-gmbus_wait_queue, C, 10); I915_WRITE(GMBUS4 + reg_offset, 0); + POSTING_READ(GMBUS4 + reg_offset); if (ret) return 0; @@ -486,6 +489,7 @@ timeout: ret = i2c_bit_algo.master_xfer(adapter, msgs, num); out: + POSTING_READ(GMBUS0 + dev_priv-gpio_mmio_base); mutex_unlock(dev_priv-gmbus_mutex); return ret; } -- 1.7.10.4 -- Jiri Kosina SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
