| === bigbash is now known as zz_bigbash | ||
| === kees_ is now known as kees | ||
| === yofel_ is now known as yofel | ||
| === smb` is now known as smb | ||
| apw | ikepanhc, is that patch enabling the actual letter P key ? | 10:58 |
|---|---|---|
| apw | *boggle* | 10:59 |
| * ppisati is reading the OMAP thread of death on the arm lkml | 11:05 | |
| * apw pokes ikepanhc | 11:08 | |
| smb | apw, Thought more it might be the magic ctrl-p or whatever is used by bios engineers instead of hotkey switch screens | 11:08 |
| apw | smb, it may be that, but if it is then its much less serious and the description is utter pants | 11:09 |
| smb | apw, Somehow I read it in a less-urgent way | 11:09 |
| smb | And I don't know why it needs such special urgency then | 11:09 |
| ikepanhc | apw: no, its an hotkey for acer laptops | 11:12 |
| apw | ikepanhc, a special key with a P on it ? | 11:12 |
| smb | Even a special p key | 11:13 |
| apw | ikepanhc, as the way the description is read, it is hard to see it meaning anything other than the regular P key is affected | 11:13 |
| apw | ikepanhc, what does it look like ? | 11:14 |
| ikepanhc | apw: according to the bug reporter, its a definable hotkey. The function on Windows would be to start some acer boatware, and in acer-wmi, there were other scancode registered for P-Key on other acer machine | 11:14 |
| * ikepanhc googling the pic | 11:14 | |
| apw | http://images.anandtech.com/doci/3631/acer-5740g-17-keyboard.jpg | 11:24 |
| ikepanhc | apw: yes, the right upper key.. | 11:25 |
| ikepanhc | http://www.notebookcheck.net/uploads/tx_nbc2/581743-2.jpg | 11:40 |
| ikepanhc | the key besides power key | 11:40 |
| brendand | man, that's some bad hardware design | 11:43 |
| brendand | press the P key | 11:43 |
| brendand | which one? | 11:43 |
| ikepanhc | apw: smb: I am sending for oneiric SRU, do you suggest we wait for merged into Linus' kernel? I can revise the patch and add CC stable in the patch | 11:43 |
| cking | its one way to P people off | 12:00 |
| cking | having > 1 P key | 12:00 |
| apw | cking, :) | 12:01 |
| apw | ikepanhc, we generally like to at least have a stable upstream sha1 before we commit things if we can, then they arn't likely to change | 12:02 |
| ikepanhc | apw: ok, got it | 12:02 |
| apw | if there is some reason things are on fire without the patch do let us know of course | 12:03 |
| ikepanhc | apw: no, its not, not urgent thing. I sent because I thought its harmless | 12:03 |
| * ppisati -> out for lunch | 12:04 | |
| diwic | apw, does one require special launchpad powers to split things into distribution versions? I'd like to mark bug 857206 as "Incomplete" for Oneiric and "Fix Released" for Precise. | 12:29 |
| ubot2` | Launchpad bug 857206 in linux "(Realek alc887-vd) Speaker and headphones get the same dac" [Undecided,Triaged] https://launchpad.net/bugs/857206 | 12:29 |
| apw | diwic, yes you do, i've approved it for you | 12:30 |
| diwic | apw, thanks | 12:30 |
| herton | vanhoof, linux-backports-modules-3.0.0 (16.9) is now on -proposed with the iwl fix | 14:13 |
| === jdstrand_ is now known as jdstrand | ||
| === bladernr_afk is now known as bladernr_ | ||
| === dduffey_afk is now known as dduffey | ||
| * ogasawara back in 20 | 15:39 | |
| ev | does /var/crash/vmcore being written absolutely mean that the kernel has completely ground to a halt, or are there circumstances from which it can recover and keep going? | 16:52 |
| ev | I'm asking in the context of the dialog we want to display when apport sees one of these, whether it should say that the system has crashed previously, or not make that assumption. | 16:52 |
| tgardner | apw, arges ^^ Isn't vmcore written after the kexec crash kernel has taken over ? | 16:56 |
| apw | tgardner, right, thats after the kernel has been replaced | 16:57 |
| tgardner | ev, so yes, I think you can assume things have completely ground to a halt. | 16:57 |
| apw | ev, a proper vmcore from 'crash' definatly means the kernel stopped and was replaced | 16:58 |
| ev | cheers guys! | 16:58 |
| mpt | Hi folks, I'm writing the error message that comes up when Ubuntu restarts after a kernel oops | 17:17 |
| mpt | So I have a question or two | 17:17 |
| mpt | When there is an oops, do you have to restart the computer manually (by holding down the power button?), or does it restart by itself? | 17:18 |
| tgardner | mpt, it depends on the severity of the oops. its really quite random. | 17:18 |
| mpt | hmm | 17:18 |
| mpt | tgardner, is it possible to tell, from the oops file, whether it did? | 17:19 |
| tgardner | holding down the power button is the only sure fire way to restart, but it can be hard on file systems | 17:19 |
| mpt | (whether it did restart by itself, I mean) | 17:19 |
| tgardner | mpt, I guess you could look in syslog to see if there is a boot message after the oops. | 17:19 |
| tgardner | that is, assuming the oops made it to syslog | 17:20 |
| tgardner | mpt, very few oops will cause an automatic restart. only the most severe triple faults would do it AFAIK | 17:20 |
| tgardner | plus, its a bit arch dependent | 17:21 |
| ev | tgardner: could we not force a magic sysrq + r e i s u b? | 17:21 |
| ev | given that they're going to hold down the power button anyway | 17:21 |
| tgardner | ev, possibly, but what if you're having a boot oops? then you're in a never ending reboot cycle | 17:21 |
| ev | (or the rough equivalent) | 17:21 |
| ev | well, that's the less likely case. And I think it's more reasonable to expect those people to hold down the power button than those in the general case | 17:22 |
| ev | and you'd hit the grub menu handler in that case | 17:22 |
| mpt | I'm not preferring one or the other, this is just to tweak the text | 17:22 |
| tgardner | ev, mpt: so what problem are you attempting to solve? I'm not getting the use case. | 17:22 |
| ev | since the computer would start and the magic grub bit wouldn't be set | 17:22 |
| mpt | tgardner, the problem I'm attempting to solve is explaining what happened. Either it's "Ubuntu has restarted after something bad happened", or it's "You restarted the computer after something really bad happened" | 17:23 |
| mpt | that's all at the moment :-) | 17:23 |
| tgardner | mpt, ok. I'd leave it at "Ubuntu has restarted after something bad happened" | 17:24 |
| tgardner | regardless of _how_ it got restarted | 17:24 |
| ev | (apols, I had jumped in and tried to solve the problem of the computer sitting there doing nothing, which is confusing.) | 17:25 |
| ev | ceding the floor back :) | 17:25 |
| mpt | My next problem is that the error message has no useful advice to give | 17:26 |
| mpt | "Ubuntu has restarted after experiencing an internal error. We hope you took this opportunity to get up and stretch your legs." | 17:27 |
| mpt | "If the problem happens again, cross your fingers while restarting." | 17:27 |
| tgardner | mpt, direct the user to file a bug? | 17:28 |
| mpt | tgardner, the project that's prompting this redesign exists partly (though only partly) to save people from having to report bugs | 17:28 |
| tgardner | ah, you have my sympathies, and are quickly losing my interest. I live to solve bugs, but if there is no report, then there is no bug. | 17:29 |
| ev | eep, no more bugs please | 17:30 |
| ev | the UI will file a crash report without further user interaction (after they click continue, that is) | 17:30 |
| tgardner | seriously, you've gotta file a bug with pertinent info or we can't do much about it. | 17:31 |
| ev | the end goal is to be able to collect the pertinent information without disturbing or confusing the user | 17:31 |
| ev | further down the road, this means server side hooks for things to collect on filing a new crash report | 17:32 |
| ev | (without dialogs asking the user a bunch of questions) | 17:32 |
| ev | for the moment, regular launchpad bug reporting will continue during the development cycle | 17:33 |
| mpt | A convenient side effect is that you'll get better coverage of how often which errors are occurring, rather than just the sort of errors that alpha testers report | 17:33 |
| ev | but as before that part will be turned off once the release is out the door | 17:33 |
| ev | people will still file bug reports | 17:33 |
| ev | and we'll have a way to link crash reports to bug reports | 17:33 |
| ev | in the cases where you really do want someone to explain step by step what happened | 17:33 |
| tgardner | ok. not sure what more I can contribute... | 17:34 |
| ev | apologies again, I'm pulling us away from the conversation at hand | 17:35 |
| ev | matthew's computer appears to have crashed though | 17:35 |
| ev | so it may be a moment before he comes back | 17:35 |
| ohsix | a tool to populate perf buildid stuff with -dbgsym files would be sweet | 17:47 |
| === mpt_ is now known as mpt | ||
| === mpt_ is now known as mpt | ||
| tgardner | ogasawara, ok if I rebuild gomeisa precise chroots ? | 18:27 |
| ogasawara | tgardner: yep | 18:27 |
| * tgardner -> lunch | 18:41 | |
| * tgardner bounces tangerine in 5 minutes for kernel update | 19:44 | |
| * cking notes that exhaustive testing of the cpu governor across a batch of systems is rather time consuming | 20:04 | |
| ohsix | is that for the power stuff? hasn't intel already said that the one that goes really fast and stop saves the most power? :D | 20:06 |
| cking | ohsix, that's very true, and my data is showing that | 20:07 |
| cking | which is a relief | 20:08 |
| ohsix | something about an order of magnitude less power at the low/idle states making it not worthwhile to even step through the middle ons | 20:08 |
| cking | but which governor is best? conservative or ondemand for a given mix of use cases | 20:08 |
| ohsix | well when i can't avoid cpu usage and i don't care how long it is, i set the cpu speed manually; otherwise ondemand | 20:09 |
| cking | you win | 20:09 |
| cking | :-) | 20:09 |
| cking | yep, my data shows you are making the right choice :-) | 20:10 |
| cking | we suspected this was true, but it's good to have the data to back this up across a range of machines | 20:11 |
| ohsix | there's something about user directed actions causing bursts of cpu usage, and otherwise being idle | 20:11 |
| cking | run fast, get work done quickly, then spend as long as you can in deep C states is the win | 20:12 |
| ohsix | there's probably a cpu or working set out there that doesn't follow, but you'd probably sooner change the working set to increase your economy | 20:15 |
| ohsix | were you able to test a machine with an amd cpu? | 20:15 |
| ohsix | kind of curious about the power usage in the different sleep states, eg. how much lower the deeper states are vs. intel | 20:16 |
| JanC | cking: what test results are you referring too (I guess maybe I lost that while my ISP reset my connection)? | 20:16 |
| cking | JanC, some extra data I'm collecting right as we speak | 20:16 |
| JanC | cking: not published yet? | 20:16 |
| cking | JanC, not yet, I'm collecting it with a whole bunch of tests now - it should be ready some time over the next week when I get time to fully analyse the data and sanity check it | 20:17 |
| JanC | nice, looking forward to it ☺ | 20:18 |
| cking | I think the current policy may be fine for most use cases, so no big surprises | 20:18 |
| ohsix | on my netbook the return-to-idle can take a while, but i don't think anything is more optimal | 20:19 |
| ohsix | considering how little power it uses when going full blast ... | 20:19 |
| cking | lets face it, if you want a low power machine, move to ARM ;-) | 20:20 |
| ohsix | or a lithium polymer battery that takes up most of the innards of the notebook | 20:22 |
| ohsix | lipo is magic, but it's a bit dangerous to have it as a user replacable or removable part :[ | 20:22 |
| cking | any form of chemistry seems like magic to me | 20:23 |
| * cking kicks of some longer tests and slips offline for a while | 20:24 | |
| tgardner | ogasawara, pushed rebase to v3.2.5 which dropped the SAUCE patch for 'PCI: Rework ASPM disable code' as well as the 2 v3.2.4 reverts | 20:33 |
| ogasawara | tgardner: awesome, thanks. was just about to do the same. | 20:33 |
| * ogasawara checks that one off the list | 20:33 | |
| tgardner | ogasawara, guess we can all quit early. | 20:33 |
| ogasawara | the weather is way too nice here today, it's getting hard to stay focused | 20:34 |
| tgardner | ogasawara, it sucks here. we had our sun this weekend. now its back to wretched. | 20:35 |
| * tgardner received a dreamplug today and is off to read about it. | 20:40 | |
| === tgardner is now known as tgardner-afk | ||
| jono | jsalisbury, hey, pal | 20:46 |
| jono | I saw you put together a test kernel at http://people.canonical.com/~jsalisbury/lp911059/ | 20:46 |
| jono | but I am running x86, do you have an image for x86 that I can test? | 20:46 |
| jsalisbury | hey, jono, yes one second. | 20:47 |
| jono | thanks jsalisbury | 20:47 |
| jsalisbury | jono, hmm, the x86 kernel didn't build. I'll build it now and post a link in the bug. | 20:47 |
| jono | thanks jsalisbury | 20:48 |
| jono | so I tested the other kernel you wanted me to test and the bug is not present | 20:48 |
| jono | it seems like we may be narrowing down on it | 20:48 |
| jsalisbury | jono, cool, thanks. | 20:49 |
| jono | br | 20:49 |
| jono | bbrb | 20:49 |
| jsalisbury | jono, these test kernels will be a bisection to narrow down the commit that introduced the regression. | 20:49 |
| GrueMaster | bjf: Can you look into bug 921473 and find out why it stalled? Also, I didn't see an imx51 kernel (linux-imx51) update during this SRU cycle. Until IS gets the babbages out of the build pool, we still need to maintain SRU kernel support afaik. | 22:04 |
| ubot2 | Launchpad bug 921473 in linux-mvl-dove "linux-mvl-dove: 2.6.32-422.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/921473 | 22:04 |
| GrueMaster | (not that I need the extra work). :P | 22:04 |
| bjf | GrueMaster: it's "stalled" waiting for an archive admin to copy it to -proposed | 22:07 |
| GrueMaster | Ah. | 22:08 |
| === dduffey is now known as dduffey_afk | ||
| === dduffey_afk is now known as dduffey | ||
| === dduffey is now known as dduffey_afk | ||
| jono | jsalisbury, hey | 23:37 |
| jono | any luck getting that kernel to build? | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
