On Mon, 2008-09-29 at 19:09 -0400, Richard Cox wrote: > First, I want to thank you for this driver...I tried it about 6 months ago, > but had a lot of difficulties.
Which driver: ivtv or cx18? > It's amazing how usable it is > now....outstanding progress. Good. :) > There is one issue (not much, but it may mean something) that I've > seen...when > I'm watching TV with mythtv, I notice these messages in my log (this is with > the latest snapshot, btw, v4l-dvb-e5ca4534b543): > > > Sep 29 19:05:14 octavian rtc: lost 1 interrupts > Sep 29 19:05:17 octavian rtc: lost 1 interrupts > Sep 29 19:05:22 octavian rtc: lost 1 interrupts > Sep 29 19:05:28 octavian rtc: lost 1 interrupts > Sep 29 19:05:28 octavian rtc: lost 1 interrupts > Sep 29 19:05:37 octavian rtc: lost 1 interrupts > Sep 29 19:05:37 octavian rtc: lost 1 interrupts > Sep 29 19:05:38 octavian rtc: lost 1 interrupts > Sep 29 19:05:41 octavian rtc: lost 1 interrupts > Sep 29 19:05:50 octavian rtc: lost 1 interrupts These can only get emitted, AFAICT when the HPET (High Performance E??? Timer) driver is emulating the Real Time Clock (rtc). The lost interrupt means that things appear to be getting behind with the emulation. I'll *speculate* that the TV apps may be using the RTC for A/V sync purposes or the sound driver may be using the RTC during playback. Here's some interesting comments from linux/arch/x86/kernel/hpet.c: #ifdef CONFIG_HPET_EMULATE_RTC /* HPET in LegacyReplacement Mode eats up RTC interrupt line. When, HPET * is enabled, we support RTC interrupt functionality in software. * RTC has 3 kinds of interrupts: * 1) Update Interrupt - generate an interrupt, every sec, when RTC clock * is updated * 2) Alarm Interrupt - generate an interrupt at a specific time of day * 3) Periodic Interrupt - generate periodic interrupt, with frequencies * 2Hz-8192Hz (2Hz-64Hz for non-root user) (all freqs in powers of 2) * (1) and (2) above are implemented using polling at a frequency of * 64 Hz. The exact frequency is a tradeoff between accuracy and interrupt * overhead. (DEFAULT_RTC_INT_FREQ) * For (3), we use interrupts at 64Hz or user specified periodic * frequency, whichever is higher. */ So RTC interrupt type 1 (wall clock second hand) and type 2 (alarm clock) probably are not at issue. Some I'm *guessing* The TV app or sound driver are likely using the type 3 RTC interrupt and the HPET driver RTC emulation is getting behind due to a busy system (I think). On my system $ cat /proc/interrupts | grep rtc 8: 1 0 IO-APIC-edge rtc0 The real RTC hardware on my system is not being used by the system for timing: only one interrupt generated. $ cat /proc/driver/rtc rtc_time : 00:38:57 rtc_date : 2008-09-30 alrm_time : 00:00:00 alrm_date : ****-**-** alarm_IRQ : no alrm_pending : no 24hr : yes periodic_IRQ : no update_IRQ : no HPET_emulated : yes <---------- Emulated rtc DST_enable : no periodic_freq : 1024 <---------- 1024 Hz batt_status : okay I'm thinking if you upped the periodic_freq of the HPET emulation of the RTC (only powers of 2 are allowed), the lost interrupts will go away. I think somewhere under the /proc filesystem root or users can change it with an echo command, but I'm not sure how. I'm not sure, the new HPET stuff is really out of my expertise. All I can tell is software emulation of a piece of hardware is getting behind. Since the software uses periodic polling to do the emulation, just have it poll more frequently. That's my guess. Regards, Andy > The only time I see this is when watching TV. Not a big deal, but I know > development is ongoing and this may help. If there is any testing you would > like me to try, please let me know...but right now, I am using this driver > full time and it has been very reliable for me. > > Best regards, > > Richard > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
