On Mon, Apr 02, 2007 at 02:07:35PM +0200, Michel Bardiaux wrote:
> Rob Dege wrote:
> > Last night, while my system was recording a show, a message appeared
> > in the logs:
> >
> > ivtv2 warning: CX2341X_ENC_MISC took 33 jiffies (250 per HZ)
> >
> > The message only appeared once, but I wasn't sure what it meant. Just
> > wanted to make sure that a jiffie wasn't a bad thing :)
> >
> > kernel 2.6.18.6
> > ivtv 0.10.1
> >
>
> http://en.wikipedia.org/wiki/Jiffy_%28time%29
Rob, thank you for noticing this clueful error message. I'm pretty sure
it's a direct indication of the problem I described two weeks ago in
"ivtv vs. system clock" - while recording, the system clock runs
slowly.
I found a great number of these warnings in /var/log/messages. Moreover,
each one is the beginning of a group of events. A typical group is:
Mar 30 22:00:06 datwiz kernel: ivtv0 warning:
CX2341X_ENC_SET_VBI_LINE took 123 jiffies (1000 per HZ)
Mar 30 22:00:09 datwiz kernel: ivtv0: All encoder VBI stream buffers
are full. Dropping data.
Mar 30 22:00:09 datwiz kernel: ivtv0: Cause: the application is not
reading fast enough.
Mar 30 22:00:11 datwiz kernel: ivtv0: All encoder MPEG stream
buffers are full. Dropping data.
Mar 30 22:00:11 datwiz kernel: ivtv0: Cause: the application is not
reading fast enough.
Mar 30 22:00:34 datwiz ntpd[27549]: synchronized to LOCAL(0), stratum
10 Mar 30 22:01:42 datwiz ntpd[27549]: synchronized to 194.171.167.130,
stratum 1
It appears that ivtv was producing data faster than some other process
could consume it. Very shortly later, ntpd lost lock.
At risk of stating the obvious, let me explain my understanding that
kernel code, unlike user code, must handle interrupts carefully and
correctly. Interrupts must be handled with minimum delay and never so
late as to miss the event. The system clock is the classic example.
If a single clock interrupt fails to increment the time before the
next clock interrupt, an increment will be lost and the clock will
"run slowly".
Some kernel operations must ensure atomicity - once begun, they must
finish without being interrupted. Kernel code can suspend interrupts
to ensure this, but the suspense must be guaranteed never to exceed a
critical interval. I think this must be less than 1 jiffy to keep the
clock accurate, and according to the Wikipedia article, this is either
10, 1, or 4 ms, depending on the vintage of the kernel.
I strongly suspect that the ivtv code violates this precept. If the
first warning really means that CX2341X_ENC_SET_VBI_LINE caused
interrupts to be suspended for 123 jiffies, this would indicate a
major disaster.
I wish I were a better coder and could analyze it further, but I'm not.
Good luck to anyone who can.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
[EMAIL PROTECTED] www.datix.us
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
