[10:23] <cooloney> hughhalf: i am back to home now with a winery machine, sorry for the confusing email from my iphone, heh
[10:23] <cooloney> ikepanhc: did you got the winery machine?
[10:40] <apw> Keybuk, i see we 'randomly' broke 18s today
[10:40] <Keybuk> yeah, those minis must love the cold
[10:41] <apw> heheh ... yeah leave the heating off and we'll hit the target
[10:42] <apw> 6.71 to X ready ... now thats encouraging
[10:42] <Keybuk> work for this week is to get the new mountall in
[10:42] <Keybuk> that'll mean we can use devtmpfs
[10:43] <Keybuk> that might save a lot of mknod() leather
[10:43] <Keybuk> and then will be able to profile udev's rules to see what's taking the time
[10:43] <Keybuk> whilst also being much more ready to drop plymouth in
[10:43] <apw> Keybuk, i assume the exec of upstart is the gap between the end of wait-for-root and the start of mountall
[10:43] <Keybuk> apw: most of the gap is cleaning up the initramfs actually
[10:43] <apw> yeah that sounds awsome ... those mknods are sync i think
[10:44] <apw> Keybuk, hrm, is there any reason for that to be sync?
[10:44] <apw> of course fixing that means looking in busybox ... gah
[10:44] <Keybuk> probably not, but then in actual numbers it takes about 0.05s on my testing
[10:44] <Keybuk> klibc not busybox
[10:45] <Keybuk> part of the gap between wait-for-root is also the time it takes to mount the ext4 root
[10:45] <apw> ahh fair enough ... hard to profile that gap for sure
[10:46] <apw> Keybuk, so do you think plymouth will slot in this week or is that a later thing
[10:47] <Keybuk> I think I'll put Plymouth in in the new year
[10:48] <Keybuk> will see how things work out timing wise
[10:48]  * apw notes that apparmor is showing up twice in userspace still
[10:48] <apw> as waht looks like an upstart job, and as D37apparmor
[10:48] <apw> S37
[10:48] <Keybuk> yeah
[10:48] <apw> that seems unlikely to be right
[10:49] <Keybuk> lots of fruit to hit with the shotgun yet :p
[10:50] <apw> bah no jj to hastle 
[11:00] <Keybuk> I like the fact that Phoronix can't read bootcharts
[11:00] <Keybuk> they've published 9.10 and 10.04 Alpha 1 charts
[11:00] <apw> Keybuk, where are those
[11:00] <Keybuk> it makes it look like we dropped from 59s to 24s
[11:00] <Keybuk> http://www.phoronix.com/scan.php?page=article&item=ubuntu_lucid_short&num=1
[11:02] <apw> they also think our kernel is 2.6.31 based
[11:04] <Keybuk> yeah, Phoronix's reporting is always ... comical a best
[11:04] <Keybuk> wavingly inaccurate at worst
[11:04] <apw> it puts their output in context for sure
[11:06]  * apw reads their previous article, on performance in 10.04 being terrible
[11:07] <apw> where the first test they say we consume 2x the CPU, while ignoring the fact we also averaged 2x the frame rate
[11:07] <Keybuk> yeah, they have their test suite, and they're sticking with it
[11:08] <Keybuk> "omgz! Ubuntu takes twice as long to do twice as much" etc.
[11:11] <apw> Keybuk, what standard-version does one have to be at to get the new upstart understanding dh_initcall |
[11:11] <Keybuk> no idea
[11:16] <apw> Keybuk, ok this double apparmor thing is cause networking needs some of apparmor to secure the network, and the main startup is still in sysv init
[11:16] <Keybuk> sure, that's a bug
[11:16] <apw> sounds like upstartification of apparmor might save some duplicated effort
[11:16] <Keybuk> the main startup needs to be moved to upstart too ;)
[11:16] <apw> heh
[12:56] <mihu> Hi. I need to recompile one single kernel module of my currently running kernel. I think I tried the most straight-forward way: "apt-get source linux-source-2.6.31" (which will apply linux_2.6.31-16.53.diff.gz), "cd linux-2.6.31", "cp /boot/config-2.6.31-16-generic .config", "make drivers/media/video/mxb.ko". Unfortunately, insmod'ing the new module fails with "-1 Invalid module format", dmesg says "no symbol version for module_layout". An
[13:01] <apw> mihu you should only need the headers installed to compile the module
[13:02] <apw> /lib/modules/2.6.31-17-generic/build is your 'source' for a make
[13:03] <apw> it has the config etc and all the headers etc your module should need
[13:04] <mihu> apw: Ok, I understand. But I want to rebuild the module from the official source tree. Is it possible to do that without copying the source code around?
[13:07] <mihu> I can understand that "apt-get source linux-source-2.6.31" and copying the .config around does not produce the correct environment for recompiling a kernel module, although this disappoints me a little bit.
[13:08] <apw> mihu, which thing did you get, you say linux-source up there
[13:08] <apw> apt-get source linux-2.6.31....-generic ought to
[13:10] <mihu> apw: Yes, plain "linux-2.6.31" (no "generic") because it said "Linux kernel source for version 2.6.31 with Ubuntu patches". "aptitude search linux-source" does not show any package with generic, unfortunately.
[13:10] <mihu> apw: Just "linux-source", "linux-source-2.6", "linux-source-2.6.31".
[13:11] <apw> yep but you can ask for the source for the binary packages, and thats the right way to get the source package for making a kernel
[13:16] <mihu> apw: Ok, I understand. If I do "apt-get source linux-image-2.6.31-16-generic" then I get the same source tree, so the problem persists.
[13:17]  * apw downloads it
[13:18] <mihu> apw: Thanks for helping me out. Actually you can try the same steps as above, even if you don't have the hardware.
[13:19]  * apw is going to compare it to the tree that the source package was built from
[13:24] <mihu> apw: Now I tried "make drivers/media/video/mxb.ko" in "/lib/modules/2.6.31-16-generic/build", but this does not get far. "make[1]: *** No rule to make target `kernel/bounds.c', needed by `kernel/bounds.s'.  Stop"
[13:29] <apw> yeah that is mixing two use models
[13:33] <apw> mihu, ok i don't quite understand what apt-get source thinks it is doing as for me it gets the latest source regardless of what i think i am asking for
[13:35] <apw> can you configmr the version in the top of devian/changlog matches uname -r
[13:38] <alex_joni> afaik apt-get source is not quite right in this case, it will get the latest sources for 2.6.31
[13:38] <alex_joni> you probably want apt-get install linux-source or linux-headers
[13:38] <alex_joni> for the specific package name
[13:39] <apw> the easiest way to get the exact source for the version is to get the source from our kernel git repository
[13:39] <apw> which has tags for each version
[13:40] <apw> i am puzzled by apt-get source's behaviour, i am assuming its a archive limitation
[13:40] <mihu> apw: Sorry, which file do you mean? "debian/changelog" Where should I look for it?
[13:40] <apw> top line, does that version number match your uname -r
[13:40] <mihu> alex_joni: Thanks for your help. That's fine with me. All I want to do is to recompile "drivers/media/mxb.ko" against my currently running kernel.
[13:41] <apw> i am suspecting it does not, this is from the apt-get source linux-image-xxx-generic
[13:41] <apw> i think you said you have a -16 binary installed, and i suspect your source will be the -17.54 from -proposed
[13:41] <mihu> apw: It says (2.6.31-16.53), while uname -r is "2.6.31-16-generic".
[13:42] <alex_joni> then use modinfo on the fresh compiled module
[13:42] <apw> then that may well be the right version hrm
[13:42] <alex_joni> and see what it says
[13:43] <mihu> alex_joni: "modinfo drivers/media/video/mxb.ko" looks sane, but the file is huge (212kB) in comparision to the original file which is about 22kB. 
[13:43] <mihu> apw: I think the version is alright. It's just that somehow the build does not produce loadable modules. This puzzles me.
[13:43] <apw> its like not stripped, images are first makde debug
[13:43] <alex_joni> yup
[13:44] <mihu> apw: Ok, it's build with debug turned on, I understand.
[13:44] <apw> http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
[13:44] <apw> that web page details how to get a module build, as an external module
[13:45] <apw> so you could try pulling mbx.c out of the tree you have there and building it in that way
[13:45]  * apw has to admit he normally just builds the whole kernel
[13:46] <apw> and right now he has a pre-release installed and can't get launchpad to give him the right source to do a test ... arrrg
[13:48] <mihu> apw: Thanks for the link. I tried pulling out mxb.c and could produce a working kernel module. Now you say, so then do this instead. But I have a usability problem. I want to modify various other modules as well afterwards and I don't like the idea of copying source files around just to compile them. Ideally I want to compile them from the source tree I grabbed, so I can diff them easily later on.
[13:52] <mihu> Ok, I think I found something. The original "mxb.ko" has "vermagic:       2.6.31-16-generic SMP mod_unload modversions 586". My new "mxb.ko" has "vermagic:       2.6.31.4 SMP mod_unload modversions 586". The "Makefile" indeed says "EXTRAVERSION = .4", while Debian/Changelog says (2.6.31-16.53). I'm confused.
[13:54] <mihu> Hm. /lib/modules/2.6.31-16-generic/build/Makefile says "EXTRAVERSION = .4" as well.
[15:02] <mihu> Ok, I give up. I copied the source for my kernel module to a separate directory. Once I tried " make -C /tmp/linux-2.6.31/  M=`pwd`modules", the other time I did "make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules". The former did not produce a correct module, while the latter did. The problem is in the run of "modpost". For the former, the file "mxb.mod.c" will look differently and the ____versions[] array does not contain any of t
[15:04] <matti> mihu: .. any of t..?
[15:04] <mihu> ... any of the unresolved symbol names that this module requires.
[15:05] <matti> :)
[15:05] <mihu> I am now checking Module.symvers...
[15:13] <mihu> Ok, success. The goal is to recompile one single kernel module from the currently running kernel. "apt-get source linux-source-2.6.31" , "cd linux-2.6.31", "cp /boot/config-2.6.31-16-generic .config". Then you can do "make -C /usr/src/linux-headers-`uname -r` M=`pwd` drivers/media/video/mxb.ko" to compile one single kernel module.
[15:13] <matti> :)
[16:06] <apw> shame he is gone, that makes sense now, as EXTRAVERSION gets overridden in the debian build system
[16:10] <apw> jjohansen, i uploaded the -ec2 kernel you tested for me last week
[16:10] <apw> and i'll be spinning another one 'soon' for testing.  will let you know when its done
[16:10] <jjohansen> sweet, and will do
[16:14]  * apw sighs at the sheer size of the 2.6.32.2 update.  i am so glad we don't have to SRU them at this stage
[16:19] <tjaalton> apw: get this one too, otherwise r600+ fails to boot http://marc.info/?l=dri-devel&m=126137027403059&w=2
[16:20] <apw> tjaalton, with kms or always?
[16:20] <tjaalton> apw: kms, but it's on by default now..
[16:20] <apw> tjaalton, indeed just interested in just how bad
[16:22] <apw> tjaalton, unfortuanate he says 2.6.32.2 in it given it didn't make .2 ... do we know why it didn't get sucked up?
[16:22] <tjaalton> apw: this was post .32.2
[16:22] <tjaalton> just an oversight I guess
[16:23] <apw> thanks for the pointer ... i'll add it to my list
[16:24] <apw> tjaalton, how is radeon KMS shaping up ?
[16:24] <tjaalton> what about the four I sent to the list? some or all of them might already be in .2
[16:24] <tjaalton> I'm not sure, tormod should be better suited to answer that :)
[16:24] <tjaalton> I lack the hw
[16:25] <tjaalton> but there have been some bugs reported
[16:26] <apw> tjaalton, what was the subject on those four?
[16:26] <tjaalton> [git pull] drm fixes (fwd)
[16:27] <tjaalton> oh, nine commits not four
[16:27] <apw> ahh a git pull ... must get that fixed so patchworks shows git pull requests
[16:32] <tjaalton> what about nouveau? the debian kernel team wants to pull it for squeeze and asked debian-x@ for comments if it's a good idea or not (no replies so far, though)
[16:34] <Sarvatt> is "drm/i915: remove render reclock support" in that by any chance? :D
[16:35] <tjaalton> no, they were mainly for radeon
[16:37] <rtg> tjaalton, I think nouveau is going to have to be an LBM package. the required DRM changes are reported to be extensive.
[16:38] <tjaalton> rtg: only four changes to the core
[16:38] <tjaalton> *commits
[16:38] <apw> yeah there is a possibility we can get it in, its on my list to build this branch up
[16:38] <apw> hope to get to it tommorrow am
[16:39] <rtg> tjaalton, apw: how about sending the commits on the k-t list as well?
[16:40] <tjaalton> rtg: nouveau? is forwaring them like that radeon one ok?
[16:40] <tjaalton> +d
[16:40] <apw> rtg i have a branch someone sent me to look at
[16:40] <apw> i've just had a sec to, hoping to get to it next
[16:42] <rtg> tjaalton - I was just interested in the commit IDs, maybe gitweb URLs.
[16:43] <apw> rtg i'll find that branch and send you a copy
[16:43] <rtg> thinks
[16:43] <rtg> thanks*
[16:48] <tjaalton> the branch(es) has/have probably changed since, but the emails have a list of commits
=== Jeeves__ is now known as Jeeves
=== Jeeves is now known as Jeeves_
[20:56] <lcra> hey, folks. when 2.6.33-rc is going to be packaged for lucid? any chance to get it off some ppa in advance?
[21:08] <joaopinto> lcra, check the topic, 2.6.32 will be the version for lucid
[21:08] <lcra> joaopinto: so this is final? to effort is going to be put to package it even for experimentation?
[21:09] <lcra> no*
[21:09] <joaopinto> lcra, afaik yes, it's final
[21:09] <joaopinto> I believe there is a ppa with the latest kernel, if you really want to experiment
[21:11] <joaopinto> lcra, https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[21:11] <lcra> any particular feature backports possible for kernel in lucid? i'd personaly like to have write barrier support on md raid10