[linux-dvb] Problems with kernel oops when installing HVR-1800.

Mark Jenks mjenks1968 at gmail.com
Sun Dec 28 23:51:01 CET 2008


On Sun, Dec 28, 2008 at 3:36 PM, Andy Walls <awalls at radix.net> wrote:

> On Sat, 2008-12-27 at 10:40 -0600, Mark Jenks wrote:
> > G'morning all!  (at least it's morning here.)
> >
> > I have a running Mythtv server that is running Suse 10.3 with a
> > hvr-1250 just fine on Kernel 2.6.24, and haven't had any problems at
> > all.
> >
> > I tried to install a hvr-1800 in it yesterday, and I get a kernel oops
> > on it and X won't start.   I compiled up a 2.6.27.10 kernel for it,
> > and moved to that, and I still get the oops.    Checked my vmalloc and
> > I am fine, but increased it anyways to 384 just for grins.
> >
> > I compiled v4l-dvb-cae6de452897 up against the 2.6.24, and the 2.6.27
> > kernels without any changes.   Server boots just fine without the
> > 1800, but with I get the oops.
> >
> > The only thing that I can see, is that the 1250 and the 1800 look to
> > be using the same interrupt.
> >
> > Here is more than enough debug info, I hope.  :)
> >
> > Thanks!
> >
> > -Mark
> >
> >
> > BUG: unable to handle kernel NULL pointer dereference at 000001a0
> > IP: [<f8e5a594>] :cx23885:video_open+0x2c/0x150
> > *pde = 00000000
> > Oops: 0000 [#1] SMP
> > Modules linked in: iptable_filter ip_tables ip6_tables x_tables
> > cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8
> > xfs loop dm_mod cx25840 mt2131 s5h1409 nvidia(P) cx23885
> > v4l2_compat_ioctl32 cx2341x videobuf_dma_sg button videobuf_dvb
> > dvb_core videobuf_core v4l2_common snd_hda_intel snd_usb_audio
> > snd_usb_lib snd_mpu401 snd_cs4232 snd_opl3_lib snd_cs4231_lib snd_pcm
> > ohci1394 videodev v4l1_compat osst agpgart btcx_risc rtc_cmos
> > i2c_nforce2 snd_timer ieee1394 snd_mpu401_uart tveeprom sr_mod
> > snd_hwdep i2c_core rtc_core rtc_lib parport_pc parport st lirc_mceusb2
> > snd_rawmidi snd_seq_device snd k8temp hwmon cdrom forcedeth soundcore
> > snd_page_alloc lirc_dev sg usbhid hid ff_memless ohci_hcd ehci_hcd
> > usbcore sd_mod edd ext3 mbcache jbd fan aic7xxx scsi_transport_spi
> > sata_nv pata_amd libata scsi_mod dock thermal processor thermal_sys
> >
> > Pid: 3178, comm: X Tainted: P          (2.6.27.10-default #3)
> > EIP: 0060:[<f8e5a594>] EFLAGS: 00013287 CPU: 1
> > EIP is at video_open+0x2c/0x150 [cx23885]
> > EAX: 00000000 EBX: 00000000 ECX: f7a9f000 EDX: f7a0e000
> > ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: f764de90
> >  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > Process X (pid: 3178, ti=f764c000 task=f7398c00 task.ti=f764c000)
> > Stack: f7a6e540 00000000 f7b16538 00000000 f7bc30a0 c016bee5 f7a6e540
> > 00000000
> >        f7a6e540 f7bc30a0 00000000 c016bdd9 c01683cd f701ebc0 f6d756c0
> > f764df14
> >        f7a6e540 f764df14 00000003 c01684d8 f7a6e540 00000000 00000000
> > f764df14
> > Call Trace:
> >  [<c016bee5>] chrdev_open+0x10c/0x122
> >  [<c016bdd9>] chrdev_open+0x0/0x122
> >  [<c01683cd>] __dentry_open+0x10d/0x1fc
> >  [<c01684d8>] nameidata_to_filp+0x1c/0x2c
> >  [<c0172986>] do_filp_open+0x33d/0x63e
> >  [<f9b7d8ce>] _nv004117rm+0x9/0x12 [nvidia]
> >  [<c01582f8>] handle_mm_fault+0x2b3/0x5dd
> >  [<c017ab2d>] alloc_fd+0x57/0xd3
> >  [<c01681e8>] do_sys_open+0x3f/0xb8
> >  [<c01682a5>] sys_open+0x1e/0x23
> >  [<c01037ad>] sysenter_do_call+0x12/0x21
> >  =======================
> > Code: 31 ed 57 31 ff 56 31 f6 53 83 ec 04 89 14 24 8b 58 34 e8 16 18
> > 46 c7 8b 15 d0 ad e6 f8 81 e3 ff ff 0f 00 eb 49 8b 82 84 0d 00 00 <39>
> > 98 a0 01 00 00 75 07 89 d6 bf 01 00 00 00 8b 82 88 0d 00 00
> > EIP: [<f8e5a594>] video_open+0x2c/0x150 [cx23885] SS:ESP 0068:f764de90
> > ---[ end trace c26ff07c077248e0 ]---
>
> Mark,
>
> Using the same interrupt isn't the problem.
>
> Here's the gory translation of the Ooops data:
>
>
> The problem is tripped in cx23885-video.c:video_open():
>
>  777 static int video_open(struct inode *inode, struct file *file)
>  778 {
>  779         int minor = iminor(inode);
>  780         struct cx23885_dev *h, *dev = NULL;
>  781         struct cx23885_fh *fh;
>  782         struct list_head *list;
>  783         enum v4l2_buf_type type = 0;
>  784         int radio = 0;
>  785
>  786         lock_kernel();
>  787         list_for_each(list, &cx23885_devlist) {
>  788                 h = list_entry(list, struct cx23885_dev, devlist);
>  789                 if (h->video_dev->minor == minor) {
>  790                         dev  = h;
>  791                         type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>  792                 }
>  793                 if (h->vbi_dev &&
>  794                    h->vbi_dev->minor == minor) {
>  795                         dev  = h;
>  796                         type = V4L2_BUF_TYPE_VBI_CAPTURE;
>  797                 }
> [...]
>
> Also note the list_entry()  & list_for_each() macro definitions:
>
> 425 #define list_entry(ptr, type, member) \
> 426         container_of(ptr, type, member)
> [...]
> 444 #define list_for_each(pos, head) \
> 445         for (pos = (head)->next; prefetch(pos->next), pos != (head); \
> 446                 pos = pos->next)
>
>
>
> The code bytes dumped in the Oops disassemble to:
>
>   1:   31 ed                   xor    %ebp,%ebp
>   3:   57                      push   %edi
>   4:   31 ff                   xor    %edi,%edi
>   6:   56                      push   %esi
>   7:   31 f6                   xor    %esi,%esi
>   9:   53                      push   %ebx
>   a:   83 ec 04                sub    $0x4,%esp
>   d:   89 14 24                mov    %edx,(%esp)
>  10:   8b 58 34                mov    0x34(%eax),%ebx   <--- line 779:
> minor = iminor(inode);
>  13:   e8 16 18 46 c7          call   0xc746182e        <--- line 786:
> lock_kernel()
>  18:   8b 15 d0 ad e6 f8       mov    0xf8e6add0,%edx   <--- line 445: list
> = (&cx23885_devlist)->next;
>  1e:   81 e3 ff ff 0f 00       and    $0xfffff,%ebx     <--- line 779:
> minor = iminor(inode);
>  24:   eb 49                   jmp    0x6f              <--- jmp to for
> loop condition check: line 445: prefetch(list->next), list !=
> &cx23885_devlist;
>  26:   8b 82 84 0d 00 00       mov    0xd84(%edx),%eax  <--- line 426 &
> 789: h = container_of(list, struct cx23885_dev, devlist); if
> (h->video_dev...
>  2c:   39 98 a0 01 00 00       cmp    %ebx,0x1a0(%eax)  <--- Ooops occurs
> here: line 789: if (h->video_dev->minor == minor) {
>  32:   75 07                   jne    0x3b
>  34:   89 d6                   mov    %edx,%esi         <--- line 790: dev
> = h;
>  36:   bf 01 00 00 00          mov    $0x1,%edi         <--- line 791: type
> = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>  3b:   8b 82 88 0d 00 00       mov    0xd88(%edx),%eax  <--- line 793: if
> (h->vbi_dev ...
>
>
> So "h->video_dev" (I think) was "NULL" in this call to video_open().
> This is a problem with the creation or manipulation of the "struct
> cx23885_dev" members of the "cx23885_devlist".
>
> This appears to be a problem with this list iteration in
> cx23885-video.c:video_open().
>
> If one of these devices only has DVB support and no analog V4L support,
> then it would make sense why one of them would have "h->video_dev" set
> to NULL.  The device shouldn't have a V4L2 "video_dev" if it doesn't
> support analog (V4L2) devices.  I believe the 1800 supports analog video
> but the 1250 does not (someone correct me on this if I'm wrong - I'm no
> expert on these devices).
>
> The iteration loop in video_open() needs to be careful about NULL
> pointer dereference of h->video_dev for DVB only devices.
>
> Try this patch:
>
> diff -r cae6de452897 linux/drivers/media/video/cx23885/cx23885-video.c
> --- a/linux/drivers/media/video/cx23885/cx23885-video.c Fri Dec 26 08:07:39
> 2008 -0200
> +++ b/linux/drivers/media/video/cx23885/cx23885-video.c Sun Dec 28 16:34:04
> 2008 -0500
> @@ -786,7 +786,8 @@ static int video_open(struct inode *inod
>        lock_kernel();
>        list_for_each(list, &cx23885_devlist) {
>                h = list_entry(list, struct cx23885_dev, devlist);
> -               if (h->video_dev->minor == minor) {
> +               if (h->video_dev &&
> +                   h->video_dev->minor == minor) {
>                        dev  = h;
>                        type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>                }
>
>
>
> If it doesn't work you'll need to find someone with access to a HVR-1250
> and HVR-1800 in the same machine to do more interactive debugging (Andy
> Walls' thought experiments can only take one so far....).
>
> I can't help further since I don't have any CX23885 based cards.
>
> Regards,
> Andy
>

Andy,

You are correct.  They are both are cx23885 cards, and only one of them has
an analog input to it. The 1250 is a DVB and the 1800 is DVB, but is a MCE
card with analog(svideo, etc), in.

I will give your patch a try tomorrow.   I'm kind of tired of pulling my
media computer, putting in and replacing the card 20 times in one day trying
to figure this out.

Thanks!

-Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20081228/f627cfa6/attachment.htm 


More information about the linux-dvb mailing list