On May 16, 2013 2:38 PM, "Andrew Bobulsky" <
rulerof@xxxxxxxxx> wrote:
>
> Hello Gordan, Alex,
>
> On Thu, May 16, 2013 at 2:25 AM, Gordan Bobic <
gordan@xxxxxxxxxx> wrote:
>>
>> On 05/16/2013 01:17 AM, Alex Karaoui wrote:
>>>
>>> Aloha Gordon,
>>>
>>> When you say "BSOD on subsequent start-ups," are you saying that on the
>>> boot after AMD driver installation your system BSODs? How do you manage
>>> to get around that, by simply restarting the host?
>>
>>
>> What I am referring to is the following:
>>
>> 1) Boot up host.
>> 2) Start up domU - works every time now with <= 2GB of RAM (any more 3GB sometimes works. 4GB+ hardly ever gets to the login screen)
>
>
> I thought I'd write in because I've seen this before. This behavior....
>
>>
>> 3) Shut down domU
>> 4) At this stage, starting up the domU usually works. Maybe half of the time it BSODs or loses the USB devices (they show up with a yellow exclamation mark in device manager - ejecting them doesn't help).
>> 5) Repeat from 3) At this point things never get past a BSOD and the only way to get the domU working again is to reboot the host.
>>
>> This should now probably become a couple of new threads:
>> 1) VGA passthrough BSOD-ing with a domU with more than 2GB of RAM
>
>
> ...and more specifically, this behavior---I'm referring to a BSOD that precedes the login screen; before the video driver switches out of the Windows Boot Manager's VGA(?) mode---is eerily similar to a longstanding issue with passing through PCIe devices on ESXi. The workaround is to configure the VM with a custom PCI Hole mapping; I use "pciHole.start = 1100" and "pciHole.end = 2200", though pretty much any "total" exceeding either 1024 (or perhaps simply the memory total in MB on the PCIe device itself), where 2200-1100 in this case = 1100, just fixes the problem entirely.
>
> I don't know for sure if they're related, but the kicker here is that the workaround is required when and only when passing through a PCIe video card to a VM that has more than 2GB of RAM assigned to it! The thread on their forums[1] where I first found this some time ago is ~44 pages long.
>
>>
>> 2) domU reboots cause USB controllers to become unavailable
>>
>> <snippity-snip/>
>
>
> I may be getting lost in the email chain, but I think that USB controllers are the one thing I've never had a problem with. I haven't ever tried attaching an onboard controller though, because every onboard controller I've come across is a regular PCI device... problems passing those are basically to be expected :(
>
> If you want to throw money at that problem, grab a RocketU 1144A or B. The lspci entries for the device[2] are a passthrough-user's dream come true.
>
> There's also the USB/IP project, but I haven't had a lot of luck with it. I actually think that it's an ideal solution to passing USB devices, as I've used commercial software that does the same, and it's good enough to connect audio, keyboard, and mouse to machines that are actually on physically different hosts with zero noticeable lag or packet loss. I'd love to see someone get the F/OSS version working... personally I'd buy the commercial software if it wasn't priced to gouge the crap out of a corporate wallet :(
>
> -----------
>
> Just my two cents of course! I wish I could be a little more helpful here. I seriously admire your persistence on this issue; I probably would have quit a week ago and just bought something else, and am really happy to see you making progress!
>
> I'm currently ignoring my desktop... I just got a ThinkPad Helix tablet and am focusing on getting Xen to work on it for the time being.
>
> Also, on a side note, I can confirm that my HD 4000 graphics does not support FLR... and appears to be a PCI device :(
>
> Cheers,
> Andrew
>
>
