[linux-dvb] Kernel panic w/ CVS drivers and Nexus-CA / TT C2300 OT (rev 2.3)

[Francois Romieu]

Johannes Stezenbach <js at linuxtv.org> :
[...]
> > The driver does too much (slow) things in its softirq part. A part of it
> > should probably be posted to a workqueue. Doable but it is not a 5min hack.
> 
> What exactly is too slow to do from a tasklet?

Any code which can go to sleep. For instance:
debiirq
-> dvb_dmx_swfilter_packets (spin_locks: so far, so good)
   -> dvb_dmx_swfilter_packet
      -> dvb_dmx_swfilter_packet_type
         -> dvb_dmx_swfilter_packet_type
            -> av7110_write_to_decoder
               -> av7110_ipack_flush
                  -> send_ipack
                     -> play_video_cb
                        -> get_video_format
                           -> av7110_set_vidmode
                              -> av7110_fw_cmd
                                 -> av7110_send_fw_cmd
!
! Issues down_interruptible: broken because of spinlock above or
! tasklet/softirq context (pick one).
!
                                    -> __av7110_send_fw_cmd
!
! Can issue msleep like crazy: broken (same reason)
!
                                       -> rdebi (spin_lock_irqsaves: ok)
                                          -> av7110_debiread
                                             -> saa7146_wait_for_debi_done
!
! It does not sleep but it busy waits up to 50 ms (presumably when hardware
! is kaputt, I can buy that but please remember that the days of matrox induced
! bus stalls are not _that_ far), 2 times. Btw I am not convinced that it is
! safe to expect jiffies to be updated when in code protected by a
! spin_lock_irqsave.
!

Don't hesitate to educate me if I am wrong but this code seems severely
broken wrt locking rules (not that it prevents to be useful/workable for
a lot of people :o) ).

--
Ueimor