[linux-dvb] dvb-kernel crasher

[Olaf Titz <olaf@bigred.inka.de>]

This crash has been there for months, going from Linux 2.6.something
to 2.6.9 now and several updates from current dvb-kernel CVS.
It happens in the following situation:
I'm running VDR under a daemon which tries to handle some error
situations by restarting VDR (see
<URL:http://sites.inka.de/~bigred/sw/vdr.html>). I also run xawtv on
the /dev/video device of the first DVB card (Nexus-S). The system also
has a Nova-S (budget-ci), both using stv0299 frontend.

Either VDR dies by itself or I kill it, then the daemon tries to
unload and re-load the DVB drivers and restart VDR, and then the
following happens:

Dec 25 16:47:26 bigred kernel: Unable to handle kernel paging request at virtual address d0aa34c0
Dec 25 16:47:26 bigred kernel:  printing eip:
Dec 25 16:47:26 bigred kernel: d0aa60d5
Dec 25 16:47:26 bigred kernel: *pde = 0ffcb067
Dec 25 16:47:26 bigred kernel: *pte = 00000000
Dec 25 16:47:26 bigred kernel: Oops: 0000 [#1]
Dec 25 16:47:26 bigred kernel: PREEMPT
Dec 25 16:47:26 bigred kernel: Modules linked in: snd_pcm_oss dvb_ttpci dvb_core saa7146_vv video_buf saa7146 v4l1_compat v4l2_common videodev ves1820 stv0299 tda8083 stv0297 sp8870 crc32 ves1x93 ttpci_eeprom nfs nfsd exportfs lockd sunrpc 8250 serial_core parport_pc lp parport ehci_hcd snd_mixer_oss b44 mii usblp uhci_hcd usbcore ipv6 via_agp agpgart snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore asb100 i2c_sensor i2c_viapro i2c_core lirc_serial lirc_dev softdog
Dec 25 16:47:26 bigred kernel: CPU:    0
Dec 25 16:47:26 bigred kernel: EIP:    0060:[pg0+275726549/1069859840]    Not tainted VLI
Dec 25 16:47:26 bigred kernel: EFLAGS: 00010202   (2.6.9)
Dec 25 16:47:26 bigred kernel: EIP is at dvb_device_open+0x65/0x1c0 [dvb_core]
Dec 25 16:47:27 bigred kernel: eax: c9356000   ebx: cfff41a0   ecx: cfff5e6c   edx: d0aa34c0
Dec 25 16:47:27 bigred kernel: esi: d0ab9da0   edi: cc220920   ebp: c454fb20   esp: c9357ee8
Dec 25 16:47:27 bigred kernel: ds: 007b   es: 007b   ss: 0068
Dec 25 16:47:27 bigred kernel: Process vdr (pid: 5246, threadinfo=c9356000 task=c7a6faa0)
Dec 25 16:47:27 bigred kernel: Stack: 00000003 ce8ff478 00000001 00000000 c9356000 ce8ff460 00000000 d0aa6070
Dec 25 16:47:27 bigred kernel:        c015d2ca c454fb20 cc220920 00000001 c9357f70 cc220920 c454fb20 c1269200
Dec 25 16:47:27 bigred kernel:        00000001 c01533a6 c454fb20 cc220920 c68f00dc 00000000 00000000 cc0a0000
Dec 25 16:47:27 bigred kernel: Call Trace:
Dec 25 16:47:27 bigred kernel:  [pg0+275726448/1069859840] dvb_device_open+0x0/0x1c0 [dvb_core]
Dec 25 16:47:27 bigred kernel:  [chrdev_open+234/528] chrdev_open+0xea/0x210
Dec 25 16:47:27 bigred kernel:  [dentry_open+326/560] dentry_open+0x146/0x230
Dec 25 16:47:27 bigred kernel:  [filp_open+104/112] filp_open+0x68/0x70
Dec 25 16:47:27 bigred kernel:  [get_unused_fd+57/224] get_unused_fd+0x39/0xe0
Dec 25 16:47:27 bigred kernel:  [sys_open+73/144] sys_open+0x49/0x90
Dec 25 16:47:27 bigred kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Dec 25 16:47:27 bigred kernel: Code: 00 00 8b 77 10 89 47 7c 8b 40 08 85 c0 0f 84 43 01 00 00 8b 10 c7 44 24 08 01 00 00 00 85 d2 74 3a b8 00 e0 ff ff 21 e0 ff 40 14 <83> 3a 02 0f 84 33 01 00 00 ff 82 c0 00 00 00 b8 00 e0 ff ff 21
Dec 25 16:47:27 bigred kernel:  <6>note: vdr[5246] exited with preempt_count 2
Dec 25 16:47:27 bigred kernel: bad: scheduling while atomic!
Dec 25 16:47:27 bigred kernel:  [schedule+1231/1248] schedule+0x4cf/0x4e0
Dec 25 16:47:27 bigred kernel:  [unmap_page_range+75/128] unmap_page_range+0x4b/0x80
Dec 25 16:47:27 bigred kernel:  [unmap_vmas+428/448] unmap_vmas+0x1ac/0x1c0
Dec 25 16:47:27 bigred kernel:  [exit_mmap+131/352] exit_mmap+0x83/0x160
Dec 25 16:47:27 bigred kernel:  [rcu_init+20/48] rcu_init+0x14/0x30
Dec 25 16:47:27 bigred kernel:  [mmput+100/160] mmput+0x64/0xa0
Dec 25 16:47:27 bigred kernel:  [do_exit+330/1040] do_exit+0x14a/0x410
Dec 25 16:47:27 bigred kernel:  [do_page_fault+0/1437] do_page_fault+0x0/0x59d
Dec 25 16:47:27 bigred kernel:  [die+392/400] die+0x188/0x190
Dec 25 16:47:27 bigred kernel:  [do_page_fault+0/1437] do_page_fault+0x0/0x59d
Dec 25 16:47:27 bigred kernel:  [printk+23/32] printk+0x17/0x20
Dec 25 16:47:27 bigred kernel:  [do_page_fault+558/1437] do_page_fault+0x22e/0x59d
Dec 25 16:47:27 bigred kernel:  [dput+36/528] dput+0x24/0x210
Dec 25 16:47:27 bigred kernel:  [link_path_walk+2592/3424] link_path_walk+0xa20/0xd60
Dec 25 16:47:27 bigred kernel:  [do_page_fault+0/1437] do_page_fault+0x0/0x59d
Dec 25 16:47:27 bigred kernel:  [error_code+45/56] error_code+0x2d/0x38
Dec 25 16:47:27 bigred kernel:  [pg0+275726549/1069859840] dvb_device_open+0x65/0x1c0 [dvb_core]
Dec 25 16:47:27 bigred kernel:  [pg0+275726448/1069859840] dvb_device_open+0x0/0x1c0 [dvb_core]
Dec 25 16:47:27 bigred kernel:  [chrdev_open+234/528] chrdev_open+0xea/0x210
Dec 25 16:47:27 bigred kernel:  [dentry_open+326/560] dentry_open+0x146/0x230
Dec 25 16:47:27 bigred kernel:  [filp_open+104/112] filp_open+0x68/0x70
Dec 25 16:47:27 bigred kernel:  [get_unused_fd+57/224] get_unused_fd+0x39/0xe0
Dec 25 16:47:27 bigred kernel:  [sys_open+73/144] sys_open+0x49/0x90
Dec 25 16:47:27 bigred kernel:  [syscall_call+7/11] syscall_call+0x7/0xb

with more OOPSes to follow, system needs reboot to get the DVB drivers
working again.

The killed process is the restarted VDR. This happens after the DVB
devices are completely reloaded. The daemon has the special feature to
omit all DVB devices but the first when reloading, so that if the root
cause for VDR exiting is the not yet completely fixed "video data
stream broken" bug, it retries with only one DVB card (in which case
the bug does not trigger). This is the reason why the budget module is
not loaded at time of crash.

This happened in versions which needed the stv0299 frontend loaded
separately, as well as in the current version which loads a ton of
frontends by itself.

I _think_ this does not happen when not running xawtv.
Perhaps some stuff in the videodevice part does not properly get
zeroed? OTOH, since the crash is in sys_open, it may be related to
VDR's device probing, perhaps in connection with the second device now
missing?

Olaf