[11:29] <Kano> hi, do you want to build a 3.14 kernel soon?
[11:30] <infinity> Kano: Like this one? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/
[11:30] <Kano> well with aufs
[11:30] <Kano> not mainline
[11:31] <infinity> Then you want http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=shortlog;h=refs/heads/unstable
[11:31] <Kano> i know, but its not tagged
[11:31] <Kano> i currently build that
[11:32] <Kano> i already updated ndiswrapper, fglrx, nvidia with rc8, the patches are simple, ndiswrapper you can get from debian
[12:30] <smb> apw, So my ppa now contains the updated xen package. I think I will have to change the binary package that I use to add the grub config from utils-common to hypervisor since that at least triggers an update-grub run.
[13:09] <apw> smb, sounds good, do you want me to test that or wait on this binary package move?
[13:14] <smb> apw, Hm, maybe its better to wait for the move. 
[13:19] <apw> smb, ack
[14:05] <smoser> anyone interested in looking at this:
[14:05] <smoser> http://paste.ubuntu.com/7184918/
[14:05] <smoser> should i file a bug? 
[14:06] <smoser> note the old kernel version
[14:10] <rtg> smoser, wow, thats pretty old. can you repro it with the current kernel ?
[14:10] <smoser> rtg, this is the only time i've ever seen that.
[14:10] <smoser> so, probably not.
[14:11] <smoser> but that doesn't mean anything :)
[14:11] <rtg> well, probably not much we can do about it.
[14:11] <smoser> mainly i just posted to see if it showed an obvious error.
[14:11] <rtg> its not one I recognize
[15:07] <apw> rtg, have pushed an update to master-next
[15:09] <rtg> apw, ack
[15:11] <smb> apw, Ok, ppa now has the more recent test version of xen
[15:11] <apw> smb, thanks
[15:11] <apw> smb, what do i undo in my setup to be "normal" for it to work
[15:11] <apw> smb, as i currently have it mangled to make it use xen right ?
[15:12] <smb> apw, If you have set some GRUB_DEFAULT != 0 and not booted manually into xen you could set that back to 0
[15:12] <apw> smb, yeah that ...
[15:15] <smb> apw, Bah, of course right after saying that, there is a "bug" in the message... its /etc/default/grub.d/xen.cfg to look into
[15:50] <rtg> apw, pushed AA sync
[15:52] <apw> rtg, ack
[15:54] <rtg> apw, I'm gonna jigger HEAD to add a bug number (bug #1298611)
[15:54] <ubot2> Launchpad bug 1298611 in libvirt (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,Triaged] https://launchpad.net/bugs/1298611
[15:54] <apw> smb, those see to work mostly as i would expect thanks, modulo that error you self spotted
[15:54] <apw> rtg, ack
[15:55] <jdstrand> apw, rtg: did the release team ack it?
[15:55] <rtg> jdstrand, they don't get to ack kernel patches
[15:55] <smb> apw, Cool, I already updated the local source to keep me forgetting
[15:55] <smb> from
[15:55] <jdstrand> rtg: not even for feature?
[15:55] <jdstrand> cause, infinity seemed to indicate they would
[15:56] <rtg> jdstrand, besides, kernel freeze is not until Apr 3
[15:56] <jdstrand> (and I've kept infinity in the loop all along)
[15:56] <jdstrand> well, I don't mean to disrupt the process. just trying to do it by the book :)
[15:56] <rtg> jdstrand, according to jjohansen these patches should be backward compatible with Precise user space.
[15:56] <jdstrand> they are
[15:57] <rtg> ok, then I'm fine with them
[15:57] <jdstrand> extensive testing was performed by him and me for that configuration (and others). this is detailed in the bug
[15:57] <jdstrand> wfm
[15:57] <rtg> jdstrand, yup, I had a pretty good conversation with him about it last friday
[15:59] <jdstrand> ack. the testing continued over the weekend with the code in the pull request
[16:02] <apw> rtg, i think the only thing we care is if they are going to reject the whole feature us carrying the patches makes no sense
[16:03] <rtg> apw, perhaps, but it does keep us closer to upstream, and should be benign for Precise user space.
[16:06] <rtg> dannf, have you booted 3.13.0-20.42 on an x-gene SOC ?
[16:06] <dannf> rtg: we booted the first -20, dont' remember the version
[16:06] <rtg> I made a bunch of config changes, some of which may have affected arm64
[16:07] <rtg> dannf, -20.41 should have been sufficient. -20.42 was just packaging
[16:07] <dannf> rtg: ok. i'll double check just to be sure
[16:08] <rtg> dannf, thanks
[16:08] <rtg> ppisati, you should do the same for your Trusy armhf platforms
[16:09]  * ppisati reads the backlog
[16:09] <rtg> ppisati, just make sure the latest Trusty kernel works
[16:10] <ppisati> rtg: i'll do
[16:10] <apw> rtg, aa> fair enough i guess, as we should have the older support still and the kernel bits should understand the lack of userspace features
[16:11] <apw> rtg, pushed a could of "shhhh" patches
[16:11] <ppisati> rtg: doing another upload before freeze?
[16:11] <rtg> ppisati, yup
[16:12] <ppisati> rtg: i would like to squeeze a ptch in, if i can make upstream ack a problem i'm seeing
[16:12] <rtg> apw, where did your "shhhh" patches go ?
[16:12] <ppisati> rtg: ping me before the deadline
[16:12] <apw> rtg, look to be there for me
[16:12] <rtg> ppisati, wednesday is the last possible 
[16:12] <rtg> day
[16:12] <ppisati> rtg: ack
[16:13] <rtg> apw, must have been a race. got 'em now
[16:18] <rtg> apw, I'm wondering if we shouldn't set CONFIG_ZSWAP=n ? Especially for an LTS kernel. This feature is still considered experimental by upstream.
[16:20] <rtg> perhaps turn it back on for 14.10
[16:21] <apw> rtg, as long as that isn't the one we use for low memory systems in the installer
[16:21] <apw> rtg, which i think is ZRAM
[16:21] <apw> rtg, so the other question is when is it used, always if it is on, on
[16:21] <apw> or does one have to trigger its use somehow
[16:22] <rtg> apw, ZSWAP always on as far as I can tell
[16:22] <rtg> is always*
[16:25] <apw> rtg, hurm, difficult given we ave been using it such a lot then, but i can see turning it off ought to be safer
[16:25] <rtg> apw, well, we do have a lot of bug reports about suspend/resume, and a number of other random page faults. seems like a possiblity (though I have _no_ hard information).
[16:26] <apw> rtg, then wack it
[16:26] <rtg> just going by the help text for the feature....
[16:37]  * ppisati starts another kernel compilation and goes for a walk...
[17:40] <vlad_starkov> QUESTION: Is it possible to disable udev on boot? (Ubuntu 14.04 Server 64bit)
[17:41]  * antarus blinks
[17:41] <antarus> in Ubuntu? why would you want to do that?
[17:42] <vlad_starkov> antarus: My system does not boot even with Live USB. It hangs with CPU soft lockup errors
[17:42] <vlad_starkov> antarus: I think the cause of this is in kernel modules load sequence 
[17:45] <antarus> hrm interesting
[17:46] <vlad_starkov> antarus: if you like I can pastebin console logs at boot
[17:47] <antarus> sorry, I probably can't help you
[17:47]  * antarus mostly lurks here
[17:49] <vlad_starkov> antarus: OK
[17:50] <antarus> I was mostly curious why you wanted udev off. The best idea I can think of is to somehow guess which module is causing hte problem and blacklist it somehow?
[17:50] <antarus> not sure what the kernel command line arugments are for that
[17:51] <vlad_starkov> antarus: this is whta I'm trying to do
[17:52] <TJ-> vlad_starkov: I'm with you here, too
[17:52] <vlad_starkov> TJ-: Oh nice
[17:53] <vlad_starkov> TJ-: so, I think this is the last attempt to deal with my server
[17:53] <vlad_starkov> TJ-: for now I disabled SATA and PATA. Trying to boot from USB. The same result :)
[17:53] <TJ-> vlad_starkov: Did you get the memoserv note I left you Friday night?
[17:54] <vlad_starkov> TJ-: Mmm I think I'm not
[17:54] <TJ-> vlad_starkov: Check... I suspect it'll address issue
[17:54] <vlad_starkov> TJ-: never did it before, could you guide me how to check memo
[17:55] <TJ-> vlad_starkov: "/msg memoserv help"
[17:55] <TJ-> vlad_starkov: The gist was, kernel option "elevator=deadline" ought to fix it
[17:56] <vlad_starkov> elevator=deadline
[17:56] <vlad_starkov> yep, just read it in memos)
[17:56] <vlad_starkov> TJ-: let me try
[17:56] <TJ-> vlad_starkov: I had to think hard to remember it!
[17:56] <TJ-> vlad_starkov: Shall we switch back to #ubuntu-server, to avoid messing up the kernel team's history ?
[17:57] <vlad_starkov> TJ-: sure!
[18:55] <dannf> rtg: oh yeah, works fine
[18:56] <rtg> dannf, cool
[19:51] <infinity> BenC: So, unless we get that kernel in today, I think you missed this SRU cycle. :P
[22:30] <rtg> sforshee, please have a look at bug #1300416 when you get a chance
[22:30] <ubot2> Launchpad bug 1300416 in linux (Ubuntu) "Install of 14.04 fails with 3.13.0-20-generic kernel" [High,Confirmed] https://launchpad.net/bugs/1300416
[22:31] <rtg> brcmsmac is involved
[23:05] <darklight_> the latest kernel kinda broke the intel driver
[23:05] <darklight_> multiple applications fail with  ../../../../../../../src/mesa/drivers/dri/i965/brw_reset.c:43: brw_get_graphics_reset_status: Assertion `brw->hw_ctx != ((void *)0)' failed.
[23:05] <darklight_> happens with i915 too
[23:05] <darklight_> I'm talking about 14.04
[23:16] <RAOF> darklight_: What mesa are you running against?
[23:17] <darklight_> RAOF: 10.1.0-1 stock 14.04 atm
[23:18] <darklight_> I've seen a bug report for kwin online and here I have another application failing related to node-webkit
[23:18] <RAOF> Huh. I thought that bug was introduced in a more recent mesa.
[23:18] <RAOF> I've seen tjaalton talking about that with upstream.
[23:18]  * RAOF sends out the Bat Signal
[23:19] <darklight_> I tried with 3.19 and at least for my testcase things work fine
[23:19] <darklight_> 3.20 breaks it
[23:19] <darklight_> for reference it's the popcorn-app, it's not in the repository, but I think anything related to node-webkit should show the same isse
[23:21] <darklight_> RAOF: I'm off to bed, if you need me to test something /msg me 
[23:22] <RAOF> Ta.
[23:22] <RAOF> Sleep wel!
[23:22] <darklight_> thanks! hopefuly you'll fix this soon :)