=== gerald is now known as Guest85795
[06:46] <raj_> "kernel: Cannot read proc file system: 1 - Operation not permitted. " getting these repeated messages  million times every minute in my syslog on 12.04 ubuntu VPS based on OpenVZ, anyone has any idea please   ???
[07:47] <ppisati> yo
[08:07] <cristian_c> Hello, I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
[08:07] <cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel. I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
[08:08] <cristian_c> A question:
[08:08] <cristian_c> 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit.
[08:09] <cristian_c> exactly, what have I to do, about this point?
[08:22] <cristian_c> Any ideas?
[08:47] <apw> ppisati, moin
[08:58]  * apw has severe dajar-vue (and spelling failure)
[08:59] <apw> cristian_c, i am sure we have had this conversation before no?  which bug #
[09:08] <cristian_c> apw, ok, but I don't know I hae to do, anyway
[09:09] <apw> if you tell us the bug number again, we can put the instructions in the bug
[09:09] <cristian_c> ok
[09:09] <cristian_c> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972604
[09:09] <ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged]
[09:10] <cristian_c> *have
[09:11] <apw> cristian_c, you have tested the mainline kernel, and joe has marked this as needing a bisect
[09:11] <apw> that normally means he will get to it when he gets a chance to start that bisect, and will put more instructions in the bug
[09:11] <cristian_c> apw, ok, but I was told to open an upstream bug report too
[09:12] <apw> i'll poke him when i see him (he is on a differnt timezone) to see where it is on his queue
[09:12] <apw> if joe is going to do a bisect, it can wait i suspect (the upstream bug)
[09:15] <cristian_c> apw, ok, then I'll look occasionally the report on Lauchpad from now on, in order to be informed of the transition to the next step
[09:45] <xnox> how long does linux autopkgtest usually take? forever, and a half or just an eternity?! =)
[09:50] <apw> xnox, it is building one flavour, so on a fast machine an hour, otherwise ... who knows
[09:50] <apw> xnox, what package triggered it, so i can find it
[09:51] <xnox> apw: initramfs-tools upload.
[09:51] <xnox> apw: i'll just wait, I guess.
[09:52] <apw> xnox, oh really, there is a merge of 115 pending review somewhere, damn
[09:52] <apw> xnox, i am pleased to report that there seems to be no timing info in the previous one to guage it from
[09:53] <apw> xnox, but i would guess that it took about 1.5 hours from the logs we do have
[09:59] <xnox> apw: excellent. 115 -> done by who?
[10:00] <xnox> apw: it's a tad late to do that past feature-freeze. I did the required cherrypick to unbreak intel-microcode package (which is also wanted by a customer)
[10:00] <apw> xnox, moi, just checked and the bits you pulled in are (obviously) in it ...
[10:00] <apw> xnox, yep, i actually did it before FF, but it has taken more time than it should to get the appropriate review, due to customers poking
[10:01] <xnox> apw: cool.
[10:01] <apw> xnox, it is in infinity's hands, he'll either sort it, or it'll go into U one way or the other
[10:38] <xnox> apw: yeah, migrated 10 minutes ago. so 1.5h + ~0.5 for britney to notice is a good estimate.
[10:43] <apw> great
=== oooooo_m is now known as oooooo
[13:19] <rtg> smb, pushed 'kvm, vmx: Really fix lazy FPU on nested guest' for bug #1278531
[13:19] <ubot2`> Launchpad bug 1278531 in linux (Ubuntu Trusty) "nested kvm fails with trusty and upstream kernels" [Medium,Fix committed] https://launchpad.net/bugs/1278531
[13:20] <smb> rtg, Thanks, it should sooner or later come via upstream stable, too
[13:20] <rtg> yup, this way though it marks the bug fix released
[13:20] <smb> Right, good thing as this blocked some other testing of Serge
[13:32] <apw> rtg, when we due the next 3.13 you recon?
[13:33] <rtg> apw, we should upload today. you've accumulated a bunch of ppc64el pconfig changes, plus the nested KVM patch
[13:33] <apw> rtg, was trying to judge whether there was a stable "today" indeed for that reason
[13:33] <rtg> apw, I don't think there will be, but I did push that KVM patch in advance of stable
[13:34] <apw> yeah pleased to see that fixed, and in is good
[13:35] <rtg> apw, I'll put a bow on it and do some test building
=== psivaa is now known as psivaa-lunch
[13:36] <apw> rtg, sounds good, thanks
[13:36] <rtg> apw, you and infinity are sure about the 64K system pages patch ?
[13:38] <apw> rtg, i think the moons are aligned there now, and its not like the builders take it without manual intervention
=== edu-afk_ is now known as edamato
=== psivaa-lunch is now known as psivaa
=== JanC_ is now known as JanC
=== edamato is now known as edu-afk
[16:33] <apw> rtg, i haven't been sent an upload announcement for -meta, is that deliberate
[16:33] <rtg> apw, dunno. I added the tracking bug, plus I also received the upload announcement
[16:35] <rtg> apw, over zealous SPAM filtering ?
[16:35] <apw> rtg, it is in LP so ... must be email or something, goodo
[17:04] <henrix> kamal: i have yet another patch for our scripts, this time notify-stable-release
[17:04] <henrix> kamal: could you please take a look here: http://paste.ubuntu.com/7028568/
[17:05] <henrix> (i can send the patch to ktml, but since we're the only living souls using this script...)
[17:05] <kamal> henrix, that looks fine to me too
[17:05] <henrix> kamal: cool, thanks ;)
[17:06]  * henrix admits most of the code was stolen from notify-stable-review ;)
[17:06] <kamal> henrix, I thought it looked awfully familiar!  ;-)
[17:06] <henrix> heh
[17:15] <rtg> apw, Its curious that we don't have EARLY_MICROCODE turned on. I pushed a config patch and am gonna see how I can make it work on a Haswell
[17:22] <trippeh> also needs a initramfs-tools update
[17:22] <trippeh> debian has the needed bits in theirs
[17:22] <rtg> trippeh, thats kind of what I was thinking as well
[17:23] <trippeh> it was fairly easy to backport into to 0.103ubuntu*
[17:23] <apw> rtg, ack
[17:24] <trippeh> I guess initramfs-tools could use a debian sync ;)
[17:26] <rtg> trippeh, not sure if wanna do a complete sync at this point. do you have a patch for your backport  that you mentioned above ?
[17:31] <rtg> trippeh, looks like xnox has already done it '[f59e716] implement early initramfs support (Closes: #712521)'
[17:31] <xnox> trippeh: are you joey? =)
[17:32] <trippeh> rtg: sure.http://tomt.net/temp/early_initramfs.patch
[17:32] <trippeh> ah
[17:32] <trippeh> xnox: Nope.
[17:33] <xnox> trippeh: ok, well a joey pinged me to do this early hours UTC, and it's been in release pocket since ~ 10:30 UTC, but I don't have a machine to test this on (one that would require e.g. intel-mircocodes)
[17:33] <rtg> xnox, working on it... we didn't have the right kernel config enabled either
[17:33] <xnox> trippeh: if you have hardware that needs this support, testing it would be good.
[17:34] <xnox> rtg: whoops. I wonder if I should revert initramfs-tools upload then? cause all initramfs with intel-microcode package installed would then be broken-ish....
[17:34] <trippeh> I've tested the backport I did on a bunch of 13.10 installs
[17:34]  * xnox tries to reboot a generic machine to see if it will boot at all.
[17:34] <xnox> trippeh: with or without kernel config change?
[17:35] <trippeh> Hm. We do run our own kernels. Didnt check the version logic on ubuntu kernels
[17:35]  * xnox reboots.
[17:35] <rtg> xnox, gimme a bit to see what it actually does. I've got a bare metal Haswell that should load microcode.
[17:35] <apw> rtg, i have a synced version of initramfs-tools already, which is pending reviwe at the moment
[17:36] <trippeh> ah, the version logic is in the actual microcde-packages, duh
[17:36] <rtg> apw, can we sync this late in the game ?
[17:36] <apw> rtg, its a merge ... but ... that is up to the reviewer, it was submitted some time ago
[17:37] <rtg> apw, there are quite a few changes since the last sync
[17:37] <xnox> rtg: so, the initramfs with early micro-code is bootable. but my machine doesn't need any, as far as I know.
[17:37] <xnox> rtg: the "traditional / late microcode" would be missing though with todays updates, so if we get kernel in soonish, it should be okish.
[17:37] <apw> rtg, i synced it with before xnox's update and after
[17:37] <apw> (as his changes were already in)
[17:37] <xnox> rtg: well, it's frankenstein, our version number is fake, 103 is not the real base (our version number is fake)
[17:38] <xnox> rtg: and we cherrypicked a lot of changes.
[17:38] <apw> yes its a 0.99 version, i did a proper merge, pullig all out changes into patches in git
[17:38] <xnox> apw: \o/ awesome =) where is it? can I grab it / review it?
[17:38] <apw> xnox, i think infinity is already reviewing it, so it'd be sad to duiplicate effort
[17:40] <apw> and as he was the one who made the 0.99 0.103 hy
[17:40] <apw> hybrid, he likely should review it
[17:42] <xnox> apw: he was also meant to do the merge... instead of sub-contracting it out =)
[17:43] <apw> xnox, heh, well i did a merge some time back which got lost in the noise, so i was in a good position to redo it on the newer base, as i had done 99% of the work in idnetifying the changes
[17:43] <apw> xnox, way back when in +1 days
[17:44] <xnox> ah, lol =)
[17:44] <xnox> apw: i wonder if +1 days will come back between 14.04.0 and 14.04.1 ;-)))
[17:51] <apw> xnox, some hope
=== edu-afk is now known as edamato
[18:22] <rtg> xnox, so how do I get some verbosity during the kernel install to tell if its actually packaging the early ucode in the initrd ?
[18:23] <apw> rtg, can't you unpack the initrd and have a look ?
[18:24] <apw> zcat /boot/initrd | cpio -it
[18:24] <apw> sort of thing?
[18:25] <rtg> apw, all I'm seeing in the initrd is 'scripts/init-premount/intel_microcode'
[18:28] <antarus> '12
[18:28] <antarus> ugh
[18:28] <trippeh> there is a verbose flag to initramfs-tools iirc
[18:28] <trippeh> update-initramfs that is
[18:29] <trippeh> it showed the early stuff going on for me
[18:30] <apw> rtg, perhaps just run update-initramfs -u -v
[18:31] <rtg> yep, that makes a bit more noise
[18:31] <rtg> /usr/sbin/iucode_tool: No valid microcodes were selected, nothing to do...
[18:32] <rtg> so, maybe the haswell doesn't need an update
[18:32]  * rtg needs brain food, back in a bit after lunch.
[18:43] <xnox> rtg: i installed intel-microcode package.
[18:43] <xnox> rtg: then i modify /etc/default/intel-microcode
[18:43] <xnox> rtg: IUCODE_TOOL_INITRAMFS=early
[18:43] <xnox> rtg: IUCODE_TOOL_SCANCPUS=no
[18:44] <xnox> rtg: then it will force include all of them as early microcode.
[18:44] <xnox> rtg: initramfs will be "interesting"
[18:44] <xnox> $ file /boot/initrd.img-3.13.0-13-generic
[18:44] <xnox> /boot/initrd.img-3.13.0-13-generic: ASCII cpio archive (SVR4 with no CRC)
[18:45] <xnox> rtg: $ cd `mktemp -d`;  cpio -ivd < /boot/initrd.img-3.13.0-13-generic 
[18:45] <xnox> kernel
[18:45] <xnox> kernel/x86
[18:45] <xnox> kernel/x86/microcode
[18:45] <xnox> kernel/x86/microcode/GenuineIntel.bin
[18:45] <xnox> 862 blocks
[18:59] <rtg> xnox, well, it at least hasn't broken anything. I'll try to find a CPU that actually needs an update.
=== snadge_ is now known as snadge
[23:34] <Prf_Jakob> So I'm about to send a very large patch to the ml with the vmwgfx hardware enabelment code, how do you guys want it? As a 256kb mail or as gz attachment?