[00:57] <omry> I want to play with systemtap, my current kernel is 2.6.35-7-generic #10~lucid1-Ubuntu, will this ddeb work? : 	linux-image-2.6.35-7-generic-dbgsym_2.6.35-7.10_amd64.ddeb
[07:24] <TeTeT> apw: morning, we have an escalated case from corp services that is now in the kernel teams hands, see bug 586325
[07:24] <ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/586325
[08:36] <apw> RAOF, about?  t
[08:36] <apw> RAOF, t
[08:36] <RAOF> apw: Yo!
[08:37] <apw> RAOF, the patch on bug 586325 ... where is it upstream ?
[08:37] <ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/586325
[08:37] <apw> morning, or evening :)
[08:37] <RAOF> It's just attached to the upstream bug at the moment.
[08:38] <RAOF> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/586325
[08:38] <ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 14)" [Medium,Confirmed]
[08:38] <RAOF> Ahem.  Wrong window.
[08:38] <RAOF> And a good morning to you too :)
[08:38] <apw> RAOF, good work finding that patch
[08:39] <RAOF> I didn't end up writing it.  Once I had hardware to test on the problem was much more obvious.
[08:40] <smb> RAOF, morning, as well. Any chance to let people try my test kernels? (nag)
[08:41] <ikepanhc1> good morning .eu :)
[08:41]  * smb waves towards asia
[08:42] <ikepanhc1> I can hear you on mumble, but in public area of office, so have better to keep quiet :P
[08:42] <RAOF> smb: I still haven't run into anyone appropriate to send to that kernel.
[08:42] <smb> RAOF, Bah, and I thought there were quite a few of the inconsistent checksum messages
[08:42] <apw> RAOF, i see that there is a final comment in the ipstream bug that its not fixed for krandrtray if its in the bottom right
[08:43] <apw> ikepanhc1, heh morning
[08:43] <smb> ikepanhc1, You should do. Maybe you get a nice isolated space then ;-)
[08:44] <ikepanhc1> smb: sure, moving
[08:45] <RAOF> apw: I hadn't seen that, no.  Let's see if I can check that.
[08:46] <apw> you may find like 'sleep 10; xrandr ....' in a window and shoving the cursor in the bottom right might do the same
[08:46] <RAOF> Yeah, looks like it.
[08:46] <smb> ikepanhc1, I actually meant if you speak up while on your normal pace you might get moved to a place where you cannot disturb anybody. Hope would be that this place would be nicer too. Though reality shows its rather the janitor's closet
[08:46] <RAOF> Hm.  I waved the cursor around, but obviously not all the way down in the bottom right.
[08:49] <ikepanhc1> ah? anyone hear me?
[09:01] <jk-> 'git bisect run' <3
[09:04] <ikepanhc1> apw: the bad wiki I wrote: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide
[09:05] <kraut> moin
[09:09] <RAOF> apw: Hm.  I've managed to make that happen exactly once, but I'm not sure how.  I have noticed another problem, though, which might resolve it - the pointer is hidden in some situations when it shouldn't be.  It looks like the bounds checking is off a bit.
[09:10] <smb> kraut, moin
[09:10] <kraut> howdy smb
[09:11] <apw> RAOF, ahh ok
[09:11] <apw> can't we just zap the cursor to the top left on change
[09:12] <RAOF> We could, perhaps.
[09:12] <RAOF> The hardware docs however say “at least one pixel of the pointer must be on the active display”, so enforcing this constraint in the kernel seems reasonable.
[09:13] <RAOF> You know what would be useful in the docs?  Which point of the 64x64 image the GPU considers to be the “position” of the cursor :/
[09:16] <RAOF> Oh, no.  There it is.
[10:13] <apw> RAOF, right, but could we not enforce that by moving it, rather than unmapping it ?
[11:37] <hrw> hi
[11:37] <hrw> can you look at bug 603087 and tell me does my patch has any chance to be accepted?
[11:37] <ubot2> Launchpad bug 603087 in linux (Ubuntu) "Allow to build just linux-libc-dev (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/603087
[11:59]  * apw talked to hrw about thsi over on #linaro
[12:31] <RAOF> apw: We could move it, but then the cursor displayed position wouldn't match the position X thinks the cursor is.
[12:33] <apw> RAOF, hrm, ok
[12:40] <hrw> is there a way to not generate linux-headers-VER package? rules.d/2-binary-arch.mk makes them if do_common_headers_indep != true but  rules.d/3-binary-indep.mk makes them if do_common_headers_indep == true
[12:40]  * RAOF is somewhat freaked out about the behaviour of the cursor.
[12:45] <apw> hrw, no by default no as you would never want to do that
[12:45] <hrw> apw: unless my case
[12:45] <apw> hrw, you need to find the 5 bits and put them all in stage1 or stage2
[12:45] <apw> as you have for the headers ... right ?
[12:46] <apw> you have 'headers' and everything you didn't make then needs to be made in 'rest' or whaever you called it
[12:47] <hrw> apw: http://pastebin.com/Xy5cCt8b does what I want but is rather ugly
[12:50] <apw> binary-debs doesn't look to need to change, as you turn it off in the if part
[12:51] <apw> we should probabally make a build-arch-deps and build that the same way to clean it up
[12:57] <smb> tgardner, Hi Tim, I was thinking on Karmic stuck in accept and in the end I think if we don't have it accepted by next Monday, I need to sit together with apw and get all changes reverted
[12:58] <tgardner> smb, what is the rush? Do you have CVEs pending for it?
[12:58] <smb> tgardner, yes
[13:07] <hrw> apw: http://pastebin.com/bNE1d6PB is a bit more clean
[13:09] <apw> hrw i really don't think you shoul dneed to change any of the configuration here
[13:09] <apw> for example changing the icommon headers to indep, might have an effect on other things
[13:09] <apw> we should just make both adds to _deps conditional
[13:10] <hrw> do_common_headers_indep:=false is just to not build it at all
[13:10] <apw> but you want to buld the headers
[13:10] <hrw> I want linux-libc-dev not linux-headers
[13:10] <apw> thats the point of the header stage
[13:10] <apw> then calling the stage headers is a bit mad
[13:10] <hrw> thats just name - will rename it to stage1
[13:11] <apw> ok i think the way i would do it is to make an enable_stage1 and enable_stage2
[13:11] <apw> with something like
[13:11] <apw> if ($(DEB_STAGE), stage1)
[13:12] <apw> enable_stage1=true
[13:12] <apw> elif ($(DEB_STAGE), stage2)
[13:12] <apw> enable_stage2=true
[13:12] <apw> else
[13:12] <apw> enable_stage1=true
[13:12] <apw> enable_stage2=true
[13:12] <apw> fi
[13:12] <apw> and for each element put it in one or the other
[13:13] <apw> if (enable_stage1, true)
[13:13] <apw> endif
[13:13] <apw> and make sure each element 'headers' 'tools' 'libc' etc are added to an _dep
[13:13] <apw> in that manner
[13:13] <hrw> where stage1 is what I want and stage2 is normal build?
[13:13] <apw> no where stage1 is what you need in stage1, and stage2 is the rest
[13:14] <hrw> ok
[13:14] <apw> and a normal build just enabled both
[13:14] <apw> i am sure you will want to build the rest, not everything in the second phase, as you have the headers already
[13:15] <apw> hrw, _or_ i guess we do already have a bunch of do_ variables for some things
[13:15] <apw> to allow those to be suppressed, you could also add one of those for each
[13:15] <apw> of the things you want to but cannot yet control
[13:15] <apw> and then do
[13:15] <apw> if $(DEB_STAGE, stage1)
[13:15] <apw> do_xxx = false
[13:16] <apw> do_yyy=false
[13:16] <apw> endif
[13:16] <apw> that might be the cleaner form
[13:16] <tgardner> apw,smb, remind me of the 2 mailing lists that get notified of an ABI bump
[13:16] <apw> given we have a few of the do_foo = true/flase already
[13:16] <hrw> ok, will adapt
[13:16] <smb> one is mobile
[13:16] <apw> kernel-team, debian-installer, ubuntu-mobile
[13:17] <apw> To: kernel-team <kernel-team@lists.ubuntu.com>,
[13:17] <apw>         ubuntu-installer <ubuntu-installer@lists.ubuntu.com>,
[13:17] <apw>         ubuntu-mobile <ubuntu-mobile@lists.ubuntu.com>
[13:17] <smb> right
[13:17] <tgardner> apw, that stuff used to be in the wiki
[13:17]  * apw will go and add it
[13:18] <apw> i will add a maintainer quiestion section
[13:40]  * abogani waves
[13:42] <abogani> apw, I'm your personal nuisancer! :-)
[13:43] <apw> yeah i know :)  you are on my mind and indeed in this window over -->
[14:06] <phil42> what changed in 2.6.24-28.71-generic ?
[14:08] <tgardner> phil42, http://launchpad.net/ubuntu/+source/linux/2.6.24-28.71
[14:38] <hrw> apw: http://pastebin.com/cmpBJqEN should be better
[14:38] <apw> hrw that does look much cleaner
[14:39] <tgardner> apw, what is the goal of these patches?
[14:39] <apw> tgardner, linaro need to be able to bootstrap in a cross-compile env
[14:40] <apw> that means they need to build the compiler to build the kernel, but the kernel headers are needed to build libc to build the compiler
[14:40] <apw> so they need to be able to build a subset of the kernel package
[14:40] <apw> they are applying similar DEB_STAGE changes as a policy
[14:40] <tgardner> apw, ok, I guess that makes sense
[14:41] <apw> i suspect these will go round a couple of times more yet, but they are clearer now in intent
[14:41] <hrw> gcc and eglibc are next in queue
[14:44] <tgardner> apw, looks like the i8042/Moorestown stuff is shaking out upstream
[14:45] <apw> tgardner, good to hear ... was worried it'd get forgotten
[14:45] <tgardner> apw, what is the tip-bot ? I've been meaning to ask that for awhile
[14:45] <apw> tgardner, its a litterally a bot which is associated with the tip tree which is used to hoover
[14:46] <apw> up lots of littl changes as little topic branches
[14:46] <tgardner> so, just specific trees?
[14:46] <apw> there are hundreds of branches in the tip tree
[14:47] <tgardner> apw, ok, I see now. one tree with lots of branches.
[14:47] <apw> yeah lots and lots of little branches
[14:48] <tgardner> apw, who commits to tip? just Ingo?
[14:49] <apw> tgardner, yeah as far as i know its all ingo
[14:55] <lacostej> Hei, I am trying to compile my own ubuntu kernel (to apply a patch I want to test). I want to make sure I use the exact same config. Should I copy /boot/config-`uname -r` into debian.master/config or is the source I got from git tag already properly configured ?
[14:56] <tgardner> lacostej, the configs that are generated for your kernel live in debian.master/config and are properly configured during the prepare build step.
[14:59] <lacostej> is there a simple way to make sure my generated kernel won't conflict with the existing one ?  e.g. by bumping the version number somewhere ?
[15:01] <tgardner> lacostej, thats more involved. apw might be able to point at a wiki page since he's been the most recent gardener
[15:02] <tgardner> lacostej, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance describes bumping the ABI
[15:04] <lacostej> thanks a lot
[15:09] <apw> yeah htats probabally the simplest we have at the moment
[15:09] <apw> we have it on our list as one which we need to write
[15:10] <hrw> apw: any suggestions what I should change to get it accepted?
[15:10] <apw> hrw once you know it does what you want send it up and i'll have a re-look at it fresh
[15:10] <hrw> ok
[15:11] <hrw> doing native full build now with this patch attached
[15:46] <apw> hrw got a link to the current patch ?
[15:48] <hrw> apw: http://launchpadlibrarian.net/51576134/linux-add-stage1-support.patch
[15:49] <apw> hrw, thanks
[15:52] <tgardner> gnarl, note sent to SRU team requesting Karmic acceptance
[15:53] <gnarl> tgardner, Ok, thanks. I guess I will see what happens  soon
[15:53] <gnarl> apw, Oh, I forgot to get back to you and nag you to try new tooling. :-P
[15:53] <tgardner> gnarl, did you already bang this out on a different list?
[15:54] <gnarl> tgardner, I have not done more than arguing with Colin and Martin
[15:54] <gnarl> tgardner, But that was on irc or the phone
[15:54] <tgardner> gnok, then this'll drag it out into the public
[15:54] <apw> heheh
[15:54] <tgardner> gnarl, ^^
[15:54] <apw> gnok gnok, who's there
[15:54] <gnarl> tgardner, ack
[15:55] <gnarl> apw, gnobody
[15:57] <apw> gnarl, we need an incantation for your maint scripts so they can find each other without needing path
[15:57] <apw> i use the same a lot in my shell scripts
[15:57] <apw> gnarl, t
[15:57] <gnarl> apw, Hm, I dont need that as they are in my path
[15:57] <tgardner> apw, CDIR=`dirname $0` sort of thing?
[15:57] <apw> yeah that sort fo thing, there is some subtlty for ./ i think
[15:57] <apw> gnarl, its not quick
[15:58] <apw> apw@dm$ maint-startnewreleaseII: linux-image-2.6.35-7-generic_2.6.35-7.11_i386.deb
[15:58] <apw> II: Downloading to kernel.ubuntu.com ...
[16:04] <bjf> moin all
[16:04] <cking_> pgraner, /sys/kernel/debug/tracing/buffer_size_kb
[16:11] <lag> pgraner: cat /sys/kernel/debug/tracing/current_tracer
[16:17] <pgraner> apw: http://pastebin.ubuntu.com/460671/
[16:20] <tgardner> sconklin, we're looking at a bug that might affect your living room laptop
[16:21] <sconklin> awesome. Only it's not in the living room any more. Susan practically threw it at me
[16:21] <tgardner> sconklin, bug #501715
[16:21] <ubot2> Launchpad bug 501715 in ureadahead (Ubuntu) "Kernel trace buffer should be cleared and size restored after profiling (affects: 52) (heat: 280)" [High,Triaged] https://launchpad.net/bugs/501715
[16:22] <sconklin> tgardner: that's evil
[16:25] <sconklin> It would also explain why it shows up on this laptop with only 1G of RAM in it
[16:26] <cking_> sconklin, echo 1 >/sys/kernel/debug/tracing/buffer_size_kb and see if the bug goes away
[16:26] <sconklin> cking_: well, it hasn't reproduced yet this boot, but I can do that and see if memory use changed significantly
[16:28] <tgardner> cnd, are you around?
[16:29] <cnd3> tgardner: yep
[16:29] <cnd3> what's up?
[16:29] <tgardner> cnd: mumble about tracing
[16:29] <cnd3> ahh, can't mumble
[16:29] <cnd3> I'm in the car
[16:29] <cnd3> is irc ok/
[16:29] <tgardner> cnd: drive, quit talking to me!
[16:29] <cnd3> ?
[16:29] <cnd3> heh, I'm a passenger
[16:29] <cnd3> I'm working
[16:30] <cnd3> I can skype if you want
[16:30] <cnd3> there's just no mumble iphone client afaik
[16:30] <apw> cnd3, how do i confirm that ftrace is off 100%
[16:30] <cnd3> apw, let me check
[16:30] <tgardner> cnd: thats OK, we just had some general questions about the tracing mechanism. it can wait
[16:31] <sconklin> cking_: that made no detectable difference in anything, including current memory use
[16:33] <cnd3> apw: echo 0 > /sys/kernel/debug/tracing/tracing_enabled
[16:33] <cnd3> there's also tracing_on
[16:33] <cnd3> I'm not sure of the semantics of the two
[16:33] <apw> cnd3, and if it is on, can i tell what if anything is enabled to be recorded?
[16:33] <gnarl> cnd3, If tracer us nop does it use up some resources?
[16:34] <gnarl> is
[16:34] <cnd3> apw: let me check
[16:34] <cnd3> gnarl: the tracer buffer can record function tracing and trace events
[16:34] <cnd3> so if current_tracer is no
[16:34] <cnd3> nop
[16:34] <cnd3> you won't get function traces, but you could still get trace events
[16:34] <gnarl> ok
[16:35] <cnd3> you can disable all trace events by:
[16:35] <apw> yeah thats my worry, so what events are on
[16:35] <apw> i need to know which ones
[16:35] <cnd3> echo 0 > /sys/kernel/debug/tracing/events/enable
[16:36] <cnd3> you can see which events are enabled:
[16:37]  * apw pokes cnd3
[16:37] <cnd3> yeah, I was trying to figure it out
[16:37] <cnd3> I thought there was an easy way
[16:37] <cnd3> you can look inside /sys/kernel/debug/tracing/events
[16:38] <cnd3> it's a hierarchy of events
[16:38] <cnd3> each folder has an enable file
[16:38] <cnd3> and enabling or disabling affects all children of the folder
[16:38] <cnd3> and each event (leaf nodes in the tree) has an individual enable
[16:39] <cnd3> but I'm not sure if there's any easier way to be sure
[16:39] <cnd3> now, I am guessing that if you disable the ftrace buffer then you probably don't have to worry either
[16:39] <cnd3> I think that's what /sys/kernel/debug/tracing/tracing_on does?
[16:40] <cnd3> let me check the docs
[16:40] <apw> cnd3, yeah we think we are ending up leaving ureadahead with its items turned on, and its putting tracing back to the previous value which may be on ... with a huge buffer configured ... and eating all your memory over time
[16:41] <tgardner> apw, tracing gets restored, but the buffer size is left large
[16:41] <cnd3> ahhh!
[16:42] <cnd3> let me play for a second
[16:42] <cnd3> tgardner, you mean the events get turned off?
[16:42] <cnd3> but they're already in the buffer?
[16:42] <apw> tgardner, so if it was on by default, with nothing enabled, then ureadahead  adds some trace points to record, then 'restores' the on off state to on, and quits
[16:42] <tgardner> cnd: the events _do_ get restored to their original values, dunno what the starting state was though
[16:42] <apw> it'll leave the events on
[16:42] <apw> hrm ok
[16:43] <cnd3> what are the events caallled?
[16:43] <apw> i'd think they'd be off by defualt, if it works
[16:43] <tgardner> apw, it sets events/fs/do_sys_open/enable, events/fs/open_exec/enable, events/fs/uselib/enable, and tracing_enabled after first reading their current values.
[16:43] <cnd3> apw, tgardner: is one of the events do_sys_open?
[16:44] <tgardner> cnd: events/fs/do_sys_open/enable
[16:44] <cnd3> tgardner: so it sets them to 0 after it's done?
[16:44] <sconklin> cking_, tgardner: I applied the startup script workaround and rebooted, and base memory usage dropped by about 100M.
[16:44] <tgardner> cnd: no, it restores them to their original values
[16:45] <cnd3> tgardner: what does that mean?
[16:45] <cnd3> this is at boot up
[16:45] <cnd3> so I'd assume 0?
[16:45] <tgardner> cnd: we could assume taht, but I don't know for sure.
[16:45] <cnd3> I guess you can turn them on at the command line
[16:46] <cnd3> so what we really need is just a way to clear out the ftrace buffer after use?
[16:46] <tgardner> cnd: the only parameter that ureadahead doesn't restore is buffer_size_kb
[16:46] <apw> tgardner, i think for this behaviour to be the cause it would have to be failing to restore them then
[16:47] <apw> and we should get pgraner to run: cat `find /sys/kernel/debug/tracing/events/ -name enable` | grep -v 0
[16:47] <cnd3> also, I think the buffers are preallocated
[16:47] <apw> on the system which he cleaned up
[16:48] <cnd3> I guess maybe ureadahead is setting the buffer size too large and we need to reset it back to a reasonable default
[16:48] <cnd3> but it wouldn't show an increase in usage over time
[16:48] <tgardner> apw, well, the restore code looks right. 
[16:48] <apw> i was more thinking some case in which it doesn't do it at all
[16:48] <apw> if not pete simply has a little time to wait for the issue to return
[16:49] <tgardner> apw, about the only place I can see that would happen is if the daemonize fails
[16:54] <sconklin> well, I've applied the workaround, and I'm still running a kernel with kmemleak debugging turned on - so if it happens again maybe I'll have a clue
[16:55] <cnd3> sconklin: what's the work around?
[16:55] <cnd3> hrm, one bar of signal, I may be lost soon
[16:56] <cnd3> oh at&t...
[16:57] <sconklin> cnd3: http://ubuntuforums.org/showthread.php?p=9271524#post9271524
[16:59] <cnd3> wth, why is the buffer size being set to 128 MB!
[16:59] <cnd3> that's per cpu!
[16:59]  * cnd3 thinks the param used to be in bytes, meaning 128 kb, so maybe this was overlooked?
[17:00] <cnd3> ureadahead really need to be resetting that to the defaults after it changes them
[17:00] <tgardner> cnd: I'm working on that.
[17:00] <cnd3> k
[17:01] <cking_> if it's per CPU that explains why i7 machines are suffering
[17:02] <cnd3> is this something new in maverick?
[17:02] <cnd3> or in lucid and earlier?
[17:02] <jjohansen> cnd3: I don't think it was ever supposed to be kb, the server team hit problems last cycle with this keeping small vms from booting
[17:02] <tgardner> cnd: same code in Lucid at least
[17:02] <jjohansen> cnd3: definitely in lucid
[17:02] <tgardner> have not checked earlier
[17:03] <cking_> yep, we are seeing it hit hibernate on Lucid
[17:03] <apw> cnd3, per CPU, now that would explain a fwe things
[17:03] <cnd3> yes, I'm 99% sure it's per cpu
[17:03] <cking_> cnd3, it looks like it in the code
[17:04] <cnd3> I'm not as sure that it preallocates though
[17:04] <cnd3> I just thought so
[17:05] <apw> i suspect not as mine say 'reallocated' and lots of coutns on it
[17:06] <apw> but it could get full up over time for sure ... and that'd be 1GB on petes machine
[17:06] <cnd3> I may have been thinking of the profiling buffers
[17:06] <cnd3> I know the profiling statistics are kept in preallocated buffers
[17:06] <cnd3> but those buffers are different from the ftrace event buffer
[17:11] <apw> cnd3, if you have a chance to investigate could you look at whether the buffer size is simply a minimum
[17:11] <apw> ie the preallocated size, as i am seeing this in my siz
[17:12] <apw> 7 (expanded: 1408)
[17:12] <cnd3> sure
[17:12] <cnd3> I'll look right now
[17:12] <cnd3> what's this "7 (expanded: 1408)"?
[17:12] <apw> that is whats in my size
[17:13] <apw> apw@dm$ cat buffer_size_kb
[17:13] <apw> 7 (expanded: 1408)
[17:13] <cnd3> I only have the maverick kernel right now though
[17:13] <apw> so i am wondering if it can expand or not
[17:13] <cnd3> yeah, in maverick the semantics changed
[17:13] <cnd3> cat buffer_size_kb:
[17:13] <cnd3> 128000
[17:14] <gnarl> cnd3, I got both outputs for lucid on two machines... odd
[17:14] <apw> i think its different if you set it and not, or something
[17:14] <cnd3> hmmm
[17:14] <apw> or the setting is the minimum and it can expand, or, hence the question
[17:15] <cnd3> yeah
[17:24] <mdz> apw, hi
[17:24] <apw> mdz, hi
[17:24] <mdz> apw, pgraner was just telling me that this may be related to tracing being enabled
[17:25] <tgardner> apw, just emailed a ureadahead patch that you should experiment with. I have to take off.
[17:25] <apw> mdz we have found a couple of scenarios where machine are very unhappy if ureadahead has left the tracing buffers expanded
[17:25] <mdz> apw, how can I check if that's the case on my system?
[17:25] <apw> tgardner, ta will look tommorrow
[17:25] <mdz> perseus:[/sys/kernel/debug/tracing] cat current_tracer 
[17:25] <mdz> nop
[17:25] <mdz> perseus:[/sys/kernel/debug/tracing] cat tracing_enabled 
[17:25] <mdz> 1
[17:25] <apw> mdz cat the buffer size one
[17:26] <mdz> apw, perseus:[/sys/kernel/debug/tracing] cat current_tracer 
[17:26] <mdz> nop
[17:26] <mdz> perseus:[/sys/kernel/debug/tracing] cat tracing_enabled 
[17:26] <mdz> 1
[17:26] <mdz> er
[17:26] <mdz> 128000
[17:26] <apw> it will only be big if you had a ureadahead rebuild last time
[17:26] <apw> yeah like that... the current thought is that this is 128MB per cpu
[17:26] <apw> cnd3, is confirming what the size means currently
[17:27] <apw> but ... we suspect this isn't a good thing generally and may be triggering OOM situations for pete doing CD reads
[17:27] <mdz> apw, the system has been feeling memory-starved lately indeed
[17:27] <mdz> I thought it was chromium
[17:27] <apw> so you can set that to 0 i believe to free it up
[17:27] <apw> see if it feels any better then
[17:28] <mdz> apw, EINVAL
[17:28] <apw> hrm
[17:28] <mdz> apw, write 0 to tracing_enabled instead?
[17:28] <apw> mdz one sec, just want to confirm how pete did it
[17:29] <cnd3> apw, mdz: it is per-cpu, and it is preallocated
 sconklin, echo 1 >/sys/kernel/debug/tracing/buffer_size_kb and see if the bug goes away
[17:29] <apw> mdz so apparently 1
[17:29] <cnd3> apw, I think it won't matter
[17:29] <mdz> before:
[17:29] <cnd3> it will always set it to be at least 2 pages in size
[17:29] <mdz> Mem:          2993       2425        568          0         13        380
[17:29] <mdz> after:
[17:29] <mdz> Mem:          2993       2003        990          0         16        411
[17:30] <mdz> i.e. ~400MB freed
[17:30] <apw> a fair chunk then
[17:30] <sconklin> apw: already tried that and saw no change. But it was not exhibiting the problem when I did it, and the problem has not happened in the last few days. It typically takes 2-4 days of use before it gets into swapping
[17:31] <apw> sconklin, sorry was repeating that for mdz not for you :)
[17:31] <cnd3> mdz, looks like you got 422 MB back ;0
[17:31] <cnd3> :)
[17:31] <mdz> yep
[17:31] <apw> 3.29*128 MB ... erm thats an odd number
[17:32] <cnd3> mdz, how many processors do you have?
[17:32] <cnd3> including HT
[17:33] <mdz> apw, I'm logged into a desktop session with gwibber, chromium and openoffice.org running, so who knows what sort of other allocations were made during that time ;-)
[17:33] <mdz> cnd3: Core 2 Duo T7500
[17:33] <mdz> so 2 cores, both HT
[17:33] <cnd3> ok, so linux sees 4
[17:34] <apw> i wonder if you have to read the resst
[17:34] <apw> cnd3, how do you find out whats in the buffer and dump it ?
[17:34] <cnd3> cat /sys/kernel/debug/tracing/trace
[17:34] <cnd3> you can use trace_pipe if you want to get rid of everything in it
[17:35] <apw> mdz could you see if there is anything in there
[17:36] <mdz> apw, empty
[17:39] <cnd3> I gotta jump off for a bit
[17:39] <cnd3> I'll be back after lunch
[18:14]  * apw wanders out to see what the sun looks like
[18:15] <cking_> it's shiny and bright apparently
[18:16] <manjo> apw, I dragged you out to the balcony
[18:32] <osmosis> if i look at the changelog for  linux-image-server ...all it says is  * Lucid ABI 23
[19:26] <awe> pong
[19:42] <JFo> manjo, I'm about to send out the CFT for firewire in a bit. Is the new stack enabled in the latest released kernel or do they need to pick it up from a PPA?
[19:43] <manjo> JFo, all the changes should be now avaiable without any ppa
[19:43] <JFo> ok, cool
[19:43] <JFo> manjo, in Lucid and Maverick yes?
[19:44] <manjo> JFo, we are only focusing on Maverick
[19:44] <manjo> JFo, no lucid
[19:44] <JFo> cool, thanks :)
[20:05] <JFo> Firewire CFT sent to everybody
[20:08] <manjo> JFo, also there were a few audio mailing list iirc 
[20:08] <JFo> you only told me about the mythtv one
[20:08] <JFo> so I sent to them and a ton of others
[20:15] <abhi_nav> what is firewirestack?
[20:18] <manjo> abhi_nav, https://ieee1394.wiki.kernel.org/
[20:18] <abhi_nav> manjo, ok
[20:19] <abhi_nav> manjo, can I ask you something ? you are free to talk?
[20:19] <manjo> abhi_nav, sure
[20:20] <abhi_nav> manjo, got email from bugsquag that firewire need to test. and on that wiki page it is writen that nothing to instal. i am on lucid. so how to test?
[20:20] <manjo> abhi_nav, the call for testing went out for maverick
[20:21] <manjo> not for lucid
[20:21] <abhi_nav> manjo, so i need to have maverick installed?
[20:21] <manjo> you can boot from a maveric usb stick 
[20:21] <manjo> ie live image and test 
[20:22] <manjo> abhi_nav, do you have a firewire port on your system ?
[20:23] <abhi_nav> manjo, i dont know. i still dont knwo what firewire is. is it software or hardware. on the link give i cant find defition of firewire
[20:23] <abhi_nav> :(
[20:23] <manjo> abhi_nav, google is your friend :)
[20:23] <osmosis> if i look at the changelog for  linux-image-server ...all it says is  * Lucid ABI 23   What does that mean?
[20:23] <abhi_nav> manjo, I googled
[20:25] <manjo> abhi_nav, http://computer.howstuffworks.com/firewire1.htm
[20:25] <manjo> for example 
[20:26] <abhi_nav> manjo, ok thanks I wll look at it
[20:26] <manjo> drivers are need to make that device work in linux 
[20:26] <manjo> and we just switched from the old drivers to new driver model
[20:26] <manjo> modules
[20:27] <manjo> we would like to make sure that there are no regressions etc and the new modules work just as well or better 
[20:28] <abhi_nav> manjo, ok
[20:40] <abhi_nav> manjo, i understool.
[20:40] <abhi_nav> understood.
[20:45] <abhi_nav> manjo, and also I come to know that I dont have it in my lappy. :)
[20:46] <manjo> abhi_nav, thanks for trying 
[20:46] <abhi_nav> manjo, yah
[20:48] <JFo> abhi_nav, thanks for asking though :)
[20:48] <JFo> we are thankful that you were willing to test :)
[20:49] <abhi_nav> JFo, :)
[20:49] <JFo> :D
[20:55] <jjohansen> -> Lunch
[20:57] <manjo> JFo, modified that wiki page 
[20:57] <JFo> thanks manjo 
[20:57]  * manjo heading out for Dr appt