| === jjohansen is now known as jj-afk | ||
| jj-afk | back on later | 00:39 |
|---|---|---|
| === sconklin is now known as sconklin-gone | ||
| Thedemon007 | Hello | 05:21 |
| Thedemon007 | On the new Siragon ML-6200 netbook I have noticed that some of the function keys do not work. | 05:22 |
| Thedemon007 | http://pastebin.ubuntu.com/597709/ | 05:24 |
| Meep | Hi, anyone here will/interested in confirming regression point in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760131 ? | 18:17 |
| ubot2 | Launchpad bug 760131 in linux "Power consumption raised significantly in natty" [Undecided,Confirmed] | 18:17 |
| ohsix | that's a good one, you know you can disable the turbo modes; but it raises an important point | 18:18 |
| ohsix | i don't think mav's kernel cared or knew about turbo modes | 18:19 |
| ohsix | ugh phoronix | 18:20 |
| ohsix | how did they waste so man god damned words and not hilight the problem | 18:21 |
| Meep | ohsix: Isolating the git commit is underway. The Linus' tree commit has been identified. Looking to find someone who can reproduce it. | 18:22 |
| ohsix | nice | 18:23 |
| ohsix | theres probably something in Documentation/ about the turbo logic; i don't know how it interacts with cpu governors but you'd think it'd just be another p-state | 18:24 |
| Meep | I've worked with Phoronix on getting details analyzed for other issues. Working with three different projects (Ubuntu/QEMU/KVM) with all of them pointing fingers at each other. | 18:25 |
| Meep | So reporting issues visibly is sometimes the best approach. | 18:25 |
| ohsix | gpu turbo is new post-mav too | 18:26 |
| Meep | Anyway, if there are people who can confirm the power delta between two commits in LInus' tree, we can confirm the merge that caused the regression. | 18:26 |
| ohsix | just running powertop and looking at changelogs will find the problem | 18:26 |
| Meep | The change is looking at being in the merge of the hugetable. | 18:27 |
| Meep | So it's unlikely that powertop will isolate the issue. | 18:27 |
| ohsix | so you suspect that's what's keeping the cpus in turbo, burning battery | 18:27 |
| ohsix | the cpu governor should be keeping it out of turbo if there isn't actually anything to run | 18:28 |
| Meep | Okay. There are two general approaches to identifying regressions. 1) prod and work through the problem directly as thought it's a new issue. 2) bisect blindly back to the cause of the problem and unwind the issue. | 18:29 |
| ohsix | or make a lot of noise | 18:30 |
| ohsix | it looks like pcc can pump up the cpu speed regardless of the governor | 18:30 |
| Meep | I assume then that you are not interesting in actually confirming the regression point? | 18:31 |
| ohsix | the BIOS decides to do that outside of the OSPM methods | 18:31 |
| ohsix | you're a strange one, i'm telling you where it is | 18:31 |
| ohsix | or not | 18:32 |
| Meep | Can you post your analysis to the bug then? | 18:32 |
| ohsix | sure | 18:32 |
| ohsix | they've got a crack team at phoronix though, they'll have it in no time | 18:33 |
| Meep | For the record though, we're tying to find ways that random users who are not domain experts can assist in finding regression points more than just posting bugs. That means that they won't be able to do the direct debugging, and they won't understand all the nuances of a subsystem. | 18:35 |
| ohsix | an elimination process is prudent; minimize where you actually have to look | 18:36 |
| ohsix | reading the commit messages usually directly hilights a related thing | 18:36 |
| Meep | usually. But require domain understanding. | 18:37 |
| Meep | A bisect can go through 1000 commits in 10 or so build/reboot cycles. | 18:37 |
| ohsix | well if you suspect the hugetbl patches you can look at commits just to that directory or file | 18:37 |
| Meep | So it's cheap. | 18:37 |
| Meep | Again, you are assuming domain expertise. Do you have ways that users can assist without the domain expertise? | 18:38 |
| ohsix | it's cheap as long as your time is worthless; and the good/bad determination needs to be made, and expensive | 18:38 |
| ohsix | i'm assuming they can read | 18:38 |
| ohsix | you really don't need to know much to follow them, it rarely gets to that | 18:38 |
| Meep | I'm assuming you want bug reports that say "Hi, I've found a problem with this subsystem. I've isolated it to this change." | 18:39 |
| ohsix | i'm not want for anything | 18:39 |
| ohsix | aside from less phoronix | 18:39 |
| Meep | Yes you are :). You want users to be able to parse a changelog and provide a good bug report. | 18:40 |
| Meep | Phoronix is a website you can avoid. | 18:40 |
| Meep | Bug reports you can't. | 18:40 |
| ohsix | i want people that have the time and effort to use so many words saying nothing, the ability to read even the slightest about what their problem is | 18:41 |
| ohsix | if something changed between x and y, first place to look is the log of chances, with respect to the problem you are having | 18:41 |
| Meep | The problem (as per the bug report) was maverick to natty. | 18:42 |
| ohsix | but you suspect the kernel already, and their versions aren't unknowable | 18:42 |
| Meep | It's clear we have different approaches to this. Post your thoughts on the bug, and we'll see where it ends up. | 18:43 |
| ohsix | i'd be too interested in solving it, i'm not a fan of forums or the mindless speculation | 18:45 |
| ohsix | anyways my utter outrage! is offtopic here, best of luck with what you're doing | 18:47 |
| ohsix | but one last thing, there was a workqueue or thread added for the hugepage migration, if you also supect that; you could investigate there | 18:48 |
| ohsix | i'm only informed by the commit messages fwiw, kernelnewbies has good summaries if you like a quick peek | 18:49 |
| Meep | We'll isolate it to a change, and then the kernel guys can dissect it as to the impact and resolution. | 18:56 |
| ohsix | sounds like an expedient use of someones time, whoever we is; not looking directly at the information that excludes 99% of what they'll be traipsing over | 18:58 |
| Meep | I'm assuming that you understand bisection. You've suggested half a dozen areas that could be contributing. The effort to analyze and test that analysis is covered by a blind bisection across the changes. With a fast machine, you can go from bisection point to point within 10 minutes. That's not too much time for analysis and trawling through changelogs. | 19:03 |
| ohsix | i'm very familiar | 19:03 |
| Meep | (FWIW, each has it's own. I use "trawling through changelogs" you use "triapsing over 99% of changes". | 19:03 |
| ohsix | but that assumes you can determine good/bad; and as you mentioned, that assumes an operator that knows more than nothing, as you seemed to imply was unreasonable | 19:04 |
| === yofel_ is now known as yofel | ||
| jorge | Please, I need some help with this... I have to modify some parameters of the WiFi MAC level, like ContentWindow min/max (CWmin/CWmax), TXOP, etc. | 21:52 |
| jorge | I think the way to go is with iwpriv, with some driver that support those params | 21:52 |
| jorge | am I right? | 21:52 |
| jorge | if so... which kernel modules and drivers are tested for that? MadWiFi perhaps? (I'm trying with a ar9170usb in a D-Link DWA-160, and this one definitely DOESN'T support this, so...) | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!