[09:16] <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:17] <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:18] <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:19] <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:20] <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:21] <smb> and Zero instead of 0x00 and renames like \_PR to _PR (which looks slightly wrongish to me)
[09:23] <cking> I'm googling for some info..
[09:28]  * apw plays the countdown clock tune in the backgroun
[09:32]  * cking is now reading some pdfs..
[09:34] <hughhalf> o
[09:38]  * smb is scared of what he has done...
[09:43] <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:46] <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:47] <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:48] <smb> apw, I don't think so. Hard to tell under that pile of comments... nope, does not look like it
[09:49] <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:50] <smb> Yeah, and in the mean time some of those just gather a lot of other drifts
[09:52] <apw> you just know its going to be a 2 line quirk once its found
[09:53] <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:54] <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:55] <smb> It can be the same or various things
[09:56] <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:57] <smb> Best action is to try to dig into that with that one system I got with that problem...
[09:58]  * cking agrees
[10:00] <smb> Ok, that would be a system which defines a register block only for CPU0 (on a amd dual core)
[10:04] <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:05] <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:06] <cking> I like the comment "I will never again buy any AMD product "
[10:09] <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:10] <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:12] <smb> The system does not seem to define any C2 or C3, so be compliant what I take from glancing over the comments.
[11:48] <Chrom_> hi all
[11:49] <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
[12:19] <gigasoft>  i have problem with Workspace Switcher, how to reinstall it or install another one
[12:21] <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:22] <ogra> #ubuntu for support is the right place
[12:22] <gigasoft> thanks anyway
[12:22] <gigasoft> bue
[12:22] <gigasoft> bye
[12:27] <_ruben> heh
[13:07] <apw> ikepanhc, you about today?
[13:07] <ikepanhc> apw: what?
[13:08] <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:10] <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:11] <ikepanhc> Thanks, I think I can do it today
[13:12] <apw> i assume you were going to propose this patch: http://launchpadlibrarian.net/24790669/i915-gem-disable.patch
[13:13] <ikepanhc> eh? I prepare to cherry-pick from upstream: 280b713b5b0fd84cf2469098aee88acbb5de859c
[13:13] <apw> that is a pretty huge commit ... 
[13:14] <ikepanhc> Yes it is :-(
[13:15] <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:16] <ikepanhc> Last time I look at the thread, they said the mainline build which has the commit works fine.
[13:17] <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:19] <ikepanhc> Hmmm, checking the thread again.
[13:44] <ikepanhc> apw: so, we have a huge commit with proper fix and another simple patch but not proper fix
[13:45] <apw> yep thats the one
[13:45] <ikepanhc> ya, I think simple is the best :-D
[13:56] <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
[16:13] <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:14] <smb> no, sorry no idea. I would try #ubuntu-devel...
[16:22] <johanbr> I don't think that's an applet. That's just some core component of gnome (gnome-settings-daemon?).
=== 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
[20:24] <awe> sconklin: ping
[20:25] <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:26] <rtg> awe: haven't the ABI's already diverged?
[20:27] <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:28] <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:29] <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:30] <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:31] <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:32] <rtg> awe: thats a good idea, though I don't see how git could but help. you can at least see whats changed.
[20:33] <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:34] <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:35] <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:36] <rtg> awe: c'mon, it can't take 10 minutes.
[20:40] <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:41] <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:42] <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:43] <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:44] <awe_> OK, should I hold off on the SRU for intrepid / jaunty then?
[20:44] <rtg> yeah, lets get that sorted first.
[20:45] <awe_> sounds good
=== awe_ is now known as awe
[20:45] <sconklin> awk has damaged me
[20:47] <awe> isn't that a song by your buddies from brooklyn?  ;)
[20:48] <sconklin> awe: something like that. they damaged me too :)
=== awe is now known as awe-afk
=== awe-afk is now known as awe
[21:07] <rtg> awe: what patches are we carrying 'out-of-band' for Broadcom wl?
[21:08] <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:09] <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:10] <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:11] <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:22] <pace_t_zulu> anyone running karmic as a virtual machine experiencing lockups since 2.6.30 was installed?
[21:51] <rtg> awe: I've responded to your LRM patch request. I'm outta here. beers await.
[21:53] <awe> rtg: thanks dude.  sake for me shortly...  ;)
[21:55] <samourai_41> Slt
=== matt64- is now known as erle-