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

[Manuel Ullmann]

Hi Daimon,

thanks for the note. Now there shouldn’t be any hindrances for
bisecting, are they, Ede? ;)

Best regards,
Manuel
> Hi Ede,
> Found a small typo, the below command should be "git describe --tags".
> The bisecting is as easy as compiling a pkg :)
>
>>Check which version you are now:
>>git --describe tags 
>
> Regards,
> Daimon
>
> On Sunday, January 8, 2017 1:40 AM, Manuel Ullmann
> <ullman.alias at posteo.de> wrote:
>
> 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
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users