[06:14] <An-iSociaL> anyone working on tegra 2 kernels?
[07:47] <pk> Hi, I need to bisect the mainline kernel on Ubuntu, what would the best way be to go about this?
[07:52] <pk> Since I experienced the bug with the Ubuntu kernel I guess I should use the same config, is this oneiric-kernel/debian.master/config/amd64/config.flavour.generic for amd64 desktop systems?
[08:42] <ppisati> morning *
[09:48] <ehw> morning, all o/  can i get someone's opinion about this last comment? https://www.virtualbox.org/ticket/9891
[09:48] <ehw> seems like they're saying our headers package is broken; wondering if that's a realistic assessment...
[09:53] <ehw> ^^ basically having the same issue on 3.0.0-14 from the kernel-ppa
[10:10] <jmux> Hi. What's the status of the Oneiric Ubuntu LTS backport kernel? The kernel PPA contains a kernel from September. Is there a release plan?
[11:01] <ehw> cking, apw can I get your opinion on that? ^^ (@9:48 UK time)
[11:04] <vanhoof> jmux: http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-backport-oneiric/ ?
[11:04] <apw> jmux, it is in -proposed awaiting release into -updates
[11:05] <apw> ehw, well the packages they have installed are mainline kernels, they are unsupported anyhow
[11:06] <ehw> apw: trying it out with 3.0.0-14 from the kernel-ppa, and having the same issue; is it a bug?
[11:07] <apw> trying what exactly ?
[11:08] <ehw> apw: when i build the vbox modules with 3.0.0-14, loading them gives the same traceback
[11:08] <ehw> apw: works fine on 3.0.0-13
[11:09] <ehw> apw: the relocation address for cleanup_module is indeed different between pci-stub.ko and the dkms-built modules, as the last comment on that bug states
[11:10] <apw> and are they the same on -13 ?
[11:11] <ehw> apw: apparently so (setting up repro environment still)
[11:11] <apw> and do you have the headers packages installed as well as the binary packages for -14
[11:11] <ehw> apw: yes, grabbed headers from the same build ppa
[11:13] <apw> ehw, it is unclear to me that i would expect the -r lines to match in those two
[11:13] <smb> If it worked before and not now I would somehow more expect that upstream changed and they need to get their things together
[11:13] <apw> ehw, it is listing the relocation table in the module which by definition does not have the knowledge of where the thing is meant to point, and indeed they are both 0
[11:18] <ehw> apw: my understanding isn't very deep; it looks suspicious, though: https://pastebin.canonical.com/56303/
[11:22] <apw> ehw, why does that look suspeicous
[11:23] <apw> do we have any idea what any of the numbers even mean ?
[11:25] <apw> great manual page "displays the relocation section"
[11:25] <apw> that so tells me what the numbers mean
[11:26] <apw> ehw, is this the only -14 kernel you have had ?
[11:27] <ehw> apw: yep, just grabbed it from the ppa on tuesday
[11:27] <ehw> (sorry so slow, got into a phone call)
[11:27] <apw> and you never had another 14
[11:28] <ehw> apw: i'm running this on a VM that I created to test this condition
[11:28] <ehw> apw: so, it's pretty clean
[11:28] <ehw> shouldn't be any stale headers or anything
[11:30]  * ppisati -> errand, back in a bit...
[11:31] <vanhoof> ehw: what version of virtualbox and where from?
[11:31] <apw> ehw, so -13 was ok and -14 is not is the contention yes ?
[11:31] <ehw> vanhoof: it's -4.1 from from upstream
[11:31] <apw> ehw, and you got  that -14 from the c-k-t PPA yes ?
[11:31] <ehw> apw: i know that -13 worked; I don't have a clean environment yet for testing that, but I'm working on it
[11:32] <vanhoof> ehw: built for lucid, or oneiric
[11:32] <vanhoof> ehw: eg: http://download.virtualbox.org/virtualbox/4.1.6/virtualbox-4.1_4.1.6-74713~Ubuntu~oneiric_amd64.deb ?
[11:32] <ehw> apw: i got it from this page:  https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/2943294
[11:33] <apw> ehw, and what architecture is this
[11:33] <ehw> vanhoof: deb http://download.virtualbox.org/virtualbox/debian lucid contrib non-free
[11:33] <ehw> apw: Linux lucid-test 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 GNU/Linux
[11:35] <apw> ehw, is that a backports kernel or ?
[11:36] <apw> ehw, ie are you runing lucid or oneiric
[11:36] <ehw> apw: i'm running lucid
[11:36] <apw> but you are installing a kernel build in oneiric
[11:37] <apw> you need to use the lts backport build probabally
[11:37] <apw> as that is built using the compiler you have on your system
[11:37] <apw> that may make a different to dkms packages
[11:38] <apw> where did you get the -13 which does work
[11:38] <ehw> apw: ok, i can do that; then the issue here: i need a backports kernel with the cifs/suspend bug fixed [LP#24330] :-)
[11:38] <ehw> apw: the -13 was in -proposed, i think
[11:38] <apw> in proposed on lucid yes ?
[11:39] <apw> linux-lts-backport-oneiric | 3.0.0-13.22~lucid1 | lucid-proposed | source
[11:39] <apw> that one ?
[11:39] <ehw> apw: right, that's the one
[11:39]  * ehw was trying to find that
[11:39] <apw> as likely the compiler lucid -> oneiric is very different and may well be contributing to this issue
[11:40] <apw> it looks like the -14 hasn't been uploaded yet for oneiric probabally as the previous one has not yet cleared into -updates
[11:41] <herton> yes, I plan to submit a linux-lts-backport-oneiric for -14, but the previous one still didn't make to updates (bug 885468)
[11:41] <ubot2> Launchpad bug 885468 in kernel-sru-workflow "linux-lts-backport-oneiric: 3.0.0-13.22~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/885468
[11:41] <vanhoof> ehw: apw works for me
[11:41] <ehw> apw: any chance I can get/create a -14 test build for lucid? not sure how that works
[11:41] <apw> vanhoof, -14 works ?
[11:41] <apw> vanhoof, and works on what
[11:41]  * apw is very suspicious of compiler skew in this case
[11:41] <vanhoof> ah crap still on -13
[11:42] <ehw> apw: i like the theory
[11:44] <apw> ehw, as and when we have something to test it is vital you remeber you have to tell dkms to remove the existing build else you won't get new modules built and the test will be invalid
[11:45] <ehw> apw: noted, thanks; will purge, scrub, and bleach dkms
[11:45] <apw> which frankly isn't easy
[11:45] <apw> herton, ok if i wanted to rebase this lts backport for you whats the magic incantation to make the new tracking bug, or is that a dangerous thing to do
[11:46] <apw> herton, i don't want shankbot after me
[11:46] <ehw> apw: virsh snapshot-revert [...] :-)
[11:46] <vanhoof> alright here we go
[11:46] <vanhoof> installing -14, w/ virtualbox already installed and built via dkms
[11:47] <apw> vanhoof, gotten from where and onto what base os release
[11:47] <vanhoof> apw: the same release ehw is using ;)
[11:47] <vanhoof> apw: lowell
[11:47] <vanhoof> apw: 10.04.3 + https://launchpad.net/~canonical-kernel-team/+archive/ppa/
[11:47] <vanhoof> amd64 though
[11:47] <apw> vanhoof, so onto a lucid base and where did you get your -14, is it the oneiric version of -14 you installed
[11:47] <ehw> vanhoof: actually i'm repro'ing on straight lucid atm (leaving lowell out of the mix for now)
[11:48] <vanhoof> apw: yup, oneiric based 
[11:48] <herton> apw, there is already a tracking bug opened for it, let me see here (just was waiting to work on it because previous version isn't released yet)
[11:49] <apw> herton, i think i should stay out of it then, i was going to try test building it is all
[11:49] <herton> apw, bug 893567
[11:49] <ubot2> Launchpad bug 893567 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-14.23~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/893567
[11:50] <vanhoof> ehw: same behaviour here
[11:50] <apw> vanhoof, and i think i expect that, what you just did is not sensible
[11:51]  * apw installs teh same binaries vanhoof did but onto an oneiric base
[11:51] <apw> in general kernels from other releases should work except for dkms stuff where all bets are off
[11:52] <apw> which in large part is why we have to build special backport kernels
[11:52] <herton> apw, if wanted I can push the update to the git repo, just will not upload the backport yet
[11:52] <apw> herton, that would be perfect for me, i could then spin these guys some test kernels from it
[11:52] <apw> herton, but don't rearrange your day to make i happen
[11:52] <herton> it's ok, will do now
[11:53] <ehw> \o/
[11:53] <vanhoof> apw: just did the same on oneiric proper and it works
[11:54] <apw> vanhoof, yeah good, that sounds beelieveable
[11:55] <apw> and i've just installed the same combinations here and they have matching offsets
[11:55] <apw> and that is why i care about the compiler we build the kernel with
[12:00] <vanhoof> apw: herton: i'm building it now against lucid
[12:00] <apw> vanhoof, building ?
[12:02]  * apw notes that build teh real oneiric kernle isn't quite the same
[12:03] <herton> apw, pushed
[12:03] <vanhoof> apw: 3.0.0-14.23 in a lucid chroot
[12:03] <herton> vanhoof, if you want, you can build lts-backport-oneiric branch from lucid repo now
[12:04] <herton> it's updated to 14.23
[12:04] <apw> yeah it makes more sense to build what he has
[12:04] <apw> herton, thanks
[12:04] <vanhoof> ack, i'll kick that off
[12:25] <ehw> vanhoof: why you working, anyway? isn't it 7AM and thanksgiving? :-D
[12:26] <vanhoof> ehw: dedication :D
[12:27] <vanhoof> ehw: just screwing around w/ other stuff
[12:27] <vanhoof> not really working
[12:27] <vanhoof> ehw: just happened to be playing around w/ the lowell build for something :)
[12:28] <ehw> vanhoof: you should be participating in mass turkeycide right now
[12:28] <vanhoof> ehw: build running
[12:28] <vanhoof> ehw: bit early for that :)
[12:28] <vanhoof> but you know what its not too early for
[12:28] <vanhoof> a beer
[12:28] <vanhoof> it is thanksgiving afterall
[12:28] <ehw> it's always noon somewhere
[12:29] <vanhoof> ehw: you want i386 right?
[12:29] <ehw> vanhoof: right, i386 pae kernel
[13:04] <vanhoof> ehw: apw: herton: http://paste.ubuntu.com/748159/
[13:04] <vanhoof> ehw: i386 build is almost done
[13:04] <vanhoof> but looks good here
[13:04] <ehw> vanhoof: excellent!
[13:04] <ehw> vanhoof: can you pastebin lsmod ?
[13:06] <vanhoof> ehw: http://paste.ubuntu.com/748161/
[13:06] <ehw> vanhoof: eeexcellent; there's no [permanent] next to the module names, either \o/
[13:13] <vanhoof> ehw: http://kernel.ubuntu.com/~vanhoof/ehw/i386/
[13:19] <vanhoof> ehw: all three packages are scp'd over now
[13:19] <vanhoof> ehw: lmk if it works
[13:19] <ehw> vanhoof: great, thanks!
[13:19] <ehw> vanhoof: setting up now
[13:20] <vanhoof> ehw: k make sure to grab linux-headers-3.0.0-14_3.0.0-14.23~lucid1_all.deb
[13:20] <vanhoof> ehw: it stalled on the transfer
[13:20] <vanhoof> but they're all there and I md5'd em
[13:21]  * ehw grabs
[13:33] <ehw> vanhoof: ok, WORKSFORME
[13:34] <vanhoof> ehw: \o/
[13:34] <vanhoof> ehw: awesome
[14:14] <apw> bug #861296
[14:14] <ubot2> Launchpad bug 861296 in linux "mmap fails to allocate 2030Mb heap on ARM" [High,Confirmed] https://launchpad.net/bugs/861296
[14:17] <ppisati> omap4 i guess
[14:20] <apw> ppisati, needed on the buildds as well according the bug, so imx51
[14:20] <ppisati> apw: but he said they were running oneiric
[14:20] <ppisati> imx51 is lucid only
[14:22] <apw> ppisati, i suspect they are building in oneiric chroots, on the buildds with a lucid kernel
[14:22] <apw> i guess we'd better check
[14:23] <ppisati> apw: discussing it on #ubuntu-arm with doko
[14:35] <apw> ok
[14:43] <apw> ppisati, seems i wasn't on #u-a, did we reach a resolution
[14:49] <cking> apw, power measurements, batch #2 coming your way in email...
[14:49] <apw> cking, thanks
[14:50] <cking> apologies, I pasted text into the mail client and it broke the formatting
[14:50] <smb> cking, metoo?
[14:51] <cking> smb, sorry, of course, will do
[14:51] <smb> cking, thanks. :)
[14:53] <Kano> hi apw 
[14:53] <Kano> apw: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=93165b7774a04cf76bc46eb6c9181ab7a8b545d7
[14:53] <Kano> could you consider that as backport for 3.0?
[14:55] <ppisati> apw: for O/omap4 is a clean cherry-pick, kernel built and i'm sending them for testing to #is
[14:55] <apw> Kano, to sru a change like that we need someone asking for it in a bug, and for them to test when its applied, else it'll get reverted
[14:55] <ppisati> apw: for lucid/imx51, i'll take a look at it now
[14:56] <ppisati> apw: half our builder are babbage (imx51) running lucid
[14:56] <apw> ppisati, sounds good
[14:56] <ppisati> apw: another half is panda running natty or oneirc
[14:56] <apw> ppisati, i am assured they will be replaced by pandas around now, but i don't hold my breath
[14:56] <ppisati> yep
[14:57] <apw> ppisati, and when they are we will stop support for the fsl branch ... yay
[14:57] <Kano> apw: it is the same code as http://knc1.de/download/Linux/KNC_DVB_C_MK3X_TDA10024_Patch.zip which is needed for one dvb-c card
[14:58]  * ppisati wonders if all these Franken-builder will ever get replaced by one proper arm server (when they are available of course...)
[14:59] <apw> Kano, that may be, but the point is someone with the h/w needs to test the fix else we can't get it through the sru process
[14:59] <Kano> i know someone, thats not the problem
[15:01] <Kano> 3.2 kernel is somehow crap currently, when i boot my netbook i get something like that: http://kanotix.com/files/fix/crash/IMG_20111123_103403.jpg or http://kanotix.com/files/fix/crash/IMG_20111121_122645.jpg
[15:02] <apw> Kano, then get them to file a bug, and add the link to the fix there, and them come here and ping me with the bug #
[15:02] <Kano> did you test 3.2 with a netbook (intel atom)?
[15:03] <apw> Kano, yep i am running the ubuntu 3.2-rc2 based kernels on most of mine
[15:03] <apw> yours is some random daily from a few days back.  have you tried at least  -rc3 ?
[15:04] <Kano> did you see rc3 compile?
[15:04] <Kano> rc2 had the same problem
[15:04] <apw> i have an -rc3 based build i am about to test
[15:05] <Kano> thats a 32 bit only N270
[15:06] <Kano> more or less the same as msi wind u100 but called akoya e1210
[15:09] <apw> i think mine are N450 ish but no not see that even on my 32bit builds
[15:09] <apw> but the stuff just before -rc3 was pretty poor
[15:13] <Kano> N450 is 64 bit
[15:14] <apw> 64bit capable, but i run 32bit on it
[15:43] <apw> Kano, so i've just booted the tip of our tree which is 3.2-rc3 based and it works for me on 32 and 64 bit atoms i have available
[15:50] <Kano> apw: curious
[15:50] <Kano> maybe it has something to do with wlan
[16:27] <lifeboy> just a question about patch files: Is a patch file anything more than a diff between two files?  I have a patch file for an older version of a driver (not the code itself, but some configuration files), and by looking at the content it seems I could apply the changes manually.  Would I miss something in the process?  I could just try it, but instead of wasting a lot of time trying, I thought I'd just ask.
[16:42] <cemc> herton: it worked, thanks a lot
[16:43] <ppisati> lifeboy: you would loose the commit msg
[16:43] <ppisati> lifeboy: git am -s $PATCH
[16:43] <herton> cemc, cool
[16:43] <ppisati> lifeboy: if that doesn't work, git apply --reject $PATCH
[16:43] <ppisati> lifeboy: then for every hunk that doesn't apply, there will be a $file.rej
[16:43] <ppisati> lifeboy: apply them manually, git add all the modified files
[16:44] <ppisati> lifeboy: and in the end git am --continue
[16:45] <ppisati> lifeboy: btw, from time to time, i closely check why a patch doesn't apply and i modify it to apply cleanly
[16:45] <ppisati> lifeboy: that's another way to approach the same problem
[16:45] <ppisati> wait
[16:46] <ppisati> lifeboy: a bit old, but still relevant
[16:46] <apw> lifeboy, there is nothing to a patch but the changes represented and the changelog entry
[16:46] <ppisati> lifeboy: http://kerneltrap.org/mailarchive/git/2007/2/22/239376
[16:47] <apw> lifeboy, git patches have some other information such as git base commit which can help git apply them more easily than you can
[16:47] <lifeboy> ppisati: It's a patch from the manufacturer of the hardware, so it's not in the git source tree
[16:49] <lifeboy> If toying with the idea of rather taking their source tree, which is based on some Ubuntu 10.04 version and adding some modules to it that I need, specifically aufs and nbd
[16:49] <lifeboy> Not "If"... "I'm toying" ...
[16:50] <lifeboy> would that be in principle possible?  I would add module sources and make sure the .config file has the relevant entries to include the modules in the build
[16:51] <ppisati> AHHHHHHHHHHHHHHHHHHHHHHHH!!!! i forgot to change the changelog... :(
[16:54] <lifeboy> apw: If the patch is not an "official" patch, then the whole git issue doesn't apply, right?
[16:54] <apw> right then it won't be annotated and is as difficult to apply as a normal patch
[16:54] <apw> git apply -C1 is a good first try which makes git apply work like patch
[16:56] <lifeboy> I might not need to do this, if I can merge the aufs and nbd source into the tree, with their corresponding .config entries.  The build will then take care of the rest or not?
[17:37]  * ppisati goes out to find some boxes...
[20:18] <lifeboy> If I use the make-kpkg way of building a kernel how can I add the items in ubuntu/Kconfig in the source tree to the .config?
[21:46] <lifeboy> I asked earlier (but it doesn't seem too many are here!): / If I use the make-kpkg way of building a kernel how can I add the items in ubuntu/Kconfig in the source tree to the .config?