> Hans Verkuil wrote:
>> On Saturday 16 June 2007 21:30, Hans Verkuil wrote:
>>
>>> On Friday 15 June 2007 20:40, Cyrus A wrote:
>>>
>>>> I'm getting lots of VBI errors recently. One particular one that
>>>> pops up frequently is in dmesg is:
>>>>
>>>> ivtv0 warning: Cannot obtain 1690835328 bytes for encoder VBI data
>>>> transfer ivtv0 warning: Cannot obtain 1690835328 bytes for encoder
>>>> VBI data transfer ivtv0 warning: Cannot obtain 1690835328 bytes for
>>>> encoder VBI data transfer ivtv0 warning: Cannot obtain 1690835328
>>>> bytes for encoder VBI data transfer ivtv0 warning: Cannot obtain
>>>> 1690835328 bytes for encoder VBI data transfer ivtv0 warning:
>>>> Cannot obtain 1690835328 bytes for encoder VBI data transfer ...
>>>>
>>>> I have not been able to discern any rhyme or reason to why it
>>>> appears. All I can tell you is my configuration...
>>>>
>>>> kernel 2.6.20-1.2952.fc6
>>>> ivtv 0.10.3
>>>> PVR-500 and PVR-150 low profile (3 tuners total)
>>>> AMD 64 X2
>>>>
>>>> ... and what I'm doing which is recording about 12 hour-long
>>>> programs every day, usually in two simultaneous recordings (i.e. 2
>>>> simultaneous hour long recordings 6 times a day), as well as saving
>>>> the closed captions for those programs to files using
>>>> lt-zvbi-ntsc-cc . It doesn't happen every time, but it's become a
>>>> daily (or every other day) routine to see those VBI errors appear
>>>> in the logs and have to reboot the machine.
>>>>
>>>> I have some machines with nearly identical configurations (2.6.18
>>>> and 2.6.17 kernels with varying ivtv versions and a single PVR-250)
>>>> that NEVER get these errors. They have run smoothly for months.
>>>>
>>>> At the very least, can someone answer this question for me: what am
>>>> I dealing with here? Hardware problems or driver issues?
>>>>
>>> It's almost certainly a driver issue given the impossible byte size
>>> that is reported. I'll see if I can find out why they are happening.
>>>
>>> Regards,
>>>
>>>     Hans
>>>
>>
>> I've taken a quick look and it is not immediately obvious what it going
>> wrong. Can you do a few tests for me? In ivtv-queue.h change this
>> function:
>>
>> static inline int ivtv_use_pio(struct ivtv_stream *s)
>> {
>>         struct ivtv *itv = s->itv;
>>
>>         return s->dma == PCI_DMA_NONE ||
>>             (SLICED_VBI_PIO && s->type == IVTV_ENC_STREAM_TYPE_VBI &&
>> itv->vbi.sliced_in->service_set);
>> }
>>
>> to this:
>>
>> static inline int ivtv_use_pio(struct ivtv_stream *s)
>> {
>>         struct ivtv *itv = s->itv;
>>
>>         return s->dma == PCI_DMA_NONE ||
>>             (SLICED_VBI_PIO && s->type == IVTV_ENC_STREAM_TYPE_VBI);
>> }
>>
>> And see if that makes a difference.
>>
>>
> Ok, I've made this change. However, there were some compilation messages
> about the variable itv being unused. Hopefully that's not a problem.

That's OK.

>> The other one is to turn on additional debugging (ivtvctl -D 73) and
>> wait until it happens again. Mail me the log (say from 1000 lines
>> before it happens).
>>
>>
> I set this debug level, although I'm not sure it took. Here is the
> command and output:
>
> [EMAIL PROTECTED] cyrus]#  ivtvctl -D 73
>  set debug level: IVTV_DBGFLG_WARN | IVTV_DBGFLG_DMA | IVTV_DBGFLG_IRQ
>
> Think that did the trick? Or do I need to specify one of those options?

Yes, that's OK too.

> Also, sorry for my ignorance, which log file? /var/log/messages? or is
> there a special ivtv log file?

No, it goes into /var/log/messages. It's the file where the kernel logging
ends up. For most if not all distributions that is /var/log/messages.

>
>> Thanks,
>>
>>      Hans
>>
> In any case, thanks a bunch for the assistance. Waking up to "X server
> has a VBI bytes error" in my message reporting system every morning was
> not fun.
>
> I'll let you know if it fails again.

Please keep me posted! If making the ivtv_use_pio code change will make
this problem go away, then I'd appreciate it if you could revert that
change and try again so that I can have a log of what went wrong.

Thanks,

     Hans


_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to