[05:45] <Toobsteak> hello there everyone ... anyone discussing kernel matters here or am I just not seeing the discussion?  :)
[07:49] <TJ-> I'm seeing a strange 16.04 amd64 issue with suspend. After suspending it last evening, kern.log indicates it woke up after every 30 minutes and then went back into suspend. timestamps jump 30 minutes throughout the night until around 06:49 where it wrote a hibernation image, but seems to have immediately woken from the sleep and then lost power.
[07:50] <TJ-> The way the timestamps of the pre-suspend/post-suspend are using the wrong time initially is making it hard to debug, any ideas on how to figure this out?
[08:16] <TJ-> I've put the logs with bug 1576571
[08:21] <apw> TJ-, well the only things i know of which can wake you like that is the BIOS EC doing it "deliberatly" or "you" setting the RTC wakealarm
[08:22] <apw> TJ-, also I don't believe we trigger hibernate, so could that be one of those BIOS assisted hibernates ?
[08:22] <TJ-> yeah, that's what I was wondering but no RTC set although the regularity points to something like that
[08:23] <TJ-> well, that's the confusing part. the timestamps for the PM: messages 'jump' every 30 minutes but in between there is logging activity which indicates the system is alive. I'm still 1/2 asleep and not yet made sense of it
[08:24] <TJ-> Its' got a pretty reasonable UEFI setup, but there's no sign of ACPI/power related options that could influence this
[08:24] <apw> TJ-, pastebin the dmesg, maybe it will make sense in context
[08:24] <TJ-> apw: it's in the bug report, kern.log
[08:25] <TJ-> actually, just noticed, the kern.log upload is truncated to 1Kib!!
[08:26] <apw> TJ-, but i see you are messing with acpi_osi, have you tested without ?
[08:27] <TJ-> lol... i ran the kern.log through 'head' to check it... and didn't remove that for the final file write!
[08:27] <TJ-> No I haven't - without acpi_osi= some devices are completely missing
[08:28] <apw> in this kernel or previous ones, i mean have you tested this 4.4 kernel without
[08:28] <TJ-> this was the first time I've noticed the suspend issue; new PC about 2 weeks ago, and it's been left powered up until now
[08:28] <apw> confirmed they are still required for this one
[08:29] <apw> ok
[08:29] <TJ-> only used it with this latest kernel. Not even got around to puting 4.6 on this thing yet, still trying to iron out all the 16.04 bugs :)
[08:30] <TJ-> It only has a bluetooth keyb, so the encrypted GRUB file-system presents a problem :P ... currently adding LUKS keyfile support to GRUB, that should be done today
[08:36] <TJ-> I've edited the bug desc. to show the PM: ... 30 minute cycle clearly with grep output
[08:54] <TJ-> hmmm, syslog makes it look like this is a case of an immediate resume-from-S3 but with systemd-suspend.service commanding a new sleep every 30 minutes
[08:56] <apw> which would make more sense that the other
[08:56] <apw> but then times before and after those are never quite clear
[08:58] <TJ-> it's certainly confusing :)
[08:59] <TJ-> i'll do some S3 tests today whilst I'm watching it, although when I command the suspend the PC for all intents and purposed plays dead
[09:00] <TJ-> this is why it should be illegal to ship a PC without a UART serial port exposed :)
[09:01] <TJ-> right, will be in-and-out now as I do some tests
[10:58] <niluje> I'm running Ubuntu 15.04 on arm. I have tons (247 exactly) of process that are defunct, and owned by init. How is it possible? shoudln't init wait for these processes?
[11:02] <apw> niluje, i think we would expect them to be reaped by init yes
[11:04] <niluje> apw: I don't even know where to begin to understand what's going on
[11:05] <niluje> any idea?
[11:05] <apw> pastebin a ps -ef or something and maybe there is a clue
[11:05] <niluje> http://pastie.org/private/ehjsuglbpdpgmw2yqgfoow
[11:09] <apw> niluje, nope they look legit and i'd expect init to deal with them
[11:10] <apw> so one has to assume systemd is sleepy, does it say anything in its journal
[12:18] <niluje> apw: sorry, I'm back
[12:18] <niluje> nope, nothing irregular in my logs
[12:19] <niluje> what I don't understand also, running strace -p 1 shows that init is waiting on "pause" and it does nothing
[12:20] <apw> niluje, whihc is what yu expect it to be doing, sleeping waiting for a SIGNAL
[12:20] <apw> from its children so it cna reap them
[12:20] <apw> that is its prime roll
[12:23] <niluje> ok
[12:23] <niluje> and what could happen here?
[12:25] <apw> well nothing that makes sense to me
[12:26] <apw> is it is paused it should have been sent signals to tell it wake up
[12:26] <apw> andit should have reaped the children befre sleeping
[12:26] <niluje> note, but I guess that's ok
[12:26] <niluje> if I run kill -s SIGUSR1 1
[12:26] <niluje> init doesn't exit from pause
[12:26] <niluje> but I guess the signal is ignored
[12:26] <niluje> let me send a sigchld :p
[12:27] <niluje> nope
[12:27] <niluje> same
[12:27] <niluje> doesn't exit from pause oO
[12:27] <apw> sounds broke
[12:28] <niluje> indeed
[12:28] <niluje> if someone wants to take a look, I can probably spawn a server and give access to it
[12:28] <niluje> or if anyone has an idea
[12:28] <niluje> the issue is reproductible
[12:29] <apw> so these are always KVM guests ?
[12:30] <niluje> no?
[12:30] <niluje> no virtualization involved
[12:32] <apw> niluje, ok my lappy pid1 is not in pause
[12:32] <apw> [<ffffffff81255670>] ep_poll+0x2c0/0x3d0
[12:32] <niluje> yes
[12:33]  * niluje starts a new instance
[12:49] <niluje> grml 
[12:49] <niluje> can't reproduce the issue :p
[13:19] <manjo> apw, you think the yakkety rebase to 4.5 (stable) will happen in the next couple of weeks ?
[13:20] <apw> we're already past 4.5, i would think the first one will be 4.6
[13:20] <manjo> apw, so it will have a 4.5 tag .. on https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/yakkety/ master is 4.4
[13:21] <apw> manjo, that is just a push forward for xenial kernels until we are ready, the rebased kernle is in unstable
[13:23] <manjo> apw, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/unstable/ seems to be 4.4 .. 
[13:24] <manjo> apw, I was hoping to find an official 4.5 tag/branch someplace on yakkety or unstable for me to base my friends patches on coz they moved to 4.5
[13:24] <apw> manjo, tat second one looks to be the right place, and is 4.6 for me
[13:24]  * manjo ◉_◉ 
[13:24] <apw> there are no tags on there, no ubuntu ones, because its never been uploaded
[13:25] <manjo> apw, yakkety once it happens after uds might have 4.5 tags ?
[13:25] <apw> manjo, nope, we'll go striaght to 4.6, this is at 4.6-rc4 i think
[13:25] <apw> we're not going to go backwards now
[13:25] <manjo> apw, oops .. that breaks me 
[13:26] <apw> ?
[13:26] <manjo> apw, so I would need to checkout a 4.5 (tag/branch) to put some friendly sauce on top 
[13:26] <apw> rtg might have an older 4.5
[13:26] <apw> if you are lucky
[13:27] <manjo> apw, coz kernel.org says 4.5 is stable my friends based their patches on 4.5
[13:27] <manjo> apw, and I was hoping to see a 4.5 tag/branch in yakkety or unstable 
[13:27] <apw> manjo, as i say, rtg may have one
[13:29] <manjo> apw, if he does not .. what do you think is the right thing to do ? use yakkety + 4.5 based patches ?
[13:29] <manjo> or ie .. 4.6 + 4.5 patches 
[13:30] <apw> yeah duno, yakkety is going to be moving like a rocket ship
[13:30] <niluje> apw: so, can't reproduce the issue on a newer systemd. I won't search more what was going on, but I guess that's a systemd bug that has been resolved.
[13:30] <niluje> thanks for your time
[13:30] <manjo> apw, you guys should not have skipped stable tags coz some people follow kernel.org to rebase their patches to stable 
[13:32] <manjo> 4.5.2 is stable in kernel.org .. so we should have had 4.5.2 tags in unstable/yakkety 
[13:33] <manjo> it might be hard for me to sell 4.6 mainline to friends who are hard to deal with in the 1st place 
[13:35] <manjo> apw, if I take the mainline builds that you do .. and pick 4.5 and apply the 3 patches will it look more or less like ubuntu-kernel ? those 3 patch sets contain any sauce we carry ?
[13:39] <apw> manjo no they are saucelss
[13:41] <manjo> ouch
[13:45] <apw> manjo, why should we have tags for things we never rebased to
[13:45] <apw> manjo, the up here was rebased recently directly from 4.4 to 4.6
[13:47] <manjo> apw, which is also a good point .. but the reason is .. there are people who will base their patches on stable kernel.org and it is easier if we rebase to stable kernel.org tags or add those as branches + sauce 
[13:48] <apw> manjo, it is easier for you maybe, for us to do the work we need to do twice
[13:48] <apw> but if you have no patches for a version we wasted our time
[13:48] <manjo> apw, ack .. I got your point 
[13:49] <apw> manjo, but as i say, rtg may well have a 4.5 around somewhere
[13:49] <manjo> very valid ... just that I am stuck ☺ 
[13:49] <manjo> apw, guessing he is not around today 
[13:49] <manjo> traveling to cloud sprint ? 
[13:51] <apw> not sure indeed
[14:29] <manjo> apw, thanks for all the info .. I emailed rtg and cced you 
[19:27] <pterodactyl> Consider that I want Ubuntu to change the input from a keyboard to some language other than English and then feed it to the application. Where do I have to make changes for such a tweak? Kernel or some other part of OS? 
[19:29] <pterodactyl> I'm new to OS design and I was wondering if it's possible to make Ubuntu to operate entirely in some other language. 
[21:01] <apw> pterodactyl, yes launguage is a selectable
[21:02] <apw> pterodactyl, settings/lanuguage support