| F41L | Having issues with 3.11 kernel. My 13.10 installation disc is even affected. | 07:42 |
|---|---|---|
| F41L | Possibly related to graphics? (AMD Radeon 7000 series) but recovery mode also locks up soon after entering. | 07:43 |
| F41L | booting 13.10 using 3.8 kernel appears to work somewhat normally, despite a KDE error on login. | 07:44 |
| === fmasi_afk is now known as fmasi | ||
| * apw groans | 09:40 | |
| ppisati | so, if you disable a feature in a pkg, and that feature built a file that was later referenced in a debian/*.install file, the build fails | 09:44 |
| ppisati | so the real question is: how do i know which feature build what? or it's just a tril and error process? i guess the second one... | 09:45 |
| apw | normally trial and error indeed | 10:02 |
| infinity | ppisati: You either be intimately familiar with the configure and Makefiles or you build the package and see what changed. :P | 10:09 |
| ppisati | and, let me guess, i can't reuse the ppaX id after a build failure | 10:14 |
| infinity | Nope. | 10:21 |
| infinity | Good thing there's an unlimited number of integers. | 10:22 |
| infinity | Also, good thing we have mechanisms for testing these things LOCALLY, so you don't have to look a fool with dozens of PPA test builds. :P | 10:22 |
| infinity | *hint, hint* | 10:22 |
| * ppisati thinks infinity is a peeper... | 10:26 | |
| RAOF | Also, the ‘-nc’ option to debuild might be of interest to you. | 10:26 |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| apw | jodh, hey ... what is the startpar-bridge job for? it seems to start a lot on my test box here | 13:26 |
| jodh | apw: sysvinit -> upstart transition-type stuff: slangasek's baby. | 13:28 |
| apw | jodh, oh ... hmmm i think | 13:38 |
| apw | jodh, it must run like 50 times on boot | 13:38 |
| brendand | cking, hi | 14:17 |
| cking | brendand, hi | 14:17 |
| brendand | cking, what you mentioned about getting the local time of cpu0 | 14:18 |
| brendand | cking, is that accesible in /sys or /proc? | 14:18 |
| cking | brendand, why do you need this? | 14:18 |
| brendand | cking, we want to write a hook for pm-suspend that gets the clock time at the start of the suspend process | 14:20 |
| brendand | cking, and also at the end of resume | 14:20 |
| cking | brendand, how about the easy way: "echo PM-SUSPEND-HOOK-START" | sudo tee /dev/msg ... and at the end of the test grep for it in dmesg | 14:23 |
| cking | oops, I mean /dev/kmsg | 14:23 |
| brendand | cking, because fwts is rude and zaps kmsg | 14:24 |
| brendand | ! | 14:24 |
| brendand | cking, :) | 14:24 |
| brendand | cking, we're using fwts to invoke the suspend (in order to get device-check etc) and it is clearing kmsg | 14:25 |
| brendand | cking, although i'm not positive that's after the hook runs | 14:26 |
| erle- | i just reported a bug with waking up after suspense to RAM | 14:26 |
| cking | brendand, why not file a bug against fwts and specify what you want and I can look into adding it | 14:26 |
| erle- | there is a crash report in /var/crash | 14:26 |
| erle- | is it save to just append it? | 14:26 |
| erle- | or may it contain private data? | 14:26 |
| brendand | cking, we want to measure the time from the beginning of suspend to when the system is suspended. then from when it is requested to resume until user space is resumed | 14:27 |
| brendand | cking, if that sounds doable i can file a bug | 14:27 |
| brendand | cking, we're trying to do it at the moment but it's a little rough around the edges | 14:29 |
| brendand | i mean we *are* doing it | 14:29 |
| cking | brendand, doesn't fwts already report the duration of the suspend? | 14:29 |
| brendand | cking, we're not interested in the time it slept for though | 14:30 |
| brendand | cking, and does it report those things seperately or only the total duration? | 14:30 |
| cking | brendand, yup, it does not do what you require, I could add that though | 14:31 |
| brendand | cking, well, i don't want you to do my job for me, but if it would be more suitable to add it to fwts then i'd take you up on it | 14:32 |
| cking | and/or not make it nuke the kernel messages | 14:32 |
| cking | brendand, when do you require a solution? | 14:33 |
| brendand | cking, well we want to get this fixed for 12.04.4 | 14:34 |
| brendand | cking, let me file a bug | 14:34 |
| erle- | bjf, crash report is coming :) | 14:34 |
| cking | brendand, file a bug and I will mull over it and get back to you on monday if it is easily do-able or not | 14:34 |
| brendand | cking, https://bugs.launchpad.net/bugs/1241638 | 14:38 |
| ubot2 | Launchpad bug 1241638 in Firmware Test Suite "FWTS to measure the time from invoking suspend to suspend, then the time from waking system to user-space resume" [Undecided,New] | 14:38 |
| cking | ack | 14:39 |
| === fmasi is now known as fmasi_afk | ||
| === fmasi_afk is now known as fmasi | ||
| slangasek | apw: yeah, startpar-bridge triggers an awful lot | 15:35 |
| slangasek | apw: it becomes obsolete once everything is managed by upstart and not by sysvinit | 15:35 |
| apw | slangasek, with --debug on my test rig here (read a very slow machine) it is seemingly vomiting as the predominant output | 15:41 |
| slangasek | yes, it will do that | 15:41 |
| slangasek | its rules is 'start on started JOB!=startpar-bridge or stopped JOB!=startpar-bridge | 15:41 |
| slangasek | ' | 15:41 |
| slangasek | s/rules/rule/ | 15:41 |
| slangasek | so that's an awful lot of starts and stops, unfortunately | 15:41 |
| apw | so that starts and checks if yo umeant an oldstyle script i assume | 15:42 |
| erle- | jsalisbury, hi, i am the guy with the suspend bug | 15:45 |
| erle- | jsalisbury, i tried 3.12 and it works | 15:45 |
| jsalisbury | erle-, which bug number is it? | 15:46 |
| erle- | will saucy get kernel 3.12 or are you just planning to backport the fix? | 15:46 |
| erle- | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1241582 | 15:46 |
| ubot2 | Launchpad bug 1241582 in linux (Ubuntu) "system freezes after suspend to RAM" [High,Confirmed] | 15:46 |
| jsalisbury | erle-, thanks. Saucy will stay on the 3.11 kernel. The next step is to identify the commit in 3.12 that fixes this and see if it was already sent for inclusion in the stable tree. | 15:47 |
| jsalisbury | erle-, we should probably test the latest 3.11 stable kernel first to see if it's already fixed there. | 15:48 |
| erle- | you mean upstream 3.11? | 15:48 |
| jsalisbury | erle-, if it's not, we can perform a reverse bisect to find the fix in 3.12 | 15:48 |
| jsalisbury | erle-, correct. | 15:49 |
| jsalisbury | erle-, I'll post the links to upstream 3.11 in the bug report. | 15:49 |
| erle- | this? | 15:49 |
| erle- | http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11.5-saucy/ | 15:49 |
| erle- | kernel.org says 3.11.5 is latest | 15:49 |
| jsalisbury | erle-, yup, that's it. | 15:50 |
| jsalisbury | erle-, it would be great if you can test that one | 15:50 |
| erle- | i would like a statement about the safety of apport in regards to privacy, i am somewhat curious | 15:51 |
| erle- | also about the files in /var/crash | 15:51 |
| ogra_ | erle-, apport isnt developed by the NSA ... does that suffice ? | 15:52 |
| ogra_ | (selinux is) | 15:52 |
| erle- | ogra_, i mean, does it take care of not to include potentially private information into reports? | 15:52 |
| erle- | like passwords in memory dumps | 15:52 |
| erle- | i dont like my passwords dumped on launchpad, you know? :) | 15:53 |
| jsalisbury | erle-, there is some info here: https://wiki.ubuntu.com/Apport | 15:53 |
| ogra_ | oops, sorry i mistook apport with apparmor | 15:53 |
| ogra_ | (since this is the kernel channel my brain tripped over this) | 15:53 |
| apw | erle-, we don't take memory images from crashes in the normal case | 15:54 |
| erle- | jsalisbury, just another reboot and we will know | 15:55 |
| jsalisbury | erle-, great | 15:55 |
| erle- | jsalisbury, works | 15:57 |
| erle- | jsalisbury, and yes, i made sure that grub picked the right one | 15:57 |
| jsalisbury | erle-, thats good news. that means the fix will make it into Saucy when it gets the 3.11.5 updates. | 15:58 |
| erle- | jsalisbury, yes | 15:59 |
| erle- | and i personally will just keep this one now | 15:59 |
| erle- | but i will purge the 3.12rc | 15:59 |
| jsalisbury | erle-, ok | 15:59 |
| bjf | erle-, those commits should hit -proposed towards the end of next week and -updates in approx. 3 weeks | 16:00 |
| erle- | bjf, don't you think that this will hit a lot of users with certain hardware? | 16:00 |
| erle- | 3 weeks seems long | 16:01 |
| bjf | erle-, it takes 3 weeks to work though our stable process there are quite a few (197) commits in the next update and we like to do a little testing before just putting it out | 16:03 |
| erle- | bjf, yes, i understand that, it was just a comment | 16:06 |
| * apw will be calling it a week in about half hour | 16:51 | |
| rtg_ | ppisati, can you have a look at bug #1239800 ? | 17:07 |
| ubot2 | Launchpad bug 1239800 in linux (Ubuntu) "Soft lockup when running bonnie++ only at 1600 mt/s" [Medium,Incomplete] https://launchpad.net/bugs/1239800 | 17:07 |
| erle- | jsalisbury, do you have any link to a kernel changelog that refers to my problem? (you don't have to look for one, but if you found one already i would be interested) | 17:22 |
| jsalisbury | erle-, I didn't do any searching on what specific commit fixes the bug | 17:25 |
| erle- | jsalisbury, ok | 17:26 |
| erle- | will 3.11.3 or something come into ubuntu release before 3.11.5 or wont it come at all? | 17:26 |
| erle- | maybe even a earlier version than 3.11.5 fixes the issue | 17:26 |
| erle- | but i dont want to try them all now | 17:27 |
| jsalisbury | erle-, 3.11.0-11.17 was already rebased to 3.11.3. So there is always the possibility it was fixed in 3.11.4 | 17:29 |
| rtg | jsalisbury, saucy master-next is up to 3.11.5 | 17:36 |
| jsalisbury | rtg, ack. | 17:36 |
| jsalisbury | erle-, so the next saucy release will be based on 3.11.5 | 17:37 |
| erle- | thank | 17:38 |
| erle- | and that means the 3 weeks you mentioned, right? | 17:38 |
| jsalisbury | correct | 17:38 |
| erle- | and if anybody asks for help with this, i will propose updates-proposed for the meantime | 17:39 |
| === cmagina_ is now known as cmagina | ||
| * rtg -> EOW | 20:19 | |
| sn0wb1rd | Hello geeks, I have the "3.2.0-49-virtual" version of kernel on my 12.04 Ubuntu virtual machine. I am experiencing some issues with xfs with and found that this commit https://github.com/torvalds/linux/commit/3948659e30808fbaa7673bbe89de2ae9769e20a7 fixes the problem in 3.4 version of the kernel. There is no virtual kernel available for 3.4 or anything higher than "3.2.0-49-virtual". How do I backport the change and rebuild my kernel to include | 21:11 |
| sn0wb1rd | this fix? | 21:11 |
| sn0wb1rd | Also is it possible to request for virtual kernel images for recent versions of kernel? | 21:12 |
| bjf | sn0wb1rd, that looks like a pretty trivial fix. please file a bug and add that information to the bug | 21:27 |
| sn0wb1rd | bjf: that is awesome. filing a bug now. | 21:29 |
| sn0wb1rd | bjf: Is this about getting virtual kernel images for recent versions of kernel? | 21:29 |
| bjf | sn0wb1rd, no, that will help get the fix into the kernel. then we'll roll out new kernels. | 21:32 |
| sn0wb1rd | Ok, I'll file a bug with the information I have. | 21:32 |
| * bjf is now afk | 21:32 | |
| sn0wb1rd | bjf: https://bugs.launchpad.net/ubuntu/+bug/1241848 | 21:46 |
| ubot2 | Launchpad bug 1241848 in Ubuntu "Request for updated Ubuntu virtual kernel images" [Undecided,Confirmed] | 21:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!