=== emma_ is now known as emma
=== emma is now known as em
[06:19] <ppisati> moin
[06:52] <gema> hi guys
[06:52] <gema> I am seeing a bit performance regression when there is heavy i/o on my big pc
[06:52] <gema> from oneiric to precise
[06:52] <gema> so big that I cannot do anything when there is heavy i/o going on
[06:53] <gema> the system freezes
[06:53] <gema> my dmesg: http://paste.ubuntu.com/946880/
[06:53] <gema> s/bit/big
[07:05] <j24> eric maio arround here?
[07:05] <j24> ericm|ubuntu:  ping
[07:06] <ericm|ubuntu> j24, hi
[07:06] <j24> pm
[07:51] <scientes> setarch --uname2.6 is broken
[07:51] <scientes> but this works: http://mirror.linux.org.au/linux/kernel/people/ak/uname26/uname26.c
[07:51] <scientes> --uname-2-6
[07:51] <scientes> as documented in the man page
[07:53] <scientes> nvm
[07:53] <scientes> used it wrong
[07:54] <cking> smb, mumble-less today?
[07:54] <smb> cking, Easy... I am just slowly waking up... :-P
[07:54]  * cking offers smb more coffee
[08:26]  * ppisati -> brb
[08:43] <cking> brendand, I updated that bug report to explain why the bug only occurs on machines with >= 10 CPUs
[08:44] <brendand> cking - yeah, i realised last night after i logged off
=== chrisccoulson_ is now known as chrisccoulson
[08:45] <cking> cool - least it's not some weird kernel issue after all ;-)
[09:13] <cking> smb, http://zinc.canonical.com/~cking/disable-turbo.sh
[09:15] <cking> smb, http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
[09:16] <cking> manual 3b, section 14.3.2.2 OS Control of Opportunistic Processor Performance Operation
[10:14] <apw> ppisati, do you have a beagleXM ?  do you know if 1GHZ works on that ?
[10:37] <ppisati> apw: i've an xm, which kernel?
[10:37] <ppisati> apw: in the past we limited it to 800mhz but that should be fixed by now
[10:38] <apw> ppisati, in whatever is in precise
[10:38] <apw> ppisati, ie. is this bug invalid now for preise: https://bugs.launchpad.net/ubuntu-release-notes/+bug/771537
[10:38] <ubot2> Launchpad bug 771537 in linux "Beagle XM lacks proper 1Ghz support" [Medium,In progress]
=== akgraner` is now known as akgraner
[10:40] <ppisati> apw: let me try that
[10:51] <pgraner> cking, ping
[10:51] <cking> pgraner, pong
[10:51] <apw> henrix, the fsam7400 thing, does that lead to an oops?
[10:52] <pgraner> cking, got time to dig into a high load mystery
[10:52] <cking> pgraner, sure, can do
[10:52] <henrix> apw: yes, it does
[10:52] <pgraner> cking, ping gema she is hitting the mysterious high load one we've never been able to track down
[10:53] <henrix> apw: btw, i was investigating this issue again and i have a question about it
[10:53] <cking> pgraner, when does this need fixing - I was expecting to pop out for an hour or so at lunch today to pick some things up
[10:53] <pgraner> cking, I think she has other things going on so its not urgent but apparently she has hw that can repro it
[10:53] <henrix> apw: why do we have this driver at all? it looks there is an in-tree driver that does the same job
[10:54] <henrix> apw: drivers/input/misc/wistron_btns.c seems to be based on fsam7400.
[10:54] <apw> henrix, its historical from before, and i think we said the in-tree one doesn't do all the same machines, and didn't you volunteer to talk to ben to help get the missing ones in or something?
[10:54]  * ppisati -> out for lunch
[10:55] <henrix> apw: true. benh isn't going to do that, but accepts patchs :)
[10:56] <apw> henrix, so at UDS during the session on the ubuntu delta we are going to need to decide if we care about the ones which done't have support, as i believe we should drop the driver there, and maybe you can help add them or we just ignore the issue
[10:56] <apw> henrix, so expect to be asked how much work it would be to add the missing ones :)
[10:56] <henrix> apw: sure
[10:57] <apw> ogasawara, add that to the blueprint ^^ :)
[10:57] <henrix> apw: i'm not sure if there are machines supported by the fsam7400 and not by the in-tree driver
[10:57] <apw> henrix, doing some research to know the answer to even that would be good
[10:58] <henrix> apw: maybe the fsam7400 just uses brute-force, while the in-tree uses a white-list.
[10:58] <henrix> apw: but the code does the same thing in both drivers, so it has to work
[10:59] <apw> henrix, if you could become our expert on this subject and bring anything you know to the session and we can use that to make a secision about dropping the stupud one we have ... sounds like it will be a slam-dunk "drop it"
[11:00] <henrix> apw: i'm working on that issue ATM. unfortunately, the (single!) bug reporter is not very responsive
[11:00] <apw> henrix, he is probabally _the_ person with such an old machine in the world
[11:00] <henrix> apw: :)
[11:01] <ogra_> apw, oh, you didnt say its about bug 771537 ... i think even if the kernel supports it, the limitation is set by the bootloader and i dont think anyone changed the defaults for this image (ask infinity though, not sure he touched it, i didnt)
[11:01] <ubot2> Launchpad bug 771537 in linux "Beagle XM lacks proper 1Ghz support" [Medium,In progress] https://launchpad.net/bugs/771537
[11:05] <apw> ogra_, so i can release note that as "your 
[11:05] <ogra_> mine ?
[11:05] <apw> "your beagle XM will run slow" then yes ?
[11:05] <apw> (newline error)
[11:05] <ogra_> "will not run at full speed teh CPU is capable of"
[11:06] <ogra_> or "at the speed the CPU is capbable to run" or so
[11:06] <ogra_> but check back with infinity first 
[11:06] <ogra_> i didnt touch omap3 at all apart from testing kubuntu yesterday
[11:06] <apw> ogra_, sorry yeah i'll write some reasonable english, but the note should just say it is expected to run slow
[11:07] <ogra_> (or check the cmdline on your local install if it got the brake there should be an mcpu uption or something similary named)
[11:07] <ogra_> *option
[11:08]  * ogra_ takes a look at nusakan 
=== cking is now known as cking-afk
[11:09] <ogra_> ah, mpurate is the options
[11:09] <ogra_> *option
[11:09] <ogra_> and it looks like we still set it 
=== yofel_ is now known as yofel
[12:26] <ppisati> ogra_: apw we set it to "auto"
[12:26] <ppisati> ogra_: so it scales up&down as it needs/will
[12:27] <ogra_> ppisati, even with the cmdline option set ?
[12:27] <ppisati> ogra_: no, if set it to a fixed default it should stay there
[12:27] <ogra_> right, thats what i mean above ... se set mpurate in the bootloader
[12:27] <ppisati> ogra_: but we don't ship by default to 1ghz cause it's not stable
[12:29] <ogra_> right, well, because it was not stable in oneiric ... nobody touched the setting since
=== cking-afk is now known as cking
[13:00] <smb> tgardner, I think it would be better to pull in the complete patch that introduced the label. There are other jumps in that function that would otherwise do the wrong thing
[13:00] <tgardner> smb, prolly ought to just redo the backport
[13:02] <smb> tgardner, Yeah, could be things become even simpler by picking both ...
[13:04] <herton> smb, tgardner: I think the right thing would just be in the backport to jump to vcpu_destroy instead of unlock_vcpu_destroy. Changing the labels that way below will introduce bugs, missing mutex_unlock in some cases
[13:05] <tgardner> smb, herton: its a clean cherry pick with d780592b99d7d8a5ff905f6bacca519d4a342c76 and 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e
[13:06] <smb> herton, I agree that just introducing the label looks wrong. In that case I just wondered whether picking the other patch could make sense as it is pretty small and then makes old code more like the new one
[13:06] <smb> tgardner, felt that way...
[13:07] <tgardner> smb, herton: and now it even compiles
[13:07] <herton> yeah, cherry-pick the other one is ok, makes sense
[13:07] <tgardner> it'll likely be the same fix for natty
[13:07] <smb> tgardner, surprise. :)
[13:08]  * tgardner will be back in a sec
[13:25] <sforshee> tgardner, your macbook air is a 4,2, isn't it?
[13:25] <tgardner> sforshee, whatever is on the wiki. its already in a box ready to ship
[13:27] <sforshee> tgardner, the wiki says 4,1, but I thought you had the 13 inch which ought to be 4,2
[13:27] <sforshee> were screen brightness changes working?
[13:28] <tgardner> sforshee, yes, as far as I remember. but I think I was only messing with the MB pro and screen brightness
[13:28] <sforshee> tgardner, we have a bug about the brightness adjustment not working on the 4,2
[13:28] <sforshee> I'll ask cnd to test once he gets the machine
[13:29] <tgardner> sforshee, ok, it should be there ear;y next week
[13:29] <sforshee> tgardner, ack
=== tgardner is now known as tgardner-afk
=== tgardner-afk is now known as tgardner
[14:09] <tgardner> smb, there is a script in the hardy repo called debian/scripts/misc/apply-patch-to-binary-custom which I used to propagate patches.
[14:09] <tgardner> thats about the only automation
[14:11] <smb> tgardner, Ok, I think I was remembering something along those line. Probably not really what the procedure should be. Like was it supposed to be done before a release or basically for every sru proposal we do for Hardy
[14:12] <cking> brendand, did that script fix resolve that server CPU offline issue?
[14:14] <brendand> cking, yeah - pretty much
[14:14] <cking> yay \o/
[14:16] <smb> tgardner, Clearly the jdb2 patch I submitted a bit ago needs to go into the flattened out trees as well... :/
[14:17] <tgardner> smb, oh yeah, that likely does. I'll take a stab at it
[14:17] <smb> tgardner, Thanks. I need to remember that next time...
[14:18] <tgardner> smb, it applies clean. I'll just squash and repush
[14:18] <smb> Ok, yeah. I wonder whether we could have a README.stupid into the tree that reminds me about special handling...
[14:41] <cnd> tgardner, sforshee: I won't have the MBA until after UDS though
[14:41] <cnd> I'm in oakland next week
[14:41] <tgardner> cnd, do you get to go home over the weekend?
[14:43] <cnd> tgardner, hadn't planned on it
[14:44] <tgardner> cnd, one of the lucky few :)
[14:46] <sforshee> tgardner, is it too late for you to just throw it in your uds luggage?
[14:47] <tgardner> sforshee, its too late
[15:00]  * ogasawara back in 20
[15:15]  * apw is glad to see the back of that
[15:16] <tgardner> apw, are you off to have fizzies ?
[15:16] <smb> more?
[15:18] <cking> bet apw has been fizzing all day
[15:26] <apw> tgardner, we are just having some now indeed, but its "open quantal" time
[15:32] <doug> anyone know of a good visualization or explanation of how udp packets get from user-space via sendto() onto a connected ethernet wire?
[15:32] <doug> in particular, how bpf hooks into things...
[15:33] <doug> i'm trying to figure out the most likely source for latency in this app i'm debugging
[15:33] <doug> which is sending out a hundred or so 196 (payload) byte udp packets a second 
[15:36] <apw> ogra_, hey ac100 thats kinda you, or you know enough to tell me who supports it and its abi number range yes?  its missing from our tables
[15:37] <ogra_> apw, janimo maintains the kernel package
[15:38] <dileks> wow, its not only precise
[15:38] <apw> bjf, the ABIPackages page is likely out of date is that manual or generated from other sources
[15:39] <dileks> its... Proven. Practical. Precise.
[15:42] <bjf> apw, ENOCLUE
[15:44] <bjf> apw, i'm guessing it's a hand-job
[15:44] <apw> heh
[16:15]  * ppisati -> gym/workout
[16:31]  * smb -> beer/workon
[16:35] <ogasawara> apw: just fyi, I can see this becoming a routine UDS session -> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-kernel-sources-in-main
[16:35] <ogra_> heh
[16:35] <ogra_> well, the text states to find a way to solve it for the future too :) 
[16:37] <ogasawara> ogra_: yah, some of those linux-linaro-* kernels I had no clue about.
[16:37]  * ogra_ hasnt either
[16:38] <ogra_> and i dont see linaro people subscribed yet
[16:38] <ogasawara> ogra_: I've sent email to jcrigby.  Hopefully he can help set me straight
[16:48] <jcrigby> ogasawara, ogra_ : yes those are old and I don't remember why they were ever in main
[16:48] <ogasawara> jcrigby: ok good to know.  thanks.
[16:53] <jcrigby> ogasawara, ogra_ : I remember uploading a kernel for qemu since it emulates a vexpress which was dropped from the ubuntu kernel.
[16:53] <ogra_> yeah, vexpress would be very helpful for qemu 
[16:54] <jcrigby> ok, so linaro needs to keep pushing a vexpress kernel somewhere I guess
[17:02] <ogra_> jcrigby, hmm. cant that come from mainline ? 
[17:03] <jcrigby> ogra_, yes it is up to the kernel team.  Only omap enabled now I believe.
[17:03] <ogra_> right, if vexpress is in mainline we should build it from there 
[17:03] <ogra_> and drop all other arm flavours (modulo omap4) from main
[17:10] <jcrigby> rsalveti will be at uds and he is way smarter than me so he will help figure it all out
[17:18] <jjohansen> ogasawara: thanks for working out the kernel maintenance bits with jdstrand, its much appreciated
[17:19] <ogasawara> jjohansen: no worries, seems we've got it all cleared up.
[17:31]  * apw moves to the release party ... enjoy people.
=== tgardner is now known as tgardner-lunch
=== tgardner-lunch is now known as tgardner
=== herton_ is now known as herton
[18:51] <rsajdok>  /j #ubuntu
=== JanC_ is now known as JanC
[20:02]  * tgardner -> EOD
[20:09]  * _ruben runs
[20:09] <_ruben> (EOD being the dutch bombsquad)
[21:23] <bjf> jsalisbury: i've been looking at some of the Package bugs that we have been getting
[21:23] <bjf> jsalisbury: i don't think the nag-bot should be adding comments to those
[21:23] <jsalisbury> bjf, ok.  
[21:23] <bjf> jsalisbury: a new kernel isn't the problem/solution
[21:23] <bjf> jsalisbury: what do you think ?
[21:24] <jsalisbury> bjf, yes, agreed.  Many times an apt-get clean and re-install will fix it.
[21:25] <jsalisbury> bjf, I've see a few of these now, so I'll dig deeper: bug 986482
[21:25] <ubot2> Launchpad bug 986482 in linux "package linux-tools-common (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/perf', which is also in package linux-base 3.4" [Medium,Incomplete] https://launchpad.net/bugs/986482
[21:26] <jsalisbury> bjf, actually, it looks like andy is looking at a similar bug: bug 931353
[21:26] <ubot2> Launchpad bug 931353 in linux "package linux-tools-common (not installed) failed to install/upgrade: trying to overwrite '/usr/bin/perf', which is also in package linux-base 3.3" [High,In progress] https://launchpad.net/bugs/931353
[21:28] <bjf> jsalisbury: i've got a python script which digs through the VarLogDistupgradeApttermlog.gz file and tries to find the issue
[21:29] <jsalisbury> bjf, ahh, cool.  What does it download the file, then unzip it?
[21:31] <bjf> jsalisbury: sort of, there is some of that built into lpltk and a little bit of other python code
[21:31] <jsalisbury> bjf, I see
[21:34] <bjf> jsalisbury: change pushed
[21:34] <jsalisbury> bjf, heh, that was quick :-)
[22:50] <apw> bjf, yep i have that one on my radar, might get that sorted this week in Q at least
[23:09] <bjf> apw, i'm just adding some code to the bot to help with initial triag, it looks at VarLogDistupgradeApttermlog.gz
[23:11] <vanhoof> sforshee: you about?
=== RAOF_ is now known as RAOF