[12:19] <yossarianuk> hi - I have a question that really is related to the launchpad process.
[12:19] <yossarianuk> I started this bug  - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434842
[12:20] <yossarianuk> and some kind person has responded and given me a kernel to test.
[12:20] <yossarianuk> I have tested and test worked - do I need to chance the status of the bug or it is a matter of just waiting now?
[14:39] <infinity> yossarianuk: You commenting was enough.
[14:45] <yossarianuk> infinity: thanks !
[14:47] <infinity> apw: See my last comment on LP: #1434842 but, other than those two things, +1 from me on the patch.
[14:49] <yossarianuk> infinity: apw: thanks for your efforts.
[14:53] <apw> infinity, yep and yep
[14:55] <infinity> apw: And yay for leveraging a feature we introduced all of a week ago. :P
[14:55] <apw> infinity, who me .. never :p
[15:54] <jsalisbury> smoser, just wanted to give you a heads up about bug 1435946 .  The bug description is for Power8, but I'm also hitting it with a moonshot cartridge.  There is a cloudinit stack trace in the bug report.
[15:54] <cristian_c> jsalisbury, hello
[15:55] <jsalisbury> cristian_c, hi
[15:57] <smoser> jsalisbury, so can you explain more what is happening ?
[15:59] <jsalisbury> smoser, After a trusty deployment, I can log into the system.  However, after a reboot or two, the network fails to come up and that cloudinit trace is printed on the console.  It just started happening yesterday for me and it seems for the power8 system too.
[15:59] <smoser> "after a reboot or two"
[16:00] <jsalisbury> smoser, yeah, I need to redeply to see if it's actually just one reboot, I'll confirm that
[16:00] <smoser> but it installs ? and the reboots and everything is good
[16:00] <smoser> and then another reboot (or two) and gone ?
[16:01] <jsalisbury> smoser, yeah.  But its not gone, the system is still there and I can get to the console, the network devices don't come up.  You happen to know the default password for the ubuntu user?  If so, I can log in from the console and dig deeper
[16:02] <smoser> jsalisbury, there is no default password.
[16:03] <jsalisbury> smoser, hmm, so I should probably set it after the first deploy, so I can get back in from the console
[16:04] <smoser> yeah
[16:05] <jsalisbury> smoser, I just scrolled back on the console a bit and see some more details:
[16:05] <jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1435946/comments/5
[16:06] <bjf> jsalisbury, i'm trying it here on an intel nuc
[16:06] <jsalisbury> bjf, ack.  
[16:10] <jsalisbury> smoser, I'm re-deplying the node note, so I should have more details in a bit.
[16:10] <jsalisbury> s/note/now/
[16:11] <smoser> k. thanks.
[16:11] <bjf> jsalisbury, smoser so far it's working fine here
[16:11] <jsalisbury> bjf, did you try a couple of reboots?
[16:11] <bjf> jsalisbury, i'm on my 4th
[16:12] <jsalisbury> bjf, ok.  I'm starting from scratch again too, so I'll have some more info in a bit.
[16:15] <bjf> jsalisbury, a dozen reboots and it's still just working
[16:24] <jsalisbury> bjf, ack
[16:24] <smoser> jsalisbury, i suspect your maas region controller went up in flames :)
[16:24] <smoser> if yo udo reproduce and get in, then /var/log/cloud-init.log should have some WARN in it.
[16:35] <cristian_c> jsalisbury, I'd like to know where I can find info about reverts
[16:43] <jsalisbury> cristian_c, The git documentation has some good info: http://git-scm.com/docs/git-revert
[16:43] <jsalisbury> cristian_c, or you can do a 'man git-revert'
[16:43] <cristian_c> jsalisbury, revert of a commit
[16:43] <cristian_c> ah, ok, seen
[16:43] <cristian_c> sorry
[16:44] <cristian_c> :)
[16:44] <neoark> jsalisbury https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1436319 started happening somewhere in 3.13
[16:47] <jsalisbury> cristian_c, I'm still trying to get a test kernel built for you for bug 972604 .  I'm having some build failures after reverting the suspect commit.
[16:48] <cristian_c> jsalisbury, ah, ok
[16:48] <jsalisbury> neoark, thanks for the update.  we should be able to perform a bisect to figure the commit that caused this
[16:50] <jsalisbury> neoark, I'll dig deeper into that bug and see why it was changed, if it was changed on purpose
[16:53] <neoark> Thanks I wasn't sure if was bugged or changed.
[16:54] <jsalisbury> neoark, I'll figure that out for you.  If it's a bug, we should be able to figure what caused it.
[17:18] <jsalisbury> smoser, bjf It figures, after re-deploying the node, I can't reproduce the bug anymore.  Maybe it was just something related to yesterday and the MAAS controller.  Anyway, I'll keep a close eye on things and see if I can make it happen again.
[17:19] <smoser> jsalisbury, ok. well, as i said, i suspect that your region controller went up.
[17:19] <smoser> cloud-init is attached to it on every boot. for better or worse.
[17:20] <jsalisbury> smoser, could be.  I don't administer any of the controller stuff
[17:20] <smoser> and cloud-init doesn't do a good job of telling you whats going wrong.
[17:21] <jsalisbury> smoser, thanks for looking. 
[17:33] <nuno> Hello. May I ask a question regarding the iperf tool ?
[18:09] <apw> nuno, no point in asking to ask, ask and we may know or redirect you to someone who might
[18:12] <nuno> ok. So I have a network where I A can reach B and vice versa
[18:12] <nuno> that link has a queue with a max rate limit of 20mbps (using linux-htb qdisc)
[18:14] <nuno> when I run iperf tool sending for example 50mbytes of data, I get a value around 18mbps (which does not exceed the 20mbps) on the server
[18:14] <nuno> On the client I get a value exceeding the 20mbps (around 24mbps)
[18:15] <nuno> If I reverse and make B client and A the server, the A reports now ~18mpbs and B around 24mbps
[18:15] <nuno> So, what's the difference between the client and the server values when doing iperf ? On which values should I rely on ?
[18:20] <apw> nuno, how long are the tested transfers, as i find the first seconds are miss counted due to buffers
[18:20] <infinity> nuno: iperf, or iperf3?
[18:20] <infinity> nuno: iperf is, as some would say, "full of lies".  iperf3 slightly less so.
[18:25] <nuno> let me check, just a second
[18:27] <nuno> the command I run is just iperf so guess its just iperf (version 2.0.5)
[18:28] <nuno> apw: I've tested for 6 minutes
[18:28] <nuno> it was a "1gbyte file"
[18:29] <nuno> But why server is giving me the "correct" values and client always exceeding ?