Messages in this thread | | | Date | Sun, 18 May 2008 09:55:21 +0200 | From | Takashi Iwai <> | Subject | Re: [Bugme-new] [Bug 10701] New: snd_pcsp lockdep warning |
| |
At Sat, 17 May 2008 17:24:22 +0200 (CEST), Thomas Gleixner wrote: > > On Sat, 17 May 2008, Takashi Iwai wrote: > > At Fri, 16 May 2008 21:32:49 +0200 (CEST), > > Thomas Gleixner wrote: > > > > > > On Fri, 16 May 2008, Andrew Morton wrote: > > > > > So the author was well aware of locking problem and the whole code is > > > > > just a stupid hack around the problem without solving it. This code is > > > > > not at all suited for HRTIMER_CB_IRQSAFE. > > > > > > > > You sound impressed! So what's the fix? HRTIMER_CB_SOFTIRQ? > > > > > > Yeah, impressed by creativity. HRTIMER_CB_SOFTIRQ should be the right > > > thing. > > > > Well, it'd be basically a similar way like snd-pcsp currently does ("a > > stupid hack" :) But, it's good to have a fix, anyway, since this > > sounds like a generic problem with a callback in a spinlock. If the > > callback requires another own lock, this can easily lead to a AB/BA > > deadlock. Actually, ALSA PCM core had sometimes similar problems, > > too. > > HRTIMER_CB_SOFTIRQ is not a stupid hack :) It's the default for > hrtimers and it does not hold any locks when calling the callback. We > really want to avoid tons of callbacks in the timer interrupt itself.
Yes, this would be an easy workaround for snd-pcsp problem, I guess.
A better fix would be to make snd-pcsp hrtimer calback just change the pc-speaker port (0x61 and 0x42) and update the position. These should be really fast path. Then, occasionally invoke a tasklet that will call snd_pcm_period_elapsed(), which could be a (relatively) slow path and lead to a spinlock mess.
thanks,
Takashi
| |