Messages in this thread | | | Date | Wed, 12 Jul 2006 22:44:53 -0700 | From | Andrew Morton <> | Subject | Re: oops in bttv |
| |
On Wed, 12 Jul 2006 22:24:07 -0700 "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> > > The class_dev is created like this, in video_register_device(): > > > > > > memset(&vfd->class_dev, 0x00, sizeof(vfd->class_dev)); > > > if (vfd->dev) > > > vfd->class_dev.dev = vfd->dev; > > > vfd->class_dev.class = &video_class; > > > vfd->class_dev.devt = MKDEV(VIDEO_MAJOR, vfd->minor); > > > sprintf(vfd->class_dev.class_id, "%s%d", name_base, i - base); > > > class_device_register(&vfd->class_dev); > > > class_device_create_file(&vfd->class_dev, > > > &class_device_attr_name); > > > > > > so it looks like class_device_register() is putting the 1 into the dentry? > > > Culprit looks to be class_device_add() in that case. > > > > Perhaps we should check the return value of class_device_register() to > > verify that nothing bad happened there? A dentry of 1 is very odd. > > Yes. We are in the process of adding such checks. > Join the fun.
Chuck got about as far through this as I did. Yes, I'm suspecting an earlier uncaught error of some form. The videodev changes since 2.6.17 are small and look to be unrelated. I'd be suspecting preexisting videodev bugs which have been exposed by sysfs/driver-model changes. But it's very hard to tell.
Going through and adding 1000 missing check-error-then-recover instances is the ideal approach, but I suspect that leaving callers as-is and blurting a message from the driver core when some of these things fail might get us what we need. But right now we have neither, and we see the result. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |