#ubuntu-kernel 2005-06-13
<zul> java is fun
<crimsun> both fun and brain-stabbing heartache
<zul> i have an interview tomorrow so i guess i should go over some stuff
<crimsun> good luck!
<zul> thanks
<crimsun> technical interview, I presume?
<zul> i suppose it is...junior/intermediate tech support for a mobile company
<crimsun> oh, good
<zul> better than not working :)
<crimsun> indeed :)
<zul> wha...transmeta going out of business?
<crimsun> :/
<zul> stupid slashdot..
<fabbione> morning
<fabbione> mjg59: <jgarzik> fabbione: that suspend patch isn't right for SCSI
<fabbione> hey JaneW 
<fabbione> hey JaneW (2nd attempt)
<fabbione> infinity http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html
<JaneW> hi fabbione (2nd attempt)
<fabbione> JaneW: we need a name today :)
<JaneW> fabbione: Bashful Brazil
<fabbione> JaneW: is that a nuts? :)
<JaneW> Fabbione: Brazil nut yes it's a big one ;P
<JaneW> http://www.rain-tree.com/brazilnu.htm
<fabbione> great :)
<mjg59> fabbione: Hmm. Bah.
<mjg59> fabbione: To the extent that it breaks existing scsi, or that it just doesn't work on scsi?
<fabbione> it breaks
<mjg59> Ok
<fabbione> and he doesn't have another patch yet
<mjg59> Ok
<mjg59> Well, we'll just have to hope he gets a move on :)
<fabbione> well.. yeah
<jbailey> fabbione: Is that in now?
<fabbione> jbailey: just uploaded..
<fabbione> but i have binaries handy
<jbailey> I don't need to rush it yet.
<fabbione> i can spare you to wait 10 hours to build :)
<jbailey> Handy. =)  Please.
<jbailey> ...
<jbailey> 10 *hours*?
<fabbione> people.u.c/~fabbione/
<fabbione> jbailey: building 8 flavours take ages
<fabbione> + we have build problems
<fabbione> so it might take way more than 10 hours
<fabbione> jbailey: note that i don't even know if that kernel will boot
<fabbione> so keep the proper precautions
<fabbione> s/keep/take
* jbailey puts the "completely untested" hat on.
<jbailey> Hey the damned thing unpacks at least, better than svenl's image did.
<jbailey> (I still haven't hunted down why.  I get dpkg errors with his .deb)
<fabbione> hahah ok :)
<jbailey> Look like no joy so far.
<chmj> morning 
<jbailey> Lemme try it again without 'quiet'
<jbailey> Heya Charles
<fabbione> hey chmj 
<fabbione> jbailey: is your machine lpar? (or something like that)
<jbailey> dict lpar?
<chmj> fabbione: I think someone has to specificly maintain external drivers 
<fabbione> jbailey: dunno... i found a "typo fix" for ppc64 lpar boot
<fabbione> jbailey: but i didn't include it
<fabbione> chmj: inside or outside the kernel?
<fabbione> jbailey: since it will be part of rc6
<chmj> fabbione: I don't know about that 
<jbailey> Oh?  Is he actually doing another rc release?
<chmj> fabbione: some off these drivers are already patches from upstream 
<fabbione> chmj: what external drivers you are talking about... inside our kernel or outside?
<fabbione> jbailey: yes.. rc6 and release according to the schedule
<jbailey> Looks like it means logical partitions
<chmj> fabbione: the ones in external-modules
<fabbione> jbailey: probably
<fabbione> chmj: i am not sure understand 100% what you mean... why somebody should maintain them specifically?
<chmj> fabbione: some off them come as patches 
<fabbione> chmj: yes
<fabbione> and?
<chmj> patches have no version numbers 
<fabbione> chmj: yes they do :)
<fabbione> chmj: some of them in the code, others in the name
<chmj> hmm 
<chmj> fabbione: in the code, makes it hard for them to be automatically watched 
<jbailey> Oh, I see.  http://www.technonics.com/ppc970.htm  - basically lpar is where you do vmwarish things in-chip.  I doubt this beast does that, it's a "consumer" g5 mac.
<fabbione> chmj: i never said it was going to be an easy task
* jbailey retries without quiet
<chmj> fabbione: wich is why I'm saying that someone will need to manually check that
<chmj> s/wich/which/g
<fabbione> chmj: well if it's only 2/3 drivers is ok
<fabbione> just spits out a warning to check them
<fabbione> so that people will remember
<jbailey> Nope, still no joy - almost like the framebuffer isn't loaded.
<chmj> ok 
<fabbione> jbailey: FB doesn't build :/
<jbailey> I get the Setup Done message, Starting Linux PPC64 2.6.12-1-powerpc64-smp blah blah down to smp_core99_probe smp_core99_kick_cpu smp_Core99_kick_cpu done  smp_core99_setup_cpu 0 done
* jbailey blinks.
<jbailey> Right, lemme try ssh then. =)
<fabbione> powerpc64-smp:CONFIG_FB=m
<fabbione> no
<fabbione> actually it is built
<fabbione> ahhh i see
<fabbione> it needs to be inline
<fabbione> crap
<jbailey> inline?
<fabbione> CONFIG_FB=y
<fabbione> instead of modular
<jbailey> Right, but in the meantime I can modprobe it in the initrd
<fabbione> yup
<jbailey> It's not getting as far as getting ssh going, so there's some other issue, too.
<fabbione> jbailey: probably there is more that needs modprobing
<fabbione> if you can start adding fb stuff and see where it stops, that would be great
<fabbione> i am pretty sure it's just question of config options
<fabbione> but not having the frigging hw locally doesn't make it easier
<jbailey> Iz no problem, boss.
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,3--2.6.11.93
<fabbione> jbailey: thanks!
<fabbione> jbailey: i suggest you to copy also the other FB modules
<jbailey> Other than just radeonfb?
<fabbione> there is a +CONFIG_FB_MACMODES=m
<fabbione> i did it all modular, but problably it needs to go all inline
<jbailey> Trying it with all those drivers in the initrd.
<jbailey> No joy.
<fabbione> crap
<fabbione> are you actually modprobing them manually?
<fabbione> or just hoping that they will get modprobed?
<jbailey> No, putting them in the initrd which is set to modprobe them.
<jbailey> I don't have enough connection to the machine at that point to modprobe anything.
<jbailey> I don't think this box has a serial port.
<fabbione> hmmmm
<jbailey> On what speed box does it take 10 hours to build?
<fabbione> jbailey: on davis
<fabbione> but i can rebuild ppc64 only in not too long
<fabbione> 10 hours is the whole package
<fabbione> i am changing the config right now :)
<fabbione> powerpc64-smp:CONFIG_FRAMEBUFFER_CONSOLE=m
<fabbione> powerpc-smp:CONFIG_FRAMEBUFFER_CONSOLE=y
<fabbione> yeah there is more :)
<fabbione> ok it's building now
<fabbione> it shouldn't take too long
<jbailey> Cool, thanks.
<fabbione> modulo gcc segfaults
<fabbione> this will make the FB situtation similar to all the other ppc configs
<fabbione> there might be more to change but at least you should be able to get the console
<fabbione> i am going to get some lunch while it builds
<fabbione> brb
<fabbione> never mind.. it already failed on some drivers
* fabbione fixes
<jbailey> Cool - if I can see what's failing after this point, that would be lovely. ;)
<fabbione> jbailey: i was thinking that perhaps mkinitrd will need ppc64 love too....
<fabbione> what about glibc?=
<fabbione> would a 64bit kernel search for 64 bit libc6?
<jbailey> It shouldn't, no.
<fabbione> jbailey: the image is up
<jbailey> The first thing it does is fire up /linuxrc, which uses the shell script interpreter in the kernel to seek to /bin/sh, which is 32bit.
<jbailey> Same filename as before?
<fabbione> note that is the next version :)
<fabbione> nope...
<fabbione> 1.3
<fabbione> instead of 1.2
<jbailey> Thanks. =)
<fabbione> no problem
<fabbione> jbailey: new 1.3 image on people
<fabbione> jbailey: tell me something while you are working on it.. your silence is killing me :)
<jbailey> Lol, it's just installing.
<jbailey> My connection to the data centre is crap.
<fabbione> hehe ok
<jbailey> booting.
* fabbione crosses his fingers
<jbailey> I still get a black screen
<jbailey> Let's give it a sec and see if I can ssh in, though.
<fabbione> crap
<jbailey> hey
<jbailey> X apparently works, even if the framebuffer doesn't. =)
<jbailey> And I can ssh in now. =)
<jbailey> I see that it's loading the radeonfb
<fabbione> AHHHHHAHAHHAHAHAHA
* fabbione goes and masturbates
<jbailey> *lol*
<fabbione> now...
<fabbione> we need to understand why the FB sucks
<fabbione> well...
<fabbione> there is not much to understand.. it does :)
<fabbione> jbailey: can stick dmesg output somewhere?
<jbailey> $ file a.out
<jbailey> a.out: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped
<jbailey> jbailey@ppc64:/tmp$ ./a.out
<jbailey> Hello, world!
<fabbione> eheheh
<jbailey> sure, need a couple minutes to wake Angie up.
<fabbione> no problem
<jbailey> And the fans appear to have gone nuts. =)
<fabbione> i am not sure APM or PM is available yet
<fabbione> i didn't have any option to enable it
<jbailey> This thing displaces an amazing amount of air.
<jbailey> Also sounds a bit like a jet engine. =)
<fabbione> ehhe
<jbailey> http://people.ubuntu.com/~jbailey/dmesg.txt
<fabbione> [   32.536434]  Console: colour dummy device 80x25
<jbailey> Want one from the working setup too?
<fabbione> isn't this one from the working ppc64 kernel?
<jbailey> I mean from the working ppc32
<fabbione> [   32.614271]  Calibrating delay loop... 66.56 BogoMIPS (lpj=33280)
<fabbione> interesting
<fabbione> yes.. later is fine...
<jbailey> I may as well fetch it now to make the 747 go away...
<fabbione> how much RAM do you have in that system?????
<jbailey> Umm, Looks like 4gb?
<fabbione> [   32.763094]  PowerMac SMP probe found 2 cpus
<fabbione> uhuuh
<fabbione> it's even SMP :)
<jbailey> Yes
<fabbione> jbailey: [   32.614139]  Memory: 3999720k/6291456k
<fabbione> it's more like 6GB
<jbailey> $ cat /proc/meminfo
<jbailey> MemTotal:      4007812 kB
<fabbione> but our kernels don't have more than GB highmem enabled
<jbailey> Ah.
<fabbione> yeah what's in meminfo comes from what the kernel can actually use :)
<fabbione> we need to talk with benh about the FB stuff
<fabbione> he hangs on debian-kernel
<fabbione> he is not around
<jbailey> On ppc32: [   25.954678]  Console: colour dummy device 80x25
<jbailey> [   26.045504]  Calibrating delay loop... 1662.97 BogoMIPS (lpj=831488)
<jbailey> On the ppc32 there's an extra:
<jbailey> [   27.434522]  Console: switching to colour frame buffer device 210x65
<jbailey> in there.
<fabbione> hmmm
<zul> he3y
<jbailey> zul: Know anything about framebuffers? =)
<zul> no :)
* fabbione sighs
<jbailey> Hmm, there's an fbset package.
<fabbione> jbailey: that's not what i am looking for
<jbailey> But I guess the problem might be making the console point to it?
<fabbione> i can't find that exact string
<fabbione> so it's generated at runtime
<fabbione> that means that we need to find what driver spits it
<chmj> jbailey: issint fbset a fluxbox util
<fabbione> and see why in 32 bit works and not in 64
<jbailey> chmj: No idea. =)
<chmj> jbailey: bah, framebuffer device maintanance program
<fabbione> ah here is
<jbailey> ben's on.
<chmj> fabbione: can I give you the watch proggie ?
<fabbione> chmj: i am waiting for it...
<zul> damn ties
<chmj> fabbione: email ?
<fabbione> chmj: or commit it in baz?
<chmj> ok 
<fabbione> chmj: you have access to people, don't you?
<chmj> yes 
<fabbione> so just use sftp instead of http to checkout/commit
<fabbione> put it inside the debian/ dir
<chmj> must I do that from chainstrap ?
<fabbione> nope
<fabbione> ssh to people is allowed from outise via ssh proxy
<chmj> ssh proxy ?
<fabbione> chmj: check the wiki
<fabbione> there is the doc on how to set that up
* fabbione goes off line for a little bit
<fabbione> bbl
<chmj> there goes my first kerne-team commit :) 
<fabbione> ./uscan-extmod --report .
<fabbione> Processing ./kernel-extmod.kwatch ......
<fabbione> uscan-extmod warning: could not open ./kernel-extmod.kwatch: No such file or directory
<fabbione> A   passed.kwatch
<fabbione> what's that?
<chmj> usca-extmod --wathifile = passed.kwatch 
<chmj> uscan-extmod --wathifile passed.kwatch 
<chmj> the wathfile by default will be kernel-extmod.kwatch, one I got it looking pretty
<chmj> s/one/once/
<fabbione> ehhe nice :)
<chmj> the script, or my typing ? 
<fabbione> the script :)
<chmj> :) 
<fabbione> chmj: did already convert all the entries in external-drivers to the watch file?
<fabbione> or only a few for sampling?
<chmj> a lot 
<fabbione> all of them or only a selection?
<fabbione> before we spend time updating that file to death...
<chmj> only a section, 
<fabbione> ok
<chmj> I'm trying to get the rest off the URLs 
<fabbione> chmj: ok. you tell me when it's ready for "deplyoment", but it looks good already :)
<chmj> did I mention I hate "You don't have permission to access <insert driver location folder here> on this server."
<fabbione> ehehhe
<jbailey> So who thinks that Apple using "intel chips" might mean itanium? =)
* jbailey hides.
<zul> ok wish me luck
<jbailey> zul: Good luck, chuck!
<fabbione> zul: come back as winner!
<jbailey> fabbione: fbcon working right.
<fabbione> jbailey: cool
<jbailey> fans haven't gone nuts.
<jbailey> x is up
<fabbione> jbailey: and yes.. i am sure apple will go ia64 :)
<chmj> zul: what u need luck for ? 
<fabbione> goody
<jbailey> ssh in.
<jbailey> "...  and print!"
<fabbione> chmj: you broke the baz archive!
<fabbione> you need to fix your umask on people
<fabbione> and change some permissions in the baz repo
<fabbione> otherwise we are all doomed
<fabbione> chmj: login to people and do what i say
<fabbione> cd /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre1,3--2.6.11.93
<fabbione> chmod 775 patch-4
<fabbione> cd patch-4
<fabbione> chmod 775 ++revision-lock
<fabbione> cd ++revision-lock
<fabbione> chmod 775 +contents
<jbailey> Not find a chmod -R g+w 
<jbailey> s/find/just/
<fabbione> jbailey: it's the same....
<jbailey> ?
<fabbione> chmj: once you have done go back to your home and:
<fabbione> edit .bash_profile
<fabbione> change the umask to look like:
<fabbione> umask 002
<fabbione> then edit .bashrc and add the same umask line
<fabbione> logout
<fabbione> and login again
<fabbione> that will fix
<chmj> done 
<fabbione> chmj: you need to change the permissions to all the dirs i told you
<chmj> I did 
<fabbione> nope
<fabbione>  /home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre1,3--2.6.11.93/
<fabbione> 4 drwxr-xr-x   3 charles  warthogs 4096 Jun  6 13:57 patch-4
<fabbione> that needs to be 775
<fabbione> same for the directories inside
<chmj> recursively ?
<fabbione> chmj: you are missing the ++revision-lock directory inside patch-4/
<fabbione> the others are or seem to be ok
<chmj> ok, done 
<fabbione> ok thanks
* fabbione tests
<fabbione> yup
<fabbione> did also change your netmask?
<fabbione> anyway i need to go offline again
<fabbione> bbl
<jbailey> fabbione: s/netmask/umask/ ?
<chmj> erm,bashrc and bash_profile, done 
<fabbione> yeah that :)
<jbailey> O
<jbailey> I'm trying to imagine what the ugliest scenario the initramfs might have to cope with for booting, and whether I care.
<jbailey> I'm adding the hooks in, but obviously somethings might care what order they're run in, like lvm before md, and cryptroot after both.
<mjg59> Any idea when the -1.2 builds are likely to be done on x86?
<jbailey> None.  And Fabio may have sent up -1.3 with the ppc64 changes from this morning.
<mjg59> Ah
<mjg59> Fair enough
<fabbione> no i didn't push 1.3 to archive.
<fabbione> 1.2 needs NEW love
<fabbione> and i386 is FTBFS
<mjg59> Ah, ok
<fabbione> hell it did build here!
<fabbione> Inconsistent kallsyms data
<fabbione> Try setting CONFIG_KALLSYMS_EXTRA_PASS
<fabbione> BAH
<fabbione> make[2] : Leaving directory `/build/buildd/linux-source-2.6.12-2.6.11.93/debian/b
<fabbione> uild/build-686-dbg'
<fabbione> well this is tomorrow's stuff
<lamont_r> fabbione: linux-source-2.6.12 won't build on hppa until expect-tcl8.3 arrives in the archive and gcc-3.4 is buildable
* lamont_r grumbles at doko, then realizes that he was going to pester the maintainer as well
<doko> lamont: expect-tcl8.3 was made only for you^H^H^Hhppa ;)
<lamont_r> doko: yeah
<lamont_r> but it's not in the ubuntu archive.  hence gcc-3.4 is pending...
<doko> so build it, don't grumble ;-)
<lamont_r> another option would be to disable the tests on hppa... :)
<doko> it's not?
<lamont_r> ah, is in universe
<lamont_r> coolness
* lamont_r mumbles a thank you
<zul> well round one done
<zul> miss a day...miss alot
#ubuntu-kernel 2005-06-14
<zul> 686-smp-dbg being built
<fabbione> morning
<fabbione> zul: still here?
<fabbione> lamont: ?
<fabbione> infinity: ping??
<infinity> 686-dbg builds right after 386-dbg, right?
<fabbione> yes
<fabbione> it should
<fabbione> AH AH
<infinity> Alright, then we're almost at the point of failure.
<fabbione> davis has hardware problems
<fabbione> it started segfaulting also on a hoary chroot
<infinity> And by 'hardware problems', you mean 'it came from Apple'?
* infinity goes to have a smoke and expects the kernel build to be dead or succeeded by the time he gets back.
<fabbione> ehhe
<fabbione> oh shit
<fabbione> i just trashed the build on concordia!
<fabbione> oh well it doesn't take long to redo it
<infinity> Building 686-dbg now..
<infinity> Please fail, please fail...
* infinity joins a religion breifly so he can pray to some god or other, then unjoins.
<fabbione> hehe
<infinity> \o/
<infinity> Yay.  It failed the same way.
<infinity> And, ofr the record, the chroot is completely up to date.
<fabbione> oh great suckage
<fabbione> now it would be interesting to see if the same chroot moved to concordia will complete the build
<fabbione> infinity: let's try something...
<fabbione> go where the kernel has been unpacked
<fabbione> rm debian/build/build-686-dbg/stamp-build (if there is any)
<fabbione> and do.....
<infinity> (Should we try KALLSYMS_EXTRA_PASS?)
<fabbione> sed -i -e's/# CONFIG_KALLSYMS_EXTRA_PASS is not set/CONFIG_KALLSYMS_EXTRA_PASS=y/g' debian/build/build-686-dbg/.config
<infinity> Heh.
<fabbione> then try to complete the build
<infinity> Oh, for.... <sigh>
* infinity forgot the -nc switch to dpkg-buildpackage.
<infinity> Thankfully, this is a reasonably speedy machine.
<fabbione> yeah but you lose the config change
<infinity> I know.
<fabbione> you need to stop and edit debian/config/i386/686-dbg
<fabbione> so it will be done automatically
* infinity tries this again, with his brain engaged.
<fabbione> infinity: good idea :)
<infinity> "There is a simple workaround that is to increase the WORKING_SET define
<infinity> in scripts/kallsyms.c to something like 65536. This will include every
<infinity> symbol in the token table calculation, so that even if symbol position
<infinity> changes, the token table should be the same."
<infinity> http://seclists.org/lists/linux-kernel/2005/May/2010.html
<infinity> "The problem with this approach is that it takes longer to calculate the
<infinity> token table. (~3secs on my P4 2.8GHz, 11300 symbols)"
<infinity> I think we can spare 3 seconds on the buildds in the name of working kallsyms.  Perhaps this is a patch/fix we should apply. :)
<infinity> (Or does it change the installed token table (System.map) to be huge?... That would be a runtime issue, not a build issue.  Hrm)
<fabbione> no idea really
<fabbione> but than... why does it build on concordia???
<fabbione> and locally?
<fabbione> but not in the buildd?
<fabbione> i don't believe the patch is the real solution to the problem, tho it can be used to workaround it
<infinity> And here's an explanation of the bug
<infinity> http://seclists.org/lists/linux-kernel/2005/May/1727.html
<infinity> I think the answer to "why does it only happen sometimes?" is "pure luck."
<fabbione> make sense
<infinity> (It may also have something to do with the running kernel, phase of the moon, and your favourite lunch item)
<fabbione> ehhee
<fabbione> infinity: we can just test it :)
<fabbione> infinity: do you still have the unpacked tree?
<infinity> Well, Im rebuilding with EXTRA_PASS right now.
<infinity> But I like Sam's patch better (expecially since he seems confident it will make mainline)
<fabbione> i am checking if it has been committed after rc5
<fabbione> the problem is that shitnezz is in bk
<fabbione> and linus doesn't use bk
<fabbione> no it's not upstream yet
<fabbione> JaneW: ping?
<infinity> Ahh, here's why:
<infinity> "As noted in mail sent to you the 14th of March I have this patch queued
<infinity> up. But since Linus has asked for a calm down period it will wait
<infinity> until next kernel release opens up."
<infinity> So we may not see Sam's patch in mainline until 2.6.13
<infinity> After this build, I'll check to see if the problem we're having is, indeed, the problem Sam's patch solves, or a differentone.
<infinity> (looks like kallsyms alignment has just been messy in general lately... Look at all the patches to arch-specific areas in the tree for alignment issues...)
<fabbione> infinity: cool thanks
<infinity> IOW, someone broke something recently in the name of "elegance", and everyone else is cleaning up the mess.  Yay.
<infinity> (Is it too late to switch Ubuntu to a BSD kernel?)
<infinity> <cough>
<fabbione> infinity: ahaha
<fabbione> we can probably consider to create a derivate once lp is in place
<fabbione> the main issue is "when lp is in place"
<fabbione> we need a name for the security release
<JaneW> fabbione: pong
<fabbione> JaneW: right in time :)
<fabbione> we need 2 names lady :)
<JaneW> 2!
<fabbione> one vegetable/fruit based for the security release
<JaneW> don;t be greedy
<fabbione> and the usual nut for breezy :)
<fabbione> 2 releases.. 2 different targets ;)
<JaneW> fabbione: kernel - Laughing Lentil
<JaneW> fabbione: security - Prickly Pear
<fabbione> JaneW: rocking!!
<fabbione> oh rc6 is out :)
<infinity> JaneW : Nice to see that you've found a niche in Ubuntu. :)
<infinity> Yeah, -rc6 is out.  That's what I was grepping for alignment changes. :)
<fabbione> no i was checking directly in git
<fabbione> and it's not there yet
<fabbione> there are already a bunch of commits after rc6 including build fixes
<fabbione> for today let's get this rc5 out with ppc64 and dbg support
<fabbione> rc6 can wait
<infinity> BUT RC6 IS SO MUCH BETTER CAUSE IT HAS A HIGHER NUMBER ON THE END!!!
<fabbione> even if it should take too long to switch
<fabbione> hahahahhaha
<infinity> So, do you watch the build logs, make a note of every driver that has "I can't write C to save my life" compile warnings, and make a mental note to neevr use those modules on your own system? :)
<fabbione> no.. i just don't use ubuntu kernels on my machine :)
<fabbione> ahhahha
<infinity> Alternately, there's the "you're using stuff that's been deprecated for 3 years, so obviously you don't maintain your dirvers" warnings.  I don't like those much either. :)
<fabbione> yes
<fabbione> ops
<JaneW> infinity: heh yes, it's a tough job, but someone has to do it ;P
<infinity> fabbione : Builds fine with EXTRA_PASS.  Will try Sam's patch instead now, for kicks.
<infinity> (Though EXTRA_PASS should be a good enough bandaid to get this going for now)
<fabbione> infinity: ok. remember to unset the EXTRA_PASS with the patch
<infinity> Yes, obviously.
<infinity> If you want to upload a -1.3 with EXTRA_PASS for now, though, it'll work on the buildds, it seems.
<fabbione> nah i can wait for your extra test
<fabbione> but hmmm
<fabbione> yeah
<fabbione> i will upload 1.3 with EXTRA_PASS
<fabbione> and we can figure the proper fix for 1.4
<fabbione> actually there is another thing we forgot to set in the -dbg packages...
<fabbione> the ramdisk size that zul was talking about
<infinity> Oh?
<fabbione> infinity: a -dbg initrd is HUGE
<infinity> -dbg ramdisks are too big?
<infinity> Yeah.  That makes sense. :0
<fabbione> and the kernel default is not enough
<fabbione> so either i change the BLK_DEV_RAM_SIZE to a reasonable size
<fabbione> or we need to figure a hook for grub
<fabbione> and i guess the former > latter
<fabbione> now the point is that i trashed all the -dbg images to test :)
<fabbione> BUT WE HAVE BATTLE STAR CONCORDIA!
<fabbione> with ccache :)
<fabbione> goody.. both gcc-4.0 and gcc-3.4 are running the test suite on sparc
<infinity> Pfft.  I'd feel your pain if I wasn't building gcc-3.3 and gcc-3.4 on m68k right now, after having just done two gcc-4.0 builds in a row.
<fabbione> ehhehe
<fabbione> [   ]  linux-image-2.6.12-1-686-dbg_2.6.11.93-1.3_i386.deb          07-Jun-2005 09:57  147M  
<fabbione> what's wrong with this????
<infinity> Ouch.
<infinity> Also, ouch.
<infinity> No one's going to install that.
<infinity> Which makes it effectively useless.
<infinity> IMO.
<fabbione> and elmo will hang us on a cross, starts the witch dance and burns us alive
<fabbione> can you image over a GB of kernel push to the mirror on each update?
<chmj> hehehe
<fabbione> ok backup solution
<fabbione> we can provide the configs, but not build them by default
<fabbione> who needs it, will build it
<chmj> +he 
<infinity> That's probably better.
<infinity> I'm on 1.5k DSL, and in most of the world, that's still considered a "really good" connection (though I think it's crap), and as a regular user, I would never download a 147 MB package to debug a bug I filed.
<fabbione> yeah i see no other solution
<infinity> And when downloading the source is less bandwidth than downloading the debug package, one starts to wonder. :)
<fabbione> infinity: actually.. that would be a good way to scare users in filing bugs
<fabbione> ahhaha
<fabbione> i need a big fat cigarette
<Mithrandir> infinity: 1.5k DSL is fairly measly. :P
* infinity heads off to go grocery shopping.
<infinity> Back soon.
<infinity> Mithrandir : Oh, I know, but it's still "decent" to most poeple.  Just not geeks.
<Mithrandir> infinity: 1.5k?  You mean 1.5M, I hope.
<Mithrandir> 1.5k is measly.  It's slower than what you get from a 28.8 modem
<infinity> Err, yeah.
<infinity> 1.5M, obviously.
<chmj> I can only dream about 1M+ adsl 
<infinity> Brain == Lame.
<Mithrandir> I need to get a faster networking card, since my router only has a 11Mbit WLAN card which limits my speed to ~2Mbit on my DSL.
<Mithrandir> apparently, I have 4Mbit now.
<infinity> Lucky.
<infinity> I'm hoping to see reasonable DSL speeds here within a year or so.
<chmj> that a lot off bandwidth 
<Mithrandir> not my fault.  They're upgrading the DSL for free once in a while ATM.
<infinity> I miss my old 7Mbps DSL in Calgary..
<chmj> Mithrandir, what country u in ?
<Mithrandir> I ordered 2Mbit which then went to 2.2, 2.4, 2.6, then 4
<Mithrandir> chmj: Norway.
<infinity> They claim we'll get ADSL2 and ADSL2+ (14Mbps and 28Mbps, I think) here within a year or so.
<Mithrandir> infinity: that's decent enough
<infinity> Personally, I can't wait.
<chmj> Mithrandir, ahh, the land off lots and lots of bandwidth 
<infinity> Anyhow.  Groceries.  Back later.
<fabbione> you all suck
<Mithrandir> infinity: but they'll still steal your money by charging you 100 AUD per microbit.
<fabbione> but i will probably get 100Mb in a year or 2
<chmj> (O.o)
<infinity> Mithrandir : I pay 100AUD flat rate right now for 1.5Mbps unlimited.  It's not the kind of cheap I was used to in Canada, but it's reasonable for around here.
<Mithrandir> infinity: heh, around 20AUD more than I pay for my 4Mbit unlimited.
* Mithrandir tries to debug the acx100 problem
<Mithrandir> fabbione: the new driver and i386 worked, at least
<fabbione> Mithrandir: ah good to know
<Mithrandir> fabbione: nah, because then the bug is mine. :-P
<fabbione> that too :)
<fabbione> infinity: unpacked kernel is like 500MB !
<fabbione> ahhaha
<fabbione> 41764 -rw-r--r--   1 root root 42717184 Jun  7 11:33 initrd.img-2.6.12-1-686-dbg
* fabbione crashes on the floor
<mjg59> Hahahahahaha
<Mithrandir> *chuckle*
<mjg59> fabbione: I think something very odd has happened there
<Mithrandir> 42 MB initrd! Rock!
<Mithrandir> does it come with a free 1GB memory module too?
<fabbione> mjg59: with all _DEBUG configs turned on
<fabbione> i will try to rebuild it
<fabbione> time to get some food
<Mithrandir> oddbjoh: fabbione it still blows up with latest upstream.
<fabbione> Mithrandir: also on i386?
<fabbione> or only on amd64?
<Mithrandir> fabbione: I didn't try very long on i386.
<Mithrandir> loads and loads of warnings while compiling on amd64.
<fabbione> Mithrandir: no shit..
<fabbione> mjg59: i did the rebuild.. it's 147MB
<fabbione> so no -dbg by default
<jbailey> g'm all.
<Mithrandir> hi jeff
<fabbione> hey jb
<mjg59> Hmm. Something is very odd on this machine.
<mjg59> PCI is basically broken after suspend/resume
<jbailey> PCI devices are overrated.
<jbailey> fabbione: Got time for me, or do you need to wait for a bit?
<fabbione> jbailey: yes in 5 minutes i will be completely your :)
<jbailey> Excellent.  I'll afk for 5 then.
<infinity> fabbione : FWIW, Sam's patch also fixed the kallsyms bug.
<fabbione> infinity: cool
<fabbione> jbailey: ready to start?
<jbailey> fabbione: Yup, back now.
<fabbione> i was almost ready to go again :)
<fabbione> so what are we going to hack?
<chmj> i was gonn ask that 
<jbailey> fabbione: making make-kpkg or whatever the piece is flexible enough to do mkinitramfs as well as mkinitrd
<fabbione> jbailey: ok than we are talking about kernel-package postinst files that are installed in the linux-image postinstalls
<jbailey> fabbione: Lovely.
<jbailey> I'm glad you know where all that crap is.  My brain started to go square while reading make-kpkg
<fabbione> there are a few files that make use of mkinitrd
<fabbione> or call it
<fabbione> for what i can see we need to modify image.preinst and image.postinst
<jbailey> Are they all after /etc/kernel-img.conf has been sourced?
<fabbione> i am checking...
<jbailey> If yes, we can just do ramdisk = /usr/sbin/mkinitrd, and then refer to "${ramdisk}"
<fabbione> jbailey: for the preinstall 1) source the config and check the path to mkinitrd
<fabbione> i guess the call happens later on
<fabbione> probably only in postinst
<fabbione> preinstall looks more like a sanity check before messing around
<jbailey> MAkes sense.  No sense unpacking the kernel for 30 minutes on an m68k box if it's setup poorly.
<fabbione> right
<fabbione> the postinst creates the image and does all the work of checking/unchecking
<fabbione> jbailey: we definetely want to make the change as smooth as possible and configurable
<jbailey> Right.
<jbailey> I can make the initramfs args the same as the initrd ones, that's easy enough.
<fabbione> jbailey: i think we shouldn't get crazy to make the same
<fabbione> but if you think that the args can be the same
<fabbione> it's even easier
<jbailey> I think it sounds less miserable than making the interface from the postinst configurable. =)
<jbailey> Yeah, there isn't a problem.
<fabbione> uh that's easy enough :)
<fabbione> also because we want to get these changes upstream
<fabbione> we don't want to blindly replace mkinitrd, do we?
<fabbione> or we want?
<jbailey> Well, that's why I'm thinking with a variable
<jbailey> If we call it as ${ramdisk}, where the default is /usr/sbin/mkinitrd
<jbailey> I will override it during my development here as /usr/sbin/mkinitramfs
<jbailey> And when it's time to switch, we just change the default, and what the Depends: line has.
<fabbione> that's more complicate than my solution :)
<fabbione> well actually... why do we need to touch kernel postinstall at all???
<fabbione> let's make it in a very simpler way
<fabbione> 1) make mkramfsthingy to accept the same options as mkinitrd
<fabbione> 2) upload a mkinitrd package with the wrapper in place of mkinitrd
<fabbione> (and rename mkinitrd as mkinitrd.whatever)
<jbailey> And then alternatives it?
<fabbione> 3) upload ramfsthingy with the config file for the wrapper
<fabbione> no.. the wrapper will read the config file and use mkinitrd or the other one
<jbailey> Oh ugh.
<jbailey> This is simpler?
<fabbione> at this point all the changes are done outside the kernel
<fabbione> yes
<fabbione> becuase you change the default in the config file and you are done
<fabbione> when you want to kill mkinitrd, you just do it, changing the default and removing the mkinitrd.orig
<fabbione> and you didn't touch any of the other packages
<fabbione> it's all done at a lower level that the kernel doesn't give a rat ass about :)))
<jbailey> I think we're talking about a 2 line change to the kernel postinst, though.
<fabbione> jbailey: it's a 2 line changes that are objects of other variables...
<fabbione> first we need to change kernel-package
<jbailey> 3 line.
<jbailey> my $ramdisk = "/usr/sbin/mkinitrd"; # initrd generating program
<fabbione> the configs in kernel-packages can be overridden by the user and that affects also kernel postinstall
<fabbione> + upload the kernel with the new postinstalls
<jbailey> $ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig;
<fabbione> and your packages to make all the above working :)
<jbailey> And change the line that contains "mkinitrd" to '$ramdisk'
<jbailey> And the solution of futzing with the postinst means that anyone can change this at a later tim.
<jbailey> Otherwise mkinitrd has to grow a wrapper, has to analyse a foreign config file and there's no future flexibility.
<jbailey> Like in case the yaird folks want to make it possible to use their setup under Debian.
<fabbione> hte configfile only has one entry... mkinitrd.real = true|false
<jbailey> Ugh  You mean use an extra config file?
<fabbione> it doesn't need to use a foreign config file
<jbailey> I think that's wrong.
<jbailey> I think it needs to be in kernel-img.conf
<jbailey> Otherwise people are having to look in yet another place for this.
<jbailey> And there's still  no flexibility
<fabbione> that is right, but you said you needed this for testing, didn't you?
<jbailey> So it would wind up having to parse it out, and forces us to keep the mkinitrd name.
<fabbione> or do you want to go directly for final solution?
<jbailey> Right, but why not make it flexible enough to do more when it appears to be a 3 line change in one file. =)
<fabbione> because take into account that a change to kernel-package might not go into debian :)
<jbailey> I'll NMU it in if I need to.
<jbailey> =)
<jbailey> initramfs is coming to town there too.
<jbailey> As is yaird
<fabbione> jbailey: that'd be Manoj's toy :)
<jbailey> (I will likely sponsor)
<jbailey> I haven't had NMU wars with someone in ages. =)
<fabbione> hmm ok
<fabbione> if you prefer that way we can do it
<jbailey> I'mve pinged manoj to check with him.
<fabbione> i really don't mind
<jbailey> But for 6 lines of changes (including the preinst check), it seems... excessive to add a new config file and a wrapper and all that.
<fabbione> sure i understand your point
<fabbione> i was considering the option to keep all the initrd/ramfs creation stuff outside of kernel build-deps and depends...
<fabbione> that will also require the ramfs to Depends: on kernel-package
<fabbione> that is actually only a build-dep for the kernel
<jbailey> hmm.
<jbailey> forgot about the depends: thing.
<fabbione> specially if you want it configurable
<jbailey> hmmhmmhm
<jbailey> Well, I suppose that could be done with provides on our side.
<fabbione> uh?????????
<fabbione> if you want /etc/kernel-img.conf you want kernel-package
<fabbione> that right now is only a b-d
<fabbione> with your change it needs to be a depends
<fabbione> if not for linux-image, it needs to be for the ramfs package
<fabbione> for linux-image is enough it's unpacked and the config there
<jbailey> Sorry, lagging a second from the phone..
<fabbione> sure
<fabbione> don't worry
<fabbione> i am preparing 1.3 for upload
<fabbione> just to get ppc64 to boot and i386 to build :)
<fabbione> brb
<jbailey> Umm.
<jbailey> Okay, I don't think your statemenet about kernel-img.conf coming from kernel-package is true.
<jbailey> I think it's placed there by d-i.
<jbailey> If it's not there, the kernel will refuse to install, since it won't have do_initrd = Yes
<fabbione> dpkg -c /mirrors/ubuntu/pool/main/k/kernel-package/kernel-package_8.135ubuntu2_all.deb 
<fabbione> -rw-r--r-- root/root       965 2004-11-17 17:33:32 ./etc/kernel-pkg.conf
<fabbione> oh kernel-img.conf
<jbailey> =)
<fabbione> hell i was looking at the wrong file
<fabbione> which package provides kernel-img.conf?
<jbailey> Nothing does.
<fabbione> kernel-package: /usr/share/doc/kernel-package/examples/sample.kernel-img.conf
<fabbione> kernel-package has the manpage and so on
<fabbione> but not the config file
<jbailey> asking Kamion in #u-d
<zul> yo
<fabbione> hey zul
<fabbione> zul: i have a bad news
<zul> hmm?
<fabbione> we need to revert the -dbg stuff
<fabbione> just the 686 image is like 147MB
<fabbione>   * Do not build -dbg flavours automatically since images are huges, but still
<fabbione>     provide configs in debian/config/debugging/$flavour for the users.
<fabbione> that's the best we can do :(
<zul> thats fine..
<zul> less work for me then
<fabbione> btw 12rc6 is out
<zul> goody
<zul> heh...it seems like everything i do is dropped ;(
<fabbione> zul: it wasn't really an option to push more than a GB of data on each kernel upload
<fabbione> sorry..
<fabbione> i didn't expect them to be so big
<zul> i know..i said that tongue in cheek
<jbailey> fabbione: rc6 should contain the module information that you told me about, yes? =)
<fabbione> jbailey: yes it does
<jbailey> w00t
* jbailey asks nicely for it. =)
<fabbione> jbailey: so if you want to go ahead and change kernel-package is fine for me
<jbailey> fabbione: What I was thinking of for the build-dep, is that I could make mkinitrd Provides: kernel-ramdisk
<fabbione> jbailey: that will be tomorrow's stuff
<jbailey> fabbione: For now if you depend on mkinitrd | kernel-ramdisk, and change it later to initramfs | kernel-ramdisk that might solve the problem.
<fabbione> Depends: initrd-tools (>= 0.1.78ubuntu1), coreutils | fileutils (>= 4.0), module-init-tools (>= 0.9.13)
<fabbione> jbailey: can't the 2 packages co-exist?
<fabbione> ok.. hold on..
<fabbione> let's make a point here
<jbailey> Sure...
<fabbione> are we doing all this config stuff only for testing??
<jbailey> It's not a conflicts, it's just to make sure you have something providing it.
<fabbione> or is it going to be the final solution?
<fabbione> because given that NOBODY owns /etc/kernel-img.conf
<jbailey> I'd like it to remain forever to allow some flexibility.
<fabbione> i am really unhappy of something mangling it
<jbailey> nobody owns it, but you're the only one using it.
<fabbione> given that we don't have the previous state of the config file
<fabbione> jbailey: are you sure?
<fabbione> i am one of the package using it
<fabbione> we are not sure i am the only one
<fabbione> also.. who is going to mangle it?
<fabbione> to switch default?
<jbailey> I haven't encountered anything else using it, and the name suggests that it's for you.
<jbailey> No, nothing should ever need to mangle it.
<jbailey> That's why everything just defaults to initrd-tools for now.
<fabbione> so if you make it configurable, how are we supposed to switch default?
<fabbione> if the default is in the config?
<jbailey> We just change the default when no configuration is provided.
<jbailey> Default doesn't go in the config.
<fabbione> ok
<fabbione> so let's summarize the steps:
<fabbione> 1) change kernel-package/kernel/postinst to look for that ramdisk var
<fabbione> 2) upload initrd-tools to provide kernel-ramdisk
<fabbione> 3) switch the images to Depends: initrd-tools | kernel-ramdisk
<fabbione> 4) test test test
<fabbione> 5) switch linux-image Depends: to initramfs | kernel-ramdisk
<fabbione> even if i really don't see the point in the kernel-ramdisk thingy
<fabbione> we could just switch the default and that's it
<fabbione> or perhaps you want to have kernel-ramdisk Provided by both initramfs and initrd-tools preferring one of them?
<fabbione> jbailey: are you still around?
<fabbione> i need to stop soon
<fabbione> i am tired to death
<jbailey> fabbione: Right.  The only advantage of the kernel ram,disk stuff
<jbailey> is flexibility.
<jbailey> I'm not too worried about that.
<fabbione> ok
<jbailey> The config file on its own would make me happy.
<jbailey> I'll ping manoj to figure out how likely it is that he'll accept it.
<fabbione> do you want to start with kernel-package?
<jbailey> Yes.
<fabbione> ok
<jbailey> Mind if I do the hackery and upload?
<fabbione> not at all
<fabbione> go ahead :)
<jbailey> Lovely.
<jbailey> I'll try to push it into Debian sanely so that you can just sync again.
<fabbione> i don't care who uploads my package, until i know who is working on them and why :)
<fabbione> meh kernel-package is desynced anyway
<fabbione> i did try to talk with Manoj unsuccessfully for a few days now
<jbailey> Yup.  Ilike to check to make sure I'm not running over other work that's being done.
<fabbione> well there are the changes to make powerpc64 a buildable image :)
<jbailey> If he doesn't reply, it's easy.  I NMU in Debian because of unresponsive maintainer.
<fabbione> jbailey: not all ubuntu changes should go in Debian
<jbailey> No, just this one.
<jbailey> I know you're trying to keep it the same.
<fabbione> exactly
<fabbione> but for ubuntu go ahead and do it...
<fabbione> so we can test the solution and propose it to Manoj as "tested and it works"
<jbailey> Cool.  I'll get that in by the end of my day.
<fabbione> perfect
<jbailey> This is supposed to be my support day, so I'll be writing specs today.
<jbailey> Perhaps I'll wake up the laptop and do so on the roof deck.
<fabbione> jbailey: poing 1 and 2 is your stuff :)
<fabbione> i will do point 3 in prepartion with 12rc6
<fabbione> that would be my tomorrow
<jbailey> I'll just do point 1 for today.
<jbailey> I'm not fussed about the kernel-ramdisk bit for now.
<fabbione> ok
<jbailey> I haven't thought that part through completely.
<jbailey> I've only thought through the config file.
<fabbione> ok well.. there is always the option to upload an ramfs that Conflicts/Provides mkinitrd
<jbailey> And it solves my immediate need that all my systems should be running initramfs' now to make sure I'm testing enough.
<fabbione> just for the testing time
<jbailey> Can't, kernel-packages have a versioned depends.
<jbailey> The provides lose out.
<fabbione> ah crap
<fabbione> ok
<fabbione> well let
<fabbione> well let's go trough point 1/3 asap
<fabbione> so you get an easy working environment
<fabbione> we can rethink the other bits later
<jbailey> initrd and initramfs coexist.
<jbailey> So there's no fuss.  I don't care for now what gets depended upon until we switch.
<jbailey> That's why I'm content to leave it alone for my testing.
<fabbione> oky
<fabbione> i guess i am off
<fabbione> i might pass by later
<jbailey> Thanks for staying up for me, Fabio.  g'd evening!
<fabbione> no problem dude
<fabbione> it's just that today i am more tired than usual
<fabbione> otherwise i would have done the implementation with you
<jbailey> I think I've actually finished the implementation now, I just need to test.
<zul> fabbione: did you put up rc6?
<jbailey> zul: He said that was tomorrow's work.
<zul> ah ok
<zul> there is a cc meeting today isnt there?
<zul> i hate dealing with recuriters
<fabbione> zul: i will start 12rc6 tomorrow..
<fabbione> i am off to bed now
<zul> ok
<lamont__> mjg59: ping
#ubuntu-kernel 2005-06-15
<mjg59> lamont__: Hello
<lamont__> mjg59: was wondering after the state of the various suspend/sleep/snooze/nap modes on the nc6000 with stock hoary and with the custom CD...
<lamont__> and getting ready to run out the door, sadly
<mjg59> lamont__: Should work fine, you might need to blacklist i2c_i801
<lamont__> hrm.. I sense an echo.... coolnes.
<fabbione> morning
<zul> evening
<fabbione> hi zul
<zul> fabbione: i have a first version of linux-non-supported-modules ill put the *.gz and debian/ directory in baz tomorrow, well make the *.gz accesible, im having problems generating the amd64 stuff debs though
<fabbione> .gz???
<zul> i put all the drivers in a tar.gz file
<fabbione> why?=
<zul> how would you do it?
<fabbione> put them directly in a .deb?
<zul> linux-non-supported-modules-2.6.12-1-386_2.6.12-1_i386.deb 
<fabbione> so where the tar.gz comes from?
<zul> heh its still a work in progress
<zul> i created a directory with the external drivers and tarred it up
<fabbione> there is very little point in tarring it up
<fabbione> you can just move the modules in a dir and create the deb out of it
<zul> well i discovered that when i was doing it
<zul> :)
<fabbione> yeah but that's the way you really want to do it
<fabbione> :)
<zul> :P
<fabbione> but don't worry.. just finish what you are doing
<fabbione> i will give it a clean afterwards :)
<zul> yeah its my first real deb 
<fabbione> ehehhe
<fabbione> don
<zul> gee thanks :)
<fabbione> don't worry
<fabbione> you are doing a great job
<zul> ill get the hang of it eventually...ebuilds were so much easier ;)
<zul> still evil though
<zul> oh yeah i have another interview next week
<zul> i need to learn about sybase though :(
<fabbione> amen
<fabbione> sybase sucks
<fabbione> :)
<zul> it looks like postgresql though...am reading sybase 101
<fabbione> eheh
<fabbione> i am pushing the orig.tar.gz for rc6 on people.u.c
<fabbione> it will take a little while
<zul> k cool..
<zul> im thinking of a way to get kdb with the kernels without having to enable config_debug
<infinity> Sybase is simple.
<zul> looks like it
<zul> bbl
<fabbione> later
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,1--2.6.11.94
<fabbione> the orig diff.gz and dsc for 2.6.11.94 are in the usual place
<zul> 686-dbg is only 147M
<zul> :)
<zul> i think i fixed my puter freezing
<zul> disable xscreensaver
<fabbione> oh 
<zul> night...my wife starts to have panic attacks if she wakes up and im not there
<fabbione> good night zul
* lamont grumbles at fabbione for bumping the linux-source-2.6.12 build-desp
<lamont> build-deps even
<lamont> .94 is -rc6?
<fabbione> hey lamont
<fabbione> yes it's rc6
<lamont> ok
<lamont> I should have an hppa merge sometime this week, I expect
<fabbione> lamont: i had to bump build-deps
<fabbione> i know i could have make them more arch specific
<fabbione> but it's a royal pain :)
<lamont> heh
<lamont> part of it is not knowing _why_ they were reved... but I expect that's just a matter of reading the changelog better...
<fabbione> lamont: ppc64 mostlikely
<fabbione> i am pretty sure i wrote it in the changelog
<lamont> cool
<fabbione>     - Bump build-dep on gcc-3.4 (>= 3.4.4-0ubuntu4) and kernel-package
<fabbione>       (>= 8.135ubuntu2)for ppc biarch support.
* lamont is heading to bed anyway
<lamont> Total 1711 package(s) in state Installed.
* lamont cheers hppa along
<fabbione> suckage
<fabbione> i am eons behind that
<fabbione> because i am too lazy to check the C++ transition status
<lamont> well, there's something like 4400 needs-build
<lamont> 4467
<fabbione> i have around 3000 needs-build i guess
<lamont> anyway, g'night
<fabbione> i will need to hunt down doko to check the C++ transition with me
<fabbione> good night 
<fabbione> cya later
<fabbione> mjg59: around?
<mjg59> fabbione: Hi
<fabbione> hey mjg59 
<fabbione> some bits of the big fat acpi patch are upstream
<fabbione> i did a rediff with 12rc6
<mjg59> Oh, urgh
<mjg59> Thanks
<fabbione> but i hope i got all of them
<fabbione> it builds.. so it's ready for warty ;)
<mjg59> Haha
<zul> heylo
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> i have rc6 almost ready to hit the archive :)
<fabbione> waiting for ppc to finish to build
<zul> it didnt segfault?
<fabbione> oh yeah several times
<zul> heh
<fabbione> but it seems to be a problem on the porting box rather than the software
<fabbione> on the buildd it just work 99% of the time
<zul> well thats good then :)
<fabbione> zul: 11602
<fabbione> want to take a look?
<zul> sire
<mdke> hi all. is it safe to say that https://bugzilla.ubuntu.com/show_bug.cgi?id=10512 is a kernel issue? would it be alright to change package:UNKNOWN to "linux"?
<fabbione> mdke: you should ask mjg59
<fabbione> i am not sure that stuff is X or kernel related
<fabbione> specially given the fact that it works -> play DVD -> doesn't work
<mdke> fabbione, i'm pretty sure that's unrelated
<mdke> it was probably a kernel update that the reporter didn't notice
<mdke> i talked to mjg59 about the bug the other day, he wasn't sure
<fabbione> neither am i
<mdke> i'll test more
<mdke> i'll do a default hoary install on it today
<fabbione> try with different kernels
<fabbione> using exactly the same userland
<fabbione> that will shed light
<mdke> fabbione, ok basically I can spend today testing with a new hoary install. What kernels do you want me to test?
<fabbione> 2.6.8.1 from warty 2.6.10 from hoary and 2.6.12 from breezy
<fabbione> skip 2.6.11
<mdke> ok
<fabbione> if you keep the same userland aka: no binary drivers, same version of Xorg and so on
<mdke> right
<fabbione> you will be able to isolate the problem
<mdke> i'm pretty sure its not X related, the problem occurs before X starts too
<mdke> but i will test properly and post
<mdke> thanks
<mdke> *grins* ok I can already say that its not working properly with the hoary install kernel
<fabbione> mdke: well.. welcome to provide us a patch with the fix :)
<mdke> :-(
<mdke> fabbione, i can't fix it :(
<fabbione> tought luck
<mdke> you guys won't fix it?
<mdke> i'll try and help by testing and reporting on the bug report
<fabbione> mdke: if there is no patch from upstream... no
<fabbione> also hoary won't get that kind of fixes
<fabbione> so just hope that it works with 2.6.12
<mdke> aw merda
<fabbione> that sounds like italian shit
<mdke> i've had some many problems with this laptop and linux
<mdke> some/so
<mdke> it worked perfectly in the days of 2.6.7
<mdke> fabbione, so i should point that bug upstream? where can i report it?
<fabbione> mdke: i dunno who is responsible for hotkeys stuff
<fabbione> really ask mjg59 is your best bet
<fabbione> also.. did you try 2.6.12?
<mdke> not yet, still installing hoary right now
<mdke> i wonder if it is just a hotkeys issue
<fabbione> it mostlikely is
<mdke> the laptop makes some quite strange buzzing noises after being switched to ac power, and the screen brightness doesn't drop/raise when AC is disconnected/connected
<fabbione> ok add all the info to the bug. it's probably acpi that is broken
<fabbione> or your bios
<mdke> I thought it was a hardware problem until I installed windows the other day, and it worked perfectly
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,1--2.6.11.94
<fabbione> (playground will be available in a couple of minutes)
<zul> fabbione: for the usb bug he says it works with the 386 kernel
<fabbione> eh
<fabbione> SMP problem?
<fabbione> if so... that's so out of my hand :)
<zul> but he is connecting the 1.1 devices to 2.0 ports
<zul> yeah
<fabbione> well usb doesn't really have 1.1 or 2.0 ports
<zul> and he is checking for bios update as well
<fabbione> they share the same phys port given the controller behind deciding the protocol
<fabbione> ook 2.6.11.94-1.1 is up
<fabbione> it builds everywhere
<fabbione> i am off for the day
<fabbione> KTHXBYE
<zul> c ya
<mdke> fabbione, am downloading some kernels to try. I've downloaded linux-image-2.6.8.1-3-686_2.6.8.1-16 from archive.ubuntu.com, is that right? where can I get the breezy one?
<fabbione> mdke: same place.. just a dir up
<dilinger> oh
<dilinger> jbailey: ping
<mdke> fabbione, i'm at ubuntu/pool/main/l/, I can only see linux-source 2.6.10 and 2.6.8.1
<jbailey> dilinger: pong
<dilinger> did you see the ide device driver model merge in rc6?
<dilinger> commit 8604affde9d4f52f04342d6a37c77d95fa167e7a
<jbailey> dilinger: I did. =) 
<jbailey> Fabio's working on those right now, I think.
<dilinger> cool
<jbailey> I'm wondering what I'll have to change in the hotplug autodetection before people suddenly find themselves unable to use their CDroms and such. =)
<jbailey> dilinger: BTW, I saw in #u-d that you were reading my testsuite stuff in cdbs?  Did you have any comments on it?
<jbailey> dilinger: I'd like to push a few more tests into there in the next couple of days (the old tests, plus some multipass stuff)
<mdke> can anyone help me out in finding the breezy kernel? i'm looking for a url. sorry...
<dilinger> jbailey: i need to look closer at it
<dilinger> i was just skimming through
<jbailey> mdke: Finding?  Err..  What are you trying to do? =)
<jbailey> dilinger: Ah, no worries then.
<mdke> jbailey, download it and install it on my hoary system to test something
<fabbione> mdke: 2.6.12 is in universe
<mdke> ahhh
<mdke> thanks!
<jbailey> mdke: Careful when pulling random bits down.  A newer initrd-tools against a breezy glibc causes unbootable systems.
<fabbione> dilinger: i already uploaded rc6
<mdke> jbailey, ok thanks for the heads up
<jbailey> mdke: Err, against a hoary glibc.
<jbailey> mdke: *isgh* I'm on crack.  hoary initrd-tools against a breezy glibc.
<mdke> *grins*
<mdke> a bet crack is necessary in your line of work
<mdke> a/i
<mdke> jbailey, thanks tho I will try and see
<jbailey> It's a fringe benefit. =)
<mdke> jbailey, i am just gonna test all the kernels I find
<mdke> will I need to install a newer initrd-tools on hoary to test the 2.6.12 kernel, or should I force install it and try without? 
<zul> fabbione: its an smp issue for the usb buglet
<zul> hehehe...http://cnews.canoe.ca/CNEWS/WeirdNews/2005/06/07/1075697-ap.html
<jbailey> mdke: I don't recall any new features in the initrd that are important.  Let the depends line guide you, though.
<mdke> hmm
<mdke> if I install a new initrd on hoary will the old kernels boot?
<jbailey> initrd's are specific to the kernels.
<jbailey> Just don't delete the old ones. =)
<mdke> ok cool
<mdke> jbailey, thanks!
<mdke> fabbione, ok i have clarified https://bugzilla.ubuntu.com/show_bug.cgi?id=10512 a bit more, thanks for your help
<mjg59> Do we ship the zd1211 driver?
<mjg59> Hngh. Sourceforge is being *very* slow
<zul> mjg59: is that a wireless card?
<zul> sourceforge sucking huge today
<mjg59> Yeah, USB 11g thing
<zul> nope we dont
<mjg59> Seems to be GPLed, might be worth sticking in
<mjg59> Buils with kbuild
<zul> cool..send me a url and ill add it..
<mjg59> http://heanet.dl.sourceforge.net/sourceforge/zd1211/sf_zd1211_20050315_src.tar.gz
<zul> got it
<zul> will make a patch for it tonight...need to start cleaning the house
<chmj> hello 
<chmj> do we have a 2.4 kernel for ubuntu ? 
<fabbione> no
<fabbione> and breezy cannot run on 2.4
* fabbione -> food
<chmj> can hoary ?
* chmj *gasp*
<jbailey> No
<jbailey> There are no ubuntu release that support 2.4
<infinity> ...
<infinity> Support, or "support"?
<infinity> If you have a glibc with LinuxThreads, you can run 2.4...
<infinity> (modutils helps too, if you happen to like modules, and it's always been there)
<jbailey> infinity: Well, that assumes that anything that is now looking at /sys and such still has all the fallbacks.
<snow> anyone alive?
<snow>  one question guys. i try to inst 5.10 but the f. machine (intel) says its not able to mount a filesys ext2 (or ext3) on /dev/ide/host0/bus0/target0/lun0/disc1 - i have tried lots of things
<zul> i think you might want to try #ubuntu
<snow> have done that several times, no help found - do you have an idea?
<zul> snow: this not between #ubuntu-devel and #ubuntu, this is a kernel development channel
<snow> sorry guys, you may be the only one whos able to help... should i instead resign?
<fabbione> snow: 5.10 is not even released
<fabbione> install 5.04
<zul> oh hey fabbione :)
<snow> i know o know, but i want breezy!! i will help reporting bugs
<snow> 5.04 is working very good
<fabbione> snow: the error you see is installer related. not kernel
<fabbione> snow: install 5.04 and upgrade if you want to run breezy
<snow> ok
<snow> thanks
* dilinger laughs
<zul> thats not nice :)
<zul> fabbione: wtf is a mungbean?
<dilinger> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be
<dilinger> ubuntu can start shipping tg3, now
* ..[topic/#ubuntu-kernel:zul] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,2--2.6.11.94
<jbailey> dilinger: Eh? =)
<jbailey> dilinger: Admitting that the firmware is stolen makes it distributable? =)
<dilinger> ?
<dilinger> broadcom owns the copyright
<dilinger> they've given us a license that allows redistribution
<jbailey> Oh, I see. =)
<jbailey> I was looking at it as "YEs, Broadcom owns this.  We stole it.  Give it away!"
<dilinger> http://lists.debian.org/debian-kernel/2005/06/msg00146.html
<dilinger> and other related threads on d-k
<jbailey> Cool.
<jbailey> I Was lucky all my tg3 boxes were happy even without firmware./
#ubuntu-kernel 2005-06-16
<zul> evening
<fabbione> morning
<dilinger> you're on time today
<dilinger> well, maybe a few minutes early
<fabbione> ehhe
<Mithrandir> jbailey: are you talking with maximilian attems about initramfs and klibc and he packaging it for Debian?
<jbailey> Mithrandir: Yes.
<jbailey> Mithrandir: I've found that so far I worked best with contrib'ing back to Debian when I have someone in Debian I can work with.
<jbailey> Since I don't really follow the lists and stuff, then I can hand patches back and forth and discuss rather than have to keep Ubuntu and Debian branches possibly separate in my head.
<jbailey> Mmm..  'Failed to create initrd image' with 94-1.1,  Expected?
<fabbione> from archive?
<Mithrandir> jbailey: ok, makes sense.
<fabbione> jbailey: i just installed the i386 kernels with no problems here
<fabbione> are you sure you didn't hack around /etc/kernel-img.conf ?
<fabbione> and forgot to revert the changes?
<chmj> fabbione: bluetooth module are included in the ubuntu kernel, yes? 
<fabbione> chmj: yes
<chmj> sweet, thanx 
<zul> mornin
<fabbione> hey zul
<fabbione> zul is up
<fabbione> it's time to stop for me :)
<fabbione> cya later fellas
<jbailey> Wow.
<jbailey> Fabio's stopping on time.
* jbailey checks for the apocalypse.
<fabbione> jbailey: quote that to Matt and Mark! :P
<jbailey> Dear Slave Drivers, Fabio is clearly slacking off and is scaring me in the process.  Please fix. kthxbye.
<fabbione> ahha
<zul> the only who is allowed to slack off is me
<fabbione> Happy Cracking Tool
<fabbione> ops
<zul> this isnt good..
<zul> arch-ppc-platforms-pmac-cpufreq_update-cpufreq-table.dpatch.failed
<zul> crap...never mind
<zul> mmmm...devo
<zul> *sigh* my wife doesnt know who devo is
<mjg59> zul: If it makes her feel any better, nor do I
<zul> aieeeeeeee
<zul> you young;uns
<zul> http://www.vh1.com/artists/az/devo/artist.jhtml
<dilinger> whip it good
<zul> exactly!
<zul> oh fuck...fabbione!!!
<dilinger> hah
<dilinger>  and the sessions for 1982's Oh, No! It's Devo were marred by an ill-considered attempt to use poetry written by would-be Ronald Reagan assassin John Hinckley, Jr. as lyrical material.
<zul> brb...need to reboot
<zul> well that was interesting..
<zul> somehow the dbg-kernel is booting first in grub..
<infinity> How can anyone not know who Devo is?
<infinity> Weird.
<zul> of course she could be saying that just to get me to shut up
<jbailey> fabbione: Don't mind me.  I forgot that the preinst doesn't actually fail.  I had ramdisk = foo set in my kernel-img.conf =)
<jbailey> infinity: Maybe it's a west coast thing?
<jbailey> I live in a jar, and I know who devo is.
<infinity> Word.
* jbailey grooves to DIDO
<zul> bleah..
<zul> almost as bad as aqua..
<jbailey> aqua has better music videos. =)
<zul> oh my god you suck :)
<infinity> jbailey has questionable tases in music.
<infinity> tastes, too.
<jbailey> I could put on slayer, but I find it hard to hack to.
<zul> jello biafra
* dilinger shakes jbailey's jar and watches his reaction
* jbailey pukes.
<dilinger> neat
<Seveas> rammstein is good hack music :)
<zul> system of a down is better
<zul> oh lovely kernel-package is broken again
* dilinger prefers jazz or techno
* zul prefers punk or heavy metal
<dilinger> punk works, as long as the lyrics are unintelligible or the songs are lyrically simple (i've found Me First And The Gimme Gimme's to be great hacking music)
<zul> dropkick murphies usually do it for me, their old stuff not the new stuff
<zul> or iorn maiden
<jbailey> dilinger: I'm not awake enough in the mornings to do techno.  Nice for the afternoon though.
<jbailey> Mronings are usually softer music.
<jbailey> I also find that answering support requests is best not done to high-adreniline anger music. =)
<dilinger> hehe
<zul> been there done that :)
<zul> fabbione: ping...kernel-package is broken me thinks
<fabbione> zul: no it's not
<fabbione> kernel-package is fine
<fabbione> if you are using the latest version :)
<fabbione> the one that has a "cosmetic fix" :)
<zul> http://zulinux.homelinux.net/linux-source-2.6.12_2.6.11.94-1.2_i386.build
<zul> updated this morning
<fabbione>  couldn't open log `/var/log/dpkg.log': Permission denied
<fabbione> that's mostlikely something else that is broken
<fabbione> probably dpkg
<zul> bah..
<fabbione> i am off.. gotta cook dinner
<fabbione> cya later
<zul> c ya
<Micksa> why have I no /usr/include/linux/net?
<Micksa> I can't compile uml cos it's looking for linux/net/mcast.h (for the host)
<lamont__> Micksa: and you have linux-kernel-headers installed?
<lamont__> hrm... mcast.h isn't there..
<lamont__> there's already a -1.2?
<jbailey> dilinger: Interesting - ash and busybox don't support posix shell arrays. =(
<dilinger> jbailey: kill them
<jbailey> The shells or the the arrays?
<dilinger> the shells, of course :)
<jbailey> Well, I might be willing to fix busybox.
<jbailey> I'd prefer just to see ash go away.
<Mithrandir> to be replaced with posh? :P
<jbailey> It's probably the best choice for klibc.
#ubuntu-kernel 2005-06-17
<lamont__> infinity: you awake yet?
<lamont> infinity: ???
<infinity> lamont : Am no.
<infinity> s/no/now/
<lamont> what were you calling a 'lamont bug' yesterday?
<lamont> well, your last night, I guess
<infinity> Oh, just a cute feature of the auto-dep-waiter.
<lamont> which one is that?
<infinity> Ifa build fails for any reason whatsoever, and it happened to build-dep on a virtual package, it'll get dep-waited on the virtual.
<infinity> Anyhow, fixed on sanae.
<lamont> and in baz?
<infinity> I need to publish my branch somewhere, I guess.  I'm still an arch/baz virgin. :)
* lamont will update his branch
<infinity> I just split "templates" into two arrays, one array that's an unconditional "you can take action on these regexps", and one that's "these only matter if we never got to a dpkg-source/dpkg-buildpackage run".
* lamont notes the introduction of the 3 stooges.  woot!
<infinity> The above caseis now in the latter.
<infinity> Hey, you had mo. :)
<infinity> The debate between larry, curly or shemp was fierce, I'll tell ya.
<lamont> yeah, but that wasn't where I got him from. :0)
* lamont mirrors the archive
<lamont> btw, new buildd-conf coming soon, etc.
<infinity> Would it make more sense to add me to the log mails, or to change it to a list?
<infinity> I guess I'd have to bug someone for a list then, so probably easier just to add me. :)
<infinity> (The list sounds like less of a headache if buildd admins come and go down the road, though)
<lamont> yeah - go ahead and add yourself and I'll fetch the changes and push again
<lamont> yeah - but the whole thing goes *poof* come launchpad production
<infinity> lamont+warty... Does that auto-expand to lamont@, or is that a .forward-hack, like debian's user-extension@?
<lamont> + is the recipient delimiter - debian uses -
<infinity> So how does one forward that to another address? :)
<lamont> so lamont+warty gets delivered by postfix to 'lamont', with an arg of warty.  Likewise, .forward+warty will forward just 'lamont+warty'
<infinity> (Not that I care)
<lamont> in my case, it comes in as $ARG to procmail
<infinity> Right.  Where do the .forward files live, perhaps is what I wanted to know. :)
<lamont> to forward it, you could create .forward+warty
<lamont>  postconf forward_path
<lamont> forward_path = $home/.forward${recipient_delimiter}${extension}, $home/.forward
<infinity> (ie: With debian, they're on master)
<lamont> oh - for canonical.com/ubuntu.com?
<infinity> Aye.
<lamont> they live where ever user@foo.com gets directed to
<infinity> fiordland?
<infinity> A host I can't log into. Yay.
<lamont> that is, if you send mail to 'foo+bar@host' and 'foo+bar' isn't in the alias file, but 'foo' is, and rewrites 'foo' to 'baz@other.dom.ain', then postfix delivers the mail to 'baz+bar@other.dom.ain'
<lamont> no.  not on fiordland
<lamont> in my case, the expansion happens on a mmjgroup.com host
<lamont> and fiordland says 'lamont@ubuntu.com lamont@mmjgroup.com'
<lamont> in virtual, truth be told
<infinity> Oh, wherever it gets redirected to, you meant.
<lamont> yeah
<infinity> I was expecting to do the expansion on a canonical host.
<infinity> Silly me.
<lamont> although you _can_ add a specific entry to the map, and redirect 'foo+bar' somewhere different than 'foo'
<Micksa> yes I did have linux-kernel-headers installed :)
<lamont> but canonical/ubuntu do not do that, to the best of my knowledege.
<lamont> Micksa: yeah - I saw that when I did a little digging..
<infinity> No big deal anyway, this was all purely academic.
<lamont> infinity: np
<infinity> Hrm, will warty-mail.py -t 'foo@bar.com,baz@quux.com' work?
* infinity takes that as a "maybe".
<lamont> hrm  second
<lamont> -t foo@bar.com -t baz@baz.org
<lamont> and on that note, I'm gonna wander off for a bit... don't break everything, k?
<lamont> (sorry - was distracted..)
* infinity breaks everything.
* lamont looked - it had appeared that you chickened out. :-)
<dilinger> infinity: i'm going to kindly request that you call your first php5 upload the infinity-breaks-everything release
<infinity> Meh.  My first php5 upload should be in the next week.  But I need to sucker someone into packaging all that PEAR crap.
<infinity> Also, this is hideously off-toping stuff in -kernel.
<infinity> fabbione will be so pleased when he shows up.
<dilinger> infinity breaks everything is relevant everywhere :p
<infinity> off-toping?... Also, off-topic.
<infinity> I have this odd feeling I'm going to be stuck doing the PEAR stuff.
<infinity> Which makes me want to KILL.
<infinity> But it's the only way php5 (or even php4 4.3.11) will ever get uploade.
<infinity> d
<dilinger> i'd offer to do it, except.. i won't.
<dilinger> :)
<dilinger> the closest i get to php at work is running an instance of squirrelmail
<dilinger> it's great
<fabbione> morning
<infinity> squirrel is the most PHP I see in a day too. :)
<fabbione> PHP should die
<fabbione> i might as well write a change in the kernel to not allow any php binary to start
<dilinger> hehe
<fabbione> lamont: ping?
<lamont> fabbione: ack
<ashaak> hi
<lamont_r> fabbione: you awake?
<lamont_r> fabbione: do we have ip6tables conn tracking support yet?
#ubuntu-kernel 2005-06-18
<_rick> hoi
* Micksa pokes mjg59
<mjg59> Hello
<Micksa> hi
<Micksa> okay, so the story so far with STR on my laptop is
<Micksa> stuff seems to mostly work okay, except the graphics card :)
<Micksa> on resume the PCI config is trashed
<Micksa> and "vbetool post" doesn't do a thing
<Micksa> so
<Micksa> could that be a BIOS related thing at all?
<Micksa> could it be related to the fact that it's on a PCIe port?
<mjg59> PCI config won't be restored because there's no PCI driver bound to it
<mjg59> If it's PCIe, then the issue is probably that the kernel doesn't currently resume PCIe bridges properly
<mjg59> There's a patch on acpi-devel - hang on a moment...
<Micksa> oooh
<mjg59> http://www.codon.org.uk/~mjg59/tmp/pcie.diff
<Micksa> oh, but! Mark Lord has an inspiron 9300, which *seems* to be almost identical to a 6000, and his patches, which get STR working for him, don't fix this problem for me
<Micksa> um, I'll get back to you :)
<_rick> i have problem to compile the kernel with dpkg-buildpackage
<Micksa> hmm, that patch applied.
<Micksa> on top of his patches I mean.
<mjg59> His patches are just for SATA, aren't they?
<Micksa> nono, not just the patch you told me about
<Micksa> sorry, forgot they were the same person :)
<mjg59> So you get working resume but no working video at the moment, right?
<mjg59> That's a touch more miserable to fix
<Micksa> yeah
<Micksa> but at least I can poke the machine via the network after resume. that sure helps.
<Micksa> ml has a page at http://rtr.ca/dell_i9300/ which goes into great detail about how to get the i9300 to work with linux
<Micksa> and it links to a patch which covers...
<Micksa> well, sata and the touch pad :)
<Micksa> I'm not actually sure if we have exactly the same PCIe bridge
<Micksa> how do you get lspci to accept output from "lspci -vvx" as input?
<mjg59> You can't
<mjg59> You need to use setpci
<mjg59> But the easiest thing to do is to use /sys/bus/pci/devices/foo/config
<mjg59> You can cat that out before suspend and back after resume
<Micksa> nono, I thought you could pass the output of "lspci -vvx" to the input of a "lspci -F"
<Micksa> to get numeric PCI ids, for example
<Micksa> (not that ml gave me the right format anyway :) )
<mjg59> Oh, right
<mjg59> No idea, I'm afraid :)
<Micksa> bah
<Micksa> what kind of support channel is this
<Mithrandir> it's not a support channel.
<Mithrandir> it's a development channel
<Mithrandir> (says so in the topic)
<jbailey> lamont: Hey, how much do you know about crazy ia64 things? =)
<swarm> I have found that kernel for amd64-k8 coming with Ubuntu Hoary 5.04 isn't compiled for preemption. That could be the reason for input devices loss of interactivity during heavy /dev/hda I/O activities?
<jbailey> swarm: Sure.  Or your dma could be disabled on the harddrive.
<swarm> jbailey: it's set to udma5
<jbailey> Compiling a kernel with preemtion is still not considered the Right Thing for distro kernels.
<lamont> jbailey: very little, truth be told.
<jbailey> lamont: Ah, 'kay.
<lamont> jbailey: but it's on my list to be come a guru of such things, I fear
<jbailey> lamont: I came up with the idea that Xen on ia64 might be able to run an i386 kernel.
<swarm> jbayley: is it available any kernel running on amd athlon 64 with preemption enabled provided by Ubuntu team?
<jbailey> swarm: No
* lamont snaps his head around to stare at jbailey in horror
<jbailey> lamont: I haven't told you the truly horrific part yet. =)
<jbailey> I want to part the Hurd to Xen. =)
<lamont> jbailey: the horror is that there's a chance it could work
<lamont> that's part the Hurd _with_ Xen. :-)
<jbailey> Right, same thing really. =)
<swarm> perhaps it's the wrong place but I ask here... do you know if sun jre/jdk >= 1.4.2 amd64 release run on Ubuntu Hoary amd64?
<jbailey> Right, it's the wrong place. =)  Please try in #ubuntu.
<swarm> I tried yesterday and before.. On #debian-amd64 said that it's normal having that Sun things run on debian amd64. Thanks for the info about kernel
<lamont> jbailey: does that mean yopu
<jbailey> lamont: I've been looking for little kernel and compiler projects that will allow me to learn stuff in my spare time without having someone else run me over on it.  I suspect this might be an amusing one that noone else would be actively trying to make work right now. =)
<lamont> you're going to make Xen work with NPTL?
<lamont> jbailey: well, _THAT's_ for certain. :0)
<lamont>  /topic jbailey's interest in the Hurd finally explained
<jbailey> lamont: It looks like it might now.  I was reading a mailing list and talking with some folks on #xen, and it looks like they can emulate what they need now at a huge penalty, or you can do a custom glibc that uses a few line patch to do TLS accesses differently.
<lamont> is there anyway to make that patch part of the standard glibc, I wonder?
<jbailey> lamont: What might be interesting is to see if it's possible to get Xen'ness exposed as an HWCAP and then just build an extra pass onto glibc with that patch.
<lamont> sounds reasonable
<jbailey> Unlikely.  I don't know all of what happens with the patch, but it looks like it doesn't use %gs:# to access the thread stuff anymore, but calculates it.
<lamont> ah, blech
<jbailey> lamont: If I do take this on, would you mind the occasional ia64 question?  You know, like "Is it true the last twinky^Witarnium rolled off the assembly line in 1970 and they're just selling the stock now?"
<lamont> eep.  must take daughter to girlscouts
<lamont> bbl
<jbailey> c'ya
<lamont> jbailey: you can ask whatever you like (literally).  I reserve the right to not answer. :-)
<lamont> and yes, I have stopped beating my wife.
<jbailey> Err.
<jbailey> Why?
<jbailey> (That's question #1)
<lamont> I let her win now.
<jbailey> =)
* lamont runs to get ready
<swarm> Using headers of current kernel image got with Ubuntu Hoary, config from /proc/config.gz, I should be able to modify kernel config only for preemption with easy, right?
<jbailey> I guess so, dunno.
<jbailey> I don't build my own kernels.
<jbailey> lamont: w-b question for you.  Does it respect the Architecture field, or does it hand everything to everyone?
<lamont> w-b respects Packages-arch-specific.  It cares not one wit about Architecture:
<lamont> dpkg/debhelper will fail the build based on Architecture: though
<swarm> jbailey: solved input devices latency problem related to kernel preemption disabled.
<swarm> I'm using kernel 2.6.11 amd64-k8 smp from Ubuntu. CONFIG_PREEMPT is not set while, of course, CONFIG_SMP=y. My pc has 1 CPU. Now there is no latency and it's very usable. Why?
#ubuntu-kernel 2005-06-19
<Micksa> mjg59: I HAVE STR!
* Micksa goes and announces it on other IRC channels
<Micksa> I'm so happy
<Micksa> has anyone suggested having ubuntu set "echo 10 >/proc/sys/vm/swappiness" on startup?
<fabbione> morning
<fabbione> Micksa: and what would be the benefit to have that setup?
<crimsun> it'd be fairly dubious to make such a change without extensive testing
<fabbione> i am not going to anyway
<fabbione> but i would like to know the possible benefit of it
<Micksa> general idea is it "improves desktop response"
<fabbione> lamont: no we still don't have ipv6 stateful support
<fabbione> Micksa: the general idea without specific data out of benchmarks are only subjective feelings ala gentoo
<Micksa> I *think* it's the max percent of memory free before the kernel starts preemptively swapping stuff out
<fabbione> "hey i compiled my kernel with -O31337 and everything crashes as twice as fast!"
<Micksa> example: setting it to a lower value means if you copy a gig of files it won't swap all your apps out in the process
<Micksa> what kind of testing? stableness or performance?
<fabbione> Micksa: what is your default value?
<fabbione> not the one you set.. the one that's there after a fresh boot
<Micksa> well the default is 60 (it's 1-100) but I've set mine to 10 to see how it goes
<fabbione> how much ram do you have on your system?
<Micksa> 1G
<Micksa> on this one
<fabbione> same here
<crimsun> [http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/1937.html for an earlier thread] 
<fabbione> on the others?
<Micksa> so like, I don't think it makes so much difference for me :)
<fabbione> i am curious to know if it is calculate at boot time
<Micksa> the only other machine I have running 2.6 at the moment has 512M, but I don't have it in linux anyway
<Micksa> I think it's just set at 60
<Micksa> I think it's a percentage
<Micksa> I don't know for sure
<Micksa> all I know is that it's in a range of 0-100, and a higher value gives more preference to cache, less to apps
<Micksa> we could argue forever about where it should be set 8)
<Micksa> google for it if you don't believe me
<fabbione> Micksa: dude.. i didn't say i don't believe
<crimsun> the higher the value, the more likely the kernel will swap out an app instead of reclaiming from cache
<fabbione> i said i want to see numbers
<Micksa> I just thought I'd mention it.  It can at least improve *percieved* performance in certain situations
<fabbione> and already the first page of crimsun thread would give you a perfect idea on why you shouldn't touch it
<fabbione> "For example, at a swappiness value of 0, Kernel 2.6.5 swapped out 0 bytes,
<fabbione> whereas Kernel 2.6.9-rc1-mm3 swapped out 10 GB."
<Micksa> heh, ah, well :)
<fabbione> since it's not a consistent value across kernels
<fabbione> i think the default will be fine for everybody
<fabbione> given that the benchmarks says that 60 is where the best interaction is at the moment
<Micksa> BUT IT WILL MAKE EVERYTHING BETTER
<Micksa> :)
<fabbione> probably.. on desktop.. what about servers?
<Micksa> it's probably best left at 60ish for servers
<fabbione> and how do you expect to detect a server install from a desktop one?
<crimsun> another reason to leave it alone: http://bugs.gentoo.org/show_bug.cgi?id=54560
<Micksa> I dunno, I thought you guys had that covered :)
<crimsun> I think we all recognize the name greg k-h
<fabbione> Micksa: there is no way to distinguish installations
<Micksa> damn.
<Micksa> wouldn't it be nice if 2.6 got stable
<Micksa> mmm, google searchable irc logs :)
<Micksa> argh dammit, it's not in here
<Micksa> oh these are yours! :)
<Micksa> dammit. could you grep for a http:// from mjg59 around 7 days ago?...
<Micksa> he pointed me at a patch which I've since lost
<fabbione> http://people.ubuntu.com/~fabbione/irclogs/ <- kthxbye
<Micksa> FINE!
* Micksa starts wget -r
<fabbione> Micksa: it's several MB :)
<Micksa> *fuming* I know....
<fabbione> and a wget -r will parse the .html
<fabbione> so basically you will endup downloading the internet :)
<Micksa> wget -r -np. whatever.
<Micksa> anyway I've found it
<Micksa> you coulda just grepped for me and it would have saved us all this ;)
<Micksa> but, I guess you had fun
<fabbione> Micksa: probably you miss a point
<fabbione> it's sunday... it's weekend.. i am not even going to ssh to people to grep :)
<Micksa> I sure am a whiny bitch huh
<fabbione> that too :)
<fabbione> and it doesn't make you gaining any point in here
<Micksa> that's not fair
<Micksa> this is me!
<Micksa> well sorta.
<fabbione> whining doesn't make you gain point
<Micksa> I just like to play the whiny bitch every now and then for fun
<fabbione> indipendently who you are :)
<Micksa> I have to hold myself back if I'm not considered a regular.
<Micksa> It's no fun.
<fabbione> Micksa: you can have fun without being a bitch :)
<fabbione> but clearly that depends on the kind of fun you like
<fabbione> "slap me! i am your bitch!" <- we do NOT need/want to know :P
<Micksa> >:)
<Micksa> I tend to be the one doing the slapping
<Micksa> which of course helps to increase my popularity
<Micksa> gotta go, back laterish
<Micksa> boing boing boing
<fabbione> Mithrandir, smurfix: ping?
<fabbione> Linux trider-g7 2.4.30-xen0 #4 Sun Jun 12 10:56:56 CEST 2005 i686 GNU/Linux
<fabbione> :)
<Mithrandir> fabbione: yaypong. :-)
<fabbione> Mithrandir: did you finish with Uni?
<Mithrandir> yeah, handed in my thesis friday.  So I'm freeeeeeeeeeee now
<fabbione> ahah cool!
<Mithrandir> that's a 2.4 kernel, though?
<fabbione> yes
<fabbione> i can't run 2.6 on that box yet
<Mithrandir> oh, ok.
<Mithrandir> anyhow, you got this stuff in arch?
<fabbione> uh?
<fabbione> i am just using upstream
<fabbione> manual patch /build
<Mithrandir> ok
<fabbione> but there is an issue building the xenU kernel
<fabbione> so i need to see if i can boot a subdomain with the domain0 kernel
<fabbione> in theory is the same
<Mithrandir> what's the problem building the xenU kernel?
<fabbione> it's an unreferenced call to something
<fabbione> linking error basically
<Mithrandir> hm
<fabbione> arch/xen/drivers/netif/drv.o(.text+0x37ec): In function `netif_connect':
<fabbione> : undefined reference to `direct_remap_area_pages'
<fabbione> so i need to understand why is missing
<fabbione> probably i just miscompiled it
<fabbione> i forgot that 2.4 is a bit behind with kbuild
<fabbione> hmm no
<fabbione> nothing to do with compilation
<fabbione> crap
<fabbione> ah hmmm
<fabbione> stupi config error i think
<fabbione> ah there it is :)
<fabbione> fixed
<fabbione> ok perfect...
<fabbione> xenU boots :)
<fabbione> Mithrandir: whatever xen config you are going to do.. remember to disable devfs :)
<Mithrandir> heh, ok.
<Mithrandir> hmf.  Sourcepuller doesn't work with bkbits, apparently.
<Mithrandir> fabbione: you've just pulled the regular stable xen version rather than messing with bk, right?
(fabbione/#ubuntu-kernel) freenode should die
<Mithrandir> we could start by switching to another network ourselves. :-P
<fabbione> actually that's an idea
<Micksa> okay, so I'm trying to compile a patched kernel
<Micksa> using the linux-source package works, except firmware doesn't get compiled in
<Micksa> so like, how should I compile from the *real* source for just the one subarch?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<mjg59> Micksa: Cool. What did you add?
<Micksa> hi
<Micksa> the pcie patch you pointed me at fixed the graphics problem
<mjg59> Cool
<mjg59> Can you feed that to fabbione?
<Micksa> now I just have to put it all together
<Micksa> haha
<Micksa> no
<Micksa> he hates me
<Micksa> *chuckles*
<Micksa> what does he need, just an email saying "these patches fix these problems with the i6000"?
<mjg59> Yeah, but he won't apply the SATA one yet
<fabbione> no because upstream said that the patch is broken
<fabbione> also is this pcie patch upstream already?
<Micksa> *shrug*
<mjg59> I don't believe so, no
<mjg59> It only appeared last week
<fabbione> mjg59: so let's wait before we start pulling too many patches from different places
<fabbione> i would like to get to 2.6.12 final first
<mjg59> fabbione: I'd prefer to have a kernel that we can actually expect to work on laptops
<mjg59> We've no idea how long 2.6.12 final is going to be, but we *need* a kernel that can be used for laptop testing
<fabbione> mjg59: .12 should be out pretty soon according to linus
<fabbione> mjg59: with this "pull in all patches from everywhere" we fucked up hoary badly
<fabbione> specially for 2 SATA controllers
<fabbione> thanks god they are not used in the installer
<Micksa> does it fry them? 8)
<fabbione> and we will need to do soon a point release
<fabbione> so for breezy we are going to be a bit more careful
<fabbione> i trust your acpi crack
<fabbione> but i don't want to end up like hoary
<fabbione> Micksa: data loss
<Micksa> aw, that's no fun
<mjg59> fabbione: How soon is "pretty soon"?
<fabbione> mjg59: max a week
<mjg59> We need to start this stuff within the next couple of weeks
<mjg59> Ok, cool
<fabbione> mjg59: .12 is not even in main
<fabbione> so you can start whenever you want
<mjg59> Uhm
<fabbione> push the crack to people
<Micksa> it's really cool seeing an announcement from _A_ saying "don't use kernel x if you have device y, it'll fry it. no, really."
<fabbione> and have fun :)
<mjg59> I can't ask people to build their own kernels from scratch. They're not all going to be competent to
<Micksa> haha
<Micksa> what about a laptop-test kernel?
<mjg59> Yeah, that might be an idea
<fabbione> mjg59: if you prefer to handle your own kernel for testing go ahead
<Micksa> "this kernel might make your laptop work. also, it might cause it to explode."
<Micksa> "we don't know."
<fabbione> right now i am not too happy to push more than required
<mjg59> Ok, fair enough
<fabbione> specially because there is still hell of a lot of work to do to move .12 in main
<fabbione> mjg59: anyway.. it's sunday and we are talking about work
<Micksa> heh
<fabbione> me not happy very much work weekend
<Micksa> just hit monday here :)
<mjg59> Heh
<fabbione> mjg59: let's talk about it tomorrow
<mjg59> Yup, that's no problem
<zul> heylo
<zul> oi...its so freaking hot
* #ubuntu-kernel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
<zul> hey fabbione
<fabbione> hey zul
<fabbione> lamont: ping??
#ubuntu-kernel 2006-06-12
<WebMaven> This *could* have been fixed prior to Dapper's release.
<crimsun_> lots of issues /could/ have been. Resource limits are problematic.
<WebMaven> I'm very grateful that it is supposedly fixed now, but I won't stop worrying until I can verify it for myself.
<WebMaven> crimsun_: sure, I understand. I also understand that the squeaky wheel gets the grease.
<WebMaven> So, I'm squeaking.
<WebMaven> I'll try to squeak more quietly, thoguh.
<WebMaven> 'though'
* WebMaven goes back to patient and reflective contemplation for the next few days.
<BenC> WebMaven: First reported: 2006-06-03 
<BenC> two days after release
<BenC> the dupes, did not contain enough info to triage the bug
<infinity> BenC: We build kernels for breezy-sparc because we always have?
<infinity> BenC: sparc wasn't officially supported in breezy, but it was released (same as hppa and ia64, both of which built fine, BTW)
<BenC> infinity: will a security update be held back because of sparc FTBFS?
<BenC> not sure if we introduced anything in the last breezy update that would have caused that
<infinity> BenC: If it can't be easily fixed, then I suppose not.  We only support amd64/powerpc/i386 on breezy.  That doesn't mean we shouldn't attempt occasionally to make sure the others work.
<zul> no i dont think anything touched those files
<infinity> BenC: Yes, it was FTBFS last time too, and I bounced you the log, you don't recall?
<infinity> (You told me you'd fix it for the next update)
<BenC> damn, guess I forgot :)
<infinity> Looks like the last one that built successfully was 10.26
<infinity> At least, that's the last one that's in the archive.
<zul> hmm....should i try to fix it?
<infinity> zul: I'd like it if someone did, but it's not the end of the world if no one does, I guess.
<infinity> I just dislike dropping a security fix on the floor just because an arch is unsupported (unless it's WAY too much effort)
<zul> ill track a crack at it
<infinity> Launchpad should have a resonable source history here, if you need to track back through the changes, since this was pre-git:
<infinity> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.12
<infinity> I know that 10.26 is the last version in the archive.  I'll have to dig a bit to see if that was actually the last version to build correctly.
<infinity> Okay, the first time I saw it fail was 10.32, since before that, Fabio was building sparc/security, not me.
<infinity> So, it broke bwteen 10.26 and 10.32 (not that helpful, I know, but I imagine the nature of the breakage won't make it that hard to track down which revision was responsible)
<mjg59> BenC: How do you get a git tree on kernel.org?
<infinity> Sleep with Linus.
<infinity> (again)
<mjg59> I told him how to make his Mac work
<infinity> That may be close enough.
<BenC> mjg59: email ftp-master@ftp.kernel.org I believe
<BenC> or maybe just @kernel.org
* BenC forgets
<mjg59> You need a kernel.org address?
<mjg59> Uh, account
<zul> sorry i didnt realized i wasnt registered :(
<BenC> mjg59: yeah, you'd get a kernel.org email, ssh account, and access to your own area(s) in the ftp tree
<BenC> I'm not sure of their criteria, but I was like "hey biatch, I'm Ben Collins, give me an account foo"
<BenC> and they were like "yeah dude, here ya go"
<zul> lol
<BenC> well, it went something like that :)
* BenC is doing a full warning-hunt on the 2.6.17 tree
<BenC> we're getting way too many compiler and MODPOST (linker) warnings
<BenC> and there's a lot of modules that cannot even load on smp machines, so I need to disable them
<zul> BenC: you did an upload for dapper?
<BenC> yeah
<zul> cool
<zul> ill put up the diffs for breezy/hoary tomorrow morning unless if i can do the uploads myself
<zul> anyays night night
<BenC> did you do anything besides the i387 for hoary?
<zul> what do you mean?
<zul> if you mean the other 3 patches that were there yes
<BenC> ok, you may want bump the hoary version
<zul> yeah i did..
<BenC> because I uploaded one after you for the i386 build failure on amd64
<BenC> one more than your last one :)
<zul> linux-source-2.6.10 (2.6.10-34.19) hoary-security; urgency=low
<zul> thats wgat i have in the changelog
<BenC> I did a .19
<BenC> so maybe make it .20
<zul> ok..ill do it tomorrow morning...same for breezy?
<zul> oh and i have a couple of patches that im testing right now if they compile alright ill forward them tomorrow
<zul> toodles
<WebMaven> BenC: You said " the dupes, did not contain enough info to triage the bug"
<WebMaven> BenC: But the main dupe had all 'requested' info, ibncluding the information that this was still a problem in the then-current Beta.
<WebMaven> The *only* reason my bug eventually had more info is because I kept asking "is there any other info you need" about twice a day.
<WebMaven> And becasue I didn't accept people blaming the ralink module.
<WebMaven> Only when another user volunteered the info that 'acpi=off' caused the network problems to go away was the problem solved.
<WebMaven> Without that info coming to light I'd probabaly still be asking "is there any furter info you need?" at irregular intervals.
<BenC> WebMaven: users were asked to try the stuff on the wiki, which included acpi=off
<pitti> hi
<fabbione> yo
<fabbione> BenC: the problem is that for some fucked up mind logic behind -updates
<fabbione> if you start using it, you will need to upload the kernel twice each time you do a security or bug fix
<fabbione> i personally don't care
<fabbione> but pitti can explain the details to you
<fabbione> i would prefer to keep all in one pocket for the sake of baby jesus
<fabbione> but you decide
<BenC> ok
<pitti> fabbione: it's not a fucked up logic, it's simply creating another branch we have to care for
<BenC> i can do security
<fabbione> BenC: do you want me to rephrase something to make it look like security?
<pitti> BenC: which changes do we talk about?
<fabbione> i am goo at that ;)
<BenC> pitti: random fixes from malone
<pitti> BenC: are they just some sparc bug fixes, or that sort?
<pitti> BenC: safe fixes with obvious patches are fine for me for -security
<BenC> no, they touch arch-indep code
<pitti> BenC: and since we should not be less careful with -updates, it doesn't really matter which one we break :)
<BenC> simple fixes
<fabbione> all i care is to get the sparc stuff in asap
<fabbione> i don't care how.. beacuse afaik we will need to push d-i into updates due to ogre model build system
<pitti> BenC: I'd avoid branching if at all possible
<pitti> BenC: so for me the question is not really -security vs. -updates, but rather whether a patch is appropriate for stable or not
<BenC> so stick with -security?
<pitti> yes
<fabbione> did we fix already all the known -security issues?
<BenC> yes
<fabbione> hmm ok
<fabbione> give me 2 minutes
<fabbione> i will give you a USN with a fix
<BenC> lol
<fabbione> BenC, pitti: see /msg
<pitti> BenC, fabbione: we don't need to invent anything :) we didn't release the current dapper kernel yet, so just update the currently pending one
<fabbione> right
<fabbione> that would work too
<fabbione> BenC: i leave up to you what you prefer.. 
<BenC> so can you reject that and I can merge .41 back to .40 and reupload .40?
<fabbione> you will need .41
<fabbione> sources for .40 have been accepted and processed
<fabbione> only the binaries are sitting in NEW
<BenC> ok
<fabbione> i guess we will still need the ABI files...
<BenC> yeah, gotta have those
<fabbione> yeha
<fabbione> infinity, Kamion, mdz and elmo are not around
<fabbione> our only hope is Znarl
<fabbione> or to start waking up people
<mjg59> Colin's on holiday
<fabbione> mjg59: yeah, that doesn't change that is not around :P
<mjg59> It was more "If you try to wake him up, really bad things would happen"
<fabbione> mjg59: yeah thanks :) i was told :)
<zul> heylo
<zul> BenC: i should have the updates for you by lunch time at the earliest
<zul> BenC: -20 is up
<zul> for hoary at least
<bradb> Is there an updated orinoco driver that supports WPA?
<mdz> fabbione,BenC: I'll accept the upload
<cjb> bradb: Are there orinoco *cards* that support WPA?
<mdz> hmm, that's odd, it claims it's been in the queue for 5 days? that seems unlikely
<mdz> oh, different upload
<mdz> fabbione,BenC: so does linux-source-2.6.17_2.6.17-1.1 need processing or no?
<BenC> mdz: Yes, it does, thanks
<bradb> cjb: Hm, good question. :)
<zul> wheee...iso training is fun
<fabbione> mdz: are you driving .15 upload trough dapper-security NEW process?
<mdz> fabbione: I was not aware that it needed driving
<mdz> I thought you were talking about edgy
<fabbione> .15 in dapper-security needs NEW in katie. I am not sure .41 is there already
<fabbione> mdz: and pitti doesn't have privileges to do it
<fabbione> anyway i am heading off for dinner and football
<zul> c ya fabbione 
<fabbione> mdz: if there is anything, please just text me
<fabbione> cya zulligno ;)
<mdz> fabbione: processing it now
<mdz> fabbione: done
<fabbione> mdz: ok cool. thanks
<zul> good luck with ghana
<fabbione> zul: thanks
<mdz> if .41 builds the same binaries it should go right through
<fabbione> mdz: yes, it will and .40 accepted is fine, since it stops at amber checkpoint ;)
<fabbione> later guys
<Alatius> Not sure if I've come to the right place here, but I wonder, what is the difference between the 386 kernel that is default and the 686 kernel you can download?
<Alatius> I mean, is there different patches applied to it, different compile settings, apart from the target platform?
<BenC> Alatius: 686 is tuned for 686 CPU's, while 386 will run on 486 and better (it's more generic)
<BenC> also the 686 version is SMP enabled
<Alatius> Yeah, I tried the 686 instead, since I have a PIII, but I have an issue with the 686 kernel that I didn't have with the 386...
<Alatius> My computer will now not shut down itself completely, instead it stays on the message "Will now halt". With the  386 kernel it worked perfectly.
<alex_joni> Alatius: sounds like ACPI is not working
<Alatius> I guess there's some issue with ACPI, yes.
<Alatius> But I wonder, is there any reason why the two kernels would handle it differently?
<Alatius> I read on the forums (right before they went offline) that I could try to start with "acpi=force lapic", but it didn't help.
<zul> later
<zul> heylo
<zul> crimsun_: ping
<crimsun_> zul: pong
<zul> have you seen this? http://www.kernel.org/hg/linux-2.6/?cs=c7a4c2b71aa7
<crimsun_> no, looking
<crimsun_> ah, I saw that changeset, but no one complained so it wasn't backported
<crimsun_> do we have a related bug report now?
<zul> yeah..#11149
<zul> i was going to grab it
<crimsun_> ok, if you want to, that's fine, else I'll queue it for this evening
<zul> ok ill will be in my tree tonight
<crimsun_> keep an eye on the struct vs. xxx_t changes
<zul> ill send you the patch 
<crimsun_> ok, thanks.  crimsun at ubuntu
<zul> ok
<blahblah> can somebody answer a simple question for me regarding kernel update frequency?
<zul> blahblah: it should be soon
<blahblah> how regularly does it happen?  daily/weekly/monthly?
<blahblah> I need a wireless driver and the stock installed kernel doesn't have it
<zul> what wireless driver?
<blahblah> broadcom, model number I forget
<blahblah> system is at work
<crimsun_> the bcm43xx has a native driver which works for some values of "works"
<blahblah> anyhow I'm just curious because I probably do'nt want to use a distro that has kernel updates quarterly or semi-annually :)
<[g2] > I think some of the OpenWRT have played with/worked on that driver
<blahblah> I've been using fedora on my laptop for the past two years but I want something less cutting edge
<blahblah> and something a bit more cohesive
<zul> well we dont do quarerly updates or semi-anual updates if that is what you are asking
<blahblah> well, I am asking the frequency............
<blahblah> is there a repository that has testing kernels that don't make it into the main repo?
<crimsun_> the frequency depends on the accumulation of fixes, generally. Security issues have highest priorities.
<blahblah> sure sure
<blahblah> but still, are we talking days, weeks or months in general?
<crimsun_> well, none of us can predict the future, but weeks to month{,s} is a decent range
<blahblah> ok so is it safe to say that there will be a kernel update monthly-ish ?
<blahblah> I can live with that
<zul> crimsun_: ttp://zulinux.homelinux.net/ubuntu/kernel/patches/cs46xx.patch
<crimsun_> I have no idea. I believe LTS wrt kernels is on the agenda at the Paris conf.
<crimsun_> zul: danke
<BenC> blahblah: if you are talking about stable (released), then monthly is probably worst case
<blahblah> ah good deal
<BenC> blahblah: however, if you are talking about following our development cycle, I can definitely put a hurt on your b/w with kernel updates
<blahblah> if everything worked, I'd be happy with a stock kernel that updated rarely
* BenC has no mercy in this case :)
<blahblah> but right now I'm using ndiswrapper w/ fedora and dapper has broken support for the wireless
<BenC> which wireless card?
<blahblah> apparently the newer kernel versions have fixed drivers so that's what I'm hoping to get
<blahblah> it's some broadcom model, forget which
<BenC> bcm43xx?
<blahblah> yeah
<BenC> if it is, you can blacklist bcm43xx and use ndiswrapper just the same as you used to
<blahblah> ah
<blahblah> can you point me to a doc on how to do that?
<blahblah> I do'nt want to kludge my system, but if it's a clean way of doing it I'll be happy with it
<blahblah> is there a modules.conf or something to tell it to avoid that module?
<BenC> (as root) echo blacklist bcm43xx > /etc/modutils/bcm-blacklist
<blahblah> ah excellent
<BenC> that'll keep udev from loading it up automatically
<blahblah> excellent
<blahblah> thanks for the tip
<BenC> np
<blahblah> adios
<zul> i think he was just looking for support
<cjb> Hrr.  My machine's been killing itself about once a week since I upgraded to the dapper release.  Maybe it's the temperature or something.
#ubuntu-kernel 2006-06-13
<zul> crimsun_: eerie
<zul> BenC: its hasnt failed yet has it? :)
<BenC> unfortunately I can't watch the builds for -security :(
<zul> ah..
<BenC> but I suspect it's going well, since no one has complained yet :)
<zul> or no one is awake 
<zul> then again
<infinity> No one was awake.  I'll go check and see if I should be complaining.
<chuck_> please
<infinity> Which one(s) am I looking at?
<infinity> Ben's latest 2.6.15 upload looks buggered all over.
<chuck_> hoary/breezy is mine
<ajmitch> morning infinity 
<infinity> Your latest 2.6.12 builds on amd64, but still fails on sparc (did you try to fix sparc?)
<chuck_> no im trying to get sparc up and running
<chuck_> and im trying to figure out whats wrong with it as well
<zul> infinity: what about 2.6.10?
<infinity> It's fine.
<zul> whoo..
<infinity> (For all I know, it's FTBFS on sparc too, but I don't build hoary on sparc/hppa)
<infinity> And don't really intend to start.
<zul> hehe
<crimsun_> (offline for ~1 hr)
<zul> night folks
<BenC> crimsun_: fixed another build failure in cs46xx
<crimsun_> BenC: besides the typo 5/6 one?
<BenC> yeah, I picked up that patch, but there was one more in the .c file
<crimsun_> ah geez
<crimsun_> sorry 'bout that
<BenC> -int snd_cs46xx_suspend(snd_card_t *card, pm_message_t state)
<BenC> +int snd_cs46xx_suspend(struct pci_dev *pci, pm_message_t state);
<BenC> np
<BenC> my fault for not build testing after those last two patches
<crimsun_> sheesh, silly me. Of course pci would have been undefined since it would have been missing as an actual parameter...
<zul> heylo
<kimo> I'm dying for sky2 driver update! When are we getting the kernel update :)
<fabbione> kimo: probably tomorrow.
<fabbione> and the less you ask, the faster you get it. people don't have to spend time here to answer, but can work on it
<zul> oh hey fabbione 
<zul> good game yesterday
<fabbione> zul: thanks. next will be against US :)
<zul> you should win that game of course
<fabbione> we should yeah
<zul> if not i will laugh and laugh
<zul> BenC: i have a couple of patches that im building now for dapper ill send them off tongiht
<fabbione> zul: i have a lock on dapper kernel now
<zul> fabbione: hmmm?
<fabbione> zul: i need to release for sparc now. No more changes until that's done
<fabbione> .43 now builds and i need to make sure that one goes in and builds as it is
<zul> fabbione: thats fine, ill just accumulate them until the lock is released
<fabbione> zul: that's exactly what i was asking for :)
<fabbione> thqanks
<zul> hmm...our junior tech typed in the bios password for a laptop wrong
<zul> and now he cant get in
<fabbione> my wife did the same
<fabbione> i need to find a way to reset it
<zul> take the laptop apart and take out the bios battery?
<fabbione> yeah i will have to do when i have time
<mjg59> Are you sure it's only the bios password?
<mjg59> Laptops have secondary passwords that are stored in eeprom
<mjg59> Only way to deal with them is take them apart until you can get access to the i2c bus, and then drive the eeprom directly
<mjg59> And then try to work out what needs to be done to remove the password
<fabbione> mjg59: pretty sure it's only the BIOS password
<zul> whee...writing documenation is fun
* mvo wonders what the minimum size of RAM we currently support. booting with mem=48M into single-user-mode gives me a "page allocation failure" when I try to load skge
<BenC> that's probably not even enough for the kernel
<Keybuk> heh
<Keybuk> mvo: what did you try and boot?
<Keybuk> you need about 20MB for the initramfs
<Keybuk> maybe another 16MB or so for init and udev
<Keybuk> you certainly need 8MB or so for the kernel itself
<Keybuk> and then it uses anything between 20MB-64MB of memory for its own nefarious purposes
<Keybuk> so minimum RAM would be 64MB on i386 and probably 96MB or more on amd64
<Keybuk> (ps. holy christ that's a lot)
<Mithrandir> server claims to work on 64MB
<Keybuk> Mithrandir: depends how much swap space you have :p
<Keybuk> 64MB is probably the absolute minimum without swap, being only just enough to get the kernel and initramfs loaded
<maswan> Well, does server install swap space by default?
<BenC> everything instals swap by default
<BenC> except for diskless systems of course :)
<Mithrandir> but swapping over NFS is _so much fun_!
<maswan> Btw, can I bug you guys with my silly feature requests now? Like shipping a vmlinux somewhere, and sensible default tcp window sizes? ;)
<mvo> Keybuk: I'm using mem=64M now and it works a lot better (swapspace is pretty big)
<BenC> maswan: s/bug/propose a spec/
<BenC> better hurry, UDS starts in 6 days
<maswan> I guess, just feels silly to do that for a small fix. But I'll write something up then.
<BenC> tcp windows needs to be discussed
<BenC> vmlinux just file a bug
<BenC> I think there's already one
<BenC> providing a patch to current git to install such a file would be your best bet there
* maswan nods
<maswan> Unless you want to discuss providing a separate -debug package to save a few megs in the kernel package.
<maswan> Yes, there is indeed a wishlist bug for vmunix
<BenC> I actually would like to see a linux-debug package, with the ABI file, vmlinux, and build-log
<BenC> one for each flavour
* maswan nods
<maswan> me too
<BenC> it can be done just like the linux-headers package does
<BenC> in debian/post-install
<maswan> sounds pretty encouraging then
<maswan> Want me to put a comment with those two lines in the bug to remember it by, or are you one of those guys that remember things and so on? :)
<zul> BenC: we tried that in breezy with all of the config options for debug turned on, it was huge
<BenC> well, I don't really mean a debug enabled kernel
<BenC> just the raw vmlinux from the actual build
<zul> ah i see
<BenC> uncompressed, unstripped, etc
<zul> later im out of here
<zul> BenC:  http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9810933701a09f9c4dd0ad963d5ec2efb7df07b7
<zul> BenC: for 38851 couldnt  we just blacklist it?
<BenC> zul: cherry-picked that commit
<BenC> let me check 38851
<zul> BenC: for dapper?
<BenC> yeah
<BenC> it's already in edgy's kernel
<zul> ahok
#ubuntu-kernel 2006-06-14
<BenC> zul: ping
<zul> yeah
<zul> what did i do wrong? :)
<BenC> rofl
<BenC> zul: in your patches, ditch the debian/changelog parts
<zul> ok
<BenC> I manually add those, and I like to keep the patch seperate from the changelog entry
<BenC> so it's easier to git-revert, without killing changelog history
<zul> i so hate freenode
<roh> yay!
<roh> http://www.kernel.org/git/?p=linux/kernel/git/davej/cpufreq.git;a=blobdiff;h=cfc4276e670e3eac2ccc2f1c0a81f3258ff8a586;hp=28cc5d524afcd18a2dce1ee4f5ccb3d2c737faf1;hb=f081a529f808ed450c22553de7b3275e0ffde9a0;f=arch/i386/kernel/cpu/cpufreq/speedstep-smi.c fixes my bug it seems
<zul> roh: already applied to the dapper kernel
<roh> zul i didnt check that.. i'm currently clicking my way through the git and am impressed.. what would we do without git..  besides inventing it
<roh> i really have to learn how to use that
<roh> zul will there be new kernelpackages for dapper also or do i need to built my own?
<zul> yes there will be updates dont know when yet
<roh> zul can you point me directly to the docs how to exactly rebuild the kernelpackages the way buddha^Wthe allknowing thing wants?
<roh> meaning: i'm currently developing a driver and don't want to sacrifice madwifi for example
<BenC> all the ppl who build custom kernels from our source are gonna love me now
<ajmitch> what did you break? :)
<BenC> hehe
<BenC> I made it easier to change the ABI, so people don't have to ask a whole lot of questions
<BenC> pretty much needed it so I can do daily builds
<BenC> the method I am using uses the git hash to create a special abi on the fly
<ajmitch> you plan to break ABI that often for edgy?
<BenC> keeps ppl from getting stock kernels confused with daily builds, plus it makes it easy to know where in the git tree the build was from
<infinity> BenC: Spiffy.
<BenC> no, just I don't want to guarantee any ABI syncronizing for daily builds
<ajmitch> sounds useful then
<BenC> infinity: yo!
<BenC> infinity: .43 is awaiting fabbione's blessing for a sparc patch, and is build tested
<infinity> Oh, hey, look, 24.42 actually built everywhere.
<BenC> infinity: what!?
<BenC> use 25.43 for l-r-m
<infinity> Was it not meant to? :)
<BenC> I thought someone told me it didn't build every :/
<infinity> Oh, wait.  I don't see a PPC build.
* infinity looks.
<BenC> yeah, that's the one, ABI failure
<BenC> 25.43 is locked waiting for a sparc patch, and fabbione promises to upload at 11am his time
<BenC> it was build/boot tested on i386, ppc and amd64
<infinity> Okay, so the PPC ABI thing is sorted?
<infinity> That's quite the ABI change...
<infinity> Why did you pull that serial stuff out of vmlinux?
<infinity> Won't that bugger early output on serial terminals?
<infinity> Or should openfirmware provice console/serial emulation until the driver kicks in?
<infinity> (serial booting on my machine, like just about anything else on an OldWorld, doesn't work for beans, so I don't actually know how OF deals with it)
<fabbione> morning
<fabbione> BenC, infinity: yes max 11am UTC
<fabbione> BenC: so i pull and another ABI bump???
<fabbione> infinity: ok i have the stuff from BenC
<fabbione> BenC: good night dude
<BenC> infinity: because of 8250 is loaded, PMACZILOG cannot work, so I had to take 8250 out as a module
<fabbione> BenC: i got all your stuff..
<fabbione> i think at least ;)
<BenC> good deal
<BenC> yeah, it's pushed, and should be all ready for you
<fabbione> linux-source-2.6.15 (2.6.15-25.43) dapper-security; urgency=low
<fabbione>   * bcm43xx dma mask handling (> 1GB memory)
<fabbione>   - Add powerpc IOMMU handlers for dma masks
<fabbione>   - Sync updates to amd64 IOMMU to handle dma masks
<fabbione>   * Sync ide changes for better flash driver handling (flash isn't removable).
<fabbione>  -- Ben Collins <bcollins@ubuntu.com>  Tue, 13 Jun 2006 08:16:30 -0400
<fabbione> that's all i have here...
<fabbione> can you confirm?
<fabbione> i still have the powerpc.ignore file
<fabbione> that can go away
<fabbione> but i can do it
<fabbione> BenC: how do i git tag the release?
<fabbione> BenC: or are you going to do it later?
<BenC> just push your final, and I'll retag itr
<fabbione> ok works for me
<fabbione> BenC: are you also syncing the changes from .15 into .17?
<BenC> yep
<BenC> I pull from dapper to edgy to make sure we keep everything in sync
<BenC> it's nice
<BenC> dpkg-deb: building package `linux-headers-2.6.17-2-f23859-386' in `../linux-headers-2.6.17-2-f23859-386_2.6.17-2.2_i386.deb'.
<BenC> sweetness
<fabbione> wth..
<fabbione> BenC: btw can you pull from my edgy tree?
<fabbione> it's a simple change in the control files for the cluster suite
<BenC> ok
<BenC> let me push later so you can merge and repush
<fabbione> ok sure
<fabbione> BenC: [    0.829976]  BUG: soft lockup detected on CPU#2!
<fabbione> i get tons of these for different CPU with .17-1.1
<fabbione> (sparc)
<zul> hola
<mjg59> BenC: If we're going to shift to libata pata drivers, we probably want to do it soon
<mjg59> Some of them are going to need testing
<fabbione> BenC: please pull from both my dapper and edgy tree.
<fabbione> BenC: dapper is uploaded and building. Please no more uploads till sparc is released 
<fabbione> BenC: otherwise we look fine.
<zul> BenC: #45679 ill update the driver tonight if thats ok?
<BenC> which driver?
<zul> arcmsr
<BenC> sure thing
<BenC>     [UBUNTU:arcmsr]  Update to latest patches in -mm tree.
<BenC> that's the last place I got patches from
<BenC> make sure it's the same set of stuff
<zul> sure..i was going to get it from the vendor apparently it works according to the bug reports
<BenC> 1.20.00.13
<BenC> it says it was fixed in 1.20.0X.12, and we have the above version
<BenC> that's a little odd
<zul> yeah..
<zul> ill look into it tonight then
<BenC> 1.20.00.12    9/30/2005       Erich Chen     bug fix with 64bit platform's ccbs using if over 4G system memory
<BenC> that's in our ChangeLog.arcmsr
<zul> just a sec..
<BenC> Documentation/scsi/ChangeLog.arcmsr
<BenC> and that was from the patches from -mm
<zul> of course the vendor website has to be down
<zul> BenC: thats in BenC yeah thats just weird
<zul> what the hell?
<ajmitch> blame the keyboard gremlins
<zul> i blame the irq between my brain and keyboard
<zul> BenC: are you going to be in paris?
<BenC> yep
<zul> coool..
<zul> have fun i wont be
<zul> when are the security updates going to show up?
<mkrufky> i spoke to the DViCO systems engineer....   Bug #12162 is bogus. the "fix" from that bug causes bug #33096, which is valid.  The fix would be to revert ubuntu git commit 3a580f39df8937f54976b2e7ce2ef54294da06f9 .....  I have added the appropriate comments to those bugs on launchpad.net
<mkrufky> BenC: should I send you a patch to revert that commit?  ...or are the launchpad.net comments enough?
<BenC> mkrifky: Yes, please
<BenC> mkrufky even
<mkrufky> :-)
<mkrufky> BenC: oh, man.... i just finished cloning ubuntu-2.6.git , and it seems that the bogus commit got automagically reverted as a result of a pull from upstream
<mkrufky> however, ubuntu-dapper.git still has the bogus patch
<mkrufky> i guess i'll have to re-clone from the dapper tree
<fabbione> BenC: please hold any dapper uploads please :)
<BenC> fabbione: wont be doing dapper again till after paris
<fabbione> BenC: kthx :)
<dilinger> meh, i wanted to go to paris :(
<zul> join the club 
<zul> whats with these ubuntu conferences when the city speak french?
<fabbione> zul: hopefully the last one :)
<zul> hehe
<zul> ill go to the next one
<zul> only if they dont speak french ;)
<dilinger> i was expecting work to send me to this one
<dilinger> but things at work aren't going so well
<dilinger> so.. *shrug*, doesn't look like it's going to happen
<mkrufky> BenC: ok, i uploaded the fix to launchpad bug #33096
<zul> fabbione: where can i get the sparc iso?
<zul> later
<kimo> sorry for being n00b, but when it says '2.6.17-1.1' is released, it means released in the git tree only, right ? (no debs?)
<crimsun_> it means it was uploaded.  [https://lists.ubuntu.com/archives/edgy-changes/2006-June/000040.html] 
<kimo> would this new version, include fixes commited to the offcial dapper kernel ?
<kimo> like the recent fixes to my sky2 driver ?
<roh> oh.. edgy already started?
<kimo> roh: yeah :) ubuntu+1
<crimsun_> kimo: see the sky2-related commits at http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=shortlog
<roh> then i hope soon somebody takes the time to make rootfs via uuid working
<kimo> crimsun_: thanks, great :) I am still not sure if there is a 'nightly build' deb package I can install to get those fixes 'now' ?? (or should I compile from a git tree) ?
<crimsun_> kimo: I presume the URL mentioned in [https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-June/000150.html]  will be populated
<kimo> ohh cool :) bcollins makes a daily build system, which is unfortunately empty ;) http://people.ubuntu.com/~bcollins/kernels-daily/
<kimo> ok I found the deb in upper dir http://people.ubuntu.com/~bcollins/
<kimo> downloading, thanks ;)
<roh> mmmh.. should i build from linux-source-2.6.15 or from the sourcepackage for linux-image-2.6.15-23-386 ?
<crimsun_> the latter.
<roh> tnx
<roh> which way of packaging is the recommended then? via make-kpkg or dpkg-buildpackage?
<crimsun_> either, depending on whether you want to use the infrastructure. If you're not sure, choose the latter.
<mkrufky> roh: are you rebuilding your kernel right now just for the sake of the dvb development?
<mkrufky> roh: that hg repo i told you about is backwards compatible with older kernels
<mkrufky> so... if that's what you're doing.... you can save yourself some time
<roh> mkrufky no.. mostly because speedstep does not work with dapper release on my tp-x20
<mkrufky> ah, okay
<roh> and i want piix ide fixed in the kernel since its the rootfs, and the initrd sometimes loads the sii-ide before piix and my root is  hde then ;)
<mkrufky> ok -- valid reasons  ;-)
<kimo> roh: u might want a newer prebuilt from http://people.ubuntu.com/~bcollins/ ?
<roh> kimo if there is enough source with it to build other modules later which need a working makefrile from a kerneltree
<BenC> roh: speedstep will be fixed for you in the next kernel update for dapper
<roh> BenC is there a package which gives me a /lib/modules/`uname -r`/source symlink to working makefiles and headers for building external drivers which depend on headers of existing drivers?
<BenC> lol
<BenC> apt-get install linux-headers-`uname -r`
<roh> i know that package.. but it does not contain tda1004x.h for example, which i need for my driver since the attach function for this demod is declared there
<roh> hm.. but... forget it.. i propably just compile the whole dvb stuff from hg, so i can use the header from there...
<BenC> roh: linux-source-2.6.15
<roh> BenC do you know when the new packages get out?
<BenC> the dapper 2.6.15 update, or edgy 2.6.17?
<BenC> well, either will be available within a day or two
<roh> dapper.. for now i'll propably stay with dapper, even if i'd like the new kernel.. its a 600mhz tp-x21.. no fun with a few hundred updates every week
<mkrufky> roh: seriously -- dont worry about the dvb frontend sources in the ubuntu kernel... you REALLY need to use the hg stuff
<mkrufky> roh: you should work within the hg v4l-dvb tree on linuxtv.org
<mkrufky> otherwise you're going to have a real pain once you're ready to merge your new driver
<mkrufky> ... (or I will)
<mkrufky> roh: i'm leaving now... if you need help later with the hg stuff, i'll be back in #linuxtv in a few hours
<mkrufky> bye all
#ubuntu-kernel 2006-06-15
<BenC> later
<zul> hey
<BenC> yo
<zul> how is it going
<zul> http://www.youtube.com/watch?v=y6vhTSwoSA8
<BenC> writing wiki pages isn't fun
<zul> heh...im doing some grub stuff
<zul> yay..new grub works
<kimo> I am using 2.6.17-1.1, everything in official dapper kernel is fixed :) Problem, is waking from sus2ram => kernel oops. Should I report this ? where ?
<crimsun_> sure.  [https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+filebug] 
<kimo> Thanks, bug reported
<kimo> anyone knows the difference bet a process's nice value & its priority value (as shown in top for example)!
<infinity> Priority is the kernel assigned priority, which relates to the niceness, but not always in an obvious 1:1 way.
<kimo> thanks ... any relation, or totally random!
<kimo> depends on load ?
<Keybuk> PRI = Nice + -20
<Keybuk> iirc
<fabbione> last i checked it was slightly different
<kimo> if its that straightforward, then its redundant
<fabbione> priority indicates the amount of CPU the process is allowed to get and it's calculated according to the amount of processes
<fabbione> nice is a value that indicates how quickly a process can be deprioritized 
<fabbione> (or prioritized according to the POV)
<fabbione> so a process can be high priority because it's really CPU consuming
<fabbione> but it can be nice 20 and gets deprioritized very fast if other process with same or higher priority get in the game
<fabbione> see for example stuff like setiathome
<fabbione> they are very cpu intesive (high priority) but they get trashed on the floor if anything else needs CPU (high nice level)
<kimo> this way, the priority, is an internal (scheduler) thing, right. The user shouldnt & doesnt want to see it, and cant change it, right ?
<Keybuk> users never need to use top
<kimo> admins I mean
<fabbione> kimo: assume you have a 1 sec sample of time
<fabbione> n one sec a lot of things happen in the CPU
<fabbione> tons of processes are running
<fabbione> they need to get scheduled and for only a very precise amount of time
<fabbione> the priority is used to calculate that time
* kimo is thinking, priority is speed, nice is acceleration. Nice changes how 'fast' priority changes!
<fabbione> right
<kimo> cool ... thanks a lot for the verbose explanation
<fabbione> kimo: please deposit 1.000 USD on my bank account
<fabbione> ;)
<kimo> :)
<zul> heylo
<hub> hi
<hub> how can I get older kernel packages from the Dapper development cycle?
<hub> I have a freeze in -23 that happen less often in -22, but used to never have problems with older kernel
<hub> I want to track it down to a specific release
<jbailey_> BenC: Hey, is this the patch from the guy who's stuff is in the -mm tree?
<jbailey_> (re: the lkh mail you sent me today)
<jbailey_> If yes, I was hoping to drag you aside and look at it in Paris sometime. =)
<BenC> Not sure, but it looked like something you'd be interested in
<BenC> ok, we can do that
<jbailey_> Or during the toolchain workshop or something.
* BenC can't wait to leave for paris
<jbailey_> About 12 hours for me.
<jbailey_> The flight was much cheaper.
<jbailey_> But I thought it was tomorrow.  I'm glad I looked at my tickets a couple days ago.
<BenC> 2 more days for me
<zul> dont get into too much trouble
<zul> jbailey_: customs agents at trudeau might recieve a call about you on your way back though ;)
<jbailey_> Err.  Why?
<jbailey_> What did you do?
<jbailey_> Oh
<jbailey_> misread.
<jbailey_> I know where you live.
<zul> you know the city, not the street :)
<jbailey_> I just need a sufficiently high grade weapon.
<zul> true
<jbailey_> ;)
<BenC> when I went to Montreal
<BenC> my friend got flagged in Baltimore for random search
<zul> last time i flew out of montreal there was a bomb scare on the airplane that i was on.
<BenC> while he was being frisked by a large security person behind a glass wall, I leaned over and told the guard "He's got something hidden up his butt, might want to check it out"
<BenC> the guard said "If he's got something up there, it's going to stay there"
<BenC> my friend was not happy :)
<zul> .hehe
<hub> zul: customs agent in YUL are assholes
<hub> zul: next time I'll ask what 272 means on the custom form
<zul> heh
<hub> so no archive of the kernel packages anywhere?
<zul> isnt there a morgue?
<hub> you tell me
<hub> I'm looking for older like 2.6.15-19 to track down a regression
<hub> my laptop freeze on wake up, very often
<Keybuk> hub: on Launchpad
<hub> -22 seems better than -23
<Keybuk> go to the kernel source page, and it lists all the versions
<Keybuk> pick one and it lets you download the binaries
<hub> ok. now I need to locate them in Launchpad
<Keybuk> linux-source-2.6.15
* hub won't say anything about launchpad UI
<BenC> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15
<hub> BenC: yeah reached that
<hub> thanks
<Keybuk> now pick a version
<hub> yep
<Keybuk> oh, weird, the binaries are missing
<Keybuk> iz lp bug
<hub> Keybuk: no biggie, I'll debuild it
<Keybuk> ah
<Keybuk> no
<Keybuk> you have to go to the build
<Keybuk> https://launchpad.net/+builds/+build/189805
<Keybuk> and then pick a binary
<BenC> hub: Only choice if lp doesn't have them is to get the GIT repo, and use the tags to build
<infinity> Yeah, binaries are associated with a build, not with the source.
<hub> BenC: I'll build from the debian package
<infinity> Which actually does make sense, internally.  Honest.
<hub> BenC: I have some time anyway
<BenC> hub: then you'll be downloading quite a few 80Meg tarballs if you don't get the right one the first time :)
<hub> my problem is that I can't even get enough diagnostic for the bug to be usefull
<BenC> plus if you do find the right one, still need to use git-bisect to find the exact commit
<hub> BenC: I have no clue were it freeze
<hub> BenC: I just want to put in the bug, version foo does not
<hub> BenC: and stick to that for my laptop
<BenC> hub: which is really useless
<hub> freeze on wakeup is a waste of time
<hub> BenC: then I'll just keep it for myself
<hub> I have NO output anyway
<BenC> so you don't want the bug fixed for everyone else, and for security updates?
<hub> my problem is that dapper final is less stable that developement
<BenC> I'm not asking for output
<BenC> you can use git to find the exact commit that causes the problem
<BenC> if you are willing to take the time to rebuild a kernel that works for you, it would be nice to take a little more to actually find the problem
<hub> I have never used git 
<hub> BenC: I'll see what I can do on my copious spare time
<BenC> hub: if you're willing to do the testing, I'm willing to help you through git
<BenC> URL in topic shows how to obtain the source
<hub> BenC: ok
<hub> the thing is that this is my only machine
<hub> the otherone does not have a keyboard
<hub> and I'd rather not use it to build kernel
<BenC> doing something like "git-checkout 2.6.15-22.33" will get you the source for that version
<hub> .34 freeze sometime, but less that 23.39
<hub> 2.6.15-19.29 did not
<hub> because that one was actually installed but has been purged since
<hub> I'll start from there, 
<hub> BenC: ubuntu-dapper.git I should get?
<hub> BenC: the bug is that one https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/49078
<BenC> yeah, dapper.git is what you want
<hub> currently cloning
* hub knew bk at one point
<BenC> it's very similar to bk
<mkrufky> except git is open source
<hub> mkrufky: yeah. that is something that was bugging me
<hub> mkrufky: but the only reason I used it is because I did doing kernel development at that time, for a short living
<mkrufky> bk was good while it was used -- i'm not knocking it ;-)
<hub> mkrufky: the worse was that $BOSS didn't trust people so we had to send hime patches
<mkrufky> huh?
<hub> yeah we had our own bk tree
<mkrufky> oh ok
<hub> and all the change had to go thru $BOSS
<hub> who didn't care about upstream
<hub> unless it was to pull the changes
<mkrufky> who is "we" ?
<hub> mkrufky: me and other coworker at that time
<hub> mkrufky: working on a ADSL settop box for the #2 ISP in France
<hub> but this is getting off-topic
<hub> does building the kernel use ccache?
<hub> if available?
<zul> yes you can use ccache
* BenC would be useless without ccache for kernel builds
<fabbione> BenC: no just a tad slower ;)
<hub> BenC: I did a git clone, and if I do a 'git-checkout 2.6.15-19.29', it says 
<hub> git checkout: you need to specify a new branch name
<BenC> git-branch 2.6.15-19.29 2.6.15-19.29
<BenC> try that
<BenC> if that doesn't work, cat .git/refs/tags/2.6.15-19.29
<BenC> and do git-branch 2.6.15-19.29 <sha from cat>
<hub> git-branch did work
<hub> or at least didn't complain
<BenC> ok, from there you can git-checkout 2.6.15-19.29
<hub> in progress
<hub> done
<BenC> are you using 386, 686, k7?
<BenC> sudo apt-get build-dep linux-source-2.6.15
<BenC> then do:
<BenC> fakeroot debian/rules binary-debs flavours=686
<BenC> change 686 to which ever you are using
<hub> Pentium M
<hub> so likely to be 686
<hub> actually it is -386
<hub> 2.6.15-22-386
<hub> should have I installed a -686 kernel?
<zul> BenC: the one kail is talking about is 0.54
<BenC> hub: no, doesn't matter
<hub> ok
<BenC> -386 should work everywhere, while -686 is a little optimized (and has SMP)
<hub> I'll test with -386 to not add variety to the testing conditions
<KaiL> fabbione, so you want the bug # here again? ;)
<KaiL> bug 49870
<KaiL> ok, no bot 
<fabbione> KaiL: why? i am not a kernel maintainer so i am not going to fix anyway :)
<KaiL> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/49870
* fabbione wins over and over
<KaiL> I thought, you are? only for edgy?
<fabbione> nope
<fabbione> i was.. for breezy
<KaiL> ah!
<fabbione> partially breezy sorry
<fabbione> mostly hoary
<zul> btw 0.53 apparently fixes this from nvidia
<KaiL> there's also a 0.54, maybe also bugfix only?
<KaiL>  *	0.54: 21 Mar 2006: Fix spin locks for multi irqs and cleanup.
<KaiL> uhm, yes...
<zul> BenC: ill put it my tree..
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.17-1.1 uploaded, please use responsibly | Daily kernel builds (for debug and testing purposes only) http://people.ubuntu.com/~bcollins/kernels-daily/ | Kernel Wiki: https://wiki.ubuntu.com/CategoryKernel
<zul> hmmm...whats wrong with this bug? #49789
<bluefoxicy> BenC:  side note, do you know anyone particularly good with linux kernel mm/ internals?  Particularly the swap code
<BenC> not off hand
<bluefoxicy> ah damn.  Oh well, maybe when I get most of this thing coded I can coerce someone into doing that part.
<cjb> bluefoxicy: #kernelnewbies on oftc?
<bluefoxicy> cjb:  they bounce me source fil eto source file but the functions are non-intuitive.  :)
<bluefoxicy> cjb:  I'm trying to break up the swap code and make a point where the kernel thinks a page has been swapped out but it hasn't yet been sent to the actual swap medium yet (i.e. disk)
<bluefoxicy> which of course has code that just shoves it into the swap medium
<bluefoxicy> I have something interesting to do inbetween though.
<bluefoxicy> (I'll break suspend to disk probably but that'll be a one line fix)
<cjb> Well, how does, say, the encrypted swap support do it?
<bluefoxicy> encrypted swap?  I dunno.
<bluefoxicy> I'm not doing anything to the swap file though.
<cjb> Okay; thought it might be using the hooks you're after.
<cjb> Since you want take page -> ? -> store page on disk, and "encrypt page" is one such action.  :)
<bluefoxicy> cjb:  http://bluefox.kicks-ass.org/mediawiki-1.5.5/index.php/Project_Zone/Design
<bluefoxicy> cjb:  That's what I'm doing :)
<WebMaven> BenC: Hi Ben!
<WebMaven> BenC: I just upgraded the laptop, and the fix works! Thanks!
<WebMaven> Yay!
<BenC> cool
<BenC> sweet, -25 is fixing bug after bug
<zul> heylo
<zul> BenC: ping
<zul> can you have a look at http://zulinux.homeinux.net/ubuntu/kernel/vmware-player
<KaiL_> connection refused ;)
<zul> oops
<zul> can you have a look at http://zulinux.homelinux.net/ubuntu/kernel/vmware-player
<KaiL_> hmm, would it be possible to write a (userspace?) tool, which sends everything accessing /dev/dsp to esddsp or aoss..?
<KaiL_> that should finally end the oss-Hell
<KaiL_> ..wrong channel? ;)
<zul> BenC: compiles and works for me 
#ubuntu-kernel 2006-06-16
<BenC> zul: all you changed was the ABI number, right?
<zul> yeah ant the control file
<BenC> upload away then
<zul> done
<zul> now wait for the rejection
<zul> im thinking it got rejected
<roh>  .oO(as long as the default kernel ends up without vmware modules....
<mdz> BenC: 2.6.17 binaries new'd
<BenC> mdz: nice, thanks
<BenC> is vmware-modules a seperate package?
<mdz> well, except ia64 which is still building
<BenC> if so, I wonder what keeps us from putting it into lrm
<BenC> mdz: is hppa gone from edgy, or just delayed?
<mdz> BenC: yes, it is a separate package unfortunately, and I would prefer to have it in lrm
<BenC> mdz: Consider it done for edgy
<mdz> I don't remember why it wasn't done that way in the first place; talk to mvo?
<roh> lrm?
<BenC> will he be in paris?
<roh> restricted modules?
<mdz> yes
<mdz> he should be online tomorrow as well
<roh> i'd like a extra package more, since i mostly don't want to accept the vmware licence just to get the madwifi modules
<BenC> mdz: Hey, kirkland from IBM invited me to a google sponsored summit at LWE
<BenC> linux testing discussion, IBM, Google, RedHat, and some others
<BenC> mdz: It's in Aug, so wanted to give you some time to think about it
<BenC> kirkland is the guy doing our ABAT stuff
<mdz> sounds interesting, where is it?
<BenC> SanFran
<mdz> BenC: ah, roh is right...that's surely the reason
<fabbione> BenC: what week?
<mdz> the vmware modules require a license acknowledgement
<BenC> he actually invited "Ubuntu", so anyone else can come
<BenC> mdz: Ah, good reason
<BenC> fabbione: hold a sec
<mdz> maybe they'll be willing to relax that in the future
<BenC> Somewhere around 14-17
<fabbione> BenC: the week after is the one davem and I were thinking for the "sparc will conquer the world week hacking fest in SF"
<zul> heh
<zul> BenC: can you grab the vmware stuff and do an upload t thx
<BenC> fabbione: If that happens we can combine it
<BenC> zul: ok
<fabbione> BenC: i had no time to talk with Matt yet :)
<BenC> well, combine the trip :)
<zul> ooh...you can stop in ottawa ;)
<zul> BenC: can i delete it...people are starting to my webserver
<fabbione> zul: it's like... it's like... who cares about ottawa? :=)
<zul> fabbione: yeah yeah...
<zul> you will when canadians take over the world
<BenC> zul: I got it
<zul> cool...ill delete it
<fabbione> zul: before canandias will take over the world, an italian will be US president
<BenC> not sure how a bunch of flapping split heads can take over the world
<zul> flapping split heads? thats a new one
<BenC> <insert south park reference>
<zul> ah ok
<zul> aboot
<BenC> zul: thanks, uploading now
<zul> cool
<zul> now people will stop asking
<zul> ..as much
<mdz> BenC: are you ready to update linux-meta to .17?
<BenC> just waiting on infinity to upload lrm for .17
<BenC> I gave him my patch to get it building, but he had a few changes for edgy
<fabbione> do you really want to switch default kernel already?
<fabbione> BenC: .17-1.1 is no go on Niagara
<BenC> yeah
<fabbione> ok
<BenC> fabbione: Fixes from davem are in -2.2
<fabbione> ok
<BenC> which I am uploading
<BenC> just finishing some final builds
<fabbione> a lot of BUG CPU #XXXX soft lockups
<BenC> yeah, you need the scheduler tuneup that davem sent
<fabbione> ok
<fabbione> BenC: remember that rcu patch i did try once and didn't work?
<BenC> as soon as I upload -2.2, infinity will do lrm
<BenC> and I'll do linux-meta
<BenC> yeah
<fabbione> BenC: we will have to revisit it for dapper. the 2/3 niagara people that hangs in #u-ports are all experiencing that problem when make -j
<fabbione> at least with low (as in 8GB) mem
<BenC> ok
<BenC> also, .17 will be final any day now
<fabbione> yeah
<BenC> we will have lots of room for stabalizing this kernel for edgy
<fabbione> .17 doesn't have the problem
<BenC> ah, ok
<fabbione> it's only .15
<fabbione> the bug was introduced in .14 and fixed in .16 when davem and I found it on Niagara
<fabbione> it's not critical, but nice to habe
<fabbione> have
<BenC> started the next dapper kernel changelog if you want to push it to me
<fabbione> push what?
<fabbione> i have nothing to push at the moment :)
<fabbione> just some extra crack ;)
<BenC> well, when you have something :)
<fabbione> ehhe sure
<zul> updating forcedth is probably cause us more problems
<infinity> BenC: I've run out of pre-flight time to tend to LRM.  If you don't mind, I'd like to just do it in our hotel room on the first night there, then I can walk you through the uber-sketchy bits at the same time.
<zul> hey
<andi5> hi... although i was just told that nobody should use edgy, i tried the new kernel (2.6.17-1-686) and wondered why there is no support for prism2_usb which was available in dappers kernel (and before).... any particular reason for removing it? thanks in advance
<zul> proabbly hasnt been enabled yet.
<andi5> zul: can you tell me, as a user that likes stock ubuntu kernels but is able to compile a kernel himself, what to do? forget edgy kernels for xyz weeks or wait abc days? .... i just wished someone could tell me why my setup is unstable :(
<zul> because you are running an edgy kernel on dapper and the edgy kernel is on high development...
<andi5> not really, i am running dapper kernel on dapper and it is unstable
<zul> anyways i have to go work..
<andi5> kswapd0 goes crazy sometimes (up to 4 times per day).... 100% cpu usage, unkillable, forces me to restart computer.... ... damnit ;-) thanks nonetheless
<KaiL_> gar.. a regression with 2.6.15-25:
<KaiL_> network modules (eepro100 and ipw2100) get "lost" on suspend on Asus M2N
<KaiL_> suspend is getting worse and worse on that Laptop :(
<zul> please open a bug
<KaiL_> on the way
<fabbione> andi5: not everything has been ported to .17 yet..
<fabbione> andi5: so if you are able to compile your kernels, you could also try to port it and provide a patch
<fabbione> that would help too
<andi5> fabbione: oh, i see.... will see what i can do... thanks!
<KaiL_> ok, not the module, only ifconfig - https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/49984
<zul> KaiL_: you need to add more detail in your bug report, ie what ethernet cards you have etc
<KaiL_> *looking into /etc/network/interfaces* *wondering* PEBKAC? ;)
<KaiL_> *trying something else*
<KaiL_> ah, now I get, what's going on here
<KaiL_> the -23 restores the network-state, the system had before suspend, the -25 the state after reboot
<KaiL_> uhm.. or not
<Symmetria> lo all
<crimsun_> what's the config of said machines? 2-/4-/8-/16-+ way? how much RAM?
<Symmetria> 4gigs of RAM 
<Symmetria> dual xeon cpu's at the moment
<Symmetria> dual e1000 gigE nics
<Symmetria> vlans configured on eth1 
<Symmetria> MTU on eth1 is 9000
<Symmetria> (due to iSCSI)
<Symmetria> MTU on eth0 is normal (1500)
<Symmetria> server is running a rather busy webserver and an ftp server, as well as doing a lot of rsyncing 
<Symmetria> traffic through eth0 is relatively low (60 odd mbit?) traffic through eth1 regularly pushes 600+mbit
<jbailey> BenC: Your daily snapshot with the new udev seems to generally work except for atheros wifi, which I suspect is lrm love.
<jbailey> But the rest of it smells good.
<crimsun_> Symmetria: and these symptoms appear with the latest 2.6.15-25.43 server kernel?
<Symmetria> crimsun, running latest 2.6.16 straight off kernel.org 
<crimsun_> oh...
<Symmetria> tried it under various distributions as well, but right now, asking everyone I can find who is into linux kernel development because so far *NO ONE* has been able to help me 
<crimsun_> erm, can't really help there. (I don't know the network code; you might want to ping BenC for that)
<crimsun_> Symmetria: have you addressed your question to the netdev list?
<jbailey> That type of mismatch to me sounds like IRQ fuckage.
<Symmetria> crimsun where is the netdev list :) I will in about 3 minutes if you can point me to it
<jbailey> (technical term)
<jbailey> Make sure that there isn't any sharing going on.
<Symmetria> http://www.spinics.net/lists/netdev/msg05485.html <=== that was the one patch that was reported
<Symmetria> but when I tried that patch, it didnt fix it
<Symmetria> (though that patch is applied)
<crimsun_> Symmetria: that is the netdev list :)
<crimsun_> linux-netdev
<Symmetria> crimsun_ heh, where do I find subscribe details for that list 
<crimsun_> Symmetria: http://vger.kernel.org/vger-lists.html
<Symmetria> heh I just hope I find a fix fairly soon, about to put in another *MONSTER* system and am gonna be forced to go fbsd if I cant find a fix :(
<crimsun_> Symmetria: these channels are fairly Ubuntu-specific, so unless the symptoms are reproducible in the kernels of the supported stable releases, I'm not sure what to tell ya
<Symmetria> heh next system is gonna be insane 
<Symmetria> quad xeon dual core hyper threading per core with 16gigs of ram 
<Symmetria> (netflow stats processing is a bitch)
<Symmetria> anyway thanks for the help
<Symmetria> gonna go sort out some other things in the mean time, need to get my ubuntu cd mirror running (that box Im having a problem with btw, is www.mirror.ac.za)
<Symmetria> which Im hoping will be an official ubuntu mirror soon :p
<mdke> anyone got any idea how I can discover why my laptop doesn't resume from suspend under the -25 kernel?
<mdke> (dapper)
<alex_joni> hello, just got an update on dapper for 2.6.15-25 (is it very different from 23? I am running a custom kernel based on 23, would it make sense to redo it on 25?)
<makx> alex_joni: custom kernels don't scale
<alex_joni> makx: this is just the default kernel with a RTAI patch, and ACPI & APM turned off
<makx> alex_joni : in doubt follow the git commits ;)
<alex_joni> makx: no simple changelog somewhere? :)
<crimsun_> alex_joni: the simple one is in git's debian/changelog
<crimsun_> alex_joni: the more verbose one is also in git
<alex_joni> crimsun_: thanks.. googling for it
<crimsun_> alex_joni: http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=summary
<crimsun_> alex_joni: sorry, that's dev. You want ubuntu-dapper
<alex_joni> aii.. thanks a bunch
<alex_joni> crimsun_: I don't see any security fixes, so I won't bother redoing it.. thanks again
<zul> hey
#ubuntu-kernel 2006-06-17
<zul> BenC: ping
<crimsun_> there's a fairly serious regression in -25.43 regarding resume from suspend-to-RAM; compiling & testing a local fix
<zul> hmmmm?
<crimsun_> #50031
<zul> thats not good
<crimsun_> I'm fairly certain it's due to borked ordering in drivers/scsi/libata-core.c::ata_device_resume()
<crimsun_> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=blobdiff;h=4b23a037222ea29396a4cbf55db2cce7d02572c9;hp=e3b92013b986e8cef87bc53947b4254ae95b51e8;hb=4662bde2ba780e63992926a88f556bde086820a1;f=drivers/scsi/libata-core.c  exacerbates it
<zul> crud 
<zul> ls
<zul> i dont think anyone is awake
* crimsun_ pushes his computer a bit 
<jbailey> Are there matching l-r-m pieces for the snapshots?
<crimsun_> there don't appear to be [yet] 
<jbailey> crimsun_: 'k.  Wasn't sure if I was missing something obvious, thanks.
<benje> hello
<dem> hello, anyone awake?
<crimsun_> dem: somewhat, yes
<dem> i'm trying to figure out what's going on with ipw3945 in the ubuntu 2.6.17 kernel
<fabbione> dem: not all drivers from dapper .15 have been ported to .17
<fabbione> 2 options: seat and wait, make the porting and post the patch for benc :)
<dem> because in KConfig it depends 80211_1_1_3 (or something like that) instead of 80211 (since that stuff has been merged)
<dem> well with my new laptop i got to go to 2.6.17 since it was laptop mode for sata drives
<dem> otherwise i get like 2 hours battery life
<fabbione> dem: as i said.. seat and wait or send a patch to fix it. edgy is not supported
<dem> i'm acctualy trying to fix it now, and right now i'm trying to figure out where from /sbin/ipw3945d-2.6.* comes from exactly (which source package)
<dem> and i'm not really familiar with the ubuntu way of building kernels, so i guess i'm a little confused
<fabbione> dem: i suggest you wait for benc to show up
<fabbione> he is actually crossing the ocean on an intercontinental flight
<crimsun_> dem: 80211_1_1_3 is obsoleted; it was a hack for his 2.6.15 tree and was supposedly ripped out of his 2.6.17 tree. He probably just hasn't fixed KConfig yet
<dem> is there a begining to restricted-modules for 2.6.17 yet or no?
<fabbione> yeah it will happen monday or tuesday
<fabbione> lrm maintainer and kernel maintainer will be sharing the same room for a week
<dem> is the lrm mailing list?
<fabbione> lrm -> linux-restricted-modules
<dem> i know, i was wondering if there is a mailing list
<dem> or way to get in touch with those people
<fabbione> kernel-team@lists.ubuntu.com
<fabbione> you need to subscribe otherwise posting is not allowed
<fabbione> but none of them will answer till monday
<fabbione> they are both on intercontinental flights
<alex_joni> fabbione: both?
<fabbione> alex_joni: yes
<fabbione> they are all heading to Paris for the Ubuntu Developer Summit
<fabbione> all other than me
<fabbione> but that's another story
<alex_joni> fabbione: sounds like you're sorry for beeing left home.. :)
<fabbione> alex_joni: benc from US and infinity from Australia
<fabbione> alex_joni: i haven't been left home.. i decided to stay home for good reasons, but i will still miss the fun to meet with the others
<alex_joni> fabbione: I know, was just joking..
<alex_joni> sorry ;)
<fabbione> :)
<fabbione> no problem
<fabbione> i am not offended or anything
<alex_joni> fabbione: we (#emc) had a nice event like that too, and I couldn't join it
<alex_joni> fabbione: so I know how it is.. luckily there's IRC
<fabbione> eheh
<fabbione> ok
<fabbione> time to cook dinner
<fabbione> later
<crimsun_> bye fabbione 
<zul> hey..
<zul> fabbione what is happening?!!? 1-1 ;)
<zul> crimsun: i was wondering if that ec.c patch is causing all the shutdown problems
<crimsun> zul: yeah, that's where I stopped troubleshooting at 6:30 AM
<crimsun> oh good lord, pasting dmesg and lspci as inline comments != readable bug report
<zul> oh yes..
#ubuntu-kernel 2006-06-18
<zul> hola
<zul> hola
<zul> hmmm....looks like 2.6.17 was released an hour ago
<dem> it's got ich7 fixes for sleep; yay
<bernard_> ich7 fixes as in the sata resume issue? or is that an ubuntu special?
<fhbeat> What hte hell is ubantu?
<alex_joni> fhbeat: just a misspelling
#ubuntu-kernel 2007-06-11
<kraut> moin
<Keybuk> what do you guys know about the RedHat audit system?
<zul> morning
<Nafallo> morning zul :-)
<zul> BenC: when is the next kernel upload?
<heno> BenC: ping
<BenC> zul: maybe this week
<BenC> heno: be back in about 20 minutes
<heno> BenC: ok, cheers
<jmg> wheres the best place to look for someone that knows acpi? i managed to reenable my wireless by booting into windows but i really want to fix this bug.
<jmg> The windows is in chinese, too, so I cant read it.
<jmg> Is there any app at all to snipe keycodes from windows?
<zul> uh...this is totally offtopic
<jmg> im trying to fix the wireless switch under linux.
<jmg> i t doesnt have a hardswitch
<jmg> https://answers.beta.launchpad.net/ubuntu/+question/1087 <- similar to this
<jmg> fixed for acer, not for asus
<BenC> jmg: test gutsy, it has rfkill support in it
<zul> BenC: fyi xen-3.1 and 2.6.22-rc4 should be ready this week
<BenC> heno: replying to your email
<BenC> zul: sweet
<zul> BenC: its a umm....suse fork ;)
<jmg> BenC: gutsy killed it.
<BenC> jmg: need more info than that
<jmg> BenC: upgrading to gutsy was what stopped the wireless
<BenC> what kind of wireless?
<jmg> ipw
<BenC> there are 3 kinds of ipw
<BenC> need more info rather than less
<jmg> hang on
<jmg> booting laptop now
<jmg> it's offline
<jmg> ipw2200
<jmg> how do i use rfkill?
<BenC> Make sure you have linux-ubuntu-modules-2.6.22-6-generic installed
<jmg> ii
<BenC> then check dmesg
<jmg> 2.6.22-6-generic 2.6.22-6.11
<jmg> i did.
<BenC> did it say anything about it?
<jmg> it told me "Kill switch enabled" until i booted windows
<jmg> nothing about rfkill
<BenC> does wireless not even get detected, is it detected and just not working, does it scan, does it associate?
<BenC> sudo modprobe rfkill
<BenC> see if that helps
<jmg> detected bok
<jmg> modprobe rfkill has no effect
<jmg> i have asus_acpi installed
<BenC> sudo modprobe rfkill-input
<jmg> no effect
<BenC> are you trying to hit the kill switch and see if it enables it?
<jmg> yeah
<BenC> what sort of switch is it, slider, click button?
<jmg> fn-f2
<BenC> is the wireless light coming on at all?
<jmg> it's on, because i went into windows and turned it on
<jmg> i'd like to know how ubuntu managed to turn it off in the first place
<jmg> oh
<BenC> Ok, file a bug and provide all this info in it please
<jmg> it turned off
<jmg> but i cant turn it back on
<jmg> will try acpi_listen and file a bug
<BenC> ubuntu doesn't turn it off, it's enabled via software
<jmg> rfkill
<BenC> or acpi workarounds like asus_acpi, tosh_acpi, thinkpad_acpi, etc...
<BenC> Mark the bug as a regression too, please
<BenC> lspci -vv, dmesg, and details from this discussion in the bug report, please
<zul> brb need to rebooty
<jmg> rgr
<jmg> what package should I file it against?
<jmg> BenC: ^
<BenC> linux-source-2.6.22
<jmg> augh, gutsy firefox keeps crashing on launchpad bugs
<jmg> oh wait 
<zul> *cough* Linux lisa 2.6.22-rc4-xen #1 SMP Mon Jun 11 08:27:51 EDT 2007 i686 GNU/Linux *cough*
<jmg> :)
<jmg> thx chuck
<calc> BenC: sorry to interrupt, but is there a known issue with intel 3945 on gutsy?
<BenC> calc: working for me
<calc> BenC: if not i need to file a bug about it not working (unless it recently was fixed)
<calc> BenC: ok, i'll look into it later today
<calc> for me it loaded the driver, etc but would never connect to an AP
<BenC> calc: it's worked for me throughout gutsy...could you make sure you have linux-ubuntu-modules-2.6.22-6-generic installed and linux-restricted-modules-2.6.22-6-generic?
<calc> i went back to feisty and it worked fine
<calc> ok
<BenC> jmg: PLEASE, do not paste things like dmesg and lspci in comments. We have a feature called attachments for a reason :)
<BenC> jmg: can you edit the description for the bug, removing the lspci and dmesg from it, and attaching them separately?
<mikmorg> hi
<mikmorg> could anyone tell me what the last number in the Ubuntu kernel version means? ie. 2.6.20-15.27-generic (what is '27' vs '26'?)
<Nafallo> ABI
<mikmorg> ok
<mikmorg> thanks
<Nafallo> ehrm. no
<Nafallo> 15 is ABI
<Nafallo> 27 is version
<Nafallo> or "upload"
<mikmorg> aha
<mikmorg> if i were to compile a module against 2.6.20-15.26-generic, and use it on 2.6.20-15.27-generic, would it always work?
<mikmorg> ie. does the version affect kernel modules?
<zul> it shouldnt
<mikmorg> what exactly does it affect, then?
<zul> it affects the abi since if the abi changes then stuff like lrm gets out of sync
<Nafallo> zul: ABI is 15 in both cases?
<mjg59> mikmorg: The .27 affects nothing. It's just the 27th version of 2.6.20 uploaded.
<mikmorg> mjg59: thanks - The reason I ask is for the sake of DKMS. I need to know if I can use the headers for 2.6.20-15.X to build for 2.6.20-15.Y (where Y > X)
<mikmorg> So it sounds like that is the case.
<mjg59> Should be, yes
<mikmorg> mdomsch: are you reading this?
<mdomsch> good day
<mdomsch> zul, but on 'apt-get upgrade'
<mdomsch> when it goes from kernel 2.6.20-15.X to 2.6.20-15.X+delta
<mdomsch> doesn't /lib/modules/2.6.20-15-generic get overwritten?
<mdomsch> or is there a directory, maybe 'volatile', under there, that doesn't?
<mdomsch> no, can't use volatile, it's a tmpfs
<mikmorg> how about 'ubuntu'?
<wuzzy79> hello all, im a linux newbie and need help
<wuzzy79> i have configured ubunto to boot live from a memory key, but now need to slim it down alot... i only need run level 3 with command prompt for a few hardware comparison commands
<wuzzy79> is anyone able to help me with this...
<wuzzy79> can anyone tell me how to set the default boot to run level 3 only?
<mkrufky> hey guys
<mkrufky> i filed bug #90723 on launchpad.net over three months ago ....   AND i provided the solution.  can we get some action on this?
<mkrufky> it's just missing "dvb-usb-bluebird-01.fw" firmware, and it is freely distributable by anyone
<mkrufky> this is a bug which has been present ever since 2.6.15
<lamont> BenC: did the module.lds fix get in yet?
<BenC> it's not in the repo yet, no
<lamont> pretty please?
<lamont> I don't want to roll my own archive just to test-build debian-installer... :-(
<lamont> or rather, eta to upload with the fix???
<BenC> should be this week easily
<BenC> as early as tomorrow
<lamont> woot
<lamont> if you could be so kind as to poke here me once it's uploaded, that'd be wonderful.
<lamont> oh, and the modules patch too....
* lamont heads for the office
<BenC> lamont: sure thing
<calc> lamont: hi
<lamont> calc: hi
<jmg> BenC: rgr!
<jmg> BenC: done :)
#ubuntu-kernel 2007-06-12
<BenC> jmg: thanks
* lamont wonders why there isn't a 'linux-ubuntu-modules-generic' to go with all the other linux-*-generic metas
<superm1> Hi guys.  I have been encountering kernel oops' consistently on the current x86_64 system.  I wanted to submit a useful bug report with the oops, but it appears to be an oops during scheduling and isn't written out to disk.  I am going to set up a serial console to capture the entire thing, is there anything else that would be useful to do, say install linux-image-debug-* or anything like that?
<kraut> moin
<zul> morning
* BenC welcomes amitk to his first day on the kernel team
* amitk waves
<Nafallo> amitk: welcome :-)
<thully> Hi - I've found an issue with the appletouch kernel modules (macbook trackpad) - for which I've found a temporary workaround...
<thully> the issue is that the appletouch module doesn't let you change the mouse pointer acceleration, UNLESS you do a rmmod appletouch and modprobe appletouch
<thully> then it's good until you restart X
<zul> BenC: ping
<BenC> zul: hey
<zul> email sent :)
<BenC> cool
<xhaker> Hi all
<xhaker> any of you acquainted with clocksource unstable kernel messages? 
<xhaker> I think it's related to dynamic ticks feature that got into the kernel at 21
<mjg59> If it's just that the TSC is unstable, that's normal
<mjg59> It's from the high-precision timer framework, not dynamic ticks
<xhaker> oh.. then it might not be that that is causing my computer to pause booting
<xhaker> i've searched the forums but didn't find any info on this problem
<xhaker> gusty boot pauses and continues if any input is given.. like touching the touchpad.. or pressing any key
<xhaker> s/gusty/gutsy
<Amaranth> are you sure it's not just trying to setup non-existing interfaces from /etc/network/interfaces?
<Amaranth> i had a 2 minute pause in feisty because of that
<xhaker> Amaranth, howdy! it's not that
<ivoks> mjg59: there's one easy-to-fix bug in acpi-support
<xhaker> it pauses several times
<xhaker> if I have my usb mouse connected it doesn't pause
<xhaker> i figured a optical mouse generates input events always
<xhaker> an*
<Amaranth> xhaker: it shouldn't
<xhaker> you know how /dev/urandom or /dev/random generates numbers based on the hardware signals
<xhaker> i think the boot is needing to be fed with signals too
<xhaker> pretty weird yes
<xhaker> but that's the only explanation i can find
<xhaker> it's not only me with the problem too
<xhaker> oh my engrish!
<xhaker> option idle=poll makes the computer boot at normal speed
<xhaker> might have to do with new udev :D
<xhaker> mjg59, what do you think?
<mjg59> Yes, that sounds like it might be a problem with dynamic ticks
<mjg59> But it's unrelated to unstable clocksource messages
<xhaker> I was reading too much into it
<xhaker> fedora 7 install was stalling too (pausing) but clocksource=acpi_pm solved that
<xhaker> i don't think it's important.. but it might be to somebody
<xhaker> I'm in a dual core laptop. k8 
#ubuntu-kernel 2007-06-13
<spirit_from_z> Hi everybody! Is it allowed to discuss driver development here? Or is there other channels for this?
<kylem> #kernelnewbies is usually a better bet unless it applies directly to ubuntu.
<spirit_from_z> Cool. Thanks kylem
<kylem> np.
* macd foo
<jmg> BenC: bug updated
<jmg> is there a companion program to acpi_listen to try and simulate an event?
<jmg> is that acpi_fakekey?
<jmg> its undocumented
<RAOF> Hi.  I'm working on bug #119254, packaging a new upstream KVM.  Since the kernel team is the maintainer of the kvm package, I thought I'd pop in and ask if there's anything special that needs to be done for it.
<BenC> RAOF: Is the new upstream coming from debian?
<BenC> RAOF: we diverged a lot from debian last release and I'd like to avoid doing they further
<RAOF> BenC: It's not coming from debian, but I was going to merge in the debian changes.  The latest upstream is 28, the latest debian is 18.  I don't think 18 works on 2.6.22, but I haven't actually tried.  I probably should :)
<BenC> talk to the debian maintainer
<BenC> he's very keen on us working together
<RAOF> Ok, I'll go for it.
<RAOF> We don't actually use kvm-source to build a kernel module, do we?  We use the kvm module shipped in the vanilla kernel?
<BenC> yeah
<BenC> I mean, yes, we use the kernel module, not kvm-source
<RAOF> Good.  I'll fire off an email to the Debain maintainer.
<kraut> moin
<fabbione> BenC: scsi-fc transport || (lpfc && qla2xxxx) are broken
<fabbione> badly :)
<doko> BenC, kylem: ping
<zul> sweeet...
<zul> xen-hypervisor-3.1-i386_3.1.0-0ubuntu1_i386.deb
<BenC> doko: yo
<Nafallo> nice :-)
<BenC> mjg59: your account on zinc.kernel.org is setup
<BenC> lamont: same for you
<BenC> err, zinc.ubuntu.com I mean
<lamont> Woto!
<lamont> woot, even
<lamont> BenC: I know that there are some hppa patches flying around for 2.6.22 that'll make it actually build.. Hopefully those will come down from k.o before I get to actually needing them.
<zul> BenC: ping can we update e1000 to the sourceforge version it has support for the ethernet card in #119337
<BenC> zul: we will be, kyle will be updating it in lum
<BlueDevil> hello, any chance we'll get a desktop kernel with HIGHMEM 64GB support?
<crimsun> you may wish to enumerate your case more explicitly.
<BlueDevil> i have a dekstop core2duo/asus p5b deluxe/4GB ram; in the bios memory remapping needs to be enabled for the system to see all the memory
<BlueDevil> the cool part begins when the bios configures a hole in the 2gb-4gb memory range and the physical 2gb-4gb is remapped to 4gb-6gb
<BlueDevil> so the standard ubuntu kernel (with 4gb support) sees 2gb of real memory and 2gb of nothing (reserved)
<BlueDevil> which in fact means that only 2 GB are really usable of the 4GB installed in the system
<BlueDevil> when booting with a bigiron kernel everything is fine
#ubuntu-kernel 2007-06-14
<calc> BlueDevil: use 64bit kernel?
<calc> BlueDevil: core2duo is 64bit btw
<AndyP> are there plans to have the rt2500 wireless module in the gutsy linux-ubuntu-modules-* package? i noticed it is included in feisty's linux-image-* package but seems to have been dropped for gutsy
<BlueDevil> calc, i can't use 64bit kernel, sorry
<BlueDevil> i need to be able to run flash natively :(
<jmg> is there an easy way to rebuild the gutsy kernel and modules including restricted for feisty?
<jmg> also including nvidia
<BlueDevil> jmg: an way way? :) i'm still trying to rebuild the feisty restricted modules for feisty :)
<BlueDevil> *easy way
<jmg> BlueDevil: ouch
<BlueDevil> i think it's meant to be a world of pain :)
<n2diy> Do dual core CPUs use SMP kernels?
<BlueDevil> yes
<n2diy> Thanks.
<BlueDevil> yw
<BlueDevil> jmg: did you find a "proper" way to rebuild the kernel?
<jmg> jmg: no
<BlueDevil> this is the part where i start missing gentoo
<jmg> BlueDevil: no it isnt
<BlueDevil> it soon stops when i'm reminded of compiling X and kde
<jmg> haha
<jmg> my alternative is to find and backport the changes that fixed 117282 in gutsy
<jmg> but i have no idea what they are
<calc> easy to rebuild the kernel
<crimsun> https://wiki.ubuntu.com/KernelCustomBuild is the template
<calc> apt-get source linux-source-foo
<jmg> and modules?
<calc> er do what crimsun says, he is smarter than me ;)
<crimsun> don't worry, what calc said is covered in https://wiki.ubuntu.com/KernelCustomBuild
<calc> heh :)
<calc> bbl, dinner
<BlueDevil> calc: bob apetit
<BlueDevil> crimsun: *bon
<BlueDevil> man i'm tired
<crimsun> right, to chris, not daniel. :)
<BlueDevil> crimsun: can you walk me through the build?
<crimsun> BlueDevil: it's outlined fairly well at the above url I've spammed twice now.
<BlueDevil> didn't work for me otherwise i wouldn't have asked
<BlueDevil> maybe i did something wrong
<crimsun> it works with 2.6.22-6.13
<BlueDevil> hmm, the latest i had was 2.6.20-16
<crimsun> 2.6.20-16.29?
<BlueDevil> yes
<crimsun> I'm referring to gutsy's source, not feisty's source, but they both work.
<BlueDevil> make: *** No rule to make target `updateconfigs'.  Stop.
<BlueDevil> i get that when i run debian/rules updateconfigs
<BlueDevil> i get the same soft binary-debs
<BlueDevil> s/soft/for/
<zul> BenC: cool ok
<kraut> moin
<Nafallo> morgon
<BlueDevil> morning
<BlueDevil> i really need help with a kernel rebuild on feisty
<elementz> hallo allerseitsw
<BlueDevil> c'mon people, anyone alive?
<Nafallo> .
<BlueDevil> hey
<BlueDevil> can you help me with a kernel build?
<Nafallo> probably not. I'm busy buying harddrives :-)
<BlueDevil> i see
<mjg59> BlueDevil: This really isn't the right place to ask
<BlueDevil> which is the right place?
<mjg59> #ubuntu
<BlueDevil> i've been asking everywhere
<BlueDevil> they don't know
<mjg59> That doesn't make this the right place
<BlueDevil> the damn build is BROKEN
<BlueDevil> or i am an idiot
<BlueDevil> it's one or the other
<BlueDevil> i've been referred to https://wiki.ubuntu.com/KernelCustomBuild 
<BlueDevil> the build targets in that document are invalid
<BlueDevil> it seems that nobody cares
<BlueDevil> great community btw
<BlueDevil> i will highly recommend it
* chmj giggles
<shawarma> BlueDevil: It's interesting that you've been asking for almost 4 hours, but still noone has heard what your problem is (apart from "OMG, THE BUILD IS BROKEN", which does not help much).
<shawarma> BlueDevil: If you just go ahead and ask your question, we can either answer it or tell you where to go to get help. Right now, we have absolutely no information about what your problem is.
<BlueDevil> shawarma: sorry, i've been explaining it for the last two days on all ubuntu channels :)
<BlueDevil> [02:56]  <BlueDevil> make: *** No rule to make target `updateconfigs'.  Stop.
<BlueDevil> [02:57]  <BlueDevil> i get that when i run debian/rules updateconfigs
<BlueDevil> initially i asked about the proper way to build the kernel, i was referred to https://wiki.ubuntu.com/KernelCustomBuild
<BlueDevil> following the steps i get errors
<shawarma> Where'd you get the source from?
<BlueDevil> apt-get source linux-source
<BlueDevil> it got me linux-meta
<BlueDevil> i also tried with apt-get source linux-source-2.6.20
<BlueDevil> which gets me the source
<BlueDevil> .29 i believe
<shawarma> Great. Now anyone who knows about this actually has some info to work from. All *I* can say is that it works for me, but I'm not a kernel dude, I just like to hang out here. :)
<BlueDevil> so actually doing debian/rules binary-debs works for you?
<zul> *sigh* what happens when you run the command?
<BlueDevil> i get: make: *** No rule to make target `updateconfigs'.  Stop.
<BlueDevil> sorry, that's from debian/rules updateconfigs
<zul> skip that step
<BlueDevil> make: *** No rule to make target `binary-debs'.  Stop.
<zul> well you are missing something
<BlueDevil> what :)
<BlueDevil> ?
<BlueDevil> i tried the alternate build method, it tries to build a version with .3ubuntu1 in the name
<BlueDevil> in the Makefile EXTRAVERSION is defined to that
<BlueDevil> i remove that and run make-kpkg --rootcmd fakeroot --initrd --append-to-version=-c2duo-64gb kernel-image kernel-headers
<BlueDevil> compiles for a while and then stops with: dpkg-gencontrol: error: package linux-image-2.6.20-c2duo-64gb not in control info
<BlueDevil> can i get linux-restricted-modules with git?
<crimsun> sure.
<BlueDevil> can you tell me how?
<crimsun> http://kernel.ubuntu.com/git
<BlueDevil> thanks
<BlueDevil> they're only for gutsy, right?
<crimsun> that would be a very observant guess.
<crimsun> ubuntu/ubuntu-gutsy-lrm.git <--
<BenC> crimsun: ping
<crimsun> BenC: pong
<BenC> crimsun: I have ids for a couple of audio devices that are detected in feisty, but aren't actually creating sound
<BenC> crimsun: if I get those ids and codecs to you, would you be able to find out what patches we need to support them in 2.6.20?
<crimsun> BenC: I certainly will attempt
<BenC> crimsun@ubuntu.com?
<crimsun> yes, and please CC: crimsunkg at yahoo
<calc> one is Realtek ALC268 ;)
<crimsun> I don't have access to the former until Saturday night
<BenC> crimsun: sent
<crimsun> BenC: thanks
<BenC> crimsun: no, thank you :)
<crimsun> BenC: actually need the SSIDs for those (grep -A1)
* Starting logfile irclogs/ubuntu-kernel.log
#ubuntu-kernel 2007-06-15
<medberry> What's the ideal (or canonical) way to apt-get my kernel source and rebuild it (with a two line .config change).  The google hits I'm finding searching for that are out of date or just plain wrong.
<medberry> I'll need the i686 and any modules/initrds and I'm running an up to date feisty
* medberry suspects this issue is already fixed in gutsy kernels and may try that but wants to be able to build a kernel the ubuntu-way regardless
* medberry reads the /topic and decides to follow the friendly suggestions therein
* medberry finds https://wiki.ubuntu.com/KernelMaintenanceFeisty
<kraut> moin
<AndyP> hi kernel folks, is bug #120297 likely to be fixed for 7.10?
<fabbione> AndyP: before filing that kind of bugs and asking for a fix you should really read the kernel devel timeline
<fabbione> not all drivers can be re-added right away during the beginning of the devel phase
<fabbione> but it's guaranteed that they will come back as soon as possible
<AndyP> fabbione: ok that's understandable, thanks, where is the timeline?
<fabbione> AndyP: https://wiki.ubuntu.com/GutsyReleaseSchedule
<fabbione> stuff needs to be all there as soon as possible before beta
<AndyP> fabbione: oh, the release schedule, ok thanks again 
<fabbione> but they never had to stretch drivers that far in time
<fabbione> usually it happens way earlier
<AndyP> right, ok
<AndyP> i'll use my ethernet cable a while longer then :)
<JanC> there is also https://wiki.ubuntu.com/KernelTeam/Roadmap :)
<AndyP> JanC: thanks :)
<TheMuso> /c
<TheMuso> gah
<zul> BenC: has there been any though on adding vserver I think there has been a couple of requests
<BenC> zul: like many of the virt implementations, request != maintainer
<zul> yeah yeh :)
<BenC> VMI, xen and openvz (hopefully) will have someone behind it making sure it works and that we can go to them for help when we need it
<BenC> we don't have that for vserver that I know of
<zul> ill try playing with it this weekend who knows
<BenC> amitk: just added you to ubuntu-kernel-team, expect lots of email
* amitk to BenC: Tell me something new :)
<BenC> crimsun: sent you codec for the sigmatel chip
<slmnhq> Hi, On an SMP machine is it normal that the LOC interrupt rate on one CPU differs from anothers?
<slmnhq> On my dual core machine, CPU0's LOC rate is about 18677 Hz and on CPU1 it's 1000 Hz
<jwendell> Hi, folks
<jwendell> does anyone could verify bug 104155 ?
<mkrufky> jwendell: is the drive unmounted when you try to eject it?
<jwendell> mkrufky, yep
<mkrufky> ok, then i have nothing to offer :-P
<jwendell> if it's umounted, it's ejected normally
<mkrufky> oh!  then i do
<mkrufky> so you just have to unmount it before you try to eject it
<mkrufky> IMHO, if previous code allowed you to eject without first unmounting, then THAT was a bug, and now its fixed
<jwendell> mkrufky, but it worked in edgy :)
<mkrufky> sounds like edgy is bugged, then
<jwendell> hehe
<mkrufky> edgy is 2.6.17.y, right
<mkrufky> ?
<jwendell> right
<mkrufky> i am not an authority here -- i am just being nosy...  but, anyway, i think your bug #104155 is a feature and not a bug, and that the previous behavior was the bug -- you are betetr off now
<jwendell> mkrufky, i got the point, but we are talking about read only media
<mkrufky> i think perhaps there is a different way to approach your issue
<jwendell> mkrufky, anyway, if i press the eject button on drive, it ejects normally
<jwendell> even when it's mounted
<mkrufky> maybe, what you want is for Fn+F10 to handle the umount command for you, and then eject
<mkrufky> so the problem is that the umount step is missing
<jwendell> mkrufky, i want the same behavior as if i press the eject button on drive
<mkrufky> in which case, this is not really a kernel issue, so i think this might not be the right place to ask about it :-/
<mkrufky> if you press eject, does the drive unmount AND eject ?  (i assume yes)
<jwendell> yes
<mkrufky> ok, so that's it ... your Fn+F10 macro handler,  or whatever it is, is neglecting to umount before trying to eject
<jwendell> yep
<jwendell> where do i fix that?
<jwendell> do you know?
<mkrufky> i dont know
<mkrufky> but your bug is files against the linux-source-2.6.20 , and probably needs to be re-classed if you want a useful response... (i dont know what it SHOULD be files against, but they can probably tell you in #ubuntu , or whatever other ubuntu support room)
<mkrufky> s/files/fileD
<jwendell> mkrufky, ok, i'll search a bit more
<jwendell> thanks
<mkrufky> you're welcome, jwendell
<afie> Any proper fixes for snd_intel_hda yet?
<afie> Ubuntu of all distros should be the _last_ to do something like this. >_>
<afie> Break sound after an update :-\
<BenC> kylem: do you know if we support Intel GMA3000?
<BenC> kylem: in dapper that is
<kylem> nope, it's way too new.
<kylem> GMA3000 is i965.
<BenC> kylem: ok, thanks
<bdmurray> rtg: ping
<crimsun> BenC: ok, thanks. I'm still needing the SSID from `lspci -nv|grep 0403 -A1`.
<BenC> crimsun: Ah, ok
#ubuntu-kernel 2007-06-16
<Nafallo> [about sabdfl's mail to -announce] : when did ralink start to make wired interfaces?
<fabbione> Nafallo: i guess that's really subjective... the mail to announce is exactly to gather a poll of information
<fabbione> and make those number more objective collecting user experience
<fabbione> you need to start somewhere :)
<Nafallo> fabbione: yea. deleted the "5?" for NICs after checking ralinktech.com :-)
<Nafallo> ralink only does wireless
<fabbione> well ok..as the email says.. fix typos.. discuss.. it's open discussion
<fabbione> it's not authoritative
<fabbione> read the email again..
<Nafallo> yea :-)
<Nafallo> I just was a bit confused about them doing NICs, which they aren't, so should count as a typo ;-)
<Nafallo> maybe we should bounce ralink from "5?" for wireless... they DO have GPL'd drivers and seems to send specs to people when asked to.
<kraut> moin
<Fudge> hi
<Fudge> hi if anyone is around, is this correct channel to enquire abotu different kernels and current development of existing ones?
<lamont> BenC: you around?
<BenC> lamont: only by accident :)
<lamont> heh.
<lamont> how long after a commit in linus' tree should one expect to see bits in ubuntu?
<lamont> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aba297927d1d558c7a94548135133bdf9172708a would be lovely
<mjg59> Small number of days
<lamont> mjg59: very small
<lamont> I was shooting for an ETA, not for a "it's there already." :-)
<Lure> mjg59: btw, does it make sense to report supend/hibernate regressions on gutsy at this point?
<mjg59> Lure: Yeah
<mjg59> Ideally we'll be able to work them out before 2.6.22
<Lure> mjg59: ok will do - it kind of always broke for me early in dev cycle
<Lure> mjg59: and always got resolved by beta or rc
<mjg59> Better chance of it being resolved if we know about it :)
<mjg59> With luck it's something upstream knows about already
<mjg59> Which would make life easier
#ubuntu-kernel 2007-06-17
<ispiked> hi, I sent a message to the kernel mailing list about a week ago and was wondering if someone could moderate it.
* ispiked looks at BenC and lamont.
<lamont> ispiked: hrm... I suppose
<ispiked> lamont: thanks
<lamont> ispiked: what from address?
<ispiked> lamont: ispiked at gmail
<lamont> no such message - wanna resend it and I'll moderate it now?
<ispiked> kernel-team@lists.ubuntu.com, right?
<ispiked> lamont: sorry, I got sidetracked. sent the mail again.
<lamont> done
<ispiked> thanks.
<lamont> np.  and shouldn't be an issue for future mails either.
<lamont> and bedtime for me.
<vnieto> Hi
<vnieto> I have a qustion
<vnieto> can i put the kernel for sempron on my feisty?
<vnieto> ??
<BenC> that question doesn't make much sense
<vnieto> why?
<vnieto> I like optimize my ubuntu with the espeficic kernel for my processor
<BenC> there, that makes more sense
<BenC> you can install any kernel you want, but whether it works really depends more on your peripherals than the cpu
<BenC> and you really wont get much benefit from an optimized kernel, ours already has optimizations that are activated at boot for specific cpus
<BenC> you might see a 1% increase in performance, and by "see" I mean you wont notice it in practice, but might with certain benchmarks
<vnieto> I intent with: sudo apt-get install linux-k7
<vnieto> but don't do anythink
<vnieto> donwload the .deb, but grub don't see it
<BenC> linux-k7 is a meta package, and it's legacy based on when we stopped shipping k7 and 686 specific kernels in favor of a single -generic kernel
<vnieto> i see
<vnieto> then i don't can try a kernel especific
<vnieto> another question
<vnieto> can I have on my feisty direct rendering with ATI 200M?
<BenC> only with fglrx driver
<vnieto> the restricted driver?
<BenC> yes
<vnieto> but with fglrx I don't  have direc rendering, I use xgl, and this freze several times
<BenC> you can get help with that from #ubuntu, ATI's website, or wiki.ubuntu.com
<vnieto> ok tk
<gortiz> sorry, have I to ask there for a problem with the restricted drivers package?
<gortiz> under gutsy?
<gortiz> sorry for the question I solved
<johnnybuoy> hi all!
<johnnybuoy> I only have a small question about the xen kernel in feisty...
<johnnybuoy> I wanted to ask if it was normal that there was no firmware for the kernel at all, and that there are no restricted modules for it?
#ubuntu-kernel 2008-06-09
<ogra> rtg_, the -19 upload misses intel-agp on lpia
<ogra> can we get that back ? i cant start X on the classmate without it
<rtg_> ogra: I'll but amit in the morning. he did the lpia update.
<ogra> ok
<ogra> i might see him before you, thanks for the pointer
<ogra> wasnt sure thats amit alone 
 * ogra is a bt trapped between not having X (missing agp) or not having network (r8169) and locking up here and there
<rtg_> ogra: seems like its been a tough day for cmpc development.
<ogra> rtg_, well, ne HW here since today
<ogra> *new
<ogra> atom is quite cool ... i wasnt aware its SMP 
<rtg_> ogra: ah. send an email to amit so he doesn't forget that he messed up lpia.
<ogra> heh
<ogra> will do
<elmarco> hello!
#ubuntu-kernel 2008-06-10
<adc> hello, when i installed ubuntu in the beta state the delivered kernel was 2.6.24-12 this kernel works well except for wireless. all the kernel updates which are installed after upgrading do not boot, they arrived at 2.6.24-18 and they hang at the state where the init scripts do load hardware modules, sometimes at the flash disc modules and sometimes somewhere else. i know this is a development only channel but maybe someone has an idea where i 
<abogani> adc: In your shoes 1) i disabling GUI 2) remove quiet splash from GRUB menu 3) add to the same line in the GRUB menu nmi_watchdog=1 4) boot and view the screen.
<adc> i did the 2) part
<abogani> Part 3 is mandatory
<adc> so i saw that it hangs on different modules all the time. i'll try adding nmi_watchdog=1
<adc> what will nmi_watchdog=1
<adc> do_
<abogani> Check if that system hang always on the same point.
<adc> ok, i'll do this
<adc> abogani: can i tell you the results
<adc> i did reboot 4 times
<adc> first time it did hung at ricoh-mmc: main firewire funcion not found
<adc> secont time it hung at sdhci: secure digital host controller
<adc> third time it hung at mmc0: SDHCI at 0xf0401800 irq 23 DMA
<adc> and the fourth time it hung at ACPI: Battery slot [BAT1] battery present
<adc> this was with kernel xx-18
<BenC> amitk, smb_away, cking, pgraner, rtg: Just rebased ubuntu-intrepid against 2.6.26-rc5, and pushed
<BenC> just an FYI if you try to pull/merge from it
<cking> Thanks
<amitk> BenC: nice..
<BenC> amitk: wimax and marvell in lum...are they pertinent to ubuntu-intrepid anymore given that we aren't doing lpia out of this tree?
<amitk> BenC: throw'em away
#ubuntu-kernel 2008-06-11
<BenC> amitk, cking, pgraner: I'm doing a full build of linux-2.6.26 now...if all goes well, I'll have an upload shortly after
<cking> BenC: excellent
<pgraner> BenC: sweet...
<BenC> I've tested the squashfs and aufs drivers and they appear to work well (despite having to munge around vfs changes for squashfs)
<BenC> so that's enough to support a livecd build
<cking> BenC: I'd like to add in dm-loop into the ubuntu tree in 2.6.26 if that's OK 
<BenC> cking: as long as it doesn't require touching anything outside of ubuntu/ I see no problem with that
<BenC> what's with all the dm-* replacements for normal things
<cking> BenC: it's a clean patch - no tainting the tree - (unlike stuff like unionfs)
<BenC> doing kernel builds under this new kernel is much better than under hardy
<BenC> my screen doesn't jerk when I rotate my cube
 * BenC makes the channel dizzy by demonstrating cube spinning
<BenC> guess I'll do lrm after this
<cking> BenC: rotating cube while compile is cool, but does audio work well when compiling too? :-)
<BenC> cking: youtube video/sound playback works jitter/stutter free...so I declare success :)
<lifeless> BenC: scheduler changes?
<cking> BenC: Well done to Ingo Molnar then!
<BenC> I think it's the change from user_sched to group_sched
<BenC> and I'm even doing an -j3 compile with no ccache, so it's not like I have any free procs
<mpt> Can anyone here reply to Sebastien Salmon in ubuntu-devel-discuss@?
<mpt> It looks like he has a kernel fix that should go upstream, but I've no idea how that works
<rtg> mpt: how about an LP bug report?
<mpt> ah, good idea
<mpt> I should have thought of that :-)
<rtg> mpt: what is the issue regarding?
<mpt> rtg, Sidewinder joystick support
<rtg> mpt: that seems familiar. I'm almost sure I've done something with that in the past. quirk support perhaps?
<mpt> I don't know
<mpt> anyway, thanks for the hint, I've replied
<mpt> ttfn
<qense> Can someone help me with bug https://bugs.launchpad.net/ubuntu/+source/hal/+bug/230184 ?
<qense> should I ask him to blacklist the USB modules?
<qense> (to test)
<qense> (and what's actually the function of the /etc/pm/config.d/unload_modules file?)
<smb_tp> qense|dinner: The file name is not important it's the variable set. SUSPEND_MODULES defines which modules should be removed before suspend (man pm-suspend).
<smb_tp> qense|dinner: Maybe adding the wireless controller's module would help.
<qense> smb_tp: why the wirless module?
<smb_tp> qense: since 03:00.0 was the last thing touched. Sure this might also be something after that and before the sync
<smb_tp> qense: Maybe you can ask to try https://wiki.ubuntu.com/DebuggingKernelSuspend
<smb_tp> qense: Oh, nay. This would only be useful on wakeup
<qense> it seems that the USB devices are causing all this trouble
<qense> their device number is the last one of the magic number block
<smb_tp> qense: If pm-utils supports dependend removals, maybe putting usbcore to suspend_modules might change something. Just a sec
<smb_tp> qense: usbcore might be done but isn't very good with external usb drives...
<qense> I think I should ask if there are any usb devices connected
<qense> I'll ask him to blacklist usbcore and tell me that
<smb_tp> qense: ok
<qense> thank you for your help ;)
#ubuntu-kernel 2008-06-12
<BenC> I'm trying to think of a good reason why we have a linux-source-2.6.x.deb package, but I'm having a hard time justifying it
<torkel> because people are used to it?
<BenC> used to it doesn't mean it's worth having :)
<BenC> most people assume they can use it to build the same packages we do, and that's just incorrect
<BenC> what most people want is "apt-get source linux" not "sudo apt-get install linux-source"
 * BenC fires off the 2.6.26-1.1 upload
<BenC> rtg: what was that you talk me last night, that adam said would pull in the last version?
<rtg> hang on...
<BenC> *told
<rtg> an option to dpkg-buildpkg, e.g., '-v2.6.24-18.36'
<BenC> Oh, I already knew about that
<BenC> rtg: that just sets the .changes file to include all changelog entries later than that version
<BenC> as opposed to just the current upload
<fabbione> BenC: are you killing linux-ubuntu-modules?
<fabbione> BenC: (for intrepid i mean)
<BenC> fabbione: yeah
<fabbione> ok
<fabbione> so all external modules are back into main tree?
<BenC> fabbione: yeah, pretty much
<fabbione> BenC: it's kind of astonishing that no matter what, everything always collapse again.
<fabbione> BenC: specially when we discussed that in regards of API/ABI breakage from lum
<fabbione> and i suggested to go back
<BenC> I never said going back wasn't possible
<BenC> just that we couldn't do it in hardy
<fabbione> nah there was time for hardy...
<BenC> nah, there wasn't :)
<BenC> time to do it, sure, but some one with that time, that's a different story
<fabbione> there was.. you are just too slow :P
<fabbione> that's why you have 24h/day and weekends 
<fabbione> weekends are boring without hacking :)
<BenC> lol, my weekends aren't boring, but I definitely don't spend them hacking
<BenC> you're married, your don't have time either :P
<fabbione> ahhaha
<torkel> BenC: married and with small kids you have nights to hack on :-) 
<fabbione> torkel: no you don't.. kids keep you busy
<tjaalton> especially at night..
<mnem0> what is the difference between linux-ubuntu-modules-2.6.24-18-386 and linux-ubuntu-modules-2.6.24-18-generic ??
<amitk> mnemo: the flavour. -386 is for older machines, -generic for 686+ machines
<mnemo> so I really want the latter then, for a modern machine??
<amitk> mnemo: depends on what kernel you have installed. 'apt-get install linux-image-generic' ought to take care of all dependencies, really
<mnemo> but how do I choose kernel between -i386 and -generic?
<amitk> mnemo: what is the output of 'cat /proc/version_signature'?
<mnemo> it's currently Ubuntu 2.6.24-18.32-386
<mnemo> but I think I got both installed in grub for some reason
<mnemo> and i'm more interested in general what is the difference between -i386 and -generic so I know which one to use in the future etc
<amitk> mnemo: if your processor is something released in the last 2-3 years, it is a safe bet to go with -generic.
<mnemo> yea I know -generic boots and works fine when I select it from grub
<mnemo> but is -generic faster because it's optimized for 686 or something like that?
<amitk> mnemo: yes. It will use optimizations, new instructions, etc. for newer processors.
<mnemo> okay cool
<mnemo> thanks for explaining it to me
<amitk> np
<bmm> Hi everybody. For starters, thanks for your work on the kernel. I'm desperately waiting for 2.6.25+ because of lan driver fixes, so I was looking around at the launchpad pages and wanted to mention two things: 
<bmm> 2.6.26 ia64 for intrepid has run and failed to build because of a missing: debian/rules.d/ia64.mk
<bmm> (which seems like a small mistake?)
<bmm> The kernel-team contact information link to the wiki doesn't work, see https://launchpad.net/~kernel-team on the right lower side.
<bmm> So, that's all I wanted to mention. Keep up the good work and looking forward to the new versions.
<bmm> Thanks for reading!
<mrec__> hi anyone awake?
<mrec__> https://bugs.launchpad.net/ubuntu/+bug/204578
<mrec__> it would be great if someone could integrate the driver from mcentral.de into ubuntu
#ubuntu-kernel 2008-06-13
<mkrufky> mrec__: might be a good idea for you do to a DKMS package
<mkrufky> mkrufky: and make your package remove any pre-existing em28xx
<mkrufky> oops, i meant mrec__ ^
<mkrufky> i *highly* suggest using the in-kernel dvb-core rather that installing your own... otherwise you'll break somebody else's driver
<mkrufky> i did this by using the headers in /lib/modules/`uname -r`/build/drivers/media/dvb/dvb-core/*.h
<mkrufky> ...and you can depend on their presence if you are doing a DKMS build
<apt_get> Hi
<BenC> fair warning...rebasing on -rc6 now, so I would hold off pushing anything to the repo
<BenC> rtg: -rc6 included a fix to xen/time.c...different than mine, but fixed the same problem
<BenC> so it wasn't just us
<rtg> BenC: cool. how did they fix it?
<BenC> rtg: They used iter_div_u64_rem()
<rtg> BenC: gotta go. home gain, home again, jiggety jig.
<maks_> what's the irc nick of tim gardner?
<amitk> maks_: it is 'rtg'
<maks_> ok thanks
<maks_> rtg f448b9a70cda0ed9878db485de30363f9c9db6e1 is a dup
<maks_> you'll find the same entry below in blacklist with proper desc
<maks_>  speaking of ubuntu hardy tree, as you might have guessed ;)
<maks_> hmm rtg is not here
<maks_> will repost
<pgraner> maks_: rtg is traveling today, he will be back online prob Monday
<BenC> mjg59: Do you recall this patch: hostap: send events on data interface as well as master interface
<BenC> mjg59: I'm wondering if it's still needed
<mjg59> I expect so, but haven't tested
<BenC> mjg59: is it something that should go upstream?
<mjg59> Conceivably
<mjg59> Probably best to check it with Dan Williams
<BenC> Ok
<BenC> -rw-r--r-- 1 bcollins bcollins 48234 2008-06-13 09:45 ubuntu-stuff.diff
<BenC> That our current delta against 2.6.26-rc2
<BenC> good chunk of that is vesafb modular
<BenC> err, 2.6.26-rc6
<qense> Can someone help me out a bit with bug 222703?
<qense> <ubottu> Launchpad bug 222703 in linux "Suspend fails after first time" [Undecided,Incomplete] https://launchpad.net/bugs/222703
<qense> I can't determine the cause
<qense> should I just mark it as confirmed and leave it to you, or do you want some more informaton?
<pgraner> BenC: ping
<BenC> pgraner: Yes?
<pgraner> BenC: hey, I want to work on a adding a patch and building. Specifically this one http://marc.info/?l=linux-usb&m=121080766320582&w=4
<pgraner> BenC: its upstream and I actually need it I'd like to build a custom pkg just for me. Where do we start, I can't seem to find the one page to get me started.
<munckfish> pgraner: https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<munckfish> KernelMaintenance page has a lot of good info
<munckfish> or
<munckfish> https://help.ubuntu.com/community/Kernel/Compile
<smb_tp> pgraner: If you want a patch on top of the current git in a ppa, I could push you a script as well
<kees> kirkland: (switching here) yeah, I think the problem is discussed in the bug you found
<kirkland> kees: the problem that pitti mentioned?
<kees> (95089)  yeah
<kirkland> okay, i've asked Serge Hallyn to add some comments to the bug
<kirkland> kees: in case there's something we're missing
<kees> kirkland: yeah, it wasn't entirely obvious to me, but after looking at CAP_SETPCAP, I tended to agree with pitti.
<kees> kirkland: if CONFIG_SECURITY_FILE_CAPABILITIES could operate without it, that'd be nice
<kirkland> kees: right, i think hallyn will be able to clarify what is/isn't possible
<kees> if you look at the code for where CAP_SETPCAP is defined, it is clearly ifdef'd with CONFIG_SEC.._FILE_CAP.. but I don't know why
<kirkland> kees: hallyn added some info to https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/95089
<kees> heya hallyn, thanks for the details -- this is an area I'm much less familiar with.  :)
<hallyn> np
<hallyn> i'm not quite clear on the history
<hallyn> at the start of the thread, were file capabilities enabled and cap-setpcap turned off, or was it just a regular kernel without file capabilities?
<kees> hallyn: I'm a bit unclear myself.  I think the issue is with the #ifdefs that seem to allow CAP_SETPCAP when CONFIG_SEC.._FILE_CAP..=yes
<kees> and without additional context, it seems dangerous
<hallyn> is there a gitweb site or something where i can see the current code and .configs for default builds?  I assume not, just would be kick-ass if so...
<kees> there is, yes, kernel.ubuntu.com
<mjg59> kees: Should get to your libx86 stuff next week, I've just got nv40 suspend/resume working
<mjg59> (without any libx86 stuff. Hurrah!)
<hallyn> kees: cool!  thanks.
<kees> mjg59: nice!  how does it work without need to talk to the bios??
<kees> hallyn: current hardy: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary current intrepid: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=summary
<mjg59> kees: Uses nouveau's bios table interpreter
<hallyn> kees: yes, seeing cap-setpcap enabled would set off warning bells :)  though we did try to comment it in include/linux/capability.h
<kees> mjg59: niiiice.  I'm so glad that project is coming along.
<mjg59> kees: nvidia and AMD both have tables that are used by the drivers, and just have a small x86 interpreter for it that sits in the bios
<mjg59> Execute the init table, restore a couple of magic values that would be programmed by the platform bios, run the lvds init code, restore the registers and wham!
<hallyn> kees: excellent, so I can take a look at the apparmor/caps integration.  What about .configs?  available?
<mjg59> An entirely broken console, but working X
<kees> hallyn: the configs are in the debian/configs directory
<hallyn> excellent
<kees> hallyn: though depending on build options, they are merge together.  other folks here might be more helpful in describing that, though.
<kees> hallyn: so, in comment 4, pitti is correct?
<kees> hallyn: this page may be useful for you as well, if you're going to build modified ubuntu kernels: https://help.ubuntu.com/community/Kernel/Compile
<hallyn> kees: was hoping not to build, just figure out the state of the current kernel
<hallyn> i.e. i'm afraid one or two apparmor lines may need tweaking
<kees> hallyn: that's fine -- intrepid doesn't have apparmor in it yet, I'm waiting for upstream to finish their port to the current linus tree.
<kees> hallyn: but they're quite responsive about patches
<hallyn> kees: pitti == martin pitt?  If so, he's only right if CONFIG_SECURITY_FILE_CAPABILITIES=n
<kees> hallyn: check in on oftc in #apparmor
<kees> hallyn: okay.  so if I boot a CONFIG_SECURITY_FILE_CAPABILITIES=y kernel, I should still get the same output he's showing?
<hallyn> kees: no, bc cap_setpcap should then be in root's sets
<hallyn> kees:  "debian/configs directory" -> can' tfind it, what is the url?
<kirkland> hallyn: is there a potentially security vulnerability if CONFIG_SECURITY_FILE_CAPABILITIES=n ?
<kees> hallyn: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=tree;f=debian/config;hb=HEAD
<kees> hallyn: pitti seems to be saying that have cap_setpcap in root's sets is, in itself, dangerous.
<hallyn> kees: cap_setpcap means something different if file caps are on
<hallyn> kirkland: do you mean if cap_setpcap is allowed?  yes.
<kees> ah-ha -- that's the piece that wasn't obvious to me.
<hallyn> kees: so yes it looks like apparmor would need some changes - at least for setxattr - to support file caps.  
<hallyn> I'll look at it some more next week.
<kees> hallyn: I'm sure they'd be open to it.
<kees> hallyn: okay, cool.
<hallyn> kees: where would I send a patch?
<hallyn> i guess i can just join #apparmor next week
<kees> hallyn: yeah, that's probably the best place to start
<kees> hallyn: they have some public mailing lists too, but IRC is good.  If you don't get any response, email me and I'll go ping them directly via email.
<hallyn> ok, thanks.
<kees> cool, thanks for digging into this -- I've been curious about what was needed for sane filecap support but hadn't had time to look into it.
<kirkland> kees: hallyn: hey, thanks for taking the time to connect
<dupondje> 'Collin King' happen to be here ? :)
<dupondje> somebody here that is able to include a patch into Hardy kernel ? :(
<kees> dupondje: best to open a bug report with the details and the patch
<dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235889
<dupondje> enjoy
<dupondje> :)
<kees> dupondje: looks like it's already being discussed there.  :)
<dupondje> its taking such a huge time to get solved :(
<dupondje> the patch is there
<dupondje> I tested it .. it works :(
<kees> hallyn: if you're still around, jjohansen is one of the AppArmor upstreams.
<hallyn> thanks kees
<hallyn> jjohansen: i haven't look at it enough, but i think in order for apparmor (in ubuntu) to work with filecaps, apparmor will need a few tweaks, such as calling the cap setxattr hook
<kees> dupondje: it can take time -- but it looks like it's progressing.
<jjohansen> yes, the apparmor hook needs to call cap_inode_setxattr its a fix that is pending
<infinity> dupondje: The hardy kernel is currently frozen for the 8.04.1 point release, but I suspect your patch and bug will be addressed shortly after that.
<hallyn> jjohansen: oh ok, saves me some time :)  thanks
<infinity> dupondje: I also have a patch queued for after the point release.  I realise it's frustrating, but QA processes just can't allow for last-minute changes. :/
<jjohansen> hallyn: np.
<dupondje> its a fucking deathlock :( kinda important
<dupondje> that controller is used in ALOT of servers
<infinity> dupondje: Swearing won't help much, nor will it make us delay a point release for a bug (no matter how important that bug may be to some people)
<dupondje> I know, but I just think its kinda an important bug, as its a verry common used controller in servers
<dupondje> if your server in a datacenter crashes because of it, its not that funny :)
<infinity> I never claimed it was funny.  Just that, unfortunately, we have release priorities that mean that you might have to carry a local patch/fork for a bit until after 8.04.1 is out (much like I also have to).
<dupondje> when is 8.04.1 comming out tho ?
<infinity> It's scheduled for end-of-month, barring any massive setbacks.
<infinity> Because the devel team is split between intrepid and hardy right now, the hardy point release test cycles are long and careful.
<dupondje> what they test btw ? :p
<dupondje> I just test its not working good ;)
#ubuntu-kernel 2008-06-14
<ajonat> hi! I'm building a custom kernel (based on 2.6.24-18-generic) with make-kpkg and while checking the files generated in the .deb, I see no /boot/abi-2.6.24-blahblah, so my question is what's this file for?
<ajonat> please point to me the right channel if this isn't where I should ask this question
<dvheumen> hi guys, could anyone explain me why the /boot/config-{kernelversion} files have deviating settings from the kernels (last time I used such a config-{version} file it had (almost) all sound support disabled)
<crimsun> because sound support (drivers, that is) is in linux-ubuntu-modules, not linux.  You're looking at the config from the latter source package.
<dvheumen> ah right, but those config files are not stored in /boot/ right?
<crimsun> correct.  See http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=tree;f=debian/config;h=bfc00c02a8dfd3c7d06f7417be898c7e6bc76404;hb=HEAD
<dvheumen> so if I understand correctly: you're actually building a smaller (stripped) kernel and a separate set of kernel objects for among others sound devices
<crimsun> dvheumen: for lum?  No.
<crimsun> dvheumen: lum uses linux-headers-*
<crimsun> e.g., http://launchpadlibrarian.net/15053052/buildlog_ubuntu-hardy-i386.linux-ubuntu-modules-2.6.24_2.6.24-19.27_FULLYBUILT.txt.gz
<dvheumen> k, tnx, at least now I know I have to check the kernel config before compiling a vanilla kernel :)
<dvheumen> I got confused with all the options that were disabled by default
<ajonat> Hi! one question: what's /boot/abi-2.6.24-18-generic for? I'm building a custom kernel with make-kpkg and it doesn't generate that abi-2.6.24-blahblah file..
<ajonat> Besides, debian's linux-image doesn't come with that file but ubuntu's does..
<ajonat> the custom kernel stills boots and works perfectly but i was wondering what was this file..
<crimsun> ajonat: https://wiki.ubuntu.com/KernelMaintenance#head-1ef412dd0059f9680eb3af6bfe2fd3a5188020c4
<ajonat> crimsun, thank you!
<crimsun> yw
#ubuntu-kernel 2008-06-15
<Nafallo> https://bugs.edge.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/182489
<Nafallo> is that something that could go into a pointrelease?
<Nafallo> (and yes, I know it's a weekend) :-)
<mjg59> Nafallo: The last comments on #1192 by upstream suggest that the new hal causes some problems
<Nafallo> the last comment looks like someone has fixed it? haven't looked further than that since I'm trying to go through my bugfolder though :-)
<Nafallo> aha. BenC already marked it for 8.04.1 :-)
<mjg59> Nafallo: http://madwifi.org/ticket/1192#comment:236 doesn't seem to have been replied to
<Nafallo> ugh. at least it seems to be some effort put into the issue.
<mjg59> Looking at the mails, it seems that the new hal adds hardware support but reduces performance and resistance to interference
 * Nafallo <3 blobs
<Nafallo> </sarcasm>
<Kano32> hi, do you really need xen active in 2.6.26 in generic kernel?
<Kano32> makes it impossible to compile nvidia 173.x+
<mst_> Hey, can anyone help me figure out why I don't get a cdrom drive with ubuntu? It appears if I boot with acpi=off, but that's not the best solution for a laptop system. I know there was a kernel parameter that forced deeper probing of the ide channels while looking for a cdrom at boot time and I'd like to try it (even though with debian it spewed out some error over and over, but didn't find the cdrom) but can't remember what i
<mst_> t was and am having trouble finding it again in the kernel Documentation/ directory 
<Kano> hi, why did you disable dvb modules in 2.6.26?
<Kano> # CONFIG_DVB_CORE is not set
<Kano> not nice...
<Kano> hi, anybody awake? even when i compile external dvb i have to blacklist snd-aw2 - otherwise no dvb...
<Kano> please diable that driver and enable V4L again
<Kano> CONFIG_SND_AW2 causes real trouble
#ubuntu-kernel 2009-06-08
<Ng> is it possible/likely that 2.6.30 is not switching off as much hardware for S3 suspend as 2.6.$jaunty was?
<Ng> I suspended last night with 30 minutes of runtime left and my laptop was off this morning
<Ng> I'm pretty sure that previously that would have been plenty
<Kano> hi apw , i prepared a little patch for the double ids already
<Kano> apw: http://kanotix.com/files/kernel/unused-patches/2.6.30-disable-some-rt2500usb-ids.patch
<Kano> if you want to be able to compile fglrx with some tricks you need
<Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-export-flush_tlb_page.patch
<smb> Ng, It might be possible. You could do the suspend/resume tests which have one testcase that verifies power consumption to verify this further...
<Ng> smb: oh interesting
<Ng> powertop suggests that running power consumption is the same or slightly less than jaunty
<Ng> but I don't exactly have hard numbers for how much power was used while suspended
<Kano> for fglrx again is that patch: http://kanotix.com/files/kernel/unused-patches/2.6.29-ubuntu-copy-headers-for-fglrx.patch
<Kano> then the needed patch is MUCH smaller
<smb> Ng, the script would be in /usr/share/checkbox/scripts/suspend_test It would not be impossible to consume less power running but miss to power down something on suspend
<Kano> i still need to create a patch to support fritz usb draft-n, maybe later...
<Ng> smb: yeah that's what I figured. I think I know someone running equivalent hardware on jaunty, so I'll try to get some comparison figures. thanks :)
<smb> Ng, But to have more confidence it likely would require to compare a few runs on both. I sometimes got quite a variation on the same hardware on several runs
<Ng> smb: ok
<lamalex> how do i check out the jaunty kernel repo? whats the clone url, its not shown in gitweb and im having trouble guessing it
<smb> lamalex, git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git
<lamalex> hm why isnt that working for me..
<lamalex> ah, because im an idiot
<lamalex> ive been typing http://. 
<lamalex> I wish I could say it was morning and i just needed my coffee, but its after 2pm
<lamalex> maybe I can say I haven't had lunch and im really hungry
<smb> lamalex, Or maybe it is just Monday ;-)
<lamalex> that works for me
<apw> smb, anyone,  any of you heard of karmic kernels panicing with splash on boot on jaunty userspace (32bit)
<smb> Hm, I feel like I heard of it, but I believe only from walking over the list with you
<apw> smb ... yeah i feel it may be true.  cirtainly happening on my crashy laptop right now
<smb> apw, awkward to debug... :/
<amitk> apw, how would I go about looking at history of a file that is no longer present in the index? IOW, the file existed, but doesn't anymore. So 'git log foo.c' doesn't work.
<smb> amitk, might "git log --follow -- foo.c" work?
<amitk> smb: yup, that does it. Thanks
<apw> the -- is the key ther
<apw> as the file is definatly a file if it appears after the --
<amitk> so --follow is the inverse operation of git format-patch -M, I guess.
<smb> Hm, would that not be "similar"? As both follow/detect renames
<amitk> smb: yes and no. patches created with 'git format-patch -M' will need to be tracked with 'git log --follow' to list the file renames.
<amitk> so they are inverse operations in that sense, but I see what you mean.
<Keybuk> did we lose the ftrace open patch?
<CarlFK> not to be confused with the mentioned panic, I have my own: http://dpaste.com/52812/ [ 7776.273727] kernel BUG at /build/buildd/linux-2.6.28/net/core/skbuff.c:124!
 * Keybuk tosses a random kernel patch into a PPA
<Keybuk> if it works, it should make the populate_rootfs call async
<Keybuk> of course, that's a very big if :p
<cr3> hi folks, where can I find the kernel arguments which were passed when booting? I vaguely remember that information being available somewhere under /proc or somesuch
<cr3> aha! nevermind, it was in /proc/cmdline... I was looking for *arg*
<invisibill> Greetings ubuntu kernel devs:  I'm using "2.6.28-3-rt #12-Ubuntu SMP PREEMPT RT Fri Apr 17 10:09:12 UTC 2009 x86_64 GNU/Linux" kernel but it keeps freezing my fresh install of jaunty during any file download.  I'm tracking this thread http://ubuntuforums.org/showthread.php?t=1145879 and want to upgrade to the 2.6.30rc8 
<invisibill> Is there a repo I can add to apt for this.  Or should I just download directly from the site? 
<apw> invisibill, the mainline kernels can be gotten from the mainline kernels archive
<apw> see this url for instructions: https://wiki.ubuntu.com/KernelMainlineBuilds
<invisibill> thanks apw.  I'll try downloading the image file and installing it with dpkg.
<Ng> good work on the grub2 packaging, upgrade worked fine here :)
<Kano> well i use grub2 for ages now ;)
<Kano> best remove the old menu.lst as soon as possible, because os prober from other distros will find otherwise outdated entries
#ubuntu-kernel 2009-06-09
<power885> can anybody help in kernel programming am just newbie to linux
<power885> hello anybody der??
<power885> hello anybody der??
<power885> is der anybody to help me in kernel programming
<dholbach> hiya - can somebody tell me if I should report http://paste.ubuntu.com/191481 - or is that a known bug and being worked on already?
<dholbach> I just get a very quiet rustling sound instead of music on karmic
<amitk> dholbach: best to report the bug
<dholbach> (same using 'aplay' too)
<dholbach> ubuntu-bug audio? or ubuntu-bug alsa?
<dholbach> what was it again?
<amitk> alsa
<dholbach> gracias
<dholbach> erm no
<dholbach> there's "no package alsa"
<amitk> alsa-base
<amitk> sorry
<dholbach> ah yes, looking much better
<soren> Err... I'm quite sure, it's "sound"
<soren> Perhaps it's not implemented yet?
<amitk> soren: that was a proposal at UDS
<soren> Ah, ok. Sorry :)
<amitk> functionality-based bug filing or some such thing
<soren> https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/SymptomBasedBugReporting
<soren> I just saw it mentioned so many times I thought it was here already :)
<amitk> right
<dholbach> thanks amitk - reported, bug 385094
<ubot3> Malone bug 385094 in alsa-driver "[karmic] very quiet rustling sound instead of music" [Undecided,New] https://launchpad.net/bugs/385094
<apw> *ANNOUCE* today is a kernel team bug day ... https://wiki.ubuntu.com/KernelTeam/BugDay/20090609
* smb changed the topic of #ubuntu-kernel to: Karmic Kernel Plan: 2.6.31 -- Kernel Team Bug Day https://wiki.ubuntu.com/KernelTeam/BugDay/20090609
 * apw wonders when dtchen choses to have his wake time
<apw> TheMuso, you still in the wake land?
<TheMuso> apw: indeed
<TheMuso> apw: its 7:10PM here.
<apw> just wading through some old bugs, for the bug day and stubled across
<apw> the bug regarding muting PCM leading to crackles when sound is played
<apw> which is believed to be pulse audio related
<apw> and wondered if you had any background on it, and/or advice as to how to
<apw> go about moving it forward
<TheMuso> I think dtchen may know more than me with that, I am not sure whats going on at this time, without checking the bug again.
<apw> TheMuso, the bug i have i don't think anything is going on :)  but i can sync with dtchen happily
<TheMuso> ok
<apw> smb, i have found a bug which was fixed by a stable update, this is in intrepid we interested in updating the changlog that far back?
<smb> Hm, I do not think there will be much attention to that now. Lets restrict that to the Jaunty kernel. 
<apw> smb, fair, ack
<apw> smb, any idea if the bug list is live in any sense?  seems to never update for me
<apw> makes working with it very laborious
<apw> i wonder if we could get tags added to them, and remove them as we go
<amitk> apw: leanne's list? It's live more me, updates take a few minutes to be seen though.
<apw> yeah leans list
<apw> amitk, none of them have changed opn your list for me
<amitk> apw: coz I haven't worked on any yet :)
<apw> ie your bit looks unchanged here
<apw> so you have no idea then!
<apw> if it was broke this time i mean
<amitk> apw: it did work on previous bug days
<amitk> aah, point.
<apw> yeah it did indeed.  not so well today
<apw> poop, its obviously worked at least a bit as its got stuff some people did yesterday updated in it
<apw> ahh its part updated.  hrm
<apw> and that happened in the last 20 mins i recon
<apw> strnage.  i do note edge is SLOOOO today so perhaps its slowing the updates too
<cjwatson> there's some firmware in the main kernel packages in karmic that needs to be delivered to d-i. There's already a separate linux-firmware source package, though, that squats the obvious package names for this (nic-firmware, scsi-firmware). What would you guys like to do about this?
<cjwatson> (this is bug 384861, regarding bnx2)
<ubot3> Malone bug 384861 in debian-installer "Broadcom NetXtreme II (BCM5708) not detected by installer [karmic]" [Undecided,New] https://launchpad.net/bugs/384861
<cjwatson> or maybe it ought to just deliver the firmware in the nic-modules package along with the bnx2 module itself; I suppose there's no real reason to keep it separate
<Keybuk> II: Checking ABI for generic...
<Keybuk> EE: Previous or current ABI file missing!
<Keybuk>     /build/buildd/linux-2.6.30/debian/abi/2.6.30-8.10~boot2/amd64/generic
<Keybuk> make: *** [abi-check-generic] Error 1
 * Keybuk explodes
<Keybuk> how the hell do I avoid this?
<Keybuk> apw: around?
<cjwatson> mkdir -p debian/abi/2.6.30-8.10~boot2 && touch debian/abi/2.6.30-8.10~boot2/ignore # ?
<Keybuk> cjwatson: I don't want to ignore it, I want to know how to get what should be in that directory
<apw> Keybuk, yep here
<apw> run getabi's
<Keybuk> apw: how do I make the debian/abi/2.6.30-8.9 for your upload?
<Keybuk> apw: where is that?
<apw> debian/scripts/misc/getabis 2.6.30 8.9
<apw> though if you have changed it in any way which changes the ABI you will still need to either ignore it
<apw> or up the ABI number too
 * Keybuk only mucked around with static functions
<apw> though i thought the current tree _has_ the ABIs in it already
<Keybuk> I went from the source p ackage
<apw> then you won't have them, as you can't know them before the upload
<apw> so they get committed with the startnewrelease commit in the git tree
<apw> basically your 'error' is making a new changelog stanza
<apw> if you update the top one and add your ~boot2 you won't hit the issue i beleive
<apw> not ideal, but ok for debugging
<apw> Keybuk, am i making sense?
<Keybuk> yup
<Keybuk> that makes sense
<Keybuk> thanks :)
<apw> phew, np
<soren> What's the maximum limit of the size of the initramfs?
<Keybuk> there isn't one
<Keybuk> though there's a multiplicative speed penalty for putting anything inside it
<Keybuk> so the smaller the better
<amitk> ogasawara: why do we have already 'incomplete' bugs on the list today? I can't set it to "really incomplete"...
<apw> yeah my understanding of initramfs was it being better than initrd
<apw> as it could grow to ram size
<apw> amitk, those are for review, if they are open without response they go Won't Fix, is on the intro page
<apw> woh, if i reload three times on web page it is the same twice and different once... out of sync web me thinks
<apw> amitk, or did i miss understand
<amitk> apw: I missed the Incomplete-> Won't Fix 
<cjwatson> soren: there are some architecture-dependent limits on the size of the objects that bootloaders can load
<cjwatson> frex yaboot has difficulty netbooting anything over 6MB
<cjwatson> (IIRC)
<soren> Hmm... I just seem to remember reading about the "protocol" the boot loaders employ putting some limits on the sizes of the kernel and ramdisk.
 * soren goes to find that again
<apw> i have cirtainly had trouble with yaboot i the past with 60MB initrds and similar
<soren> AFAIUI the bootloader puts the kernel and ramdisk at specific adresses, and then starts running the kernel. Otherwise, how will the kernel know where to look for the initrd?
<Keybuk> soren: you're confusing initrd and initramfs
<Keybuk> soren: the initramfs is simply concatenated onto the end of the kernel image
<soren> Ah. There's a specific address where you put a pointer to the ramdisk along with the size of it.
<Keybuk> soren: again, you're confusing initrd and initramfs
<soren> Keybuk: Oh.
<soren> Keybuk: I thought the difference was just the format.
<Keybuk> no
<apw> Keybuk, do you mean in /boot or by the boot laoder
<Keybuk> the format is one difference
<Keybuk> another difference is the way they are loaded
<Keybuk> and yet another difference is when in the kernel the code inside is actualyl used
<apw> it is possible to embed initramfs in the kernel, but also to have it in the initrd bucket
<Keybuk> apw: you can do both
<Keybuk> apw: the bootloader puts it after the kernel image in memory
<Keybuk> so it appears identically to the kernel whether it was directly added in /boot or put after it by the bootloader
<soren> Keybuk: ..but how does the bootloader know whether it's an initrd or an initramfs?
<apw> though it uses the normal initrd style mechanism to tell the kernel about it
<apw> if its a separate image
<apw> and we have to use the magics in the initrd to tell if its initrd or initramfs format
<Keybuk> oh, that might be a bootloader thing ;)
<Keybuk> I could certainly be wrong
<Keybuk> though, that being said
<Keybuk> "how big can I make the initramfs" is the kind of question that makes me nervous
<soren> Ok, so even though we're using an initramfs, we do still use the ramdisk_image and ramdisk_size fields as described in Documentation/x86/i386/boot.txt?
<soren> Keybuk: Heh :)
<Keybuk> soren: I don't think so, no
<soren> Oh.
<Keybuk> soren: initramfs is unpacked into a tmpfs
<Keybuk> not a ramfs
<soren> Sure, sure.
<soren> That I understand.
<Keybuk> (how many ways can the name be wrong? :p)
<Keybuk> err, I think it's a tmpfs anyway, I should check that
<apw> i beive we do use the same pointers for a non-builtin initrd image
<soren> I'm just unsure how the bootloader tells the kernel where to find the initrd.img thing.
<apw> the bootloader just has the instruction to load and tell me where you loaded this blob for either format
<soren> apw: And that's those two fields?
 * soren crosses fingers
<apw> i believe it is yes
<soren> Oh, good.
<soren> :)
<soren> I was about to lose it :)
<apw> heh ... if you look at the source for INITRD you can see the bit where it looks at those two bits
<apw> and uses them to map some space into the kernel to reference it, then it checks for initrd and initramfs format contents and unpacks it as appropriate
<soren> Keybuk: I'm trying to overcome some annoying limitations on EC2 by stuffing some extra modules in the initramfs and exporting them to "real" system by way of a tmpfs.
<soren> Keybuk: I'm not going to slow down booting on your Mini 9 :)
<apw> the problem is we rm -rf the initramfs before we switch to normal root
<soren> apw: Not a problem.
<apw> though Keybuk did i see you do something funky sharing the initramfs onto /dev/ and the like to save space?
<Keybuk> apw: yes
<apw> ^5 cool idea
<soren> I'm doing pretty much the same thing here.
<Keybuk> which is why I'm suddenly curious as to whether it's a tmpfs or a ramfs ;)
<soren> What's the difference?
<Keybuk> ramfs is backed by ram
<Keybuk> tmpfs is backed by virtual memory
<soren> So is tmpfs, surely?
<soren> Oh.
<soren> Gotcha.
<apw> ramfs is a block device into which you can put any filesystem, and tmpfs is a real filesystem type whihc uses ram to back itself
<apw> (i think)
<Keybuk> apw: no, you're confusing ramdisk and ramfs there ;)
<Keybuk> ramfs is a real filesystem that uses ram
<apw> heh ... easy to do
<Keybuk> it's basically non-swappable tmpfs 
<apw> makes sense
 * apw goes back to his _fun_ bug day list
 * Keybuk is just proving to himself that initramfs is really not a ramfs but a tmpfs
<apw> its deffo a tmpfs as you reused it didn't you?
<Keybuk> it shows up as "rootfs" ;)
<Keybuk> I just assumed it was a tmpfs because that's what all the documentation and comments say
<Keybuk> just proving to myself from the code that it's not ramfs
<Keybuk> cause that would make my idea not-so-great
<apw> if you are reusing it for the /dev/ mount too that is reported as tmpfs
<Keybuk> current karmic doesn't reuse them
<Keybuk> they're separate mounts
<Keybuk> What is rootfs?
<Keybuk> ---------------
<Keybuk> Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
<Keybuk> always present in 2.6 systems.  You can't unmount rootfs for approximately the
<Keybuk> same reason you can't kill the init process; rather than having special code
<Keybuk> to check for and handle an empty list, it's smaller and simpler for the kernel
<Keybuk> to just make sure certain lists can't become empty.
<Keybuk> Most systems just mount another filesystem over rootfs and ignore it.  The
<Keybuk> amount of space an empty instance of ramfs takes up is tiny.
<soren> Keybuk: What's the idea?
<Keybuk> soren: we have several virtual filesystems
<Keybuk> /dev, /dev/shm, /var/run, /var/lock
<Keybuk> and probably /tmp
<Keybuk> they're all instances of tmpfs, just with different mount options
<Keybuk> so each one uses up resource to exist
<Keybuk> and we also have the initramfs/rootfs hanging around forever because it was built-in to the kernel
<Keybuk> we save memory, time and money by just re-using it
<Keybuk> so instead of mounting a new tmpfs at each of them
<Keybuk> we just bind-mount sub-directories of the rootfs onto the real filesystem
<Keybuk> so (initramfs)/dev is exactly equal to (root)/dev
<soren> Ah.
<Keybuk> (initramfs)/var/run is exactly equal to (root)/var/run
<Keybuk> etc.
<soren> Yeah, that would be neat.
<Keybuk> each of the bind mounts can still have different options of course
<Keybuk> it means we don't need things like /dev/.initramfs for a start
<Keybuk> but also saves a massive amount of time on boot (bind mounts are a single syscall to set up each)
<cjwatson> Keybuk: that would mean they'd share a maximum size rather than having independent maximum sizes, wouldn't it? (I don't think that's important for /dev /dev/shm /var/run /var/lock but it might be relevant for /tmp)
<Keybuk> no, that's a mount option
<cjwatson> neat
<Kano> hi apw , how about adding 2 commits with very simple changes from wireless-git
<Kano> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=3d563f6e2fdac4544f0de25af6ff299f4e29f10a
<Kano> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=b82882e12934ec192a6b21264da087f00ade0b39
<Kano> you only need to remove the additional "ath/", then it applies
<Kano> needs a new firmware too
<apw> i would imaging we'll get that when the merge window opens
<apw> we'll need a bug i recon to handle the firmware so we can track the licence
<Kano> http://article.gmane.org/gmane.linux.kernel.wireless.general/33605
<Kano> i think it will be in 2.6.31 too, so maybe add the firmware already
<cjwatson> Kano: (#ubuntu-devel) the purpose of unionfs-fuse is not speed; it's purely a stopgap measure until we get proper VFS-level union mounts, so I'm not interested in any properties of its speed other than "is it minimally usable" right now
<cjwatson> Kano: the kernel team is fed up having to twiddle aufs* into applying against the current kernel and I don't really blame them considering that a real upstream solution is in sight
<Kano> cjwatson: i prepared the patch, it works, what big thing do you need to do?
<cjwatson> it's a pain to continue maintaining it. It will not be necessary once we have mount --union.
<amitk> Kano: it will break again when 2.6.31 starts
<Kano> it is not that hard as you say. it was a bit tricky to fix the aufs patch for module mode as u had already some additional exports
<Kano> but the driver itself you can cp 1:1 from a git tree
<cjwatson> mount --union is much cooler anyway
<Kano> is it fast?
<amitk> not hard != automatic
<Kano> amitk: you could automate it
<mjg59> Kano: --union is done entirely in the VFS, so yes, it's fast
<Kano> the only tricky part are the additional expoerts
<Kano> the rest can be of course automated
<Kano> the exports will not change usually
<mjg59> There's no benefit in adding functionality to a kernel that's never going to be part of a release
<Kano> ok, waiting for a live image with mount --union then
<Keybuk> damnit
<Keybuk> foiled again!
<vissky> who do jobs as embeded linux?
<manjo> apw, I have a draft version of the design/implementation its in no way complete but you can look at it and let me know if I am going in the right direction ... https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-karmic-suspend-resume
<Kano> cjwatson: do you use kvm?
<CarlFK1> vissky: I got hired to do embedded linux, but personally I don't think running on x86 2g ram 60g hd qualifies as embedded 
<vissky> I love arm!
<amitk> vissky: you might find more people on #ubuntu-arm or #ubuntu-mobile
<vissky> maybe!
<maxb> Karmic ABI 8 kernel seems to break my software raid
<maxb> Instead of bind<sda2> and bind<sdb2>, I get bind<dm-3>
<maxb> and then it breaks and drops to an initramfs shell
<Keybuk> apw: my attempts to make populate_rootfs() async have been so far thwarted by something re-synchronising the world just after calling it
<apw> thats a royal pain
<apw> i can see its prolly needed pretty soon 
<apw> s/see/imagine/
<apw> do you know if its syncing on it, or on something else entirly
<Keybuk> just everything
<Keybuk> need to track it down, but I think something is just calling async_synchronise_full()
<apw> unhelpful for sure, you should instrument that with a WARN_ON(1);
<Keybuk> heh
<Keybuk> there's few enough that grep should be ok
<maco> mjg59, have there been any acpi/pmutils/etc-related changes in the last few days?
<mjg59> maco: I'm not active in Ubuntu any more
<maco> mjg59, ok. i just remember that you know all about acpi, so i thought maybe you'd be someone that would notice such changes
<maco> any idea who the current ubuntu acpi know-it-all is?
<mjg59> Pitti, at a guess
 * cwillu pokes apw
<cwillu> EXT4-fs warning (device sda1): dx_probe: dx entry: limit != root limit
<cwillu> EXT4-fs warning (device sda1): dx_probe: Corrupt dir inode 8962051, running e2fsck is recommended
<cwillu> the latest post-suspend bugs :)
<cwillu> re: bug #380807
<ubot3> Malone bug 380807 in linux "[karmic, intel] Laptop locks up moments after resuming from suspend" [Medium,In progress] https://launchpad.net/bugs/380807
#ubuntu-kernel 2009-06-10
<kseise> Is this the right channel to ask about creating a custom kernel for a noobie?
<xaashi> hi where would be a good place to get help with tcpdum
<xaashi> tcpdump :)
<xaashi> oops wrong channel., sorry
<Kano> hi apw , did you see 2.6.30 final?
<apw> Kano, yep saw it.  but the repos are down at the moment
<Kano> well kernel.org only has got the tar it seems
<apw> the rebase will appear when i can get the tree
<Kano> good to know
<Kano> git seems to be back
<JarekMk> Hi
<JarekMk> I'm useing Ubuntu 9.04 and have a question, if I install kernel 2.6.30 - it's safety?
<JarekMk> someone use it?
<apw> JarekMk, cirtinaly members of the kernel team are running both mainline 2.6.30 and Karmic 2.6.30 based kernels on their Jaunty userspace
<JarekMk> so it's safe to use it?
<Kano> well when you use fglrx then the u kernel will not help you
<amitk_> JarekMk: since the kernel is so HW-dependent(!), it is hard to say. But you can always boot up with the old kernel if the new ones causes regressions.
<JarekMk> you have right, I've be a men and do this :)
<Kano> which gfx card?
<apw> JarekMk, there is always risk ... all we can definatly safe is those who have tried here have had no issues, as kano indicates binary drivers are an issue as they do not exist for these updated kernels
<smb> The graphics drivers are dkms'ed. Though there is always a chance that upstream has changed in a way, that lets them fail to re-compile.
<Kano> they dont exist for u, but they do for my system ;)
<Kano> i gave you several times the patches which would allow fglrx (with patches of course) to work
<Kano> new nv drivers work with 2.6.30 directly, old ones need a simple patch
<CarlFK1> http://kernel.ubuntu.com/~kernel-ppa/  does that work with apt-get, or do i have to use wget/dpkg ?
<smb> CarlFK1, Those you neew to wget/dpkg
<CarlFK1> thought so, the ppa thing made me wonder 
<CarlFK1> thanks
<smb> s/neew/need&
<smb> Arg, fingers... 
<CarlFK1> is ok... I think I understand :)
<smb> CarlFK1, The name is slightly misleading but a real PPA would not allow to keep the older kernels
<smb> CarlFK1, BTW, you had the problem with pauses during boot, too. iirc
<CarlFK1> yeah, still pausing 
<smb> You could try acpi_skip_timer_override
<smb> Finally got a system with the same symptoms with c1e enabled
<smb> And it turned out the problem is an incorrect timer interrupt override. Unfortunately I currently see no way to automatically fix that
<CarlFK1> I have a new laptop, so unless it will help you test it, there isn't much value for me to fix 
<CarlFK1> would it help you?
<smb> Not much further. I think I understand the problem. Though for the solution one would need the documentation of various chipsets, which isn't likely to happen so soon
<smb> Just thought, if you still have the problem with that laptop it can help you
<CarlFK1> thanks
<CarlFK1> what Is a problem with that laptop, and I have a hunch others, will test 'soon') is a panic: http://bugzilla.kernel.org/show_bug.cgi?id=13075
<ubot3> bugzilla.kernel.org bug 13075 in Other "kernel BUG at /build/buildd/linux-2.6.27/net/core/skbuff.c:128!" [Normal,New] 
<CarlFK1> which is why I am trying daily vanilla kernel 
<CarlFK1> there is no way to script "get latest kernel" is there?
<CarlFK1> make that 'easy' way...
<CarlFK1> VER=2.6.30-999-generic_2.6.30-999.1244629645 makes me grumpy :)
<smb> CarlFK1, apw should know more of the details. But there is a daily dir with <date> subdirs... Might be a way to do a script
<CarlFK1> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-06-10/  
<apw> CarlFK1, i can't think of a way to make that work with the web based stuff we have there
<smb> The version had to be sufficiently away from "real" ones, so the 999 abi
<CarlFK1> I could probably construct that date, no clue where 1244629645  comes from
<apw> thats the time it was built
<apw> used to make the 999.NNNN uniquue
 * smb wonders whether wget can work with wildcards...
<apw> you can likely just wget the directory -R
<CarlFK1> apw: "with the web based stuff we have there"  is there some other source that would be easier to script?
<apw> CarlFK1, nope there is no other source right now ... you want a PPA for upgrades
<CarlFK1> hmm... and then dpkg -i xxx*yyy.deb 
<apw> but as smb says thast doens't do 'keep the last N' functionality we require
<CarlFK1> I think your -R thing will do the trick
<apw> we are always looking to improve things.  will put something on my todo to see if we can make it easier
<CarlFK1> I was just trying to avoid having to look at the dir listing and cut/paste the 1244629645 timestamp into a script.
<apw> would recording that information separatly help in some way?
<CarlFK1> a 'current' symlink near the top of the tree would be handy 
<apw> like a current file with the numbers, or a ... current symlink ...
<apw> will see what we can do there
<CarlFK1> groovy.  I can spend more time crashing my kernel :)
<apw> that does sound somewhat massocistic for sure
<CarlFK1> the panic seems to be related to using both firewire and nic, currently I need to run dvgrab to work the firewire. any idea how I can move data over firewire using a more generic command? like I am using nc to create network traffic 
<CarlFK1> networking over firewire is better than "get a dv camera, run an app" ... really trying to avoid having anything plugged in, but I don't think that;s going to happen
<smb> Hm, not really. Not even owning something that does firewire... 
 * apw neither
<CarlFK1> i think a firewire kernel module dev is on the dvgrab mail list... maybe he can help
<smb> Fair. Just remembered I actually _have_ something with a firewire connector. Just no cables. Some USB/firewire harddisk housing. That probably could do traffic simpler...
<CarlFK1> http://www.monoprice.com/products/product.asp?c_id=103&cp_id=10301&cs_id=1030102&p_id=1991&seq=1&format=2  $1.44 plus  $1.73 shipping
<CarlFK1> feel free to send me a bill, which I will pass on to the PSF :)
<smb> heh, yeah. looking which machines have the other end it looks like I need a 6-6 pin. Anyhow it was rather a matter of "why". Maybe now... ;-)
<cjwatson> smb: wget and wildcards> try lftp
<cjwatson> it can talk HTTP and you can do 'mget <wildcard>'
<smb> CarlFK1, that might be interesting to you ^^^
<smb> cjwatson, thanks
<CarlFK1> thanks, thanks
<mr_claus_> hi, where i can find the diff.tar.gz of the compiles mainline kernels?
<mr_claus_> on http://kernel.ubuntu.com/~kernel-ppa/mainline/ are only the binaries
<CarlFK1> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-06-10/linux-source-2.6.30_2.6.30-999.1244629645_all.deb ?
<CarlFK1> duh no if the diff is there...
<apw> mr_claus_, there is only the full source tarball
<apw> that said it would likely not be so hard to produce a raw delta from the base release and we could then get rid of the source tarball which is huge
<mr_claus_> apw: ok, thx, i didn't look in the source deb
<CarlFK1> smb: "is this mainline?"  yes if this is that: http://kernel.ubuntu.com/~kernel-ppa/mainline
<apw> its not necesarily ideal
<smb> CarlFK1, You got me slightly confused
<CarlFK1> smb: oh wait... you are not: Stefan Richter 2.6.29-02062901-generic  Is this mainline?
<smb> CarlFK1, No, just another Stefan
<mr_claus_> apw: so the huge tarball is just an copy of kernel.org?
<apw> that tarball is a copy of the source from which the binaries were made
<mr_claus_> apw: and the binaries are made from the kernel.org sources withtout any changes right?
<apw> right.  the source is basically pointless in my view as we are building from mainline
<apw> so you can get the same source from linus' tree via the tag we built
<apw> but we had complaints without it so i included them for completeness
<apw> the only changes we make are to add the build machinary so we can make .deb no changes to the actual mainline sources are applied
<mr_claus_> apw: the build machinery is the most important part :)
<apw> that is available in our ubuntu trees which are also public
<Loc_Vyler> Hello everybody. I'm trying to go in kernel development and using vanilla kernel with my ubuntu. So, I take config of ubuntu stock kernel and apply it to vanilla kernel. I noticed big difference in HDV performance, ubuntu stock kernel performs much better (everything but kernel is the same). Are there any secret in stock kernel? :-)
<Loc_Vyler> I mean I looked through ububtu specific patches and found nothing special about that. I use the same config with the same Timer frequency and Preemption Model.
<mr_claus_> so the ./debian is the same like the ubuntu release packages?
<Loc_Vyler> Just disabled Kernel hacking and CONFIG_DEBUG_INFO=y and CONFIG_DEBUG_KERNEL=y that was in stock config (that is strange thing to be enabled).
<Loc_Vyler> Sorry for dummy question, but I can't find answer anywhere else. I hoped you guys can send me to the right direction
<mr_claus_> probably there are patches in the stock kernel, you can download it and check out if there is something which depends on HDV
<Loc_Vyler> I don't think there are _special_ HDV patches :-), but some ordinary performance tuning that indirectly influenced on that
<mr_claus_> as you used the stock config with the vanilla kernel there is no difference, only the patches on kernel and drivers i think
<Loc_Vyler> sure, you right.
<CarlFK1> cat /etc/rc.local = screen -S ckdvs /home/carl/vga2usb/dvs/ckdvs1.sh
<CarlFK1> I see on the console "pick a screen profile 1...2...3..."
<CarlFK1> how do I get rid of that?
<CarlFK1> ckdvs1.sh is the scrip that causes the kernel panic... trying to get some stats on how long it takes
<CarlFK1> why I am asking here.
<CarlFK1> nm... I gotta run for the day
<Kano> apw: where is your rebase
<apw> test building before i push it
<Kano> slow cpu?
<apw> i was held up by the git outage on kernel.org
<apw> and i am somewhat careful so i like to be sure the whole stack builds first
<apw> it'll be there today when i am happy
<Kano> ok
<Kano> will watch a movie then instead of waiting all the time ;)
<apw> heh a good plan.  i am eyeing up a cold beer
<smb-topper> Heh, I am eying a whole pub of beer
<cking> it's not beer time? surely?
<mr_claus_> it's beer time :)
<cking> in a 24x7 world, it's always beertime somewhere
<mr_claus_> apw: the mainline packages are built with http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.28-11.42.diff.gz except patches, the build system is the same and can copied?
<apw> mr_claus_, thats basically it yes.  we get the latest tree from the nearest distro kernel, replace the source tree and then build it
<Sarvatt> apw: might want to use drm-next-merge instead of drm-next-radeon next time you build one of those :D
<apw> Sarvatt, whats that got in it?
<Sarvatt> looks more up to date getting ready for the merge -- http://cgit.freedesktop.org/~glisse/drm-next/log/?h=drm-next-merge
<apw> Sarvatt, thanks for the headds up will go look at it
<mr_claus_> apw: ok, thx, anyway it would be nice to get a delta with the mainline build, even if it's not much work to get it from the distro kernel
<apw> i've put an item to investigate what we can produce a diff from
<apw> onto my todo list
<mr_claus_> ty
<apw> Keybuk, 1) did you see my pointer to the unionfs kernel, 2) would it be fair to say you understand LSB headers for init scripts?
<Keybuk> apw: yes, yes
<Keybuk> haven't tested it though yet ;)
<apw> would you be able to cast an eye over the proposed change for linux-restricted-modules on bug #305587 for me
<ubot3> Malone bug 305587 in linux-restricted-modules "[Jaunty] warning: missing LSB information " [Medium,In progress] https://launchpad.net/bugs/305587
<Keybuk> do you mean start in 0 and 6?
<Keybuk> i guess you do ;)
<Keybuk> so yeah that looks right
<apw>     dh_installinit -p linux-restricted-modules-common --no-start -- start 7 S . start 1 0 6 .
<apw> we install it thusly at the moment
<apw> Keybuk, excellent ... will push that to our list for acks etc and get it in...
 * Keybuk battles with Automake
<Keybuk> Automake strikes
 * Keybuk dies
 * apw lobs Keybuk a ring of regeneration
<Keybuk> an ironic choice of item, given that it's source regeneration I'm having issues with ;)
<Kano> apw: i enabled lzma compression for kernel
<Kano> gives 3.1 mb instead of 3.8 mb kernel size
<Kano> 64 bit
<Kano> 3,8M 29. Mai 19:20 vmlinuz-2.6.30-8-generic
<Kano> 3,1M 10. Jun 20:21 vmlinuz-2.6.30-9-generic
<Kano> absolutely uncritical to use
<Kano> CONFIG_KERNEL_LZMA=y
<Kano> now
<Kano> also the initramfs could be compressed with lzma
<Keybuk> we don't really need to do that though
<Kano> you save lots of space in live mode, as you have the kernel+initrd twice on live media
<Keybuk> at the cost of slower decompression
<Keybuk> also 700KB is not "lots of space"
<Kano> DEcompression is really fast
<Keybuk> it's less really fast than gzip
<Kano> the compression for the initrd takes a while thats correct,but i see no problem for the kernel image, as you precompile it
<Kano> also 700kb * 2 usually
<Kano> thats only for the kernel
<Kano> the initrd could be even better compressed
<apw> Keybuk, the trade off is how long grub takes to load the poo as against how long it takes to decompress.  that compression advantage doesn't seem vry big
<Kano> initrd with lzma -9 compared to gzip: 6.7M vs. 10M
<Kano> so you save combined 8mb for live images
<apw> hrm, that might be measurable on load via grub ... dunno
<dhendrix> whoa, sweet! I didn't even know this channel existed. So has anyone tried building linux-source-2.6.30 lately? I'm getting an error about linux-2.6.30/ubuntu/gfs missing a Makefile.
<soren>   /win 40
<soren> Whoops
#ubuntu-kernel 2009-06-11
<TheMuso> c
<mr_claus> hi, if i try to compile 2.6.30-3 the build system create the file debian/abi/2.6.30-3.1/amd64/xen, then i get the message Previous or current ABI file missing!
<mr_claus> the build system try to get the file debian/abi/2.6.30-0.0/amd64/xen
<mr_claus> why 0.0? probably i did something wrong within the settings
<garfield> can somebody with udev/module-auto-loading knowledge look at the 2.6.27 to 28 regression in bug #372232? for some reason usb-storage isn't automatically loaded
<ubot3> Malone bug 372232 in linux "kernel 2.6.28 from 2.6.27 prevents Alcor reader working" [Undecided,New] https://launchpad.net/bugs/372232
<CarlFK> kernel          /boot/vmlinuz-2.6.30-999-generic root=UUID=f288e47f-0696-46af-bd87-d77887896674 ro panic=10
<CarlFK> cat /proc/sys/kernel/panic
<CarlFK> 3
<CarlFK> er.. 10... 
<CarlFK> but it doesn't reboot after http://dpaste.com/54336/  [  685.096912] Kernel panic - not syncing: Fatal exception in interrupt
<CarlFK> the caps lock light doesn't blink either 
<manjo> CarlFK, its writing more data than it allocated space for 
<manjo> CarlFK, len:10187 but buffer ends in end:0x680
#ubuntu-kernel 2009-06-12
<zeroprog> hey guys anybody know if theres something wrong with openssl's md5 functions?
<zeroprog> it seems to produce the hash with one character missing
<zeroprog> can somebody tell me why this is producing the wrong hash http://pastebin.com/d3d8753c1
<mr_claus> hmm, should the abi file be generated automatically while building the kernel image? i'm wondering why some modules compiled but not in the abi modules list
<amitk> mr_claus: yes, abi is generated after the build
<mr_claus> amitk: there are missing some modules in flavour.modules file and i don't know why
<amitk> mr_claus: what are you compiling, how and what are the changes you made?
<mr_claus> amitk: i started to compile 2.6.30 from the jeremy git (xen-patches)
<mr_claus> amitk: i used the build system from 2.6.28 and fit the files to 2.6.30
<mr_claus> i changed changelog of course, control.d/vars.xen (created)
<mr_claus> and config/amd64/config.xen
<mr_claus> but ... i didn't change config/amd64/config until now
<amitk> mr_claus: and the build is complaining about missing modules?
<mr_claus> after a "find . -name 'sata_sil*' i get
<mr_claus> ./build/build-xen/drivers/ata/sata_sil.o
<mr_claus> ./build/build-xen/drivers/ata/sata_sil24.o
<mr_claus> but the two modules are not in the .deb
<mr_claus> and not in the xen.modules
<alex_joni> mr_claus: did .ko's get built?
<mr_claus> alex_joni: no
<amitk> mr_claus: and the module is enabled in the configs? 'debian/rules editconfigs' to edit them interactively
<mr_claus> amitk: with editconfigs the files in config/amd64/config.* will be modified, right?
<mr_claus> amitk: in config/amd64/config there are SATA_SIL and SATA_SIL24 set to "y"
<mr_claus> amitk: but the interesting is, if i run editconfigs it looks different
<mr_claus> amitk: are there some docs how that is working?
<mr_claus> amitk: no, it doesn't look different, the modules are configured
<amitk> mr_claus: after exiting from all editconfigs, updateconfigs will be run automatically. Make sure the modules are still there after that.
<mr_claus> amitk: still there mean inside of config/amd64/config?
<mr_claus> i checked .config inside of of build dir debian/build/build-xen/
<mr_claus> the modules are set to "y" too
<mr_claus> and in config/amd64/config the modules set to "y"
<mr_claus> ahh, sry, my fault
<mr_claus> i'm blind, y means inside of kernel
<mr_claus> seems the night was to long and my brain was afk
<amitk> mr_claus: heh. Good catch. :)
<lamalex> Hi- is there a ppa for 2.6.30 that has the ubuntu sauce patches?
<alex_joni> lamalex: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/ ?
<lamalex> that's not just upstream?
<alex_joni> might be, just googled it
<lamalex> yeah i thought it was upstream
<lamalex> figured someone here would actually know
<alex_joni> lamalex: there is a package for lpia
<alex_joni> https://launchpad.net/ubuntu/karmic/lpia/linux-source-2.6.30/2.6.30-8.9
<amitk> apw: how are the splitconfig patches looking?
<apw> they look ok in general, there is some purley cosmetic stuff in there which i don't know if you intended
<apw> also the rename is going to cause me pain.  still have to actually test them, got sidetracked on some kms kernels
<apw> and writing up your new blueprint :)
<amitk> apw: cosmetic changes such as getting rid of commented lines, etc.?
<apw> i saw a couple of what must be pure white space changes in there
<apw> the one which sticks in my mind was in the rename patch which has a couple i think
<apw> i need to review them agian once i've tested them
<amitk> apw: there were a few space to tab conversions that I threw in there as I ran across them.
<apw> probabally waht they are then
<rtg> amitk: I'll be taking a look at them shortly. I'm also gonna start working on the flavour changes
<rtg> apw: uploading linux_2.6.30-9.10
<apw> rtg reached my upload email then :)
#ubuntu-kernel 2009-06-13
<CarlFK> "One other experiment which could possibly give some further information is to repeat everything after replacing ohci1394 + ieee1394 + raw1394 by firewire-ohci + firewire-core. Â Requires libraw1394 v2. Â (Latest is best.)
<CarlFK> any chance I can apt-get remove/install that?
<dtchen> CarlFK: which bit(s)? libraw1394 | 2.0.2-2ubuntu1 |        karmic | source
<CarlFK> ah, thanks - the -11 confused me : libraw1394-11 
<echo6> any work being done on plymouth yet?
<echo6> any one know why 2.6.30 with aufs compiled-in stills drops me to busybox on a remastered livecd?
<cjwatson> echo6: we're planning on sticking with usplash, actually, and just arranging for X to come up as early as possible so that usplash usually won't need to appear
<cjwatson> echo6: aufs> don't know, but with 2.6.30 on karmic we're currently using unionfs-fuse. There's support for it in karmic's casper. We're expecting to switch to VFS-level union mounts once those are available
<BUGabundo> hi
<BUGabundo> what is the idea behind the kernel PPA not being a true PPA, allowing apt updates? is it to make the user a conscious decision on using it?
<BUGabundo> apw: ping ^^^^^^^
<Sarvatt> couldnt keep around older releases on a PPA :D
<BUGabundo> ahhhhh
<BUGabundo> that's a good reason too
<BUGabundo> I've filed a bug a while ago on LP
<BUGabundo> to keep superseeded packages to APT
<rune_> does anyone know if the "CPU#1 stuck for 60 seconds" bug in current 9.04 kernel is fixed in 2.6.30?  Backtrace shows two spinlocks when deleting a file
<rune_> ext4
<BUGabundo> no idea
<dtchen> BUGabundo: the idea is to provide a mechanism by which users can opt-in to installing those kernel debs for testing but not have them reportable to LP
<BUGabundo> ok dtchen
<BUGabundo> I'm advising user that get their probs fixed with those kernels to file bugs stating so
<BUGabundo> so that the fix can be backportd
<BUGabundo> hope that's ok
<dtchen> right, as long as the bugs affect ubuntu's linux source package but clearly indicate which mainline deb is used, it should be useful
<BUGabundo> usually its wifi cards or wired cards
<CarlFK> is htis a bug in the panic handler?  http://dpaste.com/55020/  [  235.483373] ---[ end trace c59b4d88b94637b5 ]--- [  235.483373] Kernel panic - not syncing: Fatal exception in interrupt   
<CarlFK> I set panic=10, which should reboot after 10 seconds, but it doesn't reboot 'ever' (20 min long enoungh?)
<BUGabundo> lol
<CarlFK> what is the vanilla kernel #chan?  something like kernel-hackers....
<tormod> apw: can you please make a 2.6.30-9.10+kms kernel? currently the main kernel supersedes the old kms kernel so that I can not build the kms mesa on top of it :( 
<tormod> (talking about the radeon-kms PPA of course) otherwise I have to fake a higher version on the older one
<tormod> apw: sorry I am an idiot, I didn't see you already made one in your own PPA :)
<tormod> I'll just copy it over
<tormod> apw: a sleep-deprived idiot I might add: I just noticed the build had failed...
<CarlFK1> how can I tell what apps/packages depend on libraw1394-11? (I was asked to test a kernel panic against it, and the app I use (dvgrab) doesn't work with it due to v2s new api)
<apw> tormod, crap that bug agaiin, will get it sorted tommorrow and uploaded again
<tormod> apw: thanks. will you drop the "~" in the version, so it can supersede the main kernel?
<CarlFK1> is a panic that does not panic[1] worth reporting, or is that 'just the way it is'
<CarlFK1> [1] panic, but then doesnt;' blink the caps lock or reboot when panic=10
<CarlFK1> http://dpaste.com/55069/  panic log
<cwillu> could somebody take a look at http://pastebin.com/f181da3d8 for me?
#ubuntu-kernel 2009-06-14
<johanbr> cwillu: kernel oopses when it tries to allocate memory
<johanbr> what are you doing when that happens?
<cwillu> johanbr, I'll come back to the machine and it's locked up (monitors are in stand-by, can't ssh in, etc)
<cwillu> so my best answer is "nothing" :p
<johanbr> what was it doing at the time?
<cwillu> happens every couple days
<cwillu> again, as far as I know, there is nothing out of the ordinary running at that time
<johanbr> basically idle?
<cwillu> yep
<cwillu> I _do_ have a daily backup happening, but I turned it off for a couple days, still experienced this hang
<johanbr> that shouldn't happen
<johanbr> oopsing when allocating memory makes me think "RAM problem"
<johanbr> have you run memtest?
<cwillu> I ran memtest on it for about 24 hours a week or two ago
<cwillu> no errors
<cwillu> 64bit cpu running a 32bit install, in case that's relevant
<johanbr> how much ram?
<cwillu> 2 gigs
<johanbr> hmm... no immediate guess
<johanbr> do you have other oopses captured?
<cwillu> this was the first netconsole capture I've done on it, but it lives long enough to write to the log files
<cwillu> May 21 13:02:43 ralph-desktop kernel: [423191.559094] BUG: unable to handle kernel NULL pointer dereference at 00000001
<cwillu> looks like I've got a couple dozen in /var/log/kern.log.*.gz
<cwillu> q
<johanbr> what's the line corresponding to [129075.799432] IP: [<c01bffcf>] __kmalloc+0x6f/0x1b0 ?
<cwillu> this started after upgrading to jaunty, the issue remains under the 2.6.30 kernels as well
<cwillu> one sec
<cwillu> May 21 13:02:43 ralph-desktop kernel: [423191.559103] IP: [<c01b8099>] kmem_cache_alloc+0x49/0xb0
<cwillu> that one's off 2.6.28-12-generic
<johanbr> okay
<cwillu> actually, give me one sec
<cwillu> I just lied to you :p
<cwillu> oh, nevermind, I didn't lie
<johanbr> :)
<johanbr> seems like it consistently crashes when trying to allocate memory
<cwillu> May 29 00:32:59 ralph-desktop kernel: [567299.666278] IP: [<c01c44c7>] __kmalloc+0x67/0x180 is the one that actually matches the second one I linked above
<johanbr> alright... same thing, basically
<cwillu> but kmem_cache_alloc shows up on some of them too
<cwillu> will jaunty boot under a 8.10 kernel?
<johanbr> that should work
<johanbr> but you said it showed up under 2,6,28?
<cwillu> yes
<johanbr> oh, never mind...
<cwillu> I'm thinking "regression added in 2.6.28 that hasn't been noticed consistently yet", but my thoughts are suspect :p
<johanbr> it didn't happen in intrepid?
<cwillu> not that I know of
<johanbr> have you run intrepid since the bug first started appearing?
<cwillu> no
<johanbr> a bug in the kernel memory allocation would've been quickly noticed
<johanbr> so I still suspect some kind of hardware problem
<cwillu> I updated to jaunty because of the improved wacom handling (was basically unusable in intrepid due to how intrepid's xserver handled hotplugging), a day or two later he started complaining about lockups
<johanbr> does the machine have swap?
<cwillu> yes
<johanbr> could also be a disk problem
<johanbr> if you have some unpartitioned space (or an expendable partition) you could try using a different swap partition
 * cwillu turns off swap and warns him of potentially odd behaviour :p
<johanbr> you can also do that :)
<johanbr> how often does the bug strike?
<cwillu> once a day, once every couple days
<johanbr> alright
<johanbr> at the moment, I don't have any other ideas
<johanbr> try running without swap for a while and see if that changes anything
<cwillu> will do
<Sarvatt> is the PAE x86 server kernel getting the axe?
<zeroprog> hey guys im trying to find the docs on my device....i did lsusb and found WinChipHead but when i google it the only sites that appear are in some asian language.....is there any other way i can figure out what i need to write the driver 
<CarlFK> log_buf_len=n	Sets the size of the printk ring buffer, in bytes. 			Format: { n | nk | nM } 			n must be a power of two.  The default size 			is set in the kernel config file.   http://www.kernel.org/doc/Documentation/kernel-parameters.txt
<CarlFK> Um... I don't see it in juser@dell30:~$ grep -i log_buf /boot/config-2.6.28-11-generic 
<CarlFK> CONFIG_LOG_BUF_SHIFT=17
<CarlFK> "The default size is set in the kernel config file." sounds odd.  
<darthanubis> I need an 8.10 kernel config, or a 9.10 kernel config
<mohan_> hi..
<mohan_> i am using ubuntu jaunty..
<mohan_> any latest RT kernel ?
<mohan_> hi.. anybody pls..
<mohan_> i need RT kernel for jaunty..
<mohan_> the current RT kernel hangs my system.. :(
<mohan_> hey..
<mohan_> anybody here?
<cwillu> mohan_... should stick around longer next time :(
<darthanubis> https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/347487
<ubot3> Malone bug 347487 in virtualbox-ose "starting virtual machine in virtualbox-ose freezes system" [Medium,Confirmed] 
<arielCo> hello, is this a good place for questions about upgrading my kernel?
<arielCo> I'm going to upgrade to 2.6.30, downloaded from kernel.ubuntu.com, but the package description warns me that I may want to install the -generic metapackage instead, and I cannot find it. Is it really necessary?
<darthanubis> arielCo, nothing is REALLY necessary
<darthanubis> arielCo, https://wiki.ubuntu.com/KernelMainlineBuilds
<arielCo> @darthanubis: going
<darthanubis> ??
<arielCo> Okay, that's what I did the last time I tried (2.6.29). That time, the b44 driver did not autoload on boot and I had to type 'modprobe b44' every time I booted.
<johanbr> that's unrelated to not installing the -generic package
<arielCo> Johan, thanks. Do you know where can I find info on autoloading / hw detection? I'm about to upgrade via dpkg, and I want to understand the issue so I can transmit simple instructions to anyone doing the same :)
#ubuntu-kernel 2010-06-14
<jaminc> I'm experiencing a seeming random kernel crash and system reboot.  I have a crash dump, the system detects the previous crash and offers to report it, however every attempt to report it seems to fail with an HTTP 500 Error (bug #538097) additionally, apport-retrace fails with an index out of range (bug #592239)... so, what are my options for either reporting this crash or getting some meaningful information out of it?
<ubot2> Launchpad bug 538097 in apport (Ubuntu) (and 1 other project) "+storeblob fails with "500 Internal server error" on production (works on edge) (affects: 104) (dups: 6) (heat: 533)" [High,Invalid] https://launchpad.net/bugs/538097
<ubot2> Launchpad bug 592239 in apport (Ubuntu) "apport-retrace - IndexError: list index out of range (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592239
<Sarvatt> any reason the i386 kernels are using CONFIG_M586=y in maverick that went to i686 by default?
<ScottL> does anyone know why the -preempt kernel keeps building uninstallable binaries?
<ScottL> i think this is keeping the ISo testing from building a proper ubuntu studio ISO
<jaminc> I'm experiencing a seeming random kernel crash and system reboot.  I have a crash dump, the system detects the previous crash and offers to report it, however every attempt to report it seems to fail with an HTTP 500 Error (bug #538097) additionally, apport-retrace fails with an index out of range (bug #592239)... so, what are my options for either reporting this crash or getting some meaningful information out of it?
<ubot2> Launchpad bug 538097 in apport (Ubuntu) (and 1 other project) "+storeblob fails with "500 Internal server error" on production (works on edge) (affects: 104) (dups: 6) (heat: 533)" [High,Invalid] https://launchpad.net/bugs/538097
<ubot2> Launchpad bug 592239 in apport (Ubuntu) "apport-retrace - IndexError: list index out of range (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592239
 * abogani2 waves
<abogani2> apw, ogasawara: Are you around?
<MTecknology> abogani2: hi
<abogani2> MTecknology: hi :-)
 * apw yawns
<ikepanhc> good morning .eu
<apw> morning
<smb> Morning .*
<cking> morning .* too
<ikepanhc> There is CONFIG_PREVENT_FIRMWARE_BUILD in driver/Kconfig, but seems no code use it, anyone knows how it works?
<ikepanhc> s/driver/drivers
<ikepanhc> eh drivers/base/Kconfig
<apw> ikepanhc, isn't that an intermederary configuration option, one that gets selected
<smb> cooloney, Heya Brian. Is Eric around today?
<ikepanhc> oh, I see them
<cooloney> apw: smb cking morning guys
<abogani2> apw: There is a bug into maverick-meta package: -preempt is still there. Could you remove it, please?
 * apw waves generally
<smb> cooloney, moin
<cooloney> smb: he seems to be dropped.
<cooloney> smb anything urgent?
<cooloney> i can call him
<smb> cooloney, Meh, semi-urgent. Not worth a coll I think. I write him an email
<abogani2> smb: I suppose than you can remove the linux-rt signed directory in your home at Zinc. Thanks for all!
<apw> abogani2, hrm, i'll get leann to drop it from the next upload, wonder how that got missed
<abogani2> apw: Thanks!
<smb> abogani2, I am lazy. So it gets removed the next time I add something new. :) You're welcome
<abogani2> smb: :)
<abogani2> apw: Only for keep you updated: the last lowlatency test build is done at https://launchpad.net/~abogani/+archive/broken/+packages
<ikepanhc> apw: about the lucid ABI number, is it good to use a greater number such as 1000+ for oem kernel branch?
<ikepanhc> sorry forget to trace this issue after last time I asked you
<ikepanhc> oh, and I asked for several oem guys, seems no oem project using karmic netbook branch
<apw> ikepanhc, ABI number> it depends if they are going to be new branches or merge into the existing ones
<apw> ikepanhc, karmic netbook> seems this branch is dead then, will talk to smb about its fate
<apw> ikepanhc, so you do not have any use for the branch any more ?
<smb> apw, ikepanhc If noboday is using that, then I'd vote for removal
 * apw concurs with smb, one less branch to fix :)
<ikepanhc> apw: yeah, that's the problem, if using a greater ABI number on a branch, it will let the branch can not be merged - build server will reject uploading a smaller ABI number
<smb> Not that I never did much with that
 * ikepanhc ponders for removal
<ericm|ubuntu> smb, the merge looks good, I'm doing a building and will have a smoke test on dove hw, get back to you soon
<smb> ericm|ubuntu, Ok, great. I hold back and upload as soon as you give your ok
 * ericm|ubuntu feels sick about the error message: ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored.
<ericm|ubuntu> anyone knows why 'fakeroot echo $LD_PRELOAD' doesn't show any clue?
<maxb> Because your shell expanded $LD_PRELOAD before fakeroot was invoked
<smb> If you were on i386 it might be a 32/64bit issue...
<ericm|ubuntu> maxb, ah right
<ericm|ubuntu> smb, I'm on amd64, ia32lib installed though
<ericm|ubuntu> maxb, let me try encapsulate that into a shell script then
<ericm|ubuntu> now it shows: LD_PRELOAD=libfakeroot-sysv.so
<jk-> ericm|ubuntu: do you have libfakeroot for 32-bit?
<ericm|ubuntu> jk, nope
<jk-> and are you trying to run a 32-bit binary ?
<ericm|ubuntu> jk-, that could possibly be the cause
<ericm|ubuntu> it's a codesourcery toolchain and it should be 32-bit binary
<apw> ikepanhc, smb, karmic netbook> i propose we tag the tip of the branch netbook-mothball and remove the branch ... then we can get it back if we need to
<ericm|ubuntu> jk-, you are right: file ~/bin/arm-2010q1/bin/arm-none-linux-gnueabi-gcc
<ericm|ubuntu> /home/ycmiao/bin/arm-2010q1/bin/arm-none-linux-gnueabi-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
<apw> ericm|ubuntu, i run those in a 32bit chroot
<ikepanhc> apw: that's a good idea
<ikepanhc> apw: +1 from me
<apw> smb, ?
<smb> apw, ikepanhc Sonds like a good middle way between complete removal and carrying it around
<smb> apw, +1
 * apw takes the action ...
<ericm|ubuntu> apw, you are right
 * ericm|ubuntu sees apw happily removing a branch
 * smb finds a Lucid ABI 23 in the meta repo done by apw... I guess not uploaded, yet?
<apw> smb, right, its an UNRELEASED one right?
<apw> thats there to trigger pre-proposed to pick up the abi change
<smb> Yep it is.
<smb> I am just finalizing it
<smb> Just a bit confused why the -22 is marked proposed too
<apw> did i do -22 ?  i don't recall touching that
<smb> Hm, looking at the archive, it looks ok though
<smb> Maybe the day0 update
<apw> yeah i wondered about that, though i thought that was not a bumper
<smb> I just got confused because I did not do an ABI bump since release. But maybe we did and its just half erased from memory. :-P
<smb> We should be in sync now
<apw> ok cool
<ericm|ubuntu> smb, it works all right
<smb> ericm|ubuntu, Ok, thanks for the verification, I will upload in a few minutes
<ericm|ubuntu> smb, thanks for the work - really appreciated
<smb> ericm|ubuntu, It was partially the confusion about the whitespace. But I am glad it is good now
<ericm|ubuntu> smb, yeah - their patches s*ck but I was not doing good to educate
<jaminc> I'm experiencing a seeming random kernel crash and system reboot.  I have a crash dump, the system detects the previous crash and offers to report it, however every attempt to report it seems to fail with an HTTP 500 Error (bug #538097) additionally, apport-retrace fails with an index out of range (bug #592239)... so, what are my options for either reporting this crash or getting some meaningful information out of it?
<ubot2> Launchpad bug 538097 in apport (Ubuntu) (and 1 other project) "+storeblob fails with "500 Internal server error" on production (works on edge) (affects: 104) (dups: 6) (heat: 533)" [High,Invalid] https://launchpad.net/bugs/538097
<ubot2> Launchpad bug 592239 in apport (Ubuntu) "apport-retrace - IndexError: list index out of range (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592239
<pgraner> jaminc: you can use https://bugs.launchpad.net/ubuntu/+source/linux/+filebug to file the bug and then use apport-collect <bug number> to attach all the needed debug info
<jaminc> isn't that likely to suffer from the same issue with the automated upload?
<pgraner> jaminc: don't know, but its worth a try, if it fails then you can upload everything manually via the web interface
 * apw lunches
<TeTeT> smb: I escalated the x201 WWAN module problem, maybe it will end in your lap
<jaminc> pgraner, can't seem to attach a file to bug report after filing it... keep getting "Cannot upload empty file." even after selecting the file and seeing it listed in the selection box
<smb> TeTeT, Thanks for the heads up. I will see... :)
<tgardner> smb, Is Lucid -meta stuck in the queue?
<pgraner> jaminc: whats the bug number?
<jaminc> 593650, uploading the file now, forgot that the crash dumps are only accessible by root
<jaminc> any tags that are needed since the crash dump is being uploaded manually?
<pgraner> jaminc: yea one sec
<pgraner> jaminc: https://wiki.ubuntu.com/Kernel/Tagging look at the last table and pick the appropriate ones
<pgraner> jaminc: I'll get out triager to get it into the right state when he comes online
<jaminc> thought there were tags to indicate a need for a retrace and such?
<jaminc> pgraner, upload got to 100%, page started to reload and then gave me: "Sorry, there was a problem connecting to the Launchpad server."
<pgraner> jaminc: what was the name of that file? Several are on the report now
<jaminc> those are the ones from apport-bug, the manual upload was the kernel crash dump: linux-image-2.6.32-22-generic.0.crash 
<apw> uploading crash dumps to launchpad ... just how big is that thing?
<MTecknology> apw: that's a really early lunch... I wasn't even to work yet
<apw> MTecknology, depends on where the sun is in the sky in my part of the world :)
<jaminc> this one is smallish 309M, others are quite large... have had one up to 2.5G
<apw> jaminc, i suspect that the upload is timing out
<pgraner> jaminc: use apport-collect 593650 <full path to the crash file>         and see if that will get it to go
<MTecknology> apw: I live in the US - therefor you all abide by my time.
<pgraner> apw: launchpad is having issues today, I'm getting timeouts just refreshing pages
<jpds> jaminc: I think bug #592239 is a dup of bug #585269.
<apw> MTecknology, luckily we have learned how to ignore .us
<ubot2> Launchpad bug 592239 in apport (Ubuntu) "apport-retrace - IndexError: list index out of range (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592239
<ubot2> Launchpad bug 585269 in apport "apport-retrace shouldn't expect a Package field for kernel crashes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/585269
<MTecknology> apw: :P
<pgraner> jpds: we don't care about dupes, we need a new report on all kernel bugs
<jaminc> pgraner, no, he's talking about why I can't locally retrace it... different item
<pgraner> jaminc: yea I saw that after the bug desc popped up
<jaminc> pgraner, apport-collect 593650 /var/crash/linux-image-2.6.32-22-generic.0.crash 
<jaminc> Usage: apport-collect <report number>
<pgraner> jaminc: then it I don't know
<apw> jaminc, i would try attaching it using the attach file option, i suspect it will puke again at which point i suspect your only choiuce is to make it available somewhere else
<jaminc> apw, already tried using the attach file option that's what resulted in the "Sorry, there was a problem connecting to the Launchpad server."
<apw> jaminc, i suspect they never ever considered files that big being attached and its timing out in the middle
<jaminc> the problem is that the crash needs a retrace, I'd happily do the retrace myself (have built and installed the debug version of the kernel), just not sure how to do it since apport-retrace bombs
<ogra> hmm, did we get a new defconfig for omap with the last upload ? i suddenly get weird error messages with the latest omap3 binary
<ogra> i cant relly see any valid stuff in the uploaded changelogs 
<jaminc> would the kernel crash dump contain potentially sensitive information?
<amitk> yes
<amitk> it dumps your entire physical memory
<amitk> so potentially decrypted keys
<jaminc> then hosting it publicly isn't much of an option.  any other way I can get a useful trace from it?
<amitk> jaminc: do the analysis yourself?
<jaminc> I'm offering to... however all the tools referred to by the documents I've found fail... so I'm asking for guidance...
<jaminc> https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe refers to using apport-retrace, however as bugs #592239 and #585269 illustrate, that's not possible currently even with self built debug kernels installed
<ubot2> Launchpad bug 592239 in apport (Ubuntu) "apport-retrace - IndexError: list index out of range (dup-of: 585269)" [Undecided,New] https://launchpad.net/bugs/592239
<ubot2> Launchpad bug 585269 in apport "apport-retrace shouldn't expect a Package field for kernel crashes (affects: 2) (dups: 1) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/585269
<cwillu_at_work> jaminc, should be easy to hack up apport-retrace to not try to include it, it's just a python script
<jaminc> seems the upload issue is a very old bug #95822
<ubot2> Launchpad bug 95822 in apport (Ubuntu) (and 1 other project) "Malone connection generates an "Internal Server Error" on large file attachments (affects: 6) (dups: 6) (heat: 84)" [Medium,Confirmed] https://launchpad.net/bugs/95822
<jaminc> cwillu_at_work, by george you were right... a single line change to the python script and a small change to how apport-retrace was called and I appear to have a viable trace
<ogra> hmm, the omap3 error seems to come from a patch that enables IO-CHAIN wakeups 
<ogra> "Wake up daisy chain activation failed."
<ogra> i dont see changes related to that in the changelog ... do we not include everything in the debian/changelog file ?
<ogra> (i mean upstream commits)
<ogra> amitk, ^^^ any idea ? 
 * ogra suspects http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18213.html entered mainline recently or something like that
<ogra> in any case it makes the beagle kernel unbootable atm
<amitk> ogra: which omap error?
<ogra> "Wake up daisy chain activation failed."
<ogra> over and over
<amitk> lucid or maverick?
<ogra> maverick indeed :)
<amitk> ogra: this is with new kernel?
<ogra> i used 2.6.34 for testing until today 
<ogra> this error shows up with 2.6.25-2.2
<ogra> err
<ogra> -2.3
<ogra> so something changed between .34 and .35
<amitk> _lots_ of omap changes went in then
<ogra> where are the changelogs for that in our package ? 
<ogra> we should somehow generate an upstream changelog that goes into the package docs 
<manjo> JFo, you feeling better ? are we doing the bug meeting today?
<JFo> manjo, not much. I think something I ate in SC didn't agree with me. We will be having the bug chat
<tgardner> ogra, we do not generate a changelog of that size since it would have tens of thousands of changes, not a manageable amount IMHO.
<ogra> hmm, i thought we used to have such a feature once
<manjo> JFo, sorry to hear that... will talk to you at the meeting 
<JFo> k :)
<ogra> in the package changelog actually
<amitk> ogra: the entire upstream changelog isn't in debian/changelog, only a pointer to what tag we rebased to. 
<ogra> it would help a lot during development 
<tgardner> ogra, we do for minor updates, but going from 2.6.34 to 2.6.35 is a big jump
<amitk> ogra: you wouldn't know where to even look if the entire 2.6.34..35 changelog was put into debian/changelog
<ogra> yeah, i understand ...
<ogra> well, i could gep for buzzwords
<ogra> i.e. in the above case i would expect something like IO-CHAIN to show up in a changelog entry
<amitk> ogra: git log | grep buzzword :-p
<ogra> amitk, then i need to pull the git tree 
<ogra> having a changelog file would be a lot more convenient for a non kernel developer 
<ogra> but if its to big then its indeed no option
<tgardner> ogra, 9479 commits from 2.6.34 to 2.6.35-rc3
<ogra> yeah, thats surely a lot
<amitk> ogra: I just checked, even debian doesn't do something like that. Just a one-liner saying "update from tag1 to tag2"
<ogra> amitk, yeah, seems i took wrong that changes sometimes show up and sometimes they dont 
<ogra> http://www.gossamer-threads.com/lists/linux/kernel/1228828 aha
<ogra> Mike Chan (2): 
<ogra> OMAP3: PM: Enable IO / IO-CHAIN wakeups for PER 
<amitk> mpoirier_: are you looking at bug 566645?
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 70)" [High,Confirmed] https://launchpad.net/bugs/566645
<mpoirier_> yes and no.
<mpoirier_> discovered a problem with SD card.
<mpoirier_> very tedious.
<mpoirier_> took me a week to find it.
<mpoirier_> I'll jump on 566645 as soon as this one is fixed.
<mpoirier_> I have the answer on SD card.  Just need to go through the patch set to see which one broke the SD card.
<amitk> mpoirier_: ok, it would be nice if you, lag and Bryan divided up the bugs at https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/ amongst yourselves, depending on what HW each of you have.
<mpoirier_> to the best of  me knowledge Bryan doesn't have HW.
<amitk> they are important enough bugs for our maverick work too, so if the fix isn't yet in 2.6.35-rc3, then we need to apply it as a sauce in maverick
<mpoirier_> here's a question:
<amitk> mpoirier_: I'll see if I can make arrangements for some more HW
<mpoirier_> What has precedence: maverick on panda or bug fixes ?
<mpoirier_> I'm working on SD card for now while no kernel from TI for panda.
<mpoirier_> but when kernel is given to us, I don't know what comes first.
<mpoirier_> and where to fit OTG ?
<mpoirier_> I just need priorities.
<amitk> mpoirier_: that (priority) is a question for tgardner, but I believe we need to fix the confirmed bugs in lucid and make sure they don't recur on marverick
<mpoirier_> Therefore, SD card and OTG would come first.
<tgardner> mpoirier: for now I think amitk's suggestion is best.
<mpoirier_> I should check in SD card today or tomorrow. tgardner, we need to talk about the problem and the fix.
<tgardner> mpoirier: ack
<mpoirier_> I'll jump on OTG after.  I think upstream got it working.
<amitk> mpoirier_: with panda, we have a totally new kernel (separate branch, new HW generation, etc.). There will be new bugs. But atleast the OMAP3 stuff should work well on lucid and maverick.
<amitk> it gives our community something to hack on widely available boards
<mpoirier_> Ok, if priorities are to fix bugs on OMAP3, that's what I'll do.
<mpoirier_> there aren't that many.
<mpoirier_> Who will take care of OMAP4 then ?
<mpoirier_> people will start asking me questions ?
<tgardner> mpoirier: we can worry about that when we actually have HW
<mpoirier_> I have a panda board right next to me.
<tgardner> ogasawara, are you planning an -rc3 based upload today? I suspect it'll fix some of the process hang problems I've had with the LTS backport.
<tgardner> mpoirier: indeed, I thought it was still under development.
<tgardner> but, as amitk suggested, lets make Lucid work well first
<tgardner> Lucid/maverick
<amitk> lucid/maverick on OMAP3
<tgardner> amitk, OMAP4 is maverick only, right?
<amitk> tgardner: right
<mpoirier_> Who will be working with TI on panda OMAP4 while I fix OMAP4
<mpoirier_> fix OMAP3 that is.
<ogasawara> tgardner: yep, planning to rebase this morning
<tgardner> ogasawara, I did a test rebase, it was completely painless
<ogasawara> tgardner: sweet, should be quick then
<tgardner> ogasawara, I did bump the ABI before building though, just as a matter of course
<ogra> mpoirier, lag and you have the omap4 HW 
<ogra> mpoirier_, so he should be able to take over 
<lag> ogra: I have Panda
<ogra> right
<ogra> thats what i was saying :)
<amitk> ogra: do you have more beagles in your team lying unused?
<ogra> (or at least meaning if it came across differently :) )
<tgardner> mpoirier: between you and lag there'll be plenty to do. the pit of bugs is bottomless.
<lag> I was agreeing with you
<ogra> amitk, not to my knowledge, lets ask davidm
 * lag gets a warm fuzzy feeling
<mpoirier_> all good with me.
<mpoirier_> We all need to agree on who does what so that we don't drop the ball.
<tgardner> mpoirier_, thats what jfo does for you
<mpoirier_> Just to be clear, I'll keep fixing OMAP3 while OMAP4 support is assured by lag.
<mpoirier_> And therefore won't look at OMAP4 at this point.
<lag> I'm happy to look at either 
 * JFo looks at *
<JFo> :)
<mpoirier_> same here - no preference.
<lag> Or both
<lag> My intention was to just select bugs and work on them
<lag> I should have my OMAP3 board sometime tomorrow all being well
<amitk> ohh good, then just split up the bugs amongst yourselves
<mpoirier_> lag: beableboard ?
<lag> Yep
<amitk> mpoirier_: beagleboard, with a 'g' :)
<mpoirier_> yes, sloppy fingers this morning.
<amitk> mpoirier_: not a coffee drinker? ;)
<mpoirier_> have been going without a drop for 4 years now.
<amitk> hehe, good call
<tgardner> mpoirier_, that way lies madness
<mpoirier_> fantastic !
<ogra> mpoirier_, did yuo test the latest archive kernel already ? 
<ogra> since i cant get it to boot at all here+
 * ogra wonders if it boots for anyone else
<mpoirier_> ogra: hold on.
<mpoirier_> ogra: you mean 35-rc3 ?
<ogra> 2.6.35-2.3
<ogra> latest uploaded archive kernel
<mpoirier_> haven't no. I'll try and get back to  you.
<ogra> i seem to have issues with this patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg18213.html
<ogra> ending up with endless "Wake up daisy chain activation failed." messages and unresponsive board
<mpoirier_> gruemaster was seeing something like that when I was chasing the SD card problem.
<mpoirier_> he was trying my kernels.
<ogra> hmm
<mpoirier_> but he had some weird user space.
<ogra> yeah, and he also had mmc timeout errors
<mpoirier_> yep - you seem to have a blessed SD card.
 * ogra learned to use sandisk for actual work ... i have about ten other brands to test though and didnt see issues 
<ogra> but i used 2.6.34 until this morning since i needed a reliable kernel for the image building stuff
<ogra> now i built the first image with .35 which got me the new issues (no mmc timeouts though)
<mpoirier_> fabulous !
<mpoirier_> I should have a fix soon.
<ogra> great
<mpoirier_> fix for SD card that is - no nothing about daisy chain.
<mpoirier_> I'll try to reproduce
<manjo> lag, you can also cat /etc/issues 
<lag> cat: /etc/issues: No such file or directory
<manjo> cat /etc/issue
<lag> Ubuntu 10.04 LTS \n \l 
<manjo> sconklin, you are cutting off 
<manjo> sconklin, stop your upload 
<manjo> sconklin, you not audiable 
<sconklin> let me try restarting mumble
<manjo> sucks
<manjo> sconklin, sucks
<sconklin> I give up
<manjo> sconklin, you need a better ISP
<sconklin> JFo: please catch me on IRC after the meeting
<JFo> will do sconklin 
<manjo> apw, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.
<manjo> tag=kernel-candidate&field.tags_combinator=ALL&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_no_branches.used=&search=Search
<manjo> http://qa.ubuntu.com/reports/jfo/kernel-Top50.html
<manjo> http://goo.gl/jwSj
<sconklin> I can hear.
<JFo> heh
<sconklin> Just that this might be a situation where we would consider attempting to write a fix
<sconklin> Several of the ones I put on the list would require significant dedication of engineer resources
<sconklin> might just be a backport
<sconklin> I think this can be backported but isn't in stable yet
<sconklin> I can look at that
<sconklin> ok, I'll see if it applies and builds and send a review request?
<sconklin> stefan, OK?
<sconklin> :)
<sconklin> all good on the previous one
<JFo> cool
<sconklin> move on
<sconklin> X61 clone mode
<sconklin> Yeah, that's what we have to talk about mostly
<sconklin> This is apparently a big deal, and ~something~ should be done, but I think it falls on the HWE people
<sconklin> It was explained in private email that we have to fix it even in a private custom build
<sconklin> presales, willing to take a custom ppa build
<sconklin> I don't think we have the hardware to reproduce it
<sconklin> I think it was all ripped out
<sconklin> next two and the last one on the list may all be the same bug. There is a brand-new upstream patch that I'm going to put in a PPA for testing.  There are still more bugs which may be the same one. I'm working on this whether it's on the list or not, so it doesn't matter if it's in the top 50
<sconklin> that sounds good
<sconklin> NO
<sconklin> See whether the patch fixes all of them
<sconklin> good!
<manjo> http://qa.ubuntu.com/reports/jfo/kernel-buglist.html
<falktx_> hi guys
<falktx_> is this the right place for kernel specific issues?
<abogani2> falktx_: yes
<falktx_> my friend is having issues with a new kernel
<falktx_> the mininote 
<falktx_> it worked on 2.6.32-21
<falktx_> but not with 2.6.32-22
<_guitarman_> yes this is me...
<falktx_> _guitarman_: please explain
<_guitarman_> my hp mininote 110 seemed to work ok when upgraded from karmic to lucid, but then i wiped it and did a clean install of lucid and now although i have 2.6.32-22 kernel, only the 2.6.32-21 kernel will boot
<_guitarman_> the other kernel just sits there nothing displays - just a flashing cursor at the top left
<_guitarman_> i am not sure if this is updates to the system that bust it, or if it is hard disk geometry or grub or what.
<_guitarman_> any thoughts
 * _guitarman_ is also googling
<abogani2> _guitarman_: Could you try to remove the kernel command line options "quiet" and "splash"?
<tgardner> smb, bjf: ^^ possible Lucid regression
<bjf> tgardner, ack
<_guitarman_> abogani2: i will try this now and let you know
<abogani2> _guitarman_: I hope that you are using an other computer for IRC... ;-)
<_guitarman_> heheh yup
<abogani2> _guitarman_: In meanwhile could you give me some details about your installation? Did you have install closed video drivers for example?
<_guitarman_> ok so... i installed the ubuntu fwcutter driver for the broadcomm wireless whereas before i think i used STA
<_guitarman_> that may be an issue
<_guitarman_> abogani2: i booted and it hangs while running /scripts/local-top ... final item is ata4: DUMMY usb 1-5: new high speed usb device using ehci_hcd and address 3
<abogani2> _guitarman_: The ALT+SysReq keystroke works?
<_guitarman_> no
<_guitarman_> its hard locked
<abogani2> _guitarman_: Sorry I meant the ALT+SysReq+S keystroke works?
<_guitarman_> abogani2: you mean RSEIUB? nope nothing works in here... and if you mean alt-sysrequest,S <-- letter S? that doesn't do anything either
<_guitarman_> abogani2: pressing that now while it is sitting here doesn't help
<smb> tgardner, That would be the day0 update
<smb> tgardner, Maybe he wants to try the -23 kernel
<_guitarman_> abogani2: do you think if i boot into .21, change wireless driver to sta, reboot and try 22 - would that help identify if thats the conflicting driver that is stopping boot?
<tgardner> smb, um, I can't remember what was in the day 0 update.
<ogasawara> apw, abogani2: I'm dropping preempt from linux-meta.  Was an oversight on my part when we dropped it in the linux package.
<apw> ogasawara, cool thanks
<abogani2> _guitarman_: Yes!
<abogani2> ogasawara: Thanks!
<_guitarman_> abogani2: ok, i'll do that now
 * smb reboots to nohpet to try to fix his strange disconnects
<falktx_> i noticed a new kernel update in proposed
<falktx_> _guitarman_: u should try it
<_guitarman_> falktx_: sorry - i will try tihs first then look at the kernel update at least it will help isolate the issue. for some reason the hardware drivers applet is misbehaving in kubuntu
<_guitarman_> says sorry-jockey - systemerror:installarchives()failed
<falktx_> _guitarman_: did u try other kernel versions?
<_guitarman_> is there a way i can do this from cmd line abogani2 falktx_ ? choose the restricted driver
<falktx_> 2.6.33/34?
<_guitarman_> falktx_: .33 is a fail
<_guitarman_> falktx_: i haven't tried .34
<falktx_> i have to go
<falktx_> _guitarman_: i hope it works
<_guitarman_> ok take care falktx_ talk to ytou later
<_guitarman_> falktx_: thx
<abogani2> _guitarman_: :-?
<_guitarman_> abogani2: restricted driver install isn't working in kubuntu proper for me
<abogani2> _guitarman_: Which driver you are trying to remove?
<_guitarman_> it says that error: sorry-jockey - SystemnError:InstallArchves()failed
<_guitarman_> abogani2: happens when i make any change in restricted hardware. active, deactiveate etc.
<methril_work> some kernel release manager here*
<methril_work> ?
<_guitarman_> i tried to deactivate the b43 and activate the sta wireless driver but it said that error
<_guitarman_> abogani2: then when i log out and log back in, i only had sta listed as a choice and i still couldn't activate it
<_guitarman_> abogani2: yipes, now my .21 won't boot
 * _guitarman_ is screwed
<_guitarman_> abogani2: booted into recovery .21 kernel in single user, then telinit 4 , startx and i am in again.  going to see what restricted drivers looks like now
<abogani2> _guitarman_: sudo apt-get remove --purge b43-fwcutter
<_guitarman_> abogani2: will do that now
 * abogani2 goes off for 10 minutes
<_guitarman_> abogani2: ok, i've done that
<_guitarman_> ugh.
<methril_work> what is the process to ask for a update of the luci kernel?
<_guitarman_> abogani2: it removed it, tried to load again, and didn't have source for this kernel anymore then tryied it for my rtkernel .33 and that bailed.. now i have bcmwl-kernel-source as a error in dpkg
<methril_work> i`ve to fill a bug asking for a release update?
<_guitarman_> abogani2: how can i install and activate the broadcom sta wireless driver now - through the hardware drivers applet which doesn't seem tob e working or is there a way to do that in apt
<eagles0513875> hey guys i have a question for yall
<eagles0513875> what would cause a kernel panic relating to the VFS
<_guitarman_> abogani2: will installing broadcom-sta-common and -source get it going?
<eagles0513875> _guitarman_: what card
<_guitarman_> eagles0513875: BCM4312
<_guitarman_> 80211b/g rev01
<eagles0513875> _guitarman_: give me a sec
<_guitarman_> eagles0513875: the whole problem i am having is kernels 2.6.32-22 and 23-realtime don't boot on my hpmininote... i was trying to see if it was that i was using the b43-fwcutter driver being an issue. but the hardware drivers applet wasn't working proper
<_guitarman_> eagles0513875: my 2.6.32-21 kernel boots but even it is sometimes failing and i can then get in via recovery option for the -21 kernel.
<_guitarman_> eagles0513875: so i was trying to install and activate it via apt to then reboot and see if that driver ws the cause of hanging boot on 22 and 23
<eagles0513875> guitarman i have always used the b43-fwcutter no  problem
<_guitarman_> i am trying it out this way to see if that is the issue of the booting no working
<eagles0513875> O_o
<eagles0513875> booting not working???
<_guitarman_> i've just tried to apt-get install the broadcom-sta-common and -source to see if the reboot into kernel -22 and -23 works with it
<_guitarman_> eagles0513875: nope - hpmininote won't boot into the -22 and 23 kernels but will boot sometimes into -21
<eagles0513875> strange im having other nightmares with lucid on my desktop 
<_guitarman_> eagles0513875: i wondered if it was the driver so i tried removing it and rebooting. 
<eagles0513875> not wifi related though :( 
<_guitarman_> eagles0513875: heheh yeah. good times
<eagles0513875> _guitarman_: did you upgrade from karmic to lucid
<_guitarman_> eagles0513875: that install worke dfine
<_guitarman_> eagles0513875: i did a clean install and had probs!
<_guitarman_> funny eh
<eagles0513875> what kinda problems outa curiosity
<_guitarman_> eagles0513875: the clean install?
<eagles0513875> ya
<_guitarman_> eagles0513875: oddly my microphone didn't work when it did before (onboard mic)
<eagles0513875> using a live usb for me i ended up with a kernel panic something about a VFS not being able to mount
<eagles0513875> that was on reboot 
<eagles0513875> trying with a cd now to install 
<_guitarman_> eagles0513875: oh thats an odd one
<eagles0513875> ya
<eagles0513875> and i also get file mismatches as well when copying .so files some times which sometimes with constant hitting of retry get copied other times they dont :( 
<eagles0513875> knock on wood that hasnt happened yet 
<eagles0513875> ive isolated part of my issue to a faulty sata cable
<eagles0513875> cant dual boot cuz my cd drive cant read my win 7 dvd
<_guitarman_> oh sounds like a bit of a picle
<_guitarman_> pickle
<eagles0513875> ya
<eagles0513875> thought it was the surge protector which didnt protect me 
<eagles0513875> which was the case 
<eagles0513875> the problem was worse then it is now atm 
<eagles0513875> _guitarman_: join me in hi_jack_this
<eagles0513875> its just a channel full of tech nuts hehe
<eagles0513875> we provide support to each other etc
<_guitarman_> heheh interesting
<abogani2> _guitarman_: Could you boot your mininote on 2.6.32-22-generic without b43-fwcutter and without STA?
<eagles0513875> btw _guitarman_ do you have both of them installed cuz i tried the sta and i had issues with it and it ended up not working so i uninstalled sta and went with the fwcutter
<_guitarman_> abogani2: i tried it and it doesn't work
<_guitarman_> abogani2: i wonder if there is a loose cable or something ... i'm at a loss.
<_guitarman_> abogani2: windows 7 is still on here and it works fine
<_guitarman_> :(
<eagles0513875> _guitarman_: do you have the same issue with karmic
<eagles0513875> here goes nothing on my reboot
<_guitarman_> eagles0513875: well this is the odd thing... karmic upgrade to lucid was fine... fresh lucid install was not fine
<eagles0513875> O_o
<abogani2> _guitarman_: So b43-fwcutter and STA are unrelated.
<_guitarman_> good luck on your reboot eagles0513875 
<eagles0513875> thanks _guitarman_ :) and so far it is looking good :) 
<eagles0513875> yay
<_guitarman_> abogani2: i guess thats what this would indicate
<abogani2> _guitarman_: Are your sure that STA driver is removed?
<_guitarman_> abogani2: well, neither driver shows as active in the hardware drivers app.  i did purge on both but got some errors
<abogani2> _guitarman_: c&p on paste.ubuntu.com
<_guitarman_> abogani2: ok 1 moment. booting back in
<jjohansen> -> Lunch
 * smb is out
 * JFo wanders off to get headache medicine
<_guitarman_> abogani2: http://paste.ubuntu.com/449790
<abogani2> _guitarman_: Please remove 33-realtime.
<_guitarman_> abogani2: did sudo apt-get remove --purge kxstudio-kernel-realtime-33 ... done
<_guitarman_> it still trying to build initial module for 2.6.33-1-realtime
<_guitarman_> the bcmwl-kernel-source
<abogani2> _guitarman_: reboot and remove b43-fwcutter and bcmwl-kernel source too
<_guitarman_> abogani2: ok, will do
<abogani2> _guitarman_: I'm wondering where is kxstudio-kernel-realtime-33 package come from?
<_guitarman_> isn't it in your repo?
<_guitarman_> abogani2: 
<_guitarman_> abogani2:  or did falktx put it in his as well
 * _guitarman_ wonders
<abogani2> I don't have idea what kxstudio stand for...
<_guitarman_> k must be for kde
<_guitarman_> abogani2: apparently thats done
<_guitarman_> abogani2: removed
<abogani2> _guitarman_: b43* and bcmwl* too?
<_guitarman_> yes
<abogani2> _guitarman_: uname -a?
<_guitarman_> right now i am in 2.6.32-12
<abogani2> _guitarman_: So now we have booting system at least. :-)
<_guitarman_> i'm not sure why the realtime still shows in grub
<_guitarman_> i removed the package
<abogani2> ls -l /boot
<_guitarman_> ah .. i searched realtime and see stuff there
<_guitarman_> removing
<abogani2> _guitarman_: Good.
<abogani2> _guitarman_: Try sudo update-grub to be sure.
<_guitarman_> thats better
<_guitarman_> now only have the -22-lowlatency and -22-tgeneric and -21-generic
<_guitarman_> shall i try and reboot now that we have wifi cleared out and realtime kernel removed?
<abogani2> _guitarman_: Yes.
<abogani2> _guitarman_: 32-22-generic
<_guitarman_> rebooting now
<_guitarman_> abogani2: stuck again. :(
<_guitarman_> i guess its not that
<_guitarman_> i wonder what the difference is between the 2 kernels
<_guitarman_> abogani2: shall i remove 22 and reinstall it?
<abogani2> _guitarman_: No but you can try to update initrd image: sudo update-initramfs -u -k all 
<abogani2> _guitarman_: At the end reboot removing quiet and splash options.
<methril_work> how you mark a bug as superseed
<methril_work> ?
<JFo> methril_work, what do you mean superseeded?
<methril_work> bug #588832 superseeds #575853
<ubot2> Launchpad bug 588832 in linux (Ubuntu Lucid) (and 1 other project) "[Lucid] Update to 2.6.32.14/15 Stable Kernel (affects: 2) (heat: 16)" [Undecided,Fix committed] https://launchpad.net/bugs/588832
<JFo> bugs don't really supersede each other
<JFo> if one is invalid
<JFo> then that should be the status it is changed to 
<JFo> with a pointer to the bug that made it invalid
<methril_work> if you apply 2.6.32.15. you could close the 2.6.32.12 one
<methril_work> ok
<methril_work> only release team members are allowed to do that?
<_guitarman_> abogani2: thx did that and rebooting and will clear out those options and see what happenes inb the -22 kernel.
<JFo> methril_work, I think bugsquad or bugcontrol can
<JFo> not sure who else
<JFo> I know I can, but not sure which team I get it from
<methril_work> also i see the same situation with #583414
<_guitarman_> abogani2: its being a real pest... hangs at the same place - ata4:dummy
<methril_work> i`m trying to learn the ubuntu-way of bug fixing ;)
<JFo> methril_work, are you meaning that they are duplicates in some way?
<abogani2> _guitarman_: Could you capture the sreen?
<abogani2> *screen
<methril_work> JFo: The #575853 refers to update to 2.6.32.12. the #583414 refers to update the 2.6.32.13 and the #588832 refers to update to 2.6.32.14/15
<methril_work> JFo: i don`t think are duplicates
<methril_work> JFo: but in some way they are
<methril_work> the usuall way is to mark them as duplicates?
<_guitarman_> abogani2: i don't have a camera
<_guitarman_> i can type it if you like into paste.ubuntu.come
<_guitarman_> com
<_guitarman_> abogani2: working on it now.
<abogani2> _guitarman_: The ALT+SysRQ+H don't print anything on the screen?
<_guitarman_> abogani2: that does nothing
<_guitarman_> its full on locked
<JFo> methril_work, no, that is the way things used to work. we are on a no duplication of bugs policy now
<JFo> the effort is designed to have all reporters file new bugs per issues
<JFo> issue*
<_guitarman_> abogani2: almost done typing
<_guitarman_> lol
<_guitarman_> abogani2: http://paste.ubuntu.com/449810/
<_guitarman_> done pheuf.  thats booting the -22 kernel... the 21 boots fine ... i going to lunch now with co-worker
<shadeslayer> um ... just to promote my bug : bug 593041
<_guitarman_> thx for all your sleuthwork so far abogani2 :)
<ubot2> Launchpad bug 593041 in linux (Ubuntu) "New 2.6.35 kernel keeps toggling bluetooth radio (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/593041
<shadeslayer> ive tried the mainline kernel as well... 
<abogani2> _guitarman_: :-)
<methril_work> JFo, could i promote the bug as fixed or works for me? I would like to help reducing the SRUs
<abogani2> _guitarman_: I suspect than the culprit is the line 12
 * _guitarman_ hasn't left yet... still chewing on sandwich
<_guitarman_> abogani2: b43 ... bug in -22 ?
<abogani2> _guitarman_: IMO You shouldn't have that line (aka b43*).
<_guitarman_> because we removed it right
<abogani2> Exactly.
<_guitarman_> i dont understand what went wrong
<_guitarman_> what exact command should i run
<_guitarman_> i ran the one you suggested
<abogani2> _guitarman_: Try to add these lines on /etc/modprobe.d/blacklist.conf:
<abogani2> blacklist b43
<abogani2> blacklist b43legacy
<_guitarman_> ok doing now
<abogani2> _guitarman_: blacklist ssb
<abogani2> _guitarman_: sudo update-initramfs -u -k all
<abogani2> the reboot
<abogani2> *then
<JFo> methril_work, I usually ping the original reporter asking if it is still an issue in the latest release version
<JFo> if so, a test of the latest mainline is in order
<JFo> based on the answer, I determine if it can be closed
<_guitarman_> ack now no kernels boot - this is before i had a chance to do as suggested.
<_guitarman_> abogani2: i am going to hit lunch now since this is going to require a livecd and chroot
<_guitarman_> i will let you know if that works after i get back
<abogani2> _guitarman_: Ok. 
<tgardner> ogasawara, is the one apw was referring to? http://lkml.org/lkml/2010/6/13/155
<tgardner> is this*
<ogasawara> tgardner: yep, it's already in Dave's net-2.6
<tgardner> ogasawara, cool. thanks
<ogasawara> tgardner: so I just pulled it from there
<tgardner> wfm
<manjo> sconklin, you are broken
<dgtombs> anyone here willing to help me with ACPI backlight stuff? i want to make a DebuggingBacklight page on the wiki since there seems to be no solid information on how to debug this
#ubuntu-kernel 2010-06-15
<jjohansen> -> walk
 * smb pries open his eyes
<smb> cking, g'morning
<cking> good morning!!!
<smb> Woah! Not so enthusiasticly :-P
<cking> oh, ok, how about:  yawn, morning... *sigh*
<cking> ;-)
<smb> Ah much better :=
<cooloney> good morning smb and cking 
<ikepanhc> good morning
<smb> cooloney, morning o king of SMS
<cooloney> smb: i guess no SMS here. hehe
<ikepanhc> smb: I read your email, what you mean is we plan to removing control*?
<ikepanhc> smb: I look into the hardy tree, looks like netbook branch is using the same control/control.stub with master branch
 * cking starts trawling through a load of BIOS bugs
<smb> ikepanhc, Can you give me more context of what I said? I am not sure what exactly I wrote when. I don't think I will remove any of the control files on the master branch.
<smb> ikepanhc, Maybe you mean my stuff about removing kernel-versions
<smb> in your branch
<smb> as you removed the other two files
<ikepanhc> smb: if master branch not to remove them, I vote for not to remove them in netbook branch...
<ikepanhc> smb: sorry for making you confusing because of changing mild
<smb> ikepanhc, No worries. Its done later, so why not think about it. I am just a bit conservative there. As Hardy is out that long
<smb> ikepanhc, Still you would be free to do your own thing there.
<smb> Whatever seems better to you
<smb> Actually the lpia branch is already different in that it checks no abi files
<ikepanhc> smb: let me 'fdr clean' again to make sure what will happen on those three files
<smb> ikepanhc, I guess all three will be re-created. The main reason for keeping them was to avoid a failure when you run something else. And clean is not the most obvious way to create something.
<ikepanhc> smb: for Jaunty and later release, we need to 'fdr clean' before doing anything else, do we expect the same on hardy release?
<ikepanhc> anything means 'debuild -S' and 'fdr binary'
<cooloney> ikepanhc: debuild -S is a command to build source package
<smb> ikepanhc, I would not, but more because a lot of things changed after Hardy. So I am prepared to difference there
<ikepanhc> cooloney: I know
<cooloney> ikepanhc: fdr bianry is for building binary package.
<smb> ikepanhc, We need to rename cooloney to man-bot. :)
<ikepanhc> :)
<smb> ikepanhc, For me its just one more difference of things in Hardy compared to the later releases that I don't want to make it different as that might surprise other people. (same with Dapper)
<cooloney> smb and ikepanhc, hehe, man-bot is more popular than bugbot
<ikepanhc> smb: agree, so I prepare the tree again, not to remove control and control.stub this time
<smb> cooloney, Maybe as popular as the talking office clip... >:-P
<ikepanhc> smb: just "as it was"
<jk-> "it looks like you're trying to package a kernel ..."
<smb> jk-, :)
<ikepanhc> btw, the kernel-version is re-created by kernel-wedge?
<smb> ikepanhc, Ok. I was saying you could keep it as you like. But there actually might be a sort of dependency when using the rebase script later. And for kernel-version, yes
 * apw thinks we should rip them out of hardy master too ...
<apw> rend, tear, shread
<smb> apw, Its a needless change to a working environment
<smb> You just should not expect that an old release behaves the same as a new one
 * apw puts his mining hat on ... "i'll get them captain"
<apw> smb, by that measure debian commonisation back to jaunty makes no sense, but i really have no firm oppinion
<smb> I am not really sure about Jaunty either. But at least Jaunty is more similar to Karmic and Lucid that to Hardy
<smb> In Hardy we have custom binary build blocks which are nowhere else
<apw> smb, if we wait long enough jaunty will fix itself :)  and no i wouldn't suggest any major changes to hardy anyhow
<apw> though i am not sure that removing those built files would be such a big change, it has stopped a lot of error in later releases
<smb> apw, If we wait long enough even Hardy fixes itself... All just a matter of time. :)
<apw> heh indeed
<ikepanhc> fixed itself.... I like it
<ikepanhc> btw, I heard hardy netbook branch will fix itself at March 2011
<smb> Well yes, you cannot create a source package without them rather than with the wrong files
<smb> ikepanhc, Then you would be more lucky than me
<smb> :)
<ikepanhc> smb: ah, yeah, the EOL for you is to 2013
<apw> smb when does hardy desktop support finish ?
<apw> is that the same time as dapper comes off completely ?
<amitk> weber finance loan company <weberfinanceloan@gmail.com> has been
<amitk> successfully subscribed to kernel-team.
<jk-> sweet
<amitk> apw: ^^ what are the chances we've got a spammer
<smb> apw, I am just thinking that there might be people out there that use the Hardy git repo as a base and might get surprised. Sure it would "just" be a educational process. But then, I usually update the files on abi bum. Or find out on my test builds...
<smb> apw, Dapper-server goes off in Apris 2011
<apw> smb we like supprising people on my side of "conservatism valley"
<smb> apw, We know we live on opposite ends of that. :)
<apw> smb, so i assume as hardy is 2 years behind, and desktop is 2 years less than server, that it goes at the saem time ?
<apw> smb, na i live in the middle, tim lives on the other side :)
<smb> hehe
<smb> apw, I usually check the times on the wiki. And usually I am surprised every time I do
<apw> smb, got a link to the support wiki ?
<smb> http://wiki.ubuntu.com :)
<apw> i can never find the support info ... i hate the wiki
<smb> Hardy: Destop till Apr-2011 and Server till Apt-2013
<apw> smb, so we do drop off desktop as we drop dapper, sweet
<apw> smb, s
<smb> Or even https://wiki.ubuntu.com/Releases. Right
<apw> smb, shouldn't dapper be on that list ?
<apw> and i note dapper says june
<smb> apw, Remember what I said about being surprised
<apw> well as it was a .06 that makes sense, though i had heard apr recently for it
<smb> There is a last column on the Release page
<smb> Oh, yeah
<smb> Err
<apw> gitk origin/ti-map4 ti-omap4 ^v2.6.32
<apw> git reset --hard origin/ti-omap4
<Sleep_Walker> hi amitk, do I understand correctly that there is currently no driver for SD and framebuffer for i.MX51 based machines?
<cooloney> apw: are you reviewing the ti-omap4 branch?
<apw> cooloney, not that i know of, should i be ?
<Sleep_Walker> (in upstream)
<apw> cooloney, oh i see, no i was helping out lag
<cooloney> apw: got it, hehe
<jk-> Sleep_Walker: that's correct
<Sleep_Walker> jk-: ah, ok, well, I'm sick this week and I'd like to help a bit - any suggestions what is needed and what doesn't anyone work on?
<jk-> Sleep_Walker: I think it's just a matter of having the time to work on it
<Sleep_Walker> jk-: I see, I'll try to have a look on SD then
<jk-> Sleep_Walker: yeah, that'd be my preference
<jk-> but you may want to catch amitk first to make sure.
<Sleep_Walker> jk-: ok, I first read some doc
<jk-> excellent plan :)
<Sleep_Walker> :b
<cooloney> apw: if i change a module driver to compile it into kernel, need i remove the module name from the abi module list file?
<cooloney> apw: is that the right way to avoid the module check failure?
<apw> you need to do something to stop the error yes
<apw> you can either remove it from the modules list or you can add it to modules.ignore
<cooloney> apw: but removing is removing from the previous ABI module list file, right?
<cooloney> apw: so after we bump abi, the new module list file of the new abi won't contain the module name which i removed, i think
<apw> yes
<apw> correct
<cooloney> apw: ok, i understand. thanks
<amitk> Sleep_Walker: correct, nothing in mainline. But I'll take patches :)
<trapmax> during system update & restart, noticed this: http://pastebin.com/cF1TVjx1
<Sleep_Walker> amitk: there are imxmmc.c and mxcmmc.c for other i.MX processors, can it be good start or it is mostly incompatibile?
<apw> trapmax, that looks liek its telling you that you have queueing state for a device which is configured not to do queuing, odd
<trapmax> apw: ok. what actions would you suggest?
<amitk> Sleep_Walker: Freescale have created a new file drivers/mmc/host/mx_sdhci.[ch]. You'll have to look at how much of that you can merge into the existing drivers
<Sleep_Walker> amitk: yeah, already reading these, but it looks like one file to all MXC MMCs
<Sleep_Walker> amitk: that's the reason I ask
<Sleep_Walker> I understand that it looks weird with all that "quirks", but it reduce reduntant code a lot
<Sleep_Walker> I'll read more
<amitk> Sleep_Walker: Do you mean that drivers/mmc/host/mx_sdhci.* essentially replaces mxcmmc.c ?
 * amitk waves to BenC 
 * BenC waves back
<manjo> cking, so every thing looks like a go for monday, there still is no installer though
<shadeslayer> hey is it possible that a new kernel can disable support for middle click of external mouse?
<shadeslayer> scrolling with the wheel works fine... its just that when i press the wheel,it doesnt register a middle click
<tgardner> lag, mpoirier: I wanna bounce emerald to pick up the latest LTS kernel as soon as your builds are finished.
<mpoirier> tgardner: I'm out
<lag> ~30mins :-S
<lag> tgardner: Okay, do it!
<tgardner> lag, bouncing
 * JFo grabs some lunch before the meeting
<bjf> ##
<bjf> ## Kernel team meeting in 1 hour 15 minutes
<bjf> ##
<cking> manjo, you ok with the arrangements for testing?
<manjo> cking, yep I think so
<tseliot> mjg59: did you discuss with AMD the need to call the ATIF method in the radeon driver?
<mpoirier> tgardner: are you done with emerald ?
<mjg59> tseliot: Yes, we're still working with them on that
<tseliot> mjg59: is there some code branch where the work is being done?
<tgardner> mpoirier, pounding the shit out of it right now.
<mjg59> tseliot: No
<mjg59> We don't have permission to release any code yet
<mjg59> From AMD, that is
<tseliot> mjg59: ok, who is working on it at AMD?
<tseliot> feel free to answer in private if you can't make it public
<mjg59> Alex
<tseliot> mjg59: ok, thanks, I'll talk to him then
<bjf> ##
<bjf> ## Kernel team meeting in 25 minutes
<bjf> ##
<apw> Keybuk, hey you about?  you said you had the union-mount tool changes somewhere.  I am looking to get those so I can test this mess :)
<Keybuk> apw: yes, I'll get them out tomorrow morning
<Keybuk> they were in pbuilder when my desktop decided it didn't like life anymore yesterday
<apw> Keybuk, cool ... did you get to test the init args stuff or the ureadahead thingy ?
<Keybuk> did you build the init args stuff?
<Keybuk> last I looked there was no built kernel for that
<apw> yeah ...
<apw> hrm ... let me double check
<Keybuk> ah you didn't tell me :p
<Keybuk> cool, looks like all three are built
<Keybuk> will test tomorrow
<apw> oh both are built, they are in my red and green PPAs
<Keybuk> yup
<apw> i suspect the init args one is a slam dunk
<apw> Keybuk, so many things to track, gah
<Keybuk> aye s'ok
<manjo> Keybuk, I cced you on a mail regarding a blue print on firewire stack I fwded to ubuntu-devel 
<Keybuk> manjo: I don't have that mail
<manjo> Keybuk, just did 2mts ago :) 
<Keybuk> oh, right
<manjo> Keybuk, all we need is blacklist the old stack and whitelist the new stack modules 
<Keybuk> manjo: is up to the kernel folks, not me
<manjo> Keybuk, the email has details 
<tgardner> manjo, dpkg -S /etc/modprobe.d/blacklist-firewire.conf
<manjo> tgardner, thanks got it 
<smb> kamal, mail sent. Don't hesitate to ask. I might have been a bit terse
<kamal> smb: got it -- all very clear, no problem.
<smb> kamal, Ok, cool. Oh one addition: Please cc kernel-team list too when sending. So I know what goes out. :)
<kamal> smb: will do
<smb> thanks
<kamal> mjg59: ping
<mjg59> kamal: Hi
<kamal> mjg59: Hi - In the ubuntu-kernel team meeting we discussed proposing your patch "ACPI: Unconditionally set SCI_EN" to stable-commits.  Your thoughts on that?  (objection?  would you like to submit it, or would you like me to?)
<mjg59> I've no problem with you doing so
<kamal> great, I'll do that then.
<kamal> and while I've got you...
<kamal> what about that i915-brightness stuff?  seems to have had no further comments on the mailing list -- what next?
 * manjo luches
 * manjo getting lunch will be back soon
<mjg59> kamal: Yeah, I'll get back to that next week with luck
<kamal> mjg59: that's just fine -- thanks very much :-)
 * cking calls it a day
<manjo> apw, when I push to bzr I do, cd modules-init-tools, bzr push lp:~manjo/modules-init-tools ? 
 * ogasawara lunch
<jjohansen> -> Lunch
<jcastro> ogasawara: if you've got a few minutes to waste this afternoon I have some questions!
<ogasawara> jcastro: go ahead and post em, I'm in the middle of cleaning up a patch but I'll get to them in a bit
<jcastro> ogasawara: ok
<jcastro> ogasawara: ok so during UDS I asked about enabling fscache now that upstream has removed the experimental tag. The module looks enabled and working and all that good stuff in maverick, but # CONFIG_NFS_FSCACHE is not set
<jcastro> should I file a bug to ask for someone to enable the modules for the filesystem support?
<jcastro> (The module and userspace thing don't seem to work without it otherwise)
<jcastro> also, there's a corresponding config for AFS and 9p, but I don't think people use the latter. No idea who uses AFS these days
<apw> manjo, superm1 suggests you also ask for testing from ubuntu-mythtv@l.u.c
<manjo> JFo, ^ CFT that list ? 
<manjo> apw, yes I saw the mail from him 
<apw> manjo, ok was in irc so didn't know if you'd see it ... cool
<manjo> apw, he is the only one who responded to my RFC :)
<manjo> apw, currently upgrading my system to maveric to test package 
<tgardner> jcastro, looks like we can enable it. I'll update bug #440522
<ubot2> Launchpad bug 440522 in linux (Ubuntu) "Kernel modules not compiled (Stats, NFS, AFS, etc) (affects: 9) (dups: 1) (heat: 53)" [Wishlist,Confirmed] https://launchpad.net/bugs/440522
<jcastro> tgardner: apparently CONFIG_FSCACHE_STATS=y and CONFIG_FSCACHE_HISTOGRAM=y help with debugging, maybe a good idea to have on during alpha/beta?
<tgardner> jcastro, it depends if it has a runtime impact. I'm still looking at those
<jcastro> oh ok.
<ogasawara> jcastro: yep, typically I'd say file a bug with the request to enable the config option, but in this case I'd say we just use 440522
<ogasawara> jcastro: I'll milestone the bug for Alpha2 so it stays on the radar
<jcastro> \o/
<Delemas> Hello, can anyone point me to an example kmod block source package? I want to make a kmod-3w-sas or something similar for Lucid.
<manjo> amitk, go to sleep dude 
<amitk> manjo: it's only half past midnight :-p
<manjo> amitk, my friend will think you are a workoholic 
<manjo> amitk, I am trying to drag him to the golf course ... and he is using you as an excuse 
<amitk> naah, wife is away ;)
<manjo> lol
<manjo> amitk, tell dinh he needs some exercise 
<amitk> he is exercising his brain
<amitk> give him a few minutes
<manjo> :) was just joking 
<amitk> I know :)
<lifeless> question - 
<lifeless> I have lucid running on an i7 laptop (arrandale, 640m), with a belkin N+N wifi access point
<lifeless> is that known brain-damaged? I'm having to unload and reload iwlagn every hour or so, to stay connected.
<jpds> lifeless: Does dmesg show anything like bug #352228?
<ubot2> Launchpad bug 352228 in linux (openSUSE) (and 2 other projects) "Intel Wireless 5300 AGN: iwlagn: No space for Tx (affects: 55) (heat: 301)" [Undecided,New] https://launchpad.net/bugs/352228
<lifeless> http://pastebin.com/CMktwt73
<lifeless> dmesg | grep iwlagn | tail -n 50 | pastebinit ^
<amitk> manjo: he's not going with you
<manjo> amitk, yeah he is making excuses
<lifeless> jpds: (in short, no)
<manjo> amitk, complaining that he has a bad neck 
<manjo> amitk, I think he wants to watch the NBA finals instead
<amitk> sounds like a good excuse
<jpds> lifeless: Bug #200509 then. That error message looks familiar.
<ubot2> Launchpad bug 200509 in debian (and 3 other projects) "iwl4965: Microcode SW error detected. Restarting 0x2000000 (affects: 33) (dups: 5) (heat: 235)" [Undecided,New] https://launchpad.net/bugs/200509
<lifeless> the [ 7003.963431] iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000.
<lifeless>  line ?
<lifeless> sounds plausible, the restart is failing I guess
<lifeless> no
<lifeless> its a generic code
<lifeless> anytime the microcode asserts
<lifeless> so its got no diagnostic utility at all :(
<lifeless> comment https://bugs.edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/+bug/200509/comments/111 matches my experience
<ubot2> Launchpad bug 200509 in debian (and 3 other projects) "iwl4965: Microcode SW error detected. Restarting 0x2000000 (affects: 34) (dups: 5) (heat: 229)" [Undecided,New]
 * manjo siging out 
<anoteng> I've git-bisected a kernel bug, should I subribe/asign the bug to the committer of the first bad revision, or just leave it to triaged and hope someone sees it?
<anoteng> subribe = subscribe
<kees> hm, how do I fix this?  ->
<kees> Your branch and 'maverick/master' have diverged,
<kees> and have 9661 and 293 different commit(s) each, respectively.
<ogasawara> kees: we rebased to -rc3 recently, so I'm guessing you might need to rebase your branch to the latest master?
<ogasawara> anoteng: what's the bug#?
<kees> ogasawara: I tried, but it didn't seem to help.
<anoteng> ogasawara: #556232 
<kees> ogasawara: everything seems correct, but it keeps yelling at me every time I change branches back to my maverick branch.
<kees> I even did a reset --hard to somewhere far in the past.
<kees> ogasawara: hm, it needed: git remote update maverick
<kees> no idea why
<ogasawara> kees: hrm, I've never used that before
<kees> me either.  found the clue here: http://stackoverflow.com/questions/2298556/branches-have-apparently-diverged-but-commit-history-is-identical
<ogasawara> anoteng: unfortunately the commit you narrowed it down to was the commit which backports the 2.6.33 drm stack which was supposed to bring more stability and bug fixes, ie it's not going to be reverted
<ogasawara> anoteng: but you mentioned that a 2.6.34 kernel works fine
<ogasawara> anoteng: don't suppose you might be able to do the bisect in the opposite direction and isolate the patch which fixes the issue?
<ogasawara> anoteng: as that I think would have a better chance of being applied as a fix in an SRU
#ubuntu-kernel 2010-06-16
 * lifeless embuginates
<emma> how is the Ubuntu Kernel different than other linux kernels or the one that Linus makes?
<johanbr> see for instance http://people.canonical.com/~pgraner/talks/SELF-09/SELF-kernel-talk.pdf
<psusi> weird... CONFIG_PM_DISABLE_CONSOLE seems to be set in all Ubuntu kernels... but as of 2.6.35 in maverick, this option seems to cause my video card to not be initialized after resume from suspend... the monitor just remains powered off.. if I build the Ubuntu 2.6.35 kernel sources with this config option set to n ( otherwise exact same config as 2.6.35-3 currently in maverick ) it works fine...
<psusi> the option is set in lucid and prior kernels, but they also work fine...
<stenten> Is there that much difference between the -lucid and -maverick mainline kernels? Can Lucid users who report bugs still test with the current -maverick kernel?
<smb> stenten, If I explain this right, the difference is the base configuration used either from Lucid or Maverick. But the differences should be little enough to give useful results when testing
<apw> right, its the configuration and build machines which come from the release specified.  lucid and maverick have not divereged much as yet, i am running a maverick kernel here on my lucid install
 * apw waves morning
<lifeless> apw: hi
<lag> Morning
 * smb waves back
 * amitk waves
<stenten> smb, apw: thanks, that makes perfect sense. Thanks!
<cking> forgot to say "morning!" earlier.
<smb> cking, Meh, me too while still walking through emails
 * cking got too focused on looking a S3 issue..
<smb> cking, You suspended yourself
 * smb remembers he wanted to speak to apw this morning but forgot what that was about. Doh!
<apw> lucky escape for me then
<cking> smb, that's where a paper and pen comes in handy 
<smb> Depends on *when* you think of it
<cking> normally 3am for me
<amitk> so, any chance that the unified debian packaging will make it into lucid and karmic?
<smb> amitk, Depends on our supporters. :-P
<amitk> Did you find any after cjwatson refused it?
<smb> Not yet that I know of
<RAOF> apw: Maybe it was about how investigating drm.debug is going? :)
<apw> RAOF, i think sconklin is on that one thankfully, so i think back to bed for me
<smb> Speaking of gfx, I was thinking of doing a debugging backlight issues page. (just remembered that was one of the things I wanted to ask). Where would that best fit in the new structure of wiki pages?
<apw> Kernel/Debugging/Backlight perhaps, linking to Kernel/Debugging of course
<smb> Oh and RAOF, I have a case of messed up EDID info here which I think I somehow isolated to come from my keyboard and display switch. If I connect the monitor directly it is ok. For those kind of checksum wrong. Is there a bug you are tracking specifically, should we make a new one?
<smb> apw, Ok, sounds reasonable
<RAOF> smb: Hm.  That certainly matches at least one bug I can think of off the top of my head, but I don't have a meta-bug about it.
<RAOF> I'm not entirely sure what can be done about KVM switches, actually.  If they're corrupting the EDID then the driver is basically going to have to fall back on a list of standard modes.
<apw> RAOF, in the 35-rc1 kernel it seems that the edid processing is triggering the kslowdNNN eating my cpu issue, you know anything about it?
<apw> RAOF, one thing we need to better test and document is the kernel command line incantion to add/select a mode when one is not present
<smb> I think to remember there were a lot of edid_valid *ERROR* EDID checksum is invalid, remainder is x bugs floating around. In my case x seemed to change every now and then.
<RAOF> apw: Haven't seen that one come up, but I do recall some edid processing changes that got merged about then.
<smb> RAOF, The thing is pre-kms I believe the same switch was handled correctly
<smb> So it maybe ignored remainders or what not
<RAOF> It might have just been more lax, yeah.
<smb> It would not be the first diver adding code for the madness of hw-vendors
<smb> err, driver even
<smb> RAOF, Would you happen to have a link or doc at hand that describe how the EDID is *supposed *to be. Then I might compare that to the actual results and give better feedback there.
<RAOF> http://docs.google.com/viewer?a=v&q=cache:mYmWXgIUta0J:www.x.org/wiki/XDC2007Notes%3Faction%3DAttachFile%26do%3Dget%26target%3DXorg_2007-EDID-JMiseli.pdf+site:x.org+edid&hl=en&gl=au&pid=bl&srcid=ADGEESg0T1gecuIUJeX1isUAslw2l6RpRzhZaOymJPsc6FVEZW4NBHkG8yBPYN7wfKuw02ixtDcRz_3BtPY9b2yLCXw_vXnQYy5gTCiKzFRvjLdVr76hOieixbLRL0eYq2T-3TpiirHo&sig=AHIEtbRTUG0TlIT9VjXCPJgaYFKgp_XRRA has a bit of an overview.
<RAOF> Ooh.  That's perhaps a longer URL than I was expecting :)
<RAOF> Wikipedia has a reasonable specification http://en.wikipedia.org/wiki/Extended_display_identification_data
<smb> Cool, ok. lets see how far I get with that
<RAOF> Time to head home.  Catch you later!
<kraut> moin
<amitk> second time in two days that my x-session got killed automatically and I came back to gdm with this in dmesg:
<amitk> [15269.573089] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2
<amitk> [15272.860288] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
<amitk> [15272.877597] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
<jk--> amitk: anything interesting in Xorg.log.0.old?
<RAOF> amitk: That's just nouveau being chatty - it's closing the channel that the DDX had opened.
<amitk> jk--: yeah, 
<amitk> Backtrace:
<amitk> 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a3248]
<amitk> 1: /usr/bin/X (0x400000+0x655ad) [0x4655ad]
<amitk> 2: /lib/libpthread.so.0 (0x7fe0a36fa000+0xf8f0) [0x7fe0a37098f0]
<amitk> 3: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fe0a062b000+0x9e27) [0x7fe0a0634e27]
<amitk> 4: /usr/bin/X (0x400000+0x130ed0) [0x530ed0]
<amitk> 5: /usr/lib/xorg/modules/extensions/libextmod.so (0x7fe0a14e9000+0xf76d) [0x7fe0a14f876d]
<amitk> 6: /usr/bin/X (0x400000+0x30c3c) [0x430c3c]
<amitk> 7: /usr/bin/X (0x400000+0x261aa) [0x4261aa]
<amitk> 8: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe0a23f2c4d]
<amitk> 9: /usr/bin/X (0x400000+0x25d59) [0x425d59]
<amitk> Segmentation fault at address 0x7fe09d60d000
<jk--> amitk: before that? there should be the reason for the server exiting
<amitk> Caught signal 11 (Segmentation fault). Server aborting
<amitk> just filing a new bug
<jk--> ah, segfault
<RAOF> amitk: Has apport triggered?
<amitk> RAOF: nope, I guess because the X server gets killed and returns me to GDM?
<amitk> should apport be able to trigger from a new x session?
 * abogani2 waves
<RAOF> It should be able to grab the crash as it goes down.
<RAOF> Because it's just listening to the core dump from the kernel.
<abogani2> apw: Please don't forget me! :-)
<amitk> RAOF: bug 595022
<ubot2> Launchpad bug 595022 in xorg (Ubuntu) "noveau driver segfaults and kills X session (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595022
<amitk> apw: you really edit 20 wiki pages at the same time!
<RAOF> amitk: Ta.  If it's really easy to reproduce, a proper backtrace would make that easier to deal with.
<amitk> RAOF: you want me to install the debug packages for X?
<RAOF> They may help, but a nicely symbolic backtrace would be better.  You may be able to get that by turning on apport - it looks like you're running Lucid, which will have apport disabled.
<apw> amitk, heh i don't know why you always think that.  i am moving stuff around so i am editing 2 or 3 at once ... but not more
<amitk> apw: I think that because I see 30 emails with wiki updates from you over 20 different files
<apw> heh but that is over several hours
<amitk> RAOF: aah, i keep forgetting that we turn off apport after release. I've turned in on now.
<apw> amitk, but yes i have been doing my 'half hour' of wiki gardening today ... i am hoping someone else will do theirs this week
 * apw bitches about kslowd indeed causing slowness :/
<cking> apw, perhaps kslowd should be called kveryslowd
<apw> kcrunchycursord
<cking> kannoyapwd?
<apw> cking, kgettinghitwithadamnhammerd
<cking> heh
<apw> cking, well its definatly i915 losing its mind
<apw>   0   897 ffff88012bb07510 12  20ms DRM_CRTC_HELPER: i915@pci:0000:00:02.0
<nessita> hello everyone! Can anyone help me debugging why my sound is gone after installing the updates for maverick?
<cwillu_at_work> nessita, every week a random module is removed from maverick just to make sure that the only people using maverick are the ones who know that it's unsupported ;)
<apw> cwillu_at_work, thanks for your confidence
<apw> nessita, you have no sounds at all ?
<nessita> cwillu_at_work: I've been asked to install it, I work for the company ;-)
<apw> what does aplay -l return
<cwillu_at_work> apw, you're welcome.  I don't credit many people with the aptitude to pull off such stunts :)
<nessita> apw: not at all that I can tell
<nessita> apw: **** List of PLAYBACK Hardware Devices ****
<nessita> card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog]
<nessita>   Subdevices: 1/1
<nessita>   Subdevice #0: subdevice #0
<nessita> card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital]
<nessita>   Subdevices: 1/1
<nessita>   Subdevice #0: subdevice #0
<apw> nessita, so the kernel has recognised the card at least
<nessita> alsamixer has all settings at the top values
<apw> have you checked the alsamixer settings, to confirm that the volumes are up and not muted
<nessita> yes
<apw> could you test with headphones to confirm that those do not work either
<nessita> apw: I'm testing with those
<nessita> I tried front and back plugs
<apw> so it doesn't work with or without headphones
<nessita> apw: well, without I coulnd't say, I have no speakers
<apw> nessita, what sort of machine is this??
<nessita> apw: a desktop machine, with no speaker but great view!
<nessita> I must confess I feel like I'm loosing my computer slowly. First the eth0 was gone, then the nvidia drivers, and now the sound! /me cries
<apw> nessita, ok so first thing to do is file a bug against alsa-driver, that should get the information needed by the sound peeps to debug it
<apw> nessita, i normally don't update my userspace this early in the cycle, though i am using and suffering with the latest kernel
<apw> ubuntu-bug alsa-driver
<apw> ^^ should do the trick
<nessita> apw: on it
<apw> nessita, what ethernet card do you have ?  and have you filed a bug on that?  if not file one against linux
<nessita> ah! "package alsa-driver does not exist"
<apw> wtf
<nessita> apw: yes, the eth0 issue was follow up by tgardner, last conclusion is that I have to flash my BIOS but so far I haven't been able to
<nessita> apw: wanna a screenshot?
<cwillu_at_work> apw, what do you know about compiling/hacking on alsa against recent kernels?
<apw> wtf you really really are meant to be able to file bugs on alsa-driver
<apw> we even have an apport package_hook to make sure it wors
<apw> works
 * apw goes and moans
<cwillu_at_work> nessita, /usr/share/apport/package-hooks/source_alsa-driver.py exists?
 * apw is getting the same failure yet i have that file
<nessita> cwillu_at_work: yes, -rw-r--r-- 1 root root 187 2010-06-04 11:36 /usr/share/apport/package-hooks/source_alsa-driver.py
<apw> cwillu_at_work, not much more than the stuff we have done in the lbm packages
<nessita> apw: ah, so no need for the screenshot
<apw> nessita, na one sec let me find out whats going on
<cwillu_at_work> ah, damnit, I forgot to install sshd on my maverick box at home
<apw> cwillu_at_work, a common error on my end
<cwillu_at_work> rebuilding ubuntu's kernel packages has always been a bit mysterious to me
<nessita> apw: thanks, I'll be around
<apw> smb, hey we are meant to file audio bugs against alsa-driver right ?
<apw> nessita, hey it seems that ubuntu-bug audio is the new way forward
<nessita> apw: ok, then, filling the bug
<nessita> apw: gah, non of the options fit my issue
<nessita> shall I pick random? :-P
<apw> yeah pick one ... stupid interface
<apw> probabally the first one
<nessita> apw: hum, the tool says "the following mixer control(s) are set quite low: Master is muted..."
<nessita> I'm seeing alsamixer and all is 100%
<apw> nessita, hrm
<nessita> apw: duh
<apw> nessita, can you get me a screen shot of your alsa mixers please
<nessita> no need, it was muted indeed, but volume at 100%
<apw> nessita, ahh, and are you now deafen by the sound ?
<nessita> apw: not yet
<apw> i get quite the oopossite effect here, the machine loves to unmute things on me
<dgtombs> hi all, anybody know what mainline build is equivalent to the current maverick kernel?
<apw> v2.6.35-rc3
<dgtombs> thank you!
<nessita> apw: so, any idea why updates muted everything?
<apw> dgtombs, you can tell by looking at /proc/version_signature
<dgtombs> thanks, i'm not running maverick though :) just triaging repots
<apw> nessita, heh no, my experience is the opposite that it unmutes things and embaresses me in meetings
<apw> dgtombs, ahh i like the sound of you triaging bugs for maverick ... is jfo helping you ?
<JFo> apw, not yet
<apw> JFo <-> dgtombs 
<apw> jfo is our main triager and knows all the tricks
<dgtombs> heh
<JFo> dgtombs, have you seen the new pages at https://wiki.ubuntu.com/Kernel/BugTriage ?
<apw> can point you to the documentation we have made and all that fun stuff
<dgtombs> i'm not doing that much, just taking care of a few bugs i'm subscribed to
<nessita> apw: well, anyways, thank you very much. An since we're at it, any idea is it safe to install nvidia drivers? last time xserver update removed them
<JFo> every bit helps dgtombs 
<dgtombs> :)
<tgardner> nessita, its policy with the ALSA bunch to mute master on an update.
<nessita> tgardner: oh, and how ddo you deal with the avalanche of bugs after that? 
<apw> nessita, i don't know i'd be using them with it yet, i suspect they won't work as the kernel has jumped an enourmous ammount
<tgardner> nessita, we all get pissed off :)
<nessita> heh
<apw> nessita, well as you noticed it checked and told you off when you tried to file a bug :)
<nessita> tgardner: so, I was also looking for you. I haven't been able to flash my BIOS because the BIOS update provided by Intel requires executing an .exe file at boot time. Any idea how can I make a USD stick bootable so I can run that .exe?
<nessita> apw: right :-)
<nessita> tgardner: I have no floppy disk nor CD-DVD rom, so for now USB is my only bet
<tgardner> nessita, oh crud. lemme research that. I used to have a DOS USB gizmo.
<nessita> tgardner: the other option is to execute the .exe in a running win**** but my religion won't allow it
<mjg59> nessita: Get a freedos boot image, mount it via loopback, put the .exe on it, boot it via grub using memdisk
<tgardner> nessita, I understand :) I'm down to just one Windoze box 'cause I can't figure out how to load my nano ipod with books on tape from audible.com
<nessita> mjg59: you make it sound so easy...
<nessita> mjg59: have a link that provides some more details? like how to mount via loopback?
<mjg59> mount -o loop disk.img /mnt
<nessita> mjg59: see? you make it sound so easy :-)
<nessita> mjg59: ok, and how can I boot it using memdisk?
<cnd> apw: https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-Firmware
<tgardner> nessita, http://syslinux.zytor.com/wiki/index.php/MEMDISK
<nessita> tgardner, mjg59: thank you
<dgtombs> jfo: question if you don't mind. i've got bug 406515, it's broken in lucid & maverick still, but fixed in latest mainline. the upstream linux task is currently Invalid, should i manually set it to Fix Released even though it was never reported upstream?
<ubot2> Launchpad bug 406515 in linux (Ubuntu) (and 5 other projects) "[Karmic & Lucid Beta 1] Brightness fn keys lost functionality (Lenovo laptops) (affects: 38) (dups: 1) (heat: 218)" [Medium,Confirmed] https://launchpad.net/bugs/406515
 * tgardner bounces for a kernel updatae
 * JFo looks
<JFo> dgtombs, no, that is the bugwatch
<JFo> it gets updated automatically based on whatever bug it is watching upstream
<dgtombs> jfo: correct, but there is no bugwatch for this bug
<JFo> so it would get changed back to Invalid most likely
<JFo> if you were to change it
<dgtombs> it's an unlinked upstream task
<JFo> yeah, I'd just leave it like that
<dgtombs> ok
<dgtombs> thanks!
<JFo> my pleasure
<dgtombs> jfo: and if you'd like to set to Triaged that would be cool, too :)
 * JFo looks again
<JFo> hmm, apw you are actually assigned to that bug ^^
<JFo> bug 406515
<ubot2> Launchpad bug 406515 in linux (Ubuntu) (and 5 other projects) "[Karmic & Lucid Beta 1] Brightness fn keys lost functionality (Lenovo laptops) (affects: 38) (dups: 1) (heat: 218)" [Medium,Triaged] https://launchpad.net/bugs/406515
<apw> jfo best to assume i have forgotten all about it
<JFo> heh, that was my assumption
<dgtombs> heh, i think some of you are a little over-assigned :)
<JFo> want me to remove the assignment?
<dgtombs> in fact, if someone wouldn't mind taking a look at bug 421985, i think it should be Incomplete instead of In Progress (in fact, expired by now), but it's assigned to smb so i don't want to change it.
<ubot2> Launchpad bug 421985 in linux (Ubuntu) "System Suspends/Hibernates when AC is unplugged (affects: 17) (heat: 107)" [Undecided,In progress] https://launchpad.net/bugs/421985
<tgardner> that smb is such a slacker
<smb> I have no problem in unassining myself
<dgtombs> smb: your choice of course, i don't want to step on any toes :)
<dgtombs> pgraner seems to have forgotten about it unfortunately
<smb> dgtombs, Actually I might long time ago forgot about it
<smb> pgraner, Actually that one was reported by you...
<dgtombs> see why i was scared to mess with it? :)
<pgraner> smb: which one
<dgtombs> pgraner: bug 421985
<ubot2> Launchpad bug 421985 in linux (Ubuntu) "System Suspends/Hibernates when AC is unplugged (affects: 17) (heat: 107)" [Undecided,In progress] https://launchpad.net/bugs/421985
<smb> pgraner, The above. About suspending when removing battery on you Colovo
<pgraner> smb: Ah sorry I did forget about it, the colovo fried it power supply so its not operational anymore
<dgtombs> hah
<dgtombs> i
<dgtombs> i'll invalidate it then, i have more time than you do smb
<pgraner> smb: I really need to get it a new supply, I just forget everytime I'm out
<dgtombs> oh hmm
<smb> dgtombs, There seem to be others that had been affected
<dgtombs> smb: i think it's false duplicates
<dgtombs> there's a big bug with unplugging A/C and upower reported critical battery for a sec, affects lots of cheap netbooks. but pgraner's bug seems different
<smb> dgtombs, Ok, I let you check and invalidate it if you think those are other problem. The Colova had AFAI remember issues when reporting the batery level.
<smb> I will unassign myself for now
<dgtombs> ok. thanks for the help guys!
<Keybuk> apw: hai
<apw> Keybuk, hi ya
<Keybuk> just been testing the initargs kernel
<apw> Keybuk, hows it looking
<Keybuk> found a bug with it
<Keybuk> it's passing all the arguments properly by default, so I get "ro" and "quiet" as well as "splash" which is ideal
<Keybuk> but when you add init=... it still passes the arguments that came before it
<Keybuk> this breaks init=/bin/bash
<apw> Keybuk, i am supprised by that, as i thought init= did a full reset
<apw> i'll have a look and see whats causing that
<apw> i cirtinaly did not aim to change that functionality
<Keybuk> k, that was the only problem though
<Keybuk> otherwise it was all good
<apw> ok will go poke it
<apw> Keybuk, hrm how did you confirm this?  as the init= implementation is to zap all existing args ... it won't zap the environment though
<Keybuk> I booted with init=/bin/bash and it failed because "ro: no such file or directory" ;-)
<Keybuk> (as the kernel called init=/bin/bash ro quiet splash -- so bash intepreted ro as a script to run)
<apw> hrm
<Keybuk> I also tried a shell script that echo'd the command-line it received, that shows the previous args too
<apw> Keybuk, most perplexing as the handling of init= is unchanged as is the method by which they are inserted into the array
<apw> so its behaviour seems hard to have affected
<apw> can you do the same test with a stock kernel to confirm its working ever
 * apw installs the test kernel in parrallel to retest, as he thought he had also tested this
<apw> Keybuk, ok i've managed to reproduce it here ... will debug it
<amitk> "Slashdot: Location Services Raise Privacy Concerns" - really??! Who would've thunk?
<Keybuk> works just fine on mainline and stock ubuntu
<tgardner> amitk, and you wonder why I'm such a luddite?
<apw> Keybuk, yeah most odd, how i missed testing it i don't know
<Keybuk> is only the initargs kernel that passes the args before init=
<Keybuk> talking of mainline kernels
<Keybuk> iwl3945 doesn't work in mainline either - what should I do now?
<amitk> tgardner: your next phone is going to be a 'smart'phone, whether you like it or not. _That_ is what you should be worried about.
<apw> so not working in either maverick or mainline kernels hrm ... i guess we need a bug filed with that info
<tgardner> amitk, yeah, I know. I've been dragging my feet.
<apw> tgardner, you heard anytihng about iwl3945 breaking?
<tgardner> apw, nope. how is it breaking?
<apw> Keybuk, ^^
<Keybuk> tgrnot associating via WPA
<Keybuk> tgardner: not assoc...
<tgardner> Keybuk, does it work with a simple open AP ?
<tgardner> there are some scanning patches in the pipeline from Intel, but they'll have to wain until -rc4
<tgardner> wait*
<Keybuk> tgardner: I don't have a simple open AP to test with
<Keybuk> scanning seems to work fine, it can see the networks, just not join them
<tgardner> I'm not sure I have one of those gizmos anymore. All I have are i4965.
 * apw sends Keybuk to starbucks
<Keybuk> ooh, hang on, there's a wifi router inside my modem
<Keybuk> I can enable that
<Keybuk> at least, I could if Linux wasn't shit
<Keybuk> tgardner: it can associate to the open AP, but packet delivery appears to be failing
<tgardner> Keybuk, ok, start a bug report and I'll see if I can get Reinette's attention with it.
<Keybuk> ah, no
<Keybuk> I hadn't enabled the DHCP server ;-)
<Keybuk> it works fine in open AP mode
<Keybuk> so it's WPA that doesn't work
<apw> Keybuk, can you up it to WEP and test that perhaps
<tgardner> Keybuk, still, a lot of folks use WPA. Is it WPA/PSK using TKIP ?
<Keybuk> yus
<Keybuk> WPA2 to be precise
<tgardner> Keybuk, right, thats the most common setup
<Keybuk> WEP seems fine
<tgardner> Keybuk, so, it likely has something to do with key exchange
<Keybuk> WPA1 doesn't work
<Keybuk> huh, weird
<Keybuk> it seems that the DHCPDISCOVER is getting out
<Keybuk> but it's the return packets that aren't
<tgardner> Keybuk, so its completing assoc, but can't receive directed data packets?
<Keybuk> sounds it
<tgardner> Keybuk, get all of this in a bug and assign me to it. it seems like a serious regression that we'd like to fix.
<Keybuk> if you don't fix it, I know where you live
<Keybuk> and I can have mini screwdrivers
<Keybuk> I can swap one of your 4965 mini-pci cards with this one
<Keybuk> <g>
<tgardner> Keybuk, ah, you know approx where I live, but not _when_ I'll be there :)
<Keybuk> tgardner: you don't have to be in
 * Keybuk is quite worried that the only working computer in his house is running Mac OS X
<Keybuk> actually, technically, the three working devices in my house are all running Mac OS X
<tgardner> Keybuk, thats a fairly broad statement. I have at least one laptop thats working quite well with Maverick.
<Keybuk> my laptop (maverick) won't associate to the wifi
<Keybuk> my desktop powers off if USB devices are attached
<tgardner> Keybuk, so, you never have to hit the power switch again? Isn't that a feature?
<Keybuk> actually, that's unfair; the server is still purring on nicely ;-)
<tgardner> that reminds me, I need to do some server upgrades.
<Keybuk> and the PS/3 isn't running Mac OS X
<tgardner> is that the port that Colin and Ben did?
<Keybuk> the PS/3 is running PS/3 ;-)
<Keybuk> you can't run Linux on them anymore
<Keybuk> (and I never tried)
<tgardner> tahts what I thought. Seems like it was Feisty timeframe
<Keybuk> Colin would remember, though probably not a good idea to ask, I think the nightmares have only recently stopped
<Keybuk> Kirsten hasn't remarked on him sitting bolt upright in bed and screaming "CEEEEELLLLLLLLLLLLLLLLLLLLLLLLLLLLLL!" in a Kahn-like way for a while
<kirkland> hey apw, where are those daily vanilla kernels?
<tgardner> kirkland, http://kernel.ubuntu.com/~kernel-ppa/mainline
<apw> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
<Keybuk> kirkland: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<kirkland> tgardner: Keybuk: thanks
<kirkland> tgardner: any known, bad crypto regressions with 2.6.34?
<tgardner> kirkland, not that have brought to my attention
<tgardner> benn brought*
<kirkland> tgardner: we're having a strange eucalyptus issue
<kirkland> tgardner: only happens when we're decrypting an image, which should be happening entirely in userspace
<kirkland> tgardner: UEC on Maverick with Maverick's kernel doesn't work (ie, can't do that decryption)
<kirkland> tgardner: UEC on Maverick with Lucid's kernel works fine
<tgardner> kirkland, reading from an encrypted mount?
<kirkland> tgardner: i'm not entirely sure;  i think it's some userspace decryption in the Java code
<tgardner> kirkland, hmm, how does that use kernel encrypt/decrypt ?
<kirkland> tgardner: no idea;  we just know that it works when running one kernel, but not the other
<kirkland> tgardner: i'm not working on this directly, just trying to get the guys focused in the right direction
<tgardner> kirkland, does that java machine fail in other ways?
<kirkland> tgardner: not sure;  my guess is that it was always doing something slightly wrong somehow, and with newer kernels, the failure is more pronounced
<kirkland> tgardner: we'll dig
<kirkland> Daviey: ping
<Daviey> kirkland:  o/
<tgardner> kirkland, k, I'll await word back from you
<kirkland> Daviey: see the discussion up there between me and tgardner 
<kirkland> Daviey: regarding UEC in maverick
<kirkland> Daviey: are you working this issue actively, or is it background?
<apw> tgardner, i wonder if it could be using a loop back encrypted mount sort of thing ?
<apw> tgardner, and i wonder if it and wpa2 not working could be related, they are both encrypted
<Daviey> kirkland: both.. at the moment none of UEC works.. so it's hard to test that issue
<Daviey> apw: I did wonder if it's a lack of entropy or something
<apw> Daviey, i would expect it to hang in that case perhaps
<Daviey> Either way, ttx reproduced it today on latest maverick kernel with Alpha1 userspace.
<Daviey> (i've also just reproduced it that was aswell)
<tgardner> apw, if that were the case then no iwlwifi device would work, right?
<apw> tgardner, fair comment, are you using wpa2 ?
<tgardner> apw, AFAIK
<ttx> It's definitely triggered by the kernel change... not sure if it's just a stricter kernel no longer supporting borderline cases, or just a plain regression
 * apw has wep here due to a crappy work laptop the lass has
<tgardner> wpa something, probably WPA2
<apw> ttx, need to find out what it exactly doing ...
<tgardner> ttx, kirkland: is there any dmesg bitching?
<ttx> tgardner: rebooting and checking
<ttx> fwiw the code does a java-bsead block decipher and complains about a bad padding
<tgardner> ttx, actually, I was wondering if the java machine was causing any complaints by the kernel
<ttx> based*
<ttx> i was wondering how much the jdk/javax.crypto/bouncycastle stuff was relying on kernel functions to do that decipher
<kirkland> tgardner: -> daviey for the dmesg
<Daviey> i saw no dmesg help
<Daviey> i can try again, but i remember being suprised it seemed to be kernel related, but nothing in dmesg
<Keybuk> my dmesg is full of irqbalance respawning
<Daviey> Keybuk: I think that is kvm related
<ttx> Keybuk: bug 594509
<ubot2> Launchpad bug 594509 in irqbalance (Ubuntu) "irqbalance main process ended, respawning (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/594509
<Keybuk> Daviey: no, it's because the script is wrong
<Daviey> ok
<Keybuk> another upstart job that wasn't checked by the foundations team
<ttx> no, it's just a bug in that upstart script
<ttx> Keybuk: it was... but then got "fixed"
<Keybuk> it's still wrong here today
<ttx> by "fixed" I mean a bugfix introduced a bug
<apw> he means you checked, then they "fixed" it into brokenness
<ttx> apw: exactly
<Daviey> Keybuk: I know you mentioned that upstart confs should be passed through foundations, but is there any hope of better docs this cycle?
<Keybuk> Daviey: do you feel like you're in a documentation writing mood?
 * Daviey hides
<apw> Keybuk, who says 'unexpectedly disconnected from boot status daemon' ?
<ttx> Daviey, kirkland: I'll try to reproduce on i386
<Daviey> ttx: Is it worth it?
<ttx> Daviey: might help in finding where it comes from (if it works there)
<ttx> hrm, looks like I don't have that ISO.
<ttx> so that's not for today.
<Daviey> ttx: if you think there is merit in the test, i'll do it
<ttx> Daviey: bisecting kernels to find which one "breaks" it is much more interesting
<ttx> but also more time-intensive
<apw> Keybuk, you know i am not sure this is is actually the kernel doing this
<Daviey> apw: I was pretty surprised to find rolling back the kernel to lucid resolved it.. i had to check it again.
<apw> Keybuk, i'll put that another way, i think that the initramfs is doing something odd _too_
<Keybuk> apw: "doing this" ?
<Daviey> Somewhat suprising to see kernel having such an issue with userspace
<Keybuk> apw: I don't think initramfs does much interesting in this regard
<Keybuk> it just copies its args to the userspace
<Keybuk> I can test again without initramfs, one sec
<apw> Keybuk, i don't think you need to am still poking
<apw> but there is an odd interaction with initramfs as it runs some scripts before erroring about ro
<apw> which is somewhat unexpected
<Keybuk> sure it would
<Keybuk> initramfs would run fine, it's a shell script and ignores its arguments
<apw> so i'd have to have also _not_ honoured the init= and initramfs final step must do so
<Keybuk> not sure I'm following you there ;-)
<apw> Keybuk, heh .. i'll go confirm my theory and get back to you
<JFo> apw, you are referring to https://wiki.ubuntu.com/Kernel/FAQ?action=show&redirect=KernelTeam%2FFAQ yes?
<JFo> ack!
<JFo> oh, it's a redirect
<JFo> whew
<JFo> smb, this is the test of the item: [jeremyfoshee] Jeremy to document the patch review process for kernel: TODO
<tgardner> apw, note the mammoth initramfs-tools (0.96.1ubuntu1) update uploaded 90 minutes ago
<apw> tgardner, yeeks no thank  you ...
<tgardner> apw, well, you _were_ just grunging around in init scripts
 * JFo sprays it with bug spray
<apw> tgardner, indeed ... and i even less want to look in there now :)
<tgardner> apw, do you know how I can restart a KVM image after using testdrive to install it?
<apw> tgardner, you can run something to get it up ... virtmanager i think it is
<tgardner> apw, k
<JFo> <-lunch
<maks_> happy cjwatson did the sync, was about time  :)
<bjf> is it possible to install just the alsa drivers from lucid-lbm or when I check "Ubsupported updates (lucid-backports)" do I just get it all?
<tgardner> bjf, AFAIK there are separate packages for each
<tgardner> bjf, install linux-backports-modules-alsa-lucid-generic
<smb> Yep, they are nicely spearated now
 * manjo heading out to radio shack to buy cables 
 * manjo getting lunch will be back soon
<kamal> tgardner: fyi, all your testdrive KVM images are down in $HOME/.cache/testdrive/img and you can start them directly from there with e.g. kvm -m 2048 whatever.img   ( -usbdevice tablet  is useful too )
<tgardner> kamal, ah, thanks. it was that bit ' kvm -m 2048 whatever.img' that I was looking for. my memory is like a sieve.
<kamal> tgardner: man kvm   is an interesting read btw
<tgardner> kamal, I have trouble distinguishing the difference between kvm, libvirt, qemu, et al.
<kamal> $ ls -l `which kvm`
<kamal> /usr/bin/kvm -> qemu-system-x86_64
<kamal> and 'man kvm' yields the man page for qemu, actually :-)
<cnd> cking: https://launchpad.net/ubuntu/+source/pm-utils-powersave-policy/0.3.1
<apw> Keybuk, did you get those union-mount tools built again ?  i was thinking of doing some testing on them 
<Keybuk> apw: no
<tgardner> kamal, do you have a recipe for simple kvm bridged networking in the guest? I have the host bridge initialized, but cannot seem to get the guest to _not_ use the internal NAT network on 10.0.2.0.
<kamal> tgardner: no, sorry -- I've always just used the NAT for simple things like moving files to and from the host
<tgardner> kamal, hmm, I want a guest that can provide a service
<kamal> google:  kvm network bridge    <-- some interesting looking stuff maybe
<tgardner> kamal, the setup info has changed from Karmic to Lucid, and its all a bit confusing. maybe I'll bug Barcet
<kamal> tgardner: good luck
<ogasawara> make[2]: *** [drivers] Error 2
<ogasawara> make[1]: *** [sub-make] Error 2
<ogasawara> make[1]: INTERNAL: Exiting with 59 jobserver tokens available; should be 64!
<ogasawara> anyone ever see that build failure before?
<ogasawara> on emerald using armel chroot
<tgardner> ogasawara, thats weird. emerald or tyler?
<ogasawara> emerald
<ogasawara> I'll try kicking the build off again to see if I can reproduce
<tgardner> ogasawara, hmm, I wonder if the armel schroot has problems.
<tgardner> ogasawara, if the x86* builds completed, then the arm build would also likely complete given the simple patches you are removing. you should upload anyways.
<ogasawara> tgardner: ack
<manjo> tgardner, so can I send out the patch with the test results and pgraner-afk can add his test finding to it too ?
<tgardner> manjo, sure
<tgardner> manjo, if it looks like its not gonna kill all our kittens, then I can make the change to modprobe and do the upload
<bjf> manjo, when we make the switch, let ronoc & TheMuso know and they can do some audio testing
<manjo> bjf, ok
<tgardner> cnd, you could hassle someone on the archive team if you like: https://wiki.ubuntu.com/ArchiveAdministration#Archive days
<cnd> tgardner: I think pitti may have mentioned he would review it for me
<cnd> said he could be a sponsor OR an archive reviewed
<cnd> reviewer
<cnd> but not both
<bjf> manjo, see http://www.ffado.org/?q=release/2.0.1
<cnd> so I asked you to upload, and I'll ping him about the second step
<manjo> bjf, the old modules will still be available in case the new ones don't work for some people 
<manjo> pgraner, I will put up a wiki asap
<pgraner> manjo: thanks, I also have a DV camera so I can test video as well
<manjo> pgraner, using kino &/or dvgrab ?
<pgraner> manjo: both + v4linux2
<manjo> tgardner, I sent out the patch with test results to ukml
<tgardner> manjo, ack
<manjo> pgraner, https://wiki.ubuntu.com/Kernel/SwitchFirewireStack
<manjo> pgraner, when you are done testing can you please share your results on the email thread on ukml (subject: [Maverick] switch to new firewire stack.) I introduced the patch to switch in that email. 
<manjo> pgraner, so that we have some doc on testing done 
<pgraner> manjo: sure thing
<JFo> manjo, will there be a PPA kernel to test for the CFT or just a regular kernel?
<JFo> BTw, I did see the myth ml that you want this sent to as well
<JFo> I have added that to the CFT
<JFo> pgraner, sent the triage summit mail to devel
<JFo> ogasawara, do you know where our Call for testing page is?
<JFo> I know i was there recently
<JFo> just can't find it now
<ogasawara> JFo: hrm, I don't.  I actually don't remember us having one :/
<JFo> I could swear I saw one
<JFo> hope I didn't dream it
<manjo> JFo, the changes to kernel are already there in Maverick and Lucid, switch accounts to blacklisting old modules & (auto) whitelist new modules 
<JFo> ok
<manjo> JFo, I have a wiki on how to do the switch on ubuntu 
<JFo> saw that
<manjo> coo
<manjo> cool
<JFo> so this can be tested on both kernels?
<manjo> bjf, suggest couple more places where you can send cft to 
<JFo> ok
<manjo> <bjf> manjo, when we make the switch, let ronoc & TheMuso know and they can do some audio testing
<manjo> <manjo> bjf, ok
<JFo> yeah, saw that
<JFo> any others?
<manjo> yes sir, when it makes into the distro we should be all set 
<JFo> I plan to send to QA, devel, etc.
<JFo> manjo, so there is a patch that needs SRU for lucid?
<bjf> jfo, manjo, this will cause breakage if not coordinated a little with an upload of FFADO
<JFo> or?
<JFo> bjf, I see
 * JFo notes that 
<JFo> I see your ffado link above bjf
 * JFo looks it over
<manjo> JFo, no we will not sru for lucid 
<manjo> JFo, coz its an LTS
<JFo> ok, so no testing in Lucid
<manjo> right only maverick
<JFo> ok
<manjo> but I did test on Lucid and it works fine too
<JFo> ok
<manjo> bjf, just curious why is FFADO imp ? 
<bjf> manjo, i don't know much about it but i am assuming that is used by pro-audio folks
<manjo> ah
<apw> tgardner, i think the new initramfs tools are broken
<tgardner> apw, bummer, how so?
<apw> tgardner, actually not 100% sure its them
<apw> but kernel failed to install on an upgraded system
<tgardner> apw, not good.
<apw> Invalid prameter, 2.6.35-3-generic
<ogasawara> apw: I think that's the bug cjwatson pinged me about
<apw> ogasawara, whats the word there?
<ogasawara> [10:26:59] <cjwatson> ogasawara: heads-up on bug 595178, you're probably going to see a few dups of that while my fix percolates through the buildds
<ogasawara> [10:27:01] <ubottu> Launchpad bug 595178 in grub2 (Ubuntu) "package linux-image-2.6.35-2-generic 2.6.35-2.3 failed to install/upgrade: subproces installed post-installation script gaf een foutwaarde 1 terug" [High,Fix released] https://launchpad.net/bugs/595178
<ogasawara> [10:27:23] <ogasawara> cjwatson: ack, thanks
<ogasawara> [10:27:39] <cjwatson> the "Invalid parameter, 2.6.35-2-generic" bit in the dpkg terminal log is the relevant one
<ogasawara> [10:27:44] <ogasawara> JFo: ^^ fyi
<ogasawara> [10:27:54] <cjwatson> upstream patch that snuck in without my noticing
<ogasawara> apw: ^^ in #ubuntu-devel
<ubot2> Launchpad bug 595178 in grub2 (Ubuntu) "grub-mkconfig stopped ignoring extra non-option arguments, breaking kernel postinst hooks (affects: 2) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/595178
<ubot2> ogasawara: Error: Bug #595178 is private.
<ubot2> Launchpad bug 595178 in grub2 (Ubuntu) "grub-mkconfig stopped ignoring extra non-option arguments, breaking kernel postinst hooks (affects: 2) (heat: 10)" [High,Fix released] https://launchpad.net/bugs/595178
<apw> ahh grub2 huh ... well thats something
<apw> ogasawara, so we wait for grub to be fixed i assume
<ogasawara> apw: yep
<tgardner> apw, grab the source, build it locally
 * JFo monitors the bug flow
<psusi> I'm confused... last night I had narrowed down a suspend problem to CONFIG_PM_DISABLE_CONSOLE... it appeared in a number of places in the 2.6.35-rc3-3 source tree I got from apt-get install linux-source... now that I'm using git, I can only find one reference to it in the code, and not at all in the Kconfig files, and no references to it whatsoever in linus's tree
<ogasawara> psusi: that looks like it came from an Ubuntu SAUCE patch
<ogasawara> psusi: commit 6063b4dc3721a63d70f81522fa130372ded60b45
<ogasawara> Author: Amit Kucheria <amit.kucheria@ubuntu.com>
<ogasawara> Date:   Fri May 23 11:43:45 2008 +0300
<ogasawara>     UBUNTU: SAUCE: pm: Config option to disable handling of console during suspend/resume
<ogasawara>     
<ogasawara>     Signed-off-by: Amit Kucheria <amit.kucheria@ubuntu.com>
<ogasawara>     
<psusi> ogasawara: yes, it does..
<ogasawara>     Signed-off-by: Ben Collins <ben.collins@canonical.com>
<tgardner> ogasawara, that one goes way back, feisty/gutsy days
<ogasawara> I wonder if we still need to carry that patch
<ogasawara> amitk: ^^ thoughts?
<psusi> it seems to be breaking resume for me... with that setting on, my display never powers back on after resume
<psusi> worked fine in lucid
<bjf> pgraner, i'm running just fine from a stick using today's live image
<psusi> with maverick it never powers back on... I traced it last night to this setting... if I build it myself and set it to n, display works fine
<ogasawara> psusi: can you file a bug, might be reason enough to drop that sauce patch
<psusi> did... bug #594885
<ubot2> Launchpad bug 594885 in linux (Ubuntu) "Maverick kernel breaks video on resume from suspend (affects: 2) (heat: 12)" [Undecided,Incomplete] https://launchpad.net/bugs/594885
<tgardner> ogasawara, I think that one has definitely decayed into crack
<ogasawara> tgardner: maybe I'll rip it out and see if anyone else screams
<tgardner> ogack from me
<tgardner> ogasawara, ^^
<pgraner> bjf: hmmm its an intel series 4, using i915 works fine under lucid won't under maverick
<pgraner> bjf: I'm installing lucid now and will add the maverick kernel and see what that does
<ogasawara> psusi: I'll get with Amit and confirm it's ok to drop and then I'll rip it out
<bjf> pgraner, mine says mobile 4 series, integrated graphics, intel, i915 driver
<psusi> ogasawara: ok... I'd like to understand why it is only now causing a problem though... worked fine in lucid and karmic...
<ogasawara> psusi: can you priv msg me your email address, I'll CC on discussions to the mailing list
<psusi> hrm... actually... I wonder... I never really looked into why but in lucid, whenever I would resume, the screen would come up with a bunch of snow.. white noise background... for a few seconds, then go to the blank screen saver until touching a key to get the password prompt.... maybe this patch was causing that
<psusi> psusi@cfl.rr.com
<ogasawara> thx
<psusi> hrm... I wonder... I think there is an early stage of resume where some quirks can initialize the display.. I bet in lucid such a quirk is what initialized the display, but left the frame buffer full of trash, which would explain the snow... then after the resume finished, x wrote to the frame buffer... and since then upstream has disabled that quirk so early initialization is not done now,...
<psusi> ...so the display is not initialized until vt_move_to_console() is called... which never happens with PM_DISABLE_CONSOLE
 * ogasawara lunch
<amitk> ogasawara: I think that patch was to allow debugging suspend, there are better ways now. Drop it!
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-22 - 17:00 UTC
<ogasawara> amitk: sweet, thanks
<lifeless> JFo: hi
<lifeless> JFo: I filed a bug about wifi N support and you asked me to test the mainline build; what chance that that will fry my [production] laptop (e.g. by having a buggy ext4 or something like that)
<lifeless> JFo: the wiki page says 'the kernel team does not support these kernels' which seems to be in direct opposition to asking folk to try them ?
<manjo> lifeless, what bug# ? 
<lifeless> sec, archived the mail already
<lifeless> bug 594889
<ubot2> Launchpad bug 594889 in linux (Ubuntu) "WiFi Link 6000 Series (rev 35) crashes regularly on N network (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/594889
<lifeless> Its the machine stefan and andy were giving me test SD cards to get hardware quirk data on
<lifeless>  - x201s, the one that there was a worry about an SRU regression on the first day of UDS :)
<manjo> lifeless, there is std disclaimer with mainline builds because it is not a std kernel that the distro releases, it is meant only for testing purposes
<lifeless> right
<lifeless> I'm trying to assess the risk
<lifeless> I have a known bug interfering with analysing optimising bzr performance, vs running an unreleased kernel mainline
<manjo> lifeless, the problem is ... it is not possible for us to access the risk coz its a crack of the day kernel .. 
<lifeless> manjo: exactly!
<lifeless> manjo: so, I think I'd much rather have another SD card given to me in prague
<lifeless> I can probably bring my N wifi AP with me
<manjo> lifeless, sounds like an alternative 
<manjo> ^ good 
<lifeless> I'm a little averse to unquantifiable risk on production machines
<lifeless> :)
<manjo> sure understandable
<lifeless> ok, I'll organise to bring the AP it has trouble with and will pop into the kernel room there
<manjo> when you say link crashes you mean disconnects ? 
<lifeless> manjo: its a little hard to pin down precisely.
<lifeless> manjo: the firmware reboots seem to correlate pretty nicely with it completely giving up.
<lifeless> manjo: a driver unload+load then makes it happy again.
#ubuntu-kernel 2010-06-17
<lifeless> the machine as a whole doesn't lock up or anything.
<manjo> looks more like a firmware issue to me
<ogasawara> bjf: let me restart mumble, just a sec
<bjf> ah
<manjo> lifeless, what driver is series 6000 use ? 
<lifeless> iwlagn
<lifeless> manjo: oh, I'm not assuming anything about where the bug is; firmware makes sense to me
<manjo> does it help if you do sudo rfkill unblock wifi ... just a shot in the dark this one ... 
<manjo> does rfkill list say it is soft blocked or hard blocked ? 
<manjo> lifeless, there is new microcode for this device ... http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-6000-ucode-9.193.4.1.tgz
<lifeless> manjo: I'll install rfkill and try those commands next time it goes awol
<manjo> do rfkill list 
<manjo> and that should tell if it is blocked.
<manjo> but I suspect it is firmware issue 
<lifeless> manjo: I'm quite sure its not, but it is worth checking
<lifeless> manjo: I says it not, because nm doesn't think its blocked
<lifeless> it thinks it can't associate
<manjo> lifeless, ah worth a try
<manjo> lifeless, I also posted a link to the current firmware 
<lifeless> manjo: indeed, its worth checking
<lifeless> I've pulled that down
<lifeless> where does that go these days ?
<lifeless> ah /lib/firmware
<manjo> /lib/firmware/
<manjo> yes
<lifeless> lucid has it
<lifeless> iwlwifi-6000-ucode-9.193.4.1/iwlwifi-6000-4.ucode
<lifeless> bah
<lifeless> robertc@lifeless-64:/lib/firmware$ diff iwlwifi-6000-4.ucode ~/source/iwl/iwlwifi-6000-ucode-9.193.4.1/iwlwifi-6000-4.ucode 
<lifeless> robertc@lifeless-64:/lib/firmware$ 
<manjo> lifeless, can you enable power mangement for the card ? 
<manjo> iwconfig wlan0 power on
<manjo> lifeless, microcode errors might be due to card over heating ... are you running in N mode ? 
<lifeless> manjo: am running in N mode; am in new zealand so its not very warm :)
<lifeless> have done the power on
<lifeless> and will do so after firware reloads from here on in
<manjo> lifeless, it might be also interesting to test the over heating theory ... 
<lifeless> manjo: other than putting it under the hot water tap, do you have any suggestions ? :)
<manjo> hhaha
<manjo> lifeless, I see an upstream bug on this ... https://bugzilla.kernel.org/show_bug.cgi?id=15374
<ubot2> bugzilla.kernel.org bug 15374 in network-wireless "iwlagn Microcode SW error detected" [Normal,Resolved: code_fix]
<lifeless> manjo: the problem is that the restart error is very generic
<manjo> lifeless, I will pull in the upstream patch for you and build a kernel if you like 
<lifeless> manjo: that would be totally awesome
<lifeless> I'm running 2.6.32-22-generic x86_64 
<lifeless> (just the stock lucid 64 bit kernel)
<manjo> lifeless, it is towards the end of the day for me. I can have it uploaded to my people page by tomorrow AM
<lifeless> manjo: there is no panic
<manjo> lifeless, :) cool talk to you tomorrow then
<lifeless> manjo: let me know in the bug where it is and I'll spin it up asap
<manjo> ok
<manjo> will do
<ogasawara> manjo, lifeless: I wonder if  linux-backports-modules might help as I think that contains and updated compat-wireless stack
<manjo> ogasawara, thanks totally forgot about the backport modules 
<manjo> lifeless, try what ogasawara suggests 
<lifeless> does it contain the patch from the upstream bug report ?
<ogasawara> manjo: no idea if it'll really help, but for testing it wouldn't hurt and might save you having to build a custom kernel
<ogasawara> lifeless: not sure on that, would have to dig around
<ogasawara> lifeless: if the patch in the upstream bug report hasn't been applied to mainline, then lbm won't have it
<manjo> lifeless, I will have a kernel for you as well & point you to it on the bug ... just in case lbm does not work
<lifeless> ogasawara: can you tell from https://bugzilla.kernel.org/show_bug.cgi?id=15374 if its applied ?
<ubot2> bugzilla.kernel.org bug 15374 in network-wireless "iwlagn Microcode SW error detected" [Normal,Resolved: code_fix]
<lifeless> ogasawara: to mainline, I mean..
<manjo> ogasawara, lifeless, there was commit to mainline 
<manjo> commit 74e2bd1fa3ae9695af566ad5a7a288898787b909
<manjo> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
<manjo> Date:   Wed Feb 3 09:28:55 2010 -0800
<lifeless> cool
<manjo> ogasawara, so lbm should have them ? 
<manjo> there are a total 4 patches to fix this issue
<ogasawara> manjo: would have to cross check and see what latest version of compat-wireless was updated to
<lifeless> don't stress
<lifeless> I'll run manjos build tomorrowish/whenever
<ogasawara> manjo:  it looks like that patch didn't land till 2.6.34-rc1
<lifeless> which as an isolated change will be valuable to confirm/deny the change works.
<manjo> ogasawara, right... that is what I was just about to say
<manjo> lifeless, in that case don't bother with lbm, I will have a kernel for you tomorrow AM
<lifeless> if it doesn't, I'll try lbm and hope; if it does we know whats up and can look at SRU inclusion or whatever.
<ogasawara> manjo:  in that case, might not hurt to give tgardners LTS backport kernel a try
<manjo> ogasawara, can you please point lifeless to it ? 
 * ogasawara digs for the link, just a sec
<lifeless> it has 2.6.34rc1 ?
<ogasawara> lifeless: it's up to 2.6.35-rc1, it's basically a maverick kernel backport
<manjo> ogasawara, remember lifeless does not want to try experimental stuff on his production machine 
<ogasawara> make that 2.6.35-rc3
<lifeless> manjo: I'm happy to try whats in maverick
<lifeless> manjo: because we're supporting that :>
<manjo> sure 
<ogasawara> it would be good to know if it exists in Maverick sooner rather than later
<manjo> lifeless, ogasawara will point you to the lts backport kernel 
<lifeless> if its good enough for the distro, I think the risk is reasonably assessed ;)
<lifeless> ogasawara: absolutely.
<manjo> ogasawara, the microcode failure is not fixed so far, the real problem still exists coz its firmware
<manjo> ogasawara, fix is to make sure that the link does not go down even if there is a microcode crash
<manjo> ogasawara, so that the connection is maintianied 
<ogasawara> lifeless: "The LTS backport kernel and meta packages at http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu are up to 2.6.35-3.4"
 * manjo heading out for dinner ... adios amigos
<lifeless> thanks
<ogasawara> lifeless: I've got an hp mini here which uses the iwlagn driver running up to date maverick and haven't seen any issues, but I haven't been hamming it that hard
<lifeless> ogasawara: I didn't see any issues at all until I got the N wifi point
<ogasawara> lifeless: ah
<lifeless> ogasawara: I don't know if you folloed the details in the bug, but there are two separate issues:
<manjo> ogasawara, you need a 6000 series, N mode & huge file tranfers
<lifeless> * the microcode is shit
<lifeless> * When the microcode fails, the recovery was broken
<lifeless> so the 'fix' here is to recover and reload the microcode better
<lifeless> if you're not triggering the underlying microcode problem, you won't have any issues at all.
<ogasawara> ack
<lifeless> and the kicker is, that the bug count in the microcode is unknown - there could be 20 different bugs
<lifeless> or 1
<lifeless> and we'll never know
<kraut> moin
<amitk> ericm|ubuntu: what is 'git blog'? An alias?
<jk-> heh
<ericm|ubuntu> amitk, heh, my alias - git config alias.blog "--pretty=oneline --abbrev-commit"
<ericm|ubuntu> very useful
<jk-> damn, i thought it makes a blog entry for your commit :)
<ericm|ubuntu> jk-, haha - it's not that smart
<amitk> yeah, that was the first thing I thought of - how and WHY?
<amitk> :)
<ericm|ubuntu> confusing, heh
<ericm|ubuntu> means brief log, cannot find any other word from my poor vocabulary, you know
<ericm|ubuntu> jk-, btw, is it convenient to setup patchwork for linux-arm-kernel ML?
<ericm|ubuntu> jk-, guess will be much useful
<jk-> yeah, it's easy to do, but someone has to maintain it
<jk-> and rmk has his own patch system, so I don't think he'll be doing that
<ericm|ubuntu> jk-, there lot of effort to maintain that?
<ericm|ubuntu> jk-, nah - just hundreds of patches flooding, and SoC patches are all over
<jk-> well, it's really to make the maintainer's life easier, and since rmk doesn't need it, I'm not sure it'll be useful
<ericm|ubuntu> guess will at least make us sub-maintainers life easier
<apw> jk-, oh can you tell if brad figg has an patchworks account?  we need him to be maintainer on the ubuntu pwks thingy
<amitk> I think omap list already uses it
<jk-> apw: will check
<ericm|ubuntu> jk-, indeed rmk is a bit stubborn - and he seems to use his own patch system for things other than kernel, which I have no idea :-X
<ericm|ubuntu> jk-, another thing - there is patchwork.ozlab.org and patchwork.kernel.org, seems they are not linked and I need to register on both sites
<jk-> apw: looks like he doesn't.
<jk-> ericm|ubuntu: yes
<apw> jk-, ok i'll hastle him to make one then
<jk-> ericm|ubuntu: I maintain the patchwork.ozlabs.org site, the kernel.org people (ie, warthog9) maintain patchwork.kernel.org
<jk-> s/maintain/admin/
<ericm|ubuntu> jk-, I see
<jk-> they're separate setups
<ericm|ubuntu> jk-, mmm... so I guess would make more sense to first setup linux-arm-kernel on ozlab?
<jk-> ericm|ubuntu: it's just going to fill up with patches if there's no one to update the patches in it
<ericm|ubuntu> jk-, but with a filter, is it still possible that, let's say, all pxa patches can be picked up there?
 * smb grumbles at his ThinkPad for "forgetting" to turn on the backlight after suspend
<amitk> smb: it was scared at night?
<ericm|ubuntu> smb, turn on or turn off?
<smb> Cannot say. But the same seems to happen now every time
<smb> ericm|ubuntu, It rurns off on suspend which is what I expect
<jk-> ericm|ubuntu: patchwork doesn't have a filter on incoming patches at the moment
<smb> It just does not turn on on resume
<jk-> but interesting idea
<smb> Which it had been done until recently
<smb> On the good side, this happens with the previous kernel, too
<ericm|ubuntu> jk-, mmm I guess it's also useful for the linux-kernel ML, as patches toward different sub-maintainers are all flooding there
<ericm|ubuntu> smb, that means a fix of a regression is seamlessly merged without our awareness?
<jk-> ericm|ubuntu: most sub-maintainers have their own lists though, so it's not too bad
<jk-> and akpm pick up a lot of the generic stuff
<jk-> *picks
<smb> ericm|ubuntu, I'd rather hope for the regression not being in the kernel
<smb> There have been X updates too
<ericm|ubuntu> smb, I see - now quite a work to find out that regression
<smb> Even more as I see no error message anywhere, yet
<smb> Hm another x-org-server-core update... Lets see
<ikepanhc> smb: good morning. I read your feedback but do not understand. you mean I did not update abi information?
<smb> ikepanhc, If I looked right, you forgot to update and commit the generated files
<smb> Oh good morning
<ikepanhc> or you mean debian/control?
<smb> control control.stub and kernel-versions
<ikepanhc> oh. in netbook-lpia delta, no commit update the three files
<ikepanhc> these three file is the same in master branch and netbook-lpia branch
<smb> Hm... I thought the rscript might change that. Give me a sec
<smb> No ok, you are right that the files are ok as they are now
<ikepanhc> yeah, I check again too. you update them for me :)
<smb> Yes, I will pull those in
<ikepanhc> thanks, I will upload now
<ikepanhc> E: bzrlib must be instyalled to use sftp transport.
<ikepanhc> eh, anyone know what package I shall install?
<apw> ikepanhc, wasn't that announced recently, the sftp support ?  per
<apw> perhaps the announce tells us
<ikepanhc> apw: let me check my email
<smb> Though I thought that sftp wasoptional
<apw> smb, it is for the normal archive, not for ikes use
<smb> apw, Oh right I forgot, they always had sftp
<ikepanhc> yeah, I try ftp, connection refused
<apw> ikepanhc, ask on #ubuntu-devel, they'll know
<ikepanhc> apw: I find the answer
<ikepanhc> apw: seems because I apt-get remove bzr
<ikepanhc> so I install it again
<apw> hrm
<apw> i wonder why those would be related without a dep
<ikepanhc> yeah, I wonder too
<amitk> apw: http://blog.namei.org/?p=258 (why is jj not attending?)
<apw> amitk, i wasn't aware of it, are you sure he isn't ?  but you should ask him when he wakes for sure
<amitk> jj is sleeping!! (the horrors...)
<amitk> his name is not on
<smb> ikepanhc, Ok, your trees have been pushed. Don't forget to make a meta-package, too
<ikepanhc> smb: eh. because of ABI bump?
<smb> yep
<ikepanhc> oh, I did not aware of that, checking
<smb> ikepanhc, To make it more fun, we don't seem to carry a branch for that on git. I am not sure, maybe OEM did the meta package on their own
<smb> apw, RAOF On of you got an idea how to kick a radeon based system in the a** to turn on the backlight?
<apw> smb, which kernel is this on ?
<apw> smb, i assume xset dpms force on doesn't do anything
<smb> Lucid, either -22 or -23
<smb> Nope
<ikepanhc> smb: yeah, I can not find it on repo, I guess I need to ping steve magoun for making sure he knows there is an ABI bump
<smb> And the other backlight controls also think its on
<apw> smb, hrm, no idea at alll, hopefully RAOF has some ideas
<apw> smb, did you see the console suspect patch being talked about, how it might cause backlight issues (reported on .35 though)
<smb> apw, Yeah, it seems to turn on when shutting down to show me plymouth... Not too useful. :-P
<smb> apw, No not yet
<apw> UBUNTU: SAUCE: pm: Config option to disable
<apw> that thread
<smb> apw,  But somehow it worked before erecently
<apw> yeah very odd, but it may be a stable update perhaps ?
<apw> smb, did you try switching VTs ?
<smb> Thats why I loaded the -22 kernel which now behaes the same
<smb> Seems no reaction
<amitk> apw: as I mentioned in that thread, that config should be disabled and a test kernel posted to all suspend/resume bugs to see if helps some of them
<smb> But somehow this would not affect the timeframe from one week ago in Lucid and now...
<smb> I try to go back one abi version further ...
<apw> smb, yeah that does seem right ...
<smb> apw, Doh! From time to time this stupid laptop just sits on the bios screen thinking. Gues thats why its called thinkpad
<apw> smb, heheh nice
<smb> apw, Grr, -21 seems to work but -22 not.Which would throw a strong suspicion on a EC patch we know of
<cking> smb, the thinkpad isn't the one that's thinking, it's making *you* think
<smb> cking, No, just grumpy
<apw> smb, i wonder why you didn't notice it before though
<smb> Yes that is odd like hell. I thought to have updated before that. Well, I try to revert that one patch and test again
<apw> fingers crossed that does not help you
<RAOF> smb, apw: I don't have any secret sauce to prod backlights on radeon.  Intel have some patches wending their way through, though.
<apw> RAOF, interesting though not helpful for smb's issue :)
<smb> RAOF, Ok, thanks. Actually I went on on suspecting some stuff with the embedded controller
<apw> smb, you are always dissing that poor EC patch, it is so going to get a complex
<smb> apw, Oh, well. Maybe I find out in a second its not its fault.:)
<apw> i do hope so
<smb> I would actually, too
<tseliot> apw: what's smb's issue with the backlight?
<smb> tseliot, It does not turn back on after suspend
<apw> tseliot, stops working on  suspend/resume 
<apw> smb, when did it appear
<tseliot> apw, smb: I have a patch that fixes the issue
<smb> tseliot, In Lucid?
<apw> tseliot, oh ?
<apw> tell all
<smb> tseliot, right, what does it change?
<tseliot> apw, smb: it simply turns dpms back on on resume: https://bugzilla.kernel.org/attachment.cgi?id=26733
<tseliot> (for radeon)
<tseliot> and it works well here
<smb> apw, So good new, it definitely is not the EC patch
<apw> smb, as in you have tested it, or that you are assuming its tseliots fix ?
<smb> apw, I tested with the EC patch reverted
<apw> PHEW good
<smb> I now can test with tseliot s patch
<smb> tseliot, I am just a bit surprised that in started to fail between the -21 and -22 kernels
<tseliot> here's the upstream report: https://bugzilla.kernel.org/show_bug.cgi?id=16180
<ubot2> bugzilla.kernel.org bug 16180 in Video(DRI - non Intel) "radeon regression with 2.6.35-rc2-00001-g386f40c: black screen after resume" [Normal,Resolved: patch_already_available]
<smb> tseliot, Which are the day0 update with only two patches and the security update which also does not touch drm iirc
<tseliot> smb: it's not the 1st mysterious regression I've dealth with...
<tseliot> smb: wait is this in lucid's kernel?
<smb> tseliot, Yes, thats what I mentioned erlier. :)
<tseliot> right. I tested the patch in 2.6.35 and I'm not sure about Lucid's kernel
<tseliot> still the patch should hurt
<tseliot> shouldn't
<tseliot> smb: does vtswitching to vt1 and then vt7 restore the backlight?
<smb> I will surely give it a try after wondering a bit more what changed between .32-21 and .32-22 to make that happen
<smb> tseliot, no
<tseliot> hmm.. ok
<smb> tseliot, Funnily the moment I say shutdown it turns on to give way to plymouth
<tseliot> smb: maybe switching to graphics mode turns on the backlight
<tseliot> KD_GRAPHICS mode, that is
<tseliot> which is what plymouth does to show the splash
<tseliot> KDSETMODE KD_GRAPHICS
<smb> tseliot, killing X works too. gdm comes up and backlight is on...
<smb> though there seems to be something going wrong now
<smb> no network anymore
<apw> smb, sounds well broken
<smb> yeah, magic sysrq worked. But everything else.. 
<tseliot> I have a similar problem with 2.6.35. I can't reconnect (using eth0) on resume
<smb> tseliot, For me it worked well until I killed the X server
<tseliot> ok, it must be a different problem then. I don't see how X can block the network
<smb> apw, Oh crap -21 was not a .32-21 but a .31-21. Now there is enough difference to behave differently. But I am really really sure I did suspends with a Lucid kernel before
<apw> smb, you got the wrong one ?  oops
<apw> bfore the .33 drm update perhaps
<apw> ls
<smb> apw, Yeah, the Karmic kernel worked. But that could be just to different interaction with something else that broke
<apw> well i say leave tseliot's patch building and try it after lunch
<smb> That sounds like a good plan
<tseliot> mjg59: I spoke with Alex about the atif method. Do you know of any code samples or documentation that I could look at to implement this in the radeon driver?
<tseliot> so that I can see what headers I should include and what function I should call (I already know what arguments I should pass)
<mjg59> tseliot: You could look at the acpi calls in nouveau
<mjg59> I'm planning on implementing it next week - I'd have got to it this week but it turns out some of our customers can't write firmware
<tseliot> :-)
<apw> mjg59, you _must_ be mistaken surely
<mjg59> Who'd have thought?
<mjg59> So now I need to hack qemu to let me reproduce the behaviour under Windows in order to justify our position
<apw> mjg59, that sounds _so_ familiar ... sign
<tseliot> mjg59: does nouveau use atif (isn't it only for ATI?)?
<mjg59> tseliot: It uses a different ACPI interface
<mjg59> Just grep for acpi_evaluate_method
<smb> tseliot, apw, Ok, so the backlight issue is the same with the patch of tseliot. But it works if I disable KMS. Why this seems to have changed recently is beyond my understanding.
<tseliot> mjg59: nothing in drivers/gpu/drm/nouveau
<apw> smb, thats a bit mental me thinks
<tseliot> acpi_get_name is the closest thing, I guess
<mjg59> tseliot: Sorry, acpi_evaluate_object
<tseliot> smb: so, it's not dpms. Is it that the backlight is off or just a black screen with the backlight on?
<smb> apw, It is mental. Especially without knowing the exact state before. Just thinking it worked.
<smb> tseliot, No backlight. The screen is really block without any ambient
<smb> I am trying to see what happens to another laptop with ati. But it would be another card.
<mjg59> Without knowing the background, on several GPUs the backlight will refuse to turn on if LVDS has been set up incorrectly
<tseliot> mjg59: what's the acpi_string pathname for atif?
<tseliot> smb: can you access the laptop via ssh?
<smb> mjg59, In my special case I believe to have had it working at some point
<smb> tseliot, Yes
<smb> tseliot, Until I kill X which seems to take the whole system into a bad state
<mjg59> tseliot: You need to get the acpi_handle for the PCI device you're working with
<tseliot> smb: anything interesting in dmesg and Xorg.0.log? Also maybe you could dump the registers after resume with the driver that works and with the driver that doesn't (with avivotool regs all)
<tseliot> mjg59: right but that's the 1st argument
<tseliot> acpi_status
<tseliot> acpi_evaluate_object(acpi_handle object,
<tseliot>                      acpi_string pathname,
<tseliot>                      struct acpi_object_list *parameter_objects,
<tseliot>                      struct acpi_buffer *return_object_buffer);
<smb> tseliot, Nothing obvious in the logs (radeon seems happy with things). But I will dod the dump with and without kms enabled
<mjg59> tseliot: "ATIF"
<tseliot> smb: hopefully we'll see the difference in the dumps
<tseliot> mjg59: "ATIF" or "_ATIF" (sorry to be such a pain)
<mjg59> ATIF
<mjg59> All ACPI methods are four characters long
<tseliot> ok
<tseliot> aah, it makes sense now. So if it's 3 characters long you prepend a "_" or something like that
<mjg59> A leading _ indicates that it's a reserved ACPI name
 * smb like those well written tools, avivotool has two possible outcomes: called non root -> segmentation fault. Called with sudo -> lockup system
<tseliot> mjg59: ah, thanks for the info
<tseliot> mjg59: if it locks up, I have a patch that can help
<tseliot> a patch for avivotool
<tseliot> smb: here's the patch: https://bugs.freedesktop.org/attachment.cgi?id=34810
<smb> tseliot, Thanks. This gets more and more complicated. One thing I just noticed. The pitch black screen is what I get when I switch to a text console. IOW those do not work, So the problem with resume is more likely that I fail to switch back to graphics. 
<smb> And I cannot do manually
<tseliot> smb: does anything change if you suspend with "sudo pm-suspend --quirk-vbe-post" ?
<smb> tseliot, That probably made no difference. But I had the funny idea of removing radeonfb from the backlist-framebuffer.conf. Which caused it to be loaded in parallel with vga16fb which presumably is bad. Though right now this not only seems to make resume work but also give me usable text consoles...
<smb> Heck, I thought radeonfb will get loaded automatically...
<tseliot> smb: I don't think you need radeonfb as the KMS driver already provides a framebuffer device. The console driver should work
<smb> tseliot, I don'T think readeondrmfb showed up on this piece of hw before. But I revert that blacklist change
<mjg59> smb: radeonfb is superceded by radeondrmfb
<mjg59> Which is automatic if you have kms
<smb> mjg59, So it is on the other laptop I got
<tseliot> I've never noticed radeondrmfb
<smb> mjI see it starting on the Dell
<smb> But I thought I had not seen in on the T42p
<smb> tseliot, Hah, it _is_ there, but too late. It becomes fb1 after vga16fb is claiming to be fb0 before. Probably taking too long to initialize
<tseliot> yes, initialisation could be slow
<smb> Especially on this reasonable quick but still only single core machine
<cking> manjo, ping
<smb> tseliot, Ok, blacklisting vga16fb to give the late radeon driver a chance, results in a corrupted but after switching to an (after suspend black) text console and back give me a working X screen.
<smb> tseliot, I think I will file my theory that it worked before into the myths drawer. At least the seems to be no regression
<tseliot> smb: :-)
<cking> bjf, hey, able to mumble to me?
<smb> Damn seems mumble lost its marbles for me
<bjf> cking, getting there
<bjf> :-)
<bjf> cking, am mumbling, shall we step out onto the balcony?
<nealmcb> when I run memtest86+ on my dell 1012, it runs clean for hours, except when I insert or remove the usb connection I use to charge my android phone.  Then I get an error at 0x0004c509 where the right-most byte is always "01" rather than what memtest is looking for.  Can someone tell me what that address is normally used for?  I get corruption of filesystems on this box regularly some time after doing a suspend and an otherwise successful resume
<nealmcb> i.e. how to check the physical memory map for that addr...
<ogasawara> apw: I notice you've got work items on the delta-review blueprint and the union-mounts blueprint which accomplish the same thing ie evaluate union-mount as a replacement for AUFS
<ogasawara> apw: care if I delete one
<apw> ogasawara, not quite sure how that occurd, but yes kill the one on delta-review i say
<ogasawara> apw: ack, thanks
 * ogasawara tries to find two more work items to close and drop us below our alpha2 trend line
 * apw added a work item for 'you' onto a foundations-m-686-something blueprint
<ogasawara> ok cool
 * tgardner thought ogasawara was running out of things to do
 * apw has closed two already today
 * amitk invents two new arm flavours to keep ogasawara busy ;)
<ogasawara> yeek
<tgardner> amitk, I see omap4 coming down the pipe. whats the second flavour?
<amitk> tgardner: nothing concrete yet, but perhaps we'll take the pain there in npitre's arm tree. We've got all these partners now :)
<jcastro> tgardner: fs-cache is working as expected on all the maverick machines I've tested it on!
<tgardner> jcastro, ack. good to know.
<tgardner> jcastro, is there a notable performance difference?
<jcastro> tgardner: hard to tell with one person on one NFS share, client side, when gigabit NFS mounting not really, however over wifi on a laptop it feels nearly-local
<tgardner> jcastro, how does it behave when you lose your wifi link? do things recover OK ?
<jcastro> tgardner: it /seems/ too but I only ran outside with it once, I will get more testing done this next week
<jcastro> tgardner: I think it would be interesting to test something like an LTSP client with local storage with an NFS /home
<tgardner> jcastro, feel free :) I'm off on other tasks....
<jcastro> no worries, I'm on it!
<nealmcb> when I run memtest86+ on my dell 1012, it runs clean for hours, except when I insert or remove the usb connection I use to charge my android phone.  Then I get an error at 0x0004c509 where the right-most byte is always "01" rather than what memtest is looking for.  Can someone tell me how to check the memory maps to find out what that address is being used for?  I get corruption of filesystems on this box regularly some time after doing a suspen
<nealmcb> (running lucid)
<apw> nealmcb, the e820 is reported in dmesg and should tell you somthing about whats there
<nealmcb> apw: thanks - I'll learn about e820's  But I also recall that the kernel may change what the bios passes on for memory mapping - is there a way to get up-to-date info?
<apw> it reports both the bios and the one it goes a head and uses
<apw> nealmcb, what filesystem are you using which shows the corruption?
<nealmcb> thanks
<nealmcb> ext4
<apw> could be bios low memory curruption, thats a low page i suspect
<apw> cnd, whats the low-memory bios corruption detection limit normally ?
<cnd> uhhh?
<cnd> apw: I think manjo knew more about that
<apw> cnd, ahh fair enough thanks
<nealmcb> fsck reported a few times that "inodes that were part of a corrupted orphan linked list found"...
<nealmcb> a manual fsck seemed to clean it up, but dpkg was hosed a bit too - haven't finished cleaning that up
<apw> nealmcb, i think we have other people with that machine and i've not heard it reported
<apw> cnd, you have a 1012 i think
<cnd> yes
<JFo> tgardner, do you think it worthwhile to post an fs-cache CFT?
<cnd> apw: what's the issue?
<apw> nealmcb is seeing oddness including fs corruption on lucid ext4, possibly related to plugging in a smart phone
<tgardner> JFo, I dunno if its really worth the effort. It _is_ mainline (and has been for some time), plus its elective, so I don't expect it'll cause any regressions.
<JFo> ok, was just catching up on scrollback
<JFo> :)
<nealmcb> cnd: I saw memtest86+ report memory errors at 4c590 every time I plugged an android phone in or out of usb.  very odd - as if something in usb was mapping to that address and yielding a "01" on read access
<cnd> hrm
<cnd> I can try that here
<cnd> I have a nexus 1
<nealmcb> I should try it with other usb devices....  mine is a g1
<cnd> nealmcb: is there a way to test this without having to boot into memtest86?
<nealmcb> cnd: that is the most easily reproduced oddness I've seen
<nealmcb> in memtest
<nealmcb> beyond that I see regular crashes some time after resuming from suspend
<nealmcb> I'm wondering if the suspend moves the memory error around and makes it worse
<nealmcb> bios-e820 in dmesg says that 0 - 9dc00 is "usable"
<apw> so its meant to be 'ram' there
<apw> and i would not expect it to change
<nealmcb> (in karmic usb-boot anyway....)
<cnd> nealmcb: ok, can you run me through the steps required to recreate the issue in memtest86
<cnd> I'm not terribly familiar with it
<mjg59> nealmcb: Almost certainly the BIOS scribbling on stuff
<nealmcb> I guess I can reserve the memory on boot
<apw> yeah likely, i thought we had bios corrupter detection turned on by default
<mjg59> USB insertion is a prime candidate for triggering SMM
<mjg59> On the other hand, we disable USB SMIs when the hcd driver bind
<cwillu_at_work> anyone have any wisdom re: compiling the xfsqa tool from the kernel tree?
<nealmcb> cnd: I happened regularly yesterday when I was doing this in the car, and I'll post a picture of the screen.  this morning I can't reproduce it - wonder if it was hotter then or something.  I just ran the normal memtest from the grub menu, and while it was running test 3 or 4 I plugged a usb cable in and out with my android g1 attached.
<cnd> nealmcb: I just tried running both tests 3 and 4 while continuously plugging in and removing my n1
<cnd> no issues here
<nealmcb> cnd: thanks for checking.  my memtest screen is shown here (I'll resize the picture to make it easier to see soon): https://wiki.ubuntu.com/NealMcBurnett/dell1012
<nealmcb> that shows the errors in test 6, but I think it happened with most any test
<cnd> well, the simplest solution is to try new memory :)
<nealmcb> I'll try to reproduce it some more at this end.  I had the filesystem problems with the original 1GB memory card, so I think it is more likely to be some problem with the usb or bus or something.  but I'll try to reproduce it more
<ogasawara> apw: just browsing through the debian commonisation patch for Maverick and notice we had to hard code "series := maverick" in debian/rules.d/0-common-vars.mk
<ogasawara> apw: so presumably whomever open the M+1 release will have to remember to update that bit
<apw> ogasawara, yeah there are a couple of places the series is used, and over time i am going to convert them over to that
<ogasawara> apw: cool
<JFo> <-lunch
<apw> ogasawara, the plan is that the update-debian script will use that
<apw> sorry apply that as its copied in, its @SERIES@ in the orignal
<apw> right now there are other places which have lucid say in, like control.stub.in, which i want to convert to using that one instance
<apw> but tis a bigger job than i wanted to bite off at this point
<ogasawara> apw: ok so still some cleaning up but getting us in the right direction, I'll get it applied
<apw> yeah, adding one to remove 5 others long term, in this one it adds one and removes one
<tseliot> mjg59: shall I check the existence of the ATIF method before calling it or is it fine to just call acpi_evaluate_object?
<mjg59> tseliot: You can call it, but you should handle the failure appropriately
<mjg59> status will be AE_NOT_FOUND if it's not there
<tseliot> mjg59: ah, but it should suffice to check ACPI_FAILURE(status)
<mjg59> Check status
<mjg59> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {printk("Things are broken\m"); return -1}, or something
<tseliot> ok, thanks again
<tseliot> mjg59: do you think we should print something if atif is not there too (without failing)?
<mjg59> I don't think so
<mjg59> There's no point in printing kernel messages when something valid happens
<tseliot> ok
<tgardner> apw, how are you intending to apply debian commonization bits from ubuntu-debian ? are you using initial-rollout/MAKER to splatter the various branches?
<apw> tgardner, that is the initial-rollout yes, next step for me is distill out just the updater from it
<apw> and that stuff will get removed and replaced by 'UPDATE' sort of thing
<apw> and a 'README' of course
<tgardner> apw, so, I'm working on the maverick ti-omap4 branch. shall I just rsync the debian directory and go from there?
<apw> tgardner, ahh you need to change the @SERIES@ to the right thing
<apw> there is a log generator in there as well, but you could just steal the commit message from maverick
<tgardner> apw, not sure to what you are referring?
<tgardner> got SERIES fixed
<apw> yeah the idea is the updater will do that as it copies it in, and will do the changelog as per mavericks update for example
<apw> see how the changelog contains the buglinks etc from the ubuntu-debian changelog
<apw> if you are commiting the tip of u-d as of now, then whats in maverick should be the same, so youc ould cut-n-paste it
<apw> the updater will know how to do that
<tgardner> apw, for this first time I probably don't have to worry about that, right?
<tgardner> its an initial commit
<apw> tgardner, oh i see, yeah its the initial version of the branch ...#
<johanbr> this is weird... under 2.6.35-3, /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq always reports maximum frequency
<johanbr> ondemand governor, negligible load
<apw> johanbr, its not systemic as my local machine has that on and is at 800MHz mostly
<apw> johanbr, do you have lots of kslowd's eating CPU?
<johanbr> no, I don't think so
<johanbr> I have some other kernels installed, will reboot a few times and see when it started appearing...
<johanbr> hmm... OTOH, powertop says CPU spends 99.6% of the time at 800 MHz
<apw> hrm
<tgardner> apw, wrt to the config checker, why is debian.master/config required? ti-omap4 is currently 2.6.34 based, so it seems a bit odd to require 2.6.35 config options.
 * tgardner lunches
 * cking calls it  day
<bcurtiswx> with 20 people affected it may be worth looking at bug #548992, with some recent good information for debugging
<ubot2> Launchpad bug 548992 in debian (and 1 other project) "Wireless connection frequently drops [deauthenticating by local choice (reason=3)] (affects: 21) (heat: 152)" [Undecided,New] https://launchpad.net/bugs/548992
<bcurtiswx> now 21 apparently, lol
 * JFo looks
<JFo> looks like someone changed it to confirmed before it hit my radar
<JFo> so bcurtiswx am I right in my assumption that this issue now appears to be a result of network-manager and DHCP?
<JFo> if so, this may need to be looked at by the n-m folks
<JFo> bcurtiswx, are you affected by it as well?
<bcurtiswx> JFo: well, i don't know enough to say its not one or the other.  I have been affected by it, and actually will look to see if its happening again as i have been disconnected on occasion today without warning
<JFo> hmmm, if it still seems to be the case, are you willing to try some other network manager?
<JFo> to see if using that resolves it?
<JFo> so that we can narrow?
<bcurtiswx> i'd be happy to help, what should I try
<JFo> on that I am not completely certain
<JFo> I have seen other cases reported like this where they tried a different connection manager
<JFo> let me see what I can find
<bcurtiswx> Ok
<bcurtiswx> and I apologize if i get DC.. i'll try to recognize it and get back ASAp
<JFo> bcurtiswx, I am under the impression that we are looking at connection-manager for maverick, but don't quote me :)
<JFo> bcurtiswx, no problem
<bcurtiswx> JFo: OK
<JFo> looks like WICD is one that has been tested
<JFo> let me see if there are others
<bigcx2> hey all, i kinda have an off the wall question for all you gurus :)
<bigcx2> i'm trying to create a custom live cd and i have a custom squashfs image i would like to mount for it
<bigcx2> but everytime i boot it up, it says that it can't find a bootable medium
<bigcx2> but
<bigcx2> i can succesfully mount the squashfs image by hand
<bigcx2> from the initramfs prompt i get dropped into
<bigcx2> but how do i get past the initramfs shell and into my squashfs image?
<bigcx2> i've seen stuff around with mount -o move but i can't quite get it right
<bcurtiswx> JFo: would it help to say that at home I don't get this problem, but here at work I do (Campus network)
<JFo> interesting
<JFo> it would help very much
<bcurtiswx> lemme know anything you need from my comp and i'll pastebin it
<JFo> will do
<jjohansen> Lunch ->
<ogasawara> apw: CONFIG_INIT_PASS_ALL_PARAMS I'm assuming it's not necessary to have that turned on for ports? ie I can disable it for ports.
<tgardner> ogasawara, won't they have the same upstart?
<ogasawara> tgardner: that's true
<tgardner> I don't think CONFIG_INIT_PASS_ALL_PARAMS is arch dependent
<JFo> it annoys me to no end that e-mail I send to ubuntu-devel must await moderator approval
<bcurtiswx> are you a devel member? i think they wanted devel for members only and devel-discuss for anyone.. no sure tho
<unlex> hi
<unlex> what is the use of afence register?
<JFo> bcurtiswx, just griping. I think it is something I could fix if I were so inclined :)
<JFo> I just like to gripe every so oftn
<JFo> often*
<bcurtiswx> nothing wrong with that :)
<JFo> :-D
<unlex> anyone understand fence registers here?
<bcurtiswx> unlex: IDK, but my google search returned http://is.gd/cT98f
<JFo> manjo, where is the git repo for the kernel-qa bits? /me forgets
<JFo> could have sworn I had a cloned branch of it, but I can't find it
<bcurtiswx> JFo: got DC
<apw> ogasawara, doh yeah, should be on for ports as well yes, sorry
<ogasawara> apw: no worries, enabled it and it's building nicely now
<ogasawara> mpoirier: bug 591941 is on the release meeting agenda tomorrow.  is there any update there and if so, could you post it as a comment to the bug?
<ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/591941
<mpoirier> ogasawara: hold on a sec, I'll look at it.
<mpoirier> ogasawara: I am currently working with TI people on it.
<ogasawara> mpoirier: ok thanks
<ogasawara> mpoirier: any idea if a resolution will happen before next friday (as that's the cut off date for our Alpha2 kernel)?
<ogasawara> mpoirier: else I'll bump the milestone on the bug out to alpha3
<mpoirier> ogasawara: it is hard to say if we'll have a solution.
<mpoirier> we are faced with a timing issue introduced by the preemption model.
<mpoirier> I will bump the milestone to alpha3.
<mpoirier> That way no one is disapointed.
<ogasawara> mpoirier: perfect thanks.
<mpoirier> ogasawara: done with comments and bumped milestone
<ogasawara> mpoirier: sweet thanks, it makes my life easier for tomorrows meeting
<Sleep_Walker> amitk: there is even no DMA support for MX5 :/
<JFo> -ENOCONTEXT
 * ogasawara lunch
<tseliot> mjg59: I'm getting "Return, Return, Super_L" if I press that key with atif (and acpi_osi="!Windows 2009")
<tseliot> still no event is listed in acpi_listen
<mjg59> Unsure what's wrong then, I'm afraid
<tseliot> I didn't get anything before calling atif
<kees> the strangest things appear in kernel builds:
<kees> II: New modules (you've been busy, wipe the poop off your nose)
<tseliot> mjg59: is there some acpi spec I can look at with all these methods (including atif)?
<mjg59> No, atif is entirely specced by ATI
<kamal> kees: yeah, when there are no new modules then it calls you a "slacker"
<kees> kamal: hah!
<tseliot> mjg59: ok
<mjg59> Everything that's standardised is in the ACPI specification, which you can get from www.acpi.info
<tgardner> kees, thats a BenC original :)
<tseliot> mjg59: great, thanks for the link
<tseliot> mjg59: does _DOS have anything to do with this?
<tseliot> not that it would explain the lack of that acpi event..
<mjg59> tseliot: If _DOS isn't set correctly then you won't get hotkey events
<tseliot> mjg59: ah, so brightness keys shouldn't work
<mjg59> Hm. Brightness typically will
<mjg59> But not display switch
<tseliot> mjg59: ah, so you're saying that I might be on the right track?
<mjg59> It's possible
<tseliot> mjg59: if so, I would just have to implement another function and set the right bits. That would be great (if it worked)
<mjg59> tseliot: _DOS should be set at boot time
<mjg59> You can alter it through /proc/acpi/video/DOS
<tseliot> mjg59: ah, how? It says DOS setting: <4>
<mjg59> Just write to it
<mjg59> Hang on a moment...
<tseliot> in /proc/acpi/video/VGA2/DOS
<tseliot> ok
<mjg59> 4 should be correct for getting events
<tseliot> the default should be 1 though
<tseliot> mjg59: "The system BIOS, when doing switching of the active display, must verify the state of the variable set by the _DOS method. The default value of this variable must be 1"
<mjg59> Yeah, which means you don't get events
<mjg59> That's why it's changed by the OS
<tseliot> right
<tseliot> mjg59: I guess I should set the 1st bit to 3
<mjg59> tseliot: You can try, but 0 or 4 is correct for getting hotkey events
<tseliot> I see
<tseliot> right, nothing changes
<tseliot> mjg59: I guess my only chances are _DCS, _DGS and _DSS
<tseliot> according to the acpi spec 40a they are all "Required if the system supports display switching (via hotkey)"
<mjg59> The spec requires them, but they do nothing useful
<tseliot> hmm... maybe it's worth bugging AMD about this
<tseliot> anyway something I can do tomorrow
<tseliot> good night
#ubuntu-kernel 2010-06-18
<smb> morning
<cooloney> smb and cking morning
<cking> yay
<smb> Another Friday morning which hopefully turns into a Friday evening soon. :)
<cking> poor smb
 * apw yawns ... morning
<smb> cking, Oh, there is nothing specific. Just the usual lamment. :)
<smb> apw, Welcome :)
<apw> heh yeah, roll on beer-o-clock
<cking> we need a time machine that's for sure
<TeTeT> smb: the public bug for the WWAN module in the x201 is https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/592046, I've put it in the private bug description
<ubot2> Launchpad bug 592046 in linux (Ubuntu) "Lenovo x201 WWAN module in Lucid kernel (affects: 1) (heat: 732)" [Undecided,Incomplete]
<smb> TeTeT, Ok works for me
<smb> So I like will look at that next week
<TeTeT> smb: great :)
<kraut> moin
<apw> moin
<amitk> apw: know why the omap kernel does not have any information generated from the variables in vars.omap? https://edge.launchpad.net/ubuntu/+source/linux/2.6.35-4.5
<apw> amitk, sorry what information is missing??
<amitk> "No description available for linux-image-2.6.35-4-omap in ubuntu maverick"
<amitk> but if you click on the kernel, it shows the info
<amitk> (on the link above)
<apw> amitk, could it just be recent
<apw> amitk, can you check now, as it seems to have a description on that page for me
<apw> amitk, oh you are saying on that link it has info, so where you seeing 'no informaiton' ?
<amitk> apw: yeah, it's there now, was this a recent upload that just get populated into LP?
<apw> yeah probababally only got though recently
<amitk> apw: no, there was no info on the link 5 minutes ago
<apw> i note sparc is still new
<amitk> I guess that page is not generated atomically
<apw> or it cannot get the inforamtion till the kernel is published by the publisher run
<amitk> apw: care to apply this patch which cleans up the description a bit? http://paste.ubuntu.com/451547/
<apw> amitk, maverick right?
<amitk> yeah
<apw> amitk, sent it out to leann
<amitk> apw: thanks
<apw> np
<tseliot> mjg59: are you around?
<tgardner> apw, did we ever bottom out on the minim CPU support in the toolchain?
<tgardner> minimum*
<apw> tgardner, its on robbie's radar to get the recommendations and write up sorted out
<apw> i have only heard 'i686' from doko and 'i686 and cmov' from keybuk, neither on official channels.  so i'd say its still up in the air for s
<apw> us
<tgardner> apw, ok. I was just reading some internal reports about thin clients.
<mjg59> Note that building glibc for i686 will generate i686 and cmov and i686 nopl
<tgardner> apw, on a diff topic, can you have a look at the maverick ti-omap4 branch to see if I got your commonized debian bits right. There was a bit of confusion over the location of the enforce file.
<mjg59> Which kills Geode
<mjg59> (even though it has cmov)
<tgardner> Geode is 586, right?
<apw> tgardner, the enforce file should be in debian.master as it is series common
<tgardner> apw, then I have it in the wrong spot.
<apw> tgardner,i suspect you have two then
<mjg59> tgardner: No, Geode LX is 686
<tgardner> apw, no, just one.
<mjg59> (depending on your precise definition of 686)
<apw> tgardner, hrm, then i'd expect updateconfigs and any build to fail if its in the wrong place
<tgardner> mjg59, some of those low enbd CPUs are kinda funky, like VIA
<tgardner> end*
<mjg59> tgardner: Yeah, some of the VIAs lack cmov
<mjg59> But the 686 family isn't very well defined
<apw> tgardner, i think such a move is going to kill off my bastion host, as that via and doesn't seem to have cmov in /proc/cpuinfo
<mjg59> cmov is the main reason to go 686
<tseliot> mjg59: using my patch (to use ATIF) + acpi_osi="!Windows 2009" = keycode 227, my patch without acpi_osi = keycodes 25 28. This happens without X. Furthermore, If I use the keymap tool, I can see that hotkey events (scan code 0x00 key code: switchvideomode) come from /dev/input/event4 while events from other keys come from event3. 
<mjg59> But gcc and binutils will potentially generate other 686 instructions as well
<mjg59> tseliot: Ok, so that sounds like it works
<tseliot> mjg59: in X, however, using xev, I still get Return, Return, Super_L
<mjg59> tseliot: X may be grabbing something or other
<tgardner> apw, well, I've uploaded the ti-omap4, so now you should come along behind me and put some whoop-ass on that branch, i.e., recreate the debian bits in your own image.
<apw> tgardner, heh ok ... will have a look :)
<tgardner> apw, I don't think its too far off
<tseliot> mjg59: that's what I thought. Killing the gnome-settings-daemon doesn't seem to help though
<apw> tgardner, yeah can't tell
<tseliot> mjg59: furthermore I still can't get an event using "acpi_listen"
<tseliot> with or without X
<mjg59> tseliot: You won't if it's sending windows+p
<mjg59> However, if you're seeing switchvideomode come from somewhere other than the normal keyboard device, it's working
<tseliot> mjg59: yes, I guess that's the device created by the dell wmi module
<mjg59> More likely it's the ACPI device
<smb> apw, tgardner The SRU team noted today that there is a big number of bug reports which have fix-committed for Maverick. From my feeling there should not be really much not being released. But I am usually not looking at Maverick that closely.
<apw> smb, i would expect there to be some stuff outstanding but not a whole heap
<JFo> cking, i seem to be unable to join your firmware team
<apw> do you have a list we can look at, so i can see if there is an issue or just they are outstanding
<smb> https://bugs.edge.launchpad.net/~ubuntu-sru/+subscribedbugs?field.assignee=&field.bug_reporter=&field.has_no_package=&field.has_patch=&field.omit_dupes=on&field.searchtext=linux&field.status%3Alist=CONFIRMED&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INPROGRESS&field.status%3Alist=NEW&field.status%3Alist=TRIAGED&orderby=targetname&search=Sear
<smb> ch&start=150
<smb> Oh how useful
<smb> Quite a few are sound bugs which probably use committed differently than we do
<apw> dammit launchpad searching is just stupid
<smb> Like  https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bug/567494 for example
<ubot2> Launchpad bug 567494 in linux (Ubuntu Maverick) (and 2 other projects) "Problem sound on Fujitsu Siemens Amilo XI 1526 (affects: 1) (heat: 10)" [Low,Fix committed]
<cking> JFo, lemme subscribe you
<JFo> thanks cking 
 * JFo gathers bits to test
<tgardner> smb, anything thats fix committed for Maverick ought to be fix released
<apw> smb, i suspect those are getting lost because pitti shoved it over to the kernel package, so dtchen cannot see it anymore and it was he who was tracking it
<smb> Right, so I probably goe over all of them and change commited to released
<apw> well we need to check the commits are in
<apw> like the one there is in so i'll fix released it
<smb> ok
<apw> apw@dm$ git merge-base 3353541fe533350a22a03e2fb7dc085b35912575 origin/master
<apw> 3353541fe533350a22a03e2fb7dc085b35912575
<apw> so that one at least is in
<tgardner> apw, whats the name of the 'misc' blueprint? I need to drop the maverick LBM and ti-omap4 work items in it.
<apw> kernel-maverick-misc
<apw> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-misc
<apw> tgardner, ^^
<tgardner> apw, my feeble memory thanks you
<apw> tgardner, you can find all of the blueprints for lucid now from the wiki.ubuntu.com/Kernel
<apw> follow 'releases' and there is a link under Lucid thre
<tgardner> apw, man, you are _way_ too organized
<apw> tgardner, thats a bit of me and a bit of ogasawara  ... there is a reason you let us do things :)
<cwillu_at_work> ooo, drama on the btrfs mailing list :)
<JFo> well that was fun
<JFo> brb
<tseliot> mjg59: if I press any other hot key (e.g. brightness keys, wlan) I get this in kern.log: "dell-wmi: Unknown key 0 pressed"
<mjg59> That seems to be a dell-wmi bug
<tseliot> ah a separate bug then
<mjg59> Yeah
<tseliot> ok
<smb> apw https://bugs.edge.launchpad.net/~ubuntu-sru/+subscribedbugs?field.searchtext=linux
<tgardner> cnd, ogasawara, lag, bouncing emerald for new kernel
<lag> tgardner: oka
<lag> y
<lag> tgardner: Can you let me know when it's back please?
<tgardner> lag, why would I know any sooner then you?
<lag> tgardner: Oh, it's not with you is it?
<lag> Are you bouncing right away?
<tgardner> lag, nope, its in Virgina (or somewhere where I can't hear it)
<lag> :)
<tgardner> lag, bouncing tyler.mills as well
<lag> Rubbish! I'm being shot from all angles! 
<lag> Back
<lag> ty
<JFo> moin bjf 
<bjf> moin
<tgardner> kees, is procps the right place to dump 'sysctl net.netfilter.nf_conntrack_acct=1' ? CONFIG_NF_CT_ACCT is being deprecated.
<cking> morning bjf - thanks for the 2nd load of logs
<bjf> cking, welcome, wish it was more
<apw> smb, ok i've gotten a script together to find these maverick noms which are Fix Committed and yet have BugLink:'s ...
<cking> bjf, no chance of getting any more then?
<bjf> cking, working on it, there's more just having "issues" :-)
<cking> bjf, no sweat, it's not urgent
<bjf> cking, running into unicode breakage in odd places
<smb> apw, Very nice. This will give us a lot of bonus points with the SRU team. :)
<apw> though i don;'t know quite how many its going to close as yet
 * cking wonders where the day has gone
<smb> cking, Towards B o'c :)
<cking> glug glug
<apw> bah an hour here
<smb> apw, Could be a few. I have been looking at least at one page listing
<apw> smb, i am thinking that this will find like 10, more accurate numbers in a sec
<smb> cool
<apw> smb, 15 by the looks of it ...
<smb> apw, Better than nothing. I guess after we got rid of those, we need to check on the remaining manually
<apw> i suspect that is a fair chunk
<ogasawara> apw: http://people.canonical.com/~ogasawara/mark-fix-commited.py
<ogasawara> apw: http://pastebin.ubuntu.com/451674/
<ogasawara> apw: not exactly what you want, but it will return the task, nomination, and milestone
<apw> ogasawara, thanks anyhow, i'll hit it harder till it squeeks
<kees> tgardner: I need slightly more background.
<kees> tgardner: (for net.netfilter.nf_conntrack_acct)
<kees> tgardner: you're saying the CONFIG_ is being dropped, but the sysctl is staying, but the sysctl defaults to the opposite of what we've had?
<kees> tgardner: why is the CONFIG_ being dropped?  it might live in /etc/sysctl.d/10-network-security.conf, but maybe iptables should ship a new /etc/sysctl.d file?
<tgardner> kees, CONFIG_NF_CT_ACCT is getting deprecated in favor of a sysctl to set that behavior at runtime. I'm sending the deprecation patch, but the default behavior should remain the same.
<kees> tgardner: why is it being deprecated?
<tgardner> kees, I'm going to send an email to ubuntu-devel about this issue 'cause its sort of a general problem, e.g., setting syctl's provided by a module
<tgardner> kees, I'm deprecating  CONFIG_NF_CT_ACCT because it prints some noise in the dmesg log
<kees> tgardner: it's not being deprecated upstream?
<tgardner> kees, its been marked for deprecation sinece before 2.6.29
<kees> hah
<tgardner> I'm just doing the patch to finally implement it
<kees> okay, well, /etc/sysctl.d is the place to ship sysctl settings.  procps is responsible for activating them.
<kees> procps itself ships some system-wide defaults.
<kees> things like wine, dosemu, kvm-qemu-static-extras, etc ship files in there.
<apw> smb, i am sure you are off by now, but i have just run that update and closed off a bunch of bugs ... hope that'll make pitti et al happier
<tgardner> kees, but what happens when the module is not installed until after sysctl does its thing at startup?
<smb> apw, I am still hanging around. :) And thanks
<kees> tgardner: ew
<kees> tgardner: sounds like you need a hook in /etc/modprobe.d instead
<tgardner> kees, yeah, thats what I'm thinking.
<kees> tgardner: ship a file that contains:    install conntrack-acct /sbin/modprobe --ignore-install conntrack-acct; sysctl net.netfilter.nf_conntrack_acct=1
<kees> kind of hacky, but it'll work
<tgardner> kees, as part of modprobe.d ?
<kees> tgardner: as a file in /etc/modprobe.d/ yeah.  like ship it as  /etc/modprobe.d/conntrack-acct.conf   or something.  probably should present the question and this idea to ubuntu-devel anyway.  perhaps I'm on crack.
<kees> tgardner: you can see examples is the oss .conf file in there now
<tgardner> kees, in lucid? All I see are blacklists
<kees> hm.  my "alsa-base" package seems to claim it ships /etc/modprobe.d/alsa-base.conf
<kees> examples like:
<kees> install snd-via82xx /sbin/modprobe --ignore-install snd-via82xx $CMDLINE_OPTS && { /sbin/modprobe --quiet --use-blacklist snd-seq ; }
<kees> (oh, I guess it should include $CMDLINE_OPTS
<kees> )
<jjohansen> -> Lunch
 * ogasawara lunch
<MTecknology> apw: Keeping busy I see
#ubuntu-kernel 2010-06-19
<kees> how do I update the kernel on a bootable USB stick?
<jjohansen> kees: what kind of bootable stick?
<kees> jjohansen: I was using one created with usb-creator-gtk.  figured out I could swap out the vmlinuz in the /casper directory.  that got me far enough (I didn't need a full userspace, just needed to see dmesg)
<Sangeeth> I'm new to Linux Kernel and deveopment... Could someone help me out...
<Sangeeth> I would like to start contributing to the kernel dev team... I'm a rookie... But, i have a lot of passion for it... I can program well in C++...
<hyperair> wow, such passion, that he leaves only 3 minutes after declaring it.
<jernst> ;-)
<jernst> is it the right channel to discuss alsa issues with recent sound cardsÂ (hda_intel ALC887) ?
<hyperair> you should probably poke crimsun_ 
<jernst> thanks hyperair
<jernst> crimsun_: I filled bug 595094 and have six of these machines waiting to be deployed with Ubuntu ; unfortunately the sound doesn't work as expected (very low volume). If you have time to look at it, let me know what I can do (I tried to play with hda_analyser but had no luck)
<ubot2> Launchpad bug 595094 in linux (Ubuntu) (and 1 other project) "Inaudible sound on Asus EeeTop ET2203 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595094
#ubuntu-kernel 2010-06-20
<Sangeeth> I want to join the Ubuntu Kernel team... How can i?..
<Sangeeth> I would like to join the kernel team...
<Sangeeth> Is there anyway for a rookie like me to start from the basic level of Kernel Dev or mod?
<Sangeeth> Some guidance for beginner, please?..
<Sangeeth> Can i join this team?.. Prog. languages - C, C++
<kees> !weekend
<ubot2> It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week.
<Sangeeth> Will I be able to contribute to this team?..
<Sangeeth> I'm interested to join this team... Could some one hep me?..
<Sangeeth> I'm interested to join this team... Could some one help me?..
<Sangeeth> I would like to join this team... Some guidance please...
#ubuntu-kernel 2011-06-13
<quentusrex_> Has anyone run into the bug with realtech nic cards where they lose inbound traffic when under load?
<quentusrex_> I have reproduced the issue with 3 different realtech nics and when the CPU has less than 50% idle I get over 10% loss of all udp traffic.
 * apw yawns
<jk-> hey apw
<apw> jk-, morning
<jk-> apw: fairly early there, no?
<apw> jk-, just  before 8 yeah
<micahg> hi, is natty not supposed to provide an automatic upgrade form 2.6.39 to 3.0?
<micahg> oops, I meant oneiric
<apw> micahg, yes it will once we are sure we've gotten all the issues sorted out
<apw> like it renedering your whole machine unupgradable
<micahg> ah, ok :), just wanted to make sure it was known and not an oversight, thanks!
<apw> micahg, yes its known, the kernel packages are in but not the meta for the moment, while we confirm that the required fixes are out
<micahg> k, great, will leave you people to work now :)
<apw> morning ppisati 
<ppisati> apw: morning
<apw> ppisati, how goes the CVE for arm slog?  
<apw> (slog == slow never ending horrible)
<ppisati> apw: i took a break, i think we have enough kernels to test for now :)
<apw> that is for sure
<apw> they must hate you in #u-arm
<ppisati> apw: never said it, but i think so :)
<apw> cking, morning
<cking> apw, hiya
<apw> cking, how ya doing
<cking> not so bad -  however I've just had to pick myself up from the floor after hearing the cost of fixing my poorly car
<apw> woh, how much
<cking> ..replacement gearbox and possibly replacement clutch = 4 figure sum
<apw> cking, oww
<cking> the car is worth about the same amount, but to replace it will cost a load more, so I think it's worth it for another 3-4 years on the road
<apw> cking, hard decision indeed
<apw> sell one of your kids, that'll offset it
<cking> heh, I have to pay for somebody to take them off me ;-).  Considering how much one pays for tax and insurance, it's not that much over 3 years.
 * cking punches mumble into submission
<bullgard4> System Monitor > Processes > tab "Waiting Channel": What is a Â»waiting channelÂ«? I found: "The address of an event on which the process is waitingâ. This definition seems to be poor as I hardly would call for example a poll_schedule-timeout an "address". Can you give a better definition?
<apw> bullgard4, well that string is the name in the symbol table for that address, so it is literally an address, sometimes symbolically represented
<bullgard4> apw: Ah, understood. --  Thank you very much for your help.
<nigelb> who posts to the kernel team blog?
<nigelb> or rather who among the people posting to kernel team blog are ubuntu members :-)
<apw> nigelb, i would think that everyone who posts to the kernel team blog (on voices yes) is an ubuntu member, why ?
<nigelb> apw: http://nigelb.me/ubuntu/2011/06/10/cleaning-up-the-planet.html
<apw> nigelb, are we needing to have an owner for it then?
<nigelb> apw: yes
<nigelb> apw: Just an Ubuntu member to own the feed
<apw> nigelb, well i guess either pgraner, tim or myself are the obvious choices
<nigelb> apw: whats your Launchpad ID? I'll put your ID in :-)
<apw> nigelb, apw
<nigelb> apw: heh, after you guys kicked pgraner to QA, he's not obvious choice anymore :-P
 * nigelb hides
 * apw gets hit boxing gloves on
<jwi> yay, regression in lucid-proposed kills intel wifi :/. bug 796336
<ubot2> Launchpad bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Confirmed] https://launchpad.net/bugs/796336
<jwi> and it seems to be a stupid one-liner that tgardner had doubts about months ago
<apw> jwi, could be, i've retagged it appropriatly
<jwi> i'm pretty sure it is - from reading the code, lucid just doesn't have the code to handle the new firmware file format
<jwi> so commit "iwlagn: Support new 5000 microcode." turns into "break 5000 stuff in funny ways"
<apw> and what was the one liner that rtg wasn't happy with ?
<jwi> that commit
<jwi> see https://lkml.org/lkml/2011/4/27/416
<jwi> (and yes, it's in maverick-proposed too. that shouldn't break though, the maverick stack seems to be capable of handling the new format)
<apw> jwi, having read all that i am unsure why this would even affect lucid
<apw> jwi, we have the old firmware still
<apw> and the old driver shouldn't even see the new one
<jwi> apw: ah, thats because iwlagn is broken in multiple ways :)
<apw> jwi, and they are
<jwi> it reads the api version from the firmware header - and with new firmware format, that version is 0 (which is < API_MIN = 1). now, instead of trying the other available firmware files, it just quits.
<jwi> so thats why falling back to the older firmware files doesnt work - this should be fixed for maverick+, too
<apw> ok so could you document that in the bug, that'd make things easier
<apw> sounds like the new firmware is a mistake in lucid given all this, hmm
<jwi> right, i was hoping to get some confirmation first from intel on whether that firmware actually *has* the new format
<jwi> nope, the firmware is fine. it's the driver that shouldnt claim to support it - because it doesnt
<apw> jwi, but then as the driver doesn't support it one could argue that its pointless having it on the machine
<jwi> compat-wireless...
<apw> which if it needs it should carry the firmware there and avoid the mai
<apw> main kernel modules seeing it
<jwi> definitely - but i don't think that's the standard procedure for compat-wireless?
<apw> hmm pretty sure its meant to carry its own firmware, and even has hacks to rename them to ensure non-overlap (the ubuntu packaging thereof)
<jwi> apw: hm, see tgardner's #2 in bug 653854 (which is currently sitting in lucid-proposed).
<ubot2> Launchpad bug 653854 in linux-firmware "Oct 3 06:01:05 bt kernel: usb 1-7: ath9k_htc: Firmware - ar9271.fw not found Oct 3 06:01:05 bt kernel: ath9k_hif_usb: probe of 1-7:1.0 failed with error -22" [Low,Fix committed] https://launchpad.net/bugs/653854
<apw> jwi, i think we've tended to do that as now we have more than one lbm and we'd have to put the firmware in them all if its not compatible
<apw> be good to confirm it is a format issue, we may be able to short circuit the load in lucid kernel
<apw> as an expedient fix
<jwi> apw: alright, poured my guesstimates into the report. i'll follow up if there's any further info from intel, but i'm pretty sure that this is what's going on
<apw> jwi, sounds good thanks, will slap people when they wake up
<apw> cjwatson, i am thinking that the 3.0 kernel should have an install dependancy on the libc changes you made, given how hard it was for me to get out of the mess, i therefore plan to add those and re-upload before shipping linux-meta ... am i making sense
<cjwatson> Breaks on older versions would be more appropriate.
<cjwatson> although, actually, I don't see why you need to bother
<cjwatson> it only breaks when you try to upgrade libc to a newer version after rebooting to the new kernel
<cjwatson> anyone upgrading libc to a newer version at this point is almost certainly going to be upgrading to a version with my fix anyway
<cjwatson> so I would just ignore it if I were you
 * apw thinks about that ... thats a fair point, so perhaps i will ignore it, thanks
<cjwatson> and it won't affect dist-upgrades from older releases since they're unlikely to reboot between upgrading the kernel and upgrading libc (even if the upgrade were somehow to an unfixed version)
<cjwatson> you'll need to think about it for backports to lucid, but maybe by then it will be 3.0.x anyway
<apw> yeah i suspect so
<ppisati> dunno if it's more pain to compile a kernel on a panda board, or roll your own cross toolchain
<amitk> ppisati: why do you need to do either?
<ppisati> amitk: trying to see if i can reproduce a problem we have with latest linaro toolchain
<amitk> ppisati: aah, in that case it is probably easier to native compile the kernel on panda if you have a usb disk connected
<ppisati> amitk: doing both of them
<ppisati> amitk: and somehow my panda doesn't like my usb disk
<ppisati> amitk: i hopne it's not the disk that is failing
<diwic> apw, do you have a moment?
<apw> diwic, yep, wassup
<diwic> apw, I'm trying to follow rtg's instructions but I fail. There is an email ~ 2 weeks back about that I should use "git cherrypick -s -x" but it seems to fail
<apw> ok how does it fail ?
<apw> cherry-pick yes 
<apw> -s to sign, and -x for the upstream reference in the pick
<diwic> let me pastebin it for you
<apw> ack
<diwic> http://pastebin.canonical.com/48405
<apw> diwic, so there are conflicts it seems?
<apw> diwic, which tree are you in ?
<apw> that by its name would be an upstream tree no ?
<diwic> apw, linux-2.6
<diwic> apw, but feel free to suggest another one if you think that's more appropriate
<apw> i'd be expecting you to do the cherry-pick in the one you want to apply it to ?
<diwic> apw, for reference, here's his message: https://lists.ubuntu.com/archives/kernel-team/2011-May/015710.html
<apw> so i assume you made all three originally with a git format-patch -3 sort of thing
<diwic> apw, sort of
<apw> he is suggestng you are missing the s-o-b and (cherry picked from xxxxx) lines in the first two
<apw> and the easiest way to get those is just to cherry-pick the patch
<apw> which you do in the destination branch
<diwic> so I must first apply them there and *then* cherry-pick them, right?
<diwic> and I apply them with git am?
<apw> normally these are upstream commits we want to cherry-pick and as long as you have some remote with them applied in the current repo
<apw> you can simply checkout the destaination brnach and git cherry-pick them into it
<apw> the cherry-pick finds extracts and applied them in one motion
<diwic> so cherry-pick moves them between two branches in a repo
<diwic> but isn't this two different repos, one linux-2.6 and one ubuntu-natty repo?
<apw> well normally for me at least the former is the --reference'd repo in the latter, and so all of its sha1s are available in ubuntu-natty
<diwic> hrm
<diwic> but I don't want to change my ubuntu-natty (I want it to track the one on kernel.ubuntu.com), so I start off by cloning it
<diwic> or should I clone with reference there as well?
<diwic> I have the same reference btw
<diwic> and suppose I actually succeed with making these cherry-picks, should I then use format-patch to be able to send them to the list?
<apw> diwic, you can safely clone with reference therre as well
<apw> and yep after the cherry-pick you would format-patch as normal
<apw> sforshee, hey ... morning
<sforshee> apw, hi
<apw> sforshee, i think you were involved in the linux-firmware updates for 'all releases' ?
<apw> seems we have a regression due to the iwlagn firmware on lucid-proposed
<apw> https://launchpad.net/bugs/796336
<ubot2> Ubuntu bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Triaged]
<sforshee> apw, I thought the only thing that was updated was ralink firmware
<apw> sforshee, the rumour is that it contains also iwlagn abi#5 firmware ... perhaps you could investiate and work out what the reality it ... believe nothing i have said as its all rumours
<apw> but that bug is enough to prevent linux-firmware being promoted to -updates till we have it resolved one way or the other
<ppisati> how do i request a pocket copy?
<ppisati> linux-fsl-imx51 2.6.31-609.26 from c-k-t ppa
<ppisati> i guess an email it's enough
<jwi> apw: its about the kernel thats in -proposed, not linux-firmware. the api-5 ucode was moved to -updates back in april ...
<apw> sforshee, down't worry about that issue, i'll look at it, seems its not at all what i thought originally
<sforshee> apw, ack
<chadhogg> in hopes that there are more eyes here on a Monday morning than a Sunday afternoon I'll repeat my question from yesterday once, but then not bother you again:
<chadhogg> I apologize if this is the wrong venue, but I was hoping to get some real-time feedback on what I could do to continue debugging Launchpad bug 793437
<ubot2> Launchpad bug 793437 in linux "Unusable Slowness In 2.6.38-8" [Undecided,Confirmed] https://launchpad.net/bugs/793437
<diwic> chadhogg, my best guess would be https://wiki.ubuntu.com/Kernel/KernelBisection
<diwic> chadhogg, using maverick and a Natty kernel on top of that could also be interesting b
<diwic> perhaps
<chadhogg> diwic: thanks; that looks complicated, but I'll give it a try
 * diwic just sent his activity report to the public kernel-team ML...fortunately there was nothing NDA in it
<apw> ogasawara, i am liking [Acked]
<ogasawara> apw: I am too
<apw> i shall take that on
<ogasawara> bjf: you're in london tomorrow right?
<ogasawara> bjf: I was gonna get the IRC meeting notes prepped
<bjf> ogasawara: i'm there now
<bjf> ogasawara: i could probably run it from here
<bjf> ogasawara: you want a copy of my runes?
<ogasawara> bjf: sure, just in case.
<ogasawara> bjf: so I'll let you handle it tomorrow but I'll be on standby
<bjf> ogasawara: wfm, runes sent
<ogasawara> bjf: thanks
<apw> sconklin1, looks like we have an iwl5000 regression in your -updates kernel, see bug #796336, it appears very much that the patch 'iwlagn: Support new 5000 microcode' which we got from stable upstream is completely inappropriate without the new firmware loader support
<ubot2> Launchpad bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Triaged] https://launchpad.net/bugs/796336
<sconklin1> apw: thanks. I'm getting used to this, unfortunately. We have never had so many things broken from stable updates in as long as I can remember . . .
<apw> sconklin1, updates kernel for lucid
<sconklin1> yep, got it
<apw> well we've never tested so well either
<apw> so ... its hard to be sure how much is new and how much is normal
<sconklin1> fair point
<apw> be good if you could confirm that lucid cannot real those files ... i think not given the error and the code, so i think reverting that commit is appropriate and prolly report it to stable too
<apw> s/real/read
<sconklin1> I'll investigate
 * ogasawara back in 20
 * ppisati -> gym
 * jjohansen -> lunch
<sconklin> GrueMaster: I'm setting up the workflow tools to assign ARM testing to your new team. Should this happen for all of the following packages? linux-mvl-dove, linux-fsl-imx51, linux-ti-omap4
#ubuntu-kernel 2011-06-14
<jjohansen> back on later
<hypatia> hey folks, i'm trying to track down an acpi regression from maverick to natty.  i'm a bit clueless with the ubuntu kernel tree - if i clone the natty repo, will it have all the older maverick stuff too?
<twb> The upgrade from 2.6.32-31 to -32 (lucid, x86-64) broke my LXC subsystem.  Containers didn't start at all; IIRC lxc-start(8) failed to mkdir in /var/cgroups (which was mounted).
<twb> Before I wade through all the LP notes in the changelog.Debian, anybody know offhand what's going on?
<twb> Unfortunately I can't give you exact details because the machine in question is mission-critical and I already failed back over to -31 when the issue occured on Sunday.
<sconklin> twb: first I've heard of it but I would very much like for you to file a bug if you can. Especially if you can do it from a machine with the same hardware running that particular kernel
<twb> Looks like you disabling CONFIG_NET_NS completely breaks containers with different network ranges.  So, uh, good job.
<sconklin> Not exactly the way in which we like to overachieve
<twb> And it was done to fix a bloody FTPd.  I hate FTP (http://mywiki.wooledge.org/FtpMustDie).
<sconklin> twb: if you file bugs (and please do), then please also add the tag "regression-updates"
<twb> OK, I'm doing that now
<twb> What is the package name to report against?
<sconklin> thinking
<sconklin> file against linux (the kernel) Even if that's wrong it'll get the logs we need.
<sconklin> and post the bug number(s) here. I'll check back a little later, I'm in the middle of cooking dinner . . .
<twb> Will do
<twb> Am I allowed to set "importance critical" ?
<twb> Too late, I did
<twb> When malone emails me back, I'll cite the bug number
<twb> It hasn't emailed me yet :-///
<RAOF> You haven't set the âdon't email me for stuff that I doâ switch, have you? :)
<twb> AFAIK I haven't touched that setting
<twb> I have used the lp web UI long enough to tell it my GPG key, so I can use email like the Goddess intended
<lamont> update-initramfs: Generating /boot/initrd.img-2.6.32-32-server
<lamont> Running postinst hook script /usr/sbin/update-grub.
<lamont> Generating grub.cfg ...
<lamont> /usr/sbin/grub-probe: error: raid5rec is not loaded.
<lamont> User postinst hook script [/usr/sbin/update-grub] exited with value 1
<lamont> why does the kernel hate this VM so?
<twb> lamont: is the VM using md RAID?
<lamont> why yes, yes it is
<lamont> more to the point, halp how make better?
<twb> I have no idea.  I am so sick of grub that I use syslinux for my (md RAID1 /boot, md RAID5 LVM root) systems now.
<twb> Last time I used grub2 it didn't support auto-detecting (grub-probe) anything inside the md RAID segment at all, and I had to manually tell it which modules to compile into the MBR.  But that was around 2007.
<twb> There is also a #grub which might help
<lamont> cool
<lamont> thanks
<charlie-tca__> j04
<charlie-tca__> 11
<twb> sconklin, RAOF: FYI #launchpad are looking into malone boo-boo now.
<sconklin> twb: sweet, Cascading failures
<twb> I was going to tell you about an even better one, but I've repressed it and can't remember
<sconklin> twb: I have to knock off so I can be all fresh and rested and ready to play whack-a-mole with regressions tomorrow. please subscribe me to the bugs when you get them created, or email me the numbers. Or ping me tomorrow during the day central time.
<twb> What's your email address?
<twb> Thanks, I'll email you if I can't subscribe you directly.
<twb> Good night.
<sconklin> twb: in PM (although it's not a secret)
<sconklin> I actually probably signed that kernel that failed
<hypatia> sconklin: before you go, could you look up at my git question?
<sconklin> looking
<hypatia> thanks :D
<sconklin> hypatia: Hi! 
<hypatia> hiya!
<sconklin> so - good question
<sconklin> No
<hypatia> i've been bugging poor matt garrett about this for 2 weeks
<hypatia> and finally pinned it on a kernel regression
<hypatia> by which i mean "works in maverick, not natty"
<sconklin> We start each new series from whatever the upstream kernel is at the beginning of the cycle. So while it will have a lot of the same history, Maverick (in this case) will have had selective patches applied for fixes and from upstream stable, and so will differ from the new upstream
<sconklin> do you have an idea which file or subsystem it's in?
<sconklin> (I'm asking so I can steer you to the right git usage)
<hypatia> sconklin: it only boots with acpi=off
<hypatia> that's about all i've got :/
<sconklin> oh, that's pretty generic
<hypatia> hp laptop, insyde bios
<hypatia> same deal with hdd or ssd
<hypatia> 10.10 x86 and 64bit both boot fine with acpi on
<ohsix> url?
<sconklin> I hate to do this to both you and Colin, but cking is absolutely the most knowledgeable person on our team about this sort of thing
<hypatia> ohsix: for the laptop?
<ohsix> for whatever report on it, i've got some stuff with insyde around
<sconklin> and Colin has been working on a firmware test suite that smokes out a lot of BIOS issues
<hypatia> sconklin: no skin off my back, i'm happy to learn something new and help out if i can :)
<hypatia> ohsix: i'll ping you when i file an issue on it tomorrow
<hypatia> must do CS homework tonight, was just hoping to get some kernels building :)
<sconklin> hypatia: there's also a lot of interesting info on Colin's blog
<ohsix> have you done any bios updates recently? even if you haven't tried resetting the bios options to the default (fine if you make your changes over after that)
<sconklin> http://smackerelofopinion.blogspot.com/
<ohsix> it's fixed the weirdest stuff on mine; theres a binary option block that can be changed by all sorts of things you can't actually see with the bios setup, but the reset will still reset them all
<sconklin> ok, g'night, gotta fall over now.
<hypatia> ohsix: i am running the latest bios which is from jan 2011... but it's been modded to remove the pci-e whitelist for wifi cards
<hypatia> stupid hp consumer crap
<hypatia> ohsix: i'll give the resetting thing a try
<ohsix> you might start looking there since it's modified
 * hypatia nods
<hypatia> i can try reloading the old bios too, i have it somewhere
<ohsix> i don't like those whitelists either; but they do it for testing w/the fcc from what i understand
<hypatia> yeah, i kinda think it's bull - like how broadcom etc. used to refuse to make Free drivers on the grounds that they would be modifiable and thus allow the user to get around fcc approvals
<twb> sconklin: #796993
<hypatia> </rant>
<ohsix> broadcom is kind of special; they have a lot of customers and it's all proprietary stuff, any part of the drivers being opened for some products can compromise their market position too
<hypatia> and then my laptop died, because i have no acpi and i forgot i was unplugged
<hypatia> ;_;
<hypatia> ^^ motivation
<cdbs> Does the latest Oneiric kernel work well with the nvidia driver? It seems to not build when it encounters the version number 3.0.0
<ohsix> the version change is still percolating through just about everything that touched the kernel
<ohsix> aside from that i don't know :]
<cdbs> ohsix: so it should work well? It failed to build when I tried using the kernel from the mainline ppa 2 weeks ago
<ohsix> couldn't say; i don't use it, its probable that there are things other than the version number that are keeping it from being built, binary drivers are like that
 * cdbs takes a ball of garbage and throws it on the nVidia banner hanging on the neighbour's house
<twb> cdbs: ahaha, third-party FTL
<ohsix> you could try the nouveau driver :]
<twb> It's a pity Intel moved their GPUs from the motherboard to the CPU, because now I can't buy high-end servers with intel GPUs
<twb> (The on-CPU GPU is only available on low-end CPUs)
<cdbs> ohsix: Nouveau doesn't work with a new GPU released last month :@
<cdbs> the disadvantage of buying stuff that's too new
<cdbs> ohsix: btw, it built with the new kernel
<cdbs> in dkms, of course
<cdbs> but that's maybe because I'm using xorg-edgers?
<ohsix> maybe, it tends to get updates for new stuff pretty quick
<twb> ITYM the disadvantage of buying hw from a FOSS-hostile vendor
 * apw yawns
 * smb joins yawning
<bjf> smb, moin
<smb> bjf, Morning visitor
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<GrueMaster> sconklin: Yes, assign all linux-mvl-dove, linux-fsl-imx51, linux-ti-omap4 to me, or rather my new team, ubuntu-armel-qa.
<GrueMaster> thanks
<smb> bjf, Wow a very early early warning...
 * apw watches the load on people hit 30, i suspect its underpowered
 * smb tries to parse above sentence and fails...
<apw> people.c.c machine load
<smb> ahhh
<apw> long term load ave >15
<smb> Now it makes sense
<smb> I was just not prepared to look at people as the machine, but as people... :)
<amitk> doesn't pitti run scripts there?
<apw> everyone and his dog does, which is why its cying in the corner
<smb> apw, May I point you to another mail in my watch list? "Re: problems on CAN bitrate" This is about a config option that is apparently needed for that driver, which is not experimental, and still disabled in Oneiric.
<AnAnt> Hello, is there a utility (like PCITree for windows www.pcitree.de), that would allow me to set configuration registers of a PCI device ?
<AnAnt> pciutils !
<AnAnt> sorry for the noise
<bjf> apw, the flavours page has nothing for oneiric
<bjf> ogasawara: apw, bugs with two digit problems are tagged "kernel-3.0"
<apw> bjf awsome
<apw> ogasawara, about ?
<apw> ogasawara, i am thinking i'd push a config change and wanted to make sure you not rebasing atm
<apw> ogasawara, ok all done
<apw> smb, changed
<smb> apw, CAN_BITRATE?
<apw> smb, yep
<apw> smb, email in your inbox
<smb> apw, Cool thanks. Well hopefully through mailing list. :) They had been querying about earlier releases too, but as they lack any response they seem not have that problem urgently enough
<brendand> someone just raised a bug against 3.0.0 kernel, should it be Invalid?
<bjf> brendand, bug #?
<brendand> bjf - i was asking more in principle, but it's https://bugs.launchpad.net/ubuntu/+bug/797141
<ubot2> Ubuntu bug 797141 in ubuntu "Can't mount NFS shares under kernel 3.0.0" [Undecided,New]
<bjf> brendand, they are valid
<brendand> bjf - okay
<hypatia> hey folks, any advice on doing a bisect between maverick and natty kernels? i have them both checked out
<hypatia> the bug was introduced somewhere after Linux butler 2.6.37-020637rc2-generic #201011160905 SMP Tue Nov 16 09:08:47 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
<apw> hypatia, if the problem is exposed in the mainline builds as well i would use those to narrow it down
<hypatia> i'm bisecting from Ubuntu-2.6.36-0.1
<hypatia> compiling right now, woot
 * hypatia hasn't built a kernel in a dog's age
<apw> brendand, if you find any could you add kernel-3.0 as a tag please, so we can monitor them 
<brendand> apw - will do
<apw> hypatia, all the uploads we ever did are available in the launchpad librarian
<sconklin> hypatia: the reason apw is suggesting that is because the mainline builds have a more linear history, and are easier to bisect, or at least to narrow it down to two adjacent versions.
<apw> and because the all exist in one place
 * ogasawara back in 20
<cking_> apw, I've completely forgotten the rune to build a kernel .ddeb  - what is it again?
<hypatia> apw: oh nifty, thanks
<smb> cking_, I believe you look for fdr skipdbg=false <target>
<apw> you need to have full_build=true 
<apw> or skipdbg=false ...
<smb> oops, even more options... 
<cking_> ah - thanks, I used the latter last time and couldn't recall it today
<cking_> smb, more?
<smb> cking, I forgot/did not remember full_build
<cking> so many ways to skin a cat 
 * smb tried so say there are even more options to do the same
<sconklin> apw: do we have a wiki page describing lts backport kernels, why they exist, and how to apply them?
<apw> sconklin, i am not sure we have that ... let me looks
<hypatia> apw: any suggestions on how to use launchpad librarian? i've not used it before
<apw> hypatia, you can find all the versions ever here: https://launchpad.net/ubuntu/+source/linux/+publishinghistory
<hypatia> oh rock on
<hypatia> thanks!
<apw> click through for the binaries
<ogasawara> bjf: I'm only seeing one bug tagged kernel-3.0, does that match what you're seeing?
<hypatia> will have to wait til i get to school and off of spotty 3G
<bjf> ogasawara: yes, it was the first
<ogasawara> bjf: ok cool.  didn't know if you had some crazy script parsing logs to auto-tag in which I would expect to see more bugs
<bjf> ogasawara: finger script
<YoBoY> hi
<YoBoY> since I'm using 11.04 on my laptop, my computer freezes sometimes when it's going to the screensaver and when it's doing that, i can only reboot or restart gdm. Do you know how I can fix that ? it's really annoying to have to restart my computer each time i want to make a break :]
<abogani> YoBoY: Are you using one of the closed video drivers?
<YoBoY> abogani: no
<abogani> YoBoY: What video driver are you using?
<YoBoY> I have an intel chipset, I think it's the i915
<abogani> YoBoY: Ok try to disabling effects (at GDM login time on Session widget)
<bjf> ##
<bjf> ## Kernel team meeting today @ 17:00 UTC
<bjf> ##
<YoBoY> (my laptop have an hybrid graphic cards intel+nvidia, currently using the intel graphic card)
<YoBoY> abogani: starting with a classic desktop ?
<YoBoY> abogani: done... I have to wait now ^^"
<abogani> YoBoY: good luck
<bjf> ogasawara: i think the meeting is yours :-)
<ogasawara> bjf: ok cool
 * ogasawara stares at -rc3 build.log and wonders why PERF_VERSION is not getting set properly now
<apw> ogasawara, what is it getting set to
<apw> there were changes in -rc3 which changed that versioning
<apw> ie. how it propogates down
<apw> it was lone of the first commits puled in since the previous -rc
<ogasawara> apw: I flipped on some debugging, lemme pastebin
<ogasawara> apw: http://pastebin.ubuntu.com/626658/
<apw> ogasawara, so perf-version looks ok in your output doesn't it
<chadhogg> following a suggestion I got here yesterday, I am attempting to perform a kernel bisection to further debug bug 793437
<ubot2> Launchpad bug 793437 in linux "Unusable Slowness In 2.6.38-8" [Undecided,Confirmed] https://launchpad.net/bugs/793437
<apw> PERF-VERSION-FILE:2: *** missing separator.  Stop.
<apw> ogasawara, that is a Make error right ?
<ogasawara> apw: yep
<apw> is the branch pushed ?
<ogasawara> apw: not yet, lemme push
<apw> anywhere is fine
<chadhogg> I know that my bug is not present in the stock 2.6.35-28 kernel that is current in maverick, but I am having through figuring out how to turn that into a tag from which to perform bisection
<ogasawara> apw: git://kernel.ubuntu.com/ogasawara/ubuntu-oneiric.git master-next
<chadhogg> s/through/trouble/
<apw> ogasawara, oh i think i see whats broken there
<apw> ogasawara, its assuming its within the kernel tree to allow it to work out the kernel version ... 
<apw> which it isn't ... let me poke at it for a sec ?
<ogasawara> apw: sure
<apw> ogasawara, ok so i think for now revert this one: 5d61b9fd19d9f3cf653dbba615876e7792eea5ea
<apw> and see if that sorts you out for now, and i'll see what i can do to sort it out
<ogasawara> apw: ack, /me tests
<ogasawara> apw: cool, working now
<db260179> Has the discussions ended?
<db260179> Is the Power usage still an issue? Is it been looked into?
<pmatulis> a lucid uname gives me: 2.6.32-24-jump1.01   -   does it look familiar to someone?
<jjohansen> db260179: yes it is still an issue.  There has been a patch that reduces the problem but it isn't entirely solved yet
<smb> pmatulis, Looks like a self compiled kernel (you can place a lot there)
<db260179> jjohansen: Thanks for the reply. What is causing the issue?
<jjohansen> db260179: if we knew that for sure it we be fixed
<jjohansen> db260179: though it isn't just a single patch, it seems to be an interaction of at least 2 making it much harder to track down
<tseliot> apw: do you know what I can use instead of (un)lock_kernel using Linux 3.0?
<apw> tseliot, add a driver specific mutex
<tseliot> apw: the main problem is that I'm dealing with fglrx
<apw> tseliot, hee
<apw> tseliot, make lock/unlock take a my_bkl_replacement mutex ?
<apw> tseliot, and pray it only wants to exclude itself
<tseliot> apw: right, but I was wondering what the replacement could be
<apw> tseliot, there is nothing, its gone
<apw> eveyrthing was converted to driver specific mutexes
<tseliot> apw: oh, so are you suggesting that I point that to an empty function?
<apw> tseliot, no make a new 'global' mutext called 'ati_lock' and make lock/unlock_kernel take and release it and hope its enough
<ogasawara> ##
<ogasawara> ## Meeting starting now - #ubuntu-meeting
<ogasawara> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<ogasawara> ##
<apw> as in make local functions called that
<tseliot> apw: ok, thanks
<jjohansen> tseliot: if it isn't you could look at the most recent patches to remove the bkl, and try taking a subset of those locks
<tseliot> jjohansen: yes, I saw that some drivers now use lock_sock() but it won't work in my case. I'll keep looking
<jjohansen> tseliot: right, but there may be some other lock, or small set of locks that will
<tseliot> jjohansen: from a quick search I've noticed that other drivers are simply using mutex_unlock()
<jjohansen> ogasawara: patch review done, basically keep all the patches.  Though the AA patches are going to get an update, but that will happen when I finish up and get the pull request together.  I'll update the wi
<ogasawara> jjohansen: ack, thanks
<tseliot> apw, jjohansen: using a mutex seems to work here. I even got Unity to work :) . Thanks for your help
<jjohansen> tseliot: I'm not surprised it works at some level, its whether it has some odd failures when interacting with the console, suspend, etc, that are worrisome
<jjohansen> tseliot: none the less, its good to hear you are having success
<tseliot> jjohansen: yes, but it should be better than having no working driver at all (when there's no alternative) in oneiric
<jjohansen> tseliot: indeed :)
<tseliot> hopefully AMD will work on a proper fix soon
<jjohansen> yeah
<skaet> bjf, sconklin - can you paste me the link to the calendar you're using to track SRU spins?
<chadhogg> following advice from diwic, I've spent all day bisecting the ubuntu-natty kernel to debug 793437, and feel that I have accomplished extremely little
<chadhogg> (the last 6 revisions that I have tried all failed to build, for a variety of reasons)
<chadhogg> what is the likelihood that continuing with this is just a waste of my time?
#ubuntu-kernel 2011-06-15
<jjohansen> chadhogg: I wish I could tell you, usually if there is a known good point in the past and the problem is due to a single commit
<jjohansen> bisecting will find it
<jjohansen> there are of course build failures that can mess you up, and disheartening
<jjohansen> chadhogg: did you find any kernel to work for you on your bisect?
<chadhogg> there was only one that I was able to successfully build, and it exhibited my bug
<jjohansen> chadhogg: okay, what range did you do the bisect on?
<chadhogg> I couldn't figure out how to translate my working release into a tag, so I did the oldest commit in the log to the head
<jjohansen> chadhogg: you don't need to use a tag for git bisect
<chadhogg> the midpoint of those lacked a debian/rules file, so I marked it as "good", figuring I could come back and figure out the old build process if I found that my bug went back that far, but that this would be unlikely
<jjohansen> you can just give it the hash
<chadhogg> rephrase: I didn't know how to translate my working release into a hash
<jjohansen> chadhogg: so 2.6.35 succeeds and 2.6.36 fails
<chadhogg> yes
<chadhogg> wait, no
<chadhogg> err, yes
<chadhogg> and I mean it this time :)
<chadhogg> but the natty source tree has nothing tagged as being part of 2.6.35
<jjohansen> right
<jjohansen> bisecting our kernels can be a bit of a pain when it comes to crossing releases
<jjohansen> you see we rebase to upstream, and start fresh for each new release
<jjohansen> chadhogg: what is the hash of the last build failure you have
<chadhogg> 974ead458b4832b34ecd8fc71c28e25783683fbd
<chadhogg> specifically, due to a function signature mismatch on line 350 of security/yama/yama_lsm.c
<chadhogg> I should mention that I made the default selection for all configuration options
<jjohansen> right
<jjohansen> chadhogg: ugh, you didn't even get into the kernel proper
<chadhogg> what does that mean?
<jjohansen> chadhogg: hrmm, I would recommend you stop atm, I am about to duck out for abit but when I get back I'll set up a bisect, and build you a kernel to try
<chadhogg> thanks; I'll continue idling in here, though the easiest way to communicate might be through my launchpad bug
<jjohansen> chadhogg: I mean that you where really just in ubuntu patches that are on top of upstream kernel
<jjohansen> chadhogg: sure, when I get a kernel built I will drop a link for you to test in there
<chadhogg> well, my (perhaps unfounded) suspicion is that that is where the problem lies
<jjohansen> chadhogg: I highly doubt it but we will find out whether that is the case rather quickly
 * smb mornings
 * smb needs more coffee
 * ikepanhc needs some food
<jjohansen> gah, where did my night go?
<smoser> k
<smb> Down the drains it seems
<apw> smoser, you erm stayed up through it as normal ?
<apw> jjohansen, ^^ even
<jjohansen> apw: sadly yes, but /me hasn't even gotten through even half of what was planned for a few hours :/
<apw> jjohansen, that always happens, nothing is ever as simple as it seems
<apw> "lets just change the version number from 2.6.39 to 3.0, should be simple"
<jjohansen> apw: hehe, yeah
<smb> Well, changing it _was_ simple. Handle the fallout not so much
<apw> ogasawara, i am assuming that revert worked ok for you ?
<apw> ogasawara, though i think i have the right fix now
<ogasawara> apw: it did, feel free to drop it and push the proper fix over it
<ogasawara> apw: as I've pushed it to master-next
<apw> ogasawara, so you have, good stuff
<cking> apw, stupid question time: are kernel .ddebs automatically built, and if so, where can I get them?
<apw> cking, yes and from ddebs.ubuntu.com
<cking> thanks
<ogasawara> apw: once you push, I'll do a quick test and then plan to upload
<ogasawara> apw: I'm also away tomorrow and friday, can you handle the release meeting friday?  otherwise I'll send skaet our part to paste in
<apw> ogasawara, ok pushed try that
<ogasawara> apw: seems to be working, my kernel is still building at least
<apw> ogasawara, good stuff ... i've pushed it to linus as well
<ogasawara> nie
<ogasawara> nice even
 * ogasawara replaces her dev box which magically died overnight
<apw> ogasawara, ouch
<smoser> hi. anyone seen major memory issues with current kernel ?
<smoser> http://paste.ubuntu.com/627335/
<apw> smoser, what in there tells you you have memory issues ?
<smoser> i was mostly idle, basically desktop and firefox running, and using all 4G + 4G swap, nothing appeared to me to be using excessive memory
<apw> smoser, yet nothing is dieing with OOM ?
<smoser> apw, i was using 100% swap, and iotop showed kswapd running full bore, system was unusable.
<smoser> i'm not sure whether or not i had rebooted since yesterday, when the oom *did* kill some processes.
<smoser> the system was too unusable to get a dmesg even.
<apw> smoser, no not seen anything like that on the two machines i am regularly using it
<smoser> i literally could not log in with ssh or use one of the gnome terminals that was open.
<smoser> so... if I had not rebooted since yesterday, what I did yesterday that *did* cause massive issues was trying to do an install in kvm.
<apw> smoser, i guess we need /proc/slabinfo as its not in kernel processes
<apw> s/kernel/user
<smoser> i'll try the kvm install from yesterday and see if I go out to lunch again
<apw> /dev/sda6                               partition	7823616	977416	-1
<apw> swap stats on a machine up 7 days with that kernel 
<smoser> shoot. i realized that pastebin didn't have one line of free -m
<smoser> should have also had:
<smoser> Swap:         4000       4000          0
<smoser> (4000 available, 4000 used)
<smoser> but /proc/meminfo had that . so anyway, i'll see if i can't reproduce.
<cking> why is the ubuntu kernel gitweb so sloooooow?
<ppisati> cking: in the afternoon is always slow
<ppisati> cking: in the morning i find it snappier
<cking> the server is being hammered at the moment :-(
<apw> cking, the machine isn\t the biggest
<cking> it's a 386?
<apw> its a 2 cpuu amd64 i think
<cking> looks memory+CPU+I/O bound to me
<apw> cking, its a tiny machine
<cking> well, we've not up-scaled it compared to how much more we use it nowadays
<apw> yep
<cking> poor thing
<smb> right now, there seem to be a lot of git pack-objects going on...
<smoser> well, so far just running kvm the same way I did yesterday hasn't triggered anything bad.
<apw> smoser, hrm, not good
 * ogasawara back in 20
 * jjohansen steps away for a bit
<smb> apw, ogasawara FYI: Being bored (or weird or both) I had been running the qa-regression-test suite on 3.0.0-1 and got one failure. Not sure this is moot but the test runs "getpcaps 1" and expects ": =ep cap_setpcap-e" but only gets ": =ep". Same test works on Natty.
<ogasawara> smb: thanks, I'll try running it here to re-create and investigate
<smb> ogasawara, OK, cool. Let me know if it does not or whatever comes out of it.
<bjf> apw: you uploaded kexec-tools to the kernel ppa today?
<apw> bjf, yeah i wanted to get a powerpc build for it, feel free to just delete it finished or not
<apw> bjf, i've now uploaded it to the archive and said balls to it
<bjf> apw, that's a pretty od version string and it's busted my scripts (made me sad)
<apw> heh :)
<sconklin> apw, bjf: can we as a policy only use that PPA for stable team builds please?
<apw> sconklin, arn't you mean with your pretty toys
<sconklin> not nice of you to say that after having smashed those toys ;)
<sconklin> admittedly, they are somewhat fragile toys
<bjf> apw, is a ':' legal?
<apw> just delete the package 
<apw> 8: at the front, yes, its an epoch, and optional
<bjf> apw, thanks
<tumbleweed> much thanks for linux-lts-backport-natty. I just deployed some new lucid machines today that needed it
<sconklin> sforshee: do you have a machine affected by this bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142
<ubot2> Ubuntu bug 424142 in linux "Address Collision" [Medium,Fix committed]
<sforshee> sconklin, I don't, BenC was working with some machines that were affected and verified the fix in the test build
<sconklin> sforshee: ok, I spammed the bug again, maybe we'll get a response. Thanks
<sforshee> BenC, you probably want to verify the fix for bug #424142 in proposed or else sconklin is going to revert the patch
<ubot2> Launchpad bug 424142 in linux "Address Collision" [Medium,Fix committed] https://launchpad.net/bugs/424142
<sconklin> sconklin cracks his knuckles and fetches the repo . . .
<sconklin> seriously, we have a couple of days.
<sforshee> sconklin, fyi that patch is queued for .32-longterm as well
<sconklin> normally that would make me want to take it, but I'm still sore from the last round of longterm updates
<sforshee> that's understandable
 * jjohansen -> lunch
 * vanhoof reads a novel from jjohansen 
<jjohansen> vanhoof: haha sorry about that
 * jjohansen is trying to spread the pain around :)
<vanhoof> jjohansen: lol
<vanhoof> jjohansen: did you sleep last night? :)
<jjohansen> no
* ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - June-21 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jjohansen> sconklin: I have a bug where the fix has made it in to the stable tree, so it will be coming in through stable updates.  Do you want bug report tasks for this type of bug
<sconklin> jjohansen: if it matters to you then you better open a bug. I think we may declare a moratorium on taking upstream stable patches unless it's within 90 days of a release or SRUd. It needs discussion but opening a bug is the best way to make sure it gets included
<jjohansen> sconklin: okay thanks
#ubuntu-kernel 2011-06-16
<BenC> sconklin: I thought I had verified that patch already
<chadhogg> jjohansen: I was unable to boot with the kernel you built me; details on launchpad
<twb> Stupid question: why does lucid-backports have linux kernels up to .35, but e.g. "compat wireless" modules up to .38?
<twb> Oh, I see, it looks like it's the driver taken from the .38 tree and compiled against .32
<smb> morning
<apw> smb morning
<diwic> apw, before my vacation I traced down a bug in PulseAudio that could be a gcc bug. Do you know how to proceed with that?
<apw> diwic, normally one would file a bug against gcc, they will want the minimum code fragment that causes the miss-compile and a good description of how it is miss compiled
<apw> against gcc-4.5 or whatever i guess
<apw> how do we know it is a compiler problem ?
<twb> apw: problem goes away when you change the compiler
<apw> as unfortuanatly code which is relying on undefined side effects of some code forms can then change if you change the compiler
<jjohansen> twb: all other parts of the environment the same?
<apw> twb, one would really want to find the exact bit of code whihch is being miss built
<diwic> apw, is bug 789031 filed against the right package?
<ubot2> Launchpad bug 789031 in gcc-defaults "Built-in ASM constraint "rm" does not work" [Undecided,New] https://launchpad.net/bugs/789031
<twb> apw: granted
<apw> diwic now that even sounds familiar, i wonder if something in the kernel ht the same issue
<apw> diwic, i think i'd expect it to be gc-4.5 or gcc-4.6 depending on the version you are using
<diwic> apw, actually in pulseaudio the problem was worse, it allocated one "r" and one "rm" into the same register
<diwic> apw, but I couldn't get that done to a simple example
<apw> so i think other than i think you want to do the right version, it looks good.  i would poke doko so he is aware, he is likely to recognise it if its come by already as a fix
<diwic> ok
 * diwic pokes in ubuntu-devel
<akgraner> jjohansen, you around?  Was given your name for the person to contact for possible interview series?
<jjohansen> akgraner: hey, of course I am around, what are you doing up so late
<akgraner> jjohansen, late it's early here I'm about to start my day :-)
<jjohansen> akgraner: ouch that is early
<akgraner> nah just sleep decided to hid from me so I thought I would get some work done :-)
<jazz2> hi, I upgraded my server from 9.04 to 10.04 (via 9.10); the server is connected in my lan via wlan(wpa2); ...
<jazz2> the problem now is that the speed downloading from the server to the lan is down from ~700kb to ~100kb, while uploading to it is mostly not affected (~700kB). ...
<jazz2> I tried: 
<jazz2> a) using a wired lan connection->normal speed, 
<jazz2> b) booting with kernel 2.6.28-19-generic -> wlan speeds are back to normal 
<jazz2> c) booting with kernel 2.6.31-14-generic -> wlan speeds still degraded
<jazz2> question now is: what changed between the kernels and where do I start to fix this? any help would be highly appreciated
<erhart> has someone tried to run a natty kernel in lucid?
<ohsix> jazz2: what wifi chipset?
<erhart> intel wifilink 5100 agn
<jazz2> ohsix, where do I look for it
<jazz2> i think it's something like Realtek
<jazz2> ohsix, zd1211rw
<ppisati> cooloney: http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=commitdiff;h=fc58ea3748869d2fa811dff26aa0fa07490b22b2
<ppisati> cooloney: i can't find any branch where this patch has been applied
<ppisati> cooloney: is it in use at all?
 * smb -> lunch
 * ppisati out to get some food
<sconklin> smb: your comment in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/681083 - sorry I'm not up on all the virt stuff - does his test imply that the bug has been fixed in the XenMotion case, or only that the kernel doesn't fail in a major way?
<ubot2> Ubuntu bug 681083 in linux "Ubuntu Crashes/Freeze on XenMotion" [Medium,In progress]
<smb> sconklin, Whatever they exactly do in xenmotion I actually do not know. But one part is running generic kernels (-pae in i386) as domU guests.
<smb> So when he took that 2.6.35 kernel I provided and installed it into his Lucid guest, the Maverick kernel got tested
<smb> sconklin, Probably another argument could be that this patch is now added for the next 2.6.32 (may or may not get picked for .35 as well) longterm tree
<smb> So sooner or later it will come. But I heard you are slightly frustrated by longterm trees. :)
<sconklin> BenC: I see your test results in the bug - It's that the SRU process requires that someone actually test the kernel in -proposed, and it looks like you tested a test build to validate the patch.
<BenC> sconklin: Ok, I'll test the actual build
<sconklin> thanks, much appreciated
<flipside> hello
<BenC> sconklin: Ok, confirmed...where do I add my two-cents?
<sconklin> add a comment and I'll set the tag. Thanks!
 * BenC has forgotten the bug report
<sconklin> stand by
<BenC> Found it in scrollback
<apw> apw ...
<apw> apw_ ?
<bjf> apw ??
 * smb wonders whether apw exploded...
<apw> smb, trying out a new irc client was all
<smb> apw, Ah. :)
 * smb -> eod
<jjohansen> apw: tangerine seems to be hanging on builds (not just in schroots), who do we hit up to look into it
<apw> jjohansen, whats the symptoms
<apw> cnd what you doing to tangerine?
<sforshee> apw, fakeroot is hanging in the kernel trying to get some semaphore
<jjohansen> apw: it just hangs, sforshee reported and I duplicated
<apw> sforshee, anything specific, which sema ?
<sforshee> apw, not sure
<apw> i can bounce it if thats useful
<sforshee> you'll see a bunch of faked-sysv processes in uninterruptible sleep
<sforshee> /proc/<pid>/wchan shows call_rwsem_down_write_failed
<sforshee> apw, yeah it prolly needs to be bounced when cnd is done
<apw> ok well let me know when he is done, if he can be anythiong other than done
<apw> sforshee, given its actual makes which are spinning, i'd say he is not making progress
<apw> yeah they are dead i recon
<apw> sforshee, i don;'t think cnd is making progress
<apw> votes for bouncing ??
<apw> jjohansen, sforshee ^^
<jjohansen> +1
<sforshee> +1
<apw> in progress
<sforshee> bjf, could you accept my natty nomination on bug #767192 ?
<ubot2> Launchpad bug 767192 in linux "Wireless flaky on Acer Aspire 5100 after installing Natty" [Medium,In progress] https://launchpad.net/bugs/767192
<sforshee> thanks apw
<sforshee> anyone around that can accept my natty nomination on bug #767192 ?
<ubot2> Launchpad bug 767192 in linux "Wireless flaky on Acer Aspire 5100 after installing Natty" [Medium,Fix released] https://launchpad.net/bugs/767192
<Specialist> Hi there, are there any plans to publish a kernel update for natty based on a recent -stable (> 2.6.38.6) kernel version?
<Specialist> I am asking because I am affected by bug #746860, which has already been fixed upstream
<ubot2> Launchpad bug 746860 in linux "System sporadically freezes during suspend to RAM" [Undecided,Confirmed] https://launchpad.net/bugs/746860
<sconklin> Specialist: the natty kernel currently in -proposed is current thru 2.6.38.8 but has two known regressions that we will have to resolve before we can fix it and spin another release
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/792013 is the tracking bug for that, and has other bugs linked from there for the regressions
<ubot2> Ubuntu bug 792013 in linux "[Regression] linux: 2.6.38-10.44 -proposed tracker" [Medium,In progress]
<Specialist> sconklin: thanks! i'll see whether those affect me and will probably just take the kernel from -proposed if they don't
<sconklin> Specialist: if either of them affect you in a way you can reproduce, we could use help bisecting kernels to locate the problem. I think our main reporter is gone until Monday . . .
<vanhoof> sconklin: ah cool, I didn't know -10 in -proposed carried all the way through 2.6.38.8
<sconklin> Specialist: sorry, I got that wrong. The release in -proposed has up through 2.6.38.7
 * vanhoof has a few bugs that will get closed out then :)
<vanhoof> ah rats :D
<sconklin> we've temporarily stopped taking upstream updates because of the load of regressions we got in the last batch
<sconklin> vanhoof: anything you really care about, open an SRU bug even though it's in a stable update, and get it on the kernel list for acks.
<Specialist> sconklin: np, as long as it's > .6, it's fine ;-) i'll let you know if i see anything unusual comparable to the two regressions with the -proposed version
<Specialist> sconklin: is the bisect progress documented somewhere?
<sconklin> vanhoof: sorry to push things into that path, but we're trying not to take another multi-week train wreck
<sconklin> Specialist: hold in - herton has been doing those ^^
<vanhoof> sconklin: well .8 will make its way in at some point
<herton> Specialist: for bug 793796, the bisect progress is on last comment on bug report
<ubot2> Launchpad bug 793796 in linux "2.6.38-10 panic after ejecting drive" [Undecided,Confirmed] https://launchpad.net/bugs/793796
<herton> it's waiting for the reporter to test the next step
<herton> the other one (bug 794096) is on a bisect also with the reporter, he will only be able to test next bisect next week...
<ubot2> Launchpad bug 794096 in linux "SMTP and posting to a web-form time out (probably due to netfilter changes)" [Undecided,In progress] https://launchpad.net/bugs/794096
<herton> this last one is weird, as reporter already tested with the most likely changes which could cause the issue reverted
<herton> and there isn't much info yet which could point to real issue
<herton> I tried to reproduce both here but without success, so if there is anyone else being able to reproduce the same and able to help would be great
<Kano> hi, which config option is the problematic one that now a newer module-init-tools is required
<Kano> rc2 worked fine with lenny, rc3 does not
<Kano> but even with squeeze 3.0rc3 works,so you do not need that extreme depend
<Kano> i lower it in my install scripts anyway
<Kano> this just takes useless time
<apw> Kano, its there becase we need it in the oneiric tree where the versions are correctly specified, and its getting copied to the mainline builds.  i'll fix it when i have time
<apw> as you have noted you can actually fix it yourself as you make your own packages
<Kano> no i use dpkg-deb
<Kano> http://kanotix.com/files/fix/mainline/install-daily.sh
<Kano> take a look
#ubuntu-kernel 2011-06-17
<Kano> but i dont get why newer kernels instantly crash with lenny
<Kano> i do not compile anything,but atoms need really long to recompress
<jjohansen> back on later
<Logan_> Anybody here good with XHCI issues?  There's a bug that has "Fix released," but I find that I still need to use a workaround to fix suspending on my USB 3.0 laptop.
<jjohansen> Logan_: update the bug with the information
<smb> morning
<apw> smb, moin
<smb> apw, Got past the signals?
<apw> smb, yeah about 20 mins sitting on the rail for nothing while they counted trains
 * smb hopes "sitting on the rail" is different from "sitting on the rails"
<smb> But yeah, some are very "secure"
<smb> One here lets you wait quite long before anything happens. Then with another of those you got 5s between the barrier being down and the train being there.
<apw> heh me too
 * ppisati -> out for food
<cking> download .ddebs -> need a faster pipe
<ppisati> apw: btw, i tested the image used by Michael and it's working ok on my panda
<ppisati> apw: so, faulty hw or a new hw revision
<apw> ppisati, the oneiric one you mean ?
<ppisati> apw: uhm... no, it was a natty iirc
<ppisati> apw: but natty and oneiric omap4-wise are the same
<apw> ppisati, well actually no at the moment oniric is behind natty (which it shouldn't be) ... i am looking at fixing that right now
<ppisati> ah ok
<apw> ppisati, yeah i am just testing a setup for it like mvl-dove 
<apw> tgardner, so we are starting to get excessive skew between natty and oneiric ti-ompa4.  as officially oneiric should be updated before we can SRU, but also becuase we know we are getting an update for Oneiric "shortly" i am proposing we do a mvl-dove style forward port to oneiric.   as an experiment i am looking to do it the same way we do fro the lucid bacports, ie with oneirici1 (no ~) on the end of the version
<apw> tgardner, this is starting to skew testing in oneiric it seems
<tgardner> apw, TI has promised to come up with a 2.6.39 kernel. we ought to ask Bryan where that is before we put too much effort into it.
<cking> apw, ping
<apw> tgardner, from waht i can tell, its a ways away, i think we can do this for very little effort, ie effectivly pass it to stable to handle -- once i have this tested.  so far i've spent just 10 mins on setting up an update-from-xxx style tree for it
<apw> and its looking like it works ok
<tgardner> apw, ok, but does it run on the HW ?
<apw> ppisati, any idea how far out the .39 kernel is for ti ?
<smoser> smb, https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/614853 . user reporting that they're still seeing that issue with a kernel that should have been fixed
<ubot2> Ubuntu bug 614853 in linux-ec2 "kernel panic divide error: 0000 [#1] SMP" [Medium,Fix released]
<apw> tgardner, well that is part of the issue, there are compiler issues in the mix here, and unless we're building in the right series the testing is actually useless
<tgardner> apw, well, yhou can build in the c-k-t PPA as a test
<apw> tgardner, if the priinciple seems sound to you, then yes that is cirtainly the sensible next test step
<ppisati> apw: that was yesterday topic and the answer is... unknown
<tgardner> apw, if its not too much work then I'm fine with it
<ppisati> apw: well, actually linaro has already a .39 kernel
<apw> ppisati, your feel?  still at least weeks out ?
<cking> apw, want to book those flights before matt closes for business?
<apw> cking, yeah if there is a generall arival that saturday before then i guess so
<tgardner> cking, apw: plumbers ?
<cking> I will book mine and CC you and ask matt to book yours too
<cking> tgardner, yep
<cking> and pre-kernel sprint too
<apw> tgardner, yeah kernel sprint ... what he said
<tgardner> cking, ah, I have not encountered tha in my email yet
<apw> tgardner, you can practically walk there :)
<smb> smoser, Hm, both patches should be in that kernel. Need to check whether it is the exact same place
<cking> dude, you need to keep up with your inbox  :-)
<ppisati> apw: we won't get it for A2 unfortunately (end of month)
<tgardner> apw, its a surprising pain in the ass for me to get there
<smoser> smb, i'm commenting. 
<tgardner> cking, 6 days off produced over 700 emails. blech
<ppisati> apw: jcrigby has a .39 linaro kernel
<apw> ppisati, blimey ... 
<ppisati> apw: but that doesn't even boot on my board
<apw> ppisati, and that is no good for our use ?
<apw> BAH
<ppisati> apw: actually i would like to get t ASAP
<cking> tgardner, that's why I loathe taking a vacation ;-)
 * apw goes away to VENT about how useless that makes the linaro kernel
<tgardner> cking, I usually keep up while traveling, but wilderness rafting doesn't really lend itself to electronic communications.
<smoser> smoser, commented. i think its user error, or at very least there is user error involved
 * cking nods
<smb> smoser, Wait... that trace is from -312 and the patch went into -313
<smb> smoser, Ok, saw you commented the same...
<sforshee> tgardner, could you accept my natty nomination on bug #767192 ?
<ubot2> Launchpad bug 767192 in linux "Wireless flaky on Acer Aspire 5100 after installing Natty" [Medium,Fix released] https://launchpad.net/bugs/767192
<tgardner> sforshee, done
<ppisati> nuntio vobis gaudium magnun: it _seems_ we are going to get 3.0 for oneiric/ti-omap4 too
<ppisati> but no ETA yet
<sconklin> smb: Your email about the xenmotion and patch, is that a recommendation to publish it or to not publish it? 
<smb> sconklin, To publish. Actually there has been one verification by now
<sconklin> or rather to verify or not to verify, upon which publishing will be decided
<sconklin> ok, thanks!
<sconklin> I'll nudge that along
<smb> Cool thanks
<smoser> smb, do you have thoughts on bug 784937 ? I'd rather have hte kernel "fixed" than work around it.
<ubot2> Launchpad bug 784937 in cloud-init "/mnt not mounted, swap not used, disk is xvde" [Medium,Confirmed] https://launchpad.net/bugs/784937
<smb> smoser, The only thought currently is that I had not thought much about that one...
 * smb looks
<smoser> verified its still in Ubuntu 3.0-0.1-virtual 3.0.0-rc2
<smb> smoser, Could this be something related to that unplug unnecessary thing? That it does not give you sda because it would be the same as xvda...
<smb> And the other thing would be, why directly specifying devices, and not uuid or label?
<smoser> i dont know. i suppose it could be.
<smoser> well, 2 things lead me to care about a name
<smoser> a.) xen is stupid, amazon followed xen's lead, and they allow a user to specify "--device" when they attach a volume.
<smoser>   the expectation is that that device, will then be what appears in the guest
<smoser> b.) in this init case (trying to mount swap), cloud-init is reading the metadata service for "swap", which says "sda2".  It then translates that to xvda2 if there is no sda2.
<smoser> but i'd like to avoid more hacks and translations
<smb> Ok, I can understand that. Hm, at least the start it odd at first glance... But need to read a bit more details...
 * apw calls its a day ... have a good weekend all
<smb> apw, same thing
<highvoltage> howdy, is there a kernel parameter I could use to disable scsi emulation for usb mass storage devices?
<jjohansen> sconklin: could you accept nomination for Bug#798860 and Bug#789409
<sconklin> jjohansen: sure, stand by
<highvoltage> (I have a sd card reader that shows up as sda on some laptops and it's messing with my d-i mojo since it's preseeded to install to sda)
<sconklin> #798860 #789409
<jjohansen> sconklin: thanks, you can ignore the accidental oneiric tick, sadly I can't delete nomination mistakes
<sconklin> got the first one, there is no 789409
<jjohansen> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/789409
<ubot2> jjohansen: Error: <Bugtracker.plugin.Launchpad instance at 0x8d65a2c> bug 789409 not found
<sconklin> doesn't look good
<jjohansen> sconklin: there really is, I am looking at it the browser
<charlie-tca> Is it private?
<jjohansen> ah yes, but its not supposed to be
<jjohansen> sconklin: try now
<vish> hi, while building the kernel deb, i get a lot of questions (y/n) or (M/n)  â¦ is it OK if I choose 'y' for all and 'M' when y is not available?
<sconklin> jjohansen: all done, I went ahead and declined the Oneiric one so it wouldn't be hanging
<jjohansen> vish: maybe, its usually safe to choose the default
<jjohansen> sconklin: thanks
<jjohansen> vish: if you just hit enter you get the default
<vish> jjohansen: how do i know which is default? 
<vish> jjohansen: ah ok.. :)
<jjohansen> vish: it will be the one that is capitalized
<vish> thx..
<jjohansen> highvoltage: none that I know of
<vish> k..
<highvoltage> jjohansen: ok thanks
<sforshee> tgardner, for the rt2800 firmware updates I started on last week, I discovered that hardy lbm does not include the drivers. Are we no longer updating compat-wireless in hardy? Because if not there's no point in adding the firmware.
<tgardner> sforshee, I don't think I ever bothered with Hardy compat-wireless. Lucid shold be sufficient;y old enough for CW backports
<sforshee> tgardner, ack. I'll send out the pull requests for lucid and maverick shortly.
<tgardner> sconklin, do we have a test victim for the USB 3.0 regression? it should be fixed in 2.6.38.8, right?
<sconklin> tgardner: I can't remember, but I think there may still be another patch required after .8. I haven't worried about it because we just reverted it all. We'll circle back after we get these releases out.
<sconklin> tgardner: the last time I checked was a week or so ago and one of the fix patches wasn't even in Linus's tree yet
<tgardner> sconklin, ok, I'll roll a 2.6.38.8 without the xhci patches
<vish> check-config: FAIL: value CONFIG_SECURITY_YAMA y
<vish> check-config: FAIL: value CONFIG_DEFAULT_SECURITY_APPARMOR y
<vish> check-config: 26/28 checks passed -- exit 1
<vish> make: *** [config-prepare-check-generic] Error 1
<vish> while building i get that^ error; how do i fix that? 
<vish> building kernel*
<vish> i could probably comment it out of /config/enforce , but Apparmor is required for security right?
<jjohansen> vish: define required.  It is required for apparmor make, but you still have unix DAC without it
<jjohansen> vish: what kernel are you building?  I assume upstream?
<vish> jjohansen: required as in; "if i dont have it, bad men will take control of my system" :D
<vish> jjohansen: maverick, trying to bisect between .35 and .34
<jjohansen> vish: ah, if you are bisecting and debugging I wouldn't worry about yama, or apparmor, they are added near the end of the stack of commits so they will disappear
<vish> jjohansen: ok, cool, thanks.. will comment it out.. (the problem started between those kernel and persists even in .39 , so trying to figure out the commit)
<jjohansen> vish: you can build without those by putting skipconfig=true on the command line
<jjohansen>  eg.  skipconfig=true fakeroot debian/rules binary
<vish> oh, k. will do that for the next build.. i just commented it out and its building \o/
<jjohansen> you may also need skipmodule=true skipabi=true
 * vish makes note
<jjohansen> vish there are also files you can touch/modify to get the same effect but if you aren't building a ppa, just putting those on the command line is good enough
<vish> jjohansen: nah, not in ppa, just local build
<vish> lp hates me atm, i dput the upload and it stops at the last 1 kb and just gets stuck forever, did that like 5 times already o.0
<jjohansen> vish: sadly that happens to more than just you
<jjohansen> or maybe not so sadly, depending on your pov.  ie. lp hates more than just you :)
<vish> lol!!
<CarlFK> natty loaded snd-hda-intel - todays oneiric 3.0-1 does not, so no sound.  
<CarlFK> should I report this somewhere?
#ubuntu-kernel 2011-06-18
<bryce> CarlFK, ubuntu-bug linux perhaps?
<CarlFK> ok
#ubuntu-kernel 2011-06-19
<bullgard4> [Natty 64-bit] My new computer shows after 1 week for the 1st time: "panic occurred, switching back to text console". It shows a detailed error report of 64 lines in a virtual console.  To report meaningfully to Launchpad, do I have to copy all 64 lines by hand, or will I find them in a log on hdd after restart?
#ubuntu-kernel 2012-06-11
<BenC> ogasawara: I have the powerpc-e500mc flavor done and ready to pull, I'm just waiting for the full powerpc build to finish to make sure the entire powerpc arch builds
<BenC> ogasawara: when do you expect the next upload to quantal with the rebase in it?
<ashwini> I am trying to convert a sample application into kernel module, any equivalent of Posix message queues (mq_send, mq_recv) ?
<ashwini> I am trying to convert a sample application into kernel module, any equivalent of Posix message queues (mq_send, mq_recv) ?
<ppisati> moin
<smb> morning
<smb> apw, https://bugs.launchpad.net/bugs/657901
<ubot2> Launchpad bug 657901 in linux "linux-virtual depends on wireless-crda and contains wireless modules" [Wishlist,Triaged]
<smb> Wondering whether now the main package could not depend on crda and the extra modules could
<apw> cirtainly can if that is where they are
<apw> smb, ^^
<smb> apw, yeah, need to check though not clear it is 
<smb> Would it have effect on the installer? Though I guess the way it gets modules is still udebs and those would be independent in packaging
<apw> right, and the live installer installs both packages, so we could split them out any way we wish
<apw> indeed the splitting system has been fixed up so it can have as many splits as we require
<smb> apw, That would be for quantal. For precise maybe similar, though then for the real virtual package. Not sure this is not already that way (need to download some pakcages to look)
<apw> smb, that bug is confusigly old and new at the same time, we may have fixed it for a few releases then reintroduced it
<smb> apw, I am not sure we ever really fixed it completely
<smb> I assume the dependency to crda was always with the linux-image package, even with the wireless modules possibly already being in -extra
<apw> that is entirly possible indeed
<apw> if you have the inclination to investigate then great, otherwise perhaps make a WI on flavours blueprint to investigate for a2
<ppisati> remote root access to mysql: ouch
<ppisati> brb
<cooloney> smb and apw: for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1008400
<ubot2> Launchpad bug 1008400 in linux "Ubuntu server uses CFQ scheduler instead of deadline" [Medium,Confirmed]
<cooloney> i don't think we need to change on our kernel side, it'd better to ping server team to add a kernel parameters in server image
<apw> smb, i am starting to wonder if cfq has any place ... i wonder if we should be using deadline in the desktop too
<smb> cooloney, That sounds reasonable to me. I only saw you discuss this on irc in my backlog and had not remembered the bug reference. But I assume what they refer to is process stuck messages.
<apw> cking, i wonder if there is some way we can quantify whether moving to deadline by default for desktop would be any impact
<apw> cking, as likely it is the trigger for responsivness going to crap when writing to USB sticks sort of thing
<smb> apw, Is that not used to prevent one big produces to hog all the processing power
<cking> apw, depends on the use-cases too
<apw> smb, which used for that 
 * smb tries to remember whether he did see some upstream discussion about it
<apw> cking, indeed, musing as to whether given we know cfq is a bit crap at times for desktop as well, whether deadline is a more sensible default
<cking> apw, it depends on HDD or SSD too, but I can rig up some tests to explore this if you so desire
<apw> cooloney, i am unsure if it even has to be a kernel paramter, this may be something that can be sysctld
<smb> apw, the boot parameter
<apw> cking, i'd be interested if you can think of any valid ways to test desktop side
<smb> apw, After that I believe it is per queue
<apw> smb, ?
<smb> apw, You can change the io scheduler on the kernel command line for all queues
<cooloney> apw: yeah, there are several method to change that, but boot parameter is the easiest why i think
<cooloney> apw: but, if we can change desktop to deadline as well as server, that's a good fix. but need some testing.
<cking> normally I just tweak this per drive rather than globally
<smb> apw, elevator=x
<cooloney> cking: exactly, we can change that via /sys
<apw> they never like changing things on the kernel command line, its never a preferred solution is all i am saying
 * ppisati -> goes looking for carbo
<cking> apw, the choice of CFQ vs Deadline may also depend on the file system choice too - just to make life more complex
<apw> cking, so when you are tweaking what are you tweaking for
<smb> apw, I wonder whether in some situations cfq just shows the problem more heavily. Like what the usb-creator does. Pukes out a fs copy and then queues up writing the boot sector, which I believe tries to unmount and that is sensibly stuck until the fs copy is done.
<smb> Still you get a lot of those "process x stuck for more than 120s"
<apw> smb, yes thats fine, but the effect on other users is what i care about
<apw> i don't care if its the umount which trips that error
<cking> smb, which highlights the question: what kind of scenarios are we worried about
<apw> the issue as reported here is other vms lose their disks due to virtual IO timeouts
<apw> i dont' care about the producer making himself sick
<apw> i care about the producer making the other consumers sick
<apw> which for desktop is 'my shit goes grey and unresponsive' and for server is 'omg where did my VM root disk go'
<smb> apw, Right but that just may be the same thing (or similar). Lacking all the info from the bug I don't know whether their images is files backed
<apw> cking, now in both cases the unrelated producer/consumer latency is probabally the concern
<apw> smb, i am sure it is file based, and here they are hammering the filesystem from the host for a backup
<apw> which really shouldn't kill the VM 
<apw> but neither should my other windoers grey out
<apw> (and they do)
<smb> Yeah, I guess in that case deadline makes sure a write is not done later that a certain time. One would think cfq should do similar but apparently not :/
<apw> it cirtainly has an odd definition of fair
<cking> me thinks the Andrew Morton Interactive Workload (AMIW) is a good test. http://kerneltrap.org/node/431
<smb> Agreed, you would think fair should mean every process gets at least some slot to do writes. The problem likely is as well that the virtual disks maybe have no way of saying "yes I got your request but I am kind of under water right now, just be patient for a bit"
<smb> apw, You probably can get into quite a bit of trouble if you have your disks on something like iscsi or so
<cooloney> cking: yeah, i also saw this AMIW testing.
<smb> cking, In general what you need is multiple tasks that do independent heavy IO
<cking> smb, yep
 * cking can't find any serious analysis of CFQ vs Deadline
<cooloney> cking: me either, but for Redhat server and SuSe server, looks like CFQ is still the default IO scheduler
<cking> yep
<cooloney> cking: how about this one http://www.redhat.com/magazine/008jun05/features/schedulers/
<cooloney> cking: http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012&num=1
<gema> cking: 
<gema> ups, sorry
<smb> apw, cking So I am currently running a kvm-vm with 2G memory doing a loop creating an erasing a 4G file on its virtual disk(ext4) which is backed by a file on ext4 to which the host rsyncs 17G of files and I see no stall messages up to now (guest at about 50M/s, host at about 80M/s).
<apw> smb, and which elevator is the host using
<smb>  apw cfq
<apw> smb, well i guess that is 'good'
<apw> though it makes reproing the bug hard
<cking> perhaps mixing a bunch of other I/O activity may force it
<smb> apw, Yeah, we should ask the bug reporter for a more detailed description of what is setup how and what is done
<apw> smb, i would suggest creating a lot of small files in the guest, to get it to push those 'gatey things' down
 * apw struggles for the word today
<smb> Hm, the request size?
<apw> s/gatey things/barrier/
<apw> make it use barrier writes for its journal
<apw> which should make it block itself waiting
<apw> for the IO to complete
<smb> Depends which parts do actually support barrier requests. The fs is on a lv on a vg which is on a dm-raid5
<apw> i would expect barriers to be supported mostly
<smb> apw, dm used to be by large just a request mapper which makes doing quarantees on barrier requests hard if requests can end up on multiple disks downwards the stack
<apw> smb, all true
<apw> but the VM doesn't know that
<apw> so it will think the right way, blocking itself
<smb> apw, Would be what the virtio driver claims to support. So I see no barriers disabled messages (neiter host nor guest) which would mean they somehow support them or upstream got rid of the message...
<apw> smb, yeah i know dm can when it has simple mappings, so perhaps it can
<smb> apw, For simple ones (linear) it is no problem. I am wondering about the dmraid(dm-raid45) one. Theoretically and barrier would need to get converted into a write+flushes on all disks in the array. Now there could be either support, or ignorance and incorrectly ignoring that bit, or the message being hidden now... 
<dileks> apw: did you rebase overlayfs.v13 against v3.5-rc2?
<apw> dileks, i'd be waiting on leann doing the base rebase
<ogasawara> apw: just fyi, I pushed the rebase this weekend
<apw> ogasawara, ahh cool.  did overlayfs build ?
<dileks> there is a 3.5-rc2-quantal kernel. did someone test the union-fs part?
<ogasawara> apw: it did
<ogasawara> apw: I think there was 1 minor fixup for it during the rebase
<apw> dileks, probabally not yet, its very early to dare running it :)
<dileks> 1st patch with path stuff
<apw> dileks, but i'll get it building
<apw> (as in get a build going so i can test it)
<dileks> I was hoping you offer a GIT branch in your overlayfs kernel URL
<dileks> especially for 3.5-rcX
<ogasawara> apw: I've got it running here on 2 systems and seems to be holding up to very light use
<apw> ogasawara, cool ...
<apw> dileks, i may well do that
<apw> dileks, given the normal delays
<dileks> IIRC there is some atomic vfs stuff pending changing the do_dentry stuff, not sure if this is 3.5 material from al viro
<cking> apw, I'm spinning the HDD on a dev box here for Deadline vs CFQ across a bunch of file systems - will take a few hours to finish
<apw> cking, thanks
<apw> cking, you did 'testing thursday' on the alpha i think
<cking> yep I did
<apw> did it seem to take a real long time after finishing the install saying "installing system" before completing ?
<dileks> apw: BTW, can you activate codel/fq_codel for 3.5? doing some initial bufferbloat testing with kamal
<apw> dileks, whats the config for that
<cking> apw, not from what I observed on a X220i
<apw> cking, perhaps i have just become impatient
<dileks> http://kernel.ubuntu.com/git?p=kamal/ubuntu-quantal.git;a=commitdiff;h=d684fa3d61223a3d8ad4622c91497f520dc1c43b
<cking> and I did 3 installs, so I would have noticed
<dileks> CONFIG_NET_SCH_CODEL=m
<dileks> CONFIG_NET_SCH_FQ_CODEL=m
<dileks> apw: ^^
<apw> ogasawara, ^^ :)
 * ogasawara looks
<cking> apw, i'll repeat the tests with a SSD later tonight once the thorough testing is completed on the HDD
<ogasawara> dileks: both look to be =m already
<ogasawara> dileks: /ubuntu-quantal/debian.master/config$ grep -rn "NET_SCH_CODEL" *
<ogasawara> config.common.ubuntu:3638:CONFIG_NET_SCH_CODEL=m
<caribou> apw: ping
<ogasawara> ubuntu-quantal/debian.master/config$ grep -rn "NET_SCH_FQ_CODEL" *
<ogasawara> config.common.ubuntu:3642:CONFIG_NET_SCH_FQ_CODEL=m
<dileks> ogasawara: ah, I see. good to know
<apw> caribou, pong
<dileks> BTW, the quantal-3.5-rc2 kernel panics here
<caribou> howdy, can I come & bug you for a minute ?
<dileks> missing some important iwlwifi patches from wireless.git#master
<apw> caribou, ask away
<caribou> apw: remember the ddeb's you built for Natty's 2.6.38-8 kernel a  while ago ?
<apw> yep
<caribou> apw: how hard would it be to rebuild them with the exact same name as the original ?
<caribou> apw: I'm getting "ERROR: Build-id mismatch: "kernel" vs. "vmlinux-2.6.38-8-server" with SystemTap.
<caribou> apw: I think it's coming from the build name of your ddeb
<apw> caribou, not hard i don't think ...
<apw> caribou, one would need care to not mix them up with the real ones
<caribou> apw: well, the real ones are gone now anyway (the ddebs)
<apw> well indeed, but to not let peopel think they are the originals
<caribou> apw: ah, ok
<apw> though i assume it uses the unpacked stuff and we can hand mod the .ddeb filenames
<caribou> apw: yep, I guess
<caribou> apw: hold on a minute, I might be onto something. biab
<caribou> apw: nervermind, I thought I had found a bug but it was for an old version
<apw> caribou, i find it odd it would call my version 'kernel' i'd expect it to be complaining about a longer name similar to the missmatch version with dates on the end
<caribou> apw: same here.
<caribou> apw: well, if you have a minute to build them, please do so so I can rule out this, I'll continue to  hack at it in the meantime
<apw> caribou, yep, i'll get the builder on the case
<caribou> apw: looks like a known issue : https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/996364
<ubot2> Launchpad bug 996364 in systemtap "systemtap reports error 'Build-id mismatch'" [Undecided,New]
<apw> caribou, quality
<caribou> apw: in the bug's case, it seems like it was indeed an version mismatch. I just ran the script on my box and it does indeed report the version with the long suffix
<apw> ok so you care about it, and the error is printing the wrong text ??
<caribou> apw: yes, I'll need the new ddebs as the script report the version with your suffix
<caribou> apw: fyi, I must step out. back later
<apw> caribou, they take a while to make cause they are so big ... so i'll leave it building 'em
<dileks> ogasawara: 3.5: FB_VESA is now bool, setting =m results is =n and FB_BOOT_VESA_SUPPORT=n
<dileks> $ grep VESA /boot/config-3.5.0-030500rc2-generic 
<dileks> # CONFIG_FB_BOOT_VESA_SUPPORT is not set
<dileks> CONFIG_FB_UVESA=m
<dileks> # CONFIG_FB_VESA is not set
<dileks> dunno if its intended
<ogasawara> dileks: we carry a SAUCE patch to make that modular, and actually have a check in our config enforcer for it
<dileks> thats overriding kbuild-system?
<ogasawara> dileks: so that likely explains the discrepancy between the mainline build
 * ogasawara back in 20
<caribou> apw: no worry, I won't use them before end of day. I'll ping you tomorrow. thanks a lot
 * ppisati -> gym
 * jsalisbury is seeing allot of Launchpad timeouts today :-(
<jsalisbury> infinity, I'm not sure we have a ppc chroot setup on tangerine for bug 1005699
<ubot2> Launchpad bug 1005699 in linux "tg3: reports "eth0: DMA Status error. Resetting chip.", fails to work" [High,Confirmed] https://launchpad.net/bugs/1005699
<jsalisbury> ogasawara, do you happen to know ^^^
<infinity> Tangering has no PPC cross compiler, no.
<infinity> You could build it on davis.
<njin> hello, is this a kernel or compiz error ?  ther's here a good man to explain me ? Jun 11 18:04:21 quantic kernel: [  806.840646] unity-panel-ser[1996] general protection ip:4063bd sp:7fff05820a60 error:0 in unity-panel-service[400000+f000]
<jsalisbury> infinity, ok, cool.  let me see if I can access davis
<ogasawara> jsalisbury: if you don't have an account on davis, I do and can build the test kernel.
<njin> Jun 11 18:02:44 quantic kernel: [  710.344448] compiz[1907] general protection ip:7fd099f3869e sp:7fffc6914b70 error:0 in libunityshell.so[7fd099cf8000+32e000]
<jsalisbury> ogasawara, infinity, looks like I can login :-)  
<jsalisbury> infinity, I'll build a ppc test kernel and post the link to the bug
<infinity> Danke.
<infinity> I'll try to push to get it tested ASAP.
<infinity> I assume it's the same bug on the Xserves and the G1s, but one can never tell for sure.
<jsalisbury> yeah
<infinity> Best to know now, than to wait another SRU cycle or two.
<jsalisbury> infinity, do you happen to know if there is a precise or mainline src tree on davis?  It will just make it a little quicker since I can --reference it versus cloning a whole new tree.
<jsalisbury> infinity, if not thats fine.  I have the clone already going :-)
<infinity> jsalisbury: No idea.  If there is, it's not mine.
<jsalisbury> infinity, cool, thanks.
<infinity> jsalisbury: "locate debian.master" finds lots of copies. :)
<jsalisbury> infinity, ahh, right.  My clone just finished too :-D
<infinity> jsalisbury: /home/ogasawara/quantal-powerpc/ubuntu-2.6/ looks promising.
<infinity> Oh, nevermind then. :P
<jsalisbury> heh, I'm always in such a rush 
<infinity> Or precise-powerpc, rather.
<infinity> But whatever.
<infinity> It's not like a clone on that network takes long.
<jsalisbury> yeah, it was pretty fast
<jsalisbury> infinity, ogasawara, hmm.  the ppc build failed pretty early on davis:
<jsalisbury> dpkg-deb: building package `linux-headers-3.2.0-25' in `../linux-headers-3.2.0-25_3.2.0-25.40_all.deb'.
<jsalisbury> make: *** No rule to make target `binary-generic'.  Stop.
<infinity> There is no generic kernel on PPC.
<infinity> So that would make some sense.
<jsalisbury> infinity, ahh ok.  I better fix up my fakeroot alias then :-)
<infinity> Was that a "dpkg-buildpackage", or are you running debian/rules targets by hand?
<infinity> If you're just hitting specific targets by hand, the one you'd want to test on the buildds would be powerpc64-smp
<jsalisbury> infinity, Just copied my bashrc stuff from tangerine.  I have an alias to shorten the fakeroot command, and it was wrong.
<jsalisbury> infinity, cool, thanks
<BenC> Is this build failure in precise a recent problem?
<jsalisbury> BenC, it was my mistake ;-)
<BenC> Ah
<BenC> If you need any help with it, let me know, I've got local ppc systems here
<jsalisbury> BenC, awesome, thanks
<jsalisbury> infinity, so the debian/rules target should be powerpc64-smp ?  
<infinity> jsalisbury: I'd assuming binary-powerpc64-smp, if it's congruous with binary-generic.  I dunno.  I just build the whole source package. :P
<infinity> (ie: I just run "dpkg-buildpackage -rfakeroot -uc -us -B")
<jsalisbury> infinity, cool, thanks!  
<jsalisbury> infinity, yeah, binary-powerpc64-smp is the proper target.  I was leaving off the binary prefix
<ogasawara> balloons: have you heard any feedback from your 12.10 kernel testing in 12.04 announcement?
<balloons> ogasawara, yes I have
<ogasawara> balloons: I was looking at our daily bug reports, but haven't seen a lot of bugs being reported
<ogasawara> balloons: but that's not to say people aren't testing
<balloons> i'm causing down some folks who've had issues but didn't report they tested to the tool, nor filed a bug
<balloons> you can see the "results" in realtime but going to the page http://packages.qa.dev.stgraber.org/qatracker/milestones/223/builds/16265/testcases/1301/results
<balloons> as you see, there's only 3 listed there. but I've got emails or random contacts with several other people who tried it and succeeded or didn't
 * stgraber needs to change his hilight regexp not to match .stgraber.org ;)
 * balloons waves
<balloons> wow -- causing   should be chasing.. I'm chasing down folks who did the work, but didn't report
 * balloons wishes we could get a number on how many people (unique ips or something) installed from a ppa
<balloons> anyways ogasawara the point behind the qatracker is to capture everyone who's doing the install and making sure they report it in a sane place.. Any bugs they find should also be linked, making it all easy to see
<ogasawara> balloons: indeed and agreed.  I really want to have this help provide us a high confidence level for the 12.10 kernel in 12.04.
<balloons> ogasawara, yep, we're on the same page. So I'm herding cats more or less.. it's something new, and this is our first pass at it, so I'm doing my best to followup and ensure we get the results recorded
 * cking --> EOD
 * smb follows
<janimo> any reason why linux-backports-modules-3.2.0 is x86/amd64 only?
<jsalisbury> infinity, fyi, the kernel build is still happening on davis.  There is some puppet process hogging all the cpu.  Anyway, I'll post a link to the kernel in the bug when it's done.
<infinity> jsalisbury: Alrighty.
<infinity> janimo: I've wondered that myself, and never really looked into it.
<janimo> infinity, ok. Btw I cannot yet claim the cookies, had no time to earn them
<BenC> ogasawara: FYI, I have cleaner patches for the AACRAID/big-endian fixes. So if you hold off, I'll rebase and request-pull with that instead of the huge lumpy/krufty aacraid patch I have in there now
<BenC> These patches are also going upstream at the same time
<ogasawara> BenC: ack, I can wait to look.  I haven't had a chance yet today anyways.
<BenC> ogasawara: can you handle my sub request for kernel-team@ please?
#ubuntu-kernel 2012-06-12
<lifeless> would love advice on upstream acceptance for my fix for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733
<ubot2> Launchpad bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,Confirmed]
<BenC> lifeless: have you sent it to the dmraid/mdraid maintainers/lists?
<lifeless> BenC: I was told that dm-devel is the relevant list, and yes - I linked to the post in my last comment to the bug
<lifeless> BenC: so far (~1week) no comments/replies/nada
<BenC> lifeless: I think linking to a bug report is not something most people will follow through on
<BenC> lifeless: Have you sent a patch upstream?
<fdr-> 'allo all. I'm a noob to kernel hacking and am trying to hack something into the memory manager, but don't quite know how to get my test cycle sorted out.
<lifeless> BenC: I have, thats what I just said
<BenC> Sorry, my mistake
<lifeless> BenC: in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733/comments/16 I state that I've sent it upstream, and reference the url of the mailing list archive copy of the post I sent.
<ubot2> Launchpad bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,Confirmed]
<lifeless> BenC: no worries, must be awfully late for you.
<BenC> Quite
<lifeless> fdr-: What do you mean ?
<BenC> lifeless: You may get a better response if you send it inline so it's not an attachmentâ¦send it as an actual commit email
<lifeless> BenC: ah, really? I use gmail, so it will get line ending mangled doing that
<BenC> lifeless: Configure a local ssmtp to use smtp.gmail.com and 'cat 0001-*.patch | sendmail dm-devel@â¦.'
<BenC> It's what I do at least
<BenC> lifeless: You may also want to check your style conventionsâ¦use \t instead of 8 spaces
<BenC> Believe it or not, these simple things will get your patch ignored by the people you really want to look at it
<mjg59> git send-email will DTRT
<abogani> DTRT?
<diwic> Do The Right Thing?
<mjg59> Yes
 * BenC doesn't have a git send-email
<diwic> BenC, sudo apt-get install git-email
 * abogani needs coffee 
<ppisati> moin
<lifeless> mjg59: thanks
 * smb tries to have coffee
 * ppisati -> should get some more too
<RAOF> Hey git geeks! Say I wanted to rebase a tree on a newer upstream tree, but that newer upstream has a commit that reindents (with a script I have access to) every file in the tree, so every single change is all conflicts.
<RAOF> This sounds like something that there might be an obscure git tool to make less mindbogglingly painful.
 * smb tries to think hard ...
<smb> hm, there was something about ignore-space-change...
<ppisati> git apply -C1 --ignore-space-change ...
<smb> Yeah, not sure git merge can take the same... optionally I would git format my changes on top, then reset --hard and git am with -C1 and --ignore-space-change...
<ppisati> and have a lot of fun... :)
 * ppisati is looking for a netbook with a backlit keyb, but it seems it doesn't exist at all...
<smb> ppisati, I definitely had when trying to cope with some patches coming from some arm vendors (when I had to)... :)
<RAOF> And presumably --ignore-space-change won't actually fix the indentation on the *new* code.
<RAOF> A mere 87 commits to rebase!
<smb> RAOF, Hm, if I read the man correctly new lines would be "wrong" (like in the patch)
<RAOF> I guess I could do one pass as --ignore-space-change, and then a second pass fixing the indentation.
<RAOF> Bah, and it only ignores whitespace in the context lines, which is insufficient.
<caribou> apw: ping
<apw> RAOF, i would git format-patch the patches, apply the same algorithm to the patches, and then reapply them
<apw> caribou, hi
<RAOF> apw: Fiendish!
<apw> RAOF, and then demand beer from the culprit
 * RAOF wonders if indent handles diffs
<apw> RAOF, hmmm, not sure, you would probabally need to 'move' the prefix off (perhaps to the end of the line) and then use it, then move them back, its going to be painful
<caribou> apw: good morning how are you doing ?
<apw> caribou, fine thanks, you ?
<caribou> apw: I'm fine thanks. Trying to get people to understand why it is useful to upgrade to new kernels
<caribou> apw: http://caribou.kamikamamak.com/2012/06/12/lucid-panics-after-208-days-dont-get-biten-by-that/
<caribou> apw: any luck in building the ddebs ?
<apw> caribou, heh if they cannot work out why they need securiyt one should not be doing business with them
<apw> caribou, same place
<caribou> apw: ok, I'll go fetch them, thanks a bunch
<caribou> apw: I call this the Microsoft syndrome : people have been bitten so often by M$ telling them to upgrade systematically that they're worried to do so
<apw> heh ... "thanks a bunch" is a negative construction :)
<apw> caribou, yeah i can believe that
<caribou> apw: coming from a french canadian you should expect those bizzareries ;-)
 * smb feels that apw can find a negative in anything if he wants to
<apw> caribou, heh thats why i assumed it was positive regardless ... but a common 'continental language native speaker' error indeed
<apw> smb, heh, no but sarcasm allows everything to be so, and our langage was built for it
<smb> apw, exactly and "if he wants to" specifically targets the relationship between mood and sarcasm seen ;)
 * cking contemplates buying an Lenovo X230...
 * cking finally does his belated laptop refresh
 * ogasawara back in 20
<manjo> henrix, any luck with gustavo ? 
<henrix> manjo: nop, didn't got any answer from gustavo
<manjo> sometimes they are a little slow to respond 
<manjo> especially on the mailing list I have had ccing his email 
<manjo> I have had better luck .. ^^
<henrix> well, i;ll give him a couple more days before ping'ing him again...
<manjo> cool :) 
<manjo> hopefully you should be able to give him the info he wants to get that patch in 
<manjo> funny thing is I have submitted 5 other patches to the same guy and he took it without asking additional Qs except on this one 
<manjo> he came back with more Qs once I gave up the HW so I don't have a way to give him the info he wants 
<henrix> but do you have any idea what sort of info he's looking for?
<manjo> he wanted the output of usb-devices before and after the patch 
<henrix> oh, ok.
<manjo> I gave him the output after the patch ... did not think he will need one before caz the device won't show up without the patch 
<henrix> ok, got it
<manjo> so if you can send him that info ie ... output of usb-devices (showing missing device probably) and he might be happy 
<henrix> well, the thing is i don't have the hw. i may ask it from a bug reporter, but i couldn't get him to test a kernel yet
<henrix> i'll try to get that info
<tjaalton> is the queue for 3.2.x at stable@v.k.o or elsewhere?
<tgardner> tjaalton, git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<tgardner> tjaalton, hmm, could be the incoming queue is elsewhere. herton could tell you.
<smb> git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
<smb> tjaalton, ^
<herton> yep, this is the correct url
<tjaalton> smb: yeah, I'm looking where to propose commits to the queue :)
<herton> ah 3.2 is different, wait
<herton> tjaalton, git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-3.2.y-queue.git
<smb> tjaalton, Proposal rather are done by sending emails to stable@vger.kernel.org
<tgardner> see Documentation/stable_kernel_rules.txt
<tjaalton> ok thanks, that was the question.. didn't know if 3.2.x used the same list
<smb> herton, Oh, right, had not updated my work tree for quite a while it seems... 
<herton> smb, tjaalton: the queue is different, since is ben maintaining it now, but everything else continues the same, regarding the stable rules/mailing list
<tjaalton> herton: right, thanks
<smb> herton, I would have known the queue is wrong if I would have stopped to think a bit longer. :-P  Knowing that Ben has taken over there.
 * herton -> lunch
<smb`> apw, ogasawara Hm, could it be that the virtual-meta package is messed up somewhat in quantal? Somehow I would expect linux-virtual to depend on linux-image-virtual and not linux-generic...
<apw> smb`, no that is right
<apw> smb`, you were there when we discussed it!  we split linux-generic so you could use the first half as -virtual and both halves as -generic
<apw> and save a build
<smb`> apw, I know that, but by depending on the linux-generic meta package, don't you actually pull in both again
<apw> smb`, oh you meant to say depend on linux-image-XXX-generic
<apw> smb`, that would indeed sound right
<smb`> apw, That might be the same result. I had the feeling it was sort of stacked linux-virtual -> linux-image-virtual -> linux-image-abi-generic
<apw> smb`, ahh yes
<smb`> apw,  So probably linux-image-extra-virtual should also point to linux-image-extra-abi-generic instead of linux-image-generic
<apw> smb`, i think that sounds about right overall yes
<smb`> apw, ok, will prepare a patch and send out
<ogasawara> smb`: please do, I'll review and apply.  It does look like it's not quite what was intended.
<smb`> ogasawara, Right, I sort of feared it may be after the discussion that just came up in the server-team meeting about unnessesary bloat...
<apw> smb`, heh they noticed, i am supprised
<smb`> apw, apparently 200M is enough for some reason... (not sure it is all because of the modules)
<seb128> hi
<seb128> I've an issue on precise and I'm wondering if that could be a kernel problem and what infos could be useful to debug it
<seb128> often after build "big" packages (glib, gtk, ...) the system starts being really slow
<jsalisbury> seb128, I'd suggest opening a bug.  You can run the following from a terminal:
<jsalisbury> seb128, ubuntu-bug linux
<seb128> it seems sluggish and memory usage seems quite high compared to what it should be
<seb128> jsalisbury, well, I would first like to figure if that's a known sort of issue and if that could be the kernel ;-)
<apw> seb128, memory usage should be 'full' always ... as the kernel will never empty a page unless it needs it for something
<jsalisbury> seb128, And sluggish behavior doesn't sound normal.  Try running top when it is sluggish and see what is consuming the resources
<jsalisbury> seb128, and it won't hurt to open a bug.  If it's an invalid kernel bug, we'll tell you so ;-)
<seb128> apw, jsalisbury: nothing it showing in top, it's like my i5 ssd was turning to a pentium 3 with 128mb ram after big builds
<seb128> then not recovering until power off
<seb128> like I had the feeling last time it happened that it was still the same after restart
<seb128> I wonder if it's overheating and the cpu is kicking is low frequency mode or something
<apw> seb128, collect /proc/meminfo and /proc/slabinfo at boot and when the issue occurs
<seb128> do you know how I could check that?
<apw> seb128, if its a laptop i'd not be supprised if its heat, is it a lenovo ?
<jsalisbury> seb128, if you open a bug with ubuntu-bug, we'll get a copy of your logs.  That will give you a place to add info we request as well.
<seb128> apw, it's a dell latitude e6410
<apw> seb128, you used to be able to have a temperature gagues on the top bar, bar thats not allowed now
<apw> seb128, i've used sensors in the past to collect temperature information
<apw> as for cirtain if its tooo hot it will throttle the cpu to protect it
<seb128> apw, can I get the CPU state info from the kernel,system in some way?
<apw> sensors can get it, you run sensors-detect first to get them working
<seb128> apw, jsalisbury: thanks, I will watch for it and open a bug with the infos
<seb128> it seems a bit better now
<seb128> Core 0:       +48.0Â°C  (high = +95.0Â°C, crit = +105.0Â°C)
<seb128> Core 2:       +50.0Â°C  (high = +95.0Â°C, crit = +105.0Â°C)
<seb128> that's the sensors infos
<seb128> but it might just that looking around and asking on IRC he went back to a reasonable temperature where it was hitting the limit before
<seb128> the system seems to have mostly recovered performance while 
<seb128> while->wise
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 12th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 19th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<jsalisbury> tgardner, this was just reported: bug 1009553
<ubot2> Launchpad bug 1009553 in ubuntu-meta "jeos install oversized" [Medium,Confirmed] https://launchpad.net/bugs/1009553
<smb`> jsalisbury, That is just what I was referring to
<smb`> jsalisbury, Just sent patch for it
<smb`> ogasawara, Please have a good look. I am not sure I did not mess anything up given the time and the speed it was slapped together... ;)
<ogasawara> smb`: ack
<tgardner> ogasawara, smb`: I don't think it makes any real change, but I'm gonna go have lunch first before I say for sure.
<ogasawara> smb`: my initial thought is that by not redirecting to the generic meta package, we can never drop the virtual meta package from existence
 * ogasawara needs to think this through again
<smb`> ogasawara, I guess as long as there is some need for a small and bigger install probably not. Not sure whether there would be a way to have different names, virtual just was convenient...
<smb`> tgardner-lunch, The main change is for linux-virtual not to depend on linux-generic, the other changes are probably more a subjective matter
 * smb` looks for some dinner
<BenC> tgardner-lunch: Can you (or someone) process my sub to kernel-team, please
<ogasawara> smb: so I think what is needed is rather linux-virtual -> [linux-image-virtual, linux-headers-virtual]
<ogasawara> smb: that doesn't resolve my hope to eventually drop the stub virtual meta package, but I believe that at least fixes the issue at hand
<cking> tyhicks, I'm seeing large seeks (> 600M) on eCryptfs with xfs as a lower file system run really slowly on 3.4 kernels on some hardware. vmstat shows I/O running at only 340 blocks per second, were as I can write at tens of MB/sec to the lower fs. have you seen this behaviour before?
<ogasawara> smb: I'd probably leave the other cross dependency meta package bits in place
<ogasawara> smb: I'll send out a proposed v2 of your patch
<smb> ogasawara, Right, the description part is not important and the two other dependencies are factually the same as before in the end
<smb> ogasawara, ack
<tyhicks> cking: What exactly are you doing? Seeking past the end of the file and then writing out data at that position?
 * ogasawara is still pondering how to get to a place where I can remove the -virtual meta package entirely and everyone would transition to just -generic
<cking> tyhicks, yep, it's the extend-file-random test in the eCryptfs tests
<tyhicks> cking: That has always been a bit of a sore spot for eCryptfs performance because it has encrypt pages of zeroes to extend the file. I wouldn't expect it to be nearly that slow, though.
<cking> tyhicks, on other H/W it runs significantly faster
<tyhicks> cking: Strange. What's common among the hardware showing poor performance?
<smb> ogasawara, That could prove quite hard as long as there is generic and generic (but please not too much) and some people for whom size does actually matter... ;/
<cking> tyhicks, they are big iron boxes
<tyhicks> cking: Do they have bigger than 4k page sizes?
<cking> tyhicks, reckon so
 * tyhicks thinks
<tyhicks> cking: I'm wondering if we have some silly math in ecryptfs_write() that only shows up when PAGE_CACHE_SIZE is greater than 4k
<cking> tyhicks, that's a good start, I can try to debug that path tomorrow
<tyhicks> cking: Sounds good. Ping me if needed.
<blueyed> Have mainline builds for Precise stopped? I would like to use 3.4.2, but cannot find it on http://kernel.ubuntu.com/~kernel-ppa/mainline/
<ogasawara> blueyed: looks like it's there, just using the quantal config for the build now -> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4.2-quantal/
<BenC> ogasawara: BTW, in regards to quantal kernel on precise, it at least works for me on powerpc
<ogasawara> BenC: that's good news, I'm still a little gun shy to pull the tigger and upload
<BenC> ogasawara: nuthin' to it but to do it
<BenC> At least, so I've heard
<ogasawara> BenC: hehe, it does work for here me and that's all that really matters right? :)
<BenC> It's all about scope :)
<cking> quality testing strategy
<ogasawara> tgardner: I'm gonna upload linux-meta to get that fix released
<tgardner> ogasawara, I'm just in the middle of it
<ogasawara> tgardner: sweet, I'll leave it to you then
<tgardner> ogasawara, uploaded
<ogasawara> tgardner: awesome, thanks
 * cking -> EOD
 * tgardner -> EOD
<thomi> Hi, I'm trying to PXE boot the precise live CD image, and I need to get the kernel to load the graphics drivers earlier. I think the way to do this is to add the appropriate drivers to /casper/initrd.lz but I can't seem to find any documentation on how to do that. Can anyone point me in the right direction?
<BenC> thomi: That's a better question for #ubuntu
<thomi> BenC: oh ok, thanks.
<lifeless> BenC: thanks for your advice last night
<BenC> lifeless: No problemâ¦good luck on getting that accepted (no sarcasm intended)
<lifeless> BenC: I'll tweak the patch to use tabs - 8 wide spacing, right ?
<BenC> Correct
#ubuntu-kernel 2012-06-13
 * smb mornings
<ppisati> moin
<jMCg> whoowhoo! I just saw my favourite bug is being "confirmed" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/613273
<ubot2> Ubuntu bug 613273 in udev "run-init: nuking initramfs contents: directory not empty" [Undecided,Confirmed]
<jMCg> I mean, good morning.
<apw> $purge_build_directory = 'successful';
<apw> $purge_session = 'successful';
<ppisati> pristine O/omap4 armel installation on a pandaes, lightdm instead of showing up shows a black screen with a blinking pointer/arrow... xdm works ok...
<ppisati> either i forgot to install something (it was a server installation), or lightdm in O/omap4 was broken, or $something else...
<ppisati> btw wmaker rocks on it! :)
<ppisati> brb
<henrix> ppisati: wmaker rocks everywhere :)
<ogra_> ppisati, how did you install the desktop parts (it should be impossible to "forget" something, dependencies should care)
<ppisati> ogra_: i didn't install ubuntu-desktop
<ppisati> ogra_: just some components (xorg, light, wmaker, etcetc)
<ogra_> well, that might make you end up without a greeter 
<ppisati> i've a greeter
<ogra_> which one ?
<ppisati> gtk
<ogra_> note that there are also prototype greeters as packages
<ogra_> but gtk should be ok
<tgardner> henrix, pushed lts-backport-natty
<henrix> tgardner: ack, thanks
 * apw lunches
<henrix> tgardner: i've just uploaded the pkg into zinc:~henrix/for-signing
<rick1121> Hello. I'm trying to install the broadcom-sta driver module, but it doesn't come with dkms in precise. Can anyone point me in the right direction? Note that bcmwl-kernel-source provides an earlier version of this driver (and it's not what I want). https://launchpad.net/ubuntu/+source/broadcom-sta
<tgardner> henrix, rtg@zinc:~/for-signing
<henrix> tgardner: cool, thanks
<rick1121> How do I go about adding a module that does not have dkms?
<pgraner> bjf, sconklin_, the PO for your hw has been acked, being ordered today
<sconklin_> \o/
<bjf> pgraner: thanks
 * ogasawara back in 20
<cking> sconklin_, was that the one with the fluke aligator clips?
<cking> pgraner, i believe there was a PO outstanding for some fluke multimeter kit that was put in as a request ~7+ months ago. is it possible to get that moving?
 * ppisati -> gym
 * cking kicks the AP
<infinity> apw: Hey, remember when we had conversation over beer that perhaps 3.x.x-ABI-flavour should be replaced with 3.x.x-BUILD-flavour?  Did anything ever come of that when sober?
<infinity> apw: Probably needs to happen in tandem with me fixing autoremovals, so we don't bloat machines even worse than we already do, but I have often feared that my running kernel would be replaced with something ABI-compatible-but-non-bootable, and I'd, of course, no longer have a "known-good-kernel" to reboot into.
<apw> infinity, yeah, though your stuff should be keeping the old kernels x3 which we should try and make ones we have successfully booted, i wonder if we know that
<apw> infinity, though nothing further was reall discussed on it no
<infinity> apw: Well, sure, my stuff would, by default, have something older than your running kernel too.  But imagine the fresh install case.
<infinity> apw: I do a fresh install, and the next SRU kernel is ABI-compatible, but doesn't work on my hardware.  I have no fallback, cause we just overwrote it.
<apw> infinity, we always bump the abi for the first kernel, its is never abi compatible even if it is
<apw> for this very reason, that the CD kernel clearly worked, so you always need to keep that one
<infinity> apw: Is that true of the first SRU after a point-release too?
<apw> infinity, hmmm, now that is a good question, i would say its probabally not in our proceedures but should be
<infinity> Still, that sounds like a hackish workflow just to avoid the problem, rather than solving it.
<infinity> I'd argue that overwriting kernels is probably never the right answer.  Not now that dkms DTRT for modules, etc, so it's less hassle.
<apw> bjf, herton ^^ ... infinity points out that the first kernel update after a point release in an LTS should _also_ be a manditory ABI bump just as the first SRU after release is ... 
<apw> infinity, i cannot deny that indeed
<apw> ogasawara, we should put discussing this abi issue on our agenda
<bjf> apw, i agree and i think that has always been the case. am i mistaken ?
<bjf> apw, missed the point, i understand and agree
<infinity> bjf: You may not be mistaken, it just came up in idle conversation.
<apw> bjf, i don't recall seeing the ABI bump after a .1 release being indicated separatly, but if you interpret the current rule to mean that then all is good for now
<bjf> infinity: was thinking of the first sru post release, you are making the point this should be after point releases as well
<bjf> and i agree
<apw> infinity, ok so lets assume documentation will be updated and proceedures too to do that, and i'll get this discussed when we are together
<infinity> bjf: Yeah.  Since what we're trying to avoid is overwriting the kernel that came from installation media.
<bjf> roger roger
<apw> thanks
<bjf> ^ herton, henrix, sconklin
<herton> ack
 * ogasawara throws it on the agenda
<apw> ogasawara, thanks ...
 * tgardner -> EOD
<manjo> jjohansen, around? do you know how I can build kernel dbgsyms package ? 
<manjo> jjohansen, nm got it 
#ubuntu-kernel 2012-06-14
<mfilipe> hi! I updated my kernel today and it doesn't show more the splash screen to decrypt my lvm
<mfilipe> :S
<mfilipe> anyone here with same problem?
<ppisati> moin
<smb> morning
 * apw yawns
<mnemoc> hi, I'm trying to make a .deb out of a kernel for a cortex-a8 soc I'm unofficially maintaining. what's the right way of making make-kpkg produce an uImage instead of vmlinuz? also, it seems only --arch arm is supported, will this work on armel and armhf?
<ppisati> mnemoc: to get an uImage instead of vmlinuz, use make uImage
<mnemoc> ppisati: when building manually sure, my doubt is when using this `make-kpkg` thing. I want to share a .deb people could just use...
<mnemoc> or `make-kpkg` is the wrong approach?
<cking> smb, apw, some more benchmarks: http://zinc.canonical.com/~cking/iosched/postmark
<ppisati> ok, this is funny
<ppisati> if i'm logged in in another tty (say via ssh(
<ppisati> then the serial is ok
<ppisati> else we start loosing chars
<brendand> Daviey, are there backport kernels for servers too?
<Daviey> brendand: we share a kernel, so yes.  I cannot comment on server specific regression testing.
<brendand> Daviey, sorry - i actually didn't ask a detailed enough question. what i meant is are there Q series backports for Precise server and which PPA do i get them from? is it the same as for desktop?
<ppisati> brb
<Daviey> brendand: same as desktop, we now share kernels
 * ppisati -> out for food, later
<brendand> once i've enabled the https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport ppa, is it a matter of just doing  dist-upgrade to install the quantal kernel?
<tgardner> brendand, nope, you have to install the kernel meta package thats in that PPA
<brendand> tgardner, linux-meta-lts-quantal ?
<tgardner> brendand, seems about right
<brendand> tgardner, sure does. i'm only suspicious because it's not been picking it up on my own precise install. trying on vbox now
<brendand> tgardner, still says unable to locate package
<brendand> weird
<brendand> i enabled with apt-add-repository and then did apt-get update to make sure
<tgardner> brendand, because thats the source package name ? try one of the binaries.
<brendand> tgardner-afk, right, so linux-image-generic-lts-quantal
<brendand> cking - i still haven't managed to catch vanhoof about where to raise firmware bugs. any chance i could raise them in fwts itself and move them later?
<brendand> cking - i've a few, including some criticals, from quantal testing
<cking> brendand, well vanhoof is on vacation, so you won't get much from him from the next week. so file them against fwts and then we will sort this out later when he gets back. did you send him an email about it?
<brendand> cking, not yet. i will and cc you on
<brendand> cking, this is one of the criticals. actually looks pretty bad : http://paste.ubuntu.com/1040728/
<cking> brendand, ok - file a bug as per usual
<cking> lemme know the bug number and I can eyeball it too
<brendand> https://bugs.launchpad.net/fwts/+bug/1013168
<ubot2> Ubuntu bug 1013168 in fwts "Asus ET2012E fails checksum test" [Undecided,New]
<cking> brendand, so it looks like the kernel has loaded the ACPI tables, so can you add the output from "sudo acpidump" to the log so I can see why fwts is complaining
<brendand> cking, assuming the system is still booted to access it, yeah. otherwise tomorrow (or maybe later today)
<brendand> cking, one sec
<brendand> cking: ubuntu@201201-10354:~$ sudo acpidump
<brendand> sudo: acpidump: command not found
<brendand> ??
<sforshee> brendand, sudo apt-get install acpidump
<brendand> sforshee, well yes
<cking> ..sorry I was answering a phishing scam call just then
<brendand> cking, i assume you'd expect acpidump to be installed already?
<cking> brendand, nope, I just guessed you may know how to install it
<brendand> cking, ok ok, i was just checking that you weren't relying on it for fwts to do it's job
<brendand> cking - looks like a little networking issue in the taipei lab. i'll have to check it with our lab engineer. i think he'll be around later, either that or tomorrow
<cking> brendand, nope, thats all taken care of in fwts
<brendand> cking, at the moment i can't install anything on that system
<cking> brendand, OK - well I will look at see if it's now a critical issue for Quantal. I believe it used to be bad issue a while ago.
<tgardner> jsalisbury, ppetraki, henrix, ayan, jjohansen - rebooting tangerine for kernel update soon
<tgardner> ppisati, ^^
<jsalisbury> tgardner, ack
<henrix> tgardner: ack
<ppisati> ack
<brendand> cking - http://paste.ubuntu.com/1040784/
<cking> brendand, I've updated the bug and will add some better intelligence to fwts.  See the bug for the full description of what's wrong
<brendand> cking, ok
<cking> thanks for the data too
<brendand> cking, no problem. i was just about to note that acpidump spat out 'Wrong checksum for XSDT!' on stderr, but you reached that conclusion already
<cking> :-)
<brendand> cking, so fwts was actually the right place ;)
<cking> of course:-)
<cking> brendand, I've got a fwts fix to help with this kind of issue, it will appear in the next release of fwts within a week or so
<brendand> cking, no problem. we'll be looking out for it
<tgardner> smb, gomeisa needs rebooting for kernel update
<smb> tgardner, Ok, then I start my build when thats done. I am off it
<jsalisbury> bjf, herton, henrix: Looks like a regression in 3.2.0-25: bug 1013093
<ubot2> Launchpad bug 1013093 in linux "Latest kernel causes purple screen of death" [High,Confirmed] https://launchpad.net/bugs/1013093
<henrix> jsalisbury: yeah, i was actually looking at it
<henrix> jsalisbury: i guess we need to get a little bit more info from the bug reporter
<jsalisbury> henrix, cool, thanks.  
<henrix> jsalisbury: np
<jsalisbury> henrix, yeah, I asked for him to disable splash to try and capture more info
<henrix> jsalisbury: yep, that should give us something to work with
<jsalisbury> henrix, thanks for looking
<jwi> jsalisbury: and check if fglrx is built properly on the new kernel :)
<jsalisbury> jwi, ok.  Anything specific to look at to check that fglrx was built properly?
<jwi> jsalisbury: jockey/dkms log files? afair fglrx also complains to dmesg if there's a version mismatch.
<jsalisbury> jwi, ok, thanks!
<ppisati> http://blogs.skype.com/linux/2012/06/skype_40_for_linux.html
<ppisati> whoa!
<ppisati> after years on stagnation, a new relase i can't belieive it!
<ppisati> *of
<cking> I don't believe it
<cking> which universe are we living in again?
<apw> bjf, what is going on with master-next on precise ?
<apw> bjf, its based on Ubuntu-3.2.0-24.37 but master is -26 ?
<apw> henrix, ^^
<apw> herton, even ^^
<bjf> apw, looking
<henrix> apw: checking
<tgardner> didn't get rebased ?
<apw> twice ?
<bjf> apw, i know we are working on the start of the new cycle
<apw> how did we make -26 from -25 if its not in master-next, makes no sense
<tgardner> apw, dunno, but it _is_ a straightforward rebase.
<henrix> ok, so that's probably a coordination issue..? i don't usually do the rebase (no permissions) and i guess usually herton does that
<sconklin_> I pushed that yesterday, maybe I screwed it up
<bjf> apw, we'll get it sorted
<apw> i don't think i want to have to rebase master-enxt every time i want to make a test kernel, that seems to defeat the point of it being the 'next' kernel
<apw> its the last kernel plus some random crap if its not up to date?
<tgardner> apw, agreed. 
<jsalisbury> bjf, herton, henrix, looks like one more regression in 3.2.0-25: bug 1013183
<ubot2> Launchpad bug 1013183 in linux "Sound playback stopped working in 3.2.0-25" [Medium,Confirmed] https://launchpad.net/bugs/1013183
<henrix> apw: right, i guess that's my fault there. whenever i ask a sponsor to push a kernel, i never check he has done the rebase and i never explicitely ask him to do that
<tgardner> apw, whats interesting is that 2 of the recent hwmon patches I submitted disappear when rebased against master.
<apw> tgardner, yeah its clearly doubly broken as its more than one behind
<apw> fingers crossed nothing got lost
<sconklin_> I know what happened, and I'll fix it.
<jwi> tgardner: i think 3/4 and 4/4 of your fam15h_power patches have already landed in oneiric (and precise) through -stable
<tgardner> jwi, I think so too
<sconklin_> Unless someone else also rebased or forced, I have everything I need to fix it
<apw> sconklin_, do you know we won't have lost anything or do we need to review the mailing list
 * apw hasn't done that
<jwi> tgardner: yep, 3.0.31 and 3.2.17
<sconklin_> I know for sure (because I always check) that the commit before I pushed matched what is now in master
<sconklin_> and what was pushed was an old local branch that I still have. So I can take the additional commits that were made on that and rebase them onto master and we shoudl be good
<tgardner> sconklin_, looks like.
<tgardner> sconklin_, what if you just rebase master-next against master ?
<sconklin_> tgardner: that would be a mess because of the differences in abi bumps and such. Easiest thing it to cherry pick the 5 commits and force it back up
<tgardner> sconklin_, hmm, I rebased it wothout any problem.
<tgardner> no conflicts
<ogasawara> bjf: just got off my manager call, gonna dip out for 5min and be back for our SRU call
<sconklin_> and you got these five commits:?
<sconklin_> 158e492 hwmon: (fam15h_power) Fix pci_device_id array
<sconklin_> 8e701b3 hwmon: fam15h_power: fix bogus values with current BIOSes
<sconklin_> e8bbc41 hwmon: (fam15h_power) Increase output resolution
<sconklin_> c763cca hwmon: (k10temp) Add support for AMD Trinity CPUs
<sconklin_> 876c6d1 x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
<bjf> ogasawara: ack
<sconklin_> tgardner: 
<tjaalton> tgardner: test-building the intuos5-branch, i'll send a pull request on the list later :)
<tjaalton> (rebased on current master)
<tgardner> sconklin_, 2 of them disappeared cause they were already in a stable update that was on master but not on master-next
<sconklin_> ack
<tgardner> tjaalton, ack
<sconklin_> ok, why don't you push that and then I'll check against what I have here. That way I'll preserve everything I have for sure
<tgardner> sconklin_, ok, one sec...
<tgardner> sconklin_, done
<BenC> tgardner: How's the e500mc looking? I'll be in San Antonio from Sunday to Friday next week, so I'm hoping to have good news for some folks while I'm there :)
<tgardner> BenC, I sent email yesterday to you and the list NAK'ing the pull request.
<sconklin_> tgardner: checking
<BenC> tgardner: I didn't get an email
<tgardner> hmm, lemme check where it went
<BenC> And no one has processed my request to sub to kernel-team@ yet
<bjf> tgardner: it made the mailing list
<tgardner> BenC, https://lists.ubuntu.com/archives/kernel-team/2012-June/020706.html
<BenC> Wait, I see the list stuff
<BenC> tgardner: I suspect you don't have enough experience in the powerpc community to make some of the assumptions you have in this email. Replying now.
<tgardner> BenC, you're absolutely correct, which is why I asked about it.
<BenC> You asked, but without the possibility that these patches may be more relevant now :)
<tgardner> BenC, its gonna be  a hard sell given the other inclusion criteria, but we can duke it out on the list.
<sconklin_> tgardner: looks ok, I also verified that the 2 commits that disappeared were really there . Thanks.
<tgardner> sconklin_, np
<sconklin_> apw: thanks for the alert
<BenC> tgardner: One of the main issues at hand here is that Freescale Power CPU/SoCs are about to reach critical mass, and either I can put Ubuntu in front of it, or it can be behind it. A good portion of our customers are looking to the cloud, and I think Ubuntu puts them in a better place, but if the install/support isn't there, then I have no pull with my fellow engineers and the pin heads to make Ubuntu tier one for them. They will buckle to 
<BenC> buzz and executive requests to go with that other distro
<BenC> linux# git log | grep '@freescale.com' | wc -l
<BenC> 4560
<BenC> tgardner: would you be open to a patch that simply adds the e500mc support as a build target first, and then I can work on each of the rest of the patches individually?
 * ogasawara back in an hour, pediatrician
<BenC> The PHY/MDIO stuff is mainly to support the 10G SoC based ethernet, so I can work on that separately (all of my [Upstream] based patches are accepted upstream, so you can safely assume those will get merged at some point, but please consider including them now to avoid the unneeded delay).
<BenC> Actually the MDAC one is required to make things compile
<BenC> And the PCI one is required to make things boot, but they have been accepted upstream (PCI by benh, mdac by the mdac maintainer)
<mfilipe> hi! I use lvm encrypted and now I updated my kernel to 3.2.0-25-generic-x86_64. So, after that update my kernel doesn't show the splash screen to inform the password to decrypted my lvm. What is wrong? Anyone know something about that?
<bjf> mfilipe: please file a bug, this sound similar to another reported problem but we'd like the bug anyway
<henrix> mfilipe: are you able to introduce the passphase from a terminal? (Ctrl-Alt-F5, or other F*)
<tgardner> BenC, lemme get back to you. I gotta step out for a bit.
<bjf> mfilipe, if you can keep an eye on the bug once you've filed it, we'd like some help in finding the regression
<cking> apw, smb, I've finally written up those ioscheduler tests results - kept on getting distracted today, so it's a bit later than I anticpated
<smb> cking, cool. well it wasn't like expecting you to get something today... :)
<cking> smb, I re-built those graphs, did some analysis and wrote it up while doing other bits and bobs, the usual kind of stuff really
<smb> cking, Yes, I had a bit of a look and at least read the summary. Just intended to say that it was clear it is a bunch of stuff to put together, so no need to think you are late
<smb> cking, The graphs look a bit less scary when starting at 0 ;)
<cking> yep, gnuplot needed some love
<mfilipe> henrix, the screen stay black but I put the passphase seeing nothing and the kernel accepts 
<mfilipe> bjf, ok, I will report it
<mfilipe> thanks
<henrix> mfilipe: ok, so you're actually able to boot?
<bjf> mfilipe: thanks
<mfilipe> henrix, yes
<henrix> mfilipe: ok, cool. can you please post the bug number once you've reported?
<mfilipe> I boot but without see the field for passphase 
<mfilipe> yep
<henrix> mfilipe: thanks
<mfilipe> I will reboot here to generate clean logs to bugreport 
<mfilipe> henrix, bjf: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1013315
<ubot2> Ubuntu bug 1013315 in linux "Kernel doesn't show splash screen to decrypt LVM" [Undecided,New]
<bjf> mfilipe: thanks
<henrix> mfilipe: ack, will take a look
<mfilipe> ;)
 * cking -> EOD
 * smb out
 * ogasawara -> dentist, back in a bit
 * tgardner -> EOD
<henrix> mfilipe: still around?
<mfilipe> henrix, yes
<henrix> mfilipe: right, so i was looking at the bug and i was wondering if you could:
<henrix> 1) test mainline kernel as suggested by the last comment in the bug report
<henrix> 2) make sure the issue is not present in the old kernel (i.e., just reboot into the old kernel to check)
<henrix> finally, i guess we will need to do a bisect to find the offending commit(s)
<henrix> could you try 1) and 2) and post results into the bug report?
<henrix> then, we could start the bisect, by building kernels so that you can test them until we find the faulty commit
<mfilipe> ok, I will do that
<henrix> mfilipe: thanks
#ubuntu-kernel 2012-06-15
<MadBoat> Hello. Im trying to compile an ubuntu kernel for the first time, and I'm running into a problem with a video driver for the platform im compiling for
<MadBoat> I'd like to know how to go about stopping the make process from trying to compile this driver
<BenC> MadBoat: Best bet for questions like this is #ubuntu
<MadBoat> alright. on what server?
<MadBoat> Im an IRC newbie as well, sorry if thats newb question
<BenC> MadBoat: this server
<MadBoat> K. much obliged
<ppisati> moin
<cking> morning ppisati
<cooloney> cking and ppisati, morning
<cking> hiya cooloney
<cooloney> cking: got your email. 
<cking> ack
<cooloney> cking: looks like we still don't have any clue to decide the change 
<cooloney> maybe we need some input from ubuntu server folks
<ppisati> ciao * :)
<cooloney> ppisati: how's going? and your usb issue on beaglexm
<cking> cooloney, as long as they don't provide us with untested "gut feeling" preferences that don't consider recent kernels
 * cking just likes hard facts
<cooloney> cking: right, we need reproduce the issue firstly and try more test case. 
<smb> morning
<cooloney> smb: morning
<cooloney> cking: i just was told they got a lot of writing operation timeout when using CFQ in cluster server. but have no idea to test this or reproduce it.
<smb> cooloney, Was that the same bug report as that one being done on a kvm?
<smb> (which I did not yet have luck in reproducing)
<cooloney> smb: hmm, i don't think so. just some description from them, i also want some hard facts like cking
<smb> Right, I agree changing anything based on no facts makes no sense
<ppisati> cooloney: saw ming's email? i'm gonna try that now
<cooloney> smb: yeah, on my side, i just have an 3 years old desktop, no chance to do some fancy testing
<ppisati> cooloney: after that i'll see for smsc911xx phy deinit code
<cooloney> ppisati: yeah, worth a try.
<cking> I can rig up more tests if required
<ppisati> cooloney: but the problem is that, after kexec, the entire usb hub is dead
<ppisati> cooloney: so IMO the problem is one layer below all these drivers
<cooloney> ppisati: i saw several patches from ming about usbnet, but might not related to kexec
<smb> cooloney, Heh, actually one feels as really old hardware is ideal. That makes the disk output even slower. :)
<ppisati> cooloney: but let me first try ming's mfd patch
<ppisati> cooloney: if it revives the usb, then the rest might be worth a try
<cooloney> ppisati: right, ming is good for help ^^
<smb> cooloney, But anyway. If your friends could open bug reports and provide a bit more information about the setup and what fails where (and maybe you then subscribe me to those) then we can start gathering facts
<cking> yep, the more data the better
<cooloney> smb, cking, right, and which testcase or benchmark tool is good for parallel reads and writes 
<cking> all and none of them
<jussi> Can anyoen tell me what is the status of the new poulsbo driver in Ubuntu?  is it in Precise/Quantal? Does it do 3D?
<rbasak> Kernel image taxonomy: is the "generic" flavour for i386/amd64 analogous to ARM subarches? So if I had a architecture-aware hierarchy, would it be fair to use <arch>/<flavour> and end up with amd64/generic and armhf/highbank without any collisions or confusion?
 * ppisati -> out for lunch
<caribou> apw: ping
<apw> hi
<caribou> apw: remember the ddeb that you rebuilt for me a few days back
<caribou> apw: I just found out that, while working well with crash dumps, it causes problem with systemtap
<apw> yay ... its good job we don't support those versions :)
<apw> what sort of problems does it cause
<caribou> well the Build-id mismatch that I got from systemtap on a rebuilt ddeb (both by you and arges_) doesn't appear on the original ddebs
<arges_> caribou, is that related to any bugs ?
<apw> well frankly they are rebuilt, and the stamp is likley wrong
<apw> and never can be right
<caribou> I had kept a .tgz copy of the original ddeb (the one that was on the archives) and this one works
<caribou> apw: I could open a bug on this, but it mostly concern systemtap. Just thought I'd mention it
<apw> the build stamps likely include the date and time of the build ...
<apw> i don't think anyone will fix it as clearly you are asking for trouble to not use the ddebs which were made with the kernel you are debugging; it is correct to tell you its wrong
<arges_> apw, would there be a way to extract this from the .deb and insert into the rebuilt .ddeb ... or perhaps allow the debugging tools to ignore the time stamp difference
<apw> you probabally should look to makeing the tool continue --i-know-i-am-using-the-wrong-ddeb
<caribou> note sure it's the timestamp. might be coming from the ELF notes
<apw> arges_, you should not be looking to do thing routinly, you should be retaining the old ddebs if you are supporting unsuported kernel versiosn
<arges_> apw, unfortunately the natty kernel ddebs were already deleted before we had a chance to back them up
<apw> the tool is right to tell you off, as there really is no guarentee the info is even right
<arges_> and we're working on crashes that involve natty
<apw> you have ddebs for the support kernel versions even in natty
<apw> and the old ones, they are gone, and they arn't recoverable
<caribou> apw: arges_ the code that triggers the Build-id mismatch is runtime code triggered by systemtap
<apw> caribou, arges_ i have to reiterate there is almost no chance they are completely accurate debugging symbols if rebuilt; the compiler is not the same most likely
<apw> given systemtap is dropping code over the kernel code segment live while its running, i am not supprised it is reticent to do so with debug info which is dubious
<caribou> apw: I know. I Just wanted to make you all aware of this. But looks pretty good for crash dump analysis
<apw> indeed i think i would prefer systemtap refuse and have no way to let you
<caribou> apw: could this be caused by the fact that the ddebs were done on a newer distro (i.e. diffs in elf or such) ?
<apw> as patching a live running system which it will likely lead to pain
<apw> caribou, they were built in appropriate chroots, but ones which were up to date
<caribou> apw: you know how support engineers like pain...
<apw> heh they do indeed
<caribou> apw: I have a Natty server available; I'll try to rebuild the kernel on it and see if there is a difference
<apw> caribou, you'd need to find out what kernel the buildd that ran on was running, and get a chroot which represents the chroot which was there on that day
<apw> and even then you'd not be guarenteed to make anything the same
<arges_> make sure toolchain was at the same version
<caribou> apw: yeah, I know. Which is why keeping the ddebs around is so important
<caribou> apw: arges_ well they were the ones used by you guys when you built the Natty official kernels
<caribou> apw: arges_ does it worth opening a new bug for this ? Maybe systemtap should take that into account ?
<apw> caribou, i don't think systemtap can take into account "you don't have reliable ddeb offset infromation for your running kernel" its black and white, its either right or its not
<caribou> apw: yeah, right. Shouldn't build broken contexts into the tool. Agree
<smoser> smb, around?
<smb> smoser, yes
<smoser> potentially stupid question.
 * smb likes those
<smoser> i'm looking at https://bugs.launchpad.net/nova/+bug/832507
<ubot2> Ubuntu bug 832507 in nova "console.log grows indefinitely" [Medium,In progress]
<smoser> i just launched a kvm guest, and did:
<smoser>  sudo dd if=/dev/zero bs=1M count=4 of=/dev/console
<smoser> 4194304 bytes (4.2 MB) copied, 43.3846 s, 96.7 kB/s
<smoser> so, it seems that /dev/console is limited (for my kvm instance) at < 100kB/s
<smoser> kvm process seems pegged handling that.
<smoser> (cpu pegged)
<smoser> the concerning thing to me is that the kernel writes data on boot at a rate not far off that
<smoser> ie, in the console log that i have (http://paste.ubuntu.com/1042460/), the kernel wrote that ~15k in .75 seconds.
<smoser> that woudl seem to indicate to me that
<smoser> a.) a fair amount of cpu resources during my bootup were spent in kvm reading the console writes
<smoser> b.) the kernel potentially blocked and waited some time on those writes
<smoser> i'm hoping/expecting that you can tell me that 'b' is not true, that the printk messgaes writing would not block anything else really.
<smoser> smb, ^
<smb> smoser, Not sure I know the whole chain from the top of my head. But printk's first go into the kernel ring buffer
<tgardner> smoser, smb: isn't it syslog that pulls out the dmesg ?
<smoser> tgardner, well this is to /dev/console specifically
<smoser> ie, 'console=/dev/ttyS0' or 'console=/dev/console'
<smb> tgardner, I think that is for the files in /var/log
<smoser> i did not think that syslog was involved there.
<tgardner> ok, likely not
<smb> But I think there is something else to send them to consoles...
<smb> (asynchronously)
<smb> apw, Would you know that from your head? ^
<apw> right there is a bit of printk which pumps out the pending bits if there is a 'console' attached to dmesg
<smoser> so probably 'b' is not a terrible concern. ie, those writes are not going to slow down boot
<apw> if you have a slow serial it can indeed slow down boot if its attached to dmesg
<tgardner> smoser, I wonder what happens if the console backs up
<apw> the backlog gets emitted when the console gets attached
 * ogasawara back in 20
<herton> tgardner, I'm going start to apply here 3.0.34/3.2.20 to oneiric/precise master-next
<tgardner> herton, ack
<tgardner> herton, I did just push precise master-next, so you should refresh first
<herton> tgardner, ok
<smb> smoser, So it looks like printk  tries to output to the console(s) first but can go (and leave things in a buffer) if the lock cannot bet taken... So I would read that as the boot is not slowed down...
<smoser> yeah, at least not significantly.
<smoser> thanks
<jodh> Could someone confirm that a debugger process (with >=1 children being ptraced) loses ptrace rights if *it* execs.
<jodh> I may be off track, but since fs/binfmt_elf.c:load_elf_binary() eventually calls ptrace_unlink(), I believe such a process does lose knowledge of its debugees.
 * smb` thinks it is about time drop
 * cking agrees with smb
 * cking --> EOD
<arges> tgardner, fixed up that pull request .. let me know if there are other issues
<tgardner> arges, you reposted on the list ?
<arges> tgardner, yea
<tgardner> arges, while the ssh:// patch works for me, its not very helpful for non-Canonical emps. I prefer that you use the git:// form of the path (but I've pulled anyways)
<arges> tgardner, shoot
<arges> tgardner, meant to use that
<jsalisbury> arges, s/shoot/darn/   Tim's from Montana ;-)
<tgardner> arges: also, its BugLink, not BugFix in the commit log. you can use kteam-tools/maintscripts/maint-modify-patch to slam in bug numbers, acks, etc.
<arges> jsalisbury, heh
<arges> tgardner, ok will use that from now on
<arges> tgardner, should i resubmit it?
<tgardner> arges, nah, I'll fix 'em up when I get a second ACK
<arges> tgardner, ok. thanks.
 * arges takes some notes.
<bladernr_> I feel silly for asking this, but can someone point me to a means to get the Precise kernel installed on a Lucid system?
<jsalisbury> bladernr_, you can get the .debs from: https://launchpad.net/ubuntu/+source/linux/3.4.0-5.11
<jsalisbury> just look under "Builds" for your arch
<bladernr_> ahhh... cool, thanks.  I was looking for a backports package but the latest available is oneiric
<bladernr_> jsalisbury: thanks!
<jsalisbury> bladernr_, whoops thats quantal, precise can be downloaded from:
<jsalisbury> https://launchpad.net/ubuntu/+source/linux/3.2.0-25.40
<bjf> bladernr_: we don't backport one LTS to another
<bladernr_> bjf: ahhh, that would explain it :)
<tgardner> bjf, thats just for the last LTS cycle. we'll eventually backport 14.04 to 12.04.
<bjf> tgardner: whatever you say
<arges> herton, hello. i see your comment about my pineview cherry pick... do you need me to rebase and reapply to and test?
<arges> to lucid
<herton> arges, no, not needed, it was a message more to tgardner when he is going to apply it
<arges> herton, ok in the future, should i be basing my SRUs against master-next instead of master?
<herton> arges, preferably yes, although hardly we could get some clash I think (something that applies to master but not master-next)
<arges> ok noted.
 * ogasawara lunch
<luca> Hi! I reported this bug #997767. Anyone who can advise on what I can do?
<ubot2> Launchpad bug 997767 in linux "10ec:8139 Network connection rtl8139 lost after some hours of inactivity and comes up again on user interaction" [Medium,Incomplete] https://launchpad.net/bugs/997767
<bjf> luca, i'll add a comment to the bug
<luca> bjf: Thanks. I don't want to bother you guys. Just want to know if I can do anything. Nothing seems to solve, not even recovery mode.
<bjf> luca, unfortunately, friday afternoon is a bad time to pop into the channel and ask for help. what timezone are you in?
<luca> bjf: I know that, sorry, I'm GMT+2:0 but I work during the day so I can only work on this in my free time.
<bjf> luca, wasn't intended as a criticism, just stating the obvious
<luca> bjf: yes, I understand, just giving a try :-) thanks for your help!
<bjf> luca, is it about 1am where you are right now ?
<luca> bjf: yes, 1am now.
<bjf> luca, what i'd suggest is on monday after you get home from work or whatever, there will be a lot of folks around that live in the U.S.
<bjf> luca, several of them have a lot more experience with wifi issues than i do
<bjf> luca, i could help you bisect your kernel but i'm not convinced that is the issue
<luca> bjf: not wifi here, just old eth. Anyway thanks! I'll try on monday then! Yes, I don't think that either. Older kernel should work I guess...
<bjf> luca, i'm not saying it's not a kernel issue
<bjf> luca, sorry i didn't get that
<bjf> luca, you were running oneiric just fine with no issues?
<luca> bjf: yes
<luca> bjf: never had an issue.
<bjf> huh
<bjf> and now you've updated, have the issue. even if you run the oneiric kernel on your precise install
<luca> bjf: exactly
<luca> bjf: tested many times.
<luca> bjf: I'll test again with a live CD of 12.04 and 11.10 and see what happens. I don't have any other idea. recovery mode fails as well so I don't know what might be the cause.
<bjf> luca, some of what you describe makes it seem like a userspace isssue
<bjf> luca, please do come back monday and we'll try to help you out
<luca> bjf: yes, but I don't know exactly what recovery mode runs. Thank you very much!
<jwi> luca: when testing the latest mainline kernels, did you also install the linux-image-extra-* package?
<luca> jwi: no, should I?
<jwi> luca: yes - this is most likely what's causing the boot failures.
<luca> jwi: then I'll test again installing that as well. Thanks!
#ubuntu-kernel 2012-06-17
<Logos01> Alright, since #ubuntu couldn't help me as it was 'too technical' a question... does anyone here know where I'd get the kernel sources package for the 3.5.0rc3 kernel version?  I'm trying to install it from http://kernel.ubuntu.com/~kernel-ppa/mainline but my nvidia graphics driver keeps erroring out (dkms)
<hyperair> i don't think getting the kernel sources would help
<hyperair> dkms is for out-of-tree modules.
<hyperair> if nvidia's erroring out, that means you'll just have to wait until nvidia updates its kernel module to work with 3.5.0
<Logos01> Yeah, the problem is that it needs the kernel source for it to compile against a specific kernel version if it's not using dkms.
<Logos01> That's pretty normal.
<Logos01> But I don't *HAVE* that source.
<Logos01> So that leads me back to my question.
<Logos01> ... really? Nothing?
<dileks> Logos01: http://www.youtube.com/watch?v=19jUboon5gI
<Logos01> And how.
<Logos01> But that doesn't help me now.
<hyperair> Logos01: use the headers as the source.
<Logos01> hyperair: I already have the headers package installed.
<Logos01> I need the linux-source package...
<hyperair> right, just point nvidia at /usr/src/linux-headers-$version/ for the soruce directory.
<hyperair> and just for the record, if it's failing in dkms with the new kernel, it'll probably fail during manual compilation as well
<hyperair> unless you're getting a new nvidia release
<Logos01> Yeah, see, that's the problem here. It's failing because it can't find the source, or so claims the dpkg -i linux-*.deb I'm running after having pulled the 3.5.0 *.debs down to my working dir.
#ubuntu-kernel 2013-06-10
<janimo> apw, hi, do you know if switching an ARM build (nexus 4) from sparsemem to flatmem model could introduce bugs ?
<janimo> I am not sure whether there's just performance differences between the memory models or correctness can be affected
<janimo> this is in the context of a cgroups bug that seems to be worked aorund if we chose the flatmem path
<apw> janimo, it shouldn't make a difference in theory, but as always YMMV
<apw> as in theory this is a single memory device, so in sparsemem is a 'flatmem' degenerate case, in theory
<janimo> apw, thanks.
<apw> janimo, then again i would be suspicious as to how flatmem could fix anything in cgroups by anything other than luck
<janimo> apw, there are two separate codepaths for memcg (initialization at least) for these two configs
<janimo> the sparsemem one skips initializing two of the five blocks of the nexus 4
<janimo> so when there's an acces to any of them there's a fault
<apw> so can we not just fix it
<janimo> apw, I sent my findings to the3 cgroups ml and got no answer, and then to ubuntu-kernel
<janimo> and a few minutes ago to arm-kernel
<janimo> I am not sure I ahve a fix, or what it would look like
<apw> this of course is the problem of basing ones security model on a feature in the kernel which is only just being finished in 3.10/11 and then using 3.1/4 kernels on your devices
<apw> it is always going to hurt
<janimo> the code looks the same in newer  kernels IIRC
<janimo> option names got changed and other fixes done. But cannot be sure as there's no new kernel to test on the nexus 4
<apw> nor will there ever be i am sure
<janimo> and most other arm boards do not have such unusual phsyisical memory layout
<apw> how unusual is it, as if it is very sparse there will be costs to switching in terms of size of th e cmap
<janimo> apw, right that is the drawback I saw, maybe around 1M overhead
<janimo> but that is not a correctness issue so expected
<janimo> apw, there are 5 blocks IIRC
<janimo> discontiguous I mean
<janimo> apw, I keep hoping that once there;s a tegra multiARM kernel and tegra3 upstreamed, forward porting older android kernels may not be that hard
<janimo> but I may be missing something big
<apw> janimo, maybe but i don't see it happening for these throw away devies
<janimo> apw, not officially from google, for sure
<apw> the devices will be on the scrap heap before it is easy
<apw> lets hope the next generation are on something less pants
<apw> tseliot, yo ... we have a working 3.10 kernel so we can start dkms testing against it: https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+packages in the saucy pocket
<tseliot> apw: excellent, I'll run some tests and fix what doesn't work
<apw> tseliot, excellent thanks
<apw> tseliot, wahts in there now is -rc3, there is a -rc4 in the queue to build as well
<tseliot> apw: ah, even better
<apw> though it looks to be FTBFS'ing ...arg
 * apw respins ... bah
<tseliot> apw: it FTBFS, at least on i386
<tseliot> something wrong in the configuration perhaps?
<tseliot> apw: shall I use this one instead? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc5-saucy/
<apw> tseliot, ok i am all confused, there is -rc4 in the PPA already, and -rc5 is building
<tseliot> apw: if I try to dist-upgrade it gets 3.9.0-4 instead of 3.10
<apw> tseliot, right, ... there is no meta in there for it
<apw> manual install for the moment
<tseliot> apw: oh, right
 * rtg_ reboots gomeisa
 * rtg_ reboots tangerine
<infinity> smb: Your linux-ec2 tracking bug might want some verification-testing love.
<infinity> smb: (Which could be an opportune time to offer a trade in the form of bugging me about your sponsorship URL again, wherever that went)
<smb> infinity, Hm yeah maybe though thats done by qa isn't it?
<infinity> smb: No, v-testing is done by you / the kernel team.
<infinity> smb: Not the same as regression testing.
<infinity> smb: Basically just amounts to making sure everything on http://status.qa.ubuntu.com/reports/kernel-bugs/reports/sru-report.html has a checkmark next to it, making sure that checkmark is accurate for your flavour, and setting the task done.  Ish.
<infinity> Well, rather, s/evetything has a checkmark/nothing has an exclamation point/
<smb> Hm, I am a bit surprised by that, which means I never had that before, so let me check up on that.
<infinity> Since tracking and security bugs are unique snowflakes.
<smb> infinity, For the other thing I am just typing something on #ubuntu-devel... :-P
<infinity> smb: Probably someone (like me) has just been setting your v-done tasks done in the past because ec2 was a straight debase and had no flavor-specific bugs listed.
<infinity> smb: Oh, I guess it has none this time either, all those ones are for the master kernel.  They're just kinda ec2-related.
<infinity> smb: So, there may be nothing to do there but twiddle the task anyway.
<smb> infinity, Yeah, let me make sure. I think there was nothing specific and I may even have booted the thing on my systems
<infinity> smb: There was nothing specific, I'm going to twiddle that task for you anyway.
<infinity> smb: Which will then move on to regression-testing and such.
<smb> infinity, Ah ok. Ta
<rtg_> apw, smoke testing 3.10-rc5. have you gotten any feedback on dkms compatibility ?
<infinity> smb: Right then.  Bug progressed.
<apw> rtg_, i have uploaded the rebase and tseliot is on the case
<apw> (to pre-proposed)
<rtg_> apw, ok, will do a bit more HW testing. 
<tseliot> right
<apw> rtg_, oh and note i brown-paper-bagged the changelog for the updateconfigs entry ... sigh
<apw> it really is -rc5
<rtg_> apw, I assumed ...
 * apw probabally should have stayed in bed
<smb> apw, Isn't that a given on any Monday?
<apw> you are very astute
<rtg_> apw, thought I'd upload mako with CONFIG_BT_HCISMD=y while I sort out perf (which is proving to be a bit of a PITA)
<apw> rtg_, yeah i recon that is reasonable
<infinity> apw: We could take a vote to make it not Monday.
<infinity> apw: Or maybe strike until Tuesday.
<smb> infinity, In which case Tuesday became alternate Monday and we had to go on strike again... 
 * smb likes that thought
<xnox> apw: i fixed cryptsetup's initramfs hook here not to add itself into initramfs if there are no encrypted root or resume devices. But that only makes a different if one has MODULES=dep, because otherwise "a basic subset of modules" is added anyway which are quite large.
<xnox> Why do we have "most" instead of "dep" by default?
<xnox> the images I guess should be built with "most" but the installed systems could be using "dep"
<xnox> infinity: am I missing something about reasoning to default to $MODULES=most in initramfs?
<apw> xnox, yep and my quick look at the boot speed tests showed it was better again today
<apw> though i have yet to see it appear in the official graphs which are days behind
<infinity> xnox: Because 'dep' hasn't always been historically guaranteed to be correct, but 'most' works for pretty much everyone.
<apw> xnox, the current reasoning is that the initramfs is 'disk independant' so we can move the disk from machine to machine and it will still work
 * xnox also is waiting for the new bootcharts.
<infinity> xnox: Oh, and what Andy said, 'most' makes initrds portable between machines.
<apw> now pitti and i had some discussions about what we do put on there, i think we could justify ripping out a goodly chunk more of the stuff in there, and still be disk portable
<infinity> xnox: I'm not sure what you mean by "that only makes a difference if..." though.  Surely, not adding cryptsetup also avoids adding plymouth, and solves the general complaint?
<infinity> (Though, I've been arguing for a while that we should just have plymouth by default in the inirtd, if only we could speed it up a tad)
<infinity> Having two very different boot paths for plymouth is hard to debug.
<xnox> actually it looks like plymouth is in by default =/
<xnox> as I don't have cryptsetup in my current initramfs, yet plymouth is still there.
<infinity> That should only be true if you have a FRAMEBUFFER=y setup.
<infinity> Unless something changed again recently...
<xnox> infinity: hm. ok let me check.
<xnox> apw: the question is should we include "cryptsetup" in the definition of portable between machines initramfs. Cause at the moment - installing a cryptsetup package and not using any encrypted filesystems results in most crypto modules in the initramfs, yet those are actually only required to boot encrypted root fs.
<xnox> imho - encrypted machines are "speciality" rather than "common/portable"
<apw> xnox, the disk is either encrypted or it is not
<apw> xnox, if _that_ disk is ecrypted (root disk) then the initrd for it needs to include them to be portable, if it is not then it does not
<apw> xnox, we are not trying to make it 'dd from one disk to another' portable i don't think
<xnox> apw: I agree. In that case, I'd like to propose to not include cryptsetup & modules in the initramfs if root disk is not encrypted. Regardless of MODULES=dep/most. For the case of "I want to generate initramfs on this machine, to transfer/boot that one" i'll add an option to include cryptsetup things unconditionally.
<apw> xnox, yes please
 * apw prepares to reboot to save his fans
<infinity> apw: 1188647?
<apw> bug #1188647
<ubot2`> Launchpad bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,In progress] https://launchpad.net/bugs/1188647
<infinity> apw: As in, is that why you're rebooting to save your fans?
<infinity> (cause my fans were on 24/7 before I twiddled that)
<apw> heh no i have a much crappier machine than that, did i give you your test kernel
<infinity> apw: Nope, you gave me no test kernel.
 * cking reboots
<apw> infinity, this should just have the enable off by default and an =enable to turn it back on: http://people.canonical.com/~apw/lp1188647-saucy/
<apw> infinity, if you could test that and let me know
<infinity> apw: Can do.  Want me to test both conditions to make sure it does what it says on the tin?
<apw> infinity, would be helpful indeed if you could
<infinity> apw: Alrighty.  I'll follow up to the bug in a bit.
<apw> ta
<infinity> apw: Updated.
<infinity> apw: TL;DR: It's all good.
 * rtg_ -> lunch
 * xnox looks at bootcharts and it returned back to normal on 20130606.1, yet the fix was uploaded on 20130607 ........
<SonikkuAmerica> I assume linux-3.9 is on its way soon?
<SonikkuAmerica> (For Raring)
<infinity> SonikkuAmerica: No, raring is 3.8
<infinity> SonikkuAmerica: We don't do new upstream versions in stable releases.
<SonikkuAmerica> infinity: Oh. That stinks, 'cuz they just announced 3.8 is EOL. I guess we won't need it for that long anyway, given it's only supported till January
<infinity> SonikkuAmerica: We're supporting 3.8 until raring goes EOL.
<SonikkuAmerica> infinity: Ah. Now that's a good idea. :) Thanks!
<bjf> SonikkuAmerica, we are supporting the raring kernel until 14.04.01 (which is around Aug. of 2014)
<SonikkuAmerica> bjf: Ummm... you mentioned a date in April. :)
<SonikkuAmerica> bjf: August 2014 is 14.08
<infinity> SonikkuAmerica: He means the 14.04.1 point release, which will be after 14.10 releases.
<bjf> SonikkuAmerica, 14.04 is april, 14.04.1 is Aug.
<SonikkuAmerica> infinity: OK. Makes even more sense.
<infinity> (Not that we'll be supporting raring itself that long, so this doesn't really matter for you)
<infinity> It just matters if you're using our upstream tree, or precise with the lts-raring kernel.
<infinity> bjf: Wait, why would we be supporting lts-raring until .04.1?
<SonikkuAmerica> (I interpreted that as a date 2014.04.01... :P) Right. By that time I'll be well into 14.04
<infinity> bjf: Surely, it's lts-saucy we need to support until then.
<SonikkuAmerica> Well I gotta go, thx for the info! Bye!
<bjf> infinity, we support all precise lts-hwe kernels until the first point release of 14.04
<infinity> bjf: Oh, that's going to be... Fun.
<bjf> infinity, why, it's just a few months difference
<infinity> bjf: But it's no longer a backport once the parent releases go EOL.  I guess that's not a big deal.
<bjf> infinity, it comes out of the same git repo
<infinity> Yeah.
<bjf> infinity, you just won't accept new uploads to raring
<infinity> We lose some of the benefit of moving to a 9-month support cycle if you have to support all the interim kernels until LTS+1.1 anyway.
<bjf> this really only affects the kernel and possibly x stack
<infinity> Yeah.  I just wish we'd gone with a "stable series" and "hwe series" instead of "hwe series x 3 (or 4?)"
<infinity> It spreads things a bit thin as far as end-user configurations and troubleshooting sanity.
<infinity> Will we bit doing an lts-t kernel for P, so people who installed with, say, lts-r because 3.2 didn't support their hardware aren't suddenly left unsupported in their supposedly 5-year LTS?
<infinity> s/we bit/we be/
<bjf> infinity, yes
<infinity> Kay, at least that bit makes sense.
<rtg_> infinity, still about ? Can you tell me what happened here ? https://launchpad.net/ubuntu/+source/linux-maguro/3.0.0-2.3/+build/4659648
<infinity> rtg_: Pandas suck.
<rtg_> infinity, can I restart, or increment version and reupload ?
<infinity> rtg_: Retrying the build.
 * rtg_ -> EOD
#ubuntu-kernel 2013-06-11
<apw> smb, moin, can you remember the bot-stop- tag name
<apw> ppisati, moin
<smb> apw, The thing about robots.thingy
<ppisati> moin moin
<apw> tseliot, i see that 3.10-rc5 kernel finally built, how did the dkms hacking go
<tseliot> apw: I have started working on nvidia. It's going to be a rather invasive patch because of some changes in the kernel
<apw> tseliot, nasty ...
<tseliot> apw: yes, I have to switch to proc_create_data and proc_create, among other things
<tseliot> I bet it will be the same for fglrx and broadcom
<ppisati> brb
<bjf> apw, should be bot-stop-nagging
<apw> bjf, ta
<rtg_> apw, any objection to uploading saucy rebased on v3.9.5 today ? 3.10-rc5 still doesn't have aufs support, so I'm not sure we should be switching over just yet.
<apw> rtg_, none, tseliot was having some trouble too, so i thin 3.9.5 is a good place to be
<rtg_> apw, k, I'm just about done compile and smoke testing.
<apw> rtg_, do you want me to do it, or are you already ... ok then
<rtg_> apw, have you tested overlayfs in 3.10 yet ?
<tseliot> apw, rtg_: yes please, I'm not done fixing the drivers yet
<apw> rtg_, i am playing in that sandbox right now, not tested that specific combination but that is about to be a sane test
<infinity> BenC: You want to do some install/reboot/fiddle testing of the PPC kernels in raring-proposed on some of your hardware?
<rtg_> apw, aufs hasn't been updated since march, so we might end up dropping it completely if it is no longer maintained.
<apw> rtg_, they will be pleased :)
 * infinity will mourn the loss of aufs.
<infinity> Though, if the overlayfs/inotify argument ever amounts to anything, I might stop caring.
<ogra_> so on the flipped container touch images i get a reboot loop on grouper (all other subarches seem to work and i can boot past the failure point using the grouper desktop kernel)  ...
<ogra_> http://paste.ubuntu.com/5754882/
<ogra_> i assume it is the "Warning: unable to open an initial console" that makes init die ... any obvious idea how i could get that console (without having to enable fbcon which will break the android container)
<ogra_> (teh kernel panic happens right after run-init switched us to upstart)
<rtg_> ogra_, I'm not seeing an FBCON option for grouper. CONFIG_FB=y and CONFIG_FB_TEGRA=y are set.
<ogra_> well, it is there since we use it on the desktop kernel ... 
<ogra_> might depend on something else thats off as well
<ogra_> but fbcon isnt an option anyway 
<ogra_> it would break the android container
<rtg_> ogra_, does saucy grouper still work on the desktop image ?
<ogra_> i tried randomly setting CONFIG_VT and stuff, but didnt get much further
<ogra_> well, the kernel is the same 
<ogra_> or at least largely ... 
<ogra_> just different configs 
<rtg_> ogra_, configs can make a difference
<ogra_> so for testing i can replace zImage in the bootimg we use for touch ... indeed it fails miserably later in the boot but it gets past the panic point
<ogra_> err, yes, i know, thats why i'm here :)
<ogra_> obviously the -nexus7 kernel has something enabled to make it boot ... which the -grouper one is missing ... 
<ogra_> my way to debug that is to enable options one by one and to do a test boot after a fresh build ... but thats very time consuming so i was hoping you guys have a better idea or see something thats obviously missing or so
<rtg_> ogasawara, lemme take a stab at diffing the configs
<ogra_> :)
<rtg_> ogra_, there are quite a few differences. http://kernel.ubuntu.com/~rtg/config.diff 
<rtg_> CONFIG_HW_CONSOLE looks suspicious
<ogra_> oh, yeah
<rtg_> ogra_, just pushed a patch to ubuntu-saucy grouper (CONFIG_VT=y). Can you give that a whirl ?
<ogra_> sure
<ogra_> i have a call soon, so only afterwards
<rtg_> I'll flash my N7 with raring in the meantime to make sure it still works
<ogra_> but i think i tried with CONFIG_VT=y alone already 
<ogra_> CONFIG_HW_CONSOLE sounds more plausible
<rtg_> ogra_, the whole patch has several more console options enabled
<ogra_> ah, k 
<tseliot> apw: does 3.9.5 have this commit? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=80e928f7ebb958f4d79d4099d1c5c0a015a23b93
<apw> tseliot, not obviously
<tseliot> apw: ok, just checking
<apw> tseliot, i cannot see it by sha reference or title, so very likely not
<apw> tseliot, something you need
<tseliot> apw: no, something that breaks the driver
<Roberth1990> hello how do I get BFS and BFQ?
<apw> Roberth1990, i suspect we need a little more context to have any hope of helping you.
<Roberth1990> they are a part of the ck patchset for the kernel
<Roberth1990> which is there again a part og zen and pf patchsets
<apw> if it is part of ck, then its not something we have any trees for, you'd have to apply it yourself
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<apw> hallyn, yo ... bug #1098378 ... test kernels in the bug, if you could check them out and report back
<ubot2`> Launchpad bug 1098378 in linux (Ubuntu Raring) "chroot+overlayfs seems to cause umount mis-behavior" [High,Confirmed] https://launchpad.net/bugs/1098378
<apw> hallyn, and can you confirm this was new in raring, i think from the fix I expect it was
<smb> Daviey, That is probably outside the scope of the meeting but if you want dkms packages checked imo its up to you to provide a list of interest. And I cannot recall "all" being agreed anywhere ever.
<Daviey> smb: not agreed, but that is what i requested 
<Daviey> it seems easy enough to test all, as it does a handful.
<hallyn> apw: will look, thanks
<Daviey> And for a test that seems really cheap to run, it seems like a good idea to the ubuntu ecosystem to do
<smb> Daviey, Things are always easy when one has not to do it. :-P But anyway, I would say this is something the qa team will be responsible for anyway. So if they do, I won't complain.
<Daviey> smb: it sounded like it was already in progress, from jibel.
<smb> Daviey, It did, and plars just write that email. So we will see
<Daviey> smb: Have you spotted complexity to it that i have blissfully sailed over?
<ogasawara> Daviey: sorry to jump in here, but I've been chatting with jibel about automated DKMS package testing
<Daviey> super!
<ogasawara> Daviey: I actually have a meeting with him on thurs, he has something already prototyped for us to go through
<smb> Daviey, To detect the build failing probably is simple enough (beside resource and time). Just the question what is done with that
<ogasawara> Daviey: but if you can get me the list of dkms packages that your team is specifically interested in, I'll be sure they try to land on the list
<ogasawara> Daviey: initiall, it's just getting a quick build test to ensure they still build with major version bumps of the kernel
<ogasawara> Daviey: specific testing of the modules/packages beyond that would be something I'd consider phase 2
<Daviey> ogasawara: Right. Just validating that the dkms packages still cleanly install sounds super.
<ogasawara> Daviey: yep, that's my initial goal
<Daviey> I can get a list.. but as a ubuntu developer, i'd love all to be covered :)
<ogasawara> Daviey: indeed, and I suggested to him to to all the packages that rdepends spit out for dkms
<Daviey> ogasawara: I will make sure I have a favoured list.
<ogasawara> Daviey: great, thanks
<ogasawara> Daviey: I was assuming for you guys is was something like openvs and iscsitarget
<ogasawara> Daviey: not sure what else though
<Daviey> someone in server raised oss4-dkms as another... not sure why i care about that.
<Daviey> (HINT, i don't think i do)
<Daviey> openswan module is interesting, but not demanded
<Daviey> dahdi-dkms is a server universe package
<Daviey> openvswitch-datapath-dkms is the priority 
<Daviey> One of the real challenges we face is making these packages work on current development version of ubuntu, and precise (all supported kernels) concurrently 
<smb> That oss4 may have been somehow misguided, but that sort of gets me back to the point that a list (not on irc) of interest and to what degree would help
<infinity> ogasawara: `reverse-depends dkms` isn't a remarkably long list, I wonder if jibel could just test the lot?
<infinity> ogasawara: Obviously, we have a priority list of what we care about fixing first, but I want to know if any of them are broken, so we can decide to fix or remove.
<ogasawara> infinity: indeed, I was suggesting to him to just test the lot since it didn't seem incredibly large.  I've got a meeting on thurs to sync with him so I'm happy to bring up everything with him and circle back with you et al.
<ogasawara> infinity: or I can just add you to the meeting if you wanted to sit in
<infinity> ogasawara: You can add me, and I'll see how social I'm feeling when it rolls around. :)
<ogasawara> infinity: ack
<smb> infinity, and how awake... 
<infinity> And that.
<jsalisbury_> ##
<jsalisbury_> ## Meeting starting now
<jsalisbury_> ##
<jsalisbury> Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 18th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 18th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati -> gym
 * rtg_ -> lunch
<arges> has anyone here figure out how to upload .crash data from a kernel oops into a new launchpad bug? ubuntu-bug *.crash asks if I want to submit it but gives no feedback afterwards
<arges> ok looks like bug 994921
<ubot2`> Launchpad bug 994921 in apport (Ubuntu Quantal) "'ubuntu-bug /var/crash/app.crash' (and even more so, 'apport-cli -c /var/crash/app.crash') should still allow manual bug filing in stable releases" [Medium,Triaged] https://launchpad.net/bugs/994921
<apw>  2291 apw        9 -11  568m 5904 4792 S 200.0  0.1  1349154h pulseaudio                       
<BenC> infinity: Yeah
<apw> bjf, http://people.canonical.com/~apw/unstable-saucy/
<bjf> apw, ta
<davmor2> apw: I'm not sure I want to work too close to you now I see you are unstable and saucy ;)
<apw> davmor2, :)
<infinity> BenC: Kay, I already marked it passed for regression-testing based on my own testing, but do let me know if it breaks for any of your platforms, so we can revert that. :P
<BenC> infinity: it worked when I built it, so should be good. I'll let you know if otherwise.
<infinity> BenC: Compiler bugs and bitflips happen.  There's also the possibility that I effed up the checkout.  Better safe than sorry. :)
<infinity> BenC: Alternately: "It works on 750, 970, POWER5, and POWER7, so sucks to be you if your flavours don't work, nyah nyah." ;)
 * rtg_ -> EOD
#ubuntu-kernel 2013-06-12
 * apw yawns
 * smb waves
<smb> ... and leaves to get more coffee
 * apw makes tea
<ppisati> diwic: i hit again the 'crackling noise'&c problem this morning
<ppisati> diwic: but with mumble this time
<ppisati> diwic: what was the status of the fix for R?
<diwic> ppisati, okay, with PA 3.0 or 3.99/4.0 ?
<ppisati> diwic: vanilla raring
<ppisati> 1:3.0-0ubuntu6
<diwic> ppisati, I made a package with the fix arun thought was right, uploaded to a ppa and asked people to test. No replies.
<ppisati> diwic: doh!
<ppisati> diwic: where is it?
<ohsix> ubuntu-audio-dev ;D
<diwic> ppisati, bug 1173073 comment 6
<ubot2`> Launchpad bug 1173073 in skype (Ubuntu) "Broken sounds in Skype" [Undecided,Confirmed] https://launchpad.net/bugs/1173073
<ppisati> diwic: let me try it
<ppisati> diwic: i guess i need to logout, right?
<diwic> ppisati, restarting pulseaudio is better, sometimes a logout/login doesn't trigger pulseaudio to restart
<diwic> ppisati, pulseaudio -k
<ppisati> smb: make some noise when you are back
<ppisati> diwic: i restarted
<ppisati> diwic: so far, skype is mute
<ppisati> diwic: can't hear anything from it
<smb> ppisati, I am making "noise"
<ppisati> smb: now?
<smb> yes
<ppisati> smb: oh, i saw the lips
<ppisati> diwic: ok, the new pulseaudio has defaned my system
<diwic> skype is mute, but the lips refer to mumble?
<ppisati> diwic: i have the 'cracking noise' problem with both skype and mumble
<ppisati> diwic: hence i was trying both
<ppisati> diwic: ok, actually my system is mute now
<ppisati> diwic: since it don't emit any sound through skype/mumble
<ppisati> diwic: i can still play a song
<ppisati> diwic: but no mumble/skype
<ppisati> :(
<diwic> ppisati, hrm
<diwic> ppisati, you restarted mumble/skype with the new pulseaudio too I assume?
<ppisati> diwic: http://paste.ubuntu.com/5757463/
<ppisati> diwic: i rebooted the box
<ppisati> ah!
<ppisati> skype has just emitted the first beep
<ppisati> and now it's like in a torturing loop
<ppisati> smb: can you hear me?
<diwic> ppisati, uhm
<smb> ppisati, no
<ppisati> smb: :(
<smb> fixed to death
<ppisati> restared skype since it was driving me crazy
<diwic> ppisati, pacmd set-log-level 4, then try skype or mumble (not both simultaneously!). Is there something interesting in /var/log/syslog ?
<smb> ppisati, see lips, hear nothing
<ppisati> diwic: http://people.canonical.com/~ppisati/pulseaudio_syslog
<apw> diwic, am i expecting outputs and inputs to be lost over s/r in raring now ?
<diwic> ppisati, okay, so endless streams of rewinds, exactly what the patch was supposed to *fix*, not *cause*
<diwic> apw, could you elaborate?
<ppisati> life is unfair... :(
<diwic> ppisati, but that patch is in 4.0 too, so I guess I should test mumble on 4.0 and see if it still works
<apw> diwic, by which i mean my i have external mic and speakers on USB and over s/r they used to remain the 'selected' outputs, now the defaults switch back to the internals every time
 * ppisati goes back to vanilla PA
<diwic> ppisati, anyway roll back for the time being
<diwic> apw, well, it's probably due to a race between PA and the kernel, so it can change between Ubuntu versions.
<apw> diwic, ok s/r is possibly slower right now, so that probabally accounts for it
<diwic> apw, last time I asked somebody it was not possible to tell when the kernel has finished probing hardware
<diwic> apw, but perhaps you know better?
<apw> diwic, pretty much not if it is usb
<diwic> apw, essentially, when PA resumes, usb sound appears no longer connected
<apw> though one could listen on the udev events and as things appear if they are what i thought the default was before we could reinstate it
<ohsix> are uevents for the device sent before it can actually be used?
<apw> ohsix, i think the conjecture here is PA wakes and scans on 'whats still here' while the devices are still being scanned
<diwic> apw, you mean a rule based ordering? Intel says they have something they want to upstream. We've been waiting for half a year for that.
<ohsix> apw: it seems to race plugging in unrelated to suspending and stuff too; i've been operating ounder the assumption that you would be able to actually use the device by the time udev knows about it
<apw> diwic, well i mean, whoever has the 'current default output' would wake up and say 'ahh crap the default is gone i supposed i'll change to the remaining thing', then later when the other device appears based on an event it could say 'oh look that is where my real default is meant to be, lets switch back transparently'
<ohsix> that is what happens if the thing actually goes away
<ohsix> barring interference from the desktop mixer applet :>
<diwic> apw, right, and that can be extended to a list of devices, add to that different routes for roles and programs, and you have the big routing problem <tm>.
<apw> diwic, well i am only really saying we should remember the 'users preferred default' for each
<ppisati> ok, so
<ppisati> i rolled back to 1:3.0-0ubuntu6
<ppisati> but still can't hear anything
<ppisati> :(
<ohsix> fuser -v /dev/snd/*
<diwic> apw, and we have been promised to get all that and more with Intel's routing system which we have been waiting for since October or so
<ppisati> ok, i've sound back
<ppisati> but still noises/crackings
<ppisati> etcetc
<ppisati> diwic: my previous 'muting' problem
<ppisati> diwic: was because it selected the digital output
<ppisati> diwic: intead of the analog one
<ppisati> diwic: i'm on analog now + your ppa bits
<ppisati> diwic: but there're still problems
<diwic> ppisati, so essentially, what you're saying *now* is that the ppa makes no difference?
<ppisati> diwic: well
<ppisati> diwic: it's a bit better
<ppisati> diwic: i can hear cking and apw ok now
<ppisati> diwic: but if i start the dummy skype voice call test
<ppisati> diwic: everything craps out
<diwic> ppisati, and what was the skype voice call test before the ppa ?
<ppisati> diwic: uhm
<ppisati> diwic: wasn't working iirc
<diwic> ppisati, so no regression at least, what about the event sounds that the original bug was about?
<ppisati> diwic: it's a bit better now
<ppisati> diwic: no noises are not constant
<ppisati> diwic: i can hear the other people on mumble quite ok
<ppisati> diwic: had some noises when i started mumble, but it's ok now
<ppisati> diwic: ok, skype is mute again
<ppisati> :(
<ppisati> while mumble is ok
<diwic> maybe I should try and see if I can reproduce it here
<ppisati> diwic: if i can help you in any way, let me know
<diwic> ppisati, when you say "skype is mute", does that refer to event sounds, the call stream or both?
<ppisati> diwic: it's mute in general
<ppisati> diwic: nothing comes out of the speakers
<ppisati> diwic: but when it does
<ppisati> diwic: it's either noise
<ppisati> diwic: or a constant loop of a beeeeeeep
<ppisati> diwic: do you want access to this box?
<ppisati> diwic: i can fwd a port if you want
<ppisati> let me see if syslog says anything when it craps out
<diwic> ppisati, I'll first try setting up skype on raring and giving it a test to see if it works or not here
<ppisati> diwic: try setting up mumble and skype
<cking> apw http://www.maximintegrated.com/app-notes/index.mvp/id/3958
<ppisati> diwic: join a mumble channel with people speaking
<diwic> ppisati, simultaneously?
<ppisati> diwic: and then try to make skype emit any sound
<ppisati> diwic: yes, simultaneously
<ppisati> diwic: looks like it's easier to trigger it this way
<diwic> hmm, when searching for skype in USC, all I get is magazines in german.
<ppisati> diwic: ok, i was able to reproduce the noise-loop
<ppisati> diwic: and here is syslog
<ppisati> diwic: http://people.canonical.com/~ppisati/pulseaudio_syslog_again
<ppisati> diwic: at the end, then i -k pulseaudio
<ppisati> brb
<diwic> ppisati, what's the recommended method to install skype?
 * diwic is listen in on mumble, sounds good 
<diwic> ah, found it
<diwic> ppisati, ok, now I did a skype test call while listening to the mumble chat, worked just fine
<diwic> ppisati, that's with raring's PA.
<ppisati> diwic: in my case, skype test calls always fail (no sound output at all)
<ppisati> diwic: and it's really racy
<ppisati> diwic: sometimes you trigger it
<ppisati> diwic: sometimes it works
<ppisati> diwic: do you have contacs in skype?
<diwic> ppisati, maybe skype is hearing noise in the beginning of the call, when the voice talks ("welcome to skype call testing service"), it reduces the volume of itself because it thinks it's hearing the echo of itself
<ppisati> diwic: can i add you in skype?
<diwic> ppisati, diwic9 is my ID
<ppisati> diwic: when i login/logout, do you get the notification sound? is it ok?
<diwic> ppisati, yes, there are correct login/logout sounds from skype
<diwic> ppisati, btw, what are the CPU powers of your machine?
<ppisati> diwic: this is an haswell box
<diwic> ppisati, that should be okay I assume
<ppisati> diwic: how do i find out? cat /proc/...?
<diwic> ppisati, /proc/asound/card*/codec*, pick the one's that not HDMI
<diwic> s/one's that/one that's/
<ppisati> diwic: http://people.canonical.com/~ppisati/haswell_hda_codecs
<diwic> ppisati, ok
<diwic> ppisati, the syslog_again log, that's from with the ppa installed, right? 
<ppisati> diwic: yes
<diwic> [alsa-source] alsa-source.c: Scheduling delay of 0.08ms, you might want to investigate this to improv
<diwic> [alsa-source] alsa-source.c: Scheduling delay of 0.08ms, you might want to investigate this to improve latency...
<diwic> sure PulseAudio should survive with more than 80 us of scheduling latency :-) 
<diwic> probably a red herring though
<ohsix> it actually says that? what is it using to determine how it was scheduled?
<diwic> tsched watermark
<diwic> it's too low
<ohsix> oh, so not strictly scheduling
<diwic> ohsix, if real_sleep_time - tsched_watermark > expected_sleep_time then complain
<diwic> ohsix, hence the tsched_watermark is less than 80 us which is bad
<diwic> I think
<ppisati> brb
<jampo> Is "What does a specific Ubuntu kernel version number mean?" on https://wiki.ubuntu.com/Kernel/FAQ outdated? If this info is correct, then the linux-image-3.2.0-48-generic 3.2.0-48.74 package of 12.04 would be based on kernel 3.2.0. But on http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html 3.2.0-48.74 is mapped to 3.2.46.
<jampo> The Makefile in the current linux-source-3.2.0 (3.2.0.48.58) packages inside of /usr/src/linux-source-3.2.0/linux-source-3.2.0.tar.bz2 contains also 3.2.46 as the kernel version.
<jampo> I am confused.
<jampo> The last change of https://wiki.ubuntu.com/Kernel/FAQ was 2011-01-27. So I think it is outdated. And the version in the Makefile of linux-source-3.2.0 and the http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html mapping is the correct one. Correct?
<jampo> So the latest linux-image-3.2.0-48-generic (3.2.0-48.74) package for 12.04 is based on kernel 3.2.46?
<smb> jampo, No, the FAQ is correct. It is based on the release version of 3.2, but it also has the stable updates up to 3.246 included.
<smb> 3.2.46
<diwic> smb, would it make sense to then call it linux-source-3.2 instead of linux-source-3.2.0 ?
<diwic> smb, (without saying that doing so would be worth all the tooling changes required)
<smb> diwic, No, we went through that before. There was just too much historically depending on kernel versions having three parts
<diwic> smb, so it would make sense, but we avoid it due to all the changes required?
<smb> diwic, That would be my definition of making sense, actually. The 0 also makes sense in a way as spelling out it is the release version. Maybe there are other reasons as well which apw may remember
<apw> diwic, possibly, though changing the name might be tricky for the consumers thereof
<jampo> So linux-source-3.2.0 is not "based on" kernel 3.2.46 but "compatible with" it? If it would be "based on" then it would be really based on the v3.2.46 release tag of the kernel?
<diwic> smb, thanks. I didn't mean to drag up an old debate (if any) so I'm satisfied with the answer :-)
<smb> jampo, Look at it from debian packaging: the source package consist of a orig.tar.gz and a diff. And the tar is based on 3.2.0
<jampo> smb: Thanks for the pointer. I will check http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.2.0.orig.tar.gz now. :-)
<smb> jampo, Nowadays there will likely be most current stable updates applied, but that was not always the case and may be and the package number deliberately does not give any hint about what stable patches are included.
<jampo> Verified: the version in the Makefile of linux_3.2.0.orig.tar.gz is 3.2.0 and the uncompressed linux_3.2.0-45.70.diff.gz is huge.
<jampo> :-)
<jampo> One last missing thing: there is no v3.2.0 release tag in the git repository of the kernel: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?id=v3.2.0 and no tarball in https://www.kernel.org/pub/linux/kernel/v3.x/ Any way to find out the commit on which linux_3.2.0.orig.tar.gz is based?
<ohsix> it's an upstream package drop
<jampo> What does that mean?
<ohsix> it should be in there somewhere ;D
<jampo> From Debian.
<ohsix> from kernel.org, it's a release
<jampo> You mean it was released an then later removed?
 * ppisati goes for some food
<ohsix> jampo: i think so, yea
<ohsix> or hm
<jampo> I am stupid. :-)
<jampo> Maybe the tag is called v3.2?
<jampo> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?id=v3.2
<ohsix> there was no 3.0.x or 3.1.x, and only a 3.2-rc*, then, 3.2.1
<ohsix> that looks plausible :]
<jampo> That's nice, everything fits together now. Thanks for the clarification!
<ohsix> np, i remember what people did with 2.6._40_ instead of '3' but i guess i got bored shortly after
<infinity> apw: *pokity poke*
<apw> yo
<infinity> apw: Can you revert rtg's HAVE_CPLUS_DEMANGLE=n mess from the last linux and linux-grouper uploads?
<infinity> (If he committed it to other trees, revert those too, please)
<infinity> apw: It forces kernel uploads to be lockstep with binutils (and vice versa), which is pretty remarkably poop.
<infinity> apw: And the bug he was working around (libiberty.a being missing) was fixed by me last night.
<apw> in ack
<apw> infinity, do i need to upload or are we good where we are
<infinity> Shouldn't be an ABI bump, feel free to rapidly upload to undo the damage.
<apw> ack
<infinity> Otherwise, your kernel will never migrate, cause doko just pushed a new binutils. :P
<apw> infinity, ack
<apw> infinity, so the liberty change is in -proposed and published already
<infinity> apw: Yeahp, has been for hours.
<apw> infinity, these two fixes are non-abi-bumpers, so i am shoving them in with the revert
<infinity> apw: Shiny.
<infinity> apw: s/revert/reverts/ ... linux-grouper got caught in the crossfire here, too.
<apw> infinity, there is one revert on master, otheres elsewhere
<infinity> apw: (And you might want to check other HEADs to see if rtg lined up the same change for other flavours, but I'm hoping not)
<apw> rtg_ is going to handle the others once this builds
<infinity> Mmkay.
<apw> at least on x86
 * henrix -> lunch
<apw> infinity, ok in the hole
<infinity> apw: There's no way to interpret that that makes me feel good about that upload.
<infinity> apw: But I'm going to take the high road, avoid the sexual innuendo, and assume that you uploaded a grenade.
<apw> infinity, most likely :)  but ... what fun would that be
<rtg_> infinity, I think only grouper (so far) has the MANGLE issue with binutils. I can re-upload now ?
<infinity> rtg_: Please do.  It won't be blocking anything else, only itself, but if you wanted it in, it'll need an upload with that reverted.
<infinity> (linux was more urgent, cause it's a tangled mess of interdependencies)
<rtg_> infinity, ok, it'll be in the hole soon :)
<infinity> Damn you people and your holes.
<apw> infinity, we didn't want to fill them both at once, but you insisted
<infinity> ...
<apw> rtg_, that goes in ubuntu.pockets=proposed
<apw> ubuntu.pockets=proposed
<rtg_> apw,  line 15 [saucy-armhf-sbuild]: Unknown key 'ubuntu.pockets' used
<rtg_> apw, Can't open /usr/share/schroot/setup/common-config
<infinity> apw: You missed the matching linux-signed for your upload.
<apw> infinity, bandits, will fix now
<rsalveti> rtg_:  Depends: libc6 (>= 2.8), libdw1 (>= 0.143), libelf1 (>= 0.131), linux-maguro-tools-common
<rsalveti> rtg_: guess the flavor specific tool is depending on flavor-tools-common
<rsalveti> which is not yet available
<rtg_> rsalveti, ok, I'll check on it.
<rsalveti> rtg_: thanks
<rtg_> rsalveti, um, it may be because flavor-tools-common has not been promoted out of proposed yet ?
<rtg_> eh, that doesn't seem right eithetr
<rsalveti> rtg_: are we even creating such package?
<rtg_> rsalveti, don't think so. thats what doesn't seem right.ght be a typo
<rtg_> rsalveti, the binary package names should be linux-maguro-tools-common and linux-maguro-tools-3.0.0-2.3. checking on the meta package now...
<rtg_> rsalveti, the dependencies should be linux-maguro-tools -> linux-maguro-tools-3.0.0-2.3 -> linux-maguro-tools-common
<rtg_> is that not what you're seeing ?
<rsalveti> that's what I'm seeing, I just couldn't find linux-maguro-tools-common
<rsalveti> rtg_: who should be in charge of generating such package?
<rsalveti> the kernel itself?
<rsalveti> https://launchpad.net/ubuntu/+source/linux-maguro
<rtg_> rsalveti, yeah, its a binary generated by teh kernel
<rsalveti> even on the one from proposed, just linux-maguro-tools-3.0.0-2_3.0.0-2.3_armhf.deb
<rtg_> rsalveti, yeah, wtf ?
<rtg_> rsalveti, maybe its because that package is 'Architecture: all' instead of 'Architecture: armhf' ?
<rsalveti> rtg_: right
<rsalveti> rtg_: for all to be published we'd need a build for i386
<rtg_> rsalveti, cut-n-paste error
<apw> rtg_, yeah any all packages in a single architecture package normally are : <arch> instead so that i only builds on one arch
<rsalveti> rtg_: package still depending on linux-maguro-tools-common
<rtg_> rsalveti, yeah, still working on it. I think I've figured it out for grouper.
<rsalveti> rtg_: cool
<rtg_> rsalveti, its been kind of a PITA
 * rtg_ -> EOD
<anon^_^> hi had a question about the -lowlatency kernel.  There appears to be two project pages on launchpad with different builds, both headed by GaryM
<anon^_^> It makes it somewhat difficult to determine which package to use and why there are two project pages
<anon^_^> https://launchpad.net/ubuntu/+source/linux-lowlatency
<anon^_^> https://launchpad.net/ubuntu/+source/linux-meta-lowlatency
<maxb> anon^_^: 'linux' = the kernel source itself, that builds packages which have ABI versioning info which often changes embedded in their names; 'linux-meta' = the metapackages which pull in the latest specific versioned packages  (or at least that's how it works in the non '-lowlatency' case, I assume it's the same)
<anon^_^> so the safe route to go, stick with linux-meta builds which are used by default in the Ubuntu Repo
#ubuntu-kernel 2013-06-13
 * ppisati goes to update his laptop to saucy...
<ogra_> pfft ... laptop 
<ogra_> update your *phone* to saucy :)
<ppisati> ogra_: btw, out of curiosity, did we already choose how we will expose the internal of our mobile devices to the rest of the world? umass or mtp?
<ogra_> well, tvoss did rebuild the android mtp server under ubuntu using libc .... not sure we will actually use it though
<ppisati> ogra_: interesting, was it packaged?
<ogra_> not yet ... 
<ogra_> the prob is that M$ has it patented 
<ogra_> so that will require some more discussion
<ogra_> i personally prefer umass ... but that means to have a vfat partition in the back iirc 
<ppisati> actually m$ invented it (on top of pptp) but it was later standardized by the usb $whatever std commitee, and pretty much everyone is using it
<ppisati> ogra_: right, and vfat means royalties to be paid too
<ogra_> right, and paying the patent 
<ppisati> btw, my mtp experience in linux has been _really_ bad so far
<ogra_> oh ?
<ogra_> the few times i used it it just worked OOTB
<ppisati> sync media files to an mtp-enabeld device? what did you use?
<ppisati> i tried many different things
<ogra_> nexu4 and my chromebook
<ppisati> among which, rhythmbox, our music player
<ogra_> and nexus4 with my desktop too
<ppisati> when i try to sync my mp3 library, it simply crashes
<ogra_> ah, i didnt use RB ... only nautilus 
<ppisati> well, but when you move media files around you need a sw that uses libmtp which in turn let you manipulate metadata too
<ppisati> else you stuff won't properly show on the device
<ppisati> e.g.
<ppisati> right now i've the nexus10 attached to my desktop
<ppisati> and while it is mounted via gvfs (and thus i can copy files to it)
<ppisati> rhythmbox says
<ppisati> 'unable to open the Google Inc Nexus 4/10(MTP+ADB) device'
<ppisati> so, now media sync for this
<ppisati> anyhow, there's a new libmto in saucy
<ppisati> so i'll know in a bit if it fixes it
<ppisati> since the changelog explicitly mentions
<ppisati> nexus4 support
<ppisati> let's see
<ogra_> yeah
<tseliot> apw: do you happen to have an agp nvidia card that works with the 304 driver? http://us.download.nvidia.com/XFree86/Linux-x86/304.88/README/supportedchips.html
<tseliot> or tjaalton ^
<tjaalton> nope..
<tjaalton> only pcie gf8600gt
<tseliot> too bad
<tseliot> I need to test my code...
<tseliot> with linux 3.10
<davmor2> tseliot: I have  a laptop with optimus gfx I've not installed the nvidia element so don't know which driver version it uses, if that is of any use to you?
<apw> tseliot, i am not sure i have, will let you know if i find one
<tseliot> davmor2: I assume that wouldn't be an agp card. If you want you can use optimus though. It's just a matter of installing nvidia-319 and the nvidia-prime package (if you want to try it)
<tseliot> apw: thanks, as I'd like to know if I'm using the procfs correctly
<davmor2> tseliot: I'll give it a go
<tseliot> good :)
<tseliot> davmor2: you won't have to do anything else, just install those packages and reboot
<davmor2> tseliot: installling..............
<davmor2> tseliot: rebooting................  What's the best way to test it all worked?
<tseliot> davmor2: unity should start and the system won't boot into a black screen ;)
<davmor2> tseliot: OMG!!!!! splash screen I see a splash screen and a login screen that's a first on this laptop :)
<tseliot> :)
<davmor2> tseliot: effects seem faster too
<tseliot> davmor2: yes, you're using nvidia now
<davmor2> tseliot: now it's up and running any tests you'd like run on it?
<apw> rtg_, http://people.canonical.com/~ubuntu-archive/proposed-migration/
<apw> rtg_, the problem with britney is it runs before the publisher (as it does publishing) so it is possible a package gets published into -proposed after it has looked, and then picked up for migration the next run
<apw> (so we may be suffering that lag)
<rtg_> apw, yep, I'll just wait a bit
<apw> rtg_, but britney just updated, and it is still there
<apw> so ... i think that is a fail
<rtg_> sounds like a job for infinity
<apw> 08:59:55*     queuebot | 05:59:55> New: accepted linux-grouper [armhf] (saucy-proposed) [3.1.10-4.12]                â adam_g_
<apw> rtg_, so it got accepted some very many hours ago, i have asked on #ubuntu-release
<tseliot> davmor2: not really, the fact that it works is enough, thanks :)
 * ppisati goes out for a bit
<davmor2> tseliot: there is one thing the backlight doesn't look like it is turning off when the screen sleeps now, I'll dig into that a bit more though
<tseliot> davmor2: are you running Saucy?
<davmor2> tseliot: Yeap
<tseliot> tjaalton: I thought the problems with the backlight were solved ^
<davmor2> tseliot: there is definitely a glow from it it is very faint but is noticeable
<tseliot> davmor2: I thought we included a patch to make sure that DPMS works and the screen can be switched off
<tjaalton> i ran it with -intel for a while, retesting with -modesetting..
<tjaalton> xset dpms force off works
<davmor2> tjaalton, tseliot: ah hang on I think I see it now,  could it be that the backlight has a very slow fade to black.  before it was kinda a very dark purple now a few minutes latter there is no glow and it is a black screen,  I just wasn't letting it get to the black bit obviously :)
<davmor2> I can't see any light at all now examining the edges of the screen like I could before
<tjaalton> yeah seems to work fine here
<tseliot> good
<davmor2> yeap just re-trying again it is currently dark purple with a faint glow from the edges of the screen
<davmor2> and now it is off, no glow and a black screen  1 minutes 27seconds ish
<davmor2> tseliot, tjaalton: mhh there is another issue, if you hit the brightness down button I get a black screen on minimum setting  I'll write a bug up for that though
<tjaalton> not here
<tjaalton> with t420s
<tseliot> I guess that depends on the modesetting driver, not on the nvidia driver
<davmor2> tjaalton: maybe hardware specific I have an ideapad Y580
<davmor2> tseliot: and now I'm going to give it a quick stress test with oil rush
<rtg_> jsalisbury, henrix: need to bounce gomeisa for openssl update
<henrix> rtg_: ack
<tseliot> davmor2: sounds good
<jsalisbury> rtg_, ack
<davmor2> tseliot: gfx set to max and it is handling it with ease, that's a first :)
<tseliot> davmor2: excellent :)
<davmor2> tseliot: it is however throwing out some massive heat so I think I'll switch it off now :)
<tseliot> davmor2: yes, the discrete gpu uses more power
 * henrix -> back in 15
<bjf> apw, still running your unstable kernel after 40+ hrs.; no wierd times in htop though it did appear to stop updating after 24 hrs.; a new htop instance is running fine
<apw> odder
 * rtg_ bounces tangerine for openssl update
<devoid> hi all, I think I found a regression on the ixgbe driver, it looks like the driver option provided by this patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065475 no longer does anything in 3.2, 3.5 and 3.8?
<ubot2`> Ubuntu bug 1065475 in linux (Ubuntu Quantal) "Add patch for various SFP+ module support to ixgbe driver in kernel 3.2.0-x (12.04 Precise)" [Medium,Fix released]
<devoid> can someone point me to the source archive for 3.8.0-23?
<devoid> that way I can check the driver code and see if the relevant patch http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8ef78adcb03b1fcb53c3bd62df4e96c1d2706c58Â landed or was silently disabled
<rtg_> devoid, git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<henrix> devoid: the commit is there (in all the kernels). something else changed in the meantime
<henrix> devoid: do you have a bug number?
<rtg_> devoid, 81469917bcd677dd65363da61137bebacb932587 in ubuntu-precise.git
<devoid> henrix: i haven't filed a bug yet, there's some irc chatter about the option no longer working though.
<devoid> s/irc/linux-network-mailing list/
<devoid> http://comments.gmane.org/gmane.linux.network/259128
<henrix> devoid: ah, interesting
<henrix> devoid: so this is an upstream issue. i could actually still work on the ubuntu kernels, but would require some testing
<rtg_> henrix, I see no patches to ixgbe_main.c afterwards that would affect it
<henrix> rtg_: yeah, so we should be ok unless the regression was tagged with 'cc: stable@' :)
<henrix> devoid: so, have you seen this issue on any of the ubuntu kernels?
<devoid> henrix: yes, 3.2, 3.5 and 3.8
<devoid> (currently on 3.8.0-23)
<henrix> devoid: btw, when opening the bug, please make sure you provide the last version that worked for you. that should help figuring out which commit introduced the regression
<devoid> henrix: I haven't found a version that works. ;)
<henrix> devoid: at least the version that closed bug #1065475 should have worked
<ubot2`> Launchpad bug 1065475 in linux (Ubuntu Quantal) "Add patch for various SFP+ module support to ixgbe driver in kernel 3.2.0-x (12.04 Precise)" [Medium,Fix released] https://launchpad.net/bugs/1065475
<henrix> devoid: as the bug was verified
 * henrix -> back in 15
 * rtg_ -> lunch
<bjf> lamont, are you still affected by bug 1170887 ?
<ubot2`> Launchpad bug 1170887 in linux (Ubuntu) "OOPS generated during boot loading drivers" [High,Confirmed] https://launchpad.net/bugs/1170887
<lamont> bjf: I'll look
 * rtg_ -> EOD
<infinity> apw: We can haz #1186932 fixed in saucy too?
<infinity> bug #1186932 ... silly bot.
<ubot2`> Launchpad bug 1186932 in linux (Ubuntu) "Regression: kernel 3.8.0-24 breaks WPA enterprise auth [iwlwifi]" [High,Confirmed] https://launchpad.net/bugs/1186932
<arges> jsalisbury: infinity : ok kernel works for me!
<arges> also did you target this bug against saucy? since it affected me in 3.9 as well
<slangasek> jsalisbury: hi, so bug #1190781 and bug #1190414 are probably duplicates of one another... and it looks suspiciously like suspend/resume is completely broken on my x201 in saucy
<ubot2`> Launchpad bug 1190781 in linux (Ubuntu) "[LENOVO 3249CTO] suspend/resume failure" [Undecided,New] https://launchpad.net/bugs/1190781
<ubot2`> Launchpad bug 1190414 in linux (Ubuntu) "[LENOVO 3249CTO] suspend/resume failure" [Medium,Confirmed] https://launchpad.net/bugs/1190414
#ubuntu-kernel 2013-06-14
 * ppisati -> out for a bit
<ogra_> hmm, did rtg revert all the CONFIG_VT  stuff in grouper with the latest upload ?
 * ogra_ cant get the flipped image to boot anymore ... with console errors as before 
 * henrix -> lunch
<rtg_> henrix, Friday is reboot day. gomeisa first.
<henrix> rtg_: ack
<rtg_> henrix, should almost be back by now
<joshhunt> i have a question about the perf CVE that was part of the USN this morning. does anyone  know if this can  be exploited by a user which does not possess CAP_SYS_ADMIN?
<joshhunt> actually i'll rephrase. is it exploitable if sysctl_perf_event_paranoid > 0?
<rtg_> jjohansen, ^^
<rtg_> chiluk, bouncing tangerine for the dbus update
<chiluk> go for it
<jjohansen> joshhunt: atm its unclear to me whether CVE-2013-2146 is exploitable with sysctl_perf_event_paranoid==1
<joshhunt> jjohansen: ok thx. yeah i'm not sure either. do you know if any exploit code has been released? i didn't find any in my searches.
<jjohansen> joshhunt: paranoid==1 still allows for none capable users to do some things, and I need to spend a fair bit more time with it to unwind all the possible paths
<jjohansen> joshhunt: I don't have any, which makes evaluating the possible attacks harder
<joshhunt> jjohansen: yep, i'll do some more investigation. thx.
 * rtg_ -> EOW
<joshhunt> jjohansen: i think i've convinced myself that you can exploit this with perf_event_paranoid = 1
<joshhunt> jjohansen: it seems like the extra_regs get loaded when an unpriv user does something like: perf stat -e L1-dcache-loads -e L1-dcache-load-misses -e L1-dcache-stores -e L1-dcache-store-misses sleep 10
<joshhunt> jjohansen: i see this when running this at the same time as root
<joshhunt> perf stat -a -e probe:* sleep 30
<joshhunt>  Performance counter stats for 'sleep 30':
<joshhunt>                  4 probe:intel_pmu_hw_config                                    [100.00%]
<joshhunt>                  4 probe:x86_pmu_hw_config                                      [100.00%]
<joshhunt>                  4 probe:x86_setup_perfctr                                      [100.00%]
<joshhunt>                  4 probe:x86_pmu_extra_regs                                    
<jjohansen> joshhunt: yep that seem like its exploitable, thanks for digging
#ubuntu-kernel 2013-06-15
<exogen> hello, my kernel load only one cpu but I have two. Can I load the second at runtime?
<exogen> normal loads two CPUs but after last reboot was only one loaded. Don't know why.
<larsduesing> Hi
<larsduesing> I've got some troubles building a current git-kernel via make-kpkg
<larsduesing> The changelog says we are creating 3.10.0-rc5+
<larsduesing> However, I thought the version is 3.10.0-rc5
<larsduesing> Am I here right to ask for help?
 * ogra_ wonders what rtg did to the mako kernek with the last upload .... seems to produce a 6M zImage now
<DANIELA> hola
<DANIELA> quiero 
<DANIELA> hablar 
<DANIELA> con 
<DANIELA> alguien 
#ubuntu-kernel 2014-06-09
<chrisccoulson> does anyone familiar with GPU hangs know if /sys/class/drm/card0/error is likely to contain anything private (before I go and attach it to a bug)?
<mlankhorst> only thing it might contain is parts of the screen contents, but not completely likely
<chrisccoulson> mlankhorst, thanks
<sforshee> kamal: you're handling 3.13.x.y, aren't you? Did you notice this patch: http://www.spinics.net/lists/stable/msg46236.html
<sforshee> kamal: also related discussion: http://www.spinics.net/lists/stable/msg46075.html
<kamal> sforshee, thanks for the heads up ...  I'll pick it up for the next 3.13.x.y (this week)
<sforshee> kamal: awesome, thanks
<rtg> bjf: Have a look at 'git://kernel.ubuntu.com/rtg/ubuntu-trusty.git i40e'. I'll send a pull request soon.
<bjf> rtg, looking
<bjf> rtg, looks good to me (by some definition of good)
<rtg> bjf, its a giant patch set with a bit of meddling in core net code (though it appears harmless)
<bjf> yeah, i'm not worried so much about the driver code itself as that probably was working at all and there is not hw in existance as far as i can tell. the core code changes would be the only concern
<rtg> bjf, pull request sent
<bjf> ack
#ubuntu-kernel 2014-06-10
<apw> diwic, hey ... i seem to have lost sound on my main "desktop" with 3.15, and i wondered how i could figure that out
<diwic> apw, are all outputs affected?
<apw> diwic, all internal ones, i have external USB connected speakers which work
<diwic> apw, if you run "ubuntu-bug audio" and go through the sound test, is any of the sound tests working?
<apw> is it complaining about mixer settings
<apw> though the command it asks me to run is wrong
<diwic> apw, okay...could you be more precise?
<apw> ok found the card by hand and the mixer setting it whines about (speaker volume) was 0% and fixing that has fixed sound
<apw> the command was "alsamixer -D hw:intel" which didnt work
<diwic> apw, it's usually big "I" in "Intel"
<diwic> apw, but send me your alsa-info and I'll have a look
<apw> yeah big I finds it, perhaps i missread the prompt, yep missread, it is in a stupid font which looks like a little i, sigh
<apw> ok, anyhow, i assume this is lost alsa settings on upgrade thing?
<apw> do you still want my alsa-info ?
<diwic> apw, well the question is more like, why didn't pulseaudio change the speaker setting to something reasonable. Or, if you don't have any internal speakers, why do you have such a mixer setting at all
<diwic> (you said it was a desktop rather than a laptop)
<apw> diwic, ahh this is a laptop in a desktop environment, monitors attached etc, so its not mobile ever, but it is a lappy, hense the "desktop"
<apw> it has something plugged in each and every possible port :)
<diwic> apw, what port is selected in PulseAudio ( what line is selected in sound settings -> output )
<apw> diwic, when i am testing the speakers it is on "Speakers"
<diwic> apw, well, then just changing the volume in pulseaudio would also change the speaker volume
<apw> as that is the setting it has to be on to use the headphone sockets, i switch it there to the USB speakers for the rest of the time
<apw> diwic, ok so the speaker volume was set to a normal value and was working on the USB ones
<apw> when i switched internal it was silent, until i used alsa mixer to fix the volume
<apw> "speaker volume" meaning pulse's one on the top bar
<apw> and switching from one to the other swaps the volume to the per channel volume in pulse too
<apw> very odd
<apw> very odd that it could be out of sync until i did the adjustment
<diwic> apw, yeah, switching to internal should update alsa's speaker volume to something reasonable
<apw> diwic, ok, if i watch alsamixer and change pulses volume when on internal
<apw> then pulse is changing "master" and not "speaker"
<diwic> apw, sure, but if you set alsa's speaker to something and then move pulse's slider, alsa's speaker is moved to maximum
<apw> diwic, yes it does, hmmm, oh of course i may not have changed volume, on internal ever
<apw> since the issue appeared, presumably in a kernel update lose of settings
<apw> as i would switch to USB, find volume works, move to internal, find it broke, whine
 * apw notes that the order of his audio devices in alsa-mixer seems different today, in that the internal is not card 0
<diwic> apw, anyway - if you find a way to reproduce the error let me know. Otherwise I'll just let it slip.
<apw> diwic, yep, as i am running a devel kernel i think that is most appropriate :)  thanks for the help, i have more tools to work it out next time
<diwic> apw, btw, while I have you around - I'm seeing some bluetooth headset errors and most of them seem to be a userspace bug I'm currently trying to track down,
<diwic> apw, but at least one or two had some weird dmesg errors, let me find them 
<apw> ack
<diwic> apw, in bug 1283003, "Bluetooth: re-auth of legacy device is not possible." "Protocol not supported (93)"
<ubot5> bug 1283003 in gnome-bluetooth (Ubuntu) "[Bluetooth + 14.04] Bluetooth headsets are not working after last couple of updates" [Undecided,Confirmed] https://launchpad.net/bugs/1283003
<diwic> apw, the latter one is from userspace, the first one from kernel
<apw> there is only one bug number there
<diwic> apw, yeah, it's the "we report all people in one big bug" story
<apw> DOG-PILE
<diwic> apw, but for the "re-auth of legacy device is not possible" part, is there anything we should/could do about that? 
<apw> diwic, well that code seems similar in 13.10 as it does in 14.04, so it is not clear it is that which is at fault
<diwic> apw, okau
<apw> Voyager bluetoothd[716]: Protocol not supported (93)
<apw> how does bluetoothd think that is a reasonable error
<apw> what the hell was it doing when it got errno = 93
<diwic> apw, okay, let's fix blueman first and see how far that gets us w r t resolving the bugs. 
<apw> diwic, so it seems we have limited ways that bluetooth can say that, and may imply we have a module missing, will check
<apw> diwic, ok everything i would expect is enabled so, hard to be sure, we really need to get bluetoothd to tell us what i was doing if it still fails
<diwic> apw, okay. Thanks for the look
<apw> diwic, as for the errors and their order, i suspect they try and auth the device, the device is of a type which cannot, so bluetoothd closes and reopens it some differnt way and that fails
<apw> but ... what ... harder to say
<apw> diwic, it is generally good at reporting what caused the error, though there are one or two places
<apw> diwic, then again it uses the saem internal errors ... so for example if a device says HCI_UNSUPPORTED_REMOTE_FEATURE then it switches that to errno 93
<apw> which ... could mean it is not kernel at all ... ugle
<diwic> apw, hmm, okay...the reason I thought it was kernel was mostly because the kernel dmesg was first
<apw> diwic, yeah, it is not clear that that is a fatal thing, as it it might be a normal process connecting and reconnecting in dumber modes
<apw> and we had the same basic code before, though if they can down grade just the kerenl and it changes then there is a kernel component
<apw> diwic, ok that "error" is informational only and says that we failed to encrypt the link, but the link remains
<diwic> ok
<diwic> btw, is the hwe backport stuff going to work (in general) like it did for 12.04? I e 14.04.2 will ship with utopic kernel and x stack
<bjf> diwic, i can't really speak for anything other than the kernel but yes, there will be a series of lts-<series> kernels for trusty which will also be the defaults for the future point releases
<diwic> bjf, ok, good to know
<pkern> Could somebody take up https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1323165? Patch committed upstream to remove the BUG_ON.
<ubot5> Ubuntu bug 1323165 in linux (Ubuntu) "[HP ProLiant DL380p Gen8] kernel BUG at /build/buildd/linux-3.13.0/mm/memory.c:3756!" [Medium,Confirmed]
<rtg> pkern, patch sent to the k-team list
<pkern> rtg: thanks!
<vmlintu> Hi, I'm trying to understand the 3.13 kernel maintenance process. How the patches end up there? The tree here has seen no activity for some time: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog  Am I looking at the right place?
<vmlintu> What I'm trying to figure out if this patch marked for stable is on its way to Ubuntu's kernel or if something needs to be done for it to end up there: http://www.spinics.net/lists/netdev/msg282079.html
<rtg> vmlintu, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
<vmlintu> rtg: ok, I'm cloning that.. is that the Ubuntu flavoured kernel?
<rtg> yup
<vmlintu> Is git://kernel.ubuntu.com/ubuntu/linux.git going to get updates or should I follow only the ubuntu-trusty.git repo on updates?
<rtg> vmlintu, linux.git is where updates for the stable kernels that we maintain are kept. ubuntu-trusty.git is where those updates go before the kernel is built and published.
<vmlintu> ok, it looks like the patch is not there in master-next
<vmlintu> Is something needed for the stable patches to be merged? The breaking patch was introduced in 3.13 and the fix went in stable kernel 3.14.5. Should I send mail to the kernel-team mailing list?
<rtg> vmlintu, you should send an email to stable@vger.kernel.org requesting that the patch be included in 3.13 stable.
<vmlintu> rtg: thanks, I'll do that. I haven't really gotten myself familiar with the 3.13 stable process after Ubuntu kernel team took over it.
<rtg> vmlintu, it is largely the same, just different maintainers
<vmlintu> rtg: ok, that's good to know. Thanks for help!
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg> jsalisbury, I suggest we cancel today's meeting as it conflicts with Mark's keynote.
<jsalisbury> rtg, ok, will do.
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting Canceled today
<jsalisbury> ##
<dsmythies> Hi, I wonder if anyone can help me. I am investigating an issue where (it appears as though) deferrable timers are being
<dsmythies> deferred for to long (sometimes much too long) and to often.
<dsmythies> What I have done is compiled with CONFIG_DEBUG_OBJECTS_TIMERS and I vaquely read somewhere that I also need my grub line
<dsmythies> to include ignore_loglevel, which I have. However, I am not seeing any additional information anywhere, including dmesg.
<dsmythies> Where would I find the additional information, if it is being generated? Or, what am I missing to generate it?
<lim-ladm> hello, has anyone experience over  the e1000 bug with dropped packages on a intel 82574L Gigabit NIC?
<shadeslayer> hi \o
<jsalisbury> shadeslayer, o/
<shadeslayer> jsalisbury: re https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1310402 , would it be possible to change the scheduler to cfq?
<ubot5> Ubuntu bug 1310402 in linux (Ubuntu) "Userland depends on ionice idle but default scheduler is "deadline". " [Wishlist,Triaged]
<shadeslayer> or maybe even change it for Kubuntu? ( in which case, what kind of issues could we be facing )
<jsalisbury> shadeslayer, there is allot of testing and discussion to decide on which scheduler to use by default.  You do have the ability to change the scheduler for your particular system.
<shadeslayer> I understand that, but deadline doesn't work out for the needs of Kubuntu/KDE since the file indexer uses features such as io niceness which are not available via deadline
<vHanda> jsalisbury: do you any data to backup why the change was made for the deskop?
<jsalisbury> shadeslayer, we can request that the default scheduler be changed for the current or next development release, but I'm not so sure we could have it changed for any stable releases.
<jsalisbury> vHanda, it was discussed at a prior UDS and should be in the minutes/notes from UDS.  
<shadeslayer> jsalisbury: right, and any ideas on whether changing it specifically for Kubuntu would mess up anything else in foundations?
<shadeslayer> i.e. is there stuff in foundations that expects the scheduler to be deadline
<jsalisbury> shadeslayer, that's a good question.  I really don't know the answer off hand.  apw or cking do you happen to know ^^^  If not, it's something that would have to be researched.
<vHanda> I had only found this - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1008400/comments/16
<shadeslayer> roger
<ubot5> Ubuntu bug 1008400 in linux (Ubuntu) "Ubuntu server uses CFQ scheduler instead of deadline" [Medium,In progress]
<apw> shadeslayer, so that was performance related, that cfq was not performing well and got switched to deadline generally
<cking> but it is useful to know the corner cases where deadline may suck
<apw> cking, sunds like it is not feature compatible with cfq
<apw> shadeslayer, as this can be changed on the fly, i assume we can just change it at boot time
<vHanda> apw: cfq was not performing well for desktop use or server?
<apw> desktop, never has for server according to the server folk
<apw> it was a key contributer to the going unresponsive for a long time issues we were seeing back at the change
<cking> like all "defaults", it tries to do the best for most classes of use cases
<vHanda> Could you please point me to some documentation regarding these "use cases" and data showing it was not performing well.
<apw> vHanda, it was a fair time ago, iirc the graphs etc were sent to the kernel-team@ list and should be in the archives
<vHanda> I have users complaining about the file indexer using a decent amount of IO and without niceness it renders there system quite slugish.
<apw> vHanda, so change the default at boot time on kubuntu ?
<apw> and be happy
<apw> it is runtime configurable after all
<shadeslayer> apw: right, for that, do you know if kubuntu can switch out deadline for cfq and things won't break apart ?
<vHanda> I see this - https://lists.ubuntu.com/archives/kernel-team/2013-July/030360.html
<apw> shadeslayer, you can change it at any time even under load and it should just work
<vHanda> which is completely right but disregards mechanical rotational medium
<vHanda> anyway, I'll look more
<cking> vHanda, it's older than that, that was for a phone config
<shadeslayer> apw: ack
<shadeslayer> I'll have a look and try it get changed for 14.10
<shadeslayer> for Kubuntu
<shadeslayer> apw: btw is there a way to set the default scheduler as a config file ( as opposed to passing it at boot time )
 * cking wonders if a udev rule will suffice, as mentioned in http://askubuntu.com/questions/78682/how-do-i-change-to-the-noop-scheduler
<apw> cking, yeah that is a good basis for changing it long term
<ekarlso> any idea on when there will be a newer kernel out for 14.04 ? 
<apw> ekarlso, newer as in more bug fixes or a later upstream version ?
<ekarlso> apw: both would be nice...
<apw> ekarlso, we issue bug fix updates about every 3 weeks, we will liklely backport the U kernel to 14.04 when that releases
<ekarlso> apw: I keep seeing kernel panics with ovs and gre / vxlan because of forwarding on a openstack network node
<apw> ekarlso, have you filed a bug about it?
<ekarlso> apw: I have for the GRE stuff yes
<smitty> The kernels newer than 3.13.0.24-generic will not recognize the Playstation 3 gamepad. 3.13.0.27-generic and 3.13.0.29-generic fail during boot with a dmesg error of "sony 0003:054C:0268.0003: can't set operational mode" and then "sony: probe of 0003:054C:0268.0003 failed with error -38".
<apw> if you could throw the bug # in here in the discussion so i can pass it on to interested parties
<ekarlso> but it sucks getting info on it because the trace is to long to record...
<bjf> smitty, have you filed a bug? if it's a regression then you can work with jsalisbury and he'll help you find the bad commit
<jsalisbury> smitty, I'll keep and eye out for the bug and help you with a bisect.
<ekarlso> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313591
<ubot5> Ubuntu bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [High,Incomplete]
<smitty> Thanks! I haven't filed a bug report as it seems a bit complicated. I've had to stick with the 3.13.0.24-generic kernel.
<apw> smitty, you should be able to run "ubuntu-bug linux" to file a basic bug
<bjf> ekarlso, it looks like that bug is waiting for you to test a kernel
<bjf> ekarlso, see comment #6
<smitty> apw, I suppose I have to be running the affected kernel right? I uninstalled it but I suppose I can reinstall it. "ubuntu-bug linux" does not seem to have a mechanism to add my own report to it. It just scans my system and goes directly to upload.
<smitty_> apw, I used "ubuntu-bug linux" to file a bug report. After several errors the process has completed. I couldn't continue to use an old kernel.
<ekarlso> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313591
<ubot5> Ubuntu bug 1313591 in linux (Ubuntu) "Panic on 3.13.0-24 with bnx2, iptables and MASQUERADE" [High,Incomplete]
<ekarlso> updated..
<ekarlso> I've tested the 3.14 with GRE and VXLAN and also on 3.13 
<ekarlso> it seems to panic on all 4 scenarios
<ekarlso> apw: anything I can try ?
<smitty_> jsalisbury, I filed a report bug #1328673 for the playstation 3 gamepad. Apparently it was a waste of time as someone beat me to it. Oops... maybe not.
<ubot5> bug 1328673 in linux (Ubuntu) "Playstation 3 gamepad does not get a device created" [Undecided,New] https://launchpad.net/bugs/1328673
<ekarlso> bjf: there it is...
<bjf> ekarlso, thanks
<ekarlso> bjf: any later kernel I can tset ?
<ekarlso> 3.15 ? 
<ekarlso> this is getting pretty annoyin
<bjf> ekarlso, you certainly could try a utopic kernel
<ekarlso> is that installable on trusty ? 
<bjf> ekarlso, the kernel is, yes. you need to pull down the .debs and use dpkg to install them
<bjf> ekarlso, amd64?
<ekarlso> bjf: yes
<bjf> ekarlso, https://launchpad.net/ubuntu/+source/linux/3.15.0-5.10/+build/6062393
<ekarlso> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-utopic/ ;)
<bjf> ekarlso, you can try that also
<bjf> ekarlso, that would actually be better
<ekarlso> bjf: so obviously the thing that helps is setting gro / gso off on the NIC that is the -o interface in iptables for the masquerade
<bjf> ekarlso, that "fixes" it for you as well?
<bjf> ekarlso, the 3.15 kernel didn't help ?
<ekarlso> bjf: yah, I was doing it for the wrong iface
<ekarlso> bjf: nop
#ubuntu-kernel 2014-06-11
<dannf> rtg: we have people wanting to play with xgene/utopic - mainly our linaro folks wanting to test out new arm64/kernel features - problem is they don't have luxuries like nic drivers, reboot support (still iterating in review upstream). question is, are you ok w/ carrying temporary versions of these drivers that we trade out w/ accepted versions later, or should i maintain a tree/ppa for them?
<dannf> and is the answer different now vs. when we're nearing freeze?
<rtg> dannf, you're talking about utopic ?
<dannf> rtg: yes
<rtg> dannf, you've got a few weeks yet that I can be flexible. As we get closer to freeze I'll clamp down on changes.
<dannf> rtg: flexible meaning willing to take not-yet-upstream stuff, and clamp-down meaning no-more-swaps?
<rtg> dannf, yup
<dannf> rtg: ack
<rtg> dannf, so, around Oct 1 I'll start to get more conservative. that said, the arm64 APM patches are quite testable.
<dannf> rtg: do you know when you'll move to a 3.16-rc? after rc1?
<rtg> dannf, it kindof depends on how stable it is. usually I'm not too comfortable inflicting a new kernel release on the real world until -rc2 or 3
<rtg> -rc2 at the earliest for sure
<dannf> ok. then we may ask for a few more cherry-picks for 3.15 in the meantime if that's ok. i'm also not sure what the best way to ask on-list for a cherry-pick is - if its a clean cherry-pick, do i need to attach patches, etc?
<rtg> dannf, if they are clean then just the list of commits is fine. a pull request is best.
<rtg> a pull request is _easiest_ for me to consume, regardless if they are clean cherry picks, etc.
<dannf> rtg: ok
<dannf> wfm
<rtg> smb, could you check to see if Utopic still needs aabdb7729a2da806e60bf2d956f126e2cc3a0d85 (UBUNTU: SAUCE: kvm: Force preempt folding in kvm on i386) from Trusty ?
<smb> rtg, I can. Gut feeling would be no, as there was a better but more invasive changeset mentioned, leading to the smal stable request
<rtg> smb, cool, I'll ignore it for now
<smb> Just have to figure out when those changes were in. ok, yeah
<smb> rtg, ok, you can continue to ignore it for utopic as the four patches are in there. Only 3.13 and 3.14 were needing the other patch
<rtg> smb, ack
<rtg> dannf, does Utopic still need 'UBUNTU: [Config] CONFIG_TRANSPARENT_HUGEPAGE=n for arm64' ?
<dannf> rtg: TBD. that's on my list to verify
<dannf> the patches i was monitoring that were supposed to fix it never landed, but i saw another bug fix go in that might be the real problem
<rtg> dannf, then I'll leave it out until further notice. just remember it if things get weird.
<dannf> yep, will do. 
<dmsmr_> I'm working on a kernel module and it triggers a BUG() as follows
<dmsmr_> [ 1077.052029] kernel BUG at /build/buildd/linux-3.13.0/include/linux/scatterlist.h:65!
<dmsmr_> How can I find out the code that triggers it?
<dmsmr_> I've downloaded the kernel source but want to be sure about the line.
<dmsmr_> Also, how can I find out my current kernel .config?
<dmsmr_> Okay, config is under /boot
#ubuntu-kernel 2014-06-12
<apw> dmsmr_, that lists the exact file and line #, 65
<apw> xnox, hey ... would you expect me to be able to upgrade running systemd at all ?
<xnox> apw: mostly yes. Some packages may fail in post-inst. E.g. those that try to do "invoke-rc.d start foo" where "foo" is only an upstart job, without systemd unit / init-script.
<apw> xnox, yeah that has just happened, in the stop for the existing installed one in fact
<apw> of course i am only doing that because of debhelpers heplfulness not directly
<xnox> apw: you can add a symlink of that name to /dev/null
<xnox> (locally)
<apw> i clearly need to get these work units in pronto
<apw> xnox, where do they live the work units ?
<xnox> apw: packages install units into /lib/systemd/system/. local administrator into /etc/systemd/system
<apw> as right now i cannot reboot, because my kernel is half installed :/
<xnox> apw: $ sudo ln -s /dev/null /etc/systemd/system/foo.service
<xnox> where foo is the service that postinsts try to start/stop/whatever
<xnox> and $ systemctl reload
<xnox> then try to dpkg --configure -a, or whatever
<apw> ok that worked, just adding the links and doing the upgrade again
<xnox> \o/
<apw> i'll get some work load units in here double quick, so i don't have this issue next time
<apw> they shold be about 3 lines
<rtg> bjf, gimme some love: https://lists.ubuntu.com/archives/kernel-team/2014-June/043914.html
<bjf> rtg, looking
<psivaa> tyhicks: hello, i noticed that you worked on bug 1296459, which is fix released. I'm on apparmor version 2.8.95~2430-0ubuntu5 on trusty and seeing similar behaviour
<ubot5> bug 1296459 in apparmor (Ubuntu) "Upgrade from 2.8.0-0ubuntu38 to 2.8.95~2430-0ubuntu2 breaks LXC containers" [Critical,Fix released] https://launchpad.net/bugs/1296459
<jjohansen1> psivaa: can you paste the results of
<jjohansen1>   dmesg | grep DENEIED
<tyhicks> psivaa: that should be DENIED
<jjohansen1> yeah
<psivaa> tyhicks: jjohansen1: oops sorry, that gives me empty list
<tyhicks> psivaa: what is the similar behavior that you're seeing?
<jjohansen1> psivaa: okay do that on syslog
<jjohansen1>   grep DENIED /var/log/syslog
<jjohansen1> I would assume that the container is failing to start
<psivaa> tyhicks: "lxc-start: command get_cgroup failed to receive response" when i run "sudo lxc-start -d -f /etc/lxc/default.conf --name juju-precise-template"
<jjohansen1> psivaa: on the grep did you fix my typo?
<psivaa> jjohansen1: yea i did and there is nothing on dmesg, but on syslog:
<psivaa> Jun 12 14:25:36 parapuva kernel: [415185.749263] type=1400 audit(1402579536.554:201): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=4172 comm="lxc-start" flags="rw, rslave"
<psivaa> Jun 12 16:07:42 parapuva kernel: [421316.922238] type=1400 audit(1402585662.502:218): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=8191 comm="lxc-start" flags="rw, rslave"
<psivaa> though the timings are not matching when i ran the lxc-start last though
<psivaa> and i did a restart at 16:10, so these errors are before the restart
<psivaa> should i ping stgraber then for a workaround?
<tyhicks> psivaa: you weren't running with pre-release packages by any chance, were you? (someone recently hit a similar bug but was using the buggy apparmor package from the devel cycle)
<tyhicks> jjohansen1: as a side note, it would be good to add the fstype to that audit message
<jjohansen1> psivaa: what is your uptime like?
<stgraber> psivaa: can you run lxc-start without the -d so you can actually see what's the error message?
<jjohansen1> tyhicks: indeed
<psivaa> tyhicks: i'm not running pre-release apparmor. the lxc is also from stable release (1.0.3-0ubuntu3)
<psivaa> jjohansen1: "16:39:58 up 28 min,  2 users,  load average: 0.27, 0.28, 0.31" is the uptime
<tyhicks> psivaa: so apparmor is 2.8.95~2430-0ubuntu5 ?
<psivaa> tyhicks: yes
<jjohansen1> psivaa: okay, that rules out stale policy in the kernel but not the cache
<psivaa> stgraber: the first line is "lxc-start: failed to attach 'vethU534EI' to the bridge 'lxcbr0' : No such device"
<jjohansen1> psivaa: can you do
<jjohansen1>   sudo /etc/init.d/apparmor restart
<jjohansen1> to make sure that the policy is recompiled with the most recent apparmor
<stgraber> psivaa: ok, do you have a lxcbr0 device on that host?
<psivaa> stgraber: checking
<psivaa> stgraber: "sudo brctl show" shows nothing
<psivaa> should *I do anything about it :)
<psivaa> ?
<stgraber> psivaa: sudo status lxc-net
<psivaa> stgraber: lxc-net start/running
<stgraber> weird... can you pastebin /var/log/upstart/lxc-net.log?
<psivaa> stgraber: "dnsmasq: failed to create listening socket for 10.0.3.1: Address already in use" is the only line.
<psivaa> please bear in mind, this is the first time i am starting to use lxc so, i could be doing something silly
<tyhicks> psivaa: this isn't feeling like bug #1296459, so I'm going to let you chase down the bridge device issue and then you can ping me if apparmor is still causing problems
<ubot5> bug 1296459 in apparmor (Ubuntu) "Upgrade from 2.8.0-0ubuntu38 to 2.8.95~2430-0ubuntu2 breaks LXC containers" [Critical,Fix released] https://launchpad.net/bugs/1296459
<psivaa> tyhicks: ack, thanks and sorry for the noice
<tyhicks> np
<stgraber> psivaa: hmm, do you have bind9, dnsmasq or some other dns servers running on that box?
<psivaa> stgraber: no http://paste.ubuntu.com/7634310/ is the grep '10.0.3.1' /var/log/syslog output
<rtg> sforshee, are we ready for '-9.ucode for 3160, 7260 and 7265.' in Trusty ?
<rtg> I think we're carrying the beacon filter patch in 3.13
<stgraber> psivaa: you've got bind installed on that system
<stgraber> psivaa: (named)
<sforshee> rtg: not sure that trusty will even use it, but there's a patch coming down from 3.13 stable that we should get before we update from -7 I think
<sforshee> it's what Emmanuel thinks will get around the problems people saw with -8 on 7260
<rtg> sforshee, the Utopic LTS kernel will use it, right ?
<sforshee> rtg: yeah, but let me double check trusty too
<stgraber> psivaa: so I'd suggest you remove the bind9 package from your system then reboot, that should do it
<stgraber> psivaa: unless you actually need named for some reason, but if that's a standard desktop or server system, you don't. You pretty much only do if you are running a DNS server on there.
<rtg> sforshee, if that patch is already in stable, then I can cherry-pick it and add the buglink
<sforshee> rtg: it was in the most recent set that kamal sent out for review
<rtg> sforshee, do you recall the commit subject ?
<kamal> sforshee, rtg which patch?
<sforshee> rtg: so trusty kernel will only use -8 right now, so I guess no harm in adding -9
<sforshee> rtg: one sec
<psivaa> stgraber: ack, will remove it and rerun. thanks for the help
<sforshee> rtg: iwlwifi: mvm: disable beacon filtering
<rtg> 7bacc782270ff7db3b9f29fa5d24ad2ee1e8e81d
<kamal> sforshee, rtg: yup, that'll be in the 3.13.11.3 that I will release tomorrow
<sforshee> rtg: after that we _should_ be able to move back to -8 ucode, but we've actually only had one tester confirm that it helped
<kamal> rtg, fyi, the sha in the 3.13-stable branch for that is   f30f889c iwlwifi: mvm: disable beacon filtering
<rtg> kamal, I'm gonna cherry-pick it in advance and add a buglink
<kamal> rtg, wfm
<sforshee> rtg: bug number is 1293569 in case you don't have it
<rtg> sforshee, thanks
<sforshee> rtg: there's another patch there that emmanuel suggested adding to 3.13, but I haven't had time to follow up yet
<sforshee> rtg: 12d423e816c69b0b4457bc047dda9a0a1c1a53c1 iwlwifi: mvm: Add a missed beacons threshold
<sforshee> kamal: ^
<rtg> sforshee, not marked for stable
<kamal> sforshee, I'll stand by on that one until somebody (you, or him) to ask me to stuff it into 3.13
<kamal> s/to ask me/asks me/
<sforshee> kamal: ack
<kamal> sforshee, it does apply fine, btw
<sforshee> kamal: cool, thanks. My hesitation is that it seems to be more of a "this might help too" than a "this will definitely help" kind of suggestion
<psivaa> stgraber: tyhicks: now, after removing bind9, i see the apparmor DENIED message:
<psivaa> [  274.185989] type=1400 audit(1402589384.417:111): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=3388 comm="lxc-start" flags="rw, rslave"
<kamal> sforshee, yeah, I'm happy to wait for you to feel less hesitant about it :-)
<psivaa> and the lxc-start command throws 'lxc-start: Permission denied - Failed to make / rslave'
<stgraber> psivaa: odd, can you paste /proc/self/mountinfo?
<psivaa> stgraber: http://paste.ubuntu.com/7634401/
<stgraber> ok, what kernel and apparmor do you have on that machine?
<psivaa> stgraber: apparmor: 2.8.95~2430-0ubuntu5 and kernel: 3.13.0-29-generic #53-
<stgraber> hmm, that's pretty weird because you're not supposed to hit that code path on Ubuntu...
<stgraber> can you start the container with -o debug -l debug and pastebin the debug file?
<psivaa> stgraber: http://paste.ubuntu.com/7634437/ a  question: do i not have to run lxc-create before ? :)
<stgraber> psivaa: ok, let's try a new clean simple container for now :)
<stgraber> psivaa: lxc-create -t download -n test -- -d ubuntu -r trusty -a amd64 && lxc-start -n test
<psivaa> stgraber: so the creating went fine, but "sudo lxc-start -f /etc/lxc/default.conf -n test" outputs "lxc-start: Permission denied - Failed to make / rslave"
<psivaa> with similar apparmor DENIED message in dmesg
<ha1dfo> Hi all. I am using an USB3 attached SSD, and for TRIM support, I'm looking for UAS driver. But it seems that it was removed somewhere between quantal and raring. Can you advise me what is the nicest way to get it for myself
<bjf> ha1dfo, http://pastebin.ubuntu.com/7635162/
<ha1dfo> bjf, Thank you!
<bjf> ha1dfo, nothing to really thank be for, it's busted and we're not going to enable it. you'll have to build your own kernel to do so
<ha1dfo> well, you saved me a couple of hours of searching for the reason, for sure!
<bjf> ha1dfo, heh, well your welcome for that :-)
<ha1dfo> ok, so if uas is broken, then is there any other way to get TRIM working via usb3?
<bjf> ha1dfo, that i don't know. cking? ^
<cking> that I don't know about :-/
<bjf> was worth a shot
#ubuntu-kernel 2014-06-13
<Yaannnn> Hi
<Yaannnn> I'm looking for help with high performance 1-to-1 NAT
<apw> ask your question you never know we might know, or know who to point you at
<Yaannnn> I have trouble NATing 10gbits with 1000 1-to-1 rules
<apw> and the trouble is? throughput?
<Yaannnn> Yep + packetloss
<Yaannnn> the server never reaches 10gbit/s when they are many flows
<apw> yeah that is somewhat beyond out experience i would say, #ubuntu-server may have done something like that
<Yaannnn> Ok, thx, i'm gonna look for help there then :)
<Yaannnn> The only thing I can say is that with normal iptables the CPU is used by Hardware IRQ and with Xtables it's softirq which are using the CPU
<trippeh_> Yaannnn: Do you have any stateful netfilter modules loaded? As soon any of those conntrack thingies are loaded into the kernel throughput can often plummet when many flows is involved.
<trippeh_> 1-1 nat should be able to run statelessly, without conntrack, IIRC
<trippeh_> Yaannnn: also rules get evaluated in order, you should look at moving the most used rules to the front, maybe even grouping into chains to limit the amount of searching done per packet
<Yaannnn> trippeh_: The problem is that by default iptables loads conntrack
<trippeh_> what iptables target are you using to do the natting?
<Yaannnn> trippeh_: We tried the default DNAT/SNAT
<trippeh_> iptables only loads the modules needed for its targets and matches to work, conntrack is not really default unless you use a match or target requiring it
<Yaannnn> trippeh_: but we also tried with rawpost from X-tables
<trippeh_> SNAT/DNAT would load conntrack indeed
<trippeh_> You might want to try out SNPT and DNPT
<Yaannnn> trippeh_: is it mainstream ?
<trippeh_> Yaannnn: it should exist in 14.04 at least
<trippeh_> its pretty recent, but mainstream
<Yaannnn> trippeh_: according to the man it seems to be IPV6-specific
<trippeh_> oh, hum *tries*
<trippeh_> Granted, I've only used it on ipv6 myself :)
<Yaannnn> trippeh_: did you try NETMAP ?
<Yaannnn> trippeh_: I tried DNETMAP but without sucess, the server was not able to reach 10gbit with lots of flows
<trippeh_> if you cant get rid of conntrack, you might want to try out kernel 3.15, it has significant performance boosts for conntrack on multicore systems
<Yaannnn> trippeh_: do you know about any kernel tweaks which could help ?
<Yaannnn> trippeh_: did you try out nftables ? We are trying this but it doesn't seems to behave but we didn't activate the rbtree module
<trippeh_> Yaannnn: there is a conntrack table size that can be tuned, but other than that there is not that many tunables
<trippeh_> maybe pinning ethernet ports to cpu's could help
<trippeh_> have not gotten around to nftables yet no
<trippeh_> yeah looks like SNPT/DNPT fails for ipv4
<Yaannnn> trippeh_: I was thinking about tweaks on interrupt handling
<Yaannnn> trippeh_: But I don't know what is possible on this side
<trippeh_> and netmap seems to load conntrack too, hmm
<trippeh_> tweaks on interrupt handling = typically cpu pinning :)
<trippeh_> I wonder if SNAT/DNAT/NETMAP would still work with -j CT --notrack in raw table
<trippeh_> if its just address to address mapping
<Yaannnn> trippeh_: nop, already tried that :P
<Yaannnn> trippeh_: the traffic doesn't flow anymore
<trippeh_> bummer
<trippeh_> maybe try out 3.15 ;)
<Yaannnn> trippeh_: are conntrack entries created on each packet processed for UDP packets ?
<apw> there is a 3.15 final kernel in utopic as of like yesterday
<apw> i believe they are, bacuase a udp pairing is a flow
<trippeh_> Yaannnn: no, it will try to match existing conntrack entry
<trippeh_> Yaannnn: switch to ipv6 :-)
<trippeh_> ahem
<Yaannnn> trippeh_: Haha, I whish I could :), gonna try the 3.15
<apw> ok, so i am suggesting there is a contrack entry made for the flow
<apw> which means on the first one, and those get reused
<apw> bah i'll butt out
<trippeh_> :)
<trippeh_> I find it odd that there is appearantly no stateless address rewriting facility for ipv4
<Yaannnn> trippeh_: Yep, they are some but in X-tables
<Yaannnn> trippeh_: And it doesn't perform well
<trippeh_> right
<trippeh_> did you make sure conntrack modules were not loaded into kernel memory when you tried it? :)
<trippeh_> say, from earlier playing around
<Yaannnn> trippeh_: what is the low latency version of the kernel ?
<apw> lowlatency is a slight config change, it is a preempt enabled, and irq via threads
<Yaannnn> apw: ok, thx, it which situation is it supposed to help ?
<Yaannnn> in *
<apw> it exists for the audio folk who will burn overall performance for latency
<Yaannnn> trippeh_: yep, we blacklisted the conntrack modules
<Yaannnn> apw: trippeh_ : Doesn't seem to be a lot better with the 3.15, maybe more level on the rules could improve the results
<Yaannnn> I'm stopping my tests for today
<Yaannnn> Thanks for your help :)
<ekarlso> will 3.16 be in the july update for the kernel ?
<trippeh_> hm. the NPT v6 module seems very simple. I wonder how well a straight over port would work on v4
#ubuntu-kernel 2014-06-15
<Fudge> hi guys, I am running Trusty 64bit 3.13.0-29-generic  on I5-4670K overclocked to 4gig, since this overclocking Ubuntu USB functionality drops out, works in Windows though. Any knowledge of this and is it kernel related?
<alexbligh1> Anyone know off-hand whether the trusty kernel is affected by the DF bit regression on IP forwarding ( see https://lkml.org/lkml/2014/6/10/712 , introduced by bd91cb56f951a7b0da8c3098ea9cd56854ece66c fixed by 895162b1101b3ea5db08ca6822ae9672717efec0 )
<infinity> alexbligh1: I don't think ca6c5d4ad216d5942ae544bbf02503041bd802aa (the upstream commit matching bd91cb56f951a7b0da8c3098ea9cd56854ece66c) is in the trusty kernel, no.
<infinity> alexbligh1: And both ca6c5d4ad216d5942ae544bbf02503041bd802aa and 895162b1101b3ea5db08ca6822ae9672717efec0 are in utopic.
<alexbligh1> infinity, thanks - couldn't find either but wanted to be sure.
<alexbligh1> thanks
<infinity> alexbligh1: Yeah, looking at the code, ca6c5d4ad216d5942ae544bbf02503041bd802aa definitely isn't in the trusty kernels.
<alexbligh1> infinity, thanks - it's a nasty one (well, from my pov)
#ubuntu-kernel 2015-06-08
<puffi> Guys, not sure if this is the right channel. I have a script that checks for Ubuntu version and kernel version and installs an application based on it. I want to add in a step that will install a supported kernel version if one is not found. That part should be ok, the bit I'm unsure of is how to automate the edit to make sure the newly installed kernel will be set to the dfefault on next boot. Is thi
<puffi> s possible?
<apw> puffi, if we are talking x86 you can use the "title" of the kernel in grub to select a specific kernel
<apw> puffi, in /etc/default/grub you can set GRUB_DEFAULT to a string iirc
<puffi> apw: Thanks looking into that now
<apw> puffi, pretty sure that is how one switches to 
<apw> xen ..
<puffi> apw: I'll need to know where it's going to be on the list of previous kernels.
<puffi> hmm
<puffi> is there a way to work that out before a reboot?
<apw> puffi, i thought you wanted to select a specific version
<puffi> apw: I want to automate the edit, eg. automate kernel install, change newly installed to default. reboot new default
<puffi> you mean GRUB_DEFAULT="3.2.0-18-generic" for example
<puffi> then it will always boot that kernel?
<apw> puffi, that kind of thing yes, you use i think the texttual name of the menuentry
<apw> menuentry 'Ubuntu, with Linux 3.13.0-53-generic'
<apw> in the grub.cfg ...
<apw> smb, i think you use that for xen right ?
<puffi> apw: works perfectly
<puffi> Thanks
<smb> apw, yes
#ubuntu-kernel 2015-06-09
<EvilRoey> hello all!  Question... now that rebootless kernel swapping is mainlined in the kernel, how long until we can upgrade Kubuntu releases without having to reboot?
<bjf> EvilRoey, there is a lot more involved than just the bits that are in the kernel. we are investigating but have no timeframe yet.
<jsalisbury> **
<EvilRoey> Aye, I understand this.   I am wondering if this is a working design goal for Ubuntu
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<arges> EvilRoey: yea it will take some thought. Livepatch won't handle _all_ patches but mostly small critical fixes.
<EvilRoey> arges:  especially as some applications must have the same ABI as their libraries (KDE in my case)
<cristian_c> jsalisbury, hello
<jsalisbury> cristian_c, hello.  I'll make some time to work on your bug some more today
<cristian_c> jsalisbury, ok
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##   
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues June 16th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
#ubuntu-kernel 2015-06-11
<neoark> linux-cloud-tools-generic-lts-vivid linux-tools-generic-lts-vivid
<neoark> are missing dependencies
<neoark> anyone know why?
<apw> neoark, ?
<apw> missing dependancies of what
<neoark> no clue apt-get is not updating
<apw> those should not exist in the latest packages
<neoark> how do i check?
<neoark> https://pastee.org/shwud
<apw> ahh ok, missread the original, hmmm that looks like an expected dependancy, and one i would expect to exist
<apw>  linux-cloud-tools-3.19.0-20-generic | 3.19.0-20.20~14.04.1 | trusty-security | amd64, i386
<apw> and one which exists in the archive
<apw> neoark, what are you doing to trigger that error, what command line is that ... in fact could you pastebin the entire output prompt to prompt
<neoark> deb http://archive.canonical.com/ubuntu trusty partner
<neoark> deb-src http://archive.canonical.com/ubuntu trusty partner
<neoark> have that
<neoark> https://pastee.org/j259y
<apw> neoark, _just_ that in your sources ?
<neoark> apt-get dist-upgrade linux-cloud-tools-generic-lts-vivid linux-tools-generic-lts-vivid -y gives missing depe
<neoark> https://pastee.org/8gc2s
<neoark> sources
<neoark> apw any clue on how to get missing dep?
<apw> neoark, i am testing here
<neoark> ty
<apw> neoark, ok on my T box here it just finds and installs the deps correctly
<apw> neoark, could you have out of date apt databased ?  I would try and  apt-get update
<neoark> did that before i did other dist-upgrade i have couple server and its happening on all of them
<neoark> W: Failed to fetch http://ubuntu.mirrors.ovh.net/ftp.ubuntu.com/ubuntu/dists/trusty-updates/main/i18n/Translation-en  Hash Sum mismatch
<neoark> W: Failed to fetch http://ubuntu.mirrors.ovh.net/ftp.ubuntu.com/ubuntu/dists/trusty-updates/universe/i18n/Translation-en  Hash Sum mismatch
<neoark> E: Some index files failed to download. They have been ignored, or old ones used instead.
<neoark> err ovh is so unreliable
<apw> hmmm
<apw> i wonder if you have a mirroring missmatch then, becuase the indexes i have here are offering me that package just fine
<neoark> how to correct it? or OVH has too?
<apw> neoark, well one expects mirrors to be in sync by default and to sync up pretty quick when they arn't ... if that is what you have
<apw> sudo apt-get install linux-tools-generic-lts-vivid
<apw> what does doing one of those say in full on the affected system
<neoark> he following packages have unmet dependencies:
<neoark>  linux-tools-generic-lts-vivid : Depends: linux-tools-3.19.0-20-generic but it is not going to be installed
<neoark> E: Unable to correct problems, you have held broken packages.
<neoark> let me switch my sources and try again
<apw> that feels like linux-meta-lts-vivid was published but not linux-lts-vivid ... which would be very unusual and doesn't match how the archive is now to my eye
<neoark> doesn't work still
<neoark> tried https://pastee.org/84m2g still same problem
<apw> apt-cache show linux-cloud-tools-3.19.0-20-generic | egrep '(Version|Depends)'
<apw> what does that show
<neoark> apt-cache show linux-cloud-tools-3.19.0-20-generic | egrep '(Version|Depends)'
<neoark> Version: 3.19.0-20.20~14.04.1
<neoark> Depends: linux-lts-vivid-cloud-tools-3.19.0-20
<apw> neoark, and the same for linux-tools-3.19.0-20-generic ?
<neoark> apt-cache show linux-tools-3.19.0-20-generic | egrep '(Version|Depends)'
<neoark> Version: 3.19.0-20.20~14.04.1
<neoark> Depends: linux-lts-vivid-tools-3.19.0-20
<neoark> root@arjun:~# 
<apw> so that says you have both packages available in your index
<neoark> yes
<apw> apt-get install linux-tools-lts-vivid 
<neoark> just can't install them
<apw> and that only said the 4 lines you pasted before nothing else ?
<neoark> yes
<apw> does apt-get install -f
<apw> say anything
<apw> be very careful about saying yes without reading what it says
<neoark> Reading state information... Done
<neoark> E: Unable to locate package linux-tools-lts-vivid
<apw> what does apt-cache show linux-tools-lts-vivid say
<neoark> -f doesn't install
<neoark> https://pastee.org/jvs77
<neoark> apt-cache show linux-tools-lts-vivid
<neoark> N: Unable to locate package linux-tools-lts-vivid
<neoark> E: No packages found
<apw> hang on ... why is it talking about linux-tools-lts-vivid at all ?
<apw> that isn't a package ...
<apw> how is that mentioned in instal -f
<neoark> https://pastee.org/jvs77 < -f install
<apw> ok ... that says a further step dependancy is missing
<apw> apt-cache show linux-lts-vivid-tools-3.19.0-20
<neoark> https://pastee.org/pd6tz
<neoark> linux-tools-common was missing odd
<neoark> hmm
<apw> linux-tools-common is missing ?  
<apw> that is a default package, hmmm
<apw> what version of linux-tools-common
<apw> does apt-cache show show
<neoark> Version: 3.13.0-24.46
<neoark> linux-tools-common
<neoark> thanks sorted gotta figure out what else is missing
<neoark> apw i guess linux-lts-vivid-tools-common
<neoark> is missing
<neoark> there is linux-lts-utopic-tools-common
<neoark>  linux-lts-vivid-tools-common (3.19.0-18.18) its missing for 3.19.0-18.20
<apw> neoark, so are you trying to upgrade just the lts packages or letting the system upgrade in general
<neoark> so upgrade stock to lts utopic to lts vivid
<apw> neoark, there is no linux-lts-vivid-tools-common
<neoark> yes linux-lts-utopic-tools-common i think uninstalls linux-tools-common
<apw> there should be no linux-lts-*-tools-common any more, they are meant to use linux-tools-common ... it is menat to be common to all kernels
<apw> so the latest linux-lts-utopic should fix that so it does not
<apw> so is the issue here you have an _old_ linux-lts-utopic installed and it is colliding with linux-lts-vivid
<apw> which is fixed ?
<neoark> https://pastee.org/3kar < still shows as available
<apw> yes, that is basically pending NBS handling, it existing isn't an issue, it should not be a dependancy of the current packages
<neoark> yes but it removes linux-tools-common on autoremove that created this issue
<neoark> so you can upgrade from 3.19.0-18.18 to 3.19.0-18.20 is you did apt-get autoremove
<neoark> can not*
<neoark> err can't type this morning.
<neoark> s/it/if
<apw> do you mean -20.20 ?
<neoark> 3.19.0-20.20
<neoark> Yes
<apw> so if you do an autoremove, then the dist-upgrade it works ?
<neoark> No it doesn't
<neoark> because it removed  linux-tools-common since i had installed linux-lts-vivid-tools-common (3.19.0-18.18)
<neoark> So I had to reinstall linux-tools-common to install 3.19.0-20
<neoark> https://pastee.org/2r3p
<neoark> - List of linux- install and their version
<apw> neoark, so i was not expecting you to install linux-lts-vivid-tools-common manually ever, that doesn't seem like something one should do
#ubuntu-kernel 2015-06-12
<TJ-> What's the recommended process to bisect on a rebased branch? I'm trying to track down a regression in PCI code between v3.15 and v3.16-rc6 on mainline, using the ubuntu-utopic branch which rebased from 3.15 to 3.16. The problem is the rebase causes a divergence back 578 commits to the common ancestor so bisect can't do anything
<apw> TJ-, we tend to acertain if the issue is present / not present in the corresponding mainline kernels at the same base level
<apw> if it is you can the bisect in th emainline which has no rebases
<apw> if ti doesn't exist then it is a matter of bisecting between the mainline base and the ubuntu tip
<TJ-> apw: I already know that, it came in with the PCI change added to v3.16; I was hoping to use the Ubuntu branch to do the bisect on rather than mainline
<TJ-> apw: the reason being I can use the Ubuntu packaging tools to distribute/install the test versions
<apw> well as you know procedurally that doesn't work, which is why indeed we make the mainlnie ones using the ubuntu tooling
<apw> and when bisecting you can do the same, the proceedure is essentially to "git checkout ubuntu/master-next debian debian.master" over the top of your bisect point, update the configs and then build
<TJ-> apw: Yes... I might try using the mainline repos as the base instead but when I tried that a few hours ago I got lost somehow with no debian/ debian.master after the bisect since those had to be applied from the packaging patches
<TJ-> Ahhhhh.... I'll play around with that approach
<MCSH> Hi, I'm getting Kernel Panic (Fatal Exception In Interrupt) about 30 seconds after I boot 15.04, can anyone help me?
<rbasak> smb: http://dep.debian.net/deps/dep5/
<rbasak> smb: lib/librte_net/rte_ip.h
<rbasak> smb: https://lintian.debian.org/tags/package-name-doesnt-match-sonames.html
<gQuigs> is there any automatic building of Ubuntu's trusty master-next?  http://kernel.ubuntu.com/git/ubuntu/ubuntu-trusty.git/?h=master-next
<apw> gQuigs, it is uploaded into a PPA about every 24 hours if changed
<gQuigs> apw: oh, cool..  I just haven't been able to find the PPA
<gQuigs> where is it?
<apw> ppa:ubuntu-kernel-test/ubuntu/stable perhaps
<apw> www.lauchpad.net/~ubuntu-kernel-test
<gQuigs> apw: that's it, thanks!
<swair>  i'm compiling kernel 3.16 gcc versions are 5 and 4.8, i've set CC=/usr/bin/gcc-4.8 still i get this error: fatal error: linux/compiler-gcc5.h: No such file or directory. any ideas?
<apw> swair, you'd have to be more specific as to how you are compiling, as that file definatly exists in v3.16
<swair> apw: its not in the 3.16 tree. It was added in 3.18. 
<apw> swair, ok it came in via stable v3.16.7 ... so sort of in 3.16
<apw> it is therefore in ubuntu 3.16 based kernels
<swair> ok., though i got the tar from kernel.org/pub/linux/kernel/v3.x/linux-3.16.tar.gz. it wasn't there. 
<apw> swair, but regardless, if we don't know how you are incanting at it, we are not going to be able to hel
<apw> help
<swair> apw:  i had gcc5 installed. so i installed gcc4.8 as /usr/bin/gcc-4.8. Set CC to as that and just make 
<apw> it might help most if you pastbin a transcript of your how you did that
<apw> and the errors etc it produces
<apw> as CC=x is one thing, export CC=x is another, and likely make CC=x is a third
<swair> i did: export CC=/usr/bin/gcc-4.8
<swair> well, right now i fixed the issue by just copying compiler-gcc5.h from the 3.18 tree. 
<swair> and it worked
<apw> swair, yep, what bit actually failed?  as the kernel uses two compilers the host and target compilers, and CC only overrides one
<swair> should i have set HOSTCC as well?
<apw> maybe, but i keep saying tell me what error you got, and maybe we can tell
<swair> sorry, just a sec.
<apw> or we could ask and answer questions for 40 minutes, oh no i won't be here to do that
<swair> apw: http://pastebin.com/ifu80YdW
<apw> yeah thats HOSTCC ... set that too
<swair> yeah. so why two different compilers? hostcc and cc? 
<apw> it is building host tooling to build bits of the build
<apw> the hostcc is building things to run on the building machine to make bits of the build
<apw> the cc is building bits for the machine which run it
<swair> ahh ok. thanks for the help!
<apw> when doing a cross-compile they are not the same
<swair> ok
<awreece> is there an easy way to see the socket options on one of my processes?
<awreece> i've looked around a while and can't see anything obvious
#ubuntu-kernel 2015-06-13
<apw> awreece, it must be visible somewhere check-point restore can get it out
<TJ-> apw: finally managed to a get a kernel build running for bisect; had to fight out-of-date/incomplete instructions in the Wiki :) Once I'm sure it's all completing correctly I'll bring the wiki up-to-date
<apw> TJ-, great, those of us who know how no longer see the errors
<TJ-> indeed... it's a few years since I focused on Ubuntu kernel  tools :)
<TJ-> spoke too soon! "ld: final link failed: No space left on device"
<apw> now that i don't think is our fault :)
 * TJ- sniggers 
<TJ-> apw: Oh it is - you should make sure it doesn't gobble up 10GB during a single-arch single-flavour build :)
<TJ-> apw: thankfully we have lvextend and resize2fs
<apw> TJ-, life savers for sure
<TJ-> apw: before I start digging, any ideas on this failure? "ld: BFD (GNU Binutils for Ubuntu) 2.24 internal error, aborting at ../../bfd/merge.c line 877 in _bfd_merged_section_offset"
<apw> TJ-, other than its the compiler barfing on its own input, no
<apw> not seen that specifici fail
<apw> are you building in a clean chroot for the series this is being build for ?
<TJ-> apw: I think maybe that was a by-product of the out-of-disk space... probably a truncated object file. I just restarted the build from clean. I'm not building in a chroot
<apw> TJ-, yeah could easily be indeed, i always use a chroot, they are so much more predictable
<TJ-> Had another bisect build fail: "II: Checking modules for lowlatency...previous or current modules file missing!"  despite starting the build with AUTOBUILD=1 which, in "debian/rules.d/0-common-vars.mk" is supposed to set skipmodule, skipabi, etc., to true *but* the fail is because $(skipmodule) isn't set in  "debian/scripts/module-check" (line 21)  when it is called from debian/rules.d/4-checks.mk (line 16)  - is something else going on I'm not aware of ?
<TJ-> Despite the AUTOBUILD=1 I've had to add "skipabi=true skipmodules=true" to get those options recognised
<TJ-> Grrr! I'm going back to bed! right at the end, packaging: "error in 'Version' field string '3.16.0-1.1~bisect_01': invalid character in revision number" ... like playing snakes and ladders :s
<apw> TJ-, the autobuild=1 has likely been broken as its not somehting we commonly use ..
<apw> TJ-, yeah some of those things it could check earlier, we did add some early checks for config
<TJ-> apw: I'll add them as mini projects to me TODO list since all the kernel build documentation conspicuously refers to AUTOBUILD
<apw> TJ-, feel free to file a bug against linux saying it AUTOBUILD doesn't seem to work, and let us know the bug # here
<TJ-> apw: I'll do that once I've figured out the fix and provide a patch
<apw> TJ-, at
<apw> ta even
<TJ-> Looks like Steve Conklin's advice in KernelBisection to add a ~xyz to the version number breaks  package creation. Getting errors because the full version string isn't being found in 'control' - because the version assigned in 'rules' $(abinum) and used to replace ABINUM in the templates only contains <kernel-version>-<ABI>.<upload> and drops any ~xyz but the build system does use the ~xyz in creating directories, version strings in object code, etc.
<TJ-> I'll fix up those docs; the short answer is always use "fakeroot debian/rules AUTOBUILD=1 ..." *not* "AUTOBUILD=1 fakeroot debian/rules ..."
<TJ-> Next bug... building "binary-indep" (to generate the independent header package) fails due to 'do_tools_usbip=true' (set from 'debian.master/rules.d/amd64.mk') but supporting file "$(builddirpa)/tools/usb/usbip/autogen.sh" is missing. Had to add "do_tools_usbip=false" to the 'debian/rules' command-line
#ubuntu-kernel 2015-06-14
<trippeh> Yay, the new wireless-regdb in wily, installed on vivid, upped 2x2 ultrabook wifi from ~105Mbps to ~305Mbps
<trippeh> TCP throughput
<pkern> trippeh: which country?
<pkern> I guess that's AUTO-BW.
<trippeh> pkern: Norway. It's availability of 80Mhz wide "channels"
<trippeh> iwlwifi could also get confused and fall back to 802.11n when it saw a 80Mhz wide network
<trippeh> instead of just continuing 802.11ac but using 40Mhz
<trippeh> pkern: it was missing a load of VHT80 updates for a bunch of countries that landed upstream in Q4 2013, and more recently VHT160
<pkern> trippeh: I see. Thanks!
#ubuntu-kernel 2016-06-13
<ppisati> ogra_: me and slangasek just went in your room to talk about rpi3 img
<ppisati> ogra_: you should have a word with slangasek 
<kees> hrm, what's the current command to build local kernel packages out of the xenial kernel git? I'm using:
<kees> DEB_BUILD_OPTIONS=parallel=32 AUTOBUILD=1 NOEXTRAS=1 skipabi=true fakeroot debian/rules binary-generic
<kees> But I fail with:
<kees> dpkg-gencontrol: error: package linux-image-4.4.0-24-generic not in control info
<kees> dh_gencontrol: dpkg-gencontrol -plinux-image-4.4.0-24-generic -ldebian/changelog -Tdebian/linux-image-4.4.0-24-generic.substvars -Pdebian/linux-image-4.4.0-24-generic -Vlinux:rprovides=, spl-dkms, zfs-dkms returned exit code 255
<kees> but I can't see why :(
<kees> ah, nm, PEBCAK
#ubuntu-kernel 2016-06-14
<funman> hi
<funman> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc3-yakkety/BUILD.LOG (warning: 13MB) shows package is built with do_tools=0, thus no linux-tools deb being built. Why not?
<funman> saving server time?
<arges> funman: The mainline builds are meant for testing. I'll highlight apw ^^^ since he maintains this script.
<apw> funman, primarily because the tools (at least used to) not build in mainline kernel without patches; also they are not crossbuildable
<smoser> what is expected kernel version for yakkety ?
<funman> apw: i see, thanks
<smb> smoser, 4.8
<smoser> smb, thanks
<smoser> oh. hm..
<flocculant> hey all - that really nice davmor2 chap told me that this might be a place to help us with bug 1568604
<ubot5> bug 1568604 in xserver-xorg-video-intel (Ubuntu) "Mouse cursor lost when unlocking with Intel graphics" [High,Confirmed] https://launchpad.net/bugs/1568604
<nusch> Hello, after last dist upgrade my Dell XPS13 is not longer bootable. I'm geting Out of memory kill on very early boot, it kills lvm, crypto related processes destroying my date. The reason is somehow connected with GPU, adding boot option noplymouth allows me booting to X, but it is killed after second due to setups of VTs. To debug it further i first need way to clean start and shutdown, now every bo
<nusch> ot kills more data (especaily corrupt kernel modules) and ads aditional problems. What can be reasons that out of memory killer doesn't kill only process with higherst memory usage, is it by design, or am I misunderstanding sth ?
<nusch> I suspected hardware, but fscked the disk on desktop, and I'm able to run liveUSB(Kali Linux)
#ubuntu-kernel 2016-06-15
<cyphermox> apw: ping; about that mirroring of MokSBState as MokSBStateRT in sysfs; so we can see when Secure Boot is enabled but that validation is disabled in shim
<cyphermox> apw: as I was saying; shim will eventually provide that variable; but for the time being it would be good if the kernel should put it in sysfs; that will mean less prompting to disable SB when SB is already disabled :)
<cyphermox> needs to happen on all releases with the kernels.
<apw> rtg, ^
<rtg> cyphermox, ack
<cyphermox> rtg: ack
<rtg> cyphermox, 
<rtg> rtg@ubuntu:/proc/sys/kernel$ cat secure_boot 
<rtg> 1
<rtg> rtg@ubuntu:/proc/sys/kernel$ cat moksbstate_disabled 
<rtg> 0
<rtg> cyphermox, is that sufficient ?
<apw> cyphermox, is that mok...._disabled the same "True/False" way round as the shim change ?
<cyphermox> well, the shim change looks for a real MokSBStateRT variable just like all the other UEFI vars
<cyphermox> but that could work too, provided I add the hooks in the script
<cjwatson> Does anyone have access to the logs of Brad's bug bot thing that deals with proposed tracker bugs?
<cjwatson> It has been doing something very very strange to bug 1591458 which caused a partial Launchpad outage
<ubot5> Error: Could not gather data from Launchpad for bug #1591458 (https://launchpad.net/bugs/1591458). The error has been logged
<apw> cjwatson, oh ..
<cjwatson> You can't see it on the bug index page, but it made about 15000 changes flipping the status of kernel-sru-workflow/security-signoff back and forth
<cjwatson> It seems to have stopped doing that, but uh
<apw> cjwatson, bjf thinks that was a state flipper gone mad, and he thought he had stopped it a couple of hours ago
<apw> cjwatson, "bjf: oops sorry"
<apw> cjwatson, we do belive the issue is fixed, and if you arn't seeing it any more, that is good
<apw> cjwatson, we are talking about making sure we don't make this class of errors
<cjwatson> apw: OK, thanks.  Figuring out how to clean it up at the moment.
<cyphermox> apw: is that really "True"/"False", or 0/1 ?
<cyphermox> nevermind, I fail at remembering
<manjo> apw, any idea when we might see a 4.7 in unstable ? 
<cjwatson> apw: (cleaned up)
 * lamont as an ipv6 trusty/xenial question...
<lamont> no firewalls involved, 3.13.0-83-generic and 4.4.0-24-generic kernels.
<lamont> ping6 "ip on the other machine on the common subnet" ==> neigbor solicitiation, but no reply.  But only sometimes.  thoguhts/
<lamont> ?
<lamont> and if I poke things with tcpdump enought (can you say promisc?), then all of a sudden it works, until later when it stops agsin
<lamont> and, of course, not currently reproducible
#ubuntu-kernel 2016-06-16
<apw> lamont`, hmmm that is interesting, i have been having some ipv6 issues at home where i find i don't always get ipv6 addys at all bouncing the interface fixes it -- i had been blaming network-manager for scortch-earthing the interface, but perhaps it is related
<apw> lamont`, and that would be involving a 4.4.0-24 as well
<xnox> apw, yeah don't rebuild d-i in stable for kernel uploads because seeds and hwe kernels make it hard
<xnox> ben_r, https://code.launchpad.net/~xnox/launchpadlib/fix-1471927/+merge/264480
<xnox> ben_r, so is that working?
<ben_r> xnox: testing it right now 
<lamont`> apw: ta.  I'll try to get better isolation next time it happens
#ubuntu-kernel 2016-06-18
<nabukadnezar43> hello is it possible to boot mini.iso with secure boot support? i can boot it in uefi mode but i cannot load modules because they aren't signed
<nabukadnezar43> do i have to create my own initrd?
#ubuntu-kernel 2017-06-12
<sovereignentity> kernel 4.4.0-64 errors out I have to 4.4.0-62 to log in
<apw> sovereignentity, file a bug against linux and get that information into it, in particular include the error
<smb> -64? sounds a bit backwards, -79 is current
<apw> a good point
<zxliu> I take it there haven't been many customers lately?
<zxliu> for the paid support packages
<zxliu> if the samples aren't working they can't get hooked
<zxliu> nope doesn't boot t
<zxliu> it was a broken helper most likely
<zxliu> xfs
#ubuntu-kernel 2017-06-13
<lucnx> How does one debug the ubuntu kernel once it is compiled
<alkisg> Hi, with an ubuntu 16.04.2 live CD I'm getting 100 times slower *write* speeds in both HDD and SDD, compared to an 12.04.3 live CD
<alkisg> dd if=/dev/zero of=/tmp/sda1/test bs=1M count=1000 => 600 MB/sec in 12.04.3, and 6 MB/sec in 16.04.2
<alkisg> The read speed, measured e.g. with hdparm, is unaffected
<alkisg> Where would I report that issue, and which info would I need to include?
<apw> alkisg, file a bug against the kernel with the details of the kerenl versions in each
<apw> and paste the bug number here, so we can find
<alkisg> (just tried with 4.4 and it works fine)
<ogra> hmm, i have an arm board with no wlan on board that always loads the cfg80211 module unconditionally ... and obviously that resets the network all 360 minutes ... if i unload or  blacklist the module this doesnt happen 
<alkisg> Thank you apw, against ubuntu-kernel or upstream kernel?
<apw> i'd start against the ubuntu kernel (ubuntu-bug linux)
<alkisg> Thank you very much, will do so
<cking> alkisg, and I'll pick that bug up and look into it
<alkisg> cking: thank you very much; I will do it tomorrow because the school that has that issue has closed for today. It was on a asus prime b250 plus motherboard.
<cking> alkisg, ok, if you can provide info on the H/W and memory size and media you are using in the bug report then that would be helpful
<apw> cking, i am suspicious this is a media kernel issue only
<apw> if we were seeing it with updated machines we would have a lot of whining in our lives
<cking> apw, indeed
<user14241> Hi! I just installed mainline kernel from drm-tip, arch amd64, version 994. The problem is that pulseaudio and alsa do not detect my soundcard, its snd-emu10k1. I can find the driver in/lib/modules/4.12.0-994-generic/kernel/sound/pci/emu10k1 however. Any ideas?
<user14241> I am using Ubuntu 16.04 lts
<user14241> "aplay -l" only returns hda-intel, but lspci sees the card fine. It also works with regular HWE kernel (4.10), but I need newer kernel due to radeon-related crashes.
<apw> user14241, the only advice i can think of it to try modprobe'ing the driver manually and see what it says about your card
<user14241> apw, I have, but no output in dmesg|tail. However, I found this manually grepping the kern.log:
<user14241> "[   35.659024] snd_emu10k1: probe of 0000:06:00.0 failed with error -14"
<user14241> thanks..
<apw> -rc tips like that often have horrible bugs, and they get resolved "later"
<user14241> apw, well the three "drm-next" from the tail do not even boot.
<apw> yep, doen't supprise me they are built so they can be tested to find that kind of boot issue
<user14241> 2017-06-07 hangs, 2017-05-31 and 2017-05-30 draw a white line on black screen right after boot, and hang
<user14241> apw, can you suggest a drm-next that does would boot? :)
<user14241> "does would"->would
<apw> user14241, heh, no not something i keep tabs on, we make those for the graphics dudes
<user14241> apw, thanks. Is there a difference between "4.12-rc" and "drm-next" kernels, or are they same?
<user14241> I am just looking for newer radeon code
<apw> user14241, yes the drm-next have whatever the drm people are intending to merge in the next merge window
<user14241> the 4.10 and 4.8 are very unstable on R9 280
<apw> so right now 4.13 planned stuff
<user14241> apw, ah, so "drm-next"  with 4.12, is newer than "v4.12-rc"* ?
<apw> well you never know what they are based on it, could be a random 4.11, but normally yes
<apw> it is the drm maintainers testing tree, it has whatever they want
<user14241> I think I should have more lucky with 4.12-rc (non-drm-next).
<user14241> yes, it definitely has a broken audio driver (but hdmi on  tahiti gpu detected fine) in "tip" and "drm-next" does not even start.
<user14241> apw, anyways, thank you very much. Looks like I got myself a borked kernel. :)
<user14241> apw, thank you, all the best to you!
<tomreyn> would anyone know how to trigger a canonical livepatch run after it failed to apply?
<tomreyn> this software is pretty good in not disclosing how it works :-/
<cjwatson> tomreyn: "sudo pkill -HUP -f canonical-livepatchd" should do it
<cjwatson> tomreyn: (disclaimer: I've never worked on the livepatch client, and this is just from looking through the slightly old copy of the code that I have access to)
<cjwatson> tomreyn: but the copy I can see has a SIGHUP handler that does just a check-and-apply-if-possible and nothing else
#ubuntu-kernel 2017-06-14
<ogra> uh, oh ... 
<ogra> the current linux package has all the config scripts (splitconfig.pl etc) set to non-executable 
<ogra> debian/scripts/misc/../config-check: Permission denied
<ogra> (thats what i get after running fdr editconfigs on a xenial source package ... (before there was the same error about splitconfig.pl whihc i manually made executable)
<ogra> something seems to have dropped all exec bits in the scripts dir
<ogra> apw, ^^^ want a bug ? 
<ogra> (thats with 4.4.0-80 on xenial)
<apw> ogra, nope that is expected ... you should be working in the git tree not a source pacakge
<ogra> pffft 
<apw> ogra, or fi you are working in the source package you need to know debian packages lose execute bits on things, because diff
<apw> i suppose we might be able to fix that with the reconstruct stuff, maybe
 * apw will card that
<ogra> well, it used to work in the past ... thats definitely new behaviour
<ogra> (and it breaks all the cross compilation howtos that use the source deb )
<apw> ogra, that is definatly not new behaviour, it always does that for any package with a .orig, and has since i join 10 years ago
<apw> it _only_ breaks changing the config, not building
<ogra> well, i did re-build the deb since years when trying out stuff on arm 
<apw> as we do not assume or need executable bits on those
<ogra> which always includes editconfigs when i do that 
<ogra> so i'm sure this used to work (though admittedly i dont think i cross built a kernel since trusty)
<ogra> but well, i'll hack in the exec bits ... 
<apw> yeah hackedy hack
<ogra> hrm ... 
<ogra> config-check freaks out ... amout arm64 and powerpc ... which i didnt even touch 
<ogra> *about
<ogra> wow, even when i start from zero and run editconfigs without doing any change it explodes
<ogra> apw, oh, ignore me ... 
 * ogra just noticed https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel#Modifying_the_configuration
<ogra> :P
<apw> ogra, i am always willing to ignore you :)
<cjwatson> apw: exec bits> only true for source format 1.0; 3.0 preserves exec
<apw> cjwatson, true enough, we are very backward in that sense
<apw> cjwatson, not that 3.0 preserves everything either, wihch is annoying
<cjwatson> apw: ogra probably perceives it as new behaviour because at various times in the past the kernel has been a native source package
<apw> cjwatson, most of the time in devel too
<ogra> oh, it isnt native anymore ? i didnt even notice that 
<ogra> but yeah, that would explain it 
<apw> ogra, once it has an .orig it isn't native ... which occurs at release of the base kernel version
<ogra> apw, right, but it used to 
<apw> each new devel kernel is native, then gains an orig before release
<tomreyn> thanks for the help some ~ 20 hours ago, CJ
<shewless> Hello. running the hwe kernel for 16.04.2.  Looking at this problem: http://people.canonical.com/~inaddy/lp1328088/.  Basically linux namejspace creation is slow.. which is causing me problems with my openstack deployment
<shewless> Trying to play around with kernel options related to RCU_NOCB_CPU and rcu_nocbs= but not having much luck so far
<shewless> wondering if someone can help make sure the options I'm setting in grub are taking effect
<shewless> We've seen that creating namespaces (multiple) is less efficient on systems with more cores.. so a 1 core system does way faster than a 40 core system
<shewless> I tried to do this to force these RCUs to happen only on CPU 3 but it didn't seem to do anything for me: GRUB_CMDLINE_LINUX_DEFAULT="CONFIG_RCU_NOCB_CPU_ALL=n isolcpus=3 rcu_nocbs=3"
<shewless> do I need to build the kernel myself with some options enabled in order for this to work? I'm open to that but not sure what options I would need to enable
<shewless> hmm I suppose since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=728dba3a39c66b3d8ac889ddbe38b5b1c264aec3
<shewless> that RCU stuff won't be valid.. since it's not using rcu_lock anymore 
<shewless> hmm. rcu_lock is still used in some of that code so it might have an impact?
#ubuntu-kernel 2017-06-15
<alkisg> cking, apw, hi, I currently have remote access to the school that had that disk issue. The exact symptoms are that disk writes start at e.g. 200 MB/sec on an HDD, and after some time, they become 2 MB/sec, without going back to 200 MB even if we leave it for hours (was suspecting temperatures). This happens on 4.4 and 4.8 (xenial), but not on 3.2 (precise) or 4.2 (trusty).  I've seen this in another case a few months ago, but I had dismissed it 
<alkisg> What I'd like to ask is, apart from `ubuntu-bug linux`, should I test or collect something else, since I won't frequently have remote access to the school?
<alkisg> My test case is dd if=/dev/zero of=test bs=1M count=1000 conv=fdatasync; then cp -a some-20gb-folder; then dd again => and there it's slow and never gets fast again
<cking> alkisg, so what happens if after that initial dd you sync and re-run that test?
<alkisg> cking: it degrades gradually, e.g. starts from 200, then 190, then 100...
<alkisg> It also happens on their SSD, it's not related to the media
<cking> alkisg, so I guess what is happening is that initially the writes fill up the cache and so it appears to be writing fast, but as the cache gets full you get band width limited to the speed of the block device 
<alkisg> cking: echo 3 > /proc/sys/vm/drop_caches would tell me that, wouldn't it?
<alkisg> It's an amazing difference, 200 mb/sec to 2 mb/sec, which makes the system completely unusable
<alkisg> I don't think it's related to caching, I've never seen something similar except for those 2 cases...
<alkisg> And, it happens only with 4.4+, not with previous kernels
<cking> alkisg, so, lets factor out the cache and just do the dd with conv=direct and see what speed you get
<alkisg> cking: ok, let me instruct the school to reboot with 4.8, as now it's with a trusty live cd that works fine. I can also give you reverse vnc if you like. Reporting in 2 mins...
<apw> cking, note these are CD boots so with whatever is on the media
<alkisg> (of course I'm dd'ing to the disk, not to RAM/overlayfs...)
 * cking finds a fungible machine to try this out too
<alkisg> I've tested about 100 installation so far, so this issue should be quite rare...
<cking> alkisg, so whats the failure rate, e.g how many times have you seen it not working efficiently?
<alkisg> cking: it 100% reproducable, what varies is that it might need 20 GB of writes before it starts to happen, or 80 GB of writes
<cking> alkisg, I mean, of all the machines it's been installed on, how many exhibit this issue?
<alkisg> I've only seen that issue in 2 machines. I've installed 16.04 in about 100 machines so far.
<cking> alkisg, if you can add the machine info to the bug report than that may give some hint on what kind of common H/W issue it is related to
<alkisg> cking: I've remote access to their xenial/4.8 installation now, freshly booted (it's not a live cd). I can give you reverse vnc if you like. Should I start with some test, or with ubuntu-bug linux?
<cking> reporting the bug 1st would be a good start
<ubot5> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<alkisg> ty, doing so...
<alkisg> https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1698118
<ubot5> Ubuntu bug 1698118 in linux-hwe (Ubuntu) "Slow disk writes after some uptime, only on certain hw and 4.4+ kernels" [Undecided,New]
<knowhow> good day
<knowhow> how do i patch a kernel? with an rt patch
<knowhow> ?
<knowhow> i donloaded the newest rt patch
<knowhow> and something that looked as the kernel from kernel .org
<knowhow> in a gz format
<knowhow> of course the thing that seemed to be the kernel isnt the kernel...it is just a source file..
<apw> knowhow, if you want to apply a patch, that applies to a source tree
<apw> knowhow, if you want to apply it to the ubuntu kernel, you want to get the kernel for the series on which
<knowhow> i am not a linux expert...so here what i did
<apw> knowhow, you intend to patch, preferably by checking out the git repo for that series
<knowhow> i am clueless about what you just said
<knowhow> i know what git is if that makes a difference
<apw> knowhow, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<apw> knowhow, you are trying to do something deeply hard, and deeply distro specific, with a very big patchset
<apw> knowhow, you would want to have a good knowledge of the platform before even considering attempting something like that
<knowhow> this is what i have to apply
<knowhow> https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/
<knowhow> it is the 4.30.rc1 way down in the list
<knowhow> i am on ubuntu 16.04 am i am used with .deb files
<knowhow> so what do i download from where to apply this rt patch to?
<knowhow> beacause this:
<knowhow> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
<knowhow> contains no kernel source code
<knowhow> it is just a file in a gz format
<knowhow> i donloaded them from graphical environment...from firefox that is
<apw> knowhow, depends what you are trying to achieve, if you want to apply it to an ubuntu kernel, you would want to pick the ubuntu source tree git respository for 16.04 and apply it there
<cking> knowhow, have you considered using the low-latency kernel?
<apw> of course there is almost no way it will apply to anything other than 4.9 which is not a kernel base ubuntu picked
<knowhow> i allready have it installed ..that came in a deb format
<apw> you have RT installed already in deb format ?
<knowhow> for a sound card it probably works....but i have a cnc on a parallel port
<knowhow> no not rt
<knowhow> low-latency but from what i hear it is not good enough
<apw> not good enough for what
<knowhow> and i am not going to compile linuxcnc against that...i need to build one from scratch apply rt patch to it and install it...so i can boot it with grub customizer when i need it
<knowhow> apw...i said in the rows above...but i will repeat....linuxcnc
<cking> knowhow, you may find using the low-latency kernel with the application running with the FIFO or RR real time scheduler with a high priority is probably more than good enough 
<apw> i think you over estimate just how much information about you and your plan i have in my head
<knowhow> what?
<apw> but, if you want to build an rt version of an ubuntu kernel, you need to apply that patch to the ubuntu-kernel
<knowhow> apw are yoy some kind of inteligent AI?
<apw> you are runnig on your system, and then build it
<knowhow> am i talking to a real person here?
<cking> knowhow, apw is a real person for sure
<knowhow> ok lets start from begining
<apw> that wiki link tells you how to get the git repositories you need to do that
<apw> and you had better know how to apply a patch if you are going to succeed in this endevour
<knowhow> i have the linuxcnc source...the sitee with instructions how to instaall it
<knowhow> i reached the step where the new kernel has to be prepared...i cannot screw up the one allready installed...just in case something goes horribly wrong
<cking> knowhow, that site states "optionally with realtime extensions", so you may not need RT
<knowhow> i can boot from the one not touched
<knowhow> i need it for operating the real machine...i do not need it for simulations
<apw> "simple installation on ubuntu" if you have to build your own kernel and apply rt to make that happen it is falling far short of "simple"
<knowhow> it will cut itself instead of the metal piece....and guys you dont want skynet in real life do you?...so help a stranger here :)
<knowhow> i need to know what source do i download for the patch and from where?
<apw> as i say if what you want is an ubuntu kernel with RT you need to get the kernel source git repo for your series, you need to get the nearest RT patch set, and you need to apply it
<knowhow> i will give again the link for the patch
<knowhow> https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/
<knowhow> and in the list is the newest 4.9.30.rc1
<apw> right but ubuntu doesn't have a 4.9.<anything> kernel, so if you want to have an ubuntu base you will need to apply it to 4.8 or 4.10, or use a 4.4 base with the rt for that
<knowhow> this wwill make the kernel realtime...now i need to know which is the newest stable kernel for ubuntu that can accept this patch...and the commands to apply it safely...and then compile it
<knowhow> and after that installing it of course...or make it a deb file for later easy use
<apw> there seems to be 4.4 and 4.8 bases for RT so as long as you are running one of those
<apw> i would recomment you use the latest RT for one of those
<knowhow> right now i run 4.7...on ubuntu which gets updated...regularily
<apw> as 16.04 was xenial and the GA kernel was 4.4, that would seem to be a lodical choice
<apw> knowhow, then you arn't running a kernel we produce
<apw> and you wouldn't be getting updates for 4.7 either (from us)
<knowhow> yeah but linus....updated it and i just grabbed the newest deb there...generic...and the low latency
<knowhow> they both work fine...but where do i get the latest stable generic source so i can apply this patch to it?
<knowhow> i instaalled them both...and with grub customizer i can boot which one i want
<apw> where do you get your mainline .debs now ?
<apw> as they should be offering you some route to source in those
<knowhow> hhold on i probably have the links somewhere
<apw> as i am sure it is not linus who is producing .debs, he is a fedora man iirc
<knowhow> aah no..no no....this got to be a serrious joke....is the latest stable version 4.11 ?....i checked the site two months ago and it was 4.7 or something
<knowhow> anyway here s the link
<knowhow> https://www.kernel.org/
<apw> and yo got a .deb form there ?
<knowhow> but the rt patch does not get updated that quickly so i am going to use the kernel coresponding its version
<apw> v4.8 was released in october last year
<apw> so if you are going to try and construct a kernel source at 4.9.30 then i would clone linus' tree, checkout v4.9 and apply the delta patch from kernel.org
<knowhow> apw....it is seems aliens  or mr smith from matrix ate the link from which i ....
 * cking notes one can build .debs from the kernel source using:  make deb-pkg INSTALL_MOD_STRIP=1
<knowhow> anyway ....i just got my eyes opened with a can opener
<knowhow> cking how do i do that ? by including ALL and imean ALL the dependencies that a ffresh install of ubuntu without internet conection?
<knowhow> i do not find the 4.9.30 version on here
<knowhow> https://www.kernel.org/
<apw> knowhow, pick the URL for the patch for 4.9.32 and adjust it to say 30
<knowhow> apw...won't that screw up shite up...the patch is intended for 4.9.30 man...i do not want to ruin my ubuntu installation
<sforshee> knowhow: use this link - https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.30.tar.xz
<knowhow> i do not know how to remove bad kernels yet
<apw> knowhow, no i am saying to make the url like sforshee has said
<knowhow> ok are you a wizard or something? how did you find that?
<apw> he took the URL which is published there for any version on the page, and changed the version to the one you wanted
<sforshee> right, copy the link on git.kernel.org for 4.9.32, then paste it and change the 32 to a 30
<knowhow> but it doesnt show on the page
<sforshee> right click the link and select the "copy" option
<sforshee> knowhow: it seems linuxcnc has a custom distribution you can install, why aren't you just using that?
<knowhow> well...for now i just found the source for my patch and i am going blind for a month now :|
<sforshee> knowhow: http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html#_installing_linuxcnc
<sforshee> or http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html rather
<knowhow> sforshee....no no no my man....no bad advice there...i have a 8 core laptop ...and i want to friggin' use it
<knowhow> i've been recommended that but i do not want to fill my house with computers
<apw> heh that will take a few hours to build it i suspect
<knowhow> and is old anyway
<knowhow> apw...yeah but that is why 8 cores and 32 gigs of ram should make it just couple of hours...but after that i have it for life
<knowhow> no?
<knowhow> it is a dell precision m6600 whith the docking station
 * apw tries to imagine a kernel lasting weeks ... heh
<knowhow> when i do not operate the cnc machine i use the low latency kernel to develop the  open source sound card
<knowhow> on low spec pcs probably lasts a day or so...
<sforshee> knowhow: if you use that link and apply the rt patch that should get you the source tree you need, building is much much more difficult than that though if you've never done it before
<knowhow> i have allready downloaded it and the patch too...i am going to apply it and compile it tomorow..beacause now it is evening
<cking> sforshee, to be fair, if one slams in the nearest ubuntu config into that tree and then build with  make deb-pkg INSTALL_MOD_STRIP=1 it may just spit out the required devs
<cking> *debs
<sforshee> cking: only if there are not config changes needed
<cking> sforshee, true, but one just answers the relevant questions on the config step and one is done
<knowhow> do i need anything else to know?
<cking> you may need several GB free to do the build
<knowhow> the steps should be apply patch....compile kernel....and make deb file for easy install in the future
<cking> knowhow, the make dep-pkg step will build and package the kernel in one go
<cking> *deb-pkg
<knowhow> cking...say what?....gigs???....what i just downloaded has 88 megs....and the patch has 300 kilos
<knowhow> cking i allready cpied that line in a notepad file :)))
<ivan> several gigs more like 30GB
<cking> yeah, my last build was 28GB
<knowhow> ckiing....i have a terabyte of sda1 and another one sda2 that means two terabytes....but...
<knowhow> how in the name of actual f u k ....can a 88 megs and  300 kilos can take 30 gigs?
<knowhow> i dont know...i am just asking
<knowhow> as i mentioned...i have the space...but....nimoy would say that this is highly ilogical
<knowhow> how can 88 megs...ok 89....can become 30 GB?
<sforshee> knowhow: 88 megs is compressed, the source is much bigger after decompression, then all the files produced by building take up space
<cking> knowhow, and compiled code with all the intermediate object code uses up a load of space
<knowhow> i know it takes more space....but THAT much?
<knowhow> i compiled files for microcontrolllers....and they take less space after compilation
<knowhow> oh i forgot about the object code....but stil...THAT much?...
<cking> ..and there a many modules being built = lots of code
<knowhow> i played with c++ on win but....30 gigs...you mean my deb file is going to be 30 gigs?
<knowhow> :|
<ivan> no
<cking> knowhow, no, the final deb files will be tens of MB, don't fret over the intermediate data being generated during a build, it's the final product you need to concern yourself about
<knowhow> ooh those are going to be like a buffer in the process of compilation and after it finshes it erases that...intermediate data yeah....that was the expression
<knowhow> i set the swap file to the size of the ram anyway for a good measure
<knowhow> :)))
<knowhow> that is 32 gigs
<knowhow> it will probably never be used
<knowhow> so do i put the gz patch in the same directory of the 88 megs file that i just downloaded?
<knowhow> the rt one that is?
<knowhow> cking
<knowhow> ?
<knowhow> well in a copy version of course just in case murphy shows up to see what i am up to?...as usual :))
<cking> knowhow, you uncompress and untar the kernel source, cd into the kernel source then apply the patch using patch -p1 < name-of-patch-file
<cking> if you are in luck, the patch will apply cleanly and then you can build the kernel
<knowhow> but the gz patch has to be in the uncompressed 88 megs folder right?...well the bigger version after decompression
<knowhow> do i need to check for build-deps or something?
<knowhow> i allready checked for linuxcnc from the linux cnc source folder
<knowhow> so that is prepared
<cking> knowhow, to be clear:
<knowhow> yes?
<cking> uncompress the kernel source and untar it
<knowhow> ok
<cking> uncompress the patch, and to make things easy move it into the kernel source directory
<knowhow> uncompress=untar
<knowhow> what i do after that with the rt patch gz file?
<cking> with the uncompressed patch file, apply it using patch -p1 < name-of-patch-file (what ever the name of the file is)
<cking> if you are in luck it will apply cleanly
<knowhow> but where the gz file needs to be for that command to be successful?...in the linux kernel source folder?...the one i just untared?
<cking> yep, in the kernel source directory
<knowhow> i am not to good with cli paths so i use graphic mode to copy everything in one place 
<knowhow> ok got it
<cking> knowhow, you need some cli know-how to apply patches, get the .config sorted and to build and install the kernel for sure
<knowhow> well after the patch is going applied well....that is the next order in line...and probably the site i got the instructions from will explain more on that part
<knowhow> but first in row....thank you apw....for the linux 4.30 kernel source file that coresponds with my patch
<knowhow> and then some serios thanks goes to you cking...for explaining some basic command and file ,folder placements that for the expert is trivial but for a newbie like me isnt
<knowhow> i copied the steps of placing everything where it needs to be too...in the notepad...so i do not have to ask again the same things later
<cking> lets hope it all works out OK :-)
<knowhow> so big thanks for apw....cking...and the rest of the forum for the courtesy shown
<knowhow> i hope so too...if not...i will sure come crying like a litle big baby back here again :)))
<knowhow> if it dosnt i am not ruining a good installed kernel anyway
<knowhow> thanks again....and i will come again for the updates about the issue
<cking> cool
<immu> Add new softlockup stressor, use with caution(!) ??? 
<immu> how can i install Unstable updated to 4.12-rc5 on 17.04 ?????
#ubuntu-kernel 2017-06-16
<knowhow> hello again
<knowhow> cking
<cking> knowhow, hi 
<knowhow> i had to decompress the tar xz in root...you could have give a gz link you know :))
<cking> xz takes less time to uncompress
<cking> I mean download
<knowhow> the patch also needs to be uncopressed it seems and has to be in the kernel folder...literaly the kernel folder
<cking> well, to make it easier you can do that
<knowhow> from the kernel directory i typed the following comand: patch -p1 --verbose ../patch-4.9.30-rt21.patch now i see a rectagular white thing
<knowhow> how long does a patch needs to be applied?
<knowhow> it is allready 5 minutes
<cking> try: patch -p1 --verbose < ../patch-4.9.30-rt21.patch
<cking> hit control-C to stop what you have running and use the above ^
<knowhow> and --verbose should have give me more than a terminal rectagular prompt shouldn't havewith the < ?
<knowhow> didn't see that in instructios
<knowhow> cking ? did ommision of the < screwd things up?
<cking> knowhow, without the < the patch command was just trying to pull in a patch from standard input rather than the file
<cking> I suspect it is OK
<knowhow> well...i still see a prompter with nothing else...should i stop it and use the <   ? or let it a little more ?
<knowhow>  my concern is that -- verbose parameter should have said more than he rectagular white prompter flashing no?
<knowhow> which i still see
<knowhow> and i have an 8 core i7 darn it :))
<knowhow> well..four real ones anyway :|
<knowhow> cking ? i applyed the command from the kernel directory where i copied the patch also
<knowhow> but the copy i did it with sudo nautilus
<sforshee> knowhow: yes you need to stop it and use the <, it's never going to do anything the way you've run it
<knowhow> doing it now
<cking> yep, hit control-C now, and run patch -p1 --verbose < ../patch-4.9.30-rt21.patch
<cking> the "prompter" is called a cursor
<knowhow> no such file or directory and i see it there with my own eyes :|
<cking> oh, it may be in the current directory, so try: patch -p1 --verbose < patch-4.9.30-rt21.patch
<knowhow> should i do it with sudo ?
<knowhow> you are absolutely right it is in current directory....damn you grammar :)))
<knowhow> pardon me it s syntax :))
<knowhow> patch -p1 --verbose  < patch-4.9.30-rt21.patch Hmm...  Looks like a unified diff to me... can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt |index 3a3b30ac2a75..9e0745cafbd8 100644 |--- a/Documentation/sysrq.txt |+++ b/Documentation/sysrq.txt ------------------------
<knowhow> that is the command + error
<knowhow> now
<knowhow> cking
<cking> knowhow, what is in the current directory?
<knowhow> the current directory is kernel
<knowhow> and in it is the patch uncompressed
<cking> ok, you need to cd into the kernel directory
<cking> and then run:  patch -p1 --verbose < ../patch-4.9.30-rt21.patch
<knowhow> i am in the kernel directory
<cking> knowhow, what is in the kernel directory?
<knowhow> lots of folders and files
<knowhow> and my copied patch
<cking> knowhow, type: grep ^VERSION Makefile
<knowhow> from the main linux directory it says that cannot find the file...should i copy the patch back to the parent directory?
<cking> and then type: grep ^PATCHLEVEL Makefile
<knowhow> done
<knowhow> no errors
<cking> who do you see?
<knowhow> nothing just jumps to next row
<ricotz> type: pwd
<cking> knowhow, ^
<knowhow> pwd gives where i am which is kernel folder
<knowhow> the two that cking gave me just do nothing they jump ok to n ext row...whitout errors
<ricotz> knowhow, then paste the output of pwd to give cking some clue
<cking> knowhow, the grep command should have found the kernel version and patch level numbers from the Makefile in the directory, the fact that it is not doing that means something is not right
<knowhow> yeah something was not right allright
<knowhow> probably the things musnt be done from the kernel directory but from the parent sorce directory
<knowhow> moving the patch  back to the main directory from the kernel directory
<knowhow> when i am in the parent directory i get output from the two commands cking gave me
<knowhow> version is 4 paatchlevel is 9 cking
<cking> good. keep in that directory
<knowhow> from the parent directory and not the kernel one
<cking> the "parent directory" you refer to *IS* the source directory of the kernel, to confuse things, there is a directory inside that called "kernel"
<knowhow> but i have to move with sudo nautilus the uncompressed patch there now....i am not a terminal guy you know :|
<cking> I have no idea why your kernel source needs root permission to write to, where is it? what does pwd show?
<knowhow> is the 666. something megabytes directory after decompression of the thing i downloaded yesterday from your link
<knowhow> probably that 666 number does these things to me :)))
<apw> how did you extract it ...
<knowhow> i put it in home directory
<knowhow> apw..that is the best question
<knowhow> with archive manager but from sudo nautilus not the ...usual nautilus...terminal commands dont work for that by the way
<knowhow> some errors that have nothing to do with reality
<ricotz> (running nautilus with sudo is a bad idea)
<knowhow> after that from root nautilus i changed permissinos for the user me....
<cking> knowing some command line foo is really a baseline to get a kernel patched, configured and built too
<knowhow> ricotz why?...the equation group will get me or something?
<ricotz> just create some folder inside *your* home-dir, uncompress with "tar xf kernel.tar.xz"
<knowhow> tar xf doesnt work...gives an error not being a bz2 format or something
<ricotz> knowhow, is messes with the root account settings and runs services which are not meant to be run like that
<knowhow> but i use it only to copy these things that do not work the usual way...after that i used normal nautilus
<ricotz> knowhow, make sure the package "xz-utils" is installed
<knowhow> it is
<knowhow> the formus blasted with that info
<ricotz> knowhow, but if you copy thing with nautilus running with sudo you get such permission problems
<knowhow> when sudo apt-get install ...it said it is allready there
<ricotz> ok
<knowhow> but from sudo nautilus i right click the folder...give all permissions to me and i done with it no?
<ricotz> cking, I don't want to hijack this
<knowhow> ricotz...by all means...i answered all the questions
<knowhow> if you have something usefull to say go right ahead...except the religious "linux god" dictatorship of course :))
<knowhow> so...sudo nautilus i used to copy things where they should be
<ricotz> please figure this out on a normal user console without sudo/root
<knowhow> apw...if not using sudo nautilus for decompressing the xz archive ...it gives an error at the extraction ...says that "no symbol links" supported on destination
<knowhow> and i have an ext4 on the system drive
<knowhow> if using sudo nautilus the archive manager doesnt complain
<knowhow> after that i revert to normal nautilus...and normal terminal of course
<cking> knowhow, this really isn't the way it should be done, you are making more problems for yourself doing it via sudo'd nautilus
<cking> knowhow, the recipe for getting this done is as follows:
<cjwatson> I suspect the only reason you need to use sudo nautilus is that you had previously done something with sudo nautilus there and so the containing directory is owned by root
<knowhow> cjwatson after the ubuntu install if you want to copy a single measily mp3 or some other file...from the stick....to the hdd....from the first hdd to second from the normal nautilus...you can't:|
<cjwatson> Depends on the target directory, I imagine
<knowhow> it simply says something ...can't copy...can't move...and you start crying near the computer.....
<cjwatson> I think you would do better if you left out the florid commentary
<knowhow> in home directory...music directory...thesame difference
<cjwatson> And it's generally much more helpful to quote exact error messages (in a pastebin if they're large) rather than paraphrasing things vaguely.  Even if the differences don't seem interesting or meaningful to you it might help whoever you're asking to help you.
<cking> if it's any help, I've just downloaded the kernel source + the RT patch, applied the patch and I'm building it right now on a server
<knowhow> cjwatson if i get this through....i am going to make a tutorial on youtube so no one goes EVER through the same ....chocolate....that i am going right now
<knowhow> even if it takes 10 episodes...with the time youtube give to  newcomers
<cking> knowhow, I just wget'd the tarball + patch, uncompress'd and untar'd the kernel source, uncompressed and applied the patch, slapped in a reasonably close .config and kicked off a build, I 'll upload it once it's done
<knowhow> cking can you make it a deb file with all the dependencies needed for a OS fresh install too?
<cking> knowhow, the .deb will contain just the kernel + modules nothing more and nothing less
<cjwatson> But on a fresh install you already have all the dependencies needed to install a kernel installed, since by definition if you can boot the thing then it has a kernel installed
<knowhow> cking i saw a kicad deb on mister reynaud2007 git....download it...no dice
<cjwatson> Anyway, on recent versions of Ubuntu you can do "sudo apt install ./foo.deb" and it will fetch dependencies for you
<cking> nice
<cjwatson> (assuming they're available in your apt sources)
<knowhow> after using lots of terminal commands...apt get magically installed it ...but with the need of internet of course...beacause of some dependencies that ubuntu didn't even bother to tell me about
<knowhow> cjwatson a deb file should normally have all the dependencies it needs...that is why it is a deb
<cjwatson> It's not Ubuntu's fault if some third-party package fails to declare its dependencies properly
<knowhow> probably i will learn to do a deb package inthe future...and learn how to put the dependencies in too
<cjwatson> (If it had declared them, the package manager would have told you about them)
<knowhow> cjwatson i know
<knowhow> oooh...so that means the uploader didnt do the deb right?
<cjwatson> That seems quite likely
<cjwatson> Depending on exactly what went wrong of course, since once again you've given an extremely vague description of the problem
<cjwatson> (Not that a problem with a third-party kicad package would be especially relevant to #ubuntu-kernel of course)
<knowhow> but that means he wants the people not to be able to use the deb???...that is extremely naughty
<cjwatson> More likely the uploader just made a mistake
<cjwatson> Don't overdramatise
<knowhow> cjwatson of course
<knowhow> but it happens...and it is the human behind that is at fault
<knowhow> that is what i try to emphasize
<cjwatson> You said "that ubuntu didn't even bother to tell me about"
<knowhow> yes beacause i didnt have the piece of info you gave about the declaration thing that some human developer should have bother putting in there
<knowhow> i am new in this darn it :)))
<knowhow> i am like an alien abductee...when he is in space :))
<cjwatson> Right.  So slow down, stop blaming things that don't deserve blame and making cracks about religious dictatorships, and listen to people giving advice.
<knowhow> or god knows where
<cking> knowhow, I'm uploading a kernel for you right now with notes on how I built it
<knowhow> cjwatson.....i know..stop feeling it
<knowhow> cking....thanks...i will try to understand the notes
<knowhow> so i can share the knoledge to others
<knowhow> cking what behemoth of computer do you have?
<cking> knowhow, a fast one
<knowhow> beacause everything you do seems ftl tehnology
<knowhow> that laforge would be gelous
<cking> knowhow, we have a lot to do, so we do it fast and efficiently
<knowhow> how many cores?
<knowhow> or cpus?
<knowhow> so cking am i installing the deb file with the software center and it should add it to the grub list?
<knowhow> i supose you give me a deb right?
<knowhow> that includes the rt patch
<knowhow> right?
<cking> knowhow, and a README and a .config for this RT kernel config http://kernel.ubuntu.com/~cking/knowhow/
<cking> wait a moment, I'm still uploading the debug deb
<knowhow> cking can the link from this server be shared....or after i download it you erase the file from server?
<cking> I will erase it once you download it all
<knowhow> cking be carefull i see that you applied patch for 4.9.30 to 4.9.32...will that be good?
<knowhow> i start downloading at 200 kb per second so it will be a while
<knowhow> cking after download ...which one do i install?
<knowhow> i have a core i 7 so amd64 it is...but you have 3 debs there
<cking> knowhow, it applied OK. Note I've not tested this nor do I support this. The notes in the README are sufficient to repeat the build
<cking> knowhow, 5 debs. just yse the firmware image, headers and linux-image deb. you can probably ignore the  dbg image deb and libc dev
<cking> i also supplied the config file I used to build that RT kernel too - you need to copy it into the kernel source directory with the name ".config"
<knowhow> cking i only see 4 debs
<cking> knowhow, note this kernel does no have any of the Ubuntu kernel team "sauce" patches, bug fixes or CVE fixes, it is just a stock kernel with RT patches and no support
<knowhow> cking is it a stable one?
<knowhow> that is why i wanted 4.0.30
<cking> yes it is a gregkh stable kernel
<cking> https://lwn.net/Articles/725370/
<cking> came out a couple of days ago, so all shiney and new
<knowhow> cking...usualy bleeding edge means black screens and all that nasty stuff :))...but if you say it is declared stable ok....the patch is garanteed by the preempt rt team
<cking> shiney and new "fixes" 
<knowhow> i am still donloading by the way
<cking> i need to pop away from the computer and cook some food for my family, I'll be back later
<knowhow> ok i saw the stable word in there :))
<cking> stable is as good as it gets
<knowhow> ok bon appetit cking
<cking> cheerio
<knowhow> but i see 4 debs and you said are 5 
<knowhow> shold i refresh browser?
<cjwatson> yes, refresh, I saw 5
<knowhow> ok
<knowhow> yes i see the other one too now cjwatson but which one do i install first?...all of them are amd64
<cjwatson> I don't recall whether software-center lets you install multiple packages in one go
<cjwatson> I'd download the set that cking recommended you install and just use the command line: sudo apt install ./linux-firmware-image-4.9.32-rt21_4.9.32-rt21-1_amd64.deb ./linux-headers-4.9.32-rt21_4.9.32-rt21-1_amd64.deb ./linux-image-4.9.32-rt21_4.9.32-rt21-1_amd64.deb
<knowhow> but the kernel is one...that is how the official low-latency one is
<knowhow> so which is which?
<knowhow> i see two linux-image things
<cjwatson> linux-image is the kernel itself, but you need linux-headers if you might ever build third-party modules against it, and linux-firmware-image I don't know but if cking said you want it then you should probably take his word for it
<cjwatson> you can run   dpkg -I ./linux-firmware-image-4.9.32-rt21_4.9.32-rt21-1_amd64.deb   (etc.) to see the package description
<cjwatson> cking said that you can probably ignore linux-image-4.9.32-rt21-dbg_4.9.32-rt21-1_amd64.deb
<knowhow> i am downloading them for sure but which one should i use?...which one is a kernel...with the preempt rt patch included?
<knowhow> i downloaded everything...so what now?
<knowhow> ok dbg one ignored for now
<cjwatson> I answered all of this above, so just re-read the last dozen lines or so ...
<knowhow> cjwatson that means i have to install everything except the dbg one but which on do i select fro boot after that? from grub customizer?
<knowhow> or it will only show a one new kernel with the rt letters?
<knowhow> and i can select that one
<cjwatson> I would assume it would not be hard to find if it isn't automatically selected as the default.
<knowhow> what should i expect after installation?
<knowhow> i know beacause it is grub customizer i have installed...just tyo be able to revert to other kernels i have installed easily
<cjwatson> I think you should just make a note of the version if you think you might not remember it.
<knowhow> so do i install them in the order you mention earlier cjwatson?
<knowhow> the packages
<cjwatson> If you pass them all on a single command line as I recommended, the order doesn't matter.
<cjwatson> apt will pick a suitable order that ensures dependencies are satisfied.
<knowhow> cjwatson it seems that they installed in one go it found some warnings about some intel chipset the forum said it would...it showed the other kernels i have installed the generic and low latency
<knowhow> and i will open grub customizer to see what horrors expect me :))
<knowhow> seems that everything is in order
<knowhow> a normal an upstart..and some other thingy exactly as the other group
 * cking back again
<cking> knowhow, so, all OK then
<knowhow> all ok i will restart soon just to see how it went...but i will probably have to do it again because....i havent understand a bob from what just happened :)))
<knowhow> i will restart and see if uname -a will show my new shiny ...with nemphasis on functional :)))...kernel booted :)
<knowhow> for now many thanks cking ...to you and to that super computer of yours
<knowhow> and cjwatson for the all in one install for the deb files
<cking> intel make some big beefy machines for sure
<knowhow> but expensive too
<knowhow> ladies and gentlemen including the people of the hour cking and cjwatson...i am writing this message from...an allmost realtime.... linux ubuntu instance running machine
<cjwatson> good stuff
<knowhow> uname -a gives this
<knowhow> 4.9.32-rt21 #1 SMP PREEMPT RT Fri Jun 16 16:36:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<knowhow> now i have to continue with the linuxcnc compilation against this kernel
<knowhow> i packed these things for safekeeping just in case someone else needs them
<knowhow> thank you again cking cjwatson apw and others...your atmost patience was not in vain 
<knowhow> so thank you again...the open source sound card continues oncemore
<knowhow> cjwatson how do you grab libraries...or to better call them what they are....dependencies..... for future use on a pc not connected to internet?
<knowhow> i used check build deps so i know how to track them for a said source compiling need...but i only know how to get them with apt install command from repos
<knowhow> or..is there another irc channel that treats these things...so i do not other more than i should?
<cjwatson> knowhow: sounds more like something for #ubuntu; but you could try the apt-offline package (disclaimer: I've never tried this myself), or if you ... bah
#ubuntu-kernel 2017-06-17
<alkisg> So, this is my new test that shows the 4.4+ kernel issue where writes start fast, but end up 100 times slower: http://paste.ubuntu.com/24879399/
<alkisg> I.e. copying /lib around, starts with < 10 sec, and now it's at 383 secs and rising
<alkisg> At any point, if I run: "echo 3 > /proc/sys/vm/drop_caches", the problem goes away for a few minutes
<alkisg> This is a 32bit installation with 16GB RAM. I suspect that some commit related to pagecache broke it at the 4.4 kernel
<alkisg> So, my question is: can I play with something in /proc/sys/vm, that would limit all caching to under 4 GB, so that it won't have paging issues with the 32bit system, to see if that solves the slowdown problem?
#ubuntu-kernel 2017-06-18
<ogra> hmm ... do we have a corss compilation guide for arm64 somewhere ... trying to recompile the 4.11 deb results in "aarch64-linux-gnu/bin/ld: cannot find -lpci" 
<ogra> (building the same for armhf works just fine)
<ogra> (ok, not building tools helps with that but seemingly the aarch64 cross compiler has no support for -fstack-protector-strong ...)
#ubuntu-kernel 2018-06-11
<apw> jsalisbury, ^
<jsalisbury> apw, I must have lost connections for a bit, I don't see what you're pointeing to.  Bug number?
<apw> jsalisbury, in pm
<jsalisbury> apw, ack
<pankaj> Hello, I want to understand about .config file (when compiling kernel) and how to edit it and understand it so that I can enable and disable options according to my needs.
<pankaj> THeir is so much compilation of linux device drivers going on that is taking too much time. Sometimes I wonder do I need a lot of them. How to minimize them so that only the essential one to my system install only.
<cjwatson> Usually people use "make menuconfig" to do interactive config editing
<femme> jsalisbury: you recently marked the amd ryzen bug as incomplete, I just want to say I'm still here but didn't get around to testing and responding
<jsalisbury> femme, ack.  I still have it assigned to me, so just update the bug whenever you can perform the testing
#ubuntu-kernel 2018-06-12
<LocutusOfBorg> sforshee, maybe lets talk here
<sforshee> LocutusOfBorg: ok
<sforshee> it's less work for us to use the in-kernel drivers as they should always be compatible with whatever kernel version we're working with
<sforshee> but as I said, if they are currently missing features it's not too much trouble to keep importing the drivers from the dkms package
<LocutusOfBorg> in my opinion it depends on how many features you want to give users
<LocutusOfBorg> having vbox in seeds is a trouble for me in freeze
<LocutusOfBorg> and meh, as long as the basic screen works, people are happy without the guest stuff, specially for live session
<sforshee> right, my position would be to keep importing them into the kernel until the in-kernel drivers provide the necessary functionality
<LocutusOfBorg> as you wish, keeping importing them was not so trivial, due to me forgetting to prod you and vice-versa
<sforshee> LocutusOfBorg: ok, so what exactly would be missing if we switch to the in-kernel drivers? Shared folders, anything else?
<sforshee> if the in-kernel drivers currently do provide sufficient functionality then I'm fine with switching to them
<sforshee> so really I'm just asking you to convince me ;-)
<LocutusOfBorg> vboxguest vboxsf vboxvideo are provided by the guest-dkms package
<LocutusOfBorg> probably shared clipboard and sf are the missing bits
<LocutusOfBorg> we have also the 3d functionality in vbox-guest-x11, so you have 3d accelerated guest
<LocutusOfBorg> but you need an additional package for it
<sforshee> so if it is only sf and clipboard ... for installer I think we could do without those
<sforshee> then why don't we give the in-kernel drivers a try, we'll see how it goes
<LocutusOfBorg> sforshee, I think with bionic we are already using the in-tree kernel driver?
<sforshee> for vboxvideo yes. It does not have the vboxguest driver, that was added in 4.16
<LocutusOfBorg> at least we spoke wrt enabling for 18.04 or 18.10 can't remember now
<LocutusOfBorg> wow I wasn't aware
<sforshee> that's why I was asking, if we use the in-kernel vboxguest driver we lose the sf driver
<LocutusOfBorg> also using the vboxvideo you lose it
<LocutusOfBorg> so, before you were losing 2 drivers, now you lose only one
<LocutusOfBorg> s/o/oo/g :)
<sforshee> we can use the in-kernel vboxvideo driver with the other two from vbox-guest
<sforshee> but vboxsf depends on exports from vboxguest which are not exported by the in-kernel driver
<LocutusOfBorg> oh... this is a big problem then
<LocutusOfBorg> anyhow, lots of time before 18.10 to see complains or revert decision
<LocutusOfBorg> FWIW we have the safe fallback called "install vbox-guest* and live happy"
<LocutusOfBorg> e.g. your vbox video passthroug 3d might not work  at all
<LocutusOfBorg> because you don't have mesa overrided llibraries
<LocutusOfBorg> so how can it work?
<LocutusOfBorg> you also don't set rules to dkms created devices
<LocutusOfBorg> look here https://sources.debian.org/src/virtualbox/5.2.12-dfsg-2/debian/virtualbox-guest-utils.init/#L62
<Simon-> how do I download the source for 4.4.0-127.153 (on xenial)?
<Simon-> https://packages.ubuntu.com/xenial/linux-image-4.4.0-127-generic just gives me links to 128 and 127 isn't available at that location
<Simon-> there's a bug that has severely broken SCTP and I want to identify exactly what has changed
<tyhicks> Simon-: https://launchpad.net/ubuntu/+source/linux/4.4.0-127.153
<tyhicks> Simon-: 'dget https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/linux/4.4.0-127.153/linux_4.4.0-127.153.dsc' would also likely work
<tyhicks> (I've never used dget to pull down a kernel source package but use it regularly for other packages)
<Simon-> thanks
<Simon-> I think someone has failed to consider that AF_INET6 SCTP sockets can have AF_INET address bound to them :|
<Simon-> sctp_inet6_cmp_addr used to be able to compare two AF_INET addresses but now they will just never match
<Simon-> how would I get d625329b06e46bd20baf9ee40847d11982569204 applied to xenial's kernel quickly?
<Simon-> actually I think that may not correctly compare the port :|
<Simon-> the port happens to be in the same place in both sockaddrs, so it will work
<Simon-> it's proposed for stable but it doesn't look like it's in there yet: https://lkml.org/lkml/2018/5/18/439
<Simon-> it is in fact already in 4.16.10, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.10
<Simon-> however, this is 4.4... the fix is in 4.4.133, https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.133
<jeremy31> jsalisbury Thanks for your time spent on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1764645
<ubot5> Ubuntu bug 1764645 in linux (Ubuntu Bionic) "Bluetooth not working" [Medium,In progress]
#ubuntu-kernel 2018-06-13
<caribou> Good morning, according to https://wiki.ubuntu.com/Kernel/LTSEnablementStack, availability of kernel 4.15 in xenial HWE is scheduled for August. Is it still a save assesment or will it be released earlier (aside from the -edge release) ?
<apw> caribou, iirc we will be transitioning linux-hwe a little before the point release, which might well be this SRU cycle
<caribou> apw: we're talking the 3 week release schedule, right ?
<apw> caribou, right, this transition is always a little hair with support packages, so it is possible it might be delayed relative to the rest of the cycle
<caribou> ok, fine thanks!
#ubuntu-kernel 2018-06-14
<alicef> hello, there are cases in ubuntu of packaging pre-builded extra kernel modules for send to the user ?
<apw> alicef, not sure i get the question ... can you expand
<alicef> like virtualbox kernel modules are distributed already compiled to the ubuntu distro through the package manager 
<alicef> or the user machine is compiling the kernel modules ?
<alicef> you are sending somethind like this i suppose
<alicef> usr/lib/modules/extramodules-4.16/vboxdrv.ko.xz usr/lib/modules/extramodules-4.16/vboxnetadp.ko.xz usr/lib/modules/extramodules-4.16/vboxnetflt.ko.xz usr/lib/modules/extramodules-4.16/vboxpci.ko.xz
<apw> those don't look like ubuntu paths ... 
<apw> for virtual box we have a special extra phase in the primary kernel to package those
<alicef> debian instead have moduleassistant that looks like is compiling the choosen modules in the user machine
<apw> because we want them to be signed into the trust chain for secure boot
<alicef> apw: elaborate extra phase 
<apw> we tend to use dkms directly 
<alicef> dkms is compiling the module ?
<apw> literally a packaging phase to build things which are outside of the primary kernel source
<apw> dkms is a differnt approach where the source is delivered to the users machine
<apw> and compiled against the kernel headers
<alicef> oh interesting 
<alicef> so ubuntu is not usually using precompiled modules but using instead dkms for compiling it in the user machine?
<apw> for things which are not distributable as binaries for sure, and generally for things of non-common needs
<alicef> what if the module take more than 30 min to build on a modern server ? in this case you would still use dkms ?
<apw> alicef, it depends on the module if the law requires we not ship the binaries pre-built we have no choice
<apw> though i am not sure i would expect a module to be so very heavy, there are very very few that are more than moniutes
<cascardo> jjohansen: we had to drop socket mediation when we rebased to 4.17, can you help us get that back in shape?
<jjohansen> cascardo: yes, just leave it to me.
<jjohansen> it may take a week, but its something I am working on
<cascardo> jjohansen: thanks!
<jjohansen> basically you had to drop socket mediation, because socket mediation is now upstream, but for the short term at least we need to carry a compatibility patch
<jjohansen> which I am working on
<pixelfog> What is the purpose of the linux-oem kernel?
#ubuntu-kernel 2018-06-15
<sub526> We are planning to develop bunch of out-of-tree linux device drivers to validate our silicon chip.  For this we decided to use Ubuntu LTS platform, which ubuntu version would be good pick?
#ubuntu-kernel 2018-06-16
<klemax> have ati drivers changed with 4.15 kernel?
#ubuntu-kernel 2019-06-10
<apw> mamarley, yeah, ne builder badly configured; should be rebuilt correctly now
<mamarley> Thanks!
#ubuntu-kernel 2019-06-12
<dupondje> This is annoying, laptop freezes like 1 time every day, but was only able to get a stacktrace once :(
<dupondje> https://nextcloud.dupie.be/index.php/s/9yNyocTbCiBz6dB FYI :)
<apw> and that as likely as not is a use after free bug in "something"
<dupondje> apw: so quite useless stacktrace? :D
<apw> dupondje, most likely yes, it is work a quick peek over what is coming in the next kernel (stable wise) to see if there is anything sounding like that
<dupondje> The disco kernel is based on 5.0.8, seems kernel is at 5.0.21 already
<dupondje> lets try that build
<dupondje> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.0.21&id=70a44a01f8a4853100856bdb65a733772a201bd8 might be a possible one? :)
<dupondje> anyway
<dupondje> root     30091  0.0  0.0  18604  4964 pts/7    S+   10:30   0:00 whiptail --backtitle Package configuration --title Configuring Secure Boot --output-fd 12 --nocancel --msgbox Your system has UEFI Secure Boot enabled.  UEFI Secure Boot 
<dupondje> whiptail hangs for some reason
<dupondje> (when installing new kernel that is)
<apw> what the heck is whiptail
<dupondje> invoked by: root     30076  0.0  0.0   2568  1828 pts/7    S+   10:30   0:00  |   |                                   \_ /bin/sh /usr/sbin/update-secureboot-policy --enroll-key
<cjwatson> dupondje: That's https://bugs.launchpad.net/bugs/1827697
<ubot5> Launchpad bug 1827697 in dkms (Ubuntu Disco) "Enroll key whiptail prompt blocks kernel header package upgrades" [High,Fix committed]
<dupondje> cjwatson: aha! thx
<caribou> hello everyone, just a quick question, what is the expected schedule for kernel 5.0.x which is in hwe-edge to hit the hwe package ?
<richi235> Hi, is there any way to know, beforehand or in general when, to what version, and how often the kernel versions for the 18.04 LTE HWE kernel will be upgraded?
<richi235> And very important in particular, is it sure that it will stay the 4.18.* line until 20.04 LTE? 
<jeremy31> richi235: about every 9 months, 4.18 kernel will be EOL bu August and the HWE will be 5.0
<richi235> I build kernel modules for tuxedo, and we get most of our code into the kernel quickly, but for some things we have a custom DKMS module and sometimes trouble with it. That's why I ask
<richi235> (to better plan such things for the future)
<richi235> jeremy31: uhh thank you
<jeremy31> richi235: the 4.15 is LTS and will be supported until 2023
<richi235> good to know
<richi235> is there a central/official page where these dates are listed? 
<jeremy31> richi235: About all you can do if you want to stay on top of things is to build dkms on kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/ and you could also look at https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2FSupport.Ubuntu_Kernel_Release_Schedule
<richi235> Ahh, 4.18.* is still missing in the graphs (it's TBD) but i get the general pattern, thank you
<richi235> also found https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack
<richi235> Another but related question: If I get a PCI_SND_QUIRK(...) fix into the kernel (just one line, minor fix about device id stuff), and it will be cherry picked to stable, all in this month, Will such changes be in the August 5.0 hwe kernel? 
#ubuntu-kernel 2019-06-13
<apw> richi235, which is why there is a linux-hwe-edge kernel which leads linux-hwe; to allow early testing
<richi235> ahh, thank you
