Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner

[Javier Marcet <jmarcet@xxxxxxxxx>]

On Tue, Sep 18, 2012 at 7:17 PM, Konrad Rzeszutek Wilk
<konrad@xxxxxxxxxx> wrote:

>> I have some news from the linux-media mailing list. There, Devin Heitmueller,
>> said this:
>>
>> """
>> > Initially I thought Xen would be the cause of the problem, but after
>> > having written on
>> > the Xen development mailing list and talked about it with a couple
>> > developers, it isn't
>> > very clear where the problem is. So far I haven't been able to get the
>> > smallest warning
>> > or error.
>>
>> This is a very common problem when attempting to use any PCI/PCIe
>> tuner under a hypervisor.  Essentially the issue is all of the
>> virtualization solutions provide very poor interrupt latency, which
>> results in the data being lost.
>>
>> Devices delivering a high bitrate stream of data in realtime are much
>> more likely for this problem to be visible since such devices have
>> very little buffering (it's not like a hard drive controller where it
>> can just deliver the data slower).  The problem is not specific to the
>> cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards
>> work this way, and they cannot really be blamed for expecting to run
>> in an environment with really crappy interrupt latency.
>>
>> I won't go as far as to say, "abandon all hope", but you're not really
>> likely to find any help in this forum.
>> """
>
> Not sure about the interrupt latency. If you run this little program
> http://darnok.org/xen/read_interrupts.c
> when capturing in both dom0 and in baremetal are the rate about the
> same?
>>
>> What I donÂt understand is how graphics pass through even works
>> and a tuner card has problems due to the introduced latencies in the
>> IRQs.
>
> The latency is very very miniscule. One could actually verify that this
> is a problem by inserting said latency in the driver so that under
> baremetal the latency would show up.
>
> But the other issue is that if the data is being lost you would at least
> get some. So the buffers ought to have "something" in them? Maybe that
> depends on what compression you use on the coder? If you jus do YUV420
> or the RGB variants and just do a simple 'cat /dev/vide0 > /tmp/file'
> does the output contain anything? Or is just a blob of empty data?

The output contains data, part of the mpeg stream without any continuity.

>> Do you have any more info about this?
>
> The other issue could be related to the vmalloc_32 being in usage
> and not using the DMA API.
>
> I recall posting a patch for this .. Ah:
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>
> Perhaps this is the issue?

Bingo Konrad! That was it :) At least I have just applied the patch,
rebooted under Xen and this time I got a good dump.

Right now I have my usual system running flawlessly under Xen. Time to
take a look again at the suspend/resume issue which I nearly had
working a few days ago.

Thanks a lot for all your help :)

P.S. I'm going to post this info on the linux media mailing list.


-- 
Javier Marcet <jmarcet@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel