=== smb` is now known as smb === amitk is now known as amitk-afk === ghostcube_ is now known as ghostcube === amitk-afk is now known as amitk === fmasi_afk is now known as fmasi [10:52] apw: who'd be the right person to talk to about hibernate in ubuntu? Do you have any knowledge about the initramfs magic, specifically around module loading, if any. [10:53] i thought that stuff was still in the initramfs, i don't recall us changing it [10:53] amitk, ^ [10:54] apw: right, but who's a good person to talk to. I've never really looked into the initramfs [10:54] you could ask me, i've done a fair bit when fixing udev and lvm [10:56] apw: ok, will start an email thread with one of my colleagues. We're going to get hibernate to work on ARM... [10:56] amitk, you might want to inculde slangasek [10:56] apw: ack [10:57] amitk, so i am not convinced that there is anything to do for hibernate is there? it isn't a clever thing in x86 [10:57] amitk, the kernel saves the image to disk, the kernel shuts down the machine, userspace notices the image on next boot and tells the kernel to restore it [10:58] i don't think any of that is system specific [10:58] apw: userspace notices the image on next boot is what we're trying to figure out [10:58] there is a command, something like resume which calls something ... [11:02] amitk, ok it is resume which is part of klibc, but in short what it does is echo "devicemajor:deviceminor:offset" in /sys/power/resume [11:02] and the kernel handles it from there [11:06] apw: and klibc in in initramfs? [11:06] *is in [11:06] amitk, yeah busybox etc use that [11:07] but the important thing is that /sys/power/resume is the interface arm needs to have [11:07] i would assume other than saving registers etc that would be generic [11:07] so if you need to do anything it would be in there [11:08] as all distros will use that interface [11:09] apw: right, it is an architecture hook that needs to be implemented. And we have patches to do that. per-SoC changes should be non-existent, unless the image lies on a device that isn't activated "soon" [11:36] apw, didnt we completely drop hibernate support ? [11:36] * ogra_ remembers a several weeks long discussion on the desktop ML before it was removed [11:37] (i think already in precise) [11:37] heh i just looked it up ... natty actually [11:39] https://lists.ubuntu.com/archives/ubuntu-desktop/2011-January/002754.html [11:39] iirc it resulted in us dropping all userspace bits for hibernate === fmasi is now known as fmasi_lunch === ghostcube_ is now known as ghostcube [12:01] ogra_: interesting... [12:02] * amitk nevers uses hibernate [12:02] * ogra_ neither [12:03] * amitk finds a fresh boot to be faster, but several people really, really care about restoring state of apps [12:03] well the new app lifecycle stuff will handle that even across reboots at some point [12:03] once it enters the desktop from phone ... [12:19] * henrix -> lunch === fmasi_lunch is now known as fmasi_afk === fmasi_afk is now known as fmasi [14:00] is inotify on overlayfs supposed to be supported in the backport kernels for precise? [14:02] hallyn_, I would assume so if its supported in the release kernel. apw ^^ [14:02] inotify on overlayfs doesn't really work, never has [14:02] whatever works on the main kernel works just the same in the backports kernels [14:06] hallyn_, ^ [14:16] apw got it, thanks [14:17] apw: got it, thanks === rtg_ is now known as Guest11042 [15:15] jodh, Still around? [15:15] smb: hi [15:16] jodh, I wonder whether you have a really pressing reason to have the 1rst level guest to be a 32bit installation [15:18] smb: well the dep8 tests I'm developing will need to work on all architectures that Upstart is built on. [15:18] smb: do you have any ideas on what might be causing the issue? [15:18] jodh, Yeah, but your testbed is the 2nd level [15:19] smb: well that has to be nested to allow the existing autopkgtest infrastructure to be leveraged. pitti may have more to say on this, but my understanding is that we need it to be nested (hence the same arch). [15:19] jodh, I am wondering whether using qemu-system-x86_64 in the 32bit 1rst level guest causes the issue. Not sure what the fallback is [15:19] apw, quick review on bug #1213136 ? [15:19] Launchpad bug 1213136 in linux-manta (Ubuntu Saucy) "linux-manta: kernel log fills with 'snd_pcm_update_hw_ptr0: 26 callbacks suppressed'" [Undecided,New] https://launchpad.net/bugs/1213136 [15:20] smb: I can try with 64-bit for all 3 systems in canonistack if you haven't already? [15:20] jodh, You could just use qemu which would be aliased to the same arch. Though in my testing I had now one success but also one crash and weird NMIs being delivered which I not yet understand [15:20] rtg, ok that pulls the majority of the payload out of the ratelimit [15:21] jodh, I am using 64-32-32 right now but would try 64-64-32 for verification next [15:21] smb: yes, the whole thing feels very "shaky" - I managed to get an almost complete test run locally earlier today with no crashes but it crashed on the 2nd run. [15:21] rtg, i would say just leave the code order as it was, and put the ifdef round just the snd_printd [15:21] jodh, I think when I first could not reproduce it was 64-64-32. [15:22] jodh, Just too long ago to be sure [15:22] apw, its the printk_ratelimit() call that is causing the problem. snd_printd() is already ifdef'd by SND_DEBUG [15:22] smb: ok, but did you run that combination a few times though? [15:23] jodh, I will do next. First I tried to see whether I can get into the same situation. [15:23] smb: ack. [15:24] jodh, And that lockup with modprobe almost always happened with the 64-32-32 setup (with the host being quantal). With a host on Saucy the qemu-64bit would fail to start any guest at all [15:24] jodh, Thats how I noticed you using the 64bit version all the time [16:00] jodh, I know 2 out of 2 is not very much, but I gotta run and see that outside world thing. I will put it onto a loop and update the report later when I get back. [16:00] smb: thanks! [16:08] apw, its actually a bug that exists upstream. This is a bit more elegant way to fix it without ifdefs. http://kernel.ubuntu.com/~rtg/pcm/ [16:23] bjf, our raring testing is about 60% done - i'm debating whether to wait until monday and actually finish it or just push it now. what do you think? [16:24] brendand, this will be the default kernel for .3 [16:24] brendand, lets go all the way with it [16:24] bjf, ah i see [16:25] bjf, in that case i'll make sure it goes out first thing monday [16:25] bjf, with full testing [16:25] brendand, thanks === fmasi is now known as fmasi_afk [16:45] * apw migrates to comfy pastures [17:24] * rtg -> lunch [17:30] bjf, i might have made a mistake with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205381 [17:30] Launchpad bug 1205381 in Kernel SRU Workflow security-signoff "linux: 3.2.0-52.78 -proposed tracker" [Medium,In progress] [17:30] bjf, can you set it so that it won't get published yet? [17:31] bjf, remove 'certification-testing-passed' maybe? [17:33] infinity, ^ [17:33] * henrix -> EOW [17:34] bjf, anyway security still need to ack it - for now i'll just ask them not to do so just yet [17:34] brendand, i'll reset some taks [17:34] tasks [17:36] brendand, i just set your task back to In Progress [17:36] brendand, infinity won't promote it before it's ready === bjf is now known as bjf[afk] [17:40] bjf[afk]: I wouldn't have promoted it anyway (and neither would have shankbot), since it's a Friday. :) [17:40] But I do hope all this stuff is ready by Mondayish. [17:41] jjohansen: There seems to be a bit of a backlog of security signoff tasks. [17:42] infinity: yep, I am aware of that. They are the next thing on my todo list [17:42] jjohansen: Shiny, thanks. [17:43] infinity, that's useful info [19:51] * rtg -> EOW === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk [22:22] zequence, yo ... when you get a chance could you make a github lowlatency repo thing for saucy, so i can publish the branches and tags ... so i can pass them off to you [22:29] Hello, I'm sure this question has been answered only but I can't find it. I just build a kernel for raring from git sources with these commands: [22:30] fakeroot debian/rules clean [22:30] DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 fakeroot debian/rules binary [22:30] how can I get the -dbgsym package? [22:34] kyle__: skipdebug=0 [22:35] is that an envirornment variable? [22:35] sorry, skipdbg=0 [22:35] DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 skipdbg=0 fakeroot debian/rules binary [22:36] ok [22:36] next time I build I will try that [22:36] is there anyway to do this without rebuilding or are the symbols already stripped? [22:37] thanks for the help [22:37] i'm not sure, the kernel build system is insane :( [22:41] shouldn't it be: [22:41] DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 fakeroot debian/rules binary skipdbg=false [22:48] it is already gone basically ... and yes non-buildd builds default to no ddebs because they take so very long to make [22:50] I ran the command again without cleaning first, I was hoping that this would reuse the object files already there [22:50] I guess we'll see [22:51] it won't ... [22:51] good luck anyhow [22:51] thanks [22:51] * apw gives it up for the day