[09:35] <laga> hum. i wonder if canonical could throw some money at the aufs guy. he's apparently unemployed and he just sent a request for donations to the aufs-users mailing list.
[09:35] <laga> of course, gregkh won't count that towards upstream contributions ;)
[12:17] <balbir> Hi, Looking for some help with whom to ask about enabling a kernel option/feature (bugzilla?)
[12:50] <abogani> balbir: Kernel team mailing-list should be the right place.
[14:03] <TheMuso> ./c
[14:43] <balbir> abogani: Thanks, I was away for a while, just saw your response
[15:11] <munckfish> smb_tp: Is linux-ports-meta going to be "in" the beta?
[15:23] <Ben1> rtg, amitk, smb_tp, cking: fyi, while working on crashdump, I totally boogered my hd, so I
[15:23] <Ben1> 'm on a tmp system till I get things sorted out
[15:24] <rtg> BenC: sucks to be you :)
[15:24] <cking> BenC: owch. virtualbox is your friend
[15:24] <BenC> cking: vbox kernel module is crashing under 2.6.27 :/
[15:24] <munckfish> rtg: With whats included in linux-ports now I'd be happy to upload it in order to catch the beta.
[15:25] <munckfish> if that's possible.
[15:25] <rtg> BenC: ^^^ thats a universe package, right?
[15:25] <cking> BenC: really? I'm running virtualbox 2.0.2 on 2.6.27-3 fine yesterday
[15:25] <BenC> rtg: no
[15:26] <BenC> cking: 64-bit?
[15:26] <cking> yep. with all the fancy virtual assistance modes on too
[15:27] <cking> ..ah.. let's clarify: 64 bit host, 32 bit virtual
[15:27] <rtg> BenC: ok, I've never built the ports package on the buildd. Is there anything special about it, or is it just a straightforward upload to ubuntu?
[15:27] <BenC> cking: I was using the kernel module source in the repo and the module would crash on load
[15:28] <munckfish> Does anyone konw anything about linux-ports-meta and whether it's likely to be included?
[15:28] <munckfish> I believe people are still having to manually select kernel to use on install
[15:28] <BenC> rtg: straight forward...same as regular kernel
[15:28] <BenC> I thought smb did the linux-ports-meta
[15:29] <rtg> BenC: HE MAY HAVE. i'LL GET IT SORTED OUT.
[15:29] <rtg> whoops.
[15:29] <smb_tp> munckfish, BenC I did the preparations but I am missing the step to get it into beta
[15:29] <cking> ..I just downloaded the VirtualBox 2.0.2 deb file (Hardy version), downloaded the kernel headers and installed the deb file - and I'm running Alpha 6 32 bit server fine in it
[15:29] <smb_tp> rtg, No need to shout. I hear. :)
[15:29] <rtg> har, har
[15:30] <smb_tp> rtg, Who would I have to bug to get linux-ports-meta into the beta
[15:31] <rtg> smb_tp: me or BenC I guess.
[15:31] <smb_tp> rtg, Ohhh! >:-)
[15:31] <BenC> since my gpg key is in an unknown state, that means rtg
[15:31] <rtg> smb_tp: if you wanna package the ports kernel and meta, just lemme know when your done.
[15:33] <smb_tp> munckfish, You had worked on the ports source?
[15:33] <munckfish> smb_tp: yes
[15:33] <munckfish> added some PS3 specific changes
[15:34] <smb_tp> munckfish, So that is all in the repo now and we could try to package that
[15:34] <BenC> smb_tp, rtg: For ports, I would follow an always-bump-abi upload rule
[15:34] <munckfish> smb_tp: yep
[15:34] <munckfish> BenC: may I ask why?
[15:35] <munckfish> is that to prevent wasting time?
[15:35] <rtg> munckfish: makes it easier to revert to a previous kernel.
[15:35]  * BenC wonders whos long brown hair he keeps pulling out of his pocket
[15:35] <munckfish> ah ok I see
[15:35] <rtg> BenC: too much info.
[15:35] <laga> BenC: was she pretty?
[15:36] <laga> cops usually have short hair, so we can rule that out.
[15:36] <BenC> I surely hope so
[15:36] <BenC> hehe
[15:36] <munckfish> BenC: I thought you had long hair?
[15:36] <BenC> munckfish: not since a year ago
[15:36] <munckfish> http://behindubuntu.org/interviews/BenCollins/
[15:36] <munckfish> ah ok
[15:36] <munckfish> getting less rock'n'roll?
[15:37]  * munckfish used to have long hair too and knows what it feels like to lose it
[15:37] <BenC> getting more single and need to be clean cut :)
[15:37] <BenC> I saved the pony tail in a bag....wanna buy it?
[15:38] <rtg> man, thats just gross.
[15:38] <laga> 7msg BenC i'll buy it for rtg
[15:39] <BenC> rtg: you know you offered me $20 for it :)
[15:39] <BenC> I'm pretty sure I've thrown it away by now
[15:39] <rtg> huh, on that note I think I'll go make some breakfast. biab.
[15:39] <BenC> just took longer to let go of it than it did to cut it off
[15:39] <laga> so, would canonical like to donate to the aufs author? (no, it's not met)
[15:39] <laga> s/met/me/
[15:40] <BenC> laga: if he's willing to do a full on merge to upstream, maybe
[15:40] <BenC> but not anytime soon
[15:40] <laga> BenC: upstream won't accept unionfs or aufs AFAIK
[15:41] <BenC> laga: not much point then :/
[15:41] <laga> but yeah, i was just wondering if canonical had a policy on such things. i didn't mean to spam the channel ;)
[15:41] <BenC> that would be the gain for us, not having to maintain it out-of-tree
[15:42] <laga> to be fair, the gain right now is that it actually works ;)
[15:47] <BenC> For our purposes, so does unionfs 1.4
[15:47] <BenC> but users want features in aufs, so we've moved on to that
[17:48] <munckfish> smb_tp: if you need to contact me about any issue with the ports build I'll be unavailable till about 23:00 UTC
[17:48] <munckfish> I'll try to check my mail then
[17:48] <munckfish> but also in the morning too.
[17:48] <smb_tp> munckfish, ok
[17:48] <munckfish> bfn
[17:49] <munckfish> oh my email is
[17:49] <munckfish> lists@munckfish.net or the one in my commits
[17:49] <munckfish> bfn
[18:15] <Zhenech> heya guys
[18:21] <Zhenech> i'm the maintainer of tp-smapi in debian and would like to know why you decided to patch tp-smapi into your kernels
[18:21] <Zhenech> rather then providing modules packages as we do
[18:22] <Ben1> tp-smapi?
[18:23] <Zhenech> BenC, yeah, thinkpad smapi driver for querying the EC
[18:25] <BenC> Zhenech: remind me what that is
[18:25] <BenC> Zhenech: but the short answer would probably be because we didn
[18:25] <BenC> 't want to have to have ppl install a separate package
[18:26] <Zhenech> ibm/lenovo thinkpads have an embedded controller, which can e.g. controll the charging of the battery
[18:26] <Zhenech> tp-smapi offers a interace to these settings
[18:26] <Zhenech> (http://www.thinkwiki.org/wiki/Tp_smapi)
[18:27] <BenC> then my answer stands...tighter bindling helps us keep it stable
[18:27] <pwnguin> laga: don't worry, im sure greg k-h will hire him! gregk-h promised there were jobs just waiting for kernel hackers
[18:28]  * Zhenech fetches your kernel git
[18:29] <BenC> is it such a bad thing that we do that?
[18:29] <BenC> *bundling
[18:29] <IntuitiveNipple> Benc: l-u-m commit 2e0a73b13cfe2c8c2d620b46a74013435e30c18b
[18:31] <Zhenech> BenC, well, I probably won't do that, but it's not as bad that it could break something easily (besides of compilation of the kernel itself)
[18:32] <Zhenech> BenC, but its kinda not usefull for people who dont know the interface (and I'm waiting for git to look which docs you ship)
[18:33] <BenC> Zhenech: we likely don't ship the docs....we include it for things like acpi-support to use, IIRC
[18:33] <Zhenech> there is no acpi support in tp-smapi
[18:33] <Zhenech> thats what thinkpad-acpi is for
[18:33] <Zhenech> and that is in linus tree
[18:34] <Zhenech> the only two things tp-smapi does is battery info/control and better hdaps sensor readings
[18:35] <BenC> I mean for userspace to use, but not the user directly
[18:36] <Zhenech> ah you mean the acpi-support package
[18:37]  * Zhenech looks at the source
[18:38] <BenC> then it's probably used by hal
[18:40] <BenC> right
[18:46] <Zhenech> BenC, you dont ship hdaps_ec anymore?
[18:48] <IntuitiveNipple> For Hardy, it's in l-u-m ubuntu/hwmon/
[18:48] <IntuitiveNipple> see the l-u-m commit I mentioned earlier
[18:48] <Zhenech> IntuitiveNipple, but not for intrepid?
[18:51] <Zhenech> there is no l-u-m for intrepid as far i can see
[18:55] <rtg> BenC: did we get a new compiler version in Intrepid? I'm getting ABI errors on memcpy using the ABI files you commited for 2.6.27-4.5
[18:58] <BenC> weird
[18:58] <BenC> not that I know of
[19:00] <rtg> BenC: it is weird. I can't rebuild the version I successfully uploaded just last night. hmmm
[19:00] <IntuitiveNipple> Zhenech: I don't see it in the logs, for ubuntu-intrepid or ubuntu-intrepid-ports. u-i-p has what looks at first glance like a duplicate drivers/hwmon/hdaps.c
[19:02] <Zhenech> IntuitiveNipple, drivers/hwmon/hdaps.c is the in-kernel hdaps driver (at least it looks like it)
[19:02] <IntuitiveNipple> Zhenech: yeah, thats what I said. It looks to be a dupe of the one in u-i  ... I'm just waiting for an update to finish so I can't diff the two repos right now (plus I'm stuffing a chicken!)
[19:04] <Zhenech> ok
[19:06] <IntuitiveNipple> BenC: is it possible u-i commit ed464174f93b accidentally left out hardy l-u-m ubuntu/hwmon/hdaps_ec.c ?
[19:11] <rtg> Ng: what display graphics do you have on your e1000e based machine?
[19:13] <mjg59> rtg: He's got an X3100-based system
[19:13] <mjg59> 965GM
[19:14] <rtg> mjg59: I was following up on Jiri's comment on LKML that so far all affected machines appear to be i965
[19:15] <smb_tp> IntuitiveNipple, The hdaps_ec came from the thinkpad smapi package. I am not sure why it is in u-i-p but not in u-i
[19:26] <smb_tp> CarlFK, There have been C1E news upstream. Put a new kernel to the usual place to try.
[19:28] <CarlFK> smb_tp:  on my way
[19:29] <IntuitiveNipple> smb_tp: The u-i-p  hdaps.c is an older version than the one in u-i (has some newer IDs added). The hardy l-u-m hdaps_ec.c has some significant differences to hdaps.c (from the tp_smapi-0.36 source tarball). I wonder if those difference ought to be integrated or are no longer necessary/
[19:30] <Zhenech> they should be intrgrated imho (but from 0.37 tp-smapi source)
[19:30] <Zhenech> afk, food :)
[19:31] <smb_tp> IntuitiveNipple, The one from tpsmapi had some improvements regarding to some axis inversion. And it worked together with tp_smapi trhough the common ec driver. otherwise one one can be loaded. I have to check how well the kernel one does
[19:32] <CarlFK> smb_tp: what kernel params should I be using? currently doing apic=debug debug
[19:33] <smb_tp> CarlFK, Just leave it that way, but frankly, from the changes I very much hope this is not needed and boot goes smoothly
[19:33]  * smb_tp knows he said so before...
[19:33] <CarlFK> I was wondering when you were hoping for problems :)
[19:34] <smb_tp> CarlFK, Who ever is hoping for them. :)
[19:35] <IntuitiveNipple> smb_tp: is it worth mailing-list post just so it is on the radar?
[19:40] <smb_tp> IntuitiveNipple, I believe it is worth it. Might also be worth to see why this doesn't get into upstream
[19:40] <IntuitiveNipple> okay... I have no idea about it but since I've just tracked all the changes I'll post one before I forget so others can consider it
[19:41] <smb_tp> IntuitiveNipple, Ok, thanks
[19:43] <CarlFK> smb_tp: it paused... will post dmesg
[19:45] <smb_tp> CarlFK, *argh* Oh well, so I can just re-add my debugging messages...
[19:46] <CarlFK> so that's why it didnt work... you angered the debug gods 
[19:47] <laga> pwnguin: haha
[19:47] <smb_tp> CarlFK, Looks like it. Alright, lets add so much debugging the system is near paused by them. ;-)
[20:06] <CarlFK> smb_tp: do you want dmesg now, or wait for the extra debugging ?
[20:07] <smb_tp> CarlFK, Wait for the extra debugging. I don't expect much change in the current dmesg
[21:52] <smb_tp> CarlFK, Ok, there is a 4-6smb2 now and it should please the debug gods. If that pauses you probably have to write down the previous messages as far as they are visible... It is really noisy
[21:59] <CarlFK> on my way
[23:11] <CarlFK> smb_tp: it overflowed the dmesg buffer :/
[23:12] <smb_tp> CarlFK, Did it pause somewhere before?
[23:12] <CarlFK> nope
[23:12] <CarlFK> im posting what I have - might be useful 
[23:13] <smb_tp> CarlFK, the enter and exit broadcast might be just too much... Ok, thanks
[23:13] <CarlFK> http://launchpadlibrarian.net/17938610/dmesg24ck.txt
[23:15] <CarlFK> [    2.595651] hpet_resources: 0xfed00000 is busy
[23:17] <CarlFK> that's the onlything I find interesting but I don;t know what to look for :)
[23:25] <smb_tp> CarlFK, No there isn't really much to see. I remove the noisy ones and put that up later
[23:36] <smb_tp> CarlFK, What seems to be useful: both cpus were not in broadcast while that pause between 3 and 17 secs happened.
[23:38] <CarlFK> every little bit helps 
[23:41] <smb_tp> CarlFK, It surely does. This was again the first stall (before marking tsc unstable)? And you pressed a key after some time.
[23:41] <CarlFK> yep - actually plugged in AC
[23:42] <CarlFK> pluggin in AC keeps me from having to hold down a key to get it past the other pauses 
[23:43] <smb_tp> CarlFK, Does that mean plugging in AC somehow prevents the other pauses, while pressing a key has to be repeated?
[23:43] <CarlFK> right
[23:43] <CarlFK> if I hold down the shift key, (or probably any other key) it doesnt pause 
[23:44] <CarlFK> i don't know if it is keyrepeat or what
[23:44] <CarlFK> starting the boot with AC plugged in still pauses
[23:44] <CarlFK> at the same place 
[23:45] <smb_tp> CarlFK, Might be something like this. And plugging in the AC maybe triggers some charging updates...
[23:46] <mjg59> Does plugging in AC change the available C states?
[23:46] <CarlFK> but it doesn't explain the initial pause if it is already on AC
[23:46] <mjg59> /proc/acpi/processor/*/power would tell you
[23:46] <mjg59> CarlFK: Until the processor module is loaded, C state behaviour may be different
[23:47] <smb_tp> mjg59, CarlFK might be something to follow. Since it is clear now that at least the cpus have not gone into an idle state during that time
[23:48] <smb_tp> So maybe C1E is not at fault there...
[23:48] <CarlFK> http://dpaste.com/80368/ /proc/acpi/processor/CPU0/power  
[23:48] <mjg59> CarlFK: Is that on AC or DC?
[23:48] <CarlFK> ac
[23:48] <mjg59> And on battery?
[23:49] <CarlFK> http://dpaste.com/80370/  both 
[23:50] <mjg59> Huh. It's never going into C2 or C3 anyway.
[23:50] <mjg59> Which sounds like some different type of failure