#ubuntu-kernel 2005-11-14
<dilinger> that's... bizarre
<Mithrandir> dilinger: did you want access to ravel?
<dilinger> Mithrandir: yes please
<Mithrandir> dilinger: mail ssh key to tfheen@debian.org + maswan@acc.umu.se, say that you want access to ravel and include preferred user name.  Please sign the mail.
<Mithrandir> if you prod me once you've done it, I'll fix the account right away
<dilinger> mm.  i need to revoke my gpg key, actually
<dilinger> i just recovered what i hope is my complete revocation cert from a dying drive
<dilinger> but i can pretend like the key's not compromised and sign it anyways ;p
<Mithrandir> you could also put it on your ~ on some d.o host and I could grab it off there.
<dilinger> gluck.d.o:~dilinger/debian.pub
<dilinger> 'dilinger' for the username, please
<Mithrandir> ok, done.
<Mithrandir> host is ravel.hpc2n.umu.se
<Mithrandir> it has a bunch of chroots, if you need anything in any of them, prod maswan or me.
<Mithrandir> don't use the base system for anything, it's fairly fucked.
<dilinger> thanks.  is there a recommended way to chroot/build into them?
<dilinger> (i assume you mean the ones in /scratch
<Mithrandir> dchroot
<Mithrandir> yup
<Mithrandir> it's the packaged dchroot, not the debian dchroot, which kinda sucks, but it works.
<dilinger> nice
<zul_> oh btw i added linux speakup to my kernel tree
#ubuntu-kernel 2005-11-15
<anavim> is there somewhere I can jump in to help with the kernel?
<anavim> I've been programming for 13 years professionally, mostly with Mac OS, but in the past year have been porting software to Ubuntu, albeit slowly
<anavim> my experience is mostly with graphics software, games, and interprocess bridging from web browsers, but I would like to make a career switch to linux kernel dev  :D
<olafura> Is there any ETA on linux 2.6.14 hitting dapper
<olafura> Sorry to be asking again but there are new people: Is there any ETA on linux 2.6.14 hitting dapper
<anavim> is there an ubuntu page about kernel dev volunteering?
<anavim> crimsun, ping
<BenC> fabbione: ping
#ubuntu-kernel 2005-11-16
<anavim> geez, what's with the network today?
<BenC> anyone know how to override KERNEL_ARCH in kernel-package rules?
<answerguy> What is the current limit on NGROUPS (number of supplemental GIDs per process) in 2.6.x?
<answerguy> ... and are reasonably recent versions of glibc able to cope with more then 32 GIDs/proc?
* answerguy apologizes to anyone that read this question in any of the other Linux kernel related channels to which it's posted it.
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-rc upload expected any day, will probably only build for x86
<zul> heylo
<zul> BenC: ping
<BenC> zul: pong
<zul> BenC: when are you going to do a pull from me ;)
<zul> after 2.6.15?
<BenC> as soon as I get everything else kosher :)
<zul> ok cool..because i have some interesting stuff in there
#ubuntu-kernel 2005-11-17
<zul> merde
<zul> there partially automated kernel build
<zyga> what is the proper channel to ask kernel howto questions?
<zyga> I need to build a custom kernel with squashfs and unionfs, based on stock ubuntu kernel. I've searched the wiki but since I'm inexperienced with kernel construction I was wondering if anyone can point me to proper documents
#ubuntu-kernel 2005-11-18
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-rc1-ubuntu1 uploaded to dapper
<BenC> zul: ping
<zul> BenC, pong
<BenC> can you email me your git url?
<zul> sure
<zul> whats your email again?
<BenC> bcollins@u.c
<zul> i kind of have an automated kernel build system going..well script at least 
<BenC> are you synced to the latest git?
<zul> im doing a build right now
<BenC> x86 and amd64 are building right now, and ppc will build as soon as kernel-package gets fixed
<zul> cool
<zul> i had problems will building kernel-docs yesterday but that could have been me
<BenC> haven't booted amd64, but the only problem I had with x86 was the rt2500pci driver not working anymore
<BenC> nah, it is fixed now
<zul> goodie
<BenC> ll_rw_blk.c was moved, and DocBook parsed the old location
<zul> that is what i thought
<zul> i did add the speakup stuff and the new kernel drivers to the .config yet either
<zul> scarey 
<zul> http://linuxicc.sourceforge.net/
<BenC> pulling now
<zul> nifty
<zul> i just did a pull with my stuff and doing a build
<zul> i need to fix those copy_to_user warnings they are starting to bug me
<BenC> things like that need to be sent upstream
<zul> yeah ill submit a patch to kj
<BenC> I don't want to clutter out tree (especially since we aren't doing patches) with non-functional fixes
<zul> sure
<BenC> what are the changes for mips/Kconfig coming from?
<BenC> it's a big conflict
<zul> linux-speakup
<BenC> what exactly is that?
<zul> linux for blind users
<BenC> also, please make sure your diffs are clean, there's one file I pulled from you that had a change from if ( to if(
<zul> sorry
<BenC> and nothing else, and there were a few white space changes in one driver, and actually a typo introduced aswell
<zul> damn it
<BenC> ok, I'll finish this merge when I get back
<BenC> thanks dude
<zul> no probs
<zul> thanks for pulling
<joh> Any 2.6.14.2 backport to breezy?
<zul> probably not yet
<zul> breezy only gets security updates really
<zul> and its 2.6.12 
<zul> so no 2.6.14, dapper is oging to be 2.6.15
<joh> Ok, I'll have to roll my own then ... :)
<zul> exactly
<joh> One thing though, the KernelBuildpackageDetailedHowto on the wiki explains some, but not all. How are the ubuntu linux-headers generated? When I used the method from the wiki, the linux-headers package was incomplete and it was impossible to build anything against it. It was missing the headers (i.e. /lib/modules/.../build was pointing to the linux source tree, not any /usr/src/linux-headers-... as it is in the official ubuntu packages. Any hints?
<joh> It seems that howto is a bit outdated :P
<joh> Also, how do I convert a vanilla kernel tree to a debian/ubuntu tree with dpatches etc?
<joh> linux-patch-ubuntu-2.6.12 perhaps...
<joh> or not :p
#ubuntu-kernel 2005-11-19
<codepoet> ok
<codepoet> anybody here first?
<zul> hey
<DevinT> woah
<DevinT> somebody's here
<DevinT> ok
<DevinT> well
<DevinT> i know you and 3 other people are on the kernel team from launchpad, correct?
<zul> yeah
<DevinT> well, are you familiar with the acx100 driver?
<zul> not really..
<zul> whats the problem
<DevinT> well
<DevinT> i was wondering how i could become some sort of psuedo module maintainer for that
<DevinT> i'm interested in helping out with the ubuntu kernel, and i was thinking that would be a great place to start, especially as it needs a lot of work
<zul> DevinT: you might want to talk to BenC 
<DevinT> ok
* BenC lifts his head
<zul> but all you really do is pull the git tree, make patches and push
<BenC> yeah, read the wiki in the channel topic
<DevinT> alright
<makx> BenC: davej had some comments about enabled lapic.
<makx> maybe you imported that setting from Debian as we have this also set.
<makx> any comment on the matter.
<makx> ?
<makx> (i was quite happy for his acpi cut off pointer, did turn that off too in current tree, all the old boxes i've seen work with acpi=force)
<DevinT> how lame haha
<mjg59> makx: Enabled lapic ought to work fine now
<DevinT> why 0.99.9abcdefg, just go to 1.0 already
<DevinT> silly Linus
<makx> mjg99: vanilla?
<mjg59> makx: As far as I know, yes
<mjg59> What's the issue?
<makx> well i need to find time and see if some boot failures are corelated too UP_APIC
<makx> mjg59: did you read latest davej blog?
<makx> (not that i want to throw any flames, more interested in facts :)
<mjg59> makx: Enabling local apic in the kernel used to enable it on boot regardless of what the BIOS did
<mjg59> That changed in 2.6.10 or so - now the kernel only enables it if the BIOS has already enabled it
<mjg59> That seemed to fix all the problems we saw
<mjg59> Let me see if I can track down when that changed
<makx> hmm definitely before git time. :)
<BenC> makx: Haven't looked into it
<zul> BenC: its just a rant
<makx> zul: naah it had also nice info for me.:)
<BenC> I need to setup a test partition on my g5
<mjg59> makx: We've had no reported problems with enabling UP APIC
<zul> makx: heh...im going to start a blog to respond
<makx> zul: ok cool, but be nice ;)
* fabbione eyes 2.6.15 changelog
<fabbione>   YES! I know there are no i386 SMP packages. The 686 and k7 packages are
<fabbione>      SMP enabled. In fact, they are also UP enabled "WHAT!?!? HUH!?!". Yes, SMP
<fabbione>      on i386 now has the added benefit of killing lock ops dynamically on boot.
<fabbione>      This is still in testing phase. I also need to fix a few things to get it
<fabbione>      working for modules.
<mjg59> EAT YOUR CRACK
<fabbione> mjg59: i assume that's too much even for you
<mjg59> Haha
<mjg59> Linus has actually been talking about it - he seems to think it's kind of cool
<fabbione> that patch is old as helll
<fabbione> i think Ben did port it from 2.4 or something
<fabbione> so i assume Linus is looking into our tree
<dilinger> fabbione: hope there's a provides for the smp flavours :)
<dilinger> or dummy packages or something
<fabbione> dilinger: there is no need to do that in the kernel package
<fabbione> we can handle that in linux-meta
<dilinger> no?linux-image-686-smp
<dilinger> that's what i've got installed; that will need to be sure to pick up -686 instead
<fabbione> yeah
<fabbione> linux-image-686-smp comes from linux-meta
<fabbione> not from linux-source
<dilinger> ok
<fabbione> that one will pick up the right kernel
<BenC> Linux colorless 2.6.15-2-powerpc #4 Mon Nov 14 10:58:05 EST 2005 ppc GNU/Linux
<BenC> g4 booted flawlessly with new kernel
<fabbione> BenC: cool
<fabbione> so it did actually build
<fabbione> or is it with a local version of kernel-package
<fabbione> ?
<fabbione> because i need a d-i with .15 to be able to install my powerbook
<BenC> local mods to k-p
<fabbione> or backport some git stuff to .12
<fabbione> ok
<BenC> we have to use ARCH=powerpc for ppc32
<BenC> 15-1 wont work, I had to make a few fixes to .config for ppc32
<fabbione> BenC: ok
<fabbione> i need to ask benh if the ID changes have made linus tree
<BenC> it's all in git if you want to do a build though
<BenC> and I can dpkg-repack my kernel-package
<BenC> is your powerbook G5?
<fabbione> the problem is that to build d-i you need stuff in the archive, otherwise it's a bunch of hacks
<fabbione> nope.. g4
<fabbione> there are no powerbook g5 yet
<fabbione> i am off for dinner
<fabbione> bbl
<BenC> later
<dilinger> hm
<dilinger> http://www.livejournal.com/users/kernelslacker/30664.html
<zul_> dilinger: yeah saw it this morning
<BenC> people getting mad at us is probably a good thing in that sense :)
<BenC> we do have about half a dozen patches that need to be pushed upstream though
<dilinger> yea
<BenC> good thing is that a whole lot of patches got rm'd with 2.6.15
<dilinger> now that i'm not doing debian kernel stuff anymore, i'm thinking i should start going through vendor kernels and pushing stuff upstream (maybe starting another kernel tree w/ those fixes)
<BenC> mostly acpi of course
<BenC> they are easy to find in our git tree
<dilinger> yep
<BenC> search git-log for "UpstreamStatus: Unsubmitted"
<fabbione> clearly who did that review isn't aware that 90% of the patches we pull are from other upstreams
<fabbione> specially the ACPI ones
<fabbione> BenC: btw.. speaking of patches.. the megaraid split is my work
<fabbione> something i did almost for fun
<BenC> ah, so you lay claim to that code? :)
<fabbione> code... well.. it's a patch...
<fabbione> it does nothing fancy :)
<BenC> is it needed?
<fabbione> well yes
<fabbione> some controllers are supported only by the old driver
<fabbione> and viceversa
<fabbione> so the patch does split per PCI ID's
<fabbione> to support the largest amount of cards
<fabbione> with no overlap between the two
<fabbione> so they should be even able to load in parallel
<BenC> to make it correct, I should probably make it so that it enables/disables the extra PCI id's depending on whether the new module is compiled
<fabbione> hmmm that's an option
<BenC> this new kernel doesn't seem as troublesome as I was expecting, but I don't have the varied hardware like our users do
<BenC> atleast I can say "works for me" though :)
<fabbione> BenC: i will be able to start testing on 8 boxes tomorrow
<fabbione> modulo my fever going away
<BenC> you should get some rest dude
<fabbione> i have been in bed all day
<fabbione> just too restless to stay there longer
<fabbione> i needed a break :)
<BenC> yeah, I can't just lay around all day either
<BenC> need to restart X
<zul_> hey...we both worked on that patch fabbione 
<fabbione> zul_: we did???
<fabbione> probably
<zul_> yeah..
<zul_> the megaraid one if you are talking about
<fabbione> yeah that one
<zul_> i started it, you finished it :)
<fabbione> right
<fabbione> BenC: ^^^now you can blame zul for that patch :)
<zul_> damn it
<zul_> is this because of davej's blog?
<fabbione> no.. you want to share credits and it's of course fine by me.. you also share the blames :P
<zul_> nah i dont want blame i just want a share of the credit..you can have all of the blame ;)
<fabbione> ehhe
<fabbione> anyway i am out of here
<fabbione> time to get more rest
<zul_> toodles
#ubuntu-kernel 2005-11-20
<zul> merde
<zul> the new system of a down is gooooood..
<zul> hmm...
<zul> Linux bart 2.6.15-1-686 #1 SMP Sun Nov 13 11:44:52 EST 2005 i686 GNU/Linux
<zul> couple of hardware regressions on my laptop though
<zul> ipw2200 couldnt load the firmware and usplash didnt work
<BenC> usplash worked for me on my laptop and G4
<BenC> is that the buildd build?
<zul> my own build
<BenC> from my git?
<zul> my git
<BenC> but I mean does it have all the stuff from my git tree?
<zul> no wait...hmm...just a sec..
<zul> yeah
<zul> yours and mine
<BenC> any messages in kern.log about unresolved symbols in any modules?
<fabbione> hmm how do you cherry pick with git?
<fabbione> mjg59: ping?
<mjg59> fabbione: Hi?
<fabbione> hey
<fabbione> mjg59: i was looking at one commit Ben did on .12
<fabbione> after breezy release
<fabbione>   * external-arch-i386-kernel-reboot_reboot-thru-bios: Remove
<fabbione> i assume this was coming from you
<mjg59> Yeah
<mjg59> We added a DMI patch to only do it on the machines that needed it
<fabbione> is it a whishlist for dapper or something absolutely important for breezy?
<mjg59> Some machines in Breezy don't reboot
<mjg59> Dropping that patch would probably fix them
<fabbione> ok so it is not even sure it will fix the problem, right?
<mjg59> I don't have any of the hardware concerned
<fabbione> ok
<fabbione> than i will kill the change
<fabbione> if it was sure and important i would have snicked in for -security
<fabbione> but given the status i will keep it as it is from breezy
<fabbione> there might be a -update for breezy anyway
<Mithrandir> mjg59: iirc, Karianne's laptop (HP something) doesn't reboot cleanly, so I guess I can have her test it.
<mjg59> Mithrandir: No, that one works now
<Mithrandir> mjg59: oh, ok
<zul> BenC: sorry my wife was in a pissy mood last night and decided to take it out on me
<BenC> that's what wives are for
<zul> yeah so uspalsh doesnt work for me on my laptop
<BenC> any messages about vga16fb loading?
<zul> didnt see..
<zul> ill have to check tonight when my laptop is powered back up
<BenC> ok
<jbailey> Is the git in dapper useful for upstream kernel trees now?
<zul> well it was announced on lkml
<jbailey> Which it, sorry?
<jbailey> I don't follow lkml all the time.
<BenC> jbailey: 0.99.x is suggested
<BenC> 0.99.8 is what I have
<BenC> 0.99.9 something or other is latest
<BenC> I don't use cogito though, so I can't answer any questions about that :)
<jbailey> Oh?  What do you use/
<BenC> just the git-* commands
<jbailey> But not packaged?
<BenC> fabbione: ping
<BenC> jbailey: not sure, but I don't think so
<jbailey> 'k
* jbailey wonders if its worth packaging.
<BenC> fabbione said he was going to do it
<BenC> cogito contains the git commands, so maybe he was just going to update that
<jbailey> fabbione: Didja, didja, didja?  huh huh huh?
<jbailey> =)
<jbailey> BenC: The linux-libc-header guys have been using a separate svn for their 'user abi' headers.  I'm going to try and push them into using git and also keep that tree available.
<jbailey> Easier to merge the pieces that probably actually ought to be, and easier to track new changes.
<BenC> yeah, would make things a lot easier
<zul> jbailey: im trying to package it
<jbailey> zul: Cool.  Do you need help?
<jbailey> ROAR
<jbailey> "GIT 0.99.9i aka 1.0rc2 is found at usual places."
<jbailey> Is a stupid line to have at the top of an announcement mail.
<fabbione> BenC: pong
<BenC> fabbione: re the reboot patch, it was tested by users
<fabbione> BenC: ok.. it will wait -updates if we will ever do one
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-rc1-ubuntu2 uploaded (should build for x86, amd64, and ppc)
<zul> jbailey: not really its my first real debian package so its best that i learn how to do it and get you to look over it 
<BenC> zul: did you use debmake? :)
<zul> nope
<fabbione> BenC: did you actually uploaded k-p too?
* BenC remembers those days
<BenC> fabbione: yeah, and build-dep's on it
<fabbione> coooool
<fabbione> if i can get somebody to build a breezy ppc d-i for me
<fabbione> i might even get my powerbook to install
<BenC> I'm trying to convince my wife to let me dual-boot ubuntu on her g5 so I can some extra testing there
<zul> BenC: i bought a new hard drive for my wife on condition that she dual boots
<fabbione> BenC: you have a ppc or two, rigth?
<BenC> I need to get an amd64 machine so I can test boot that...I hate just saying "it built"
<jbailey> zul: Fair 'nuff.
<jbailey> zul: Are you updating cogito or just doing git?
<BenC> fabbione: two G4's (one my desktop) and a G5
<fabbione> ah
<fabbione> BenC: you just offered volunteer to do a d-i build for me
<fabbione> because i can't believe in 36 hours into my ppc experience and i still can't install linux :)
<BenC> you can't install breezy?
<fabbione> BenC: are you running breezy?
<fabbione> BenC: no
<fabbione> apple did change PCI IDs on the latest powerbooks
<BenC> yeah, breezy with dapper kernel (oooh, aaah, bad)
<fabbione> so now on davis
<fabbione> i have a .12 with the patch 
<doko> BenC: can silo be built with something newer than gcc-2.95?
<fabbione> the kernel and udebs are already built
<fabbione> doko: silo is already building with gcc-4.0
<fabbione> BenC: i need to build d-oi
<BenC> doko: not last I checked
<fabbione> d-i
<fabbione> but davis has no B-D
<fabbione> and nobody around that can install them
<BenC> not sure I can do that in a reasonable time frame
<fabbione> BenC: so would it be possible for you to build it for me?
<doko> fabbione, BenC: *lol*
<BenC> oh, it only breaks on sparc32 with newer gcc, so ubuntu can do that :)
<fabbione> re: silo has been fixed to build with gcc-4.0 by David
<BenC> fabbione: oh, right, I need to merge that patch into silo
<fabbione> BenC: the d-i build takes like 15 minutes.. please
* BenC has been a bad upstream for silo for like 4 months now
<fabbione> i really really want to try to install this machine
<doko> ok, thanks, one compiler less ...
<BenC> fabbionne: it's not the build, it's all the stuff I have to download :)
<fabbione> BenC: it's 3 udebs
<BenC> really?
<fabbione> yes
<BenC> email me the specifics of what I need
<fabbione> ok
<BenC> I'm used to the old installer build I guess, where it needed a mostly complete base mirror
<fabbione> nah
<fabbione> it downloads some stuff from the net
<fabbione> but not much
<fabbione> BenC: you got mail
<fabbione> dude if you can get that done asap, i am going to put one portrait of you in my personal "Heros of my life" section in the temple
<zul> jbailey: just git
<jbailey> zul: git itself appears to have debian packaging already in it.
<BenC> fabbione: ok, as long as it's atleast an 8x10 portrait
<fabbione> BenC: ehhehe
<BenC> sweet, kernel-package is built, so 2.6.15-2.2 should follow soon
<BenC> fabbione: at the very least, if I can get my e3k up this weekend, I can atleast do some builds for 2.6.15 kernels
<BenC> the builds go pretty fast when you can through 6 cpu's and 6gigs of ram at it
<BenC> s/through/throw/
<fabbione> eheh i know
<fabbione> i have been building security kernels on a 2 x dual core amd64 with 8GB of ram today
<fabbione> pretty fast
<zul> jbailey: yeah i know fabbione said it sucked
<zul> fabbione: pretty fast?!?!
<zul> thats a bit of an understatement
<fabbione> as everything else that has a debian/ dir upstream
<fabbione> zul: it did start swapping approx 512MB with make -j750
<fabbione> = the sucks
<fabbione> with -j500 was okish
<zul> heh...can i give you my ssh key ;)
<fabbione> give it to Mithrandir 
<fabbione> it's his playtoy
<zul> hmmm..
<zul> im off to lunch
<jbailey> Lunch sounds like a lovely idea.
<zul> with meat ;)
<fabbione> thai vegetarian ++
<fabbione> jbailey: that resturant was really nice..
<fabbione> i wouldn't mind to go there again
<fabbione> BenC: you can stop build d-i (if you started)
<BenC> you have it?
<fabbione> yes
<BenC> ok
<fabbione> i got Znarl to install b-d on davis
<BenC> ok, cool
<jbailey> BenC: Got a moment for a stream of git questions?
<BenC> sure
<jbailey> I'm looking at putting lkh into git.  What I've noticed others have done is have a working branch and then a branch marked "for-linus" or some such for merging back in.
<jbailey> Are those truly just branches in the same .git file?
<jbailey> Or do they turn into multiple repositories that get merged back and forth?
<BenC> same .git/
<BenC> you can merge from head to a branch, and branch to head
<BenC> all in the same repo
<jbailey> Okay, cool.
<BenC> so you can cherry-pick commits from head, into the branch, and do a pull request to linus, or whatever
<jbailey> Okay.
<jbailey> When doing commits, is it hard to go back afterwards and break things into better changesets?
<jbailey> At this point I need to just get it done, but I'd like to go back afterwards and start to split things up into changes that I think would be accepts back upstream, and changes that haven't a hope of going in.
<BenC> well, let's say you do a large commit, then later you want break it down into smaller ones...
<jbailey> Right.
<BenC> first you'd rebase the commit to the head (make the chageset against the latest code, instead of your older branch point)
<BenC> then you could pull the diff, and revert the changeset
<BenC> and re-apply into changesets as needed
<BenC> it's not very straight forward, but it is possible
<jbailey> Okay, so it does understand the concept of "take this changeset out".  Cool.
<BenC> but if you have commits that depend on the large one, it gets ugly fast
<BenC> yeah
<jbailey> Since it's just futzing with include files, it shouldn't be too bad for now.
<BenC> the commit still shows in the log, but the revert does too
<jbailey> I'm sure they're probably used to that from folks new with the tool. =)
<BenC> yeah, I have a few reverted commits in the ubuntu tree :)
<jbailey> Argh, I think I'm still confused.
<jbailey> So for my code that is never intended for Linux, I can just commit this to my checkout, yes?
<jbailey> s/Linux/Linus
<jbailey> Then when it comes time to hand changesets back, do I make a new branch then?
<BenC> yes
<BenC> you can make a branch at any time
<BenC> best to pull things into the branch just after you check them into the head
<zul> dont do what i did
* jbailey wonders what zul did...
<jbailey> Actually.
<jbailey> Does that include getting up this morning?
<jbailey> I could've avoided that easily enough.
<BenC> I tried to avoid it, but the rest of the house wasn't having it
<dilinger> i managed to put it off for a few hours
<dilinger> hm
<dilinger> looks like we're skipping breezy on our desktop systems at work :/
<BenC> going straight to dapper? :)
<dilinger> probably
<dilinger> the problem is, we're running sarge on our servers, and dealing w/ the differences between gcc-3.3 and gcc-4.0 is a pain
<dilinger> w/ our in house software
<dilinger> oh well
<zul> jbailey: i didnt branch and that probably fucked things up
<zul> actually i dont remember what i did
<jbailey> dilinger: Is that going straight to dapper in 6 months, or is that, "Whee, let's ride the rollercoaster" on the way there?
<dilinger> jbailey: ooh, rollercoaster?
<jbailey> dilinger: Minor C++ abi transition, kernel update.  glibc update, you know.  The little things.
<dilinger> oh
<dilinger> going straight to dapper in 6mo
<dilinger> sticking w/ the same gcc/libc6 for now
<dilinger> my boss was actually talking about "breezy for sarge"
<dilinger> recompiling most of breezy against the older gcc/libc6
<jbailey> Might not work in the case of the C++ bits.
<jbailey> Sounds like what you might want is a breezy server with a sarge chroot for now.
<dilinger> yea
<dilinger> i recommended the chroot
<dilinger> but it's just easier to stick w/ hoary for now
<dilinger> than to change how people work
<jbailey> It's all good.
<jbailey> The whole point of the long support cycle is to let you choose when to upgrade.
<jbailey> You're only in trouble if you're still running warty and can't upgrade soonish.
<jbailey> Do oldworld macs use PCI?  I thoguht they did.
<jbailey> The only thing I think that the "SCSI drivers built into kernel" guy on u-d should need is to set his /etc/mkinitramfs/initramfs.conf to MODULES=dep
<jbailey> infinity: ^^
<jbailey> infinity: I'll let you take that so that I actually can start pretending like initramfs-tools isn't mine anymore. =)
<dilinger> jbailey: the main problem is all the backporting i'm going to have to keep doing
<jbailey> dilinger: Hmm.  The automatic backports and stuff aren't enabled for Hoary?
<dilinger> there's automatic backports?
<dilinger> i remember mako talking about the idea at UDU, but..
<jbailey> I thought that it got done.  I might be mistaken, though.
<jbailey> I know that there's supposed to be something crazy with backports going on/.
<fabbione> dilinger: remembet also that we don't support hoary -> dapper upgrades. You might have to jump via breezy anyway
<zul> later
<dilinger> fabbione: given how badly the 2 hoary->breezy upgrades went for me, i'm not that concerned :)
<fabbione> badly? ;)
<dilinger> yea
<fabbione> badly how?
<dilinger> #19477, #19478
<dilinger> that was for my upgrade
<dilinger> a coworker did an upgrade that failed in various other places, but i couldn't file bugs because he needed his machine
<fabbione> -ENOBUGZILLA atm
<dilinger> misc packages that were missing conflicts/replaces
<fabbione> from within main?
<fabbione> or from universe?
<dilinger> main, i believe
<dilinger> i'd have fixed them myself if i had some sort of upload privileges; they seem like easy fixes
<dilinger> instead i just fixed them in a local repository
<BenC> mjg59: ping
<BenC> mjg59: just filed a bug report on usplash, it needs to load softcursor.ko first to work with 2.6.15, and the module path changed
<dilinger> ok
<infinity> BenC : It does?... I just upgraded to 2.6.15 here, and usplash worked.
<infinity> BenC : Or is this PPC specific, perchance?
<BenC> no, this was i386
<BenC> it may "work", but it's broken early on
<infinity> BenC : Also, if you're not yet aweare, the ipw2200 driver is looking for firmware named 'ipw-2.4-*', but we're shipping 'ipw-2.3-*'... A quick rename and my wireless worked again.
<BenC> the first load attempt in the usplash initramfs script doesn't work because fbcon.ko needs softcursor.ko
<infinity> \o/
<BenC> infinity: yeah, that's next on my list
<infinity> I'll look into the usplash issue.
<infinity> Was this with vga16fb?
<infinity> Maybe I dodged the bullet with vesafb.
<BenC> doesn't matter if it's vga16fb or vesa
<infinity> Oh, also, damn you.  You didn't switch to the New World Order of update-initramfs in your postinst.
<BenC> I tried both
<infinity> But we can fix that on your next ABI bump.
<BenC> heh, yeah, I forgot :)
<BenC> almost every upload between now and near 2.6.15 release will be an ABI bump
<infinity> I assumed as much.
<BenC> but other than ipw2200 it worked ok for you?
<infinity> We'll have a ridiculously high ABI magic number in the package names.
<infinity> Oh well.
<infinity> Yeah, it's working okay right now.
<infinity> Too early to say it's working "well", but it hasn't crashed yet.
<BenC> it atleast booted, so that's promising
<infinity> <nod>
<infinity> I guess today will have to be LRM day for me.
<BenC> inifinty: oh, and damn you, I've been watching family guy every night since I got back, trying ot watch them all :)
<infinity> Especially if you want to update the linux-meta package.
<BenC> productivity killer
<infinity> Family Guy is good for the soul.
<BenC> yeah, that would be nice
<BenC> I have a machine that needs nvidia
<infinity> Legacy or newskool?
<infinity> I can always go for some testing.
<BenC> fairly new
<infinity> Zofia's machine is a 6800GT, so it can use both drivers.  But I'd love a "legacy-only" machine to get some testing.
<BenC> 0000:02:04.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000 AGP 8x]  (rev c1)
<BenC> not sure what's considered legacy, but that may be it
<BenC> it's a mame machine, so I can give it some good testing :)
<infinity> Not quite legacy yet, no.
<Mithrandir> nope, I think you need to have GF2MX or older.
<infinity> Might be in another year.
<infinity> But your machine can run both drivers, so you can do some testing of that setup for me.
* infinity ponders.
<infinity> I wonder if I'm going to have to wait for jbailey's glibc/lkh upload, followed by the new X building correctly, before I can update the ATI shit to something shiny and new.
<infinity> Oh well, I can do nvidia at any rate, and build for the new kernel.
<BenC> definitely, I'll test whatever I can
<infinity> Hrm, core hours start in 15 minutes.  Guess I should find some breakfats before I start working for real.
<infinity> Or, some breakfast.
<dilinger> nice fatty bacon? :P
<infinity> Or some fat breaks.
<dilinger> are those like beats?
<infinity> Well, like breakbeats, sure.
#ubuntu-kernel 2006-11-13
<admin321> I used the 2.6.17 config for building my own kernel image(2.6.18) however my dvdrom is not getting detected anymore on bootup of the 2.6.18 is there a module that needs to be loaded?
<admin321> and what is the diffrence between profile and oprofile?
<zul> hey
<zul> hey
<gebruiker> would profile benefit performance / startup time?
#ubuntu-kernel 2006-11-14
<zul> hey
<zul> do do do
<zul> hey BenC 
<BenC> kylem: YO DUDE!!
<kylem> heh
<zul> how is SF going?
<BenC> don'tyou mean "eh?"
<infinity> SF smells nice.
<kylem> so do burgers
<BenC> zul: things for pretty weird last night
<zul> oh?
<BenC> s/for/got/
<BenC> see, it messed up my vocabulary
<zul> how so
<BenC> you don't want to know
<zul> throwing up again?
<BenC> we might even not be allowed to talk about it :)
<zul> oi kyle responding to launchpad bugs now? heh
#ubuntu-kernel 2006-11-15
<lamont> BenC: lamont: I'm thinking it might be a good idea to add the ps/2 drivers to the ia64 edgy install
<zul> hey
<tonfa> hi
<tonfa> by chance does anybody knows what command are used by the gnome-applet when hibernating/suspending ?
<zul> bunch of tards
<Mithrandir> BenC__: nfs-utils ftbfs due to UTS_RELEASE not being defined (http://librarian.launchpad.net/5071382/buildlog_ubuntu-feisty-i386.nfs-utils_1%3A1.0.10-4_FAILEDTOBUILD.txt.gz ) Any idea about that?
<BenC__> Mithrandir: it's a bug in nfs-utils
<BenC__> Mithrandir: it needs to #include <linux/utsrelease.h>
<zul> kernel-headers have changed havent they as well
<Mithrandir> BenC: ls: /usr/include/linux/utsrelease.h: No such file or directory
<Mithrandir> (on feisty)
<BenC> Mithrandir: my question is, why does it use UTS_RELEASE from userspace? That's incorrect
<BenC> Mithrandir: if it's a userspace program, it should really be using uname() and utsname.release
<zul> BenC: i ran into this when i was trying to port xen to 2.6.19 
<zul> i dont remember the fix right now
<BenC> if it's actually a kernel bit (like for zul) then it needs to use utsrelease() in the kernel
<BenC> or something like that
<Mithrandir>  * Get version number of the kernel this was compiled for.
<Mithrandir>  * This is NOT the same as calling uname(), because we may be
<Mithrandir>  * running on a different kernel.
<Mithrandir> I'm not sure what it needs it _for_, but that's why it's not using uname.
<BenC> Mithrandir: the "kernel it was compiled for" is pretty bogus thing to assume from userspace
<kylem> possibly structure versioning or something equally incorrect.
<Mithrandir> BenC: this is the nfs userland bits; they reasonably need to stay very much in sync with the kernel.
<zul> heh if gitweb was working for me i could point out where it changed
<BenC> Mithrandir: then they very much need to use linux-headers instead of the libc-kernel-dev
<BenC> libc-kernel-dev is by nature just what userspace needs...something tightly bound to kernel needs to use kernel headers
<kylem> zul, use www2
<kylem> oh, they're both broken. use hera.kernel.org/git/
<zul> kylem: that works thanks
<zul> doh i had it somewhere..
<zul> ok maybe it was something else, but this what i ran into http://hera.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=96b644bdec977b97a45133e5b4466ba47a7a5e65;hp=e9ff3990f08e9a0c2839cc22808b01732ea5b3e4
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel | 2.6.19-6.7 uploaded - The Pumped/GroupHug/HighFive Release. Use it, but there are still a few missing modules.
<ajmitch> great release name, sounds like an interesting week in SF :)
<zul> or BenC is on crack
<fabbione> BenC: CJA still has problems with her wireless... what should I poke?
<BenC> fabbione: modprobe -r bcm43xx; modprobe bcm43xx
<fabbione> oh ok
<BenC> repeat until "iwlist eth1 scan" shows ap's
<fabbione> feh ok
<BenC> yeah, it sucks
<kylem> yeah, broadcom has issues with bringingg the if up and down.
<BenC> hold on, be right there
<fabbione> git pull
<fabbione> fatal: unexpected EOF
<fabbione> Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<fabbione> kylem: please fix...
<kylem> the kernel.org mirroring is fucked right now
<fabbione> ok
#ubuntu-kernel 2006-11-16
<fabbione> kylem: do you have any experience with bmc43xx driver?
<fabbione> it keeps dieing on CJA LAPTOP
<fabbione> ops
<fabbione> laptop
<kylem> i'm a user... it has... issues.
<fabbione> perhaps we can add some debugging info
<kylem> what's the problem?
<fabbione> after a little while it just dies
<fabbione> rmmod && modprobe seems to be the only way
<kylem> is it an "Air Force One" BCM4318?
* kylem prods fabbione 
<johanbr> It dies for me too on the new feisty kernel, taking the keyboard with it. The bcm43xx in 2.6.17 was (mostly) ok.
<fabbione> kylem: yup..
<kylem> bcm4318 is pretty borken in general.
<fabbione> kylem: well please fix
<fabbione> :)
<kylem> ok, send broadcom docs plz.
<kylem> ;o)
<zul_> hey
<fabbione> kylem: tsk.. a real hacker doesn't need docs
<mjg59> fabbione: Congratulations on volunteering!
<fabbione> mjg59: and congratulation for taking over from me :)
<BenC> I'll donate the first $100k to get a broadcom docsafe account
<zul_> son of a bitch
<kylem> hmm.
<kylem> i can maybe spend some time this week working on 4318.
<zul> kylem: 2-1 for buffalo
<kylem> ?
<zul> ottawa loosing yet again
<kylem> ah.
<johanbr> kylem: There's been several reports on the bcm43xx mailing list about the driver version in 2.6.19-rc5 not being very good (current Feisty is rc5-based, right?). One guy reported backing out a bunch of patches and things improved quite a bit.
<kylem> yeah, i'm reading the list archives atm.
<user_> is there a patch fot the edgy via chipset kernel panic?
<user_> found it on bts
<ternkoe> ubuntu tries hard to emulate windows bloatwares??
<mjg59> Oddly, no
<ternkoe> i mean with the GUI
<ternkoe> it is quite heavy on old machines..
<mjg59> Then why are you in -kernel?
<ternkoe> just wondering
<ternkoe> since im working on thje ubuntu kernel now
<ternkoe> :D
<ternkoe> whats weird is XP runs faster compared to gnome
<ternkoe> am running PIII 450 256MB
<ternkoe>  anyway
<fdoving> which io scheduler is recommended for laptops?
<liri> whats this about? kernel: [17181640.020000]  psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4
#ubuntu-kernel 2006-11-17
<qhartman> I am having a problem with hard locks under sustained network / CPU load (rsync) with Edgy that produce no logging output that I can see. What's the best place to help / get help diagnosing this?
<qhartman> Found the info I need from the link in the topic, thanks.
#ubuntu-kernel 2006-11-18
<lfittl> is it intentional that /usr/src/linux-headers-2.6.19-*/include/linux/config.h does not exist anymore?
<Slyth100> I keep getting this error message when I try to compile kernel-source 2.4.27 for kernel 2.6.15-23-386. Have I got the right kernel source? I presume so because it came with the cd. Here is the error message: gcc-3.3 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c
<Slyth100> make: gcc-3.3: Command not found
<Slyth100> make: *** [scripts/mkdep]  Error 127
<minghua> hi, after an update in feisty, my computer can't boot anymore
<minghua> the dev-mapper seems to be looking for physical volume before ide kernel modules are loaded
<minghua> so of course it can't find any hard drives and decide there is no LVM VG to activate
<minghua> and then I don't have a root file system
<minghua> what package should I file bug against?
<tormod> I filed a bug on 2.6.19, but it seems nobody get notified, and it is not fed to the kernel-bugs ML.
<matjan> hi i follwed this guide to detect cpu temperature, but when i do 'sudo modprobe i2c-sensor' it says: FATAL: Module i2c_sensor not found. what could be the problem?
<pmjdebruijn> matjan, I don't think that module exists... at all...
<tormod> Anyone knows how to force DMA (on ATA drives) in 2.6.19 ?
<matjan> hi, i followed a guide for being able to monitor the cpu temperature: http://ubuntuguide.org/wiki/Dapper#How_to_detect_CPU_temperature.2C_fan_speeds_and_voltages_.28lm-sensors.29
<matjan> when i did 'sudo modprobe i2c-sensor' it gave an fatal error saying that it could not find module i2c_sensor
<matjan> is there a way i can solve this?
#ubuntu-kernel 2006-11-19
<dade`> Is there any plan to include mactel patches in the ubuntu devel kernel ?
<probins> help!  I cant get snd_usb_audio to work (Dapper)
<ph8> if anyone here's running a 64-bit system would you mind checking if you've got /lib32/libfl.a?
<ph8> i can't seem to find 32-bit flex libraries
#ubuntu-kernel 2007-11-14
<lamont> what does it mean when the driver says that the ata driver doesn't support LBA48? (gutsy)
 * lamont wonders if the bug ever got filed that says removing lum at the same time that lrm and the kernel get removed can result in lum failing in postinst... (update-initramfs needs to be conditionally called, not unconditionally)
#ubuntu-kernel 2007-11-15
<lamont> BenC: awake?
 * lamont has issues with sata on his new computer...
<Keybuk> how do I build an i386 kernel on an amd64?
<mjg59> make ARCH=i386 ?
<Keybuk> that simple, eh?
<Keybuk> to debian/rules ?
<mjg59> Not sure if it automatically passes -m32 - you might need to set CFLAGS as well
<Keybuk> AUTOBUILD=1 NOEXTRAS=1 ARCH=i386 fakeroot debian/rules binary-generic
<Keybuk> ?
<mjg59> Worth a go. I've never tried it with the build system.
<Keybuk> make bzImage gave me something with a different ABI string
<mjg59> What does file say about it?
<Keybuk> dunno, deleted it days ago
<mjg59> Ah
<Keybuk> Tim told me to use debian/rules
<mjg59> make EXTRAVERSION=-14-generic, or whatever
<Keybuk> arch=i386 seems to work
<mjg59> Sweet
<Keybuk> it's building arch/i386 anyway
 * Keybuk waits for 40 minutes
<mjg59> Ah, yes, arch/i386/Makefile:CC              := $(CC) -m32
<\sh> moins
<\sh> Keybuk, ping mom...why is mom only running against the unomdified archive, but not against -security or -updates? 
<kraut> moin
<cathyal> thats your mom?
<cathyal> i mean your mom runs linux?
<pwnguin> ...
<pwnguin> mom is merge-o-matic
<\sh> hmmm? my mom? 
<\sh> I don't know what my mom is doing, I didn't see her for 20 years...but I know what Keybuks MoM does ;)
<cathyal> lol
<bullgard4> After upgrading from Feisty to Gutsy I have no LAN access any more. How can I resolve the IRQ 11 resource conflict thus formed? (https://bugs.launchpad.net/update-manager/+bug/158397/)
<ubotu> Launchpad bug 158397 in update-manager "[Ubuntu 7.10] dmesg: "serial8250: too much work for irq11"" [Undecided,New] 
<Keybuk> \sh: because it does
<Keybuk> we don't normally fill -security or -updates for a development release ;)
<Keybuk> likewise, there's no unstable security in Debian
<zul> okies have the xen infrastructure kind of inplace for 2.6.24
<amitk> zul: cool zul :)
<zul> amitk: upstream kernel devs are evil or basatrds :)
<amitk> hehe... you are referring to the x86 merge?
<zul> yep
<amitk> but it was all handled quite nicely for everything that is already in the kernel. I am running 2.6.24-rc2 right now
<zul> cool..hopefully ill get there soon
<abogani> zul: Great work chuck! 
<alex_joni> 'lo all.. is the kernel version for 8.04 already decided?
<zul> 2.6.24
<alex_joni> zul: thanks.. any pointers on when there will be a first cd?
<zul> check the release schedule on the wiki
<alex_joni> ok, thanks
<alex_joni> hmm.. 2.6.24 isn't released yet afaik, isn't it a bit too 'new' ?
<alex_joni> or do you guys think it's best to take the last possible version beeing a LTS?
<rtg> alex_joni: the first of the Hardy kernels is coming 'real soon now'
<alex_joni> rtg: ok, thanks.. I plan of doing a RTAI patched version of it (did the same with dapper.. still works great)
<rtg> alex_joni: I'm grinding through the test builds right now for the x86 variants. I hope to push them all later today.
<alex_joni> rtg: is this based on rc2 form kernel.org?
<alex_joni> RTAI's latest patch is for 2.6.22, I wanna see how far off it is
<rtg> alex_joni: rc2 and them some. I pull from linux-2.6 just about every morning.
<alex_joni> rtg: ok cool, I'll try against rc2
<amitk> alex_joni: Going by past experience, we expect 2.6.24 to be released by February. That should give us a good 1-2 months to iron out the issues.
<alex_joni> ok guys, you've been really helpfull as always.. I'll be back around that time :)
#ubuntu-kernel 2007-11-16
<ianloic_> hey, is there a repo containing previous ubuntu kernel releases
<ianloic_> so I can try downgrading my kernel easily?
<ianloic_> I want to isolate a bug I'm seeing
<kraut> moin
<gregorovius> I know this is a dev channel, but I can't seem to get any answers, maybe one of you can point me to the right direction. I'm running gutsy, I installed the RT kernel, but when booting from it my computer becomes unresponsive
<gregorovius> I can type, move the mouse, change ttys, but I can't login and there's no disk activity
<gregorovius> and I can't find any similar bug reports
<pwnguin> why linux-rt?
<gregorovius> trying to use jack without xruns...
<gregorovius> any ideas? I can't even see anything weird on the logs
<pwnguin> what's mount say?
<gregorovius> pwnguin, sorry, what's mount got to do with it?
<pwnguin> if you're having problems with disk, perhaps mount will reveal some bad state
<gregorovius> pwnguin, http://paste.ubuntu-nl.org/44703/ but I don't see nothing unusual
<pwnguin> fuseblk?
<gregorovius> sda1, I guess that'd be my ntfs partition
<pwnguin> i thought you couldn't log in
<gregorovius> now i'm with the generic kernel, with the RT kernel I can't do anything
<pwnguin> not even with the recovery console?
<gregorovius> didn't try that, I guess I should
<gregorovius> it works up to init 1
<gregorovius> it crashes when I start gdp
<gregorovius> gdm*
<abogani> Zinc go very slow with a simple git-clone: is it normal?
<zul> morning
<abogani> zul: to you
<abogani> zul: Do you know why zinc runs so very slow?
<zul> abogani: nope
<abogani> Perhaps my internet connection have some trouble...
<amitk> abogani: zinc is not loaded at all
<amitk> abogani: load average: 0.00, 0.04, 0.02
<tepsipakki> I sent an email to kernel-team, hopefully someone will let it through :)
<ogra> BenC, awake already?
<Kano> hi
<Kano> could ivtv-fb included into the lum package?
<Kano> a tiny mod is needed to the source, as the "wrong" headers are used by default, but basically it works then
<Kano> hmm maybe not for the current release, i see there is very new one..
<Kano> http://dl.ivtvdriver.org/ivtv/archive/1.0.x/ivtv-1.0.3.tar.gz
<Kano> well 100% is to replace the ivtv-driver*.h file...
<Kano> i would do that
<rtg> Kano: send a patch to kernel-team@lists.ubuntu.com, but note that it has to conform to the SRU policy.
<Kano> sru?
<zul> stable release update
<Kano> when will be a package for kernel+lum with the current changes?
<Kano> btw. i posted the raid 5 patch for dmraid on the kernel list and got no response
<Kano> it is 100% verified that the patch works
<Kano> https://lists.ubuntu.com/archives/kernel-team/2007-October/001878.html
<Kano> i verified it on 2 ubuntu boxes remotely
<abogani> Kano: Sure, It importat that you have verified the patch on two your machines but it is more important check the patch for avoid regressions and this isn't a simple task.
<Kano> as it only adds a new module what regression should happen?
<Kano> i use it daily
<Kano> same kernel, just without raid 5 hardware currently
<Kano> btw. how are the packages are created out of the git without that additional git data
<rtg> lamont: Are you and Kyle co-maintainers of hppa?
<lamont> rtg: kyle is the upstream side of things, and I deal with ubuntu and such
<lamont> sup>?
<rtg> lamont: I'm about to upload configs for hardy. Would you go through the hppa configs and send me any changes you need?
 * lamont needs to run a quick errand
<lamont> rtg: can do
<lamont> there's an outstanding 64-bit A500 bug that we need to track down eventually... that'll certainly result in some changes to the configs
<rtg> lamont: upload is done.
<lamont> it's not exactly top-of-my-list right now though
<lamont> upload to where?
<rtg> the usual place on kernel.ubuntu.org.
<lamont> and will look when I get back online later
<lamont> ah, ok
<rtg> kernel.ubuntu.com
<rtg> lamont: its in the git repo, not a source package upload.
<lamont> right
<lamont> I assume ubuntu/ubuntu-hardy.git, and will look at scrollback when I'm back online
<rtg> lamont: yep.
<ogra> amitk, do you happen to be here ? 
<amitk> ogra__: hi
<ogra__> hey
<ogra__> i ran into this patch: http://lwn.net/Articles/198333/
<ogra__> by reading teh thread it looks like grekKH isnt opposed to it 
<amitk> awesome
<ogra__> (its for 2.6.18 though)
<amitk> ogra__: that shouldn't be a problem now that we have something that supposedly works
<amitk> we just need to find time to port it :)
<ogra__> :)
<rtg> amitk: how do I build lpia? Its doesn't follow the normal custom-binary-FLAV formula.
<amitk> rtg: it should
<amitk> fakeroot debian/rules custom-binary-lpia{,compat}
<amitk> ohh.. you need the lpia chroot :p
<rtg> amitk: I think I saw an option in 2.6.24 that allows USB devices to persist during suspend.
<rtg> amitk: ah, the lpia chroot. I should have guessed. I thought it was an i386 based flavour.
<amitk> rtg: ogra__: great.. I will play with it during my alleged vacation
<ogra__> doh !
<ogra__> dont !
<ogra__> you can surely get assigned some work time for that :)
<ogra__> relax during your holiday :)
<amitk> rtg: is everything in 2.6.23.x stable tree guaranteed to be in 2.6.24?
<amitk> http://lwn.net/Articles/258938/rss
<rtg> amitk: In some form or another, unless it was deemed a bad feature and got ripped out.
#ubuntu-kernel 2007-11-17
<jogi> hello
<jogi> I am a victim of the fsck check failed. UUID unable to resolve.
<jogi> two of my /dev/sdXX partitions are completely missing
<jogi> Am on feisty
<jogi> google got me to bug 106209
<ubotu> Launchpad bug 106209 in partman-basicfilesystems "fsck Unable to resolve UUID" [High,Confirmed] https://launchpad.net/bugs/106209
<jogi> any workaround present
<jogi> ?
<jogi> I am unable to run any sudo commands :-(
<Kano> hi, i just saw a new hardy repo. on which kernel is that based?
<crimsun> 2.6.24-rc
<Kano> ok
<Kano> is hda intel enabled?
<crimsun> alsa will be enabled separately
<crimsun> it has been a serious PITA attempting to backport the changes
<Kano> but no lum are for it?
<crimsun> AFAIU, for hardy there will be a separate alsa-foo package tracking alsa-{kernel,driver} hg [tip, possibly]
<Kano> ok
<Kano> and is the dmraid 45 patch working with it?
<crimsun> I have not tested ubuntu-hardy.git; I'm running vanilla 2.6.24-rc3
<Kano> takes ages to fetch it currently...
#ubuntu-kernel 2007-11-18
<Kano> did anyone else test the 2.6.24 kernel?
<Kano> i dont get any other kernel module to work, no nvidia, no fglrx, nothing...
<cathya> Problem is a kernel oops on boot.  Stock ubuntu-server kernel oopses, and I can get it to come up.  It hangs while setting up udev.  I can get the system to come up by killing everything (either ctrl-alt-del or magic-sysrq + k).
<cathya> any hints?
<cathya> I compiled a new kernel that was well-suited to my hardware (which is: Core 2 Duo at 2.2 Ghz in a Gigabyte GA-G33M-DS2R, 3 SATA hdds on the Intel fakey-RAID (running straight AHCI, no goofy RAID), and DVD-ROM on the other IDE).
<cathya> I havent tried the desktop kernel work though..
<cathya> I could try jumping runlevels.  Trouble is udev starts in single-user, too.
<IntuitiveNipple> Can you start it with init=/bin/bash ?
<cathya> IntuitiveNipple: I can start it, eventually, with a full system.  But it will oops while booting.  It occurs to me that I may not have tried futzing with init - another good thought.
<cathya> It starts from an initrd that has bbox... it'll have to be /bin/sh, not /bin/bash.  But I'll see if that resolves the oops.
<cathya> I'm thinking if this is an udev problem by disabling udev and booting, then dmesg | grep -i "error"
<cathya> Or any more possible thoughts on this?
<IntuitiveNipple> I was thinking along similar lines. Does it oops whilst udev is initialising, or before udev starts. Your previous comment on that was unclear.
<cathya> I will see if I can find anything more.  Aside from the oops, I have not found much in dmesg.
<IntuitiveNipple> If it is whilst udev is initialising stuff, then I'd drop some /etc/udev/rules.d/ rules that I suspected, try to narrow down the precise cause.
<cathya> Too many unknowns to narrow it down reliably...
<IntuitiveNipple> Have you got the log showing the oops?
<cathya> IntuitiveNipple: It appears to be while udev is initializing.  I magic-sysrq-t'd while it was hung, and the only userland processes were related to udev startup.
<cathya> IntuitiveNipple:  Should have, yes.
<cathya> let me get to this box and pastebin it.
<IntuitiveNipple> Best to post a bug report to Launchpad, attach it plus an output of lspci -nn
<cathya> You think its a bug?
<IntuitiveNipple> If it oops, yes!
<cathya> I want to be sure not to waste your(Developers) time, 
<IntuitiveNipple> Which kernel is this? Gutsy?
<cathya> IntuitiveNipple: There is more funkiness to this setup.  Root is on one of the SATA drives.  /home and /var are on an MD RAID5 across the three drives.  I do not know if that is giving it fits.  Doesn't appear to.
<cathya> Yes, gutsy.
<IntuitiveNipple> If it turns out not to be a bug, it'll only get marked invalid, but once it is in launchpad people will look at it and if they have input, you'll hear about it
<IntuitiveNipple> ooo ooo ooo
<cathya> My kernel is 2.6.23.8, and has the same problem.
<IntuitiveNipple> I'm not sure about this, *but* I'm sure I saw a conversation along the lines of, Ubuntu can't cope with separate / and /var, and I'm sure that is in launchpad
<cathya> Are you a dev?
<IntuitiveNipple> I'm on the kernel ACPI team, and I do a lot of debug work
<cathya> Yeah its gotta be there on launchpad
<cathya> COuld you direct me to that bit in launchpad or where do i go here on?
<IntuitiveNipple> Are you using LVM?
<IntuitiveNipple> https://bugs.launchpad.net/ubuntu/
<cathya> IntuitiveNipple: Just md
<IntuitiveNipple> I wish I could find mention of that /var issue... I may have just seen people talk about on IRC
<IntuitiveNipple> or, it may be in the mailing list! Grrr
<cathya> IntuitiveNipple: I have logs showing the oops.  I apparently no longer have the log showing the process dump, which is disappointing.  I'll regenerate that one.
<IntuitiveNipple> then post the launchpad bug # here
<cathya> In the errors, he most important line appears to be [   40.923128] BUG: unable to handle kernel paging request at virtual address f8b7fffc
<cathya> s/he/the/
<cathya> Then it dumps an oops.
<cathya> IntuitiveNipple: Here as in ?
<cathya> oh you mean I paste it here?
<cathya> Ok.
<IntuitiveNipple> in this room, so any dev that looks at the back-history can click through to the bug
<IntuitiveNipple> If you type bug #163011
<ubotu> Launchpad bug 163011 in linux-source-2.6.22 "[FTBFS] unknown field âaio_reserved3â building User Mode Linux" [High,Triaged] https://launchpad.net/bugs/163011
<IntuitiveNipple> See? uboto provides a link for you
<cathya> How do I add it?
<cathya> Ok
<cathya> So I post it in launchpad and just give you the number later I guess?
<cathya> So they can look through it
<IntuitiveNipple> Once you've report the bug, simply type in here bug #<number>
<cathya> Gotcha
<IntuitiveNipple> Yes
<cathya> Thanks
<cathya> i wanted to disable acpi.. I really wanted to avoid it.  That seems to be the solution to a lot of these issues.
<cathya> I've seen a lot of issues with acpid loading modules that crash a system, and stuff like cpuspeed (throttles the CPU when there is not much load) causing strange errors
<cathya> Anyhow Im filing a bug report
<IntuitiveNipple> Unless the motherboard has a broken DSDT, ACPI should be fine. With Ubuntu you can correct the DSDT and load the fixed one at boot-time
<cathya> Good so that can be overwritten
<IntuitiveNipple> Generally, the Linux approach is, the ACPI interpreter works to specification (hah!) so if it breaks, it is an issue with the BIOS (and it usually is!). Windows will include workarounds to play nicely. There's another approach that says if it works with Windows it should work with Linux.
<cathya> IntuitiveNipple: 163551 
<IntuitiveNipple> bug #163551
<ubotu> Launchpad bug 163551 in ubuntu "Kernel oops during boot on gutsy server" [Undecided,New] https://launchpad.net/bugs/163551
<cathya> That'll do?
<IntuitiveNipple> It looks to be the AGP bridge
<cathya> That was my first thought, so I disabled the AGP bridge in the custom kernel (I don't need it).
<cathya> It just blew out. It now occurs to me that that may have been because of a bad initrd, however - it didn't oops, it just collapsed trying to mount root.
<IntuitiveNipple> the fault appears to happen at intel_i915_configure()
<cathya> Would it be helpful for me to compile this kernel without agp and a decent initrd?  I want to recompile anyway, because I want a monolithic kernel.
<IntuitiveNipple> you could try blacklisting intel_agp
<cathya> That would certainly be quicker.  Let me see if I made that a module.
<cathya> IntuitiveNipple: .. stock kernel.  Sorry, I'm a bit slow today.
<IntuitiveNipple> lol :)
<IntuitiveNipple> I know how it is
<cathya> IntuitiveNipple: no oops.  Boots perfectly.
<IntuitiveNipple> ok... can you do without intel_agp?
<IntuitiveNipple> You'd best add a comment to the bug describing that as a workaround for the issue
<cathya> So that does it for me.  I'll update the bug.
<IntuitiveNipple> Thanks
<cathya> IntuitiveNipple: Absolutely.  This will be headless for most of its life.
<IntuitiveNipple> I wish I was!
<cathya> Thank you for the help.
<IntuitiveNipple> You're welcome
<cathya> So, next question... it _appears_ to be running fine with /var off on its own.  Is this going to create a problem for me down the road?  I like having /var contained, if at all possible.
<IntuitiveNipple> I wish I could remember where I saw the discussion on that, but I can't. Just test well and then ignore me :p
<cathya> heh.  Wilco.  Thanks for the heads up in any event.
<IntuitiveNipple> It *may* have been to do with ubiquity and the desktop CD installer, so that wouldn't affect you
<cathya> It would be very annoying if some system cared much about an adminisrative decision.
<cathya> I've seen similar problems elsewhere that made a bit of sense.  For instance, sometimes if you have to start something funky in order to mount /var, there will be a problem with delayed writes.  This happens when people crypto /var, for instance, and the networking subsystem is started first and tries to write to it.
<IntuitiveNipple> Thinking about, the installer would make sense. Because a separate /car implies it'd have to 'know' to mount / then mkdir /var, then mount /var
<IntuitiveNipple>  /car??? lol
<cathya> lol
<cathya> Okay.  For what it's worth, I didn't install this way - I installed onto a monolithic fs, then added the raid arrays and mounted them.  So there is _a_ /var right away, just not the one that will be there when daemons start.
<cathya> ok IntuitiveNipple Thanks a lot
<cathya> I'll be back later:)
<IntuitiveNipple> don't hurry.. I can do without any more bugs today... I'm all full up :)
<cathya> Haha I'll still see you in a bit:) Nice talkin to you
<kraut> moin
<socketErr> what os-virtualization (like user-mode-linux, openvz,...) is supported by ubuntu?
<soren> socketErr: uml, qemu, and kvm are all in universe.
<JanC> as well as virtualbox-ose
<Kano> something must be in 2.6.23 that fixes this
<Kano> http://ftp.tu-chemnitz.de/pub/linux/ubuntu-releases/kubuntu/gutsy/MD5SUMS
<Kano> err
<Kano> https://bugs.launchpad.net/linux/+bug/54294
<ubotu> Launchpad bug 54294 in linux-source-2.6.20 "Failed to allocate mem resource #6 ... (dup-of: 159241)" [Low,Confirmed] 
<ubotu> Launchpad bug 159241 in linux "[Tracking Bug] PCI resource allocation warnings" [Unknown,Fix released] 
<Kano> that
<Kano> some laptops can not boot at all
<Kano> also 2.6.23 fixed another issue with intel onboard gfx which could not detect the right screenres from vga monitor
#ubuntu-kernel 2008-11-10
<CarlFK> what kernel .deb do I get with ubuntu-8.10-desktop-amd64.iso    ?
<crimsun> the one corresponding to linux-image-2.6.27-7-generic 2.6.27-7.14
<crimsun> (http://releases.ubuntu.com/8.10/ubuntu-8.10-desktop-amd64.manifest)
<CarlFK> yeah, but I can't figure out what the name is... expecting something like linux-image-x64 or -amd64
<CarlFK> this worked:  http://people.ubuntu.com/~smb/bug254668/linux-image-2.6.27-3-generic_2.6.27-3.3smb5_amd64.deb - I am looking for the released version 
<crimsun> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.27-7-generic_2.6.27-7.14_amd64.deb
<CarlFK> does apt-cache search filter that out if I am booted into a 32 bit kernel?
<CarlFK> thanks btw - downloading now
<crimsun> well, the binary package name is identical, but aptitude download would retrieve the version for your $arch, so it wouldn't quite do what you likely intend
<CarlFK> I don't see it here either:  http://packages.ubuntu.com/search?keywords=linux-image-2.6.27-7-generic_2.6.27-7.14_amd64&searchon=names&suite=intrepid&section=all
<CarlFK> "packages that names contain linux-image-2.6.27-7-generic_2.6.27-7.14_amd64 in suite(s) intrepid, all sections, and all architectures.       Sorry, your search gave no results"
<CarlFK> ah
<crimsun> nah, you'd search on the binary package name
<crimsun> and 7.14 has been superceded by 7.16
<CarlFK> thanks again.   I was going batty 
<crimsun> https://launchpad.net/ubuntu/intrepid/+source/linux will give you the rundown for intrepid
<CarlFK> dpkg -i linux-image-2.6.27-7-generic_2.6.27-7.16_amd64.deb =  package architecture (amd64) does not match system (i386)
<CarlFK> but I did this before...
<CarlFK> at least I thought i did
<crimsun> what are you attempting to accomplish?
<CarlFK> run qemu-system-x86_64, install u-s-x64, and test a few things
<CarlFK> I was running ï»¿qemu-system-x86_64 on my 32, and it looked like the install would take over 10 hours 
<CarlFK> $ uname -a; Linux dv67 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:06 UTC 2008 x86_64 GNU/Linux
<CarlFK> yay.
<CarlFK> however, it replaced the 32bit ver of /boot/vmlinuz-2.6.27-7-generic *grumble*
<NCommander> Who's our local grub expert
<CarlFK> I have fought with grub often...
<CarlFK> i often win by dumb luck 
<NCommander> CarlFK, I'm hoping I can get someone to work with me to close a long standing grub bug
<NCommander> #3339
<NCommander> Bug #3339
<NCommander> ...
<NCommander> Bot is broken
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/3339
<CarlFK> Ubuntu grub should be deluxe...
<NCommander> YEah
<NCommander> I already found the patch in SuSE
<NCommander> And I'm testing our grub with it
<NCommander> I found this bug after I set up my mom with dual boot Ubuntu
<NCommander> (I single boot so I didn't know we didn't have a graphical loader)
<CarlFK> there was mention of making it optional.  I would start with it being a package that can be installed 
<NCommander> It would mean a new grub package
<NCommander> Who's the Ubuntu grub guy?
<NCommander> (the packaging says the kernel team is the official maintainer ...)
<CarlFK> that sounds like replacing grub 
<CarlFK> er
<CarlFK> that sounds like replacing the current grub package 
<NCommander> well, its a code patch that adds the command gfxmenu
<CarlFK> my though is let the installer install the normal grub package, and have a 2nd one that can be added later, 
<CarlFK> the only thing I know about this is from reading ï»¿#3339
<NCommander> Well, the way it works is the patch from SuSE adds a gfxmenu command
<CarlFK> but I will be surprised if it replaced the current grub right out the dooor 
<CarlFK> make a grub-gfx package that replaces the current grub with the patched one.  and maybe hacks the menu.lst with something to make it pretty 
<CarlFK> hmm... "replace grub" isn't clear 
<NCommander> I don't get the reasoning, don't we want this the default for Ubuntu? (scary text bootloader == bad)
<NCommander> Having no theme is as easy as not having one installed
<CarlFK> Colin wants stability over pretty 
 * NCommander would note that SuSE and Fedora use the same patch and have for consider time
<NCommander> I think Debian might now too
<CarlFK> you are welcome to argue with him :)
<CarlFK> but I would bet it gets implemented quicker if it was first an easy add on
<NCommander> But its not an add-on, it litterially would replace the installed grub
<NCommander> Hrm
<CarlFK> any idea where grub-installer gets the bytes that is grub to drop onto the boot loader?
<NCommander> the stage1 and stage2 files
<CarlFK> what I am calling an add on would replace wherever those bytes are, just like installing an app 
<NCommander> brb
<NCommander> testing new grub
<CarlFK> it would make it easy for the people who want ti now to have it now, and them using it would build support for stability 
 * NCommander is trying to figure out the existing grub package
<NCommander> brb
<NCommander> CarlFK, back
<NCommander> CarlFK, so our grub does have support for graphical bootloader support
<NCommander> It looks like on the last merge we pulled the patch from Debian
<NCommander> but nothing takes advantage of it
<CarlFK> heh
<CarlFK> well, never mind my idea :)
<NCommander> It just means ubuntu/kubuntu/xubuntu default settings need to be tweaked to install a splash and then call upgrade-grub
<CarlFK> or.. if you want to tread lightly, leave the default alone and make an app that tweaks 
<CarlFK> kinda like nvidia-settings and xorg
<NCommander> Did I tell you that this is one of the highest rated and wanted things on brainstorm :-) (I have no problem doing that, but it should be the default once its tested)
<CarlFK> looks like you would have to argue with both Colin and Brian Murray - 
<NCommander> ??
<CarlFK> "       Declined       for       Gutsy       by       Colin Watson     ...        Declined       for       Intrepid       by       Brian Murray     "
<CarlFK> neat spaces...
<NCommander> I don't think they'd object
<NCommander> no code changes to grub necessary
<NCommander> even update-grub knows how to handle a splash
<NCommander> brb, testing splash screen
<NCommander> CarlFK, neat, I have a grub splash that shows the Debian logo
<NCommander> :-P
<CarlFK> heh - you should pull an m$ and show a desktop 
<NCommander> :-P
<smb_tp> tseliot, Hi Alberto, tjaalton told me you know of some problems with the 173 nvidia driver. What is the story there?
<tseliot> smb_tp: a number of users (which specific hardware configurations which I can't remember) reported that the only driver that works for them in hardy the one in nvidia-glx-new
<tseliot> I provide newer drivers in the linux-restricted-modules-envy
<tseliot> so that we don't have to break the one in the linux-restricted-modules
<tseliot> smb_tp: did you try envyng to install my drivers?
<smb_tp> tseliot, Is this for Intrepid only? The reason I came to it was, that we have been asked to update lrm for hardy in order to fix some suspend/resume problems.
<tseliot> smb_tp: no, the lrm-envy only exist in hardy (in universe/multiverse)
<smb_tp> tseliot, Hm, so it would be possible to use the nvidia drivers from envy which are newer instead of the lrm ones without updating lrm at all...
<tseliot> smb_tp: yes, right
<smb_tp> tseliot, Hm, cool. Seems there is much more choice I am  aware of. :-/ Does that simply work by installing envyng in parallel or would it need lrm to be removed? Oh well, I should probably just have a look into the web...
<tseliot> smb_tp: the lrm-envy will coexist with the drivers in the lrm. If you remove the lrm-envy you will be able to use the nvidia driver in the lrm again.
<tjaalton> smb_tp: right, I forgot about envy and thought you were aware of it already :)
<tseliot> if you want to install them and configure the xorg.conf automatically you can use either the textual installer (envyng-core) or the gtk ui (envyng-gtk)
<smb_tp> tseliot, Sounds great. That gives a simple way of getting the newer driver for those in need without breaking those for which the lrm driver works better.
<tseliot> here you will find the full instructions: http://www.albertomilone.com/envyngfaq.html#A
<tseliot> yes :-)
<smb_tp> tjaalton, It's one of the things I heard some time and which did not catch. :-[
<fransman> hi to all
<fransman> is there a Ubuntu 2.6.28 git avail?
<abogani> fransman: Not yet
<fransman> Ok so got to wait for some day's
<abli> Hi! I was told on #ubuntu-installer that this channel might be a better place for my question: I have a machine with an NVidia 8600 video card in a pci-express slot. If the video card is in the slot, hardy or intrepid live CDs don't boot. Apparently they crash due to kernel oops. If the NVidia card is removed, they appear to boot fine. Any idea what might be wrong or how can I debug this? (installing without that videocard and then putting it back would
<abli>  be fine, but if the liveCD can't boot what are the chances that booting from hdd will work?)
<Jodoog> Hi :) I know it was planned for 2.6.28 in order to get Lenovo's APS working without need for a patch...but has 2.6.28-rc4 put general disc protection directly into the libata driver already? Thanks a lot :)
<papo> hello
#ubuntu-kernel 2008-11-11
<dholbach> hi guys
<dholbach> maybe you can help me debugging why the wifi kill switch on my IBM X40 does not work any more (intrepid)?
<dholbach> I can load the ipw2100 module without problems, but I can't get the wifi LED to light up at all
<amitk> dholbach: probably best to wait for rtg to show up. He has been following the led issues closely.
<dholbach> amitk: it worked nicely like two days ago :)
<amitk> huh
<dholbach> amitk: I can't get wireless to work at all
<amitk> dholbach: does dmesg say anything about kill switch active?
<dholbach> I dunno if it's a hardware thing or if it just broke in intrepid, but I don't know how to debug it
<dholbach> daniel@lovegood:~$ dmesg | grep -i kill
<dholbach> daniel@lovegood:~$ 
<dholbach> maybe I chose the wrong words... what I meant is that FN-F5 right now just toggles bluetooth on and off, it doesn't do anything regarding to wifi
<amitk> dholbach: what does 'modprobe -r ipw2100; modprobe ipw2100' do in dmesg?
<amitk> also, find /sys/ -name "*kill*"
<dholbach> +[ 6603.769069] ieee80211_crypt: unregistered algorithm 'NULL'
<dholbach> +[ 6603.799013] ieee80211_crypt: registered algorithm 'NULL'
<dholbach> +[ 6603.811687] ieee80211: 802.11 data/management/control stack, git-1.1.13
<dholbach> +[ 6603.811699] ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
<dholbach> +[ 6603.824297] ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
<dholbach> +[ 6603.824309] ipw2100: Copyright(c) 2003-2006 Intel Corporation
<dholbach>  /sys/devices/platform/thinkpad_acpi/rfkill
<dholbach>  /sys/devices/platform/thinkpad_acpi/rfkill/rfkill0
<dholbach>  /sys/class/rfkill
<dholbach>  /sys/class/rfkill/rfkill0
<dholbach>  /sys/module/rfkill
<amitk> dholbach: what do the two rfkill0 files contain?
<dholbach> hang on, they're directories :)
<dholbach> amitk: http://paste.ubuntu.com/70342/
<dholbach> seems they only contain bluetooth stuff :-/
<amitk> hmm
<amitk> dholbach: most times the Fn+F5 is tri-state or quad-state, BT WLAN 0 0, 0 1, 1 0 and 1 1
<dholbach> *nod*
<amitk> how does it work on yours?
<dholbach> I think it's quad-state too
<amitk> dholbach: and I guess you have cycled through all those states?
<dholbach> yes
<dholbach> check out my discussion with slangasek on #ubuntu-devel (just the last lines)
<dholbach> amitk: seems like my issue is not fixed yet :-/
<dholbach> [12405.928353] ipw2100: ***** PARITY ERROR INTERRUPT !!!! 
<dholbach> [12405.928386] ipw2100: ***** PARITY ERROR INTERRUPT !!!! 
<dholbach> [12405.928401] ipw2100: ***** PARITY ERROR INTERRUPT !!!! 
<dholbach> [13512.268457] ipw2100: eth1: write index mismatch
<dholbach> [13512.270513] ipw2100: ***** PARITY ERROR INTERRUPT !!!! 
<dholbach> [13512.516413] ipw2100: eth1: write index mismatch
<dholbach> [21216.305009] ipw2100: eth1: ipw2100_verify failed: -5
<dholbach> [21216.305072] ipw2100: eth1: Failed to power on the adapter.
<dholbach> [21216.305077] ipw2100: eth1: Failed to start the firmware.
<dholbach> [21309.349497] ipw2100 0000:02:02.0: PCI INT A disabled
<dholbach> this makes me guess that it's a hardware problem :-/
<rtg> dholbach: 'PARITY ERROR INTERRUPT' certainly makes it seem like a HW error. Can you see the same result with a Hardy Live CD?
<dholbach> rtg: the X40 does not have a CD drive :)
<amitk> dholbach: we know for a fact now that your card has dust puppy issues
<dholbach> rtg: I had this http://people.ubuntu.com/~dholbach/img_2498.jpg this morning
<amitk> dholbach: tried giving it a shower? :)
<dholbach> amitk: I tried that like 2 years ago, when I emptied a glass of water into the keyboard while the laptop was running
<dholbach> I think I need to live with the idea that the hardware is slowly dying
<amitk> dholbach: you wouldn't happen to have a can of compressed air handy? It is useful to clean the motherboard...
<dholbach> amitk: no, unfortunately not, but I could try it
<mjg59> dholbach: An 1802 error means the card didn't even manage to give its PCI configuration data to the BIOS
<mjg59> Or corrupted it in the process
<mjg59> Take the card out, attempt to reseat it?
<dholbach> mjg59: did that this morning - it worked until now (6-7h)
<mjg59> dholbach: Mm. Might be a bad contact, or might be the card dying.
<dholbach> mjg59: yeah, the machine is 4+ years old now :)
<Jodoog> Hi :)
<Jodoog> I know it was planned for 2.6.28 in order to get Lenovo's APS working without need for a patch...but has 2.6.28-rc4 put general disc protection directly into the libata driver?
#ubuntu-kernel 2008-11-12
<Daviey> Would it be possible to revert upstream commit 6427f7995338387ddded92f98adec19ddbf0ae5e ?
<soren> Daviey: Why? (I can't do anything about it, I'm just curious.)
<C10uD> hello there
<C10uD> anyone using frequency scaling? :)
<C10uD> uhm, i'll get straight to the facts: i basically just want to blacklist some frequencies 
<C10uD> but i can't find how to do it
<C10uD> i know how to set a minimal frequency but i can't find how to skip "intermediate" ones
<AnAnt_> Hello, is there any further info that I should add to bug 281451 ?
<BenC> bug #281451
 * BenC wonders where ubotu is
<BenC> AnAnt_: more than likely, there's not much we can do
<BenC> AnAnt_: some vendors just don't add all the proper vga modes to the vga bios that the card supports
<BenC> I'm not even sure that 1280x800 is a vga mode
<AnAnt_> hmmm, ok
<AnAnt_> BenC: yes I think it is a vga mode, on a laptop that got an Intel graphical adapter, hwinfo --framebuffer does report 1280x800 vga mode
<AnAnt_> why can't nvidia & nvidiafb be used at the same time ?
<mjg59> Because both claim the PCI device
<BenC> AnAnt_: thing is, vesafb and uvesafb only handle what the bios explains to it
<AnAnt_> I see
<BenC> AnAnt_: I've noticed that nvidia and ati seem to skimp on the vga bios stuff, relying on people to have the accelerated drivers to do anything useful
<AnAnt_> lousy cards !!
<AnAnt_> thanks anyways
#ubuntu-kernel 2008-11-13
<Daviey> soren: late reply - getting verbose information 10 times per second aint helpful :)
<Daviey> Bug 256767
<Daviey> Bug #256767
<Daviey> fail
<andresmujica> hi!
<andresmujica> is it possible if someone can check this bug? https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/290506
<NCommander> amitk, ping
<amitk> NCommander: hiya
<Kano> hi, is there a 2.6.28 test git somewhere?
<amitk> Kano: git://kernel.ubuntu.com/rtg/ubuntu-next
<Kano> ah, this is already 2.6.28?
<Kano> 2 month old git?
<amitk> Kano: according to rtg's post it was supposed to be
<Kano> well from shortlot it is 2.6.27-1.2
<amitk> huh.. looks like he did the work, sent email to the mailing list but forgot to push it out
<Kano> funny
<amitk> Kano: actually it is from 5 days ago
<amitk> so he seems to have pushed it out
<amitk> only the tags are missing
<amitk> http://kernel.ubuntu.com/git?p=rtg/ubuntu-next/.git;a=shortlog;pg=1
<amitk> look for Linus' commits
<Kano> ah rtg next
<Kano> will check it out
<Kano> amitk: well it does not seem to compile also it tries to create still a 2.6.27 package
<zul> uh...include/asm-x86/ has been moved in 2.6.28?
<mjg59> Yes, arch/x86/include
<Kano> zul: does the new git repo compile for you?
<zul> Kano: i havent tried
<NCommander> amitk, you told me once why it would be a bad idea to have something, say, the rt kernel patchset (as an example) build out of the linux-ports source package via binary-custom.d, what was the reasoning behind that?
<amitk> NCommander: i don't recall that conversation
<NCommander> oh
 * NCommander would like to be able to generate linux-ports-rt out of a single source package via the binary-custom mechanism, but if its a bad idea ...
<BenC> NCommander: because if the patch starts failing to apply, it holds up the entire source
<BenC> NCommander: we ran into that before, and that's why we took those patchsets out of the main tree
<NCommander> BenC, that's only a problem if the tree is constantly rebasing
<BenC> NCommander: not true...any patch has the potential to cause the rt patchset to get rejects
<BenC> especially with something like -rt, which touches hundreds of source files
<BenC> even drivers
<NCommander> right
<NCommander> Or TuxOnIce
<NCommander> The current solution however isn't what I call pretty w.r.t. to the way linux-rt works
<NCommander> This is one of those catch-22 scenarios
<BenC> NCommander: the current scenario puts the blame and responsibility directly on the person who wants to maintain the patchset
<BenC> which is exactly how it should be
<NCommander> makes sense
<StOrM_NW> any recommendations where can i find some information about how to debug an own kernel module?
<StOrM_NW> i m getting kernel panic with an old own module that i tried to port to the ubuntu kernel 2.6.27-7
<marlock> hi
<marlock> i did recompile a vanilla kernel
<marlock> how can i create the related restricted modules?
<marlock> i need the same that are in linux-restricted-drivers...
<marlock> linux-restricted-modules, sorry...
<marlock> is there anyone can answer me?
#ubuntu-kernel 2008-11-14
<rtg> zul: would you be so kind as to respond to this thread on the kernel mailing list. I'm not as conversant with the intricacies of xen as are you: https://lists.ubuntu.com/archives/kernel-team/2008-November/003470.html
<zul> rtg: sure np
<johnny> hi folks, i was having an issue with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/262845
<johnny> is there anything i can do to help?
<johnny> altho i think bisecting from the last working kernel i have 2.6.22 would not be productive
<johnny> oliver grawert directed to me ask you folks
<amitk> johnny: are you sure you don't have multiple devices connected at master and slave?
<johnny> master and slave on sata?
<johnny> i'm not the person who filed that bug btw..
<amitk> johnny: nevermind. I am still reading through the bug
<johnny> it is fine in the gutsy kernel, so i don't see how that would all of the sudden bite me now.. even if it were a case like that
<amitk> johnny: the bug is against intrepid
<johnny> i know
<johnny> i'm using intrepid, but the last working kernel i have, is from gutsy
<johnny> had bugs that have affected this system every release since gutsy :(
<johnny> either network issues, missing sound drivers, completely broken sata, and now  just bad sata
<amitk> johnny: could you attach lspci, dmesg out from you machine too
<johnny> dmesg out from the working gutsy kernel.. don't think that would be useful
<johnny> lspci is possible tho
<johnny> i can't reboot that machine.. it is in ltsp production.. and booting it up with intrepid kernel takes at least 10 minutes :)
<amitk> johnny: i will need dmesg from gutsy and intrepid
<johnny> when do you guys plan on releasing a new kernel package?
<johnny> perhaps the bug is fixed in more recent 2.6.27.*
<johnny> do you guys have a script that will build a perfect ubuntu kernel package from your git tree?
<johnny> i'd prefer to just try that out
<johnny> i saw some related fixes to my sata controller in the shortlog if intrepid.git
<johnny> in*
<amitk> 2.6.27.4 stable updates was uploaded to proposed (2.6.27-8.17)
<johnny> since when?
<johnny> i didn't see dates for upload on packages.ubuntu
<johnny> maybe i'm looking in the wrong place
<amitk> johnny: if you enable -proposed repos in /etc/apt/sources.list, you should probably see it
<amitk> https://edge.launchpad.net/ubuntu/intrepid/+source/linux/2.6.27-8.17
<johnny> 8 days ago, the fixes i need are 6 days ago
<johnny> at least some of the fixes..
<johnny> amitk,  i'm going to install that one
<johnny> but.. do you guys have a script i can use to build something later, if that doesn't fix it?
<johnny> i'll be back in a bit, but if you wanna link me, that'd be great
<doko> amitk: please could you upload something that builds an linux-libc-dev on armel?
<amitk> doko: I am running a test build currently. I'll email you when it is done.
<amitk> doko: are you available to check it over the weekend?
<doko> amitk: will look at it tomorrow. I'm just interested in getting the chroot installable, so a build without any image would be fine as well
<mkrufky> there was a time when i was able to pull git trees from kernel.ubuntu.com, but it doesnt seem to work anymore.  i cant pull from kernel.org either, so i use my ssh account to do that ....   any suggestions how to pull from kernel.ubuntu.com without having an ssh account, when my company's firewall gets in the way?
<mkrufky> i ask, because i have a lod of patches that i have to backport to both hardy-lum *and* intrepid .... anybody?
<mkrufky> loAd
<rtg> mkrufky: can't you use the git:// protocol?
<rtg> git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid.git 
<mkrufky> it gives me:
<mkrufky> kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection refused
<mkrufky> fatal: unable to connect a socket (Connection refused)
<mkrufky> its kinda frustrating... . i dont know if something changed in git, or if somebody changed something on our firewall
<mkrufky> i always had this problem on kernel.org, so ive just used my ssh account there instead, but i never had this problem with kernel.ubuntu.com until recently ... (then again, i havent tried kernel.ubuntu.com in the past month or so)
<rtg> mkrufky: do you have a local issue? I just tried pulling with this path, git version 1.5.6.3
<rtg> works ok.
<rtg> mkrufky: off to lunch, back in an hour or so.
<mkrufky> thanks rtg ... i'll ask the network guys here
<mkrufky> hmm, im using git version 1.5.4.3
<amitk> mkrufky: use the http links shown on the top the git page
<mkrufky> amitk: yeah those arent working ... i think its a firewall issue here in my office
<mkrufky> amitk: thanks though
#ubuntu-kernel 2008-11-15
<CarlFK> ï»¿[16549.921345] WARNING: at /build/buildd/linux-backports-modules-2.6.27-2.6.27/debian/build/build-generic/compat-wireless-2.6/net/mac80211/rx.c:2200 lbm_cw___lbm_cw_ieee80211_rx+0x19f/0x600 [lbm_cw_mac80211]()
<CarlFK> dmesg: http://dpaste.com/90917/
<sourcemaker> I am a urgent problem related to a VPN connection... I receive the kernel error (ll header and martian source error)
<sourcemaker> I have a urgent problem...
<sourcemaker> I tried to fix the problem the whole night... but without success...
<CarlFK> dmesg [  125.019452] NOTE: The dv1394 driver is unsupported and may be removed in a future Linux release. ...
<CarlFK> should that be bugged against the kernel? 
#ubuntu-kernel 2008-11-16
<CarlFK> installed jaunty, boot, dmesg, see stackdump: http://dpaste.com/91033/
<CarlFK> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/287392 looks the same - should I 'me too' it or anything?
<desrt> hi.  has any consideration been given to providing a linux-image-amd64 package for i386 arch?
<desrt> i just manually downloaded and dpkg --force-architecture'd a amd64 kernel onto my 32bit install and everything seems quite fine
<desrt> even the initramfs generated properly (something that surprised me since it's now a weird mix of 32bit utilities and 64bit kernel modules)
<desrt> ok.  i've filed a bug about it.
<soren> desrt: That certainly would have made the few i386->amd64 upgrades I've done much easier.
<soren> amitk: Do you happen to know if the armel kernel will support the NSLU2? Wikipedia says it has a 266 MHz ARM Intel XScale IXP420 CPU.
<NCommander> soren, it will once we have a kernel configuration that supports it
<soren> NCommander: No shit? The kernel will support it once it supports it? :p
<NCommander> soren, I mean once we add a ipx420 varient to the ARMel kernel
<NCommander> the armel distribution itself is compatible (XScale has the necessary instruction support)
<soren> Yeah, I know. Mine already runs Debian.
<NCommander> soren, Debian targets a different ARM instruction set
<NCommander> (armel)
<amitk> soren: yes it will
<CarlFK> #0  0xb808c430 in __kernel_vsyscall ()
<CarlFK> No symbol table info available.
<CarlFK> can I get debug symbols for the kernel?
<laga> hey
<laga> when i "apt-get source linux-image-2.6.24-21-generic", i end up with a source tree that builds 2.6.24-22.
<laga> is that intentional?
<fransman> laga:  maybe 2.6.24-22 goes from your $release_name-security
<Xtreme_Great> Can someone tell me where the build directory inside /usr/src/linux-headers-`uname -r` is?
<Xtreme_Great> I'm trying to make rt73 driver and facing problems...
<Xtreme_Great> I posted the problem #ubuntu and got no response... You are the kernel... Please help.
<Xtreme_Great> :(
<Xtreme_Great> I even checked ubuntuforums for the solution... But nothing worked... And all were incomplete too
<amitk> Xtreme_Great: run 'uname -r' on the command line
<amitk> and then use that output to look in the correct direction /usr/src/linux-headers-<outpu>
<Xtreme_Great> amitk: I already did that... It's 2.6.24-21-rt
<Xtreme_Great> I meant that I can't find the build directory in /usr/src/linux-headers-2.6.24-21-rt
<amitk> Xtreme_Great: you need to install the linux-headers package
<amitk> Xtreme_Great: and you will probably find it in /lib/modules/<kernelver>/build
<Xtreme_Great> That build directory is empty...
<Xtreme_Great> I mean the one in /lib/modules/`uname -r`/build
#ubuntu-kernel 2009-11-09
<apw> Keybuk, pete tells me you might be interested in testing kernels with the ext4 issues sorts (this would be a .32 base) ?
<ghostcube> hi humans logitech uvc bug fixed in 2.6.31-15 from proposed updates on 64bit
<ghostcube> thx
<apw> ghostcube, yay ... which bug was that?
<ghostcube> moment pls
<ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935
<ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,New] 
<apw> hrm, New
<ghostcube> i reported direct aafter karmic upgrade
<ghostcube> but no one took it :)
<apw> heh ... sorry we have a fair few reports out there
<ghostcube> no prob :) 
<Appiah> :D
<ghostcube> works again now in all apps exept camorama
<ghostcube> claims no /dev/video0
<ghostcube> but all others work in kubuntu 
<ghostcube> :)
<slytherin> Can anyone please take a look at bug 476154. I have tracked upstream change that should fix the problem. It will be great if someone could provide a test build for kernel with this patch included.
<ubot3> Malone bug 476154 in linux "Stack trace on console, can not do clean shutdown" [Undecided,New] https://launchpad.net/bugs/476154
<apw> ghostcube, hrm, unless htat webcam is a usb connected one its not obvious there are any fixes in there for it
<ghostcube> its usb
<ghostcube> anything was changed i dont know what
<ghostcube> but it works again for all i aksed with same error
<apw> yeah happy its working for you ... i'll close it off.  do reopen it if it breaks
<ghostcube> ok i will do so :)
<apw> unless we had some modules missing and the module bit fixed it ... hmmm
<ghostcube> it was only the picture not working
<ghostcube> cam was detected and in demesg the driver was installed fine
<ghostcube> it was just a black picture even with 500 watt lamp infront
<ghostcube> :D
<apw> well i'll take any victory however won
<ghostcube> :)
<smb> apw, Hm, the only modules missing were in virtual. And the only usb change seems to be the sense one for the huawei's. But true enough better fixed without understanding that not at all
<apw> yeah oddness
<smb> slytherin, seems to be one coming down from stable. I get a test kernel build
 * apw was just going to ask smb if that update was in stable and if os .5 or .6 ?
<smb> apw, .6
<apw> gah
<apw> pre-pre-propposed
<smb> apw, I do a special kernel and make a note to have that other bug cross-referenced
<apw> yeah
<apw> smb, i note its for powerpc ...
<smb> apw, iirc the original one was 
<smb> (the one which broke things)
<apw> yeah i mean, i would have made x86 test kernels and looked stupid :)
<ghostcube> ah i forgot to test the r128 modul from ppc edition in 9.10 damn
<slytherin> smb: My machine is powerpc. So I will need a powerpc kernel.
<smb> slytherin, ok, seems that was what apw wanted to tell me
<slytherin> smb: I don't know how the kernel packages in Ubuntu work otherwise I could have tried to build it myself.
<smb> :)
<slytherin> I wish PPAs supported powerpc. :-(
<smb> slytherin, Yeah, that would be nice. Fortunately I can use a porter...
<slytherin> smb: By the way I didn't understand your comment - "seems to be one coming down from stable."
<smb> slytherin, There is an upstream 2.6.31.y tree which gets fixes for a certain amount of time (usually until the next version starts being developed)
<smb> slytherin, Some of the 2.6.32 fixes get sent to that stable tree in parallel if they are deemed to be important bug fixes
<slytherin> smb: right, but I didn't find the fix in 2.3.31.y tree. Or may be I misread the change history of that tree.
<smb> slytherin, No its the thing just being through review. I just happen to be on that reviewers list... ;-)
<slytherin> Oh. That is great. So It is like that the change will land in .31 tree and eventually in karmic-updates eventually right?
<smb> Given nobody screams it would be in 2.6.31.6 and then make its way to karmic too. Though the process is a bit slow. Definitely it will help if you can verify the fix in the test kernel 
<smb> slytherin, The kernel is building now, I will update the bug with a link to download it, when it is finished
<slytherin> smb: I will test it tonight (about 6 hours from now).
<smb> slytherin, Great, the kernel should be there by then
<smb> apw, Gah, could you have a look at bug 464552? Can't remember anything really suspend/resume related changing... You?
<ubot3> Malone bug 464552 in linux "suspend_test_finish warning triggers too easily, increase timeout to match mainline times" [Low,In progress] https://launchpad.net/bugs/464552
<apw> smb ... something bad happening on that bug?
<smb> apw, sort of. someone claiming it broke his suspend (the kernel update) and this one getting marked verification-failed
 * apw bets its just another falsey
<apw> people do not get what that change does, not what it means
<smb> ... which could delay the import 2.6.31.5 with 2.6.31.6 rolling its way... :(
<smb> apw, Actually I can't really see any of the changes being related to suspend/rsume
<apw> smb, nope none that i recall
<smb> apw, The only one, maybe, is the change to usb which might make things half working and then breaking susp/res
<apw> yep tend to agree there
<smb> apw, Could you probably make a test kernel, taking out that and let that be retried?
<apw> smb, yep ... have asked him to test the basic as he says 'doesn't work' which is no use
<apw> will get a kernel together now
<Keybuk> smb: did you upload a new kernel to karmic?
<smb> Keybuk, One, yes
<Keybuk> is that in -proposed or -updates ?
<smb> Keybuk, -proposed
<apw> and failing validation right now
<Keybuk> oh, what's failing to validate?
<smb> suspend/resume aparantly but not sure
<apw> the problem is there are 200 bugs dup'd on that one, so we are onto a loser
<apw> its unlikely that patch is the issue for sure
<apw> (if there even is an issue)
<lool> Ng: Didn't experience this Xorg thing you get; flashing capslock means kernel is alive though, so you might want to connect over SSH
<Keybuk> err
<Keybuk> I thought Flashing Capslock meant kernel panic? :p
<apw> flashing by itself means panic normally, a working capslock means something else
<Keybuk> the caps lock light should use morse to output the entire panic dump ;)
<apw> Keybuk, that has been suggested, and actually one of our guys has played with some h/w to receieve it
<Keybuk> that would be Colin wouldn't it?
<apw> Keybuk, steve and colin actually yeah
<Keybuk> apw: it had a Colinishness about it ;)
<apw> yeah mad as a spoon :)
<apw> smb, ok my plan is to produce two test kernels, the first will revert just the change introduced by the bug itself, to confirm (as we know) that the patch is tooo trivial to be the cause of any issues, the second to revert just the usb patch
<Ng> lool: hrm, that's distressing in that it might mean my hardware is failing
<Ng> I'll check with robbie and jerone too
<cking> apw, I'm not quite that mad
<rtg> smb, apw: whats the story on those ureadahead trace patches?
<apw> they modificy the tracing sligthly to allow ureadahead to get more information to allow it to work out wihich executabled are in use
<rtg> are we gonna do 'em for Karmic?
<rtg> apw, actually, I was wondering why they weren't in the last upload, but I see that they are.
<rtg> 7423c4c3b22816168b912c39a0298227076854b8
<apw> yep, they are in the current -proposed kernel, Keybuk has an exception for ureadahead as i understand things
<cking_> they produce some excellent results BTW
<cking_> http://people.canonical.com/~cking/karmic-boot-in-QEMU/boot-total-blocks-karmic-reads.png
<ghostcube> damn i just rebootet and now cam stopped working again 
<ghostcube> so the bug is still there and i cant tell u what its causing
<ghostcube> grml
<ghostcube> anyone can open this one again
<ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935
<ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Fix released] 
<ghostcube> same as before the kernel update
<scroll> Why gcc throws erros when i try include "linux/module.h"?
<ghostcube> apw: ping
#ubuntu-kernel 2009-11-10
<dtchen> ogasawara: thanks, sending upstream.
<benh> TheMuso: ping
 * apw wonders if the lucid compiler will deign to compile his kernel today
<Appiah> hello apw , are you busy?
<apw> Appiah, always busy ... /me is fighting the lucid compilers ... grr
<Appiah> :)
<Appiah> I was wondering what happend to that laptop without networking bug, you mentioned that the kernel with the fix was old.. but for karmic there's no alternative atm
<Appiah> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/418933
<ubot3> Malone bug 418933 in linux "no internet connection (wifi+ethernet doesn't work)" [Low,Confirmed] 
<apw> Appiah, the fix back there never did seem likely as a real fix
<Appiah> well I'm using it now or else I dont have any network on karmic :D
<apw> Appiah, ok ... there seems to be a settling on a fix for things which reverting that commit have been helped by... so i'll pull that back and get you to test a newer kernel with that in
<apw> it'll take a bit
<Appiah> apw ok
<apw> i am not on the fastest of links today
<ghostcube> apw: my bug has arrived again after reboot the webcam was dark again
<ghostcube> :)
<ghostcube> but it worked after the installtion
<apw> so its intermittent then
<apw> (most likely)
<apw> what was the bug # so i can reopen it
<ghostcube> moment
<ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935
<ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Fix released] 
<ghostcube> after the installation of the kernel and reboot the cam worked fine
<ghostcube> the next day after reboot the cam stopped delivering any picture but its working 
<ghostcube> could thi9s be an /dev problem ?
<ghostcube> cause camorama claims no /dev/video0
<ghostcube> all other tools just use the cam 
<ghostcube> but it claims it too if the cam works in cheese oO
<smb> Hm, could this be some v4l1->v4l2 problem...
<apw> normally no /dev/video0 means that the kernel hasn't seen the device i belive as its not asked udev to make the devices
<apw> and it could well be related to that smb yes
<apw> "if a hospital cannot meet 18 week guarentee, the patient would be offered a range of options 'at nhs prices'"
<apw> heh, wrong window
<amitk> apw: trying to sell viagra on #u-k, eh?
<apw> yeah one needs a bit of side income
<Appiah> :)
<ghostcube> smb: i dont know this started with karmic update
<ghostcube> and on jaunty i had the dev/video0
<ghostcube> could this be an usb problem maybe that the usb devices arent registered normally ?
<smb> ghostcube, karmic update as in updating the whole system (not only a kernel update after updating to karmic)? 
<ghostcube> yeah jaunty to karmic
<ghostcube> after this cam stoped working
<ghostcube> then i thought the new kernel from proposed may fixes an driver bug so i tested and it worked direct after reboot
<ghostcube> then a day later after starting pc it didnt work 
<ghostcube> i tried to disconnect and reconnect usb boot with and without it
<ghostcube> no chance
<smb> ghostcube, just to tule that out: is karmic the only os on the machine?
<ghostcube> yeah
<ghostcube> pure linux machine
<ghostcube> and pure ubuntu :)
<ghostcube> nah kubuntu but this shouldnt be the prob hehe
<ghostcube> :D
<smb> ok, so it can't be initialized by something else ;-). Well it might be a race then. There were some because the boot is now more parallel and quicker
<ghostcube> smb: i still boot grub 1 if this is important too
<smb> Hm, I don't believe this should have effects on that...
<ghostcube> in my bug report you see that udev gives a strange device id to the cam 
<ghostcube> could this be the problem ?
<smb> have not yet, looked to it as apw was. lemme see...
<ghostcube> and iam not the only one with exactly this problem  i tested in compiz channel wth spme supporters
<ghostcube> for them it worked too after fresh install of the kernel update then reboot the other day and it stoped 
<ghostcube> totally strange thing hehe
<smb> Hm, just a stupid thought... on the first boot sreadahead is slowing things down to sample the map for speedup...
<smb> where was that again... I believe /var/lib/sreadahead/pack...? apw?
<apw> yeah i think that is there you are correct
<smb> It might be interesting to remove that pack file and force it to resample again and see what happens
<smb> (on reboot)
<apw> and removing that pack is enough to ensure a 'slow' boot
<apw> (good thought smb)
<ghostcube> oh i get it so it builds an "id package" with all found ids i it and uses them on second boot to not relocate the packages again ?
<ghostcube> is this somehow correct ?
<smb> ghostcube, no actually unrelated to udev. I samples which files are opened on boot
<ghostcube> ah ok :D
<smb> to place them into a map to read-ahead on the next boot
<apw> what it does do is significantly change the timing of boot
<apw> so if your cam worked on first boot after an update and not after it may be timing related
<apw> removing that file and rebooting would give you the 'other' timing pattern and 
<apw> would allow confirmation of that as cause
<ghostcube> ah ok so i should remove this pack later at my machine ?
<ghostcube> and then reboot
<smb> and then try your webcam, yep
<ghostcube> ok :)
<ghostcube> thx for all i will try later guys
<apw> Appiah, i've posted an updated kernel
<Kano> hi, when will be karmic based on 2.6.31.6 + released as security update
<Appiah> apw: i'll test and reply with a result
<Appiah> apw: kernel works great
<apw> Appiah, thanks
<Appiah> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/418933 updating there
<ubot3> Malone bug 418933 in linux "no internet connection (wifi+ethernet doesn't work)" [Low,Confirmed] 
<Appiah> make sure the fix is in the new update! :)
<Keybuk> apw: do you think anyone would mind a kernel patch to pass "quiet" to init as a command-line argument (along with whatever options the kernel didn't know about)
<apw> Keybuk, to allow userspace to follow the same levels as the kernel?
<Keybuk> yes
<apw> do we not expose the kernel log level in /proc or /sys ?
<apw> (as an alternative)
<Keybuk> not in a useful way
<apw> thats very useless
<apw> i thoought you could set it from there
<Keybuk> upstart is going to do special things for its arguments
<Keybuk> and it'd be nice if quiet could just be one of them
<Keybuk> so quiet & splash could be handled *with the same code*
<Keybuk> rather than having to MOUNT /PROC FIRST! :-/
<apw> well i have no fundamental objections
<apw> and i assume if its just quiet, then its a one line change to push it to inits args?
<Keybuk> yes
<apw> so it doesn't sound impossible to carry too
<Keybuk> ie. make it push any arg it doesn't know about *and quiet*
<apw> yep
<apw> we might get it into upstream if it was configurable in kconfig
<apw> why not spin the basic patch and let us look at it
<Keybuk> I shall do that
<apw> Keybuk, cool thanks
<apw> i can see justifying ... userspace might care if we are loud or not for a patch
<Keybuk> userspace might want to follow kernel loudness
<Keybuk> which is exactly what we do :p
<apw> the other option might be for a generic prefix to say we want something pushed through
<Keybuk> quiet kernel => quiet userspace
<Keybuk> load kernel => load userspace
<Keybuk> prefix wouldn't help upgrades though
<apw> so like >quiet means keep it regardless
<Keybuk> we're stuck with using quiet for hysterical raisins
<apw> yeah there is that
<apw> i guess they might say ... just use quiet Quiet
<Keybuk> exactly
<Keybuk> which is UGLY
<apw> quiet usquiet would be my choice but makes interacting with users harder
<GargFun1> high all; we're trying to track down a problem with the Via C3.  We have a problem where the sytem will hang after 10h38m with most kernels, but we have found that the problem does NOT happen with the Ubuntu kernel used on the installation media
<GargFun1> we are trying to find a kernel that we can build ourselves that works, so we built a kernel using the sources
<GargFun1> we got the sources using git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git and we expected the result to be the same as the standard ubuntu kernel
<GargFun1> but apparently it's not since those don't work...
<GargFun1> any idea how I can build a kernel identical to the one used on the install media?
<bjf> GarFun1, there are wiki pages that explain how to build our kernels, will get you a link or two
<GargFun1> We followed those directions, and don't get a kernel that acts the same as the one on the install media
<bjf> GarFun1, which directions did you follow? Did you build using debuild?
<GargFun1> https://help.ubuntu.com/community/Kernel/Compile was our starting point
<bjf> GarFun1, which version are you trying to build, latest karmic?
<GargFun1> yes
<GargFun1> latest karmic
<GargFun1> but every version of the kernel from 2.6.18 through .31 seems to have the problem
<GargFun1> we've tried quite a few
<GargFun1> the ones we've found to work are the ones on the install media
<bjf> GargFun1, what is "the problem"
<GargFun1> after 10h38m of uptime, the system hangs
<GargFun1> typing something wakes it up
<GargFun1> but our goal is headless systems
<GargFun1> it hangs hard, including stopping counting uptime
<GargFun1> (so if I wake it up an hour later, it doesn't think any time has passed)
<bjf> GargFun1, but it's alive enough for you to do an "uptime" ?
<GargFun1> what we do is we boot with a serial console and have a simple script that generates uptime; just a sec I'll type it in
<GargFun1> #!/usr/bin/perl
<GargFun1> $btime = $1 if `cat /proc/stat` =~ /btime (\d+)/;
<GargFun1> while(1) {
<GargFun1>         print "up ". (time-$btime) ." load ". `cat /proc/loadavg`;
<GargFun1>         sleep 1;
<GargFun1> }
<GargFun1> so every second it prints the uptime
<GargFun1> after 10247s (sometimes slightly more or less)
<GargFun1> it stops printing anything
<GargFun1> at the same time, it stops responding to pings
<GargFun1> same thing happens with nonserial console
<bjf> GargFun1, ok got it
<GargFun1> same thing happens with no modules loaded
<GargFun1> (of course, can't test pings then)
<bjf> GargFun1, you started off with a Karmic release kernel?
<bjf> GargFun1, have your tried one of our mainline kernel builds?
<GargFun1> HorsePunchKid did the actual building
<HorsePunchKid> (howdy)
<HorsePunchKid> we haven't tried one of the mainline builds. just the sources from the git repo (for karmic) built with the openwrt toolchain, then a couple of different kernels that i grabbed off the installation ISOs.
<HorsePunchKid> the next test we're going to run is with one of the pre-built kernels, probably from karmic.
<bjf> GargFun1, HorsePunchKid what is your hardware platform?
<HorsePunchKid> it's a Via C3-based motherboard... i can look up more specifics if it would be useful...
<bjf> HorsePunchKid, no, that's ok
<bjf> HorsePunchKid, isn't the openwrt toolchain a cross-compiler toolchain
<HorsePunchKid> yes.
<bjf> HorsePunchKid, or are you using that to get uClibc
<HorsePunchKid> that will be another test that i'll run, to just build the kernel outside of the openwrt buildroot.
<HorsePunchKid> i believe openwrt also builds uClibc, if that's what you're asking.
<GargFun1> I guess the question I was trying to track down an answer to is: are the kernels on the install media built differently than other kernels
<bjf> HorsePunchKid, I'm trying to understand why you are cross compiling since the Via C3 is an x86 clone
<bjf> GargFun1, they are built using debuild
<HorsePunchKid> fair question... just because that's how openwrt is set up, and it seemed like the path of least resistance. i figured it would be easier to track openwrt package updates and such if we constrained ourselves to their build system.
<bjf> HorsePunchKid, that could be but you've wandered quite a ways away from the way we build ubuntu, your using a completely different toolchain
<HorsePunchKid> true... desperate times call for desperate measures, i suppose :).
<bjf> HorsePunchKid, does this system currently have a head on it at all and have you tried to just install the regular Karmic release on it?
<bjf> HorsePunchKid, I understand that's more than what you want to end up with but gives us common ground to debug a kernel issue
<HorsePunchKid> no, but given that the system works fine with the kernel from the installation CD, i figured installing a complete system probably wouldn't tell us much more.
<GargFun1> bjf, my understanding of debuild is that it builds a package from source; that sounds like the answer to how the kernel packages are created
<HorsePunchKid> though i don't know how close the installation CD's kernel is to what is actually getting installed. hence, the next test will be to try out the kernel from the karmic package.
<bjf> HorsePunchKid, I'm assuming that kernel is a very different version from Karmic, which version is it?
<HorsePunchKid> they're both 2.6.31. i don't have the complete string handy. the server CD was something like 2.6.31-14, if i recall correctly.
<bjf> HorsePunchKid, ok
<bjf> HorsePunchKid, do you have the sources to that kernel and have you tried to build them and run that kernel?
<bjf> GargFun1, you can also use debuild to build your tree without producing a source package for example ....
<HorsePunchKid> no, i don't. not unless the karmic git repo is exactly the same as what got built for the server CD, which i'm getting the impression is not likely.
<micahg> does 2.6.31 not support software raid?
<HorsePunchKid> we should have results from the test with the karmic-package kernel in the next 12-16 hours.
<bjf> GargFun1, debuild -eCROSS_COMPILE=arm-none-linux-gnueabi- --prepend-path=/home/toolchains/arm-2009q1/bin -b -aarmel -us -uc  
<bjf> GargFun1, is how I've cross-compiled for ARM systems
<GargFun1> what would -e be for the install CD?
<bjf> GargFun1, it set's the environment variable "CROSS_COMPILE"
<ghostcube> smb: ping
<ghostcube> there was a kernel update 
<ghostcube> and i rebootet after now cam works
<ghostcube> iam going to reboot noe if the cam works after too
<GargFun1> bjf, I understand, but what CROSS_COMPILE string is used for building the install CD's kernels?
<smb> ghostcube, It should be repeatable whenever you remove the pack file I mentioned, not only on update
<GargFun1> I'm just trying to get as close to those kernels as I can =)
<bjf> GargFun1, no, I was just using that as an example of how I've used debuild to build for an ARM target
<GargFun1> ah, I see
<bjf> GargFun1, you could do something similar for a x86 build
<bjf> GargFun1, if you wanted to do that
<GargFun1> bjf, I guess I'll abandon that tack and we can see what happens with HorsePunchKid's tests using the mainline kernel and the mainline kernel built with the ubuntu toolchain
<GargFun1> by mainline, I mean karmic release
<bjf> GargFun1, HorsePunchKid, sorry if I wasn't able to help
<GargFun1> bjf, no it's great to have gotten feedback
<GargFun1> we have some new things to try, and we'll try them =)
<HorsePunchKid> yeah, definitely. thanks for talking it over with us. i'll get those tests set up and report back tomorrow.
<apw> HorsePunchKid, GargFun1, the kernels on the CD are taken from the archive same as the ones installed when you do an update
<apw> built in clean chroots by the buildd's
<HorsePunchKid> okay, that's useful to know.
<HorsePunchKid> so i'm trying to follow the directions in KernelCompile on the ubuntu help wiki. i think i don't know enough about apt to do what i need to do. i'm on an jaunty system, but i need the karmic linux-image-* sources. how do i obtain those?
<apw> i always build (when building locally) using the sources in our git trees
<apw> you can clone those, and then 'fakeroot debian/rules clean'
<apw> the result then is something which you can compile with debuild -b in an appropriate chroot
<HorsePunchKid> hm, okay. i've already got clone of the karmic repo which i was building with openwrt. i'll try just building that with debuild instead.
<apw> you must clean it first, else it won't have all the control files you need
<HorsePunchKid> *nod* will do.
<HorsePunchKid> i'm not so familiar with git... how can i get a list of tags or releases, or how can i peg my clone at the latest release, rather than the (presumably not as stable) head?
<ghostcube> smb: ureadhead crashed at boot 
<ghostcube> but the cam still works here
<ghostcube> woha yeah i can see my damn ugly face now again
<ghostcube> :D
<ghostcube> i will test it a while and look if it somehow stops after i do anything special
<smb> ghostcube, ureadahead supposed should not crash. But that might delay things just enough. So I'd expect it to be flakey
<micahg> does 2.6.31 not support software raid?
<HorsePunchKid> apw, or anyone else, could you give me an idea of how to use debuild to build the kernel package, now that i've got the karmic kernel sources cloned? it's not mentioned in the KernelCompile wiki page, and the -b flag isn't mentioned in the man page or help.
<smb> In the top level dir
<smb> fakeroot debian/rules clean
<smb> debuild -b -uc -us
<HorsePunchKid> does -b just indicate to only build binary packages or something like that?
<smb> yep
<HorsePunchKid> cool, thanks much.
<smb> -uc -us does not sign them
<micahg> smb: do you know anything about software raid and 2.66.3
<micahg> 2.6.31?
<smb> micahg, I have no md running on 2.6.31 atm just a dm strip, so I cannot say much about it specifically. It should be supported
<micahg> thanks, I'll check back with the -server team then
<Darxus> CD P
#ubuntu-kernel 2009-11-11
<EruditeHermit> hello, is it possible to build a 32bit kernel on a 64bit machine?
<maco> EruditeHermit: of course
<maco> (but not the other way around)
<angel_> is it possiable the kernel swap the page that mmapped from file??
<EruditeHermit> hello, is it possible to build a 32bit kernel on 64bit karmic?
<AceLan> EruditeHermit: yes, use chroot
<AceLan> EruditeHermit: https://wiki.ubuntu.com/KernelTeam/BuildKernelWithChroot
<EruditeHermit> AceLan, do you have the script that is mentioned on that page? The link to it is broken
<AceLan> EruditeHermit: I just fixed the link, please try again
<EruditeHermit> AceLan, still getting 404
<AceLan> EruditeHermit: I can download it, maybe your browser need to reload the page :p
<EruditeHermit> ah it works now
<EruditeHermit> AceLan, does the script make any permanent changes?
<EruditeHermit> AceLan, can I just rm -rf /var/chroot and nothing else will have changed?
<EruditeHermit> AceLan, also, the page is a little unclear. Can I run the script and just use the chroot immediately or do I have to perform the steps in the sections below the initial script section
<AceLan> EruditeHermit: the script will do most of the work describe in the following section below.
<AceLan> EruditeHermit: The script will modify /etc/fstab, you have to take care of thar file, if you remove the chroot directory
<EruditeHermit> AceLan, what does it to to fstab?
<EruditeHermit> AceLan, as a request, if you made the script have an uninstall option, that would be really cool
<AceLan> EruditeHermit: haha
<AceLan> EruditeHermit: It will modify the fstab, so that fstab will mount the filesystem that use by the chroot
<AceLan> EruditeHermit: uninstall is much more difficult than install, I'll think about that, thanks for the suggestion :)
<EruditeHermit> just make a copy of fstab as a backup
<EruditeHermit> remove the /var/chroot/hardy-lpia or whatever
<EruditeHermit> and then copy the backed up fstab back to /etc/fstab once done
<AceLan> EruditeHermit: haha, not so easy, what if you have more than one chroot?
<EruditeHermit> so make it an option to delete each chroot individually
<EruditeHermit> and make an option to delete all
<EruditeHermit> the delete all will replace the fstab
<EruditeHermit> the individual chroot delete will just rm -rf /var/chroot/specific-chroot
<AceLan> EruditeHermit: looks like you're very interesting in this, would you like to write one :)
<EruditeHermit> AceLan, I am not skilled enough =p
<EruditeHermit> AceLan, it would be nice if you knew awk/sed etc to edit fstab to remove each relevant entry
<EruditeHermit> AceLan, I just dislike having cruft left behind on my machine
<EruditeHermit> one thing I love about most distributions is that they keep track of files
<EruditeHermit> other OSes get bloated with random stray files everywhere
<AceLan> EruditeHermit: you have to track the chroot related files by yourself, I don't have to much time to rewrite the script now, but I'll do it once I have time. :p
<EruditeHermit> AceLan, ok
<EruditeHermit> AceLan, but you assure me that the only related files are in /var/chroot and /etc/fstab
<AceLan> EruditeHermit: and /etc/schroot/schroot.conf, /etc/dchroot.conf :p
<EruditeHermit> AceLan, thanks for your help today
<EruditeHermit> I may ask you more questions about it later
<EruditeHermit> =)
<EruditeHermit> its a cool script
<AceLan> EruditeHermit: :)
<^arky^> About bug 480665 : what other information should I provide ? 
<ubot3> Malone bug 480665 in linux "rejecting I/O to offline device" [Undecided,New] https://launchpad.net/bugs/480665
<Kano> apw: hi, did you see 2.6.31.6?
<apw> Kano, yep, its 100 patches, it'll take some reading
<dtchen_> ogasawara: are there debs of git://kernel.ubuntu.com/ogasawara/ubuntu-karmic stable-2.6.31.6 available?
<rtg> dtchen_, she's likely not working today as its a holiday (unless you've already talked to her)
<dtchen_> rtg: right. that's fine, no pressing matters. (and it's the only reason I'm online at this time -- holiday)
<ogasawara> dtchen_: no debs yet, am coordinating with smb to get them pushed to his PPA for pre-proposed testing
<dtchen_> ogasawara: thanks. (also, thanks for the update WRT jacksense)
#ubuntu-kernel 2009-11-12
<slytherin> Can anyone please explain how the default modules to be loaded are decided for a machine? and how are they configured at time of installation?
<AbdulHaleem> Hello every one
<_ruben> now if only i could figure out which is the most accurate and up-to-date documentation on how to roll your own kernels
<Kano> hi, how about some backports from mainline like
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6ef8836c1ff5199abd40cfba162052bc7e8af00
<slytherin> _ruben: What do you mean by roll out?
<_ruben> roll, not roll out, roll as in: compile my own .. but i did find some blog post detailing various steps .. if only my (windows) hadnt crashed i would know if the compile was succesful :p
<slytherin> _ruben: This is what has worked for me in the past - http://www.howtoforge.com/kernel_compilation_ubuntu
<slytherin> _ruben: By the way, unless there is custom configuration you want to do you can use mainline kernel builds form here - http://kernel.ubuntu.com/~kernel-ppa/mainline
<_ruben> that's the old way of doing things .. i followed this one (more or less) : http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/
<_ruben> its some (performance) patches for scst i include
<apw> Kano, if someone is hitting that issue and files a bug we might do it, or if it gets into .y stable we'll get it for free
<gnarl> actually rather, if something like that should go in, it has to go to stable
<ogasawara> dtchen_: https://edge.launchpad.net/~stefan-bader-canonical/+archive/karmic/+packages  2.6.31-16.51~pre2 has the 2.6.31.6 patch set incorporated.  just need to wait for it to finish building in the PPA.
<gnarl> dtchen_, should be any second
<akheron> I upgraded from Jaunty to Karmic and the machine won't boot with the 2.6.31-14 kernel, the Jaunty kernel 2.6.28-16 still works. I'm not sure how to file a bug for this because if I use "ubuntu-bug linux" the report will contain the info of the wrong kernel
<akheron> the machine just hangs, and this seems to be related to keyboard, because pressing keys makes the booting proceed in small steps
<akheron> somehow I've managed to get into X a few times (once with the live cd), and the keybord didn't work
<akheron> mainline 2.6.31.4 seems to work (tried a few times), but mainline 2.6.32rc6 doesn't
<tvst> Hi, I'm having some trouble reading data from USB-serial FTDI devices that used to work on 9.04. I was wondering if anyone knows about any change in the kernel/modules that could have caused this...
<tvst> It also appears that a vanilla kernel could work, according to this bug report 
<tvst> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/474180
<ubot3> Malone bug 474180 in linux "[karmic] usbserial regression with MessPC Environment Sensors" [Undecided,New] 
<tvst> ^ i just found that :) and posted there.
<tvst> is there any additional debugging info i should add to that report?
<tvst> (oh, apparently i was replying to a bot. nevermind :) )
<dtchen_> ogasawara: great, thank you
<amitk> dinh: pushed some hacks to get serial port working
<cj> hey all
<cj> looking for a kernel for my xen hvm karmic...
<cj> https://wiki.ubuntu.com/KernelTeam/EC2 <- suggests that such a kernel may exist
#ubuntu-kernel 2009-11-13
<jk-> cj: linux-image-virtual ?
<jk-> ooh, maybe linux-image-xen
<cj> I'll try linux-image-virtual... -xen is paravirt, IIRC
<jk-> 'k
<cj> ah.  mdz pointed me to linux-image-2.6.31-302-ec2
<dinh> amitk: still there?
<jjohansen> cj: actually the EC2 xen kernel isn't paravirt, it is a xen 3.0.2 compatible kernel for EC2
<mozmck> I'm making a custom LiveCD with a custom kernel, and I need to know if squashfs support will work as a module or does it need to be compiled in?
<ikepanhc> mozmck: if your root filesystem is squashfs, build-in will be a better idea, otherwise it shall be in initramfs
<mozmck> Ok.  I built my custom kernel using the ubuntu config from 2.6.31, and made a few changes.  I noticed that squashfs is a module there.
<mozmck> I'll probably rebuild the kernel with it built-in.
<ikepanhc> :-) 
<billybigrigger> hey all anyone alive?
<billybigrigger> anyone here have a working gspca webcam with 2.6.31?
<billybigrigger> if not, does it work with 2.6.32?
<billybigrigger> was thinking about running 2.6.32 on my karmic install as my vx1000 webcam won't work, and hasn't all throughout the .31 development
<Kano> apw: it does not seem to be a full merge of 2.6.31.6
<Kano> as it conflicts when you try a pull
<falxx> Hi, I got a error this morning, but I'm not quite sure where to submit it, or if this even is the right place
<falxx> dmesg looks like this: http://lart.no/lpaste/gw4uk/
<apw> Kano, we didn't merge 2.6.31.6 we took the majority of it.  a couple of patches were deemed to be a regression risk and dropped
<apw> falxx, that looks like a kernel issue.  it looks like a kernel issue which we just took a fix for and is being merged at the moment
<apw> falxx, probabally this bug: http://bugs.launchpad.net/bugs/480144
<ubot3> Malone bug 480144 in linux "[Karmic] Update to 2.6.31.6 Stable Kernel" [Medium,In progress] 
<apw> oh ... thats a tracking bug
<apw>     fsnotify: do not set group for a mark before it is on the i_list
<apw> that fix anyhow
<apw> if you could file a bug with ubuntu-bug linux and let me know the bug number we can get it annotated
<falxx> ubuntu-bug linux? as in https://bugs.launchpad.net/ubuntu/+source/linux/+filebug ?
<akheron> run "ubuntu-but linux" in the command line
<akheron> it collects information on your system and lets you submit it to launchpad
<ghostcube> hi
<falxx> greats, launchpad crashed
<falxx> "OOPS-1413M1454"
<ubot3> https://devpad.canonical.com/~jamesh/oops.cgi/1413M1454
<falxx> apw: launchpad bug-id 482089
<apw> bug 482089
<ubot3> Malone bug 482089 in linux "Crash that freezes input devices but leaves system living" [Undecided,New] https://launchpad.net/bugs/482089
<apw> falxx, can we get the oops added there
<apw> falxx, ahh have it from your pastebin
<falxx> yeah, it's also present in the top of "WifiSyslog.txt"
<falxx> (although I don't know why it is named wifi)
<apw> how stupid of it... thanks
<apw> ok _now_ i've managed to find the bug i thought existed, and i've dup'd yours against it
<apw> the extra infor is handy for that one
<apw> i will hastle the sru maintainer to add that one
<falxx> allright, good to be of assistance
<apw> info is always useful.  we should be pushing that fix to -proposed perhaps at the end of next week or shortly after
<pgraner> dtchen_: question about audio got a sec?
<maco> hehe
<pgraner> maco: you find that funny?
<maco> pgraner: knowing that everyone pokes him, specifically?
<maco> (also, i think he's at work)
<StevenK> Is it worth while reporting as a LP bug that my Studio XPS 13 consistently oopses when resume?
<rtg> StevenK, seems like a reasonable thing to me
<ogasawara> StevenK: let me know the bug #
<fl0pser> Hello. Where can I find kernel headers for 2.6.18? Please help! 
<StevenK> ogasawara: LP didn't love me when I tried to submit it
<ogasawara> StevenK: stupid LP.  don't suppose what you're seeing is a WARNING about suspend_test_finish?
<StevenK> [31316.883361] WARNING: at /build/buildd/linux-2.6.31/kernel/power/suspend_test.c:52 suspend_test_finish+0x80/0x90()
<StevenK> So yes, I am
<ogasawara> StevenK: you're likely seeing a dup of bug 464552 (which we have a patch making it's way through -proposed).  if you look through your dmesg after resume, look for something like "PM: resume devices took 6.220 seconds"
<ubot3> Malone bug 464552 in linux "suspend_test_finish warning triggers too easily, increase timeout to match mainline times" [Low,Fix committed] https://launchpad.net/bugs/464552
<ogasawara> StevenK: note that it
<StevenK> ogasawara: Ah, yeah, that' be it
<StevenK> [31316.883354] PM: resume devices took 8.192 seconds
<ogasawara> StevenK: 's just a warning so should not be cause any other ill effects
<StevenK> ogasawara: Aside from apport yelling whenever I resume ...
<ogasawara> StevenK: right.  the patch we have increases the barrier to 10sec
<sbeattie> StevenK: hrm, apport/kerneloops should have stopped notifying you about that.
<ogasawara> that's assuming he updated
<ghostcube> hehe my black picture bug is back :D
<ghostcube> after the x reboot
<ghostcube> and nothing done other than before the days
<ghostcube> :)
<StevenK> ogasawara: I'm naughty since I don't have -proposed installed
<ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935   keeps staying :)
<ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Triaged] 
<Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286?comments=all
<ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] 
<Q-FUNK> would anybody know what happened to smb?
<Q-FUNK> I had asked him if he could attach his diff between vanilla and this, so that others could help debug this.
<Q-FUNK> right now, someone from the OLPC project would be willing to help, but without smb's patch, there's no way to see what he tried.
<dandel> i'm working on finishing bug 338701 however, what's left is to finish getting the quirks figured out.
<ubot3> Malone bug 338701 in linux "acpi_irq is not set properly." [Medium,In progress] https://launchpad.net/bugs/338701
<maco> fl0pser: no ubuntu version ships with 2.6.18 so you will find no such header package in our repositories. you're down to getting the entire kernel source from kernel.org
<mjg59> deshantm: I'm not quite sure what you mean, but adding anything to the OSI table isn't the right solution
<mjg59> Oops
<mjg59> dandel: ^
<mjg59> deshantm: Sorry, not you
<dandel> mjg59, it's part of the solution.
<mjg59> dandel: No, it's not
<dandel> without the Linux entry enabled, the irq is completely ignored.
<mjg59> Then that's a bug that needs fixing
<dandel> and with that, it'll automatically fail suspend every time.
<dandel> i wish i could get it fixed ><;
<billybigrigger> hey anyone here?
<mjg59> But adding something to the Linux OSI table is not fixing a bug
<dandel> it's fixing the irq.
<dandel> there is some other quirk.
<dandel> i'm currently trying to fix that quirk.
<dandel> because with the quirk as it stands now, it'll suspend, and then upon resume, the video does not return.
<larrycorywell> exit
<dandel> http://bugzilla.kernel.org/show_bug.cgi?id=12873 (Kernel Bugzilla entry)
<dandel> I'm testing on 9.04 with latest git kernel.
<ubot3> bugzilla.kernel.org bug 12873 in Config-Interrupts "irq 9: nobody cared - 2.6.26 regression - Toshiba Satellite P305D-S8828" [Normal,Rejected: insufficient_data] 
<dandel> as it stands. using pm-suspend --quirk-dpms-on --quirk-s3-bios causes the video to return, but it then crashes.
<dtchen_> pgraner: pong (yes, I was at work)
#ubuntu-kernel 2009-11-14
<StevenK> 444444444
<virtuald> stevenk: is it caturday?
<StevenK> virtuald: No, the wireless connection in this hotel is making me a sad panda
<dtchen_> I suppose we can look forward to wonderful connectivity for the sessions?
<maco> hahahahaha
<dtchen_> s/we/others/ . I won't be online for the sessions anyhow.
<maco> you wont?
<dtchen_> no.
<StevenK> dtchen_: The wireless downstairs is fine, it's the hotel wireless that's (I feel) sub-par
<dtchen_> hotel wireless almost always blows
<StevenK> Yeah :-/
<StevenK> dtchen_: But I've had no problems with the Ubuntu wireless network set up by James
<dtchen_> I don't think we can count on competence for hotel wireless ;-)
<virtuald> when's uds and will there be live streams?
<maco> virtuald: starts monday and yes
<virtuald> nice, where would the streams be?
<maco> !uds
<ubot3> The Ubuntu Developer Summit is being held November 16th-20th in Dallas, Texas, USA. See https://wiki.ubuntu.com/UDS for more information.
<maco> somewhere near that wiki page should tell you
<virtuald> thank you
<openeye> good day everyone, i have a question. Would it be possible for me to remove the 65k restriction on connections from the tcp/ip stack?
<openeye> so that the port isnt limited on the 16bit order
<openeye> ?
#ubuntu-kernel 2009-11-15
<dandel_> hmm... i found a bug with the ext3 subsystem used for the virtual partition install of ubuntu 9.04 :/ (when using kernel 2.6.32-rc7)
<dtchen_> reported upstream?
<dandel> somewhat.
<dandel> i'm trying to reopen a bug that got closed ><;
<dandel> i haft to figure out how to over ethernet send the debug ><; (the crash happens upon resume)
<dandel> 2.6.28 (which is used in 9.04 by default does not display this bug, but the system still crashes shortly afterwards)
 * dandel checks 2.6.32-rc6 for bug.
<dandel> that also displays the bug (go figure)
<dtchen_> and rc8?
<dtchen_> rc7*
<dandel> i'm testing 2.6.31 ><;
<dandel> 2.6.31 also does the crash on resume 0o
<dandel> i know it's some sort of module change... the crash does not occur when i suspend with testing via s2ram on init=/bin/bash
<dandel> it'd be excellent if i could get the kernel dmesg stuff to go to my tower (the laptop lacks serial ports tho)
<maco> is one of your USB ports a debug port?
<dandel> no clue.
<dandel> however, the kernel did not panic, so the log is scrollable (although it is a little short)
<dandel> how can i make the usb port a debug port?
<maco> http://www.coreboot.org/EHCI_Debug_Port
<dandel> Yes, the usb does support debug 0o'
<maco> this time, im bookmarking that link. i had to search through last december's chatlogs to find it :P
<dandel> so how do i run the device as a debug port then?
<dandel> (Keep in mind that i have 2 EHCI controllers, and both of them support debug)
 * dandel makes note that both the laptop and tower have debug port capability on the usb.
<maco> ive never done it myself. the $83 pricetag on that hardware was a bit steep for me
<dandel> ><;
<dandel> any idea on how to get the debug to go over ethernet?
<maco> spose you could ssh in before it breaks...
<dandel> can't
<maco> right....suspend/resume
<maco> i wasnt thinking
<dandel> hmm... my only option now is to start gutting module trees with the modprobe blacklisting.
<dandel> ok... got the crash down to about 15 modules which i can't unload.
<hagabaka> why doesn't the kernel ppa work as a repository now?
<asabil> hi all
<teabag> hello all, I am getting this error during the makefile process
<teabag> http://paste.ubuntu.com/319311/
<teabag> can anyone plz tell me what is wrong and how to fix it ?
<teabag> ah nevermind
<teabag> go it
<_Narc_> Hello, Kernel Wizards. I got a little something to ask you. I had/I'm having/ a hard time figuring out if a bug is coming form the kernel or from something else. It's network related, especially to the r8169 module... Anyone I could explain to ? Thanks
<dtchen_> _Narc_: please don't ask to ask.
<dtchen_> _Narc_: and, it's better if you have a bug report reference.
<_Narc_> dtchen_: Sorry. The problem is I don't have a bug report yet because I waited to have an advise here to submit it under the right package.
<BenC> _Narc_: you can file a bug report against just ubuntu and specify the package later
<BenC> _Narc_: since you know it is in ubuntu, you know you will have to file a bug report anyway, so best to do it from the start and narrow down the exact package after it's been triaged a bit
<_Narc_> BenC: Good idea, I didn't think about that. I came here to ask because someone on ubuntu-bugs told me it was weird and to ask to someone who knows the kernel better. But I'll do that, thanks.
<BenC> _Narc_: you can still explain here if you can provide enough detail
<_Narc_> BenC: Yes, I even have too much of them. Too make a long story short, it's been months that I experience network hangs/ deconnexions when the network was under heavy load, using bittorrent (Miro) for example. I tested with a different router, changed nothing. Then I looked in syslog and found this : http://paste.ubuntu.com/318620/ . 
<BenC> _Narc_: not so sure that's a bug at all...
<BenC> _Narc_: if anything, it is kernel, but just saying that the driver may be acting as expected
<_Narc_> With different people on ubuntu-bugs, we thought it was a r8169 issue. But now I discovered that changing the default port in Miro stops it. So, I need your help determining if it's Miro who's talking nonsense to the kernel or the kernel who can't handle it.
<_Narc_> Oh really
<_Narc_> Two people on ubuntu-bugs told me it was an Oops
<BenC> it's not an oops at all
<_Narc_> Oh
<BenC> it's a WARN_ON() in the driver
<BenC> oops == crash, WARN_ON() == driver got something unexpected from the hardware and tried to handle it
<BenC> likely in this case, that means resetting the device
<_Narc_> Ok, it means it's just telling that something is wrong, but acting as expected ?
<_Narc_> Ok
<BenC> that's an initial guess
<_Narc_> It's really something already :)
<_Narc_> Do you know if the SYN flood messages just at the beginning could trigger this ?
<_Narc_> Or is it unrelated 
<_Narc_> Because I had a lot of them. 
<BenC> I believe it is directly related
<BenC> need to find out why the kernel thinks it is getting syn-flooded
<_Narc_> Oh. That's interesting, because that's what I thought, and I unabled the syn flood cookies, and it still hanged. But changing Miro's default port from 8500 to 51413 solves it. So, I wondered why one and not the other...
<_Narc_> I say Miro specifically because it's the only app who's doing this. On this port. And the syslog message I showed you does not appear at each network hang. 
<_Narc_> So, hardware, kernel, miro... I'm not good enough to figure out. Ask me if you need any other info.
<BenC> _Narc_: do not disable syn cookies, that causes more problems
<BenC> _Narc_: quite possible you need to lower some limits in Miro so that it doesn't cause flooding on your connecting
<_Narc_> Yes, that's what I did. But the strange thing is that I only get the syn warnings when miro's port range are 8500-8600. So, it's not a kernel issue you say, because it's acting brave and try to handle miro's/my hardware crappy packets, right ? 
<BenC> _Narc_: I believe so
<_Narc_> Ok, thank you very much then. I'm starting to understand this more. It's probably a Miro bug then. Because my hardware is not exotic.
#ubuntu-kernel 2010-11-15
<jk-> m4t: shouldn't do
<sangeeth> I heard the right step to hack the linux kernel is to begin with Linux 0.01 kernel... I could get a hand on the source code, but couldn't get any guide... PLEASE HELP ME...
<rlpb> Can anyone help with debugging acpi? I'm running acpiexec but not getting the same battery status as reported in /proc/acpi/battery/... . How does acpiexec emulate actual hardware?
<kusanagi> hi, i am running lucid. How can i install latest kernel? or at least 2.16.36?
<RAOF> The lucid-maverick-backport kernel is in the archives now I think.  Either that, or it's in the kernel team PPA.
<kusanagi> RAOF, I have backports activated in lucid, but nothing proposed. Do i have to add the ppa to get it proposed?
<RAOF> Hm, maybe.
<RAOF> I can't see it in the lucid archives.
<kusanagi> mm ok i have added the ppa
<kusanagi> how do i install the kernel now?
<kusanagi> it is not proposed if i do an update && upgrade
<RAOF> It looks like you'd want to install the linux-meta-lts-backport-natty package
<kusanagi> cant find that package :S
<kusanagi> whats the difference between meta and not meta?
<RAOF> Dunno, sorry.
<kusanagi> ok, it found it without meta
<kusanagi> thanks RAOF i think i can take it from here on ;D
<kusanagi> mmm it seems there is only headers and source packages :S
<kusanagi> :(
<apw> man its quiet today ...
<smb> Now you broke it. :)
 * apw prepares the flood gates ...
<apw> smb, did you sort out that bundle?  it seems you can treat filename as a remote, git ls-remote and git fetch <file> <branch>:<branch2> style things work on it
<smb> apw, No, could not really be bothered
<apw> anyone remember who it was who was doing cross-compilation and finding x86 binaries in the header files ?
<apw> and indeed remember the bug number?
 * apw finds a multi-iso stick in his kit ... damn these are good
<lool> Someone knows kettgordon at gmail.com?
<lool> alternatively, is there an admin for the Ubuntu kernel-team mailing-list around?  :-)
<lool> everyone posting to kernel-team@ gets a message to confirm emails going to this subscriber
<apw> lool, what do you need ?
<apw> oh thats a lot crap
<lool> apw: I think we should unsubscribe this guy and write him to not subscribe to mailing-list with this address
<apw> heh welll if i write to him and it asks me to confirm, i won't bother, so they won't find out
<lool> (He's probably subscribed with an @boxbe.com address, but the autoreplier mentions the kettgordon at gmail.com as a contract address)
<lool> apw: Fair enough  :-)  I suppose the kettgordon gmail.com one isn't filtered though
<apw> lool can you fwd me the autoreply ??  i don't seem to get them
<lool> apw: done
<lool> apw: Maybe he whitelisted @ubuntu.com, @canonical.com, but not @linaro.org (or anyone possibly posting to the list)
<apw> lool, maybe so... seems he needs a poke for sure
<apw> lool, ok i have sent a whining email to him on your behalf
<lool> apw: Thanks;
<lool> I could have done the latter part myself I realize, I went straight to listmasters because I don't want other subscribers to be annoyed :)
<apw> yep, well you also wouldn't know whether we were all being spammed which we don't, and it sounds more appropriate coming from a list person, so it seems right
<kraut> moin
<doko> apw, tgardner: any idea about  bug #673073 ?
<ubot2> Launchpad bug 673073 in linux (Ubuntu) (and 1 other project) "<net/if.h> and <linux/if.h> are incompatible (affects: 3) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/673073
<tgardner> doko, looks like an upstream issue. we'll work on it.
<doko> thanks!
<apw> tgardner, i wonder if its a simple case of _kernel_ round that include
<tgardner> apw, doko, I think this was introduced by eglibc. include/linux/if.h has not changed significantly for over a year
<apw> tgardner, i think the file that has changed is rtnetlink.h
<apw> which is triggering an include of if.h indirectly now
<apw> commit 24824a09e35402b8d58dcc5be803a5ad3937bdba
<apw> Author: Eric Dumazet <eric.dumazet@gmail.com>
<apw> Date:   Sat Oct 2 06:11:55 2010 +0000
<apw>     net: dynamic ingress_queue allocation
<tgardner> apw, ah, hadn't drilled down to that yet
<apw> that one brought a new include of netdevice.h to that header
<doko> tgardner: are you sure? eglibc isn't yet updated ...
<tgardner> doko, no, I'm not sure. apw pointed out changes in rtnetlink which are the likely culprit
<apw> doko, do you have some code which triggers this error on compilation, somethign short?
<tgardner> apw, the bug report does. we could just hack the local chroot copy of rtnrtlink to see if its a workaround
<apw> tgardner, yeah going to try tha
<doko> apw: in the bug report, bug description
<apw> tgardner, ok it seems that putting that include in an __KERNEL__ at least lets the example compile
<apw> not sure if that would be enough for elibc ....
<apw> doko, if i spin a test kernel with that change can you test it against your eglibc build ?
<tgardner> apw, you should probably send a note to Duzamet and Miller.
<doko> apw: sure
<apw> tgardner, for sure
<lag> diwic: Where is your 'self help' Wiki page?
<diwic> lag, what do you need help with?
<lag> My 'friend' has audio issues
<lag> Didn't you have some scripts that was used for debugging?
<diwic> lag, https://wiki.ubuntu.com/DebuggingSoundProblems ?
<diwic> although I don't really recommend everything there, some of it is outdated
<lag> What was the script I ran, which churned out lots of debug?
<diwic> https://wiki.ubuntu.com/Audio/AlsaInfo
<lag> I think that's it
<lag> Is that still in date?
<diwic> yes
<lag> Great, thanks
<apw> doko, could you see if the versions of linux-libc-dev fix your issue: http://people.canonical.com/~apw/rtnetlink-netdevice-include-natty/
<apw> (i think they should)
<beaver74> hey
<beaver74> i have only a small question, is it possible running the AMD SB850 SATA controller in AHCI mode with 2.6.35 kernel?
<doko> apw: will do, my remote machine is currently not reachable ... will update the bug report
<apw> doko, i take it this is a blocker on you
<apw> tgardner, i've copied you on the patch i've send upstream for this one
<tgardner> apw, ack
<tgardner> apw, we should just commit that for natty for now regardless of whether upstream takes it.
<bjf> tgardner, apw, http://ireport.cnn.com/docs/DOC-518781?hpt=C2   
<tgardner> too weird...
<kamal> bjf, sconklin: guess that ^^ is the same as we saw the kids playing in Cambridge then?  still seems to me that the broomsticks are superfluous here.  ;-)
<bjf> kamal, ack, tgardner and apw and I saw another group "flying" around boston common on Sat.
<kamal> guess they were gearing up for the 'big match' ;-)
<doko> apw: yes, the patch works
<smb> apw, ogasawara Could you have a quick look at https://wiki.ubuntu.com/Kernel/Dev/KernelDriverDeviations to see whether my "reason"s sounds reasonable to you as well?
<ogasawara> smb: sure
<ogasawara> smb: looks fine to me
<smb> ogasawara, ok, cheers. then we can tick that off the list
<ogasawara> sconklin: just fyi re: bug 672964.  determined to not be a kernel issue and is getting resolved via udev.
<ubot2> Launchpad bug 672964 in udev (Ubuntu Maverick) (and 2 other projects) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 732)" [High,Fix committed] https://launchpad.net/bugs/672964
<sconklin> ogasawara: sweet, a nice first bit of news for the day
<smb> sconklin, Then I could add that I still got network when updating on an acer aspire one, so the other report is probably something special as well
<sconklin> smb: great! Should I log off now before the law of averages catches up?
<bjf> sconklin, where are we "in the process" right now?
<smb> sconklin, There is always something broken somewhere. Trying to escape is futile :)
<sconklin> bjf: Today is the day we revert all unverified fixes. We'll need to actually look at each bug first, of course. I don't think we have a good tool yet to remove the buglinks from reverted patches, so we'll probably have to manually edit the changelogs after insertchanges. Sound right to you?
<smb> sconklin, Doh! And the OS installed Maverick now. So much for reproducing...
<smb> Eh no, it was another guy on the bug 
<bjf> sconklin, yes, sounds right, have you started
<sconklin> bjf: no, I just sat down. Haven't even looked at the status yet
<ogasawara> sconklin: let us know if you want help.  I'm also fixing up some build failures for the CVE's at the moment and will move on to some quick smoke testing and regression tests after that.  will send you, bjf, and smb an email with results.
<sconklin> ogasawara: thanks. I think it makes sense for bjf and I to each take a release - Maverick and Lucid are the ones to be done. What you're doing is great. I'll write some boilerplate for the bugs first, so we have consistent text.
<mildoe> hi
<sconklin> The number of verified fixes in lucid is disappointing
<mildoe> what is the major difference between RHEL and the ubuntu kernel?
<mildoe> similar?
<ogasawara> mildoe: depends which version of RHEL and Ubuntu you're referring to.  and even then, I'm not sure who on this channel follows the RHEL kernel closely enough to give you a good comparison.
<mildoe> rather arent most distro kernels the same?
<mildoe> just minor differences here and there for services and such
<jjohansen1> mildoe: yes and no, they all derive from upstream, but will include some different sauce patches and configuration differences
<bjf> sconklin, i'm reviewing the "verification-needed" bugs for maverick
<apw> mildoe, RHEL is aimed at very long term stability, and therefore is most comparible with Lucid (our LTS release), otherwise our normal releases are more like Fedora releases, aimed at the latest versions of everything
<sconklin> bjf: then I'll take lucid
<mildoe> ah
<mildoe> so rhel and ubuntu is almost similar in most cases?
<mildoe> ok thats what i thought
<apw> mildoe, in a very simplistic sense yes
<sconklin> ogasawara, bjf: Hmm, we haven't exactly defined the steps to take to have a fix reconsidered. How about this text in the wiki:
<sconklin> When fixes are reverted due to lack of verification, they may be proposed for reconsideration by performing the following:
<sconklin>  * update the bug with a firm commitment to verify the fix during the next stable kernel release cycle (usually this will begin one week after the fix is reverted).
<sconklin>  * Send a request to the Ubuntu Kernel mailing list request reconsideration of the fix. Include the bug number, and if possible, reply to the original SRU request that was made for the fix.
<bjf> i thought we were going to just reapply then for the next cycle?
<sconklin> bjf: not without some commitment to test
<bjf> we talked about many options and i'm not exactly sure what we are doing at this point
<sconklin> that was my memory
<sconklin> Originally we were going to close wontfix, and require a whole new SRU request, but we changed to just incomplete, and now it's unclear 
<sconklin> We can change what doesn't work - but for this cycle, there are bugs that have not gotten any response from multiple requests to test, so I have no faith that we won't be in the same position next week as we are now if we simply reapply them
<ogasawara> sconklin: do we really need them/us to send an email to the Ubuntu kernel team mailing list?  I suspect most users are not subscribed and it'll just add noise to the list.
<tgardner> sconklin, regardless if they send an email they at least need to update the LP bug with some commitments
<ogasawara> sconklin: I'd just be fine with the first bullet point and then maybe tagging the bug with kernel-patch-reapply or something
<sconklin> ogasawara: maybe your work flow is different, but if they simply reply to the bug, it'll get lost in noise for me. It won't be in the pending SRU tracking any more, and we have to way to track this class of bugs now
<ogasawara> sconklin: indeed, hence the need for the tag
<sconklin> ogasawara: yeah, how about this:
<bjf> ogasawara, tgardner i'm with sconklin (as far as I can tell) how do we know which bugs to add without email to the list?
<sconklin> when we revert we tag with stable-reverted, and when the commitment to test is added, they tag with stable-reapply
<ogasawara> sconklin: I like that
<apw> asking them to remove tags has generally been our way
<apw> as they are less likley to spell the tag wrong that way
<sconklin> it would be up to the edn user to add tags. Can anyone edit tags, or does it require special privs?
<sconklin> end user
<ogasawara> sconklin: unfortunately anyone can add/remove tags
<sconklin> I've assumed all along that anyone could do it
<bjf> sconklin, it's your call but I think doing it via tags is going to be a mess
<apw> is not the current process tag driven though, with needs-verification etc ?
<sconklin> bjf: what's your alternative? email to the list?
<ogasawara> bjf: I think having to track multiple emails would be just as messy
<bjf> sconklin, yes, email to the list just like any other patch request
<bjf> ogasawara, so we have to continuously scan bugs for the right "stable-reapply" tag? yes it can be done but it's yet another process.
<sconklin> tgardner, apw, smb, (and everyone) ^^ thoughts? Tags are a bit messy but list email subjects the entire kernel team to a bit of stable process that not everyone is interested in
<tgardner> sconklin, I think we should use LP as the basis for our process, and that means tagging.
<tgardner> email is abit ad-hoc
<bjf> tgardner, trying to not be a complete ass here, but why do we ask for the inital email to the mailing list when we could just accept a "please-pull" tag on LP bugs instead?
<sconklin> I think that the barrier for reapplication should be pretty low - i.e. someone says they'll test. So since we have two acks for the patch already, we don't need the number of eyes that we get from email
<tgardner> I guess because the list is lower volume then LP ?
<sconklin> bjf: for the acks
<bjf> sconklin, you can do the acks in the lp bug as well
<sconklin> but acks come from the entire kernel team, and reapplying is a part of a process that only the few team members dealing with stable process care about
<smb> i guess the email process seemed to be more open to people not looking at specific bug reports and quicker to work with in general (for the acks)
<smb> Just from gut feeling it seems better to work the process itself with lp and tags. Just as it seems simpler to query and process that programatically
<sconklin> smb: I think I agree, although we're continuing to really abuse launchpad as a process tool it was never intended to be. But it's the only tool we have.
<sconklin> So I think the vote is for tags. If it was a tie, I'm happy with being the tiebreaker for tags
<sconklin> next question - 
<sconklin> When we reapply, do we revert the revert?
<sconklin> or reapply
<tgardner> sconklin, nah, just apply
<ogasawara> +1
<tgardner> it might be a different patch by then anyways
<sconklin> tgardner: doing that has the advantage of getting the correct entry in the changelog, which is important
<sconklin> ok, decided.
<tgardner> sconklin, apw was working on a tool to futz the changelogs when a patch is reverted
 * manjo getting lunch will be back soon 
<sconklin> tgardner: yes, I'm aware of that - for today we'll manually deal with it
<sconklin> bjf, ogasawara: should we make the tags release-specific i.e. "stable-reverted-lucid", as some of these bugs are against multiple releases?
<bjf> sconklin, i guess so
<ogasawara> sconklin: makes sense
<sconklin> check me on this https://wiki.ubuntu.com/Kernel/StableReleaseCadence
<bjf> sconklin, so how much discretion are we giving ourselves in deciding the keep a non-verified patch versus reverting it?
<ogasawara> sconklin: looks good.  I know you're going to do this, but I'd add a blurb to Details section that along with setting the bug to Incomplete for unverified patches, a comment will be posted to the bug for how they can request re-application of the patch pending their commitment to test.
<bjf> sconklin, i have a one line quirk which fixes 7 LP bugs but didn't get verified
<sconklin> ogasawara: good point, I'll do it now
<sconklin> bjf: who's responsible for testing
<sconklin> ?
<bjf> sconklin, so you'd revert it
<bjf> ?
<mildoe> apw: ok
 * apw doesn't think this is going to get sorted out in one pass, i think we need a solid proposal to test-execute and critique
<bjf> sconklin, also, if a patch has 7 buglinks, do they all have to verify it fixed or is any single good enough?
<sconklin> bjf: In general yes. If there was any sort of explanation from someone about why it wasn't testable and was safe or something, I might consider taking it, but it would be a hard call. Remember that the verification requirement is actually part of the archive admin process, and not something we can just be free about. In this case, try asking pitti what he thinks
<sconklin> bjf: that's a very good question, and I'd take it. If it was a patch with many model numbers in the quirks, it gets harder, but still and especially for audio, if we assume that (for example) the mapping of codecs to model numbers is right, it should be OK
<bjf> sconklin, this is essentially new process. i understand what you are saying that it is part of the archive admin process. however, since we've are just now starting to implement it, i consider it new
<sconklin> bjf: agreed, and we are making it up as we go along . . .
<sconklin> the details, anyway
<ogasawara> if a patch fixed 7 bugs, I'd think they would all be marked as dups with one master bug?  And you then have 7x the possibility of it being verified.
<bjf> ogasawara, so the one master must be verified as fixed
<sconklin> bjf: in that case, yeah, which is another unenforced policy step
<ogasawara> bjf: right, you'd just pick one of the 7 to be the master, dupe the other 6 to it, and lp tells the other 6 to add comments to the master bug rather than continue using the duped bug
<bjf> ogasawara, yes, if the users have done what they are supposed to do and created a master bug
<ogasawara> bjf: the user doesn't have to create a master bug, you as the triager/developer just choose which one you want to be the master
<ogasawara> bjf: that's how duplicate bugs have always been handled
<sconklin> and if they are all separate in the pending SRU for a -proposed release, you may have to individually set them all to verified
<bjf> ogasawara, i understand what you are saying, but i am not necessarily the triager and not all triagers are going to do the right thing
<apw> tgardner, did that fixy to the rtnetlink.h make sense to you?  i am thinking if we are happy i should upload it sooner rather than later
<lool> apw: If you upload to fix linux-libc-dev, would you mind including https://patchwork.kernel.org/patch/320712/ ?
<tgardner> apw, yep
<apw> lool, that is the second patch of a pair from its commentary?  are both needed ?
<bjf> sconklin, are we the beginning of the first week of a new cycle? if not then i assume next monday is the first week of a new cycle (it seems we are several weeks into this cycle when did it officially start?)
<sconklin> Next week will not be the beginning of a new cycle unless a miracle happens. Once we revert, we're in a hold until testing happens, and the definition of "what's good enough" for that for the first pass will have to be made with input from QA, Cert, and the release manager.
<sconklin> I think that most likely, we will end up running out through the next two weeks, and effectively skip a cycle
<tgardner> sconklin, any test results from cert's dry-run ?
<lool> apw: It's not; it's a fix for commits which are already in the Ubuntu tree
<sconklin> tgardner: in a word, no
<apw> sconklin, who are we interfaced with over in QA for this
<sconklin> there were some results, but they were not all useful
<sconklin> apw: Victor
<vanhoof> sconklin: i'd vote heavily towards skipping a cycle ;)
 * vanhoof prays each night for .37 in -proposed to release :D
<sconklin> vanhoof: it's not really up for a vote, but fwiw I hear you
<cking> oops, not been away for hours, my fail
<bjf> sconklin, for maverick it looks like 3 reverts
<bjf> sconklin, 8 lp bugs affected 
<sconklin> bjf: for lucid, it's eight bugs, haven't counted how many reverts that maps to yet
<sconklin> some of them (most?) are the same bugs as maverick
<bjf> yes :-)
<bjf> sconklin, i'm going to start reverting patches, updating trees and doing builds
<sconklin> bjf: exactly where I am. I just fetched.
 * tgardner lunches
<bjf> sconklin, so we need to "startnewrelease", revert, "finish-release", then upload
<bjf> sconklin, with building and boot testing mixed in there as well
<sconklin> yeah, but is it insertchanges instead of "finish-release"? (along with manually editing changelog to remove buglinks on the reverted original patches
<bjf> sconklin, there is no "finish-release", yes I meant "insertchanges" + any other final details before uploading
<sconklin> bjf: whew
 * jjohansen1 -> lunch
<smoser> smb, can you poke bug 659084 ? or jjohansen1 so we can get it on future maverick kernel udpate.
<ubot2> Launchpad bug 659084 in linux-meta (Ubuntu) "2.6.35-22-virtual is missing nfs modules (affects: 10) (dups: 1) (heat: 145)" [Medium,Confirmed] https://launchpad.net/bugs/659084
 * tgardner breaks for a few hours
<bjf> apw, someone going to report out status for you in tomorrows meeting?
<sconklin> http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/
<bjf> sconklin, well that's just special
<sconklin> yeah, he was attacking deprecated SHA1s but still . . .
<jjohansen1> yeah, the cloud can make massive compute power available to anyone
<jjohansen1> and that can be scarry, sure he was just attacking sha1 but the same thing could be applied to stuff that isn't deprecated.  How many people really have good pass phrases on things
#ubuntu-kernel 2010-11-16
<Kubuntiac> can anyone tell me the deb sources line to add the mainline kernel daily ppa? I don't mean "http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/" I'm looking for the line to add to sources to get files from that location on updates.
<Kubuntiac> ie ppa:kernel-ppa/mainline or whatever it actually is
<RAOF> There isn't one.
<Kubuntiac> I must be misunderstanding something here then... what's the point of a ppa that you can't add to your sources?
<RAOF> It's not really a PPA.
<Kubuntiac> So it's just called kernel-ppa? o_O
<RAOF> The intention is to make it easy for people to test on an upstream kernel.
<Kubuntiac> Sure. I just want to contantly be testing the latest upstream kernel...
<Kubuntiac> Anyway, thanks for your help. I guess I'll just download manually every few days
 * abogani waves
<abogani> How can I compile a separated module? Is there any guide about it?
<jk-> abogani: does it have a makefile?
<jk-> (and do you want to build a package, or just the .ko?)
<abogani> jk-: I would want apply a very little patch on already present module.
<jk-> so you have the source tree for the module?
<abogani> I would prefer use the -headers package.
<abogani> Is there any RTFM or wiki URL/I?
<abogani> Google suggests this: http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
<kraut> moin
<jjohansen1> smb: tim grabbed Bug #659084 today before I got to it
<ubot2> Launchpad bug 659084 in linux (Ubuntu Maverick) (and 1 other project) "2.6.35-22-virtual is missing nfs modules (affects: 10) (dups: 1) (heat: 66)" [High,In progress] https://launchpad.net/bugs/659084
<alexandrosorodio> Hello there , doen anyone have any solutions on how to injection to work with ath9k and ubuntu 10.10 patch or any other solution? Thanks
<diwic> so given the new SRU cadence, what's the next deadline and when will that version reach maverick-updates?
<smb> diwic, Unfortunately I don't think this can be said right now. As they have to draft out the details of the process on the go.
<diwic> ok
<smb> diwic, I would hope for at least end of next week. But I am not much wiser than you at the moment
<diwic> smb, ok, then I'll have at least this week to produce patches :-)
<smb> diwic, :) Heh, you can produce them anytime. But I can see the pain involved in getting them actually in. Which the new process tries to improve as soon as we know what the new process is.
<apw> doko_, the libc fixes should be in the archive .... have at em
<doko_> apw: thanks
<tgardner> sconklin, your bug bot set the Lucid portion of bug 628776 to stable-reverted-lucid, but the Maverick patch is already fixed released. This seems like it needs a little oversight.
<ubot2> Launchpad bug 628776 in linux (Ubuntu Maverick) (and 2 other projects) "HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs (affects: 2) (heat: 18)" [Low,Fix released] https://launchpad.net/bugs/628776
<NoobFukaire1> anyone know of a PPA or something with an ubuntu kernel and the new wonder UI patch applied?
<sconklin> tgardner: that was no bot, that was manual, and intentional. There's no verification for lucid, and a comment saying that there is a new pull request in progress with no further updates.
<tgardner> sconklin, isn't that because no one has actually reviewed the pull request?
<sconklin> tgardner: possibly, but no pull requests can be processed until the current cycle is complete, since we were sitting in the verification stage
<tgardner> sconklin, hmm, this seems like a bug in the process. how are we going to handle patches in progress ?
<sconklin> tgardner: it probably is a bug in the process, which assumed that patches are atomic and complete, and that once they are released in a -proposed kernel, the only options are to verify and release them, or revert them
<sconklin> There's really no staging or working area other than what's applied for the next -proposed
<sconklin> and there's an assumption that all the decisions for revert/verify can be made using information in the bugs, without any external knowledge from mailing lists, etc
<tgardner> sconklin, perhaps bugs that are 'In Progress' should be ignored until they've gone 'Fix Committed'
<sconklin> that bug was "fix committed" for lucid.
<tgardner> sconklin, I guess I should have changed it back to 'In Progress'
<sconklin> But - in a case where the fix actually has been committed, it's unclear what the right action is.
<sconklin> shouldn't a change from fix-committed to in-process be accompanied by a revert? Since we don't really have an in-progress any more. Unless we add a staging branch to the repo.
<tgardner> sconklin, I guess we'll just have to use our judgement based on the complexity of the patch and the chance for regression
<sconklin> I do think that having a -next beanch may be helpful, although it would be rebased often. It would give developers a chance to test their patch on top of everything that's currently queued, and give us a little early testing, plus give visibility, and we could handle it like upstream merge windows. Although - we're having trouble just keeping up as it is. That will improve as our tools develop around the new process.
<tgardner> sconklin, I am definitely in favor of a master-next branch. Its quite tedious (and not always conclusive) to grovel patchworks and the mailing list to find out the state of a patch.
<tgardner> incoming patches should get applied to master-next sooner rather then later
<tgardner> though I'm not sure it really solves the problem
<sconklin> tgardner: we (the entire team and community) need to start talking about this larger problem. The whole mailinglist/patchwork/launchpad set of tools are not working and can't scale
<sconklin> but that's the swamp, and I'm ass-deep in alligators
<tgardner> sconklin, given that we're in verification week, do you know yet that you'll be able to get test results from cert ?
<sconklin> tgardner: no, but Brad and I haven't yet uploaded the new -proposed, and that's a predecessor. Should do that today, earlyish.
<sconklin> Right now I have to prepare a report for the meeting
* You're now known as ubuntulog
<sense> Is the Kernel Team aware of bug #653274? It is quite a visible regression in Maverik and Natty for Nvidia users and it has been around since the betas.
<ubot2> Launchpad bug 653274 in linux (Ubuntu) (and 1 other project) "Plymouth doesn't show Kubuntu or Ubuntu logo with Nvidia proprietary driver (affects: 26) (heat: 154)" [Undecided,Confirmed] https://launchpad.net/bugs/653274
 * JFo looks
<bjf> apw, meeting status? (i didn't think you were planning on attending)
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - in 30 minutes - #ubuntu-meeting
<bjf> ##
<smoser> smb, if you're awake/around, we're having our Server Team meeting now
<smoser> jj is gone, but normally he attends
<smoser> (#ubuntu-meeting)
<smb> smoser, I was there already
<smoser> you dont miss a thing
<sense> JFo: Thanks for taking a look.
<smoser> thanks smoser 
<smoser> smb
<JFo> sense, my pleasure
<JFo> still looking... got sidetracked
* You're now known as ubuntulog_
* You're now known as ubuntulog
<bjf> https://kernel-tools.canonical.com/srus.html
<bjf> https://kernel-tools.canonical.com/queues.html
<smb> "internal server error..."
<bjf> smb, the links are working for both sconklin and myself
<smb> second one does
<smb> probably first one is an openid problem
<bjf> smb, i'll go look at the logs
<smb> bjf, It works now
<sconklin> fails for me too, was working a bit ago
<smb> bjf, Looks like my kernel packages needing love, just nicer. :)
<kamal> kernel team meeting?
<smb> server team just finished
<ogasawara> JFo: just fyi, you can probably drop some of those kernels in your bug summary for future meetings.  for ex, linux-fsl-imx51 doesn't exist for Natty.
<JFo> yeah, was wondering about that
<JFo> thanks ogasawara 
<JFo> :)
<JFo> any other than that one?
<ogasawara> JFo: mvl-dove too I think, and ec2?
<JFo> ok, I'll remove them
<JFo> easy to add them back if needed :)
<smb> ogasawara, JFo I don't think any ec2 was dropper
<smb> dropped
<JFo> ok, so keep that one smb?
<smb> JFo, Yes, please. Until I change my mind. :)
<JFo> smb, will do :-)
<ogasawara> smb: it may not have been officially dropped, but I don't see it existing at the moment - https://launchpad.net/ubuntu/+source/linux-ec2
<smb> ogasawara, Oh gee, are we talking about natty?
<smb> Sorry got confused
<JFo> ah
<smb> JFo, So for natty ec2 did never exist and I just changed my mind
<JFo> heh
<JFo> ok :-P
<jjohansen> smb: so I lost internet at about 8:30 anything interesting happen
<smb> jjohansen, I thought so. Not too much, I can send you a transcript privately
<jjohansen> smb: thanks
<c10ud> hello, just read about the "uber" responsiveness patch..i was wondering if it can work with .32 and/or anyone already thought about backporting (yes, i'm still using lucid)
<JFo> c10ud, responsiveness patch?
<JFo> do you have a link?
<c10ud> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
<JFo> ah, this one.
<JFo> it must make it into the upstream kernel before we can get it
<JFo> so nothing on backporting yet
<JFo> I'm afraid
<c10ud> np, i didn't know how your team works, that's why i was asking :)
<JFo> :)
<jjohansen> c10ud: so in general the principle is sound and it would work, I have know idea what it would take to backport, as it will depend on other scheduler changes
<JFo> c10ud, our preference is to pull from the stable queue if possible
<jjohansen> it is not something see being backported to the stable series, so my guess is no
<smb> jjohansen, Not even in linux-next yet
<c10ud> i see
<jjohansen> nope, but it will be with the high praise it is getting
<JFo> c10ud, but we are watching it :-)
<smb> But generally as for upstream stable it needs to land in Linus tree first
<c10ud> linus seems very positive about it, it's just i am too lazy to put some unstable stuff in my box..but lately i've been suffering of those responsiveness issue a bit so.. :)
<jjohansen> c10ud: the problem is it is not just the 1 patch, my bet is it relies on other foundational work
<c10ud> heh that was my biggest doubt...32 seems so old compared to this new shiny stuff, poor lucid
<jjohansen> if it were just the 1 200+ line patch, I think it would make it to stable as several distros are using 2.6.32
<tgardner> jjohansen, I have a 2.6.32 backport from spanasik@gmail.com
<smb> jjohansen, Depending on how well Linus can sell that "new feature" as a bug fix to Greg. But I guess he can be pretty convincing.
<jjohansen> tgardner: oh really?  Interesting
<tgardner> it looks substantially the same as 2.6.37-rc2 version
 * smb begins to wonder whether we all talk about the same patch
<jjohansen> well my bet is suse will push greg to include it then, as it will probably be picked up for the sles kernel
<tgardner> jjohansen, I'm sure we'll have a serious look as soon as its upstream
<jjohansen> my assumption, without actually looking at the patch, is that it depended on some of the other scheduling work
<jjohansen> definitely
<jjohansen> as it would go a long ways to addressing certain bugs :)
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - November-23 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> sconklin, bjf: I pushed a script update to Lucid/lts-backport-maverick. Be sure to update before turning that crank.
<ogasawara> JFo: your sysrq handling email you sent to the k-t ml, was that in reference to bug 642792
<ubot2> Launchpad bug 642792 in metacity (Ubuntu Maverick) (and 6 other projects) "ALT+PrtSc not recognised: breaks built-in screenshot function (affects: 85) (dups: 6) (heat: 478)" [High,Triaged] https://launchpad.net/bugs/642792
 * JFo looks
<JFo> indeed it is
<sconklin> http://www.tomsguide.com/us/microSD-ATT-Windows-Phone-7-Focus-WP7-certified,news-8819.html
<JFo> nice
<sconklin> brings new meaning to plug and pray
<JFo> yep
<tgardner> ogasawara, do you have to run apport as root? re: kees wish to make dmesg protected.
<ogasawara> tgardner: not that I know of
<bjf> tgardner, because we collect acpi tables, we now require root for apport
<tgardner> bjf, do we also get DMI info as root?
<bjf> tgardner, this was a fairly recent change
<bjf> tgardner, we only had to go to root priv. for the acpi tables, not for dmi
<mjg59> kees: For the information you're talking about in dmesg, how much could an attacker determine by booting the same kernel version on a machine with a similar quantity of RAM and comparing /proc/iomem on the target machine?
<kees> mjg59: I'm meaning various debugging details leaking out of the network stack
<kees> mjg59: for full hilarity, see Dan Rosenberg's threads on net-dev
<JFo> cking, you roc?
<JFo> grrr
<JFo> deleted half the sentence
<cking> JFo, eh?
<JFo> was meant to be: cking you rock... have I told you that lately?
<JFo> :)
<cking> oh, thanks. ;-)
<JFo> the WMI brain dump
<cking> oh. yeah. that was fun - not.
<JFo> heh
<JFo> but I appreciate it
<cking> JFo, you need to thank mjg59 for all his helpful morsels of ACPI goodness he's been writing about that I find on google ;-)
<mjg59> kees: Ah, got you
<JFo> thanks mjg59 :)
<tgardner> ogasawara, why didn't your v2.6.32.25 stable updates make into this most recent Lucid upload?
<tgardner> you did the review (which is why I'm asking)
<ogasawara> tgardner: I was told that it was going to instead be pulled from smb's 2.6.32.y+drm.33 tree
<smb> ogasawara, tgardner It contained all the drm patches from .32 and then I think it was just late before trying to get the new process into place
<ogasawara> tgardner: I've got a few other patches I want shoved into Lucid as well, but am waiting for the green light for the SRU merge window to open
<tgardner> I'm beginning to think we need a -next branch 'cause I think stuff is getting lost.
<smb> tgardner, Either a -next or being confident that master can go ahead while proposed is processed
<ogasawara> I'd vote for a -next branch which gets rebased.  that way sconklin can still easily revert patches from master and then merge in -next when he's ready.
<sconklin> ogasawara: +1, we're really not able to keep up with everything as it is and I hope it will help. I get anxious every time I think about you taking time off. 
<smb> I tend to vote for doing the processing on a side branch and then merge that. But just because it seemed to work reasonable well for security and proposed re-uploads. MAybe the result of the merge looks even similar both ways
<ogra_ac> bjf, bug 663642 was verification-done since quite some time already
<ubot2> Launchpad bug 663642 in linux-linaro (Ubuntu Maverick) (and 3 other projects) "DVI doesn't work at BeagleBoard xM rev A3 (affects: 1) (heat: 18)" [Undecided,Fix released] https://launchpad.net/bugs/663642
<ogra_ac> bjf, does your comment mean you removed the fixed package from proposed again ?
<rsalveti> and the bug was changed to verification-done on time
<ogra_ac> right
<rsalveti> that was nov 08
<smb> sconklin, Yeah I guess regardless what we end up with, the working branch would be good to be an officially pushed one
<smb> or the next branch
<smb> whatever suits better
<bjf> rsalveti, ogasawara look at the action on 2010-11-13 which added "verification-needed" and removed "verification-done"
<bjf> ogasawara, sorry not you, ogra_ac
<bjf> ogra_ac, ^
<rsalveti> bjf: I did that, because I thought the linaro one was tested
<rsalveti> and not ours
<rsalveti> my mistake 
<rsalveti> but the deadline was nov 11
<bjf> rsalveti, it looked like the testing was not done for maverick by the deadline which was yesterday
<rsalveti> the bug said the deadline was nov 11
<GrueMaster> I had changed the tag on 11-08 when I filed the comment.  Unfortunately it doesn't appear to have changed in LP at that time.
<bjf> rsalveti, at this point it doesn't matter what the date was as the revert happened yesterday
<rsalveti> urgh, so how to get it back?
<GrueMaster> Would be nice for someone to ask us in the future before the patches get reverted.  I don't suggest relying on LP alone.
<GrueMaster> (I can't even find half the bugs I need to track without google).
<bjf> GrueMaster, we have to rely on LP
<ogra_ac> in any case (before that turns into a LP discussion) can we have the fix back asap ?
<GrueMaster> I fail to rely solely on it, as I don't even get half the emails for bugs I filed.
<bjf> GrueMaster, rsalveti, ogra_ac, going forward there will be a "verification-needed-<rls>" tag which will help a little
<GrueMaster> ok
<rsalveti> GrueMaster: and how should we proceed when we have the bug on both kernel?
<rsalveti> linaro and ubuntu
<rsalveti> we need the verification-done for both, that was the main confusion for me
<rsalveti> bjf: how can we get the patch back to the repo again?
<GrueMaster> Understood.  But as a general rule, I try not to change tags without a supporting comment.
<rsalveti> GrueMaster: martin pitt changed the tag
<GrueMaster> Yes, I know.  And his comments supporting that change are...where?
<GrueMaster> As I said, I had changed it when I added my comment.  But LP didn't take the change for some reason.
 * tgardner lunches
<bjf> rsalveti, am discussing with sconklin
<bjf> GrueMaster, ogra_ac, ^
<GrueMaster> But LP asside, we either need to get the patch re-reverted and back to where it was on 11-08, or we need to reapply it and re-recruit community members to retest (which imo makes us look incompetent).
<bjf> GrueMaster, ogra_ac, rsalveti, am reapplying and will re-upload
<ogra_ac> thanks 
<rsalveti> bjf: thanks so much, and sorry about the confusion again
<GrueMaster> Requiring retesting?
<bjf> GrueMaster, would be a good idea
<GrueMaster> sigh.  
 * GrueMaster puts recruiter's hat back on.
<bjf> GrueMaster, but there is no plan for a second revert pass if it isn't tested
<GrueMaster> Unless it gets preempted by another security release.
<GrueMaster> I've been down this path before with Dove and babbage.
<jjohansen> pgraner: you around
<sconklin> ogra_ac, GrueMaster: there is no other way for us to scale stable kernel maintenance other then relying on bugs to track the verification state. People will have to be responsible for tracking the things they care about.
<GrueMaster> sconklin: The main issue here is that none of us have the newest board that requires this patch, so we need to rely on members of #beagle to test it for us.
<GrueMaster> All I ask is that in the future, especially when there are different kernel packages in the same bug, that each tag change is followed by a comment.
<GrueMaster> It would greatly help avoid future confusion.
<ogra_ac> sconklin, the issue with that bug was that we have a duplicated package in the archive which caused confusion, there is the omap3 kernel as well as the linaro omap3 kernel verification for the one didnt happen for the other that caused the havoc we're in now
<jjohansen> https://wiki.canonical.com/UbuntuPlatform/Sprints/TestAutomationSprint
<smb> sconklin, bjf JFo ^ Sounds like it could be interesting to you (one at least)
<JFo> hmmm
<JFo> I'd be interested as long as the team thought that were a useful use of my time.
<JFo> looks to be geared toward guidance of the framework as it stands and has been planned
<bjf> i'm interested but haven't got the time
<bjf> the other issue i have with it is it will be "yet another framework" which will take an entire dev cycle to get in place (at the least)
<JFo> yeah
<smb> bjf, It just seemed to be much about testing the proposed sru kernels that I thought there might be someone useful that knows the subject of the test and keeps people at bay of inventing the golden egg when we just need some simple ones
<jjohansen> bjf: what I think would be useful is to hit manjo with a few points/notes as he is going
<smb> yeah
<manjo> smb, can I join you guys in mumble ?
<smb> manjo, There is nothing interesting going on in hell. Just heat. 
<sconklin> manjo: https://wiki.ubuntu.com/Kernel/StableReleaseCadence
 * jjohansen -> lunch
 * ogasawara lunch
<achiang> was there some discussion here a few days ago about powernowd? is that package deprecated?
<pgraner> jjohansen1, I am now
<tgardner> jjohansen1, have you started on ecryptfs yet? It would be nice to get those patches in 2.6.38
<jjohansen1> tgardner: no not yet, I'll start this week, I have been trying get the interface up that jamie will need for dbus
<jjohansen1> pgraner: quick chat
<jjohansen1> mumble or call I don't care
<pgraner> jjohansen1, sure lemme get my headphones
<bjf> ogra_ac, GrueMaster, rsalveti, new source package containing your patch has been uploaded
<sconklin> skaet: lucid and maverick kernels are uploaded and awaiting acceptance, I'm outta here - catch you tomorrow.
<skaet> sconklin,  sounds good.
<skaet> sconklin,  re the sprint - yes, some of the concerns we talked about will be addressed.  Catch me on mumble tomorrow and I"ll give you more details. 
<sconklin> skaet: great, thanks!
<sconklin> and thanks for setting up the recurring meeting
<skaet> heh, no worries.
#ubuntu-kernel 2010-11-17
<rsalveti> bjf: cool, thanks
 * apw yawns
 * smb looks whether apw looks a bit sweaty
<apw> huh ?
<smb> How does it feel being dragged into mumble hell
<tseliot> smb, apw: do you know where's the script that's called by "debian/rules insertchanges"? I'm asking as it's not working correctly for me (I'm using a customised flavour)
<apw> tseliot, in part some of it is in the rules (the bit which works out the start point) and the second debian/scripts/misc/git-*log*
<apw> but i suspect its the rules themseleves which fail
<apw> the key think is they look for the Ubuntu-<version> messages in the commits to find them
<apw> s/them/the start commit/
<apw> tseliot, ^^
<tseliot> apw: ok, thanks
<smb> My workaround for that is sometimes "git log <whatever range>|./devian/scripts/misc/git-ubuntu.log > bla" and then include the output in the changelog with my favorite editor
<apw> tseliot, you can find the version number it is looking for using the fdr printenv
<tseliot> apw: this looks correct (at least to my sleep deprived eyes) http://pastebin.ubuntu.com/533394/
<apw> tseliot, so this is the first version on the branch as it is looking for 2.6.37-0.0
<apw> prev_revision     = 0.0
<tseliot> apw: yes, that's correct
<apw> so unless you have an UBUNTU: Ubuntu-2.6.37-0.0  commit somewhere it will not woerk
<apw> i generally just hand make the commit log for the firrst time there, must as smb suggested
<apw> it will work the next time
<tseliot> apw: I have this though: "UBUNTU: (release) Ubuntu-2.6.37-0.0 for $MYPROJECT"
<tseliot> maybe "(release)" broke the regular expression or whatever it's using
<apw> no its the for $MYPROJECT that broke it
<tseliot> apw: oh, really? Where is it in the code?
<apw> tseliot, look for printchanges
<tseliot> apw: I can only see insert-changes.pl in misc
<apw> rintchanges:
<apw>         @baseCommit=$$(git log --pretty=format:'%H %s' | \
<apw>                 awk '/UBUNTU: '".*Ubuntu-$(release)-$(prev_revision)"'$$/ { print $$1; exit }'); \
<apw>                 git log "$$baseCommit"..HEAD | \
<apw>                 perl -w -f $(DROOT)/scripts/misc/git-ubuntu-log $(ubuntu_log_opts)
<apw> tseliot, it is that way because we generally prefix the taging on branches
<tseliot> apw: what file is that? I mean the one with printchanges
<apw> UBUNTU: NBK-Ubuntu-2.6.37-1.2
<apw> normally they are like that ...
<apw> tseliot, that is debian/rules/1*
<apw> but grep is your friend
<tseliot> apw: right, I should have used a combination of find and grep
<tseliot> thanks
<apw> git grep is even better
<smb> tseliot, There is grep -r ;-)
<tseliot> ah
<tseliot> apw, smb: adding a simple .* to the regular expression did it :)
<apw> yeah thats fine for your bracnch, a bit risky for main
<tseliot> lazyness FTW :)
<tseliot> apw: yes, it's just for my branch
<tseliot> apw: BTW this doesn't seem to change insertchanges, only printchanges
<apw> tseliot, insertchangs directly uses printchanges
<tseliot> this saved me a lot of time
<apw> have you lost the markers
<tseliot> apw: I know that it should use printchanges but maybe it aborts the operation
<tseliot> it = insertchanges
<apw> tseliot, insertchanges needs the markers in the changelog, which get lost as soon as the first insertchanges fails to find anything
<apw> you often need to get them back, git diff will show you what went away
<tseliot> apw: markers? Aren't they in printchanges?
<apw> there are three lines of markers in the changelog, added by startnewrelease
<apw> which are removed and replaced by insertchanges
<apw> is they are not there, it cannot find the right place to put the output
<tseliot> apw: oh, I didn't use startnewrelease for the changelog
<apw> theres your problem
<tseliot> right
<tseliot> apw: http://kernel.ubuntu.com is public, isn't it? Does it support private branches?
<apw> tseliot, define private, as in secret and must be kept hidden?
<tseliot> apw: as in accessible only to canonical employees
<tseliot> apw: and hidden
<apw> then zinc is not an appropriate venue
<apw> there are non-canonical people who can login for example
<tseliot> s/to/by/
<apw> there is an oem repo somewhere
<apw> whihc you should ask about on #hwe
<tseliot> apw: ok, thanks
<smb> cking, apw https://wiki.canonical.com/UbuntuPlatform/Rally/Natty
<cking> smb, ta
<kraut> moin
<apw> https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
<akheron> just stumbled upon bug #154271
<ubot2> Launchpad bug 154271 in xen-3.3 (Ubuntu) (and 2 other projects) "xenU sending too big packets (affects: 2) (heat: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/154271
<akheron> does anyone have a clue of what could cause this?
<smb> gutsy???
<akheron> the kernel in xen domU sends too big IP packet, router asks to fragment, kernel sends a smaller one, the other end of the connection acks, and then the kernel sends too big packet again
<akheron> smb: no, I have this with a lucid domU
<apw> well if it is a kernel issue then it should really be files against the kernel ?!?
<akheron> domU is 2.6.32-22-generic-pae, dom0 is lenny's 2.6.26 something
<akheron> xen 3.3
<akheron> apw: I don't really know where the bug is but seems kernel to me
<smb> Hm, in Hardy there has been some F-RTO issues. Though I thought 2.6.26 should have those fixed. 
<apw> smb, the tcpdump seems to show packats being sent >MSS
<akheron> I can send more tcpdumps if someone wants to
<akheron> just figured out today why my domUs have been sending data VERY slowly
<apw> akheron, i assume the ethtool -K tx  off works for you ?
<akheron> apw: yes, fixes it completely
<akheron> but I don't understand why some tx checksumming would matter
<apw> akheron, well you are handing off processing to the 'hardware' which presumably is the xen virtualised driver ... and perhaps its utterly broken
<akheron> ah, ok
<apw> i've documented the work-around prominently in the description and added a task for the kernel
<akheron> so you think the bug is in the dom0 kernel then?
<akheron> we're using debian kernels there are ubuntu doesn't ship them, afaik
<akheron> I'm not the system admin :)
<apw> akheron, no i suspect it is in the domU kernel as its only there that switching it
<apw> makes a difference
<smb> Well dom0 would be the one supplying the "hw"
<smb> Last dom0 we did was hardy
<akheron> smb: yes, that's what I thought also
<apw> smb, not necessarily, as this is logically bridged
<apw> intermediate hops do not normally change the package they just ship it along
<apw> and as the change of config is on the domU, and that change should be a no-op from the view of outside the domU
<apw> it seems likely it should be the domU which is breaking things
<smb> But as you say you change the tx offloading
<apw> but that is tx offloading in the domU kernel, i can only offload it to the driver, and that is still in my domU
<smb> hm
<apw> it is possible that the offloading means that the dom0 does the summing instead, but that does seeem odd to me
<tgardner> apw, wouldn't that imply para-virt ops? I'm pretty sure a DomU of that vintage wasn't that smart.
<apw> akheron, what sort of fake ethernet is being used in the domU
<akheron> I'm just looking
<apw> tgardner, it is a lucid domU
<akheron> xen_netfront
<tgardner> oh, I thought I saw Hardy mentioned
<akheron> tgardner: the bug is very old
<smb> well ii read correctly this is since gutsy
<apw> smb, yep i mean new kernels are still broke, or its dom0 yes
<smb> Yeah. Quite odd
<akheron> it seems to me that xen has some weird checksum offloading system
<akheron> now that I'm looking, I can find many pages with google that suggest to disable tx offloading
<apw>         /* We need checksum offload to enable scatter/gather and TSO. */
<apw> it seems once we turn off the tx sum offload, we stop using scatter gather and TSO whatever the latter is
<apw>                 dev->mtu = ETH_DATA_LEN;
<apw> heh but what it does do ... is immediatly do that
<apw> oh ignore me
<tgardner> apw, isn't there a sysfs way to cap mtu ?
<smb> apw, Where the heck are you looking? Latest code?
<apw> tgardner, yep and that is set as far as i can see, and when it starts SG mode it ignores it and breaks everything
<tgardner> apw, hmm, bad news
<apw> smb,  lucid domU support
<apw> static int xennet_change_mtu(struct net_device *dev, int mtu)
<apw> {
<apw>         int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN;
<apw>         if (mtu > max)
<apw>                 return -EINVAL;
<apw>         dev->mtu = mtu;
<apw>         return 0;
<apw> }
<apw> that seems to allow MTU to clamp close to 64k in scatter-gather mode, turning off tx csum also turns that off
<apw> i suspect that when csum is turned on the dom0 is meant to do something meaningful with the packets before pushing them out onto the wire
<apw> and i suspect it is not
<apw>                 if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-sg",
<apw>                                  "%d", &val) < 0)
<apw>                         val = 0;
<apw>                 if (!val)
<apw>                         return -ENOSYS;
<apw> does that error condition seem inverted to anyone?  if we are unable to lookup feature-sg surly we should assume we have not got it, not assume we have ?
<akheron> if scanf fails, val = 0 and if val == 0, return -ENOSYS
<akheron> looks correct to me
<apw> doh just my eyes, thanks
<akheron> :)
<apw> from what i can see i think xennet assumes we can pass large packets to the host and let it fragment and sum them
<apw> and it looks like the host is not
<akheron> so it's dom0 problem after all?
<apw> i would lean to debugging there first yes
<akheron> at least the fragmentation needed packets arrive at domU
<smb> I dunno, max is not used. Its mtu in the code above
<smb> And that is set to the right value
<tgardner> apw, we could test your theory by fixing the mtu CAP on the domU client.
<akheron> the mtu on eth0 is 1500
<apw> well i would expect that if we shove a bad packet out without fragmenting it and get a reply from an external router, i would expect us to pass that back to the domU thinking its for it
<akheron> but it still sends >2900 byte packets
<akheron> I can see that using tcpdump clearly
<apw> right, and the MTU seems to be ignored at the domU when when DG and CSUM offloading is enabled
<apw> SG even
<apw> and we pass all the bits as one packet even if it was multiple skb's
<akheron> doest it try to optimize domU - domU traffic inside dom0 by ignoring mtu?
<akheron> because that traffic seems to work
<apw> akheron, yes i think its meant to optimise by ignoring MTU during the cross domU/domH transition
<apw> assuming that the dom0 will fit the result into the MTU before shoving it into the bridge at the other side
<akheron> but it doesn't
<apw> indeed it seems not
<apw> but that seems like a dom0 issue
<apw> its not clear from the interface how you would avoid having to handle that at the other end of the link
<apw> akheron, one interesting test would be to disable tx offloading then turn it back on and confirm that the issue reasserts itself
<apw> smb, with luck xen dom0 will be upstream by the next LTS, ie by the time hardy goes away
<smb> apw, and maybe fixed. Though (and unfortunately I have not time to learn enough) lots of the interaction is done by a user-space part
<apw> yeah i bet it is
<apw> we have qemu for the same purpose in kvm
<smb> I believe they use qemu too
<smb> apw, Hm, just reading that qemu is more likely used for HVM domUs not for the PV domUs (which use a xennet-backend (which is maybe in the hypervisor code))
<bjf> https://kernel-tools.canonical.com/srus.html
<bjf> https://kernel-tools.canonical.com/queues.html
<tgardner> bjf, did mumble die on us?
<cking> died on me
<JFo> yep
<smb> Seems to have for me
<bjf> yup
<JFo> diead for everyone it seems
<smb> And it looks like canonical irc as well
<JFo> yep
<tgardner> just came back
<cking> me too
<cking> and my email
<ubuntuuser> Hi
<ubuntuuser> I have run into some issues between my SATA-controller  (VT6420) and my new Western Digital Green Power disk (WD10EARS)
<ubuntuuser> There seems to be a fix for it
<ubuntuuser> http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/02db8575ded42ab1
<ubuntuuser> what can I do to help get the patch in ubuntu's kernel as soon as possible?
<tgardner> ubuntuuser, this seems like a stable updates sort of patch. 
<bcurtiswx_> im going to assume you've gotten this question a lot recently and apologize if its overkill.  Does Ubuntu plan on grabbing the ~200 line kernel patch that sig improves things for Natty?
<ogasawara> bcurtiswx_: http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch
<bcurtiswx_> ogasawara, :) muchas gracias
<manjo> have you guys looked at https://status.canonical.com/doc/faq ?
<apw> manjo, how does microblogging help us?  i have enough of that in my life already
 * apw pokes manjo
<manjo> apw, on a call
<apw> so multi-task :)
<JFo> why must headaches all act differently? This one refuses to let my eyes focus for very long :-/
<JFo> that is my QOTD
<ubuntuuser> thanks tgardner, I am new to bug reporting/patching etc, can I do something/do I have to file a bug report?
<manjo> ubuntuuser, you could file a bug and add a comment pointing to that patch
<apw> JFo, different causes, that one is likely eye strain related
<JFo> could be
<JFo> I think it is still lack of sleep related
<JFo> either way, it sucks
<apw> generally being awake is signalled by eyes not closed and not resting
<ogra_ac> tgardner, hmm, Bug 673509 is no duplicate of bug 673504
<ubot2> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/673509
<ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (dups: 1) (heat: 26)" [High,Fix committed] https://launchpad.net/bugs/673504
<ogra_ac> *of Bug 673509
<tgardner> ogra_ac, its already been pointed out to me
<ogra_ac> tgardner, but now we have verification tags on both 
<ogra_ac> after the disaster yesterday i'd like to avoid that uploads get wiped from -proposed unconditionally through wrong tagging
<tgardner> ogra_ac, ti-omap4 is building.
<ogra_ac> yes, and the beagleboard bug has a verification-needed tag now
<tgardner> ogra_ac, that wasn't a disaster, merely a minor hiccup
<ogra_ac> well, tell that to tobin who moans about having to spend a week to find community testers
<apw> heh well we do want to know we arn't bricking boards right ?
<ogra_ac> apw, well, hard to brick a board if you apply the patch to the wrong kernel :P
<ogra_ac> i set the bug back to proper status so we can track verification as soon as the next linux package goes up
<jewsucanuse> what rc is the scheduler patch er... scheduled for?
<tgardner> jewsucanuse, http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch
<jewsucanuse> thx tim
<Sarvatt> jewsucanuse: 2.6.38-rc1 most likely unless some magic happens
<tgardner> apw, how do I get .bashrc to execute on login? Since trashing /home on tangerine I can't seem to automatically get it sourced.
<jewsucanuse> natty is still scheduled for .38 right?
<apw> tgardner, i believe different ones get souced depending if the connection is interactive or not, i always have to add an echo NAME to .bashrc .bash_login and .profile in my home and try it out to figure out which ones get loaded when
<tgardner> apw, ah! Its .profile that sources .bashrc
<ubuntuuser> ok i will file a bug, thanks tgardner, manjo
<JanC> apw: it's documented in 'man bash' and 'info bash', you know...  ;)
<apw> JanC, yeah it is, but it uses words that make it much easier to just try it and see :)
<JanC> eh, it seems like it's plain English to me, but I'm not a native speaker
<ubuntuuser> ok I have reported the bug (676644) sorry if it is not quite up to the usual standards, I am new to this ;)
 * tgardner lunches
<hallyn> to replicate a kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/, do i just apply the 3 patches there and hit 'go'?
 * hallyn wants to get resume on his netbook working!
<tgardner> hallyn, why not try the kernel in https://launchpad.net/~kernel-ppa/+archive ?
<tgardner> its based on 2.6.37-rc2 (and is still cooking)
<JanC> ubuntuuser: if you mention LP bugs on IRC, use something like: bug 676644
<ubot2> Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/676644
<JanC> see why?  ;)
<ubuntuuser> k thanks JanC
<hallyn> tgardner-afk: that kernel doesn't work for me :)
<hallyn> tgardner-afk: so i wanna tweak it to try and make it work again
<JanC> ubuntuuser: and you can add useful info for the developers to your bug with the command "apport-collect 676644" (not sure if that's still needed if there is a patch available already though)
<ubuntuuser> JanC: I'll look into it, I've just looked for some more information about the patch&bug, now I am not so sure it is what I am experiencing... A hardware issue is very unlinkely however, as I have switched out every part of the chain.
<tgardner> hallyn, whats missing frmo that kernel that _is_ in the mainline build? Or were you planning to patch the mainline?
<ubuntuuser> goodbye to all, thank you
<hallyn> tgardner: well, i want to debug it. 
<hallyn> tgardner: in the lucid kernel, resume worked
<hallyn> in maverick kernel AND In upstream, it fails
<hallyn> i'm kinda hoping i can find an easy fix
<tgardner> hallyn, bummer. there are a lot of commits between lucid and maverick.
<hallyn> yeah
<hallyn> i did open bug 674075, but am figuring since it's broken upstream, there's not much hope :)
<ubot2> Launchpad bug 674075 in linux (Ubuntu) "Maverick won't resume (lucid will) on Lenovo S10-3 (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/674075
<tgardner> hallyn, which Broadcom driver are you using? The hybrid driver?
<hallyn> 'wl' i guess
<hallyn> (accoding to lspci -v)
 * jjohansen -> lunch
<tgardner> hallyn, since its a binary blob, try 'modprobe -r wl' before suspending.
<tgardner> you might also try 'rfkill bluetooth'
<hallyn> no bluetooth on this thing it seems (i found out the hard way yesterday when i was expecting to use headset to mumble :)
<hallyn> i'll try the modprobe -r in a few mins, thanks
<dany_> hi all
<dany_> hi guys
<tgardner> ogasawara, shall I reset Lucid master-next back to its original HEAD ?
<ogasawara> tgardner: nah, just about to push.  want to do a quick test build first.
<tgardner> ogasawara, but you're gonna clobber HEAD, right?
<ogasawara> tgardner: I'm just gonna force the push over the existing master-next
<ogasawara> tgardner: right
<tgardner> ogasawara, ack. lemme know when cause I've a couple patches to drop in
<ogasawara> tgardner: I just pushed.  if there's a build failure, I'll fix it up in a subsequent commit.
<ogasawara> tgardner: I was also gonna drop in your patch for bug 628776, unless you beat me to it
<ubot2> Launchpad bug 628776 in linux (Ubuntu Maverick) (and 2 other projects) "HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs (affects: 2) (heat: 54)" [Low,Fix released] https://launchpad.net/bugs/628776
<tgardner> ogasawara, there are 2 patches for 628776. I'm just gonna do a test build then mark the bug verification-done
<tgardner> since its verifiable by inspection
<ogasawara> tgardner: cool
<hallyn> tgardner: wl is apparently not the culprit.  at least not the only one
<tgardner> hallyn, well, if the bug is still upstream then you're likely gonna have bisect it
<hallyn> tgardner: right
<hallyn> tgardner: hence my original question.  i recon' i'll just try it
 * jjohansen running an errand
<dany_> no one?
<apw> dany_, if you have a question ask it ...
<dany_> apw: I said before, I'll copy again :=
<dany_> :)
<dany_> I get this error: gcc -g -O2 -Wall -Wunused -o .libs/dc1394_vloopback dc1394_vloopback.o affine.o  -lm ../libdc1394/.libs/libdc1394_control.so /usr/lib/libraw1394.so
<dany_> ../libdc1394/.libs/libdc1394_control.so: undefined reference to `raw1394_set_iso_handler'
<dany_> I'm installing an old version of libdc1394
<dany_> the 1.2 one
<dany_> I think that it doesn't see the raw library that is installed in my system
<dany_> Can you tell me how can I say to libdc1394 (there is a configure file)
<dany_> to see the libraw?
<dany_> tgardner: wl is apparently not the culprit.  at least not the only one
#ubuntu-kernel 2010-11-18
<MTecknology> I just 'love' this... I try to use the newer flash in firefox and when launched from cli. I see this message when I try to play the flash '2.4+ kernel w/o ELF notes? -- report this'. You guys have any idea what it might be complaining about?
<MTecknology> I see in the kernel config for the latest generic there's not much about ELF that's not added
<MTecknology> I wonder if that
<MTecknology> I wonder if that has something to do with why flash doesn't work for crap for me on this system
<akheron> apw: after ethtool -K eth0 tx on, the data still moves fast
<akheron> apw: so the problem actually doesn't reassert itself
<apw> akheron, interesting, could you document that in the bug as well
<apw> akheron, perhaps there is a source end clamping issue after all
<smb> akheron, One thing I was wondering as well, was that tcpdump taken in the domU or dum0?
<smb> apw, Good morning btw. :)
<apw> smb morning
<kraut> moin
<akheron> smb: the tcpdump in the bug desc is not mine
<akheron> smb: but I had the same dump in my domU, didn't dump at dom0
<smb> akheron, Ah ok. Hm, wondering whether it would add some insight to dump dom0. But probably its just the same
<akheron> probably yes
<akheron> apw: commented on the bug now
<akheron> gah, there's a typo
<akheron> I can't edit comments?
<apw> nope, that would be useful
<dholbach> hey
<dholbach> did anybody else report problems with the newest kernel in natty in vms? I can't start X in there:
<dholbach> [    8.358283] WARNING: at /build/buildd/linux-2.6.37/drivers/pci/pci-sysfs.c:758 pci_mmap_resource.clone.9+0x156/0x1a0()
<dholbach> [    8.358297] Hardware name: Bochs
<dholbach> [    8.358300] process "Xorg" tried to map 0x00100000 bytes at page 0x00000000 on 0000:00:02.0 BAR 0 (start 0x        f0000000, size 0x         2000000)
<dholbach> full dmesg log: http://people.canonical.com/~dholbach/tmp/dmesg.log
<apw> dholbach, nope noone mentioned it before you
<dholbach> want me to file a bug? with -4 it works
<apw> dholbach, please and assign it to me
<dholbach> will do
<dholbach> apw, what would a good bug title be so you can find it more easily?
<ogra_ac> "doesnt work"
<ogra_ac> :)
<dholbach> "IT DOESN'T WORK!!!!111!!!1!!111!11"
<dholbach> apw, ok nevermind, bug 676963
<ubot2> Launchpad bug 676963 in linux (Ubuntu) "process "Xorg" tried to map 0x00100000 bytes at page 0x00000000 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/676963
<smb> dholbach, http://www.spinics.net/lists/kernel/msg1111743.html
<smb> apw, ^ upstream detection of regression of lp#676963
<apw> smb thanks ... that thread says "its fixed in master" ... so i'll go look
<dholbach> smb, thanks
<bond> hi list I recently began doing kernel programming
<bond> I was able to develop a character device driver
<bond> based on my search on internet and docs here and there
<bond> I want to do bug fixing
<bond> and I had a look at the ubuntu kernel bugs page
<bond> I am reasonably Ok in C and programming
<bond> have been practising things for quite some time
<bond> I am not sure as which bug should I start with
<bond> can some one suggest me some thing
<apw> bond, JFo normally has a list of bugs which are of priority to us perhaps something off there would be suitable
<tgardner> sconklin, now that we have kernels in proposed, have you have any feedback from cert that they've gotten started?
<tgardner> had*
<apw> (or indeed have they been told they are there)
<tgardner> skaet, ? ^^
<skaet> tgardner, heard from victorp and they're ready to go as soon as sconklin sends the signal.
<tgardner> skaet, what signal? I think all we are lacking are the meta packages.
<skaet> think the process is still going to be a bit manual in terms of the handover, until we get some flows and expectations nailed down.
<sconklin> skaet: If the packages are there, then they can start. I'll ping victor (I just walked in)
<skaet> signal is to tell victorp(?) that its ready to be kicked of (via IRC, phone, email, etc.)
<skaet> sconklin, yup,  that's what seems to be needed right now.  :)
<tgardner> sconklin, make sure they aren't depending on the meta packages to be up to date.
<sconklin> tgardner: they probably are, but I'll ask
<tgardner> sconklin, shall I upload those packages whilst you're talking to them?
<sconklin> tgardner: make it so ;)
<skaet> :)
<tgardner> sconklin, maverick meta looks OK. 2.6.35.23.25, and the kernel ABI is 2.6.35-23.40 ( have to say it outlous 'cause these numbers make me dyslexic)
<tgardner> outloud*
<sconklin> tgardner: thanks
<sconklin> I don't recall an abi bump for either, but my memory is not to be relied on
<tgardner> sconklin, and lucid meta is 2.6.32.26.28, the kernel ABI is 2.6.32-26.47, so it all looks good.
<sconklin> tgardner: thianks, I've just informed Victor, and they'll start testing.
<apw> they both look up to date to me
<apw> sconklin, bjf[afk] i have moved the pre-preproposed kernels over to master-next for maverick and lucid
<tgardner> apw, I saw those go by on the c-k-t list this AM
<apw> oh yeah, thats where the accept emails go
<sconklin> apw, you did that yesterday around noon, right?
<apw> nope, today around 10 my time
<sconklin> apw: hmmm, there was a pile of stuff on both -next branches yesterday . . .
<happyaron> could somebody have a look at bug 674952 ?
<ubot2> Launchpad bug 674952 in linux (Ubuntu) "natty kernel doesn't work with voice input by microphone (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/674952
 * sconklin looks at the repo
<apw> sconklin, huh?  i only switched over the checker to -next today at 10, so that was the first it would have noticed
<tgardner> sconklin, what apw meant was is that he switched the pre-proposed builds to pull from master-next,
<sconklin> oh, I get it now.
<sconklin> Sweet, and thanks apw
<sconklin> Only one cup of coffee so far
<apw> sconklin, keep me in the loop if you are making -next for any other repos
<sconklin> apw: ack
<apw> dholbach, ok i've posted some test kernels in your bug if you could test for me ... :)
<dholbach> apw, sweet - thanks
<sconklin> dholbach: the lucid kernel in -proposed may fix your audio problem, it would be great if you could test it for me
<dholbach> sconklin, I'm in the office now, I'll test it tonight and send you a mail
<dholbach> I'm VERY much looking forward to it working again
<dholbach> :-)
<bjf> sconklin, if we just start telling people the -proposed kernel will fix their bug, we get more -proposed testing, good plan
<bjf> sconklin, :-)
<dholbach> haha
<sconklin> bjf: heh, yeah - only this time there's some fact-based reasoning behind that ;-)
<dholbach> bjf, there might be a future in marketing for you!
<bjf> dholbach, i thought i was in marketing
<dholbach> right.........
<dholbach> :-)
<dholbach> apw, it works
<apw> dholbach, ack thanks
<dholbach> good work
<dholbach> thanks apw, sconklin, smb, ... and bjf: you rock! :)
<sconklin> dholbach: That's provably true now, and I'll continue their roadie training so they have a second career to fall back on ;-)
<dholbach> haha, excellent :)
<tgardner> bjf, don't forget to upload the LBMs for lucid/maverick
<bjf> tgardner, ack
<tgardner> lots of ogasawara goodness therein
 * apw pops to the bank
<pgraner> bjf, sconklin, smb: https://wiki.ubuntu.com/ReleaseTeam/Meeting/2010-11-22-SR  can you look over and add any points/questions as necessary pls.
 * smb looks
<JFo> skaet, speaking of which, do you have any bugs other than the one noted for me to keep an eye on?
<apw> JFo, yo ... yogout
<JFo> did you just call me yogurt? ;-)
<skaet> JFo,  for the tomorrow agenda - just culling through the bugs right now.   Will post something out after lunch. :)
<JFo> coolness thanks :)
<vanhoof> anyone decent with bug mail w/ lp?
<vanhoof> i keep getting everything (including direct subscriptions) in kernel-bugs
<vanhoof> i even tried leaving the team, but they're still coming
 * vanhoof cant figure out why
<vanhoof> You received this bug notification because you are a member of Kernel
<vanhoof> Bugs, which is subscribed to linux in ubuntu.
<vanhoof> ... must be some indirect association?
 * tgardner lunches
<apw> vanhoof, probabally some other team is a member of that team, you can tell somewhere though
<cking> never sure how though
<vanhoof> apw: i cant seem to find anything :\
<vanhoof> its weird, this just started on Nov 5th
<vanhoof> at 3am
<vanhoof> i certainly wasnt playing w/ mail or lp at 3am
<JFo> that is probably when that crackhead put all those lists on Kernel-Bugs
<JFo> I remember seeing the e-mail
<cking> which crackhead?
<JFo> can't remember the guy's name now
<cking> annoying-mailing-list-dude?
<JFo> but there was someone creating all these lists and adding tons of others
<JFo> yeah :)
<JFo> so not a literal crackhead :)
<apw>  vanhoof  ubuntu-kernel-team  is a member of kernel-bugs
<apw> and i suspect you are an indirect member of that
<vanhoof> apw: right, but would that trump me being a subscriber?
<vanhoof> bugs i subscribe to are landing in kernel-bugs w/ that verbiage in them
 * vanhoof is puzzled
<bjf> is "kernel-bugs" a legitimate group or one the crackhead created?
<JFo> legitimate
<JFo> created by Brian Murray
<JFo> iirc
<JFo> been around a while
<bjf> well he's a crackhead :-)
<JFo> heh
<JFo> sigh*
<JFo> <-late lunch
<JFo> I have got to do better at looking at the time
<cking> #include <garbage.h>
<vanhoof> JFo-food: where did that email get sent?
<vanhoof> this is pissing me off :\
<JFo-food> vanhoof, what do you mean?
<JFo-food> Oh, Kernel-bugs... let me look
<JFo-food> vanhoof, when you look at https://launchpad.net/~kernel-bugs what does it say in the active members section?
<vanhoof> 62 active members
<vanhoof> You are a member of the team that owns this team. You are not currently an active membe
<Sarvatt> not a member here
<vanhoof> Sarvatt: those b43 updates went to kernel-bugs, even though im a subscriber
<vanhoof> Sarvatt: which is why i didnt see it :)
<JFo-food> so vanhoof you do or do not want mail from there?
<JFo-food> just so I understand
<JFo-food> Sarvatt, are you a member on https://launchpad.net/~ubuntu-kernel-team?
<Sarvatt> yeah I've been following, it's something you're in that i'm not. he doesn't want to be in it
<Sarvatt> nope!
<vanhoof> JFo-food: well ive been in it since june
<JFo-food> yeah, I see that
<JFo-food> Sarvatt, want to be? :)
<vanhoof> JFo-food: i left last night in an effort to fix mail
<JFo-food> hmm
<Sarvatt> not if it's going to screw my mail filters :)
<JFo-food> heh
<JFo-food> it shouldn't
<JFo-food> I don't see anything that would make me think something here is what hosed you vanhoof 
<vanhoof> ok
<vanhoof> here's an example:
<vanhoof> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663442
<ubot2> Launchpad bug 663442 in linux (Ubuntu Maverick) (and 1 other project) "S3 resume fails to restore video on Intel Sandybridge platforms (affects: 2) (heat: 127)" [Undecided,Fix committed]
<vanhoof> all that lands in kernel-bugs
<vanhoof> maybe i should have a few beers and search aruond :D
<JFo-food> what mail client are you using?
<vanhoof> tbird
<JFo-food> because there may be a duplicates handling issue at play here
<vanhoof> yeah good idea
<Sarvatt> JFo-food: do you have the mailing list as the team contact address list for the team maybe? I dont have that problem with X bugs I'm subscribed to while being subscribed to the ubuntu-x-swat list manually, I think we did that for this exact problem
<JFo> where do you mean Sarvatt?
<Sarvatt> (for kernel-bugs)
<JFo> no, that isn't my team.
<JFo> it has it's own e-mail address
<Sarvatt> https://launchpad.net/~kernel-bugs - change details - set contact details
<Sarvatt> oh ok, what a pain in the butt :)
<JFo> it has no contact e-mail address set
<JFo> yeah
<JFo> :)
<vanhoof> Sarvatt: do me a favor
<JFo> it does have a list that I am not subscribed to
<vanhoof> Sarvatt: update 663442 with something
<vanhoof> i want to watch procmail
<JFo> vanhoof, think it is the duplicate handling I mentioned?
<vanhoof> well im doing no filtering in thunderbird
<vanhoof> unless its server side duplication handling
<JFo> hmmm
<Sarvatt> vanhoof: done
<vanhoof> Sarvatt: k
 * vanhoof waits for mail
<Al_5> hi guys, I have a question about a bug that was solved with a patch, but that patch wasn't integrated upstream in the kernel. I know maybe this is not the appropriate place, but maybe someone could point me to the right direction :)
<vanhoof> Sarvatt: JFo here we go
<vanhoof> From bounces@canonical.com  Thu Nov 18 20:12:09 2010
<vanhoof>  Subject: [Bug 663442] Re: S3 resume fails to restore video on Intel
<vanhoof>   Folder: /home/vanhoof/af/autofolder					   5097
<vanhoof> autofolder: launchpad lpproj="kernel-bugs"
<vanhoof> autofolder: delivering message via dovecot to folder lp.kernel-bugs
<ubot2> Launchpad bug 663442 in linux (Ubuntu Maverick) (and 1 other project) "S3 resume fails to restore video on Intel Sandybridge platforms (affects: 2) (heat: 22)" [Undecided,Fix committed] https://launchpad.net/bugs/663442
<vanhoof> wtf ...
<JFo> very odd
<JFo> you said you were unsubscribed or never subbed to the kernel-bugs list yes?
<vanhoof> i unsubscribed last night
<JFo> ah
<JFo> may not have been done yet then
<JFo> (it is possible)
<JFo> try it again
<JFo> :)
<JFo> shades of reboot
<Al_5> this is the bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/278648?comments=all . until now I used a patched kernel, but this solution is not available in maverick.
<ubot2> Launchpad bug 278648 in linux-ubuntu-modules-2.6.24 (Ubuntu) (and 1 other project) "[regression]snd-hda-intel sound input does not work at all with Conexant CX20549 (Venice) chips (affects: 12) (dups: 1) (heat: 67)" [Undecided,New]
<vanhoof> lol
<vanhoof> i find it hillarious my email address is chris.van.hoof
<JFo> lol
<JFo> I didn't notice that
<vanhoof> i dont use it
<vanhoof> use the alias for in/out
<JFo> you should get it changed to chris.von.und.zu.hoof@
<JFo> :)
<vanhoof> X-Launchpad-Message-Rationale: Subscriber (linux in ubuntu) @kernel-bugs
<vanhoof> weird
<JFo> yeah, so no unsub processed
<JFo> did you try the unsubscribe again?
<JFo> oh wait a sec...
<vanhoof> i cant
<vanhoof> i can join/part it
<JFo> :-|
<vanhoof> JFo: just joined and left again
<vanhoof> we'll see :\
<JFo> k
<JFo> good luck
 * JFo is looking at something that could be related
<vanhoof> JFo: is there launchpad support? lol
<vanhoof> i tried #launchpad, no luck
 * vanhoof could just file a bug i guess
<JFo> dunno
<vanhoof> JFo: well thanks for looking for me
<JFo> I see that I am getting the e-mail from them, but I am not subscribed either
<JFo> hmmm
<JFo> vanhoof, my pleasure
<vanhoof> JFo: so you're seeing it too?
<JFo> wonder if you are getting them via the ubuntu-kernel-team 
<JFo> yea
<JFo> I see Robert's mail as the last one
<vanhoof> JFo: find a bug you're physically subscribed to
<vanhoof> see if its in the right place
<JFo> and apparently I have been getting them too since the 5th
<JFo> so it would seem I am in the same boat
<vanhoof> hmm
<Sarvatt> bryceh: are you around? what did you do to ubuntu-x-swat to make it stop doing what they're describing?
<vanhoof> JFo: too odd its on the 5th ...
<JFo> yeah
<Sarvatt> bryceh: tormod complained everyone on the team was subscribed to bug mail so you made a mailing list and let people opt in to the bug mail
<JFo> makes me think something is broken on the back end
<vanhoof> unless something was changed by accident
<vanhoof> but ive looked everywhere
<Sarvatt> everyone on kernel-bugs is getting bug mail looking at the mailing list subscriber list
<vanhoof> and if its impacting you ...
<vanhoof> Sarvatt: im not even in kernel-bugs anymoer and im getting it
<JFo> and I only see one subscriber to kernel-bugs e-mail
<JFo> huh, and it looks like the team mail list is deactivated on that page anyway
<JFo> from looking here: https://launchpad.net/~kernel-bugs/+mailinglist
<vanhoof> Sarvatt: where did that sandybridge email land for you?
<vanhoof> whats in the header under X-Launchpad-Message-Rationale
 * jjohansen lunches
<JFo> yeah, I dunno how/why we are getting this e-mail now. the mail list for kernel-bugs is deactivated
 * JFo sends a test e-mail to the list 
<JFo> sent
<JFo> got mail delivery failure to kernel-bugs@lists.launchpad.net
<JFo> so that isn't where it is coming from
<JFo> vanhoof, ^^
<JFo> found this though: https://lists.ubuntu.com/mailman/listinfo/kernel-bugs
<JFo> so that may be where it is coming from
<JFo> bdmurray, any idea why we are suddenly seeing e-mail from kernel-bugs since the 5th of November with no interaction from us?
<JFo> I tried to unsubscribe but I got Error: Illegal Email Address: Jeremy Foshee
<bryceh> Sarvatt, yeah
<JFo> ooh wait
<JFo> I think I may have figured it out vanhoof 
<bryceh> Sarvatt,  yeah by default teams are set up to send bug mail to all members
<bdmurray> JFo: can I see one of these emails with all the headers
<JFo> sure
 * vanhoof reads
<bryceh> I'm trying to remember exactly how it was done
<bryceh> I *think* I created a second team ${team}-bugs and set it as the bug contact for the team
<JFo> sent bdmurray 
<vanhoof> JFo: you figure something out?
<JFo> maybe vanhoof gimme a sec :)
<vanhoof> heh
<bdmurray> X-Launchpad-Message-Rationale: Subscriber (linux in ubuntu) @kernel-bugs
<bdmurray> the "kernel-bugs" team is subscribed to all linux bug reports
<bdmurray> however all the mail should go to the kernel-bugs mailing list
<JFo> right, but we only suddenly started getting e-mail on the 5th
<JFo> that seems odd
<vanhoof> and
<vanhoof> bugs im a direct subscriber on are only going to kernel-bugs
<vanhoof> with the same header you just posted
<JFo> how wound we individually unsubscribe if that was wanted bdmurray?
<bdmurray> This team's mailing list has been deactivated.
<JFo> right
<JFo> and yet we are getting e-mail
<JFo> :)
<bdmurray> well because it is deactivated it likely goes to the team members
<Sarvatt> did the mailing list get deactivated on the 5th?
<bdmurray> I thought the email address used to kernel-bugs@lists.ubuntu.com
<bryceh> aha, https://edge.launchpad.net/~ubuntu-x-swat/+contactaddress
<bryceh> by default the email notifications are set to go to 'Each member individually'.  You can set up a mailing list for the team and then direct the bug mail to go there instead.
<bryceh> then people can sub/unsub as appropriate
<vanhoof> check this out
<vanhoof> https://lists.ubuntu.com/archives/kernel-bugs/2010-November/thread.html
<JFo> bdmurray, I sent an unsubscribe through https://lists.ubuntu.com/mailman/listinfo/kernel-bugs but I have gotten nothing back yet
<vanhoof> Starting: Mon Nov 1 00:02:04 GMT 2010
<vanhoof> Ending: Fri Nov 5 05:15:12 GMT 2010
<bdmurray> JFo: I believe the team email address used to be k-bugs@lists.ubuntu.com and somebody changed it
<JFo> I am thoroughly confused now
<vanhoof> so perhaps it should be changed back to k-bugs@ ?
<bdmurray> I'd be happy to mumble about it
<bdmurray> well aside of the fact that I like the song I am listening too ;-)
<JFo> heh
<vanhoof> JFo: think we should change it?
<JFo> I just want the mail to go to the right place again.
<JFo> I don't care how we accomplish that
<JFo> :)
<bdmurray> I'll fix it then
<bdmurray> hmm, can't
<JFo> thank you bdmurray sorry to pull you into all of this
<JFo> uh oh
<bdmurray> anyway set team email to kernel-bugs@lists.ubuntu.com
<Al_5> hi, anyone wanting to look into that conexant problem? :)
<vanhoof> JFo: bdmurray thanks guys :)
 * vanhoof feels better about life now 
 * ogasawara lunch
<vanhoof> bdmurray: JFo: https://launchpad.net/~kernel-bugs ... didn't you just set this to the list?
<JFo> no, that mail list is deactivated
<JFo> list is @ubuntu.com
<vanhoof> Team details
<vanhoof> Email:
<vanhoof> No contact email Set contact address
<vanhoof> oh i see
<vanhoof> he said he cant do it
<vanhoof> JFo: want me to set it?
<JFo> no
<JFo> I'd ask pete about it as he is the penultimate owner
<vanhoof> JFo: right, i guess what im saying is that ntohing has been changed yet
<JFo> I have no idea
<JFo> all I do know is that nothing has changed
<JFo> still getting the e-mail I mean
<vanhoof> im still getting kernel-bugs
<kees> what's the tool to track disk access? it'll show each block and the process responsible... can't remember now
<kees> blktrace!
#ubuntu-kernel 2010-11-19
<Sarvatt> heads up that X is broken in 2.6.37-5 with kvm/vmware and on a ton of old UMS drivers until this commit comes in in case it comes up - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8c05cd08a7504b855c265263e84af61aabafa329
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/676759
<ubot2> Launchpad bug 676759 in linux (Ubuntu) "X fails to start in vmware/kvm and with various UMS drivers on 2.6.37-5 (affects: 3) (dups: 1) (heat: 20)" [High,Triaged]
<jk-> Sarvatt: ack
<kees> is anyone successfully using the natty kernel? I'm seeing really broken NFS with it (file locking appears hosed).
<lifeless> nfs locking hosed....
<lifeless> this is different somehow?
<kees> lifeless: yes. I've had no problems for years.
<RAOF> I'm using the natty kernel, but I don't use NFS.  Nothing seems to be more broken than usual.
<kees> I'll track it down tomorrow...
<kees> I bet this fixes NFS for me... http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8e35f8e7c61c88f9a979a4e6f7f4ffd4c158a88a
 * kees waits for -rc3
<kees> :)
<TheSarge> So what is the deal with the new patch?
<TheSarge> Are you guys gunna take the bashrc workaround instead?
<TheSarge> Hello?
<amitk> TheSarge: patience :) Most of the kernel team working on the Ubuntu distro kernel are in the European timezone - so they are probably stumbling around looking for coffee at the moment.
<amitk> (and US timezone)
<juniort> Hi I am new member here I just had posted on mailing list
<juniort> for doing some thing on the kernel front
<juniort> I am having a Laptop 
<juniort> and that is the only hardware available to me
<juniort> I have developed a character device driver recently
<juniort> and have been reading a lot of things related to 
<juniort> devices such as CMOS ,Network and etc etc
<juniort> so I wish if I can contribute to 
<juniort> the kernel development or bug fixing some way 
<juniort> so show me some way
<juniort> I am very interested for the wireless devices area
<juniort> but I do not have  hardware for that
<juniort> I have checked this page https://wiki.ubuntu.com/KernelTeam/BugTriage
<juniort> and also looked at this page https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
<juniort> I have also checked this page https://bugs.launchpad.net/ubuntu/+source/linux/+bugs
<juniort> let me know how can I start 
<juniort> working
<JeanPijon> Hello to all devs. Can someone please tell me, if there will be enabled again OSS emu sometime in the future in the stock kernel? 
<diwic> JeanPijon, that is unlikely
<joaopinto> JeanPijon, you probably want to follow https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300
<ubot2> Launchpad bug 579300 in linux (Ubuntu) "Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS* (affects: 19) (heat: 130)" [Wishlist,Fix committed]
<JeanPijon> joaopinto: I have read this, so there won't be stock kernel with this feature enabled?
<joaopinto> that is what looks from the bug reading
<joaopinto> it was one of those hard changes
<JeanPijon> joaopinto: I see, but there will be probably problems with many applications (such as MythTV)... and it results 
<diwic> JeanPijon, how come that MythTV does not support ALSA?
<joaopinto> diwic, from the bug report, "It turns out this OSS garbage is responsible for my (cx8801) TV tuner cards' being able to capture audio from analog cable."
<JeanPijon> joaopinto, diwic, so it results to the way NOT to update any kernel, until those applications will be rewrited:(
<diwic> joaopinto, so is it the hardware or the software that does not support ALSA?
<diwic> joaopinto, googling both MythTV and CX8801 it seems like there is support for ALSA on both sides.
<diwic> JeanPijon, or help us fix the problems with ALSA
<JeanPijon> diwic: Sure, but I don't think I am the right person to code the kernel:(
<diwic> JeanPijon, you can at least file bugs for your issues and help out with testing if we come up with a fix
<JeanPijon> diwic: Absolutely right, I will try, but again, there is no possibility for now, except to recompile own kernel with that modules enabled...
<apw> smb, whats the status of: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669496
<ubot2> Launchpad bug 669496 in linux (Ubuntu) "natty kernel fails to mount root on ec2 (affects: 1) (heat: 210)" [Critical,Confirmed]
<apw> smb, seems it is on the release meeting agenda
<smb> apw, It seems to affect only i386 and amd64 with t1.micro. Unfortunately when it fails it usually gives no logs at all. jj had captured some but I have to check whether he attached them to the bug
<jtapas> Hi on this thread https://lists.ubuntu.com/archives/kernel-team/2010-November/013541.html I was suggested to join this IRC
<apw> jtapas, hi you are interested in helping with kernely things i think
<apw> this is the place where all those interested in ubuntu kernely things hang out
<apw> so you are in the right place
<apw> smb, ok so i'll write that up as a limited exposure and testing still possible, investigation continuing
<smb> apw, sounds good to me. I am just now updating the bug as well with that facts
<jtapas> yes
<jtapas> @apw
<jtapas> yes I am interested in developing or doing kernely things
<apw> jtapas, so i guess the question is what sort of things are you interested.  we have lots going on
<jtapas>  I like network sort of things
<smb> I believe he mentioneed wireless
<apw> ranging from initial triage of bugs through to patching and upstreaming patches
<jtapas> ya
<jtapas> wireless is one thing that does fascinates me
<jtapas> the only hardware I have is 
<jtapas> my laptop
<apw> ok well if you are interested those kinds of things then i think we do tag bugs which are related to that
<jtapas> ok
<apw> is it kernel-wireless ?  i forget exactly
<smb> jtapas, This is not uncommon when looking at bugs
<smb> We rarely have the hardware ourselves
<apw> you might want to have a poke about in those and see what you can help wil
<apw> with ...
<apw> cirtainly one learns a lot about a thing by looking at the bugs there
<jtapas> I do not know if i am right or wrong but I feel that to have a fix or
<jtapas> driver u need to have that hardware
<jtapas> is that not the case
<smb> This is where talking to people comes into play. :)
<jtapas> ok
<jtapas> so how can I start with
<jtapas> let me know reading and reading books I have cooked myself too much
<jtapas> I want to actually do some real work
<jtapas> which u people enjoy doing
<smb> jtapas, JFo is our "master triager" sort of. So he would know a bunch of reports grouped for people wanting to help
<jtapas> ok JFo is it a human
<smb> Sometimes yes and no
<smb> He tends to run his scripts in his name but he is a human too
<jtapas> so u mean to say that I should contact him
<jtapas> is he on this IRC
<apw> yeah jfo looks after our incoming bugs, and helps us find the interesting ones. he is normally here
<smb> Right, he will be here on irc too
<apw> hrm, but not at the moment
<jtapas> Ok when can I expect him generally 
<jtapas> UTC time I will be online at that time
<smb> apw Still relatively soon in the morning his place
<apw> smb, its 9:30 his time, not so early
<smb> But more or less soonish. Depenends on the human factor
<smb> apw, Maybe he was able to sleep for a change
<apw> yeah maybe, that guy needs to relax
<jtapas> my time zone is +0530 of UTC r u referring to UTC time at 09:30
<apw> jtapas, he is east coast US, so i am guessing your are similar
<smb> jtapas, It is 9:30 where he is
<smb> So thats 14:30 UTC
<jtapas> ok
<apw> 'about now' :)
<jtapas> ya :)
 * apw incants to try and raise him
<apw> jFo, JFo, Jfo ...
<apw> man it worked for bloody mary on the tv last night
<jtapas> Ok then I shall wait for the guy to let me understand where to start
<apw> the other place to look is in our Kernel wiki, that has lots of information on how we do things
<apw> https://wiki.ubuntu.com/Kernel/
<jtapas> ya I had looked that page also
<apw> the stuff on trige would help you understand what the status of bugs means etc
<apw> and on the tagging page you should find the lists of tags we use to mark bugs
<jtapas> ok
<jtapas> are you referring to this page https://wiki.ubuntu.com/Kernel/BugTriage
<jtapas> I see a lot of bugs here https://bugs.launchpad.net/ubuntu/+source/linux/+bugs
<jtapas> but if I pick one and start doing some thing then that would not be heading to any direction
<jtapas> since I never fixed any bug till today in my life
<jtapas> though I wrote a char driver
<apw> jtapas, working at the distro level generally involves digging into peoples issues, and trying to help them
<jtapas> and at kernel level
<apw> the other place people help is with askubuntu, which helps with things including onfiguration and usage issues
<jtapas> how did u people started fixing such kernel bugs
<jtapas> since all here are developers so I believe
<jtapas> some where u must have started
<jtapas> I will follow the same
<jtapas> it might take time
<jtapas> but I feel I will be able to do it with some patience and practise
<apw> yep, i just dug into the bug list, picking out bugs I knew things about, using the source of the kernel to help understanding them and trying to fix
<jtapas> currently I am not clear
<jtapas> and how much time it took u to fix the first bug
<apw> so as you like networking i would look at some in gneeral networking perhaps as you can fix those
<jtapas> ok
<apw> i think i fixed a few in my first week, but i was working on it full time
<jtapas> ohh I see
<apw> a lot of the time you find the issue is already fixed in much newer kernels
<jtapas> hmmm
<jtapas> did u had the devices for which u fixed the bugs
<apw> so one can use that information to pull back the fix, or to do the equivalent
<jtapas> Ok
<apw> often we ask people to try newer kernels and mainline kernels from the mainline kernel archive
<apw> to see if later kernels have a fix
<jtapas> r u referring to vanilla kernel from kernel.org
<jtapas> or the one from ubuntu repositories
<apw> jtapas, yes we build those installable for ubuntu systems every day
<apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
<jtapas> ok
<apw> those are made automatically as they release, and we use those as a debugging resource
<jtapas> ok
<jtapas> let me read that doc
<jtapas> I will get back here once I read it
<jtapas> ok what I understand from the link of MainlineBuilds is u apply Ubuntu specific patches to kernel which is on www.kernel.org and test
<jtapas> if those patches work
<jtapas> or not
<jtapas> is that correct
<apw> jtapas, no those kernels have our _config_ only applies
<apw> they are useful to know if the ubuntu patches are causing an issue
<jtapas> I did not get that
<jtapas> why do u test your config 
<jtapas> are u referring to the config file in arch subdirectory
<apw> well a distro needs cirtain things turned on to be useful
<jtapas> ok
<apw> so we build with the ubuntu config to make sure the kernels are likely to be usable on an ubuntu root
<jtapas> ok
<jtapas> so let me know if this time I understand :u take a kernel from kernel.org and 
<jtapas> give ur default config
<jtapas> and test if it works for ubuntu
<jtapas> if that is the case then I am curious to understand why do u do that
<jtapas> does the kernel from kernel.org not work for Ubuntu
<apw> the ubuntu kernel includes fixes for various things
<apw> sometimes those things fix the person they are intended for, but break someone else
<apw> so sometimes a failure can be related to a fix we carry above and beyond the base point
<jtapas> these are ubuntu kernels?
<jtapas> ok
<apw> the mainline kernels are mainline virgin trees, configured for ubuntu
<jtapas> ok
<apw> used as testing points.  they allow testing without our patches, and on newer versions than our stock kernels
<apw> both are useful
<jtapas> ok
<jtapas> on that page it is mentioned u built 4 sets 
<jtapas> of kernels
<jtapas> 2 from Linus's tree and
<jtapas> 2 from DRM
<jtapas> what  is the difference between the two
<jtapas> are these both different kernels
<jtapas> I have compiled kernels in past
<jtapas> but I never came across such thing
<jtapas> Linus's tree and DRM
<jtapas> development repositories
<apw> linus tree is the master upstream repository
<apw> from that we build each release he does (ie each tag) and we also build a random daily
<apw> snapshot, ie whatever is in the tree at 10am UTC every day
<apw> the other two are maintainer trees for sub-systems we care about a lot
<apw> in this case two graphics trees.  they contain stuff likely to be in the next release from linus, but before he gets them
<apw> so we can see if there is anything coming which may help us
<jtapas> ok
<jtapas> I checked this page https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
<jtapas> the laptop I have I use it in my work place also
<jtapas> if I try these new kernels and bug fixing on
<jtapas> a virtual machine would that be fine
<jtapas> or I need do all on the bare metal
<apw> jtapas, some of us do testing in VMs too
<apw> specially in early cycle like now when the release is not very stable
<jtapas> ok
<jtapas> since I am new also so I will take some time to understand all this but I am happy that at least I am heading in some direction
<jtapas> you mentioned above in coversation ubuntu specific __config_ files
<jtapas> applied to mainline kernel so can you give me 
<jtapas> link to those configurations which exactly you are pointing to
<jtapas> I want to see what is ubuntu specific __config_ in Ubuntu's situation and how is it
<jtapas> different from the mainline kernels config files
<ogasawara> smb: thanks for testing Dapper
<smb> ogasawara, No problem, its installed so its not much effort
<apw> http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.html
<apw> cking, ^^
<apw> tgardner, i have a couple of config changes i want to put in the same one
<tgardner> apw, you have time to roll it? you're nearing EOD.
<apw> yeah no problem
<tgardner> take it away...
 * ogasawara bails for appt, back in a bit
<smb> sconklin, bjf Pushed and uploaded a lucid-ec2 package which is rebased to the phase2 lucid kernel
<smb> jjohansen, And btw realized that there is nothing to do for Maverick \o/
<bjf> smb, thanks though i have no idea what the "phase2 lucid kernel" is
<smb> bjf, The one you have currently in proposed and has the reverts. Hey I am just using your new wording. ;-P Or is that phase 0 and 1? ;-)
<tgardner> smb, oh, crack week v.s. stable week
<JFo> apw, want to plan a chat on Monday (morning for me)?
<apw> JFo, can do
<JFo> cool
<apw> ping me when you get in
<JFo> will do
<smb> tgardner, Yes
<sconklin> tgardner: verification kernel vs. testing kernel.
<smb> sconklin, I think that is the same with less opinion
<jtapas> JFo I was suggested you are "master triager" sort of here ,I am some one who wants to contribute to bug fixing etc on wireless area and kernely things on Ubuntu can u say some thing about this I had been waiting for you to come online
<JFo> hey, sure
<JFo> sorry about that. Sometimes I don't realize IRC isn't up for a while(happens often in the AM) :)
<JFo> any specific portion of the kernel interest you jtapas?
<jtapas> I want to do some thing on wireless area also I was looking at many links
<jtapas> https://blueprints.launchpad.net/ubuntu/+spec/cloud-server-n-ec2-cluster-compute
<jtapas> and the above link seemed interesting to me
<jtapas> though not sure as what I can contribute at this point of time
<jtapas> wireless does appeal me
<JFo> no problem, there are many ways to contribute
<JFo> excellent
 * JFo looks at the BP
<jtapas> I want to do bug fixing 
<jtapas> on such areas
<JFo> excellent! I am happy to have you here then :)
<jtapas> yea :) but I am just beginner and it will take me time
<jtapas> to understand things and then to be able to 
<jtapas> actually contribute some thing worth
<jtapas> may take time
<jtapas> I am a bit slow learner
<JFo> smb is our kernel server liason and jjohansen to a degree, so they will have the most info on that relationship
<JFo> that's ok
<jtapas> ok
<JFo> those things worth doing sometimes take time :)
<jtapas> ok
<smb> This blueprint is about images for amazon ec2, nothing wireless there
<jtapas> so I have been reading  lot of wiki pages here
<jtapas> on Ubuntu kernel pages
<JFo> excellent
<JFo> smb, yeah
<smb> In general I don't think blueprints are a place to start when one wants to do bugs
<jtapas> ok
<JFo> I agree
<JFo> but that is ok
<JFo> we can look at some bugs :)
<jtapas> yea
<jtapas> I did had looked the Kernel Wireless page
<jtapas> but that redirects outside
<jtapas> the Ubuntu domain
<jtapas> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
<jtapas> to the above page
<JFo> jtapas, have you looked at the Triage pages found here:https://wiki.ubuntu.com/Kernel/BugTriage ?
<jtapas> yes
<jtapas> I did looked and the mail 
<JFo> excellent
<jtapas> also in which the questions were answered
<jtapas> I want to start with some thing easy
<JFo> ok
<jtapas> that will take me some time to understand
<JFo> hmm
<jtapas> so if you think you can give me one such bug I want to
<JFo> let me see...
 * smb thinks wireless and easy are slightly orthogonal. But that is just my opinion
<jtapas> ok
<JFo> are you wanting to learn about how wireless works in the kernel or try to help with wireless misconfiguration on bugs?
<JFo> I would agree with smb
<jtapas> I want to do some thing kernely
<jtapas> and wireless seemed promising to me
<jtapas> so I asked
<JFo> by that you mean development?
<jtapas> ya
<jtapas> exactly
<JFo> ok
<JFo> let me see...
<JFo> so, in order to ensure we are all on the same page...
<JFo> I just wanted to mention that 'wireless' really covers a lot of ground
<jtapas> ok
<JFo> and is mainly handled by the modules themselves that are created and provided by outside companies
<jtapas> ohh
<jtapas> it is not some thing specific to Ubuntu
<JFo> smb, correct me anywhere here if you see that I am wrong
<JFo> jtapas, no, it is specific to the overall kernel itself
<jtapas> ok
<JFo> and is different in each of the modules
<jtapas> ok
<JFo> hence my question about whether you wanted that or helping to fix misconfiguration etc.
<jtapas> I do want that 
<jtapas> development
<jtapas> it may take time for me to understand
<jtapas> but do not worry about that part
<JFo> In many cases (those that we have the most issues with) the driver  is messy
<jtapas> ok
<JFo> I'm not worried :)
<JFo> I just want to give you the best information
<jtapas> ok :) u mean messy to misconfiguration
<jtapas> ya ya right
<JFo> and point you in the right direction
<jtapas> ok
<JFo> well, that and the code is very questionable in some cases
<jtapas> ok
<JFo> meaning that over time they have done things to make bits work that didn't improve the overall quality of the code
<JFo> not that they are bad
<jtapas> ok
<jtapas> ok
<JFo> just that many of them would require a rewrite to be improved
<JFo> which is a major undertaking
<jtapas> ya that will be a good start
<JFo> but I digress
<jtapas> ok
<JFo> so, the kernel handles pretty much all modules it loads the same
<jtapas> ok
<phetips> can anyone tell me why this is happening when i try to load my module? http://pastebin.com/55dBXeKE
<JFo> the difference is to do with what the module does or controls
<phetips> module source: http://pastebin.com/asn5Bt9p
<phetips> makefile: http://pastebin.com/30c5WLHU
<jtapas> ok
<JFo> but it is not entirely that simple either
<vanhoof> JFo: btw, it has to be that ~kernel-bugs had its list removed.  I just removed myself from ~u-k-t, and what'dya know, everything works again
<jtapas> ok
<JFo> vanhoof, hmmm
<JFo> but you had to remove yourself from u-kt though
<JFo> sounds odd
<vanhoof> JFo: i think i found that 'crackhead' stuff you mentioned, which also happened on the 5th
<JFo> jtapas, give me one sec to check something
<jtapas> ok
<JFo> vanhoof, yeah, I think something there is what did it
<vanhoof> I see that in my 'Indirect' folder
<vanhoof> Vishnu (vishnuvishnu.2012) added Kernel Bugs (kernel-bugs) (which you
<vanhoof> are a member of) as a member of sljdg (hjgf). <https://launchpad.net/~hjgf>
<JFo> yep, that's the stuff
<vanhoof> all on the 5th
<phetips> i keep getting the following when trying to build my module: WARNING: "kallsyms_lookup_name" [/home/daan/Code/Phrack/phrack.ko] undefined!
<JFo> looks like someone was trying to escalate privilege in the groups
<phetips> and this when trying to load it: Unknown symbol kallsyms_lookup_name
<JFo> may have succeeded
<phetips> i am pretty sure i included the right header (linux/kallsyms.h)
<phetips> and my kernel also exports the symbol
<JFo> bdmurray, I'm still getting the mail. Any ideas?
<vanhoof> JFo: ~k-bugs was never set to the list
<vanhoof> JFo: i dont think bdmurray can set it
<JFo> I just want to know where it is suddenly coming from and nuke whatever that is
<JFo> :)
<bdmurray> And I'm telling you set the email address for the team to k-bugs
<bdmurray> I can't do it since I'm not in ubuntu-kernel-team - they are the owner of kernel-bugs
<JFo> bdmurray, k-bugs@l-u-c?
<JFo> oh ok
<JFo> sorry, that must have been after my brain scramble yesterday
<bdmurray> yes, set the email address to kernel-bugs@lists.ubuntu.com
<JFo> k, done
<JFo> but apparently there is a confirmation sent
<JFo> and I am not subscribed to the list
<JFo> wonder how that will work out :)
<JFo> ok, moving on
<JFo> jtapas, apologies
<jtapas> no problem
<JFo> so, it is not entirely as simple as generically handling modules
<jtapas> what I understand from ur conversation till now is
<jtapas> to be able to start some where
<jtapas> this will be a good warm up
<JFo> I think so, ye
<JFo> err yes
<jtapas> that way when I jump to actual bug fix etc
<jtapas> I will be able to do some thing
<JFo> indeed
<jtapas> so that is fine with me
<jtapas> even I want to start with some thing that I can at this point understand
<jtapas> this is a time consuming process and needs
<jtapas> practise I feel
<JFo> and once you get the idea of the scope of the bugs, you will have a better understanding of the wireless modules once you start looking at them from a dev standpoint
<jtapas> so do give any link
<jtapas> right
<jtapas> so go ahead and give links which you feel I should be starting 
<jtapas> at least I begin some where
<JFo> so here are the bugs that I have tagged kernel-net already: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=kernel-net
<JFo> those bugs should be a good place to look for bugs about networking and wireless
<jtapas> ok
<JFo> sorry, got pinged in another channel
<jtapas> just one question I was looking at this page
<jtapas> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tags_combinator=ALL&field.tag=kernel-net+kernel-needs-review
<JFo> :)
<jtapas> what is the difference between the link you gave and I gave
<JFo> right, that is probably going to become obsolete
<JFo> that is the list of bugs up for review by the team in my weekly bug meeting
<jtapas> ok
<JFo> but we are changing what we look at 
<jtapas> ok
<JFo> so that will probably go away
<jtapas> so the link which you gave needs improvement in quality of code
<jtapas> the way it is written is not very well as I understand this
<jtapas> from this conversation
<JFo> jtapas, no. The link I gave are just the bugs I have tagged as relating to kernel-networking
<jtapas> ok
<jtapas> ok
<JFo> they are for all types of net bugs
<jtapas> ok
<JFo> some are things we can fix, some are not
<jtapas> ok
<JFo> but in all cases there is a minimum amount of information needed before the bug is ready to be looked over
<JFo> and to be fair, some will never get looked at
<jtapas> ok
<JFo> there are over 6,000 bugs filed on the kernel
<JFo> and there is a team of less than 20 people
<JFo> so you see where the math is going
<jtapas> oh 
<jtapas> right
<JFo> I think the best thing for you would be to start in that list I gave you
<jtapas> ok
<jtapas> do I need to mail on the lis
<jtapas> t
<JFo> and begin to understand the problems these reporters are encountering
<jtapas> ok
<JFo> mail on the list for what?
<JFo> I didn't understand thatr
<jtapas> wait
<JFo> k
<jtapas> I forgot the link
<JFo> :)
<jtapas> let me get back I am searching
<JFo> ok
<JFo> vanhoof, I had to subscribe to the team list. I am now trying to change the team e-mail
<JFo> :-/
<JFo> vanhoof, will let you kow how it goes
<jtapas> this is the link I was talking about https://lists.launchpad.net/ubuntu-bugcontrol/msg00715.html
<jtapas> I got above from here https://wiki.ubuntu.com/UbuntuBugControl
<jtapas> with a sentence Application from Yofel
<jtapas> do I need to do a similar mail
<JFo> jtapas, ah, that is the bug control team. You can only become a member of that once your basic triaging skills have been verified
<jtapas> ok
<vanhoof> JFo: cool man
<jtapas> for that I need to download understand and commit changes
<JFo> so there must be a body of work in order to review what you have done and your understanding of the policies
<jtapas> ya ya right
<JFo> jtapas, no
<jtapas> then
<JFo> for that you need to triage bugs for the developers ofr a while
<JFo> and then submit an application
<JFo> via e-mail to become bug control
<jtapas> I think that would come at a later part once I start understanding such stuff
<jtapas> and be able to deliver some thing
<JFo> yes, so you see there are several steps before you can start committing changes to code
<jtapas> ok so suppose I choose one bug
<JFo> and I think looking over those bugs is the best start
<jtapas> I do not have the hardware for that
<jtapas> and I need to pull down the kernel 
<jtapas> and start understanding the bug
<jtapas> and make some changes is this how the process will work
<JFo> no
<JFo> first, you look here https://wiki.ubuntu.com/Bugs/HowToTriage
<JFo> next you look at those bugs on the link I gave you
<jtapas> ok
<JFo> and get them to a good triaged state that can be worked from
<jtapas> oohh okk
<JFo> once you have done that for a bit
<jtapas> I was confused about this part only
<JFo> then you can go for Bug Control
<jtapas> ok that makes it clear
<JFo> but the main thing here is that you get an idea of the issues that are being reported
<JFo> before you start looking at code... or even while you are looking at code so that you understand
<jtapas> ya ya that I am doing
<jtapas>  I was reading I2C protocol
<jtapas> and related drivers today 
<jtapas>  I had looked at many other sort of drivers
<JFo> if you see something you think you can fix, you can submit a patch to the kernel mailing list for a review
<jtapas> ok
<jtapas> right
<JFo> but understand
<jtapas> ok
<JFo> if you want to do fixes on those systems, you will need to understand and use the upstream patch submission process 
<JFo> because we pull the vast majority of our fixes from upstream
<JFo> meaning Linus and the maintainers
<JFo> via the stable tree
<jtapas> Ok
<JFo> as maintained by Greg K-H
<JFo> so, what I want to do
<JFo> is give you the data to begin understanding these bugs
<jtapas> ok
<rtg__> bjf, do you keep your email sent folder? If so, look for "ALSA: HDA: Apply SKU override for Acer aspire 7736z"
<JFo> so that when you begin submitting patches, you will have the best information
<jtapas> ok
<JFo> make sense?
<bjf> rtg__, i do and that is not in my sent folder
<JFo> jtapas, does that make sense?
<rtg__> bjf, hmm, I distinctly remember you complaining to David that his second patch did not apply (but that was back in October)
<bjf> rtg__, i remember that as well, let me look
<jtapas> hi sorry I was copying the text
<jtapas> of chat 
<jtapas> from beginning yes that makes sense
<JFo> heh
<bjf> rtg__, the title is "Acer aspire 7736 - Playback not working"
<JFo> good idea
<rtg__> bjf, ah, cool. I was searching on the wrong subject
<jtapas> JFo I was making a backup of the links u gave and conversation to look back
<JFo> great idea
<jtapas> I am clear with this and I will get back here 
<jtapas> let me see what I can do
<JFo> ok
<jtapas> thnkx for the information
<bjf> rtg__, looks like you applied it
<JFo> jtapas, my pleasure
<JFo> I am normally here, unless I have forgotten to open my IRC client after an update reboot like last night :)
<JFo> so feel free to stop in and ask questions jtapas :)
<rtg__> bjf, yes, but sconklin  was hassling me about missing Acked-by....
<JFo> heh
<JFo> that sconklin, what a harsh taskmaster
<JFo> :-P
<bjf> rtg__, so do you know if this patch was tested by diwic against maverick
<JFo> grabbin lunch, bbiab
<sconklin> JFo: I am a quick student
<JFo> sconklin, :-D
<rtg__> bjf, one wouls assume, but I guess that'll shake out during verification week.
<jtapas> sure thanks JFo I have been poking into kernel and drivers
<rtg__> sconklin, updated Maverick master-next.
<jtapas> from some time
<sconklin> rtg__: thanks
<jtapas> the idea to actually start some thing came recently
<jtapas> and I do want to do some thing 
<jtapas> like if some one opens a driver file 
<jtapas> then I see peoples email id mentioned in that I wish I can be one of those :)
<jtapas> it is very appealing and I did not knew
<jtapas> that an OS as Ubuntu which is highly popular
<jtapas> has only 20 people in their kernel bug fixing team
<rtg__> JFo, whats with all these initramfs-tools bugs? Are they asa result of that udev regression?
<JFo> rtg__, no idea, but I will look 
<rtg__> JFo, there appear to be dozens of them.
<JFo> what is the udev regression? got a bug link?
<JFo> I'll compare the behavior in them to that
<rtg__> JFo, dunno. maximilian attems has been telling most of the folks with this bug that their disk is full. I'm having a hard time buying that.
<JFo> yeah
<smb> rtg__, Are those kind of the failed to boot after upgrade because the initrd is bad?
<rtg__> smb, https://bugs.launchpad.net/bugs/572083
<ubot2> Launchpad bug 572083 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 failed to install/upgrade: (affects: 1) (heat: 6)" [Undecided,Invalid]
<smb> would help if most of the message was *not* is Russian
<JFo> one of them is in spanish
<JFo> which isn't AS bad
<JFo> but still
<rtg__> smb, how about https://bugs.launchpad.net/bugs/577205
<ubot2> Launchpad bug 577205 in initramfs-tools (Ubuntu) "package initramfs-tools 0.92bubuntu78 failed to install/upgrade: (affects: 1) (heat: 15)" [Undecided,New]
<JFo> my spanish is old
<smb> rtg__, Though some people tend to have /boot as a separate small partition
<smb> and having lots of abi bumps tends to fill that
<rtg__> but that many? I've seen him reply to dozens of folks like that over the last several days.
<smb> Its probably visible in the install log .gz which I have not looked into
<JFo> rtg__, that last one was opened in May
<smb> And we may just have reached a critical / common level of multiple kernels
<rtg__> JFo, why haven't they been expired if they're that old?
<smb> the computer janitor would bring you down to 4 but its not automatic
<JFo> rtg__, I suspect due to them not having been properly triaged
<JFo> I have not looked at anything other than linux bugs for a while
<JFo> which reminds me... we need to nail down the list of packages you guys want me to report on/triage
<JFo> so that I am working the right ones
<JFo> I think I am missing some (like this one)
<rtg__> JFo, we don't own this one. I just thought it was interesting that there were so many reports.
<JFo> ah
<JFo> whew, thought I was failing you guys :)
<JFo> well failing worse than normal that is
<Nafallo> hmm. have we got any reports of bluetooth disappearing with the latest kernel?
<rtg__> JFo, how can I get a list of bugs with patches attached? Preferably for bugs that are not fix-committed, etc.
 * Nafallo bets it's just his hardware being old and grumpy.
 * smb -> EOW
 * JFo looks
<JFo> rtg__, see if http://goo.gl/TpbSJ meets your needs
<rtg__> JFo, yeah, looks good. thanks.
<JFo> my pleasure
 * rtg__ lunches
 * cking calls it a day
<rafiyr> How hard is it to disable a specific acpi gpe interrupt from the boot command line?
<JFo> rafiyr, I'd ask cking, but he is gone for the day
<rafiyr> JFo: Thanks
 * ogasawara lunch
<JFo> rafiyr, my pleasure
<julius__> hi
<julius__> is thre any reason why theres still the outdated rt2870sta staging driver?
<julius__> its from 2008 i think v 2.1.0.0
<julius__> the new one from ralink site is 2.4.0.1
<julius__> from 2010
<julius__> it improves the wireless reliability and speed a lot
<kees> apw, tgardner: if you're going to do another natty kernel publication before -rc3, can you include 8e35f8e7c61c88f9a979a4e6f7f4ffd4c158a88a ? This seems to fix my NFS regressions.
<kees> (I will send email too)
<tgardner>  kees - its already upstream, right? I'm pretty sure apw will rebase against current tip
<kees> tgardner: yeah, it's already in linus's tree. I just wasn't sure what your schedule was for publishing to natty
<tgardner> kees - he was thinking about rolling a version to fix a KVM regression
<kees> works for me :)
<komputes> Hi kernel folks, I am trying to patch the 2.6.32-25 kernel with Mike Galbraith's recent sched patch, but I need some help with rejected hunks
<komputes> JFo: ^ you free to assist?
 * jjohansen lunches
<komputes> I will try with a newer kernel
<komputes> later y'all
#ubuntu-kernel 2010-11-20
<tgardner> ogasawara, only you could drive tangerine that hard: 01:43:00 up  1:10,  2 users,  load average: 367.39, 246.65, 212.55
<tgardner> I'm gonna backport that galbraith patch just for this :)
<blahsphemer> I have kernel hacking experience in FreeBSD (implementing my own scheduling algorithm, page replacement algorithm). Are there any internship opportunities in ubuntu
<JanC> blahsphemer: I don't know about internships, but Canonical are looking for several kernel engineers it seems
<JanC> http://www.canonical.com/about-canonical/careers
<blahsphemer> JanC, great, thanks. I'll look it up.
<JanC> blahsphemer: if you are a FreeBSD developer(?) do you happen to know Philip Paeps?  ;)
<blahsphemer> JanC, I know nobody in FreeBSD, I did all those uber-daunting projects as a part of my grad course ;)
<blahsphemer> what is philip paeps's irc nick?
<JanC> I think currently it's trouble
<blahsphemer> heh, no i haven't talked to him
<JanC> not sure he uses that in freebsd channels too, not sure how active he is in freebsd nowadays
<blahsphemer> I am active generally on the freebsd hackers channel, not on the freebsd channel
<blahsphemer> JanC, Could you suggest some other company where I could apply for an intern with this kinda knowledge?
<blahsphemer> I don't even know what to google for
<blahsphemer> :(
#ubuntu-kernel 2010-11-21
<kees> what's the kernel magic that replaces code at boot-time? like for the smp vs uniproc code? I can't find it at the moment...
<devaj> Hi, could anyone help me with kernel upgrade
<devaj> I am trying to upgrade the kernel from here : http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-maverick/
<devaj> The problem is I don't understand what the patch stands for (in terms of kernel upgrade)
<devaj> and if they are of importance how do I apply it
<devaj> or is the kernel already patched
<hrw|conf> hi
<hrw|conf> I am plying with ubuntuization of kernel for one of my machines (unsupported by ubuntu) and have a problem with ABI check
<blahsphemer> Could someone please give a kernel-level project idea for ubuntu
<blahsphemer> I'd like to contribute in the kernel development
<blahsphemer> like I said earlier(about a day or two) I have kernel hacking experience in FreeBSD like implementing my own process scheduling algorithm, page replacement algorithm
<RAOF> blahsphemer: What sort of project are you after?
<blahsphemer> RAOF, I really can't define anything specifically cuz I. 
<blahsphemer> am onl starting out now
<blahsphemer> *only
<blahsphemer> I'd like to work only on the kernel though
<RAOF> Well, generally the plan would be to find something that you want to work and make it work.
<RAOF> I'd quite like someone to play around in the input subsystem (the /dev/input/event* nodes) to change their behaviour from multicast to all open fds to unicast to one open fd + an ioctl to switch which fd gets the input :)
<blahsphemer> RAOF, sorry, I didn't see your post cuz it wasn't highlighted. 
<RAOF> No problem :)
<blahsphemer> RAOF, quite frankly, I followed nothing after the work 'behaviour'
<RAOF> Heh.
<RAOF> So, currently, every open fd of /dev/input/event* gets all input from that device.
<RAOF> It would be useful if it were possible to restrict it so that exactly one open fd got the input, and there was an ioctl to switch which fd is currently getting input.
<RAOF> Does that make more sense?
<blahsphemer> fd?
<RAOF> File descriptor
<blahsphemer> aaah
<blahsphemer> now it makes sense
<blahsphemer> Jesus
<RAOF> Sorry, I thought that terminology would be shared with the BSD kernels. :)
<blahsphemer> I have only heard the full term being thrown around, no acronyms. My bad.
<RAOF> blahsphemer: I've not investigated that code at all, but it seems like it should be relatively easy to do.  And quite useful :)
<blahsphemer> RAOF, Sounds great. I am googling some basic stuff about it. Could you point me to some link, just so that I get to the point directly instead of skimming through bad results
<RAOF> blahsphemer: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/evdev.c;hb=HEAD is the evdev code which would need to be modified.
<blahsphemer> Good lord, that was lightning fast considering the fact that you said you haven;t looked through the code
<blahsphemer> ;)
<RAOF> I knew evdev was what you were after; drivers/input/evdev.c is a pretty obvious guess after that :)
<blahsphemer> heh
<blahsphemer> RAOF, Do you think this would be of any use: http://www.opengroup.org/onlinepubs/9699939699/toc.pdf
<blahsphemer> I have no idea about fd's. So I thought I must get my basics right
<RAOF> blahsphemer: That's probably not going to be a whole lot of use; it's only indirectly relevant.
<bryceh> good morning RAOF
<RAOF> Good eventide bryceh 
<blahsphemer> okay. But is there some sorta write up and not the 'code' itself where I can gather the fundamentals before I could land my hands upon the kernel
<blahsphemer> I hope you get what I am trying to say
<RAOF> Yeah, I do.
<blahsphemer> I am reading the wiki article right now. If you'd like me to read some text (book or web article) I'd be glad
<bryceh> blahsphemer, there's a lot of books published with kernel hacking fundamentals, which are in various states of semi-obsolescence, many of which can also be found online
<RAOF> www.xml.com/ldd/chapter/book/ch03.html is a somewhat out of date primer on char devices.
<bryceh> blahsphemer, you might also want to peruse the "kernel janitor's todo list" which has some simpler tasks if you're looking for smallish starter projects
<blahsphemer> bryceh, I wanna hit and I wanna hit hard ;) the fd thing sounds fun
<bryceh> RAOF, very kind of you not to hoodwink him into implementing 8xx kms support ;-)
 * blahsphemer struggles to comprehend the complexity in whatever bryceh just said :)
<RAOF> bryceh: That's slowly coming along; if I'm reading intel-gfx right, the rewriting of AGP and gem might land in the next couple of kernels :)
<bryceh> RAOF, huh well I'll count chickens later
<RAOF> Maybe the kernel support will be there before the all silicon is broken by electron-migration ;)
<blahsphemer> Funny thing is that my OS professor specifically asked us not to involve ourselves in any sorta device driver development 
<blahsphemer> cuz according to him we'd be stuck there for our entire life
<bryceh> my bed is they'll get it working right before we switch to wayland, and then they'll have to redo it all
<bryceh> hehe
<bryceh> blahsphemer, it's true
<RAOF> This isn't really device driver development, luckily.
<blahsphemer> :)
<blahsphemer> in another channel, someone said that it'd really help if I worked on Wayland cuz it's soon making its way into both fedora and ubunyu
<bryceh> that's not really kernel development though
<RAOF> This *is* working on Wayland.  Just indirectly :)
<blahsphemer> RAOF, o_O
<bryceh> for sufficiently broad definitions of "wayland" ;-)
<RAOF> Specifically, this is making it possible to remove input routing priviledges from Wayland.
<bryceh> speaking of which... I was able to get wayland working on i945 this morning
<bryceh> (and gm45 the other day)
<RAOF> Are the flowers beautifully rendered?
<RAOF> :)
<RAOF> Also, cool.
<bryceh> they are
<bryceh> RAOF, speaking of which... I nearly have the packaging done, so at some point this week I'd appreciate it if you could block out a couple hours to do a review of my mesa packaging changes
<RAOF> Certainly.
<bryceh> RAOF, thanks, I'll let you know when I feel it ready
<blahsphemer> okay, so I am going to read this now www.xml.com/ldd/chapter/book/ch03.html and when I'm stuck at something, I'll hit the room again :)
#ubuntu-kernel 2011-11-14
<semitones> that would be cool
<semitones> too bad he left
<kristian-aalborg> greetings
<cking> morning
<smb> morning (.+)
 * cking kills pulseaudio and tries some different tweaks
<cking> apw, https://wiki.ubuntu.com/Kernel/PowerManagement
 * RAOF should do some more controlled tests, but that seems to drop t420s power consumption ~4W (down to a more respectable 11-12W totally idle)
<cking> nice
<apw> RAOF, which is your entry in the table ?
<RAOF> There isn't one yet.  See point "should do some more controlled tests".
<apw> ahh :)
<apw> RAOF, its very early hear
<apw> here even, bah
<RAOF> :P
<RAOF> I wonder if that issue applies to this x200s, too.  Although it can't save *that* much power; dropping power consumption 4W here would drop it down to 4W in total, which seems a bit ambitious :)
<apw> RAOF, but 1w on there would be mamoth
<RAOF> It might get me back up to >10h runtime on the 9cell, yeah.
 * cking rummages around for his power meter
<Daviey> What is the current state of realtime kernel?
<Daviey> (morning btw)
<tjaalton> RAOF: which screen brightness setting did you have?
<tjaalton> when testing the t420s
<Daviey> apw / cking: Do you know the status of -realtime?  https://wiki.ubuntu.com/RealTime , suggests -lowlatency is the focus.. but TBH, i don't understand the difference.
<apw> realtime hasn't existed for some time has it ?
<apw> Daviey, realtime is presumably the -rt patchset, which lags the main kernel by many releases
<apw> Daviey, lowlatency is about using upstream features is differnet configurations to get the best latency response they can
<Daviey> apw: so TL;DR suggests we don't have a good story in that area?
<apw> TL;DR ?
<tjaalton> "too long; didn't read" :)
<tjaalton> RAOF: 9,2W here, with rc6 enabled too, though the brightness is ~60%
<tjaalton> turning bt off (0,5W), min_power for sata (0,5W) and brightness to minimum drops the estimate to ~7,1W :P
<tjaalton> can't get lower than 6,2W
<apw> does anyone know if we had a launchpad rollout recently?  i am seeing new delete buttons next to tasks and nominations
<Daviey> apw: that was on planet.ubuntu.com as a new feature
<apw> oh what does it do
<Daviey> apw: if i add a task for FOOBAR project by accident, previously all you could do was mark it invalid. Now you can remove it.
<apw> any idea what it means for a nomination, will it remove all precice ones or just the one on the specific task
<diwic> no more "the NULL project" I assume :-)
<Daviey> apw: http://blog.launchpad.net/bug-tracking/removing-a-project-from-a-shared-bug-report
<Daviey> apw: NFI, try it on https://staging.launchpad.net/
 * apw is tempted to hit it on production just to see what explodes
<Daviey> lol
<apw> Daviey, and anyhow as usual anything i click on on staging leads to an oops
<apw> Daviey, oh and it doesn't have the code for that rolled out anyhow
<Daviey> hah
<ogra_> apw, do you remember the conclusions from our hallway hack session about dropping the initrd ? was it "kernel team rolls uuid support into the in-kernel tub 
<ogra_> ergh
<ogra_> ... into the in-kernel-stub initrd, then "stopwatch boot time diffs on different arches with that change"
<ogra_> ?
<apw> there is cirtainly a 'comparison of the three no-initrd, small initrd =mod, and fat' to produce
<ogra_> right, i'm just thinking about how to turn it into proper WIs
<apw> there should citainly be one to say do that comparison, and perhaps one to investigate use of the internal initrd
<apw> i suspect maintainance of that is so fraught with complexity its not worth it
<ogra_> would it be ok to write "rtg: to provide a kernel with uuid support in the internal initrd for measuring" ?
<apw> i'd just put canonical-kernel-team on those and we can figure out who
<ogra_> i can do all the measuring items and assign them to me
<ogra_> k
<ogra_> would we need to make the kernel learn a new cmdline option ? noinitrd will likely also skip the internal one i guess
<ogra_> (or wont it ?)
<apw> initrd handling is all grub side
<apw> bootloader side, we only use one if its passed
<ogra_> apw, but how does the kernel know if it should use the in kernel initrd or no initrd ?
<apw> it always uses the internal initrd, just mosttimes it is empty
<apw> unless there is one passed from outside
<ogra_> k
<ogra_> thx :)
 * apw runs to toolstation, seems one of our switches i about to fall apart and expose live wires !
 * smb looks over to apw, wondering whether the curse is spreading now...
<apw> heh yeah, i'd not connected that things here were all falling appart cause the were house ones
<apw> but clearly smb is to blame
<smb> Always a pleasure to pass on the fun. :-P
<apw> heh thanks
<apw> heh nice, my battery is so flat that gsd is reporting it as not-present
<smb> hm, is it present in the acpi stat?
<apw> yep and now it has a charge of != 0, its now present in gsb too
<smb> maybe a feature... a battery without charge is not really present... :-P
<_ruben> i wonder if it'd detect my fully charged battery, which is not within my laptop currently ;)
<ppisati> -CONFIG_BOOT_PRINTK_DELAY=y -- why do we have this on?
<smb> to allow using the option iirc
<smb> it allows setting the delay when y (does not do any delay by default)
<ppisati> ah ok
 * ppisati is having fun with the omap4 config sync/review
<apw> ppisati, sounds riviting
<apw> cking, i added a notes column to your sheet
<apw> cking, and i am updating and charging a couple of my laptops to test
<cking> apw, yeah, good note to add, nice to flag up broken results
<apw> cking, this fix does what enable alpm by defualt ?
<cking> alpm? ASPM don't you mean?
<apw> cking, possibly :)
<cking> alpm is sata related
<apw> and what is aspm
<cking> ASPM is the PCIe power tweaks
<smb> Too many STLBs
<cking> if ALPM is borked you may lose data
<smb> STLAs even
<cking> ALPM = Aggressive Link Power management for SATA
<apw> cking, anyhow does nothing for my acer :(
<smb> cking, Aggressive or Advanced as well?
<cking> Aggressively Advanced?!
<apw> cking, does your version number appear in version_signature?
<smb> apw, As far as I understand the change it would only disable that now if the bios had enabled it and os is granted control
<apw> and if not, how did you arrange that exactly
<cking> apw, smb was discussing the version signature with me just now, seems like I foobar'd it
<smb> apw, look for _OSC in your dmesg
<apw> it is very confusing that you managed to elide your +foo ... and makes it hard to know if i am testing the right thing
<apw> i see those
<cking> apw, I know, I failed, this is what happens when I rush things over saturday :-(
<apw> just amazed it is actually possible
<smb> apw, I was surprised as well
<cking> nothing surprised me
<apw> normally one has to work pretty hard to stop it being in there
<smb> cking, good point is, do you know whether aspm on/off would yield any message and which?
<cking> smb, theoretically yes, but I dunno off the top of my head
<smb> On my netbook here _OSC fails, but I don't know whether it would have the bit enabled or not. Well, from the data it does not seem to have
<smb> apw, You can check whether your current kernel was compiled on Sat. ;)
<cking> smb, what do you mean by _OSC fails?
<smb> cking, pci0000:00: Unable to request _OSC control (_OSC support mask: 0x0f)
<cking> ah, yes, that that then disables ASPM
<smb> cking, Currently. With the patch I would assume it would be left alone if the bios had enabled it
<cking> smb, I believe that's the idea behind it
<smb> So this was taken, running the Sat. kernel. But power usage seems to be unchanged. Just was wondering whther there would be a piece of msg saying something... Hm, though that would only appear in the unpatched kernel...
<jjohansen> smb:  		printk(KERN_INFO"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
<smb> jjohansen, Cool. Thanks. Re-installing the original kernel to cross check
<jjohansen> smb: also not this patch won't fix everybody, only some of those with broken bioses
<cking> sorry, this is hard to follow at the mo, my kids are demanding my attention
<jjohansen> cking: when don't they :)
<apw> "do they blend?"
<cking> but the gist is that some broken BIOSes caused the old code to put the system into a sub-optimal state
<smb> apw is a bit harsh
<smb> jjohansen, Right, I just want to make sure data taken is consistent
<mjg59> It seems that the expected behaviour is for Linux to *never* touch the ASPM bits unless we get _OSC control
<cking> mjg59, where is the microsoft presentation you referred to in the patch?
<mjg59> Right now if the firmware sets the "Do not use ASPM" bit  we clear ASPM state
<mjg59> Which involves touching the ASPM bits
<mjg59> It seems that we shouldn't be doing that
<apw> ahh one of those subtle wordings catching us again
<mjg59> There is no wording
<apw> deep joy
<mjg59> Platform expectations here are entirely undocumented
<cking> well, it's kind of nebulous isn't it and it's not really mentioned in any specs we've got
<mjg59> cking: If you just google for "pci express in depth for windows vista and beyond" you should find it
<cking> so theoretically we should see some platforms do well out of this patch, while others no change whatsoever and the likelyhood of worse behaviour is nil isn't it?
<cking> ah google my frend
<mjg59> In theory
<cking> well, so far the minimal crowd sourcing results look that way too
<mjg59> The machine that triggered the original patch /seems/ to give full _OSC control
<mjg59> Which would mean it still works with this patch
<apw> cking, where is my automation *stamp*
<cking> apw, what do you mean?
 * apw is bored of oding this testing by hand already on 2 machines
<cking> apw, lazy git ;-)
<smb> apw, You have not written it, yet?
<cking> I'm writing some code right now, I've got netfilter process monitoring and the ACPI battery monitoring in, just need to tidy it up.
<apw> cking, this machine here, i've plugged the  power back in, and am still getting acpi estimates
<apw> that seems unexpected
<cking> bad powerflop behaviour perhaps?
<apw> most likey
<cking> this is why I'm hacking my own code, to ensure it's done right
<cking> or more right ;-)
<ogra_> whats the superlative of right ?
<ogra_> rightest ? :)
<cking> not more right for sure
<apw> rightingly
<cking> even righter
<ogra_> so right :)
<cking> more rightish
<apw> less ridingcrop perhaps
<smb> righton
<kraut> howdy
<kraut> i got a strange issue with the 3.0.x kernel. i wrote a daemon which watches if network devices are available with the kernel mac-table
<kraut> after i upgraded to 3.0.x the timeout "gc_stale_time" doesn't as supposed to
<kraut> gc_stale_time is set to 60 but it takes much more time until the entry wents from "STALE" to "FAILED".
<apw> the entry in which table ?
<kraut> could anybody tell me what changed from 2.6 to 3.0?
<kraut> apw: arp
<kraut> root@exodus:/proc# ip -4 neigh show dev br0 | grep "192.168.1.12 lladdr"
<kraut> 192.168.1.12 lladdr 00:23:76:4f:8e:3b STALE
<kraut> f.e.
<apw> which kernel version is it confirmed working as you expected ?
<kraut> wait
<kraut> meh, deleted anyone because of diskusage
<kraut> the last one from the last ubuntu version
<kraut> hmm
<kraut> linux-image-2.6.31-21-generic
<kraut> this one f.e.
<kraut> the entry above is still on "STALE" by the way :/
<apw> so since Lucid ?
<kraut> yep
<apw> no 31 isn't anything
<kraut> can't remeber all the "code names" ;)
<kraut> with 11.04 everything was fine, with 11.11 not.
<kraut> or 11.10 better said
<apw> ok so 2.6.38 then
<kraut> hmm. can't really tell. from dpkg -l it must be 2.6.31-21?
<apw> smb, did we release with .31 in anything?  karmic maybe ?
<kraut> ah, i think i purged the old packages so i can't figure out with dpkg -l
 * ogra_ doesnt think it is a kernel prob ...
<smb> apw, No, except maybe he is on arm
<apw> kraut, is this imx51 ?
<kraut> ogra_: i'm not really sure weither it's a kernel issue or not
<kraut> but as i remember the arp table is a kernel "feature" and i think there is anywhere anyhow an issue :/
<ogra_> i can use the command here on my ac100 and get STALE on oneiric with .38 ... if i try it on my x86 laptop under natty with .38 i dont get the STALE
<kraut> apw: lmx51?
<kraut> x86
<kraut> Linux exodus 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux
 * ogra_ would suspect the ip command to have changed here, rather than the kernel
<apw> ok so if it worked on 11.04 which was natty, then the kernel would have been a 2.6.38 kernel
<kraut> and no, it's not an issue with the hostname ;)
<apw> and from there to 3.0 there are only 4 commits to arp
<apw> none of which sound anything to do with state handling
<kraut> from /proc/net/arp:
<kraut> 192.168.1.11     0x1         0x2         38:e7:d8:de:bd:5d     *        br0
<kraut> and 0x2 is STALE IMHO
<kraut> root@exodus:/proc# cat /proc/sys/net/ipv4/neigh/default/gc_
<kraut> gc_interval    gc_stale_time  gc_thresh1     gc_thresh2     gc_thresh3     
<kraut> is gc_thresh new?
<kraut> brb
<apw> nope
 * ogra_ would suggest looking at the changelog of iproute 
<apw> its curtainly true that iproute has changed a lot in oneirc
<kraut> i don't think it's an issue with ip-utils because /proc/net/arp shows me the same issue?
<ogra_> ogra@horus:~$ zgrep -i ARP /usr/share/doc/iproute/changelog.Debian.gz 
<ogra_>           Update ARP header type table
<ogra_> well
<ogra_> ...
<kraut> hmmmm!
<apw> cking, this is hopeless, the powertop interval changes randomly depending on how the values change
<apw> 10s 15 45 sometimes
<cking> apw, now you see why I'm hacking up something more useful
<apw> i am more wondering what use any of the results are given this behaviour
<cking> apw, they are limited, but will hopefully show up any seriously bad power issues or improvements
<cking> hence, that's why I'm getting some proper kit
<apw> proper kit is approriate, but something more usefult for 'us' would be good
<cking> yep, but once I can calibrate typical ACPI results against real world power usage and make powertop like tool we will be in a better shape, but this is only day #1 of the project so progress is limited so far ;-)
<kraut> from /usr/include/linux/neighbour.h the flag 0x2 in /proc/net/arp means REACHABLE so i think it's still a kernel issue
<smb> cking, The only "downside" seems to be that external kit can only gather power consumption while plugged into ac, while acpi only gives you the consumption when on battery...
<apw> kraut, well we'll need an accurate kernel version where its behaving different to work out where to look
<apw> kraut, from what you've told me there doen't look to be any significant changes at all between the two versions
<cking> smb, well, I can take these machines apart you know...
<smb> cking, You even might succeed in putting them back together. :) I may not succeed on that part. 
<apw> cking, nothing i've tested so far sees any benefit
<cking> apw, it has been beneficial, now you see why I'm doing this over the next few months and you're not.
<apw> cking, oh i know why you are doing it :)  i don't have the patience :)
<kraut> apw: that's not so easy because i can't downgrade that way :/
<apw> kraut, you should be able to run the older kernel with teh current userspace generally
<kraut> if i didn't deleted it, that wouldn't be a problem^^
<apw> you can get it back from the launchpad librian
<apw> https://launchpad.net/ubuntu/natty/+source/linux
<kraut> can't i add that one to my sources.list?
<kraut> deb https://launchpad.net/ubuntu/natty/+source/linux oneiric main
<apw> that sounds dangerous
<apw> oh that, no that isn't an archive
<kraut> hmm
<hallyn> hoping to test the new power-saving oneiric kernel today, but - I'm curious, does anyone have an idea offhand on whether th elucid kernel would be even still more battery-friendly?
<kraut> so should i take this one? https://launchpad.net/ubuntu/natty/+source/linux/2.6.38-13.52/+files/linux_2.6.38.orig.tar.gz
<kraut> i think i finish for today. i'm fed up :/
<kraut> thanks for helping so far!
<cking> apw, so I want to make my power measuring tool skip a reading if it sees processes wakeup/die. do you think that's a sane idea?
<cking> s/wakeup/fork or exec or exit/
<apw> my experience is more than one after are affected, i wonder if we could just consider restarting
<apw> but dropping one or more is not unreasonable perhaps
<cking> I've now got a vmstat like output including average + stddev power data
<cking> gonna sleep on the this and tinker some more tomorrow
<apw> cking, sounds planwise
<cking> been reading the power meter manual, it's a nice bit of kit
<cking> just hope I don't blow it up
<apw> cking, stay away from smb
<cking> he's had his fair share of dead H/W
<apw> and i realise the switch which just broke and tried to kill me, was one he has been using
<apw> just saying
<cking> heh
 * apw wanders off
<smoser> smb, around ?
<redzarf> trying to rebuild lucid kernel on amazon ec2, but it's not building the image deb file (only headers, docs, tools)
<redzarf> any ideas?
<redzarf> kernel version is linux-ec2_2.6.32-319.39
<GrueMaster> Anyone know what happened to linux-ti-omap4: 3.0.0-1206.12 ?  I tested it in proposed last week, and it is marked now as fix-released.  The source and meta are on the server, but not the kernel deb.
<GrueMaster> For oneiric.
#ubuntu-kernel 2011-11-15
<mdeslaur> Is there an ETA for the lucid mini 9 sound regression caused by kernel 2.6.32-34? (LP: #875300)?
<mdeslaur> or do I have to apply workaround for all family and friends?
<redzarf> more details are here: http://stackoverflow.com/questions/8088901/
<jjohansen> redzarf: whats up :)
<redzarf> jjohansen: I was hoping you might be around :)
<redzarf> still can't get the image deb file to build
<jjohansen> yeah I gathered that :)
<jjohansen> redzarf: what kernel source are you using, and on what version of the OS are you building
<redzarf> kernel: linux-ec2-2.6.32
<redzarf> OS is lucid (latest on EC2)
<jjohansen> alright and where is it failing
<redzarf> Been trying from the plain Ubuntu AMI's
<redzarf> I think it's during the fakeroot debian/rules binary
<redzarf> the stackoverflow page has the error message that comes up at the end
<jjohansen> redzarf: okay, can you paste the error some where? paste.ubunt.com ?
<jjohansen> redzarf: ah, okay looking again
<redzarf> thx
<jjohansen> redzarf: in the source directory, what debian directories exist?  is it debian and debian.ec2 or debian and debian.master
<redzarf> all 3
<jjohansen> redzarf: hrmm, try binary-ec2
<jjohansen> it should be hooked up so that binary, does binary-ec2 /me is wondering if there is a bug there
<redzarf> still similar errors as before (no image file)
<jjohansen> redzarf: what is under debian/build/
<redzarf> i'll try redownloading source and doing it from scratch, then paste the full output
<redzarf> i'll try redownloading source and doing it from scratch, then paste the full output to paste.ubuntu.com
<jjohansen> redzarf: oh wait did you do a fakeroot debian/rules clean first
<redzarf> i did
<redzarf> but i'll do it from scratch to be sure
<redzarf> would you recommend I get linux-image-2.6.32-318-ec2 or just linux-ec2?
<jjohansen> redzarf: honestly I would recommend the git tree
<redzarf> what settings would i need to change for ec2?
<jjohansen> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<jjohansen> git checkout --track ec2 -b ec2 origin/ec2
<jjohansen> second command from within the directory the first creates
<redzarf> ah, excellent :-)
<redzarf> nearly finished using the apt-get version...
<jjohansen> I know the source tarball should be good enough, but I always use the git tree
<redzarf> http://paste.ubuntu.com/738824/
<jjohansen> looking
<redzarf> btw, i think the file that is touch'ed on line 11 doesn't exist - the place it's copied from doesn't have that file
<jjohansen> redzarf: ah yeah, okay do
<jjohansen> make mrproper
<jjohansen> git checkout -f
<jjohansen> and try building again
<redzarf> ok, doing the clone now
<redzarf> then I do the first checkout above? (--track ec2)
<redzarf> then those 2 commands?
<redzarf> do i make menuconfig just before doing the debian/rules clean?
<jjohansen> oh, sorry no
<jjohansen> within a git tree, those last to will let you get past the mrproper error and build, but not from the source tarball
<jjohansen> so the the clone and checkout commands
<jjohansen> then do
<jjohansen> fakeroot debian/rules editconfigs
<jjohansen> if you do menu config before clean, its changes will get blown away
<jjohansen> actually you will need to do an
<jjohansen> fakeroot debian/rules clean
<jjohansen> before editconfigs
<jjohansen> editconfigs is a wrapper around make menuconfigs
<redzarf> i'd been doing make menuconfig then the fakeroot debian/rules clean then fakeroot debian/rules binary, so i guess they were out of order
<redzarf> right
<jjohansen> well you can do it but, I won't guarentee that it will work
<redzarf> so do i still do make mrproper and git checkout -f ?
<jjohansen> actually I think make menuconfig will but then you hit the mrproper problem
<jjohansen> no
<redzarf> so this is what i'm about to run:
<redzarf> git checkout --track ec2 -b ec2 origin/ec2
<redzarf> fakeroot debian/rules clean
<redzarf> fakeroot debian/rules editconfigs
<redzarf> fakeroot debian/rules binary
<redzarf> fatal: git checkout: updating paths is incompatible with switching branches.
<jjohansen> oops
<jjohansen> git checkout --track -b ec2 origin/ec2
 * jjohansen messed up the checkout syntax
<redzarf> thats ok, the noob who doesn't know any better will forgive you :)
<jjohansen> well even for someone who uses git daily sometimes its syntax is uhm less than friendly
<redzarf> the binary command is running - taking much longer than it ever has before, so I'll take that as a good sign
<redzarf> jjohansen: it's finished and the image file is there!! :)
<redzarf> so I just run  dpkg -i linux-*.deb  then restart - anything else?
<jjohansen> redzarf: that should be it
<redzarf> great, thanks for your help!
<jjohansen> redzarf: np
<apw> GrueMaster, did it end up in universe perhaps
<smb> morning .+
<n0ti0nis> morning
<ppisati> morning morning
<seb03> Hi, I'd like to help with the ASPM bug, how do I know that I've installed the patched kernel correctly?
<seb03> does it simply replace the existing one or should it be selectable on boot?
<smb> seb03, It would replace the existing one if you take the same version
<smb> Theoretically you should notice a difference in uname -a after boot
<smb> but in doubt it is the one compiled on Sat-12
<seb03> sure do: uname -a Linux snoopy 3.0.0-13-generic #22+mjgaspmfix SMP Mon Nov 14 18:02:48 UTC 2011 i686 i686 i386 GNU/Linux
<smb> So that is the patched one
<seb03> so how do I get rid of it again after I've done my power readings?
<seb03> install the meta package from the repo again?
<smb> seb03, In doubt you can get the package from there https://launchpad.net/ubuntu/oneiric/+source/linux/3.0.0-13.22
<smb> There is also some way to force a reinstall with specifying a version, but I personally find it rather complicated. :)
<seb03> thanks
<iceroot> hi
<iceroot> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/869502  can you have a look at this bug to give me infos how i can support you on a better way to get it fixed
<ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
<iceroot> see also http://article.gmane.org/gmane.linux.kernel/1211290 and http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=6192
<seanius> hi, quick question:  I'm maintaining a local kernel package based off the ubuntu-lucid git repo.  I'm wondering how I should make commits to incrememnt the changelog frmo the ubuntu version
<seanius> is there some magic string i need to put in the commit to get it show up in debian/changelog?  and is there anything else I need to do to increment the ubuntu version?
<tgardner> seanius, kernel maintenance is described somewhere in https://wiki.ubuntu.com/Kernel 
<ppisati> seanius: everything you commit (except if you use the Ignore: Yes string in the commit log) should show up in the changelog
<ppisati> seanius: about the version, it's your duty to increment it
<ppisati> seanius: you mean the last 2 numbers, right?
<ppisati> seanius: e.g. linux-image-3.0.0-1206-omap4_3.0.0-1206.12_armel.deb
<ppisati> seanius: the 1206 and 12 numbers in this pkg
 * ppisati -> lunch
<seanius> ppisati: none of my commits show up in the changelog, but like I said I don't know if there's some documented syntatic sugar i'm missing in the commit or some script/template etc
<seanius> tgardner: i will poke around and see what i can find
<apw> seanius, you probabally need a fakeroot debian/rules insertchanges to get them into the changelog, of course that implies you have followed standard proceedure in opening the changelog entry (fakeroot debian/rules newrelease)
<apw> all of this is documented (poorly) in the kernel-team wiki
<seanius> looking at https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication right now
<seanius> basically, i have a set of about 50 backported patches which i need to maintain on top of one of the ubuntu-lucid kernels
<seanius> and periodically rebase against the ubuntu updates int the repo
<seanius> each time i rebase the list of patches get a bit smaller but i don't see the problem ever going away entirely
<seanius> at least until 3.2 is released and backported :)
<seanius> it looks like apw's suggestion agrees with the above wiki page, so i'll try working with that
<seanius> thanks!
<seanius> one more question: what provides maint-getabis?
<apw> there is a getabis script in the tree, maint-getabis is more for use by team members, as it talks to our PPAs etc
<smb> (which would be in the kteam-tools git repo)
<seanius> right, thx
<seanius> and for changes to be inserted via debian/rules insertchanges they need to have an "UBUNTU:" line in them?
<apw> nope
<apw> for them to have your name against them ye
<apw> yes, otherwise no
<seanius> or... i guess the new release commit has to go before them
<apw> nope, not that either
<apw> it looks for the previous release commit
<apw> the format of the release commit title is important
<seanius> insertchanges turns my new release changelog into a blank entry
<ppisati> seanius: did you close it properly?
<apw> its all simple shell in debian/rules.d so you should be able to debug it pretty easy
<apw> its definatly orientied to our use models
<seanius> understandable
<seanius> okay so this is what i'm doing so far
<apw> normally an empty entry is triggered by it failing to find the previous release commit
<seanius> git pull --rebase to get some updates
<apw> and fakeroot debian/rules printenv will tell you what it things current and previous are
<seanius> git clean -dffx && git reset --hard
<seanius> fakeroot debian/rules clean
<seanius> fakeroot debian/rules startnewrelease
<seanius> git commit -s -F debian/commit-templates/newrelease
<seanius> oh, oops, there's a git add debian/changelog in there
<seanius> er, debian.natty/changelog
<seanius> and then  fakeroot debian/rules insertchanges, which sets the changelog to be empty
<apw> ok, as i say thats probabally because its failing to find its previous entry
<apw> fdr printenv will show you the version it is looking for
<seanius> i also see an error from expr when running fdr startnewrelease
<seanius> apw: will look at printenv after i clean up again
<apw> then likely your version format is probabally not working for the tooling, and the tools may need a tweak
<seanius> but i haven't added any version yet
<seanius> but this is in the natty-lts-backport tree so maybe it's something existing in the repo
<apw> if your version is triggering the expr then likely the previos version is being broken
<apw> which means we won't find it to do the entry detection
<apw> you can just ignore the tooling there and use like
<apw> if you look at the implementation of insertchanges, you can see how it works
<apw> you can use git log of your own in the same command line
<seanius> ah, yeah, you have a bug in rules.d :)
<seanius> revision          = 13.52~lucid1
<seanius> @nextminor=$(shell expr `echo $(revision) | awk -F. '{print $$2}'` + 1);
<apw> yep, probabally never used on lts backports
<apw> we don't generate those that way
<seanius> but really, if all i'm interested is sticking a version on top of the existing backport version, and don't care about good changelog documentation, i could just directly edit the debian.natty/changelog file?
<apw> yes
<seanius> okay, simplicity ftw then :)
 * ogasawara back in 20
<apw> smb, whats the latest official relase of your drm33 tree ?
 * smb believes 2.6.32.48.21
<smb> apw, ^ Should be that. Am I slacking somewhere?
<apw> smb, no making sure the flip back to kernel.org worked
<apw> and that we are up to date
<smb> Ah, ok
<smb> apw, We should be up to date from before. I think I saw builds happening while I still was bringing k.org back to life
<apw> url = git://kernel.ubuntu.com/smb/linux-2.6.32.y-drm33.z.git
<apw> oh we are on the old one, which one do you want to use
<apw> are you keeping our mirror up to date anyhow?
<smb> apw, Sort of automatically as I use it to transfer to local builders to test builds. I had been a bit more lax with the tag, but I guess I will use it as a real mirror now
<smb> Otherwise: git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git
<apw> smb, ok will leave it pointing at your ubuntu one for nwo
<ogasawara> ##
<ogasawara> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<ogasawara> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<ogasawara> ##
<ogasawara> ##
<ogasawara> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
<ogasawara> ##
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0.0 || Ubuntu Kernel Team Meeting - Tues Nov 22 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> ogasawara, ok i've redone the configuration review and dumped a slew of new inconsistant items on your plate :)
<ogasawara> apw: ack
<apw> ogasawara, did we add doing a re-review at rally to the work items ?
<tgardner> ogasawara, I was sure ther would be a few. it was kind of mind numbing with all the new options
<ogasawara> apw: yep, and I thought you added it to the agenda already
<apw> tgardner, yeah epecially as you see them all 20 times
<apw> ogasawara, will check and confirm
<apw> ogasawara, yep its there good
<ogasawara> tgardner: how's the sprint going?
 * ogasawara rebases precise to 3.2-rc2
<tgardner> ogasawara, neck deep in server configuration....
<apw> ogasawara, I assume there is no patches for the 3.1.0 -> 3.1.1 stuff
<ogasawara> apw: which stuff?
<apw> Replace compat-wireless 3.1.0 with 3.1.1
<apw> that stuff, i assume your thread is not meant to contains patches for the code itself
<ogasawara> apw: not exactly, it just dumps the 3.1.1 tarball over the 3.1.0 bits
<apw> ogasawara, what are we naming the meta packages nwo
<apw> i was sort of expecting the relase to be 3.1 in the meta package, pointing to 3.1.x whatever it is called in the lbm package
<ogasawara> apw: for oneiric it's linux-backports-modules-cw-3.1.1-oneiric-<flavor>
<ogasawara> apw: I suppose we could make it just be 3.1
<apw> we use 2.6.38 presumably for the meta package in previous releases yes?
<apw> ie it points to the base version?  then i think the new ones should be 3.0 3.1 etc as they are meant to upgrade
<ogasawara> apw: yep, in lucid for we used 3.0.0, so I followed suit and used 3.1.1
<apw> well 3.0.0, and 3.1.0 (where the 0 is always 0) might also make sense as it matches our kernel naming
<apw> but the .1 is like patch releases right?  if so then we don't want that bit to change in the meta package name
<apw> so either not there, or zapped to 0, so we get upgrades
<ogasawara> apw: yah, I think I like the 2 digit convention
<ogasawara> apw: eg just 3.1
<apw> ogasawara, yeah
<ogasawara> apw: I'll send a revised patch to the list
<mdeslaur> tgardner: who do I need to ping for SRU regressions?
<tgardner> mdeslaur, start with the stable team
<mdeslaur> who is on the stable team?
<apw> mdeslaur, bjf and herton in the first instance
<mdeslaur> apw: thanks!
<apw> mdeslaur, fileing a bug against the version with regresion-proposed or regression-updates would get their attention too
<apw> what you found, anything fun ?
<EtienneG> trying to test the latest natty kernel in natty-proposed, but it seems like linux-image-2.6.38-13-generic is not in the archive.  Is it still building?
<mdeslaur> apw: there's already a bug open (#875300)...we broke sound on mini 9's running lucid...and now, a bunch of friends have started pestering me :P
<mdeslaur> apw: never _ever_ recommend machines to friends :P
<apw> EtienneG, shouldn't work that way as things are copied in as a chunk
<apw> EtienneG, which flavour are you having issues with 
<EtienneG> apw, -generic, amd64
<EtienneG> apw, it shows on https://launchpad.net/ubuntu/natty/amd64/linux-image-2.6.38-13-generic/2.6.38-13.52, but it not apt-getable from us.a.u.c or archive.u.c directly
<EtienneG> also, linux-image-generic do depend on linux-image-2.6.38-13-generic, but it is not there ...
<EtienneG> I am perplexed
<EtienneG> might just be me doing something wrong
<apw> EtienneG, they appear to be in universe
 * apw investigates
<EtienneG> ah!
<EtienneG> weird, but he
<tgardner> EtienneG, an inexperienced archive admin likely forgot the overrides (again)
<apw> tgardner, looks like it yep
 * apw starts poking on #ubuntu-devel
<EtienneG> tgardner, I am shocked! is there such a thing as an "inexperienced archive admin"?  :)
 * apw wishes it was not so
<apw> though the kernel copies is meant to be scripted so in thory that could be part of the scirpting
<apw> EtienneG, adding universe temp should let you get testing
<EtienneG> anyway, that was it.  my sources.list entry for natty-proposed only had main and restricted
<EtienneG> so there
<EtienneG> thanks for the pointer, as long as I can it, I am happy
<EtienneG> I guess it will be fixed in time
<apw> yep, will poke that aa's to get it resolved
<apw> looking likely will be tommorrow now
<apw> ogasawara, under the new rougime wherein the archive is meant to work all the time, i wonder if we should upload a semi-official kernel to the kernelppa or something so we can get some testing on it before unleashing it on the unsuspecting public
<ogasawara> apw: sounds reasonable
<apw> of course that assumes we have PPAs
<ogasawara> apw: I know there are still some powerpc build failures that I need to fix us (assuming they're not fixed with -rc2)
<apw> ogasawara, ok :)  let me know if i can help, else i'll keep grinding on the configuration check tommorrow
 * apw drifts away
<ogasawara> apw: ack, I'm gonna kick off test builds and see what's still breaking.  Likely won't get to fixing them up till tomorrow since I drop off here in a bit.
<apw> ogasawara, sounds like a plan to me, now where is that beer
<ogra_> apw, you might find this thread intresting https://lists.ubuntu.com/archives/ubuntu-users/2011-November/254160.html
<ogra_> (looks like overlayfs /cow contents dont go into swap)
<apw> ogra_, could be
#ubuntu-kernel 2011-11-16
<orated> Hello! Are ubuntu kernels released every 2-3 months? Can I give a request of a change here?
<orated> When will there be support for Sandy bridge processors?
<broder> orated: Ubuntu has had basic support for sandy bridge processors since Ubuntu 10.10, and supported 3D acceleration since 11.04
<orated> broder: Apart from graphic, are there any performance issues? Like system running in performance mode than normal mode 
<broder> orated: That's not something I pay attention to, so I don't really know
<orated> broder: Well, that really drains life out of laptops with it..
<orated> The processor fan running at performance mode even when idle
<RAOF> No.  There's the PCIE PM power thingy, but that's not related to the cpu.
<RAOF> orated: Sandy Bridge processors are well supported in 11.10 (and slightly less well supported in 11.04)
<smb> RAOF, Hm, actually makes me wonder (since I got no hw to look at): is the graphics card you see on those somehow presented as being connected via pcie?
<RAOF> It does show up in lspci.
<smb> Its hard to say for sure but that still may leave a little opportunity of someone twiddling pcie pm and having some magic impact back on the cpu doing gpu'y things. (totally unrelated to any knowledge here, just thinking)...
<smb> cking, Hey how are you feeling today?
<orated> RAOF: I didn't get the reason for that. What is PCIE PM?
<RAOF> PCI Express power management; there's ambiguity between what the spec says and what Windows does.
<apw> RAOF, isn't there also some rc6 related power drain on sb ?
<RAOF> Yeah, there's that too.
<orated> Well, I n Windows it works absolutely fine. In Ubuntu it starts the fan in performance fan
<RAOF> That could just be your BIOS being stupid.
<orated> er
<RAOF> Which we *should* obviously deal with, but might not.
<apw> RAOF, is that the 'performance MSR' thing?
<apw> sb is a bit of a mess, and thats an upstream issue in the main
<RAOF> apw: EAMBIGOUSTHAT
<apw> and its going to take a while to perculate out into release
<orated> RAOF: I have the BIOS updated
<apw> RAOF, stupid BIOS> wondering if thats the 'CPU in performance by default' thingy thats controlled by a CPU msr or something more general
<RAOF> Oh, no.  I was thinking "fan speed need not have any relationship to CPU performance mode"
<apw> ahh, more possibilities.  i hate bios vendoes
<orated> RAOF: But isn't that proportional?
<RAOF> orated: Not necessarily; the fan control isn't wired up directly to a thermal sensor or anything like that.  At least, not all the time :)
<RAOF> In other words: CPU state and fan state can be totally independent.
<orated> I'm not aware of the different states but I think the CPU fan rpm will increase/decrease as per CPU/GPU load
<orated> as far as I'm aware
<RAOF> No, that's by no means guaranteed.
<RAOF> Same with gpus, which is why the nouveau guys are paranoid about enabling fan control.  It *is* entirely possible to turn off the fan and have the GPU cook itself.
<orated> So my system to run cpu fan in performance mode can be only due to power management?
<RAOF> What should happen is that the kernel should see that ACPI thermal zone $X has hit $TRIP_POINT and turn the fan on to $POWER_LEVEL.  At least on most hardware.
<RAOF> orated: You CPU fan may be running at 100% simply because the BIOS starts it up at 100% and doesn't hand control off to the kernel correctly.
<orated> On what does it depend to hand over control to kernel?
<RAOF> It needs to say that the fan should be controlled by the OS.
 * RAOF â dinner.
<orated> Well, I'm not that aware of proper technicalities but I only presented my observation here of system performance in Windows and Ubuntu. But if its BIOS issue, how can I fix it? Its updated ...
<orated> ah-ok. Catch up with you later then ...
<dupondje> The thing thats really missing atm is Optimus support. That drains the battery :)
<apw> that one will be a while coming
<dupondje> are things getting in kernel for that ?
<broder> apw: yeah, but we *should* be able to stopgap that some by being sure to power down the unused chip, at least in theory
<apw> broder, in some cases for some hardware with a machine specific quirk in every case
<apw> broder, its not going to be pretty until the proper support comes and no mistake
<cking> as it is, the fans are normally controlled by System Management Mode, so it's normally totally out of our control and up to the firmware to get it right.
<smb> cking, btw just found a funny state of brokenness: while everything else seemed ok, the discharge rate was reported as 0. Wonder whether its worth bailing out of powerstat and tell users to try to connect and disconnect ac (that was how I "fixed" it).
<cking> smb, yep, I can add that logic to cater for broken machines like yours ;-)
<cking> did you tinker with the other powerstat options? I'm interested to see if it looks useful or if we need to add more goodness to it
<smb> cking, I am pretty sure there are many more. :) Not yet, just had a quick run. Oh and it will actually run without complaining but with 0W power consumption on a desktop without any battery at all. ;)
<cking> gah, I didn't think of that, I'll fix that too :-)
<smb> cking, I feel a bit like the devil's advocate here, though. :)
<cking> smb, I appreciate you checking for things that I overlooked
<smb> cking, It is quite cool and I am sure apw will love it
 * smb already does
<cking> did you try the funky -r and -s options?
<smb> cking, will look at those next. they sound pretty interesting
<cking> netlink was fun to figure out, but there was plenty of good documentation lying around
<tjaalton> i sent an email to kernel-team@, but seems it didn't get through
<smb> tjaalton, Are you normally subscribed?
<apw> tjaalton, may be in the moderation queue, we get a _lot_ of spam
<tjaalton> i'm subscribed yes, checking which address i have there
<smb> cking, Another completely unimportant note: -r is missing in the usage summary...
<apw> tjaalton, it was in the mod queue, i've poked it
<orated> smb: Can I ask which command you are using?
<cking> smb, err, try updating
<cking> ./powerstat -h
<cking> usage: ./powerstat [-s] [-h] [-d N] [delay [count]]
<cking> 	-s show process fork/exec/exit activity log
<cking> 	-d specify delay before stating, default is 15 seconds
<cking> 	-r redo a sample if we see process fork/exec/exit activity
<cking> 	-h show help
<cking> 	delay: delay between each sample, default is 10 seconds
<cking> 	count: number of samples to take, default is 10
<cking> oh, yeah, I see now.
<tjaalton> apw: thanks
<smb> orated, Something cking is currently whipping together
<orated> got it
<cking> orated, technically know as "work in progress"
<cking> smb, suppose I should write a man page too
<tjaalton> ok, I had the wrong email address on the list, changed it now
<smb> cking, When things settle down, I guess that is a good idea, and in the end probably have it in a ppa
<smb> cking, Just an idea, you think it would be useful to have -r also redo the sample if idle is below a threshold (like 99)?
<cking> smb, yes, but how about making that another option, like -i, so we have more fine tuning?
<orated> cking: Regarding the fan rpm related to firmware you said above, I checked with dmidecode and the BIOS is updated and current A06 ...
<smb> cking, sounds good. probably could become -rf and -ri 
<cking> smb, good suggestion, will do
<smb> cking, maybe not that simple with getopt (without making those --)...
<cking> smb, it's OK, getopt long is easy to use
 * ppisati -> post office
<smb> herton, Quick question: is there currently a lucid-ec2 tracking bug open that I missed? Seeing the other uploads...
<herton> smb: yes, let me find the bug here
<herton> smb: bug 888700
<ubot2> Launchpad bug 888700 in linux-ec2 "linux-ec2: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/888700
<smb> herton, Thanks, that one I totally missed somehow...
 * ppisati wonders how much does it take to setup a local ubuntu repository...
<ppisati> space-wise i mean
<smb> ppisati, A lot probably does not help, but the sync would also take long. That is why I went for apt-cacher-ng
<ogra_> do you really need a full archive copy ?
<ogra_> i woudl go with something like approx instead
<ppisati> i was just wondering since this morning i read an article about "how to setup your own builder" or stuff like that, and one of the prerequisites was a local repostiory
<ogra_> well, approx, apt-cacher and friends work in a way that they pull from the archive *if* there is a newer package, else they use the local version
<ogra_> that has the advantage that you only use the diskpace for packages you actually need and that it only pulls updates if there actually are updates
<smb> Probably more of a recommendation to avoid you pulling packages over and over for each build. But as ogra_ said, you can use the proxy cachers as servers
<ogra_> indeed its slower than having a full local mirror ... on the first run
<ppisati> yep
<ppisati> but i still need a new 2tb disk, and latest flooding didn't help... :)
<ogra_> subsequent builds of the same package are fast though
<ogra_> oh, you only want to justify buying a new disk 
<ogra_> go for a full mirror them :P
<ogra_> *then
<ppisati> asd :)
<ppisati> do you think 2tb is big enough?
<ppisati> don't think so
<ogra_> one arch one release ?
<ppisati> pretty much
<ogra_> shoudl be ok ... i guess
<ogra_> but better ask someone who actually has a full mirror at home
<ogra_> GrueMaster has one for example
<smb> ppisati, Oh you really want to buy three to have it raid5'd :-P
<ogra_> infinity too
<ppisati> ah
<ogra_> smb, 3 ? you need 5 for a 5.1 :P
<ppisati> smb: better to raid 0 then
<ppisati> i mean
<ppisati> raid 1, mirror
<smb> ppisati, yep
<smb> ppisati, But I thought you wanted more arguments for yourself to buy many disks... :)
<ppisati> ah :)
<smb> Cause in reality with caching (I use it a lot and currently got 4G used) you do not really need a new one and any raid is not really needed because you can always start over from the archive
<ppisati> smb: thgat
<ppisati> smb: that's true
<ppisati> but with a big enough disk i can offload not only the archives, but even the OS and all the rest
<ppisati> one raid to rule them all
<mdeslaur> hi herton, any ETA on a regression fix for lucid? (LP #875300)
<ubot2> Launchpad bug 875300 in linux "[Realtek ALC268] ALSA test tone not correctly played back (regression in lucid from 2.6.32-33.72)" [Medium,Triaged] https://launchpad.net/bugs/875300
<herton> mdeslaur: I can revert the patch causing it, the problem is reverting should bring the previous regression the "fix" is handling. I plan to see if I find a solution until the end of the week.
<mdeslaur> herton: but, have you actually seen the regression? AFAIK lucid sound on mini 9's has always worked...
<herton> mdeslaur: it's just a problem with quirks, machines with same id but codec differences, so one quirk was applied to one model, but the same id make the quirk brake other models. Newer kernels have a better hda auto-config, and I suppose will handle this better. It's not so bad, you still can use model=dell (options snd-hda-intel model=dell), to avoid the breakage for now
<mdeslaur> herton: oh, hrm...I wonder if breaking people to fix others who's sound never worked in the first place is an acceptable trade-off
<herton> mdeslaur: yeah, may be we'll just revert the fix, I'm going to take a look at it if there is some we can do on lucid to have both cases fixed, if not revert it
<mdeslaur> herton: cool, thanks :P
<mdeslaur> herton: if you need any testing, let me know
<herton> ok, once I have something I'll let you know
 * herton -> lunch
 * ogasawara back in 20
<GrueMaster> ppisati: My mirror is currently at 325G, but it is only arch armel/armhf/all binaries.  I do not currently mirror source.  Initial mirror setup and pull can take a weekend, depending on your bandwidth and the bottlenecks between you and the original source (I would assume ports).
<GrueMaster> My mirror is a 1U rack system w/ 4-1T sata drives in a soft raid (apparently, most SATA raid controllers are software raid, with software raid drivers for Windows - hence the raid marketing).
 * ogra_ guesses armhf doesnt actually take much space yet :P
<mpoirier> ogasawara: good day
<ogasawara> mpoirier: hi
<mpoirier> ogasawara: I have a brain bug this morning
<mpoirier> ogasawara: ages ago you have me a make command to upgrade a target config .
<mpoirier> something like make updateconfig
<mpoirier> but I can't remember...
<ogasawara> mpoirier: fdr updateconfigs
<mpoirier> ha !
<mpoirier> fantastic thanks.
<ogasawara> fdr == fakeroot debian/rules 
<mpoirier> yep.
<sforshee> cking, didn't you have something to execute an AML method and get the result from the command line?
<ppisati> mpoirier: any chance you give me an update on that patch i asked you?
<cking> sforshee, yep, lemme find it for you
<ppisati> GrueMaster: just 325GB???
<ppisati> GrueMaster: entire armel repository?
<GrueMaster> ppisati: Armel, armhf (which I expect to almost double the sixe), and arch-all.
<mpoirier> ppisati: you asked me for a patch ?
<ppisati> mpoirier: i think i did... wait a sec...
<ppisati> GrueMaster: i expected to take much more space... uhmm...
<cking> sforshee, git://kernel.ubuntu.com/cking/systemtap-scripts.git
<GrueMaster> ppisati: As I said earlier, no source (yet).
<ppisati> mpoirier: subject "Patch review/comment (from O to P)"
<sforshee> cking, thanks
<cking> sforshee, in acpi-eval, you can hack that script 
<ppisati> mpoirier: i think the patch is not needed anymore, but i wanted you to give it a look
<mpoirier> ppisati: that was in an email ?
<ppisati> mpoirier: yep
<cking> sforshee, you may like to also use the amltrace script too, perhaps a combo of both
#ubuntu-kernel 2011-11-17
<iceroot> https://bugs.launchpad.net/linux/+bug/869502  please have a look here (patch available)
<ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
<CrazyThinker> Hey
<CrazyThinker> What tool should I use to display the inode structure of the entire filesystem
<smb> Not sure I understand the exact output you want. I don't know of anything that would get you a tree-like output of all inodes. For just the inode number, ls -i would be enough. And debugfs lets you manually explore things (and be potentially dangerous)
<CrazyThinker`> smb, but isn't there a tool to visualize the whole thing?
<smb> CrazyThinker`, As I said, not that I know of, but it could still exist. Though I could imagine that sizes usually are so big that you need a quite big wall to put it up there. 
<CrazyThinker`> oh okay
<smb> Bugger, its 10:35UTC. LP is offline...
<cking> bugmail time then
<smb> cking, Was more going to have a coffee break
<smb> Don't think bugmail will run either
<tkamppeter> Hi, I have reported bug 872711 and there an SRU for Oneiric was proposed, tested, and verified. When will the new kernel (3.0.0-13) make it into -updates?
<ubot2> Launchpad bug 872711 in linux "Kernel does not report some USB printers correctly, making them not being detected by CUPS" [High,Fix committed] https://launchpad.net/bugs/872711
<smb> tkamppeter, The SRU calendar says something about next week. If nothing (regressions) happen
<tkamppeter> smb, where can I see the SRU calendar?
<smb> tkamppeter, It is a google calendar but I am not sure whether it is public
<smb> tkamppeter, "Ubuntu Kernel" if that helps
<smb> tkamppeter, seems it is named "Ubuntu Kernel Schedule" correctly and seems to be public...
<apw_> tkamppeter: normal plan is a week of verification, a week of qa testing, so if no problems then 2 weeks from when you are asked to verify
 * ppisati thinks has the first batch of cfg sync for P/omap4
<apw_> ppisati: sounds great
<ppisati> apw_: wait to see the diff... :)
<apw_> ppisati: ogra mentioned some squashfs options, are you aware? 
<ppisati> apw_: uhm no
<ppisati> but since the skew between master and omap4 is sooo large
<ppisati> i'm doing it incrementally
<apw_> ppisati: perhaps poke him and find out :)
<herton> smb: I noted now that the ec2 jumped from 319 to 340 abi, not sure if worth to fix now that the package is already built in the ckt ppa
<herton> tgardner: bugs 872179 and 745836 are waiting for verification until tomorrow
<ubot2> Launchpad bug 872179 in linux "ipv6: restore correct ECN handling on TCP xmit" [Undecided,Fix committed] https://launchpad.net/bugs/872179
<ubot2> Launchpad bug 745836 in linux "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [High,In progress] https://launchpad.net/bugs/745836
<tgardner> herton, I cleared the verification tags for bug 872179
<ubot2> Launchpad bug 872179 in linux "ipv6: restore correct ECN handling on TCP xmit" [Undecided,Fix committed] https://launchpad.net/bugs/872179
<herton> mdeslaur: hi, about bug 875300, are you available with the machine to do a test for me?
<ubot2> Launchpad bug 875300 in linux "[Realtek ALC268] ALSA test tone not correctly played back (regression in lucid from 2.6.32-33.72)" [Medium,Triaged] https://launchpad.net/bugs/875300
<mdeslaur> herton: could you give me an hour to reinstall lucid on it?
<herton> mdeslaur: yep, no problem
<mdeslaur> herton: cool
<tgardner> apw, ogasawara: bouncing gomeisa for kernel update, ok?
<apw> tgardner, ok for me
<ogasawara> tgardner: ack,
<apw> ogasawara, i've taken the liberty of pulling the meat of the conifiguration review 'data' out of the config review spec
<apw> ogasawara, with a view to us having a copy of each one we use for updates as separate pages
<ogasawara> apw: ack
<apw> ogasawara, i am also moving to suppressing the uninteresting entries in the various sections
<ogasawara> apw: cool, that'll help speed up future reviews
<mdeslaur> herton: what do you want me to test?
<tkamppeter> apw_, smb, thanks, in the user space packages is only the week of verification and no week of QA, now I know why it takes so long.
<herton> mdeslaur: I need you to do confirm something, with the broken kernel. Download ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.4.tar.gz, build it, then run this commands:
<herton> sudo ./hda-verb /dev/snd/hwC0D0 0x14 SET_EAPD_BTLENABLE 2
<herton> sudo ./hda-verb /dev/snd/hwC0D0 0x15 SET_EAPD_BTLENABLE 2
<mdeslaur> herton: ok, give a 15 minutes, and I'll do that
<herton> And then check if after the commands you have sound
<herton> ok
 * herton -> lunch
<diwic> herton, fyi, I have hda-verb packaged up in my ppa together with a few other tools in the snd-hda-tools package
<diwic> herton, *reading scrollback* hmm, not for lucid though
<mdeslaur> herton: after those commands, I do have sound
<lifeboy> Would this be an appropriate channel for getting help with troubleshooting compiling a custom kernel for 10.04?
<mdeslaur> herton: is there any thing else you need me to test?
<mdeslaur> herton: oh, did you get my last comment?
 * ogasawara back in 20
<herton> mdeslaur: hmm didn't get it, probably my connection dropped, what was the result?
<mdeslaur> herton: I confirm sounds works after those two commands
<herton> ok thanks, that confirms what I expected, the eapd is needed on your hardware. Now, on the other bug report from which came the regression, I'm not sure now why it's needed the auto config model, may be the other dell machine (910) doesn't like the eapd setting...
<apw> ogasawara, a few more inconsistant config item WIs added for you :/
 * lifeboy is then just going to ask and hopes someone will respond with a solution
<mdeslaur> herton: fwiw, the oneiric kernel works fine on my mini 9, and has the same commit in it
<lifeboy> I'm trying to compile a kernel with r6040 ethernet support by using debuild, but debuild ignores/overwrites my .config.  How can I fix this so the kernel is built with the change I want?
<bjf> lifeboy which version ? lucid/maverick/natty/oneiric ?
<bjf> lifeboy, have you looked at: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<herton> mdeslaur: that's interesting, I'm taking a look at oneiric, I run the codec from the bug and on oneiric it's enabling eapd (that's why works for you), probably somewhere else it's being enforced in oneiric
<mdeslaur> herton: huh, interesting
<smb> lifeboy, I think what you need is "fakeroot debian/rules editconfigs" where you modify those configs under debian.master/config which are the ones used . Any local .config would get ignored
<herton> (I mean, I run the codec against hda-emu)
<popey> apw: with regards to https://wiki.ubuntu.com/Kernel/PowerManagement - how long are you planning on asking for feedback on that?
<apw> popey, thats actualy cking's baby
<popey> ah
<cking> popey, probaby when we hit enough reasonable samples, maybe next week at the rate we are going
<cking> also, I'm waiting for some sample laptops to arrive to add my data ;-)
<apw> cking, i see that basically the table tells you lenovo have terrible bioses
<cking> apw, yep, which is kinda annoying as they should know better really
<apw> cking, can the fwts detect this?
<cking> apw, not yet :-(
<cking> it was on the blueprints of fwts things to do
<popey> cking: I was going to mention it on the podcast on tuesday, call for more people, which will go out on wednesday
<popey> (next week)
<cking> popey, well, ping me before you intend to do it, we may have closed the crowd sourcing down by then
<ogasawara> apw: I'm gonna flip ext2=m, sata_ahci=y, and disable aufs then do final test builds and upload.  any other config changes you think need to land before I upload?
<apw> disable aufs, thats brave
<popey> will do cking 
<apw> those are the main ones i recon for this next one
<apw> ogasawara, ^^
<cking> popey, by the way, great to have you on board :-)
<ogasawara> apw: I figured best to flip it off early and see who screams
<apw> ogasawara, indeed ...
<popey> thanks cking âº
<ogasawara> apw: I suppose I should maybe wait to upload it until after tomorrow's release meeting so to get input from outside parties
<ogasawara> which reminds me I need to write up and send out our kernel bits for tomorrow's meeting
<tgardner> ogasawara, have you run it on anything? I should try it on my HP mini since -rc1 hard locked on suspend.
<ogasawara> tgardner: not yet, was gonna get this final test build through before any testing
<apw> ogasawara, when you have some test build let us know where they are and we can get some testing on the kit i have here
<ogasawara> apw: ack
<tgardner> ogasawara, ditto
 * apw volunteers smb as well :)
<lifeboy> bjf: 10.04 Lucid
<ogasawara> nice, aufs is already disabled due to build failures
 * smb tries to hide his preciousss kit
<lifeboy> bjf: I've now tried to follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, but it also breaks!  I get to 'fakeroot debian/rules binary-headers binary-generic' and although I have a fresh clean sources dir, it says the source is not clean!
<lifeboy> btw, I'm trying to build a kernel for an LTSP client that needs R6040 ethernet support without cmov
<smb> lifeboy, Could you still have your .config in the top level directory ?
<lifeboy> Yes, shouldn't I?
<smb> No. The debian build does a make with external object tree
<lifeboy> Ah, it's probably because I initially followed https://help.ubuntu.com/community/Kernel/Compile
<lifeboy> Is this where I should use "fakeroot debian/rules editconfigs
<lifeboy> ?
<smb> lifeboy, Yes, that runs menuconfig on the various architectures (I think you can skip the ones you do not need with yes,no)
<smb> But it will make sure the right configuration files get updated
<lifeboy> smb: Thanks. It seems I'm eventually going to build my own kernel after all... 
<lifeboy> smb: to build a 32bit kernel on a 64bit machine, what to do I add to "fakeroot debian/rules editconfigs" since I only have 64 bit kernel configs to choose from?
<smb> lifeboy, For that you should best set up a (s)chroot environment with debootstrap that has a 32bit personality.
<smb> lifeboy, Hopefully this is still current enough: https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter#Building_in_a_chroot_environment
<lifeboy> yes, I have that.  I created the chroot with "ltsp-build-client arch=i386 dist=lucid"
 * lifeboy is reading smb's link
<smb> Then this is where you should do the build. uname -m should show i686 or so if done right. Otherwise the chroot needs to be started with linux32 (which schroot can do automatically)
<lifeboy> I haven't done this before, just familiar with the what LTSP scripts create.  uname -m shown x86_64.
<lifeboy> So I should read up on schroot?
<smb> Since I do not know anything about the ltsp scripts, I cannot give any good advice there. Not even sure how you switch into your chroot
<smb> If it is just calling chroot <path>, you may try linux32 chroot <path>
<lifeboy> Yes that what I do.  Either chroot /opt/ltsp/i386 or ltsp-chroot --arch=i386. Both do the same essentially
<lifeboy> Let me try
<lifeboy> linux32 chroot /opt/ltsp/i386
<lifeboy> root@Ashton:/# uname -m
<lifeboy> i686
<lifeboy> work fine, it seems
<lifeboy> editconfigs still only has configs like "amd64/config.flavour.generic? [Y/n] n"
<smb> lifeboy, Oh that actually goes over all of them
<lifeboy> although debian.master/config/i386 and other exist
<herton> mdeslaur: I found a fix which should be in Lucid stable updates (probably upstream forgot to apply it), and will fix your case. In fact I think reverting the other kernel patch would be ok also, I have doubts about it, reverting dell models with 02b0 subdevice id to auto, I suspect the user had a mixer setting issue, based on what I saw on codec configuration differences in hda-emu besides the EAPD issue. Anyway, seems the best action is cherry
<herton> -picking the missing fix for lucid (commit 5a8cfb4e8ae317d283f84122ed20faa069c5e0c4 upstream), and forget about it... I'll prepare and send the patch to kernel-team mailing list.
<smb> lifeboy, keep saying no to the amd64 ones
<lifeboy> smb: there are only three amd64 questions and then I get debian/scripts/misc/kernelconfig: line 130: /usr/src/linux-2.6.32/debian/scripts/misc/splitconfig.pl: Permission denied
<lifeboy> should I mark them executable?
<lifeboy> debian/scripts?
<lifeboy> brb
<smb> lifeboy, Likely yes. 
<lifeboy> that did it, yes
 * lifeboy is away: will be back later to report or ask for more help
<mdeslaur> herton: sorry, was on the phone. Yeah, that looks good...whatever you think is the best way to fix it is fine with me
<mdeslaur> herton: as long as people get sound back :)
<lifeboy> !smb
<ubot2> Samba is the way to cooperate with Windows environments. Links with more info: https://wiki.ubuntu.com/MountWindowsSharesPermanently and https://help.ubuntu.com/10.04/serverguide/C/windows-networking.html - Samba can be administered via the web with SWAT.
<lifeboy> !seen smb
<ubot2> I have no seen command
<lifeboy> Building a slightly custom kernel, after "fakeroot debian/rules editconfigs", is there any else I need to do to ensure the modified config will be used to build the kernel.deb?  I just ran "fakeroot debain/rules clean" \ and then "fakeroot debian/rules binary-headers binary-generic"
<lifeboy> It ignored the change I made the the config however.
<bjf> lifeboy: the fdr clean probably blew away your config changes
<lifeboy> sO I shouldn't do clean before I compile?
<lifeboy> It's just that all the docs I find say you should, but I guess they're not for custom configs...
<lifeboy> I just ran "fakeroot debian/rules editconfigs", made the changes to the 386....-generic config, ran "fakeroot debian/rules clean", went back to "fakeroot debian/rules editconfigs" and found all the changes still there.  Could it be something else causing the changes to be lost?
<lifeboy> bjf: ?
<bjf> lifeboy: not sure right off the top of my head, i'd have to play with it
<lifeboy> would I maybe need to run "debian/rules updateconfigs" after "editconfigs"?
<jjohansen> lifeboy: no that shouldn't be necessary
<lifeboy> I redid the process twice now, it I choose the -generic config by responding 'y' while I answer 'n' for the rest. The change it not applied to the kernel build.
<lifeboy> What am I missing?
<tgardner> sforshee, how should pgraner be reading his thermal values ?
<sforshee> tgardner, I have /sys/bus/acpi/devices/LNXTHERM\:00/thermal_zone/temp on my machine
<tgardner> sforshee, ok, I'll let him know.
<tgardner> sforshee, his wifi kill keeps getting set.
 * tgardner is EOD
<Kano> hi, whats the huge difference between 3.2-rc2 mainline to 3.2.0-2 git?
<Kano> with mainline i can run nvidia binary drivers on my intel boards (tested q35 and q67), but with precise git not
<Kano> master-next of course
#ubuntu-kernel 2011-11-18
<lifeboy> Hi all!
<lifeboy> Is there a channel log somewhere to go read?
<apw> tseliot, hey ... have you done any testing with 3.2 kernels as yet, for binary drivers
<apw> lifeboy, yes there are, something like irclogs.ubuntu.com
<tseliot> apw: no, not yet. Is 3.2 in precise or is it just in the mainline ppa?
<apw> tseliot, we're working up to uploading it, but i am worried about nvidia particularly for design peeps
<apw> tseliot, if i put a kernel in a PPA somewhere would that help
 * apw notes that kano was just complaining it works on mainline and not our kernel
<tseliot> apw: yes, definitely, I'll see if I can patch it
<apw> tseliot, ok so i'll get you a kernel
<tseliot> apw: thansk
<tseliot> *thanks
<apw> tseliot, are raw .debs ok?  that i can get you in much less time
<tseliot> apw: sure, as long as they are for amd64 ;)
<apw> anyone else having trouble with LP waiting on fonts.googleapis.com ?
<apw> tseliot, these are built from the tip of our tree: http://people.canonical.com/~apw/master-next-precise/
<tseliot> apw: excellent, thanks
<apw> tseliot, thank you for looki
<apw> looking at it
<ppisati> wasn't there a script to check if a release was closed properly?
<apw> ppisati, yep, erm ...
<apw> ppisati, stable/verify-src-package perhaps ?
<ppisati> let me try
<apw> i'd guess its meant to be against the source package though
<ppisati> uhm no
<ppisati> wait
<ppisati> i use that against the topic branches
<ppisati> perhaps it works in this case too
<ppisati> no wait
<apw> the rules should be the same
<ppisati> in the topic branches case i use the
<ppisati> kteam-tools/maintscripts/verify-release-ready
<ppisati> and in fact the release wasn't closed properly...
<ppisati> ok
<apw> cool
<apw> odd that its not in the same place ... sigh
<ppisati> btw stable/verify-src-package seems a complete different tool
<apw> joy
<apw> herton, just remembered, while you weer away a number of kernels ended up in universe.  not sure if they all got fixed correctly, may be worth checking
<ogra_> they are universal kernels !
<ogra_> :)
<herton> apw: yep, I noted some of those, and reported the problem on the tracking bugs, mostly all arm kernels ended up in universe
<ogra_> just ping an archive admin ... thats faster
<apw> herton, well all the otehre i think as well, i had everything moved for the master branches for everything back to lucid, i ma unsure if hardy got done or not, it was late
<apw> and hardy is more complex
<herton> ogra_: I usually do, but it's usually a recurrent issue, I don't know how the copy is done and why it happens
<ogra_> there is a command the admin runs, sometimes they miss the right option then the kernel goes to universe
<herton> apw: ah yes, for the master branches I looked I think on wednesday/yesterday and seems fine now
<ogra_> usually an oversight 
<ogra_> and quick to fix 
<tseliot> apw: can you reupload this file, please? http://people.canonical.com/~apw/master-next-precise/linux-headers-3.2.0-2_3.2.0-2.4~masternext201111180933_all.deb
<apw> tseliot, reupload it?  s is missing?
<tseliot> apw: or one which ends with 80936
<herton> apw: for hardy I think it didn't work, checking now it's still on universe (http://archive.ubuntu.com/ubuntu/pool/universe/l/linux/)
<apw> herton, i think hardy got missed as some do belong there and some not and steve wasn't sure
<tseliot> apw: I'm getting "short read on buffer copy for failed to write to pipe in copy"
<apw> herton, probabally should re-refer that one to pitti
<herton> ok
<tseliot> (also the file is 688kb)
<apw> tseliot, on it
<tseliot> thanks
<seanius> is there something extra that needs to be done to enable the linux-crashdump support?  i.e. do i need to tweak anything OOTB?  the Kernel/CrashDumpRecipe page doesn't seem to imply i
<apw> seanius, i thought it was something that needed enabling in /etc/default/somethng
<apw> other than that i think its meant to be automatic
<seanius> apw: yeah, i found /e/d/kexec in which kexec wasn't enabled
<seanius> which is what i was wondering about actually
 * apw isn't a crahsdump expert unfortuanatly, though i am asking abuot
<seanius> and *no*, this doesn't have aything to do with that custom kernel stuff i was asking about earlier :)
<apw> tseliot, ok there now should be a new one in there ... well in about 2:30
<seanius> what i really want is osmething like redhat's netdump support, but i don't think that exists in debian/ubuntu
<seanius> i.e. on crash scp /proc/kcore to a remote server, and reboot
<apw> thats a pretty nifty idea maybe you could file a bug suggesting it
<apw> it doesn't sound like so very hard
<seanius> heh, they were saying the same thing in #debian-devel
<apw> yep, we are small compared to redhat so we have less effort to focus
<seanius> could probably be done with the existing stuff and an extra initramfs hook
<apw> so we don't always see the obvious
<apw> i'd have thought so indeed
<apw> tseliot, there now
 * cking reboots
<seanius> hrm, panic seems to still panic, and i get no files in /var/crash
<seanius> is there any way to test the crash kernel without triggering a panic?
<tseliot> apw: ok, thanks
<apw> seanius, not that i know of
<apw> seanius, mostly people do that via sysrq
<seanius> apw: yes i can do that but it's not loading the crash kernel, hence my wondering.  kexec -p.... seems to work
<seanius> but i get nothing beyond that
<apw> what happens?  just normal boot ?
<seanius> that's just the "prepare" step afaict
<apw> when you ask it to start
<apw> you must be able to trigger it like you can a normal boot
<apw> when kexec is installed reboot uses it, i'd have thought -p and whatever it uses to trigger the start might work
<ogasawara> bug 888597
<ubot2> Launchpad bug 888597 in linux "linux-image-extra-3.1.0-2-virtual is uninstallable" [High,Confirmed] https://launchpad.net/bugs/888597
<ogasawara> apw, tgardner, smb`: so there are test debs for 3.2.0-1.1 on gomeisa in precies-amd64 and precise-i386 in my home dir, but I'm gonna try and fix up 888597 and then respin tests
<apw> ogasawara, ok will wait on that
<apw> ogasawara, i have just been talking to tseliot about checking the nvidia binary drivers
<apw> ogasawara, as that will affect a lot of design people if it doesn't work
<apw> ogasawara, we may want to wait till he reports back before uploading
<ogasawara> apw: ack.  also because we've merged server into generic, I also wanted to pick your brain about the best approach for fixing up linux-meta in terms of the control.d files
<apw> ogasawara, ok so is it just called generic now ?
<ogasawara> apw: yep
<apw> ogasawara, wil have a poke in a bit and see whats what
<ogasawara> apw: awesome thanks
<ogra_> why do you keep the -generic tag at all ?
<ogra_> if we only have one kernel that feels somehow redundant
<apw> we still ahve two, generci and virtual
<ogra_> ah
<apw> and getting rid of it to add it back when someone makes a new one is confusing too
<ogra_> indeed
<tseliot> apw: the latest driver in precise seems to work well with linux 3.2 (at least with the one you gave me)
<apw> tseliot, nvidia binary drivers yes ?
<tseliot> apw: yep
<apw> tseliot, would you be interested in testing fgrlx ?
<tseliot> apw: sure, even though I'm going to update them, either today or next week
<apw> will give us some confidence in the viability of our new kernel at least
<tseliot> apw: I can already tell you that the fglrx module builds, I only have to see if it segfaults ;)
<apw> tseliot, :) just bound to work
<tseliot> :)
<tgardner> ogasawara, I updated the precise chroots on gomeisa
<ogasawara> tgardner: ack
 * herton -> lunch
 * ogasawara back in 20
<apw> ogasawara, http://status.ubuntu.com/ubuntu-precise/group/topic-precise-kernel-essential.html <-- should represent the release critical blueprints
<ogasawara> apw: awesome, did that just recently appear?
<apw> i made it about 5 hours ago yep, and its finally in the output :)
<tgardner> ogasawara, 3.2.0-2-generic - at least suspend now works again on my HP mini
<tseliot> apw: fglrx works well too :)
<apw> ogasawara, ^^ so i think thats both binary drivers tested :)
<ogasawara> apw: cool.  do you want me to pull in that last config change you pushed to master-next before I upload
<ogasawara> apw: I think I might wait till we have the linux-meta bits sorted as well
<apw> ogasawara, the config changes i am pushing are not urgent or important
<ogasawara> apw: k, I'll leave it for the next one then since I've already prepped the master branch
<apw> yeah will look at that next, i suspect we want to keep the seaparation at the meta package level, so not a tranisitional package
<apw> should be pretty easy in theory, though we don't need it till the builds are complete anyhow
<ogasawara> apw: yah, I was hoping to keep it separate in case we do want to fall back to having a server flavor
<apw> ogasawara, how much testing have we had on those builds of your?  you were updating them last i looked and haven't seen if new ones are there
<ogasawara> apw: I kicked of the new builds, not sure if they've finished yet
<ogasawara> apw: been sidetracked with the release meeting
<apw> yep no worries
<tgardner> pgraner, tangerine.buildd:~rtg/ukb/oneiric/amd64/master-next/linux-image-3.0.0-14-generic_3.0.0-14.23_amd64.deb
<apw> ogasawara, i have just pushed an update to ubuntu-precise-meta which i think is what we want
<apw> ogasawara, obviously it still needs a version bump as and when
<apw> cking, are you aware of this page: http://status.ubuntu.com/ubuntu-precise/u/colin-king.html
<apw> cking, that has all your WIs regardless of blueprint, i note you have some duplicates by the look of it
<ppisati> i'm trying to package a new omap4 kernel for O, but can't get the debian* stuff right i.e. fdr printchanges is always empty
<ppisati> can anyone give it a look?
<ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
<cking> apw, ah, duplication, hrm, well I was unsure if the power management was a general placeholder for all things related to this kind of work
<ppisati> (btw i bumped abi to 1400 to distinguish it from O/omap4 kernels)
<apw> ppisati, if the previous version differs in the changelog then it won't find it
<apw> ppisati, and you just have to do the changelog bits by hand, common on the first upload for a release
<ppisati> apw: i think i did it
<apw> you can see how its done in the debian/rules.d
<ppisati> i can even build the first pkg
<apw> fdr printenv gives you hints if its not recognising the previous version
<ppisati> but now i would like to add some stuff on top of it
<apw> ?
<ppisati> but fdr printenv insist in using the OLD abi (1206)
 * apw pulls
<ppisati> and fdr printchanges is still empty
<ogasawara> apw: awesome, thanks
<ogasawara> apw: also test builds on gomeisa finished, feel free to pull the debs and test on any kit you have there
<apw> ppisati, do there are no new commits on here after the close ?
<ppisati> apw: nope
<ppisati> locally, didn't push them
<ppisati> wait
<ppisati> apw: pushed
<apw> ppisati, so if you want to make a .2 you need to open that with fdr startnewrelease, if you want to replace .1 then you need to rebase the .1 close commit out of existance
<ppisati> apw: why shall i obliterate the .1 close commit?
<apw> ppisati, which are you trying to do make a new .1 or move on to .2
<ppisati> move to .2
<apw> then you should be ading a startnewrelease
<apw> fdr startnewrelease, then commit that
<ppisati> ok
<apw> then you can close it to make .2
<ppisati> start new release add the boilerplate in debian.ti-omap4/changelog
<ppisati> but i don't understand why fdk printchanges doesn't show anything
<ppisati> ...
<ppisati> never mind
<ppisati> printchanges work only AFTER a new release has been opened...
<ppisati> "a storm in a changelog..."
<cking> power measuring gets a little repetatititititive after a while
<apw> ppisati, indeed so
<apw> cking, yep that why you need a program to do it
<cking> apw, true, but somebody has to install software, run the test, gather the data for different tests...
<ppisati> herton: how does ktl.ubuntu.series_name() knows if a version is in one release or in another one? does it use hardcoded values?
<herton> ppisati: yes, it checks the version/abi or the package name if necessary, and do the specific checks if needed (verifying abi number for ex.)
<herton> ppisati: eg. if it's linux-mvl-dove, it just checks abi and returns lucid or maverick
<ppisati> herton: ok
<ppisati> apw: one last thing, if you are still alive
<ppisati> apw: now it complains about "package linux-image-3.0.0-1401-omap4 is not in control info"
<ppisati> apw: http://paste.ubuntu.com/742485/
<ppisati> apw: and here is the pkg: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
<EtienneG> Beginner's question, guy's: the pae flag in /proc/cpuinfo, that means the CPU supports PAE, right?
<EtienneG> (I guess so, just want to be sure)
<jjohansen> EtienneG: yes if pae is listed then the processor should support PAE
<EtienneG> jjohansen, thanks!
<EtienneG> reason I asked is the discussion about dropping non-PAE kernel or not in precise.  Not sure if a final decision was made, but I want to be ready in case it is
<apw> ppisati, have you cleaned it properly
<EtienneG> by making an inventory of the machines that will be non-upgradable
<ppisati> apw: i think so
<ppisati> apw: let me try with a git clean -fdx
<apw> ppisati, have a look at the control.stub.in and make sure the base version is updated correctly
<ppisati> apw: ok, i'll do
<apw> ppisati, and check control afer a clean
<mfilipe> will Oneiric Kernel be update to 3.2?
<apw> mfilipe, no it will remain on 3.0
<mfilipe> apw, will be released any package to update the kernel to 3.2?
<jjohansen> mfilipe: probably not, there will be the backports kernels from the next releases Q, R, S but Q likely will be on of 3.3, 3.4, 3.5
<jjohansen> just depending on when the upstream kernels come out
<mfilipe> hum... 3.2 will have many improvements in energy management 
<mfilipe> anyway, I compile it if be necessary 
<ppisati> mfilipe: why don't you simply install precise kernel?
<mfilipe> jjohansen, apw: thanks for informations
<mfilipe> ppisati, precise kernel?
<ppisati> it's 3.2 based
<jjohansen> mfilipe: oh shoot you where talking Oneiric, and here I was thinking precise, there will be no backports for Oneiric, the are for precise
<mfilipe> http://packages.ubuntu.com/precise/kernel-image-3.1.0-2-generic-pae-di
<mfilipe> it is 3.1
<jjohansen> ppisati: err no its not
<mfilipe> when torvalds tree tagged 3.2 final release, will you update to 3.2?
<ppisati> jjohansen: well, not yet... :)
<jjohansen> right
<jjohansen> mfilipe: yeah we should move to 3.2, its 3.3 that will be skipped (/me was remembering the wrong revision)
<mfilipe> ok
<mfilipe> thanks a lot!
<ogasawara> mfilipe: I'm getting ready to upload the first 3.2 based precise kernel in just a bit
<jjohansen> ogasawara: oh really without binary drivers?
<ogasawara> jjohansen: was told that tseliot tested both nvidia and fglrx this morning on the 3.2 kernel
<jjohansen> ogasawara: ah, I hadn't heard that and was expecting those to be a pita
<mfilipe> ogasawara, but 3.2 stay like release candidate yet 
<mfilipe> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
<ogasawara> mfilipe: yep, we rebased to the latest 3.2-rc2
<ogasawara> mfilipe: we'll keep rebasing until 3.2 is final
<mfilipe> ok, nice
<apw> yeah unexpectedly they still work (the binary drivers)
<ricotz> the vbox dkms module will break though
<apw> ricotz, maybe so, they will need to sort it out 
<ricotz> apw, yeah, 4.1.6 should be compatible which is already in debian
<apw> ricotz, then it should get synced in the mass sync with luck
<ricotz> apw, it is still in testing so it wont :\
<ricotz> a manual sync would be nice here though
<ricotz> oh meant "unstable"
<GrueMaster> ppisati: I am seeing several missing CVE issues with the omap4 kernel on maverick (2.6.35).  I'll add them to the kernel release tracking bug.
<herton> GrueMaster: what CVEs are missing?
<GrueMaster> LP #729839 is one.  I have 7 failures, some are CONFIG_ features that are not enabled.
<ubot2> Launchpad bug 729839 in linux "PR_SET_PTRACER does not work from a thread" [High,Fix released] https://launchpad.net/bugs/729839
<GrueMaster> I added a log to bug 888569
<ubot2> Launchpad bug 888569 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.27 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/888569
<GrueMaster> test-kernel log now added as well.
<sforshee> ogasawara, do you have a 3.2-rc2 precise build somewhere that I can get at easily?
<ogasawara> sforshee: yep, check on gomeisa in my home dir under the precise-amd64 or precise-i386 dirs
<sforshee> ogasawara, thanks, now I don't have to wait for a build :)
 * herton -> eow
<arges> sforshee, who would be the wifi guru to talk to , just was able to reproduce https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250
<ubot2> Launchpad bug 836250 in network-manager "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Invalid]
<sforshee> arges, the bug is assigned to tgardner and he's the most knowledgeable about wireless anyway, but he's not around right now
<arges> ah, yea I just got hit with it when I tried a new router
<sforshee> arges, you should probably grab dmesg and syslog while you're seeing the symptoms as a starting point
<arges> Yea, there seems to be quite a bit of info in the bug... so trying to determine if I won't just be adding a 'me too' case to it
<sforshee> arges, also you might look at http://linuxwireless.org/en/users/Documentation/Reporting_bugs for some things you might want to try
<sforshee> although it seems most of the stuff there is geared towards problems associating, not performance problems
<arges> Cool. I might add some info. One thing was looking at iwlist/iwconfig etc its not obvious which wireless 'mode' i'm connected to 802.11a/g/n etc
<arges> so I was trying to just figure out how to switch modes from my laptop to isolate it being an 'n' issue vs 'b/g' which is what I've been seeing switching the modes on the router side.
<arges> the workaround in the bug seems to agree since it just involves disabling n mode on the laptop. 
<arges> by disabling it in the module
<sforshee> arges, if you look at the bit rate in iwconfig you can probably guess at which mode it is
<sforshee> i don't know a definitive way to tell though
<arges> yea that's what I was figuring
<arges> ok
<sforshee> there's probably a better way to tell, i just don't know what it is
<Sarvatt> no more brcmsmac driver in 3.2.0-1?
<mjg59> It moved from staging. The config may not have been updated.
<arges> sforshee, so I installed ogasawara's 3.2-rc2 kernel in my system using dpkg -i and its not showing up in grub, do I need to do something special to get that entry made? It looks like it was doing the hooks for the grub update
<sforshee> arges, update-grub should be run as part of the installation, but I guess you could try running it manually just to be sure
<sforshee> arges, also run 'dpkg --get-selections | grep ^linux' and make sure the packages really are installed
<arges> sforshee, yea checked if it was installed first nad it is... will re-run update-grub
<arges> trying again...
<sforshee> ogasawara, did you see the above comments about brcmsmac?
<ogasawara> Sarvatt, sforshee: thanks, have added an item to our config blueprint for brcmsmac.  will look into it on Monday.
#ubuntu-kernel 2011-11-19
<bromichaelhenry> hello, does the ubuntu-kernel support linux-abi?
<pk> On an Asus Zenbook, I'm trying newer kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/. 3.1.1 works fine but 3.2 rc1 and rc2 won't boot. Ideas? ASPM? Any way to debug?
<pk> Screen just goes black (no backlight) and doesn't come back on 
<fishor_> hallo all, i work on uvcvideo driver. my primer interest is troubleshooting, make easy to gather need information for bug report. currently we added debugfs interface to get some statistic like error rate and so. my next step is to add a "report" interface...
<fishor_> this will include video stream format, resolution and frame rate. i think also to add a dmi.boardmane to track upsidedown cams
<fishor_> are there any one here how managed uvcvideo bug report, are you have any wishes or ideas?
<lifeboy> Compiling a Lucid kernel: originally did "apt-get source linux-image-2.6.32-35-generic",
<lifeboy>  then re-extracted the sources with "dpkg-source -x linux_2.6.32-35.78.dsc"
<lifeboy> and marked debian/scripts executable.
<lifeboy> I then use "fakeroot debian/rules editconfigs", edit "generic" config to add the drivers I need,
<lifeboy> then run "fakeroot debina/rules clean" followed by
<lifeboy> "fakeroot debian/rules binary-generic".
<lifeboy> I get
<lifeboy>       read 2799 modules : new(1)  missing(297)
<lifeboy> EE: Missing modules (start begging for mercy)
<lifeboy> make: *** [module-check-386] Error 1
<lifeboy> What's wrong with this?  All I want to do is get the sources, enable r6040 ethernet driver, compile and have a new kernel.
<lifeboy> I'm putting all my console output logs to pastebi, but since the logs are big, I've put each step in a different paste
<lifeboy> step 1: http://pastebin.com/hpQZd327
<lifeboy> step 2: http://pastebin.com/ATndWsXj
<lifeboy> step 3: http://pastebin.com/fsP35Miv
<lifeboy> step 4: will follow soon
<lifeboy> step 4: http://dl.dropbox.com/u/12668653/part4.paste (too big for my pastebin)
<lifeboy> anybody around on a Saturday without too much to do?
<javier__> hi, i want to know what i have to do if I want to modify a kernel with the default programs I want and then make an iso with it
<javier__> please tell me
<javier__> i am going to learn the linux kernel
<javier__> and i want to know where to start
#ubuntu-kernel 2011-11-20
<ermo> this is a crosspost from -server:
<ermo> How do I interpret the Ubuntu kernel versions? And what do I do if I'd like to get the latest patches to the 3.0 kernel (i.e. 3.0.9) but with the ubuntu patchset/configuration?
<ermo> Oh. I guess http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html answers my question :)
<pk> Hmm so how can I get a 3.2 (rc2 or newer) kernel, with ubuntu and own patches? the oneiric kernel git sticks at 3.0.0
<pk> Could I use the Precise git tree?
<kortsi> i'm having problems after upgrading from maverick to natty - natty does not seem to recognize my HP Smart Array P600 - running natty with the maverick 2.6.35 kernel now instead - any ideas?
<kortsi> oneiric server amd64 install cd does not recognize the controller either
<dolguldur> hi all
<dolguldur> I'm trying to modify some tcp/ip stack configuration variables
<dolguldur> especially tcp_max_syn_backlog and somaxconn
<dolguldur> it seems that modifying these variables through /proc/sys/net/... has no effect at all
#ubuntu-kernel 2012-11-12
<cking> smb, make deb-pkg INSTALL_MOD_STRIP=1
<xnox> is peromnii readyboot stuff proprietary? as presented at korea linux forum
<xnox> ogasawara: I am looking at the useful http://reqorts.qa.ubuntu.com/reports/ogasawara/weatherreport.html but it looks like it's still looking for quantal.
<xnox> Can you please s/quantal/raring/ ?
<janimo> apw, is there some doc about how to ship firmware files from a kernel package?
<janimo> I see patches in the quantal-backport branch that add a file and touch firmware/Makefile
<janimo> but there must be some extra scaffolding I guess
<janimo> generating fwinfo under  abi/
<ogra_> janimo, please dont ship the firmware in the kernel, ship it separately
<apw> i'd be looking at that one for sure, as it must have everything you need
<janimo> ogra_, what did that change again?
<ogra_> i thought that was clear since last week
<janimo> apw, yes it has everything I just don't know what exactly to look at
<janimo> ogra_, to me it seemed we do it the fastest via kernel and decide later if we want to reorganize
<apw> janimo, i know of no docs indeed.  rtg did the work and has been waking up about now :)  so i'd poke him
<ogra_> janimo, unless you know how to hack up the kernel packaging to also show license debconf notes etc
<janimo> apw, thanks
<janimo> ogra_, the thing was discuseed last meeting and that we do not need to show anything on package install
<janimo> just in the installer or on cdimaer
<ogra_> if we have to show it in the installer we need to show it at package installation
<janimo> according to achiang 
<ogra_> people can install the package on any arm system to use/inspect it 
<ogra_> if we have to show the license at install time there is no way around to show it at package install time
<apw> damnable binary junk
<ogra_> if we dont have to show it at package install tiome we dont need to show it in the installer either
<ogra_> as i understood it we need to show it if we distribute the files 
<janimo> ogra_, I am not sure about what to show when, just that it was decided at last meeting I ship it in the kernel package and if anyting comes up later we fix that
<ogra_> so the license needs to be shown for any way we distribute 
<ogra_> janimo, remember i had hangout issues last meeting
<janimo> ogra_, that was not my impression after all the back and forth talk honestly, but I would not be surprised by another change of stance
<ogra_> but if we dont show it on package install time i will drop the WI for the installer too
<janimo> ogra_, yes, drop it I'd say
<janimo> and we can put it back if someone request it
 * ogra_ thought everything was clear after the longish discussion on IRC 
<janimo> victorp I think had the final word
<janimo> and I think achiang too agreed
<janimo> nothing is clear when it comes to 'damnable binary junk'
<ogra_> and neither of them is around 
<janimo> I just hoped copying frimware files in the tree would just install them, but as this is kernel packaging things are not that simple
<ogra_> just use a .install file
<ogra_> though i really think we should keep the closed firmware separate from the open kernel
 * xnox though linux-firmware-nonfree was the package for blobs....
<ogra_> xnox, yes, but that is generated from our kernel tree
<ogra_> which we dont use in nexus7 
<ogra_> linux-firmware-nonfree-nexus7 is what we should have imho
<ogra_> and meta depending on it
<xnox> sounds sensible.... but then I don't do kernel packaging.
 * ogra_ only does it if teher is no way around it :)
 * henrix -> lunch
<apw> herton, i see in your original drafts of the 3.5-stable thing it was ubuntu/linux-stable.git, but in your announcement i see ubuntu/linux.git ... i wonder at the change
<herton> apw, it's where you/rtg recomended last week to put the branches on, at ubuntu/linux
<apw> herton, i don't recall that, i recall being asked if that tree was safe to use as a --reference
<apw> i don't recall discussing where to put those branches, or more specificially i didn't realise that was what i was discussing
<smb> apw, It was what I understood in that discussion
<apw> well crap, sounds like i wasn't listening very well
<smb> Or the two of us... ;)
 * janimo also does kernel packaging if there's no way around it :)
 * apw reads the logs ... ok i only said about reference and then didn't comment again
<apw> clearly i didn't listen at all :)
<apw> to add to the discussion, my only worry is that i have been storing all the u* tags in there which might be very confusing for anyone looking at the repo for stable stuff
<herton> yeah I don't know, it's not immutable, I can change the URL later, and put the right one when I start to do the releases if needed
<apw> i guess i could evict those to another repo as well
<herton> I mean, we can revisit where we put things if needed
<apw> herton, while on the subject do you have a tag naming scheme in mind, are you just going to use v3.5.x or something else
<herton> apw, what I plan is v3.5.7-ext.<number>
<herton> ext meaning "extended"
<apw> that feels difficult, i wonder if we could just use v3.5.8u or u3.5.8 and onwards
<apw> though that last would clash with my naming
<apw> though we could ask for the v3.5.x range from greg and just use that
<BenC> apw: Too quickâ¦I was starting dput with the right change...
<BenC> I'll exit and merge yours
<apw> BenC, hopefully i did it right
<herton> apw, well the only reasoning I chose that is to reflect more reality, we are not upstream stable, and if they unlikely decide to release a new v3.5 we don't clash. I think Greg will ignore us as always, or deny the use of v3.5.y
<apw> as it takes a long damn time to build
<BenC> If only it had picked the other buildd, it would have been half the timeâ¦two flavours used to take only 2.2 hours on that buildd, so 4 flavours shouldn't take 8 hours :/
<apw> we never get lucky
<BenC> Thanks for the upload though
<apw> BenC, it was a mostly selfish action to try and get britany to be happy, but you are welcome
<apw> BenC, dunno if it makes sense for me to have rights on your repo so i can help in these siturations; your call
<BenC> apw: as long as I can pull from ubuntu-raring:ppc it all works out just as well
<apw> ack
<BenC> apw: do you have a github account?
<apw> BenC, yeah awhitcroft
<apw> BenC, also while i think about it, do you have a repo for -meta or is that just apt-get source job
<BenC> apw: I've added you to the repo
<apw> BenC, thanks, i will try not to need to use it
<BenC> apw: added you to that repo as well
<apw> herton, so ... perhaps v3.5.7u1 u2 etc
<apw> something nice and short
<herton> works for me, that's ok as well
<herton> and looks nicer indeed
<BenC> ogasawara: linux-ppc exists now, btw
<ogasawara> BenC: ack, thanks.  I'll have jsalisbury look at moving bugs over tomorrow when he's back from today's holiday.
<BenC> Thanks
<apw> herton, remind me how i check whether i have applied things to the right bits in hardy, there is a magic incantion
<herton> apw, hmm let me check, I have to remember as well :)
<apw> must be validate-patch-range
<apw> herton, ahh got it ...
<apw> apw@dm:~/git2/ubuntu-hardy$ debian/scripts/misc/validate-patch-range HEAD^ HEAD
<apw> f1b33e80f6bcc2f6b3c7edc4ceafab5466fbd33c: not ported to openvz
<apw> f1b33e80f6bcc2f6b3c7edc4ceafab5466fbd33c: not ported to xen
<herton> apw, and use apply-patch-to-binary-custom to apply them
<herton> then just fold the changes on top
<apw> herton, awsome ... works like a charm
 * smb wonders how much sense those make, but well if there is a simple way to get them
<caribou> smb, got a question about the SRU query I just sent to the list
<caribou> or anyone else that care to answer
<smb> So let it hear and we let you know whether we care :)
<caribou> regarding hpwdt, should I have included a diff of the config files instead of just listing the config options ?
<caribou> smb :)
<caribou> smb: since I supposed that those options would end up being setup by editconfigs anyway
<smb> caribou, Usually its nice to have the patch as well. Just for life being simpler that way
<caribou> smb: yeah, thought of it as well but wasn't too sure which config files was targeted precisely
<caribou> smb: ok, will  do next itme
<caribou> s/itme/time/
<smb> Probably having them added to the main ubuntu configs file and run updateconfigs and then check the result
<caribou> smb: ok will do
<BenC> apw: Almost a winnerâ¦fixing it now
 * apw cries
<BenC> apw: I disabled pccard in my last upload and didn't remember that d-i would be affected. Is there a way to disable a d-i package for just one flavor?
<BenC> Honestly, I don't think pcmcia even matters on any of the powerpc flavours for udeb's
 * ppisati -> gym
 * henrix -> EOD
<kees> apw: any thoughts on my checkpatch change on lkml for the CONFIG_EXPERIMENTAL removal warnings?
#ubuntu-kernel 2012-11-13
<BenC> apw: success
<apw> kees, poke me tommorrow, i am off today
 * henrix -> lunch
<caribou> rtg: Regarding hpwdt, it's already in ./config/config.common.ubuntu for Q & R; should I mark it "Fix released" ?
<rtg> caribou, too late
<caribou> rtg: :-) didn't refresh quick enough
<BenC> apw: cjwatson says you two talked about the lack of arch-all builds for linux-ppcâ¦what was the verdict?
<caribou> rtg: thanks
<bambee> hi , on quantal, with a core i7 ivy bridge (Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) ) I always get this error in dmesg
<bambee> [19327.764996] [drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0
<bambee> my screens change from a normal mode to black... randomly...
<bambee> any ideas?
<bambee> It worked just fined on precise
<apw> BenC, ok i believe you need to switch the architecture:all things to :powerpc
<bambee> it's a regression introduced in quantal
<apw> and then there is a switchable
 * smb slaps apw
<apw> smb, i know, shhh
<rtg> apw, you're already out of bed? I thought you fancied a lie in today.
<apw> BenC, I believe it is do_common_headers_indep should be false
<apw> BenC, you should be able to test that on a local build building binary-arch
<BenC> apw: Ah
<BenC> thanks
<apw> BenC, do_flavour_header_package turns it on and off, and do_common_headers_indep says if it is :all or :<arch>
<apw> rtg, i am not here, you cannot see me, your meds are affecting your eyesight
<rtg> apw who ?
<apw> rtg, i am really doing my tax return which is so much less stressfull
<smb> arrrrrgh
<smb> At least now its understandable why you cannot resist irc
<apw> exactly ... anything is better than that
<smb> apw, Already wearing the paper suit?
<apw> smb, yep, socks paired the whole 9 yards; thinking of painting the wall using my toothbrush
<smb> :)
<smb> rtg, Ok, I think if the v01 on the IVRS table means what I think it means, I only have a v1 iommu
<rtg> smb, I can always drop that patch until it can get properly tested.
<smb> rtg, No, actually I think it should be ok as it is creating a new module that in theory should only be used on affected hw and since it is sru it won't survive stable testing without verification (normally)
<rtg> smb, that presumes that stable testing has a xen host
<smb> rtg, Actually I think that even is independent of Xen. Though I am not sure how much these things are used normally. At least we would expect whoever filed the bug to have the hardware and let us know
<xnox> ogasawara: at uds, in passing, I've asked you if it would be possible to pull some patches and build experimental kernels for me. The condition was "do the patches apply cleanly".
<xnox> well they do.
<ogasawara> xnox: sure, send me an email with the list of patches and I'll build you a test kernel
<xnox> I pushed them to git@github.com:xnox/linux.git the ubuntu-raring-master-f2fs which is on top of ubuntu-raring master
<xnox> or I can format patches.
<xnox> ogasawara: awesome. thanks.
<ogasawara> xnox: sweet, I'll just build from your tree
<ogasawara> xnox: I'm assuming you need an amd64 build?
<xnox> ogasawara: I want it for i386, amd64, armhf (panda, ac100, nexus7)
<ogasawara> xnox: ack
<xnox> ogasawara: the last three being most important, as it's the new flash filesystem  I want to play with and I have that hardware available.
<xnox> ogasawara: send the "pull & build" request to your work email.
<ogasawara> xnox: thanks
<xnox> ogasawara: thank you =))))
<rtg> bjf, can you try a kernel from http://kernel.ubuntu.com/~rtg/3.7-rc5.1 on your Lexington Emerald Ridge again ? 
<rtg> ogasawara, can you do some smoke testing on http://kernel.ubuntu.com/~rtg/3.7-rc5.1 ?
<ogasawara> rtg: yep, will do
<rtg> 'tanks
<bjf> rtg, will do
<cking> me too 
<rtg> cking, thanks
<rtg> bjf, I'm seeing similar pcpu_alloc faults on an AMD server
<cking> rtg, what kind of hardware shall I exercise this on, I've got plenty to chose from
<rtg> cking, I suppose whatever doesn't require a signed kernel
<rtg> cking, I'm starting a bisect for 'PERCPU: allocation failed' because its starting to show up more often
 * cking wonders what's tickling this bug
<rtg> cking, multiple CPUs perhaps ?
<cking> hrm
<rtg> this is a 2-way AMD. bjf saw it on a 4-way Romley
 * cking will expercise it on a bunch of SMP kit
<cking> expercise? exercise, doh
<rtg> cking, I didn't even notice until you corrected it :) you see what you expect to see.
<smb> rtg, Do the percpu messages say something more (like which module)? Sounds like something doing bigger dynamic percpu variable allocations...
<rtg> smb, [    7.261175] kvm: Could not allocate 304 bytes percpu data. So it might be https://lkml.org/lkml/2012/10/11/198
<smb> rtg, Hm, maybe. Hmm, maybe depending on the maximum possible cpus not the available ones... Otherwise it sounds weird that your 2way has the same issue with it than the 40core box...
<smb> But at least the same problem with kvm module now loading automatically...
<rtg> smb, I'll try it with that commit reverted
 * smb wodners what version weed some people smoke,,,
<rtg> smb, drifting in your window ?
<smb> rtg, more on my keyboard. While wondering about the 2.6.0 version
<smb> rtg, fwiw I don't see the same on Quantal running on my 4 core i7
<ogasawara> rtg: works on my test kit here which are a mix of amd64 and i386 and ranging from full raring installs, quantal installs, and precise+enablement stack installs.  I did quick boot tests, pings out to the network, audio, and suspend/resume on the laptops.
<rtg> ogasawara, did you check dmesg for PERCPU allocation failures ?
<ogasawara> rtg: yep, I didn't see any, but I did see an interesting error on my adamo which is a Precise + enablement stack -> "Request for unknown module key 'Magrathea: Glacier signing key: d
<ogasawara> 185d6ac223b0843daf202524618aa134d085f80' err -11"
 * ogasawara back in 20
<rtg> ogasawara, dkms ?
<rtg> smb, reverting e9bda3b3d0ce775afe15eaf71922d342cc74991c didn't fix it. guess I'll use some mainline kernels to do a gross bisect.
<smb> rtg, Hm, ok. Though it was so tempting to think about it as the allocation size just was exactly the same
 * smb cannot believe do-release-upgrade was broken that badly in Quantal (or even is for the textual version)
 * cking can't seem to trigger any PERCPU issues as yet
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<ogasawara> rtg: it shouldn't be dkms related on this laptop, I'll try and see if I can track down the root cause.
<rtg> ogasawara, did it fail to load, or just complain ?
<ogasawara> rtg: just complained.  everything seems to be running fine as far as I can tell.
<rtg> ogasawara, prolly OK to ignore it then
<janimo> rtg, all kernel packages should depend on linux-firmware?
<rtg> janimo, no. why do you think so ?
<janimo> rtg, just that the dep got autogenerated it seems in the nexus7 package as well
<rtg> linux-firmware is seeded for our install images
<janimo> rtg, also because maybe some usb wifi or other peripherals can be used on any system
<rtg> janimo, which is why it is seeded
<janimo> Depends: linux-image-3.1.10-7-nexus7, linux-firmware
<janimo>  in linux-image-nexus7
<janimo> I need to see where that came from then
<bjf> rtg, i am not getting those errors any longer on the emerald ridge. still no console though
<rtg> bjf, I'm finding it on this AMD as far back as Quantal. I've yet to find a kernel where it doesn't happen.
<jsalisbury>  ** Ubuntu Kernel Team Meeting Happening Now in #ubuntu-meeting
<cking> blink and you've missed it
<jsalisbury> :-)
<xnox> wow. Ubuntu kernel meetings are really rt meetings.
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 20th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * smb offline for tinkering...
<ppisati> rtg: (quantal-amd64)ppisati@tangerine:~/ubuntu-raring$ dpkg-buildpackage -us -uc
<ppisati> [snip]
<ppisati> dpkg-checkbuilddeps: Unmet build dependencies: libunwind8-dev libaudit-dev
<ppisati> doesn't happen when building armhf tough
<rtg> ppisati, why wouldn't you use a raring chroot ?
<ppisati> ah
<rtg> ppisati, and armel is gone
<ppisati> right, we are in raring...
<rtg> for raring
<ppisati> nevermind
<ppisati> yeah, saw that
 * ppisati -> EOD
 * rtg bisects between 3.5.0-rc1 and 3.5.0-rc2 for PERCPU allocation failures
 * rtg -> lunch
<infinity> Hrm.  Have we finally reached a critical mass of "too many kernel SRUs to QA in a timely fashion", or did UDS (and recovering from it) just throw off the cadence a bit?
<henrix> infinity: i believe the delay is due to bug #1076963
<ubot2> Launchpad bug 1076963 in Launchpad itself "SPPH.getPublishedBinaries timing out" [Critical,Triaged] https://launchpad.net/bugs/1076963
<bjf> infinity, there were other factors, we'll get caught up i think
<infinity> rtg / janimo: (looking at backscroll) all image metapackages absolutely do depend on linux-firmware...
<infinity> rtg / janimo: Which seems correct, so I'm not sure what Jani's question was about.
<janimo> infinity, it was just a curiosity really, thanks
<infinity> janimo: Mmkay.  On a platform where you definitely knew you didn't need any of the firmware, dropping that dep from your meta would be fine.  Though, that's clearly not the case for nexu7, where we're doing weird things like attaching all sorts of USB thingees to it. :P
<infinity> (And, realistically, won't be the case for any kernel we support as a generic computing device, as opposed to some phone/tablet preinstalled mojo)
<janimo> infinity, I agree,
<infinity> henrix / bjf: Alright, cool.  Was more a curiosity thing than anything else.  And wondering if you guys needed to multiply at some point. ;)
<arges> sforshee, hi
<arges> sforshee, re: 922906. Those set of 9 patches are in linux-next, do i need to wait until they land in Linus' tree to SRU?
<sforshee> arges, that's usually preferred but not mandatory
<sforshee> arges, they've been in linux-next for several releases though, something needs to be done to get the ball rolling upstream too
<arges> sforshee, ok. what can I do to get the ball rolling?
<sforshee> I suppose ping Eric Paris and ask why he hasn't asked Linus to pull them
<arges> ok
 * rtg hates it when a bisect fails to produce a reasonable result
 * rtg -> EOD
<arges> sforshee, any idea where that tree is? is this on kernel.org? i'm assuming its something fsdevel?
<sforshee> arges, I found it earlier ... just a second
<sforshee> arges, http://git.infradead.org/users/eparis/notify.git
<arges> sforshee, awesome thanks. i couldn't find it via google and the usual places
<sforshee> arges, within the linux-next repo there's a file called Next/Trees that shows all the repos that linux-next pulls from
<arges> ah
<vanhoof> ogasawara: hola
<ogasawara> vanhoof: konichiwa, call?
<vanhoof> ogasawara: sure you free?
<ogasawara> vanhoof: ya, gimme 1min
<darkxst> currently vmware/vmplayer fail to install on raring due to a moved file (version.h) in the kernel headers, would it be acceptable to work around this with adding a symlink in the headers package  until vmware catch up with the changes?
<jjohansen> apw, ogasawara: https://lkml.org/lkml/2012/11/12/446, this may be affecting our lower memory images (/me is thinking arm)
<apw> jjohansen, thanks ... P and up huh
<jjohansen> yeah: apparently it took quite the effort for google to track that one down
<apw> jjohansen, if they are seeing it, then "low memory" may be not as low as we might think
#ubuntu-kernel 2012-11-14
<jjohansen> apw: this was on the chromebooks I am hearing if the machine has 2G or under
<jjohansen> so yeah not that low
<BenC> apw: Finally, a build we can all be proud of
 * ppisati feels a bit sick today...
<apw> ppisati, sounds bad ... your football team lose ?
<ppisati> apw: yes, last weekend, but i don't think it's related
<ppisati> normal flu, i think i'll survive.. hopefully... :)
<jibel> cking, I tested lxc with kernel 3.5.0-18.29-lp1065434, transfered data over different links, shutdown/restarted the container multiple times successfully while I can reproduce the bug reliably with the version of the kernel in 12.10
<jibel> cking, it sound like it resolves the "waiting for lo to become free" issue
<cking> jibel, so that looks like a reasonable fix then :-)
<apw> bug #1065434
<ubot2> Launchpad bug 1065434 in linux (Ubuntu) ""unregister_netdevice: waiting for lo to become free. Usage count = 1" after LXC container shutdown" [High,Incomplete] https://launchpad.net/bugs/1065434
<cking> jibel, if you can update the bug report and I will SRU it
<jibel> cking, sure, I'll update it with the tests I did. thanks for the fix!
<smb> infinity, still awake?
<xnox> I am seeing video/graphics degradation in kvm on raring-host&guest https://launchpadlibrarian.net/122917285/lightdm-grey-boxes.png
 * xnox ponders of any good ways troubleshooting that
<apw> henrix, hey ... i assume it is you doing the puloads for the current SRU cycle ?  when might i see a linux-lts-quantal 
<henrix> apw: yep, i am working on that.
<apw> henrix, great indeed
<henrix> apw: the quantal packages are pretty much ready for -proposed
<henrix> apw: after they are in proposed, the bot should create the bug for the -lts. 
<apw> henrix, gotcha
<henrix> apw: i may start working on the -lts today
<apw> henrix, cool, if you could start with the Q backport out of all the derivatives, as it will help expedite secure-boot testing in P
<henrix> apw: ack
<henrix> apw: ah! problem is that we still have a few kernels pending from previous cycle. and linux-lts-quantal is one of them
<apw> henrix, what is holding it back ?
<smb> jodh, Would you know from the top of your head how I would make an upstart job depend on a certain device? "tty-device-add DEVICE=hvc0" is not complaining, but neither really seems to not work if I change the name to something that does not exist...
<jodh> smb: that should be "tty-device-added DEVNAME=hvc0" I think.
<smb> jodh, Ah ok, likely DEVNAME to be what udevadm test prints out
<jodh> smb: correction, it should be "tty-device-added DEVNAME=*hvc0" (asterisk added)
<jodh> smb: the need for the asterisk being show by the output of...
<jodh> smb: awk 'BEGIN{RS="";ORS="\n\n"}; /UDEV.*\[/ && /ACTION=add/ && /SUBSYSTEM=tty/ { print; }' /var/log/udev
<smb> jodh, Ah there is that log already. I suppose it is the same ass the adevadm call shows. I think it is working now. Thanks.
<ppisati> apw: did you already create a config diff matrix among flavours for R?
<apw> ppisati, hmmm, not refreshed it since UDS, but which flavour you interested in
<ppisati> apw: ah, the uds one is good
<ppisati> apw: where is it?
<smb> jodh, What confused me was some statement that the format would be something like <subsystem>-device-<action>. (Or I did not read well enough) And then not realizing that "service x start" probably overrides any start on magic
<apw> ppisati, http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/UDS.html
<apw> but bear in mind it has not derivates as we do not have any at even a slightly similar level
 * apw will try and get a 'current' one done in a bit
<jodh> smb: good catch! The man pages are incorrect on that point! I'll get them fixed...
<smb> infinity, So just to let you know that I have a newer version of the xen package for raring in zinc:~smb/4review which is adding some of the things agreed to at uds and some cves. If you would review and sponsor that you may ignore the currently uploaded one in proposed.
<smb> jodh, Ah, then at least something good came from my failure. :)
<rtg> apw, I see that linux 3.7.0-0.5 was accepted finally. I presume that means ppc et al are now consistent and we can upload at will ?
<apw> rtg, indeed it should mean exactly that ... phew
<rtg> apw, the regression I was chasing yesterday (PERCPU allocation failure) was actually introduced between 3.5-rc1 and 3.5-rc2, so I think we're clear to upload 3.7-rc5 later today. Do you have anything you want in the upload ?
<rtg> ogasawara is working on some haswell crack, but I don't think its ready.
<rtg> and it might be for Quantal anyways
<apw> rtg, i think everything i wanted is on there, just be aware there are changes in there for the common headers package (for ppc) which should not change a think on master, but just be aware
<apw> s/think/thing
<rtg> apw, this one ? "UBUNTU: [Config] Use SRCPKGNAME as prefix for indep linux headers package"
<apw> rtg, yeah, in theory it is a noop on master, and a quick review still looks ok, and i have tested it, but it was ported to your cleanup of that code
<apw> but just worth checking those in your test build
<rtg> apw, yeah, I looked at it yesterday. seems fine
 * henrix -> lunch
<rtg> apw, please review ubuntu-raring-signed. Is there anything one needs to do besides just uploading it ?
<apw> rtg, that looks fine, other than tagging it, uploading it should do the trick; it will depwait on the main binaries
<rtg> apw, OK. I was waiting to tag it until after your review
<apw> rtg, guessed as much indeed
<apw> literally making sure the version number is right, you found 'update-version' i assume
<rtg> apw, um, no. I used 'dch -i'
<apw> there is a scripty to copy the right version from the master repo: ./update-version ../ubuntu-raring stylee
<rtg> apw, I backed up one commit and ran update-version. It did the same as I did )by hand), so I guess I got it right.
<apw> rtg, indeed, it looked similar enough i assumed you had used it :)
<apw> it does emit the tag commands etc for you to make life easier
<rtg> apw, oh well, I'm used to doing those by hand anyways. tagged, pushed and uploaded.
<apw> rtg, thanks
 * rtg will be back on in a bit
<arges> smb, hey
<smb> arges, hi
<arges> smb, I see that you fixed pad.lv/322737 a long time ago.  I think bug 1070182 might be related since it is the same network driver. 
<ubot2> Launchpad bug 1070182 in linux (Ubuntu) "8086:10f5 Can't connect to the network through a wired connection - Network dialog shows "Wired Cable unplugged"" [Medium,Confirmed] https://launchpad.net/bugs/1070182
<smb> I did... must be a longer while
<arges> smb, I think you made a sauce patch to fix this then, should I try and reapply the sauce to the newer version to see if it fixes the issue?
<smb> arges, maybe you also could just refresh my memory with the subject of the patch I did and a release
<arges> smb, sure   * SAUCE: Add support in e1000e for a couple of ICH10 PCI IDs  
<arges> smb, added support for intel 82567LM 
<smb> That probably was hardy...
<arges> oh yea 8.04
<smb> and usually just adding pci ids
<arges> smb, so do I need to fix this in linux-ubuntu-modules? or is this in linux ?
<smb> I think back there it was lum, which do not exist for any recent kernel
<arges> yes
<smb> And remember that only adds pci ids
<smb> not sure whether that matches the problem of that other bug
<arges> smb, the error seen in dmesg is exactly the same
<smb> Ok, so might be just not attaching then...
<smb> arges, Though the e1000e driver is loading.
<rtg> henrix, I assigned bug #1072163 to you. Please see if you can drive it to some sort of conclusion.
<ubot2> Launchpad bug 1072163 in linux (Ubuntu Raring) "Lack of fsam7400 kernel module in quantal" [Medium,In progress] https://launchpad.net/bugs/1072163
<smb> So it looks like the pci id would be causing the probe but some checksum is not what is expected.
<henrix> rtg: ack. i've seen it before, but couldn't find too much time to dig into it
<henrix> rtg: basically, we don't want to fix it, i.e., we don't need that driver
<henrix> rtg: there's an upstream driver with same functionality (actually, there are 2), and with the same prob
<arges> smb, #define E1000_DEV_ID_ICH9_IGP_M_AMT             0x10F5  <--- yea its in the driver
<rtg> henrix, I'm fine with that. mark it invalid or won't fix with an appropriate explanation.
<henrix> rtg: ack. i'll try to focus on that bug later today (or, more likely, tomorrow)
<arges> rtg, http://patchwork.ozlabs.org/patch/197479/
<hallyn> smb: hey, could you give your opinion on whether bug 1078305 should be deemed a kernel (bridging) bug, or just a legitimate quirk which libvirt should work around?
<ubot2> Launchpad bug 1078305 in libvirt (Ubuntu) "source IP address of broadcast packets gets rewritten when using NAT" [Undecided,New] https://launchpad.net/bugs/1078305
<smb> hallyn, not quickly I'd need some time to understand the thing
<hallyn> smb: ok.  i just don't want to work around something in libvirt if it's actually a kernel bug.  i'll comment in the bug for nwo.
<apw> hallyn, ok ... we really need to have confirmation of the network topology, and the iptables rules in use here
<apw>   337 20220 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
<apw>    31  2296 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
<apw>     1    40 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24    
<apw> hallyn, so if his setup is default (ie matches mine) then i think it is doing what these rules tell it
<hallyn> apw: for some reason i'm having a really hard time reasoning about this bug this morning
<apw> hallyn, could we rewrite these instead of using !192.168.122.0 ... so like -out !virbir0 -in virbir0 or something
<rtg> smb, iptables -vnL -t nat
<apw> hallyn, have you got a test rig for this ?
<hallyn> apw: no
<hallyn> apw: been out a few days, just saw this bug sitting there today
<hallyn> apw: but, his observatiosn seem actually backward, right?
<hallyn> the values are NOT masqueraded when usin 192.168.122.0, but are when using 0.0.0.0
<hallyn> uh, s/0/255/g
<apw> hallyn, well from what i can see the kernel is doing what was asked, if you use 255.255.255.255 as a destination then it must be rewritten
<apw> hallyn, right and that matches his complaint, that if you send to 192.168.122.255 then no rewrite occurs
<apw> and if you use 255.255.255.255 then you need to do masquerade whcih will rewrite the source address
<apw> the rules are just not right in that sense
<henrix> rtg: you have a 'start new release' commit on ubuntu-precise-meta. was there something you wanted to get into this package?
<henrix> rtg: ah, its a commit from 19th oct, so you probably don't remember about it anymore :)
<henrix> rtg: actually, it was on precise-lbm, not -meta
<hallyn> apw: ok, thx.  i'm not sure how easy it is to fix the way you suggest (as it's somewhat hardcoded in libvirt), but i'll mark as not affecting kernel :)
<apw> hallyn, am playing with some rules now to see if i can even write what we want written
<apw> hallyn, well in theory you can make the bridge outside of libvirt and use that prebuilt one
<apw> hallyn, and it is possible they are just wrong and should be fixed for everyone
<hallyn> apw: yes, i think it's wrong upstream, if that's what you mean.
<apw> sudo iptables -t nat -I POSTROUTING 1 -s 192.168.122.0/24 -d 255.255.255.255 -j RETURN
<apw> hallyn, i would be interested to know if the above also sorts it out
<hallyn> <shrug>  i'll ask in the bug
<rtg> apw, what model N7 did we get? the 16GB one ?
<apw> rtg, i believe so yes
<apw> its on the end of the box if that helps
<rtg> apw, you mean the box I left in Denmark ?
<apw> yeah that one.  mine cirtainly is 16
<apw> rtg, ok ... i am seriously considering reinstating the common headers package for -lowlatency so disconnect it from master ... else lack of updates for it prevent linux from moving to -updates
<apw> rtg, now that we have the template with ppc its pretty easy to do
<rtg> apw, so that would make it the same as ppc , right ?
<rtg> fully decoupled ?
<apw> yes, that indeed
<rtg> go for it
<rtg> apw, the N7 rootfs image is giant. I'll likely be at it for awhile
<apw> rtg, that sucks
<apw> rtg your -1.6 upload is dropping depwait on libaudit-dev
<rtg> apw, which is a tools build dependency
<rtg> what do you mean 'dropping' ?
<apw> rtg, i mean it doesn't exist so linux is not building
<apw> E: Unable to locate package libaudit-dev
<rtg> apw, ugh, wtf ? I'm sure I installed it.
<apw> Raringreleaseon 2012-10-18universelibs
<apw> if you could read that you'd see its universe, so needs an MIR for the build to succeed
<rtg> apw, ah, shit
<rtg> apw, I think x86 perf tools will build without it. lemme check
 * apw muses as to why all his pastes get shafted like that
 * ppisati -> EOD
<SpamapS> is there some reason there are no mainline kernel builds for precise past 3.4 on http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<rtg> SpamapS, 'cause we started using the quantal config for 3.5, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-quantal/
<SpamapS> rtg: ah ok, so you'd expect the latest 3.6.6 to work on precise?
<rtg> SpamapS, I see no reason why it wouldn't
<SpamapS> rtg: I had thought there were firmware changes in quantal
<rtg> SpamapS, there were for some devices. I've packaged those updates with the distro backport, but mainline doesn't have them
<SpamapS> gotchya
<infinity> smb: I can poke at that today, sure.
 * rtg -> lunch
 * henrix -> EOD
 * apw wanders somewhere more comfortable ...
<infinity> bjf: Is shankbot just lagging on updating https://bugs.launchpad.net/ubuntu/+source/linux-lts-backport-oneiric/+bug/1068230 or has something gone pear-shaped with the rebase promotion logic, perhaps?
<ubot2> Launchpad bug 1068230 in Kernel SRU Workflow "linux-lts-backport-oneiric: 3.0.0-27.44~lucid1 -proposed tracker" [Undecided,In progress]
<herton> infinity, it's waiting on oneiric linux bug to be promoted to updates
<infinity> herton: Oh, that's the wrong logic, IMO.  It should just wait on the promotion tasks being set.
<infinity> herton: Otherwise, I'll just pre-empt the bot and promote without it setting the tasks, cause I'm not going to do this in two passes. :P
<herton> infinity, I can change that, my understanding was that we wanted that behaviour, at least in case there was some dependencies between the binaries, which isn't the case
<infinity> herton: The only place where there's actually a dependency between binaries is lowlatency->master (which just got fixed to no longer be true in raring).
<infinity> herton: But even then, if all the promotion tasks are set together, one can assume that the packages will also get promoted together.  I don't tend to make more work for myself when I don't have to. ;)
<herton> np, I'll fix the bot later to just wait for confirmation of the tasks instead of the current behaviour
<infinity> Shiny, thanks.
<infinity> We can test it next cadence.  This time, I'll just preempt the bot and DTRT.
<herton> ack
<jsalisbury> rtg, ogasawara, This was just assigned to the canonical kernel team: bug 1078861
<ubot2> Launchpad bug 1078861 in ubuntu-nexus7 "Rebase kernel to the branch shipping with Android 4.2" [Medium,New] https://launchpad.net/bugs/1078861
<ogasawara> jsalisbury: I'll assume jani just opened that as a tracking bug and will do the work there
<jsalisbury> ogasawara, ahh, ok
<rtg> ogasawara, I'm having a look
<rtg> ogasawara, bjf: by the way, I just pushed the lts-backport-raring branch to precise
<ogasawara> rtg: ack
<bjf> rtg, so does that imply there is an upload happening real-soon-now ? will this be happening in the x-swat ppa like quantal?
<rtg> bjf, I'm assuming so, though the PPA name is disingenuous
<bjf> maybe there should be a "hardware enablement" ppa
<rtg> bjf, I'll upload later tonight and also send a note to bryceh asking about PPA naming. Maybe they want to start a whole new one.
<bjf> rtg, ack
 * rtg -> EOD
<infinity> herton: Do you know who's responsible for the regression-testing task on https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068573 ?
<ubot2> Launchpad bug 1068573 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1604.6 -proposed tracker" [Medium,In progress]
<infinity> herton: Would be nice to get that one done and released before starting all over again with the new Q kernels in the PPA.
<herton> infinity, not sure, but I think our QA was doing the testing on armadaxp kernels, bjf ikepanhc  ^
<infinity> (Not that it's critical that it be released before we start on Q, it just gets a bit harder to keep it all straight when the flavours are out of sync)
<bjf> infinity, QA is doing it. i know they were running into some issues today with HW
#ubuntu-kernel 2012-11-15
<dlbike76_> Hi I'm running kernel 3.5.0-18-generic on quantal and am seeing instances where the kernel is killing the chromium tasks
<dlbike76_> Is this a known problem?
<dlbike76> I'm running lubuntu on a computer with limited RAM, and I didn't notice the problem while on precise.
<dlbike76> I'm seeing the kernel sending sigkill to the various chromium tasks in the kern.log once memory usage gets to a certain point.
<RAOF> dlbike76: That would presumably be the OOM killer?
<dlbike76> RAOF:  OOM?
<RAOF> Out of memory killer.
<dlbike76> Gotcha.
<RAOF> ie: We've overcommitted, and now something wants to cash the check for memory that we don't have, so we need to kill something.
<dlbike76> Should that happen even if swap hasn't been fully utilized?
<ohsix> yea ...
<ohsix> swap can't always service memory requests
<ohsix> you can adjust the overcommit ratio
<ohsix> though at best it will probably get you a machine that runs slower for a long time before something is finally killed :]
<ohsix> chrome seems faster in part due to the way it uses memory to do its work, you might get more out of the situation with a browser not based on webkit
<dlbike76> It's working pretty good otherwise.  I'll just have to multitask less...
<ohsix> you can tell firefox how many images to keep decoded before discarding them, and how much of the back/forward cache to keep around; lots of knobs that won't get you around not having enough memory
<dlbike76> I've been experimenting with various browsers to see which ones work best for the limited RAM that I currently have.
<dlbike76> My biggest problem is that I went from a system with over 3GB RAM to a system with approx 300MB.
<ohsix> fun, i had to use my netbook when my laptop broke once :] could barely start the firefox session i regularly used, and do anything else
<dlbike76> So is OMM Killer something new in the 3.5 kernel? 
<dlbike76> I don't remember this ever happening in 3.2, but I do remember the system slowing to a crawl at times.
<ohsix> it's not new, it's probably just a coincidence that you're noticing it kill chrome
<dlbike76> Okay at least I know that it is working correctly.  Thanks for the help ohsix and RAOF.
<smb> infinity, Hiya, somehow I think there was not time to look at the xen package?
 * apw yawns
 * smb remembers to make more tea
<infinity> smb: Oh, uhm.  Indeed.  I got sidetracked with a bunch of other stuff.
<infinity> smb: Say, you have a new core-dev on your team, you should make him review and sponsor. ;)
<smb> infinity, I asked him about another package and he hasn't done it for a whole week... :-P
<smb> apw, ^ ;)
<infinity> smb: A whole week?  Man, what a slacker.
<apw> you all smell
<infinity> (... says the man who's had a review pending for Andy for months)
<Laney> hello kernelers ... :-)
<Laney> I noticed that with the new raring kernel I don't have aufs or overlayfs or whateveritis any more ... is that deliberate?
<Laney> also modprobe says this "FATAL: Could not load /lib/modules/3.7.0-0-generic/modules.dep: No such file or directory"
<apw> Laney, i suspect its expected, undesired, i'll check a bit later
<Laney> apw: OK, I'll go back to 3.5 then for now, cheers
<petantik> Hello, I'm trying to debug the ubuntu kernel with kgdb over serial. How can I get a vmlinux file from the vmlinuz file so I can load it into gdb? or does the vmlinuz work fine?
<einonm> petantik: Are you not building the kernel from source yourself?
<petantik> einonm: I am but not using upstream kernel sources 
<petantik> einonm: einonm using the instructions here https://help.ubuntu.com/community/Kernel/Compile#Alternate_Build_Method:_The_Old-Fashioned_Debian_Way
<einonm> So do you have a vmlinux image in your build directory. I'm not overly familiar with that way of building the kernel, but there should be a vmlinux produced after building. 
<petantik> what I'm trying to figure out is how to generate a vmlinux file instead of a vmlinuz file
<petantik> einonm: let me check
<einonm> The vmlinux file is generated before the vmlinuz file, and is used to generate the vmlinuz file
<petantik> einonm: you're right, definitely a pebkac moment.
<petantik> cheers
<einonm> np :)
 * henrix just received a build failure email for a build that is still pending...!?!?
<henrix> apw: any idea what happened here? ^^
<henrix> apw: it was an armel build for 3.2.0-34.53
<apw> henrix, the build may have failed due to buildd failure (say they rebooted a buildd) and then someone put the build back for rebuilding
<apw> so what you see if it pending for rebuild
<apw> henrix, got a pointer to the build
<henrix> apw: yeah, but the link sends me to the "Lost something?" thing :)
<apw> henrix, well that probabally means it was indeed retried, as we do lose the errors then
<henrix> apw: ok, so i'l just wait and see
<apw> which build was it, which series
<henrix> i've just build tested armel again and it builds without an error
<henrix> it was precise
<henrix> 3.2.0-34.53
<apw> henrix, yeah it seems to be building right now, so it must have been put back
<henrix> apw: ok, thanks. let's wait and see what happens
<rtg> apw, henrix: I restarted it 'cause it was a compiler seg fault
<apw> heh there you go then
<apw> rtg, i am working on fixing aufs and overlayfs in raring, so don't upload without me
<rtg> cking, could you give me a quick review of your batter patch on git://kernel.ubuntu.com/ubuntu/ubuntu-nexus7.git master-next ? I've rebased against a new release and there were some conflicts in your battery status patches.
<rtg> apw, ack. did you re-upload signed or do you plan to wait ?
<apw> rtg, no i didn't ... i will do that right now
<apw> oh perhaps i won't if that is holding us from breaking the images ... hmmm
<henrix> rtg: ok, thanks
 * henrix -> lunch
<rtg> apw, can't build dailies without overlay or aufs ?
<apw> rtg, they won't boot without as far as i know
<apw> rtg, i have some test builds ongoing, i am doing overlayfs first, as thats the default
<apw> if that works we can upload that
<rtg> apw, ok
 * ppisati switches to the haswell box (back in a bit)
 * henrix realises that herton is referred in lwn! \o/
<apw> henrix, link ?
<henrix> apw: it's on this week edition, kernel section: https://lwn.net/Articles/524304/
<henrix> apw: it's just the announment of the stable tree for 3.5 :)
<apw> heh ... good stuff
<apw> rtg, ogasawara, anything you want thrown in the next upload for raring ... i don't want to have any rebases in here really, as this enabled a heap of code
<ogasawara> apw: nothing here
<ppisati> ogasawara: did you put somewhere the list of patches that you showed during the delta review?
<apw> ppisati, normally that is in the spec for the blueprint
<ogasawara> ppisati: yah, in the spec.  lemme find the url for you.
<ogasawara> ppisati: https://wiki.ubuntu.com/KernelTeam/Specs/RaringKernelDeltaReview
<ppisati> cool, thanks
<apw> ogasawara, i have generated the 'per dev patch review' WIs and added them
<ogasawara> apw: sweet, thanks
<ogasawara> apw: I need to go through and update our milestone tracking too in our BP's since the new monthly checkpoints were added to LP
<apw> ogasawara, monthly what now ?
 * rtg actually made a nexus7 kernel that boots
<ogasawara> apw: there's the new monthly milestones now since we don't have alpha's
<ogasawara> apw: eg ubuntu-13.04-month-1 
 * apw hans rtg a pint ... well done
<ogasawara> apw: hrm, I'm also now seeing the alpha's there too.  I swore they were not there yesterday.
<apw> ogasawara, yeah, so we should be trying to fan out our WIs to the appropriate months
<apw> ogasawara, now all i need is some feeling for what month-1 etc means, any idea when they are
<ogasawara> apw: nope.  I checked yesterday to see if the release schedule had any specific date for what the month-1 deadline was, but found nothing.
<apw> ogasawara, the milestones themselves will have them, if i could remember where they are
<apw> https://bugs.launchpad.net/ubuntu/raring/+milestones
<apw> ogasawara, oh the alphas etc are 'optin' now
<apw> ogasawara, anyhow so its the 18th, -month-1 is like saturday, and so on
<ogasawara> apw: ah ok.  /me makes a note
<ogasawara> I never knew of the /+milestones url, that's helpful
<apw> ogasawara, me either, i just guessed, right for once
<cking> is that a new LP feature?
<apw> cking, don't think so no
<bjf> apw, due to the elegance and consistency of LP you can just naturally anticipate those features
<apw> it is the very first time that my guess found something, i am somewhat chuffed
<ogasawara> apw: you just happened to stumble onto a LP easter egg
<cking> I though the way to find out LP features was to grok the source
<cking> *thought
 * ogasawara back in 20
<cking> https://launchpad.net/launchpad/+specs  is interesting, all the eggs aren't in one basket
<apw> rtg, ogasawara, ok i have a kernel here with working overlayfs and aufs, so i am proposing to upload it now
<rtg> apw, lock and load....
<apw> BenC, i have just pushed a new raring master-next with working overlayfs which you need for your images to boot
<BenC> apw: Ah, thanks
<apw> rtg, when you build source pacakges do you do so on 32 or 64 bit chroots ?
<rtg> apw, generally both
<BenC> apw: Is that -2.8?
<apw> BenC, yes
<apw> BenC, i have literally just pushed the master repo, packages are being prepped now
<apw> though i am running it here on my kit
<apw> BenC, oh you may want to fetch again so that the master branch is updated, else the rebase script may not work, as i found out when i did lowlatency :)
<rtg> apw, what script ? ppc is a straightforward rebase against master isn't it ?
<apw> rtg, well it cannot be a strightforward rebase just because master is rebase as well, for lowlatency i use an update-from-master script which knows how to find the bottom of what to rebase etc
<BenC> Mine seemed to find the correct places to rebase against using the tag
<BenC> Maybe I'm lucky
<BenC> apw: Starting a build, so I'll follow up in a couple hours
<rtg> ogra_, are the nexus7 udeb files of any use ? the installer just blats an image onto flash, right ?
<apw> rtg, the d-i and netboot images use them don't they?  regardless of final installation method
<cking> I installed my n7 kernel  image from the .debs  - but hey, I don't know the official way its done
<rtg> apw, neither of which are useable by the nexus 7
<apw> rtg, then it seems unlikely they can be being used indeed
<rtg> lemme check with janimo
<rtg> ^^
 * ppisati goes out for a bit...
<stgraber> hello kernel people. The new linux-libc-dev broke libnl and in turn a bunch of universe packages.
<stgraber> I'm now working on a patch to libnl's netlink-kernel.h to deal with the change and would appreciate one of you confirming it's the correct approach
<stgraber> the debdiff for libnl would be: http://paste.ubuntu.com/1360658/
<rtg> apw is likely the most informed about header issues
<apw> stgraber, hi
<stgraber> I'm currently doing a test rebuild of sssd (one of the affected package) with the updated version of libnl to see if that does the trick
<stgraber> apw: hi
<apw> stgraber, oh god that is utterly vile
<apw> stgraber, it is clearly doing something which it should not, relying on the names of _ prefixed defines
<apw> stgraber, what you have done seems as appropriate for the new headers as for the old, but *barf*
<stgraber> hehe, well, upstream fixed that in libnl3 (different api) and redhat is in the process of porting sssd to using libnl3
<stgraber> so hopefully we can kill libnl1 soon and won't have that kind of problem again...
<apw> stgraber, but yeah i think you have no choice in your situation and you appear to have done something which means the right thing
<stgraber> good and the test build just succeeded so I'll push that to the archive now. Thanks for taking a look at the fix.
<apw> rtg, ogasawara, not sure who did the fold down last time we rebased, but when we did squashing aufs into its base patches (aufs-base and aufs-standalone) made it real complex to unpick and update
<apw> i've attempted to mark the ones which are annoying to lose separation on (no-squash) for next time
<rtg> apw, prolly me
<janimo> rtg, feel free to drop udebs
<janimo> I suppose ubiquity does not use them either in case we ever want a proper ubuntu installer
<rtg> janimo, already did, just uploaded to raring directly
<janimo> rtg, great
<rtg> janimo, also created nexus7 branch in ubuntu-raring-meta
<janimo> rtg, should I push the firmware package from PPA to raring NEW too or Are you looking at that too?
<janimo> rtg, nice, had no git tree for meta so far
<rtg> janimo, where is the firmware package ?
<janimo> in the ubuntu-nexus7 staging ppa raring pocket
<rtg> janimo, lemme have a look...
 * rtg -> lunch
 * henrix -> EOW
<slangasek> ogasawara: bug #1079385 looks like a duplicate of the overlayfs support issue; is there a master bug for this?
<ubot2> Launchpad bug 1079385 in upstart "init: can't start after load iso image on hyper-v server 2008 r2 sp1" [Undecided,New] https://launchpad.net/bugs/1079385
<slangasek> looks like 1079193
<ogasawara> slangasek: yep, that's the one we shoved in the changelog
<slangasek> ok, thanks
<BenC> apw: Can you help me out using insert-ubuntu-changes.pl?
<BenC> nm, figured it out
<infinity> BenC: Oh hey.  I wanted to chat with you.
<infinity> BenC: Specifically about the udebs you dropped from PPC...
<BenC> infinity: Yes?
<infinity> BenC: The pcmcia stuff is absolutely usable on Apple hardware.  Perhaps only disabling those for the e500 flavours would have made more sense than across the board?
<infinity> BenC: (And the 8250 stuff also worked fine in the past, and should still do...)
<BenC> infinity: unfortunately, there's no way to do that on a per flavor build
<BenC> I have it on my todo list to re-enable that once I create a mechanism that does what we need it to
<infinity> Hrm.
<BenC> The udeb's are empty on e500* so It's not like I could just ignore a few modules
<infinity> Yet another argument for "powerpc should have stayed in master, and only e500 should be out-of-tree"? :P
<infinity> Having e500 randomly break previously-working non-e500 setups seems suboptimal. :/
<BenC> I've not heard of any other arguments for such a case :)
<BenC> I did say I plan to fix it :)
<BenC> IMO, it's kernel-wedge that is suboptimal
<infinity> Yeah, I heard you.  I'm just thinking in the more general case.
<BenC> Also, having 8250 (for I assume serial console) be modular is less than desirable anywayâ¦I can't imagine anyone using that in a sane way
<BenC> My plan was to build it in on non-e500* to match up and not lose that udeb functionality, but I haven't decided yet
<infinity> It wouldn't generally be for consoles, most PPC hardware I know has onboard serial that isn't 8250.
<infinity> (Which, sure, also makes it less likely to be a useful udeb...)
<BenC> I couldn't really think of a legit use case
<infinity> Keeping the module but dropping the udeb is probably fine for the serial one.
<BenC> But I'll take your word for it that it's important :)
<infinity> For pcmcia, not so much.  Those are kinda useful.
<BenC> I've never heard of people using PCMCIA from powerbook's for things needed during install
<BenC> Except maybe networking, but is that something not available on most PowerBooks anyway?
<infinity> I could dream up a scenario where one might want an 8250 udeb to do some serial debugging or something weird, but it's pretty corner case, and not something I suspect anyone really cares about.
<infinity> PCMCIA for networking would absolutely be the use-case.
<BenC> Oh, wait, is airport on things like G5's attached to a PCMCIA port internally?
<BenC> I think it isâ¦so there's a good reason for having it
<BenC> G5/G4
<infinity> That's also possible, I dunno, but I was just thinking of the ton of powerbooks with crap internal NICs and PCMCIA instead.
<infinity> (Which was not an uncommon setup)
<infinity> Either way, we don't make a habit of telling people "if you don't use the internal NIC, you no get networking during install".
<BenC> Ok, I'll definitely work on getting PCMCIA udeb's back, and I'll mull over 8250
<infinity> Hence why we even have usb-network-udeb, etc.
<infinity> (Or whatever it's called)
<infinity> BenC: Of course, a rebase to -2 master is probably slightly more urgent, due to the overlayfs/aufs oopses in -1. :P
<infinity> BenC: No pressure, welcome back to the kernel team, etc.
 * infinity mails Ben a beer.
<BenC> infinity: sure thing, and you missed the opportunity to buy me a real beer
<BenC> Oddly, not many were willing to drink with me in Copenhagen
<infinity> You were a hard man to find after hours at UDS.  I could have just beered you at the smoke doors between sessions. :P
<infinity> (Or maybe I was the hard one to find?  I'm not sure...)
<BenC> I believe I was being avoided due to the bar having jaeger on hand
<apw> BenC, this new upload didn't get an abi bump, i cannot see how it could not have been; do you still have skipabi/skipmodules turned on ?
<apw> (not that it matters anywhere near as much on ppc as you likely have no dkms, but ...)
<apw> infinity, this whole kernels are (new) and linux-signed can't build till they are done crap really makes getting kernels built a long arduious process
<apw> it would be good to get the signed in, so we get new kernels in the live's
<infinity> apw: Yeah, yeah.  Hold your horses. ;)
<apw> heh thanks :)
#ubuntu-kernel 2012-11-16
<BenC> apw: I've purposely disabled ABI until the package settled downâ¦will enable it on next upload and do a -1 ABI bump
<dlbike76> Hi I'm seeing logs in kern.log like the following immediately before OMM-Killer kills my chromium task.
<dlbike76> Nov 15 20:41:09 artemis kernel: [ 1980.410410] type=1701 audit(1353030069.602:24): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=2060 comm="chromium-browse" reason="seccomp" sig=0 syscall=20 compat=0 ip=0xb2f76424 code=0x50000
<dlbike76> what does the above kernel message indicate?
<dlbike76> A link to documention would be appreciated.
<RAOF> dlbike76: That's the seccomp security filtering system kicking in. I'm not sure if there *is* documentation to point you at, sorry.
<RAOF> It's unlikely to be the cause of the OOM killer going on a rampage.
<dlbike76> RAOF: I just see it immediately before the OOM-killer.
<dlbike76> RAOF: and I'm partly just curious what the log is indicating.
<Sarvatt> I really wish I knew how to disable seccomp with a kernel command line option instead of having to launch chrome with --disable-seccomp-filter-sandbox so it didn't spam dmesg so bad :P
<RAOF> It's indicating that the process tried to do something that it shouldn't.
<dlbike76> RAOF: What does the debugging information in the log point to?
<RAOF> It says that pid 2060 (chromium-browse) from user uid=1000 (ie: you) had a syscall (specifically, syscall 20) denied.
<dlbike76> RAOF: What do the numbers in parens after audit refer to?
<RAOF> No idea :)
<dlbike76> RAOF: If I looked up the syscall number correctly then it refers to the epoll_create1 syscall.  Does that sound right?
<RAOF> Entirely plausible
<dlbike76> RAOF: I'm really wondering if that failed syscall is somehow indirectly causing the OMM-kill later.
<RAOF> I think that's unlikely.
<RAOF> More likely is that chromium is spawning a process, which during its initialisation harmlessly tries to do something that seccomp denies, then allocates too much memory.
<dlbike76> RAOF: Just to be clear, I wasn't suggesting that this was necessarily a problem in the kernel.  At least not at this point.
<dlbike76> RAOF: I am curious about what's going on in Chromium around the time that syscall is blocked though.
<RAOF> Probably process startup.
<RAOF> Which is going to dirty a bunch of memory, which is going to cause the OOM killer to kick in if you've got memory pressure.
<dlbike76> RAOF: I guess the docs referring to file descriptors are throwing me off.  I also haven't done any low level programming in awhile, so...
<dlbike76> RAOF: I can't reproduce the same thing in either firefox or midori, but then again neither of them spawn a bunch of child processes.
<RAOF> Nor do they use seccomp :)
<dlbike76> RAOF: I'm assuming that's related to the chrome-sandbox?
<RAOF> Chrome's sandbox uses seccomp, yes.
<dlbike76> RAOF: 
<dlbike76> RAOF: Yeah, that's what I meant.
<dlbike76> RAOF: Thanks for patiently answering my questions.
<dlbike76> RAOF: Oh, and I agree now that the seccomp thing and the OMM-killer thing are unrelated.  I think you described the situation pretty well.
 * ppisati notes that the messages indicator doesn't show up anymore...
 * apw finally finds his cve 'rebase' issue ... sigh
<apw> ppisati, as in no envelope at all?
<ppisati> apw: rigt
<ppisati> apw: right, i don't have the envelope icon at all
<ppisati> i just moved my desktop to the haswell box and reinstalled Q from scratch
<apw> hmmm ... try an apt-get install ubuntu-desktop^
<apw> ppisati, did you say Q ... i notice its gone here too 
<apw> ppisati, i hadn't noticed as i don't use any apps which use it
<ppisati> :(
<ppisati> skype is somehow broken
<ppisati> msn too
<ppisati> ok, i'm disconnected...
<apw> ppisati, /me is asking about the envelope on #ubuntu-unity
<ppisati> lemme join
<apw> ppisati, it seems it is normal if you have not yet run anything which uses it, trying to work out of this is a change or we are just unobservant
<ppisati> ?!?!
<ppisati> no no
<ogra_> ppisati, now that you mention it, i dont have the message indicator either on my raring install (on a chromebook though, i thought it was just arm fallout)
<ppisati> :(
 * ppisati wants to die
<ogra_> geez, you italians are always so fatal :)
<cking> its that bad is it?
<cking> apw, I want to build a kernel using "debian/rules build" and also set CHECK and CC so I can run smatch at compile time, any idea how I can easily do that?
<apw> cking, without modding debian/rules i don't think so
<apw> you might look at how CROSSCOMPILE is done for something we could apply
<cking> yeah, if only it was that easy 
<cking> no worries, I will hack around a bit more
<anon3> hello everyone
<apw> cking, ok there is a CC override, see LOCAL_ENV_CC
<anon3> can somebody give me adive? i would like to change the active sending behavior of IEEE 802.11 probe requests for an active ap search
 * cking looks
<apw> cking, see how that is done in debian/rules.d/0*
<cking> apw, thanks!
<apw> cking, and there might be where to add a new stanza for it too, as kmake is the right thing to mod
<anon3> my laptop is using the iwlwifi driver, i guess =)
<apw> anon3, hi
<anon3> hey apw
<anon3> the reason why i want to change the interval of sending probe requests: i'm writing my thesis about fingerprinting of individual devices with help of probe requests..(sorry about my bad english). therefore i have to analyze how a device is sending the probe requests and where is the sending behavior implemented
<apw> cking, i recon a LOCAL_ENV_SMATCH or something would work pretty well
 * cking nods
<anon3> i've found some interesting variable in /net/mac80211/scan.c   
<anon3> IEEE80211_CHANNEL_TIME (HZ / 33) and IEEE80211_PROBE_DELAY (HZ / 33)
<anon3> but, in nearly every kernel version the definition of these variables are the same, but the devices are sending in different intervals
<anon3> is here anybody who is well schooled in this topic? =)
<apw> anon3, well some devices do background scanning in firmware, so perhaps that is what you are seeing
<apw> those may only be used for devices with no firmware suppotr
<apw> but then i am no expert
<anon3> you mean those two variables i have wrote down?
<anon3> in scan.c?
<anon3> if the sending behavior is implemented in the firmware i won't have a chance to see the implementation?
<apw> yeah, i am pretty sure a lot of devices do scanning on their own
<apw> from the firmware, not necessarily from higher levels
<anon3> okay
<anon3> i've tried to edit theses variables and recompiled the kernel
<anon3> but that didn't make much effect
<anon3> so apw, thank you for your help and hints!
<anon3> have a nice day!
 * ppisati -> out for lunch
<hrw> hi
<hrw> I know that armel is dropped in raring but could kernel support it at least for headers?
<hrw> I need them for armhf/armel cross compiler
<ogra-cb> hrw, wouldnt that require that there is a buildd that builds the source targeted for armel ?
<ogra-cb> i dotn think we have that in raring
<hrw> ogra-cb: not necessary
<hrw> ogra-cb: I take linux-source-3.7.0 package and run dpkg-buildpackage -aarmel with some options just to get headers
<hrw> do not need it to be able to build kernel
 * ogra-cb doesnt think thats something you can easily do on a buildd
<ogra-cb> but i might be wrong
<ogra-cb> also how would you publish the resulting binary ? the archive doesnt have any armel support anymore
<hrw> armel-cross-toolchain-base does it
<ogra-cb> what ? publish a non existing arch ?
<hrw> check which binaries it generates
<ogra-cb> there is no more Packages.gz for armel, how would you provide it ?
 * ogra-cb thinks this discussion would be better suited for #ubuntu-release
<hrw> I do not publish arch:armel but arch:all packages
<ogra-cb> ah
<hrw> armel-cross-toolchain-base (actb in short) generates linux-libc-dev-armel-cross from linux-source-3.x.0 package as arch:all
<hrw> but for that I need partial support for armel
<ogra-cb> ah, k
<hrw> and this blocks whole arm{el,hf} cross compiler stuff
<hrw> aarch64 one is now pbuilding
<ppisati> has anyone ever experienced fs corption on the haswell box?
<ppisati> *corruption
<cking> ppisati, nope, not yet
<ppisati> when i came back, the fs was in ro and the screen was full of 'sda retry failed blablabla"
<ppisati> but not panic or oops
<ppisati> i'll try to catch it early next time, and scroll to the beginning of the carnage
<cking> ppisati, my earlier SDPs had flaky SATA connector plugs which caused errors like this
<ppisati> weird
<ppisati> becasue yesterday i had no prob at all
<cking> i blame every problem now on entropy
<ppisati> :)
<rtg> apw, here is a puzzler: https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+build/3988532/+files/buildlog_ubuntu-precise-amd64.linux-lts-raring_3.7.0-2.8%7Eprecise1_FAILEDTOBUILD.txt.gz
<rtg> I've seen this error before but can't remember what it was.
<apw> Compiling 49 OIDs
<apw> presumably that was meant to make the .c
<rtg> oid_registry.c is just a regular file
<rtg> oid_registry_data.c is the one that is generated
<apw> erp, then no that cannot happen :)
<rtg> maybe I'll just rerun the build
<apw> rtg maybe, i cannot see any reason it would go missing ... sigh
<rtg> i386 is already past that point in the build.
<apw> double erp
<rtg> I kind of hate instabilities on the buildds
<apw> i have heard of removing the /build directory being an approved way to stop a build; maybe something like that happened
<apw> i wish there was some way to tell if human intervention was the cause
<rtg> apw, well whats weird is that I've seen this exact same build failure before
<apw> rtg, so it has to be a parallel race somehow then ... but quite how
<rtg> apw, don't think so. its -j1
<rtg> apw, oh well, maybe I'll start grinding through all of the firmware issues
 * apw utterly fails to test steam
<apw> utter fail on my system, 3.7gb download to say "not compatible with your system"
<rtg> ya gotta love it :)
 * ogasawara back in 20
<Theodoros> Is the plan to ship 3.5 by default in 12.04.2?
<rtg> Theodoros, yes. The Raring kernel will get shipped in 12.04.3
<bjf> Raring != 3.5
<rtg> bjf, and 12.04.3 != 12.04.2
<Theodoros> Okay so after some false starts I was able to fully understand my issues with samba and 3.5 in precise
<Theodoros> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1075670
<ubot2> Launchpad bug 1075670 in linux (Ubuntu) "samba panics with sys_setgroups failed" [High,Incomplete]
<bjf> rtg, so "yes" meant what exactly? :-)
<rtg> bjf, yes meant that we _are_ shipping 3.5 in 12.04.2
<bjf> ack
<Theodoros> Thanks for the prompt answer btw :D
 * bjf is going to go soak his head
 * ppisati -> EOW
<apw> bjf, herton, fyi i have just uploaded an emergency linux-lowlatency identicle to that in -updates but with -pae enabled, this is going round the back and you can ignore it
<apw> i'll be doing the -34 version as soon as that is out of the way
<ogra_> so i heard there will be config 2normalization" for the nexus7 kernel
<ogra_> *s/2/\"/
<ogra_> it would be good to restrict that to modules for HW you can actualy attach to the device than making it to ubuntu generic like
<rtg> ograjust USB mostly, right ?
<ogra_> yeah
<ogra_> probably some BT 
<ogra_> not swure the kernel has anything for the client side 
 * rtg -> lunch
 * apw wanders off for beer ...
<infinity> apw: emergency lowlatency is in proposed, so the new rebase can head to the PPA whenever you're appropriately drunk.
 * rtg -> EOW
<patr|ck> is there a newer kernel package for testing a graphics driver issue, than the one that ships with Ubuntu 12.10?
<infinity> patr|ck: There's the one in 13.04, of course.
<patr|ck> infinity, can that package be installed on 12.10 or would that require other packages to be updated, too?
<infinity> patr|ck: Should install fine on 12.10, I don't think any deps got bumped.
<patr|ck> nice, thank you
#ubuntu-kernel 2012-11-17
<jefferai> Hello there...I'm seeing a regression in kernel 3.6.3 (I'm not sure when it begins), as built by the Ceph guys, in bridging
<jefferai> some packets are being dropped on the floor going through a bridge to a VM
<jefferai> doesn't happen on the stock Precise kernel
<jefferai> if anyone can help me figure out how to debug this, I'd appreciate it
<jefferai> the later kernel is relatively important for using the Ceph RBD in-kernel driver
<apw> jefferai, does it fail on hte 3.6.3 mainline kernel, that would tell you if it is 3.6.3 or something the ceph guys did
<jefferai> apw: yeah, fails on mainline, and fails in 3.5 and 3.4 but not in 3.3. Currently on my 15th or so build of the vanilla kernel tree -- doing a git bisect to find out what's going on
<jefferai> apw: found it -- bisected to an exact changeset, a change in the ixgbe driver
#ubuntu-kernel 2012-11-18
<tomatopotato> hi setting noapic in grub does not allow the suspend mode to work properly, the psu fan is still turning and it seem like the computer does not shut down, but when i push the button and turn of the computer and turn it on again, it resumes, is there any reason why it is like that? do i need to use a different option? because without noapic, i get a kernel panic error 
<tomatopotato> here is my lspci http://pastebin.com/Cw9GCPY3 im running xubuntu 12.10
<tomatopotato> i dont know what else logs you would need
<fairuz_> Anyone know the Ubuntu for Android by Canonical? They said both can be running concurrently and using the same kernel. How did they do it? Ubuntu chrooted in Android? or something else...
#ubuntu-kernel 2013-11-11
<apw> moin
<ppisati> :(
<ppisati> the dnsmasq instance in my router, this morning stopped working
<ppisati> for some still unknown reason
<ppisati> maybe it's on strike...
<apw> ppisati, i had total admin interface "what interface" behaviour from mine over night
<apw> ppisati, it got a poke in the eye this morning for its trouble
<ogra_> geez, you are so mean to your machines 
<ppisati> apw: well, in my case it was my cock up
<ppisati> apw: i modified the config file but forgot to reload
<ppisati> apw: so when i restarted it for the first time it sucked in the modification
<ppisati> apw: and that screwed it up
<ppisati> :P
<apw> hehe ... oops
<ppisati> apw: btw, do you have a script/way/$something to detect that there is a new kernel available for a specific release?
<ppisati> apw: i would like something that i can use in a script
<smb> ppisati, beside of dist-upgrade on the system I assume. :-P
<ppisati> smb: yeah
<ppisati> smb: i'm running precise on this board, but i can shave a *LOT* of stuff from the config
<ppisati> smb: so i would like some sort of tool that detects that a new kernel is available, git fetch it, applies my config diff and kicks a build
<smb> ppisati, I guess you could either directly check the latest commit of a master branch in git or rmadison output
<apw> ppisati, recipe build in a PPA ?
<ppisati> apw: yeah
<ppisati> smb: rmadison? uhm
<apw> rmadison -a source linux
<smb> Though I think the mainline builds mostly would do what you need
<smb> ppisati, or the line from apw, probably excluding the proposed lines
<apw> rmadison -a source linux | grep precise-updates | awk '{print $3}'
<infinity> -s precise-updates... Querying all dists and grepping is abusive to the remote end. :P
<infinity> (Plus, 'rmadison -s precise-updates -a source linux' should generally return much more quickly)
<apw> heh, indeed, i guess i should read the manual page more often
<ppisati> nice, that's what i was looking for
<smb> infinity, True. It became a bit better after moving lots of other things from that machine
<infinity> smb: Other way around, rmadison itself moved to snakefruit with the other archive stuff.
<infinity> (But yes, splitting lillypilly's load almost exactly in half was a pleasant side-effect of us moving off)
<smb> infinity, Ah... ok, something moved and I did not care for the details except that it stopped taking ages
<infinity> smb: All of ~ubuntu-archive moved.  Anything you see at people.c.c/~ubuntu-archive is actually a transparent proxy to our new machine.
<infinity> And that includes rmadison, but that was just a nice side-effect of the deal.  The real motivation was to get permission-sensitive stuff like proposed-migration off a massively shared machine.
<smb> Quite sensible. And at least it felt like some of that got more or more complicated because the responsiveness of lillipilly really went down a lot at some point
<infinity> Yeah, lillypilly wasn't in a happy place.
<infinity> I used to spend a lot of time running around neutering ~desktop and ~kernel processes on lillypilly so the archive scripts wouldn't be starved for I/O and cycles.
<infinity> Now I don't care, and you guys can battle it out. :P
<infinity> (But it seems much better in general with archive off there anyway)
<smb> Heh, yeah I guess shanky is running from there, too
<infinity> Is it?  I thought shankbot ran from one of bjf's home machines.
<smb> Hm, maybe I am wrong
<infinity> I actually kinda hope it does, since it has his LP creds.
<infinity> Which really shouldn't be sitting on a shared account on lillypilly. :P
<smb> But kinda would add a lot to the "bus problem" if it does...
<infinity> It probably *should* be run with a role account from a tightly-controlled kernel team machine somewhere.
<infinity> Or something cloudy.
<apw> infinity, yep, we even have a role account, the problem is getting that account the creds it needed, like nominate rights
<infinity> Actually, a role account would reduce the scariness a lot, since it wouldn't need to have much in the way of permissions.
<infinity> Where as bjf's account is actually a bit scary to share.
<smb> Yeah, that would be best... hm... not sure I would trust cloudy stuff with that
<infinity> apw: I can give it series nomination privs.
<apw> infinity, but we do have one, and it should be sorted out
<infinity> smb: When I say "cloudy", I mean "prodstack", which should be quite trustable.
<apw> we have the kernel robot or something which was intended for that
<infinity> apw: Point me at said robot, and I'll give it the same nomination privs I gave bjf.
<smb> infinity, ok less cloudy in the whereabouts
<apw> infinity, whne i can remember its name :)
<infinity> apw: ~kernel-ppa perhaps, or something else?
<infinity> Probably a bad choice, if that's what you were planning on anyway.
<infinity> A "Kernel Team Bug Robot" that *only* has permissions to mangle bugs would be ideal for privsep.
 * smb thought that was one older approach and as scary in getting shared
<smb> (the kernel-ppa one)
<apw> infinity, something else ubuntu-kernel-bot i am pretty sure
<smb> infinity, Something named like that would also have the advantage of stopping people to reason with the robot in bug reports
<apw> i should check that belongs to us still
<infinity> ubuntu.kernel.bot@gmail.com ...
<infinity> The email address doesn't inspire confidence. :P
<infinity> But then again, the archive robot isn't any better.
<apw> infinity, heheh that i believe we own, it was one of those things you cannot have two accounts with the same addy, so you have to make a new address, then add the mailing list as a second one, and make it a preferred one
<apw> infinity, but before you give it any privs let me find the password and confirm
<infinity> apw: I hope by "mailing list" you mean "private alias expansion" or something.
<infinity> apw: Cause having an LP account with a public mailing list as the owner is obviously very bad. :)
<apw> infinity, heh who knows any more, ... but i think the one we made was kernel-janitor ... confirming now
<apw> well i would be if compiz handn't just crashed when it opened the dash, something i didn't want it to do i would add
<apw> 200% cpu it is managing to use, ARRRG
<infinity> https://launchpad.net/~kernel-janitor is  linux.kernel.janitor@gmail.com 
<infinity> So, looks like you have two bots.  Maybe cause someone forgot and made a second. :P
 * infinity breaks down and orders a Nexus 5.
<apw> heh yeah likely so ... that is leann's way but i have the password for the second according to my records, and if i could run firefox i could confirm
<apw> infinity, a 5?  for what
<infinity> apw: To replace my ancient phone.
<infinity> I played with my friend's 5 last night and it's... Really nice.
<apw> oh dear .... trusty X sucks ass
<apw> i have nice shiney display corruption
<davmor2> apw: I don't believe you, it can't be a shiny display if it's corrupted it can only be a broken display :P
<apw> davmor2, heh ... it is a good job i only speak in sarcasm
<davmor2> apw: damn did I forget the sarcasm tabs again "My bag"
<ogra_> use your babelfish ;)
<apw> bablefish don't speak sarcasm either :)
<davmor2> apw: you must still be using bablefish 1.0 (US version)  You need to update to bablefish 2.0 (UK version) It assumes sarcasm at all times and is terribly shocked when there is none
 * ppisati -> out for lunch
<apw> davmor2, heh point indeed
<apw> RAOF, yo, who do i whine at if on saucy i am getting character corruptions
<apw> RAOF, on intel kit
<infinity> apw: I'd try mlankhorst or tjaalton.
<infinity> The former never idles in this channel, which is irritating.
<tjaalton> apw: there are some bugs about it (still), like lp#1222871
<apw> bug #1222871
<ubot2> Launchpad bug 1222871 in xserver-xorg-video-intel (Ubuntu) "[gm45] Corrupted painting of window surfaces (L-shape tiling corruption?)" [Medium,New] https://launchpad.net/bugs/1222871
<apw> ubot2, can't you learn lp# format please
<ubot2> apw: I am only a bot, please don't think I'm intelligent :)
<apw> no s*it
<apw> tjaalton, that souds remarkably like mine
<tjaalton> you can also just open bug strings formatted like that on terminator ;)
<tjaalton> hmm I thought g-t supported those too, but no
<apw> i think its lp:1222871
<apw> they are all inconsistant for sure
<apw> tjaalton, is there an upstream bug on ths L thing, that should be linked to the lP bug ?
<tjaalton> apw: i'm not sure.. perhaps not but ickle is on lp
<apw> tjaalton, yeah i noticed that with supprise
<trevorj> Sorry, I don't mean to spam across multiple channels, I just realised #ubuntu-kernel existed.
<trevorj> Hi guys, I compile a custom flavor of the Ubuntu kernel for our boxen here based on Ubuntu's kernel git. I've been trying to figure out the proper way to create a source package that I can upload to an apt repo. Anyone have any experience with this?
<melodie> hello
<melodie> I would like to know wether the 3.8.x-generic series for Precise have PAE enabled or not enabled. Does someone know about that?
<melodie> I have seen the 3.11 does, and the 3.2.x don't. But the latest 3.2.0-55 and -56 don't support zram-config (bug #1246664)
<ubot2> Launchpad bug 1246664 in linux (Ubuntu Precise) ""Buffer I/O error on device zram0, logical block 515067"" [Medium,Fix committed] https://launchpad.net/bugs/1246664
<melodie> Will the kernel series 3.2.0-x for Precise always be PAE free until 2017?
<melodie> I got the answer
<melodie> which is "yes, that is the idea"
<melodie> does someone know when the fix done by henrix as per #1246664 will be integrated in the kernel? 
<melodie> hi again
<melodie> is there someone here who is in charge of the kernel 3.2.0-x for Precise, and who could say when the patch for zram will be integrated?
<melodie> #1246664
<melodie> bug #1246664
<ubot2> Launchpad bug 1246664 in linux (Ubuntu Precise) ""Buffer I/O error on device zram0, logical block 515067"" [Medium,Fix committed] https://launchpad.net/bugs/1246664
#ubuntu-kernel 2013-11-12
<Psil0Cybin> hey guys i have a few questions about how kernels work, I upgraded my Ubuntu system and the new kernel is causing a blackscreen where no parameters fix the issue
<Psil0Cybin> how can i go about creating a proper report so i can help people working on the new kernels to look at my issue
<Psil0Cybin> do you think it is fine to use an outdated kernel? would new kernels have a potential of fixing my issue and i should sit this kernel update that is causing the problems out?
<Psil0Cybin> hey guys i have a few questions about how kernels work, I upgraded my Ubuntu system and the new kernel is causing a blackscreen where no parameters fix the issue
<Psil0Cybin> do you think it is fine to use an outdated kernel? would new kernels have a potential of fixing my issue and i should sit this kernel update that is causing the problems out?
<Psil0Cybin> hey guys i have a few questions about how kernels work, I upgraded my Ubuntu system and the new kernel is causing a blackscreen where no parameters fix the issue
<Psil0Cybin> woops wrong button sorry. 
<ppisati> robher: Rob, don't know if you saw my email, but we are still waiting your comments about the xgmac learning patch
<ppisati> robher: subject: "Re: [PATCH 4/5] UBUNTU: SAUCE: net: calxedaxgmac: add mac address learning"
<brendand> cking, is there an fwts test for backlight?
<cking> brendand, no
<brendand> cking, any reason?
<cking> no one never requested it (yet)
<brendand> cking, fair enough :)
<cking> brendand, you could file a bug and i'll chat to hwe to see what is doable 
<brendand> cking, i think there should be since the firmware interface seems to be the preferred method of updating the backlight by gsd
<brendand> cking, i can file a bug of course
<cking> brendand, more tests is always good ;-)
<brendand> cking, https://bugs.launchpad.net/bugs/1250429
<ubot2> Launchpad bug 1250429 in Firmware Test Suite "FWTS should have a test to check that ACPI backlight interface works correctly" [Undecided,New]
<brendand> cking, cheers
<cking> brendand, I'll get around to it in the next week or so
<rtg> ppisati, any feedback on the xmac MAC learning patch ?
<ppisati> rtg: nope, i pinged rob today, let's see if he answer
<rtg> ack
<rtg> apw, I'm gonna start an unstable branch in trusty so I can start going through all of the new config options in 3.13
<apw> rtg, makes a lot of sense to me, will help me with my endevours too
<ppisati> mumble failure
<rtg> ppisati, I'm rebasing against 3.13 merge window. WTF is ARM_ARCH_TIMER_EVTSTREAM ?
<ppisati> rtg: hold on
<rtg> even afterreading the help text I'm confused
<ppisati> rtg: i had the same reaction...
<ppisati> rtg: https://lkml.org/lkml/2013/9/18/125
<ppisati> rtg: looks like timeout support for wfe (enter/exit low-power standby) or evern programming error events
<rtg> ppisati, hmm, I wonder why its being built for x86'en. seems like some Kconfig patches are in order.
<ppisati> rtg: i doubt it attaches there, they probably let it build on x86 to extend toolchain exposure trying to catch as many bugs as possible
<cking> brendand, i've just responded to that brightness test fwts bug, can you follow it up?
<hallyn_> apw: stgraber: so there's a weird issue (https://github.com/lxc/lxc/issues/25) with avahi-daemon in a container.  it drops caps then clones.  Outside a container the clone works, but inside a container the clone only works if you hack it to not drop CAP_SYS_RESOURCE.
<hallyn_> (clone fails with -EAGAIN)
<hallyn_> running the container unconfined does not change things;  running outside a container in a hand-built cgroup does not change things;  so i'm having a hard time figuring out why there is anydifference in the privilege level
<hallyn_> ooooh, wiat
<apw> hallyn_, ... waiting
<hallyn_> the uid is in use on the host
<hallyn_> i bet using a unique uid will fix it
<hallyn_> not really a satisfactory fix, but it would at least explain it
 * apw hmms isn't that meant to be fixed by uid spaces
<brendand> cking - ok i did
<cking> ta
<hallyn_> apw: yeah, but those are not yet in use in most places
<brendand> cking, i think i probably shouldn't raise any more of these bugs before the years end, else i'll have to buy you a christmas present
<brendand> (at this stage i probably already should)
<cking> brendand, heh, it's no problem really
<hallyn_> apw: yeah so that fixes it.  sorry for the noise.  (not sure what to do about it, but it's not a kernel issue :)
<cking> brendand, i think I will call it "autobrightness" if that's OK
<brendand> cking, backlight?
<brendand> cking, your call
<ppisati> bug 1250495
<ubot2> Launchpad bug 1250495 in flash-kernel (Ubuntu) "armhf: highbank: relocate initrd to make room for a bigger kernel" [Undecided,New] https://launchpad.net/bugs/1250495
<ppisati> infinity: you might be interested in it ^
<apw> ppisati, approved noms
<rtg> apw, pushed unstable, starting build tests
<apw> rtg, ta
<robher> ppisati, infinity: we've adjusted the initrd and kernel addresses in the u-boot env to fix this issue. It should be part of 2.4.x firmware.
<infinity> ppisati: Erk.  Fun.  Can you remind me about it in a few days?  I'm about to run and catch a plane today and lose all context.
<infinity> robher: Adjusting it in firmware means we don't need to care about the boot.scr hack, or...?
 * apw wanders to another room
 * rtg -> lunch
<Psil0Cybin> hey guys i have a question about kernels i am so ocnfused maybe someone can shoot me in the right direction
<apw> Psil0Cybin, you will do well to actually ask that question
<apw> then we can work out who knows etc 
<Psil0Cybin> okay
<Psil0Cybin> i have kernel number 3.2.0-55-generic-pae
<Psil0Cybin> apw: my question is i used dist-upgrade got a new kernel, it caused a blackscreen i tried nomodeset
<Psil0Cybin> did not work i tried all other paremeters did not work
<Psil0Cybin> someone suggested to ry a mainline kernel
<Psil0Cybin> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-trusty/
<Psil0Cybin> is this the newest kernel for my build?
<rtg> Psil0Cybin, its the newest one you want to try. anything newer is getting pretty steamy.
<Psil0Cybin> okay perfect so im installing it
<Psil0Cybin> and im getting this
<Psil0Cybin> http://pastebin.com/nE5xGHee
<Psil0Cybin> is that normal or is it because i did not instead the headers yet?
<rtg> Psil0Cybin, its benign (unless you have an rtl device that requires this firmware)
<Psil0Cybin> okay thanks
<Psil0Cybin> jesus im new :P so im trying to learn ahah
<Psil0Cybin> you guys are so helpful i wish i could get everyone @ #ubuntu a giftbasket.
<rtg> then we'd all get fat :)
<Psil0Cybin> hahahahahha
<Psil0Cybin> okay so now im installing the headers
<Psil0Cybin> and im set to test :)
<Psil0Cybin> rtg: i installed the header and im getting this messages
<Psil0Cybin> http://pastebin.com/wDhkxQGF
<Psil0Cybin> Error! Bad return status for module build on kernel: 3.12.0-031200-generic (i686)
<Psil0Cybin> Consult /var/lib/dkms/cedarview-drm/20120717/build/make.log for more information.
<rtg> Psil0Cybin, I don't know what cedarview-drm is, but it clear;y doesn't like those kernel headers
<Psil0Cybin> cedarview is my graphic driver
<Psil0Cybin> which is why i am getting a blackscreen i assume
<rtg> likely
<Psil0Cybin> darn
<Psil0Cybin> so it looks like no kernel will work for me other then what i am using now
<Psil0Cybin> 3.2.0-55-generic-pae
<rtg> yeah, its unlikely kernels newer then 3.2 will work.
<Psil0Cybin> so what do i do..if i have an acer aspire one, d270-1628 i do not want new features
<Psil0Cybin> but i want to make sure i am always secure
<Psil0Cybin> when it comes to security issues.
<rtg> 3.2 is supported for 5 years from 12.04
<Psil0Cybin> oh eally for now?
<Psil0Cybin> so im fine for 5 years
<Psil0Cybin> just i should save up for better hardware?
<rtg> indeed
<Psil0Cybin> sigh
<Psil0Cybin> alright
<Psil0Cybin> so now next question if i go out and buy a laptop what laptop can i buy to insure that i get good quality support from ubuntu
<Psil0Cybin> when it comes to kernel and drivers.
<rtg> system76
<Psil0Cybin> system76?
<rtg> dell pre-installed
<Psil0Cybin> oh really dell?
<Psil0Cybin> is a good machine for ubuntu?
<rtg> only those that come pre-insatlled with ubuntu
<Psil0Cybin> okay but lets say i get a pre installed version does it come with the drivers on a usb or something incase i want to format later?
<Psil0Cybin> or just the hardware is really good one those when it comes to support
<Psil0Cybin> for the linux community.
<rtg> a little of both
<Psil0Cybin> alright sigh i wish i knew this before hand
<Psil0Cybin> i just got this laptop...and now i find out when it comes to linux its garbage because intel is shittay
<Psil0Cybin> its small netbook i wanted to run xubuntu on forever :)
<rtg> well, whats wrong with the bits that came on it ? you're good until 17.04
<rtg> anyway, I'm EOD
 * rtg -> EOD
#ubuntu-kernel 2013-11-13
<apw> moin
<smb> mornings
<cking> morning
<smb> (kernel devs crawling out from under their rocks)
<cking> copious amounts of strong coffee required today
<apw> are you dissing my rock?
<apw> cking, and some _heat_ it is cold
<apw> there is ice on my grass
<cking> 'tis cold ere too
 * cking has a audio issues today, I was faffing around with a new MIDI USB dongle and managed to kill audio
<smb> sound waves are frozen?
<smb> apw, No we all love our rocks
<tseliot> I have a stupid question: if the driver fails to bind, it is the driver's fault, right? (linux 3.8) It's unlikely that there's a bug in the local_pci_probe() call, right?
<apw> tseliot, it sounds unlikely for sure, drivers like to fail to bind, it is their modus operandi, as they are commonly offered everything
<tseliot> apw: right, and we're talking about the broadcom driver here...
<apw> oh man, man o man
<apw> that thing exhibits a manevolance i have only seen else in (sci-fi) extra-terestrials
<tseliot> :D
 * smb also wonders what exactly fails to bind means (where, what call, return code?)
<tseliot> smb: https://launchpadlibrarian.net/155781369/for-comment-21-lp-bug-1247712.log
 * smb was hoping for some higher level describtion that apport vommit... *sigh*
<tseliot> and the bug report https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1247712
<ubot2> Launchpad bug 1247712 in linux-lts-raring (Ubuntu Precise) "Unable to install Broadcom STA wireless dirver on 3.8.0-33 / 3.8.0-29 kernel via jockey-gtk" [Undecided,New]
<tseliot> smb: basically jockey writes to the sysfs tree to unbind and then rebind the driver after the driver installation
<smb> tseliot, Supposedly that is "simpler" than unloading the other broadcom modules after blacklisting them? 
<tseliot> smb: I'm not sure, as I didn't design that part of Jockey
<smb> So it could be that its a problem with the other driver and unbinding. But who knows. (and not sure I want to).
<tseliot> hehe
<smb> Feels like the only two relevant error messages are 
<apw> tseliot, which driver does it try and unbind when brcmwl is loaded
<smb> [  526.263040] ERROR @wl_dev_intvar_get : error (-1)
<smb>  [  526.263045] ERROR @wl_cfg80211_get_tx_power : error (-1)
<tseliot> apw: I'm not sure as I have no device with that driver here but the log reports "[last unloaded: bcma]"
<smb> Yeah, the lspci also shows those two as possible alternatives (wl and bcma)
<apw> ok so there isn't a third or anything, the world of brcm is complicated these days
<tseliot> smb: right, and that (wl_dev_intvar_get, etc.) should be caused by "wl" (I assume)
<smb> apw, Yeah, I don't know like that other thing you get with b43
<smb> ... ssb I think
<tseliot> I should probably upload a new broadcom driver and see what happens
<tseliot> after all, we have a stable release now
<apw> tseliot, ok the EIP is 'somewhere else' not in a bit we have symbols for, so it is most likely we moved on from pci_probe_local
<apw> smb, does one of you or me have a 4313, i know i have a 4312 somewhere, was it you who had the 13 /
<apw> ?
<smb> apw, If I could remember...
<apw> perhaps in your previous travel lappy ?
<smb> It certainly had to use wl but...
<smb> Ok, it says 4312, too
<tseliot> I'm still looking for a device for local testing
<tseliot> I wish it were easier to find one
<brendand> cking, just a quick question - if updating /sys/class/backlight/acpi_video0/brightness doesn't do anything, does that sound like busted firmware, or could it be a kernel bug too?
<cking> brendand, it's hard to tell w/o more info really
<brendand> cking, that's all i've got right now
<cking> brendand, i guess the best bet is file a bug and it can be investigated
<cking> but I guess it's more likely a firmware bug than anything
<mjg59> brendand: Kernel bug
<mjg59> brendand: Especially if it's Intel graphics
<mjg59> The ACPI video interface shouldn't be used on Windows 8 systems
<brendand> mjg59, but the kernel docs say that the firmware interface should be used when available?
<brendand> mjg59, which happens to be acpi_video0
<mjg59> brendand: Yes. The kernel shouldn't be exposing that interface on Windows 8 systems. But there are bugs in the i915 backlight driver and Intel haven't fixed them.
<brendand> mjg59, most interesting
<brendand> mjg59, so it's still correct to use the interface where it exists
<brendand> mjg59, and the bug is that it does?
<zyga> mjg59: hi
<zyga> mjg59: is there anything that should be added to the kernel documentation on backlight to make this issue cleaer?
<mjg59> brendand: Correct
<mjg59> zyga: No, the bug should just be fixed
<mjg59> But that needs someone to actually commit to fixing the i915 backlight code
<zyga> mjg59: is there a bug on that open anywhere that you know of?
<mjg59> Unsure off hand
<mjg59> It was discussed on LKML
<cking> that narrows it down, some discussion on LKML
<cking> https://lkml.org/lkml/2013/6/9/161 perchance?
<mjg59> Yeah, followed by the complaints that saw it reverted
<cking> ok, I see intel needs to play catchup on this, sigh
<brendand> mjg59, what range of hardware does this affect? haswell only?
<mjg59> brendand: And some Ivy Bridge
<mjg59> There's certainly an argument that it's a firmware bug, in that the firmware's exposing an interface that doesn't work
<mjg59> But if Windows doesn't use a firmware interface then it's not going to be tested
<mjg59> And there's no reasonable expectation that it'll work
<mjg59> So the kernel really shouldn't attempt to use it
<apw> amen to that
<cking> so much borkage
<apw> bios is junk, shocker
<brendand> this is the bug we raised btw: https://launchpad.net/bugs/1250401
<ubot2> Launchpad bug 1250401 in linux-lts-raring (Ubuntu) "[Dell Inspiron 5737] brightness could not be controlled by the indicator applet "System settings -> Brightness and Lock"" but sysfs works" [Undecided,New]
<cking> apw, we need a way to test for that for sure
<apw> good old dell firmware
 * rtg -> lunch
<cwillu_borken> Is there a debug package for the mainline repo kernels available anywhere?
<cwillu_borken> the btrfs folks want me to run a systemtap script to troubleshoot an issue I'm having, but it complains about missing DWARF information
<apw> cwillu_borken, nope we don't make those, though the source can be reconstruced and you could make them
<cwillu_borken> that's too bad
 * cwillu_borken starts compiling a kernel
<apw> they are half a gig per build, they are just tooo big to have large numbers thereof
 * cwillu_borken buys apw a 2tb drive to hold them, because that's obviously all that's needed to keep them around right? ;p
<rtg> apw, I'm rebasing again after the vfs and net merge. I dropped all aufs patches because of the extensive vfs changes 
<apw> rtg, thanks for the warnig
<rtg> apw, build testing, then I'll push 
<rtg> apw, looks like overlayfs is gonna have issues as well
<apw> rtg, no supprises, something for me for the mornign
<rtg> apw, yep
<manjo> is there a kernel release milestones wiki for trusty?
<bjf> manjo, was there one for saucy?
<manjo> bjf, no I think the last one was raring 
<bjf> manjo, you mean a release schedule?
<manjo> right release schedule 
<Sarvatt> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
<bjf> manjo, what Sarvatt said
<manjo> cool thanks 
<manjo> looks like the kernel wiki stop updating those links since raring :) 
<bjf> manjo, there used to be an interlock schedule with had the sru cadence schedule on it
<manjo> bjf, so drop dead date for patches would be March 27th ? 
<manjo> ie sometime before final beta freeze
<bjf> manjo, yes i think so
<manjo> cool thanks 
<xnox> bjf: the interlock schedule was mostly out of date, most of the time. As it was updated by hand, and was out-of-sync with every authoritative sources of information.
<xnox>  https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule <- is the only authoratative for Trusty release. Same naming pattern goes for all other releases.
#ubuntu-kernel 2013-11-14
<bjf> xnox, yup, well aware of the issues with the interlock schedule
<diwic> Hi, I'm trying to decipher the workflow schedule...but not sure what everything means, so I'm just asking instead:
<diwic> If I'm making a patch that I want to go into linux-lts-raring, when is my next deadline?
<apw> diwic, i believe this was prep-week, so the next prep week is in two weeks time, but i am not authorative 
<apw> diwic, that seems to jell with most of the kernels being in prepare or copy to proposed right now
<apw> diwic, make sense?
<diwic> apw, ok, thanks, so two weeks then...that should definitely be doable to get the hda backport in until then, I think
<apw> diwic, there is always another cycle after as well
<diwic> apw, right, but I understand this is urgent enough to warrant backporting, otherwise we could just wait for 12.04.4 instead
<apw> diwic, if this is a big scarey patch set, you want it out for review sooner rather than later, so we have time to digest it
<diwic> apw, fair enough, plan is to do it early next week
<rtg> apw, did you see bug #1251035 ?
<ubot2> Launchpad bug 1251035 in linux (Ubuntu) "kernel stack trace when running openvswitch DEP-8 tests" [Undecided,Confirmed] https://launchpad.net/bugs/1251035
<apw> rtg, will have a look, thanks
<rtg> apw, I already bugged james on #ubuntu-server
<apw> rtg, i have just pushed an update to unstable to reenable overlayfs
<rtg> apw, good thing you let me know. was just rebasing against the latest merge
<rtg> apw, hmm, not seeing it.
<apw> rtg, try that
<apw> rtg, it should be rebaseable
<rtg> apw, better.
<ppisati> back in 20
<rtg> apw, pushed unstable, now build testing
<bjf> ppisati, R U back ?
<ppisati> bjf: yep
<bjf> ppisati, bug 1248504 has a patch. is it waiting on anything to be submitted?
<ubot2> Launchpad bug 1248504 in linux (Ubuntu Saucy) "[saucy] [armhf] [calxeda] add mac address learning capabilities" [Medium,Confirmed] https://launchpad.net/bugs/1248504
<bjf> ppisati, same for bug 1248492
<ubot2> Launchpad bug 1248492 in linux (Ubuntu Saucy) "[saucy] [armhf] use pstore to save console log messages" [Medium,Confirmed] https://launchpad.net/bugs/1248492
<hallyn_> apw: hey, i think commit e51db73532955dc5eaba4235e62b74b460709d5b in trusty kernel is causing me grief.  (haven't tested a revert of it yet, but it seems the likely culprit)  Do you know where that one came into the tree?  (It's not in Linus' tree)
<hallyn_> oh, or is it.  frown.
<hallyn_> nm, i'm misplacing my blame.  i'll find the real culprit
 * rtg -> EOD
<apw> hallyn_, let me know what you find, indeed
<hallyn_> apw: yeah, waiting for a tes kernenl to build.  at this point i have no idea why, just know i can't mount proc in a child userns
<hallyn_> guess i should be bulding on tangerine.  inside kvm is just silly
#ubuntu-kernel 2013-11-15
<apw> hallyn_, heh you should indeed
<alex116> hi, I'm trying to read i2c data and from userspace the example code uses ioctl
<alex116> I want to read i2c data from a kernel module and would like to figure out how to read from the device
<alex116> can I just use the normal open read write close functions?
<cking> alex116, how about https://www.kernel.org/doc/Documentation/i2c/dev-interface
<cking> maybe https://www.kernel.org/doc/Documentation/i2c/writing-clients
<alex116> I was hoping I could just use the loaded driver's functions because thats all ioctl does
<igalic> Can I somehow make it impossible (or near impossible) for apt to even consider removing linux-image-server, linux-server, linux-headers-server, etc..?
<infinity> zequence: It's SRU time again, if you missed out on the new bugs.
<infinity> igalic: There's no reason it would remove them unless you ask it to remove something they depend on.
<infinity> igalic: As a general rule, people are expected to read apt's output when it tells them what it intends to do.
<apw> infinity, arn't they even manually installed top levels so it should be hard to force them off
<apw> igalic, how did you get into a sitruation where it wanted to, what did you ask for
<apw> that it though could only be solved by so removing it
<infinity> apw: They're manually installed, yeah.  Not that autoremove would ever pull them anyway, since they're never installed as deps.
<infinity> apw: So, people removing them are doing it intentionally (ie: by removing the kernel they depend on)
<apw> i can only assume you asked it to remove the latest kernel ?
<igalic> We're trying to remove automatically installed kernels. We don't quite trust autoremove, since it tends to uninstall things that are "running". This "recipie" http://dpaste.com/1464493/  (from https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels ) however will remove /other/ stuff that we'd rather kept.
<igalic> (I like how the automatic section is actually empty)
<igalic> oh.. that's the latest kernel. That's why it's removing it.
<igalic> so that "documentation" is lying.
<diwic> ogasawara, I understand you will discuss this next week, but do you today have a feeling for whether you'll end up with 3.13 or 3.14 for the LTS?
<ogasawara> diwic: most likely 3.13
<diwic> ogasawara, thanks, that was my guess too
<rtg> apw, dropped 'UBUNTU: SAUCE: (no-up) drm -- stop early access to drm devices' during the rebase. Do you think we still need it ?
<infinity> igalic: "apt-get autoremove" will not remove the running kernel.  Random other weird snippets on wikis are generally suspect.
<igalic> infinity: apt-get autoremove will not remove the running kernel, but it will remove the running kernel's utils, tools and headers.
<infinity> igalic: Not anymore.
<apw> rtg, i think i am supprised to still find it applied, i thought that that was fixed another way in upstream now
<rtg> apw, well, I've been faithfully forward porting it for several releases
<infinity> igalic: That was fixed in saucy.  In precise, it'll yank tools probably, yeah.  Maybe also headers.
<apw> rtg, hehe ... oh well ... 
<apw> infinity, didn't we fix those deps back in the end?  i thought we did
<rtg> apw, guess we'll find out. I haven't even boot tested this pile yet
<igalic> infinity: that's badd, because we're running LTS
<infinity> apw: I may have made the header fix in precise.  Can't fix the tools issue without backporting the rename/reorg.
<igalic> infinity: can you link me to the bug?
<apw> infinity, point, that we have done for the lts-backport kernels, saucy onwards but .. yes not before that
<infinity> igalic: Okay, just verified, precise won't autoremove headers, but it will autoremove tools.
<infinity> igalic: And the tools problem is hard to solve without us reorganizing the precise kernel packages.
<infinity> (Which is probably not worth doing with another LTS around the corner, IMO)
<infinity> Given that the number of people who need tools installed is tiny.
<igalic> perf top is invaluable.
<infinity> For normal users?
<igalic> >_o
<infinity> You and I may define normal differently. :P
<igalic> Define normal users.
<infinity> s/normal/average/
<infinity> Statistically, very few people use perf.
<igalic> I'm a Unix Admin. I don't know what you mean.
<infinity> And the people who do use it probably intersects well with people who can read the output of "apt-get autoremove" and say "no" when it's not what they want.
<igalic> Yes, except we have everything puppetized on hundreds of machines.
<infinity> Anyhow, we *could* backport the whole tool renaming madness to precise, I'm just not sure it's worth the pain.
<igalic> infinity: if I run the cool new kernels on LTS, will that still be an issue?
<infinity> apw: Is the tool renaming magic represented in linux-lts-saucy?
<igalic> i.e.: linux-image-generic-lts-saucy 
 * infinity looks.
<igalic> (or any other)
<apw> infinity, yes
<infinity> Yeah, looks like that works.
<apw> infinity, oh well ... perhaps the answer is "in the new one"
<infinity> igalic: Only lts-saucy, not the earlier ones.
<infinity> But, I'd need to backport the matching apt fix for that.
<apw> it may not have hit updates yet, or is about to now or something
<igalic> infinity: apw: can you link me to the issues describing this?
<infinity> linux-tools-3.11.0-12-generic linux-tools-3.11.0-13-generic linux-tools-3.11.0-14-generic are all what I'd expect in precise.
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1205284
<ubot2> Launchpad bug 1205284 in linux (Ubuntu Precise) "linux-tools naming is not scalable to multiple source packages" [Medium,Fix committed]
<apw> infinity, the bits for master might not be in yet, and there is a common tools package fix pending on the lts-saucy branch
<apw> infinity, yeah the wrapper fixes are pending for the next sru round for master
<infinity> apw: s/next/current/, or in another month?
<apw> as in only on master-next right now
<infinity> Bummer.  Well, I'll backport the apt fix, since that's trivial.
<apw> ie the /usr/bin/perf won't recognise the new perf binaries till that fgoes out
<apw> yeah, it got missed in testing
<apw> its not like you cannot find them manually so not world ending, they are there installed
<infinity> apw: Alright, apt backport uploaded.
<igalic> wowzers!
<infinity> apw: If someone wants to mangle all the tools crap in 3.2, that might make somoene happy, but I personally think it's likely not worth the effort.
<igalic> infinity: do you have a bug for that also I can track?
<infinity> igalic: Same bug I pasted above.
<igalic> so, once this gets promoted (demoted?) to precise, if we have linux-image-generic-lts-saucy installed, and the system's apt-to-date, we can simply have Unattended-Upgrade::Remove-Unused-Dependencies "true"; and everything will be perfectly fine.
<ppisati> bjf: i'm preparing the P/omap4 kernel
<bjf> ppisati, ack
 * ppisati disappears for a bit
<infinity> igalic: If you want headers too, that would be linux-generic-lts-saucy
<infinity> igalic: And linux-tools-generic-lts-saucy for tools.
<igalic> infinity: linux-generic-lts-saucy installs headers also?
<infinity> igalic: "linux-generic" depends on "linux-image-generic" and "linux-headers-generic" (trade "generic" for flavour du jour, like generic-lts-saucy)
<igalic> infinity: I think I've asked this question a couple of times, but, what's the difference between -generic, -server, -chewgum, -etc ?
<infinity> igalic: These days, generic is the only flavour, though there's a fake not-quite-flavour called virtual, which is actually just generic without most of the modules.
<infinity> igalic: But, on LTSes, you'll have different generic options for the HWE backport kernels (like lts-raring, lts-saucy, etc).
<infinity> Oh, I guess it's not fair to say "generic" is the only one, as there's also lowlatency.
<infinity> But it's the only one built from the master sources. :P
<igalic> What's that mean?
<infinity> There's a "linux" source package, maintained by the Canonical kernel team, and it only produces the generic (and virtual) flavour.
<apw> (and notionally the server flavour)
<infinity> lowlatency is a rebased fork maintained by the Ubuntustudio team, which has a few different twiddles.  Not particularly ideal for servers, so probably of little intrerest to you.
<infinity> apw: There is no server flavour.
<infinity> (Not anymore)
<apw> there is a linux-server and linux-{image,headers}-server though
<apw> which are used in server images, which is why it is notional
<infinity> apw: Sure, but it just installs generic. ;)
<apw> right, just .. dunoo ... being a pedant
<infinity> I suppose it keeps the option open if we feel the need to fork configs again some day.
<infinity> But with scheduler improvements and the like, forked configs are less interesting over time.
<igalic> It would be nice to install -server and have sysctl settings actually worthy of a server.
<apw> igalic, that would be possible, as it has its own meta package
<apw> igalic, if there was a definative set which made sense
<igalic> apw: disabling the oom killer for instance ;)
<apw> igalic, i don't think disabling that is going to solve any issues, yo should never ben runnig a server to the point it would need to
<infinity> Disabling the OOM killer doesn't magically prevent you from running out of RAM.
<infinity> It does, on the other hand, assume that the first few processes started are the only ones allowed to have memory leaks, which might be a desired behaviour for some.
<igalic> No, it doesn't but it magically prevents the kernel from not killing processes even though I'm NOT out of RAM.
<infinity> igalic: When you're out of RAM, all your processes are out of RAM.  Until a sufficiently large one crashes.  *shrug*
<infinity> The OOM killer attempts to make intelligent decisions based on usage patterns.  It's not necessarily any dumber than the non-oom-kill algorithm of "let stuff crash when it tries to malloc()".
<infinity> igalic: Without the OOM killer, you could leak with some Java servlet, but the malloc() that hits the brick wall could be init.  Instant kernel panic, game over.
<infinity> igalic: You can't control WHICH process hits the last available page and dies.
<igalic> please read http://www.twistedmatrix.com/users/glyph/rant/softethics.html
<apw> your point with that ?
<apw> or is that a total no-sequiter
<infinity> apw: It's unethical to prevent init(8) from dying, if that's what it chose to do.
<infinity> apw: How dare we stand in the way of its suicide attempt via malloc().
<apw> igalic, anyhow if you can change it via sysclt, one can do that, so ...
<igalic> apw: read the bit about car manufacturers.
<igalic> (I think a good resource is also http://www.loper-os.org/?p=284 )
<infinity> igalic: It's a poor analogy, in reference to the above discussion.  If your car runs out of gas, do you think it would be appropriate for it to jam a piston through the hood and send a tire flying off the side of the road?
<infinity> igalic: Sure, if you had just kept the tank topped up, you'd be a responsible driver, and you'd still have an engine.  On the other hand, lolwut?
<igalic> I think a better "fuel" analogy is this one https://lwn.net/Articles/104179/ ;)
<apw> so all one needs to do is swtich to full commit mode for allocation and ensure you have enough swap
<igalic> And suddenly you have a predictable VM. YAY. It's almost like I'm using a Unix.
<apw> yeha right, like they wern't the same
<ppisati> rtg: i'm building a test kernel
<rtg> ppisati, ack, I'm about to email a comment to robher about the mac learning patch
<TooLmaN> Hi guys.  I'm back to working on embedded projects and I'm rusty on kernel building.  What is a good resource for building a kernel from source on Ubuntu/Mint?  The Wiki appears to be a bit dated.  Thanks
<ppisati> [flag@luxor ubuntu-saucy]$ git fetch origin
<ppisati> [flag@luxor ubuntu-saucy]$ git rhard origin/master-next
<ppisati> HEAD is now at a223125 UBUNTU: SAUCE: (no-up) apparmor: Fix tasks not subject to, reloaded policy
<ppisati> [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f0915781bd5edf78b1154e61efe962dc15872d09
<ppisati> [master-next 15fa8df] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon <will.deacon@arm.com> 3 files changed, 123 insertions(+), 30 deletions(-)
<ppisati> rtg: ^
<ppisati> rhard is an alias for 'reset --hard'
<rtg> ppisati, huh, well maybe I fat fingered something.
<ppisati> rtg: actually that hash comes from rmk's git tree
<rtg> ppisati, well, try the same patch from Linus' tree
<ppisati> rtg: but if you don't have that remote, it would probably say 'unknown hash or something'
<ppisati> rtg: let's see
<TooLmaN> disregard.  I had to add the source repos.  
<ppisati> rtg: even linus version apply ok
<ppisati> [flag@luxor ubuntu-saucy]$ git cherry-pick -sx f091578
<ppisati> [master-next acaa3ca] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Author: Will Deacon <will.deacon@arm.com> 3 files changed, 123 insertions(+), 30 deletions(-)
<rtg> ppisati, ok, works for me then
<ppisati> anyhow
<ppisati> let's wait until it builds
<rtg> ppisati, isn't that the same SHA1 as rmk tree ? f091578 and f0915781bd5edf78b1154e61efe962dc15872d09
<ppisati> same sha
<rtg> ppisati, ok, I see what I did. I got the wrong patch, e.g., 'ARM: tlb: don't perform inner-shareable invalidation for local BP'
<ppisati> rtg: yeah, slightly different subj
<ppisati> rtg: local BP vs local TLB
<rtg> ppisati, too damn close...
<ppisati> rtg: sent
<rtg> ppisati, ack
<slangasek> apw: hey, can you sanity check me... does fsync() have any meaning on ptys?
<apw> slangasek, i cannot think what it would mean on a pty
<slangasek> hmm
<apw> the data is either in the hole or it is not
<slangasek> so I'm asking because of https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-upstart/14/ARCH=amd64,label=adt/ - an upstart test that's failed intermittently, because a log file that's supposed to be created didn't get created
<slangasek> and I'm trying to figure out why; my current guess is in-kernel buffering
<slangasek> but that's a SWAG
<slangasek> the other possibility is the kernel is doing everything right, and upstart is just failing to create the logfile with the data it's meant to be reading from the pty ;)
<apw> slangasek, if you can point me at the source for the test, i'll have a think about it and figure out if fsync means anything
<slangasek> apw: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/tests/test_state.c#L2115 vs. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/view/head:/init/tests/test_state.c#L2143
<slangasek> anyway, fsync() returns non-zero, so in practice that's the wrong interface anyway ;)
 * rtg -> EOW
#ubuntu-kernel 2013-11-16
<BenC> slangasek: in saucy, linux-libc-dev:i386 and linux-libc-dev:powerpc cannot be installed at the same time :/
<slangasek> hmm, really?  they're at the same version
<slangasek> so they ought to be
<slangasek> BenC: pastebin me some apt output?
<BenC> slangasek: http://paste.ubuntu.com/6423974/
<BenC> slangasek: so a version mismatch of 3.11.0-12.19(ppc) and 3.11.0.13.20(i386) will make it uninstallable?
<BenC> Seems so...I can install it now
<BenC> SRU mismatch
<BenC> slangasek: libc6-dev conflicts now (installing :powerpc removes :i386)
<BenC> slangasek: how I can get apt-get to show how it's depsolving this?
<BenC> It's the same version, too
<slangasek> apt-get -o Debug::pkgProblemResolver=yes  ?
<BenC> slangasek: And sorry, it's libc6-dev:amd64 it is conflicting with
<slangasek> still shouldn't conflict - but they do have to be at the same version
<BenC> They are the same version.
<slangasek> hmm
<slangasek> what does 'apt-get install libc6-dev:amd64 libc6-dev:powerpc' say?
<BenC> It appears part of the problem has to do with libc6-dev-powerpc-cross
<slangasek> ah, hmm
<BenC> http://paste.ubuntu.com/6424041/
<slangasek> ok, that's odd
<slangasek> and an 'apt-get -f install' doesn't fall over, or something?
<BenC> slangasek: tries to upgrade linux-libc-dev:amd64, but that's all
<slangasek> ah, so you probably need that upgrade to happen first
<slangasek> and then the rest of the conflicts should just go away
<BenC> If I upgrade that, it removes linux-libc-dev:powerpc
<BenC> Because then it doesn't match versions
<slangasek> hum
<slangasek> well, you need them to be matched
<BenC> linux-libc-dev:(amd64|powerpc) are matched on the system right now
<BenC> And everything is satisfied
<slangasek> but 'apt-get -f install' wants to upgrade it?
<slangasek> that's strange
<BenC> You're right, that is strange, but it gave me no problems on downgrade
<slangasek> this is amd64?
<slangasek> (the main architecture)
<BenC> $ dpkg --print-architecture 
<BenC> amd64
<slangasek> why can you not upgrade both :amd64 and :powerpc?
<BenC> Oh, wait!
<BenC> Maybe I should add powerpc updates and security :/
<slangasek> aha
<slangasek> yes :)
<BenC> Damnit...that fixes the linux-libc-dev problem, but still won't let me install libc6-dev:powerpc
<BenC> slangasek: apt-get -f install
<BenC> Now shows nothing
<BenC> No upgrades available
<BenC> slangasek: I've purged all the powerpc packages...starting from scratch...what's the main package to install to get this rolling?
<BenC> slangasek: So the main thing is I can install a cross build environment without problems, base build...but to install libncurses5-dev:powerpc requires linux-libc-dev:powerpc (as opposed to linux-libc-dev-cross-powerpc)
<BenC> There is no complimentary libncurses5-dev-cross-powerpc :/
<BenC> slangasek: so "apt-get install libc6-dev:powerpc" wanted to remove gcc, but "apt-get install libc6-dev:powerpc gcc" allowed it to install without issue
<BenC> slangasek: Sounds like a problem in apt-get's dep solver relating to Multi-Arch
<linuxtech> I have an old laptop that I upgraded to saucy and it will only boot the earlier 3.8 kernel.  The 3.11, including the proposed, hangs on "Platform eisa.0: Probing EISA bus 0"  I also tried the 3.12.0-999 kernel at http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2013-11-07-saucy/ Any suggestions?
<apw> linuxtech, you should file a bug with 'ubuntu-bug linux' and let us know the number, note in the description that the version you are reporting on works, and which versios you have tried which do not.  we can then suggest some versions to try to identify where the issue was introduced
<jovando> hello everybody, i need help for my other pc, because i cant boot anymore after kernel-test-phase
<jovando> this is the mail after i have reported to launchpad: http://paste.ubuntu.com/6376813/
<jovando> please help!!
<jovando> The main problem is because of the fail load of fallback graphics devices
<jovando> any idea?
<melodie> what is your gpu?
<JanC> jovando: selecting another kernel in the boot menu doesn't work?
<jovando> yes it doesn+
<jovando> t
<JanC> wait, you're using Netrunner, not Ubuntu?
<jovando> before testing a new kernel (according to kernel team or launchpad) the last kernel i could use was the kernel "Netrunner, with Linux 3.2.0-52-generic-pae"
<jovando> after installing the test kernel i was able to boot one time to KDE but after a recommended restart -> no kernel work any more because of the fallback graphic devices *fail*
<JanC> "VGA compatible controller [0300]: NVIDIA Corporation G96M [GeForce 9600M GT] [10de:0649] (rev a1) (prog-if 00 [VGA controller])"
<jovando> yes and they forwarded me to ubuntu-kernel forum, because this is a kernel-issue
<jovando> yes this is my graphic card
<jovando> does anyone have any idea to prevent the fail of fallback graphic devices?
<JanC> jovando: I'm not sure if Netrunner has different kernels from Ubuntu's?
<melodie> JanC do you have the non free driver for nvidia installed?
<melodie> and I am assuming nouveau would be installed in your system
<jovando> i am also not very good at linux issues, because i use linux since 2 years (just for information)
<melodie> I started in 2005
<jovando> i dont know if there are different kernels - the next is that i use a pae kernel version
<melodie> and I am not yet good at all issues although I used several families of distributions over time
<jovando> at "additional drivers" i have installed the recommended driver
<jovando> i think version 347
<JanC> jovando: one problem is that you seem to use Netrunner, not Ubuntu, and this is a channel for Ubuntu; maybe there is a channel for Netrunner somewhere?
<melodie> jovando do you have nvidia non free blob or not? If you do, you could start a live, chroot and remove the nvidia (apt-get autoremove --purge -y nvidia)
<jovando> i dont know if this was a non-free driver....
<melodie> jovando what does the error in /var/log/Xorg.0.log say?
<JanC> if Netrunner is enough like Ubuntu, that might work...
<jovando> what is nouveau?
<melodie> jovando try this command:
<melodie> nouveau is the free driver
<melodie> and it works (now)
<melodie> so your system might meet with a conflict between drivers, so for the testing purposes at least you should remove nvidia driver
<melodie> if you have it installed
<jovando> netrunner is very similar a kubuntu version
<melodie> you should look from within a live cd or live usb if you find the error messages related to "Driver" in /var/log/Xorg.0.log 
<melodie> jovando just do that, boot to live and have a look, then if you have nvidia installed, just remove it
<melodie> you know how to chroot probably?
<jovando> ok, the problem is i cant boot - how can i look and report the "Driver" in /var/log/Xorg.0.log ?
<melodie> and mount and or bind /dev to dev/ and such?
<melodie> jovando with a LIVE CD
<melodie> I just told you
<jovando> sry, what does chroot means?
<jovando> jep, sry one moment i will try
<melodie> https://help.ubuntu.com/community/LiveCdRecovery
<melodie> chroot means you change the root
<melodie> when the partition / is mounted, to /media for example
<melodie> then you cd to /media
<jovando> ok, cd boot now ...
<melodie> then the command "sudo chroot ." will get the / of the distro which is in the hdd at the level of the / of the live
<melodie> from within the console of course
<melodie> you have to mount a few more things first so that what you will do in the chroot is well registered in the system 
<melodie> I think this is appropriate:
<melodie> mount none -t proc /proc
<melodie> mount none -t sysfs /sys
<melodie> mount none -t devpts /dev/pts
<jovando> ok, it needs a little bit time - still booting
<melodie> once the / of the hdd mounted to /media of course
<melodie> jovando take note
<jovando> thanks in advance for advise
<melodie> of the two following links:
<melodie> https://help.ubuntu.com/community/LiveCdRecovery
<melodie> I don't know the mount and bind relevant commands by heart so I go to that page to find them again when in need:
<melodie> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<melodie> if you meet with error messages about other directories not mounted when you will be in the chroot just leave the chroot by typing "exit" in the console, and add the missing mount point, then again chroot
<melodie> just pay attention : /dev is not the same thing as dev/ : according to where in the system you are located from within the console
<melodie> once chrooted, you can seek for nvidia in the chrooted system, ie with a command such as "dpkg -S nvidia"
<melodie> if you see a long list then it means it is installed
<jovando> ok, i try the point: Update Failure
<melodie> if you just type "apt-get autoremove --purge -y nvidia" and it does remove nvidia and packages it is as good
<melodie> I am hurrying because it's almost time for dinner her
<melodie> here
<melodie> I don't know what is "Update Failure" ?
<jovando> under you first link: https://help.ubuntu.com/community/LiveCdRecovery
<melodie> jovando this first link is just to tell you how to use a live cd, all the rest may not refer to your present case
<melodie> while I'm here I have a general question, does someone know how long the SRU process can be before a patch committed by someone hits the newer kernel coming in the repos?
<melodie> I have a concern about the 3.2.0 serie for Precise because I can't use zram-config with it
<jovando> what does SRU process mean?
<melodie> https://wiki.ubuntu.com/StableReleaseUpdates
<melodie> thanks google "SRU Ubuntu" ;-)
<jovando> i can just say that approx. every 2 weeks i have to update my kernel over the repos, but you mean something different, don't you?
<jovando> ok, i have studied the links
<jovando> now you recommend to purge via: apt-get autoremove --purge -y nvidia?
<jovando> have a good snack first, melodie :-)
<jovando> ok, so first i have to change root before i can purge?
<jovando> can anyone give me advise what to do next?
<jovando> or can somebody give me advise to chroot?
<jovando> Do i need the packages "Casper" and "debootstrap"?
<jovando> i found another way to purge, but the console says: E: Unable to locate package nvidia
<jovando> what can i use instead of: apt-get autoremove --purge -y nvidia?
<melodie> jovando reread what I told you:
<melodie> mount the system partition, do the necessary bindings, then chroot to be *inside* the system
<melodie> then type your remove command line
<jovando> i try but i am also not so good in english
<melodie> jovando if you don't talk English of French I can't help more :)
<melodie> being good in English will come with practice, don't worry about that
<jovando> i try my best
<jovando> ok, i am booting now the live cd again
<jovando> so i am at gui of live cd
<jovando> the link says i need casper for chroot,,? it's a little bit difficult for me to know what i need to solve the problem
<jovando> ok, now i have also internet on live cd
<jovando> i think i have mounted the hard-disks now
<jovando> i think i have chroot with sudo, the only problem is that the nvidia package is unable to locate
<jovando> do you know what to do in this case?
<linuxtech> apw: bug https://bugs.launchpad.net/bugs/1251816  Boot failure with saucy kernel 3.11 probing eisa
<ubot2> Launchpad bug 1251816 in linux (Ubuntu) "Boot failure with saucy kernel 3.11 probing eisa" [Undecided,Confirmed]
<melodie> jovando you don't need casper to chroot /o\
<melodie> jovando if you chrooted then do this command now:
<melodie> grep Driver /var/log/Xorg.0.log and paste the result to http://pastebin.com
<melodie> then bring back the url
<melodie> grep will filter and seek the word Driver in the Xorg.0.log file which is under /var/log and we will see what it says
<melodie> or you could as well copy the whole file Xorg.0.log to pastebin and I will look 
<jovando> ok, om
<melodie> jovando ping me once done, I'll be talking on other chans too
<jovando> http://paste.ubuntu.com/6428411
<melodie> ok
<melodie> jovando from lines 14 to 26 it shows you have the nouveau driver in action. so do just the reverse that I told you: install the non free driver nvidia and remove nouveau driver and nouveau firmware
<melodie> then reboot once or twice 
<melodie> the package name you will find with "dpkg -S nouveau"
<melodie> package names*
<melodie> install nvidia first
<melodie> I think the nvidia current version should do, perhaps checking this detail at geforce website would help ensure it is correct
<jovando> this is the hole file of Xorg.0.log: http://paste.ubuntu.com/6428428
<melodie> jovando ok so don't do what I just said
<melodie> look at lines 107 to 110
<melodie> and then I'll explain what I think
<k1l_> make sure you got the kernel headers
<jovando> ok, so the module does not exist
<melodie> no no
<melodie> not just that
<jovando> ok, just one information in advance: i am still in live boot - is this ok?
<melodie> the last file is not complete
<melodie> you might want to install pastebinit and do "pastebinit /var/log/Xorg.0.log"
<melodie> yes, you need to be in the live boot in chroot in a console to be inside the system which is on the hard drive
<melodie> in the chroot type "apt-get install pastebinit
<melodie> "
<melodie> without the quotes of course
<melodie> tell me if you can install it?
<jovando> ok, so i already used chroot and i wasnt aware of that?
<melodie> aware of what?
<jovando> that i chroot
<jovando> i didnt installed anything of that what was in your link - i just used sudo
<melodie> well when you are in a swimming pool under the water with a diving equipment you are aware where you are, right?
<melodie> when you are in a chroot you are root
<melodie> so you don't need sudo
<melodie> when you are in a chrooted system in a console you have the # at the end of the prompt
<melodie> and when you type "ls" you see all the directories which are inside / in your hard drive. Is that ok ?
<melodie> in the normal live system when you open a console you are in /home/ubuntu : is that ok so far?
<jovando> the # isnt here, but i can see all in the system with ls - this is how i reported the xorg.0.log file
<melodie> the # must be there
<melodie> if you report the wrong file system it is meaningless
<melodie> http://paste.ubuntu.com/6428428/
<melodie> your prompt does not show
<melodie> I'll chroot one of my own systems and paste the result to show you
<jovando> at this here: http://paste.ubuntu.com/6428411/
<melodie> I will chroot this one:
<melodie> /dev/sdb3: LABEL="MiniBuntu" UUID="2faa1046-6563-4f33-b82c-ce316f35664a" TYPE="ext4" PTTYPE="dos" PARTUUID="000c3e38-03"
<melodie> there: is "netrunner@netrunner:~$"
<melodie> not good
<melodie> you are user in the live system
<jovando> what do you do to know so much about that?
<melodie> we need to be root inside the system
<jovando> ok, i hope it is not complicated to chroot
<melodie> I have been using and learning since 2004 without stopping one day, you don't want to know all about the file system and all tips and tricks just in two years, do you?
<jovando> how can i do that?
<melodie> it is not once you will have understood the principle, just look at the example I will provide now and you might get it instantly
<melodie> <melodie> I will chroot this one:
<melodie> <melodie> /dev/sdb3: LABEL="MiniBuntu" UUID="2faa1046-6563-4f33-b82c-ce316f35664a" TYPE="ext4" PTTYPE="dos" PARTUUID="000c3e38-03"
<melodie> [joyce@squirrel:~]$ sudo mount /dev/sdb3 /mnt
<jovando> i learnt much, but the terminal commands are not so easy for me...
<melodie> [joyce@squirrel:~]$ 
<melodie> just read please, for now and stay focused
<melodie> now my mini buntu is mounted to the /mnt directory
<melodie> $ cd /mnt
<melodie> $
<melodie> $ls
<melodie> bin   dev  home        lib         media  opt   root  sbin     srv  tmp  var
<melodie> boot  etc  initrd.img  lost+found  mnt    proc  run   selinux  sys  usr  vmlinuz
<melodie> let's say I have done the mount and bind necessary to have the /dev partition under /mnt populated
<melodie> or not: I will do the mount commands
<melodie> $ sudo mount -o bind  /dev dev/
<jovando> i can i find out which disk to mount?
<melodie> $
<melodie> with "sudo blkid" you will get information about all partitions available, be they mounted or not mounted
<melodie> $ sudo mount -o bind /sys/ sys/
<melodie> $
<melodie> $ sudo mount -o bind /dev/pts dev/pts/
<melodie> $
<melodie> next is just typing:
<melodie> $ sudo chroot .
<melodie> the . means "here"
<melodie> now my prompt is this : root@squirrel:/# 
<melodie> the # pwd command tells me where I am:
<melodie> root@squirrel:/# pwd
<melodie> root@squirrel:/#
<jovando> ok, but first i have to do the sudo mount -o bind ...
<jovando> ?
<melodie> I have "CHanged Root"
<melodie> chroot
<jovando> ok, so easy :-)
<jovando> i am root now
<jovando> with the #
<melodie> yes, because it will allow populating the /dev partition of your system in hdd and it will allow for some logs to be updated when you will install or uninstall some components
<melodie> jovando you see? A good example is better than a long explanation
<jovando> jep :-)
<melodie> check if you are having the network connection, do a ping to google.com for instance (in the chroot)
<jovando> http://paste.ubuntu.com/6428531
<melodie> I am not sure I provided all the mount commands necessary but if you see a message error later it will be easy to correct and add a missing mount (by exiting the chroot, adding the missing mount point and chrooting again)
<jovando> yes i have ping of approx. 200 
<melodie> something is wrong in your pastebin
<melodie> very wrong
<melodie> I will comment line by line
<melodie> netrunner@netrunner:/$ sudo mount /dev/sdb3 /mnt
<melodie> you have assumed that your /dev/sdb3 is the same as mine. Huge error, in your partition it is a Windows install or other Windows partition
<melodie> as says the sentence:
<melodie> "Mount is denied because the NTFS volume is already exclusively opened.
<melodie> The volume may be already mounted, or another software may use it which
<melodie> could be identified for example by the help of the 'fuser' command."
<melodie> (I should get paid for a full course)
<melodie> jovando you were already in the / of the live:
<melodie> netrunner@netrunner:/$ sudo blkid
<melodie> see ?
<melodie> netrunner@netrunner:/$
<jovando> yes you should get paid :-)
<melodie> and from there you have just chrooted !
<jovando> i can send you via ... anything
<melodie> you didn't even read the warning !
<melodie> here is not the good chan for a full course, come to #linuxvillage and I might point to a Free software actor where you can send a little donation if you are willing to
<k1l_> jovando: i dont think that this fits into the kernel channel. its very low level support asked from you: see this german ubuntu chroot howto http://wiki.ubuntuusers.de/chroot/Live-CD    
<jovando> i think i know what you mean
<k1l_> and again: no guarantee that this works with netrunner OS. i would suggest to talk to their support
<jovando> i should mount the right partition first - then i go in with chroot
<jovando> right?
<jovando> should we go an in the other channel now?
<melodie> k1l_ it's ok I take it from here with jovando on my chan dedicated to all topics 
#ubuntu-kernel 2013-11-17
<jovando> hallo erstmal, has anyone an idea what to do when i cant boot into the system? http://imagebin.org/277526
<jovando> sry, this is english channel: can somebody help me to boot with the kernel: 3.2.0-56-generic ? problem is that i stuck at the screen: http://imagebin.org/277526
<melodie> hi jovando here again?
<melodie> jovando you should either go to #ubuntu or come back at #linuxvillage now I have had some rest I can restart
<jovando> yes, i cant find the issue :-(
<jovando> or the cause
<melodie> here is the chan dedicated specifically to the people configuring and compiling the kernels for the Ubuntu distribution it's not meant for newcomers, newbies and end users
<melodie> I know the cause jovando I just could not get you to type the commands the right way
<netrunner_> melodie: hello, can you give me again the adress of your luxus server
<netrunner_> ?
<jovando> melodie: i will do a restart again
<jovando> hello, does anyone know the channel from "melody" ?? it is a france channel simmilar like: #luxus-...
#ubuntu-kernel 2014-11-10
<tseliot> apw: fglrx, nvidia, and bcmwl are all ready for linux 3.18 in vivid now. You might want to let rtg know (apparently I'm never online when he is)
<apw> tseliot, ack thanks, in theory the dkms matrix sort itself out and show that too
<apw> jibel, hey, the dkms testing, when a new dkms package is uploaded, how long after that will a new run for it trigger
<jibel> apw, same than the rest, we check once a day. I could schedule it more frequently if you need to.
<jibel> apw, for info I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766668 to add autopkgtest support to all dkms packages
<ubot5> Debian bug 766668 in autodep8 "Add support for dkms packages" [Normal,Open]
<jibel> apw, the patch is attached waiting for a review by the maintainer
<apw> jibel, nice on the debian stuff indeed
<jibel> apw, then dkms tests will run each time a dkms test of its deps are uploaded
<jibel> and block the migration if they fail
<apw> jibel, nice
<apw> jibel, ok so the fix for the dkms package in question was just 24m ago so thats not a supprise it has not appeared yet
<apw> jibel, is there a button an apw can click to jiggle that one into action, as daily is plenty fast enough on the normal run of things, but it would be nice to be able to jiggle things once in a while
<jibel> apw, you should be able to trigger tests manually from http://d-jenkins.ubuntu-ci:8080/view/DKMS/
<jibel> apw, if you are not allowed the CI team can give you the right privileges
<apw> so if i just wanted to run the bcmwl test, where is the button for that for you, i seem to remember having retry buttons so i suspect i have some priviledge at least
<apw> (then i can look see if it is there :))
<jibel> apw, for bcmwl + kernel team ppa: http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/V%20KT-PPA%20-generic/job/dkms-vivid-release_canonical_kernel_team_ppa-generic-bcmwl_kernel_source/
<jibel> apw, for bcmwl + kernel in proposed: http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/V%20-generic/job/dkms-vivid-release-generic-bcmwl_kernel_source/
<apw> jibel, and i'd expect like a "run me" button on there on that left menu ?
<jibel> apw, yes, there should be a "build" button on the left menu. Are you logged in?
<apw> ahh no i am not, and now i am i see a build
<apw> jibel, and that build says "make a new build for the latest kernel/package combo" i assume
<apw> jibel, and ... that worked, excellent
<apw> (the one you tickled for me)
<jibel> apw, it'll build with the most recent version of the packages in the archive + proposed + any ppa enabled.
<apw> that, is exactly what i need, thank you
<jibel> yw
<apw> tseliot, have all of the below gone in vivid?
<apw> fglrx REMOVED?
<apw> fglrx_updates REMOVED?
<apw> nvidia_173 REMOVED?
<apw> (the first two seem to now have _core versions)
<tseliot> apw: not really
<tseliot> apw: fglrx-core is just an addition to fglrx
<tseliot> fglrx-core is the one with the kernel code
<apw> fglrx MISSING
<apw> fglrx_updates MISSING
<apw> so those two not being tested, is wrong i assume
<tseliot> apw: right, fglrx-core and fglrx-updates-core are the dkms packages
<tseliot> nvidia-173 was indeed removed
<apw> tseliot, ok now i am confused has the fgrlx dkms packge name changed then ?
<tseliot> (I thought you were saying they had been removed from the archive)
<tseliot> apw: fglrx-core contains only the bare minimum (DKMS stuff, and non X specific libraries), whereas fglrx is specific to X
<apw> ie was the dkms bits in fglrx in U and in fglrx-core in V ?
<tseliot> both U and V have the fglrx and fglrx-core split
<apw> tseliot, ahh but did the split occur in the developement of U ?
<tseliot> put simply, we always need to test the -core package
<tseliot> yep
<apw> ok then _that_ makes my results make sense :)  thanks
<tseliot> :)
<apw> jibel, hey ... during U the fglrx "went away" and was replaced by fglrx-core as a dkms package, i note
<apw> jibel, that during that time the job names went wonky as well (3.16.0-24-generic /2:14.201-0ubuntu2) is that indicative that that result is not relevant perhaps ?
<apw> what does the name before the / there mean anyhow i guess
<apw> if that is the name of the dkms module we _find_ in the package then i guess it is indicative
<tseliot> apw: BTW, when is the lts-utopic backported stack due in 14.04?
<apw> tseliot, the kernel is already there i think
<apw>  linux-lts-utopic | 3.16.0-25.33~14.04.2 | trusty-proposed | source
<tseliot> apw: in -proposed or in -updates?
<apw> sitting in proposed at the moment it seems
<tseliot> oh, good
<tseliot> as that would break my packages
<tseliot> ok, maybe only bcmwl, IIRC
<jibel> apw, if the name changed in U then only results for fglrx-.*-core are relevant. Tests are added automatically but not removed.
<jibel> apw, the name before /<version> is PACKAGE_NAME found in dkms.conf of the module
<apw> jibel, ok so if that goes "" then it is very likely that that package can be ignored as a result ... purfect
<apw> jibel, this replication who owns fix that when the two do not match ?
<apw> jibel, do we run any of this tesitng for the lts-backport kernels ?
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues November 18th, 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.
<j4s0nmchr1st0s> What packages are needed to rebuild the kernel?
<apw> j4s0nmchr1st0s, the build dependancies on the kernel are the packages you need
<bjf> j4s0nmchr1st0s, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
#ubuntu-kernel 2014-11-11
<soren> Hi. I need a bit of help translating a kernel call trace entry to line of code in the source.
<apw> soren, got a reference to the trace ?
<soren> apw: Sorry, on a call now. Will get back to you in an hour and a half or so.
<soren> apw: http://imagebin.ca/v/1grE6VHtfuiG
<soren> apw: uname -a: Linux cp2-production 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
<soren> apw: ...which seems to be very unfortunate as that exact version doesn't seem to have a ddeb for amd64.
<infinity> soren: If only there were newer kernels you could be using. :)
<infinity> soren: By like 5 months...
<soren> infinity: Yeah :( Gah. Upgrading these things is a such a pain.
<infinity> Or 4.  Whatever.
<soren> apw: Without the ddeb, I'm out of luck, aren't I?
<apw> pretty much out of luck, you can prolly mostly build the ddeb again, and it will whine it is not the same, but if you make it from the tag, it ought to be right
<soren> apw: Yeah, that makes sense.
<apw> i don't believe we had a new compiler in T whch helps
<soren> apw: Ok, I have the vmlinux now. I can pinpoint the line of code where it break.. Going further up the stack, I hit a module (compiled with dkms). How can I resolve that to a line of code?
<apw> soren, hmm, no idea, never wanted to do that, good old dkms
<soren> apw: What if it were a "regular" module?
<soren> apw: The memory location is dynamic, so how would e.g. addr2line know what to do with it?
<apw> it is was regular you'd have the info in the ddeb you already have
<apw> hmm, that info ought to be int he kernel unless we have hidden it for security
<soren> apw: Oh, I actually didn't use the ddeb. I just grabbed the vmlinux and used addr2line. What should I have been doing?
<soren> It's been a while since I debugged kernel code like this :-/
<apw> soren, i don't think i tend to debug that way either, i'd be using objdump on the .ko and working it manually i suspect
<soren> apw: Fair enough. I'll keep digging. Thanks.
#ubuntu-kernel 2014-11-12
<j4s0nmchr1st0s> What packages are needed to rebuild the kernel?
<ogra_> the build dependencies of the kernel package indeed
<apw> 22:57:48*           bjf | j4s0nmchr1st0s, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> if those two arn't sufficient answer, you need to help us with a more comprehensive question
<j4s0nmchr1st0s> apw: fatal: remote error: access denied or repository not exported: /ubuntu/ubuntu-3.X.X-XX-generic.git
<apw> j4s0nmchr1st0s, <release> is the ubuntu release codename, trusty or whatever
<apw> j4s0nmchr1st0s, the example 2 lines below makes this clearer
<j4s0nmchr1st0s> apw: 2 lines below what
<jpds> j4s0nmchr1st0s: The git section you copied and pasted.
<j4s0nmchr1st0s> nope
<apw>     git clone git://kernel.ubuntu.com/ubuntu/ubuntu-<release>.git
<apw> For example to obtain the precise tree:
<apw>     git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<apw> i think you were using that from the wiki?  if not where did you get it from so i can delete it
<j4s0nmchr1st0s> apw: the link you posted
<j4s0nmchr1st0s> It says to use uname -r
<apw> apt-get source linux-image-$(uname -r)
<apw> that ?
<apw> j4s0nmchr1st0s, ^
<j4s0nmchr1st0s> yes
<apw> that is a completely different command getting the source from a different source, and using differnt versioning
<j4s0nmchr1st0s> quantal isnt on there
<infinity> quantal is EOL.
<apw> quantal is dead a buried
<infinity> And has been for a long time.
<apw> why on early would you want to build that
<infinity> https://lists.ubuntu.com/archives/ubuntu-announce/2014-May/000184.html
<j4s0nmchr1st0s> It is not legal to bury it.
<j4s0nmchr1st0s> You are in violation of the liscence.
<infinity> Uhm, no.
<ogra_> huh ?
<infinity> The sources are still available next to the binaries.
<j4s0nmchr1st0s> Where?
<infinity> http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux/
<apw> apt-get source linux-image-$(uname -r)       
<ogra_> but they likely have gaping security holes that will not be fixed 
<apw> and in fact regardless of the fact the source is in the archive (as infinity points out) the git repo is still available but in the ubuntu-archive directory
<infinity> ogra_: s/likely/do/
<ogra_> infinity, yeah, i didnt check, that made me careful ;) 
<j4s0nmchr1st0s> infinity: What is this link?
<apw> yeah no likely on that, it has vast caverous security issues which are definatly not fixed
<infinity> j4s0nmchr1st0s: That's a link to the pool where all your kernel binaries now live, as well as the source packages.
<ogra_> right
<apw> j4s0nmchr1st0s, that is a web url
<infinity> j4s0nmchr1st0s: quantal isn't on archive.ubuntu.com anymore, and hasn't been for a long while.
<j4s0nmchr1st0s> Is ogra_ infected?
<ogra_> ??
<ogra_> i think i'm rather healthy ... apart from slight overweight and a smokers cough
<apw> :)
 * ppisati still thinks we should have called P "pandemic platypus"
<apw> is pandemic an adjective?  though english is much abused these days
<infinity> ppisati: Pandemic doesn't exactly have that LTS ring to it.
<apw> "profligate platypus"
<ppisati> apw: isn't it? e.g. a pandemic disease
<ppisati> a pandemic ogra_
<ppisati> etcetc
<infinity> ppisati: No, a pandemic is a thing.
<ogra_> :)
<apw> you don't to pandemic, you have a pandemic 
<ppisati> ahhhhhhhh
<ppisati> ok
<ogra_> would pandemical work ? 
<ogra_> or pandemistic ? 
<ppisati> hold on
<ppisati> http://dictionary.cambridge.org/dictionary/british/pandemic
<ppisati> it's an adjective too
<infinity> No one trusts Cambridge.
<j4s0nmchr1st0s> The source isn't on here.
<j4s0nmchr1st0s> Only for a revision.
<j4s0nmchr1st0s> I want the sourcecode.
<ogra_> j4s0nmchr1st0s, well, then grab the source package from old-releases.ubuntu.com ... 
<apw> j4s0nmchr1st0s, if you mean the git repo we made the source packages from, those are still in ubuntu-archive/ rather than ubuntu/ in the git line
<apw> j4s0nmchr1st0s, though the source code for any released version is only definativly in the .dsc there
<j4s0nmchr1st0s> apw: Is that on github?
<apw> nope, take the original git url and s@ubuntu/@ubuntu-archive/@ on it
 * apw still doesn't get why you don't just upgrade, that has to be easier than making your own kernel for a dead release
<j4s0nmchr1st0s> Is that for all of the source or just the kernel apw ?
<apw> that is just for the kernel
<j4s0nmchr1st0s> Why are there so many objects?
<apw> becasue it contains the entire history of the linux kernle up to 3.5 and every single release of that kernel we did, which was a lot
<j4s0nmchr1st0s> Why does it contain the entire history?
<apw> because it is a git repo of the kernel, that is how they work
<apw> it is cirtainly not going to be smaller than the source pacakge for any specific kernel
<j4s0nmchr1st0s> So ubuntu archives the entire kernel history for each release?
<apw> the ubuntu kernel-team keeps the entire history of its kernels yes
<apw> as each kernel is derivative of the same on going linux (linus') history, they can share objects locally
<apw> and cirtainly that is what those of us who have 10 releases worth locally
<j4s0nmchr1st0s> That doesn't seem necessary why would the team clone the entire linux history for each release and archive it, unless it is being built from freshly compiled older linux platforms?
<apw> because that his how the git history is represented, as a history of the repo.  the archive repos also share objects
<apw> if you only want the current version that is in the source .dsc for the version
<apw> if you want the entire history of the version that is in the repo, and yes it is large
<j4s0nmchr1st0s> Was git even around when linux 1 was released?
<apw> no it was not, history starts at 2.6.12-rc2 iirc
<apw> older history is somewhere, not in the main repo
<apw> remember disk space is almost free in the GB range, and this is the logical and simplest form for it to take
<apw> if you share the objects with a linux-linus tree, then the overhead is near 0
<j4s0nmchr1st0s> What do you mean by 'free in the GB range'?
<apw> a GB of disks is of the order of $0.00 in real money
<j4s0nmchr1st0s> ?
<infinity> j4s0nmchr1st0s: Translation: "disk is cheap, who cares about big git repositories".
<apw> that, thanks
<infinity> j4s0nmchr1st0s: We don't ship the full history in the ubuntu archive, only a checkout of the tag being built, but for the kernel team's work, it's valid and useful to have complete history to search, revert, cherry-pick, etc.
<j4s0nmchr1st0s> It is bandwidth that is of concern. 
<infinity> j4s0nmchr1st0s: If bandwidth is really a concern, you don't want actually want a full git clone. :P
<infinity> So why are you doing one?
<j4s0nmchr1st0s> I need to connect to some high speed link to do this.
<apw> or do a shallow clone
<j4s0nmchr1st0s> If I see a fiber optic cable how can I splice it?
<infinity> A shovel.
<ogra_> an axe ... a very slim one ... 
<j4s0nmchr1st0s> I would have to know how they are transmitting over light.
<j4s0nmchr1st0s> Is the backbone using open source drivers?
<apw> unlikely they are using anything non-proprietary at this stage, the data and speeds of same they handle are astronomical
<j4s0nmchr1st0s> Interesting to think about.
<j4s0nmchr1st0s> That is where I am at.
<j4s0nmchr1st0s> apw: Is ubuntu-archive on github, search found nothing.
<apw> git://kernel.ubuntu.com/ubuntu-archive/ubuntu-quantal.git
<apw> or whatever the series is
<j4s0nmchr1st0s> apw: Can git://kernel.ubuntu.com/ubuntu-archive/ubuntu-quantal.git be bookmarked on github?
#ubuntu-kernel 2014-11-13
<apw> j4s0nmchr1st0s (N,BFTL), i don't think that makes any sense
<tjaalton> is it normal that booting to a new kernel renders a drive in a md array broken? the server had uptime of 197 days and after booting (trusty) to -39 caused issues
<smb> tjaalton, no
<tjaalton> I'll try an earlier one..
<tjaalton> it's a remote system so kinda awkward to test things
<smb> tjaalton, question is how broken, broken means
<tjaalton> smb: trying to access /dev/sda fails
<tjaalton> so no wonder it got dropped from the arrays
<tjaalton> it's a hp microserver that has worked ~4y without issues
<smb> tjaalton, ok. but also the chance of a change in the kernel only affecting one drive sounds slim. I would rather believe in cosmic rays
<smb> Some unfortunate coincidence with resetting the disk on reboot? 
<tjaalton> yeah could be
<smb> Sometimes weird shit happens. I had a SSD turning into a brick after resume... not any kind of pre-warning
<tjaalton> yeah one of mine broke while I was at the (last) uds
<bjf> zyga, trusty kernel and lts-hwe-trusty are being respun
#ubuntu-kernel 2014-11-14
<zyga> bjf: thanks for the heads up
<j4s0nmchr1st0s> apw will you assit in getting a high speed wire provisioned?
<apw> heh
<j4s0nmchr1st0s> I am surrounded by "intelligence" agents.
<j4s0nmchr1st0s> They keep siphoning my ip lines.
<j4s0nmchr1st0s> It is slowing down productivity.\
<j4s0nmchr1st0s> apw all you have to do is put in an order
<j4s0nmchr1st0s> pottery barn
<j4s0nmchr1st0s> apw: order a cable line
<j4s0nmchr1st0s> Have you ever felt like you were surrounded by chick tracts
<j4s0nmchr1st0s> digital ocean
<apw> i think you over estimate my influence, we're straying rather off topic 
<j4s0nmchr1st0s> apw: then play mindcraft with myself
<j4s0nmchr1st0s> shark tech is very dangerous
<j4s0nmchr1st0s> sharks are pure survival instinct
<j4s0nmchr1st0s> You are going to have to incept some fresh code apw
<j4s0nmchr1st0s> apw: I don't ask you to influence just carry out the plans
<j4s0nmchr1st0s> Influence already is.
<j4s0nmchr1st0s> There is some way to make sharks eat each other.
<apw> this really isn't the forum for this
<j4s0nmchr1st0s> It is the best forum I see out there already made.
<apw> no really, not
<j4s0nmchr1st0s> The only alternative that was recently made is github
<j4s0nmchr1st0s> How many years of martyr psychometrics did you hold out on?
<apw> this isn't ubuntu kernel related, and really not on topic for this channel, please find a more appropriate one
<infinity> apw: \o/
<smb> jibel, oh btw, did apw already talk to you about dkms testing for dahdi-dkms being futile as long as the host cannot connect to the internet?
<jibel> smb, not that I remember. We can probably use the proxy if it's a requirement
<smb> jibel, Yeah, the problem is that the dkms build tries to download stuff from somewhere.  so the test fails even if it would not fail otherwise
<jibel> smb, I understand, I'll setup a proxy to see if it helps.
<smb> jibel, Ok, great. Thanks
<apw> jibel, smb, thanks for looking into that ... and smb well remembered
<infinity> smb: The dkms build tries to download from the internet?  Eww.
<smb> infinity, it's all their fault :-P
<smb> infinity, maybe it is not done anymore with the more recent Debian versions which we probably should get in sync once the dust settles
<infinity> smb: Err, but what is it downloading?
<infinity> smb: This sounds like a massive bug to me.
<smb> infinity, could be some firmware things
<infinity> smb: Unless it's a non-free thing, then it shouldn't be in universe.
<smb> infinity, We can and probably should do a more insightful review. Right now I was just trying to get them actually compile
<smb> infinity, which was when I found that the last sync from Debian was done about 2012
<smb> There seem to be three related source packages all of which have different versions numbers for us while in Debian they seem to be in sync
<infinity> smb: That sounds rather unfortunate.
<smb> that would be the nicest way of putting it coming to my mind, yes
<caribou> arges: around ?
<arges> caribou: yes
<caribou> arges: howdy. Got a question regarding the makedumpfile fix that you submitted for ppc64el (the vmlinuX mod)
<caribou> arges: it has been tested correctly ?
<caribou> arges: I mean, I have no way to test it before uploading to Debian
<arges> caribou: yes, i verified on ppc64el hardware
<arges> caribou: i can assist with testing too if needed
<caribou> arges: ok, I'll trust you on this one
<caribou> arges: well, if you have a minute, I send a .deb your way to test it
<arges> caribou: yea i think that's the only delta left when I did the last deiban sync too
<arges> so that would be great if we got that in debian properly
<caribou> arges: working on it atm
<caribou> arges: you worked on the makedumpfile merge yet ?
<caribou> arges: for vivid I mean
 * arges looks
<caribou> 'cause I did too
<arges> caribou: hmm. i uploaded 1.5.7-1ubuntu1 i think
<caribou> arges: well, I'm about to upload 1.5.7-3 to debian .2 had a fix for ssh networked dump & .3 will be the ppc64el fix
<arges> caribou: yup. 
<caribou> arges: so hopefully both will be in sync
<caribou> & no delta
<arges> caribou: ok. is ther that fix for changing the runlevel
<arges> at which kdump runs:?
<caribou> arges: not yet
<arges> ok
<caribou> arges: but networked kernel crash dump is in there
<caribou> arges: I'm hoping to have runlevel S kernel dump in during this cycle
<caribou> arges: I now have a complete test program for testing makedumpfile (both local & remote)
<arges> cool : )
<caribou> arges: I need to investigate autopkgtest for this one
<caribou> arges: so do you have time to test the .deb before I upload it ?
<arges> caribou: i can make some time sure
<caribou> arges: ok, let me build it
<j4s0nmchr1st0s> apw why was 12.10 "killed"
<caribou> arges: which release you want it built on ?
<arges> caribou: umm, trusty would be fine
<caribou> arges: k
<ogra_> j4because its lifecycle has ended
<arges> caribou: can you send a ppc64el build? or give me sources and I'll build them
<caribou> arges: oh, right. Hold on, I'll put the source package up there
<caribou> arges: ok, source .gz & .dsc are up there
<arges> caribou: ok
<apw> henrix, ok that build seems to have made it to the builder at least (-ckt)
<henrix> apw: cool! so the builds work; hopefully the triagger will also work... :)
<apw> henrix, its only building, not seen it publish yet :)
 * apw goes run the triager ...
<alexbligh1> Any idea where I'd even *start* looking for bug where an 8 core machine running 3.8.0-32-generic #47~precise1-Ubuntu appears to be nearly entirely idle (CPU wise), kvm running mostly, load average > 250,000, "rcu_sched detected stalls on CPUs/tasks:" appears in logs, hung "shortly afterwards" (per customer). Whole system running from RAM I believe.
 * apw stuggles to remember what 3.8 was even
<infinity> alexbligh1: Well, the first step would be to run a supported kernel. ;)
<infinity> apw: saucy.
<apw> well that was my first guess :)  saucy, ouch
<alexbligh1> infinity, that's a Precise h/w enablement kernel. Yes I know it should be 3.8.0-44.66~precise1
<infinity> alexbligh1: No, it should be 3.13. :/
<apw> alexbligh1, yeah but those went off support some time ago
<henrix> infinity: actually, 3.8 was raring; saucy was 3.11
<infinity> https://lists.ubuntu.com/archives/ubuntu-announce/2014-July/000186.html
<infinity> henrix: Err, yes.  I can't alphabet.
<alexbligh1> infinity, hmmm - I thought those were still supported even though R (obviously) isn't. I'm obviously wrong. Well, we can fix that.
<infinity> henrix: I meant "the one after quantal", which is, apparently "S" in my mind today.
<henrix> heh
<apw> alexbligh1, but the rcu_sched reports imply someone got into the kernel and got stuck there, so it woudl be something likely running on proc all the time, you ought to be able to find that in like an sysrq whatsit
<apw> alexbligh1, but yeah when 3.13 came back to precise that signalled eol for the older releases, there is a nice piccy that ogasawara drew to help visualise this, somewhere in teh wiki
<infinity> Yeah, though rcu_sched stalls are ALWAYS kernel bugs.
<infinity> So an upgrade might just fix it.
<infinity> Often exacerbated by userspace, but always kernel bugs.
<infinity> alexbligh1: Any custom dkms drivers or anything, or just a stock kernel build?
<alexbligh1> infinity, apw no custom drivers, stock kernel build. The stacktrace we got from customer was: http://pastebin.com/edLwdQDp - I'm not seeing anything fantastically unexpected there.
<alexbligh1> infinity, I agree an update might fix it. I was hoping I might be able to say "we think this update will fix it because it fixes X".
<apw> alexbligh1, https://wiki.ubuntu.com/Kernel/Support has the nice piccy in case you need something to shove at them
<infinity> alexbligh1: Oh, with KVM in play, I'd give you good odds that an upgrade to linux-lts-trusty will fix it "Just cause".
<infinity> alexbligh1: KVM has improved in leaps and bounds in that timeframe.
<infinity> And Paul even fixed a few bugs in RCU. :P
<infinity> Though this doesn't look like an RCU bug.
<alexbligh1> infinity, yeah I think that's about the best I'm going to get :-)
<alexbligh1> thx
<apw> alexbligh1, that dump only shows 0 4 and 5, i wonder where the others are
<alexbligh1> apw, yeah I thought that too. I have an output from top showing them not doing much. Very strange.
<apw> either they cut the report short, or they didn't respond to the NMI which seems unlikley
<alexbligh1> apw, let me go ask support to find out whether the logs got chopped. If the processors literally froze, didn't respond to NMI etc., that would presumably explain the load average.
<apw> well the lack of RCU completing implies things are stuck and stuck things normally hold locks, which leads to eveyrthing else train-wrecking into those locks
<alexbligh1> apw, yep. thanks.
<arges> another approach (if you can easily reproduce) is to induce a crashdump on a softlockup and analyize it from there
<alexbligh1> arges, appears the customer can (whether he tries or not) reproduce one a day or so across a number of machines, so if an upgrade doesn't fix it I'll try that.
<arges> alexbligh1: fwiw, here's a write-up i did (since i was debugging a hang recently) http://dinosaursareforever.blogspot.com/2014/10/getting-kernel-crashdumps-for-hung.html if you don't already know how to set that up
<alexbligh1> what is the correct package to depend on to bring in the newest 3.13 on precise? http://packages.ubuntu.com/search?keywords=linux-lts-trusty&searchon=names&suite=precise&section=all is deeply unhelpful
<alexbligh1> arges, thanks
<infinity> alexbligh1: linux-lts-trusty for kernel+headers, or linux-image-lts-trusty for just kernel.
<infinity> alexbligh1: And linux-signed-lts-trusty if they're in a secure-boot environment.
<infinity> Err, I missed a "generic" in there.
<alexbligh1> infinity, ah, that was my mistake too :-)
<infinity> alexbligh1: linux-generic-lts-trusty for kernel+headers, linux-image-generic-lts-trusty for just kernel, linux-signed-generic-lts-trusty for SB.
<alexbligh1> infinity, yep, got it, just missing the 'generic'.
<alexbligh1> What's the hope of persuading someone to take the tiny patch in LP #1337262 to kmod for vivid?
<ubot5> Launchpad bug 1337262 in kmod (Ubuntu) "kmod should permit use of compressed modules" [Undecided,New] https://launchpad.net/bugs/1337262
<cmagina> is there a changelog diff between the trusty-proposed 40.68 and the 40.69 kernels. trying to find out what exactly the difference is
<arges> cmagina: there was a regression .69 is a fix for .68 with no changes to the ABI
<arges> this is essentially the change (minus changelog changes etc etc) : http://pastebin.ubuntu.com/9012495/
<cmagina> arges: ah, thanks for the info. 
#ubuntu-kernel 2014-11-16
<gyuukgku> How can I open the encrypted home directory to do backups before reinstalling?
<gyuukgku> usually there is a llarge encrypted file it all looks empty.
#ubuntu-kernel 2015-11-09
<jtaylor> hi, the lts-wily git is in a different location than the 3.x lts, will that stay like this?
<jtaylor> the btrfs read corruption fixes that went into 3.x recently don't seem to be in 4.2 but I also don't know where the review branch is :/
<apw> jtaylor, in a different place?  how so ?
<jtaylor> apw: there are only 3.19 branches at kernel.ubuntu.com
<jtaylor> while 4.2 seems to be on launchpad
<apw> jtaylor, could you give me the URLs you are referring to
<apw> jtaylor, as my ubuntu-trusty tree seems to have lts-backport-iwly in it
<jtaylor> apw: kernel.ubuntu.com/ubuntu/linux.git
<apw> jtaylor, that is just the stable trees, and 4.2 isn't under stable maintenance by us as yet i don't believe
<apw> jtaylor, so that would be in gregkh's trees and he produced only the quilt forms
<apw> jtaylor, but either way they don't represent the ubuntu kernel source
<jtaylor> apw: what is the right one then?
<jtaylor> I think I got that from the ubuntu docs
<jtaylor> but that might have been a long time ago
<apw> jtaylor, if you are looking for the source for linux-lts-wily in trusty that is on the lts-backport-wily branch in the ubuntu-trusty tree
<jtaylor> apw: thx, what is the relation of that tree to the stable tree? will patches from the stable go into the lts backports?
<jtaylor> seems lts-vivid is lagging ~3 month behind stable 3.19
<apw> jtaylor, generally the answer to that is yes, we follow and apply the vast majority of the stable updates to the trees
<apw> jtaylor, really?  vivid seems to have -ckt8 applied and -ckt9 is the latest
<apw> which would make it a couple of weeks behind, which with us being at the start of a 3 week cycle, would be unsupprising
<jtaylor> apw: I just looked at the btfs tree, last update there was in july
<jtaylor> there have been a bunch of important fixes in stable since then
<apw> jtaylor, do you have an example of a missing commit
<jtaylor> though maybe they only got merged in recently so its probably ok
<apw> jtaylor, if they are in -ctk9 then they will be in the next kernel upload
<jtaylor> apw: 3276852 e.g. is from aug, but thats probably the author date not when it actually went into stable
<jtaylor> so its probably fine
<jtaylor> now I know where to look so I'll be patient, thanks
<apw> jtaylor, right that appears in -ckt8, and vivid is -ckt7 in the last cycle, so we can expect that to be applied any day now for the next cycle
#ubuntu-kernel 2015-11-10
<samson-uo> Hello
<samson-uo> Someone mind pushing the latest set of tags to git?
<samson-uo> for the now-public CVE-2015-5307
<samson-uo> well, to their respective git repos anyway. Precise (3.2), Trusty (3.13), Vivid (3.19), and wily (4.2)
<henrix> samson-uo: sure, that will happen in the next couple of hours.
<henrix> and for anyone who cares: all git repositories should now be updated with that CVE fix
<rtg> cking, re: bug #1480349 - a new intel-microcode was synced to Xenial from Debian a few hours ago. intel-microcode | 3.20151106.1
<ubot5> bug 1480349 in intel-microcode (Ubuntu) "Intel Microcode Breaks frequency scaling in XeonÂ® E5-2687W v3 & E5-1650 v3" [High,In progress] https://launchpad.net/bugs/1480349
<cking> rtg, yep, i'll prod the users to test with the latest fixes, whatever they were, since intel does not like divulging the details
<rtg> indeed. lets hope isn't the disaster the last update was
<rtg> it isn't*
<cking> rtg, will this intel microcode be available for Wily, or is it just a Xenial sync?
<rtg> cking, just xenial for now. if it makes a positive difference, then we can pursue an SRU
<cking> rtg, considering I've not found any H/W (nor has Intel) that can reproduce this issue, it is a weird one
<rtg> cking, yeah, we might have to rely on the kindness (or frustration) of strangers :)
<cking> and considering it may be a microcode issue, it's not possible to reverse engineer it to fix it :-/
<mamarley> I am trying to recompile the kernel package for 4.2.0-18-generic on wily (so that I can apply a patch), but when I compile it (using "fakeroot debian/rules binary-generic"), I get the error "cc1: fatal error: /home/michael/Source/linux/linux-4.2.0/ubuntu/vbox/vboxguest/include/VBox/VBoxGuestMangling.h: No such file or directory".
<mamarley> I didn't get that error when I compiled 4.2.0-17-generic the same way.
<rtg> mamarley, try compiling from the git repository ?
<rtg> though it sounds like there could be an error in packaging.
<mamarley> rtg: This one? http://kernel.ubuntu.com/git/ubuntu/ubuntu-wily.git/
<rtg> mamarley, yup, then 'git reset --hard Ubuntu-4.2.0-18.22; fakeroot debian/rules clean binary-generic'
<mamarley> OK, thanks, I will try that.
<mamarley> rtg: That worked, thanks!
<samson-uo> henrix: I see them now, thanks!
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ ||  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: hi
<jsalisbury> cristian_c, sorry, I really havnen't had much time to dig into that bug recently.  I'll try to get to it soon.
<cristian_c> jsalisbury: if you don'tmhave time, I can talk with guys in #linux-wireless channel
<cristian_c> jsalisbury: could it be a good idea?
<jsalisbury> cristian_c, it wouldn't hurt.  It would be good to get some feedback from the upstream developers and see if they have any ideas
<cristian_c> jsalisbury: ok
<kdub> hey all, trying to compile the flo vivid kernel, but when trying to pack the zImage into the boot.img from phablet-dev-bootstrap, its complaining that the produced zImage is too big
<kdub> any ideas?
<rtg> kdub, turn off ext2/ext3 in favour of CONFIG_EXT4_USE_FOR_EXT23=y
<kdub> rtg, thanks, will give it a try
<rtg> kdub, have a look at the mako branch
<kdub> rtg, thanks for the tip, that seemed to get me over that hurdle
<rtg> kdub, no problem
#ubuntu-kernel 2015-11-12
<ricotz> henrix, hi :), are looking into backporting 4.2.0-19.23 as linux-lts-wily to trusty too?
<henrix> ricotz: yes, i'll probably be uploading it into the kernel team PPA today.  soon it will hit -proposed
<ricotz> henrix, great thanks
<caribou> apw: smb` cking: any reason why vt.handoff=7 would break my boot following upgrade to Xenial ?
<apw> caribou, you should have the same kernel as you had in wily, so no
<caribou> I have a fully encrypted HD and unless I remove it, I just get a blank screen & nothing else
<caribou> apw: I noticed a change in libplymouth
<apw> caribou, try hitting esc (or is it tab) twice to switch out of and into graphics mode again at the prompt
<caribou> I also loose my USB keyboard + external display
<caribou> apw: thanks, will try that
 * caribou biab
<apw> caribou, what did you upgrade from, as the kernel, grub2, and plymouth are at the same versions in wily as xenial
<caribou> apw: yes, I just noticed that
<caribou> apw: I upgraded from Wily
<caribou> apw: so hitting tab/esc brings me to the encryption password
<caribou> so I'm able to boot but w/o sound, external display & USB keyboard even if this one is seen by the kernel
<caribou> so I don't think it's a kernel issue
<apw> caribou, very odd behaviour though.  i am going to guess the tab thing is a race as much as anything, i have seen that before i think
<apw> caribou, but the  latter issues with sound etc is just plain strange
<caribou> apw: indeed, I'm looking at it atm
<caribou> apw: well, alsactl reports on soundcard found, so that takes care of it
<apw> "no" or "one"
<apw> ?
<caribou> apw: alsactl[808]: /usr/sbin/alsactl: load_state:1735: No soundcards found...
<caribou> apw: I also get systemd complains about apparmor
<apw> oh systemd, hmmm, cking didn't you have that barfing on you as well ?
<cking> apw, it SEGV'd on an arm64 debian unstable update for me
<apw> there is a new apparmour in xenail-proposed
<cking> rendered the machine unbootable
<cking> apw, I was not using apparmor 'cos I was using debian unstable ;-)
<apw> cking, if it was debian then its off the table 
<apw> ta
 * cking notes that since systemd is critical to a functioning system we should probably do static analysis and some kind of formal stress testing on it to see if we can shake out bugs
<diwic> caribou, could it be that the -extra kernel package is missing?
<diwic> caribou, that matches somewhat with your description of missing sound and USB
<caribou> diwic: I think you are onto something, yes it's not there
<caribou> err, NO it's not there
<caribou> diwic: apw: is it normal NO TO FIND a linux-image-extra for linux-image-4.2.0-18-generic
<caribou> let me reboot to .17 for which I have one
<apw> caribou, it is not normal no
<apw> have you lost your linux-generic or something ?
<caribou> apw: diwic: ok .17 works fine, I got everything back
<caribou> apw: let me recheck my archive, one second
<apw> caribou, so confirm you have linux-generic installed correctly
<apw> caribou, and also check that apt-get install -f doesn't say you are in the middle of an update
<caribou> apw: apt-get -f install is fine
<caribou> I disabled my squid-deb-proxy as well
<apw> and you have linux-generic installed, and you have no linux-image-extra-* ?
<caribou> yes
<apw> for that abi ?
<apw> that ... is impossible (in theory)
<caribou> apw: here is the result of apt-cache search linux-image : http://paste.ubuntu.com/13237767/
<caribou> apw: maybe a mirror issue, let me point directly to the main archive
<apw> caribou, before you do that
<apw> show linux-generic | egrep 'Version:|Depends:'
<apw> apt-cache show linux-image-generic | egrep 'Version:|Depends:'
<caribou> apw: http://paste.ubuntu.com/13237786/
<caribou> apw: even with the main archive, I don't see any linux-image-extra for .18
<apw> caribou, there is no -18 in xenial ... at alllll
<caribou> apw: ok, now I now what happened
<apw> this is a process fail, caused by the emergency cve release
<caribou> apw: I manually installed .18 just before the upgrade because it was complaining that it couldn't find it in the xenial archive
<caribou> apw: so I went back to wily & manually installed .18 (forgetting to install the -extra)
<apw> caribou, ok ... that then is all explained, and i am asking for that to be copied up, it should have been
<caribou> apw: then upgraded
<apw> yep, and now you are in a mess :)
<caribou> apw: well, no I still have .17 which has all the bits
<apw> hopefully we'll get that copied up into xenial today, it should have been
<caribou> apw: ok, so that's the source of the problem, good to know
<dannf> rtg: thanks for the pull! sorry for not mentioning the branch - i actually thought about it and decided to omit it, because start/end hashs would be unique (if my git foo is accurate)
<rtg> dannf, I think you have to know the branch in order to fetch the commit, but no matter. 
<dannf> rtg: cool - yeah, will go back to including the branch name. TA!
<apw> right, the sha1s are unique in space and time (in theory) but you need a handle which is exported, which is a tag or branch, you can't fetch arbitrary sha1s from a repo
 * dannf didn't know you could restrict fetching shas to a branch - seems like every fetch i do from a remote get all objects
<dannf> for some definition of all objects (not sure if objects from deleted branches are fetched)
<rtg> dannf, a fetch should only be fetching the objects on that branch that you don't already have
<rtg> if you fetch tags then you might be getting more then you need
<dannf> i don't  - just get fetch. for example, when i git fetch my wily remote, i get both wily/master and wily/master-next
<henrix> iirc, when you do 'git fetch' it will fetch all remote tracking branches (there's a git-config to set those i believe)
<henrix> e.g. remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
<apw> dannf, as henrix says a clean fetch is fetching "all branches" and any objects those reference you don't have
<apw> dannf, so to use your sha's i'd have to actually add your entire repo as a remote and fetch it, then find the shas that way, its more normal to offer me a real branch as then i can git fetch git://... yourbranch:dannf
<apw> ...
<dannf> apw: got it - makes sense
<kamal> rtg, so I find that I can get all of the linux/tools/* stuff to build in our chroots with just two more -dev packages:
<kamal> +ADDPKG="$ADDPKG libpopt-dev libreadline6-dev"
<kamal> I think we should just go ahead an add those to build-mkschroot
<kamal> also, build-mkschroot feels like it needs a good cleanup ... there are waaaay too many separate case $SUITE clauses, including at least one that I think is entirely pointless
<kamal> (a case that adds libssl-dev to some $SUITES -- but libssl-dev is already added to all suites)
<kamal> I'll submit those two patches ^^, but will hold off on doing any more cleanup, in case you like it the way it is
<rtg> kamal, I'm fine with that. it has accumulated a lot of cruft as we add special cases to it from release to release
#ubuntu-kernel 2015-11-13
<xnox> apw: is this a really bad ultrabook to choose? http://www.dell.com/uk/p/xps-15-9550-laptop/pd?oc=cnx5504&model_id=xps-15-9550-laptop it will only like ship in december/january
<xnox> and it's all the stuff that doesn't work yet: type-C, skylake, nvidia graphics, 4k display...
<apw> xnox, sounds ideal, buy two :/
<xnox> apw: well, it's better than my orange ideapad...
 * xnox bets regardless of choice of hardware I'll still be a laughing stock.
<apw> xnox, you have little to no luch in h/w :)
<xnox> =)
<xnox> apw: looked at thinkpad T, X, W series, they are either 2 generations old cpus - like haswell, or have little ram, or are 300-500 quid more expensive than dell. =(
<cking> the cool part about thinkpads is that one can download the hardware maintenance  manuals for free and one can strip the machine down and rebuild them easily. dells are a bit tricker to do that from my experience
<apw> xnox, t'is true, then again they are good
<xnox> cking: well. i think i've had enough tinkering with stuff. pieces of casing hit the fan of my old laptop and it smoked up at debconf in switzerland. I only upgraded ssd or some such there. And my last three phone repairs didn't go well: fixed screen, physical button stopped working, or fixed screen but broke the light sensor & power on-off button. even my desktop self assembled vibrates for no reason making noise.
<xnox> and dells are more soldered on, but lighter when compared with thinkpads.
<cking> xnox, yup, sometimes its just good to get a value priced machine and dump it after 3 years rather than continually nursing it along
<tseliot> apw: hey, I don't see the new kernel here: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa
<apw> tseliot, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable
<apw> tseliot, rtg has his own ranch now
<tseliot> apw: ok, good to know, thanks
<apw> tseliot, helps prevent ifddling in devel from messing up versioning in the main CKT PPA, which makes bjf's life a misery later
<tseliot> it makes sense
<apw> tseliot, we have made bjf have sad faces a couple of times in there recently, so he kicked us out :)
<tseliot> hehe
<manjo> bjf, have you guys settled on a kernel version for 16.04 ? 
<manjo> ogasawara, ^ ? 
<ogasawara> manjo: aiming for v4.4 
<manjo> ogasawara, any chance for pulling in stuff from 4.5? what would be the date by I need to tell you what patches from 4.5 we might need? 
<ogasawara> manjo: we can of course evaluate cherrypicking bits from 4.5 if needed.  As always, the earlier you get us that list, the better.
<ogasawara> manjo: Kernel Freeze is Apr 7, but I'd want somthing landed much much earlier than that.  I'd assume you'd know the list by the time the 4.5 merge window opens.  So I'd say that should be your target.
<infinity> manjo: Leann's above mention aside, given that 4.4 will be a Greg LTS, it wouldn't be a bad idea if you asked nicely for the 4.5 bits you need to land in 4.4 proper upstream, if they're suitable for stable@
<ogasawara> indeed
<manjo> got it ! 
<manjo> infinity, ogasawara thanks a ton for the info. I will make sure we have those patches cced to @stable.. and in case there are some lingering patches in 4.5+ I will ping you with cherrypick requests
<bjf> infinity: and the fact sabdafl told the world it would be 4.4
<infinity> Good old sabdafl.
#ubuntu-kernel 2015-11-14
<SamSpaces> Hi all, I've noticed a process called Rpigdnos. It returns after killing and deletion from /bin. Any ideas what that is?
<TJ-> SamSpaces: is this a publicly available system?
<TJ-> SamSpaces: check its parent process;  anaylse *all* running processes and exectuable paths; some other process may be restarting it as a randomly named process. The name doesn't match any file in the archives, so it is likely some form or malicious process, possibly part of a root-kit exploit
<SamSpaces> Thanks for the reply. It's a digitalocean server. I've rebooted with firewall now, checking if it's still there.
<SamSpaces> Hm, yes, still active
<SamSpaces> it takes up 100% cpu too
<SamSpaces> parent process is /sbin/init
<SamSpaces> Oh sorry, it's not a server, it's a droplet.
<SamSpaces> Ok, Rpigdnos is as malicious program probably, no references what so ever, so to anyone who wants the scoop, now is your chance :)
<TJ-> SamSpaces: found out anything more about it?
<SamSpaces> I've managed to clear my system of it. I created another older droplet, copied the /sbin/init to the infected droplet, removed the init file, deleted the program in /bin, overwrote /sbin/init with the clean version and rebooted.
<TJ-> SamSpaces: you should  investigate how it got itself installed and launched, that sounds like an init system compromise
<SamSpaces> I mess around a lot with crypto currency wallets. I know I shouldn't run them as root, so, that's a bit dumb, I know. But the culprit is most likely a crypto wallet.
<Guest58677>  wats +5519994589853 hacking
<JanC> seems like SamSpaces is not the only one: http://webcache.googleusercontent.com/search?q=cache:RqrdyvB6TTwJ:https://forums.aws.amazon.com/thread.jspa?threadID%3D219865
<JanC> and "Rpigdnos" might not be too random...
#ubuntu-kernel 2015-11-15
<slangasek> why does the ubuntu kernel's test suite install... exim?
<apw> slangasek, erm something must think it wants to send email ... where you seeing that, adt, somewhere else ?
<slangasek> apw: it's in the autopkgtest output; when the ubuntu-regression-test test runs, it goes about installing a bunch of packages one by one (nice that the output lists the commands it runs, btw!  Wish other things would do that...)
<apw> slangasek, yeah ... it is
<slangasek> apw: I looked through the code and it appears to call a sendmail api directly to talk to gmail
<apw> *blink*
<slangasek> no visible invocations of sendmail or exim in the tree
<apw> why on earth would it need to do that ... bjf ^
<slangasek> and exim is not the preferred mta :)
<slangasek> well I think it's sending mail to Brad
<apw> yeah, i'd say it is a hangover from the old trigger mechanisms, we moved to aqpm for most things so its likely redundant
<slangasek> ahhhh why is this machine firewalled off of ddebs.u.c!
<slangasek> apw: ok. fwiw I'm working on fixing the root cause of the actual kernel autopkgtest failures right now (util-linux stuck in xenial-proposed, and autopkgtest doing silly things with base packages)
<slangasek> ahhhh why is binutils failing to create dbgsyms packages!
<apw> slangasek, doing silly things?  most of the recent carnage was to do with the more selective package pinning changes ...
<slangasek> apw: the autopkgtest infrastructure does a dist-upgrade of the testbed before installing any per-package deps; then it sets the package pins; which means libuuid1 gets upgraded to xenial-proposed, then we drop a pin that says libuuid-dev can only come from xenial
<slangasek> according to infinity this is a deliberate misfeature at the moment because it "ensures testing of the base packages".
<slangasek> but those packages should get their own autopkgtests declared, and we should set the pin before touching anything in the tetsbed
<Ben64> are we going to get new kernels without rebooting now?
<apw> slangasek, yep, that does sound confusing indeed
#ubuntu-kernel 2016-11-15
<tjaalton> apw: drm-intel-nightly builds on amd64 seem to be failing
<tjaalton> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
<WeiJunLi> i have a vm with 10.5gb available is it enough space to build 4.8.0 kernel?
<neoark> anyone have a fix for this issue? https://askubuntu.com/questions/844583/state-check-failed-when-running-canonical-livepatch#new-answer
<neoark> It seem like I am getting lot of 403 errors
<cyphermox> bjf: on the system where you get the grub upgrade errors, could you please run /usr/lib/grub/powerpc-ieee1275/prep-bootdev ?
<cyphermox> I've been working on a fix for the issue how I think I managed to reproduce it here in a VM, but it would help to make sure I'm working on the right issue :)
<bjf> jsalisbury, ^
<WeiJunLi> the maximium of mem for vmare fusion is around 8gb, everytime i create a new vm it only has 10gb available and I want to compile 4.8.0 kernel? Any idea to have big space on a vm, my host has around 60gb free
<bjf> PHLin, ^
<bjf> jsalisbury, sorry, i want PHLin to look at that problem with ppc64el and not you
<PHLin> bjf, ack
 * PHLin redeploy the system
<cyphermox> I expect it returns something like /dev/sda or something, and I'll hand you some more code to run in a bit
<bjf> PHLin, be careful that if kernels land in -proposed the automatic testing is going to grab that system
<cyphermox> PHLin: and this is my proposed fix: http://paste.ubuntu.com/23480943/, should return some /dev/mapper/mpathsomething
<PHLin> bjf, ok, maas is now doing its job
<PHLin> cyphermox, got it
<cyphermox> PHLin: if you want to easily compare the "old" behavior and the new one, you'll want to drop "&& !multipath_path" from line 34 in the file (line 38 in the pastebin), and run it as prep-bootdev -l
<cyphermox> ie. that would likely list /dev/sda1 (or something equivalent), being the real disk, and /dev/mapper/mpath0-part1 (the multipath layer)
<PHLin> okok
<bjf> cyphermox, doesn't foundations have a ppc64el system for testing?
<cyphermox> if I'm looking at the right thing, the issue is that prep-bootdev, when run by the grub installer, lists disks in order but it tends to always get them with the "real" disks first, whereas they're claimed by multipath
<cyphermox> bjf: I'm working on a ppc64el in VMs
<cyphermox> it's usually good enough, and easier to redeploy
<cyphermox> (and I can keep more than one deployed to compare things)
<bjf> cyphermox, right and that's not good enough, hence asking us to test (which we are happy to do)
<cyphermox> bjf: only to make sure I really was looking at the right thing
<cyphermox> there's clearly a bug in the way grub-install gets run for multipath on ppc64el, and it's the most likely issue on your system, but it helps to make sure.
<jsalisbury> bjf, ack
<PHLin> cyphermox, http://pastebin.ubuntu.com/23480984/ first result on 3.13.0-101
<PHLin> cyphermox, result with your code: http://pastebin.ubuntu.com/23481000/
<PHLin> cyphermox, looks like it's working as expected, the /dev/mapper/mpath0p1
<cyphermox> yeah, that looks about right
<cyphermox> PHLin: so I'll get you next a new grub package with that change in, so we'll be able to make sure the upgrade goes clean
<PHLin> cyphermox, ok cool
<WeiJunLi> the maximium of mem for vmware fusion is around 8gb, everytime i create a new vm it only has 10gb available and I want to compile 4.8.0 kernel (want to enable some more debug features). Any idea to have big space on a vm, my host has around 60gb free
<PHLin> cyphermox, got to go, just send me a mail and I can work on this tomorrow
#ubuntu-kernel 2016-11-16
<sacarde> hi
<sacarde> I have this problem in building kernel for ubuntu-16.10
<sacarde> http://unix.stackexchange.com/questions/319761/cannot-compile-kernel-error-kernel-does-not-support-pic-mode/319830
<sacarde> that is the solution?
<sacarde> when I apply this patch http://unix.stackexchange.com/questions/319761/cannot-compile-kernel-error-kernel-does-not-support-pic-mode/319830
<sacarde> I have error: patch: **** malformed patch at line 7: all: vmlinux
#ubuntu-kernel 2016-11-17
<sacarde> hi
<sacarde> https://ubuntuforums.org/showthread.php?t=2342399
<sacarde> https://ubuntuforums.org/showthread.php?t=2342399
<rtg> tseliot, there is a 4.9-rc5 based kernel in -proposed that you ought to have a look at wrt nvidia
<tseliot> rtg: right, thanks for letting me know. I'll have a look at it as soon as I'm done with a high priority oem bug (i.e. very soon)
<rtg> tseliot, thanks
<sacarde> how can I solve this error building kernel 4.8 : kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
<smb> sacarde, you could just simply pick the disable-pie patch from the mainline builds (-> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8.8/)
<sacarde> smb, thankyou, I folloow your hint
<sacarde> now I aply patch, and works
<sacarde> thanks
<sforshee> tyhicks: could you take a look at bug 1636890? I'm thinking it might be an ecryptfs problem, but I'm not sure.
<ubot5`> bug 1636890 in linux (Ubuntu) "invalid file times with overlayroot and encrypted home" [Undecided,Confirmed] https://launchpad.net/bugs/1636890
<tyhicks> sforshee: hey - I won't be able to take a look until next week
<tyhicks> sforshee: is that ecryptfs mounted on top of overlay mounted on top of ext4?
<tyhicks> sforshee: nevermind, I see your breakdown of the mounts in comment #15
<sforshee> tyhicks: yeah, it's a weird one. I've been trying to generate the behavior indepentently of overlayroot without success - this doesn't do it: http://paste.ubuntu.com/23492117/
<tyhicks> sforshee: bummer, that was going to be my first thing to try
<vdavidoff> Hello. Does anyone know what it takes to make a ata_dev_dbg print? I have tried a variety of things and a message I think I should be seeing, I am not. I'm trying to confirm I'm doing the right things to make ata_dev_dbg work before deciding that message just isn't getting triggered.
<vdavidoff> I have tried setting the console loglevel to 8 and enabling dyndbg on everything at boot time. Maybe I'm still missing something, though.
<vdavidoff> Ultimately I'm trying to determine if a particular device is blacklisted in libata for TRIM in the running kernel. Based on what I think is the right source code, it is, but I'd like to confirm somehow on the running machine.
#ubuntu-kernel 2016-11-18
<mamarley> apw: Quick question, when do the mainline kernel builds switch to compiling on Zesty?
#ubuntu-kernel 2016-11-19
<White_Light> why was 4.8.9 released in the mainline ppa when upstream has not release 4.8.9 yet?
<apw> White_Light, they are built from tags pushed by upstream, so it all depends how you define "not-released"
<White_Light> I see, thanks apw 
#ubuntu-kernel 2016-11-20
<jpd> hello world
<jpd> ping ogasawara
#ubuntu-kernel 2017-11-13
<alkisg> Hi, if I system boots fine with noapic, and crashes randomly without it, can I use some more refined kernel parameter to pinpoint it, or should I leave it at that?
<lorddoskias> hello i have a tp-link wn822N rtl8192eu based usb wifi dongle and ubuntu 16.04.03. But the rtl8xxxu module is not detecting the wifi dongle. Here is the lsudb output: Bus 001 Device 005: ID 2357:0108
<lorddoskias> it seems the rtl8xxxu driver in ubuntu is missing: c14239f23adb ("rtl8xxxu: Add another 8192eu device to the USB list")
<smb> lorddoskias, you could increase the chances of this getting added to the 4.10 hwe kernel (if you are actually using that and not the original 4.4) before 4.13 becomes the next hwe kernel by filing a bug report for it (just run "ubuntu-bug linux" on the machine with the dongle plugged in). Then mention the bug number here
<longsleep> Hey all, i want to run Kernel 4.14 on Xenial. Anyone here already figured out a way to avoid problems with AppArmor profile compatibility?
<jjohansen> longsleep: it should be fine. Xenial actually has more features apparmor wise than 4.14
<longsleep> jjohansen: mhm - last version i tried was linux-image-4.14.0-041400rc3-generic and there i get lot of denies of eg. dhclient
<jjohansen> longsleep: so there was a patch reverted for 4.14-rc7, that was likely to be the source of your problem. Its not there anymore
<jjohansen> so you should be fine
<longsleep> jjohansen: ah that is excellent news thanks! Will try later tonight
<longsleep> jjohansen: interesting, updated my Xenial installation to linux-image-4.14.0-041400-generic_4.14.0-041400.201711122031 and now [    0.042709] AppArmor: AppArmor disabled by boot time parameter - is that the expected behavior?
<longsleep> trying to add `apparmor=1 security=apparmor` now ..
<jjohansen> longsleep: it depends on how you configured your kernel when you built it. you need
<jjohansen> CONFIG_SECURITY_APPARMOR=y
<jjohansen> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
<jjohansen> CONFIG_DEFAULT_SECURITY_APPARMOR=y
<jjohansen> CONFIG_DEFAULT_SECURITY="apparmor"
<longsleep> jjohansen: yeah sure, i use the one from the ubuntu mainline kernel ppa - since ever those kernels had apparmor enabled by default. Now with http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14/ i need to add `apparmor=1 security=apparmor` - then it actually even works
<longsleep> those now seem to have +# CONFIG_DEFAULT_SECURITY_APPARMOR is not set
<longsleep> mhm ok, thats troubling imho - many people running from that ppa will have no apparmor when going for 4.14 without even noticing
<longsleep> whoa that 4.14 package even has CONFIG_DEFAULT_SECURITY="selinux" - is Ubuntu switching to selinux?
<jjohansen> longsleep: no, I have no idea why that would be set there
<sforshee> jjohansen: our ubuntu configs have changed because of the lsm stacking patches, I think CONFIG_SECURITY_APPARMOR was removed. So when we try to apply those configs to mainline builds probably some options are getting set to whatever the defaults are.
<sforshee> or CONFIG_DEFAULT_SECURITY_APPARMOR i mean
<sforshee> apw: ^, not sure what we should do about that
<jjohansen> sforshee: ah right, I'll get back to you on that
<apw> sforshee: the config will need adapting ...
<apw> there is a way to do that, card me ?
<sforshee> apw: ack
#ubuntu-kernel 2017-11-14
<sforshee> tseliot: I have some nvidia dkms fixes for 4.14, bug 1727015 and bug 1727016
<ubot5> bug 1727015 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-graphics-drivers-304 304.137-0ubuntu1 ADT test failure with linux 4.14.0-3.4" [Medium,Confirmed] https://launchpad.net/bugs/1727015
<ubot5> bug 1727016 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-graphics-drivers-340 340.104-0ubuntu2 ADT test failure with linux 4.14.0-3.4" [Medium,Confirmed] https://launchpad.net/bugs/1727016
<tseliot> sforshee: great, I'll have a look at them soon, thanks
<sforshee> jjohansen: I'm getting an oops from apparmor in 4.14 - http://paste.ubuntu.com/25963263/
<sforshee> this is with a port of the lsm stacking patches from artful applied
<jjohansen> sforshee: ack, I've got a new set of stacking patches I am looking at. I'll get them to you asap
<sforshee> jjohansen: thanks
#ubuntu-kernel 2017-11-15
<sforshee> jjohansen: it turns out I was running a differnt kernel than I thought I was when I was getting that oops (I guess I had forgotten to reboot), it did not have the lsm stacking patches. Now I am running the kernel with those patches and am not getting the oops anymore, so seems the oops wasn't related to those patches and hopefully is no longer a problem.
<jjohansen> sforshee: thanks, I'll take a little more time on the updated patches them. We still want them so we are tracking closer to upstream
<Guma> I was wondering if there is a tool to generate custom kernel configuration for specific hardware (versos doing it by try and error manually) so I can build kernel with just specific options to specific hardware configuration?
<apw> Guma, not really, there are defconfigs for various bits of h/w in the kernel, but making them work with a distro, not so easy
<Guma> apw: I figured it will not be easy. But where would I start reading about it. Something most relevant to what I am trying to do? Any good suggestions?
<apw> Guma, i am not sure there is anything useful, we have been talking about the lack of this kind of information ...
<Guma> apw: I think this is needed. Reading on the net there there are quite few people searching about it but quite contradicting or old information.
<Guma> I think it would be good info for people to get into this space. Else it is very hard to figure this out and some might be turned off. 
<Guma> I got a feeling you already know this since there is a talk about it
<Guma> I think it would be great tool to run after installation on system and it would produce config for current running kernel for starters. I understand that it is all another level to create config for different kernel versions
<mjg59> The information needed to do that correctly isn't available
<mjg59> You'd need kernel build system modifications
#ubuntu-kernel 2019-11-11
<jlayton> where can I get the sources for this kernel? 5.0.0-32-generic #34~18.04.2-Ubuntu ?
<jlayton> (preferably in a git tree)
<amurray> jlayton: https://kernel.ubuntu.com/git/ubuntu/ubuntu-disco.git/tag/?h=Ubuntu-5.0.0-32.34 
<jlayton> ahh, that's disco? I thought 18.04 was bionic...
<jlayton> sorry
<amurray> jlayton: are you using the HWE kernel on bionic? 
<jlayton> I'm just trying to help debug a ceph issue. Need to look and see if they have a botched backport that crept into stable
<amurray> jlayton: looks like that is here https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/?h=hwe&id=73f3faeeb3d35d883bcef0b492074789f7bfaaea
<jlayton> https://tracker.ceph.com/issues/42707#change-151248
<amurray> ie https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/tag/?h=Ubuntu-hwe-5.0.0-32.34_18.04.2
<jlayton> ...and yeah, looks like it has the bad backport
<jlayton> amurray: many thanks!
<jlayton> any idea when the next disco kernel release will be?
#ubuntu-kernel 2019-11-12
<jlayton> looks like the master-next branch has the fix
<amurray> jlayton: https://kernel.ubuntu.com/ shows 2nd December
<jlayton> thanks
<amitk> anybdody know why installing sparse on 19.10 pulls in gcc-8?
<amitk> I thought gcc-9 was the default compiler for 19.10
<tjaalton> amitk: hi, sparse seems to have a hardcoded dep, see it's changelog
<amitk> tjaalton: Hi, I was hoping someone knew _why_ that is the case
<tjaalton> why? because no-one touched it? :)
<tjaalton> it's in universe
<tjaalton> synced from debian
<amitk> tjaalton: fair enough, adds unnecessary disk footprint for a dev image I'm doing
#ubuntu-kernel 2019-11-15
<sdhd-sascha> hi, i am searching the latest, bleeding edge, git tree for the raspi 4 ubuntu kernel ?  
<sdhd-sascha> i only found this, but the branch didn't exists: Vcs-Git: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/eoan -b linux-raspi2
<apw> sdhd-sascha, drop the linux- prefix
<sdhd-sascha> apw: thank you. Is eoan really the latest? I found "focal" too, but the latest commit is older there
#ubuntu-kernel 2019-11-16
<Kaloz> connor_k: sorry for being mia, so I've checked 5.3.0-24 from proposed, and although it fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850600 , som other updates there generate a nice WARN_ON in intel_wait_for_register in i915
<ubot5> Ubuntu bug 1850600 in linux-oem-osp1 (Ubuntu Bionic) "Suppress "hid_field_extract() called with n (192) > 32!" message floods" [Undecided,Confirmed]
<Kaloz> connor_k: https://pastebin.com/zYbDieAE
<connor_k> Hey Kaloz! I'm happy to hear the other bug is fixed. Could you open a new Launchpad bug for the i915 WARN_ON you're experiencing? That way it'll be easier for us to track work on that 
#ubuntu-kernel 2019-11-17
<ChmEarl> problems with LZ4 decompression on Virt platforms: http://archive.ubuntu.com/ubuntu/dists/eoan/main/installer-amd64/current/images/netboot/xen/vmlinuz
<ChmEarl> I've attempted to boot the about kernel with xen->xl, pvgrub2, and qemu-system-i386 (qemu-4.1)
<ChmEarl> none of these Virt platforms can boot the above kernel
<ChmEarl> xen->xl gives a specific error about `failed to LZ4 decompress ..`
<ChmEarl> both eoan and focal fail, but disco works in all these Virt platforms
