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. I'm not sure how in the cx18-alsa.ko things can be screwed up so badly that it messes up the kernel's reference counting of mm structures. I'll take a harder look at it myself this weekend, but the kernel mm system is a little out of my current realm of experience. Looks like I get to learn, because I'm not going to bisect a BUG() that halts the machine and risks disk corruption every time. Regards, Andy -- 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
