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

[Javier Marcet <jmarcet@xxxxxxxxx>]

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

>> >> 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.
>>
> I see.
>> >> 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.
>
> Woohoo!

:)

>> 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.
>
> Keep in mind that for the suspend/resume you need out of mainline
> patches for right now. I hadn't yet upstreamed all the parts. They are
> in  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> devel/acpi-s3.vXX (I believe 11 would apply cleanly to your tree?)
>
> Keep in mind that there were some bugs in Xen 4.2 in regards to resume.
> Look on xen-devel for emails between Jan and Ben Guthro.

I have the needed patches in place and I have followed that thread, at
least until a few days ago. I have opened a new one about the only
problem I still have with S3: http://goo.gl/vYK42

>> Thanks a lot for all your help :)
>>
>> P.S. I'm going to post this info on the linux media mailing list.
>
> If you could CC me on it I can provide the technical explanation
> for the 'DMA-API-ing the vmalloc_32' call.

I have CCed you in my last reply to the thread. I'm pretty certain
Devin understood well the problem and what the solution your patch
gives.


-- 
Javier Marcet <jmarcet@xxxxxxxxx>

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