At Fri, 04 Mar 2011 12:13:04 -0500, Andy Walls wrote: > > On Fri, 2011-03-04 at 10:50 -0500, Devin Heitmueller wrote: > > On Thu, Mar 3, 2011 at 9:06 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote: > > > Hi, > > > > > > I got a BUG when loading the cx18.ko module (which in turn requests the > > > cx18-alsa.ko module) on a kernel built from this repository > > > > > > http://git.linuxtv.org/media_tree.git staging/for_v2.6.39 > > > > > > which I beleive is based on 2.6.38-rc2. > > > > > > The BUG is mmap related and I'm almost certain it has to do with > > > userspace accessing cx18-alsa.ko ALSA device nodes, since cx18.ko > > > doesn't provide any mmap() related file ops. > > > > > > So here is my transcription of a fuzzy digital photo of the screen: > > <snip> > > > I'm not very familiar with mmap() nor ALSA and I did not author the > > > cx18-alsa part of the cx18 driver, so any hints at where to look for the > > > problem are appreciated. > > > > Hi Andy, > > > > I'm traveling on business for about two weeks, so I won't be able to > > look into this right now. > > > > Any idea whether this is some new regression? > > I do not know. I normally don't let cx18-alsa.ko load, due to > PulseAudio's persistence at keeping the device nodes open (which makes > unloading the cx18.ko module for development a hassle.) > > > > I'm just trying to > > understand whether this is something that has always been there since > > I originally added the ALSA support to cx18 or whether it's something > > that is new, in which case it might make sense to drag the ALSA people > > into the conversation since there haven't been any changes in the cx18 > > driver lately. > > I can add some information about what is going on in userspace. This > was on a Fedora 10 machine. When devices nodes show up, the HAL daemon > and PulseAudio start using the device nodes right away. > > That activity triggers cx18.ko to do a firmware load which gets udevd > running to satisfy firmware requests, and then the cx18 driver issues > some simple commands to the CX23418 firmware, which will have > acknowledgment interrupts coming back from the CX23418. I resolved the > firmware race in cx18*.ko a while ago, so I'm confident its not an > issue. > > The BUG looks like some sort of mmap() race or memory management problem > outside of the cx18*.ko modules, given that mmput(), which appears to be > an mm specific reference counting function, is involved. > > It could also be in ALSA I guess. There is no change in ALSA core regarding mmap for really long time. If it's a regression, it must be triggered by some other changes. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
