#ubuntu-kernel 2005-06-20
<Mithrandir> fabbione: do you have any xen packaging done or should I start from scratch on it?
<jbailey> zul: Angie just came from Ottawa, said it was brutal.
<zul> it is brutal..
<zul> 26 degrees 79% relative humitidy 79%
<zul> tomorrow its going to feel like 39
<fabbione> morning
<zul> hey fabbione 
<fabbione> hey zul
<zul> how goes it?
<fabbione> just woke up
<zul> nifty
<fabbione> zul: is there anything i need to merge from your tree?
<zul> i dont think so..
<zul> nothing that cant wait
<fabbione> nah it's an easy merge
<zul> right im off to bed..
<zul> i might be back later if i cant sleep in this freaking heat..
<fabbione> night zul
<fabbione> Mithrandir: xen packages are in experimental already
<fabbione> Mithrandir: the userland and the boot loader at least
<fabbione> Mithrandir: you will still need the kernels tho
<fabbione> lamont: ping?
<lamont> fabbione: yes?
<fabbione> hey dude
<fabbione> you almost totally disappeared from earth :)
* lamont tries to remember what he was doing saturday... sunday's I'm almost never on
<zul> its way too hot to sleep
<jbailey> fabbione: Hey, bored? =)
<fabbione> jbailey: gimme some crack :)
<jbailey> fabbione: I uploaded 0.7 of initramfs-tools, wondering if you could try it on your sparc boxes.
<fabbione> s/boxes/box
<fabbione> and no.. 2.6.12 is no go yet on sparc
<fabbione> sorry :(
<jbailey> No worries.  It does work with older kernels still.
<jbailey> Just need to specify which modules to load into the initramfs
<fabbione> hmm ok..
<fabbione> i will try that soon
<fabbione> not today probably
<jbailey> No worries. =)
<jbailey> When you do try it, let me know and I can tell you what configurations I need most tested. =)
<fabbione> jbailey: let's try to schedule it together
<fabbione> since we can share a screen session on the console
<jbailey> Serial console?
<fabbione> yup
<jbailey> Coo.
<fabbione> it doesn't have anything else this sparc :)
<jbailey> I should also get off my ass and buy a switch.
<fabbione> it's a U1
<fabbione> brb i need to wake up my wife
<fabbione> re
<fabbione> hey chmj 
<fabbione> chmj: it would be a good idea if you can complete the uscan-extmod thingy asap
<fabbione> specially the file with the data info
<Mithrandir> fabbione: I was thinking about the kernel packaging
<fabbione> Mithrandir: and didn't you get a nightmare?
<Mithrandir> fabbione: no, should I?
<fabbione> ehhe
<chmj> fabbione, its complete, just the url file need to be reformated 
<fabbione> chmj: ok can you please finish it?
<fabbione> chmj: you also told me that the url file is not completed, but only a "sample" of the external-drivers
<fabbione> Mithrandir: and what are you toughts?
<Mithrandir> fabbione: on the xen build process?  It's utterly crackful ATM.
<fabbione> Mithrandir: why?
<Mithrandir> it downloads random stuff off the intarweb
<fabbione> oh yeah, but that's easy to patch/fix
<Mithrandir> I found nightly snapshots so broken sourcepuller isn't that big of a problem
<chmj> fabbione, will do 
<fabbione> chmj: thanks
<fabbione> bah this udeb stuff is a real mess
<fabbione> too many files in too many different places
<fabbione> this doesn't work
<fabbione> this is an interesting failure
<fabbione> ppc kernel does build properly on the buildd
<fabbione> it fails on davis
<fabbione> anybody can do a manual build at home?
<fabbione> both dpkg-buildpackage -rfakeroot -uc -us -b -B
<fabbione> and fakeroot make -f debian/rules binary-arch
<fabbione> please?
<chmj> ppc ?
<chmj> I don have 
<jbailey> fabbione: Still need a ppc build?
<fabbione> jbailey: pretty much yes
<jbailey> What package to pull down?
<fabbione> linux-source-2.6.12
<fabbione> actually ...
<fabbione> yes please do so
<jbailey> Great.  Hopefully it'll be quick.
<jbailey> Is the SMP aware?
<zul> morning
<jbailey> Heya Chuck
<zul> hey jeff
<zul> how the hell do you import a directory into baz?
<chmj> import or add ? 
<zul> import
<zul> oops...never mind figured it out
<jbailey> zul: bzr add directory
<jbailey> zul: =)
<zul> meh..
<zul> fabbione: you can get my first version of linux-non-supported-modules in my baz archive under linux-non-supported-modules--pre1,1--2.6.23 and the external drivers that i used is http://zulinux.homelinux.net/arch/lnsm/
<zul> its very very beta though
<chmj> jbailey, I just commited, can you please check that nothing is broken ?
<jbailey> chmj: Committed what to where, sorry?
<zul> aiieeeeeeeeee...:)
<chmj> kernel-team 
<chmj> committed kernel-team@ubuntu.com--2005/kernel-debian--pre1,3--2.6.11.93--patch-10
<zul> uh...2.6.11.94 should it be?
<chmj> arg ! 
<chmj> i knew i missed something 
<zul> well at least you didnt break it yet :)
<chmj> what are those numbers btw -> kernel-team@ubuntu.com--2005/kernel-debian--pre(.*)--
<zul> pre-release
<zul> jbailey: im still getting thoese i486-linux-gnu-gcc: command not found
<jbailey> chmj: I don't do kernel-team stuff really.  Chuck or Fabio is a better bet.
<jbailey> That and I don't know how to work baz. =)
<zul> lovely...something is still fucked..
<jbailey> zul: For local testing, make a symlink.  It should get overwritten when the new gcc is in.
<zul> okie dokie
<jbailey> doko: This is true, yes?
<chmj> I desperately need bandwidth 
<zul> chmj: where do you live?
<jbailey> chmj: Can't work remotely on one of the Canonical boxes?
<chmj> zul, South Africa 
<doko> jbailey: yes
<chmj> jbailey, too slow 
<zul> chmj: cool i lived in east africa for a couple of years
<chmj> zul, no, not cool, not cool at all
<chmj> not if you are in IT and need bandwith 
<zul> heh..
<zul> wheee....kernel-package cant determine subarch now
<zul> jbailey: new kernel-package fixes the i486 stuff
<svenl> fabbione: do you include a patch that fixes the sleep issues on powerbook in the latest linux-images ?
<svenl> or not yet.
<fabbione> zul: no it's a gcc issue
<fabbione> svenl: mostlikely not. i am tracking upstream atm and what benh push me
<fabbione> zul: in a second
<svenl> fabbione: so, question is, did benh push you something or push something upstream for this powerbook don recover from sleep problem yet ? :)
<fabbione> zul: i will look at the package
<svenl> fabbione: but as i guess the reply is no, i rather not use that kernel just yet on my powerboook :)
<zul> fabbione:   http://incoming.debian.org/kernel-package_9.001_i386.changes
* lamont__ prepares to commit a new hppa patch to the tree
<fabbione> zul: that's weird, because there are other packages failing for that reason
<lamont__> while mumbling something about new drivers magically showing up in the config files...
<fabbione> anyway it's tomorrow work
<lamont__> r2[45] 00, hostap, etc
<lamont__> etc== squashfs, iirc
<fabbione> lamont__: i did probably add most of them automatically
<fabbione> zul: but but... did you make an entire new package for l-n-s-m ????
<zul> no i didnt..the tar.gz has the drivers that i used minus the debian directory the debian directory is in baz
<fabbione> zul: hmm ok.. i will look at it tomorrow
<zul> builds for me on 386 at least..
<fabbione> zul: ok thanks
<fabbione> lamont__: anyway i plan very soon to do the magic config allignment
<fabbione> because it's too much of a mess right now
<fabbione> zul: so you did create another package :)
<fabbione> ok.. we need to find a way to integrate that into the kernel build system
<zul> kind of yeah..
<zul> its based off linux-restricted..
<fabbione> zul: right, i understand and the idea is good
<zul> buuuuut....:)
<lamont__> fabbione: I'll commit my changes shortly- waiting for at least one of the 4 kernels to build
<lamont__> should be another 10-20 minutes
<fabbione> lamont__: sure.. i am done for today
<fabbione> 9 hours of d-i sync is a pain
<fabbione> and i am not even half way
<fabbione> cya tomorrow guys
<fabbione> :)
<mjg59> Hmm. Need to play with the dynamic-HZ stuff at some stage.
<zul> yay another interview
<jbailey> fabbione: The kernel build has died with it prompting me for:
<jbailey> Thermal Management Support (TAU) [N/y/?]  (NEW)
<fabbione> jbailey: hmmmmm
<fabbione> same as davis
<fabbione> so now the question is... why the fuck does it build on the buildd???
<jbailey> No tty, probably
<fabbione> i don't think that's the problem
<fabbione> if you just hit enter it will fail later
<jbailey> Do you want me to do so?
<fabbione> if you want to try
* jbailey shrugs
<jbailey> No skin off my teeth. =)
<fabbione> i wonder if that can be a consequence of running a 64bit kernel
<fabbione> i never saw that using a 32bit one
<fabbione> jbailey: if you could try to reboot your ppc later in 32 bit mode
<fabbione> and rebuild, that would be nice
<jbailey> Sure.
<jbailey> Ugh.  glibc testsuite managed to do something nasty to the ppc64 kernel.
<fabbione> jbailey: nasty to what level?
<Mithrandir> buggy kernels.  Gotta love 'em
<lamont__> fabbione: kernle 4 of 4 building now... I think I'm going to commit
<fabbione> lamont__: great
<jbailey> fabbione: Can't run sudo, during reboot init couldn't should down the MTA, had to hit the power button.
<fabbione> ah
<fabbione> anything in the logs?
<lamont__> _GAH_ - lossy link to the house today.  interactive performance sucks
<jbailey> fabbione: It's just coming back up.
<fabbione> jbailey: i am really not 100% sure how stable is 12rc6 on ppc64
* lamont__ hands jbailey a 50# bag of salt for his kernel
<jbailey> Well, tst-ifaddrs randomly hangs at the best of times.  I've just never seen it take out the box before.
<dilinger> lamont__: salting the holy penguin pee is the trick for keeping 'em stable?
<jbailey> dilinger: It's like beer nuts.  It makes it drink more.
<jbailey> With alcohol, code flows.
<jbailey> Nothing in syslog
<zul> jbailey: yeah /* XXX - drunk fix later */
<jbailey> /* XXX - here be pr0n */ char *firmware_blob {  ...
<zul> brb...need to reboot
<dilinger> jbailey: feh, more like /* we're not allowed to redistribute this, but we can fix it later... */ char *firmware_blob = ...
<lamont__> dilinger: nah, you just have to take them with a grain of salt sometimes...
<lamont__> oops.
* lamont__ adds themissing file
<zul> this is interesting http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d5f7b4353dae4c7ee342c61303372fd996ca161
<dilinger> hm
<dilinger> won't that keep artifacts, then?  shouldn't it check if fb console has been initialized, and memset only if that's the case?
<lamont__> * committed kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.94--patch-18
* lamont__ reads some mail, giggles... the high packet-loss is in the T1, not in the wireless.... go figure
<zul> fabbione: ping
<dilinger> zul: fyi, looks like neofb does the same thing
<dilinger> at least in 2.6.11
<fabbione> zul: pong
<zul> fabbione: some of the external drivers have a ./Configure or ./configure and sometimes just a make how do you suppose we deal with them?
<fabbione> zul: we will see it tomorrow really .. i am tired :)
<zul> ok i was just doing some work on it though
<jbailey> Wow
<jbailey> Uncompressed initramfs = 7megs right now
<jbailey> gzip'd: 3.2 megs
<jbailey> lzma'd: 1.57 megs
<jbailey> Oh great kernel gods, please provide. kthxbye
<Mithrandir> who cares about the size of the initramfs?
<jbailey> Mithrandir: Some ppc arch's can't cope with a  >4mb initramfs, and anyone downloading it off of a tftp server.
<Mithrandir> it's the difference between 0.2 and 0.3 seconds or so of boot time.
<Mithrandir> ah, ok.
<Mithrandir> ppc is dead, though. ;-)
<jbailey> In fact the boottime would be longer locally.  It took it a good little while to compress it.
<Mithrandir> I guess I'm spoiled with amd64.
<jbailey> "It's not dead yet!"
<jbailey> Mithrandir: This is a dual ppc64 machine. =)
<Mithrandir> I'm looking forward to playing with a dual 275 AMD64 machine.
<Mithrandir> that means four cores.
<Mithrandir> hm, we probably want Ubuntu to support that well, so I should be able to play with that on work time.
<TMM> hi all!
<TMM> I'm having a little problem, I build my own kernel with kernel-package from the sources apt-getted (which claim to have ubuntu patches) I copy the config from /boot, build the kernel with make-kpkg --initrd buildpackage (no changes) and my vesafb won't work with that kernel... shouldn't it be identical to the ones provided with ubuntu?
<TMM> I was trying to add bootsplash support, and devise some initrd magic to load and set up the correct framebuffer driver (perhaps for inculsion in breezy, haven't checked with anyone or anything, just my fancy) but I'm getting stuck at even building a functioning kernel :)
<jbailey> That reminds me that I should poke sladen about bootsplash stuff.
<TMM> I'm currently not an ubuntu dev, just aspiring to be one with this little thing :)
<jbailey> TMM: I doin't know how far the bootsplash stuff has gotten.
<TMM> but, for now I can't even figure out how to build a 'standard' ubuntu kernel from source apparently
<jbailey> TMM: But there's a group of people who are quite passionate about it that are probably worth checking in with.
<jbailey> Hmm, dunno.  I don't build kernels. =)  
<TMM> in my experience, even the friendly bootup procedure of ubuntu (not too verbose) scares people 
<TMM> and I've got ubuntu (previously debian sid) running on quite a few luser desktops :)
<TMM> somehow people consider it to look old fashoned
<TMM> so, noone that can shed some light on my situation then? :)
<TMM> am I missing some initrd stuff from ubuntu itself? I can't check because for some reason, my harddisk freezes as soon as I try to loopmount an initrd
<TMM> yeah, weird, I know
<jbailey> Is this on the stock kernel or a custom one?
<jbailey> I don't think you should need to make a custom kernel at all for bootsplash stuff.
<TMM> I'm pretty sure the bootsplash stuff isn't included in the stock ubuntu kernels
<TMM> and, even then, why can't I build a working kernel image from the ubuntu sources? :)
<jbailey> IIRC, the planned bootsplash stuff is entirely in userspace.
<TMM> hmm
<TMM> well, then this won't be much help
<TMM> even then... I'm stuck with this problem :)
* TMM just doesn't get it
<jbailey> kernels are possibly not the best place to start hacking. =)
<jbailey> Are you willing to consider doing other hacking?
<TMM> ofcourse
<jbailey> Have you heard of the MOTUs?
<TMM> but, this problem kind of has me a bit baffled
<TMM> no, what is a MOTU? sounds like a swearword
<jbailey> They're the folks who help keep the "universe" section in good shape.  
<jbailey> "Masters Of The Universe"
<TMM> ah
<TMM> is there bootsplash stuff in there?
<jbailey> There's alot of tasks to do there, and the heads of the MOTU are really cool people who can help you find something fun that's the right amount of challenge.
<jbailey> sladen is the one who's generally doing the bootsplash stuff, and yes, he's in there.
<jbailey> #ubuntu-motu is the name of the channel.
<TMM> ok!
<dilinger> jbailey: sorry for taking so long to respond, i totally forgot about the email
<dilinger> jbailey: anyways, check your inbox
<jbailey> dilinger: It's okay.  I havne't been the speediest either. =)
* dilinger heads home
#ubuntu-kernel 2005-06-21
<Micksa> suspend-to-ram is working like a charm
<Micksa> and all it right with the world once more
<zul> jbailey: dont start hacking on the kernel? sheesh thats what i did :)
<jbailey> I didn't say don't start there.  I said it's possible not the best place to start.
<zul> hehe..
<jbailey> And really, to start by doing kernel hacking requires a whole lot of drive.
<jbailey> Someone with it will do it regardless of what I say.
<jbailey> (Esp as I don't mean to be discouraging.  It is a daunting place to start on its own without my help)
<zul> oh i know...
<zul> its a rough place to start if you are just starting out
* lamont kicks ipsec, hard.
<lamont> now to figure out if I really care about the bug
<lamont> new oo.o2 and gcc-3.3 sigh
<lamont> and gcc-3.4
<lamont> that explains why it's taking forever. :=(
<dilinger> jbailey: ping
* lamont could swear there was a way to have iptables look at the unencapsulated ipsec packet
<fabbione> morning
<chmj> fabbione, ping 
<fabbione> pong
<chmj> fabbione, is it possible to merge the last patch in kernel-debian--pre1,3--2.6.1 1.93 to the new playground ?
<fabbione> chmj: i think so yes.. but that change needs to be reverted in that branch
<chmj> ok, I don't know my way around baz that much
<fabbione> chmj: ok i will try to clean up
<jbailey> dilinger: pong =)
<fabbione> hey jbailey 
<jbailey> g'm Fabio
<zul> morning
<fabbione> hi zul
<zul> how is the external-modules going?
<fabbione> i didn't work on it yet
<zul> ah
<fabbione> doing other stuff atm
<fabbione> looking at the new kernel-package and kernel-wedge
<chmj> zul, where are the external-modules packages ? 
<chmj> if there are any packages 
<fabbione> there are no packages
<jbailey> fabbione: *poke*
<fabbione> jbailey: ?
<jbailey> I think in ppc32 mode this thing has gotten farther.
<jbailey> It's got a bunch of XMLTO lines on the screen now.
<fabbione> jbailey: why am i not surprised? :)
<fabbione> yeah that's it
<fabbione> i think
<fabbione> let it finish
<jbailey> Will do.
<fabbione> i will deal with it soon.. i think i know what it is
<jbailey> I think I'm going to have a nap.  I woke up crazy early this morning because of the cats.
<fabbione> i noticed :)
<fabbione> thanks a lot
<jbailey> =)
<fabbione> speaking of which.. a nap is a really good idea
<fabbione> zul: i did upload the new kernel-package
<chmj> u have cats ?
<fabbione> so you can build again
<fabbione> chmj: no... i have a wife :P
<chmj> who has cats I assume ? 
<fabbione> chmj: i am not following you :)
<fabbione> anwyay.. later
<chmj> later 
<jbailey> fabbione: Build finished fine.
<dilinger> jbailey: i was just curious what you thought regarding cdbs2 testing framework stuff
<jbailey> dilinger: When I read it, it made my brain hurt, so I went to bed. =)
<jbailey> I'll take a look again today.
<dilinger> jbailey: writing it made my brain hurt a little.  i should probably try and make it a bit more coherent or something ;)
<jbailey> I wrote the original testsuite, and it's basically the one from cdbs1 ported up.
<jbailey> I agree that it would be nice to make it a bit more generic.
<lamont__> fabbione: ping
<jbailey> I do occasionally run the testsuite by hand while I'm hacking, largely with debugs turned on so that I can see what's happenning.
<dilinger> jbailey: yea, basically the abi checking stuff fits right in w/ this..
<jbailey> Right.
<jbailey> I need to learn a bit more about how that's happening.
<jbailey> But if we could unify it with stuff that we're developping collectively, then that would be lovely.
<zul> fabbione: ping
<lamont__> "BTW, nobody should be using transport mode over the Internet anyway."
* lamont__ wonders why not...
<jbailey> context?
<dilinger> ipsec?
* dilinger makes wild guesses
<lamont__> ipsec
<fabbione> pong
<lamont__> vs tunnel mode
<fabbione> lamont__: dunno why.. but you can use tunnel mode between 2 hosts exactly as you use transport
<fabbione> lamont__: i am pretty sure that what he sais is ok, given he is one of the Ipsex developer :)
<fabbione> zul: pong?
<lamont__> fabbione: ok
<zul> fabbione: i made some changes my arch you can sync if you want
<fabbione> zul: ok thanks
<lamont__> fabbione: what I'd really like is a comprehensive tutorial on the subject. :-)
<fabbione> lamont__: i remember i read all the RFC's 5 years ago... and i met who wrote them. you really don't want to go there.. do you? ;)
<jbailey> lamont__: Step 1: Install checkpoint Step 2: Slit wrists.
<lamont__> fabbione: all the stuff from 6 months ago is completely incorrect
<fabbione> lamont__: probably the linux implementation sucks....
<fabbione> i did use fbsd+racoon against an ericsson ipsec implementation at that time
<fabbione> and it was working
<dilinger> heh
<dilinger> ipsex?
<fabbione> but i didn't even attempt firewalling
<fabbione> dilinger: yeah.. isn't ipsec sexy??
<lamont__> fabbione: that's the thing - none of the ipsec howto's address firewalling
<fabbione> i even wwrote ipsex several times in my test reports for ericsson...
<fabbione> nobody bothered to correct them :)
<dilinger> hehe, nice
<lamont__> Jun 14 09:39:57 localhost racoon: NOTIFY: the packet is retransmitted by 10.17.72.128[500] . 
* lamont__ grumbles
<fabbione> lamont__: right, because ipsec and firewalling are 2 separate issues...
<fabbione> lamont__: one to protect data/connection , one to protect the host
<lamont__> right.
<lamont__> many of the ipsec tutorials tell you that to make ipsec work, you need iptables -A INPUT -p esp ACCEPT
<lamont__> which isn't necessarily so
<lamont__> what is /dev/vcsN ?
<zul> virtual console screen
<lamont__> ah, ok
<fabbione> hey thombot
<fabbione> ok
<thom> yo
<lamont__> fabbione: note that you're making it harder and harder to build 2.6.12 on hoary. </grumble>
<thom> fabbione: dude, ipw2100 is at 1.1.0 which is apparently the version we have
<zul> for breezy?
<fabbione> lamont__: you are not even supposed to build 2.6.12 on hoary :)
<fabbione> thom: is it???
<lamont__> fabbione: yeah, and?
<fabbione> ipw2100            | 1.1.0                      | ok     | 12/04/2005   | http://ipw2100.sourceforge.net/
<fabbione> oh yeah indeed
<fabbione> lamont__: i know.. but there are a bunch of assholes sitting on #ubuntu-toolchain that keeps breking things... and i have to put pieces back together again
<fabbione> ;)
<lamont__> gcc-3.4 (>= 3.4.4-0ubuntu6) [powerpc i386]  | gcc-3.4 (= 3.4.3-9ub
<lamont__> untu4) [i386] , gcc-3.4 [!powerpc !i386] 
* lamont__ sighs - that just looks, well, wrong
<fabbione> i didn't do it :)
<lamont__> that's my addition in between the | and the ,
<lamont__> and makes hoary happy again
<zul> i hate sql
<lamont__> zul: I've never met anyone who claimed otherwise. 
<zul> good so im not alone
<thom> bleah. EIP is at ieee8011_wx_get_scan
<lamont__> fabbione: the ones doing the breaking are all here, too. :-)
<lamont__> cache hit                             65
<lamont__> cache miss                         17642
<lamont__> grumble
<thom> fabbione: right, this ipw2100 problem is a regression from 2.6.10
<jbailey> Should the kernel be part of ubuntu-minimal?
<fabbione> thom: it's an upstream problem. ipw2100 is using an old version of ieee$randomnumbers
<fabbione> i remember very well that from when i did the merge
<fabbione> so we need to wait upstream to sync
<fabbione> both ipw2100 and 2200 have this ieee code duplication
<fabbione> and they often go out of sync
<fabbione> lamont__: that was the point of my comment :P
<thom> fabbione: grah, k
<lamont__> 6000 more misses, 20 more hits.  woot!
<zul> fabbione: new inotify
<jbailey> dilinger: Around?
<dilinger> yep
<jbailey> dilinger: cdbs2 thoughts for you.  Once we're done this testsuite and some basic docs.  What all do you think there is left before we can include it for some basic usage?  I know that the debhelper and autotools need a bunch of variables populated and help things written for them.  Is there other just basic functionality that's missing before people can at least start peeking at it for basic apps?
<dilinger> yea, the main thing that's missing/broken is per-module pass stuff
<dilinger> right now, if you have CDBS_MODULES := autotools, foo_CDBS_MODULES := autotools debhelper, debhelper gets run for both
<dilinger> i think that's a bug i introduced, with the way i'm keeping track of stuff
<dilinger> that's the main thing that's remaining
<jbailey> Nice. =)
<jbailey> I haven't dug through everything yet that you've done.
<dilinger> after that, we just start porting modules
<jbailey> My initial targets for modules are just autotools, python, ant, gnome and kde.
<jbailey> Those are ones that I feel confident writing testscripts for.
<dilinger> the framework is there, debian/rules help will spit out all variables, hooks, etc; i'm not too concerned about the test suite stuff, but if we decide to make it built in (w/ the way i'd prefer, test-specific hooks), it wouldn't be too hard to add in there
<jbailey> I'm hoping to be more hardcore about features needing testcases for this so that we don't have the kind of fuckage debian had from robert in the last few months of cdbs.
<dilinger> jbailey: that would be nice
<dilinger> i'd certainly appreciate it if you pushed for the test stuff
<dilinger> because i can pretty much guarantee how it'll go if i do it (first, i'll say i just want to get stuff working, so i won't concentrate on the test suite.  after stuff is working, i'll say things need enhancements before i can get to the test stuff.  finally, i'll say it's time for the test suite, and i'll get distracted and work on some other project that's bugging me)
* dilinger is very much motivated by itches
#ubuntu-kernel 2005-06-22
<fabbione> morning
<Mithrandir> hiya
<fabbione> hey Mithrandir 
<Micksa> oh my
<Micksa> a google search for "fuckwankers" finds, among other things, this
<Micksa> http://www.photonhunter.co.uk/cgi-bin/vmjg59.pl
<zul> morning...stupid internet
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> zul: i did merge the new inotify ans -dbg stuff
<fabbione> zul: close to stop.. headacke is killing me today
<zul> cool...i had to drive the wifey to work..
<zul> uh...bug 11857...hehe
<Micksa> I guess that thing is old news :)
<fabbione> ahahhaa
<fabbione> no
<zul> ill close it
<fabbione> i am doing it
<fabbione> done already
<zul> awwww...:)
<zul> meh...i hate to wear a tie 2 days this week!! aiiie
<fabbione> amen
<fabbione> i am off for a while
<fabbione> my head is exploding
<zul> i pay to see that
<fabbione> zul: die!
<fabbione> ;)
<zul> hehge
<fabbione> later
<zul> toodles
<zul> http://www.fotosearch.com/ART411/aa039991/ <-- fabio's head
<Micksa> oh my mjg's blogs are fun to read
<Micksa> His 04-01-2004 entry simply goes "2:51 am 
<Micksa> oops
<Micksa> His 04-01-2004 entry simply goes "Hrgnk. Kngk. Gk."
<Micksa> (It's a link)
<zul> so wish me luck
<fabbione> zul: good luck
<lamont__> zul: luck, for whatever the endeavro is
<zul> interview
<zul> yes im leaving now
<mdz> fabbione: ping?
#ubuntu-kernel 2005-06-23
* #ubuntu-kernel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
<jbailey> fabbione: Is there an easy way to generate the modules.alias file based on a subset of modules that I copy to the initramfs?
<zul> one down one more to go
<jbailey> Nice!
<zul> and it looks like im going to get a call back as well
<jbailey> Nice!
* jbailey attempts to actually get sleep tonight now that the weather's finally broken.
<jbailey> We're down to 18 here.
<zul> how is the smog? :)
<zul> same here
<jbailey> Three days of reasonbly heavy rain at some point during the day have worked some magic.
<jbailey> But I could really wish that people would just stop driving their cars.
<jbailey> Oh well, sleep time.
<zul> then people in toronto would die
<fabbione> morning
<fabbione> mdz: i did ask elmo to remove 2.6.11 even before hoary release...
<fabbione> mdz: and asked after another few times 
<fabbione> jbailey: i think you can do that using depmod with proper parameters...
<fabbione> jbailey: iirc it accepts a module dir to look into
<fabbione> hm interesting... busybox-cvs is FTBFS on sparc with a really nice error
<fabbione>  /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a: could not read symbols: Bad value
<fabbione> this looks like either libc or gcc are doomed
<fabbione> hey amy
<fabbione> amu
<amu> hey
<zul> c ya later
<zul> got another at 9
<fabbione> zul: good luck dude
<jbailey> fabbione: No, that's the error that is fixed with the newest glibc upload.
<fabbione> jbailey: sorry.. what error?
<jbailey> <fabbione> hm interesting... busybox-cvs is FTBFS on sparc with a really nice error
<jbailey> <fabbione>  /usr/lib/gcc/sparc-linux/4.0.1/../../../../lib/libc.a: could not read symbols: Bad value
<fabbione> ah ok :)
<jbailey> But no, I'm mistaken
<jbailey> That's not the same error I was thinking of.
<jbailey> Could be solved with the same fix, though, who knows.
<fabbione> ehe ok
<fabbione> i will see once glibc are done
<jbailey> I should check on that.
<fabbione> we will see in the test chroot
<fabbione> with the new libc
<jbailey> Ayup
<zul> i so much hate wearing ties
<jbailey> Ahaha
<jbailey> Will you need it in the new job?
<fabbione> zul: how did it go?
<zul> just about to leave...yesterdays was pretty good they wanted a "portfolio" and definite second interview
<fabbione> nice
<jbailey> "portfolio"?
* fabbione sighs
<jbailey> Are you applying to go painting?
<fabbione> nic-* udebs are driving me stupid
<fabbione> hey lamont
<zul> oh headache..
<fabbione> zul: eh....
<zul> it went ok...they asked for references
<fabbione> good
<thom> zul: what are you applying for?
<zul> desktop support/network admin
<zul> part time--junior, need a job
<thom> ah
<fabbione> thom: do you mind to do an ipw2100 test for me please?
<thom> sure
<fabbione> thom: remove the following modules from the stock kernel:
<fabbione> ipw2100
<zul> i need a break..bbiab
<fabbione> (sec.. i can't find the full list :()
<thom> heh, no worries
<thom> i'll need to reboot to .12 anyway
<fabbione> -rw-r--r-- root/root     28937 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ieee80211/ieee80211.ko
<fabbione> -rw-r--r-- root/root      7872 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ieee80211/ieee80211_crypt.ko
<fabbione> -rw-r--r-- root/root      8561 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ieee80211/ieee80211_crypt_ccmp.ko
<fabbione> -rw-r--r-- root/root     11558 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ieee80211/ieee80211_crypt_tkip.ko
<fabbione> -rw-r--r-- root/root      6536 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ieee80211/ieee80211_crypt_wep.ko
<fabbione> drwxr-xr-x root/root         0 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ipw2100/
<fabbione> -rw-r--r-- root/root      8522 2005-06-08 16:43:25 ./lib/modules/2.6.12-1-386/kernel/drivers/net/wireless/ipw2100/fsam7400.ko
<fabbione> there
<fabbione> remove this modules for real
<fabbione> and try to compile ipw2100 from upstream source
<fabbione> that will install the olds ieee stuff
<thom> ok
<fabbione> and the same ipw2100 driver
<fabbione> if you can test that and tell me if it works or not
<fabbione> i might be able to compile ipw2100 in a different way to make it working again
<doko> fabbione: no amd64 2.6.12 kernels in the archive?
<fabbione> doko: are you nuts?
<fabbione> they are in universe
<fabbione> like all the others :)
<doko> ok, don't expect dselect be up to date after an apt-get update ...
<fabbione> doko: dselect update != apt-get update
<zul> fabbione: when you and i arent busy do you want to talk about the linux-non-supporte-modules thingy?
<fabbione> zul: you can bet on it.. we are just in a slightly different TZ
<mdz> fabbione: it is starting to cause problems that 2.6.12 is not in main
<mdz> fabbione: ndiswrapper-utils is uninstallable, and klibc is unbuildable
<lamont__> fabbione: maybe it's time to upload -1.2, eh?
<mdz> anastacia has been wanting to pull it into main for a while now, and I've been ignoring it
<lamont__> find: warning: you have specified the -mindepth option after a non-option argument -type, but options are not positional (-mindepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.
* lamont__ wonders wth that actually means
<lamont__> fabbione: I'd like us to upload -1.2 sometime soon, not just because 94-1.1 is ftbfs on hppa
<fabbione> mdz: it's ok with me to move it main. I am almost done with cleaning the udeb mess.
<fabbione> mdz: and if you want you can move it now
<fabbione> lamont__: i would really love to complete the cleaning before 1.2. i miss only a few sets of udebs
<fabbione> (nic-* pcmcia-* scsi-*)
<lamont__> woot
<fabbione> lamont__: did you see the changelog?
<fabbione> didn't you?
<lamont__> fabbione: I was meaning sometime this week, not sometime this day...
<fabbione> i should be able to upload tomorrow
<fabbione> i need to check with pitti how much time i have to prepare another security update for hoary
<fabbione> mdz: or can we wait tomorrow after 1.2 is in?
<fabbione> mdz: otherwise mostlikely i will have to bump the abi at the first upload
<fabbione> mdz: that's kind of annoying for one day
<mdz> fabbione: tomorrow is fine, just notify me when you are ready
<fabbione> mdz: as soon as i upload 1.2
<fabbione> mdz: there is really a bit cleanup to make it ready for main :)
<mdz> fabbione: if jbailey needs to make a klibc upload, you must answer to him though :-)
* jbailey scrolls back.
<fabbione> mdz: ok :)
<fabbione> there are only 128 lines of almost detailed changelog :)
<fabbione> and i started to be less anal retentive than before
<mdz> jbailey: klibc (main) build-deps on a 2.6.12 package (universe)
<fabbione> jbailey: btw.. klibc is FTBFS on sparc dude :)
<jbailey> Eh, when did klibc get promoted to main? =)
<fabbione> jbailey: if you want .12 in main.. we need to get that fixed :P
<jbailey> <insert obligatory comments about logs and visibility here>
* jbailey ssh's
<fabbione> jbailey: i am setting up something for that...
<fabbione> that you will access ala people.
<jbailey> Yay!
<jbailey> Then I will start asking you guys to have them all in one place. =)
<jbailey> But first things first.. =)
<fabbione> let me ask elmo if he had any extra tought about it
<lamont__> fabbione: if you want to drive getting a process that elmo is happy with, I'd love to see it - any implementation changes I need to make to do the merge, etc.
<jbailey> err.. can't find umul.  Unsigned multiply instruction?
<fabbione> lamont__: yup...
<lamont__> fabbione: thans
<fabbione> lamont__: did you read on #ubuntu-toolchain ?
<zul> damn im popular
<mdz> jbailey: how goes the modalias stuff?
<zul> fabbione: i had a couple of ideas i was playing with this week but whenever you are free
<fabbione> zul: i will be free in 5 minutes
<fabbione> wife is in bed (finally)
<fabbione> zul: so.. what's up?
<zul> so i was thinking setup similar to d-i
<zul> i was looking through the drivers and some of them have ./Configure ./configure make and whatnot
<zul> so we would have a flat text file with a flag saying 0 for make 1 for whatever and 2 for whatever
<zul> or something like that
<zul> thoughts?
<zul> or we could script it in kernel-wedge
<zul> thats another option as well..
<zul> we juat have to make as easy as possible to maintian
<fabbione> you already lost me :)
<fabbione> let me finish one thing i started while you were away ;)
<zul> heh i have a tendency to do that
<zul> bleah..:)
<zul> i just want it easy to maintain thats pretty much it right now
<zul> gotta pick up wife bbl
<zul> sorry
<fabbione> zul: don't worry.. 
<zul> ok im back
<fabbione> ok
<fabbione> so explain what you are talking about...
<fabbione> step 1)
<zul> 1) figure out what drivers are we going to support
<fabbione> #1 we already agreed on that
<zul> 2) make sure that the modules build individually
<fabbione> #2 what do you mean individually?
<zul> make sure that there is no surprises when we are compiling them
<fabbione> ok they need to build... that's clear :)
<zul> yep
<zul> 3) add linux-non-supported-modues-* to debian/control debian/control.stub
<fabbione> yes
<zul> 4) add drivers-build, drivers-install to debian/rules
<zul> 5) profit $$$
<fabbione> #4 ?????
<fabbione> what i don't understand is:
<fabbione> 1) why do you want to build them outside the kernel
<zul> 4) those are just arbirtary names
<fabbione> 2) adding an extra lever of complexity
<fabbione> what we need to do is way more simple than that
<zul> 1) how would you do that?
<fabbione> we already compile the drivers
<fabbione> they are already there
<fabbione> given your #1 create the list
<fabbione> match against this list and move the drivers from build-$flavour into debian/linux-non-supported-$ver-$abi-$foo-$bar-$mysyster-$yourdad
<fabbione> and create the debs...
<fabbione> (defined in debian/control and .stub)
<fabbione> it sounds to me you created a much bigger issue that what needs to be done
<fabbione> what lands in there is simple to control and doesn't need extra complexity
<zul> i was kind of thinking that so something like d-i right?
<fabbione> just one step before install
<fabbione> d-i is something else..
<zul> ok
<zul> ill get d-i out of my head then
<fabbione> more levels we add, more complex it becomes to maintain
<fabbione> creating udebs is another story and needs other stuff
<zul> so something like the abi check?
<fabbione> that's already done at kernel build time
<fabbione> think in this way:
<fabbione> or better
<fabbione> look at debian/rules
<fabbione> more or less in sequence happens:
<fabbione> unpack
<fabbione> patch
<fabbione> configure
<fabbione> build
<fabbione> (****)
<fabbione> install
<fabbione> create debs
<fabbione> create udebs
<fabbione> now
<fabbione> build also includes the abi check
<fabbione> what we need to do is somehow:
<fabbione> add that (****)
<fabbione> that will move the non-supported-modules according to the list
<fabbione> from debian/build/build-$flavour/<path_to_the_module>
<fabbione> to debian/l-n-s-m-foo-etc/<path_to_the_module>
<fabbione> that's all the hook needs to do
<zul> ah i think i see
<fabbione> it's pointless to duplicate build mess
<fabbione> and stuff like that, when it's already there
<zul> so you would copy the source to debian/l-n-s-m/
<zul> do what ever you need to do
<fabbione> no.. no source
<fabbione> i will mv directly hte builded binaries
<zul> where would you build the binaries from?
<fabbione> directly in the kernel, like we are doing now
<zul> ah...so we still maintain the patches?
<fabbione> yes
<zul> ok gotcha
<fabbione> but given that they are modules in l-n-s-m
<fabbione> we take the freedom to remove them if they don't build
<zul> now i understand :)
<fabbione> or upstream dies
<fabbione> or the patch doesn't apply anymore
<fabbione> they are 3rd class drivers
<fabbione> 1st class in vanilla kernel
<fabbione> 2nd class - external we must have
<zul> so you would have a list of modules per arch and a list of modules where the are suppose to go
<fabbione> 3rd class - nice to have if it builds
<fabbione> we need one list of modules per arch. you already know where they will go
<zul> heh i guess i should have gone to udu :)
<zul> cool...ill get started on the list tonight
<fabbione> eheheh cool :)
<fabbione> and i am off to sleep
<fabbione> i am tired
<zul> nighty night
<zul> im off to learn about iscsi as well
#ubuntu-kernel 2005-06-24
<fabbione> morning
<fabbione> Mithrandir: apt-cache search pistachio
* netjoined: irc.freenode.net -> orwell.freenode.net
<Mithrandir> fabbione: no hits, yes
<fabbione> Mithrandir: it's in debian.. but a very old version
* netjoined: irc.freenode.net -> orwell.freenode.net
<fabbione> i just uploaded 1.2
<fabbione> please wait to commit around that i need to do the baz dance
<fabbione> and get some food before that :)
<zul> hola
<fabbione> hey zul
<zul> hey fabbione how goes it
<fabbione> the main baz repo seems to be fucked
<zul> huh?
<fabbione> we are investigating the problem
<fabbione> there are some strange merge issues
<zul> i didnt do it :)
<fabbione> and i can't tag 1.2 upload
<fabbione> i know :)
<fabbione> it's a baz bug apparently
<zul> bah...lets use cvs ;)
<fabbione> i can take your word for it :)
<zul> lol
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,3--2.6.11.94 | if baz merge doesn't work.. your code is ok.. use baz merge --star-merge .. deprecated algo that actually does the right thing
<fabbione> zul: i am almost done with the tagging :)
<zul> ok im trying to track down something
<fabbione> 1.3 is open :)
<fabbione> have fun
<fabbione> i am off for a bit
<jbailey> Hmm.  depmod will have to be done at boot time to deal with module assembly. =(
<jbailey> I know the kernel can cause modules to be loaded automatically.  Does it shell out to insmod or something, or does it rely on a hotplug event to get that right?
<jbailey> I'm thinking things like sd_mod
<zul> i think it relies on hotplug
<zul> but im not 100% sure
<jbailey> Cool.  Thanks, Chuck.
<zul> np
<fabbione> jbailey: depmod can run at initramfs creation time, but it's always a good idea to run it at boot
<fabbione> and if can.. please stop using insmod and switch to modprobe
<jbailey> This is simply for the modules that exist in the initramfs for hardware autodetection.
<jbailey> The problem is that at build time I can't assume that I have all the modules that will eventually be present in there, so to get the modules.aliases file right, I need to run it on the bits in the initramfs
<jbailey> Already stopped using insmod in my local tree.
<fabbione> jbailey: ah ok.. i see
<jbailey> Booyah!  She boots!
<jbailey> The only modules I have to hardcode now are md, raid1, and sd_mod
<fabbione> Total 2075 package(s)
<fabbione> ^ sparc needs-build
<fabbione> 24 hours ago they were 2200
<jbailey> Hmm, I could drop md from that list, nice.
<jbailey> Is there any way to tell which things in kernel/drivers/net are actually for hardware devices and which ones are just things for ppp/slip etc?
<fabbione> not automatically
<jbailey> 'k, thanks.
<fabbione> ppp is hardware.. it gives you a device back
<fabbione> even if it's "virtual"
<jbailey> Yeah, I was hoping for a device tag or something.
<jbailey> No biggy, they're pretty small, and I can always do a blacklist later.
<jbailey> Or hey, perhaps we can support NFSRoot over PPP
<jbailey> *puke*
<fabbione> ahahhaa
<jbailey> Lesse..  Reasonable root filesystems:  ext2, ext3, jfs, nfs, reiserfs, xfs.
<jbailey> Would anyone try over afs, hfs or ufs?
<zul> reiserfs4..hah!
<jbailey> I don't see that in the Ubuntu kernel...
<fabbione> ahaha
<dilinger> jbailey: i'd like to get our root filesystems using afs, but i'm not sure if that's possible
<dilinger> given afs has a global namespace that always has to be /afs/<cell>
<dilinger> it would require some ugliness involving symlinking, for example, /usr into /afs/<cell>/root/usr or somethihng
<dilinger> or bind mounting
<dilinger> or something
<jbailey> dilinger: Mind if I ignore that case for now?  We can always add the drivers in later.
* dilinger nods
<jbailey> That sounds in the same class as root over NFSv4 =)
<dilinger> does nfs4 employ some weird namespace?
<jbailey> It uses strong auth like Kerberos as well. =)
<dilinger> interesting
<jbailey> dilinger: Eh, you might know the question chuck answered earlier.
<jbailey> You mentioned before that SCSI can autoload things like sd_mod when it loads the appropriate driver.
<lamont>   CC [M]   drivers/net/fealnx.o
<lamont> drivers/net/fealnx.c:907:2: warning: #warning Processor architecture undefined!
<jbailey> Does it shell out to insmod, or rely on a hotplug event?
<lamont> fabbione: I think we can disable that driver for hpp
<lamont> a
<fabbione> lamont: go ahead :)
<lamont> heh
<fabbione> baz commit -s'Fix FTBFS on sparc64'
* fabbione sighs
* lamont wonders if the ubuntulog bot could watch and announce baz commits to the kernel-team repository
<fabbione> lamont: nope.. it knows nothing about baz
<fabbione> we can make another bot for it
<jbailey> Wire it up to the commits bot?
<fabbione> hmmm actually.. given that sparc32 is not supported.. i could make sparc64 the default and kill sparc
<lamont> kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.94
<jbailey> It would probably be easy to write a module for CIA, and nice for baz projects to have it anyway.
<lamont> that's the right version, yes?
<fabbione> jbailey: no. i don't like to mix too much
<fabbione> lamont: nope..
<fabbione> that's been released today
<fabbione> 1,3
<lamont> you uploaded -1.2, ok
<lamont> -1.2 went to main?
<jbailey> fabbione: Why not?  There are enough people who look at the #commits channel, and it keeps stats and such.  Might just be interesting PR for Ubuntu.
<lamont> s/went to/is headed for/
<dilinger> jbailey: i don't think it calls out to insmod, i think it calls the internal stuff that does module loading
<fabbione> jbailey: because i don't want another extra service to run on my own server.
<dilinger> jbailey: map the driver into memory, call the init function, etc.  that's just a guess, though; i haven't looked at the module loading code
<fabbione> jbailey: if somebody wants to set it up.. more than welcome :)
<jbailey> dilinger: 'kay thanks.  I'll look and see what I can find.
* jbailey adds jbd to the initramfs so that ext3 can load.
<fabbione> brb
<jbailey> Ugh.  Now the network drivers are detected in the initramfs, which is correct, but hotplug on the boot system isn't triggered by the module loading, so the network doesn't get started. =(
<lamont> jbailey: don't make us hurt you....
<jbailey> What if I beg?
<zul> hey...the live cds dont have a System.map do they?
<zul> huh...where is the kernel-image for powerpc 2.6.12
<fabbione> they should....
<zul> not on the iso
<fabbione> strange...
<zul> chuck@homer:/media/cdrom$ find . -name "System.map" -print
<zul> chuck@homer:/media/cdrom$
<fabbione> we should ask Kamion if they get removed to save space
<zul> i was trying to track down that amd64 problem to see what is causing it to crash
<Micksa> alright, hibernate works
<Micksa> that was easy
<Micksa> heh, even my ssh sessions stayed running 8)
<jbailey> mdz: Around?
<mdz> jbailey: yep
<jbailey> mdz: I have all the hardware autodetection working right, but it has the side effect of not letting hotplug generate a colplug event (since the module is already loaded).  The end result is that ifup is never called.
<jbailey> mdz: I think the fix is in hotplug.  I can upload what I have for now if you'd like to test it, though (or post .deb's or whatnot)
<jbailey> mdz: s/is in/needs to go in/
<mdz> jbailey: go ahead and upload
<mdz> we don't rely on a plug event to call ifup by default anyway, right?
<mdz> we just do ifup -a at boot
<jbailey> Hmm, it didn't on my box.
<jbailey> I can look for that, though.
<mdz> that's certainly how it works here
<jbailey> mdz: If you're testing it locally you still might have to add ide-general or sd_mod, but all the actual hardware drivers are autodetected.  The kernel is supposed to autoload those, but I'm guessing that I don't have something quite right.
<mdz> jbailey: the kernel should load sd_mod when needed, but ide-generic has never worked that way (unfortunately)
<mdz> jbailey: wasn't it you who implemented the workaround in the hotplug package for that?
<jbailey> I did, I haven't ported that to it yet.
<jbailey> dilinger said that a recent rc version included the patch to ide to make it use the driver model.
<jbailey> So it might do the autoloading on its own.
<jbailey> In any event, my test system for this is sata, and sd_mod isn't being autoloaded, so I'm trying to see what I need to make that happen as well.
<jbailey> The rest of the hacks are nice known things, so I can just toss them in easily enough.
* jbailey gets confused.
<jbailey> I didn't have auto eth0 in my interfaces file... =(
<jbailey> mdz: btw, thanks for the fix to initramfs.
<mdz> jbailey: no problem
<mdz> jbailey: is busybox-cvs-initramfs waiting in queue/new or something?
<jbailey> Filename: pool/universe/b/busybox-cvs/busybox-cvs-initramfs_20040623-1ubuntu18_powerpc.deb
<mdz> ah, no, it's in universe
<jbailey> I thought dependancies were automatically taken care of?
<mdz> where "taken care of" means "show up in the anastacia output the next day", yes
<jbailey> Ah. =)
<mdz> jbailey: which MODULES choice should I used to get the network drivers included?
<jbailey> It does it unconditionally at the moment.  Did it miss yours?
<mdz> s/used/use/
<mdz> no, I didn't look
<mdz> I had MODULES=list, so I assumed it wouldn't add them
<jbailey> That will be a valid assumption soon. =)
<mdz> jbailey: does it get af_packet as well (for dhcp)?
<jbailey> It appears not.
<jbailey> (I'm in my initramfs atm)
<mdz> my ethernet driver didn't get loaded
<jbailey> Which driver?
<mdz> oh, silly me; I installed busybox-cvs-initramfs and then forgot to go back and upgrade initramfs-tools
<jbailey> =)
<mdz> that's more like it; taking much longer to build the initramfs now :-)
<jbailey> If you want to take a look inside it, I have a script locally that I use that basically does mkdir /tmp/initramfs; (cd /tmp/initramfs && zcat /boot/initramfs <cpio -i)
<jbailey> I current save my initramfs as /boot/initramfs for testing.
<mdz> jbailey: I get some error messages from invalid modprobe invocations, but it does work
<jbailey> Yup, I haven't done noise reduction at all on this.
<jbailey> Did you have to add af_packet?
<mdz> I didn't take it out of mkinitramfs/modules
<jbailey> 'k
<mdz> I added it in the first place when ipconfig failed to work without it
<mdz> so I assume it's still needed
<jbailey> Yup, and it's definetly not getting pulled in atm.
<mdz> it's probably a safe assumption that all nfs-root setups should have it
<mdz> jbailey: hmm, taking nfs out of modules fails too
<mdz> I end up with an initramfs which has the nfs module in it, but not its dependencies
<mdz> also, the kernel-package hook doesn't seem to work
<mdz> root@mizar:/usr/bin/X11 # dpkg-reconfigure linux-image-2.6.12-1-386
<mdz> Cannot find /lib/modules//lib/modules/2.6.12-1-386
<mdz> Failed to create initrd image.
<mdz> looks like mkinitramfs syntax differs slightly from mkinitrd
<jbailey> Hmm.  I'm copying whole directory trees at this point into the initramfs.  I thought I had most of what we needed for nfs.  I'll add more in.
<mdz> jbailey: why does it work via /etc/mkinitramfs/modules, but not via the nfs magic?
<mdz> do you resolve deps in one case and not the other
<mdz> ?
<jbailey> Right.
<jbailey> In modules, I'm actually resolving dependancies.  In the other case, I'm using cp -a to get thigns from /lib/modules into the initramfs
<jbailey> I can add specific things to resolve dependancies on, but I don't want to wind up with a list of drivers that we copy in - that just means we have to maintain it.
<mdz> yep
<mdz> jbailey: is the kernel-package thing simple to fix?  it'd simplify my life
<jbailey> I'm rebooting into the working system to test it now.
<jbailey> I'll also add the dependancy check for nfs and af_packet
<mdz> cool
<jbailey> And force those to modprobe in the nfs case.
<jbailey> At that point will the modules file be empty on your nfs system?
<mdz> af_packet and nfs should both autoload fine, no?
<jbailey> There's nothing in there to autoload them right now.  If you list them in modules, they get modprobed.
<jbailey> But in nfs mode, they should be modprobed too
<mdz> oh, kmod doesn't work?
<jbailey> Doesn't seem to, I haven't tracked that down.
<jbailey> but sd_mod isn't being autoloaded either.
<jbailey> I was asking dilinger about that earlier.
<jbailey> mdz: Looks like 0.11 will make :33, it has your fixes.
<mdz> jbailey: cool, thanks
<jbailey> mdz: One of the things in the nfsroot spec currently is: Add ability to specify module loading from the kernel command line and additional module details (IRQ, IO Address, Port) to support older network cards.
<jbailey> mdz the ltsp folks didn't think it was so necessary, since it's pretty rare to see non-pci devices (and our hardware detection won't find it atm anyway)
<jbailey> I will hack it so that if module information is specified it will get used, but do you otherwise see any problem with dropping that?
<jbailey> Either that, or I can also take a parameter for additional modules to load from the command line.
#ubuntu-kernel 2005-06-25
<mdz> jbailey: perhaps I can just merge LTSP's code to accomplish this into another hook script in ltsp-client
<mdz> jbailey: 0.11 looks great, thanks
<fabbione> morning
<fabbione> mdz: can you be so kind to allow a few hours between X uploads?
<fabbione> mdz: i understand that you need it, but it makes * FTBFS on other arches ;)
<fabbione> .12 is out
<mdz> fabbione: FTBFS how/why?
<fabbione> mdz: sorry i meant that without the latest X other pkgs are FTBFS
<fabbione> because some pkgs becomes uninstallable
<mdz> fabbione: oh, arch: all deps on arch: any?
<fabbione> mdz: that too.. it's also versioned Depends
<fabbione> so until the latest X is built,part of gnome and kde becomes uninstallable
<fabbione> and binaries for older versions are automatically REJECTED by katie (correctly)
<fabbione> even if they did build fine
<fabbione> mdz: btw it would be an extremely good idea to ask infinity/elmo/lamont to start building main over main on a regular base
<fabbione> at least on one test arch
<fabbione> specially becuase of the X split
<fabbione> universe would be a plus
* fabbione goes out in the sunshine
<fabbione> later
<zul> morning
<lamont> fabbione: that's breezy-autotest, and it's pending archive existance
<jbailey> Heya Chuck, LaMont.
<lamont> morning jbailey 
<jbailey> Is breezy-autotest some sort of continuous autobuilder?
* lamont needs to get a shower in and drive 10 miles.  all in the next 5 minutes..
<lamont> hrm... wife's gonna be mad. :-(
<lamont> breezy-autotest is the 'rebuild the world and throw away the bits' archive
<jbailey> Go go go!!
<lamont> build using only breezy bits, bitch about anything that is now ftbfs
<jbailey> If your wife gets mad at you, she might stop letting you come play.
<lamont> killing comes more to mind....
<jbailey> Cool.  Once it's done, will it jsut automatically start over again?
* lamont flees.  back on in a few hours
<jbailey> 'bye!
<lamont> dunno if elmo will cron the archive flush, or if he'll manually do it.
<lamont> but yeah, over and over.
<lamont> breezy-test will be a bit more benign, since we'll just use it to abuse one change at a time, or some such.
* jbailey pokes lamont with a stick.  Go now, that's what backlogs are for. =)
<lamont> right.  gone.
<lamont>  /bin/sh: hppa64-linux-objdump: command not found
<lamont> fix binutils (or linux-source-2.6.12). kthxbye
<jbailey> What does the mapping from i.86->i386 usually?
<jbailey> That's the big that needs to be tweaked for hppa64.
<jbailey> s/big/bit/
<lamont> jbailey: note that there is a binutils-hppa64 as well - and I think that's what's failing, dunno thought
<lamont> s/t$//
* lamont is out the door
<jbailey> Ah, cool.
#ubuntu-kernel 2005-06-26
<mjg59> fabbione: ipw2100 is still fucked
<mjg59> II
* netjoined: irc.freenode.net -> orwell.freenode.net
<fabbione> morning
<fabbione> mjg59: blame upstream.. not me :)
<Micksa> how does automatic CPU scaling tend to behave when playing video?
<Micksa> like, if you have a video that plays right if you have it at top CPU but then it uses ~65%, does the scaling behave nicely?
<Micksa> I have the inspiron's media buttons working. awesome.
<Micksa> er, oops :)
<Micksa> this channel doesn't care about that
<mjg59> fabbione: Yeah, I know. I'll try to figure out what it's actually doing wrong
#ubuntu-kernel 2006-06-19
<zul> hey
<zul> hmmm...all of theese french isp this week i wonder why
<Keybuk> heh
<AnAnt> does the new kernel for dapper "version 2.6.15-25.43" support MMC v4 ?
<BenC> if the -23 version didn't, then -25 wont either
<AnAnt> k, thx
<zul> hey Keybuk, good session
<zul> hey BenC how is paris?
<BenC> dunno, I've been in the hotel all them
<zul> heh...
<zul> oh i started the xen stuff on the weekend i have it almsot building
#ubuntu-kernel 2006-06-20
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-2.2 uploaded, l-r-m and linux-meta to follow soon today
<BenC> wow, xchat just blew away the rest of the topic :/
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-2.2 uploaded, l-r-m and linux-meta to follow soon today | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: hey, can you tell me exactly what in the nsc/irda changes in -25 broken suspend/resume?
<BenC> is it something I need to fix, or did acpi have a workaround that didn't work anymore?
<mjg59> Previously, nsc-ircc oopsed on modprobe so we couldn't rmmod it
<mjg59> Now, if you rmmod it, the pnp_bus_suspend stuff blows up
<mjg59> Looks like it doesn't unregister itself correctly
<BenC> ok, I'll take a look at that
<BenC> great, 2.6.17 released code bombs on ppc build :/
<BenC> easy to fix, but stupid
<ajmitch> how annoying
<BenC> oh wait...that's an issue with the swsusp patch
<zul> heylo
<zul> hey BenC 
<BenC> hey
<zul> how is it going?
<BenC> it's going
<zul> good
<ajmitch> hey zul, BenC 
<zul> hey ajmitch 
* ajmitch wishes git pull didn't complain about debian/control not being up-to-date after a build :)
<BenC> mjg59: ping
<BenC> hey aj
<mjg59> BenC: Hi
<BenC> mjg59: do you have any comments on suspend2?
<mjg59> Crack
<BenC> bad crack or good crack?
<mjg59> Evil crack
<BenC> I can't help but notice the number of ppl who claim that it works for them when current kernel suspend doesn't :)
<mjg59> There's no functional difference
<mjg59> There's also no way they could patch the Ubuntu kernel with it
<mjg59> The driver suspend/resume calls are identical
<BenC> == dapper kernel, right?
<mjg59> Yeah
<BenC> one thing I wondered about was the compression
<mjg59> If it works and our suspend to disk doesn't, it's almost certainly configuration differences
<mjg59> We can get compression with uswsusp
<BenC> seems like an aweful useful feature
<mjg59> And also integrate that with usplash
<BenC> so I should just ignore the crack?
<Mithrandir> mjg59: how far out is uswsusp?  (Time-wise)
<mjg59> Yeah
<mjg59> uswsusp is integrated, isn't it?
<mjg59> I thought it made 2.6.17
<Mithrandir> that'd be neat.
<BenC> mjg59: Ok, thanks
<Mithrandir> I should make sure to make the live cd not only being able to suspend to disk, but suspend to network too, then
<Mithrandir> but, I'll nap for a bit.  Headache.
<mjg59> http://suspend.sourceforge.net/
<BenC> mjg59: When will our userspace make use of that?
<zul> cd /usr/local/tomcat/
<zul> oops...sorry
<mjg59> BenC: Once someone has a small amount of time? :)
<zul> BenC: when is the next dapper upload going to happen?
<zul> and the second question do you want me to take care of it :)
<fabbione> BenC: ping?
<fabbione> BenC: can you please pull from my dapper branch?
<fabbione>   Changes by Fabio M. Di Nitto
<fabbione>   * Add sata_mv to sata-modules udeb if available.
<fabbione> and if you can cherry pick the same change into edgy it would be wonderful
<zul> yay...i have been confirmed for the xen conference
<BenC> fabbione: ok
<BenC> fabbione: Got your change and pulling to edgy to
<dem> any plans to itegrate the the ahci ACPI suspend/resume patches
<zul> hey
<dem> key
#ubuntu-kernel 2006-06-21
<cvp> Alright, so I switched to the 686 kernel recently because of P4 hyperthreading junk. It runs absolutely dandy except for half a second before Ubuntu is finished loading. Somewhere in the initialization (before the welcome screen), the text becomes gibberish and funky characters replace the diagnostic messages. I use an ATI graphics card. Can anyone help me?
<BenC> are you using fglrx or the stock ati Xorg driver?
<cvp> stock ati xorg
<cvp> wait...
<cvp> or am i...
<cvp> one sec
<cvp> yeah, stock ati
<BenC> sudo apt-get install linux-686
<BenC> and then change to fglrx and see if that helps
<cvp> Will do. Thanks!
<fabbione> Keybuk: i am getting real tons of: "open: No such device or address" booting sparc. do you have any idea what could cause them? or what should i be looking for?
<Keybuk> yes
<fabbione> Keybuk: .17 and latestes edgy
<Keybuk> I know exactly what causes them
<Keybuk> I just don't care much ;)
<Keybuk> it's just an error
<Keybuk> ie. it needs an if (errno != ENODEV) before the perror() call
<fabbione> ok.. 
<fabbione> thanks
<fabbione> BenC: sparc64 UP .17-2 looks good.
<fabbione> Keybuk: even with / on xfs on lvm on raid1 :)
<Keybuk> huh?
<fabbione> sparc64 edgy
<Keybuk> the error is just a cryptic way of saying "usplash is not running"
<Keybuk> usplash_write shouldn't say that :p
<Keybuk> the fix is waiting on the buildd someway
<Keybuk> somewhere
<fabbione> Keybuk: nah.. sorry i mean to say that the latest udev works on sparc with that setup
<Keybuk> oh, right
<Keybuk> yeah, latest udev is largely ok
<Keybuk> just multiple ide controllers is broke with it
* fabbione is supposed to be on crack
<fabbione> Keybuk: ok.. i can test that... if i feel lucky ;)
<fabbione> Keybuk: but not before next week when you are back home and ready to hack
<Keybuk> no point testing :)  I know it won't work
<BenC> fabbione: cool
<fabbione> BenC: didn't test Niagara yet but i might sometimes tomorrow
<fabbione> i want to finish to prepare GFS2 userland first
<Keybuk> fabbione: what's sparc-utils?
<fabbione> Keybuk: <fucker>a collection of specific sparc utils</fucker>
<fabbione> ;)
<Keybuk> universe?
<fabbione> Keybuk: main
<Keybuk> seeded?
<fabbione> it has stuff like prtconf
<fabbione> that's the equivalent of dmidecode
<fabbione> it should be seeded
<fabbione> it was in dapper
<Keybuk> it wasn't, because it's in NEW :p
<Keybuk> (though that may be the udeb)
<fabbione> udeb?
<fabbione> ok it's the udeb in NEW
<Keybuk> there's a udeb now
<fabbione> that package is as old as debian
<fabbione> i didn't know...
<Keybuk> ---------|----|----------------------|----------------------|---------------
<Keybuk>    46871 | -B | sparc-utils (sparc)  | 1.9-2.4              | 41 hours
<Keybuk>          | * sparc-utils/1.9-2.4/sparc Component: main Section: misc Priority: IMPORTANT
<Keybuk>          | * sparc-utils-udeb/1.9-2.4/sparc Component: universe Section: debian-installer Priority: EXTRA
<Keybuk> ---------|----|----------------------|----------------------|---------------
<fabbione> Keybuk: for the udeb we will need to talk to Kamion
<fabbione> i dunno if they are actually using it in the new d-i
<fabbione> also because the new d-i hasn't been merged yet
<fabbione> but i guess we will figure it soon enough
<Keybuk> indeeed
<zul> hey
#ubuntu-kernel 2006-06-22
<zul> yo
<dem> hello
<jbailey> benc: http://git.infradead.org/?p=hdrinstall2-2.6.git;a=commitdiff_plain;h=master;hp=linus
<BenC> jbailey: excellent, thanks
<BenC> jbailey: It's in
<BenC> I'll wait to do the actual linux-kernel-headers packages, till you can test some things
<jbailey> BenC: Nice!  Are you working on abi -2 now?  I noticed that your nightlies seem to be -2.
<jbailey> Yup.
<jbailey> I'll do an upload of the tarball extract first.
<BenC> last nightly should have been -3
<BenC> if not, it will be soon
<jbailey> Then migrate the stuff to your package.
<jbailey> I haven't looked since last week, before 2.6.17 was in edgy.
<BenC> going to do another daily now to test build this after merging xen and your patch
<BenC> infinity and I are planning a "linux-image/lrm/linux-meta upload" BoF sometime this week
<jbailey> Ah, nice.
<jbailey> I'm just trying to guess how the version numbering should go, so I don't stop on yours by accident.
<jbailey> 2.6.17-ABI-Ubunturev?
<jbailey> Or do use 2.6.17-ABI.Rev?
<BenC> for the dailys?
<zul> BenC: my xen patch is almost done for x86, its a 2 meg patch ;0
<zul> but now it kill some people
<zul> doh...s/it/to/
<ajmitch> :)
<ajmitch> who do you plan to kill off?
<BenC> zul: I already have xen in git :)
<ajmitch> BenC: you'll make him cry, you know
<BenC> jbailey: the dailys use 2.6.17-ABI-<squished git sha of head>
<jbailey> BenC: No, I mean for what version lkh will wind up having when it comes from the kernel.
<BenC> are lkh arch dependent?
<BenC> yep, asm is at least
<jbailey> No.  there's an asm symlink needed.
<jbailey> err.
<BenC> ah, ok
<jbailey> yes, dependant.
<zul> BenC: hmmm...ok
<BenC> bleh, make up your mind :)
<jbailey> It could be indep if you'd rather.
<jbailey> Sorry, I read it as 'independant' first.
<jbailey> It would just require a postinst.
<BenC> jbailey: linux-kernel-headers-2.6.17-ABI-ARCH
<jbailey> Wait.
<jbailey> no, I'm smoking.
<jbailey> The idea had been to actually only install the headers that a particular arch needs.  It's an easy variable to set:
<jbailey> make ARCH=$arch INSTALL_HDR_PATH=/tmp/foo/$arch headers_install
<jbailey> So definetly dependant.
<BenC> and I'll make a linux-meta for linux-kernel-headers so it's easier to build-dep on
<jbailey> glibc needs to dep on it.
<BenC> actually, the ABI is probably pointless
<jbailey> or libc6-dev does, anyway.
<BenC> linux-kernel-headers-2.6.17
<BenC> then you can ver build-dep if you need to
<jbailey> Mmmm..
<jbailey> The package itself shouldn't contain that.
<BenC> the arch and abi in the package name is useless
<jbailey> Otherwise it's another package colletion to pile up.
<jbailey> I think so is the version number,
<BenC> so just linux-kernel-headers?
<jbailey> Please.
<jbailey> Then nothing else needs to change for all of the build-deps that are out there.
<BenC> ok
<jbailey> But I'm wondering about the version number that will go with it.
<jbailey> I want to make sure that the upload I do now doesn't wind up being newer by accident.
<zul> hey
<zul> BenC: where did you get the xen patch from?
<BenC> xensource
<BenC> and I brute forced it into our tree
<zul> ah...and it compiles?
<BenC> doing some compile testing now
<BenC> few quirks, but I think I've worked out all the kinks
<zul> yeah it redefined a couple of things
<zul> at least when i was compiling it
<zul> but then again i suck..:)
<BenC> I'm running into the vsyscall crap now
<zul> yeah thats a fun part
<BenC> think I got it...gotta start another build to find out
<zul> did you fix that config_early_printk as well?
<BenC> didn't see that?
<zul> hold on lemme check..
<BenC> the tpm driver was a bitch too
<zul> its in the setup-xen
<zul> BenC: look for CONFIG_EARLY_PRINTK
<zul> hey jeffrey how is it going?
<zul> BenC: there should be better coordinating between us since i was doing an xen patch as well
<zul> so there isnt any duplication of work
<BenC> yay, it built
<ajmitch> good
<BenC> no xen enabled kernels yet, but the stock targets build...that's step one
<ajmitch> now to get it working :)
* ajmitch wishes there were a non-rsync way of doing git pull for us mortals
<BenC> there's the git protocol, but I've never used it, and I'm not sure if git.kernel.org runs it
<BenC> you can try git-pull git://git.kernel.org/....
<ajmitch> my ISP seems to hate rsync
<ajmitch> so when there's a 120MB pack file to pull down, it dies
<zul> BenC: i can add my config.xen tonight if you want
<BenC> I'm waiting to see what we can yank out of the default kernel
<BenC> iwj is supposed to assist with most of everything else
<BenC> like userspace tools and testing
<zul> ok
<BenC> I'm just wondering if we can have our default kernels Xen enabled
<BenC> they need to be in order to be dom0/host right?
<zul> i used debian as a template
<zul> i had like linux-image-2.6.12-3-xen with the kernel-pacakge from sid
<Mithrandir> BenC: apparently, that'll break nvidia and fglrx modules.
<Mithrandir> BenC: I would not be very amused if so happened.
<BenC> this is getting worse
<BenC> I'm half tempted to just revert this whole damn thing
<zul> heh
<BenC> why couldn't they make a nice simple patch
<BenC> why the fuck do they have this whole parse tree and patches, and both conflict
<BenC> s/parse/sparse/
<BenC> I need a break, this is pissing me off
<zul> hey Keybuk 
<Keybuk> heyhey
<ajmitch> hello Keybuk 
<zul> BenC: heh... got to that point yesterday
* BenC performs a mass revert
<zul> BenC: need my help?
<BenC> nah, just help when I get it building
<BenC> do you know how to setup a xen system?
<zul> i done it once and then got disgusted
* BenC wonders how something called xen can cause so much frustration
<zul> heh...it caused more hair for me to fall out
<Mithrandir> BenC: ian knows his way around it, AIUI.
<lifeless> BenC: you need a new kernel first
<lifeless> BenC: as xen and binary drivers do not play at all well
<BenC> what do you mean need a new kernel first?
<BenC> can a xen patched kernel, even though it doesn't have xen enabled, not work with our l-r-m package?
<BenC> if that's the case, I'm shitting on this patch right now
<BenC> gotta relocate
<BenC> xen is now official not going into dapper
<BenC> err, edgy
<Mithrandir> what about edgy?
<Mithrandir> :-P
<Mithrandir> you might want to tell Ian, then.
<Mithrandir> also, why?  Because you're fed up?
<BenC> I'll break it to him gently
<BenC> no, because it simply doesn't compile when you are not compiling a xen target
<Mithrandir> uh
<BenC> and the amount of breakage will just increase my maint. time down the road for it
<Mithrandir> that's special.
<BenC> I could fix it, but I don't want to
<Mithrandir> and fixing it is nontrivial, I guess?
<ajmitch> wonderful
<zul> i could give it a shot in my copius spare time
<BenC> yeah, it's very non-trivial, and very intrusive, and with the way I have to import xen into our tree, it's a lot of work to keep it that way while still following xen
<BenC> zul: Don't bother, it's not the getting it to work part, it's the keeping it working part that bothers me
<Mithrandir> and xen upstream's not happy to make it not break the regular kernels?
<BenC> if they decide to make a git tree, and make it compile when !CONFIG_XEN, then I'll pull it in
<zul> BenC: you wouldnt have to maintain it i could if you want
<TheMuso> BenC: Speakup upstream is looking into getting a git tree up. Will keep you posted.
<zul> im volunteering *eep*
<BenC> zul: In  a way, I still have to maintain it, but if you're willing to try, start a -xen branch in git and make it work
<zul> ok
<BenC> TheMuso: that sounds really good
<BenC> TheMuso: Can I get your to forward a patch for speakup?
<TheMuso> Yeah it does.
<TheMuso> Certainly.
<BenC> TheMuso: it's a rework for the keyboard.c file, so it's just a replacement diff
<BenC> TheMuso: email?
<TheMuso> That would be great. Thanks.
<TheMuso> There is also another slight issue that I might talk over with you at some point when you aren't so busy. Doesn't have to be in person, so IRC is fine, and doesn't have to be this week either. It is to do with speakup softsynth driver and kernel preempt, but I will explain later when we talk about it.
<BenC> ok
<BenC> TheMuso: what's your email?
<TheMuso> themuso@themuso.com
<BenC> TheMuso: Sent...it's the patch I am using, so I know it compiles...pretty certain it also works :)
<TheMuso> Ok thanks. When I get onto edgy when I return home, I will give it a whirl. Thanks again.
<zul> BenC: xen gives me something to do ;)
<BenC> zul: be happy :)
<zul> i always am
<ajmitch> heh
<zul> with conditions
<irvr_> since the last update in the ubuntu 6.06 kernel I lost sound, If I move back one kernel from 25 to 23 I get my sound back.
<makx> irvr_ try alsaconf on the new
<irvr_> i will need to restart and login with new kernel and do this, thanks. Will be back shortly.
<irvr> I restarted with the new kernel. Now to get my sound back working I need to alsaconf. Is this right.
<TheMuso> Alsaconf has been depricated for ages AFAIK.
<irvr> I guess I am not sure what you mean by this
<TheMuso> Alsaconf is no longer used for detecting and setting up soundcards.
<irvr> If I use AFAIK how can I get the sound back with this new kernel?
<TheMuso> Sorry, alsaconf is no longer used to detect and configure sound cards as far as I know.
<irvr> Thanks
<dilinger> BenC: ping?
<XMuffinFlavoredX> Hello.
<mikearthur> how would I go about making a self-compiled kernel image fill the dependency for linux-image?
<crimsun> use make-kpkg with --stem linux
<mikearthur> nice one, thanks
<XMuffinFlavoredX> Anyone there.
<XMuffinFlavoredX> If I compiled a more recent kernel, for ex, 2.6.17.1, how would I get the restirced modules?
<crimsun> whoa, snd_aoa replaces wholescale snd_powermac
#ubuntu-kernel 2006-06-23
<nigel_c> BenC: The Suspend2 tree will be at http://www.kernel.org/git/?p=linux/kernel/git/nigelc/suspend2-2.6.git
<nigel_c> What's there at the moment is just vanilla.
<Mithrandir> BenC: can you pull from http://people.ubuntu.com/~tfheen/git/ubuntu-2.6.git/ , please?
<Mithrandir> (no auto-pull, it's just the include thingy I mentioned yesterday)
<Mithrandir> BenC: also, can you check that it looks sane?  I haven't used git before so I might have fucked something up
<Mithrandir> BenC: did you see my pull request?
<BenC> Mithrandir: no, where from?
<Mithrandir> 08:42 < Mithrandir> BenC: can you pull from http://people.ubuntu.com/~tfheen/git/ubuntu-2.6.git/ , please?
<Mithrandir> 08:42 < Mithrandir> (no auto-pull, it's just the include thingy I mentioned yesterday)
<Mithrandir> 08:44 < Mithrandir> BenC: also, can you check that it looks sane?  I haven't used git before so I might have fucked something up
<BenC> Mithrandir: ok, pulled
<BenC> thanks
<Mithrandir> woo, my first kernel patch. :-)
<Mithrandir> only ten years after I started using Linux
* fabbione checks
<BenC> Mithrandir: 1st kernel patch is a 1 liner....next time for got two :)
<BenC> *next time go for two
* BenC needs sleep
<Mithrandir> yup :-)
<fabbione> Mithrandir: and you make all that noise for one change????
<fabbione> git-diff-tree -p ca96426a13f7a30c9fd768a0e56785ee2d471918
<fabbione>  ??
* fabbione sighs :P
<Mithrandir> yup
<zul> BenC: ping
<BenC> zul: pong
<zul> BenC: i just saw the xen spec do you guys still need my help?
<BenC> zul: Looks like iwj is going to provide stock 2.6.16.13 kernels + xen patches in universe
<infinity> Mithrandir: Don't let them ridicule you too much, my first kernel patch was a one-liner in a SoundBlaster driver sometime in the mid-to-late 90s.
<BenC> infinity: Get your ass out of bed!
<infinity> BenC: My ass isn't (technically) in bed.
<Mithrandir> infinity: My next patch will be a one line removal _and_ addition. :-)
<BenC> infinity: I hear you had to be picked up out of the bathroom and carried to the room last night :)
<zul> BenC: so ill bug him about it
<BenC> zul: Yeah, he's problem wanting some help
<zul> cool..
<BenC> s/problem/probably/
<infinity> BenC: There's notihng better than being the focus of others' gossip...
<zul> Mithrandir: you did a kernel patch? wow :)
<Mithrandir> zul: added a missing include.  Not very hard.
<fabbione> Mithrandir: now you need to offer to drink to everybody for that
<zul> Mithrandir: now fix my computer
<fabbione> welcome to the kernel team.. now you will become addicted
<BenC> infinity: it's not gossip, it's social conversation, and concern for ones peers
<BenC> the chuckling was just accidental
<Mithrandir> *cough*
<infinity> BenC: Thpt.
<Mithrandir> fabbione: I'm affluent, but I wouldn't be if I offered drinks to everybody here.
<BenC> Mithrandir: one of us...one of us...one of us
<fabbione> Mithrandir: i am not there.. the round will be cheaper :)
<zul> bunch of alcoholics
<BenC> Mithrandir: just don't offer infinity any drinks, he buys the expensive ones :)
<BenC> MASSIVE DESTRUCTION WEAPON
<fabbione> zul: no we are not..
<fabbione> we are really truely committed to our company
<fabbione> to produce crack for users we need alchool
<infinity> BenC: The sad part is that I think I'm still a bit drunk.
<Mithrandir> BenC: I could bring a suitcase of home-made beer to the next conf.  After brewing a round of extra-strong porters or something.
<Mithrandir> infinity: go for a swim.
<fabbione> infinity: do you still feel the alchool going trough your veins?
<BenC> if it isn't in his veins it's probably coming out one of his orifices
<fabbione> ahha
<zul> off to work...yay
<zul> BenC: for the xen stuff if i rip out the stuff in debian/rules i should be able to copy over to the xen kernel shouldnt it
<zul> yes i know i dont make sense sometimes
<BenC> no
<BenC> it's not the same code base
<BenC> well, you could do; git-branch v2.6.16.13 v2.6.16.13; git-checkout v2.6.16.13
<BenC> then you'll have the stock code
<BenC> probably better to do; git-branch v2.6.16.13 xen-kernel; git-checkout xen-kenrel
<BenC> and then you can work from there
<zul> cool...thanks
<zul> what i was going to copy over the debian directory and modify it
<zul> BenC: we dont really care for abi for the xen-kernel stuff do we?
<BenC> it's probably a good idea
<BenC> ppl may be compiling external modules themselves against it
<zul> bah...users :)
<zul> i do it for me only
<TheMuso> Ok folks. If you need to talk to me about anything to do with my submitted specs or accessibility in general? Now is the time. I will be at at the table that has been known as Kenrik's table for the net 15-20 minutes if you want to catch me before I get ready to leave.
<TheMuso> Ok folks. I'm outa here. Nice to meet you all.
<BenC> TheMuso: later, good to have met you too
<zul> hey
#ubuntu-kernel 2006-06-24
<zul> hey
<milosz> damn i keep getting a SharingViolation when I try to create XmlTextWriter
<milosz> even tho i explictly make sure to Close the text reader I was using before
<milosz> lol wrong channel
<bernard_> does anybody have any thoughts about vesafb-tng? (ie, good idea, bad idea, ugly code)
<stefg> I'm suffering from a bug in the recent kernel which (stupidly) waits for a nonexisting medium in my dvd-drive at boottime. Is there some ubergeeky clever boot-parameter to override that?  
<stefg> (2.6.15-25-k7)
<crimsun_> gah, missed Ben.
<crimsun_> flight delay/cancellation is no fun
#ubuntu-kernel 2006-06-25
* mode/#ubuntu-kernel [-s]  by ChanServ
* ..[topic/#ubuntu-kernel:irc.freenode.net] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-2.2 uploaded, l-r-m and linux-meta to follow soon today | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<zul> hey BenC how was the flight?
<BenC> not bad, except for the 4 hour delay on an already 5 hour lay-over in newark
<zul> ouch
<BenC> when you hear things like "We have a plane, but no crew...your flight will be delayed", you tend to lose confidence in your airline :)
<zul> well when i was flying out of thunder bay i was stuck there because the airline had a crew but all of our airplanes are being fixed
<BenC> hehe
<fabbione> BenC: you have seen nothing yet :)
<BenC> I've seen enough :)
<BenC> I spent more time in the airport yesterday than in a plane
<BenC> I could have driven home from newark in the time I spent _waiting_
<fabbione> eheh
<BenC> it's really nice to find out that the IRC network you just logged into was recently hijacked only because you read slashdot
<BenC> would have been nice to get a notice or something when connecting, or after being connected :/
<fabbione> BenC: yeah.. they suck
<fabbione> big times
<zul> arent we moving to oftc anyways?
<fabbione> BenC: i don't think you were even online 13 hours ago when it did happen
<fabbione> mine is probably comprimised
<fabbione> not that i care
<fabbione> i don't use that password if not for irc
<fabbione> and my creditcard
<fabbione> ;)
<zul> heh...my credit cards are maxed out ;)
<fabbione> mine is empty
<fabbione> he should have asked my wife
<fabbione> not me ;)
<fabbione> Jun 25 05:44:07 -ratbert-       [Global notice]  I am a fat asshole, who loves abuse, die 
<fabbione> Jun 25 05:44:18 -ratbert-       DCC SEND YOUAREALLJUDENLOL
<fabbione> and a huge netsplit did follow
<zul> heh...back to the match
<fabbione> what match?
<zul> england and ecuador
<zul> 0-0
<eitch0000> how can I create new linux-restricted-module package compiled against a new kernel?
<BenC> custom kernel?
<eitch0000> yep
<eitch0000> well from the git repo
<BenC> did you build it with debian/rules, or using make-kpkg?
<eitch0000> well I'm doing it the way it is described in the wiki from ubuntu.com
<BenC> by typing "debian/rules binary-debs ...?
<eitch0000> which creates a .deb
<BenC> either way will create a .deb, that's not the point though :)
<BenC> I need to know if you used the linux-source build system, or the make-kpkg program
<BenC> if you can't tell me which wiki page, or the command you typed to start the build, I can't help you any further
<eitch0000> fakeroot debian/rules binary-debs --> so I guess that's linux-source build system?
<BenC> right, ok
<BenC> did you build all the flavours, or just a certain one?
<BenC> IOW, did you build with like flavours=686 ?
<eitch0000> only 686
<eitch0000> yep
<BenC> ok, install the linux-headers package for that
<BenC> oh, wait, is this 2.6.17?
<eitch0000> yep
<BenC> out of luck then, we haven' t uploaded the working packages for that
<eitch0000> and there is no way to create such a package?
<BenC> there's quite a bit of hacking to get the previous 2.6.15 package to build against 2.6.17 headers
<eitch0000> yeah...
<eitch0000> sheet
<BenC> sure, you can use 2.6.15, if you know how hack kernel builds
<BenC> just hold off a few days
<eitch0000> hmm... I think not =))
<eitch0000> k
<BenC> we'll have l-r-m and everything uploaded
<eitch0000> cool
<BenC> fabbione: No edgy chroot for faure?
<fabbione> BenC: afaik there is an RT request for it
<BenC> fabbione: Ok, I'll add faure/sparc to the daily builds once that gets resolved
<fabbione> BenC: yeah no hurry..
<crimsun> BenC: pong, sorry about the lag. Friday was an awful time; spent 13.5 hours in the Baltimore airport chasing down flights after my original one was delayed/duty timed-out/cancelled
#ubuntu-kernel 2007-06-18
<BenC> johnnybuoy: yes, that's normal
<johnnybuoy> ah
<johnnybuoy> okay, so I need to "roll my own", I guess?
<BenC> johnnybuoy: not sure there are even headers for those kernels so you can compile your own
<johnnybuoy> that sucks.
<johnnybuoy> why is it that the xen kernel has third of the normal kernel's drivers?
<BenC> because the xen patch did not support 2.6.20 kernels, else we would have been able to compile it with the rest of the kernels instead of in it's own source package
<BenC> hopefully that wont be the case for gutsy
<johnnybuoy> one last Q
<johnnybuoy> can you please point me to a place where I can download the xen kernel patches, because I can't find them at all
<BenC> xensource.com?
<BenC> not sure where else to look, they come from all over when you diverge from the actual xen repo
<johnnybuoy> man, this is tedious
<johnnybuoy> the rpm from xensource.com only has patches for 2.6.18..
<johnnybuoy> okay, thanks, BenC 
<johnnybuoy> I guess I'm going to try openvz after all :D
<BenC> johnnybuoy: I'd suggest giving us a week or two with gutsy
<BenC> we'll probably have xen and openvz around then
<johnnybuoy> yeah, but I just installed feisty now, removed gutsy...
<johnnybuoy> I simply need one or two dev machines, not servers
<johnnybuoy> to compile and mess up ;)
<johnnybuoy> but thanks, I might check it out then...
<johnnybuoy> any backports in the plans? :P
<BenC> very very doubtful :)
<johnnybuoy> aww
<johnnybuoy> maybe some repo will emerge
* johnnybuoy hopes
<BenC> I'd be surprised, we can't even get people to submit a decent patch during our 6 month devel cycle for release
<BenC> except for zul, but he's real busy being a dad :)
<johnnybuoy> w00t: http://cedric.gabriello.fr/ubuntu/
<johnnybuoy> check it out, it looks like just what the doctor ordered :)
<BenC> someone should whack that guy in the head for hording his work :/
<BenC> we need people working on it during devel cycle so everyone can benefit easily
<johnnybuoy> yeah, it's strange he starts his own repo
<johnnybuoy> mayb he did submit something that was too ugly to be included?
<BenC> you should send him a kindly email *nudge*
<johnnybuoy> :)
<johnnybuoy> yeah, if there was his e-mail anywhere...
<johnnybuoy> but it isn't, mabe in the packages
<JanC> johnnybuoy: maybe in his GPG key  :)
<johnnybuoy> ah...
<johnnybuoy> :$
<johnnybuoy> wtf? :D
<johnnybuoy> if it's in there, he went long wats to make it impossible to send him e-mails :D
<JanC> there is a gmail address in it  :)
<johnnybuoy> whaaa? :D
<johnnybuoy> I don't want to past his gpg, but I can't even see an @ in there...
<JanC> a gpg key is encoded, but you can see his e-mail address after importing it
<johnnybuoy> ah!
<johnnybuoy> gots lots to learn yet...
<johnnybuoy> wow, there is..
<johnnybuoy> I could tell him to contribute to the gutsy effort, or maybe he could make some backports?
<johnnybuoy> well, I'll test the packages first :)
<johnnybuoy> okay, brb
<johnnybuoy> yep, it works like a charm :)
<johnnybuoy> only think that needed a little tweak was the fscking ipw3945 regulatory daemon, that he forgot out of the kernel
<johnnybuoy> luckily the one from the -16-generic ubuntu kernel works :)
<eean> like every could of minutes my USB drive will be "disconnected" and then (according to dmesg) .2 seconds later it is "reconnected"
<eean> like every *couple of minutes
<eean> so I repeatedly get the new medium detected messages
<JanC> does your USB drive have its own power?
<eean> JanC: no, its one of those keychain usb stick
<eean> sticks
<JanC> then maybe the connector doesn't fit well anymore, or maybe the USB stick is just flaky, or your USB controller is flaky  :)
<JanC> does it work on other computers?
<eean> haven't used it on others
<JanC> and do other USB devices still work properly on your computer ?
<eean> I haven't had this problem with other devices
<eean> (just mice)
<JanC> I suspect it might be your USB stick then...
<eean> but its a new one!
<eean> :)
<eean> I'll check it out though
<eean> thanks
<JanC> my brother in law bought a new USB mp3 player once, and after 3 days it started working flaky too  ;-)
<JanC> (of course he got his money back)
<RAOF> Hm.  What's the policy for filing a bug for a new nvidia driver release?  The 100.14.09 drivers are released, and include support for a bunch of previously unsupported cards.  Would a bug against linux-restricted-modules be appropriate, or would this be unnecessary noise?
<crimsun> seems like a reasonable wishlist
* RAOF fileinates
<RAOF> crimsun: Could you change bug #120943 to wishlist?
<crimsun> triaged.
<RAOF> Ta muchly.
<crimsun> np.
<shiester_miester> would a discussion involving the "sh" and "tty" programs be applicable in this channel, or should i go elsewhere?
<BenC> #ubuntu
<shiester_miester> thanks
<fabbione> hey BenC 
<BenC> fabbione: hey
<fabbione> BenC: you are up late
* BenC is about to go to sleep
<BenC> fabbione: they have fathers day in denmark?
<BenC> even if not, happy fathers day :)
<fabbione> we had it a couple of weeks ago :)
<fabbione> thanks same to you old man :)
<BenC> thanks
<BenC> had a good day with the kids
<fabbione> ehe did you do anything fancy?
<BenC> cook out and kicked the soccer ball around :)
<fabbione> ehhe
<fabbione> i finished to prepare the swimming pool for my son yesterday
<fabbione> had to do all the treatment for the water and stuff
<fabbione> hopefully the weather is going to warm up again or i will need to add a water heater
<BenC> I love pools, hate setting them up
<BenC> fabbione: have a good day, I'm off to bed
<fabbione> BenC: night man.. tty
<fabbione> +later
<kraut> moin
<zul> hola
* Starting logfile irclogs/ubuntu-kernel.log
<zul> BenC: so pkl is handling the virt stuff now right?
<BenC> zul: it's being handed off to him, yes
<zul> should I still patches to the kernel-team ml or to him directly?
<zul> since I have updated it this weekend
<BenC> zul: To: pkl, Cc: kernel-team
<zul> ok pkl@ubuntu.com right?
<BenC> yeah
<zul> coolio
<pkl_> zul: phillip@ubuntu.com, or phillip.lougher@ubuntu.com... thanks
<zul> just need to do one more thing before I do
<BenC> pkl_: zul is sending patches for binary-custom.d/xen/ in gutsy kernel
<BenC> or patch I hope
<pkl_> BenC: OK
<zul> sorry timed out
#ubuntu-kernel 2007-06-19
<kraut> moin
<BenC> crimsun: ping
<zul> BenC: the xen kernels in ubuntu-gutsy are still trying to isntall a bzImage
<BenC> build_image_xen = vmlinuz
<BenC> doesn't look like it
<zul> vmlinux 
<BenC> ok, commit a fix and I can pull it
<zul> sure
<xivulon> mjg59, I have some issues with hibernation/suspend that are relevant for the ubuntu windows-installer. I am out of my depth here and would appreciate some help.
<mjg59> xivulon: What sort of issues?
<xivulon> mjg59, wubi installs Ubuntu within a file on an ntfs partition. The ntfs partition is mounted using fuse. This in short is the setup. Hybernation freezes with a prompt like: _  
<xivulon> suspend starts and then automatically resumes after a few secs
<xivulon> or according to some users it freezes completely
<xivulon> In an implementation which does not use fuse (image file is inside ext3), suspend works but hybernation still freezes
<xivulon> I have played with the acpi-support parameters but did not get too far.
<xivulon> First question I guess is how to turn on verbose logs for the suspend/hibernation process
<xivulon> If you still have windows lying around you might also want to try directly, so far most of our clienst are first timers, and I would appreciate some feedback from devs
<mjg59> xivulon: I think the easiest thing to do is probably for me to give it a test myself
<mjg59> But right now I suspect that suspend + root on fuse isn't going to work terribly well
<xivulon> http://www.cutlersoftware.com/ubuntusetup/minefield.html
<mjg59> I'm on holiday right now, though
<mjg59> I'll be back next week
<xivulon> sounds good
<xivulon> the offer is still valid for any other good soul around here
<xivulon> Another issue we have is fs robustness.
<xivulon> Users do tend to hard boot more than the should
<xivulon> Since ext3 is inside ntfs (ntfs-3g), a hard reboot sometimes compromises the journal
<xivulon> I have played a bit with /etc/sysctl.conf hoping to minimize damage. But I am quite clueless about filesystems
<xivulon> If anyone else wants to try wubi, please do, we are close to release candidate and any feedback would be much appreciated.
<poningru_> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/121216
<poningru_> anyother info that I can file on there? that will be helpful I mean
<crimsun> BenC: pong
<BenC> crimsun: any luck on those hda chips?
<crimsun> BenC: I only got Tim's email this afternoon, and I'm still at work, but I will look tonight.
<BenC> crimsun: thanks, and sorry for bugging, but it's sort of urgent...if you could give me some tips on what to look for, I'd have a go at it myself
<crimsun> ok, give me about 5 minutes to get to a point
#ubuntu-kernel 2007-06-20
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* Starting logfile irclogs/ubuntu-kernel.log
<kraut> moin
<rbs-tito> Hi guys, is there anything that can be done about bug 120837 , with the ATI drivers in the restricted modules, or would you like it closed?
<zul> morning
<zul> BenC: ping seen this? http://www.kroah.com/log/linux/enterprise_kernel_future.html
<ivoks> hi
<ivoks> i'm looking at http://hr.archive.ubuntu.com/ubuntu/pool/main/l/linux-backports-modules-2.6.20/, there is no backports for -16?
<BenC> ivoks: there were never any backports
<BenC> ivoks: but there will be soon
<BenC> ivoks: it's an empty package to make it easier to upload new drivers without uploading a new kernel
<Nafallo> I was just about to ask :-).
<ivoks> could something like this be done for dapper? :)
<Nafallo> what drivers is it aimed for? :-)
<BenC> ivoks: we have, hopefully, bigger plans for dapper
<ivoks> i already did reboot after upgrading kernel (and forgot to update my scsi module) - had to run to the client :/
<BenC> ivoks: bad part about dapper is any new drivers wont compile against it :/
<ivoks> yes they would, 3w-9xxx and e1000 :)
<BenC> Nafallo: for feisty, we are going to upload an e1000 driver to support ich9 mac types
<BenC> ivoks: well, most wont :)
<ivoks> :)
<Nafallo> kewl! :-)
<bdmurray> BenC: I know there is a reason for bug 121295 but can't recall it at the moment
<bdmurray> it deals with vmware player modules for gutsy
<ivoks> just a reminder; gutsy kernel needs updated toshiba-acpi module
<Nafallo> also, it failed on broken memory. should it really do that? :-)
<Nafallo> ;-) even
#ubuntu-kernel 2007-06-21
<kraut> moin
<calc> BenC: do you know if the realtek ALC268 support is supposed to be in upstream kernel yet? i don't see it in there yet, just on the alsa git repo you told me about before
<BenC> calc: if you can get the patch and test it, I can include it in our kernel
<calc> ok i'll try to work on that soon
<zul> BenC: how you add new modules to lum?
<zul> I mean do you just plop in a new directory update the Makefile and add the Kconfig?
<BenC> zul: add the directory and/or source, update Makefile, and update debian/config/*
<BenC> zul: if applicable, update debian/d-i/ module lists too (for like network and storage controllers
<BenC> )
<zul> okies, i was thinking of adding the xen drivers that xensource ships and some other drivers as well
<enseven> Hi, I on a Ubuntu system with 2 AMD 64bit CPUs, each dual core, with one 2GB memory section vor each CPU, like the TYAN Thunder h2000M (S3992) board. Which type of kernel do I have to use? And is Ubuntu aware of the two shared memory design of the system?
<BenC> zul: are these guest drivers?
<zul> BenC: correct
<kylem> bloody backseat drivers.
<BenC> enseven: use the Ubuntu 64-bit (amd64, Core2Duo) release
<BenC> zul: Shouldn't these be built with the xen guest kernel instead?
<zul> BenC: its seperate in the xen tree 
<zul> its for the full paravarilized guests
<enseven> BenC: Thanx. Can this release handle the two distinct shared memory sections, that are shared between the two cores on each cpu? Can one process allocate memory from only one or both CPUs? Where can threads of one process run? On the same core, on the same cpu or on either cpu?
<BenC> enseven: I think you're overcomplicating this :)
<BenC> enseven: the kernel handles shared mem between cores and memory allocation and threading on cores, and is aware of these things
<BenC> you don't have to do anything special
<enseven> benc: that's fine
<enseven> benc: what about the memory a process can allocate and where threads can run?
<BenC> what about it?
<BenC> processed don't decide where they get memory from, they request it, and the kernel allocates it
<BenC> processes even
<BenC> the kernel is smart enough to allocate from certain portions of memory based on which cpu a process is running from, for better performance
<BenC> which cpu a thread runs on is generally handled by the kernel scheduler, again, not by the process
<BenC> although you can force these things, It's not often you ever need to
<enseven> benc: Ok, so a process can get as much memory is available on both cpus, but gets first what is on the cpu it is running.
<BenC> enseven: how that all happens is complete black magic, and I wouldn't worry yourself about it too much
<enseven> benc: I just wonder if such a system is performing well for a database server ...
<enseven> benc: ... that has one process for each client and some threads ...
<enseven> ... and if the whole memory can be used with a good performance, not only half of it.
<BenC> enseven: I'd be more worried about the disk IO than the threading and memory allocation
<BenC> enseven: of course the whole memory can be used...that's why they have things like MMU's
<enseven> benc: disk IO is planed to be done by a dual 4G Fibre-Channel link to a RAID system with 16 FC-Disks. 
<BenC> only thing to do is install it and benchmark it then :)
<enseven> benc: Ok. I am very looking forward to that. :-)
<enseven> benc: thanks again.
<BenC> enseven: np
<calc> i think i found the one thing more insane to build than OOo... the default ubuntu kernel package
<zul> yep should have tried it breezy
<calc> i think its going to have taken ~ 3hr or so to build
<zul> our you building everything?
<zul> doh...s/our/are/
<calc> i was doing a test build, probably could have done something special to not have it build so much, lol
<johanbr> crimsun: Hi. A few weeks ago, I told you I'd look into the bluetooth headset pairing problems I had and I've now done so. Do you have a few minutes?
<calc> i need to verify a sound patch works with the ubuntu kernel
<calc> real    179m7.724s
<calc> user    143m47.179s
<calc> sys     13m10.349s
<calc> ouch
<calc> i can see why benc wants to drop bigiron now
<calc> and 9GB of diskspace to build
<BenC> calc: fakeroot debian/rules binary-generic
<calc> ah :)
<HawkeV> any developer types about?
<calc> going much faster now ;) esp with ccache primed
<calc> binary-generic 17m4s  not too bad
<calc> < 10% of original build time :)
<calc> BenC: the fix from alsa git isn't enough apparently
<calc> i'm going to try using a diff from realtek's alsa version and see how it does
<calc> fsck
<calc> realtek's driver no longer has 268 support
<calc> wth
<calc> ok i guess they removed their 268 since alsa added partial 268 support
<calc> apparently the alsa 268 support isn't complete i get the full mixer (i think) but no sound
<BenC> calc: have you tried something like model=3stack for snd-hda-intel module?
<BenC> calc: is this hda?
<calc> yea its hda
<calc> i'm pretty sure i tried 3stack also
* calc checks history
<calc> yep tried 3stack as well as auto
<calc> it looks to setup the mixer right or close to right
#ubuntu-kernel 2007-06-22
<calc> there may be some patches left that alsa hasn't committed to their mercurial repo yet
<calc> or maybe a quirk setting needed for the toshiba (i hope not)
<noup> hi, i'm having a small problem with the 2.6.20 kernel
<noup> the module for the keyspan media remote control isn't built with it
<noup> any info on this?
<crimsun> johanbr: I'm traveling for the next two weeks, so access is quite spotty.  What's the update?
<johanbr> crimsun: Doesn't look good, I'm afraid. Both the btsco kernel module and the headsetd from bluetooth-alsa give hard lockups with the Feisty release kernel. The gutsy kernels won't even boot. Compiling 2.6.22-rc5 from kernel.org as we speak.
<johanbr> Apparently the Broadcom bluetooth controller that my laptop uses has some quirks that needs kernel workarounds. These workarounds are supposed to be in the newest kernels, but those don't seem to boot. Something acpi-related, I think.
<johanbr> Well, gotta reboot. We'll see how this goes...
<johanbr> No luck, it seems. 2.6.22-rc5 hangs on boot, as does 2.6.21.5 and the Gutsy kernels. I filed a bug for the kernel hang at boot: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121603
<jkakar> I'm using Ubuntu Tribe 1 on a rev 3 Macbook.
<jkakar> I got wireless working great with it.  Today I upgraded (the first upgrade since the Tribe 1 install) and now my networking is flaky.  Wireless doesn't work at all and wired fails after a while (seems to be after about 512MB is transferred, or so).
<jkakar> I tried running a ping while copying a large amount of data and got this error: ping sendmsg: No buffer space available
<jkakar> Is this a kernel issue?  Where should I file a bug/what should I do to investigate this further?
<fabbione> jkakar: yes that looks like a kernel bug. use LP against linux-source-2.6.22
<fabbione> also make sure to try the old kernel
<fabbione> and see if that fixes the problem
<jkakar> fabbione: Cool.  How do you recommend I try an older kernel?
<fabbione> jkakar: well you can grab the binary from tribe1 cd or from LP directly
<fabbione> install it
<fabbione> and reboot?
<jkakar> fabbione: Ah, okay.  Awesome, thanks.
<fabbione> np
<jkakar> fabbione: Do you know where I'd find an older kernel on the Tribe 1 CD?  Or on Launchpad for that matter?
<jkakar> fabbione: I've looked at both with no luck. :(
<fabbione> jkakar: if you have the cd.. mount it somewhere and go in pool/l/linux-source-2.6.22
<fabbione> the kernel is there
<jkakar> fabbione: I looked there; all I see is a libc package.  It's the same as the version already installed.
<fabbione> jkakar: did you install from the dekstop cd or the alternate?
<jkakar> fabbione: desktop
<fabbione> ah ok
<fabbione> sorry then.,..
<fabbione> my bad
<jkakar> fabbione: Has the kernel changed since Tribe 1?  I only see that libc package with find /var/cache/apt/archives -name linux\*
<fabbione> no i don't think it did change
<jkakar> fabbione: Cool.  So, it was probably just a problem I didn't notice until after the upgrade.  I only installed Tribe 1 yesterday.
<jkakar> fabbione: If there's anything I can do to help make rev 3 Macbook support rock let me know. :)
<fabbione> jkakar: you want to follow the proper procedure.. file bugs and talk to the kernel team (BenC & co)
<jkakar> fabbione: Ah, sorry, I thought you were part of that team.  I've filed a bug and will follow up with them.  Thanks for your help.
<fabbione> jkakar: i am but i don't do intel *cough*junk*cough* ;)
<fabbione> i only do sparc bits
<jkakar> Ah, hehe. :)
<jkakar> fabbione: This piece of junk runs the Landscape test suite in 1m35s vs the 2m35s my old piece of junk took.  The junk is getting faster at least. ;)
<fabbione> jkakar: can the landscape test suite fork and run on multiple CPU's?
<jkakar> fabbione: No.  We haven't had the need for that yet.
<fabbione> tsk
<jkakar> fabbione: There's much easier lower hanging fruit in terms of test speed optimization before we go there.
<fabbione> ehehe yeah i believe you
<jkakar> I'm also not convinced it's CPU bound anyway.  I think it's IO bound on the database.  Anyway... bed time.  Thanks again fabbione.
<fabbione> night dude
<zul> BenC: ping linux-vserver has a patch for 2.6.22 which im going through now
<pitti> hi guys
<pitti> BenC: when can we expect a new kernel? there are some kernel bugs tagged as tribe-2
<pitti> and I'd like to have a plan for it, for freezing etc.
<BenC> pitti: this weekend, in time for Tue freeze
<zul> i guess we will have the xen stuff after tribe-2?
<pitti> BenC: then I'll try to hop online at some occasions for NEWing and such
<BenC> zul: looks that way
<zul> cool...ill get the vserver patch done this weekend as well
<crimsun> bah, I'd better push those patches up, then.  Will do that tomorrow after the six-hour drive of doom.
<rtg> crimsun: Where is the drive of doom to/from?
<crimsun> rtg: I'm in the metro D.C. area house-hunting, driving back to Greensboro, NC.
<rtg> crimsun: My sympathies :)
<zul> crimsun: why D.C?
<johanbr> crimsun: Hi. If you see this, the news today is slightly better. I now have my headset pairing working with the 2.6.20-15 kernel, using the old snd-bt-sco kernel module. I still haven't been able to get it work with the 2.6.22 kernels - there it seems you have to use headsetd, as the snd-bt-sco module appears to have been removed.
<_paco_> okaratas, okaratas  u are the lamest of all
<_paco_> u can't even code "hello world" in visual basic
<Mithrandir> hm, it appears e1000 does not cope entirely well with suspend.
#ubuntu-kernel 2007-06-23
<MrRTOS> what the command "make oldconfig" is for? or what does it do?
<Mithrandir> it only asks you about any new options
<johanbr> It starts the kernel build with a previous .config file, only asking you about config options that aren't already in the old .config.
<MrRTOS> cool but where are these configurations that are not part of .config? where do they come from and how does "make" know that there are more configurations that are not especified by .config?
<johanbr> The config options are part of the kernel build system. A typical use for oldconfig is when you an old .config file from a previous kernel, with fewer options.
<johanbr> "when you have..."
<MrRTOS> I'm still confused
<MrRTOS> lol
<MrRTOS> you have a new .config that make oldconfig will use
<MrRTOS> but you say that there is an old .config file too
<MrRTOS> how can there be two files with the same name?
<johanbr> There aren't two .config files. "make oldconfig" populates the old .config file with the values you select for the new options.
<MrRTOS> I'm probably having problems understanding because I do not understand the basics of the build system
<MrRTOS> if there is no .config file (if I delete it) and type make menuconfig and choose a bunch of stuff then save it and exit it
<MrRTOS> what are the results of this operation?
<johanbr> It produces a .config file with whichever values you selected.
<MrRTOS> will menuconfig create a .config file for me and when I type "make zImage" make will use the .config file created to configure everything?
<johanbr> yes
<MrRTOS> ok
<MrRTOS> so it's starting from scratch
<MrRTOS> but you say
<MrRTOS> that if I already have a .config
<MrRTOS> I could do make oldconfig and it will use the existing .config as a template?
<johanbr> yes
<MrRTOS> meaning use the answers provided by .config to create the new .config
<johanbr> yes
<MrRTOS> ok so my old .config file ends up overwritten by the make oldconfig process
<MrRTOS> cause there might be some other options
<johanbr> Not really, all the old options you selected are still there. The difference is that it will also contain the values you just selected for the new options.
<MrRTOS> ok I get it now
<MrRTOS> there is still one question un-answered though
<MrRTOS> those extra configurations that make oldconfig add
<MrRTOS> may add I should say
<MrRTOS> where do they come from?
<MrRTOS> if I have an old .config and I type "make oldconfig" it will use the old .config and add whatever new configurations I choose if there is any available
<johanbr> The new options come from somewhere in the kernel build system, I don't remember the details.
<MrRTOS> oh ok
<johanbr> Basically each kernel source tree "knows" which options go with it.
<MrRTOS> english is my second language so sorry for not explaining things clearly
<johanbr> Your English is fine. It's not my native language either. :)
<MrRTOS> :)
<MrRTOS> thx
<MrRTOS> I guess I should learn the kernel build system
<MrRTOS> any good books that could teach it to me?
<johanbr> Don't really know, haven't read any of the kernel books. A good start would be to look in the Documentation directory of the kernel source tree.
<MrRTOS> k I'll do that
<MrRTOS> I'll check at amazon too 
<MrRTOS> thanks for your help
<MrRTOS> finally I understand the make oldconfig stuff
<johanbr> No problem. :)
<JanC> does anyone know if motherboards with the new P35 Core 2 Duo chipset are supported in feisty or gutsy ?
#ubuntu-kernel 2007-06-24
<lamont> BenC: are we -rc5 yet?
<lamont> (because -6.13 is ftbfs on hppa and I just need to figure out if it's a patch that hasn't made it upstream, or if we just haven't harvested it from upstream yet.
<lamont> )
<bleinmono> Hello, does anyone know if openvz will be included in 7.10?
<shawarma> I'm debugging https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121815 and I need a bit of help figuring out the build system.
<shawarma> I followed the instructions on the wiki, so I managed to build a new kernel package and install it. Now, I want to fiddle a bit more with a certain driver, but when I edit the file and do the "AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-debs flavours=server" again, it doesn't notice my changes and rebuild the driver..
<shawarma> Do I really have to debian/rules clean ? 
<shawarma> That would mean building the entire thing all over again, so I'd rather if I could avoid that..
<Q-FUNK> is there any wiki page with a list of ACPI regressions since Feisty and known work-arounds?  i have hardwar eon which poweroff works on Edgy and Etch, but not on Feisty.
<kraut> moin
#ubuntu-kernel 2008-06-16
<nolan> I added the kernel PPA to my sources, but there doesn't seem to be any kernel available from it.  Is that PPA stale?
<strix> apologies if this is OT, but: how do I rebuild a kernel as distributed by ubuntu? (more accurately, that generates the same uname -r )?
<strix> and is there any difference between getting sources with 'aptitude install source kernel-image' and 'aptitude install kernel-source'?
<strix> otherwise, i've found the docs that describe how to build with fakeroot make-kpkg etc
<Kano> hi, anybody awake?
<Kano> when can i expect that dvb will be readded to 2.6.26?
<Kano> hi rtg 
<Kano> some problems with new kernel
<rtg> Kano: do tell.
<Kano> first of all you disabled dvb
<Kano> also you have lots of new alsa drivers  - at least one of it does interfere with my dvb cards
<Kano> you can a) disable it or b) blacklist it, but you can not leave it as is
<rtg> Kano: which kernel are we talking about? Intrepid?
<Kano> yes
<Kano> CONFIG_SND_AW2=m
<Kano> disable or
<rtg> Kano: you'll have to talk to Ben. I'm still working on Hardy
<Kano> blacklist snd-aw2
<Kano> but i saw your commit when you disabled v4l, then somebody partly enabled v4l and forgot to enable dvb
<Kano> UBUNTU: Disable V4L until the build issues get ironed out. Ignore: yes
<Kano> your commit
<Kano> and the result was that it was forgotten to reenable
<Kano> # CONFIG_DVB_CORE is not set
<rtg> Kano: perhaps, but it was awhile ago. How about a synopsis of your comments in an email to the kernel team mailing list?
<Kano> next thing is: do you really need to enable xen for default kernel
<Kano> i see currently no working patch for nvidia 173.xx which would allow the use of it
<Kano> without xen you can compile 173.x
<Kano> i modded the kernel config on the fly, i enabled highmem64gb -> pae enabled + disabled xen
<Kano> then at least nvidia works
<Kano> pae i enabled because mem is relatively cheap and lots of users have 4gb and more
<Kano> but that change is optional
<Kano> also do you drop the way with the lum package? as you added now dmraid4-5 directly?
<Kano> if you would rename the module to dmraid45 it would be even better
<rtg> Kano: did you miss the part about email to the kernel team mailing list? You are wasting your time with me. I'm _not_ working on Intrepid.
<Kano> why do you commit changes then?
<Kano> the dmraid rename could be done in lum too
<Kano> i think there was a modded version already, dont know where however
<Kano> rtg: could you give me adress where to send mail?
<rtg> kano: kernel-team@lists.ubuntu.com
<Kano> ok
<Kano> so mail sent
<Kano> hmm forgot one thing, well the rename of dmraid4-5 but maybe talk about that with the one who did the hotfix, dont remember who it waas
<BenC> Good morning everyone
<rtg> BenC: Kano has some suggestions for you on the kernel team mailing list.
<BenC> rtg: We need to talk about the 4G vs. 64G issue
<BenC> there's a good reason I disabled it (it prevents other things from working)
<rtg> BenC: not only that, but it causes performce issue, doesn't it?
<BenC> yeah
<BenC> lots of overhead for the few people that use want > 4G + 32-bit kernel
<BenC> I'm of the opinion we take a strong stance for this people to use 64-bit kernel
 * BenC needs coffee
<rtg> BenC: is there any reason for them not to use the 64 bit kernel?
<BenC> just woke up, been sick since I got back from london
<rtg> bummer.
<BenC> rtg: I'm using it, and I have found no problems
<BenC> in fact, I would say it's a little snappier than 32-bit on the same machine
<rtg> yeah, I have both 32 and 64 on the same platforms with no noticeable differences, but that entirely subjective.
<mjg59> 64-bit kernel with 32-bit userland breaks various things
<BenC> mjg59: We don't want to give them 32-bit userland :)
<mjg59> Yeah, if you can push them entirely to 64-bit then that works better
<BenC> but if they need 32-bit userland for some legacy/proprietary reason, it can work
<BenC> e.g. adobe-flash player, or some codecs
<rtg> all that stuff seems to work fine for me.
<rtg> granted, i'm not an intensive user of flash et al.
<cjwatson> was it intentional that the ide-modules udeb has been dropped in the 2.6.26 packages?
<cjwatson> also, is linux-ubuntu-modules likely to arrive soon for 2.6.26? I'd like to start building d-i against .26
<rtg> cjlum has been folded back into the kernel package.
<rtg> cjwatson: ^^
<maks_> cjwatson: from watching BenC is making a big monolithic exploding package
<rtg> maks_: perhaps, but it solves some ABI skew issues
<cjwatson> rtg: in that case, there seems to be no ubuntu-modules udeb now
<cjwatson> so that has intentionally gone away, I guess?
<cjwatson> I suppose that makes sense actually
<maks_> rtg: i had a post for you last day
<rtg> cjwatson: dunno. BenC has been working hard on it this last week or so.
<maks_> hmm no longer in backlog
<rtg> maks_: you mean the patches sent to akpm?
<maks_> irclogs/OPN/#ubuntu-kernel.2008-06-13.log:13:41 <maks_> rtg f448b9a70cda0ed9878d
<maks_> b485de30363f9c9db6e1 is a dup
<maks_> 13:41 <maks_> you'll find the same entry below in blacklist with proper desc
<maks_> 13:47 <maks_>  speaking of ubuntu hardy tree, as you might have guessed ;)
<BenC> we only had 64G enabled on i386 server anyway
<BenC> in which case, I even more strongly suggest people go 64-bit
<cjwatson> hmm. 2.6.26-1 d-i boots but without keyboard input
<BenC> 64G disables DMA_ENGINE, which server people would be pissed at
<BenC> cjwatson: hmm...USB keyboard?
<cjwatson> BenC: kvm
<rtg> maks_: I cannot figure out what you're talking about? perhaps a bit more context. my memory seems bit porous this morning.
<BenC> cjwatson: so atkbd...that should be all good
<cjwatson> atkbd doesn't seem to be modular, so shouldn't be a udeb issue
<BenC> rtg: ur not supposed to have rum in your coffee on weekdays
<rtg> BenC: I know you've you've told me that before, but I just keep forgetting.
<BenC> cjwatson: right...anyway to test 2.6.26-1 under kvm (not d-i)?
<cjwatson> err. you're the kernel specialist ;-)
<BenC> hehe
<cjwatson> I can give you the d-i .iso I have if that would help
<BenC> cjwatson: I was hoping you had an existing rig...requires setup for me
<BenC> cjwatson: yeah, that would be a good start, thanks
<cjwatson> I'm just running 'kvm -cdrom dest/netboot/mini.iso -boot d'
<BenC> cjwatson: what's the status on alpha-1?
<maks_> rtg: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=c1712ff3d8002a5070dd13c8fb6d7b77c9bd2516;hp=f448b9a70cda0ed9878db485de30363f9c9db6e1
<cjwatson> dunno if you'll be able to do much without keyboard input though ...
<BenC> cjwatson: is this holding it up?
<maks_> that adds a dup entry rtg
<maks_> just look at current drivers/bluetooth/hci_usb.c
<cjwatson> BenC: critical path = me, but I could release with 2.6.24 if need be - would rather not if possible
<rtg> maks_: now I understand.
<cjwatson> this isn't the only thing holding it up, but getting the installer out of the way is definitely on the list
<maks_> rtg: sorry for mixing hardy and intrepid
<maks_> you release to often :P
<BenC> cjwatson: we are still missing a few bits for 2.6.26 to be good on livecd...(firmware in lrm-common, etc, linux-meta)
<rtg> maks_: many folks think thats an advantage :) release frequently and often.
<BenC> maks_: yeah, my debian background really made it hard for me to get used to frequent releases too :)
<cjwatson> BenC: just to give us an idea, how far off are these?
<cjwatson> I wouldn't necessarily mind releasing with 2.6.26 just for the installer on alternate/server CDs; it can usually cope with installing a different kernel version
<cjwatson> though the effects can sometimes be a little weird so that's not entirely desirable
<cjwatson> but I figure the more early kernel testing the better
<cjwatson> BenC: http://people.ubuntu.com/~cjwatson/tmp/mini.iso
<BenC> cjwatson: I can get lrm together today
<BenC> linux-meta is ready, just needs upload
<cjwatson> BenC: it's a stock kernel and you can unpack and repack the initrd if need be; udebs are irrelevant for this particular purpose
<cjwatson> the initramfs is built with 'find . | cpio --quiet -o -H newc | gzip -9c'
<BenC> cjwatson: thanks, downloading
<rtg> maks_: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=b8e6e9b08265826ec89bf97f30bb10db78cf9663
<BenC> cjwatson: done
<maks_> rtg: thanks makes it easier to watch out for patches on your next rebase :)
<rtg> maks_: yep - thanks for the note.
<cjwatson> bizarrely, if I boot without 'quiet', it hangs, but if I boot with 'quiet', it gets as far as the first screen of d-i
<rtg> maks_: I'm always happy to dump SAUCE patches.
<cjwatson> (last thing on the screen is "Freeing unused kernel memory)
<cjwatson> "
<cjwatson> oh, and if I use BOOT_DEBUG=3 then I have keyboard input
<cjwatson> maybe it's a d-i problem after all ...
<cjwatson> keyboard input only for a while, though, then it hangs. This feels like a lockup more than lack of keyboard input, actually
<cjwatson> it's unreliable, but on one boot I got "BUG: soft lockup - CPU#0 stuck for 184s! [events/0:6]"
<BenC> cjwatson: ah, sounds more like a hang than lack of keyboard to me too
<cjwatson> anything I can pass on the kernel command line to make it spit out lots and lots of output or something?
<BenC> cjwatson: try with -nokvm(?)
<cjwatson> so just qemu basically?
<BenC> So as to exclude it being an lguest/kvm interaction
<BenC> yeah
<cjwatson> Ubuntu does not support running KVM without hardware acceleration. Sorry.
<BenC> I have the iso now, so I'll start checking it out
<cjwatson> I think I need to run qemu explicitly
<cjwatson> BenC: yes, it seems much happier with qemu
<cjwatson> I've got far enough to run into the bits I left out of the installer to make it buildable
<BenC> cjwatson: There's also noreplace-paravirt kernel param that might make it work under kvm (but without paravirt)
<cjwatson> BenC: still hangs after a short while
<cjwatson> (qemu's faster in that case anyway, I think :-) )
<BenC> cking: Can you add a BOM file for ubuntu/dm-loop/ please?
<BenC> cking: there's one in the other directories if you need a template
<cking> BenC: Will do.
<BenC> thanks
<BenC> cjwatson: they should pimp that as a feature :)
<BenC> cking: And please install the git hooks from build scripts :)
<BenC> cking: config changes should be a separate commit from the code
<BenC> just to make it easier to separate things out, and do reverts independent of each other
<cking> BenC: OK apologies for no understanding that. Will do in future.
<BenC> cking: I'm not sure it's documented, so not your fault
<cking> BenC: call it organic documentation
<cking> ..its in someone's head
<cjwatson> BenC: I think it's a bit of both actually. It's slower at device detection but faster at screen refreshes
<BenC> cjwatson: you should be good enough with d-i not to need a head to do the install :)
<asac> rtg_: iwl4965 from your PPA works great so far (scan_capa > 0 \o/)
<rtg_> asac: you get the one from this morning? Its based on 2.6.26-rc6
<asac> rtg_: err ;) ... not sure. i just added your hardy PPA and upgraded
<BenC> Checking ABI for generic...check FAILED (nice one Tonto, go get the Lone Ranger)
 * BenC marks intrepid for an ABI bump
<asac> at least i hae scan_capa now and NM 0.7 without workarounds connects quick
<rtg_> asac: great. its the absolute bleeding edge wireless support.
<asac> rtg_: is there anything we can do for hardy?
<asac> i think the workarounds that more or less works well for iwl4965 dont help that good for iwl39xx
<asac> at least i saw ken not being able to connect at all at UDS ;)
<rtg_> asac: I'm confused. the LBM package you are loading _is_ for hardy.
<asac> rtg_: yeah it is. buts its from PPA :)
<rtg_> asac: oh, I see. I'm waiting to upload until after the point release.
<asac> rtg_: or is that ment to go to -proposed at some point?
<rtg_> asac: it is, but Steve asked that I wait until the point release CDs are pressed.
<asac> kk
<asac> rtg_: but lum wont see a fix for scan_capa right?
<asac> which is still the default i guess
<rtg_> asac: yes, I can probably get that done. I think there is an LP report open on it, right?
<asac> rtg_: about missing scan_capa? i think so ... unless it was closed by accident ;)
<asac> rtg_: we can use bug 200950
<asac> probably should be reopened for  backport-modules 
<asac> too
<rtg_> asac: perhaps it never made it on ogasawara's list? In that case I might not have seen it recently.
<asac> rtg_: you closed that bug with: "* iwlwifi: Update to iwlwifi-1.2.25 and mac80211-10.0.4 - LP: #200950
<rtg_> asac: ok, I'll review it and try to figure out what happened. In the meantime I've gotta fix some CVE FTBSs for kees
<asac> rtg_: sure. ill reopen it for lbm and add lum to that bug
<rtg_> asac: k
<asac> and bump severity to medium (high?) and set it to triaged
<asac> ;)
<asac> rtg_: resume works well with your packages
<asac> only thing is that iwl4965 still has its own will in associating to some AP i never connected before after resume
<asac> (thats with NM 0.7 - aka without hacks and workarounds)
<rtg_> asac: I've never had prblems with that, but I'm using NM straight from the Hardy archive.
<asac> rtg_: yeah. that one has several hacks. i hope i can upload NM 0.7 to PPA in the next days
<Kano> http://rafb.net/p/U71w8c27.html
<Kano> thats the problem with xen + latest nvidia
<Kano> lastest git code
<Kano> BenC: dont forget module-init-tools
<Kano> and the modules abi bump
<Kano> so ne module-init-tools in d-u
<BenC> another hit and run
<BenC> and I've no idea what most of that meant
<BenC> and that doesn't look like a xen+nvidia bug...looks more like a paravirt+nvidia bug
<munckfish> BenC: Hi, could I pester you about that zinc account?
<munckfish> BenC: I'm concerned that the main Ubuntu linux source is getting so far ahead of the linux-port that we'll have a problem catching up.
<munckfish> I really need somewhere to upload a tree to so I can get some feedback on the changes I'm making. If zinc isn't the best place for that just now, just say and I'll look at alternative GIT hosting.
<BenC> munckfish: linux-ports is 2.6.25 based
<BenC> munckfish: there is no skew
<munckfish> BenC: did you update it quite recently then?
<BenC> munckfish: update what?
<munckfish> I last touched it on Friday night
<munckfish> oops sorry misread
<munckfish> now I mean you're moving on to 2.6.26 now
<munckfish> that's what you're targeting for Intrepid right?
<BenC> i386 and amd64 are going to be 2.6.26
<BenC> I was leaving linux-ports at 2.6.25
<munckfish> Ok, I just thought we would try to sync as close to i386/amd64 as poss
<BenC> but that's entirely up to who ever wants to maintain it...I can't see the need for 2.6.26, but it's someone elses effort, not mine...just remember it affects 4 architectures + the -386 flavour :)
<munckfish> BenC: ok
<BenC> munckfish: I'll get your request processed...note, I don't do it myself, I just process them through our IS team
<munckfish> ok that's fine I just wanted to know the score really
<BenC> score is You - 1, Me - 0 :)
<BenC> balls in my court, I'll get it taken care of
<lamont> "Q: what is the command for ejecting a DVD from the drive after a drive error? A: /sbin/reboot"
 * lamont would love to help fix that
<munckfish> BenC: hang on, i386, what's that in ports for? Is that just so we can build on x86 to test?
<mjg59> munckfish: i386 rather tha -generic
<mjg59> -generic x86 is still mainline
<BenC> munckfish: it's the old -386 flavour from mainline
<BenC> it's not needed for primary use, so we stuck it in ports
<BenC> linux-ports may become the place for things like binary-custom flavours (rt/xen/openvz)
<BenC> which is why it needs to be handled with care, and not just have tons of patches dumped into it
<munckfish> BenC, mjg59: ok so I take it -generic is more like i486+ (or is that stupid)?
<munckfish> ok so I'll take it that's correct :)
<munckfish> BenC: I have a very simple patch which allows me to cross build the powerpc64-smp kernel on x86.
<munckfish> Just allows setting of the CROSS_COMPILE variable so it can be passed to the kernel makefile
<munckfish> that plus running eval `dpkg-architecture -apowerpc -s` is all that was needed
<munckfish> are there likely to be any objections to including that in the packing scripts on linux-ports?
<munckfish> Surely it would be useful for the other arches too?
<munckfish> BenC: over
<BenC> munckfish: definitely...sounds like a good addition
<munckfish> BenC: cool
<munckfish> I have a script I wrote to intelligently compare/diff two kernel configs. Is that something that other folks would find useful? If so I'll mail it in.
<munckfish> However, I note most of the script the kernel team use are in Perl. My script is in Python, would that be a problem?
<munckfish> For anyone who may be interested I've just written in a PS3 project status update email. Includes progress on the kernel.
<munckfish> https://lists.ubuntu.com/archives/ubuntu-cell/2008-June/000122.html
<munckfish> That's my day over. Bye all.
<BenC> whoop
<BenC> lrm for intrepid is done
<BenC> pushed, and ready to upload
<Nafallo> ooh. does it include support for that eeepc wireless thingie? :-)
<Nafallo> cause in that case, it's time to dist-upgrade soon ;-)
<BenC> is that a madwifi svn thing?
<Nafallo> yea. that weird chipset that needs a new hal or something like that.
<BenC> then no :)
<BenC> same as the madwifi that's in hardy
<Nafallo> I'm stuck on gutsy then :-P
<BenC> Nafallo: I'd be willing to introduce an eeepc only madwifi that has just the PCI id's needed
<Nafallo> if you do, I would be happy to test it :-)
#ubuntu-kernel 2008-06-17
<zul> Kano: 
<rtg> cking: there is info about the SRU process here: https://wiki.ubuntu.com/StableReleaseUpdates
<cking> rtg: thanks!
<rtg> cking: if pitti agrees,  then we ought to package up dapper just for that one bug. I'm pretty sure it affects a bunch of folks.
<cking> rtg: I've subscribed ubuntu-sru - I suppose this will prompt pitti into action on it - not sure how to "package up dapper" though. 
<amitk> rtg: can we still do a hardy kernel + lum upload for lpia only?
<rtg> amitk: yeah, but not until after the point release freeze has thawed a bit.
<rtg> cking: this is when you get to start learning Debian packaging.
<amitk> rtg: what does that mean? We do want this in the point release w/o an ABI change...
<amitk> cking: lucky man! :)
<rtg> amitk: ok, so it _only_ affects lpia ?
<cking> it was inevitable. 
<cking> oh joy
<amitk> rtg: yes, since it only touches config.lpia. But a lum recompile is necessary because ABI is changing for lpia.
<rtg> amitk: so that means a forced version bump on LUM?
<rtg> e.g., that is what triggers a rebuild.
<amitk> rtg: I have a LUM lpia-only patch that could be snuck in there to go with the version bump. Intel would be happy...
<rtg> amitk: ok, so the issue is that there are already a number of SRU fixes pending in the Hardy repo. Steve is _not_ going to want those in the upload. What you have to do is prep a kernel and LUM upload that contains _only_ the lpia changes, then merge the changelog, etc, back into the master branch. Does that sound right?
<rtg> these freezes are a real pain in the ass, but I understand why he wants it done this way.
<amitk> rtg: correct. I can reorder that patches in the tree so only lpia ones are picked up... others will be 'floated' up towards the top.
<amitk> it will requires a git push -f
<rtg> amitk: well, now is as good a time as any. 
<BenC> amitk, rtg, cking: Not sure if you guys noticed, but 2.6.26 is default in intrepid now (or should be if the NEW process is done)
<BenC> new lrm was uploaded last night
<cking> BenC: Excellent
<BenC> And you guys might enjoy the new Kconfig system is lrm
<BenC> I'm going to use it as a basis for lbm in intrepid as well
<BenC> basically it's a full Kconfig like in the kernel, and you can do "debian/rules updateconfigs" like in the main kernel after adding or removing kconfig options
<BenC> even has an "-include .../autoconf.h" for the local results added to the build
<cjwatson> I processed at least some kernel stuff through NEW earlier today
<BenC> cjwatson: basically it was lrm and linux-meta
<BenC> rtg: and to make you happy, lrm is now in git :)
<BenC> Big fat note, is all of our firmware is now in lrm, and is installed via the linux-restricted-modules-common package
<BenC> IOW, firmware is not versioned based on the kernel now
<BenC> I'll do some documentation on this scheme later, but the simple description is, we will make an effort to version firmware by filename instead of installed duplicate copy of it for each kernel flavour/abi
 * BenC thinks he is done with his rambling now
<rtg> BenC: I versioned firmware for iwlwifi by changing the firmware file name in the source.
<BenC> rtg: exactly...that's the preferred way, IMO
 * pgraner notes BenC found coffee this AM
<BenC> pgraner: No, I was _served_ coffee
 * BenC keeps a tight leash on the little minions
 * pgraner just remembered why he had kids, to get served ....
<amitk> BenC: SELINUX is on by default in 2.6.26. Shouldn't we turn it off?
<BenC> amitk: enabled or actually on and being used?
<BenC> debian/config/amd64/config:CONFIG_SECURITY_SELINUX_BOOTPARAM=y
<BenC> debian/config/amd64/config:CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
<BenC> I show it as being enabled, but turned off by default
<BenC> debian/config/i386/config:CONFIG_SECURITY_SELINUX_DISABLE=y
<amitk> BenC: I didn't notice the BOOTPARAM_VALUE. That looks ok..
<BenC> pgraner: I'm sure you remember being the channel changer when you were a kid....I vowed to have my own channel changers when I grew up, but then they came out with remotes
<pgraner> BenC: yea now mine have become remote fetchers
<BenC> hehe
<BenC> amitk: drm-poulsbo keep/remove in intrepid?
<amitk> BenC: remove
<amitk> I will integrate it into the mobile kernel tree
<BenC> thanks
<BenC> Anyone have an atheros, broadcom 4312 or ltmodem they can test with intrepid kernel+lrm?
<rtg> BenC: I might have a 4312
<BenC> rtg: if you have any broadcom...maybe you can echo VEN:DEV into new_id for the driver and see if that works too :)
<rtg> BenC: its a 4328
<hallyn> rtg: did you have any questions about file capabilities?  Are you at all considering enabling them in the hardy kernel?
<BenC> cjwatson: Any gotchas in d-i stuff in 2.6.26/intrepid kernel?
<cjwatson> BenC: the 386 udebs aren't there
<cjwatson> I've disabled the netboot/386 build for now
<cjwatson> haven't found anything else so far, only found that five minutes ago ;)
<BenC> cjwatson: I thought you didn't use those?
<cjwatson> use which, the udebs, or the netboot/386 builds?
<BenC> we moved -386 to linux-ports
<cjwatson> yes, and that's fine, but it doesn't build the udebs any more
<BenC> cjwatson: ok. I'll take a look at that
<cjwatson> I believe some people do need to use them, or at least I'm not confident that they don't :)
<rtg> hallyn: kirkland brought that one up earlier this morning. I have a couple other issues to run to ground, then I'll take a look at it again. I did see your comment in the report.
<kirkland> hallyn: enabling for hardy kernel will be almost impossible, unless there's a security vulnerability.  enabling for Intrepid is what I think you're requesting....
<hallyn> kirkland: i'm a demanding jerk
<kirkland> hallyn: ;-)
<hallyn> rtg: ok, thanks, whenever you get a chance
<rtg> kirkland: as hallyn pointed out, it may well be a security vulnerability.
<hallyn> huh, what did i point out?
<kirkland> hallyn: in your bug comment
<rtg> hallyn: remind which bug number it was
<rtg> maybe I'm confusing things
<rtg> we're talking about the SET_PCAP stuff, right?
<kirkland> rtg: hallyn: bug #95089
<kirkland> hallyn said: "CAP_SETPCAP is dangerous when CONFIG_SECURITY_FILE_CAPABILITIES=n because then it allows a task to grant capabilities to other tasks."
<rtg> kirkland: right. I'll get to it as soon as kees and I are done with the -security uploads.
<kirkland> rtg: it = discussing, or it = enabling?
<hallyn> ah, excellent, i see chris friedhoff stumbled into a linked thread and wants to help :)
<rtg> kirkland: "it" being a nonspecific promise of attention.
<kirkland> rtg: ;-)  cool
<BenC> IRC meeting time
<BenC> Give me 2 minutes to prepare
<mrec__> BenC: ping
<BenC> Ok, sorry for the delay
<BenC> amitk_, rtg, cking: You guys present and accounted for?
<cking> Here
<rtg> BenC: dude
<BenC> Just to get started, the primary agenda for this meeting is to discuss what's happening in Intrepid now and in the coming months
<BenC> So as of last night some time, 2.6.26-rc6 went default in intrepid
<BenC> If you pay attention to the git repo's, you will notice that much of lum has moved back into the main tree under ubuntu/
<BenC> There are a few drivers still left to move, and that will occur over the coming weeks
<BenC> In addition, lrm has been uploaded for intrepid
<BenC> All of our firmware has been moved to linux-restricted-modules-common package
<BenC> This includes firmware that was in lrm and in lum
<BenC> The only drivers in lrm at the moment are broadcom 4312 hybrid driver, madwifi (still 0.9.4) and ltmodem
<cking> BenC: Are many of the lum modules been updated, e.g. lirc?
<BenC> nvidia and fglrx are being moved to a DKMS style package and will be available separately
<BenC> (and just to note, almost all of this is documented on the kernel team wiki, and was discussed at UDS)
<BenC> Speaking of UDS/wiki, the specs from there will get fleshed out soon to provide more implementation details
<BenC> rtg, amitk_, cking: Do you guys have anything to add?
<BenC> cking: the ones in the tree already have been refreshed to the latest stable versions
<rtg> BenC: nah, just working on SRUs for older kernels.
<BenC> The ones left to move (lirc included) will also be refreshed
<BenC> Well that's all I have...anyone want to add anything, or have any questions?
<BenC> mrec__: did you have something for the meeting, or was that a general ping? :)
<cking> BenC: Will the build for lrm be different to that of Hardy?
<BenC> it is based on the lum/lbm packaging
<BenC> but has the addition of better config handling
<BenC> it is also in git
<cking> Better all round then
<BenC> yeah, should make working with all the kernel related trees more consistent now
<BenC> We'll need a good doc refresh on the kernel team wiki to match the changes too
<BenC> If no one else has anything to add...
<BenC> Ok, meeting adjourned then
<BenC> Thanks everyone
<kees> infinity: you around?  rtg and I are trying to debug a security buildd failure on amd64 lbm
<kees> rtg: does the amd64 failure match the prior one?
<rtg> kees: no, its slightly different, but no less confusing. however, it does build locally under a gutsy chroot.
<rtg> kees: I'm gonna package it with an ubuntu1 version and upload it to my PPA.
<kees> rtg: okay
<lamont> which suite?
<rtg> lamont: gutsy?
<lamont> package logic is flawed
<lamont>           dpkg -x $(ls ../linux-backports-modules-$i\_*amd64.deb) \
<lamont> so what happens when -nn.xx and -nn.yy exist in the parent directory???
<lamont> one must never make assumptions about the contents of the parent directory, other than that maybe the deb we just packaged landed there
<rtg> lamont: so dak must have a package alreay there that matches, right?
<lamont> rtg: the buildd does
<lamont> specifically, s/3/2/ in the package name... and they're both there.
<rtg> lamont: I guess that explains why the previous version built ok.
<lamont> yep
<rtg> and why my local versions don't fail, since I clean first.
<lamont> rtg: next time you're messing around in the build process, that '*' should be replaced with the version number... :-)
<rtg> lamont: well, I think I have to do it for this version, un;ess you can remove older releases.
<lamont> rtg: can do
<rtg> lamont: looks like hardy has the same issue.
<lamont> kees: do I need to figure out how to do the give back as well, I assume?
<lamont> rtg: I doubt the source has ever been right...
<kees> rtg: so the -15.12 failure was due to accidental changes outside of just abi bump, and -15.13 failed due to -15.12 existing?
<kees> (and why only for amd64?)
<lamont> meh.  what's the source package name?
<rtg> lamont: linux-backports-modules-...
<lamont> yeah... it's the ... that I'm curious about
<lamont> and I see that I can tell that
<rtg> linux-backports-modules-2.6.22
<rtg> lamont: I should be able to reproduce this in a chroot.
<lamont> given back
<kees> lamont: cool, thanks muchly
<lamont> rtg: yeah - in the same place where you said dpkg-source -x (parent of linux-backports-modules-2.6.22-2.6.22), say touch linux-backports-modules-2.6.22_foo.amd64.deb
<lamont> and then cd into linux-backports-modules-2.6.22-2.6.22 and do a build
<rtg> lamont: right
<rtg> lamont: that also explains why the PPA always works, it creates xen instance from scratch
<lamont> yep.
<lamont> pls to fix before next upload, kthx. :-)
<kees> geh, failed again
<rtg> kees: did lamont not remove the enough debs?
<lamont> meh
<lamont> I thought I had
<lamont> find: debian/updates-modules-2.6.22-15-generic-di: No such file or directory
<lamont> updates-modules-2.6.22-15-generic-di will be empty
<lamont> make: *** [binary-udebs] Error 1
<lamont> not my doing
<lamont> and that'd be why -15.12 was still sitting there...
<lamont> looks like you _do_ get to fix it. :0)
<rtg> kees: ok, gimme a bit.
<lamont> that was the output from         kernel-wedge find-dups 2.6.22-15-generic
<infinity> kees: Yeah, I'm around.
<rtg> infinity: I think we're getting it figured out.
<kees> rtg: let me know if I can help
<rtg> will do
<infinity> lamont: Err, eww.  It was using ../ ?
<lamont> infinity: with a wildcard, no less.
<lamont> because, I mean, why would there be files in the parent directory??? :-(
<infinity> And, on a different note, why ARE there files there?
<infinity> As in, why is there stuff built that's not in .changes?
<infinity> linux-backports-modules-2.6.22-15-generic_2.6.22-15.13_amd64.deb
<infinity> linux-backports-modules-2.6.22-15-rt_2.6.22-15.13_amd64.deb
<infinity> linux-backports-modules-2.6.22-15-server_2.6.22-15.13_amd64.deb
<infinity> linux-backports-modules-2.6.22-15-xen_2.6.22-15.13_amd64.deb
<infinity> Tsk, tsk.
<lamont> infinity: oh, those are from the build failure that followed
<lamont> they're smashing them into .changes as they go.  why would they use dpkg-deb like everyone else??
<lamont> and then the build fails, and they leave detris to trip on the next time,.
 * infinity cries.
<infinity> Okay, rebuilding.
<lamont> otoh, if I fetch a whole bunch of source versions and for i in *.dsc; do dpkg-source -x && $appropriate_cd && debuild -B; done; it'll blow up
<lamont> infinity: I gave back -15.13 and it blew up with the empty generic-di thing
<lamont> which, I expect, will require a new upload
<infinity> Ahh, I see.
<infinity> Relying on an empty build directory is stellar, though.
<rtg> lamont: actually, the  empty generic-di thing was the first build failure, and I don't understand it.
<infinity> Cause, like, who ever builds in a directory with stuff in it?
<rtg> infinity: did Fabio write this originally?
<infinity> rtg: Is it based on LRM?
<rtg> infinity: no, probably LUM
<infinity> rtg: Ahh, I don't know if Fabio had much to do with LUM.
<infinity> rtg: I thought that was Ben.
<infinity> rtg: LRM was Fabio, then half rewritten by me.
<rtg> infinity: could be. It likely came from Feisty, and I've just inherited it.
<infinity> rtg: We have a saying for that around here... I think it goes something like "Sucks to be you."
<rtg> infinity: such sympathy.
<infinity> rtg: I'm known far and wide for my lovely demeanor and sympathetic ear.
<rtg> infinity: hmm, I've noticed.
<infinity> *cough*
<lamont> infinity: remember to turn your head.
<lamont> so now that I've finally upgraded to 2.6.24-19, how soon is the next kernel going to land and make me do it all over again?
<rtg> lamont: a couple 3 weeks yet
<lamont> kewl
<infinity> rtg: The PPA upload you did a while ago seems to have worked...
<rtg> infinity: its the clean xen instance creation.
<infinity> rtg: Also, completely offtopic.  Now that -19- is out, have you rolled those hppa changes into git for -20-?
<infinity> rtg: Err, a dirty chroot can't be causing "find: debian/updates-modules-2.6.22-15-generic-di: No such file or directory
<rtg> infinity: glad you reminded me. need to do that still.
<rtg> infinity: perhaps not, but its a condition that appears to be unique to the security buildd
<infinity> rtg: Or, perhaps, unique to chroots using pkg-create-dbgsym and pkgbinarymangler?
<infinity> rtg: (PPA doesn't, because it's not a primary archive)
<rtg> nifinI'll have to take your word for it :)
<rtg> infinity: I'll have to take your word for it :) even
 * infinity grabs a chroot and does a test build for kicks.
<infinity> rtg: For the record, the security chroot is as clean as can be.  No stray packages, nothing in /build/buildd. nothing in /tmp, etc.
<infinity> rtg: I'm going to try to reproduce this on my laptop, though, so we can stop blaming poor king.
<rtg> infinity: k
<infinity> rtg: Same failure on my laptop.
<infinity> rtg: You want precise reproduction instructions?
<rtg> infinity: ok
<infinity> rtg: Kay.  Just testing to see if your PPA version fails the same way.
<infinity> rtg: If so, I'll give you directions to reproduce locally. :)
<infinity> rtg: Your PPA version built fine here.
<infinity> rtg: So, whatever cruft you cleaned up, that fixed the bug.
<infinity> rtg: (To reproduce, if you were so inclined, you'd need to untar a chroot from chinstrap:~adconrad, fiddle with resolv.conf and sources.list to be sane, install build-deps, "sudo chroot chroot-autobuild su - buildd", "cd /build/buildd" "dpkg-source -x /tmp *.dsc" (assuming you put the source in tmp), and then dpkg-buildpackage from there.
<infinity> rtg: But might just be easier to take my word for it that "15.33 doesn't work, 15.33ubuntu1 does".
<rtg> infinity: they ought to be identical except for 'ubuntu1'
<infinity> rtg: They really aren't.
<rtg> just to be clear, the version is -15.13, right?
<infinity> Err, 13, not 33, yes.
<infinity> Ugh, -15.13ubuntu1 has all sorts of binary cruft in it, though. :/
<infinity> That said, it "works". :/
<rtg> infinity: could be, I didn't debdiff it before uploading
<infinity> I suspect this is what's making it "work":
<infinity> linux-backports-modules-2.6.22-2.6.22/debian/updates-modules-2.6.22-15-generic-di/DEBIAN/control
<infinity> Though that just feels icky and wrong, cause that so looks like it should be autogenerated.
<rtg> infinity: I'm pretty sure it is generated
<infinity> Possibly not, though.
<infinity> It doesn't get cleaned on debian/rules clean, at least.
<infinity> And the package sure seems to be unhappy about it not being there.
<infinity> *shrug*
<infinity> Oh, wow, this clean target is retarded.
<infinity> The package (and git, possibly) will develop cruft if people build with one arch, but clean with another.
<infinity> (As is the case here... I'm cleaning on amd64, but have i386 cruft lying around)
<infinity> And that's why there's cruft in the PPA source.
<infinity> debian/d-i-i386 needs to be manually cleaned if you're on amd64, and vice versa.
<infinity> (And same for the other arches, I guess)
<infinity> rtg: Anyhoo.  If you just rm -rf debian/d-i-i386, fix the version number to -15.34, and regenerate control, upload, should be good.
<infinity> rtg: (Or seems to be here)
<rtg> infinity: ok, I about have the exact fine match pattern figured out.
<rtg> s/fine/fuile/
<rtg> you get the picture...
<infinity> I hope it's better than that regex .;)
<rtg> infinity: yep - it uses existing make variables that have all the info I need.
<rtg> infinity: how about this: 'dpkg -x ../linux-backports-modules-$${i}_${pkgversion}-${revision}_${arch}.deb $(udebdir)/'
<infinity> rtg: Assuming that works, it looks slightly saner.
<rtg> infinity: it seems to, and its an exact match, no wild cards
<infinity> Yay.
<mario_limonciell> hi guys: is it possible to provide a blacklist for a module on the kernel command line itself? I didn't see anything in quick searches, but I was hoping so
<mkrufky> ah, you're here now
<mario_limonciell> yeah hi :)
<mario_limonciell> multiple fires i'm unfortunately fighting simultaneously 
<mkrufky> i have a link for you ... any second
<mkrufky> brb
<mario_limonciell> argh: it looks like it was a brainstorm idea but it didn't happen yet http://brainstorm.ubuntu.com/idea/86/
<kees> rtg: any closer to happiness on the l-b-m build?
<rtg> kees: I finally got it to fail on my PPA. I gotta take off for awhile, but will work on it more tonight.
<kees> rtg: yay reproduction!
<kees> rtg: okay, cool
#ubuntu-kernel 2008-06-18
<xivulon> hi cking,
<xivulon> thanks a lot, that looks like great work
<xivulon> I replied in #204133
<cking> xivulon: I added the syncs on the loopback so that ext3 dirty writes are forced through to the ntfs below. Without it, there will be latency between ext3 writes and the final write to the device
<cking> xivulon: The ntfs-3g debdiffs need pushing into Intrepid too. Not sure if that's my domain.
<xivulon> cking, for intrepid I think the best route is to have the patch upstream directly
<xivulon> I have already notified szaks
<xivulon> szaka
<cking> xivulon: Thanks - that makes my life easier :-)
<cking> xivulon: Can you take it from here - do some testing on a Windows box and verify it works 100% correctly - and then see if the patch goes upstream too?
<xivulon> as for nested writes, aren't only the journal flushes relevant? I would assume that once the nested ext3 tries to write to the journal it will go through ntfs-3g which will in turn writ to disk
<xivulon> that is whether the nested ext3 is mounted with -o sync or not
<xivulon> but provided that ntfs-3g is mounted with -o sync
<xivulon> or at least that is my understanding
<xivulon> cking, sure I will do the testing, and modify related packages (lupin/wubi/initramfs accorddingly)
<xivulon> only need clarification on the above question
<cking> xivulon: ext3 journal writes will be flushed straight through to the device if ntfs-3g has the -syncio mount option. However, if you want extra resiliance to make sure writes get flushed immediately then I recommend -o sync on the loop too
<cking> It's a kind of performance vs reliability tradeoff 
<xivulon> any idea of the performance hit for that?
<cking> My tests showed -o sync on the loop was 1/3 to 1/2 slower. But I did just raw block write tests using dd. Normal usage may differ.
<xivulon> hm so it's on the heavy side
<cking> cking: A lot of the time data is being read and not written, and so real case usage may not see a significant impact. That's why it's worth testing in a real world Windows box test just to see
<xivulon> that is an easy test, only involves changing the boot parameters and upgrading ntfs-3g
<cking> xivulon: the sysctl hacks are fairly poor performance hit too, so Wubi users will probably not see much of an difference 
<cking> ..and the benefit is that removing the sysctl hacks mean than external devices like USB disks will perform well with the sysctl hacks removed
<cking> xivulon: I suspect that testing this is the only way to see if it's a usable solution with respect to performance. ntfs-3g is a performance hit which is something we are stuck wth
<cking> ..but at least we can tweak the loopback sync or no sync option.
<xivulon> cking thanks a lot that is great, I'll take care from here on
<cking> xivulon: I need to go - I have some stuff that needs attending to. Keep me posted.
<xivulon> will do
<cking> great
<LimCore> hi
<LimCore> how about addiging ubuntu packages for kernel.org vanilla kernels?  like say   linux-kernel.org-stable  and  linux-kernel.org-prepatch.  No ubuntu patches so  1) easy to package  2) good for people working on kernel development/testing
<xivulon> cking any reason why the option is called syncio as opposed to sync?
<cking> xivulon: sync is a non ntfs-3g option that can get passed through as a mount option to mount, but it's currently ignored by fuse - hence I added a syncio option which won't clash with fuse 
<xivulon> I see, thanks
<cking> cking: one day sync may be honoured correctly by fuse, which may make syncio redundant
<mkrufky> how do i just build the linux-ubuntu-modules?  im getting my patch ready and just want to confirm im not missing any dependencies
<rtg> mkrufky: use 'debuild -b' to check build dependencies.
<mkrufky> ok, cool
<mkrufky> thanks
<rtg> mkrufky: note that it only checks dependencies for the arch under which you are building.
<rtg> but you should be OK with LUM.
<mkrufky> i dont think that would matter in my case
<mkrufky> i just want to make sure i didnt omit any new headers
<rtg> mkrufky: are you building both x86 and x86_64?
<mkrufky> i been building within the linuxtv.org hg repo
<mkrufky> the code is safe for both x86 and x86_64 -- i test on both machine types using the linuxtv.org tree
<rtg> that seems sufficient
<Kano> did somebody delete intrepid-lum.git?
<rtg> Kano: it got folded into the Intrepid kernel package
<Kano> like for 2.6.22?
<rtg> Kano: there is no LUM for Intrepid. All of those modules are now residing in the ubuntu-intrepid.git and are built along with the kernel.
<Kano> there was it 2 days ago
<rtg> Kano: change is good.
<cking> change is frequent
<Kano> where is the firmware then?
<rtg> Kano: I think its all in LRM now
<Kano> not good, lrm is a crap package
<rtg> Kano: its undergone serious surgery. a face lift of massive proportions.
<Kano> also when you enable madwifi you have to disalbe ath5k, thats clear or not?
<rtg> Kano: dunno. its a work in progress. BenC is in the drivers seat.
<Kano> ath5k is free variant of madwifi (ath_pci)
<rtg> Kano: I even know the guy that wrote ath5k.
<Kano> do you own a card for it
<rtg> Kano: only in mini-PCI form factor.
<Kano> well that does not matter the form factor, you can try it, thats all needed
<Kano> maybe i create my own package from the ubuntu-firmware part
<Kano> will you revert the gpl only usb exports to make avm usb drivers work?
<rtg> Kano: against the author's wishes? Thats highly unlikely.
<Kano> well it is not forbidden or?
<Kano> i dislike when a new kernel supports less hardware
<rtg> Kano: I'm not qualified to say, but no one at Ubuntu is going to do it.
<Kano> will you change the alsa-base package for options snd-pcsp index=-2? or does pcsp not install in front of other sounddrivers for you?
<rtg> Kano: perhaps you could suggest it to BenC. I'm not working on Intrepid right now.
<Kano> i guess more kanotix users test your new kernels as ubuntu users ;)
<Kano> i added already a blacklist to my module-init-tools for snd-aw2
<Kano> but several users have problems with sound order, so guess i will patch alsa-base
<mkrufky> rtg: i have my first version of the lum patch ready -- can you take a look?  this just adds the new files, still needs to be integrated into your build  ï»¿http://linuxtv.org/~mkrufky/lum/add-hvr950q-to-lum.patch
<rtg> mkrufky: for LUM you enable configs in debian/config/${arch}. Kconfig won't do much.
<mkrufky> ok
<mkrufky> ...any chance you can just fix this patch up, so that i'll know what to do for all future patches?
<rtg> mkrufky: echo "CONFIG_VIDEO_AU0828=m" >> debian/config/i386 ? Its no more complicated then that. Just add your config macros to the appropriate arches (I assume just i386 and amd64)
<mkrufky> ah, ok cool
<mkrufky> :-)
<mrec__> BenC: ah well I would have had something sure 
<mrec__> BenC: it would be nice if someone could have a look at: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/230877
<cjwatson> BenC: could you please move isofs back to storage-core-modules (from fs-core-modules)? it makes a lot more sense there even though it's the only filesystem module there, because the rest of fs-core-modules isn't needed in the cdrom initrd
<mkrufky> rtg: i updated the patch at the same location -- i think it's good to go now
<rtg> mkrufky: if you've built it and tested successfully, then email the patch to the kernel team mailing list.
<mkrufky> ok
<BenC> cjwatson: done
<Kano> BenC: do you want my alsa-base fix?
<Kano> or dont you have the problem with snd-pcsp?
<BenC> there is a problem, but I've no idea what your fix is
<Kano> well i changed the rules
<Kano> to add a new index=-2
<BenC> isn't that something we can add into module-init-tools?
<Kano> well there i added a blacklist for snd_aw2
<Kano> but thats basically another problem
<Kano> for snd-pcsp there is only a alsa order problem
<BenC> cjwatson: do you think we really need scsi-tape block driver in d-i at all?
<BenC> cjwatson: do you know of anyone doing installs from tape? :)
<Kano> BenC: look into query for alsa-driver (alsa-base source package) hack
<zul> BenC: I like being retro ;)
<Kano> hmm have to put in my ati card to test ati 8-6 ;)
<BenC> grrr...you should not need anything other than build-essential to do a source only upload
<Kano> BenC: can you rename dm-raid4-5 to dm-raid45 like it is in current hardy
<cjwatson> BenC: scsi-tape doesn't sound necessary
<cjwatson> BenC: module-init-tools is not involved in d-i
<cjwatson> at least not in any relevant way
<cjwatson> 18:15 <BenC> there is a problem, but I've no idea what your fix is
<cjwatson> BenC: what's the problem?
<BenC> cjwatson: that was to Kano
<BenC> Kano: I don't want to rename it away from what upstream had it
<cjwatson> oh, right, sorry
<BenC> Kano: possibly had an alias, but keep the module name the same
<Kano> BenC: just rename the target then dmraid can autoload it
<BenC> I don't want to change upstream's naming
<Kano> i checked with modinfo, the module in -19 kernel IS renamed
<Kano> you have to
<BenC> I don't have to
<Kano> to fix the dmraid issue
<Kano> look into hardy changelog
<BenC> I'll investigate, but I'm not going to just haphazardly change the upstream naming
<Kano> well the nameing in the patch is wrong as it can not be found by dmraid
<BenC> in what patch?
<BenC> I downloaded the actual source from upstream
<BenC> if something is inconsistent, I need upstream to make a decision, otherwise I'm fighting a long drawn out battle
 * BenC recalls tar's bzip2 command line argument as a good example
<rtg> BenC: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/220493
<rtg> BenC: probably ought to get the dmraid user space tools to use the right module name.
<BenC> rtg: sounds like the right way
<BenC> hmm...there's definitely a dead server on the us.archive.ubuntu.com round-robin
<rtg> BenC: you know, I've had problems off and on today also. I finally just went to rookery to get bits.
<BenC> rtg, Kano: Uploaded a new dmraid package that uses raid4-5
<BenC> raid4-5 sounds better anyway...like "4 or 5" rather than "forty five"
<Kano> BenC: when you change dmraid then add the new module to initramfs
 * kees makes flushing noise -- stable kernel updates are going out to soyuz...
<kees> rtg: ^^ I finished my last-minute boot-testing-of-dak-builds
<elmo> aiee
<kees> elmo: ?
<pwnguin> I'm thinking about moving a bug from wacom-tools to linux, but I need some guidance on triage
<pwnguin> the wiki mentions like three teams to assign to when marking confirmed
<pwnguin> but i also found a ubuntu-kernel-usb
<pwnguin> is that dead?
 * pwnguin reads harder
#ubuntu-kernel 2008-06-19
<baron1984> I have a question about the kernel, if anyone can enlighten me for a moment
<baron1984> 2.6.24-17 and -18 failed to resume from suspend entirely requiring me to cut power to the power supply itself before the computer would even boot again
<baron1984> 2.6.24-19 resumes but makes a chirping noise from the speakers then says it failed to resume
<baron1984> is there any harm in using suspend in light of this?
<baron1984> I looked in the system log and all it says is: Jun 18 19:48:52 ryan-desktop gnome-power-manager: (ryan) suspend failed
<sisyphe> frenchies here ?
<crimsun_> BenC: the previous intrepid upload of alsa-driver (1.1ubuntu1) already contains maks_'s addition, which you noted per Kano in the changelog for 1.1ubuntu2.  What gives?
<Kano32> hi BenC , i have got a problem with the lrm package
<Kano32> i raised the abi with
<Kano32> DEBFULLNAME="Hotfix" DEBEMAIL="no@mail.ad" dch -v 2.6.26-2.0 Kernel ABI bump.
<Kano32> then usually
<Kano32> debian/rules clean
<Kano32> should update the abi
<Kano32> but it does fetch 1 not 2 as abi, it seems the lowest line is used not the top line of the changelog?
<Kano32> sed -e 's/PKGVER/2.6.26/g' -e 's/ABINUM/1/g' >>
<Kano32> this is exchanged
<Kano32> but when i put the new abi in the last line of the changelog this is evalutated, something is really wrong there..
<Kano32> the same worked with lum
<Kano32> could somebody look at this please..
<Kano32> stupid package
<Kano32> hmm now i know it...
<Kano32> you renamed the package from linux-restricted-modules to linux-restricted-modules-2.6.26
<Kano32> then it can not work...
<saispo> hi all
<saispo> it's normal in ubuntu-feisty branch there are no debian/abi/2.6.20.17-36/ ?
<xivulon> at UDS I understood that that intrepid kernel will support suspend-to-disk also when swap is on file
<xivulon> can someone pls confirm that? 
<mjg59> The kernel already supports suspending when swap is a file
<mjg59> But there's no support for resuming
<xivulon> mjg59: is that planned for intrepid?
<mjg59> I'm afraid I don't know.
<cjwatson> BenC: bug 241295 is another udeb issue for you (or somebody)
<xivulon> cking, given your patch in ntfs-3g, do you think there is still any reason to use dm-loop (for intrepid)?
<xivulon> will that improve write performance?
<cking> xivulon: one I have a usable intrepid kernel on my 2 boxes here I can thoroughly benchmark it and compare it with the normal loopback
<cking> xivulon: dm-loop will give better performance if it has direct access to the block device - in the Wubi case it won't, so the difference is debatable
<xivulon> does it help with LVM(2) by any chance? that is in order to have resizable virtual disk
<cking> xivulon: I'm unsure of this.
<xivulon> thx
<cking> xivulon: can you drop me an Email concerning the LVM(2) resizable virtual disk requirements so that I won't forget it and so I can mull over that question
<xivulon> https://wiki.ubuntu.com/WubiIntrepid
<cking> excellent!
<xivulon> on that subject, do you think we can do anything on fsck for ntfs-3g?
<xivulon> not necessarily a full blown fsck, but at least to address most common (or easier) issues
<xivulon> and turn off the dirty flag
<zul> gah....I didnt notice the ubuntu directory in ubuntu-intrepidi git tree
<rtg> zul: its the new LUM
<zul> rtg: gotcha
<zul> drbd needs to be updated since I uploaded a new version today
<cking> xivulon: it makes me feel uncomfortable fsck'ing a ntfs volume. It's a userland tool that I have no personal experience of (yet! :-)
<xivulon> cking, I know, but that is probably the biggest issue we have in wubi at the moment :(
<cking> xivulon: I suppose resourcing the ntfs fsck fix is the question to ask.
<zul> BenC: ping
<BenC> zul: yo
<tseliot> BenC, rtg: why is the -generic flavour of Intrepid's kernel Xen-enabled?
<zul> BenC: for the drbd8 any reason why you chose the 8.2.6 version?
<BenC> tseliot: so it can be used a guest in xen environments
<BenC> zul: I chose the latest version I saw available
<zul> BenC: ah because I just uploaded 8.0.12 version which was just merged from debian
<tseliot> ï»¿BenC: fglrx doesn't work with Xen kernels and I'm having problems with nvidia too
<BenC> tseliot: tell fglrx to ignore that fact...I think if you do that, it works ok
<BenC> tseliot: have you contacted nvidia to see if they can fix their end?
<zul> I doubt they will :)
<tseliot> BenC: I have contacted them because their new driver (there are 4 flavours now) doesn't build with realtime kernels but I haven't received any reply
<tseliot> BenC: here's the error with the NVIDIA driver: ï»¿http://pastebin.com/m3c096a17
<tseliot> with the -generic flavour
<emgent> tseliot: heya
<tseliot> BenC: I'm a bit concerned about this, since tjaalton and I should replace the lrm with the new packages in Intrepid
<tseliot> ï»¿emgent: hi
<tseliot> BenC: I'm building with ï»¿IGNORE_XEN_PRESENCE=1 IGNORE_CC_MISMATCH=1
<BenC> tseliot: yeah, new lrm for intrepid is uploaded, without nvidia and fglrx
<tseliot> BenC: I'll try contacting NVidia on their forums and saying explictly that I'm the new maintainer. Let's see if they care to reply.
<BenC> tseliot: that looks like something I can fix
<BenC> tseliot: can you give me your wip packages?
<tseliot> BenC: ï»¿wip?
<tseliot> ah ok
<tseliot> work in progress
<tseliot> yes, sure
<BenC> cjwatson: does that af_packet bug imply that we should have another upload soon for alpha 1?
<tseliot> BenC: I'll upload them right now to my webspace.
<BenC> cjwatson: I can do one today
* lukehasnoname changed the topic of #ubuntu-kernel to: "Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-16.30 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: April 22, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com UPDATE THE TOPIC"
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-1.5 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: June 24, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<zul> how do you just build the lum stuff in intrepid now?
<cjwatson> BenC: yes please - lack of DHCP is sort of fatal :)
<BenC> zul: there is no "lum stuff" in intrepid
<zul> so I have to do the fakeroot debian/rules binary-generic ?
<BenC> zul: there are ways of only building a portion of the kernel tree if that's what you are trying to do
<zul> BenC: yes please :)
<BenC> zul: mkdir ../build; cat debian/config/i386/config{,.generic} > ../build/.config; make O=`pwd`/../build prepare; make O=`pwd`/../build ubuntu/
<BenC> that will build just the stuff under ubuntu/
<BenC> you can even do things like ubuntu/aufs/
<zul> BenC: thanks
<mst_> Hey guys, I'm really stuck here: I cannot get Linux to see my IDE cdrom drive unless I boot with acpi=off -- I've tried just about every boot-time option with the stock Ubuntu kernel and just about every possible way of configuring things with a custom kernel to no avail... I need some help in figuring out what to do next to try and track down the problem 
<BenC> mst_: the problem sounds like a BIOS issue
<BenC> mst_: I suggest seeing if there's a BIOS update before doing further
<BenC> mst_: the next step would be a bug report along with the usual info (dmesg with and without acpi=off, lspci -vvn)
<mst_> BenC: I'm real frustrated because I can boot a LiveCD just fine -- I have the latest BIOS, its from Lenovo and it's real shitty... totally devoid of configuration options and info 
<BenC> mst_: maybe just adding acpi=off /boot/grub/menu.lst (but I suspect without acpi you don't get suspend)
<BenC> mst_: Oh, wait, you can boot the livecd fine (without acpi=off) but not your install?
<mst_> BenC: yeah, acpi=off is not really a solution for a laptop system :-( 
<mst_> BenC: yeah
<BenC> mst_: which release is this?
<mst_> BenC: 8.04 
<BenC> is the installed kernel updated prior to having this problem? what if you boot the originally installed kernel (via grub menu)?
<mst_> I started running 8.04 pre-release and this problem has persisted with every subsequent kernel update 
<mst_> I suspect it has something to do with the fact that it's an IDE cdrom and a SATA hard disk
<BenC> I can't see how a livecd boots fine, but the normal install doesn't work
<mst_> the live cd boots, installs, and I can boot and everything works great, just no cdrom without "acpi=off" in the actual install 
<BenC> mst_: does your BIOS have a way to set your hd controller to something like legacy/compatible/ahci?
<mst_> and i've tried libata.noacpi=1
<BenC> mst_: but the livecd wouldn't be able to boot if it didn't find your cdrom :)
<mst_> That's why I suspect that libata is taking over control of the IDE ports (verifed by cat /proc/ioports) but wont recognize my drive 
<BenC> libata is supposed to do that
<mst_> I tried compatable and achi mode, each with combined_mode=ide and combined_mode=libata 
<mst_> Yeah, but even with libata.atapi_enabled=1 I get nada... and I've tried all of these options as parameters in /etc/initrd-tools/modules, and having made and used the new initrd 
* BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-2.6 |  Latest news: Intrepid plans open: https://wiki.ubuntu.com/KernelTeam/UDS/May2008 | Next meeting: June 24, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
<BenC> atapi is enabled by default in libata
<BenC> so you can likely stop chasing that route, since libata is going to be the way your drive is detected
<BenC> mst_: I'd be interested in a dmesg from a livecd boot, and one from a normal install boot (without acpi=off) to compare
<mst_> cool, so what I think I might need to do is tell the kenrel explicitly what ioport to use for the cdrom drive 
<BenC> if it works in a livecd, it should work in the installed system
<mst_> I'd be happy to colleced that data, should I go about doing that now? I can but them both up in my public http space on my schools server 
<BenC> mst_: yes, please
<mst_> Alright... I have some rebooting to :-), be back in a few minutes 
<lukehasnoname> if you had it on a VM you wouldn't have to bring down your machine :)
<BenC> also probably couldn't reproduce the problem either :)
<mst_> lukehasnoname, wouldn't the kernel just see virtual hardware? I have to be honest I don't know too mcuh about that 
<mst_> alright rebooting...
<BenC> cjwatson: new kernel+lrm uploaded, I'll get meta out when it's near finished (which should be quick)
<BenC> cjwatson: it is an ABI bump
<cjwatson> ok, thanks
<BenC> cjwatson: builds for intrepid appear to be amd64=1:20hours and i386=2hours
<BenC> just FYI
<mst_> Alright... 
<mst_> BenC: you should be able to see 3 files at www.uvm.edu/~mtretin 
<mst_> BenC: I did dmesg for the installed system in AHCI mode and in Combatible mode 
<mst_> as well as AHCI mode for the liveCD 
<mst_> BenC: are you able to access them? I don't really ever use the public_html directory... 
<BenC> mst_: weird, it's just plain not even probing the device...I was expecting a failure msg of some kind
<BenC> mst_: do you have 2.6.24-16-generic on the installed system? If so, can you give me ahci dmesg from that?
<BenC> that's what the livecd is booting, and I want to compare the same kernel on both sides
<mst_> BenC: yep... just one reboot away 
<mst_> brb
<bdmurray> rtg: I seem to remember talking about bug 213011 in Prague but don't recall what you said.
<BenC> hmm...ide-pci-generic.all-generic-ide
<BenC> that shouldn't be there either
<rtg> bdmurray: looking...
<bdmurray> rtg: thanks
<rtg> bdmurray: these guys need to be running the -19 kernel. there was a cosmetic fix that I think will help them out.
<mst_> BenC: it should be there nw
<bdmurray> rtg: alright, I'll ping them
<rtg> bdmurray: I'll add it to the report
<bdmurray> rtg: is that in -updates yet?
<rtg> yep
<mst_> BenC: thank so *very* much for all the help BTW
<bdmurray> I'm so confused running -proposed all the time
<rtg> bdmurray: I hear you there.
<BenC> mst_: np...I tried to catch you before you left out, but can you also remove "ide-pci-generic.all-generic-ide" from the kernel cmdline...I don't think it is an issue, but just to keep a consistent test, redo the last dmesg without that
<BenC> mst_: and thank you for taking the time to track this down
<mst_> BenC: no problem... just let me get vim up...
<mst_> BenC: dmesg.2.6.16-generic.achi-mode.txt should now be w/o the bogus kernel parameter 
<mst_> or argument... to be technical lol 
<tseliot> BenC: check your mail or the kernel mailing list. I have sent you the links to the source of my packages
<mst_> BenC: and as far as me taking the time to track this stuff down... I couldn't be happier that I'm finally talking to someone who isn't telling me to do "modprobe ide-cd" :-)
<BenC> mst_: I'm at somewhat of a loss as to why this is happening
<BenC> mst_: can you try "sudo modprobe sr_mod"?
<mst_> BenC: still no /dev/scd0 
<mst_> BenC: woudl a dmesg with the option acpi=off (when the cdrom appears as scd0) help? 
<mst_> BenC: I would love to figure out exactly what the addresse for my cdrom is, then couldn't I try ide0=xxx at boot time? 
<BenC> mst_: is there anything in dmesg when you modprobe sr_mod?
<BenC> mst_: also, try "sudo modprobe -r ata_piix; sleep 1; sudo modprobe ata_piix"
<mst_> BenC: modprobe sr_mode doesn't put anything interesting in dmesg, except possibly "Driver 'sr' needs updating - please use bus_type methods" 
<mst_> BenC: removing and reinserting (using your command) give me some output, but I don't really know whether any of it is useful or not 
<mst_> output in dmesg that is
<mst_> no cdrom in either case though 
<mst_> is there a way of forcing the kernel to probe more deeply, equiv. to hdX=cdrom? like scd0=cdrom? 
<BenC> Not that I'm aware of
<BenC> it's probing, just not seeing anything
<BenC> What I'm concerned about is what's the difference between the livecd boot and the installed system...they should be identical
<BUGabundo> hi there
<BUGabundo> ï»¿I'm having trouble with linux-restricted-modules-2.6.24-19-generic
<BUGabundo> ï»¿getting this /var/lib/dpkg/info/linux-restricted-modules-2.6.24-19-generic.postinst: 7: lrm-manager: not found
<mst_> BenC: So what's the next step? And, I know there is a boot parameter to tell the scsi system to probe more deeply for devices on a scsi channel... you think that might help? 
<mst_> BenC: I'm going to try adding sr_mod to /etc/initramfs-tools/modules and hope that it does something different... I figure as long I i'm trying something I'm moving in some direction. Thanks for all the help though! 
<Kano> anybody interested in a live cd 2.6.26 with auto installer of nvidia 177.13 and fglrx 8-6? (ubuntu config -xen +highmem64g)
<Kano> it seems you are unable to produce a intrepid live cd ;)
<infinity> kees: Yes?
<kees> infinity: oh, meant the other one, but this works
<kees> Rejected:
<kees> avm-fritz-firmware_2.6.20.17.29_amd64.deb control file lists section as main/restricted but changes file has main/misc.
<kees> avm-fritz-firmware_2.6.20.17.29_i386.deb control file lists section as main/restricted but changes file has main/misc.
<kees> the "old" problem was that the Section was wrong in the debian/control file
<kees> that was fixed -- all releases now match:
<kees> Package: avm-fritz-firmware
<kees> Architecture: i386 amd64
<kees> Section: restricted/misc
<infinity> main/restricted?  Ouch.
<infinity> That's busticated.
<kees> I'm a bit at a loss for what's going on here
<infinity> Looks like a broken debian/control to me....
<infinity> kees: Where can I snag this source?
<kees> infinity: dak?
<infinity> kees: Mmkay.
<rtg> kees: will it still be there if its been rejected?
 * infinity goes to find it.
<kees> rtg: it got rejected by soyuz, so it's still in dak
<infinity> rtg: The source will be there regardless.
<infinity> La, la, la... Bandwidth, FTL.
<kees> infinity: isn't "restricted/misc" valid?
<infinity> kees: Should be.
<cjwatson> main/restricted sounds like somebody did "Section: restricted"
<kees> cjwatson: right, that's the old hiccup
<kees> and the warning I saw was:
<kees> 2008-06-19 17:55:39 WARNING Unable to grok section 'restricted', overriding it  
<infinity> No, that's the current hiccup.
<kees> with misc                                                                       
<kees> 2008-06-19 17:55:39 WARNING Unable to grok section 'restricted', overriding it  
<kees> with misc                                                                       
<kees> which matches the same problem.
<infinity> adconrad@lucifer:~/linux-meta$ dpkg-deb -I avm-fritz-firmware_2.6.20.17.29_amd64.deb | grep "^ Section"
<infinity>  Section: restricted
<cjwatson> debian/control.in.autogenerated.noreally?
<infinity> It needs to be "Section: restricted/misc"
<kees> linux-meta-2.6.20.17.29$ grep fritz -A2 debian/control
<kees> Package: avm-fritz-firmware
<kees> Architecture: i386 amd64
<kees> Section: restricted/misc
<infinity> debian/control is autogenerated.
<infinity> Is it not?
<rtg> infinity: I see it, in control.common
<kees> gah, control.common
<rtg> should be 'Section: main/restricted' ?
<infinity> No!
<kees> restricted/misc
<infinity> Should be "Section: restricted/misc"
<rtg> ok
<cjwatson> main/restricted is Soyuz "helpfully" expanding what it thinks Section: restricted means for you
<cjwatson> the main effect of this is to make it more obvious that it's a mistake, because it looks weird :)
<cjwatson> (actually it's more likely just an internal normalised form rather than intentional helpfulness or otherwise)
<alex_joni> what's Soyuz?
<BenC> and evil robot that controls everything
<cjwatson> alex_joni: the archive management component of Launchpad
<alex_joni> cjwatson: ah, ok.. thanks
<BenC> what cjwatson said is more PC I guess
<alex_joni> PC = polite .. ?
<alex_joni> politically correct?
<infinity> That.
<kees> alex_joni: "politically correct" which is the PC term for polite.  ;)
<BenC> that one
<alex_joni> ah right.. that one ;)
<infinity> cjwatson: Anything without an explicit component is shoved into main, so "main/restricted" is certainly the "correct" way to interpret "Section: restricted"
<cjwatson> indeed
<infinity> (This is true of Debian too, for that matter, Debian/dak just won't reject for such an error, since it completely ignores a package's control field anyway, once overrides are in place)
<infinity> s/control field/Section control field/
<cjwatson> BenC: linux-crashdump-{generic,server} targeted at main or universe?
<kees> rtg: are you re-uploading with the fix, or do you want me to poke it?
<rtg> kees: just did it. linux-meta_2.6.20.17.30
 * kees hugs rtg 
<mst_> BenC: Alright... so i've been trying more stuff, and according to the libata FAQ there are detection problems with intel IDE mode drives (what I've got i'm sure), they suggest to play with force_pcs in ata_piix but modifno ata_piix doesn't have it listed as a param? 
<mst_> BenC: shouldn't that men i cant call it at boot time? 
<BenC> mst_: you're looking at old documentation
<BenC> mst_: there's something more basic going on here...if it works in livecd, it should work on normal system, and the only reason for it not to is an ordering or race problem
<BenC> brb, I need to force panic my machine for fun and profit
<hwilde> when I run "top" what is meant by "buffers" in the memory display?
<hwilde> Mem: 507664k total, 475780k used, 31884k free, 92116k buffers 
#ubuntu-kernel 2008-06-20
<jdub> anyone working on the kernel freeze (possibly related to wireless) issue with hardy? i have a useful petri dish of varying hardware presenting the symptom.
<lifeless> jdub: -19 ?
<jdub> yeah
<rtg> cking: you around? Can you comment on bug #153702 since you have one of the affected machines?
<cking> rtg: will do.
<cking> rtg: I did the same workaround ida_generic_ide for #153702 - is this classed as a legitimate fix or is this a call for more investigation for a better solution?
<rtg> cking: Amit was curious what the parameter actually does. Is there a downside to it?
<cking> rtg: These I don't know - I will investigate and comment.
<mjg59> Yes, it means that you're driving it as a generic ATA device
<cking> mjg59: which could imply some performance hit?  My experience with this hardware is that it can move data to/from the disc reliably and fairly fast
<mjg59> Yes, performance hit and reduced functionality
<mjg59> What does lspci -n give you when booted with the bios in ide mode?
<rtg> mjg59: my fuzzy notion of what that means is that in IDE mode it does not participate in SATA topology discovery, link state, and other stuff. 
<mjg59> It's probably less of an issue with the chipset in IDE mode to begin with
<mjg59> Since ata_piix provides a smaller set of features to begin with
<mjg59> You're probably limited to the timings set up by the BIOS, though
<mjg59> I'd be interested to know which driver is binding to the chipset
<rtg> cking: ^^
<cking> mjg59: 00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
<mjg59> cking: Can I have lspci -n as well?
<cking> mjg59: I mail you 
<rtg> cking: I have the same Inspiron 530, but it shows a different controller: 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02), 00:1f.2 0104: 8086:2822 (rev 02)
<rtg> Perhaps thats why I've not seen this issue.
<mjg59> rtg: Yeah, that'll happen if you boot in RAID mode
<mjg59> If you flick the switch in the BIOS it should be identical to Colin's
<rtg> but the bug report is about _not_ being able to sense the drives in non-RAID mode, but I know this one works both ways.
<cking> rtg: I need 5 mins to get a monitor added to the server - it's remotely located at the moment.
<cking> rtg: "works" meaning "does not need the all_generic_ide" boot option?
<rtg> cking: right. I'm cranking up my laptop cause this session is on the Dell 530 (which will go away when I start messing with BIOS options)
<cking> rtg_: IDE mode definitely requires the all_generic_ide option, where as RAID does not
<rtg_> cking: switching mine between RAID/IDE seems to have trashed the MBR. Now it can;t find a boot device in either mode. shit, that is my dev box.
<cking> as for performance, some quick dd tests show: write: IDE 51.1 MB/s, RAID: 51.4 MB/s,  read: IDE 65.0 MB/s RAID: 64.5 MB/s
<cking> rtg_: not good.
<cking> rtg_: so there is little difference between RAID and IDE modes - apart from crapping up your system in the process of testing
<rtg_> cking: indeed. please add that to the bug report :)
<cking> will do
<cking> rtg_: hope you get your dev box sorted asap
<rtg_> cking: thats just great. all of the ISO's for Hardy on the drives I can't get to. 60 minutes to download...
<cking> rtg_: 60 minutes - that's lame speed
<rtg> cking: stupid BIOS. some futzing around restored the boot.
<cking> rtg: it's kinda worrying that a BIOS can be so flakey
<rtg> cking: I could boot if I chose F12 and went through the boot menu. I ended up having to change boot device  priority settings
<rtg> smb_tp: are you taking care of adding the HVR950Q driver for LUM ?
<smb_tp> rtg: yes
<smb_tp> rtg: I opened bug 231628 for tracking
<smb_tp> bug 241628
<mkrufky> thanks for that :-)
<rtg> smb_tp: thanks. I'm just going through the kernel team mailing list requests to make sure I don't forget something.
<smb_tp> rtg: Np, I am also on the AC-BAT stuff from Yong
<rtg> smb_tp: great, thanks.
<mkrufky> there was another driver to be added also -- i sent it to mike frey and asked him if i should also send to kernel-team ... he said he'd just commit it and ask you guys to pull ...  but if you want to take a look, it is at: http://linuxtv.org/~mkrufky/lum/add-sms1xxx-to-lum.patch
<rtg> mkrufky: is it of general use to the distro kernel? Or just MID style devioces?
<mkrufky> general use
<smb_tp> mkrufky: at the moment it would be better to post on the list. just to have a better reminder
<mkrufky> ok, no prob
<rtg> mkrufky: if these drivers are not already in 2.6.26 you should hassle BenC to put them in the Intrepid package.
<smb_tp> rtg: I just pushed the changes for bug241229 but since the nomination seems to be pending I am not sure where to place the progress 
<mkrufky> rtg they are not in 2.6.26 ....  the hvr950q driver *is* in 2.6.26, but its missing some usb ids and some performance tweaks
<rtg> smb_tp: mark it "Fix committed", subscribe ubuntu-sru, nominate it for Hardy, and write up the SRU justification in a comment.
<mkrufky> rtg: when it comes to intrepid, i think it would be easier for me to send in patches against upstream to sync intrepid kernel -- is that cool?
<mkrufky> er, came out wrong... ie:  the hvr950q fixes for intrepid would be easier for me if i could just patch the kernel, rather than LUM
<rtg> mkrufky: you're too late for that. 2.6.26 is the kernel Intrepid will settle on. right now you'll be pressed to get your drivers into 2.6.27.
<mkrufky> ok, no prob
<mkrufky> i'll get them into 2.6.27.  and i can probably get the performance tweaks and usb vid:pid updates into 2.6.26.y -stable
<rtg> mkrufky: as for patching the kernel, we prefer to keep the kernel as close to upstream as possible. wholesale changes (like new drivers) are going into a different directory. 
<BenC> mkrufky: If you are adding drivers to intrepid, we don't want them in the same place as upstream would have them
<BenC> mkrufky: we'll have them in the ubuntu/ subdirectory
<rtg> mkrufky: for Intrepid, the ubuntu/ subdirectory is the equivalent of Hardy LUM.
<mkrufky> to clarify:
<mkrufky> in 2.6.26, the au0828 xc5000 and au8522 drivers are already merged
<mkrufky> but, the 2.6.26 versions are missing some patches, such as usb id's and some small performance tweaks
<mkrufky> so, i will try to get those into 2.6.26.y -stable ... if that doesnt work out, then we'll have to do LUM ....  however, LUM poses a problem in this case, since 2.6.26 has OTHER drivers that also depend on xc5000.ko
<mkrufky> we'll have linking problems if we provide a new xc5000.ko
<rtg> mkrufky: patching an existing driver is much less of an issue.
<mkrufky> ....and ^^ that is what i meant. 
<mkrufky> :-)  ok, cool then
<mkrufky> sms1xxx patch email sent
<BenC> mkrufky: patching an existing driver should be limited though...large amounts of patching would mean instead, putting the patched driver in ubuntu/ and disabling the in-kernel one
<mkrufky> BenC: so far the delta is very small
<rtg> mkrufky: perf tweaks and PCI ID updates should be OK.
<mkrufky> BenC: if it gets larger, we can move the au8522 / au0828 to ubuntu/  but we cant do that to xc5000 in intrepid.  actually, right now the xc5000 sumbitted for LUM is identical to upstream, but I plan to rev it over the weekend with some power management fixes.  
<mkrufky> ...and it will probably be about a week or so before I submit those patches -- the power management stuff will need good testing here first before i submit anywhere :-)
<BenC> cjwatson: were you able to look at makedumpfile? I need it in main because linux-meta deps on it, and I'll also need it as a build-dep for linux
<cjwatson> BenC: I'll have to do a main inclusion review on the spot for it - need to take Benedict over to his dad's now though
<BenC> cjwatson: ok, no rush, since this is all post-alpha-1
<BenC> yet another time I wish dpkg diversions supported directories
<rtg> BenC: would your fix your permissions in /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-dapper.git ?
<rtg> the usual BS
<BenC> rtg: done
<rtg> BenC: thanks. dapper abi's pushed
<BenC> rtg: maybe a good idea to copy that pre-receive hook to the rest of our trees
<BenC> it's in ubuntu-intrepid.git/hooks/
<rtg> BenC: yep 
<rtg> BenC: I'll do it as long as I'm messing with the ABI uploads.
<lamont> dear linux-meta.  why does ppc not get linux-image-server love?
<lamont> :-)
<rtg> BenC: and again for /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-gutsy.git
 * lamont grumbles at bug 241726
<lamont> full dmesg output is at davis:~lamont/dmesg
<rtg> lamont: what's a windfarm?
<elmo> rtg: the thermal/fan subsystem for Xserves
<elmo> at least in the powerpc era - I don't know if the Xeon based ones still use it 
<rtg> elmo: yeah, I figured it out as soon as I looked at dmesg
<rtg> elmo, lamont: looks like it might be a macintosh specific driver.
<elmo> it is
<rtg> elmo: which might be incompatible with powerpc64-smp ?
<elmo> rtg: nope
<elmo> rtg: or, rather, it use to work
<elmo> in dapper + edgy
<rtg> elmo: I'm checking. I seem to remember some issues with smp-64
<mjg59> It's used in the G5s, as well
<mjg59> It's certainly meant to be SMP-compatible
<rtg> mjg59: right - I'm looking at moduels.dep. It looks like its not loading one of the sensor modules correctly, e.g., PM81, PM91, or PM112.
<rtg> which would pull in windfarm_core
<rtg> elmo: do you know which of those sensor modules davis is supposed to use?
<elmo> therm_pm72
<elmo> I guess
<elmo> http://paste.ubuntu.com/21645/
<elmo> ^-- same machine, running dapper
<rtg> elmo: well davis has therm_pm72 as well
<elmo> yeah
<elmo> I've no idea if the output is a problem or not, it just stood out
<rtg> elmo: hmm, there is also no winfoarm module installed on ross.
<elmo> hmm
<elmo> the temperature sensors also claim the cpu is running at 11 degrees
<elmo> which seems unlikely
<mjg59> My recollection is that the fans will run full-on without windfarm loaded
<elmo> that sounds entirely plausible
<elmo> 'cos those xserves are probably the loudest piece of equipment we have
<mjg59> And beahve more sanely if it is
<elmo> fwiw
<elmo> http://paste.ubuntu.com/21648/
<elmo> I was able to modprobe those on ross
<rtg> elmo, mjg59: here's the deal. therm_pm72 is adding i2c drivers at load time, but none of the i2c drivers seem to depend on windfarm_core (which has the missing symbols wf_register_control, etc);
<elmo> whether or not they actually helped with the fans is harder to tell
<elmo> the others said 'ha ha no such hardware'
<rtg> elmo: can you try 'modprobe -r therm_pm72; modprobe windfarm_core; modprobe therm_pm72'
<elmo> on davis?
<rtg> elmo: sure
<elmo> FATAL: Error inserting windfarm_core (/lib/modules/2.6.24-19-powerpc64-smp/kernel/drivers/macintosh/windfarm_core.ko): No such device
<rtg> elmo: but no missing symbols. It just couldn't find the i2c device that it liked.
<elmo> rtg: it could on ross though
<rtg> elmo: lemme figure out what windfarm_core is bitching about.
<elmo> k
<elmo> it's not super important btw, I'm pretty sure it's not melting the hw
<rtg> elomo: how about this comment in windfarm_core: '/* Don't register on old machines that use therm_pm72 for now */'
<elmo> and if it did; I'm definitely not sure if I'd care ;-)
<elmo> rtg: hmm, could be I guess
<elmo> benh would know for sure
<rtg> you mean BenC ?
<elmo> no, benh
<rtg> don't know him
<elmo> Benjamin Herrenschmidt 
<rtg> oh, he the author :)
<rtg> elmo: so aside from the annoyance in dmesg, it looks like the default is OK since the fans come on full?
<elmo> rtg: assuming they are on full yes
<elmo> rtg: but I can't easily tell that from here.  but I'll let you know if the machine explodes over the weekend ;-)
<rtg> elmo: no problem, then I'm back to what I was doing.
<BenC> rtg: You've done this before...how do you upload to a ppa?
<rtg> I use dput with a .dput.cf file
<BenC> what's the stanza in  your .dupt.cf?
<rtg> [my-ppa]
<rtg> fqdn = ppa.launchpad.net
<rtg> method = ftp
<rtg> incoming = ~timg-tpi/ubuntu/
<rtg> login = anonymous
<rtg> allow_unsigned_uploads = 0
<BenC> rtg: thanks
<ChickenCutlass> rtg: were you able to find the DVB driver commit in the netbook tree?
<rtg> ChickenCutlass: after some pain, yes. I just pushed it to the LUM repo.
<ChickenCutlass> rtg: sorry -- did I not do the commit correctly
<rtg> ChickenCutlass: who is to say, I'm not really a git expert. Was origin/abi-18 a branch name?
<ChickenCutlass> rtg: yes
<rtg> ChickenCutlass: I kind of fumbled my way through it.
<ChickenCutlass> rtg: I typically create a new branch based on an ubuntu kernel tag then make my changes
<rtg> ChickenCutlass: exposing the SHA1 commit ID so I could cherry-pick was the hard part. I couldn't seem to get that syntax right.
<ChickenCutlass> rtg: ah ok
<rtg> ChickenCutlass: I finally had to create a branch in my local tree with the same name, fetch from the remote, cherry-pick, switch back to master, then rebase against abi-18
<ChickenCutlass> rtg: ugly
<rtg> ChickenCutlass: it seems that a lot of git stuff is done the ugly way :)
<ChickenCutlass> rtg: right -- only the strong survive
 * BenC stares in wonder at the ppa
<BenC> You guys are gonna love this shit
 * BenC implemented a last-good-boot infrastructure so you will always have a safe kernel to boot into
<rtg> never again will I boot to a blank screen?
<BenC> rtg: well, never again will you upgrade to a new kernel, and not have a known good one to reboot to if that one fails
<BenC> e.g. if you have only one kernel installed, and you upgrade to a same ABI kernel...you still have one kernel, and it might not boot
<BenC> this mechanism will make sure that doesn't happen
<rtg> BenC: does the user have to make a grub choice? 
<BenC> I'm not sure it can guarantee that things like same-upgrade nvidia breakage wont keep it broken (e.g. userspace libraries mixed with wrong version of kernel modules)
<BenC> rtg: For now, yes...but I'm hoping to add some magic to detect a failed boot, boot to last-good, and pop up something on the desktop saying "Blah blah, you failed last time, you are in a safe mode now"
<BenC> but with something better than "safe mode" to call it
<rtg> BenC: won't that depend on being able to mount a file system?
<BenC> what do you mean?
<rtg> I was just thinking about the detection for a failed boot.
<BenC> well, it will require at least mucking with a boot record for grub to notice it
<BenC> I'm not sure how it will come together, but I'm going on the assumption that I can make it work
<rtg> isn't Colin training to be a grub expert?
<BenC> for now, just the ability to keep a last booted kernel around is golden
<BenC> rtg: yeah, this may be a good task for him
<BenC> Anyone want to add: "deb http://ppa.launchpad.net/ben-collins/ubuntu intrepid main" to their apt sources.list, install and let me know if it works for them
<BenC> I've only tested on one machine :)
<BenC> you will have to do a reboot to get the first last-good-boot setup, but then it should work after that
<BenC> unfortunately, grub fails to build on amd64, so it will only work for i386 for now
<BenC> pgraner: ping
<munckfish> BenC: I'm running the misc/getabis script in the ports source. It's failing. I've updated it so it builds the correct URL (was using 'linux' instead of 'linux-ports')
<munckfish> BenC: but now I notice there are no linux-image-* packages in their for the 1.2 upload
<munckfish> there are kernel-image-*di*
<munckfish> Any idea what's wrong there?
<munckfish> BenC: this is my patch for it so far http://paste.ubuntu.com/21667/
<munckfish> here's where I'm hoping it'll find em http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ports/
<BenC> munckfish: are you looking on ports.ubuntu.com?
<munckfish> yes
<munckfish> see url above
<BenC> munckfish: hmm...for some reason, someone put them in universe
<BenC> which makes zero sense
<BenC> http://ports.ubuntu.com/pool/universe/l/linux-ports/
<munckfish> hmmm
<munckfish> https://launchpad.net/ubuntu/intrepid/powerpc/linux-image-2.6.25-1-powerpc64-smp/2.6.25-1.2
<munckfish> yep it says universe there
<munckfish> weird
<munckfish> :S
<munckfish> oh, or is that a sarcastic way of saying that's deliberate?
<trainpic> I have a question about madwifi drivers
<trainpic> I was under the impression that they are included in restricted-modules, but someone told me that they aren't included at all
<trainpic> I'm fairly sure they are, and I'm sure someone here knows
<rtg> trainpic: they are in LRM as of feisty.
<trainpic> If they are, when will the latest version be in?
<trainpic> OK
<munckfish> BenC: so shall I just update the getabis script to look there as well as the other 3 urls it already does? Cause I presume they aren't going to move now.
<trainpic> When will the version with support for the AR242x be in?
<trainpic> I have to manually compile it for each kernel
<rtg> trainpic: have the madwifi folks released a mainstream version that supports it?
<trainpic> Yes, that is what I downloaded and compiled.
<trainpic> I'm not sure what version it is, and madwifi.org is having problems right now
<rtg> if I remember correctly, the last version was 0.9.4
<rtg> what have you built?
<trainpic> The version in Ubuntu supports the chipset under 32bit, but I run 64bit and need the latest
<trainpic> let me check
<munckfish> BenC: I've just realised I don't actually know how to specify whether something should go into universe or main. I presume it's about which ftp site the package source is uploaded to.
<munckfish> BenC: if so, how can half of the packages from the same source end up in the wrong section
 * munckfish is utterly confused :S
<rtg> munckfish: each package is defined in debian/control under its own 'Section:'
<trainpic> I think it was 0.9.4
<trainpic> Whatever it was had AR242x support under 64bit, and was mainstream
<trainpic> I would check the website but it isn't responding
<munckfish> rtg: yep, says 'devel', or 'base' etc
<munckfish> rtg: but not 'main' or 'universe'
<rtg> trainpic: 0.9.4 is what is in LRM.
<trainpic> Hm... maybe it wasn't mainstream yet then. Again, wish the site was up so I could be sure. I know for a fact that what's in LRM doesn't support the AR242x under 64bit :-(
<rtg> munckfish: thats the root of your problem. I'd help, but I'm late already. gotta go.
<munckfish> rtg: ok np c ya
<pgraner> BenC: pong
<munckfish> BenC: patched to look in that location too now (http://paste.ubuntu.com/21674/)
<munckfish> I'll send this into the mailing list if you like
#ubuntu-kernel 2008-06-21
<mkrufky> is there a trick to cloning a git tree from kernel.ubuntu.com onto kernel.org?
<mkrufky> error: The requested URL returned error: 403
<mkrufky> warning: remote HEAD refers to nonexistent ref, unable to checkout.
<mkrufky> hmm, i think i just fiugured it out :-P
<mkrufky> hehe ok i got it 8-)
<bullgard4> "~$ uname -r; 2.6.24-19-generic" Is the '-19' suffix a number issued by Ubuntu only, or can -19 also be found in Debian?
<crimsun_> bullgard4: see https://wiki.ubuntu.com/KernelMaintenance#head-1ef412dd0059f9680eb3af6bfe2fd3a5188020c4 for an explanation of ABI.  Debian uses something similar.
<BenC> anyone know a reason why we shouldn't be using uvesafb?
<BenC> other than we don't have v86d, but I have that packaged now...just wondering if it will get us better console with usplash and such
<BenC> bullgard4: short answer is, Debian and Ubuntu's kernels are nothing alike and not based on each other
<bullgard4> crimsun_, BenC: Thank you very much for explaining.  
<crimsun_> BenC: BTW, can you revert the change in 1.0.16-1.1ubuntu2/intrepid, please?
<crimsun_> (I attempted to explain a few days ago that maks_'s patch was already applied in 1.0.16-1.1ubuntu1.)
<BenC> crimsun_: initramfs-tools?
<crimsun_> BenC: sorry, no.  alsa-driver 1.0.16-1.1ubuntu2/intrepid.
<BenC> crimsun_: the change I made?
<BenC> weird, I didn't see it in there
<crimsun_> yes, it's in debian/rules.
<crimsun_> also, from 1.0.16-1.1ubuntu1's changelog: + SVN r2069 to prevent snd-pcsp from loading as default.
<crimsun_> I would have done so, but I'm no longer in the upload group.
<crimsun_> (and, thanks!)
<bullgard4> 2.6.22-4-generic
<wgrant> Any timeline for 2.6.26 LUM appearing?
<Kano> hi BenC , could you update to rc7?
<tseliot> Kano: I got the driver to build. This doesn't mean that it works. I'll let you know after I do some testing
<tseliot> Kano: the driver works now. The solution is in the mailing list
<tseliot> kernel mailing list
<Kano> url
<Kano> does it work for all 4 drivers?
<tseliot> Kano: can I send you a copy of my email? ï»¿realKano at directbox.com , right?
<Kano> yes
<tseliot> ok
<Kano> as soon as somebody updates the kernel to rc7 i will check it out again
<tseliot> Kano: email sent. I'm using 2.6.26-2-generic
<Kano> ok
<tseliot> it's a rather stupid hack, BTW
<tseliot> ;)
<tseliot> problem solved
<Kano> tseliot: there is no patch?
<tseliot> no, using sed will be enough
<Kano> ah you just exchanged the 2 words
<tseliot> just replace XEN_CONFIG with ALB_CONFIG in nv.c and nv-linux.h
<tseliot> yes, it did the trick
<Kano> interesting
<tseliot> this doesn't solve the problem with realtime kernels though
<tseliot> I'll fix that too
<Kano> good
<Kano> i currently did not test rt,but if you know how i can adopt it
<tseliot> I'll let you know as soon as I fix it
<Kano> did you read that 2.6.26rc7 has the needed ati drm changes for 3d with up to r500?
<Kano> tseliot: was your hack needed in addition to the already known xen patch for 2.6.24+?
<tseliot> ï»¿Kano: I kept that patch
<Kano> i guessed so
<tseliot> I haven't tried to build without it
 * tseliot > launch
<Kano> didyou try 71.84 + 96.43 too?
<tseliot> ï»¿Kano: not yet, let me try it now
<Kano> for 7184 i made my own patch, 9643 i took from a gentoo bug report
<tseliot> I'll see if they build in my Intrepid in Virtualbox since I would rather not touch my current system right now
<tseliot> if they build then the hack works
<tseliot> Kano: 9643 and 7186 fail here
<tseliot> can you give me the patches, please?
<BenC> mjg59: ping
<afflux> morning. I read about some splitting up of the nvidia/fglrx drivers from LRM on the UDS summary, but I couldn't find out where I can find them now. Any hints?
<BenC> afflux: there's an email about wip packages on the kernel-team mailing list
<BenC> sounds like they'll be ready and in the archive soon
<afflux> ah okay
<afflux> thanks for the hint
<Rabiddog> possible kernel bug, not sure https://bugs.launchpad.net/ubuntu/+bug/241983
#ubuntu-kernel 2008-06-22
<ir8> Hello all I have a few questions about driver support./
<ir8> anyone around ?
<Q-FUNK> http://launchpadlibrarian.net/15434295/00001.jpg
<Q-FUNK> I started getting this since upgrading to Hardy, on one particular piece of hardware.
<Q-FUNK> related to bug #241307 on LP
<Q-FUNK> I have no idea how to decode that ksoops message or how to solve it.
<Q-FUNK> would anybody know?
<mjg59> Q-FUNK: Having the previous lines would help a great deal
<mjg59> But I'd guess bad hardware
<Q-FUNK> mjg59: I doubt that. reverting to the gutsy kernel fixes it.
<mjg59> Hm
<mjg59> Well, it really needs more of the backtrace
<Q-FUNK> mjg59: I welcome instructions on how to get that
<Q-FUNK> right now, the hardware freezes right at that point.
<mjg59> Boot in a higher resolution?
<Q-FUNK> hm. that, I can try. just a sec.
<Q-FUNK> mjg59: no can do, it seems.  this doesn't have a normal bios. it boots in plain VGA by defualt.
<mjg59> Pass vga= to the kernel?
<Q-FUNK> it seems thta it oopses before it gets around parsing that
<Q-FUNK> the only bit that remains understandable to me is that it's preciselt related to boot options.
<mjg59> If it oopsed before it got that far you wouldn't get an oops
<Q-FUNK> hm
<Q-FUNK> it says something there about some unknown boot option.  what is it?
<mjg59> Nothing
<mjg59> It just usually ends up at the bottom of a backtrace
<JanC> can't you use a serial link to debug such things (to get all the messages)?
<Q-FUNK> no serial port here
<pottytheshitter> I ask that the kernel devs add ext4 for intrepid
<kernelmode> wow lazy kernel devolpers
<JanC> hint: like most other people the kernel developers are not paid to work during the weekend
<JanC> and ext4 is still experimental & considered unstable AFAIK
<kernelmode> so other big distros include it
<JanC> that's their responsibility
<kernelmode> Guess what if you ubuntu-devs consider ext4 unstable you should really remove reiserfs 
<JanC> I think Ubuntu doesn't want to take the risk that people who don't know that it is still unstable loose data after an upgrade...
<JanC> reiserfs has a stable on-disk format, I think ext4 doesn't have that yet?
<kernelmode> ahh i see the kernel devs dont want to make there kernel version even more unstable
<ubuntufails> see even the lazy kernel devs are to lazy to admit it
#ubuntu-kernel 2009-06-15
<zeroprog> hey guys im havin a little trouble learning make files http://codepad.org/Uqn2MCyY....my driver source is in /home/name/Desktop/misc-drivers
<zeroprog> http://codepad.org/Uqn2MCyY sorry (...)
<zeroprog> now i keep getting invalid format for hello.ko
<btQuark> hello everyone
<btQuark> i've just tried this one successfully - after quite some time http://www.jan-steinhoff.de/linux/synaptics-usb.html what about bringing that into the kernel -the author obviously at it
<Ng> how would I want to go about interpreting the battery consumption part of the checkbox suspend tests? I suppose I should really only use it to compare against results from different kernels on the same machine?
<apw> Ng, yeah its a very subjective measure
<apw> my feeling is it should be considered only as an indication of maximum suspend time, and if its less than a day or two its fail
<apw> before some fixes i had a like 8 hour suspend time, which was definatly wrong
<Ng> bah, that means I need to put jaunty back on the machine to get a baseline to support my gut feeling that suspend time has nosedived ;(
<Ng> I also need to file a bug somewhere, some of the automated resumes didn't... resume. The LEDs changed, but I had to poke the power button
 * popey filed bug 387272 but isn't sure it's a kernel bug or a desktop bug, feedback welcome
<ubot3> Malone bug 387272 in linux "[karmic] long boot time on eee 900" [Undecided,New] https://launchpad.net/bugs/387272
<rtg> cjwatson: do you have a cross compile environment for karmic ARM? Your patch series for udeb firmware isn't quite right for ARM (and probably other CPU arches without firmware)
<cjwatson> rtg: nope
<cjwatson> rtg: what's wrong with it?
<rtg> cjwatson: it tries to copy a firmware directory that doesn't exist. I'll see if I can fix it later today
<cjwatson> is it a bug in linux/debian/rules* or in kernel-wedge/commands/copy-firmware?
<cjwatson>         cp debian/d-i/firmware/* $(builddir)/firmware/$(arch)/
<rtg> cjwatson: linux/debian/rules
<cjwatson> oh, is it that?
<rtg> cjwatson: I think so, it was last Friday that I was messing with it
<cjwatson> no, that can't be right, that directory does exist
<cjwatson> if you can show me the error message I'll be happy to fix it
<rtg> cjwatson: I'll get to it later today.
<cjwatson> ok
<apw> cjwatson, could there be no files in there though?
<apw> then it could try and copy a file called '*'
<apw> maybe some incantation of cp -r debian/b-i/firmware/ is more appropriate
<rtg> apw: thats exactly what is happening. I can repro the problem quite easily, so I ought to be able to fix it justr as soon as I clear up soem other issues.
<apw> rtg ack
<cjwatson> rtg: did you apply all my patches? one of them creates a file in that very directory
<cjwatson> so I don't see how it would be possible for that to be empty
<cjwatson> it's not dynamic or anything, it's just a source directory
<cjwatson> i.e. in my branch, there exists a file debian/d-i/firmware/nic-modules
<rtg> cjwatson: yes, I applied all of the patches. However, I prefer patches that are bisectable so I may collapse the last 2 (once I figure out why they don't work for ARM)
<cjwatson> fine by me, perhaps I should have committed them in the opposite order
<apw> Keybuk, hey ... did you get to any testing on union mounty stuff 
<Kano> hi apw ,do you want to add headers to make external dvb modules compile
<apw> which ones are missing
<Kano> cp -a drivers/ieee1394/*.h $(indep_hdrdir)/drivers/ieee1394
<Kano> and for fglrx it would not hurt to add
<Kano> cp -a drivers/acpi/acpica/*.h $(indep_hdrdir)/drivers/acpi/acpica
<Keybuk> apw: not yet, was off on Friday
<apw> Keybuk, heh no worrie
<Kano> apw: firedtv will not compile without
<Kano> i have got a test script for dkms
<Kano> http://kanotix.com/files/fix/dkms/dvb-s2api-liplianin-dkms.sh
<Kano> that compiles all dvb drivers + some additional dvb-s2 drivers
<Kano> the same script can be used to update gspca drivers too, just a small change
<apw> Kano, that first one seems like a reasonable request, so get that into a bug... will think about the other
<apw> let me know the number so
<Kano> for the other you need an extra export too
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-export-flush_tlb_page.patch
<Kano> with both things my fglrx script works with 2.6.30
<Kano> with a relatively small patch
<Kano> when you dont copy the headers the patch has to contain em, thats not really useful
<Kano> btw. i have have got a verified patch for avm draft-n usb sticks, will be most likely in 2.6.31 too
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-ar9170-support-1-stage-firmare+avm-fritz.patch
<Kano> you only need the firmware
<Kano> apw: why dont you set CONFIG_HAVE_KERNEL_LZMA=y 
<Kano> that compresses the vmlinuz with lzma
<apw> you mean CONFIG_KERNEL_LZMA ... and that is not guarenteed to be a good thing
<apw> the kernel is smaller, but slower to extract from the compressed form
<Kano> it is 100% a good thing
<apw> there is a trade off there dependant on disk and cpu performance characteristics
<Kano> decompress is always fast
<apw> its 2x the CPU time to decompress over the default compression
<apw> as reported by a number of sources
<Kano> which means in seconds
<Kano> .5s longer or what
<apw> which mean double the decompress time 
<apw> which with a boot budget of 10s could make a difference
<apw> t
<apw> the point is that its not a slam dunk to change, as its a trade offf which needs measuring
<Kano> the load time to load the kernel is shorter
<Kano> so you win
<mjg59> I'd be amazed if the difference in size makes up for the difference in compression
<apw> the laod time is shorter yes, but on a netbook where the cpu is poor and the disk is ssd
<Kano> for live images you gain 5 mb when you compress kernel+initrd with lzma
<apw> is it going to be faster
<apw> most of that presumably comes from compressing the initrd with it
<Kano> i dont have got a netbook
<apw> Kano, and how does that affect my decision?
<Kano> apw: well when you dont change it, i change it
<apw> then you are happy, and i am happy. win
<Kano> it is just a patch i want to get rid of
<cjwatson> Kano: FWIW our live images only contain the kernel and initrd once, not twice as I saw you saying the other day
<apw> cjwatson, it does beg the question if we could use lzma for the initrd on the CD images as they are one time build compress time wise
<Kano> cjwatson: you forget the compressed filesystem!
<apw> if the kernel understands both of course
<cjwatson> if it works, I expect we could; speed is not so critical there
<cjwatson> Kano: no, I don't.
<Kano> the only way to get rid of storing it twice would be using for example grub2 as bootloader with a squashfs support module that would fetch the file from the squashfs
<cjwatson> Kano: false
<cjwatson> Kano: by demonstration, in the last several releases of Ubuntu :-)
<Kano> you have got no /boot/vmlinuz-... in squashfs?
<cjwatson> Kano: that's correct
<cjwatson> Kano: the installer knows to copy it from the ISO9660 filesystem rather than from the squashfs
<Kano> then you are forced to boot with iso-scan to isntall
<cjwatson> no you aren't, we use ubiquity
<Kano> well when you boot from network
<cjwatson> you can do that with casper/ubiquity too
<cjwatson> (might need some fixes since it's not tried very much, but it's basically possible)
<cjwatson> and I don't see why iso-scan is a problem - you ought to have /cdrom set up properly during installation from local media anyway, several bits of code assume that and may operate a bit weirdly if it isn't there
<Kano> what does happen when you used live-media-path override
<Kano> does your installer support it
<cjwatson> casper does but if you use that ubiquity will probably fail to understand what's going on. I invite anyone who has a problem with this to submit patches :-) shouldn't be hard to fix
<cjwatson> it'd just need to read casper.conf
<cjwatson> (casper does> as of karmic anywya)
<cjwatson> anyway
<cjwatson> Kano: ... indeed, that's simple enough to do that I've just committed support for it
<Kano> do you really need the preseed option in order that your installer works correctly
<cjwatson> huh?
<cjwatson> what preseed option?
<Kano> file=/cdrom/preseed/kubuntu.seed for example
<cjwatson> it has sensible defaults for Ubuntu
<cjwatson> the preseed options arrange for the right packages to be installed appropriate to the flavour you're installing, so that we don't have to ship a separate installer for every flavour
<cjwatson> (we actually do ship a preseed file for Ubuntu too; the main relevant thing it does is to arrange to install the desktop automatically. if you don't use that preseed file then (a) you'll get asked the question on alternate/server CDs (b) it makes no difference on desktop CDs)
<Kano> so bascially it is useless on the desktop ones?
<Kano> when this is the case, why are those files on it then
<cjwatson> Kano: I didn't say that, I said that the bit that arranges to install the desktop automatically makes no difference on desktop CDs
<cjwatson> Kano: though right now it's true that none of the rest of the preseed file is relevant to desktop CDs, only DVDs; but who cares? it's easier to just tell the image building infrastructure to always include it
<cjwatson> premature optimisation => silly
<Kano> well it is at least good to know
<Kano> if i want to test u live i use currently something like
<Kano> http://kanotix.com/files/fix/grub2/config/70_ubuntu_iso
<Kano> did you ever see such a code
<Keybuk> -9 is not a happy kernel for me
<Kano> Keybuk: do you use a dvb-c card
<Keybuk> no
<Kano> whats your problem with it
<Keybuk> hard locks after the screen is switched off
<Kano> intel gfx?
<Keybuk> yes
<awe> sconklin: you have time for a build question?
<Mike-DC> Hi everyone. I'm having trouble recompiling the stock 2.6.28-11-generic kernel in 9.04. Everything compiles fine except for the Ubuntu supplied third-party drivers. I'm rebuilding from the tar.bz2 I retrieved through aptitude. Anyone run into this before and/or have any knowledge in this area?
#ubuntu-kernel 2009-06-16
<zeroprog> hey guys i keep getting invalid module format and ive recompiled the kernel...turned loadable module support on...downloaded a new kernel and tried the same thing but nothing works
<zeroprog> the module is in .ko format
<lifeless> zeroprog: is it for the same arch?
<mjg59> You'll get "invalid module format" if it's built for a different kernel version or configuration
<mjg59> Check dmesg for the actual error
<zeroprog> hello: disagrees about version of symbol struct_module
<zeroprog> and my kernel v is 2.6.28-11 and the kernel source is 2.6.28
<TheMuso> C
<zeroprog> alright on kernel.org they dont have 2.6.28.11 so what linux source can i use 
<apw> Keybuk, i had a conversation with the vfs union mount peeps last night and they sent me a rebase to 2.6.30 with a couple of race fixes, so i've make you a new kernel (again): https://edge.launchpad.net/~apw/+archive/green
<apw> cking, you had a machine (a dell i think) which had a problem with halt and reboot which only exhibited itself when splash was enabled but i think turned out to be like reboot=b was required and we added a quirk, can you remember?
<cking> apw, reboot=b forced it to work OK. Not sure about the quirk being added for the Dell Inspiron 6400 though. I cannot recall that (too much water under the bridge, or old age :-)
<apw> your memory matches mine
<haitao0826> è¯·æå¤§å®¶ä¸ªé®é¢ï¼ç¼è¯åæ ¸ä¹åè¦æä¹éç½®æè½å¨ç¼è¯æ¶æä¸éè¦çä¸è¥¿æé¤
<haitao0826> æä¹æ²¡äººè¯´è¯é¿ï¼
<amitk> haitao0826: The language of this IRC channel is English. I'm afraid most people here don't read Japanese.
<haitao0826> ok,sorry
<haitao0826> bey
<smb> amitk, Its chinese 
<apw> google says it says "Question to ask you, how to compile the kernel before the compile-time configuration in order to rule out things that do not need no one how to speak Albanian?"
<_ruben> all i saw was a bunch of ?'s ;)
<smb> _ruben, Iterestingly we saw the chinese letters, but the translation is still a bit weird :)
<_ruben> true ;)
<amitk> smb: oh well. I thought 'tao' was more Japanese. I need to figure out how to tell Chinese, Korean and Japanese apart
<ikepanhc> eh, just someone speak in chinese?
<cooloney> apw, you are close
<apw> cooloney, google was close :)
<amitk> apw: its quite compact (chinese) to encode all that information in such few 'characters'
<apw> yeah its very compact thats for sure
<xivulon> apw hi, would you have some time to investigate a swapon freeze during ubuntu install?
<xivulon> this happens when a swpa file is created and used within a fat fs
<apw> that sounds like a bad idea :)
<apw> (putting swap in fat)
<apw> do you get any panic output?
<xivulon> the alternative is swap at all
<xivulon> davmor2 has set up a machine with ssh access
<xivulon> one sec
<apw> xivulon, ok, so this swap file is it directly on the fat, or inside your ext4 loopback into a file crack ?
<apw> xivulon, is there a bug filed for this one?  so i have somewhere to record stuff?
<xivulon> directly on fat
<xivulon> I guess 376120 is the same issue
<xivulon> the file is in /host/ubuntu/disks/swap.disk 
<xivulon> where /host is the fat partition
<xivulon> davmor2 should provide you with instructions to ssh in
<apw> thaks
<apw> thanks
<xivulon> there should be a swapon and a couple of mkswap processes (from tests I assume) that cannot be killed 
<apw> xivulon, yeah i think i know waht this might be
<apw> are we sure this bug# 376120 is the same bug or should i make a new one
<apw> and get that one dupped against it should it be the same cause, its not clear from the bug
<xivulon> apw I think it is the same bug, but feel free to open a new one with a more explicit title
<apw> thats ok, if you are pretty sure then i am happy
<apw> xivulon, if i get you a fixed kernel are you able to test it ?
<davmor2> apw: check with xivulon, but as far as I am aware wubi on windows side creates the drives and imports the cd image and then runs an automated install against that image on first run.
<davmor2> if it's a case of following instructions in this current environment I can test it.  But only use little words :D   I'm going to be away for a couple of hours so it would need to be after that, if that is okay
<apw> davmor2, i suspect it is complex as we need to replace the kernel somewhere in here, i'll let xivulon talk to that
<davmor2> apw: np's
<apw> xivulon, ?
<xivulon> hi apw
<apw> xivulon, hi ... i am building you some test kernels with what i believe is the fix for the issue applied
<apw> will let you know when they are built and pushed, and will update the bug also
<xivulon> apw thanks a lot
<apw> i am assuming you will be able to wave your hands over them and see if they fix things
<xivulon> hmm deployment would be complex though, as it will have no effect unless a new ISO is shipped
<xivulon> although users could replace the kernel inside of windows before rebooting
<apw> yeah indeed.  but i am hoping you can at least frig it into a test install
<apw> to at least confirm this is the right fix
<apw> then we can make up some way to handle that
<xivulon> no module/initrd are involved correct?
<xivulon> hmm actually they are I guess
<apw> its actually the fat module which is updated, so yes
<xivulon> well vmlinuz/initrd is still ok
<apw> you build initrds on the machine normally
<xivulon> users can simply drop them into a directory, easy enough
<apw> as in the installation of an updated kernel image builds an initrd them
<apw> then
<xivulon> the initrd must be a live CD one (with casper and lupin-casper)
<apw> hrm, no idea how those get generated
<xivulon> once you have the patch ready I'll see to have one built
<apw> i'll let this test build run and then push up the patch and images, and you can use whichever works best for you :)
<xivulon> apw thanks a lot
<apw> np
<cjwatson> apw: FYI I have cdimage/livecd-rootfs changes now to support using lzma compression for the live CD initramfs, once the next kernel lands; it saves 3MB so seems well worth it
<apw> cjwatson, nice.  the size constraint in that context more than justifies any performance risk
<cjwatson> xivulon: could you make wubi try each of /casper/initrd.gz, /casper/initrd.bz2, and /casper/initrd.lz? I see that it currently hardcodes initrd.gz
<cjwatson> oh, and I'd better fix ubiquity too
 * apw notes cjwatson is making much work for himself
<cjwatson> oh, no, I don't need to fix ubiquity, never mind that
<cjwatson> I did think about making it just initrd.img but I sort of like having the extension there
<cjwatson> if it turns out to be a real hassle somewhere I'll reverse that choice
<apw> yeah ... its kinda nice to know what it is, just by the name as shell can do that check nice and easy
<apw> cjwatson, you might have some clever ideas on this, we have found what appears to be a kernel bug which affects the wubi installer and hangs it.  the fix is likely a replacement kernel but it needs to be in a cdimage to be useful to wubi as i understand it
<cjwatson> I don't have direct access to the buildds that produce the live filesystems
<cjwatson> you could build updated initrd/filesystem combinations using the livecd-rootfs package though
<cjwatson> xivulon: ^-
<xivulon> cjwatson, sure that is easy enough
<xivulon> but is that required for this jaunty update, or is it for karmic?
<apw> the lzma initrd would presumably be karmic onwards
<xivulon> in karmic I will try not to have an external boot  dir at all and use grub2 loop module if possible
<apw> sounds sexy
<xivulon> will still need to edit the menu.lst (or whatever is called these days)
<apw> xivulon, things in /etc/grub.d/* which then make /boot/grub/grub.cfg
<cjwatson> xivulon: what apw said
 * apw muses that grub2 seems to have some kind of splash/background support
<xivulon> yep, will need to edit grub.cfg directly though, but should be easy
<xivulon> I will have to find partitions UUID from windows though
<Keybuk> apw: weird, I can't even chroot into the union mount
<Keybuk> bash just segfaults
<Keybuk> in fact, now it just hangs
<apw> Keybuk, poop, so thats worse
<apw> which one you got? 7?
<Keybuk> -8
<Keybuk> vfsunion6
<Keybuk> in fact, this looks like a very old one ;)
<Keybuk> linux (2.6.30-8.10~vfsunion6) karmic; urgency=low
<Keybuk>   [ Andy Whitcroft ]
<Keybuk>   * forward port of the VFS union-mount patch set.
<Keybuk>  -- Andy Whitcroft < apw@canonical.com>   Fri, 05 Jun 2009 11:42:53 +0100
<Keybuk> are you sure you uploaded a new one? <g>
<apw> hrm
<apw> yeah ... one sec
<Keybuk> there's a vfsunion7 in your "staging" PPA ;)
<apw> Keybuk, yeah forgot to copy it over, spanner
<apw> its copying now, take that one
<Keybuk> ok
<apw> that was an update i got last night from val
<apw> and it is meant to fix a locking issue
<apw> so it might even fix what you are seeing
<Keybuk> right, that sounds just like what I'm seeing ;)
<apw> they are being pretty responsive so far, keen to get some testing i suspect
<apw> i have tooo many ppas and no delete button, grrr
<Ng> who would be a good person to pester about getting one of the kernel/ubuntu/misc/ modules updated for bug #387756 ? :)
<ubot3> Malone bug 387756 in linux "[karmic] please update tp_smapi" [Undecided,New] https://launchpad.net/bugs/387756
<apw> isn't that tp_smapi thing the driver of questionable provenance?
<Ng> apw: afaik it's been refused a merge into the vanilla kernel because the author insists on remaining anonymous
<apw> right, the definition of questionable provenance
<Ng> apw: but we've been shipping it for ages, so pragmatic precedent wins the day and we can update it ;)
<apw> so lawyers may decide we remove it too :/
<Ng> lawyers schmawyers
<apw> easy [sic] for you to say
<apw> there is a blueprint for reviewing all those drivers
<Ng> dammit
<apw> ?
<Ng> oh, do you mean reviewing as in "with a view to removing anything we can't square away legally"? or "so we can get them all spruced up and fresh"?
<apw> a combination of the two, a review and decide what to do with each, with the result being either drop or update
<Ng> would dropping mean entirely removing all trace from the archive, or demoting to a DKMS/modass package?
<apw> removing from a kernel point of view would be 'washing hands of'
<apw> i have no idea which way any particular item is going, or more specifically that item is marked RESEARCH, so its not been decided as yet
<apw> added links to both bug and spec (to the other)
<Ng> ta
<Ng> if I were a petulant person, I'd suggest that an anonymous driver is a drop in the ocean of legal questionability that pours forth from multiverse, but I'm not, so I'll just wait quietly and hope that I don't lose the excellent tp_smapi driver ;)
<apw> it is a worry that they won't tell people why they won't tell people who they are
<apw> probabally means they do not have the right to release the code, as it belongs to their employer or something
<Ng> yeah I've always assumed it means they or someone they know works for ibm/lenovo and obtained the specs without permission
<Ng> which is clearly not cool
<Ng> and balanced against that obvious legal situation is the longevity of my battery ;)
<Ng> anyway, thanks for the linkage :)
<lifeless> http://lkml.org/lkml/2008/11/17/355
<apw> yep, if they had simply made up a believeable name and submitted it they would have gotten by
<apw> by showing they are anon and making it clear there is a _reason_ they cannot tell us
<apw> they taint the code
<apw> by implication
<apw> and the law sadly expects you to be reasonable, and not ignore hints like that
<lifeless> well they've said they are willing to show trustworthy people
<lifeless> which is why I linked that particular mail
<apw> no they are willing to prove they are a person
<apw> not explain why they cannot tell everyone who they are
<apw> which is the rub, its likely they have done something questionable
<lifeless> "willing to disclose is identity to
<lifeless> "
<lifeless> Assuming thats a typo of 'his'
<apw> that is just their identity
<apw> their need to hide their identity implies something about them or their working practice
<lifeless> or where they live
<apw> and one has to assume the worst, or open self to pain
<lifeless> well, thats clearly false.
<apw> right, there is a possibility its cause they live in china or north korea or something
<lifeless> everything is patented, so why do we write code at all?
<apw> the law tends to be kinder if you had no way to know in advance
<apw> this situation creates a reasonable expectation we s
<apw> should be suspicious, that is the issue
<apw> if they had called themselves something sane and we'd never known
<apw> life would have been fine
<Daviey> Could it not be that they work for am employeer that is competition to the Linux kernel, and no exclusive code clause in contract - but would appear bad if they were known.
<lifeless> I'd be much more suspicious of someone trying to pretend they didn't want to be anonymous
<lifeless> Daviey: ecactly.
<apw> its pretty unusual for an employer to not have the rights to everything one produces
<apw> its a standard clause in all contracts i have seen and worked under
<lifeless> There are many reasons that being known as the author of that code *without it being tainted* could be problematic.
<apw> yes, but the point is that the law is full of 'could reasonably expect to have assumed' type stuff in it
<lifeless> apw: works in both directions.
<apw> you don't get the benefit of the doubt most of the time
<Daviey> apw: Well i've avoided such contracts, but if that is the case - a HUGE amount of code in the Linux stack is therefore non-free, as the authors may not have had permission to release under a free licence
<apw> indeed so, and lawyers are notoriously 'assuming the worst' kind of people
<apw> Daviey, not necessarily i am employed, the code belongs to my work, i am specifically allowed to contribute it
<lifeless> lawyers are often extremely risk averse. You have to take that into consideration.
<Daviey> yes.. because you have your employeers permisson.  I would imagine that a great deal of patches are written by pure hobbyists, away from dayjob
<Ng> I wonder what our relationship with lenovo is like
<Ng> they don't have to do anything further than agree not to sue anyone because of us distributing a driver that makes their hardware look better
<apw> in a previous job i had the right to do 'non-compete' things outside work in my own name
<apw> anyhow, its not my decision to accept it into or not into mainline, they made their reasons felt, and i can understand them
<lifeless> seemed rather inconclusive in the things I found, given Linus being willing to accept it :P
<apw> and if he does then we get it for free and all is well
<cjwatson> and http://lkml.org/lkml/2008/11/18/272 says "SuSE asked, Lenovo said no"
<cjwatson> (in the same thread lifeless linked to)
<Ng> one does have to wonder exactly what suse asked though
<Keybuk> apw: still a segfault with vfsunion7
<Keybuk> is weird
<Keybuk> it's not even a segfault, the kernel seems to kill bash
<apw> hrm, well that might make sense
<apw> did you get any kernel stack traces on it
<apw> if not, what does strace say happened
<Keybuk> strace just hangs
<Keybuk> in the execve()
<apw> hrm
<apw> setuid perhaps?
<Keybuk> just going to fire up upstart and see why it thinks bash exits ;)
<apw> heh nice
<apw> did you say there was nothing in dmesg at the time, most hard kills are reported
<Keybuk> didn't look tbh
<apw> worth checking then after it happens
<Keybuk> got one
<Keybuk> BUG: unable to handle kernel NULL pointer deference at (null)
<apw> pastebin?
<apw> ouch
<apw> i'll have a look see if i can see what casues it if you paste the whole thing
<apw> somewhere
<Keybuk> sure
<Keybuk> one moment
<Keybuk> it's inside inode permission things ;)
<apw> yeeks :(
 * apw waits impatiently for the trace
<apw> Keybuk, poke
<Keybuk> rebooting
<apw> ouch
<Keybuk> got stuck in kernel and wouldn't shut down :p
<apw> it has that tendancy :/
<Keybuk> apw: http://pastebin.ubuntu.com/197021/
<apw> eip == 0 ouch
<Keybuk> useful stack trace?
<apw> Keybuk, i think its valid, an trying figure it out... what was your union of?
<apw> Keybuk, ??
<apw> Keybuk, think its worth writing up what you did and sending that with the panic to val and jblunk, cc: me
<Keybuk> apw: back
<Keybuk> had to run David to physio
<Keybuk> it was a union of the filesystem.squashfs from today's daily-live
<Keybuk> and a tmpfs
<Keybuk> I ran chroot /mnt /bin/bash
<apw> smb, heads up i just pushed a patch to jaunty-lrm, looks like you are working in there too
<smb> apw, Thanks, though I must refresh my memory what I might do there
<smb> uh oh
<smb> apw, any chance you might kill that again for a sec? What version did you base on?
<apw> smb, ?  i fetched origin and put it on the top
<smb> apw, Hm, yeah. It just looks to me I forgot to push a release
<apw> smb, then force it and i'll re do it
<smb> ok. thanks
<smb> done
<Keybuk> aww, nobody's picked up my LKML patch :'(
<rtg> Keybuk: you should have sent it to a more specific audience
<Keybuk> rtg: there isn't one that I can tell
<Keybuk> nothing in MAINTAINERS for cn_proc or connectors in general
<rtg> Keybuk: I'm can;t remember who was involved in the last round of syscall discussions, but they'd bea good starting point
<Keybuk> it isn't syscall though, no?
<rtg> Keybuk: not really, but its up in the process control layer. Perhaps Ingo?
<apw> Keybuk, if all else fails always send it to akpm he knows everyone
<Keybuk> true
<Keybuk> will give it a few days ;)
<Keybuk> Ingo, Andrew, Oleg, etc. tend to pick up things from LKML anyway
<rtg> Keybuk: he might have missed it in the merge window storm
<smb> apw, Just for info, the patch for jaunty lrm is for whch bug?
<apw>     BugLink: http://bugs.launchpad.net/bugs/305587
<ubot3> Malone bug 305587 in linux-restricted-modules "[Jaunty] warning: missing LSB information " [Medium,Fix committed] 
<rtg> apw, jjohansen: is there a reason LGUEST_GUEST isn't enabled for i386?
<rtg> in karmic, that is
 * apw looks
<apw> LGUEST_GUEST implies we are building a paravirtualised kernel
<apw> so i'd not expect it to be on for a primary i386 kernel i don't think
<apw> rtg, ^^
<rtg> apw: right, it allows the 32 bit lguest kernel to boot under an lguest hyper visor. why wouldn't we enable it?
<apw> well it would depend on whether it is independant of being a real kernel at the same time
<apw> i would expect it enabled in a special kernel like the server virtual flavour
<rtg> apw: all of the paravirt-op stuff is dynamic anyway.
<apw> i'll see if it is enableable in parallel
<apw> rtg then it should be fine. note it is only non-pae so we'd only get it in the new i386_nonpae flavour
<soren> LGUEST and PAE don't like each other.
<soren> I forget why.
<rtg> apw: I think I remember someone at UDS requested it
<soren> Oh, apw already said that.
<soren> Never mind me.
<apw> shall i put it on the config review and spin a patch for it?
<rtg> apw, soren: I'll get back to lguest in a bit. I'm currently making sure PAE works.
<apw> ack
<rtg> apw: wait until I have the legacy flavour implemented
<apw> i was about to respin that config merge patch
<apw> if you are mid flavour mangle then it should wait
<apw> rtg ^^
<rtg> apw: it should be independent of the flavours, right? 
<apw> yeah the code change is, but there is an associated fdr updateconfigs which isn't
<rtg> apw: we could do them independently since the build process would pick up the config changes anyways
<rtg> i.e., just the script patch with out the config file updates
<apw> yeah we can do that for sure
<rtg> I can collapse them later
<apw> i'll send out the patch with a sample patch for the config change so peple can see what it does
<apw> but with a view to merging only the code change 
<rtg> right
<apw> ok plan
<mohan_> hi.. i am building kernel..
<mohan_> how to make deb file out of it?
<mohan_> hi.. any body pls help..
<rtg> mohan_: start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<mohan_> rtg: ok.. thanx..
<mohan_> rtg: fully confused .. :(
<mohan_> i am right now done with make modules..
<rtg> mohan_: then you are doing the wrong thing. see 'https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Normal full build'
<rtg> mohan_: you must use debian commands to build the kernel
<rtg> the best way is to install devscripts and run 'debuild -b'
<mohan_> hmm,.. but before it worked..
<mohan_> i installed RT kernel before in this way..
<rtg> mohan_: you may have installed it, but you didn't build it that way
<mohan_> oh.. ok..
<mohan_> i didn't build a deb package though..
<mohan_> but now i want..
<mohan_> but doing this : fakeroot debian/rules binary-generic
<rtg> mohan_: then do as I've indicated. plod through the steps
<mohan_> gave error: /usr/bin/fakeroot: line 176: debian/rules: No such file or directory
<mohan_> ok sir..
<rtg> mohan_: sudo apt-get install build-essential fakeroot devscripts
<mohan_> ok.. sir.. its installing..
<mohan_> takes one min..
<mohan_> i have done passing menu config and make and make modules command..
<mohan_> opened package configuration..
<rtg> mohan_: then you've made a mess. do 'git checkout -f master;git clean -f -d'
<rtg> thern 'debuild -b'
<mohan_> ok..
<mohan_> now what should i set in this package configuration?
<mohan_> no mail?
<rtg> huh?
<mohan_> postfix configuration dialogue box is asking
<rtg> use the default
<mohan_> ok..
<mohan_> what does git checkout do?
<rtg> mohan_: uh, you must not be using the Ubuntu git repo?
<mohan_> no..
<mohan_> i downloaded kernel manually from kernel.org and patched RT kernel to it..
<rtg> mohan_: then go back to https://wiki.ubuntu.com/KernelTeam/KernelMaintenance and read
<jjohansen> The kernel team weekly meeting will start in #ubuntu-meeting in 5 min
<zeroprog_>  hey guys how do u check MTU size in ubuntu
<dtchen> ip(8), ifconfig(8)
<dtchen> (same as in other Linux distributions)
<maxb> Does anyone know if the lack of provision of a linux-image-debug package is deliberate?
<maxb> Or is it just an accident of someone thinking that it's redundant now we have ddebs..... except ddebs are effectively only available for the current development release of Ubuntu
<dtchen> maxb: rtg answered that some time last week
<dtchen> maxb: briefly, the omission is intentional, as they can be built on the servers but result in gigantic binary packages
<maxb> It would be nice to have an official comment in LP 289087
<maxb> ubot3: ?
<maxb> ubot3: bug 289087
<maxb> hrm
<ubot3> Malone bug 289087 in linux "Missing linux-image-debug packages and metapackages since Intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/289087
<ubot3> Factoid bug 289087 not found
<dtchen> maxb: feel free. https://lists.ubuntu.com/archives/kernel-team/2009-June/005931.html
<maxb> "How to build them" is not the same question as "Why are they no longer downloadable"
<dtchen> maxb: a deliberate attempt to avoid bloating the archive has been raised. i actually asked this question some time ago at the most recent UDS Mtn View.
<dtchen> maxb: if you feel it is necessary to have the rationale written precisely in response to why the large debug packages are unavailable from cc.archive.ubuntu.com, then by all means, go for it.
<maxb> Well, I feel it necessary that the users legitimately noting that a feature present in Hardy is no longer available have some sort of explanation why that is the  case.
#ubuntu-kernel 2009-06-17
<dtchen> cjwatson: at least from inspecting current git HEAD of anaconda, it seems the PAE is indeed quite straightforward: (from isys/isys.py:711)   if line.startswith("flags") and line.find("pae") != -1:
<dtchen> err, "the PAE check"
<cjwatson> dtchen: ok, thought so
<cjwatson> my question about how the heck we're going to actually account for both sets of users on a single CD stands, though ...
<cjwatson> (but I see Tim has answered. Fair enough. I guess time will tell)
<cjwatson> (and any bugs I get about it will be unceremoniously reassigned to the kernel! :-) )
<Sarvatt> is the default i386 generic kernel switching to PAE? or is there going to be a PAE flavor?
 * Sarvatt hopes its not the former for the sake of all intel graphics users :D
<Sarvatt> (because GEM doesnt work with PAE)
<cjwatson> *blink* that's news to me
<cjwatson> shame rtg left a while back ...
<cjwatson> the proposal was to leave -generic alone but basically only offer it for netboot/DVD users; that may be a bit of a roadblock
<jjohansen> it might be but there are work around patches that can be applied if the real fix doesn't land for .31
<maxb> ogasawara: I don't agree with wontfixing that bug based on that mail link. The bug is about "Why are these packages no longer in the archive", the mail thread is about "How do I build these packages locally"
<maxb> "Debug packages are so large that they are only built on the buildd's." does not explain why the debug packages built on the buildds are not then published to the archive
<ogasawara> maxb: feel free to add a comment
<cjwatson> Sarvatt: I've brought the GEM issue up on the mail thread, thanks
<Sarvatt> is there really alot of demand for the default kernel to be PAE on x86? I would think most everything with >4gb ram is going to be x64 compatable so it's down to NX vs the performance overhead and incompatability issues with PAE.. theres some discussion on it in this thread - http://thread.gmane.org/gmane.linux.kernel/843866
<cjwatson> lots of people don't want to use amd64 on desktops because then they have to deal with 32-bit compatibility libraries and argh nightmare pain
<cjwatson> but yeah, interesting comments from Linus there
<ikepanhc> hi apw
<apw> hi
<ikepanhc> apw: could you look at https://bugs.launchpad.net/bugs/276949, is that ok?
<ubot3> Malone bug 276949 in linux "No driver for HP Webcam - 15b8:6002" [Medium,Triaged] 
<apw> ikepanhc, what do you need me to see?
<ikepanhc> apw: the last comment I just sent
<apw> ok, the statement seems factual
<ikepanhc> I try to, I just afraid bug reporter will be disapoint
<apw> they are always dissapointed when we cannot do everything for them
<apw> if you have asked smb and he is against then thats that
<apw> we will have a release before long, and have given them an unofficial kernel which supported the camera
<ikepanhc> thanks, I will ask smb's story or viewpoint
<apw> yep... he can aways comment on the bug if there is dissent
 * apw looks if the patch is in stable
<ikepanhc> that is not a short patch
<apw> that indeed is the  issue, big patches == risk
<smb> Ideally I would like a stable topic branch to be like the mainline builds. So you can install it simply to try out stuff
<smb> and you could switch between the official one and the other
<zeroprog> hey guys i just installed karmic koala and it says that it is built on kernel 2.6.30 but when i do uname -r it says 2.6.28....and i cannot find the source with the correct patches so that i can set up a proper driver dev environment
<smb> If we got that, then a pocket in the kernel-team ppa might be the place to put it
<smb> zeroprog, Was that a clean install/chroot/or upgrade?
<zeroprog> clean install
<apw> smb, yeah i tend to agree with all of that
<apw> zeroprog, the kernel should indeed be 2.6.30
<zeroprog> hmm.....it says 2.6.28-11.....which doesnt have a source package i guess
<smb> zeroprog, exactly. the uname output comes from the kernel... Just to rule that out /proc/version says the same?
<zeroprog> yes smb
<apw> zeroprog, can you paste the output of cat /proc/version_signature please
<smb> zeroprog, 2.6.28 is the Jaunty kernel
<zeroprog> cat /proc/version
<zeroprog> Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009
<smb> That is the Jaunty release kernel
<apw> how about the output of: dpkg -l | grep linux-image
<zeroprog> dpkg -l |grep linux-image
<zeroprog> ii  linux-image-2.6.28-11-generic              2.6.28-11.42                              Linux kernel image for version 2.6.28 on x86
<zeroprog> ii  linux-image-generic                        2.6.28.11.15                              Generic Linux kernel image
<smb> And maybe to check sanity, check what /etc/apt/source.list has as release
<apw> and the output of: cat /etc/lsb-release
<zeroprog> ok it says distrib is jaunty but i just bought an ubuntu book with a karmic koala cd
<apw> finally check /etc/apt/sources.list
<smb> apw, and yeas. I think we are on the same track there. I hope we can allocate a slot to think just about the versioning. The rest might be simple enough
<apw> zeroprog, it claims to be karmic, thats not even released
<smb> zeroprog, Interesting yeah ^^^
<smb> Chances are rather that they have a Jaunty CD
<zeroprog> really....it was supposed to be beta
<smb> zeroprog, alpha
<apw> karmic is only at alpha2
<zeroprog> yes alpha sorry
<apw> hmmm... then it is possible that the CD was taken at alpha1
<apw> zeroprog, the easiest way forward is likely to run update-manager -d
<apw> and then take the option to update to karmic
<smb> apw, Not if sources.list is wrong
<apw> update-manager will sort that out in theory
<smb> Or aeh
<smb> You are right
<zeroprog> well id prefer to stay on jaunty because it is stable...but i still cannot get the source for it 
<apw> zeroprog, ok so what is the actual issue?
<apw> what source are you trying to get
<zeroprog> i keep getting the invalid format when compiling a simple module .... extension is ko
<apw> can you paste the commands you are doing and all of the output into a pastebin and point us to it
<zeroprog> well i went to kernel.org and downloaded 2.6.28
<zeroprog> http://pastebin.com/d21a8f2fd
<smb> zeroprog, One thing (probably not really related) The kernel 2.6.28-11 looks like you never did any sort of update on that system. The current updates kernel would be 2.6.28-14.33
<apw> zeroprog, so are you trying to enable something specific?
<zeroprog> yes ive just installed this within the last two days after using hardy heron for a year
<zeroprog> just the ability to write device drivers heh
 * smb wonders wheter this might be "make menuconfig"
<apw> ok that paste has no errors?
<zeroprog> hardy is working fine on my alernative notebook but this one seems to be giving me trouble
<smb> Though that should not be required to get an external module to build
<zeroprog> there are no errors everything installs fine
<apw> except you complained about errors?
<zeroprog> invalid format hello.ko
<apw> right that is an error, who says it where from what command
<zeroprog> from make
<smb> zeroprog, Does dmesg say something at the end
<smb> like disagrees about version
<zeroprog> yes 
<apw> ok so when i asked for the command and the errors, those were the ones i was referring to
<zeroprog> disagrees with symbol struct_module
<apw> you need to be running your installed kernel
<apw> before you can load up modules which you built for it]
<apw> your uname says you are running the ubuntu kernel, not your built kernel there
<smb> This might be just an external module tree. Not a complete kernel
<zeroprog> it says im running a generic kernel
<smb> zeroprog, the place you run the make commands. Is that just containing ou hello world module?
<zeroprog> yes
<apw> paste the uname -r output again
<zeroprog> 2.6.28-11-generic
<apw> that is not a generic kernel, that is the ubuntu generic flavour
<apw> the mainline kernel would say 2.6.28
<zeroprog> the vanilla kernel yes but that failed so i tried this one
<apw> right but modules are specific to the kernel you built them for
<apw> so you either need to be running the mainline kernel and make modules for that
<apw> or you need to be running the ubuntu kernel and need to make modules for that
<apw> the two will not mix in either combination
<apw> you should be able to make modules for the ubuntu kernel using the headers
<apw> they should contain enough to allow 'out of tree' compilation of a module
<smb> Were there any linux-headers-generic installed?
<zeroprog> i tried that also....how do i install the mainline kernel?
<zeroprog> yes smb
<apw> it sounds like you already did, from those commands
<apw> when you say 'it failed' what does that mean
<zeroprog> id get the invalid format hello.ko error
<apw> so somehow you are not making the module for either kernel it seems
<zeroprog> i am sketchy at makefiles but heres mine http://pastebin.com/d3a99a3cd
<zeroprog> i just switched it to the headers 
<smb> The danger lies in the absolute path for the headers
<zeroprog> i dont see it
<smb> normally you go through /lib/modules/$(uname -r)/build
<smb> make -C /usr/src/linux-headers-2.6.28-11-generic M=$(PWD) modules
<smb> ^ here you force it to use that path. That might not be your running kernel
<apw> thats the one
<apw> make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules
<smb> or "make -C /lib/modules/`uname -r`/build M=`pwd` modules"
<smb> same for clean
<zeroprog> i get target /path/to/my/src does not match target pattern
<smb> That is another problem. You usually want to mask the all part when the kernel compile looks at the makefile
<smb> hell what was that again
<zeroprog> im sorry what do u mean by mask
<smb> ifeq ($(KERNELRELEASE),)
<smb> <here comes your all>
<smb> else
<smb> obj-m += hello.ko
<smb> endif
<smb> That way, when you run make, you go into the upper branch and call the kernel make
<zeroprog> ahh ok
<smb> then that sets KERNELRELEASE and calls your makefile again and only sees the obj-m
<zeroprog> is there a separator or some sort or is it the way you typed it
<smb> The part between ifeq and else certainly has to be replaced. The rest might or might not be correct, given I just typed from my head
<zeroprog> yeah im getting a missing separator error
<smb> And just another note: I really do not understand the "make menu config" part. That sounds slightly like useless (or even dangerous) voodoo
<zeroprog> the tutorial i read on installing and setting up the kernel source said to do it 
<zeroprog> actually it was the README
<zeroprog> alright ive bothered u guys enough thanks for the help ill try to figure the rest out on my own
<tjaalton> hey, I have no 3G with my thinkpad in karmic, worked in jaunty (and with the jaunty kernel)
<tjaalton> I wonder if the kernel thinks it's disabled or something
<tjaalton> filed bug 386528, will attach the dmesg output now..
<ubot3> Malone bug 386528 in linux "[karmic] No sierra 3G with 2.6.30, works with 2.6.28" [Undecided,New] https://launchpad.net/bugs/386528
<smb> tjaalton, Is the 3G visible in lspci -vvvnn (and has a module loaded)?
<mvo> hello! looking at https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-karmic-flavours its not entirely clear to me what the new names will be linux-generic (with PAE) and linux-legacy (without) - what about linux-386? is that going to go away? what about -server, -virtual? -rt? etc? 
<smb> apw, Actually what was that ubuntu-bug incarnation that collects all kind of usefull data
<tjaalton> smb: the module was listed in /etc/modules, so it's loaded, but can't see anything with lspci
<apw> ubuntu-bug linux i thought
<tjaalton> and the command is apport-collect ###, but I'd need to clear the lp auth first
<apw> there is also apport-collect something to add it to another bug
<tjaalton> where is the cookie stored?
<smb> But given the fact it is not in lscpi looks a bit suspicious
<smb> anyhow
<tjaalton> I'll try .27
<apw> mvo, the linux-386 version will remain in ports as far as i know
<tjaalton> make that .28
<smb> mvo, -rt has been a community kernel anyways
<apw> mvo, the -server is likely to remain unchanged name wise.  -rt is a port flavour and not part of the review
<smb> -386 a ports kernel (also community)
<smb> I think that leaves virtual which anyways was a repackaged server kernel
<tjaalton> smb: actually, it's a usb device, but lsusb doesn't show it either
<mvo> thanks - so I will add code then that transitions from "generic" -> "legacy" if no PAE is available for now
<smb> tjaalton, Heh, ok. Wrong lead then. Hm usb...
<mvo> I'm still wondering what to do about -386 for people with old installs/upgrades. I guess it makes sense to transition them to -generic if they have PAE 
<mvo> ?
<smb> mvo, If they have PAE that would make sense. What we were not quite clear is people without and possibly cpus not even up to M586
<mvo> right. if PAE is safe I start with that, if there is a additional combination of flags/information to look at, I'm happy to add them too
<smb> tjaalton, Just a very wild guess as all the usb modules have been compiled in in jaunty too. maybe you could experiment with unbinding the (crap which one was usb1) ehci driver
<mvo> I just want to be very careful not to transition people to a kernel that does not boot 
<smb> mvo, We tried to start of with cpus whe have on that page.
<mvo> smb: should I add info there as well for my machines (also I have mostly relatively recent ones)?
<mvo> i.e. is that useful for you?
<smb> mvo, Tentiatively it feels like getting info about the ones that might break (the older) being more helpful. apw, what would you say?
<tjaalton> smb: ok I'll try. .28 shows it ok, sierra wireless 1199:6813
<apw> smb, yeah agree with that
<mvo> the oldest in use I have is a P3-mobile, I guess that is not really very helpful 
<mvo> thanks, I think I got enough info to add basic transition support
<tjaalton> smb: hmm you mean not building EHCI_HCD in the kernel?
<apw> mvo, there were people who were transistioned onto the 386 ports kerenl who prolly should not have been when upgrading
<apw> from pre hardy->hardy which are worth considering in the transition
<smb> tjaalton, No, actually (without any experience) I thought it should be possible to use sysfs to unbind the driver from activeness...
<mvo> apw: there is no code in update-manager that would do a transition like this, they probably had -386 installed before? 
<mvo> apw: -386 -> -generic is done if they run a SMP kernel, but thats aobut all the magic there is currently
<tjaalton> smb: ah. ok
<apw> right, thats the issue.  older releases the i386 kernel was the default, they updated and ended up on the ports kernel, not thorough an action but through inaction
<apw> you mentioned pulling them up to pae if they had support, it is worth considering pulling them up to -legacy if they have 586 and above
<mvo> right, I know about this problem, I would love to fix it, but I need a reliable way to know what machines should not be transitioned
<mvo> I do not want to transition everyone and end up with some machines no longer booting
<mvo> ok, if 586 is good, I can certainly do that
<smb> mvo, Yeah, we need the support of all low-level-cpu loving folks out there
<tjaalton> smb: it's possible to unbind a device from the driver, but the device isn't bound anywhere..
<cjwatson> can we please not call the non-PAE kernel "legacy"?
<cjwatson> firstly, having names that are basically "old" and "new" runs into rather obvious trouble when you need a third; we found that with nvidia
<cjwatson> descriptive names are *always* better
<cjwatson> secondly, as I said in e-mail, I'm concerned about the likely performance of using PAE everywhere when it isn't necessary and I think "legacy" is considerably overoptimistic
<apw> cjwatson, i thought the flip side was that the security people were very keen to have it turned on for NX
<cjwatson> there are lots of considerations
<cjwatson> but I don't think they're simple enough that we can just say "screw you guys, you're legacy"
<apw> not trying to dismiss your concerns
<cjwatson> I linked to a comment from Linus that was basically "people who turn on HIGHMEM64G are crackheads"
<cjwatson> but anyway, why not just have value-neutral names?
<cjwatson> Tim used -generic and -generic-pae in another place, which seemed reasonable
<apw> yep, that part is separate and obvious
<apw> as in i  htink we should separate the naming issues as against the how to choose the appropriate kernel issues
<cjwatson> yes
<apw> cjwatson, your thread as i see it has no mention of naming, we should inject that into that thread, as it seems to be the master discussion on this feature
<cjwatson> that's because Tim's original mail in that thread used names I didn't object to :-)
<cjwatson> apw: I've injected it now
<apw> cjwatson, thanks thats excellent
<tjaalton> smb: looks like the sierra doesn't work even with mainline 2.6.29.5
<apw> cjwatson, in what form is the kernel on the CD image.  is there a full kernel install, as in the .deb installed?
<cjwatson> which CD image?
<apw> hrm, i was thinking of the live ones
<cjwatson> the .deb's just installed in the live filesystem
<apw> thats what i assumed, thanks
<cjwatson> the only difference from a regular installation is that the actual kernel image is removed, because it's also on the ISO9660 filesystem
<cjwatson> saves us several megabytes
<cjwatson> and the installer is smart enough to copy it from the right place
<cjwatson> but other than that it's as normal
<apw> thanks
<smb> tjaalton, It least that narrows down the pile. Though it probably still is the whole of usb-core to look at
<alex_joni> cjwatson: is that also true for 8.04 LiveCDs ?
<alex_joni> cjwatson: meaning if I install a custom kernel deb, and I install the kernel and initrd outside the squashfs, can I simply remove the kernel from /boot ?
<AceLan> alex_joni: I can't understand what's your problem, could you describe more explicitly?
<alex_joni> AceLan: see what cjwatson said above
<cjwatson> alex_joni: no, I'm afraid this was added in 8.10
<cjwatson> AceLan: I understood :-)
<alex_joni> cjwatson: ok, thanks.. something to remember for 10.04 then
<cjwatson> (and it went badly wrong when first introduced, resulting in world-writable kernel images, but we fixed that just before release ...)
<alex_joni> world-writable (after the copy from the CD to the live system) ?
<rtg> soren: do we still need a 32 bit virtual kernel package for Karmic?
<Keybuk> apw: Jan replied to the vfs union mount issue
<apw> Keybuk, after the 'i'll look later' ?
<Keybuk> Arrgh, it is the autofs crap that is killing us (see commit
<Keybuk> 051d381259eb57d6074d02a6ba6e90e744f1a29f). They actually replace the nameidata
<Keybuk> and therefore the inode operations when they see a symlink which isn't coming
<Keybuk> from the filesystem of the parent directory. This is because their root dentry
<Keybuk> is actually a symbolic link ...
<Keybuk> Thanks for finding this,
<Keybuk> Jan
<apw> Keybuk, ahh yes
<apw> so i guess we might get a fix sometime soon
<Keybuk> yes
<Keybuk> I didn't know whether the commit id was a fix or the cause
<Keybuk> or which tree that was in
<Keybuk> etc.
<apw> looks to be the cause
<apw>     [PATCH] autofs4: nameidata needs to be up to date for follow_link
<cjwatson> alex_joni: after the copy from the CD to the *installed* system
<cjwatson> alex_joni: but don't worry about it, it's fixed now
<alex_joni> cjwatson: heh, I have tons of confidence that you guys squash these bugs pretty fast
<solarion> Can also do more than 2 channels?
<solarion> ALSA, rather
<solarion> (is what this amd guy is saying: http://blogs.amd.com/home/2009/06/16/turning-it-up-to-11/comment-page-1/#comment-224)
<solarion> ah, perhaps I misread; he meant that the current driver only does 2channel audio
<cjwatson> alex_joni: where in this case "pretty fast" is "massive panic the day before release", yes :-/
<alex_joni> cjwatson: don't we all work better under pressure and deadlines :D
<alex_joni> errr.. not :D
<dtchen> solarion: alsa does not place artificial limits on the number of channels available to software above it in the audio stack
#ubuntu-kernel 2009-06-18
<zeroprog> hey guys i finally was able to compile my module example....but in /var/log/messages it says init suspiciously returned 32 but loading module anyway.....is this bad?
<Ng> are things like /proc/sys/vm/{laptop_mode,dirty_writeback_centisecs} supposed to be remembered across suspends?
<amitk> Ng: they should be...
<Ng> amitk: empirically... not so much
<Ng> I set them in sysctl.conf on boot and they're back at roughly default looking values 20 hours later after an unknown number of suspends
<Ng> what I need, is a test case :)
<amitk> Ng: does laptop-mode.conf have any settings to override it, I wonder
<Ng> ooh, good point
<Ng> http://pastebin.com/f537ccbeb
<Ng> oh I wonder if this is the _ON_AC setting
<amitk> probably
<amitk> try disconnecting AC and see if your settings are restored, assuming they are made to laptop-mode.conf and _not_ sysctl.conf
<lifeless> is there a known bug in karmic where laptops randomly power off?
<lifeless> happened to me twice now; power button wasn't held down. machine didn't feel overheated.
<amitk> lifeless: never seen in before, worth a bug.
<rtg> apw: lemme experiment with the pae kernel a bit.
<apw> sure ... in a couple of hours i will have some kernels available for testing (errors permitting)
<rtg> apw: why does gem barf on pae?
<rtg> is it the extra page table level?
<apw> the agp interfaces used to take addresses <4gb only as i understand it
<apw> the patches change the API to take page*'s instead fixing the issue
<rtg> ah, I guess that makes sense
<apw> i think it meant you might try and push things into highmem for graphics objects and the world ended
<apw> in bad, corrupting type ways
<amitk> one would think that this would be one of the first problems the developers would encounter given that they work for Intel and probably have few machines with < 4Gb of memory
<apw> amitk, i am constantly amazed by what is ignored
<apw> the issue was a core interface issue, so it got ignored by the graphics people
<apw> till dave picked it up it seems
<rtg> hmm, its pretty bad when NM can't even get an ethernet DHCP address. I can see the server offerring an address, but the Karmic client is just ignoring it.
<apw> ouch, no receieve side?
<rtg> apw: works fine if I hard code the address
<apw> unable to receive broadcasts perhaps?
<rtg> apw: no, it ARP'd OK
<apw> hrm
<apw> bug in dhcp client perhaps
<apw> perhaps slap a tcpdump on the channel before enabling
<rtg> apw: I can see the offer in /var/log/syslog
<apw> *gurgle*
<apw> that has to be a NM/dhcp bug then
<apw> as we now know the offer made it to the machine, and into dhcp-client, and we know you can set an address on the interface
<rtg> apw: well, pae --> garbage onscreen
<apw> rtg hrm, that is unexpected
<apw> i would have expected working but compiz disabled
<apw> i'll get with bryce and see what testing we can get done on those kernels
<rtg> apw: this DHCP issue has to be Karmic related, I booted a Jaunty kernel and still cannot get an ethernet address, though wireless works fine.
<apw> yeah be worth seeing if we have merged those support packages recently
<apw> rtg, i see luke has just sent up a pull for the ports re-merge
<rtg> this ought to be interesting
<apw> yeah ... you gonna handle that?
<rtg> might as well, everything is fresh in my head
<apw> or do you want me to
<apw> good enough
<rtg> back in a few, coffee run
<TheMuso> FWIW this was not something I asked for. I was happy with how it was, but the archive admins are the ones who want this merge.
<apw> yeah we were happy too, not sure quite what the beef was exactly
<Keybuk> apw: got a new build for me yet? :p
<TheMuso> apw: I can fully understand why  you guys wanted it separate.
<apw> Keybuk, oh we got fixes there too
<apw> ?
<Keybuk> apw: yeah Jan sent a patch through earlier
<Keybuk> Subject: [PATCH] Don't replace nameidata path when following links
<apw> ok just finsihed some kms uploads, so will get that now
<Keybuk> (in the thread)
<apw> Keybuk, any idea what the limitation on sysfs and proc might mean
<Keybuk> yes
<Keybuk> if you mount your union over /
<Keybuk> then any attempt to write into /proc, /sys, /dev, etc. will go to the union ;)
<apw> ahh heh yeah it is a stupid thing to do obviously
<apw> it was only a minimal demo of the explosion
<soren> Keybuk: What's the solution for that? Special case virtual filesystems or avoid overlaying "submounts" altogether?
<soren> Or something entirely different?
<Keybuk> soren: you make the union before you mount them
<Keybuk> you can mount over top of a union obviously
<soren> Keybuk: Oh, right.
<Keybuk> ie. make your root filesystem, then mount the union, then mount the virtual filesystems, etc.
<Keybuk> I was actually thinking that it might be fun to support this in /etc/fstab :p
<soren> Right, right. *headdesk* I wasn't thinking.
<Keybuk>   server:/ro/jaunty/usr  /usr  nfs defaults 0 0
<Keybuk>   tmpfs                  /usr  tmpfs  union 0 0
<Keybuk> then I realised that it just works
<apw> nnng
<pgraner> apw: ping
<apw> pong
<pgraner> apw: can you take a peek at https://bugs.launchpad.net/bugs/370173  this one is getting a huge number of "me too" 
<ubot3> Malone bug 370173 in linux "Ubuntu 9.04 laptop overheat and shutdown" [Undecided,Confirmed] 
<apw> pgraner, what a crock
<pgraner> apw: heh... its another one of those bugs with a billion comments...
<rtg> apw: we use crock pots to make stew, and they are hot. is that the issue?
<apw> heh perhaps
<pgraner> apw: not sure if its better suited for you or smb but we need to track it and see if there what upstream knows
<apw> pgraner, indeed .... i'll get a range of kernels and see if i can reproduce it here
<smb> We probably have to look and decide
<bjf_afk> rtg, question about imx51 build
<rtg> bjf: hmm?
<bjf> rtg, jiffies.h can find CLOCK_TICK_RATE
<bjf> rtg, it's defined in mx51.h
<rtg> bjf: s/can/can't/ ?
<bjf> rtg, right "can't"
<rtg> seems like an arch problem introduced by their patch set
<bjf> rtg, early part of build must setup headers so this can be found
<bjf> rtg, It's probably one of the merge conflicts that I didn't handle right
<rtg> bjf: yep, the prep phase points asm to asm-arm
<rtg> bjf: do you have your branch pushed somewhere?
<bjf> rtg, looking at include I don't see asm or asm-arm
<bjf> rtg, just asm-generic
<bjf> rtg, I'll dig into it
<rtg> bjf: k, I'll be back in awhile
<apw> Keybuk, that unionfs kernel is ready: https://edge.launchpad.net/~apw/+archive/green
<Keybuk> thanks
<MacSlow> http://pastebin.ubuntu.com/198664
<MacSlow> Anybody with an idea what "Failed to register hw (error -17)" means?
<MacSlow> Thanks in advance
<rtg> MacSlow: Jaunty?
<MacSlow> rtg, no on Karmic 2.6.30-9-generic
<rtg> MacSlow: its a software registration error, so I'm not really sure why its failing.
<MacSlow> rtg, firmware issue?
<rtg> MacSlow: I have some 3945's. Lemme try 'em out.
<MacSlow> rtg, sweet... thanks!
<MacSlow> rtg, btw.. just so that you know... I've wifi-based network again thanks to the atk9k PCMCIA-card I've plugged into laptop
<MacSlow> rtg, but still getting the internal wifi-card working again would be very slick
<rtg> MacSlow: they both use the same registration function, so its interesting that iwl is failing.
<rtg> MacSlow: I assume the i3945 worked with Jaunty?
<MacSlow> rtg, oh... so it's not a firmware thing then?!
<MacSlow> rtg, well the whole thing started failing around the interpid/jaunty time
<rtg> MacSlow: I don't think so, but I did recently upgrade the Karmic firmware for that part.
<rtg> MacSlow: if its been failing for that long, then you may have HW issues.
<MacSlow> that's why I bought the atk9k in Mountain View during second last UDS in California
<MacSlow> crap
<rtg> some of these wireless cards don't last forever.
<MacSlow> rtg, it's not really an old laptpo
<MacSlow> only about 2 years old
<MacSlow> I regard that still as rather new
<rtg> MacSlow: I guarantee that i3945 worked with Intrepid and Jaunty.  Its in one of my primary travel laptops
<MacSlow> *sniff*
<rtg> MacSlow: I'm updating an Inspiron 1420 with Karmic. It'll be 20 minutes or so. I also know that ogasawara has the same laptop.
<MacSlow> I wonder if I can get a replacement one on warrenty still
<rtg> MacSlow: can't help you there :)
<MacSlow> rtg, ogasawara had her fair bit of entanglements with my laptop at last AllHands regarding the issue
<MacSlow> killswitch issues back then
<rtg> MacSlow: I'm really thinking you might HW issues
<MacSlow> but I was running another kernel during AllHands
<rtg> s/might/might have/
<rtg> MacSlow: what kind of laptop?
<ogasawara> MacSlow: lemme reboot into the latest karmic, but I've not had any issues with my wifi (iwl3945) on my inspiron 1420
<MacSlow> rtg, I'll try to get feedback on an exchange card at the local dealer tomorrow or so
<MacSlow> brb
<invisibill> Greetings deep kernel heads:  I'm an amd64 / nvidia / ubuntustudio user.  I had to upgrade from the relase-rt kernel to http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc8/ to work around system crashes.  
<MacSlow> re
<invisibill> side effect is my best sound card "echoaudio mia" doesn't work with this. 
<invisibill> I want to build the latest kernel from scratch but I'm not sure of the way to go for this.  I see there is an rt in the git repository, but I cant tell if it will work for amd64. 
<invisibill> any suggestions for the best place to start on this?  
<invisibill> I've built custom kernels on debian systems a few years back but I'm sure the process is different on ubuntu. 
<invisibill> This may be asking too much, but can you (anyone that knows what they're doing) put a how-to for building an ubuntu kernel on the kernel wiki?  
<ogasawara> MacSlow: unfortunately no errors here for me with 2.6.30-9 - http://pastebin.ubuntu.com/198684/
<rtg> invisibill: start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<MacSlow> ogasawara, ok I'll try to get a replacement iwl3945 on warrenty then... hopefully
<invisibill> there is this blog post here but It looks a bit ad-hoc http://blog.avirtualhome.com/2008/10/28/how-to-compile-a-custom-kernel-for-ubuntu-intrepid/
<MacSlow> ogasawara, rtg: thanks sofar to the two of you!
<invisibill> ok thanks rtg  I'll have a read up of this.
<rtg> MacSlow: works fine for me as well
<MacSlow> rtg, yeah.. rub salt into the wound ;)
<rtg> MacSlow: just walk around muttering "I'm screwed, I'm screwed" :)
<MacSlow> rtg, but you mentioned to see it often such internal wifi-cards die
<rtg> MacSlow: mostly I see them die in outdoor environments
<MacSlow> that kind of ruins my trust in the overly solid thinkpads
<MacSlow> rtg, due to other electromagnetic radiation?
<rtg> MacSlow: sometimes, but they also fail due to continuous use.
<MacSlow> which is usually shielded by building walls (if one uses the laptop only indoors)?
<MacSlow> how stupid is that?
<rtg> MacSlow: if this is your primary laptop for the last 2 years, then its had a great deal of use.
<MacSlow> almost sounds like built-in failure to keep customers
<MacSlow> rtg, but it's a tool... it's meant to be used that thoroughly...
<MacSlow> especially thinkpads
<rtg> in a perfect world...
<MacSlow> gee... my world is collapsing right now :)
 * apw shifts to his ethernet connection to save his packets
<MacSlow> apw, now you're scared right? :)
<apw> heh
<Keybuk> apw: I can chroot in!
<invisibill> hi again.  I want to checkout the latest rt kerenel to build on my amd64 system:  http://kernel.ubuntu.com/git?p=abogani/ubuntu-jaunty-rt.git;a=commit;h=b583230610922e5414cb38d09d3104753a77a771  What is the command to do that? 
<apw> Keybuk, excellent.  so you can do some sensible testing now?
<apw> you could reply and let them know when you get a chance
<Keybuk> apw: strange issue with symlinks
<Keybuk> bash: /usr/bin/vi: File exists
<Keybuk> where /usr/bin/vi -> /etc/alternatives/vi -> /usr/bin/vim.tiny
<apw> hrm very odd.  so any of the other links work?
<invisibill> git clone git://kernel.ubuntu.com/git?p=abogani/ubuntu-jaunty-rt.git  ??
<Keybuk> yes
<Keybuk> which is weird
<Keybuk> type -f doesn't find it either
<Keybuk> seems to be true for most alternatives
<Keybuk> other symlinks are ok
<apw> invisibill, nope, git clone git://kernel.ubuntu.com/abogani/ubuntu-jaunty-rt.git
<apw> so links to links are unwell perhaps
<Keybuk> apw: rename() obviously doesn't work
<Keybuk> which breaks lots of things
<invisibill> thanks apw
<apw> whats it say 'EXFS' or something?
<apw> i do wonder why a rename can't trigger a copy up, then simply return ERESTART
<Keybuk> weird
<Keybuk> stat64("/usr/bin/vi", 0x99999999) = -1 EEXIST (File exists)
<apw> erp
<Keybuk> damnit, this feels so close :p
<Keybuk> mailed Jan + Val
<apw> you are clearly testing it far more than they
<jjohansen> apw: as I recall it, its returning that its across device, and the libc is suppose to pick that up and fallback to a copy
<apw> but one really needs the atomicity of the rename() call
<apw> so it seems safer to copy-up and restart the rename().  As i understand things rename() on things in the top layer can work
<jjohansen> apw: I haven't looked at the patches enough, but I believe last I looked it was only doing rename in the top layer if both files were in the top layer, other wise it treated it like copy up
<jjohansen> s/enough/recently
<apw> right, i believe it will rename if the file is already up
<jjohansen> I remember this being explicitly mentioned as a problem
<jjohansen> that is possible
<Keybuk> apw: I'm running apt-get dist-upgrade in the chroot
<Keybuk> it's a pretty mean and unforgiving test
<apw> so i think triggering a copy up, then returning ERESTART should trigger a new rename() from glibc and that should succeed
<jjohansen> of course I could be mixing up aufs or unitionfs with union mounts, I spent more time in them
<apw> i've suggested it to the authors, they can tell me why it would not work
<jjohansen> apw:  is the error EXDEV
<apw> i believe so yes
<jjohansen> yeah, that is the error for moving files across a device
<apw> Keybuk, that is very brave ... i am expecting you to have nothing left :)
<Keybuk> which you are, obviously
<Keybuk> though in practice, it should be a copy and a whiteout
<apw> is your machine still with us?
 * Keybuk decides to leave the "kernel panic on umount" bug for later
<Keybuk> apw: sure
<Keybuk> while, yes, I agree with Jan that POSIX does say that rename() might fail ...
<invisibill> Hi again:  can someone tell me what the difference between running 'fakeroot debian/rules binary-modules-rt' and 'fakeroot make-kpkg âinitrd âappend-to-version=-me1 kernel_image kernel_headers' ? 
<TheMuso> rtg: Ok I'll hopefully get to revising the ports configs stuff this evening.
#ubuntu-kernel 2009-06-19
<nick_schembri> Can anyone point me to the status of aufs and it's replacement?
<dtchen> ubuntu status and/or upstream status?
<dtchen> as far as ubuntu is concerned, it's gone from karmic
<dtchen> it was turned down from upstream recently, too
<nick_schembri> that is sad. :(  can you point me to the replacement?
<dtchen> nick_schembri: whatever Fedora/Red Hat is using
<nick_schembri> peter graner talked about dm-snapshot.  I'm just trying to make sure I get the correct project.
<dtchen> that's correct
<nick_schembri> dtchen: thanks for the help.
<dtchen> nick_schembri: yw
<cwillu> question:  the mainline daily ppa hasn't had an i386 build show up in nearly a week
<cwillu> is that known?
<johanbr> cwillu: what happened with your kernel lockups?
<cwillu> johanbr, nothing yet really
<cwillu> johanbr, although kms screws up suspend even quicker :p
<johanbr> :)
<johanbr> did you try the older kernel with newer userspace?
<cwillu> ya, that seemed to work fine, although I didn't run it for more than an hour or two, and I've had the newer kernel work that long once in a while
<cwillu> I'll try that again tomorrow for work
<johanbr> alright
<cwillu> latest daily that has an i86 panics on boot with a allocation of page_cgroup was failed
<johanbr> oh
 * cwillu boots a mainline-ppa 2.6.29
<cwillu> oh right, I remember why I hadn't tried 2.6.28 during a full work day
<cwillu> ext4 delete crasher :)
<cwillu> although that didn't exist in the mainline 2.6.28, so I'll grab one of those
<cwillu> 2.6.29-020629 looks good so far
<solarion> So I have in my hands at least partial docs for programming a programmable HD DSP/Amp from AMD's HTPC platform.  Where should I start looking for coding up a driver for it?
<solarion> is there any sort of ALSA interface for programming a programmable dsp?
<solarion> looks like it's controlled over the HD Audio bus; where do I find docs on using it?
<cwillu> johanbr, 2.6.29 seems to be working, I'm going to try that one tomorrow unless it gives me some trouble tonight
<johanbr> alright
<johanbr> good luck
<cwillu> johanbr, quick question (I'm on my way out, but I'll read when I'm back), if this 2.6.29 works, am I in bisect-land, and if so, should I be bisecting between 2.6.29 and an early 2.6.30, or is there a better starting point?  (I remember you saying something about big suspend changes landing early on)
<zeroprog> hey guys when trying to write a driver for an undocumented piece of hardware where should i begin in the reversing process
<AceLan> zeroprog: what kind of driver? and what's its interface?
 * apw wonders how Keybuk's machine is ...
<apw> there must be communities who specialise in the reverse engineering process.  i think nouveau was whole reverse engineered from the hardware.  they may be a good group to approach
<Keybuk> apw: still trying to work out why these renames fail
<apw> Keybuk, which renames, i thought all should fail pretty much
<Keybuk> since it should be a rename of something on cow to something else on the cow
<Keybuk> well you should be able to create a new file, then rename it elsewhere, no
<apw> yeah that is true, and those don't work either?
<Keybuk> that's what I'm investigating
<Keybuk> it seems not
<apw> t
<apw> that would be limiting indeed
<Keybuk> apw: of course, this could be an APT bug, arguably
<apw> you would think that apt would have hit this issue before
<Keybuk> dunno, I can't work out what it's doing at the moment ;)
<Keybuk> the syscalls don't make much sense
<apw> heheh .... if you can't figure it out we are in a lot of trouble :)
<Keybuk> Invalid cross-device link (/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_karmic-security_Release -> /var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_karmic-security_Release).
<Keybuk> now
<Keybuk> correct me if I'm wrong
<Keybuk> but aren't those the same path?
<soren> Their md5sum is identical, at least.
<apw> to my eye yes
<mvo> interessting behaviour
 * Keybuk clears out partial and tries again
<Keybuk> ok, I get a different error now
<Keybuk> apt clearly has a bug there, it's just one you can only hit if you first experience the failure mode of a union mount <g>
<Keybuk> I clearly need a smaller test case than apt
<Keybuk> haha
<Keybuk> strace strace ...
<Keybuk> gives unexpected output ;)
<Keybuk> iiiiiinteresting
<Keybuk> I think they just didn't bother to implement rename at all ;)
<Keybuk> root@union:/# echo "foo" > a_file_in_the_cow
<Keybuk> root@union:/# ./overwrite a_file_in_the_cow
<Keybuk> rename: Invalid cross-device link
<Keybuk> apw: see my mail ;)
<Keybuk> it shouldn't be a problem for rename ("some_path", "some_path.bak") to fail
<Keybuk> because apps doing that should
<Keybuk>  a) check the return value and cope
<Keybuk>  b) not do that
<Keybuk> but the other three rename()s I highlighted there should work, because they're not doing much cross-device
<apw> yeah i think the first one they lilley don't support, but it sounds like a sane description in tha tyou can do it all at the top level only ever looking at the toplevel
<apw> the other two sound like bugs, but i think there is rename code in there
<apw> so it must be broke
<Keybuk> yeah
<Keybuk> it should be easy enough to do
<Keybuk> if source is on the top layer, the rename() should always be permitted
<apw> yeah that i think makes sense
<Keybuk> if source is on a lower layer, the rename() should return EXDEV
<Keybuk> if the source is on the top layer, and there's something of the same name on a lower layer, the rename() should be permitted and leave a whiteout in the old location
<Keybuk> (otherwise you could overwrite a file on the top layer, rename() it, and suddenly the old file comes back)
<apw> its likely you could _always_ leave a whiteout, so you don't have to check the lower level
<Keybuk> true
<apw> though i think once the names are copied up the first time, they directory becomes opaque anyhow
<apw> there is some mind bending optimisation in there
<Keybuk> rename(src-on-lower, dest-on-upper) can't work because you need to copy up
<Keybuk> but that's ok
<apw> sounds like we might be able to live with that
<apw> that the critical erm atomics are top to top only
<Keybuk> right
<Keybuk> I'd be interested if anything is actually trying the other form of rename()
<Keybuk> since it shouldn't
<apw> right other than mv
<Keybuk> you shouldn't rename() files to ".bak" because you end up with the permissions round the wrong way
<apw> and it really should cope
<Keybuk> you should create .bak and copy into it before trunc()ing the original
<Keybuk> and if you have a genuine reason to rename() a file, you should at least cope with EXDEV ;)
<cwillu> Keybuk, I'm curious: how does that interact with the ext4 delayed allocation semantic workaround?
<cwillu> i.e., does it still trigger an implicit fsync, or does that end up looking like something else?
<Keybuk> cwillu: ?
<Keybuk> -ECONTEXT
<apw> +       /* renaming on unions is done by the user-space */
<apw> +       error = -EXDEV;
<apw> +       if (is_unionized(oldnd.path.dentry, oldnd.path.mnt))
<apw> +               goto exit5;
<apw> +       if (is_unionized(newnd.path.dentry, newnd.path.mnt))
<apw>                 goto exit5;
<apw>  
<apw> Keybuk, dispite the commentry in the patches saying that this is supported it appears that rename is simply not supported at all, fail.
<cwillu> Keybuk, currently with ext4, if you rename over top an existing file, you get an implied fsync of the new contents.  This 'fixes' the empty-file-after-a-crash bug that people complained about
<apw> ext4 does not support union
<Keybuk> cwillu: this is all done at the VFS level
<apw> its ext2 and tmpfs only right
<cwillu> sorry, I didn't read enough scrollback.  I thought you were discussing application behaviour, not unions
<Keybuk> cwillu: if you were using an ext4 top layer, and both the source and destination were on that, its semantics would apply
<Keybuk> apw: I didn't think the patches were ext2 specific
<apw> the upper level fs has to have the ability to support whiteout entries
<apw> and i only see patches for tmpfs and ext2 for that
<Keybuk> ext4 is based off that ext2 code though, right?
<apw> i don't think it is in this context
<apw> but we should ask.  for our use cases i don't think we care
<apw> as any volatile and any non-volatile upper layer is fine
<Keybuk> right
<Keybuk> yeah looks like it's ext2 only - but relatively trivial to patch to ext3 and ext4 later
<apw> yeah and for the two uses we absolutly need for this work for karmic i think tmpfs and ext2 would be fine right?
<Keybuk> yes
<Keybuk> though I think the existing COW is ext3
<Keybuk> which briefly surprised me
 * Keybuk tries to remember whether USB and journalling filesystems are friends or enemies
<apw> its all very perplexing
<Keybuk> Eurasia!
<Keybuk> Subject: Re: [PATCH 15/32] union-mount: Documentation
<Keybuk> Message-ID: <20090618190558.GB22206@shell>
<Keybuk> apw: val posted the old rename() patch to lkml
<Keybuk> might be worth looking at
<Keybuk> see if it's possible to keep rename() on top layers without the copy-up
<apw> yeah i think your minor exceptions would be implementable as they occur in one layer only
<apw> Keybuk, well it still seems to apply to the current stack, i'll apply it and get a kernel building and we can see what happens
<StevenK> apw: I was curious if it has been accepted upstream
<apw> vfs union-mounts ?
<apw> not yet, they are still being developed, i think they were given the nod as the right approach
<StevenK> apw: Yup
<apw> which is more than half the battle
<apw> they seem much less invasive than the alternatives to my eye
<Keybuk> plus aside from a few minor issues, they work
<StevenK> Well, so did aufs :-P
<apw> yeah that they are this close to working so soon is always a good sign
<apw> cirtainly worth us spending a few man days playing with anyhow
<apw> Keybuk, i do wish .deb's were rsyncable
<Keybuk> you can make them rsyncable
<apw> i can?  how?
 * apw slobbers at the thought
<Keybuk> there's a patch to add it directly to dpkg
<apw> oh hrm. so not just a simple option then
<Keybuk> you can manually recompress a .deb after making it with gzip --rsyncable as well
<apw> oh now that i would be happy to do
<apw> is that documented anywhere/so obvious i should know
<StevenK> apw: ar x .deb
<StevenK> gunzip *.tar.gz
<Keybuk> ar p THINGY.deb | gunzip -c | gzip --rsyncable > data.tar.gz
<StevenK> gzip --rsyncable ...
<Keybuk> ar r THINGY.deb data.tar.gz
<Keybuk> err
<Keybuk> ar p THINGY.deb data.tar.gz | gunzip -c | gzip --rsyncable > data.tar.gz
<Keybuk> obv
<apw> heh thanks both, will give it a go
<apw> these 28 min uploads are killing me
<ivoks> anyone around?
<ivoks> i'm looking at linux/connector.h in karmic
<ivoks> shouldn't connector unique ids be uniq?
<ivoks> i remember having problems with drbd when it had the same cn_idx as v86d
<ivoks> both modules couldn't be loaded at the same time
<ivoks> actually, they could, but only the first one loaded worked, and the other didn't
<ivoks> by bad, they are unique :)
<apw> Keybuk, ok finally got that rename patch to build at least, so i've uploaded it to the same PPA.  should be there in an hour ish
<Keybuk> apw: tvm
<apw> its taken me an hour to get the PPA to accept it, what a waste of time
<apw> Keybuk, actually waht arch are you testing
<Keybuk> i386
<apw> i'll get you a dirty binary from my build farm ... much quicker
<apw> getting overly into PPAs and actually they are slowing me down
<rtg> apw: just sent you a note about GEM/PAE. Have you any test results from your patch set?
<apw> not seen anything will poke them
<mdz> is the kernel packaging (debian/ dir) kept in git as well?
<rtg> mdz: yes
<mdz> rtg: thanks.  so if I have a packaging patch to submit, I should do it the same way as one would a kernel code patch?
<rtg> mdz: exactly
<lionel> Hi all. Digging with a collegue of mine today on bug #243393, we found that a one line fix (removing a warning) could fix it. Do you think this low risk fix could be integrated in the next hardy SRU kernel upload?
<ubot3> Malone bug 243393 in linux "dmesg is flooded with warnings in kvm/mmu.c" [Low,Fix released] https://launchpad.net/bugs/243393
<rtg> mdz: as an example, see how Luke has done it for the ports config changes: 'git://kernel.ubuntu.com/themuso/ubuntu-karmic.git master'
<smb> lionel, In general it could. But as this is a WARN_ON it needs to be made clear this is not just shutting the eyes in the face of some evil...
<lionel> smb: agreed, but considering that it is now what's is done on newer kernel
<lionel> smb: the problem is that is fill partitions (10GB of logs here for this :()
<mvo> for me the crashkernel functionatlity is not work (bug #389449 and possible #364414) - is that a known issue?
<ubot3> Malone bug 389449 in linux "linux-crashdump not working: "crashkernel reservation failed - memory is in use" " [Undecided,New] https://launchpad.net/bugs/389449
<smb> lionel, Well in that case, if you can provide that patch from upstream with an explanation on why and send it to the kernel-team mailing list.
<lionel> smb: Ok, will do, thanks !
<Araneidae> Wondering where my RAM has got to: have 3GB installed, but Linux (and Memtest) only recognises 2.5G!
<Araneidae> /proc/iomem tells a curious tale, not really sure how to interpret it...
<apw> Keybuk, ok ... http://people.ubuntu.com/~apw/vfs_union10-karmic/
<Keybuk> apw: if my computer burns, you owe me a new one :p
<Keybuk> which reminds me, wonder what happened to the one pgraner was supposed to have sent me
<apw> Araneidae, look at the e820 section of the dmesg output, tells you where your ram is
<pgraner> Keybuk: I haven't sent it yet. My wife packed it my mistake (we are moving houses) and I will get it next week. Once that happens I'll drop it in FedEx.
<pgraner> Keybuk: Sorry I forgot to mention it to you earlier
<Araneidae> apw, it's a bit all over the place -- and it's not all there!
<Keybuk> ahh, no worries
<Keybuk> not in any rush, just wondered whether the postman had stolen it ;P
<Keybuk> or customs
<apw> Araneidae, paste the e820 in a pastebin
<Araneidae> http://pastebin.com/d24698a24
<Araneidae> That's the first page of dmesg
<Araneidae> I was kind of hoping 00000000 - bfffffff, but I guess that was too simple minded of me
<sbeattie> smb|ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/330824/comments/191 should probably get on your radar (as a separate bug)
<ubot3> Malone bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,In progress] 
<ogasawara> sbeattie: thanks
<Araneidae> apw, am I just at the mercy of my BIOS here? 
<apw> Araneidae, uless some of the ram has been shifted over 4GB cause of the other stuff
<apw> you might try booting with a pae kernel (like the server one) and see if its there
<smb> sbeattie, Thanks. Yeah should be there
<Araneidae> Well, there's something funning going on -- when I tried Memtest86+ it also showed 2.5G; if I tried reconfiguring memory it crashed!
<Araneidae> Probe => black screen; All BIOS => many memory error messages then hang
<apw> define reconfiguring memory
<Araneidae> On the Memtest86+ screen it offers a couple of menu options, one is "c" => "Configure Memory"
<Araneidae> This then offers a menu with a number of options, including "All BIOS" and "Probe" as well as the subset it had selected.
<Araneidae> Unfortunately I'm wholly unfamiliar with this tool!
<Araneidae> and with the BIOS interface it's using
<mdz> is linux-meta in git as well? or just in the archive?
<apw> mdz, in git as well, in the ubuntu/ubuntu-series-meta.git
<smb> mdz, it is in git
<Araneidae> I'm guessing my motherboard is messing me about; don't know if the kernel can do any better with what it's being told.
<mdz> apw: can you translate that to a URL for me?  I tried git://kernel.ubuntu.com/ubuntu/ubuntu-series-meta.git but that  fails
<apw> if the memory is mapped high, and that happens often when you get abover 3GB then the kernle won't see it unless its PAE enabled
<mdz> apw: oh, series=karmic
<apw> mdz s/series/karmic/ etc
<apw> i should have said -<series>-
<Araneidae> Is the Ubuntu stock kernel not PAE enabled by default?
<smb> only the server kernel
 * Araneidae is running Ubuntu 9.04 "out of the box"
<apw> no, we will have it avilable in karmic
<Araneidae> Ahhh
<Araneidae> Is there a simple package to switch to PAE?  Not that keen on maintaining a separate kernel build on this machine...
<ogasawara> sbeattie: just fyi I created - https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/389555.  also posted a comment to 330824
<ubot3> Malone bug 389555 in linux "[PATCH] ext4 filesystem corruption" [Undecided,Fix released] 
<apw> you can install the server kernel
<Araneidae> Package linux-server ?
<apw> linux-image-server
<mdz> apw: so I have an ubuntu-karmic tree and an ubuntu-karmic-meta tree containing local changes which I would like to submit to the kernel team for review.  what's the best way to do it?
<mdz> commit and then format-patch?
<Araneidae> Guess linux-server is a meta-package, it depends on linux-image-server and linux-restricted-modules-server
<apw> yeah thats the simplest 
<rtg> mdz: the simplest is 'git format-patch -1 <SHA1>', then email it
<apw> Araneidae, that will do the trick then
<Araneidae> Ach: "There can be issues with third party drivers and the server kernel (specifically, nvidia drivers)".  I'll have to suck it and see, I guess...
<Araneidae> Can anybody here run `cat /proc/uptime` on a 2.6.30 kernel and tell me what it says?
<apw> apw@dm$ cat /proc/uptime 
<apw> 270380.70 254.39
<Araneidae> Is that second, very small number, a likely measure of idle time on that machine?
<Araneidae> If not, /proc/uptime is *still* broken
<Araneidae> My patch didn't make it in...
<apw> i'd say its a load average
<Araneidae> No, it's meant to be cumulative idle time.
<apw> but i don't know
<Araneidae> Always was up to .28
<apw> then its broken
<Araneidae> Well, damn.  I'll have to try prodding everyone who was cc'd before on this.  Dammit, I thought it went in.
<apw> Araneidae, what was the title of the bug
<apw> patch eve
<apw> even
<Araneidae> hang on, I'll try and hunt out the thread
<apw> smb, dunno if you watching the release meeting, they are on hardy .03
<smb> apw, thanks missed it
<smb> apw, Thought after kernel team it is done... :-P
<apw> heh me too
<apw> just luck its in another window so i saw it
<Araneidae> This was my repost of the patch: http://marc.info/?l=linux-kernel&m=124265309620490&w=2
<Araneidae> There was quite a lot of traffic with titles: "linux-next: cputime tree build warning" and "[GIT PULL] cputime patch for 2.6.30-rc6"
<mdz> apw: I've attached two nearly-trivial patches to bug 382115 which fix it (and bug 247517)
<ubot3> Malone bug 382115 in linux "Consider building unversioned linux-doc package" [Wishlist,Triaged] https://launchpad.net/bugs/382115
<ubot3> Malone bug 247517 in linux "linux-doc-2.6.26 unnecessarily conflicts  with other linux-doc packages" [Medium,Triaged] https://launchpad.net/bugs/247517
<Araneidae> The build warning was an annoying accident, which probably didn't help it.
<apw> mdz, thanks for those
<mdz> apw: is it sufficient to attach them to the bug, or would it help if I sent them to the mailing list?
<apw> if you have time to send them to the mainling list then they'll get sorted sooner
<mdz> apw: done
<apw> thanks
<rtg> apw: one of the things mdz's patch reminded me of is that we were considering the removal of generated files from the git repo, e.g., debian/control, debian/control.stub, debian/d-i/kernel, etc
<rtg> that would make some of these patches a bit simpler
<mdz> rtg: yeah, I was unsure about whether I should commit the autogenerated stuff or not
<apw> yeah i tend to send the patches without the generated stuff and let them come in automatically for that reason
<mdz> different packages handle this differently
<rtg> mdz: I usually strip that stuff out when I'm integrating the patch anyways
<mdz> if you want me to strip it out, that's easy enough
<rtg> mdz: thats ok, we can deal
<mdz> ok, thanks
<rtg> apw: so, lets try it for awhile. I'll go ahead and delete those generated files. OK ?
<rtg> that would also help a common packaging mistake where debian/control doesn't get regenerated correctly
<apw> yeah i am down with that.
<apw> as long as the packaging will clean things before making the source package we will be ok i think
<apw> there was something about control needing to be there before building the src pckg which would need testing
<rtg> apw: it does 'cause everything is dependent on debian/control
<apw> yep, so as long as dpkg-thingy doesn't need a control to exist before it hits clean we are good, and clean is the first thing in src generation
<rtg> apw: it always does a clean first
<rtg> I'll practice it to make sure
<apw> dpkg-buildpackage: source changed by Andy Whitcroft <apw@canonical.com>
<apw> dpkg-checkbuilddeps: failure: cannot read debian/control: No such file or directory
<apw> dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
<apw> dpkg-buildpackage: warning: (Use -d flag to override.)
<apw> dpkg-buildpackage: warning: This is currently a non-fatal warning with -S, but
<apw> dpkg-buildpackage: warning: will probably become fatal in the future.
<apw>  fakeroot debian/rules clean
<apw> so control may need to be there still,
<rtg> I'll work on it. 
<rtg> apw: so, I think I like the side effects of removing the auto-generated files. It pretty much forces you to generate them before you can package or build.
<apw> i can live with that, the instructions need to be 'fdr clean; debuild -s .... -sa' sort of thing i guess
<rtg> If we go forward with this patch, then we'd better mention it on the maintenance wiki
<Keybuk> apw: err, that one panic'd on boot
<apw> hrm i did what?
<apw> it even?
<Keybuk> apw: panic, on boot
<Keybuk> somewhere in populate_rootfs
<apw> before you did anything with unions ?
<Keybuk> right, before it even got as far as the initramfs ;)
<apw> well heck what did i do wrong there
<Keybuk> no idea
<Keybuk> even "ls" produces wacky output
<Keybuk> d??????? ? ?? ??  grub
<apw> there was a lot of porting forward for that patch, so i must have bust it
<Keybuk> ls: cannot access grub: File exists
<Keybuk> it looks like you screwed the VFS <g>
<apw> gurgle
<Keybuk> clearly it's that special time of the week that we call "Friday"
<apw> yeah ... clearly
<Keybuk> so I can't tell you whether the rename patch works
<Keybuk> because I can't access my filesystem <g>
<apw> Keybuk, any stack info for me from it?
<Keybuk> apw: only that it's somewhere in populate_rootfs()
<Keybuk> annoyingly someone thought the top of the stacktrace should be off the top of the screen without the ability to scroll up ;)
<apw> yeah i know ... bloody thing
<apw> its inevitably rename
<zeroprog_> if something has a usb-ttl converter(pl2303) does that mean i can use serial i/o instead of having to write a driver?
<cr3> anyone happen to have a moment to help me understand overcommitting memory? I heard that it's possible to allocate gigabytes of memory, more than what seems to fit in the void* address space. is that right?
<mjg59> cr3: No
<mjg59> Overcommit relates to whether allocated pages are backed by real memory or swap, not whether you can have more than 3GB of address space on a 32-bit CPU
<cr3> mjg59: ok, I understand the first part but not the latter part
<cr3> mjg59: to have more than 3GB, is the address still allocated on the heap somehow?
<mjg59> You can't allocate more than 3GB on a 32-bit CPU
<cr3> mjg59: my bad, I misread "not whether" as "or whether". heh, maybe it was wishful thinking :)
<mjg59> PAE means you can have more than 4GB of RAM for the platform
<mjg59> But each process can only have 3GB in its address space
<mjg59> What you /can/ do is use shared memory segments (backed by RAM) as if they're files
<mjg59> Oracle does that
<cr3> mjg59: gotcha, all makes sense again. I was given a false impression of what overcommitting really is. thanks!
<cwillu> johanbr, 2.6.29's suspend was working fine for me today under karmic's userspace
<johanbr> alright :)
<johanbr> so it's a problem with 2.6.30...
<cwillu> surprise surprise :p
<johanbr> you'd filed a bug, right?
<johanbr> did you add that information to the bug?
#ubuntu-kernel 2009-06-20
<cwillu> johanbr, I did, I haven't yet, and I will :p
<cwillu> johanbr, https://bugs.launchpad.net/bugs/380807
<ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] 
<rwlove> I was wondering if someone could help me with a SSD that is showing up in lsscsi/dmesg, but not by fdisk or the jaunty partitioner
<masterkernel> hello
<masterkernel> I am the author of KernelCheck -- http://kcheck.sourceforge.net/
<masterkernel> I need someone to package it since I can't be the maintainer since I wish to remain anonymous
<maxb> I've not noticed anything saying that you're obliged to reveal your real name when submitting a package to Ubuntu?
<masterkernel> The folks over at mentors.debian.net said nobody would sponsor my package unless I reveald my name
<ivoks> nobody in ubuntu would sponsor you packages either
<ivoks> but could you your source to build package
<masterkernel> ?
<ivoks> still, there should be copyright holder
<ivoks> s/you/use/
<masterkernel> the co-author has his real name in there
<ivoks> so he is copyright holder?
<masterkernel> and I can use the source to build the package
<masterkernel> there are two upstream authors: he and I
<masterkernel> so I guess we'd both hold copyright
<ivoks> then your name is needed
<ivoks> i guess
<masterkernel> what if I remove my name as the upstream author? i guess i'd have no rights then
<ivoks> correct :)
<masterkernel> i was in contact with a guy about a year ago who said it was possible according to the debian-legal guys, for the name Master Kernel to be the author, but I never got the specifics and we broke off
<ivoks> well, i'm not sure about the legal stuff, but i guess that copyright holder should be real person with real name
<lesshaste> hi
<NCommander> Is anyone around here good with makefiles and the kernel packaging to help me run down the ports FTBFS issue?
<dtchen> TheMuso: we should identify regressions via calls for testing of increasing the HDA prealloc buffer (/proc/asound/card*/pcm*/sub*/prealloc*, given in KiB).  At least openSUSE and Fedora increased it from 64 KiB to 2 MiB.
<dtchen> TheMuso: that change alone accounts for significantly fewer "glitch" HDA reports
<eshaase> I have Jaunty and I'd like to use 2.6.30, is it recommended that I install karmic's kernel package or should i use kernel.ubuntu.com/~kernel-ppa's?
<dtchen> eshaase: neither would be a supported configuration, but if you find you need the Ubuntu sauce, use karmic's
<eshaase> dtchen: ok, thanks
<needRS232wizard> howdy heavy hitters.
<needRS232wizard> Why would a USB serial adapter not work at bauds > 1200?  Tested on Debian Woody 3.0 and Hardy Heron (PPC and x86)?
<ppurka> can i ask a question to you devs?
<ppurka> i want to know where i can get the ubuntu specific patches for the 2.6.30 kernel
<ppurka> no one knows how to get the ubuntu specific kernel patches for the 2.6.30 kernel?
<Nafallo> !weekend
<ubot3> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<ppurka> k thx ubot3
<uart> help
<ppurka> I will try some other day
<uart> oops ^_^  thanks also to you Nafallo & ubot.
<uart> \quit bye
<ppurka> oops.. thanks goes to you Nafallo :P
#ubuntu-kernel 2009-06-21
<Nafallo> I have the same problem. never know what day it is ;-)
<masterkernel> how do I pass an option to dpkg-deb from make-kpkg?
<TheMuso> dtchen: Interesting, I guess its worth a try.
<zeroprog> hey guys is there a way to check which driver my device is using
<TheMuso> zeroprog: Depends on how the device is connected to your machine.
<TheMuso> zeroprog: If its a pci device, then "lspci -vvnn" should show you the driver associated with your device.
<zeroprog> its a usb device
<zeroprog> its an iphone if that helps
<TheMuso> zeroprog: not sure then sorry.
<zeroprog> ok thanks
<peabody> yo
<peabody> I'm trying to build a custom kernel, from the 9.04 deb packages and I've hit a snag in the documentation
<peabody> I'm following this guide https://help.ubuntu.com/community/CustomRestrictedModules to build my restricted modules
<peabody> so I did my kernel config and built my header and image packages
<peabody> but when I tried to install my image it executed /etc/kernel/postinst.d/nvidia-common exited with error code 20
<peabody> so I grabbed the restricted modules stuff, but I don't have this abi version in my debian/rules
<peabody> basically, the documentation isn't very clear what I should do next. 
<peabody> can anyone help?
<masterkernel> Hello, I am in need of a reviewer for my package, kernelcheck. It is a GUI tool that can automatically (custom) build any 2.6 kernel from the upstream source with any patches the user wants.
<masterkernel> it is on REVU.
<peabody> masterkernel: you got a url?
<masterkernel> peabody: to REVU? or the homepage?
<masterkernel> REVU: http://revu.ubuntuwire.com/p/kernelcheck
<masterkernel> Homepage: http://kcheck.sf.net/
<peabody> I'm just finishing up a new build right now, but I'll check it out
<masterkernel> just use caution if you use the nVidia option in it
<peabody> why's that? (I do use the nvidia modules)
<masterkernel> best install it yourself then. it runs a script that uninstalls everything related to nVidia, downloads the newest version, then installs that (or a kernel module if the latest binary is already installed). It doesn't use dkms
<peabody> thanks for the warning
<masterkernel> i just know i'm gonna get a lot of crap from people who don't know much about kernel modules and dkms
<peabody> it sounds like it fills a needed gap, thanks for the dev work
<peabody> of course
<masterkernel> i havent fully updated the website yet, but the latest version is 1.2.5
<peabody> I will leave you a feedback from the website, nice template ;)
<masterkernel> thanks, did that top image myself, but the theme came from freecsstemplates
<peabody> PyGTK
<peabody> boo
<peabody> can you make a QT version?
<_ruben> strange .. when i google for "ubuntu tcp_frto" .. all i get is stuff related to network printing .. where as we ran into a problem where one of customers couldnt download any large files over http from our hardy based webserver, until we set it back to the (old?) default of 0
<masterkernel> peabody: I have no idea how to use qt
#ubuntu-kernel 2010-06-21
<Sangeeth> Hello all!.. I am willing to join this team... Could someone guide me please....
<Sangeeth> Could someone help me join this team???
<Sangeeth> I had been included in this team by Tim Gardner... What's my next step?..
<ikepanhc> eh wiki.ubuntu.com no response....
<ikepanhc> Sangeeth: you may take a look at https://wiki.ubuntu.com/Kernel/ (but no response for me right now)
<ikepanhc> Sangeeth: if you have any interesting idea, you may discuss here or on kernel-team mailing list, or discuss with anyone here :)
<ikepanhc> Sangeeth: or propose any patch you think it will make Ubuntu Kernel better on kernel-team mailing list
 * ikepanhc leaves a while for lunch
<Sangeeth> I had been included in this team... Could some one explain me what's my next step...
<Sangeeth> Somebody interested... A little guidance needed here...
<JanC> Sangeeth: do you have kernel development experience?
<Sangeeth> No... But i do have some knowledge on Kernel structure and working...
<Sangeeth> JanC : No... But i do have some knowledge on Kernel structure and working...
<JanC> well, I don't have any experience like that, but you might want to look at kernel-related bugs on launchpad about things that don't work, and see if you can find a solution (and of course propose that solution then)
<Sangeeth> But, even I see some bugs, they are all completely strange to me... I need someone to guide me through the initial steps... I'm good at C , C++....
<achiang> http://kernelnewbies.org/
<JanC> the easiest bugs are those that already have a fix elsewhere, that way you can get used to how the kernel team works
<JanC> and maybe achiang can help you some more  âº
<achiang> no, sorry, i've used up my help allocation for tonight. ;)
<achiang> 22:45 here, and i'm winding down for bed.
<achiang> Sangeeth: but yeah, start at kernel newbies, and see how far you get
<JanC> achiang: meh, it's 6h45 here, so you're early to go to bed  :P
<JanC> (okay, I don't have to get up early)
<achiang> Sangeeth: actually, the suggested path to becoming a kernel developer is to get linux working perfectly on every piece of hardware that you own
<Sangeeth> achiang : What is Kernel Newbies and where could i find it...
<achiang> Sangeeth: um, did you see the url i posted about 9 lines up?
<Sangeeth> achiang : Ya... It's there...
<achiang> so go read it?
<JanC> there might be some ubuntu-kernel specific stuff too (not sure if there is a "bite-sized" or "papercut" or similar tag in LP for the kernel?)
<Sangeeth> achiang : Ok... It will be good if i am assigned with some minimal bugs in launchad... Could i get some help from you???
<achiang> Sangeeth: what is it exactly you're trying to do?
<JanC> Sangeeth: maybe check on https://wiki.ubuntu.com/Kernel/ if there is a specific tag for that
<Sangeeth> achiang : I'm new to the open source community and I would like to get involved in the Kernel, the core area, than the other areas of ubuntu... But i have no idea, where to start...
<jk-> Sangeeth: please read what JanC and achiang have wrote already, it is good advice.
<Sangeeth> achiang : I'm good at C, C++... Will that be helpful in Kernel Development or Mod...
<JanC> except the wiki seems to be down  ;-)
<JanC> Sangeeth: the kernel is in C (no C++ allowed)
<Sangeeth> JanC : Ya... :) But, no problem... I found it via cached pages of Google...
<maco> JanC: hehe which is why i still never got around to learning C++ 
<maco> and the wiki's not flat-out down
<Sangeeth> JanC : Ok... Got it... C... Then what is my next step... 
<maco> it's going in and out
<achiang> Sangeeth: like i said: start by reading every page on http://kernelnewbies.org . second, get linux working perfectly on every piece of hardware you own. once you do those two steps, you'll have a much better idea of other places you can help contribute
<Sangeeth> maco : :-))
 * maco should read that site at some point
<maco> actually should read it soon for that matter
 * ikepanhc is back and reading
<Sangeeth> achiang : What is the second you are mentioning??? I couldn't get it...
<achiang> Sangeeth: if you own a laptop (or other computer), then make sure every piece of hardware is functional. make sure things like suspend/resume work. etc.
<Sangeeth> achiang : Ok... What do you mean by suspend/resume???
<JanC> achiang: "linux" already works on all hardware I own, that's exactly why I bought the hardware to begin with, so I hope Sangeeth has more "luck"...  ;-)
<achiang> JanC: if you ask extremely broad questions, you get extremely broad answers. :-/
<Sangeeth> achiang : The page you gave me is about the general Linux Kernel... Isn't the Ubuntu Kernel a bit extended/modified from the Linux kernel???
<JanC> Sangeeth: you might want to learn to work with 'git' if you want to see the difference
<achiang> Sangeeth: there are more similarities than there are differences.
<Sangeeth> Janc : achiang : Please tell me the first step exactly to learn the Kernel of Ubuntu... Is it the Kernel Newbies...
 * achiang is getting trolled?
<JanC> AFAIK most changes are things like newer drivers
<JanC> for ALSA & wireless & such
<ikepanhc> Sangeeth: I will suggest in two ways - try to build a kernel with debian/rules command and be good in git
<Sangeeth> Janc : Ok.... Could you lead me to a simple bug, where i could learn, what actually is happening and what is to be done....
<jk-> achiang: perhaps?
<Sangeeth> ikepanhc : Build?! I'm a perfect rookie... By the way, GIT? For what it is used?
<JanC> Sangeeth: okay, start with learning get then (it's the version control system used for the kernel source code)
<JanC> s/get/git/
<achiang> jk-: maybe some AI researcher unleashed a new turing machine onto freenode
<ikepanhc> Sangeeth: Ubuntu is based on debian, and you need to install a kernel image in debian command, so you need to know how to use debian/rules to build your kernel image
<Sangeeth> JanC : ok... What is a version control system and what is the command you gave me?.. Should you use it at terminal???
 * ikepanhc agrees with JanC
<Sangeeth> ikepanhc : Could you explain it still simply...
<ikepanhc> Sangeeth: well, start from git: http://en.wikipedia.org/wiki/Git_%28software%29
<JanC> Sangeeth: there are some good introductions to git, and I would be surprised if they aren't linked somewhere from kernelnewbies and/or from the Ubuntu kernel wiki
<Sangeeth> ikepanhc : Thanks...
<Sangeeth> JanC : No worries.... I'm about to try wikipedia...
<Sangeeth> ikepanhc : Ok about GIT... But what did you said in your first point??? Some Kernel image, debian commands??? What are they???
<ikepanhc> Sangeeth: you can have git on your Ubuntu, just simply type: sudo apt-get install git-core
<Sangeeth> ikepanhc : Thanks...
<Sangeeth> ikepanhc : After I studied about GIT and other Kernel basics, to get involved in kernel dev or mod of ubuntu, where should i go...
<ikepanhc> Sangeeth: the best way to stay on this channel and subscribe kernel team mailing list
<Sangeeth> ikepanhc : Will i be assigned any bugs or modules of projects, by the team leader in launchpad???
<Sangeeth> ikepanhc : I had already subscribed and got a few audio bugs??? I was wondering, how could i give a solution....
<ikepanhc> Sangeeth: you will not, but you can assign bugs you are interested to yourself
<ikepanhc> Sangeeth: if you have a solution, you may try to post the git commit on mailing list, or to LKML
<Sangeeth> :( :( :(
<Sangeeth> What is LKML???
<JanC> Linux Kernel Mailing List
<ikepanhc> linux kernel mailing list, the mail list for upstream kernel
<JanC> if you subscribe to that, be prepared to get between 150 & 500 mails / day  ;)
<Sangeeth> JanC : Ya... I already got 5... But, what should i do to solve them??? All are ALSA bugs...
<achiang> Sangeeth: i'll say this one more time. you are asking questions that are ALREADY ANSWERED in http://kernelnewbies.org . that page provides much of the background information that you seek about kernel development. once you become more familiar with the entire process, the ubuntu-specific portions will become much more clear to you. as it is, right now, you are just wasting multiple people's time.
<Sangeeth> ikepanhc : Is the git-core, you said, is enough or should i have to install some other things???
<ikepanhc> Sangeeth: its more then enough
<JanC> Sangeeth: well, you can check if that bug is fixed in upstream ALSA, or ask the person reporting the bug to try out a more recent kernel (there are .deb packages for that in a place listed on the kernel wiki)
<Sangeeth> achiang : I'm sorry... As you describe, i'm a newbie and interested a lot on Ubuntu and its kernel... Sorry again...
<JanC> Sangeeth: don't worry, it just needs a lot of work & time to learn everything  ;)
<Sangeeth> JanC : Ok... But, how could i contribute to that bug???
<Sangeeth> JanC : like solving the bug???
<ikepanhc> the wiki seems back: https://wiki.ubuntu.com/Kernel/Dev
<achiang> Sangeeth: yes, i understand that. we were all newbies once. everyone goes through this same process. that is exactly the reason why the community created that web page. so please do read it, and it will explain quite a bit
<ikepanhc> Sangeeth: this is the major knowledge base of the kernel team, but start from the kernelnewbies.org will be a better idea
<Sangeeth> JanC : A friend of mine is working on drizzle and uploading weekly patches assigned by his mentor... How could i be possibly able to contribute like the same to Ubuntu Kernel team...
<JanC> Sangeeth: following everything discussed here & on the mailing list for some time might help too
<JanC> Sangeeth: I'm not sure there are mentors who have much time  :-/
<Sangeeth> JanC : His mentor actually is one of the developers of that project...
<JanC> although many people will be happy to answer specific questions
<Sangeeth> JanC : Isn't there any such projects undergoing in Ubuntu Kernel division???
<JanC> Sangeeth: in theory, that should be kernel-newbies  ;)
<Sangeeth> JanC : What are you exactly working at in the ubuntu kernel???
<JanC> although in many cases, the best people to ask questions are the developers of the particular driver or kernel subsystem you're working on
<Sangeeth> JanC : Whether you all in the team, divide the tasks between you or take up your own ideas and develop a patch???
<JanC> Sangeeth: i'm not, I've just been following kernel development (remember I said I didn't have real experience with kernel development?)
<Sangeeth> JanC : Ok... Have you done any patches or fixed some bugs???
<JanC> not in the kernel
<Sangeeth> JanC : In what else then???
<JanC> Sangeeth: some small things in GParted, for example, but really, that's not really related to the kernel  ;)
<Sangeeth> JanC : Ok... I know c, c++.. Is there anyways i could involve in dev/ patch dev of any apps or someother things...
<Sangeeth> ikepanhc : Installed git through terminal... What's my next step??
<ikepanhc> Sangeeth: well, https://wiki.ubuntu.com/Kernel/Dev gives you lots of information
<Sangeeth> ikepanhc : Ok... Thanks...
<JanC> Sangeeth: for things probably not related to the kernel, the patch review team might be a good place to start, I'm sure nigelb or some other person in #ubuntu-reviews could help you with that
<Sangeeth> JanC   Achiang  ikepanhc  : Thanks a lot for all your info... I gained some knowledge about how to start with my expedition on Ubuntu Kernel.... Thanks a lot, once again...:)  :)  :)
<orangey> hello all!
<orangey> I'm trying to compile a new kernel
<orangey> and I'm doing it with: sudo make -C /usr/src/linux-headers-`uname -r`  M=`pwd`
<orangey> however, it will NOT compile this new file!
<orangey> it DOES compile properly all the OLD files, though
<jk-> orangey: you added a new file? or changed an existing one?
<orangey> added a new one
<orangey> usb_wwan.c
<jk-> did you update the Makefile too then?
<orangey> yes
<orangey> I've updated every makefile I can find
<jk-> you only need to update one
<orangey> well, I updated two : )
<orangey> one in the headers directory
<orangey> and one in the directory I was working in
<orangey> if I were to get it to only compile this ONE file (it truly compiles every other one), I think I'd be home free
<orangey> thoughts?
<kraut> moin
 * apw yawns
 * smb yawns back
 * cooloney yawned 6 hrs ago
<apw> heh
<smb> No way to win this
<cooloney> lol
<apw> yay emergency budget day ... say goodbye to income
<cooloney> how's going, folks
<jk-> emergency budget day?
<smb> apw, Your MPs neet new things?
<apw> yeah we are broke, time to suck those with money harder to fix it
<smb> Heh, ours suck those with not so much money. Probably hoping they cannot afford to retaliate
 * smb waves to cking 
 * cking waves to all
<jk-> hey cking
<cking> jk-, howdy do
 * jk- is lost in a forest of topic branches
 * apw does not like the sound of that
<jk-> apw: s'ok, I won't be asking you to merge them :D
<jk-> I need a 'git replant' - like rebase, but move a set of sub-branches to a later commit
<apw> jk-, heh sounds handy
<jk-> should've taken that graph theory unit at university :D
<smb> apw, Do you know were to find entry information to JFo's community bug days? I only seem to find quite old pages.
<apw> smb, hrm no i've not remembered seeing any output regarding bug days recently
<smb> jk-, I got a rebase branch script but it might be too much geared towards releasing...
<smb> apw, Hmmm, ok. So maybe I point people asking me about contributing directly to his ... backside
<apw> smb, heheh yeah something like that
<RAOF> apw: Yo!  I'm looking at your WIs on http://tinyurl.com/24yqzyw - have you looked at them, and I want to discuss whether you think it still makes sense to do them.
<apw> RAOF, yo ...  have been meaning to talk to you about those, last i looked the patches were all over the place
<apw> have they settled down?
<RAOF> I don't think they're moving much any more, but I think that's in part because they're slightly dead.
<apw> hrm, thats not good.  if they are dead do they do us any good any more?
<apw> these were sorting out the regressed i8xx platforms iirc
<RAOF> Not all the regressed i8xx platforms, actually - there's a similar bug for i845 and i865 that I don't think the patch addresses.
<apw> i suspect i am vague enough that i am reliant on your oppinion
<RAOF> For Maverick I've got the help of an intel dev to just plain re-add the EXA acceleration stuff which isn't reliant on the AGP interface working properly (which it doesn't on the i8xx stuff).
<apw> heh, did they recently remove that?
<RAOF> No - ages ago.  In 2.9 I think, which we've carried since Karmic.
<RAOF> These i8xx problems weren't a regression in _Lucid_ , except as compared to Hardy :)
<apw> ahh i see ... so do you think we'll get them back in Maverick, i assume not, NN perhaps ?
<RAOF> I'm confident we'll get a usable -intel driver that doesn't use GEM for those cards in Maverick, yes.
<apw> i sense you are suggesting these patches are not worth persuiing ?
<apw> cirtainly any work i don't have to do is a bonus for me
<RAOF> :)
<RAOF> It might be nice for Lucid to have the v9 patch via an SRU, but I understand if that's hugely scary.  I don't think that we need to carry it for Maverick.
<RAOF> And by âniceâ I guess I mean âin the land of unicorns and unlimited kernel-team manpowerâ.
<hyperair> lol
<apw> RAOF, i have a note here which says "major pre-requisites" when i looked at it ... hmmm
<RAOF> Hm.  Dinner time!
<RAOF> apw: That might have something to do with the patch splitting the intel-agp modules into different pieces.
 * apw drops offline for a bit
<apw> RAOF, yeah there was some re-jigging for sure in there
<abogani2> What should be effetc of the "do_common_headers_indep" option?
<apw> abogani2, it defines whether the 'flavour independant headers' are generated in the binary-indep pass on i386 or in an architecture specific pass
<tseliot> apw: does it hurt if I do "debian/rules updateconfigs" after changing the code?
<tseliot> mjg59: BTW the patch works, a bug in grub2 prevented me from using acpi_osi=\"!Windows 2009\". The video switch key works fine with my patch now
<mjg59> Ha
<mjg59> Ok, excellent
<mjg59> Want to send it upstream?
<cking> tseliot, what was wrong with grub2?
<mjg59> cking: It eats the quote marks
<tseliot> mjg59: sure, I'm bugging Alex about that too. Where should I send it? (of course I'll give credit to both of you guys for your help)
<cking> doh
<tseliot> cking: yes, that's the problem
<tgardner> apw, this is quite a handy reference: http://book.git-scm.com/index.html, I didn't realize it existed.
<smb> tseliot, When you did not change any options it should not hurt. But you can check afterwards with git status to see if it has. The stuff in debian.master/configs should be unchanged
<mjg59> tseliot: drm-devel@lists.freedesktop.org
<mjg59> tseliot: You'll need to send it with a Signed-off-by: line. See the SubmittingPatches doc in the kernel source.
<tseliot> smb: ah, ok. I was only asked about external firmware support when I ran that command (and I pressed Enter)
<tseliot> mjg59: ah, drm-devel, not dri-devel?
<smb> tseliot, If you get asked then it likely changed something.
<mjg59> tseliot: Sorry, dri-devel, yeah
<tseliot> smb: that's what I thought
<tseliot> mjg59: ok, I'll send it there then, thanks again for your help. It's been a good learning experience for me
<tseliot> mjg59: does this commit comment look good to you? http://pastebin.ubuntu.com/452930/
<mjg59> Yeah, sounds fine
<tseliot> good
<mpoirier> ogra ?
<JFo> bjf, you around?
<bjf> JFo, yup
<JFo> just saw the tag kernel-workflow. what is that?
<bjf> JFo, not me
<JFo> hmmm
<bjf> JFo, going hunting in the scripts
<JFo> looks like the new script added it
<JFo> Bug 592039
<ubot2> Launchpad bug 592039 in linux (Ubuntu) "Please enable vmware-balloon driver in kernel config (affects: 1) (heat: 387)" [Undecided,New] https://launchpad.net/bugs/592039
<JFo> err rather process-new
<bjf> JFo, i just grep'd the scripts on my system and didn't find that string
<JFo> interesting
 * JFo digs
<bjf> JFo, i'm pulling down a new version
<JFo> k
<bjf> JFo, not found
<JFo> very odd
<JFo> because it is saying it was added by me along with a kj-triage
<JFo> which means it is a script doing it
 * JFo digs further
<bjf> JFo, we do look for a "workflow" tag but we don't add one
<JFo> very odd
<bjf> JFo, grep your scripts for it
<JFo> I am
<JFo> none have it
<ogasawara> aight, dudes we need a status check for A2 work items (ie will they be done or not in time for the milestone)
<ogasawara> apw: review the i8xx patch ?
<ogasawara> apw: produce a PPA for the i8xx patch to allow testing?
<ogasawara> apw: enable linux-tools for mainline builds
<ogasawara> apw: help abogani mockup -preempt derivative for universe?
<ogasawara> apw: Address assigned set of Ubuntu Patches?
<ogasawara> apw: evaluate union-mount as a replacement for AUFS?
<ogasawara> apw: investigate whether upstream would accept mounting /proc and /sys automatically ?
<ogasawara> apw: I imagine some of those can be pushed to A3 as they're not A2 release critical
<apw> ogasawara, yeah let me get at the list and push some out
<ogasawara> apw: sweet, thanks
<ogasawara> cking: Investigate situation with Intel graphics drivers on EFI? Will we be able to mark that work item complete by A2?
<ogasawara> cnd: LP: 333990 : [Karmic]Please enable PCI express ASPM (powersave) (pm-utils-powersave-policy) ?
<ogasawara> cnd: seems you're working on that bug, think the fix will land in pm-utils by A2?
<ogasawara> bug 333990
<ubot2> Launchpad bug 333990 in linux-2.6 (Debian) (and 4 other projects) "[Karmic]Please enable PCI express ASPM (powersave) (affects: 3) (heat: 28)" [Unknown,Unknown] https://launchpad.net/bugs/333990
<ogasawara> hrm, no bot
<ogasawara> manjo: blacklist old firewire stack & enable new stack ?
<ogasawara> manjo: add basic tests to kernel-qa to test new firewire stack.
<ogasawara> manjo: how's the firewire stack changes coming?
<cnd> ogasawara: for the ASPM bug, the fix will come in the form of a new version of pm-utils
<cnd> the new version was just released this weekend
<ogasawara> cnd: cool
<cnd> as soon as debian packages it, we can copy it over
<cnd> but I don't know if that will be before A2
<tgardner> cnd, debian sync is done on thursday, so likely not
<ogasawara> cnd: sounds like it's on it's way, so we can push to A3 if we have to
<cnd> at the same time, we will have to deprecate pm-utils-powersave-policy
<Q-FUNK> apw: about bug #241307 why did you unsubscribe yourself?  Plenty of info was provided to track the source of the issue, down to a specific release with the exact diff.
<ubot2> Launchpad bug 241307 in linux (Ubuntu Hardy) (and 1 other project) "[Geode SC] [DBE60] kernels >= 2.6.22 fail to boot [A20 interrupt] (affects: 5) (heat: 32)" [High,New] https://launchpad.net/bugs/241307
<ogasawara> JFo: your work items for the firewire stack are likely dependent on it being enabled in time for A2, so I might retarget those to A3
<apw> Q-FUNK, i unsubscribed myself because I didn't have time to work on the 159 bugs I had ended up subscribed to, it was giving a false impression i was working on them and preventing anyone else in the team looking at them
<JFo> ogasawara, sounds good :)
<JFo> thanks for letting me know 
<Q-FUNK> apw: ok. fair enough.  it's just that it becomes rather frustrating to file bugs, get involved in tracking down the cause and not see the bug acted upon.
<JFo> ogasawara, are those on a blueprint somewhere?
<ogasawara> JFo: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack
<JFo> thank you :)
<apw> Q-FUNK, i cannot disagree with you there, i block unsubscribed to bugs I had not touched for months, there was no thought involved
<Q-FUNK> apw: understood. :)  my comment mostly was about how some bugs simply never get acted upon.
<apw> Q-FUNK, though the last commentary i can see in there says that commenting out some code used to work but doesn't
<apw> anymore, so its not clear we have a real fix in there
<Q-FUNK> apw: right, because there's been more drastic changes to that code since then, so we can no longer revert a specific commit.
<Q-FUNK> apw: which is only predictible.  the longer it takes to react to a bug, the higher the probabilities that upstream furhters hacks the code to a point where reacting becomes a PITA.
<apw> Q-FUNK, indeed sadly.. not having such a beast makes it hard to debug
<apw> Q-FUNK, i think i replied to you on another of your bugs just a sec ago, completley unrelated, about /proc/config.gz
<Q-FUNK> apw: yes, you did and I responded. :)
<apw> smb, you got a hardy install ?  can you check your /boot/configs-* are full configs for me
<apw> Q-FUNK, cirtainly all the ones  I have access to here are complete
<Q-FUNK> ogasawara: I noticed that you added a task to the libc6 blueprint.  is this about merging the NOPL patch?
<smb> apw, I got one. Give me a min to boot up
<ogasawara> Q-FUNK: we're not quite sure what that work item will entail as the spec/blueprint it not yet written, ie i'm blocked
<apw> smb, the ones on chinstrap look to be complete
<Q-FUNK> ogasawara: I'm rather worried to find that i686-only libc6 binaries have already been pushed and approved, despite a lack of complete paper trail.
<ogasawara> Q-FUNK: you probably want to take it up with doko as it's his spec
<Q-FUNK> ogasawara: I did. his response wasn't too cooperative.
<ogasawara> Q-FUNK: not sure what you'd like me to do about it?
<smb> apw, There is lots of stuff in there. Anything that would indicate not-full configs?
<Q-FUNK> ogasawara: since one of the possible solutions seems to be to merge a kernel patch to emulate the mission CPU instruction, I think that this is something that you could affect?
<mjg59> A kernel patch that's been rejected by upstream
<Q-FUNK> mjg59: without much of any justification, at that.
<ogasawara> Q-FUNK: possibly, but until I see them make that request I'm not going to act on it
<apw> as in a patch to emulate CMOV or whatever ?
<Q-FUNK> ogasawara: noted.
<Q-FUNK> to emulate NOPL
<apw> presumably they said, just compile your kernel for i586, and rejected it
<Q-FUNK> http://marc.info/?l=linux-kernel&m=126748102722641&w=2
<mjg59> apw: Upstream doesn't want single-issue emulation
<mjg59> They want a more generic framework
<Q-FUNK> it's a chicken and egg case. either fix gcc to stop using NOPL with -m686, fix libc6 to produce finer optimization that won't break support for Geode, or patch the kernel to emulate the missing instruction.  
<apw> ahh the perfection argument
<Q-FUNK> right now, everyone is throwing the baby around.
<mjg59> It's not actually gcc that's the issue - it's binutils
<Q-FUNK> upon initial reading, it indeed seemed to be GAS.  now, I'm not so sure.
<Q-FUNK> these guys have encountered the same issue and have a whole thread about it:  https://bugzilla.redhat.com/show_bug.cgi?id=579838
<ubot2> bugzilla.redhat.com bug 579838 in glibc "glibc not compatible with AMD Geode LX" [Medium,Assigned]
<Q-FUNK> the plethora of related discussions this bug links to is fascinating.
<ccheney> is jjohansen working today?
<ogasawara> jjohansen: I was just doing a quick status check for A2 work items, just want to get some quick updates from you if the following will be done by A2:
<ogasawara> jjohansen: update compatibility patch for old kernel interface (kernel-maverick-apparmor)
<ogasawara> jjohansen: sync distro apparmor to upstreaming version of apparmor (kernel-maverick-apparmor)
<ogasawara> jjohansen: Refresh Xen patchset and get xen version of EC2 kernel working in Maverick (kernel-maverick-pv-ops-ec2-kernel )
<jjohansen> ogasawara: You'll get the Xen patchset today I've got some testing and cleanup todo
<jjohansen> ogasawara: and then I will finish up the AA testing and you should get the rebase tomorrow
<ogasawara> jjohansen: cool
<JFo> tgardner, http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
<sconklin> smb: http://people.canonical.com/~sconklin/radeon_flicker/
<sconklin> smb: for some of these, it is also reported that booting with radeon.new_pll=0 solves the issue
<sconklin> smb: so please  try the test kernel and the boot option, but not both together
<smb> sconklin, Ok, made note of both and will try maybe tomorrow
<sconklin> smb: thank you
<manjo> cking, around ? 
<cking> manjo, still around dude
<manjo> cking UEFI Banter ?
<manjo> cking,  UEFI Banter ?
<cking> manjo, hold on a sec.. firing up
<manjo> cking, can you hear me ? 
<cking> nope - can you hear me?
<manjo> yes
<manjo> let me check my audio settings
<manjo> s**t its broke
<cking> urgh
<manjo> ok anyway
<manjo> the current ISO does not boot 
<manjo> it shows the initial splash and then a blinking cursor 
<manjo> cking, any thoughts ? 
<cking> urm, did any previous ISO boot?
<manjo> yes from previous week
<manjo> the iso I tried on sat also had the same issue
<cking> manjo, which ISO image is this
<cking> ?
<manjo> amd64
<cking> ok - and when did you download it?
<manjo> with grub-efi
<manjo> this am
<manjo> this iso is suppsed to have the new installer changes
<cking> lemme download and see
<manjo> but you don't have uefi do you ? 
<cking> meanwhile can you roll back to a previous version and do the install manually
<cking> manjo, I have VirtualBox
<manjo> cking, ah
<cking> gonna take me 12 mins to download it
<cking> manjo, when did install changes land?
<manjo> cking, I believe this weekend/this morning 
<cking> manjo, where are you now locale-wise?
<manjo> cking, still in TX will catch a plane this afternoon 
<cking> manjo, you think this is specific to the ISO image changes with the installer?
<manjo> cking, no not sure 
<cking> manjo, today's ISO may not fit on a 700MB CD-ROM, so that may be an issue
<manjo> cking, no I stripped off some packages like openoffice to make it fit, 
<manjo> my iso is 633 only
<manjo> cking, once I boot the live CD is there any way of telling what my grub env settings are ? the grub tool to modify env block does not list anything 
<cking> manjo, not sure what you mean by "env block"?
<manjo> grubenv 
<manjo> GRUB Environment Block
 * cking looks on google...
<apw> http://tools.ietf.org/html/draft-ietf-softwire-ipv6-6rd-10
<JFo> <-lunch
<cking> manjo, hrm, downloaded and got it to boot in my system. Dunno why it hangs on your box
<cking> lemme do a full install an see what's cooking
<manjo> cking, this is with efi grub ? 
<cking> doing an EUFI install now
<manjo> cking, let me download the iso again... May be zsync corrupted my iso... 
<cking> maybe, hard to tell at this point
<cking> md5sum is your friend
<cking> manjo, you tested it on the box I sent you?
<manjo> yes
<cking> urm, well, maybe worth booting with acpi=off if you see these issues again on real H/W 
<cking> if that fails, revert back to plan B - karmic and hand install 
<manjo> cking, I have a maverick based iso that boots, just that the recent iso does not boot for some reason
<manjo> the recent iso has 2.6.35 kernel and the new installer 
<cking> manjo, well, maybe asking cjwatson - he's got H/W very recently so things may change very rapidly over the next few days
<manjo> cking, I suspect it is a grub issue so building another iso with hacked grub env options 
<cking> manjo, unless one installs on the older ISO, updates the kernel and then see's it die - that will show if it's the kernel or not
 * tgardner lunches
<JFo> apw, are you waiting for me on something for permissions on the kernel-ppa for the testing dir??
<JFo> if that sentence makes any sense
<apw> JFo, nope, i have it prototyped and 'working' just not written it up and passed it over to you and bjf
<JFo> ah, cool
<jjohansen> -> Lunch
<bjf> tgardner, ?
<tgardner> bjf, ?
<ogasawara> ogasawara@tangerine:~$ mkdir maverick-amd64
<ogasawara> mkdir: cannot create directory `maverick-amd64': Permission denied
<ogasawara> tgardner, bjf: ^^?
<tgardner> ogin $HOME ?
<tgardner> ogasawara, in $HOME ?
<ogasawara> tgardner: yep
<bjf> ogasawara, all home dirs owned by root
<tgardner> I guess that makes sense since they are all root.root
<JFo> X/
<tgardner> ogasawara, gimme a bit....
<ogasawara> tgardner: thanks
<bjf> tgardner, hmm, was saying that on mumble but I guess my mumble session is busted
<JFo> apw, if you are still around, mind commenting on bug 538648
<ubot2> Launchpad bug 538648 in xserver-xorg-video-intel (Ubuntu) (and 2 other projects) "[Intel GM45] Irregular sync flashes on 8086:2a42 (Needs i915.powersave quirk) (affects: 63) (dups: 6) (heat: 392)" [Medium,Invalid] https://launchpad.net/bugs/538648
<JFo> apparently a test kernel you gave them does the trick
<tgardner> ogasawara, try now
<ogasawara> tgardner: works now, thanks
 * ogasawara lunch
<JFo> ogasawara, when you return from lunch :) bug 589439
<ubot2> Launchpad bug 589439 in linux (Ubuntu) "configuration gotchas with Maverick 2.6.35 kernel... (affects: 1) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/589439
<JFo> looks interesting to you
<JFo> hopefully
<JFo> cnd, you around?
<cnd> yep
<JFo> could you take a quick look at bug 579783
<JFo> cnd ^
<ubot2> Launchpad bug 579783 in linux-firmware-nonfree (Ubuntu) "Hauppauge hvr-2200 firmware not included (affects: 2) (heat: 95)" [Undecided,Triaged] https://launchpad.net/bugs/579783
<cnd> JFo: yep
<JFo> thanks :)
<cnd> I periodically get to the firmware bugs
<JFo> cool
<JFo> bjf, do you still want bug 279102 assigned to you?
<ubot2> Launchpad bug 279102 in linux (Ubuntu) (and 1 other project) "Unreliable network connection with B44 driver (affects: 17) (dups: 3) (heat: 134)" [Medium,Triaged] https://launchpad.net/bugs/279102
<bjf> JFo, no, i made it unassigned
<JFo> cool
<JFo> just wanted to check :)
<JFo> tgardner, you still around?
<JFo> looks like we have a problem in the kernel-ppa
<JFo> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-06-09-maverick/
<tgardner> JFo, for  FEW MORE MINUTES
<tgardner> opps
<JFo> we aren't building an image-
<JFo> heh
<JFo> no problem
<JFo> huh
<JFo> strike that
<JFo> looks like we failed to build a few images
<JFo> the mavericks failed to build image debs from the 5th to the 10th
<JFo> from what I see
<tgardner> JFo, send apw an email. he's the most familiar with his cod infrastructure
<JFo> k, will do
<JFo> just wanted to tell someone :)
<apw> ogasawara, are you running your -4 kernel on any intel graphics h/w ?  seeing some nasty flashing here
<ogasawara> apw: I've had it running here on my hp-mini all intel, but not noticing any flashing
<bjf> apw, works fine for me
<ogasawara> apw: let me update it to the latest bits in the archive
<apw> ogasawara, was seeing flashes of black full screen as it were, seems ok when it is being used
<gaurav> hello, i am using thinkpad x201, i have to boot into ubuntu by adding '915.modeset xforcevesa nomodeset' in the grub menu while booting. I was told to enable thinkpad acpid module and recompile the kernel.
<jjohansen> -> walk
#ubuntu-kernel 2010-06-22
<psusi> I've noticed that Ubuntu kernels use a lot more memory than mainline ppa builds... I've compared the output of free and ps aux on both and can see no substantial difference in the rss total in ps, but free -m reports 545mb more used ram under the Ubuntu kernel
<psusi> are there some reporting files in /sys or /proc somewhere I can't find to get more information on kernel memory usage?
<jjohansen> psusi: /proc/slab/
<psusi> jjohansen, no such dir...
<jjohansen> err make that /proc/slabinfo
<psusi> ahh ;)
<psusi> nope, not there either
<jjohansen> what kernel?
<psusi> 2.6.35-rc3+
<jjohansen> hrmm, ubuntu or mainline
<psusi> mainline currently
<jjohansen> I think its a config option
<psusi> I built it with the config file taken from the current maverick kernel
<jjohansen> psusi: can you open a bug, and report the disparity
<psusi> yea... I intend do, was just hoping for some advice on getting more info that could be helpful for the report
<jjohansen> hrmm, okay I'll have a look once my maverick install is done
<jjohansen> /proc/slabinfo should be there
<psusi> I was just looking in the kernel documentation and found slabinfo.c...
<psusi> seems useful... going to check ubuntu kernel...
<psusi> oh great... NOW it ISN'T hogging memory....
<psusi> man it sure takes ages for the build farm to build the kernel... 3 hours and still going... iirc it takes me about an hour...
<kees> ogasawara, JFo: this bug report isn't very great, but I don't know what to say beyond what I've put here: 597075.  any ideas to help me debug this?
<ogasawara> kees: hrm, removing quiet and splash help show anything like a panic?
<ogasawara> kees: can you attach lspci from when you boot 2.6.34?
<psusi> jesus... the build farm is coming up on 5 hours compiling the kernel... what is it, a pentium-133? heh...
<kees> ogasawara: yeah, no panic, nothing.  on a normal boot, the framebuffer loads, clears the screen and nothing else ever happens.  if I break=top, I get an initramfs prompt and it hangs.
<kees> ogasawara: I've done a full apport-collect on that bug now.
 * smb waves good morning to .*
<jk-> smb! just the guy...
<cking> morning smb
<jk-> do you have an ETA for the alsa backports to hit -proposed ?
<smb> jk-, Uh oh... :)
<jk-> :)
<smb> which ones that did not?
<jk-> oh, an update has gone up?
 * jk- looks
<smb> jk-, should be in proposed as you whished. :)
<smb> IF you talking of Lucid of course
<smb> linux-backports-modules-2.6.32 | 2.6.32-23.16 | lucid-proposed | source
<jk-> smb: yep, Lucid
<jk-> thanks :)
<smb> jk-, NP. Actually the ALSA stuff was in -23.15 but it seems in minorly messed up and did not include the whole changelog since updates. :/
<slytherin> On powerpc, power management in gnome-power-manager does not work correctly without loading pmu_battery module. What can be done to make it work out of box?
<smb> slytherin, Hm, is there any bus information / IDs that could be used in module alias definitions
<slytherin> smb: I don't know. I only know for sure this bug is affecting a lot of people and is open since karmic.
<smb> The usual way in the kernel would be to have something like this but that might be better answered by someone who actually is doing work on ppc
<slytherin> bug 458004 has relevant info. I can do necessary testing on my ibook. But I don't know enough to try kernel changes myself.
<ubot2> Launchpad bug 458004 in linux (Ubuntu) (and 1 other project) "gnome-power-manger does not work in karmic ppc (affects: 2) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/458004
<kraut> moin
<amitk> lag: nice overview of the suspend/resume debugging! :)
<amitk> lag: did you discuss this with upstream?
<lag> amitk: Thank you
<lag> amitk: I believe it has. It has been passed to Matt? @ -mm
<cooloney> lag: your email is quite helpful, since i also got suspend/resume on fsl-imx51
<apw> smb, morning
<smb> apw, morning
<slytherin> smb: Can you please take a look at the bug and comment on what the next step should be?
 * apw suspects it would be easier for him to do that if slytherin included bug #nnnn so that ubbotu could do her thing
<smb> its above
<smb> but i cannot really comment on ppc
<slytherin> Should I bug TheMuso then?
<apw> slytherin, i would say its a lack of a module alias, but presumably there is a simple work around of adding modules to /etc/modules
<slytherin> apw: There is. But users want power management to work out of box.
<slytherin> Specifically on laptops (ibook/powerbook etc).
<apw> apple really should help the community to keep their laptops working shouldn't they
<slytherin> They did till OS X 10.5. Now there is no powerpc support.
<apw> slytherin, thats apple for you, don't care about their customers once the kit is a year old
<slytherin> Anyway, what I was looking for is what is the best way to make it work out of box in Ubuntu. Sine we already know which module is needed, what is the next step.
<apw> slytherin, you need to work out what feature of the platform indicates that that module is needed
<apw> the module in the kernel has no load triggers.  there is no 'if this h/w exists you should load'
<slytherin> How do I go about that. As per comment in bug 458004, "To make DeviceKit see the battery, pmu_battery kernel module needs to be  loaded."
<ubot2> Launchpad bug 458004 in linux (Ubuntu) (and 1 other project) "gnome-power-manger does not work in karmic ppc (affects: 2) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/458004
<smb> I was trying look a bit at the whole thing, but my problem is that I don't see a pmu_battery module at all on the only ppc machine I can access (ppc64 though). There are battery modules but also have no alias . The only other mchanism other that matchin dmi information
<smb> which ppc does not have, would be bus ids, which batteries usually also not have
<smb> So probably some devicekit magic might be reasonable
<slytherin> smb: What kind of magic?
<smb> slytherin, Well, find out that the machine you are running is a ppc. The problem is, and that should be answered by someone who really understand ppc. How do you decide which battery module should be loaded and when. As I saw on that ppc64 machine there is no pmu_battery modules provided (at least not for Karmic). So what should be loaded then. And when. 
<smb> And when not
<slytherin> I can't say I understand ppc. I will check if anyone in Debian knows what to do.
<apw> slytherin, normally such a module has aliases to load based on the machine type, so you would need to find a computer readable identifier for the machine which has this, the equivalent of dmi-decode on x86
<apw> you can then tie the module to that existance.  you can tell if there is such a thing by 1) trying dmidecode, 2) looking at the udev logs to see if it fired an event for the device
<apw> for the battery
<slytherin> Will it be sufficient to check difference between udev log when module is loaded vs not loaded.
<apw> slytherin, nope, the event would have fired if it exists
<apw> slytherin, the way auto loading works is that the kernel detects things in the machine and triggers uevents, those go to udev which tries to match modules to them and autoload them
<slytherin> hmm
<apw> to be loaded a module has to advertise it understands something, some h/w attribute so that the udev triggers it
<apw> now the module you want loaded doesn't do that so udev will never load it whether there is a trigger or not
<slytherin> Ok.
<apw> so you need to look a tthe udev log and see what h/w triggers appeared and see if there is one for the specific machine type or better for the battery
<apw> slytherin, i would advise adding the udev log to the bug
<slytherin> Doing that right now. Please note that I have already loaded the module.
<jk-> slytherin: and maybe poke around in /proc/device-tree to see if there's a directory that describes the battery ?
<slytherin> jk-: http://paste.ubuntu.com/453282/
<slytherin> apw: Added udev log to the bug.
<apw> jk-, any idea what this means: MODALIAS=ssb:v4243id0812rev05
<apw> slytherin, its probabally not very convienient, but it would be helpful if the log didn't have the battery autoloaded
<slytherin> apw: Ok. Let me reboot without the module.
<slytherin> apw: Attached the udev log without module loaded. If there is any more info needed, let me know.
 * slytherin will be out for some time
<apw> jk-, is there a machine identifier in of ?
<jk-> apw: it should be in /proc/device-tree/model
<jk-> it should contain something like PowerBook5,2
<jk-> IIRC
<BenC> wow, you guys have a ToS for IRC now
<bjf> moin all
<JFo> moin bjf
<JFo> apw, this looks potentially important: bug 596257
<ubot2> Launchpad bug 596257 in linux (Ubuntu) "MAJOR CRASH POSSIBLE: sysrq remains active with 2.6.35 (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/596257
<JFo> hmm, they reference the patch that apparently fixes it
<simar> Bug 569122 . Please help regarding the triaging  ... Logs can help ..
<ubot2> Launchpad bug 569122 in linux (Ubuntu) "Resuming from hibernation fails (video garbage with nouveau, no progress/hibernation with nvidia-current) (affects: 2) (dups: 1) (heat: 68)" [Medium,Confirmed] https://launchpad.net/bugs/569122
<tseliot> mjg59: what would be the right place to look at if my dell laptop's Print key behaves like SysRq when I press "Alt+Print"?
<mjg59> showkey on the console is the easiest
<tseliot> right, I was thinking in terms of code
<tseliot> mjg59: it gives me code 56 and 99, which is not SysRq
<tseliot> showkey -k, that is
<JFo> ogasawara, do you want me to tag config request bugs with a kconfig tag?
<JFo> I saw that you did that on one
 * bjf is meeting the rest of the pdx mafia downtown, will be back online in a bit
<ogasawara> JFo: that's what I'd been using in the past
<JFo> cool
<JFo> I can add that to the tagging wiki
<ogasawara> JFo: sounds good
<JFo> :)
<tazz> i have a x86_64 i5 processor, would it be possible for me to compile a i386 kernel ? 
<JFo> tgardner, what were the packages we wanted to add to bug metrics for the team meeting?
<JFo> omap and what?
 * JFo forgets
<tgardner> ti-omap4 ?
<tgardner> JFo, ^^
<JFo> yeah, I have that one, wasn't there another?
<tgardner> JFo, was it in the notes from last week IRC meeting?
<JFo> think it was in e-mail, but I can't find it now
<tgardner> 'cause I'm not really remembering what you're talking about
<JFo> heh
<JFo> you were telling the guys you wanted a status during the meeting for 2 projects
<JFo> and I only remember the one
<JFo> I'm sure it was an e-mail you sent out
<tgardner> JFo, just looked through the notes. nothing is jumping out at me
<JFo> ah well
<JFo> I'll add the omap and maybe someone will remember during the meeting for next week
<simar> hello
 * bjf is back
<jjohansen> be back in 5
<gnomefreak> i have 2 bugs that seem to be the same (same error code and same problem) except they are not on the same version of kernel, one is 2.6.32-22 and the other is -23
<gnomefreak> does that sound like the same? i can give bug numbers if you like
<gnomefreak> see bug 596557 and bug 596293
<ubot2> Launchpad bug 596557 in grub2 (Ubuntu) "package linux-image-2.6.32-22-generic 2.6.32-22.36 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127 (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/596557
<ubot2> Launchpad bug 596293 in grub2 (Ubuntu) "package linux-image-2.6.32-23-generic-pae 2.6.32-23.37 failed to install/upgrade: podproces instalovanÃ½ post-installation skript vrÃ¡til chybovÃ½ status 127 (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/596293
<manjo> cking, around ? 
<cking> manjo, yep
<cking> wassup?
<manjo> cking, at the plugfest 
<ogra> gnomefreak, these are users that followed very likely the ubuntugeek blog and broke their /etc/default/grub file by copy pasting 
<ogra> gnomefreak, we have 100s of duplicates of that bug
<manjo> cking, you said you were able to boot iso on virtual box 
<manjo> was that the one with the modified grub ?
<gnomefreak> ogra: ok thanks if i run into them i will mark them. Do you have a master bug #?
<ogra> thanks to the blog software ubuntugeek uses which replaces quotes qith double backticks
<JFo> did the team meeting time change?
<bjf> JFo, no why?
<cking> manjo, I was mistaken - my UEFI flag got flipped back to non-UEFI
<JFo> just looked odd to me
<JFo> maybe I just had too much coffee this AM
<JFo> :)
<bjf> JFo, 35 minutes from now
<JFo> hmmm
<manjo> cking, ok so we don't know yet if the new isos work... ok so I will make copies of the livecd iso and hand those out
<ogra> gnomefreak, not from the top of my head, there is a guy (Jean-Baptiste Lallement) who did the collecting of these bugs for the last few weeks. i guess he has a master
<JFo> the calendar shows it an hour and 35 from now bjf
<JFo> so it did look funny to me
<gnomefreak> ogra: thanks
<JFo> whoops
<JFo> nevermind bjf
<JFo> figured out what it was
<cking> manjo, well, may be worth trying it with one first before handing out a load
<manjo> cking, yeah I have tried the livecd at home 
<JFo> bjf, the KTeam cal hadn't loaded, so I was seeing the call on the Eng Cal
<manjo> this is based on the iso that was prior last weekend 
<JFo> heh
<manjo> so last Thursday etc 
<ogasawara> manjo: any progress with the new firewire stack bits?  will it make Alpha 2?
<manjo> ogasawara, I sent out the patch to the ukml ... 
<ogasawara> manjo: right, just curious if it's been applied and uploaded
<manjo> tgardner, ^^ ?
<ogasawara> manjo: I assume the second work item "add basic tests to kernel-qa to test new firewire stack." will slip to Alpha3?
<manjo> ogasawara, yeah unfortunately I am out this week.. so next week I will be able to add some 
<cking> manjo, looks like you may need to "wing it" a bit then
<ogasawara> manjo: the tests aren't A2 release critical so I'll reset it to the A3 milestone
<manjo> ogasawara, sure 
<manjo> ogasawara, tests are not even part of the OS so its ok to slip I think 
<ogasawara> manjo: ack
<manjo> cking, intel just asked me if I have any server isos
<manjo> cking, :) 
<cking> not today
<cking> manjo, suppose it's not out of the question is it?
<manjo> cking, yeah they wanted us to show case the cloud stuff... 
<manjo> cking there is another plugfest in October 13-15 Taipei
<cking> manjo, nothing like being put on the spot
<cking> Now that sounds like a good opportunity
<manjo> cking, we should get someone out there for that one with maverick desktop & servers
<manjo> cking, 2.2TB HDD looks like a big new thing that EFI supports and there is seagate & WD here with 2.2 drivers 
<manjo> drives
<cking> manjo, agree - want to forward the details of the Taipei plugfest to hugh and me?
<manjo> cking, will do
<cking> cheers
<bjf> ##
<bjf> ## Kernel team meeting in 20 minutes
<bjf> ##
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<manjo> bjf, I won't make it to the meeting 
<slangasek> apw: hi, I have a stack of issues with the ti-omap4 kernel packages that I'm trying to unwind; the first is that I can't clone git from the documented URL :)
<tgardner> slangasek, git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
<slangasek> tgardner, apw: so here are the main lintian problems that I'm concerned about in the ti-omap4 package:
<slangasek> W: linux-image-2.6.34-900-omap4: postrm-does-not-purge-debconf
<slangasek> W: linux-image-2.6.34-900-omap4: missing-debconf-dependency-for-preinst
<slangasek> there's also a lot of changelog noise which probably just needs some tuning to whatever script generates those
<slangasek> the postrm stuff ought to be fixable by making sure the maint script has a #DEBHELPER# token in it
<slangasek> assuming you're using debhelper in debian/rules... which I hope you are :)
<slangasek> the lintian warning wouldn't be there if you're not using debconf
<apw> slangasek, ok thanks .... hrm
<slangasek> apw: debian/control-scripts/preinst - inherited from kernel-package, blaaah
<apw> see we get to blame debian :)
<slangasek> heh
<apw> i see all the debian kernels have the same warnings ... whee
 * apw cries at how slow lintian is on a kernle package
<slangasek> ick
<apw> produce some output dammit
<apw> no really i'd love to know your oppinion on my package, today
<cking> patience is a virtual, apparently, but I've never gotten around to prove it.
<apw> FINALLY
<apw> slangasek, is there a way to say some warnings are wrong?
<apw> W: linux source: native-package-with-dash-version
<apw> W: linux source: changelog-should-mention-nmu
<apw> its not clear we can avoid either of those
<apw> W: linux-image-2.6.35-5-generic: windows-devel-file-in-package lib/firmware/2.6.35-5-generic/korg/k1212.dsp
<apw> or indeed that one
<slangasek> apw: yes, lintian overrides - I agree those should be overridden
<slangasek> I think the lintian manpage documents how to declare overrides
<apw> slangasek, yep found it, will get those added and get the others on the list to squash
<JFo> bjf, you want that ftraceable bugs item on the arsenal BP?
<bjf> JFo, we were maintaining a wiki page with arsenal todo items on it, that's where it should go so we don't loose track of it
<JFo> k
 * JFo goes to look for the page
<JFo> hmmm, bjf do you have the link handy?
<JFo> I apparently don't have it bookmarked and my wiki search fu is weak today
<bjf> JFo, damn, i just knew you were going to ask... now i've got to go hunt for it :-)
<JFo> heh
<bjf> HA! too easy ... http://wiki.canonical.com/Kernel/Arsenal
<JFo> nice
<JFo> hmmm
<JFo> bjf, you big kidder
<JFo> I suppose that means you want me to create it :-P
<bjf> JFo, just a sec
<JFo> k
<JFo> :)
<bjf> https://wiki.ubuntu.com/Kernel/Arsenal
<bjf> user error
<JFo> cool
 * tgardner lunches
<JFo> cnd, do you think it would be possible for you to give me some ideas on what bugs you want to see in the 'ftraceable bugs'?
<JFo> I suspect this is something where you want us to identify them and then ask them to do a specific set of commands
<JFo> to provide the output to the bug
<apw> slangasek, i am not seeing any whinges about our changelog format, have you an example
<slangasek> apw: in the ti-omap4 package: W: linux-image-2.6.34-900-omap4: debian-changelog-line-too-long line 31
<apw> slangasek, thanks
<JFo> apw, do you see a use-case for mainline -server kernel builds?
<JFo> someone is asking about them in a bug
<apw> i don't know of any, do they have one?
<tgardner> about the only differenxces are HZ and def scheduler and I/O settings
<JFo> it made me wonder if it were something worthwhile for us to build as an unsupported test case for server users
<shadeslayer> hi,can someone look at 593041
<shadeslayer> bug 593041
<ubot2> Launchpad bug 593041 in linux (Ubuntu) "New 2.6.35 kernel keeps toggling bluetooth radio (affects: 1) (heat: 6)" [Undecided,Triaged] https://launchpad.net/bugs/593041
<shadeslayer> its getting worse with each kernel upgrade :P
<jjohansen> what is the magic url for opening bugs again?
<JFo> +filebug iirc jjohansen 
 * JFo checks
<ogasawara> jjohansen: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+filebug
<tgardner> https://bugs.edge.launchpad.net/ubuntu/+filebug
<jjohansen> thanks
 * JFo ticks a point
<JFo> ;)
<jjohansen> -> rebooting and then switching venues
<apw> $ lintian linux_2.6.35-5.7.dsc
<apw> N: 2 tags overridden (2 warnings)
<apw> $
<apw> better me think
<tgardner> ogasawara, Maverick git URLs in LP bugs become invalid the next time you rebase
<tgardner> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/594382/comments/8
<ubot2> Launchpad bug 594382 in linux (Ubuntu Maverick) (and 1 other project) "Wake up daisy chain activation failed on omap3 (affects: 1) (heat: 8)" [Critical,Fix committed]
<ogasawara> tgardner: bah, you're right
<tgardner> ogasawara, that particular commit also has a bogus buglink, I emailed you about it.
<ogasawara> tgardner: I'll fix that up
<Azelphur> Hi, i keep getting an issue with my pc which i think is to do with kernel usb support, my keyboard/mouse will randomly start going very slowly, keystrokes arrive very slowly and often in the wrong order or not at all, mouse position seems to update twice a second, i tried replugging my keyboard, it took 3 minutes to be powered up again
<Azelphur> i can only solve the issue by restarting my pc, restarting X does not solve it
<Azelphur> and it happens seemingly at random
<Azelphur> running 10.04 64bit
<ogasawara> tgardner: was trying to schroot into maverick-armel on tangerine, but get the following error
<ogasawara> tgardner: $ schroot -c maverick-armel
<ogasawara> mmap: Operation not permitted
<ogasawara> tgardner: no hurry on needing to get it fixed, was just testing if I could use the chroot to do a test build
 * ogasawara lunch
<tgardner> ogasawara, ack, looking into it
<kees> ogasawara: your mmap_min_addr is too high.  install qemu-kvm-extras-static
<tgardner> kees, rtg@tangerine:~$ dpkg -l|grep qemu
<tgardner> ii  qemu-kvm-extras-static          0.12.3+noroms-0ubuntu9            static QEMU user mode emulation binaries
<kees> hm, check /etc/sysctl.d/ ?  do you have 30-qemu-kvm-extras-static.conf ?
<tgardner> kees, yep
<tgardner> vm.mmap_min_addr = 4097
<kees> what does   cat /proc/sys/vm/mmap_min_addr 
<kees> say?
<tgardner> 65536
<kees> sounds like qemu-kvm-extras-static's packaging doesn't reload sysctl correctly.
<kees> sudo service procps start    shoudl fix it
<tgardner> 4097
<kees> now the schroot should work
<tgardner> kees, success!
<kees> \o/
<tgardner> kees, so, basically you need a reboot after installing qemu-kvm-extras-static.
<kees> no, qemu-kvm-extras-static needs to call "start procps" in its postinst
<tgardner> kees, I saw this on one other machine after a fresh install, so I think you're right
<kees> tgardner: open a bug, should be a really easy fix for hallyn :)
<tgardner> kees, doing so as we speak
<tgardner> kees, its got this:
<tgardner> # apply /etc/sysctl.d settings
<tgardner> if [ "$1" = configure ]; then
<tgardner>     invoke-rc.d procps start
<tgardner> fi
<kees> invoke-rc.d is wrong.  :)
<tgardner> kees, so, change it to 'service procps start' ?
<kees> the whole line should be "start procps"   (upstart fully broke invoke-rc.d, which was always wrong, iiuc)
<kees> yeah, "service procps start" is more portable (to Debian) than just "start procs" but both will worki.
<tgardner> ogasawara, tangerine armel schroot issue fixed thanks to kees
<bguthro> Is anyone here particularly versed on the i915 driver?
<bguthro> I've got a Dell Latitude E6410, that when switched to an external VGA display at the BIOS, will come up properly...but if left to its own devices, never displays on the LVDS connector
<slangasek> kees: nooooooooo
<kees> slangasek: ?
<bguthro> lspci looks like its the "Ironlake" chip, referred to in drivers/gpu/drm/i915
<kees> slangasek: but invoke-rc.d doesn't work...
<kees> O_o
<kees> tgardner: everything I said about invoke-rc.d is wrong.
<kees> tgardner: something is still wrong in the qemu-... package though
<tgardner> I'm getting that. how come?
<kees> it looks like invoke-rc.d still works, and slangasek is trying to reach across the table here to hurt me
<slangasek> tgardner: invoke-rc.d is still the only suitable interface for use in maintainer scripts.  Keybuk doesn't want this to be the interface for upstart jobs, but hasn't implemented its replacement yet
<kees> tgardner: but something still didn't actually fire procps after qemu... installed.
<slangasek> if there are any cases where invoke-rc.d currently fails, we should fix that instead of calling a different command
<tgardner> kees, exactly
<kees> slangasek: this has been a problem in other packages (wine) too.
<slangasek> tgardner: was there any output in the dpkg log?
<slangasek> then we shall fix it! :)
<tgardner> slangasek, where is the dpkg log?
<slangasek> tgardner: /var/log/dpkg.log
<tgardner> nm
<slangasek> actually, /var/log/apt/term.log is more useful
<tgardner> kees, slangasek:
<tgardner> Selecting previously deselected package qemu-kvm-extras-static.^M
<tgardner> Unpacking qemu-kvm-extras-static (from .../qemu-kvm-extras-static_0.12.3+noroms-0ubuntu9_amd64.deb) ...^M
<tgardner> Processing triggers for man-db ...^M
<tgardner> Processing triggers for ureadahead ...^M
<tgardner> Setting up binfmt-support (1.2.18) ...^M
<tgardner>  * Enabling additional executable binary formats binfmt-support^M
<tgardner>    ...done.^M
<tgardner> ^M
<tgardner> Setting up qemu-kvm-extras-static (0.12.3+noroms-0ubuntu9) ...^M
<tgardner> update-binfmts: warning: /var/lib/binfmts/arm does not exist; nothing to do! ^M
<tgardner> procps stop/waiting^M
<tgardner> ^M
<tgardner> Log ended: 2010-06-19  15:11:20
<tgardner> I see that procps _was_ restarted
 * kees scratches his head
 * kees tries to reproduce locally
 * slangasek nods
<kees> worked correctly for me.  :(
<tgardner> kees, me too. huh. the failure was on a 64 CPU machine. timing?
<kees> O_o uhm
<tgardner> kees, I can try it on that machine.
<kees> basically, installing and purging qemu-kvm-extras-static each time it should change /proc/sys/vm/mmap_min_addr
<tgardner> kees, dang, it worked that time. I purged and restored /proc/sys/vm/mmap_min_addr to 64K, then reinstalled.
<kees> tgardner: purging should restore mmap_min_addr on it's own (due to /etc/sysctl.d/10-zeropage.conf)
<tgardner> kees, I didn't actually check first
<slangasek> and there's a bug in the postrm, purge will fail if the procps package has been uninstalled :)
<tgardner> kees, slangasek: well, I'm gonna let you wizards deal with it. Its EOD for me.
<kees> if procps has been uninstalled I won't debug that system.  :)
<kees> tgardner: cool, thanks.  weirdness.
<tgardner> kees, non-sequitur, I think it should be YAMAC (Yet Another Mandantory Access Control) LVM
<kees> it's not a MAC!  :)  It's a NAC.   NAKed Access Control system
<tgardner> maybe this attempt will get some traction
<kamal> jjohansen: ping
<jjohansen> kamal: pong
<kamal> is the atop patch being considered for lucid kernel, or just maverick?  (I have it working in lucid with just one tiny change)
<jjohansen> maverick
<jjohansen> it isn't something we will sru
<kamal> that was my guess (but was easier for me to test / play with in lucid :)   ok, I'll check applying it to maverick.
<jjohansen> yeah, completely understood.  I had considered that too
<bjf> JFo, around?
<stenten> For bug reports, what subsystem are Oopses under? kernel-core?
<ogasawara> stenten: if you're not sure which subsystem the oops is coming from I'd use kernel-uncat
<ogasawara> stenten: we review those weekly and it'll then get shuffled to the right category
<stenten> ogasawara: ok, thanks!
#ubuntu-kernel 2010-06-23
<JFo> bjf, am now
<bjf> JFo, no big deal, someone was pointing out a Launchpad oddity
<JFo> ah
<bjf> JFo, just emailed some links to you
<JFo> sweet
 * JFo looks
<bjf> the "current series" is 2.6.31
<bjf> i'd never looked at any of those pages
<JFo> yeah, we need to change the development focus :)
<MTecknology> jussi: You ever get that figured out?
 * amitk waves
 * cooloney waves back to amitk 
<om26er> is there any technical name for gpu-switching? (for finding related bugs upstream)
<apw> om26er, not sure i even know what you mean by gpu-switching
<om26er> apw, there are system with two graphics card. e.g alienware m11x
<apw> i would call those dual-gpu something like that
<ogra> apw, do you know if anyone is on top of bug 595949 ?
<ubot2> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) (and 1 other project) "linux-meta-ti-omap depends on the wrong binary kernel in maverick (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/595949
<apw> ogra, not sure, will look
<apw> achaemenes, wondering why you need to turn off that option?
<achaemenes> apw: I'm doing some security research, and writing a rootkit for 8.04 - however from 2.6.24-19 to 2.6.24-28, that option has been enabled - as is happening with most kernels in most distros - however i have to keep it disabled because my work hasn't yet finished, but I'd like to be on the latest 8.04 kernel while developing it
<achaemenes> once it's complete, I'll have to write an anti-rootkit for it
<achaemenes> and after that, again a rootkit that does not modify syscall tables at all, and again an anti-rootkit for that... etc. 
 * achaemenes git clones
<apw> achaemenes, if you have a local linux-2.6 tree you can --reference that, as we are pretty close to mainline
<achaemenes> ahh thanks, good to know
<lag> Has anyone build the Lucid ti-omap branch recently?
<lag> built*
<ogra> lag, i guess smb since there were security updates in lucid
<lag> Thanks ogra
<apw> i built it i believe to when testing the debian commonisation changes
<achaemenes> i hear make-kpkg is now the "old way" :)
<achaemenes> man i felt old after reading that
<arun> achaemenes,  what's the new way to build kernels?
<ogra> apw, hmm, dont we end up with clashing binaries now for linux-omap ? 
<ogra> since the old one still exists in the archive
<achaemenes> arun - i was just reading the ubuntu page which is where i read that comment: https://help.ubuntu.com/community/Kernel/Compile#Alternate Build Method: The Old-Fashioned Debian Way
<achaemenes> apw - is that the best page i should be reading for doing what i'm doing?
<apw> achaemenes, i would normally build from the git tree
<apw> git checkout -b foo <tag>
<apw> then use a chroot to build it
<achaemenes> since the clone, all ive done is "git checkout Ubuntu-2.6.24-28.71                     "
<apw> fakeroot debian/rules clean; fakeroot debian/rules binary-generic
<apw> (both inside the chroot)
<achaemenes> and i am guessing debian/config/i386/condif.server shoud be == /boot/config-`uname -r`
<apw> yep the config fragments used to make the configs are in debian/config
<achaemenes> hmmm, this is odd: /usr/src/ubuntu-hardy is not clean, please run 'make mrproper'
<achaemenes> if i mrproper, all the goodies will disappear
<apw> try rmdir include/config
<achaemenes> hmm, no such directory - I'll just post a complete log of what I've done in case I'm doing something silly (/me prepares pastebin)
<achaemenes> http://pastebin.com/kTNmSsY0
<achaemenes> and there is no include/config or include/config*
<apw> what does git ls-files -o show
<achaemenes> no output at all
<apw> achaemenes, oh you have .config
<apw> you don't put the .config in the top level
<achaemenes> apw - oh? they how will it know what to build?
<apw> it will build the flavour config for the flavour that you speciified
<apw> binary-server for the server config
<achaemenes> ohhhh
<achaemenes> of course!
<achaemenes> duh
<apw> rm .config and it'll work i suspect
<achaemenes> thankyou apw - you've been increadably helpful - and yet - that was it!
<achaemenes> i didnt even think twice on that
<achaemenes> apw will you be making it (or interested in) ruxcon? :)
<apw> heh don't think i'll be there
<apw> some of our security people might though
<amitk> cooloney: lag: so TI-omap4 is based on 2.6.33 or 34?
 * amitk thinks it is .34, based on the renamed package
<ogra> amitk, .34
 * ogra will start building hand-rolled test images today for omap4
<ogra> so you can try it if you have omap4 HW
<amitk> ok, I got confused by some commits I saw from lucid in there
<lag> VERSION = 2
<lag> PATCHLEVEL = 6
<lag> SUBLEVEL = 34
<lag> EXTRAVERSION =
<lag> NAME = Sheep on Meth
<lag> :)
<amitk> ogra: no OMAP4 HW here
<lag> Who names these things?
<lag> :)
<ogra> time you get some 
<apw> ogra, the linux-image-omap meta packages are updated in maverick
<apw> lag, thats linus himself
<lag> apw: Maybe he needs to stay off the stuff himself 
<apw> lag, very likely :)
<lag> /
<thangam_arun> Hello All
<thangam_arun> i am building kernel on Ubuntu-8.10
<thangam_arun> but at the end i am getting two .deb files(image, kernel-header)
<thangam_arun> But i want to build debug kernel 
<thangam_arun> how do i get that .deb file ??
<thangam_arun> linux-headers-2.6.27-17-core2_2.6.27-17.46_i386.deb linux-image-2.6.27-17-core2_2.6.27-17.46_i386.deb 
<thangam_arun> these are tow files i got, after compionilat
<thangam_arun> *compilation
<thangam_arun> sudo CONCURRENCY_LEVEL=2 NOEXTRAS=1 skipabi=true skipmodule=true fakeroot debian.master/rules binary-core2
<thangam_arun> the above one is used for kernel compilation 
<thangam_arun> Can you please some one help to get "debug" kernel .deb file 
<thangam_arun> i am witing for reply ??
<smb> thangam_arun, If you are looking for the package that contains the unstripped binaries, try adding a skipdbg=false to you cmd line
<thangam_arun> smb: Okay
<thangam_arun> smb: wht about "binary-debs" ??
<thangam_arun> smb, Any idea?
<smb> No I am trying to understand what exactly you mean with binary-debs.
<smb> As an argument
<smb> or as something else
<thangam_arun> okay
<smb> That was sort of a question on my side. :)
<smb> As targets I usually use only binary-<flavour> or binary or binary-arch
<thangam_arun> oh ok
<smb> I mean, you got a linux-image apparently, which would be the binary kernel package.
<thangam_arun> yes that correct
<smb> You might want to make a run with either binary-indep or binary-header which creates the common headefr package
<thangam_arun> is that enough for debugging purpose ?
<bguthro> Hello,
<smb> Depends on how you debug. If you add printk's or use special debugging options you might not need the debug package. That only help to disassemble stuff or find symbols or profile
<smb> thangam_arun, But otherwise that should be enough
<thangam_arun> in this build i have configured "debug" in the "kernel hacking" section
<bguthro> I'm attempting to chase down an Intel i915 problem in lucid - nothing displayed on an E6410... I've tried up to the mainline builds of 2.6.35-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid - and now wanted to try the Intel-drm development branch from kernel.org...but wanted to know if there was some build patch that I can apply over the top, to get the deb build system...
<bguthro> I assume this is one of kees trees here: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=summary - but didn't know if there was a patch I should be using, to apply on top of a different devel branch: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=summary
<smb> thangam_arun, Hm, I cannot say from my head what exactly that enables. Generally the build has bdebugging informationenabled but strips things for the normal packages
<smb> bullgard4, It looks like something from kees and maybe you will find useful things under mainline-build in git://kernel.ubuntu.com/ubuntu/kteam-tools.git but apw may have better info or even written a wikke 
<thangam_arun> smb, okay
<thangam_arun> smb, let me experiment and see
<smb> thangam_arun, best way to go. :)
<thangam_arun> smb, bwt when i gave binary-debs building extra modules, i do not know why :)
<apw> bguthro, don't we already build the drm-intel branch in the mainline builds ?
<smb> thangam_arun, Ugh, I fail to parse that last sentence. o_O
<apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
<apw>  thangam_arun which ones extra do you get ?  .udebs perhaps ?
<bguthro> Excellent. I missed that. Thanks - saves me some time!
<thangam_arun> smb, when i pass "binary-debs" option for compliation, it is compiling new modules 
<bguthro> Is there a git tree somewhere that this is generated from that I could dig into, if I have to debug this LVDS issue?
<apw> bguthro, nope.  but the scheme is simple, checkout the debian* directories from lucid/master into your mainline tree, update the configs and buil
<apw> build .. thats is what the mainline builds do
<bguthro> apw, sounds like a plan. Thanks a lot
<smb> thangam_arun, Hm, ok. Maybe the udeb packages?
<thangam_arun> smb, might be. waiting for build to complete
<achaemenes> apw - i forgot to ask, say i want to amend the "binary-server" - which config file do i change?
<achaemenes> debian/config/i386/config.server maps to binary-server? or there is more magic to it?
<apw> i think you change debian/config/i386/config:CONFIG_DEBUG_RODATA=y
<apw> and usually run debian/rules updateconfigs afterwards
<achaemenes> right, and all the other configs in there are regened
<achaemenes> hmmm, no 
<achaemenes> git status shows only that file to have changed
<apw> thats good, that means your change stuck
<achaemenes> is there an inheritance model with those files then?
<apw> yeah the config is common to the others
<achaemenes> ahh ok now i get it
<ccheney> apw: i need kernels please... ;-)
<ccheney> apw: aka is there a status update yet? :)
<ccheney> tgardner, or do you happen to know?
<tgardner> ccheney, eh? know about what?
<ccheney> tgardner, oh sorry i didn't explain what i am asking about, i need ppa test kernels (or however they will be provided) for rc's between 2.6.32 and 2.6.33 to track down the cause of bug 588861
<ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/588861
<ccheney> tgardner, its a blocker for UEC
<tgardner> ccheney, uh, hang on while I figure it out
<ccheney> tgardner, jjohansen was looking into it but said he might not have time to get to them and so you or andy might end up generating them
<ccheney> its becoming more urgent as i'm pretty sure your kernel alpha 2 freeze window is rapidly approaching :)
<tgardner> ccheney, well, I'm pretty sure you're releasing A2 with a Lucid kernel
<ccheney> tgardner, yea i think at this point we will probably need to do that
<ccheney> even if we find the kernel it broke in it might not be obvious how to fix it
<tgardner> ccheney, this is the -virtual flavour, right?
<ccheney> -server
<ccheney> i tested using the ppa mainline kernels where it was seen as well
<ccheney> the error happens on the walrus server not inside a kvm instance
<tgardner> ccheney, what is a walrus server?
<ccheney> its the part of eucalyptus that stores images for use by instances
<ccheney> tgardner, so basically i try to add a lucid image to the uec machine to be used by instances that want to use it and when doing so it gives me the pad block corrupted error
<tgardner> ccheney, so you want a -server flavour built from sources somewhere between 2.6.32.15.5 and 2.6.33 ?
<ccheney> yes -server if possible but for testing it can be even mainline like at http://kernel.ubuntu.com/~kernel-ppa/mainline/ as it shows the same issue
<ccheney> whichever is easier on you guys
<tgardner> ccheney, damn, I had apw clean up all those daily builds just last week.
<tgardner> ccheney, I'll start reproducing the 2.6.33-rcX builds to see if we can narrow it down
<ccheney> tgardner, sorry we didn't get to it sooner I was out on paternal leave for the past 2 weeks and got assigned the bug on last Friday, from what I recall they were already gone at that time.
<pgraner> JFo: can you get this on one of our lists? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/449043
<ubot2> Launchpad bug 449043 in linux (Ubuntu) "Suspend/resume failing with Audigy2 PCMCIA attached (affects: 5) (dups: 1) (heat: 30)" [Undecided,Triaged]
<JFo> pgraner, yessir
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/2.6.33/linux-image-2.6.33-rc1_2.6.33-rc1-1_amd64.deb
<ccheney> thanks
<tgardner> ccheney, -rc2 is building, but I suspect you'll find that -rc1 doesn't work. -rc1 is where most of the new changes appear
<ccheney> ok thanks
<tgardner> I'll bisect between 2.6.32 and 2.6.33-rc1 if that is the case
 * ccheney hopes he didn't corrupt his setup, might have to reinstall maverick before testing
<ccheney> ok will try to get this tested asap, my euca-* commands aren't working at the moment, going to see if rebooting helps, otherwise may be another hour before i can test to do a full reinstall
<ccheney> wow that deb is giant :)
<tgardner> ccheney, its probably not stripped. I build using the Kbuild deb-pkg target
<ccheney> oh ok
<tgardner> it'll make bisection a lot quicker
<smb> sconklin, Hi Steve, be careful with that last SRU. I was under the impression it was invalid
<JFo> apw, you around?
<JFo> looks like we need to do some updating to https://edge.launchpad.net/linux/
<tgardner> JFo, wow, I've never seen that page
<JFo> heh
<JFo> bjf pointed it out to me yesterday
<JFo> along with this one https://edge.launchpad.net/linux/2.6.31
<JFo> but there doesn't appear to be a corresponding .35 page
<JFo> or anything later than that for that matter
<ogasawara> JFo: is that the project to allow setting upstream bug watches?
<JFo> ogasawara, I think so, but I am not sure
<JFo> it is owned by us though
<JFo> ogasawara, we can change these pages yes?
<JFo> since it is showing .31 as the dev effort :)
<ogasawara> JFo: not sure if we can or if we have to ask the launchpad team to help
<sconklin> smb: you mean only the one from Manoj, right? If so, I agree and it is not in my branch
<JFo> hmmm
<ogasawara> JFo: right, definitely out of date
<JFo> heh
 * JFo tries something
<smb> sconklin, Right I was referring to that. It sounded like that was next on your list when quickly reading over that
<JFo> ogasawara, want me to try changing it to .35?
<bjf> JFo, there was a page were you could register a new "series"
<JFo> I think I have the power
<ogasawara> JFo: sure
<bjf> JFo, but I didn't play with it
<JFo> hmmm
<sconklin> smb: no, I couldn't tell what was needed and it looked incomplete so I was going to leave it alone
<smb> sconklin, Ok, right. Taht was one were apw and myself have looked at and did not find real eviddence why it should be broken. And I think manjo wanted to test it again and I don't remember feddback there.
 * JFo waits for LP to refresh
<JFo> ogasawara, look at it now
<ccheney> tgardner, it tells me unknown command recordfail
<JFo> I changed it to trunk
<JFo> as dev seried
<ccheney> tgardner, at grub when trying to boot your kernel
<JFo> err series
<ogasawara> JFo: cool
<bjf> JFo, on https://launchpad.net/linux/ there is a link "Register a series"
<smb> bjf, sconklin I am currently listening to a training session. But we can get together after that when you want to. (to sort out questions)
 * ccheney wonders if something he did when he removed the old kernels and installed the new one messed up grub somehow
<bjf> smb, wfm
<ogasawara> JFo: and it is indeed the project that was set up that allows setting the upstream bug watches
<JFo> cool, I thought it must be
<ogasawara> JFo: I opened a bug with an upstream bug watch and followed the links back to that page
<JFo> cool :)
<tgardner> ccheney, you can still boot older kernels? you though you might have borked you UEC enviro.
<tgardner> thought*
<ccheney> tgardner, well i didn't know i had borked grub, but yea it seems to not boot any kernel now for some reason and i see insmod messages in the grub config, which seem somehow wrong as well
 * ccheney looks at his other systems grub config file
<jaminc> I'm currently experiencing Bug #593650, as part of the troubleshooting I've tested a few kernel builds from the mainline PPA.  Each of the builds I've tested so far (.35-rc3 and .34) appear to correct the crash issue, but each appear to be interact badly with libvirtd managed VMs... suggestions?
<ubot2> Launchpad bug 593650 in linux (Ubuntu) "periodic kernel crash and system reboot (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/593650
<tgardner> ccheney, well, make sure you have a stable boot environment first.
<ccheney> hmm i bet the insmod stuff has to do with grub2, i don't know that much about the newer version
<JFo> ogasawara, I find it interesting that https://edge.launchpad.net/linux/trunk shows incomplete info
<JFo> looks like there may be a bzr branch somewhere that isn't up to date or something
<ccheney> hmm yea it booted back up fine under 2.6.35-4-server, will try the test kernel again to see what is going on
<ogasawara> JFo: yah was wondering why it was only showing through 2.6.32-rc8
<JFo> ogasawara, is this ours ~vcs-imports/linux/trunk ?
<ogasawara> JFo: no idea, I'm not sure where the trunk actually lives
<JFo> hmmm
<JFo> ogasawara, looks like it is here https://code.edge.launchpad.net/~vcs-imports/linux/trunk
<ccheney> tgardner, hmm yea just the test kernel fails with 'recordfail' related error message, the server kernel works, tested it a second time
 * ccheney looks to see what the cause of that would be
<ogasawara> JFo: interestingly, the recent revisions notes looks accurate (ie 2.6.35-rc3)
<JFo> yeah, was just looking at that
<tgardner> ccheney, shit, must be the way the kernels are packaged. are you running update-initramfs ?
<ogasawara> JFo: Ah, "This branch is an import of the HEAD branch of the Git repository at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git."
<ogasawara> JFo: so it seems to generate from mainline which is good
<ccheney> tgardner, not manually, but i can if needed
<tgardner> ccheney, give that a try
<tgardner> 'update-initramfs -u' after 'dpkg -i'
<JFo> ogasawara, wonder why the other data is wrong then
<ogasawara> JFo: but I can't explain why it's then displaying out of date
<JFo> hmmm
<JFo> let me think on it a minute
<JFo> I may have an idea why
<ccheney> running: update-initramfs -k all -c  to see if it helps
<ccheney> just running that didn't seem to help
<ccheney> maybe i should run it verbose to see if it is having problems? it didn't return any errors when i ran it though
<tgardner> ccheney, lemme build a 2.6.32.15 kernel just to make sure its a packaging issue.
<ogasawara> JFo: maybe has to do with the milestones? https://edge.launchpad.net/linux/+milestones
<ccheney> tgardner, ok
<JFo> could be
<ogasawara> JFo: as those look to only go up through 2.6.32-rc8
<JFo> hmmm
<JFo> that has to be it
<JFo> so ogasawara it looks like it pulls those from registered series
<JFo> I registered https://edge.launchpad.net/linux/2.6.35
<JFo> but it has no milestones
<JFo> wonder where those were coming from before
<ogasawara> JFo: "Milestones belong to a series and can be created from the series page by a project owner or series release manager."
<JFo> hmmm, but I am sure no one from upstream was creating these in LP
<jaminc> any ideas on what would cause mainline kernel builds to somehow cause libvirt managed VM disk image files to be non-writable?
<JFo> or rather, reasonably sure
<ogasawara> JFo: I think the project ower is actually the ubuntu-kernel-team
<JFo> yeah, that makes sense due to us owning the pages/branch/etc
<ogasawara> JFo: so I think you need administrative rights with the ubuntu-kernel-team to then create the milestones for a series
<JFo> hmmm
<JFo> looks like I have that type of permission
<JFo> if I hit create milestone
<JFo> it gives me a dialog where I can enter the info
<JFo> looking at this page https://edge.launchpad.net/linux/2.6.34
<JFo> toward the bottom
<JFo> you have it too I bet
<ogasawara> JFo: I don't have that magic
<ogasawara> JFo: you'r special
<JFo> oooh
 * JFo feels powerful
<JFo> :P
<JFo> well, if you feel it is worthwhile, I can look up the milestones for .34 and .35 and add them I guess
<JFo> not sure what the benefit is though
<ogasawara> JFo: not sure who actually looks at that page
<JFo> same here
<JFo> or if it has some impact on anything in bugs
<ogasawara> JFo: and it seems annoying you'd have to go and set the milestone for each -rc kernel that comes out
<JFo> yep, we are thinking the same
<ogasawara> JFo: maybe just set 2.6.35-rc1, 2.6.35-rc2, and 2.6.35-rc3 and call it done
<JFo> so maybe I just do it for the kernels we determine to use for a release
<JFo> sounds fine
<ogasawara> JFo: yah, I wouldn't bother with 2.6.33 or 2.6.34
<JFo> yeah
<JFo> k
<JFo> will do
<JFo> ogasawara, is there a good place to find release dates for RC?
<ogasawara> JFo: hrm, just a sec and let me see if I can find you something
<JFo> ooh, I may have found something
<ogasawara> JFo: shoot, I thought the kernel version map might have it
<JFo> I found an RSS feed for releases
<ogasawara> but doesn't :(
<JFo> lemme check
<JFo> ogasawara, I found http://www.kernel.org/kdist/rss.xml
<JFo> it shows release dates :-)
<JFo> June 11 was RC3 yes?
<ogasawara> JFo: yep that sounds right
<JFo> RC2 June 6?
 * JFo is so handy
<JFo> wait a sec...
<ogasawara> JFo: you have the git tree cloned locally?
<JFo> ogasawara, I do
<ogasawara> JFo: git show v2.6.35-rc3
<smb> bjf, sconklin Ok, I am finished over there
<bjf> smb, just be a sec, getting mumble setup for today
<maco> JFo: that rss feed doesnt look like it agrees with you...
<JFo> ogasawara, sweet
<ogasawara> JFo: wash, rinse, repeat for the others
<JFo> ogasawara, :-P
<JFo> maco, how so?
<maco> JFo: that rss feed is showing rc2&3 on the 11th
<maco> (you sound more likely to be right)
<JFo> I don't see that
<JFo> oh no, that is git6 of RC2
<JFo> I looked back for the RC2 release
<maco> oh
<maco> um ok. im confused. i dont see june 6 anywhere on there
<jaminc> alright, this just more and more strange... with the current stable lucid kernel (2.6.32-22-generic) I'm able to start VMs backed by a qcow2 file using libvirt just fine... the same VM with a mainline kernel fails to start via libvirt... however, changing ownership of the qcow2 file to root:root fixes the problem... anyone have ideas as to why?
<JFo> mainline:	2.6.35-rc2	2010-06-06
<JFo> maco ^ that is from that RSS
<JFo> ogasawara, odd that now it still isn't showing up
 * JFo tries something
<ogasawara> JFo: maybe refreshes hourly or something
<JFo> think I figured it out
<JFo> one sec
<JFo> ah well, I'll look back in on it later 
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/2.6.33/linux-image-2.6.32.15_2.6.32.15-2_amd64.deb
<ccheney> tgardner, thanks
<ogasawara> jjohansen: do you think we'll have the apparmor maverick update before Fri?
<jjohansen> ogasawara: yeah sorry, the testing took a little longer than I planned, I am working on the cleaned up rebase for you now
<ogasawara> jjohansen: sweet, thanks
<tgardner> apw, mumble me when you get around
<ccheney> tgardner, 32.15 didn't work either, was that the test to see if it was the packaging issue?
<tgardner> ccheney, yep, so I've gotta figure out what the hell I'm doing wrong.
<ccheney> tgardner, ok, not sure what is causing it, i haven't seen that kind of error before
<ccheney> tgardner, when i remove recordfail i get a little further
<ccheney> it says the following:
<ccheney> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<ccheney> the system uses lvm
<tgardner> ccheney, hmm, thats definitely an initramfs issue, or perhaps teh default config doesn't build in the right drivers
<ccheney> oh
<ccheney> tgardner, http://pastebin.com/6GMaie6T not sure if that is useful for you to see, but it does look normal to me at least like the other grub entries that work
<maks_> tgardner: no
<maks_> aboves message means that it is a bootloader issue.
<maks_> aboves is a linux-2.6 message when it can't mount root.
<maks_> this means it never got the initramfs.
<tgardner> maks_, well, its still a apackaging issue in the way I was building. I used the internal kpg-deb target
<maks_> well i didn't see the kernel commandline
<maks_> it may well be that the initramfs wasn't passed at all.
<tgardner> maks_, likely, thats why I suggested it was an initramfs issue. its the normal culprit when you can't mount the root FS.
<maks_> no that is not an initramfs issue itself :P
<maks_> as it wasn't loaded ;)
<tgardner> semantics
<maks_> ccheney: in http://pastebin.com/6GMaie6T  why do you have toplevel dir entries?
<maks_> just use the stuff in /boot/
<maks_> hmm don't see a faulty entry although if those symlinks exists
<maks_> ccheney: does ls -l /initrd.img-2.6.32.15 really exist?
<ccheney> maks_, i didn't modify that, its the way maverick does it
<ccheney> maks_, maybe its buggy?
<ccheney> all i did to it was run update-grub2 to make sure it was up to date
<ccheney> after installing 32.15 for some reason it didn't even appear in the boot list until i did that
<maks_> can you please anser the ls
<maks_> hmm i might have an outdated grub2 here in Squeeze, but I see /boot/ everywhere.
<ccheney> maks_, hmm let me see something
<ccheney> it might make sense, looking
<ccheney> maks_, yea since i am using lvm / is the non lvm boot dir
<ccheney> so that should be sane
<ccheney> http://pastebin.com/jm6trFQv
<ccheney> http://pastebin.com/a5JpZZVT
<ccheney> those are my fdisk -l output and lvscan output
<maks_> ls -l  /initrd.img-2.6.32.15 # or you land on fucking ignore
<ccheney> there is no  /initrd.img-2.6.32.15 on my root filesystem but that isn't what grub2 is looking at when it boots (or shouldn't be anyway) since it is lvm
<ccheney> i can create a link to it but it won't work unless grub2 magically reads lvm volumes now, will verify
<ccheney> maks_, and note the other kernels also work fine without any symlink there
<maks_> hmm so it sees /boot as /, okay fun never saw that yet.
<maks_> and the ls -l /boot//initrd.img-2.6.32.15 exists ?
<ccheney> still did not work with the same error as expected
<ccheney> yes
<ccheney> i also regenerated the 33-rc1 initramfs before tgardner sent me a 32.15 to test with, regenerating it did not help at least for the 33-rc1 kernel he sent me
<maks_> what's it's size, compared to the others?
<maks_> (have to run so will read later)
<tgardner> jjohansen, what else besides 'fdr binary-server AUTOBUILD=1 no_dumpfile=1' ? I'm getting errors when its generating the package, 'dh_installdeb: package linux-image-2.6.32-23-ref-server is not in control info'
<ccheney> maks_, much larger from what i recall, iirc he thought it was not stripped
<ccheney> system just finished booting, looking now
<jjohansen> tgardner: hrmm I don't recall ever seeing that
<ccheney> maks_, the two that don't work are over 85MB, and the one that does is 11MB for the initrd
<jjohansen> tgardner: what you have looks good to me, I haven't done it for a while, maybe something in the updated build infrastructe?
<jjohansen> I have just kicked off a build to see what I get
 * ccheney wonders if initramfs/initrd can get too big to work
<tgardner> jjohansen, shit, I didn't want to have to _think_ about this.
<tgardner> ccheney, how do I replicate what you have for a testbed?
<ccheney> tgardner, i installed maverick alpha 1 and then installed your image (i did a few things in between but no package upgrades)
<tgardner> ccheney, no, I meant how do I replicate what you're doing with UEC ?
<tgardner> isn't that is whats failing?
<ccheney> tgardner, oh i see
<ccheney> yea, i can email you the script i am running
<tgardner> ccheney, I don't know jack shit about UEC, so make it an installation guide for idiots.
<ccheney> ok
<ccheney> tgardner, ok i wrote it up, if you have any questions let me know
<ccheney> tgardner, it should be fairly straight forward, the test doesn't really need any knowledge of UEC beyond getting through the install steps I referenced in the email
<ccheney> tgardner, and to see if the issue is happening you grep under /var/log/eucalyptus after running the script for the 'pad block corrupted' message as noted in the bug report
<tgardner> ccheney, ack
<cking> tgardner, emerald isn't too happy, it's kinda stuck on some builds
<tgardner> cking, emerald.mills ?
<cking> yep
<jjohansen> yeah, for me too
<tgardner> oops in dmesg
<cking> yep, looks kinda wrong to me
<tgardner> cking, jjohansen: I'm installing ogasawara's latest kernel, rebooting in a sec
<cking> cool
<jjohansen> tgardner: thanks
<tgardner> cking, jjohansen: maybe its this: http://launchpadlibrarian.net/50396107/qemu-kvm_0.12.3%2Bnoroms-0ubuntu9_0.12.3%2Bnoroms-0ubuntu9.1.diff.gz
<jjohansen> ccheney: ^
<tgardner> jjohansen, no, I meant that the mem leak in qemu might be why processes stall on emerald after awhile
<cking> seems to happen a lot now we do a load of QEMU assisted builds
<jjohansen> tgardner: yeah, I hadn't looked at it yet when I did that and just assumed was for the ccheney conversation, and tab completion had gotten you :)
<JFo> pgraner, I find the last comment here disturbing: bug 365739
<ubot2> Launchpad bug 365739 in linux (Ubuntu) "Loud cracking sound before suspend to RAM (affects: 1) (heat: 16)" [Undecided,Fix released] https://launchpad.net/bugs/365739
<JFo> sorry, wrong bug
<JFo> bug 592598
<ubot2> Launchpad bug 592598 in linux (Ubuntu) "dell latitude 2110: speakers work; headphones don't work (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592598
<JFo> pgraner, ^^
 * tgardner lunches
<jjohansen> -> lunch
<apw> tgardner, been laid flat by my head ... will try and catch you after your lunch
<tgardner> apw, no problem, I've about gotthe local mainline build stuff figured out. I'm gonna add some notes to the README in the giot repo
<cking> this day is never gonna end
 * ogasawara lunch
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/v2.6.33-rc1-maverick/
<ccheney> tgardner, thanks
<tgardner> ccheney, if -rc1 works for you, then watch at http://kernel.ubuntu.com/~rtg/mainline/ for the next one to appear in about an hour
<ccheney> it booted mostly ok, some alsa backtrace, testing now
<ccheney> tgardner, looks like the problem is there in 33rc1
<ccheney> tgardner, i'm seeing some of the errors already, I have it run the test 10 times but it definitely looks like it was in rc1 already
<tgardner> ccheney, ok, I'll start bisecting between 2.6.32.15 and 2.6.33-rc1
<ccheney> ok
<ccheney> tgardner, it finished and failed all 10 tries
<tgardner> ccheney, k
<bguthro> I have what I'm sure will come across as a stupid question but here goes... I'm used to developing outside of a .deb environment...so I am still getting used to this build system. How can I do an incremental build, without rebuilding the entire tree? I start by doing DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 NOEXTRAS=1 skipabi=true skipmodule=true fakeroot debian/rules binary-generic - but then subsequent executions of that do not seem to build the
<bguthro>  tree, only install it...
<bguthro> If I'm working on just 1 module - what is the best way to do iterative work?
<jjohansen> bguthro: when developing and doing incremental builds, I actually build outside of the .deb env
<jjohansen> bguthro: once done with that I will move patches inside the deb
<jjohansen> its just faster, and no overhead of packaging up the kernel into .debs etc either
<bguthro> jjohansen: so you have the tree, and just do a "make modules", "make install" ?
<jjohansen> basically
<bguthro> ok, thanks.
<jjohansen> you need to make the kernel first and install it
<bguthro> clearly
<jjohansen> then you can just install the modules to that kernel
<bguthro> and a depmod -a...
<jjohansen> yeah
<bguthro> ok, thanks
<jjohansen> the you need update-initramfs, and update-grub
<kees> ogasawara: my hangs are i915 related.  yay
<ogasawara> kees: yuck
<kees> ogasawara: I have to blacklist both i915 and intel_agp.  though that really doesn't help because as soon as udev start on the real root, it loads them anyway and hangs the system.  and if I blacklist them in both initramfs and real root, X still tries to load them.  *stabby*
<ogasawara> heh, stabby
<ogasawara> kees: you said this started with 2.6.35-rc1?
<kees> ogasawara: yup.
<apw> bguthro, you can remove the build stamp from the debian/stamps directory then it will only incrementally build
<ogasawara> bah, stupid disconnect.  kees, did you see my above msgs?
<kees> 21:22 < ogasawara> kees: you said this started with 2.6.35-rc1?
<kees> 21:22 < kees> ogasawara: yup.
<kees> ogasawara: that's all I saw
<ogasawara> [14:40:21] <ogasawara> kees: was browsing through rafael's regression list http://lkml.org/lkml/2010/6/20/143 but I'm not seeing anything noted there similar to what you're seeing
<ogasawara> [14:40:34] <ogasawara> kees: ogasawara@emiko:~/linux-2.6$ git log --pretty=oneline v2.6.34..v2.6.35-rc1 -- drivers/gpu/drm/i915 | wc -l
<ogasawara> [14:40:34] <ogasawara> 71
<ogasawara> [14:40:54] <ogasawara> kees: If I started building bisect kernels, could you test?
<kees> ogasawara: yup, totally
<ogasawara> kees: amd64?
<kees> ogasawara: yuppers
<kees> ogasawara: if you show me how to do the bisect while keeping a sane debian/ directory, I can do it :)
<ogasawara> kees: was going to sorta try and see if I could just bisect amongst those 71 commits first
<ogasawara> kees: I don't think there's a sane way to do that though
<ogasawara> kees: using 'git bisect' at least
<ogasawara> kees: I wanted to avoid having to bisect all of 2.6.34..2.6.35-rc1
<ogasawara> kees: I started doing the following on tangerine . . . git bisect start v2.6.35-rc1 v2.6.34 -- drivers/gpu/drm/i915
<ogasawara> kees: I think the debian directory is still ok, but we'll see how long that lasts
<ogasawara> nm, it's hosed
<ogasawara> kees: http://kernel.ubuntu.com/git?p=ubuntu/kteam-tools.git;a=blob;f=mainline-build/README;h=448b7308f357764e812a607033d717ce7625962f;hb=HEAD
<ogasawara> kees: I think I can use those instructions, will let you know
<kees> ogasawara: hunh.  okay
#ubuntu-kernel 2010-06-24
<ogasawara> kees: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/597075/comments/20 , I posted the test kernel in that comment
<ubot2> Launchpad bug 597075 in linux (Ubuntu) "2.6.35 hangs at boot due to regression in i915 or intel_agp (affects: 1) (heat: 3382)" [Undecided,Triaged]
<ogasawara> kees: I've gotta bail for a few hours but let me know (either here or in the bug) if that kernel boots or hangs
<psusi> jjohansen, you remember that screwed up memory problem I was talking about the other night?  it's back... and I found a thread on the maverick testing boards and think it correctly identifies the cause as ureadahead doing a profile and mounting the debugfs... funny though though, is that the slab info doesn't seem to show the allocated memory anywhere
<psusi> son of a bitch... it's the fscking trace buffer...
<cking> morning lag
<lag> Morning :)
 * lag has a fuzzy head :)
<jjohansen> cking, lag: good evening and good night :)
<dmarkey> anyone know where i can get the config.gz for http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/
<amitk> dmarkey: don't you see it in /proc/config.gz when you boot the kernel?
<dmarkey> nope, aint there
<dmarkey> cant waste precious memory on that it seems :)
<soren> dmarkey: All Ubuntu supplied kernel packages should be accompanied they their config in /boot/config-<version string>
<dmarkey> ah yes, there we go
<dmarkey> hanks
<VanessaE> question:  I have a Dell Inspiron 9200 laptop.  All components seem to work fine except USB.  The kernel detects it, but no devices are recognized.  Nothing I plug in seems to get any reaction at all, except that power to the port seems to work.
<VanessaE> no USB-related messages of any kind are added to dmesg except during the kernel's initial scans of the USB controller/hub.
<dholbach> hey guys
<dholbach> we're planning Ubuntu Developer Week right now - would anyone of you interested in talking a bit about kernel team workflow, getting fixes in, dkms or anything else?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<kraut> moin
<apw> moin
<ogra> apw, up early ? 
<smb> ogra, Heh, its just one hour difference in tz
<apw> cking, http://www.mail-archive.com/debian-bugs-forwarded@lists.debian.org/msg13966.html
<apw> this might be what is triggering which seems like a miss implementation of the backoff mechanism
<cking> apw, that's great - thanks!
<apw> cking, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509089
<ubot2> Debian bug 509089 in dhcp3-client "dhcp lease negotiation takes longer than necessary" [Normal,Open]
<apw> cking, that bug has the patches, and it looks like if we had them you'd need a configuration change too in /etc/something
<cking> apw, hopefully awe can pick that work up as it's his kinda domain
 * cking punts
<apw> cking, yep
 * cking lunches
<tgardner> ccheney, that last commit 41440ffe21f29bdb985cab76b2d0b06d83e63b19 didn't build. Am investigating
<ccheney> tgardner, ok
<Daviey> Hey!  Is there an informal freeze date for the A2 release?
<ccheney> tgardner, Daviey's question is in relation to potentially getting the kernel fixed for the issue we are investigating before A2
<tgardner> ccheney, dunno about a fix yet. today is likely the last day that ogasawara will accept patches for A2
<ccheney> tgardner, ok
<ccheney> Daviey, see ^
<tgardner> it depends on _what_ the fix is.
<ccheney> ok
<tgardner> ccheney, plan a lucid kernel for your UEC A2 release
<ccheney> o
<tgardner> plan on*
<ccheney> er ok
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/41440ffe21f29bdb985cab76b2d0b06d83e63b19-maverick/linux-image-2.6.32-020632g41440ff-generic_2.6.32-020632g41440ff_amd64.deb
<ccheney> tgardner, thanks
<ccheney> tgardner, appears good, test still running
<tgardner> ccheney, k, lemme know for sure.
<ccheney> tgardner, i'm doing an extra test this time to make sure that lack of the error means its actually fixed, may take about 30m, will let you know when i'm done, that kernel though didn't show the error message expected
<tgardner> ccheney, ack
 * ccheney had to reinstall his node controller due to breakage, so he can make it run an instance using the image that was supposedly properly registered
<ccheney> tgardner, it got a bit more involved my cloud controller apparently forgot how to see nodes so i am reinstalling it too
<ccheney> tgardner, once that is done i will test the 701791c to make sure it still fails and then retest 41440ff to see it works and then run the instance, assuming it can see the NC again
<tgardner> ccheney, ack
<tseliot> apw: I've sent both of my patches for radeon to the kernel mailing list
<ogasawara> tseliot: The second email doesn't seem to include the patch, "Add support for the ATIF ACPI method to the radeon driver"
<tseliot> ogasawara: oops, let me attach the patch then
<ogasawara> tseliot: you mention it's been accepted upstream and should land in 2.6.36 which is great.  Is the patch residing in an upstream maintainers tree at the moment?
<ogasawara> tseliot: if so, could you point us to which tree and commit just so we can track it
<tseliot> ogasawara: AFAIK they're trying to see if they can include it in 2.6.35 (if Linus agrees)
<ogasawara> tseliot: Ooo even better
<tseliot> patch sent
<MaximLevitsky> what udev maveric will eventually use?
<sconklin> https://bugs.launchpad.net/ubuntu/lucid/+source/linux/+bug/590783
<ubot2> Launchpad bug 590783 in linux (Ubuntu Lucid) (and 1 other project) "Lucid sfc stable updates from 2.6.33.4 (affects: 1) (heat: 241)" [Medium,In progress]
<gnarl> sconklin, Are there newer things than there are already in or did that not get updated with the upload?
<sconklin> gnarl: I'm not following you
<gnarl> sconklin, I just saw you posting the sfc update bug number
<gnarl> sconklin, And the current proposed kernel wold contain some updates to sfc from 2.6.33
<sconklin> That's one of the patches I'm putting on my branch for you to inspect, and I was adding the buglink, and the bug was marked incomplete, so I asked Tim about it
<dholbach> we're planning Ubuntu Developer Week right now - would anyone of you interested in talking a bit about kernel team workflow, getting fixes in, dkms or anything else?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
<sconklin> gnarl: that's interesting because the patch applies
<gnarl> sconklin, Hm, maybe I so much was about to do it that I thought I had ...
<sconklin> gnarl: I'm about to fetch a fresh tip and reapply them, let me try that
<gnarl> sconklin, Ok. It could really just be that I thought to have done without actually having done so
<sconklin> gnarl: possibly, because there was no APPLIED message sent and it was not marked as acked in patchworks
<gnarl> sconklin, So you better just ignore me
<gnarl> sconklin, Cannot see anything sfc related applied recently
<sconklin> gnarl: at my peril . . . :)
<sconklin> gnarl: yes, it applied ok, and I've just pushed to the stable-lucid branch in my repo on zinc. If that passes your inspection I will apply those patches to the master and push to the distro repo
<gnarl> sconklin, Ok let me look right away
<sconklin> in sconklin/ubuntu-lucid.git
<gnarl> That would have been my guess
<gnarl> sconklin, Ok, two things which sadly will cause work for you, sorry about that. First (simpler) in the patch from Keng-YÃ¼ I'd add his signed-off-by (as he should have done). As those patches are actually in 2.6.33.y I would take those add a buglink, our acks and your sob. So we really follow the specific updates instead of one monolithic patch.
<sconklin> gnarl: add a buglink, our acks and my sob to what?
<sconklin> 2.6.33y patches somewhere?
<gnarl> sconklin, to the patches you would export from the 2.6.33.y tree
<sconklin> oh, I see.
<apw> gnarl, does he know about your mass patch updater script
<sconklin> gnarl: well ok, that's why we're doing it this way. Let me refactor it and then you can look again
<apw> ie, about exporting them as patches using that to add acks to the right ones etc and them git am ing them back onto the branch
<gnarl> sconklin, yes. You know you can get only those by git log (or format-patch) with the path added?
<gnarl> apw, Since yesterday, he should I beleive
<sconklin> gnarl: yes, thanks, though
<gnarl> If I did not dream again
<apw> good enough :)
<sconklin> no, we talked about it yesterday
 * bjf will brb
<sconklin> The Best Buy chumby-like ARM device is intentionally hackable, and $179 USD http://www.bunniestudios.com/blog/?p=1140
<ccheney> tgardner, the 41440ff is good
<tgardner> ccheney, ack
<ccheney> tgardner, verified with a running instance after rebuilding my cloud
<tgardner> ccheney, did you reverify the other versions? Or do you think it necessary ?
<ccheney> tgardner, i don't think its necessary, i saw something in the log for 41440ff that i thought might mean it was still broken but differently, but its running ok
<ccheney> tgardner, the older failed ones showed the pad block corrupted issue
<ccheney> i can do a quick smoke test to make sure its broken on 701791c
<tgardner> ccheney, k, I'll start the next build in the meantime
<ccheney> shouldn't take more than 10m to verify its actually broken
<apw> tgardner, homing in on a bug ?
<tgardner> apw, bisecting to see when the UEC guest kernel stopped loading
<apw> is this one where we seem to have a kernel interaction with uec, with the java bit ?
<tgardner> yep
<apw> getting close yet ?
<tgardner> apw, oh yeah, we're homing in on it. perhaps 3 or 4 more kernels
<ccheney> tgardner, its in pending state now, will wait a couple minutes to make sure it is stuck
<tgardner> apw, bug #588861
<ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/588861
<ccheney> apw, we're down to 2 days of commits, which may be a lot for the kernel (not sure the exact number in between)
<tgardner> ccheney, 641 commits left after this next build
<apw> ccheney, could be lots, could not be all depends 
<ccheney> heh ok, yea i thought they get a pretty large amount per day
<ccheney> should be less than 10 kernels anyway :)
<ccheney> maybe we'll get lucky
<ccheney> ok i'm calling 701791c bad its still not starting and had the same pad block corrupted message
<tgardner> ccheney, wfm
<sconklin> gnarl: I just pushed a new stable-lucid branch to my repo, which should address the things we talked about.
<gnarl> ok looking
<ccheney> tgardner, new kernel failed to build also, not sure if its the same issue as before
<tgardner> ccheney, it is, I've corrected it and am continuing the build
<ccheney> ok
<gnarl> sconklin-lunch, sfc patches look good. The sob of keng-yÃ¼ should be reordered to be the first one. then the acks and you sob
<tgardner> gnarl, what does keng-yu have to do with the sfc patches?
<gnarl> tgardner, nothing. thats another patch
<gnarl> I might have been a bit ambiguous there
<tgardner> hmm, just a bit
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/23eb3b64b5e44680c867e165fe1cd18e57fba255-maverick/linux-image-2.6.32-020632g23eb3b6-generic_2.6.32-020632g23eb3b6_amd64.deb
<sconklin> gnarl: should I that one thing (kengyu sob) and push to distro?
<gnarl> sconklin, sure go ahead
<ccheney> tgardner, thanks
<tgardner> ccheney, lunch, back in 20-30
<ccheney> tgardner, ok
<ccheney> tgardner, that one looks good as well, will run an instance since you will be gone for a bit
<sconklin> gnarl: pushed, you can review it if you want and make sure it's ok
<gnarl> sconklin, np. a sec
<gnarl> sconklin, Looks fine by me. So we will see that tomorrow as a new pre-proposed if apw has not broken things while fixing them. :-P
<kees> ogasawara: gah, sorry, I got it wrong.  .35-1.1 works, .35-2.2 fails.  I've updated 597075 to reflect this.
<ogasawara> kees: cool, maybe less to look at then
<ogasawara> kees: if I recall correctly, 2.6.35-1.1 was -rc1 based and 2.6.35-2.2 was -rc2 based
<kees> oh good, I was worried it would be worse.  :P
<tgardner> ccheney, ack, will start the next build
<ccheney> tgardner, thanks, just had phone call, sorry for the lag
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9553426/ , whenever you have time to test
<ogasawara> kees: the deb has an odd 2.6.34 version name but please test anyways
<kees> ogasawara: rebooting, brb
<kees> ogasawara: 2.6.34-020634g9553426 fails
<ogasawara> kees: k, I'll kick off the next build
<kees> cool
<ogasawara> kees: just fyi, I'm putting notes in the bug
<ogasawara> kees: no need for you to respond
<kees> ogasawara: okay, cool.  was just going to ask if you wanted me to reply here, the bug, or both.  :)
<tgardner> kees, would expect a powerpc qemu schroot to work? It seems to get hung up in /usr/bin/make
<kees> tgardner: I've never tried that -- does the qemu emulator actually work for that?
<tgardner> kees, yep, I can get into the schroot, its breaking on Hardy, gonna try Maverick
<kees> tgardner: I've done armel and mips, and both of those were fine.  yeah might be a ppc-specific glitch.  the emulators are a little weird.
<tgardner> kees, we're doing a bunch of armel schroots
<tgardner> ogasawara pounds the hell out of 'em :)
<jjohansen> -> Lunch
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/734b415/
<ogasawara> kees: no hurry
 * ogasawara lunch
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/79a56ed0e11c7d924762062a0e2a46b87014498d-maverick/linux-image-2.6.32-020632g79a56ed-generic_2.6.32-020632g79a56ed_amd64.deb
<kees> ogasawara: 734b415 boots ok
<ccheney> tgardner, yep rebooting into it now :)
<tgardner> ccheney, you must be tailing the build log
<ogasawara> kees: ok nice, I'll kick off the next
<ccheney> tgardner, refreshing the page occasionally
<ccheney> seemed to hit it at just the right time, heh
<kees> ogasawara: your build will be done before my disk checks finish. :P
<ogasawara> heh
<ccheney> tgardner, bad
<tgardner> ccheney, ack
<ccheney> tgardner, how wide is the range now, ~ 150 ?
<tgardner> ccheney, Bisecting: 169 revisions left to test after this
<tgardner> ccheney, I'm also working on moving the build scripts to a much faster machine. They are unfortunately somewhat specific to zinc.
 * apw looks bashful ... its on my list
<ccheney> tgardner, great :)
<tgardner> apw, what is BUILD_CONFIG_OVERRIDE ? I can't find it
<apw> its an old way of setting the config in older releases, replaced by OVERRIDES
<apw> note that we put the data in OVERRIDES and the point BUILD_C_O to it, backwards compatible
<tgardner> apw, I'm trouble getting schroot to digest that command line
<apw> well you can drop the variable for any release where git grep doesn't find it in debian*
<tgardner> apw, ah, seems much happier without that
<apw> tgardner, i must admit in a lot of my scripting i change things into
<apw> { echo "commands" } | chroot /bin/bash
<tgardner> apw, duh, that looks like a simple work around. I've even done it for other cases. why didn'tI remember :)
<apw> tgardner, heheh always the way ... good luck
<tgardner> apw, I've got it building on emerald. it runs circles around zinc
<apw> tgardner, nice ... that should get u moving what about 3x the speed
<tgardner> apw, closer to 10x
<apw> i'll bet, you might want to also setup a ccache in the shell that you run it from too
<apw> bet that'll speed up the second one
<tgardner> apw, actually, I've done some benchmarking with ccache on the emerald class machines. It doesn't really save much. In a few runs I found it made only about 10 seconds difference
<apw> interesting .. 
<tgardner> I think the disk is fast enough....
<tgardner> multiple spindles and all
<tgardner> ogasawara, are you doing anything on emerald.mills? I think I'm gonna revert to the Lucid kernel. 
<ccheney> wow 10x faster is nice, then i might be the slow factor :)
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9962c92/
<ccheney> new image :)
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/e33c01972239fee4696679ae5f7d1f340f424999-maverick/linux-image-2.6.32-020632ge33c019-generic_2.6.32-020632ge33c019_amd64.deb
<ccheney> :-)
<ogasawara> jjohansen: the atop patch set, is that something the server team is hoping to land in Alpha2? or can it wait post Alpha2
<tgardner> ogasawara, it needs some more study as I think its a bit crackful
<jjohansen> ogasawara: it needs debate
<jjohansen> definitely not alpha2
<ogasawara> jjohansen: cool, cuz I didn't want to have to slam them in :)
<tgardner> jjohansen, do they have a good use case?
<jjohansen> tgardner: hrmm, when I asked they said it was something that had been repeatedly requested and would be really nice to have
<jjohansen> I will but jose, a ttx for specific use cases
<tgardner> jjohansen, repeatedly ? first I've heard of it
<jjohansen> well, I guess its more of a server thing
<jjohansen> I hadn't heard of it until a couple weeks ago
<kees> ogasawara: 996 fails
<jjohansen> there is a bug filed from 2007 though
<jjohansen> Bug #134159
<ubot2> Launchpad bug 134159 in atop (Ubuntu) " atop Kernel patch doesn't work (heat: 3)" [Undecided,Confirmed] https://launchpad.net/bugs/134159
<jjohansen> tgardner: also not that it is a nice to have, it isn't a hard requirement
<tgardner> jjohansen, thats not exactly a bug.
<ogasawara> kees: ack, will build the next
<kees> ogasawara: thanks :)
<jjohansen> tgardner: no, but it shows some time line of interest
<ccheney> tgardner, bad
<tgardner> ccheney, ack
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/951c30d135390a108f102b0f6e3cfa6241f2a1aa-maverick/linux-image-2.6.32-020632g951c30d-generic_2.6.32-020632g951c30d_amd64.deb
<ccheney> thx
<ccheney> tgardner, bad
<tgardner> ccheney, ack
<tgardner> ccheney, I'm breaking for a couple of hours. I've started the next cycle. If successful it should copy bits to zonc.
<ccheney> ok
<tgardner> zinc*
<jjohansen> ogasawara: hey on the AA patch rebase, instead of splitting kees's patch I could probably just move it to after the AA patches and fix the AA conflict if that would be easier for you
<ogasawara> jjohansen: no worries, I've already got it applied to my local tree.  I kept it split like you had it
<jjohansen> ogasawara: cool
<ogasawara> jjohansen: just finishing up test builds, then will do a few boot tests and upload
<jjohansen> okay let me know if you need anything
<kees> ogasawara, jjohansen: hopefully that should change when I request Yama get pulled into maverick.  I'll have a patch that bolts it to AppArmor so hopefully it won't cause conflicts.
<ogasawara> kees: cool
<tgardner-afk> kees, does that mean we'll drop the other soft/hard link patches?
<jjohansen> kees: cool, let me know if you want any help on it
<kees> tgardner-afk: yeah, the symlink/hardlink/ptrace stuff will be done via Yama, and then I'll add a patch to bolt Yama into the kernel somehow.. maybe not against AppArmor since that would mean running SELinux on ubuntu would lose the protection.
<tgardner-afk> kees,  oh, 'cause we can't yet chain or stack LSMs ?
<kees> tgardner-afk: yup :(
<sbeattie> kees: clearly you need to take eparis' patch against selinux. :-)
<kees> sbeattie: that too
 * ccheney is somewhat confused, trying to read through the commits that are in between what is good and bad and found it seems 2.6.32 was released in the middle of that, and thought we already proved 2.6.32 was good
<ccheney> maybe i didn't look at the right spot
<ccheney> hmm yea i didn't, but i don't see the commit in the list on the web ui
<ccheney> ogasawara, is there a way using the git.kernel.org to see all commits between two git revisions?
<ccheney> the log for the commits i mean
<tgardner-afk> ccheney, http://kernel.ubuntu.com/~rtg/mainline/476d42f138ba82389a92a894d8a630a70d36278f-maverick/linux-image-2.6.32-020632rc5g476d42f-generic_2.6.32-020632rc5g476d42f_amd64.deb
<tgardner> got delayed by a t-storm
<ogasawara> ccheney: hrm, not sure how to do that via the web
<ccheney> ogasawara, ok
<ogasawara> ccheney: if you have a local clone of the git tree I can give you the command
<ccheney> ah ok, i thought maybe there was way to do it on the web interface
<ogasawara> ccheney:  there might be, I'm just unaware
<ccheney> ok
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/7648fa9/
<ccheney> the timestamps seem out of order but its probably because the commit i am looking at is part of a merge
<ccheney> tgardner, bad
<tgardner> ccheney, ack
<erichammond> jjohansen & co: Haven't chatted in a while.  Hope things are going well.  I have a client who runs Asterisk on Amazon EC2 using Ubuntu 10.04.  He's having problems with choppy voice and limits on the number of concurrent phone calls per server because of the 100Hz Ubuntu kernels on EC2.  Back in 2009 we discussed this and you were interested in building a 1000Hz kernel for him to try, but things sort of fizzled out as other prioriti
<erichammond> How should I or he go about making the request for a test 1000Hz Ubuntu kernel for EC2?
 * ccheney thinks the next one should be in the 10 commit range :-)
<tgardner> ccheney, Bisecting: 18 revisions left to test after this
<ccheney> ok
<jjohansen> erichammond: file a bug against maverick and subscribe me and ttx
<ccheney> tgardner, do you have a way to pastebin the log of those commits?
<erichammond> jjohansen: Cool, will do.  No chance for Lucid given the development process?
<jjohansen> I think it unlikely
<jjohansen> but maverick kernels will be supported on Lucid
<tgardner> ccheney, https://pastebin.canonical.com/33985/
<ccheney> thanks
<erichammond> jjohansen: Fascinating, thanks.
<tgardner> erichammond, they already are, look in the kernel-ppa
<erichammond> tgardner: What already are what?
<ccheney> heh probably one of the big merges in the list :)
<tgardner> The Maverick kernels are already being built for Lucid: http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu
<tgardner> erichammond, or a better URL is: https://edge.launchpad.net/~kernel-ppa/+archive/ppa
<erichammond> tgardner: I see, thanks.  This Asterisk/EC2 user would still need ones built with 1000Hz for EC2 which is a different process, I believe.
<kees> ogasawara: 7648fa9 boots ok
<tgardner> erichammond, its worth trying just to see if the scheduler fixes help, HZ setting not withstanding
<erichammond> tgardner: We were told that back when upgrading from Jaunty to Karmic and now he's running Lucid.  Are there significant changes between Lucid and Maverick?
<ogasawara> kees: cool, will kick off the last test build
<tgardner> erichammond, oh yeah, though I don't have hard numbers.
<erichammond> tgardner: Cool.  He sounds very motivated, so I'll provide him with instructions on how to test with Lucid against the Karmic kernel on EC2.  I guess I'll need to get the new kernel modules installed on a new image as well as RightScale integration, and so on.
<tgardner> erichammond, I assume you know how to do that? 'cause I sure done :)
<tgardner> don't*
<ccheney> tgardner, build failed
<tgardner> ccheney, I fixed it, its copying right now
<ccheney> ok
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/5db5d64277bf390056b1a87d0bb288c8b8553f96-maverick/linux-image-2.6.32-020632rc3g5db5d64-generic_2.6.32-020632rc3g5db5d64_amd64.deb
<ccheney> ok
<tgardner> ccheney, now I'm really gone. back in an hour or two
<ccheney> ok
<ccheney> tgardner-afk, prelim looks good
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9908ff7/
 * ccheney guesses at the next one failing since the log entries point that way
<kees> ogasawara: 9908ff7 fails
<ogasawara> kees: ack
<kees> ogasawara: does that leave us at the end, or is there one more?
<ogasawara> kees: I lied, I thought that was going to be the last test build, kicking off one more.
<kees> ogasawara: cool.  I wasn't sure how to part the git bisect output
<ogasawara> kees: once we isolate the commit, I'll have you do two more tests.  one with a mainline tree with the commit reverted and one with the maverick tree with the commit reverted.
<ogasawara> kees: it's down the following 3 commits
<ogasawara> 9908ff736adf261e749b4887486a32ffa209304c drm/i915: Kill dangerous pending-flip debugging
<ogasawara> 9a7e8492d17394a81d5534abf90b5b2ada7ea3c0 drm/i915: Storage class should be before const qualifier
<ogasawara> 7648fa99eb77a2e1a90b7beaa420e07d819b9c11 drm/i915: add power monitoring support
<ogasawara> kees: the first you confirmed is bad, the last you confirmed is good, and I'm building the middle one as we speak
<ccheney> tgardner-afk, yea 5db5d64 is good
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/9a7e849/
#ubuntu-kernel 2010-06-25
<erichammond> tgardner: (Took a meeting break)  Yes, I should be able to take care of what is needed, though RightScale keeps changing the best way to set up their integration software with Ubuntu on EC2.
<kees> ogasawara: 9a7e849 boots ok
<ogasawara> kees: cool, I expected it to pass looking at the commit
<kees> I guess it's 9908ff736adf261e749b4887486a32ffa209304c causing the problem then?
<ogasawara> kees: yah, that's what the bisect is pointing to
<ogasawara> kees: k, I'm going to try revert just that commit and build a final test kernel
<kees> ogasawara: sweet
<tgardner-afk> ccheney, http://kernel.ubuntu.com/~rtg/mainline/4f570f995f68ef77aae7e5a441222f59232f2d0e-maverick/linux-image-2.6.32-020632rc3g4f570f9-generic_2.6.32-020632rc3g4f570f9_amd64.deb
<ogasawara> kees: this is the latest 2.6.35-6.7 Maverick kernel with the 9908ff7 reverted - http://people.canonical.com/~ogasawara/lp597075/2.6.35-6.7-9908ff7/
<ccheney> tgardner-afk, thanks
<ogasawara> kees: I'm still building the mainline kernel with the commit reverted
<ccheney> tgardner-afk, looks good
<ccheney> be back in about 30m
<ogasawara> kees: http://people.canonical.com/~ogasawara/lp597075/2.6.35-rc3-9908ff7/ - that's the latest 2.6.35-rc3 mainline kernel with 9908ff7 reverted
<kees> ogasawara: lp597075/2.6.35-6.7-9908ff7 did not boot :(
<kees> trying the mainline next...
<ogasawara> kees: ugh, was afraid of that
<kees> ogasawara: :( lp597075/2.6.35-rc3-9908ff7 did not boot either.
<ogasawara> boo
<kees> ogasawara: this is really odd.  are there maybe multiple problems?
<ogasawara> kees: I'm thinking it's a commit outside of i915 that might be triggering the i915 issue
<kees> oh, the bisection was targetting only changes in i915, but there were other commits between it?
<ogasawara> kees: yep
<kees> gotcha.  craps.
<kees> well, if you can show me the commnds you're running, I can take this over maybe.  I have access to the builders.
 * ccheney back
<ogasawara> kees: ooh, have access to tyler?
<ccheney> tgardner-afk, ok yea your 4f57f9 kernel was good
<ogasawara> kees: that's what I was using as the build box
<kees> ogasawara: yup, I'm on tyler
<ogasawara> kees: git clone git://kernel.ubuntu.com/ubuntu/kteam-tools.git
<kees> done
<ogasawara> kees: cp /home/ogasawara/kteam-tools/kteam-tools/mainline-build/mainline-build-one to /home/kees/kteam-tools/kteam-tools/mainline-build/mainline-build-one
<ogasawara> kees: It's just a tweaked version of the script to use the tyler chroots
<tgardner-afk> ogasawara, did you swipe the one I've been using on emerald?
<kees> ogasawara: okay (removed extra /kteam-tools from path, but good now)
<ogasawara> tgardner-afk: nope, saw you'd added a README to the repo and then tweaked the script to make it work for me on tyler
<tgardner-afk> I'm gonna spend tomorrow making them work on any machine, not just zinc
<ogasawara> kees: oops, copy and paste error
<ogasawara> tgardner-afk: that'd be awesome, I found it really useful doing these mainline bisects for kees
<tgardner-afk> ogasawara, yep, I've been doing 'em for 2 days now
<ogasawara> kees: so I did a mkdir lp597075
<ogasawara> kees: just to keep things separate
<erichammond> tgardner: The currently published Maverick kernel on EC2 is 2.6.32-305.9.  Do you know if the "scheduler fixes" you mentioned are available in that version or would we need to wait for the next release?
<kees> ogasawara: okay
<ogasawara> kees: then in lp597075 I cloned the mainline git tree, git clone --reference /usr3/ubuntu/linux-2.6.git/ /usr3/ubuntu/linux-2.6.git/
<kees> okay, done
<ogasawara> kees: cd linux-2.6
<ogasawara> kees: then run the following to build `/home/kees/kteam-tools/mainline-build/mainline-build-one <sha1> maverick`
<kees> which sha1 do I want to start with?
<tgardner> erichammond, hmm, I have not backported the EC2 kernel from Maverick. All I have are the standard kernels. I may have mislead you thinking that a standard kernel would work, but thats only for UEC, not Amazon, right?
<ogasawara> kees: ah, so in a separate linux-2.6 tree I kept track of the bisect
<ogasawara> kees: git bisect start v2.6.35-rc2 v2.6.35-rc1
<erichammond> tgardner: We are only interested in Amazon EC2 kernels as this is where the application servers run.
<kees> separate tree? ooooh.  on tree doing the bisect, the other tree doing the builds?
<ogasawara> kees: right
<ogasawara> kees: I just liked being able to read the bisect output uninterrupted
<kees> ogasawara: and now I just get to do a full-blown bisect without limits
<tgardner> erichammond, right. I don't think jjohansen has a working Maverick kernel for EC2 yet, correct?
<ogasawara> kees: I think I could replay it, but am too lazy to look it up
<tgardner> ogasawara, you know it keeps a log? .git/BISECT_LOG 
<ogasawara> kees: yep :(  looked like around ~1500 commits between rc1 and rc2
<ogasawara> tgardner: there is?
<jjohansen> tgardner, erichammond: yes I am trying to get the EC2 kernel for Maverick up
<kees> ogasawara: so the sha1 I give is the one git bisect spits out?
<kees> i.e.:
<kees> 6$ git bisect start v2.6.35-rc2 v2.6.35-rc1
<kees> Bisecting: 373 revisions left to test after this (roughly 9 steps)
<ogasawara> kees: yep
<kees> [b1413357d924792e2e332dcb6b712a7fb2a5fb25] fbdev: fix frame buffer devices menu
<kees> ^^^ that?
<erichammond> tgardner, jjohansen: I saw a note about that in the latest server-team meeting summary, but I was able to get the Maverick alpha-1 AMI running on EC2.
<ogasawara> kees: yah, so use b1413..
<ogasawara> tgardner: well, I'll be damed.  /me makes a note
<jjohansen> erichammond: right
<kees> ogasawara: does mainline-build-one correctly maximize CPU parallelization in the build
<kees> ?
<tgardner> erichammond, my understanding from jjohansen is that it still fails in some zones
<ogasawara> kees: not sure about that, but it'd crank em out pretty fast
<tgardner> ogasawara, kees: it does
<jjohansen> tgardner, erichammond: specifically the pv-ops stuff fails in some zones, the full Xen has other bugs, and problems
<kees> fatal: 'maverick' does not appear to be a git repository
<kees> ogasawara: I seem to be missing something
<ogasawara> kees: shoot, forgot to have you add the remote
<kees> ah-ha!
<erichammond> tgardner, jjohansen: For this Asterisk test, we only need the 64-bit kernel in us-east-1, but it sounds like it will need to wait anyway.
<kees> ogasawara:  git remote add maverick /usr3/ubuntu/ubuntu-maverick.git/ ?
<ogasawara> kees: git remote add maverick git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
<jjohansen> erichammond: try me again tomorrow, I have another kernel I will be testing soon
<tgardner> kees, for i in dapper hardy jaunty karmic lucid maverick; do git remote add $i git://kernel.ubuntu.com/ubuntu/ubuntu-$i.git; done
<kees> oh, not the local one?
<ogasawara> kees: you could probably use the local one too
<ogasawara> kees: it's sync'd regularly
<tgardner> kees, it doesn't make much difference after the first pull
<kees> ogasawara, tgardner: cool, now it's rockin' :)
<ogasawara> kees: sweet
<tgardner> kees, tyler is a wuss, you oughta try emerald.
<tgardner> or tangerine
<kees> tgardner: I was doing my Yama builds on tangerine.  woof.
<tgardner> tangerine and emerald are basically the same machine
<kees> I wonder how much ccache would help when doing a bisect
<tgardner> kees, I found on emerald and tangerine it makes about a 10 second diff over a full 3 arch pass on Lucid
<tgardner> so, not much
<kees> holy cow, that's not so great.  :P
<ogasawara> kees: ok, I gotta bail for a bit.  keep me posted how the bisect goes.
<kees> ogasawara: cool; thanks!
<ccheney> tgardner, another build failure showed up
<tgardner> ccheney, copying now
<ccheney> ok
<ccheney> 150e6c6 ?
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/150e6c67f4bf6ab51e62defc41bd19a2eefe5709-maverick/linux-image-2.6.32-020632rc3g150e6c6-generic_2.6.32-020632rc3g150e6c6_amd64.deb
<ccheney> tgardner, good
<ccheney> tgardner, er it works i mean :)
<tgardner> ccheney, Bisecting: 2 revisions left to test after this
<ccheney> great :)
<jjohansen> back on later
<kees> ogasawara, tgardner: should I expect this thing to work on tangerine?  it only seems to build on tyler.
<kees> oh, er
<kees> /home/kees/kteam-tools/mainline-build/mainline-build-one: line 128: dch: command not found
<kees> heh
<tgardner> see  mine stuff in emerald:~rtg/kteam-tools/mainline-build
<tgardner> kees, see my*
<tgardner> kees, its in a transitional phase. I'm gonna fix it tomorrow so that it works everywhere
<kees> tgardner: okay, cool
 * kees runs away for dinner
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/e00ef7997195e4f8e10593727a6286e2e2802159-maverick/linux-image-2.6.32-020632rc5ge00ef79-generic_2.6.32-020632rc5ge00ef79_amd64.deb
<ccheney> testing
<ccheney> tgardner, works
<tgardner> ccheney, ack
<ccheney> looks like it must be cc56f7de7f00d188c7c4da1e9861581853b9e92f, the other commit is supposedly ps3 specific
<tgardner> ccheney, probably, but lets play it through
<ccheney> yea
<tgardner> ccheney, this one has a good vibe though.
<ccheney> tgardner, there is a v2 of the patch, if i understand what is on lkml that was posted on 5/29
<ccheney> may be related to the bug we are seeing, if it is indeed that patch causing the problem
<tgardner> ccheney, I'll have it in 5 minutes
<ccheney> ok
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/cc56f7de7f00d188c7c4da1e9861581853b9e92f-maverick/linux-image-2.6.32-020632rc5gcc56f7d-generic_2.6.32-020632rc5gcc56f7d_amd64.deb
<ccheney> testing
<benjamim>  Anyone can tell me if the current maverick kernel present on the PPA (2.6.35-5) already has vga-switchero compiled as default ?
<RAOF> Yes.
<RAOF> It deos.
<benjamim> thanks RAOF
<benjamim> i'm trying to switch to my RADEON graphics with "echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch"
<benjamim> but i receive a blackscreen
<benjamim> is the command right ?
<RAOF> I forget.
<RAOF> From what I understand, that's highly unlikely to work properly if X is running.
<ccheney> tgardner, failed test, i am going to verify e00ef79 is actually good and can run instances to be sure its the cc56f7d
<benjamim> yep, after type that command i restart X
<benjamim> but the screen just go black
<benjamim> Only the intel graphics are working
<RAOF> benjamim: I'd probably grep the git log for the switcheroo commit to see what to do.
<tgardner> ccheney, this next kernel is the absolute proof since that last commit is now skipped (if it doesn't fail)
<ccheney> tgardner, ok
<benjamim> RAOF, could you tell what is the file that the switchero log is stored ?
<RAOF> benjamim: It's not - it's in the VCS history.  You'd need to clone the kernel's git tree.  Alternatively, go to git.kernel.org and use the search box in Linus' tree.
<benjamim> oh, i did not know that, I'll take a look.
<benjamim> thanks for help RAOF
<ccheney> tgardner, yea e00ef79 ran an instance so its good, i saw a different type of failure but we think its a different unrelated bug
<ccheney> the other bug is probably due to eucalyptus not doing error checking
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/f21121cde6e617b90cd03ce083652ca543004dc2-maverick/linux-image-2.6.32-020632rc5gf21121c-generic_2.6.32-020632rc5gf21121c_amd64.deb
<ccheney> testing
<ccheney> tgardner, looks good so far
<tgardner> ccheney, play it all the way, just like the others.
<ccheney> tgardner, its still running, just giving early feedback :)
<ccheney> takes around 15m to run the test 10 times
 * ccheney has to go to the grocery store, bbia 1hr
<ccheney> so far passed the test 3/3 with 7 left to try
<tgardner> ccheney, k, see you in a bit
<tgardner> ccheney, back in the AM
<ccheney> i got swallowed by walmart
<ccheney> sorry for being gone so long :-\
 * ccheney needs to remember to look at the list his wife writes up before leaving to make sure it is detailed enough to buy
<jk--> 1) "items"
<smb> Morning
<cking> Good morning smb! Welcome to another wonder filled day
<smb> cking, Too true
<smb> cking, Just experienced the wonders of democratic bit reading. :-P
<LLStarks> apw or ogasawara: any chance that enable-multiple-ring-buffer.patch can get backported for maverick?
 * cking wonders what "democratic bit reading" is
<smb> LLStarks, Not apw and ogasawara will not be around till later
<LLStarks> okay
<LLStarks> any other kernel managers that i should speak to?
<smb> cking, You read 5 times and let the majority decide whether its 0 or 1
<cking> smb, not sure that's entirely a good idea. a dictatorship suits me better. as long as I'm in control ;-)
<smb> LLStarks, Depends on the urgency and the patch. And as I still wait for my mail to sync I don't even know whether apw has written something about this patch
<smb> cking, In my case democracy seems the better choice as that allows the EDID to be ok even with some monitor switch in between
<LLStarks> it's for vaapi support on intel
<cking> smb, I get your drift now
<LLStarks> kinda stupid to not have it since  libva is now in ubuntu archives
<LLStarks> http://intellinuxgraphics.org/h264.html
<smb> LLStarks, Have you sent the patch to kernel-team@lists.ubuntu.com with some short explanation?
<LLStarks> i'm not on the mailing list
<RAOF> That ended up missing 2.6.35, did it?  It's been on the intel-gfx lists for some time - I kinda thought it made it into Linus' tree.
<LLStarks> made 2.6.35 from what i've heard
<smb> LLStarks, You could still send to it. Though it then take a bit of time for it to get moderated to the list
<LLStarks> not sure though
<RAOF> Then rejoice, for Maverick will have 2.6.35
<LLStarks> like i said, i'm not sure if it made the cut
<LLStarks> ah. it did. http://permalink.gmane.org/gmane.comp.video.dri.devel/46855
<RAOF> git log says that its in 2.6.35-rc3, so it's in Maverick now.
<LLStarks> hopefully everything else required falls into place.
<RAOF> The easiest form of backporting!
<smb> RAOF, Very true
<smb> RAOF, Btw, just out of interest. There have been a few bugs about invalid EDIDs. Do you know whether they are all over adapter space or mainly intel?
<RAOF> The EDID processing code is in the shared drm code.  EDID processing recently got more strict about the checksum being accurate (ie: actually checking the checksum, rather than completely ignoring it).
<smb> RAOF, Right the EDID code itself is. But the implementation of the bit banging functions are driver specific. In my case intel_i2c.c
<smb> RAOF, And I seem to experience flakyness when the monitor cable is not directly connected to the laptop
<smb> RAOF, But as of this mornings "democratic" approach it seems to work. With mostly a 4:1 vote for the bit being 0
<RAOF> Urgh :)
<smb> Oh yeah. :)
<smb> Especially as the i915 code has so many bit values defined that I am completely lost about their intention
<RAOF> I'm not sure how I'd tell if a bad EDID on a bug was due to the monitor or the i2c interface.  It's not something I've regularly asked reporters about.
<RAOF> And there are plenty of monitors with bad EDIDs to go around.
<smb> Yes, that might be specific to my case. The interesting part would be the number of messages. If the remainder is always the same, I guess the EDID /monitor is at fault
<smb> If, like in my case, the remainder always changes, there is flakyness
<RAOF> Yeah.  I *have* noticed some changes in that sort of area for i915 but not radeon or nouveau.
<smb> That would sort of match my experience that all radeon (I think I have not tried nvidia) laptops when connected to that same monitor switch would get the right EDID but not that i915 based netbook
<smb> And as it drove me nuts (because I mainly work on that netbook and it would only allow the high mode after much cursing and tricking around) I played around with that yesterday and today
<RAOF> I think it might be at least in part because Intel chips are entirely integrated, so they rely on third parties to actually wire stuff up.  ATi and nVidia both either (a) are discrete cards, wired up by people whose job it is to wire up discrete cards, or (b) on motherboards wired up by AMD or nVidia.
<smb> Maybe also because compared to radeon i2c code which only seems to set unset a bit in the registers, the intel implementation has dir bits and a mask and val bits and a mask and I think I really need to talk to somebody that can actually make sense of that. :) I'll try Eric, maybe he can tell me what all of this means
<cking> smb, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=13f8acafe67361d7afda05c23a0408820e0cb468
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/3b2e8e02ca5a31b6f8db8de05becb613d819622a-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<ccheney> tgardner, thanks, testing
<ccheney> tgardner, seems to be working, doing full test and going to run instance to be sure
<tgardner> ccheney, ok, I've been looking at the patch. most of the changes are just pointer guards, but there is one change that could affect the behavior.
<ccheney> ok
<ccheney> tgardner, the pad block corrupted message doesn't appear but it seems to not run the instance, i am going to try it again and see if it will work
<ccheney> tgardner, its possible there is more than one bug, i am going to look into finding other ways to verify if the image was registered properly
<tgardner> ccheney, a different behavior then the previous successful runs?
<ccheney> with this kernel it appeared to register the image properly but then when i tried to launch an instance using the image it did not work, both worked before, i may need to retest your last kernel from last night to make sure it was working for running instance, but i am pretty sure it was
<ccheney> i slept since then so i have forgotten a bit :-\
<tgardner> ccheney, retry 2.6.35-5.6 to verify it still produces the PAD error, then I'll build a kernel based on that version but with the offending commit reverted.
<ccheney> ok will do
<ccheney> tgardner, it ran this time, i think its probably an issue with eucalyptus that caused it to not work the first attempt
<tgardner> ccheney, does it pass the 10 loop test?
<ccheney> i'll try a few more times to make sure it consistently is working, but i wouldn't be surprised if it was euca for that part
<ccheney> tgardner, yea the 10 loop test passed, that just tests the registration for the pad bug
<ccheney> this is still on 2.6.35-6
<ccheney> the step i do after testing the pad bug is gone is to run the instance which seemed to hang the first attempt but worked on the second
<ccheney> will get back to you soon about it, talking to the guys about it
<tgardner> ccheney, just to be clear, you're running the kernel with cc56f7de7f00d188c7c4da1e9861581853b9e92f reverted?
<ccheney> i am running http://kernel.ubuntu.com/~rtg/mainline/3b2e8e02ca5a31b6f8db8de05becb613d819622a-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<tgardner> ccheney, k, I'll add that to the bug report
<ccheney> tgardner, ok
<ccheney> tgardner, yea it seems to fix it, it only failed the first time of running instance and i don't have a great track record of instances running on my box anyway due to other weird eucalyptus bugs
<ccheney> so i would consider the test to be successful
<ttx> tgardner: what are our options wrt A2 ? would you consider using that "current minus problematic patch" kernel for A2 ?
<ttx> s/patch/commit/
<tgardner> ttx, um, I don't completely understand _why_ that patch causes a failure. As far as I can tell it merely implements more rigorous error checking, which the Java machine may be tripping over. I'm still of the opinion that you should release with a Lucid kernel 'cause I'm not yet willing to advise that we revert that commit for the master kernel.
<ttx> tgardner: hm...
<tgardner> ttx, Linus has been gone for 2 weeks, so there may well be fixes for this already in the pipeline. I'll bug the authors about it.
<ttx> tgardner: I thought there would be more value in testing a 2.6.35 kernel in the A2 milestone than to revert to a Lucid one.
<ttx> tgardner: there have been some patches proposed by the same author that seem to "fix" things, ccehney found them
<tgardner> ttx, perhaps I read a different thread. Which one did you read?
<ttx> No clue if they fix anything relevant for us though
<ttx> might be worth generating a test kernel with them and see
 * ttx looks at reference
<tgardner> ttx, I read this one http://marc.info/?l=linux-fsdevel&m=127488511324250&w=2 which was inconclusive
<ttx> tgardner: there are a few others at http://marc.info/?a=119980668900012&r=1&w=2 but I have no clue if they are more conclusive
<tgardner> ttx, which is why I thought I'd contact the authors, 'cause I also have no clue
<ttx> tgardner: if you're more comfortable with shipping a Lucid kernel for Maverick A2 than the modified 2.6.35 one, we should go that way
<ttx> I'm missing historical referenbce to see what most acceptable for an A2
<ttx> tgardner: maybe that's a subject for the release meeting in one hour
<tgardner> ttx, what is the use of testing a Maverick kernel in UEC if we _already_ know it doesn't work. It seems to me that it'll preclude testing of other UEC features.
<ttx> tgardner: agreed, by "modified 2.6.35 one" I was thinking the one that ccheney just tested
<ttx> the issue being it affects more than just UEC, but all servers
<tgardner> ttx, well, I'm not ready to recommend that ogasawara revert that commit. I assume that the A2 release _must_ use the kernel from the archive, correct?
<ttx> tgardner: that's my understanding as well
<ogasawara> tgardner: and I'd prefer not to have to spin a new kernel, I uploaded what I hoped to be our final A2 kernel last night
<tgardner> ogasawara, yep, agreed
<ogasawara> and it's cutting it close to do another upload
<ttx> tgardner: if A2 uses the one from the archive, how can you make it "ship the Lucid kernel" ?
<ttx> another solution is to just releasenote the fact that for UEC, you should revert to a Lucid kernel due to a yet-to-be-investigated bug
<tgardner> ttx, I guess its a matter of seeding? The Lucid kernel _does_ live in the archive, just in a different releas.
<ttx> tgardner: ah ok.
<ccheney> i'm not sure if you can seed something not in your pocket
<ccheney>  but that would be a question to ask someone like cjwatson probably
<ttx> ogasawara: I'm unsure we should just prevent non-UEC server use cases from testing the 2.6.35 kernel in the A2 milestone
<ccheney> if we can't and we want to use the old kernel we can probably get it copied to maverick
<ttx> documenting the workaround for the UEC users sounds like the best move here
<ccheney> hmm actually if it has the same source package name then probably the only way to do it is by telling users to install (but i may be wrong)
 * tgardner gets breakfast. biab.
<ttx> tgardner, ogasawara: i'll mention the issue in the release meeting since the release team should decide on what they prefer to have in A2
<ttx> (and will confirm what our options are, if we have more than one)
<ogasawara> ttx: ack
<ccheney> ttx, yea our only options might be to either respin or to document in the a2 release notes, but i don't know if they have some magic they can perform on the image outside of regular seed generation
<cnd> is there a way to keep my system at 10.04, but somehow tell apt to upgrade my kernel from maverick?
<cnd> so far I've just been manually installing kernels
<ttx> ccheney: that's what I'll ask at the release meeting
<tgardner> cnd, you could run the LTS backport.
<cnd> tgardner: can you remind me whether that differs in any way from the real maverick kernel?
<cnd> config options?
<tgardner> cnd, should be identical.
<cnd> tgardner: are they now produced at the same time as the maverick kernels, or do they lag?
<tgardner> cnd, the only diff is that the backport is built with the Lucid toolchain
<tgardner> cnd, obviously it lags because its dependent on maverick, but usually no more then a day or so
<cnd> ok
<cnd> thanks
<tgardner> cnd, it depends somewhat on the crazy shit ogasawara has done to maverick. I'm working on the backport right, but apparmor is giving me some grief.
<cnd> heh
<ccheney> tgardner, anything else you would like me to test? whenever the other patch gets reviewed by Linus I can test it out as well
<tgardner> ccheney, it'll likely take a few days.
<ccheney> tgardner, no problem just let me know when you are ready
<tgardner> ccheney, just to be clear, this PAD error is emitted by a node host kernel when it is attempting to unpack and load a KVM guest, right?
<JFo> tgardner, is this bug on your radar? bug 597904
<ubot2> Launchpad bug 597904 in linux (Ubuntu Maverick) (and 1 other project) "No video on beagleboard with 2.6.35 kernels. (affects: 1) (heat: 10)" [Critical,New] https://launchpad.net/bugs/597904
<tgardner> JFo, it should get on mpoirier's radar
<JFo> k
<JFo> mpoirier, you around?
<mpoirier> sure am
<ccheney> tgardner, its emitted when attempting to uec-publish-tarball on the walrus server
<JFo> k, have you seen that bug I just pointed to tgardner?
<mpoirier> hold on, looking at it...
<JFo> k
<ccheney> tgardner, the node doesn't do anything with it at all, the node is the system running the kvm instance that you start using the image off the walrus server
<ccheney> tgardner, i hope that was clear, i can try to reword a bit better if it wasn't :)
<tgardner> ccheney, clear as mud. explain in a language that upstream will understand
<ccheney> tgardner, ok
<mpoirier> JFo: I am aware of the issue - been present since I joined the company.
<JFo> cool
<JFo> just worried as I got mail indicating it was critical, etc.
<ccheney> tgardner, so this bug shows up on the server running 'walrus' which is the equivalent of Amazon S3 if you know what that is?
<ccheney> tgardner, reading my uecglossary page :)
<mpoirier> JFo: they are all critical right now...
<JFo> and they set milestone to Alpha2 and the kernel freeze is today
<mpoirier> JFo wont' happen.
<ccheney> tgardner, so its running on the box not running the node controller, so not the one running the images in VMs
<ccheney> tgardner, when you start an instance (VM) the software provides the image you tell it to use via 'walrus' S3 to the node controller to use as the base image to run for the VM
<mpoirier> JFo: we need to coordinate with the mobile team.
<JFo> yeah, I agree
<ccheney> tgardner, our bug is failing when attempting to register the image (make it available for use) to the 'walrus' S3 service
<JFo> just wanted to verify that no one had given them the idea that it was possible :)
<tgardner> ccheney, more fundamentally, this is the walrus host kernel attempting to decrypt a file?
<ccheney> tgardner, to explain better than that i may need to defer to ttx
<ccheney> tgardner, yes
<JFo> thanks for looking mpoirier 
<ccheney> tgardner, so not a vm kernel, actual bare metal kernel
<ttx> tgardner: in fact it's walrus calling a Java decryption routine
<tgardner> ccheney, and your 10 cycle test simply runs that decryption 10 times?
<mpoirier> JFo.  I'll have a chat with tgardner on how to proceed with the workload and what to prioritize first.
<ccheney> ttx, i couldn't find where bouncycastle or openjdk-6 is actually using sendfile but i may be lacking my grep skills
<ttx> when used against large files, ultimately it fails with that pad block error
<ccheney> tgardner, essentially, my script attempts to register the image which does various things unknown to me including the decryption
<tgardner> ttx, ccheney: ok, that seems to be the fundamental issue.
<ccheney> tgardner, and repeats that 10 times, yes
<ccheney> ttx: i did notice even when it does work it mentions something about the file being too large in the euca logs
<ccheney> ttx, i don't know if you saw that message before
<ttx> I suspect the JVM does things that are no longer well supported by the kernel
<ccheney> some cache error message i'll see if i can find it, might be in the bug report, will check
<ttx> smoser pointed at  java.nio.channels.FileChannel transferTo using sendfile
<JFo> mpoirier, ok
<ccheney> hmm the cache message seems not in the bug report, i'll add it in case its useful
<ccheney> ttx, do you happen to know what package that is in? seems not in the main openjdk-6 source
 * ttx looks into his mighty java-Contents file
 * ccheney doesn't know enough about java to know how to locate where it would be
<ttx> openjdk-6-jre-headless rt.jar java.nio.channels.FileChannel
<ccheney> if its a bug in java we can get doko to look into it
<smoser> it would seem unlikely to me that java would utilize and expose something that isn't standard.
<ccheney> hmm weird
<ccheney> i grepped over openjdk-6 source
<tgardner> ttx, do you think you could develop a simple reproducer? Something that an upstream developer could use to stimulate the bug without having to have all of the UEC stuff?
<ttx> ccheney: didn't the eucalyptoids provide us with that ?
<smoser> its possible that its a java bug, but i would think, given 2 years of function and then breakage in linux and expectation of java to run cross unix, that its kernel regression.
<ccheney> ttx, iirc someone said there is a huge reproducer in java attached to the bug
<tgardner> smoser, its clearly kernel regression (or at least a change in behavior)
<ttx> right, it's just unclear why
<ccheney> yea 134MB test program
<tgardner> ah, I see it.
<ccheney> its either regression or undefined behavior that was relied on
<tgardner> ccheney, If I can reproduce it, then I can likely narrow down the exact line in the commit that is causing this issue
<ccheney> tgardner, yea, looking to see if i can find the sendfile code used
<ccheney> umm we have patches in the FileChannel area
 * ccheney hopes we didn't cause this bug ourselves
<ccheney> actually hmm no those aren't ubuntu patches but something else
 * ccheney upstream source looks a bit odd
<ttx> ccheney: the bug is occurring on RedHat too
<ttx> ccheney: so it's not "just us"
<ccheney> oh ok
<ttx> it's anyone with 2.6.34+
<tgardner> ttx, do you have a reference to the RedHat report?
<ccheney> yea the patches are from icedtea, which i think is similar to ooo-build for java
<ccheney> i still don't see a reference to sendfile though
<ttx> it's a forum post at eucalyptus.com
<ttx> http://open.eucalyptus.com/forum/decrypting-image-exception
<ccheney> maybe it gets generated in some way
 * ccheney is going to write up the preliminary information to the mailing list in a few minutes
 * ccheney still isn't on the list apparently, or hasn't gotten the response back yet
<ccheney> ah ha my openjdk-6 source wasn't fully unpacked it has a bunch of extra stuff plus a huge tarball in the dir
<ccheney> no wonder i saw no reference to sendfile in my grep
<ccheney> now i found it
<tgardner> ogasawara, the only item for us in the release meeting is the 'pad block corrupted' issue. You're aware of the status changes, i.e., we've narrowed it down to a single kernel commit?
<ccheney> jdk/src/solaris/native/sun/nio/ch/FileChannelImpl.c
<ogasawara> tgardner: yep, got it all written up to paste
<tgardner> ogasawara, cool. on top of things as always :)
<ccheney> its definitely special cased for solaris vs linux
<ccheney> so not fully standard across *nix anyway
<ccheney> http://pastebin.com/z5juRcCB
<cnd> apw: ogasawara: I want to grab the latest kernel ddeb, but the amd64 version is missing
<cnd> I see that the previous kernel, 2.6.35-5, is also missing amd64 ddebs
<ogasawara> cnd: Is it still building?
<ogasawara> amd64 that is
<tgardner> cnd, its still building
<cnd> oh
<tgardner> ccheney, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/588861/comments/10 doesn't reproduce the bug.
<ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress]
<ccheney> tgardner, oh ok
<cnd> ogasawara: tgardner: launchpad says it's been done building for 2 hours
<ccheney> tgardner, i'll grab it and see if it happens with that for me
<tgardner> ccheney, dang, it would be nice to a have a simple reproducer
<tgardner> cnd, it takes awhile for the publisher  to run, plus things may be starting to freeze for A2
<ccheney> tgardner, i'm writing an email to upstream about it so maybe they will know how to make a simple test case
<cnd> tgardner: ok, I suppose I'll chill for a bit
<ccheney> er upstream eucalyptus i mean not kernel
<tgardner> ccheney, hmm, this is gonna be a kernel issue I think.
<tgardner> unless the java engine is just borked
<ccheney> tgardner, yea i don't know the code well enough to be able to tell
<tgardner> ccheney, its in openjdk-6-jdk, right?
<ccheney> tgardner, yes sendfile is in that, if you download it and unpack the source there is a large tarball with the actual source inside of that
<tgardner> working on it....
<ccheney> so double packed debian source
<ccheney> thats how i managed to overlook the sendfile call earlier
<ccheney> tgardner, i attached a pastebin link of the file using it to the bug report earlier
<ogasawara> jjohansen: just fyi, I went ahead and marked the two apparmor A2 work items you had as done (sync distro apparmor with upstream version, and update compatibility patch)
<jjohansen> ogasawara: thanks, I meant to do that
<ogasawara> jjohansen: was selfish really, I just wanted our burn down charts to look good for the release meeting :)
<jjohansen> hehe :)
 * ogasawara bails for a few hrs
<ogasawara> tgardner: ^^ deflect any fires should there be any
<GrueMaster> JFo: Any suggestions on how to get apport data through a serial console on a system that doesn't have a released kernel?  Re: bug 597904
<ubot2> Launchpad bug 597904 in linux (Ubuntu Maverick) (and 1 other project) "No video on beagleboard with 2.6.35 kernels. (affects: 1) (heat: 10)" [Critical,New] https://launchpad.net/bugs/597904
<JFo> GrueMaster, not off the top of the head
<GrueMaster> Then QUIT MARKING OMAP BUGS AS INVALID.
<GrueMaster> thank you.
<JFo> GrueMaster, before you start yelling... probably best to give an example where I did
<GrueMaster> I just did.
<JFo> GrueMaster, get your facts straight
<JFo> I set it incomplete
<JFo> because I asked for info
<JFo> and for the record, and your general fund of knowledge
<JFo> I don't take people yelling at me very well
<JFo> especially when they arewrong
<GrueMaster> System isn't booting.  Best info we are able to gather is through minicom logs.
<JFo> please refer to my boss pgraner if you have issues\
<GrueMaster> This isn't an x86 system that has multiple tons of ways to collect this info.
<GrueMaster> And because we need to get it working, we are getting hand-built kernels prior to release (which apport considers invalid).
<JFo> I know that, hence my question as to whether it was possible
<GrueMaster> Nope.  Not possilble.
<JFo> like I said, get your facts straight
<JFo> then fine, add a comment to the bug to that effect, if necessary and we can move on
<JFo> see how easy that could have been?
 * smb moves on to boc and we. See you next week
<GrueMaster> JFo: sigh.  I owe you an apology.  I'm letting my frustrations of trying to get this image working get the best of me.  I shouldn't have taken it out on you like that.
<JFo> apology accepted. If you need to vent to me about something like that in the future, may I suggest a private window? :)
 * JFo steps away for lunch
<tgardner> mpoirier, you around?
<mpoirier> I am.
<mpoirier> whazup ?
<tgardner> mpoirier, did Lucid omap3 have video? Is this a maverick regression?
<kees> ogasawara, tgardner: this bisect script rocks.  :)
<ogra> tgardner, maverick regression
<mpoirier> let's mumble...
<tgardner> kees, If I can get clear of UEC I'll try and make it better
<GrueMaster> tgardner: Yes, Lucid works fine on omap 3.  In fact, I tried the latest 2.6.35 kernel on that image as well.
<kees> tgardner: works great for me already.  :)
<kees> ogasawara: I seem to be zeroing in on the middle of a mess of i915 commits again... we'll see how it goes.
<GrueMaster> I have just been informed that there is now a 2.6.35-6 release kernel (not a hand rolled one).  I'm going to pull that and retry it just to verify.  Might even get some apport data.
 * JFo crosses his fingers
<sconklin> kees: I'm about to leave for the day, but if you end up sending email, I'm interested in anything having to do with i915
<kees> sconklin: okay, sure.  are you seeing problems too?
<sconklin> kees: I'mnot, but I don't know which problems, release, or hardware you're talking about - I'm just trying to keep up with i915 in general
<kees> sconklin: okay, cool.  I have a Q35 intel mainboard with onboard G35 (?) that since -rc2 hangs on boot.  I seem to be the only person with this problem.  :P
<kees> (pci id 8086:29b3)
<sconklin> kees: Hmm. Hang is not good. I'm not paying much attention at all to maverick recently, been working on lucid stable updates. Have you tried the simple things like disabling kms?
<kees> sconklin: booting with "nomodeset" you mean?
<sconklin> kees: yes
<kees> yeah, that doesn't work.  :)
<kees> the only way I could get past the initramfs was to blacklist i915 _and_ intel_agp.
<sconklin> kees: that's a new one on me
<sconklin> sorry
<kees> then once into root fs, they weren't blacklist any more (initramfs bug) and udev immediately loads them and hangs the system.
<kees> and if I blacklist them on the rootfs, when X starts, it ignore the blacklist and loads them again.  it's been a really fun few days.  ;)
<maks_> AGP needs to be built in.
<maks_> we got heavily hit by having it modular afaik upstream is not properly testing modular agp
<maks_>   * [alpha, amd64, i386, amd64, powerpc] Make all AGP driver built-in to
<maks_>     workaround race-condition between DRM and AGP.
<maks_> it was directly asked by airlied.
<sconklin> kees: ^^
<kees> oh, lovely
<kees> ogasawara: ^^
<ccheney> tgardner, yea their test case works for me even on the broken kernel, so its not good enough test apparently
<ccheney> tgardner, i'm going to try to modify it to use the same image i was previously using to see if that makes a difference
<tgardner> kees, the race is a generic problem. we had a macro that would allow you to force a symbolic dependency, but ogasawara ripped it out of Maverick 'cause it wasn't getting used anywhere.
<kees> tgardner: er, so, is my problem not due to this?  /me isn't sure what to test next.
<tgardner> kees, I'm not sure. Try changing the config to build-in AGP
<kees> will do
<GrueMaster> JFo: No joy here.  
<GrueMaster> *** Problem in linux-image-2.6.35-6-omap
<GrueMaster> The problem cannot be reported:
<GrueMaster> This is not a genuine Ubuntu package
<tgardner> ccheney, I'm building an instrumented kernel that might give me enough information to indicate which part of that patch is causing problems,.
<ccheney> ok
<GrueMaster> I might be getting this due to bug 595949.
<ubot2> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) (and 3 other projects) "linux-meta-ti-omap depends on the wrong binary kernel in maverick (affects: 1) (heat: 564)" [Low,In progress] https://launchpad.net/bugs/595949
<tgardner> GrueMaster, this is omap3, right?
<GrueMaster> yes
<tgardner> GrueMaster, k, lemme have a look
<GrueMaster> It may be possible that this is because the kernel was just released and not on my mirror yet.
<tgardner> GrueMaster, AFAIK it hasn't completed building yet. ogasawara upload the meta package before amd64 or armel were complete
<GrueMaster> I have the kernel.  It was at https://edge.launchpad.net/ubuntu/+source/linux/2.6.35-6.7/+build/1811239
<GrueMaster> or am I missing something?
<tgardner> GrueMaster, what meta-package are you using? It should be linux-omap or linux-image-omap
<GrueMaster> This is a hand rolled image initially running 2.6.34-5.  I downloaded linux-image-2.6.35-6-omap from the above link.
<tgardner> GrueMaster, ok, so why do you think you're hitting bug # 595949 ?
<GrueMaster> Has it been fixed yet?
<GrueMaster> My image was created 6/22.
<tgardner> GrueMaster, yes, but I just noticed that there might still be  a bogus package in the archive.
<GrueMaster> And I haven't seen anything kernel related with apt-get update.
<GrueMaster> hmmm
<tgardner> GrueMaster, lemme chat up some archive admins about this
<tgardner> GrueMaster, 'dpkg -l|grep ti-omap'
<GrueMaster> none.
<tgardner> GrueMaster, then you don't have the meta package installed?
<GrueMaster> as I said earlier, it is broken (or was on 6/22 when this image was created).
<tgardner> GrueMaster, um, try 'dpkg -l|grep omap'
<GrueMaster> ii  linux-image-2.6.34-5-omap       2.6.34-5.14               Linux kernel image for version 2.6.34 on OMA
<GrueMaster> ii  linux-image-2.6.35-2-omap       2.6.35-2.3                Linux kernel image for version 2.6.35 on OMA
<GrueMaster> ii  linux-image-2.6.35-6-omap       2.6.35-6.7                Linux kernel image for version 2.6.35 on TI 
<tgardner> GrueMaster, what happens with 'sudo apt-get install linux-image-omap' ?
<GrueMaster> "apt-cache search ti-omap" only lists the linux-headers for 2.6.33|34|35 and omap4 meta packages.
<tgardner> its not ti-omap, just omap
<GrueMaster> It wants to revert to 2.6.35-5-omap kernel.  
<psusi> anyone care to apply the proposed patch in bug #595489
<tgardner> GrueMaster, after you've done an update? 'apt-get update' ?
<ubot2> Launchpad bug 595489 in linux (Ubuntu) (and 1 other project) "lvm snapshot causes deadlock in 2.6.35 (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/595489
<GrueMaster> Just a sec.  Updated mirror, now updating apt.
<tgardner> psusi, it ain't gonna happen for A2, but I've milestoned it for A3
<psusi> doh
<tgardner> psusi, is Eric gonna get it into .35 ? Linux won't be back until next week.
<tgardner> Linus*
<psusi> he fired off the patch to the mailing lists and I guess it's waiting for Linus to apply
<psusi> but since kernel freeze starts today, I think we're going to have to apply it ourselves?
<tgardner> psusi, ok, this issue won't get lost now that its milestoned. I would prefer to get the fix direct from Linus' tree
<psusi> yes, but that won't happen because of the kernel freeze will it?
<tgardner> psusi, we don't freeze the kernel until the official 2.6.35 is released
<psusi> ohh... I thought I read that today begins kernel freeze...
<tgardner> this is just a momentary freeze in order to get A2 out the door
<psusi> ahhh
<tgardner> so there time yet
<tgardner> there is*
<psusi> then hopefully it will get into .35 final... though Eric said there is another deadlock possible, but I have yet to hit it
<psusi> he's working on tracking that down now
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/ae0f36f0b964caf916c2ffc9f84b28c0f91c18a2-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<tgardner> ccheney, do a 'sudo dmesg -c' right before you start your test
<kees> maks_, sconklin-gone, tgardner: building with intel_agp built-in did not fix it.  the bisect has resulted, finally, in this one: f1befe71fa7a79ab733011b045639d8d809924ad
<kees> I'm building a maverick kernel with that reverted now...
<tgardner> kees, you have an older i945?
<kees> yes
<kees> G35, though, not G33
<tgardner> kees, you should ask Kyle about this. He did a bunch of i945 stuff a few years ago.
<kees> tgardner: I figured I'd poke Anholt since I think he's in my timezone.  (if I can find him)
 * tgardner lunches for a bit
<GrueMaster> tgardner: Ok, I am officially giving up trying to get apport data on this omap bug.  I have followed all the steps on https://help.ubuntu.com/community/ReportingBugs based on a headless system, but apport is now trying to collect data on my desktop system (different arch altogether).
<maks_> I'd like to know what the fix for #554569 is
<maks_> the linked rh and freedesktop bugs all point to different patches
<maks_> oh the freedesktop bug finaly points to something interesting cool.
 * bjf will be back in a bit
<tgardner> ccheney, any update? 
<ccheney> tgardner, not yet, sorry was at lunch
<ccheney> tgardner, no response from my email and still looking into how to do the test with my own image
<tgardner> ccheney, well, just rerun the original UEC failure case with this latest kernel so I can get some output from that patch
<ccheney> 2.6.35-6 ?
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/ae0f36f0b964caf916c2ffc9f84b28c0f91c18a2-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<ccheney> oh nm i see you sent me a new one
<ccheney> tgardner, appears broken, is that expected?
<ccheney> i'll see how it does over all 10 tests but it already has one failure
<tgardner> ccheney, yes, I expect it to be broken. I want the dmesg output
<ccheney> oh ok
<ccheney> [  211.296957] /home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849 should this happen?
<ccheney> i'll get the whole log once its done
<tgardner> ccheney, I only need the results of one pass. _Before_ you start it do 'sudo dmesg -c' to clear the kernel buffer
<ccheney> oh oops, i need to redo it then
<ccheney> ok as soon as it finishes the first pass i will get it to you
<ccheney> all i saw was once for one pass: [  365.268713] /home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849 should this happen?
<ccheney> that was the entire output of dmesg during the first pass of the run
<tgardner> ccheney, yeah, its some debug, but I think its harmless
<ccheney> oh that wasn't my question it was this "[  365.268713] /home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849 should this happen?" exactly
<ccheney> :)
<tgardner> ccheney, oh, yes. its the debug I put in.
<ccheney> ok
<ccheney> tgardner, so what does the special output mean? :)
<tgardner> ccheney, hang on, I'm spinning one more 
<ccheney> ok
<tgardner> ccheney, 10 minutes or so
<ccheney> ok
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/0a87a0c1b12f56bd556fd4506041966717c87fb1-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<tgardner> same drill as before
<ccheney> ok will test
<ccheney> tgardner, i may have to disappear for an extended time in the next week, if so contact kirkland for how to proceed, i don't want to go into details in public
<ccheney> tgardner, most of the server team knows the details though if it does happen so they can fill you in
<tgardner> ccheney, ack
<ccheney> tgardner, will be a medical emergency if it happens
<tgardner> ccheney, you haven't disappeared already, have you?
<ccheney> no sorry
<ccheney> had to talk my father in law to fill him in on my wife's status
<tgardner> ccheney, I'm about EOD, but wanted to ponder the results of that last patch
<ccheney> ok let me see if it finished running
<ccheney> doh i ran off to tell him before i rebooted and started it
<ccheney> it should take about 3-4m
<ccheney> tgardner, [  129.980324] /home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849 ffffffff816256e0 (null)
<ccheney> repeated 20 times
<ccheney> most within a second, first was 50s before i'll pastebinit
<ccheney> tgardner, http://pastebin.ubuntu.com/455139/
<tgardner> ccheney, ack
<tgardner> ccheney, hmm, I wonder if I restore the original lines there if it'll make a diff. you gonna be around for another 20 minutes?
<ccheney> yea
<tgardner> k, gimme 15 minutes
<ccheney> tgardner, i'll be around the rest of the day unless emergency happens
<ccheney> i'll do my best to alert everyone to that case if time permits
<jjohansen> -> Lunch
<tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/afef312909fa10e603a05e030b2ee2feebde8d9f-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb
<ccheney> testing
<tgardner> this should be the last one.
<tgardner> ccheney, I left the debug in along with the restored code. It might just work.
<ccheney> ok will see what happens
<ccheney> tgardner, we got a bit of bad news, probably more to follow in the next week, but i'm still around today
<tgardner> ccheney, I'm definitely outta here after this test.
<ccheney> ok
<ccheney> just one result from 1 loop
<ccheney> [  193.874005] /home/rtg/kern/maverick/kern-64/ubuntu-maverick/fs/read_write.c:849 ffffffff816256e0 (null)
<tgardner> ccheney, did the PAD error show up?
<ccheney> oh i forgot to check that, sorry :-\
<ccheney> no i think it is working
<ccheney> i'll rerun
<ccheney> i didn't clear my euca logs
<ccheney> it looks like it worked though
<ccheney> yea it worked, i checked the timestamp from my script vs the timestamp of the last error on the log
<ccheney> haven't run an instance yet, but it seems to no longer show pad corrupted
<ccheney> yea no more pad corrupted error
<ccheney> what did you change?
<tgardner> ccheney, cool. I'll send a note to upstream about it later tonight. Add your results to the LP report.
<ccheney> ok
<tgardner> ccheney, I restored the 2 lines of code that made any substantive difference in the behavior of the patch
<ccheney> ok
<tgardner> ccheney, upstream email sent. I'm outta here.
#ubuntu-kernel 2010-06-26
<cnd`> cnd
<cnd2> cnd
<cnd`> cnd
<cnd`> 1
<cnd`> cnd 2
<cnd`> 1
<cnd`> ls
<cnd`> ls
<cnd`> ls
<Rensky> hey i will install vmware server in my ubuntu 10.4 and he ask me about the lib folder
<Rensky> default is: What is the location of the directory of C header files that match your running kernel? [/lib/modules/2.6.32-22-generic/build/include]
<Rensky> it can?t be correct then i become an error when he will compile
<Rensky> http://pastebin.com/wEC20Dhf 
 * abogani2 waves BenC 
<BenC> abogani2: hey, how's things?
<abogani2> BenC: so so
<abogani2> BenC: And you?
<BenC> pretty good, thanks
<abogani2> BenC: Still developing IPhone applications? :-)
<BenC> hehe, I've never developed an iPhone app :)
<abogani2> :-)
#ubuntu-kernel 2010-06-27
<dupondje> mmc0: Got command interrupt 0x00030000 even though no command operation was in progress. => when pluggin in an SD card. this is a kernel bug right ?
#ubuntu-kernel 2011-06-20
<bullgard4> I obtained a message "panic occurred, switching back to text console". What Natty log file should reflect that?
<ohsix> that's a panic; it wouldn't have made it to a log file, you need to take a screenshot of it or otherwise read it to start investigating what it is
<ohsix> er screenshot -> photo
<bullgard4> ohsix: When having made a photo, is the proper way to report to Launchpad using the command '~$ ubuntu-bug linux-image-2.6.38-8-generic' and attaching there the photo as a file?
<ohsix> thats what i did last time i reported a panic
<bullgard4> Thank you.
 * apw yanws
 * apw waves to cking 
<jjohansen> morning apw, cking
<apw> jjohansen, not again!  morning
 * apw wonders if mumble is broke, or if its just none of us is in CC
<cking> morning one and all, here we go again
<jjohansen> apw: nope I'm not here, you are still groggy got get some coffee
<jjohansen> s/got/go/
<jjohansen> apw: so for aufs in the oneiric kernel we have commit dc7c488aeee4e3a50d6e76c5a6eba01d4ecfe432, and then b105abf699ff68fe0960a2568c14da8f82cfe4eb which is the merge from upstream which should have contained the patch in first commit mentioned, but that commit never got dropped
<apw> jjohansen, looking
<apw> jjohansen, ok the 'merge' from upstream is just a physical copy over of the aufs code
<apw> so we'd never know to remove the old commit, does t
<jjohansen> apw: ah, right
<apw> that matter ?
<jjohansen> apw: nope, except it shows up as a sauce patch to check status on
<apw> jjohansen, ahh just mark it 'merged upstream already' and i'll try and figure out how to lose it :)
<jjohansen> apw: will do :)
<apw> 7467571 cpuidle: menu: fixed wrapping timers at 4.294 seconds
<ppisati> lucid/fsl-imx51 have already 3 new commits but no start release since the last UBUNTU: Ubuntu-xxx closure
<ppisati> shall i start a new release or do i keep committing on top of these?
<apw> ppisati, generally we expect whoever notices the startnewrelease is missing to add it, thoguh it doesn't matter when it occurs, so feel free to add it
<ppisati> apw: do i pop off the 3 commits and add a new release there or do i add it now?
<apw> ppisati, it totally doesn't matter the order, so just stick it next
<ppisati> ok
 * ogasawara back in 20
<sconklin> moin
<lool> I've started an ubuntu-devel@ thread to discuss removal of the armel versatile flavor; I didn't Cc: ubuntu-kernel@, but will pass the result of the discussion in case it's favorable (nobody objects to the removal)
<tgardner> lool, isn't the versatile flavor required for qemu ?
<tgardner> lool, nm, just saw your email
<ppisati> who decides which patch-es close a CVE? because i'm skeptical about CVE-2010-4251
<ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
<ppisati> since the mentioned patches are not enought to close the DDOS scenario
<ppisati> and in fact, later, there's another patch related to it but the CVE doesn't mention it as necessary
<apw> ppisati, i would say in large part the security team who read the background, but should you find an apparent discrepancy do feel free to refer it back to them, better to waste a bit of their time checking than to miss it
<ppisati> apw: ok
<stat> Anyone here able to let me know a bit about the PAE kernel?
<stat> (I'm just going to talk anyways. Ignore me if I'm irrelevant)
<stat> It seems that the "big memory" flag for the PAE kernel is disabled by default now. That means you only get a maximum of 3.5GB. If you only get an extra 512MB, why even bother with PAE?
<apw> stat, big memory flage?  which one are you referring to ?
<stat> I'm not entirely sure to be honest. From what I understand though, is that there is a flag that you must enable to get up to 64GB, and you need to recompile the current PAE kernel to get that flag enabled. I'll see if I can find the link where I was reading this.
<stat> Ok, my mistake. It's called "High Memory Support (64GB)" not "Big Memory"
<apw> stat, the PAE kernel doubled the number of bits available to store the location of physical page, which allows you to have more physical memory
<stat> I know what PAE is for. I've just installed it, but now it seems 3.5GB instead of the 4GB that it should, which apparently is due to this flag.
<stat> http://www.larmeir.com/2009/07/enabling-pae-on-a-32-bit-ubuntu-desktop-supporting-up-to-64-gb/
<apw> stat, not necessarilly, physical layout of your ram may preclude seeing all 4GB
<apw> can you pastebin yout e820 information from your dmesg
<smb> I think the issue is that you get 3.5G per process because kernel has to be mapped there too. but with PAE you can address all mem so the virtual 4G could be spread over different physical memory
<stat> http://pastebin.com/evE63C7P
<apw> stat, ok and how do you know you only have 3.5gb, ie. where is that being expressed
<stat> /proc/meminfo
<apw> can you paste the overall number pls
<stat> MemTotal:        3600576 kB
<apw> stat, none of this makes any sense.  the point of the generic-pae kernel is that that it does set HIGHMEM64G
<apw> can you paste the whole dmesg please from this boot
<apw> that blog post is simply not applicable, as the kernle you have should have the flag you are aski
<apw> asking to be on
<stat> http://pastebin.com/zLLZZLim
<apw> stat, how much memory did you have on the -generic kernel ?
<apw> i am suspectin
<apw> i am suspecting from the physical layout that it as much less than 3GB
<stat> Ummm, I can't remember. I'm pretty sure it was 3GB. It was definitely more than 2.5 if that's what your suspecting.
<smb> or probably asked the other way round: how much ram is there for real
<stat> 4GB. 2 2GB sticks.
<apw> i am suspecting its 2.6 as you have a full G over 4 GB
<stat> That... might be.
<apw> or do you ... argle stupid hex numbers
<stat> Hang on, I'll reboot it without PAE and double-check.
<apw> stat, ok
<apw> cking, this is 512MB right?
<apw> [    0.000000]  modified: 0000000100000000 - 0000000120000000 (usable)
 * apw needs a sanity check
<smb> apw, But for that (4G) it sounds reasonable to have 3.6G left after taking away kernel, page tables and other reservations, doesn't it?
<apw> cking, and this is a smidge less than 3 right ?
<apw> [    0.000000]  modified: 0000000000100000 - 00000000bffc6b00 (usable)
<apw> so if i am reading this e820 right its is only advertising 3.5GB
<cking> apw, you got access to the machine?
<apw> cking, nope,but i do have the whole e820
<apw> http://pastebin.com/evE63C7P
<apw> but i think thats saying the bios is not advertising all the ram
<stat> (Sorry that took so long. I suck at Grub2)
<apw> stat, ok it looks like your bios is simply lying
<stat> MemTotal:        3096612 kB <-- Non PAE kernel.
<stat> Mmk. So my motherboard is just crazy then?
<apw> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
<apw> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffc6b00 (usable)
<apw> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
<apw> are the 'usable' memory
<apw> the first two are basically the whole first 3GB, then you have .5GB from 4GB physical
<apw> so 3.5 in total
<apw> sometimes there is a layout option in your bios to say where the ram will be placed
<cking> 3583M useable IMHO
<apw> but given the information the machine is offering the kernel is doing the right things
<smb>  /me thinks there is also acpi tables placed 
<apw> smb, but those would be shown cut from the ram ... but its still not even there
<apw> i suspect the ram is actually being placed under the io space and masked
<apw> which is stupid
<cking> if e820 tables are wrong, that's all you get
<apw> [    0.000000] e820 update range: 00000000d0000000 - 0000000100000000 (usable) ==> (reserved)
<apw> i think that is the other bit being lost, i think that means its under the AGP apature
<smb> hmm, maybe stolen graphics memory (on cheap cards)
<apw> stat, what machine is this, we might find some help on if there is a bios wiggle
<apw> cause you want different layouts for windows 32 bit and windows 64 bit ... so often there is a way
<herton> apw: yes, a bios option like "Remap memory above 4GB"
<apw> herton, right
<stat> Uhh an hp machine of sorts. 
<stat> Do you jsut want a device list?
<apw> worth rooting about in the bios then, or searching for "remap memory above 4GB" and "machine name"
<apw> on google
<apw> heh ... really its the bios infor thats intreesting
<stat> So do you want biosdecode info?
<cking> I have code to dump out the e820 from user space directly using the e820 BIOS call
<cking> http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=blob;f=e820/e820.c;h=fc4721eb80e50a7491dac4a059f746019f36d49e;hb=6cb227ece5ef420af9b341025b6a5e49e2d0e232
<stat> Will that be more useful if I reboot back into PAE?
<cking> but I expect it will give you identical results as the kernel gives
<stat> cking: I am confused by your code. I tried that makefile that came with it, but it doesn't seem o have an actual target for building it.
<stat> http://pastebin.com/X0fVehMJ <-- biosdecode if you're interested. I'm going to fiddle with my BIOS settings as you've suggested.
<stat> Thanks everyone for your help so far. :)
<ppisati> lp#799805
<ppisati> please accept my nomination
<tgardner> bug #799805
<ubot2> Launchpad bug 799805 in linux-ti-omap4 "CVE-2010-4256" [Undecided,New] https://launchpad.net/bugs/799805
<tgardner> ppisati, done
<ppisati> 10x
<stat> Well, I couldn't find anything in my BIOS about memory settings or remapping. I guess my BIOS is just lame. :P
<sforshee> tgardner, one of the testers that had reported that the new rt2800 firmware made his rt3072 work is now saying it's causing problems (poor performance, machine won't shutdown/reboot). Is that justification to revert back to the old firmware, given that rt3072 didn't work at all previously?
<apw> stat, did you see an option for the size of the AGP apature ?  and if so do you know how much video ram you have ?
<tgardner> sforshee, yeah, I think so. I should just get the archive admon to reject it.
<tgardner> admin*
<stat> Uhh, I did see a setting for video memory. It was set to auto, but could also be between 32-256.
<tgardner> sforshee, perhaps you should send an email to the SRU mailing list requesting rejection of the Lucid/Maverick packages that are currently in the unapproved queue
<tgardner> sforshee, after that I'll just reset HEAD~2 on those 2 repos
<stat> apw: It looks like it's 256MB.
<sforshee> tgardner, what's the address for the SRU mailing list? I'm not familiar with it.
<tgardner> sforshee, uh, I forget. bjf, sconklin ?
<sconklin> ubuntu-kernel-sru@lists.ubuntu.com
<stat> Ok, definitely 256MB according the memory range from lshw.
 * tgardner --> lunch
#ubuntu-kernel 2011-06-21
<jj-afk> back on later
<jk-> ogasawara: ping?
<BenC> I just saw that Canonical was supposed to have a session at the Freescale Technology Forum, but it seems to have been canceled...sad :(
<lifeless> the forum or the session?
<ogasawara> jk-: pong
<jk-> ogasawara: hey
<jk-> just been looking though lucid git
<jk-> bcbfc24ead6935714a001ab6f1f725763075f98c in particular - is this yours?
<jk->  ( http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=bcbfc24ead6935714a001ab6f1f725763075f98c )
<ogasawara> jk-: indeed it appears that way as I'd signed off on it, however I'm slightly confused by the bug noted in the commit message
<ogasawara> jk-: the commit for that bug should really be:
<ogasawara> commit 5b4d91d21e6c3e57fdbd5b4c2354c6f98153a3f3
<ogasawara> Author: Islam Amer <pharon@gmail.com>
<ogasawara> Date:   Thu Jun 24 13:39:47 2010 -0400
<ogasawara>     (pre-stable) dell-wmi: Add support for eject key on Dell Studio 1555
<jk-> ok, i'm confused now
<jk-> that patch is for drivers/media/video/
<jk-> ah, yeah, buglink is wrong
<jk-> anyhow
<jk-> there are a couple of changes that aren't IR-related
<jk-> - to drivers/media/video/cx23885/cx23885-core.c
<jk-> is this intentional?
<ogasawara> jk-: I want to say yes but I'd likely need to go back and review the email thread to completely refresh my memory
<jk-> ogasawara: probably getting late there, I can put this in an email to kernel-team if you prefer
<jk-> I'll check the thread out.
<ogasawara> jk-: Subject: "LIRC 0.8.7 Fixes for Maverick"
<jk-> ogasawara: cool, thanks
<bullgard4> Ich bin mit einer Natty-Live-CD unterwegs. Warum Ã¶ffnet 'Alt+F2 > Run a command > gparted <Enter>' nicht GParted? Ebenso nicht das Klicken auf  auf das Symbol Â»gpartedÂ«?  
<bullgard4> Wie kann man in der Live-CD umschalten von Unity auf GNOME 2?
<bullgard4> upps! Pardon me.
<smb> morning
<diwic> morning
 * apw yawns ... morning
<smb> apw, You sound like "need tea/coffee"
<abogani> morning all
 * apw needs t/c badly thank you ...
<apw> smb you got a hardy box lying around still ?
<smb> apw, You bet. Currently using it for xen test but I got a desktop install on it too.
<apw> smb, http://people.canonical.com/~apw/CVE-2011-0726-hardy/
<ubot2> apw: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0726)
<YoBoY> hi
<apw> smb, so we should expect the contents of /proc/<pid>/stat to have addresses 0'd out for stack, code start and code end
<apw> with that kernel
<apw> YoBoY, hi
<YoBoY> last week I came here with a freeze problem on my computer on natty (since the release). I used ubuntu some days without effects like recommended and no freeze problem anymore. I also tried since yesterday the new 2.6.39 kernel and the freeze problem came back, any idea what I can try to correct that and keep visual effects on my computer ?
<apw> YoBoY, there is nothing other than a hard hang?  you are unable to contact the machine over the network when it hangs ?
<YoBoY> apw: I can go to a tty and restart gdm
<apw> YoBoY, and things work find after restarting gdm ?
<apw> s/find/fine
<YoBoY> yes until the next freeze
<YoBoY> the hang occurs when the computer go to screensaver by the way (forget to tell)
<YoBoY> and not each times
<apw> ok thats very odd, it is cirtainly unusual for restarting gdm to recover from a kernel grpahics driver failure
<apw> and this only occurs when 'effects' are enabled yes ?
<YoBoY> yes
<apw> i am suspicious this is not a kernel issue, but a compiz one
<apw> my first suggestion would be to reproduce the issue again and then switch to VT1
<YoBoY> vt1 ?
<apw> from there, first take a copy of the kernel dmesg, running: dmsg >DMESG.FROZEN
<YoBoY> tty ?
<apw> (vt1 == tty1, ctrl-alt-F1)
<YoBoY> ok ^^"
<apw> and then try restarting compiz,  i think that the incantation is:  DISPLAY=:0.0 compiz --replace
<YoBoY> I can do that, next time :)
<apw> and then switch back to X and see if that unfreezes things
<apw> if the compiz replace works i am suspicious that we have a compiz hang and need to report against that, otherwise a report it against the kernel
<YoBoY> I tried the 2.6.39 kernel beacause I thought my problem was similar to the bug 740126
<ubot2> Launchpad bug 740126 in linux "Disabling an output can cause vblank events to be missed" [High,Fix released] https://launchpad.net/bugs/740126
<apw> http://awhitcroft.blogspot.com/2011/05/union-file-systems-again.html
<YoBoY> thanks apw i'll come back with the results
<apw> YoBoY, sounds good
<apw> ppisati, i am assuming you're noticong that when i am doing CVEs now i am sending out fsm-imx51 etc patches too, so you don't have to worry about those CVEs separatly
<ppisati> apw: yep, saw it
<apw> ppisati, maybe one day you and i will meet in the middle of the table
<apw> ppisati, and i think we deserve some beer when we get there
<ppisati> that's a good excuse to booze :)
<ppisati> bug 800121
<ubot2> Launchpad bug 800121 in linux-ti-omap4 "CVE 2010-4649" [Undecided,New] https://launchpad.net/bugs/800121
<ppisati> please accept the nominations
<apw> ppisati, you should mention my nick ... and done
 * apw pops ou
<apw> out
<jjohansen> apw: thanks for setting up the planet.ubuntu syndication
<jvargas> hi
<jvargas> I want to downgrade the 11.04 kernel to the one shipped with 10.10, so my network card could work at a very decent speed.
<jvargas> how can I proceed? I do not find info aboiut that..
<jj-afk> back on in a few
 * apw whines about poor internet
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
 * ogasawara back in 20
<apw> tgardner, would you cast an eye over the oneiric ti-omap4 binaries in ckt PPA, they are oneiric2 as the ppa wouldn't allow me to reuse the name, but would be oneiric1 for upload to OO
<apw> (then i can delete them before i get moaned at by those whining stable people)
<tgardner> apw, cast an eye to what end ?
<apw> tgardner, sanity check the version numbers for me, i don't want another libc abi hack or similar
<tgardner> apw, ah
<apw> they look ok to me, but i am too familiar with them now
<apw> the way they are made it should be impossible to be anything other than the same as natty ... but i've been blind to it before
<tgardner> apw, you don't have a ti-omap4 branch in oneiric yet ?
<apw> tgardner, we have nothing newer than what is in natty no
<apw> tgardner, i've pushed what i am proposing to upload into the repo for now
<apw> tgardner, when we do finally get a real one then it will just get pushed over and go away
<apw> last i asked it was still at least weeks away before we see anything
<apw> and i am not confident, we'll get it then, plus the fact its behind natty is starting to impact testing
<tgardner> apw, just did an update on oneiric. now I see the ti-omap4 branch
<apw> tgardner, cool 
<tgardner> apw, so, isn't the issue a namespace collision? e.g., the binary package names will collide in the archive. right now you're creating identicle package names for 2 pockets - http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/linux-image-2.6.38-1209-omap4_2.6.38-1209.13_armel.deb
<tgardner> 2 releases, rather (natty and oneiric)
<apw> they are at different version number however
<tgardner> thats the reason I've had to change the ABI series in the past
 * apw looks
<tgardner> apw, is simple version skew sufficient?
<brendand> bjf, sconklin - any news on the Natty -proposed kernel?
<apw> 	linux-image-2.6.38-1209-omap4_2.6.38-1209.13oneiric2_armel.deb
<apw> tgardner, thats the one in the pool in the PPA, so the filename is different
<apw> i thought we needed the abi to be different between all releases in the same pocket
<apw> so that the common header don't collide
<apw> and update each other
<tgardner> apw, there is that as well
<apw> ie all the armel common headers would be -10.X and swap about randomly
<apw> but version skew is enough if you only have that abi range once as far as i can tell
<apw> we can't do it this way going back to lucid for the lts backports as they are elective only
<tgardner> the difference with the LTS backports is that the source package name changes
<apw> right so we avoid the update
<apw> but here we'd want it
<tgardner> apw, but we do it with the meta package, _not_ through versioning
<tgardner> versioning of the kernel binary, that is
<apw> right, but the update would be ok
<apw> safe i mean
<apw> i could bump abi and release it on .39 comining in, but i dont think we need to
<tgardner> apw, AKAIK .39 doesn't work yet, so there isn't much use in releasing on .39
<tgardner> AFAIK*
<apw> right, that we are waiting  on a working one hense wnting a better .38
<tgardner> apw, but I think the ABI issue is separate. I'd be more comfortable with a unique ABI for each release.
<apw> tgardner, ok i'll respin it with an updated abi
<apw> should be trivial
<tgardner> apw, thanks.
<sconklin> brendand: No. We're totally dependent on several people who reported regression in the -proposed kernel to help test  , and are not getting responses from them. So it will sit until we get more information.
 * apw notes just how close together 'Delete PPA' and 'Package details', somewhat different risks for clicking too
<tgardner> sconklin, is that reasonable? how long do we wait on resources we don't own ?
<sconklin> tgardner: we have no way of knowing which of several hundred patches caused these, it's not a simple case of a known revert.
<sconklin> If we are to expend resources, the next step would be to assign someone to try to come up with reproducers
<tgardner> herton, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/794096/comments/8
<ubot2> Ubuntu bug 794096 in linux "SMTP and posting to a web-form time out (probably due to netfilter changes)" [Undecided,In progress]
<herton> tgardner: I think not, didn't tried reverting that
<herton> tgardner: other think I thought about that bug, the guy has a p54 card, and from 9.43 to 10.44 kernel it should have started to work again
<tgardner> herton, of the natty commits since the last release, its about the only patch that could have a bad effect on netfilter: 'git log -p --reverse Ubuntu-2.6.38-9.43..HEAD -- net'
<herton> so we could also have a conflict in his setup, from one of the logs seems the wifi is associating also on that machine
<herton> I'll revert also this commit and ask for him to test
<tgardner> herton, I frequently have that situation in Maverick on my laptop, e.g., 2 routes to the same place when I plug in an ethernet
<tgardner> herton, didn't lamont complain about a network regression also ?
<lamont> I did.
<lamont> testing it is somewhat problematic
<lamont> both reproducing it reliably to the point of having a good test, and then making time to run the tests on the one place I've seen it thus far
<tgardner> lamont, would it be in an environment that experienced fragmentation?
<lamont> PPPoE connection, so definitely subject to PMTU discovery and/or fragmentation
<tgardner> lamont, could you run one of herton's kernels with a specific patch reverted for awhile ?
<lamont> sure
<herton> lamont: you're running on lucid correct?
 * lamont checks on exactly when he next needs his network to really work
<tgardner> herton, it should be a natty kernel.
<lamont> herton lucid/i386
<lamont> though 'tever on the actual kernel you give me, as long as it's happy with a lucid/i386 userspace
<lamont> (the box is i386 only)
<tgardner> lamont, I thought we were talking natty. do you have a lucid version that you _know_ works, and the one that doesn't ?
<lamont> I have about 60 minutes before I'll need to yank the kernel back to something known-to-work
<lamont> 2.6.32-31-generic-pae works, the upgrade from about 4 days before I filed my bug to -32 broke things
<lamont> pae or non-pae, doesn't seem to matter
<lamont> symptom was "web sites don't work", with what looked to be perfectly normal tcpdump of the traffic
<herton> tgardner: lamont filled bug 791512 about it on lucid
<ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
<lamont> yeah - that bug
<herton> so it may well be that commit, which should also be in lucid
<lamont> herton: any chance you have a lucid kernel with that commit reverted?
<tgardner> herton, I'm not seeing that commit in Luciod
<herton> tgardner: hmm indeed, so the issue gets more strange, may be it isn't the same bug
<tgardner> herton, the only common patches between Lucid and Natty updates are 'dccp: handle invalid feature options length' and 'af_unix: Only allow recv on connected seqpacket sockets.'. The second one deals with fragments.
<tgardner> herton, nm, the second patch deals with sequences, not fragments.
<tgardner> still, those are the 2 patches that are common between the 2 releases, plus we have similar symptoms on natty.
 * lamont tries one of the two kernels he got before
<tgardner> herton, how about producing a kernel for lamont to try with those 2 patches reverted?
<herton> the dccp change I also can't see how it would cause the issue
<herton> tgardner: yep, will do this then
<herton> also revert on natty and ask MacSlow to test it
<tgardner> yeah, the dccp change looks benign, but you never know... the rest appear protocol specific.
<lamont> brb
<bjf> ##
<bjf> ## Kernel team meeting in one hour
<bjf> ##
<lamont> linux-image-2.6.32-32-generic-pae_2.6.32-32.63~01spc823e22f_i386.deb <-- this one is fai
<lamont> l
 * lamont tries the other
<apw> bjf, i hope it'll be over in an hour from then :)
<bjf> apw, is editmoin working for you since the wiki upgrade?
<apw> bjf they say they revoked all the key things, so you'd need to get the new one
<apw> if you can remember how
<bjf> apw, looking for that info now 
<apw> error: body information not found
<bjf> apw, indexing must be working, the search returned results, fast
<apw> bjf do yoou get htat ?
<apw> if so i think thats a different problem
<lamont> hrmpf.  did my last bit make it through?
<lamont> 585c_i386.deb <-- appears to be win
<lamont> <lamont> sconklin: ^^
<lamont> just in case
<lamont> <lamont> linux-image-2.6.32-32-generic-pae_2.6.32-32.63~01spce92585c_i386.deb <-- appears to be win
<tgardner> sconklin, what patches got reverted for that kernel ?
<sconklin> lamont: ok, those two commits (Sha1 in the version) bound the netfilter changes in the kernel
<sconklin> I was hoping one would pass and one would fail. That should take the bisection down to about 3 tries
<sconklin> tgardner: ^^
<tgardner> sconklin, ack
<tgardner> sconklin, are you bisecting the whole mess, or just the net directory ?
<apw> bjf, shame that login, and writing to pages is as slow as hell
<sconklin> tgardner: well, those were not bisections, just builds from those commits. 
<sconklin> hold on let me look at the repo
<tgardner> sconklin, that SHA1 includes the nf patches
<sconklin> yeah, it appears to be backwards from what I would expect
<sconklin> so I have no clue
<tgardner> sconklin, I do. your 'win' kernel excludes 'af_unix: Only allow recv on connected seqpacket sockets' which I think is the likely culprit.
<sconklin> ok, but not sure that explains the "lose' kernel
<tgardner> sconklin, herton is busily building a version with that and one other patch reverted. which one was the 'lose' kernel ?
<lamont> linux-headers-2.6.32-32-generic-pae_2.6.32-32.63~01spc823e22f_i386.deb
<sconklin> 823e22f was a faila ccording to lamont
<lamont> sconklin: note that I wish I had a testcase that was 100% reliable
<bjf> apw, did you get your's setup again, I can't find the "user info page"
<sconklin> Thanks Lamont - noted that it's not 100%.
<apw> bjf,  no it seemed broken and i was relying on you to get there first :)
<bjf> apw, i'll get it sorted and get back to you
<lamont> fwiw, in about 10 minutes, I go dark-for-testing for a couple hours minimum
<apw> heh, how lucky is that
<tgardner> lamont, I'll have herton post his kernel in bug #791512 please remember to check for it when you light up again
<ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
<lamont> tgardner: will do.  I'll be able to fetch it and all, just can't get away with rebooting my "test" box for a while
<apw> lamont, you'll be trying to convince us you have a day job next :)
<lamont> heh
<tgardner> lamont, no problem. now I'm off to track down Mirco who had similar issues, but with natty.
<herton> lamont: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791512/comments/4
<ubot2> Ubuntu bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New]
<lamont> test box actually gets used by other people, and they have needs
<herton> going to lunch here, will come back in ~30min
<lamont> Generating grub.cfg ...
<lamont> /usr/sbin/grub-probe: error: raid5rec is not loaded.
<lamont> User postinst hook script [/usr/sbin/update-grub] exited with value 1
<lamont> this is my other problem child: lucid kernel on a ESXi 4 vm
<lamont> with software rade
<lamont> raid. wow. where'd thatcome from
<apw> dunno but its like totally rad man
<apw> ogasawara, are you rebasing to -rc4 ?  i fancy a new shiney kernel, this one is getting old and tired
<ogasawara> apw: I am, ran into a minor bump, but test build should be finishing momentarily
<apw> ogasawara, yay, then i simply need to wait :)  
<ogasawara> apw: I'll ping you when it's ready
<apw> i am seeing horrible disk slowness, but i can't work out if that is cause its worse, or just because my bug mailbox has hit 60k messages .... /me applies a liberal dollop of D
<tgardner> herton, will you have a kernel for bug #794096 soon? I'll track down Mirco and get him to test it when its ready.
<ubot2> Launchpad bug 794096 in linux "SMTP and posting to a web-form time out (probably due to netfilter changes)" [Undecided,In progress] https://launchpad.net/bugs/794096
<apw> tgardner, last herton messages says back in 30, 7 mins ago
<tgardner> apw, right, I just didn't want him to forget what he was doing
<apw> :) ahh
<apw> bjf what was that weechat ish thingy called
<bjf> apw, weechat
<lamont> herton: you do promise this'll boot, right?
<bjf> booting is overrated
<lamont> bah.  your -headers package fails to install
 * lamont reboots again
<smb> lamont, Something completely unrelated and mostly out of curiosity: do you know whether the ppa builders run 32bit domU on 64bit servers or only matching architectures?
<bjf> apw, got new moin ids from IS but still busted, and they don't support editmoin, so i'm still working it
<apw> from is ?
<apw> i thoight they were personal, and you got them from your broswer
<lamont> herton: your kernel appears to be non-fail
<lamont> thank you
<bjf> apw, thought so also, still investigating
<apw> i think it was pitti who first introduced me to it
<herton> tgardner: yes it's built now, will copy it now
<lamont> smb: ppa builders are *wavehands* 64-bit everything where they can be (hw supports 64-bit), and 32-bit only where they need to be for hardware.
<herton> lamont: hmm ok, so one of the reverts probably worked
<lamont> with maybe 5 machines that make that statement a total lie. <-- smb
<herton> I'll build just with the af_unix change reverted, and ask you to test again, it's the most likely one
<lamont> herton: and dark-to-testing for a couple hours, but can do another one after that if you want to try unreverting one of those
<lamont> heh. nice collision there
<tgardner> herton, please detail in the LP report _which_ patches were reverted.
<apw> bjf, pitti says its broken and he's not managed to fix it
<herton> tgardner: ok
<bjf> apw, sweet!
<smb> lamont, Hm ok. Just asking cause I found "xm save" crashing when trying to save a 32bit domU on a 64bit kernel. And that seemed to be the same at least for the previous abi release.
<apw> bjf, see #ubuntu-devel
<ogasawara> apw: linux-image-3.0-2-generic_3.0-2.3_amd64.deb on tangerine in my oneiric-amd64 dir
<ogasawara> apw: i386 build in progress...
<apw> ogasawara, looks exciting 
<tgardner> ogasawara, close enough to push ?
 * apw updates his amd64 crasher pre-install
<ogasawara> tgardner: just booted it on an amd64 box so it must work everywhere :) which means I'm gonna push it
<tgardner> good enough for me
<apw> ogasawara, its those boots, hardcore
<lamont> smb: dom0 and domU are the same on all of them
<smb> lamont, Ah, that explains a lot. :)
<ogasawara> tgardner, apw: pushed to master-next
<bjf> apw, is got the ids from the server logs for my session, i don't know how to find them myself anymore, couldn't find them in firefox
<apw> bjf, oh i see, hrm
<apw> but they don't work anymore anyhow ?
<bjf> apw, right
 * apw focuses winning vibes on bjf
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<apw> ppisati, should we consider using a specific older version of the compiler for the kernel on arm ?
<ppisati> apw: can we switch compiler just for the kernel package?
<apw> ppisati, i think it is possible, not desirable normally but possible
<jjohansen> ppisati: what was the bug # on that one again
<ppisati> lp#791552
<ppisati> bug 791552
<ubot2> Launchpad bug 791552 in linux "No USB support on beagle/beagleXM" [High,New] https://launchpad.net/bugs/791552
<ppisati> in one of the message i attached the discussion where they acked the bug and proposed some workarounds (that didn't work here)
<ppisati> apw: goign back to 4.5 as long as this bug is not fixed is ok for me, but i fear that we could miss many early problems if we switch back even for the entire userland
<apw> ppisati, this would be only for the kernel
<tgardner> we used to use a specific kernel compiler for PARISC
<herton> tgardner: http://people.canonical.com/~herton/lp794096/reverts/
<herton> the kernel for Mirco to check
<apw> tgardner, thats what i thought, i think its a matter of setting GCC and adding the right build-dep
<maco> i was just reading victor's blog post. system tap works on ubuntu?
<tgardner> apw, yep. I think Hardy has an example
<apw> maco, beleive so yes, that is all ckings work, but he is off today
<ppisati> apw: if a fix doesn't appera before alpha2, then yes, because wihout usb our SOCs are not that userful: we loose eth, keyboard, mouse, etcetc
<maco> apw: ok. the system tap wiki claims it doesnt without lots of hacking around. one of the dinosaur book authors was looking at using ubuntu in the classroom and jumped to fedora after coming across that
<apw> maco, i'd not heard that, i would recommend you touch cking tommorrow and confirm he didn't have to jump hoop to make it work, i didn't think so
<tgardner> herton, Mirco won't know to try your new kernel unless you update the LP report. since he's subscribed he'll get an email
<apw> and if he says its working then we need to find and kill the systemtap errorage
<herton> yep, adding a comment there
<maco> will do
<apw> maco, thanks
<ppisati> apw: while here, can we have a meeting about arm kernel and the platform rally?
<ppisati> s/arm kernel/arm kernels/
<apw> ppisati, sure whatsup
<ppisati> apw: well, basically to pull all people involved together and try to define some kind of a schedule
<ppisati> apw: e.g. TI first said they were going .39
<ppisati> apw: last week said they moved to 3.0 (and they only told us when we asked about an ETA for the BSP)
<apw> ppisati, the rally is normally pretty free form, but if you need to get people together thats great
<ppisati> apw: but thert's no ETA, and there's no consesus on what to do
<apw> ppisati, are you suggesting at the rally or before the rally to prepare for the rally ?
<apw> ppisati, if at the rally just add it to the agenda
<ppisati> apw: if there's a slot at the rally
<ppisati> apw: ok, i'll talk with the arm and linaro people
<apw> ppisati, rally has about 10 meetings total there is plenty of time ... normally we just walk to people and sit on their laps till they talk to us
<ppisati> apw: cool, than i'll inform all the parties involved
<apw> ppisati, i think we already had said we would get with davidm etc and work out what we are doing with the ti kernels
<apw> ppisati, but reminding them can't hurt
<ppisati> apw: cool, then we are already set
<ppisati> but i'll ping people
<apw> apw_, oi
<apw> apw_, oi
<herton> lamont: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791512/comments/6
<ubot2> Ubuntu bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New]
<herton> when you finish testing the current kernel, just try that one with only af_unix change reverted
<lamont> herton: fetching both
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - July-5 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> apw
<lamont> herton: so are we expecting love or hate from r3?
<herton> lamont: love, but who knows :)
 * lamont stabs the machine to find out
<lamont> herton: the kernel is love
 * lamont boots in to -33.68
<herton> yeah, would be good to know now if -33.68 stock in proposed really has the issue
<herton> if 33.68 stock fails, that af_unix patch really is the culprit
<Quintasan> http://paste.kde.org/85561
<Quintasan> How not normal is the above output is?
<apw> Quintasan: depends how long it goes on for and what exactly the machine was doing when it occured
<Quintasan> apw: I'm doing linaro-media-create magic on my i.MX53 Quick Start board
<Quintasan> last output is Populating rootfs partition. Be patient, this may take a few minutes
<apw> and does the machine recover from that ?
<Quintasan> apw: It does, but I was unable to interact for a few seconds
<apw> if so then its likely you are just hammering crapola out of your usb stick and clogging up everything else
<Quintasan> Oh I see.
<apw> yep, thats a known "not really meant to react that way", but non-fatal
<lamont> herton: rebooting back into r3 to verify that the site that doesn't work now does work there
<apw> one shouldn't be able to starve you when doing such things, but you can with a lot of writes
<Quintasan> apw: http://paste.kde.org/85567
<herton> lamont: ok, so -33.68 stock failed then?
<Quintasan> apw: I was also wondering if you could tell me what's this
<apw> Quintasan: that implies the disk host controller lost the link to the drive and reset the link a couple of times to recover it
<Quintasan> apw: What can be the cause of that?
<apw> does it happen often, if it does something is up, could be a bug, could be bad h/w
<apw> very hard to diagnose, unless its common on one kernel and not on another, then we might be able to acertain why
<apw> i think its saying there was a parity type error on the transaction on the bus
<lamont> herton: 33.68 stock is fail
<lamont> though the test website did magically work on that one.  the other one was solidly fail, and works on r3
<lamont> so I have r3 live
<herton> hmm. well, seems that change then is causing things to break
<herton> lamont: can you post your testing results on bug 791512?
<ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
<Quintasan> apw: Okay, is it possible that cable is bad?
<lamont> herton: will do
<apw> Quintasan: it is _possible_ if you have a spare it may be worth changing.  it depends how often you see that, if its once ever i'd not bother
<Quintasan> more like three times a day
<Quintasan> :S
 * Quintasan goes to buy a new SATA cable
 * jjohansen -> lunch
<apw> tgardner-afk: you applied this 0726 commit to hardy/master and lucid/ti-omap4, but not to maverick/ti-omap4 ... is there a reason or just an oversight
<tgardner> apw, checking
<tgardner> apw, doh! I just missed Maverick ti-omap4, gimme a sec
<apw> tgardner: heh np, the matrix _is_ some use after all
<tgardner> apw, done
<apw> tgardner: ok i've pushed up a replacement oneiric ti-omap4 and tag (also removed the old tag) the tree diff is just the update script change and abi+100
<apw> tgardner: so i am inclined to just upload it
<tgardner> apw, looks good to me
<apw> tgardner: ok thanks :)
<apw> ENO-bjf
<herton> tgardner: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791512/comments/7
<ubot2> Ubuntu bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New]
<herton> seems that af_unix change is really at fault
<tgardner> herton, good. how about annoying the upstream authors? perhaps mention to the various stable maintainers that we're gonna revert it.
<herton> ok, I'll try to enter in contact with patch author and CC netdev, lets see what they have to say
<tgardner> ogasawara, did you have to use some magic to get oneiric to build ? I think ubuntu/rtl8192se is borken.
<ogasawara> tgardner: no magic needed for me
<ogasawara> tgardner: used the usual build scripts
<tgardner> ogasawara, hmm, a rebuild with that commented out in ubuntu/Makefile seems to be working better.
<ogasawara> tgardner: what was the error you were seeing?  my build log is on tangerine:oneiric-amd64/build.log
<tgardner> ogasawara, I've over written it already, but it was complaining about EXTRA_CFLAGS
<tgardner> ogasawara, I've updated the chroot on tangerine since your build. perhaps you should try again.
<ogasawara> tgardner: ah, will kick off another build then
 * tgardner --> EOD
#ubuntu-kernel 2011-06-22
<ohsix> sconklin: re #793796, i'm around if you want me to poke at stuff
 * apw yawns
 * smb joins apw
<apw> i cannot be bothered to even drink my tea today
 * smb realizes he forgot his coffee in the machine...
<apw> smb doh doh doh
<jk--> :)
<smb> *slurp*
 * apw waves to jk-
<apw> just how many -'s do you have today
<jk-> just the one now
<jk-> apw/smb: OK if I target https://bugs.launchpad.net/800527 to maverick ?
<smb> jk-, Not thinking so. Seems to be wrong number
<smb> At least lp does not find anything
<jk-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/800527
<ubot2> Ubuntu bug 800527 in linux "cx23885: Incorrect argument passed to videobuf_dma_unmap" [Undecided,New]
<smb> better :)
<smb> Ok, why not. Seems to be maverick affected, right?
<jk-> smb: yep, I've just never had to use the 'Nominate for a series' thing before, so wasn't sure what the etiquette/process is :)
<smb> jk-, Ah, well if your not an uploader, you need one of us to accept the nomination.
<apw> jk-: do we know why that original was applied even ?
<smb> Or we do the whole thing for you
<apw> jk-: it seems to be a sauce patch ?
<jk-> apw: it was a backport of some updated IR stuff, and yes, SAUCE
 * smb Yeah, I think I remember some discussion on that lirc stuff
<apw> jk-: then it was done badly and fixing it seems appropriate, i assume we get bangs without
<jk-> apw: no bangs seen so far
<jk-> probably leaks though
<jk-> the other change to cx23885-core.c causes bangs on a particular ASUS MB though
<jk-> but that's not *really* the driver's fault
<apw> jk-: sounds awsome
<smb> jk-, I wonder whether at least in the bug report it would help to point out that the faulty change was due to some sauce and that therefor does not affect any upstream stable 
<jk-> apw: yeah:
<jk-> grep MSI /proc/interrupts
<jk->  44:          0          0          0          0   PCI-MSI-edge      cx23885[0]
<jk-> smb: noted
<apw> smb, ... i like commas better
<smb> apw, huh?
 * smb thinks he misses some joke
<apw> smb, playing with settings ... trying out weechat for a bit
<apw> something i saw being used at the QA sprint, trying it out
<smb> apw, heh, so is it worth learning a new client
<apw> a question indeed.  it does the split window thing, and its actually a terminal program
<apw> so it has some advantages over xchat
<apw> but like all change, it is painful for the first person (me)
 * smb thinks its painful for every person trying
<apw> well less painful when someone can give you the one line you need to add specific new servers
<apw> took me a long time to even work out how to add one
<smb> True. Its more about the attachment to some style. Used to be ok with mud. Now have been using tb for so long...
<apw> exactly
<apw> has some nice features like hiding join part for people _unless_ they were talking recently when you might care
<apw> and they are only filtered so you can hit a key to see them
<apw> cking just appeared and dissappeared it seems ... network issues in his office perhaps
<smb> See I do the opposite with xchat. Hide them all but for people on my sh.. err friends list. :-P
<smb> Sounded like it
<smb> Or we look scary this morning :)
<apw> it would be funny if he can't get to his own wireless from the loft
<smb> Hope cking does not find out the only thing not being perfect in the new office is the lan cables
<apw> time for some ethernet over power adapters
<cking> apw, heh, did have a wireless fail - laptop worked last night, this morning wireless did not
<cking> I moved the latop 2 inches and it could then find the AP
<smb> cking, Your neighbours started to use theirs. :)
<cking> think I was not in a nodal point
<apw> cking, i think you need some ethernet over power from your router to your desk
<apw> then you can have a shiny local AP for your stuff up there
<apw> get one of those 20 dollar ones
<cking> apw, I've got that too, just wanted to make sure wireless worked before I hooked up my cheap and cheerful portable AP
<apw> ahh good
<Kano> hi, firmware 1.54 is too old for ath9k
<Kano> http://paste.debian.net/120626
<apw> Kano, does appear so, is that firmware update in upstream firmware tree?
<Kano> i fetched it from
<apw> don't suppose there is any hope you might file a bug
<Kano> http://wireless.kernel.org/download/htc_fw/
<Kano> no idea if it is somewhere else too
<Kano> why is the module-init-tools depency still not removed from the daily/rc builds
<apw> because i have not had time, have you had time?
<Kano> apw: i use dpkg-deb/sed of course, i had to do take thetime 
<ppisati> it seems there's a fix for the usb thing on omap
<apw> ppisati, yeah?  what sort of fix, got a pointer
<ppisati> apw: 1395401 linus tree
<apw> ppisati, looks 'ok' i guess, i assume you are going to get some test kernels together with that applied?
<ppisati> apw: doing it right now
<ppisati> apw: so far omap4 works
<ppisati> and indeed it works
<apw> ppisati, very good
<ogasawara> tgardner: I wasn't able to reproduce that build failure
<apw> morning ogasawara 
<tgardner> ogasawara, ok, I'll get back to it in a bit.
<ogasawara> mornin
<apw> tgardner, it is reported that ath9k needs updated firmware for oneiric: bug #800678
<ubot2> Launchpad bug 800678 in linux-firmware "ath9k firmware out of date for kernel 3.0" [Undecided,New] https://launchpad.net/bugs/800678
<tgardner> apw, is it upstream yet?
<apw> tgardner, i haven't checked, i actualy hoped it was the sort of thing you knew off the top of your head :)
<tgardner> apw, easy enough to check
<tgardner> apw, hmm, nothing jumping out at me.
<apw> there is a link to the firmware in the bug, but i have no idea of provenance
<tgardner> apw, I suspect provenance is fine. Atheros needs to get it into Woodhouse's repo
 * ogasawara back in 20
<tgardner> apw, re: CVE-2010-4526. You indicate in the preamble email that it applies to Lucid/ti-omap4, but then you sent a patch for lucid/fsl-imx51. confused...
<ubot2> tgardner: Race condition in the sctp_icmp_proto_unreachable function in net/sctp/input.c in Linux kernel 2.6.11-rc2 through 2.6.33 allows remote attackers to cause a denial of service (panic) via an ICMP unreachable message to a socket that is already locked by a user, which causes the socket to be freed and triggers list corruption, related to the sctp_wait_for_connect function. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4526)
<apw> tgardner, sounds like i am confused ... /me checks
<apw> there is no lucid ti-omap4 is there ?
<tgardner> hence my confusion
<tgardner> just wanted to be sure
<ppisati> apw: no
<ppisati> ti-omap4 starts in maverick
<apw> tgardner, the cover letter is in error
<tgardner> apw, ack
<apw> tgardner, the titles of the patches are correcet
 * apw hates all the silly names of arm things
 * amitk too
<ppisati> ouch
<ppisati> actually i already have CVE-2010-4256 for maverick/ti-omap4
<ubot2> ppisati: The pipe_fcntl function in fs/pipe.c in the Linux kernel before 2.6.37 does not properly determine whether a file is a named pipe, which allows local users to cause a denial of service via an F_SETPIPE_SZ fcntl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4256)
<ppisati> on zinc
<apw> ppisati, so much for me trying to include arm
<apw> kees, we need our bug thing sorted out so we have somewhere to interlock updates
<ppisati> apw: actually i've it only in mav/omap4
<ppisati> apw: wait...
<ppisati> yes
<ppisati> fsl-imx51 doesn't need it
<ppisati> apw: anyway, go ahead, no prob
 * apw is still using the 'awsome' tracker, but seemingy i am on the only one
<ppisati> ah right, i should have updated it
<tgardner> ppisati --> beers to apw
<apw> ppisati, no real blame, the process is in a massive mess while we wait on bugs being kept in sync
<smb> tgardner, Sorry, I had been changing my mind about code cleanup just this morning
 * ppisati updates the cve tracker...
<tgardner> smb, s'alright. I think I have it figured out.
<smb> On the positive side, this is much smaller
<apw> ppisati, get your updates pushed up i recon, sooner rather than later
<tgardner> smb, have you tested this final version ?
<smb> tgardner, Just passed the point it would have crashed before when I sent it
<tgardner> smb, ack
<ppisati> apw: ok, i push it now
<apw> ppisati, i don't mind a few extra pull requests, its mosrly the same amount of work -- reviewing the patches
<ppisati> btw, whats status can i use for "i have it in one of my tree but not pushed yet"?
<apw> ppisati, there isn't one, and thats why its a problem
<apw> and why you and i are stepping on each other.  thats why we have yet a third place to track things
<ppisati> apw: yeah, but i was confused ny the "pull req only when the window opens" aka this morning discussion
<apw> we want to remove all that and make the bugs the primary copy
<ppisati> yep
<tgardner> ppisati, apw: its 'In Progress' until pushed to the main repo when it becomes 'Fix Committed'
<apw> BUT that needs kees stuff to work
<apw> tgardner, right on the bugs yes
<ppisati> tgardner: uhm... i did that transition on launchpad but not on the cve tracker
<ppisati> tgardner: i was looking for a "in progress" state there too
<apw> but as i discovered yesterday searching for 'CVE-NNN-MMM' in launchpad does nto always find you a bug you know exists
<apw> and its there that things go wrong, as we have an external list of bugs currently
<ppisati> apw: yep, i use two search the cve page, and then walk there the list of lacunhpad bugs attached until i find the right one (usualy it has the same title as the CVE)
<ppisati> s/two/to/
<apw> ppisati, what search do you do, all mine make no sense and find nothing
<apw> i hate launchpad search its almost useless
<ppisati> apw: https://launchpad.net/bugs/cve/
<apw> OH its the damned 'if the main task is closed i don't exist bug'
<apw> thats why i've missed the bugs and crossed with you
<apw> ppisati, have you got an example bug you are currently working on so is in an active state
<apw> bah these searches just do not include bug tasks i can clearly see exist
 * tgardner back in 10
<ppisati> ok, i borked the git url
<apw> ppisati, where ?
<ppisati> apw: lucid/fsl-imx51 pull req, but i sent another email with the right url
<apw> ppisati, ahh i see
 * apw bounces to fix some niggling bustness
 * ppisati -> out to buy a couple of usb cables
<tgardner> apw, the buglink for CVE-2010-4163 is wrong. isn't that messing up your status page ?
<ubot2> tgardner: The blk_rq_map_user_iov function in block/blk-map.c in the Linux kernel before 2.6.36.2 allows local users to cause a denial of service (panic) via a zero-length I/O request in a device ioctl to a SCSI device. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4163)
<tgardner> it should not be bug #690730
<ubot2> Launchpad bug 690730 in linux "Maverick update to 2.6.35.10 stable upstream" [Undecided,Fix released] https://launchpad.net/bugs/690730
<tgardner> or maybe its the result of your CVE checker script
<apw> tgardner, the bug links matter not to the cve updater
<apw> tgardner, commonly where i take a backport and cherry-pick that i will leave the BugLu
<tgardner> apw, ack
<apw> BugLink alone, and add anohter one at the bottom too
<apw> tgardner, does it have two ?
<tgardner> nope
<apw> hrm, then i suspect i forgot it, thats naught
<apw> naghty
<apw> tgardner, is there a bug do you know
<tgardner> apw, dunno, didn't check.
<tgardner> it was something that we got via stable, so likely not
<apw> tgardner, now i am confused, according to the Awsome tracker there is one, but you are assigned to the row
<apw> bug #721441
<tgardner> apw, maverick/ti-omap4 ?
<ubot2> Launchpad bug 721441 in linux-ti-omap4 "CVE-2010-4162" [Undecided,In progress] https://launchpad.net/bugs/721441
<apw> bah missed, bug #721504
<ubot2> Launchpad bug 721504 in linux "CVE-2010-4163" [Undecided,Fix committed] https://launchpad.net/bugs/721504
<apw> tgardner, if you are applying now do add it
<tgardner> apw, can do
<tgardner> apw, pushed maverick/ti-omap4. better now?
<apw> tgardner, looks like you did only one of the pair of patches for -4163, not that i think it matters much
<tgardner> apw, likely. I only noticed one commit in error before I lost interest
<apw> tgardner, fyi the cve updater uses only upstream commit ids from the logs and the ubuntu tags to work out the release correlations
<apw> thats why its important those are maintained, of course it is policy to so maintain them
<apw> ppisati, thats looking pretty good, fix two more CVEs for arm and hardy will officially move into last place
<apw> ppetraki, would it be useful to have a matrix of just the arm kernels? 
<apw> ppisati, ^^ even
<tgardner> ogasawara, what is the exact command you're using to build oneiric on tangerine ?
<apw> tgardner, which build is failing for you ?
<ogasawara> tgardner: I use the 'build-start --dist oneiric --branch master-next tangerine-amd64'
<tgardner> its still the ubuntu/rtl8192se stuff. the 2.4 kernel part modifies CFLAGS which kbuild hates.
<apw> tgardner, for amd64 yes?
<tgardner> ogasawara, try it with 'kteam-tools/buildscripts/ukb-make --arch=amd64 --release=oneiric --branch=master-next --clean'
<tgardner> apw, yes
<apw> tgardner, and which flavour fails
<tgardner> binary-generic
 * apw lets his tools build it too, to see if its tools related
<tgardner> apw, if I delete all of the Makefile code for 'KERNEL 2.4' then it works fine
 * tgardner thinks the rtl8192se makefile is hideously fucked.
<apw> ifeq ($(shell uname -r|cut -d. -f1,2), 2.6)
<apw> ifeq ($(shell uname -r|cut -d. -f1,2), 2.6)
<apw> tgardner, ^^ EEK
<tgardner> uh huh, indeed
<apw> so if your _host_ kernel is 3.0 it will fail
<tgardner> 3.0-1-server
<apw> so i suspect this will run on tangerine ok, and not on your local systems
<tgardner> right, so I guess I'll fix that
<apw> 2.6.35-25-server <- so tangerine indeed
<apw> but that is utter spack, and should be based on the kernel version... though just making that like like
<apw> ifeq (1, 1)
<apw> would likley be just as appropriate as we know it is NOT 2.4
<tgardner> now, I like that kind of fix :)
<ppisati> apw: i'm ok with the big matrix
<tgardner> !vi
<ubot2> Text Editors: gedit (GNOME), Kate (KDE), mousepad (Xfce4) - Terminal-based: nano, vi/vim, emacs, ed - For HTML/CSS editors, see !html - For programming editors and IDE, see !code
<apw> the things ubot2 knows ... i ask you
<ppisati> bug 800758
<ubot2> Launchpad bug 800758 in linux-ti-omap4 "CVE-2011-1082" [Undecided,New] https://launchpad.net/bugs/800758
<ppisati> please accept the nominations
<ppisati> apw: ^^^
 * apw looks
<apw> ppisati, done
 * cking wonders how many euros to take to dublin
<tgardner> cking, enough to buy bus fare to the hotel
<cking> tgardner, no beers or food in the evening?
<maco> cking: how'd you get system tap going with ubuntu? last i checked the wiki it was like "fedora: install it. ubuntu: jump through hoops!"
<tgardner> cking, I think there is an ATM in the hotel
<maco> did the hoop-jumping reasons go away?
<cking> maco, let me find the runes...
<tgardner> lamont, are you still happy with the kernel herton built for you yesterday regarding bug #791512 ?
<ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
<cking> maco, part of this README is relevant to getting systemtap installed: http://kernel.ubuntu.com/git?p=cking/pmdebug.git;a=blob;f=systemtap/README;h=56ca292345a02dea722ffee603ca598af5403356;hb=a86d419fc92da76abb6ff6731cf43667de5c14b2
<lamont> tgardner: I have heard no complaints, and experienced no issues with it
<tgardner> lamont, great. I'll add that to the bug.
<lamont> tgardner: likewise, upstream(?)'s reply to the email does concern me more than I'd like to admit
<ppisati> uhm... CVE-2011-1082 and CVE-2011-1083 point to the same fix
<ubot2> ppisati: fs/eventpoll.c in the Linux kernel before 2.6.38 places epoll file descriptors within other epoll data structures without properly checking for (1) closed loops or (2) deep chains, which allows local users to cause a denial of service (deadlock or stack memory consumption) via a crafted application that makes epoll_create and epoll_ctl system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1082)
<ubot2> ppisati: The epoll implementation in the Linux kernel 2.6.37.2 and earlier does not properly traverse a tree of epoll file descriptors, which allows local users to cause a denial of service (CPU consumption) via a crafted application that makes epoll_create and epoll_ctl system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1083)
<tgardner> lamont, me too. I'm gonna have to do some deep code dive. empiracal evidence suggests there is something going on the Eric has overlooked.
<cking> maco, you may find that building a .ddeb kernel is required if there isn't an appropriate kernel .ddeb :-(
<lamont> tgardner: I hope so.  because random data stomping is (1) scary, and (2) a cheap copout
<maco> cking: i feel like there should be an add-ddebs.deb that puts it in /etc/apt/sources.list.d/ and gets the key, like those rpms that install yum repos
<tgardner> lamont, we have some initial findings that the same patch affects 3.6.38.8, so the random code stomping theory is likely specious.
<maco> or the key should be included by default and the ddebs repo in sources.list but commented
<maco> thatd be handy too
<lamont> tgardner: very nice
<apw> maco, i think we might be able to add it by default if that pool is made one of those 'opt in only' repos
<cking> apw, is that a discussion point for the platform rally?
<maco> apw: isnt commenting it out enough to make it count as "opt-in only"?
<apw> maco, not sure, they are talking about having things like backports enabled all the itme, and then you only getting packages you explicitly install updated
<apw> which would fit well for the ddebs i suspect
<maco> apw: with pinning?
<apw> maco, i think somehow its the default on the repo so you don't have to have anything locally, but functionally like the pinning yes
<broder> maco, apw: we definitely talked about turning on ddebs by default at uds in one of the sessions
<broder> you shouldn't have to pin, though, since the packages all have different names
<broder> no, wait, we talked about adding it by default, but commented out
<broder> and including the key in the default keychain
<maco> oh, cool, so what i just said
<broder> let me go dig up the blueprint...
<broder> http://summit.ubuntu.com/uds-o/meeting/foundations-o-dbgsym-integration/
<broder> looks like...nobody ever actually turned it into a spec. hmm...
<fowlduck> We have an Intel Xeon E5645 and we're not seeing the 2 threads per core in lscpu, cat /proc/cpuinfo, etc, despite the processor being capable of hyperthreading. Is there a way to determine what features are supported by the kernel? I'd like to check if hyperthreading is enabled but haven't a clue.
<fowlduck> also, not sure if this is the appropriate place for this question
<tgardner> fowlduck, hyper-threading is definitely enabled. what kernel  and HW are you using?
<fowlduck> Intel Xeon E5645 and `uname -a` # => Linux 358015-domain 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
<mjg59> fowlduck: Your BIOS supports the processor?
<mjg59> And put dmesg up somewhere
<tgardner> yeah, this is likely a BIOS issue
<fowlduck> http://pastie.org/private/hdib338al84ipuhgqetja
<fowlduck> mjg59: I'm actually not even sure, we're using a bare-metal host that rhymes with shmackspace and don't have access to the BIOS 
<mjg59> fowlduck: At a guess I'd say that hyperthreading is disabled in the bios
<mjg59> The R710 should be new enough to handle those chips
<tgardner> looks like a Dell Poweredge, and I know they are supported.
<fowlduck> ok, great, we'll push this back to our host
<fowlduck> thanks guys
<tgardner> mjg59, fowlduck:     0.228857] Booting Node   0, Processors  #1 #2 #3 #4 #5
<tgardner> [    1.126949] Brought up 6 CPUs
<tgardner> [    1.126956] Total of 6 processors activated (28728.72 BogoMIPS).
<mjg59> Yeah, that should mean that ACPI only gave us 6
<tgardner> an R710 has 6 physical cpus ?
<fowlduck> yep, it's a hex-core, so with HT it should show 12: http://ark.intel.com/Product.aspx?id=48768
<tgardner> fowlduck, oh, 6 cores. I'm just a little slow today.
<fowlduck> :)
 * tgardner --> lunch
 * jjohansen -> lunch
<herton> tgardner: about that af_unix patch, after Eric responded I made this small testcase which that patch fixes: http://pastebin.ubuntu.com/630957/
<herton> just in case it helps with something
<herton> may be one of the applications lamont uses on that server has the same bug, recv before accept
<herton> sconklin: ^^
<tgardner> herton, looking...
<sconklin> also looking
<tgardner> herton, attach that to the bug with an appropriate explanation. I'd also summarize Eric's email about why the patch exists.
<herton> ok
<sconklin> It never occurred to me that doing a receive before accept could ever work in anything . . .
<tgardner> herton, are you able to cause a kernel oops with that patch reverted ?
<herton> testing here on natty worked, previous to 10.44
<herton> on 10.44 it returns the ENOTCONN
<sconklin> unless it's in some path that fails but another fallback path works
<herton> tgardner: on my test machine it didn't oops
<sconklin> oh, interesting
<sconklin> Maybe cking knows whether SystemTap can be used to detect a userspace app that does this and point a finger
 * tgardner --> EOD
#ubuntu-kernel 2011-06-23
 * apw yawns
 * jjohansen waves goodbye
<apw> ppisati, morning
<apw> ppisati, i see you looked at CVE-2011-1090, i assume you are just looking at the versions which are a straight cherry-pick there?
<ubot2> apw: The __nfs4_proc_set_acl function in fs/nfs/nfs4proc.c in the Linux kernel before 2.6.38 stores NFSv4 ACL data in memory that is allocated by kmalloc but not properly freed, which allows local users to cause a denial of service (panic) via a crafted attempt to set an ACL. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1090)
<ppisati> apw: yep
<ppisati> apw: actually when i posted it i just wanted a couple of acks, but an apply is even better :)
<apw> ppisati, tim likes to get things moving along
<ppisati> yep
<apw> ppisati, i closed out your oldest active CVE, 2010-3859 turns out it was already applied when i fixed the upstream commits
<ppisati> ok
<ppisati> apw: CVE-2011-0711 is marked as "needs-triage" in fsl-imx51 but the fixes have already been committed
<ubot2> ppisati: The xfs_fs_geometry function in fs/xfs/xfs_fsops.c in the Linux kernel before 2.6.38-rc6-git3 does not initialize a certain structure member, which allows local users to obtain potentially sensitive information from kernel stack memory via an FSGEOMETRY_V1 ioctl call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0711)
<apw> ppisati, ok let me look at that
<apw> ppisati, ok that was cause by the fact that there are two sha1s for the possible fixes upstream
<apw> ppisati, and for lucid and lucid only someone used the other one for one patch
<apw> ppisati, can and will fix it now
<ppisati> apw: and i just noticed that i forgot one of the patches in maverick/ti-omap4... uhmmm....
<apw> ppisati, which is presumably why its also needs-triage
<apw> ppisati, so just slap that one on the next pile and it will sort itself out
<ppisati> yep
<ppisati> and luckily mav/omap4 didn't go out... it seems SRU has enough work...
<apw> ppisati, it actually doesn't matter, as the CVE would not be deemed fixed until the second patch was detected as applied so they would get half the fix (which in this case is useful and safe) but not an entire fix
<ppisati> ok
<apw> ppisati, this is one of the advantages of the new scripted detection, it really knows if you are done
<ppisati> cool
<apw> before you would have said "released" and the world is bluffed
<apw> ppisati, ok 0711 is now fixed for fsl-imx51
<ppisati> k
<ppisati> apw: http://bugs.launchpad.net/bugs/801083
<ubot2> Ubuntu bug 801083 in linux-ti-omap4 "CVE-2011-1012" [Undecided,New]
<ppisati> nominations
<apw> ppisati, done
<ppisati> btw, why don't i have the nominations right? i mean, this why i don't way to beg anyone
<ppisati> this way
<apw> ppisati, because stupidly nomination rights are part of being an uploader or a very very high up in release managment option
<ppisati> ah
<ppisati> uhm
<apw> ppisati, which frankly makes no sense to me what so ever, but that is how it is
<ppisati> so how do i become an uploader?
<apw> i think there are plan afoot to split nomination off so we can ask for you to get that
<ppisati> ok
<apw> to be an uploader you need to learn all the stuff that herton is doing basically
<ppisati> doh!
<apw> then convince someone outside the group to let you
<apw> (there is a committee)
<apw> i am sure you will be asked to get that over time, but the nominations thing should be separate
<ppisati> ok, let's hope for the rights split
<apw> as it is simply very very anoying
<ppisati> right
<apw> it was worse when noone in our team in the EU had them, smb and i had to wait until tim woke up
<apw> and that made us very mad
<ppisati> what a waste of time
<apw> ppisati, yeah and its on our "please fix this" list for launchpad, it should be a separate acl so we can add canonical-kernel-team to the nominations one
<ppisati> apw: sounds logical
<ppisati> btw, here's another one
<ppisati> CVE-2010-4163
<ubot2> ppisati: The blk_rq_map_user_iov function in block/blk-map.c in the Linux kernel before 2.6.36.2 allows local users to cause a denial of service (panic) via a zero-length I/O request in a device ioctl to a SCSI device. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4163)
<ppisati> it's made of 2 patches
<ppisati> but the second one supeseded the first one
<ppisati> thus i apllied only the second one
<ppisati> and the CVE matrix marks it as "needs-triage"
<apw> ppisati, lookin
<apw> ppisati, so does one get reverted or something? 
<apw> ppisati, ok i see so one adds it and the other moves it
<apw> ppisati, so what did you do, just add it in the second place?
<apw> in the second commit?
<apw> if so then the new single commit should mention both sha1s as it is both
<ppisati> apw: just committed the second one
<ppisati> ah, ok
<apw> but the second one is a move
<apw> so it wouldn't apply without the first right?
<ppisati> modified it
 * apw will sort this out somehow
<ppisati> ok, thanks
<apw> ppisati, ahh good its not been 'released' yet so i can just re-write it
<ppisati> apw: can't you just fix the tracker?
<apw> ppisati, i can only fix the tracker by telling it that your commit actually should say two things
<apw> ppisati, and as this has not yet been closed i can rewrite it safly
<apw> ppisati, so its simpler to fix the history so its accurate
<ppisati> ok
<apw> ppisati, i see why you only got half the fixes ... as only one is marked in the lucid history, as we got half via stable
<apw> you do need to check the tracker for all the ids
<ppisati> apw: and there's another one in the same state, somehow...
<ppisati> CVE-2010-4655
<ubot2> ppisati: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4655)
<ppisati> it's made of 2 commits
<ppisati> the first one was in lucid/master (and i cherry picked it)
<ppisati> while the second one was made to resolve a conflict with nother commit (and we didn't import)
<ppisati> so it was not committed in master
<ppisati> and thus i didn't bring it in
<apw> ppisati, ok so we are in the right place there (fsl-imx51 yes?)
<ppisati> apw: yep
<ppisati> apw: both fsl-imx51 and mav/omap4
<ppisati> but in the CVE tracker ios marked as "needs triage"
<apw> yes as the tracker says you need both to make that CVE 'applied'
<apw> for those i will tell the tracker applier those ones only needed the one sort of
<ppisati> so, do i import the clashing commit and the second fix, or what?
<ppisati> ok
<apw> if we truly only need the first fix to fix the CVE then i can tell the tracker that
<apw> ppisati, ^^
<ppisati> apw: as far as the CVE goes, yes, we need only the first one
<apw> then good enough
<apw> tgardner, any idea if lsattr is related to xattrs or if its something else
<apw> stupid naming
<tgardner> apw, haven't the faintest.
<tgardner> lsattr - list file attributes on a Linux second extended file system
<tgardner> doesn't seem to display extended attributes
<apw> pwd
<apw> pthhtht
<ogasawara> smb`: can I mark your iscsitarget work item as done?
<ogasawara> bah, forgot he's away today
<tgardner> ogasawara, I applied his patch, so I would say yes
 * ogasawara back in 20
<tgardner> apw, do you remember which firmware bug number you pointed me at yesterday? the only update for Oneiric that I see is for  iwlwifi-5000-5.ucode
<apw> tgardner, hmmm
<tgardner> apw, nm, I can probably find it through LP
<apw> tgardner, i filed it so i should be able to find it pretty quick
<tgardner> apw, bug #800678
<ubot2> Launchpad bug 800678 in linux-firmware "ath9k firmware out of date for kernel 3.0" [Undecided,New] https://launchpad.net/bugs/800678
<tgardner> its ath9k, not iwlwifi
<apw> tgardner, heh how did you find it quicker than i can from my own list ... bah
<tgardner> apw, if you look at the package page (https://bugs.launchpad.net/ubuntu/+source/linux-firmware), it gives you a link to new bugs
<apw> tgardner, point
<tgardner> apw, ogasawara: where can I find the list implied in this work item: '[timg-tpi] review assigned set of Ubuntu delta patches and push upstream where applicable: TODO'
<ogasawara> tgardner: https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview
<ogasawara> Tim Gardner
<ogasawara> ubuntulo1: SAUCE: Disable building the ACPI debugfs source
<ogasawara> ubuntulo1: Sony laptop: Some Sony Vaia laptops do not enable wwan power by default.
<tgardner> ogasawara, ack. thanks. you're as efficient as always :)
<apw> ogasawara, do i see your nick completion getting out of wack there ?
 * apw pops out to do some rally prep errands
<ogasawara> apw: nah, cut and paste from the wiki turned out weird
<ogasawara> apw: s/ubuntulo1/UBUNTU/
<apw> ogasawara, i think thats nick completion though as that sub is actually a nick on this channel
<apw> ogasawara, i suspect you have : as auto nick complete
<ogasawara> hrm, /me check
<apw> try typing tga:<space>
<ogasawara> apw: you're right, it's set in my preferences
<apw> right hairy backson
<tgardner> apw, re :bug #800910 - are there any flavours other then -generic and -server that ought to have grub-efi as a bootloader ? I can't imagine any of the 32 bit platforms needing it.
<ubot2> Launchpad bug 800910 in linux "Kernel Upgrade forces removal of grub-efi due to missing recommends entry" [Undecided,In progress] https://launchpad.net/bugs/800910
<apw> tgardner, i wouldn't imagine so, if we had a -xen we might want it there
 * apw is now officially shawn
<tgardner> apw, what is shawn?
<apw> tgardner, it is what you do to a sheep
<tgardner> oh, you got your ears lowered
<apw> tgardner, i see we have grub-efi all the way back to hardy, i wonder if we should have that anywhere earlier than natty
<tgardner> apw, what are the odds that machines will work with grub-efi in environments that old?
<tgardner> will the kernels even work?
<apw> tgardner, i assume we won't put it on by default just allow it to already be there, dunno if the kernels work of course
<apw> heh
<tgardner> I don't think kernels prior to Natty will support native EFI
<apw> tgardner, i am a little worried about it being first, does that have any meaning
<tgardner> apw, not as far as I can tell
<apw> i am wondering if that is the one it would cause to be on the CD
<tgardner> apw, its a recommends. we could always ask cjwatson or slangasek
<apw> tgardner, ok the rule according to steve is the first one is the preferred one
<apw> so if nothing else asks for anything then we only put on grub-efi
<tgardner> apw, so I shold swap it
<apw> i suspect that means we should put it second on natty at least
<apw> tgardner, thats my take yes
<tgardner> well, likely the same for oneiric
<apw> yeah likely
<tgardner> ok, I'll fix it up
<apw> pgraner, what is it you use to keep your tunnels open
<cjwatson> tgardner: grub-efi should definitely never be first
<cjwatson> and "forces removal due to missing recommends" is nonsense
<cjwatson> an unsatisfied recommends should not force removing a package
<cjwatson> also, the real packages involved are grub-efi-amd64 and grub-efi-ia32 - grub-efi is a metapackage
<cjwatson> good grief, that apt-get output is incredibly weird
<cjwatson> tgardner: in my book, that's an apt bug and you should give mvo a task for it - adding non-first grub-efi-amd64 | grub-efi-ia32 Recommends won't hurt though
<tgardner> cjwatson, well, should I reference the meta package, or the underlying package (since they are somewhat arch dependent, right?)
<cjwatson> underlying
<cjwatson> it doesn't matter if you recommend something that's missing
<cjwatson> especially when it's one of several alternatives
<tgardner> cjwatson, ok, can do
<cjwatson> referring to the metapackage: consider the case where somebody has grub-efi-amd64 installed but not grub-efi
<tgardner> makes sense
<cjwatson> I still think it's not really your problem, but fixing apt's resolver in a stable release probably isn't happenng
<pgraner> apw, gstm
<apw> pgraner, ta
 * tgardner is off to pack and get the road show organized, remembering the wifi AP for the hotel room.
<apw> tgardner-afk, yeah wired only, how backward
 * jjohansen -> lunch
<kees> apw: hm, why the not-affected -> pending changes? (rather, why was it ever not-affected?)
<kees> -devel_linux-ti-omap4: not-affected
<kees> +devel_linux-ti-omap4: pending (2.6.38-1309.13)
<apw> kees, likely the version is it pending in is one from -release or before therefore not-affected ... after you do your usn processing
<apw> kees, our agreed approach was move to pending if the version changes, so here it was n-a (no version) and now is (version) so it moves pending ... i assume you will process to n-a (version) and we are good
<apw> or you will issue the usn cause it was wrong
<kees> apw: but there are no USNs for devel releases
<kees> apw: it was only the devel_* ones that I was curious about.
<kees> apw: I would have expected them to just stay as "not-affected", but I guess once the tool found the commits, it made it "pending".
<kees> I guess that's fine. our other script will fix this up as expected. okay. :)
<kees> apw: heh. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/788684 changelog entry says "CVE-1011-..."  time travel! :)
<ubot2> Ubuntu bug 788684 in linux "CVE-2011-2022" [Undecided,In progress]
<kees> apw: where can I find the lucid mvl-dove tree? I'm trying to identify 'Revert "econet: fix CVE-2010-3848"
<ubot2> kees: Stack-based buffer overflow in the econet_sendmsg function in net/econet/af_econet.c in the Linux kernel before 2.6.36.2, when an econet address is configured, allows local users to gain privileges by providing a large number of iovec structures. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3848)
<kees> ' in the changelog
<kees> to make sure the fix came in from the upstream update, but I can't find the tree. (or rather, the one I know about doesn't have the revert)
<kees> apw: oh-ho, I see it in master-next.
<kees> is there an mvl-dove -next ?
<kees> sconklin: do you know where I can find the -next trees for the other kernels? now I'm trying to hunt stuff for fsl-imx51 :)
<tgardner> kees, the only -next trees we carry are for the master branch because they are typically the only branches that have multiple committers
<tgardner> rather, the only -next branches....
<sconklin> kees: what he said
<kees> tgardner: okay, that makes sense. I guess I'm just trying to figure out how to review a kernel in -proposed when it one of the ports
<tgardner> kees, check it out based on the tag ?
<kees> tgardner: I'm not sure what you mean? for example, I was looking at mvl-dove, but it's tree didn't show that is in -proposed
<tgardner> kees, well, the git repo doesn't really reflect the state of the package. is that the association you're trying to make ?
<kees> yeah
<sconklin> you have to check out the tag associated with the release
<kees> it works for the master branches since there are versioned tags, etc
<kees> sconklin: how would I do that for mvl-dove? I didn't see an associated tag
<sconklin> which is especially necessary for branches like arm which are rebased
<tgardner> about all you can say is that at each tag _something_ was uploaded, but it may not have been pocket copied from the c-k-t PPA
<sconklin> kees: looking
<sconklin> well, not 100% true, because things have been tagged and then failed to upload. But mostly true
<apw> kees, there are tags for every upload so those should be the contents of the upload
<apw> they are not linear on teh branches, but they should exist
<kees> "not linear on the branches"
<kees> ?
<sconklin> branches which are rebased from other branches do not have a linear history across releases
<apw> a rebased tree like mvl-dove is not linear in time, it jumps about, each release is tagged but you can only find the released version via the tag, as after rebase the commits it was made from are no longer findable from the head of the branch
<kees> sconklin, apw: okay, so I see "Ubuntu-2.6.32-217.34" which is the version for mvl-dove, but I guess that tag isn't visible when I look at the mvl-dove branch?
<sconklin> right
<kees> aaah, so what I see in mvl-dove is basically the "next" rebase
<kees> or, next next.
<sconklin> so do a 'git checkout -b mybranch Ubuntu-2.6.32-217.34'
<apw> kees, the tag has mvl-dove in it doesn't it?  Ubuntu-mvl-dove-version
<sconklin> or the last one
<apw> but either way there is a tag and thats the way to get it
<sconklin> apw: no, people have been very inconsistent in their tagging
<apw> sconklin, yep and we are going to talk about htat at Rally, and i suggest fix them too
<sconklin> apw: ack +1
<sconklin> sconklin@xps-1:/src/ubuntu/ubuntu-lucid$ git tag | grep mvl
<kees> okay, so I guess what tripped me up is that I can't navigate those tags via the gitweb interface.
<sconklin> Ubuntu-mvl-dove-2.6.32-416.33
<sconklin> Ubuntu-mvl-dove-2.6.32-417.34
<sconklin> sconklin@xps-1:/src/ubuntu/ubuntu-lucid$ 
<sconklin> never tried that. 
<apw> kees, ok, so of course you could checkout the bzr branches the importer is importing
<kees> apw: right, I'll do that. the rebase confused me since I saw no tags after I looked into the branch.
<kees> I feel saner now! :) thanks guys :)
<apw> heh ... kees lets get together at rally and make sure you can find what you want
<sconklin> kees: np, it does take a bit of head-wrapping
<sconklin> generally, if in doubt you can take the version from the package without decoration, i.e. '2.6.32-416.33' and grep for that in the tags
<kees> apw: well, see, that's the problem, I don't know what I don't know. I keep hitting these weird situations while going about what I thought was a standard process. heh
<kees> sconklin: yeah, that's my way forward
<sconklin> when we standardize our tags it will be easier
<apw> kees, yeah thats how the cve tracker updater does it too
<apw> sconklin, ^^
 * kees nods
<sconklin> all this reminded me that we should schedule some testing of running all the stable tools across a 3.0 kernel so we don't spend the week after release picking up pieces
<apw> sconklin, oh you will :)
<apw> sconklin, perhaps i should upload one into ckt for giggles
<sconklin> apw: I know we will. I wrote some of the regex's we use . . . ;(
<sconklin> apw: don't do it when I have easy access to you.
<sconklin> meaning within a 12 hour flight
<apw> sconklin, :)
<sconklin> Although it will be easy enough to grab the development branch and try to prep a package
<sconklin> it's going to explode hard
 * apw wanders off again
#ubuntu-kernel 2011-06-24
 * apw moans about mumble ... again
<cking> should be called grumble
<ppisati> yep, it's really quiet this morning
<cking> we are so busy
<ppisati> lp 801473
<ppisati> nominations
<ppisati> bug 801473
<apw> bug 801473
<apw> bug #801473
<ppisati> the bot is on strike today
 * apw slaps ubot2
<apw> ttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/801473
<apw> thats not a bug
<apw> nope LP doesn't know that number
<apw> pp^
<apw> ppisati, ^^
<ppisati> uh?
<ppisati> wait
<ppisati> ah
<ppisati> still private
<ppisati> bug 801473
<ppisati> now it's pubbli
<ppisati> c
<ppisati> *public
<apw> bug #801473   
<ppisati> crap
<ppisati> it doesn't work...
<apw> ppisati, approved
<apw> ppisati, this CVE -1082/-1083 where they share the same sha1 fix
<apw> ppisati, for those just put both CVE numbers in the body and let them both go releeased rather than mark them ignored
<apw> ppisati, i've moved 1083 back to needed to mirror -1082
<apw> ppisati, i think we should leave th bottom 5 yellow entries, the new ones to be worked as a CVE across teh whole distro
<apw> as in not just fixed for arm
 * apw is going to look at the bottom on (2534) as 'todays' CVE
<ppisati> doh!
<ppisati> waity
<ppisati> i just did the 2534
<ppisati> and i created the lp bugs for the other 4 news
<ppisati> ...
<ppisati> the 4 new one
<apw> well thats annoying ... 
<apw> if you don't mark the awsome tracker i am going to assume they are not done
<ppisati> you mean the cve tracker?
<ppisati> i'm doing in batch
<apw> nope that awsome tracker
<apw> https://spreadsheets.google.com/a/canonical.com/spreadsheet/ccc?hl=en&key=tOvtWlTi17QL1bZm-0dCKEg&hl=en#gid=0
<ppisati> ah ok
<ppisati> did you do anything?
<apw> whats your bug # for 2534
<apw> so i can dup my bug against it
<apw> i cannot be assed to close all the tasks i just opened
<ppisati> 801473
<ppisati> and then i have
<ppisati> 801480 801482 801483 801484
<ppisati> for the other 4
<ppisati> and btw i need nominations acceptance for them
<apw> ug #801480
<apw> bug #801480
<ubot2> Launchpad bug 801480 in linux-ti-omap4 "CVE-2011-1170" [Undecided,New] https://launchpad.net/bugs/801480
<apw> bug #801482
<ubot2> Launchpad bug 801482 in linux-ti-omap4 "CVE-2011-1171" [Undecided,New] https://launchpad.net/bugs/801482
<apw> bug #801483
<ubot2> Launchpad bug 801483 in linux-ti-omap4 "CVE-2011-1172" [Undecided,New] https://launchpad.net/bugs/801483
<apw> bug #801484
<ubot2> Launchpad bug 801484 in linux-ti-omap4 "CVE-2011-1173" [Undecided,New] https://launchpad.net/bugs/801484
<apw> ppisati, all done
<apw> do put them in the awsome
<ppisati> k
 * apw stops working on cves ..
<apw> ppisati, so do we have open bugs for all the open cves now ?  sounds like you've been opening them
<ppisati> apw: yep, for all the cve that i tackle if there's no open bug, i open it
<ppisati> and while here, i should report the other cve i've in my queue...
<ppisati> i mean, in the awesome tracker...
<apw> if there is no line for them you could add them yes, and for any you have a bug get that in too
<apw> we are likely to stop using the tracker once we have proper automation, but we'll need something to seed the links between the cves and bugs, and it may as well be the awsome tracker
<apw> ppisati, i _thnk_ the only one missing is CVE-2010-2955
<ubot2> apw: The cfg80211_wext_giwessid function in net/wireless/wext-compat.c in the Linux kernel before 2.6.36-rc3-next-20100831 does not properly initialize certain structure members, which allows local users to leverage an off-by-one error in the ioctl_standard_iw_point function in net/wireless/wext-core.c, and obtain potentially sensitive information from kernel heap memory, via vectors involving an SIOCGIWESSID ioctl call that specifies a lar
<ppisati> which link?
<ppisati> -> "we'll need something to seed the links between the cves and bugs"?
<apw> ppisati, i am saying that to allow any automation to update the bugs from the tracker and visa-versa will need a list of cves against their bug numbers
<ppisati> ok
<ppisati> but why do we need an external tracker? can't we use launchpad for everything?
<apw> ppisati, lunchpuddle doesn't support some of the information in the tracker
<ppisati> extending it? :)
<apw> right :)  i'd like to fix searching so i can find your cves, and they can't do that, so i have no hope they would add anything security needs
<ppisati> nothing a whip cannot fix...
<apw> ;)
<ppisati> ok, i think i'm done with the aws tracker
<apw> ppisati, you are doin 2534 right?  i've changed that to you in the at
<ppisati> yep
<apw> ok have fun with all those cves
<apw> ppisati, what is the status of 2011-1090
<apw> ppisati, are you done with it?  if so i might do teh remaining ports
<ppisati> apw: i always do the arm side
<ppisati> apw: so yes, hardy is there for you
<apw> so are you doing the fsl-imx51 for that one ?
<ppisati> yep
<ogasawara> hrm, looks like some of the data for our work items is incorrect @ http://people.canonical.com/~platform/workitems/oneiric/canonical-kernel-team-oneiric-alpha-2.html
<ogasawara> other-kernel-o-ubuntu-delta-review 	1 	0 	0 	0 	8 	89%
<ogasawara> Started
<ogasawara> I know for sure we have more than 1 todo items remaining
<apw> ogasawara, hmmm, i could 2-3 depending who is in the c-k-t
<apw> ogasawara, ok the matrix on the oneiric status page, the wiki one, seems to show at least 3, probabally 5
<ogasawara> apw: that sounds better
<apw> ogasawara, so the database must be ok, but the reports are not right somehow
<apw> ogasawara, as pitti seems quiet, could you remind me in dublin and we can incestigate
<ogasawara> apw: yep, I'll throw it on our agenda so we both don't forget
<apw> ogasawara, ahh good plan
 * apw has to admit to feeling lax, i am alread thinking about packing
<ogasawara> apw: just go pack and have a beer
<apw> ogasawara, i am thinking of the packing part anyhow
<ogasawara> I'm thinking of a coffee to wake up, kai won the battle last night
<apw> ogasawara, thats hard for sure ...
<apw> ogasawara, seems its cause the title are the same of the work items, seems we've regressed and are squashing them in the table part though not in the graph
<ogasawara> apw: huh, ok.  so I guess I could just fudge the titles to be different for now
<apw> ogasawara, yeah make them [apw] review apw's patches or something
<apw> and we can try and fix it at sprint
<ogasawara> apw: and I'd assume then the one's marked DONE are also afflicted by the same
<apw> ogasawara, yeah i believe so
<apw> ogasawara, do you recall if we report any stats for cves in the weekly meeting ?
<ogasawara> apw: I don't think we do
<ogasawara> apw: but I would find that info interesting if we did
<ogasawara> apw: just to know if we're falling behind processing them
<apw> ogasawara, i was thinking something along the lines of those at the bottom of here, in a digestable form: http://people.canonical.com/~apw/cve/pkg/ALL-linux.html
<apw> ogasawara, probabally just and overall number, 21 cves open some some release sort of thing
<ogasawara> apw: yep, that would be nice
<apw> i think i can make this page produce all the numbers one might care for ... hmm something to consider
<ogasawara> apw: we sure have a lot of 'pending' ones
<apw> ogasawara: yeah though that is triggered by them either being in -proposed only or if kees has not yet run a reconcilliation against the usns
<apw> ogasawara: and i think we are pending quite a bit both ways
<apw> for us any sort of green is positive, and will resolve itself without further interaction from anyone but stable
<ogasawara> apw: so is our CVE workflow ironed out now, eg security team opening bugs to drive our work etc.
<apw> ogasawara: not yet, the last bits are meant to be finished by next week, we are meeing with -security to iron it all out
<ogasawara> apw: cool, didn't know if we needed to add it to the agenda but sounds like you guys are already set to meet
<apw> ogasawara, if you have the agenda on your browser lets add something to remind us
<ogasawara> apw: ack, I'll add it since I'm staring at it right now
<apw> (is the release meeting in 10m?)
<ogasawara> apw: yep, I got it covered
<apw> i don't doubt you are prepared :)
<hyperair> manjo: ping
<hyperair> manjo: i happened to stumble upon http://permalink.gmane.org/gmane.linux.kernel.input/19005 while attemptnig to find a fix/workaround for my e220s. did you make nay progress on that issue?
<hyperair> last post seems to be april
<manjo> hyperair, its a bios issue ... if you load your module with proto=bare you can work around it 
<hyperair> manjo: proto=bare detectss only a single device.
<hyperair> and both the touchpad and trackpad work through it
<hyperair> as a result, the touchpad doesn't work with synaptics
<ogasawara> apw: bah, I had an old release schedule for O, Alpha2 is the week after rally
<ogasawara> apw: so I'll plan to upload our final Alpha2 kernel Friday of the rally
<hyperair> manjo: also, my bios doesn't seem to have a setting to disable the touchpad =\
<apw> ogasawara: ok, well we should probabally still go for something today as its been a while
<ogasawara> apw: yep, still plan to upload after the release meeting
<manjo> hyperair, yeah ... I know ... I did email the guys at lenovo about this ... and have not seen a bios  that fixes that 
<ogasawara> apw: will you be able to watch for any fires the week of Alpha2, I'll keep an eye too even though technically being on vacation
<hyperair> manjo: did you receive a reply from them?
<manjo> hyperair, I got an email from them saying synaptic is looking at it 
<hyperair> ah i see
<hyperair> hmm
<apw> ogasawara: yeah of course
<apw> ogasawara: unless we are totally on fire its a noop anyhow for us
<hyperair> manjo: a matter of time, eh.
<ogasawara> and here I tried so hard to schedule vaca around the milestones
<manjo> hyperair, good that you reminded me ... I need to ping them again on this ... been a while 
<hyperair> manjo: np.
<hyperair> actually if you could CC me as well, that would be great. i'd like to hear when a fix comes out =)
<apw> ppisati: did the usb fixes get committed yet?
<ppisati> apw: yep
<apw> ppisati, cool thanks ... must make sure they are uploaded early next week if they have not already
<ppisati> apw: right, i've a couple of pull req pending
<apw> ppisati, sounsd good, thanks
<lmn123> What does this dmesg line mean ?
<lmn123> [    1.731033] sata_svw 0000:01:0e.1: PCI INT A -> GSI 11 (level, low) -> IRQ 11
<apw> lmn123, its telling you how PCI interrupta are being connected up and delivered
<cking> apw, isn't it beer time?
<lmn123> apw, http://pastebin.com/4pv4Zivv
<lmn123>  By observing the time diff in consecutive lines, does it look normal ?
<lmn123> line 7 and 8
<lmn123> apw, here is the correct link. http://pastebin.com/hzkYZ3nS
<smoser> apw, are you actually stlil around?
<smoser> bug 801408 is what i reported about a week ago. i saw it again and tried to collect some more info.
<ubot2> Launchpad bug 801408 in linux "out of memory, dont know why" [Undecided,Confirmed] https://launchpad.net/bugs/801408
#ubuntu-kernel 2011-06-25
<openfly> Hey all are there any immediate plans to re-add raw1394 and ohci1394 support to the 11.04 kernel?
<eruditehermit> hey, is there a ppa with kernel 3.0.0 rc4 for natty?
<eruditehermit> or a ppa with mainline builds for natty
<htorque> hello everyone! i got a question about bug 760142: if there was a fix, would it be backported to natty?
<ubot2> Launchpad bug 760142 in linux "Several Ubuntu-certified Dell laptops: ImPS/2 ALPS GlidePoint configure as PS/2 mouse instead of proper touchpad" [Medium,Confirmed] https://launchpad.net/bugs/760142
<apw> htorque, it always depends on how intrusive the fix is, how specific to the h/w it fixes, and how likely it is deemed to regress other non-matching h/w
<apw> if it 2k l
<apw> if it 2k lines of change its going to be a no
<apw> htorque, last i heard there still wasn't a proper fix cause alps were refusing to tell people how it worked
<htorque> apw: ok, thanks for the comment :-)
<apw> htorque, do you have an actual fix ?
<htorque> apw: oh no, i just asked here to help answering a question at askubuntu.com
<htorque> apw: but it seems quite unlucky that this is happening with ubuntu certified hardware :(
<apw> htorque, its certified with a working touchpad, just not very well
<apw> htorque, we are really not in control over the h/w vendors who keep stuff secret
<apw> htorque, they are mad imo
<htorque> apw: i know and i agree :-)
#ubuntu-kernel 2011-06-26
<etneg> hi
<etneg> whats so differnet about the ubuntu kernel vs say fedora's?
<etneg> you get to precompile it with different support options?
#ubuntu-kernel 2012-06-18
 * smb yawns
<cooloney> smb: morning,
<smb> cooloney, Morning, how are things going?
<cooloney> smb: i'm good, just went through the kernel config about cgroups, looks like there is not much change we need to do
<cooloney> smb: could you please share the link for me again about the review cgroups config task
<smb> cooloney, Ah, good it is not too much. Though I take it some things are still missing... Sure, give me a sec
<cooloney> smb: thanks. 
<smb> cooloney, It is not directly the link to the workitem, but this may be even more useful: http://status.ubuntu.com/ubuntu-quantal/u/cooloney.html
<smb> The link for the cgroups stuff is in the work item details
<cooloney> smb: wow, thanks a lot, i searched a lot but failed to find out this
<smb> cooloney, It is a good place to look whether someone gave you a work item without telling you. ;)
<cooloney> smb: for the CFQ and deadline discussion, i plan to reply to the reporter about cking's evaluation
<cooloney> smb: and ask for some hard facts in detail
<smb> cooloney, Is that your friends or theother reporter?
<smb> I think from the other report it is at least clear that it is related to kvm and the emulated disk
<cooloney> smb: i sent out an email, did you see that
<smb> cooloney, I just started my email and begin to drink some coffee, don't expect too much, yet... :-P
<cooloney> smb: echo 10 > /proc/sys/kernel/hung_task_timeout_secs
<cooloney> And start some parallel reads and writes. After a while dmesg will
<cooloney> have some warnings about flusher being blocked.
<smb> cooloney, But quickly looking, I am not sure I see it. Where did you send this? cc me somewhere or our mailing list(s)
<cooloney> we will got oops with CFQ but not with deadline
<smb> cooloney, Well sure that is maybe not the ideal fairness but should not yet bet fatal. 
<cooloney> smb: yeah, not fatal.
<smb> Means somehow deadline still does not cause a latency of more that 10s while cfq des
<smb> does
<cooloney> smb: i sent to c-k-t
<smb> cooloney, Ohhh
<smb> You mean last week ...
<cooloney> yeah,
<smb> That one I did see. Thought it was something new
<cooloney> it should be last friday
<smb> Sorry, yeah, I saw that test. Surely I need to check on the latency values on the data I got.
<smb> But I have not yet done so
<cooloney> smb: np, do you think i can put cking's evalution report in LP bug?
<smb> cooloney, I would maybe wait till we get some time to talk to him. I think for how it looks, test data may concentrate on the wrong details. This was mainly looking at the trhoughput
<smb> But the gelt problem seems rather that the latency goes quite high
<smb> This sounds a bit too bad for something called fair scheduler. I wonder whether it is something basic or really a bug in the code
<smb> If we add data, we should put up both views
<cooloney> smb: yeah, my friend in taobao.com said they originally used CFQ by default, but got some time out writing issue in their system
<cooloney> then they applied some patches from google to add deadline features in CFQ, 
<cooloney> so i'm looking for those patches
<cooloney> but not sure it's the same issue
<smb> Right, initially I thought that it might just be the emulated disk controller but if there is something really wrong with cfq and it is possible to get it so badly behaving that there seems to be no progress, this sounds like a real problem with cfq
<smb> I think it would be interesting to have several io tasks in parallel and see how much the latency and runtimes differ...
<ppisati> moin
<smb> Since throughput seems not too bad, it looks a bit like that is done in chunks that potentially are long times apart
<smb> ppisati, morning
<cooloney> ppisati: morning, man
<cooloney> smb: for parallel tasks, I just run bonnie++ 3 times in background
<smb> cooloney, Right, now you only need to gather the data for that. Meaning probably a) how long do those tasks run, b) what is the throughput and c) how much latency each task sees on those tests...
<smb> And at least while looking at the latency one needs to be careful as bonnie does change the scale
<cooloney> smb: ok, i will test it again, my computer will be quite slow when testing this. -:<
<smb> cooloney, Hold on just a bit. I could do it as well on a different machine. Or it might be that cking has the data already but jut not yet put into graphs
<cooloney> smb: ok, np, actually, i have a server machine, which was occupied by my wife.
<smb> cooloney, And you really think _was_? ;)
<cooloney> smb: it't not very powerful actually, and any new items for lxc or virt stuff you think i need to take care of?
<cooloney> smb: i found there is not much work for lxc,
<smb> cooloney, Not directly, but making sure at least one of us knows all the parts on the kernel side to make it work (or to adjust if needed). And verify the test cases Serge has (are they covering enough, is something missed)
<smb> Especially interesting should be how they try to get the environment as secure as possible. 
<cooloney> smb: got it. thx
 * apw looks out on a new week
<smb> apw, nothing to see. It is just preparing to lash out 
<cooloney> apw: morning
<apw>  moin
<smb> cooloney, So cking would be helping to do some testing later on. He got lots of kit to let it run on
<cooloney> smb: cool, save my poor computer.
 * ppisati notes 3.5rcX redefines the concept of "f*cked up" for omap3
<cooloney> ppisati: what's the "f*cked up" crap in 3.5-rc for omap3?
<ppisati> cooloney: it doesn't survive 2 boots in a row
<ppisati> cooloney: secondo time the fs is badly corrupted
<tgardner> henrix, did you see the email on the kteam list about the hp infrared RC6 remote regression ?
<henrix> tgardner: checking...
<henrix> tgardner: ah, ok. will reply in a minute
<henrix> tgardner: i'm actually looking at a similar bug with same kernel
<tgardner> henrix, ack
 * ogasawara back in 20
<ppisati> brb
<sisar> i want to file a bug about touchpad, i should file it under "ACPI" or "Drivers" ? (https://bugzilla.kernel.org/enter_bug.cgi)
<rtg> ogasawara, herton, apw: I need to reboot gomeisa to clean up some sbuild carnage.
<herton> rtg, ack
<ogasawara> rtg: gimme 2min to copy some build logs off
<rtg> ogasawara, ack
<ogasawara> rtg: ok, reboot whenever you're ready
<rtg> herton, ownership on gomeisa seems to have gotten totally scrogged when I installed sbuild. its gonna take awhile to restore ownership settings I think
<herton> rtg, yep heard that, I probably will go to tangerine for now too
<apw> rtg, ack
 * ppisati -> gym, back in a bit
 * herton -> lunch
<bambee> hi
<ogasawara> bambee: hi, thanks for joining the channel.  you mentioned you were interested in getting involved and I suggested bug triage is a nice place to start as it gets you familiar with Launchpad, how our bugs are handled, and our typical work flows in general.
<ogasawara> bambee: if this is something you'd like to start with I'd actually point you to jsalisbury and he can help you get started.
<jsalisbury> bambee, o/
<bambee> jsalisbury: hi 
<jsalisbury> bambee, if you are interested in triage there is a few good wiki pages that is good to review:
<jsalisbury> bambee, https://wiki.ubuntu.com/Bugs/HowToTriage
<bambee> I would be interested in kernel/testing and debugging, I think or debugging+triaging
<jsalisbury> bambee, there is allot of info there.
<jsalisbury> bambee, we can always use help testing :-D
<jsalisbury> bambee, and debugging/triaging
<bambee> oh
<jsalisbury> bambee, the best way to get started is to take a look at some of the wiki docs.  Then go through the process of triaging a new bug, which I can help you with.  And if you find a bug with similar hardware that you have, testing for those types of bugs really help.
 * bambee is reading the wiki docs
<bambee> ok it's noted, thanks for your explanations ;)
<jsalisbury> bambee, sure np.  just let me know if you run into anything you have questions on.
<bambee> for a beginning, you're right, I think that's probably better to start with triaging and testing (to be familiar with launchpad and your development process). Later I think I would like to help with development, and bugs fixing (this is a task reserved for guru, probably).
<bdmurray> apw: any news on bug 882147?
<ubot2> Launchpad bug 882147 in linux "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147
 * rtg -> eod
<henrix> jsalisbury: ping
<jsalisbury> henrix, pong
<henrix> jsalisbury: regarding bug #1014800
<ubot2> Launchpad bug 1014800 in linux "infrared remote doesnt work anymore (3.2.0-26)" [Medium,Confirmed] https://launchpad.net/bugs/1014800
<henrix> jsalisbury: mind if i step in? i believe i know the issue, so i've built a test kernel
<jsalisbury> henrix, absolutely :-D  Thanks for the help!
<henrix> jsalisbury: thanks. its related with a patch i submitted
<jsalisbury> henrix, ok, thanks
<henrix> jsalisbury: so, i'll just "readjust" the patch and it should fix it
<jsalisbury> henrix, good stuff
<henrix> jsalisbury: ;)
#ubuntu-kernel 2012-06-19
<FNStaffa> yo
<FNStaffa> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<FNStaffa> !ops
<FNStaffa> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<tjaalton> anyone know if stable@vger is moderated?
<smb> morning
<smb> tjaalton, Not as far as I know. But it may do some delaying when one is not registered and such...
<smb> tjaalton, And I see some mails from you posted recently
<tjaalton> smb: oh cool, I'll just wait then :)
<ppisati> moin
<cking> smb, my tests are still running - HDD is getting rather over-worked :-/
<smb> cking, Saw your email. Rather than worrying about your hdd, how are you doing?
<cking> smb, I'm OK - crashed out a late afternoon, got a raging temperature and head was all fuzzy, lots of sleep seems to have helped, but woke up at 6am, so I kicked off some tests again
<smb> cking, Sounds a bit like dragging something along. 
<cking> yep
<smb> Anyway, yeah. It seems that something really is not cool with cfq...
<cking> so, for the multi-bonnie + dd reader + dd writer, deadline finishes in a few minutes, but cfq is saturated by the dd I/O and bonnie is taking forever to complete
<smb> So in the present state it really is not well suited for server and I wonder how well it is for desktop...
<cking> bit rubbish for both methinks
<cking> let's face it, a dd seems to suck up all the I/O for some strange reason, so it seems totally unfair
<smb> right. What you could try (when things ever finish) is to disable autogroup (just wondering about it since trying to find something else around it)
<smb> /proc/sys/kernel/sched_autogroup_enabled
<cking> yep, I will give this test one more hour to complete and try that
<smb> cking, It might be time for breakfast. Isn't it?
 * cking munching it right now 
<smb> cking, There are rumors about doing that at the breakfast table and non-sticky keys... ;-P
 * cking nods
<cking> munchy munchy munch
 * apw yawns slowly
<smb> apw, Morning. Overstretched jaw?
<cking> is he still yawning?
<smb> cking, ultra slow motion...
<cking> just the thought of the yawn is making me yawn too
<bambee> morning
<xnox> If I'm trying to see which releases an upstream commit went into, is it save to use commitid, e.g. git branch -a --contains commitid
<xnox> on the ubuntu git kernels
<xnox> ?
<xnox> as in, do you ever rewrite upstream history? or do you only ever rebase on top of it?
<infinity> apw: Is the linux-image-hwe-generic stuff in precise-* meant to be in main?
<infinity> apw: (And linux-image-current-generic, which depends on it)
<infinity> You know what, I'm going to assume yes, and we can punt it back to universe if I'm wrong. :P
 * henrix will be away for a while
<xnox> infinity: you are awake :/
<xnox> anyway I think we are sorted with bug 1014883
<ubot2> Launchpad bug 1014883 in linux "Check that the nasty md/raid bug is not currently shipped across all releases" [High,Fix released] https://launchpad.net/bugs/1014883
<infinity> xnox: Not for long.
<xnox> infinity: =))))
 * xnox taps infinity, and he crashes
<ppisati> brb
<cking> smb, so my first round of bonnie++ tests are complete, - you want me to re-run with  /proc/sys/kernel/sched_autogroup_enabled set to zero?
<smb> cking, Yes, you don't have to wait eternity for completion. Just to quickly check whther it makes a difference
<cking> smb, hrm, let's see how it works out on the faster of the two tests...
<smb> cking, Thinking is that maybe having processes isolated counters the goal cfq tries to archive ...
<smb> Though sounds completely opposite to what we thought to have seen...
 * cking needs to check this tweakable
<smb> cking, Basically it turns off the feature that a task with its own session id gets into its own taskgroup
<cking> ok, lets see if it does any better
<cking> smb, looks like I'm getting a more even share of time to each reader + writer, but let me see what the final data says
<smb> cking, Interesting... yeah
 * cking is surprised at how long multiple bonnie tests take, sigh
<ppisati> cking: i should try them on any arm board, you would be shocked how fast they run on your x86 box :)
<ppisati> s/i/you/
 * cking chuckes, yep,  you' would see them complete just at the point that the sun turns super-nova
<ppisati> probably later
<cking> oh, when time comes to a halt then
 * cking reboots his AP once more
<brendand> jsalisbury, ping
<jsalisbury> brendand, pong
<brendand> jsalisbury, i'm trying to get back to confirming https://bugs.launchpad.net/bugs/960311
<ubot2> Ubuntu bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Confirmed]
<brendand> jsalisbury, i can't seem to find the binary packages for the old kernel
<brendand> jsalisbury, you wanted me to try : https://launchpad.net/ubuntu/+source/linux/3.2.0-17.27
<brendand> jsalisbury, in case you don't remember, this bug appeared about alpha2 and then i got the lab engineer to upgrade the bios and it seemed to disappear. then it returned again at release
<jsalisbury> brendand, The .debs you can install are under "Builds".  You just need to click on your specific arch.  Let me look at the bug, it might be beetter to try a newer kernel.
<jsalisbury> brendand, It might be best to test the latest Precise kernel, then go from there.
<jsalisbury> brendand, https://launchpad.net/ubuntu/+source/linux/3.2.0-25.40
<brendand> jsalisbury, i can even test it with the -proposed one (that would actually be easier for me)
<brendand> jsalisbury, i'll try and update asap
<jsalisbury> brendand, sure that would be great
<Yankees52> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<Yankees52> !staff
<ubot2> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :)
<Yankees52> yay =)
<Yankees52> === bazhang_ is now known as bazhang
<Yankees52> [03:13] <ubottu> Yankees52 called the ops in #xubuntu ()
<Yankees52> [03:27] <ubottu> Yankees52 called the ops in #ubuntu-irc ()
<Yankees52> [03:28] <bazhang> hfsplus again
<Yankees52> [03:28] <Jordan_U> I didn't know I had ops powers in #ubuntu-irc.
<Yankees52> [03:29] <Unit193> You do?
<Yankees52> [03:29] <Jordan_U> Well, I'm in the !ops factoid there. Let me check if I actually do.
<Yankees52> [03:29] <ubottu> FNStaffa called the ops in #ubuntu-motu ()
<Yankees52> [03:30] <bazhang> I don't but the emergency ! o p s call is the same as in #ubuntu
<Yankees52> [03:30] <Jordan_U> Maybe that should be changed :)
<Yankees52> [03:30] <Unit193> Appears my fancy cloak allows me.
<Yankees52> [05:11] <sistematico> Any help is welcome on #ubuntu-br
<Yankees52> [05:11] <sistematico> JavaNunes is using bad words and insulting others users.
<Yankees52> [05:43] <bkerensa> IdleOne: you around?
<Yankees52> [06:07] <bkerensa> What do we suggest to users reporting abuse in a loco channel if they have no ops available?
<Yankees52> [06:07] <bkerensa> Brazil's loco channel has a guy in there that has been using vulgar profanity in there and trolling it it would appear nobody with ops is around.
<Yankees52> [06:13] <Flannel> bkerensa: LoCo channels are -irc, but in case of emergency, that channel has ubuntu/member as operators, so... if it's an emergency, it seems you have the ability to handle it yourself.
<Yankees52> [06:13] <bkerensa> kk
 * ogasawara back in 20
<arges> apw, rtg https://bugs.launchpad.net/ubuntu/+source/linux/+bug/905219
<ubot2> Ubuntu bug 905219 in linux "Linux Kernel crash in Netfilter both in Natty (2.6.38-8-server) and oneiric(3.0.0-13-server/3.0.0-14-server) kernels" [Medium,Confirmed]
<rtg> henrix, has the patch for drivers/media/rc/ene_ir.c been accepted upstream ?
<henrix> rtg: no, i haven't submitted it yet
<henrix> rtg: will do in a minute, i was just waiting for you guys to take a look just in case... :)
<rtg> henrix, ack
<janimo> apw, ogasawara when does ubuntu switch to a new upstream major release kernel? I did not see in the wiki when master-next with a new kernel based on upstream rcX replaces the stable one on master
<ogasawara> janimo: well I uploaded our first v3.5-rc3 based kernel for Quantal today
<ogasawara> janimo: can you point me to the wiki you are looking at?
<ogasawara> janimo: I don't have it as a step in my upload process to update the wiki, but will do so in the future if that's what people are monitoring
<janimo> ogasawara, thanks I just saw 3.5 is on master too (it was not yet a few hours ago when I last looked)
<janimo> I meant the various kernel wiki pages in general
<ogasawara> janimo: yep, I only pushed it this morning
<janimo> the mentions of master-next I saw only related to SRUs where it is clearer when they are folded into master
 * janimo goes on to rebase armadaxp on 3.5
<ogasawara> janimo: indeed our master-next branches are for staging purposes only, nothing is official until it lands in master.  I'll try and get our wiki's cleaned up if they are misleading.
<janimo> ogasawara, the SRU part of it is clear, just being in a -devel series I was not sure if there are hard rules as to when to go with Linus' next besides 'when it feels right' :)
<cking> smb, I'm still waiting for one more set of results to pop out of my test box - I will get them to you tomorrow
<smb> cking, Sure. By then I might have a brain again to understand... ;)
<cking> hopefully I won't be vomiting up so much tomorrow either :-/
<smb> cking, Lucky for me that does not transfer that well via email... But yeah, hope you get better
 * cking heads for some rest
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 26th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<janimo> smb`, any reason why a canonical email address is enforced in maint-tools? Non-Canonical lemployees could find them useful, or even canonicalers with an @ubuntu.com address
<janimo> smb`,  and by maint tools I mean the maintscripts in kteam-tools :)
<dupondje> Somebody alive here that can help me with some usb power issue ?
#ubuntu-kernel 2012-06-20
<thomi> is anyone able to help me diagnose why inotify seems to not work on a live CD boot, as described here? https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1015348
<ubot2> Ubuntu bug 1015348 in linux-meta "openssh-server package does not start sshd on a live CD boot" [Undecided,New]
<thomi> Oh, I see it's already been reported: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147
<ubot2> Ubuntu bug 882147 in linux "overlayfs does not implement inotify interfaces correctly" [High,Triaged]
<scientes> can i get on that backport track with kernel for precise NOW?
<scientes> There are various reasons I want a 3.4-based kernel
<tjaalton> scientes: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<tjaalton> scientes: what reasons?
<smb> janimo, You mail look into git for you answer: eb66750db88b59b28ac91c627dd0984b5508f5a6 (at least for maint-startnewrelease). And it was not me putting it there. ;)
<smb>  s/mail/may/
<smb> Morning, btw
<ppisati> moin
<smb> tjaalton, Hey, I just noted on your submissions to stable that they only went there (and yourself). Usually it is better to cc at least the maintainer(s) and the author (depending on Greg's mood (if it is for one of his stable trees) the sub-system mailing list too.
<smb> Reason is that maintainers not always (if at all) look at stable but are normally required to ack or nak
<tjaalton> smb: oh
<tjaalton> it's not mentioned on Documentation/stable_kernel_rules.txt though
<smb> tjaalton, I try to put everyone who signed-off and the author (if not equal to one s-o-b) on cc. Maybe not, but I could give you examples of me being told so. ;) And it just gives you a much better chance at being seen/noticed. :)
<tjaalton> smb: heh, ok
<apw> bjf, henrix, looks like this might be a regression-update: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1015480
<ubot2> Ubuntu bug 1015480 in linux "webcam not found (no device found)" [Undecided,New]
<henrix> apw: checking
<apw> cking, hey you looked at bug #904261, did the fix for that make it into the main kernel ?
<ubot2> Launchpad bug 904261 in linux "Lenovo U300s does not suspend" [Medium,In progress] https://launchpad.net/bugs/904261
<henrix> apw: yeah, it looks like. thanks
<cking> apw, not yet, I'm waiting for a specific patch to land
<apw> cking, so i think you supplied a custom kernel, and that has now been superceeded
<dileks> hi
<cking> apw, yep, that's true
<apw> cking, if you have the patch around it might be nice to spin a replacement
<dileks> is a wubi-installation a somehow elegant way to "bypass" secure-boot problem :-)?
<cking> apw, I could do that, but I could be doing this until 3.6 at this rate
<apw> cking, if this one fixes it then lets just SAUCE it in
<cking> apw, and there is a user-space hackaround for it
<cking> apw, the patch is really ugly and won't get upstreamed, it was just a sanity check to see why things were locking up
<apw> the userspace work around is reported (by a normal) to have stopped working
<apw> http://marc.info/?l=linux-pm&m=133573212512122&w=2 <-- this one ?
<cking> yep
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904261/comments/32
<ubot2> Ubuntu bug 904261 in linux "Lenovo U300s does not suspend" [Medium,In progress]
<cking> it's more complex that that though
<apw> i cannot tell easily as the machine was installed by someone else, but i am suspicious he had your kernel
<apw> and its gone now, and he is not using the work around, hmmm
<cking> apw, fundamentally it is partly to do with a BIOS issue
<apw> cking, so the kernel you did was jsut a bodge and not something we can put in master
<cking> apw, it was a bodge and I'm waiting for the real fix to land - which is going to be somewhat different
<cking> ..as this fix may cause other issues on other machines if I read it correctly
<apw> cking, i wonder if we need a genric mechanism for these
<apw> like ubuntu-bodge-lpNNNN
<apw> which explicitly has to be turned on
<apw> ie deliberatly not letting it be DMI enabled etc, to cover the space before an upstream fix lands
<cking> makes sense - or I write in the bug report "THIS IS A TEST KERNEL AND IS NOT SUPPORTED!!"
<apw> you can write that, and what happens is someone installs it for the VP of something, and then when it gets replace, i get involved via rick
<apw> its a general problem though, that we have no way to put 'crap needed for broken machines' in the tree safely right no
<apw> now
<ppisati> cooloney: still around?
<janimo> smb, ok. I noticed it because I have my @ubuntu.com address the default for gpg and debemail :). I am not sure why only Canonical people should run this script, it makes perfect sense even for local tweaks and rebuilds to keep the packaging cleaner
<smb> janimo, I guess it is valid to ask whether it may be changed to be configurable there. Just as an answer to "do you know why" it is "yes, because" ;)
<janimo> smb, :)
<janimo> probably a config option would make sense
<janimo> if we are to be nitpicky canonical@foo.com also matches currently :)
<smb> janimo, Or probably an environment variable to override the requirement (to avoid having an additional config file)
<janimo> ok, I thought there was a conffile already but if not envvar is better
<smb> janimo, Ok, I did a quick stab at it. Now you can at least override the check (I admit the envvar name is long)
<janimo> smb, nice thanks ! btw can you add me to (janimo/jani.monoses@canonical.com) to the mainstscript.cfg list? The docs said I should add myself but could not push
<smb> janimo, I could but I think this list is more intended as a default with a bit more limitation on the scope
<janimo> smb, ok great than. I thought it was used by some scripts to match commit authors to irc names for some reason
<janimo> maybe to ping  by bot or something
<smb> janimo, Maybe you are even talking about a different config file... Which one was that exactly?
<smb> There is a exmaple-kteam.rc which would go to ~/.kteam.rc but that is solely used to make maint-modify-patch wrork
<janimo> smb, yes, that one
<janimo> ah ok then. no worries :)
<janimo> I had it copied to ~/.maintscripts.cfg based on what I read somewhere (wiki most likely)
<smb> Ah, ok. That is really only to avoid typing email addresses for adding signed-off-by and acked and such. You can easily create your own fitting your needs
<Defusal> the latest cpuset package says "ImportError: No module named cpuset.main" when running "cset", does anyone know how i can fix this?
<cooloney> ppisati: yeah, i'm here, just felt a little bit head ache and took a reset
<Defusal> does anyone know how to make a default group for all system-wide processes (starting with init) that are not part of another cgroup in cgconfig.conf?
<ppisati> cooloney: no prob, i was actually looking for ming, so i wanted to know if you have seen him around on irc
<cooloney> ppisati: np, he is in #hwe channel
<ppisati> cooloney: ack
<cooloney> ppisati: but don't know whether he is online
<ppisati> cooloney: i'll ping him tomorrow then
<ppisati> cooloney: we hit the same mmc card regression on oamp3
<ppisati> cooloney: and i was wondering if he saw a panic during about voltage_scaling
<ppisati> *during boot
<cooloney> ppisati: oh, i saw you mentioned that yesterday. is that related to filesystem or just voltage thing
<ppisati> cooloney: one is about mmc card (sever file system corruption) both of us hit it, we bisected and came down to the same problem
<ppisati> cooloney: but in the mean time, they introduced another regression
<ppisati> cooloney: and it _seems_ (i'm rebuilding openocd to jtag it) to be voltage scaling required
<cooloney> ppisati: oh, what a mess. is that in mainline kernel? unforunately, i don't have omap3 board
<ppisati> cooloney: actually that's something to do with ubuntu config (omap2plus_defconfig doesn't exhibit it)
<ppisati> no prob
<cooloney> ppisati: hmmm. got it.
<ppisati> but i wanted to know if he saw the secont one too since we are working on mailine both for omap3
<tlei> ppisati, ping
<ppisati> tlei: hey
<tlei> ppisati, I am ming, and bryan said you are looking for me
<ppisati> tlei: yep, besides the mmc regression, didn't you hit a kernel hang during boot?
<ppisati> tlei: last kernel message complains about voltage_scaling
<tlei> ppisati, what is log?
<ppisati> tlei: something like this - http://paste.ubuntu.com/1049450/
<ppisati> tlei: to rreproduce it, grab mainline (3.5rcx), use the ubuntu config file, compile and try to boot it
<ppisati> tlei: usually around the second reboot, it hangs (something not de/initialized properly seems)
<tlei> ppetraki, looks no such problem on beagle-xm revB with 3.5-rc2
<ppisati> tlei: are you using ubuntu config file? doesn't show up with omap2plus_defconfig
<tlei> ppisati, oh, I seldom tried 2nd reboot since there is a crash triggered by reboot, and I am a bit lazy to apply one patch to fix it
<ppisati> tlei: i usually reset in that case :)
<tlei> ppetraki, no, I seldom tried ubuntu kernel on beagle-xm, and it is very slow with my low speed mmc card
<ppisati> tlei: ack, no prob
<tlei> tlei, ok, I will try it, but I remembered one reboot crash problem not fixed, so can you reboot successfully without any out-of-tree patch? 
<tlei> tlei, just on beagle, and panda is not affected
<tlei> ppisati,  ok, I will try it, but I remembered one reboot crash problem not fixed, so can you reboot successfully without any out-of-tree patch? 
<ppisati> tlei: nope, when it crashes at reboot i simply reset the aobrd
<tlei> ppisati,  just on beagle, and panda is not affected
<ppisati> tlei: beaglexm yes
<tlei> ppisati, if so, I am sure I have not meet the kernel hang problem with the reset button
<ppisati> tlei: you can easily grab Q/master-next, revert the autocmd12 commit and build
<tlei> ppisati, maybe I need to try ubuntu config, instead of the omap plus config
<ppisati> tlei: first boot ok, from the second one onward, solid hangs during boot
<ppisati> tlei: 100% reproducible
<tlei> ppisati, this line may be a clue:  voltdm_scale: No voltage scale API registered for vdd_mpu_iva
<ppisati> tlei: yep, that's why i thought it's voltage scaling related
<tlei> ppisati, looks I didn't enable voltdm_scale
<ppisati> tlei: in your config?
<tlei> ppisati, I will try to test it tomorrow
<ppisati> tlei: no prob, it's night over there
<tlei> ppisati, yes, I guess
<ppisati> tlei: enjoy the... night? :)
 * ogasawara back in 15
 * ppisati -> gym
 * cking gives up with RTC_IRQP_SET and calls it EOD
<scientes> tjaalton, this bug mainly https://bugs.launchpad.net/ubuntu/+source/linux/+bug/955665 However I am also trying to use the new DRM_UDL driver, but havn't had much success yet
<ubot2> Ubuntu bug 955665 in linux ""udlfb: device_create_bin_file failed -22" boot hang with displaylink graphics" [Medium,Triaged]
<scientes> and i noticed that the mainline builds that are marked "quantal" don't work with precise (networking doesn't come up for example)
<apw> ogasawara, i had forgotten about that rebase bug finder ... heh
<ogasawara> apw: I love it
<apw> ogasawara, it is most surrpising just how many there are
<ogasawara> apw: it did seem we had more than usual
 * apw wanders out to do some errands, have fun
<scientes> any previews of the signed uefi secure-boot kernels?
<scientes> and any writeup on what features they don't have?
<scientes> i didn't think you guys had any way to sign modules
<adam_g> other than changelog and the specific bug reports they resolve, where do ubuntu specific patches / sauce get tracked?
<ogasawara> adam_g: If you want a current view, you'd want to look at the git tree.  All Ubuntu specific patches are prefixed with "UBUNTU:" and the sauce patches are prefixed with "UBUNTU: SAUCE:".  We also have a slightly dated view in our delta review spec.  eg.  https://wiki.ubuntu.com/KernelTeam/Specs/QKernelDeltaReview.
<adam_g> ogasawara: thanks
<scientes> somwhere i can track a 3.4 mainline?
<infinity> ogasawara: Oh, your kernels should be getting published in quantal around nowish, BTW.  Sorry for the delay.  Headless chickening.
<scientes> (for precise) the mainline builds seem like they are only against quantal
<scientes> and i tried one and it broke my precise system
<infinity> scientes: quantal kernels probably shouldn't break precise systems... Define "broke"?
<scientes> infinity, no networking, no usb
<scientes> graphics works fine
<scientes> with the 3.4.3 quantal, the 3.4.0-precise works fine
<infinity> Curious.
<infinity> I really can't think of why that would be.
<infinity> Except potentially 3.4.3 just hating you.
<scientes> ant the lts 3.5 backport works with networking and usb
<scientes> although it doesn't work with my touchscreen, but that is likely upstream thing
<jwi> scientes: you installed the -extra package?
<scientes> no
<infinity> Or used the metapackage...
<scientes> just the raw linux-image-fooo-amd.deb
<infinity> Ahh.
<infinity> That would be why.
<infinity> A bunch of modules were broken out.  The metapackage handles that for you.
<scientes> ahhhhhhhhhh
<scientes> ahh i need the -extra i see
<scientes> should have checked that
<scientes> i couldn't find the ppa to do these automatically: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.3-quantal/
<ogasawara> scientes: did you install both the quantal linux-image and linux-image-extra's packages?  You need both.
<scientes> yes i did
<scientes> (now)
<ogasawara> infinity: thanks!  /me leaves for vacation
#ubuntu-kernel 2012-06-21
<smb> morning
<jk-> hey smb
<smb> morning, err, evening jk-
<cooloney> smb and jk- morning
<cooloney> oh, for jk-, should be good afternoon
<jk-> heya coololololoney
<smb> cooloney, actually for you, too :)
<ppisati> moin
<cooloney> ppisati: morning
<ppisati> cooloney: hi Bryan
<apw> TheMuso, about?  i am looking at simplifying lowlatency for Q 
<smb> morning apw
<apw> smb, moin
<ming> ppisati, follows my log on voltage scale
<ming> ppisati, [    6.078063] omap2_set_init_voltage: unable to set vdd_mpu_iva
<ming> [    6.090911] ThumbEE CPU extension supported.
<ming> [    6.095428] Registering SWP/SWPB emulation handler
<ming> ppisati, but kernel can boot successfully
<ppisati> ming: hangs on boot?
<ming> ppisati, no hangs
<ppisati> ming: .config? 3.5rc3?
<janimo> apw, why does the linux-image package provide both   linux-im linux-image and  linux-image-3.0? Same for headers, plain and -3.0.
<ming> rc2
<ppisati> ming: ah, it happens at the second boot btw
<ming> ppetraki, rc2, I checked the code and looks no special options need to be enabled
<janimo> apw, I am looking to sync up the armadaxp packaging bits with changes in ubuntu's main package
<ppisati> ming: first one works ok
<janimo> apw, now with the splitting of extra that causes build failure it's a good opportunity to reduce other deltas too
<apw> janimo, hmmm i think those are for things like user-mode-linux arn't they
<janimo> apw, no idea really. I was wondering if they were workaround from the time of the 2.6.x->3.0 name change which may have confused some tools? No ide
<janimo> a
<ppisati> ming: ok, i just checked, it's plain master-next from quantal
<ppisati> ming: you compile it, install on the board
<ppisati> ming: fist boot is ok (i even let it run for a night installing stuff on the mcc card)
<ppisati> ming: reboot
<ppisati> ming: (press reset since it panics on shutdown :) )
<ppisati> ming: and during the second boot it will hang there
<ming> ppisati, no such problem, I am sure
<ming> ppisati, could you send your .config to me?
<ppisati> ming: do you have access to tangerine?
<janimo> smb, apw, did the splitting out of -extra happen only for 3.5? Is there some doc/ml thread discussing it? I want to make sure I get all the implications to packaging and not just copy over bits from debian.master
<janimo> is debian.master/control.d/generic.inclusion-list related to the splitting?
<ming> ppisati, if you can, I think it will be a bit quicker, tangerine is very slow from access in China
<ppisati> ming: i'll send you an email with .config attached
<ming> ppisati, thank you
<smb> janimo, There was a splitting for the virtual package only in precise... not sure it went back into Oneiric too...
<janimo> smb, I thought it was quantal. Hmm I wonder why I only saw build issues now. Maybe they're unrelated then
<smb> Since virtual now is not its own flavour the split went into generic and the meta-packages pull in the correct bundle
<smb> janimo, You would only notice with quantal as its only since then for basically the "normal" kernel
<janimo> ah ok
<janimo> and in quantal only 3.5? I did not have this issue when rebasing on 3.4
<smb> no, that should have been that way before rebasing to 3.5
<apw> janimo, you don't need to follow it, just don't have a includes file for it
<apw> janimo, it just lets us share the -generic with -virtual but having a slim option
<janimo> apw, find: `debian/crypto-modules-3.5.0-1601-armadaxp-di': No such file or directory this is what I got and thought maybe it's related to some splitting off
<janimo> but if not I'll just chalk it off to me and kernel packaging not getting along and will debug further
<ppisati> ming: .config is exactly what i get form master-next, so no need to attache anything
<ppisati> ming: i sent you an email with the exact steps to reproduce it
<ppisati> ming: i've another beagle xm here, let me try with that in the mean time
<ming> ppisati, not got your email, :-(
<ppisati> ming: not yet maybe, don't loose your faith! :)
<ming> ppisati, ok, :-)
 * ppisati -> grabs more coffee
<ming> ppisati, could you send the .config to me so that I can test it quickly. otherwise I need much extra time to do it
<ppisati> ming: ack, wait
<ming> ppisati, OK
<ppisati> ming: sent
<ming> ppisati, thanks, :-)
<janimo> apw, when does d-i/exclude-modules needs changing? I had to add crypto there now to get the build going (that was the error). But it is unclear what caused the change from 3.4 to 3.5 or why those modules should be blacklisted instead of some bugs fixed to have them working
<apw> janimo, more likley they are now built in
<janimo> apw, indeed I see CONFIG_CRYPTO=y but it's the same in debian.master/ too and the main kernel package does not have crypto-modules in the exclusion list
<apw> janimo, well what module is missing?  i assume crypto-modules lists a bunch of things, its onnly when it becomes completely empty it needs adding i believe
<apw> janimo, i assume highbank has something else builtin which we don't rendering the udeb empty
<janimo> apw, hmm, do I need to look higher in the logs. I only saw the kernel-wedge error
<janimo> this is armadaxp, not sure how highbank configs should be different if at all
<apw> janimo, i used the wrong name, amardsxp is the one
<apw> janimo, i would download the corresponding .udeb for quantal and see what is in it, and see what your config for that is
<ppisati> ming: ok, i can reproduce it 100% on beagle xm rev a and rev c
<ming> ppisati, good, I think you can submit it on omap or arm mailist
<ppisati> ming: actually i would like someone else to confirm it first
<ming> ppisati, no problem, I will confirm it once I can reproduce it on my xm RevB
<ppisati> ming: ack
<ppisati> ming: btw, i've some brand new sd cards, let me try that too
<akssps011> I am trying to compile kernel from kernel.org on ubuntu 12.04. I followed these steps, 
<akssps011> 1) make menuconfig
<akssps011> 2) make
<akssps011> 3) make modules 4) make modules_install 5) make bzImage 6) mkinitramfs -k -o /tmp/initramfs- and copied initramfs from /tmp to /boot/initrd.img
<akssps011> 7) added the menu entry to grub. But when I boot into the kernel I get the errors. error: Not a regular file error: You need to load the kernel first in the grub
<akssps011> Where I may have gone wrong
<akssps011> ?
 * ppisati -> out for lunch
 * apw drops to shift location ... back in a bit
<janimo> ikepanhc, ppisati are some config options turned off in 3.5 for ARM because they can cause lockups on boot? My armadaxp rebased on 3.5 locks up and want to see if I should disable something
<ikepanhc> janimo: yes, I saw lots of config being temporarily disabled
<janimo> ikepanhc, I rebased on 3.5 Ubuntu though so was expecting to have the same configs too
<janimo> hmmm maybe should have synced with flavour configas
<ppisati> janimo: there are at least 3 different problems on omap3 ATM
<ppisati> janimo: one is about mmc (but it's omap4 specific)
<ppisati> janimo: then i'm experiencing a hang during boot
<ppisati> janimo: something like this - http://paste.ubuntu.com/1049450/
<janimo> ppisati, hang during boot regardless of setting?
<ppisati> janimo: and then we've a panic during the shutdown
<ppisati> janimo: what you mean by settings? cmdline?
<ppisati> janimo: do you get a trace or it just hangs with no output?
<janimo>      ppisati I mean config options. I get a hang after detecting SDA
<janimo> with a plain build of uImage (not deb) it got a bit further so I thought it may be some config thing
<janimo> need to look some more
<ppisati> brb
<ogra_> ppisati, where do we stand wrt a new omap4 code drop ? will it make A2 (next thu)
 * ogra_ would like ot have a working display again
<ppisati> ogra_: i was thinking about that
<ppisati> ogra_: in master-next we have 3.5rc3, so i can probably rebase on that
<ogra_> yeah, i think 3.5 was what ndec also said they worked on already 
<ppisati> i see agreen has tilt-traccking on 3.5
<ogra_> yep
<ppisati> but ndec told me they won't support it
<ppisati> anywhow
<ppisati> i'll give it a shot tonight/tomorrow
<ogra_> hmm, didnt he say they had some new commits that fix video on 3.5 ?
<ogra_> cool, thanks !
<ppisati> did they? (video fix in 3.5)
<ogra_> i though that was what he said when we recently talked to him in #ubuntu-arm 
<ppisati> he said there were some new commits in tilt-tracking
<ppisati> don't remember anything video specific tough
<ppisati> though
<ogra_> well, we can ask him tomorrow i guess
<ppisati> ack
<ppisati> anyway i'll trya rebase in a few hours
<ppisati> if it works i can hand you a kernel for testing
<ogra_> great, thanks a lot 
<ogra_> yep
<smb> bah herton stand in between me and my final test kernel completing compile... ;-P
<herton> smb, stable upstream likes to do new releases every day now it seems :P
<smb> herton, Always "those". :) 
 * rtg -> EOD
<TheMuso> apw: I'm around now.
#ubuntu-kernel 2012-06-22
<toocool>   I need some help compiling and packaging a custom kernel flavour for an i386 target ona amd64 host 
<toocool> i have 3.2.0 source via git for precise 12.04, but debian/rules is not aware of i386 binary target
<toocool> i was able to compile and package a custom flavour kernel based on generic on the i386 machine but can not duplicate it on my amd64 laptop
<toocool> is there something simple i'm missing- to target a 32bit target on a 64bit system? i was hoping to do so would be quicker
<BenC> toocool: make a 32-bit chroot environment with deboostrap
<BenC> There's another way using dpkg-cross or something, but I'm not familiar with that route
<toocool> thank you, i'll start reading
<ppisati> moin
<smb> morning
<apw> moin
<brendand> cking, what to do about this one? http://paste.ubuntu.com/1053912/
<cking> I believe fwts also generates some advice with this, which points me to the specification - do you keep that info, if not  I will look it up by hand
<cking> brendand, I'll look it up in section 7.21 of the spec, bear with me
<brendand> cking, we have the full log. i can pastebinit to you
<brendand> cking, http://paste.ubuntu.com/1053916/
<brendand> yes, i should have done that in the first place ;)
<cking> no worries
<cking> brendand, so I doubt it will screw anything up, but it is definitely not matching the specification. the value 0 is reserved, so should not be used, I expect values like 1 or 2 in this field, or 0xff if unknown.
<brendand> cking, i'll raise a bug against ubuntu and subscribe you and the project managers as vanhoof requested
<cking> brendand, I will put in my notes to the bug and we should forward it to the BIOS vendor if they can be bothered to fix it
<cking> which I doubt
<brendand> cking, so this is an enabled system. don't we have bios engineers?
<cking> brendand, sorry, I don't understand your question
<brendand> cking, neither do i, to some extent :/
<cking> brendand, we can't fix this issue, it's up to the BIOS vendor to fix it
<brendand> cking, right
<cking> but I doubt they will do since it's not breaking anything and it's costly to fix it. however, we can tell them not to do this again in next releases
<brendand> cking, of course. 
<brendand> cking, https://bugs.launchpad.net/ubuntu/+bug/1016436
<ubot2> Ubuntu bug 1016436 in ubuntu "[Lenovo E325] DMIIllegalMappedAddrRange error when running FWTS" [Undecided,New]
<cking> brendand, thanks, I've updated the bug report, upto somebody else to figure out what to do with it though :-/
<brendand> something of a critical issue we've found here in quantal: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1016444
<ubot2> Ubuntu bug 1016444 in linux "Broadcom NetXtreme II detect network hardware fails due to can't find bnx2 firmware" [Undecided,New]
 * ppisati -> lunch
<apw> cking, ok i may have some quantal lowlatency kernels if you are interested in them, no idea if they work of course :)
<cking> apw, I'd like to give them a spin
<apw> arges, it was you who had some idea why we might care about lowlatency and have a usecase for it right?
<arges> apw, yea i can help test
<apw> ok they are just uploading now, will point you at 'em when they are done
<cking> ta
<arges> apw, i'll also try to get some numbers 
<arges> apw, in terms of how it affects audio recording (since that's a big usecase for me)
<apw> rtg, i think i've put together a lowlatency branch using a new 'just override these configs' approach
<apw> so it should be a straight rebase with no tweaking
<cking> arges, so how do you propose to get some figures for that?
<rtg> apw, is it _just_ config changes ?
<apw> rtg, right now the branch still has your patch, though that could become config changes.  the point was that there is no manual handling of the configs for the branch so maintenance of it is simplified massivly
<apw> and if it works well for quantal it would likely make sense for P too
<apw> as right now one has to handle the config delta and all changes in the config, by hand, nnng
<apw> http://people.canonical.com/~apw/lowlatency-quantal/ <-- cking, arges 
<arges> downloading
<arges> apw, whats the appropriate patch format if. An original ubuntu patch was modified by another author, and wants to contribute it back? Should From: be changed, and just credit the original patch? 
<rtg> arges add a second patch that modifies code touched by the first ?
<cking> apw, it boots
<BenC> rtg: Any chance of some feedback on the newer patch set I sent to kernel-team@?
<rtg> BenC, yep, though the answer hasn't changed. I'll send it out on the list.
<BenC> rtg: That set doesn't change any relevant code though
<BenC> rtg: And you do realize it's difficult to maintain a community driven port when the community has such a hard time getting support from the kernel-team...
<BenC> I've put in over 100 hours of work getting failed builds down to a reasonable level on powerpc (and 25%+ of that helped arm by extension) over the past few weeks
<rtg> BenC, look, its not my call. Rick said no, so you're gonna have to convince someone higher then my pay grade.
<BenC> So how about ya throw me a bone here...
<BenC> Rick who?
<rtg> Rick Spencer, our director of engineering. 
<apw> BenC, why is it hard to maintain a derivative kernel, we have many of them
<BenC> And it would be nice if the person actually making the call was the one responding to my emails on the list
<BenC> apw: derivatives go into universe
<BenC> universe == no installer
<apw> the destination of a derivative kernel is not fixed is it?  lowlatency goes into main as it is the default kerenl for the ubuntu-studio CD ?
<BenC> I don't think soâ¦ubuntu-studio is a derivative of ubuntu, so it can pull in different components
<BenC> I don't want to have to start going through MIRs just to get this thing going either
<BenC> The new flavor isn't anything but another configuration, and one arguably more usable than powerpc-smp being currently built
<BenC> rtg: And for the record, and I know it's not you at all, but Canonical has been extremely slow getting us any response on our OEM partnership paperwork we sent in several weeks ago
<BenC> We put in our partnership requests with Redhat and Suse well after we started the process with Canonical, and we already have logo rights back to us and developer channels open with them, in less time
<BenC> So you can imagine my frustration at how difficult this process is with the dist/company that I have such an affinity for :)
<apw> cking, can you tell what hz is from the running kernel there?
<rtg> BenC, well, this isn't the right channel. I guess you need to keep talking to vanhoof, but I know he's on vacation this week.
<apw> BenC, i have not found kernel MIRs particularly onerous, as a kernel is a known shape, and we know where CVE fixes are coming from
<apw> though i assuem you want installer bit bacause you want CDs built, and those tend to be a problem due to space
<cking> apw, apart from the following, I'm not sure how to figure that out easily. grep CONFIG_HZ= /boot/config-`uname -r`
<cking> CONFIG_HZ=1000
<apw> cking, well thats something at least :)  does PREEMPT appear in uname -a
<apw> cking, next to SMP, have the feeling its exposed in the same place
<cking> grep PREEMPT= /boot/config-`uname -r`
<cking> CONFIG_PREEMPT=y
<arges> apw, getting some numbers for comparison with the generic-amd64 kernel frist btw
<cking> arges, how are you instrumenting that?
<arges> cking, i knew you'd ask : )
<arges> cking, basically just using qjackctl to set the latency lower and checking for xruns
<arges> its not as scientific as i'd like it
<BenC> apw: Do you really want security guys to have to worry about another package that needs to get built for kernel CVEs and processing those ABIs and relevant meta packages?
 * cking using cyclictest and other tests
<BenC> Sounds like way more work than just adding the config/meta to the existing packages
<arges> cking,  can you point me at that
<cking> arges, http://people.redhat.com/williams/latency-howto/rt-latency-howto.txt
<cking> but I need to faff around and see if it's useful or not
<BenC> rtg: I know you say Rick said not to do it, but I tend to think you didn't do much to try to convince him, but most likely just wanted his confirmation of your decision :)
<BenC> Anyways, I'm out of San Antonio heading back home from the Freescale conference where Canonical actually has a booth, so again, my confusion when we can't get a Freescale product line supported...
<rtg> BenC, I did my homework with the biz-dev types. I'm not gonna commit to a another flavour until I'm sure its gonna stick, so keep talking to them.
<cking> arges, http://elinux.org/Realtime_Testing_Best_Practices
<cking> arges, and audio related: http://www.gardena.net/benno/linux/audio/
<cking> arges, http://www.alsa-project.org/~iwai/suselabs2003-audio-latency.pdf
<cking> arges, can you write up how you are measuring the audio on your machine?
<arges> cking, yes doing that now
<arges> rtg, apw : pad.lv/669641
<apw> [email@bar: desctription]       
<ming_lei> ppetraki, I have seen the boot hang just one time
<ming_lei> ppetraki, looks it is very difficult to reproduce it on my board
<ming_lei> ppisati,  I have seen the boot hang just one time
<ming_lei> ppisati, looks it is very difficult to reproduce it on my board
<ppisati> ming_lei: cool
<ppisati> ming_lei: so, with a brand new card i don't see it at all
<ppisati> ming_lei: so fat
<ppisati> far
<ppisati> ming_lei: but it has been just one day that i'm trying with it
<ppisati> ming_lei: now there's a problem with video output
<ppisati> ming_lei: so i won't test it anymore
<ppisati> ming_lei: i'll have to fix video first
<ming_lei> ppisati, I mean the problem of 'omap2_set_init_voltage: unable to set vdd_mpu_iva'
<ppisati> ming_lei: yes, i understood what you mean
<ppisati> ming_lei: but at least you reproduced it one time
<ming_lei> ppisati, yes, just one time
 * ppisati -> reboot
<diwic> if the same patch solves more than one bug, will it work to have two "BugLink:" lines in the patch header?
<bjf> diwic, yes
<diwic> bjf, thanks
<rtg> diwic, is one a dupe of the other ?
<diwic> rtg, not really. I was thinking of adding three similar quirks (for three different machines) in the same patch for efficiency.
<bjf> diwic, as long as all three bugs have the sru text, i think you are fine with a single commit that fixes them all
<diwic> bjf, ok. These will all go through upstream, so they won't need any SRU text.
<diwic> probably they will hit quantal and not precise
<bjf> diwic, ah!, that's cool
<diwic> still good to have them autoclosed though :-)
<bjf> diwic, yup
<bjf> rtg, http://pastebin.ubuntu.com/1054497/
<bjf> rtg, it's working just fine
<rtg> bjf, that looks better.
<cking> arges, I'll get back to you on tools to try - I'm experimenting with a bunch of broken old of date tools that seem to not be very useful at the moment :-/
<arges> cking, ok thanks
 * cking --> EOD
<cking> ...and mutters to himself about broken tools..
 * ppisati ->EOD
<bjf> cnd, how do you simulate a middle mouse click on the MB?
 * rtg calls it a week.
<cnd> bjf, you don't
<bjf> cnd, oh
<cnd> you can manually configure it to be a three-touch tap if you want
<cnd> but it's limited
<cnd> the reason is that the unity multitouch gesture spec conflicts with three-touch tap
<cnd> so the default is to not provide middle button emulation
<cnd> I'm trying to find the bug about this
<cnd> it has some info on how to enable it manually
<cnd> but it doesn't to stick after suspend/resume or reboot
<cnd> bjf, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/754000/comments/64
<ubot2> Ubuntu bug 754000 in xserver-xorg-input-synaptics "Running Unity disables Xorg's 3-finger click support (middle click)" [Low,Won't fix]
<bjf> reading
<cnd> bjf, note that if you enable middle click emulation, you lose the three-touch gestures in unity
<cnd> which may not be a big deal to you :)
<bjf> cnd, ack thanks for the explaination
<cnd> it's just an unfortunately reality of X being architected as it is
<infinity> Don't we map some keyboard shortcuts to right and middle by default on Macs?
<cnd> maybe the option key for right click?
<cnd> I would be surprised for middle click, but I could be wrong
<infinity> F11 and F12 or something?  I dunno.  I buy hardware with mouse buttons.
<infinity> Ubuntu bug 754000 in xserver-xorg-input-synaptics "My MacBook isn't a ThinkPad" [Low,Won't fix]
<ubot2> Ubuntu bug 754000 in xserver-xorg-input-synaptics "Running Unity disables Xorg's 3-finger click support (middle click)" [Low,Won't fix] https://launchpad.net/bugs/754000
<infinity> ubot2: Shut it.
<ubot2> Factoid 'Shut it.' not found
<genii-around> Hello.. Perhaps someone may know offhand.. if there is some known bug with 3.4,3.5 64 bit kernels and Atom N450. I get odd messages like bad rss-counter state
#ubuntu-kernel 2012-06-23
<bryceh> there's a mapping of EISA hex codes to companies in drivers/eisa/eisa.ids
<bryceh> is that file exposed any where, or a tool or call available to look up the company name given an id?
<mjg59> bryceh: I really really hope you mean pnp ids rather than eisa ids
<mjg59> bryceh: EISA devices went out in the mid 90s
<mjg59> If you do mean PNP then pnputils and lspnp
<bryceh> mjg59, this is for EDID, which wikipedia says uses EISA ID's
<mjg59> bryceh: The IDs in eisa.ids are only for the ancient EISA hardware, not anything else that uses the same format
<mjg59> bryceh: Microsoft maintain the PNP ID registery which is probably the right namespace
<Yankees52> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<Yankees52> !staff
<ubot2> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :)
<Yankees52> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<Yankees52> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<Yankees52> !staff
<ubot2> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, dax, stew, or tomaw, I could use a bit of your time :)
<Yankees52> ban!
<Yankees52> i will stay on freednode all night until tomorrow until i am banned
<Yankees52> yay
<Yankees52> ban ban ban ban
<Yankees52> come on boy!
<bryceh> mjg59, aha, many thanks, I'll do some further investigation
#ubuntu-kernel 2012-06-24
<chronos> I own one dual 3.5" bay with raid (http://www.welland.com.tw/html/2bay/580j.html) that uses chipset JMB352 (which should support linux). I'm running ubuntu 12.04 in two machines and one of than recognize one of two hard disks, other any.  Someone maybe already seen this model  or chipset or know a way to go on, cuz I'm little lost.
<nickoe___> hi
<nickoe___> Â´Can I obtain a ubuntu without pae?`
<Eimann> yes, use the non-pae kernel
<nickoe___> Eimann: where to fin the image with that?
<Eimann> http://askubuntu.com/a/117751
<Eimann> workaround 3
<cnd> sforshee: I've got a new macbook air, but I'm finding the instructions on how to install ubuntu confusing
<cnd> I thought we didn't have to do anything special anymore, and efi support was built-in by default
<cnd> but the installation guide here is a bunch of stuff I don't really want to do: https://help.ubuntu.com/community/MacBookAir4-2
<cnd> what do you do?
<thomi> Hi, I'm getting a kernel panic while runnign the precise live CD - anyone have any ideas why that might be? is there anything I can do to get more useful information? The stack looks like this: http://static.inky.ws/image/2227/image.jpg
<thomi> seems similar to this: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/923217
<ubot2> Ubuntu bug 923217 in casper "[Oneiric] Kernel Panic doing PXE/NFS boot" [Undecided,New]
<mjg59> thomi: /looks/ like init exited
<mjg59> I don't think that's a kernel bug
<thomi> oh?
<thomi> hmmm, Any idea how I can debug that?
<mjg59> I haven't looked at the Ubuntu live init for way too long, I'm afraid
#ubuntu-kernel 2013-06-17
 * smb yawns
<ppisati> reboot
 * apw waves
<smb> apw, We were speaking of you but mumble decided you need not to know. :-P
<smb> henrix, Do you have an estimate how soon or late the 3.5.7.14 stable release may make it into Quantal?
<henrix> smb: i believe a new SRU cycle is starting this week
<henrix> smb: so, it should be in Q in 3 weeks
<smb> henrix, Ah, ok. Thanks.
<henrix> smb: (i may be wrong about the SRU cycle... its better to confirm that with bjf or sconklin)
<smb> henrix, Yeah, though it sounds correct as there were a whole lot of activity on tracking bugs. Of course there was also some emergency override, too
<henrix> smb: i just checked some IRC logs, and the cycle is starting today
<smb> ok
<henrix> smb: so, 3.5.7.14 should be in -proposed later this week, and in -updates in 3 weeks
<smb> henrix, That is enough of an estimate for my purpose (just need to relate that in a bug report)
<henrix> smb: cool, so i was able to provide useful information on a monday morning :)
<smb> henrix, :D
 * ppisati -> out for lunch
<rtg_> apw, https://launchpadlibrarian.net/142644121/buildlog_ubuntu-saucy-i386.linux_3.10.0-0.5_FAILEDTOBUILD.txt.gz is a weird failure
<ogra_> rtg_, your latest change to mako made the zImage quite big .... doesnt fit into the 8M boot.img anymore (together with the 2.1M initrd)
<rtg_> ogra_, drat
<ogra_> i bumped the boot.img size ...  but we should probably take a llook if we can make it lose weight again
<rtg_> ogra_, so the zImage has to be <= 8M ?
<rtg_> or is it the combination ?
<ogra_> no, zImage + initrd has to be <= the partition size for the boot.img  ... 
<ogra_> the mako has a slightly bigger partition ... so we can bump it ... but that means special casing per arch now
<rtg_> ogra_, what is the last version that was small enough ? I don't see any major changes to the configs other then CONFIG_ECRYPT_FS=m
<ogra_> if it is possible it would be good to stay inside the 8M and not have to special case it ... but if it isnt i guess we have to live with that
<ogra_> (it doesnt break anything, its just an observation i made and had to react on ... )
<rtg_> ogra_, well, it looks like its your choice, e.g., make mako a special case and have ecryptfs, or no special case and no ecryptfs.
<ogra_> the image of the 15th had no issues ... sadly the builder broke over the weekend so i cant really tell when it  grew beyond the 8M ...
<ogra_> ok
<rtg_> its likely the ecryptfs change. I seem to remember apw having problems with that
<ogra_> do all the other arches have ecryptfs support already ?
<ogra_> maguro cant grow above 8M
<rtg_> ogra_, yes IIRC
<ogra_> ok, then we should eb good ... 
<ogra_> *be
<ogra_> i can live with the special casing if needed
<rtg_> ogra_, maguro _has_ ecryptfs enabled as a module
<ogra_> just for grouper and maguro we are bound to the 8M
<rtg_> ogra_, ok, so shall I leave mako as it is then ?
<ogra_> yeah, its fine 
<rtg_> ack
<ogra_> i'm not sure modules help us much btw 
<ogra_> we dont install kernel packages in the image 
<rtg_> ogra_, so we shouldn't have _any_ modules ?
<ogra_> well, either that or we find a way to deploy modules from outside the image somehow
<ogra_> i dont think there is ant planning for that yet
<rtg_> ogra_, what goes into the initrd ? aren't some modules picked up during the formation of the initrd ?
<ogra_> *any
<ogra_> no, the initrd is fully generic 
<ogra_> MODULES=list ... without a list
<rtg_> so ecryptfs is useless as a module ?
<ogra_> (i.e. MODULES=none ... faked)
<ogra_> we will have a redonly system root, ecryptfs would be used for homedir/data decryption 
<ogra_> so we dont need it in the initrd 
<rtg_> which means it must be built-in
<ogra_> but we have no plan for getting the module into the rootfs either atm
<ogra_> no, it could stay modular, but we would need a way to deploy it 
<ogra_> and that must be reproducable by the porters 
<ogra_> (keeping a module needs planning we dont have in place, not having the module will probably make grouper and maguro explode)
<rtg_> ogra_, so really you're just thinking out loud ?
<ogra_> well, loud enough to get some input from you :)
<ogra_> i wasnty aware its modular in the other kernels ... 
<rtg_> ogra_, I'm easy either way. its a simple config switch
<ogra_> might be helpful to have some size comparison data 
<ogra_> the initrd is 2.1M currently 
<rtg_> ogra_, if you have MODULES=none then why would the initrd size ever change ? 
<ogra_> it wouldnt ... but if the kernel grows to 6M it will break 
<ogra_> with ecryptfs support builtin
<rtg_> that makes 6M the effective limit for zImage, right ?
<ogra_> so knowing how the binary size of zImage differes with it would be good i think
<ogra_> well, 5.9 ... but yeah
<rtg_> ok, I can figure that out
<larsduesing> Hi
<larsduesing> I've got some troubles building a current git-kernel via make-kpkg
<larsduesing> However, I thought the version is 3.10.0-rc5
<larsduesing> is what make-kpkg says to me
<larsduesing> "The changelog says we are creating 3.10.0-rc5+
<larsduesing> very strange
<apw> larsduesing, that implies there are commits after the actual commit changing the version number, doesn't it ?
<apw> rtg_, i rebased unstable and uploaded it to the pre-proposed ppa
<rtg_> apw, saw that
<larsduesing> apu - there is a patch applied, yes.
<apw> larsduesing, then the version should be + to tell you that indeed
<joshhunt> sconklin, around?
<sconklin> joshhunt: yes
<joshhunt> sconklin, hey i was in the process of pulling in the latest USN for 3.2 and noticed the diff/patch seems to be much smaller for the new USN which seems odd to me. https://launchpad.net/ubuntu/+source/linux/3.2.0-44.69 vs https://launchpad.net/ubuntu/+source/linux/3.2.0-48.74
<joshhunt> i'm referring to the linux...diff.gz files
<sconklin> looking
<joshhunt> when i diff their contents i notice that a lot of patches which were in the previous patch have been removed. this seems suspicious to me.
<joshhunt> for ex: it looks like all patches to linux-3.2.0/fs/dcache.c are removed in the new USN, which seemed a little odd.
<jdstrand> ogasawara: hi! did I set bug #1191197 correctly?
<ubot2> Launchpad bug 1191197 in linux-nexus7 (Ubuntu) "kernel config does not support ufw firewall" [Undecided,New] https://launchpad.net/bugs/1191197
<sconklin> josepht: the git tree all looks ok, I suspect a packaging error, looking at that
<rtg_> jdstrand, its more likely going to be an issue of size. ogra tells me that we're already over the 8M limit for the boot image
<rtg_> though we should be able to enable these as modules
<jdstrand> rtg_: and we aren't going to have modules either?
<jdstrand> modules is fine
<rtg_> jdstrand, thats the part I'm finding a bit confusing. ogra says we are not using packages for the kernel, so I'm not sure if modules are used. guess I'd better find out.
<jdstrand> not having modules and having a very small kernel is fairly limiting
<ogra_> we are using packages during the android build ... but not in the ubuntu rootfs
<rtg_> ogra_, which means nothing to me. will modules get loaded when user space requests ? like udev ?
<ogra_> no
<ogra_> and udev wont handle hardware at all 
<rtg_> well then, why have _any_ modules ?
<ogra_> the android container will, udev startup is held back until ueventd in android is done
<ogra_> some are needed by the android side
<ogra_> not sure how we do that, sergiusens or rsalveti could elaborate 
<ogra_> all hardware related bits need to happen in the container
<ogra_> udev is only used for permissions of devices on the ubuntu side or if needed to set up symlinks
<apw> ogra_, is this in adroid outside/ubuntu inside ... or ubuntu outside/android inside ?
<ogra_> this is in the flipped container ... android under lxc 
<apw>  and we have no udev for module loading
<ogra_> (teh future image we will use hopefully from next week on by default)
<ogra_> we hold back udev
<ogra_> the modules need to be loaded from the container 
<rsalveti> well, we don't have any solution for the kernel packages yet
<rsalveti> we thought about installing the package during first boot/installer
<ogra_> rsalveti, how do we get the modules in place atm ? 
<rsalveti> but we can't necessarily do that anymore once we have ro rootfs
<ogra_> on the android side
<rsalveti> ogra_: I think we're copying them over
<ogra_> k
 * apw is slightly confused as to why modules need to be inside at all
<ogra_> what we can surely do is set up a link from /lib7modules to /vendor/lib/
<ogra_> apw, inside what now ?
<ogra_> :)
<apw> inside the android lxc
<ogra_> because thats what ships the binary blobs used in the modules
<ogra_> and it ships the setup (wpa_supplicant config for example=
<ogra_> )
<ogra_> the ubuntu side only talks to the hardware through platform-api
<jdstrand> ogra_: would that link fix loading via requests from userspace??
<ogra_> (and through some /dev entries we have on both sides and sockets)
<ogra_> jdstrand, well, we will have to teach udev to never load anything, it would just make the modules visible
<ogra_> (no idea for what though)
<ogra_> ubuntus udev should only set up device permissions and possible links to make the android device names recognized by a linux system
<rtg_> jdstrand, if there is a /lib/modules/`uname -a`, then ufw->iptables ought to do the right thing.
<jdstrand> ogra_: well, I'm talking about if I use iptables to add a rule, and it needs to have a module loaded. on the desktop, this happens without any help. if we enable these things as modules, will I need to load them manually or will they autoload?
<ogra_> nothing should autload
<ogra_> and they should be loaded from android 
<ogra_> (which doesnt know modprobe)
<jdstrand> I see
<jdstrand> ogra_: do we have an /etc/modules that we can populate?
<ogra_> we dont really have any plan for that yet :)
<rtg_> but iptables _does_ know how to insmod
<ogra_> probably worth a meeting
<apw> ogra_, why does it matter which side of the line (ubuntu/android) that the modules live ?
<ogra_> apw, races ... 
<apw> ogra_, the kernel is there to moderate races surely
<apw> (for things like iptables)
<ogra_> we have two concurring HW managers running
<ogra_> and ueventd needs to be the master so we get the android configs 
<ogra_> for iptables (if that works at all with the android networking stack) we might be able to make an exception but would need the link 
<jdstrand> I can say that iptables works with JENKINS_BUILD=saucy-11 on mako (unflipped)
<ogra_> ok, that answers the android network bit :)
<ogra_> the whoile container flip thing had not had *any* planning so we mostly plan and design on the go 
<jdstrand> it does for a lot of things actually, there are just a few kernel configs that we need for ufw to be happy (see aforementioned bug)
<ogra_> the iptables requirement didnt come up yet
<rtg_> jdstrand, I'm working on it
<jdstrand> rtg_: cool, thanks
<apw> rtg_, if you are about to do a mako i have a patch i want on it
<rtg_> apw, ack
<rsalveti> ogra_: I'll check if we're copying the modules over, as that would probably be the way to go anyway
<jdstrand> rtg_: did I use all the right kernels in that bug?
<rsalveti> ogra_: as the image will be ro, the only way to updated would be via the update image process
<jdstrand> I picked linux-nexus4 and linux-nexus7
<rsalveti> which would flash both the android and ubuntu side
<rtg_> jdstrand, I'm changing the names to linux-mako and linux-grouper
<rsalveti> and during that flash, we can bring the new kernel and modules
<ogra_> rsalveti, well, we wont have apt/dpkg anyway
<rsalveti> right
<ogra_> so flashing is the only option
<jdstrand> rtg_: ok, thanks, noted for the future. I imagine the nexus 10 has the same issue
<rsalveti> ok, I'll check if the copying is indeed happing
<ogra_> its just that we need to plan that wrt flip 
<rtg_> jdstrand, N10 -> manta
<ogra_> since i have no idea how to handle that on the ubuntu side yet 
 * ogra_ will ponder about that a bit 
<lamont> it seems that one cannot configure a ifenslaved bond interface as part of a bridge... is this expected?
<joshhunt> sconklin: did you find a problem with the packaging?
<rtg_> lamont, arges is the expert on that IIRC
<lamont> good to know
<sconklin> still looking, and I asked infinity to have a look'
<joshhunt> sconklin: thx
<arges> lamont: how are you setting this up? and are you seeing dropped packets?
<rtg_> apw, did you notice that saucy unstable no longer builds for armhf ?
<lamont> arges: I am seeing no packets
<lamont> as for capturing the config, that'll take me a bit, since well, no internet
<lamont> er, network
<arges> lamont: let me see if its similar to a bug i'm looking at
<arges> lamont: pad.lv/736226
<lamont> arges: eth0 and eth1 bonded into a cisco channel-group compatible config, layer2+3, etc.  then br0 attemts to have bond0 as a member of the bridge.  I see traffic on bond0, but nothing on br0
<arges> lamont: it could be a matter of disabling arp monitoring, give that a try
<lamont> arges: bond is configured as:
<lamont>  bond-miimon 100
<lamont>  bond-mode 4
<lamont>  bond-slaves none
<lamont>  bond-xmit-hash-policy layer2+3
<lamont> bridge is as per that bug
<lamont> also vlans over the bond seemed to have issues
<lamont> arges: sounds like you would like some more / additional concrete data on the subject?
<apw> rtg_, i did not, will put it on my todo to look at next
<sconklin> joshhunt: I guess I'm not sure exactly what you're asking about. which specific deltas? 44-45, or 45-48?
<joshhunt> sconklin: i only checked 44-48, but it looks like the same holds true for 45 to 48
<joshhunt> the diff.gz file size in 45 is 5.3MB where as in 48 it's 3.7
<joshhunt> MB
<joshhunt> when you extract them both there's a difference of about 7MB
<joshhunt> when i do diff -u linux_3.2.0-44.69.diff linux_3.2.0-48.74.diff
<joshhunt> i see a lot of things removed in the latest diff which were in the .44 diff. i guess that i would see the same if i were to diff the 45 to the 48 as well
<joshhunt> given the change in size
<sconklin> josepht: so your concern is abotu the size, and not the content of the diffs?
<joshhunt> no my concern is the content
<joshhunt> did you look at the diffs?
<joshhunt> the first clue they were different was the size
<joshhunt> then i diff'd them
<jsalisbury> arges, It looks like the fix for bug 1186932 landed in v3.10-rc6.  Can you give that kernel a test when you have a chance?
<ubot2> Launchpad bug 1186932 in linux (Ubuntu Saucy) "Regression: kernel 3.8.0-24 breaks WPA enterprise auth [iwlwifi]" [High,Confirmed] https://launchpad.net/bugs/1186932
<arges> jsalisbury: cool yea i'll give it a shot
<jsalisbury> arges, great, thanks
<joshhunt> sconklin: i'm diff'ing 45 to 48. maybe i am looking at it wrong.
<sconklin> I don't see how comparing two diffs makes sense, when each one is between to consecutive releases
<sconklin> kamal: you here?
<joshhunt> sconklin: b/c that will show me what has changed b/t the two releases. and why they are different by 7MB
<sconklin> one diff shows you what the difference is between two releases.
<sconklin> two diffs together shows you the difference between three releases, if they're consecutive
<sconklin> the difference between the diffs doesn't mean anything
<joshhunt> the .diff.gz files you produce are applicable to the vanilla kernel. a diff b/t the two diffs shows what's changed b/t releases. i'm not sure why that doesn't make sense.
<kamal> joshhunt, sconklin: for whatever its worth (maybe not much) ...  I'm looking at this now also.   I do see that the 44.69 diff is quite a bit larger than the 48.74 diff
<joshhunt> sconklin: i think i found the issue. there appears to be a large number of EXPORT_SYMBOLs which were removed. possibly just a cleanup on your side?
<joshhunt> things from  linux-3.2.0/debian.master/abi/3.2.0-41.66/armhf/highbank
<joshhunt> tons of removes there
<joshhunt> -+EXPORT_SYMBOL crypto/gf128mul 0x00000000      gf128mul_4k_bbe
<joshhunt> -+EXPORT_SYMBOL crypto/gf128mul 0x00000000      gf128mul_4k_lle
<joshhunt> i'm not familiar with what the debian.master/abi dir contents are for, but it appears this is the main explanation for the size difference
<apw> joshhunt, those list the contents of the abi
<apw> joshhunt, of course when the abi number changes the whole abi directory is removed and replaced by one with a new name
<sconklin> joshhunt: we did recently discover and delete some old cruft in the ABI directory, but I can't remember off hand which release it was for
<apw> joshhunt, and when the abi is suppressed, it may be empty temporarily in an upload
<kamal> joshhunt, sconklin: yup, the only things I see "missing" is just that ... old debian.master/abi files
<joshhunt> yeah a quick du of that dir with both old and new release shows ~7MB difference now. 7.4MB vs 15MB
<joshhunt> thx for your help. the other "changes" i thought i saw can be explained by reordering of the contents of the diff. patches that looked like they had been removed were just found further down in the new patch file.
<kamal> joshhunt, forgive if this is old hat to you ...  what I did was to run each of the diffs through "lsdiff | sort", thus generating two sorted lists of the files contained in each diff.   then I diff'ed those two lists, and the abi changes jumped right out
<joshhunt> kamal: yeah i should have done that first. thx!
<kamal> joshhunt, truth be told, there is one other non-abi diff there, but it looks like a source file just got renamed (but I didn't look in detail):
<kamal> -linux-3.2.0/fs/lockd/clntproc.c
<kamal> +linux-3.2.0/fs/lockd/clntlock.c
<arges> jsalisbury: hey just realized that it was WPA enterprise. I don't have time to setup something here to test, but i'll try to swing by the cafe that had WPA Enterprise to test when i can
<jsalisbury> arges, ahh, ok.  thanks!  I also asked for testing in the bug, so no need to go out of your way
<bjf> apw, i noticed last week that we were still doing oneiric mailine builds
<apw> bjf, as in stable against something like 2.6.35
<bjf> apw, i'll try to find it but yes, i think so
<apw> bjf, so i think i would expect us to still build any stable we see, though i am supprised it is still being updated regardless
<apw> bjf, must be one of gregs specials
<bjf> apw, so even though we don't support it we'll continue to do those builds?
<apw> bjf, well the point more is to build all the mainline things that come out, that is using an oneiric config as the 'nearest' is the only association with the series
<bjf> apw, ack
<rtg_> apw, do you remember where gcc checks are enabled in the kernel ? For example, '/ubuntu-saucy/net/netfilter/xt_connbytes.c:23:2: warning: passing argument 1 of 'atomic64_read' discards 'const' qualifier from pointer target type [enabled by default]'
 * rtg_ -> lunch
<apw> greping for the -f option for that thing will find the bit which it checks for them
<rtg_> apw, I found it. I was looking at the wrong include file. doh! http://permalink.gmane.org/gmane.linux.kernel.commits.head/326441
 * rtg_ -> EOD
#ubuntu-kernel 2013-06-18
<harryc> How can I set btrfs to make one copy of the data and metadata on three drives of the same size?
 * apw yawns
<ppisati> cking: we can hear you
<cking> i can't hear you, /me retries
<usr_> hello everybody 
<usr_> I face a problem with Ubuntu 13.04 sudden kernal panic http://s1.directupload.net/images/130530/pqrvetxb.jpg
<usr_> Help me please its very serious problem It happens regularly !
<smb> usr_, The you should file a bug (and if doing screen pictures, disable the flash ;)) From what is readable it looks like being caused by the wl module (proprietary driver for Broadcom wireless) and at least the kernel never got updated since release. So update the system before reporting any bugs.
<usr_> I did 
<smb> The picture still shows kernel 3.8.0-19.29 running. So either the wrong kernel runs or the picture is outdated.
<usr_> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1181392
<ubot2> Ubuntu bug 1181392 in linux (Ubuntu) "[Solved for me]Kernel Panic not syncing fatal exception in interrupt-solved for me, firmware-b43-lpphy-installer instead of b43-firmware solves the panic" [High,Confirmed]
<usr_> this pic not of my computer 
<smb> Then even more reason to open your own bug report with your information. The bug you mentioned is about the b43 module an would not even match the stacktrace.
<usr_> No I faced the same problem 
<usr_> I think I  the problem is solved :-) 
<usr_> Thank you very much indeed 
<usr_> and sorry about being rude 
<usr_> Cya :-)
 * ppisati goes out for a bi
<ppisati> y
<ppisati> t
<ppisati> *bit
<apw> a biyt sounds good to me
<apw> tseliot, hey hows the dkms packags going, i think you fixed nvidia ...
<tseliot> apw: I'm about to test (as in compile) my patch for nvidia-173. So far I've patched 319 and 304. I need to transition 310 and 313 to 319 (since I don't intend to maintain them). Then I'll move on to fglrx and broadcom
<tseliot> the patches are quite big for nvidia...
<apw> tseliot, how long do we think this will take for the others?  we're obviously chomping at the bit to get 3.10 in the archive
<tseliot> apw: I was hoping to finish my work by the end of this week
<apw> tseliot, thanks
<tseliot> yw
<ppisati> looks like i'm back...
<smb> ppisati, Seems like. If you are not 3G ppisati 
<ppisati> smb: nope
<ppisati> smb: and i even upgraded the haswell box, finally! :)
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg_> apw, I assume 'UBUNTU: SAUCE: ubuntu: overlayfs -- ovl_path_open should not take path reference' should also be applied to unstable ?
<apw> rtg_, yes it should in deed, have i not done so, bad andy
<apw> rtg_, and i'll get that upstream today
<rtg_> apw, I just pushed it
<apw> great
<rtg_> apw, aufs has still not been updated upstream since March
<apw> rtg_, hmmm let me check my email archives, in case it moved
<apw> rtg_, ok there have been releases since then, i'm on the case
<rtg_> apw, cool. I'm working on lttng
<apw> you have more pain me thinks
<apw> rtg_, ok it has moved, i'll get teh new one and update our shit and see fi it works any better
<rtg_> apw, ack
<rtg_> apw, where has it moved to ?
<rtg_> it was git://aufs.git.sourceforge.net/gitroot/aufs/aufs3-standalone.git
<apw> git://git.code.sf.net/p/aufs/aufs3-standalone
<apw> rtg_, i'll get master-next and unstable cleaned up and see if they work
<apw> b #is
<tseliot> apw: just to give you an idea, this is the kind of fun it is to fix drivers for linux 3.10: http://paste.ubuntu.com/5777380/ ;)
<apw> tseliot, they really hate you don't they
<tseliot> apw: I've always had my suspicions... :D
<apw> tseliot, you seen any reports of wl being pants with 3.9 ?
<apw> tseliot, though as we won't be on 3.9 for long i guess ignore that till we are on 3.10
<rtg_> and then 3.11
<tseliot> apw: yes but I haven't looked into it yet and the only device I have for testing doesn't really work with the latest driver...
<tseliot> hopefully they won't break the procfs functions again...
<smb> Actually there seemed to be some saying even 3.8 has some issues
<smb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1181392
<ubot2> Ubuntu bug 1181392 in linux (Ubuntu) "[Solved for me]Kernel Panic not syncing fatal exception in interrupt-solved for me, firmware-b43-lpphy-installer instead of b43-firmware solves the panic" [High,Confirmed]
<smb> Of course them saying the problem is "fixed" by using b43 does not help
<tseliot> smb: that would be the open driver, right?
<smb> tseliot, yeah
<tseliot> I'm talking about the binary driver
<smb> And on the hw I got wl seemed to be running ok
<smb> Well the bug reports _start_ with a backtrace of wl
<smb> Then they switched to b43 and that was the "solution"
<tseliot> heh
<apw> for me wl seems to not be working well, like it sees nothing at all
<apw> rmmod wl; modprobe brcmsmac seem to work ok for me
<apw> we shall see how 3.10 fares with brcmsmac shortly
<smb> apw, Thats good as long as your are not unlucky like me and brcmsmac does not support your particular chipset
<mjg59> Which, given it only supports one chipset...
<mjg59> Eh, ok, three.
<apw> mjg59, yeah the wonderful world of broadcom ... sigh
<mjg59> apw: And then they decided not to add new support because b43 already had support. But we can't distribute the b43 firmware.
<smb> and then there is not only one but the lpphy and the other...
<tseliot> nice, it's even worse than I thought :D
<apw> mjg59, oh how lovely indeed
<mjg59> Yeah, pretty easy to get the impression that it was a driver written to meet a contractual obligation or something...
 * smb remembers daily nag-time: infinity: crash? apw: xen?
 * apw whines
<apw> rtg_, ogasawara, aufs updated in unstable and seems to at least surviving touch testing
<ogasawara> apw: good to know, thanks
<rtg_> apw, cool. I'm about to push alx from linux-next as well
<apw> rtg_, sweet, i have already pushed so you should be good whenever
<rtg_> apw, ack
<apw> smb, it is 4.2.1 we are looking at yes 
<smb> apw, Yeah, the 4.2.1-2ubuntu1 iirc only
<smb> Holding off with the 4.2.2 until maybe there is a Debian origin
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
 * ppisati -> gym
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 25th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg_ -> lunch
<jsalisbury> sforshee, you mind taking a look at bug 1192259
<ubot2> Launchpad bug 1192259 in linux (Ubuntu) "wireless access point won't connect- changed bandwidth in a way we can't support - disconnect" [High,Confirmed] https://launchpad.net/bugs/1192259
<rtg_> ogasawara, do you  know how the Package information Maintainer URL is generated ? for example, on https://launchpad.net/ubuntu/+source/linux it _says_ 'Ubuntu Kernel team', but actually points to https://launchpad.net/~kernel-team (which is wrong).
<ogasawara> rtg_: heh, I was looking at that very issue this morning and trying to figure it out
<ogasawara> rtg_: but then I got distracted of course
<ogasawara> rtg_: I wasn't able to determine where we could update it
<ogasawara> rtg_: is it in our kernel source?
<rtg_> ogasawara, Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
<rtg_> thats from our control info
<ogasawara> that must be it
<rtg_> a launchpad algorithm that attempts to deduce the LP ID from that ?
<ogasawara> it must, it's clearly wrong in the control file as it is
<rtg_> well, the email address is correct.
<ogasawara> ah right, that email address is correct, I keep thinking its ubuntu-kernel-team@
<tjaalton> 3.5.0-35.56 is now in quantal-proposed?
<tjaalton> oh pre-proposed..
<tjaalton> I'll probably revert the abi-break in i915_hsw, because it'll make i915-dkms ftbfs. should've seen that coming..
<tjaalton> so that drm_mm_* is again appended with _hsw, makes retiring the dkms smoother
<rtg_> ppisati, http://permalink.gmane.org/gmane.linux.network/271538
 * rtg_ -> EOD
#ubuntu-kernel 2013-06-19
<ppisati> reboot
<smb> login
<ogra_> oh my ... who decided to make the framebuffer console builtin on grouper ...
 * ogra_ sighs
<ppisati> ogra_: this one? - git://kernel.ubuntu.com/ubuntu/ubuntu-nexus7.git
<ogra_> well, the last upload
<ogra_> it was a module in the former upload, that i could at least rm at build time 
<ogra_> (imge build time that is)
<ogra_> we dont want anything to initialize the framebuffer before surfaceflinger or Mir do that ... fbcon somehow did get enabled (as a module) as part of the "we need a /dev/console for upstart" change ... 
<ogra_> while we want a /dev/console we dont want the framebuffer console ...
 * ppisati ponders... it sucks to be a framebuffer console nowadays...
<ogra_> haha
<ogra_> on android for sure
<ogra_> argh, and all the other kernels were switched to "quiet"
<ogra_> GRRRRR !
<ogra_> so we wont have any info on the ramconsole for debugging anymore 
<ppisati> ogra_: you wanna talk with rtg as soon as he wakes up (~3hrs)
<ogra_> yes, just writing a mail, i think that was a request from slangasek (only for grouper though) 
<tjaalton> bjf, henrix: hey, I have a last-minute change or two for the ubuntu-quantal kernel :/ (for -35.5x)
<henrix> tjaalton: i believe sconklin started prep'ing the Q kernel yesterday
<tjaalton> henrix: yeah I noticed -35.56 got tagged..
<henrix> tjaalton: i guess you'll need to convince him to respin the kernel :)
<tjaalton> henrix: right.. so in 4-5h maybe?
<henrix> tjaalton: yep. maybe you can start by sending the patches to the mailing list so that we may get the ACKs before that
<tjaalton> sure
<tjaalton> I'll prep the second one
<henrix> tjaalton: cool. thanks
<ogra_> ppisati, ...
<ogra_> ogra@anubis:~/datengrab/bastel/nx7/linux-grouper-3.1.10$ fakeroot debian/rules binary-grouper
<ogra_> make: *** No rule to make target `binary-grouper'.  Stop.
<ogra_> shouldnt that work ? (i dont want to build the tools)
<ppisati> ogra_: should be, hold on
<ogra_> ppisati, heh, false alarm, ignore me
<ogra_> i forgot to do the dpkg-architecture export
<ppisati> DOH!
<ppisati> since i upgraded this box to saucy, i lost gcc4.6
<ppisati> and that kernel explicitely requires 4.6
<ppisati> AKA i can't build it anymore
<ogra_> that cant be ... the package gets built on saucy in the archive 
<ppisati> ogra_: i'm cross compiling here
<ogra_> ah, got it 
<tjaalton> henrix: ok, pushed the branch and email sent
<henrix> tjaalton: great, thanks. i'll have a look at them in a bit.
<tjaalton> thans
<tjaalton> +k
<tjaalton> it's kinda backwards though to add the pci-id's before they are even on saucy, but oh well .)
<tjaalton> :)
<henrix> tjaalton: ugh, i guess the 2nd patch generation is automated, right? :p
<tjaalton> henrix: the drm_mm* madness?
<henrix> tjaalton: yep
<tjaalton> well I did double-check against the old version for correctness, should be right :)
<tjaalton> also built fine, dkms too
<henrix> tjaalton: yeah, and it will be a pain to maintain :)
<tjaalton> so it should match 1:1 to the old one, a650b0fdeda61 shows how to rename next time if such trickery is needed again
<tjaalton> sure is
<henrix> tjaalton: that's why i was asking if you had some script to automate that renaming
<tjaalton> but, I think it wont receive many updates anymore
<tjaalton> not to the old names
<tjaalton> old-old names that is, the recent rebase was easy
<henrix> tjaalton: cool. anyway, we're already maintaining that ubuntu/i915 thing, so maintenance will always be painful
<tjaalton> I just wish we'd be able to just suck it up and pull all of drm/* as sru..
<henrix> tjaalton: one of the things missing for that is a bug # :p
<tjaalton> henrix: 3.8.13.x won't receive that many updates, I hope. and the old version was kinda left behind anyway
<tjaalton> bug for?
<aquarius> A little while back I was testing a kernel bug with jsalisbury and so installed a specific kernel, 3.8.0-030800-generic. I'd like to stop using that and get back to running the most recent kernel from raring. How do I do this? I am frightened of apt-get removing the kernel that I am currently running ;)
<tjaalton> the rename? maybe reuse 1188305?
<henrix> tjaalton: oh, sorry. i missed the BugLink in the 1st patch
<tjaalton> yeah, so "some oem's" want us to have all these new pci-id's in the archive by end of next week..
<tjaalton> userspace is already being dealt of, uploaded to -proposed just not acked yet
<henrix> tjaalton: ok, cool. so lets just wait for sconklin and bjf and see what they say. maybe they are already waiting for these patches...?
<tjaalton> but if the kernel one could be squeezed in it would roughly fit that timeframe as well
<tjaalton> henrix: nah, I was just late to the party..
<henrix> tjaalton: heh, so lets hope they had a good night sleep :)
<tjaalton> indeed :)
<tjaalton> I did mention this late last night (my time) but I guess they were gone already
<gompa> iam getting a amd-vi event logged io_page_fault device=0a:00.0 domain=0x001f message on the x64 kernel 3.8.0-25-generic on a asus  sabertooh 990fx r2.0 (this disables my nic) (i think i found related bug report here :http://linux-kernel.2935.n7.nabble.com/AMD-Vi-error-and-lost-networking-with-r8169-td630152.html )(but in that bug report the device and domain are different)
 * henrix -> back in 15
<apw> gompa, sounds like an iommu getting all humpy, i would file a but, at least that way people can track what h/w etc you have
<apw> s/but/bug
 * ogra_ hugs rtg_ 
<ogra_> rtg_, yeah, theh quiet thing is simply useless (we dont (and likely wont) set quiet on the cmdline but its a patch we dont need to carry
<rtg_> ogra_, do the rest of the Nexus kernels have the same FRAMEBUFFER_CONSOLE issue ?
<ogra_> android explicitly disabled fbcon, so they shouldnt 
<ogra_> that came in with the console fixes for boting grouper in the flipped setup ... 
<rtg_> ogra_, why was slangasek hot for the 'quiet' patch ?
<ogra_> all other HW seems to properly just use the ramconsole, its a tegra thing
<ogra_> because he didnt understand that we wont have any console output ever 
<ogra_> unless we actually patch the kernels, but that would mean a lot of extra work for porters (exynos for example doesnt boot if you enable fbcon)
<rtg_> ogra_, ok. I won't bother reverting for now since its a harmless patch as long as 'quiet' isn't on the boot command line.
<ogra_> yeah
<rtg_> ogra_, upload grouper then ?
<ogra_> yup, i tested it locally and it works fine here 
<rtg_> ogra_, ok, will do
<ogra_> thanks :)
<bjf> tjaalton, you have made me very sad this a.m. I will accept your nasty commits and we will respin. this _really_ should have come in last week.
<tjaalton> bjf: :/ sorry.. and huge thanks
<bjf> tjaalton, shouldn't we apply the pci id commit to raring as well?
<tjaalton> bjf: it's there via 3.8.13.2
<bjf> tjaalton, ok, i'm not awake enough to check
<bjf> infinity, ^ respinning Q
<tjaalton> btw, the ReleaseInterlock page is old, shouldn't saucy have one?
<tjaalton> hmm that's not what I wanted.. kernel-sru-workflow.html instead
 * ppisati steps away for ~10mins
<rtg_> apw, ogasawara: anything you want in saucy before I upload ? there are a couple of d-i fixes that need to get propagated.
<ogasawara> rtg_: nope, I'm good here
<ogasawara> rtg_: I assume the dkms issues tseliot was sorting are done?
<rtg_> ogasawara, heck if I know.
<rtg_> ogasawara, I just annoy apw periodically who then annoys tseliot
<ogasawara> rtg_: I guess I should clarify, this is the 3.10 kernel you're going to upload right, not 3.9
<rtg_> ogasawara, don't you know ? I'm a nexus hacker these days. who thought it was a good idea to do 4 of those dang things ?
<rtg_> ogasawara, no, 3.9 for now
<ogasawara> rtg_: heh.  ok then nevermind my babbling about dkms bits.  that's only an issue for 3.10
<rtg_> ogasawara, right. IIRC tseliot said he hoped to be ready by end of the week
<ogasawara> rtg_: yep, I recall the same
<tjaalton> aiui only fglrx left
<ogasawara> Daviey: ^^ it would be good to get your formal list of dkms packages you guys care about if you want us to perform advanced testing before we upload.  I sense an impending upload soon.
<tseliot> ogasawara: yes, I'm working on fglrx
<rtg_> an impending dkms explosion :)
<ogasawara> heh
<Daviey> ogasawara: Ah, i thought my team were doing the advance testing this time.. so i held off on sending a list.
<ogasawara> Daviey: ok cool, in that case...heads up, we're probably going to upload a 3.10 kernel soon.
<ogasawara> Daviey: would probably be good for you guys to test sooner rather than later
<Daviey> ogasawara: I was looking to get some stuff validated against the PPA tomorrow.  Which means that we'll know of issues then.
<Daviey> I wouldn't like you to block on this tho.
<ogasawara> Daviey: ok great, tomorrow should be good.  I don't think we'd upload until EOW anyways at best.
<infinity> bjf: Ack on the Q respin.
 * rtg_ -> lunch
 * henrix -> EOD
<jjohansen> apw, rtg_: is there a wiki for doing test builds of the phablet kernels
<apw> jjohansen, yeah you want er
<jjohansen> apw: yes please
<apw> jjohansen, https://wiki.ubuntu.com/Kernel/Dev/AndroidKernel
<apw> jjohansen, i cross build my kernels to make them for that use
<jjohansen> yeah
<rtg_> jjohansen, what apw says. for what you are doing you can just cross build them
<jjohansen> rtg_: yep thanks
 * apw calls it a day ... i hate hyper-v and i love beer, so the decision is easy
 * rtg_ -> EOD
#ubuntu-kernel 2013-06-20
<xnox> does CONFIG_ARCH_RANDOM enable usage of intel rdrand to seed /dev/random ?
 * henrix will be out for a bit
<tseliot> apw: I'm facing a problem with 3.10 and fglrx but I'm not sure it depends on my work on the procfs calls
<apw> tseliot, sounds nasty indeed
<tseliot> apw: I'm getting this http://paste.ubuntu.com/5783212/
<apw> tseliot, i think i recall them using bios calls to get the BIOS out of the card, and sucking info out of it
<apw> perhaps a change in interface there for making int10 calls
<tseliot> apw: hah, one more error: Fail to open device PCI:1:0:0
<apw> oh :)
<tseliot> which is the actual amd card...
 * ppisati goes out for a bit...
 * henrix -> lunch
<rtg_> henrix, rebooting gomeisa for misc updates
<henrix> rtg_: ack
<apw> henrix, ok ... cve tracker is happy again
<apw> henrix, totaaly a bug, and only affecting handlng of linus tree markers ie upstream_source: not any of the visible versions
<henrix> apw: great, thanks. why something has to break whenever i touch cve tracker? :)
<apw> henrix, cause you are doing work so it has to changed things :)
 * henrix shakes on every bzr push :)
<apw> henrix, what you are doing is just fine :)  its the tracker that has mental problems
<smb> infinity, Did I ask you about looking at crash today?
<rtg_> slangasek, using libpython-dev as a build dependency instead of python-dev causes a build failure, e.g., make cannot find /usr/bin/python-config.
<rtg_> Makefile:755: The path '/usr/bin/python-config' is not executable.
<rtg_> Makefile:755: *** Please set 'PYTHON_CONFIG' appropriately.  Stop.
<rtg_> I've not encountered this problem, so I could use your input.
<slangasek> rtg_: hmm, that's strange, it *cross*-built for me just fine; in that case, I guess more work is needed before we can make the package cross-build-friendly
<rtg_> slangasek, yeah, I was just drilling down through the dependency layers.
<rtg_> slangasek, python-dev depends on python (which contains python-config) whereas libpython-dev does _not_ depend on python
<slangasek> rtg_: actually, python-config should be in python-dev, *not* in python; that seems to be the case here
<rtg_> well, until hat bug is resolved I'm gonna drop that part of your patch.
<slangasek> rtg_: yep, sounds fine
<slangasek> I'm still puzzled that the package didn't ftbfs for me when building cross
<slangasek> either maybe that's a clue, or maybe it's a subtle bug
<rtg_> slangasek, you're sure it tried to build perf ?
<slangasek> yep
<rtg_> dunno then
<slangasek> but maybe I didn't clean the tree between attempts
<rtg_> slangasek, what incantation did you use ? dpkg-buildpackage --arch=armhf ?
<slangasek> rtg_: 'debuild -uc -us -B -aarmhf'
<rtg_> slangasek, 'do_tools	= false' for armhf.
<rtg_> seems like I should fix that
<slangasek> rtg_: ok :)
<rtg_> slangasek, man, this multi-arch cross build works great forarmhf on saucy. I feel stupid for having used QEMU to do all the Nexus kernel development. this is blazing fast.
<slangasek> :D
<slangasek> rtg_: well, when poking at this, I was shaking my head in bewilderment that the cross-build wasn't in better shape and wondering what exactly you guys were doing for ARM kernel testing ;)
<rtg_> slangasek, mostly native building.
<slangasek> right :)
<rtg_> bjf, By default, no CPU will be an adaptive-ticks CPU.  The "nohz_full="
<rtg_> boot parameter specifies the adaptive-ticks CPUs.  For example,
<rtg_> "nohz_full=1,6-8" says that CPUs 1, 6, 7, and 8 are to be adaptive-ticks
<rtg_> CPUs.
<rtg_> see Documentation/timers/NO_HZ.txt
<bjf> looking
<bjf> rtg_, as i read that, it doesn't make sense for us to have CONFIG_NO_HZ_FULL=y
<rtg_> bjf, well, given that its causing problems.... Otherwise with CONFIG_NO_HZ_FULL=n there is no change in behavior
<rtg_> its opt in
<bjf> rtg_, it's not opt in if _ALL=y: "the CONFIG_NO_HZ_FULL_ALL=y Kconfig parameter specifies that all CPUs other than the boot CPU are adaptive-ticks CPUs"
<rtg_> bjf, right. its opt-in if  CONFIG_NO_HZ_FULL=n
<bjf> ack
<rtg_> bjf, so, disabling that config means the feature will get little testing. thats all I'm saying.
<bjf> rtg_, agreed
<rtg_> bjf, perhaps you should reach out to Fred about this. he might have some ideas
<bjf> rtg_, i just don't see that option being viable for a general desktop kernel
<rtg_> bjf, it seems like it would be the cat's meow if it worked.
<slangasek> ogra_: so dropping in the new kernel with the console fixes yesterday gives me a perfect, no-scrolly-text container-flipped boot on grouper... but when I try to launch apps, I'm getting the white canvas again, which I thought was fixed a while ago.  Do you know what's going on there?
<ogra_> slangasek, there is  a race in the platform-api/qtubuntu code, its known and being worked on, reboot a few times, one boot will have it working
<slangasek> ok
<slangasek> so nothing I need to worry about, thanks :)
<rtg_> slangasek, I figured out  why cross compiling fell out of favor for me. dpkg-buildpackage was what I was using, but the installed package dependency check always failed, whereas debuild must be smarter.
<slangasek> rtg_: debuild actually uses dpkg-buildpackage under the hood, so I think dpkg itself got smarter :)
<slangasek> rtg_: you can also always pass '-d' to skip the dependency check if you know it's checking wrong, fwiw
<rtg_> slangasek, well, dpkg-buildpackage _still_ fails the dependency check
<slangasek> hmm!
<rtg_> lemme try -d
<rtg_> tahts better
 * ogra_ sees a "export $(dpkg-architecture -aarmhf)" .... in the cross compile instructions ... might be that this is related ?
<rtg_> ogra_, I'm running in a clean saucy amd64 chroot with no environment changes. 'dpkg-buildpackage -d -aarmhf -B' works pretty well (except for tools)
<ogra_> ah, i never build tools ... 
<rtg_> and frankly, I don't care about tools for test builds
 * ogra_ always only builds binary-$subarch
<rtg_> I _am_ liking this cross compile stuff though. it hauls ass. 
<ogra_> hehe, yeah
<rtg_> ppisati, conf call ?
<ppisati> yep
 * rtg_ -> lunch
 * apw calls it a day, and goes make a new travel laptop .. sigh
 * rtg_ -> EOD
<infinity> ppisati: Can you re-do your ti-omap4/Q rebase to match the respin?  (bug #1192805)
<ubot2> Launchpad bug 1192805 in Kernel SRU Workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1192805
#ubuntu-kernel 2013-06-21
<tseliot> apw: are you around?
<smb> tseliot, Only if suffering from insomnia
<tseliot> smb: that would make the two of us ;)
<smb> tseliot, Heh, yeah. Somehow I fell out of bed early today
<tseliot> it is rather annoying...
<smb> At least my office is less hot this morning. 
 * apw yawns
<RAOF> BEES!
 * smb gets second cup of coffee
<RAOF> Time for another steaming cup of bees!
<smb> A stinging start into the day. :)
<cking> bees? the buzzy sort?
 * ppisati grabs more coffee
<Daviey> Morning, Please can a linux-meta for saucy be uploaded to https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages.
<apw> Daviey, i had ben staying away from doing that because we haven't switched yet ... and the versions in that ppa are always -0 so they self update
<Daviey> apw: Ah, the reason i wanted it was to simply upgrading to the pre-proposed kernel.
<Daviey> surely if you add the PPA, you want the latest?
<apw> Daviey, yeah probabally, it isn't have we have used that PPA generally, it is more about builds
<apw> i'll see about making an unstable branch in out meta perhaps, ick
<Daviey> apw: thanks
<apw> Daviey, ok it is building
<apw> expect it in the ppa in half hour or so
<Daviey> apw: thanks
 * ppisati goes out for lunch
<apw> ppisati, good plan
<smb> apw, Depending on weather conditions... :)
<apw> heh true
 * apw will be dropping shortly to shift locations ...
<rtg_> apw, going to work from your local pub ?
<apw> rtg_, oh that would be nice
<rtg_> apw, laundramat then ?
<apw> in laws ... not sure if that is the saem
<apw> closest to a local pub :)
<rtg_> surely just as much fun
<tseliot> apw, ogasawara, rtg_: nvidia(s), fglrx(s) and broadcom should be all set for linux 3.10
<ogasawara> tseliot: awesome, thanks!
<rtg_> tseliot, cool. I'll upload first thing Monday
<tseliot> good :)
<rtg_> Daviey, y'all ready with your dkms bits ?
<Daviey> rtg_: The primary package is a bit more complicated than we hoped.
<Daviey> openvswitch is going to be a real pain from what we can see
<rtg_> Daviey, bummer
<rtg_> Daviey, do you have any folks running saucy that'll crater if I upload a 3.10 kernel ?
<Daviey> rtg_: James Page and I both found it to be a PITA independently, but James summarised it to upstream - http://openvswitch.org/pipermail/dev/2013-June/028822.html
<Daviey> rtg_: Well, i don't think it's a good idea to block getting 3.10 in.  We are looking to have a cheat/compat
<rtg_> Daviey, I have to wonder why ovs isn't in the upstream kernel
<Daviey> rtg_: half of it is.. 
<Daviey> They are introducing it into mainline in chewable hunks.  
<rtg_> the half that works :)
<rtg_> ok
<apw> man the traffic is epic today ... sigh
<smb> apw, Is that so unusual on a Friday where you are
<apw> smb, this early it is yeah, but the world is full i think
<smb> apw, Yeah, that too. Here it is not uncommon to start at 2 or 3pm as commuters from farther places move home. At least I used to be stuck in there when I was one of those a long time ago... :)
<apw> oh no
<jsalisbury> cking, quick pci question.  Is the value for a devices "Subsystem" set in the devices firmware?  For example the values 1000:0012 in the following lspci output:
<jsalisbury>  01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01)
<jsalisbury>         Subsystem: Device [1000:0012]
<infinity> jsalisbury: It comes from the device, if that's what you mean.  Whether that's firmware or hardware, or whatever, depends on the device in question.
<jsalisbury> infinity, cool, makes sense.
<infinity> jsalisbury: (Plus, in cases like full system builds, laptops come to mind, it can be masked so, for instance, all devices in a Lenovo laptop claim to be "Lenovo" instead of "Intel" and "Atheros")
<infinity> jsalisbury: Which can be both a good or bad thing, depending on what you hope to do with said numbers. :P
<jsalisbury> infinity, ahh, interesting
<jsalisbury> infinity, that is definitly something to remember so not to go down a rat hole :-)
<infinity> jsalisbury: I suppose it may be more accurate to say that it can come from the device, or the host bridge, or the ACPI tables in the BIOS, and any higher level can override the lower levels.
<infinity> jsalisbury: Most devices themselves won't have a subsystem ID, except when they do, some hostbridges will override, some won't, and most pre-build systems seem to override in ACPI tables, except the ones that don't. :P
<infinity> (But it's handy for, say, isolating "intel_hda, but only on on lenovo laptops", cause you can match the device ID with the subsystem ID)
<jsalisbury> infinity, very informative.  Thanks for the details.
 * ppisati -> EOW
 * henrix -> EOW
 * rtg_ -> lunch
 * cking -> EOW
 * rtg_ -> EOW
#ubuntu-kernel 2013-06-22
<savio> Bug #987630 anyone working on this
<ubot2> Launchpad bug 987630 in gnome-settings-daemon (Ubuntu) "changing brightness freezes computer" [Undecided,Confirmed] https://launchpad.net/bugs/987630
#ubuntu-kernel 2014-06-16
<caribou> Any quick git trick to know when a specific commit made it to the Ubuntu kernel ?
<smb> caribou, Generally (if it does not have to be automated), search for the commit message in git log, then you can use that sha1 in a "git describe --contains"
<smb> All usually on the master branch
<caribou> smb: I already had the hash thanks looks like it's what I need
<smb> caribou, The last step of course is usually to ask rmadison where that version is (-proposed or -updates)
<arges> apw: discussing bug 1323165 
<ubot5> bug 1323165 in linux (Ubuntu Trusty) "[HP ProLiant DL380p Gen8] kernel BUG at /build/buildd/linux-3.13.0/mm/memory.c:3756!" [Undecided,Fix committed] https://launchpad.net/bugs/1323165
<arges> looks like the patch is in master-next but the bug status wasn't updated
<apw> yes that appears to be wrong, it has a bug link so it should just be flipped as you suggest
<arges> cool
<rtg> looks like the patch committer was too lazy or stupid to do the right thing.
<apw> lets assume lazy :)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 17th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
#ubuntu-kernel 2014-06-17
<Yaannnn> i
<Yaannnn> Hi
<bjf> rtg, the synaptics hid driver that's on the mailing list. that got applied once and then reverted due to regressions. i'd like to hear about extended testing on this patchset before applying
<rtg> bjf, ah, I'd forgotten about that. good catch.
<smb> bjf, Did not know about the revert but I had similar feelings about it
<bjf> smb, yeah, it was a bit of a mess. they have not come back with it for some time so i'm hoping that they did more testing
<smb> bjf, Yeah, I looked into the lp bug report and did not have the feeling everybody was happy
<bjf> AceLan, ^ anything you can add to the mailing list thread would be helpful
<stgraber> hey there, any idea when I'll get a fix for bug 1308761 in trusty? that thing is spamming all LXC users with thousands of scary looking warnings in their log, making any kind of centralized logging explode...
<ubot5> bug 1308761 in linux (Ubuntu Trusty) "apparmor spams log with warning message" [Undecided,Confirmed] https://launchpad.net/bugs/1308761
<stgraber> John apparently got the fix into utopic, but I guess this got missed as a required cherry-pick for trusty SRU
<Agontuk_> Hello. I'm trying to boot ubuntu touch but can't get past boot logo. last_kmsg says "Kernel panic - not syncing: Attempted to kill init!". There's no other useful info. How can I debug the issue ?
<rtg> stgraber, well, he's the one assigned to the bug, so I thought he'd send a patch.
<rtg> Agontuk_, wrong channel. try #ubuntu-touch
<stgraber> rtg: hmm, yeah, I'll bug him some more, though let me first check if that patch isn't trivial enough that I can just figure it out and be done with it
<Agontuk_> rtg, they told me to ask here :). OK, I'll check with them again.
<rtg> stgraber, its a simple enough patch. I'll float it on the k-team list.
<stgraber> rtg: thanks
<hansh> Is anyone willing to help me with my latest post on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981 regarding patching a kernel?
<ubot5> Ubuntu bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
<rtg> stgraber, fix committed for Trusty
<stgraber> rtg: yay, thanks1
<stgraber> *thanks!
<arges> rtg: re 16-bit segments/wine fix. I think the fix is fine for now, but just to be aware that in the future a better fix might come down the pipe
<rtg> arges, well, perhaps. If upstream gets around to it.
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg> jsalisbury, maybe you could get this gal started on a new bug ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1327300/comments/13
<ubot5> Ubuntu bug 1327300 in linux (Ubuntu Lucid) "Regression in commit 8e4e453d548e3c24e9070eda23c52f210951b921" [Critical,Fix committed]
<jsalisbury> rtg, sure, I'll take a look
<rtg> ascertain if her stuff ever worked
<jsalisbury> rtg, ack
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<rtg> apw, Hans109h is feeling abandoned. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981/comments/46
<ubot5> Ubuntu bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
<rtg> sforshee, where are we wrt to -8 or -9 iwlwifi firmware ? https://bugs.launchpad.net/bugs/1325200 https://bugs.launchpad.net/bugs/1330724
<ubot5> Ubuntu bug 1325200 in linux-firmware (Ubuntu) "Missing iwlwifi-7260-8.ucode causes connection problems" [Medium,Confirmed]
<ubot5> Ubuntu bug 1330724 in linux-firmware (Ubuntu) "FW for Intel Wireless 7260 v8 missing" [Undecided,New]
<apw> rtg, ack, damn that thing, i see i even figured out the bug
<sforshee> rtg: 3.13 won't use -9, but once we've released with that iwlwifi patch you applied recently we should be able to go back to -8
<rtg> sforshee, ack
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 24th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<hansh> apw, not necessarily abandoned after all you did figure it out!...just need further instructions.  I appreciate your help on it, just getting itchy to upgrade.
<apw> hansh, yeah dropped the ball on that one, i'll clean it up and get it submitted in the morning, i've melted my brain for today
<hansh> apw, amazing!  
<arges> mlankhorst: hi
<arges> not sure if you are still around its pretty late for you
<arges> kirkland: ok so dpkg -i linux-image*.deb works on th ec2 image
<arges> ec2 instance
<arges> it spits out some warnings with grub, but after rebooting it 'uname -a' shows the correct version
<kirkland> arges: nice
<kamal> arges, what version exactly?  :-)
<kirkland> kamal: okay, do you have a ppa or .deb's that I can point them to, to test?
<arges> kamal: i'm running current mainline. and when I say 'works'I mean it boots:  3.16.0-999-generic #201406170315
<arges> kirkland: you should check the bug comment, I think jsalisbury has the instructions there
<jsalisbury> arges, ooh, that's crack of the day kernel too, so it might already have that patch
<jsalisbury> s/might/should/
<kamal> kirkland, no, my 3.13-stable version which includes that hasn't been released yet (not until Friday), so no .debs yet  ...  yes, just test that mainline -- they'll both include the patch we're talking about.
<kirkland> kamal: ack
<arges> cool,now to shutdown this instance before i start getting charged money
<jsalisbury> kirkland, comment #3 in the bug, but instead of downloading the .deb, see if they can do it the way arges just did.
<kirkland> jsalisbury: k
<jsalisbury> kamal, do you know off hand if the patch is in mainline as of 3.15 or 3.16-rc1?
<kamal> jsalisbury, kirkland, arges: that patch first appears in v3.15
<jsalisbury> kamal, cool
<kamal> for reference, the patch we're talking about here is mainline sha cc2f338 "batman-adv: fix local TT check for outgoing arp requests in DAT"
<jsalisbury> kamal, thanks, I'll add that to the bug
<kamal> jsalisbury, *after* you test it!  ;-)
<kamal> jsalisbury, this whole goose chase is based only on my wild speculation  :-)
<arges> kamal: well its pretty standard. test latest mainline to see if a patch already exists.
<kamal> arges, well sure -- *that* part at least is based on solid principles  ;-)
<jsalisbury> arges, did you just download the image from kernel.ubuntu.com and dpkg -i it?  If so, can you use either on AWS amd64 or i386?
<jsalisbury> arges, just curious so if I have to ask someone else to test an AWS kernel again in the future.
<arges> wget http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/linux-image-3.16.0-999-generic_3.16.0-999.201406170315_amd64.deb && sudo dpkg -i linux-image*.deb
<jsalisbury> arges, cool, thanks!
<arges> then you'll get a wierd grub merge issue. use the maintainer version.
<arges> then reboot
<arges> kirkland: i think you shoudl also emphasize that this should only be done with a _test_ VM
<jsalisbury> arges, thanks
<kirkland> arges: of course
#ubuntu-kernel 2014-06-18
<mlankhorst> arges: hey
<smb> mlankhorst, Hope you don't expect him to be around at this time of day. :)
<infinity> zequence: I see fresh lowlatency rebases in your PPA.  Are those good and ready to be copied?
 * infinity assumes "yes" and copies away.
<infinity> pkern: Can we assume from your comments on bug 1300739 that it's also working for you for lts-trusty?
<ubot5> bug 1300739 in keepalived "keepalived doesn't load any ipv6 virtual servers" [Undecided,New] https://launchpad.net/bugs/1300739
<pkern> infinity: I tried the trusty kernel on precise and I tried the lts-trusty kernel on precise. Both worked fine.
<pkern> infinity: Somewhat annoyed that the audit fix didn't make it into -30, though.
<apw> pkern, last i looked they hadn't settled on a sane fix for that, a lot of "this doesn't fix blah and i don't care" going on
<pkern> apw: Tempting to just divert the x32 ld-linux away.
<pkern> I think my initial fix was pretty close to fixing stuff. One could've switcheroo'ed the arch designation, but meh.
<trippeh_> x32, ugh
<apw> pkern, yeah i asume the issue here is there is noone stepping up to care about x32 upstream
<trippeh_> buggy POS ;)
<trippeh_> and security hazard
<infinity> trippeh_: Security hazard how?  Because one security bug was found in it?
<infinity> pkern: Seems odd that production machines would have libc6-x32 installed in the first place.
<trippeh_> because it is messy and is bitrotting, as far as I understood the discussions on lkml some time ago
<trippeh_> they besicly regretted merging it
<infinity> trippeh_: Upstream regrests merging nearly everything, I think I'd take that with a grain of salt unless I read the thread in question and put it in context.
<trippeh_> ok, I think the wording was something like "horrible mess"
<trippeh_> ;)
<trippeh_> its a while ago, but I doubt much has changed
<pkern> infinity: gcc-multilib
<pkern> infinity: Because engineering.
<infinity> pkern: Fair enough.  What was the bug again?  As much as we're fans of "upstream first", I vaguely recall your patch being trivial enough that maybe we should JFDI as Ubuntu saucy for the next cycle.
<infinity> apw: Opinions?
<infinity> s/saucy/sauce/
<infinity> Stupid release names breaking my ability to type.
<apw> infinity, i think the issue was it fixed the bit in question but broke auditing or something, and upsteam instrad of helping went all postal on auditing
<pkern> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605
<ubot5> Ubuntu bug 1302605 in linux (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang when using auditd" [Undecided,Confirmed]
<pkern> apw: Ack.
<pkern> It was a bit inconsistent to have two syscall paths both yield to auditing, one with arch=i386 and one with arch=amd64. I admit that.
<pkern> But surely bounds-checking alone will just exclude syscalls from auditing, which is wrong as well.
<apw> "but auditing is slow and utter crap, *sounds or machine guns and people screaming*"
<pkern> And they're probably right. But it's not my choice to make. 
<apw> no indeed, helping make it less crap and work mostly would have been nice
<marvin24> hi and maybe silly question
<marvin24> which modules belong to debian.master/d-i/modules/kernel-image
<marvin24> ?
<apw> marvin24, that is the d-i module kernel-image which contains the kernel
<marvin24> apw: ok, so this affects only debian installer (not the kernel in a installed system)
<apw> marvin24, it defines a grouping of files for installation into the image which becomes the CDs yes
<marvin24> apw: the reason I'm asking is that I want to get the utopic kernel booting on my tegra2 netbook
<marvin24> it seems that srwarren (from nv) added a lots of tegra specific drivers to kernel-image
<apw> hmmm, that sounds like it owuld be odne if they wern't already in the right places
<marvin24> in fact, the generic kernel already boots fine, but misses the tegra-drm module
<apw> and likely that should be in the appropriate other d-i module for arm
<marvin24> I can submit a patch to fix this, but I wonder if I should also add it to kernel-image
<marvin24> yes, maybe some video module
<marvin24> on the other hand, some modules are necessary to get the system to some useful state, e.g. regulators, i2c
<marvin24> so kernel-image should be ok
<marvin24> but I'm not an d-i expert
<apw> likely things like that would be in kernel, not 100% sure myself, i'd say make the patch send it to kernel-team@ list, and i can talk it through with the d-i folk to make sure it is appropriate
<marvin24> apw: yes, the real problem is that everything is a module, but I guess that won't change
<hans109h> apw, any progress?
#ubuntu-kernel 2014-06-19
<amitk> cking: thanks for the fixes, do you have a branch where I can pull from? I am not close to a patch-friendly email setup currently
<cking> amitk, i don't but I can do that in a mo
<cking> amitk, git://kernel.ubuntu.com/cking/idlestat
<amitk> cking: great, thanks
<cking> btw, there are a bunch of big leaks that valgrind is finding, I've not yet had time to look at them all
<cking> amitk, do you intend to throw the code at tools like coverityscan? if you want I can set that up?
<amitk> cking: we really should run valgrind/sparse/ etc. on this but we're racing against time to get it feature complete for kernel summit in Aug
<amitk> cking: please go ahead, will you be able to share the reports?
<cking> i can share the reports and add whoever you want to be included on the project
<cking> btw, do you require this to be packed in debian? 'cos I am willing to do that to as I'd like this tool in ubuntu ;-)
<amitk> cking: yes please! As you know, packaging has been a particular weakness of mine
<cking> i'll try and get it done when I have some "spare" moments 
<amitk> much appreciated
<cking> np
<cking> amitk, BTW, nice write-up in LWN
<amitk> cking: thanks :)
<apw> hans109h, i have started the conversation upstream
<apw> mlankhorst, so ... do we still use RADEON_UMS under any circumstances or has that been excised from Xorg now
<mlankhorst> not in X.org at least since precise, maybe it was used on other archs but the xorg driver from quantal didn't support ums any more
<mlankhorst> and even in precise it was probably some old ppc's only that actually ended up using it
<rtg> BenC, I've disabled powerpc64-emb in Utopic for FTBS in some arch code. How about having a look ? ('cause I think it is as a result of your SAUCE patches)
<BenC> rtg: Ok, Iâll have it working by Monday
<rtg> wfm
<sforshee> rtg: on bug #1332137 I don't think he's saying that -8 shouldn't have been reverted for 7260, I think he wants it reverted for 3160 as well
<ubot5> bug 1332137 in linux-firmware (Ubuntu) "linux-firmware 1.127.3 has -8 firmware for Intel 3160, but not Intel 7260" [Undecided,Invalid] https://launchpad.net/bugs/1332137
<sforshee> rtg: that's based off of the activity on bug #1293569
<ubot5> bug 1293569 in linux-firmware (Ubuntu) "iwlwifi-7260-8.ucode causes network disconnections problems" [Medium,Confirmed] https://launchpad.net/bugs/1293569
<rtg> sforshee, oh. Maybe Trusty will be out soon.
<sforshee> rtg: yeah not sure that it makes sense to revert it at this point
<arges> bjf: hey for autotests; if a test might crash the kernel; how will autotest detect the failure? is it timeout based?
<bjf> arges, yeah, it's likely to timeout though it also may just hang the jenkins job until someone goes and pokes it
<marvin24> rtg: thanks for applying tegra drm support
<marvin24> would it also be possible to increase the CMA size to 64M?
<bjf> arges, it's fairly straightforward to add timeouts to the tests if desired (i've done it)
<rtg> marvin24, this one ? CONFIG_CMA_SIZE_MBYTES=16
<marvin24> yes
<marvin24> rtg: needs 64M 
<rtg> marok
<rtg> marvin24, ok
<marvin24> rtg: thanks!
<rtg> marvin24, done
<marvin24> rtg: ok, so thanks again for high speed :-)
<rtg> np
<arges> bjf: is there a way to have autotest install ubuntu package dependencies
<bjf> arges, i do that via my own infrastructure. look at kernel-testing git repo; lib/testsprops.py
<arges> bjf: so that's done outside of autotool client test?
<bjf> arges, yes
<bjf> arges, though there's no reason the test itself can't do it
<arges> bjf: utils.system('apt-get install blah') ? 
<bjf> arges, yeah
<bjf> arges, i install pkgs externally using my method and then reboot the system one final time before running the actual tests
<arges> bjf: http://autotest.readthedocs.org/en/latest/main/local/AddingTest.html#setup fyi
<bjf> arges, yes i use that
<bjf> arges, but not for installing packages
<arges> for the tarball extraction etc.the last comment shows how to use the 'client's system software manager' which uses apt
<bjf> arges, that may well be but i want a reboot after installing packages and before running tests
<arges> bjf: ok
#ubuntu-kernel 2014-06-20
<narindergupta> rtg: hi Tim
<melodie> hi
<melodie> I would like to have an information about the kernels under Trusty, the 3.13 series: are they patched to come with AUFS or is AUFS part of the kernel tree?
<rtg> melodie, patched
<melodie> oh thanks rtg !
<melodie> rtg does the patch have to be pulled from kernel.org?
<rtg> melodie, git log --pretty=oneline -- ubuntu/aufs
<rtg> fd8c5e7da57c4ad14c3baecd1a632d96ba797902 UBUNTU: ubuntu: AUFS -- update to 75dbb997b5812e16771bec20e92449ba0b1705d9
<rtg> d4fce216bb3b0d1df7ea47a57ae7ad8c24adda8a UBUNTU: ubuntu: AUFS -- update to 7b136a27b021da9010d8b6c101939dd298e46be7
<rtg> a1ef98765934f7679c095d274185dea74c211799 UBUNTU: ubuntu: AUFS (no-squash): basic framework and update machinary
<rtg> melodie, I'm pretty sure all of the info is in the commit log
<melodie> oh so?
<rtg> it all comes from 'git://aufs.git.sourceforge.net/gitroot/aufs/aufs3-standalone.git'
<melodie> we might need some help, I'm not the one who compiled the kernel for which I'm looking for the information, but first I'll transmit what you just told me as is
<melodie> rtg I just transmitted it right now from there : http://pastebin.com/5xLYdbaU
<melodie> and I thank you very much
<rtg> melodie, is this related to a Launchpad bug ?
<melodie> rtg not at all, it's related to phillw trying to provide a non pae kernel for non official spinoffs. His kernel does not boot in my isos :)
<msx> Hi everyone, I'm wondering about the naming conventions for packages: can a package name have upper-case carachters or it must contain only lower-case ones?
<msx> Oops, sorry, wrong channel!
#ubuntu-kernel 2014-06-21
<CTSae> could someone help me determine which kernel I should be running on a linux VM box?
<apw> CTSae, i think you need to be more specific
<CTSae> I've figured it out now ; )
<apw> ok good
#ubuntu-kernel 2015-06-15
<caribou> Hi, any reason why I cannot locate the dbgsym package for linux-image-3.13.0-45-generic ?
<caribou> This seems like a valid official kernel
<apw> caribou, where have you looked for it
<caribou> apw: I've setup the ddebs.ubuntu.com archives & it doesn't find it
<caribou> apw: that's usually where I go to get them & what is documented in the Crashdump Recipe wiki
<apw> caribou, you mean -45 or -54 ?
<caribou> apw: -45
<apw> caribou, the old ones always go missing don't they ?
<apw> thats -10 behind tip
<apw> i thought the STS guys kept an archive though
<caribou> apw: I thought it had been fixed before Trusty
<caribou> apw: used to be me :-/
<apw> they had been fixed to be generate, they still get cleared out when they are unpublished
<apw> that said, going forward i beleive they are in the librarian
<apw> and therefore permenant until the series is archived
<apw> but i odubt it goes back that far
<caribou> well, that's a trusty kernel & the other 3.13 are there
<caribou> apw: -32 & -53 are there. Looks like this one took a summer vacation
<caribou> arges: do you still archive the ddebs ?
<arges> caribou: which one do you need
<caribou> arges: linux-image-3.13.0-45-generic
<caribou> arges: otherwise I'll try to rebuild it
<arges> caribou: i do not have it unfortunately
<caribou> arges: that's fine
<apw> arges, your job to suck them down is automated right?  which kinda implies we never had it
<apw> i am glad that is resolved going forward
<arges> apw: it appears my cronjob was not running. so I'm fixin gthat now
<caribou> arges: remember the requirement for rebuilding them correctly ? 
<caribou> arges: afair, needed to rebuild using LP builders
<arges> caribou: i thought a local build would work too. Do you need to do crashdump analysis?
<caribou> arges: yes
<caribou> arges: yes = crashdump
<apw> caribou, you have to incant at the build to make it make ddebs at all, but you can make them locally
<arges> skipdbg=false
<arges> fakeroot debian/rules binary-generic skipdbg=false
<caribou> arges: apw: ok I'll try a local build & see what I get
<arges> and i'll make sure these scripts re-run
<apw> you have to say something on the build line to ensure you get a ddeb
<arges> apw: so wily+ will be backed up in launchpad librarian?
<apw> it does not make them by default for a local build
<apw> arges, i don't think it is pocket specific, i think it is all builds from "a little while back" onward
<apw> you can see the ddebs listed at least
<arges> apw: ah, glad its not pocket specific
<arges> i'll re-run the mirror script fwiw then, and hopefully the re-build works
<jdstrand> ogasawara: hey, fyi bug #1465322. I just noticed and filed this and was able to reproduce in VM and live system. I don't know the impact of the regression
<ubot5> bug 1465322 in linux (Ubuntu) "regression: "df: `/sys/kernel/debug': Function not implemented" with 3.2.0-85.122" [Undecided,Confirmed] https://launchpad.net/bugs/1465322
<ogasawara> jdstrand: ack, I'll turn jsalisbury loose on it
<jsalisbury> ogasawara, jdstrand I'll dig into it
<jdstrand> thanks
<rtg> jsalisbury, I see at least 2 possibilities for bug #1465322, "kdb: fix incorrect counts in KDB summary command output" and "debugfs: leave freeing a symlink body until inode eviction"
<ubot5> bug 1465322 in linux (Ubuntu) "regression: "df: `/sys/kernel/debug': Function not implemented" with 3.2.0-85.122" [High,In progress] https://launchpad.net/bugs/1465322
<jsalisbury> rtg, great.  I'll build a test kernel with those two commits reverted for jdstrand to test, while I setup a Precise VM and reproduce it
<jsalisbury> jdstrand, Do you happen to know if this is only happening on 3.2 kernels?
<Kano> hi, for the nightly kernels can you add kmod alternative depends? module-init-tools is just a meta package anymore on Debian
<infinity> A transitional package, not a metapackage.
#ubuntu-kernel 2015-06-16
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 23rd, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
<Guest35492> Anyone knows about th recent changes to 3.2.0-86.123 ?
<infinity> Guest35492: Launchpad knows: http://launchpadlibrarian.net/209149320/linux_3.2.0-85.122_3.2.0-86.123.diff.gz
<Guest35492> Ouch, there will be a diff of the codelines, isn't it ?
<Guest35492> I'm not a programmer :-(
<Guest35492> Isn't there a "short story" of the changes ?
<infinity> Guest35492: Yes, in the changelog.
<infinity> Guest35492: /usr/share/doc/linux-image-$version/changelog.Debian.gz
#ubuntu-kernel 2015-06-17
<smoser> is it declared / decided what major.minor wily will be ?
<rtg> smoser, likely 4.2
<rtg> 99% sure
<smoser> rtg, thank you. 
<smoser> rtg, silly related qestion
<smoser> uname will show 4.2.0 ?
<smoser> is .0 basically always now ? /me remembers this sort of
<rtg> smoser, yup
<rtg> smoser, /proc/version_signature shows the stable release version, e.g., 3.13.11-ckt20
<infinity> smoser: To be fair, it's always been like this.  As in, our uname never showed patchlevel.
<infinity> smoser: It's just that it got a bit wonky when upstream switched from 3-part (plus pl) to 2-part (plus pl), but downstreams were scared to death (rightly so) of userspace exploding with a 2-part uname, so we tacked a fake .0 to the end of it. :P
<smoser> that wasn't really what i was asking about.
<smoser> more the change from 2.6.18 where major.minor.micro meant one thing to 3.19 where micro essentially is gone.
<infinity> smoser: It's actually minor that's gone from that scheme.
<infinity> If one wants to be a pedant.
<infinity> But yeah, our workaround is confusing.
<infinity> And probably worth revisiting some day, but I don't think anyone digs the task of "test all userspace software ever" to see if we can get away with just reporting "4.2".
#ubuntu-kernel 2015-06-18
<ogra_> cking, hey ... so i found the issue of my overheating laptop ... (though it still is beyond me why it started *exactly* with the upgrade to vivid) ... obviously a 1cm thick filth blob at the fan intake isnt really helping to cool the CPU ... 
<ogra_> (took me a week to get the right wrench to even open that XPS13 properl)
<ogra_> i havent tried switching back to thermald control yet, but i guess it will be fine
<ogra_> read: i think we can close the bug
<cking> ogra_, ah, it should be fine w/o thermald if you have cleaned out the fan
<cking> http://smackerelofopinion.blogspot.co.uk/2010/09/hot-laptop.html
<cking> it's happened to us all
<ogra_> well, the thing is that the dveic ebehaved totally fine before the upgrade ... 
<ogra_> uh, my typing ... 
<cking> ogra_, vivid works hard to make sure you CPU does not cook, so I think the scaling was trying to do this and not working well because the thermal gradients were not as it expected
<ogra_> but yeah, my fan intake looked similar :)
<ogra_> ah !
<cking> the passive cooling expects some kind of heating/cooling characteristic, but if the CPU is on fire it will just ramp down fast then give you all sorts of odd up/down speed changes
<ogra_> yeah, now i understand 
<cking> i'm glad it resolved it.  i7's are probably the worst headache as they dump a lot of heat very quickly into the thermal zone
<ogra_> yeah, and the old XPS13 having a teeny weeny fan and heatpipies going everywhere through the case doesnt really help the case :)
<cking> ogra_, i guess manufacturers need to run stress-ng to see if their laptop thermal designs are OK ;-)
<ogra_> well, i'm sure it is ok if it comes out of the factory ... they should be obligated to do tests after 1-2 years of usage ;)
<cking> ogra_, care to update bug 1460399 with your findings, I think we should close that one now :-)
<ubot5> bug 1460399 in linux (Ubuntu Vivid) "ivybridge system gets completely unusable after upgrade to vivid thanks to defaulting to immature intel_pstate driver" [High,Confirmed] https://launchpad.net/bugs/1460399
<ogra_> cking, yeah, closing it (there was someone else moaning in a comment, i guess he should open a new one)
<cking> definitely
#ubuntu-kernel 2015-06-21
<SturmFlut> Does anybody here know about the kernels we run on Ubuntu phones? I am trying to figure out the content of /proc/timer_stats and there is an oddity which doesn't seem to show up on my desktop
<melodie> hi
<melodie> I need to ask an information to the ubuntu kernel packagers and devs : in Vivid the zram module is loaded by default, even though it's configured as module and not hard in the configuration of the kernel. And there is a module having for name ZRAM_LZA_COMPRESS default loaded (y). It seems that the zram-lza-compress module would call zram to be default loaded if zram isn't blacklisted. My question is this: is my statement true? Am I right to 
<melodie> think the zram-lza-compress is what triggers zram to be loaded at boot time?
<melodie> this is my actual kernel:
<melodie> 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<melodie> and I have noticed this behavior in all former kernels since I moved to Vivid.
<melodie> so what is it that really happens here,
<melodie> ?
<melodie> it's about bug #1449678 except that something was changed in the original description : "non english locales" was added by some folk, no idea why, I think it's unrelated
<ubot5> bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed] https://launchpad.net/bugs/1449678
<melodie> while I'm here, the fix doesn't work
<melodie> can't work is my guess
<melodie> except if zram is prior blacklisted in the /etc/modules.d/blacklist.conf ;-)
<melodie> I think I am right, the kernel is faulty.
<melodie> [melodie@bento64:~]$ sudo systemctl status -l zram-config.service
<melodie> â zram-config.service - Initializes zram swaping
<melodie>    Loaded: loaded (/lib/systemd/system/zram-config.service; enabled; vendor preset: enabled)
<melodie>    Active: active (exited) since dim. 2015-06-21 18:33:11 CEST; 9min ago
<melodie>   Process: 4906 ExecStart=/usr/bin/init-zram-swapping (code=exited, status=0/SUCCESS)
<melodie>  Main PID: 4906 (code=exited, status=0/SUCCESS)
<melodie> juin 21 18:33:11 bento64 systemd[1]: Starting Initializes zram swaping...
<melodie> juin 21 18:33:11 bento64 init-zram-swapping[4906]: Setting up swapspace version 1, size = 947216 KiB
<melodie> juin 21 18:33:11 bento64 init-zram-swapping[4906]: pas d'Ã©tiquette, UUID=6c74759b-83cd-47a1-b911-f5242c125979
<melodie> juin 21 18:33:11 bento64 init-zram-swapping[4906]: Setting up swapspace version 1, size = 947216 KiB
<melodie> juin 21 18:33:11 bento64 init-zram-swapping[4906]: pas d'Ã©tiquette, UUID=3e6fce71-7773-40e4-9dcb-3dfe509ec23d
<melodie> juin 21 18:33:11 bento64 systemd[1]: Started Initializes zram swaping.
<melodie> [melodie@bento64:~]$ sudo systemctl restart zram-config
<melodie> [melodie@bento64:~]$ sudo systemctl status -l zram-config.service
<melodie> â zram-config.service - Initializes zram swaping
<melodie>    Loaded: loaded (/lib/systemd/system/zram-config.service; enabled; vendor preset: enabled)
<melodie>    Active: active (exited) since dim. 2015-06-21 18:43:44 CEST; 4s ago
<melodie>   Process: 4985 ExecStop=/usr/bin/end-zram-swapping (code=exited, status=0/SUCCESS)
<melodie>   Process: 4996 ExecStart=/usr/bin/init-zram-swapping (code=exited, status=0/SUCCESS)
<melodie>  Main PID: 4996 (code=exited, status=0/SUCCESS)
<melodie> juin 21 18:43:44 bento64 systemd[1]: Starting Initializes zram swaping...
<melodie> juin 21 18:43:44 bento64 init-zram-swapping[4996]: Setting up swapspace version 1, size = 947216 KiB
<melodie> juin 21 18:43:44 bento64 init-zram-swapping[4996]: pas d'Ã©tiquette, UUID=13e90b6a-1f85-40d3-b468-a77332c14f97
<melodie> juin 21 18:43:44 bento64 init-zram-swapping[4996]: Setting up swapspace version 1, size = 947216 KiB
<melodie> juin 21 18:43:44 bento64 init-zram-swapping[4996]: pas d'Ã©tiquette, UUID=1864b236-4b6f-433d-b3e3-5ae7c3b8a88a
<melodie> juin 21 18:43:4
<melodie> omg
<melodie> sorry wrong buffer. :-/
<melodie> https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1449678/comments/12
<ubot5> Launchpad bug 1449678 in zram-config (Ubuntu Vivid) "(Vivid) zram-config 0.3 Job for zram-config.service failed" [High,Fix committed]
<melodie> well the fix is yet to be committed!
<melodie> it has to be produced first
#ubuntu-kernel 2016-06-20
<Pray3r> Hello, I want to test the kernel(http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc3-yakkety/) on my ubuntu system, but I do not find this kernel's dbgsym package. Could you tell me where it is?
<apw> xnox, hey i hear that you have a fix for the python3 launchpadlib Keyerror business with oauth ?
<henrix> apw: i believe you're looking for this: https://code.launchpad.net/~xnox/launchpadlib/fix-1471927/+merge/264480
<henrix> (i had the same prob last week)
<apw> henrix, that does the trick, xnox who needs a kick to get that out
<dsmythies> The mainline PPA builds for kernel 4.7-rc4 failed, permissions issues. Is there anyone here willing to get the builds done so the .debs are available? Reference: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc4-yakkety/
<apw> dsmythies, hmmm
<apw> dsmythies, that might be happier
<dsmythies> apw, thanks very much.
#ubuntu-kernel 2016-06-21
<xnox> apw, right and last week i was like "somebody tell me if this fixes it for them or not"
<xnox> =)
<apw> xnox, this fixes it for me :)
<xnox> =)
<ricotz> apw, hi, you might be interested in https://paste.debian.net/plain/740703
<ricotz> (full log at https://launchpadlibrarian.net/266795156/buildlog_ubuntu-yakkety-amd64.firefox_48.0~b2+build1-0ubuntu0.16.10.1_BUILDING.txt.gz)
<ricotz> rtg, hi, or you ;) ^
<apw> ricotz, i think thats something that broke in a stable update, and i believe we are respinning at the moment for this
<ricotz> apw, I see, the xenial build seems to work while it uses 4.4.0-24.43 instead of 4.4.0-25.44 
<ricotz> apw, I guess this only affects x86(_64)?
<apw> ricotz, right ... the fix for a cve introduced the issue, and we have a fix on deck for that i believe
<ricotz> apw, is there an eta or a bug report to follow?
<apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1592930
<ubot5> Launchpad bug 1592930 in linux (Ubuntu) "failures building userspace packages that include ethtool.h" [Medium,Triaged]
<apw> ricotz, ^ that appears to be the bug we are tracking under
<ricotz> apw, alright
<apw> ricotz, i believe the only affected version is in xenial-proposed and that one will replaced as soon as the new one builds
<apw> ricotz, and indeed it may alreday be built and pending review to copy, i'll check next
<ricotz> ok, yakkety too of course
<apw> ricotz, yes it gets copied there too
<ricotz> thanks
<kees> when/where are the kernel team meetings these days? it seems https://wiki.ubuntu.com/KernelTeam/Meeting is very out of date :)
<apw> kees, we don't have scheduled ones any more, noone came for 2 years, so we switched to a newsletter form
<apw> kees, do feel free to make free with this channel to start discussions any time
<kees> apw: ah! okay. well, in that case, I'd like to discuss a packaging/building changes for future kernels
<kees> or rather, give a heads-up.
<kees> I'm in the process of merging support for gcc-plugins into the upstream kernel
<kees> this means a few things:
<kees> - building the kernel with gcc-plugin-enabled features will require the gcc-N-plugin-dev package added
<kees> - the kernel-headers package will either need to depend on a new binary package, or will need to become a binary package
<kees> - said binary package will need to include the .so files that are the built gcc plugins from the kernel build
<kees> (so that out-of-tree builds can run the plugins)
<kees> Does any of this sound terrible, and either way, is there anything I can do to help with it?
<apw> the headers are already binary arch/flavour specific, we include some kind of .so in the powerpc ones for the same reason; so that sounds tractible
<kees> oh, excellent. well that's one problem down. ;)
<apw> the first is just new build-depends if i am reading things right
<kees> right, that should be trivial
<kees> it was the "carry .so files in the headers package" that seemed to me to be the "worst" :)
<apw> so overall that sounds like its mostly about knowing what to include in the headers packages
<kees> but you're already doing that, so yay
<apw> i beleieve we include the config binary in them for instance so we have to be binary
<kees> yeah, I'm going to try to figure out what it looks like for out-of-tree builds. I assume some symlinks or something need to be added/tweaked/etc
<apw> when is all this slated to land ?
<apw> yeah i assume it all lands linked out of /lib/<version>/build/lib or something
<kees> the first plugin should be landing in 4.8. more should follow
<apw> lib/modules/<version>
<apw> damn so we will likley have to figure this out for yakkety then, could you copy me on the patches as and when
<kees> I think it would end up being /lib/modules/VER/build/scripts/gcc-plugins/ right now, but yeah
<kees> sure thing
<apw> ok so we include scripts already, so it might just happen "naturally" but we clearly need to track
 * apw dumps this info in our "things to fear" list
<apw> kees, and thanks for the heads up
<kees> yeah, and I think we'll want to first plug ("latent_entropy") enabled by default on x86, arm, and arm64 at least.
<kees> sure thing!
<kees> s/want to/want the/
 * apw hopes the patches will make it clear what is going on :)
<kees> ... I'm hoping so ... but ... the kbuild parts are dark magick that I am only now starting to understand.
<kees> and the plugins themselves are compiler dark magick... but they have a lot of comments.
<apw> yeah kbuild is deeply arcane black magic, i am supprised it is legal
<kees> hehe
<kees> (in related news, can't this spl thing be a pre-built dependency, it takes forever to run its configure script in the kernel build)
<cyphermox> apw: hey
<cyphermox> did you have a look at the testing matrix for secure boot? or is it all just for rtg? 
<apw> cyphermox, i cast an eye over it, i've not got to do anything aboutit yet
<cyphermox> apw: fair enough
#ubuntu-kernel 2016-06-22
<rtg> cyphermox, there is a full suite of signed module enforcement kernels at ppa:canonical-kernel-team/unstable. Lemme know if there are any gaps.
<cyphermox> rtg: thanks. have you taken a look at the test matrix?
<rtg> cyphermox, have you told me where it is ? if so, I've forgotten
<cyphermox> rtg: I sent it by email, but here it is: https://docs.google.com/spreadsheets/d/1GbyQDb4-sRv7OlIpbISiwVJ2ARHP3AkG2HbPTRk7p-E/edit#gid=0
<cyphermox> first page is the matrix; second page is kernel test cases, last page (still needs to be fleshed out) is the userland-side tests
<cyphermox> I set up scripts to make it easy to spin up VMs with the right keys and Secure Boot enabled
<cyphermox> rtg: I'd still like to know if the test cases I wrote up there match up with however you were testing things on your side so far
<rtg> cyphermox, k, lemme look through them
<rtg> cyphermox, I actually used fwts-dkms, but bbswitch ought to produce the same result wrt secure boot
<cyphermox> right, I only picked that one because I knew this one built
<cyphermox> rtg: trusty lts-wily fails validation here -- everything looks as though SB is enabled; yet it loads the module
<rtg> cyphermox, ok
<cyphermox> is there anything I can check?
<cyphermox>  /proc/sys/kernel/secure_boot  is 0, and so is moksbstate_disabled 
<rtg> cyphermox, it should be working. I'll check in a  bit
<cyphermox> could it be that the build I got is one that doesn't enforce?
<rtg> cyphermox, oh, secure_boot shuold be 1
<cyphermox> right, it should
<cyphermox> but the firmware does show SecureBoot-(UUID) is 6 0 0 0 1
<cyphermox> ie. Secure Boot is enabled.
<rtg> cyphermox, anything in dmesg ?
<cyphermox> what should I look for?
<rtg> dmesg|grep Secure
<cyphermox> nope
<rtg> hmm. ok, gimme a bit to check it out
<cyphermox> I suppose it may be that MokSBState is still set wrong, but the kernel should have noticed and logged something
<rtg> cyphermox, yes, it should say that SB is disabled because MOKSBState is non-zero
<cyphermox> well, I don't know whether MokSBState is zero or not
<cyphermox> Are you checking the variable as MOKSBState or MokSBState? in case it's case-sensitive
<rtg> MOKSBState
<cyphermox> should be "MokSBState"
<cyphermox> but I'm not sure if that's suppose to be case-sensitive.
<rtg> huh
<cyphermox> I think the variable would *not* be there at all if SB is enabled
<cyphermox> if I'm to follow efivarfs code, looks like it might be case-sensitive, maybe that's the issue
<rtg> certainly couldn't hurt
<cyphermox> rtg: you're looking into whether this might be the issue?
<rtg> cyphermox, soon
<rtg> trying to wrap up a rebase
<cyphermox> what worries me is that it looked like xenial did things correctly, but lts-xenial clearly doesn't
<cyphermox> ie. on xenial if sb is enabled, modules are not loaded
<rtg> you said wily I thought
<cyphermox> oh, right
<cyphermox> but it's irrelevant, they should be using pretty much the same code for the SB magic.
<rtg> cyphermox, is there a difference in behavior between wily and lts-wily ?
<cyphermox> I will be able to tell you later (currently on a trusty install)
<cyphermox> I'm writing a xenial image to USB now, and upgrading the trusty machine to lts-xenial
<cyphermox> err, I mean writing wily to usb
<cyphermox> too many releases
<cyphermox> hrm, well lts-xenial on trusty is also letting things through
<cyphermox> ok, looks like the lts-wily kernel is looking for the right variable
<rtg> cyphermox, case likely isn't the culprit (unless this is wrong):
<rtg> arch/x86/boot/compressed/eboot.c:                               L"MokSBState", &var_guid, &attr, &datasize,
<rtg> still getting my trusty instance spooled up
<cyphermox> right, that's just what I was saying
<cyphermox> and anyway, the kernel seems to think SecureBoot is off
<cyphermox> except od -t u1 -An /sys/firmware/efi/efivars/SecureBoot-* shows it's set to 1
<cyphermox> going to try to reset everything in the BIOS to see
<cyphermox> rtg: I don't know what to make of this, it looks at though none of the code is working -- the writing of the files in /proc should happen correctly regardless of whether enforcing is done or not, and  if enforcing is enabled, we should see something other than a sdhci message in dmesg | grep Secure
<cyphermox> ie. looks like the enforcing isn't being enabled either.
<cyphermox> source for lts-wily has 
<cyphermox> arch/x86/kernel/setup.c:#ifdef CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE
<cyphermox> debian/changelog:  * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
<cyphermox> debian.master/config/config.common.ubuntu:CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
<cyphermox> debian.master/changelog:  * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
<cyphermox> debian.wily/config/config.common.ubuntu:CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
<cyphermox> debian.wily/changelog:  * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
<cyphermox> not sure whether that's all it should have or if there should be a debian.trusty directory
<rtg> cyphermox, looks like enforcement is enabled to me
<cyphermox> except that still won't fix the writing files to /proc part.
<cyphermox> right
<rtg> debian.wily/config/config.common.ubuntu:CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
<cyphermox> I don't know, but something is clearly broken
<cyphermox> that's for trusty's lts-wily though, is it correct for it to be set in a debian.wily directory?
<cyphermox> I'm grasping at straws, I have no idea how your build process works.
<rtg> cyphermox, yes, that looks correct.
<cyphermox> very well
<cyphermox> well, moving on to testing wily itself now, and I'll leave the debugging in your hands.
<rtg> cyphermox, looks like trusty isn't right either.
<rtg> rtg@ubuntu:~$ dmesg|grep Secure
<rtg> [    0.000000] Secure boot enabled
<rtg> rtg@ubuntu:~$ cat /proc/sys/kernel/secure_boot 
<rtg> 0
<rtg> rtg@ubuntu:~$ cat /proc/sys/kernel/moksbstate_disabled 
<rtg> 0
<cyphermox> that's what I was just saying
<cyphermox> except I don't even get the Secure boot enabled message
<cyphermox> Secure Boot is most definitely enabled on my test machine
<rtg> cyphermox, in my case it means the user keys are enrolled correctly, but the secure boot state isn't getting save 
<rtg> saved*
<rtg> ok, gimme a bit and I'll find it
<rtg> cyphermox, should I expect the MOK util enable/disable dialog when installing a DKMS package on Trusty ?
<cyphermox> if you're using my PPA too, yes
<rtg> cyphermox, oh, I'm not. that'll make a difference
<cyphermox> yeah, and you should take care when you install as it will removed grub2-signed; and change the efi BootEntry
<rtg> cyphermox, what is your PPA ?
<cyphermox> I don't think the userland should make much of a difference for testing the kernel bits though
<cyphermox> ppa:cyphermox/efi
<rtg> I might as well test against it
<rtg> cyphermox, I re-uploaded trusty. lts-utopic looks like it is working OK
<cyphermox> ok, so to work around the fact that things are signed by my PPA key rather than the Canonical key, you'll want to go download http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/uefi/grub2-amd64/current/grubx64.efi.signed
<cyphermox> you need to replace /boot/efi/EFI/ubuntu/grubx64.efi with that file.
<cyphermox> (so grub is correctly signed)
<rtg> cyphermox, can't I just re-sign using my local keys ?
<cyphermox> and also run:  sudo efibootmgr -b *whatever ubuntu is at, 0018 for instance, depends what efibootmgr -v says*; sudo efibootmgr -c -L ubuntu -l \\EFI\\ubuntu\\shimx64.efi
<cyphermox> rtg: well, sure, you can resign with your keys if you want
<rtg> cyphermox, that is a lot easier in my setup
<cyphermox> the efibootmgr commands still probably will need to be done though
<cyphermox> I'll fix that shortly
<cyphermox> rtg: I don't know, did you reupload lts-utopic earlier?
<rtg> whoops, forgot the efibootmgr command.
<cyphermox> oh, I didn't test lts-utopic I think
<rtg> cyphermox, trusty is the only kernel I've re-uploaded
<cking> bjf, what's the story on the arm64 wily boot saga?
<bjf> cking, checking
<cyphermox> rtg: have you looked at lts-wily though? doesn't look to me like the issue is the same at all
<cyphermox> ie. there is that setbit call there.
<rtg> cyphermox, still recovering from your grub package update. I think I'll not do that again.
<cyphermox> you should be able to disable SB in BIOS to get booting
<cyphermox> rtg: can you ping me as soon as you have things working correctly for secure_boot and moksbstate_disabled; so I know where we're at?
<rtg> cyphermox, I'll be testing lts-vivid here in a sec
<cyphermox> rtg: could we focus first and foremost on having trusty, lts-wily, lts-xenial, and xenial working correctly?
<rtg> working on it
<cyphermox> since lts-wily is what's installed by default if you install from 14.04.4.
<rtg> cyphermox, ok, I'm comfortable that all the LTS kernels work. 
<cyphermox> rtg: ok; are things in the ppa?
<rtg> cyphermox, yeah, the trusty kernel is still building, but I'm pretty sure it'll be OK
<rtg> I'm gonna work on vivid/wily just be be sure those kernels work as well, but they should since the LTS kernels are built from identical sources
<cyphermox> well, they will only work if you just did some code change, it was very obviously broken
<rtg> cyphermox, indeed. vivid seems to work just fine.
<cyphermox> what do you mean by "vivid"?
<rtg> cyphermox, 15.04 
<cyphermox> 15.04 is EOL, we don't care about it.
<rtg> cyphermox, lts-vivid is still built from the vivid kernel
<cyphermox> I'd really just like to see either trusty's linux-image-generic or linux-image-lts-wily-generic working so that I can feel like we did some kind of progress today
<rtg> lts-wily works for me
<cyphermox> can you build all the kernels and signed kernels in the PPA so we can do one last pass tomorrow and be good to do the SRUs ?
<rtg> cyphermox, they are already built.
<rtg> I'm not sure what you mean
<cyphermox> what I mean is that to do proper testing, you should be able to add the PPA; then upgrade, and things would just work.
<rtg> cyphermox, that is pretty much waht I've been doing
<cyphermox> and re-signing stuff? or doing some other steps?
<rtg> cyphermox, oh, I've had to re-sign but I think that is acceptable
<rtg> I can't build an archive signed kernel in a PPA anyways
<cyphermox> I do to, since you're building in a PPA; but any other steps would show that the process is broken
<rtg> signing the kernel after update is the only "extra" step
<cyphermox> fair enough
<cyphermox> then let me finish this update and I'll check lts-wily again
<rtg> cyphermox, I'm about EOD
<cyphermox> please wait so you can know whether this is still exploding
<cyphermox> 2 minutes.
<cyphermox> I'm still getting secure_boot == 0 on lts-wily.
<cyphermox> oh, wait
<cyphermox> that's without re-signing, hold on
<rtg> cyphermox, is it signed ?
<rtg> never mind
<cyphermox> looks fine, so to you we're good to SRU this crap?
<rtg> cyphermox, all of the kernel patches have been accepted and applied. they'll appear in the next SRU cycle.
<cyphermox> and the corrolary to this is "can we upload it all to -proposed queues tomorrow rather than friday?"
<rtg> cyphermox, for that you will have to coordinate with bjf or kamal
<cyphermox> well, if it's automated stuff that will just land if the patches are accepted and whatnot and merged in the right places, then that's fine
<rtg> cyphermox, I dare not get in the middle of the stable team process :)
<cyphermox> it doesn't have to be tomorrow; I'm just curious because friday is a national holiday for me.
<rtg> yes, they are all on the master-next branch
<cyphermox> very well
<cyphermox> for all the relevant releases?
<rtg> cyphermox, I think kamal packages everything beginning on Monday
<cyphermox> does that include precise too?
<cyphermox> ok
<rtg> yup
<kamal> rtg, cyphermox: yes, we'll start a new cycle (for all of them) on Monday
<cyphermox> precise is with enforcing disabled iirc?
<rtg> cyphermox, yes, enforcement is disabled in lts-trusty (i.e., precise)
<cyphermox> ok
<cyphermox> well, sounds like we're good then, thanks!
<rtg> cyphermox, yup, cheers.
#ubuntu-kernel 2016-06-23
<sam_yan> Is there some project or work to tuning the multi-core?
<apw> santoshmahto, 
<apw> bah sorry tab fail
<sam_yan> ?
<apw> sam_yan, there is cirtianly wrk going on upstream on numa and multi-core and the relationship between
<apw> which trusty kernel, GA or one of the HWE kernels ?
<fish_> the trusty-updates installer kernel is 3.13.0-85-generic
<apw> ok so the GA kernel
<fish_> so that's what I would need the module for but I'm also fine with using another kernel which has this module available.
 * apw looks
<fish_> http://packages.ubuntu.com/search?searchon=contents&keywords=pm80xx.ko&mode=exactfilename&suite=trusty-updates&arch=any
<fish_> the only 3.13.0-85 is /lib/modules/3.13.0-85-powerpc-e500/kernel/drivers/scsi/pm8001/pm80xx.ko
<fish_> but maybe the kernel module is called diffrently now
<apw> well its unlikely to be a differnt name in the two architectures
<fish_> it's unlikely that a raid controller driver is available for ppc but not amd64 I'd say ;)
<fish_> so.. who knows
<apw> indeed
<apw> that driver looks to be enabled for all architectures
<apw> that have pci and scsi
<apw> debian.master/abi/3.13.0-87.133/amd64/generic.modules:pm80xx
<apw> and the module is a module for amd64
<apw> crap launchpad is in a heap
<apw> so i can't get the packages to confirm
<fish_> it's possible that the module was introduced around that time. I'm pretty sure we had to use a external/dkms kernel modul in the past
<apw> dunno but it looks to be in the version you are asking about
<apw> but i cannotdownload actual binaries right now to confirm
<apw> (this is from the info in the source tree)
<fish_> apw: hrm.. let see, maybe packages.ubuntu.com is just wrong
<fish_> apw: nope: dpkg -L linux-image-3.13.0-85-generic|grep pm80xx
<apw> have you looked in linux-image-extra-...
<fish_> ah right, let me check
<fish_> apw: oh! yes, it's there.. 
<fish_> apw: but why is it missing from packages.ubuntu.com?
<fish_> apw: okay now maybe there is also a better way to include that in the installer than me extracting the initrd manually and adding the module..?
<apw> fish_, you are looking at linux-image on p.u.c perhaps
<fish_> apw: no, I searched for all packages including pm80xx.ko
<apw> fish_, sounds like that should be in the disk udeb, and to fix that weneed a bug
<apw> file a bug against the kernel "ubuntu-bug linux" and put that detail in there
<fish_> okay, then I'll fill a bug
<apw> when you have a bug, let me know the number here
<fish_> kk
<apw> but ... that won't fix existing installer images
<apw> so if we fix it "now" we should be able to fix it in the next point release though
<fish_> apw: are there something like nightlies for the installer?
<apw> there will be soon if not, as we are coming up to a a release
<fish_> launchpad has still issues though
<apw> yep a lot of infrastucture is sick right now, many people are running about
<fish_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1595628
<ubot5> Launchpad bug 1595628 in linux (Ubuntu) "disk udeb should include pm80xx" [Undecided,New]
<apw> kamal, ^ that one we prolly want to ensure is fixed in trusty and xenial kernels this cycle
<apw> (so you might want to poke me if you haven't had a patch for that before you close up the releases)
<kamal> apw, last day for commits will be tomorrow, so . . .  poke!
<fish_> apw: a minor note: the brad-figg bot says "please add a comment stating that fact and change the bug status to 'Confirmed'." where the status description of confirmed says "Verified by someone other than the reporter.
<apw> fish_, yeah don't worry about that, just move it confirmed
<fish_> I've set it to confirmed but this could confuse people and might (or might not) be trivial to fix :)
<apw> fish_, the people who consume the bug states know that they are a little odd for kernel bugs
<apw> fish_, we will not be confused by it being confirmed
<fish_> apw: fine with me, but from a UI perspective you tell your users two things that are contradictory. I know that you added this bot and what it says weights more than the those labels, others might not. just a though :)
<fish_> anyway, thanks a lot for your help :)
<apw> fish_, meh very few people read anything even if it is flashing
<fish_> fair enough :)
<apw> fish_, confirmed is mean to mean this is affecting more than one user, but we cheat a little
<apw> else we keep spamming you for logs :)
<apw> there you go i have moved it to triaged, as it has everything we need to fix it
<apw> now it is in a state which matches the meaning
<fish_> yay :)
<apw> stgraber, hey ... when are we going to get the lxc tests fixed in yakkety ... i am concerned about the level of change we are about to dump in there when lxc is totally untested
<stgraber> apw: uploading a new lxc which should skip the test on yakkety
<stgraber> http://paste.ubuntu.com/17763572/
<apw> stgraber, awsome thanks
<stgraber> well, skipping the test isn't exactly awesome, but yeah, it's going to be less crappy for you
<apw> stgraber, well if it doesn't work and always fails, that is worse than skipping
<apw> stgraber, as we just assume the failure is that test and ignore the results, and who knows what else is actually broken
<stgraber> yeah, I actually do read the adt test output usually to confirm it's just that test :)
#ubuntu-kernel 2016-06-24
<RAOF> Bah!
<RAOF> What's the sensible way to get a mainline kernel building on the -fPIC-all-the-things default yakkety gcc?
<i915> anybody know how the /proc/irq/xxx/  affinity_hint  and node files work? I get the rest of the files under /proc/irq quite important for controlling what cpu get what interrupts in a multiprocessor enviorment 
<i915> So curious on those 2 files node sounds like some cluster thing for cpu's affinity_hint not sure what the heck that is smp_affinity ,smp_affinity_list are quite important
<apw> i915, smp_affinity is literally a bitmap of whihc cpus can handle a specific incoming interrupt ... _list is that in human
<apw> RAOF, you need to apply the fix for -fpie to the main Makefile, which is what mainline-build-one does
<i915> I know this i am talking about affinity_hint  and node files?
<apw> oh your last line wasn't very clear
<i915> what are those 2 file for
<RAOF> apw: I found passing -fno-pic which makes it *almost* build. Where's mainline-build-one so I can steal?
<RAOF> Also, good morning and commiserations.
<RAOF> May your bees be extra comforting today.
<apw> RAOF, you don't want that really, you want to git log Makefile in yakkety and take the -fPIE patch there
<RAOF> Hm. I apparently haven't pulled yakkety in approximately 100MB worth of time.
<apw> i915, affinity_hint is a hint from the device driver as to where the irqs are best handled
<apw> i915, it appears to be set in specific drivers where that driver knows about the h/w
<apw> i915, node appears to be which numa node the device is associated, which i would interpret as meaning
<apw> i915, the nearest memory node for incoming/outgoing data
<RAOF> apw: I can't seem to find any relevant patch to Makefile in kernel.ubuntu.com/ubuntu/ubuntu-yakkety.git:master? That's where it's meant to be, right?
<apw> RAOF, UBUNTU: SAUCE: (no-up) disable -pie when gcc has it enabled by default
<apw> is the one i mean
<apw> c863674de4911d8fb7643d5dfe4e5063b052bfe5
<RAOF> I have clearly messed up my git somehow; I can see that commit, but not in the history of yakkety/master. Oh well.
<RAOF> Thanks!
<apw> RAOF, master-next is always better, beacuse raisons
<RAOF> I'll try to remember that in future.
<i915> anybody out there know much about the mei-me driver and what all this Management Engine Interface (Intel(R) MEI  stuff is good still don't get  what this host an Me interface is for. Seems like a remote management tool but whats the point we have so many why build it in as an LKM or something internal to the ubuntu kernel 
<apw> i915, the linux interface to the mei is all about letting the OS configure the remote management interfaces and the like
<apw> i915, the specific features are per chipset though so you would have to look at the chipset docs on what all you can change
<i915> ya doesn't seem like a major deal why not just remote desktop vnc over to the machine at that point or ssh over 
<apw> management interfaces are for when the machine is broken enough that those don't work
<i915> O i can kind of see in that case but 90% of the time you probably want to be physically there because the problem could be hardware related at that point or a complete shut down
<apw> with a management interface you don't have to be there, which machines the machine doesn't have to be where you are
<i915> And what happens if the mei-me driver gets cooked then your screwed anyway unless its built into the bios
<apw> the driver is not for operational purposes, those are independant, it is to allow configuration before failure
<i915> in which case your only cooked if the bios or computer is completely off even more rare
<i915> I don''t think i completely get it then is it for remoting in to fix a problem or shutting down gracefully with certain configurations?
<apw> the pysical device is for analysis and fixing remote, the kernel driver is to let the host
<apw> OS ocnfigure the device to define its actions and abilities
<i915> and what exactly is the purpose of the mei-me LKM driver if not for controlling the remote management process
<i915> So its like host machine your at issues commands to the target machine running mei-me LKM which sets the actions and abillities the target machine uses in case of  mei-me crashing or other really bad issues happening so the host can still remote 
<i915> there is got to be some fail safe with this so if the mei-me module crashes there still some default that allows one to remote manage it right. Do i have this right now?
<apw> i915, no you talk to those interfaces "remotely" usually over the network.  the interface locally is only use to configure the local device
<i915> And if i do then the management stuff is part of the bios or some fix place in memory that all computers have available for it
<apw> so you can cange config without rebooting into bios
<i915> Still your screwed if the NIC goes down
<apw> its a separate thing mostly hidden from the host
<apw> it uses the nic directly in a more reliable way
<i915> ok so this is to change bios settings without shutting down and F10/12,...etc
 * apw wanders off
<i915> bottom line if the NIC is down or no network connectivity then there is nothing you can do
<Larry__Tate> Is there any way to know when the next kernel release will occur?
<Larry__Tate> And if the fix for this bug will be included: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1437492
<ubot5> Launchpad bug 1437492 in linux (Debian) "boot stalls on USB detection errors" [Unknown,New]
<apw> Larry__Tate, there is an SRU announce list which has dates posted
<Larry__Tate> Ok, any chance you can point me to where that is located? I've searched but come up empty...
<apw> kamal, ^
<apw> Larry__Tate, that fix looks to be in 4.4.0-25.44 and later, so in this current cycle
<Larry__Tate> apw that is good news.
<kamal> Larry__Tate, apw: yes, that fix is in the kernel sitting in -proposed right now.  we do expect to release this coming Monday.
<Larry__Tate> Whew. That is good news. Thanks, kamal, apw!
<Larry__Tate> Just out of curiosity, is the only way to find a release date to scroll through the entire mailing list for the kernel team?
<Larry__Tate> Ah, never mind guys. I just saw that there was a specific list for announcements. Thanks again.
<i915> curious anybody know about this node file in /proc/irq i think it has to do with NUMA node but how is any of this different then SMP_affinity files ?
<apw> smp_affinity is about processor affinity, numa is about memory affinity
<apw> it is possible to have cpuless and memoryless nodes which are separate
<i915> so what does the /proc/irq/xxx/node tell you or modify for you that smp_affinity cann't?
<i915> it always has 0 for me
<apw> the memory affinity ... which is separate to cpu affinity
<i915> what what does memory affinity actually set or tell you i guess 
<i915> if its memory less or  cpu less what does that mean for an irq doesn't make much sense to me. nodes seem like the same thing as  a collection of cpu that you control with the bitmask
<apw> i915, a node is a collective object that contains 0 or more cpus and 0 or more memory
<apw> normally cards are assoicated with a numa domain, in a small machine there may well only be one (called 0)
<i915> by cards what do you mean mobo , memory cards , pci expresses ...?
<i915> and what does a node have to do with irq settings irq are only like hardware interrupts to a cpu so its only worth anything if cpu is associated to a node for an irq to be of any uses that and memory in the first place
<apw> i am talking about perpipheral cards, pci whatever.  an interrupt coming in needs to be routed to a cpu and the io it performs needs memory to land in.  these two affinities define where those two are
<apw> they will in the normal case be the same, but they may not
#ubuntu-kernel 2016-06-25
<i915> curious is if my HDD has a ext4 linux filesytem installed and i build a linux kernel from scratch to replace the old one with the ext4 file system driver as a built in not as a [M] can i just tell grub to uses this kernel without specifying a initrd ram disk or init paramters ?
<i915> Way i figure it is if the ext4 driver is built in grub boots it and the kernel has the ability to mount./find the init process right or am i missing something?
<i915> because i still have trouble getting linux kernels to boot without giving an oops or an error that somethings missing for it.
<i915> I can get a printk line out to the screen so i was be over looking somethings still. But in theory is this correct or is my logic forgetting something
<i915> ls /proc
#ubuntu-kernel 2016-06-26
<BleuBizarre> Hello guys :)
<BleuBizarre> I've a problem on my laptop and people adviced me to come ask help on IRC. So my problem is : I cannot enter my bios, it will give me a dark page and block my pc, and I've a grub rescue problem after trying to add ubuntu in dual boot to my win10 without having in a partition the boot folder with the vmlinuz so I cannot understand what to do. I can sometimes see my usb stick with the ls 
<BleuBizarre> and did find a way to be in a "linux way" doing this http://unix.stackexchange.com/questions/148041/recovering-from-grub-rescue-crash/148042#148042 but with my usb key and there were no boot folder in it... I don't mind losing all my data and any OS. I just want to be able to use my laptop again under any OS. 
<BleuBizarre> Thank you very much in advance :)
#ubuntu-kernel 2017-06-19
<alkisg> cking: hi, after longs hours of testing, the slow disk writes issue appears in all 32bit systems with 16+ gb ram. Now I'm trying to bisect it, and I'm at "after 15.04=3.19, before 15.10=4.2"
<alkisg> cking: did you manage to find something related that I could test, instead of bisecting?
<cking> alkisg, there have been some changes that I am aware of, I need to find the exact commit and and inform you of the kernel where the behaviour changed
<alkisg> E.g. would diff -R <3.19>/proc/sys/vm vs <4.2>/proc/sys/vm and playing with the settings there help?
<alkisg> Xenial with 3.19 works, /me reboots into xenial with 4.2 to verify it's broken there...
#ubuntu-kernel 2017-06-20
<manjo> sforshee, got your email about adding the git repo to the commit. The same applys for the RAS patches I sent out previously .. only the cover letter has the repo info.. did you want me to resubmit these with repo added? 
<sforshee> manjo: yes, please do
<manjo> sforshee, ok will submit both as a single pull req 
#ubuntu-kernel 2017-06-21
<dja> heya - after making a change in debian.master/config/annotations, what do I need to do to propagate the changes to the config.${ARCH}. and config.ubuntu.common files?
<apw> dja, the annotations are checks and balances against config*, those need to be updated directly
<dja> apw, so I've edited annotations directly
<dja> apw, how are the config.* files generated?
<dja> for context, I'm playing with xdp on powerpc, which works much better if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set, which happens if we switch from CPU_POWER7 to CPU_POWER8.
<dja> (IBM never shipped any production Power7 little-endian systems, so it's safe to make ppc64el Power8 only)
<apw> dja, the annotations will have no effect, they are only used in tree for checking those entries marked enforced, and otherwise it is used outside for review purposed
<apw> dja, to change config you need to change the entries in config.*
<dja> apw, so just to check I've correctly understood you - I need to directly edit debian.master/config/$ARCH/config.common.$ARCH?
<dja> I'm happy to do that, I just thought they were automatically generated somehow
<apw> the easiest way to override a value for a specific flavour, is to add it to the specific flavour names config file
<apw> then a fakeroot debian/rules updateconfig will rebalance the options into common if appropriate
<dja> apw, ah, thanks; I was trying to figure out what the updateconfig target did
<apw> the balanced configs are good for detecting change in review
<mamarley> This isn't directly Ubuntu-related, but I was hoping someone here might could point me in the right direction.  I have found a regression in the media/rc subsystem of the kernel on the 4.12 mainline builds.  I bisected it and filed a bug, but no-one is paying any attention to the bug.  Does anyone know who I might poke about this?
<mamarley> The commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8f4818895b3d7f34b3e5852bce77b3257a27ecc, if it matters.
#ubuntu-kernel 2017-06-22
<AceLan> cking: what kind of regression test should I do when submit SRU patch?
<cking> AceLan, for the "regression potential" part of a SRU, I just want to see a description of where you think regressions could possibly occur.  For fixes such as the PCI power savings, it would be useful to check this on a range of H/W just to see if it works on other devices apart from the ones you are targetting for the fix
<AceLan> cking: got it
<AceLan> cking: about his one "Fix can't disable USB port issue", it's a quirk for specific id, do I need to test it on other machine?
<smb> AceLan, the more a patch changes in code that potentially is run on a lot of HW, the more we get worried. Sorry for rejecting that one request for the second time, but it just feels like a lot of potential to go wrong
<cking> AceLan, I'm very anal about checking stuff, so some checking on other H/W when it comes to some types of fixes is always useful, even the simplest of fixes can sometimes catch one out
<cking> it's called the "can I sleep OK overnight with this fix" sanity check ;-)
<AceLan> smb: thanks for the comment, I'll try to gather more machines for testing
<smb> AceLan, yw, and again sorry for being a pain. But we try to avoid pain on our side ;)
<cking> well, pain on the user's side too if it goes bad
<xnox> in the ADT tests I have
<xnox> 12:18:01 ERROR| [stderr] FAIL: test_061_guard_page (__main__.KernelSecurityTest)
<xnox> 12:18:01 ERROR| [stderr] Userspace stack guard page exists (CVE-2010-2240)
<xnox> failing for kernel, on artful.
<xnox> is this test downloaded by autopkgtest from not the source package?
<xnox> because a package should be able to pass it's autopkgtest. And I don't see how that test is relevant for src:linux triggered by systemd.
<xnox> does it mean artful started to be vulnerable to CVE-2010-2240 ?
<smb> xnox, probably rather the test being confused by the new changes due to CVE-2017-1000364 and needing updates. I believe artful picked up the upstream commits which had some compat issues / regressions in corner cases
<xnox> smb, horum. I am no kernel person and the ADT failure looks scary to the uninitiated. Can the ADT test please be "fixed" to e.g. expectfail / skip that test for now, if it is not in fact regressing?
<xnox> but it seems that update to systemd is not causing this kernel regression.
<smb> xnox, no don't think so to the latter. and the former was was afaik already redirected at the sec team 
<Ivanovik> Hi, anyone know the right channel I need to head to if I need NIC internals information?
<Ivanovik> I'm more interested in the datasheet/electronic aspect of it.
<Ivanovik> My goal is to write a driver.
<Ivanovik> I am fairly familiar with the os/kernel interfacing part.
<xnox> smb, hm.... does this mean kernel security update was released without running adt test?
<xnox> (one can run adt test with kvm and cloud image using embargoed / locally built packages)
<smb> xnox, you do realize that the adt test is failing for artful which has a different patch than the rest?
<xnox> smb, yes I do.
<xnox> smb, and my understanding was that linux kernel is built in ppa, with adt tests run, before it is copied into artful-proposed and starts blocking migrations of all packages.
<xnox> e.g. we are failing to migrate gcc, systemd, because of the failing adt test.
<xnox> smb, or e.g. copy linux from ppa to silo, and then to the archive.
<apw> xnox, this was an embargoed cve all things are different
<smb> xnox, this is a devel kernel which is built into proposed like any other package
<xnox> to have a full run of adt tests report, which is automated for the silo ppas.
<apw> xnox, and regardless the one which is affecting your adt tests is not the things we released via security
<xnox> smb, it was built in the PPA for Canonical Kernel team and then copied into artful-proposed.
<apw> xnox, why are we so caring about this one failure, we have adt failures which block things all the time
<xnox> apw, ok.
<apw> xnox, we have a system to cope with it
<xnox> sure. but things that do clog up -proposed are either resolved quickly or removed from proposed.
<xnox> do we need a broken kernel in artful-proposed, if it is not passing adt tests?
<apw> what is it blocking whihc is such a huge pressure ?
<xnox> it's not like it will magically pass, due to changes needed in either kernel or the test-suite? thus that upload is toast, no?
<apw> if you say gcc i will punch you on the nose
<xnox> it's blocking automated migration.
<xnox> systemd
<xnox> gcc for doko; systemd for me. As usual.
<apw> ok so we can hint systemd if that is the only failure
<apw> that is why we have hints
<xnox> apw, but hinting requires humans.
<xnox> i'd rather just remove the src:linux from artful-proposed.
<xnox> rather than badtesting src:linux.
<apw> and you will expect me to not do the same for systemd if it fails for an instant right ?
<smb> and that does not require a human?
<xnox> the test is good; and that src:linux is genuenly toast, no?
<apw> smb, the same humans indeed
<xnox> apw, i expect an upload to fix the systemd in proposed or remove the offending systemd in proposed.
<apw> xnox, indeed, and we are working on that right now
<xnox> obviously we cannot remove src:linux or src:systemd from artful-release.
<xnox> hm it is very odd.
<apw> what is very odd
<xnox> i see test results for 6.11 and 7.12, but not 8.13 and release pocket has 4.10.0-22.24
<xnox> e.g. systemd migration should be tested against 4.10, not 4.11
<apw> xnox, yes, if it is not that is a failure in adt
<apw> or some muppet ran all-proposed run
<apw> we should remove that option
<xnox> kernel adt tests are odd; they mostly test the new kernel; and very little test of changed userspace.
<xnox> apw, but do you run adt tests of linux kernel against the new kernel after it is built in the kernel PPA before copying into the devel-proposed?
<apw> xnox, normally yes, unsure if that was done for this one as this was a fix for an emergency CVE
<xnox> because 5.10, 6.11, 7.12, 8.13 of the 4.11 are all failing
<apw> xnox, but as the only people who should be afected are us
<xnox> true.
<apw> xnox, as they are only in -proposed and your testing is against -release
<apw> xnox, so perhaps we need to work out how you got tests against the -proposed version at all
<xnox> yes.
<xnox> meanwhile i'm doing self service request to rerun systemd->linux against release linux, rather than proposed linux.
#ubuntu-kernel 2017-06-23
<manjo> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1700026 IBM is requesting we switch on CONFIG_POWER8_CPU for artful and switch off CONFIG_POWER7_CPU in the kernel build
<ubot5`> Ubuntu bug 1700026 in linux (Ubuntu) "[17.10 FEAT]: Update kernel .config for POWER8" [Undecided,New]
<manjo> apw, is this something we can do without much heartburn ?
<apw> manjo, that appears to be the config as is in the artful 4.11 kernel
<manjo> apw, ah so it will just happen 
<apw> iirc there are also patches out for discussion for zesty, from them as far as i remember, so i am confused
<manjo> apw, this bug  I ref here is talking only about artful .. they have not asked me regarding zesty .. unless they emalied you guys directly .. and bypass me .. which they do sometimes 
<manjo> slangasek, apw, for the stuff we discussed yesterday -edge to -hwe .. do you have a bug for that already? or do you want to me to open one so that I can point the stakeholders at it for their tracking? 
<aletorrado> Hi! Does anyone have experience building v4l (linuxtv) using recent ubuntu kernels? I'm having all kind of issues
#ubuntu-kernel 2017-06-24
<xkern> hi
<xkern> i have a problem related to debugging kernel.
<xkern> i downloaded latest stable kernel from kernel.org and i compiled for debugging.
<xkern> my ubuntu is on virtual machine.
<xkern> my problem is that if i put  breakpoint anywhere, ubuntu gives kernel panic.
<xkern> i guess i use qemu rather than virtualbox. any advice for this ? 
<xkern> and sorry maybe my english is not clear.
<xkern> i spended a lot of time but i have nothing : (
<xkern> if you know something , can you help me ?
#ubuntu-kernel 2017-06-25
<xkern> hi again
<xkern> there is someone here ?
<xkern> that's my problem when i debug linux kernel.
<xkern> http://imgur.com/kL9YUB7
<xkern> http://imgur.com/LdDMgm3
<xkern> http://imgur.com/9dsJfYr
<xkern> http://imgur.com/4mLPDlq
<xkern> step by step.
<xkern> if you know something, dont hesitate you know something : )
<xkern> oh sorry links dont work.
<xkern> https://image.ibb.co/hseHyQ/1.jpg
<xkern> https://image.ibb.co/b6yXXk/2.jpg
<xkern> https://image.ibb.co/gfyMQ5/3.jpg
<xkern> https://image.ibb.co/gfyMQ5/3.jpg
<xkern> these are new links.
#ubuntu-kernel 2018-06-18
<mozmck> Why do the 4.16.x mainline kernel packages say linux-image-unsigned...?
<apw> mozmck, because the packaging is coming from a later release where installed kernels (on amd64 and ppc64el) are signed by default; the unsigned kernel is therefore shipped in linux-image-unsigned for test builds
<mozmck> So I'm building a kernel to ship with the preemp-rt patch.  Do I need to do something to sign the package or is it fine like it is?
<mozmck> I'm using the ubuntu patches such as these: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16.15/
<mozmck> Then applying the preempt-rt patch and making relevant config changes.
<apw> mozmck, well yes, it makes no difference as the consumer won't have any common key with you anyhow
<apw> mozmck, though if you also switch off the efi_signed (and similar) flags in debian.master/rules.d/*.mk
<apw> mozmck, you will get a linux-image package again, though the contents are unsigned still
<mozmck> Will that affect booting on efi systems at all?
<apw> mozmck, no more than the ones you are already producing, ie they will be unsigned
<apw> i suppose once enfocement of efi signatures becomes a thing you will have to talk people thorugh
<apw> turning that off to boot your non-standard kernels
<apw> but that is the same for everyone
<apw> including us when we do test kernels
<mozmck> apw: Ok, thanks for the information!  That was just what I needed to know.
#ubuntu-kernel 2018-06-19
<sub526> I'm having the 16.04 GA kernel 4.4.0-28-generic, here i'd like to understand the semantics of this versioning(Major\Minor\Patch etc)?
<sub526> For GA kernel, is there any chance of jumping the version numbers during the 5 years support?
<xnox> sub526, it's a 28th upload of v4.4 based kernel. for more details see changelog as to what fixes it includes; security patches; features backports; upstream point-release inclusions.
<xnox> sub526, no, it will not jump. but there is an hwe rolling kernel that does get bumped every ~6 months with newer series kernel. so cosmic/d-/e-/f- kernels will be made available on bionic.
<xnox> sub526, but if there are particular drivers or features to backport, it can be requested for consideration via bug reports.
<sub526> xnox: I see a patch "sched/headers: Move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>" in later v4.10 kernel. We are having an out-of-tree drivers and using the ubuntu 16.04 GA kernel, with GA kernel is it possible to test drivers with the mentioned patch?
<xnox> sub526, you can install bionic kernel on xenial; and it should have that change. But I don't think such a change would be uploaded into the v4.4 kernel, as that sounds like it would break things.
<xnox> sub526, on xenial-updates has v4.13.0 based kernel already, and xenial-proposed has v4.15.0 one.
<xnox> sub526, but that's linux-hwe kernel flavour, not the default linux-generic.
<xnox> but yeah, install linux-hwe kernel; reboot; and it should provide you with the new major kernel.
<xnox> sub526, out-of-tree drivers -> ideally you want out-of-tree drivers to work with both GA and hwe kernels, as people are free to install either.
<sub526> xnox: Our org people prefers GA kernel over hwe because it is stable solution and will continue to get security updates for the whole of the 5 years support period. At the same time they want out-of-tree drivers support for newer kernels, i don't know what's the solution?
<tomreyn> doing twice the work. ;-)
<xnox> sub526, you can write out-of-tree driver that is as compatible with many versions of kernel. How is it installed? if you are using dkms, you can, apply patches on per-target-kernel-version-number basis such that you can tweak the include paths
<sub526> xnox: We release source code tarball and it will be stored in the build server. From this .deb package gets created and kept in internal repository. During apt-get install this source code gets copied to the ubuntu machine and gets build. Iâm yet to understand this complete process, it looks we are using dkms. Can you please shed some light on how to go about doing this?
#ubuntu-kernel 2018-06-20
<cascardo> jjohansen: any news about that apparmor compat fix?
<jjohansen> cascardo: its a wip, it builds but I am chasing a bug
<jjohansen> hopefully it will be done today
<cascardo> jjohansen: thanks!
<dijuremo> I am not quite sure this is specifically a kernel, issue, but I am going to ask here. I have two machines, Alienware 17 R5 and XPS 15 9570. These both come with Nvidia Video cards. If we install them using LUKS on EFI with full drive encryption, the machines start up, show the dark background ubuntu screen and lock up. Sometimes they will show the field to enter the LUKS key, but no input would be taken from the keyboard. So far, the only 
<dijuremo> Furthermore, in the XPS 15 9570, I have been completely unable to make the GUI login work, with the nvidia driver installed. I tried many suggestions I found around, but none work. If I remove the nvidia driver and only use the intel, then I can log in via the GUI just fine. Suggestions included using kernel options like nomodeset, acpi_osi=! acpi_osi='Windows 2012" and many other things. The nvidia driver will never find the card itself, 
<dijuremo> What IRC channel do you recommend I take the XPS 15 9570 discussion to?
<apw> tseliot, ^ dunno if you have heard anything about nvidia for that machine ?
<apw> on the luks key, does hitting escape do anything; to flip to text and hit it again to come back
<dijuremo> apw: Let me try that the "ESC" key....
<tseliot> dijuremo, apw: I haven't really tested LUKS, but the nvidia modules should be available in the initrd. It's hard to tell what's going on without seeing some logs
<tseliot> dijuremo: for example, seeing these files might help: /var/log/gpu-manager.log, dmesg output, and /var/log/Xorg.0.log 
<dijuremo> Even without the nvidia driver, I see the problems with LUKS on both the Alienware 17 R5 and DELL XPS 15. This is an image of it. I am unable to type anything and ESC does *not* take me to a text login: https://imgur.com/a/BXa51vJ
<dijuremo> tseliot: Do we want those logs on the XPS 15, where the nvidia driver does not work at all to look at the Ubuntu GUI problems, or do we want to look at this on the Alienware, where I am using text mode to eneter the LUKS passphrase and where we are using the Nvidia driver succesfully for GUI logins?
<tseliot> dijuremo: I only maintain the nvidia driver, so I can probably help with that. It would be best if you filed a bug report (against nvidia-graphics-drivers-390 for now), and attached those files. Then we can try to diagnose the problem.
<tseliot> also, it's EOD for me
<dijuremo> tseliot: no worries, I will either open or mention existing bug requests, though some point to 18.04, and I am using 16.04
<tseliot> dijuremo: if you are on 16.04, then maybe the nvidia driver is simply too old for the XPS15
<dijuremo> I've tried all of them, including graphics-drivers/ppa, they seem to behave similarly, 384, 390 and 396
<dijuremo> This laptop has the GTX 1050 Ti, which has been supported for a while...
<mozmck> I just built 4.16.15 mainline using the ubuntu stuff and there is a linux-modules package which I haven't seen before.  Did I do something wrong?
<mozmck> Looks like it split the modules out of the linux-image package into another package?
<apw> mozmck, yes we did that
<mozmck> Ok, thanks!
<mozmck> Ok, trying to compile 4.16.15 on 18.04 and I'm getting this: ./include/linux/kernel.h:6:10: fatal error: stdarg.h: No such file or directory.
<mozmck> I compiled this same source on 16.04, then I did a debian/rules clean, zipped up the source, copied to an 18.04 VM, ran debian/rules clean again, and debian/rules binary-indep
<mozmck> Could it be that I'm missing a dependency?  I thought I had everything but had to install flex, bison, and kernel-wedge to get this far.
#ubuntu-kernel 2018-06-21
<apw> mozmck, normally you would install the build-deps en-toto for a package like that
<apw> apt-get has a way to do that
<femme> jsalisbury: performed the testing and the results are the same even with 4.18 rc1
#ubuntu-kernel 2018-06-22
<cascardo> jjohansen: any luck with that bug for the apparmor compat fix?
<jjohansen> cascardo: sigh yes, I have fixed multiple bugs, but there is at least one more to go
<sforshee> jjohansen: is missing this compatibility fix going to cause significant issues for things like lxd or snappy?
<jjohansen> cascardo, sforshee: unfortunately it will, and the current bug with it will cause problems too
<sforshee> jjohansen: thanks
#ubuntu-kernel 2018-06-23
<jhg_> greetings
<jhg_> I moved /boot (ext2) to / (ext4) in order to do kernel development on Ubuntu 16.04 kernel 4.4. I built/installed 4.18.0-rc1+ from source. The boot drops out to an (initramfs) shell because it cannot find the root lvm partition. /dev/mapper and /dev/disk/id are empty. 
<jhg_> vgchange -ay has empty output, even after modprobe ext4
<jhg_> I am going to try the ubuntu ppa 4.18.0-rc1 as a test.
<jhg_> the ppa works... so I did something wrong with initrd. hmmm.
<jhg_> the patches aren't relevant to me, so I am wondering what I missed. hmm... http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc1/
<tomreyn> you have /boot on an LVM LV? i wasn taware this works
<tomreyn> oh rhgt, it's support, just discouraged for complexity
<tomreyn> *supported
#ubuntu-kernel 2018-06-24
<jhg_> tomreyn: yes, I think it is worth ditching lvm for this case.
#ubuntu-kernel 2019-06-17
<hallyn> hm, why the flood of Jun 17 16:40:56 stp kernel: usb usb2-port3: device 2-3 not suspended yet
#ubuntu-kernel 2019-06-18
 * tsimonq2 is currently git bisecting bug 1829805
<ubot5> bug 1829805 in linux (Ubuntu) "Lubuntu Eoan Daily Image fails to boot after install on KVM" [Undecided,Confirmed] https://launchpad.net/bugs/1829805
<tsimonq2> I'll try my best to work out the problem, but it'd be cool to get a second set of eyes from someone who regularly does kernel stuff. :)
<TJ-> tsimonq2: are you still working on the bug?
<tsimonq2> TJ-: Yes.
<tsimonq2> It just takes a while for a kernel to build, and I've been at SELF.
<TJ-> no need; see my about-to-be posted comment to the bug
<tsimonq2> Oh?
<tsimonq2> So, why does installing the Disco kernel work fine? :/
<TJ-> tsimonq2: not sure, but I'd start with investigating from the initramfs to identify the problem
<tsimonq2> That's a weird one.
<tsimonq2> TJ-: And it only happens with Lubuntu.
<tsimonq2> Harumph.
<TJ-> tsimonq2: I'm fetching the lubuntu image so I can test here in QEMU too
<tsimonq2> Thanks.
<TJ-> I've dealt with lots of these unable to mount root-fs using the break=XXXX method
<TJ-> 22 minutes to fetch; I miss the days of CD image!
<tsimonq2> haha :)
<TJ-> You should have fixed it by the time I've got the image :)
<tsimonq2> TJ-: We do have a new release of Calamares that should be in this daily.
<tsimonq2> Watch that be the solution. :P
<tsimonq2> I trust your judgement though, because last time you were right.
<tsimonq2> (I'd like to document whatever the solution is, though.)
<TJ-> remind me what Calamares is? installer?
<tsimonq2> Yeah.
<tsimonq2> It replaces Ubiquity.
<TJ-> tsimonq2: are you saying the current daily may be fixed?
<TJ-> tsimonq2: is there a lubuntu-dev channel for dealing with this?
#ubuntu-kernel 2019-06-20
<rbasak> $ sudo canonical-livepatch status
<rbasak> uptime: 598h20m30s
<rbasak> ^ that's wrong - `uptime` reports 24 days, 22:21
<rbasak> And also
<rbasak>     patchState: apply-failed
<rbasak> Anything I should look at before I lose state by rebooting?
<rbasak> http://paste.ubuntu.com/p/gNKr4YPdhB/
<TJ-> rbasak: uptime seems correct; 24 days x 24 = 576 + 22 hours 
<rbasak> TJ-: oh. Thanks. I saw 598 and didn't pay attention to the units.
<TJ-> :)
<TJ-> yeah, at first glance I thought "wow" !
<rbasak> I found some logs (on "apply-failed"): https://paste.ubuntu.com/p/F4mYrd45Tc/
<rbasak> It's been doing that a while. https://paste.ubuntu.com/p/td7qYQ9SjZ/ is when it seems to have started.
<rbasak> https://askubuntu.com/q/1152398/7808 is the only Google hit with the same problem - no answer currently.
<rbasak> Seems too much of a coincidence that both of us had it happen on exactly the same day.
<TJ-> we've been seeing a lot of reports of livepatch failures in #ubuntu for the last 2 weeks. Originally we thought it was a server connection issue but canonical-sysadmin couldn't see any problems. We asked some users to report bugs but I think they were lazy :)
 * rbasak is writing up a bug
<rbasak> https://bugs.launchpad.net/canonical-livepatch-client/+bug/1833566
<ubot5> Launchpad bug 1833566 in Canonical Live Patch Client "Client stops applying patches with "cannot execute finitModule syscall: required key not available"" [Undecided,Confirmed]
<apw> ben_r: ^
 * ben_r will take a look at it
<ben_r> rbasak, I am confused, your text says 4.4.0.151.159, did you mean 151.178? Also, that is not the kernel that was running, you were on 4.4.0-148.174 at the time right?
<rbasak> ben_r: otp sorry, back in a bit
<ben_r> np
<rbasak> ben_r: ah, I see the confusion
<ben_r> rbasak, np I think I've figured it out. Is this system running with secure boot enabled?
<rbasak> ben_r: I think so. I have grub-efi-amd64-signed installed. Is there a way to verify?
<ben_r> rbasak, mokutil --sb-state
<ben_r> if that is enabled, did you enroll the livepatch key?
<rbasak> SecureBoot enabled
<rbasak> ben_r: I believe livepatch has been working correctly for a long time prior to that error
<rbasak> ben_r: eg: https://paste.ubuntu.com/p/xBQBZD7tpd/
<rbasak> ben_r: so I think it was all enrolled correctly, yes.
<rbasak> ben_r: I recall seeing patches applied in previous calls to "status" (in previous boots)
<rbasak> your text says 4.4.0.151.159> because that's the kernel package currently installed, not the one running
<ben_r> rbasak, OK, that doesn't do anything to livepatch though. :)  you can list the enrolled keys with "mokutil --list-enrolled". If there's a key enrolled you'll see one with the Subject field "        Issuer: CN=Canonical Ltd. Live Patch Signing"
<rbasak> MokListRT is empty
<ben_r> rbasak, any chance the system's BIOS was updated recently? that can trash keys sometimes
<rbasak> I have only rebooted once in months, and I believe livepatch was working before the reboot.
<rbasak> The reboot itself seemed to be completely normal - I didn't enter the BIOS or anything.
<rbasak> The reason I rebooted was some kind of kernel bug though.
<rbasak> https://irclogs.ubuntu.com/2019/05/24/%23ubuntu-server.html#t18:29 was what happened that caused me to reboot
<rbasak> I suppose it's possible that fwupd might have done something though perhaps, and the reboot caused a new BIOS fw version to run?
<rbasak> I don't remember having done that though.
<rbasak> And on this machine I always update/upgrade manually
<rbasak> "Earlier I sent SIGSTOP to firefox and snap related process, so I can't run livepatch right now."
<rbasak> I did that before rebooting.
<rbasak> Could that have broken livepatch - by it not being able to "shut down" properly?
<rbasak> Also "canonical-livepatch status" hangs, but I don't know if I caused that by interfering with it earlier. <-- also before my reboot
<ben_r> rbasak, it's likely that it would have stopped it from doing anything else, but that wouldn't break livepatch. The next time the system boots it would have started normally.
<ben_r> I think the lack of keys is the problem here, on secure boot the kernel won't let you load anything that isn't signed with a key it recognises. I don't know where your keys went, but there should be at least the one used to boot the system listed
#ubuntu-kernel 2019-06-21
<dupondje> Small question. Why does the latest kernel for disco in proposed update to:   * Disco update: 5.0.12 upstream stable release (LP: #1830934)
<ubot5> Launchpad bug 1830934 in linux (Ubuntu Disco) "Disco update: 5.0.12 upstream stable release" [Medium,Fix committed] https://launchpad.net/bugs/1830934
<dupondje> While there is 5.0.21 already, why is there such a delay?
<apw> dupondje, because they take time to prepare i guess, and a lot of time consumed by security CRD type releases like the one we just had
<apw> dupondje, particularly where those stable updates clash with or contain variants of the CRD patch kits
<apw> we normally try and be up to date as close as we can
<dupondje> apw: ok thanks! :) 5.0.12 is 7 weeks old.
<dupondje> What are those CRD patch kits?
<apw> yeah, its not ideal for sure
<apw> dupondje, the MDS release last monday for example, getting those ready can delay other work
<dupondje> apw: Yea indeed. But you could lower the time by just using the latest 5.0.x (in disco case) kernel (which has the patch included)
<dupondje> then you don't need to adjust the patch yourself
<dupondje> Anyway, I don't know the whole ubuntu kernel flow :)
<apw> we released those kernels before the patch kit was available on stable; necessarily because it was embargoed
<dupondje> ah :(
<dupondje> lets further debug my curreny issue with 5.2-rc5
<dupondje> network seems to drop packages every 5 minutes or so :)
<dupondje> 20 drops at ip_rcv_finish_core.isra.22+1ac (0xffffffff96d4828c)
<apw> dupondje, we are aware of the tardyness of stable there; and it is on the teams radar
