WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Pasi Kärkkäinen <pasik@xxxxxx>
Subject: Re: [Xen-devel] Re: VGA passthrough on unstable
From: Gennady Marchenko <gennady.marchenko@xxxxxxxxx>
Date: Tue, 24 May 2011 21:27:36 +0400
Cc: Liwei <xieliwei@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 24 May 2011 10:28:41 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W610yaeOGzlWb/vUBa1icV4+TljSya8zOObbhqiTJ8Q=; b=RNxetC8zD7nAOVIilqnaN+XhEr4pXy7pvJYQ8w88IB9yE7towOLYF7FAdrYeLVMm5m KHImUr7ty4ZYkBXffuwggDFeE8HNDtN2trcdPNTxANBLhkJtRL5cpVWwWgZab7gbl1r2 zQ26175pAWxFoMBrSvfnXXbFMMoAF5ProkoJ8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h35y9VS3Z4BPsK0/FCcsx67pd3vMvu6MwMY7ME8U3JreMuIBvHRG05hXr0q2nr8N2c kpADMxtPM5y+XgBdvTg1xD4gsI7YWPz1foV80/q+3iiqSobhZrpEeHoM+lAvnkhjkyY2 ETjslKq84+j320UHCc5dVWD5lCnn0JzM5okCo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110524154305.GE32595@xxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <BANLkTi=bbaAhhM3ATfdrodU1t=ThdFzxoA@xxxxxxxxxxxxxx> <20110524154305.GE32595@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Liwei,

Thanks a lot for big report. I saw a some messages where users told about wrong bios load when they load pri gfx with gfx_passthrough = 0 and several problems, as example - no any accelerate in video out at all. Have you checked it with gfx_passthrough = 1? The result are same? I saw your last message where with adapt vbars but first try to write correct memory range to the sources from my lspci:

        Memory at d0000000 (64-bit, prefetchable) [disabled] [size=256M]
        Memory at febc0000 (64-bit, non-prefetchable) [disabled] [size=128K]
        I/O ports at e000 [disabled] [size=256]
        Expansion ROM at feba0000 [disabled] [size=128K]


 was bad (can't compile the sources), I will check it now again.

And I saw the patch with autodetect BARs (Pasi looked at it below: http://lists.xensource.com/archives/html/xen-devel/2010-12/txtNwRlN3jloS.txt ) but I can't apply this patch on current ustable. If you have a little time, take a look at it please mayb you so smart to adapt it...

Gennady.

On Tue, May 24, 2011 at 7:43 PM, Pasi Kärkkäinen <pasik@xxxxxx> wrote:
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-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel