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