jjohansenhallyn: can I throw your tested by on the patch04:46
hallynjjohansen: yup!04:48
alkisgGood morning all05:56
alkisgSo currently I'm at: problem verified between vanilla 4.15rc4 and 4.15rc5, and I've also done two "git bisect good" steps after that. Each "git bisect" step takes me 1 hour, so I might hopefully finish it today...05:59
f_galkisg: welcome to the world of kernel bisecting, where progress can be slow and tiresome :) at least your reproducer is easy and fast - I've had bisects where the test was "do the following non-trivially automatable steps in several VMs, some of which run Windows", with the chance of triggering the problem being about 30%.07:00
f_gso each build took ~10 minutes, then rebooting/kexecing, then preparing the VMs, then running the test (that took about 20 minutes), then repeat the preparation and test at least 5 times unless the issue triggered07:01
f_gthat was a fun week and a half ;)07:01
alkisgMeh... well, at least I can do a few things while I'm building the kernel... but I'd really appreciate a monster PC right now, that could build it in under half an hour...07:01
alkisgOne of the builds needed 88 mins because I was doing some other work simultaneously :(07:02
alkisgTesting time :) (unfortunately I can only reproduce it on my work pc, not any spare ones!)07:14
alkisg3rd bisect => good. I'm afraid the problem will be the pti patches that came right before rc5.07:20
f_galkisg: three good beside rc4? or including?07:28
alkisgf_g: rc4 good, rc5 bad, then git bisect good 3 times07:33
alkisg$ git bisect good07:35
alkisgBisecting: 20 revisions left to test after this (roughly 4 steps)07:35
alkisg[ed1bbc40a0d10e0c5c74fe7bdc6298295cf40255] x86/cpu_entry_area: Move it to a separate unit07:35
f_galkisg: sounds like you should be done soon, and that it's like one of the PTI changes.07:37
alkisgwell, in 4 hours... :(07:37
f_gout of curiosity, did you test -rc8 as well? if not, you might want to add that to your next reboot cycle..07:39
alkisgYes, that was one of my very early tests, but only using the mainline .deb, not with compiling07:40
f_gnevermind then07:41
alkisg(I also tested the daily deb)07:41
alkisggit status ==> HEAD detached at ed1bbc4, You are currently bisecting, 09:36
alkisg...and yet that gave me a kernel named 4.14? Is that possible?09:36
alkisg(while bisecting between 4.15rc4 and 4.15rc5)09:36
alkisgIn bisection step 3, I got this: linux-image-4.15.0-rc4-custom_4.15.0-rc4-custom-6_i386.deb09:38
alkisgThen moving forward (git bisect good), I got this: linux-image-4.14.0-custom_4.14.0-custom-7_i386.deb09:38
alkisg...can that be because some older commit got merged later on, or does it sound like I did something wrong?09:39
alkisgAnyway continuing with: $ git bisect good/ Bisecting: 10 revisions left to test after this (roughly 3 steps)/[9c294ec08408ed90c0f2d994a7979366675e3734] Merge tag 'powerpc-4.15-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux09:41
f_galkisg: yes, that is usually an artifact of bisecting into some merged branch which hasn't been rebased prior to getting merged. the git DAG in linux-stable looks rather interesting :P10:07
alkisgty! I got worried for my sanity there for a while :D10:13
alkisg$ git bisect good / Bisecting: 5 revisions left to test after this (roughly 3 steps) / [24e3a7fb60a9187e5df90e5fa655ffc94b9c4f77] libnvdimm, btt: Fix an incompatibility in the log layout11:27
alkisgYey for grub-reboot, it allows to continue this remotely :)15:52
alkisg$ git bisect good/ Bisecting: 2 revisions left to test after this (roughly 2 steps) /[f6c4fd506cb626e4346aa81688f255e593a7c5a0] x86/cpu_entry_area: Prevent wraparound in setup_cpu_entry_area_ptes() on 32bit15:54
alkisgSo, I'm guessing I'll find that the problem was https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=caf9a82657b313106aae8f4a35936c116a152299, the pti preparation patches.16:01
alkisgWhat next? File a bug report in Ubuntu? Or directly upstream? Or both?16:01
alkisgOr "blame" that commit on github?16:02
alkisgAlso, would I be able to test the latest version without that huge patch? I'm not sure it can be cleanly un-applied in the latest version...16:04
mattsmdo any scripts / automation exist to copy a ubuntu kernel to a remote machine and boot into it?/16:23
alkisgmattsm: I don't know, but it shouldn't be hard to do this with ssh/scp/grub-reboot...16:37
mattsmalkisg yea i was just curious... for grub-reboot I'd need to add an entry for it is all i suppose16:39
alkisgmattsm: normally, installing a kernel add the grub entr16:39
alkisggrub-reboot then just selects that for the next reboot16:40
mattsmwell, i need to copy kernel + modules and add grub entry... and try it out16:40
mattsmwas just hoping for a script that copied stuff to a target machine existed16:41
alkisgmattsm: ah, you're not using a .deb package that does all that automatically?16:41
mattsmalkisg im attempting to rebuild a kernel on a remote machine and copy it over16:43
TJ-mattsm: you can also reboot into another kernel using kexec - but best to test it on the actual target hardware in person first before relying on it for remote reboot :)16:58
mattsmTJ-: i've got remote power reset, so that would be OK16:58
TJ-mattsm: in which case after rsync-ing the /boot/vmlinuz-$VERSION, /boot/initrd.img-$VERSION and /lib/modules/$VERSION/* you can do "sudo kexec -l /boot/vmlinuz-$VERSION --initrd /boot/initrd.img-$VERSION --reuse-cmdline" (that  loads them into memory) you can do either "sudo systemctl reboot" or for a more abrupt switch "sudo kexec -e"17:01
mattsmTJ-: that sounds like it will work pretty good, also it seems like the kernel build instructions do in fact build a deb as well17:01
TJ-Although recently I've found kexec seems to be broken on every hardware and kernel version combination I've tried17:02
mattsma major downside17:03
TJ-mattsm: if you're doing "fakeroot debian/rules binary" yes that generates the packages in the parent directory17:04
mattsmdoes anyone know where the zesty kernel configs are?17:04
mattsmTJ-: yea im playing with that17:05
mattsmi suppose that will put the config somewhere?17:05
TJ-mattsm: they're combined at build-time from fragments (-common + -flavour specific)17:05
TJ-mattsm: the generated config will be in the build directory as .config 17:05
mattsmTJ- nice, i  think i have a zesty kernel building17:06
OliverOHi everyone!17:12
OliverOAny idea why v4.14.14 (released 2 days ago) build does not show up in http://kernel.ubuntu.com/~kernel-ppa/mainline?17:12
chilukOliverO it could be getting held up by requisite changes to gcc in order to enable retpoline.  If I was the kteam that's what I would expect.17:43
=== ben_r_ is now known as ben_r
mattsmWhat gcc version does Ubuntu intent to use for building zesty kernel?17:52
mattsmand is there a way to tell fakeroot which version to use?17:55
tomreyn!zesty | mattsm 18:25
ubot5mattsm: Ubuntu 17.04 (Zesty Zapus) was the 26th release of Ubuntu. Support ended on January 13th, 2018. See !eol and !eolupgrade18:25
tomreynjust in case you're not aware of the EOL status18:25
tomreynother than that, to actually answer your question, my guess would be: the gcc version available in zesty.18:26
mattsmhmm which tree is in the next version?18:27
tomreyn!info gcc artful18:27
ubot5gcc (source: gcc-defaults (1.173ubuntu1)): GNU C compiler. In component main, is optional. Version 4:7.2.0-1ubuntu1 (artful), package size 5 kB, installed size 64 kB18:27
mattsm!artful | mattsm18:28
ubot5mattsm, please see my private message18:28
tomreynnote my guess can be very wrong, i'm not sure how / where default kernel image packages are built.18:29
mattsmyou made it clear to me i was confused as well18:30
mattsmi wanted the next kernel version, so bionic beaver...?18:30
tomreynbut i would indeed expect that building them with the gcc version of the same ubuntu release will work without an issue18:30
tomreynbionic is going to be 18.04 lts18:31
tomreynzesty was 17.04, artful is 17.1018:31
tomreynso 'next' can mean many things ;)18:31
mattsmwell, there is an ubuntu-bionic tree in the same place18:38
alkisg$ git bisect bad / Bisecting: 0 revisions left to test after this (roughly 1 step) / [613e396bc0d4c7604fba23256644e78454c68cf6] init: Invoke init_espfix_bsp() from mm_init()18:38
alkisgAt least it's NOT the pti preparation patches :)18:39
mattsmDoes anyone know if there is a wiki for getting changes into an Ubuntu kernel release....18:56
TJ-mattsm: bug report, plus email to the kernel-team mailing list19:11
mattsmTJ- perfect, thanks19:13
alkisg$ git bisect bad / Bisecting: 0 revisions left to test after this (roughly 0 steps) / [92a0f81d89571e3e8759366e050ee05cc545ef99] x86/cpu_entry_area: Move it out of the fixmap19:56
alkisg...so I guess I'll file this to bugzilla.kernel.org...19:57
ubot5bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New]20:20
TJ-alkisg: best to send an email to the maintainer and sub-system mailing list (using "scripts/get_maintainer.pl  path/to/source/file.c" )20:21
alkisgTJ-: after reporting the bug, bugzilla said it notified his mail20:22
alkisgIs that enough, or should I also send it to the sub system mailing list?20:22
TJ-alkisg: oh, cool, i've not noticed it do that for my reports!20:22
alkisgEmail sent to:            bugsfx@gmail.com,          tglx@linutronix.de20:22
alkisgThat second mail there is the committer20:22
TJ-alkisg: yeah, that's Gleixner :)20:23
alkisgI saw a follow up commit where fixes a breakage in 32bit, and he blames "the moron that wrote the code", and I think that's again himself... sounds like he has a sense of humor :D20:24
TJ-alkisg: he signed off under protest on a commit for 4.14 that fixed a regression for nvidia that I reported with " Despised-by: Thomas Gleixner <tglx@linutronix.de>" (commit 87df26175e67)20:28

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!