|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] xhci passthrough
Hi Konrad,
Due to a 2.6.37-merge-window kernel now being able to boot under Xen i was able
to test my xhci controller under dom0 which i previously couldn't.
The results:
A) 2.6.37-merge-window kernel baremetal: Videograbbing while doing 20
iterations of make -j6 of kernel works.
B) Xen + 2.6.37-merge-window kernel as Dom0: Videograbbing while doing 20
iterations of make -j6 of kernel works.
C) Xen + 2.6.32.24 pvops dom0 + 2.6.37-merge-window kernel DomU: Videograbbing
while doing 20 iterations of make -j6 still freezes the machine without a
trace after a short while.
An other interesting thing is the interrupt rate i see in /proc/interrrupts for
the xhci controller, i measured for 5 minutes each time.
In situation:
A) About 3200 Interrupts/second
B) About 3200 Interrupts/second
C) About 7800 Interrupts/second, what would be 7.8 interrupt per ms which seems
to work as long as you don't stress the rest to the limit.
Which probably causes some sort of deadlock (some where in the path from
device, xen, dom0/pciback , domU/pcifront, xhci driver, application.) when not
delivered on time or when it boldly goes on a code path where no one has gone
before ..
Compared with a measurement of interrupts by a USB2 controller:
Around 155 Interrupts/second
Probably a silly question without a right answer ... but what interrupt rate
would you guess it should be able to take ?
And is it logically that when passed through it causes around 2.5 times more
interrupts ?
Now testing on a Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
--
Sander
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] xhci passthrough,
Sander Eikelenboom <=
|
|
|
|
|