[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] Re: [Xen-devel] Re: VGA passthrough on unstable



On Tue, May 24, 2011 at 11:35:25PM +0800, Liwei wrote:
> Hello all,
>     I've made some progress after manually editing dsdt.asl to reserve
> my card's memory ranges based on lspci, 

Hello,

Did you take a look at this patch? 
http://lists.xensource.com/archives/html/xen-devel/2010-12/msg00705.html
It supports dynamic detection of BARs and might help you (if you're not using 
it already).

-- Pasi

> and fixing a bug in the
> previous patch where a pair of braces were missing causing the wrong
> video BIOS to be loaded. The fixed patch is attached. Do take note
> that I've also removed the changes for secondary card passthrough.
>     With those changes I am able to boot into Windows with the driver
> installed (Fresh install with gfx_passthrough = 0). Logging in using
> remote desktop, I can see that the driver is active. I also see that
> screen spanning is active as I can move my mouse pointer between both
> monitors. Everything looks good - until I tried to physically login.
>     First two tries:
>         The login screen disappears, leaving both screens black with
> my cursor free to move around. After a few seconds, the whole system
> (Dom0 + DomU) locks up. The reset button didn't work as normal;
> usually pressing it will immediately reboot the PC, but this time it
> had no response for a few seconds, then it shut down, and almost
> immediately started again, returning back to normal. Weird.
>         The logs from qemu and syslog didn't show anything special
> happening before and up to the lockup. xl dmesg didn't throw up
> anything interesting before the lockup either, though that was viewed
> through a script that repeatedly calls xl dmesg over a ssh connection.
> 
>     After that, I tried to compare the memory ranges from Device
> Manager to the ranges specified in dsdt.asl. Matches. But I also
> noticed the original PCI memory reserve overlapped with the range of
> the card. Not sure whether that was bad, but I pushed the range back
> anyways and tried again.
>     Third and subsequent tries:
>         After logging in, but before the login screen disappears, the
> DomU reboots. I didn't see any BSOD flash by but a minidump appears.
> Analysing it gives me the following:
>       VIDEO_TDR_FAILURE (116)
>       Attempt to reset the display driver and recover from timeout failed.
>       Arguments:
>       Arg1: fffffa8003bdb010, Optional pointer to internal TDR recovery
> context (TDR_RECOVERY_CONTEXT).
>       Arg2: fffff8800f204520, The pointer into responsible device driver
> module (e.g. owner tag).
>       Arg3: 0000000000000000, Optional error code (NTSTATUS) of the last
> failed operation.
>       Arg4: 0000000000000002, Optional internal context dependent data.
>         Also I noticed that if the display goes into suspend, it never
> comes back. I'm still able to do stuff over remote desktop though.
> 
>     Sometimes I get the following minidump too, even in a remote
> desktop session:
>       BUGCODE_USB_DRIVER (fe)
>       USB Driver bugcheck, first parameter is USB bugcheck code.
>       Arguments:
>       Arg1: 0000000000000008, USBBUGCODE_RESERVED_USBHUB
>       Arg2: 0000000000000006, USBHUB_TRAP_FATAL_TIMEOUT
>       Arg3: 0000000000000006, TimeoutCode: Timeout_PCE_Disable_Action -
> PortData->PortChangeListDone - Timeout trying to set Disable bit
>       Arg4: fffffa8003434000, TimeoutContext - PortData
> 
>     Also, if I give the DomU more than about 3GB of memory, windows
> fails to boot with the non ACPI compliant BIOS BSOD. Also, windows
> installer doesn't get past the "Starting Windows" part, the pulsating
> logo also never appears.
> 
>     I'm basically learning what every part of the code I'm messing
> with does as I go on, but this is really way too complex for one
> person to go through in a reasonable timeframe. So most of the changes
> I've made are pretty bruteforce-y. I'd really appreciate someone
> giving me a hand in this.
> 
>     Also attached are dmesg and qemu logs.
> 
> Thanks




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.