[07:05] <f_g> bjf: thanks. like I said, we've already completed our in-house testing based on those and have begun rollout to users yesterday - no negative feedback so far, let's see what today brings ;)
[09:09] <alkisg> If I want to buy a new intel cpu, can I buy something that won't have the meltdown/spectre performance impact?
[09:12] <apw> not that i know of
[09:15] <alkisg> Thank you apw
[09:32] <f_g> I think one of the backports for 4.4 left an erroenous kfree in arch/x86/events/intel/ds.c
[09:32] <f_g> f8365429a3dc1377e99d821be17cdeb76dd4b815
[09:33] <f_g> vs 20cbe9a3aa2e341824da57ce0ac6d52cbffaa570
[09:34] <f_g> the latter removes kfree(ds); from release_ds_buffer
[09:35] <f_g> the commits are otherwise identical (modulo location of modified file and commit message/hashes)
[09:36] <f_g> apw, bjf: ^^
[11:17] <apw> f_g, odd
[11:17] <f_g> probably just an oversight since the diff was manually applied / fixed up? not sure..
[11:19] <apw> f_g, most likely, but still an odd differnce
[11:21] <f_g> apw: users reported the following on some HP DL G7 boxes: https://imgur.com/a/vVbR0 , I'll see whether the kernel without the kfree gets rid of that
[11:25] <apw> f_g, which tree is 20cbe9a3aa2e341824da57ce0ac6d52cbffaa570 in ?
[11:26] <f_g> v4.4.110
[11:29] <f_g> (~33 to be exact)
[11:33] <apw> ahh ok
[11:46] <tseliot> apw: hey, any reason why the updates seem to require libelf-dev to be installed? bbswitch said that when DKMS failed. Nvidia didn't build either, but I missed the log
[11:46] <apw> tseliot, i do not, sounds odd anything would be different
[11:47] <tseliot> apw: let me try removing that package, to see if I can reproduce the problem with nvidia
[11:49] <tseliot> apw: yes, I can reproduce it: Makefile:969: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop.
[11:49] <apw> is that for out of tree bits using the kernel ?
[11:51] <tseliot> apw: nvidia and bbswitch
[11:51] <f_g> ZFS as well
[11:51] <f_g> (when building out-of-tree)
[11:52] <tseliot> apw: that's with 4.13.0-24.28
[11:52] <f_g> (we reverted to FRAME_POINTER downstream)
[11:52] <apw> tseliot, sounds like we should add that as a dependency of the headers
[11:53] <tseliot> apw: I think so. I've tested this in artful
[11:54] <tseliot> let me send an email, I'm not sure you are subscribed. Leann is
[15:30] <ernstp> I noticed that the cves fixed in 4.13.0-22.25 are not fixed in 4.13.0-24.28 right now
[15:39] <bjf> ernstp, that is correct. the meltdown patches have been applied to the code that was in the previous -update
[15:40] <bjf> ernstp, the CVEs that were sitting in -proposed will be reapplied and released at a future date
[15:54] <dsd> apw: hi again, anything i can help with to help the KPTI work move forward?
[15:54] <dsd> (artful)
[16:40] <leitao> when I try to build trusty kernel on ppc64el I got /home/ubuntu/kernel/linux-private/arch/powerpc/kernel/exceptions-64s.S:721: Error: unrecognized opcode: `hwsync'
[16:40] <leitao> should I upgrade gcc in order to build the kernel?
[16:41] <leitao> I am using standard gcc-4.8
[16:43] <cjwatson> this isn't my field but wouldn't that be binutils rather than gcc?
[16:44] <cjwatson> added in 2.25.1 I *think(*
[16:47] <leitao> cjwatson, was binutils 2.25 made available on trusty?
[16:47] <cjwatson> I don't know if the relevant feature was backported
[16:47] <cjwatson> not my field, like I say
[16:49] <leitao> cjwatson, no worries. I am wondering how it is being compiled.
[16:49] <leitao> klebers, do you know?