| smb | cking, have you insight into the acpi processor declaration? | 09:16 |
|---|---|---|
| cking | smb: acpi processor declaration - only what the ACPI handbook says, and from memory, zilch, zero. | 09:16 |
| cking | what's required? | 09:17 |
| * apw notes the mtrr conv is still there in scroll back ... i think i have found the change which might make that come back, building a test kernel now | 09:17 | |
| smb | I am revisiting a bug about these pause-until-keypress on boot. And some guy seems to be able to fix it for him with a custom dsdt. | 09:17 |
| * apw wonders if he told you what he changed | 09:17 | |
| smb | beside other things in there, this looks a bit suspicious | 09:17 |
| smb | - Scope (\_PR) | 09:18 |
| smb | + Scope (_PR) | 09:18 |
| smb | { | 09:18 |
| smb | - Processor (CPU0, 0x00, 0x00001010, 0x06) {} | 09:18 |
| smb | - Processor (CPU1, 0x01, 0x00001010, 0x06) {} | 09:18 |
| smb | + Processor (CPU0, 0x00, 0x00000000, 0x06) {} | 09:18 |
| smb | + Processor (CPU1, 0x01, 0x00000000, 0x06) {} | 09:18 |
| smb | } | 09:18 |
| cking | OK - me looks at manual | 09:18 |
| smb | In the book it only says the number is the processor block address | 09:18 |
| apw | but what is the processor block ... | 09:19 |
| smb | exactly | 09:19 |
| cking | how can that change fix the bug?(!) | 09:19 |
| * apw connects a tap to cking's acpi brain centre | 09:19 | |
| apw | if the processor block describes the processor, then it might change the capabilities of the cpus | 09:20 |
| cking | cking's acpi brain centre is in need of coffee + some reading of the spec | 09:20 |
| smb | apw, That is my wild guess | 09:20 |
| * apw couriers over some freshly ground beans | 09:20 | |
| smb | The rest of the changes mostly consist in using One instead of 0x01 | 09:20 |
| smb | and Zero instead of 0x00 and renames like \_PR to _PR (which looks slightly wrongish to me) | 09:21 |
| cking | I'm googling for some info.. | 09:23 |
| * apw plays the countdown clock tune in the backgroun | 09:28 | |
| * cking is now reading some pdfs.. | 09:32 | |
| hughhalf | o | 09:34 |
| * smb is scared of what he has done... | 09:38 | |
| smb | Actually 0x0 could mean nothing which would be slightly contradicting the 0x06 length but on the other hand there was a little sentence somewhere else about ignoring those definitions... | 09:43 |
| cking | From my limited googling know-how, the address refers to the PBLK address which allows inter processor communication some how - if set to zero it essentially states there is no PBLK. I assume the hang is because something is borked on the interprocessor communication. | 09:43 |
| cking | Is this an AMD processor? | 09:43 |
| smb | Its one of those bugs with 320 comments... I believe yes, some with MCP67 based hardware... | 09:46 |
| cking | smb: acpi_processor_get_power_info_fadt() checks the PBLK - and probably this is used when the system goes idle. I've seen some comments that this may be broken on some AMD cpus | 09:46 |
| cking | Is than enough to get ones teeth into? | 09:47 |
| * smb notes that down | 09:47 | |
| smb | That is a pointer to look at. Thanks | 09:47 |
| apw | smb did we ask them to try idle=foo type selectors? | 09:47 |
| smb | apw, I don't think so. Hard to tell under that pile of comments... nope, does not look like it | 09:48 |
| smb | bug 272247 | 09:49 |
| ubot3 | Malone bug 272247 in linux "System freezes during boot, unless I hold a key down" [High,Confirmed] https://launchpad.net/bugs/272247 | 09:49 |
| smb | wear your danger-sensitie-googles | 09:49 |
| apw | smb, damn i think we talked about putting a list of options to try together for them, seems we talked and failed to act | 09:49 |
| smb | Yeah, and in the mean time some of those just gather a lot of other drifts | 09:50 |
| apw | you just know its going to be a 2 line quirk once its found | 09:52 |
| smb | apw, most of the affected in that report seem to be hp pavilion laptops. but I just look at one stating he got a P4 moile with an intel chipset... | 09:53 |
| smb | Toshiba Satellite A30 | 09:53 |
| apw | hrm ... | 09:53 |
| apw | though many people see the same bug when it cannot be the same | 09:53 |
| smb | HP Pavilion dv6646us, AMD turion64x2, nVidia, Broadcom. | 09:54 |
| smb | yeah, at this point it is hard to make out any real issue | 09:54 |
| smb | It can be the same or various things | 09:55 |
| smb | I would think the essence is that for some reason the system ends up in a sleep state without a wake up trigger. That could be some timer issue or processor definition... | 09:56 |
| smb | Best action is to try to dig into that with that one system I got with that problem... | 09:57 |
| * cking agrees | 09:58 | |
| smb | Ok, that would be a system which defines a register block only for CPU0 (on a amd dual core) | 10:00 |
| smb | So I could both try the idle= and the modified dsdt | 10:04 |
| smb | This one is special though, as it only has problems with C1E enabled | 10:04 |
| cking | smb: maybe this has some background hints - https://bugzilla.redhat.com/show_bug.cgi?id=465637 | 10:04 |
| ubot3 | bugzilla.redhat.com bug 465637 in kernel "C1 state unsupported on modern AMD mobiles" [Medium,Closed: cantfix] | 10:04 |
| smb | cking, Thanks for that link. Will have a read on that | 10:05 |
| cking | it may be related, hope it does not waste your time. | 10:05 |
| smb | The beginning sounds intresting anyway | 10:05 |
| cking | I like the comment "I will never again buy any AMD product " | 10:06 |
| cking | states are processor power states. C1 is mandantory and reached on IA32 compatible processors using the HLT instruction, C2 and C3 are optional and must be configured. | 10:09 |
| cking | C states can be configured in ACPI using two methods: | 10:09 |
| cking | 1. by defining the P_BLK base address in the Processor() Definition, and P_LVLx_LAT values in the FADT | 10:09 |
| cking | 2. using the _CST object | 10:09 |
| cking | P_BLK is easier to configure, if the hardware supports that method. ACPI defines that there must be two registers at P_BLK+4 and P_BLK+5 that initiate a transition to C2 or C3 when the register is read. After sleep, the read returns 0. P_LVLx_LAT define the worst case latency of the state transition. | 10:09 |
| cking | _CST is necessary if you want to support more than 3 C states, or if the transition procedure doesn't follow the ACPI requirement. | 10:10 |
| cking | smb: ^^ may be worth checking the P_LVLx_LAT values in the FADT too | 10:10 |
| smb | The system does not seem to define any C2 or C3, so be compliant what I take from glancing over the comments. | 10:12 |
| Chrom_ | hi all | 11:48 |
| Chrom_ | hey guys, did anybody try to dist-upgrade jaunty today? there-s a leftover package that prevents linux-restricted-modules-generic to be installed | 11:49 |
| gigasoft | i have problem with Workspace Switcher, how to reinstall it or install another one | 12:19 |
| amitk | gigasoft: and how is that related to the kernel? :) | 12:21 |
| ogra | amitk, modprobe new-workspace.ko :P | 12:21 |
| amitk | please try #ubuntu | 12:21 |
| gigasoft | i do not know | 12:21 |
| ogra | yeah | 12:21 |
| ogra | #ubuntu for support is the right place | 12:22 |
| gigasoft | thanks anyway | 12:22 |
| gigasoft | bue | 12:22 |
| gigasoft | bye | 12:22 |
| _ruben | heh | 12:27 |
| apw | ikepanhc, you about today? | 13:07 |
| ikepanhc | apw: what? | 13:07 |
| apw | hi, was just looking at a bunch of intel graphiscs issues, and see you have the A17 swizzle bug. wondering what you are doing with it, which patch you are going to propose for sru | 13:08 |
| ikepanhc | eh, bad, I almost forget that. sorry. Do it as highest priority | 13:10 |
| apw | ikepanhc, no problem. i can just as easily do it if you arn't activly doing it now | 13:10 |
| ikepanhc | Thanks, I think I can do it today | 13:11 |
| apw | i assume you were going to propose this patch: http://launchpadlibrarian.net/24790669/i915-gem-disable.patch | 13:12 |
| ikepanhc | eh? I prepare to cherry-pick from upstream: 280b713b5b0fd84cf2469098aee88acbb5de859c | 13:13 |
| apw | that is a pretty huge commit ... | 13:13 |
| ikepanhc | Yes it is :-( | 13:14 |
| apw | from what i read the alternative is to allow gem to be disabled, using that other patch. that might be more appropriate for sru | 13:15 |
| ikepanhc | I think I shall look at the thread again | 13:15 |
| apw | ok | 13:15 |
| ikepanhc | Last time I look at the thread, they said the mainline build which has the commit works fine. | 13:16 |
| apw | yeah, but the patch doesn't just cherry-pick, and its pretty big. your call if you think its worth trying the backport | 13:17 |
| ikepanhc | But we need the shortest commit, am I right? | 13:17 |
| apw | smaller means less risk of regressions, and regressions for previously unaffected users are something to avoid for sure | 13:17 |
| ikepanhc | Hmmm, checking the thread again. | 13:19 |
| ikepanhc | apw: so, we have a huge commit with proper fix and another simple patch but not proper fix | 13:44 |
| apw | yep thats the one | 13:45 |
| ikepanhc | ya, I think simple is the best :-D | 13:45 |
| apw | smb, you wanted to have a link to the mtrr test kernels, they can be found here: https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/314928/comments/54 | 13:56 |
| ubot3 | apw: Error: Could not parse data returned by Malone: The read operation timed out | 13:56 |
| smb | apw, cool, will test | 13:56 |
| * apw spanks ubot3 | 13:56 | |
| apw | smb, i am going a bit mad ... any idea which damn applet does volume? | 16:13 |
| apw | ie which one converts alsa changes into an OSD? | 16:13 |
| smb | no, sorry no idea. I would try #ubuntu-devel... | 16:14 |
| johanbr | I don't think that's an applet. That's just some core component of gnome (gnome-settings-daemon?). | 16:22 |
| === thunderstruck is now known as gnomefreak | ||
| === awe is now known as awe-lunch | ||
| === awe-lunch is now known as awre | ||
| === awre is now known as awe | ||
| awe | sconklin: ping | 20:24 |
| sconklin | awe: hello | 20:25 |
| awe | hey was wondering if you saw rtg's reply to my SRU for the broadcom wl driver. are we going to create netbook-lpia branches for the lrm git trees? | 20:25 |
| rtg | awe: haven't the ABI's already diverged? | 20:26 |
| sconklin | hmm. Was that request for the driver to go into lrm? The way the request was made it would apply to the main hardy distro kernel | 20:27 |
| awe | rtg: I think so, but I didn't check... | 20:27 |
| sconklin | I think it should go into lrm. | 20:28 |
| awe | sconklin: yes, since cking and I get notified whenever a new version is released, I decided I'd handle it across all releases. | 20:28 |
| awe | sconklin: it's already in lrm, this is an update | 20:28 |
| rtg | sconklin: drop it on master, SRU it, then cherry-pick to netbook-lpia ? | 20:28 |
| awe | sconklin: I still need to do an SRU for intrepid and jaunty | 20:28 |
| sconklin | rtg: that's what I assumed when you pointed him at srb, but I wanted to make sure | 20:29 |
| awe | rtg: OK, so if I handle the SRUs, then sconklin can cherry pick? | 20:29 |
| sconklin | awe: yes | 20:29 |
| awe | cool | 20:29 |
| rtg | awe: yeah, what sconklin said | 20:29 |
| sconklin | awe: but it never hurts to bug me and make sure I don't miss it | 20:30 |
| awe | rtg: also, one other thing that concerns me is that our change to using git has made the process of upgrading to a new version more error prone. | 20:30 |
| awe | rtg: the ACK process alone doesn't really ensure that I haven't made a mistake in untar'ing / manual manipulation required | 20:31 |
| sconklin | awe: on another topic . . . when can we sync up your dennis branch in lum into our repo, and possibly combine it with the netbook-lpia branch? | 20:31 |
| awe | rtg: perhaps I should ask someone like cking to verify out-of-band that it looks right? | 20:31 |
| rtg | awe: thats a good idea, though I don't see how git could but help. you can at least see whats changed. | 20:32 |
| awe | rtg: it doesn't help... colin would need to validate the git tree against the zip from broadcom | 20:33 |
| awe | sconklin: it's on my list. I promise I'll get the patch requests sent out before next week's kernel mtg. | 20:33 |
| sconklin | awe: as long as you're on it - you're the one mostly affected, and you are aware of the (6 or so patches) delta between your branch and ours. | 20:34 |
| awe | sconklin: I'm actually working on the desktop team for the karmic cycle, and am still trying to get my bearings | 20:34 |
| sconklin | awe: I completely understand | 20:34 |
| awe | sconklin: I am aware of it, and it's at the top of my list post updating the wl driver | 20:34 |
| rtg | awe: we've unrolled the zip in Hardy LRM. I'm not sure wherein lie your concerns. | 20:35 |
| * awe beats himself over the head for volunteering to upgrade the 'wl' driver | 20:35 | |
| rtg | awe: c'mon, it can't take 10 minutes. | 20:36 |
| awe_ | rtg: sorry 'bout that... !@#% X lockup/crash... | 20:40 |
| awe_ | rtg: anyways. ot | 20:40 |
| awe_ | it's not the simple. we used to be able to just copy the new tarballs in place and tweak the rules | 20:40 |
| awe_ | now, since any patches we have are applied as commits, we have to untar, re-apply the patches ( MODULE_LICENSE / Makefile ) | 20:41 |
| awe_ | ...then copy the architecture-specific binary files into place ( they're now suffixed with the arch ) | 20:41 |
| awe_ | it's not hard, just alot of manual steps...which makes it error prone | 20:42 |
| rtg | awe: what about carrying the patches in the patches directory like we used to? | 20:42 |
| rtg | that seems to have disappeared. hmm | 20:43 |
| awe_ | yup | 20:43 |
| rtg | awe: I see your point. | 20:43 |
| awe_ | ;) | 20:43 |
| rtg | lemme annoy smb about it a little. | 20:43 |
| awe_ | OK, should I hold off on the SRU for intrepid / jaunty then? | 20:44 |
| rtg | yeah, lets get that sorted first. | 20:44 |
| awe_ | sounds good | 20:45 |
| === awe_ is now known as awe | ||
| sconklin | awk has damaged me | 20:45 |
| awe | isn't that a song by your buddies from brooklyn? ;) | 20:47 |
| sconklin | awe: something like that. they damaged me too :) | 20:48 |
| === awe is now known as awe-afk | ||
| === awe-afk is now known as awe | ||
| rtg | awe: what patches are we carrying 'out-of-band' for Broadcom wl? | 21:07 |
| awe | there's used to be a Makefile patch and a vlan patch ( which also included the MODULE_LICENSE update ) | 21:08 |
| rtg | awe: i think the vlan patch was eventually accepted by Broadcom | 21:08 |
| awe | vlan has been fixed in the driver, however the MODULE_LICENSE still needs to be set, so that should get rolled into it's own patch | 21:09 |
| rtg | awe: do you have the MODULE_LICENSE patch somewhere? | 21:10 |
| awe | I applied it directly as a commit in my tree referenced in the SRU request | 21:10 |
| rtg | awe: k, lemme look | 21:11 |
| awe | hmmm...actually maybe it wasn't a separate commit | 21:11 |
| rtg | awe: it would help if it was. could you extract it? | 21:11 |
| awe | I do have a version of the patch for our dennis-specific lrm | 21:11 |
| pace_t_zulu | anyone running karmic as a virtual machine experiencing lockups since 2.6.30 was installed? | 21:22 |
| rtg | awe: I've responded to your LRM patch request. I'm outta here. beers await. | 21:51 |
| awe | rtg: thanks dude. sake for me shortly... ;) | 21:53 |
| samourai_41 | Slt | 21:55 |
| === matt64- is now known as erle- | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!