sorry, forgot to reply all ...
Begin forwarded message:
> From: "John McDermott (U.S. Navy Employee)" <john.mcdermott@xxxxxxxxxxxx>
> Date: September 17, 2010 2:57:59 PM EDT
> To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Subject: Re: [Xen-devel] Has Anyone Been Able to Run PVOPS DomU Against any
> nVidia Chipset?
>
> Jeremy,
>
> Thanks. I will probable build a new development system that has an on-board
> Matrox chipset. Meanwhile, I willing to keep pounding on this hardware to see
> what is causing the problem. I have a tarball of the serial output, lspci,
> .config etc., from the i7 machine, if that would be of any help.
>
> On Sep 17, 2010, at 2:35 PM, Jeremy Fitzhardinge wrote:
>
>> On 09/17/2010 09:53 AM, John McDermott (U.S. Navy Employee) wrote:
>>> Xen Developers,
>>>
>>> This has already been posted to Xen-Users, but I got no response.
>>>
>>> Short version: has anyone been able to run a 2.6.32.18 PVOPS domU, on Xen
>>> 4.0.1, on Fedora 13, against any nVidia chipset? I'd like to know which
>>> chipset please.
>>
>> By "nVidia chipset" do you mean a system chipset, or specifically a
>> graphics card?
>
> @Jeremy, both the boxes have graphics cards made by nVidia, but as far as I
> can tell the issue is the chipset on the card.
>>
>> By "run ... pvops domU ... against any nVidia chipset" do you mean
>> passing the hardware through to the domU?
>
> @Jeremy, no passthrough.
>>
>> Are you running domU as HVM or PV? If it is HVM, are you using stubdoms?
>
> @Jeremy, I have tried both HVM and PV domU; no stubdoms. Basically, I just
> followed the directions Boris D. has on his blog, which seem to work fine
> until things get to domU video time.
>>
>>> Long version:
>>>
>>> I have encountered what appears to be an interesting video or DRM problem
>>> with this combination. Dom0 runs X11 without problems but this
>>> combination will not run X11 as dom U. While attempting to install Fedora
>>> 13 dom U as an HVM, using a 2.6.32.18 PVOPS dom0, running on Xen 4.0.1 on
>>> Fedora 13, using virt-install --nographics, it reaches the point following
>>> the XML display of the boot guest configuration, reports an
>>>
>>> (EE) FBDEV(0): FBIOBLANK: Invalid argument
>>>
>>> error and then hangs with garbage displayed on my remote xterm console.
>>> (Virt-install --vnc dies also.) My serial console shows a bunch of
>>> hypervisor
>>>
>>> (XEN) HVM2: int13_harddisk: function 41, unmapped device for ELDL=81
>>> ...
>>>
>>> and then some
>>>
>>> ...
>>> (XEN) vlapic.c:702:d2 Local APIC Write to read-only register 0x30
>>>
>>> error messages.
>>
>> I think those are more warnings than errors. Are there any other error
>> messages?
>
> @ Jeremy, not from Xen and all of the other errors are X11 errors. My xterm
> just goes to garbage when I try to virt-install an HVM.
>>
>>> I can get a pvops domain U to install --nographics, but the resulting guest
>>> cannot start X and fails with the same "(EE) FBDEV(0): FBIOBLANK: Invalid
>>> argument". No hypervisor error messages are generated by this failure.
>>
>> If you're using an emulated FB then it should Just Work, and be
>> independent of whatever the host graphics chip is - and emulated is
>> probably what you should be using for install regardless of what you
>> plan to do once the guest is installed.
>
> @Jeremy, that is what I expected; that is why I posted when it did not; it
> surprised me. In my admittedly dated experience with fighting nVidia on Linux
> since about 1998, nVidia just makes awkward things happen. All of my recent
> coding experience is in the hypervisor code, which is where our research is
> focused. So I am a noob about modern Linux kernels and hope they just work.
>
>>
>> If you are passing through a graphics controller, how are you making
>> sure that dom0 isn't also using it?
>
> @Jeremy, not passing through.
>>
>>> I have tried to get this kernel-hypervisor combination working on 2
>>> different boxes:
>>>
>>> 1) a Dell Precision 690 with an Intel E6320 processor (I don't think this
>>> is the issue) and an nVidia Quadro NVS 285, which X11 reports as nVidia NV
>>> 44. Plain old Fedora 13 uses the nouveau driver with no problems. Udev
>>> tells me it is version 153. The problem remains even with the kernel booted
>>> nopat.
>>>
>>> 2) a "roll-your-own" with EVGA X58 SLI motherboard / Intel i7 combination,
>>> with an nVidia GEForce 9800 GTX+, which X11 reports as nVidia G92. Again,
>>> plain old Fedora 13 uses the nouveau driver for this, without problems.
>>> Trying a pvops domU gives me the same behavior: Fedora domU installs and
>>> runs fine, but cannot start X11.
>>>
>>> I have tried this against 2 kernels: Jeremy's e6b92c and Michael Young's
>>> 2.6.32.21-167.xendom0.fc13.x86_64. (The latter fails in video during kernel
>>> boot, when I use init=/sbin/upstart, but boots OK without it, but then
>>> fails to run X on domU's.) When building these kernels, both complain about
>>> missing the nouveau module at depmod time.
>>>
>>> Before I go swapping cards or outright buying one, has anyone run this
>>> pvops combination against any nVidia-based graphics card? Does pvops
>>> require an ATI chipset?
>>
>> Konrad has done a lot of work on making many different graphics cards
>> work, including nVidia, at least in dom0.
>
> @Jeremy, the nVidia stuff runs great in the pvops dom0 on both of my boxes.
> Using the nv driver I think?
>>
>>> Has pvops been run against an onboard Matrox chipset, as on a server?
>>
>> Yes, my home server machine has a Matrox controller which works OK.
>>
>> J
>
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
>
> J.P. McDermott building 12
> Code 5542 mcdermott@xxxxxxxxxxxxxxxx
> Naval Research Laboratory voice: +1 202.404.8301
> Washington, DC 20375, US fax: +1 202.404.7942
>
>
>
>
>
>
>
----
What is the formal meaning of the one-line program
#include "/dev/tty"
J.P. McDermott building 12
Code 5542 mcdermott@xxxxxxxxxxxxxxxx
Naval Research Laboratory voice: +1 202.404.8301
Washington, DC 20375, US fax: +1 202.404.7942
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home