Thanks again. I've made a very rough check with diff -y bewteen configs
and they look quite similar.
Not too surprising. I'll be using the 4.6 config for most part, so I
should be safe
Did that to rule out any change on the side of the arch release.
However, I may as well have overseen something, of course.
As for the supposedly relevant parts:
# cat .config-4.5.4 | grep -i vfio
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_KVM_VFIO=y
# cat .config-4.6.5 | grep -i vfio
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
CONFIG_VFIO_PCI_MMAP=y
CONFIG_VFIO_PCI_INTX=y
CONFIG_VFIO_PCI_IGD=y
CONFIG_KVM_VFIO=y
# cat .config-4.5.4 | grep -i mmu
CONFIG_MMU=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_IOMMU_HELPER=y
CONFIG_MMU_NOTIFIER=y
# Near Field Communication (NFC) devices
CONFIG_VFIO_IOMMU_TYPE1=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
# Generic IOMMU Pagetable Support
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_STATS is not set
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_KVM_MMU_AUDIT=y
# cat .config-4.6.5 | grep -i mmu
CONFIG_MMU=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_IOMMU_HELPER=y
CONFIG_MMU_NOTIFIER=y
# Near Field Communication (NFC) devices
CONFIG_VFIO_IOMMU_TYPE1=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
# Generic IOMMU Pagetable Support
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_STATS is not set
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_KVM_MMU_AUDIT=y
Am 10.01.2017 um 22:48 schrieb Manuel Ullmann:
Hello Ede,
you’re welcome. :) Had to look up that for myself.
git tag
shows you the available tags and it is v4.6.
Wouldn’t use olddefconfig on a production kernel, but for bisecting I
considered it sufficient. Probably you should check, that VM relevant
options are still in place on major version jumps, but yeah, it’s
equivalent to running oldconfig and holding return.
Most important is obviously VFIO_PCI_VGA, which has a lot of
dependencies, so check for that on major version jumps:
cat .config | grep VFIO_PCI_VGA
Best regards,
Manuel
Hello Manuel,
big, BIG, B I G thanks for your time and the excellent
instructions. Highly appreciated.
Meanwhile, without dissecting, I have narrowed it further down to the
obvious, that is, the last Kernel of 4.5, which is 4.5.7, is working,
while 4.6 is not. In fact, the general guest behaviour with 4.6 is
horrible, barely usable at all, even without involving the parallel
port.
Further, my parallel device is not even recogniced at all and the
mouse is rather jumpy.
Before the dissecting starts, which will take quite some time, please
allow one more question: The proper tag for Kernel 4.6, is it
git fetch linux-stable refs/tags/v4.5.7:refs/tags/v4.6
or
git fetch linux-stable refs/tags/v4.5.7:refs/tags/v4.6.0
? As I have both variations. The modules are called 4.6.0, the archive
iself just 4.6.
And of course, thanks to you Daimon for the correction as well.
Ede
P.S.: As a side note: Learned something new, did not know about
olddefconfig. Saves a lot of work compared to make oldconfig, when
making larger verion jumps.
Am 07.01.2017 um 18:38 schrieb Manuel Ullmann:
Hello Ede,
you do not need to be a programmer for bisecting. It is just required,
that you can follow a step-by-step guide and adapt examples for your
case. Git documentation is quite good and the first time I bisected
something, I didn’t even know about it, but knew the git command for
jumping through the commit history, which was also sufficient, but more
time intensive. So:
mkdir /path/to/your/new/source
cd /path/to/your/new/source
git init
git remote add linux-stable
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
The following will just fetch the tags inbetween the versions you have
found, sparing you a lot disk space and download bandwidth.
git fetch linux-stable refs/tags/v4.5.4:refs/tags/v4.6.1
https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation
Cherrypicked the Archwiki for the following:
Install build requirements:
pacman -S base-devel xmlto docbook-xsl kmod inetutils bc
Copy your current kernel configuration:
zcat /proc/config.gz > .config
Back to business: You should now have build tools and a configuration
available.
git bisect start
git bisect bad v4.5.4
git bisect good v4.6.1
git will now checkout a commit inbetween this range, which requires that
you repeat the following steps:
make olddefconfig
make -j<number-of-processor-cores> -l<number-of-processor-cores>.0
make modules_install
mount /boot (if required)
make install
Check which version you are now:
git --describe tags
mkinitcpio -g /boot/initramfs-<kernel major and minor versions>.img -k <kernel
version without v>
(Example for 4.5.4:
mkinitcpio -g /boot/initramfs-45.img -k 4.5.4)
grub-mkconfig -o /boot/grub/grub.cfg
sudo systemctl reboot (or su -c 'systemctl reboot' if sudo is not installed)
If the version works, cd to the kernel source again and do
git bisect good
otherwise
git bisect bad
Repeat the above steps from make olddefconfig.
Bisect will print how much steps are left. Once it is finished it will
print out the commit.
Best regards,
Manuel
Hello Alex,
thanks very much for showing some interest. I have found an archive of
older arch kernels and can confirm, the last working kernel is:
Linux kvmother 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST
2016 x86_64 GNU/Linux
the next kernel release from the arch team would be according to the
archive:
Linux kvmother 4.6.1-1-ARCH #1 SMP PREEMPT Thu Jun 2 07:17:31 CEST
2016 x86_64 GNU/Linux
and this already does not work any more. Also crosschecked to 4.6.5-1,
no change and of course none with 4.8.x either.
Installed and reinstalled both (4.5 and 4.6) multiple times, including
power off and hard reset between kernels, and the results are
absolutelty consistent.
Suggests, that either some bug or some required configuration change I
am not aware of has been introduced with Kernel 4.6.
Unfortunately I do not know enough about programming at all to bring
it down to a certain commit (not to look for that), but if there is
anything I could do, just let me know. please.
Thanks again
Ede
Am 06.01.2017 um 00:30 schrieb Alex Williamson:
On Thu, 5 Jan 2017 19:14:29 +0100
Ede Wolf <lis...@nebelschwaden.de> wrote:
Hello,
Running arch, I am having a windows XP guest, to which I am passing
through a PCIe Parallel Card, that again talks to a device that
unfortunately is very picky about interrupts and more so the interrupt
setting within Windows XP for that parallel port.
For a short explanation: Windows XP offers 3 ways to operate the
parallel port:
"never use an interrupt"
"try not to use an interrupt"
"Use any interrupt assigned to that port"
My device requires the last option, otherwise communication does simply
not work, albeit the device itself is detected. So it seems, that
whatever setting I choose within windows xp, it is now ignored and does
not make any difference any more.
However, it used to work perfectly fine up to Kernel 4.5. or 4.6, I do
not remember exactly, but does not work any more with 4.8. Skipped 4.7
for sure.
Booting into the 4.4-lts kernel makes things work as expected, booting
into 4.8.x and communication is broken again. Can be repeated at will
with consistently the same results and holds true now for several
incarnations of the 4.8 kernel the archlinux team has provided so far.
Now I am wondering: Is there any compelling configuration change that I
am not aware of or is this simply a bug? And if, is this related to vfio
or other parts of the kernel and this the wrong place?
Thanks for any help
Any chance you could narrow down where this broke a little further,
perhaps even bisecting the kernel to a specific commit? Thanks,
Alex
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
