Re: oops in bttv

From: Greg KH
Date: Thu Jul 13 2006 - 01:07:47 EST


On Thu, Jul 13, 2006 at 12:43:49AM -0400, Chuck Ebbert wrote:
> In-Reply-To: <20060711204940.GA11497@xxxxxxxxxx>
>
> On Tue, 11 Jul 2006 22:49:40 +0200, Alex Riesen wrote:
>
> > What I did was to call settings of the flashplayer and press on the
> > webcam symbol there. The system didn't crash, just this oops:
> >
> > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000065
> > printing eip:
> > c01875b0
> > *pde = 00000000
> > Oops: 0000 [#1]
> > PREEMPT SMP
> > Modules linked in: tuner tvaudio msp3400 bttv video_buf firmware_class ir_common
> > compat_ioctl32 btcx_risc tveeprom videodev v4l2_common nfs vfat fat nfsd export
> > fs lockd sunrpc snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq
> > snd_seq_device reiserfs rtc microcode radeon drm intel_agp agpgart snd_intel8x0
> > snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc sd_m
> > od usb_storage libusual usbhid uhci_hcd usbcore e100
> > CPU: 0
> > EIP: 0060:[<c01875b0>] Not tainted VLI
> > EFLAGS: 00010292 (2.6.18-rc1 #80)
> > EIP is at sysfs_add_file+0x10/0x76
> > eax: 00000001 ebx: f9bd6d14 ecx: 00000004 edx: f9bd6d14
> > esi: f9bde920 edi: 00000001 ebp: dc489eac esp: dc489e94
> > ds: 007b es: 007b ss: 0068
> > Process modprobe (pid: 11377, ti=dc489000 task=f21ff6b0 task.ti=dc489000)
> > Stack: f9bde920 f9bde920 00000004 f9bde920 f9bde920 00000000 dc489eb4 c018763c
> > dc489ebc c0220cc3 dc489ec8 f9bc3073 c19b4800 dc489ee4 f9bc35de 00000000
> > 20bd7818 f9bd7880 f9bd7880 ffffffed dc489ef0 c01c3c1b c19b4800 dc489f04
> > Call Trace:
> > [<c018763c>] sysfs_create_file+0x26/0x28
> > [<c0220cc3>] class_device_create_file+0x14/0x1a
> > [<f9bc3073>] bttv_register_video+0x8c/0x147 [bttv]
> > [<f9bc35de>] bttv_probe+0x4ab/0x593 [bttv]
> > [<c01c3c1b>] pci_call_probe+0xd/0x10
> > [<c01c3c4f>] __pci_device_probe+0x31/0x43
> > [<c01c3c82>] pci_device_probe+0x21/0x34
> > [<c0220429>] driver_probe_device+0x47/0x94
> > [<c0220542>] __driver_attach+0x5e/0x89
> > [<c021fada>] bus_for_each_dev+0x38/0x5d
> > [<c0220581>] driver_attach+0x14/0x16
> > [<c021ff2c>] bus_add_driver+0x5f/0x98
> > [<c02209a8>] driver_register+0x75/0x7a
> > [<c01c3e3e>] __pci_register_driver+0x4f/0x5d
> > [<f9bc3b3b>] bttv_init_module+0x9f/0xa1 [bttv]
> > [<c01325f7>] sys_init_module+0x95/0x1c5
> > [<c010291b>] syscall_call+0x7/0xb
> > [<b7ea781e>] 0xb7ea781e
> > Code: 01 00 00 00 6a 00 e8 f9 cf f8 ff 89 d8 e8 2f 40 fe ff 5b 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 89 c7 56 53 89 d3 83 ec 0c 89 4d f0 <8b> 40 64 89 45 ec 8b 47 1c 05 84 00 00 00 0f b7 72 08 c7 45 e8
> > EIP: [<c01875b0>] sysfs_add_file+0x10/0x76 SS:ESP 0068:dc489e94
> >
>
>
> int sysfs_add_file(struct dentry * dir, const struct attribute * attr, int type)
> {
> OOPS==> struct sysfs_dirent * parent_sd = dir->d_fsdata;
> umode_t mode = (attr->mode & S_IALLUGO) | S_IFREG;
>
> dir == 1, which is a strange value for a pointer to have (you can see it in eax.)
>
>
> called from:
>
> int sysfs_create_file(struct kobject * kobj, const struct attribute * attr)
> {
> BUG_ON(!kobj || !kobj->dentry || !attr);
>
> return sysfs_add_file(kobj->dentry, attr, SYSFS_KOBJ_ATTR);
>
> }
>
> so kobj->dentry == 1 here.
>
>
> called from:
>
> int class_device_create_file(struct class_device * class_dev,
> const struct class_device_attribute * attr)
> {
> int error = -EINVAL;
> if (class_dev)
> error = sysfs_create_file(&class_dev->kobj, &attr->attr);
> return error;
> }
>
> so the kobj is in a class_dev.
>
>
> called from:
>
> static int __devinit bttv_register_video(struct bttv *btv)
> {
> if (no_overlay <= 0) {
> bttv_video_template.type |= VID_TYPE_OVERLAY;
> } else {
> printk("bttv: Overlay support disabled.\n");
> }
>
> /* video */
> btv->video_dev = vdev_init(btv, &bttv_video_template, "video");
> if (NULL == btv->video_dev)
> goto err;
> if (video_register_device(btv->video_dev,VFL_TYPE_GRABBER,video_nr)<0)
> goto err;
> printk(KERN_INFO "bttv%d: registered device video%d\n",
> btv->c.nr,btv->video_dev->minor & 0x1f);
> ===> video_device_create_file(btv->video_dev, &class_device_attr_card);
>
> video_device_create_file() is a wrapper for class_device_create_file():
>
> video_device_create_file(struct video_device *vfd,
> struct class_device_attribute *attr)
> {
> class_device_create_file(&vfd->class_dev, attr);
> }
>
>
> 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.

If you enable debugging for the driver core and for kobjects (they both
are config options), is there anything interesting in the log right
before this happens?

> I tried tracing through that and... gave up.

Heh, yeah, it's not exactly a "simple" path...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/