#ubuntu-kernel 2005-08-15
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<Mithrandir> dilinger: I'm sure we could find hosting for it in Debian too.
<zul> i could of sworn i logged off last night
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<jbailey> Is debclean supposed to work in the kernel package?
<jbailey> Or do you guys just purge and build from the checkout each time?
<jbailey> Oh, 00list fun
<jbailey> fabbione: Are you back now?
<fabbione> not till next monday :)
<jbailey> Ah. =)
<jbailey> I just uploaded a new kernel-package and linux-source-2.6.12
<jbailey> I didn't manage to sync up on getting the stuff into baz, so mostly a heads-up on that.
<fabbione> jbailey. hmmmm
<fabbione> i don't like uploads without RCS in sync...
<jbailey> fabbione: Got 2 minutes to help me with it?
<fabbione> but i am happy if you did the right upload :)
<jbailey> Appears to be right.  00list.* updated, abi directory changed, control.stub and control updated
<fabbione> jbailey: seems about right...
<fabbione> i didn't check the package.. just reading your stuff..
<fabbione> jbailey: i am sure you did test a build... right?
<jbailey> Just a short one to make sure that everything unpack and such correctly.
<fabbione> ok
<jbailey> fabbione: It appears to have built on i386 and ppc.  The segfault on amd64 isn't my doing. =)
<fabbione> humm we already had pre6.9 in baz....
<fabbione> amd64 segfault???
<jbailey> Installing X
<fabbione> AH ok
<fabbione> ENOCARE..
<jbailey> Like I said, not my fault. =)
<fabbione> that's dpkg issue afaik
<fabbione> i guess i will do the baz dance tomorrow morning when i wake up
<fabbione> 6.9 is still not on my local mirror
<jbailey> Nor mine.
<jbailey> Thanks, dude.  How's holidays?
<fabbione> we almost finished to do the garden room..
<fabbione> i need to lay the new floor
<fabbione> that will happen either during the weekend or sometimes next week
<fabbione> but it has been pretty hard
<fabbione> + work
<jbailey> Got pictures?
<fabbione> yeah,, they are still in the camera tho
<fabbione> i will put stuff in order later on :)
<fabbione> i had not a single day to relax and enjoy my holidays :(
<jbailey> 6.9 is now on the canadian mirror, I guess the games begin now. =)
<fabbione> nah i have a local mirror
<jbailey> Oh, I mean in general.
<fabbione> i am not using archive or anything..
<jbailey> That it's actually propagating.
<fabbione> eheh
<jbailey> Mithrandir: If not, it should be as easy as adding another driver.
<zul> heylo
<Mithrandir> hi fabio
<Mithrandir> jbailey: humm?
#ubuntu-kernel 2005-08-16
<desrt> anyone know what the story with this mkinitramfs thing is?
<desrt> is it correct?
<jbailey> desrt: Is what correct?
<desrt> someone changed mkinitrd to mkinitramfs in the postinst script for the kernel
<desrt> mkinitramfs doesn't exist in my /usr/sbin
<desrt> as a result the postinst fails
<desrt> if i change it back to mkinitrd, it's fine
<jbailey> Install initramfs-tools.  The newer kernel version will depend on initramfs-tools correctly.
<desrt> awesome.
<jbailey> 6.10, that is.
<jbailey> I missed a spot in 6.9
* desrt doesn't report the bug, then :)
<desrt> thx for the initramfs-tools tip.
<jbailey> Np, sorry for getting it wrong in the first palce. =)
<jbailey> Lemme know how rebooting works for you.
<jbailey> All the reports today have been succesful, which is nice. =)
<desrt> k.  i'll install on my x86
<desrt> i'm having some ubuntu issues at work
<desrt> it might be the kernel it might be yaboot
<desrt> ubuntu refuses to boot if you don't have a videocard
<jbailey> Hmm.
<jbailey> I don't have any machiens with that particular afflication. =)
<desrt> (which is the normal case for most xserves)
<desrt> i have 7 :P
<desrt> it's one of those problems that you just gotta know is gonna be a blast to solve
<desrt> i love bugs that are pre-bootup and only occur when you don't have the ability to use a monitor
<desrt> :D
<jbailey> Ah, what life will be like with a modular frame buffer. =)
<jbailey> desrt: Do you know when you'll get a chance to do your test?
<desrt> jbailey; 7% [40 gnome-control-center 230153/625kB 36%]                    35,6kB/s 42m20s
<desrt> mirrors are freakin' slow today
<jbailey> Ah, plenty of time for a walk then. =)
<desrt> cheers.
* desrt has a nice shower
<desrt> jbailey; thumbs up
<desrt> (pentium 4 with straight up serial ata)
<jbailey> desrt: Sweet!
<jbailey> I like all these success reports, they make me happy. =)
<desrt> glad i could contribute :P
* fabbione sighs
<fabbione> i guess that -10 is not in baz either
<Mithrandir> jbailey: will it work with evms as well now?
<fabbione> hey Mith
<Mithrandir> hiya Fabio
<fabbione> how come awake so early?
<jbailey> Mithrandir: No, neither that nor cryptroot, but those are just scripts that need to be tweaked in those packages.
<jbailey> Mithrandir: Writing them is trivial, but I have no way of testing what gets written.
<Mithrandir> jbailey: I can test them.
<Mithrandir> hm, no, I probably can't, I don't have / on evms.
<Mithrandir> I just use evms and that should work fine, I guess.
<fabbione> so how many bugs did the kernel got for the initramfs stuff?
<jbailey> fabbione: One.
<fabbione> on the wave of:
<fabbione> "I 
<jbailey> initramfs got two bugs, one of which was an error that occured only if you failed to install it properly and then purged the package.
<fabbione> "IT DOESN'T WORK I AM GONNA KILLA YA ALL"?
<jbailey> Something like that.
<fabbione> no wonder :)
<Mithrandir> jbailey: what does ERROR: ld.so: object '/path/to/libfoo.so' from LD_PRELOAD cannot be preloaded: ignored.  mean?
<Mithrandir> that is, what can I do to get rid of it?
<dim> hi
<dim> where could I see what patches are included in the official ubuntu kernel?
<dim> I'm interested in the sata_pm patch
<dim> because I can't get my t43 thinkpad to suspend without it
<zul> heylo
<BenC> hey, anyone mind helping me through a checkout of the kernel stuff?
<infinity> BenC : First time playing with arch/baz?
<BenC> yeah
<jbailey> Poor BenC
* doko listens
<jbailey> doko: To us consoling Ben? =)
<infinity> BenC : Do you have an account on rookery?
<infinity> Benc : If so, try something like this:
<infinity> baz register-archive  sftp://rookery.ubuntu.com/home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/
<infinity> baz get kernel-team@ubuntu.com--2005/kernel-debian--preX,9--2.6.12
<infinity> BenC : If you don't have an account yet, then do the above, but using the http:// address in the topic.
<BenC> I have an account, but not sure if it's on that machine
<BenC> is it part of userdir-ldap stuff?
<infinity> Is, rookery is replicated to via ud-ldap.
<infinity> Not all machines are, but if you have an account on chinstrap, you definitely have an account on rookery.
<infinity> (You can only get to rookery through chinstrap though, do you have your .ssh/config set up for proxying?)
<zul> BenC: when you got your baz stuff working you can merge some of my stuff as well
<BenC> never done ssh proxy
<BenC> got an example config?
<infinity> Host chinstrap.ubuntu.com
<infinity>  ProxyCommand none
<infinity> 
<infinity> Host *.ubuntu.com
<infinity>  ProxyCommand ssh adconrad@chinstrap.ubuntu.com nc -q0 %h %p
<infinity> 
<infinity> That should do it.
<infinity> s/adconrad/bcollins/ (or whatever)
<BenC> thanks
<BenC> ok, I can get to chinstrap
<BenC> but I cannot get to rookery from chinstrap
<infinity> From, or through?
<infinity> rookery is people.ubuntu.com, I was pretty sure we all had an account on there by default, but you may have to ask..
* infinity checks.
<infinity> Oh, I can't check.  No permissions on that file.  <kicks sand>
<BenC> I login to chinstrap and then try to ssh to rookery from there
<BenC> and it wont let me
<infinity> I'd try that if I knew what my password was.  I only ever use pubkey auth.
<infinity> Which should work for you, if you have a key in LDAP..
<BenC> I sent a key via email, but it doesn't appear to be working
#ubuntu-kernel 2005-08-17
* Mithrandir adds an unionfs-modules.*udeb.  Hopefully.
<zul> hey
<mjg59> Any chance we can get http://bugme.osdl.org/attachment.cgi?id=5596&action=view ?
<mjg59> Seems to be needed to fix the clock running twice the correct speed on some AMD64 hardware
<mjg59> I'm just about to test it
<zul> sure
<zul> ill make a patch tonight and add it to my baz so it can be picked up
<zul> mjg59: how well is the dell latitude x support under linux?
<zul> sorry latitude x1
<mjg59> zul: Ought to be pretty good
<zul> good...just want to see how much work i have to do ;)
<mjg59> Oh, damn. No, that seems to have resulted in the machine hanging on boot. Possibly an ABI issue.
<zul> oh i wont make that patch then 
<mjg59> Let me try to figure out what's up
<mjg59> Ok, that patch is definitely broken
<zul> hey benc
<zul> how is the baz fight coming?
<BenC> well, I got a checkout done
<BenC> not through ssh though
<BenC> what's the baz command for checking out the repo via ssh proxy?
<zul> no idea..i use sftp when connecting to my home one
<Mithrandir> baz register-archive sftp://people.ubuntu.com/[...]   and have a proper .ssh/config
#ubuntu-kernel 2005-08-19
<fabbione> Mithrandir: there is very little point in adding modules to kernel-wedge.
<fabbione> if you need to ship modules, you need to do it directly from the kernel.
<fabbione> we removed the "lists" dependencies between kernel and kernel-wedge
<Mithrandir> fabbione: how do I do that?  I didn't see a way.
<fabbione> Mithrandir: debian/d-i/
<fabbione> there is shared/ that has the same meaning as adding a module to kernel-wedge
<fabbione> the trick is in what you include in the unionfs-modules per arch
<fabbione> instead of <unionfs>
<fabbione> that would be "shared/unionfs"
<fabbione> but if unionfs udebs are required, just remind me on monday
<fabbione> i need to unfuck the baz repo first
<fabbione> and open proper devel branch first
<Mithrandir> I did that, but kernel-wedge gen-control didn't output anything about unionfs-modukes
<Mithrandir> modules, even
<fabbione> Mithrandir: you still need to tell that you want the module in a per arch specific way
<fabbione> and note that kernel-wedge is stupid
<Mithrandir> yes, but gen-control needs to have a description and so on, that seems to go into kernel-wedge.
<fabbione> if you check the debian/rules, you will see that we copy the info in another dir to make them available to kernel-wedge
<fabbione> Mithrandir: you can always override it locally
<Mithrandir> how?
<fabbione> anyway did you commit anything about this into baz?
<Mithrandir> not yet
<fabbione> if so in which branch??
<fabbione> ojk
<fabbione> ok
<Mithrandir> overriding where modules goes (per arch) is easy, but you can't _add_ modules without touching kernel-wedge, or at least it seems that way to me.
<fabbione> Mithrandir: debian/d-i/$arch/package-list iirc or very similar
<fabbione> Mithrandir: nah.. we override all the lists of modules from kernel-wedge
<fabbione> anyway, don't worry..
<fabbione> we will look at it tomorrow after i get a proper baz branch and stuff
<fabbione> sunday.. last day of holidays :)
<Mithrandir> shouldn't there be a description too in the package-list?
<Mithrandir> and shouldn't there be a shared/package-list too?
<fabbione> Mithrandir: description can be added to arch/packages-list
<fabbione> shared/package-list is not taken into account afaik
<fabbione> last time i did check kernel-wedge code it only use the global provided by kernel-wedge and per arch specific one
<Mithrandir> ok
<zul> hey
<zul> fabbione: are you around?
<Diablo-D3> <Diablo-D3> /boot/config-2.6.10-5-k7:CONFIG_PREEMPT=y
<Diablo-D3> <Diablo-D3> /boot/config-2.6.12-6-k7:# CONFIG_PREEMPT is not set
<Diablo-D3> <Diablo-D3> so... preempt has been turned off in later packages?
<mdz> Diablo-D3: you seem to have answered your own question before asking it :-)
<Diablo-D3> mdz: hrm?
<Diablo-D3> thats the question Im asking, btw
<Diablo-D3> I dont know whats really goind on
<mdz> Diablo-D3: you answered it already
<mdz> in 2.6.10-5-k7, CONFIG_PREEMPT=y, and in 2.6.12-6-k7, CONFIG_PREEMPT is not set
<Diablo-D3> mdz: but that doesnt mean 2.6.12 doesnt have preempt
<Diablo-D3> say, if, preempt is default in 2.6.12
<mdz> the default is irrelevant; if it is not set, then it is not enabled
<Diablo-D3> why?
* Diablo-D3 doesnt exactly know how kernel makefiles work
<Diablo-D3> #ubuntu-laptop is open for buisness
#ubuntu-kernel 2005-08-20
<fabbione> morning
* fabbione starts unfucking the baz repo
<fabbione> Mithrandir: so.. why do we need unionfs udebs?
<Mithrandir> for the live cd
<Mithrandir> https://wiki.ubuntu.com/LiveCDFeatures
<fabbione> ok
<fabbione> i am unfucking the baz repo now
<fabbione> to resync with the last 2 kernel uploads
<fabbione> and after that we can open devel dances again
* fabbione powers up the sodomotron and points it towards baz --'s
<Mithrandir> fabbione: so you've added unionfs now?
<Mithrandir> or should I?
<fabbione> Mithrandir: i am still branching and merging...
<Mithrandir> ok
<fabbione> Mithrandir: but i can do it.. so don't worry about it
<Mithrandir> cheers
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion ONLY | 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--preX,11--2.6.12
<fabbione> there
<fabbione> baz resynced
<Mithrandir> is there anything explaining what the logic in the version string is? :-)
<fabbione> pre <- prerelease
<fabbione> X <- hidden abi number
<fabbione> ,11 <- next deb version
<Mithrandir> prerelease as in "not yet uploaded", not "prerelease from kernel.org"?
<fabbione> not uploaded yet
<Mithrandir> and what do you mean by hidden abi number?  Might break multiple times before next public breakage?
<fabbione> hidden abi is a trick to avoid more than a devel branch...
<fabbione> example:
<fabbione> when we upload 6,10 it means ABI =6 ver 10
<fabbione> but during the devel cycle of 11
<fabbione> we don't know if the abi is going to break
<fabbione> so you can't name the pre branch as 6,11
<fabbione> so we hide it
<Mithrandir> ok
<fabbione> because it might easily land as 7,11
<fabbione> look at preX,Y as HEAD
<fabbione> where we all commit
<Mithrandir> mm
<fabbione> once it's ready we merge it mainline--2.6.12
<fabbione> from there we branch the tag release and the next pre
<fabbione> don't ask me why this schema
<fabbione> lamont did create it in early stage :)
<fabbione> but clearly merging from other repos is ok
<Mithrandir> it makes some kind of sense, I guess.
<Mithrandir> if I'm touching stuff, do you prefer me to commit into the kernel-team repo directly or work in my own space and then later merge it when it's ready?
<fabbione> Mithrandir: i don't care either way
<fabbione> if you keep your repo, you need to ping me manually for merge or merge yourself
<Mithrandir> but kernel-team@ is supposed to be kept "working at all times" or are temporary breakages ok?  (I presume the former)
<fabbione> but if you commit directly, in most of the cases your changes will be test-builded by me each time i do a change
<fabbione> well the former is better, but if it breaks it's not a tragedy
<Mithrandir> ok
<fabbione> let say that i don't mind "it did break by mistake"
<fabbione> but breaking it on purpose i am a bit less happy
<Mithrandir> ok
<fabbione> or at least tell me in advance :)
<Mithrandir> I'm fine with doing on-purpose breakages in my own space. :-)
<fabbione> Mithrandir: btw.. unionfs is/should be available on all arches
<fabbione> when you have one module only in a list, mark it as ? is pointless
<fabbione> because kernel-wedge will fail later with an empty udeb
<fabbione> so either is everywhere, or you need to create a per arch list
<Mithrandir> ok
<fabbione> if there is more than one module and one is available everywhere, than it makes sense to have other optionals
<fabbione> but iirc unionfs is available on all our kernel images
<Mithrandir> 'k
<fabbione> is there a bug assigned for unionfs udebs?
<Mithrandir> not to my knowledge
<fabbione> ok
<fabbione> * update pristine tree (kernel-team@ubuntu.com--2005/kernel-debian--preX,11--2.6.12--patch-1 => kernel-debian--preX,11--2.6.12--patch-2)
<fabbione> this is the commit you want to look at
<fabbione> Jeg er s travlt og der kun i frst dag p arbejde
* fabbione shows that he is going to danish class now ;)
<Mithrandir> thanks
<Mithrandir> should (udeb) modules call depmod -a in their postinst?
<fabbione> no idea.. kernel-wedge takes care of creating that stuff
<Mithrandir> oh well, apparently it doesn't.  I'll add a workaround in casper, then
<fabbione> i think depmod -a is executed after all kernel modules have been downloaded
<fabbione> but i dunno about casper...
<fabbione> that's anna taking care of that
<fabbione> or at least it should
<Mithrandir> I've added a workaround and I'll speak with Colin once he's back again
<Mithrandir> live cd testing takes tiiiiime
<fabbione> eheheh
<fabbione> i am doing a test build to create the unionfs udeb
<Mithrandir> is unionfs supposed to be the slowest thing since sliced bread?
<fabbione> no idea
<Mithrandir> I think something I did made debconf unhappy
<fabbione> that's not difficult :)
<Mithrandir> I need to find something to generate Release files for me.
<Mithrandir> apt-ftparchive release seems to work
<fabbione> yup.. i use it here :)
<fabbione> (breezy-chroot)fabbione@davis:~ $ dpkg -c unionfs-modules-2.6.12-6-powerpc64-smp-di_2.6.12-6.11_powerpc.udeb
<fabbione> -rw-r--r-- root/root   1718210 2005-08-15 09:41:53 ./lib/modules/2.6.12-6-powerpc64-smp/kernel/fs/unionfs/unionfs.ko
<Mithrandir> cheers
<Mithrandir> fabbione: when can we have that in the archive?
<Mithrandir> fabbione: I would really like to have it in quickly so we can get some unionfs testing
<Mithrandir> since I just uploaded a casper which needs it.
<fabbione> Mithrandir: meh... in a few days :/
<fabbione> you should have told me it was urgent :/
<Mithrandir> fabbione: can I push a new version up with just that small change?
<fabbione> Mithrandir: let me see a couple of things...
<fabbione> i might be able to upload today...
<Mithrandir> that'd be great. :-)
<Mithrandir> sorry about the miscommunication
<fabbione> yeah but it means pushing a big bunch of security fixes for the next upload...
<fabbione> we also need elmo/mdz for NEW love...
<fabbione> the new udeb will stall buildd -> archive movement
<Mithrandir> argh, true :-(
<Mithrandir> can we see when mdz gets around in a few hours?
<fabbione> i have no problems with it, but i must leave around 3:30 pm
<fabbione> (our time)
<fabbione> so i can upload.. (untested) but you need to follow up with mdz
<fabbione> anyway.. food now :)
<Mithrandir> ok, cheers
<mjg59> fabbione: I'm going to have patches to feed you from laptop testing
<mjg59> Need to do a bit more back and forth with upstream on a couple first, though
<fabbione> mjg59: ok, but don't wait too long
<fabbione> we need to update heaps load of stuff in the kernel
<fabbione> TheMuso:
<fabbione> bah
<fabbione> SO :
<fabbione> 1) i am going to upload -6,11 basically untested...
<fabbione> 2) NOBODY please plan to push URGENT stuff for a few days that needs an upload yesterday
<fabbione> push but wait...
<Mithrandir> fabbione: actually, you don't need to hurry with the kernel, my casper upload got rejected.
<fabbione> Mithrandir: ok!
<fabbione> perfect
<fabbione> that will give me the time to break it in unreasonable new ways :)
<zul> morning
<fabbione> hey zul
<zul> hey fabbione good vacation?
<Mithrandir> fabbione: I'd  love it if you can get it in a couple of days, though.
<fabbione> Mithrandir: 2/3 days should be fine.. 
<fabbione> zul: more or less
<fabbione> zul: i saw you missed me :)
<zul> heh...
<zul> at little...but not much
<chmj> heh 
<fabbione> zul: do you have anything that i need to merge?
<zul> yeah a couple of bug fixes from bugzilla
<zul> its in my arch under ,9
<zul> uh...we are at ,11 now?
<fabbione> zul: mind to update to ,11 ?
<fabbione> yes.
<fabbione> .11
<fabbione> zul: i did import this morning the 2 uploads that have been done outside baz
<zul> ok
<zul> sigh gimme a sec
<fabbione> take your time
<fabbione> i will leave in less than one hour
<fabbione> so i will defenetely not upload today
<zul> ok good because im at work right now
<doko> fabbione: the i386 biarch compilers are in the archive, hint, hint ...
<fabbione> doko: are you hinting me that you just offered volunteer to build the kernel?
<fabbione> since you got biarch done, you must have more spare time now :)
<Mithrandir> is lrm in baz?
<fabbione> doko: more seriously.. i need to build an amd64 kernel on i386..
<fabbione> right?
<fabbione> Mithrandir: nope.. lrm is crap.. we don't want it :)
<fabbione> doko: if so.. what is the usecase for it?
<Mithrandir> fabbione: ok, since I need to fix it up a bit.  It's br0ken.
<fabbione> Mithrandir: eheh ok
<zul> fabbione: i just branced and merged my stuff in my arch so my changes are in X,9 in my arch
<fabbione> zul: ok... can you just branch to ,11 ?
<fabbione> so we work on same versions?
<fabbione> it's already confusing enough :/
<zul> ok..will do on my break
<fabbione> zul: thanks
<doko> fabbione: use case is: install i386 on amd64 to have better 32bit compatibility, and be able to do things for 64bit as well, i.e. a chroot
* fabbione scratches his head...
<fabbione> you mean installing a 64bit kernel with a 32bit userland?
<doko> yes
<chmj> is that possible  ?
<fabbione> chmj: yes
<fabbione> doko: i *THINK* i can do it...
<fabbione> but i won't make more than one flavour...
<fabbione> only a generic kernel
<fabbione> that also means bloating the i386 CD with udebs...
<doko> fabbione: sure, that should be sufficient
<fabbione> did you mention that to Kamion?
<fabbione> because it's another kernel to ship...
<doko> no, not yet. how much is that in size?
<doko> but at least it's mentioned on our ToolchainRoadmap
<fabbione> doko: a bunch of MB
<fabbione> changes that needs to be done in the installer
<fabbione> and several other things...
<fabbione> it's not exactly trivial to do all of the above
<doko> ouch
<fabbione> and for sure i am not going to do that in the installer while Kamion is away
<zul> i...dislike...sybase
<fabbione> YAY for the ABI change!
<fabbione> -+#define OCFS2_BUILD_VERSION "0.99.17"
<fabbione> ++#define OCFS2_BUILD_VERSION "1.1.0"
<fabbione> Mithrandir: whatever fix you have for lrm, better you upload it asap
<fabbione> next kernel upload will bump the ABI
<Mithrandir> fabbione: it's already uploaded.
<fabbione> ah cool
<fabbione> let see in which wonderful ways the kernel is going to break :)
<fabbione> i already noticed a target that goes banana with the debian version made of 2 digits :)
<Mithrandir> heh
<fabbione> impressive...
<fabbione> the force is strong in the bumpabi target...
<fabbione> later fellas...
* fabbione -> danish class
* lamont-away returns
<lamont-away> fabbione: I did it that way because I sometimes forget to tag...  But I almost always remember to branch for the new version
<lamont-away> or rather, I'm far less likely to release from non-mainline than I am to forget to tag from mainline
<doko> fabbione: "x86_64 kernel on i386 system" on u-u ml
<zul> hey BenC 
<BenC> hey
<fabbione> hey BenC
<fabbione> welcome to the team
<fabbione> BenC: i am going to have dinner and i will be back later (if wife will allow me ;))
<fabbione> so we can talk a bit
<zul> you are so whipped
<zul> but thats ok so am i
<BenC> ok
<zul> hey lamont 
<lamont> hey zul
<mjg59>  /win goto #ubuntu-devel
<mjg59> Hrngh.
<fabbione> re
<fabbione> BenC: still around?
<fabbione> lamont-away: ping?
<fabbione> bah something is wrong with this client
<lamont> sup>
<fabbione> lamont: did you read my email about util-linux patch?
<lamont> not yet
* lamont is still burried
<fabbione> ok
<lamont> generally, I've tried to not deviate from upstream unless there was good cause.  I haven't really looked at the 200+ line patch, but it seems to be relatively isolated in it's changes... something as invasive as the hurd patch won't be in until upstream takes it.
<fabbione> lamont: the patch is much smaller than it looks like
<lamont> right
<fabbione> due to static int foo it needs to move a function a few lines above
<lamont> it looks to be like it just calls the helper for the fs type if said beast exists
<lamont> ah, even better
<fabbione> exactly
<fabbione> so it's pretty simple in itself
<lamont> let me look at it tonight and I'll upload to both
<lamont> and fire it upstream
<fabbione> sure...
<fabbione> i think Manish did try to get it upstream with no success
<fabbione> or no response from upstream....
<lamont> right - upstream has bounced around a bit...
<fabbione> who is upstream? 
<fabbione> vietse?
<lamont> it might be semi-stable, esp since there's a new upstream version now as well
<lamont> adrian bunk, iirc
<fabbione> ah...
<lamont> the debian maintainer before me took it over upstream recently
<fabbione> ok
<fabbione> btw.. we are bumping ABI for the next kernel upload
<fabbione> so if you have something intrusive to push, it's the right time
<fabbione> AH GREAT.. the second sparc buildd managed to die in less than 12 hours
* fabbione sighs
<lamont> mtg
* lamont needs to isolate the ia64 acpi issue, but that will be later this week at the earliest.  likelihood of an ABI bump is >0
<lamont> just because acpi seems to be intrusive
<fabbione> lamont: if you build with ACPI disable, does it boot?
<fabbione> bah i come back to talk with Ben and he disappeared :)
* fabbione will teach BenC the way of the dark side of the force
<BenC> fabbione: ping
<fabbione> BenC: pong
<fabbione> i tought you left...
<fabbione> and i was close to go away :)
<BenC> sent you an email
<fabbione> yeah i just saw it...
<fabbione> i think there are 2 groups of bugs we are interested in..
<fabbione> USB and ACPI related
<fabbione> USB seems to be a royal pain
<BenC> yeah, I saw a lot of ACPI related bugs
<fabbione> ACPI is well.. mjg59 crack
<fabbione> but it still needs extra love...
<fabbione> on the other side we are already in Feature Freeze for Breezy
<fabbione> so we need to avoid extra breakage if we can
<BenC> right
<fabbione> .10 was a crappy release
<fabbione> too many patches coming from too many upstreams
<fabbione> .12 is looking quite good compared
<BenC> are there any show stoppers, or are the issued mainly non-regression things we want fixed?
<fabbione> show stoppers none that i am aware of...
<BenC> any serious regressions?
<fabbione> there is a Serial PATA patch that is sort of a problem
<BenC> PATA?
<BenC> or did you mean SATA?
<fabbione> we had a patch in hoary pulled from atadev for a mistake
<fabbione> #13298
<fabbione> (and other related bugs)
<fabbione> PATA...
<fabbione> zul: you need to learn to write Subjects in the email.. see.. i can't even copy paste without looking stupid :)
<BenC> hehe
<fabbione> the issue is that jgarzik almost crossburned me for inclusion of that patch
<fabbione> because it can cause data corruption
<fabbione> now everybody is including it and we are not....
<BenC> have the libata head patches been tested?
<fabbione> and tbh i have no fucking clue who to trust
<fabbione> they have been in hoary....
<fabbione> right now they are not in breezy
<fabbione> because i did expected to find them in .12
<fabbione> while they are not...
<BenC> anyone besides the submitter able to test things?
<fabbione> not from our team
<BenC> hardware specific testing....the downside to all this :)
<BenC> ok, I'll put that on my list
<fabbione> ehhe no shit!
<BenC> anything else?
<BenC> btw, I have my G4 installed with ubuntu now
<BenC> so I can test some ppc32 things
<fabbione> ah nice
<fabbione> it looks like Jeff didn't make too much noise on redhat bugzilla...
<fabbione> but the bug explains that:
<BenC> it's UP and only 512megs of ram, which is the stable type system that doesn't seem to show in most reports about ppc
<fabbione> a) ghetto pulled the patch from jgarzik HEAD
<fabbione> b) we pulled from ghetto
<fabbione> c) fedora and redhat did pull it from us
<fabbione> d) jgarzik that works for RH got pissed
<fabbione> GO FEDORA!
<BenC> who/what is ghetto?
<fabbione> gentoo
<BenC> ah, ok
<fabbione> dude.. you should know that by amok ;)
<BenC> lol
<BenC> Amok, the wiki of IRC
<fabbione> so true :)
<BenC> haven't worked with ATA much, but libata is a kernel driver library right? (not userspace)
<fabbione> yup
<fabbione> the patch is much much cleaner than the old one
<fabbione> it seems safe to me
<fabbione> BenC: did you manage to strech your wings on baz?
<fabbione>  http://sourceware.org/ml/binutils/2005-08/msg00190.html <- (from doko
<fabbione> BenC: but if you feel lucky i have a few tons of security bugs for hoary :)
<BenC> you can dump as much on me right now as you like...haven't been here long enough to be "busy" :)
<fabbione> BenC: ahahah
<fabbione> enjoy it till you can
<fabbione> BenC: get a bit familiar with the kernel build.. we have a bunch of extra features that debian does not have 
<fabbione> like the ABI checker..
<fabbione> and some extra madness in debian/rules...
<fabbione> like we build all from one source...
<fabbione> including udebs
<dilinger> fabbione: debian now builds all from one source, btw.. but not udebs.
<fabbione> dilinger: uh yeah...
<fabbione> sorry forgot about that
<BenC> To: bcollins@kernel.org
<BenC> sweet
<fabbione> ehehhe
<fabbione> i have the BAD feeling i just managed to fuck up the sparc buildd....
<BenC> impossible, sparc is unfuckable
<fabbione> i can manage..
<fabbione> :)
<fabbione> ah here it is
<fabbione> no shit it doesn't show anything on console..
<fabbione> the cable is disconnected....
<fabbione>  dists/breezy/main/binary-sparc/:Bus error
<fabbione> i guess sid is sort of broken...
<BenC> what command caused a bus error?
<fabbione> apt-ftparchive
<fabbione> after a glibc upgrade...
* fabbione attempts a downgrade
<BenC> c++
<fabbione> dpkg: /lib/libc.so.6: version `GLIBC_2.3.4' not found (required by dpkg)
<fabbione> AH CRAP
<fabbione> i should have downgraded dpkg first....
<fabbione> SEE I CAN MANAGE TO DESTROY SPARC! :)
* fabbione tries to remember how to unfuck that
<BenC> ar/tar
<BenC> maybe dpkg-deb will work
<fabbione> yeah..
<fabbione> ar x 
* fabbione heads to bed
<fabbione> night guys
<fabbione> cya tomorrow
#ubuntu-kernel 2005-08-21
<fabbione> morning
<lamont> gah... fabbione: I'll do that patch when I wake up
<fabbione> lamont: don't worry.. if it's ok with you i can upload both in debian and here
<fabbione> hey jbailey 
<jbailey> Heya Fabio
<fabbione> jbailey: we need to get klibc to build on sparc...
<fabbione> actually.. B-D can't even be satisfied
<jbailey> fabbione: Hmm, I thought it was building.
<jbailey> Which b-d?
<fabbione> on kernel headers?
<fabbione> you are still using the -1- abi reference...
<fabbione> we are up to 6 and soon to 7 :)
<jbailey> Ah, thought I had updated that.
<jbailey> Bloody abi bumps.
<fabbione> retarded klibc :)
<jbailey> *lol*
<fabbione> jbailey: the append to initr* patches...
<fabbione> i saw a bug about them...
<jbailey> I have a bug report for initramfs asking for vesafb and fbcon to be auto added on i386
<jbailey> I thought the kernels had all the framebuffer stuff built in automatically.
<fabbione> eh it did with initrd...
<jbailey> fabbione: I need to hack more on it.  The classic initrd case is OOPSing at startup, and I haven't troubleshot it yet.
<fabbione> placing the modules in /lib/modules/$ver/initrd
<jbailey> Sorry?  I'm having trouble following.
<jbailey> (My bad for telling you something else at the same time as you told me something)
<fabbione> fabbione@gordian:/lib/modules/2.6.12-4-686/initrd$ ls
<fabbione> capability.ko  vesafb.ko
<fabbione> the modules in that dir are automatically added to the initrd
<jbailey> Right, but I thought that you said that you inicluded all the necessary framebuffer things in the kernel for each arch.
<jbailey> So I didn't bother including them.
<jbailey> (There's alot of historical cruft in initrd-tools)
<fabbione> we build them as module.. and we ship them.. that's all
<jbailey> Ah, okay.
<fabbione> i don't include them automatically anywhere..
<jbailey> If you didn't, I wouldn't have a console on ppc...
<fabbione> jbailey: i think some arches must have fb in the kernel
<fabbione> others don't or can't
<jbailey> Ah, okay.  So it's a per-arch thing then.
<fabbione> yup
<jbailey> 'k
<fabbione> jbailey: the best thing you can do to see it, is to grab all -images- from jackass and dpkg -c them
<fabbione> to get an idea
<fabbione> something you can easily do from either chinstrap or rookery
<fabbione> i need to wake up my wife... brb
<fabbione> re
<fabbione> jbailey: klibc.. you said you were going or planned to change it to use l-k-h
<fabbione> if that doesn't work, i can still provide you with a meta package to B-D on
<fabbione> so you don't need to get too crazy about abi bumps
<fabbione> specially after release.. when we might bump ABI in a security update
<fabbione> and klibc won't build anymore
<jbailey> Right, it just hasn't been top on my priority list when sorting all the initramfs-tools stuff out.
<jbailey> Now that it's in use, I want to clean up things like this.
<fabbione> jbailey: ok..
* jbailey needs to go to sleep.
<fabbione> night jb
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: amd64 kernel on i386....
<fabbione> what B-D do i need?
<doko> libc6-dev-amd64
<doko> I'm not sure, if these headers really work at the moment, I didn't get feedback from jbailey yet. so you might try amd64-libs-dev instead
<fabbione> well i need something a bit more tested.. since i need to ask elmo to install these possible B-D on concordia
<fabbione> also.. what's the minimal version of gcc-3.4 that i need to use...
<doko> 3.4.4-6ubuntu4
<fabbione> ok
<Mithrandir> I think perhaps there is something in the hoary kernel which leaks loads of memory.
<fabbione> that's called X and GNOME
<Mithrandir> on a server?
<fabbione> you should have specified it before :)
<Mithrandir> :-P
<Mithrandir> my slabinfo showed me those nice numbers:
<Mithrandir> biovec-1          5925600 5925825     16  225    1 : tunables  120   60    0 : slabdata  26337  26337      0
<Mithrandir> bio               5925623 5925743    128   31    1 : tunables  120   60    0 : slabdata 191153 191153      0
<Mithrandir> which means it has allocated almost 6M objects of size 16 and 128, a grand total of ~850MB.
<Mithrandir> that hurts a bit when the box runs SA and some other stuff.
<Mithrandir> compared to the box freshly booted:
<Mithrandir> biovec-1            1347   1800     16  225    1 : tunables  120   60    0 : slabdata      8      8      0
<Mithrandir> bio                 1341   1581    128   31    1 : tunables  120   60    0 : slabdata     51     51      0
<fabbione> weird
<Mithrandir> nothing special here, runs apache2, random user processes, does have a raid5 with evms, but that's just devmapper.
<fabbione> hmmmm no idea really...
<Mithrandir> http://www.ussg.iu.edu/hypermail/linux/kernel/0506.3/0965.html
<Mithrandir> ah, it seems to be related to the fact that my SATA controller generates some spurious errors which then causes memory leaks in the raid code.
<fabbione> ah neat bug
<Mithrandir> yeah
<Mithrandir> oh well, I'm off to hack the live cd.
<fabbione> JaneW: ping?
<JaneW> fabbione: pong
<fabbione> JaneW: i need a little help with the wiki update...
<JaneW> ok
<fabbione> we agreed to make a list of deferred points inside specs
<JaneW> (thought you needed a name) ;)
<fabbione> but i am not sure how you want me to do that
<JaneW> which spec?
<fabbione> LinuxKernelRoadmap is 90% implemented, shipped, tested...
<fabbione> JaneW: name is for after Colony 3 release ;)
<JaneW> fabbione:  cool, what's deferred?
<fabbione> but there are still a few deferred points...
<fabbione> JaneW: the list of deferred points is in comments inside the spec itself
<JaneW> fabbione: once I create a deferred column and list the stuff there, you can make the LKR completed.
<fabbione> i did never change the specs, but only added comments on what happened/when and why
<JaneW> ok, I'll go look
<JaneW> oh in the spec...
<fabbione> same goes for InstallerVolumeManager...
<fabbione> JaneW: yes..
<JaneW> the ubuntu wiki is much slower that the UDU one...
<fabbione> that was the easiest to keep detailed track of stuff
<fabbione> without "altering" the original specs.. 
<fabbione> i did only add comments to them
<fabbione> sort of status tracker
<JaneW> fabbione: is it 2 items?
<fabbione> JaneW: ?
<fabbione> what do you mean by "2 items"?
<JaneW> fabbione: there's 2 things in the spec that says DEFERRED
<fabbione> checking.. i remember there were a bit more
<fabbione> there are more...
<JaneW> oh
<fabbione> i will update the page with "DEFERRED"
<fabbione> some of them are not capital letters :)
<JaneW> ok thanks
<JaneW> fabbione: can I make the rest of the goal completed (light green i.e. 100% done) ?
<fabbione> JaneW: yup...
<JaneW> YAY! *clap*
<fabbione> there.. page updated...
<JaneW> thanks
<JaneW> shew the wiki is SLOW
<fabbione> did i ever mention that i HATE wiki?
<JaneW> fabbione: hehe, ok I see 6 DEFERRED's now...
<fabbione> yes that's correct..
* fabbione updates InstallerVolumeManager
<fabbione> JaneW: InstallerVolumeManagement looks good enough for me
<fabbione> the last comment from 2005-07-14 is the same as reported to the meetingh
<fabbione> there are no updates since than
<JaneW> fabbione: has InstallerVolumeManagement had more testing yet?
<JaneW> fabbione: and do you think it will change before it can be marked completed?
<fabbione> JaneW: it won't change because we can't support our 3 arches
<fabbione> it will be completed for real in breezy+1
<fabbione> there is nothing we can do more for breezy
<JaneW> can I make it complete then? for purposes of tracking what need to be done now
<fabbione> JaneW: it's ok with me or we can move it to implemented -> deferred
<fabbione> because the real target of the spec can't be achieved
<JaneW> it is useable at all?
<fabbione> on the other side the logic has been implemented and it works
<Mithrandir> is the spec "LVM/EVMS by default" or "possible to use LVM/EVMS"?
<fabbione> yes yes.. it works
<fabbione> Mithrandir: yes
<Mithrandir> fabbione: "yes" is a terrible answer to an "or" question
<JaneW> ok, then lets say complete? Although are portions deferred, in which case I;ll add it to deferred as well?
<JaneW> Mithrandir: LOL
<fabbione> damn.. i can't workaround you ;)
<fabbione> "This spec considers our options for setting up logical volume management in the installer by default."
<Mithrandir> fabbione: do you think we can get a fix for the slab issue into hoary, it's kinda critical that servers run out of memory after a month.
<fabbione> Mithrandir: i think so.. i can pass it at memory leak/ddos
<Mithrandir> fabbione: great, thanks. :-)
<Mithrandir> just tell me if you need somebody to test the update
<fabbione> Mithrandir: well if you can test it yourself that'd be great
<Mithrandir> fabbione: that patch doesn't apply to -10, so we need to backport it a bit.
<fabbione> a one liner that doesn't apply is an issue...
* fabbione checks
<Mithrandir> the surrounding code has changed, but I think it's doable anyhow
<fabbione> Mithrandir: i can't find the code at all...
<fabbione> not even in .12
<Mithrandir> http://lists.debian.org/debian-kernel/2005/07/msg00231.html ?
<Mithrandir> it's relative to http://marc.theaimsgroup.com/?l=linux-raid&m=111155701929593&w=2, I think
<fabbione> the first patch you pasted is in .13 git
<fabbione> and it applies to a function called
<fabbione> super_written
<fabbione> that's not in .10 or .12
<Mithrandir> the missing link is in the theaimsgroup link, though
<JaneW> fabbione: ok InstallerVolumeManagement is completed in the main table and listed in deferred too, I hope that is ok.
<fabbione> Mithrandir: the patch at http://lists.debian.org/debian-kernel/2005/07/msg00231.html seems to be the correct one
<fabbione> JaneW: sure.. that's fine
<fabbione> Mithrandir:
<fabbione> static int sync_page_io(struct block_device *bdev, sector_t sector, int size,
<JaneW> fabbione: all your goals are completed - you can go on holiday again ;)
<fabbione> on line 332 has been splitted into 2 functions
<fabbione> that's why it doesn't apply 
<fabbione> JaneW: i would love to.. but i guess somebody won't be happy about it :)
<fabbione> JaneW: i still need to push the SoC stuff in...
<fabbione> Mithrandir: if you can test that patch, i will add it as security thing for hoary
<fabbione> given that a memleak is NOT good
<Mithrandir> fabbione: ok, I'll do that.  Can you prepare images or should I?
<fabbione> now.. time to prepare some food and to get a long break
<fabbione> Mithrandir: up to you.. if you can do it > *
<JaneW> fabbione: yes I hope the SoC stuff completes well, and I could give you some more goals if you are looking? ;)
<fabbione> otherwise give me time till tomorrow.. i guess i will have to prepare a hoary security update
<fabbione> JaneW: thanks but i have enough stuff to do :)
<JaneW> :)
<Mithrandir> fabbione: tomorrow is fine for me, I'm trying to find out wtf is up with the live cd atm
<fabbione> + give a head up to BenC
<fabbione> Mithrandir: ok
<fabbione> security...
<fabbione> update packages around...
* fabbione is already tired at the second day of work
<fabbione> anyway.. long break time now
<TheMuso> c
<TheMuso> argh
<TheMuso> sorry
<TheMuso> 
<JaneW> fabbione: ping
<fabbione> JaneW: pong?
<JaneW> fabbione: what's up with NFSRoot? (jbailey is not around), there are no comments listed at all
<fabbione> JaneW: it's part of ltsp/EarlyUserSpace...
<fabbione> it works :)
<fabbione> i will check with jbailey to update the wiki
<JaneW> ok thanks :)
<JaneW> fabbione: xen - is your student working on that whole goal? or only part of it? Is it justified in moving over to WIP?
<fabbione> JaneW: xen?? you just told me to forget about it yesterday :)
<JaneW> oh right, sorry that's Ed...
<JaneW> Mithrandir! ping
<zul> heylo
<Mithrandir> JaneW: pong
(JaneW/#ubuntu-kernel) Mithrandir: are we likely to get anothing completed there for Breezy, or will it need to be deferred?
(Mithrandir/#ubuntu-kernel) that depends on whether I should concentrate on getting it into ok-ish shape or not.
(Mithrandir/#ubuntu-kernel) I think it's doable for breezy
(Mithrandir/#ubuntu-kernel) but at the moment I'm not working on my goals but rather picking up various loose threads around.
<fabbione> JaneW: i doubt there is a chance to get Xen for breezy
<fabbione> that means a FeatureFreeze breakage
<fabbione> + ENOTIME to do a deep test
<Mithrandir> fabbione: it'd be universe for now.
<Mithrandir> and yes, mdz wouldn't be happy about the freeze exception
<fabbione> imho it's pointless to spend that many resources for a universe package
<Mithrandir> (I'd imagine)
<fabbione> given that the patch in 2.0.6 is for .11
<fabbione> and porting it to .12 is a pain
<zul> fabbione: i have some stuff in my arch for you to merge
<fabbione> there is just too much work that needs to be done, without even be sure that it will work
<fabbione> zul: good boy :)
<zul> fabbione: do i get a cookie :)
<JaneW> fabbione: hmmm, don;t think mdz will allow that - so shall I defer?
<fabbione> JaneW: yes. let's get it done properly for breezy+1
<fabbione> JaneW: unfortunatly upstream and us are way too much desynced
<fabbione> zul: with choccolate too ;)
<zul> wohoo!
* fabbione baz gets zul
<zul> now if only dell would get off their butts
* fabbione will soon go offline for brain crashing
<fabbione> i woke at 5am today!
* fabbione needs some sleep
<zul> meh...toodles
* fabbione goes offline
<fabbione> later fellas
<lamont> fabbione: building now
<lamont> actually, there were some other issues that I want to look at for -6
<fabbione> lamont: -6 ?
<lamont> util-linux 2.12p-6
<lamont> and -6ubuntu1
<fabbione> ah ok
<zul> fabbione: eh? i though you got stuff from my arch?
<lamont> fabbione: but I'm also going to go to lunch, and email upstream before I upload. :-)
<fabbione> zul: not yet.. i did a checkout.. look at it and merge :)
<fabbione> lamont: ehhe sounds a good plan
<fabbione> zul: i meant.. i did a checkout.. now i need to look at them and merge :)
<zul> i understand fabbione speak..
<fabbione> zul: die
* fabbione goes for dinner
<lamont> fabbione: it should be uploaded before reasonable people are awake in your area tomorrow. :-)
* lamont lunches
<fabbione> lamont: ahaha ok :)
<fabbione> hmmm pasta today is going to be good...
<fabbione> i love to cook the tomato souce on very low fire...
<lamont>   * Use helper program in mount for guessed FS types too.  Thanks to Manish
<lamont>     Singh and Fabio Massimo Di Nitto.  Adds: 20guesshelper.dpatch
<lamont>   * Remove /usr/doc links on install.  Closes: #322806, #322816
<lamont>   * Fix /usr/bin/pg pager alternative.  Closes: #323204
<fabbione> it takes longer but it tastes 3 times more
<fabbione> super
<BenC> hey fab
<lamont> fabbione: please make RTC not be a module anymore in ubuntu kernels (assuming it still is)
<lamont> http://bugs.debian.org/50572
<jbailey> lamont: Hey - did that glibc update fix your hppa troubles?
<jbailey_> What populates /lib/modules/$(uname -r)/initrd?  Is that an upstream decision or something the kernel team does?
<fabbione> hey BenC
<fabbione> lamont: we can't compile it for all arches
<fabbione> some of them don't have standard RTC
<jbailey_> fabbione: Heya.
<fabbione> jbailey_: we populate it manually.
<jbailey_> Okay, so I'll just trust that you guys will continue to handle that directory for now.
<jbailey_> I had missed it in the initramfs-tools stuff.
<fabbione> jbailey_: i would love to kill it..
<fabbione> if you want you can take it over via initramfs
<fabbione> it's only wasted space on duplicate modules
<jbailey_> That would work too.  How do you decide what goes in?
<jbailey_> fabbione: It's hardlinked, so there's no wasted space.
<fabbione> jbailey_: i don't decide.. really. i found it from warty and ported forward..
<jbailey_> fabbione: Mmm..  Then let's leave it there for now and decide for 6.04
<jbailey_> It's the least amount of work for me to just pull it from there, and then at least we can handle it during feature hacking time.
<fabbione> sure
<fabbione> works for me
<fabbione> lamont: i will look at it again, but i remember that problem...
<zul> laster
<lamont> jbailey: dunno - haven't gotten there yet
<jbailey> lamont: Well, even on your test build, though.
<fabbione> jbailey: libc seems to be broken on sparc
<lamont> jbailey: I thought it was a gcc front end fix
<fabbione> it makes apt-utils -> apt-ftparchive segfault
<jbailey> fabbione: Just this most recent update?
* lamont was offline from wed thru sunday, hopingto worry about things later this week,
<fabbione> jbailey: i did try both debian 2.3.5-3 and our latest
<lamont> kyle was playing with the debian side of things, and planning to followup with me afterwards
<lamont> jbailey: you're referring to the GOT issue?
<jbailey> lamont: Whatever the issue was that commenting out that patch was.
<jbailey> Was that the GOT issue, or was that a different one?
<jbailey> fabbione: Hmm.
<lamont> jbailey: commenting out the patch fixed that issue.
<jbailey> lamont: 'k
<lamont> the new issue is that we have GOT abs syms in shlibs, which makes many things unloadable.
<fabbione> jbailey: it actually leads to a "Bus Error"
<jbailey> lamont: Mmm, tasty.
<jbailey> fabbione: Right.  But why do you think it's glibc?
<fabbione> because downgrading glibc make it working again?
<lamont> gcc.gnu.org/PR23369
<jbailey> fabbione: glibc doesn't generally do memory allocation, it may have had something in it before that was forcing alignment by doing an extra copy or something that doesn't exist now.
<jbailey> fabbione: We'll need to trace it to the call before it SIGBUSes and figure out what it's being called with.
<fabbione> jbailey: the bus error comes right during a pread
<fabbione> iir
<fabbione> iirc
<jbailey> Right, so is the buffer that's handed in correctly alligned?
<fabbione> i will need to do it again in a chroot
<jbailey> Sure, we can play dueling screen sessions again. =)
<fabbione> jbailey: yes.. but not before i finish to download a few torrents :)
<fabbione> i am not in the mood to stop them now
<jbailey> fabbione: I'm about full up for today anyway.
<fabbione> jbailey: dude.. it's like 10pm here :)
<jbailey> Exactly. =)
<fabbione> jbailey: did you install your sparc?
<jbailey> No, I've been away the past few days.
<fabbione> ah right...
<fabbione> forgot about that
<jbailey> Reminds me that I should ask Simon is I can borrow his null modem cable to get it setup.
<fabbione> jbailey: make one...
<fabbione> it's easy ..
<jbailey> I used to have a nice breakout box for doing things like that.
<fabbione> yeah i need to get one again
<fabbione> speaking of which... i need the console cable for the U60
<fabbione> BenC: do you happen to have the schema of the connectors around?
<fabbione> U60 has the big fat female (DB25) 
<fabbione> to connect to a normal serial port (9 pin or whatever it is now)
<BenC> schema?
<BenC> you just need a regular serial cable, and a NULL modem terminator on it (or a NULL cable)
<BenC> regular 25-9 pin adapters work ok with the sparc serial too
<fabbione> BenC: hmm weird... i saw the SUN guy using a DB25 to RJ45 -> Cisco RJ45 (all crossed) -> RJ45 DB9
<fabbione> the other solution didn't work..
<BenC> ugly
<BenC> I have a 25pin cable, with a 9-25pin adapter and a null term
<fabbione> that's what i tested..
<fabbione> i will try again
<BenC> should work
<fabbione> http://edition.cnn.com/2005/US/08/16/computer.frenzy.ap/index.html
<fabbione> AHAHHAHA
* fabbione goes to sleep
<fabbione> cya tomorrow fellas
<jbailey> g'n fabio
#ubuntu-kernel 2006-08-14
<wordsofglass> hi, i just compiled a kernel according to the FAQ and comp is a lot faster, but mounting extra drives wont work, it tells me they're mounted or the folder is busy; i do have all the fs-types compiled into the kernel
<wordsofglass> not sure if this is the place to ask
<infinity> It's not.
<infinity> This isn't a support channel, but rather a kernel development channel.
<infinity> (For Ubuntu-specific kernel development, obviously)
<wordsofglass> sorry, i realized after looking at the channel list categories
<wordsofglass> support vs devel team channels
<lifeless> hi
<lifeless> any chance of us enabling the callgraph option, which oprofile needs to get callgraph data ?
<crimsun> lifeless: For Dapper/Edgy? What needs to be tweaked? The callgraph patch on oprofile.sf.net seems to already be in ubuntu-dapper.git, and oprofile is modularised.
<lifeless> well
<lifeless> I'm not an oprofile expert
<lifeless> but when I follow the faq info for getting callgraph data
<lifeless> it generates no parents/children
<lifeless> (this is using dapper)
<crimsun> sorry, I don't have any experience with it either
<zul> hey
* pschulz01 waves
<doko> BenC: will the xfs corruption bug be fixed in the dapper kernel?
<BenC> doko: If I recall the bug report, there was no clear and simple update to fix that bug
<BenC> basically meant backporting the entire xfs tree
<doko> ouch
<doko> BenC: so the answer is yes, or maybe later?
<BenC> doko: the answer is "not unless the fix becomes a lot easier"
<BenC> I'm a little reluctant to backport an entire fs
<zul> you can do it!
<zul> heh
<kbyrd> infinity: ping.
<kbyrd> ok, anyone: infinity has said that he would include the vmware-player-kernel package into the l-r-m build for edgy. What would be the deadline for that? 
<BenC> kbyrd: I'll probably be able to get to it with the next kernel upload
<BenC> it's an ABI bump anyway, so perfect time to do that
<BenC> kbyrd: is there a place to download stock tarball's for this?
<kbyrd> Cool. But, we're considering releasing vmware-server as a deb, and we would have a vmware-server-kernel package too. So, I need to know when I have to get that to you.
<kbyrd> BenC: about the tarball, there isn't a stock tarball of just the modules (it's not a separate installer for us normall). But, the current package includes the source and makefiles. 
<BenC> ok, I'll pull from that
<kbyrd> But, last time I talked to someone. the l-r-m build isn't going to include our modules, it's going to build the entire package. The reason for this is that we actually need to have two packages: vmware-player-kernel and vmware-server-kernel.
<kbyrd> They can't co-exist.
<kbyrd> You guys don't have vmware-server-* yet. But in my version, they conflict with vmware-player-*
<kbyrd> So, I still need to get a deadline for handing off vmware-server-kernel to you all to be included in edgy.
<BenC> the sooner you get them to me, the sooner I'll get it done :)
<BenC> basically I'll keep vmware-player-kernel in l-r-m package proper, and build vmware-server-kernel in separate package
<BenC> l-r-m package will provide vmware-player-kernel to satisfy any deps
<BenC> hmm, wait
<BenC> they'll both need to be separate packages
<BenC> but I can do that easily
<BenC> mdz: ping
<mdz> BenC: pong
<BenC> mdz: I'm in the middle of running an extensive benchmark test on -386 vs. -686 on my UP P4 2Ghz system
<BenC> I'm going to do the same on my Athlon64 UP system with -amd64-generic vs. -amd64-k8
<BenC> and the same on my SMP xeon
<BenC> just to see if these alt kernels are giving us _any_ performance improvement (and my bet is that they aren't)
<mdz> BenC: thank you, it's high time we had some hard data to work with
<mdz> BenC: SMP/dual-core support out of the box in Edgy would be valuable
<BenC> good thing is that most systems with SMP/dual-core fall into the amd64 category, so they already get it, but with Intel's CoreDuo coming out, that will change
<BenC> $ cat /proc/version_signature 
<BenC> Ubuntu 2.6.17-7.19-amd64-xeon
<BenC> that's going to be a useful little file
<mdz> indeed indeed
<mjg59> BenC: Coming out? There's been shipping Core Duo hardware since February...
<BenC> mjg59: I meant CoreDuo2, sorry
<mjg59> BenC: Core Duo 2 is amd64
<BenC> CoreDuo 2 is emt64
<mjg59> Well
<mjg59> The scheduling is close enough, surely?
<BenC> oh, I get what you mean now :)
<mjg59> Heh
<mjg59> Yes, the ones where we're losing are the original core duos
<BenC> I thought some of the CoreDuo2 was 32-bit still
<BenC> maybe I need to reread the docs
<BenC> I know there's CoreDuo2 - emt64, and CoreDuo2 - ia64
* kylem_ looks at BenC.
<mjg59> BenC: Pretty certain there's no ia64 ones
<BenC> damnit, you ppl are going to make me open this powerpoint on windows, aren't you? :)
* BenC goes to recheck his facts
<kylem_> it probably says "Dual Core Itanium2"
<BenC> it was all convoluted into a big PPT file, so it's understandable if I got all the 100 name combinations mixed up
<kylem_> :)
<mdz> mjg59: regarding our discussion about the ondemand governor, will it only appear in available_governors if it works properly? or do we need to be cleverer than that?
<mdz> it seems to work OK on the systems I have access to, so I don't know what the other case looks like
<mjg59> mdz: We need to be cleverer than that
<mjg59> Hm. At least, I think so.
<mjg59> It might be cleverer than I think
<mjg59> The failure will be that attempting to set the governer to ondemand will fail
<mjg59> In that case, we probably want to fall back to powernowd
<mdz> oh, that's easy enough then
<zul> hey
#ubuntu-kernel 2006-08-15
<TheMuso> BenC: Thanks. Seems like someone has already taken your fixes upstream.
<BenC> TheMuso: which ones?
<TheMuso> The module loading, and the semaphore fixes.
<TheMuso> As well as the ppp serial header adjustment.
<TheMuso> ppc 
<BenC> excellent
<BenC> that was quick :)
<TheMuso> Daniel drake from Gentoo must be following it, as he is the one who committed the fixes.
<TheMuso> I don't know if you are also aware, but there was a commit to CVS recently that I submitted to add a keyboard command for laptop keyboards. I can send you a patch if you'd like.
<BenC> yes, please do
<TheMuso> sent. Thanks again.
<TheMuso> BenC: I would like to build a test kernel from git to test the speakup stuff. Is there a way that I can build only one kernel flavour, i.e just i686?
<BenC> TheMuso: See the CategoryKernel wiki in the topic, there's a link on that page to a "howto build" wiki page
<TheMuso> Ok thanks.
<BenC> TheMuso: or you can wait one day, and the daily builds will be up (URL is in the topic)
<TheMuso> Yeah I saw that too. Cheers.
<BenC> mdz: ping
<mdz> BenC: pong
<BenC> mdz: email with benchmarks sent
<BenC> mdz: basic idea is, there's little to no difference
<BenC> same results for amd64 kernels
<BenC> mdz: the best numbers to look at are the Ratio's to the no_load
<BenC> the Time columns is also important
<BenC> I'm still running a UP amd64-generic vs amd64-k8 test, but I don't expect it to be any different
<mdz> BenC: that looks pretty compelling to me
<BenC> mdz: just say the word
<mdz> BenC: we should discuss on ubuntu-devel; mind if I forward your email?
<BenC> sure
<pschulz01> Greetings.. I am going to be 'lurking' here.. but is there anything that I should be aware of (other than what is in the channel subject line?)
<pschulz01> the plan is to learn and start contributing where I can.. I have various embedded archtectures I can test on (if relevent) and an older (non-intel) Mac Mini.
<mdz> BenC: do you have any pointers to documentation which explains what the figures mean?
<BenC> pshel: welcome, nothing really to explain really :)
<mdz> pschulz01: there's some information at https://wiki.ubuntu.com/KernelTeam, though the time-related stuff is out of date
<BenC> mdz: contest.kolivas.org
<mdz> thanks
<pschulz01> mdz: Thanks.
<pschulz01> BenC: Is ther much that needs doing?
<BenC> pshulz: bug maint is the main thing we need, but we only have light documentation on the wiki for kernel bug triaging
<BenC> sorry, I keep misspelling your name
<pschulz01> BenC: How many packages does the team/you look after?
<BenC> well, kernel is mainly linux-source-2.6.17 (edgy) 2.6.15 (dapper) 2.6.12 (breezy) and 2.6.10 (hoary)
<pschulz01> BenC: that's OK :-)
<BenC> we also maintain linux-restricted-modules and linux-meta
<pschulz01> Can I put that on the Wikipage :-)
<BenC> and to some degree, other packages like initramfs-tools, kernel-package and kernel-wedge
<mdz> BenC: you want to read over this before I send it, or just get it when it hits the list?
<BenC> mdz: you can just send it...doubt there's much I need to read over
<BenC> pschulz01: just keep it simple...the less we have to maintain the info the better
<pschulz01> BenC: I need somewhere to keep notes :-)
<BenC> kylem_: ping
<pschulz01> BenC: Have a look at https://wiki.ubuntu.com/KernelTeam
<pschulz01> BenC: Is there a lauchpad page?
<mdz> pschulz01: launchpad.net/people/ubuntu-kernel-team I believe
<pschulz01> BenC: launchpad
<BenC> make sure you get the right one
<BenC> there are two kernel teams, one has about 6 members, and the other is empty
<BenC> choose the one that has members
<BenC> I'm waiting for the launchpad folks to implement team merging
<BenC> pschulz01: you can kill the news portion. Looks great though, thanks!
<pschulz01> BenC: I need an administrator to add me.. 
<BenC> I'll get the request
<pschulz01> Done..
<BenC> mdz: nice email, thanks
<kylem_> BenC, pong.
<pschulz01> BenC: The Launchpad team is listed as 'restricted', as opposed to 'moderated'.. so it doesn't look like you'll even get my request to join.
<pschulz01> BenC: Some final changes to https://wiki.ubuntu.com/KernelTeam otherwise will switch back to lurk mode.
<pschulz01> My shipit CD's just arrived..
<pschulz01> 70 CD ROMS - 50 PC; 5 Mac/PowerPC; 15 AMD/64Bit + 40 Stickers.
* pschulz01 apologises.. related.. but wrong channel.
<mdz> BenC: np.  I just got a panic when unplugging a slightly flaky USB device, and got an oops in khubd.  worth a bug report?
<crimsun> hmm. the old ndiswrapper-1.1 source package in main generates a ndiswrapper-utils-1.1 binary package that apparently doesn't work with Edgy's kernel.
<BenC> edgy's ndiswrapper kernel module has been updates...maybe the userspace tools need to be as well
<BenC> crimsun: ^^
<BenC> mdz: I think given the lack of any real problems with the proposal, I'm going to move forward with the image conversions
<BenC> I'm not going to upload till I get to germany
<BenC> so if there's any problems, we can schedule a dev session for it :)
<mdz> BenC: sounds good
<mdz> BenC: so what are your thoughts on the naming?
<BenC> mdz: -386 will remain as an alternate kernels
<BenC> -generic will become the standard kernel
<mdz> and -generic will be fairly close to what -686 is now? (SMP-enabled)
<BenC> basically it will be the same as the k7/686 kernel, but targeted at 586 and above (386 is targeted at 486 and above)
<BenC> amd64 will have -generic (which is just a rename of the -amd64-generic kernel) and remove the -xeon and -k8 versions
<BenC> -amd64-server will be renamed to -server too
<BenC> so we're killing three kernels
<BenC> I'm also considering droping the non-smp kernels on ia64, since I doubt there's many non-smp ia64's around
<BenC> I've never heard of any at least
<thom> i'm pretty sure the workstation ia64s were uniproc
<thom> (or the low end ones anyway.) http://www.ia64-linux.org/machines/zx2000.html
<mdz> sounds good
<BenC> thom: it may just have to run an smp kernel if they want to use it
<BenC> we force ppc64 users to run an smp kernel
<thom> fair enough.
<BenC> I never hear anything from ia64 users anyway :)
<BenC> probably will change with the new Itanium2 chips, bu then they are multi-core anyway
<BenC> mdz: lrm has a "base" kernel for each arch...are we saying we want -generic to be base for i386 now?
<mdz> BenC: what does that mean?
<BenC> the standard kernel used for installs and most running systems
<BenC> I think linux-meta makes the distinction as well
<BenC> lrm uses it for udeb creation
<mdz> I don't see why lrm should care
<BenC> it doesn't create udebs for all kernels
<mdz> if it's for udebs, then it should be the kernel we use on the alternate CD
<mdz> which will continue to be -386
<BenC> because the liveCD doesn't need udeb's, correct?
<mdz> correct
<BenC> ok
<mdz> linux-meta is trickier, since we use that on both
<BenC> linux-meta is going to be tricky because it's gaining a lot of rename cruft :)
<maswan> BenC: Hey, a question, I got buried behind real work and stuff, did you get any time for a -dbg or similar kernel package with vmunix?
<BenC> maswan: we've had linux-image-debug-* for several kernel versions now
<BenC> well, several revisions of the edgy kernel
<maswan> BenC: ah, awesome. we're just getting around to upgrading to dapper. :)
<maswan> BenC: thanks and keep up the good work
<BenC> maswan: np
<mdz> BenC: nvidia-kernel-common recommends nvidia-kernel-source | nvidia-kernel.  should the kernel provide nvidia-kernel or should we do away with that business entirely?
<BenC> do we even need that package?
<BenC> I guess we do
<BenC> I'd say remove it
<BenC> that package is just a dep of the lrm stuff, so it gets pulled in when needed
<BenC> I mean remove the recommends
<zul> BenC: i have an 2.6.17ish xen kind of working
<BenC> that sounds vaguely cool :)
<BenC> mdz: we only support single release upgrades, right (like you can't upgrade directly from breezy to edgy)?
<zul> 2.6.18 xen was cherry picked and back ported now just to cherry pick edgy
<kylem_> BenC, you pinged last night?
<BenC> kylem_: I forget why
<kylem_> k :)
<zul> grrr...suse sucks
<mdz> BenC: correct
<infinity> BenC: That said, I entertain bug reports about skipped-release upgrades, if the upgrade path doesn't take me more than 10 seconds to divine and hack into a maintainer script.
<infinity> (With most packages, we get that for free anyway, since Debian's release cycle is slower, so they handle most upgrade paths)
<BenC> just wondering how long I should keep linux-meta upgrade meta-packages
<BenC> like the ones we had in dapper for -686-smp, and the ones that have been there for who knows how long for power[34]  kernels
<BenC> I think I'm going to kill off the power cruft
<BenC> leave the {686,k7}-smp for one more release
<zul> so what is the end result going to be?
<zul> so i can reflect it with the xen bits
<BenC> zul: i386 => generic (standard kernel), 386, server, server-bigiron
<BenC> amd64 => generic (standard kernel), server
<BenC> hppa and ia64 are getting their -smp versions cut (basically it will be SMP only for those arches, but no biggie)
<zul> ok cool..
<zul> ill make my changes as well
<BenC> mdz: hey remind me to give you back that euro power adapter you lent me in paris
<mdz> BenC: ah, so that's where it went
#ubuntu-kernel 2006-08-16
<zul> hey
<AnAnt> what is the version of ieee80211 & ipw2200 that is in Edgy ?
<crimsun> git-1.1.13 and git-1.1.1, respectively
<AnAnt> is there a reason that the latest versions are not used ?
<crimsun> because they're in 2.6.17?
<crimsun> have you asked Ben to pull from upstream's git overlays, etc.?
<crimsun> (or provided patches)
<AnAnt> oh
<AnAnt> Ben who ?
<AnAnt> what does upstream's git overlays mean ?
<crimsun> AnAnt: BenC; the git overlays refer to what's referenced on {ieee80211,ipw2200}.sf.net
<AnAnt> oh
<AnAnt> BenC is a bot ?
<crimsun> no, he's a real live human being who happens to be the kernel lead.
<AnAnt> oh
<AnAnt> oh, you mean that Ben=Benc
<AnAnt> that was 2 answers
<AnAnt> ok, I got it, thanks
<AnAnt> you got an idea how to install new firmware for ipw2200 ?
<AnAnt> yes, I will ask BenC
<AnAnt> BenC: u awake ?
<crimsun> new firmware? I don't see anything referenced on http://ipw2200.sourceforge.net/firmware.php
<AnAnt> I downloaded the firmware, but dunno how to install it
<crimsun> AnAnt: it's already included in both Dapper and Edgy linux-image* binary packages.
<TheMuso> AFAIK it has actually been inclulded as early as warty/hoary, but I am not entirely sure about that.
<crimsun> Breezy I think was the earliest.
<TheMuso> Right. Well I am pretty sure the 2100 firmware was included earlier.
<crimsun> oh, sorry, Hoary.
<AnAnt> crimsun: what is included ? the firmware ?
<AnAnt> crimsun: you mean the latest version of firmware is already included ? how can I check that, do you know ?
<crimsun> AnAnt: the latest is in Dapper & Edgy.
<AnAnt> crimsun: thanks 
<crimsun> TheMuso: well, apparently (happily) I'm incorrect. It's in Warty, too.
<TheMuso> Right.
<TheMuso> Because I remember just being able to use my ipw2100 on my notebook in warty without any problems.
<crimsun> must be my senility ;)
<TheMuso> Not at all.
<dilinger> anyone know what the timeline is for the next dapper kernel?
<dilinger> i see benc's last commit was 5 days ago or so
* TheMuso remembers he wanted to grab a kernel daily to test with.
<TheMuso> ...or maybe not.
<AnAnt> crimsun: ok, if I compile new versions of ipw2200 & ieee80211 will I need to reinstall the firmware ?
<crimsun> no
<AnAnt> cool
<AnAnt> thanks
<zul> hey
<ajmitch> hi zul 
<zul> .win 10
<zul> damn it
<hackdown> hi guys
<fabbione> BenC: 
<fabbione> headers-i386            i386                    x86_64
<fabbione> this is in debian/config/archmap
<fabbione> x86_64 ?
<fabbione> (edgy)
<BenC> fabbione: the i386 hdr_install target only installs the x86 headers
<BenC> while the x86_64 target installs the x86 and x86_64 headers
<fabbione> yeah but that map was supposed to install the x86 headers
<fabbione> so you are shipping both in both x8 and x86_64...
<fabbione> x86 even
<fabbione> if so it's all good
<BenC> we are shipping both in i386 and amd64
<fabbione> yup ok then
<fabbione> you win :)
<BenC> :)
<fabbione> BenC: i am going to take some fancy hw down to Germany so we can have some fun
<fabbione> i have a bunch of flash/memory cards for pcmcia
<fabbione> a webcam
<BenC> any ide-cd pcmcia type cards?
<BenC> err, ide-cs
<fabbione> nope :(
<fabbione> i can get scsi-cs
<fabbione> from gdd
<BenC> ide-cs is causing some crashes in certain situations
<fabbione> but i am not sure if i will get to see him before i get down to germany
<mjg59> Flash for PCMCIA is generally ide-cs
<fabbione> ok
<fabbione> i don't remember how linux look at them
<fabbione> they are old intel flash
<fabbione> and i remember i managed to make them work once with 2.4
<fabbione> that's it
<Mithrandir> I could bring an pcmcia-to-smartmedia card with some memory.  Would that do?
<mjg59> Almost certainly
<zul> right im heading home for a nap c ya later
<mdz> BenC: I will bring Mark's device (the one I reported a bug about) to Wiesbaden
<BenC> mdz: ok, Mark promised me some keyboard time on his system in Wiesbaden for that and two other bugs
<BenC> he's not going to be there?
<mdz> he is
<mdz> but I have his PCMCIA card
<mdz> here with me
<BenC> I may be able to test that directly on my pb
<zul> hey
<dilinger> BenC: what kind of timeframe are you planning for the next dapper kernel upload?
<dilinger> i'm currently using a git snapshot for a cd; it would be nice to use a proper release :)
#ubuntu-kernel 2006-08-17
<BenC> dilinger: probably about two weeks unless some nasty security issue comes up
<dilinger> oh, ok
<mjg59> BenC: I sent you a couple of patches
<mjg59> Did you get those?
<mjg59> (Some time last week)
<dilinger> guess i'm sticking w/ the git checkout, then; i'm be working for a different company by then
<dilinger> thanks
<BenC> mjg59: don't show them, but I had issues last week with email
<BenC> mjg59: can you resend?
<mjg59> BenC: Sure
<BenC> thanks
<BenC> mjg59: Might be better to send them to kernel-team@
<BenC> either way is fine though
<mjg59> BenC: Will do in future
<mjg59> On their way to you now
<zul_> BenC: ping did you do anything special for ipw3945?
<BenC> infinity: ping
<infinity> BenC: pong
<BenC> infinity: I have a lrm 2.6.17.3-1 upload pending
<BenC> it contains a crap load of changes for the new kernel flavours plus vmware-player modules
<infinity> Oh, we got the clickwrap removed?  Yay.
<BenC> there was never a click-wrap on the kernel modules, just the player itself
<infinity> Can you put it somewhere, and I'll roll new fglrx crap into it as well, and upload for you?
<BenC> kbyrd ok'd the inclusion, and I checked the package, and he was right
<infinity> Yeah, no idea why they originally did it seperately, then.  Oh well.
<infinity> Did you add their license to the incresingly huge debian/copyright?
<BenC> I can give you access while I'm in germany (willing to bet the hotel has better upload b/w than I do)
<BenC> not yet, but will
<BenC> just got the build working and tested
<BenC> I don't plan on doing the next kernel upload till next week, so that's when lrm will get uploaded to
<infinity> Oh, then I guess I can do my LRM changes now, then.
<infinity> And you'll just have to re-roll your .orig to include them. :P
<BenC> no!!
<infinity> (Or, trickle that upload at chinstrap now, and I'll just tidy up)
<BenC> there's lots more changes than just the orig :P
<infinity> Oh, but it matches the new kernel.  Right.
<infinity> Feh.
<infinity> Stupid renames and such.
<BenC> yeah, but it's actually a lot cleaner
<infinity> Well, I want the new fglrx to happen soon, so I guess we have no choice but to merge later.
<BenC> basically just a new tarball for fglrx?
<infinity> Assuming it builds, yes.
<BenC> I can merge your changes into mine (easier than merging mine into yours :)
<infinity> Yeah.
<infinity> My changes will be minimal.
<infinity> New tarballs, changelog, maybe a tweak to debian/rules, and maybe a patch or two.
<infinity> But nothing big.
<BenC> I can incr diff -1 and -2, so no biggy
<infinity> Well, .3-1 and .4-1, but yeah. :)
<infinity> (Since it's a new .orig both times)
<infinity> Whee.
<BenC> oh, duh
<BenC> so you're still not coming to wiesbaden?
<infinity> Yeah.  Just can't do it right now, sadly.
<infinity> I'll be at the next conf, with bells on.
<infinity> Perhaps literally.
<BenC> I'll see if I can find a place that serves "Massive Destruction Weapon's" and drink one for you :)
<infinity> I don't even remember what was in it..
<infinity> It was like a Long Island with a shot of Kahlua or something.
<BenC> probably a good idea not to remember what was in that thing
<infinity> Not bad, just not ideal to have 6 in a row.
<BenC> especially since I think the bartender started making it up
<infinity> I'm seriously never going to live that down, am I?
<infinity> shawarma keeps poking fun at me for those things too.
<infinity> The dude had almost as many as I did, so I'm don't think he has a leg to stand on.
<infinity> s/I'm/I/
<lifeless> it does not sound like either of you had legs to stand on:)
<BenC> infinity: it was definitely a funny site...wish I had stuck around till you made it into the bathroom and scared the janitor :)
<zul> hey
<Keybuk> Recent changes to -mm include a reworking of the serial ATA configuration options ("If you blindly run `make oldconfig' you won't have any disks.")
<Keybuk> mmmm
<infinity> Keybuk: Awesome.
<Keybuk> http://lwn.net/Articles/194866/
<Keybuk> interesting
<zul> hey kbyrd 
<kbyrd> hey zul.
<mdz> BenC: please remember to update all of the seeds approximately in sync with the kernel renames
<BenC> mdz: Can I do that, or does someone else need to?
<mdz> BenC: you can do that
<BenC> mdz: ok, but I don't know how :)
<BenC> is it a package?
<mdz> https://wiki.ubuntu.com/SeedManagement
<BenC> thanks
<zul> later..
<AnAnt_> BenC: you there ?
<BenC> AnAnt: yes
<AnAnt_> BenC: ok, I wanted to suggest some things
<AnAnt_> BenC: using latest version of ipw2200 instead of the one supplied with the kernel
<AnAnt_> BenC: the one supplied is 1.1.1 , while latest is 1.1.3
<AnAnt_> BenC: and same for ieee80211 driver
<BenC> please file a bug report for that against linux-source-2.6.17
<BenC> ieee80211 probably wont be updated
<AnAnt_> why's that ?
<BenC> too many wireless drivers are dependent on it
<AnAnt_> oic
<AnAnt_> so ?
<BenC> updating it tends to break existing drivers
<AnAnt_> oh ok
<AnAnt_> BenC: btw, my MMC card reader used to work in dapper
<AnAnt_> I tried knot1 and it didn't work
<BenC> do you have certain reasons for these suggestions?
<BenC> ok, please file a bug about that too
<BenC> attach dmesg from dapper and edgy boots
<AnAnt_> BenC: well, I needed to run aircrack-ng
<BenC> what is that?
<mjg59> BenC: We dropped support for TI parts in the sdhci driver and you haven't merged the replacement yet
<BenC> mjg59: is that your patch?
<mjg59> Yes
<AnAnt_> BenC: and I found on the website, that to inject packets, I have to use the latest ieee80211 & ipw2200 driver (and also patch ipw2200 driver )
<AnAnt_> aircrack-ng: Wireless WEP/WPA cracking utilities
<BenC> AnAnt: what constitutes "latest" for ieee80211?
<BenC> because we have a fairly recent version in edgy
<AnAnt_> BenC: the one I got is 1.1.14
<AnAnt_> the one in edgy is git-1.1.7
<BenC> no, the one in edgy is git-1.1.13
<BenC> include/net/ieee80211.h:#define IEEE80211_VERSION "git-1.1.13"
<AnAnt_> mjg59: you mean TI card readers won't be supported anymore ?
<BenC> AnAnt: no, he means we lost the patch that enabled support, it just needs to be reapplied
<AnAnt_> BenC: maybe that was after Knot1 ?
<AnAnt_> oh ok
<BenC> very possible, but if you install Knot1, and then upgrade to latest, you should be good
<AnAnt_> so do I still need to file a bug report on that MMC matter ?
<mjg59> No
<AnAnt_> ok
<BenC> mjg59: I don't see a TI patch in sdhci's git history
<mjg59> BenC: We shipped one in dapper
<AnAnt_> BenC: ok, I'll try using ipw2200-1.1.3 with the ieee80211 that is in edgy
<mjg59> It did mad fudging to a bit in pci config space if there was a TI card
<BenC> fudge_ti() ? :)
<mjg59> But now there's a separate driver for the part instead
<BenC> so your patch will add that separate driver, I understand now
<BenC> AnAnt: your TI sdhci should be fixed in the next edgy kernel, no need to file a bug
<BenC> mjg59: both your patches are for edgy?
<AnAnt_> back to the ipw2200, is it possible to add that patch (that enables injection) too ?
<BenC> AnAnt: I'll see about updating ipw2200 as well
<BenC> depends on how intrusive and ugly it is
<mjg59> BenC: Both?
<BenC> send it to me, bcollins@ubuntu.com
<mjg59> BenC: Oh, everything I've sent is for edgy, yes
<BenC> mjg59: I have two patches from you right now
<BenC> ok
<AnAnt_> what do you mean by "intrusive" ?
<BenC> I mean it changes too much
<AnAnt_> ok
<BenC> plus I need to be sure it isn't opening up any security issues...that sort of patch is tricky
<AnAnt_> ok
<AnAnt_> where do I file the request ?
<BenC> just email me the patch, bcollins@ubuntu.com
<BenC> I'll give it a quick review
<AnAnt_> ok
<AnAnt_> BenC: sent
<AnAnt_> thanks  !
<crimsun> BenC: thanks for the merges!
#ubuntu-kernel 2006-08-18
<Keybuk> BenC: so, I've been thinking about the whole PATA thing
<Keybuk> it's going into 2.6.19 right?
<BenC> from what I hear
<Keybuk> and I thought we were going to the Hurd for edgy+1
<zul> hmm?
<Keybuk> zul: did nobody mention that?
<zul> meh...im not paying attention right now...
<zul> hmm...must go watch big brother
<infinity> Must?
<infinity> That reads like "hmm...must go clamp testicles in vice"
<zul> yeah i have to go loose brain cells
<kylem> if you have some to spare, why don't you share? :)
<infinity> kylem: You want my spare testicles?
<kylem> i could always use more.
<kylem> never know when you might need them.
<infinity> I suppose not.
<zul> ewwww..
<BenC> mjg59: Your patches are integrated
<infinity> zul_: *poke*
<infinity> zul_: Why are xen-headers-* and xen-image-* in "Section: base"?
<infinity> zul_: I'd expect "devel" for the headers, and I dunno, maybe "admin" or "utils" or something for the images (though, I guess if they're meant to run on both the host sytem and the client, they'd be about as "base" as the normal linux-image-* ones)
<infinity> zul_: The headers are definitely misplaced, though.
<zul_> infinity: ok ill fix thanks
<zul> BenC_: ping...mind if i keep the xen stuff in a hg repo
<BenC_> zul: how you maintain it is up to you
<zul> ok
<zul> i should have something for you this weekend
<zul> meh...2.6.18 fails..
<zul> fixed that one
<zul> BenC: 2.6.18 builds with xen
<BenC> zul: no
<jwest-> hasnt dell been offering amd with their copmputers for awhile now
<zul> BenC: hmm?
<BenC> zul: hmm, I typed no, but I meant to type "cool"...no idea how that happened :)
<zul> sure sure..i heard that one before ;)
#ubuntu-kernel 2007-08-13
<rapflap> any info on this bug : soft lockup detected on CPU#0!  ? I generally need to boot like 3-4 times before i get past splash screen.. and can this have anything to do with my wifi crashing and forcing me to reboot to get net back ?
<kraut> moin
<asac> hi .... any hints how i could prepare something to let users test new ipw3945 drivers?
<asac> e.g. there are a few changes listed on http://ipw3945.sourceforge.net/ for 1.2.1, 1.2.2 which appear to address issues that constantly pop-up with that chipset.
* Starting logfile irclogs/ubuntu-kernel.log
<lamont> kylem: just wanted to make sure that my hppa64 fixes (lamont/hppa-ia64.git) are going to make .26....
<kylem> yes, and if you keep pestering me, i'll revert it.
<Nafallo> kylem: are you planning an upload that will make Turion tickless? :-)
<kylem> no, i'm planning an upload that will let crap amd cpus boot.
<Nafallo> ooh. sounds as good. any ETA or should I just keep watching? :-)
<Nafallo> would be great for me before Thursday actually ;-)
<mjg59> Hm. My Quickcam Express seems to have stopped working.
<doko> BenC, kylem: lpia kernel ping, would it be possible to build the kernel udebs, plus the various module packages for lpia?
<kylem> er.
<kylem> someone told me last time i uploaded that there was no need for d-i.
<kylem> but ok.
<doko> thanks
#ubuntu-kernel 2007-08-14
<lucas_> hi... 
<lucas_> someone know a howto work with lmks on kernel 2.6???
<lucas_> how is in this chat?
<zul> BenC: ping https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/125855 it sounds sane but im not sure
<defendguin> i just thought i would check to see if anyone in here knows how usplash works  i think i broke it 
<kraut> moin
<Kmos> Hi! gutsy will have kernel 2.6.22.2 patches applied ?
<mjg59> It's likely
<Kmos> nice
<Kmos> thx
<Kmos> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131957 - Gutsy Tribe 4 live CD don't boot
<Kmos> can someone ask for seveas to put ubotu here? it's nice for bug Number :)
<mjg59> Kmos: Clearly not a kernel bug
<mjg59> I suspect a bad CD
<Mithrandir> Kmos: no, ubotu shouldn't be here
<Kmos> mjg59: I'll ask him to do a md5sum check
<Kmos> Mithrandir: ok :(
<hroo772> is anyone around, i was wondering what the proper way to request a change would be? like in launchpad?
<zul> yes
<Kmos> hi
<Kmos> i'm thinking on changing https://wiki.ubuntu.com/Bugs/Responses#head-45808066734637ee99b63d089b514e2dff49b231 in kernel general
<Kmos> because the adicional information asked is already at https://wiki.ubuntu.com/KernelTeamBugPolicies
<Kmos> so the finally work will be something like http://paste.ubuntu-nl.org/33697/
<hroo772> I was wondering if I should be subscribing a group to this bug report I just created
<hroo772> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132478
<hroo772> nevermind, its taken care of
<lamont> amitk_: you around?
<amitk_> lamont: barely :)
<lamont> I noticed a few commits merged, was debating panicking that mine wasn't one of them...
<lamont> hppa should go live in the DC this week, so things will be better integrated for getting the abi files in, I expect.
<lamont> hrm... actually, it almost looks like I could do it myself.
<lamont> nah.  kernel_devs != kernel_team
<amitk_> I am not sure if kylem was planning on doing those.
<lamont> as in you don't want to do it if he was, or it might be out-plan for -9.26?
<amitk_> I could do them tomorrow. Kyle said something about uploading a kernel tomorrow though.
<amitk_> as in it's 1am and I don't trust the commit right now :-p
<lamont> We have been "this close" to actually building a kernel for going on 6 or 7 weeks now.
<lamont> if it's not in -9.26, I'll have to escalate it
<amitk_> lamont: I will leave a message for kylem to do it today. Else I will do it tomorrow evening. Does that work for you?
<lamont> works
<amitk_> lamont: done
<amitk_> as in.. sent the message
<lamont> the big issue is that it's mucking with the abi files without an abi bump. and yeah.
<lamont> given that there isn't a kernel in the archive before that, though, it's not an abi change... :-)
<amitk_> lamont: That ABI muck is why I don't trust myself to touch it while I am sleepy. :D Good night now. I am out of here.
<lamont> amitk_: it's actually just a git cherry-pick and be done (only changes things in hppa-land)
<lamont> gnight
#ubuntu-kernel 2007-08-15
* #ubuntu-kernel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
* Starting logfile irclogs/ubuntu-kernel.log
<joris_> I have a rather odd feisty problem. Machine with a core2quad cpu with a 2.6.20-16-generic kernel works very fast, altough with only 3.2 out of 8GB of ram. Installing the 2.6.20-16-server kernel halves disk IO speed (measurably) and subjectively decimates CPU performance... I'm at a complete loss
<joris_> I filed a bugreport containing some more info https://launchpad.net/ubuntu/+bugs?field.searchtext=2.6.20-16-server&orderby=-importance&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<joris_> wrong url, sorry
<BenC> joris_: are you trying 32-bit or 64-bit kernel?
<joris_> 32bit
<BenC> Try 64-bit
<fabbione> hey BenC 
<BenC> hey fabbione
<joris_> (hmmz, I can't seem to find my own bugreport on launchpad..)
<joris_> bug id #132577
<joris_> BenC: do you mean to install an x86_64 optimized kernel, or switching the entire distro to 64bit?
<BenC> well, you have to do the entire distro
<joris_> ouch
<BenC> but you could just do a kernel, but it wont be easy
<joris_> it's supposed to become a fat server (for thin clients) for a school... they'll need some 32bit apps like flash
<joris_> BenC: apt-pinning feisty/amd64 for linux-image*?
<fabbione> no you can't use pinning for this
<BenC> this is taking a .deb by hand and dpkg-deb extract/control -> build
<BenC> and having to continue doing it for security updates
<joris_> hmm... not fun
<BenC> you can't use a chroot for the 32-bit thin clients?
<joris_> is it a known problem? is it worth the effort to try to bugfix this?
<fabbione> joris_: are you using LTSP ?
<fabbione> or some manually crafted thin client installation?
<BenC> it's not a bug...just 32-bit can only handle but so much (the slowdown on -server is a bug though)
<joris_> BenC: possibly yes, but I'm having enough trouble getting LTSP up and running without doing an arch transposition
<joris_> fabbione: no, edubuntu ltsp :)
<fabbione> joris_: ok. i suggest you wait one hour or so and talk to ogra
<fabbione> joris_: i think he did put some work into running an amd64 server with 32bit thin client for flash and stuff
<joris_> aha
<joris_> he'll be on here?
<fabbione> he is no kernel expert but he is the LTSP guru
<joris_> nice :)
<fabbione> in #edubuntu or #ubuntu-devel
<joris_> I'll see if I can remotely reinstall the machine to amd64
<fabbione> but he is not awake yet for what i can see
<fabbione> i'd recommend to talk to ogra first
<fabbione> and see what's the best way to handle it
<joris_> well, I don't know yet if going to amd64 will fix the lack of performance
<BenC> joris_: you could try booting an amd64 livecd and see what it would do
<BenC> pretty sure it would handle the memory a lot better
<mjg59> joris_: Your BIOS doesn't set MTRRs for the upper memory
<mjg59> So it's all flagged as uncacheable, and performance sucks
<mjg59> It's unlikely that using a 64-bit kernel will help her
<mjg59> e
<BenC> ah, there's a better answer
<mjg59> We really need PAT support in Linux, but nobody's written an implementation the maintainer is happy with
<joris_> mjg59: hmmm
<joris_> mjg59: that's not good
<joris_> and this is why I recommended using a server board, but they wanted to save 100 bucks
<joris_> mjg59: the effect is really surprisingly strong btw
<mjg59> Yes, it will be
<mjg59> The machine will be basically unusable
<joris_> it's not like a 10% slowdown, it's more like a 95% slowdown
<joris_> it is indeed
<joris_> mjg59: anything I can try to objectively measure this?
<mjg59> joris_: Not really - it'll depend on workloads and where in memory stuff gets allocated
<mjg59> The bottom ~4GB is probably flagged cacheable, but the kernel will be loaded higher
<mjg59> So if your code is in the cacheable region and doesn't make any syscalls, it'll probably run fairly fast
<joris_> hmmm
<joris_> without programming C there is no way to put a benchmark util in upper or lower memory, I presume
<Mithrandir> take out half the memory and see if it improves vastly?
<mjg59> There's no way to do it at all
<mjg59> You're at the mercy of the kernel in terms of where your app ends up
<joris_> Mithrandir: that's what happens with the desktop kernel, presumably
<joris_> mjg59: ok :(
<mjg59> It's a genuine failing in Linux to implement PAT, but it's also a BIOS issue to fail to set the MTRRs sanely
<Mithrandir> joris_: presumably, yes.
<mjg59> You can boot with different values of mem= to find the maximum you can get away with
<mjg59> joris_: Adding the output of cat /proc/mtrr to the bug would be helpful
<joris_> mjg59: is there any logic in the values to try?
<joris_> mjg59: will do so
<mjg59> joris_: Look at /proc/mtrr. Figure out the highest address that's flagged write-back or write-through.
<mjg59> That's the maximum amount of RAM you can use
<joris_> okay
<joris_> as soon as the machine finishes installing sysinfo (half an hour and counting)
<joris_> mjg59: it's attached
<mjg59> joris_: Thanks - what was the bug number, again?
<joris_> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/132577
<joris_> what does write-combining mean?
<mjg59> joris_: Looks like you're not going to get more than 3584MB
<mjg59> joris_: http://en.wikipedia.org/wiki/Write-combining :)
<joris_> ouch :(
<mjg59> The mtrrs simply don't cover more than that
<kraut> moin
<joris_> mjg59: do you know off hat what unit/syntax does the kernel mem= parameter accept?
<joris_> 'mem=xyzM' ?
<mjg59> Yeah
<joris_> mem=3584M it is then
<mjg59> Might end up needing to be slightly lower than that
<mjg59> But give that a go first
<joris_> okay, here goes nothing
<joris_> that worked :)
<mjg59> Excellent
<joris_> it's most likely an intel 965-based motherboard
<mjg59> Yeah
<mjg59> All you can really do at this point is check for a bios update, I'm afraid
<joris_> yep... makes sense :/
<mjg59> Or wait for PAT support
<joris_> I'll break the bad news
<zul> morning
<lamont> morning zul
<zul> hi lamont how goes it?
<lamont> generally pretty well
<zul> good
<instabin|work> Is any one working on getting the nvidia 100.14.11 drivers in to gutsy
<infinity> Yes.
* Starting logfile irclogs/ubuntu-kernel.log
<NativeAngels> hello
<NativeAngels> is there anyone in here who knows about unrealirc and neostats
<mjg59> NativeAngels: This sounds like the wrong place to ask
<NativeAngels> i know
<NativeAngels> sorry
<verwilst> hellow!
<NativeAngels> hello
<verwilst> i'm building the -xen kernel for amd64
<verwilst> i did an apt-get source linux-source-2.6.22
<verwilst> and then debuild
<verwilst> but this will take aaaages :)
<verwilst> is there an easy way to only build the -xen kernel?
<verwilst> ):
<verwilst> it's done "build-generic  build-server  custom-build-rt  custom-source-rt" so far :)
<verwilst> btw any reason why -xen is i386-only?
<verwilst> and not amd64?
<JanC> verwilst: because it doesn't compile on amd64 AFAIK  :)
<verwilst> oh?
<verwilst> we'll soon know =-
<verwilst> :)
<verwilst> i'm compiling it now
<JanC> I might be wrong, but I'm sure there must be a good reason
<verwilst> i could really use an amd64 version of the -xen though :)
<verwilst> the 2.6.18 from xensource has ext3 corruption
<verwilst> as i experienced :p
<JanC> Xen patches seem to be constantly outdated compared to current kernels anyway  :)
<verwilst> yeah
<verwilst> maybe i should just use a 32bit system instead of a 64bit..
<verwilst> but 64bit is a lot faster imo
<verwilst> does the -generic have pae?
<JanC> hm, what's the kernel config option for PAE again?
<JanC> anyway, there are -server kernels too
<verwilst> i need to use -xen, stupid me :)
<verwilst> 32bit, with -xen
<verwilst> can i go over 4GB RAM with it?
<JanC> I have no -xen kernels installed
<JanC> I guess they support > 4 GiB of RAM if the patch allows for it
#ubuntu-kernel 2007-08-16
<verwilst> linux-image-xen woooooorks
<verwilst> :d
<verwilst> 32bit, but still :)
<verwilst> just installed libc6-xen, if it does what i think it does, i won't need to move /lib/tls either :)
<verwilst> suhweet!
* verwilst thanks all kernels devs!
<TheMuso> c
<TheMuso> ugh
<kraut> moin
<amitk_> lamont: ping
<amitk_> lamont`: ping
<lamont> amitk_: si?
<amitk_> lamont: your last patch made changes to all hppa configs. Did you run updateconfigs after that?
<lamont> amitk_: effectively
<lamont> config vars appear in either config, or both of the others, never all 3.
<lamont> and they'll be changing again before release - this is really an interim set of configs
<lamont> so they're not exactly in the order that updateconfigs would create, but they're of the same consistency.
<amitk_> lamont: updateconfigs is basically reverting back to the oldconfigs. Try a git pull and run updateconfigs
<lamont> maybe I'll do that on an hppa box. :-)
<lamont> note that updateconfigs on i386 has errors for ia64, and fails in hppa (since hppa-linux-gcc isn't on the system)
<amitk_>  ll hppa-linux-gcc
<amitk_> lrwxrwxrwx 1 amit amit 12 2007-07-03 18:24 hppa-linux-gcc -> /usr/bin/gcc
<lamont> debian/scripts/misc/oldconfig: line 66: /home/lamont/linux-source-2.6.22-2.6.22/debian/scripts/misc/splitconfig.pl: Permission denied
<amitk_> it works around the problem, but it is a bug
<lamont> that needs to be chmodded.
<lamont> in the makefile'
<lamont> with the hppa-linux-gcc link installed, and a bit of research, we find that lamont is a liar.
<lamont> grep 'CONFIG_SECURITY[^_] ' debian/config/hppa/*
<lamont> debian/config/hppa/config.hppa32:CONFIG_SECURITY=y
<lamont> debian/config/hppa/config.hppa64:CONFIG_SECURITY=y
<lamont> update configs (properly) moves that to config
<lamont> and the other change is to remove more parameters from config.hppa64, which my hand edits didn't remove.
<lamont> IOW, if you want to commit the result of updateconfigs, don't hold back on my account.
* lamont commits that in his tree
<kylem> push it out asap and it will go in the next upload.
<amitk_> lamont: great
<lamont> pushing now
<lamont> db6e512aa46b6d22bae7c48aed72b778c192dc70
<lamont> aka the only diff in the tree
<lamont> and there now
<lamont> sorry about taht
<kylem> i've already done testbuilds, so if that breaks something, so help me god....
<lamont> kylem: I verified that the sum total change to the hppa output configs is non-consequential.  and those are the only files changed in the commit
<lamont> did hppa get a test build too??? *blush*
<kylem> no.
<kylem> in fact, i'm rather certain sparc is going to break. oh well.
<lamont> that's what rapid turns are for, right?
<lamont> :-)
<kylem> indeed.
<amitk_> kylem: before I forget, can you mail me your scripts to farm out testbuilds
<kylem> amitk_, ah, i haven't used them in a while, so it will take some archaeology to dig them out.
<kylem> i'll make a note to find those for you.
* lamont will be afk for quite a bit
<kylem> i've only been testing on i386 and amd64 atm.
<amitk_> kylem: so you did a manual build?
<amitk_> kylem: ahh ok
<kylem> yeah
<kylem> i have a bind mounted dir into both chroots and just kick them both off from the same git checkout
<kylem> er, rather, two checkouts, sharing objects
<geser> Hello, I've tried to sync rootstrap (bug #130640) as pbuilder-uml depends on it. But as rootstrap is on the blacklist it can't currently be synced.
<geser> Can rootstrap be removed from the blacklist or should the pbuilder-uml package be dropped? Or is there an other solution?
<gnyffel> Can anyone tell me if the new 2.6.22.3 kernel update will be in Gutsy? It is my understanding that as a rule, only security updates will be provided, and that newer releases are held off until Gutsy+1. 
<gnyffel> Oh well.
<tormod> re bug #121959, how can I see what changes has been done from the upstream source to the l-u-m?
<rtg> tormod: http://kernel.ubuntu.com/git
<tormod> I forgot to add "easily" and that I am git-challenged :)
<rtg> tormod: 'git clone git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy-lum.git ubuntu-gutsy-lum' will put the source on your machine.
<tormod> rtg thanks, I'll give it a try. When I browse the gitweb tree down to a prism2 file and look at the history: nothing
<tormod> ok, I've got the source now, but where is the changelog? patches? reference to upstream source?
<rtg> tormod: you can view history by using 'git whatchanged', e.g., 'git whatchanged ubuntu/wireless/prism2_usb'. In this case its not very helpful since nothing has changed. It doesn't look like Ben recorded the original version.
<rtg> tormod: debian/changelog has lots of stuff.
<tormod> rtg, debian/changelog doesn't mention prism2 :(
<tormod> Benc, can you please have a look at bug #121959? prism2 is broken in Gutsy.
<bdmurray> rtg: ping
#ubuntu-kernel 2007-08-17
<kraut> moin
<verwilst> hi!
<verwilst> I seem to be having a problem when starting xend. As soon as the xen-br0 bridge is up, i can only ping to the server. telnetting to port 22 shows it's connected, but the ssh id string never comes through. ssh'ing on the server itself to localhost still works fine.. Anyone has a clue, or had a similar encounter?
<verwilst> Could this be a kernel issue?
<verwilst> (using 2.6.22-9-xen )
<joris> mjg59: are you on?
<Riddell> 2.6.22-9 will be the version for tribe 5 I presume?
<verwilst> hi Riddell
<mjg59> joris: Hi
<joris> mjg59: remember my mtrr problem yesterday?
<joris> I updated the bios, /proc/mtrr is promising
<joris> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/132577
<mjg59> joris: Excellent
<joris> but my first try by removing the memory limit results in a slow system
<joris> I added up the size segments
<joris> and it adds up the the total memory
<joris> so maybe I was a bit too quick not setting any mem limits at all
<mjg59> joris: Hm. Yeah, try setting one a few megabytes off the top
<joris> ok
<joris> like 8100
<joris> works like a charm :)
<mjg59> joris: How high can you go until it breaks?
<superm1> Hi guys, I was wondering if what the reason was that the rtc.max-user-freq was set low?
#ubuntu-kernel 2007-08-18
* Starting logfile irclogs/ubuntu-kernel.log
<juliux> hi all
<JanC> hi juliux :)
<juliux> hey JanC 
<juliux> JanC, http://www.ubuntuusers.de/paste/13940/ any idea why i dont get an ip address?
<JanC> this channel isn't exactly the right place to ask support questions, but it looks like your DHCP doesn't work?
<juliux> JanC, dhcp is working it is only the thinkpad with the atheros card which is not working
<JanC> firewall?
<JanC> hm, I'm not sure what """46 Aug 18 17:56:34 ubuntu dhclient: wifi0: unknown hardware address type 801""" means...
<juliux> JanC, i am asking here because prism cards and intel cards are working fine, only atheros is not working
<JanC> on the same laptop?
<JanC> probably not (as intel has no "cards")
<juliux> intel ipw2200 on a hp notebook. prism ist as usb-stick and ipw 3945 in a desktop pc
<juliux> and on the accesspoint is an other atheros card in master mode working
<JanC> did you try the prism usb stick on that thinkpad ?
<juliux> yes, its working without any problems
<JanC> so, probably no firewall problem or similar  :)
<juliux> jap
<JanC> maybe NM doesn't work with atheros...
<juliux> hmm now the atheros card is working but not with my selfbuild accesspoint
<juliux> so perhaps it is a problem with two atheros cards:(
<JanC> might be incompatible config too
<juliux> could be
<juliux> but on this laptop has to work everything it is the notebook for my girlfriend
<JanC> :)
<JanC> can you configure wireless manually?
<JanC> or does it work without encryption?
<juliux> without encryption, wep and wpa are not working
<verwilst> 2.6.22-9-xen is greaaaat!
<verwilst> i have a domU centos5 and gutsy running on it :)
<JanC> juliux: of course without encryption WEP & WPA don't work, but if it works without encryption on the AP, that might give an indication of where the problem is  :)
#ubuntu-kernel 2007-08-19
<MrEmbedded> I was wondering why there was a chann for ubuntu's kernel
<MrEmbedded> is ubuntu's kernel diff from the other kernels?
<MrEmbedded> special patches or something?
<crimsun> Ubuntu's kernel source contains numerous git changesets (exportable as unified diffs via git), yes
<crimsun> kernel.ubuntu.com/git/
<crimsun> (ubuntu/ubuntu-*.git)
<MrEmbedded> thx
<SirBob1701> how do you enable xgl in the nvidia 100.14.11 drivers on a desktop?
<SirBob1701> oo i have to use composite dont' it
* Starting logfile irclogs/ubuntu-kernel.log
<kraut> moin
<laga> moin
<Layer8> hi
<Layer8> when I try to make-kpkg clean i get an error that tells me something about infiniband is missing...how can I fix this?
<defendguin> ubuntu gutsy is not going to support the Quirk framework?
<mjg59> Which quirk framework?
<defendguin> http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html
<mjg59> We have something analagous already
<mjg59> But it's nothing to do with the kernel
<defendguin> when i come back from a suspend there is a little bubble saying my computer didn't suspend properly and it provides a link to that website 
<mjg59> That suggests two things
<mjg59> (1) g-p-m is wrong about the failure to suspend
<mjg59> (2) we shouldn't be linking to that website
<mjg59> Could you file bugs about both of them?
<defendguin> yes i can 
<defendguin> mjg59: i don't suppose you have had any problems where you keep getting a keyboard press event and the only way for you to break out of it is to suspend?
<mjg59> Nope
<johanbr> A bug already exists for the reported suspend failure, https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/89983
<defendguin> mjg59: mjg59  how would i be able to see what is going on with the keyboard?   thats not something that dmesg would tell me
<mjg59> Does it continue to happen if you change VTs?
<defendguin> i can't change VT's because the keyboard is not responsive 
<JanC> mouse ?
<defendguin> i only have one desktop with several viewports i dont think it works the same way does it
<mjg59> No
<mjg59> Almost certainly a kernel bug
<defendguin> i would say it happens once every few days and it just happened about 10 minutes ago
<johanbr> defendguin: On what kind of hardware is this? That happens to me too if I associate/de-associate from my wireless AP a couple of times. I think the bcm43xx driver is to blame.
<defendguin> nope   i have an intel card
<defendguin> its a lenovo 3000 n100
<defendguin> and my association to the AP has been constant for an hour or so
<defendguin> mjg59: how would i go about reporting this keypress bug  and what would you like included with it?
<mjg59> defendguin: File it against linux-source-2.6.22 and include dmesg
<defendguin> https://bugs.launchpad.net/ubuntu/+bug/133352
<defendguin> hmmmm
<defendguin> i never tried his solution to the problem
<mjg59> defendguin: Wait,you only get it after suspending?
<defendguin> i don't reboot that often so it is very very likely that this is true 
<defendguin> I will be certain to look for it happening before i suspend the first time after a reboot
<defendguin> i guess if you look at the dmesg output it will note where i suspended at but i can't see in there where i had the keypress problem
<mjg59> If it doesn't happen immediately after a suspend, then it's unlikely to have anything to do with suspend
<defendguin> well this guy said it happens randomly 
<defendguin> which is how i would describe my issue 
<defendguin> ha this guy is also using a lenovo made pc
<defendguin> his is a thinkpad though 
<defendguin> mjg59: any other info i can add to help out with this bug?
<superm1> Hi guys.  I was wondering if inclusion of DKMS was  planned to be addressed for gutsy's release cycle.  The bug is assigned to the kernel team currently but is listed as wishlist.  https://bugs.launchpad.net/ubuntu/+bug/121676
#ubuntu-kernel 2008-08-11
<benje> hello bug about amilo resolved the amd74xx bug was due to CONFIG_IDEPCI_SHARE_IRQ to NO 
<benje> you have to set it to no 
<benje> and cdrom is ok 
<benje> how can ia do a simple patch for ? 
<benje> hi
<alex_joni> benje: first find the bug at launchpad, then add the info there
<Kano> did somebody try that next kernel? i updated it to kernel git but still rt2x00 is broken and i get dmi bios error that it wants acpi=force
<Ng> which alsa is in intrepid?
<Ng> please say 1.0.17 ;)
<Kano> thats in 2.6.27, in 2.6.26 is 1.0.16
<Ng> Kano: but afaics ubuntu uses a separate ALSA from the kernel anyway, 'cos it's in LUM
<Kano> Ng: only 2.6.24
<Kano> there is no lum for 2.6.26/7
<Ng> oh
<Ng> bah
<Ng> 1.0.17 has a bunch of new hardware support :/
<Kano> then delete buildin alsa and compile it externally
<Kano> modprobe -l|awk /snd-/|xargs rm -f
<Kano> then the kernel ones are gone away, compile alsa manually
<Ng> I already rebuild LUM with 1.0.17 for my laptop, but there are plenty of users for whom that isn't a realistic option :)
<Ng> perhaps lbm could contain 1.0.17?
<abogani> https://lists.ubuntu.com/archives/kernel-team/2008-August/002867.html
<Ng> aha
<Ng> I'll wait for ben to wake up then :)
<BenC> TheMuso: your zinc account is done
<BenC> Ng: ?
<Ng> BenC: aha :)
<Ng> BenC: I was wondering about the possibilities of alsa 1.0.17 getting into intrepid
<Ng> my laptop is entirely silent with .16, as are some others aiui
<BenC> Ng: it's highly possible....not for Alpha4, but shortly after
<BenC> Ng: is that a regression?
<Ng> no, it was never supported in hardy, it required new code in hda_intel to work
<Ng> I've been building my own LUM with 1.0.16 removed and 1.0.17 put in ;)
<Ng> I've encountered at least one other person with newer hardware than .16 supports, so my guess is that several hda_intel variants are new enough to only be in .17
<Ng> obviously this will always be the case, but if we can sanely do it, then I'd be very happy to see it :)
<BenC> Ng: Can you test 2.6.27-rc2 deb's from http://kernel.ubuntu.com/pub/next/2.6.27-rc2/ ?
<BenC> Ng: It's got LUM built-in (like intrepid)
<Ng> sure
<Ng> should it JustWork with hardy userspace?
<TheMuso> BenC: Thanks.
<TheMuso> Ng: I'm actually going to be looking at backporting important driver fixes/updates from 1.0.17 to hardy's 1.0.16 alsa-driver code.
<Ng> TheMuso: aha, well I'll probably be running Intrepid in the next month if I stick to my usual schedule, but I'm sure there are people who will be sticking with hardy for a lot longer who'd appreciate something like that
<TheMuso> Ng: Yeah, supporting newer sound hardware for hardy, at least for a while, is something that IMo needs to be done.
<Ng> TheMuso: well my suggestion would be to start with hda_intel - my impression is that that covers more current hardware than any other driver. I could be wrong, that's just my guess ;)
<TheMuso> Ng: Yes thats one of the ones being considered.
<Ng> :)
<BenC> Ng: it's a good guess :)
<BenC> Almost anything coming out today is based on HDA, whether it's AMD or Intel chipset
<Ng> it's a bit weird that there are so many variants though
<TheMuso> IMO weird is an understatement.
<BenC> Ng: it's more than weird, it's hugely irritating
<mjg59> Ng: Multiple different codecs that can be attached, and then vendors can wire them all up in different ways
<BenC> Ng: the main thing is that HDA just defines a way to access the codec...it doesn't have a built-in way to define the pin-outs, so they have to be hardcoded :/
<mjg59> Oh, there's a definition
<mjg59> It's just often ignored
<mjg59> The BIOS is supposed to provide a table
<Ng> ahhh. by which I mean "ugh" ;)
<BenC> mjg59: that's funny...I assumed it didn't because more often than not, new hardware doesn't work out-of-the-box
<mjg59> I think Linux has occasionally been poor at using the BIOS information, but also vendors are poor at putting anything in there
<mjg59> The Windows .inf files usually contain the pinouts
<mjg59> What /would/ be nice would be some way of using the .inf to teach the kernel
<BenC> mjg59: Tim and I talked about doing that, but never got around to looking at it
<Ng> sounds like something Wubi would be able to harvest pre-install
<mjg59> Yeah
<Ng> but useless to those of us who stab windows in the face when deboxing a laptop ;)
<mjg59> If you've got the driver CD, there's still hope
<BenC> deflowering I think is the term you were looking for :)
 * TheMuso is personally not a fan of recovery partitions.
<Ng> yeah in this laptop's case there were no CDs in the box, it's pure recovery partition, but naturally I stabbed that in the face too. I'm probably an atypical user though, and I like the idea of being able to steal information from .inf files more generally :)
<BenC> Ng: let me know if that 2.6.27-rc2 kernel works for you...I plan on using sound/ out of that for intrepid/2.6.26 kernel
<Ng> BenC: will do, I'll give it a try when I get home
<rtg> BenC: where is the root partition remounted? Is that done in initramfs? In particular, I'm curious how file system options are applied after the initial mount.
<BenC> rtg: remount is done in init scripts from the root partition
<rtg> BenC: checkroot.sh ?
<BenC> rtg: looks right
<abogani> rtg, BenC: Sorry to bother you. Are there some chance to have an linux-restricted-modules-source package (as i requested in https://lists.ubuntu.com/archives/kernel-team/2008-August/002871.html)?
<BenC> abogani: we're considering making it spit out dkms packages instead, which will get it working for any kernel installed (including -rt)
<abogani> BenC, Wow! it would be great! One less package to handle! :-)
<_gAri-> hi there, can you please help me out where can I find the ubuntu specific kernel patch in peaces that is applied to the vanilla kernel? I mean I only want to use parts of it, not totally
<mjg59> _gAri-: It doesn't exist
<mjg59> _gAri-: If you download the Ubuntu kernel git tree, you can extract individual patches from it with git
<_gAri-> can you give me a clue how to do that?
<_gAri-> I'm not a kernel developper, I just want to patch a vanilla kernel with the apparmor version ubuntu uses, and PAX or grsecurity.
<_gAri-> actually if I patch a vanilla kernel with apparmor myself, it says that the profiles are malformed or something like this
<mdz> has anyone looked at bug 255635?
<mdz> https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/255635
<bdmurray> superm1: Do you have any ideas about bug 257003?
<superm1> bdmurray, yeah its been addressed in the latest git tree
<superm1> bdmurray, i was holding off doing an upload as it should just be in the next driver release though
<bdmurray> superm1: what can I do in the mean time?
<superm1> bdmurray, manually remove any symlinks in /usr/lib32/fglrx
<superm1> make sure to only remove the symlinks though
<iiinc> Where should I ask about m-a kernel source package uploads? Noticed that drbd8 module source isn't in hardy/intrepid
<iiinc> scratch that, it's in ubuntu-modules. Sigh.
<BenC> mjg59: would you agree that if dsilvers tlsup driver works as advertised, we don't need any of the tosh workarounds in acpi-support?
<BenC> His driver compiles, and seems to do what he said it does (works out-of-box with no /dev/ or /proc/ stuff to mess around with)
<BenC> has hotkeys going through input-devpoll
<BenC> real backlight driver, etc.
<BenC> ogasawara: Is it possible to have a count of current/carried-forward/fixed on intrepid-buglist.html?
<ogasawara> BenC: yup, I can just add it to the page
<BenC> ogasawara: thanks
<BenC> ogasawara: looks like we are really backed up
<hyperair_> BenC, iwlagn (using intel 4965 agn) looks for iwlwifi-4965-2.ucode in the 2.6.27 kernel.. where do i get the firmware?
<BenC> hyperair: I need to upload latest lrm to intrepid...then you can get it from linux-restricted-modules-common
<hyperair> BenC, i see. thanks. any chance of it being backported to hardy?
<BenC> hyperair: You can install the lrm-common from intrepid to hardy with no problems
<hyperair> i see
<hyperair> what about the kernel itself?
<hyperair> i got it from kernels.ubuntu.com or soemthing of that sort
<hyperair> make that kernel.ubuntu.com
<BenC> hyperair: what about it?
<hyperair> any chance of it entering backports?
<hyperair> i'm looking specifically at this kernel because it's got .17 alsa drivers
<hyperair> and anything below that doesn't support lenovo y410 very well
<abogani> BenC, When i could know if lrm switch (or no) to dkms?
<BenC> hyperair: not to hardy, no
<BenC> hyperair: we will likely have .17 alsa in intrepid though
<BenC> abogani: it will switch, hopefully by alpha5
<BenC> hyperair: lrm for intrepid just uploaded, so give it a few hours
<abogani> BenC, Is it already definitive?
<laga> hello.
<BenC> abogani: it was already decided awhile back, I just haven't switched it out yet
<laga> BenC: BTW, i showed the intrepid kernel source tree to the aufs maintainer and he said he can't support it because some files are missing ;)
<abogani> BenC, Ok. thanks!
<hyperair> BenC, thanks. 
<BenC> laga: what files?
<laga> BenC: stuff like Kconfig and Makefile. i'm having trouble with NFS right now, but i think i know what's missing
<BenC> laga: lol...there is a Makefile/Kconfig, else the damn thing wouldn't build :)
<BenC> laga: There was some stuff related to NFS in there, but it required ugly patches to the kernel, and I wasn't prepared to apply them (unless aufs maintainer is prepared to support those patches in case they break anything else)
<laga> indeed, but they are truncated.
<BenC> laga: truncated to just what we need...that has nothing to do with the code
<laga> BenC: ugly patches? it should require the following patches:
<laga> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=blobdiff;f=fs/file_table.c;h=0b6dbac60adda31cb1ba57c93a46c2cad71e7a1d;hp=83084225b4c3b3195520d5a7a441360046d6f230;hb=3b3cff7d20e3a13b89f77e641362170000ffc5c0;hpb=952058fa3a0ea802fb5e958a69119aeb01aae7a9
<laga> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=blobdiff;f=fs/namei.c;h=df4bd0d1515eb139648088a194e1311bc3dd4dc0;hp=01e67dddcc3d2033a2038c37f9f791ba0921a781;hb=3b3cff7d20e3a13b89f77e641362170000ffc5c0;hpb=952058fa3a0ea802fb5e958a69119aeb01aae7a9
<laga> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=blobdiff;f=include/linux/namei.h;h=33c7f23f716ef1009158ffe01690356e11a2fe3e;hp=24d88e98a62648180a553fdfb457837bcbcb5c00;hb=3b3cff7d20e3a13b89f77e641362170000ffc5c0;hpb=952058fa3a0ea802fb5e958a69119aeb01aae7a9
<laga> Mythbuntu really needs these patches :)
<laga> it's mostly exported symbols
<BenC> laga: Actually, it shouldn't even need that if we compile aufs into the kernel (which I would rather do)
<laga> okay, then i'm going to edit the config, rebuild the kernel and try again.
<laga> can i just edit debian/config/amd64/config or is that bad karma?
<BenC> laga: that should work
<laga> okay.
<laga> interesting, make distclean deleted debian/
<tormod> I am looking for someone to sponsor bug #192772, the debdiff is 6 weeks old, and another freeze is coming...
<tormod> the same happened with the same package in Hardy, please don't let it happen again
<BenC> tormod: I'll look into it
<tormod> thanks!
<mjg59> BenC: Yup.
<laga> BenC: is there any reason not to restore Kconfig for aufs? it looks like it's doing some magic to set invisible config items like AUFS_BR_NFS. but i could also just hardcode these in config
<BenC> laga: just add the ones we care about
<BenC> The rest are pointless clutter if we aren't actually using them
#ubuntu-kernel 2008-08-12
<laga> silly question, but i'm not a kernel hacker. if i add stuff to debian/config/$arch/config, do these needs corresponding entries in ubuntu/aufs/Kconfig?
<BenC> laga: yes
<benje> hello is the kernel source in hardy include patch rt ? to compil 
<BenC> benje: there's already a linux-image-rt package you can install in hardy
<benje> BenC, this version of kernel doesn't work for amilo 
<benje> but the patch is in source trying apply new tellit ;) 
<benje> BenC, amilo don't get dvd working cause of pciide share irq options when get it off dvd working now i try to get sound card i get problem with compiling alsa-sources i retrying
<benje> with new fresh compil 
<benje> after we solve compilation of alsa with this kernel i post it until fix is commited
<Kano> hi, did somebody tell linus that paravirt enabled does not let fglrx + nvidia compile without a tricky hack?
<Kano> with 2.6.27
<Kano> gpl only error...
<Kano> for exports: pv_cpu_ops and pv_lock_ops may not be gpl only
<Kano> now i know a trick that can compile any driver with gpl only symbols, but i dont know if that is ment to be used ;)
<Kano> think about it...
<BenC> Kano is so smart...none of us could have figured out how to make a module fake being gpl compatible to circumvent in-kernel license enforcement
 * lifeless snorts
<nightwish> log
<Kano> hi rtg 
<Kano> did you try binary 3d drivers with 2.6.27 yet?
<rtg> Kano: I'm not working on 2.6.27, try BenC
<Kano> why are you always the last with a commit then ;)
<BenC> Kano: I don't use them
<Kano> BenC: you should,becauce it is critical currently when you want to use em
<BenC> That makes no sense
<Kano> both fglrx and nvidia run into gpl-only problem
<Kano> when paravirt is enabled
<BenC> Well, I'm not disabling paravirt
<Kano> the changes needed to make the drivers compile are small
<Kano> then 2 symbols my not exported as gpl only
<BenC> And I'm not changing upstreams decision on EXPORT_SYM_GPL()
<Kano> may
<Kano> these are wrong
<BenC> Then get upstream to change them
<Kano> tell upstream to do so
<BenC> and acknowledge that
<Kano> if you want to be able to use binary drivers without extra hacks
<BenC> You're the one worried about it, don't boss me around to take care of the things you care about
<Kano> well YOU should be worried about because YOU dont want to patch it. and ia sure ubuntu users want to use those drivers!
<BenC> As far as I know, nvidia binary driver is working fine right now
<Kano> i know how to compile em and get around the problem
<BenC> Kano: does this only affect 2.6.27?
<Kano> yes
<BenC> Then I don't have time for it right now
<Kano> a 2 line change
<BenC> Kano: A two line change the breaks the license of the GPL
<Kano> pv_cpu_ops and pv_lock_ops are needed
<BenC> Email linux-kernel@vger.kernel.org
<Ng> BenC: the 2.6.27-rc2 kernel you pointed me at yesterday seems fine, audio works as well as it was from my own build of alsa (everything except the digital mic, which the alsa guy didn't manage to get working) :)
<BenC> explain this to them...
<BenC> Ng: excellent, thanks
<Ng> np, I hope this helps the quest for latest and greatest alsa in intrepid ;)
<Kano> BenC: whre in the gpl it is broken when you change the code? you only have to publish the changes!
<BenC> Kano: if you change a GPL-only export for the sake of a non-GPL compliant module to use, that is definitely breaking the license
<Kano> BenC: show me the line in the licence
<mjg59> Kano: Changing the export is legal. However, it indicates that the third party module is illegal.
<mjg59> If you're doing it in order to distribute the third party module along with the kernel, that's almost certainly illegal.
<Kano> how about compile tricks to avoid the problem?
<BenC> Kano: end-users are free to do what they want to get it to compile...however, we (as in Canonical) are not willing to put ourselves at risk of just the community backlash that it would incur
<mjg59> No. If a closed module needs a symbol that's under EXPORT_SYMBOL_GPL, that indicates that the closed module is a derivative work of the kernel.
<mjg59> Therefore there is no way to distribute that module unless you also distribute source.
<Kano> mjg59: well ti was not when the module was introduced
<mjg59> Kano: So?
<mjg59> EXPORT_SYMBOL_GPL is a hint, not a technical protection mechanism
<Kano> mjg59: so when you distribute it as source like you use dkms then it is legal?
<mjg59> If the module is available under license terms compatible with the GPL, then that's fine
<BenC> Kano: the entire kernel has been GPL'd since it started...anything compiled against it is generally considered a derivative work
<mjg59> In which case it should simply have a MODULE_LICENSE header that indicates it's under a GPL-compatible license
<Kano> BenC: well but linus never wanted that you can not use 3d drivers
<Kano> and never forced nvidia to opensource the driver
<BenC> Kano: He doesn't care whether it's a 3d driver or not
<mjg59> Linus didn't think that the nvidia driver was a derivative work of the kernel
<BenC> That's mainly because the binary blob was not written for Linux
<mjg59> But Linus isn't the only copyright holder of the kernel
<Kano> well binary drivers usually are binary blobs + a wrapper to get integrated into the kernel
<BenC> Kano: which is just re-exporting functions, which is even more devious, and doesn't shield from being a derivative
<Kano> http://www.nvnews.net/vbulletin/showthread.php?t=117209&page=2
<Kano> 17+23
<Kano> take a deep look into 23
<laga> BenC: it seems you removed some files from the aufs tree when you integrated it, like br_nfs.c. was that intentional?
<Kano> BenC: besides that, did you notice that rt2x00 does not compile?
<Kano> BenC: and one last thing: why do you need 686 optimizsation,you gain no speed with it, you only make it impossible to boot the system with amd k6-(2/3) which are fast enough when they have got enough ram
<Kano> 586 is really enough
<BenC> Kano: rt2x00 compiles for me locally
<Kano> compiling again your git, when i tried last it did not work nor did it work with an addional git pull from master
<Kano> in master there is ath9k btw
<BenC> laga: I probably removed it because we weren't compiling it in
<laga> BenC: i'll add it back then. 
<laga> i'm getting an error which prevents me from building the intrepid kernel: http://pastebin.ca/1168076
<laga> how can i resolve this?
<tseliot> Kano: if there are problems with the nvidia driver you should talk to me, since I'm the new maintainer. If something doesn't work I can write a patch for it. Any links to the issue?
<Kano> http://www.nvnews.net/vbulletin/showthread.php?t=117209&page=2
<Kano> the hack at 23 is only needed because the exports are gpl only
<Kano> the hack works perfectly, maybe too good ;)
<Kano> i patched the legacy nvidia drivers myself and fglrx 8-7 too
<Kano> all work now
<Kano> but you need that hack which should not be the case
<Kano> correctly it has to work when the official patch at 17 is applied
<tseliot> Kano: ok, thanks, I'll have a look at it
<Kano> if you want the patch for the legacy drivers just tell me
<tseliot> Kano: thanks but I'm waiting for NVIDIA to make them compatible with the new Xorg first ;)
<Kano> legacy 3 aka 173 is compatible
<Kano> so 2/4
<BenC> laga: that pastebin is just a warning
<Kano> tseliot: try my script with -v 3 option
<tseliot> Kano: I don't consider 173 legacy yet since 177 is still beta
<Kano> it is legacy because new cards dont run with 173
<Kano> it is for geforce 5 series only needed
<Kano> geforce 6+ run with 177
<tseliot> Kano: I know ;)
<Kano> also the legacy definition is from nvidia
<tseliot> I know this too
<Kano> then change you mind
<tseliot> Kano: I know it's a legacy driver but I still find it funny that NVIDIA has no non-legacy stable driver. That's all.
<Kano> BenC: i dont know what you have got locally but when i check it out it get this: http://paste.debian.net/14596
<BenC> tseliot: will 177 supercede 173, or does it drop support for things that are in 173?
<tseliot> BenC: it adds the support for some cards and drops a series
<BenC> Kano: I don't know what you have, but it isn't the latest git...I reverted the patch that causes that
<BenC> tseliot: nvidia is too quick to drop support, IMO
<Kano> BenC: i checked it out 30 min ago!
<BenC> Kano: Then you need to fix something...line 1127 in my tree is an empty line
<Kano> i can not fix anything, i only did a checkout of the official ubuntu-next git
<Kano> maybe you did not publish your change?
<BenC> Kano: confirmed at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-next.git;a=blob;f=drivers/net/wireless/rt2x00/rt2x00dev.c;h=f42283ad7b023b697e4aa9375b5c01557ae54f2b;hb=HEAD
<tseliot> BenC: I see your point but fortunately (for users, not for me...) they keep supporting legacy drivers
<BenC> Kano: no, it's definitely there...the problem is on your end
<Kano> BenC: i wiped out the whole tree, it is a new checkout. maybe git is broken
<Kano> cant you do a checkout on your system and try it
<Kano> i am sure i did not change a line myself in that driver
<BenC> Kano: I did a checkout already
<BenC> to confirm
<BenC> Kano: it's a problem on your end
<BenC> Kano: git-pull and see what happens
<Kano> always at the same file for every checkout?
<laga> BenC: you were right about the warning ;) i scrolled up and it showed me the real error
<laga> BenC: it looks like the kernel still needs patching for aufs. but that's just to make some functions public
<laga> but the symbols don't have to be exported anymore
<BenC> laga: CONFIG_FS_AUFS=y
<laga> yes. it still needs patches, or it won't compile.
<BenC> laga: Ah, if we have to patch s/static// anyway, then we might as well export
<BenC> Only reason for doing =y was to avoid patching
<laga> that'd be good because it would allow aufs to work as a module, too.
<Kano> well i made already live iso images with 2.6.27 ;)
<laga> is there any reason not to have a full-blown aufs module like in hardy?
<Kano> BenC: what do you think about 586 not 686 like hardy?
<BenC> laga: Other than not liking to hack the hell out of the kernel, no
<Kano> i dont think that 2.6.27 should require a new system, that will break many old systems during upgrade
<laga> BenC: okay, then i will get a complete copy of the checkout you had back then, apply the kernel patches and submit it to you?
<Kano> BenC: now you pushed some new things which introduced a new error, could you please update your system clock, you always changes things in the past
<Kano> you added gfs which included asm/semaphore.h, but the new position is linux/semaphore.h
<Kano> you definitely changed things at max 1 h ago and still it shows last change was 21h ago
<Kano> BenC: http://paste.debian.net/14600
<BenC> Kano: it's not system clock, it's called a rebase
<Kano> sure and then the error is on my end, clear...
<BenC> Kano: let me make this perfectly clear...2.6.27 is not my primary work...I do it to make things easier in the future
<BenC> Kano: if you are depending on it to produce some whack off-shoot of Ubuntu, then you'll just have to live with my delays
<laga> BenC: so would you be OK with including a complete copy of the source? that'd also make upstream happier i suppose
<laga> err, complete copy of the source == everything that normally lives in aufs/fs/aufs/ in the upstream source.
<BenC> laga: sure
<Kano> BenC: could you fix that new error?
<BenC> Kano: yes, I will fix it
<Kano> can i wait for it
<BenC> You sure can
<Kano> 1 h or less
<alex_joni> Kano: it probably happened already
<Kano> 22h ago?
<alex_joni> but since the clock is off.. it probably hasn't :D
<alex_joni> it depends how fast and in what direction you are travelling atm
<Kano> i thinks so...
<hyperair> BenC, which linux-restricted-modules-common should i download in order to get the iwlwifi-4965-2.ucode firmware?
<BenC> hyperair: 2.6.26-5.12
<hyperair> thanks
<hyperair> i suppose i'd need to install he 2.6 kernel with it?
<hyperair> sorry 
<hyperair> i meant 2.6.26
<BenC> No, it will work with 2.6.24 as well
<hyperair> i see. okay.
<BenC> but since iwlagn is only in 2.6.27, it doesn't make much sense to download it for anything else
<hyperair> hahah
<hyperair> well. 
<hyperair> i did download the 2.6.27 kernel from kernel.ubuntu.com
<BenC> that will work then
<Kano> BenC: http://paste.debian.net/14616
<laga> BenC: when you added aufs, did you use fs/aufs or fs/aufs25 from the upstream source tree?
<laga> BenC: i got a checkout from sourceforge from the same date as you (according to BOM) and i'm seeing lots of changes.
<laga> BenC: aaah, your checkout was probably too early for that monday release
<Kano> well 2 extre LM flags are missing...
<Kano> i dont know why you need gfs
<Kano> just disabled it and it compiled...
#ubuntu-kernel 2008-08-13
<mcadetg> hi, I've a problem with lib/firmware when trying to compile/install vanilla kernel on ubuntu via the git/debian way...
<mcadetg> I think the main problem is that dpkg -i linux-image tries to install firmware in /lib/firmware instead of /lib/firmare/$(uname -r)
<Kano> thats correct
<Kano> the uname hack is ubuntu specific
<mcadetg> can I configure this somewhere under the debian control directory?
<Kano> and not used in intrepid anymore
<Kano> you need a patched udev in order to use that uname -r dir anyway - or at least one with changed config, when you compare it to debian
<Kano> it is non standard
<mcadetg> Kano: ok so shall I go for /lib/firmware then
<mcadetg> ?
<Kano> lib/firmware works for any kernel
<Kano> on any distro
<mcadetg> ok thanks
<Kano> when you try to use /lib/firmware/$(uname -r) with debian you have lost already
<mcadetg> ok thanks
<Kano> if you dont know that is is non standard and requires a udev config change
<mcadetg> so I revert my changes to the Makefile ;)
<mcadetg> anyway I guess my problem was just because I'm not very familiar with debian/ubuntu dpkg
<mcadetg> when I tried to install a newer (minor) version of my newly build 2.6.27-rc3 kernel I wasn't able to install it
<mcadetg> because dpkg was not happy with that:
<mcadetg>  trying to overwrite `/lib/firmware/edgeport/boot2.fw', which is also in package linux-image-2.6.27-rc2-custom
<mcadetg> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<Kano> well unisntall the other package
<mcadetg> hmmm
<mcadetg> basically I would like to have it as a rescue kernel version
<Kano> as thats your only other kernel?
<mcadetg> no no
<mcadetg> it is not
<Kano> then you have got enough rescue kenrnels ;)
<mcadetg> hehe
<mcadetg> yeah ok
<mcadetg> I will go on with that
<Kano> i am playing around with ubuntu git + update to kernel git. that new e1000e update is fully crap
<mcadetg> but for example if you are tweaking with some drivers I definitely would like to be able to have different minor version 
<Kano> which is patched in, just disabled it and recompile
<Kano> is is so buggy that the nic did not even work after reboot with another kernel
<Kano> also the zd1211rw seens to be broken
<Kano> in standard kernel tree
<Kano> mcadetg: do you use nvidia or fglrx driver?
<mcadetg> intel
<mcadetg> Mobile 945GM/GMS
<mcadetg> gah still not sorted out the /lib/firmware prob. The kernel doesn't want to load firmware from /lib/firmware but when I put firmware manually in /lib/firmware/$(uname -r) then it works
<mcadetg> how does the firmware get loaded
<mcadetg> is it via an udev rule?
<mcadetg> couldn't find anything in /etc/udev/*
<Kano> well ubuntu patched udev internally, i use a debian udev + firmware search change
<mcadetg> Kano: thanks a lot
<s0u][ight> hello i have a question regarding to patch for the mac80211 core
<s0u][ight> this patch im talking about makes it possible to perform fragmentation attack with the aircrack-ng suite
<Kano> hi rtg 
<Kano> hi BenC 
<Kano> there are some problems with e1000e, it seems the newer version is not better than the kernel built in
<Kano> also zd1211rw can lockup a system
<BenC> Kano: I noticed that the e1000e we put in covers too many PCI ID's, so I'm going to cut them down. Can you be more specific about "not better"?
<Kano> well for one tester his e1000e chip does not work anymore, not even with old kernels, dont know how that could happen
<Kano> also i disalbed gfs, as it is still broken,not only the inclues, but 2 other things missing
<Kano> i dont need it anyway...
<Kano> somebody gets a lockup with his zd1211rw
<pwnguin> i thought .26 was going to be for demo purposes only?
<pwnguin> on second thought, im stupid and recalled benC's ubuntu-next incorrectly
<Ampelbein> Hi! Could someone please check on Bug 256629? Now that I've got enough information and done some research I found out that the specific WLan-Card (IntelÂ® Wireless WiFi Link 5100 WLAN) is not supported under Kernel 2.6.24, but will be supported in 2.6.26. What is the correct status to set this bug to? Fix-Released?
<rtg> Ampelbein: Intel is working on backporting the iwlwifi 5K driver to Hardy. It might be awhile yet.
<Ampelbein> rtg: so the correct status would be "in progress" until the driver comes out working?
<rtg> Ampelbein: sounds about right. 'In Progress' bugs should also have someone assigned to them. I would do it but LP seems to be flakey today. I think I'll go have lunch and try again later.
<tormod> now with linux-image-2.6.24-21-generic in hardy-updates, do I have to install it manually, or is update-manager waiting for some meta-package to be updated and pull in -21?
<rtg> tormod: wait until linux-meta gets uploaded. the update-manager will annoy you when everything is consistent.
<tormod> rtg: thanks
<rtg> uptime
<rtg> -EBADWINDOW
#ubuntu-kernel 2008-08-14
<matjan> hi, over the past couple of days i have been experiencing system crashes... but but no messages were left in the logs... i am using hardy with the 2.6.24-19 kernel
<matjan> however, yesterday, something was logged
<matjan> let me post quickly one line here: 
<matjan> Aug 12 11:32:30 quadpc kernel: [101268.517063] Pid: 11524, comm: hadam3_um_5.03_ Tainted: P    B D (2.6.24-19-generic #1)
<matjan> this is followed by 40 (or so) more messages and then it stops with: ==================
<matjan> not sure if i can ask about this problem here...
<RAOF> It seems the interactive performance has dropped a lot under heavy IO, certainly from Hardy's kernel.  In particular, reading the dpkg database can interrupt Banshee/gstreamer/pulseaudio's music for multiple seconds, and make the UI unusable for the duration of the read.  What's the best way of debugging this?
<RAOF> I could build the kernel from Ubuntu git and try to bisect, but it'll take quite some time to actually test each build, so it'd be good if someone had a guess as to where to start :)
<pwnguin> scheduling policy
<pwnguin> RAOF: in hardy, you might notice from time to time that high disk i/o messes with input
<pwnguin> apt operations seem to trigger key repeats
<pwnguin> something about group scheduling polcy
<RAOF> I didn't so much notice that.
<pwnguin> a friend of mine got rather angry at Ubuntu over it, up until debian had similar problems
<lifeless> lol
<pwnguin> same with firefox
<pwnguin> those Ubuntu developers! always breaking my stuff. thats it, i have to go back to debian if I want a working computer
<pwnguin> *24 hours later*
<Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic-next/source/2.6.27-pv_lock_ops-fix.patch
<Kano> could somebody push that upstream? it is a needed fix for 3d drivers + paravirt
<amitk> Kano: BenC already told you we would not do anything to work around GPL symbols
<Kano> but thats a newly introduced error
<Kano> it was not there in 2.6.26
<Kano> if you ignore that ship 8.10 without nvidia+fglrx drivers
<Kano> i am pretty sure nobody will use it then
<amitk> Kano: besides, why don't you email it to lkml? :)
<Kano> dont like mailinglists, never liked that
<amitk> Kano: i think you can post to LKML through a web interface, no subscription necessary.
<Kano> you can read it
<amitk> Kano: http://www.kernel.org/pub/linux/docs/lkml/#s3-3
<amitk> There, now you can post to the list directly.
<mjg59> Kano: The only people who will apply that patch are upstream, so.
<Kano> well i will not write mail, just do it
<Kano> bye
<laga> Kano rocks.
<amitk> laga: he does indeed
<laga> so, how do i submit patches against the ubuntu kernel?
<laga> assuming i've got them in my git tree
<benje> hi is ther is planed to set memory to 64 in generic kernel to handle all memory and swap of recent conmputer .
<mjg59> benje: Use a 64-bit kernel or the server kernel
<mjg59> benje: Supporting PAE results in a performance hit
<benje> mjg59, oki thanks 
<laga> ooh, i found some documentation in the wiki
<laga> i guess it's a bit too late now to use the commit templates :(
<laga> is it absolutely necessary to have the signed-off-by line in all commits?
<laga> ooh, git-gui.
<amitk> laga: Signed-off is mandatory to establish provenance of the code
<laga> ok. i've found out how to add it to existing commits
<amitk> laga: sending each commit as an attachment to a separate email is good. If you have lots of patches, you can point to your git tree.
<laga> hum. i don't have lots of patches, but i'm lazy so i'll just upload my tree.
<amitk> laga: if they are patches to various drivers , it would be nice to have detailed explanations in the patches themselves
<laga> no, it's just a proper aufs tree
<soren> BenC: Do you think you can explain what needs to happen for virtio-net to be available in the installer (without having to install additional udebs)?
<BenC> soren: I can split up the modules into the general udeb's...otherwise, you would need to ask cjwatson how things work in the installer
<BenC> soren: maybe it can detect that it is running in a vm and automatically request the right udeb
<BenC> amitk, rtg, smb_tp: Preparing an intrepid upload...anything you guys working on right now that I should hold off for?
<soren> BenC: I think we ship much, much more esotric modules in the general udeb's as it is.
<soren> BenC: I have a patch for Intrepid, actually.
<smb_tp> BenC, nope
<BenC> soren: patches are good :)
<rtg> BenC: Mario pointed out that Broadom ain't working in LRM, so I need to look at that.
<soren> BenC: Indeed they are. :) Gimme a minute.
<rtg> Intrepid LRM (that is)
<BenC> rtg: I'd say that's an incorrect statement, since I was just using it last week :)
<rtg> BenC: I'm good with that :)
<BenC> rtg: which reminds me, that I and some one else confirmed that the wl driver has a bug which prevents it from allowing wan connections behind a NAT AP
<rtg> BenC: I remember seeing that. How can a MAC layer driver mess up a NAT connection?
<BenC> rtg: b43 works fine, so it's definitely the wl driver's fault
<BenC> rtg: does wl have it's own IP stack too?  :)
<rtg> BenC: I wonder if ti's truncating the MTU. (It is a full MAC driver)
<BenC> rtg: I didn't get far enough with testing it to see where the packets were being dropped...maybe I'll have some time another day to run ethereal on it
<BenC> rtg: MTU was some one else's guess too
<BenC> I'd have to see the packet to know what's going on, and I really hate spending time on it considering I can't fix it
<BenC> rtg: Can you email me the broadcom contacts?
<rtg> BenC: NAT packets aren't wrappered, they just get the return IP and port number swizzled after trhe routing decision.
<BenC> rtg: right...I'm kind of thinking that either the AP is ignoring the packets from some odd reason, or the swizzling is causing wl to ignore the return packets
<rtg> BenC: all that happens in IP. The AP is a layer 2 MAC bridge.
<BenC> rtg: the fact that it works to LAN machines _AND_ that it only affects some applications is making it even more weird
<BenC> rtg: e.g. mozilla works fine, elinks works fine, but telnet to port 80 doesn't
<BenC> rtg: and ssh doesn't work
<BenC> so it seems to have something to do with packet size
<BenC> I think ssh and telnet limit to 512 bytes
 * amitk looks up yet another Tim'ism - swizzle. And it surprised to find it in the Jargon File!
<BenC> amitk: swizzle sticks dude
<rtg> amitk: what? You think I invented it? huh.
<amitk> heh
<BenC> wget doesn't work either, IIRC
<rtg> BenC: Broadcom POC info emailed.
<BenC> rtg: thanks
<BenC> I wonder if it may have something to do with tcp windows...I can at least swizzle that in sysctl ;)
 * BenC honors the new word-of-the-day
<soren> sysctl? :)
<amitk> BenC: the wl driver should not know anything about the NATing.. that would happen at the gateway
<rtg> BenC: as you said, no use spending time on something we can't fix.
<BenC> amitk: it shouldn't...but it doesn't happen across a straight route...only over NAT
<BenC> amitk: and confirmed with two different b43 cards, and two different AP's
<BenC> so we can't even blame the NAT stack on the AP
<rtg> BenC: are the APs simple bridges, or do they have routing built in?
<amitk> BenC: played with 'iwconfig frag' ?
<BenC> rtg: mine is routing...I don't know about the other
<BenC> mine is a wrt54g with dd-wrt firmware
<BenC> the other was a stock cisco AP
<BenC> rtg: email sent, CC'd you
<soren> BenC: Patch sent to kernel-team@l.u.c
<soren> BenC: Ok, as I was saying: I don't think keeping virtio modules in a udeb by themselves is justified (if that requires people to do more stuff in the installer to make it work).
<BenC> soren: But is it possible to have that udeb automatically selected based on the environment?
<soren> For KVM, yes.
<soren> (other virtualisation things will be offering virtio devices soon, too)
<soren> BenC: Oh, er..
<soren> WEll, yes, we can look at the presence of certain PCI id's.
<soren> That should always work.
<soren> Just to reiterate: You removed them from nic-modules to keep netboot images smaller. Right?
<BenC> soren: right
<soren> So how am I supposed to netboot kvm guests?
 * soren might be missing something here..
<BenC> soren: well, it can netboot...just might not be able to do the install :)
<BenC> soren: this probably should include someone who works on d-i
<BenC> soren: since I only know a trivial amount about this
<BenC> soren: does kvm/qemu even support PXE boot?
<soren> I'm just desperately trying to work out why specifically virtio was removed from nic-modules and not one of the many other ones.
<soren> BenC: Sure. It has done so for ages.
<BenC> soren: I'm personally at a disadvantage to defend that decision, I just know that for netboot, things need to be kept small
<soren> BenC: Oh, I thought you were the one who decided it should be that way. The commit had your name on it, I believe :)
<BenC> soren: I did decide it, but soley based on what udebs/netboot was meant for :)
<soren> So I should talk to cjwatson, I presume?
<BenC> soren: clflush commit pulled into intrepid
<soren> Thanks very much.
<BenC> soren: cjwatson is probably best
<BenC> soren: if I can get a clear definition of what should and shouldn't go into udeb's, it would make life remarkably easier for all of us
 * soren makes a note
<soren> Ok, thanks
<mkrufky> is there a command that i can ask a user to do that will tell me if he is running hardy32 or hardy64 ?
<laga> uname -a?
<mkrufky> obviously i can have him look at /proc/cpu , but i am not sure if that is definitive to determine that running flavor, versus cpu capability
 * smb_tp damn, too late ;-)
<rtg> uname -m
 * smb_tp curses tiny laptop fonts. 
<smb_tp> mkrufky, right uname -m ist the one
<amitk> uname only tells about kernel, dpkg-architecture will tell about userspace too
<smb_tp> mkrufky, dpkg-architecture will show which ... ok
<rtg> BenC: pushed Intrepid patch
<mkrufky> awesome ... thanks to both of you
<mkrufky> looks like dpkg-architecture is what i needed
<cody-somerville> Hey
<cody-somerville> Did we ever get compcache spec done?
<mkrufky>  is anybody here going to the Linux Plumbers conference?
<mkrufky> http://www.linuxplumbersconf.org
<rtg> mkrufky: all of the Canonical/Ubuntu kernel dev team will be there.
<mkrufky> ah, great!
<Ampelbein> Could someone please have a look at bug #163236? The ipw3945-driver is deprecated and all development has gone to the iwlwifi-project. So I think this bug can be set to "Won't fix"? Can somebody with the correct rights check that out, please?
#ubuntu-kernel 2008-08-15
<laga> so, i just send the patches as attachments to the list?
<smb_tp> laga, could it be that patch 1/6 is missing?
<laga> it's stuck in moderation
<laga> i forgot to add it, then sent another mail which is stuck now
<laga> 5/6 has a wrong subject line - it's past 2am here :)
<laga> G'night
<smb_tp> laga, ah ok. yeah I figured that out. Und auch die Uhrzeit. ;-)
<abaqueiro> hello, I have this problem: I installed Ubuntu Server for sparc, I have 2 disk (hda, hdd) both with four partitions, the partitions 1Âº are only unused 8 Mb partitions, the partitions 2Âº are about 512 Mb, and I created a Raid1 device for the swap, the partitions 4Âº about 19Gb in both disk are for a RAID1 device, wich contain a ext3 filesystem (including /boot), ubuntu instalation was ok, until the instalation of silo, where it says there was an 
 * BenC likes the new ABI blacklisting
<BenC> I can't remember the last time we've been able to do 4 mid-development kernel uploads without bumping the ABI
<laga> BenC: have you seen the aufs patch? ;)
<BenC> laga: Yeah, I'll review it over the weekend
<BenC> laga: thanks...Have you tested that it actually works?
<laga> yes.
<laga> not on a live disk, but it boots my diskless client
<laga> it looks like i'm not supposed to set config options to "n", they need to be undefined instead. i'll send another patch to fix that.
<BenC> laga: to make it easy, run "debian/rules updateconfigs"
<BenC> that's what I'll end up doing afterwards anyway
<adamwood> Hi, I just attached a patch to launchpad bug #242448, I hope it's helpful
<rtg> kirkland: '<adamwood> Hi, I just attached a patch to launchpad bug #242448, I hope it's helpful'
<kirkland> rtg: adamwood: hiya, let me reboot ...  messages here are logged by my proxy
<kirkland> adamwood: hi, do you have a kernel built that I can try?
<kirkland> rtg: or perhaps you have one?
<adamwood> kirkland:Hi, I have a 2.6.24-21-generic .deb if you want it
<rtg> kirkland: no, I was just looking at his patch. part of it at least is already in Hardy, so I'm not sure what he's got for sure.
<kirkland> adamwood: please
<adamwood> kirkland:give me a min to upload it somewhere
<kirkland> adamwood: which arch?
<kirkland> adamwood: I'm going to install a new kvm
<adamwood> i386
<kirkland> k
<rtg> adamwood: I'm totally confused by your explanation in the bug report. you are referencing commits that are already in Hardy. How did you assemble your patch?
<adamwood> rtg:the commits are from around the 2.6.25-rc3 tag so they're not part of the Ubuntu- tags as far as I could tell.
<rtg> adamwood: they are from the Hardy tree. How can they be 2.5.25-rc3?
<adamwood> rtg:something that confused me too, but running git tag -l on the hardy tree lists a lot of extra tags I was surprised to see.
<rtg> hmm, I wonder if someone pushed all of their fetch info from upstream.
<adamwood> rtg:I first downloaded the ubunut-hardy tree a couple of days ago so I don't really know, I just muddled through ;-)
<ogasawara> adamwood: I'm seeing the same one freshly cloned ubuntu-hardy trees
<ogasawara> s/one/on/
<adamwood> ogasawara:I hope that means I'm looking a little less stupid ;-)
<rtg> adamwood, ogasawara: lemme see if I can clean things up. the LP message makes more sense.
<ogasawara> adamwood: heh, I thought I was going crazy for a while
<adamwood> kirkland: http://www.xephi.co.uk/files/linux-image-2.6.24-21-generic_2.6.24-21.41_i386.deb 
<adamwood> rtg:sorry if I've given you some extra work there, i just assumed the full tree was supposed to be included
<rtg> adamwood: t'aint your fault.
<smb_tp> rtg, ogasawara, adamwood: the one could have been me when I pushed the re-worked head
<rtg> adamwood: for future reference, the preferred way to backport a patch is to 'git cherry-pick', then resolve conflicts, etc. That way you preserve the provenance of the upstream patch.
<adamwood> rtg: thanks, I thought something like that which is why I linked to the sources, but I doubt applying the second patch I listed would be a good idea.
<rtg> adamwood: you're right about the second one.
<rtg> smb_tp: assume the Hardy repo is offline for a bit.
<adamwood> rtg: there's only a 1 line change of any use in it anyway. Hence my patch just to keep things simple even though I knew it wasn't the best way to handle it
<kirkland> adamwood: you don't happen to have an amd64 deb, do you?
<adamwood> kirkland: not ready made but I could probably build one tomorrow
<kirkland> adamwood: okay, let me get a fresh vm
<adamwood> kirkland: I'll be going afk shortly (it's been a long day ;) ) but it can't be too hard to find my e-mail address on launchpad if you need me to build a different arch
<kirkland> adamwood: okay, thanks
<kirkland> adamwood: i'll update the bug status
<adamwood> kirkland: let's hope i'm not wrong then
 * adamwood is back
<soreiser> hi there, i would like to know why "all_generic_ide" is not working with hardy. i really need it to make my old pc working. thanks
<Tallken> soreiser: it works, at least worked with server version
<alex_joni> soreiser: what's the error you're getting?
<alex_joni> on some systems I used to use all_generic_ide, but then switched to irqpoll to make them work
<Tallken> soreiser: have you tried -- generic.all_generic_ide=1
<Tallken> ?
<soreiser> Tallken, alex_joni just tried with ubuntu-server and ubuntu (8.04) and simply it does not work (i can see many I/O errors from dmesg loading). it works on xubuntu 7.10 instead :-/
<soreiser> Tallken no, should i try that too?
<Tallken> why not?
<Tallken> soreiser: add "generic.all_generic_ide=1" and hope for the best
<soreiser> Tallken, alex_joni i forget to say that it does not work only with livecd/install cd
<soreiser> on grub it works
<Tallken> ah
<Tallken> don't know then :/
<soreiser> ah and "generic.all_generic_ide=1" if i dont mistake i have already tried also this, some time ago
<Tallken> the livecd boot system acts weird now and then
<soreiser> also all_generic_ide=1 <-- about this i'm sure
<alex_joni> soreiser: try the irqpoll option too
<alex_joni> can't hurt
<soreiser> alex_joni does is serves to my ide-problem? :-/ 'cause i have an old motherboard with the 34gb limit block and i need to get rid of it (all_generic_ide does :))
<alex_joni> soreiser: probably not
<soreiser> the problemTallken how can i install hardy-server on my old pc if that parameter not woks? is there any workaround?
<soreiser> alex_joni irqpool has to do with hdd too? 'cause that pc is now down and i wuold like to be sure that it works to dont wait half hour for it to wake up uselessly ;)
<alex_joni> soreiser: I was bitten by this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/206635
<soreiser> this is what i get if all_generic_ide is not added: http://launchpadlibrarian.net/6454122/A%3A%5Cdmesg.txt
<soreiser> see under, all those I/O errors
<soreiser> alex_joni
<soreiser> alex_joni excuse me, have you read when i wrote the problem is only for the livecd? have you any idea/workaruond?
<soreiser> ah, i forgot: on xubuntu 7.10 the parameter worked, on ubuntu 7.10 did not (livecd both i mean) what do you think about?
<alex_joni> soreiser: I would still try to add irqpoll and all_generic_ide as boot params for the LiveCD
<soreiser> alex_joni both?
<soreiser> or just irqpool?
<soreiser> *poll
<alex_joni> yes.. did you read the bug link I pasted?
<alex_joni> both
<soreiser> sorry no i didn't read it so much, 'cause i wanted to search the laucnhpad report i already did  sorry ;) ok i'll try it tomorrow then if i'll got troubles i will return here :)
<soreiser> ah alex_joni: <soreiser> ah, i forgot: on xubuntu 7.10 the parameter worked, on ubuntu 7.10 did not (livecd both i mean) what do you think about? <--
<alex_joni> soreiser: not familiar with xubuntu's livecd
<alex_joni> and neither with ubuntu's 7.10
<soreiser> alex_joni okey thank you anyway i'll try it tomorrow thanks again :)
<alex_joni> np..
<soreiser> ;)
<rtg> kirkland: when it is done building http://ppa.launchpad.net/timg-tpi/ubuntu will have a kernel with the ecryptfs patch from upstream e4465fdaeb3f7b5ef47f389d3eac76db79ff20d8
<kirkland> rtg: awesome, i have had a hell of a time getting an i386 vm up and running
<rtg> kirkland: I'm outta here a bike ride. have a good weekend.
<kirkland> rtg: nice!
<kirkland> rtg: i bought a road bike yesterday
<kirkland> rtg: Canondale
<rtg> mine's a canondale too, but its a 15 year old F700 mountain bike. still works good.
<rtg> the thing I like about mountain biking is that there are no cars to run me over.
<kirkland> rtg: i hear ya, this thing still scares me shitless
<rtg> kirkland: like when you forget to unclip at a stop light?
<kirkland> rtg: yeah, and doing 50mph down hill (well, i haven't done that yet)
<kirkland> rtg: but it will scare me
<rtg> kirkland: yeah, well be careful. gotta go.
<godlygeek> can anyone here explain to me how key presses on the keyboard get mapped to keycodes by the kernel?
<mjg59> godlygeek: There's a table in drivers/input/atkbd.c
<mjg59> godlygeek: There's a table in drivers/input/keyboards/atkbd.c
<godlygeek> maybe i'm missing something...
<godlygeek> what's the distinction between keycode and scancode?
<mjg59> scancode is what the hardware generates. keycode is what it gets turned into.
<mjg59> keycodes are things in /usr/include/linux/input.h
<godlygeek> ah, ok.  i had them flipped in my head...
<godlygeek> i'm going to try very hard to figure out how to get a sysrq button press on my macbook...
<godlygeek> because not being able to use magic sysrq is absolutely killing me... i'd love to be able to cleanly unmount my disks when i crash... heh
<godlygeek> one last thing.. if two key presses generate the same scan code (with showkey -s), this means that they look exactly the same to the kernel, since showkey -s does absolutely no translation... right?
<mjg59> They should, yes
<godlygeek> ok.  mac docs say that fn-shift-f11 is printscrn on windoze, but that definitely doesn't do anything different from regular-old f11 here.
<mjg59> Oh! USB is different.
<mjg59> Entirely different.
<mjg59> Showkey will probably lie to you when it comes to the raw scancodes, since there aren't any
<mjg59> They're already abstracted by the HID protocol
<godlygeek> i take it the internal keyboard in mac laptops are USB, then?
<godlygeek> never knew that.
<mjg59> Yup
<godlygeek> ok.  well, pointers to what i should read up on to try to further my goal, then?
<mjg59> Not sure. I'm really not sure how the sysrq stuff is implemented, I'm afraid.
<godlygeek> well, from what i can see, whenever the kernel gets a keycode it checks if it's for SYSRQ, if it's down, whether alt was pressed, etc, and waits for a new keycode for function to do...
<godlygeek> so, that all makes perfect sense, except that my keyboard never gives it any scan codes that match the keycode for SYSRQ
<godlygeek> so, it ought to be no different from the general question of "how do i make key XXX send keycode YYY"
<godlygeek> except that it needs to be done on the lowest level possible, of course.  :)
<chris_goe> does anyone know why CONFIG_MD_RAID10 is not selected in hardy's kernel image?
#ubuntu-kernel 2008-08-16
<chris_goe> hm...
<kaimerra> can anyone guide me in the right direction to recompile one of my kernel modules?  specifically snd_usb_audio
<godlygeek> mjg59: thanks a lot for the help earlier.  the eventual solution was something quite apocryphal with a tool called 'keyfuzz' to manipulate the USB keyboard codes before they're sent on to the PS/2 compatibility layer (if i understand correctly), so you certainly pointed me in the right direction.
#ubuntu-kernel 2008-08-17
<superm1> hi ScottK-laptop.  okay to start out you'll need to clone the intrepid git tree
<superm1> you can visit http://kernel.ubuntu.com/git for a listing of all the git trees available
<superm1> more or less git-clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git
<ScottK-laptop> Man, now you want me to use git too.
<ScottK-laptop> Doing
<superm1> hehe
<superm1> i was very resistant of using git myself too at first, but i've come to be at peace with it
<superm1> so while that's cloning, click on the ubuntu/ubuntu-intrepid.git link
<ScottK-laptop> I need to learn it.
<superm1> can try to explain how the tree is organized
<ScottK-laptop> OK
<superm1> so if you click the "tree" link, you'll see an ubuntu/ subdirectory
<superm1> all the out of mainline kernel modules are kept there
<superm1> inside there there is a Kconfig for everything that is included in there, it ends up sourcing the Kconfig for subdirectories and more modules
<superm1> so you would likely make subdirectory for your module, and then end up modifying Kconfig to source the Kconfig of your module
<superm1> also, there is a Makefile that drops it down into the subdirectories as well when they are built
<superm1> you'll have to add in a line for that too
<ScottK-laptop> Their patch includes kconfig changes
<superm1> well it include a Kconfig for the module itself
<superm1> the top level Kconfig is just going to call the Kconfig from this module
<ScottK-laptop> Yes, and they have the b/security/Kconfig change to add themselves.
<superm1> well they are assuming they end up "in tree"
<superm1> based through the security directory
<superm1> instead you are in the ubuntu directory
<superm1> so you'll be patching the Kconfig in the ubuntu directory instead
<ScottK-laptop> Right.
<ScottK-laptop> So we'd need to modify their patch a little.
<superm1> yeah
<superm1> just where you are sourcing and what not
<superm1> once you've got all those files in place, you need to modify the kernel configs
<superm1> in debian/config/(arch)/config
<superm1> to add in that extra Kconfig option that they are referring to
<superm1> CONFIG_SECURITY_DAZUKO
<superm1> the syntax should hopefully be pretty apparent in there
<ScottK-laptop> hopefully.  It's 1AM here, so nothing is really apparent at the moment.
<superm1> well tomorrow then :)
<superm1> let me give you the last two steps and you cna let it sink in and ask questions/what not
<superm1> https://help.ubuntu.com/community/Kernel/Compile#Build%20the%20kernel%20(when%20source%20is%20from%20git%20repository,%20or%20from%20apt-get%20source)
<superm1> that shows you how to build a kernel from the git tree
<superm1> you dont want to build all the different variants, just the generic for testing
<superm1> so CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic is probably what you want to do
<superm1> when you're sure that everything is functional, you can make a git patch out of everything and submit it to the mailing list or publish a git tree.  ping me or someone in here when you are ready to do that so that you can get your git config all ready with commit name and how to use the templates
<ScottK-laptop> OK.
<ScottK-laptop> I'll probably be asking for help several times again between now and then.
<superm1> yeah the first time is pretty confusing when you dont understand syntax and all, but hopefully it should end up more apparent
<ScottK-laptop> So I'm reading some more and this is getting a bit scary.
<ScottK-laptop> http://dazuko.org/tgen.shtml#LSM indicates the whole thing may not work so well with Apparmor.
<superm1> yuck :)
<ScottK-laptop> I'm guessing we don't have an RSBAC enbaled kernel http://www.rsbac.org/ and aren't likely to get one.
<ScottK-laptop> Which would leave syscall hooking and I'm guessing that won't be popular.
<superm1> especially since they dont have snapshots for 2.6.26
<ScottK-laptop> Yep.
<ScottK-laptop> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423281 is also relevant.
<ScottK-laptop> I think I'm going to go to bed and then ponder tomorrow if I really want to open this can of worms or not.  Here I was just hoping I could wave a little DKMS magic over it and it would be easy.
<ScottK-laptop> superm1: Thanks for the help.
<superm1> ScottK-laptop, sorry if it won't work here, no DKMS magic will help it either :)
<superm1> best of luck sorting out though
<ScottK-laptop> Thanks.
<soreiser> alex_joni: hi, i tried also all_generic_ide + irqpoll, but.. no way to make it working :/
<soreiser> seems that ubuntu-server 7.10 and all ubuntu 8.04 does not support all_generic_ide somehow :( hmm so bad :(
<soreiser> *do not
<soreiser> all_generic_ide is a very needed parameter for OLD PCs to make them working
<superm1> i've personally used all_generic_ide in 8.04 without trouble
<soreiser> superm1 it worked for me only with xubuntu 7.10, how is it possible?
<soreiser> (and ubuntu 7.10 too, if i dont mistake. but any server version did)
<soreiser> *did not
<superm1> huh?
<soreiser> just tried with ubuntu-server hardy
<soreiser> does not work, i get several I/O errors about my hdd
<superm1> well are you sure that's really the root cause of your troubles?
<superm1> are you thrown to a functional initramfs prompt?  You can check what modules ended up being used 
<superm1> whether it's ata_piix or what not
<soreiser> superm1 sorry i forgot to mention that: i refer to livecds :/ sorry, i totally forgot to say that
<soreiser> yeah in grub it works
<superm1> soreiser, well in both cases the kernel parameters are passed the same.  you are adding it to the live cd prompt then?
<soreiser> yeah superm1
<soreiser> something like: "..... all_generic_ide -- " (also tried without the '--'"
<superm1> soreiser, well that's awfully odd then if its not being passed on properly only from a live cd 
<soreiser> so superm1 what could i do? is it going to be fixed for the next release?
<superm1> soreiser, i've used all_generic_ide in both a live cd and a scripted install
<superm1> so i'm not sure where your issue is
<soreiser> superm1 we could talk in italian if is it possible, as i've seen your italian in your personal info
<soreiser> *yuo're
<soreiser> **you're
<superm1> soreiser, sorry i don't speak italian
<soreiser> superm1 ah sorry i thought you were :) your is an italian name eheh :)
<superm1> i am, but i dont speak it unfortunately
<superm1> soreiser, i'd recommend trying to get a bug report together with all of this data you've gathered to get some more eyes on the problem
<soreiser> superm1 well, however, simply that parameter does not work me with livecds (except xubuntu/ubuntu 7.10)
<soreiser> superm1 yeah i've already made a bug report, even if were not so sure it is a bug
<superm1> soreiser, hopefully something will stick out 
<soreiser> *work for me
<superm1> soreiser, sorry i can't be of much more help :)
<soreiser> well ok superm1 thanks anyway for your support, good ;)
<soreiser> superm1 should i maybe (re :))turn to #ubuntu-dev to report it is not a bug issue then?
<superm1> soreiser, well there very well can still be a bug here, your hardware is different than mine, perhaps it's just been a fluke that it's worked in the past for you
<superm1> soreiser, i say let the bug triage folks handle it on the report 
<superm1> that's the best workflow to record all of the empirical data
<soreiser> well ok superm1 i'll try to get some workaround from the discussion in the bug report, hoping it will be FIXED soon ;)
<Ampelbein> Could a member of bug-control please check on bug #258754? i think it could be set to "triaged".
<chris_goe> hm, I shall try again: does anyone know why CONFIG_MD_RAID10 is not selected in hardy's kernel image?
<_ruben> chris_goe: because it is?
<_ruben> $ grep RAID10 /boot/config-2.6.24-19-server
<_ruben> CONFIG_MD_RAID10=m
#ubuntu-kernel 2009-08-10
<amitk> rtg: will these changes that you threaten to push to master break a rebase?
<rtg> amitk, rebase to a topic branch? not if you _completely_ remove the topic branch debian directory first.
 * amitk will try it out once the change is made...
<rtg> amitk, you're gonna have to change the rebase script in the fsl topic branch
<amitk> I will
<amitk> and then push it to master for the next poor soul who has to start a new branch
<rtg> amitk, agreed
<rtg> we'll get it figured out eventually
<pgraner> anyone else seeing us.archive.u.c being awfully slow today?
<apw> amitk, i recon the rebase script should by default pull in the contents of the scripts/misc directory from master by default
<apw> pgraner, where are you timezone wise?  its always slow from here
<pgraner> apw: back in EST (NC)
<pgraner> apw: I'm getting a steady 41.8kB/s 
<apw> thats utterly shite :)
<Ng> --help
<pgraner> apw: yea now you see why I'm asking about the apt-cacher-ng thing
<apw> does it belong to us?
<ogra> rtg, for the upgrade issue from linux-imx51 you simply need to add: Conflicts: linux-imx51 and Replaces: linux-imx51 to the linux-babbage debian/control file 
<pgraner> apw: my rsync script stopped running while I was gone so I'm a week out of date :-(
<apw> yeeks life is over
<rtg> ogra, send a patch to the mailing list so I don't forget
<pgraner> apw: so I'm reworking my setup ....
<pgraner> apw: the only thing I'll need to rsync are the daily ISO bits
<apw> yeah same here, iso's get syned apt-cacher for the rest
<rtg> Ng, ? whats up with '--help' in all the channels?
<ogra> us.archive.u.c has dailies ? 
 * ogra thought they would not be mirrored from cdimage.u.c
<pgraner> ogra: no, just talking about how we do it
<Ng> rtg: shockingly poor use of irssi's /foreach :(
<rtg> Ng, ah, I have that problem some days too :)
<ogra> pgraner, ah, i thought it was related to your question about us.a.u.c
<pgraner> Ng: and here I thought you had so deep insight to the slow us.archive discussion :-(
<pgraner> rtg: I got an email from someone complaining that we dropped the DSDT patch
<rtg> pgraner, we didn't drop it, I just never forward ported it.
<pgraner> rtg: ok, at this point its the same difference
<pgraner> rtg: IIRC we decided at the sprint that we would not fwd port it, correct?
<rtg> mjg59, do you think the DSDT patch is still worth it? I consider it a bit dangerous since you can brick your BIOS with it.
<mjg59> rtg: I'd be surprised if you can brick the BIOS
<mjg59> It's certainly possible to damage the hardware by breaking thermal control, though
 * cking concurs with mjg59
<mjg59> I don't think it's necessary any more
<mjg59> We don't ship it in Fedora and there's a miniscule number of bugs from people wanting it
<rtg> mjg59, I have not checked, but are you carrying it in Fedora?
<rtg> mjg59, cool, thanks.
<rtg> pgraner, I stand by our decision to _not_ carry it.
<pgraner> rtg: ack, I'll respond, I'll document on the wiki on the Kernel FAQ
<apw> amitk, what was the syncy thing you use called?
 * rtg thinks apw speaks in pidgin english 
<apw> i have a way with words don't you think
<amitk> apw: unison
<apw> thx ... stupid name :)
<amitk> apw: wait till you find out what its written in :)
<cking> Ocaml?
<apw> amitk, you used this thing with more than one replica?
<amitk> cking: correct
<cking> and there was much gnashing of teeth...
<amitk> apw: simultaneously? no
<apw> cking, one of your favourites then?
 * cking notes it's another scripting language to learn and then forget about
<amitk> apw: you can do several 1-to-1 syncs to achieve the effect
<apw> amitk, any idea which end keeps state for the sync?  src/dst/both?
<amitk> both keep their end of the state
<apw> so doing a sync from A to B from either end is equivalent and interchangeable
<amitk> absolutely
<amitk> http://www.cis.upenn.edu/~bcpierce/unison/ , incase you haven't found it already
<apw> amitk, is this thing interactive?  ie is it asking me a question when it says:
<apw>          <---- file       bin/kpkg-check  [f] 
<amitk> apw: use -auto, it will then only bother you with the ones with conflicts
<apw> handy thanks
<amitk> apw: I use this script: http://pastebin.ubuntu.com/250854/ . I can then call it with unison-sync.sh <ip/hostname> <dir>
<apw> yeah that looks handy
<apw> i assume that makes the sync unit the whole account but then limits us to one subdir 
<amitk> if by whole account, you mean your home dir, then yes
<rtg> jjohansen, will we achieve a uec (aka ec2) flavour for this A4 release?
<jjohansen> rtg: I hope so
<jjohansen> rtg: I have run into a few problems with the suse patches though
<rtg> jjohansen, its pretty much gotta happen today. otherwise I won't have time to integrate the patch set. I may not have time anyway.
<jjohansen> rtg: right now I am running a paravirt ops build while I work on the suse patches, to see if that will work
<rtg> perhaps you just  oughta take your time and get it right. An A4 release isn't critical.
<sumanc> hi, can someone help me with linux-image-debug-<version> package?
<sumanc> i understand that its not available for all kernel versions. how can i make one myself?
<rtg> sumanc, look in debian/rules.d/0-common-vars.mk for CurrentlyBuilding
<rtg> ogra, re: fsl imax51 build times. what do you suggest?
<ogra> rtg, faster buildds :) 
<ogra> we'll get them soon
<rtg> ogra, I've been working to speed developer build times by skipping some packages.
<ogra> rtg, that wasnt a serious comment in the other channel
<rtg> ogra, couldn't tell if you were just grumbling
<ogra> nah 
<ogra> i'll wait patiently
<ogra> have my nightshifts for the week planned anyway so it doesnt matter when the buildd spits it out
<ogra> it just feels longer if you watch it all the time
<rtg> ogra, go have a beer and come back in awhile.
<ogra> yeah, i probably should do that
<sumanc> rtg, thanks. i read that file. can you please dumb it down for me a little. 
 * apw wonders if it is entirly reasonable to be checking floppies for partition tables?
<sumanc> if i do AUTOBUILD=1 fakeroot debian/rules binary-debs, will it build that package?
<apw> i assume they are supported in theory?
<apw> sumanc, i would not have expected you to need AUTOBUILD=1, otherwise i would expect that to make you some binaries to install
<rtg> sumanc, 'sudo mkdir /CurrentlyBuilding', then rerun your build. You can shortcut some of the build by running 'fakeroot debian/rules binary-debs flavours=generic'
<sumanc> apw and rtg, thanks. command 'fakeroot debian/rules binary-debs flavours=generic' is running right now
<ogra> you might want to make it skip abi and modules checking in the end of the build 
<ogra> if you made any config changes
<sumanc> but CurrentlyBuilding is created under / right? what does this do? i am running fakeroot as non-root user. will it create any permission issues?
 * ogra always runs into that 
<ogra> and sedly the check happens only at the very end of the build
<ogra> *sadly
<sumanc> i c.
<rtg> sumanc, its a convention used by the buildd's. if '/CurrentlyBuilding' exists (which it will on a buildd), then the debug packages (and some other stuff) are created.
<sumanc> i have not made any config changes, i want the linux-debug-<version> package for the systemtap to work.
<rtg> sumanc, you should be fine. note the debug package is quite large
<sumanc> rtg, thanks for the explanation. large is fine. i got a lot of space :)
<rtg> sumanc, and hopefully a fast disk
<sumanc> 5400 rpm
<sumanc> build is crawling the laptop though :(
<apw> you have an hour of grinding i'd say
<sumanc> wow
<sumanc> i am just getting into kernel hacking. is systemtap something you guys recommend? or are there other tools and practices? i want to be able to debug/look inside the hood as much as possible
<sumanc> i am used to printk, but it gets in the way and not always appropriate, i think.
<apw> cking, and every time it finds a floppy, it checks it for a partition table
<apw> which leads it to read at least 2 blocks, leading to a 50s ish delay
<ogra> apw, i doubt we would drop devicekit within the next two weeks to switch to udev only design
<ogra> and after FF such a change is inappropriate
<ogra> so fixing devkit is surely the way to go for floppies
<apw> it'll be a udev config change i think, but yes
<ogra> geez ! 
<ogra> seems linux-fsl is in its finishing stages
<apw> na you are hulucinating from holding your breath
<ogra> lol
<apw> sumanc, i tend to use printk myself for most of my debug
<rtg> ogra, armel FTBS
<ogra> bohooo
<rtg> hmm, dpkg-gencontrol: error: package linux-image-debug-2.6.31-0-babbage not in control info
<rtg> thought I fixed that
<sumanc> glad to see: dpkg-deb: building package `linux-image-debug-2.6.28-14-generic'
<ogra> rtg, well, your debian/rules seems to still have lines with -plinux-image-debug-2.6.31-0-babbage
<rtg> ogra, indeed. Is there a requirement for a debug package?
<ogra> not now, no
<ogra> the kernel wont even work properly, we have no working USB and no NIC driver atm
<ogra> its all about booting and making sure the image layout in karmic works right
<ogra> drop debug 
<apw> gurgle, arm, ... pop
<sumanc> thanks guys. i have the debug package installed now. i need to reboot to test it. thanks a lot for your help.
<mattwj2002> hi everyone
<mattwj2002> I need help
<mattwj2002> anyone know if this would be supported by the kernel?
<mattwj2002> http://www.ppa-usa.com/products/usb/usb_pci/1325.htm
<Q-FUNK> mattwj2002: hard to tell without knowing what's the chipset used for each function.
<mattwj2002> oh okay
<mattwj2002> yeah I tried googling it
<mattwj2002> no luck :(
#ubuntu-kernel 2009-08-11
<Q-FUNK> ogasawara: is there any new kernel for me to test on this Geode LX? :)
<ogasawara> Q-FUNK: building it right now
<Q-FUNK> ah, ok :)
<Q-FUNK> I would give it a spin before going to bed
<ogasawara> Q-FUNK: sorry for the delay.  I'll post a link in the bug when it's ready
<Q-FUNK> alright :)
<Q-FUNK> ogasawara: I dunno if this is relevant but, just for the heck, I tried using kernel-package on a 2.6.30 tarball with the 2.6.31-rc5 patch and that LKML guy's config and it failed to build on Karmic.  GCC kept on complaining about truncated files during build.
<Q-FUNK> it built fine using the GCC on Jaunty, though.
 * ogra scratches head, so why are all udebs built for linux-fsl ?
<ogra> i thought tim disabled them
<apw> ogra i thought there was much upset that they were missing
<apw> i think they got reenabled cause cjwatson kindly fixed up kernel-wedge to make getting them to work possible in one lifetime
<ogra> apw, yeah, it helps a lot, else i would have had to hack around it in the builder scripts, now i'm only missing meta and am done :)
<apw> i assume that'll be a simple one
<apw> now that the names are acceptable
<apw> i assume the kernel works?
<ogra> havent tested yet
<ogra> i'll do so after i rolled a rootfs/bootloader for amitk 
<apw> too late to change it a assume now anyhow?
<ogra> well, its broken anyway
<ogra> no USB and no NIC 
<apw> ya
<ogra> but it should boot
<ogra> as long as it does that i'm happy
<apw> its probabally to late to do anything about it even if it doesn't boot
<apw> i assume the archive is basically frozen from today?
<ogra> later today, yes
<ogra> but our kernel is in universe ;)
<ogra> i hacked up the builder scripts, so freeze doesnt affect us ;)
<ogra> we could upload changes until last minute if needed
<ogra> but i'm confident it boots, its amits config which i tested already and i dont belive the packaging trashed anything
<amitk> the lange boards don't have ethernet :/
 * amitk looks for usb-ethernet adapters
<amitk> apw: did unison work for you?
<apw> amitk, yeah did thank you, only used it for a small shared directory syncing back the accumulated sprint delta to it,but it seemed to work for me
<apw> i'll need a bit more time to work out how i want to use it in my existing framework, but its looking useful
<Q-FUNK> ogasawara: seems that we found our winner :)
<amitk> apw: I have a .AMIT dir in $HOME. I move all my configs into that dir and symlink it from $HOME. e.g. .muttrc, .xemacs, etc. Then I sync .AMIT to all my machines.
<amitk> ugly hack, but works.
<apw> yeah i have something similar going on in general
<apw> just the sync was mostly one sided there, and this makes it more bi directionally capable
<ogra> amitk, did the redboot work for you ? 
<amitk> yes
<ogra> good to know 
<ogra> i was told the lange requires a different redboot
<ogra> but lool was wrong (or wrongly informed) then
<apw> it may be documented to require a different one 
<ogra> yes, though it might differ between lange 5.1 and 5.2 
<apw> indeed
<amitk> confusing
<ogra> it gets funnier if you think about the fact that 5.1 is newer than 5.2 :)
<lool> ogra: Hardware might not work if you're not using Lange's redboot with Lange boards
<ogra> lool, ah, well, i think the 5.2 is still close enough to the babbage to work with TO2
<lool> It might mostly work
<ogra> 5.1 had more changes afaik
<lool> 5.1 and 5.2 share the same lange52 tree in the sources we got
<ogra> as long as it gets the kernel to run it should be fine
<lool> No
<ogra> not in redboot
<lool> In RedBoot too
<ogra> the redboot i have seen had two binary trees 
<ogra> not sure how much they differ though
<lool> Yeah one for lange31 and the other for lange 5.x named lange52
 * ogra admits he didnt look very close
<lool> Ok don't state that I was wrong then
<lool> (Sorry but it's a bit annoying)
<ogra> sorry
<lool> amitk: Lange 5.1 does have Ethernet on the board but it's wired over the USB bus
<lool> i.e. it's an USB Ethernet adpater soldered on the board
<ogra> he only has 5.2
<ogra> and no babbage anymore
<ogra> 5.2 only has wireless and no driver 
<amitk> yeah, it is a PITA to develop one since I can't get my kernel over http
<amitk> s/one/on
<ogra> thats why i set up the rootfs to be able to use flash-kernel
<amitk> true, but it requires me to build .debs I guess.
<ogra> no
<amitk> ohh?
<amitk> just copy it to /boot and  run flash-kernel, then?
<ogra> just cp your zImage over the /boot/vmlinuz-2.6.31-0-babbage
<amitk> cool
<ogra> then run flash-kernel and reboot
<ogra> i forgot to install linux-firmware, you might need that if you want to use a usb NIC
<lool> ogra: I was responding to the comment that "< amitk> the lange boards don't have ethernet :/"
<ogra> lool, yeah, i know
<lool> amitk: You might want to script some fis based script to update your SD card and take it out to write the kernel
<lool> (In case your kernel doesn't boot and you can't run flash-kernel)
<lool> That's shorter than serial port pushes
<lool> amitk: These are old notes I have to do that by hand: http://paste.ubuntu.com/251307/
<ogra> amitk, http://paste.ubuntu.com/251308/
<lool> You need the redboot-tools package for the fis command
<ogra> thats what i use with the same setup i gave you
<ogra> from my laptop
<lool> amitk: You don't need the padding
<ogra> rtg, my babbage images will build from universe, that should give us some extra hours for the meta (we can slip the freeze a bit)
<rtg> bjf, you probably ought to update the meeting page https://wiki.ubuntu.com/KernelTeam/Meeting
<rtg> ogra, I'll get the fsl meta package done today
<ogra> cool
<rtg> I live to serve
<bjf> rtg, done, I just had the date of the next meeting hosed, the rest of the info is up to date
<rtg> bjf, 'tanks
<lool> rtg: Hey Marvell currently pushed kernel trees to kernel.u.c; do you think it would be an issue if they pushed u-boot as well?
<rtg> lool, we've plenty of disk. 
<lool> Ok thanks
<rtg> lool, in general, anything they push should be gplv2. other then that I don't much care.
<lool> rtg: I'm not sure it's GPL *v2*
<rtg> lool, its some open source license, right?
<lool> I rather suspect it's a mixture of GPL versions and perhaps LGPL along; but it's as opensource as u-boot is
<lool> It is
<mjg59> A mix of GPL and LGPL is GPL
<lool> mjg59: A mix of GPL and LGPL is a mix of GPL and LGPL  :)
<lool> You might mean the binaries are effectively GPL
<mjg59> No, I mean the work is GPL. Sections of it may have additional permissions.
<ogra> rtg, btw, i changed the buildscripts already to use linux-babbage, if you pick any other binary name for meta, please let me know before the freeze is in effect (that has to go to min)
<ogra> *main
<rtg> ogra, in fact, I was just researching that. 
<ogra> well, if you use another name, tell me what it will be, livecd-rootfs needs to know the name of the binary for building
<rtg> ogra, what about updates from Jaunty? the previous meta package binary was linux-image-imx51, etc.
<ogra> you will need to add conflicts and replaces line in your new control file for the old names
<ogra> *lines
<lool> rtg: I personally have objections to the fsl-imx51/babbage names but I think we should fix that post a4
<rtg> lool, ogra: well, I'm doing the meta package right now. I might as well choose the names that you guys want.
<lool> rtg: I'd rather we change the linux image name back to imx51 after a4, but because that was already uploaded and we're in a hurry, it's best to defer to post a4 I think
<lool> rtg: The linux-image names are incorrect; I prefer if both match at all times and we'll fix it after A4
<ogra> rtg, well linux-imx51 would indeed be best and cause least hassle
<lool> I mean the ABI versionned names
<lool> I'm not sure it's a good idea to go for a mismatch at this point
<ogra> lool, lets not confuse this conversation to much, its currently only about meta 
<lool> We might not be seeing the consequences if the ABI versionned name and the meta name dont match
<ogra> because meta will go in the archive now, while the actual binaries are in already
<rtg> ok, but I'm getting different input from amitk. How about you guys get together and decide on the final names? In the meantime I'll just name the meta packages *imx51*
<lool> amitk: What's your input?
<ogra> ok, i'll change livecd-rootfs back 
<lool> ogra: ?
<rtg> ogra, just wait until you actually see what gets produced.
<ogra> rtg, i need to do it before freeze 
<lool> ogra: You dont know what the name will be; just leave it alone until you do?
<ogra> it affects other arches if i make a typo or something, livecd-rootfs is used by all live images across the board (and in main)
<rtg> ogra, then tell me the exact package names upon which your livecd build depends.
<lool> It does not affect other arches if your build fails
<ogra> lool, i had to add universe today already
<amitk> lool: send me an email in writing that all imx51 flavours will run on a single kernel and I'll agree to your proposal. IMHO, the distro should only concentrate on the dev boards, not OEM ones.
<lool> But it does if you do a syntax error yes
<lool> amitk: Ok
<ogra> lool, so i changed to what the description of the linux image package says (linux-babbage) with a note that i will change back to what it actually will be
<lool> amitk: I think the way you present it makes it highly political instead of being simpl technical but I have no problem in putting my views in an email
<ogra> i just dont want to change livecd-rootfs after the freeze
<amitk> lool: it _is_ political. Someone is going to come in a few months wanting to enable an OEM board that doesn't work off the same binary.
<amitk> then we do the naming dance again.
<rtg> amitk, how can all imx51 flavours run from one kernel? We've already got 2 ARM kernel trees.
<rtg> aren't they both imx51 variants?
<amitk> rtg: you are confusing single SoC, multiple boards vs. a branch for each SoC. I think.
<amitk> in theory, multiple boards _can_ run from a single kernel binary. If the code is written such.
<rtg> amitk, you are right in that I'm confused :)
<ogra> rtg, currently all babbage boards run from the imx51 tree ... we would like to add support for lange as well as its the same arch effectively 
<rtg> where does dove fit into that mess?
<ogra> the current naming scheme would men to have a -babbage flavour and a -lange flavour
<amitk> rtg: dove == separate SoC from marvell
<ogra> dove is a different thing
<rtg> its not imx51 compatible?
<amitk> ogra: or a -lange flavour aliases to -babbage if that is possible.
<ogra> having a -babbage and a -lange flavour would effectively enforce us to build two images for each of them (rootf images i mean)
<ogra> having simply a binary that supports all of imx51 would not cause such probs 
<ogra> and currently it doesnt look like we would actually need any -lange flavour at all, the patches all apply to the imx51 tree without touching babbage stuff afaik
<ogra> having that two name setup effectively binds the double amount of ressources, costs the double space for images and twice the amount of maintenance
<amitk> rtg: please don't get distracted by this naming issue for A4. This conversation should _really_ have been brought up after A4.
<ogra> right
<ogra> it's nothing to have now, binary kernels are up now and wont change atm
<rtg> amitk, ogra: ok, I'm gonna email the meta naming convention so that you have it in writing.
<ogra> thanks
<lool> amitk: There you go
<lool> amitk: I agree this should all be post A4
<levonshe> Hi guys, sorry to interrupt your discusssin, just simple question -  Please explain why ubuntu kernel ftp site lists separate mdules, like virtio-modules-2.6.31-5-generic-di_2.6.31-5.24_i386.udeb . I thought these modules should be a product of kernel compilation?  
<lool> amitk: Do you agree we should just use babbage in meta as well now for a$?
<lool> a$
<lool> grr
<lool> a4
 * ogra doesnt care as long as he gets told the right name :)
<amitk> lool: agreed. It will be easier to rename everything if we decide to.
<ogra> rtg, so call it linux-babbage for now and we'll adjust post A4
<ogra> rtg, and dont care about upgrade paths for now, its only important that we have solved that for final, A4 is only first shot 
<rtg> ogra, email sent
<ogra> rtg, agreed for A4 ...
<rtg> ogra, cool. when you want the names changed post A4 please start an LP bug so that we're all reading the same page.
<ogra> yeah, good idea
<ogra> lool, mind to file it since you are the driving power here ? 
<rtg> ogra, lool: make sure you assign it to me lest I not see it in the blizzard of bug reports.
<ogra> indeed :)
<lool> Sorry I'm in a call
<lool> File a bug on the renaming?
<lool> Sure can do
<ogra> great, thanks
 * ogra would do it but you have the best arguments :)
<apw> levonshe, those .udeb files are the result of kernel compilation
<lool> rtg: What's the package name for meta?
<ogra> levonshe, they are not used in normal systems though
<lool> rtg: I mean same meta?
<ogra> lool, linux-babbage says the mail
<lool> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/411968
<ubot3> Malone bug 411968 in linux-fsl-imx51 "Please rename babbage to imx51, just like in jaunty" [Undecided,New] 
<ogra> lool, meta isnt uploaded yet
<lool> ogra: I mean the source
<rtg> apw, re: bug #350789. I though we fixed it?
<ubot3> Malone bug 350789 in linux "AppArmor Debug: Hook being called from interrupt context" [Medium,Triaged] https://launchpad.net/bugs/350789
<jjohansen> rtg: we did
<apw> yeah its only on our lists cause its in an odd state
<jjohansen> rtg: status is updated
<apw> jjohansen, ta
<apw> jjohansen, is the fix applicable to Karmic, or already applied there?
<jjohansen> apw: already applied
<apw> and released?
<jjohansen> apw: yeah, it actually has a slightly alternate fix in it from the start
<apw> so its already uploaded in karmic?  then the linux(ubuntu) task should be Fix Released
<jjohansen> ah okay
<apw> and i don't think it can be assigned to a jaunty milestone
<Q-FUNK> TheMuso: it appears that those changes in alsa-utils and pulseaudio to rely upon udev features have bombed majorly.  how can we fix them?
<rtg> ogra, linux-meta-fsl-imx51 uploaded. perhaps you could annoy the various mobile team archive admins in order to get this package processed through NEW ? I'm off onto the next big thing...
<ogra> will do, i'll yank your chain if it fails to build though ;)
<rtg> ogra, I would expect no less.
<bjf> >>
<bjf> >> Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> >>
* pgraner changed the topic of #ubuntu-kernel to: "Home: https://wiki.ubuntu.com/KernelTeam/ || Karmic Kernel Version: 2.6.31 || Ubuntu Kernel Team Meeting - Tuesday, 11 August - 17:00 UTC"
<ogra> rtg, james_w had some complaints aout meta but left it through
<ogra> <james_w> ogra: I don't think there's a need for it to explain the history of linux in debian/copyright given that it's just a metapackage
<ogra> <james_w> plus, Vcs-Git is invalid
<ogra> (for the next round :) )
<rtg> ogra, what's wrong with 'Vcs-Git: http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-karmic-meta.git fsl-imx51' ?
<ogra> no idea, i havent complained
<apw> rtg, i've got a couple of karmic updates dropping stuff from ubuntu as per discussions at sprint... is the tree up to date?
<rtg> apw, nail it
<rtg> apw, and while you're at it, make sure I haven't wrecked anything. there are a few packaging changes
<apw> will do ... i'll be uploading it to my preview ppa so that'll be a good test
<rtg> ogra, the copyright does seem a bit over the top, but then its been there since Feisty AFAIK
<ogra> well, lets ask james for the actual final meta, i dont think we need to care for that one at all
<apw> rtg ok i've just uploaded karmic tip to my daily PPA
<apw> we'll know shortly if its all spagetti
<rtg> apw, well, I _did_ build it here before I pushed :)
<maco> iwlagn is currently using 101% of CPU on my system. this has to be bug.  have any of you run into it?
<rtg> maco, seems like a lot. have you contacted anyone on the wireless mailing list?
<maco> no, id thought it stopped. i dont think it was doing it with -3 but its there in -5 again
<rtg> sconklin, I'll see your comment, and raise you by one. https://launchpad.net/bugs/412039
<ubot3> Malone bug 412039 in linux-backports-modules-2.6.28 "ath5k: Add LED support for Acer device" [Medium,In progress] 
<rtg> maco, does it still happen with Karmic LBM ?
<maco> rtg: its nondeterministic. if i modprobe -r and then modprobe, itll stop
<maco> "i dont think it happened on -3" means "i dont recall getting annoyed at my keystrokes not being registered in the last couple weeks...uh...."
<maco> (when it pegs my cpu, and i try to type, some keystrokes just get dropped)
<rtg> maco, that kind of implies an interrupt storm
<maco> i can try installing lbm, but since i dont have any nice reproducible way to get it to happen...
<maco> im behind a nat, so i doubt anyone's trying to DoS my laptop and actually reaching it
<maco> if thats what you mean by interrupt storm....that the interface is being hammered
<rtg> maco, no, I mean that the firmware might be misbehaving and generating too many interrupts. Hence, your loss of keyboard inputs
<maco> ah.  i was surprised to see iwlagn being a process of its own
<maco> would lbm have new firmware? i didnt think it did
<rtg> maco, I think iwlagn still uses their own rate selection process, so perhaps its that thread running amok
<rtg> I'm checking on firmware versions 'cause I can't remember
<rtg> maco, i4965 is one minor rev newer. everything else looks the same.
<maco> alright, ill give it a try then
<rtg> doh, i4965 is the same. I'm dislexic. 
<maco> oh
<rtg> the biggest difference with LBM will be in the driver itself.
<rtg> its worth a shot
<maco> ok any suggestions on why Xorg is using 58% of CPU (now.... before iwlagn started acting up it was using 98%) when ive got compositing off? or should i ask #ubuntu-x that one?
<rtg> maco, definitely an X question
<maco> (yay dual core! actually makes it possible for wireless to use 100%, graphics to use 60% and my mail client to use 40%)
<rtg> maco, you're kind of hell on battery life :)
<maco> rtg: well none of the above SHOULD use as much cpu as they do
<rtg> maco, hence my amusement.
<maco> if i wanted to compile anything, id be screwed
<maco> itd take a week
<maco> actually, i find my cpu spins up all hot and crazy when i compile things on a remote system over ssh and dont even have that ssh screen visible (so drawing the compile output isnt the issue)
<maco> rtg: maybe iwlagn goes stupid when there's lots of small amounts of data going through?
<rtg> maco, it still generates plenty of network traffic (lots of small packets)
<rtg> maco, try using screen on the remote, then disconnect
<maco> so maybe IRC is the ame way?
<maco> *same
<rtg> hmm, IRC generates such a small amount of traffic.
<maco> when in 35 channels?
<rtg> even so, unless someone is pasting a boatload of stuff, there really isn't that much.
<maco> im trying to think...maybe the combination of IRC + KMail syncing + apt = iwlagn :(
<rtg> maco, possibly. I'd drop a not to the wireless folks. perhaps they've already seen something similar.
<rtg> note*
<maco> ok
<Q-FUNK> ogasawara: seems that I got bingo on that Bug #396286 
<ubot3> Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
<ogasawara> Q-FUNK: I'm building the next test kernel, just have to give it a while to finish building
<ogasawara> Q-FUNK: as usual, I'll post to the bug when it's ready
<Q-FUNK> ogasawara: ok. I was just curious to hear about possible causes I should watch for.
<ogasawara> Q-FUNK: that's what we're narrowing down
<ogasawara> Q-FUNK: there's 71 commits left to bisect
<Q-FUNK> oh
<Q-FUNK> between 999.200908071658 and 999.200908110142 you meant?
<Q-FUNK> as 2.6.30.999.200908110142 crashes during boot while 2.6.30.999.200908071658 didn't
<ogasawara> Q-FUNK: right, narrowing it down between those two
<Kev__> hi
<Kev__> there is a problem with the configuration of the ubuntu kernel which lets a system freeze completely
<Kev__> it concerns the configure symbol CONFIG_SATA_PMP which has some bug that will freeze some systems under heavy IO Load
<mcasadevall> apw, I have a config patch for SPARC for you (it just built off the latest head as of a few hours ago)
<mcasadevall> (I fear if I send it to the list, I'll hit the moderation queue again)
<Noble> Hi, I've got a MSI notebook with UNR installed. Some kid told me that using the 2.6.30 kernel would improve speed. How do I go about installing it?
<Kev__> speed of what?
#ubuntu-kernel 2009-08-12
<praveen_> looking for the defination of dlsym
<praveen_> anh pointers ?
<praveen_> probably its libc code 
<praveen_> I think I can find it
<aaron__> hi i'm trying to follow this doc: https://help.ubuntu.com/community/Kernel/Compile
<aaron__> but I can't find the 'debian/config' directory it keeps referringto
<aaron__> oh, sorry this looks like a dev channel
<jjohansen> aaron__: did you check out the ubuntu git tree?  debian/config doesn't exist in mainline trees
<aaron__> jjohansen: no i'm just following that doc. does it mean that's a directory within the source package?
<aaron__> i'm d/ling that at the moment
<aaron__> (apg-get source linux-image-$(uname -r))
<jjohansen> aaron__: yes it is a directory in the kernel directory
<aaron__> ok, then i should be able to find my way around... where does that land, /usr/share somewhere?
<jjohansen> aaron__: /usr/src/linux-2.6.XXXX
<aaron__> cool, thanks
<jjohansen> aaron__: or that would be my guess, standard kernel location.  I have never actually used the deb source package
<aaron__> hmm
<aaron__> huh, interesting, it puts it right in /
<jjohansen> aaron__: interesting
<jjohansen> aaron__: just a warning about the scripts, they stick the .debs etc in the dir above the kernel dir
<aaron__> ok
<aaron__> if i want to customize a standard ubuntu flavor i think i have to take the standard config, copy to .config, run make xconfig, and then copy it back and then gothrough the standard ubuntu build
<aaron__> fakeroot debian/rules etc.
<aaron__> or maybe i can point xconfig at a certain config file
<aaron__> hmm doesn't look like make xconfig loaded the standard config optiosn
<spO> do any of you know how to compile fglrx/ati drivers for a custom ubuntu kernel (after you uinstall karmic package)?
<aaron__> omg i forgot how many freakin options there were
<Yingying> anyone know the kernel version of Ubuntu 8.04.3 LTS?
<maswan> ikepanhc: give me a prod if you want me to take a new netboot kernel for a spin for testing things out
<hyperair> aren't all kernels nebootable?
<hyperair> net*
<maswan> hyperair: Oh, context that was only clearly available in my head: Bug 360966, bnx2x missing or broken
<ubot3> Malone bug 360966 in linux "bnx2x missing in initrd for install media" [Medium,In progress] https://launchpad.net/bugs/360966
<hyperair> ah
<maswan> sorry for the confusion
<hyperair> np
<apw> maswan, didn't see the context, but i though that was resolved at least for karmic?
<maswan> apw: yes, except for bnx2x not loading due to missing crc32c dependancy
<apw> i thought there was a dep on something crc related added
<apw> +libcrc32c
<apw> yeah there was a deliberate attempt to get that resolved in the patch
<apw> i see ikepanhc is looking at it
<apw> maswan, are you able to boot these blades from a usb stick?
<maswan> apw: Not currently, no. That's something else I'm trying to debug, the blade virtual media applet just gives me a grey square, and no virtual media.
<maswan> But I doubt that's the kernel at fault. :)
<apw> how annoying
<maswan> yup, and the bladecenter is 1200 km away so I have to arrange with someone else that then has to go onsite, etc, etc, if I want to try and plug something in. But is is a bit annoying to have all this new and shiny hardware without being able to use it right now. :)
<apw> does any netboot work for any release?
<apw> hardy for instance?
<maswan> hardy doesn't have bnx2x support at all, jaunty almost has it, and karmic is closest so far with module existing but failing to load.
<apw> i assume you are gettitng to a busy box?
<maswan> apw: yeah, the installer starts even and I can chose language etc, then it doesn't get very far without any network connectivity [sorry for the slow reply, collegues pulled me away from lunch]
<apw> maswan, so that implies you have access to the emergency holographic shell on VT-2 or wherever it is
<apw> so you should be able to open that and try the modprobe yourself to see what errors it reports
<apw> and to find out if the modules are in there
<apw> and indeed if the firmware is actually there
<maswan> the module fails to load due to missing symbols that look like they should come from the crc32-thingie somewhere
<apw> and is that modules on there?
<apw> libcrc32c that is
<apw> maswan, also if its there does loading it directly work, and if so does modprobe bnx2x work?
<maswan> Working on it, I did try most of this last night, but getting a console on another server now to try it "properly".
<maswan> apw: unknown sumbol in module
<maswan> might libcrc32c possibly depend on crc32c, which isn't there..
<maswan> I should probably add that to the bug.
<apw> crc32 should be there already in another one
<apw> does it not tell you the dep you need when you try and load it?
<maswan> find . -name '*crc* in /lib/modules only finds libcrc32c.ko, crc-itu-t.ko and crc-ccitt.ko
<maswan> Nope, just "Unknown symbol in module, or unknown parameter (see dmesg)", and it seems like dmesg is having issues, I haven't gotten any updates since timestamp 125.9.
<maswan> no, that's not dmesg issue, just that the libcrc32c modprobe doesn't put anything there
<apw> debian/d-i/modules/crypto-modules:crc32c
<apw> debian/d-i/modules/nic-shared-modules:libcrc32c
<apw> we are meant to be supplying crc32c at least in theory in crypto modules
<maswan> onlything in kernel/crypto is arc4.ko
<apw> bibble ... so sounds like installer failure ...
<maswan> of course, this is before I have a chance to load any udebs
<apw> could you report all that in the bug.  that the crc32c seems to be missing too, and not in crypto
<maswan> ack
<apw> rtg those packaging changes seem to be holding up so far.  the build i have in progress seems to at least have produced sane packages for lpia
<rtg> apw, thanks for the note. now I have to write up how complex I'm making the stable maintenance job. Perhaps you could review the rebase scripts in each of the topic branches. I forgot to look at them.
<maswan> And with a rebuilt initrd with copies of the modules in crypto-modules-2.6.31-5-generic-di_2.6.31-5.24_amd64.udeb the network interfaces are indeed discovered (after a manual modprobe crc32c)
<apw> maswan, you had to manually probe the crc32c?  without the probe of the network would not work?
<rtg> maswan, are you doing a network boot?
<maswan> apw: I'll retry it once more, it might just have needed to wait very long
<maswan> rtg: yes, with bnx2x nic
<apw> i would not expect a pause, but if you can confirm the load does not occur unless you manually load the crc32c then it implies there is a missing dep from libcrc32c to it, and that would likely explain why its missing
<rtg> maswan, indeed, you are probably correct.
<rtg> maswan, can you start a bug report on that? Please make sure to list the module dependencies in the report.
 * apw notes that empathy sucks... 
<maswan> rtg: it's currently a followup in bug 360966, I'll add some more info there (or open a new bug if you'd prefer) once I verify that it won't load unless I manually load crc32c
<ubot3> Malone bug 360966 in linux "bnx2x missing in initrd for install media" [Medium,In progress] https://launchpad.net/bugs/360966
<maswan> Anyway, need to spend some "quality time" with hardware in a local machine room, so I'll let it try load bnx2x without manual interference for a while
<rtg> maswan, its odd. debian/d-i/modules/nic-shared-modules:libcrc32c which implies that it should be getting loaded, though the network boot stuff may be different wrt initramfs.
<maswan> rtg: AIUI, libcrc32c is a small wrapper aroudn crc32c as of 2.6.29
<maswan> rtg: and the missing part being crc32c which makes libcrc32c/bnx2x not load
<maswan> But I'm no expert in these matters
<apw> rtg libcrc32c is being loaded, but crc32c is not... even though it is listed in our .udeb lists
<rtg> maswan, right. I think, as you've discovered, that the crc32 stuff needs to be in the initramfs when loaded by PXE. Right?
<maswan> rtg: Yes, I've gotten that far. Now there is a second potential issue, and that is bnx2x not pulling crc32c in automatically but needing a manual modprobe as well.
<maswan> I have a custom initrd with the modules from crypto-modules that I'm working off right now. Of course, that might lack some dependancy info, I guess.
<maswan> anyway, I'll let it stand at "detecting network hardware" for a while and see how it goes if I'm patient (aka doing other stuff)
<rtg> maswan, can you add the output of 'lsmod|grep bnx' to the report? That should fully describe the dependencies.
<ikepanhc> maswan: hi, you mean we still need crc32c.ko for bnx2x?
<maswan> ikepanhc: Yes, that's what it looks like from here. After I added that module to the initrd bnx2x works.
<maswan> init takes a really long time, but it did eventually complete
<ikepanhc> maswan: you mean after you add the crc32c.ko into initrd, it takes a long time, but it works?
<maswan> ikepanhc: yes
<ikepanhc> I remember I have tested, the libcrc32c.ko works fine without crc32c.ko. Its seems I need to double check it
<maswan> ikepanhc: while googling around, I found this: http://lkml.indiana.edu/hypermail/linux/kernel/0811.0/02433.html
<maswan> and it seems like that went in as of 2.6.29.something
<maswan> That's funny, lsmod doesn't claim crc32c to be used by any other module
<ikepanhc> maswan: I saw that too, so I trust what modules.dep tells me
<ikepanhc> maswan: but looking into the code, looks like libcrc32c.ko shall depends on crc32c.ko
<maswan> but before crc32c is loaded, bnx2x timesout on init of libcrc32c with some other message about missing symbol crc32c (sorry, it has scrolled off now)
<rtg> ikepanhc, the driver could be doing a dynamic module load instead of a direct symbol reference.
<ikepanhc> rtg: you mean he just register and leave?
<rtg> ikepanhc, no, probably something like load_module()
 * ikepanhc digs in
<rtg> ikepanhc, its in lib/libcrc32c.c. it loads the crc32c module dynamically.
<rtg> it eventually boils down to crypto_alloc_tfm()
<ikepanhc> rtg: ya, looks like my fault, I shall make one initrd.img for testing, not only test with insmod
 * ikepanhc changes the bug status
<maswan> ikepanhc: please let me know if there is anything you want me to test
<ikepanhc> maswan: thanks a lot.
<maswan> ikepanhc: I'm trying it again now (fiddled around with the external networking so I can get further), and it isn't that bad a slowness, but still, 2-4 minutes of waiting for "detecting network hardware" might be a bit on the long side
<maswan> then it's 50 second timeouts to see if the nics have link, x8 for all the interfaces
<maswan> hm. which gets repeated several times over all interfaces, which is why it takes so long
<maswan> but that might be an installer issue or driver issue, rather than kernel/initrd inclusion issue
<spO> is this about custom kernels?
<hyperair> spO: is what about custom kernels?
#ubuntu-kernel 2009-08-13
<cesarb> I just noticed that the builds from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc5/ do not have CONFIG_MEDIA_SUPPORT set, which makes it harder to test anything webcam-related.
<cesarb> Should I report it somewhere?
<Q-FUNK> howdy!
<Q-FUNK> I'm wondering what is the correct syntax for declaring the framebuffer size on grub cmdline, these days?  vga=794 no longer works, it seems.
<Q-FUNK> have we reverted to hex values again?
<apw> Keybuk, hey ... floppies ... do you think its reasonable to automatically scan those for partitions?  or more specificially do you think its unreasonable to not scan them?
<Keybuk> err, floppies can't have partitions
<apw> Q-FUNK, i've alway seen hex used, i have also seen vga=ask which lists them and lets you select
<apw> they really can
<Keybuk> no they can't
<apw> they have an mbr, therefore they can have a partition table, as far as i know
<apw> but i am happy to hear scanning them is stupid in your opinion :)
<Keybuk> actually that's not correct ;)
<Keybuk> floppy disks have a volume boot sector
<apw> please educate me, it not being possible is very handy
<Keybuk> not an mbr
<Q-FUNK> apw: found the solution.  it just seems that fbdev used to be compiled-in on ubuntu kernels. not anymore.  plus, it's blacklisted in some modprobe.d config.
<Q-FUNK> Ã¶Ã¶.. vesafb
<Keybuk> apw: just to confirm
<Keybuk> we're talking about the legacy floppy controller here
<Keybuk> not IDE or SCSI "floppy" drives, right?
<apw> yes, the legacy isa one, not scsi etc
<Keybuk> you don't mean ISA do you?
<Keybuk> hard-wired one?
<apw> i mean the crappy old one most of us don't have :)
<Keybuk> right
<apw> so i think thats the cause of the boot delays, devkit-disk is running on the floppy
<Keybuk> really?
<apw> and trying to find the partition table, even when there is no media, and its takign 48 seconds
<Keybuk> that's probably
<apw> i had someone time it, 48s to run devkit-disks on it
<Keybuk> that devkit-disks rules is causing a *lot* of problems
<apw> (this is the case when you dont have a floppy drive)
<apw> cool.  then i think i can simply justify skipping those checks on a floppy
<Keybuk> yeah
<Keybuk> talk to upstream though
<Keybuk> don't patch the rules locally
<apw> upstream being debian i assume
<Keybuk> no
<Keybuk> upstream being devkit-disks upstream
<Keybuk> we have a strong policy of not shipping modified udev rules for any of the plumbing layer
<apw> oh are the rules coming from there... hrm
<apw> ok ...
<Keybuk> https://bugzilla.redhat.com/show_bug.cgi?id=489083
<ubot3> bugzilla.redhat.com bug 489083 in DeviceKit-disks "devkit-disk tortures my good old floppy drive" [Medium,Closed: errata] 
<Keybuk> looks from that like davidz is quite happy with the "ignore legacy floppy" approach
<Keybuk> and this is just an omission
<Keybuk> interestingly
<Keybuk> in 60-persistent-storage.rules:
<Keybuk> KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*", GOTO="persistent_storage_end"
<Keybuk> but in 95-devkit-disks.rules:
<Keybuk> KERNEL=="mtd*|nbd*|gnbd*|btibm*", GOTO="probe_parttable_end"
<Keybuk> so they don't quite match
<Keybuk> I'll chat to David when he wakes up
<apw> Keybuk, thanks
<apw> yeah my proposal was to add fd* to the latter one
<Keybuk> right
<Keybuk> that would be the fix
<Keybuk> let me get it fixed upstream though ;)
<apw> fair enough for me
<apw> less work :)
<apw> i should mark the bug for devkit-disks i guess ... will do that
<Keybuk> yup
<apw> Keybuk, done
<mhatch> Two quick questions:  1.  Why is the AHCI and ATA drivers compiled directly into the kernel in 9.04 Server, and 2.  Is there a way to change the order in which these drivers are loaded?  I could do this with modules in the past but I have yet to determine if it's possible when the drivers were compiled directly into the kernel.
<amitk> who is our squashfs expert?
<amitk> I've got a problem with the fsl live image: http://pastebin.ubuntu.com/252472/
<rtg> amitk, apw did the port
<amitk> squashfs had to be ported?
<rtg> well, integrated I guess
 * apw looks up... huh?
<apw> that pastebin think looks like there is no filesystem?
<amitk> apw: squashfs, bug, http://pastebin.ubuntu.com/252472/, clue?
<apw> SQUASHFS error: squashfs_read_data failed to read block 0x0
<apw> it panicing after a read error might be reasonable
<apw> where is the squashfs stored?
<ogra> vfat partition
<ogra> on mmc
<apw> rtg squashfs went upstream didn't it?
<apw> it was compcache i ported
<rtg> apw, uh, right. I was confusing it with AUFS
<apw> amitk, ogra that error is nearly useless it can mean one of at least 5 different failures
<apw> probabally a decompression failure
<apw> how do we build these squashfs things?
<ogra> a simple mksquashfs
<apw> do we have a userspace tool to check its integrity like we do with initrds?
<ogra> apt-get source livecd-rootfs ... see the bottom of the livefs.sh script
<ogra>     mksquashfs ${ROOT} livecd.${FSS}.squashfs -sort livecd.${FSS}.sort
<ogra>     chmod 644 livecd.${FSS}.squashfs
<apw> ogra, i guess the first test is to pull the MMC and see if you can successffuly run unsquashfs on it
 * ogra does so
<apw> there is no real error before to say it failed to load anything
<ogra> hmm, trying to unsuqsh on i386 doesnt work so far
<ogra> http://paste.ubuntu.com/252484/
 * ogra copies the file over to an arm board
<ogra> takes a moment ...
<amitk> squashfs data shouldn't really be arch-specific, should it?
<ogra> no
<krgn> hi
<ogra> amitk, but to be sure i'll try it anyway, the squashfs was built on armel
<ogra> though it will take another 10min to copy 
<krgn> if I need to build a kernel from vanilla for some reason, how to initialise the source tree so I have all the build scripts in debian/ etc?
<amitk> krgn: you could just use the pre-built vanilla kernels if you don't need extra patches
<krgn> amitk: I do need extra patches though
<krgn> amitk: is there a script that creates debian/ ?
<rtg> krgn, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<krgn> amitk: thanks for the link
<amitk> krgn: you could also look at https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds and just download the source .deb of the last mainline build
<ogra> amitk, though i shouldnt get an oops (i dont get one on i386) even with a corrupted fs
<ogra> i can properly reproduce the oops with mount -o loop -t squashfs filesystem.squashfs /cdrom ... in the initramfs
<amitk> ogra: that bug should go upstream through kerneloops/apport
<ogra> complicated :P 
<ogra> we dont have kerneloops in initramfs 
<amitk> I can see the same issue trying to mount the squashfs on my laptop
<amitk> and it triggers kerneloops ;)
<amitk> it would be interesting to see how the armel liveimage squashfs differs from the i386
<amitk> ogra: ^
<ogra> OH !
<ogra> ogra@dove:~/temp$ file filesystem.squashfs 
<ogra> filesystem.squashfs: Squashfs filesystem, little endian, version 4.0, 179630923519 bytes, 113897 inodes, blocksize: 41 bytes, created: Sun Jan 15 06:02:56 1967
<ogra> thats pre-epoch
<amitk> heh
<ogra> i wonder if that has any influence
<ogra> it definately shouldnt but you never know
<amitk> I guess I should refuse to work on things that were created before I was born ;)
<ogra> heh
<amitk> ogra: BTW squashfs isn't oopsing. It is a warning.
<ogra> cant they make their warnings look like warnings ? 
<ogra> its confusing to have a stacktrace in a warning
<amitk> they do, WARNING: at /build/buildd/linux-fsl-imx51-2.6.31/fs/inode.c:699 unlock_new_inode+0x40/0x4c()
<ogra> yeah, but attach a stacktrace below
<rtg> apw, I'm having a brain fade. How do you get the SHA1 of HEAD for the branch you are on?
<apw> git show has it
<apw> to get just the raw one there is a command
<apw> git show-ref HEAD
<apw> hmm not sure that does what you might hope
<rtg> apw, ah, thats it.
<apw> hmmm no thats not getting the right head
<rtg> apw, 'tis for me
<apw> whats the second word tho.
<apw> on mine its a remote ref
<apw> 73aa74e5a55563ac54c161f307f8fc282a8f4e47 refs/remotes/origin/HEAD
<rtg> you're right, but its OK in my case.
<rtg> I guess you could always 'git log |head -n1 ...'
<apw> apw@penfold:~/git2/ubuntu-karmic$ git log --pretty=format:%H HEAD^..HEAD
<apw> 3844ea1e7161a8883a1a52b7b176d5f6c29be463
<apw> looks to me one way
<cking> amitk, ogra, so is this really a squashfs kernel error or not?
<ogra> cking, i start to suspect its userspace induced
<ogra> i cant loop mount the squashfs anywhere nor can i unsquash
<cking> it's not some weird endianess issue?
<ogra> we didnt have endianess issues in jaunty
<ogra> it was the very same script we used to build images
<ogra> just with squashfs-tools 3.0 
<ogra> or 3.3 or whatever
<ogra> while we use 4.0 now
<cking> ARM specific or a generic issue?
<ogra> works on the ubuntu livecds and i guess also on UNR vfat images
<apw> ogra, hrm, so unsquashfs failed too?  at least the kernel isn't going mad
<ogra> right, mount fails as well as unsquashfs
<ogra> i'm just rebuilding the image on the build servers to see if it was a temporary hiccup or something
<ogra> i'll also rebuild one locally
<apw> ogra, sensible but a bit scarey
<cking> apw, I'm getting audio clicks after ~10 seconds of not using audio on karmic on my HP mini - you referred to this a while ago - do you know what the workaround is?
<apw> thats the amps going off, there is new code to do that, power them down to save power
<apw> bug #380892 is where it was turned on and lists how to supress it
<ubot3> Malone bug 380892 in alsa-driver "[9.10 regression] HDA power_save=10"" [Undecided,New] https://launchpad.net/bugs/380892
<rtg> cking, thats the patch I showed you while in Dublin
<cking> rtg, of course, that's the one - I'm kind of fuzzy headed at the moment - I'm pain killer'd out and had a tooth worked on earlier today ;-)
<rtg> cking, dude - you should be napping :)
<cking> maybe in a couple of hours :-)
<cking> anyhow, the pain in the mouth has gone so that's a result!
<apw> cking, heh ... its funny how good one feels when a pain you had is gone
<apw> of course in your case the pop is thought to be a known issue with your specific lappy, so we don't want to fix it generally
<cking> I think there could be a work around by tweaking the EAPD pin and waiting 250ms.. hrmm..
<rtg> ogra, new crack in the Karmic Dove branch, rebased against -rc5
<ogra> cool
<ogra> i'll update my local stuff soon then
<apw> cking, ? i thought we always did that (the turn offy wait thing)
<cking> apw, not sure for karmic.
 * cking goes and has a peep
<apw> i think i've missunderstood, i though the EAPD thing was a std and supported ... clearly not
 * cking does some vague handywavy statement : possibly, it depends.
 * apw adds cking to ubuntu-audio, *whistles*
<cking> no - taint me not
<apw> toooooo late
<cking> humbug
<cking> apw, we probably should add the clicky audio pop power check to those manjo tests
<apw> yeah how would one test that i wonder
<cking> make a sound, wait 20 seconds, "do you hear a pop?"
<apw> heh yeah i guess so
 * apw notes that firefox has become a crashy pos today, and i didn't even update it
<cking> Must be the flash-tastic sites you're looking at
<apw> freshly started no flash
<cking> Hrm. I'm now on 3.5.2 - it's been as solid as the previous 3.0.x version
<apw> 3.0.13, and its new behaviour today.  and as far as i know i've not installed any fixes
<cking> if only one had "apt-unget  yesterday" 
<manjo> carefully applying all the audio patches that dtchen suggested did not fix sound on xps1300
<manjo> 1330
<ogra> probably be less careful ?
 * manjo plugs ogra's babbage 2.5 board into the network and watches it die
<ogra> :P
<cking> apw, what's the story behind the broadcom b43 driver on Karmic - where can I peek at the driver?
<apw> cking, hrm which one is that.  there are so many broadcom ones
<apw> is that the one which drives BCM43xx devices?
<apw> the one on the mini for instance?
<cking> That's what I'm confused about. I've just installed karmic in a HP mini 1000 and it's grumbling at me.
<apw> and not working?
<apw> there seem to be three options
<cking> ..yep - no workies. 
<apw> there is b43 and b43legacy in the kernel
<cking> 3 options(!)
<apw> plus there is bcmwl-kernel-source which is a dkms thingy which carries some binary blob
<apw> that is the one which works on my mini10
<apw> 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
<cking> how does one get the bcmwl-kernel-source installed?
<apw> i installed it by hand using apt-get i think
<cking> bit tricky w/o a network connecton
<apw> i think that was sufficient, reboot required i think
<apw> i used an ethernet cable to install it
<cking> that don't work either. This is a tad regression bound at the mo
<apw> a usb stick for someone at sprint
<apw> i just got the .deb from the pool and shoved it on
<cking> OK. That's a cunning plan
 * apw looks up cunning ... hmmm
 * cking wonders how the average punter is gonna handle this 
<zul_> has anyone seen this before?
<zul_> /usr/bin/ld.real: kernel image bigger than KERNEL_IMAGE_SIZE
<apw> zul_, not seen that no
<apw> cking, they arn't
<apw> thats why oem ship their own installs
<apw> cking, so any idea what an ssb id is ?
<cking> what's the context?
<apw> the b43 driver is using ssb ids for matching not pci vendory things as normal
<apw> looks to be some kind of bridgey thing
<cking> yeah "b43: probe of ssb0:0 failed with error -95"...
<apw> is that from the default kernel modules?
<cking> yep. use the source luke
<apw> now i am lost as i don't have an lsssb -nnvv to get them
 * apw is using the source and getting moany :)
<apw> cking, i wonder if lbm would help here, as it has wireless more up to date in it
<cking> maybe
<apw> that might be worth a go
<cking> urgh.. running out of time..
 * apw looks at the lbm to see what it has in it
<krgn> hey all
<krgn> I have the following scenario: I have a vanilla source tree but use the debian/ dir from karmic git
<krgn> actually I get this error too with jaunty
<krgn> but when I execute debian/rules binary-generic or binary-arch it just tells me that binary-generic isn't defined
<krgn> make: *** No rule to make target `binary-generic', needed by `binary-debs'.  Stop.
#ubuntu-kernel 2009-08-14
<krgn> good morning
<krgn> hey, is there a way to remove certain arches from debian/config/* ? updateconfigs fails because I removed some dir's for arches i don't want to build for
<Daviey> krgn: Wouldn't it make more sense to only build for the arches you want to build for?
<amitk> krgn: if all you need is a single flavour, just using the binary-<flavour> target
<krgn> Daviey: true, but when using updateconfigs target i have to go through tons of configs which I am too lazy to do ;)
<amitk> fakeroot debian/rules binary->flavour>, that is
<Daviey> ^^ Surely you can do that :)
<krgn> I guess I can just switch myself off for a little while 
<krgn> hey, is there a way to get sources for the mainline kernel anywhere?
<Kano> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
<Kano> ?
<krgn> Kano: ok ok, but I also need the ubuntu-specific stuff
<Kano> well you can use a ubuntu kernel then git pull from that
<Kano> that will update it
<krgn> you mean, git checkout origin/v2.6.29 or something
<krgn> ?
<Kano> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git
<Kano> cd ubuntu-karmic.
<Kano> git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git master
<Kano> for example
<krgn> Kano: great, I'll try this. thanks
<Kano> i am waiting for next official sync currently but you can do that to update that whenever you want
<krgn> hmm weird, I end up without debian/rules etc...
<krgn> hey, are there deb source files for the mainline kernel builds?
<amitk> krgn: I pointed those out to you yesterday
<krgn> amitk: this page: http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<amitk> krgn: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds
<amitk> go to the archive link on this page
<amitk> krgn: your link should work too
<krgn> amitk: ah but these don't have source debs so I can see how the packaging is done
<amitk> krgn: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-source-2.6.31_2.6.31-020631rc4_all.deb <-- this doesnt?
<amitk> apw: ^^^
<apw> yeah i thought we had source debs in the mainline builds?
<krgn> amitk: ah yes, but then I need to use specific version 2.6.29.6 as I patch with rt patch and aufs, and the linux-source deb doesn't contain a lot of the files in debian/*
<krgn> its quite convoluted :)
<apw> krgn?
<apw> oh hrm source .debs ...
<apw> are we copying the wrong one?
<krgn> apw: you mean wrong deb? I think that .31 would be ok, but I can't use that yet since aufs doesn't have a compat patch for rt
<apw> well the way they are made is we simply checkout the mainline version, then checkout the debian directory from the tip of the nearest release and run updateconfigs
<apw> then build, there is no rocket science involved
<krgn> apw: ah yes, thats exactly what I did. then I ran into build failure that only happens with the debian/rules  binary-arch but not when I just put a config and run make
<krgn> which is strange to me, since it doen't seem to patch anything
<apw> what was the build failure as we don't mod the source
<krgn> it fails to build kernel/power/snapshot.c because apparently there is a parse error, but this doesn't happen when I do the build manually
<krgn> http://pastebin.ca/1529303
<amitk> apw: what was the rune to quickly create a branch? 'git checkout -b foo' takes a while
<apw> if you don't need to be on it
<apw> then you can make a branch directly with git branch <name> <commitish>
<amitk> aaaaaaaah, I do need to be on it.
<apw> if you need to be on it i don't know of a quicker way
<ukev> hi... did you heared of the linux kernel root exploit?
<ukev> I've just tested it, jaunty full patched is vulnerable..
<ukev> no one here?
<ukev> its important
<amitk> ukev: our -security teams are aware of it and kernel updates are being prepared
<ukev> ok great :)....
<ukev> thanks for all the work!
<amitk> ukev: you could join #ubuntu-security to track status
<ukev> ok thanks for that hint
 * krgn wonders... are any .h / .c files by default in debian/ dir?
<krgn> this build error could be related to mismatching source/header files 
<krgn> for example, there are 3 different files called power.h in debian/ while this also exists in kernel/power/
<krgn> sorry for all teh confusing and ... thanks for the help!
<amitk> usb oops and apport == fail (atleast in my case)
<amitk> lsusb was stuck in a loop and hence apport for stuck
<amitk> s/for/was
<krgn> is this a common mistake?
<krgn> EE: Previous or current ABI file missing!
<krgn> I built binary-generic target, and so for this kernel version only one abi exists
<jnfuller> can I ask a kernel compilation question here or is this only for development discussion?
<jnfuller> mostly what I am wondering is: if I am currently running 2.6.28-14-generic (#47) and I apt-get linux source I end up with 2-6-28-9. If I apply Linus' patch for the null pointer exploit to this tree and then make and install the deb for the custom kernel what sort of issues will I have in relation to the restricted-modules. Will I need to recompile those for the new custom kernel?
<jnfuller> Or... is the patch in the works for a new kernel from the offical repos and I shouldn't bother?
<rtg> jnfuller, the latter
<jnfuller> thanks, rtg, but if I do end up having to apply this kernel (i.e. boss demands it on production systems) I'd have to apply the kernel, reboot and then compile the restricted-modules against the custom kernel in order for the proprietary stuff to work, right?
<rtg> jnfuller, any time you change the ABI, then you'll have to recompile all external, 3rd party modules.
<jnfuller> ok that's what I thought.
<jnfuller> thanks again
<krgn> hey, how do I bump the abi? do I do this in the changelog?
#ubuntu-kernel 2009-08-15
<dtchen> ogasawara: i'll look at the realtek stuff from hardy-lum tomorrow (sat 15 aug)
<krgn> hi
<krgn> if I want to host a kernel on a ppa, do I use the build-mkppa script or is there another process?
<krgn> or does it just come down to debuild -S -sa?
<laga> apw: ping. i hear you're the guy to bug if we (mythbuntu) needs a kernel option enabled. we need CONFIG_AUFS_BR_RAMFS=y so we can properly use aufs in our diskless setups
<samgee> what are the debian/d-i/modules/ files for?
<samgee> why do most lines have a question mark, but some don't?
<ijuz_> stupid question: a security updates going to be released because of the recent kernel root exploit (the one from 2 days ago)?
<crimsun_> ijuz_: it's likely; a more precise answer will be had during the work week.
<elmo> it's probably worth pointing out that unless you installed wine or dosemu, recent versions of ubuntu aren't vulnerable
<elmo> (6.06 is though, so I'm sure there'll be USNs on Monday)
<ijuz_> ok, thanks
<crimsun_> on the other hand, spender seems intent on insisting that his exploit(s) works regardless of protection mechanism
<crimsun_> (http://seclists.org/fulldisclosure/2009/Aug/0190.html)
#ubuntu-kernel 2009-08-16
<mjg59> crimsun_: It can only bypass mmap_min if you're either using selinux or have a vulnerable pulseaudio
<mjg59> I have no idea whether Ubuntu's selinux setup results in issues - I suspect it's ok, but know that Debian had the same problem as RH here
<dschulz> hi all
<dschulz> installed 2.6.31-6 recently
<dschulz> had to manually select it 
<dschulz> i mean the package
<dschulz> was not detected as an update for 2.6.31-5, though
<dschulz> and yes, got linux-image-generic installed
<dschulz> a few minutes ago booted the kernel to see how it goes
<dschulz> in 2-3 minutes the system got hung
<dschulz> now back to rc5
<ameno> hi! ive been using the automated vanilla builds for a while (mainly 2.6.29-02062904, 2.6.30 had a regression) on my jaunty desktop. i now updated to the 2.6.31-rc6 build, but all drivers/media modules are missing...
<ameno> noticed because my tv card does no longer "work", because no module is loaded
<crimsun> ameno: right, the config is not synced
<ameno> synced == taking the ubuntu .config defaults and use them there?
<crimsun> right
<ameno> will this be fixed (soonish)?
<ameno> today's vanilla build still does not use ubuntu's default config
<juliank> Hi. I just wanted to know what the plans are with regard to union mounts in karmic. Will it use aufs2 or unionfs2, or will FUSE-based solution be used? 
<ogra> aufs is in the tree 
<ogra> it is used since a while again 
<ogra> aufs2-30 to be precise
<juliank> ogra: OK. Just asking because aufs2 requires 18 symbol exports and is much larger than unionfs (which is the reason why Debian still uses aufs1 from January). 
 * laga waves at ogra 
<ogra> hey laga 
<laga> how's it going?
<ogra> busy
<tormod> hi, I am starting netconsole in the initrd. it works, but the firmware loading for the network card (tg3) hangs for a minute and fails, even though the lib/firmware files are present in the initrd. am I missing something?
<TomJaeger> apw, can we talk about http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=6ef9b7dc073c6cff9bd3e700aa03f52094f5171e ?
<tormod> hmm guess I was missing lib/udev/rules.d/50-firmware.rules
<dhillon-v10> hi everyone
#ubuntu-kernel 2010-08-16
<pwp> Hello
<pwp> Is anyone here?
<RAOF> !ask
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<RAOF> Hm.  With an added side order of âIt's about 3AM in England where much of the kernel team areâ
<ikepanhc> or it is still weekend for west coast of US?
<bdrung> https://wiki.ubuntu.com/Kernel/Dev/UKMLPatchSubmission says: "After you push your changes to your remote git tree use git request-pull to generate a pull request". I have no remote git tree for the kernel. Where should I push it?
<bdrung> here's the patch that I want to get included: http://pastebin.com/6qrs71kt
<RAOF> bdrung: You probably want to git-send-email that, rather than to generate a pull request.
<ikepanhc> bdrung: if you dont have a public git server, just post the patch on mailing list
<bdrung> do you have a git-send-email command example for me?
<RAOF> âgit send-email --to=xorg-devel@lists.x.org HEAD~1â - sends the last commit to xorg-devel@lists.x.org
<bdrung> is it enough to ask to apply the patch also to lucid?
<ikepanhc> https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide#Sending your patch to mail list
<ikepanhc> I need to update the wiki someday...
<bdrung> ikepanhc: are the params mention in https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide#Sending safe to use?
<ikepanhc> bdrung: for one patch, yes. for patches, maybe not
<bdrung> ikepanhc: i haven't msmtp installed.
<mjg59> ikepanhc: Off-topic, but do the docs you have for the VPC2004 interface include the rfkill interface?
<mjg59> I'd really prefer that the driver not use the direct EC setting calls
<ikepanhc> bdrung: you can install it
<ikepanhc> mjg59: yes. can you tell me why you not prefer that?
<bdrung> ikepanhc: hm, now i have to configure it...
<mjg59> ikepanhc: I may have been unclear. I was ok with dwmw2's code because reverse engineering the VPC2004 calls didn't seem straightforward, but I'd prefer that ideapad driver use methods that are under the VPC device rather than explicitly calling functions under _SB
<mjg59> ikepanhc: So your one seems fine, except for it not supporting rfkill :)
<ikepanhc> mjg59: oh, there are two acpi method in VPC2004 that help writing to ec register, I will use the method not ec_write()
<ikepanhc> mjg59: the doc tells me I shall use the acpi method to access ec register
<mjg59> ikepanhc: Argh, sorry, I'm confusing everything now
<mjg59> ikepanhc: David Woodhouse was using \_SB_.GECN
<mjg59> Whereas I suspect he should be using something that's within the VPC device
<ikepanhc> mjg59: yes, but only s10-3 has  GECN, but other ideapads not
<mjg59> Exactly
<mjg59> So if you know how to control the radios using the VPC methods, it'd be a huge help if you could implement that so we don't have it relying on the GECN method
<ikepanhc> mjg59: yes, there are two method within VPC2004 that we can read/write two ec registers
<mjg59> ikepanhc: Right. If those can be used to control the radio, that would be awesome.
<ikepanhc> mjg59: they can :)
<mjg59> ikepanhc: Awesome. If you could write the code to do so, that would be even better :)
<ikepanhc> mjg59: that's my plan
<mjg59> Great
<bdrung> ikepanhc: i defeated msmtp, the mail is send.
<ikepanhc> IIRC I spent almost one day on msmtp when first time use it
<bdrung> google was my friend
<bdrung> time to go to bed...
<ikepanhc> bdrung: good night
<MTecknology> So 2.6.36-rc1 is finally here. AppArmor support is now in mainline. :D
 * apw yawns
 * smb slurps some more coffee
<cooloney> moring apw and smb 
<smb> cooloney, morning
<RAOF> Morning all.
<JFo> :-P
 * JFo longs for the sleep that should have been last night
<JFo> morning cooloney 
<JFo> morning RAOF 
<smb> JFo, Sounds like you could be ultra-wake later on the call
 * RAOF wonders if many people are worried about the âconflicting fb, removing generic driverâ messages in dmesg.
<cooloney> JFo and RAOF morning guys
<JFo> smb, no call today
<smb> JFo, Ah ok
<JFo> I should have sent e-mail, but it is likely that it didn't get out
<smb> Oh right, you are away
<smb> In the "wrong" tz
<JFo> was having issues with my mail :(
<JFo> or the right one :)
<smb> Heh, yeah
<smb> What happened to Friday? Not that I would have been any prepared
<JFo> I forgot about it
<JFo> naturally
<JFo> plus it took forever to get my glasses from the store
<JFo> so I would have been extremely late anyway had I remembered
<ikepanhc> new installer for maverick looks interesting - asking infomation and copy file in the same time
<apw> yeeks
<amitk> ikepanhc: I should try it out. I've alway wondered why I can't play tic-tac-toe during an install :)
<ikepanhc> amitk: give the machine ethernet connection - seems will install fail if no connection
<ikepanhc> ah, installer do not ask me the computer name..
<ericm_> apw, how debian.mvl-dove/d-i/kernel-versions is generated?
<apw> ericm, fdr clean generates it
<ericm> apw, it looks like a package list - where's the list generated?
<apw> ericm, kernel-versions is generated from kernel-versions.in in the debian/rules file
<ericm> apw, ah - I see
<ericm> apw, so what are the purpose of those debian.mvl-dove/d-i/exclude-* files?
<ericm> the modules listed will be excluded from the udeb for installer?
<apw> they adjust which debian-installer .udebs are generated as compared to the 'default' list
<ericm> apw, but the file name is prefixed with 'exclude' ??
<apw> yes, they 'adjust' the list, in this case negativly
<ericm> apw, so they 'adjust' the list by removing those .udebs from the 'default' list?
<apw> yep
<ericm> apw, got you
<bdrung> my lirc patch mail doesn't appear on https://lists.ubuntu.com/archives/kernel-team/2010-August/thread.html - do you received the mail?
<xampart> i have 2.6.32-24-server. when i try to create lvm-snapshot, it hangs. known bugs concerning this kind of behavior?
<apw> smb, ok the LBM package change looks ok, but it does imply that the meta packages are updated, which tim is not wanting to do
<apw>   You likely do not want to install this package directly. Instead, install
<apw>   the linux-backports-modules-compat-wireless-2.6.34-generic meta-package, which will ensure
<apw> thats the note on the 34 package, but there is no linux-backports-modules-compat-wireless-2.6.34-generic meta package currently
<smb> apw, Ok, I will need to make that consistent before I push out things
<apw> well its not really a show stopper and can be corrected as a second patch if he decides not to fix meta i guess
<smb> Yeah, I'd do it as separate update to the initial ones
<apw> so yeah i'll ack the LBM update, and leave comments on the meta
<smb> ok, ta
<apw> smb, done
<smb> cool
<xampart> getting http://pastebin.com/WQ8xLSwH when trying to lvcreate and system hangs. using 2.6.32-24-server. need fix.
<smb> Hm, had no reports yet that this would affect lvcreate. Is snapshot involved?
<xampart> yes
<smb> Ok. There is a fix. Trying to find where kernels with that might be
<smb> Normal proposed updates are waiting on finalizing the point release. You might try -25 kernels from: https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<xampart> smb: assuming that when normal updates are released, they get installed when doing update && safe-upgrade?
<smb> Normal updates should always supersede pre-proposed. So when you remove the source to the ppa later you will come back to the normal updates kernels
<apw> lool, have you filed a bug already for the purge issue?
<lool> apw: Yes, it's the last one on my list
<lool> LP #618591
<ubot2> Launchpad bug 618591 in linux (Ubuntu) "Leaves modules.devname and modules.softdep behind in /lib/modules (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/618591
<bdrung> i send a lirc patch mail (lirc - Fix Hauppauge TV Card is detected as Leadtek IR) but it doesn't appear on https://lists.ubuntu.com/archives/kernel-team/2010-August/thread.html - Can a kernel-team subscriber check if he/she got the mail?
<JFo> bdrung, when did you send it?
<JFo> I don't see it
<bdrung> 8 hours ago
<JFo> yeah, I don't see it
<bdrung> JFo: ok, i have sent it manually now. do you get it and is the format still correct?
<JFo> bdrung, one moment... I will check
<bdrung> ups, my signature was added
<JFo> still not seeing it bdrung but it takes a while for me to get things on occasion
<JFo> I'll check again after lunch :)
<bdrung> thanks
<diwic> JFo, you have an automated script that ask people to try mainline kernels.
<diwic> JFo, I'm wondering whether that is the best test option
<diwic> JFo, I usually ask people to test the c-o-d builds instead
<diwic> JFo, this is all about kernel-sound bugs, of course
<apw> diwic, which c-o-d builds do you ask them to test?
<diwic> apw, https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules
<apw> JFo, its possible we should be asking for those as well for 'sound' bugs
<bdrung> JFo: ok
<bdrung> this time the mail is in the log
<JFo> bdrung, now I see 2 of them
<JFo> diwic, I ask them to test mainline so we can bisect what upstream stable has versus what we have in development
<JFo> are the items in the link you provided different from those 2?
 * JFo checks the link
<bdrung> JFo: strange... both appeared on https://lists.ubuntu.com/archives/kernel-team/2010-August/thread.html
<bdrung> JFo: you can use one for maverick and the other for lucid ;)
<diwic> JFo, I don't think we have much delta sound-wise so I don't know if that makes sense
<diwic> JFo, or, it does make sense, but question is if anything else makes even more sense
<JFo> bdrung, looks like one has a PGP sig and the other does not... only difference between them that I see
<bdrung> JFo: yes - it's the same. it applied on both :)
<JFo> :)
<JFo> diwic, I am open to suggestion if you think it is useful enough
<diwic> JFo, right, so I'm asking users to try c-o-d to know if upstream has fixed the bug (or hardware enabled...) recently.  
<diwic> JFo, and this is possible because c-o-d builds are relatively stable 
<diwic> JFo, Takashi does a good job in keeping them fairly stable, but of course, that could change.
<apw> diwic, i assume those packages are de-installable also ... so not the end o fthe world
<diwic> apw, yes, they are as uninstallable as <random other package> 
<apw> diwic, on a related note, that page could do with updating with "uninstall instructions" for those who don't know how packages work
<apw> i believe there is a 'ppa-purge' thing you can use
<diwic> apw, sounds interesting. Yeah, I guess updating those pages falls on me now
<apw> :)
<apw> well as you know that that one exists, and are the one pointing to it, you are uniquly qualified to check it
<diwic> apw, it's on my TODO list
<apw> http://bigbrovar.aoizora.org/index.php/2010/01/10/how-to-safely-remove-ppa-repository-from-ubuntu/
<apw> diwic, ^^ seems to document it
<diwic> apw, cool
<diwic> apw, hmm, seems like you have to install that from another ppa 
<apw> yeah not so cool.  sounds like something which should be moved to the apt-add-repository package
<diwic> apw, my thought exactly
<apw> diwic, seems the package is at least an official package from lucid
<diwic> apw, good enough, but merging into add-repo would be even better
<diwic> apw, from maverick, unfortunately
<apw> diwic, yeah seems to be in -backports only on lucid
<diwic> aha
<apw> but as its an LTS, i am thinking that might be short-sighted
<diwic> apw, how to you easiest check what releases have a particular package?
<apw> either rmadison <package> or i use the 'versions' page
<apw> https://edge.launchpad.net/ubuntu/+source/ppa-purge
<apw> smb, so the pre-proposed build of LBM seems to have made its way into the PPA ok
<apw> i therefore declare LBM support working in cod
<smb> Yes. Saw that a bit ago. Ok, wfm
<diwic> apw, hmm, I use http://packages.ubuntu.com/ppa-purge , but that one shows no results.
<apw> diwic, never used that one
 * diwic notices that a rmadison search on google results in, excepts for the correct ones, also "A vintage 1969 Mercedes", "A chill individual"
<diwic> and a few others
<apw> diwic, heh ... well the service itself is called madison
<apw> the cmdline app is rmadison
<diwic> apw, anyway, I added uninstalling without removing the ppa for now.
<apw> diwic, sounds good
<apw> i'd say if its well documented, adding it in jfo's call in the bug is appropriate
<KE1HA> sri to both you guys, know your very busy atm, but Im testing 10.04.1 ISO's, is there a fix for the Intel i855 chipset black screen issue in this release ?
<KE1HA> Bother*
<JFo> apw, I agree. It can't help bug be beneficial
<diwic> apw, JFo, I'd like if we would replace "test mainline builds" with this. Testing mainline wouldn't give me/us much more information    
<diwic> compared to the additional effort 
<apw> in principle we should be doing whatever the area expert recommends we ask for ... imo
<diwic> of the user
<JFo> apw, indeed
 * diwic looks around for an area expert... ;-)
 * JFo looks pointedly at diwic 
<JFo> :)
<diwic> "Audio area expert",  that might be something for a business card. 
<JFo> I'll check and see what will be needed to get this going along with bjf as he is expert on the scripts. It may be simple, but if it is not then we shall put it in the todo for later
<JFo> rather a bit later
<JFo> not just later
<diwic> Sure, it's nothing urgent.
<apw> i think we get a sound tag from apport 
<diwic> There aren't that many kernel-sound bugs anyway, as most of them go to alsa-driver
<JFo> apw, we do
<apw> so perhaps we can be conditional on that
<JFo> oh yes, that is the plan
<bjf> JFo, diwic, i've read the scrollback and can't really tell what you'd like changed in the arsenal scripts, can you educate me
<diwic> bjf, if the linux bug is a sound bug, change "please test mainline build" to "please test takashi's c-o-d"
<diwic> bjf, I think that makes more sense, what do you think?
<bjf> diwic, i'm staring at the auto reply messages now
<bjf> diwic, i'm going to send the file that contains the text to you and JFo, it should be trivial to change the text
<diwic> bjf, btw, I saw the c-o-d builds ftbfs today but I believe that is fixed by Takashi so tomorrow's one will work
<bjf> diwic, was it the i386?
<JFo> bjf, this needs to only be for the 'kernel-sound' tagged bugs. Do we do a specific message for those now?
<JFo> sorry for the late response, I'm in a meeting. :-/
<bjf> JFo, there are sound specific messages in the message file, and I _think_ we use them
<JFo> ok cool
<diwic> bjf, yes, it was an old isa driver which was not enabled in amd64 
 * JFo needs to look over the script again
<diwic> bjf, so the error only occurred on i386
<apw> sconklin, is there a dead-give-away to knowing if a machine is an aarandale
<sconklin> apw: cking would probably know which bits in the processor ID give it away
<apw> sconklin, he is off for two weeks, so you are in the frame as expert :)
<sconklin> hmm. let me check
<sconklin> apw i7's all are I'm just not sure about any other IDs
<diwic> bjf, so I saw arsenal_reply.py you sent me, and I think the test_upstream reply needs to be split in two, one for sound bugs and one for non-sound-bugs
<sconklin> as well as i5 5xx aparently. I'll look for something more definitive
<apw> sconklin, isn't there a known issue with aarrondale in gneeral with suspend not working
<apw> smb, ^^
<apw> where you use something like nolapic or nohpet can help
<sconklin> Well, there were several I think, and some have been fixed by cking. But I don't know what they are.
<bjf> diwic, did you see the "sound_bug" and "alsa_old_bug" entries?
<diwic> bjf, yeah perhaps change the text in those as well 
<smb> apw, hm, I am a bit out of context. There were probably various things. Including incorrect timer irq override...
<bjf> diwic, I accept patches :-)
<apw> smb, i am scrabbling without contxt myself, but i did think we had a slew of issues with suspend/resume on those puppies
<apw> and i thought we were fixing them by quirking
<sconklin> apw http://www.cpu-world.com/Cores/Arrandale.html
<apw> sconklin, ta
<sconklin> for IDs
<smb> apw, Hm yeah. Wasn't there tsc jumps after resume....
 * smb tries to remember how that could be quirked
<apw> smb, yeah that period .... wern't some of the expidited patches for that sort of thing?
<smb> There was something... to handle warps... somewhere...
<apw> smb, you wouldn't be able to find that one for me would you
 * smb tries
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374
<ubot2> Ubuntu bug 532374 in linux (Ubuntu Lucid) (and 3 other projects) "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend (affects: 58) (dups: 4) (heat: 229)" [Critical,Invalid]
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/477106
<ubot2> Ubuntu bug 477106 in linux (Ubuntu) "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware (affects: 147) (dups: 25) (heat: 539)" [Medium,In progress]
<diwic> bjf, bug #596882 is an example where I should have preferred c-o-d testing, but the text is neither alsa_old_bug or sound_bug, but test_upstream
<ubot2> Launchpad bug 596882 in linux (Fedora) (and 1 other project) "[ALC888] No Sound - used a clean Install of Maverick 10.10 (affects: 5) (heat: 88)" [Undecided,New] https://launchpad.net/bugs/596882
<bjf> diwic, that's more than a text change, i'd have to look at why that text string was being applied and "fix" the logic to use one of the sound text messages instead
<diwic> bjf, exactly, so I could probably give you a text (which someone with native English language could proofread), but I don't know anything about the logic behind.
<bjf> diwic, ack, I was hoping it was just a text change
<apw> pgraner, which model is your lenovo?
<pgraner> apw, t410
<apw> pgraner, ta, not that then
<JFo> I have a t410s
<JFo> the S is for Special ;)
<smb> Rather Small
<smb> Its the netbooks
<JFo> if it is on i7 then I have a desktop at the house I can test on when I get home
<smb> I would guess the Sxx are rather atom based
<Kano> hi, when is .36-rc1 in mainline
<apw> Kano, normally a few hours after release, its queued ... 
<Kano> ok
<apw> Kano in fact it didn't build, and won't as its broken
<GrueMaster> JFo: Bug 618738.  Anything else I need to add?
 * JFo looks
<Sarvatt> apw: is disabling comedi so mainline post 1685e633b396b0f3dabbc9fa5d65dfefe6435250 builds an option? 
 * Sarvatt doesn't know how much of a pain in the butt that is with the build infrastructure
<apw> Sarvatt, depends if they have fixed it up stream already i guess
<apw> there is no simple way to turn it off in an automated way
<GrueMaster> but without comedi, there won't be any humour.
<apw> arf
<tgardner> Sarvatt, the easiest way is to comment out the line in drivers/staging/Makefile 
<apw> i suspect he wants it in the mainline archive
<Sarvatt> I dont see any fixes in any of the staging trees or on the lists :(
<tgardner> apw, ah, you might have to add some hackage in yuor mainline build scripts.
<apw> tgardner, i can fix the -rc1 build, but its not obvious how one automates fixing that other than always turning off COMEDI
<apw> tgardner, and it sounds like it might be more than comedi
<tgardner> apw, well, shuold we bother building staging for mainline?
<apw> tgardner, we do use a fair number of the drivers in released kerenls, so not enabling staging drops those and renders the kernels useless for some users
<Sarvatt> it'd be a shame not to since stuff like nouveau is still in there
<apw> and there i was just thinking of some of the wireless drivers ... 
<apw> hrm ... what a pain thats going to be
<Sarvatt> how about just allowing arbitrary patches and disabling it in one?
<apw> well i can do that, but how do i know when to drop it
<apw> its not a technology issue as much a maintenance issue
<Sarvatt> check to see if drivers/staging/comedi/drivers/das08_cs.c has changed before patching? next time it's updated it'll probably be fixed
<apw> see now thats not an arbiray patch, thats a patch with a really complex trigger
 * Sarvatt adds http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=rss;f=drivers/staging/comedi/drivers/das08_cs.c to his rss feed to tell you when its fixed?
<pgraner> smb, can you  look into https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/405544   There's some evidence that it /may/ be kernel related, but I need your opinion.
<ubot2> Ubuntu bug 405544 in linux (Ubuntu Lucid) (and 4 other projects) "Kernel does not recognize blank optical media (affects: 87) (dups: 13) (heat: 404)" [Undecided,New]
<smb> pgraner, I could but atm I am a bit covered by multiple layers of things. how critical is it
<pgraner> smb, not critical, sometime next week when you have some spare cycles, or kick it to one of your minions either way not critical at all
<Sarvatt> i set up an email alert for the rss feed for that file in git
<apw> Sarvatt, heh thanks
<smb> pgraner, ok I add it to my list then and see who when 
<pgraner> smb, cool this was a request from robbiew, so if you have any questions that are foundations related you can ping him
<smb> ack
<tgardner> apw, do you know how I can tell if ureadahead has done its job correctly? I've a patch proposed in https://bugs.edge.launchpad.net/bugs/491943, but I'm not sure if it just doesn't paper over the problem.
<ubot2> Ubuntu bug 491943 in ureadahead (Ubuntu) (and 2 other projects) "Kernel trace buffer should be set to less unrealistic value (affects: 16) (dups: 2) (heat: 88)" [High,In progress]
<apw> tgardner, you could dump the pack it generates before and after the change and see if they are similar ?
<apw> tgardner, there is a textual dump option
<tgardner> apw, k, I'll try that
<apw> smb, that bug that robbiew is referring, its not clear that the kernel errors there are meaningful, in that somone is opening the drive to identify the contents and there is blank disk in there so block 0 is missing wihch its reading to acertain itstype ... and the last comment shows it being recognised at a udev level as a blank disk
<apw> smb, and my machine recognises blank cd's and asks to write to them
<apw> pgraner, ^^
<robbiew> apw: yeah...and the fact that k3B works
<apw> that too
<apw> whats the default cd writer in gnome, as thats waking up for me
<robbiew> I think nautilus has some sort of basic feature for it
<robbiew> but brasero is the default app
<smb> well it might be something related to ioctls that the drive does. there have been fw issues on drives as well
<apw> and the bug is a usless dogpile started when karmic was in development
<smb> apw, We might chat about it tomorrow if that is still a question by then
<robbiew> apw: I'm only interested in Lucid...I declined the others
<robbiew> (Maverick and Karmic)
<apw> yep, but the info in the bug is mostly older, as always
<apw> robbiew, works with brasero here ... though its a terrible app to understand and not the one that comes up by default
<robbiew> apw: yeah...as the bug says, some people don't see it...probably hardware related
<apw> so we should really close the bug and get everyone seeing it to file a bug with their h/w info
<robbiew> apw: works for me
<apw> or perhaps as we don't know its a kernel bug, or indeed h/w related in fact, perhaps get them to open bugs each against linux and add the numbers to that original bug ... hrm
<smb> apw, ogasawara Does Maverick already use an orig.tar.gz 
<apw> smb, it should by now in theory
<apw> smb, but it doesn't look like it does
<apw> we should get the 2.6.35 virgin tarball from linus for the next upload
<smb> apw, Ok, that answers my next question
<apw> thats what we've done for the previous releases, as anyone can get that from linus too
<smb> Because I was remembered that back in Hardy it was not a virgin release but sort of a virgin stable 
<apw> cnd, you may need to encourage them to come talk ...
 * tgardner lunches
 * smb drops into a hole
 * jjohansen -> lunch
 * ogasawara lunch
<cnd> apw, cjwatson says the balls in your court, regarding the radeon gfxpayload issues
<cnd> have fun with it :)
<apw> deep joy
<akgraner> jjohansen, give me 10 minutes (if the Ubuntu User site doesn't kick me out *again*) - the AppArmor stuff will be up - I'll drop you a link in just a few - Thanks again!!!
<akgraner> jjohansen, here is the link to your interview - http://www.ubuntu-user.com/Online/Blogs/Amber-Graner-You-in-Ubuntu/AppArmor-makes-it-into-the-2.6.36-Upstream-Kernel
<akgraner> Thanks!
<jjohansen> akgraner: thanks, for putting it together
<MTecknology> akgraner: The sucky thing is that it seems with the addition of apparmor - ecryptfs is breaking
<jjohansen> MTecknology: how/where? pointers please
<jdstrand> uhh, not here
<jdstrand> I use both extensively every day
<jjohansen> jdstrand: well its not like it hasn't happened in the past so I would like to make sure we are on top of it
<MTecknology> I'm pulling it up
<jdstrand> jjohansen: oh absolutely, I just meant I've not seen it and more info is needed
<jjohansen> jdstrand: right I haven't seen the breakage either, but then thats always the way for me.  Otherwise I would have fixed the bug before the code got pushed :)
<MTecknology> jjohansen: When I log in I do ls -l I see d????????? ? ?      ?      ?        ? Desktop
<MTecknology> Also  ls: cannot access Desktop: No such file or directory
<jjohansen> heh?  Your shell outputs that?
<MTecknology> yup
<jjohansen> MTecknology: do you have AppArmor rejects in your logs?
<MTecknology> jjohansen: <date/name> kernel: apparmor_parser[372]: segfault at 0 ip 00007f075a1ac5d6 sp 00007fff44310868 sd error 4 in libc-2.11.1.so[7f075a1a07f000+17a000]
<jjohansen> MTecknology: strange? are there any other apparmor messages around that?  From the error I would say its completely user space.  This means that the loaded policy may be looser than what was intended but definitely not tighter
<MTecknology> jjohansen: there's two about the same but that's it
<jjohansen> hrmm, can you run >sudo /etc/init.d/apparmor restart
<jjohansen> and tell me if those errors show up in your logs
<MTecknology> jjohansen: errors are just output by restart..
<jjohansen> what type of errors?
<MTecknology> xargs: /sbin/apparmor_parser: terminated by signal 11
<jjohansen> MTecknology: what kernel are you running?
<MTecknology> cat: /sys/kernel/security/apparmor/profiles: so such file or directory
<MTecknology> v2.6.36-rc1
<jjohansen> right
<jjohansen> So you need to wait for the updated tools
<MTecknology> oh..
<jjohansen> Basically what is upstream is not fully compatible without some additional patches
<jjohansen> For example the profiles virtual file went away as it is not very sysfs like
<jjohansen> MTecknology: I am working on a wiki page explaining the details
<MTecknology> jjohansen: Please send me a link when you get that wiki up
<jjohansen> MTecknology: will do
<MTecknology> jjohansen: anything I could do now - like disable the apparmor module?
<jjohansen> MTecknology: you can do that if you would like.  You can pass apparmor=0 as a kernel command line parameter and then user space should even try to load policy
<MTecknology> jjohansen: Where would I set that in grub2? That thing is still a confusing beast for me
<MTecknology> jjohansen: heh.. look at grub.cfg instead and it gets easier :P
<MTecknology> Except what I did didn't work - I just added it to the kernel line
<MTecknology> I suppose I should run off though
#ubuntu-kernel 2010-08-17
 * abogani waves!
<smb> morning
<jj-afk> morning
 * apw yawns
 * smb wonders whether he should give apw virtual coffee. :)
 * apw looks blearily at his real tea
<RAOF> See, there's your problem.
<jk-> RAOF: lol
<RAOF> Tea is very sensitive; looking blearily at it can only result in tears!
<apw> the trade off is the risk of dropping the tea in my lap due to tiredness induced incompetance against the restorative effects of the contents ...
<smb> At least you would be awake then
<RAOF> Dropping tea in your lap would certainly provide a temporary buff to attentiveness.
<jk-> apw: on the other hand, that would wake you up
<jk-> snap * 2
<smb> three minds one thought
<apw> thats not the kind of awake i approve of
<jk-> it's the kind of slapstick we approve of, though
<RAOF> You haven't been fitted with the special Canonical underwear I take it then?
<smb> Actually, wasn't that fortified on the opposite side only? :-P
<apw> heheh
<JFo> apw, should I be showing you guys any kino bugs or do we care about those?
<apw> kino ?
<JFo> yeah...
<JFo> one sec.
<JFo> bug 6290
<ubot2> Launchpad bug 6290 in baltix (and 1 other project) "DV capture over Firewire is broken (no rights for /dev/raw1394) (affects: 41) (dups: 10) (heat: 306)" [Undecided,New] https://launchpad.net/bugs/6290
<JFo> doubt it has to do with us but there was a legacy team group subscribed to the bug
<JFo> I've unsubscribed it
<JFo> but I have no clue what kino is
<apw> JFo, i would guess its a codename ... but given the age of that bug we are not interested anyhow, its like dapper time isn't it ?
<JFo> yeah, I think they need to open a new bug
<apw> oh its an app, but the age is the key here i ithink
<JFo> k
<apw> if they are reporting on that one ... i'd get a fresh one opened
<JFo> will read through it then and decide what is needed
<JFo> cool
<ogra> it the typical DV capture tool 
<JFo> thanks :)
<ogra> and is the one app that always exposed the brokeness of the FW stack
<ogra> JFo, given that there are recent comments from users that it is fixed for them, i'd set it to fix released no matter how old it is
<JFo> k, that was what I was thinking too
<apw> JFo, i think that bug can just be left alone
<apw> its mostly (in this year timeframe) about switching to the new firewire stack and that being a good thing
<JFo> apw, ok
<JFo> yeah saw that
<apw> as we have done that in maverick i suspect it is fixed in maverick from the user perspective, but not 100% sure how to be sure
<JFo> just not sure who is responsible for kino
<apw> as if it was we could close it there
<apw> JFo, as it seems to be an app, not us :)
<JFo> heh
<JFo> my thoughts exactly
<ogra> apw, its a kernel prob
<JFo> it was the reason I had no issue removing that group subscribe
<apw> ogra, if its a kernel problem then it should be filed against the kernel
<apw> ogra, can you elucidate on the problem? as noone in the bug seems to be helping me
<ogra> apw, and if the new firewire stack fixes it i'D close it, else it stays open forever
<ogra> apw, its the permissins of the firewire device
<ogra> *permissions
<ogra> which i thought the new firewire stack fixes
<apw> as in the the unix permissions or something deeper
<ogra> unix permissions and something deeper :)
<apw> so it might be worth asking for testing on maverick as the stacks are switched
<ogra> the permissins are only set that way because its the only safe way
<ogra> (by design)
<apw> and if its a kernel problem it should have a kernel task so we can close that Fix Released on Maverick, and Won't Fix (you have a workaround) on Lucid
<ogra> i would ask the last three commenters if they use maverick
<ogra> and if so, close it
<apw> JFo, ok read the whole bug and it does seem to be a case of, old kernel stack has no sane permissions model, new stack does.  old stack therefore is prevents access without being root, new should not
<apw> therefore .... will add linux tasks for lucid and maverick and close this in maverick kernel side
<JFo> ok
<JFo> sounds god to me
<JFo> good*
<apw> and actually in lucid too, as we are not going to change the default there
<JFo> right
<JFo> since the new stack is Mav only yes?
<apw> will close that won't fix, but wth the appropriate comments about the workaround to switch the stack
<diwic> Out of curiousity, I run Lucid on one machine here but with the Maverick backport kernel, am I running 1) the old FW stack 2) the new FW stack 3) some weird combination
<JFo> diwic, the maverick backport kernel is not supported on desktpo ;)
<JFo> heh
<JFo> desktop*
<JFo> what is with my spelling to day?
<diwic> JFo, it does exist in the generic flavour though
<JFo> exist yes....:)
<diwic> JFo, and so far it has been working better than the Lucid one, graphics-wise
 * JFo picks on diwic 
<jk-> hey JFo
<JFo> heya jk- 
<jk-> JFo: saw your update on 584812; just waiting for feedback from Jerone..
 * JFo goes to look
<JFo> ah yeah
<JFo> wanted to get the guys to take a look at it too during the weekly chat
<JFo> would you rather I wait on that jk- ?
<jk-> apw knows about it, once it's been tested I'll forward the config change to k-t for review
<JFo> since I see that you have a test build that may take care of it
<JFo> coolness
<JFo> may just want to put on the hot list
<JFo> good deal :)
<apw> bug #584812
<ubot2> Launchpad bug 584812 in linux (Ubuntu Maverick) (and 4 other projects) "uinput kernel module is not loaded automatically (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/584812
 * apw has seen that yes
<JFo> :)
 * smb needs to run some errands. bb later
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<pgraner> tgardner, lag: call in 10...
<lag> pgraner: ack
<lag> pgraner: Mumble?
<pgraner> lag, yep
<JFo> pgraner, I completely forgot to schedule myself
<pgraner> JFo, dooh!
<JFo> heh
<tgardner> pgraner, ack
<pgraner> JFo, we can do it next week when your back
<JFo> k
<JFo> apw, you still around?
<apw> yep
<JFo> smb are you around?
<JFo> in the event that you are. would you have a look at bug 546091
<ubot2> Launchpad bug 546091 in linux (Ubuntu) "10.04 Installer doesn't properly detect 9240 MegaRaid SAS Controlers (affects: 8) (heat: 72)" [Undecided,New] https://launchpad.net/bugs/546091
<JFo> think that could be caused by an old driver?
<smb> JFo, Now yes
<JFo> heh
<ogasawara> JFo: around for much longer today?
<JFo> a bit yes :)
<JFo> want me to try to attend the meeting?
<ogasawara> JFo: nah, was hoping you could spam a small set of bugs for me
<JFo> I may be able to indeed :)
<ogasawara> JFo: which would then clear off one of your work items... "post CFT to lp bugs using an ubuntu/ driver"
<ogasawara> JFo: https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=rtl8192se
<JFo> interesting
<JFo> I don't remember that one
<JFo> but I'd be happy to
<ogasawara> JFo: In the most recent Maverick kernel I uploaded yesterday (linux-2.6.35-16.22) I'd updated rtl8192se
 * JFo worries he  missed subscribing to the BP
<JFo> ogasawara, cool
<ogasawara> JFo: so if you could just spam those bugs asking if they could test with the latest 26.35-16.22 kernel that'd be awesome
<JFo> will do
<JFo> what BP is that item in?
<JFo> misc?
<ogasawara> JFo: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-ubuntu-delta-review
<JFo> yep, I missed subscribing to that one
<JFo> fixed now
<JFo> thank you :)
<ogasawara> JFo: that last bug in that last might not be relevant, so you could maybe skip that one
<JFo> k
<smb> JFo, scanning through that bug sounds like they would need a completely updated driver, yes. I would say its would be a candidate for lbm but they need that for installation. tgardner, pgraner anyone of you got hw that uses the megaraid_sas driver?
<tgardner> smb, not me
<tgardner> smb, is this a regression, or just a new version of the card ?
<smb> tgardner, I would say a new version
<smb> yep
<smb> Three newer cards
<JFo> sm, thanks for looking
<tgardner> smb, I wonder if "we" are smart enough to build an ISO with the LTS backported kernel on it for testing. bjf?
 * smb really feels like sm today :)
<bjf> tgardner: "we" should be able to do that, yes
<tgardner> bjf, how is the alternate kernel selected? do you just replace the Lucid kernel?
<bjf> tgardner: yes
<bjf> tgardner: desktop is what i've been doing, not sure about server
<tgardner> bjf, smb: maybe we should get them to try the Maverick daily first in order to make sire its going to be a solution
<tgardner> sure*
<smb> tgardner, There is a comment about Maverick a2 or 3 working
<tgardner> smb, ok. then they are going to have to wait until we have a Lucid point release with the Maverick kernel as an option
 * tgardner goes to snatch some breakfast
<smb> Yeah, someone mentioned 9.10 drivers from the vendor. Have not followed that but could be an option too if they have something newer
<smb> hm probably not. looks a bit hackish
<tgardner> smb, it also won't solve their install problem, will it?
<JFo> ogasawara, spam complete
<JFo> smb :)
<ogasawara> JFo: awesome, thanks.  I'll mark it off the blueprint.
<JFo> k, thank you :)
<smb> tgardner, Only very sort of. Basically I think thy provide initrd and kernel plus modules for KArmic
<ogasawara> ##
<ogasawara> ## Kernel team meeting in one hour in #ubuntu-meeting
<ogasawara> ##
<smb> tgardner, The difference between maverick and lucid is just a mere 1100 lines. If we get the right person the right hw we can sru it by rule #5 :-P
<pgraner> smb, I don't have any hw for that
<smb> pgraner, ack, yeah its probably rather high end server stuff
<pgraner> smb, yea I'm more low rent lol
<smb> heh
<apw> smb, i wonder if they could make a USB stick with the updated kernel
<smb> apw, Well if the installation offers the maverick lts backport they should be fine
<apw> well ... no as they can't see the disk to install it ... right ?
<smb> Right, would require that kernel to be there for install... :/
<tgardner> apw, thats an interesting point
<apw> they'd need an image with that kernel actually on it, as a boot option
<tgardner> we'll have to ask cjwatson if thats an option on the alternate installer
<apw> might be on the DVD images for instance
<ogasawara> cnd: you've got a generic work item to "Work with Rafi and Stephane to import any post 2.6.35 multitouch driver code" is that still ongoing or can I mark it done?
<smb> apw, The only other solution would be some sort of override mechanism to pull in certain lbm packages from the cd or dvd. But I guess thats even more not implemented
<apw> presumably they could make a USB stick on another machine, and chroot into it, and install the updated kernel
<apw> so perhaps its a 'write a proceedure for it' problem ?
<apw> smb ^^
<smb> apw, Hm its probably the same or similar to making some of our test cds. 
<JFo> odd that the alternate CD worked but not the regular
<JFo> well, it may not be that odd
<JFo> hmm
<jjohansen> ogasawara: I've updated my work items let me know if I missed anything
<ogasawara> jjohansen: will do, thanks
<ogasawara> ##
<ogasawara> ## Kernel team meeting in 5 minutes in #ubuntu-meeting
<ogasawara> ##
<cnd> ogasawara, you can mark it done
<ogasawara> cnd: yep, thanks
<cnd> that work item became utouch :)
<cnd> its spawned way too many other work items...
 * tgardner lunches
 * jjohansen -> lunch
 * smb -> out
<bjf> ogasawara: thanks for handling the meeting, 15 minutes, nice!
<ogasawara> bjf: np, was short and sweet today.
<ogasawara> bjf: I sent you the mootbot bits, not sure if you really needed it or not
<bjf> ogasawara: thanks, don't use them but thanks anyways
 * ogasawara lunch
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-24 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jj-afk> back on in a bit
#ubuntu-kernel 2010-08-18
<vanhoof> kentb_out: \o/
<superm1> hey anyone around that can chat with me a little bit about fixing up lirc in the maverick tree?
<superm1> particularly what's there right now is going to oops left and right on 2.6.35, and after chatting with jarod wilson about, probably the best thing to do at this point is to rebase it on the stuff he's submitting for 2.6.36 at http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=summary and pull lirc 0.8.7ish userspace into maverick
<superm1> so mostly my question is how the best way to handle this is.  for the past few releases, lirc has lived in the ubuntu/ directory by hand injected tarballs.  would it be better to just stick with that model for now, and grab latest from his git and drop them in place with the intention that they get removed for ubuntu-n since they should be available without this hackery?
<superm1> or is there still value in trying to merge/cherry pick/rebase commits out of his tree, shuffle them around and keep all that history if the stuff would only be around for one more release
<apw> superm1, we've just taken tarballs from you in the past, so i don't think there is any value in doing anything else this time, especially if its coming in mainline in .36
 * smb waves to apw
 * apw waves
<RAOF> apw: I did see that radeon+GRUB2+graphics mode bug, but it looked like you and Colin were on it, so I wandered off to less well-tended bugs.  Also, I don't think *my* radeon system is affected, although I haven't tried particularly hard to prod the beast.
<apw> ahhh i think its fallen through the cracks
<RAOF> Also, in Prague the radeon systems that seemed to have problems got magically better once we killed vga16fb with fire.
<apw> RAOF, well thats good at least, that thing is sooooo old i am amazed it can even start
<apw> RAOF, i wonder if you would have any time to cast an eye over that radeon/grub2 thingy, as i am about to vacation
<RAOF> I shall see if I can reproduce on my local radeon.
<RAOF> I'm in a radeon bugfixing mood.
<apw> heh thanks man ...
<RAOF> apw: In return, would you kindly pass your wandering eye over bug #586325 and accept the lucid task for me?
<ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 57)" [Medium,Triaged] https://launchpad.net/bugs/586325
<apw> RAOF, ahh your cursor patch finally made it round the houses
<apw> nomination accepted, that sounds like a patch we'd consider for lucid, though its not tiny
<TeTeT> apw: awesome, our customer will be all excited
<apw> heh don't let them get tooo excited
<JFo> apw, it seems you were right with your Natty Narwhal naming
<apw> JFo, ?
<JFo> when we were discussing what the next release would be named in fun
<JFo> I think it was you that said something about natty narwhal
<apw> heh narwhal i may have got, i doubt i'd have gotten natty
<JFo> hmmm
<JFo> well, we were close anyway :)
<apw> heh ... at last natty is easy to type
<JFo> indeed
<JFo> for this natty new release
<JFo> apw, do you know if we have SRU plans for bug 586325?
<ubot2> Launchpad bug 586325 in linux (Ubuntu Lucid) (and 2 other projects) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 18)" [Undecided,Triaged] https://launchpad.net/bugs/586325
<JFo> I didn't see anything in the bug suggesting we were considering it
<JFo> but that doesn't mean we are not
 * abogani waves all!
<abogani> FYI I have updated -lowlatency kernel flavour in the git tree on Zinc if anyone could-would want review it.
<abogani> Thanks in advance for all!
<JFo> hiya abogani 
<lag> JFo: Are you in the UK?
<JFo> lag, yep
<JFo> in Oxford
<lag> JFo: I wondered why you were on the internet at some ungodly hour this morning :)
<JFo> heh
<JFo> sprinting with the QA folks for a community of practice meeting
<JFo> for the week
<lag> Isn't that like doing community service at an old folks home or special school? 
<JFo> hah
<lag> :)
<luftikuss> What is "kernel mode setting" generally? https://wiki.ubuntu.com/X/KernelModeSetting: "X/KernelModeSetting: Kernel mode-setting (KMS) shifts responsibility for selecting and setting up the graphics mode from X.org to the kernel." I don't want to know what it does but rather I'd like to know what KMS is. (It occasionally produces error messages on my Ubuntu 10.04.1 computer.)
<JFo> luftikuss, it is the changing of the screen resolution of your machine
<JFo> it is handled by the kernel now versus X
<luftikuss> JFo: Thank you for your information.
<JFo> luftikuss, my pleasure :)
<luftikuss> JFo: If the X server has crashed: Is there all I can do to analyze the cause to access the crashed computer via ssh and read the /var/log/Xor.0.log? 
<luftikuss> s/Xor/Xorg/
<JFo> luftikuss, I'm afraid my X knowledge is rather limited.
<JFo> this may be a better resource: https://wiki.ubuntu.com/X/Debugging
<JFo> have you taken a look there?
 * amitk just compiled a 12Mb kernel! \o/
<amitk> sed -i -e's/=m/=y/' .config
<apw> smb, is master.kernel.org up for you ?
<smb> apw, yep seems ok
<apw> smb, hrm, seems down for me
<smb> apw, I see other people there, too. Must be some weird routing issue
<apw> smb, yeah must be ... can get in there via frylock
<smb> apw, local credentials busted?
<luftikuss> JFo: What is a "paint-by-numbers fashion" in https://wiki.ubuntu.com/X/Debugging?
<apw> smb, its a network level connection timed out
<smb> apw, Weird indeed. Maybe the gov is upon you ;-P
<apw> heh maybe indeed
<luftikuss> JFo: ~$ dict paint-by-numbers
<luftikuss> No definitions found for "paint-by-numbers"
<smb> malen nach Zahlen
<apw> luftikuss, to paint by numbers is a phrase meaning 'the easy way' it comes from books with black and white outline pictures with the number of the colour to use to fill each box
<luftikuss> smb, apw Thank you for your help.
<JFo> luftikuss, apologies, I was away at lunch.
<tgardner> JFo, being "out to lunch" has its own connotations.
<JFo> tgardner, :)
<apw> smb, does that .de translation have the same meaning as in english
<JFo> in that case, I am always "out to lunch"
<smb> apw, In the literal sense. Its the name for that painting style
<apw> but you wouldn't use it to mean 'easy' generally
<smb> I don't think commonly. You might probably say it is like paining by numbers
<apw> smb, heh ...
<apw> confirmed i've triggered some counter-measure ... by logging in successfully ... changed IP address at home and its all fixed
<diwic> *paining* by numbers, is that a freudian slip?
<smb> apw, You must have been bad.
<apw> probabally logged in 100 times today
<smb> diwic, Must be. Or incompetence at the keyboard
<jdub> hey there
<jdub> have you guys been hearing about lucid block layer issues under kvm and xen?
<jdub> https://bugs.launchpad.net/bugs/618529
<jdub> ^ i filed that earlier
<ubot2> Ubuntu bug 618529 in linux (Ubuntu) "kernel call traces from blk-core.c (affects: 1) (heat: 6)" [Undecided,New]
<jdub> there's a link to a debian bug
<jdub> i'm having regular freezes on my linode vm
<jdub> and it looks like there are references to this being fixed around the place
<smb> jdub, Depends a bit whether it is real freeze or just slow as hell. If things move on after a while (possibly a long while) it probably is the general problem with writeback
<jdub> hmm
<jdub> ah, well, i don't mean kernel freeze
<jdub> just to be clear
<jdub> disk, block or vm or something sure
<jdub> i can type 'ps afx' over ssh, for instance, but it never* returns ;-)
<jdub> * (may not have tested this to the ultimate conclusion of "never")
<smb> Right, so in that case its likely that writeback (block layer)  has some issues. We are working on that
<jdub> ah, known probs
<jdub> lovely
<jdub> particularly on xen/kvm?
<smb> Yeah, just not that simple to come by (there is a set of 14 patches or so). No in general on higher io loads its seems and in particular when unmounting
<smb> I saw the same kind of messages just yesterday while compiling kernels
<jdub> smb: is it a lucid-worthy issue?
<smb> jdub, Definitely. There are some tests I want to do which are next on my todo list. And then moving forward. But it should get fixed sooner than later.
<jdub> sweet! thanks smb
<jdub> in the mean time, i will keep an eye on my poor, suffering linde... and perhaps not post more big videos :-)
<cooloney> quit
<smb> There might be some test kernel mentioned in bug 585092. Though they might be slightly outdated or rather suited for systems not needing dkms packages (like binary gf drivers)
<ubot2> Launchpad bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 1) (heat: 65)" [Medium,Fix released] https://launchpad.net/bugs/585092
<gzerphey> any reason I cant load backports jaunty with the 2.6.32-24-generic kernel?
<tgardner> gzerphey, many, many reasons, not the least of which is "it won't work"
<gzerphey> kind of what i thought
<gzerphey> the reason i ask is that used to be a fix for the wireless disconnect problem with 2.6.x kernels but now im not sure what to do
<tgardner> gzerphey, try a Lucid compat-wireless package?
<smb> tgardner, In Jaunty?
<apw> he has a lucid kernel no ?
<gzerphey> yes im in lucid
<tgardner> I guess thats why I assumed Lucid
<smb> Ah ok. thought I read jaunty
<gzerphey> i have tried 32-21 and 32-23 with little success
<tgardner> gzerphey, have you tried linux-backports-modules-wireless-lucid-generic ?
<gzerphey> yes
<gzerphey> that loaded 32-24
<gzerphey> also no help
<gzerphey> are you guys familiar with the problem i am running into.... the wireless randomly disconnects and I have to disconnect and reconnect to get it operational again.  this seems to happen under load
<superm1> apw, okay i'll get a patch together that does it that way then soon, thanks
<JFo> bjf, do we still have testing images supposed to be building daily?
<JFo> or whenever?
<bjf> JFo: that's the theory though i don't check on them every day
<JFo> looks like they last built on the 5th
<bjf> JFo: i accept patches
<JFo> bjf :)
<JFo> not sure what is broken, but I'll have a look later. just wanted to make sure we actually expected them to be building regularly
<bjf> JFo: i've added it to my stack for today
<JFo> k, or if you like I can look at it next week
<JFo> I do need to get my knowledge together on the testing images anyway
<bjf> JFo: whoever gets to it first
<JFo> k :)
 * smb -> out
<apw> ogasawara, ok i've started the sync for the ports meta into our tree
<apw> generally we try and keep a vagly recent copy of that in our ports branch, so that it doesn't get lost
<apw> obviously he is maintaining that currently
<ogasawara> apw: sweet, thanks
<bjf> JFo: i think i fixed the daily iso image building
<bjf> JFo: am testing now
<JFo> sweet!
<bjf> JFo: but is anyone using them?
<JFo> bjf, I am planning on testing them, but I keep getting sidetracked
<JFo> I want to make sure we are building them well before I start giving them away
 * tgardner knows its lunchtime somewhere.
<kees> apw: should "linux-linaro" be added to https://wiki.ubuntu.com/Kernel/Dev/ABIPackages ?
<apw> kees, probabally, though i've never seen it before :) 
<tgardner> apw, linux-linaro is a 1000 series, the most recent upload was 2.6.35-1002.6
 * jjohansen -> lunch
<apw> tgardner, do we have a meta package for l
<apw> linaro ?
<tgardner> apw, we do, its a branch in the maverick meta repo
<tgardner> apw, I'd have thought the k-t list traffic would have twigged you to it
<apw> tgardner, i thought it was there, just too lazy to confirm
<bjf> tgardner: did i miss my time?
<tgardner> bjf, we;re in mumble  just qwaiting
<apw> pgraner, have you dropped me that goals email ?
<pgraner> apw, nope in 5 mins or so
<apw> pgraner, ok i'll go grab dinner
<jjohansen> rebooting
#ubuntu-kernel 2010-08-19
<jk-> eep, first victim of yama/ptrace_scope changes: wine will no longer run Rosetta Stone
<jk-> .. not that it ran that well in the first place, but would indicate that wine uses ptrace() on non-child processes
<jjohansen> jk-: you can turn yama off
<jk-> yep
<amitk> cooloney: did you look at the patches that Tony posted on linux-omap for SMP kernel on UP?
<amitk> I asked him to post patches so you or someone else can test it
<cooloney> amitk: yeah, man
<cooloney> amitk: i tested rmk's version 
<cooloney> and tony posted a fixing just now
<cooloney> i am going to testing that on my board
<amitk> cool
<cooloney> amitk: so we a close to boot smp kernel on beagle, i think.
<amitk> cooloney: hopefully :)
<cooloney> amitk: but the patch changes several important low level assemble line code. 
<cooloney> need more testing and review
<amitk> cooloney: Tony said that he doesn't think we need to rewrite locking primitives during runtime like is done on x86
<cooloney> amitk: no sure about that. spin_lock version is different in smp and up, i think.
<sconklin> not traffic shaping, just saturatign my uplink
<sconklin> the tests that failed were obviously ones that were not for ext4, but were not correctly excluded from the tests
<smb> Hm, ok. I think I had at least one about aio but those failed before and after.
 * smb goes to reboot the test machine
<JFo> is the -rt kernel being added to main that anyone knows of?
<JFo> rather -lowlatency and -preempt
<JFo> I am being asked about them
<JFo> apw or tgardner ^^?
<tgardner> JFo, preempt is an official flavour for Lucid, not for Maverick
<JFo> ah, I see
<JFo> anything for the -lowlatency?
<tgardner> JFo, not in maverick
<tgardner> nor lucid
<JFo> tgardner, thank you
<JFo> tgardner, is there any rationale for not including them?
<JFo> I have been asked that specifically
<tgardner> the -rt guys are providing a kernel AFAIK, so it was duplicated functionality.
<JFo> cool, thanks again tgardner 
<sabdfl> ps ax is hanging over here, known issue? kernel or elsewhere?
<sabdfl> fwiw it gets to  1751 ?        S      0:00 udisks-daemon: polling /dev/sr0
<kees> sabdfl: what does "strace ps ax" show it's stuck on?
<sabdfl> read(6, "Name:\tchromium-browse\nState:\tD ("..., 1023) = 786
<sabdfl> close(6)                                = 0
<sabdfl> open("/proc/1898/cmdline", O_RDONLY)    = 6
<sabdfl> read(6, 
<kees> ew
<tgardner> sabdfl, maverick?
<sabdfl> tgardner: very :-)
<tgardner> cat /proc/version_signature
<sabdfl> Ubuntu 2.6.35-16.22-generic 2.6.35.2
<sabdfl>  ~/ $ ls /lib/modules/2.6.35-16-generic/updates/dkms 
<sabdfl> hid.ko	hid-magicmouse.ko  vboxdrv.ko  vboxnetadp.ko  vboxnetflt.ko
<tgardner> sabdfl, lots of stable fixes since then. I hate to give you the runaround, but can you install just the -proposed kernel and try again?
<sabdfl> sure, url?
<tgardner> one sec
<sabdfl> didn't realise we had -proposed on maverick
<tgardner> sabdfl, doh, I was thinking Lucid. never mind.
<sabdfl> :-)
<sabdfl> i think about lucid often, too :-) best release EVAR
<tgardner> though we do have stable updates in the pipe for Maverick
<sabdfl> how's .35 treating us?
<tgardner> not too bad, but there is a known mm regression in the version you are running. I wonder if thats it
<tgardner> ogasawara should be releasing an update with a couple of days
<kees> is it always chromium it blocks on, or is it at random?
<tgardner> kees, 'mm: fix page table unmap for stack guard page properly' is what I suspect
<kees> tgardner: what sha is that?
<kees> tgardner: I think we have it in the -security kernels, but I wanted to double-check
<tgardner> in the maverick repo its 6106dafae6d0ff50c82bb544b3b999562238504b
<mjg59> sabdfl: While hung, writing W to /proc/sysrq-trigger should give you the in-kernel backtrace for the blocked task
<tgardner> sabdfl, you could also reboot to Ubuntu-2.6.35-14.20. Thats based on 2.6.35 _before_ any stable updates (which actually destabilized things a bit)
<kees> yup
<sabdfl> mjg59: hello there! nice to see you again
<sabdfl> so, echo W > /proc/sysrq-trigger ?
<mjg59> Yeah, as root
<tgardner> echo W | sudo tee /proc/sysrq-trigger
<sabdfl> tgardner: still have it around, iirc, so yes can roll back
<tgardner> sabdfl, remember you have to hold the shift key just prior to grub getting control or you'lll miss the grub menu
<sabdfl> so, that's put stuff in dmesg?
<mjg59> Yup
<sabdfl> lots of blech at http://pastebin.ubuntu.com/480605/
<mjg59> sabdfl: Hm. Sure you did w? And ps is still blocked in read?
<tgardner> mjg59, anon_vma_prepare, wasn't this what Linus was seeing?
<mjg59> Yeah, looks like something's very unhappy there
 * jjohansen -> lunch
<tgardner> I'm pretty sure thats the stack guard regression
<sabdfl> mjg59: just tried again, ps ax in one terminal tab, and the echo W magic in another
<sabdfl> ps doesn't get unblocked
<mjg59> Yeah, ps is pretty solidly dead at that point
<mjg59> One of those scheduling while atomic errors probably left a lock held
<tgardner> sabdfl, I think your best bet for now is to use the older kernel until ogasawara get the next stable update uploaded.
<sabdfl> okdokey
<ogasawara> sabdfl: hoping to upload this afternoon actually.  just have a few more patches I wanted to review and possibly apply.
<sabdfl> other than the vbox bits, which i am not using so doubt they are active, i'm on standard bits with dell m1330
<sabdfl> so i wouldn't be surprised if others see the same thing
<sabdfl> thanks leanne
<ogasawara> sabdfl: I think I've got a test kernel with a fix for that bug 480605, just a sec
<ubot2> Launchpad bug 480605 in telepathy-haze (Ubuntu) (and 2 other projects) "Repeated subscription request from same user (affects: 12) (dups: 2) (heat: 78)" [Medium,Triaged] https://launchpad.net/bugs/480605
<ogasawara> bah, not bug, the pastebin
<sabdfl> ok, will let you guys know if the next update fixes it
<ogasawara> sabdfl: bug 618846, http://people.canonical.com/~ogasawara/lp618846/
<ubot2> Launchpad bug 618846 in linux (Ubuntu) "Kernel 2.6.35.2 reports "scheduling while atomic" (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/618846
<sabdfl> will reboot to prior kernel. thanks for the help, hope the report was helpful, nice to see you mjg59
 * ogasawara drops to grab lunch, back in an hour
<joshhunt> can someone provide a pointer to the differences between ubuntu server kernel and desktop kernel? i have found this: https://help.ubuntu.com/10.04/serverguide/C/preparing-to-install.html but was wondering if there are any other differences
<tgardner> joshhunt, there are no source code differences. the only differences are in some of the config options.
<joshhunt> tgardner, ok thanks. that's what i suspected, but wasn't sure.
<joshhunt> tgardner, is there a place where i can download the kernels manually. instead of going through apt, etc?
<kees> joshhunt: I tend to do it through Launchpad. https://edge.launchpad.net/ubuntu/+source/linux
#ubuntu-kernel 2010-08-20
<bjf[afk]> ogasawara: still around?
<ogasawara> bjf: yep
<bjf> i just started two builds before noticing that we will probably run out of disk space on tangerine
<bjf> i was wondering how to kill builds started with the build scripts
<ogasawara> bjf: yeek, lemme go clear out some stuff
<ogasawara> bjf: my builds have finished
<ogasawara> bjf: I don't think it's scripted to kill the builds, so I usually just run screen -ls, then reattach to the session I want to kill and manually kill it
<bjf> ack
<bjf> ogasawara: killed both of mine
<ogasawara> bjf: I've cleaned out my trees
<bjf> ogasawara: will start them again some time later (will check disk space first)
<bjf> ogasawara: ack
<ogasawara> bjf[afk]: should be about 44G free now, not sure who else is consuming space
<marcosroriz> Hi guys
<marcosroriz> Can anyone help me with my bug --> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/571422
<ubot2> Launchpad bug 571422 in linux (Ubuntu) "[LUCID] suspend/resume issue on Dell Inspiron 1464/1564/1764 (affects: 10) (heat: 52)" [Undecided,Confirmed]
<marcosroriz> ?
<bbordwell> Hey everyone I am just noticing all the scheduling while atomic bugs popping up since the -16 kernel update in maverick and it looks like they are caused by this upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=16588  the regression was caused by the fix to the x exploit. Would anyone object to me setting one of the reports as master by linking the upstream bug report and then marking all the others as dups?
<ubot2> bugzilla.kernel.org bug 16588 in Other "Regression introduced in 2.6.35.2 causes freezing, crashing, oopsing" [Normal,Resolved: code_fix]
<bbordwell> Well I am pretty confident this is the right course of action so I will go ahead and do so. Hopefully no one gets mad at me :)
<sconklin-gone> bbordwell: unless I'm mistaken there's already a fix for that in the repo, which means that tomorrow's daily will have it. So this should be a dhort-lived bug.
<bbordwell> sconklin-gone, should be since its already fixed upstream. Just want to clean up after the mess its leaving on lp :)
<bbordwell> Here is the master I made: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/620810
<ubot2> Launchpad bug 620810 in linux (Ubuntu) (and 1 other project) "[MASTER] BUG: scheduling while atomic (affects: 7) (dups: 7) (heat: 62)" [Medium,Triaged]
<sconklin-gone> looks fine to me~
<sconklin-gone> !
<ikepanhc> lag: https://wiki.ubuntu.com/Kernel/Dev/MultipleISOBootUSBKey
<lag> Well done ikepanhc - thank you
<ikepanhc> :)
<jdstrand> smb: hi! so it looks like the maverick rebase to 2.6.35.2 grabbed the CVE-2010-2240 fixes (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35.2), I don't see that CVE-2010-2803 or CVE-2010-2959 are fixed in maverick
<ubot2> jdstrand: ** 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-2240)
<ubot2> jdstrand: ** 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-2803)
<ubot2> jdstrand: ** 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-2959)
<jdstrand> thanks ubot2
<jdstrand> smb: I've updated the tracker for CVE-2010-2240 just now
<ubot2> jdstrand: ** 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-2240)
<jdstrand> ubot2: dude, stop
<ubot2> Factoid 'dude, stop' not found
<smb> jdstrand, Ok. Don't even try to convince a bot. :)
<jdstrand> :)
<smb> jdstrand, Yes, I think Leann got them pulled. Though I have not been looking whether those were all of them
<jdstrand> smb: well, the changelog.Debian.gz file didn't seem to have it either
<jdstrand> (2.6.35-16.22)
<smb> Somehow I believe it was only one to fix another issue... tgardner are you more up to date in Maverick than I am
<smb> ?
<tgardner> smb, I asked ogasawara to upload yesterday to fix the mm regression that came via stable. she might not have gotten to the CVEs just yet
<smb> OK, right so that was just incidentally one of the cve patches
<smb> jdstrand, ^ (but give me a sec and I look into the repo to be sure)
<jdstrand> smb: I appreciate it
<smb> jdstrand, I think there is one of the fixups for 2240 missing, so 4/5 complete there (the missing one properly fixes the error case properly). So the main issue might be ok
 * smb wonders how many properlies he manages to put into one sentence
<jdstrand> hehe
<jdstrand> smb: so, can you follow up with Leann when she comes online or shall I?
 * jdstrand isn't sure based on this conversation who should be fixing maverick
<tgardner> jdstrand, we assure you, its Leann
<smb> jdstrand, Maybe you. Depending on when she gets up it might be beer 'o clock here
<jdstrand> hehe
<jdstrand> ok, I'll just follow up with her directly
<jdstrand> thanks guys! :)
<smb> No problem. We love OPPs :)
<diwic> Is there a wiki guide for doing git bisect? I e if somebody says it worked in version x but not in version y and is willing to take the time to do a git bisect
<tgardner> diwic, there is plenty of help in the command itself, git bisect --help
<diwic> tgardner, right, I'm just looking for a stock reply / wiki link to point people to
<diwic> tgardner, which also includes which tree to start with
<tgardner> diwic, I'm thinking if they can't figure it out from the help notes, then they probably are gonna need more hand holding then the wiki provides
<diwic> tgardner, I'd like to learn how to do git bisecting then, so I can hold people in their hands later
<tgardner> diwic, no better way to learn then to just do it
<diwic> tgardner, fair enough, so to get started I'd probably follow Kernel/BuildYourOwnKernel, which will create a deb, which I will install, and reboot, and that's basically one git bisect iteration
<abogani> diwic, I don't suggest you to build a deb package for a git bisect section.
<diwic> abogani, but instead...?
<abogani> diwic, IMHO Upstream method is more easy for that.
<diwic> abogani, so assume I've compiled an upstream kernel. How do install it? "make install" and then "sudo grub-install"?
<abogani> sudo make modules_install, copy bzImage into /boot with an appropriate name, create initramfs with mkinitramfs, reboot and edit GRUB command line for boot the just compiled kernel. 
<diwic> abogani, now that is something that should be in a wiki page
<JFo> ogasawara, the current list of those is here: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=gfxpayload%3Dkeep
<jdstrand> ogasawara: hi! smb and tgardner directed me to you regarding the recent CVE fixes for maverick
<jdstrand> ogasawara: from backscroll:
<jdstrand> 08:03 < jdstrand> smb: hi! so it looks like the maverick rebase to 2.6.35.2 grabbed the CVE-2010-2240 fixes (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35.2), I don't see that CVE-2010-2803 or CVE-2010-2959 are fixed in maverick
<ubot2> jdstrand: ** 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-2240)
<ubot2> jdstrand: ** 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-2803)
<ubot2> jdstrand: ** 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-2959)
<jdstrand> 08:12 < smb> jdstrand, I think there is one of the fixups for 2240 missing, so 4/5 complete there (the missing one properly fixes the error case properly). So the main issue might be ok
<ogasawara> jdstrand: getting the remaining maverick CVE's are also on my todo list this morning
<jdstrand> ogasawara: would you mind pulling what's needed to get maverick patched?
<jdstrand> ogasawara: thanks! :)
<jdstrand> ogasawara: you seem busy this morning ;)
<ogasawara> jdstrand: heh, yep :)
<ogasawara> jdstrand: I'd have shoved the CVE fixes in yesterday's upload but the 2.6.35.2 regression we were seeing needed to go up asap
<jdstrand> ogasawara: that's cool-- based on what smb said about the rebase, the CVE everyone is talking about should be fixed
<jdstrand> ogasawara: (well, fixed enough to not be a vuln)
<smb> ogasawara, Just a note that the regression patch was part of one of the cves, so now there is only one of the set missing
<ogasawara> smb: cool
<kees> frankly, I think the CAN bug is more pressing. :)
<kees> anyway, s'all good
 * smb thinks he now has re-uploaded everything in need and that it is now past boc
<tgardner> sconklin, bjf: whats the story on 2.6.32.[18,19] ? there looks to be some serious goodness for intel wireless, ext4 deadlock, btrfs, etc.
<bjf> tgardner: i've got the patches applied to my public repo, i've done test builds, just waiting review by smb and sconklin
<bjf> tgardner: looks like btrfs was re-written in that patchset :-)
<smb> I'll do a quick review Monday. We should get it then applied that day or Tuesday
<bjf> tgardner: sconklin is out today as well
<tgardner> ah, ok
<tgardner> bjf, whats your branch? I'll run some tests
<bjf> tgardner: sru-18+19
<bjf> it doesn't have smb's writeback patches though
<bjf> tgardner: ^
<tgardner> rebases are us
<bjf> tgardner: was just about to fix that
<smb> bjf, I am now at 6G. Would that be good enough?
<tgardner> for those who don't know bjf's whole name, his repo is at git://kernel.ubuntu.com/bradf/ubuntu-lucid
<bjf> smb, sure
<bjf> smb, and thanks
<smb> NP, need to remember to clean up after big build tests
<tgardner> don't forget we have  emerald as well
<kamal> I'm curious why Lucid jumped from #39 to #41... why was there was no 2.6.32-24.40 ?
<smb> Stuck in proposed and overrun by security
<smb> kamal, ^
<kamal> smb: got it, thanks
 * smb -> out (really)
<bjf> tgardner: the branch has been rebased
<tgardner> bjf, lemme know when you've finisihed your rebase
<tgardner> :)
<bjf> tgardner: i'll go spin some test builds and make them available
<tgardner> I'll light up my big honking server and have -generic done in 15 minutes.
 * bjf notes the glow in the east even in the bright morning light
<cnd> jjohansen, how sure are you that the load avg patch is incorrect for Xen machines?
<jjohansen> 100%
<cnd> every machine's load avg went up with the fix in
<cnd> jjohansen, can you explain in more detail what's wrong?
<jjohansen> cnd: well in the Lucid case the kernel isn't tickless
<cnd> the patch doesn't add in any load that isn't real
<jjohansen> it really does
<cnd> how?
<jjohansen> I can simulate loads of 2 and 3 on an idle machine
<cnd> how do you do that?
<jjohansen> cnd: I'm still poking at that, but it is interacting with the Xen patches in a bad way
<cnd> it's worth noting that the patch that went upstream was different, but with the same semantics
<cnd> you can try that patch out
<jjohansen> cnd: start up an ec2 instance, launch some applications to idle (they aren't doing anything) and that is it
<jjohansen> cnd: did, it works better on Lucid
<cnd> jjohansen, even though the applications are idle, the machine is still doing stuff
<jjohansen> but reverting your patch is just as easy
<jjohansen> cnd: yes but its not doing stuff to the point of maxing out each cpu
<cnd> so you're saying you are actually seeing load of 2 or 3 (not 0.02 or 0.03) when idle?
<jjohansen> if I take and revert you patch, and apply upstream the problem is fixed on Lucid
<cnd> and you've double checked with top that nothing is running?
<jjohansen> yes
<jjohansen> yes
<jjohansen> I have ftraced, run different loads,
<jjohansen> run tons of different kernels
<cnd> it just seems really odd to me
<jjohansen> yeah it is
<cnd> cause I don't understand how the code could be doing that
<jjohansen> right, well I am still working on that one
<cnd> are you saying you've taken the upstream fix for this issue and it works correctly?
<jjohansen> yes
<cnd> ok, in that case I have no real qualms myself
<jjohansen> well sort of
<jjohansen> it works for Lucid but not Maverick
<cnd> I just saw the revert on kernel-team without the proposed patch from upstream
<jjohansen> right
<jjohansen> no point applying the upstream patch as it actually does nothing for Xen
<cnd> ok, I'll let you continue sorting through the issues then
<jjohansen> if you fallow it through, there are if defs for non-tickless kernels
<cnd> oh, I guess it's a different branch for ec2
<jjohansen> yes, only ec2
<jjohansen> I need to poke at it more for Maverick, as that is a different story
<jjohansen> in Maverick the upstream patch is there, the kernel is tickless, and we see the problems again
 * jjohansen -> lunch
<DrGrov> What is the issue with the new kernel? It kind of gives a lot of kernel panic once in a while, not every rebooting but every 3rd or so. The 10.04 stock kernel did work a lot better.
<DrGrov> No help then, nevermind. 
<kees> ogasawara: is it possible to get the linaro kernel patches into the non-linaro arm kernel builds?
<tgardner> kees, you mean ti-omap in Maverickl?
<kees> tgardner: honestly, I'm not sure. I've still got the giant list from Lucid in my head
 * kees checks ABIpackages....
<tgardner> kees, we've only one external ARM branch for maverick right now.
<kees> tgardner: yeah, looks like it.
<kees> tgardner: and the internal ARM build that is part of "linux", right?
<tgardner> kees, yep, same source code
<kees> I mean, ultimately, I know the linaro stuff is going upstream
<kees> tgardner: wait, which is the same?
<tgardner> kees, I meant that the "internal" ARM branch is from the same source code as x86/x86_64
<kees> right
<tgardner> you know, ther normal stuff
<kees> so, I guess I'm curious if we can get some of the linaro patches into both "linux" and "linux-ti-omap4"
<kees> specfically, npitre's ASLR
<tgardner> I guess that depends on how intrusive they are.
<tgardner> hmm, what is ASLR ?
<kees> address space layout randomization
<tgardner> ah
<kees> tgardner: I'll ask npitre if he has time to prepare a diff. I know he has plans to upstream it, so it should be the same work.
<tgardner> do you have a reference in his tree? we can certainly take a look.
<kees> tgardner: 
<kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=df0698be14c6683606d5df2d83e3ae40f85ed0d9
<kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=c743f38013aeff58ef6252601e397b5ba281c633
<kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=cc92c28b2db5b406657ecc05235d4ca4e222ae34
<kees> http://git.linaro.org/gitweb?p=linaro/linux-linaro.git;a=commitdiff;h=990cb8acf23cab19a2930f1ed5e7dc108f89079b
<kees> and one more is coming
<tgardner> kees, those don't look too bad.
<tgardner> its one of those "it either works, or it doesn't" kind of patch sets
<kees> well, true for stack protector, and mostly true for ASLR, but there have been subtle issues in the past with ASLR. However, at this point, I think I've got a good enough regression testing suite that the corner-case collisions are detected. (and currently this passes with the linaro kernel)
<tgardner> kees, well, float 'em on the list and see what folks think
<kees> tgardner: okay, I'll wait for npitre's last commit and I'll send 'em.
<tgardner> kees, EOD for me. see you Monday
<Kano> hi, when will be 2.6.35.3 mainline be ready
<kees> ogasawara: is the magic for arm cross compilation on the build resources documented? all I can find on the wiki is amitk's blog post
<ogasawara> kees:  I want to say yes, are you using the current kteam-tools/buildscripts ?
<ogasawara> kees: lemme try to find the doc, but it's pretty much the same, for ex ./build-prep --dist maverick tangerine-armel
<kees> ogasawara: I can be; I have a local copy of that you gave me a while bakc.
<kees> ogasawara: okay, lemme, going afk for a bit.
<ogasawara> kees: https://wiki.ubuntu.com/Kernel/Dev/KernelBuildScripts
<ogasawara> kees: but it doesn't mention the arm builds :(
<bjf> kees: there's a very simple way to do it on tangerine
<bjf> kees: schroot -c maverick-armel;fdr clean; fdr binary-<flavour>
<bjf> cnd: i have build images of my sru-18+19 at http://kernel.ubuntu.com/~bradf/sru-18+19/
<cnd> bjf, cool
<cnd> hopefully I can find some time to check it out
<syte> Hi, I've tried for the first time to compile my own kernel (2.6.35.2). I've used my current kernel's configuration settings, and then applied "make oldconfig". I complied with "make && make install_modules", and then finally installed with make install. When I tried to boot up my new kernel, I got the error "Couldn't mount because of unsupported optional features (240)." For some reason it was trying to mount ext2 and ext3, when i
<syte> t should've been mounting ext4
<kees> bjf[afk]: but that "native" via emulation, right? isn't it pretty slow?
<bjf[afk]> kees: it's not bad
<kees> okay, cool. I'll give it a shot.
<bjf[afk]> kees: i don't build arm much anymore so i've kind of lost my frame of reference
#ubuntu-kernel 2010-08-21
<Kano> http://packages.debian.org/squeeze/all/firmware-realtek/filelist
<Kano> those files should be added to the linux firmware package
<bjf[afk]> kano, send email to the ubuntu kernel team mailing list
<Kano> there are already bug reports...
<bjf> Kano: then i don't understand why you post a url and a request for files to be added in the irc channel
<Kano> because maybe you dont know where to get those files
<bjf> kamal: then that information should be added to the relevant bugs
<bjf> Kano: ^
<lucidfox> How are patch sets managed in the Ubuntu kernel? I want to try reverting an upstream commit
<andrew_708476> Is anyone in here thats good with Ubuntu
#ubuntu-kernel 2010-08-22
<Guest21386>  hi I have question related to metacity crashing - I have downloaded a latest build kernel, and I want to know how to use - having already run sudo dpkg -i *.deb
<Guest21386> sudo add-apt-repository ppa:kernel-ppa/pre-proposed    -- just tried this and still see issues so want to try 2.6.36rc
<Guest21386> hi when is 2.6.36 due ?
<andrew_708476> Hey I have a problem I cant seem to be able to remove this Anti Virus for my Ubuntu system can someone help me please
<azop> gue: Maverick (10.10) is going to use 2.6.35 not .36
#ubuntu-kernel 2011-08-15
<Laibsch> ping apw
<jk-> Laibsch: he's probably asleep
<Laibsch> jk-: thanks.  I figured as much.  He is in an American timezone, isn't he?  That would mean we are at complete opposite timezones.  I thought I'd ping him and stick around.
<jk-> Laibsch: nope, GMT.
<jk-> so your evening should be fine.
<Laibsch> Oh, that's good.  Then I hope to have a chance to catch him later in the evening.
<Laibsch> yes, thank you.
<jk-> anything we can help you with though?
<Laibsch> We had talked about a particular issue I had with an encrypted LVM and incorrect initramfs being created by update-initramfs. After several months I now figured out what the issue was.  I believe something is buggy, but wanted to ask him if he agrees.
<jk-> right, ok.
<Laibsch> Let me dig up the answer ticket
<Laibsch> https://answers.launchpad.net/ubuntu/+source/initramfs-tools/+question/154973 The answer to that was that apparently during the upgrade (or manually, don't remember) fstab was changed to mount root via UUID. That seems to fail, addressing via /dev/mapper/$ID works now.
<Laibsch> I want to see if that answer ticket should be converted to a bug ticket against the kernel
<Laibsch> or update-initramfs
<Laibsch> jk-: what do you think?
<jk-> well, the kernel doesn't deal with UUIDs, so doesn't sound like a kernel issue.
<jk-> I'm curious why referencing by UUID fails though
<Laibsch> yes, you are right, not a kernel issue.
<Laibsch> yes, me too, I am curious about that.  Figuring out the scripts was difficult enough as it is.  I was more or less walking through the scripts, guessing what happened and playing around.  Educated guessing, more or less. So, I can't really say what's going on.
<Laibsch> Some of the if-statement resolved differently in the UUID case, I can say that much.  I inserted a couple of echo statements in the scripts for debug purposes and to see what code actually was and wasn't called.
<cjwatson> lool,jcrigby: FYI, I'm disabling the d-i armel/linaro-vexpress build until bug 826021 gets fixed
<ubot2> Launchpad bug 826021 in linux-linaro-vexpress "Please re-enable crypto-modules udeb" [High,New] https://launchpad.net/bugs/826021
 * ogasawara back in 20
<apw> tgardner, did you ever play with the 200line patch cgroup thing?  do you know how to tell if its doing anything?
<tgardner> apw, feeling dumb. what cgroup patch ?
<ohsix> the lkml post had the token load, make -jwhatever in a terminal while doing other work
<tgardner> apw, gonna be in and out for awhile. I'm bisecting a Lucid 2.6.32-34 regression
<txomon> hello, I have a big problem with my computer, it crashes easily, and its all about networking. I think this is a kernel problem, as when I kill all the graphic sesions, the computer gets COMPLETELY blocked
<txomon> when plug in a network wire (RJ45)
<txomon> sforshee, can you help me with this?
<apw> txomon, it would be helpful to know which release you are running and which kernel version, plus which network card, and what the ubuntu bug# is
<txomon> the last
<txomon> I will fill now at the moment the bug
<txomon> but I can't fill it as I am using gnome3
<apw> so i assume you mean oneiric there
<txomon> 2.6.38-10-generic
<txomon> where?
<apw> ok so not the latest anywhere then
<apw> as thats neither teh latest kernel nor the latest series
<txomon> im in x64
<txomon> there are no more updates if I do "apt-get update"
<txomon> apw, do you want me to compile from 0 the last release?
<apw> txomon, you probabally could enable -proposed and see if that changes anything
<txomon> apw where?
<txomon> apw, where?
<apw> https://wiki.ubuntu.com/Testing/EnableProposed
<txomon> apw, done, im going to reboot
<txomon> apw, Linux javier-PB-ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
<txomon> there is no more updates of the linux kernel
<apw>      linux | 2.6.38-11.48 | natty-proposed | source
<apw> according to the archive there is
<txomon> so how do I get it?
<apw> normally adding -proposed, apt-get update, apt-get dist-upgrade gets everything
<txomon> now yes
<Sarvatt> ogasawara: thanks a ton for doing ubuntu-p.git this early, made drm-intel-fixes based kernels a million times easier to build :P
<apw> Sarvatt, we do normally have it about now, -rc2 of the release after the one we are shoving in
<apw> just you don't always know about it :)
<ogasawara> Sarvatt: heh, np.  I'm still fixing up build failures at the moment.
<apw> (not that ogasawara doesn't deserve thanks of course)
<apw> ogasawara, let me know if any of my fss drop off
<ogasawara> apw: ack
 * apw switches his DNS servers ... say goodbye :/
<txomon> apw, done
<ricotz> Sarvatt, exactly ;)
<ricotz> ogasawara, thanks!, i hope this yama thing is easy to fix
<ogasawara> ricotz: yep, about to patch it and push to my repo
<ricotz> ogasawara, great
<hggdh> sconklin: bug 823912 is ready to keep on
<ubot2> Launchpad bug 823912 in linux "linux: 2.6.24-29.93 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/823912
<sconklin> hggdh: thanks!
<tgardner> sconklin, have you had any howling about a regression in the recently -proposed 2.6.32-34.73 kernel? I'm trying to bisect it, but I've got one of these damn nVidia cards which is giving me a bit a DKMS trouble. I'm suspecting one of the mm patches since the reproducer uses chromium, and I've straced the lockup to an mmap system call.
<sconklin> tgardner: let me check my list of regressions I'm tracking. I don't catch them all,but I'll look at the ones I have
<sconklin> tgardner: no, I see a 'cordless mouse stops working on return from suspend' and 'lost ethernet networking', no graphics
<tgardner> sconklin, ok, I'll keep pursuing this until I figure it out.
<sconklin> tgardner: any regressions that I am aware of in a release get tagged regression-release, so you can always try searching for that
<tgardner> sconklin, that presumes some skill with LP (and that it won't timeout)
<sconklin> tha advanced search page allows searching for tags, but I can't help with the timeout
 * jjohansen -> lunch
<tgardner> sconklin, I was kidding about the skill :) the timeouts, not so much.
<lool> cjwatson: linaro-vexpress > ack; we've had a discussion 10 days ago about revamping the configs and having a sane way to manage them again, so at least I see a path forward on avoiding this kind of issues in the future
<njin> Hello guys, i've got a bug during the installation with 3.0.0-8.11 (2.6.32 works fine), can someone look at bug 826948 at the attached photo and tell me wich voice select at https://bugzilla.kernel.org/enter_bug.cgi
<ubot2> Launchpad bug 826948 in linux "system crash during installation" [Undecided,New] https://launchpad.net/bugs/826948
<njin> thanks
#ubuntu-kernel 2011-08-16
<RAOF> Oh, bah.  Stupid broken mainline builds.
 * smb crawls in
 * RAOF waits to ambush apw.
<smb> RAOF, He probably saw that. :)
<RAOF> smb: I know.  You need to properly prime the target for a psychological ambush.
<smb> Giving time to don all armor does not seem like a good move before attacking... :-P
<RAOF> No.  Now, apw will dread the moment he needs to say something in #ubuntu-kernel, premtively flinching for the pile of work that will be dropped upon him!
<smb> Reminds me of the rumors about a 24hrs notice before committing a crime to the victim (unverified to be thought of or done in TX)
<smb> RAOF, On the "good" side, we should have a whole bunch of QA analysts in London this week. :-P
<RAOF> Ah, really?  What sprint's happening there?
<smb> Something with QA
<smb> CoP and DA
<smb> wth
<ppisati> morning
<abogani> ppisati: morning
 * smb wonders into which hole apw fell...
<RAOF> apw: Could you give the drm-intel kernel builds a kick?  I'm mainly interested in 1519b9956eb, ed10fca9c351c83, and de842eff410.
<apw> RAOF, will have a look
<apw> smb, in the office is all
<smb> apw, Ah, that explains mumble (and the general silence as there is probably a queue of broken laptops as usual)
<apw> heh :)
<Guest47227> does anyone know how to include some custom files in the linux-headers package after building a kernel with ubuntu-package ? I have some extra .so files build under tools/gcc (gcc plugins) but they don't get included in the headers .deb so I have to move them from the build dir manually after installing it. How can I include them in the package?
 * ppisati -> out to get some foood
<siji> apw, hi
<siji> hi all
<siji> am trying to build 2.6.38-omap kernel (ubuntu natty) 
<siji> for Touchscreen support (ads7846)
<siji> And downloaded the source code from ubuntu 
<siji> but while doing menuconfig , this driver is not visible 
<siji> then I have added this driver manually in .config 
<siji> but its not building the module 
<siji> any one can tell me where am wrong ?
<siji> http://paste.debian.net/126389/ 
<siji> my .config file is there
<smb> siji, When you use the ubuntu source you should do a "debian/rules editconfigs" That modifies the config in debian.ti-omap4 which is used for the builds
<siji> smb, if am building only specific module then ?
<siji> same method have to follow ?
<smb> siji, Not exactly. But on the other hand it might be better to do complete builds because that gives you a package to install which can have a unique version number, too. Also it makes sure the module version matches up with the rest of the kernel. But I know that at least building on arm is not that quick
<tgardner> sconklin, herton: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813026/comments/2
<ubot2> Ubuntu bug 813026 in linux "CVE-2011-1020" [Undecided,Fix committed]
<siji> ya i got your point , cose of the time am trying to build only the module 
<herton> tgardner: hmm ok, may be we have to revert the fix on lucid and everyone else. I'll mark the tracking bug with the regression found
<tgardner> herton, I pushed the revert for Lucid. I don't know that its required on newer kernels.
<herton> ok
<jwi> tgardner: maverick-proposed needs the revert as well, bug 827198
<ubot2> Launchpad bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,Confirmed] https://launchpad.net/bugs/827198
<tgardner> jwi, noted.\
<jwi> I guess 827208 & 825207 are dups
<tgardner> jwi, hmm, dunno about 825207. its possible.
<apw> tgardner, did i break it 
<apw> tgardner, and if you are reverting, be nice if they are Reverts:
<tgardner> apw, it certainly did on Lucid. still working on Maverick
<apw> tgardner, bah ...
<tgardner> apw, I had a clean bisect on Lucid, so I'm reasonably sure its the right commit.
<apw> tgardner, fair enough indeed.  i'll have to test that the reverts do the right thing
<tgardner> apw, lucid master-next has the revert. I built that kernel as well as the bisect kernel with that reverted. both fixed the lockup.
<apw> tgardner, sheet ... will have a look
<ogasawara> ##
<ogasawara> ## Kernel team meeting today @ 17:00 UTC in #ubuntu-meeting
<ogasawara> ##
<herton> tgardner, apw: hardy update has the same cve fix, because of the regression we put it on hold now (bug 823912)
<ubot2> Launchpad bug 823912 in linux "linux: 2.6.24-29.93 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/823912
<tgardner> herton, does chromium even run on Hardy ?
<herton> tgardner: no idea. is this specific to chromium, or more a general issue?
<tgardner> herton, its likely generic, but chromium appears to be the most commonly used reproducer.
 * ogasawara back in 20
<Sarvatt> ogasawara: is it normal makedumpfile fails on the ubuntu-p kernel? i had to set no_dumpfile=1 to build it
<ogasawara> Sarvatt: I had to do the same.  it appears makedumpfile doesn't like the newer kernel version, but I haven
<ogasawara> 't dug much deeper into it
<ppisati> maint-startnewrelease is failing for me
<ppisati> http://pastebin.ubuntu.com/667427/
<ppisati> i think it cannot find linux-image-3.0.0-1201-omap4_3.0.0-1201.5_armel.deb
<ppisati> any way to force it?
<ppisati> (got a new BSP update from agreen so so i was rebasing...)
<tgardner> ppisati, can you just run 'fdr startnewrelease' ?
<ppisati> tgardner: good idea :)
<cnd> sforshee, awesome work on alps!
<sforshee> cnd, thanks!
<cnd> I want to ask you about your possibilities for reporting
<sforshee> still got a lot of work to do to get everything in shape
<cnd> I think I understand what alps is reporting
<cnd> and I understand option 1
<cnd> but I can't figure out what option 2 is
<cnd> could you restate it?
<sforshee> so you understand that the projection of a touch point could set multiple bits in each of the bitfields?
<cnd> yeah
<sforshee> I could estimate the width by counting the number of bits that are set
<sforshee> and estimate the touch point to be in the middle of the range of set bits
<sforshee> does that make more sense?
<cnd> you could do that if there's only one touch
<cnd> but what if there are multiple?
<sforshee> then there are multiple groupings of set bits, as long as the fingers aren't too close together
<cnd> yeah
<sforshee> if they are too close together, I have to do a little guessing, like assuming the contacts are of equal size
<cnd> oh, I think I see what you are saying
<sforshee> I know how many contact points are represented in the bitmaps
<cnd> you'll try to figure out the center positions
<cnd> and the widths
<sforshee> yep
<cnd> and that's how it's different than option 1?
<sforshee> yes, for option 1 I'd only take the extremities and use that to create points for a bounding box
<cnd> ok
<cnd> sforshee, what do you get with three touches?
<cnd> do you get three sets of X and Y bits set?
<cnd> potentially up to three, that is
<sforshee> I still need to experiment with that, but that's my assumption
<cnd> ok
<sforshee> I think any bits that are "covered", so to speak, will be set
<cnd> yeah
<cnd> that makes sense
<cnd> so how to report that best...
<cnd> sforshee, I think you should use SEMI_MT
<cnd> and report only the min and max X and Y values
<cnd> but try to get the "center" of the extreme bits
<sforshee> so option 1 then?
<sforshee> ah, halfway between 1 and 2
<cnd> yeah
<cnd> so if you have an X axis like: 00110000111000
<sforshee> if I'm doing that work I might as well report width though, as I'll already have it
<cnd> then report half way between the first two '1's and in the middle of the second group of '1's
<cnd> sure
<cnd> well...
<cnd> actually, I wouldn't
<cnd> because of the tricky aspect of SEM_MT
<cnd> you don't know which bits correspond to which touches
<cnd> if you have two groups in both the X and Y directions
<cnd> you don't know if the touches are in corners 1 and 3 or 2 and 4
<sforshee> yes, that's true, unless I'm able to figure it out from the absolute position data in the first packet, but I'm still unsure about that
<cnd> and evdev reports widths in a circular sense, so unless you can match up the X and Y directions the widths may not be correct
<cnd> yeah, I wouldn't try to figure it out
<sforshee> okay, makes sense
<cnd> that's too much to be doing in the driver
<cnd> at least at first :)
<cnd> and userspace could potentially do it
<cnd> though width values couldn't be calculated after the fact in userspace
<cnd> but as soon as you go from two to three touches, then you're screwed
<sforshee> all right, that's what I'll do then
<sforshee> thanks!
<cnd> you could match up one position
<cnd> but you don't have enough info for the other two
<cnd> sforshee, I'm so glad we're getting alps going!
<sforshee> yeah, it would only work for 2 fingers anyway
<sforshee> cnd, I'm not sure what's going to happen when we start trying this on more hardware though
<sforshee> the initialization is still pretty opaque
<cnd> sforshee, when you report values, I would linearly multiply the low-res stuff up to the high-res range
<sforshee> it may not be right for all hardware of this type
<sforshee> yeah, that was my plan
<cnd> so it's the same range between ABS_X and ABS_MT_POSITION_X
<cnd> yeah
<cnd> sforshee, I would suggest making a dkms and trolling for testers in one of the ALPS bugs on LP
<sforshee> will do
<cnd> they're like a honeypot, and you'll be treated like a king :)
<sforshee> you'd think, but I've only had a few testers for the elantech stuff
<cnd> really...
<cnd> that surprises me
<sforshee> me too
<sforshee> people are happy to complain, not so happy to test it seems
<cnd> did elantech have anything better than PS/2 emulation?
<cnd> before you worked on it?
<sforshee> not for the third-generation of their hardware
<cnd> k
<sforshee> I'm going to send those patches to linux-input in the next couple of days
<cnd> awesome!
<cnd> sforshee, please CC me when you do
<cnd> not a big deal if you forget though
<sforshee> I'll try to remember :)
<cnd> I'm subscribed and I'll see them one way or another
<ogasawara> ##
<ogasawara> ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting
<ogasawara> ##
<ogasawara> meeting's about to start ...
<Daviey> ppisati: There were a few server arm issues raised last week.. are you the contact for that?
<ppisati> Daviey: ah, the lxc stuff? sorry, i just came back from vacation
<ppisati> Daviey: i'll queue it up for the next arm report
<ppisati> btw, my usb stopped working... cool...
<Daviey> ppisati: There was iscsi support being missing aswell, which was a concern
<jjohansen> Daviey: stefan had lxc running on an arm kernel at the sprint
<Daviey> jjohansen: Oh great!  via libvirt?
<ppisati> jjohansen: yep, he told me but i forgot to say it in the report :P
<jjohansen> he said the kernel was good but there where some user space issues
<Daviey> eek, i should have kept quiet
<jjohansen> Daviey: I don't think it was via libvirt
<smb> Not sure what lxc-tools using
<smb> Stephane was the one doing the user-space side
<jjohansen> smb: yep
<smb> And as far as I know the issues there are resolved 
<jjohansen> hrmm, well hopefully, though I that he was using lxc-exec instead of lxc-start
<jjohansen> but I could be wrong
<smb> Hm, thought both
<ogasawara> sconklin: going forward for the meetings, would you prefer to just combine the "Status: Stable Kernel Team" and "Security & bugfix kernels" topics?
<ppisati> last time i check, lxc-config (??? don't remember the name of the user land tool that checks lxc kernel compatibility) complained about a deprecated option
<smb> Cause he pulled in a whole chroot env
<jjohansen> smb: oh maybe, I remember catching the bit about lxc-exec and then finding some of the problems so by the end maybe
<ppisati> s/check/checked/
<jjohansen> smb: ah I missed that
<smb> ppisati, When we tried (with some other options enabled) there was only config_cgroup_freeze missing
<smb> and the userland tool crashed 
<smb> because of a personality check
<sconklin> ogasawara: yeah, there's no sense in breaking out a one-line link as a separate agenda item
<ogasawara> sconklin: agreed.
<ppisati> smb: uhm ok
<ogasawara> bjf: ^^ might want to update your runes file for the meetings...
<smb> ppisati, Well anyway, next kernel should be ok and lxc tools saw several uploads last week :)
<smb> Beside of running with one cpu was faster than with two, things looked promising so far...
<ppisati> smb: the smp looks really nasty
<ppisati> smp bug
 * ppisati is really tired...
 * smb nods
<smb> ppisati, And all the useful tools seem to be missing on arm
<smb> Like perf or latencytop...
<cking> that's not fun
<smb> ppisati, Someone (jjohansen you remember his name? rob something?) noted that cache invalidation may be a problem...
<ppisati> smb: imo it could be everything
<ppisati> smb: from affinity, to timers, to $whatever...
 * smb thinks we need someone with a jtag and not being afraid to use it
<jjohansen> smb: no I don't remember but he was the Calxeda guy
<ppisati> i've jtag and i know how to use it
<jjohansen> he said that the smp cache snoop/invalidate on A8 and A9 where extremely slow
<tgardner> jjohansen, Rob Herring ?
<smb> Could be. At least I think I remember the Rob part
<jjohansen> yeah I think that was it
<jjohansen> yep, it was
<jjohansen> ppisati: one way you could test that theory is do some parallel compute, and for one test make sure its hitting different areas of mem/cache alignment and for another shared data
 * jjohansen doubts that the slow cache is the responsible for the problem
<cking> it's one of those bugs that you need to figure out a way to exercise it and then use JTAG to see what's really going on
<ppisati> jjohansen: sounds like a time-attack
<jjohansen> ppisati: yeah
<ppisati> imo it's something simpler but yes, trimming it down to the simplest case is the first step
<ppisati> so i can follow the code/call path and see what's different in the single vs dual cpu case
<smb> Though the hdparm run is quite simple, I guess there is still multiple things involved
<ppisati> yep
<ppisati> uhm
<ppisati> but if the bug is still there even when a cpu is hotplugged, how can it be an smp scheduling bug?
<smb> ppisati, I was suspecting the way or what timers are used
<ppisati> a good trace could be to see what's the difference between single cpu and smp-with-one-cpu only
<smb> Even when hut-unplugging one cpu, it is different from what is used when starting only with one
<ppisati> yep, but nothing is scheduled on the second cpu
<smb> right
<ppisati> because it's not there anymore (modulus bug)
<smb> well /proc/interrupts does look different (in the ipi section)
<smb> which still shows two entries...
<ppisati> ah
<sconklin> Is it possible to use virtualbox or any other vm tools to boot entire SATA drives in a VM? I have a machine with a swappable SATA drive bay, and I'd like to be able to boot entire test disks
<sconklin> anyone know?
<jjohansen> sconklin: look for pci device passthrough for kvm
<sconklin> jjohansen: thanks
<jjohansen> sconklin: I know its possible just haven't done it myself
<sconklin> That's just the kind of pointer I was looking for
<jjohansen> sconklin: I did do it years ago with vmware so I know its possible there too
<sconklin> Yeah, I'm done it with VMWare in the past
<CarlFK> have you tried: qemu -hda /dev/hdb 
<CarlFK> er..
<sbeattie> sconklin: http://www.virtualbox.org/manual/ch09.html#rawdisk indicates its possible with virtualbox, too.
<CarlFK> have you tried: qemu -hda /dev/sdb
<sconklin> haha typical Linux "there are three ways to do it" response. Thanks!
<sbeattie> sconklin: hehe, you get to pick your poison. :-)
<sconklin> sbeattie: Oh, I like any option that warns me about total loss of data in a Big Red Box!
<tgardner> herton, the mystery deepens: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/827198/comments/4
<ubot2> Ubuntu bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,In progress]
 * tgardner is back in an hour or so
<herton> tgardner-afk: strange indeed
<CarlFK> sconklin: from #qemu: balrog-k1n: i've done something like this many times, but usually added -snapshot  to avoid the VM writing to the physical disk
<sconklin> CarlFK: ok, I'll check that also
<sconklin> thanks
<CarlFK> welcome
<herton> tgardner-afk: checking here commits, I suspect we need also "76597cd proc: fix oops on invalid /proc/<pid>/maps access" backported to maverick and others
<stickyboy> I'm starting to sense something fishy with kernel-package's `make-kpkg` in 11.04.  The headers package it generates is behaving inconsistently.
 * ogasawara lunch
<tgardner> herton, while we may need 76597cd, I'm not sure its related to the chromium hangs.
<mfilipe> sforshee, fuuuuuuuuuuuuuuuuuu
<mfilipe> more 1 year to solve the bug :( 
<mfilipe> +1 year*
<cr3> anyone happen to know how to parse the MODALIAS strings in the output of udevadm info --export-db?
<herton> tgardner: indeed. but other guy came in the bug reporting a oops that I think 76597cd will fix. I think would be worth giving them a test build with it, and we should have that backported anyway
<tgardner> herton, ack.
<sforshee> mfilipe, every time there's a patch that fixes it something else gets broken, and that's a big part of why it's taken so long
<tgardner> herton, ok, I'll have a look at backporting that commit and getting some test kernels advertised.
<herton> ok, cool
<mfilipe> sforshee, thanks again for you effort to fix the problem but I think that it will get some months again :(
<tgardner> ogasawara, you might as well clone P into the ubuntu directory on zinc. that way we won't have to change 
<tgardner> sources later
<ogasawara> tgardner: ack
<jjohansen> rebooting
<txomon> hello is there anyone that can explain me this?
<txomon> man 3 va_end in /va_dcl
<txomon> apw, can you help me?
<txomon> is there anyone there?
<bryceh> txomon, past EOD for most kernel folk I think
<txomon> Its about a strange C syntax, that I can't understand..
<txomon> do you know what it means?
<txomon> !EOD
<ubot2> Factoid 'EOD' not found
<txomon> bryceh, do you know what it means?
<bryceh> txomon, "End of Day" i.e. they're not in work hours
<txomon> ah xD ok ty
<bryceh> most kernel guys are in US or European time zones
<jjohansen> txomon: va_end is weird
<jjohansen> txomon: what are you looking for?
<txomon> im looking for the meaning of that va_dcl there in the middle
<txomon> C syntax
#ubuntu-kernel 2011-08-17
<jjohansen> ah, right let me look at the man page more carefully
<jjohansen> txomon: va_dcl is a define brought in by #include "arargs.h" to define anything that the compiler may need for the old style varags
<jjohansen> from vararhgs.h
<jjohansen> +#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3
<jjohansen> +#define	va_dcl			__builtin_va_alist_t __builtin_va_alist;
<jjohansen> +#else
<jjohansen>  #define	va_dcl			__builtin_va_alist_t __builtin_va_alist; ...
<jjohansen> +#endif
<jjohansen> so it may expand to nothing, or it can expand to some attributes to tell the compiler the function is using varages
<jjohansen> I think it is only ever used on implementations that are using varargs.h instead of stdarg.h
<txomon> oki
<txomon> so is just something weird and outdated that I shouldn't take care off?
<txomon> s/off/of
<jjohansen> txomon: mostly yeah, if you are using varags.h you'll need it, but you should probably be using stdarg.h instead
<txomon> ok, ty very much
<smb> diwic, And I was just about to ask myself... :)
 * apw yawns
 * smb waves
<ppisati> morning
<apw> morning!
<bryceh> hiya apw
<apw> bryceh, hiya, late for you
<bryceh> apw, unfortunately, not really (baby)
<apw> ahh jj syndrome :)
<bryceh> :-)
<ppisati> so guys, according to the "kernel team new world order" i can't pull req till next week, right? (i mean the new topic branches discipline)
<apw> ppisati, if they have asked you to prepare something, and its prepared i think you can ask anytime no?
<ppisati> apw: didn't receive any notification... let me see if reading all the emails help
<apw> smb, have they actually told you how they will tell you when there are derivative brach updates to do?
<smb> apw, ppisati Not exactly. I guess the hope is that I won't miss the bugmail... but  Iam not convinced
<smb> Last time I asked because I saw an upload message, there was none needed...
<ppisati> anyway, the new omap4 kernel boots, has video working, etcetc and i wanted to give it to the arm people - i'll put a kernel pkg binary on people.* and push it to zinc so they can start tinkering with it
<ppisati> rsalveti: ^
<apw> ppisati, sounds good.  this is for oneiric ?
<ppisati> yep
<apw> ahh the new world order doesn't apply to that
<apw> send away
<ppisati> i want top dequeue ASAP so i can concentrate on the slow usb i/o thing
<ppisati> doh!
<ppisati> ok, pull req coming
<apw> ppisati, slow usb> yeah that one is pretty odd, i think smb poked it a bit dunno if he had any insite to help get you started
<smb> apw, Not too much but we talked about that yesterday
<apw> smb, good enough
<apw> RAOF, was it you who was asking me about mainline drm builds yesterday?
<RAOF> apw: Yes, it was.
<RAOF> apw: I haven't tried them yet; I want to see if those commits fix a bug where my external monitor gets permanently turned off.
<apw> so remind me of the issue, the logs imply there has been no updates for a while now
<apw> are we using teh wrong trees again ?
<siji> smb, hi
<apw> RAOF, ^^
<RAOF> apw: The tree that I looked in FTBFS in ecryptfs
<apw> oh really, hrm, which one
<RAOF> I'm looking at http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ whose COMMIT suggests that it contains the commits I'm afterâ¦
<newb> hi
<newb> I have a trouble in compile module...
<newb> can anybody help?
<apw> RAOF, seems that the ecryptfs boys have screwed the pooch
<RAOF> Superlative
<apw> will see if i can coax that option off and rebuild
<RAOF> Of course, I *have* an ecryptfs filesystem.
<RAOF> Just to make this super awkward.
<newb> can anybody help my problem?
<newb> my problem is same as here: http://www.incentivespro.com/forum/viewtopic.php?t=214
<newb> If I compile my module, It says
<newb> scripts/mod/modpost: 1: Syntax error: word unexpected (expecting ")") 
<txomon> newb, syntax error
<txomon> try in #c
<txomon> if here nobody answers
<txomon> bye!
<RAOF> I guess I could just suck it up, cherry-pick those commits, and build a kernel locally.
<newb> it is not a syntax error in my program...
<newb> my program can compiled in my host PC
<newb> I'm compile the module in target Embedded board
<apw> newb, hm
<RAOF> Different /bin/sh on your host and embedded?
<ogra_> s/Embedded board/panda/ 
<newb> yeah, pandaboard
<apw> newb so on the machine which failed what does 'file scripts/basic/fixdep' say
<ogra_> i sent newb here and asked him to compile natively instead of cross with the right headers installer 
<ogra_> which i would have expected to work ... but apparently it causes that sytax error
<ogra_> *headers installed
<newb> first scripts/basic/fixdep is failed but
<apw> newb, i don't think i understand what you mean there?
<newb> Right now, I compile a module in Pandaboard
<newb> And I install the kernel package linux-headers-2.6.38-1209
<newb> linux-headers-2.6.38-1209-omap4
<newb> linux-image-2.6.38-1209-omap4
<newb> And then, I compile the module I wrote
<newb> But it fails with scripts/basic/fixdep error
<newb> So I tried "make modules_prepare" in /usr/src/linux-header forder
<newb> but that command also fails...
<apw> ok and on that system where the failure is occuring, what does 'file scripts/basic/fixdep' say
<newb> Syntax error
<newb> After the failure of "make modules_prepare", the error changed to "scripts/mod/modpost"
<apw> no i mean the literal command, something like 'file /usr/src/*/scripts/basic/fixdep' what does _that_ command say
<newb> you mean that command is "make modules_prepare"??
<apw> no i want you to run the command 'file /usr/src/*/scripts/basic/fixdep' on the system which is failing the build and tell me what the output is
<apw> if its long you could pastebin the output
<newb> It was
<newb> scripts/basic/fixdep: 1: Syntax error: "(" unexpected
<apw> newb, no i really, really mean i want you to run the _new_ command i am giving you, not the old output
<newb> sorry...
<newb> I'll try
<newb> I can type...
<apw> newb if you have netowkr on the machine you can use pastebinit to upload the output
<rsalveti> ppisati: I'd ask you to wait until tomorrow
<rsalveti> ppisati: as tomorrow is the release date for the kernel at linaro
<rsalveti> then you'll be getting the kernel from 11.08 release
<rsalveti> ppisati: and as I said, you'd need to revert one patch to make sgx to work
<newb> it says: /usr/src/linux-headers-2.6.38-1208-omap4/scripts/basic/fixdep: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped /usr/src/linux-headers-2.6.38-1209-omap4/scripts/basic/fixdep: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
<rsalveti> ppisati: where is your dev tree?
<newb> apw: this is the output
<apw> newb and if you run that /usr/src/linux-headers-2.6.38-1208-omap4/scripts/basic/fixdep directly, does it say Syntax error?
<newb> there is no syntax error i think
<newb> that is whole output
<newb> the compile error is changed to modpost...
<apw> newb i mean if you now additionally try and run the fixdep binary on the command line does it error
<newb> additionally try and run the fixdep binary??
<apw> what does executing /usr/src/linux-headers-2.6.38-1208-omap4/scripts/basic/fixdep say
<newb> Usage: fixdep <depfile> <target> <cmdline>
<ogra_> looks fine
<apw> ok so that fixdep is ok
<newb> ah
<apw> and is a native binary as expected
<newb> is it okay fixdep?
<apw> newb, i think the Syntax error from the attempt to run fixdep is most likely caused by the fixdep it is running not being a binary for the machine you are compiling on
<apw> the system things its not a binary so it tries to run it as a shell script, and it errors
<newb> I execute /script/mod/modpost and it says cannot execute binary file
<apw> and does that file exist and if so what does the command 'file <name>' on that file say
<newb> It says executable, Intel 80386...
<newb> I think it is not arm binary
<apw> ok so that will not run on your arm machine indeed.  what is the full filename to that file
<newb> filename:  /usr/src/linux-headers-2.6.38-1209-omap4/scripts/mod/modpost
<ppisati> rsalveti: git://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4
<ppisati> rsalveti: the pull req is already out, i'll reissue another one when the next update hits
<apw> newb, and who built the headers you have installed ?  was that us or you?
<rsalveti> ppisati: ok
<newb> me
<newb> use dpkg-buildpackage
<apw> newb, and where was it built? on the board or cross-compiled
<ppisati> rsalveti: BTW, there're some new options about video&c (like OLD_VIDEO_$something) and that prevents some other DSS options to be turned on
<newb> CROSS_COMPILE=arm-linux-gnueabi- do_tools=false dpkg-buildpackage -B -aarmel -uc -us
<newb> cross-compiled
<ppisati> rsalveti: when you compile the new kernel you'll see some warnings, revire it and tell me what i have to turn on/off
<apw> newb, ok so you can only use cross-compiled kernels to cross-compile external modules and you need to use a native build kernel to native build external modules
<ppisati> rsalveti: s/revire it/review them/g
<apw> as the headers packages you are using contain copies of the binaries which are needed for the build, like modpost
<rsalveti> ppisati: sure
<ppisati> rsalveti: cool, thanks
<newb> yes
<newb> so what i have to do?
<apw> use nativly compiled headers if you are compiling on the board and cross-compiled headers on your cross-compile environment
<ogra_> just build on the panda
<ogra_> that excludes such issues
<ogra_> for a single module that wont make much difference in build time
<apw> but you must use native header packages to do that, not ones you cross-compiled
<newb> the compile of kernel in panda takes too long time....
<ogra_> you want only a new module 
<ogra_> no need to compile the kernel
<apw> just use the one from the archive
<newb> I need to change kernel too
<apw> then you need to build both in the same place
<newb> I need to use gpmc in pandaboard
<apw> then you need to compile both your kernle and your external module in the very same environment
<newb> so I need to modify kernel
<rsalveti> ppisati: do you have a bug already for the issue with pulseaudio consuming 100% of the cpu?
<rsalveti> ppisati: when using natty we also had that issue, as described by bug 816638
<ubot2> Launchpad bug 816638 in linaro-ubuntu "Pulseaudio consumes 100% of the cpu when trying to play a sound with natty's linaro LEB and 3.0.0-1402-linaro-lt-omap " [High,Confirmed] https://launchpad.net/bugs/816638
<rsalveti> but I still didn't reproduce with oneiric, so would be good to have your results
<ogra_> newb, just out of curiosity, what are you using gpmc on a pandaboard for there is no flash ? 
<newb> I want to connect FPGA
<apw> RAOF, ok the issue for your build is that the new ecryptfs stuff is starting to use a new symbol from security/keys/encrypted.c, which means that if ecryptfs =y then that module needs to be =y, and it is =m and so its not there and blammo no buildy
<ogra_> ah
<apw> RAOF, now as it is a new requirement it is not obvious if you are able to move ECRYPTFS_FS=m for your test build then life will be ok
<siji> apw, any updates on the Bug #824589
<ubot2> Launchpad bug 824589 in ubuntu "improper Touch Screen Driver module(for arm beagleboard) for TSC2046 in the Expansion board,and it connect with DM3730 by SPI port ." [Undecided,Incomplete] https://launchpad.net/bugs/824589
<apw> RAOF, so if you want that specific build you should be able to take a linus tree, git reset --hard to the sha1 in COMMIT, apply the patches in the directory, update the config and build the result
<ppisati> rsalveti: nope, no bug yet
 * ppisati -> lunch
<siji> smb, ping 
<smb> siji, Hi
<siji> hi
<siji> sorry for bothering you
<siji> Just want to clarify something regd. kernel building 
<smb> siji, Sure, just ask away
<siji> I am trying to build it from my host PC(for omap3 beagle)
<siji> And downloaded the kernel source from kernel.org , config file from ubuntu natty (/boot/config-2.6.38-8-omap
<siji> so just want to confirm that if i did make modules with cross-gcc will it generate the module ?
<smb> siji, You should generally be able to cross compile. But when you took the kernel source from upstream (which is 3.1-rc2 right now) the question is what version is running on your arm board. This may be completely incompatible
<siji> smb, I think i have downloaded the right version 
<siji> my arm kernel is 2.6.38-8
<siji> (ubuntu natty -omap3)
<smb> ppisati, Probably has the latest runes how to set up the cross compile part correctly, but still. Is there a reason you did not take the git tree from kerne.ubuntu.com for natty and changed to the ti-omap3 branch?
<smb> siji, ^
<siji> cose i think there is some bug in the desired module (ads7846) 
<smb> Hm, actually natty already seems to be ti-omap4...
<siji> ok
<siji> actually the rootstock already built the the desired kernel module 
<siji> but failed to insert it
<siji> Bug #824589
<ubot2> Launchpad bug 824589 in ubuntu "improper Touch Screen Driver module(for arm beagleboard) for TSC2046 in the Expansion board,and it connect with DM3730 by SPI port ." [Undecided,Incomplete] https://launchpad.net/bugs/824589
 * smb looks at the report
<smb> siji, Those kind of failure sounds like the module was build with the wrong headers somehow...
<siji> smb, right but i have build it by rootstock 
<smb> siji, I think I am not sure what you mean with rootstock
<siji> smb, sorry 
<siji> rootfile system building tool
<smb> Ah
<smb> Probably something doing a chroot to build
<siji> right
<siji> and there is a option in rootstock tool to build the kernel image too 
<siji> which generated those modules 
<smb> There seems to be something wrong with the tool or its usage then... But to get me correct, this driver is in the ubuntu kernel code and just not enabled or you need a newer version of it?
<siji> the driver is there in the ubuntu kernel source +it has generated the loadable module 
<siji> smb, you understood ?
<smb> hmm, I try to parse... I may be a bit slow today...
<siji> ok :)
<siji> actually rootstock tool with the parameter linux-omap generated the RootFile System with initird and vmlinux of 2.6.38-8-omap 
<smb> My confusion is that you said, that you got the kernel.org code and try to compile the module. The first question to me somehow is: why in the first place do you need the module compiled. You said there is a bug. So the original kernel package has the module but it does not work
<siji> ah ,got it
<siji> So you mean this bug is not only for ubuntu kernel 
<siji> smb, what you will recomend ?
<smb> Well maybe or maybe not. But generally its hard to claim it a bug when you try your own compile and it does not work as expected. At least not against a distro. You can say the module does not work and needs to be fixed or does not exist and should be enabled
<siji> ok
<smb> siji, And even just for giving help, there is a lot of information missing. Like the exact release and kernel version you are running. Where the module in question comes from, why it was made. Just looking at the content of the bug report there is unfortunately more questions open than answered.
 * smb notes that we here may know how to compile kernels but have to mind-reading powers ;)
<siji> smb, I assumes ubuntu-arm natty  is enough to indentify the kernel version 
<smb> siji, There are updates
<smb> It is clear that it is 2.6.38 but not exactly which upload
<siji> ya may be .But this is build by rootstock for me 
<smb> Yeah, but as I do not know what it is, I cannot say what it does exactly ... And what it takes as a source
<smb> The module disagress about symbol could be wrong headers or slightly different configuration in something used by the module
<tgardner> ppisati, are you ready for me to upload the meta package for oneiric ti-omap4 ?
<tgardner> ppisati, never mind, just saw your email
 * herton has to run an errand in business hours, back in 1h hopefully
 * smb notices with some relief that assigning the topic branch tracking bug to him does make the notification go into a bucket which is not overflowing with other stuff..
<apw> smb, heh something works then 
<smb> yep
<bjf> tgardner, ogasawara : http://people.canonical.com/~kernel/reports/_kernel_hot_.html
<bjf> tgardner, ogasawara : this is the start of a "kernel hot list"
<ogasawara> bjf: cool, I'll take a look
<ogasawara> bjf: AM column stands for ?
<bjf> ogasawara, "Affects Me"
<ogasawara> ah, thanks
<tgardner> bjf, is the AM column the metric that makes a bug 'hot' ?
<bjf> tgardner, ogasawara : bdmurray clams that "heat" is working better, i'll be adding a "heat" column and if it works i may drop the CO SU AM columns
<ogasawara> bjf: ack
<tgardner> bjf, how is heat measured?
<bjf> tgardner, ogasawara : we'll run with them all for a bit
<bdmurray> tgardner: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/database/schema/trusted.sql#L1846
<bdmurray> tgardner: the calculation is right there
<tgardner> bdmurray, so I merely have to mark my bug private and a CVE to bump it to the top of the list.
 * ogasawara back in 20
<bdmurray> tgardner: yes that'd do it
<tgardner> bdmurray, given that private bugs and CVE's generally come to us by fairly direct routes, does it make sense to have them in the hot list ?
<bdmurray> tgardner-afk: well the same calculation is used for every package and project in Launchpad so I'd say yes
<tgardner> bdmurray, well, I can sort bjf's page by column, so it makes it easy to ignore CVEs at least.
<bjf> tgardner, apw wanted the cve's on the list
<bjf> tgardner, there will be _no_ private bugs on this list as it is a public list
<tgardner> bjf, well, I can sort such that I can ignore apw as well
<apw> tgardner, yeah mostly as there actually should only be a couple on there as we only have a couple open... i need to clean them up and this will help
<tgardner> bjf, so this is gonna get updated regularly ?
<bjf> tgardner, every 30 minutes the list is refreshed, the data is refreshed more frequently than that
<bjf> tgardner, there is also a mechanism in place to add a specific bug to the list, right now the list is based off of several tags
<bjf> tgardner, the tags currently tracked are: "kernel-key", "iso-testing", "pc-cert", "kernel-cve-tracking-bug"
<tgardner> bjf, ack
<ogasawara> bjf: is there a tag to use to remove a bug from the list?
<bjf> ogasawara, no
<bjf> ogasawara, if it were tagged and on the list because of "kernel-key" you could remove the tag, but other than that, no
<brendand> sconklin - is it still the case that the natty kernel will be respun?
<sconklin> as far as we know, yes. HWE is still working with upstream as far as I know. Status has not changed since the last email status update.
<apw> sconklin, is there a kernel with the relevant patches reverted?  i have a machine with a display regression in -11 and want to make sure its the same issue
<sconklin> apw: talk with vanhoof. I believe that there are only a very limited number of machine configurations which exhibit this and if you have the same problem, you could be helpful for testing
<herton> apw: if it is related to i915, I have some built kernels here, with patches reverted: http://people.canonical.com/~herton/lp814325
<herton> but built amd64 only
<apw> herton, ok i suspect i am i386, but i also am not any of the suspected platforms
<vanhoof> apw: some sort of corruption? ... can you correct w/ cycling dpms?
<sconklin> apw, herton: My understanding is that for the platform which was reported, the problem still exists upstream, and that if you revert the patch which seems to have introduced it, you lose graphics on all Sandy Bridge platforms. So we're waiting until we understand it before we do anything
<apw> nope mine is a black-screen in X, damn
<herton> sconklin: if we revert that patch we reintroduce bug 791752
<ubot2> Launchpad bug 791752 in linux "Can not toggle Display to External only mode " [Medium,Fix committed] https://launchpad.net/bugs/791752
<sconklin> herton: right
<vanhoof> which impacts SandyBridge as a whole
<apw> but that isn't a regression from the previous version, so thats ok
 * apw is unsure it makes sense to hold every other fix in the tree while one decides.  the problem which it fixes is in the kernel out there, and will be the same in the kernel with the revert, so is it not safe to revert and release while we wait for the fixed fix
<ppisati> smb: i found another bug related to the clk on omap4, but it didn't fix the i/o problem... crap...
<herton> apw: it is a regression, on -proposed kernel
<smb> ppisati, Suboptimal... But hey, another bug bites the dust... :)
<apw> herton, which the 791752 itself or the bug introduced by its fix
<herton> right
<apw> herton, that was an OR question
 * smb giggles
<vanhoof> apw: on my end its just a question of the bigger win, the regression really does seem like a corner case, on a relatively niche subsystem of machines
<apw> herton, was 791752 a regression in -proposed, or only the breakage by its fix
<vanhoof> however, a regression is a regression, is a regression :)
<apw> vanhoof, well thats not what policy says even if you are right
<herton> apw: only the breakage by its fix
<apw> ok so its broke in -updates and without the fix its broke in -updates, so i am wondering why we are sitting there waiting for upstream to possibly maybe fix it, rather then either reverting or releasing
<herton> apw: now I'm confused. 791752 doesn't look a regression, but a bug in natty. the fix for it brought a regression (bug 814325)
<ubot2> Launchpad bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Incomplete] https://launchpad.net/bugs/814325
<ppisati> smb: yeah, if i keep this pace, sooner or later i'll find the right bug :)
<smb> ppisati, And the panda won't jump into ones face when trying a simple upgrade... :)
 * herton -> lunch
<tjaalton> herton: exactly, the -proposed fix is for 791752, which affects every SNB machine using the built-in gfx. and what vanhoof said
<tjaalton> ah, gone
<apw> tjaalton, right but they are broken already, and not having the fix doesn't change that
<vanhoof> apw: also as a side note, the regression introduced exists in 3.1 mainline as well
<vanhoof> apw: worth noting, its not natty specific
<apw> vanhoof, yes but its not in the kernel in -updates
<apw> so you have to have a really good reason to introduce that regression to those users
<vanhoof> apw: fair enough, we'll see what more we can turn up today, and I'll update you all again on where we stand
<vanhoof> right now its not clear if its limited to the T510 + hybrid graphics + intel as default gpu OR arrandale + hybrid graphics + intel as the default gpu
<apw> so we have no idea as to the size of the regression, thats not a positive
<vanhoof> well we have a decent sizing, however this configuration isn't exactly prevalent, so a bit tricky to track down testers
<vanhoof> I can tell you everything else is not exposed ;)
<vanhoof> give us the day to see what more can be turned up, and we can take it from there
<jjohansen> so my 7 year rode his bike into a tree on the morning running, its been an interesting morning so far
<smb> jjohansen, hopefully not too badly ran into it. Kid and tree surviving?
<jjohansen> smb: yeah, the tree got the better of him, though I must say from the moaning he is still doing he thinks he is dying
<jjohansen> really just a few good scraps, nothing quite as good as his face plant though
<apw> jjohansen, heh, as long as he doesn't start throwing up
<jjohansen> apw: yeah, that would make things worse
<smb> jjohansen, I guess it can feel rough. Though its sometimes hard to say where the pain stops and making use of the situation starts...
<jjohansen> oh I am pretty sure he is into the making use of the situation
<jjohansen> his moans got quite a bit loader when mommy came in :)
<smb> jjohansen, Help, this wound needs a substantial amount of sweets to mend. :)
<jjohansen> hehe, yeah
<apw> jjohansen, heh typical, tells you he is fine then
<apw> jjohansen, you need some "well if you are sick we can't have <favourite dinner>, it'll have to be gruel"
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0 || Ubuntu Kernel Team Meeting - August - 23 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jjohansen> apw: sadly he already know what dinner plans where for the night, but perhaps we can use dessert as the lever :)
 * smb -> gone
<kobrien> Evenin'. I'm trying to boot kernel version 3.0 under Ubuntu 11.04 amd64. After I select it in grub, I'm presented with a purple splash which never goes away. I never get further than this. Any ideas on how to fix?
<apw> kobrien, you'd want to turn of graphical splash and see if if you can get some diagnositics
<apw> kobrien, which would be editing the command line in grub2, change the =$linux_gfx_mode for =text and then remove quiet splash and replace that with debug
<apw> kobrien, oh and the vt.handoff=xxx bit as well, get rid of that
<kobrien> apw: thanks, I'll try that now
<apw> ogasawara, ok i've just pushed a major update to the devel config summary tools for use for next UDS
<ogasawara> apw: awesome, was actually just going to start shoving bits in a wiki for some of the P specs
<apw> ogasawara, we need some work on the OVERRIDES which i'll try and do a bit of tomorrow
<apw> ogasawara, but we only shove it in raw anyhow.  once you have the config blueprint and spec i can shove in an early one from your tree
<ogasawara> apw: cool
<ogasawara> apw: I'm also not sure how much more of the module config review I'll be able to knock out between now and kernel freeze, so I'll likely carry that over to P as well
<apw> ogasawara, well, i am inclined to think of things out of policy as a bug, so not really subject to the freeze
<ogasawara> apw: most are usually powerpc changes, so as long as it builds I'm not too worried.
<apw> ogasawara, even more so as they are only a ports port
<ogasawara> apw: I was also going to ask if we should rip out the ppc64 bits
<ogasawara> apw: as I recall that was a one time thing for natty?
<ogasawara> apw: or is there value for us to carry that along
<apw> ogasawara, there is a possibility we may need then i suspect, and they are easier keep in and maintain as we go through the rebases
<apw> we should definatly drop them in 12.04 if we've not used them by then
<ogasawara> apw: ack, definitely no pain in carrying them, I hardly notice most of the time
 * tgardner --> lunch
<ogasawara> apw: https://wiki.ubuntu.com/KernelTeam/Specs/KernelPConfigReview - empty spec template for now, but feel free to throw any bits there
<apw> ogasawara, will do
<apw> ogasawara, initial update in the spec
<ogasawara> apw: ack, thanks
<apw> i'll try and remember to update it regularly going forward
<herton> tgardner: are you still looking at  the chromium lockup on lucid? I'm curious if with environ patch not reverted, but with the oops fix applied we still get a hang, and if yes, if it's on kernel (sysrq-w could help). Only place I can see it could may be deadlock because of that patch, would be getting the cred_guard_mutex, or task_lock inside get_task_mm (although get_task_mm was being used before in environ_read)
<tgardner> herton, I was able to get both symptoms, the lockup as well as the oops. I could try just the oops fix just to be sure.
<herton> I think would be good to check, just in case
<apw> tgardner, if you could let me know any testing results there as i have looking at why thats bust tommorrow on my list
<tgardner> apw, k
<herton> tgardner, apw: the oops fix (commit 76597cd upstream) should go into natty master-next as well. hardy doesn't need it, checking here the backport doesn't patch m_start with ERR_PTR
<herton> do you think I should see with sconklin and respin the lucid/maverick kernels, or can we wait? (I would respin maverick with the oops fix, and lucid with the revert + oops fix)
<tgardner> herton, lemme verify lucid first
<tgardner> herton, oops fix applied to natty
<herton> ack
 * jjohansen -> lunch
 * ogasawara wonders who won the race to push to the repo, me or tgardner 
 * ogasawara guesses I won since I had no conflicts
<tgardner> ogasawara, I'm thinking you did too.
<tgardner> ogasawara, but I also pushed an updateconfigs commit afterwards
<ogasawara> damn, I thought I ran an  updateconfigs after rebasing
 * kamal is cheering at the finish line \o/ in celebration of mjg59's backlight patch finally landing!
<kamal> tgardner, ogasawara: thanks!    mjg59: super-duper-ultra-bright-thanks!
<apw> tgardner, was it you who was complaining about the two handed alt-tab alt-down thing ?
<tgardner> ogasawara, seems like you just did 3.02, and now greg has already released 3.0.3
<ogasawara> sheesh, already?
 * ogasawara rebases
<tgardner> apw: not me. that would imply a sophisticated use of the keyboard.
<apw> must have been jjohansen :)
<jjohansen> yeah I hate that
<jjohansen> I do complain about it almost daily lately
<jjohansen> what I really hate is unity not letting me turn it off, even when resolving conflicts in ccsm
<apw> jjohansen, well ccsm does have a keybinding for it, and moving it to alt-` seems to be _much_ less annouing
<jjohansen> apw: hrmm I hadn't thought about that
<jjohansen> now if I could only get to ccsm, unity layering issues strick again
<apw> jjohansen, i think thats the osx binding :/
<jjohansen> s/strick/strikes/
<jjohansen> apw: how am I not surprised
<jjohansen> apw: that is much better thankyou
<apw> jjohansen, yeah at least one can single digit it
<apw> though this thing shows empty spaces for iconified windows ... sigh
<jjohansen> ewww
<apw> jjohansen, i have filed like 8 bugs in two days :(
<jjohansen> apw: yeah I keep finding them because you beat me to filing them
<tgardner> herton, I've backed out the revert for CVE-2011-1020 on Lucid. It appears that that the oops fix is the right patch.
<ubot2> tgardner: The proc filesystem implementation in the Linux kernel 2.6.37 and earlier does not restrict access to the /proc directory tree of a process after this process performs an exec of a setuid program, which allows local users to obtain sensitive information or cause a denial of service via open, lseek, read, and write system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1020)
<herton> tgardner: oh, cool. So I think we can go forward then and respin just with the fix, and hardy shouldn't be affected and can be released
<tgardner> herton, correct
<herton> ok, I'll "reopen" hardy tracking bug etc.
 * tgardner -> EOD
<apw> herton, thats good news, the revert not being required, just the extra fix ... 
<herton> yep
<jjohansen> rebooting
#ubuntu-kernel 2011-08-18
 * apw yaws
 * apw pitches
 * apw rolls
 * amitk pulls back the rudder
 * apw hears "pull up, pull up"
 * amitk sucks at flight simulator and promptly crashes the plane
 * apw was ok on the bbc back in the day... flying under the bridge upside down was tricky
<cking> heh, I learnt my flying skills in Elite
<apw> cking, :)  that bbc flightsim had a lot of hours of my time
<cking> the wonders of 3d wireframe graphics on the 6502...
<apw> yeah amazing
<apw> and their GPU was a dac
<cking> I hacked up a 6502 line drawing routine that could pop out pixels in 98 cycles
<cking> those were the days...
<cking> sigh
<apw> heh yeah :)  old bugger
<_ruben> 6502 .. that's c64'ish?
<_ruben> been too long, and am not too old yet :p
<apw> _ruben, that era yes.  when computing hit the home for the very first time
<cking> when one could get a lot done in 1K of assembler..
<apw> a scarey thought indeed, when your logout button takes up more RAM than you had space on all of your disk media
 * apw is pretty sure his first hard drive in his PC was 15MB, and the OS and something useful fit on it
 * gema thinks this is starting to feel like a kernel channel now :D
<_ruben> i recall picking up our first pc with my dad .. a laser xt .. the question was to go witha 20MB hdd or no hdd
<_ruben> and my dad upgrading our PET from 64KB to 128KB ram orso .. for 500 bucks .. hadda solder out the old mem chips and replace 'em with new ones :)
<apw> heh, the days when you could see the pins on chips
<_ruben> apw: fair point :)
<_ruben> the good ol' .1" spacing
<ppisati> can i have a faster kernel.ubuntu.com for christmas?
<apw> ppisati, heh ... she a little reticent to do what you want ?
<smb> ppisati, Depends on how many times your sudo attempts fail
<cooloney> ppisati: how's your speed to k.u.c
<cooloney> ppisati: for me, sometimes 3k
<smb> Sounds as fast as from the hotel last week...
<soren> That's impossible. It's git, so it doesn't care about bandwidth. It just sprinkles more pixie dust on the bits and bytes and then magically makes everything faster.
<ppisati> i'm not talking about network, it's jst that gitweb is so slow...
<ppisati> btw, in the last few days since i upgraded to the latest kernel, after 3/4 hours of work. my trusty ps/2 dies
<ppisati> and i've to reboot to make it work again
<ppisati> did anyone experience this before?
<apw> ppisati, nope all stable here
<smb> Neither before nor after...
<ppisati> :(
<apw> ppisati, but what release you running on it
<ppisati> Linux newluxor 3.0.0-8-generic #11-Ubuntu SMP Fri Aug 12 20:23:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
<ppisati> oneiric
<ppisati> i update it every morning
<smb> adventourous
<ppisati> :)
<ppisati> in fact half of the desktop is broken
<ppisati> btw, this usb eyboard sucks
<smb> Seems to have lost its k... :)
<apw> ppisati, well there is known death in the archive right now, see ubuntu-devel@ for details
<smb> shoot, and I just upgrade a test system...
<apw> smb, kiss it goodbye
<smb> apw, Definitely should not try to reboot it... :-P
 * smb wonders whether it is Friday already...
<apw> the end of something :)
<cking> heh, I updated my lap-top 10 mins ago and it's working OK
<smb> cking, For me, apport seems to be one of those packages not really happy
<cking> however, typing seems really laggy on the desktop - it's as if something is getting in the way
<apw> cking, i think you should show that to colin king he is great at fixing those toughies
<cking> apw, that's just a rumour, anyhow colin king is busy at the mo
 * cking double checks his US visa paperwork. gah, I dislike paperwork
<ppisati> VISA?
<cking> the ESTA stuff
<ppisati> ah ok
<cking> it's just a faff remembering my number, putting in hotel and flight info.
<smb> Isn't that supposed to be no *paper* work?
<cking> it's paperwork in electronic form IMHO
 * smb never does update the thing. somehow I got in anyways...
<smb> Maybe its the reason they ask for the hotel and stuff again after putting the same information into the online checkin (which of course gives you no boarding passes because you could be lying)
<apw> cking, putting in what ?
<apw> cking, you do know you don't have to do that right ?
<smb> apw, In theory you have to update your esta thingy everytime you travel to the us
<apw> smb, thats not what it said when i applied.  it said the info was optional (hotel)
<cking> well, I like to update it because they may do something nasty to be if I don't. being paranoid as usual
<apw> and i've never updated mine
<apw> maybe i am meant to. bah
<smb> Me neither, but the travel agency brought it up last time
<smb> Apparently its optional for the allowance
<apw> for the allowance ?
<smb> but you should (if you are nice) update it when you know
<smb> apw, wrong work maybe
<smb> allowing you in
<smb> word
<cking> they allow apw in?
<apw> ahh i see, for the permission perhaps
<apw> not if i am with _you_ no
<cking> ha
<apw> ahh gads, i've just realised, you and scott will be in the same place
<smb> cking has done every bit required, of course he *must* be a terrorist
<cking> yep, but we won't be travelling on the same plane, therefore it's OK
<cking> things only go pear shaped when scott and myself travel on the same plane/train/taxi/etc
<apw> cking, you claim ...
<cking> assert(trip_cking == trip_scott);
<smb> not !=?
<apw> yeah
 * smb thinks there should be a tripit travel warning if that happens
<apw> though cking hides from tripit
<smb> Even more reason to get him some glove treatment (apart from acting suspiciously unsuspicious)
<cking> very funny
<cking> smb, you saying if I act weird then I'm OK?
<smb> cking, Of course, only people that want to do evil would not want to stick out, wouldn't they? ;)
<cking> smb, I'm doomed
<smb> cking, Too normal for the world. But I guess travelling with apw cancels out that a bit... :-P
<cking> quite a bit
<cking> only another 34 fwts tests to document.. sigh
 * ppisati -> lunch
<smb> ppisati, A sec
<ppisati> smb: what?
<smb> ppisati, Just to confirm (since I got some mails about subscriptions to those) you got the tracking bugs for arm topic branch prepeartions too?
<smb> bug 800234 and 8000235 just in case not
<ubot2> Launchpad bug 800234 in gwibber "gwibber-accounts crashed with URLError in do_open(): <urlopen error [Errno -2] Name or service not known> (dup-of: 728844)" [Undecided,New] https://launchpad.net/bugs/800234
<ubot2> Launchpad bug 728844 in gwibber "gwibber-accounts crashed with URLError in do_open(): <urlopen error [Errno -2] Name or service not known>" [Medium,Invalid] https://launchpad.net/bugs/728844
<smb> errr
<apw> heh those are not even close specially the second on
<smb> forget it... there seems to be something with wastagin in it...
<apw> one
<smb> apw, Yeah, I think I got some test runs
<apw> bug #8000235
<smb> But did not realize
<smb> bug 800235
<ubot2> Launchpad bug 800235 in firefox "firefox addons web page is not opening just it keep loading" [Undecided,New] https://launchpad.net/bugs/800235
<apw> oh i see its actually reading its _own _ output
<smb> See
<smb> apw, Well the numbers I saw are not valid in the "real lp world"
<apw> bug 800234
<ubot2> Launchpad bug 800234 in gwibber "gwibber-accounts crashed with URLError in do_open(): <urlopen error [Errno -2] Name or service not known> (dup-of: 728844)" [Undecided,New] https://launchpad.net/bugs/800234
<ubot2> Launchpad bug 728844 in gwibber "gwibber-accounts crashed with URLError in do_open(): <urlopen error [Errno -2] Name or service not known>" [Medium,Invalid] https://launchpad.net/bugs/728844
<smb> Oh you mean that
<smb> Yeah
 * smb wonders what would happen if a bug title contained its own number again...
<ppisati> smb: actually no
<ppisati> smb: did yu receive just now?
<smb> ppisati, No, I saw some but there were done in the staging system. I got one for ec2 for real, but maybe they just did not get that far for the fsl et al
<ppisati> dunn
<ppisati> i had some emails about the tracking bugs for the different arm topic branches
<ppisati> but didn't receive it right now
<smb> Those would be the ones. With "version to be filled". Those would have come yesterday
<ppisati> ah ok
<ppisati> yes, got them
<smb> I just got confused by the test ones
<ppisati> bt i didn't have anything to push
<smb> For ec2 it was at least the rebase (and actually needed one upstream patch to be brought into the file clones)
<apw> ppisati, do you not do the mvl-dove rebases when they are needed
<ppisati> apw: last time they did it
<ppisati> apw: uhmmm...
<smb> ppisati, You saw that email about passing of things to us, did you? :)
<apw> ppisati, ok then they may be happy doing so, probabally worth asking who is responsible in case they fall through the cracks
<ppisati> apw: maybe i did the rebase, and they closed the release... don't remember exactly...
<ppisati> ok
<ppisati> smb: you mean the "Updates on topic branches" mail, right?
<smb> yep
<ppisati> smb: yes, but i think i forgot it... :)
 * ppisati goes to reread it...
<apw> ppisati, thanks for your feedback on those arm patches ... they have been hangin about for a while.  am happy to carry them if we need to but we don't "know" anything about they at the moment
<smb> apw, On related topic, was I able to clarify the libbfd confusion?
<apw> not seen your reply yet, i am "better" at my email now, but not great
<ppisati> apw: ye, let's see what sakoman says
 * smb was hoping... :-P
<apw> ogasawara, on burndown, we seem to have two sets now, the pitti ones we've used for sometime, and now the new status.ubuntu.com ones.  There hwe is split out and on the kernel ones we are: http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-kernel-tasks.html
<apw> ogasawara, and there we are below the line!
<Daviey> Reset the trend line, simples.
<apw> Daviey, no they are genuine trend lines, its whats included and whats not that gets us there
<apw> the status ones split kernel into kernel and hwe and its hwe who are behind :)
<apw> but nothing they are doing is release critical so we don't really care if they are behind
<tgardner> ppisati, uploaded the meta package for linux-ti-omap4 3.0.0-1202.6 and sent announcement.
<ppisati> tgardner: ok, thanks
<ppisati> smb: it's still in demo-mode, right? i mean the new trackign bug etcetc
<smb> ppisati, The ec2 one was real. Have not looked out for any other.
<ppisati> i've 2 mvl-dove tracking bugs, bt they say "Ignore this bug"
<ppisati> and one on bugs.qastaging.launchpad.net
<ppisati> ok, i'll ask the SRU when they apper
<ppisati> *SRU people
<smb> Hm, one of the ec2 ones went to ignore as well
<smb> yeah, they should know
<herton> ppisati, smb: yep, they were closed because we are respinning today lucid and maverick kernels
<ppisati> ah ok
<ppisati> btw, in case i've noting to push, wat do i have to do?
<herton> so just ignore them for now, you will get new bugs after the new kernels are built again
<smb> herton, Seems only one. I've done a rebase to what was in lucid-master
<herton> ppisati: if you don't have anything to release, I think you can just close the bug, invalidating everything (you can do with check-release-tracking-bugs --bug=<n> --invalidate)
<herton> smb: if you rebased that's fine, but you will have to rebase again, I'll push to master a fix to a CVE patch that brought a regression
<smb> herton, Not a problem just more work. Would have been good then to have both tracking bugs marked as, please ignore... :-)
<herton> smb: you mean the master lucid bug? it could be done, I just set it as a duplicate of the new tracking bug
<smb> herton, No I mean the two ec2 tracking bugs
<smb> bug 800236
<ppisati> i've to disappear for half an hour
<ppisati> brb
<apw> smb, luckily the second rebase should be a slam dunk :)
<smb> apw, yeah
<smb> Argh
<herton> smb: 800236 doesn't find any bug here
<smb> herton, You really confuse people with those qastaging versions
<herton> smb: ah... I used qastaging for testing, everything on qastaging should be ignored :)
<smb> herton, Tell that the bug mailer... :-P
<herton> smb: hmm, I don't know how qastaging is setup, I thought it shouldn't sent any emails, weird. Never received emails from it, pehaps it's broken for direct people assignments, who knows
<smb> herton, It seems so. And unfortunately the mails look completely like real ones. Just with qastaging in the link. :/
<herton> ppisati, smb: so just wait for new tracking bugs, they will be opened when the packages are built, nothing to do until then. I'm going to get sconklin review the new releases today and then do the upload, the bot will open the tracking bugs when everything is built.
<smb> herton, ack
<ogasawara> apw: \o/, I'll update our status wiki's to point to the status.u.c burn downs
<apw> ogasawara, :)
<apw> ogasawara, what did we decide about SECCOMP (mode 2) in the end
<ogasawara> apw: I'm waiting for an updated pull request as it currently breaks the build on arm
<apw> ahh yes, i remember now.  cool
<tgardner> ogasawara, apw: I'm thinking it won't make the cut since its gonna take  a major revamp to get it working on ARM
<apw> tgardner, might there be value to having it availabe on x86.  it sounded like chromium was committed to using it
<tgardner> apw, perhaps. in that case we should use it as is and disable for armel ?
<apw> tgardner, that was kinda my thinking.  arm is marjinal for users right now
<tgardner> apw, don't say that too loud. you'll have ogra_ crawling all over you.
<apw> :0
<ppisati> back
<apw> ogasawara, we normally say EXPERIMENTAL =n, but for filesystems, sensors, etc we tend to say "but they are opt-in and we want them enabled for testing" ... does that sound about right?
<ogasawara> apw: yep
<apw> ok so i am going to code that in, i am thinking filesystems, sensors, hid, netfilter things
<apw> as a first set of exceptions
<smb> cking, I now see what you meant with lagging. Seems every keystroke ponders about something. And trying to move a window my mouse pointer is at the target before the window even considers to move...
<smb> cking, Have you reported that already?
<apw> smb, see if you have kworker threads eating your machine
<apw> that sounds liek the symptoms i had when that was occuring
<smb> apw, Now compiz is using 8%cpu even when idling
<smb> apw, Only have a few kworkers and they do not show up prominently in top
<apw> smb, 2-3% on my netbook on oneiric
<smb> apw, consistently between 8 and 10 on a dual core dell...
<cking> smb, not yet
<smb> apw, Its ati gfx
<apw> smb, slightly more when there are stupid OSDs on the screen
<apw> smb, ok, i don't have those
<smb> apw, btw bug 828737
<ubot2> Launchpad bug 828737 in ubuntu "The iconify and de-fullsize buttons are barely noticable" [Undecided,New] https://launchpad.net/bugs/828737
 * apw confirms it
<cking> wow, just moving a window makes compiz consume 12%  of my CPU
<apw> cking, it must be falling back to doing something by hand
<smb> cking, What gfx card do you have?
<apw> does unity 2d work any better
<cking> smb, an old ATI Radeon X1300
<smb> cking, May be a pattern as apw does not see it. I got some ati card as well
<smb> An X1200
<cking> smb, since pulling in some updates this morning it feels less laggy
<smb> Hm, I just pulled the latest stuff
 * smb does not want to know haw it was
 * cking tries 2d
<cking> yep, 2d much snappier
<cking> still, moving a window gives 10% CPU loading
<cking> and terminal feels more responsive when typing - although the is a tad subjective
<cking> terminal resizing is a pain when you have wobbly touchpad input
<smb> cking, bug 828752
<ubot2> Launchpad bug 828752 in compiz "Very slow responding system (compiz/ati?)" [Undecided,New] https://launchpad.net/bugs/828752
<cking> smb, you verified this with 2d to see if it does the same?
<smb> cking, not yet. doing now
<smb> cking, Hm so compiz is not right... its the same in 2d but without any process to blame directly
<smb> though the typing is quicker
<cking> so it looks to me like the keyboard is being read in a timely manner, but rendering it is taking a while
<cking> do you see a lay when you switch to a text console?
<cking> s/lay/lag/
<cking> doh
<apw> or s/lay/delay/
<smb> cking, no, just on the way backl
<smb> cking, But actually typing text is rather normal in 2d (I had a one sec delay before a key typed would appear)
<smb> Just dragging windows feels like they are unwilling
<smb> Btu maybe that is a new feature...
<cking> sluggish windows a good feature?!
 * smb did not say good
<smb> It feels as "good" as that for a restart you now have to click shutdown and then restart...
<tgardner> apw, do you remember how to change the I/O scheduler ? I'm thinking a HW RAID controller doesn't need any kind of elevator sorting.
<vanhoof> tgardner: system wide, elevator= in grub, believe on a per fs basis somewhere in sys
<tgardner> vanhoof, I remember that there is a sysfs knob, but can't remember the name
<vanhoof> tgardner: /sys/block/sda/queue/scheduler
<apw> tgardner, i think its per device in sysfs
<apw> tgardner, i will be supprised if no elevator is going to be better unless its to IO merging
<apw> but i assume you are going to measure
<tgardner> apw, how can it know if its talking to a HW RAID controller with 8 spindles ?
<apw> tgardner, it can't know, but sending lots of small IO's may not be an improvement over at least merging things nearby
<apw> tgardner, but i am all for trying it
<tgardner> apw, I'm just watching this Emerald idle along with 10-15 processes running and 1350 sleeping. wtf ?
<Guest3769> cking: Nope, no lag here!
<apw> tgardner, i would very supprised if that much CPU couldn't kill almost any ammount of disk you add
<cking> Guest3769, very droll
<tgardner> apw, but only 10 processes running? I'd think a high end RAID controller could keep things busier then that.
<apw>  tgardner i am keen to see if changing it helps any, try the others if not too
<apw> tgardner, my experience is if there isn't battery backed front end cache on the controller then its not going to like random IO
<tgardner> apw, I'm only seing write speeds in the 5M/s range, well below what its capable of.
<smb> I actually think even noop does merging. But I am not sure that the other elevators still take any geometry assumptions
<apw> and bear in mind this is a write heavy pattern, which is usually hindered by any sort of raid 5 type raid
<apw> as we have to write more than one sector for each sector, and often have to cut up the IO into smaller chunks
<tgardner> I wonder if there are any white papers on how to tune for HW RAID
<Guest3769> cking: :D
<Guest3769> cking: lag is in Africa 
<apw> that is a goog question
<apw> good
<tgardner> apw, I think 'goog' is apropos :)
<apw> tgardner, heh i did chuckle at my own typo
 * ogasawara back in 20
<awolfson> Hi all. Are there any plans to include utrace support in onerick?
<apw> if that is extra kernel patches then its not in now, and unlikely to be
<apw> ogasawara, ok i've done the bulk of the annotations for the P config review we should ahve far fewer oddnesses in the session now
<ogasawara> apw: awesome, thanks
 * tgardner disappears into his server room
<apw> ogasawara, i have just found an NETFILTER match which is inconsistant on O, it really should have been caught in the review, so i am proposing to just fix it and push it up, that ok ?
<ogasawara> apw: go for it
<apw> now that there are not 1000s of inconsistant entries its easier to find the ones one should worry on
<apw> ogasawara, done
<apw> ogasawara, also pushed it to u-p, i note that uses master not master-next ... which is a little odd
<ogasawara> apw: yah, I didn't make master-next yet since I didn't think there'd be much conflict in pushing
<ogasawara> apw: but will do so now
<apw> ogasawara, i more think of master as 'whats released' and master-next as 'next stuff'
<apw> so we almost could not have a master in there
 * ogasawara migrates back to the office
<jpds> Can someone take a look at https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/795823 ?
<ubot2> Ubuntu bug 795823 in alsa-driver "Dell Studio XPS - Internal Microphone not Working " [Undecided,Triaged]
<jpds> I can confirm that the model= workaround works.
<apw>  /whois jpds
<jpds> apw: Oh hi.
<apw> hi, i've pushed it over to the kernel, as it will need a quirk
<apw> jpds, you do need to confirm that abolutly everything all the holes and jack detection etc works with that model=
<apw> if you can do that and report it in the bug
<apw> (not just the one mic you are trying to fix)
<jpds> apw: I'll test it and see.
<apw> jpds and your machine isn't the one listed on that bug
<apw> (or is it)
<diwic> jpds, can you please file a new bug for your issue with "ubuntu-bug audio"? (As hw might not be the same)
<diwic> jpds, and do so in a state where you're trying to record from the internal mic
<apw>         SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02fe,
<apw>                                 "Dell Studio XPS 1645", STAC_DELL_M6_BOTH),
<apw> it seems there is already a quirk to a different setting for that machine
<diwic> aha
 * apw hands over this one over to diwic :)
<diwic> we had the same problem with dell studio 1558
<apw>         SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413,
<apw>                                 "Dell Studio 1558", STAC_DELL_M6_DMIC),
<apw>         SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413,
<apw>                                 "Dell Studio 1558", STAC_DELL_M6_DMIC),
<apw> yeah we have _two_ entries for that puppy
<diwic> oh, anybody want to have their name in the kernel? Some low-hanging fruit here :-)
<apw> oh no that is my incompetance, i'd copied it to add the new one before i dicovered it was already there
<apw> diwic, ok this 1645 was only set to STAC_DELL_M6_BOTH cause a reporter said it worked, they may have never tested the mic
<diwic> apw, m6_both creates two mics whereof one does not work, and so user gets confused
<diwic> apw, it would be good to have jpds alsa-info or apport info to see if that's the case
 * apw pokes jpds
<apw> ogasawara, can you make "
<apw> UBUNTU: Stop ARM boards crashing when CUPS is loaded" (no-up) on your next rebase please
<ogasawara> apw: yep
<apw> ogasawara, then thats lag's patched done and dusted, i've closed that WI
<ogasawara> apw: sweet
<apw> tjaalton, hey you have a patch hanging around on our tree, and we are wondering if it is going upstream or ... "UBUNTU: SAUCE: Added quirk to recognize GE0301 3G modem as an interface"
<tjaalton> apw: yeah I got a ping about it while on vacation, and actually refreshed my tree to create a patch for upstream, but didn't finish it yet :)
<apw> tjaalton, so can i say "its upstreamable and timo is sorting it out as time allows" ?
<apw> as i think from the review point of view that means keep it till it collides on rebase which is fine
<tjaalton> apw: yeah, I believe it's still a valid patch
<apw> tjaalton, thanks :)  i call that reviewed
<tjaalton> cool :)
<apw> ogasawara, we should look a lot better in a few
<ogasawara> apw: indeed.  I think we only have one work item left for the delta review now.
<apw> ogasawara, two i think, both inprogress
<ogasawara> apw: heh, I overlooked yours
<ogasawara> apw: so I'm going to rip out master from P for now
<apw> ogasawara, yeah always me, sigh
<apw> ogasawara, works for me
 * apw bails
<Sarvatt> mdeslaur: building a kernel now with what jbarnes posted on the fdo bug
<mdeslaur> Sarvatt: cool, thanks
<Sarvatt> mdeslaur: amd64 or i386?
<mdeslaur> Sarvatt: please build it for oneiric, I'm on oneiric now
<Sarvatt> oh, ok
<mdeslaur> Sarvatt: I couldn't postpone updating any longer :)
<Sarvatt> mdeslaur: http://kernel.ubuntu.com/~sarvatt/fdo40172/
<mdeslaur> Sarvatt: cool, thanks, give me a few minutes
 * tgardner is off to buy a house.
<sforshee> cnd, you around?
<cnd> yep
<sforshee> more touchpad questions for you :)
<cnd> ok
<sforshee> in reference to this: http://pastebin.ubuntu.com/669405/
<sforshee> it seems like the ABS_[XY] report in the last packet is making utouch's drag or flick detection get confused
<sforshee> since their 0, it detects an upward flick
<sforshee> but the buttons are being released
<cnd> hmmm, our stack doesn't look at ABS_{X,Y}
<sforshee> so is that a driver problem (the driver shouldn't send the position) or a utouch problem?
<sforshee> really?
<cnd> it looks at ABS_MT_POSITION_{X,Y}
<sforshee> because if I modify the driver so that those aren't sent, there's no upward flick at the end of my downward drag
<cnd> hmm, maybe for semi-mt devices it looks at ABS_{X,Y}
<cnd> we should check out the code of utouch-frame
<cnd> (which I'm currently rewriting :)
<sforshee> I'd think since BTN_TOUCH and BTN_DOUBLETAP are released in that frame, it should ignore the position
<sforshee> this is something I'm encountering in testing the driver changes elantech sent earlier
<cnd> ahh
<cnd> what are you using to test touch?
<cnd> to test utouch* that is
<sforshee> I have an oneiric install, and I'm just testing drag-to-scroll in various application windows
<cnd> sforshee: is ginn running?
<cnd> ps aux | grep ginn
<sforshee> nope
<cnd> ok, good
<cnd> so outside of a development version of ginn, we don't do scrolling through utouch (yet)
<cnd> so this is an issue in xserver-xorg-input-synaptics
<sforshee> oh, okay
<cnd> though it's in the code that I added
<cnd> :)
<sforshee> at least I'm asking the right person then :)
<cnd> well, actually, maybe not
<cnd> let me try to remember
<cnd> yeah, I don't think I touch scrolling
<cnd> that's still handled through ABS_{X,Y} and BTN_TOOL_DOUBLETAP
<cnd> which would explain why this is throwing things off
<cnd> really, the driver shouldn't be emitting ABS_{X,Y} of any value when BTN_TOUCH is released
<sforshee> that's what I was thinking
<cnd> so I would consider that a bug
<sforshee> but
<sforshee> it's pretty trivial to not send them from the driver too, so I'll probably suggest they make that change
<sforshee> not that the bug shouldn't be fixed :)
<cnd> hmm?
<cnd> I think we're talking about the same bug
<cnd> the driver should be fixed
<sforshee> sorry, didn't read carefully enough (trying to multitask...)
<cnd> if you mean that synaptics shouldn't be using an X and Y event when BTN_TOUCH is released
<cnd> well, that would be great too :)
<cnd> but it shouldn't have to check that
<cnd> sforshee: thanks for testing it out!
<sforshee> either way, I'll just tell them to fix it in the driver
<sforshee> cnd, thanks!
<mdeslaur> Sarvatt: unfortunately, I can still reproduce
<Sarvatt> mdeslaur: darn.. mind commenting that on https://bugs.freedesktop.org/show_bug.cgi?id=40172 ?
<ubot2> Freedesktop bug 40172 in DRM/Intel "[arrandale] Fuzzy screen after dpms cycles on lenovo t510 [bisected, 3.0+]" [Normal,New]
<mdeslaur> Sarvatt: just did
<Sarvatt> thanks a ton!
<mdeslaur> np
<cnd> sforshee: in return you can help jog my memory
<cnd> how do I build the generic kernel from git
<cnd> fdr clean
<cnd> fdr binary-image (but I know there's something to select just generic)
<sforshee> fdr binary-generic
<sforshee> is that what you want?
<cnd> ahh, yes
<cnd> is there still an env var to make it not build the dbg package?
<sforshee> no, you have to give a var in order to get the dbg package built
<sforshee> by default it doesn't build the dbg package
<cnd> ahh, that's a change from when I last built stuff
<cnd> what about building with make -j16?
<cnd> do I need to do anything special?
<cnd> nm, I see it did it automatically
<sforshee> just what I was about to say :)
<sforshee> I don't know how to override the decision the scripts are making tho
<sforshee> wrt how many jobs to use, that is
<Sarvatt> DEB_BUILD_OPTIONS=parallel=16
<sforshee> Sarvatt, thanks!
<cnd> hmmm, I'm trying to rebuild the 3.0-0.1 kernel but I get the following:
<cnd> WARNING: drivers/built-in.o(.data+0x1c898): Section mismatch in reference from the variable ab3550_driver to the function .init.text:ab3550_probe()
<cnd> The variable ab3550_driver references
<cnd> the function __init ab3550_probe()
<cnd> If the reference is valid then annotate the
<cnd> variable with __init* or __refdata (see linux/init.h) or name the variable:
<cnd> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
<cnd> anyone seen this type of error before?
<sforshee> cnd, I see those sometimes, but I didn't think it caused the build to fail
<cnd> maybe it's something else
<cnd> ugh
<sforshee> probably, looks like ab3550_probe shouldn't be marked __init but the build shouldn't fail as a result
<cnd> something else, but I'm not sure how to fix it
<cnd> I'll have to play a bit
 * ogasawara goes out for lunch, back in a bit
<cnd> stupid rtl driver
<cnd> glad we got rid of it
 * jjohansen -> lunch
#ubuntu-kernel 2011-08-19
<adam_> hey I accidently deleted a folder under /usr/src
<adam_> and I want to put it back
<adam_> necessary for kernel development
<adam_> ...
<ohsix> dpkg -S /usr/src
<adam_> thanks... I think that's almost there, but it didn't put the folders back
<ohsix> that just gives you package names, you can reinstall the one you think was it
<adam_> oh! man
<adam_> I'm so dumb
<adam_> I should have known that. thanks man
 * apw yawns
 * cking offers coffee to apw
 * apw bites your hand off
<cking> remind me never to offer apw coffee first thing when he's grouchy
<cking> ;-)
<apw> heh
<apw> cking, i want to dump the comment section out of an elf binary, i'd like it just raw, suggestions as to what to use
<cking> hrm, must be doable from objdump somehow, surely?
<apw> cking, somewhat but it gives me <addy> <hex> <text wrapped every 8 characters>
<apw> and i'd rather not reconstruct it by hand
<cking>  readelf -p .comment a.out perhaps?
<apw> cking, readelf is easier to decode i guess ... sigh
<cking> sure, what are you doing to require this?
<apw> cking, i want to know what compiler was used to build the .ko in my hand
<apw> cking, as i want to check that all builds of a kernel were with the same compiler
<apw> cking, without booting them
<cking> ah, sanity checking. nice
<apw> apw@dm$ readelf -p .comment /lib/modules/3.0.0-5-generic/kernel/fs/squashfs/squashfs.ko 
<apw> String dump of section '.comment':
<apw>   [     1]  GCC: (Ubuntu/Linaro 4.6.1-2ubuntu2) 4.6.1
<apw>   [    2c]  GCC: (Ubuntu/Linaro 4.6.1-2ubuntu2) 4.6.1
<apw>   [    57]  GCC: (Ubuntu/Linaro 4.6.1-2ubuntu2) 4.6.1
<apw> so i think thats the nearest to a usable version string I have
<ppisati> just upgraded: now skype is broken, oh crap...
<apw> ppisati, nice
<RAOF> ppisati: Probably missing some i386 libs if you're on amd64?
<ppisati> RAOF: yep
<ppisati> [flag@newluxor ~]$ skype
<ppisati> skype: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory
<RAOF> ppisati: sudo apt-get install libxss1:i386; rinse and repeat until all the dependencies are satisfied.
<ppisati> RAOF: thanks, i'll try
<apw> RAOF, ahh is that multiarch finally coming into play 
<RAOF> apw: Yup.  ia32-libs lost a lot of weight in the last upload.
<apw> Fetching omap...extracting...GCC: (Ubuntu/Linaro 4.6.1-6ubuntu2) 4.6.1...done.
<apw> Fetching generic...extracting...GCC: (Ubuntu/Linaro 4.6.1-6ubuntu3) 4.6.1...done.
<apw> cking, omg, its caught one already
<_ruben> ohh .. that multi-arch stuff looks fancy :)
<cking> apw, how the heck does that happen?
<apw> compiler building in parallel with the kernel, and slightly ahead
<cking> gah
<apw> clearly the armel compiler built later (which given the speed of the builders makes sense)
 * cking --> dr appointment
<smb> Some morning make you want go straight back to bed... Just had to sweettalk the raid to ignore one lying device...
<apw> smb, ouch, how long before you have redundancy agian
<smb> apw, approx 139min
<apw> smb, and presumably its as slow as snot for the duration?
<apw> WARNING: inconsistant compiler versions detected
<apw> yay ... it works
<smb> apw, its okayish as it only tries to do that in the background
<smb> apw, Of course, when that is failing, the auto-rename of networking devices decides to fail as well. leaving you with a partially renamed one nobody likes... Ok, that was simpler to recover...
<apw> what the heck did you do to this machine ?
<apw> you did something odd like turning it on didn't you
 * smb thinks it may be that odd turning off before...
<apw> smb, does maint-get-abi use getabis at all
<smb> apw, Some mornings that machine is like me, but unlike me it cannot be cured by coffee
<smb> apw, no thinks its all re-implemented
<apw> have you tried coffee on the machine?
<apw> BAH now why would you do that
<apw> now someone will have to add the same compiler checks to that ...
<smb> apw, Because the previous implementation sucks. Isn't that the way it has to happen?
<smb> apw, Besides getabis would not be easily converted to not do it locally
<apw> well the sucking parts is that you have to run it locally, it runs remotly just fine, ie out of the tree
<smb> apw, Wait, compiler checks...?
<apw> smb, yes compiler checks, we have a WI to check the compiler, and doing that now, so i am fixing getabis
<apw> as that is the only time you have all the information you need
<apw> anyhow, maybe i'll fix maint-getabis to use getabis :)
<smb> apw, argh, hopefully not fixing python by perl code... :-P
<apw> sounds like a great idea to me
 * smb slaps apw
<smb> apw, But frankly where did that WI come from and what sense does it make to check any compiler for just getting abi information from built packages?
<apw> smb, well the work item is to know if we have compiler skew in our builds
<apw> and it just detected compiler skew in the latest oneiric stuff
<apw> smb, how does maint-getabis know which flavuors exist
<smb> apw, It checks the d-i information and has some internal blacklist to ignore stuff
<apw> smb, GAH, you complain about the current implementation and me putting perl in it ... and then you have a shell script embedded in it!
 * smb does not remember that...
<smb> It has been a wile
<smb> apw, So its probably not d-i but control.d
<smb> the vars stuff I believe
<apw> smb, and then another to extract it
<apw> this is basically the bits of getabis from the scirpt all cut up... i am wondering why we don't just send the getabis script from the current tree and use that
<smb> apw, Must have been that I just was learning python and had to do the job because I needed the money
<apw> heh maybe
<smb> apw, Maybe, though I am sure I just did not want to rely on variously broken or different implementations of getabi
<smb> You know how things evolve and how happy the sru team can be about fixing that kind of things
<apw> though with hindsight we should have fixed getabis
<smb> apw, Probably. Cannot say for sure now but I may have written this when we tried convincing people that debian.master backports are a good thing. You may remember how well that went. And I wanted it to be working for all releases.
<smb> apw, Would it be possible to have the check coded as its own script? Then we could at least call that from maint/build/*-getabis
<smb> if present
 * smb goes making coffee
<ppisati> yeah, my usb mic is broken... :(
<smb> ahh
<ppisati> i mean, it works
<ppisati> it's just that m installation is broken
<ppisati> :(
<ppisati> doh
<smb> all I can hear is something that sounds like a water fountain
<ppisati> that doesn't sound so good :)
<smb> apw, and if you don't know what we are talking about your mumble is broken too. :)
<smb> ppisati, I guess you heard me talking, though it would not surprise me today if my mumble was broken too
<ppisati> smb: i head something (i had music in background)
<smb> ppisati, So at least I make some noise...
<smb> :)
<illusec> Dear guys, what is deferences between ioctl and unlocked_ioctl in device driver programming, why ubuntu kernel doesn't support ioctl?
<illusec> differences"
<apw> illusec, as far as i know they are simply different APIs for ioctl, that they wanted to change the locking rules for ioctl handlers, so they added a new one and deprecated the old one
<apw> it is still the place that ioctl calls from userspace go
<illusec> aha, tnx
<bjf> apw, my unity is fixed, seems my solid background color was breaking it
<apw> bjf ... !
<bjf> apw, this was helpful: https://wiki.ubuntu.com/Unity/FilingBugs#Getting_a_stack_trace
<illusec> but i have a driver with ioctl, but when i change it to unlocked_ioctl for compile reasons the whole ioctls in source get me -1 ! 
<apw> bjf, are you saying having your own background broke it
<bjf> apw, now i have to make all my changes that were lost when i --reset
<bjf> apw, yes
<apw> do these guys test even the simplest things?
<smb> bjf, Oh your unity --reset actually works?
<bjf> smb, depends on your definition of "works"
<smb> Mine bails with an error message and does nothing
<bjf> now i'm trying to figure out where I set "focus follows mouse"
<smb> That was at least yesterday
<apw> bjf, is that in 'windows' control panel app
 * smb thinks that was set in generic config of compiz
<bjf> apw, can't find a 'windows' control panel app
<apw> illusec, well the syscall ioctl calls do_vfs_ioctl which calls vfs_ioctl which calls unlocked_ioctl
<bjf> apw, i'm looking at the "system settings" control panel
<bjf> but i thought it was in CCSM somewhere
<smb> bjf, I don't think it was in there
<smb> bjf, Yeah either that one or the full blown
<bjf> smb, "full blown" ?
<smb> bjf, I thought there was some simple config bla and the otehr one
<smb> I usually install the other one
<smb> And last time I looked there was a generic config option in that one, in the first block of things
<apw> bjf, its 'windows' application
<bjf> apw, there is an application whose name is just "windows" ?
<apw> hit the windows key and search for windows
<apw> see if that is the one
<bjf> apw, window == "super" ?
<smb> bjf, just out of interest, you have the "normal" intel gfx card, right?
<bjf> smb, yes, the i915
<cjwatson> I'm horribly confused.  Why does ecryptfs seem to be a module in 3.0.0-8.11
<cjwatson> ?
<cjwatson> despite debian.master/config/config.common.ubuntu:1402:CONFIG_ECRYPT_FS=y
<smb> bjf, Ok, so at least you won't be suffering the problem cking and I see where the whole gui seems to resist any of your actions
<bjf> smb, i don't think i have that problem
<apw> cjwatson, well what you ask for and what you get arn't always the same
<apw> cjwatson, if they added a dependancy on something wich isn't a module it can ripple up
<cjwatson> I have a d-i bug due to this - can I lob it over to the kernel and let you guys figure it out?
<apw> cjwatson, yes
<apw> cjwatson, whats the number
<cjwatson> cool, thanks, it's bug 827197
<ubot2> Launchpad bug 827197 in user-setup "/usr/bin/ecryptfs-setup-private fails with exit status 1 during install - User's home directory not encrypted" [High,Triaged] https://launchpad.net/bugs/827197
<cjwatson> thrown your way now
<bjf> apw, finally found it, it's in CCSM "general options"
<apw> bjf, sadly it is not sloppy focus
 * smb -> reboot after resync
<apw> bjf have you found a way to get sloppy focus rather than just follows mouse ?
<bjf> apw, not sure while i'm typing this my mouse pointer is not in the xchat window but over the desktop
<bjf> and now over the launcher
<apw> ok my test is " open two overlapping windows, cursor in the one behind, alt-tab to the other window (cursor is now not in the new window but still in the old), where is focus
<apw> under sloppy it would be in the new alt-tabbed to window
<bjf> hmm, seems to be working that way for me, alt-tab to xchat, mouse still over terminal window behind while i type this
<apw> so what are you doing different
<apw> you just flipped that one ticky in ccsm ?
<apw> oh you are on oneiric, they may have fixed it there
<apw> DOH test on the same platform wally
<bjf> heh, yes
<apw> yeah they have fixed it on oneiric, so i can switch back if i upgrade ... oh the joy of that choice
<apw> ogasawara, i've just pushed a fix to bug #827197 to the oneiric tree, this is affecting the installer so needs to be in for beta-1
<ubot2> Launchpad bug 827197 in linux "/usr/bin/ecryptfs-setup-private fails with exit status 1 during install - User's home directory not encrypted" [High,Fix committed] https://launchpad.net/bugs/827197
<apw> cjwatson, ^^
 * ppisati -> lunch
<ogasawara> apw: ack
<herton> smb: prepare-package should be fix released (bug 829162), fixed that, just minor thing
<ubot2> Launchpad bug 829162 in linux-ec2 "linux-ec2: 2.6.32-318.37 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/829162
<smb> herton, Ah, darn. Ok, next time then
<smb> herton, note that you might need to fetch --tags because I reused the previous (unreleased/unused) version
<herton> ok
<cjwatson> apw: ta
 * ogasawara back in 20
<ogasawara> kees: if you get me that updated seccomp pull request by noon-ish, I'll throw it into our Beta-1 upload that I plan to do by EOD
<illusec> where is ubuntu's kernel changelog?
<illusec> and list of all patches and etc
<ppisati> herton: while trying to close a tracking bug
<ppisati> herton: 
<ppisati> herton: http://pastebin.ubuntu.com/670124/
<tgardner> ogasawara, you need to add an ignore.modules
<smb> illusec, The changelog you will find either in the git repo under debian.master/changelog or on launchpad (https://launchpad.net/ubuntu/+source/linux/+publishinghistory)
<illusec> smb, thanks in advance
<herton> ppisati: I think you need to add this ppa: sudo apt-add-repository ppa:arsenal-devel/ppa
<herton> ppisati: then update to latest lpltk
<herton> (python-launchpadlib-toolkit)
<kees> ogasawara: okay, cool
<ogasawara> tgardner: ack, will do
<ppisati> herton: uhmm... what's the exact name of the pkg i need?
<herton> ppisati: python-launchpadlib-toolkit
<sconklin> smb, Sarvatt: Looks like we have an i915 regression in Lucid -proposed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828550
<ubot2> Ubuntu bug 828550 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/i915_gem_evict.c:183!" [Undecided,Confirmed]
<ppisati> herton: it worked, thanks :)
<herton> cool
<ppisati> apw: what did it happen to the CVE matrix on people/~apw/cve/...?
<apw> ppisati, s/apw/kernel
<ppisati> herton: is it normal that it changed the bug title to "Ignore this bug"?
<bjf> ppisati, http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
<ppisati> ok, no need fo any rebase then
<herton> ppisati: yes. I think fsl-imx51 needs to have the released closed no and uploaded no?
<ppisati> herton: both mvl-dove and fsl-imx51, i'm --invalidate-ing the tracking bugs
<ppisati> ok, did for both
<herton> ppisati: ok, so please don't invalidate
<smb> sconklin, Hm ok. Ithink there was a large patchset to fix another nasty lockup...
<ppisati> doh
<ppisati> herton: just did...
<herton> ppisati: ok, I'll fix here, wait a sec
<ppisati> herton: ok, so what do i have to do in case there's no need for ny uploaD?
<herton> ppisati: you just invalidate when there is nothing to upload release
<sconklin> smb: yes, there were a number of patches. I just wanted you to be aware. As soon as we get a known good version from the reporter we can start bisecting
<ppisati> herton: wait
<ppisati> herton: that's the situation, nothing to do
<ppisati> herton: aka i've notjing new to push
<herton> ppisati: hmm ok. but isn't there anything new in the branches that should be uploaded?
<ppisati> herton: nope
<smb> sconklin, Yeah. Actually it seems the file where the bug occurs was created for fixes for http://bugs.launchpad.net/bugs/599017 http://bugs.launchpad.net/bugs/807508
<ubot2> Ubuntu bug 599017 in linux "[gm45] Xorg freeze on Firefox on one particular page" [High,Fix committed]
<herton> ppisati: ah ok, that's fine then
<ppisati> herton: ok, done then
<ppisati> herton: anything else i've to do?
<herton> ppisati: nope
<ppisati> ok
<apw> herton, i think this bug here is actually fixed by the fix for the CVE crasher: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/828465
<ubot2> Ubuntu bug 828465 in linux "Kernel OOPS while running Chrome: BUG: unable to handle kernel paging request at fffffff3" [Undecided,Confirmed]
<apw> so if you had a bug for that this should be a dup of it
<herton> apw: correct, let me see here, I think there was another bug opened
<apw> http://bugs.launchpad.net/bugs/813026 perhaps
<ubot2> Ubuntu bug 813026 in linux-ti-omap4 "CVE-2011-1020" [Low,Fix committed]
<apw> oh hrm no thats the cve bug itself
<smb> sforshee, So maybe you are interested in that bug above in some way... ;)
<herton> apw: we can duplicate it against bug 827198, though this one is nominated for maverick only, not lucid (which 828465 is for)
<ubot2> Launchpad bug 827198 in linux "Kernel update google Chrome and Chromium freeze" [Undecided,In progress] https://launchpad.net/bugs/827198
<sforshee> smb, yes
<apw> herton, so if i nominate 827198 for lucid too does that make more sense
<herton> apw: yep
<apw> herton, nom done
<herton> apw: thanks, marked 828465 as a duplicate
<smb> sforshee, Hm, interestingly the BUG_ON that is hit was removed by e39a01501b228e1be2037d5bddccae2a820af902
<apw> http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-kernel-tasks.html
<sforshee> smb, I'm still trying to catch up on the issue -- which commit is causing the regression?
<smb> sforshee, Well I guess it is multiple which were part of the fix for that hang which could be triggered through firefox
<ogasawara> sconklin: http://people.canonical.com/~platform/workitems/oneiric/u/sconklin-ubuntu-11.10-beta-1.html
<smb> sforshee, You should be able to search for one of the bugnumbers I posted
 * tgardner relocates. back on in a bit.
 * smb decides to retire for this week. back next one :)
<apw> smb, have fun
<herton> ppisati: shouldn't fsl-imx51 have an update? there were changes (cve fixes) since Ubuntu-2.6.31-609.26 in -updates. also mvl-dove should be rebased
<herton> I was checking it here now
<ppisati> herton: not by me, at least
<ppisati> herton: come back tuesday and i didn't commit anything, so...
<ppisati> herton: perhas someone else have fixes and their tree, but i'm unaware
<ppisati> s/and/in/
<ppisati> (bloody usb keyboard)
<herton> ppisati: ok, then you have something to do. if there are changes on the branch since latest fsl-imx51 that got uploaded, then I expected that you closed a new released and pushed, so I can prepare a new source package and upload
<apw> fsl-imx51 is a raw tree so its not rebased, it has stuff on it ready i suspect so needs closing out; but herton you guys close them yes
<herton> apw: hmm, so should I close? I thought ppisati did the same as stefan
<apw> herton, i don't really care who closes it, when we talked about the process i am pretty sure sconklin said he wanted to close things as you had process and scripting in place to get it right
<apw> sconklin, ??
<sconklin> reading back
<herton> the way I thought would be, is that we open a tracking bug for ppisati, without the package version. ppisati checks and closes the release in the branch if there were changes from the last package pushed in updates, or if a rebase is needed. then he updates the tracking bug with the package version, sets prepare-package to fix released. Then I or sconkling prepare the src pkg and upload
<sforshee> sconklin, herton, smb: I chatted with Chris Wilson about the BUG_ON from bug 828550. He said it was just paranoia, never actually necessary, and in any case not something the kernel should explode on. So we could try removing it and see if any issues remain with the BUG_ON removed.
<ubot2> Launchpad bug 828550 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/i915_gem_evict.c:183!" [Undecided,Incomplete] https://launchpad.net/bugs/828550
<apw> sforshee, what fun
<sforshee> I hope we can avoid reverting the fair lru eviction patches, as they fix a pretty severe problem (full-on X hang)
<sconklin> apw, herton: my memory matches what herton just described
<sforshee> If that's agreeable to you guys I can make a test build
<apw> sconklin, ok then cool
<apw> ppisati, either way the mvl-dove branch needs a rebase i suspect
<sconklin> sforshee: I'd be tickled if you just run with this and ask the reporter to test
<sforshee> sconklin, all right, I'm on it :)
<apw> sconklin, now the copy branches do you do those or do we
<apw> i presume we do those too
<apw> but you do the lts-backport-xxx yes ?
<ppisati> apw: really? actually there are no open cve in mvl-dove that were closed in master
<ppisati> anyway, i rebase
<mjg59> kirkland: http://fedoraproject.org/wiki/Features/Matahari is what I mentioned yesterday
<sconklin> apw: yes, I think that is what was intended to be accomplished by creating the tracking bugs for derived packages, and assiging them to various teams or people. Maybe we don't have that right yet
<apw> ppisati, right but there are general updates which it will get if rebased, stable updates etc yes ?
<ppisati> ok
<apw> a
<ppisati> so, a rebase is coming
<sconklin> typically, someone else prepares the lts-backport-xxx kernal and tags it (coughTim) and we package it, I think
<apw> sconklin, ok if you arn't doing them then we need shankbot to make derivative branch bugs for them too no ?
<apw> sconklin, t
<herton> sconklin: hmm, I thought were doing now the lts-backport-*, I did the last maverick backport
<apw> they are just a script and upload
<sconklin> ok, if herton did it, then they are ours
<sconklin> yeah they are easy
<ppisati> git branc
<ppisati> ops
<apw> git: did you mean
<apw>  git branch
<ppisati> :)
<apw>  git remove-all-my-files
<apw>  git fall-over-in-a-heap
<apw> git: chosing git-remove-all-my-files -- hope i got it right
<herton> ppisati: so I'm reopening/fixing your tracking bugs, so you can update them when finished
<ppisati> herton: k
<ppisati> herton: so, i rebase mvl-dove and where do i put it? zinc?
<apw> ppisati, i'd say push it to zinc and put the pull request in the bug
<herton> yep, works for us
<ppisati> in the tracking bug?
<ppisati> ok
<ppisati> ok, rebase done, is compiling now
<ppisati> ill be back in a bit
<herton> ppisati: fixed tracking bugs. when you're ready, you can comment on them, and set prepare-package to fix released (also update the bug title with the version of the closed release)
<herton> bbl, lunch here
<herton_> ppisati: fixed tracking bugs. when you're ready, you can comment on them, and set prepare-package to fix released (also update the bug title with the version of the closed release)
 * herton_ -> lunch
<diwic> hey you git experts
<apw> diwic, s'up
<diwic> I'm trying to run "git blame" on something, and what I get is a whitespace change 
<diwic> for the line I'm interested in.
<apw> ok
<apw> so perhaps git blame <whitspace committish>^ -- <filename>
<diwic> how do I continue, i e "git blame" for the version of the file that was before the whitespace change?
<apw> and get a history at that point instead
<apw> note the ^
<diwic> apw, hey, we could do jeopardy, you come up with the answer before I even ask the question!
<apw> heheh
<apw> let me know if it doens't wor
<apw> work
<diwic> it did, many thanks
<kirkland> mjg59: aha, thanks, reading now
<ppisati> herton: ok, should be done
<ppisati> herton: tell me if it's ok, i'll prepare dinner in the mean time
<herton> ppisati: ack
<herton> ppisati: at mvl-dove, it's missing a * Release Tracking Bug:... entry in the changelog, with the tracking bug number opened
<ppisati> herton: hold on
<ppisati> herton: does it go in debian/changelog or debian.mvl-dove/changelog? or both?
<herton> ppisati: only in debian.mvl-dove/changelog
<ppisati> herton: ok, see if it's ok
<herton> ppisati: looks good now
<ppisati> cool
<herton> ppisati: oops, noted a problem
 * ppisati finally bails out for the weekend :)
<herton> ppisati: you used the maverick mvl-dove bug, that was recently opened. It's confusing right now, since we have mvl-dove on lucid and maverick
<ppisati> doh!
<ppisati> crap
<ppisati> ok, let me fix it
<herton> we have two bugs, for now check the tag or nomination to see which is which. I think may be shank bot could add a comment there, when opening the tracking bug, to make things more clear (eg. saying from which maverick or lucid release it opened the tracking bug)
<ppisati> herton: ok, repushed to zinc pointing to the lucid mvl-dove tracking bug
<ppisati> herton: in the maverick bug, i deleted the name/version and reverted "prepare package" to New
<ppisati> unfortunaely i can't delete my comment "please reset HEAD ..."
<ppisati> i'll add anither comment down there
<ppisati> saying to ignore my pull request
<herton> ppisati: hehe np, it's ok now both, thanks. about fsl-imx51, will you close the release later, or do you wish that I do it?
<ppisati> i can close it now if you want, i mean, --invalidate it
<ppisati> the same could be done for omap4
<herton> ppisati: seems a netsplit here. about fsl-imx51 we shouldn't invalidate it, we must release, there are unreleased cve fixes in the branch, but that can wait, no need for you to verify now
 * jjohansen -> lunch
<pedahzur> Don't know if this is directly kernel related (feel free to direct to the appropriate place), but: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/829696
<ubot2> Ubuntu bug 829696 in linux-firmware "Upgrading to version 1.52.1 breaks broadcom b43 driver" [Undecided,New]
<kees> hm, bug 825207
<ubot2> Launchpad bug 825207 in linux "gnome-system-monitor fails to launch with latest kernel upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/825207
<jjohansen> rebooting
#ubuntu-kernel 2011-08-21
<slavanap> Hello! Is there any way to delete shared irq handler, that was registered by foreign module?
#ubuntu-kernel 2012-08-13
<ppisati> moin
<smb> morning
 * ppisati notices that if you don't read lkml on a daily basis, the associated folder tends to explode...
<apw> morning ...
<cooloney> apw: morning, i'm trying to add 'ln -s' workaround in lxc-start-ephemeral
<cooloney> apw: i don't fully understand where shall i add this 'ln -s', upper or lower. i think it should be lower directory 
<apw> cooloney, well if it is in the lower then its a one off thing
<apw> cooloney, though as its a bodge, in the upper seems fine
<cooloney> apw: cd ${upper}; ln -s rootfs / ?
<apw> ln -s . rootfs
<apw> i'd guess, as we want /rootfs to mean /
<cooloney> apw: oh, i tried that. actually it doesn't work,
<apw> and why does it not work ?
<cooloney> apw: rootfs will be an endless loop point
<apw> ?
<apw> if you ln -s . rootfs it cannot be an endless loop
<apw> i assume we end up with /rootfs in the names because somewhere you have a rootfs directory (a real directory) which is used to build the fake namespace
<apw> inside that directory we need to add the link, not replace it
<apw> as a test i would try and run "ln -s . rootfs; ls -ld /etc /rootfs/etc" as the command payload for an ephemeral lxc start thing
<apw> cooloney, ^^
<apw> and see what that produces
<cooloney> so in upper there is rootfs -> .
<apw> ok that sounds right
<apw> so what does ls -ld /etc /rootfs/etc do in that
<cooloney> it looks like overwrite the real directory in lower, 
<cooloney> oh, the lxc hangs in the middle
<apw> whats in rootfs in lower ?
<cooloney> $ ls /var/lib/lxc/p1
<cooloney> config  fstab  rootfs
<cooloney> this is lower
<cooloney> rootfs is a directory containing everything for lxc container
<apw> ok get rid of the symlink in upper
<apw> and ln -s . /var/lib/lx/p1/rootfs/rootfs
<apw> and try that
<cooloney> after i added a link in upper named rootfs, it probably overwrite this real one
<apw> yeah i don't want the top rootfs replaced i want to add rootfs/rootfs effectivly as a link
<apw> so remove the upper one for now, and add the lower one and tell me waht that does
<apw> note the double rootfs at the end
<apw> cooloney, ^^
<cooloney> cd ${upper} sudo ln -s . ${lower}/rootfs/rootfs cd -
<apw> ?
<cooloney> apw: i added this 
<apw> no that is in upper
<cooloney> oh, sorry
<apw> actually that might be in lower, as its absolute
<apw> so you don't need the cd
<apw> ln -s . ${lower}/rootfs/rootfs
<apw> looks right
<apw> cooloney, and ?  does it work /
<apw> ?
<cooloney> apw: oh, no, i got the same error with /rootfs
<apw> ok
<apw> actually which error
<apw> this directory /var/lib/lx/p1/rootfs, is it persistant?  always there?
<cooloney> http://pastebin.ubuntu.com/1144614/
<cooloney> apw: yeah, always there
<cooloney> since lower is a real directory
<apw> ok rathan than putting it in the ephermal scripts like you are
<cooloney> it might be ln -s rootfs ${lower}/rootfs/rootfs
<apw> remove that change, and run: ln -s . /var/lib/lx/p1/rootfs/rootfs in the real filesystem
<apw> outside of the container
<apw> then paste me the ls -l /var/lib/lx/p1/rootfs
<cooloney> roc@roc-desktop:~$ sudo ln -s . /var/lib/lxc/p1/rootfs/rootfs
<cooloney> roc@roc-desktop:~$ sudo ls -l /var/lib/lxc/p1/rootfs/
<cooloney> total 80
<cooloney> drwxr-xr-x  2 root root 4096 Aug  2 11:52 bin
<cooloney> drwxr-xr-x  2 root root 4096 Jul  4 02:01 boot
<cooloney> drwxr-xr-x  3 root root 4096 Aug  2 11:51 dev
<cooloney> drwxr-xr-x 63 root root 4096 Aug  2 11:54 etc
<cooloney> drwxr-xr-x  3 root root 4096 Aug  2 11:54 home
<cooloney> drwxr-xr-x 12 root root 4096 Aug  2 11:52 lib
<cooloney> drwxr-xr-x  2 root root 4096 Aug  2 11:49 lib64
<cooloney> drwxr-xr-x  2 root root 4096 Aug  2 11:48 media
<cooloney> drwxr-xr-x  2 root root 4096 Jul  4 02:01 mnt
<cooloney> drwxr-xr-x  2 root root 4096 Aug  2 11:48 opt
<cooloney> drwxr-xr-x  2 root root 4096 Jul  4 02:01 proc
<cooloney> drwx------  2 root root 4096 Aug  2 11:48 root
<cooloney> lrwxrwxrwx  1 root root    1 Aug 13 18:33 rootfs -> .
<cooloney> drwxr-xr-x  6 root root 4096 Aug  2 11:52 run
<cooloney> drwxr-xr-x  2 root root 4096 Aug  2 11:53 sbin
<cooloney> drwxr-xr-x  2 root root 4096 Jun 12 02:36 selinux
<cooloney> drwxr-xr-x  2 root root 4096 Aug  2 11:48 srv
<cooloney> drwxr-xr-x  2 root root 4096 Jul 21 10:42 sys
<cooloney> drwxrwxrwt  2 root root 4096 Aug  2 11:53 tmp
<cooloney> drwxr-xr-x 10 root root 4096 Aug  2 11:48 usr
<cooloney> drwxr-xr-x 11 root root 4096 Aug  2 11:48 var
<cooloney> apw: ^^^
<cooloney> looks like it is right.
 * ppisati hates debian packaging...
<cooloney> apw: but the output still has /rootfs/ prefix
<apw> cooloney, the output matters not, as long as the path whatever it is points to the right place
<apw> so as long as ls -l /proc/$$/fds
<apw> as long as those paths wrong though they are with /rootfs on the front now validly point to the right file
<apw> which they should as the symlink effectivly strips the prefix (makes it point to the same as /) we should be safe
<apw> does the container work right with it like that
 * apw has to nip out for an hour ... will check back in when he gets back
<cooloney> apw: http://pastebin.ubuntu.com/1144648/
 * henrix -> lunch
<dileks> hi
<dileks> can someone enlighten me why umask 0022 is not working as expected?
<dileks> see this with linux-{3.5.1,3.6-rc1,next-201213}
<dileks> http://nopaste.snit.ch/156629
<dileks> chmod 755 looks like the workaround
 * dileks wants to understand
<dileks> looks like I have to umask on ${MOD_ROOT_FILES_DIR}
<dileks> formerly I could do umask 0022 $local-git-repo
 * ogasawara back in 20
<jsalisbury> bjf, henrix, herton possible regression with 3.2.0-29.  bug 1035590
<ubot2> Launchpad bug 1035590 in linux "Kernel update on 10 Aug 2012 affects nm-applet signal strength" [Medium,Confirmed] https://launchpad.net/bugs/1035590
<hggdh> ogra_: there?
<herton> jsalisbury, ack. Only direct change to ipw drivers was "net/wireless: ipw2x00: add supported cipher suites to wiphy initialization"
<jsalisbury> herton, I also added the network-manager package to the bug for their review
<herton> I wonder if nm is trying to use now nl80211 because of that change, and that doesn't work well with this driver
<henrix> yeah, it could be just a gui thing. it's not clear from the bug if the card actually works or not
<henrix> (gui or nm)
<ogra_> hggdh, whats up ?
<hggdh> ogra_: have you tried today's image for quantal-server armhf+omap4? On one machine (the lab, with the uboot) it loops on 'detecting hardware to find CDROM', on another (no preseed, manual) goes thru the language selection, then nothing
<hggdh> on the loop: I ^C, see a message about seg fault, and hardware detection restarts
<hggdh> same thing on the manual, it seems
<ogra_> well, i just tested desktop an that explodes as well but in ubiquity
<ogra_> hggdh, bug 1028905 for cdrom-detect ... try if wiping the partition table on the target disk helps
<ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
<hggdh> oh crap, forgot about this one
<ogra_> i'll try to nail it down this week
<ogra_> butu first i need a usable desktop install to test a kernel 
<ogra_> *but
<hggdh> ogra_: yes indeed, it is the extended partition 
<Kano> hi apw , why was aufs patched but not enabled?
<apw> Kano, for the same reason we patch it every cycle, because if we don't need to we do not want to enable it
<Kano> i would like it to be enabled by default
<Kano> where is the dsc for the -10 package?
<apw> Kano, in the archive ?
<Kano> yes
<Kano> i only see 9
<Kano> ok, found it on https://launchpad.net/ubuntu/+source/linux/
<elmo> hey, do we have quantal kernels for precise yet at all?  even in testing stages
<elmo> I'm trying debs from quantal directly and not having a huge amount of luck
<bjf> elmo: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<bjf> elmo: there be kernels there
<elmo> bjf: thanks, will try that
<elmo> bjf: interesting
<elmo> bjf: so, the linux-image-3.5.0-9-generic in quantal doesn't have a hpsa.ko despite having it as =m in the /boot/config file
<elmo> bjf: but the PPA deb *does* have the hpsa.ko
<elmo> and hpsa is what gives me my root file system, so ...
<bjf> elmo, so you are golden because you are using the ppa which has the module you need right?
<elmo> bjf: sure sure
<elmo> bjf: but I suspect if I was using quantal (userspace + kernel); the machine wouldn't boot
<elmo> bjf: but I don't have time to (dis)prove that theory right now, so I'll wave my hands and assume you guys have that under control
<bjf> elmo, ah, that was your point 
<bjf> elmo, a bug on that would be nice
<elmo> bjf: ok, will file one in a sec
<elmo> just got to quickly see if quantal fixes all my OCZ SSD woes
<ogasawara> elmo: by chance, when you were installing the .debs from quantal directly, did you make sure to install the linux-image-extra deb?
<ogasawara> $ dpkg -c linux-image-extra-3.5.0-9-generic_3.5.0-9.9_amd64.deb | grep "hpsa"
<ogasawara> -rw-r--r-- root/root     97080 2012-08-09 07:16 ./lib/modules/3.5.0-9-generic/kernel/drivers/scsi/hpsa.ko
<Kano> elmo: what ocz problems? which drive
<elmo> ogasawara: I was, I didn't
<elmo> ogasawara: forgive my ignorance, but why are drivers split out into -extra?
<ogasawara> elmo: we slit the -generic package so that we could eliminate maintaining a separate -virtual flavor.  so the linux-image is a paired down offering for vm's, linux-image-extra provides everything else, so most will want both installed.
<elmo> ogasawara: ah, I see.  so PEBKAC, then, no bug needed.  thanks for explaining
<elmo> 0b:00.0 SCSI storage controller: OCZ Technology Group, Inc. Device 1044 (rev 02)
<elmo> Kano: ^-- those; they spass out when more than one is in a given box at the same time
<elmo> unfortunately, the OCZ binary driver works in that case, but the mvsas driver does not
<elmo> I was hoping quantal's 3.5.xx might fix it, but it doesn't
<Kano> elmo: a pci-e ocz?
<elmo> Kano: yes
<Kano> i only have got ocz via sata
<Kano> whats the pci-id? lspci -vnn
<elmo> Kano: http://paste.ubuntu.com/1145316/
<elmo> or http://paste.ubuntu.com/1145320/ (as root)
<Kano> http://www.spinics.net/lists/linux-scsi/msg54932.html
<Kano> hmm thats the part you could write a bug report
<Kano> do you use latest firmware?
<Kano> mvsas is the driver
<Kano> btw. did you look at modinfo mysas
<Kano> that driver has got 2 modes
<micahg> jsalisbury: you marked bug 1036063 as triaged, do you need more information from me or not?
<ubot2> Launchpad bug 1036063 in linux "BUG: soft lockup - CPU#4 stuck for 22s! [rm:30630]" [High,Triaged] https://launchpad.net/bugs/1036063
<Kano> apw: i reenabled the aufs module, now it fails on hash check (after renameing 9.9 to 10.10 for as 10.10kanotix1)
<Kano> apw: how to fix that
<apw> Kano, hash check?
<Kano> apw: http://paste.debian.net/183416/
<apw> Kano, what does debian/rules printenv say
 * apw suspects you have not pulled a real 10.10 ABI into your package
<Kano> no i just renamed 9.9 to 10.10 because it failed 
<Kano> wget -qO- 'http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=patch;h=eddf18835fe46235ed6800ff80b88251a390b84b'|sed s/8.8/9.9/g|patch -Rp1
<apw> then its saying what it should that the ABI is changed, you either need a real abi or to disable it for your build 'skipabi=true'
<Kano> i did that, then moved 9.9 to 10.10
<apw> abi is not disabled it its failing
<Kano> http://paste.debian.net/183417/
<apw> if you just renames 9.9 to 10.10 thats not going to work
<apw> you need to turn of the abi check or get accurate abi files
<Kano> so how to do it?
<apw> skipabi=true
<Kano> and then?
<apw> then it won't do the check
<apw> and you need to build it again
<Kano> and when i want to update the check?
<apw> update the check?
<Kano> well the way you do it
<Kano> how would you enable aufs?
<apw> i would use getabis to pull the abi information, but as you are going to then end up with a failed abi check because you need it to be called 10.10xxx1 you need to disable the check
<Kano> but when i compile it twice?
<apw> no just add skipabi=true
<apw> and build it just once
<Kano> i want to build it with pbuilder
<apw> so add skipabi in the arch.mk files
<Kano> and how do you update it?
<apw> update what
<Kano> the abi check
<apw> if you mean the abi, if you update it you will have to make your version 11.10
<apw> and the you will be newer than our 11.11
<apw> and your versioning will go to hell
<Kano> hmm
<Kano> cant you just enable aufs by default ;)
<apw> heh
#ubuntu-kernel 2012-08-14
<ppisati> moin
<smb> morning
<ppisati> smb: Stef, i've a problem with maint-startnewrelease
<ppisati> smb: 100% i screwed the packaging
<ppisati> smb: but i don't get why...
<ppisati> smb: so, basically
 * smb does not know either...
<ppisati> hold on... :)
<ppisati> smb: http://paste.ubuntu.com/1146380/
<cooloney> smb: morning
<smb> cooloney, good morning
<cooloney> these days i'm fighting with the building test on my imx6 board
<cooloney> i was asked to test building kdepim, gcc-4.6, chromium-browser, firefox and webkit
<apw> cooloney, how is sbuild working out for you there
<cooloney> i only got kdepim build successfully, but other four packages fail for some reason.
<cooloney> sometimes out-of-memory
<apw> cooloney, but they build on your babbage ?
<apw> (or whatever the current buildds are?)
<cooloney> oh, i never tried that on babbage before.
<apw> babbage may be the wrong name, i get very confused
<cooloney> they are supposed to be build without any error
<apw> i probabally mean panda
<cooloney> since we build them on panda
<apw> you have a panda right?  so you could shift the sbuild containing disk over there and test 
<smb> OK, if they build there with the same compiler it sounds a bit like some corruption going on on the other
<cooloney> and sometime the system will lockup without any output after a very long building time like 8 hours.
<apw> to see if its your environment or the machine
<cooloney> apw: yeah, i'm trying to setup the environment with my PandaES. bs
<apw> it might be good to literally take the same disk over there
<apw> then you'd know it wasn't that exact sbuild environment
<cooloney> right, i'm trying to do these on my PandaES. i tried another USB harddisk before, it looks like not very stable.
<apw> cooloney, if they are not reliable over time, they are next to useless as that is exactly what we would want to do with them
<cooloney> i think i need a USB disk with external power supply. i just found one, and going to do that
<apw> cooloney, ok
<cooloney> apw and smb, thanks for understanding. it is quite annoying about the build failure. and I will post the build logs after i tested it on my PandaES
<cooloney> apw: and for the lxc /root prefix issue. based on your idea, i think i can post a patch to LP for you guys discussion
<apw> cooloney, ok sounds good, point me at it when it is there, i will forget otherwise
<smb> cooloney, As apw said I think it is a good idea (if possible) to take the environment to the Panda and see what happens there. It would rule out this as a source of error. And yes, if you have something, post it 
<smb> cooloney, I assume it is a change to the lxc setup?
<cooloney> smb: yeah, that's what i'm going to do. i got an SATA-TO-USB cable and an external SATA HD power supply now
<smb> ppisati, Try the getabis posted and let us know how that works :)
<ppisati> smb: i'm finishing another kernel than i'll test ot
<ppisati> it
<smb> apw, Yes, some message/warning would do ok. Hopefully you never place a package of the exact name there, but anyway.
<apw> smb, indeed but if you do it'll be a big confusing supprise that you cannot get it to work, then i ask you to test and it works and i pull all my (remaining) hair out
<smb> apw, No we would not want you to do that... :)
<apw> smb, exactly, who would look like bill the cat then
<smb> bill the cat himself?
<cooloney> apw: i posted the patch in bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/959352
<ubot2`> Ubuntu bug 959352 in lxc "Ephemeral containers have "/rootfs" prefix in /proc/self/maps entries" [High,Confirmed]
<apw> cooloney, thanks
<apw> cooloney, i have also made comment that as only the rootfs part of the name leaks into the container, there may be something we can do with the way the unions are placed to get rid of it should they really not be able to cope with the prefix
<apw> perhaps placing two unions instead of one or something
<dileks> +        # echo "rming rootfs softlink for overlayfs" >&2
<dileks> Removing/Deleting
<cooloney> dileks: that's is just a comment, i followed others 
<dileks> and I thought its rming's rootfs
<cooloney> apw: hmmm, i don't fully understand here. 
<cooloney> apw: do you mean we move the unions directory to some other place instead of "rootfs"?
<apw> cooloney, me either i am just suggesting they may be able to play with mounting differnetly
<apw> i have not looked to see how its mounted
<ppisati> brb
 * smb -> munch
<jibel> todays quantal server with LVM fails to reboot after installation
<jibel> bug 1036612
<ubot2`> Launchpad bug 1036612 in linux "Quantal Server failed to install with LVM: VFS: Cannot open root device "mapper/ubuntu-root" or unknown-block(0,0): error -6" [Undecided,New] https://launchpad.net/bugs/1036612
<smb> jibel, Repeatable or maybe just some failure with the initrd (which it quite often is)
<jibel> smb, repeatable, all the automated tests that use LVM failed and reproduced manually
<jibel> smb, alternate, which also runs a test with LVM but doesn't use a squashfs for installation passes. And it uses the same kernel
<smb> Ok, hm. mapper/ubuntu-root... would be good to know what grub.cfg looks like and what the vg / lv is named, but I assume it uses ubuntu as hostname, too...
<smb> I'll try to reproduce it here...
<henrix> apw: are you aware of any network changes on tangerine or gomeisa?
<henrix> apw: i'm not able to run rmadison anymore
<henrix> apw: for ex., 'rmadison --architecture=source linux' seems to hang forever
<henrix> well... no forever. it eventually exit with a 'couldn't connect to host' error
<smb> henrix, firewall? did that work before?
<henrix> smb: yes, it did work before
<henrix> smb: the makefile for the meta packages actually use rmadison
<henrix> smb: that's how i found something's changed
<smb> henrix, Ok, so that really sounds like something changed in between
<smb> (not on the hosts)
<henrix> yep
<ppisati> smb: it works
 * smb assumes it is the getabis script and not the rmadison call
<ppisati> smb: yep, getabi
<smb> ppisati, Cool, then you can ack it
 * smb closes both eyes on tangerines dmesg...
<smb> hm gomeisa as well...
<henrix> ouch! :)
<smb> apw, non-accessible hardlink creation was attempted by: git
<henrix> i've never seen this error before, but it looks like its yama related
<henrix> sysctl kernel.yama.protected_nonaccess_hardlinks
<smb> henrix, Yes I think it is some effect of hardening
<smb> henrix, It might be we need to talk to sforshee ... ;)
<smb> ... and Joe and Colin...
<smb> ... he and I have to talk to me as well...
<henrix> heh
<apw> smb, so when is that happening?  when pusing or locally?
<smb> apw, Cannot say, its just entries that happen at some point
<apw> smb, not that it matters probabally ... as git will fall back to copying
<smb> Must be something I cannot write to... hm, maybe --reference /usr3/...
<smb> apw, Yeah, both are on the same disk... I guess that is what happens 
<apw> yeah makes sense.  and git is hiding it from you probabally
<apw> as it probally just does ln, and if that fails its copies
<apw> assuming ln failure will be cross disk
<smb> sounds reasonable... Just trying it, so my id should produce a new msg
<smb> it did
<smb> apw, And no error from git. Only scary thing is a double entry in alternates (which likely does not matter either)
<apw> oh that is odd
<smb> but I suspect it might be completely unrelated
 * smb wonders whether hardlink protection might go a step too far, though
<apw> it is doing what is intended, it is preventing you linking to things you cannot write to
<apw> so that you cannot drop links to things you cannot modify in random places
<apw> to be overwritten by accident
<smb> hm, thought git would create only readable objects...
<smb> though at some point they probably are writeable, otherwise it should not be possible to create them...
<apw> i may be able to write to the directory but not link the files as they are yours
<smb> apw, Well I guess, given that my objects appear to be writeable to me (on gomeisa, my local repo objects seem to be read-only) that hardlink failure is correct
<henrix> apw: what about the rmadison failure i referred above? any idea?
<apw> henrix, seems to work for me here now
<apw> rmadison -a source linux
<henrix> hmm... i'm unable to run it on tangerine or gomeisa, but it runs locally on my laptop
<smb> And it still does not on gomeisa for me
<smb> I asked on #is but got no answer yet
<henrix> on gomeisa i get an error; on tangerine it seems to hang forever
 * ogasawara back in 20
<hggdh> sforshee: just a Q -- my touchpad when south with the new kernel on quantal, is it still an option to try your dkms?
<sforshee> hggdh, that dkms package was only for testing. All the changes should be in quantal, so if it worked with the dkms package and doesn't work with quantal file a bug and assign it to me.
<hggdh> sforshee: will do, thanks.
<sforshee> mjg59, would you be agreeable to picking up the gmux switcheroo changes now, before the graphics driver issues are sorted out? That will at least get the mux state restored correctly after s3.
<mjg59> sforshee: Yeah, I think so
<mjg59> sforshee: It shouldn't break any existing config
<sforshee> mjg59, no it shouldn't. I'll rebase on top of your patches for the retina then and send the patches later today.
<mjg59> sforshee: Brilliant, thanks
<kiko> live hangout on status update for single zimage for arm http://www.youtube.com/channel/UCIVqQKxCyQLJS6xvSmfndLA?v=4Lpzc_dkh9E
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 21th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati -> out for a bit
 * henrix -> EOD
 * smb -> EOD
<rsalveti> ogra_: bug 1008713, from linux-base/linux, but guess it affects more the images depending on flash-kernel
<ubot2`> Launchpad bug 1008713 in linux "[STAGING] package linux-tools-common (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/perf.1.gz', which is also in package linux-base 3.4ubuntu2" [Medium,Confirmed] https://launchpad.net/bugs/1008713
<rsalveti> as flash-kernel depends on linux-base, which then doesn't let the user to install the linux-tools-common 
<rsalveti> which is a dependency from any specific linux-tools package, that covers perf 
<jpds> Does anyone know if there's a way to tell if a USB port is USB 3.0 compatible ?
<jpds> Of course; $ lsusb.
#ubuntu-kernel 2012-08-15
<adam_g> hey, im trying to bisect for a bug that was seemingly introduced with v3.3. according to tags in the ubuntu-precise repo, the testing window seems to be: Ubuntu-lts-3.4.0-3.7 and Ubuntu-3.2.0-9.16, but 'bisect start' says 'Bisecting: a merge base must be tested' and starts me at Linux 3.2.  i'm assuming i've done something wrong, are these the points to start, or have i chosen incorrect tags?
<bjf[afk]> adam_g: take a look at https://wiki.ubuntu.com/Kernel/KernelBisection
<adam_g> bjf[afk]: i've followed that so far
<adam_g> AFAICS, it doesn't realy cover my issue
<scientes> where is the gitweb for this? http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-precise.git
<jk-> scientes: http://kernel.ubuntu.com/git/ubuntu/ubuntu-precise.git/
<scientes> I just got a not permitted (EPERM right) from prctl(PR_SET_CHILD_SUBREAPER) instead of the expected EINVAL
<scientes> (36)
<ppisati> moin
<cooloney> ppisati: morning, man
<smb> morning .*
 * RAOF matches that regex!
<RAOF> Good morning smb :)
<cooloney> smb: morning
<smb> :) 
<smb> RAOF, Maybe you will tell me someone will frantically work on my acceleration failure with my radeon driven Dell... ;-P
<RAOF> smb: Nobody magically picked that up while I was away? Bad team! No biscuit!
<smb> Nope, all hiding to wait for someone else stepping up. :) 
<lifeless> RAOF: wb, and congrats.
<RAOF> lifeless: Thanks!
<RAOF> Hah. I see that launchpad now sends oops emails when failing to copy packages :)
<lifeless> cjwatsons work
<smb> RAOF, And yeah well, hm, congrats... I guess your effort was the easier... But anyways :)
<RAOF> Yup. Not nearly as big as Sam's effort!
<RAOF> lifeless: So, the oops email doesn't exactly make it clear - do I try again? Will LP finish the copy later, after it's its hissy fit has ended?
<lifeless> RAOF: ask cjwatson :P
<apw> cooloney, so i guess we need to see kdepim done for panda es there as thats the only one which built
<cooloney> apw: yeah, it will finish soon. from the launchpad log, it should be about 4:30 hours
<apw> cooloney, does your machine have swap configures, the one which fails with out of memory
<cooloney> apw: oh, no. i did setup that for both imx6 and pandaES
<cooloney> apw: i will try that later
<apw> cooloney, are you saying you didn't have swap on either?
<cooloney> apw: yeah, there is no swap on my imx6 and pandaES right now
<cooloney> apw: i'm not sure about our PandaES buildd, does it have swap?
<apw> cooloney, i would imagine they would have to have swap to build anything of any size
<cooloney> apw: ok, after finishing building kdepim, i will add a swap and try to build gcc-4.6 and webkit then
<smb> cooloney, How much memory have these things? I mean main memory?
<apw> infinity, i assume the arm builds have swap and i assume it is on the spinning media
<cooloney> smb: for both of them it's 1G memory
<apw> i do not see firefox building in 1G of ram, without swap
<smb> Ok, not as bad as older Arms but still not that much compared to other things
<smb> apw, One would be surprised
<smb> That actually could be the reason for the failures, couldn't it?
<cooloney> for firefox, i think it should be some package dependency issue,
<cooloney> i failed to build firefox on my x86 host with sbuild precise armel schroot.
<cooloney> the error is the same. 
<cooloney> but for webkit building error, i guess it might be related to memory or sway
<cooloney> swap
<cooloney> apw and smb, if we just compare the sucessful case 'kdepim', imx6 is about 3 and half hours, pandaES should be 4 and half
<apw> thats not a huge improvement really is it compared to what was claimed
<smb> One hour seems not too bad, though
<cooloney> apw: probably need more testing. i just have one board, maybe rtg can help to test on his side.
<cooloney> apw and smb, on my pandaES. it took 5hours to build kdepim
<apw> cooloney, ok, we probabally need to get swap on, and then do like 3 of each
<apw> so we can see how variable it is
<cooloney> apw: ok, i will try that
<cooloney> apw: and do you know how to resize a partition with some command line tool in ubuntu. i want to add a new swap partition and shrink my root partition 
<apw> cooloney, hmmm i don't think i do, the installer does it, but i am not sure how
<apw> though google knows all normally
<cooloney> apw: installer is using gparted
<cooloney> ok, maybe it should be resize2fs
<smb> I think gparted would use that under the hoods
<smb> But only offline (whole disk not mounted)
<cooloney> smb: yeah, i can boot from SD card and mount the hard drive for resize2fs.
<smb> cooloney, Though resize2fs is not enough, you want the paritioning to be adjusted as well
<cooloney> smb: right, i plan to use fdisk after that to setup the swap 
<smb> cooloney, Just saying, why not take the whole disk to some machine that runs gparted and do it from there.
<cooloney> smb: aha, my bad. that's a better method. thx
<smb> I try to use the simplest approach :) Otherwise it is too easy to mess up
<mwk_> the ubuntu provided ec2 images include kernels that are not compiled with CONFIG_HW_RANDOM_VIRTIO.  does ec2 support the virtio hwrng?
<smb> mwk_, I have not checked but virtio would sound to me like something belonging to kvm not xen
<mwk_> smb, it does doesn't it -- do you know of an equivalent way of getting good entropy into an ec2/xen vm?
 * henrix -> lunch
<smb> mwk_, hm, not having thought too much about that. probably also depends on hvm vs. pvm (which most ec2 instance types are). Thought /dev/urandom would be producing enough randomness though sometimes take a bit to build up entropy
<mwk_> my application is specifically for key generation -- i would prefer hwrng if at all possible -- at the moment my only real alternative is the cryptographically secure prng in openssl
<smb> mwk_, I don't believe there will be better options. Even if it would be possible to use virtio-rng, that would require some support from the qemu used. And ec2 is using Xen 3.x which would not have any newer features. And from all I can find /dev/urandom sounds like the only option. But you could probably ask on the xen-user (or xen-devel) mailing list to get a better answer.
<mwk_> smb, thx for your feedback
<rtg> ogasawara, while reading https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Quantal I noticed the first bullet item is misspelled; 'Overall Statusbj'
<rtg> which I guess _I_ can fix since its a wiki. doh!
<ogasawara> rtg: hrm, thanks.  must have been some copy and paste error on my part.  I can fix it.
<rtg> ogasawara, take it away...
<ogasawara> rtg: welcome back btw
<ogasawara> rtg: I assume you're drowning in your inbox
<rtg> ogasawara, yep, 600+ including SPAM
<infinity> apw: The buildd have 30G (which is overkill) swap partitions on the same spindle as the system, yeah.
<apw> cooloney, ^^
<cooloney> infinity: is it a swap file or a swap patition? i just allocated 2G partition for building test
<cooloney> 2G swap
<infinity> cooloney: Yeah, 2G won't be enough.
<ogra_> what is he building ? 
<ogra_> libO ?
<infinity> cooloney: And it's a swap partition, but file wouldn't impact things awfully if you had to.
<cooloney> infinity: ok, i will setup a 30G swap partition.
<cooloney> ogra_: i'm trying to build several packages like kdepim, firefox, chromium-browser, webkit and gcc-4.6 on imx6
<ogra_> ah
<cooloney> infinity: did you open my google doc about the build fail
<cooloney> ogra_: imx6 has 4 cores, we wanna test to see whether it is worth to replace panda buildd with it.
<infinity> cooloney: I will later, I'm in meetings this morning.
<ogra_> cooloney, i know, i have one (that i just brocked and recovered)
<ogra_> *bricked
<Kano> hi apw , could you enable aufs with your next kernel upload based on 3.5.2?
<apw> we wouldn't be planning on enabling aufs unless we have a usecase for it, its one more thing to support
<cooloney> ogra_: did you try to build some packages on it before?
<ogra_> cooloney, only the kernel ... 
<ogra_> which isnt really representative 
<ogra_> but it was twice as fast as a panda doing it :)
<Kano> apw: aufs is much older and better tested than overlayfs. if you use overlayfs in casper by default it does not hurt you
<apw> Kano, if its not in my kernel i don't have to security support it for 18m
<dileks> apw: built linux-next with overlayfs.v14 but didnt run any tests so far - so compile-tested
<cooloney> ogra_: it just took about 42 minutes for me to build a kernel on imx6
<ogra_> cooloney, i build the package in exactly 100min
<cooloney> ogra_: probably, you use chroot, right? i just build it natively
<ogra_> i built natively 
<ogra_> the mx6 kernel package from your mx6 branch
<ogra_> (including the udebs, headers etc)
<Kano> ogra_: mx6?
<ogra_> yep
<ogra_> freescale sabrelite
<apw> cooloney, we also need to do some 48hour soak tests to confirm they are stable over long perious of use, building all the time
<cooloney> ogra_: or really, 100 min?
<cooloney> apw: yeah, but i still faced some lockup on my board. 
<ogra_> cooloney, i did five builds in a row (until i bricked the board) ... all with the same result ... 
<apw> cooloney, well if thats the outcome, they lock up if used continuiously, then that is the result of a 48hr test, FAIL
<cooloney> ogra_: did you meet some lockup when you building the kernel. like
<apw> cooloney, and we know they arn't suitable
<ogra_> cooloney, nope, it ran stable (but using the shipped uImage atm, you might remember i didnt get it to boot your kernel)
<cooloney> apw: right. i didn't see such issue on the board in Portland.
<cooloney> apw: the board i'm testing is borrowed from ericm|ubuntu, 
<cooloney> rtg: could you please also do some package building on your imx6 board?
<apw> cooloney, you likely didn't test for such a long period either over there
<rtg> cooloney, I've done a few, but I have yet to setup an sbuild environment.
<ogra_> apw, i tested across 48h but it didnt have constant load 
<cooloney> apw: building webkit will take like 48 hours, i think. 
<ogra_> (the five kernel package builds randomly over two days )
<cooloney> apw:  i will try that soon
 * cooloney needs go to sleep.
 * ogasawara back in 20
<infinity> ogra_: Testing with the Freescale kernel is, of course, not useful, since it's not what we'd be running in production.
<bjf> ogasawara: bug 1013270 is the video bug QA were referring to in the hangout
<ubot2`> Launchpad bug 1013270 in linux "if no monitor is connected, Nouveau fails to initialise" [High,Triaged] https://launchpad.net/bugs/1013270
<ogra_> infinity, well, once io found a way to make u-boot not explode with devicetree issues i will hgappily try out our kernel :P
<rtg> jsalisbury, I uploaded a fix for bug #1032779, so you could take it off the top 10 (if Nick agrees that it fixes his problem)
<ubot2`> Launchpad bug 1032779 in linux-firmware "Missing firmware for wireless chipset on pandaboard" [Medium,Fix released] https://launchpad.net/bugs/1032779
<ogra_> having to recover from brickage wasnt really a pleasantly motivating experience though, so i moved to something else for the interim ;)
<jsalisbury> rtg, ack
 * rtg starts ripping apart a server for CPU upgrade. back in a bit....
 * smb -> gone
<bjf> jsalisbury: bug 1013270 should be on the hot list
<ubot2`> Launchpad bug 1013270 in linux "if no monitor is connected, Nouveau fails to initialise" [High,Triaged] https://launchpad.net/bugs/1013270
<bjf> ogasawara, jsalisbury, ^ is blocking _all_ desktop qa tests using nvidia hw for all series post Lucid, including mainline kernels
<ogasawara> bjf: so it would seem a simple workaround until we resolve it is to make sure a monitor is connected?
<ogasawara> bjf: or am I asking too much
<jsalisbury> bjf, ack
<bjf> hggdh: i'd like to continue any further discussions here so I don't have to repeat myself :-)
<hggdh> bjf: OK
<hggdh> ogasawara: we will need to get local to hook a monitor, there is no provision for monitors in the rack. There is also a dongle update for the KVM that, when installed, will solve the issue (we hope)
<hggdh> ogasawara: this dongle will have connections for pretty much all video outputs
<ogasawara> hggdh: is there an eta for that new dongle?
<hggdh> ogasawara: there should be, retoaded would know. I do not.
<ogasawara> hggdh: and just so I have it clear in my head, when exhibiting this issue, the system in question is just connected to a kvm swtich, but no monitor is attached to that switch correct?
<hggdh> ogasawara: the switch does have a monitor
<ogasawara> hggdh: so I wanted to post a comment to the bug, but I'm still a little confused as to where the "if no monitor is connected..." part comes into play then.
 * ppisati bails out
<hggdh> ogasawara: the machines connect to a KVM (in this case using a DVI<-> VGA converter; the KVM has a local monitor that allows one to connect and use a system; it also allows one to remotely connect to the KVM, and select a system to work on
<hggdh> amd firepro V5900 prints out a few EDID errors and is done; system can be used from the console. nVidia keeps on printing EDID errors, making console usage impossible (server images, 3.5.0-10, now installing desktop)
<ogasawara> hggdh: so a monitor *is* connected (albeit via a kvm switch) when you're seeing these repeated EDID errors.
<jwi> hggdh: maybe try https://patchwork.kernel.org/patch/1301341/ ?
<rtg> apw, what is going on with 'UBUNTU: SAUCE: khubd -- switch USB product/manufacturer/serial handling to RCU' in Quantal ? Is it still relevant ? it caused a minor rebase conflict for 3.5.2 which is what caused me to look at it.
<hggdh> ogasawara: indeed
<ogasawara> hggdh: so the bug report then is completely misleading with the title and description being "if no monitor is connected..."
<hggdh> ogasawara: I agree
 * rtg -> lunch
<apw> rtg, it was a performance enhancement, i can try and do the rebase if you like
<rtg> apw, oh, the resolution is easy. I just wondered if it was making its way upstream
<apw> rtg, that one is on my list to re-test and confirm it still provides benefit
<apw> and to resumbit if so
<rtg> apw, I'll just leave it in Quantal for now
<apw> thanks
 * ogasawara lunch
<retoaded> ogasawara, hggdh: no eta on the new KVM CIMs (dongles) yet. the rfq hasn't been completed yet; once it is completed it will be submitted for PO then ordered. That should all be done in time for me to head up right after Labor Day weekend to start installing them.
<ogasawara> retoaded: ack, thanks
 * rtg -> EOD
#ubuntu-kernel 2012-08-16
 * smb yawns
<ppisati> guys, is there a way to pass stuff like 'skipmodule=true' to dpkg-buildpackage?
<cooloney_> ppisati: i don't know, why not use fdr binary-arch?
<ppisati> cooloney_: because dpkg-buildpackage is waaaaaaaaay faster
<cooloney_> ppisati: really? are you using sbuild/schroot or just crosscompiling
<ppisati> cooloney_: cross compiling in an amd64 schroot
<ppisati> cooloney_: i know it's possible to start a massive parallel compilation with fdr too, but i simply don't know how :)
 * ppisati will always be debian* ignorant
<ppisati> packaging, rule file, etcetc
<ppisati> brb
<diwic> ppisati, fwiw, I'm putting skipmodule/skipabi directly in the makefile
<ogasawara> rtg, apw: I'm thinking of prepping an upload to get some testing on the latest v3.5.2 rebase.  I think the only outstanding patches I wanted to pull in prior to upload would be kamal's trackpad driver and kees' updated yama patches which were dropped.
<ogasawara> rtg, apw: anything else from your guys' end?
<rtg> ogasawara, I'm currently working on yama, trackpad was next on my list
<apw> ogasawara, nothing from me currently
<rtg> ogasawara, Lets ignore yama for now. I think kees must be working on it since his repo HEAD has changed in the last few minutes. I'll pull the trackpad stuff and do a quick build test.
<ogasawara> rtg: ack
 * ppisati hears audio coming out of its speakers... :)
<ppisati> ogra_: http://people.canonical.com/~ppisati/ti-omap4-tilt-34-on-35/linux-image-3.5.0-207-omap4_3.5.0-207.13~audio4_armhf.deb
<ogra_> nice !
<ppisati> ogra_: i've still one little bug, than i'm done
<dileks> ppisati: its still not EOW
<rtg> ppisati, how far behind master is this kernel? 
<ppisati> rtg: rebased on Ubuntu-3.5.0-9.9
<rtg> ppisati, ogasawara is gonna upload today with the rebase against 3.5.2
<ppisati> rtg: good, then i'll pull req tomorrow
<rtg> ppisati, just wondering if you're getting ready to publish a 3.5 based kernel
<ppisati> rtg: yep, ecept for the rtc thing i'm doing now
<ppisati> rtg: the rest is in a decent shape
<rtg> ppisati, sounds good
<ppisati> no major showstopper
<rtg> ogasawara, pushed cypress. its all yours
<ogasawara> rtg: awesome, thanks
<apw> ogasawara, have you tied the bow yet ?
<apw> ogasawara, if not i have a config change for X32 which might be fun to have
<ogasawara> apw: go for it
<ogasawara> apw: am in a meeting so I won't tie the bow for an hour
<apw> ogasawara, pushed
<henrix> ogasawara: apw: i guess you don't need to rush because of this: https://launchpad.net/builders
<apw> henrix, any idea of cause?
<henrix> we have powerpc builds pending since yesterday
<henrix> apw: #launchpad-ops are working on it i believe. know issue
<henrix> but not sure what's the cause
<henrix> or even if they have already root caused it
 * ppisati -> reboot
 * ogasawara back in 20
<bjf> hggdh, psivaa, can one of you go to the public jenkins page and get the sru_kernel-quantal_lts_hwe-* jobs on the "LTS Backports" tab or on a "LTS HWE" tab? that would be much appreciated.
<hggdh> bjf: https://jenkins.qa.ubuntu.com/view/LTS%20HWE/? done
<bjf> hggdh: thanks! that works
<hggdh> bjf: LTS Backports has been merged into LTSA HWE
<bjf> ogasawara: ^
<bjf> jjohansen: putting you down as uds-r roomie
<hggdh> bjf: I also changed the RE for SRU Kernel so that the lts_hwe jobs do not appear there
<_mreed> is there anyone that can take a look at this bug? Originally I thought this might be a kernel bug that was only on  arm architecture, but it seems that it is not architecture dependent.   https://bugs.launchpad.net/eilt/+bug/1034197
<ubot2`> Ubuntu bug 1034197 in linux-armadaxp "Out of memory error when running min_free_kbytes testcase on precise-updates on armadaxp" [Undecided,New]
<apw> _mreed, what does teh test do?  set min-free-kbytes = 0 ?
<_mreed> apw:  I don't think it sets it to zero, checking...
<kees> rtg, ogasawara: did you get my email yesterday about yama? the patches you need should be in my yama-extras tree
<ogasawara> kees: we saw it, although rtg was mentioning he thought he saw you making changes this morning
<rtg> kees, I pulled your repo this morning, but it didn't have the 2 patches I was looking for.
<rtg> kees, git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git right ?
<kees> rtg: i haven't changed the tree in 20 hours.
<kees> rtg: right, the "yama-extras" branch from there
<rtg> kees, shit, I missed the extras branch
<kees> sorry, yeah, I split the unupstreamable stuff from the "please pull" stuff
<rtg> kees, should I apply 'Yama: access task_struct->comm directly' as well ?
<kees> rtg: it'll probably end up on stable too -- it shouldn't hurt and fixes a nearly impossible to trigger deadlock
<rtg> kees, got 'em
<bjf> should be the "crack" branch
<rtg> indeed
<kees> bjf: heheh
<_mreed> apw:  sorry for taking so long, I was otp,   as far I can tell the testcase  uses the default value of mem-free-kbytes and half of that value before trying to eat up memory.  The full  description of the test case is located at this link  http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg13978.html
<sforshee> jsalisbury, an fyi on bug 1007765. Turns out I don't have the exact same card, but I've been trying to reproduce on another Intel card. So far no luck.
<ubot2`> Launchpad bug 1007765 in linux "brightness adjusting crashes system" [High,Triaged] https://launchpad.net/bugs/1007765
<sforshee> jsalisbury, oops. should be bug 1036427
<ubot2`> Launchpad bug 1036427 in linux "unreliability with Centrino Ultimate-N 6300 wireless connection, 802.11n" [High,Incomplete] https://launchpad.net/bugs/1036427
<jsalisbury> sforshee, ok, thanks
<jsalisbury> sforshee, steve says it's pretty difficult to reproduce
<sforshee> jsalisbury, I'm gong to keep trying. Just wanted to let you know how things were going since I told you I'd work on reproducing.
<jsalisbury> sforshee, cool, ta
 * smb off to enjoy some evening daylight
<jjohansen> bjf: sounds good, thanks
 * rtg -> lunch
 * henrix -> EOD
 * ogasawara lunch
 * rtg -> EOD
#ubuntu-kernel 2012-08-17
<ppisati> moin
 * smb tries to get in unseen
<ppisati> brb
<dileks> apw: http://marc.info/?l=linux-kernel&m=134519512112692&w=2
<apw> heh, that sounds like fun
<dileks> apw: s***storm expected
<apw> dileks, i expect it will just get ignored actually
<apw> though al migh reply and tell us if union-mounts is going in or not
<dileks> I repeated consciously the word "finished" and remembered the nvidia-f-u video, so this will ring bells (I hope so). but lets see.
<apw> well its not like overlayfs is finished either
<apw> its all pretty tricky
<dileks> apw: if the code is upstreamed more people will look at it and use it. its more a phychological thingie. /me thinks of enlightenment DR17 (OK, the major libs have now stable versions :-), but ...)
<apw> dileks, there is that, overlayfs has semantic issues (due to its attempts to be performant) that i am not sure will ever be acceptable
<apw> to the purists
<dileks> I remember a faculty meeting where one professor throw into the round, only (software engineering) fundamentalist talk like this... rebellion or kindergarden I dunno. he sould have said "purists", hehe.
<dileks> apw: and miklos somehow reminds of IBM and OS/2
<dileks> hope he will not throw away his own code
<dileks> marketing seems to be a foreign word to him
<dileks> I suggested to get overlayfs into linux-next
<dileks> out of my own experiences... linux-next is better tested than any rcX (upstream) :-)
<dileks> https://lkml.org/lkml/2012/8/16/602
<caribou> smb: howdy, just saw your comment about the kdump kernel issue in Quantal
<smb> caribou, Hi there. Well, just made it. :)
<caribou> smb: just so I understand things correctly : this is not specific to our kernel but is in any mainline kernel above 3.5 ?
<smb> caribou, right
<caribou> smb: if so, shouldn't it be brought up to the kexec ML ?
<smb> caribou, Well it is an issue that ends up making the limited memory even more limited. I don't think it is something that kexec needs to change but the kernel.
<caribou> smb: I know, but maybe the kexec people oughta be aware of it (I mean the fact that it doesn't  work)
<caribou> smb: afaik, hpa is on the kexec ML
<smb> But feel free to take it to the kexec ml 
<smb> So maybe that would be another way to make him aware
<smb> He was cc'ed on the lkml discussion but I can understand when people miss things there
<caribou> smb: it's worth a try. I just don't wanna make a fool out of myself by stating the obvious :-)
<caribou> smb: to me, it looks like the full kexec mechanism doesn't kick in, which should have been seen before
<smb> caribou, I wonder, did you try with more than 128M of crashkernel memory?
<caribou> smb: nope, but I can try, I just prepared a VM for that
<smb> (that would be 64bit, on 32bit it would be a different problem)
<caribou> smb: yep, x86_65
<caribou> euh, 64
<smb> heh :)
 * smb always needs to refrain from saying 31 bit
<smb> caribou, So basically the problem is that on 64bit, due to some mismatch you have about 3 to 6MB (rough estimate) more memory wasted to initial page tables.
<smb> Depends of course on the amount of memory you have on the machine
<caribou> smb: with a 2G VM, even with 256M reserved it doesn't work
<smb> caribou, what kind of vm (xen, kvm, virtualbox,...)? and does a normal (non-crash) kexec work there?
<smb> The problem could be a different one just in the VM
<caribou> smb: it's a KVM vm. 
<caribou> smb: I'll try to test on baremetal when I have a minute
 * henrix -> lunch
<smb> *sigh* is it just me or is a kvm using cirrus graphics currently broken in quantal (had to blacklist the cirrus kernel module otherwise the X driver went into a corner and sulked)
<apw> smb, not tried that i am afraid
<smb> Of course I have not looked what modules were loaded and which driver was used before that giant upgrade...
<siretart> hi. - I'm currently testing the fai (fully automated installation) package in ubuntu, and am struggling with technicalities in the kernel
<siretart> it seems that aufs has been disabled currently in quantal. is this correct, and is the plan for release to leave that disabled in favor of overlayfs?
<apw> that is the current plan, though it was the plan for P as well, and it didn't work out
<siretart> I've also tried overlayfs, but I got a kernel oops when trying it with an nfsroot
<siretart> I didn't find nor file a bug for that yet, I'm still checking the options here.
<apw> always interested in overlayfs triggered opses
<siretart> let me phrase it as a question: is overlayfs supposed to work with NFS?
<apw> there is an indication that NFS is not complete enough to be suitable
<apw> (as an UPPER filesystem)
<apw> otherwise i suspect it is expected to work
<siretart> I'm not sure if I undestand the 'UPPER' part correctly. The setup is to mount the nfsroot read-only from the installation server, and use unionfs to mount a tmpfs ontop of that in early userspace, then continue booting
<apw> in that context the NFS is LOWER
<siretart> ok
<apw> so i think the docs say we might it expect it to work indeed
<apw> cirtainly i have never tried that combo
<siretart> I'll try to reproduce this in non-initramfs context (i.e., on an properly booted system) first, and see if that's enough to describe a test-case. thanks for explaining the current situation and what to expect.
<apw> ok cool.  do ping me with the bug number when you get that far
<siretart> willdo
<siretart> apw: yep, I managed to reproduce it without early userspace. http://pbot.rmdir.de/ba0ec9f8742a0a0dce7ffcd24db00c12 - filing a bug now
<siretart> apw: filed as bug #1038075 - feel free to ping me either here or in #ubuntu-devel if there is any additional information that might be useful here
<ubot2`> Launchpad bug 1038075 in linux "[Overlayfs] kernel OOPS with NFS" [Undecided,New] https://launchpad.net/bugs/1038075
<rtg_> apw, sbuild wants aufs, doesn't it ?
<apw> rtg_, i believe it uses overlayfs as well
<siretart> rtg_: sbuild itself doesn't care, but schroot deals with aufs if configured to do so
<apw> i thought the default changed recently, i'd have to check
<siretart> the mk-sbuild script from the ubuntu-dev-tools package switched the default from aufs to overlayfs in quantal
<apw> if only the three upstream groups could talk to each other and sort out the problems
<siretart> I did that only a couple of days ago
<apw> smb, might that explain why your builds all broke ?
<rtg_> apw, siretart: I'm using a quantal setup in a chroot, but a precise host. I guess I should just install a vanilla precise. this is on an ARM system.
<siretart> could aufs be provided as out-of-tree add-on kernel module package in quantal?
<apw> that doesn't really reduce the maintenance burden which would be the point of not building it
<smb> apw, No I am still P. My "error" was to a( have switched from lvm snapshots to overlay and b) have set build_dir which seems to cause the actual build go into /build (which is overlay)
<siretart> rtg_: I think the switch to overlayfs by default was already done for precise, if I read the changelog correctly
<siretart> version number 0.136, dated Wed, 16 Nov 2011 14:33:04 +0200
<rtg_> siretart, right. I know that sbuild works correctly in precise. it sure doesn't seem to in quantal.
<apw> really waht issues you seeing, i am pretty sure my builder here is quantal using overlay for sbuild
<siretart> rtg_: as said, with the test machine here that I have (amd64, upgraded from precise to quantal) mk-sbuild seems to work just fine for me
<rtg_> hmm
<apw> that fits with my expectations too
<rtg_> dunno. I'm using this hacked up nano image from linaro.
<apw> ahhh ... eeep
<rtg_> think I'll start over
<siretart> too bad that this booting via nfsroot is quite critical for our deployment here :-(
<rtg_> apw, turns out this dang Linaro kernel has neither overlayfs or aufs. Guess I'd better fix that first.
<apw> qualtity
<ppisati> ogasawara: rtg_: after rebasing Q/omap4 on -11.11 i found a regression on boot. so i'll need some time to check what's going on
<ogasawara> ppisati: ack
<ppisati> but i would really like to upload 3.5 Q/omap4  even if it's still on -9.9
<rtg_> ppisati, send a pull request. we can catch up to -11 next week.
<ppisati> ack
<ppisati> besides, i wanted to warn you that, no matter what we do, beta1 omap4 desktop image is going to be broken due to missing 3d driver
<smb> caribou, So I have proof now that kvm crash-kexec works when fixing up the too big page table (4M->16K) and crashkernel=128M but it would not work with crashkernel=256M and the unpatched kernel. 
<caribou> smb: good !
<caribou> smb: I didn't get to test on realiron
 * ogasawara back in 20
<smb> caribou, Cannot really explain why. Probably it is not alone the size but also the location or increasing crashkernel= over a certain number is as bad as not being big enough...
<akua> Can someone help me. I am trying to compile a kernel ( into a deb so I can copy it to a few systems at my work ). I need to use the linux 3.5.x kernel because of USB3 support, however I am trying to stay on Ubuntu 10.04 for the time being.  Everything is going well, I had a lot of problems finding a .config that worked OK, but before I install the kernel-image.deb, I have to copy initramfs from 
<akua> /usr/share/doc/kernel-package/examples/etc/kernel/postinst.d/initramfs into /etc/kernel/initramfs or the kernel panics on reboot.
<caribou> smb: might be a good idea to put your findings in the bug; I will refer to it if I post to the kexec ML (maybe monday)
<akua> I would rather the deb has all the files and actions necessary, but it seems it doesn't.  I am building the deb with the command: "fake root make-kpkg --initrd --append-to-version=-test1 kernel-image kernel-headers" 
<smb> caribou, I should ... and thought I had some but right, I will update it
<rtg> akua, have you tried just installing the quantal kernel ? 
<akua> I also tried the "AUTOBUILD=1 fake root debian/rules binary-debs" method on a git checkout from quantal, but ended up with debs that had no usb hid_drivers, etc.
<akua> ya. I tried that, but it was built with gcc 4.6, and some new version of glibc and then I couldn't compile any kernel modules after the fact, which I must do to run the devices ( capture cards, etc ) required.
<rtg> akua, remember that the git checkout method produces _2_ packages that need to be installed. linux-image and linux-image-extra
<rtg> you might also need the linux-firmware package from precise or quantal to pair up with kernel drivers that need newer firmware.
<akua> rtg: what do you mean about the firmware, is it only if i use the pre-built quantal kernel, or even if i compile my own?
<rtg> akua, yes, you should use a newer linux-firmware in either case
<akua> rtg, i was hoping to build my own kernel-image.deb so I can use a specific kernel, do I need to compile my own firmware then, or is it 'generic'?
<rtg> akua, its largely generic
 * rtg reboots gomeisa for kernel update
<akua> rtg: and there is no easy/obvious solution as to this initramfs problem? I can probably live with it, but for the firmware should I just install linux-image and linux-firmware ( the one from quantal ) and everything should work?
<rtg> akua, yes, but don't forget linux-image-extras
<akua> it seems the debian/rules method makes one of those, but the make-kpkg doesn't
<akua> rtg: ok, the git method seemed to work, but the headers won't install cleanly because it (linux-headers-3.5.0-10-generic) depends on 'linux-headers-3.5.0-10'. Can I build this?
<rtg> akua, build binary-indep (I think)
 * smb -> EOW
<apw> binary-headers might do it too
 * henrix -> EOD
 * ppisati -> EOW
<cwillu_at_work> quick question: the 32-bit mainline packages seem to have some magic to detect whether the cpu supports pae or not; I'm trying to roll a test image, but I can't install that package on the build server because cpuinfo doesn't reflect the target hardware
<cwillu_at_work> is there a way to ignore that check?
<cwillu_at_work> "This kernel does not support a non-PAE CPU.
<cwillu_at_work> dpkg: error processing /tmp/linux-image-3.5.2-030502-generic_3.5.2-030502.201208151151_i386.deb (--install)"
<rtg> cwillu_at_work, unless you've changed the config options, then I don't think the mainline kernel is gonna work.
<cwillu_at_work> rtg, how do you mean?
<rtg> cwillu_at_work, I mean the its not gonna work on a non-PAE capable CPU
<cwillu_at_work> rtg, I'm not running a non-pae capable cpu
<cwillu_at_work> the cpu supports pae just fine
<cwillu_at_work> the problem is the build environment
<rtg> cwillu_at_work, well, the check is in the pre-inst. perhaps it is incorrect ?
<cwillu_at_work> rtg, I don't doubt that the check is correct, it's just that I really do know better than it in this case
<rtg> cwillu_at_work, well then, hack on debian/control-scripts/preinst to remove the check and rebuild the kernel.
<cwillu_at_work> rtg, I see a grim future of never being able to use the packaged kernels for automated installs though
<cwillu_at_work> I'm mainly wondering if there's an existing flag to slap it down (--force-architecture should seem to imply this sort of thing, although that's primarily for dpkg I suppose)
<rtg> cwillu_at_work, yeah, I don't see a way around it. preinst is part of the package and it wants to see 'pae' in /proc/cpuinfo
 * rtg -> lunch
<Eimann> sweet, https://eimann.etherkiller.de/nmz/panic-cisco-dlm-java-applet-in-ff.JPG - happens with 3.6.0-999-generic #201208090423 on x86_64 with 7~u3-2.1.1~pre1-1ubuntu3 openjdk when using the cisco software download manager in firefox 14.0.1+build1-0ubuntu0.12.04.1
<cwillu_at_work> rtg, I think I got it faked out by plopping the word into an empty cpuinfo; first attempts didn't work as it's actually looking for " pae ", while I had tried a simple "pae" :p
<cwillu_at_work> even so
 * cwillu_at_work leaves a postit reminder on his monitor to file a bug
<akua> I built my own kernel, and linux-image and linux-headers installs as expected, and boots with everything working. However, I am trying to compile nvidia's drivers ( because I need CUDA ), and it is complaining about not being able to find the headers.
<akua> the director "/usr/src/linux-3.5.2-custom1/ exists, but /lib/modules/linux-3.5.2-custom1/build and /lib/modules/linux-3.5.2-custom1/source point to /usr/src/linux-3.5.2
<akua> but if i link /usr/src/linux-3.5.2to /usr/src/linux-3.5.2-custom1 it still fails
 * rtg -> EOW
#ubuntu-kernel 2012-08-18
<ChogyDan> hey folks, I am trying to recompile the ubuntu kernel with the BFS patch.  I followed some directions, ran debian/rules updateconfigs, and then during compile, it never asked if I wanted BFS.  I still seem to be running CFS.  
<ChogyDan> Im used to configuring from scratch, but this time around, I copied my config file from the stock running ubuntu kernel.  That seems to be the main change
#ubuntu-kernel 2012-08-19
<mancha> hi folks. community services are still down (beyond the 12-hour estimate) right?
<lifeless> mancha: #canonical-sysadmins is a better place to ask.
<mancha> lifeless: you're right, didn't mean to add noise. i think it is a good working assumption that downtimes are all move related for the next 24 hours :)
<cpatrick08> I was trying to install a mainline kernel and kernel.ubuntu.com/~kernel-ppa/mainline/
<cpatrick08> I was trying to install a mainline kernel and kernel.ubuntu.com/~kernel-ppa/mainline/
<deffrag> I'm using rcn-ee Ubuntu 11.10 image on BeagleBoard XM. I was recently trying to upgrade to distribution to 12.04 but noticed that after completing <sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade>  the command <sudo do-release-upgrade -d> didn't work. It gives error as no such command
<deffrag> How can I upgrade to 12.04 in such case?
#ubuntu-kernel 2013-08-12
<GiGaHuRtZ> Anyone awake? I asked a kernel question in #ubuntu+1 cause sometimes people are knowledgeable there with this stuff
<GiGaHuRtZ> Anyway, I like to test upcoming kernels.  And since the ppa mainline mirror, is no longer a ppa and doesnt work like a apt mirror. I wrote a simple script to use as a cron job
<GiGaHuRtZ> And it grabs the 2 heads and the linux image of the daily build, and installs them via dpkg
<GiGaHuRtZ> My question is, I know there is a 3.11rc3>rc4>rc5 (as of midnight EST) dir
<GiGaHuRtZ> But I have been grabbing from the daily dir http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
<GiGaHuRtZ> And the dailies are like 3.11-99999999 or whatever, and I know 9999999 usually denotes daily
<GiGaHuRtZ> My question is, inbetween rcX releases, those dailies include newer code not yet put into the rcX branch, right?
<GiGaHuRtZ> So if I want newest, my current script grabbing from the daily dir, would be the best bet?
<GiGaHuRtZ> razther than http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11-rc5-saucy/ or whatever newest rc there is
<tjaalton> what's holding back 3.11 from saucy?
<smb> tjaalton, Appears to be something about "out of date" with the di modules... Wished I could understand Britney better...
<tjaalton> oh, needs d-i rebuild?
<tjaalton> makes sense
<smb> Though I thought that now should happen automatic... So probably something holding that
<tjaalton> ah, ok
<smb> Guess we have to wait till infinity wakes up or rtg
<mwhudson> is there someone i can bribe to have http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c5f927a6f62196226915f12194c9d0df4e2210d7 turn up in a kernel for raring?
<mwhudson> (it's a fix for perf on arm32)
<rtg> jjohansen, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1202161/comments/8
<ubot2`> Launchpad bug 1202161 in linux (Ubuntu) "seccomp filter: execve(): Operation not permitted" [Medium,Incomplete]
<jjohansen> rtg: yep thanks
<rtg> let the carnage begin: [ubuntu/saucy] linux 3.11.0-1.4 (Accepted)
 * rtg -> lunch
 * rtg -> EOD
<bjf> stgraber, can you verify bug 1204194 ?
<ubot2`> Launchpad bug 1204194 in linux (Ubuntu Raring) "Please add iwldvm to nic-*-modules" [Medium,Fix committed] https://launchpad.net/bugs/1204194
<nessita> jsalisbury, hey there! saw your comment in the bug 1201528. Question (perhaps silly): what's the point on testing a kernel from mainline released on 30-Jun-2013 when I already tested a kernel from mainline from 04-Aug-2013 (v3.10.5-saucy)?
<ubot2`> Launchpad bug 1201528 in linux (Ubuntu Saucy) "[Realtek ALC889] - Audio Playback Unavailable" [Medium,Incomplete] https://launchpad.net/bugs/1201528
<nessita> is worth noting that v3.10.5-saucy did not break audio
<stgraber> bjf: I filed that bug by proxy for a machine we had around during a sprint in bluefin, but if you're happy with me grabbing the udev and confirming that iwldvm.ko is in there and marking it verification-done, sure I can do that ;)
<bjf> stgraber, that works for me. we just like the bug 'owner' to be the one to verify (in general). 
<stgraber> bjf: done
<bjf> stgraber, thanks!
#ubuntu-kernel 2013-08-13
<brendand> infinity, is it just me or are a lot of the kernels seriously overshooting their verification phase?
<brendand> apw, smb ^ (or anyone in this timezone that knows what is going on)?
<infinity> brendand: I think Brad's been chasing people down to get the last few bugs verified.
<infinity> brendand: You can check progress at http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html
<brendand> infinity, am :)
<apw> brendand, heh no sorry, been on vacation for a couple of days :)
<infinity> brendand: I don't think it'll hurt anyone's feelings if you start doing cert testing on them before the bot has flipped the tasks.
 * infinity goes to find a bed.
<apw> arges, yo ... how is the crash testing going ... 
<hallyn_> apw: hey, so if I do mkdir a; subvolume create a/b; echo c > a/b/c; rsync -va --one-file-system a b
<hallyn_> apw: then b/b is empty.  I.e. a subvolume is treated as a separate filesystem
<hallyn_> apw: is that the expected behavior?
<apw> what the heck is a subvolume
<apw> subvolume
<apw> subvolume: command not found
<apw> i don't even get an offer of one
<hallyn_> apw: make that 'btrfs subvolume'
<apw> i think i would expect a subvolume to be a mount, does it appear as a mount ?
<hallyn_> no
<apw> in /proc/mounts i mean
<hallyn_> it only shows up in 'btrfs subvolume list'
<apw> hallyn_, so rsync figures it out from the stat 'st_dev' field for the file
<apw> hallyn_, so if files in a subvolume have a different st_dev then it will think they are a filesystem
 * henrix -> lunch
<hallyn_> apw: i'm surprised it has a different st_dev.  will ahve to think about what to do about that...
<apw> hallyn_, don't subvolumes represent things like snapshots, i would think they would have to have a different st_dev to avoid being the same actual file in rsync's mind
<hallyn_> apw: yeah they can represent snapshots.  but the first one you create (which you can then snapshot) also shows up a different fs.  which in one way makes sense, but otoh if it doesn't show up in /proc/mounts i'm not sure how a backup script shoudl know whether to separately rsync /var/lib/lxc/$container/rootfs, which may or may not be a subvolume
<hallyn_> i mean, yeah, i can call out to btrfs subvolume, but if i have to do separate tricks for each fs, that's kind of pathetic
<apw> yeah doesn't make much sense does it
<hallyn_> apw: but anyway, thanks - so that's an answer for lifeless_ at least :)  it *is* a different fs, you just have to do it separately
<apw> at least in rsync's mind indeed
<hallyn_> thanks
<bjf> brendand, feel free to start testing i have no reason to believe there will be a respin of any kernels at this point (hopfully i didn't just jinx myself)
<brendand> bjf, that's what i was wondering
<brendand> bjf, it's not a huge problem if there is - but better to know that it's unlikely
<brendand> bjf, i noted though that there is no lucid kernel. have they stopped completely now?
<bjf> brendand, no, just no patches this cycle
<brendand> bjf, ok
<bjf> brendand, though we expect fewer and fewer at this point
<rtg> kees, I'm repackaging rng-tools for v4 'cause debian is way behind and the maintainer is unresponsive. You added TPM cruft in 2009. Is it still necessary ? See kernel.ubuntu.com/~rtg/rng-tools-4 for the new source package.
<rtg> kamal, mdeslaur: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208532/comments/9 might be related
<ubot2`> Launchpad bug 1208532 in linux (Ubuntu) "put_page failures with 3.8.0-27.40" [Medium,Incomplete]
<mdeslaur> rtg: thanks, I'll take a look
<rtg> sbeattie, do you have any interest in reviewing rng-tools at http://kernel.ubuntu.com/~rtg/rng-tools-4 ?
<rtg> you touched it once several years ago
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg> jjohansen, rebooting tangerine for kernel update
<rtg> apw, why is kernel promotion getting held up by an eglibc autopackage test ? what is it doing ?
<jdstrand> apw: hey, I think bug #1204005 may be fixed in 3.11
<ubot2`> Launchpad bug 1204005 in linux (Ubuntu Saucy) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
<jdstrand> apw: I was able to boot saucy and raring vms, both with vmvga, login to a unity session, launch a browser, etc
<apw> jdstrand, yay thank $deity for that, that was my percieved experience as well
<apw> rtg, i believe it is a functionality test, and all 'depends' packages have their tests run
<apw> rtg, so in this case eglibc needs kernel headers so it is tied to the kernel
<apw> rtg, howerver i think the eglibs tests generally are not very good and run out of space
<rtg> apw, wll its pissing me off. IOError: [Errno 28] No space left on device: '/home/ubuntu/adt-log//dsc0-build-xerr'
<apw> rtg, yeah that sucks, so i bring those up on #ubuntu-release and whine
<ogra_> ship a usb key in your source package :)
<rtg> apw, already did, but I think most everyone is at debconf
<apw> ahh no so good, i think jibel is responsible for that puppy
<rtg> apw, http://kernel.ubuntu.com/~rtg/rng-tools-4
<apw> rtg, so i think if the upstream version is '4' this should be versioned as 4-0ub
<apw> rtg, so i think if the upstream version is '4' this should be versioned as 4-0ubuntu1
<apw> as logically the first debian version would be 4-1
<rtg> apw, I thought about that, but none of Jeff's versions in the past have had a minor number
<apw> 42-unofficial-mt.14-1ubuntu1
<apw> rtg, that is *-1ubuntu1
<apw> rng-tools (2-unofficial-mt.14-1) unstable; urgency=low
<apw> was the debian version there
<rtg> apw, ok, I'll add the minor number
<apw> rtg, that is *-1ubuntu1 unclear how 4-unoffical-m...1 would sort relative to 4-0u1
<rtg> apw, seems like the other version cruft is just BS
<apw> rtg, and with it there sorting is all a bit of a lottery anyhow
<apw> rtg, but i think 4-0ubuntu1 seems appropriate
 * apw idly wonders who maintains it in debian, as it clearly has not been maintained for some time
<rtg> apw, ok, updated the version. I'm inclined to just upload it.
<apw> rtg, yeah the binaries look similar to the previous version
<apw> rtg, there are some very minor lintian errors, nothing to hold you up
<rtg> apw, right. the big difference is that I ripped out some TPM cruft from kees. we can always add it back if need be
<rtg> apw, I might drop this on the c-k-t PPA first to make sure armhf builds
<apw> rtg, good plan, my amrhf builder isn't booting right now ... grrr
<bjf> brendand, seems i might have jinx'd myself .. looking like we may have to respin Q and R (still investigating)
<rtg> apw, I don't have an armhf sbuilder right now either
 * apw goes and tries again
<brendand> bjf, lol - i don't think we've started testing anyway :)
<bjf> brendand, indeed, it looks like i'm respinning. you should have new kernels tomorrow. if we have to delay the start of the next cycle, that's just how it goes.
<kees> rtg: hrm, I added TPM cruft?
<kees> rtg: oh, the rng-tools? hey, don't rip that out, I use it!
<rtg> kees, maybe you could get garzik to add it to his upstream repo ?
<kees> it's been semi-abandoned by debian, though. :(
<kees> yeah, I'll ping him
<kees> oh, hm, there's a note about doing this in the kernel...
<kees> hmm 578b016fdc91464c08c096f0c5952cae549fdb8f
<rtg> kees, otp, I'll be back i a bit
<kees> went into 3.7, so I guess I'll just switch what I'm doing.
<kees> $ grep HW_RANDOM_TPM /boot/config-3.8.0-27-generic 
<kees> CONFIG_HW_RANDOM_TPM=m
<ogra_> kees, just stop being around all these thieves
<kees> ogra_: what?
<ogra_> then you wont need theft protection ;)
<ogra_> (isnt that what TPM is ?)
<kees> is that what "tpm" means to you? :P
<rtg> kees, so you're OK with me having ripped out your TPM additions ?
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<kees> rtg: yup! totally fine. new solution is much nicer. http://www.outflux.net/blog/archives/2013/08/13/tpm-providing-devhwrng/
<mdeslaur> kees: oh, that's nice!
<rtg> kees,  cool. rnd-tools v4 is now in Saucy
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 20th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg -> lunch
<sbeattie> kees: oh, sweet!
<lifeless> hallyn_: so this comes back to my question; can we disable the lxc btrfs integration ?
<hallyn_> lifeless: yes, we can.  question is only how shoudl we?
<hallyn_> lifeless: i think in  the past i required /var/lib/lxc to be its own btrfs mount to do the integration.  but i don't think that's compelling.
<hallyn_> lifeless: are you sure you'll never wnat to lxc-clone?  is updating the backup scripts more palatable by any chance?
<lifeless> hallyn_: how about a flag on lxc-create and lxc-clone
<hallyn_> lemme try something
<lifeless> hallyn_: to disable both lvm and btfs special behaviours
<hallyn_> lifeless: what is the lvm special behavior?
<hallyn_> lifeless: if you do 'lxc-create <...> -B dir', does it then not create a subvolume?  (was going to test myself, but my box is busy installing a bunch of fresh containers so i'm stuck on a lock)
<lifeless> hallyn_: man lxc-clone says When the original container's
<lifeless>        rootfs is an LVM block device or is on a btrfs filesystem, then a snapshotted clone  can  be  created,
<lifeless>        taking up very little initial disk space.
<hallyn_> yes
<hallyn_> but you have to ask for an lvm backed container to get one.  it's a separate block device.  not really analogous to the btrfs case
<lifeless> hallyn_: sure
<lifeless> hallyn_: so I guess I'm saying
<lifeless> hallyn_: lets make lxc behaviour predictable. Ask for LVM -> Ask for btrfs.
<hallyn_> lifeless: iiii...  still prefer to default to a subvolume, but i might be wrong.  
<hallyn_> still waiting to be able to test lxc-create -B dir in btrfs
<lifeless> hallyn_: so -B means I'd need to put in /var/lib/lxc/foo/rootfs for each invocation? I presume you just want to test the code paths ?
<lifeless> hallyn_: So if btrfs is on by default, I'd be happy if there is an option to turn it off for both create & clone
<hallyn_> lifeless: no, -B would just mean
<hallyn_> lxc-create -t ubuntu -B dir -n x1
<lifeless> oh, -B none - gotchya
<lifeless> blah, dir. I see.
<hallyn_> stopped my script, testing
<hallyn_> stupid shift key, i said debuild -S not -s!
 * rtg -> EOD
<FernandoMiguel> hi
<FernandoMiguel> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1211976
<ubot2`> Launchpad bug 1211976 in linux (Ubuntu) "[ 11.063330] WARNING: CPU: 2 PID: 1455 at /build/buildd/linux-3.11.0/drivers/gpu/drm/i915/intel_display.c:8286 check_crtc_state+0x58f/0x9c0 [i915]()" [Undecided,New]
#ubuntu-kernel 2013-08-14
<infinity> zequence: Around?
<infinity> zequence: We had to respin Q and R for a regression.   You have new tracking bugs for lowlatency.
<apw> rtg, yo ... did you rng-tools build ok
<rtg> apw, yeah, as far as I know.
<rtg> apw, yep, looks like -4 is published
<rtg> apw, just idle curiosity ?
<apw> rtg, yeah just curiosity, it was up in the air when i quit last night
<rtg> apw, the biggest question was TPM support. since that is now in the kernel kees was OK with removing the TPM cruft from -2
<apw> rtg, ahh ok good
<rtg> apw, you working on the linux-tools naming scheme ?
<apw> yeah, just trying to slip in this other thing in the middle
 * henrix -> lunch
<purezen> Hey guys..! I am a long time Linux enthusiast and have been using Ubuntu since long.. and would like to know if features from kernels with revisions advanced than the ones being used in Ubuntu are backported to ones used by Ubuntu by the Ubuntu team.. Like the 3.11 is supposed to bring DPM to AMD Graphics card.. and shall such features be ported to 3.10, slated to be used by Ubuntu 13.10..? Thanks..!
<rtg> purezen, 13.10 will be based on the 3.11 kernel
<apw> kamal, yo .. this cpufreq thing, which arches is is known to 
<apw> build with
<purezen> rtg: Hey..! Well, that'd be great..!
<apw> purezen, indeed it already has an early 3.11 kernle in it
<purezen> apw: Oh well..:-)
<purezen> Though guys, I would like to know if the kernels that Ubuntu releases officially, I mean that the users get as updates and all.. do really get it with 'backported' components..
<purezen> I hope that my use of the word 'backported' implies features from advanced versions, ported over to previous versions..:-)
<apw> purezen, rarely, we tend to provide newer kernels en-toto where that is appropriate
<rtg> purezen, sometimes we'll backport drivers, or parts of drivers, but rarely do we backport features.
<apw> kamal, this seems pretty intel specific
<rtg> tseliot, what is the difference between nvidia-graphics-drivers-304-updates and nvidia-graphics-drivers-experimental-304 ? The latter incorrectly depends on 'linux-headers-generic | linux-headers'
<tseliot> rtg: which Ubuntu release are you referring to?
<purezen> apw, rtg: Well.. Thanks for the info guys..! Also, great to see 3.11 making it to 13.10.. Needed it for DPM on AMD..!
<rtg> tseliot, precise
<tseliot> rtg: nvidia-graphics-drivers-experimental-304 is going away, as per bug #1198942
<ubot2`> Launchpad bug 1198942 in nvidia-prime (Ubuntu Precise) "Hybrid Graphics and general enablement for fglrx and nvidia in Precise for 12.04.3" [Undecided,Fix committed] https://launchpad.net/bugs/1198942
<rtg> tseliot, does that mean the source package will be reaped from the archive ?
<tseliot> rtg: we'll have transitional packages to migrate nvidia-graphics-drivers-experimental-304 to nvidia-graphics-drivers-304-updates
<rtg> tseliot, is that happening pretty soon ? the linux-headers dependency is causing some problems.
<tseliot> rtg: I'm trying to have the packages moved into -updates ASAP (they're already in -proposed) so that I can finally go on holiday. So the answer is yes ;)
<rtg> tseliot, good. I assume you are regularly hassling folks in the release channel ?
<tseliot> rtg: yep, every day
<rtg> arges, ^^
 * arges reading
<rtg> arges, getting rid of nvidia-graphics-drivers-experimental-304 will solve part of the problem, i.e., the bogus dependency
<arges> rtg: yes
<rtg> tseliot, fglrx has the same problem:
<rtg> fglrx-installer-8.960/debian/control: linux-headers-generic | linux-headers, , ${xviddriver:Depends}
<tseliot> rtg: I'm not updating that driver but feel free to file a bug report about that (using a different SRU)
<apw> ogra_, yo ... can you remind me where to find the panda board docs we had, particularly how to enable a console on the serial console
<ogra_> apw, just copy the serial script in place on the first partition of the SD
<ogra_> (there is a bootscript that has all you need, you just need to cpp it over the one without the -serial tag)
<ogra_> *cp
<apw> ogra_, sounds good, where is the -serial one hiding in the filesystem
<ogra_> nowhere ... its only on the first vfat partition ... put in place when the image is made bootable
<apw> ogra_, ok this is too old an image then to have that, it is my buildder which is being all non-booty
<ogra_> sudo mount /dev/mmcblk0p1 /mnt ... 
<apw> ogra_, yeah i have done that, and have a boot.script, but no other
<ogra_> oh
<ogra_> ok
<apw> boot.scr  MLO  u-boot.bin  uImage  uInitrd
<ogra_> yeah, so you want to edit boot.scr
<ogra_> copy it to be boot.script ...open in vim and remove the garbage at the front
<ogra_> then add a console=ttyO2 to the cmdline 
<apw> yep
<ogra_> mkimage -A arm -O linux -T script -n boot.script boot.sc
<ogra_> r
<ogra_> that should add the header then
<apw> Segmentation fault (core dumped)
<apw> oops
<apw> ogra_, does not work on either raring or saucy it seems
<ogra_> well, if it wouldnt work we wouldnt have image releases for them :)
<ogra_> the image build scripts dont use anything else 
<apw> ogra_, heh that was at release
<apw> ogra_, this is _now_ when, they coredump
<ogra_> thats the x86 version of mkimage ?
<ogra_> (also probably the line above was wrong ... i havent touched any panda in over a year ... (and dont plan to))
<apw> ogra_, that is indeed x86
<ogra_> well, file a bug :)
<ogra_> not sure who from fooundations does arm now though 
<ogra_> probably adam
<apw> mkimage -A arm -O linux -T script -d boot.script boot.scr
<apw> that at least didn't explode and made something similar
<ogra_> heh, yeah
<ogra_> it was my fault 
<ogra_> -n is name 
<ogra_> and indeed you need input data (-d)
<apw> ogra_, well i have more on the console, this is encouraging :)
<ogra_> :D
<apw> ogra_, nothing much to be happy about as yet
<apw> but ... hey 
<apw> sudo: unable to resolve host localhost.localdomain
<apw> she is not feeling too well i think
<ogra_> are you sure this was properly installed ?
<ogra_> sounds like the installer didnt run 
<apw> hmmm
 * apw wonders if he has the wrong card, might be
<ogra_> (we luckily dropped the preinstalled images a while ago, for panda, so this cant happen anymore)
<apw> this thing did get drug into the office one time, so i might have gotten them mixed up
<apw> ogra_, is there a nice howto to install a nice shiney saucy image on this thing, whats on here is all sick
<ogra_> apw, all newer images need a target disk ... (USB disk) ... 
<ogra_> but if you have that, sure, there are d-i images 
<apw> ogra_, hrm ... ok
 * apw goes and find some h/w
<ogra_> apw, http://ports.ubuntu.com/dists/saucy/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz ... unzip and dd to SD card, then boot ... the rest is a server netinstall via serial
<apw> ogra_, that sounds ... believable :)  will let you know
<apw> ogra_, i have d-i ness on there :)
<apw> ogra_, so does flash-whatsit know i have a split bootloader in the new world order, with uboot or whatever on mmc ?
<ogra_> apw, its still the same ... MLO and u-boot.bin ... 
<ogra_> on a vfat 
<ogra_> and yeah the panda HW can only boot from MMC
<ogra_> so you need it as "bootfloppy"
<bjf> brendand, new Quantal and Raring kernels are ready for testing. the lts-backport-[raring/quantal] kernels just got uploaded and are building
<brendand> bjf, yeah testing is under way
<bjf> brendand, sweet!
<tjaalton> i've just upgraded my desktop machine to saucy, but the kernel panics on boot. mainline 3.10-rc7 at least worked fine
<tjaalton> and raring
<tjaalton> kms isn't initialized yet, so there's not much on the screen to report
<tjaalton> huh, now it worked
<tjaalton> dropping quiet from cmdline makes it boot, weird
<apw> rtg, ok i pushed the bits of the linux-tools fixups upto and including kamal's bits, the actual name fixes
<apw> i am redoing now on the top and testing to confirm
<apw> tjaalton, hrm ... odd
<tjaalton> it seems to boot 3.11 fine after a successful boot with an earlier kernel, but not after a fresh start
<tjaalton> doesn't matter what options it has, which makes sense
<tjaalton> some acpi related issue
<tjaalton> but this is an ivybridge SDP so doesn't matter that much I guess
<manjo> tjaalton, do you have virtual box drivers installed ? 
<tjaalton> manjo: no, and it panics 2s into boot, so it's quite early :)
<manjo> ok
<manjo> I had issues with panics on SR with vboxdrv loaded so asked 
<tjaalton> ok
<PhoeniXYZ> Hi everyone. Is there a way to find out whats wrong (some kind of log maybe) if my pc just freezes after the "loading kernel image" and "loading initram" messages (sorry if this is not the right place to ask about this)?
#ubuntu-kernel 2013-08-15
<apw> zequence, yo .. about ?
<xequence> apw: yep
<apw> xequence, i thought you were on holiday
<apw> and ... what happened to your z
<xequence> apw: I'm in Switzerland, yes. More like a holiday from my holiday
<xequence> apw: I left the z at my server, and cant login to it 
<apw> xequence, hehe ... well as you are on holiday i am doing the rebases for Q and R for lowlatency for you
<apw> xequence, ... but it might make sense if you added me to your ubuntu-studio git repo so i can push the result for you
<xequence> apw: oh, thanks. Yeah, sure. 
<apw> xequence, i am awhitcroft on github
<xequence> apw: Yep
<xequence> apw: Think I found the right buttons to let you push and pull
<apw> xequence, we shall see shortly thanks
<infinity> xequence: Hey, want to add adconrad as a member to that too, just in case? :P
<xequence> infinity: Sure. Just a sec
<xequence> infinity: Should be done
<infinity> xequence: Looks good, thanks.
<jk-> hey infinity 
<stgraber> apw: hey, do you have a link to your sbuild sources.list magic script?
<stgraber> apw: I remember infinity mentioning it a couple of times and I had a paste.ubuntu.com link for it but it doesn't work anymore (DB was reset)
<apw> stgraber, it is in the kteam-tools repo, in the apt-pocket directory ... git://kernel.ubuntu.com/ubuntu/kteam-tools
<apw> stgraber, that is also on gitweb on kernel.ubuntu.com if you want to avoid a clone
<apw> stgraber, heh ... so there is a pretty comprehensive readme in there as well
<apw> seems to work pretty well for me,  sbuild --arch amd64 -c saucy-proposed+main <thing>.dsc stylee
<stgraber> apw: cool, thanks
<apw> stgraber, if you are on anything newer than P then things are simpler to undo as well 
<jodh> apw, smb: now that 3.11 is out of proposed, we're seeing different errors (kernel BUGs) wrt the nested kvm issue. See latest details on bug 1208455.
<ubot2`> Launchpad bug 1208455 in linux (Ubuntu Saucy) "general protection fault running apt-get inside double nested kvm VM" [High,In progress] https://launchpad.net/bugs/1208455
<apw> jodh, you are really trying to hurt yourself arn't you
<jodh> apw,smb: I'm going to try running everything locally for now and will report back but could you guys take a look at this again?
<jodh> apw: :)
<smb> apw, jodh Can try to reproduce though 
<smb> jodh, Have you documented clearly what steps you run _in_ the bug report
<smb> ?
<apw> jodh, so to confirm this is 3.11 in all three cases or somethign else, and it is the host who is blowing chunks
<jodh> smb: yes - the latest comments show that it happens running bin/prepare-testbed
<jodh> apw: well, I can't as this is via canonistack so I don't know what kernel the host is actually running.
<apw> jodh, and which kernel croaks
<apw> jodh, so ... waht we need is a canonistack recipe, if you can't put that in the bug, email it to smb and i
<apw> and me
 * smb needs to find out whether his credentials still work and if he got them
<jodh> apw: the kernel running within the kvm instance that is spun up by prepare-testbed (ie the first kvm created on top of the (possibly kvm) canonistack instance I'm given by euca-run-instances).
<jodh> apw: recipe? You mean the steps I took to create the canonistack instance?
<apw> jodh, yeah so ... that is gobblydeegook.  we are dumb kernel people here, who are scared of userspace apps.  a nice "cut-n-paste these 7 commands and watch the fireworks"
<smb> jodh, Yes, so we can follow that as cloesely as possible
<jodh> apw: ok, give me a couple of mins...
<apw> we really are clueless about most things, including canonistack :)
<apw> though i have used it so i do have creds at least
<smb> Well we got machines able to run kvm... so why would we :)
<smb> apw, On unrelated note (before I forget after the context switch): what am I supposed to do with Xen-4.3. All but the xen-api/xcp related package which have dependencies compile ok with the changes. blktap, xen-api-libs ad xen-api do not but due to not being compilable at all anymore in saucy. I can change my xen package to not include blktap which may drop some functionality but then we have not shipped before any devel libs that would all
<smb> ow to compile against anything there...
<smb> all + ow -> allow
<smb> Maybe a question for infinity (if  awake or when woken)
<apw> yeah i think that is beyond my current knowledge.  we are a bit stuck if xen-api is unhappy i know it stayed unhappy for a while last time
<stgraber> apw: hey, any hope of getting my small kernel patch reviewed in the near future? ;)
<stgraber> apw: https://lkml.org/lkml/2013/4/24/518
<apw> stgraber, ok what we should do is get you to resend it, to the same people, and add me to the CC:, with [RESEND] on the subject line (include the Ack from serge as well).  then people are reminded and i can review it too, which it looks ok to me
<apw> and i can say "hmmm this has been hanging about for a long time" etc
<apw> as it is from 4 months ago
<apw> stgraber, looking at the patch abstractly i wonder if it might make sense to make it like a prefix, so like %hp was the pid in that space so we could use only one new letter for any number of 'not the one inside the container, but the one outside the container'
<apw> i asume pids have the same issue
<apw> i mean uids
 * henrix -> lunch
 * smb notes to jodh that he has not received any notes on setting up a canonistack instance, yet
<jodh> smb: I've put step-by-step instructions on bug 1208455.
<ubot2`> Launchpad bug 1208455 in linux (Ubuntu Saucy) "general protection fault running apt-get inside double nested kvm VM" [High,In progress] https://launchpad.net/bugs/1208455
<smb> jodh, How convenient that this is a bug I am not subscribed to, yet. :-P
<smb> Done now
<smb> Probably should have done before
<thariman> Hi how do I file a bug on Microsoft Sorface Pro wifi does not work ?
<thariman> does running ubuntu-bug linux sufficient ?
<xequence> infinity: Is it too loate so SRU the raring lowlatency to the lTS?
<smb> jodh, So I followed your instructions and seem to have no space left on device on /...
<jodh> smb: ok. In which case, "rm -rf /tmp/adt", create a directory in /mnt that user ubuntu can write to (say /mnt/adt) to and then "echo BASEDIR=/mnt/adt > ~/.adtrc".
<jodh> smb: autopkgtest should then use /mnt which has lots of space on medium guests.
<smb> jodh, is that what *you* do as well?
<jodh> smb: I think something has changed recently in adt. It's rather difficult to document every single step and work-around I've had to use to get this far. sorry :(
<smb> jodh, Just makes it a bit hard to get the same experience... :/
<rtg> apw, have you done a saucy live install lately ?
<apw> rtg, lately, not in the last two weeks no, i did one just before sprint
<apw> rtg, and i did a server install like yesterday on armhf ...
<apw> rtg, if it would be useful i can do a VM one now
<rtg> apw, I checked that I wanted updates installed from the net during installtion, but on first boot there were like 100 packages that needed updating.
<apw> rtg, that checkbox is "download updates while installing"
<apw> it doesn't install them i don't believe
<rtg> apw, just caches them ?
<apw> yeah i think that is right ... i seem to remember being caught out by the same
<apw> when discussing how a kernel in -updates would avoid something something
<rtg> huh, I'm not convinced of the usefulness of that "feature"
<apw> no me either
<rtg> apw, though one could argue that if the live CD kernel booted, then you'd at least want that one installed.
<apw> heh yeah you always want the first one
<arges> smb: https://merges.ubuntu.com/libv/libvirt/REPORT
<rtg> apw, we're not building an alternate install for saucy anymore, right ?
<apw> we still build alternates yes, d-i images
<rtg> apw, where do they live on cdimage.ubuntu.com ? looks like we're only doing server and live
<apw> is not the server image the alternate installer ?
<rtg> apw, the alternate used to include desktop whereas the server does not
<apw> oh then ... no :)
<rtg> not that I'm really caring. just curious
<smb> Yeah I think that got dropped. Now that the desktop supports LVM... 
<infinity> zequence: Almost certainly too late to figure out what that would mean and how we'd do it, yeah.
<infinity> rtg: No desktop alternates, but you can install desktop fine from a d-i netboot or a server CD (just that you have to hit the interwebs for the packages).
<rtg> infinity, my get dailies script was complaining about alternates no longer existing, which is what caught my attention
<smb> infinity, Ni, err I mean Xen MRE, maybe, please?
<infinity> rtg: Ahh.  We dropped them in Q, I think, your script's been out of date for a while. ;)
<rtg> infinity, could be....
<infinity> smb: Did you get someone to sponsor the uploads?
<smb> infinity, No, I am trying to get you to
<smb> infinity, apw Always runs faster than lightning when I mention those three letters
<infinity> Heh.
<ogra_> infinity, what are you doing here !
<ogra_> off to bed with you !
<infinity> ogra_: I had a meeting this morning.  Blame ogasawara.
<ogra_> oh, evil girl !
<ogasawara> Muahahah :)
<ogra_> :)
<smb> One never knows when infinity sleeps... or which timezone he actually is in... :-P
<infinity> smb: Alright, if you can't talk Andy into sponsoring it for you, bug me on the weekend, and I'll see about doing a one-shot sponsor-and-SRU-review.  Just need to set aside some time to do so.
<smb> infinity, Usually I would want to avoid bugging people anywhere around weekends, but then I am getting slightly desperate with that, so will try
<infinity> smb: Well, I'm happy to do "community" work on weekends occasionally, and Xen currently sits on a bit of a fence there.
<infinity> I'm still trying to figure out who I need to convince to make it a first-class citizen in everything we do.
<smb> Yeah that might be a difficult task... 
<xequence> infinity: I was away for a while, in case you answered. I was asking about SRU of lowlatency for the LTS. Is it too late to do that?
<apw> smb, am i expecting to see crash on the merges list again ?
<smb> apw, For saucy you might as upstream did a 7.x.x
<smb> Actually I had been looking and we had issues with hardening options
<apw> infinity, the issue with xen-4.3 is the xapi stuff whcih all went wrong last time we did xen
<smb> apw, Oh, I asked him about the other Xen
<apw> there is anohter xen
<infinity> xequence: 10:44 < infinity> zequence: Almost certainly too late to figure out what that would mean and how we'd do it, yeah.
<smb> Yeah the stable MREs for P, Q and R
<apw> oh ok
<apw> those i don't think i ahve seen anyhow
<smb> infinity, So yeah actually for 4.3 there is this xen-api madness. They got rdepends against xen but are not even buildable right now
<apw> or if i have i have painfully blmked them
<smb> apw, I tried not to "overload" you with xen
<apw> heh
 * rtg -> lunch
<xequence> infinity: Ok. I'd like to do one for 12.04.4 though. How long before would it be good to bother you on that?
 * henrix -> EOD (SIGBOOSE)
<infinity> xequence: Sometime after next week.
<infinity> xequence: Given that you don't actually put lowlatency on your install images (or am I misremembering?), this isn't something that needs to be tied to a point release, really.
<infinity> xequence: You could jam an lts-raring kernel in precise and just socialize the idea that it's there for people who want to use it.
<infinity> xequence: Assuming you commit to the same cadence as the Canonical SRU people (as you've done for your P/Q/R rebases), I'd be alright with letting that in.
<xequence> infinity: We do have lowlatency on the images, so therefore it would be nice to get it on there too. But, I'm not at all against getting it there non timely as well
<xequence> Ah, but you meant like using a PPA
<infinity> xequence: Right, let's talk about it after .3 is out the door, then.
<infinity> xequence: No, no.  I don't mean a PPA.  I mean in the archive proper.
<xequence> infinity: cool
<xequence> alright
 * apw relocates away from his mic
 * smb relocates away from work
 * apw goes make food
<jjohansen> rtg: do we file a support ticket to get tyhicks access to zinc and the kernel build machines (tangerine, ...)?
<rtg> jjohansen, yes, he needs to be in the LDAP group
<jjohansen> rtg: okay thanks
<tyhicks> jjohansen: should I open it or have you already started?
<jjohansen> tyhicks: feel free to open it, I have not started it yet
<tyhicks> will do
 * rtg -> EOD
#ubuntu-kernel 2013-08-16
<amitk> apw: who'd be the right person to talk to about hibernate in ubuntu? Do you have any knowledge about the initramfs magic, specifically around module loading, if any.
<apw> i thought that stuff was still in the initramfs, i don't recall us changing it
<apw> amitk, ^
<amitk> apw: right, but who's a good person to talk to. I've never really looked into the initramfs
<apw> you could ask me, i've done a fair bit when fixing udev and lvm
<amitk> apw: ok, will start an email thread with one of my colleagues. We're going to get hibernate to work on ARM...
<apw> amitk, you might want to inculde slangasek
<amitk> apw: ack
<apw> amitk, so i am not convinced that there is anything to do for hibernate is there?  it isn't a clever thing in x86
<apw> amitk, the kernel saves the image to disk, the kernel shuts down the machine, userspace notices the image on next boot and tells the kernel to restore it
<apw> i don't think any of that is system specific
<amitk> apw: userspace notices the image on next boot is what we're trying to figure out
<apw> there is a command, something like resume which calls something ...
<apw> amitk, ok it is resume which is part of klibc, but in short what it does is echo "devicemajor:deviceminor:offset" in /sys/power/resume
<apw> and the kernel handles it from there
<amitk> apw: and klibc in in initramfs?
<amitk> *is in
<apw> amitk, yeah busybox etc use that
<apw> but the important thing is that /sys/power/resume is the interface arm needs to have
<apw> i would assume other than saving registers etc that would be generic
<apw> so if you need to do anything it would be in there
<apw> as all distros will use that interface
<amitk> apw: right, it is an architecture hook that needs to be implemented. And we have patches to do that. per-SoC changes should be non-existent, unless the image lies on a device that isn't activated "soon"
<ogra_> apw, didnt we completely drop hibernate support ? 
 * ogra_ remembers a several weeks long discussion on the desktop ML before it was removed
<ogra_> (i think already in precise)
<ogra_> heh i just looked it up ... natty actually
<ogra_> https://lists.ubuntu.com/archives/ubuntu-desktop/2011-January/002754.html
<ogra_> iirc it resulted in us dropping all userspace bits for hibernate
<amitk> ogra_: interesting...
 * amitk nevers uses hibernate
 * ogra_ neither
 * amitk finds a fresh boot to be faster, but several people really, really care about restoring state of apps
<ogra_> well the new app lifecycle stuff will handle that even across reboots at some point 
<ogra_> once it enters the desktop from phone ... 
 * henrix -> lunch
<hallyn_> is inotify on overlayfs supposed to be supported in the backport kernels for precise?
<rtg> hallyn_, I would assume so if its supported in the release kernel. apw ^^
<apw> inotify on overlayfs doesn't really work, never has
<apw> whatever works on the main kernel works just the same in the backports kernels
<apw> hallyn_, ^
<hallyn_> apw	got it, thanks
<hallyn_> apw: got it, thanks
<smb> jodh, Still around?
<jodh> smb: hi
<smb> jodh, I wonder whether you have a really pressing reason to have the 1rst level guest to be a 32bit installation
<jodh> smb: well the dep8 tests I'm developing will need to work on all architectures that Upstart is built on.
<jodh> smb: do you have any ideas on what might be causing the issue?
<smb> jodh, Yeah, but your testbed is the 2nd level
<jodh> smb: well that has to be nested to allow the existing autopkgtest infrastructure to be leveraged. pitti may have more to say on this, but my understanding is that we need it to be nested (hence the same arch).
<smb> jodh, I am wondering whether using qemu-system-x86_64 in the 32bit 1rst level guest causes the issue. Not sure what the fallback is
<rtg> apw, quick review on bug #1213136 ?
<ubot2`> Launchpad bug 1213136 in linux-manta (Ubuntu Saucy) "linux-manta: kernel log fills with 'snd_pcm_update_hw_ptr0: 26 callbacks suppressed'" [Undecided,New] https://launchpad.net/bugs/1213136
<jodh> smb: I can try with 64-bit for all 3 systems in canonistack if you haven't already?
<smb> jodh, You could just use qemu which would be aliased to the same arch. Though in my testing I had now one success but also one crash and weird NMIs being delivered which I not yet understand
<apw> rtg, ok that pulls the majority of the payload out of the ratelimit
<smb> jodh, I am using 64-32-32 right now but would try 64-64-32 for verification next
<jodh> smb: yes, the whole thing feels very "shaky" - I managed to get an almost complete test run locally earlier today with no crashes but it crashed on the 2nd run.
<apw> rtg, i would say just leave the code order as it was, and put the ifdef round just the snd_printd
<smb> jodh, I think when I first could not reproduce it was 64-64-32.
<smb> jodh, Just too long ago to be sure
<rtg> apw, its the printk_ratelimit() call that is causing the problem. snd_printd() is already ifdef'd by SND_DEBUG
<jodh> smb: ok, but did you run that combination a few times though?
<smb> jodh, I will do next. First I tried to see whether I can get into the same situation. 
<jodh> smb: ack.
<smb> jodh, And that lockup with modprobe almost always happened with the 64-32-32 setup (with the host being quantal). With a host on Saucy the qemu-64bit would fail to start any guest at all
<smb> jodh, Thats how I noticed you using the 64bit version all the time
<smb> jodh, I know 2 out of 2 is not very much, but I gotta run and see that outside world thing. I will put it onto a loop and update the report later when I get back.
<jodh> smb: thanks!
<rtg> apw, its actually a bug that exists upstream. This is a bit more elegant way to fix it without ifdefs. http://kernel.ubuntu.com/~rtg/pcm/
<brendand> bjf, our raring testing is about 60% done - i'm debating whether to wait until monday and actually finish it or just push it now. what do you think?
<bjf> brendand, this will be the default kernel for .3
<bjf> brendand, lets go all the way with it
<brendand> bjf, ah i see
<brendand> bjf, in that case i'll make sure it goes out first thing monday
<brendand> bjf, with full testing
<bjf> brendand, thanks
 * apw migrates to comfy pastures
 * rtg -> lunch
<brendand> bjf, i might have made a mistake with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205381
<ubot2`> Launchpad bug 1205381 in Kernel SRU Workflow security-signoff "linux: 3.2.0-52.78 -proposed tracker" [Medium,In progress]
<brendand> bjf, can you set it so that it won't get published yet?
<brendand> bjf, remove 'certification-testing-passed' maybe?
<bjf> infinity, ^
 * henrix -> EOW
<brendand> bjf, anyway security still need to ack it - for now i'll just ask them not to do so just yet
<bjf> brendand, i'll reset some taks
<bjf> tasks
<bjf> brendand, i just set your task back to In Progress
<bjf> brendand, infinity won't promote it before it's ready
<infinity> bjf[afk]: I wouldn't have promoted it anyway (and neither would have shankbot), since it's a Friday. :)
<infinity> But I do hope all this stuff is ready by Mondayish.
<infinity> jjohansen: There seems to be a bit of a backlog of security signoff tasks.
<jjohansen> infinity: yep, I am aware of that. They are the next thing on my todo list
<infinity> jjohansen: Shiny, thanks.
<brendand> infinity, that's useful info
 * rtg -> EOW
<apw> zequence, yo ... when you get a chance could you make a github lowlatency repo thing for saucy, so i can publish the branches and tags ... so i can pass them off to you
<kyle__> Hello, I'm sure this question has been answered only but I can't find it.  I just build a kernel for raring from git sources with these commands:
<kyle__> fakeroot debian/rules clean
<kyle__> DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 fakeroot debian/rules binary
<kyle__> how can I get the -dbgsym package?
<Sarvatt> kyle__: skipdebug=0
<kyle__> is that an envirornment variable?
<Sarvatt> sorry, skipdbg=0
<Sarvatt> DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 skipdbg=0 fakeroot debian/rules binary
<kyle__> ok
<kyle__> next time I build I will try that
<kyle__> is there anyway to do this without rebuilding or are the symbols already stripped?
<kyle__> thanks for the help
<Sarvatt> i'm not sure, the kernel build system is insane :(
<kyle__> shouldn't it be:
<kyle__> DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 fakeroot debian/rules binary skipdbg=false
<apw> it is already gone basically ... and yes non-buildd builds default to no ddebs because they take so very long to make
<kyle__> I ran the command again without cleaning first, I was hoping that this would reuse the object files already there
<kyle__> I guess we'll see
<apw> it won't ...
<apw> good luck anyhow
<kyle__> thanks
 * apw gives it up for the day
#ubuntu-kernel 2014-08-11
<SirDMZ> Ok, so i've built a new pbuilder and the kernel still FTBFS in that. http://pastebin.com/KAhXkKMF
<karooga> Hi anyone familiar with vmebus?
<zyga> hey, are the new 3.13-based kernels for precise and trusty being released via some fast track this time around?
<zyga> bjf: hey
<zyga> bjf: the man I wanted to talk to
<bjf> zyga, what's up?
<rtg> kamal, could you have a look at https://lists.ubuntu.com/archives/kernel-team/2014-July/046963.html ? it is affecting 3.13 stable.
<kamal> rtg, ok, will do
<rtg> kamal, it has regressed kirkland's orange box (if you need a tester)
<kamal> rtg, ack.  looks like upstream has a fix in the works -- I'll see what we can do for 3.13-stable asap
<rtg> kamal, I couldn't find the upstream patch in linux-next, so its still pretty green
<kamal> rtg, yes
<kirkland> kamal: rtg: yes, please I need that fix in trusty-updates ASAP, urgently
<kirkland> kamal: rtg: I'm happy to test
<rtg> apw, do you have patches for https://bugs.launchpad.net/bugs/1354397 ?
<ubot5> Ubuntu bug 1354397 in linux (Ubuntu Trusty) "Latest fixes from storvsc & scsi drivers for Hyper-V/Azure" [Undecided,In progress]
<apw> rtg, ahh i am working on that one, slowly, as the list i have which is in another bug, fails to apply like at the first hurdle
<rtg> apw, are they for Trusty or Utopic ?
<apw> rtg, for trusty at least, i started on friday and flushed the context
<rtg> smoser, do you have any reproducers for https://bugs.launchpad.net/bugs/1354459 ? Maybe we can get IBM to have a look.
<ubot5> Ubuntu bug 1354459 in linux (Ubuntu) "kernel crash power 8 bare metal" [Undecided,Incomplete]
<smoser> rtg, it fails ~ 20% of time maybe
<smoser> boot fails.
<smoser> maybe only 10% .
<rtg> smoser, just idling ?
<smoser> well, boot is hardly idling
<smoser> it doesnt make it up to the point where it is doing anything useful.
<rtg> smyes, but otherwise
<smoser> i think i've seen it fail both in d-i kernel and in iscsi remote root boot.
<rtg> smoser, does it happen on more then one ? I think there are some OPAL version differences
<smoser> i have onyl really tried doing install and such to one machine.
<smoser> so my sample set is a bit small
<rtg> infinity, ^^ have you seen any bare metal problems ?
<rtg> smoser, we have a bunch of these machines, so I'm surprised the issue is not more widespread
<infinity> rtg: No, but I don't do a lot of bare metal testing (yet).
<rtg> infinity, ok, I thought we had.
<infinity> rtg: We almost entirely run in VMs.  This needs to change, obviously.
<infinity> rtg: And will change a bit as host LE KVM starts working, so we can run Ubuntu on Ubuntu.
<rtg> infinity, do you anticipate installing more bare metal machines soon ?
<rtg> when KVM starts working I assume
<infinity> rtg: Over the coming weeks, perhaps.  It's not an urgency for me, yet, though it should be for the cert people pretty soon.
<smoser> rtg, infinity it is important, its "supported" for maas.
<infinity> rtg: But yes, once we have a working KVM solution, the plan would be to flatten all the machines we have and run Ubuntu on all of them.
<smoser> and is not entirely un-useful either. u
<smoser> it can be useful for lxc host.
<smoser> to run ppc64el "bare metal".
<infinity> smoser: Sure, it's useful for some usecases (whole machine use, or lxc), but neither of those is currently my use-case.
<infinity> smoser: But my use-case should be getting fixed pretty soon.
<smoser> infinity, you are not the only person ;)
<infinity> smoser: I know I'm not, but Tim was asking if *I* do a lot of bare metal, and the answer is currently no.
<infinity> smoser: Other people should definitely be testing it more.
<infinity> smoser: And one of those people will soon be me.
<rtg> smoser, have the cert folks started on bare metal yet ?
<smoser> rtg, i believ they have started.
<rtg> kamal, https://bugs.launchpad.net/bugs/1354469 looks like another 3.13 stable regression
<ubot5> Ubuntu bug 1354469 in linux (Ubuntu) "[3.13.0-30.55] rtl8821ae Kernel PANIC due to calling incorrect function" [High,Triaged]
<apw> rtg, that is the driver update you did isn't it?
<rtg> apw, a staging driver ? I don't remember that
<rtg> lemme look again
<rtg> apw,ah, it was ppisati
<apw> nominally it was "us" at least
<rtg> kamal, nm about bug #1354469. I found an upstream patch and have sent it to the k-team list.
<ubot5> bug 1354469 in linux (Ubuntu) "[3.13.0-30.55] rtl8821ae Kernel PANIC due to calling incorrect function" [High,Triaged] https://launchpad.net/bugs/1354469
<kamal> rtg, but should I really never-mind?  that seems like a good candidate for 3.13-stable anyway, doesn't it?
<rtg> kamal, I don't think those patches came in via stable, but I have not checked.
<kamal> rtg, not tagged for stable, but sounds like maybe it should be
<kamal> *have ben
<kamal> *have been   (sigh)
<rtg> kamal, IIRC the rtl8821ae patches were backports proposed by ppisati.
<kamal> rtg, ok I'll take stock and bug him
<rtg> kamal, just checked. there are no updates in your 3.13 stable for drivers/staging/rtl8821ae/rtl8821ae, so I'm sure this is not your problem.
<kamal> rtg, excellent -- thanks!
<retabell> just filled a bugreport
<retabell> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1355318
<ubot5> Ubuntu bug 1355318 in linux (Ubuntu) "wlan-dongle ID 0df6:0076 Sitecom Europe B.V." [Undecided,Confirmed]
<zartoosh__> HI using ubuntu 14.04 I get this error. BUG: Bad page map in process sshd  pte:01000000 pmd:23ed32067
<apw> zartoosh__, that would be unexpected, you should file a bug against linux when it occurs
<zartoosh__> apw, thanks for your reply, should I file that against linux kernel, or ubuntu kernel. Please advise? thx
<apw> ubuntu kernel in the first instance, if it proves to be upstream we can move it up then
<apw> zartoosh__, file the bug and report the number here, as that sounds like something needing investigating
<zartoosh__> apw thank you will do, last question:  that what number ?
<apw> the bug numbre
<zartoosh__> apw thank you.
<henrix> ~/quit
#ubuntu-kernel 2014-08-12
<sacarde> hi
<sacarde> can you suggest me a driver for webcam ID: 10f1:1a08 ?
<sacarde> can you suggest me a driver for webcam ID: 10f1:1a08 ?
<gsedej_work> Hello! Does anyone know if there is some big change from kenrel 3.12 to 3.13 reguarding ACPI (laptop hot keys)? From 3.13 on, power button on my EeePC 1101HA does not work anymore. More info: http://ubuntuforums.org/showthread.php?t=2219864&p=13096245#post13096245
<apw> gsedej_work, you likely should file a bug against the package linux (the kernel) in launchpad
<apw> and put all that information in it, if you have a bracket like that working not working a bisect can find it
<apw> rtg, on that hyper-v stackola i have a pile for each of trusty and utopic sorted, i'll get utlemming to test them before i send them in
<rtg> apw, ack. this is packaging week for trusty
<apw> rtg, i don't think it is a rush, so if it misses this one, *shrug*
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes - in #ubuntu-meeting
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues August 19th, 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.
<rtg> dannf, have you ever talked to chiluk about their hotfix helper ? I think they've solved the version issues that you're encountering.
<dannf> rtg: i haven't
<dannf> chiluk: got some info?
<chiluk> dannf can you restate what you are trying to accomplish?
<rtg> I think he wants versions that fit between distro release versions
<dannf> chiluk: https://lists.ubuntu.com/archives/kernel-team/2014-August/047617.html (skip down to the 1-5 list)
<chiluk> dannf take a look at https://bazaar.launchpad.net/~cts-engineering/cts-engineering/cts-platform-tools/files/head:/kernel/
<chiluk> let me know if you don't have access.
<chiluk> I'm still reading through your e-mail.
<dannf> chiluk: no access
<chiluk> dannf try now.
<chiluk> and welcome to cts-engineering ;)
<chiluk> basically we get around your abi issue by disabling abi checks for our hotfix kernels.
<dannf> ah
<chiluk> also we version using ~ and + after the ubuntu version string.
<dannf> yeah - i've found it useful to keep the abi checking, because sometimes we're building modules that need to load in existing d-i
<chiluk> + is newer than ~ is older than.
<rtg> dkms is the bane of my existence
<dannf> ~ *and* +?
<dannf> oh, one or the other - gotchya
<dannf> yeah, that's what i'd expect
<dannf> chiluk: sorry for the internal link, but https://wiki.canonical.com/CDO/Hyperscale/KernelMaintenance
<chiluk> dannf... I just checked actually we are not using + and ~ for kernel packages.
<chiluk> instead we version like so.. 3.13.0-32.57hf70318v20140801b1
<dannf> rtg: ^ btw - i was wondering about moving that content somewhere public, if there's not already a public equivalent, for how to create ubuntu-y commits
<chiluk> hf=hotfix... then internal bug.. then external bug... then build number.
<dannf> chiluk: heh - i thought that was a commit hash
<chiluk> but dannf not that fancy.. but much more useful.
<chiluk> especially in my line of work.
<dannf> rtg: of course, i'm making up the policy based on what i've seen, dont' really know what ya'lls rules iz
<rtg> dannf, my only rule is, "Don't cause regressions" :)
<chiluk> right.. dannf ideally we would follow the same process for hotfix and test kernels .
<rtg> chiluk, except for the whole ABI and DKMS issue....
<chiluk> well i guess that's up to the developer not to screw that up.
<rtg> chiluk, non-sequitur - looking at your dcache branch. the only patch missing is up through 3.16 is 'vfs: add cross-rename' which I don't think is necessary. Agreed ?
<rtg> or rather, the only patch up through 3.16 _not_ on your branch is 'vfs: add cross-rename'
<chiluk> rtg correct... it's also the only patch that doesn't touch dcache_shrink_list or it's related locking.
<rtg> chiluk, cool. lemme know how your testing goes.
<rtg> dannf, do you know for sure that DKMS will correctly detect an ABI change with the 2 field scheme you are proposing ?
<dannf> rtg: right, that's why i started the commit with commands showing that the results are the same
<dannf> rtg: i don't - dkms isn't something i deal with. but if it breaks w/ the 2 field, that shouldn't regress anything
<rtg> dannf, so if you change your minor ABI number it _won't_ trigger a DKMS rebuild ?
<dannf> well, i'd hope it *would* trigger a DKMS rebuild, but i haven't tried it
<rtg> dannf, if it doesn't, then what good is the minor ABI number ? you could just as easily add skip_abi to your build.
<dannf> rtg: d-i compat
<rtg> and version appropriately
<dannf> for example, with the x-gene sata changes, we needed to verify that the sata driver worked at install time. 
<dannf> beacuse the abi was the same (and verifiably so), i could extrat that module and cat it to the d-i initrd
<dannf> now, if things break, i could just skipabi and move on
<dannf> things == my changes break the abi
<dannf> but i've had customers building modules to test, etc - nice not to make those suddenly stop working
<rtg> dannf, so these aren't DKMS modules, but just straightforward externally built modules ?
<dannf> right. though i suspect it'd be a useful feature for chiluk et al if there's a case where they have a DKMS customer who needs to temporarily branch from ubuntu but resync later
<dannf> but that doesn't sound like a case they've needed to handle yet
<dannf> rtg: honestly, i'd be happiest if ubuntu just didn't use the abi number in the package version, but i guess there's a reason for that
<dannf> nothing technically wrong with e.g. linux-image-3.13.0-33-generic_3.13.0-58_arm64.deb
<rtg> dannf, the ABI number provides for a unique binary package name which allows you to have multiple kernels installed.
<dannf> rtg: i understand that - but that doesn't mean it has to be in the version
<dannf> you could have both linux-image-3.13.0-33-generic_3.13.0-58 and linux-image-3.13.0-34-generic_3.13.0-59 installed at the same time
<rtg> dannf, its _not_ in the version, its part of the binary package name.
<dannf> it is in the version.
<dannf> that's where the existing packaging extracts it from
<dannf> linux-image-3.13.0-33_3.13.0->>33<<.59
<rtg> rather, the ABI is also in the version as well as the package name.
<dannf> right - and that's what makes it a pain to do "normal" branch versions
<rtg> well, we're gonna have to deal with it 'cause it ain't gonna change
<dannf> rtg: i assuemd that was true, thus my hacky patch :)
<dannf> if i thought you'd take a patch to drop the abi from the version i'd have done that first :)
<dannf> though tbh i don't understand why it is that way
<dannf> maybe easier to map back to a package version given just an oops message?
<rtg> dannf, so I'm EOD. Lemme think about this some more. I'm trying to think through the implications for your packaging as well as mine.
<rtg> I think I understand your use case though
<dannf> rtg: understood, and no rush on my part - i just keep this patch in all my trees
<dannf> though of course i'd like to shed it/share it eventually
#ubuntu-kernel 2014-08-13
<hans109h> @apw Andy, any progress on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981?  I tried not to bug your for over a month...
<ubot5> Ubuntu bug 1313981 in linux (Ubuntu) "Kernel disabling serial port ttyS0 on boot" [Medium,Confirmed]
<system0x01> Hi. Where reported, the fact that certified equipment is not working on a newer version of kenel?
<system0x01> It is part of a notebook-G1 455 Hp
<system0x01> Ubuntu 14.04 kernel 3.13.0-33-generic
<system0x01> rt3290 wifi + bluetooth combo, where part of the wifi works and some Bluetooth adapters do not.
<system0x01> Official drivers for linux on the HP website are only a SLED-11 and is kernel version 2 in front.
<system0x01> http://paste.ubuntu.com/8033443/
<gsedej_work> apw, others: by sisecting kernel - does this mean compailation? I have issue on EeePC with Atom - very slow cpu. Or can I just download from kernel.ubuntu.com?
<smb> gsedej_work, In the end it is compiling kernels (probably not on the EeePC, though) using git and the bisect command. You can narrow down the range that needs to be covered by use of the mainline builds. Usually it ends up being a previous version to next version -rc1 thing but at least less than otherwise.
<gsedej_work> smb, can i compile on my (AMD) 64bit machine and use on 32bit Atom?
<smb> gsedej_work, Yes, personally I would use a (s)chroot set up with arch=i386 so you would not have to worry about details. 
<smb> gsedej_work, hope this might be useful https://wiki.ubuntu.com/Kernel/KernelBisection
<gsedej_work> thanks, I already saw
<gsedej_work> so, now I found out that 3.12.26 (lastest 3.12) is working, while 3.13-rc1 is not. It is up to compiling...
<smb> gsedej_work, Yeah. And using the upstream tree as git source, you might have to use v3.12 good and v3.13-rc1 bad.
<gsedej_work> I don't have time atm, but I can open ticket - launchpad or krenrel.org bugzilla?
<gsedej_work> it's probably not ubuntu specific... or?
<smb> gsedej_work, You can open a bug with "ubuntu-bug linux" (from the netbook) anyway.
<gsedej_work> with 3.13-rc1 loaded? (first bad one)
<smb> If that works ok enough to do it, yes. The data that is collected with that would maybe have some more info about the issue
<smb> or actually
<smb> better with the latest Trusty kernel from the distro
<smb> gsedej_work, ^
<gsedej_work> the problem is Power button not woking. else is ok. Power button does not react anywerhe, not even in raw keyboard grab (others like wifi hotkey are)
<gsedej_work> ok,
<gsedej_work> so I should install the newsest kernel from synaptic?
<smb> Ah ok. Think I saw you asking or stating the issue somewhere. Might be really some subtle problem around acpi
<gsedej_work> I suspect eeepc-laptop kernel modul
<smb> So for reporting the bug, install the latest kernel for that release (or lts backport kernel for that release) and do the ubuntu-bug call. Then mention in the report that is generated that 3.13-rc1 already was bad
<gsedej_work> ok... I already did post some results on forums http://ubuntuforums.org/showthread.php?t=2219864&p=13096245#post13096245
<gsedej_work> I will include in bug
<smb> ok, thanks
<smb> Always better to have things in one place
<smb> Hm, at least limited to the eeepc-laptop module there is only one change between 3.12 and 3.13 that does more than just cosmetic changes: eeepc-laptop: convert acpi_evaluate_object() to acpi_execute_simple_method()
<smb> Though it still could be a change in acpi which has not been fixed up in eepc-laptop properly
<gsedej_work> anyway - the main problem is, that it's impossible to wake up from suspend - it's impossible without this key, lid is now working on wakeup (but does suspend when down)
<smb> So its good to have the bug report to track this. Looking at both changes to the driver itself, they both seem to be sane and not changing functionality. Hopefully bisecting leads to the actual cause...
<gsedej_work> is it ok, or should I add more info? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356229
<ubot5> Ubuntu bug 1356229 in linux (Ubuntu) "Asus EeePC 1101HA PowerButton not working" [Undecided,New]
<smb> gsedej_work, looks good enough to me.
<smb> gsedej_work, Have you ever tried removing acpi_osi=Linux with the newer kernel? At least the dmesg shows the eepc-wmi module not loading because of that.
<gsedej_work> smb, it's even worse - I am not able to use wifi. And yes power button doesn not worke either
<gsedej_work> I can try without parameter
<smb> gsedej_work, Right now (from the logs) eeepc-wmi fails to load because of that and eeepc-laptop happens to not be loaded at all
<smb> Added a comment to the rport
<smb> *report
<gsedej_work> maybe I did not say good. So If you put acpi_osi=Linux parameter, eeepc-laptop gets loaded (and not -wmi). Problem with -wmi is that I am not able to use wlan-hotkey. Neither Powerbutton works
<gsedej_work> uuuups!!! blacklisted eeepc-laptop when I was testing -wmi
<gsedej_work> and forget about it
<smb> Aha. :)
<gsedej_work> interestingly power button work in 3.12 witout this module
<gsedej_work> any
<smb> That can make sense. The power button likely is standard enough that it is handled by normal acpi functions
<smb> Usually its all the special hotkeys that need the special modules
<gsedej_work> i just found out that wifi hotkey IS working with -wmi, but not brightness 
<smb> for that you could try removing the other option (backlight=vendor) 
<gsedej_work> oh
<gsedej_work> I did remove backlight=vendor, but brightness still does not work
<gsedej_work> so, no my paramters in kernel command line
<smb> Ok, probably best to re-add things so eeepc-laptop is in use and attach the output of dmesg from that boot. That should be all works as good as possible but not the power button.
<gsedej_work> this makes -wmi loaded which makes working wlan and others BUT NOT lid brightness. (also touchpad disable touchpad, netiher does with eeepc-laptop)
<gsedej_work> interesingly, brightness hotkey works in grub (probably controlled by bios?)
<smb> yes, that is usually the case
<gsedej_work> so, now i have loaded last trusty kernel, with parameters, loaded with eeepc-laptop. What should I do?
<smb> "dmesg > dmesg.txt"  and then attach that file to the bug report and a comment saying it was blacklisted before (and maybe that the power button was working in 3.12 regardless of the module not being loaded)
<gsedej_work> I did post
<smb> thanks
<prorus> Hi guys how do I specify kernel version in lb config? (live-build)
<apw> prorus (N,BFTL), hmm no idea, i'd ask on #ubuntu-devel
<onicrom> so i switched back to the bianry nvidia drivers and i still get load them in any kernel besides 3.13.0-30 or lower
#ubuntu-kernel 2014-08-14
<apw> omicrom (N,BFTL), hmmm that says you can't load them in old kernels, and can in new, is that right ?
<SrinivasGowda> Hi guys just wanted to report a change that needs to be made on this document
<SrinivasGowda> https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues
<SrinivasGowda> The last section near the footer with "sudo restart thermald"
<SrinivasGowda> needs to be changed to  "sudo service  thermald restart"
<apw> SrinivasGowda (N,BFTL), thanks
<apw> SrinivasGowda (N,BFTL), and fixed
<soren> apw: "(N,BFTL)"?
<smb> soren, Not(there), But For The Log. I wondered the same. :)
<apw> soren, yeah that
<onicrom> apw: sorry i cannot load the nvidia kernel modules in any kernel newer than 3.13.0-30
<apw> onicrom, i think we are already aware of that, i think tseliot was on the case there
<apw> soren, and i think that shows that is worth it :)
<tseliot> onicrom: weren't you using drivers from a ppa?
<onicrom> tseliot: i was then i switched back 
<onicrom> same problem
<tseliot> onicrom: what driver are you using?
<onicrom> nvidia-331-updates 331.38-0ubuntu7.1
<tseliot> onicrom: are you running Precise or Trusty?
<onicrom> trusty
<tseliot> onicrom: ok. Is there a bug report about it?
<onicrom> i had only been searching google for something and couldnt find, if there is a more appropriate place to search for a bug i can do there
<soren> apw: :)
<soren> smb: Thanks :)
<tseliot> onicrom: please type "ubuntu-bug nvidia-331-updates" and file a bug report from there
<soren> Google gave some interesting suggestions, though, but I'll leave it as an exercise to the reader to look them up. :)
<onicrom> thanks tseliot 
<rtg> dannf, your patch 'Allow for package revisions condusive for branching' does not correctly extract the ABI number when the version is of the form 3.16.0-8.13~14.10 (as it is for the LTS kernel).
<dannf> rtg: ah, wasn't familiar with that string - i'll fix. if you need to revert in the meantime, no hard feelings :)
<dannf> rtg: are there any other version forms you need to deal with?
<rtg> dannf, that is the only other version form I use. I've reverted your patch only in the LTS branch so far.
<dannf> ack
<hallyn> apw: stgraber: hi, in a current ubuntu-cloud utopic vm (3.16.0-5-generic) unprivileged overlayfs appears broken
<hallyn> lxc-clone -s -o u1 -n u2 fails
<bjf> hallyn, do you know if there are any tests for that in lxc-tests? we run those tests and nothing is failing.
<bjf> stgraber, ^
<stgraber> I don't believe lxc-test-unpriv currently tries that, though we probably should
<bjf> thanks
<bjf> would also give apw handy tests to run
<apw> sounds good
<hallyn> Yeha, it'd be a good thing to test, just not sure how to finagle that for upstream tests
<hallyn> I.e. most kernels don't yet expect that to be allowed, so how do we sanely say "in this system, fail if the overlayfs mount fails"
<apw> hallyn, i'll have a look at the unpriv issue in the am i guess, i am fading fast, is there a bug filed
<hallyn> apw: not yet.  in a bit i'll file a bug with hopefully a testcase
<hallyn> apw: thanks - ttyl
<apw> hallyn, sweet, we may have lost a fix rolling forward, has happened before
<hallyn> yeah usually it tends to be apparmor :)
<apw> hallyn, or that :)
<stgraber> hallyn: IIRC lxc-test-userns is already an Ubuntu-only test (as in, configure will only include it on Ubuntu systems)
<apw>  /proc/version_signature is pretty much ubuntu specific
<hallyn> stgraber: yeah, Makefile.am does it.  
<hallyn> so the test can go there
<hallyn> meanwhile i need to set up a trusty vm so i can actually test overlay clones real quick :)
<hallyn> apw: opened bug 1357025
<ubot5> bug 1357025 in linux (Ubuntu) "unprivileged overlayfs mounts no longer work in utopic" [Undecided,New] https://launchpad.net/bugs/1357025
<kees> did you guys typo this:
<kees> * auditsc: audit_krule mask accesses need bounds checking
<kees> Â  Â  - LP: #1347088
<ubot5> Launchpad bug 1347088 in linux (Ubuntu) "Trusty update to 3.13.11.5 stable release" [Undecided,Confirmed] https://launchpad.net/bugs/1347088
<kees> 3.13.11.5 is not in trusty's kernel.
<bjf> kees, i'll check but i think that's going into what we are currently working on ... will come out in 2 weeks
<rtg> kees, its in Ubuntu-3.13.0-33.58
<rtg> according to the git log
<bjf> kees, rtg is right that came out on monday
<kees> rtg: but why does the Makefile show 3.13.11.4 then?
<bjf> kees, because we pulled it from the upstream stable set and put it into a special kernel
<kees> $ git log | grep -m1 "Linux 3.13.11.4"
<kees>     Linux 3.13.11.4
<kees> but this returns nothing:
<kees> $ git log | grep -m1 "Linux 3.13.11.5"
<rtg> d428381b112e220dbba0b6d8197b51db60318432 in master-next
<kees> so it's certainly not in 33.58
<bjf> kees, are you looking at master or master-next ?
<kees> I'm looking at master, but specifically I was looking at 33.58 which claimed to have that bug (3.13.11.5) fixed.
<kees> so it looks like a typo in the changelog, and that 3.13.11.5 is on it's way.
<bjf> kees, one sec. 
<bjf> 6ff733c0b2cac445b2535a9adc83c76a315052be auditsc: audit_krule mask accesses need bounds checking
<bjf> $ git tag --contains 6ff733c0b2cac445b2535a9adc83c76a315052be
<bjf> Ubuntu-3.13.0-33.58
<bjf> Ubuntu-3.13.0-34.59
<bjf> Ubuntu-3.13.0-34.60
<bjf> kees, ^
<kees> bjf: 6ff733c0b2cac445b2535a9adc83c76a315052be is not "all of 3.13.11.5" which is what bug #1347088 claims to be
<ubot5> bug 1347088 in linux (Ubuntu Trusty) "Trusty update to 3.13.11.5 stable release" [Undecided,Confirmed] https://launchpad.net/bugs/1347088
<bjf> kees, yes and as i said above we pulled that one commit from the .5 stable release just specially for "someone" who was whining at us about it
<kees> sure, but it seems like that bug shouldn't be closed, since all the other fixes (e.g. "ptrace: fix fork event messages across pid namespaces") haven't been imported yet.
<bjf> kees, ok, but that's kind of a minor nit
<bjf> kees, i can fix that
<kees> I just found it confusing since "Trusty update to 3.13.11.5 stable release" hasn't happened, but the bug got closed. :)
<bjf> kees, yes, that was confusing
<kees> but it sounds like it's on it's way still, which is totally fine. I just had people asking me why their ptrace stuff was still breaking even though they were running with the kernel version that closed that bug. :)
<kees> all is clear now! thanks :)
<bjf> kees, .5 is almost in the oven
<kees> \o/
<rtg> kees, we often cherry-pick patches in advance of stable releases
<bjf> rtg, the issue here is/was that it has a buglink for a general upstream stable release
<bjf> rtg, and then we pulled it earlier so when 33.58 went out the .5 tracking bug got marked fix-released
<rtg> bjf, oh, I see how that could happen.
<bjf> rtg, i saw that it was going to happen and ment to go back and fix the bug but forgot
<hallyn> jjohansen: hi, bug 1357103 is a squirrely one andreas just ran into
<ubot5> bug 1357103 in lxc (Ubuntu) "apparmor denied a golang build inside a container" [Undecided,New] https://launchpad.net/bugs/1357103
<hallyn> apparmor is denying file_mmap to a file which presumably is cloned from another btrfs subvolume
<jjohansen> hallyn: interesting
<hallyn> jjohansen: heh, any ideas on the cause though?
<jjohansen> hallyn: maybe the name is disconnected
<jjohansen> hallyn: I think that will be due to an issue with bind mounts that I hit
<jjohansen> hallyn: I have a patch that for that, that we can try and see if it resolves it
<hallyn> jjohansen: cool!  better than i'd hoped
<jjohansen> hallyn: which kernel would you like me to build to test? trusty, utopic?
<jjohansen> the bug is trusty, so I am assuming that, but ...
<hallyn> jjohansen: yeah, i haven't reproduced myself, so what andreas has
<jjohansen> okay, I added a note to the bug, and I will get the test kernel attached tonight
<hallyn> thanks!
#ubuntu-kernel 2014-08-15
<apw> hallyn, bug 1357025, looks like we lost a patch on rebase to v3.16, i've repplied it and am dumping test kernels in the bug shortly
<ubot5> bug 1357025 in linux (Ubuntu) "unprivileged overlayfs mounts no longer work in utopic" [Medium,Confirmed] https://launchpad.net/bugs/1357025
<rtg> apw, which one ?
<apw> UBUNTU: SAUCE: Overlayfs: allow unprivileged mounts
<apw> rtg, ^
<rtg> hmm, that isn't in my dropped file
<apw> you probababally just said "overlayfs is dropped" as a whole ?
<rtg> apw, could be
<apw> collateral dammage from that, if the test existed (which it will soon) it owuld have been cought before it left CKT PPA but ... hey
<hallyn> apw: cool, thanks
<hallyn> apw: test case has been submitted to lxc upstream, it may make it into the utopic yet
<apw> hallyn, ok there are test kernels up, if you could get them verified "soon" then we have an upload planned for today
<apw> which i would like to see it in
<hallyn> will do, thx
<hallyn> apw: fixed
<apw> hallyn, thanks for the confirmation, confidence was high
<dannf> rtg: http://paste.ubuntu.com/8054904/
<dannf> rtg: i'll update to those regex's - let me know if there's any other tests you'd like me to add
<rtg> dannf, I've never used extended regex's. I may have to find a new book :)
<rtg> dannf,  those look like sufficient tests
<dannf> ack. will send out a patch after a test build
<apw> rtg, i sometimes wonder if we should just add .0 in the middle there for this purpose
<apw> rtg, indeed i wonder what would happen if we just used like -Nr0.U and people rev'd r
<apw> something to chew on
<rtg> apw, so, what would that do for us (the distro) besides making the version even _more_ complicated ?
<rtg> dannf, I just accidentally moderated your emails out of existence. maybe you should just subscribe ?
<dannf> rtg: i'm on ubuntu-kernel
<dannf> er kernel-team
<rtg> dannf, this was the private list I moderated
<dannf> oh - i assumed that was an organizational list 
<hallyn> sforshee: just to be sure, nothing you've done with fuse+userns would break if fuse mounts requred MS_DEV?
<hallyn> uh, MS_NODEV
<sforshee> hallyn: I'm thinking that I required MS_NODEV for fuse+userns mounts, but I'd have to go back and look
<hallyn> cool, long as there's nothing wher eyou'd have needed NOT specifying MS_NODEV :)  (which would be ridiculous, i think)
<hallyn> thanks
<sforshee> hallyn: yeah, I didn't set FS_USERNS_DEV_MOUNT which means that any userns mounts get NODEV
<hallyn> not for long :)
<sforshee> are you referring to that cve fix?
<sforshee> hallyn: either way, I think letting a userns+fuse mount contain devices would be a big problem
<hallyn> sforshee: i'm referring to a patch by Andy L. reverting part of Eric's patch
<hallyn> (not sure if that's the cve fix you mean)
<sforshee> hallyn: yeah, I'm talking about the one from eric. Do you have a link to the revert?
<hallyn> sforshee: http://lkml.org/lkml/2014/8/13/746
<sforshee> hallyn: that's still okay then. Instead of an implicit NODEV the mount just fails.
<hallyn> right
<sforshee> hallyn: does that impact our overlayfs support?
<hallyn> sforshee: hm.  it might
<hallyn> but if it does then lxc should simply add the nodev option 
<hallyn> the new lxc-test-unpriv extension should catch it if it does
<sforshee> right, something to look out for when we pick up that patch
<stgraber> hmm, so the latest kernel security update for the 3.13 kernel breaks LXC
<stgraber> (well, nested unprivileged containers specifically)
<hallyn> stgraber: http://lkml.org/lkml/2014/8/13/746 will be the patch to fix it
<hallyn> can you test-build a kernel?
<hallyn> apw: I assume the quickest we could get http://lkml.org/lkml/2014/8/13/746 into a build is 3 weeks?
<stgraber> we obviously have two talks lined up at LinuxCon/Linux Security Summit next week which both demo nested unprivileged containers on Ubuntu... so looks like we'll need custom patched kernels or tweaked LXC which means people following those talks won't be able to reproduce what we show them...
<stgraber> hallyn, apw: filed bug 1357588
<ubot5> bug 1357588 in linux (Ubuntu) "3.13.0-24 broke nested unprivileged LXC" [Undecided,New] https://launchpad.net/bugs/1357588
<stgraber> and tagged as a regression in an udpate
<stgraber> *update
#ubuntu-kernel 2014-08-16
<bjf> stgraber, are you demoing with trusty or utopic ?
<bjf> stgraber, if trusty, yes 3/4 weeks. if utopic, sooner
<stgraber> bjf: I currently run utopic with a trusty kernel because wifi sucks with the utopic one, but I don't really need wifi for the demo so I could reboot on 3.16
<apw> stgraber, so this has been broken since before release in 3.13 and we didn't notice ?
<stgraber> apw: no, this was broken by the last kernel upload to trusty
<stgraber> oh, misread, sorry
<stgraber> yeah, then, though that was in a security fix so it didn't exactly had much time to be tested in proposed
<stgraber> or even upstream I suspect
<israel> Hi, I have a non-PAE specific question regarding 14.04  is anyone available who understands this well enough
<israel> according to https://help.ubuntu.com/community/PAE (part C at the end) could dd 'install' 14.04 on a non-PAE machine rather than swapping out HD?
<israel> hmmm... kinda quiet here...
#ubuntu-kernel 2014-08-17
<stevespiegel> hi. I'm building kernel packages from the ubuntu team's  git repository. is there a way to generate packages for  one flavor only? I see in the docs how to build for one  arch, but nothing about flavor builds
<dorimon5> helo!, need some help, my ubuntu server always get hang under heavy load after 4-6 hours. when i monitor the dmesg. i get this message before it finally hang. "perf samples too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 50000". is these kernel issue?
#ubuntu-kernel 2015-08-10
<genkgo> jsalisbury: do i understand correctly that patches from bug 1445195 are merged in 3.19 kernels?
<ubot5> bug 1445195 in linux (Ubuntu Precise) "[Hyper-V] Kernel patches for storvsc" [High,Triaged] https://launchpad.net/bugs/1445195
<bjf> genkgo, that is correct
<genkgo> bjf: thanks, that is great. then i am going to take them into production.
<rbasak> smb: could you help triage bug 1483214 please? Does this need a linux task?
<ubot5> bug 1483214 in openipmi (Ubuntu) "ipmi_si module spams kernel log with "ipmi_si 00:05: Could not set the global enables: 0xcc."" [Undecided,New] https://launchpad.net/bugs/1483214
<smb> rbasak, sounds like there is a kernel fix for the message. The module itself getting probed may be a feature through better detection
<rbasak> smb: yeah, I think that the reporter just wants the message upstream fix cherry-picked into Vivid's kernel and then to HWE, which sounds reasonable to me.
<rbasak> smb: do I need to create a linux task to make sure that hits your team's queue?
<smb> rbasak, I just replaced the meta package which was there (and not correct)
<rbasak> Ah, great. Thanks!
<bdmurray> This image could use updating https://wiki.ubuntu.com/Kernel/Support?action=AttachFile&do=get&target=14.04.x+Ubuntu+Kernel+Support+Schedule.png
#ubuntu-kernel 2015-08-11
<tseliot> apw: hi. Shall I fix the binary blobs for Linux 4.2 in the PPA? Also, does that include rtg's commit for the workqueue?
<apw> tseliot, i believe his change is applied, checking
<apw> tseliot, yes -3.3 has it
<tseliot> apw: excellent
<apw> tseliot, and yes shove those in the PPA to get that
<apw> or indeed feel free to copy them out with binaries into your own PPA
<apw> that also works
<tseliot> yes, I only need to grab the packages for my chroot to see what broke
<apw> as i assume they can go into -proposed first
<apw> and indeed should if possible
<tseliot> right
<tseliot> apw: fglrx doesn't seem to fail here with 4.2
<apw> tseliot, great
<tseliot> I'll try the nvidia drivers
<apw> tseliot, the nvidia ones claim to work on the matrix
<tseliot> err... my nvidia 352 is still stuck in NEW
<apw> but not fgrlx
<apw> http://people.canonical.com/~kernel/info/dkms/int-matrix.html
<apw> so that is rather odd
<tseliot> apw: it only seems to fail on i386
<apw> tseliot, oh, odder
<apw> tseliot, and indeed that is what the matrix says too
<tseliot> error: implicit declaration of function Ã¢â¬Ë__xgÃ¢â¬â¢
<tseliot> which, garbage aside, is  : "q"(new), "m"(*__xg(ptr)), "0"(old)
 * tseliot needs to create an i386 wily chroot...
<apw> tseliot, new compiler perhaps
<apw> oh .. an actual removed __foo thing
 * tseliot nods
<om26er> on wily bcmwl fails to build if I install linux 4.2 rc6: here are the logs http://paste.ubuntu.com/12054833/
<om26er> anyway to workaround/fix that ?
<apw> om26er, there is an upstream fix coming for that which is appplied to our 4.2 kernel in the ckt PPA
<apw> tseliot, i didn't realise the fix for nvidia also fixed brcm
<tseliot> apw: IIRC rtg said he fixed bcmwl (?)
<om26er> apw, great, I'll install from there.
<apw> tseliot, he may have fixed it by fixing the kernel, or it had two issues and the second was already fixed by nvidia
<tseliot> right
<tseliot> well, it's always a win when I don't have to fix things myself ;)
<TJ-> Oh, you're on about the flush_workqueue() licence change? I reported it originally back in June but haven't kept track - has 4.2 mainline fixed it?
<apw> TJ-, it wasn't technically a flush_workqeue licence change, it was a caller becoming inline
<apw> but yes that is the one we are talking about
<apw> a fix for it seems to have been taken by the sub-system maintainer, but clearly is not in -rc6
<TJ-> apw: yeah I know, but that was the effect
<TJ-> OK ... thanks... I only found it because I was building 4.2 with some major PCI subsystem fixes for testing and the nvidia driver failed to build
<apw> yeah that'd do it indeed
<unixabg> apw: Greetings just checking in on the overlayfs and casper (or so I think but I could be wrong) status.
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting today @ 17:00 UTC
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Aug 18th, 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/
<cristian_c> jsalisbury: hello
<cristian_c> jsalisbury: I'd like to know if you have contacted the author of commit
<gQuigs> there's no ubuntu/ubuntu-wily.git?  where could I get the ubuntu kernel config for wily? - http://kernel.ubuntu.com/git  (Ideally I'd just want to know the difference between it and 14.10) 
<apw> gQuigs, there is a git repo for it, its in launchpad, we are starting to migrate, very very slowly
<apw> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily  iirc
<gQuigs> apw: oh.. awesome; thanks!
#ubuntu-kernel 2015-08-12
<bdmurray> jsalisbury: What's the status of bug 1436940?
<ubot5> bug 1436940 in linux (Ubuntu Wily) "Atheros wifi 168c:0041(QCA6164) is not supported" [Medium,Confirmed] https://launchpad.net/bugs/1436940
<jsalisbury> bdmurray, let me take a look and see
<cristian_c> jsalisbury: hi
<cristian_c> jsalisbury: jsalisbury: I'd like to know if you have contacted the author of commit
<jsalisbury> cristian_c, not yet, I plan on getting to it shortly
<cristian_c> ok
<jsalisbury> bdmurray, looks like the activity has stalled upstream.  I'll ping the maintainers directly and see if the updated firmware is available yet.
<bdmurray> jsalisbury: okay, thanks
<jsalisbury> bdmurray, The upstream maintainers have been notified that many folks are still waiting on new firmware.  I'll let you know what the response is.
<bdmurray> jsalisbury: Okay, I brought it up because I get all these emails regarding the bug.
<jsalisbury> bdmurray, thanks, I'll let you know what they say
#ubuntu-kernel 2015-08-13
<jsalisbury> bdmurray, Upstream replied with a recently found work around for bug 1436940 .  However, it's not the most elegant solution.  It requires booting with unofficial windows-extracted firmware images.  More info in comment #20 of bug. 
<ubot5> bug 1436940 in linux (Ubuntu Wily) "Atheros wifi 168c:0041(QCA6164) is not supported" [Medium,Confirmed] https://launchpad.net/bugs/1436940
<jsalisbury> bdmurray, well that was fast.  There is now real firmware here: https://github.com/kvalo/ath10k-firmware/commit/7f7e7dda33676ced293de477b03711199ffe5256  I'll update the bug report.
<tseliot> apw: how do I find out what (upstream) kernel release linux 3.19.0-26 is based on? (I need to add a check in my kernel code for fglrx)
<apw> tseliot, http://people.canonical.com/~kernel/info/kernel-version-map.html
<tseliot> apw: thansk
<tseliot> *thanks
<tseliot> apw: so 3.19.0-26 = 3.19.8-ckt2, but how do I use that with the KERNEL_VERSION macro?
<apw> oh you can't
<apw> don't be sillly converting to a number broke you
<tseliot> apw: apparently 3.19.0-25 -> 3.19.0-26 made a symbol gpl-only
<apw> to a ckt-N name, well and that it is in 4th
<apw> welll you can tell -25 and -26 apart
<tseliot> how?
<apw> UTS_UBUNTU_RELEASE_ABI
<apw> which is defined in the same place as you get other versions from
<apw> you want something like
<apw> #ifdef UTS_UBUNTU_RELEASE_ABI
<apw> #define UBUNTU_VERSION KERNEL_VERSION * 100 + UTS_UBUNTU_RELEASE_ABI
<apw> #else
<apw> #define UBUNTU_VERSION KERNEL_VERSION * 100
<apw> #endif
<apw> or something
<apw> 100 isn't enough i expect
<tseliot> I think checking the Ubuntu ABI would be enough. So, if none is available I can define the ABI as 0
<tseliot> and check the kernel version
<tseliot> ok, that helps
<tseliot> thanks
<apw> yeah
<apw> tseliot, yeah thats why we don't provide accessors, as you have to check they exist and provide your own if no
<apw> as you can't assume we are ubuntu, ugg
 * tseliot nods
<tseliot> apw: are you sure that UTS_UBUNTU_RELEASE_ABI is available in the lts-vivid kernel?
<tseliot> I'm doing this:
<tseliot> #ifndef UTS_UBUNTU_RELEASE_ABI
<tseliot> #define UTS_UBUNTU_RELEASE_ABI -1
<tseliot> #endif
<tseliot> #if UTS_UBUNTU_RELEASE_ABI < 0
<tseliot> and that always seems to be true
 * tseliot clones the git repository...
<apw> debian/rules.d/2-binary-arch.mk:        echo "#define UTS_UBUNTU_RELEASE_ABI $(abinum)" >> $(hdrdir)/include/generated/utsrelease.h
<tseliot> hmm...
<apw> /usr/src/linux-headers-3.19.0-14-generic/include/generated/utsrelease.h:#define UTS_UBUNTU_RELEASE_ABI 14
<apw> and there it is in a 3.19 i have installed
<tseliot> ok
<apw> so unless it is getting lost in the lts-backport, which is pretty unlikely
<tseliot> I can see it here. Do I have to include that header or is that already exported?
<apw> i thouoght if you included the one with KERNEL_VERSION it was incldued
<apw> but perhaps not
<tseliot> that would be a  bit of a problem
<tseliot> as custom kernels won't have utsrelease.h
<apw> why not ?
<apw> its a standard include
<apw> #define UTS_RELEASE "3.19.0-14-generic"
<apw> #define UTS_UBUNTU_RELEASE_ABI 14
<apw> it has the UTS_RELEASE string in it
<apw> which would be 3.19.8-ckt3 normally
<tseliot> my fix has to go into fglrx, and I need it to build against custom kernels that may not have that header
<tseliot> if I add an #include in the fglrx code, it won't find the header in /usr/src/linux-headers-$(uname -r)/include/generated/
<tseliot> apw: oh, wait, fglrx already does that
<tseliot> except they get it wrong
<tseliot> as they include it only #ifndef UTS_RELEASE
<tseliot> no they don't
<tseliot> ok
<tseliot> it's included in the wrong file
<tseliot> apw: problem solved :)
<dkessel> i want to run the trusty kernel version (3.13) on my vivid and wily installations. is there an easy way of doing that?
<dkessel> i have the problem that power saving is properly working with the trusty kernel, but with vivid and wily's kernels, only one "performance" and "powersave" governors seem to be available. and "powersave" uses more power than in trusty, which i notice because the fan is working all the time, instead only when doing cpu-intensive tasks
<ohsix> that could just be a matter of the fan never going off, and those governors are going to be separate from thermal policy stuff thaty may have also changed
<ohsix> are you looking at powertop to see if more power is actually being used? (disregarding just fan being on uses more)
<apw> dkessel, no easy way of doing that no, we do not assume compatibility in that direction
<dkessel> okay. ok, so i did some more searching and found that disabling intel_pstate works for me, as i found in bug 1188647
<ubot5> bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix released] https://launchpad.net/bugs/1188647
<dkessel> kernel 4.1.0-3 does not work good without disabling it
<dkessel> do you think i should collect some more information and file a bug? (yes, i have read the channel topic....)
<apw> dkessel, yes you should file a bug indeed if pstate_idle is breaking you on 4.1, it should be "purfect" by now
<apw> dkessel, ubuntu-bug linux so we get appropriate h/w info
<dkessel> ok, here's bug 1484616 . if i can provide any more info, try anything else, just tell me :)
<ubot5> bug 1484616 in linux (Ubuntu) "pstate_idle is broken on 4.1, high fan speed when idle" [Undecided,New] https://launchpad.net/bugs/1484616
#ubuntu-kernel 2015-08-14
<cetex> where can i find linux-tools for kernel-ppa kernels? or do i need to build it myself?
<cetex> i'm running 4.0.9 on ubuntu 15.04 and need "x86_energy_perf_policy" from linux-tools.
<apw> we dont build tools i dont believe
<baojg> hang in compile mainline stable kernel ,the output is  linux-stable/scripts/mkmakefile: line 19:  9955 Trace/breakpoint trap   (core dumped) grep -q Automatically $2/Makefile
<baojg> i change the make concurrent level to 1,the compile pass.
<baojg> why?
<baojg> some backgroud: 3.18.20 stable kernel,three ubuntu patch applied,  fakeroot debian/rules clean;fakeroot debian/rules binary-headers binary-generic
<baojg> the hang occurs on the binary-generic stage
<baojg>  hang in compile mainline stable kernel ,the output is  linux-stable/scripts/mkmakefile: line 19:  9955 Trace/breakpoint trap   (core dumped) grep -q Automatically $2/Makefile
<baojg> i change the make concurrent level to 1,the compile pass.
<baojg> why?
<baojg> some backgroud: 3.18.20 stable kernel,three ubuntu patch applied,  fakeroot debian/rules clean;fakeroot debian/rules binary-headers binary-generic
<baojg> the hang occurs on the binary-generic stage
<baojg> hi,anybody here?
<tseliot> apw: jenkin seems to hate me. The build succeed but they are still marked as a failure (look at the logs): http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/W%20-generic/job/dkms-wily-release-generic-fglrx_core/
<jmss> Hi, does someone know why kworker threads are "always" writing (with a period of a few seconds)?
#ubuntu-kernel 2015-08-16
<apw> jibel, seems some of the recent dkms builds are "pass" in the summary.log but failures in jenkins, i assume this is a harness failure ... fgrlx as an example
<apw> fglrx_core specificiallly
#ubuntu-kernel 2016-08-15
<bjf> stgraber, can you point me at the latest version of you lxc exercise script?
<stgraber> bjf: https://github.com/lxc/lxc-pkg-ubuntu/blob/dpm-yakkety/debian/tests/exercise
<stgraber> so whatever we currently have in the archive
<jbicha> hi, should Ubuntu follow this? https://bugs.debian.org/795090
<ubot5> Debian bug 795090 in perf-tools-unstable "perf-tools-unstable: please update Depends: linux-tools to linux-perf" [Normal,Fixed]
<jbicha> perf-tools-unstable is currently uninstallable in yakkety-proposed because of that
<jbicha> I'm thinking about just reverting the change in Ubuntu's perf-tools-unstable for now
#ubuntu-kernel 2016-08-16
<Laney> sooooooo
<Laney> We have a big migration in yakkety-proposed, which the kernel is involved in unfortunately
<Laney> don't suppose the new one could be unblocked today? :-)
<rtg> dannf, can you boot a Yakkety 4.6 kernel from ppa:canonical-kernel-team/ppa no bare metal ?
<rtg> on bare metal*
<dannf> rtg: lemme try
<dannf> rtg: it isn't booting on a mustang - no output. i had been testing 4.6's on here succesfully before though
<rtg> dannf, modularization of the console perhaps ?
<dannf> will check
<gpiccoli> Hi, sorry to bother you all. Need some help/advice:
<gpiccoli> is there a way to perform a netboot install with some older kernel to test a regression?
<gpiccoli> I want the 4.4.0-31, whereas the latest is 4.4.0-34 I guess...Xenial speaking here
<gpiccoli> In other words, I need an older installer image. Is there such thing available?
<gpiccoli> hmmm...in fact seems my netboot kernel is 4.4.0-31
#ubuntu-kernel 2016-08-17
<Mirv> any chance of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux today? (bug #1609913) all other transitions are now waiting for that and we have halted publishing of Touch related packages to yakkety to not interrupt the transition
<ubot5> bug 1609913 in Kernel Development Workflow "linux: 4.6.0-10.12 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1609913
<infinity> Mirv: I'm fixing differently.
<infinity> Mirv: Deleting 4.6 from -proposed and rebuilding 4.4 against the new binutils.
<infinity> Mirv: But that's taken some back and forth.  See my ranting in #-devel.
<infinity> Mirv: Anyhow, I'm pretty sure I have it licked this time, so once an arch or two passes my current test build, I'll call it good and upload a non-test build.
<infinity> And pray a bit.
<infinity> And then ~5h later, we should have a migration.
<Mirv> thanks for the update infinity!
 * Mirv reads backlog rants
<infinity> Mirv: Long story short; no one expected the kernel to get caught in this transition (like, seriously, WTF), but the kernel team's been working on making 4.6 sane, and I've put in some non-work hours to fix your immediate issue with a hacked-up 4.4.
<infinity> Mirv: So, feel the love. :P
<Mirv> indeed wtf. everyone will feel infinity's love once transition happens. the whole community comes and hugs you for weeks.
<hallyn> sforshee: what woudl be the best ppa to use to test a 4.6 kernel in yakkety?
<hallyn> should i use mainline for that or is there an actual wip ppa?
<rtg> hallyn, ppa:canonical-kernel-team/ppa
<hallyn> thx
<hallyn> drat, lxd fails to start there
<hallyn> bc lxcf sfailed, bc there is no fuse module?
<sforshee> hallyn: I would just download the debs from the c-k-t ppa - https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+packages
<hallyn> which deb has the fuse module?
<sforshee> linux-image-extra
<sforshee> probably anyway, either that or linux-image
<hallyn> sforshee: phew, that gives me fuse.  odd that it moved to -extra, this means lxcfs package will have to depend on that
<sforshee> hallyn: it's been that way for a while now
<hallyn> hm?  i installed a yakkety vm, lxcfs came up fine.  added the ppa, upgraded, lxcfs did not come up.  which suggests fuse moved between the 4.4 pkgs in yakkety and 4.6 in ppa
<sforshee> hallyn: oh, seems that fuse used to be built-in
<sforshee> might be a good idea to include it in linux-image then, we probably want lxcfs to work out of the box on the server install
<sforshee> rtg: ^
<hallyn> awesome - thanks
<hallyn> meanwhile, i was mainly wanting to reproduce https://github.com/lxc/lxcfs/issues/125 , but it doesn't fail, so yay for that
<hallyn> \o
<rtg> CONFIG_FUSE_FS=m
<sforshee> rtg: in xenial it's =y
<rtg> sforshee, but not in Yakkety
<sforshee> rtg: right, I'm saying we should probably include it in linux-image if it's going to be a module because lxd needs lxcfs, which in turn needs fuse
<rtg> sforshee, ah, right
<rtg> sforshee, done
<sforshee> rtg: thanks
<u554c46> hello, i have skylake problems. i upgraded to kernel 4.7.1, and installed the intel drivers manually. however it seems to overheat. i am sure there are modules not activated or similar. i don't know how to fix it
<u554c46> anyone here?
#ubuntu-kernel 2016-08-18
<tgm4883> Odd question. I'm about to try bisecting the kernel and I'm not sure if the updated 4.6 kernel I installed is mainline or has ubuntu changes. Is it correct to assume that this verson (4.6.0-040600.201605151930) shows it's the mainline kernel where this version (4.6.0-9.11) shows it's the yakkety kernel?
<tgm4883> Odd question. I'm about to try bisecting the kernel and I'm not sure if the updated 4.6 kernel I installed is mainline or has ubuntu changes. Is it correct to assume that this verson (4.6.0-040600.201605151930) shows it's the mainline kernel where this version (4.6.0-9.11) shows it's the yakkety kernel?
<rtg> tgm4883, that should be obvious after looking at the recent commits in your repository. An Ubuntu distro repo will have dozens of 'UBUNTU:' commits.
<tgm4883> rtg: heh, I haven't checked out the repository yet, just installed the prerolled packages from the PPA. That's actually why I was wondering, before I bisect I want to make sure I know where the working version is
<rtg> tgm4883, well, the mainline kernel is pretty much vanilla upstream.
<tgm4883> Yep, I'll probably just download the ubuntu kernel packages from the ppa again, test that it's fixed and then I'll be able to clone and build from the right repository
<tgm4883> The difficult part is that it's not an issue that shows up immediately, so it takes some time to test
#ubuntu-kernel 2016-08-19
<jsheeren> hi there
<jsheeren> quick question about running the cloudimages on an openstack platform and specificaly io performance differences between stock xenial and stock trusty with a xenial-lts kernel installed through apt
<jsheeren> are there differences in the kernel options?
<jsheeren> the xenial cloud image with kernel 4.4.0-24-generic has almost 2 times better IO performance than the trusty cloud image with the xenial-lts 4.4.0-34-generic kernel
<jsheeren> which i find surprising as i would expect the same performance
<mdeslaur> jsheeren: just a theory, but the xenial kernel is built with a newer gcc
<mdeslaur> 5.4.0 vs 4.8.4
<xnox> better/newer userspace too? (depending on how the testing is done....)
<mdeslaur> that too
<jsheeren> so the xenial kernel for xenial is built with 5.4.0, the xenial kernel for trusty is built with 4.8.4?
<mdeslaur> yep
<xnox> jsheeren, the package for each release is built in the target release build chroot. So all of toolchain for -lts kernels is from the target distro. Everything including things like binutils, glibc, compilers, etc.
<xnox> the backport kernels are just that -> new source code, new package name, compiled on an old release.
<jsheeren> just to add hardware compatibility, but not to enhance performance, etc?
<xnox> it's not a .deb / binary copy. (that would result in naming clash)
<jsheeren> is it doable to upgrade the gcc on trusty to the version on xenial?  or are there too many dependencies that will bork?
<xnox> jsheeren, there are multiple reasons and multiple usecases as to why hwe kernels were started to be provided. It's a mix of hardware compat / performance / (new)security features
<xnox> no no no no
<xnox> that would break the ABI
<xnox> on c++
<jsheeren> ok
<xnox> i mean kernel is special, cause it's stand-alone / freestanding code.
<xnox> but we would not do that.... Upgrade to xenial perhaps? =)
<xnox> it is shiny =)
<mdeslaur> it's got the "new car" scent
<jsheeren> xnox: yeah if we run a do-release-upgrade on trusty so we end up with a xenial, the performance issue is the same
<jsheeren> we've looked at a lot of stuff
<jsheeren> using the same hypervisor, same openstack flavor, etc
<jsheeren> a bit stumped at the moment on why we are seeing the IO performance difference that is so large at the moment 
<jsheeren> we compared the sysctl settings as well but did not see any differences that would impact IO
<xnox> jsheeren, your findings would be interesting. To rule things out, you /could/ *warning not supported* enable xenail repository on trusty, pin it down below trusty with apt-pinning, install/upgrade generic kernel from the xenial repository with e.g. apt install linux-generic/xenial, see what happens.
<jsheeren> ah yeah, could try that
<xnox> this way you will rule out if the $userspace in xenial affecting benchmarks, or indeed the 4.4 kernel compiled on xenial, when running trusty userspace, is better.
<jsheeren> we tried copying the files from a xenial to a trusty but that did not go so well ... heh
<xnox> yeah.... partial apt upgrade to xenial to get new kernel from xenial rather than via hwe-stack is *safer*. Still a frankenstein =)
<jsheeren> https://gist.github.com/beci/2a2091f282042ed20cda   this is a no go then?
<phillw> I take it that the 9134 version is the latest.... Quite a step change from the last one?...
<phillw> phillw@piglet:~$ ls -lt /boot/abi*
<phillw> -rw-r--r-- 1 root root 1241623 Aug 16 23:23 /boot/abi-4.4.0-9134-generic
<phillw> -rw-r--r-- 1 root root 1241623 Jul 27 22:28 /boot/abi-4.4.0-34-generic
<phillw> Kindest Regards,
<phillw> Phill.
#ubuntu-kernel 2016-08-20
<phillw> anhgg any news on 4.4 kernel?
<phillw> hggdh: ^^
#ubuntu-kernel 2016-08-21
<phillw> Hi good people, I'm testing yakkety and seem to have acquired a kernel not in the usual numbering system.... 4.4.0-9134-generic I was expecting some more along the lines of 4.4.0-35-generic etc. 
<phillw> 1) Would I be best placed to remove this one so that the numbering sequence reverts and 2) how did this occur?
#ubuntu-kernel 2017-08-14
<jjohansen> ogasawara: fyi I have a 4.13 test kernel with the LSM stacking patches on it, well LSM stacking minus the secid stacking bits, Casey is still working on those
<ogasawara> jjohansen: ok cool, need any assistance with testing/review?
<ogasawara> apw, bjf, sforshee: ^^ fyi
<jjohansen> its built for amd64 in  https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-devel 4.13.03..4+stack6
<jjohansen> I didn't bother modifying the build files for i386, arm, ... that is why it only built for am64
<jjohansen> I still need to push my artful unstable git tree some where
<sforshee> jjohansen: oh btw, a heads up, the artful 4.13 development has been moved to unstable/master as of late last week
<sforshee> so that's where I pushed the rebase to -rc5
<jjohansen> sforshee: ack thanks
<mwhudson> have any of you seen https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1679768 ?
<ubot5> Ubuntu bug 1679768 in linux (Ubuntu) "Docker build hangs on XFS with kernel 4.10" [Undecided,Incomplete]
<ScottE> mwhudson: We have run into that problem (one of the comments there is mine). I'm not sure I have any more details than what's in the bug, but am happy to try and help from our side.
<mwhudson> ScottE: i get it as docker.io maintainer but it seems pretty clearly not a docker.io problem to me...
<mwhudson> so need to attract kernel team attention :)
<ScottE> I think that's true - current suspicion is that it's either in XFS or AUFS. It does not occur with previous kernel, we're going to test the latest hwe backport (4.11).
#ubuntu-kernel 2017-08-15
<xnox> apw, do we still need kmod, if we have systemd-modules-load thing?
 * xnox wonders if the systemd-modules-load actually masks kmod already
<xnox> ah it does, via systemd. It ships kmod.service -> systemd-modules-load.service symlink
<tyhicks> if I'm doing artful backports of some patches that were recently acked upstream to land in 4.14, what git tree/branch should I be targeting? the master branch of the unstable tree?
<sforshee> tyhicks: that or artful/master-next, whichever is more convienient for you
<sforshee> if it only applies to one or the other and I can't figure out how to reconcile it, then I'll ask you to provide it for the other one ;-)
<sforshee> or if they are in linux-next already you can just give me the sha1's and I can cherry pick them directly
<tyhicks> I think it'll apply cleanly to 4.13 and will need a little work to 4.12 so I'll do the backport to artful/master-next and then reference the sha1's from linux-next for unstable/master-next
<sforshee> wfm
<sforshee> jjohansen: do you have an ETA for apparmor sauce for 4.13?
<jjohansen> sforshee: my 4.14 pull request is going out this week, so I should be able to get you it by the end of week
<jjohansen> there will be a couple of patches that are in revision and are targeted to 4.15 that we will probably get some revision, but we can revert and apply newer iterations as needed
<sforshee> jjohansen: sounds great, thanks
#ubuntu-kernel 2017-08-16
<cyphermox> any reason we don't have CONFIG_JFS_DEBUG set? the doc says "very little overhead" :)
<apw> cyphermox: debug stuff is mostly off unless someone asks for it, with a good use case. especially as they are rarely free
<tseliot> apw: hey, what git branch shall I use to get a patch into the kernel of 16.04.3?
<apw> tseliot, that had the linux-hwe kernel in it, which is 4.10 derived, which is zesty base, so againts zesty/master-next if its a code change
<tseliot> apw: and will that also get the patches into the xenial 4.10 kernel too automatically?
<apw> tseliot, yes, that is a direct backport
<tseliot> apw: ok, then I will have to send the patches to the mailing list and tag them as [zesty] , right?
<apw> SRU zesty yeah
<tseliot> ok, thanks
<apoz> Hi all
<apoz> Iâm having some problem with a kernel error in syslog for some IPv6 packets (ICMPv6)
<apoz> what would be the best way to have some support?
<apoz> (I just posted a question in launchpad for the moment)
<apw> apoz, if you have a kernel trace then filing a bug against the kernel (ubuntu-bug linux) and attaching that is a good start
<apw> then drop the bug number in here
<apoz> ok, Iâll try that
<apoz> a trace with systemtap is ok?
<apoz> or I should try to get something else?
<apw> apoz, i mean if you are getting a kernel message in dmesg
<apw> not a "make a trace" the kernel message dump is often called a kernel trace
<apoz> ok, Iâll include all the info Iâve got already in the bug
<apoz> I just filled the bug with all the info Iâve got in Bug #1711124
<ubot5> bug 1711124 in linux (Ubuntu) "âIPV6 header not foundâ log with ICMPv6 with QinQ" [Undecided,New] https://launchpad.net/bugs/1711124
<apoz> thanks!
<apw> tjaalton, hey ... my touchpad seems to (as of today) a very small bottom click area ... if my finger is on the touchpad more than a few mm the other finder can no longer move the cursor ... mean anyting to you ?
<apw> (lenovo x250)
<apw> tjaalton, ahh ok ... removng xserver-xorg-input-synaptics sorted it ...
<tjaalton> apw: yeah we've essentially migrated to -libinput by now
<tjaalton> synaptics could have issues
#ubuntu-kernel 2017-08-18
<tjaalton> apw: so now you get to bisect 4.11..4.12 for the touchpad issue? :)
<apw> yay
<xnox> apw, config/s390x/config.common.s390x:# CONFIG_BLK_DEV_NVME is not set
<xnox> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708432
<ubot5> Ubuntu bug 1708432 in linux (Ubuntu) "[17.10 FEAT] Enable NVMe driver - kernel" [Undecided,New]
<xnox> is there something i can do to the bug, to raise attention? should i prepare and mail patch to ubuntu kernel mailing list?
<xnox> or is this done, because CONFIG_BLK_DEV_NVME_SCSI=y ?
<apw> xnox, not sure if that means it is on or not, i don't suppose any of our kit has those in it ...
<xnox> apw, it does sound like a forward looking thing e.g. z14 or maybe even later.
<xnox> thus yeah, we deffinately do not have kit.
<apw> xnox, anyhow you have done the right thing to raise it to my attention
<xnox> apw, thank you sir.
<dasjoe> So, I've got some TB3 and USB-C docks with an (as of now) unsupported Realtek r8152. I've built a PPA for realtek's drivers, as the new revisions will be supported from 4.13 onwards. Is there a process to SRU specific drivers into xenial, or is the usual method to just wait it out?
<apw> dasjoe, it all depends how self-contained the changes are to support that, if it looks tractible it is not impossible to have it SRUd
<apw> dasjoe, and of course if it is in 4.13 that will be a linux-hwe kernel in xenial at some point
<loganaden> hello
<dasjoe> apw: well, it's this commit: https://github.com/torvalds/linux/commit/65b82d696b9e84fda6dd7df61801b57d3e7fb976
<dasjoe> Although I went a different way and built my PPA from realtek's source
#ubuntu-kernel 2017-08-19
<loganaden> ogasawara: hello
<loganaden> kees: ping
<Tester2009> pong
#ubuntu-kernel 2017-08-20
<_Xenial_Xerus_> Is there any way to get  them to modify the kernel code for LUKS.
<_Xenial_Xerus_> I can make some sort of lustration about why the keys need to be on a seperate partition.
<_Xenial_Xerus_> Picture of a man pulling out the SDCARD.
<_Xenial_Xerus_> Walking past police beating checkpoints.
<_Xenial_Xerus_> Reaching the F.D.L. (food distribution location) and then returning to the computer without 8 necrosan neighbors data dumping the entire system during a home invasion.
<_Xenial_Xerus_> JanC call up infinity
<JanC> ?
<JanC> I think you need to read documentation
<_Xenial_Xerus_> Oh, you make a funny?
<JanC> how to do what you ask for is explained in the cryptsetup manual (see e.g. the --header option)
<_Xenial_Xerus_> JanC manually from a running kernel?
<_Xenial_Xerus_> backup and restore header
<_Xenial_Xerus_> This requires a second system.
<_Xenial_Xerus_> Too much.
<JanC> LUKS can have the key(s) on a separate device; you can suspend/resume a LUKS-encrypted device (suspend here means that the kernel erases the encryption key from memory); if you want you can automate the suspend/resume with udev or the like
<_Xenial_Xerus_> JanC LUKS now allows for the header to be stored on /boot?
<_Xenial_Xerus_> Can this be done from the ubuntu installer?
<_Xenial_Xerus_> Last I looked into it the only way to remove the keys is to do a backup/restore manually from command line.
<JanC> I think it always did, but maybe not from the installer
<_Xenial_Xerus_> The LUKS code stores the keys in the header and the header at the start of the encrypted part.
<JanC> AFAIK the kernel doesn't really care where the header/keys are; storing it there is just the default/usual way to do it with cryptsetup & most linux installers
<JanC> (and you can always use bare dm-crypt also)
<_Xenial_Xerus_> LUKS is designed so.
<_Xenial_Xerus_> The keys are stored in the header, the header the beginning of the crypt part.
<_Xenial_Xerus_> What do you mean bare dm-crypt, no LVM?
<_Xenial_Xerus_> JanC?
<JanC> meaning dm-crypt without LUKS
<_Xenial_Xerus_> LUKS uses dm-crypt doesn't it?
<_Xenial_Xerus_> It wraps the partition in an encrypted LVM.
<_Xenial_Xerus_> Here we go turning support into an argument.
<_Xenial_Xerus_> What is the command for pulling the current source?
<_Xenial_Xerus_> sudo apt-get source linux?
<_Xenial_Xerus_> or is it, sudo apt-get --download-source linux?
<_Xenial_Xerus_> Or is it trapped with dependency injections?
<_Xenial_Xerus_> JanC leaving the kernal as it is for now then, do you want to work on moving the /boot to an ISO with isolinux
<JanC> see: https://skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/
<_Xenial_Xerus_> Did you writup my specs and predate it?
<xnox> _Xenial_Xerus_, please use some other irc nickname, this one is tasteless
<_Xenial_Xerus_> xnox: what is tasteful?
<_Xenial_Xerus_> better?
<ubuntu> better?
<xnox> now, yes =)
#ubuntu-kernel 2018-08-15
<ricotz> klebers, hi, please re-try https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/15263551
<klebers> ricotz, just did, thanks for the notice!
<ricotz> klebers, thanks
#ubuntu-kernel 2018-08-16
<Kon-> Hi, after updating the kernel on Bionic, dpkg shows I have both 4.15.0-32.35 and 4.15-32.34 installed
<Kon-> https://images2.imgbox.com/1c/20/xLsu5m6M_o.png
<Kon-> Package history tells me many 30.32 files were upgraded to 32.34, but then 32.35 files were installed for the first time
<Kon-> Here's the package history showing some files were upgraded to 32.34 while 32.35 was also installed https://images2.imgbox.com/4f/5c/lA8G6cNc_o.png
<apw> Kon-, no that is showing you you have linux-image-* at 4.15.0-32.35 and linux-image-generic at 4.15.0.32.34 ... the first is always new, the second is upgraded; but they are distinct
<apw> the second is the meta package and comes from a different source; it is this that drives installation of the other
<apw> this is the mechanism by which it is possible to have >1 kernel installed
<juliank> I'm seeing files disappearing on my btrfs system on 4.17 (a few each day). I guess I'll revert to 4.15 and see if that is affected too. Is there any data I should collect?
<juliank> My $HOME is pretty well backed up so I'm not worrying a lot
<tsimonq2> Git bisect? XD
<juliank> that's with the -6 kernel
<juliank> tsimonq2: It needs a day per step...
<juliank> roughly
<juliank> I see at least one new file disappearing each day
<tsimonq2> Ah, I was half joking, but hey :)
<juliank> today it ate my keepass keyfile
<juliank> now I gotta copy it over again from my other machine :/
<juliank> or the backup, I think it has a copy as well
<juliank> And the backup server runs ZFS in raid-z2 I think, so that data is fairly safe
<tsimonq2> Perhaps try and find a pattern...
#ubuntu-kernel 2018-08-17
<m0x90> Hello! I'm trying to find dbgsym for the mainline builds (for 4.17.x), any insight where could I find them?
#ubuntu-kernel 2019-08-12
<fling> I built a kernel with shiftfs patches I extraced from a git repo.
<fling> But it does not show up in lxd.
<fling> What am I missing?
<fling> # CONFIG_SHIFT_FS is not set
#ubuntu-kernel 2019-08-13
<lotuspsychje> tjaalton: confirming 5.0.0.25 gets the flickering aswell on the clevo
<tjaalton> no wonder
#ubuntu-kernel 2019-08-14
<matti> fling: It looks like you need to enable support for it in the Kconfig, and then build again :)
<h3rbz> Hi! I'm running Bionic, with a manual kernel selectionn (4.18, not 4.15, currently). This kernel does not get updates installed when running `apt upgrade'. Is there a way to have apt manage a non-standard linux-image version? Or, should I work around it myself? thx!
<h3rbz> Am I right to assume that updates do work for 4.15, because it is selected by the meta-package (e.g. linux-image-generic)?
<tjaalton> h3rbz: 4.18 was from cosmic, which is now EOL
<tjaalton> if you want to stay on the hwe kernel, install linux-image-generic-hwe-18.04 which would pull 5.0 now
<lotuspsychje> tjaalton: good news, tomreyn found booting intel_idle.max_cstate=4 fixxed my issue on 5.0.0.25 keeps working after suspend aswell
<tjaalton> just a workaround then
<tomreyn> yes, a workaround
<lotuspsychje> yes
<tomreyn> we read this at https://bugs.freedesktop.org/show_bug.cgi?id=109215
<ubot5> Freedesktop bug 109215 in DRM/Intel "intermittent display on kaby lake/i915 from kernel 4.19 onwards" [Major,New]
<tomreyn> (where OP also runs a clevo)
<tjaalton> but doesn't say if it's fixed in 5.3 for him
<lotuspsychje> i tested a 5.3 and confirmed no flickering
<tjaalton> but he didn't
<lotuspsychje> no
<h3rbz> tjaalton: thx! I think I was not inderstanding exactly what this 'hwe' version is.
<h3rbz> I did not consider it, jsu as with lowlatency et. al.
<h3rbz> *just
<h3rbz> nice to have 5.x though :)
<h3rbz> meh.. is it true, that the cephfs kernel client does not support quota in 5.0.0?
<h3rbz> it did not in 4.15, it did in 4.18, that's why I installed it
<h3rbz> n/m my mistake. it works, I was just doing something stupid while testing :) thx anyway
<niluje> hi, which paramater should I give in the cmdline to get a shell in the initrd? break=init-top doesn't seem to work
<tjaalton> recovery?
<tjaalton> or just boot the recovery entry
<niluje> tjaalton: the answer is for me?
<tjaalton> yes
<niluje> tjaalton: you mean I should add the param "recovery" without option?
<tjaalton> look at what grub menu already has in /boot/grub/grub.cfg
<tjaalton> I think that should drop in initrd, but could be wrong
<tjaalton> anyway, there are boot entries for recovery mode, so just try with that first
<niluje> ok, thanks
<niluje> will try
<niluje> hm it doesn't work â I'm not sure why. I have a broken RAID, and I think adding "recovery" to the kernel cmdline attempts to mount the failing partitions which fails, and so it doesn't drop a shell. So I guess I need to drop a shell before
<tjaalton> https://wiki.ubuntu.com/DebuggingKernelBoot
<tjaalton> try break=premount
<tjaalton> or just break
<tjaalton> premount should be the default
<niluje> I already tried break, break=premount and break=top without success
<tjaalton> dunno then
<niluje> thanks a lot for your help :)
<tomreyn> just "break" works for me on bionic
#ubuntu-kernel 2019-08-15
<silesm> i'm trying to get 4.15.0-58-generic to boot on AWS metal instances and it's not passing the initial status checks
<silesm> i'm wondering how i can better understand the diffs between that kernel and the linux-aws kernel series so that i can base what i'm doing off of generic
<silesm> i need videodev, which isn't in the linux-aws kernels, but is in the generic kernels. but the generic kernels don't boot metal instances. :/
<logan-> i'm seeing very strange file permission behaviors on xenial lxc containers that cropped up in my jobs over the past 2 days. main difference i'm seeing is the nodes that worked 2 days ago had 4.4.0-157 based images, the nodes failing today have 4.4.0-159
<logan-> http://paste.openstack.org/raw/757170/ 
<logan-> stop/start of the container seems to fix it also 
<ldvsoft> Hello! In recent disco update I saw changelog entry "x86/cpufeatures: Carve out CQM features retrieval". What was that?
<ogra> ldvsoft, CVE-2019-1125
<ldvsoft> @orga, yeah, i got that, but I haven't found anyone mentioning that particular patch.
<ogra> there was discussion on LKML, i think it is spectre related 
<ogra> https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-1125.html
<ldvsoft> And I saw that page too) Where can I see the patches themselves, if it is possible?
<ldvsoft> Maybe I am just blind, but I have not found that CQM-related change.
<ogra> i'd dig on LKML
<ogra> it isnt an ubuntu patch after all 
<ogra> comes from upstream
<ldvsoft> Upstream? Uh... Ok, Thanks!
<logan-> bug filed regarding the 4.4.0-157 -> 4.4.0-159 file access regression I mentioned in here yesterday.. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840328 ... is there any further debugging that would be helpful for this? 
<ubot5> Ubuntu bug 1840328 in linux (Ubuntu) "Regression in overlayfs between 4.4.0-157 and 4.4.0-159" [Undecided,New]
#ubuntu-kernel 2019-08-17
<lotuspsychje> tjaalton: think this commit could be related to the flickering bug? https://bbs.archlinux.org/viewtopic.php?id=244115
<tjaalton> lotuspsychje: so if you blacklist that module, do you get the same issue on 4.18?
<lotuspsychje> tjaalton: 4.18 works without flickering, should i try a blacklist on 5.0.0.25?
<tjaalton> lotuspsychje: my point was does 4.18 regress
<tjaalton> 5.3 has 62b1b3b3b6d3ef3
<tjaalton> 62b1b3b3b6d3ef3 r8169: don't activate ASPM in chip if OS can't control ASPM
<tjaalton> maybe that "fixed" it for you
<lotuspsychje> or on 4.19 it also flickers, i could try a blacklist there?
<tjaalton> that commit was added in 4.20
<lotuspsychje> tjaalton: so that doesnt prove why 5.0 doesnt work?
<tjaalton> maybe not
<lotuspsychje> i could try blacklisting it on 4.19 and 5.0 ill see what happens ok cant harm to try
<tjaalton> and you have that hw?
<lotuspsychje> yes
<tjaalton> as in, is the module loaded now
<tjaalton> ok
<lotuspsychje> whats command again for modules
<tjaalton> lsmod
<lotuspsychje> description: Wireless interface
<lotuspsychje>        product: Wireless-AC 9260
<lotuspsychje> iwlwifi
<tjaalton> there you go
<lotuspsychje> ill test it a bit later, ill ping you after ok
<tjaalton> lsmod|grep r8169
<tjaalton> r8169 is ethernet, not wireless
<lotuspsychje> tjaalton: so this is another bug then?
<lotuspsychje> lotuspsychje@Rootbox:~$ lsmod|grep r8169
<lotuspsychje> r8169                  81920  0
<tjaalton> loaded but not used, lspci -k should show if you have the hw
<tjaalton> though having it loaded usually means that..
<jeremy31> Is the used by result accurate?  I am using USB wifi and I see ath9k_htc              77824  0
<tjaalton> ah, it shows how many modules use it..
#ubuntu-kernel 2019-08-18
<tjaalton> lotuspsychje: i was wrong, the commit was in 4.19 already
<tjaalton> maybe try blacklisting the module and try 5.3rc, it should flicker again
<tjaalton> I don't think the bug in i915 which causes the flicker has been fixed yet
<lotuspsychje> tjaalton: but the module was my eth card, would that still be valid then?
<lotuspsychje> my wifi is that iwlwifi
<lotuspsychje> tjaalton: whats weird, that thread i found was mentioning same intel wifi, but the commit is about r8169
<tjaalton> lotuspsychje: it's loaded, and the commit means that it's no longer blocking the cpu/gpu to enter lower power state
<tjaalton> which then triggers the bug in i915
<tjaalton> it all makes sense
<tjaalton> just blacklist r8169 (or unload it) and test on 5.3rc
<lotuspsychje> allrighty
<lotuspsychje> but 5.3 was not flickering right
<lotuspsychje> only 5.0 flickering
<tjaalton> because it had another commit for r8169
<lotuspsychje> ah
<tjaalton> 62b1b3b3b6d3ef3 r8169: don't activate ASPM in chip if OS can't control ASPM
<tjaalton> which I believe kinda reverts the older commit
<lotuspsychje> ok, blacklist added, lets reboot
<tjaalton> in the sense that it would no longer use lower cstates
<lotuspsychje> tjaalton: you need my dmesg now with the blacklist?
<tjaalton> no
<tjaalton> does it flicker?
<lotuspsychje> 5.3 was not flickering
<tjaalton> even after blacklist?
<lotuspsychje> yep
<tjaalton> okay
<lotuspsychje> oh wait
<lotuspsychje> i forgot to delete cstate 4
<lotuspsychje> my bad
<tjaalton> heh
<tjaalton> also fastboot=0
<lotuspsychje> ok
<tjaalton> or suspend/resume
<lotuspsychje> ok here goes
<lotuspsychje> hmm wifi enables anyway after a while
<lotuspsychje> no flickering
<lotuspsychje> r8169 0000:01:00.1: can't disable ASPM; OS doesn't have ASPM control
<tjaalton> so it's loaded anyway?
<tjaalton> try rmmod r8169
<lotuspsychje> tjaalton: http://dpaste.com/2JBCR5F
<lotuspsychje> rmmod: ERROR: could not remove module r8169: Operation not permitted
<tjaalton> how about sudo -s first..
<lotuspsychje> reboot again?
<tjaalton> what?
<tjaalton> how did you blacklist it?
<tjaalton> 'sudo rmmod r8169'
<lotuspsychje> added to /etc/modprobe.d/blacklist
<tjaalton> does it work?
<lotuspsychje> rmmod: ERROR: Module r8169 is not currently loaded
<tjaalton> cool, does it flicker after suspend/resume
<lotuspsychje> lets try
<lotuspsychje> no, Fn keys brightness also work
<tjaalton> what's that got do to with this? :)
<lotuspsychje> tjaalton: well the Fn keys have influence on the flickering
<lotuspsychje> making it flicker more
<lotuspsychje> so im alwyas testing too
<lotuspsychje> ok whats next :p
<tjaalton> sudo cat /sys/kernel/debug/dri/0/i915_dmc_info
<lotuspsychje> http://dpaste.com/16GYRN8
<tjaalton> sounds like some other device is now blocking lower power state
<tjaalton> if r8169 is not loaded
<tjaalton> fun
<lotuspsychje> yikes
<tjaalton> anyway, we should get 62b1b3b3b6d3ef3 in 5.0
<lotuspsychje> tjaalton: i dont need to test this blacklist on 5.0?
<tjaalton> it wouldn't have any effect
<lotuspsychje> kk
<tjaalton> thing is though, that it's kinda hard to debug the actual bug in i915 because their code is now based on 5.3 where the bug doesn't happen
<tjaalton> isn't triggered I mean
<lotuspsychje> ah
<lotuspsychje> tjaalton: if it can help, these are the kernels we all tested: http://dpaste.com/2T98DVQ
<lotuspsychje> 4.15 4.18 5.2 and 5.3 were not flickering
<tjaalton> 5.2?
<tjaalton> surely did flicker
<lotuspsychje> tested 19.10 without flickering i think
<lotuspsychje> live daily
<lotuspsychje> tjaalton: i can test some of my list if you want
<EoflaOE> hello
<lotuspsychje> hi EoflaOE 
<EoflaOE> hi lotuspsychje
<lotuspsychje> brb
<tjaalton> lotuspsychje: no need to test anything, since I know what's going on
<tjaalton> lotuspsychje: 5.2 has this: b75bb8a5b755d0c r8169: disable ASPM again
<tjaalton> that's why it doesn't flicker
<tjaalton> also, it explains why my builds with smaller config didn't flicker
<lotuspsychje> tjaalton: allright, thank you for all your work, time & effort in this bug
<shibboleth> current 5.0.0 -20 until -28 are all messing with the tor browser bundle
<shibboleth> is this known, has anyone weighed in?
#ubuntu-kernel 2020-08-10
<fling> Is not 5.4.49 compat patch for shiftfs there yet?
<Ezro> Hey folks. Can anyone help with a bug I raised (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891062)? It looks like a patch is available in the linux 5.4.y branch that _should_ resolve the bug, but I'm unsure of what steps should be taken next.
<ubot5> Ubuntu bug 1891062 in linux (Ubuntu) "Lenovo X1 Tablet Gen3 trackpoint and buttons not working" [Undecided,Confirmed]
<tjaalton> Ezro: that commit has been in the distro kernel for a long time already
<Ezro> Hm.. I upgraded my BIOS earlier today and performed a clean install but I'm still not able to use my trackpad buttons. Do you have any guidance on what I could / should do to get the buttons working?
<sarnold> Ezro: if it doesn't work becaues the kernel doesn't support it correctly, you can file bugs with the kernel folks; I'm not sure if they actually look at it, but it'll at least be a place to report results that might be easier to follow than LKML https://bugzilla.kernel.org/
<Ezro> Ah, I see what you're saying. I'll reach out to them. Thanks!
#ubuntu-kernel 2020-08-11
<LocutusOfBorg> ppisati, hello, do you know the kernel patch for vbox is not in linux?
<LocutusOfBorg> https://www.virtualbox.org/attachment/ticket/19644/local_patches
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/v/virtualbox/20200811_062936_f93f3@/log.gz
<LocutusOfBorg> without that patch, it won't migrate...
<ppisati> LocutusOfBorg: let me check
<ppisati> LocutusOfBorg: that's an old revision AFAIK
<ppisati> LocutusOfBorg: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/groovy/log/?h=master-next
<ppisati> LocutusOfBorg: the kernel patch was applied 7 days ago
<ppisati> LocutusOfBorg: the we had was with virtualbox-guest-dkms, and nothing to do with the kernel patch
<LocutusOfBorg> ppisati, the guest-dkms is fixed
<LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/v/virtualbox/groovy/amd64
<LocutusOfBorg> but I did pull-lp-source linux, and that patch wasn't there...
<LocutusOfBorg> ok, so the one in groovy-proposed is not fixed... nice, on the next linux upload virtualbox will be green then
<ppisati> LocutusOfBorg: awesome!
<ppisati> LocutusOfBorg: i thought you were on vacation
<ppisati> LocutusOfBorg: you should go back to ombrellone
<LocutusOfBorg> I'm back since yesterday :D
<ItzSwirlz> o/
#ubuntu-kernel 2020-08-13
<LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/v/virtualbox/groovy/amd64
<LocutusOfBorg> ppisati, ^^ any idea?
<LocutusOfBorg> I don't know what the kvm is...
<sforshee> LocutusOfBorg: linux-kvm is built with a stripped down config really just meant for kvm, you can ignore those failues
<LocutusOfBorg> nice to know
<LocutusOfBorg> ppisati, if you want to open a merge request, there you can see the issue I opened https://github.com/draios/sysdig/issues/1669
