All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-21 15:08 ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-21 15:08 UTC (permalink / raw)
  To: Intel Graphics Development
  Cc: Chris Wilson, Daniel Vetter, Jaroslav Kysela, Takashi Iwai,
	Guneshwor Singh, Hardik T Shah, Julia Lawall, Vinod Koul,
	Subhransu S. Prusty, Libin Yang, linux-kernel

So back when the i915 power well support landed in

commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
Author: Wang Xingchao <xingchao.wang@linux.intel.com>
Date:   Thu May 30 22:07:10 2013 +0800

    ALSA: hda - Add power-welll support for haswell HDA

the logic to handle the cross-module depencies was hand-rolled using a
async work item, and that just doesn't work.

The correct way to handle cross-module deps is either:
- request_module + failing when the other module isn't there

OR

- failing the module load with EPROBE_DEFER.

You can't mix them, if you do then the entire load path just
busy-spins blowing through cpu cycles forever with no way to stop
this.

snd-hda-intel does mix it, because the hda codec drivers are loaded
using request_module, but the i915 depency is handled using
PROBE_DEFER (or well, should be, but I haven't found any code at all).
This is a major pain when trying to debug i915 load failures.

This patch here is a horrible hackish attempt at somewhat correctly
wriing EPROBE_DEFER through. Stuff that's missing:
- Check all the other places where load errors are conveniently
  dropped on the floor.
- Also fix up the firmware_cb path.
- Drop the debug noise I've left in to make it clear this isn't
  anything for merging.

Cheers, Daniel

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: "GitAuthor: Daniel Vetter" <daniel.vetter@ffwll.ch>
Cc: Guneshwor Singh <guneshwor.o.singh@intel.com>
Cc: Hardik T Shah <hardik.t.shah@intel.com>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: "Subhransu S. Prusty" <subhransu.s.prusty@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Cc: linux-kernel@vger.kernel.org
---
 drivers/base/dd.c              |  2 ++
 sound/pci/hda/hda_bind.c       |  6 +++---
 sound/pci/hda/hda_controller.c |  8 +++++++-
 sound/pci/hda/hda_intel.c      | 13 +++++++++----
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..842bc8782124 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -17,6 +17,8 @@
  * This file is released under the GPLv2
  */
 
+#define DEBUG
+
 #include <linux/device.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index 6efadbfb3fe3..0bc164a17493 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -253,7 +253,7 @@ static int codec_bind_generic(struct hda_codec *codec)
 	request_codec_module(codec);
 	if (codec_probed(codec))
 		return 0;
-	return -ENODEV;
+	return -EPROBE_DEFER;
 }
 
 #if IS_ENABLED(CONFIG_SND_HDA_GENERIC)
@@ -289,8 +289,8 @@ int snd_hda_codec_configure(struct hda_codec *codec)
 		codec_bind_module(codec);
 	if (!codec->preset) {
 		err = codec_bind_generic(codec);
-		if (err < 0) {
-			codec_err(codec, "Unable to bind the codec\n");
+		if (WARN_ON(err < 0)) {
+			codec_err(codec, "Unable to bind the codec, err=%i\n", err);
 			goto error;
 		}
 	}
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 3715a5725613..4b4262c72327 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -1337,9 +1337,15 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
 /* configure each codec instance */
 int azx_codec_configure(struct azx *chip)
 {
+	int ret;
+
 	struct hda_codec *codec;
 	list_for_each_codec(codec, &chip->bus) {
-		snd_hda_codec_configure(codec);
+		ret = snd_hda_codec_configure(codec);
+		if (ret) {
+			printk("bailing real hard %i\n", ret);
+			return ret;
+		}
 	}
 	return 0;
 }
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 07ea7f48aa01..8241387cc8ca 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1649,7 +1649,8 @@ static void azx_check_snoop_available(struct azx *chip)
 static void azx_probe_work(struct work_struct *work)
 {
 	struct hda_intel *hda = container_of(work, struct hda_intel, probe_work);
-	azx_probe_continue(&hda->chip);
+
+	WARN_ON(1);
 }
 
 static int default_bdl_pos_adj(struct azx *chip)
@@ -2158,7 +2159,6 @@ static int azx_probe(struct pci_dev *pci,
 					      azx_firmware_cb);
 		if (err < 0)
 			goto out_free;
-		schedule_probe = false; /* continued in azx_firmware_cb() */
 	}
 #endif /* CONFIG_SND_HDA_PATCH_LOADER */
 
@@ -2167,8 +2167,13 @@ static int azx_probe(struct pci_dev *pci,
 		dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in CONFIG_SND_HDA_I915\n");
 #endif
 
-	if (schedule_probe)
-		schedule_work(&hda->probe_work);
+	if (schedule_probe) {
+		err = azx_probe_continue(chip);
+		if (err) {
+			printk("hit the right error return finally! err=%i\n", err);
+			goto out_free;
+		}
+	}
 
 	dev++;
 	if (chip->disabled)
-- 
2.5.5

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-21 15:08 ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-21 15:08 UTC (permalink / raw)
  To: Intel Graphics Development
  Cc: Vinod Koul, Daniel Vetter, Guneshwor Singh, Takashi Iwai,
	Jaroslav Kysela, Julia Lawall, Hardik T Shah,
	Subhransu S. Prusty, linux-kernel

So back when the i915 power well support landed in

commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
Author: Wang Xingchao <xingchao.wang@linux.intel.com>
Date:   Thu May 30 22:07:10 2013 +0800

    ALSA: hda - Add power-welll support for haswell HDA

the logic to handle the cross-module depencies was hand-rolled using a
async work item, and that just doesn't work.

The correct way to handle cross-module deps is either:
- request_module + failing when the other module isn't there

OR

- failing the module load with EPROBE_DEFER.

You can't mix them, if you do then the entire load path just
busy-spins blowing through cpu cycles forever with no way to stop
this.

snd-hda-intel does mix it, because the hda codec drivers are loaded
using request_module, but the i915 depency is handled using
PROBE_DEFER (or well, should be, but I haven't found any code at all).
This is a major pain when trying to debug i915 load failures.

This patch here is a horrible hackish attempt at somewhat correctly
wriing EPROBE_DEFER through. Stuff that's missing:
- Check all the other places where load errors are conveniently
  dropped on the floor.
- Also fix up the firmware_cb path.
- Drop the debug noise I've left in to make it clear this isn't
  anything for merging.

Cheers, Daniel

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: "GitAuthor: Daniel Vetter" <daniel.vetter@ffwll.ch>
Cc: Guneshwor Singh <guneshwor.o.singh@intel.com>
Cc: Hardik T Shah <hardik.t.shah@intel.com>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: "Subhransu S. Prusty" <subhransu.s.prusty@intel.com>
Cc: Libin Yang <libin.yang@intel.com>
Cc: linux-kernel@vger.kernel.org
---
 drivers/base/dd.c              |  2 ++
 sound/pci/hda/hda_bind.c       |  6 +++---
 sound/pci/hda/hda_controller.c |  8 +++++++-
 sound/pci/hda/hda_intel.c      | 13 +++++++++----
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..842bc8782124 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -17,6 +17,8 @@
  * This file is released under the GPLv2
  */
 
+#define DEBUG
+
 #include <linux/device.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c
index 6efadbfb3fe3..0bc164a17493 100644
--- a/sound/pci/hda/hda_bind.c
+++ b/sound/pci/hda/hda_bind.c
@@ -253,7 +253,7 @@ static int codec_bind_generic(struct hda_codec *codec)
 	request_codec_module(codec);
 	if (codec_probed(codec))
 		return 0;
-	return -ENODEV;
+	return -EPROBE_DEFER;
 }
 
 #if IS_ENABLED(CONFIG_SND_HDA_GENERIC)
@@ -289,8 +289,8 @@ int snd_hda_codec_configure(struct hda_codec *codec)
 		codec_bind_module(codec);
 	if (!codec->preset) {
 		err = codec_bind_generic(codec);
-		if (err < 0) {
-			codec_err(codec, "Unable to bind the codec\n");
+		if (WARN_ON(err < 0)) {
+			codec_err(codec, "Unable to bind the codec, err=%i\n", err);
 			goto error;
 		}
 	}
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 3715a5725613..4b4262c72327 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -1337,9 +1337,15 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
 /* configure each codec instance */
 int azx_codec_configure(struct azx *chip)
 {
+	int ret;
+
 	struct hda_codec *codec;
 	list_for_each_codec(codec, &chip->bus) {
-		snd_hda_codec_configure(codec);
+		ret = snd_hda_codec_configure(codec);
+		if (ret) {
+			printk("bailing real hard %i\n", ret);
+			return ret;
+		}
 	}
 	return 0;
 }
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 07ea7f48aa01..8241387cc8ca 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1649,7 +1649,8 @@ static void azx_check_snoop_available(struct azx *chip)
 static void azx_probe_work(struct work_struct *work)
 {
 	struct hda_intel *hda = container_of(work, struct hda_intel, probe_work);
-	azx_probe_continue(&hda->chip);
+
+	WARN_ON(1);
 }
 
 static int default_bdl_pos_adj(struct azx *chip)
@@ -2158,7 +2159,6 @@ static int azx_probe(struct pci_dev *pci,
 					      azx_firmware_cb);
 		if (err < 0)
 			goto out_free;
-		schedule_probe = false; /* continued in azx_firmware_cb() */
 	}
 #endif /* CONFIG_SND_HDA_PATCH_LOADER */
 
@@ -2167,8 +2167,13 @@ static int azx_probe(struct pci_dev *pci,
 		dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in CONFIG_SND_HDA_I915\n");
 #endif
 
-	if (schedule_probe)
-		schedule_work(&hda->probe_work);
+	if (schedule_probe) {
+		err = azx_probe_continue(chip);
+		if (err) {
+			printk("hit the right error return finally! err=%i\n", err);
+			goto out_free;
+		}
+	}
 
 	dev++;
 	if (chip->disabled)
-- 
2.5.5

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-21 15:08 ` Daniel Vetter
@ 2017-06-21 15:23   ` Chris Wilson
  -1 siblings, 0 replies; 22+ messages in thread
From: Chris Wilson @ 2017-06-21 15:23 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics Development
  Cc: Daniel Vetter, Jaroslav Kysela, Takashi Iwai, Guneshwor Singh,
	Hardik T Shah, Julia Lawall, Vinod Koul, Subhransu S. Prusty,
	Libin Yang, linux-kernel

Quoting Daniel Vetter (2017-06-21 16:08:54)
> So back when the i915 power well support landed in
> 
> commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> Date:   Thu May 30 22:07:10 2013 +0800
> 
>     ALSA: hda - Add power-welll support for haswell HDA
> 
> the logic to handle the cross-module depencies was hand-rolled using a
> async work item, and that just doesn't work.
> 
> The correct way to handle cross-module deps is either:
> - request_module + failing when the other module isn't there
> 
> OR
> 
> - failing the module load with EPROBE_DEFER.
> 
> You can't mix them, if you do then the entire load path just
> busy-spins blowing through cpu cycles forever with no way to stop
> this.
> 
> snd-hda-intel does mix it, because the hda codec drivers are loaded
> using request_module, but the i915 depency is handled using
> PROBE_DEFER (or well, should be, but I haven't found any code at all).
> This is a major pain when trying to debug i915 load failures.
> 
> This patch here is a horrible hackish attempt at somewhat correctly
> wriing EPROBE_DEFER through. Stuff that's missing:
> - Check all the other places where load errors are conveniently
>   dropped on the floor.
> - Also fix up the firmware_cb path.
> - Drop the debug noise I've left in to make it clear this isn't
>   anything for merging.

This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
continuously spewing previously, and now the system is usable again.
Thanks,
-Chris

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-21 15:23   ` Chris Wilson
  0 siblings, 0 replies; 22+ messages in thread
From: Chris Wilson @ 2017-06-21 15:23 UTC (permalink / raw)
  To: Intel Graphics Development
  Cc: Vinod Koul, Daniel Vetter, Guneshwor Singh, Takashi Iwai,
	Jaroslav Kysela, Julia Lawall, Hardik T Shah,
	Subhransu S. Prusty, linux-kernel

Quoting Daniel Vetter (2017-06-21 16:08:54)
> So back when the i915 power well support landed in
> 
> commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> Date:   Thu May 30 22:07:10 2013 +0800
> 
>     ALSA: hda - Add power-welll support for haswell HDA
> 
> the logic to handle the cross-module depencies was hand-rolled using a
> async work item, and that just doesn't work.
> 
> The correct way to handle cross-module deps is either:
> - request_module + failing when the other module isn't there
> 
> OR
> 
> - failing the module load with EPROBE_DEFER.
> 
> You can't mix them, if you do then the entire load path just
> busy-spins blowing through cpu cycles forever with no way to stop
> this.
> 
> snd-hda-intel does mix it, because the hda codec drivers are loaded
> using request_module, but the i915 depency is handled using
> PROBE_DEFER (or well, should be, but I haven't found any code at all).
> This is a major pain when trying to debug i915 load failures.
> 
> This patch here is a horrible hackish attempt at somewhat correctly
> wriing EPROBE_DEFER through. Stuff that's missing:
> - Check all the other places where load errors are conveniently
>   dropped on the floor.
> - Also fix up the firmware_cb path.
> - Drop the debug noise I've left in to make it clear this isn't
>   anything for merging.

This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
continuously spewing previously, and now the system is usable again.
Thanks,
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-21 15:23   ` Chris Wilson
@ 2017-06-21 15:30     ` Takashi Iwai
  -1 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-06-21 15:30 UTC (permalink / raw)
  To: Chris Wilson
  Cc: Intel Graphics Development, Daniel Vetter, Guneshwor Singh,
	Hardik T Shah, Libin Yang, Subhransu S. Prusty, Vinod Koul,
	Julia Lawall, Jaroslav Kysela, tiwai, linux-kernel

On Wed, 21 Jun 2017 17:23:57 +0200,
Chris Wilson wrote:
> 
> Quoting Daniel Vetter (2017-06-21 16:08:54)
> > So back when the i915 power well support landed in
> > 
> > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > Date:   Thu May 30 22:07:10 2013 +0800
> > 
> >     ALSA: hda - Add power-welll support for haswell HDA
> > 
> > the logic to handle the cross-module depencies was hand-rolled using a
> > async work item, and that just doesn't work.
> > 
> > The correct way to handle cross-module deps is either:
> > - request_module + failing when the other module isn't there
> > 
> > OR
> > 
> > - failing the module load with EPROBE_DEFER.
> > 
> > You can't mix them, if you do then the entire load path just
> > busy-spins blowing through cpu cycles forever with no way to stop
> > this.
> > 
> > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > using request_module, but the i915 depency is handled using
> > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > This is a major pain when trying to debug i915 load failures.
> > 
> > This patch here is a horrible hackish attempt at somewhat correctly
> > wriing EPROBE_DEFER through. Stuff that's missing:
> > - Check all the other places where load errors are conveniently
> >   dropped on the floor.
> > - Also fix up the firmware_cb path.
> > - Drop the debug noise I've left in to make it clear this isn't
> >   anything for merging.
> 
> This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> continuously spewing previously, and now the system is usable again.

Could you give a failing scenario?  I'm not opposing to the suggested
solution, we need to fix the mess in anyway, but I just would like to
know how to trigger the problem easily.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-21 15:30     ` Takashi Iwai
  0 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-06-21 15:30 UTC (permalink / raw)
  To: Chris Wilson
  Cc: Vinod Koul, Daniel Vetter, Intel Graphics Development,
	Guneshwor Singh, linux-kernel, Jaroslav Kysela, Julia Lawall,
	tiwai, Hardik T Shah, Subhransu S. Prusty

On Wed, 21 Jun 2017 17:23:57 +0200,
Chris Wilson wrote:
> 
> Quoting Daniel Vetter (2017-06-21 16:08:54)
> > So back when the i915 power well support landed in
> > 
> > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > Date:   Thu May 30 22:07:10 2013 +0800
> > 
> >     ALSA: hda - Add power-welll support for haswell HDA
> > 
> > the logic to handle the cross-module depencies was hand-rolled using a
> > async work item, and that just doesn't work.
> > 
> > The correct way to handle cross-module deps is either:
> > - request_module + failing when the other module isn't there
> > 
> > OR
> > 
> > - failing the module load with EPROBE_DEFER.
> > 
> > You can't mix them, if you do then the entire load path just
> > busy-spins blowing through cpu cycles forever with no way to stop
> > this.
> > 
> > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > using request_module, but the i915 depency is handled using
> > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > This is a major pain when trying to debug i915 load failures.
> > 
> > This patch here is a horrible hackish attempt at somewhat correctly
> > wriing EPROBE_DEFER through. Stuff that's missing:
> > - Check all the other places where load errors are conveniently
> >   dropped on the floor.
> > - Also fix up the firmware_cb path.
> > - Drop the debug noise I've left in to make it clear this isn't
> >   anything for merging.
> 
> This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> continuously spewing previously, and now the system is usable again.

Could you give a failing scenario?  I'm not opposing to the suggested
solution, we need to fix the mess in anyway, but I just would like to
know how to trigger the problem easily.


thanks,

Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* ✗ Fi.CI.BAT: failure for BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-21 15:08 ` Daniel Vetter
  (?)
  (?)
@ 2017-06-21 15:52 ` Patchwork
  -1 siblings, 0 replies; 22+ messages in thread
From: Patchwork @ 2017-06-21 15:52 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
URL   : https://patchwork.freedesktop.org/series/26154/
State : failure

== Summary ==

Series 26154v1 BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
https://patchwork.freedesktop.org/api/1.0/series/26154/revisions/1/mbox/

Test core_auth:
        Subgroup basic-auth:
                pass       -> SKIP       (fi-ilk-650)
                pass       -> SKIP       (fi-snb-2520m)
                pass       -> SKIP       (fi-snb-2600)
                pass       -> SKIP       (fi-ivb-3520m)
                pass       -> SKIP       (fi-ivb-3770)
                pass       -> SKIP       (fi-byt-j1900)
                pass       -> SKIP       (fi-byt-n2820)
                pass       -> SKIP       (fi-hsw-4770)
                pass       -> SKIP       (fi-hsw-4770r)
                pass       -> SKIP       (fi-bdw-5557u)
                pass       -> SKIP       (fi-bsw-n3050)
                pass       -> SKIP       (fi-skl-6700hq)
                pass       -> SKIP       (fi-skl-6700k)
                pass       -> SKIP       (fi-bxt-j4205)
                pass       -> SKIP       (fi-kbl-7500u)
                pass       -> SKIP       (fi-kbl-r)
                pass       -> SKIP       (fi-glk-2a)
Test core_prop_blob:
        Subgroup basic:
                pass       -> SKIP       (fi-ilk-650)
                pass       -> SKIP       (fi-snb-2520m)
                pass       -> SKIP       (fi-snb-2600)
                pass       -> SKIP       (fi-ivb-3520m)
                pass       -> SKIP       (fi-ivb-3770)
                pass       -> SKIP       (fi-byt-j1900)
                pass       -> SKIP       (fi-byt-n2820)
                pass       -> SKIP       (fi-hsw-4770)
                pass       -> SKIP       (fi-hsw-4770r)
                pass       -> SKIP       (fi-bdw-5557u)
                pass       -> SKIP       (fi-bsw-n3050)
                pass       -> SKIP       (fi-skl-6700hq)
                pass       -> SKIP       (fi-skl-6700k)
                pass       -> SKIP       (fi-bxt-j4205)
                pass       -> SKIP       (fi-kbl-7500u)
                pass       -> SKIP       (fi-kbl-r)
                pass       -> SKIP       (fi-glk-2a)
Test drv_getparams_basic:
        Subgroup basic-eu-total:
                pass       -> SKIP       (fi-ilk-650)
                pass       -> SKIP       (fi-snb-2520m)
                pass       -> SKIP       (fi-snb-2600)
                pass       -> SKIP       (fi-ivb-3520m)
                pass       -> SKIP       (fi-ivb-3770)
                pass       -> SKIP       (fi-byt-j1900)
                pass       -> SKIP       (fi-byt-n2820)
                pass       -> SKIP       (fi-hsw-4770)
                pass       -> SKIP       (fi-hsw-4770r)
                pass       -> SKIP       (fi-bdw-5557u)
                pass       -> SKIP       (fi-bsw-n3050)
                pass       -> SKIP       (fi-skl-6700hq)
                pass       -> SKIP       (fi-skl-6700k)
                pass       -> SKIP       (fi-bxt-j4205)
                pass       -> SKIP       (fi-kbl-7500u)
                pass       -> SKIP       (fi-kbl-r)
                pass       -> SKIP       (fi-glk-2a)
        Subgroup basic-subslice-total:
                pass       -> SKIP       (fi-ilk-650)
                pass       -> SKIP       (fi-snb-2520m)
                pass       -> SKIP       (fi-snb-2600)
                pass       -> SKIP       (fi-ivb-3520m)
                pass       -> SKIP       (fi-ivb-3770)
                pass       -> SKIP       (fi-byt-j1900)
                pass       -> SKIP       (fi-byt-n2820)
                pass       -> SKIP       (fi-hsw-4770)
                pass       -> SKIP       (fi-hsw-4770r)
                pass       -> SKIP       (fi-bdw-5557u)
                pass       -> SKIP       (fi-bsw-n3050)
                pass       -> SKIP       (fi-skl-6700hq)
                pass       -> SKIP       (fi-skl-6700k)
                pass       -> SKIP       (fi-bxt-j4205)
                pass       -> SKIP       (fi-kbl-7500u)
                pass       -> SKIP       (fi-kbl-r)
                pass       -> SKIP       (fi-glk-2a)
Test drv_hangman:
        Subgroup error-state-basic:
                pass       -> SKIP       (fi-ilk-650)
                pass       -> SKIP       (fi-snb-2520m)
                pass       -> SKIP       (fi-snb-2600)
                pass       -> SKIP       (fi-ivb-3520m)
                pass       -> SKIP       (fi-ivb-3770)
                pass       -> SKIP       (fi-byt-j1900)
                pass       -> SKIP       (fi-byt-n2820)
                pass       -> SKIP       (fi-hsw-4770)
                pass       -> SKIP       (fi-hsw-4770r)
                pass       -> SKIP       (fi-bdw-5557u)
                pass       -> SKIP       (fi-bsw-n3050)
                pass       -> SKIP       (fi-skl-6700hq)
                pass       -> SKIP       (fi-skl-6700k)
                pass       -> SKIP       (fi-bxt-j4205)
                pass       -> SKIP       (fi-kbl-7500u)
                pass       -> SKIP       (fi-kbl-r)
                pass       -> SKIP       (fi-glk-2a)
Test gem_basic:
        Subgroup bad-close:
                pass       -> SKIP       (fi-ilk-650)
WARNING: Long output truncated
fi-skl-6260u failed to collect. IGT log at Patchwork_5016/fi-skl-6260u/igt.log

40b1ea11ae139b383d62f22ed2007db408f42a3e drm-tip: 2017y-06m-21d-14h-16m-17s UTC integration manifest
bc18335 BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5016/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-21 15:30     ` Takashi Iwai
@ 2017-06-26 16:16       ` Daniel Vetter
  -1 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-26 16:16 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Chris Wilson, Intel Graphics Development, Daniel Vetter,
	Guneshwor Singh, Hardik T Shah, Libin Yang, Subhransu S. Prusty,
	Vinod Koul, Julia Lawall, Jaroslav Kysela, linux-kernel

On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> On Wed, 21 Jun 2017 17:23:57 +0200,
> Chris Wilson wrote:
> > 
> > Quoting Daniel Vetter (2017-06-21 16:08:54)
> > > So back when the i915 power well support landed in
> > > 
> > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > > Date:   Thu May 30 22:07:10 2013 +0800
> > > 
> > >     ALSA: hda - Add power-welll support for haswell HDA
> > > 
> > > the logic to handle the cross-module depencies was hand-rolled using a
> > > async work item, and that just doesn't work.
> > > 
> > > The correct way to handle cross-module deps is either:
> > > - request_module + failing when the other module isn't there
> > > 
> > > OR
> > > 
> > > - failing the module load with EPROBE_DEFER.
> > > 
> > > You can't mix them, if you do then the entire load path just
> > > busy-spins blowing through cpu cycles forever with no way to stop
> > > this.
> > > 
> > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > > using request_module, but the i915 depency is handled using
> > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > > This is a major pain when trying to debug i915 load failures.
> > > 
> > > This patch here is a horrible hackish attempt at somewhat correctly
> > > wriing EPROBE_DEFER through. Stuff that's missing:
> > > - Check all the other places where load errors are conveniently
> > >   dropped on the floor.
> > > - Also fix up the firmware_cb path.
> > > - Drop the debug noise I've left in to make it clear this isn't
> > >   anything for merging.
> > 
> > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> > continuously spewing previously, and now the system is usable again.
> 
> Could you give a failing scenario?  I'm not opposing to the suggested
> solution, we need to fix the mess in anyway, but I just would like to
> know how to trigger the problem easily.

Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
collective blow through 100% of the cpu time spewing into dmesg (and make
the system completely unuseable for kernel work because you can't find
your own debug printk anymore).

This is on a snb, where we don't even need the cross-module stuff ... But
I think it goes sideways in other cases too, if you simply build but don't
load i915. So every time an i915 breaks module load things become real
painful.

Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
so plan B would be to stop building snd-hda (which will make the intel
audio team unhappy, but mea culpa if they don't fix this mess).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-26 16:16       ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-26 16:16 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, linux-kernel, Julia Lawall, Daniel Vetter,
	Jaroslav Kysela, Subhransu S. Prusty

On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> On Wed, 21 Jun 2017 17:23:57 +0200,
> Chris Wilson wrote:
> > 
> > Quoting Daniel Vetter (2017-06-21 16:08:54)
> > > So back when the i915 power well support landed in
> > > 
> > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > > Date:   Thu May 30 22:07:10 2013 +0800
> > > 
> > >     ALSA: hda - Add power-welll support for haswell HDA
> > > 
> > > the logic to handle the cross-module depencies was hand-rolled using a
> > > async work item, and that just doesn't work.
> > > 
> > > The correct way to handle cross-module deps is either:
> > > - request_module + failing when the other module isn't there
> > > 
> > > OR
> > > 
> > > - failing the module load with EPROBE_DEFER.
> > > 
> > > You can't mix them, if you do then the entire load path just
> > > busy-spins blowing through cpu cycles forever with no way to stop
> > > this.
> > > 
> > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > > using request_module, but the i915 depency is handled using
> > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > > This is a major pain when trying to debug i915 load failures.
> > > 
> > > This patch here is a horrible hackish attempt at somewhat correctly
> > > wriing EPROBE_DEFER through. Stuff that's missing:
> > > - Check all the other places where load errors are conveniently
> > >   dropped on the floor.
> > > - Also fix up the firmware_cb path.
> > > - Drop the debug noise I've left in to make it clear this isn't
> > >   anything for merging.
> > 
> > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> > continuously spewing previously, and now the system is usable again.
> 
> Could you give a failing scenario?  I'm not opposing to the suggested
> solution, we need to fix the mess in anyway, but I just would like to
> know how to trigger the problem easily.

Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
collective blow through 100% of the cpu time spewing into dmesg (and make
the system completely unuseable for kernel work because you can't find
your own debug printk anymore).

This is on a snb, where we don't even need the cross-module stuff ... But
I think it goes sideways in other cases too, if you simply build but don't
load i915. So every time an i915 breaks module load things become real
painful.

Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
so plan B would be to stop building snd-hda (which will make the intel
audio team unhappy, but mea culpa if they don't fix this mess).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-26 16:16       ` Daniel Vetter
@ 2017-06-26 17:47         ` Takashi Iwai
  -1 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-06-26 17:47 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Chris Wilson, Intel Graphics Development, Daniel Vetter,
	Guneshwor Singh, Hardik T Shah, Libin Yang, Subhransu S. Prusty,
	Vinod Koul, Julia Lawall, Jaroslav Kysela, linux-kernel

On Mon, 26 Jun 2017 18:16:30 +0200,
Daniel Vetter wrote:
> 
> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> > On Wed, 21 Jun 2017 17:23:57 +0200,
> > Chris Wilson wrote:
> > > 
> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> > > > So back when the i915 power well support landed in
> > > > 
> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > > > Date:   Thu May 30 22:07:10 2013 +0800
> > > > 
> > > >     ALSA: hda - Add power-welll support for haswell HDA
> > > > 
> > > > the logic to handle the cross-module depencies was hand-rolled using a
> > > > async work item, and that just doesn't work.
> > > > 
> > > > The correct way to handle cross-module deps is either:
> > > > - request_module + failing when the other module isn't there
> > > > 
> > > > OR
> > > > 
> > > > - failing the module load with EPROBE_DEFER.
> > > > 
> > > > You can't mix them, if you do then the entire load path just
> > > > busy-spins blowing through cpu cycles forever with no way to stop
> > > > this.
> > > > 
> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > > > using request_module, but the i915 depency is handled using
> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > > > This is a major pain when trying to debug i915 load failures.
> > > > 
> > > > This patch here is a horrible hackish attempt at somewhat correctly
> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> > > > - Check all the other places where load errors are conveniently
> > > >   dropped on the floor.
> > > > - Also fix up the firmware_cb path.
> > > > - Drop the debug noise I've left in to make it clear this isn't
> > > >   anything for merging.
> > > 
> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> > > continuously spewing previously, and now the system is usable again.
> > 
> > Could you give a failing scenario?  I'm not opposing to the suggested
> > solution, we need to fix the mess in anyway, but I just would like to
> > know how to trigger the problem easily.
> 
> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> collective blow through 100% of the cpu time spewing into dmesg (and make
> the system completely unuseable for kernel work because you can't find
> your own debug printk anymore).

Ah, that's the case we discussed in the past.  We know that it's
problematic for component binding, but we're ignoring this scenario
because it's supposed to be no real use-case but only for some
temporary workarounds.

We had some bigger-hammer patchset, but it didn't justify for the
further development of the reasoning above.

> This is on a snb, where we don't even need the cross-module stuff ... But
> I think it goes sideways in other cases too, if you simply build but don't
> load i915. So every time an i915 breaks module load things become real
> painful.

Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
hardware inquiry over HD-audio verb was so unstable, so we rather take
a path directly inquiring to the gfx driver.

> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> so plan B would be to stop building snd-hda (which will make the intel
> audio team unhappy, but mea culpa if they don't fix this mess).

OK, let me think and take a look for older patchset, too.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-26 17:47         ` Takashi Iwai
  0 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-06-26 17:47 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, linux-kernel, Julia Lawall, Daniel Vetter,
	Jaroslav Kysela, Subhransu S. Prusty

On Mon, 26 Jun 2017 18:16:30 +0200,
Daniel Vetter wrote:
> 
> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> > On Wed, 21 Jun 2017 17:23:57 +0200,
> > Chris Wilson wrote:
> > > 
> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> > > > So back when the i915 power well support landed in
> > > > 
> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > > > Date:   Thu May 30 22:07:10 2013 +0800
> > > > 
> > > >     ALSA: hda - Add power-welll support for haswell HDA
> > > > 
> > > > the logic to handle the cross-module depencies was hand-rolled using a
> > > > async work item, and that just doesn't work.
> > > > 
> > > > The correct way to handle cross-module deps is either:
> > > > - request_module + failing when the other module isn't there
> > > > 
> > > > OR
> > > > 
> > > > - failing the module load with EPROBE_DEFER.
> > > > 
> > > > You can't mix them, if you do then the entire load path just
> > > > busy-spins blowing through cpu cycles forever with no way to stop
> > > > this.
> > > > 
> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > > > using request_module, but the i915 depency is handled using
> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > > > This is a major pain when trying to debug i915 load failures.
> > > > 
> > > > This patch here is a horrible hackish attempt at somewhat correctly
> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> > > > - Check all the other places where load errors are conveniently
> > > >   dropped on the floor.
> > > > - Also fix up the firmware_cb path.
> > > > - Drop the debug noise I've left in to make it clear this isn't
> > > >   anything for merging.
> > > 
> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> > > continuously spewing previously, and now the system is usable again.
> > 
> > Could you give a failing scenario?  I'm not opposing to the suggested
> > solution, we need to fix the mess in anyway, but I just would like to
> > know how to trigger the problem easily.
> 
> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> collective blow through 100% of the cpu time spewing into dmesg (and make
> the system completely unuseable for kernel work because you can't find
> your own debug printk anymore).

Ah, that's the case we discussed in the past.  We know that it's
problematic for component binding, but we're ignoring this scenario
because it's supposed to be no real use-case but only for some
temporary workarounds.

We had some bigger-hammer patchset, but it didn't justify for the
further development of the reasoning above.

> This is on a snb, where we don't even need the cross-module stuff ... But
> I think it goes sideways in other cases too, if you simply build but don't
> load i915. So every time an i915 breaks module load things become real
> painful.

Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
hardware inquiry over HD-audio verb was so unstable, so we rather take
a path directly inquiring to the gfx driver.

> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> so plan B would be to stop building snd-hda (which will make the intel
> audio team unhappy, but mea culpa if they don't fix this mess).

OK, let me think and take a look for older patchset, too.


thanks,

Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-26 17:47         ` Takashi Iwai
@ 2017-06-26 17:54           ` Daniel Vetter
  -1 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-26 17:54 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Chris Wilson, Intel Graphics Development, Guneshwor Singh,
	Hardik T Shah, Libin Yang, Subhransu S. Prusty, Vinod Koul,
	Julia Lawall, Jaroslav Kysela, Linux Kernel Mailing List

On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 26 Jun 2017 18:16:30 +0200,
> Daniel Vetter wrote:
>>
>> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
>> > On Wed, 21 Jun 2017 17:23:57 +0200,
>> > Chris Wilson wrote:
>> > >
>> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
>> > > > So back when the i915 power well support landed in
>> > > >
>> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
>> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
>> > > > Date:   Thu May 30 22:07:10 2013 +0800
>> > > >
>> > > >     ALSA: hda - Add power-welll support for haswell HDA
>> > > >
>> > > > the logic to handle the cross-module depencies was hand-rolled using a
>> > > > async work item, and that just doesn't work.
>> > > >
>> > > > The correct way to handle cross-module deps is either:
>> > > > - request_module + failing when the other module isn't there
>> > > >
>> > > > OR
>> > > >
>> > > > - failing the module load with EPROBE_DEFER.
>> > > >
>> > > > You can't mix them, if you do then the entire load path just
>> > > > busy-spins blowing through cpu cycles forever with no way to stop
>> > > > this.
>> > > >
>> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
>> > > > using request_module, but the i915 depency is handled using
>> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
>> > > > This is a major pain when trying to debug i915 load failures.
>> > > >
>> > > > This patch here is a horrible hackish attempt at somewhat correctly
>> > > > wriing EPROBE_DEFER through. Stuff that's missing:
>> > > > - Check all the other places where load errors are conveniently
>> > > >   dropped on the floor.
>> > > > - Also fix up the firmware_cb path.
>> > > > - Drop the debug noise I've left in to make it clear this isn't
>> > > >   anything for merging.
>> > >
>> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
>> > > continuously spewing previously, and now the system is usable again.
>> >
>> > Could you give a failing scenario?  I'm not opposing to the suggested
>> > solution, we need to fix the mess in anyway, but I just would like to
>> > know how to trigger the problem easily.
>>
>> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
>> collective blow through 100% of the cpu time spewing into dmesg (and make
>> the system completely unuseable for kernel work because you can't find
>> your own debug printk anymore).
>
> Ah, that's the case we discussed in the past.  We know that it's
> problematic for component binding, but we're ignoring this scenario
> because it's supposed to be no real use-case but only for some
> temporary workarounds.
>
> We had some bigger-hammer patchset, but it didn't justify for the
> further development of the reasoning above.
>
>> This is on a snb, where we don't even need the cross-module stuff ... But
>> I think it goes sideways in other cases too, if you simply build but don't
>> load i915. So every time an i915 breaks module load things become real
>> painful.
>
> Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> hardware inquiry over HD-audio verb was so unstable, so we rather take
> a path directly inquiring to the gfx driver.

Ah right, forgot about that.

>> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
>> so plan B would be to stop building snd-hda (which will make the intel
>> audio team unhappy, but mea culpa if they don't fix this mess).
>
> OK, let me think and take a look for older patchset, too.

Yeah would be great if we can somehow address this, preferrably using
EPROBE_DEFER or something else that's standard. At least the component
stuff really doesn't work without wiring EPROBE_DEFER through.

And if that patch series requires some soaking I think I could easily
add it to our drm-tip CI branch for testing (and making our developers
lifes easier), we already pull in your -next/-fixes trees anyway.
Pulling in another topic branch would be simple.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-26 17:54           ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-26 17:54 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, Linux Kernel Mailing List, Julia Lawall,
	Jaroslav Kysela, Subhransu S. Prusty

On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 26 Jun 2017 18:16:30 +0200,
> Daniel Vetter wrote:
>>
>> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
>> > On Wed, 21 Jun 2017 17:23:57 +0200,
>> > Chris Wilson wrote:
>> > >
>> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
>> > > > So back when the i915 power well support landed in
>> > > >
>> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
>> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
>> > > > Date:   Thu May 30 22:07:10 2013 +0800
>> > > >
>> > > >     ALSA: hda - Add power-welll support for haswell HDA
>> > > >
>> > > > the logic to handle the cross-module depencies was hand-rolled using a
>> > > > async work item, and that just doesn't work.
>> > > >
>> > > > The correct way to handle cross-module deps is either:
>> > > > - request_module + failing when the other module isn't there
>> > > >
>> > > > OR
>> > > >
>> > > > - failing the module load with EPROBE_DEFER.
>> > > >
>> > > > You can't mix them, if you do then the entire load path just
>> > > > busy-spins blowing through cpu cycles forever with no way to stop
>> > > > this.
>> > > >
>> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
>> > > > using request_module, but the i915 depency is handled using
>> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
>> > > > This is a major pain when trying to debug i915 load failures.
>> > > >
>> > > > This patch here is a horrible hackish attempt at somewhat correctly
>> > > > wriing EPROBE_DEFER through. Stuff that's missing:
>> > > > - Check all the other places where load errors are conveniently
>> > > >   dropped on the floor.
>> > > > - Also fix up the firmware_cb path.
>> > > > - Drop the debug noise I've left in to make it clear this isn't
>> > > >   anything for merging.
>> > >
>> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
>> > > continuously spewing previously, and now the system is usable again.
>> >
>> > Could you give a failing scenario?  I'm not opposing to the suggested
>> > solution, we need to fix the mess in anyway, but I just would like to
>> > know how to trigger the problem easily.
>>
>> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
>> collective blow through 100% of the cpu time spewing into dmesg (and make
>> the system completely unuseable for kernel work because you can't find
>> your own debug printk anymore).
>
> Ah, that's the case we discussed in the past.  We know that it's
> problematic for component binding, but we're ignoring this scenario
> because it's supposed to be no real use-case but only for some
> temporary workarounds.
>
> We had some bigger-hammer patchset, but it didn't justify for the
> further development of the reasoning above.
>
>> This is on a snb, where we don't even need the cross-module stuff ... But
>> I think it goes sideways in other cases too, if you simply build but don't
>> load i915. So every time an i915 breaks module load things become real
>> painful.
>
> Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> hardware inquiry over HD-audio verb was so unstable, so we rather take
> a path directly inquiring to the gfx driver.

Ah right, forgot about that.

>> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
>> so plan B would be to stop building snd-hda (which will make the intel
>> audio team unhappy, but mea culpa if they don't fix this mess).
>
> OK, let me think and take a look for older patchset, too.

Yeah would be great if we can somehow address this, preferrably using
EPROBE_DEFER or something else that's standard. At least the component
stuff really doesn't work without wiring EPROBE_DEFER through.

And if that patch series requires some soaking I think I could easily
add it to our drm-tip CI branch for testing (and making our developers
lifes easier), we already pull in your -next/-fixes trees anyway.
Pulling in another topic branch would be simple.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-26 17:54           ` Daniel Vetter
@ 2017-06-28 10:16             ` Takashi Iwai
  -1 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-06-28 10:16 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Chris Wilson, Intel Graphics Development, Guneshwor Singh,
	Hardik T Shah, Libin Yang, Subhransu S. Prusty, Vinod Koul,
	Julia Lawall, Jaroslav Kysela, Linux Kernel Mailing List

On Mon, 26 Jun 2017 19:54:49 +0200,
Daniel Vetter wrote:
> 
> On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Mon, 26 Jun 2017 18:16:30 +0200,
> > Daniel Vetter wrote:
> >>
> >> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> >> > On Wed, 21 Jun 2017 17:23:57 +0200,
> >> > Chris Wilson wrote:
> >> > >
> >> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> >> > > > So back when the i915 power well support landed in
> >> > > >
> >> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> >> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> >> > > > Date:   Thu May 30 22:07:10 2013 +0800
> >> > > >
> >> > > >     ALSA: hda - Add power-welll support for haswell HDA
> >> > > >
> >> > > > the logic to handle the cross-module depencies was hand-rolled using a
> >> > > > async work item, and that just doesn't work.
> >> > > >
> >> > > > The correct way to handle cross-module deps is either:
> >> > > > - request_module + failing when the other module isn't there
> >> > > >
> >> > > > OR
> >> > > >
> >> > > > - failing the module load with EPROBE_DEFER.
> >> > > >
> >> > > > You can't mix them, if you do then the entire load path just
> >> > > > busy-spins blowing through cpu cycles forever with no way to stop
> >> > > > this.
> >> > > >
> >> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> >> > > > using request_module, but the i915 depency is handled using
> >> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> >> > > > This is a major pain when trying to debug i915 load failures.
> >> > > >
> >> > > > This patch here is a horrible hackish attempt at somewhat correctly
> >> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> >> > > > - Check all the other places where load errors are conveniently
> >> > > >   dropped on the floor.
> >> > > > - Also fix up the firmware_cb path.
> >> > > > - Drop the debug noise I've left in to make it clear this isn't
> >> > > >   anything for merging.
> >> > >
> >> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> >> > > continuously spewing previously, and now the system is usable again.
> >> >
> >> > Could you give a failing scenario?  I'm not opposing to the suggested
> >> > solution, we need to fix the mess in anyway, but I just would like to
> >> > know how to trigger the problem easily.
> >>
> >> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> >> collective blow through 100% of the cpu time spewing into dmesg (and make
> >> the system completely unuseable for kernel work because you can't find
> >> your own debug printk anymore).
> >
> > Ah, that's the case we discussed in the past.  We know that it's
> > problematic for component binding, but we're ignoring this scenario
> > because it's supposed to be no real use-case but only for some
> > temporary workarounds.
> >
> > We had some bigger-hammer patchset, but it didn't justify for the
> > further development of the reasoning above.
> >
> >> This is on a snb, where we don't even need the cross-module stuff ... But
> >> I think it goes sideways in other cases too, if you simply build but don't
> >> load i915. So every time an i915 breaks module load things become real
> >> painful.
> >
> > Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> > hardware inquiry over HD-audio verb was so unstable, so we rather take
> > a path directly inquiring to the gfx driver.
> 
> Ah right, forgot about that.
> 
> >> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> >> so plan B would be to stop building snd-hda (which will make the intel
> >> audio team unhappy, but mea culpa if they don't fix this mess).
> >
> > OK, let me think and take a look for older patchset, too.
> 
> Yeah would be great if we can somehow address this, preferrably using
> EPROBE_DEFER or something else that's standard. At least the component
> stuff really doesn't work without wiring EPROBE_DEFER through.

Now I took a closer look, and this appears rather like a brown paper
bag bug, not about the deferred probe or module dependency.
The fix patch is below.  Could you check whether it works?


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: hda - Fix endless loop of codec configure

azx_codec_configure() loops over the codecs found on the given
controller via a linked list.  The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.

The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus.  Since the list is initialized via list_del_init(), the
next object points to the same device itself.  This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.

For fixing this bug, just use a *_safe() version of list iteration.

Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_codec.h      | 2 ++
 sound/pci/hda/hda_controller.c | 8 ++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index d6fb2d5d01a7..60ce1cfc300f 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -295,6 +295,8 @@ struct hda_codec {
 
 #define list_for_each_codec(c, bus) \
 	list_for_each_entry(c, &(bus)->core.codec_list, core.list)
+#define list_for_each_codec_safe(c, n, bus)				\
+	list_for_each_entry_safe(c, n, &(bus)->core.codec_list, core.list)
 
 /* snd_hda_codec_read/write optional flags */
 #define HDA_RW_NO_RESPONSE_FALLBACK	(1 << 0)
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 3715a5725613..1c60beb5b70a 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -1337,8 +1337,12 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
 /* configure each codec instance */
 int azx_codec_configure(struct azx *chip)
 {
-	struct hda_codec *codec;
-	list_for_each_codec(codec, &chip->bus) {
+	struct hda_codec *codec, *next;
+
+	/* use _safe version here since snd_hda_codec_configure() deregisters
+	 * the device upon error and deletes itself from the bus list.
+	 */
+	list_for_each_codec_safe(codec, next, &chip->bus) {
 		snd_hda_codec_configure(codec);
 	}
 	return 0;
-- 
2.13.2

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-28 10:16             ` Takashi Iwai
  0 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-06-28 10:16 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, Linux Kernel Mailing List, Julia Lawall,
	Jaroslav Kysela, Subhransu S. Prusty

On Mon, 26 Jun 2017 19:54:49 +0200,
Daniel Vetter wrote:
> 
> On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Mon, 26 Jun 2017 18:16:30 +0200,
> > Daniel Vetter wrote:
> >>
> >> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> >> > On Wed, 21 Jun 2017 17:23:57 +0200,
> >> > Chris Wilson wrote:
> >> > >
> >> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> >> > > > So back when the i915 power well support landed in
> >> > > >
> >> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> >> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> >> > > > Date:   Thu May 30 22:07:10 2013 +0800
> >> > > >
> >> > > >     ALSA: hda - Add power-welll support for haswell HDA
> >> > > >
> >> > > > the logic to handle the cross-module depencies was hand-rolled using a
> >> > > > async work item, and that just doesn't work.
> >> > > >
> >> > > > The correct way to handle cross-module deps is either:
> >> > > > - request_module + failing when the other module isn't there
> >> > > >
> >> > > > OR
> >> > > >
> >> > > > - failing the module load with EPROBE_DEFER.
> >> > > >
> >> > > > You can't mix them, if you do then the entire load path just
> >> > > > busy-spins blowing through cpu cycles forever with no way to stop
> >> > > > this.
> >> > > >
> >> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> >> > > > using request_module, but the i915 depency is handled using
> >> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> >> > > > This is a major pain when trying to debug i915 load failures.
> >> > > >
> >> > > > This patch here is a horrible hackish attempt at somewhat correctly
> >> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> >> > > > - Check all the other places where load errors are conveniently
> >> > > >   dropped on the floor.
> >> > > > - Also fix up the firmware_cb path.
> >> > > > - Drop the debug noise I've left in to make it clear this isn't
> >> > > >   anything for merging.
> >> > >
> >> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> >> > > continuously spewing previously, and now the system is usable again.
> >> >
> >> > Could you give a failing scenario?  I'm not opposing to the suggested
> >> > solution, we need to fix the mess in anyway, but I just would like to
> >> > know how to trigger the problem easily.
> >>
> >> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> >> collective blow through 100% of the cpu time spewing into dmesg (and make
> >> the system completely unuseable for kernel work because you can't find
> >> your own debug printk anymore).
> >
> > Ah, that's the case we discussed in the past.  We know that it's
> > problematic for component binding, but we're ignoring this scenario
> > because it's supposed to be no real use-case but only for some
> > temporary workarounds.
> >
> > We had some bigger-hammer patchset, but it didn't justify for the
> > further development of the reasoning above.
> >
> >> This is on a snb, where we don't even need the cross-module stuff ... But
> >> I think it goes sideways in other cases too, if you simply build but don't
> >> load i915. So every time an i915 breaks module load things become real
> >> painful.
> >
> > Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> > hardware inquiry over HD-audio verb was so unstable, so we rather take
> > a path directly inquiring to the gfx driver.
> 
> Ah right, forgot about that.
> 
> >> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> >> so plan B would be to stop building snd-hda (which will make the intel
> >> audio team unhappy, but mea culpa if they don't fix this mess).
> >
> > OK, let me think and take a look for older patchset, too.
> 
> Yeah would be great if we can somehow address this, preferrably using
> EPROBE_DEFER or something else that's standard. At least the component
> stuff really doesn't work without wiring EPROBE_DEFER through.

Now I took a closer look, and this appears rather like a brown paper
bag bug, not about the deferred probe or module dependency.
The fix patch is below.  Could you check whether it works?


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: hda - Fix endless loop of codec configure

azx_codec_configure() loops over the codecs found on the given
controller via a linked list.  The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.

The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus.  Since the list is initialized via list_del_init(), the
next object points to the same device itself.  This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.

For fixing this bug, just use a *_safe() version of list iteration.

Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/hda/hda_codec.h      | 2 ++
 sound/pci/hda/hda_controller.c | 8 ++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index d6fb2d5d01a7..60ce1cfc300f 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -295,6 +295,8 @@ struct hda_codec {
 
 #define list_for_each_codec(c, bus) \
 	list_for_each_entry(c, &(bus)->core.codec_list, core.list)
+#define list_for_each_codec_safe(c, n, bus)				\
+	list_for_each_entry_safe(c, n, &(bus)->core.codec_list, core.list)
 
 /* snd_hda_codec_read/write optional flags */
 #define HDA_RW_NO_RESPONSE_FALLBACK	(1 << 0)
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
index 3715a5725613..1c60beb5b70a 100644
--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -1337,8 +1337,12 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
 /* configure each codec instance */
 int azx_codec_configure(struct azx *chip)
 {
-	struct hda_codec *codec;
-	list_for_each_codec(codec, &chip->bus) {
+	struct hda_codec *codec, *next;
+
+	/* use _safe version here since snd_hda_codec_configure() deregisters
+	 * the device upon error and deletes itself from the bus list.
+	 */
+	list_for_each_codec_safe(codec, next, &chip->bus) {
 		snd_hda_codec_configure(codec);
 	}
 	return 0;
-- 
2.13.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-28 10:16             ` Takashi Iwai
@ 2017-06-29 10:25               ` Daniel Vetter
  -1 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-29 10:25 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Daniel Vetter, Chris Wilson, Intel Graphics Development,
	Guneshwor Singh, Hardik T Shah, Libin Yang, Subhransu S. Prusty,
	Vinod Koul, Julia Lawall, Jaroslav Kysela,
	Linux Kernel Mailing List

On Wed, Jun 28, 2017 at 12:16:17PM +0200, Takashi Iwai wrote:
> On Mon, 26 Jun 2017 19:54:49 +0200,
> Daniel Vetter wrote:
> > 
> > On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > > On Mon, 26 Jun 2017 18:16:30 +0200,
> > > Daniel Vetter wrote:
> > >>
> > >> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> > >> > On Wed, 21 Jun 2017 17:23:57 +0200,
> > >> > Chris Wilson wrote:
> > >> > >
> > >> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> > >> > > > So back when the i915 power well support landed in
> > >> > > >
> > >> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > >> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > >> > > > Date:   Thu May 30 22:07:10 2013 +0800
> > >> > > >
> > >> > > >     ALSA: hda - Add power-welll support for haswell HDA
> > >> > > >
> > >> > > > the logic to handle the cross-module depencies was hand-rolled using a
> > >> > > > async work item, and that just doesn't work.
> > >> > > >
> > >> > > > The correct way to handle cross-module deps is either:
> > >> > > > - request_module + failing when the other module isn't there
> > >> > > >
> > >> > > > OR
> > >> > > >
> > >> > > > - failing the module load with EPROBE_DEFER.
> > >> > > >
> > >> > > > You can't mix them, if you do then the entire load path just
> > >> > > > busy-spins blowing through cpu cycles forever with no way to stop
> > >> > > > this.
> > >> > > >
> > >> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > >> > > > using request_module, but the i915 depency is handled using
> > >> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > >> > > > This is a major pain when trying to debug i915 load failures.
> > >> > > >
> > >> > > > This patch here is a horrible hackish attempt at somewhat correctly
> > >> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> > >> > > > - Check all the other places where load errors are conveniently
> > >> > > >   dropped on the floor.
> > >> > > > - Also fix up the firmware_cb path.
> > >> > > > - Drop the debug noise I've left in to make it clear this isn't
> > >> > > >   anything for merging.
> > >> > >
> > >> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> > >> > > continuously spewing previously, and now the system is usable again.
> > >> >
> > >> > Could you give a failing scenario?  I'm not opposing to the suggested
> > >> > solution, we need to fix the mess in anyway, but I just would like to
> > >> > know how to trigger the problem easily.
> > >>
> > >> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> > >> collective blow through 100% of the cpu time spewing into dmesg (and make
> > >> the system completely unuseable for kernel work because you can't find
> > >> your own debug printk anymore).
> > >
> > > Ah, that's the case we discussed in the past.  We know that it's
> > > problematic for component binding, but we're ignoring this scenario
> > > because it's supposed to be no real use-case but only for some
> > > temporary workarounds.
> > >
> > > We had some bigger-hammer patchset, but it didn't justify for the
> > > further development of the reasoning above.
> > >
> > >> This is on a snb, where we don't even need the cross-module stuff ... But
> > >> I think it goes sideways in other cases too, if you simply build but don't
> > >> load i915. So every time an i915 breaks module load things become real
> > >> painful.
> > >
> > > Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> > > hardware inquiry over HD-audio verb was so unstable, so we rather take
> > > a path directly inquiring to the gfx driver.
> > 
> > Ah right, forgot about that.
> > 
> > >> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> > >> so plan B would be to stop building snd-hda (which will make the intel
> > >> audio team unhappy, but mea culpa if they don't fix this mess).
> > >
> > > OK, let me think and take a look for older patchset, too.
> > 
> > Yeah would be great if we can somehow address this, preferrably using
> > EPROBE_DEFER or something else that's standard. At least the component
> > stuff really doesn't work without wiring EPROBE_DEFER through.
> 
> Now I took a closer look, and this appears rather like a brown paper
> bag bug, not about the deferred probe or module dependency.
> The fix patch is below.  Could you check whether it works?

Yay, this works!

Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> 
> 
> thanks,
> 
> Takashi
> 
> -- 8< --
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH] ALSA: hda - Fix endless loop of codec configure
> 
> azx_codec_configure() loops over the codecs found on the given
> controller via a linked list.  The code used to work in the past, but
> in the current version, this may lead to an endless loop when a codec
> binding returns an error.
> 
> The culprit is that the snd_hda_codec_configure() unregisters the
> device upon error, and this eventually deletes the given codec object
> from the bus.  Since the list is initialized via list_del_init(), the
> next object points to the same device itself.  This behavior change
> was introduced at splitting the HD-audio code code, and forgotten to
> adapt it here.
> 
> For fixing this bug, just use a *_safe() version of list iteration.
> 
> Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
> Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/pci/hda/hda_codec.h      | 2 ++
>  sound/pci/hda/hda_controller.c | 8 ++++++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
> index d6fb2d5d01a7..60ce1cfc300f 100644
> --- a/sound/pci/hda/hda_codec.h
> +++ b/sound/pci/hda/hda_codec.h
> @@ -295,6 +295,8 @@ struct hda_codec {
>  
>  #define list_for_each_codec(c, bus) \
>  	list_for_each_entry(c, &(bus)->core.codec_list, core.list)
> +#define list_for_each_codec_safe(c, n, bus)				\
> +	list_for_each_entry_safe(c, n, &(bus)->core.codec_list, core.list)
>  
>  /* snd_hda_codec_read/write optional flags */
>  #define HDA_RW_NO_RESPONSE_FALLBACK	(1 << 0)
> diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
> index 3715a5725613..1c60beb5b70a 100644
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -1337,8 +1337,12 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
>  /* configure each codec instance */
>  int azx_codec_configure(struct azx *chip)
>  {
> -	struct hda_codec *codec;
> -	list_for_each_codec(codec, &chip->bus) {
> +	struct hda_codec *codec, *next;
> +
> +	/* use _safe version here since snd_hda_codec_configure() deregisters
> +	 * the device upon error and deletes itself from the bus list.
> +	 */
> +	list_for_each_codec_safe(codec, next, &chip->bus) {
>  		snd_hda_codec_configure(codec);
>  	}
>  	return 0;
> -- 
> 2.13.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-06-29 10:25               ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-06-29 10:25 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, Linux Kernel Mailing List, Julia Lawall,
	Jaroslav Kysela, Subhransu S. Prusty

On Wed, Jun 28, 2017 at 12:16:17PM +0200, Takashi Iwai wrote:
> On Mon, 26 Jun 2017 19:54:49 +0200,
> Daniel Vetter wrote:
> > 
> > On Mon, Jun 26, 2017 at 7:47 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > > On Mon, 26 Jun 2017 18:16:30 +0200,
> > > Daniel Vetter wrote:
> > >>
> > >> On Wed, Jun 21, 2017 at 05:30:10PM +0200, Takashi Iwai wrote:
> > >> > On Wed, 21 Jun 2017 17:23:57 +0200,
> > >> > Chris Wilson wrote:
> > >> > >
> > >> > > Quoting Daniel Vetter (2017-06-21 16:08:54)
> > >> > > > So back when the i915 power well support landed in
> > >> > > >
> > >> > > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6
> > >> > > > Author: Wang Xingchao <xingchao.wang@linux.intel.com>
> > >> > > > Date:   Thu May 30 22:07:10 2013 +0800
> > >> > > >
> > >> > > >     ALSA: hda - Add power-welll support for haswell HDA
> > >> > > >
> > >> > > > the logic to handle the cross-module depencies was hand-rolled using a
> > >> > > > async work item, and that just doesn't work.
> > >> > > >
> > >> > > > The correct way to handle cross-module deps is either:
> > >> > > > - request_module + failing when the other module isn't there
> > >> > > >
> > >> > > > OR
> > >> > > >
> > >> > > > - failing the module load with EPROBE_DEFER.
> > >> > > >
> > >> > > > You can't mix them, if you do then the entire load path just
> > >> > > > busy-spins blowing through cpu cycles forever with no way to stop
> > >> > > > this.
> > >> > > >
> > >> > > > snd-hda-intel does mix it, because the hda codec drivers are loaded
> > >> > > > using request_module, but the i915 depency is handled using
> > >> > > > PROBE_DEFER (or well, should be, but I haven't found any code at all).
> > >> > > > This is a major pain when trying to debug i915 load failures.
> > >> > > >
> > >> > > > This patch here is a horrible hackish attempt at somewhat correctly
> > >> > > > wriing EPROBE_DEFER through. Stuff that's missing:
> > >> > > > - Check all the other places where load errors are conveniently
> > >> > > >   dropped on the floor.
> > >> > > > - Also fix up the firmware_cb path.
> > >> > > > - Drop the debug noise I've left in to make it clear this isn't
> > >> > > >   anything for merging.
> > >> > >
> > >> > > This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was
> > >> > > continuously spewing previously, and now the system is usable again.
> > >> >
> > >> > Could you give a failing scenario?  I'm not opposing to the suggested
> > >> > solution, we need to fix the mess in anyway, but I just would like to
> > >> > know how to trigger the problem easily.
> > >>
> > >> Disable i915 loading e.g. with i915.modeset=0. Watch how snd-hda*
> > >> collective blow through 100% of the cpu time spewing into dmesg (and make
> > >> the system completely unuseable for kernel work because you can't find
> > >> your own debug printk anymore).
> > >
> > > Ah, that's the case we discussed in the past.  We know that it's
> > > problematic for component binding, but we're ignoring this scenario
> > > because it's supposed to be no real use-case but only for some
> > > temporary workarounds.
> > >
> > > We had some bigger-hammer patchset, but it didn't justify for the
> > > further development of the reasoning above.
> > >
> > >> This is on a snb, where we don't even need the cross-module stuff ... But
> > >> I think it goes sideways in other cases too, if you simply build but don't
> > >> load i915. So every time an i915 breaks module load things become real
> > >> painful.
> > >
> > > Even on SNB, we still need i915 for the HDMI/DP ELD notification.  The
> > > hardware inquiry over HD-audio verb was so unstable, so we rather take
> > > a path directly inquiring to the gfx driver.
> > 
> > Ah right, forgot about that.
> > 
> > >> Unfortunately the patch is a bit too big for our fixup branch in drm-tip,
> > >> so plan B would be to stop building snd-hda (which will make the intel
> > >> audio team unhappy, but mea culpa if they don't fix this mess).
> > >
> > > OK, let me think and take a look for older patchset, too.
> > 
> > Yeah would be great if we can somehow address this, preferrably using
> > EPROBE_DEFER or something else that's standard. At least the component
> > stuff really doesn't work without wiring EPROBE_DEFER through.
> 
> Now I took a closer look, and this appears rather like a brown paper
> bag bug, not about the deferred probe or module dependency.
> The fix patch is below.  Could you check whether it works?

Yay, this works!

Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> 
> 
> thanks,
> 
> Takashi
> 
> -- 8< --
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH] ALSA: hda - Fix endless loop of codec configure
> 
> azx_codec_configure() loops over the codecs found on the given
> controller via a linked list.  The code used to work in the past, but
> in the current version, this may lead to an endless loop when a codec
> binding returns an error.
> 
> The culprit is that the snd_hda_codec_configure() unregisters the
> device upon error, and this eventually deletes the given codec object
> from the bus.  Since the list is initialized via list_del_init(), the
> next object points to the same device itself.  This behavior change
> was introduced at splitting the HD-audio code code, and forgotten to
> adapt it here.
> 
> For fixing this bug, just use a *_safe() version of list iteration.
> 
> Fixes: d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
> Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  sound/pci/hda/hda_codec.h      | 2 ++
>  sound/pci/hda/hda_controller.c | 8 ++++++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
> index d6fb2d5d01a7..60ce1cfc300f 100644
> --- a/sound/pci/hda/hda_codec.h
> +++ b/sound/pci/hda/hda_codec.h
> @@ -295,6 +295,8 @@ struct hda_codec {
>  
>  #define list_for_each_codec(c, bus) \
>  	list_for_each_entry(c, &(bus)->core.codec_list, core.list)
> +#define list_for_each_codec_safe(c, n, bus)				\
> +	list_for_each_entry_safe(c, n, &(bus)->core.codec_list, core.list)
>  
>  /* snd_hda_codec_read/write optional flags */
>  #define HDA_RW_NO_RESPONSE_FALLBACK	(1 << 0)
> diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
> index 3715a5725613..1c60beb5b70a 100644
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -1337,8 +1337,12 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs);
>  /* configure each codec instance */
>  int azx_codec_configure(struct azx *chip)
>  {
> -	struct hda_codec *codec;
> -	list_for_each_codec(codec, &chip->bus) {
> +	struct hda_codec *codec, *next;
> +
> +	/* use _safe version here since snd_hda_codec_configure() deregisters
> +	 * the device upon error and deletes itself from the bus list.
> +	 */
> +	list_for_each_codec_safe(codec, next, &chip->bus) {
>  		snd_hda_codec_configure(codec);
>  	}
>  	return 0;
> -- 
> 2.13.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-06-29 10:25               ` Daniel Vetter
  (?)
@ 2017-07-04 15:14               ` Daniel Vetter
  2017-07-04 15:28                   ` Takashi Iwai
  -1 siblings, 1 reply; 22+ messages in thread
From: Daniel Vetter @ 2017-07-04 15:14 UTC (permalink / raw)
  To: Takashi Iwai, Chris Wilson, Intel Graphics Development,
	Guneshwor Singh, Hardik T Shah, Libin Yang, Subhransu S. Prusty,
	Vinod Koul, Julia Lawall, Jaroslav Kysela,
	Linux Kernel Mailing List

On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> Now I took a closer look, and this appears rather like a brown paper
>> bag bug, not about the deferred probe or module dependency.
>> The fix patch is below.  Could you check whether it works?
>
> Yay, this works!
>
> Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Next one: i915 module reloading is broken because something is holding
onto a module reference and doesn't drop it. Didn't check which sets
of patches introduced this, but iirc this worked last week. Disabling
hda-intel gets in Kconfig gets rid of the problem, so I assume
something in the sound driver is leaking that reference ...

It's also causing lots and lots of red in our CI :( If we can't fix
this we need to disable snd-hda-intel there too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-07-04 15:14               ` Daniel Vetter
@ 2017-07-04 15:28                   ` Takashi Iwai
  0 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-07-04 15:28 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Chris Wilson, Intel Graphics Development, Guneshwor Singh,
	Hardik T Shah, Libin Yang, Subhransu S. Prusty, Vinod Koul,
	Julia Lawall, Jaroslav Kysela, Linux Kernel Mailing List

On Tue, 04 Jul 2017 17:14:39 +0200,
Daniel Vetter wrote:
> 
> On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> Now I took a closer look, and this appears rather like a brown paper
> >> bag bug, not about the deferred probe or module dependency.
> >> The fix patch is below.  Could you check whether it works?
> >
> > Yay, this works!
> >
> > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Next one: i915 module reloading is broken because something is holding
> onto a module reference and doesn't drop it. Didn't check which sets
> of patches introduced this, but iirc this worked last week. Disabling
> hda-intel gets in Kconfig gets rid of the problem, so I assume
> something in the sound driver is leaking that reference ...
> 
> It's also causing lots and lots of red in our CI :( If we can't fix
> this we need to disable snd-hda-intel there too.

I spotted out a typo in my previous patch that leads to the module
reference unbalance.  The fix is  already in sound.git tree today:
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-linus&id=fc18282cdcba984ab89c74d7e844c10114ae0795

The bug was introduced after 4.12.


thanks,

--
Takashi Iwai <tiwai@suse.de>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-07-04 15:28                   ` Takashi Iwai
  0 siblings, 0 replies; 22+ messages in thread
From: Takashi Iwai @ 2017-07-04 15:28 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, Linux Kernel Mailing List, Julia Lawall,
	Jaroslav Kysela, Subhransu S. Prusty

On Tue, 04 Jul 2017 17:14:39 +0200,
Daniel Vetter wrote:
> 
> On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> Now I took a closer look, and this appears rather like a brown paper
> >> bag bug, not about the deferred probe or module dependency.
> >> The fix patch is below.  Could you check whether it works?
> >
> > Yay, this works!
> >
> > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Next one: i915 module reloading is broken because something is holding
> onto a module reference and doesn't drop it. Didn't check which sets
> of patches introduced this, but iirc this worked last week. Disabling
> hda-intel gets in Kconfig gets rid of the problem, so I assume
> something in the sound driver is leaking that reference ...
> 
> It's also causing lots and lots of red in our CI :( If we can't fix
> this we need to disable snd-hda-intel there too.

I spotted out a typo in my previous patch that leads to the module
reference unbalance.  The fix is  already in sound.git tree today:
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-linus&id=fc18282cdcba984ab89c74d7e844c10114ae0795

The bug was introduced after 4.12.


thanks,

--
Takashi Iwai <tiwai@suse.de>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
  2017-07-04 15:28                   ` Takashi Iwai
@ 2017-07-04 18:12                     ` Daniel Vetter
  -1 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-07-04 18:12 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Chris Wilson, Intel Graphics Development, Guneshwor Singh,
	Hardik T Shah, Libin Yang, Subhransu S. Prusty, Vinod Koul,
	Julia Lawall, Jaroslav Kysela, Linux Kernel Mailing List

On Tue, Jul 4, 2017 at 5:28 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Tue, 04 Jul 2017 17:14:39 +0200,
> Daniel Vetter wrote:
>> On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> Now I took a closer look, and this appears rather like a brown paper
>> >> bag bug, not about the deferred probe or module dependency.
>> >> The fix patch is below.  Could you check whether it works?
>> >
>> > Yay, this works!
>> >
>> > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>
>> Next one: i915 module reloading is broken because something is holding
>> onto a module reference and doesn't drop it. Didn't check which sets
>> of patches introduced this, but iirc this worked last week. Disabling
>> hda-intel gets in Kconfig gets rid of the problem, so I assume
>> something in the sound driver is leaking that reference ...
>>
>> It's also causing lots and lots of red in our CI :( If we can't fix
>> this we need to disable snd-hda-intel there too.
>
> I spotted out a typo in my previous patch that leads to the module
> reference unbalance.  The fix is  already in sound.git tree today:
>   https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-linus&id=fc18282cdcba984ab89c74d7e844c10114ae0795
>
> The bug was introduced after 4.12.

Ok, CI over here confirmed that it's all good again.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support
@ 2017-07-04 18:12                     ` Daniel Vetter
  0 siblings, 0 replies; 22+ messages in thread
From: Daniel Vetter @ 2017-07-04 18:12 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Vinod Koul, Hardik T Shah, Intel Graphics Development,
	Guneshwor Singh, Linux Kernel Mailing List, Julia Lawall,
	Jaroslav Kysela, Subhransu S. Prusty

On Tue, Jul 4, 2017 at 5:28 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Tue, 04 Jul 2017 17:14:39 +0200,
> Daniel Vetter wrote:
>> On Thu, Jun 29, 2017 at 12:25 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> >> Now I took a closer look, and this appears rather like a brown paper
>> >> bag bug, not about the deferred probe or module dependency.
>> >> The fix patch is below.  Could you check whether it works?
>> >
>> > Yay, this works!
>> >
>> > Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>
>> Next one: i915 module reloading is broken because something is holding
>> onto a module reference and doesn't drop it. Didn't check which sets
>> of patches introduced this, but iirc this worked last week. Disabling
>> hda-intel gets in Kconfig gets rid of the problem, so I assume
>> something in the sound driver is leaking that reference ...
>>
>> It's also causing lots and lots of red in our CI :( If we can't fix
>> this we need to disable snd-hda-intel there too.
>
> I spotted out a typo in my previous patch that leads to the module
> reference unbalance.  The fix is  already in sound.git tree today:
>   https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=for-linus&id=fc18282cdcba984ab89c74d7e844c10114ae0795
>
> The bug was introduced after 4.12.

Ok, CI over here confirmed that it's all good again.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2017-07-04 18:12 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-21 15:08 [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support Daniel Vetter
2017-06-21 15:08 ` Daniel Vetter
2017-06-21 15:23 ` Chris Wilson
2017-06-21 15:23   ` Chris Wilson
2017-06-21 15:30   ` Takashi Iwai
2017-06-21 15:30     ` Takashi Iwai
2017-06-26 16:16     ` Daniel Vetter
2017-06-26 16:16       ` Daniel Vetter
2017-06-26 17:47       ` Takashi Iwai
2017-06-26 17:47         ` Takashi Iwai
2017-06-26 17:54         ` Daniel Vetter
2017-06-26 17:54           ` Daniel Vetter
2017-06-28 10:16           ` Takashi Iwai
2017-06-28 10:16             ` Takashi Iwai
2017-06-29 10:25             ` Daniel Vetter
2017-06-29 10:25               ` Daniel Vetter
2017-07-04 15:14               ` Daniel Vetter
2017-07-04 15:28                 ` Takashi Iwai
2017-07-04 15:28                   ` Takashi Iwai
2017-07-04 18:12                   ` Daniel Vetter
2017-07-04 18:12                     ` Daniel Vetter
2017-06-21 15:52 ` ✗ Fi.CI.BAT: failure for " Patchwork

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.