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
