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.al...@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 <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
