On Thu, Apr 21, 2005 at 11:24:42PM +0200, Francois Romieu wrote: > 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 This would only happen with TS playback through the dvr device, and this is known broken. I won't touch this code, if you want to fix it please do. Anyway, Mikko said his problem was when trying to capture a stream, so I assume the trace he posted is bogus (there are other indications for this). > -> 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) These functions aren't broken, it's the av7110_write_to_decoder thing that is. > ! > -> 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) ). The dvr playback code yes. Well known, I've posted this here multiple times. Anyway, there's a lot of ugly code in the av7110 driver, I would not object if you or someone else would clean it up. But I believe this has nothing to do with Mikka's problem. Johannes
