=== [home-bjf] is now known as bjf
[01:39] <bjf> plars, i'm fine with the btrfs failure
=== gerald is now known as Guest66789
=== fmasi is now known as Guest13772
=== cmagina_ is now known as cmagina
=== xnox_ is now known as xnox
=== lag is now known as Guest67837
=== fmasi is now known as Guest63667
[07:02] <ppisati> moin
=== mwhudson is now known as zz_mwhudson
[08:56] <apw> moin
[08:59] <smb> true
=== lan3y is now known as Laney
=== Laney is now known as Guest89008
[09:01] <apw> (moin_p) ?
=== Guest89008 is now known as Laney
=== zz_mwhudson is now known as mwhudson
[09:06] <smb> apw, null pointer dereference ... mornings are pointless ... mwhuah
[09:34] <apw> smb, hehe ... i thought you were talkling lisp at me ..
[09:38] <smb> apw, not really. the only fact about lisp I know for sure is that one has to embrace many braces
[09:56] <apw> perhaps enbrace to be fuly lisp
=== kloeri_ is now known as kloeri
=== mwhudson is now known as zz_mwhudson
=== rbasak_ is now known as rbasak
=== ikonia_ is now known as ikonia
[11:54] <zequence_> apw: I've confirmed that it's threadirqs that causes the freeze on both -lowlatency and -generic
[11:54] <zequence_> with the driver rt73usb, at least
[11:56] <zequence_> apw: So, best to remove that config for now :)
=== zequence_ is now known as zequence
[12:50] <apw> zequence, ok, we can do that for the next upload
[12:51] <apw> zequence, got a bug number you are working to, which i can link the config change so we remeber to review it again and turn it back on
=== Guest63667 is now known as fmasi
[13:24] <zequence> apw: bug 1279081
[13:24] <ubot2`> Launchpad bug 1279081 in linux (Ubuntu) "linux-lowlatency freezes when rt73usb is loaded" [High,Confirmed] https://launchpad.net/bugs/1279081
=== gerald is now known as Guest75347
[13:53] <rtg> apw, I wonder if this affects our LTS Trusty build: '[PATCH v2] compiler/gcc4: make quirk for asm_volatile_goto unconditional'
[13:55] <matanya> hello, regarding https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705 the bug was introuduced in one of 95 commits i guess
[13:55] <ubot2`> Launchpad bug 1276705 in linux (Ubuntu) "Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)" [High,Confirmed]
[13:55] <matanya> i guess i can help sort it out, any one intersted ?
[13:56] <rtg> matanya, jsalisbury can help you bisect it when he comes online
[13:56] <matanya> rtg: when would that be roughly?
[13:56] <rtg> matanya, in the next hour or two
[13:56] <matanya> thanks rtg 
[13:58] <apw> zequence, ok turned off for the next upload, you'll want to test manually tunring it on to see if the stable .3 fixes it 
[13:58] <rtg> matanya, it looks like jsalisbury is already working on that bug.
[13:58] <matanya> ok, great, i won't bother :)
[13:59] <rtg> matanya, though it might be to your advantage to start a new bug, describe the last known working version, and provide quick turn around on test kernels.
[14:00] <matanya> i'll see if i can be of a help here. thank you
[14:23] <zequence> apw: Alright
[14:54] <rtg> jsalisbury, prolly ought to get bug #1276705 on our top 10 until you can get it bisected.
[14:54] <ubot2`> Launchpad bug 1276705 in linux (Ubuntu) "Kernel 3.13 fail to boot with LSI SAS1068E (Dell SAS 6/iR)" [High,Confirmed] https://launchpad.net/bugs/1276705
[14:54] <jsalisbury> rtg, sure thing.  I'll add it.
[14:56] <matanya> jsalisbury: do you want my help sorting that one out?
[14:58] <matanya> jsalisbury: http://dpaste.com/1614107/
[15:00] <jsalisbury> matanya, can you provide some details on your issue?  Do you have a bug ID?  
[15:00] <matanya> the one mentioned above
[15:01] <jsalisbury> matanya, ah, ok.  I have a test kernel building now.  I'm going to post it to the bug shortly.  It would be great if you could test it.
[15:02] <matanya> ok, thanks
=== erle- is now known as ma
=== ma is now known as matt-
=== matt- is now known as mattt-
=== mattt- is now known as matttt-
=== kamal__ is now known as kamal
[16:35] <_bt> hello, does the latest trusty kernel have this patch? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=227ae10f17a5f2fd1307b7e582b603ef7bbb7e97
[16:35] <_bt> im not sure how to check
[16:36] <_bt> currently, trusty daily is giving this bug our of the box on my hardware: https://bugs.freedesktop.org/show_bug.cgi?id=74927
[16:36] <ubot2`> Freedesktop bug 74927 in DRM/Radeon "Screen corruption on Ubuntu 14.04, Kernel 3.13 with Radeon R7 240 (OLAND PRO)" [Normal,New]
[16:40] <rtg> _bt, yup
[16:41] <rtg> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=summary
[16:43] <apw> rtg, ok i think i have the cloud tools cleaned up as 'cloud-tools', i've pushed that to the repos so you have have a look over it
[16:43] <rtg> apw, ack
[16:44] <rtg> apw, I assume you've added this to -meta ?
[16:47] <_bt> hi rtg
[16:47] <_bt> looks like it made it into 3.13.0-8.28
[16:47] <_bt> and i am running 3.13.0-8.27
[16:47] <_bt> lol
[16:47] <apw> rtg, yes both linux and linux-meta
[16:48] <_bt> brb
[16:48] <_bt> testing
[16:48] <rtg> apw, I know I'm being a complete pain in the ass, but I _hate_ that commit subject and body. This is really about splitting out "Could only" tools into a separate package. As such, I would prefer that Hyper-V get little or no mention (other then maybe a small footnote at the end).
[16:48] <rtg> "Cloud Only"*
[16:49] <apw> rtg, you going to fix it or you want me to?
[16:49] <rtg> I'm happy to re-write it :)
[16:49] <apw> rtg, feel free :)
[16:54] <rtg> apw, ok, pushed. check out what I've written
[16:56] <apw> rtg looks fine
[16:59] <rtg> hallyn, re: bug #1279041 - what is the kernel fix to which you refer ? I can't figure out why ip_local_reserved_ports would be treated different then any other file in that /proc directory.
[16:59] <ubot2`> Launchpad bug 1279041 in lxc (Ubuntu) "/proc/sys/net/ipv4/ip_local_reserved_ports not writable because of apparmor" [Medium,Confirmed] https://launchpad.net/bugs/1279041
[17:03] <xnox> who is responsible for creating /dev/md directory?
[17:05] <rtg> smb, ^^
[17:05] <smb> I would say udev rules
[17:05] <hallyn> rtg: ip_local_reserved_ports needs to be namespaced
[17:05] <apw> xnox, that'd be udev everything in there is its responsibility
[17:05] <apw> xnox, though likely in response to finding something to put in it
[17:06] <rtg> hallyn, but then why doesn't everything else in that directory need to be name spaced in order to be visible ?
[17:06] <smb> Guessing its some /dev/md? appearing
[17:06] <xnox> apw: hm. what if udev couldn't have known about them at the time?
[17:07] <hallyn> rtg: eh, it's kinda ugly and hard to follow
[17:07] <rtg> yeah, I kinf of get that :)
[17:07] <rtg> kind*
[17:07] <hallyn> rtg: some things are namespced;  some are host-wide and should not be namespaced;  some are not yet namespaced
[17:07] <xnox> apw: smb: in the installer - udev fires and is gone, then mdadm kernel modules are loaded, then "mdadm" pretends to find /dev/md/Volume2 which doesn't exist... =)
[17:07] <xnox> let me assemble it and check what happens.
[17:08] <hallyn> rtg: I've not had time to do a full survey.  I'll try to do that if I can get the overlayfs thing working (which so far I can't)
[17:08] <rtg> hallyn, ok, I'll leave you to it
[17:09] <apw> xnox, well ... is /dev devtmpfs in the nistaller setup?
[17:10] <xnox> apw: smb: odd, so it did assemble and create /dev/md/imsm0 but /proc/mdstat is out of date it has the array but not the "container" (intel fakeraid entry)
[17:10] <apw> why is udev not left running by the way
[17:10] <xnox> apw: oh it is running.
[17:10] <hallyn> rtg: thanks :)
[17:10] <xnox> apw: but there was no mdadm nor modules loaded when the drives first appeared...
[17:11] <smb> xnox, /proc should be closest to what the kernel thinks it has
[17:11] <apw> right its not really sensible to say it is out of date
[17:11] <apw> it is a direct representation of what is in the kernel
[17:11] <xnox> apw: smb: so mdadm did start the container, but mdmon was not autostarted and /proc/mdstat is clearly missing an entry =(
[17:12] <rtg> xnox, do you have an entry in /etc/mdadm/mdadm.conf ?
[17:12] <xnox> rtg: ofcourse not, this is in the installer.
[17:12] <smb> In theory it should not be necessary to have one but in practice it can make odd differences
[17:13] <rtg> it certainly does on reboot
[17:13] <smb> xnox, is that a raid5 setup?
[17:13] <xnox> smb: raid1
[17:14] <smb> Wondering whether it needs a md device for the container of this setup...
[17:14] <apw> might that not appear in dm instead ?
[17:14] <smb> But I guess you saw it when not in the installer
[17:14] <xnox> smb: apw: so mdadm --auto-detect (after kernel modules were installed) and then assembling helped
[17:14] <xnox> and how i have two arrays in /proc/mdstat =)
[17:15] <xnox> and it went into resync.
[17:15] <xnox> let's see if i can reboot and repeat everything....
[17:15] <smb> rtg, In theory nowadays everything should just be assembeld by the devices appearing... I n practice I found at some point in the past at least that kernel/userspace started to have differenct options of device names in that case
[17:16] <rtg> smb, yeah, which is why I always write the config to that conf file
[17:16] <smb> Yeah, its the safe way... for some reason
[17:16] <xnox> retoaded: /etc/mdadm/mdadm.conf if there isn't one, one is generated for the initramfs. and even if initramfs is without one, one would be generated inside initramfs and then attempt to assemble everything.
[17:17] <smb> I wanted to investigate but ... *sigh*
[17:21] <rtg> grumble. the apparmor userspace/kernel mismatches are annoying.
[17:22] <apw> rtg, test booting your kernels on precise userspace ?
[17:22] <rtg> yup
[17:23] <rtg> can't start a container
[17:23] <rtg> just gonna grub apparmor=0
=== DarkPlayer_ is now known as DarkPlayer
[18:37] <apw> smb, can you remember what options were bad for luks
[18:38] <smb> apw, errrrrr no (I think)
[18:38] <smb> apw, Bad in what way ?
[18:41] <xnox> apw: xts is the good one, aes is the flaky one.
[18:41] <xnox> (IV vector that is)
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson