Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751940AbdFZQQk (ORCPT ); Mon, 26 Jun 2017 12:16:40 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33686 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751411AbdFZQQe (ORCPT ); Mon, 26 Jun 2017 12:16:34 -0400 Date: Mon, 26 Jun 2017 18:16:30 +0200 From: Daniel Vetter 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@vger.kernel.org Subject: Re: [PATCH] BUG-REPORT: snd-hda: hacked-together EPROBE_DEFER support Message-ID: <20170626161630.u4ubdzgxr37o63ip@phenom.ffwll.local> Mail-Followup-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@vger.kernel.org References: <1498057734-14622-1-git-send-email-daniel.vetter@ffwll.ch> <149805863799.15021.15278760577807511996@mail.alporthouse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.9.0-2-amd64 User-Agent: NeoMutt/20170306 (1.8.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2749 Lines: 65 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 > > > 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