[07:36] <smb> Morning .+
[07:41] <diwic> smb, good morning. How is ssh towards kernel.ubuntu.com working for you this morning?
[07:41] <smb> diwic, The same it did the previous weeks. Not
[07:42] <diwic> smb, okay - then the error is not on my side. Is there currently any way to push to a git tree there?
[07:42] <smb> diwic, Not that I am aware of. 
[07:42] <diwic> smb, ok.
[07:44] <jjohansen> err doesn't it just work if you push through zinc?
[07:45] <smb> jjohansen, If master is up again
[07:45] <smb> Oh
[07:45] <smb> diwic, Sorry not enough coffee
[07:45] <smb> I read kernel.org
[07:46] <jjohansen> smb: no kernel.org isn't backup, and it will be done different when it is
[07:46] <smb> diwic, kernel.ubuntu.com works for me
[07:46] <jjohansen> me too
[07:47] <diwic> jjohansen, interesting, zinc.canonical.com works but kernel.ubuntu.com does not
[07:47] <smb> diwic, Have you changed some keys? Maybe different entries in ssh/config
[07:48] <diwic> smb, yeah, that's probably it. Thanks.
[07:48] <jjohansen> diwic: hrmm, not sure why, I don't think I actually ever use kernel.ubuntu.com for ssh, only zinc
[07:49] <smb> jjohansen, Its just another name for the same machine
[07:50] <jjohansen> smb: I am never sure what gets multiple eithernet interfaces and haven't bothered checking that they are the same
[07:51]  * diwic happily pushes an update to a tree on kernel.ubuntu.com, thanks for the assistance
[07:57] <diwic> btw, linuxfoundation.org is up now, it was down among the others last time I checked (a week ago or so?)
[07:57]  * smb thinks that one also had an incident
[07:58] <jjohansen> yep, separate incident
[07:58] <diwic> smb, I think so too, but at least they seem to be working on something
[07:58] <diwic> if something comes back up :-)
[08:40] <janimo> hello, how can I get (should I?) access to the git servers to host a new tree - the ac100 ARM kernel published in the archives in oneiric
[08:40] <janimo> which currently is only available as a source package
[10:13] <apw> janimo, cirtainly it seems reasonable that the kernel is stored somewhere if its master source is git
[10:14] <apw> (i assume thats hwat you are saying)
[10:14] <janimo> apw, so what do you suggest, how do I go about getting an account on the ubuntu kernel machine?
[10:15] <janimo> apw, what I say is I suppose there's a policy of stroring ubuntu kernel trees on the same server
[10:15] <janimo> as opposed to me keeping it on github 
[10:15] <janimo> even if the later would be much sweeter :)
[10:16] <apw> actually we don't have any particular policy, the ubuntu ones are on kernel.u.c, the linaro ones are on a linaro server i believe, github is fine as long as people know it is there
[10:16] <apw> janimo, indeed if it is there we probabally could mirror it as well if you like to have it on githum
[10:18] <janimo> apw, whatever the kernel team thinks is better really
[10:18] <janimo> even if you guys are not very likely to need to touch this particular tree
[10:19] <ogra_> well, ppisati expressed intrest on a 3.0 port 
[10:19] <janimo> I just thought it would be weird to have a kernel for an ubuntu shipped arm image reside on github
[10:19] <janimo> ogra_, well not sure if needed, it is being done upstream and we may just need to get it for free in P
[10:19] <ogra_> and given that we ship this kernel on images we build, i think at least mirroring the packaging bits to k.u.c should happen
[10:19] <ogra_> so you can find it in the place you expect to find ubuntu kernels
[10:20] <ogra_> work can for sure happen on github if you prefer, but we should make it accessible through an ubuntu channel
[10:22] <Kano> apw: why dont you add the 3 dvb fixes?
[10:22] <Kano> it is in YOUR launchpad
[10:22] <Kano> so...
[10:22]  * ogra_ wasnt aware apw is responsible for launchpad 
[10:22] <apw> why don't you trust me to proritise my time appropriatly
[10:23] <Kano> because you released one kernel without that fix
[10:23] <apw> while you think a dvb issue is important, i personally think security issues which affect the entire userbase are more important, that you don't agree is a worry for your users
[10:24] <Kano> well there are simpler ways to attack linux users than exploiting kernel issues
[10:25] <janimo> a baseball bat for instance
[10:26] <apw> and they are only $15 on amazon, we'd better ban them
[10:27] <janimo> that would just make the black market for bb bats more active
[10:27] <apw> Kano, seems i have lost the reference to the bug
[10:27] <janimo> ogra_, I would use gitorious too as upstream hosts it there, but gitorious sometimes has availability issues
[10:28] <janimo> hmm, and .git is > 500M would not fit in a github free plan
[10:29] <apw> janimo, depends, if you fork linus' tree you may be ok
[10:29] <janimo> apw, it is fork of a tree on gitorious
[10:29] <janimo> a 2.6.38 one
[10:29] <apw> ick
[10:29] <janimo> exactly
[10:29] <janimo> well, it is the best among the free services probably
[10:30] <apw> well if you want kernel.u.c access then the best place to start is by bringing it up on kernel-team@ ...
[10:31] <janimo> apw, ok thanks
[10:53] <Kano> apw: http://lists.debian.org/debian-kernel/2011/08/msg00932.html
[10:54] <Kano> somewhere should be a reference in launchpad too to that link
[10:54] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/838130
[10:54] <ubot2> Ubuntu bug 838130 in linux "Kernel 3.0 breaks DVB-T (ISDB-Tb) in DiBcom 8000" [Undecided,Confirmed]
[10:55] <Kano> tjaalton: did you try a patched kernel yet?
[10:56] <tjaalton> Kano: yes, but not sure if my device is affected after all
[10:56] <tjaalton> i need to try again to be sure
[10:57] <tjaalton> it works after the patches, but it might've been "broken" for other reasons (PEBKAC mostly)
[10:58] <Kano> most likely not
[10:58] <Kano> there are definitely cards which require the patches
[10:58] <tjaalton> i had issues with the antenna too
[10:58] <Kano> they work with 2 patches already, the 3rd does not have got that heavy impact
[10:59] <Kano> but as you say it works with all 3 too
[10:59] <Kano> there are 2 kanotix users who i know personally which need that fix
[11:00] <Kano> most likely there are even more u users...
[11:22]  * ppisati -> out for lunch
[12:22] <lamont> ppisati: dunno why, but the current natty kernel on some (apparently video enabled) pandas hates the network far more than the maverick kernel
[13:02] <ppisati> lamont: uhm, what you mean for video enabled?
[13:03] <ppisati> lamont: does it have a video connected?
[13:04] <lamont> no actual monitor / etc connected that I know
[13:06] <ppisati> lamont: so what you mean for "video enabled"?
[13:07] <lamont> not sure, 'twas a comment the arm guys made based on the panic we saw
[13:07] <lamont> Nafallo: anything diff about habitat vs the other pandas?
[13:08] <ogra_> ppisati, in a past kernel we had an issue with the kernel locking up if the system triggers suspend on console without monitor attached 
[13:08] <ogra_> i havent seen that since maverick though
[13:08] <lamont> anyway, afk for a whil
[13:08] <ppisati> ogra_: AFAIK suspend is still broken now (with or without monitor)
[13:09] <ppisati> ogra_: but i don't think it's the case for lamont
[13:09] <ogra_> ppisati, i'm talking about dpms on console
[13:10] <ppisati> ogra_: ah k
[13:22] <ppisati> ogra_: btw, i upgraded my panda this morning
[13:22] <ppisati> ogra_: and i noticed that if you don't use it for a while
[13:22] <ppisati> ogra_: $someone suspend it
[13:23] <ppisati> ogra_: http://paste.ubuntu.com/697869/
[13:23] <ogra_> ppisati, complain to #ubuntu-desktop 
[13:23] <ppisati> never happened before
[13:23] <ogra_> ppisati, known bug, gnoem-power-manager defaults to suspend after 30min 
[13:23] <ppisati> but i noticed it when i came back from lunch
[13:23] <ogra_> regardless if you are on battery or AC
[13:23] <ppisati> ah
[13:23] <ogra_> did you manage to resume actually ? 
[13:24] <ppisati> ogra_: nope
[13:25] <ppisati> ogra_: LAN as no WOL
[13:25] <ppisati> ogra_: keyboard doesn't affetc it
[13:25] <ppisati> ogra_: and even setting the rtc doesn't help
[13:25] <ogra_> yeah, and there is no resume button anywhere :)
[13:25] <ppisati> ogra_: :)
[13:26] <ogra_> btw, did you hear that we have suspend working fine on ac100 ?
[13:26] <ogra_> and sound through headphones
[13:26] <ppisati> nope
[13:26] <ppisati> cool
[13:26] <ppisati> i'm stiil waitingh for the ac42 cable
[13:26] <ppisati> i want to solder it on the motherboard to get a serial console
[13:26] <ericm|ubuntu> apw, do you know how can I completely disable the kernel-wedge thing to produce d-i udebs?
[13:30] <tgardner> ericm|ubuntu, it is the kernel-wedge thing that produces the udebs
[13:30] <ericm|ubuntu> tgardner, the problem is we don't necessarily need those udebs
[13:30] <tgardner> ericm|ubuntu, so, you'd like to bypass udeb generation altogether ?
[13:31] <apw> udebs are only made if your architecture is mentioned in machines.in
[13:31] <ericm|ubuntu> tgardner, yes if that's possible
[13:31] <apw> debian.master/d-i/kernel-versions.in
[13:31] <apw> i should say kernel-versions.in
[13:31] <ericm|ubuntu> apw, let me check
[13:32] <ericm|ubuntu> apw, what can we do to that file?
[13:32] <ericm|ubuntu> apw, to disable generating udebs?
[13:33] <tgardner> apw, I think CONFIG_MODULE_UNLOAD=n for mainline builds. Do you recall if there was a specific reason for that?
[13:33] <tgardner> ericm|ubuntu, simply comment out the armel line
[13:33] <diwic> ogra_, sound through headphones?
[13:33] <ericm|ubuntu> tgardner, ah all right - stupid me
[13:34] <diwic> ogra_, on 2.6.38?
[13:34] <ogra_> diwic, yep :D
[13:34] <diwic> ogra_, congratulations!
[13:35] <ogra_> not my work :) but thanks :)
[13:40] <Nafallo> lamont: not that I'm aware. want me to go check revisions etc?
[13:57] <apw> tgardner, are you saying we are wacking _UNLOAD to n in mainline ?
[13:58] <tgardner> apw, I think so.
[13:59] <tgardner> apw, though I'm not sure how just yet.
[13:59] <apw> hmm not intentionally now
[14:07] <apw> tgardner, so whats not working ?
[14:08] <tgardner> apw, http://stackoverflow.com/questions/7482469/why-is-this-kernel-module-marked-at-permanent-on-2-6-39
[14:11] <apw> tgardner, well he mentions they are marked permenant
[14:14] <tgardner> apw, is that a different config option?
[14:15] <tgardner> hmm, not taht I can find
[14:16] <apw> it is possible they broke  module unload in those mainline kernels
[14:16] <tgardner> are we carrying a patch for that? I sure don't remember anything
[14:16] <apw>         if (mod->init != NULL && mod->exit == NULL) {
[14:16] <apw>                 printed_something = 1;
[14:16] <apw>                 seq_printf(m, "[permanent],");
[14:16] <apw> no we have nothing to fix it for sure
[14:16] <apw> so i'd have to guess his module is compiled wrong somehow
[14:18] <apw> tgardner, have you reproduced the effect ?
[14:18] <tgardner> apw, not yet. I'll work on it.
[14:18] <tgardner> I'll get a VM going
[14:21] <bjf> ##
[14:21] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:21] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:21] <bjf> ##
[14:21] <apw> tgardner, i will point out he is using some random snapshot of the kernel so i am not going to be supprised if it is reporoducible, but not in a release tag for mainline
[14:29] <tgardner> apw, well, I can add and remove fat.o in a mainline Lucid kernel.
[14:30] <apw> he seems to be using 2.6.39-02063904-generic wich would be a specific days tip
[14:30] <tgardner> I'll try that one
[14:30] <apw> if it fails, i'd recommend finding 2.6.39 tag version and see if its gone, as for the described use case i cannot see why that would not be a more appropriate test version
[14:31] <tgardner> apw, I'm just gonna try 2.6.39.4 and if it works, then its not our problem
[14:56] <herton> ppisati: are you able to verify/test the -proposed kernel for bug 709245 on maverick? (or if you know who could test it)
[14:57] <ubot2> Launchpad bug 709245 in linux-linaro "ARM SMP scheduler performance bug" [Medium,Confirmed] https://launchpad.net/bugs/709245
[15:05]  * ogasawara back in 20
[15:06] <ogra_> herton, i'm pretty sure it will land in the next set of GrueMaster's tests
[15:08] <herton> ogra_: ack, being tested this week it's fine
[15:09] <ogra_> herton, no idea if its this week, better ask GrueMaster ... he is the arm QA person for such stuff (and should be notified in advance)
[15:11] <herton> ogra_: it's not QA, it's just the bug verification. There is only this bug waiting to be verified for linux-ti-omap4 on maverick, once someone does it it'll go to testing/QA
[15:11] <apw> herton, any idea why natty ti-omap4 is lagging so far behind the others in getting out to -updates ?
[15:11] <herton> apw: I think it went to -updates, let me check
[15:11] <apw> ahh is that just security being lax then
[15:11] <bjf> skaet, cjwatson tells me that bug #790240 should not be part of the rls-mgr-o-tracking-bugs report, do you concur ?
[15:11] <ubot2> Launchpad bug 790240 in gnome-mag "at-spi needs demotion for oneiric (at-spi2-core in main)" [Medium,Confirmed] https://launchpad.net/bugs/790240
[15:12] <bjf> skaet, it has no "open" oneiric tasks
[15:12] <skaet> bjf,  otp,  will review in about an hour.
[15:13] <bjf> skaet, np, no rush
[15:13] <herton> apw: yep, everything fine, 2.6.38-1209.15 was released (rmadison shows it on -updates, 2.6.38-1209.15, bug 837761)
[15:13] <ubot2> Launchpad bug 837761 in linux-ti-omap4 "linux-ti-omap4: 2.6.38-1209.15 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/837761
[15:24] <lamont> Nafallo: if you have a few minutes, I'd be extremely interested in the difference between say habitat and algol
[16:06] <bjf> ##
[16:06] <bjf> ## Kernel team meeting in one hour
[16:06] <bjf> ##
[16:15]  * apw wanders out to enjoy the sun ... back in 30
[16:20] <skaet> bjf,  re: 790240,  yeah given it won't be fixed in oneiric,  and nothing is planned for SRUs for it,  makes sense for it not to show up on the list.   I've gone and altered the tag to "rls-mgr-p-tracking". 
[16:54] <cking_> you heard it from apw, sunshine in the UK is possible
[16:57] <Sarvatt> 30 whole minutes of it a day yeah
[16:58] <cking> that's enough to get a small tan on the top of one's head
[17:08] <apw> one cannot expose ones soft southern skin to the sun for more than 30m anyhow, else it peels off
[17:09] <apw> cking, any good experiences with s/r on sandybridge ?
[17:12]  * tgardner hopes he doesn't toast his Emerald by installing a xen hypervisor
[17:15] <cking> apw, kinda works, we pushed it passed 250 on quite a few occasions, but generally a pass level of 30 iterations seems possible most times
[17:17] <cking> it depends on a lotta factors though, why? you seeing problems?
[17:22] <apw> cking, yeah this one s but not r
[17:24]  * ppisati -> gym
[17:24] <cking> well, that's 50% OK then ;-)
[17:24] <cking> you willing to try that S3 stap script to see if you get insight
[17:56]  * tgardner -> lunch
[18:01]  * jjohansen -> runs an errand
[18:15]  * jjohansen back
[19:58] <BarkingFish> Good evening guys.  I wonder if you could help me please.  I've been trying to use a kernel module from 2.6.38-11-generic to make my HP iPAQ RX1950 register, but the USB Ident wasn't in the module.  So I got the code, wrote a makefile, and rebuilt the module against that kernel.
[19:59] <BarkingFish> Modinfo will read the details, and clearly now shows the usb ident for my device in the alias list.  But it won't insmod into the kernel - I get the following error: FATAL: Cannot insert /home/thor/Downloads/ipaqsrc/ipaq.ko - Unknown symbol in module (-1)
[20:00] <BarkingFish> I have no idea what i've done wrong, but building the module produced no errors
[20:01] <BarkingFish> Could anyone possibly give me some advice as to what I might do about this issue please? It's vital that i get this module working
[20:33] <dhunt> anybody here have compiled linux 3.0 with "make deb-pkg" succesfully?
[20:41] <BarkingFish> Hi again. Sorry, I've sorted out the kernel module now.  Is there anyway of getting hold of the source code of the .ko that was used to build the kernel module which came with a particular kernel, please?
[20:41] <BarkingFish> I'd like to see how it compares to the one I built this end.
[20:44] <dhunt> how do you build it?
[20:45] <BarkingFish> I got the original code of ipaq.c from a git repository on the net, and wrote a basic makefile for it to turn it into a module, ran it and wound up with a .ko including the usbident for my iPAQ.
[20:46] <BarkingFish> I tested it using insmod and it went in, and it's appearing in lsmod
[20:46] <BarkingFish> i already have the ipaq.h file in my kernel headers
[20:51] <BarkingFish> dhunt, the issue with the original version of the module was that my iPAQ's USBID (03f0:1c1d) wasn't included in it, so I edited the code to add the ident in and rebuilt it.
[21:00] <dhunt> BarkingFish: can't help on that sorry, I misunderstood you before,  I'm trying myself to compile 3.0 with make deb-pkg since kernel-package does not works
[21:01] <BarkingFish> Thanks anyway.  All I need is the .c file for the code that was used to make the current ipaq.ko module in 2.6.38-11-generic-pae, so that I can compare how it looks.  Anyone else have any ideas on how to get it please?
[21:06] <dhunt> oh that, go to the kernel git and get a regression to that revision
[21:08] <BarkingFish> dhunt, brilliant!  I just need to find the git repo for the kernel now :)
[21:08] <dhunt> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
[21:08] <dhunt> BarkingFish: change the version depending of the one you use
[21:09] <BarkingFish> do I have to specify the name of the kernel exactly, like 2.6.38-11-generic-pae or will 2.6.38-11 suffice?
[21:10] <dhunt> no no, 2.6 is the branch I guess
[21:10] <dhunt> the exact revision depends
[21:10] <dhunt> anyway forget that
[21:11] <dhunt> download the source of the version you use
[21:11] <BarkingFish> so git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.38-11-generic-pae would work?
[21:11] <dhunt> is faster than git
[21:11] <dhunt> the second parameter is just the name you´re putting locally
[21:12] <dhunt> you can do git clone git:/.....linux.git BarkingFish and it works
[21:12] <BarkingFish> ah ok. Thanks a load dhunt, I appreciate it. 
[21:13] <dhunt> ur welcome ;)
[21:13] <BarkingFish> Nice! I wouldn't mind building a barkingKernel :)
[21:13] <BarkingFish> anyhow, I have to go for a bit, got some other stuff to do.
[21:13] <BarkingFish> See you later
[23:48] <hallyn> i'll try to come up with a tigher way to reproduce this, but when I create 4 lxc containers through openstack, which creates their filesystems on qemu-nbd block devices as ext4, I frequently get oopses like http://people.canonical.com/~serge/20110927_001.jpg
[23:49] <hallyn> after which clean shutdown is impossible