|   xen-devel
Re: [Xen-devel] Re: VGA passthrough on unstable 
| 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,> Hello all,
 >     I've made some progress after manually editing dsdt.asl to reserve
 > my card's memory ranges based on lspci,
 
 
 
 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
 | 
 |  |