33-rc8 Running aplay with pulse as the default
in [Kernel]
|
Prev: sched: fix SMT scheduler regression in find_busiest_queue()
Next: [PATCH 08/10] ARM: ftrace: fix and update dynamic ftrace
From: Takashi Iwai on 18 Feb 2010 08:30 At Thu, 18 Feb 2010 07:25:38 -0500, Ed Tomlinson wrote: > > On Wednesday 17 February 2010 09:29:37 Takashi Iwai wrote: > > At Wed, 17 Feb 2010 08:16:32 -0500, > > Ed Tomlinson wrote: > > > > > > On Tuesday 16 February 2010 08:37:46 Takashi Iwai wrote: > > > > > Thanks for the patch. It helps in that it eliminates the opps but lockdep still triggers and aplay still fails. > > > > > Here is the new traceback. > > > > > > > > Hmm, fixing this isn't so trivial. The same problem occurs on other > > > > subsystems like NFS over years. And it's still there, AFAIK. > > > > The mmap mutex appears suddenly in the strange code path at close. > > > > > > > > The patch below might fix, but I'm not 100% sure whether this has no > > > > side effect. > > > > > > > > Anyway, I doubt very much it being a regression. There is no change > > > > in ALSA core side, and also in V4L em28xx code. Maybe the lockdep > > > > wasn't triggered by some reason. And, this lockdep warning is almost > > > > harmless... > > > > > > Takashi, > > > > > > The second patch eliminating the lock causes oppes every time (one follows just in case > > > its helpful). > > > > Are you sure? The patch should causes a compile error, so you must have > > patched manually in a wrong place ;) > > Yes I am sure. I fixed the compile error the same way it is fixed below. But the Oops looks pretty irrelevant from the code path. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |