Re: [Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs 4.3.2

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On October 6, 2014 6:16:35 PM EDT, Zir Blazer <zir_blazer@xxxxxxxxxxx> wrote:
>>> HARDWARE
>>> Processor: Intel Xeon E3-1245V3 (Haswell) -
>http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>>
>> I seem to see 8 CPUs while your serial output say it has 4?
>>
>> Did you disable hyper-threading?
>
>Yes, Hyper Threading is disabled.
>
>
>
>> Anyhow, could you when booting under Xen 4.3 (and Xen 4.4) also use
>> iommu=verbose,debug
>
>Will try adding that to syslinux.cfg the next time I experiment with
>that install, which should be sooner than later. Is there any specific
>log file I should save, or better to repeat all them? Any other command
>line I could include in case you want to get logs of everything in one
>go? Also, should I get logs with the DomU running, or after closing it?
>
>

Just boot it up and 'xl dmesg' them both please.
>
>> And there were no BIOS updates in between using Xen 4.3 or Xen 4.4? I
>recall that BIOS v1.0 on those
>> boards would spit errors.
>
>When I purchased the Motherboard, if I recall correctly, there were no
>BIOS updates posted at Supermicro website, so I should have had the
>first shipping BIOS. There was a BIOS update around the same time I
>received it (Don't recall version because I didn't upgrade, could be
>1.1), then another one which is the 2.0 I have currently, installed
>from X10SAT4_421.zip which should be from April 21 2014. So Xen 4.3.1
>was installed and used with BIOS 1.0 with no issues for 9 months or so.
>
>I did update the BIOS two weeks ago while trying UEFI Boot with Xen
>4.4.1, due to the fact that pretty much all people I saw but me managed
>to get it working, so I through that a Firmware upgrade could fix it.
>It didn't. I finally got it working when I tested with the 3.17 Kernel.
>Right after that I found the Passthrough regression. After giving up
>seeing that no option could make it work, I decided to test again with
>my older Xen 4.3.1 install and it worked fine as always, so that's when
>I decided to test Xen 4.3.2, and it worked, too. So Xen 4.3.1 was
>tested -briefly- with BIOS 2.0, while 4.4.1 and 4.3.2 exclusively with
>2.0. And some days ago I did an standarized test to make sure that I'm
>comparing the latest two versions on common grounds instead of my
>bleeding edge patchwork attempt.
>
>
>
>Some interesing things I found while googling are:
>https://wiki.archlinux.org/index.php/Pulseaudio#Glitches.2C_skips_or_crackling
>Which suggest for the same symptoms I suffer, to disable the IOMMU.
>However, I don't have pulseaudio installed in Dom0, and the issue is in
>DomU. Plus only change was Xen package version installed.
>
>
>Another one, even more interesing because it does involve Xen:
>http://www.gossamer-threads.com/lists/xen/users/282195#282987
>This guy says that when he uses pciback.hide in the Boot Loader exactly
>like I do, he gets sound issues in the DomU, but that he succeded by
>instead letting Dom0 initialize the Sound Card, then using xl
>pci-assignable-add to disconnect it from Dom0 so it can be available
>for DomU. Which means that there could be an initilization issue. That
>Thread is dated one year ago and for Xen 4.2, but its too identical to
>my issue to not want to test this.
>
>
>Because my test Dom0 is extremely minimalist, I need to check what I
>have to install so I can get sound output from Dom0 then proceed to try
>again output from DomU. Chances are that I end up installing a full
>blown Gnome or KDE on it with maybe Chromium and try a Youtube video.
>It also doesn't helps that my DomU selection is only WXP SP3, could
>help to add another Arch Linux DomU, giving that there are now a few
>more variables to test. Maybe the initialization issue is bound to the
>Realtek WXP SP3 Drivers and not other OSes.
>Assuming you have the time and will, as you said that you have near
>identical Hardware, you may want to try to reproduce it yourself. There
>is indeed an issue somewhere related to Xen 4.4.1, but I doubt I can
>pinpoint what exactly it is. I will try to get more logs with the IOMMU
>setting, test without xen-pciback.hide, and post results, but chances
>are that you can do a more in-depth test of whatever I miss.                   
>                 
>

The will is there but the time is sadly not available :-(



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel