[02:13] <JFo> baptistemm, apologies, I got pulled away doing a favor for a friend
[02:16] <JFo> will chat with you tomorrow
[02:23] <AceLan> cooloney: should I file a new bug for the ftrace config changes?
[02:23] <AceLan> cooloney: or just give you the patch?
[02:31] <cooloney> AceLan: great, please file a new bug and send me the patch?
[02:48] <AceLan> cooloney: got it
[02:49] <cooloney> AceLan: thanks a lot. 
[03:26] <cooloney> AceLan: could you give me a hand
[03:26] <cooloney> AceLan: please try to set the mac address on your fsl-imx51 hardware
[03:27] <cooloney> AceLan: maybe that will cause kernel panic
[04:00] <AceLan> cooloney: yo
[04:01] <AceLan> cooloney: my fsl-imx51 h/w doesn't have fec, only wireless
[04:08] <cooloney> AceLan: oh, too bad
[08:27] <smb> moin
[08:33] <smb> psurbhi, morning, have you seen the mail from kees ?
[08:33] <psurbhi> smb, no
[08:33]  * psurbhi checks
[08:33] <psurbhi> smb, morning :)
[08:34] <smb> psurbhi, He has found some problems with your sync patch apparently
[08:34] <psurbhi> smb, ok
[08:34] <psurbhi> let me check..
[08:42]  * smb good-mornings cking 
[08:42] <cking> hiya
[08:43] <cooloney> morning smb psurbhi and cking 
[08:43]  * abogani waves
[08:43] <psurbhi> hi cooloney, cking
[08:45] <smb> Hey abogani. Reminds me you asked for some sponsoring and a forgot. You got a page somewhere I could add things to?
[08:45] <smb> I forgot, even
[08:45] <smb> Heya apw 
[08:46] <apw> smb, morning you ... 
[08:46]  * apw waves to psurbhi 
[08:47]  * psurbhi waves back to apw
[08:48] <cooloney> apw: morning, 
[08:48] <abogani> smb: The link is https://wiki.ubuntu.com/AlessioIgorBogani/linux-rtPPUApplication. It isn't really necessary anymore because DMB have choosen to refuse me upload rights on linux-rt package. Evidently more than 3 years of work and 7 Ubuntu supported releases don't matter nothing :-)
[08:48] <apw> o/ cooloney 
[08:49] <apw> abogani, have people been uploading it for you as in sponsoring the uploads though?
[08:50] <psurbhi> smb, thanks for pointing this out
[08:50] <abogani> smb: In any case I really appreciate your comments about me and my work. In this I can bring up my moral (if comments are positive obviously) :-)
[08:50] <smb> abogani, Hm, sad. What exactly was their reasoning?
[08:50] <abogani> apw: Since Intrepid Luke Yelavich
[08:50] <abogani> smb: No one sponsor me.
[08:50] <apw> abogani, thought as much ...
[08:51] <apw> so was it just lack of sponsors getting behind you, probabally need some social engineering to line them up before hand
[08:51] <smb> abogani, Doh. Well on my side it was mainly because timing and forgetting
[08:51] <smb> close to release and some sprints
[08:52] <abogani> smb: No worry I know that you (like other UKT members are really busy).
[08:52] <abogani> apw: I'm starting to think that linux-rt don't have a lot of users... :-|
[08:53] <mase_wk> hmm maybe i should try the RT kernel
[08:53] <mase_wk> never really looked at it
[08:53]  * abogani wonders if someone of UKT would want "adopt" linux-rt package.
[08:54] <smb> abogani, You usually find out one hour after removing the package completely :-P
[08:54] <abogani> smb: Indeed
[08:54] <smb> abogani, No thank you. Its nothing about the package, but I already have enough O_o
[08:55] <abogani> smb: :)
[08:57] <apw> abogani, busy for release for sure, and a lot of traveling about just there as well, and ash clouds and ... mad times indeed
[08:58] <cking> don't mention the a** word
[09:00] <abogani> apw: Thanks anyway. As I already said above I know than you really are busy.  :-)
[09:00] <smb> cking, the v* word then?
[09:00] <cking> volcano is fine by me ;-)
[09:01]  * smb pictures an eruption under cking 's chair
[09:04] <cking> that's not a particularly pleasant image
[09:05] <abogani> smb: Please don't forget to add sponsor to above mentioned wiki page... I really appreciated it :-)
[09:06] <smb> cking, No. But you mentioned the v* word. Well, I hope for the best. Lucky you don't fly to UDS. I heard some closures in Ireland and Scotland have been done
[09:06] <smb> abogani, I try to finally remember this time.
[09:11] <psurbhi> apw, we could give btrfs as an experimental support in maverick
[09:12] <apw> smb, maybe a*h down here this afternoon ...
[09:12] <cking> urk
[09:12] <apw> psurbhi, we generally don't offer installs on EXPERIMENTAL marked  filesystems, the major barrier is whether the on disk format has stopped changing or not
[09:13] <psurbhi> though the wiki says it has not, it seems it has
[09:13] <psurbhi> but we would find out later if it changes.. as of now.. it does not seem to have changed for a long time
[09:13] <apw> i think that may be a gating issue, if they have stopped changing it, we may be able to offer it as a 'at your own risk' job
[09:13] <psurbhi> the wiki says "its still experimental and susceptible to change"
[09:14] <psurbhi> apw, yes! 'at your own risk' exactly
[09:14] <apw> a UDS topic for sure, to work out the constraints on whether we can and get people to go investigate them
[09:16] <psurbhi> ya
[09:17] <apw> psurbhi, i note that there is an upstream potential fix in that mainline bug linked from the unmount is a slow as snot bug we were just discussing
[09:17] <apw> you might want to revert our patch and shove that on and test the result
[09:18] <psurbhi> apw, ok.. for lucid?
[09:18] <psurbhi> or for maverick?
[09:19] <psurbhi> apw, i mean do we revert it for lucid too?
[09:19] <smb> psurbhi, for lucid as your workaround probably has not been copied to maverik, but otherwise both
[09:19] <psurbhi> smb, ok
[09:20] <apw> psurbhi, the important thing at this stage is to get the suggested patch tested
[09:20] <smb> psurbhi, That is the thing you wanted to check when i asked about kees mail. Remember? ;-)
[09:20] <psurbhi> smb, thats what started the discussion :)
[09:21] <apw> and report back in the upstream bug if it works for you, perhaps get kees to test as well as he has some more test cases
[09:21] <psurbhi> thanks for that
[09:21] <psurbhi> apw, the suggested patch ?
[09:21] <psurbhi> apw, ya.. get it
[09:22] <psurbhi> i will do it and report back
[09:30] <apw> psurbhi, most excellent
[10:10] <apw> pgraner, about?
[10:11] <pgraner> apw: yep
[10:33]  * cking notes that w/o wiggle my life would be painful
[10:35] <apw> cking, it is a blessing indeed
[10:35] <apw> RAOF, hey ...
[10:56] <apw> cking, can you remind me the incantation on the new CD's to get to nomodeset?
[10:59] <apw> you hit a key in that initial purple thing don't you
[11:18] <cking> apw, nay, cannot remember the key 
[11:19] <cking> apw, to get to grub? or what?
[11:19] <apw> no when we had the new CDs they go purple with a strange thingy at the bottom then boot i think, if you do something while the odd thingy is visible you get the older menu with function keys
[11:20] <cking> press enter?
[11:25] <apw> possible will have to make a cd to be sure
[11:36] <cking> sigh, another day, another ACPI bug...
[11:39] <cking> 3 cheers for acpiexec - the tool that allows me to single step AML 
[11:56] <apw> cking, sounds amazing ... whos is that?
[11:58] <cking> apw, http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html
[11:59] <apw> cking, geek
[11:59] <cking> yep
[12:00]  * apw notes the greeks are attacking their own parliament
[12:01] <cking> politics the greek way
[12:01] <apw> they seem more militant than usual ... lots of throwing things at the moment
[13:35] <h00k> I am not familiar with the innerworkings of the kernel, but I'm seeing this in dmesg, I'm just wondering what it means: CE: hpet increasing min_delta_ns to 33750 nsec
[13:37] <h00k> Turns out there is bug 270798 related to it.
[13:37] <ubot3> Malone bug 270798 in linux "lockups with default (hpet) clocksource on  2.6.27-2-generic 64-bit" [Medium,Confirmed] https://launchpad.net/bugs/270798
[13:37] <smb> h00k, Just that the hpet could not be programmed with a smaller interval and is now using a bigger one
[13:37] <h00k> smb: what is hpet?
[13:38] <smb> high precision event timer
[13:38] <h00k> alright
[13:38] <h00k> it appears to keep increasing and over time, my laptop gets slower. I guess I'll mark this bug as affecting me
[13:38] <smb> h00k, The successor of the old timer with a higher precision (and more bugs apparently )
[13:39] <h00k> smb: heh.
[13:39] <smb> Does it only show this message once or over and over with higher numbers?
[13:39] <h00k> No, over and over with higher numbers
[13:40] <h00k> 15000, 22500, 33750
[13:40] <h00k> so far, after 529 seconds of uptime.
[13:40] <h00k> http://pastebin.ubuntu.com/428263/ basically
[13:41] <h00k> 2.6.32-21-generic
[13:41] <smb> In theory it should stop at some point. But there might also be a chance that failing to program it is not because it needs more delay but for some other reason
[13:41] <h00k> I'll keep an eye out, I suppose
[13:42] <smb> Yeah, if it stays at a certain number it still might be ok
[13:43] <smb> Not having looked into the bug above I am not sure what lockup means in that context
[13:44] <h00k> I'll see what it ends up doing after today.
[13:44] <smb> ... and seeing 2.6.27 as the start of it, I wonder whether it would not make sense to open a new bug for 2.6.32 problems
[13:44] <h00k> If it keeps increasing? Should I open something new?
[13:44] <h00k> Ah, okay.
[13:44] <smb> h00k, If it never stops I definitely would open a new thing
[13:45] <h00k> smb: oh, upstream might be aware: https://bugzilla.kernel.org/show_bug.cgi?id=14426
[13:45] <ubot3> bugzilla.kernel.org bug 14426 in Realtime Clock "CE: hpet increasing min_delta_ns flood" [Normal,New] 
[13:46] <smb> h00k, Ok, so if you want to open a lp bug make sure to link the upstream bug to it
[13:46] <smb> If there is not already one linked
[13:46] <smb> somewhere else
[13:46] <h00k> alright, i'll check
[13:54] <h00k> I don't see anything on LP regarding this particular kernel, I'm opening a new bug and I'll link it upstream
[13:55] <smb> h00k, cool, thanks
[14:06] <h00k> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/575774
[14:06] <ubot3> Malone bug 575774 in linux "2.6.32-21-generic CE: hpet increasing min_delta_ns flood" [Undecided,New] 
[14:11] <bigcx2> hey all, is there a way to disable APIC in 2.6.32.11?
[14:11] <bigcx2> there's no option for it in menuconfig
[14:12] <bigcx2> and when i try to set CONFIG_X86_LOCAL_APIC as no in my config, as soon as i do make oldconfig it overwrites it with yes
[14:13] <bigcx2> and then, trying to set it as no in arch/x86/Kconfig makes my kernel build fail with
[14:13] <bigcx2> arch/x86/kernel/tsc.c: In function ‘unsynchronized_tsc’:
[14:13] <bigcx2> arch/x86/kernel/tsc.c:827: error: implicit declaration of function ‘apic_is_clustered_box’
[14:14] <bigcx2> the same thing happens with 2.6.32.7
[14:14] <mjg59> nolapic on the kernel command line
[14:14] <mjg59> Or noapic if you want to disable the i/o apic
[14:15] <bigcx2> mjg59: i tried that...the problem is i'm trying to build a RTAI kernel
[14:15] <bigcx2> and RTAI complains about it being enabled in the config and then not being available/enabled
[14:15] <bigcx2> so that doesn't work for me
[14:15] <bigcx2> so there's no way to build any of the latest kernels without apic?
[14:16] <bigcx2> that's what it looks like
[14:16] <mjg59> Only if you turn off SMP. But I believe that that's always been the case.
[14:17] <bigcx2> hm.
[14:17] <bigcx2> i don't need smp, lemme give that a shot
[14:17] <mjg59> Also, it has to be a 32-bit build
[14:17] <bigcx2> it is
[14:23] <bigcx2> mjg59: i think that worked, thanks
[15:04] <apw> psurbhi, hey ... that unmount patch upstream suggested, any idea when you might get that tested?
[15:04] <psurbhi> apw, i will do it today evening/today morning.. shall send it out soon
[15:05] <apw> psurbhi, cool, only as ask kees is asking about reverting the current work around as it has some other side effects he doesn't like, and if we make a change i'd like to do both together to make the SRU people not explode
[15:05] <psurbhi> apw, ack
[15:07] <pmatulis> is this the proper procedure for updating an initramfs using a live cd?:
[15:07] <pmatulis> boot, mount the partition containing /boot, mount it (say on /mnt), then 'chroot /mnt update-initramfs -u -k <kernel version>'
[15:07] <apw> smb, what was the thing about running update-initramfs which was 'negative' ?
[15:08] <smb> apw, Someone *claimed* it would then not be done on normal updates, but I really did not think this happened to me ever
[15:08] <apw> ah ok, then i suspect that is the right way to do it
[15:11] <pmatulis> what if /usr is on a separate partition?
[15:11] <smb> I thinks so. I don't see any reason why this should be bad, given that it initrd is _always_ automatically build this way. Maybe I am wrong but I have never received a good explanation on why
[15:11] <apw> gah, pmatulis you would need to mount all the normal things in there
[15:11] <apw> if /usr is separate mount that, likely you need to mount /proc too
[15:12] <smb> I guess at least proc and /dev too
[15:12] <apw> do people still split /usr these days?
[15:12] <pmatulis> apw: so enter chroot and then mount those partitions?
[15:12] <apw> yeah after the chroot
[15:12] <smb> apw, Sounds even more anal than I am
[15:12] <apw> indeed, something not to be tollerated :)
[15:13] <smb> Heh, well, maybe there could be reasons, like to make it ro
[15:14] <pmatulis> but the shell is not available in the /boot chroot
[15:14] <smb> But at least for a while I did it but ended always up with too little space in either /usr or /opt and then just gave up. Maybe by now online expansion of file system works...
[15:15] <smb> pmatulis, Is even /bin in another partition or only /usr?
[15:16] <pmatulis> only /usr
[15:17] <smb> pmatulis, I guess you need to mount everything into /mnt the intentional / (maybe not /usr) and /proc and /dev
[15:17] <smb> and /boot 
[15:18] <smb> Thats what I usually do:
[15:18] <smb> mount /dev/x /mnt (root partition)
[15:18] <smb> mount /dev/y /mnt/boot 
[15:19] <smb> mount --bind /dev /mnt/dev
[15:19] <smb> mount --bind /proc /mnt/proc
[15:19] <smb> chroot /mnt
[15:20] <pmatulis> ok, that looks reasonable.  all this b/c apparently there is a problem with 2.6.32-22 whereby initramfs is not updated after kernel upgrade.  still not confirmed
[15:20] <pmatulis> smb: 6
[15:21] <pmatulis> smb: heh, ^^^
[15:22]  * smb fall out of his parser at b/c and 6
[15:23]  * psurbhi got a dr appointment - quits for today
[15:23] <pmatulis> smb: ?
[15:23] <apw> b/c == because
[15:23] <smb> pmatulis, I fail to translate b/c and have no idea what 6 meant
[15:23] <smb> apw, ahh
[15:24] <apw> and 6 is what ^ is without shift accidentally
[15:24] <apw> on a UK/US keyboard
[15:24] <pmatulis> apw: you rock
[15:24] <apw> i have seen smb's keyboard :)
[15:24] <smb> apw, You get the personal translator award. :)
[15:24] <apw> heh ... :)
[15:25] <smb> apw, Its all sensible (at least to me)
[15:25] <apw> i work with a lot of foreign people with non-native english speakers predominating
[15:26] <apw> pmatulis, not seen that here for sure on any of my machines
[15:26] <apw> as they really wounldn't boot well without initramds
[15:26] <smb> pmatulis, Ok, so to get back to the issue... :-P I have the feeling this happens from time to time (not kernel related) but cannot say what is the trigger
[15:26] <smb> Actually I rather saw this happen with update-grub
[15:27] <apw> smb, actually i do have a theory ...
[15:27] <apw> when i did this recent upgrade it did install more than one kernel
[15:27]  * smb is all ears
[15:27] <apw> arn't initramfss generated as a 'delayed' dpkg triggery thing?
[15:27] <pmatulis> maybe it has to do with update-grub then
[15:27] <apw> and that actually only does the 'latest' one
[15:27] <apw> so we might in theory miss one therre, though not the one you should be using of course
[15:27] <apw> hrm
[15:28] <smb> I think that would be the intention.
[15:29] <smb> Its probably hard to get all the special cases right
[15:29] <smb> as the initrd update is also triggered by essential userspace changing
[15:29] <smb> like installing lvm or updating udev
[15:30] <smb> That you would only want to do on the 'current' kernel
[15:30] <smb> but installing a new kernel obviously needs it all the time
[15:32] <smb> pmatulis, My update-grub issue would 'only' be not seeing the new kernel. The initrd was there as far as I remember
[15:32] <smb> So it might be two things
[15:32] <pmatulis> smb: forgot to mention something
[15:32] <pmatulis> smb: the problem purportedly manifests itself when using LVM
[15:33] <pmatulis> smb: it's the lvm2 module that is missing from the initrd
[15:33] <pmatulis> smb: using ext4, not sure if that is important
[15:34] <smb> Is that installing lvm2 without a kernel update?
[15:36] <smb> If the kernel is also updated at the same time, this might be a third problem we sometimes see: kernel is updated/installed->initrd is (re-)generated. lvm2 is installed at the same time but initrd is not regenerated because it thinks this is already done.
[15:36] <pmatulis> smb: no, LVM is in use on disk
[15:37] <smb> pmatulis, Then we should wait for the results of running update-initramfs manually. If that still fails to include lvm2 it is a problem there
[15:38] <pmatulis> smb: alright, will report back
[15:46] <JFo> ogasawara, interested in this bug? It's an old one. bug 45021
[15:46] <ubot3> Malone bug 45021 in linux-source-2.6.22 "including "omnibook" module would help with ACPI support on HP laptops" [Medium,Won't fix] https://launchpad.net/bugs/45021
[15:46] <JFo> anyone have an idea who needs to see bug 574184
[15:46] <ubot3> Malone bug 574184 in linux "Bad signatures for 10.04 installer validation: MD5SUM SHA1SUM SHA256SUM" [Undecided,Confirmed] https://launchpad.net/bugs/574184
[15:46] <JFo> apparently the DVD ISOs have bad signatures
[15:48] <smb> JFo, maybe cjwatson or slangasek directly?
[15:49] <JFo> smb, ta
[15:51] <apw> JFo, yeah bring that up on ubuntu-devel,
[15:52] <JFo> apw, done
[15:55] <JFo> apw, or were you thinking that was a bad idea?
[15:55] <apw> no it is the right thing.  thats a case of someone using linux to mean 'the whole thing' not the 'kernel'
[15:55] <JFo> right
[15:55] <JFo> thought so\
[15:56] <JFo> here is an interesting bug 575518
[15:56] <ubot3> Malone bug 575518 in linux "linux kernel contains GPL violations" [Undecided,Incomplete] https://launchpad.net/bugs/575518
[15:56]  * smb closes eyes and ears
[15:58] <mjg59> JFo: It's entirely unclear whether including those objects is something other than mere aggregation
[15:58] <apw> smb, its the remaining inbuilt firmwares
[15:58] <apw> as they come directly from linus' tree i am less worried about it
[15:58] <JFo> same here
[15:58] <JFo> but I wanted to bring it up
[15:58] <persia> Isn't fixing that 90% just editing debian/copyright?
[15:59] <apw> JFo, pgraner has the lead on all firmware related issues so i would get him on the case
[15:59] <persia> so that the entirety of the source *isn't* claimed GPL?
[15:59] <JFo> apw, that is the plan :)
[15:59]  * persia thought someone went through that pain about 18 months ago already
[15:59] <mjg59> persia: No, large quantities of the source tree aren't GPL
[15:59] <mjg59> persia: THere's a lot of it that's BSD, for instance
[15:59] <JFo> pgraner, you there my captain?
[15:59] <mjg59> And some dual GPL/MPL
[15:59] <apw> persia, for the majority of consumers  i suspect so yes, though i suspect from the reports tenor that they will not be happy to install a kernel which pulls them in
[15:59] <JFo> yeah, sounds like they want the option to leave them out
[16:00] <apw> persia, someone did for the main firmware packages, not for the small inbuilt ones
[16:00] <persia> mjg59: I still think it's largely a documentation issue, but I may be mistaken.  That said, most BSD stuff becomes GPL when integrated with GPL stuff, doesn't it?
[16:00] <persia> apw: Ah, that makes sense.
[16:00] <mjg59> persia: No, BSD stuff remains BSD
[16:00] <persia> OK.
[16:00] <mjg59> persia: But that's fine, because the BSD license doesn't confer any restrictions above and beyond the GPL
[16:01] <apw> only doing GPL things with BSD ensures you don't violate BSD cause its essentially a superset of the GPL rights
[16:01] <persia> Right.  I'm confusing license-of-the-compiled-binary-package and license-of-the-compiled-binary-objects.
[16:02] <pmatulis> smb: bad news:
[16:02] <pmatulis> mount: unknown filesystem type 'LVM2_member'
[16:02] <apw> all thats said i thought there was a driver to pull them all out to loadable status, not sure if that has occured yet
[16:02] <mjg59> apw: It's happening gradually
[16:02] <apw> thought as much, not sure when it slated to be 'done'
[16:02] <smb> pmatulis, You need to install lvm2 to the live image
[16:02] <apw> as us trying to preceed is plain bonkers :)
[16:02] <mjg59> apw: That said, I think that analysis is wrong in places
[16:03] <ogra> apw, will anyone from the kernel team merge initramfs-tools ? 
[16:03] <apw> ogra, do what ?
[16:03] <apw> ogra, as in sync it from debian ?
[16:03] <ogra> apw, merge the initramfs-tools package
[16:03] <ogra> yes
[16:03] <mjg59> apw: In fact, it *is* wrong in places
[16:03] <ogra> not *sync* 
[16:03] <ogra> that needs heavy-lifting merge work :)
[16:03] <apw> normally foundations has done that IIRC
[16:03] <mjg59> drivers/scsi/aic7xxx/aic79xx.seq is *source* and comes with a GPL compatible license
[16:04] <ogra> ah, kernel-team is the owner since lucid
[16:04] <mjg59> The toolchain for it is *included in the kernel source*
[16:04] <apw> yeah it does appear to be a list of all files not called .c
[16:05] <apw> and following his links its to the radical end of the alarmist world
[16:06] <mjg59> drivers/scsi/sym53c8xx_2/sym_fw1.h looks pretty like source to me
[16:06] <apw> 'its not free software because i cannot understand it'
[16:06] <apw> not 'its not free because i am not allowed to distribute it freely'
[16:08] <ogasawara> JFo: I took care of that bug - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/45021/comments/34
[16:08] <ubot3> Malone bug 45021 in linux-source-2.6.22 "including "omnibook" module would help with ACPI support on HP laptops" [Medium,Won't fix] 
[16:08] <apw> JFo, we can talk to pete next week about it i recon
[16:08] <apw> i don't see it being a major issue
[16:08] <JFo> cool
[16:08] <JFo> yeah, no big, just wanted to provide the head's up
[16:09] <apw> yeah i think most of it is non-pragmatic and we are not in any real danger there, but its for the lawyers not 'us' to take a position and thats petes end of the world
[16:11] <manjo> ogasawara, omnibook is under ubuntu/
[16:12] <ogasawara> manjo: right, which is why I marked it Fix Released
[16:12] <ogasawara> manjo: and posted the reasoning in the comment
[16:12]  * apw waves to manjo 
[16:12]  * manjo waves back to apw
[16:13] <manjo> ogasawara, right.
[16:14] <pgraner> JFo: you can close that bug
[16:15] <pgraner> JFo: we created linux-firmware-nonfree to address that
[16:15] <pgraner> JFo: I forgot to close it
[16:15] <JFo> pgraner, I think apw was indicating it was things that were not in nonfree
[16:16] <JFo> ogasawara, thanks, just now saw your response above
[16:16] <manjo> apw, any plans for suspend resume this cycle ? except for freq based reporting which I moved to this cycle ?
[16:16] <apw> i suspect that given his desire to point out nonfree in his bug, that that would placate him
[16:16] <JFo> apw, cool
[16:16] <apw> curtainly worth saying we now have that same as debian, and firmware has been cleaned up and recategorised
[16:16] <JFo> I'll write up something
[16:16] <pgraner> apw: ack
[16:17]  * pgraner is off to find food
[16:17] <JFo> enjoy
[16:38] <JFo> apw, just reading your e-mail re:KMS Bugs... dude, you read my mind and actually created the tag I was thinking of using... scary. :)
[16:39] <apw> jfo you need a thicker tin helmet
[16:39] <JFo> indeed
[16:39] <JFo> and some aluminium lining :)
[16:44] <cking> great minds and all that
[16:46] <kees> apw: which patch did surbhi see as helping fix the umount stalls?
[16:54] <smb> kees, The one you found causing the slow downs afaik
[16:54] <kees> smb: no, I mean, what's the proposed new solution?
[16:54] <apw> kees, thats not been found, mearly me requesting she test the patch as proposed at the end of the upstream bug
[16:55] <smb> kees, She is currently looking into the patch that was proposed in the upstream bugzilla
[16:55] <apw> to see if it is the fix or not
[16:55] <kees> okay, right, I wanted to direct attention there if it wasn't already known, but it is, so good.
[16:55] <kees> I'm glad to at least understand the trigger (boundaries)
[16:56] <ogasawara> smb: what was the keybinding incantation you had in your .vimrc file?
[16:56] <achiang> there's this too: http://www.spinics.net/lists/linux-ext4/msg18780.html
[16:56] <achiang> kees: ^^
[16:56] <smb> ogasawara, A second (if apw is not again faster)
[16:58] <smb> ogasawara, map =F :call Finalise()<ctrl-m>
[16:58] <ogasawara> smb: awesome, thanks
[16:58] <kees> achiang: ooh, yeah
[16:58] <smb> ogasawara, The ctrl-m is ctrl-v+ctrl-m
[16:59] <smb> ogasawara, map =N :call NewVersion()^M^[:call Finalise()^M''A
[17:01] <smb> ogasawara, Thats probably better to describe what you see. ^M and ^[ are control sequences
[17:07] <pmatulis> re fix-committed for karmic in bug 513848, wondering when it will become fix-released
[17:07] <ubot3> Malone bug 513848 in linux "[karmic] CPU load not being reported accurately" [Low,Fix committed] https://launchpad.net/bugs/513848
[17:07] <apw> smb, that one i think is acked and applied, when is the next -proposed going in?
[17:08] <smb> apw, Somewhen after the next round of security
[17:08] <smb> IOW don't know, yet
[17:08] <apw> ahh a while then
[17:08] <smb> I hope not too long
[17:08] <pmatulis> a few weeks?
[17:09] <smb> pmatulis, yeah, given UDS interruption
[17:09] <pmatulis> smb: alrighty then
[17:10] <ogasawara> smb, apw: I think my ping yesterday missed you guys, but did we accidentally lose this commit in Lucid? - "UBUNTU: [Config] Add atl1c to nic-modules udeb"
[17:11] <ogasawara> smb, apw: kernel-team ml thread was "Lucid pull request, SRU lp557130" from rtg
[17:11] <apw> ogasawara, i thought that was Fix Committed
[17:11] <smb> ogasawara, Thought I did that. lemme check i messed up to push
[17:13] <smb> ogasawara, Hm, I might have forgotten to push. i see it locally but not remotely
[17:14] <smb> ogasawara, I am in the middle of a am sequence the. Give me a few min and I push it
[17:14] <ogasawara> smb: ok cool.  no hurry.
[17:19] <smb> ogasawara, ok, pushed. Sorry for that
[17:19] <ogasawara> smb: thanks
[17:20] <JFo> you go ogasawara crack that whip ;-0
[17:20]  * JFo grumbles about his shift key
[17:21] <ogasawara> JFo: heh, I'd have not even noticed it had tim not nudged me when he sent the patch mentioning I'd want it for Maverick
[17:21] <JFo> ah
[17:23] <cking> shift key?
[17:25] <vanhoof> pgraner-afk: ping
[17:29] <apw> cking, 0 -> )
[17:30] <JFo> heh, sorry, should have been more clear
[17:30] <smb> apw is universal keyboard translator today
[17:30] <JFo> indeed
[17:30]  * JFo applauds apw
[17:31] <smb> In my world this would have been 0 -> =
[17:31] <apw> smb, :)
[17:32]  * smb is away to have some fun
[17:35] <cking> heh, 3 hours to print a map on my Brother laser printer. That's what I call painful
[17:37] <manjo> cking, how big is the map ? 
[17:39] <cking> manjo, not that big - my laser printer has a small buffer, and rendering images takes forever
[17:39] <cking> my fail for buying a lame printer
[18:00] <JFo> <-lunch
[18:04]  * manjo looks towards the kitchen
[18:05] <cking> always thinking of food?
[18:09] <manjo> :)
[18:10]  * apw is at the moment (food!)
[18:10] <cking> bah, now I'm hungry
[18:10] <apw> cking, it _is_ dinner time, yours must be burned by now
[18:16] <cking> ..just one more bug...
[18:30] <manjo> apw, I guess you missed my Q earlier... I am wondering if you have any thoughts for a suspend/resume blueprint? I can think of frequency based reporting that I moved to this cycke
[18:30]  * apw notes that PPA's have a delete button all of a sudden
[18:31] <apw> i don't think we ahve any plans for detailed work do we?
[18:31] <apw> seems excessive to have a whole blueprint for one item like that
[18:31] <apw> we have talked about having a catchall blueprint for those
[18:32] <apw> for those small items which would be too small to warrent their own
[18:32] <cking> hehe, my neighbour just drove their car up the driver and nearly eliminated a tory councillor  delivering leaflets
[18:33] <cking> s/driver/drive/
[18:33] <apw> sounds worthy to me
[18:34] <manjo> apw, yep that works for me 
[18:39] <apw> manjo, so just keep it in mind and i'll get one made
[18:40] <kro> which special options do I need in my kernel to be able to boot a ubuntu 10.04 userland?
[18:40] <kro> so far I found out I need devtmpfs
[18:40] <kro> and I have to remove ureadahead
[18:40] <apw> yep ureadahead needs some patches from the ubuntu kernel
[18:40] <kro> but I still can't boot a vanilla kernel on a fresh 10.04 :-/
[18:41] <apw> i generally build mine with the lucid config
[18:41] <kro> systems get stuck during mountall/upstart-udev-bridge/udev
[18:41] <apw> perhaps you don't have unix domain sockets built in?
[18:42] <kro> that's not an option here :-/
[18:42] <apw> why so?
[18:43] <apw> pretty sure something like that is used for mountall
[18:43] <kro> CONFIG_ what would that be?
[18:44] <kro> because it's some sort of company kernel... I can askto have some options added or removed, but I can't change the whole conf
[18:44]  * apw checks what it is that it uses
[18:44] <kro> (running on several thousand servers)
[18:44] <apw> so you can change the whole of userspace ?
[18:46] <apw> kro CONFIG_UNIX would be unix domain sockets
[18:46] <kro> ah, nope, that one's =y
[18:46] <apw> hrm ok
[18:47] <apw> probabally need to ask the upstart people what its needing
[18:47] <apw> keybuk is the ubuntu maintainer there
[18:48] <kro> but right, upstart-udev-bridge seems to hang on some socket related stuff...
[18:48] <abogani> kro: CONFIG_CONNECTOR?
[18:48] <kro> bingo.
[18:48] <kro> do I need that?
[18:49] <apw> thats =y for distro and =m for ports and i assume both boot
[18:49] <apw> what you got there?
[18:49] <kro> I got "is not set", i see lucid's kernel is =y
[18:50]  * apw has no idea if that is used, abogani is that something known needed for upstart?
[18:51] <apw> oh yeah that looks like something upstart would need to wait for its children
[18:51] <kro> Connector - unified userspace <-> kernelspace linker
[18:51] <kro> sounds good
[18:51] <kro> thx, I'll give it a try
[18:53] <abogani> apw: I'm not sure but I noticed some days ago a strange use of netlink for upstart/udev comunication.
[18:53] <apw> looking at the description i think that upstart uses it for all child instantiation and tracking
[18:55] <abogani> Sorry for (big) off-topic. I hope that no one flame me for that.
[18:55]  * abogani wonders if there are in this channel someone could offers him some sort of job.
[18:55] <abogani> Thanks in advance!
[18:56] <apw> all our jobs are listed on the web site
[19:06] <manjo> apw, if lsusb lists a bluetooth device, that means the kernel is able to recognize the device correct ? 
[19:23] <cnd> apw, smb, ogasawara: does a config enforce addition require a bug and an SRU (for lucid)?
[19:23] <cnd> JFo:  I keep getting emails about bug 521967, so I decided to take a look
[19:23] <ubot3> Malone bug 521967 in linux-backports-modules-2.6.32 "support for new atheros wifi chipset - AR2427/ath9k" [Medium,Triaged] https://launchpad.net/bugs/521967
[19:23] <cnd> JFo: it seems there's an upstream patch that was CC'd to stable@kernel.org, but it hasn't been accepted for over two months
[19:23] <apw> build system changes arn't SRU material, but a bug makes sense
[19:23] <cnd> JFo: I'm kinda busy with hwe, but maybe you could find someone to take a quick look at it?
[19:23] <JFo> nice
[19:23] <JFo> I'll see what i can do cnd 
[19:24] <cnd> JFo: thanks
[19:24] <JFo> my pleasure
[19:26] <JFo> hmmm
[19:26] <ogasawara> cnd: hrm, even though it does seem a bit overkill for enforcing a config option, I'd say it needs to follow the same rules for all changes being applied to Lucid.  So yes, a bug and an SRU.
[19:26] <ogasawara> cnd: but I'd check with smb first as he's the official gatekeeper for Lucid
[19:27] <JFo> cnd, that ath9k bug would explain why I have seen a veritable flood of ath9k issues
[19:27] <cnd> JFo: potentially
[19:37] <cking-afk> by
[19:37] <cking-afk> bye
[19:44] <manjo> ogasawara, when apport collects lspci and lsusb outputs, May be we should collect it will -vv flags 
[19:44] <cnd> ogasawara: do I need to do anything to have the patch I just sent for lucid also applied to maverick?
[19:44] <ogasawara> cnd: nah, just mention you want it applied for maverick and I'll pull it
[19:45] <cnd> ogasawara: k, thanks
[19:45] <ogasawara> manjo: I thought it did use the -vv flags for lspci (not sure about lsusb)
[19:45] <ogasawara> manjo: I'm sure pitti would take patches :)
[19:46] <manjo> ogasawara, I think it does not collect lsusb right now 
[19:46] <manjo> ogasawara, also dmidecode information will be useful especially dealing with bios bugs 
[19:47] <apw> dmidecode is tricky cause we cannot run root things
[19:47] <ogasawara> manjo: yep, what apw said
[19:47] <apw> there is a file containing the output at boot think, and that may be taken i forget
[19:47] <ogasawara> manjo: I thought it might inject some bits into the bug description
[19:48] <manjo> ogasawara, ah yes it does 
[19:49] <manjo> lsusb -v needs to be run as root to collect complete info, other wise it will say permission denied for some info
[20:01] <manjo> nvidia driver seems to be trash.. I see a lot of reports where it takes more than 8sec to resume
[20:08] <apw> manjo, yep, radeon seems to take 10s here for me
[20:10] <manjo> I am trying to understand the bits and pieces of nvidia in the src... there is drivers/video/nvidia and drivers/gpu/drm/nouveau
[20:11] <abogani> I suspect than a lot of magic happens in blob...
[20:11] <abogani> By the way, When we'll know what is the final version of kernel used in Maverick?
[20:12] <ogasawara> abogani: next thurs, tbd at UDS
[20:12] <abogani> ogasawara: Thanks.
[20:15] <akgraner> apw et al you awesome kernel people's :-) 1500 UTC Kernel Q &A Session for open week :-)  - https://wiki.ubuntu.com/UbuntuOpenWeek
[20:16] <apw> ogasawara, we need to get a possy together for that, you making it ?
[20:16] <ogasawara> apw: yep, I'll be there
[20:16] <JFo> akgraner, that is tomorrow, yes?
[20:16] <akgraner> yeppers
[20:16] <JFo> I'll be there if that matters
[20:16] <JFo> :)
[20:16] <akgraner> JFo, that will be 1100 your time :-)
[20:17] <JFo> k
[20:17]  * JFo plans coffee early
[20:17] <apw> who is going to take point, akgraner i assume you are running the show
[20:17] <akgraner> apw, nah I just help :-) 
[20:17] <JFo> snort*
[20:17] <JFo> errr
[20:17] <akgraner> but yeah I'll be there and can drive the bot if you all want me too
[20:18] <apw> ogasawara, you've done one of these before haven't you ... i'm clueless
[20:18] <ogasawara> hrm, we should have some talking points
[20:18] <JFo> well, it is Q & A
[20:18] <JFo> so they ask, we answer?
[20:18] <akgraner> ogasawara, if you want to add some slides put them in pdf format and shoot me the link to them
[20:18] <apw> we might want some basic questions lined up to kick things off
[20:18] <ogasawara> JFo: yah, but they sometimes need a little push
[20:18] <JFo> good point
[20:18] <akgraner> we can get them added to your session as well
[20:19] <apw> ogasawara, remember those slides we did for pete
[20:19] <apw> that was all questions and answers
[20:19] <cnd_mini> ogasawara: what do the different colors on the kernel track uds schedule mean?
[20:19] <ogasawara> apw: hrm, I don't recall those
[20:19] <apw> when you wake up normally UTC ?
[20:19] <JFo> cnd_mini, there is a schedule?
[20:19] <ogasawara> cnd_mini: the colors usually group by track - ie the kernel is that yellow/orange color
[20:20]  * JFo would like to see
[20:20] <ogasawara> JFo: summit.ubuntu.com
[20:20] <apw> i am not sure i can be bothered tonight, but i can look them out tommororow
[20:20] <JFo> ogasawara, thanks
[20:20] <ogasawara> apw, akgraner: I never usually prepared slides
[20:20] <cnd_mini> ogasawara: ahhh, thanks
[20:20] <apw> ogasawara, i didn't mean as slides, more as potential basic questions we might ask each other if noone else has any to start with
[20:20] <JFo> odd that is still shows me as not registered to attend
[20:21] <ogasawara> apw: I'm usually up around 14:30 UTC, but I'll get up a little earlier tomorrow so we're prepared
[20:21] <akgraner> with classbot and lernid sessions can now have slides - was just letting ya know
[20:21] <akgraner> :-)
[20:21] <akgraner> just in case
[20:21] <ogasawara> apw: I'll throw together some general Q & A in an email today
[20:21] <apw> akgraner, do i need to do anything other trhan use xchat in those two channels?
[20:21] <ogasawara> apw: then maybe we can mumble in the morning
[20:22] <ogasawara> apw: that's all I ever needed
[20:22] <apw> ogasawara, you are something of a hearo
[20:22] <akgraner> apw, you may want to use lernid
[20:22] <akgraner> that way you can see both channels at the same time
[20:22] <akgraner> side by side
[20:22] <apw> i can see both with xchat too :)
[20:22] <akgraner> ok  then you are good to go :-)
[20:25] <ogasawara> akgraner: tomorrow could you op both apw and I so we both can post to #ubuntu-classroom
[20:25] <JFo> sweet!
[20:25] <akgraner> yep
[20:25]  * JFo gets out of it
[20:26] <akgraner> kirkland, are you all good to go for the Server Q & A for 1600 UTC tomorrow as well? or do I need to pop into another channel and ask?
[20:39]  * ogasawara lunch
[21:18] <cnd_mini> sconklin: I just sent you my key for the uds key signing session, but I had to do it using msmtp directly, so can you verify everything looks ok?
[21:18] <sconklin> looking
[21:20] <sconklin> looks ok. The mailer even recognized it and asked if I wanted to import it
[21:20] <cnd_mini> ahh cool
[21:20] <sconklin> If there's a problem I can always get it from you directly at UDS before Wed
[21:20] <sconklin> I'm still frantically working on a demo of the patch tracking stuff and slides in case I get picked for a plenary presentation
[21:21] <cnd_mini> well, now I know how to send attachments using the cmdline :)
[21:22] <cnd> I've been working nonstop on oem stuff...
[21:23] <sconklin> cnd: I totally understand
[21:23] <cnd> I think things should be quieted down now though, at least for a bit
[21:28] <JFo> cnd, I have not yet gotten anyone to look over that bug
[21:28] <JFo> <-slack
[21:29] <cnd> JFo: np, consider it just a wish
[21:29] <JFo> heh
[21:29] <cnd> I don't really care other than to quiet the people down
[21:29] <JFo> yeah
[21:29] <JFo> I understand
[21:31] <mrec> hey, does anyone know is there something like a broadcast message available before a system goes into hibernation?
[21:31] <JFo> mrec, you mean to users?
[21:32] <mrec> yes, I need to close and restart an application (as root) when this happens
[21:32] <JFo> I'm not aware of anything
[21:32] <JFo> but then, others are more knowledgeable
[21:32] <mrec> it's a problem for live data.. 
[21:32] <mrec> as long as the notebook is down it will miss the data and after it wakes up the data is corrupted
[21:33] <JFo> I see
[21:35] <mjg59> mrec: There isn't. The easiest thing is for you to drop a script fragment into pm-utils.
[21:37] <mrec> hmm ok this works for ubuntu
[21:38] <mrec> I guess this is absolutely messed up and every distribution has its own path for this
[21:38] <mrec> but it helps alot for ubuntu thanks
[22:15] <kamal> mjg59: Hi - yesterday you kindly pointed me to i915_opregion.c as a possible solution to the Dell Studio 1558's non-functional DSDT brightness control -- may I update you on my progress and where I'm stuck?
[22:15] <mjg59> Sure!
[22:15]  * kamal pastes away...
[22:15] <kamal> Today I hacked up some test code where I arrange for i915_driver_irq_handler() to call asle_set_backlight() based on a global that I stuff in the acpi/video brightness code ...
[22:15] <kamal> Additional printk's show that my hack does end up calling asle_set_backlight() in response to the brightness keys and that routine returns 0 (success) -- but alas, there is no effect on the actual backlight brightness. 
[22:15] <kamal> Should I expect asle_set_backlight() to "just work" on anything that supports opregion?  Or perhaps there's some additional opregion setup steps that I'm supposed to be doing first?
[22:15] <kamal> (Side note: I also tested moving the misplaced _BCM routine where I thought it was supposed to go -- that did make the acpi/video driver happier, but that _BCM routine doesn't actually affect the brightness either.  Further experiments showed that the registers that _BCM sets just don't any visible effect).
[22:15] <kamal> mjg59: ^^ Any advice will be most appreciated.
[22:16] <mjg59> kamal: Ok, unless Dell are doing something *very* odd then the writes should probably work
[22:17] <mjg59> kamal: Can you check which registers asle_set_backlight() is hitting?
[22:17] <kirkland> akgraner: i cannot do that
[22:17] <kirkland> akgraner: will need to get someone else
[22:17] <kirkland> akgraner: try mathiaz, zul, or smoser
[22:17] <mjg59> Oh, hang on
[22:18] <mjg59> kamal: More to the point, what's getting passed to asle_set_backlight in the bclp argument?
[22:19] <kamal> mjg59: :-)  I was careful to pass in :    (  (1<<31)  |  mybrightnessvalue  )   where mybrightnessvalue ranges from e.g. 0 to 100 (I see that it accepts 0 to 255 range)
[22:19] <kamal> mjg59:  I do check that asle_set_backlight returns 0, which it only does if it gets all the way through.
[22:20] <mjg59> kamal: Yeah, ok. So I guess you get to make sure that it's writing the registers
[22:20] <kamal> mjg59: ... this was all of course after missing the ASLE_BCLK_VALID check the first time ;-)  but yes, its writing the registers
[22:21] <mjg59> kamal: Hrm.
[22:21] <mjg59> kamal: Oh...
[22:21] <mjg59> kamal: asle_set_backlight_ironlake()
[22:21] <mjg59> I bet that'll help things
[22:21] <kamal> mjg59: Doh!  I noticed that yesterday, and wondered, but then forgot about it!
[22:22] <mjg59> This is an i5?
[22:22] <kamal> mjg59: yes, an i5.
[22:22] <mjg59> Yeah
[22:22] <kamal> yeah
[22:22] <mjg59> Needs to be the ironlake version
[22:22] <kamal> :-) Ok, I'll take another spin at it.  I'll let you know!
[22:34] <kamal> mjg59: Bingo!  it works perfectly!
[22:35] <kamal> (well, as perfectly as a horrid hack should work at least)
[22:35] <mjg59> kamal: Heh
[22:36] <mjg59> kamal: Ok, so now you just need to add a callback registration function to video.c and have i915 set that up before it calls acpi_video_register()
[22:36] <mjg59> Then if that's set, use it rather than calling _BCM or _BCL
[22:38] <kamal> mjg59: ok got it -- I'll let you know when I have that ready for review -- thanks very much for your help with this.
[22:38] <mjg59> No problem
[22:38] <mjg59> Saves me having to write it
[22:43] <kamal> mjg59: I'll need some guidance about how we can detect whether opregion-brightness-control is supported ...  and will we want to let i915 take over brightness control by default?  Anyway, I'll get working on the callback-based functionality and then we/you can figure out when to enable it.
[22:44] <mjg59> kamal: If you're in i915_opregion_init() then it's probably supported - there's some error checking through there
[22:44] <kamal> mjg59: is it the case that all devices which support opregion will support the backlight control mechanism?
[22:45] <mjg59> You might want to check the spec
[22:45] <mjg59> I expect so, since it's about the only useful thing opregion gives you
[22:46] <kamal> mjg59: :-)  ok got it -- anyway I'll focus on getting the callback working.  thanks again!