From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gennady Marchenko Subject: Re: Re: VGA passthrough on unstable Date: Tue, 24 May 2011 21:27:36 +0400 Message-ID: References: <20110524154305.GE32595@reaktio.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0603074822==" Return-path: In-Reply-To: <20110524154305.GE32595@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= Cc: Liwei , xen-devel , xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0603074822== Content-Type: multipart/alternative; boundary=90e6ba6e8f1c6ff11a04a408e75a --90e6ba6e8f1c6ff11a04a408e75a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D 0 and sever= al problems, as example - no any accelerate in video out at all. Have you checked it with gfx_passthrough =3D 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=3D256M] Memory at febc0000 (64-bit, non-prefetchable) [disabled] [size=3D12= 8K] I/O ports at e000 [disabled] [size=3D256] Expansion ROM at feba0000 [disabled] [size=3D128K] 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.tx= t) 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=C3=A4rkk=C3=A4inen w= rote: > 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 =3D 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 drive= r > > module (e.g. owner tag). > > Arg3: 0000000000000000, Optional error code (NTSTATUS) of the las= t > > 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > > --90e6ba6e8f1c6ff11a04a408e75a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Liwei,

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Memory at d0000000 (64= -bit, prefetchable) [disabled] [size=3D256M]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 Memory at febc0000 (64-bit, non-prefetchable) [disabled] [size=3D12= 8K]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I/O ports at e000 [disabled] [siz= e=3D256]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expansion ROM at feba0000 [disabled] [size= =3D128K]


=C2=A0was bad (can&#= 39;t compile the sources), I will check it now again.

<= div>And I saw the patch with autodetect BARs (Pasi looked at it below: http://lists.xensource.com/archives/html/xen-devel/2010-12/txtNwR= lN3jloS.txt ) but I can't apply this patch on current ustable. If y= ou 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=C3=A4rkk=C3=A4inen <pasik@iki.fi> wrote:
On Tue, May 24, 2011 at 11:35:25PM +0800, Liwei wrote: > Hello all,
> =C2=A0 =C2=A0 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.=
> =C2=A0 =C2=A0 With those changes I am able to boot into Windows with t= he driver
> installed (Fresh install with gfx_passthrough =3D 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<= br> > monitors. Everything looks good - until I tried to physically login. > =C2=A0 =C2=A0 First two tries:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 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.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The logs from qemu and syslog didn't s= how 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<= br> > through a script that repeatedly calls xl dmesg over a ssh connection.=
>
> =C2=A0 =C2=A0 After that, I tried to compare the memory ranges from De= vice
> 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.
> =C2=A0 =C2=A0 Third and subsequent tries:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 After logging in, but before the login scr= een disappears, the
> DomU reboots. I didn't see any BSOD flash by but a minidump appear= s.
> Analysing it gives me the following:
> =C2=A0 =C2=A0 =C2=A0 VIDEO_TDR_FAILURE (116)
> =C2=A0 =C2=A0 =C2=A0 Attempt to reset the display driver and recover f= rom timeout failed.
> =C2=A0 =C2=A0 =C2=A0 Arguments:
> =C2=A0 =C2=A0 =C2=A0 Arg1: fffffa8003bdb010, Optional pointer to inter= nal TDR recovery
> context (TDR_RECOVERY_CONTEXT).
> =C2=A0 =C2=A0 =C2=A0 Arg2: fffff8800f204520, The pointer into responsi= ble device driver
> module (e.g. owner tag).
> =C2=A0 =C2=A0 =C2=A0 Arg3: 0000000000000000, Optional error code (NTST= ATUS) of the last
> failed operation.
> =C2=A0 =C2=A0 =C2=A0 Arg4: 0000000000000002, Optional internal context= dependent data.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Also I noticed that if the display goes in= to suspend, it never
> comes back. I'm still able to do stuff over remote desktop though.=
>
> =C2=A0 =C2=A0 Sometimes I get the following minidump too, even in a re= mote
> desktop session:
> =C2=A0 =C2=A0 =C2=A0 BUGCODE_USB_DRIVER (fe)
> =C2=A0 =C2=A0 =C2=A0 USB Driver bugcheck, first parameter is USB bugch= eck code.
> =C2=A0 =C2=A0 =C2=A0 Arguments:
> =C2=A0 =C2=A0 =C2=A0 Arg1: 0000000000000008, USBBUGCODE_RESERVED_USBHU= B
> =C2=A0 =C2=A0 =C2=A0 Arg2: 0000000000000006, USBHUB_TRAP_FATAL_TIMEOUT=
> =C2=A0 =C2=A0 =C2=A0 Arg3: 0000000000000006, TimeoutCode: Timeout_PCE_= Disable_Action -
> PortData->PortChangeListDone - Timeout trying to set Disable bit > =C2=A0 =C2=A0 =C2=A0 Arg4: fffffa8003434000, TimeoutContext - PortData=
>
> =C2=A0 =C2=A0 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.
>
> =C2=A0 =C2=A0 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 someo= ne
> giving me a hand in this.
>
> =C2=A0 =C2=A0 Also attached are dmesg and qemu logs.
>
> Thanks




> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenso= urce.com
> htt= p://lists.xensource.com/xen-devel


--90e6ba6e8f1c6ff11a04a408e75a-- --===============0603074822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0603074822==--