[05:31] anyone know a good place to learn some tips to compiling a kernel [05:31] like what options i don't need or how to shrink my kernel and such? [05:31] or any speed optimizations? [05:31] or is it all pretty much learn it on your own and trial and error? [05:37] well the kernel team knowledge base has a lot of useful info for dealing with Ubuntu kernels [05:37] https://wiki.ubuntu.com/KernelTeam/KnowledgeBase [05:38] Dealing with upstream kernels is a little different, look at kernel.org [05:39] and kernelnewbies.org [05:40] billybigrigger_: there certainly is a bit of trail and error but there is a lot of good documentation [05:40] As for speed optimizations, the is a matter of setting the configs for your situation [05:42] eg. If you don't need SMP you can get a little speed boost by turning it off. But then your kernel will only work on with a single thread/core on newer cpus [05:43] figuring out which config options you want is going to be the hardest part. [05:44] You can compare what the different distros do, that will give you a feel for what is needed for generic style kernel. And then you can start turning stuff off (well for the most part, you may turn a few things on) [05:45] but if you are looking to speed up a generic kernel with some magic config it isn't going to happen. [06:19] RFC2828 includes a definition of 'proxy server'. In two commentaries of this definition the term 'proxy' is used (not 'proxy server'). Does this use of 'proxy' mean a short-hand for 'proxy server' or what does proxy stands here for? [06:20] s/stands/stand/ [12:11] cjwatson, iscsitarget -- would a test kernel be of use? if so what arch? [12:15] i386 [12:15] actually I can probably put together something for myself from the iscsitarget source package and svn ... [12:16] I don't need to ship this, it's just for local use while testing [12:16] cjwatson, i've just pulled ours up to that svn you pointed to, [12:16] and was going to compile test it, so might as welll make you a kernel you can use to validate it [12:16] ok - is it ABI-compatible with -3? [12:16] ideally I'd just insmod something [12:17] oh, -generic, btw [12:17] its wholey contained within its own dir, so i assume its compatible yes. [12:17] i will be making a whole kernel as part of the test [12:18] let me make just the .ko and you can try insmoding it [12:23] cjwatson, try: http://people.canonical.com/~apw//iscsitarget/ [12:30] insmod: error inserting 'iscsi_trgt.ko': -1 Invalid module format [12:30] hmm [12:30] iscsi_trgt.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped [12:30] Jul 17 12:30:05 sarantium kernel: [105134.078592] iscsi_trgt: no symbol version for module_layout [12:31] does it need to be modposted or something? [12:31] (er, please excuse me not really knowing what I'm talking about) [12:32] hrm ... oddness [12:36] apw, Did you compile the whole kernel or just the module? [12:36] i compiled just the module. [12:36] it did get modposted [12:36] maybe it also misses the whole modules versions [12:37] bah, i'll just build the whole thing [12:37] from the external symbols [12:37] its only computrons [12:37] And it keeps you warm :) [12:38] I'll try updating the external package locally here [12:40] cjwatson, it would almost be preferable for you to test the real kernel [12:41] well, FWIW the external module at least builds fine once updated, but I'm entirely happy to test the real kernel too [12:41] of course I have to figure out how to use the userspace stuff ;-) [12:42] hehe 'instant expert' time again huh [12:42] just add coffee [12:42] :) [12:43] cjwatson, i assume its you who i need to make sure is aware we reinstated aufs [12:43] I saw the mail on ubuntu-installer@ [12:43] (and replied, actually) [12:43] hrm. damned too much email [12:43] oh, it's uploaded, cool - in that case current desktop images should actually already be using it [12:44] I didn't change the default to unionfs-fuse, I just made it a fallback in case aufs was missing [12:44] very nice ... handy for ever more for sure, particulalrly for alpha-1 kernels [12:45] modules is the same name so we should be good [12:48] * hyperair wonders if iwlagn takes up 100% cpu from time to time for anyone around here [12:49] not that i've seen on my kit. i did have it blow its tx queue once since i hit 2.6.31-3 [14:19] amitk_ hi [14:23] apw: Dave Morley reports that aufs is happily in use on today's live CD [14:23] cjwatson, most excellent thanks for the report [14:23] cjwatson, but is it 'quickly' in use? i.e., faster then FUSE? [14:23] i hammered the hell out of it before i committed it, but you do never know [14:23] dinh: hi [14:24] how do you do? [14:24] amitk: good thanks...manoj mentioned you have some prior experience with lauterbach? [14:24] dinh: yes [14:24] on OMAP2/3 platforms [14:25] i'm been able to debug with source level debuggin on our bsp, with your 2.6.31, my lauterbach script can't seem to be able to locate the source code after loading the .vmlinux file [14:26] do i need to do a KBUILD_OUTPUT with your tree? [14:28] dinh: not sure. Are you using load.elf? [14:28] yes... [14:29] * amitk_ tries to dredge up his lauterbach .cmm files [14:29] perhaps I can you send our .cmm file that we use to load? [14:29] amitk_, the armel config we have in karmic ... i note we have a lot of stuff 'off' for arm is there a reason that things are this way ... for example most of CRYPTO [14:30] apw, the config in karmic isn't for imx51 it's for imx31 [14:31] dinh: sure. send it over. [14:31] apw, I don't think that config is any good (I don't know that anyone has actually looked at that config) [14:31] apw: the config is FOOBAR currently. === amitk_ is now known as amitk [14:31] amitk_, so would it be sane for me to try and commonise some of those options then [14:32] on the assumption you are going to replace the armel config anyhow when the code is fixed [14:32] apw: for arch-independent stuff, feel free to enable it all. That way when we add the imx51 config, we'll know what we forgot to turn on [14:33] thanks [14:36] amitk: nevermind, i think i just figure it out...hold off on looking at the cmm file... [14:37] ack [15:19] amitk: hi amit [15:20] yo amitk [15:22] dinh: hi [15:22] yo manjo [15:23] amitk: what i'm seeing is that after some time, the system goes to turn off the display(ipu), it disables the IRQ for the IPU [15:24] but it seems like all IRQs have been disabled because the command prompt is also not responding [15:28] dinh: you mean at the login prompt? [15:28] yeah [15:29] dinh: could it be something simpler related to MXC_CONSOLE? [15:31] amitk: hmm...can you explain more by MXC_CONSOLE? [15:33] dinh: is CONFIG_SERIAL_MXC_CONSOLE=y ? and if so, is that code correct? [15:34] perhaps a better question is, does lauterbach show that all IRQs are disabled? or are you guessing? [15:35] random Q [15:35] why doesn't broadcom wireless work in Karmic? [15:35] how can I make it work? [15:35] Keybuk, its a dkms package [15:35] rtg_: how do I install it? [15:35] what's it called? is it on the CD image? :) [15:35] bcm-source (i think), tseliot is the maintainer [15:37] we got rid of lrm entirely right? [15:37] Keybuk, entirely, ling live lrm :) [15:38] jjohansen, can you update status on bug #359338 [15:38] Malone bug 359338 in linux "apparmor paths are broken when using ecryptfs on jaunty" [High,Confirmed] https://launchpad.net/bugs/359338 [15:40] Keybuk, bcmwl-kernel-source [15:45] rtg: ack doing it right now [15:46] amitk: the console code looks correct...from my lauterbach, i see that we try to disable the IPU_SYNC irq(11), we call disable_irq(), then it get stuck in synchronize_irq [15:46] in synchronize_irq, we're stuck in the loop that will not let us get out because it thinks we're in a critical section [15:56] amitk: while (desc->status & IRQ_INPROGRESS) cpu_relax(); [15:56] hmm [15:57] amitk: i cleared the desc->status IRQ_INPROGRESS bit and the login prompt is alive again === cjwatson_ is now known as cjwatson [16:01] dinh: so you suspect some irq handler is stuck? [16:02] amitk: yes [16:03] dinh: is the trigger always the IPU turn off display code? [16:04] yes [16:05] I guess IPU is trying to release the clocks and idle dynamically when it sees no user activity [16:08] yes, the ipu will turn off after some period of inactivity [16:21] dinh: you could try disabling that? Is it done through the suspend callbacks? I can see a call to mxc_pg_enable in the suspend callback of the ipu3 driver [16:21] perhaps comment that out? [16:23] amitk: i [16:23] amitk: sorry..we look at it some more..but i'm pretty sure its ipu related code, because our system has been running for a long time now that the ipu is asleep [16:26] manjo, ping [16:26] dinh: drivers/mxc/ipu3/ipu_common.c:ipu_suspend() Trying commenting out the mxc_pg_enable in that if you feel like a quick test [16:26] pong [16:27] manjo, got time for a quick call (i'll call you)? [16:27] bjf, can you we do it in 30mts or so ? [16:28] manjo, yes, let me know [16:28] bjf: manjo: dinh: I've gotta run a few errands. It being Friday evening 6:30pm and all. Will be back later... [16:28] amitk, we are in ipu_common .. making some mods [16:28] amitk, cya soon [16:28] manjo: cool [17:01] bjf, you want to call ? [17:01] manjo, yes [17:01] k can you call my cell ? [17:02] manjo, I think I have that number [17:56] jj so we still clone regression outstanding [18:02] apw: yes [18:24] thanks [21:14] I want to help, tell me how [21:15] * MT- enjoys opening can-o-wormies on self w/ already busy schedule :)_ [21:16] MT-, you could take part in the ubuntu kernel bug day [21:16] and look at some of the kernel bugs [21:16] what day is that? [21:16] I think the next one is Tue 21st [21:16] MT-, let you point you to the wiki ... [21:19] MT-, https://wiki.ubuntu.com/KernelTeam/BugDay/20090721 [21:21] manjo: sounds like fun [21:22] MT-, http://qa.ubuntu.com/reports/ogasawara/kernel-buglist.html [21:24] wow [21:28] MT-, ping ogasawara, will get you set up if you want to contribute [21:28] ogasawara: remember me? I wanna be on the other side now :) [21:29] manjo: thanks [21:29] MT-, np [21:33] manjo: I've been working on ubuntu-drupal stuff and 3/5 of the projects are basically done. Just little tweaks left abd probably bug reports. Two devs are working on the other 2 and I'll work on finishing those when they're done. After that I think I'll try to leave the project in the hands of the other devs and move on to kernel stuff and motu [21:33] manjo: do kernel and motu merge well together? [21:34] MT-, you have to ask the motu guys ;) === Omegamoon is now known as Omegamoon|kraftw === Omegamoon|kraftw is now known as Omegamoon === Sarvatt_ is now known as Sarvatt