[09:03] <apw> eno-gabriell
[09:04]  * apw yawns theatrically
[09:04] <smb> apw, You expect people to actually hang on after asking a question. ;-P
[09:12] <apw> smb, this kvm patch, i don't think it does what i expected it to
[09:12] <apw> smb, or indeed what the description implies.  if the issue is folding the bit in, why don't you fold the bit in just before calling kvm_resched(), and isn't not calling it bad
[09:12] <smb> apw, why? it seems to at least from a practical experience
[09:13] <smb> Not sure I parse the last part of the sencence
[09:15] <smb> But I did not want to meddle around with the bits in the background. I think that at the place where kvm does the cond_resched there probably should not be anything preventing it... at least not in the config_preempt=n case
[09:32] <apw> if (test_tsk_need_resched(current)) set_preempt_need_resched();
[12:09] <apw> smb, that patch looks like what i would expect, if you have tested it i'll just commit it
[12:11] <smb> apw, I thought "compile it - ship it" was the motto ;) No, got it tested on my 32bit install. At least was able to boot ok twice in kvm
[12:11] <smb> while otherwise none is successful
[12:11] <apw> smb, yeha as i recall when we talked "way back when" it was basically fatal on all boots
[12:11] <apw> (without)
[12:12] <smb> right
[12:12] <smb> apw, note the buglink I forgot to add initially
[12:14] <apw> smb, is this fixed in 3.14 etc and later, "some other way" ?
[12:14] <smb> apw, Not to my knowledge but I was not testing a few weeks
[12:15] <apw> ok
[12:17] <apw> smb, i shall assueme you are owning that :)
[12:17] <smb> apw, owning? I suppose need to try getting it solved for read. Yeah, probably
[12:24] <apw> s/read/real/?  for unxious ?
[12:39] <smb> apw, true
[14:31] <mjeanson> rtg: Hi, I was wondering if you knew which version of the lttng modules was last pulled in trusty's kernel?
[14:32] <rtg> mjeanson, it was an rc candidate for 2.4 IIRC
[14:32] <rtg> the lttnk-modules package is more up to date
[14:32] <mjeanson> I'm investigating a problem with the lttng-modules-dkms package
[14:32] <rtg> lttng*
[14:32] <mjeanson> the rc modules are identified as 2.4.0, so dkms won't install over those from the ubuntu kernel
[14:33] <rtg> mjeanson, I've removed lttng from the kernel, so this next upload should fix your issues.
[14:33] <mjeanson> and some modules don't have version tag, resulting in a non-working mix and match
[14:33] <mjeanson> ok great
[15:24] <apw> rtg, ... ooops
[15:24] <apw>       MISS: lttng-tracer
[15:24] <apw>       MISS: lttng-types
[15:24] <apw>       read 2952 modules : new(0)  missing(42)
[15:24] <rtg> apw, hmm, thought I did a test build. I'll get 'em
[15:25] <apw> rtg, ack
[15:26] <rtg> apw, ah, I hacked it out of the previous ABI
[15:26] <apw> ahh startrewrelease nackered you
[15:27] <rtg> apw, am gonna collapose it into the SNR and slam HEAD, OK ?
[15:27] <apw> rtg, ack
[16:24] <hallyn> rtg: hi, so still, months later, i can ssh into gomeisa but not tangerine.  
[16:25] <hallyn> i get 'permission denied (publickey)...
[16:25] <rtg> hallyn, hmm
[17:22] <smoser> rtg, i think i pinged you earlier this week with just a pastebin stack trace
[17:22] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301496
[17:22] <ubot2> Launchpad bug 1301496 in linux (Ubuntu) "kernel crash: Unable to handle kernel paging request for data" [Undecided,New]
[17:23] <smoser> it happened again. you can change title of bug to be more correct.
[17:24] <rtg> smoser, try it with -20. I turned off ZSWAP
[17:26] <smoser> Z as in compress?
[17:26] <smoser> and swap as in swap ?
[17:27] <smoser> $ free
[17:27] <smoser>              total       used       free     shared    buffers     cached
[17:27] <smoser> Mem:      16742464   12982528    3759936      26240     223872   11398080
[17:27] <smoser> -/+ buffers/cache:    1360576   15381888
[17:27] <smoser> Swap:            0          0          0
[17:27] <rtg> smoser, yeah, it was still listed as an experimental feature.
[17:27] <smoser> ie, there is no swap on the system.
[17:27] <rtg> smoser, -20 also has a major stable update. does this happen every time ?
[17:28] <smoser> no, not every time. we've seen this twice, and jcastro is working juju very hard.
[17:28] <smoser> jcastro also informed me that juju stack traced
[17:28] <smoser> and i can get that stack trace if useful.
[17:29] <rtg> smoser, from  the current archive kernel please. This trace doesn't have much to go on.
[17:29] <apw> smoser, so you got that with -19 and not the -8 this time ?
[17:29] <smoser> apw, yes.
[17:29] <rtg> not that that will change much.
[17:30] <smoser> for the record, -19 was current as of 9 hours ago
[17:30] <apw> isn't that saying that netns is closing there when it barfed ?
[17:31] <smoser> (ie, its not like i was running something from 3 weeks ago)
[17:31] <smoser> juju is running several lxc containers.
[17:32] <rtg> smoser, we're not accusing you of being a lagard. I'm merely pointing out that -20 has a huge stable update in it.
[17:32] <smoser> k. i'll try to get jcastro to do that.
[17:32] <rtg> -21 actually
[17:34] <smoser> bah. sorry. i thought i was only 1 behind.
[17:35] <smoser> alright. htat system is up in 3.13.0-21-generic now.
[18:34] <manjo> ppisati, around ? 
[18:35]  * manjo thinks rtg was scared I would ping him next ... ? 
[18:38] <manjo> rtg, got a quick question for you 
[18:39] <rtg> manjo, hmm ?
[19:13] <miseria> "que doloroso es amar y no porderlo decir, caminar y no saber donde ir, vivir y no saber donde morir" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[20:24] <darklight_> RAOF, ping
[20:55] <bladernr_> asked in #ubuntu-server and I'll ask here too...
[20:55] <bladernr_> hey, how familar are any of you with tweaking kernel routing?
[20:55] <bladernr_> there used to be a setting in /proc/sys/net/ maybe in ./ipv4 to force packets to ONLY go out and return via the interface they were supposed to
[20:56] <bladernr_>  by default, it's possible to have packets go out eth1 and come in eth0 if both are on the same network
 and it's been well over 5 years since I last tried this and I forgot the magic switch.
[20:57] <apw> bladernr_, do those interfaces have the same ip?
[20:57] <bladernr_> no, but they're on the same LAN (e.g. 10.0.0.123 and 10.0.0.128)
[20:59] <apw> so that would be down to how arp responses occur then else each would only respond to its own
[20:59] <apw> but no i cannot recall seeing the option you seek
[21:00] <bladernr_> hrmmm.. ok.  I found the ip-sysctl docs so maybe something in that will help too...
[21:02] <apw> there might be a kernel parameter (which may have a sysctl equiv) called arp_ignore 
[21:02] <apw> oh it is documented in that very file
[21:02] <apw> bladernr_, ^
[21:03] <apw> bladernr_, i think arp_ignore of 2 is what you describe, maybe
[21:03] <bladernr_> perhaps so... i was just starting to look at arp related things in the docs... you beat me to it.
[21:03] <apw> net.ipv4.conf.all.arp_ignore = 0 
[21:03] <apw> that one maybe
[21:03] <bladernr_> thanks apb1963 I'll play around with that and see what happens
[21:03] <bladernr_> err... I meant thanks apw... tab complete win
[21:07] <apw> bladernr_, some of those .all. things copy to an interface when it is made, and need changeing per interface as well if the interface is established before it si changed
[22:17] <hatch> hey guys, any idea of the kernel will be fixed so it will run on more than one cpu for the new mac haswell machines? 
[22:17] <hatch> for 14.04
[22:18] <bjf> hatch, do you really mean one cpu or one core?
[22:18] <hatch> sorry one core :)
[22:18] <hatch> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
[22:18] <ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
[22:19] <hatch> the title is a little missleading as it's also an issue on the MBP's
[22:19] <bjf> hatch, because i'm running an 8 core haswell and it's banging on all of them
[22:19] <hatch> misleading 
[22:19] <hatch> oh really....
[22:19] <bjf> hatch, it's not a macbook air though
[22:20] <hatch> did you have to do anything special to make it work?
[22:20] <bjf> sforshee, do you have a haswell macbook?
[22:20] <hatch> the same issue for the macbook pros
[22:20] <bjf> hatch, nope
[22:20] <bjf> hatch, htop shows 16 cpus and a kernel build works them all
[22:21] <hatch> hmm maybe I should try the latest kernel
[22:21] <bjf> hatch, i'm running the latest kernel 3.13.0-21.43
[22:22] <bjf> hatch, we are talking trusty right?
[22:22] <hatch> yeah
[22:22] <bjf> hatch, and was it working before and suddenly stopped?
[22:23] <bjf> (after an upgrade)
[22:23] <hatch> bjf I installed it, it booted, then on reboot it stopped at Node #0  CPUS #1
[22:23] <bjf> hmmm
[22:24] <hatch> basically I have the exact same issue on my MBP as outlined in that bug with the Air
[22:24] <bjf> i have another haswell here, let me try that
[22:27] <hatch> great thanks
[22:39] <hatch> I'd be happy to provide any other information - I'd really like to get Trusty running on metal on this thing :)
[22:46] <bjf> hatch, i'm installing from scratch, won't take long
[22:47] <hatch> oh ok, well I sort of hope it doesn't work so that it's reproducible :D
[22:48] <hatch> of course if it's a newer kernel than I have then that would also be good :)
[22:48] <bjf> heh
[22:56] <bjf> hatch, this is a dual core system with hyperthreading so htop shows it has 4 cpus. i see them all getting worked.
[22:57] <hatch> hmm well then...
[22:57] <hatch> is there some documentation on how I might upgrade the kernel? I can get to the grub loader but beyond that it hangs
[22:57] <hatch> I could wipe the partition and start over too I suppose
[22:58] <bjf> hatch, you should be able (from a terminal window) sudo apt-get update; sudo apt-get dist-upgrade
[22:58] <hatch> bjf yeah I can't get that far
[22:58] <hatch> :)
[22:58] <bjf> hatch, so it won't even boot up for you?
[22:58] <hatch> nope, hangs at the same place as in that bug report....identical
[22:59] <hatch> there is an image in there to where it's hanging 
[22:59] <Sargun> Any reason why CONFIG_IP_VS_IPV6 is disabled?
[22:59] <hatch> bjf this is the picture supplied by the original bug reporter https://www.dropbox.com/s/behviox991o01o1/2014-02-23%2016.15.15.jpg
[23:00] <bjf> jsalisbury, ^^ this seems like it should be on our hot list
[23:00] <jsalisbury> bjf, ack, I'll add it.
[23:00] <hatch> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284085
[23:00] <ubot2> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [High,Confirmed]
[23:00] <hatch> there is the ticket again
[23:00] <jsalisbury> hatch, I also just posted some comments in the bug report on testing older kernels or Ubuntu releases.
[23:00] <hatch> oh ok awesome
[23:01] <hatch> I'd be more than happy to help debug/test anything too as it sounds like you're not able to reproduce
[23:01] <bjf> hatch, did this work with an earlier version of trusty or any saucy?
[23:01] <jsalisbury> hatch, you can either download prior kernels and install them on your current install, or create a LiveCD with the prior Ubuntu releases.
[23:02] <hatch> bjf honestly I haven't tried that - I could though
[23:02] <hatch> I've just been running a vm on top for work
[23:02] <bjf> hatch, that would help us identify if it a specific, recent commit or it's been broken forever
[23:03] <hatch> alright tonight I'll give saucy a go, and the latest trusty
[23:04] <hatch> thanks for the help
[23:04] <jsalisbury> hatch, cool.  If we find it's a regression, we can then perform a bisect to identify what commit introduced it.
[23:05] <hatch> awesome - we have a sprint coming up...I dont' want to take any OSX heat if I can avoid it :P
[23:10] <jsalisbury> hatch, your boot dmesg seems to indicate that you have 8 cpus when you booted 3.13.0-8.28-generic: https://launchpadlibrarian.net/167437657/BootDmesg.txt
[23:11] <jsalisbury> [    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1
[23:11] <jsalisbury> [    0.000000] PERCPU: Embedded 29 pages/cpu @ffff88026f200000 s86400 r8192 d24192 u262144
[23:11] <jsalisbury> [    0.000000] pcpu-alloc: s86400 r8192 d24192 u262144 alloc=1*2097152
[23:11] <jsalisbury> [    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[23:11] <hatch> jsalisbury I wasn't the original bug reporter, but my message was the same
[23:11] <jsalisbury> hatch, ah, ok, so that isn't your system.
[23:11] <hatch> no I have a MBP which hung on the same spot that was shown in the image linked in the bug
[23:11] <hatch> sorry I thought that meant it was only reading a single core
[23:12] <hatch> I really know nothing about the kernel :)
[23:12] <jsalisbury> hatch, ok, so it hangs at that spot you posted in the picture?
[23:13] <hatch> not my picture.....hangs in the same spot :)
[23:13] <jsalisbury> hatch, ok.  It will still be good to know if this is a regression, which would allow us to bisect.
[23:14] <hatch> yeah definitely
[23:16] <hatch> I'll wipe the partition and try saucy, if that's successful then I'll try the latest trusty
[23:16] <hatch> if neither work are there any logs or anything that would be beneficial? 
[23:17] <jsalisbury> hatch, you could just try booting a LiveCD, which might be quicker.  It might also be good to just open a new kernel bug, which would give us all your logs.  It can then be marked as a duplicate.  You can open a new kernel bug by running this from a terminal:
[23:17] <jsalisbury> hatch, ubuntu-bug linux
[23:18] <jsalisbury> hatch, Basically to boot from a LiveCD, select "Try Ubuntu" install of Install Ubuntu.
[23:18] <hatch> yeah ok - so that will run through all of the same stuff as running on metal?
[23:19] <jsalisbury> hatch, yes, it will just boot off the flash drive instead of booting from your hard disk.
[23:20] <hatch> oh ok - I assumed that it would be different for whatever reason so I didn't try
[23:21] <jsalisbury> hatch, Anything you do while booted to the LiveCD wont be saved to your hard disk, but it will exercise the kernel and let us know if that kernel version has the bug or not.
[23:21] <hatch> Yeah I knew it woudln't touch the disk but good to know that it'll run the same stuff in the kernel
[23:22] <jsalisbury> hatch, just to confirm, you were able to install Trusty fine, but this bug happened once you rebooted?
[23:22] <hatch> yeah I rebooted right away though
[23:23] <jsalisbury> hatch, ok.  maybe run dmesg and save it if you are able to boot a liveCD.  Something like:
[23:23] <jsalisbury> sudo dmesg > dmesg.out
[23:23] <jsalisbury> Then copy that file off the system, so it can be reviewed
[23:24] <hatch> ok can do
[23:24] <hatch> I'm on the machine right now just finishing up some work so once I"m done I can give that stuff a go
[23:24] <jsalisbury> hatch, if you are able to boot a LiveCD.  You can then install that kernel version onto your Trusty install and see if the bug goes away.  
[23:24] <hatch> ahh good idea
[23:24] <jsalisbury> that will confirm it's a regression or not.
[23:26] <jsalisbury> hatch, cool.  I'm finishing up for the day, but I'll check with you first thing in the morning.  You can either update the bug report, or just send me email.
[23:26] <hatch> sure will do thanks again for your help
[23:26] <jsalisbury> np