[09:13]  * apw yawns
[09:31] <xnox> apw: cking: do you by any chance know how to setup  Qemu + NVMe + OVMF vm for testing?
[09:32] <cking> xnox, no idea about emulating NVMe in Qemu
[09:32] <xnox> somebody in 2013-02-25 was installing testing it like that.
[09:32] <xnox> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1132681
[09:32] <ubot2> Launchpad bug 1132681 in ubiquity (Ubuntu) "U 12.10 LiveCD installer crashing during boot loader configuration on NVMe storage( QEMU + NVMe +OVMF )" [Undecided,New]
[09:33] <xnox> cking: otherwise i can propose some patches for you to try.
[09:33] <cking> xnox, that's a better plan, I can give them a spin on the H/W I have
[09:34] <xnox> cking: cool.
[09:45] <apw> xnox, not ever done that here eitehr
[09:46] <xnox> rbasak: what do you say on upgrading libvirt to 1.2 release?
[09:51] <cking> last time I tried QEMU was with OVMF I built from scratch from the tianocore sources
[09:52] <apw> if you read the description of this Qemu bug, it blows chunks in grub.  didn't you have a similar issue cking?
[09:53] <cking> apw, yup, bug 1265483
[09:53] <ubot2> Launchpad bug 1265483 in grub-installer (Ubuntu Trusty) "Installer crashed when installing to an Intel NVMe SSD" [High,New] https://launchpad.net/bugs/1265483
[09:54] <cking> apw, also my firmware can't boot off this device either, so that's another issue I face
[09:54] <apw> cking, i am somewhat expecting the next bug from this person to be that
[09:55] <apw> given they are using ovmf, it may only just have support for them much as your box does
[09:55] <cking> xnox, http://smackerelofopinion.blogspot.co.uk/2011/10/uefi-edk-ii-revised.html,  although I guess the notes may be old now
[09:56] <cking> bah, the links are stake
[09:56] <cking> *stale
[09:56] <apw> 'stale' i thought those were 'pementant' links
[09:56] <cking> https://wiki.ubuntu.com/UEFI/EDK2
[09:57] <cking> apw, somebody kindly redirected them
[09:57] <apw> xnox, ckings bug above also talks about grub failing during grub-install onto this type of device died
[09:57] <apw> (as does this new bug)
[09:57] <xnox> cking: well OVMF is packaged and it's simply -bios /usr/share/ovmf/OVMF.fd.
[09:57] <cking> xnox, that's way too easy ;-)
[09:58] <xnox> apw: sure. quite similar to the most recent patch to enable FusioIO devices.
[10:00] <xnox> cking: so you could try http://paste.ubuntu.com/6683593/   but that one assumes that /dev/nmve0n1 is device name and /dev/nmve0n1pX are partitions of thereof. But that's me guessing =/ ideally there would be some more precise way to know how nmve devices and partitions are numbered.
[10:00] <xnox> cking: in the mean time, i'll try to make this qemu-system to give me a nmve device.
[10:01] <cking> xnox, if you can figure out how to do that, then please let me know
[10:01] <xnox> cking: of course =)
[10:13] <xnox> cking: well, i booted something which does have nvme devices, they are numbered differently from what your device was however.
[10:13] <xnox> cking: qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -m 1024 -cdrom /var/cache/utah/iso/ubuntu/trusty-desktop-amd64.iso -drive file=nvme.img,if=none,id=D22 -device nvme,drive=D22,serial=1234 --enable-kvm
[10:14] <xnox> adjust memory, path to .iso, path to a device-drive image "nvme.img", no clue about the nvme parameters i copied them from blogger.
[10:14] <cking> xnox, that patch make grub install correctly
[10:14] <xnox> that does boot in EFI mode.
[10:14] <xnox> cking: \o/ excellent. Does it boot?
[10:14] <xnox> cking: cause grub2 might need patches to actually recognise the device =/ if that is the case it would be passing the ping-pong to cjwatson.
[10:15] <cking> xnox, I can't boot it 'cos the  firmware does not support that device
[10:15] <cking> i.e. it can't find it, I need newer firmware I believe
[10:17] <xnox> cking: people on the forums patch stock motherboard firmwares with updated drivers all the time. E.g. i got "unofficial" firmware for my motherboard with updated intel drivers et.al. =) granted it may have come with extra NSA modules =) i got it off the forum post attachment over http ;-)
[10:18] <xnox> cking: so what do you want me to do? upload that patch into archive & respin ubiquity such that at least you will have daily desktop/server images tomorrow with it?
[10:19] <xnox> cking: and do we need this for 12.04.4?
[10:19] <cking> xnox, gimme a sec, I will just boot the box up from another image and see if the nvme grub  looks sane
[10:21] <cking> xnox, it looks sane to me, so lets update it for the daily images
[10:21] <apw> xnox, have we asked the OR for their qemu command line etc, ask them when you ask them to test tommorows images
[10:21] <xnox> apw: >~cking ?
[10:22] <cking> apw, that makes sense
[10:22] <xnox> apw: i don't think i get to them at all. slangasek simply asked me to look into cking's bug report.
[10:22] <xnox> to talk that is.
[10:24] <xnox> cking: apw: https://bugs.launchpad.net/bugs/+bugs?field.searchtext=NVMe&search=Search+Bug+Reports&field.scope=all&field.scope.target= gives nice output, at least to me =)
[10:25] <cking> xnox, well, I'm OK with the fix, it installs grub correctly, I just need to talk to intel to get my firmware sorted to try a boot test
[10:26] <cking> so pop it in to the archive and respin is good for me.  any objections apw?
[10:26] <xnox>    * Handle NVMe devices, based on the debug logs from Colin
[10:26] <xnox>      King. Preliminary support (LP: #1265483)
[10:26] <ubot2> Launchpad bug 1265483 in grub-installer (Ubuntu Trusty) "Installer crashed when installing to an Intel NVMe SSD" [High,New] https://launchpad.net/bugs/1265483
[10:27] <xnox> sounds good? as in conveying that it's not fully tested yet?!
[10:28] <cking> yep
[10:29] <cking> it may be a while before I can properly test this, I need to chat to various bods in intel
[10:58] <apw> cking, shove it in ;)
[10:58] <cking> +1
[10:58] <rbasak> xnox: zul and hallyn look after libvirt usually. zul uploaded 1.2.0-0ubuntu1 yesterday.
[10:59] <xnox> rbasak: excellent. didn't notice.
[11:01] <cking> thanks xnox
[13:18] <rtg> cking, just going back through my pre-holiday emails. For Trusty unstable (v3.13) I have set CONFIG_X86_INTEL_PSTATE=y. Is that OK without the thermal daemon ?
[13:20] <cking> rtg, well, yes and no
[13:33] <infinity> Is INTEL_PSTATE still a laughing stock of fan-spinning hilarity?
[13:33] <infinity> It's been shit for so many releases, I'll be amazed if it's finally fixed.
[14:05] <rtg> apw, still working on getting lttng to compile on all arches for unstable. seems it doesn't like gcc 4.8 on armhf
[14:06] <apw> rtg, ack, i had noted it was off
[14:14] <eagles0513875> hey apw
[14:24] <apw> hi
[14:39] <eagles0513875> apw: still no response on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/967399 :( im not sure what to do in terms of getting it upstreamed 
[14:39] <ubot2> Launchpad bug 967399 in linux (Ubuntu) "[11.10] Elantech trackpoint does not work Lenovo " [High,In progress]
[14:41] <Kano> hi, has somebody a patch for nvidia + 3.13?
[14:49] <tseliot> Kano: it's in 14.04
[14:49] <Kano> tseliot: i dont see it in the changelog
[14:49] <tseliot> let me check
[14:52] <tseliot> Kano: ok, maybe I confused it with 3.11 and 3.12. Do you have a dkms log for nvidia showing the failure?
[14:53] <Kano> tseliot: it builds,but i get: nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
[14:56] <tseliot> Kano: apparently they removed a symbol. I'll work around that next week
[14:58] <Kano> tseliot: well the patch in the nv forum seems to use >= instead of <
[15:11] <apw> tseliot, does that imply that the nvidia dkms is not working with 3.13 ?
[15:12] <tseliot> apw: I guess so, I haven't checked
[15:12] <tseliot> https://devtalk.nvidia.com/default/topic/644906/331-20-on-3-13-rc1-kernel/
[15:14] <apw> tseliot, ok sounds like there are a couple of issues, but sounds like you are on the case
[15:16] <tseliot> apw: yes, whatever that is, I'll fix it. BTW where are we going to get 3.13 in 14.04?
[15:16] <apw> well ... "now" if the dkms packages we care about arn't borked
[15:17] <apw> i suspect "early next week" is most likely now
[15:18] <rtg> I'm thinking Monday
[15:19] <tseliot> I'll probably fix my packages next week
[16:12] <rtg> apw, did a practice rebase on unstable against current Linus tip and had aufs3 conflict. I resolved by dropping the conflicting chunk (i.e. the code the patch wanted to add), but could use a second set of eyeballs. perhaps you could take a quick pass at rebasing as well?
[16:16] <rtg> tseliot, fglrx isn't installing. you should get that on your todo list as well.
[16:16] <rtg> Setting up fglrx (2:13.101-0ubuntu5) ...
[16:16] <rtg> update-alternatives: using /usr/lib/fglrx/ld.so.conf to provide /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf (x86_64-linux-gnu_gl_conf) in auto mode
[16:16] <rtg> update-alternatives: error: error creating symbolic link `/usr/lib/x86_64-linux-gnu/xorg/extra-modules.dpkg-tmp': No such file or directory
[16:16] <rtg> dpkg: error processing fglrx (--configure):
[16:17] <tseliot> rtg: that's what I meant when I said that I would fix my packages ;)
[16:18] <apw> rtg,  will do
[16:30] <apw> rtg, so its not a "just drop that hunk job"
[16:30] <rtg> apw, ok. looks like upstream changed some macros though.
[16:33] <apw> rtg, this is aufs3 introducing a macro intersecting with upstream adding the 'get flags first' to avoid a use-after-free
[16:33] <apw> i'll build test my merge and see
[16:34] <rtg> apw, cool. I figured you would be able to spot it right away having done this before
[16:54] <apw> rtg, seems to work, i guess it makes sense for me to push this rebase so we don't have to do it again
[16:54] <rtg> apw, ack, thanks
[16:54] <apw> rtg, done
[16:54] <rtg> apw, I was thinking about uploading to the PPA so I could get some mileage on the IMA stuff
[16:55] <apw> i assume we'll get an -rc7 like tommorrow ?
[16:55] <Kano> i fixed the nvidia binary,but you should update the firmware package for 3.13 as well as files like /lib/firmware/radeon/HAWAII_pfp.bin are missing
[16:55] <rtg> apw, likely, but I'll be off skiing
[16:59] <Kano> maybe radeon dpm could be activated by default
[17:03] <apw> radeon dpm ?  
[17:03] <apw> nvidia binary> patch?
[17:04] <Kano> apw: http://kanotix.com/files/fix/nvidia.wheezy/update/nvidia-graphics-drivers-331.20-2kanotix1/nvidia-graphics-drivers_331.20-2kanotix1.debian.tar.gz
[17:04] <Kano> look into debian/patches
[17:06] <rtg> it is tseliot that needs that info
[17:06] <Kano> and if somebody from X is looking, why dont you add libvdpau-dev for mesa
[17:06] <Kano> and package the vdpau /xvmc things
[17:07] <tseliot> these are questions you might want to ask in #ubuntu-x
[17:07] <Kano> well i dont use mesa from ubuntu, just as hint
[17:07] <tseliot>  radeon dpm should be on by default in 3.14
[17:08] <Kano> well why not with 3.13
[17:08] <tseliot> additional fixes in 3.14, I guess
[17:08] <Kano> i used it with 3.12 too
[17:10] <tseliot> well, I use it here with 3.11
[17:55] <kees> cking: so... your memory benchmark of IMA was for IMA built in, but not enabled?
[17:55] <cking> kees, I compared it with it build in and enabled vs not enabled with some simple instrumentation
[17:57] <kees> cking: the report in the bug was for which situation?
[17:57] <cking> built in and enabled
[17:57] <kees> I'm curious if just the CONFIG_IMA built in (but not enabled with policy) incurs a cost?
[17:57] <cking> with it built in and not enabled we see an atomic_t per inode
[17:57] <cking> extra
[17:58] <kees> ah, so the math following that was not the result of just the atomic_t?
[17:59] <kees> if it's just 8 bytes per inode when disabled, that seems like a reasonable cost to add CONFIG_IMA
[17:59] <cking> kees, yep, with it enabled there are some 72 byte slab allocations and misc meta data which again isn't too large 
[17:59] <cking> per file
[18:00] <kees> cool. what's needed to enable it? (i.e. and how can we check if a system has it enabled or disabled?)
[18:00]  * cking rummages around for a suitable quickstart guide..
[18:01] <kees> I just want to make sure we don't regress -- CONFIG_IMA caused soooo much trouble for big file servers. :P
[18:01] <cking> kees, http://sourceforge.net/p/linux-ima/wiki/Home/
[18:02] <cking> ^ i think that's more reasonable source of info rather than me regurgitating it all 
[18:02] <kees> cking: sounds good.
[18:03] <kees> cking: thanks for doing all this!
[18:04] <cking> no probs, thank apw for asking me to look into it ;-)
[18:06] <kees> hehe
[18:11] <eagles0513875> apw: are you around?
[18:24] <antarus> kees: cking thanks for that ;)
[18:31] <mjg59> Now if you could just sign all userspace binaries, that'd be great
[18:32] <antarus> mjg59: haha
[18:34]  * rtg -> lunch
[18:52] <antarus> cking: is there a link to the commit enabling IMA?
[18:52]  * antarus isn't finding it on the lp bug
[18:54] <cking> antarus, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=72bb20892cddc00b0d47d987f929017390fa39c9
[20:10] <antarus> hrm
[20:10] <antarus> launchpad continues to elude me
[20:10] <antarus> How do I made it clear on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244627 that I would like the change also in Saucy?
[20:10] <ubot2> Launchpad bug 1244627 in linux (Ubuntu Trusty) "Please enable CONFIG_IMA in the ubuntu kernel" [Medium,Fix committed]
[20:10] <antarus> whenever I futz with the Affects stuff, it won't let me add another copy of 'linux' and I can't find a linux (Ubuntu Saucy) package..
[20:24] <sbeattie> antarus: nominate for series, then mark saucy
[20:29] <antarus> sbeattie: don't I have to be on a specific team to nominate for a series?
[20:30] <sbeattie> to nominate, no, to accept the nomination, yes
[20:42] <antarus> it appears apw did the needful for me
[20:42] <antarus> apw: thanks ;)
[21:07]  * rtg -> EOD
[21:23] <antarus> downloading the kernel debug syms
[21:23] <antarus> huge mistake
[21:23] <antarus> heh