=== fish__ is now known as fish_
=== yofel_ is now known as yofel
=== henrix_ is now known as henrix
[06:59] <rsalveti> apw: let me know once the meta packages are available in the ppa, so we can try to land them today in the archive
[09:19] <apw> rsalveti, sorry been having fallout from any upgrade this morning, will be soon
[09:44] <apw> rsalveti, ok they are all building or pending publication now
[11:41] <snadge> whats the easiest way to try out the latest kernel/radeon driver in saucy? .. oibaf? edgers?
[11:49] <apw> snadge, i would guess edgers, but #ubuntu-x might have better info
[13:26] <jdstrand> so, I've noticed for a little while that if I have VMs running and then I suspend my machine, when I come out of suspend, sometimes they are unresponsive and qemu is pegging the cpu
[13:26] <jdstrand> so I decided to look in kern.log this morning, and see: http://paste.ubuntu.com/7010323/
[13:27] <jdstrand> what's interesting to me is that I suspending at Feb 27 21:36:08 and resumed at Feb 28 07:16:05
[13:28] <jdstrand> I don't know how the ordering is supposed to all go, but it seems like all the 'kvm: disabling virtualization on CPU1' is happening way too late (as in, after I resume)
[13:28] <jdstrand> maybe that is just when it hits syslog
[13:29] <apw> the date on the left is a lie, that is "stopped" when syslog is frozed in the freezeing ling
[13:29]  * jdstrand tries to remember the format of the kernel timestamp
[13:29] <apw> seconds and microseconds since boot
[13:29] <apw> or nanoseconds or something
[13:30] <apw> Feb 28 07:16:05 localhost kernel: [260761.679027] ACPI: Low-level resume complete
[13:30] <apw> i think that is the first thing it says on the way up, everything before that is before it went down, but cking is more is an expert on those msgs
[13:31] <apw> jdstrand, are these 64 or 32 bit guests ?
[13:31] <jdstrand> it was a 64 bit bit guest last night
[13:31] <apw> not smb's bug then.  well, i think its time to file a bug, and we'll get smb et al too poke at it
[13:32] <cking> apw, yep the timestamp is a lie at that poinmt
[13:32] <jdstrand> I've seen it with more than this guest, but I'm not sure if I've only ever seen it with 64 bit
[13:32] <jdstrand> ok, that makes sense then
[13:34] <jdstrand> I don't see anything particularly wrong from a kernel perspective looking at the kern.log if I consider 'ACPI: Low-level resume complete' as the place to split
[13:36] <jdstrand> except perhaps the CPU0 is never actually listed as having kvm disabled or enabled
[13:36] <jdstrand> but I'm not convinced that is wrong
[13:37] <jdstrand> ok thanks. I'll be testing hallyn's new qemu at some point soon, so I'll just put this on the backburner
=== arges_ is now known as arges
[14:04] <rsalveti> apw: thanks!
[14:05] <apw> jdstrand, ok if its there, bug us up please
[14:05] <apw> rsalveti, let me know if they are any good
[14:05] <rsalveti> sure
[14:06] <_bjf> arges, bug 1270237
[14:06] <ubot2`> Launchpad bug 1270237 in linux (Ubuntu Quantal) "prevent the conntrack table from filling up in the kernel" [Medium,Fix committed] https://launchpad.net/bugs/1270237
=== _bjf is now known as bjf
[14:06] <bjf> arges, you think we can set this to verified?
[14:07] <arges> bjf: so far the user that's tested it hasn't hit the problem, but its one of those 'run for a long time and try not to hit it' problems
[14:08] <bjf> arges, right. but we have to decide if we are going to revert or not at some point and now would be a good point :-)
[14:09] <lamont> why does trusty's grub-probe say: grub-probe: error: unknown filesystem.
[14:10] <apw> lamont, any idea which one it is whining about ?
[14:12] <lamont> there are several options
[14:12] <lamont> which is to say, no.
[14:12] <lamont> trusty upgrade threw a fit when memtest86+ and the kernel postinsts failed as a result.
[14:13] <lamont> and then the reboot led to a kernel panic (no root fs, iirc - didn't look much), so I'm running trust on a 3.11 kernel atm
[14:13] <lamont> apw: I don't mind the unknown filesystem as much as I mind the exit(1)
[14:20]  * lamont gives the reboot the ol' college try
[14:21] <lamont> apw: hints on where I might add a --verbose to have grub-probe be more forthright?
[14:26]  * lamont throws strace -ff at the problem
[14:28] <lamont> apw: it's complaining about /dev/mapper/sda5_crypt ...
[14:28] <lamont> which, yes, it shouldn't like so much
[14:30] <lamont> because it's an lvm pv
[14:52] <apw> hurumph, i suppose this is related to the grub2 update
[14:53] <apw> cjwatson, ^^ have yu seen any reports of grub getting whiney about encrypted drives ?
[14:54]  * lamont really tries the reboot thing.  brb hopefully
[15:01] <lamont> apw: after manually moving grub.cfg.new -> grub.cfg, life is happier and I'm running a trusty kernel
=== vmesons is now known as vmeson
[15:23] <apw> lamont, well that is something at least
[15:27]  * lamont generates a strace -ff update-grub stream
[15:33] <lamont> apw: who should I be pestering to look at chinstrap:~lamont/update.strace?  (is grub2 kernel, or foundation?)
[15:35] <ogra> apw, bug 1286184
[15:35] <ubot2`> Launchpad bug 1286184 in linux-flo (Ubuntu) "udev ACLs for sound devices can not be set" [Undecided,New] https://launchpad.net/bugs/1286184
[15:35] <ogra> apw, seems it doesnt happen on mako 
[15:35] <ogra> checking manta now 
[15:35] <ogra> but it smells like this is flo specific 
[15:38] <ogra> yup it is ... verified on manta 
[15:55] <apw> ogra, ack
[15:55] <apw> rsalveti, do you want to copy out the current flo before i upload, or shall i replace it
[15:56] <rsalveti> apw: just replace it, I'm publishing the other packages in a CI silo (as we need to rebuild the android package as well)
[15:56] <rsalveti> so don't worry, I'll get  them in the archive via a CI silo
[16:00] <apw> rsalveti, so yo have taken them "elsewhere" ok
[16:00] <rsalveti> apw: yeah
[16:01] <ogra> yeah, so we are able to fish them out of the conatiner at least
[16:01] <ogra> still better than having to download the package 
[16:04] <rsalveti> yeah
[16:04] <rsalveti> apw: just ping me once the new flo kernel is available in the ppa
[16:06] <apw> rsalveti, ack
=== kamal__ is now known as kamal
[16:16] <hallyn> hi - i keep getting lockups which i was blaming on unity, but now am wondering whether it's kernel.
[16:16] <hallyn> http://paste.ubuntu.com/7011147/  does this mean anything to anyone?
[16:25] <apw> hallyn, not sure i know of them specifally, but it sounds like bad commands in the gpu pipeline, of course that could be mesa
[16:26] <hallyn> ok - yeah i couldn't tell if nouvou was misbehaving, or was getting a bad command.
[16:26] <hallyn> was wondering whether it is the same as https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1282342, or a kernel cause for it
[16:26] <ubot2`> Launchpad bug 1284536 in compiz (Ubuntu) "duplicate for #1282342 compiz crashed with SIGSEGV in two_way_long_needle()" [High,Confirmed]
[16:27] <hallyn> but no i guess it is unrelated.  sigh.
[16:27] <apw> i would bring this up on #ubuntu-x someone might recognise it
[16:28] <hallyn> heh, i try to avoid that chan, but ok will do :)  thanks
[16:30] <sforshee> ogasawara, apw, bjf: do we have anyone going through these fedora kernel patch report emails and seeing if there's anything we should consider picking up?
[16:31] <sforshee> e.g. https://lkml.org/lkml/2014/2/28/302
[16:32] <bjf> sforshee, i'm sure kamal will be happy to look at those :-)
[16:34] <sforshee> bjf: I noticed that the most recent one is patches on 3.13, which seems it would definitely be of interest
[16:36] <bjf> sforshee, yeah, so someone from the dev kernel team should be looking at those. your on that team aren't you? :_)
[16:36] <apw> sforshee, yeah that looks interestnig indeed, if you arn't looking :)  then i can on monday or s
[16:36] <apw> so
[16:36] <sforshee> bjf: I am, I just didn't want to duplicate effort if someone else is already doing it
[16:37] <henrix> sforshee: i usually look at those in my usual review of stable patches, but this one may be of particular interest for T
[16:38] <apw> sforshee, then ... we have a plan :)  thanks
[16:38] <henrix> most of the time these are patches that hit the stable trees anyway, so... :)
[16:38] <kamal> bjf, sforshee, henrix: I'm not convinced that all of those (or perhaps any of those) are suitable for stable
[16:38] <henrix> kamal: well, yeah... i just saw there was an email, i didn't look at the patches
[16:38] <bjf> kamal, and i'm ok with that evaluation
[16:40] <kamal> bjf, sforshee, apw:  ok,henrix and I will look through them and compare notes
[17:05] <ppisati> hey
=== kgunn is now known as Guest30100
=== ogasawara is now known as Guest32383
[18:27] <arges> hallyn: hey i'm looking at bug 1278531. there is a patch that fixes 3.13, but are you still seeing issues with a 3.11 kernel?
[18:27] <ubot2`> Launchpad bug 1278531 in linux (Ubuntu) "nested kvm fails with trusty and upstream kernels" [Medium,Confirmed] https://launchpad.net/bugs/1278531
[18:28] <hallyn> arges: 3.11 has a idfferent bug,
[18:31] <hallyn> at least for me.  for some ppl it works fine
[18:31] <hallyn> for me, kvm jsut hangs with 100% cpu
[18:40] <arges> hallyn: ok is that tracked in a different bug or same one?
[18:40] <hallyn> arges: iirc that bug originally was for that failure
[18:41] <hallyn> we re-used it as i assumed at first it was the same.  but smb found that the 3.11 bug was probably fixed somewhere between 3.11 and 3.13
[18:44] <arges> hallyn: ahh here's the other bug 1208455 to track it
[18:44] <ubot2`> Launchpad bug 1208455 in linux (Ubuntu Saucy) "general protection fault running apt-get inside double nested kvm VM" [High,In progress] https://launchpad.net/bugs/1208455
[18:45] <hallyn> that one gets more convoluted :)
[18:46] <hallyn> arges: what exactliy are you trying to nail down?
[18:46] <hallyn> you're having a failure on saucy?
[18:46] <arges> hallyn: just want to make sure 3.11 work as well
[18:46] <hallyn> ok.  yeah, i'm kinda letting 3.11 suffer until trusty is golden
[18:50] <sconklin> #rake
=== ogasawara_ is now known as ogasawara
[19:54] <apw> rsalveti, ok uploaded flo, should be about an hour all things being equal
[19:54] <rsalveti> apw: awesome, thanks!
[23:59] <cetex> ACPI. Is it polling-based or event based? or a combination?