Francois Romieu writes: > Johannes Stezenbach <js@xxxxxxxxxxx> : > [...] > > > 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) ). You are right but the actual 2 small bugs are elsewhere. The call sequence above should not happen this way. Easy to fix. The other bug is in dvb_dmx_swfilter, which should not lock for user space calls. It also (purposely) did not until it was abused for IRQ calls of cards with unaligned TS data. Ralph
