[vfio-users] Interrupt Handling: Regression or config change?

Tue Jan 10 21:18:50 UTC 2017

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 <listac at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users