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:23 |
apw | Keybuk, i see we 'randomly' broke 18s today | 10:40 |
Keybuk | yeah, those minis must love the cold | 10:40 |
apw | heheh ... yeah leave the heating off and we'll hit the target | 10:41 |
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:42 |
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:43 |
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:44 |
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:45 |
apw | Keybuk, so do you think plymouth will slot in this week or is that a later thing | 10:46 |
Keybuk | I think I'll put Plymouth in in the new year | 10:47 |
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:48 |
Keybuk | lots of fruit to hit with the shotgun yet :p | 10:49 |
apw | bah no jj to hastle | 10:50 |
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:00 |
apw | they also think our kernel is 2.6.31 based | 11:02 |
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:04 |
* apw reads their previous article, on performance in 10.04 being terrible | 11:06 | |
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:07 |
Keybuk | "omgz! Ubuntu takes twice as long to do twice as much" etc. | 11:08 |
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:11 |
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 | 11:16 |
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 | 12:56 |
apw | mihu you should only need the headers installed to compile the module | 13:01 |
apw | /lib/modules/2.6.31-17-generic/build is your 'source' for a make | 13:02 |
apw | it has the config etc and all the headers etc your module should need | 13:03 |
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:04 |
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:07 |
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:08 |
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:10 |
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:11 |
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:16 |
* apw downloads it | 13:17 | |
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:18 |
* apw is going to compare it to the tree that the source package was built from | 13:19 | |
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:24 |
apw | yeah that is mixing two use models | 13:29 |
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:33 |
apw | can you configmr the version in the top of devian/changlog matches uname -r | 13:35 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 | |
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:46 |
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:48 |
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:52 |
mihu | Hm. /lib/modules/2.6.31-16-generic/build/Makefile says "EXTRAVERSION = .4" as well. | 13:54 |
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:02 |
matti | mihu: .. any of t..? | 15:04 |
mihu | ... any of the unresolved symbol names that this module requires. | 15:04 |
matti | :) | 15:05 |
mihu | I am now checking Module.symvers... | 15:05 |
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 | :) | 15:13 |
apw | shame he is gone, that makes sense now, as EXTRAVERSION gets overridden in the debian build system | 16:06 |
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:10 |
* 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:14 | |
tjaalton | apw: get this one too, otherwise r600+ fails to boot http://marc.info/?l=dri-devel&m=126137027403059&w=2 | 16:19 |
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:20 |
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:22 |
apw | thanks for the pointer ... i'll add it to my list | 16:23 |
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:24 |
tjaalton | but there have been some bugs reported | 16:25 |
apw | tjaalton, what was the subject on those four? | 16:26 |
tjaalton | [git pull] drm fixes (fwd) | 16:26 |
tjaalton | oh, nine commits not four | 16:27 |
apw | ahh a git pull ... must get that fixed so patchworks shows git pull requests | 16:27 |
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:32 |
Sarvatt | is "drm/i915: remove render reclock support" in that by any chance? :D | 16:34 |
tjaalton | no, they were mainly for radeon | 16:35 |
rtg | tjaalton, I think nouveau is going to have to be an LBM package. the required DRM changes are reported to be extensive. | 16:37 |
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:38 |
rtg | tjaalton, apw: how about sending the commits on the k-t list as well? | 16:39 |
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:40 |
rtg | tjaalton - I was just interested in the commit IDs, maybe gitweb URLs. | 16:42 |
apw | rtg i'll find that branch and send you a copy | 16:43 |
rtg | thinks | 16:43 |
rtg | thanks* | 16:43 |
tjaalton | the branch(es) has/have probably changed since, but the emails have a list of commits | 16:48 |
=== Jeeves__ is now known as Jeeves | ||
=== Jeeves is now known as Jeeves_ | ||
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? | 20:56 |
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:08 |
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:09 |
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 | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!