#ubuntu-kernel 2005-05-24
<thom> fabbione: when you get a chance, care to review thom@ubuntu.com--fandange/kernel-debian--pre1,2-fix-update-message--0
<fabbione> re
<fabbione> thom: sure.. but just commit on the main branch
<fabbione> if there is something wrong we can always revert the commit
<thom> fair enough
<fabbione> thom: don't be afraid.. that's why it's called PREx,Y :)
<fabbione> + today is national holidays.. i will be around only to check the g++ transition on sparc
<fabbione> i will be off after that
<thom> ah, fair enough (to both)
<thom> also, skge is *much* *much* better than sk98lin here
<fabbione> rocking
<fabbione> humpf
<fabbione> something is wrong with X today
<fabbione> never mind.. thunderbird sucks :)
<thom> yes
<chmj> lol
<fabbione> much better...
<fabbione> wow the sparcbuildd has been busy....
<chmj> firefox sucks also 
<fabbione> 890 mails in 48 hours :)
<fabbione> as much as fedora does
<fabbione> food time..
<fabbione> i will be back in a few
<jbailey> fabbione: You back yet? =)
<thom> few hours, i think that was ;-)
<jbailey> *lol*
<chmj> hehe 
<fabbione> jbailey: yeah now
<jbailey> fabbione: I'm just moving the imap stuff for sparcbuildd to my main machine, but I didn't see any failures there last week that were lkh related.
<jbailey> fabbione: Did you have them in a separate folder?
<fabbione> jbailey: they are all in the needsreallove folder
<fabbione> util-linux is one of them
<fabbione> iptraf
<fabbione> probably reiser4progs
<fabbione> hfsplus
<fabbione> ifplugd
<fabbione> parted seems another good candidate
<fabbione> hmm
<fabbione> skip resiser4progs
<fabbione> a new version has been built recently 
<fabbione> (catching up on 900 buildd emails)
<fabbione> hmm there are also new l-k-h.. could they make a difference?
<chmj> reiser4progs has been given love 
<jbailey> fabbione: I have not intentionally fixed lkh on sparc.
<fabbione> jbailey: let's do one thing.. let me reset the counters...
<fabbione> and see how it goes with the new headers
<jbailey> Lemme take a look first.
<fabbione> ok
<jbailey> If there's a bug, it's probably a single one affecting everything.
<jbailey> But I don't know why it's taking so long for my evo at home to connect to the imap server.
<jbailey> You're not checking ident, are you?
<fabbione> nope.. the server is up and running fine
<jbailey> Yeah, it was taking forever to connect before, and it just sycnd up when I closed evo.
<jbailey> I've reopened and it's taking forever again.
<fabbione> are you trying to download all the messages ?
<fabbione> or are you reading only the headers and download the message on request?
<fabbione> because i only have 512k outbound
<fabbione> and the mailbox is HUGE
<jbailey> Oh really?
<jbailey> That might be it then.
<jbailey> The folder was pretty empty last time I looked at it.
<fabbione> yeah... just the inbox is around 680 messages right now
<fabbione> of buildlogs
<fabbione> otherwise gimme a few minutes to clean it up
<jbailey> Sounds like that might be best.  Sorry!
<fabbione> no problems :)
<jbailey> That would explain evo's behaviour though.  =)
<jbailey> I think it downloads all the messages so that it can run filters on them (even though I have filtering turned off on that connection)
<jbailey> fabbione: Would you mind forwarding the util-linux failure to jbailey@ubuntu.com for now?
<fabbione> sure.. in a sec
<fabbione> scrap ipsectools
<fabbione> they did build in a new version
<chmj> fabbione: where is the needsreallove folder
<fabbione> chmj: on the sparc buildd machine
<jbailey> util-linux is a good choice since it builds on other archs.
<chmj> fabbione: thats not in the machine overview list 
<fabbione> jbailey: on the way
<fabbione> chmj: it's the sparc buildd sitting one meter on my left side
<chmj> oh, :-|
<chmj> anything I can give love to then ?
<fabbione> chmj: sparc is an unofficial port
<chmj> don't have sparc though :-| 
<fabbione> so it's done on spare time :)
<fabbione> but it managed to catch some weird bugs that don't show up on other arches due to its nature
<chmj> well, that an upside 
<fabbione> except that my wish to see ubuntu release with sparc is slowly vanishing
<fabbione> because an error seen on sparc only takes more time to get fixed
<fabbione> and sparc slows down
<fabbione> sparc didn't make hoary because of one package with wrong build-dep...
<chmj> ouch
<fabbione> when i first saw the error and told the maintainer it did never get fixed...
<fabbione> but the fact that the buildd at the datacenter are much faster, they didn't really notice the problem
<fabbione> also because the chroots are updated automatically...
<chmj> develop a simple tool to monitor third-party driver releases (similar to debian/watch).
<chmj>     *      (low priority: needs to be done before UVF)
<fabbione> so the bug passed unseen
<jbailey> fabbione: Looks like a util-linux bug where they're declaring a prototype that they shouldn't be.  If anything, it's a glibc bug not lkh.
<fabbione> jbailey: so why it doesn't show up on other arches?
<fabbione> chmj: go ahead.. it's fine with me
<jbailey> fabbione: Dunno yet.
<fabbione> chmj: take the task and work on it. use debian/external-modules as a reference to start from
<chmj> ok 
<jbailey> Ugh.  util-linux should not have compiled elsewhere, I think.
* jbailey tries a build.
<jbailey> *sigh*
<jbailey> #if defined(MNT_FORCE) && !defined(__sparc__) && !defined(__arm__)
<jbailey>  /* Interesting ... it seems libc knows about MNT_FORCE and presumably
<jbailey>      about umount2 as well -- need not do anything */
<jbailey> #else 
<jbailey> fabbione: I'm guessing that the new glibc finally knows about this for all arch's now, instead of just a few before.
<fabbione> ok :)
<fabbione> so it's a glibc bug that knows too much!
<fabbione> wankers
<fabbione> :P
<chmj> heh
<jbailey> fabbione: I can tweak this a bit later.  Mind sending me another suspected lkh problem?
<jbailey> fabbione: Although if this is the type of problem it is, the bugs might generally be that glibc sucks less than it used to.
<fabbione> jbailey: let's do it tomorrow or in a couple of days
<fabbione> i want to try to upgrade the chroots
<fabbione> cleaning the logs
<fabbione> and giving-back all of main
<fabbione> or at least what is FTBFS in main atm
<jbailey> 'kay.
<fabbione> otherwise just wait a few minutes :)
<fabbione> i am down to the last 64 mails to parse ;)
<fabbione> jbailey: try to connect now to the imap server :)
<jbailey> Either way.  I'm going to work on something else for a few moments, but I want it officially to be Not Me(tm) who's holding you up ;)
<fabbione> jbailey: you and doko will always hold me up :)
<fabbione> any of your uploads will kill my sparc :)
<jbailey> There is that...
* fabbione lovely hugs jbailey 
<doko> fabbione, fix your sparc
<jbailey> fabbione: We should take up a collection of people who care about sparc to buy you a second one. =)
<fabbione> doko: no.. stop messing up your uploads....
<jbailey> doko: By fix, you mean overclock, clone and running with a liquid cooling system? =)
<fabbione> jbailey: eheheh you have one.. time to change it in a buildd :)
<jbailey> fabbione: I don't have the bandiwdth for it.
<fabbione> doko: also.. bootstrap a breezy chroot on your sparc, using ports.ubuntu.com
<jbailey> fabbione: p'haps in my new place.  The ISP I'm looking at will have 900k up.
<fabbione> doko: and pre-test your uploads like i do with amd64/ppc :)
<fabbione> jbailey: cool.. i only have 512k :)
<jbailey> fabbione: Right, but I use VoIP for all my phone calls.
<jbailey> fabbione: So I can't have an automated system chewing that up. =)
<fabbione> eheheh
<fabbione> doko, jbailey: is there anyway to make the gcc build system slightly more ccache happy?
<jbailey> fabbione: How is it not right now?
<fabbione> ccache off = 17hours
<fabbione> ccache on = 17hours
<jbailey> Ahahah,.
<jbailey> ouch
<jbailey> =)
<fabbione> that's gcc-4.0
<jbailey> And not just when doko's updating snapshots?
<jbailey> -7ubuntu2 was a cvs snap.
<fabbione> bah no idea...
<fabbione> it's always around 17 hours 20 minutes
<fabbione> NOW
<doko> fabbione: don't build -7ubuntu2 yet, should be replaced by -3 soon
<fabbione> thanks to the last gcc-4.0 upload and the upcoming g++ transition
<doko> how's 3.4 working?
<fabbione> ah
<fabbione> so i should kill the build?
<doko> yes, please, but not me
<fabbione> doko: i told you last time.
<jbailey> fabbione: Erm.  glibc does better with ccache right?
<jbailey> fabbione: If not, you may want to hold all glibc builds for a week or so, too.  It should go through 3 or 4 iterations in that time.
<jbailey> lamont requested more frequent uploads with smaller changes for enabling ppc64, amd64, etc.
<fabbione> jbailey: glibc afaik does benefits of ccache
<fabbione> we also need to move sparc64 to NTPL, don't we?
<fabbione> doko: i killed the build right now
<jbailey> fabbione: YEs, and regular sparc ideally, but still need to figure out whether we continue to care about pre sparc9
<doko> jbailey: wrong channel ;)
<jbailey> doko: *g* =)
<fabbione> ok let's move to -toolchain
<doko> fabbione: does the kernel support Video4Linux 2
<fabbione> yes
<fabbione> but it also depends from the driver to support v4l2
<zul> hey
<fabbione> hey zul
<zul> hey fabbione how goes it?
<fabbione> stolen-from-head_libata-updates.dpatch
<zul> what about it?
<fabbione> zul: is this one of your patches?
<fabbione> (2.6.10)
<zul> yep
<fabbione> from what tree did you grab it?
<zul> you wanted me to update libata a long time ago
<zul> linus bk tree
<fabbione> that patch is not in linus bk tree :/
<zul> i think..
<fabbione> and jgarzik just told me that the patch introduces code that is highly broken
<zul> actually it was an email to lkml 
<fabbione> with data corruption
<zul> frig..
<fabbione> that means that we will need to prepare an update for hoary
<zul> *sigh*
<zul> can my day can get any better?
<fabbione> that also means that somebody will feel a huge pain in the ass
<zul> *sarcasm*
<fabbione> that means becoming a goatse from a virgin in 0 ms
<zul> lovely
<zul> fuck..that made me in a lovlier mood now...thanks...i appreciate it
<fabbione> do you remember if anybody requested specifically these 2 drivers?
<zul> yeah i think so
<fabbione> they are not shipped in the installer
<fabbione> so nobody can use them to install
<zul> gimme a sec..
<fabbione> i will need to go very soon
<zul> ok...i just need to check bugzilla 
<zul> it was some promise sata controller
<fabbione> yeah
<fabbione> that too
<zul> i kind of remember you asking me to get an update for sata when i was first starting out
<fabbione> yes, but from the linus main tree... not from a mail floating around on lkml :/
<zul> meh..
<fabbione> well at least it has been me larted publically
<zul> other than me for once
<fabbione> now.. i need to go and sue my ass in one piece again...
<zul> sew?
<fabbione> can you try to check the bugzilla and what happen if we revert that patch?
<fabbione> yeah that ... sew
<zul> ok..
<fabbione> please send me a mail
<zul> sure..
<fabbione> i am off now and i won't be back anytime soon
<fabbione> thanks
<zul> and i can wallow in my own missery c ya
<zul> hah! found it
<fabbione> thom: you must fix your umask on roockery
<fabbione> you locked again the kernel archive :/
<chmj> morning 
<fabbione> hi
<thom> fabbione: dude, i so have
<fabbione> thom: apparently not :(
<fabbione> the ++revision lock is still 755
<thom> thom@rookery:~$ umask
<thom> 0002
<thom> *sigh*
<fabbione> thom: where do you set the umask?
<thom> .bash_profile
<thom> (i'm not a bash user normally)
<fabbione> .basrc
<fabbione> .bashrc
<thom> ber
<fabbione> _profile is not loaded by scp/sftp
* thom grumbles and mutters
<thom> fixed
<fabbione> danke
<thom> and the rev lock should be fixed too
<fabbione> yup.. i am committing right now
<JaneW> doko: ping
<fabbione> WARNING: new symbols have been added.  This is not critical, but probably is not a good idea when attempting to maintain ABI stability.  Differences:
<fabbione> fuck security updates
<fabbione> zul: when you add new drivers, can you be so kind to also update the configs?
<fabbione> thom: ping?
<thom> fabbione: ack
<fabbione> thom: are you familiar with ip6tables ?
<thom> never used it
<fabbione> so i guess it would be a good time to learn? :)
<fabbione> i am considering to add the usagi patch to our kernel
<fabbione> but that needs a brand new iptables package
<fabbione> due to kernel headers changes
<fabbione> but the package is messy and i would like somebody experienced to do it :)
<chmj> issin't there a new version on ip4tables? 
<thom> i probably wouldn't be able to get to it till next week
<fabbione> thom: ok...
<fabbione> chmj: probably.. and?
<thom> network magic this week
<thom> oh, and udevraces
<fabbione> amen
* fabbione understands and feels thom's pain
<fabbione> thom:
<fabbione> Executing shell in 'breezy-i386' chroot.
<fabbione> No directory, logging in with HOME=/
<fabbione> on concordia
<fabbione> can you fix that please?
<thom> and i need to spec buntu with jbailey tomorrow
<thom> i can, but you really shouldn't ask me
* chmj -> food 
<fabbione> thom: yeah don't worry.. i was just checking if you had time.
<fabbione> thom: i know.. but elmo is not around 
<thom> fabbione: done
<fabbione> thom: thanks
<zul> ack
<fabbione> new inotify builds fine...
<fabbione> zul: is there anything pending from your queue?
<zul> nope you should have the latest i havent added anything this weekend
<fabbione> time to cook some food
<fabbione> and think how to add ndis for amd64
<jbailey> thom: Do you need more time?  We could push buntu back by a week if it needs it.
<zul> i wouldnt mind helping with  buntu
<chmj> me neigther 
<thom> jbailey: i think i'd appreciate it, yes
<zul> fabbione, are you doing an upload today?
<fabbione> zul: no
<zul> k
<fabbione> g++ transition day
<zul> ah
<zul> later
* lamont updates the hppa patch
<pitti> Hey dudes
<pitti> I added a patch to the kernel, increased changelog version, added to 00list.myversion and so on
<pitti> and debuild -us -uc -nc even creates a debian/abi/2.6.11.92-1.1/ with stuff
<pitti> but on cleaning this seems to go away
<pitti> Missing /home/pitti/kernel/linux-source-2.6.12-2.6.11.92/debian/abi/2.6.11.92-1.1/abiname file.
<pitti> make: *** [clean]  Error 1
<pitti> what do I have to do to make this permanent?
<Lathiat> pitti: ht patch?
<pitti> no, trulux's linking restrictions patch
<fabbione> pitti: you need to mv debian/abi/2.6.11$whateveristhere to debian/abi/$previous_ver_compared_to_the_one_you_are_building
<pitti> ah, ok
<pitti> that explains why there is only a 2.6.10foo in the 2.6.11-1.1 kernel
<pitti> is there any way to generate debian/abi/<previous_version> for all arches?
<lamont> pitti: yeah - you parse the build logs.
<lamont> which, btw, sucks
<lamont> what we really need is some method of telling the buildd to pull out some files from the build, that are then special cased in katie to not actually go into the archive (the mirrored part that is), but are available from the top-level mirrors _somewhere_
<lamont> hrm.. we could put pofiles there too.. :)
<pitti> and debug packs :-)
<fabbione> pitti: thanks for the CAN
<fabbione> i will add it right away
<pitti> great
<fabbione> pitti: CAN added to hoary
<fabbione> heard anything from Xu about the HT?
<pitti> cool
<pitti> fabbione: no, he didn't answer yet
<fabbione> ok
<pitti> fabbione: I sent him thom's debdiff, your mail with patches and a list of todo items on thom's changes
<jbailey> Feh, mmap error doing a debootstrap.
<fabbione> http://geekz.co.uk/lovesraymond/
<fabbione> ahaha
<jbailey> Ahahaha.  sweet
<jbailey>  Food time, bbiab
<thom> there were todo items? ;-)
<zul> heylo
#ubuntu-kernel 2005-05-25
* #ubuntu-kernel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
<fabbione> morning
<infinity> afternoon
<dilinger> 'night
<fabbione> night dilinger 
<zul> morning
<mjg59> Hmm. I've checked out the baz tree. How do I then get a kernel source tree?
<zul> archive
<zul> http://archive.ubuntu.com/ubuntu/pool/universe/l/linux-source-2.6.12/
<mjg59> Ok. And just dump the patches and 00list from the baz tree into the archive?
<zul> dpkg-source -x *.dsc
<zul> then blow away the debian directory and do a baz get
<zul> fabbione: ping
<zul> hmmm...this is not good
<zul> make-kpkg --stem linux  clean
<zul> make[1] : Entering directory `/home/chuck/work/ubuntu/2.6.11.92/linux-source-2.6.12-2.6.11.92'
<zul> /usr/share/kernel-package/rules:1624: *** Error. I do not know where the kernel image goes to [kimagedest undefined]  The usual case for this is that I could not determine which arch or subarch tihs machine belongs to. Please specify a subarch, and try again..  Stop.
<zul> make[1] : Leaving directory `/home/chuck/work/ubuntu/2.6.11.92/linux-source-2.6.12-2.6.11.92'
<zul> make: *** [clean]  Error 2
<zul> dilinger: ^^^ this is what im getting
<dilinger> zul: haven't seen it
<zul> damn
<fabbione> zul: pong?
<zul> fabbione: oh yeah for patches that touch alot of files what is the naming convention again?
<fabbione> zul: what patch is that?
<fabbione> what it does?
<zul> its just a patch that fixes unused variables warnings hen compiling
<fabbione> zul: bah you stink...
<zul> well i havent had a shower today so you are probably right there
<fabbione> call it something like: global_remove-unused-vars.dpatch
<fabbione> or something along that line
<zul> okie dokie..
<fabbione> but if you are so bored to do that kind of job, you can come here and clean my house
<zul> fabbione: who do you think you are my wife? :)
<zul> i had to pull weeds from my back yard
<zul> that was fun..
<fabbione> zul: no.. your god :)
<zul> sure..
<fabbione> weeds? did you smoke them before committing something? ;)
<zul> hehe..
#ubuntu-kernel 2005-05-26
<zul> meh
<fabbione> morning
<zul> hmmm...kernel-package is broken
<chmj> O.o
<svenl> fabbione: what is the status of the current breezy kernel with regard to hoary ? 
<svenl> would using it on a hoary system break horribly ?
<fabbione> svenl: not that i know of.. try 
<svenl> fabbione: i am thinking of building a pegasos version of hoary, which would need the newer kernel so that the gigabit ethernet interface works.
<fabbione> svenl: just keep in mind that it is 2.6.12rc4.
<svenl> fabbione: so ?
<svenl> fabbione: just because it is not a released kernel ? 
<svenl> ARRGGGHHH
<svenl> gedit just died on me, and i dind sae my changes, sucks big time.
<svenl> zul: did you fix kernel-package ? Or did you just downgrade ? 
<fabbione> svenl: well dude.. i was only warning you. do whatever you want :)
<svenl> fabbione: :)
<svenl> fabbione: i have worse problems, the current ld in breezy doesn't like to build the pegasos firmware.
<svenl> i am trying to build a sarge chroot, but seems debootstrap uses something else than apt and thus cannot bypass this stupid firewall i am saddled with here.
<fabbione> uh? yes it does use apt
<Lathiat> use tsocks and ssh -D <port>
<fabbione> just set HTTP_PROXY
<svenl> fabbione: for the Release file also, and not wget or somethign ? 
<fabbione> HTTP_PROXY is respected by wget too 
<svenl> i have Acquire::Http::proxy set in /etc/apt/apt.conf
<fabbione> that only acts on local machine
<svenl> huh ? I could upgrade and stuff with it, and broke my build env.
<svenl>  HTTP_PROXY=223.223.223.226:8080 sudo debootstrap sarge sarge http://ftp2.de.debian.org/debian
<svenl> I: Retrieving debootstrap.invalid_dists_sarge_Release
<svenl> E: Failed getting release file http://ftp2.de.debian.org/debian/dists/sarge/Release
<svenl> i guess this is not how i am supposed to use it, right ? 
<fabbione> nah
<fabbione> export HTTP_PROXY
<fabbione> than sudo
<svenl> fabbione: oh, and do you know how comes firefox tells me some horrible thing when trying to edit prefs, about pref.xul being bad ?
<fabbione> no
<fabbione> i don't use firefox
<Lathiat> btw, wget uses http_proxy
<fabbione> oh sorry
<fabbione> it was all small
<Lathiat> in fact, so does apt
<fabbione> even for apt
<Lathiat> http_proxy="http://223.223.223.226:8080/" sudo deboostrap sarge sarge http://ftp2.de.debian.org/debian
<Lathiat> shoudl work
<Lathiat> wfm(tm)
<svenl> he, thanks, that worked.
<svenl> fabbione: do the powerpc kernels include the atkbd stuff ? 
<zul> svenl: i got the new version from snapshot.debian.net
<svenl> zul: i installed a sarge chroot :)
<zul> that works..
<svenl> and it built the package :)
<svenl> now i need to test it on that prototype board :)
<zul> this is a new one
<zul> make[1] : Entering directory `/home/chuck/work/ubuntu/2.6.11.92/linux-source-2.6.12-2.6.11.92/debian/build/build-686'
<zul> The changelog says we are creating 2.6.12, but I thought the version is 2.6.12-1-686
<zul> make[1] : *** [stamp-debian]  Error 1
<zul> make[1] : Leaving directory `/home/chuck/work/ubuntu/2.6.11.92/linux-source-2.6.12-2.6.11.92/debian/build/build-686'
<zul> make: *** [build]  Error 2
<zul> debuild: fatal error at line 765:
<zul> dpkg-buildpackage failed!
<mjg59> zul: I've seen that, but didn't manage to figure out why it happened
<zul> how did you get around it?
#ubuntu-kernel 2005-05-27
<lamont> pitti?
<lamont> zul: the version is 2.6.11.92-1.2
<lamont> zul: what command exactly did you run?
<zul> debuild
<zul> im using breezy though so maybe somehting screwed up
<lamont> ah, /me uses debuild -i -S, and then uses sbuild to actually build it
<zul> sbuild?
<lamont> for uploads, we want the -i, so that the arch crap goes *poof*
<lamont> sbuild is what the buildd uses.  pbuilder is another common tool for building in a chroot
<zul> ah ok
<zul> ill try that then
<svenl> fabbione: linux-image-2.6.11-1-powerpc 2.6.11-0.2 is 2.6.11-rc something ? 
<svenl> err.
<svenl> 2.6.12-rc something ?
<fabbione> no
<fabbione> that is 11rc something
<fabbione> a bk snapshot
<fabbione> you want linux-source-2.6.12
<fabbione> that is 12rc4
<svenl> fabbione: yep.
<svenl> fabbione: apt-cache search linux-image didn find it though.
<fabbione> svenl: it's in breezy
<svenl> Oh, you mean that it was not yet build on powerpc or something such ? 
<fabbione> universe
<fabbione> it is built
<fabbione> it's there
<svenl> oh, i didn have universe/multiverse in breezy sources, that explains it.
<svenl> BTW, how can i get ride of these messages : 
<svenl> W: GPG error: http://fr.archive.ubuntu.com breezy Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<svenl> BTW, did you bring in mkvmlinuz 13 into breezey ow ?
<fabbione> cat chroot-breezy/etc/apt/apt.conf
<fabbione> APT::Get::AllowUnauthenticated "1";
<svenl> and to authentificate it correctly ? 
<fabbione> svenl: dunno.. you can just use dpkg -p mkvmlinuz and see yourself
<fabbione> no that's to disable the message
<fabbione> it turns off authetication
<fabbione> usually when you get that message is beacuse the mirror is not in sync properly or it is syncing
<svenl> and no, i am not in some funny breezy changeroot, i run breezy directly :)
<svenl> fabbione: ah.
<svenl> fabbione: i have mkvmli13 installed locally.
<svenl> but yes, it si synced, there is a 13ubuntu1 :)
* fabbione signs up for a danish course
<fabbione> time to learn the language
<fabbione> i think....
<svenl> hehe
<svenl> fabbione: we have a bug in the 2.6.12-rc wakeup from sleep on powerbook code.
<svenl> fabbione: i will investigate with benh, but can you note it down somewhere until i recover my X.
<svenl> yep, definitively a problem with the current X.
* fabbione goes to commit suicide
<chmj> fabbione: whats up ? or rather do I wanna know ?
<fabbione> chmj: not yet
<fabbione> never mind
<chmj> that can't be good 
<zul> heylo
<zul> fuck
<lamont> chmj: he's married.  that explains much. :-)
<chmj> I was afraid he was gonna say that :p 
<zul> hmmm?
<zul> fabbione: do you still have the rc4 tarballs somewhere can you throw them up again on your ~fabbione thx
<fabbione> zul: they are in the archive :)
<zul> yeah but something is fucking up
<zul> make[1] : Entering directory `/home/chuck/work/ubuntu/2.6.11.92/linux-source-2.6.12-2.6.11.92/debian/build/build-686'
<zul> The changelog says we are creating 2.6.12, but I thought the version is 2.6.12-1-686
<fabbione> that's the package name
<zul> so the changelog is messed up?
<zul> or kernel-package
<fabbione> i don't understand what changelog you are talking about
<zul> grr..i think it might be me
<fabbione> the version is 2.6.11.92-$whatever
<lamont> zul: 2.6.12-1-686 is part of the package name, not the version
<lamont> linux-source-2.6.12 (2.6.11.92-1.2) UNRELEASED; urgency=low
<lamont> that's what's in my changelog copy, and it's what it should be,
<zul> i know im not sure why im gettting that error though
#ubuntu-kernel 2005-05-28
<lamont> fabbione: we have a guestimate on when we want to upload -1.2?
<fabbione> morning
<fabbione> lamont-away: as soon as i can get unfucked chroots on concordia and davis
* Mithrandir wants the new ipw2200 driver in the next kernel.
<fabbione> Mithrandir: yeah we got a post for that
<fabbione> i will see if i can get it in for the next kernel
<Mithrandir> fabbione: yeah, it was what prodded me.
<Mithrandir> fabbione: yay, rock.
#ubuntu-kernel 2005-05-29
<mjg59> fabbione: I just got an oops in inotify
<mjg59> I tried unmounting an ntfs partition
<mjg59> (this is 2.6.12 as of Wednesday)
<jbailey> There's no __NR_sigaction on x86_64.  Does the 32-bit emulation on amd64 promise to do all to 32bit syscalls?
<Mithrandir> jbailey: I would think so, yes.
<Mithrandir> it's supposed to be a 100% emulation
<jbailey> Oh good. =)
<jbailey> So now all we need is glibc headers that DTRT.
<jbailey> Mithrandir: Is there any hope of us doing multiarch at least a little bit for Breezy? =)
<Mithrandir> jbailey: you mean "a little bit more"? :)  I'm hoping to get some time allocated for actually coding up a bit once I'm done with my thesis
<Mithrandir> doing binutils + gcc support should either already be there or easily fixed.
<jbailey> Mithrandir: I'd love to see at a base just have gcc look in the multiarch directories for -m64 and -m32 as well as the standard directories.
<jbailey> We can then take the current biarch packages and have it put things in the right places.
<jbailey> Including all the header files and such.
<Mithrandir> jbailey: get doko to apply a set of fixes from http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/gcc-debian--multiarch--3.4 and you're set.
<jbailey> Nothing from dpkg would need to be touched, basically just gcc, glibc, lkh, ncurses and zlib.
<jbailey> And it's all stuff we could do in our sleep today.
<Mithrandir> that's easy enough to do, sure.
<jbailey> I suspect that doko's current libjava on 32 bit arch problem will give him incentive to say yes. =)
<Mithrandir> heh :)
<Mithrandir> this won't give you coinstallability until dpkg is fixed, though
<jbailey> He's running into the fact that i386 and amd64 aren't like ppc, sparc and s390 in glibc.
<Mithrandir> oh, fun
<jbailey> Noone in glibc land ever intended it to be a biarch arch AFAICT.
<jbailey> So the headers don't seem to easily cope with each system.
<Mithrandir> which is the reason for the crack in amd64-libs-dev to divert headers and such?
<jbailey> Partly, but mostly amd64-libs crack is due to the fact that Sarge wasn't shipping with amd64.
<Mithrandir> that too
<jbailey> So no compiler support, so no way to make proper biarch packages.
<Mithrandir> true
<Mithrandir> it's also aiming for a bit more than ia32-libs-dev which is "this is enough to give you a crosscompiler"
<jbailey> Right. =)
<jbailey> So assuming doko agrees, that patch is all that needs to be applied to 3.4 to make it look in /usr/include/${GNU_ARCH} and /usr/lib/${GNU_ARCH} before the regular search paths?
<Mithrandir> you need to fix up binutils too, but yes.
<jbailey> Right - for ls/.
<jbailey> ld.
<Mithrandir> in the cases of people calling ld directly, for instance.
<Mithrandir> gcc DTRT and passes the right parameters, but it's not always enough
<fabbione> morning
<fabbione> mjg59: i have an inotify update pending for the next upload.
<fabbione> mjg59: but i can't upload yet.
<zul> hey
<zul> blah
<jbailey> Can the ia64 kernels run i386 binaries if the appropriate libraries are hanging around?
<doko> jbailey, they should
<jbailey> doko: I'm just wondering how many multiarch setups we'll need.  I imagine the trouble you're running over with OOo is going to have to be repeated for ia64 at some point.
<doko> hmm, who does run OOo on ia64? ;-)
<Mithrandir> doko: insane people.  That means, everybody who uses ia64.
<jbailey> Mithrandir: That's not fair.  I don't use OOo anywhere, much less on my ia64. =)
<Mithrandir> jbailey: well, you're a glibc hacker so you're insane, hands down. :-)
<jbailey> ;P
<Mithrandir> actually, I didn't say that everybody with an ia64 used ooo, just that they were insane.
<doko> Mithrandir: amu reports 100% CPU usage when installing the new bash package on amd64, can you confirm that?
<Mithrandir> doko: just installing it?
<doko> no, using it
<Mithrandir> give me a few secs
<Mithrandir> just by launching it and running some commands?
<Mithrandir> if so, can't duplicate.
<doko> hmm, strange, maybe you could ask amu tomorrow
<Mithrandir> I'll try to remember.
<doko> thanks
#ubuntu-kernel 2006-05-22
<CarlFK> why does /lib/firmware/2.6.15-22-386 have an acx dir but /lib/firmware/2.6.15-22-686 doesn't ?
<CarlFK> 2 day old dapper box
<BenC> because you don't have linux-restricted-modules-2.6.15-686 installed
<BenC> you can recitfy that by installing linux-686
<CarlFK> hmm... i wonder how the 386 ones got installed...
<CarlFK> thanks
<zul> hey
<CarlFK> oats
<BenC> airlied: ping
<zul> hey BenC 
<BenC> hey zul
<zul> what are you doing up?
<BenC> playing poker online
<zul> hehe
<zul> im just waiting for the daily show to come on
<airlied> BenC: pong, I have a patch ready if you want it.. vs ubuntu-2.6 master..
<BenC> yes, defnitely
<BenC> bcollins@ubuntu.com, please
<airlied> BenC: done.
<airlied> I have to say git cherry-pick rocks..
<airlied> made that task quite simple..
<desrt> BenC; word.
<desrt> BenC; how goes the ppc64 hugepage testing?
<BenC> airlied: hell yes it does...
<BenC> desrt: hey, gotta wait till tomorrow to test it (my G5 belongs to the wife)
<desrt> that's cool
<desrt> i have a cluster of machines i could let you test it on :p
<BenC> airlied: ping
<[g2] > mjg59_ If running only dapper on the intel mac mini can I just install elilo and have it boot to dapper ?
<mjg59_> As long as you're not using the bios emulation, yes
<[g2] > mjg59_ I've got bootcamp installed does that cause the bios emulation ?
<mjg59_> It depends how you're booting it
<[g2] > basically I've installed from the Livecd and used the whole disk
<mjg59_> Then no, you can't trivially install elilo
<mjg59_> If you have a /sys/firmware/efi directory, you can
<[g2] > right now it's booting to grub and dying
<[g2] > mjg59_ what's the best way to get elilo on there ?
* desrt pays attention because he's gonna be doing this in a couple of weeks
<infinity> BenC: Still around?
<BenC> yeah
<infinity> An interesting point was just raised on the -users list (yeah, I know, whoah)
<infinity> Since we now build all our i386/amd64 kernels SMP (except for -386), rtc really shouldn't be modular, since not having it loaded blows up ntp/hwclock/etc.
<infinity> In general, udev seems to load it automagically on most systems anyway, but the user on -users didn't have it loaded until he explicitely loaded it, and ntp was failing for him as a result.
<infinity> kernel.org upstream has (for eons) recommended that CONFIG_SMP=y always be accompanied by CONFIG_RTC=y
<BenC> Ok, I can do that
<infinity> May as well keep it a module on the -386 kernel for the pathological case where it might break one RTC in a million on some ancient system.
<infinity> But all the SMP kernels should definitely have it on.
<BenC> so that's all of amd64, and all of i386 except -386
<infinity> Should be, yes.
<infinity> Meh... 5am... Maybe I should just cook myself some food and stay up.
#ubuntu-kernel 2006-05-23
<airlied> BenC: pong
<bluefoxicy> when you all get back from #-meeting in an hour, does anyone want to help me figure out wtf as I try to patch something into my kernel?
<bluefoxicy> arch/i386/kernel/process.c:667: error: per_cpu__cpu_gdt_table undeclared (first use in this function)
<bluefoxicy>                 load_user_cs_desc(cpu, next_p->mm); // the line in question, this is a macro
<bluefoxicy> #define load_user_cs_desc(cpu, mm) per_cpu(cpu_gdt_table, (cpu))[GDT_ENTRY_DEFAULT_USER_CS]  = (mm)->context.user_cs  // The macro's definition
<BenC> wow, I had no idea how much space the debian/abi directory was taking up
<BenC> # du -sh debian/abi
<BenC> 119M    debian/abi
<zul> oi
<BenC> and there it's done
<zul> yay...
<zul> now you can go play poker in theory
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-22.35 uploaded (May your computer boot happily)
<bluefoxicy> BenC:  what does abi do?
<BenC> abi is the kernel compatibility
<maks> abi does not exist ;)
<BenC> if the ABI changes, then modules compiled against it (like LRM) have to be recompiled
<BenC> if the ABI doesn't change, then all modules should still work
<BenC> maks: no, there's no _stable_ abi, but there is an abi :)
<maks> BenC: catched ;)
<fabbione> BenC: congrats boy
<fabbione> BenC: time to fork ubuntu-dapper-2.6 and start ubuntu-2.6 for edgy? ;)
<BenC> fabbione: don't forget everyone that helped, like you :)
<fabbione> i didn't do much come on
<BenC> yep, that's my unofficial Friday excercise
<fabbione> ehehe
<fabbione> BenC: once you open edgy can you please merge gfs2 from kernel.org?
<BenC> gfs2 git tree?
<fabbione> i want an early start for the cluster stuff since it will change a lot
<fabbione> yes
<fabbione> we will be able to kill cman from the kernel
<fabbione> it's all userland now
<fabbione> otherwise i can prepare a commit that will revert all the cluster bits from GFS1
<fabbione> and we can merge gfs2 later
<zul> BenC, then you can show me some stuff later
<BenC> zul: sure thing
<BenC> setuid: if you just want to build stock kernels for Ubuntu, without initrd, just do a normal kernel build, install, modules-install
<BenC> and edit /boot/grub/menu.lst to reflect the lack of initrd
<setuid> Of course, but I need the new kernel to represent the same level of functionality as the running Ubuntu kernels, so if that's as simple as dropping in a .config from /boot, I'm golden. I remember running into all kinds of weirdness with this approach about 2 months ago. 
<BenC> Probably just adding a custom entry to grub's menu for your kernel would suffice (and keep you from messing up anything specific to Ubuntu's stuff)
<setuid> I'll give it a go again, maybe bugs were fixed. 
<setuid> Naturally
<BenC> copy the config
<BenC> but without an initrd, you will need to change some drivers to be built-in (storage drivers, and filesystem drivers)
<BenC> if you want to build the proper way "make-kpkg --initrd --rootcmd fakeroot kernel_image"
<BenC> setuid: I have one question, if you don't like the way that Ubuntu's kernel images are working (the boot process, initrd, etc.), why are you using Ubuntu for testing of these drivers?
<setuid> BenC: Trying to model the environment with newer kernels for our users (I'm the maintainer of pilot-link, which projects like Evolution, gnome-pilot, J-Pilot, KPilot, PilotManager and several commercial projects rely upon) 
<setuid> So we get reports of bugs, and I need to identify if they're due to kernel patches, or kernel bugs. 
<setuid> Then flet out from there
<setuid> Fedora is the worst offender, I'm afraid to admit. 
<setuid> 9 times out of 10, going to a non-Fedora kernel solves a truckload of users problems with sync 
<setuid> make silentoldconfig doesn't seem to work with the most-recent 6 2.6.16 kernels
<setuid> I'll keep going back 
<desrt> silentoldconfig is only a good idea if you're actually using the same kernel version as the config was generated for
<desrt> since otherwise there will be deltas in the available options and you probably want to use 'oldconfig'
<setuid> Or close enough, but yes. 
<setuid> I'll mrproper and restart
<setuid> I wish mconfig supported 2.6
<desrt> does 2.7 exist yet?
<setuid> Some work in git
<setuid> iirc
<crimsun> BenC: thanks again!
<chuck> heylo
<chuck> doh
<crimsun> hey zul :-)
<zul> hey crimsun 
<zul> so I take it im going to the xen conference thingy
<crimsun> awesome
<zul> heh i was asking
<setuid> Ok, that didn't work (blew up in initrd, as I suspected)
<setuid> Why does mkinitrd make a cramfs initrd, instead of a standard compressed cpio image? 
<setuid> I've taken a vanilla 2.6.16.16 kernel and copied my Ubuntu's 2.6.15-22 .config into the tree, did make-kpkg kernel-image, it built the kernel + modules... but initrd fails. 
<mjg59_> Because it's mkinitrd, not mkinitramfs
<setuid> So I need to use mkinitramfs? 
<setuid> But the resulting line in grub's config is for an initrd? How... confusing. ;) 
<mjg59_> The filename is still initrd for compatibility reasons
<mjg59_> It's loaded in the same way
<setuid> Almost worked, it booted and X failed, probably some fglrx thing.. no r300 or radeon in this tree, apparently. 
#ubuntu-kernel 2006-05-24
<setuid> Well that was fun... seems the fglrx module doesn't built at all, and nothing I can find contains it, nor radeon or r300 modules for the kernel, so it all dies after I try to log in. 
<setuid> I get the gdm login/graphics/etc. but after I log in, it just recycles gdm, no X at all after login. 
<setuid> Is there some magical mojo to get the fglrx kernel module built for a custom kernel? 
<jbailey> benc, airlied: I noticed that the kernel from today has more r300 bits in it.
<jbailey> So I'm trying it again. =)
<BenC> jbailey: yeah, I'm hoping that will help you
<setuid> hrm, r300 you say? ;) 
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernl GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-22.35 uploaded (May your computer boot happily)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-22.35 uploaded (May your computer boot happily)
<BenC> well, he goes a git-pull from latest kernel
<jbailey> BenC: *lol*
<jbailey> I'd say "sheesh, you barely stopped for a smoke", except I'm sure that's not true ;)
<BenC> this merge is getting ugly :)
<jbailey> Do you cherry pick changesets, or create new diffs when you do backports?
<BenC> jbailey: a little of both
<jbailey> I'm really not looking forward to merging glibc with Debian again.
<BenC> some of the stuff can't be cherry picked, especially things that made the semphore -> mutex switch
<jbailey> Right.
<jbailey> Assuming you're targetting .17 for edgy?
<jbailey> I'm wondering if glibc should have support for the new syscalls.
<BenC> man, I know I've seen atleast 50 conflicts pass by so far
<BenC> yeah, maybe even .18
<jbailey> 'k
<BenC> if .17 released within 4 weeks of edgy opening, then we'll target .18
<jbailey> You're brave.
<jbailey> Aren't we theoretically still aiming for an October edgy release?
<BenC> Linus has been sticking with his 3 month release cycles pretty closely
<BenC> are we??!
<BenC> wow, that sounds like it will be a little insane
<jbailey> I haven't seen anything that says we're not.
<crimsun> yeah, we're shooting for a shortened one to get back on track
<crimsun> 6.06, 6.10, 7.04, 7.10, ...
<jbailey> Anyhow, off to the gym.
<BenC> shit, this merge is going to take a few days
<desrt> oh man
<desrt> edgy kernel already?
<BenC> 360 files conflicting
<cjb> This is for edgy?  I think Fedora does things pretty well by rebasing to Linus every day.
<cjb> But I guess they stay closer to upstream than you guys.
<desrt> it takes a lot of guts to be as cool as benc :)
<cjb> he doesn't feel the peer pressure, huh :)
<cjb> Of course, Fedora also introduces weird bugs that break things that they then ignore the bug report on for a month, and then continue to ignore it after I find out what they've done wrong and give them a patch to fix it.  *sigh*
<desrt> BenC; got a sec to explain something to me?
<airlied> cjb: kernel bugs? or other things?
<desrt> (or anyone who knows, really)
<cjb> airlied: Yeah, kernel, I was thinking of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190128 .
<desrt> when building a new kernel config, how do i decide if it needs a new ABI number and how do i affect the change?  is this somehow automated?
<cjb> (Which is still broken in Rawhide.)
<airlied> I haven't seen davej online lately, he might be away.. :-)
<cjb> He's posting to lkml and pushing new kernels, so I think he is around, but I've heard that he's pretty swamped.
<airlied> they should have a hey I fixed this flag in bugzilla..
<crimsun> desrt: yes, it's in debian/rules.
<desrt> crimsun; does kpkg automatically deal with it?
<crimsun> desrt: it's sed, grep, wc, and shell magic.
<cjb> airlied: That's a really good idea.  I wouldn't have privileges to change state to it, though, unless they make it so that anyone can.  Which would also be a good idea.
<jbailey> cjb: Every distro has their own approaches to kernel, toolchain, etc.
<jbailey> It's what makes us all interesting ;)
<desrt> jbailey; is there more of a formal office in montreal these days?
<cjb> Yeah.  And then there's Xen, which rebases against -stable guaranteeing that *no* distro will be in a position to merge it, no matter how often they rebase to Linus.  :)
<desrt> crimsun; i guess the thing that confuses me -- you have to know the kernel version number before you start building it
<desrt> crimsun; but it doesn't seem like you'd know the ABI version number until after building
<BenC> desrt: If you do the debian/rules build, it will tell you the ABI changed
<BenC> and if it does do: debian/rules bumpabi
<BenC> and be sure to edit the version in debian/changelog
<desrt> then i have to rebuild?
<BenC> debian/rules binary-debs
<BenC> is the target I use
<BenC> desrt: yeah
<desrt> crikey
<BenC> desrt: it will only build the first target though
<BenC> not the whole thing
<desrt> ok.  if i'm fairly sure the ABI is gonna change then i can just bumpabi first?
<BenC> desrt: apt-get install ccache
<desrt> good call.
<BenC> yeah
<desrt> does that setup automagically?
<BenC> you have to add /usr/lib/ccache to the front of your PATH
<desrt> done & done
<desrt> so first, build
<BenC> maybe even set CCACHE_DIR to some place you want
<BenC> debian/rules binary-debs
* cjb symlinks gcc to 'ccacne gcc'.
<BenC> if the ABI changes, run debian/rules bumpabi
<desrt> erm....
<desrt> there is no debian/ directory here?
<BenC> edit debian/changelog to reflect the ABI change
<BenC> then how can you have an existing ABI? :)
<desrt> where do i get debian/ from?
<jbailey> desrt: Yeah, we take possesion of it next week.
<BenC> apt-get source linux-source-2.6.15
<desrt> oh.
<desrt> i thought install == source for linux-source
<BenC> well, it is, minus the debian directory that we use to build the packages
<desrt> ok.  this actually makes quite a bit more sense now :)
<desrt> what of make-kpkg?
<desrt> jbailey; that's pretty sweet.  where is it?
<chuck_> bleah...
<desrt> BenC; so i take it the bump-abi rule just copies the new abi info into the debian/ directory?
<BenC> desrt: it just sed's the files needed to reflect the new version
<desrt> there's a stored copy of the 'old' abi information somewhere in debian/ for purposes of comparison, right?
<desrt> ok... so the -23 source package has a copy of the abi's for -22 but not for -23
<jbailey> desrt: Near Lucien L'alier.
<jbailey> (mtro)
<desrt> jbailey; cool.
<jbailey> BenC: X spun out and kill -9 didn't solve it.
<jbailey> So still some sort of problem  Ah well.  post-dapper problem.
<airlied> jbailey: still nothing causes the spin?
<airlied> just general usage?
<BenC> jbailey: that sucks
<jbailey> airlied: In this case it was in a screensaver.
<jbailey> I was afk, so I don't have more details.
<jbailey> In a screensaver, I can't really tell if it's thatit's changing, was about to DPMS, etc.
<airlied> hmm I'll probably have to run more screensavers.. you on 64-bit or SMP?
<jbailey> It's unfortunately a very poor testcase.
<jbailey> both. =)
<airlied> ah lovely... I've always wondered if we might have some SMP issues..
<jbailey> airlied: If you have some sort of assault test that you want me to run, I can cheerfully do so.
<airlied> my only SMP machine has an X1300 in it, so I can't use it yet..
<jbailey> Although perhaps not tonight.
<airlied> jbailey: I'd love to have one that's the problem we don't so finding these things is a real pita..
<airlied> I might put a PCI radeon in my SMP box for a test...
<jbailey> YEah, I'm sure.
<jbailey> I don't know how to start troubleshooting this sort of thing.
<jbailey> If it's at all significant, kill -9 wouldn't take out Xorg
<airlied> yeah nothing will take it out once the GPU crashes..
<airlied> it's also like playing whack a mole, you smack one bug, another bug the exact same pops up, it could be 5 bugs all different having the same symptoms..
<jbailey> heh.
<jbailey> Are you part of upstream for this?
<airlied> jbailey: I'm the DRM maintainer for upstream..
<jbailey> Ah, cool.
<jbailey> You seemed excessivly clueful for a random observer. =)
<airlied> I also try and fix r300 things because I hate ATI. :-P
<fabbione_> morning guys
<jbailey> airlied: Eh, you express hatred in a way with which I am not familiar ;)
<jbailey> Heya Fabio!
<fabbione> hey Jeff
* jbailey goes and grabs some more food.
<fabbione> touch: cannot touch `/root/glibc-2.3.6/stamp-dir/check_sparc64': No space left on device
<fabbione> WTF
<fabbione> infinity: i need your binaries.. sort of now
<BenC> airlied: When I sync to 2.6.17-git, I can just revert and merge conflicts in drm to match Linus' tree, right?
<airlied> BenC: yes there should be nothing in your tree that isn't in Linus..
<infinity> mjg59: Too late to do anything about it now, but I think your "switch to 640x480 on some machines" hack could be circumvented with just tweaking the 640x400 timings instead.
<infinity> mjg59: If I'd known you were looking at doing that, I would have worked with you to test some stuff.  I didn't have access to any hardware where the current (admittedly not-quite-right) timings didn't work, so I couldn't test better ones. :/
<bluefoxicy> whew.
<bluefoxicy> that is ugly as shit.
* bluefoxicy is attempting to write a patch to control mmap() and stack randomization entropy levels from kernel parameters
<bluefoxicy> trivial but 1) i don't understand the code really so I may be off by 1; 2) I shoved two additions, a subtraction, a bit shift, and a modulus in one statement.
<bluefoxicy> at least the code appears robust enough to handle it even if I screw up.
<infinity> BenC: Hrm, the CONFIG_RTC=y thing didn't go in, did it?
<Keybuk> oh, hurrah
<Keybuk> pleeeease put that in
<Keybuk> and GENRTC=y
<Keybuk> let more pointless modules bite the dust <g>
<infinity> It's less about pointless modules and more about SMP machines *requiring* the RTC driver to manipulate the hwclock in any sane fashion.
<BenC> infinity: damnit...that's two config options I forgot to add
<infinity> So hwclock and ntp don't blow up, among others.
<Keybuk> hwclock wouldn't blow up now anyway
<BenC> I forgot HUGEPAGES for PPC64 aswell
* Keybuk points at /etc/udev/rules.d/85-hwclock.rules
<BenC> I'll sneak it into the first update
<desrt> Keybuk; try to convince BenC to release a -24 for dapper :)
<BenC> no no
* desrt j/k
<BenC> -23.36 if anything :)
<desrt> fwiw i have a sneaky suspicion that hugepages changes the abi
<Keybuk> desrt: that wouldn't be an ABI change
<desrt> you certainly get new functions
<infinity> BenC: When you say "first update", you mean "the first update before release", not "after", right? :)
<Keybuk> yeah, let's have ANOTHER kernel ABI change before release
<Keybuk> they're SO MUCH FUN
<infinity> BenC: I suspect the RTC change especially won't fly after release.
<BenC> if HUGEPAGES changes the ABI, then powerpc will get an ignore file
<infinity> (Doubly-so, since we seem to build some udebs with rtc drivers in them?... Feh)
<BenC> I don't think it would affect modules anyway
<desrt> ignore file?
<BenC> desrt: echo "Yes" > debian/abi/powerpc.ignore
<BenC> so I don't have to bump the ABI
<desrt> ah.  i see.  cheater file :)
<infinity> Of course, we put those udebs in universe, so we know d-i isn't using them ANYWAY.
<BenC> if it only adds functions, it would ignore it anyway
<BenC> since new != important
<BenC> wait a second
<desrt> plus... the normal modules get upgraded along with -image and you don't really have a whole lot of linux-restricted-modules kicking around on ppc
<BenC> I'm not working...I don't have money in my budget for extraneous beer-to-super expenses
<Keybuk> BenC: fabbione promised to wipe clean the irc logs :)
<infinity> BenC: I'll cover your drink requirement.  I'm sure I already owe several.
<BenC> lol
<infinity> Hell, I actually UPLOADED on my day off.
<infinity> So, I'm a lost cause.
<Keybuk> infinity: and it wasn't exactly a subtle package either ;)
* desrt has been looking for someone willing to do an upload since last night :p
<BenC> I'm at 73 files remaining of 360 for the edgy 2.6.17 git merge
<zyga> hi
<zyga> I've got a kernel panic just a moment ago
<zyga> I've got pictures if anyone is interested
<desrt> BenC; btw.. is it normal that the kernel doesn't build-dep on kernel-wedge or m4?
<BenC> zyga: you're too late...all oopses are not considered features, which enable breaks to prevent hyper-tension and repetitive syndromes
<jbailey> s/not/now/ ?
<zyga> ? :D
<BenC> yes
<zyga> duh.. I need to run now
<zyga> I'll post the pictures and come back in 5 hours
<zyga> bbl
<BenC> desrt: the kernel, or the kernel source?
<desrt> BenC; source
<desrt> oh man i'm a dumbass.  i did apt-get build-dep linux-source.  disregard.
<BenC> apt-get install linux-kernel-devel
<BenC> that'll help a little too :)
<BenC> http://www.technologyevangelist.com/2006/05/ubuntu_linux_dapper.html
<desrt> so i'm still trying to figure out the abi thing
* BenC notes we are better than Vista
<BenC> and, our install is easier than MacOSX, which I think says a lot more
<desrt> the -23 source i downloaded contains the -22 abi files.... how does the build check if my build is the same as -23?
<BenC> desrt: it doesn't
<BenC> we have to add the -23 files in afterwards, they aren't important in that source file
<desrt> ah.  so if you were building a kernel, you'd have them kicking around in there
<infinity> desrt: Grab the -23 ABI file from /boot/ :)
<desrt> ahah.  truth revealed
<desrt> infinity; thx. i've been wondering :)
<BenC> desrt: debian/bin/getabis 2.6.15 23
<BenC> that will get them _all_
<infinity> BenC: Actually, that's a fair point.  Maybe our shipping kernel source should contain the ABI files, for people trying to mangle derivative kernel builds.
<BenC> in the process, downloading a few hundred megs of .debs :)
<infinity> BenC: Which makes a good excuse for one last upload. :)
<desrt> FAILED
<desrt> :)
<BenC> desrt: debian/bin/getabis 2.6.15 23.35
<infinity> BenC: The process is confusing enough for people to understand without also wondering where the files are. :)
<desrt> to hell with it
<BenC> infinity: Nah, ppl love a good file hunt :)
* desrt copies from /boot :)
<jbailey> BenC: I'm vaguely amused at comparisons between Linux distros and Vista.
<BenC> jbailey: I'm ammused that our TCP/IP stack needs optimizing
<jbailey> With a target release of midwinters, the likelyhood of xgl being stable is high.
<jbailey> Did davem just plan a redo of a large part of the IP stack?
<jbailey> I thought I saw something about doing channels and some other optimisation.
<infinity> Our IP stack has needed optimisation for eons, this is no surprise.
<jbailey> But just that all the flashing zing that Vista can pump out will probably be matched in every aspect that an end user will care about.
<infinity> The WinNT IP stack was lifted nearly verbatim from BSD, and has been very performant from day 1.
<infinity> But, yeah, most users don't give a hoot about a slightly better IP stack.
<infinity> And most server scenarios don't push data from RAM fast enough for those benchmarks to mean anything to them.
<infinity> (Some few here and there actually do, but most machines aren't bottlenecked elsewhere)
<infinity> s/aren't/are/
<desrt> heh
<desrt> this dapper review has an entire paragraph devoted to "we should have shipped networkmanager by default"
<infinity> Yeah, WiFi is either not important at all, or THE MOST IMPORTANT THING EVER.  It's a rather polarising thing.
<infinity> I'm still in the "not important at all" camp, despite having a small wireless network at home.
<desrt> it depends on if you have a laptop or not
<infinity> Mostly because when I want to get any real work done, I still switch to copper (and probably always will, since copper is always a few steps ahead)
<desrt> my laptop's inability to get onto my wireless network without me invoking a shellscript is sort of a sore spot
<desrt> it doesn't hurt me too much....
<desrt> but it hurts my "look how awesome ubuntu is!" credibility :p
<infinity> Mine seems to do well anywhere with NM now.
<infinity> WEP, WPA, etc, etc.
<desrt> nm is terribly buggy on bigendian
<infinity> So are many wireless drivers. :/
<desrt> the opensource broadcom ones seem to work fairly well
<desrt> and the latest upgrade massively improved the range i get
<desrt> i used to barely be able to connect from the far corner of my office... now i get flawless signal from across the hall
<BenC> linux-source-2.6.15 (2.6.15-23.36) UNRELEASED; urgency=low
<BenC>   Changes by Ben Collins
<BenC>   * powerpc64: Enable HUGETLB
<BenC>   * x86: Build-in rtc and genrtc on all but the 386 kernel.
<BenC> I'll try to get this in for dapper release, but no guarantees
<desrt> :)
<infinity>   * amd64: Same as above
<infinity> ?
<BenC> good call
<infinity> I have no idea about RTC drivers on PPC, so I can't comment there, sadly.
<infinity> If you have an SMP G5, you could do some hwclock testing.
<desrt> what's the issue with having the driver built-in?
<desrt> kernel gets correct initial time without having to use hwclock in the initscript?
<infinity> But on amd64, we know we want it (heck, the installer does "echo rtc >> /etc/modules" on amd64, doesn't it?)
<infinity> desrt: No.
<infinity> desrt: hwclock and ntp (and other hwclock-using things) just plain don't work right on SMP systems without an rtc driver.
<infinity> desrt: So having it modular on our kernels that are now all SMP-enabled is just plain silly.
<desrt> btw: there is no 'rtc' module on ppc
<desrt> infinity; why not just load the module on boot?
<infinity> desrt: Because loading it on boot unconditionally it no different from having it built in?
<desrt> fair enough :)
<infinity> desrt: s/it no/is no/
<infinity> Simplicity++
<desrt> i thought the ubuntu kernel policy was "make everything a module that is humanly possible"
<infinity> I dislike adding more moving parts without a good reason.
<infinity> No, that's the Herbert Xu kernel policy.
<desrt> that's my kernel policy too :p
<infinity> Ours is more like "make things modular if there are conflicting ways to set up a system"
<desrt> or my pre-ubuntu-feeding-my-kernel policy
<infinity> You'll note we don't modularise the IP stack, for instance.
<infinity> Which CAN be done.
<infinity> But it's insane.
<desrt> wait.. the true test
<desrt> brb
<desrt> ok
<desrt> unix domain sockets -- not a module
<desrt> good job :)
<infinity> Yeah, I vaguely recall Xu building that one modular.
<desrt> who is Xu?  i think i'd like this chap.
<infinity> Herbert Xu.. Was a Debian kernel maintainer for ages, worked for us on the kernel back in the warty and hoary days, and did some contract work for us in the breezy timeframe.
<infinity> Has nothing to do with us recently.
<fabbione> BenC: what about HUGEPAGE for sparc?
<fabbione> HUGETLB i mean
<BenC> I can do that too
<fabbione> is it worth?
<fabbione> or are we going to destabilize *?
<BenC> probably best to ask davem
<fabbione> i know he enables it in his kernels
* BenC is down 10 files to manually merge from the 360 he started with
<BenC> fabbione: might be a good idea then
<jbailey> BenC: 10 files?!?
<jbailey> slacker ;)
* jbailey hides
<BenC> it'd be a lot more if my perl skillz weren't soo good :P
* BenC pushes a most likely unbuildable edgy 2.6.17-git kernel
<fabbione> BenC: cool :)
<BenC> yay, first 2.6.17-git build started!
* BenC waits for it to fail horribly
<BenC> if this works on the first try, I'll be worried
<crimsun> I expect it to break horribly in sound/  ;-)
<BenC> I reverted most of sound/
<BenC> it's pretty much stock 2.7.17-git
<crimsun> oh excellent.
<BenC> except for my snd-power-mac forward port
<BenC> crimsun: do you go both ways...like if I send you patches can you submit them to alsa? :)
<crimsun> BenC: oh sure
<BenC> good, I need to get the snd-powermac changes merged
<BenC> benh has been bugging me to get it done for awhile
<infinity> BenC: Stop hitting on our volunteer contributors.  It could be misconstrued as sexual harassment. :)
<BenC> hehe
<infinity> "Do you go both ways" indeed.
<jbailey> BenC: merged..  What did you take on doign sound?
<bluefoxicy> fuck that
<bluefoxicy> oops wrong window
<tuxmaniac> Guys isnt it linux-kernel-tree to download source from ubuntu breezy?
<crimsun> you probably mean linux-tree{-2.6.12}
<tuxmaniac> crimsun: yes.. linux-tree-2.6.12 will download the source I guess? I forgot and now in dapper its linux-source?
<bluefoxicy> woot!
<bluefoxicy> I wrote a patch to let me shift around entropy for mmap() and stack bases via kernel command line!  ... now to build and test.
<zyga> back
<zyga> anyone awake?
<bluefoxicy> I'm awake
<bluefoxicy> And very bored.
<bluefoxicy>   LD [M]   drivers/media/video/zr36067.o
<bluefoxicy>   CC [M]   drivers/media/video/videocodec.o
<bluefoxicy> It seems I have much more boredom to come.
* bluefoxicy building a kernel package to test a patch
<zyga> I've got pictures of a kernel panic
<zyga> interested? :)
<bluefoxicy> ocrap, i have it set to build for like 59 different architectures
<bluefoxicy> abort, abort!
<zyga> (fspot is still working on that part though :)
<zyga> 59? :)
<bluefoxicy> didn't clean antyhing out
<bluefoxicy> http://rafb.net/paste/results/ImsI6i74.html  <-- this is what I'm doing
<zyga> checking
<zyga> I'll post the pictures in a moment
<bluefoxicy> gotta love how I replace 2 lines of code with 23 lines ;)
<zyga> holy sh... :-)
<bluefoxicy> random_factor = get_random_int() % (4096 << (mmap_random_bits - 1));  <-- this is wrong :)
<zyga> I had just plugged an USB mic+headphones
<zyga> and a notification popup asked me to configure it...
<zyga> when did linux distros get that good!
<bluefoxicy> lol
<infinity> The more interesting thing isn't that it asked... It's whether or not it workes afterward. :)
<infinity> s/workes/worked/
* bluefoxicy changes things directly inside the patch ;)
<zyga> good point
<zyga> well gstreamer seems to see it
* zyga is curious what kind of usb device it reports as
<zyga> hmm, bDeviceClass - 0 
<zyga> I don't know usb :P
<zyga> nyway
<bluefoxicy> lsusb
<zyga> pictures are ready
<zyga> bluefoxicy: I did use lsusb
<bluefoxicy> what'd you panic this time?
* bluefoxicy would imagine usb headphones == sound card
<zyga> bluefoxicy: probably right
<bluefoxicy> zyga:  next april I should send a patch to lkml to fix panic()
<bluefoxicy> it occurs to me the kernel doens't actually panic
<zyga> #define panic() BUG() 
<zyga> http://ubuntu.suxx.pl/2006--1/bugs/kernel-panic-0
<zyga> (tla has left its marks on my soul)
<bluefoxicy> I'll fix this by having it mdelay() for a few seconds and then randomly printk() one of {"My mind is going","I'm scared, Dave; will I dream?","Daisy, daisy....","HELP ME!!!!!!} in a loop.
<zyga> hehe
<zyga> hrumpf... gnome-sound-properties doesn't remember the default sound device setting
<zyga> whoooa
<zyga> it works 
<zyga> are my photos of any use?
<bluefoxicy> I see lots of numbers.
<bluefoxicy> so not to me :)
<zyga> there is a backtrace...
<zyga> http://ubuntu.suxx.pl/2006--1/bugs/kernel-panic-0/DSCN5461.JPG
<bluefoxicy> I know
#ubuntu-kernel 2006-05-25
<jbailey> Ahahah.  Someone went through the effort of registering ubuntu.suxx? =)
<bluefoxicy> suxx.pl with a subdomain ubuntu
<jbailey> I just think it's funny. =)
<jbailey> Some people like us, some people hate us. =)
<bluefoxicy> watch this.
<bluefoxicy> gimme 2 minutes.
<bluefoxicy> jbailey: ubuntu-dapper.kicks-ass.net
<bluefoxicy> :>
* bluefoxicy removes that now.
<jbailey> =)
<zyga> bluefoxicy: suxx.pl is my domain
<zyga> ubuntu is just a topic subdomain
<zyga> I had a bad day when I registered suxx.pl but now it's just history :)
<zyga> I like ubuntu alot :D
<zyga> jbailey: do you happen to use itanium?
<jbailey> zyga: FSVO 'use'
<zyga> great, do you happen to need a dual CPU daughterboard for free?
<zyga> for itanium 1 :/
<jbailey> Nope.  Mine's a dual 900mhz itanium 2.
<zyga> I've got two itanium 2 cpus as well but I plan to use them as soon as I find a mobo :)
<zyga> eh :)
<zyga> those things are pricey :)
<jbailey> I got a bit lucky with that particular hardware acquisition.
<zyga> well so did I, I guess
<zyga> both cpu's cost about 20$
<zyga> 10$ / cpu
<zyga> even less than that useless daugtherboard :)
<infinity> zyga: You could mail me the daughterboard and I could use it to decorate my house.
<infinity> zyga: I suspect you'll have a hard time finding someone who will actually USE it, though.
<zyga> if you cover the shipping I might ;]  I also posted it on to the debian-hw-donations project
<zyga> I might end up buys the remaining bits to assemble an itanium 1 box
<zyga> it's brand new you know :)
<zyga> I kind of like the connector :)
<zyga> looks like some ancient computer card :D
<bluefoxicy> oh holy shit it works!
<jbailey> bluefoxicy: it?
<bluefoxicy> jbailey:  http://rafb.net/paste/results/VkXzkF11.html paxtest on ubuntu
<bluefoxicy> I wrote a small kernel patch, and then booted the new kernel with stack_random_bits=22 mmap_random_bits=16
<bluefoxicy> http://rafb.net/paste/results/gI4UFC11.html
<jbailey> bluefoxicy: I was reading drepper's blog on the lock downs that they did.  Neat stuff.
<jbailey> I hope we can do that for edgy.
<bluefoxicy> on what?
<jbailey> Lemme find the posting for you
<bluefoxicy> jbailey:  yeah.  I want to try to get this patch into mainline, but I'm hoping maybe I can get ubuntu behind me?
<bluefoxicy> It lets you adjust mmap() and stack randomization at boot time
<bluefoxicy> the stack by default shifts around in 8 megs, mmap() base in 1 meg
<jbailey> http://udrepper.livejournal.com/9666.html
<jbailey> bluefoxicy: Dunno.  I'm not involved in the kernel at all.
<bluefoxicy> this gives (to granularity of 16 bytes) 524288 positions in 128 pages for stack; and (to granularity of 4096 bytes) 256 positions for the mmap() base (libraries etc)
<jbailey> I just show up here to  harass Ben. =)
<bluefoxicy> Of course the stack you might throw 4096 bytes of stuffing into and make that 128 ranges your attack works in...
<bluefoxicy> in such a case, imagine we have say 1000 users who get attacked on a vulnerability protected by this.  That's 1/128 success, maybe 10 fall to it? (gaim has an executable stack, x86 tends to have an executable stack...)
<bluefoxicy> worst case scenario.
* bluefoxicy wants to be able to hit a button and get high-order entropy :)  Also heap randomization which fedora seems to have...
<bluefoxicy> ah
<bluefoxicy> that's nice, yes
<jbailey> Right.  I'd like us to follow this if we could for edgy.
<jbailey> I think it would be very hard.
<jbailey> Third party programs are likely to also cause troubles.
<bluefoxicy> I know nvidia glx breaks due to that stuff (because PAX BROKE NVIDIA GLX AND WE BITCHED AT THEM FOR 3 YEARS BEFORE GIVING UP)
<bluefoxicy> nVIdia will never care.
<bluefoxicy> they'll just say, "Well turn the security off."
<bluefoxicy> Really, it's not a matter of negotiating, 3 years of negotiation did nothing.  Go kick them in the balls if you want it to get done
<bluefoxicy> What we need is an open source nvidia glx driver
<jbailey> True.
<jbailey> Anyone working on one? =)
<bluefoxicy> nope :)
<infinity> The proprietary one needs to start sucking more so people are more motivated to replace it.
<infinity> I can only assume that fglrx being COMPLETE CRAP has been a large motivation for radeon hacking.
<bluefoxicy> also that radeon mainly worked before the fglrx was out
<jbailey> Oh well, one more thing in the list of things I'll never have the skill to hack on. =)
<bluefoxicy> we actually had 3D on lower radeon
<jbailey> And probably wouldn't chip in more than $20 towards getting fixed.
<bluefoxicy> jbailey:  go offer to suck ajax's thing for it or something, maybe he'll finally get around to writing it.
<infinity> jbailey: Get a brain transfusion from airlied.
<lifeless> jbailey: thats what things like daniels are for
<bluefoxicy> i knew an excellent graphics card hacker
<jbailey> infinity: I could all the drm knowledge.  And he could then go write scary makefiles instead?
<jbailey> Joy.
<bluefoxicy> but he hates open source stuff.
<bluefoxicy> it's an egoism thing
<jbailey> lifeless: Eh, didn't know you trakced this channel. =)
<bluefoxicy> but the guy picked up a game cube and started writing stuff to control its hardware
<bluefoxicy> could reverse engineer shit
<infinity> jbailey: Well, he's an X hacker, so probably already know scary Imake. :)
<bluefoxicy> it didn't seem like a big deal to him, he was just really smart
<mjg59> There are people working on an open nvidia driver
<bluefoxicy> hey mj
<bluefoxicy> http://rafb.net/paste/results/1GRXs654.html about to send this to lkml to see what I get.
<zul> hey
<zul> how was you guys day off?
<bluefoxicy> WTF?
<bluefoxicy> Thunderbird suggests "testatrix" in place of "paxtest"
<bluefoxicy> ubotu... dammit wrong channel
<bluefoxicy> http://lkml.org/lkml/2006/5/19/219  And there it goes.
<dilinger> mm.  people aren't going to like that hardcoded page size
<bluefoxicy> mm.
<bluefoxicy> I did note as a FIXME to replace 4096 with PAGE_SIZE
<dilinger> yep
<bluefoxicy> I will have to rewrite some of the logic for that of course.
<bluefoxicy> the semantics of stack_random_bits for example means the stack can take on 2^stack_random_bits different values.
<bluefoxicy> if you lose the ability to shift by 16 bytes at a time then 16 bits of stack randomization is 256M; otherwise 24 bits is 256M
<bluefoxicy> similarly, if your pages are 8KiB instead of 4KiB you have to use the first 9 bits for intra-page randomization and the rest for page randomization.
<bluefoxicy> and of course mmap() randomization is straight randomization * PAGE_SIZE, which is easy
<bluefoxicy> the stack stuff however requires log base 2 calculations.
<bluefoxicy> dilinger:  to be fair, the original shifted around by 8192 (2 pages) for sub-page stack randomization.
<bluefoxicy> Anyone know how to log(2,n) something?
<bluefoxicy> dilinger:  fixed.
<kimo> why does the topic still say -22 ! duh, I'm on -23 now
<BenC> dpkg-deb: building package `linux-image-2.6.17-1-powerpc' in `../linux-image-2.6.17-1-powerpc_2.6.17-1.1_powerpc.deb'.
<BenC> yummy
<BenC> sweet, full build of 2.6.17-git for edgy on powerpc
<BenC> Linux colorless 2.6.17-1-powerpc #1 Sat May 20 01:39:11 EDT 2006 ppc GNU/Linux
<bluefoxicy> aye ben.
<bluefoxicy> http://rafb.net/paste/results/b1eCH937.html  Think I got a shot at getting this one into Edgy as per https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap ?
<bluefoxicy> I'm still working on it, gotta handle some logic for x86-64 with IA-32 emulation specifically.
<bluefoxicy> (wouldn't want randomization over 1TiB of VA space and suddenly an IA-32 process tries to put stuff at 0x001C000000000000 and finds VMA isn't that long)
<BenC> cool
<bluefoxicy> aha, got it
<bluefoxicy> I used TASK_SIZE / 6 as my random interval
<bluefoxicy> so IA-32 code should let you tell it to randomize mmap() by 512M and stack by 512M; x86-64 assuming VMA space is 192TiB (of the 48 bit 256TiB space the CPU gives us) would give 32TiB max
<bluefoxicy> but if you don't specify on the kernel command line, it'll just do 1MiB mmap() and 8MiB stack, as it does now :)
<bluefoxicy> I should probably cut that back to TASK_SIZE/12
<bluefoxicy> since I know /6 will have issues on IA-32
<bluefoxicy> anyway gotta go for about an hour, be back in a bit.
<bluefoxicy> (what I really need is a guaranteed TASK_STACK_ALIGN, which should always be 16, to determine how much alignment the stack needs for randomization)
<bluefoxicy> yay
<zul> heylo
<bluefoxicy> my patch looks nice now, and it still patches to the dapper one ;)
<bluefoxicy> hey zul
<zul> hey bluefoxicy 
<bluefoxicy> http://rafb.net/paste/results/VblFVp66.html  :>
<bluefoxicy> hmm.  Build fails.
* bluefoxicy forgot something.  *fixes*
<bluefoxicy> didn't define a long I used in one function.
<bluefoxicy> now it works.
<bluefoxicy> http://rafb.net/paste/results/pOP53u33.html  :)
<bluefoxicy> shit.
* bluefoxicy copied a chunk of code around without actually re-declaring the variable it uses, so he keeps finding spots where max_random_bits isn't defined >:|
<holden> hi. does anyone know what /lib/modules/2.6.15-23-amd64-k8/volatile is for?
<mjg59> For linking non-free modules
<holden> mount reports:  lrm on /lib/modules/2.6.15-23-amd64-k8/volatile type tmpfs (rw)
<holden> do I need it? how can i disable it?
#ubuntu-kernel 2006-05-26
<tuxmaniac> hey guys! If I download the latest 2.6.16.16 from kernel.org and compile and install it on Ubuntu Dapper I know it will work
<tuxmaniac> but we will miss out on the Ubuntu patches right?
<tuxmaniac> So what will be the end effect if one installs a latest vanilla kernel on Dapper?
<crimsun> tuxmaniac: "know it will work"?
<crimsun> tuxmaniac: as in you've tested it, and the udev<->kernel interaction works identically?
<tuxmaniac> no
<tuxmaniac> crimsun: There are some problems?
<tuxmaniac> there are some problems!
<tuxmaniac> But is there no way to install the latest kernel from kernel.org
<tuxmaniac> I did install 2.6.16 on Brezy and it pretty much worked fine except for my synaptic touchpad scroll feature
<crimsun> you can, but there's no guarantee everything will work. The udev<->kernel interaction I mentioned is just one issue.
<tuxmaniac> hmmm.. so the latest on Ubuntu Dapper is 2.6.15-23 but the topic says -22 !?
* ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel GIT tree info (updated): https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-23.35 uploaded (May your computer boot happily)
* tuxmaniac thanks crimsun 
<tuxmaniac> crimsun: I want to ask one more standard question. am very much interested in working with the kernel team. How do I start? Submit patches to bugs or how?
<crimsun> that's an excellent way.
* tuxmaniac finds helluva lot of CONFIG variables missing when comared to the 2.6.15- found on Dapper and that off 2.6.16
<crimsun> well yes, there are rather gigantic differences
<fabbione> BenC: ping?
<BenC> fabbione: pong
<fabbione> hey BenC 
<fabbione> BenC: -23- is no go on my PB
<fabbione> as soon as X starts the machine is totally frozen
<fabbione> hard 
<BenC> running it on mine
<fabbione> -22- works fine
<fabbione> i just dist-upgraded 10 minutes ago or so
<BenC> Linux grayson 2.6.15-23-powerpc #1 Thu May 18 09:56:00 EDT 2006 ppc GNU/Linux
<fabbione> yeah
<fabbione> i do believe you :)
<BenC> I'm running the one I built before upload
<BenC> I'll reboot to the archive one in a second
<fabbione> can you try the one that has been built in the archive?
<fabbione> thanks
<BenC> btw, 2.6.17-1 is building on everything except hppa and ia64 now
<fabbione> cool
<BenC> it boots on my G4, but on my ultra3k it is causing a openboot panic
<BenC> sends it into a POST loop
<fabbione> interesting
<tuxmaniac> fabbione: -23 runs fine on mine too.. Just installed today! :)
<fabbione> tuxmaniac: what model is your?
<tuxmaniac> sorry fabbione Dint see.. ou guys are talking abt ppc.. Mine is x86 :D
<fabbione> BenC: i am going to calibrate the THX on the mythtv box
<fabbione> i will pass by later to check on -23-
<jbailey> BenC: Which gcc are you using for the edgy kernels?
<BenC> whatever /usr/bin/gcc is
<tuxmaniac> BenC: I did a custom install of 2.6.16-ck11 
<tuxmaniac> BenC: While booting the EVMS is generaing a device maper error! What could it be.. Should I disable EVMS or something?
<BenC> not sure
<fabbione> re
<fabbione> BenC: does it boot for you?
<bluefoxicy> gah
* bluefoxicy just defines a per-arch value in mm.h fora blanket #ifndef case
<bluefoxicy> there, booting with stack_random_bits=99 mmap_random_bits=99 on v3 (rebuilding with v4 after this to test that..)
<bluefoxicy> Stack randomisation test (SEGMEXEC)      : No randomisation
<bluefoxicy> yay i broked it :)
* bluefoxicy facedesk.
<bluefoxicy> wow
<bluefoxicy> that's really freaky.
<bluefoxicy> 2 files not to patch because they're simply not there, and the code is new.
#ubuntu-kernel 2006-05-27
<bluefoxicy> Fabulous
<bluefoxicy> http://rafb.net/paste/results/Mq64HK84.html  Works on i386, untested on PPC, tested with 2.6.15-23.35 (skipped the patch for arch/x86-64/ files that aren't in that version), built as i686 and tested.
<bluefoxicy> Any chance at all I can talk this one into Edgy later?
<bluefoxicy> (Dapper's kernel is well past being frozen)
<zul> what is it?
<jbailey> Heya Chuck!
<zul> hey jeff how is it going?
<jbailey> bluefoxicy: This is more stsack randomisation stuff?
<jbailey> bluefoxicy: What's the upstream status of it?  Is it at least in -mm?
<jbailey> zul: Good!
<jbailey> I didn't manage to ping you about the lkh stuff last week.
<zul> jbailey: good to hear
<jbailey> zul: Workin' away as always.
<zul> jbailey: i wasnt around much this weekend but im working on it right now
<jbailey> Oh, nice!
<zul> while watching family guy
<bluefoxicy> jbailey:  nowhere near mm, upstream saw the first try (a really ugly and hackish patch) and only arjan has taken me up on principle, nobody else cares.
<jbailey> bluefoxicy: Really?  Why not?  Stand randomisation is generally accepted as sane, and this doesn't look like it has high cost.
<lifeless> y
<bluefoxicy> jbailey:  This patch has (tested) absolutely 0 effect on i386 if you just patch and reboot; and should have (not tested) absolutely 0 effect on any other architecture if you don't touch it.
<bluefoxicy> Our current kernel inherits mainline's 8 megs of stack randomization and 1 meg of mmap() base randomization, which has been in since 2.6.12
<jbailey> lifeless: Are you agreeing, or just farting?
<bluefoxicy> What the patch I wrote does is leaves that in tact, except makes it dependent on a variable that can be adjusted easily -- and throws a knob on the kernel command line
<bluefoxicy> I had hoped for mainline to lay the framework for SELinux-controlled randomization entropy
<lifeless> jbailey: finger fart
<bluefoxicy> For now, if a user so chooses, he can turn stack and mmap() randomization up/down/off with boot time parameters.
<jbailey> lifeless: =)
<bluefoxicy> jbailey:  I'm going to have to install fedora core 5 here and run paxtest probably to argue with them.  Arjan is claiming 8M and 1M is enough; but I'm pretty sure Fedora Core 5 and RHEL both use 128M (PaX uses 256M, and the code will not let you use more than 1/12 the VMA space-- which is 256M if TASK_SIZE=3G)
<bluefoxicy> jbailey:  I'm looking at https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap (Disclaimer:  I wrote some of it), I'm pretty sure -Wstack-protector and FORTIFY_SOURCE can make Edgy (gcc 4.1)
<jbailey> Cool.
<bluefoxicy> yeah.. I was hoping 4.2 would make edgy but eh.
<bluefoxicy> I hear the stack protector in 4.1 is semi-broken.
<bluefoxicy> FC5 uses it
<bluefoxicy> so it can't be that bad
<bluefoxicy> http://rafb.net/paste/results/wgUvS593.html  Here we go, with FC5's defaults (12 bits and 19 bits, instead of 10 and 19)
<bluefoxicy> wait, the hell
<bluefoxicy> since when do they have randomized ET_EXEC base
* Starting logfile irclogs/ubuntu-kernel.log
<Mithrandir> BenC: any idea about https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 ? Doesn't the kernel actually lock the drive when mounting something off it?
<fabbione> BenC: so -23- on live keeps freezing...
<fabbione> BenC: sometimes when i boot it from hd it works, but switching to console kills the machine
<airlied> fabbione: what graphics card?
<fabbione> airlied: ati
<fabbione> it's a PB g4
<fabbione> exactly the same as BenC
<fabbione> it works for him but not for me
<airlied> fabbione: I assume switching to console is switching from X?
<fabbione> yes
<fabbione> from X to console
<fabbione> it's a hard freeze
<airlied> what ati chipset?
<fabbione> 0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<fabbione> i was just looking at the kernel changelog and stuff to see if there is anything relevant
<airlied> well I merged up the drm changes from the latest kernel to dapper..
<fabbione> oh
<airlied> you mightn't of had DRI enabled on the previous kernel perhaps..
<fabbione> i can check
<fabbione> old kernel seems to have dri enabled
<fabbione> (II) RADEON(0): [DRI]  installation complete
<airlied> can you pastebin an old kernel xorg.0.log and a new one?
<fabbione> let's check with the new one
<fabbione> airlied: sure of course
<fabbione> i was just rebooting into the new one
<fabbione> how curious
<fabbione> now i can ssh into the box but i have no X and keyboard is dead
<fabbione> no
<fabbione> box is dead
<airlied> benh is away as well, I normally punt all ppc to him :-)
<fabbione> yeah i know
<airlied> I really need to get an M10 out of somewhere..
<fabbione> here it is booted fine now
<fabbione> HMMMMMMMMMMMMMM
<fabbione> grabbing the logs....
<fabbione> http://people.ubuntu.com/~fabbione/Xorg.0.log.daltanius.*
<fabbione> the new is when it manages to startup with the new kernel
<fabbione> i need to modify a bit the boot sequence and see if i can scp the logs of when it crashes before it does so
<fabbione> it seems to be DRI/DRM related
<fabbione> (II) RADEON(0): AGP card detected
<fabbione> drmOpenDevice: node name is /dev/dri/card0
<fabbione> drmOpenDevice: open result is -1, (No such device or address)
<fabbione> this is the last thing it can write to disks before it dies
<fabbione> in the middle of DRI init
<fabbione> [  187.896705]  [drm]  Initialized drm 1.0.1 20051102
<fabbione> [  187.991213]  [drm]  Initialized radeon 1.24.0 20060225 on minor 0
<fabbione> [  189.157702]  agpgart: Putting AGP V2 device at 0000:00:0b.0 into 1x mode
<fabbione> [  189.157715]  agpgart: Putting AGP V2 device at 0000:00:10.0 into 1x mode
<fabbione> [  189.305909]  [drm]  Setting GART location based on old memory map
<fabbione> [  189.305928]  [drm]  Loading R300 Microcode
<fabbione> [  189.305987]  [drm]  writeback test succeeded in 1 usecs
<fabbione> this is in dmesg
<fabbione> disabling dri from xorg.conf does the trick
<airlied> hmm I wonder about how well radeonfb works with the new drm memory mapping..
<fabbione> apparently not very well.. :)
<airlied> I suspect the system is crashing in radeonfb rather than X.org on VT switch..
<fabbione> possibily... what do you want me to test?
<airlied> hmm can you boot without radeonfb and set usefbdev to off?
<fabbione> sure
<airlied> I've no idea if that is possible on ppc..
<fabbione> i can do all teh tests you want
<fabbione> no idea too
<fabbione> but we can try :)
<fabbione> no actually no.. radeonfb is built-in
<fabbione> but i can disable usefbdev and see
<airlied> yeah try that at least..
<fabbione> this one works too
<fabbione> but note this now:
<fabbione> drmOpenDevice: node name is /dev/dri/card0
<fabbione> drmOpenDevice: open result is 6, (OK)
<fabbione> drmOpenDevice: node name is /dev/dri/card0
<fabbione> drmOpenDevice: open result is 6, (OK)
<fabbione> drmOpenByBusid: Searching for BusID pci:0000:00:10.0
<fabbione> drmOpenDevice: node name is /dev/dri/card0
<fabbione> drmOpenDevice: open result is 6, (OK)
<fabbione> this time it find the devices?
<airlied> yeah you get some wierd results with drmOpenDevice..
<fabbione> it looks like a very interesting race condition
<airlied> no it is just got lots of backwardss comapt..
<fabbione> ah ok
<fabbione> well either disabling dri or radeonfb seems to work
<fabbione> so the two did stop to like eachother
<airlied> thats a bit of a problem, as benh is probably the only one that can fix radeonfb..
<fabbione> yes it is indeed a problem...
<fabbione> given that we have only less than a week to get this stuff sorted
<airlied> can you send me a log file with usefbdev off as well?
<fabbione> airlied: sure
<fabbione> in a second
<fabbione> Xorg.0.log.daltanius.nousefb
<fabbione> same url as above
<airlied> hmm it's hard to decide whether we need to fix radeonfb or the X.org driver using it..
<fabbione> airlied: or revert the drm change...
<fabbione> at this point in time there is no time to guess.. :/
<airlied> fabbione: the drm change fixes a few x86 issues :-)
<fabbione> and break my laptop... and i hate x86... 
<fabbione> ;)
<airlied> I'm thinking usefbdev isn't needed for radeon anyways :-)
<airlied> I think benh recommends against it now..
<mjg59> We could just drop that from dexconf
<mjg59> Or hack the driver so it's the default
<airlied> I need benh to take a look at this , he might know a quick fix..
<airlied> from what I can see the drm is just picking some wrong values..
<fabbione> i think last time we were talking about making it the default since everybody was turning it on anyway
<fabbione> iirc
<fabbione> but that doesn't change the situation as it is now
<airlied> in theory when you use the old mapping code, the drm operatse the same..
<airlied> bah the codepaths looks the same, but it is getting the fb size wrong on the new DRM for no good reason..
<airlied> I know how to punt the problem if that is anygood :-), we can CHIP_NEW_MEMMAP flag to the drm_pciids.h for all those RV350 chips..
<airlied> I think that'll stop DRM from getting enable if usefbdev is on..
<airlied> could change the message to say either a new X.org DDX or try not using UseFBDev.
<airlied> I might look into it more tomorrow evening, bed time now, g'night
<fabbione> airlied: do you have a patch you want me to test?
<fabbione> ok
<fabbione> good night :)
<airlied> fabbione: can you edit kernel sources easy?
<fabbione> airlied: generally ...
<fabbione> vim usually works fine :P
<airlied> in drm_pciids.h just add CHIP_NEW_MEMMAP to the line for your card, 0x1002, 0x4e50 I think..
<fabbione> ok
<airlied> that should stop DRM from working with fbdev I think..
<airlied> let me know if it works... l8r/
<fabbione> ok
<fabbione> my card is not there at all :)
<fabbione> oh never mind
<zul> hey
* fabbione pats zul on the head
<zul> hey fabbione how was the holiday?
<fabbione> zul: pretty good thanks
<zul> good to hear
<fabbione> BenC: the ubuntu-2.6.git on rookery is .17, right?
<BenC> right
<BenC> ubuntu-dapper.git is the one
<fabbione> yup
<fabbione> BenC: git pull http://people.ubuntu.com/~fabbione/archives/ubuntu-dapper.git
<fabbione> tested
<fabbione> it fixes the crashes for me
<fabbione> this is a must go in for dapper
<fabbione> let me talk to mdz too
<BenC> Put it in your tree and push please
<BenC> I'll pull and upload
<fabbione> already done
<fabbione> it's all there
<BenC> fabbione: pulling
<BenC> fabbione: thanks
<fabbione> thanks
<fabbione> no problem
<zul> BenC: im available later in the week for fatal beatings
<BenC> ok
<BenC> sry been missing ya, been way too busy
<zul> no problems i start the new job tomorrow its a holiday in ontario today
<fabbione> BenC: 
<fabbione> silo -f
<fabbione> /etc/silo.conf appears to be valid
<fabbione> Fatal error: File systems other than ext2, ext3, ufs and romfs not yet supported
<fabbione>  /dev/mapper/root on / type ext3 (rw,errors=remount-ro)
<BenC> what fs is it?
<fabbione>  /dev/md0 on /boot type ext3 (rw)
<fabbione> ext3
<fabbione>  /dev/md0              228M   14M  203M   7% /boot
<BenC> md0 for root is probably a bad idea
<BenC> s/root/boot/
<fabbione> it works fine on a 9GB disk
<Mithrandir> BenC: when you have the time: 10:55 < Mithrandir> BenC: any idea about https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 ? Doesn't the kernel actually lock the drive when mounting something off it?
<fabbione> it fails here on the 73G
<fabbione> BenC: but the partition is small and at the beginning of the disk
<BenC> Mithrandir: ok, checking it
<fabbione>    8     0   71687369 sda
<fabbione>    8     1       8032 sda1
<fabbione>    8     2     249007 sda2
<BenC> fabbione: but it's an md device...I've no idea how silo handles that
<fabbione> BenC: it works on the 9GB just fine
<BenC> as an md device?
<fabbione> it's raid1 device that silo claims to support
<fabbione> yeps
<BenC> not sure then
<fabbione> i take a 9Gb disk with 8M empty -> 128MB md -> /boot -> works
<fabbione> i am ready to bet that it fails because the partitioner did stop once in the middle of all that mess
<fabbione> i know at least one user that did install the same and did work
<BenC> mjg59: Is libata-acpi.c needed with 2.6.17-git?
<mjg59> BenC: Probably, but I doubt it'll apply right now
<BenC> doesn't
<BenC> is there a libata git I can pull from safely?
<BenC> the libata suspend/resume stuff in current git supercedes the stuff we had in dapper, right?
<fabbione> BenC: i think i found the silo bug
<mjg59> BenC: There's stuff we have that isn't in git
<mjg59> But I'll need to go over everything to figure out what
<fabbione>     if (lseek (fd, 1024, 0) != 1024 || read (fd, &sb, sizeof (sb)) != sizeof (sb))
<fabbione>         silo_fatal("Cannot read Super Block!");
<fabbione>     if (swab16 (sb.s_magic) == EXT2_SUPER_MAGIC) {
<fabbione>         if (fstype == unknownfs) fstype = ext2fs;
<fabbione>         return 1024 << swab32 (sb.s_log_block_size);
<fabbione>     }
<BenC> mjg59: For now I've reverted 2.6.17 to stock ata code
<fabbione> this looks like not properly alligned to the disk or something
<BenC> I've forward ported a couple of things like promise pata support
<mjg59> I think we ought to consider jumping to libata pata support
<mjg59> It'll be dodgy for a bit, but we'll actually get decent testing of it
<BenC> mjg59: Agreed, initrd can handle the change (with a long delay)
<BenC> mjg59: are there any IDE drivers that libata pata doesn't replace?
<mjg59> Don't think so, no
<mjg59> Possibly some ancient ISA stuff
<BenC> so we'll just need ide-generic?
<mjg59> Guess so
<mjg59> Not sure if that's been ported to libata
<BenC> Mithrandir: the only way around that is to send an ioctl for the cd device to lock it
<BenC> CDROM_LOCKDOOR maybe
<BenC> not sure if that overrides the software eject
<BenC> it makes it so you can't eject via the button on the drive
<rlaager> How is the source for linux-restricted-modules managed? I'm building a modified kernel and I need those modules as well.
<rlaager> BenC: Are you the guy to ask about linux-restricted-modules?
<BenC> rlaager: it aint easy
<BenC> in fact, it's so not easy, I can't really begin to tell you how to do it
<rlaager> BenC: I don't care about easy.
<rlaager> I'm building a kernel from the git tree....
<BenC> like I said, the package really isn't built with custom kernels in mind :)
<BenC> are you using a known target?
<BenC> and did it produce a linux-headers-x.x.x... package?
<rlaager> I'm not sure what you mean by "known target".
<BenC> -386, -686, etc.
<rlaager> -686 at the moment.
<BenC> then install all the linux-headers-2.6.15-23* packages
<BenC> install your custom linux-headers package, and rebuild l-r-m just like a normal debian package
<rlaager> rebuild l-r-m-2.6.15 ? I get the impression the git tree is 2.6.17, from debian/control.
<BenC> oh, you are using the latest git instead of ubuntu-dapper.git?
<BenC> then you are out of luck
<BenC> much of l-r-m doesn't build against it, as I've already found out
<rlaager> BenC: Yes. Ouch. Hmm.
<rlaager> Well, in the short term, I just need nvidia and ipw3945.
<BenC> what modules do you need?
<BenC> ipw3945 is in the kernel
<rlaager> but there's a regulatory daemon, though, isn't there?
<BenC> you can just link ipw3945d-2.6.17-1 to ipw3945d-2.6.15-23
<BenC> same daemon
<BenC> should be in /sbin/
<rlaager> k, that'll do for now
<BenC> nvidia, you can just download their tarball and install
<rlaager> Alright. Any idea on how long it'll take for that stuff to be working again? Anything specific that I could do to help?
<rlaager> Or perhaps I should ask about my end goal... I'm trying to build a -xen0 kernel package with the eventual goal of coming up with something acceptable for inclusion in Ubuntu.
<zul> BenC: should i email mdy for the xen stuff?
<jbailey> zul: For the conference?  Yeah.
<zul> jbailey: okie dokie
<zul> jbailey: done
<zyga> hello
<jbailey> =)
* zyga will ask once and then make a bug at launchpad
<zyga> I've got pictures of a kernel panic if anyone is interested
<zyga> on k7 about 3 days ago
<zul> heh...star trek 1 is on
<Keybuk> zul: billshatnertastic
<zul> Keybuk: exactly..
<Keybuk> it suddenly occurs that a duet between Bill Shatner and Tom Jones would be sublime
<zul> he was ok in over the hedge
<zul> mr tamborine man was awesome..
<Keybuk> common people was fantastic
<zul> heh..
<jbailey> And all that made me think of was William Shatner singing "Major Tom"
<bluefoxicy> hmm.
<bluefoxicy> pitti is busy, I wanted to ask him his thoughts on Edgy.
<bluefoxicy> But right now he's very busy with dapper and in discussion.  :)
<Keybuk> Edgy is a banned topic on #ubuntu-devel until June 2
<bluefoxicy> mmm.
<bluefoxicy> Like I said, he's massively busy anyway
<zul>  ooh...muppet show is on
<jbailey> Anyone have an amd64 box handy?
<zul> not me
<cjb> jbailey: Yes.
<jbailey> cjb: Mind doing a test for me?
<jbailey> #include <stdio.h>
<jbailey> #include <unistd.h>
<jbailey> #include <errno.h>
<jbailey> int
<jbailey> main ()
<jbailey> {
<jbailey>         nice(-2);
<jbailey>         printf("%d", errno);
<jbailey>         perror(0);
<jbailey>         return 0;
<jbailey> }
<jbailey> cjb: Please compile that and run it as a regular user, tell me what you get.
<cjb> havoc:cjb~ % ./a.out
<cjb> 13
<cjb> Permission denied
<cjb> 
<jbailey> cjb: Great.  Give me uname -a ?
<cjb> (32-bit userland, 2.6.15-22-k7.(
<cjb> Linux havoc 2.6.15-22-k7 #1 SMP PREEMPT Sun May 7 17:27:47 UTC 2006 i686 GNU/Linux
<jbailey> Ah, I need to test this on the amd64 kernel.
<cjb> Hm?  Which?
<jbailey> That test.
<cjb> I mean, which kernel.  :)
<jbailey> jbailey@auzura:~$ uname -a
<jbailey> Linux auzura 2.6.15-22-amd64-k8 #1 SMP PREEMPT Sun May 7 16:15:46 UTC 2006 x86_64 GNU/Linux
<jbailey> Would be nice.
<jbailey> Or -23, I guess is out now.
<jbailey> I haven't updated that machine yet,
<cjb> 'kay, can upgrade to that.
<jbailey> Cool, thanks!
<cjb> No, I can't.  :)  I don't see -amd64- kernels available.
<cjb> Maybe they require 64bit userland?
<cjb> Yeah, I suppose they're only in the amd64 distro, and I'm using i686.  Looks like I can't help; sorry.
<jbailey> Ah, dunno.
<jbailey> Thanks, though
<cjb> Welcome.  At least you have a simple test case, should be able to find someone in one of the other channels.
<Mithrandir> BenC: ok, I thought the kernel did that already.
<BenC> Mithrandir: It locks the device from unmounting, but that doesn't stop the physical eject with an ioctl, which overrides anything
<Mithrandir> BenC: 'k, I guess casper should lock the drive, then
<zul> why the hell am im watching opra?
<BenC> because you have no life? :)
<zul> that must be it
<zul> its mesmerizing though
<fabbione> BenC: <airlied> fabbione: set if for all rv350 to be safe.. <---
<fabbione> BenC: the patch i gave to you yesterday
<pips1> hi
<pips1> are there any known problems with G5? (yesterday's daily build)
<pips1> and if so, what are the symtombs?
<pips1> symtoms
<pips1> ?
<beanz> Where can I find pre-released versions of the ubuntu kernel?
<mjg59> https://wiki.ubuntu.com/KernelGitGuide
<beanz> Is there not a holding area for the debs before they enter main or updates?
<mjg59> No
<beanz> damn
<beanz> okay
<mjg59> The source gets uploaded, autobuilt and goes into the archive
<beanz> I see. and the _0 in linux-kernel-di-i386-2.6_0.64ubuntu2.dsc  - does it mean current?
<fabbione> i am afraid you are not looking in the right place
<beanz> ah. you're right. thanks.
<crimsun> BenC: any kernel upload planned prior to final? There are enough HDA ALC* bug reports that I think http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=aca7d794a097b9aa64ff7e2d8536586a494c8313;style=gitweb would be worth merging
<BenC> not before release
<crimsun> ok, thanks.
<BenC> mdz is already reaming me for the last one :)
<crimsun> heh :)
<BenC> I can squish it in with the first security upload though
<crimsun> that would be fabulous
<zul> heylo
<Keybuk> olyeh
<zul> hey Keybuk how is it going?
<Keybuk> I'm trying to persuade one of my teeth to come loose
<zul> thats nice
<Keybuk> and Openoffice only builds if run under strace
<Mithrandir> Keybuk: you're not supposed to lose teeth at such an early age, are you?
<zul> hehe
<Keybuk> Mithrandir: it's the one I broke in Kristiansand, if you remember
<Mithrandir> I don't, but ok. Then it makes sense, or something
<Keybuk> the shoddy repair job came loose over the weekend and fell out today
<Keybuk> I should probably just go to the dentist
<Mithrandir> can't be that shoddy if it held up for two years.
<Keybuk> true
<zul> time for din din
* desrt hugs BenC 
<desrt> BenC; thanks a bunch :)
<BenC> heh, you owe me a beer :)
<BenC> infinity: ping
<cjb> Can anyone get in touch with any Ubuntu Summer of Code admins?  They're desperately needed to resolve a duplicate with a student being accepted to Ubuntu as well as another org.
<BenC> try -devel?
<cjb> Don't think we've had any luck there, will try again.
<foogle> I got a Kernel panic my install cd wont work anymore  I think it has some thing to do with segmentation
<crimsun> foogle: do you have a recent dapper live cd ?
<foogle> Is dapper 5.10?
<crimsun> no, that's breezy.
<crimsun> you probably want to migrate this question back to #ubuntu
<foogle> oh ok 
<infinity> BenC: pon?
<infinity> g
<RandolphCarter> is there any chance of reverting the changes made to the sky2 module in 2.6.15-23? (afaik they weren't bugfixes, and they've broken networking here)
<zul> heylo
<BenC> infinity: Trying to get lrm building with 2.6.17
<BenC> infinity: It fails in the ati module build, for some reason it's trying to symlink Makefile.lib.c to scripts/Makefile.lib.c and build Makefile.lib.o in the linux-headers directory...any idea why?
<BenC> lamont: in regards to the ia64 acpi crash on boot, my i2k started showing it, so it's a problem that just started showing up
<BenC> lamont: good news is, the 2.6.17 kernel boots fine
<zul> BenC: do you want to do some training on thursday night?
<BenC> RandolphCarter: actually they were bug fixes
<BenC> zul: tomorrow night sounds good
<zul> cool...because lost is on tonight
<RandolphCarter> BenC: ah :/ I've filed a bug (#46326), but they've broken net here, and they were introduced the day the kernel was frozen :/ (doh?)
<BenC> RandolphCarter: We had some 10-15 bug reports on sky2 prior to that update...it fixed some of those
<BenC> most are still broken
<RandolphCarter> ah :/ I'm about to try amd64, failing that, can you point me to any archives that still have the -22 rev?
<RandolphCarter> and there it goes :( sorry, if you answered that, could you send it again?
<infinity> BenC: No idea, TBH... I don't have the time to look at it.
<infinity> BenC: But you're adopting it anyway, right? :)
<BenC> yeah, I'm getting it ready for edgy...just wondering if you had seen this failure before :)
<BenC> so far I have 2.6.17 building on all 6 arch's, and booting on ia64, amd64, ppc and i386
<infinity> Sweet.
<infinity> So, we'll have the first 2.6.17 upload on June 2?
<infinity> Oh, while you're doing LRM prep, "rm -rf madwifi madwifi-ng && svn co <latest madwifi-ng HEAD> madwifi"
<infinity> I can do that on June 2, though. :)
<BenC> yeah, it'll be uploaded the day edgyi is opened hopefully
<BenC> mjg59: Is something supposed to replace wlan-ng?
<BenC> the prism stuff isn't compiling well with 2.6.17 :/
<mjg59> No idea
<mjg59> It shouldn't be too hard to fix up
<BenC> it's actually pretty horrible
<BenC> for some reason it has a lot of depency loops for include/prims2/*.h headers...not hard but tedious
<BenC> not sure why it's showing up now :/
<BenC> *depndency
<desrt> BenC; agreed.
<BenC> doesn't hostap take care of most of prism2?
<mjg59> Not USB
<BenC> prims2_pci only had one id that hostap_pci didn't handle
<BenC> copied that
<BenC> prims2_cs had all the id's commented out, so seems like it was never any use in dapper
<BenC> same for plx
<BenC> I'll see if I can just enable usb
<lamont> BenC: I tracked down which change (pair) caused it, back in the -15 to -16 transition (on zx2000).  Or are you saying that the i2k is still failing even with ACPI_DEBUG turned on?
<BenC> lamont: was failing for me
<fabbione> lamont: ACPI_DEBUG is good for me
<BenC> irq 39: nobody cared (try booting with the "irqpoll" option)
<BenC> I still get that on ia64
<BenC> wait, I haven't tested if 2.6.15 boots on it now that ACPI_DEBUG is enabled
<lamont> BenC: starting with -16 it quit booting unless ACPI_DEBUG is on to mask whatever the real problem is
<BenC> ah
<BenC> lamont: do you know why hppa would give me a bad reloc entry when it tries to load a kernel module with 2.6.17?
<BenC> I reverted all of parisc to stock code
<fabbione> BenC: it's probably the 17bit jmp limit?
<BenC> it fails to load jbd.ko, which as you can imagine makes things pretty hard to boot
<fabbione> that would be a toolchain issue
<BenC> didn't have it on 2.6.15
<BenC> odd that it would show up now
<fabbione> is jbd.ko in .17 bigger?
<fabbione> or is it of the same size?
<lamont> BenC: there's a, um, feature in ld -r
<lamont> it creates unlinkable .o files under some circumstances
<BenC> crappy...I've built it 4 times and it's always the same thing in jbd.ko :(
<BenC> I need to get the exact failure for you
<lamont> if it has the number 17 in the reloc name, that's the bug
<BenC> rebooting now...
<BenC> Module jbd, symbol journal_destroy_caches is out of range for PCREL22F relocation
<fabbione> yeps
<BenC> journal_destroy_caches is a static function
<fabbione> BenC: it's the 17bit issue
<BenC> how can I workaround it?
<fabbione> fixing the toolchain
<BenC> I want all my machines booting 2.6.17 by the end of the week :)
<fabbione> kile has been working on it for a while without success
<zul> heylo
<zul> BenC__: around?
<BenC> yeah
<BenC> got your email, 8pm sounds good
<zul> goodie..i would have been available last night but you know lost was on..
<zul> priorities ;)
<BenC> hehe
<zul> meh..
<Keybuk> BenC: ping
<BenC> Keybuk: pong
<Keybuk> BenC: so sendfile64 appears busted
<Keybuk> on AMD64, doing sendfile() with >2GB returns -EINVAL
<BenC> hmm
<Keybuk> fwict. sendfile() on AMD64 == sys_sendfile64
<infinity> It's been busted for ages on 2.6 kernels, from what I can tell.
<infinity> Last time I tested all this was on 2.4
<infinity> Silly me.
<Keybuk> it's not unique to our kernel either, Debian are busted too
<infinity> No, it's upstream.  I found some stuff about it from Linus in the 2.5.x days.
<infinity> it was intentionally broken, but was also meant to be reimplemented and fixed.
<infinity> I guess the latter part never happened.
<BenC> wonder why it's broken on say amd64 and not things like ppc64 and sparc64
<BenC> duh, they are 32bit userspace
<infinity> Ed zachary.
<BenC> still, you would think on 64-bit userspace, sys_sendfile() itself would support > 2G files
<infinity> Well, that's not fair, actually.  sendfile64() seems to be universally broken on at least all 64-bit kernels.
<infinity> It's not the userspace that matters, afaict from my reading.
<infinity> Anyhow, trivial to workaround in the one application where we seem to care.  Just wish this had been noticed a few months ago.
<infinity> BenC: Why did my burner decide to statr flaking out with the latest kernel? :)
<infinity> sr 1:0:0:0: Device not ready
<infinity> (over and over again)
<BenC> infinity: murphy :/
<infinity> I'll blame him until further evidence makes it your fault. >)
<jcole> if someone has time, kernel build help please -> http://pastebin.com/737508
<jcole> i don't need the udebs either
<jcole> is there a way to disable them?
<jcole> i want to bump the ABI version, so the users i'm providing these kernels too, don't accidentally get upgraded to a stock dapper kernel
* jcole reads https://wiki.ubuntu.com/KernelGitGuide to see if it could help
<jcole> :/ nothing useful for me
<jcole> got it
<jcole> i think i need to change these files -> ./debian/config/amd64/config,./debian/config/hppa/config,./debian/config/i386/config,./debian/config/ia64/config,./debian/config/powerpc/config,./debian/config/sparc/config
<crimsun> see the abi hints in debian/rules
<zul> BenC: we still ok for tonight?
<zul> bbl,,
<jcole> crimsun: i don't understand
<jcole> crimsun: i'm in debian/rules right now
<jcole> crimsun: i want to recompile using a certain .config 
<jcole> crimsun: isn't there a maintainers guide/readme/doc/howto for this?
<crimsun> jcole: not that I know of. BenC could give you the rundown for bumping the ABI.
<jcole> crimsun: i've got the ABI bumped, need to add REGPARM=y to all kernel configs
<jcole> crimsun: how does one enable one kernel option?
<jcole> crimsun: i have to recompile and provide all kernels with this one flag enabled
<jcole> crimsun: i've compile twice and it keeps generating .config files with REGPARM disabled
<jcole> crimsun: i tried to add a .config file to the source dir, tried to edit debian/config/i386/config, and tried to edit arch/i386/Kconfig... nothing is working
<crimsun> what did you edit in debian/config/i386/config?
<crimsun> "CONFIG_REGPARM=y" ?
<jcole> crimsun:  CONFIG_REGPARM
<jcole> yes
<jcole> do i need to run a "special command" or something?
<jcole> lol
<crimsun> jcole: no idea, ping Ben for that
<jcole> maybe a --compile-with-my-damn-config option
<jcole> it takes hours and hours to compile all these... this really sucks
<jcole> holy mother of gawd
<jcole> it's working now
<jcole> $ grep REGP ./debian/build/build-386/.config
<jcole> CONFIG_REGPARM=y
<jcole> *sigh* FINALLY
<jcole> :)
<jcole> if people really want these kernels, i'm going to make each and everyone install distcc
<lifeless> clearly you should embed distcc in the kernel
<jcole> lifeless: good point
<zul> heylo
<zul> BenC: hey
<BenC> hey, might have to delay this a bit more
<BenC> tracking down this damn squashfs bug
<zul> ok no problem
<zul> tomorrow same bat channel same bat place?
<zul> oh yay...charlie's angel's is on
<zul> having fun yet BenC 
<BenC> not really
<BenC> yeah, tomorrow night should be good
<zul> heh ok
<zul> that was weird my swap was not acitviated
<crimsun> failed resume from hibernation in the past?
<zul> nah...it just wasnt formatted or activated
<zul> heylo
<zul> BenC: i should be home around 8:30 tonight
<pips1> Hi, booting dapper rc hangs on a new imac (G5), I tried live cd's of both kubuntu and edubuntu flavors. Have other users reported problems with G5 processors?
<fabbione> pips1: afaik the new imac g5 support has been added to the kernel only recently
<fabbione> i think it requires at least .16 if not .17
<pips1> ic
<fabbione> and the backport is not possible.
<fabbione> the code has been ported to .16 for a distro and it resulted in a very unstable environment
<fabbione> pips1: anyway edgy will open very soon with .17
<pips1> right
<fabbione> question of 2/3 weeks max
<pips1> :)
<pips1> fabbione, thanks for info
<fabbione> no problem
<archis_> Hi - I get fs-related error messages when mounting ext3 partitions via USB in dapper.
<archis_> See http://paste.ubuntu-nl.org/14672
<archis_> syslog: http://paste.ubuntu-nl.org/14673
<fabbione> archis_: did you actually umount them before fsck?
<fabbione> May 26 15:38:44 localhost kernel: [4303502.447000]  kjournald starting.  Commit interval 5 seconds
<fabbione> May 26 15:38:44 localhost kernel: [4303502.447000]  EXT3 FS on sda2, internal journal
<fabbione> May 26 15:38:44 localhost kernel: [4303502.447000]  EXT3-fs: mounted filesystem with ordered data mode.
<fabbione> May 26 15:38:44 localhost kernel: [4303502.463000]  kjournald starting.  Commit interval 5 seconds
<fabbione> May 26 15:38:44 localhost kernel: [4303502.463000]  EXT3 FS on sda5, internal journal
<fabbione> May 26 15:38:44 localhost kernel: [4303502.463000]  EXT3-fs: mounted filesystem with ordered data mode.
<fabbione> this clearly shows that the devices have been mounted properly
<archis_> fabbione, yes they mount fine but fsck.ext3 complains during boot and drops me into a shell
<fabbione> can you show me fstab?
<archis_> just a s ec
<fabbione> sure
<archis_> fabbione, http://paste.ubuntu-nl.org/14674
<fabbione> Keybuk: ^^^this is udev/mount race condition i am afraid
<fabbione> archis_: thanks.
<Keybuk> USB drive not mounted by fstab?
<fabbione> yup
<archis_> fabbione, welcome
<fabbione> and it's not even root
<Keybuk> Known, solution "DON'T DO THAT THEN"
<fabbione> it's just a media
<Keybuk> the edgy solution is to get rid of checkfs/checkroot/mountall entirely, and do all fsck and mount calls from udev rules
<archis_> fabbione, Keybuk ..any suggestions?
<fabbione> that's going to fail with SAN systems and multipath with hotstandby disks
<Keybuk> fabbione: no, it only fails on USB drives that I know of
<Keybuk> because they take so damned long to initialise
<fabbione> Keybuk: nope.. it will fail also on SAN with multipath
<fabbione> i can explain you why
<fabbione> Keybuk:  i assume you are familiar with internet routing?
<Keybuk> fabbione: I used to work for an ISP
<fabbione> to be able to read a traceroute at least
<fabbione> ok
<fabbione> well just to make sure :)
<fabbione> imagine host A and B
<fabbione> routers C D E F
<fabbione> A is connected to C and D
<Keybuk> archis_: echo 'SUBSYSTEM=="block", ACTION=="add", NAME=="sd[a-z] [0-9] *", RUN+="mount %k"' >> /etc/udev/rules.d/88-mount.rules
<fabbione> C is connected to E and F
<fabbione> D is connected to E F
<fabbione> E and F are connected to B
<Keybuk> archis_: though that won't give you fsck ... which might be a problem
<fabbione> so you have N paths to get there
<archis_> Keybuk, thanks :-)
<fabbione> now.. in a SAN system...
<fabbione> A is the host
<fabbione> C and D two FC-HBA controllers
<fabbione> E and F 2 SAN controllers
<fabbione> B the disk
<fabbione> A will see B as sda sdb sdc sdd
<fabbione> if you try to fsck them in parallel you will doom the FS on the disk
<fabbione> alsp
<fabbione> usually 2 paths are active
<fabbione> and that's ok acces
<archis_> I can boot into USB from second grub located on the USB itself for occasional filechecking, no?
<fabbione> access
<fabbione> 2 of them are kept hot-stsandby
<fabbione> that means if you try to access them you will get errors
<fabbione> like real scsi errors
<Keybuk> fabbione: I think you've wandered from the point ?
<fabbione> if you do the fsck the way you describe it, it will fail the boot and possibly corrupt the FS if it starts in parallel
<Keybuk> or I'm not following
<Keybuk> fabbione: the SAN doesn't support parallel fsck?
<fabbione> the SAN has nothing to do with the FS you run on top :)
<Keybuk> ie. simultaneous fsck of different exposed DRIVES ?
<Keybuk> sda == a device
<fabbione> SAN exports a block device
<fabbione> not a FS
<Keybuk> this is all besides the point
<fabbione> or N block devices.. but one is enough for our example
<Keybuk> let's get back to the "will a SAN mount today" issue
<fabbione> i am not talking about mounting..
<Keybuk> does the SAN driver return from _init before it has discovered and created the block devices in the kernel?
<fabbione> <Keybuk> the edgy solution is to get rid of checkfs/checkroot/mountall entirely, and do all fsck and mount calls from udev rules
<Keybuk> what are you talking about then?
<fabbione> ^^ i am talking about this for edgy
<Keybuk> right, I don't see why that is bad
<fabbione> it works in dapper now.. so that's no problem
<Keybuk> if you can't fsck the block device, then it won't work today
<fabbione> because you can start 2 fsck on the same disk at the same time?
<Keybuk> then it won't work today
<fabbione> on a SAN you rarely use the sdX devices
<fabbione> you slam a multipath tools on top that abstract the sdX to a single device that you mount
<Keybuk> in edgy we'll be able to explicitly exclude SAN devices that won't let you do that
<Keybuk> so I don't see the problem
<fabbione> well you didn't say that before and i got worried :)
<Keybuk> if you don't use /dev/sdX then it won't be in /etc/fstab, no? :)
<fabbione> also remember that usually SAN devices are recognized by uuid
<fabbione> true that too
<Keybuk> udev will only be calling fsck + mount for something in /etc/fstab
<Keybuk> ie. replacing mountall
<fabbione> assuming that your box is fully redundant
<fabbione> there are still corner cases where we want to offer the blacklist
<Keybuk> yeah, we can blacklist with udev -- is easy
<fabbione> perfect
* fabbione doesn't bother anymore
<Keybuk> anyway, archis_'s problem is a known one
<Keybuk> it's not "solvable" today
<archis_> Keybuk, I had no problem with fsck checking sda on breezy - why do I have it now?
<Keybuk> archis_: you actually did ... breezy just took longer to boot
<Keybuk> oh, wait
<Keybuk> no, that's right
<Keybuk> breezy took longer to get from S04udev to S30checkfs.sh
<Keybuk> (though how /dev/sdaX got created without the modules being loaded by hotplug I have no idea :p)
<Keybuk> did you put anything in /etc/modules ?
<archis_> nope
<archis_> no udev rules either
<Keybuk> magic :p
<archis_> I have an ancient syslog somewhere that I can paste if you're interested
<Keybuk> syslog doesn't help
<Keybuk> all this happens wayyy before that daemon is started ;)
* dilinger chuckles
<dilinger> i go to packages.ubuntu.com/nagios, and get prompted for a username/passwd
<fabbione> dilinger: we hate you :P
<dilinger> guess i'll have to backport nagios2 to dapper
<BenC> infinity: ping
<zul> BenC: i should be home around 8:30 tonight we can do it then if you want
<doko> BenC: is there an easy way to turn of hyperthreading/smp in the kernels?
<BenC> doko: # CONFIG_SMP is not set
<BenC> in the debian/config/$arch/config.$flavour of your choice
<doko> well, but hyperthreading is turned on
<doko> BenC: no boot option to turn these off?
<fabbione> doko: ht=on
<fabbione> off=
<fabbione> ht is disabled by default iirc
<fabbione> because of the hw bug
<fabbione> SMP ... hmmm 
<fabbione> somehting like smppersonality=off
<fabbione> or smp=off
<BenC> nosmp on the command line
<doko> fabbione, BenC: ht is on by default, so ht=off should work ...
<BenC> yeah, ht=off nosmp
<BenC> that should do it
<fabbione> ok
<fabbione> i am ogg
<fabbione> off
<fabbione> good night
<BenC> good night fabio
<zul> im heading home as well ill talk to you later BenC 
<BenC> later zul
<doko> BenC, Mithrandir: booting using ht=off, the boot hangs mounting the root file system: IOAPIC[0] : Invalid reference to IRQ 0
<BenC> what is this on?
<doko> P4 with hyperthreading
<BenC> some systems have to have SMP/ioapci enabled, and wont work otherwise
<BenC> ioapic
<doko> ok, removing nosmp lets the boot succeed
<doko> fabbione, BenC: ht=off doesn't work
<BenC> I really thought ht was off by default because of a security errata
<doko> no, /proc/cpuinfo still shows two CPUs
<jcol1> doko: that doesn't work for me neither
<BenC>                 else if (!memcmp(from, "ht=on", 5))
<BenC>                         disable_ht = 0;
<BenC>                 else if (!memcmp(from, "ht=off", 6))
<BenC>                         disable_ht = 1;
<BenC> should work
<BenC> anything in dmesg about ht?
<doko> ok, it's disabled, but it still finds two CPU's. strange ...
<doko> BenC: ^^^
<BenC> I think it always scans all of them when in that mode
<BenC> it just may only use the one
<doko> $ getconf _NPROCESSORS_ONLN
<doko> 1
<BenC> sweet
<zul> heylo
<zul> BenC: yo
<BenC> zul: Hey, give me a couple of minutes
<zul> sure
<zul> firg...my eye hurts..
<BenC> zul: email address?
<zul> zulcss@gmail.com
<zul> *sigh* you dont know it yet? :)
<BenC> I'm as bad with email addresses as I am with names
<BenC> that's why I like IRC, you see the persons name whenever they speak :)
<zul> im worse with names, better with email addresses
<infinity> BenC: Pong?
<davyd> is there much time for bug fixing before the Dapper release?
<davyd> 42258 would be very, very handy
<davyd> (oops, wrong button)
<fabbione> davyd: no time at all
<davyd> fabbione: that's a damned shame, because this bug is going to break every single one of our desktops at work
<crimsun> (I'm not sure if infinity asked about newer Nvidia drivers)
<davyd> and shoots my attempt at an Ubuntu migration (from Fedora)
<fabbione> davyd: it is already proposed as update
<fabbione> it might happen shortly after release
<davyd> ok
<davyd> I've got my kernel packages here on hold
<davyd> it doesn't seem to affect you until you start twinview, so I suppose I'll just have to run updates first
<davyd> once it lands
<infinity> davyd: I'm pushing to get it fixed before release, so the new drivers ar on the CD, but if not, it'll happen shortly after release.
<davyd> ok
<davyd> that's excellent news
<archis_> I see fabbione is not around...
<archis_> Just to follow up on Keybuk's udev rule for the udev/mount race condition on my system
<archis_> It sort of confuses things - screenshot: http://paste.ubuntu-nl.org/14722
<archis_> (fstab here) http://paste.ubuntu-nl.org/14674
<archis_> and I'm still being dropped into a shell at boot like so.. http://paste.ubuntu-nl.org/14672
<zul> heyl0
<zul> BenC: er ping
#ubuntu-kernel 2006-05-28
<davyd> hi all
<davyd> I was wondering about building a new linux-restricted-modules with updated nvidia drivers
<davyd> I'm not entirely sure how this package ties in with the older nvidia-kernel package
<cjb> How lrm does, or how nvidia-glx does?
<davyd> in the old days, I know I could get nvidia-kernel-source, replace what I wanted to and run make-kpkg over it, and I would get useful packages
<davyd> but nowadays, l-r-m provides nvidia-kernel
<crimsun> l-r-m is preferred. nvidia-kernel-source is separate source in multiverse.
<davyd> so, if I didn't want to break my tree, knowing this is eventually going to be fixed in Ubuntu
<davyd> I would want to build a new l-r-m
<davyd> ?
<crimsun> I should clarify that to read, build a new l-r-m-2.6.15, since it provides binaries for l-r-m-$(uname -r) and nvidia-kernel-source alike
<davyd> will it throw out nvidia-glx as well?
<crimsun> yes
<crimsun> (apt-cache showsrc nvidia-glx)
<davyd> aah yes, now I remember why I thought this was wrong, it's a 100M source package
<davyd> ok, I'll come back to this once I've done some chores
<davyd> it should be down by then
<infinity> davyd: I'm building a new LRM now, if you can wait and test my packages.
<davyd> infinity ; I can test it
<infinity> davyd: Spiffy.  I'll push packages in a bit.  Just have to finish some OO.o mangling first.
<[g2] > mjg59 do you have sound working on the Intel macmini ?
<mjg59> Not with the built-in speaker, no
<[g2] > mjg59 with the audio out ?
<mjg59> Try the audio in
<[g2] > well I"m looking to build/boot a custom kernel
<[g2] > the 2nd processor is item number one
<[g2] > sound could be item number 2
<mjg59> You don't need a custom kernel for the first, and there is currently no working kernel for sound
<[g2] > mjg59 how do I enable SMP for i386 ?
<[g2] > with the latest dapper
<mjg59> apt-get install linux-image-686
<[g2] > mjg59 is there a place for status on the different devices like the Atheros wifi, BT, ACPI etc.. or is here (meaning you) :)
<mjg59> Everything should work with the exception of ACPI
<[g2] > I'll double check the linux-image-686 but I'm running a remastered livecd
<[g2] > I think that kernel is in a different spot
<[g2] > Ok so everything, but sound and ACPI should work with the 686 kernel ?
<mjg59> Yes
<[g2-build] > mjg59: Ok so just copy over the vmlinuz and initrd to the /install dir on the livecd to run that 686 kernel ?
<[g2-build] > the vmlinuz and initrd from /boot
<mjg59> And the modules
<mjg59> But I really don't know
<[g2-build] > Ok
<[g2-build] > mjg59: thx
<[g2-build] > mjg59: is anyone working on the ACPI stuff ?
<crimsun> [g2-build] : there are sound fixes for the macmini upstream in hg alsa-kernel
<crimsun> [g2-build] : http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=14772d35b9a64e07d703c9eaac0d34fca76d87eb;style=gitweb
<mjg59> crimsun: Ah. Including speaker support?
<crimsun> mjg59: no idea, I don't have hardware to test :-)
<mjg59> Ok, checking the patch, it seems not (a friend has been playing with that code)
<[g2-build] > crimsun: THX. 
<kimo> Hi, can someone please tell me which function gets called, that is actualy responsible for flipping off my laptop's power switch, when I am turning off my laptop?
<kimo> I'm asking coz my toshiba laptop still wont power off, & it seems it's not gonna get fixed for the dapper release
<kimo> thought I'd compare the source code, with Suse's, which works great (not that I'm close to being a kernel developper) :)
<[g2-build] > kimo: shutdown
<[g2-build] > kimo: j/k... 
<[g2-build] > I'd guess that either APM or APCI functions handle it
<[g2-build] > ACPI
<[g2-build] > bbl
<kimo> oh well, in which file ??
<infinity> pm_power_off, which will either be acpi_power_off from drivers/acpi/sleep/poweroff.c or apm_power_off from arch/i386/kernel/apm.c, depending on whether you use APM or ACPI by default.
<kimo> thnx .. seems the core is acpi_enter_sleep_state
<infinity> davyd: Still around, dude?
#ubuntu-kernel 2007-05-21
<mjg59> BenC: The dyntick options only seem to be set in -generic, not -386?
<BenC> mjg59: -386 has always been considered a fallback kernel when we have new options like that
<mjg59> Ok
<theCore> BenC: just a quick question, is there a reason why you use 4 different git trees (one for each dist), instead of branches?
* Starting logfile irclogs/ubuntu-kernel.log
<Keybuk> http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commit;h=d9aca22cf443f5ed77d15a320abbab055ae4a976
<Keybuk> ^ That's in git head now ... will that make it to a kernel upload soon? :p
* Starting logfile irclogs/ubuntu-kernel.log
#ubuntu-kernel 2007-05-22
<akio> hello
<Keybuk> BenC: ping?
<BenC> Keybuk: pong
<fabbione> hey BenC 
<BenC> hey
<Keybuk> BenC: what would be the estimated timeline for getting http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9aca22cf443f5ed77d15a320abbab055ae4a976 into our kernels?
<fabbione> BenC: i will pretty soon need 2 things from you.... pull from gfs2-nmw tree and export the 3 symbols i need for gfs1.
<fabbione> BenC: but i will give you a ping when it's time. I need 2 more fixes to hit gfs2-nmw
<BenC> fabbione: why isn't gfs2-nmw in 2.6.22?
<BenC> I really wanted to avoid pulling in other trees, especially when there's time to push things upstream still
<fabbione> BenC: not all of it yet. but i need it before otherwise new userland doesn't build/work
<BenC> Keybuk: Should be next upload, hopefully on or before Friday
<fabbione> BenC: i understand, but there is a change on dlm headers and gfs2 headers that i need to propagated to build the new userland.. otherwise i am blocked.
<fabbione> BenC: i still want these 2 extra fixes in before you pull
<BenC> Keybuk: We need to talk about bug #115616
<fabbione> BenC: also.. i saw kernel.u.c
<BenC> fabbione: any assurance that those changes will be pushed upstream for 2.6.22 or are we stuck with the divergence in gutsy?
<BenC> fabbione: you might have an account on kernel.u.c, try ssh to zinc.u.c
<fabbione> BenC: they will be pushed upstream for sure.. when it's something i can't say right now, but i can ask
<BenC> you can clone, and put whatever changes you want to push to me there
<fabbione> BenC: i already have an account there
<fabbione> how do i setup a tree that shows up in gitweb?
<BenC> fabbione: are you in kernel_team group?
<fabbione> i was planning to put gfs2/ocfs2 and gfs1 team
<fabbione> i guess so... checking
<BenC> if so, mkdir /srv/kernel.ubuntu.com/git/fabbione/
<BenC> then clone a tree, mv newtree/.git /srv/kernel.ubuntu.com/git/fabbione/fabbione-gutsy.git
<fabbione> yes i am
<Keybuk> BenC: ok :)
<BenC> fabbione: you might want to look at 115616 too, since it involves evms, and I could use some feedback
<fabbione> BenC: i saw that bug. i will need to look at whatchanges
<BenC> The basic issue is described here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/115616/comments/3
<fabbione> BenC: not sure i can get there by today
<BenC> Mainly that I want to ditch the horrible bd_claim patch, but we need a way for users not to have broken systems that were based on the work around
<Keybuk> BenC: ah, ok, it was a patch we dropped?
<BenC> Keybuk: yeah, we've been carrying it around for a few releases, and it really is evil, and in actuality creates more room for breakage than it fixes
<Keybuk> agree
<Keybuk> the evms FAQ doesn't offer a better solution though
<BenC> Actually, it does, which is to convert to evms totally, or ignore devices that evms isn't using
<Mithrandir> fixing it is easy.  Move partition discovery out of the kernel and just use devmapper devices.
<Mithrandir> fsvo easy, that is.
<Keybuk> Mithrandir: actually, that doesn't help, since evms would still fight over the devmapper devices
<Keybuk> claim applies to the devmapper ones too
<BenC> it still tries to lock the physical block dev, which is the problem
<fabbione> BenC: ok.. i have the tree cloned as you say... now?
<Keybuk> evms for all => well, if you're using evms, you're doomed anyway
<BenC> fabbione: "mv newtree/.git /srv/kernel.ubuntu.com/git/fabbione/fabbione-gutsy.git"
<Keybuk> we actually have udev set to prefer to *not* use the evms-supplied devices right now
<fabbione> BenC: done that
* Mithrandir will not be very happy if somebody decides to break all his systems.
<Keybuk> evms to exclude => it doesn't seem easy to do that either, since we don't know what to exclude or not?
<BenC> fabbione: the main gitweb page is hourly generated...let me run the script
<fabbione> BenC: ok
<BenC> fabbione: shows up now
<fabbione> oh neay
<fabbione> neat
<Mithrandir> Keybuk: make it not lock the whole device unless it contains an evms volume, and if so, see if it can just claim a partition?
<fabbione> how do i setup the repo description?
<BenC> fabbione: vi ubuntu-gutsy-gfs2.git/description
<Keybuk> Mithrandir: do you know how to do that?
<Mithrandir> Keybuk: a) get drunk, b) dive into the evms source code.
<Mithrandir> it's a big and scary chunk of code.
<Mithrandir> talking to upstream might be a good start, though
<Keybuk> given that upstream haven't felt inclined to fix it yet, I doubt they'll be responsive
<BenC> yeah, their FAQ is sort of "eh, deal with it"
<Mithrandir> depends.. I've found them very good in the past when I've managed to catch their attention.
<fabbione> BenC: ok.. all done.. can you regenerate the page?
<fabbione> BenC: coolness it works
<BenC> fabbione: weez cookin' now
* Keybuk never understood why evms creates all those devmapper'd copies anyway
<Keybuk> I think we have two choices:
<Keybuk> - apply the bd-claim patch
<Keybuk> - stop supporting evms
<BenC> Keybuk: what's the fallout from option 2?
<Keybuk> upsetting some users
<BenC> is there any way we can make option 2 work without asking users to hack a config file?
<fabbione> BenC: let see if the git-send-pack works :)
<fabbione> yeps
<fabbione> gfs1 tree updated...
<fabbione> BenC: the gfs2 author is in vacation this week. there are a set of patches in there that will be pushed to Linus (like the 2 i am waiting for), others will make .23 for sure
<fabbione> BenC: if you really really feel unconfortable with that, i can start diverging userland, but it's just shifting one problem from one place to another
<fabbione> BenC: also note that gfs2 tree touches "only" dlm and gfs2.. meaning none of the core kernel functionalities
<fabbione> and not stuff people will use regularly
<BenC> fabbione: that's good
<fabbione> anyway. i will let you take a breath on it and ping you once the other fixes are in
<Keybuk> BenC: how do you mean?
<BenC> Keybuk: I mean our work arounds include: 1) uninstall evms, 2) edit evms.conf to ignore the disks, 3) switch to evms completely
<BenC> none of which seem easy to do with update-manager or something
<Keybuk> the problem with 2) is that it's not obvious to me why evms doesn't just do that by default
<Keybuk> (ignore volumes without evms metadata)
<BenC> yeah, that does seem pretty broken
<BenC> the people having the problem so far are not even using evms at all
<BenC> it's just being stupid
<Keybuk> yeah
<Keybuk> we installed it by default once
<Keybuk> yay us
<BenC> which release was that, dapper?
<Keybuk> warty
<Keybuk> +/**
<Keybuk> + * activate_on_kernel_partition
<Keybuk> + * The normal activation failed. If we're running on a 2.6 kernel, this could
<Keybuk> + * be due to bd_claim, meaning the user may have a kernel partition mounted on
<Keybuk> + * the same disk that we're trying to activate on. In this case, lets try to
<Keybuk> + * activate the segment on top of the kernel partition instead of the disk.
<Keybuk> + * The only things that change are the minor number for the target device and
<Keybuk> + * the starting offset.
<Keybuk> + *
<Keybuk> + * If this succeeds, we must indicate that this segment is active on top of a
<Keybuk> + * kernel partition, since it means certain other functionality cannot be used.
<Keybuk> + **/
<BenC> sounds like it's supposed to work around things
<Keybuk> yeah, trying to work out exactly how
<bdmurray> what is the ti multimedia card reader bug number?
<rtg> bdmurray: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/53923
<bdmurray> rtg: thanks
<johanbr> I've never been bitten by the above bug, but I noticed SD cards no longer automount with the Gutsy kernel. They work fine after manually mounting, though.
<bdmurray> rtg: is dmidecode helpful with bugs like 116185?
<BenC> bdmurray: /proc/acpi/dsdt is more helpful, but in reality, most bugs like that are BIOS bugs
<BenC> dsdt will help find out
<bdmurray> BenC: okay, thanks
#ubuntu-kernel 2007-05-23
<cmarcelo> hello. there's a net driver in ubuntu tree called "ipg", is there a reason for this driver not be in kernel main tree? looks like it used to be part of kernel main tree, but not anymore. anyone knows why?
<crimsun> it doesn't look like it was ever merged into mainline.
<crimsun> (unless it underwent a signifcant rename)
<cmarcelo> http://lkml.org/lkml/2006/5/1/273 -> (this patch refers to a file in mainline, at least looks like)
<cmarcelo> s/to a file/to ipg.c/
<jbailey> BenC: Around?
<zul> hey
<mjg59> BenC: The toshiba_acpi patch seems to have been dropped again
<BenC> mjg59: I deferred all of our local patches till this week
<BenC> I'll be getting them in before Tribe 1
<mjg59> Ok
<BenC> first part of upstream devel cycle is too crazy to have to merge all those things daily
<mjg59> Also, it doesn't seem to be present in the ubuntu-feisty history
<mjg59> But is applied
<mjg59> Oh, actually, it seems that the history link on k.u.c gitweb just doesn't give anything
<BenC> hmm...wonder if that's gitweb that's broken or something in the tree
<Keybuk> BenC: btw, afaict, SuSE don't have bd_claim.patch in their kernel tree
<Keybuk> so I guess this evms patch I stole off them works for them
<BenC> sweet
<mjg59> BenC: If I search for the commit, I can grab the commitdiff
<mjg59> It's just the history link that doesn't work
<BenC> Keybuk: are you going to upload fixed up evms?
<Keybuk> I will, yes
<Keybuk> working on mdadm first, since we care more about that
<BenC> Keybuk: thanks
<Keybuk> (more stolen patches from SuSE to improve udev interaction)
<bdmurray> BenC: would tagging bugs kernel-oops be helpful at all?
<BenC> bdmurray: yeah, actually that'd probably the be first useful tag we've had for linux-source-* :)
<bdmurray> BenC: heh, with the new apport stuff could it auto add the tag?
<BenC> bdmurray: probably...I still need to talk to pitti about how to handle oops/vmcore stuff, so I could check with him
<bdmurray> BenC: okay, I just wanted to make sure the bug squad and apport use the same tag
<bdmurray> I'll start with 'kernel-oops' - okay?
<BenC> cjwatson: would it make sense to preemptively add udf to storage-core too, or are we still using isofs for DVD images?
<BenC> bdmurray: sounds good
<cjwatson> BenC: we only need isofs in there
<cjwatson> I don't expect to be moving to UDF for the stuff d-i needs to detect
<bdmurray> BenC: I was looking at bug 113539 when this occurred to me but it doesn't have an oops statement in it.  Would a different tag be appropriate?
<BenC> cjwatson: ah, right, keep forgetting d-i != livecd
<BenC> bdmurray: if there machine crashes (lockups), we generally can't do anything without an oops...so maybe we need a tag for that case
<bdmurray> BenC: okay, I'll think about that
<zul> BenC: you can get my ssh key from my launchpad page: http://launchpad.net/~zulcss
<BenC> zul_: email me so I can forward it to proper channels (I don't create the accounts)
<zul_> okie dokie
<kylem> zul, hey dude, how's the little one?
<zul> kylem: meh...he had surgery again this weekend
<zul> BenC: done
<zul> kylem: but he is recovering alot better than the first time
<kylem> groovy.
<zul> and i might be going to see a stanley cup game at scotia bank ;)
<zul> or read the docs in the wiki
<kylem> BenC... why did we turn off IKCONFIG for a few flavours?
<BenC> IKCONFIG?
<BenC> not sure how that got disabled...worrisome
<BenC> then again, I can't see it needing to be turned on
<BenC> since we drop /boot/config-`uname -r` in the package anyway
<kylem> dunno, maybe an issue if someone wants to see config options from initramfs?
<maks_> was introduced for distros without /boot/config-foo
<kylem> yeah, i know what it's for, i just don't see a reason not to enable it... :)
<maks_> useless mem waste
<kylem> yeah, maybe 20KB worth, tragic.
#ubuntu-kernel 2007-05-24
<BenC> zul: wouldn't it be better to work on ubuntu-xen in a way that I could pull (IOW, work in ubuntu/binary-custom.d/xen)?
<BenC> zul: btw, to sync with the main tree, you'll want to remember these steps: "git-fetch origin; git-rebase origin"
<BenC> instead of git-pull
<zul> BenC: I thought I would just send a patch to the list 
<BenC> zul: you could do that too, just a suggestion
<BenC> doesn't make much sense to have a git tree just to produce a patch that I wont apply, but instead place in a subdir :)
<zul> no problem just wanted to keep the delta smallish
<Whoopie> BenC: Hi, are you aware of that? http://madwifi.org/wiki/news/20070523/release-0-9-3-1-fixes-three-security-issue
<BenC> Whoopie: nope, thanks I'll alert the security folks
<rtg> BenC, Whoopie: I got the madwifi notification from Luis earlier this morning.
<BenC> rtg: want to prepare new lrm for edgy/feisty/dapper?
<rtg> BenC: Not really :) But I'll do it anyway.
<BenC> rtg: it should be pretty easy
<BenC> get 0.9.3 and 0.9.3.1 tarballs, diff them, and put the patch in madwifi/patches/ in the lrm source, new changelog entry, and dpkg-buildpackage -rfakeroot -S
<Whoopie> rtg: ok, thanks.
<Whoopie> BenC: thanks, too.
* Starting logfile irclogs/ubuntu-kernel.log
<unhappy> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-feisty.git;a=commit;h=d3de93c8319a0dfe58e37eb7c27371f2f2d52456
<unhappy> how to undestand, where are rtl818x drivers from?
<unhappy> UBUNTU: rtl818x: Add 8180/8187 driver from wireless-dev
#ubuntu-kernel 2007-05-25
<BenC> unhappy: wireless-dev git tree
<unhappy> BenC, U mean this: linux/kernel/git/linville/wireless-dev.git @ git.kernel.org?
<unhappy> oh, i got it.
<unhappy> Its John Linville's git tree
<unhappy> thnx
<MidMark> guys there is some delays in linux kernel to appears in update manager? I got only updates for restricted modules, nvidia driver and linux-libc-dev
<MidMark> I repeat: linux-image-generic point still to .15 and not .16, restricted modules are updated aswell nvidia drivers, if someone updates then breaks things because X will not start anymore apart back to nv instead of nvidia driver
<Lure> MidMark: linux-restricted-modules-common does not include much (no kernel code), so it is safe
<Lure> MidMark: I am sure the remaining packages will follow soon (they need archive admin to get them trough binary NEW)
<MidMark> Lure: ok but for people who has nvidia this is not so safe
<MidMark> I think that if I will updates and will break my feisty
<Lure> MidMark: why? no nvidia stuff is in the packages that were updated. Is there any report of brekaing on nvidia?
<MidMark> or I'm wrong?
<MidMark> Lure: I mean nvidia-glx abi bump
<MidMark> from .15 to .16
<Lure> MidMark: also modules go in separate dir - see /lib/modules/2.6.20*
<MidMark> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/116768
<Amaranth> MidMark: having nvidia-glx get upgraded does not hurt, it's just the X driver
<Amaranth> as long as your linux-restricted-modules and linux-image don't get out of sync (and those are parallel installable so no worries) you should be fine
<MidMark> Amaranth: if I install nvidia-glx .16 with kernel .15 will X starts??
<Amaranth> it should, yes
<MidMark> sure? strange
<Amaranth> the version is because it comes from the linux-restricted-modules package
<Amaranth> but it's _just_ the X driver, it'll work with any kernel module of the same version
<Amaranth> version being 9631
<MidMark> then ok, but I don't want to try
<MidMark> wait for kernel image that seems quite late
<goncalo> hello
<bdmurray> what package did ipw3945 run off to for the gibbon?
<zul> ubuntu-modules i think
<Nafallo> indeed
<Nafallo> but rt2x00 seems to have gone AWOL?
<bdmurray> thanks
<johanbr> There's an rt2x00-source package in Gutsy. Maybe it's not meant to be built in-tree anymore?
<Nafallo> that's because we import it from Debian :-)
<xhaker> crimsun, regression on 2.6.20-16 SB450 Acer, ping me back please
#ubuntu-kernel 2007-05-26
<andi5> hi... is there a way to install an ubuntu kernel with CONFIG_HPET_EMULATE_RTC=[ym]  without losing the nvidia (and maybe vmware) modules?
<kylem> rebuild l-r-m yourself?
<andi5> hm... lrm 2.6.22 seems to miss vmware-player modules, so it is probably best to start from a stock generic 2.6.20 feisty kernel, modify and rebuild that?
<Nafallo> hi :-)
<Nafallo> why doesn't my NIC work with the latest feisty-security? :-)
<Nafallo> Linux ogre 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007 i686 GNU/Linux
<Nafallo> I had to revert
<\sh> Nafallo, which nic? 
<Nafallo> 3Com 3c905-TX-NM
<Nafallo> anyone can reproduce? :-)
<Nafallo> I was inches away from blaming my ISP ;-)
<\sh> oh...old stuff ;) I just can't use wifi on my r200 since the last kernel update on feisty anymore 
<\sh> that's why I can't take the r200 to the linuxtag...it would be really a shock to see, that wifi is not working on ubuntu ;) 
<JanC> sorry, the only 3Com I have is an almost antique 3c900B-TPO Etherlink XL   ;-)
<johanbr> Well, if you can't connect to the net anymore, your machine is obviously more secure than it was before. :)
<Nafallo> johanbr: :-P
<Nafallo> old stuff, good stuff... ;-)
#ubuntu-kernel 2007-05-27
<Enverex> Is there any particular reason rt2500 is missing from the .22 kernel? (I'm concerned that it doesn't seem to build against the .22 series)
<isidoro> hi
<isidoro> I got this: Ubuntu 7.04 with kernel 2.6.20-15 ships with a kernel built with CONFIG_USB_SUSPEND which apparently breaks the libusb support that I need for my garmin... do you something about it??
<EnolaGay> hi all
<Nafallo> hi
<EnolaGay>  Is it possible that in Gutsy sony_acpi is removed from the linux-source-2.6.22 but not from the kernel package?
<EnolaGay> hi Nafallo
<EnolaGay> maybe it is sepparated because of the linux-ubuntu-modules package
<EnolaGay> yeah, seems so, sorry for bothering
<EnolaGay> hm, it makes it very hard to patch the "ubuntu modules" without recompiling the whole kernel at least I don't know how
<EnolaGay> cu all
<EnolaGay> hi again
<EnolaGay> Is the dynamic tick option only disabled for the 386 gutsy kernel package or is it for alle packages?
<shawarma> Mithrandir: /win 48
<shawarma> Mithrandir: whoops
<shawarma> I'm working on getting user-mode-linux into gutsy. I had it working with 2.6.22-1.5 but since then, aio_reserved3 was removed from (struct iocb), which makes user-mode-linux ftbfs on compiling arch/um/os-Linux/aio.c
<shawarma> I tried removing the only reference to it (which was just in the initialisation of the struct: http://lxr.linux.no/source/arch/um/os-Linux/aio.c#L75 ), which made it compile, but it just seems too easy. :)
<shawarma> Any clever input on this?
#ubuntu-kernel 2008-05-19
<arekm> hello, is there some nice way to get all patches gutsy kernel patches that are in ubuntu git repository and that are not in upstream .22?
<evand> cking: Are you handling squashfs bugs these days?  Would you mind taking a look at bug 199997 ?
<cking> evand: OK
<cking> evand: Bug #199997 is actually a lower level I/O problem, so I try and document some appropriate tweaks to try to work around the read error.
<evand> ok, thanks
<CoolAcid> Good Day everyone - anyone around?
<CoolAcid> Q: How is the Xen tree built? I'm getting an opps on the xen tree, but not on the server tree - specifically aacraid driver - trying to find the differences now.
<CoolAcid> Diving down: is chucks/ubuntu-hardy-xen.git the tree the Xen kernel is built from?
<crimsun> maks_: re: 481979, index=-2 is preferable, but index=2 will achieve something similar.  For >=2.6.24, you really want to use snd.ko's slots=  parameter.
#ubuntu-kernel 2008-05-20
<maks_> uups already asleep crimsun 
<maks_> right that was the new interface thanks :)
<maks_> i was starting a bisect when the reboots reproducibily went random
<maks_> was due too load order and having it on first slot ;)
<TeTeT> as discussed in the roundtable, here a start for a walkthrough for the driver update cd, module package creation: https://wiki.ubuntu.com/KernelTeam/Hardy/DriverUpdateCd
<tjaalton> my iwl4965 sometimes crashes when trying to suspend the machine (and the driver is removed). I'm using the version from lbm, so maybe I don't need the led :)
<nxvl> hey
<nxvl> i'm having this problem with my ricoh card reader
<nxvl> and a lot of people seems to have it on google
<nxvl> but there is still no solution
<nxvl> at least no one than i have find
<stgraber> nxvl: the "is disabled" thing ?
<nxvl> stgraber: yep
<stgraber> I have it too, HP Compaq 8510p
<nxvl> [   27.567602] ricoh-mmc: Controller is now disabled.
<mjg59> That's saying that the mmc controller is disabled, which in theory allows the SD reader to read MMC cards as well as a result
<nxvl> well
<mjg59> The windows sdhci driver won't read MMC cards, hence the separate controller
<nxvl> it doesn't
<mjg59> Yes, but it's nothing to do with tha tmessage
<nxvl> mjg59: what else do you need?
<mjg59> A bugfix
<mjg59> I've no clue what causes the fact that it doesn't work (I have the same problem)
<nxvl> oh
<stgraber> I would love a fix too :) I currently have a separate card reader which is somewhat stupid when you have an internal card reader :)
<nxvl> yep
<nxvl> i'm going for a trip i don't have a camera cable and not a lot of space in the memory card
<nxvl> so i'm kind of in problems
<nxvl> i have found this patch
<nxvl> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=882c49164d72c45f37d7fa1bb3de7c31cf1a5fab#patch1
<nxvl> and some commendts saying it solves the problem
<nxvl> BUT
<nxvl> i don't know how to compile only the module and not the whole kernel
<nxvl> so i haven't tried it yet
<laga> amitk: are you guys still interested in hearing about aufs (and how it's used in ubuntu)?
<BenC> laga: Mainly we are interested in how we can use it for livecd
<BenC> laga: We know it works, we just need to enable it for the livecd build
<BenC> so it can start to be tested more widely in that context
<laga> oh, that's simple.
<laga> "Ubuntu 8.04 allows the user to boot the standard installation disk (the
<laga> live disk) with aufs instead of unionfs, by using the union=aufs option."
<BenC> really?!
 * BenC wishes he knew that
<laga> that's what julian andres klode, the aufs guy for debian, said on the aufs-users ML.
<cking> That's news to me.
<amitk> laga: that is good news indeed if it works. 
<amitk> laga: how actively is it being developed
<amitk> ?
<laga> amitk: aufs or the initramfs patch?
<amitk> laga: aufs
<laga> amitk: new "monday release" every, umm, monday. those are basically stable CVS snapshots.
<amitk> laga: the aufs page lists lots of patches needed to apply to get it to work properly
<amitk> any plans to upstream aufs?
<laga> the maintainer is usually friendly and responsive..
<laga> amitk: some of those patches are applied to the ubuntu kernel already.
<laga> amitk: i dont think upstream likes stacking file systems like aufs or unionfs. but you better ask the maintainer about that.
<BenC> not-upstream == more work for us
<laga> unionfs isnt upstream either :)
<BenC> if upstream has a better way to do livecd than a stacking filesystem, we'd like to hear about it
<BenC> laga: yeah, but we want to follow something that has a chance
<amitk> laga: we aren't anti-aufs :) We just don't want to swap one set of bugs for another set of bugs without any long term benefit
<laga> :)
<laga> aufs works better for me with NFS. that's all i can say. :)
<laga> upstream prefers a completely different upstream to stacking file systems, but i haven't followed the discussion closely
<laga> um.
<laga> a completely different approach.
<amitk> ok
<laga> it'd be great if aufs was used for the live disk. i use for diskless clients in mythbuntu and it works very well there.
<amitk> we are planning to do a test livecd with aufs
<laga> lots of live disks use aufs, i'm sure you won't be disappointed
 * laga afk
<maks_> crimsun: do you have link for useful output on an alsa bug report?
<crimsun> maks_: kernel- or userspace?
<maks_> dealing mostly kernel side
<crimsun> maks_: ok, driver (codec) or core?
<maks_> haha, ok hmm most are driver
<maks_> (generic question so i'd be better guide for the next filing)
<crimsun> maks_: ok, then the appropriate codec info is useful.  /proc/asound/card*/*codec*
<crimsun> maks_: there's a script (http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh) to gather the more useful info.
<maks_> thanks crimsun 
<crimsun> np
<sectech> I was wondering if someone could help with a bug I am triaging (I am a member of bugsquad)... The bug on launchpad is bug #231986...The summary is that the reporter has a soundcard in his laptop with the ALC861VD chipset and it isn't working... I have made our standard information request for hardware detection and I am finding the device isn't even showing up in lspci -vvv... Can someone help me out with this?
<maks_> cat /proc/asound/cards, lsmod
<maks_> sectech: HD Audio Controller [8086:284b]
<maks_> it is shown in lspci
<sectech> Ahh... It is now... The previous lspci didn't show it
<sectech> I can only go by what the reporter submits...
<maks_> 22:16 <crimsun> maks_: there's a script 
<maks_>                 (http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh) to 
<maks_>                 gather the more useful info.
<maks_> don't see that particular laptop in alsa changelog
<maks_> guess it needs it's own quirks
<maks_> snd-hda is the new ata piix :)
<sectech> maks_,  Okay, I'll ask the reporter to get that file, run and submit the result...
<johanbr> sectech: see also http://ubuntuforums.org/archive/index.php/t-636194.html
<sectech> Okay
<sectech> johanbr,  I saw on one of the forums they that they requested that the user install the backports package for his kernel...  So I made the same request, I ended up getting a reply stating it now makes a sputtering noise I guess
<sectech> Yeah this doesn't seem new
<crimsun> sectech: the two most useful pieces of info are 1) lspci -nv|grep -A1 0403 ; 2) the contents of /proc/asound/card*/*codec*
<crimsun> sectech: for PCI audio devices, the SSID is much more useful (hence grep -A1).
<crimsun> sectech: (the script takes care of grabbing that info)
<sectech> crimsun,  Thank you... I documented that for myself for the next audio problem I run into... 
<sectech> It's difficult sometimes when you don't know 100% what to ask for, this helps a lot
<crimsun> sectech: np
<crimsun> the script is (or should be) mentioned on wiki/DebuggingSoundProblems
<sectech> Hmm... okay.... 
<crimsun> I think bdmurray, ogasawara__, and I talked about it last UDS, so it should be there.
<sectech> yes it's there... I guess I missed that
<sectech> thanks crimsun 
<crimsun> np
#ubuntu-kernel 2008-05-21
<lamont> May 21 09:18:29 mix kernel: [159411.675112] rtc: lost 17 interrupts                     
<lamont> make it stop saying that, mk?
<psusi> does anyone know why the kernel was changed to default to defeating host protected areas on disks and why this should not be considered a bug and reverted?
<mjg59> psusi: Because the alternative was for people's systems to stop working when they switched from IDE to libata
<psusi> mjg59: eh?
<mjg59> Turns out that most people consider that a bug
<psusi> mjg59: I'm seeing people's systems breaking because of this change
<mjg59> psusi: The IDE system deactivated the HPA since, well, forever
<psusi> oh really?
<mjg59> Yes
<mjg59> So people created partitions in the HPA
<mjg59> When libata didn't deactivate the HPA, stuff broke
<psusi> hrm.... why is that not broken?  HPA means you arent supposed to muck with it
<mjg59> Because their filesystems now extended into unreachable areas of the disk
<psusi> well, yea... but it was broken before and then fixed
<mjg59> No
<psusi> so we revert to the broken heavior?  doesn't seem right
<psusi> behavior even
<mjg59> There is no way in the universe you can claim that breaking people's filesystems is a fix
<psusi> no, the fix was NOT breaking HPA
<mjg59> There is no way in the universe you can claim that breaking people's filesystems is a fix
<psusi> but if they already had a broken system then fixing it broke their system
<mjg59> That's not an acceptable option
<mjg59> Which is why upstream behaiour was changed
<mjg59> Also, this happened over a year ago
<psusi> how is it acceptable to allow them to break their system by overwriting the HPA?
<psusi> there may be parts of the bios written there that if we overwrite, the system won't boot
<mjg59> Yes, it's acceptable to let people do that
<mjg59> No, there will not be parts of the BIOS written there
<psusi> there could be... you don't know why the bios protected it
<mjg59> Yes, and it could also contain child pornography
<psusi> it seems that some vendors put bios extension programs there
<mjg59> In which case being able to delete it would be a good thing
<psusi> the point is that via HPA, the bios is telling us DON'T TOUCH
<mjg59> No, vendors do not put bios extension programs there
<psusi> if you as the user want to override that, that's one thing... but doing it by default?
<psusi> I have heard of some that do
<psusi> there is at least one vendor I have heard of that uses it to store some sort of instant on cd playing program
<psusi> so you can play audio cds without booting up fully
<mjg59> Yes, it's a filesystem containing Linux
<mjg59> It's not a BIOS extension
<psusi> right... but it's marked as protected... so then we come and install Ubuntu and trash it
<mjg59> So don't trash it
<mjg59> The partitioner makes it easy to avoid this
<psusi> kind of hard when it just looks like the tail end of free space on the disk
<mjg59> No, it'll still look like a partition
<psusi> it isn't listed in the partition table since it exists in the hidden part of the disk
<mjg59> jpgpls
<psusi> though at least in this one person's case, the protected area doesn't appear to contain anything.... but for some reason the bios wanted it protected and it's causing a problem when the disk size does not match what the bios recorded, which was minus the hpa
<mjg59> "disk size"?
<mjg59> If there's an HPA, the BIOS will still see the HPA
<mjg59> It's not altered until Linux starts up
<psusi> it appears to record the size without the hpa when it writes the fakeraid metadata
<mjg59> Hm. Though, potentially, it would cause problems if the kernel or grub files end up in the HPA
<psusi> then linux starts, disables the hpa, and suddenly the disk size is wrong
<mjg59> psusi: At which point the BIOS isn't called again, so there's no problem
<psusi> yea, there is... the metadata is now in the wrong location
<mjg59> What metadata?
<mjg59> What do you mean by "wrong location"?
<psusi> it's supposed to be the last 2 sectors of the disk... but in this case, it's actually about a meg short of there
<psusi> fakeraid metadata
<mjg59> What?
<mjg59> Ah
<psusi> the bios writes it to what IT sees as the last 2 sectors
<psusi> but that's just before the HPA starts
<mjg59> That's more interesting, but easy to fix
<psusi> we lift the HPA and now it's not in the last two sectors
<mjg59> Ridiculously retarded BIOS
<psusi> probably ;)
<psusi> "but it works fine with windows"
<mjg59> But, as I said, easy to fix
<mjg59> The fakeraid code needs to check both the reported size and the old size
<psusi> ack
<psusi> hrm.... how would it find the old size?
<mjg59> The kernel has the original size
<mjg59> It reads it before messing with the HPA
<psusi> any idea how one would look that up?
<mjg59> In-kernel? Not off-hand.
<mjg59> Just grep for hpa in drivers/ata/
<psusi> hrm... guess it's time to do a git clone
<mjg59> ANyway, getting into the station now
 * mjg59 leaves
<psusi> mjg59: it appears that the kernel does NOT retain the HPA disk size after lifting the limit
<psusi> libata defines the parameter ata_ignore_hpa... can you not just pass ata_ignore_hpa=0 on the kernel command line if it is built as a module?
#ubuntu-kernel 2008-05-22
* You're now known as ubuntulog
<jaminkle> can you guys help me with a kernal panic i am getting when i boot or should i ask in #ubuntu
<abogani> jaminkle: #ubuntu is a better place for that type of questions
<jaminkle> ;[
<zul> rtg: is the universe kernel build system for intrepid up somewhere?
<amitk> zul: BenC was going to propagate teh tree...
<amitk> *the
<zul> amitk: ah ok
<BenC> depends on what you mean by universe
<BenC> if you mean ports (a la sparc), then yes...if you mean universe as in binary-custom out-of-tree builds, then no
<BenC> well, ports wont be universe, so you can't possibly mean that :)
<zul> the binary-custom build thingies :)
#ubuntu-kernel 2008-05-23
<tjaalton> there's a strange'ish issue with the hardy kernel, that it confuses our netapp when using nfs4 mounts with kerberos. all the clients that use them get "remote io" errors. I've just sent an email to the nfsv4-list, but if anyone has seen something like this fixed in .25 or .26rc, I'd like to know :)
<alex_joni> anyone uses software RAID with 8.04 ?
<Ng> alex_joni: yup
<Ng> lots of people I imagine :)
<alex_joni> Ng: any good setup instructions?
<Ng> alex_joni: if this is a fresh install, let the installer do the work for you :)
<alex_joni> Ng: tried that.. but doesn't quite work
<alex_joni> Ng: I have 3 x 500G hdds, and I want to set up RAID5..
<alex_joni> I finally managed to make it build /dev/md0 (but then I can't set up 2 partitions for / and swap on it..)
<alex_joni> installing only with /, fails when it tries to install grub (or lilo)
<Ng> never done raid5 with software raid, only 0, 1 and combinations thereof, but I expect there are googleable tutorials for madm
<Ng> mdadm
<alex_joni> Ng: that's why I was asking .. found a couple, but not that usefull
<alex_joni> hmm.. seems grub & lilo can't read RAID5 arrays
<cocoa117> hello, question regarding to fdisk. How many partition can kernel see on amd64 Ubuntu Hardy? I currently trying to create total 17 partitions on my hard disk, because of LVM, after exceeding /dev/sda15, kernel won't see it anymore
<cocoa117> is this normal? i am using Ubuntu hardy desktop amd64
<mjg59> The SCSI layer only supports 15 partitions per device
<cocoa117> ohhhh, that's why
<cocoa117> nothing to do with kernel then
<cocoa117> thanx mjg59
<mjg59> The kernel SCSI layer, that is
<mjg59> The kernel could be modified to allow more
<cocoa117> yep, i am using /dev/sda as SATA driver
<cocoa117> really? how and where?
<mjg59> No clue off-hand
<mjg59> But it's a code limitation, rather than anything fundamental
<cocoa117> i c
<arekm> anyone alive with knowledge about ubuntu git kernel trees?
<BenC> arekm: Yes
<pwnguin> fail
#ubuntu-kernel 2008-05-24
<cwillu> Are cgroup's known to be broken in 2.6.24-17-generic?
<cwillu> bah, nvm, although sensible defaults for /cpus and /mems would make people not ask about this another time :p
<u-foka> Hy! Please help my to recompile my kernel with a patch! I read the kernel compile howto on help.ubuntu.com but I'm lost :S
#ubuntu-kernel 2008-05-25
<qense> What is a 'qc timeout'?
#ubuntu-kernel 2009-05-18
<benh> hoy !
<benh> any reason why jaunty is missing the keyspan firmwares ?
<benh> they got lost around hardy or so and we got them back in
<benh> but it looks like they're gone again
<benh> ahaha
<benh> as usual
<benh> "will fix in the next release"
<benh> morons
 * benh calms
<benh> needs coffee
<hakkav> hi
<hakkav> anyone worked on   Complete Fair Queueing
<anubhav> hakkav, have you tried kernelnewbies?
<hakkav> yeah
<hakkav> pretty dead
<hakkav> im just curious to know whats complete fair queieng and whats a better option these days
<hakkav> also have there been any new improvements to the Broadcom b43 driver
<anubhav> hakkav, linuxwireless must be having some info about b43
<anubhav> hakkav, regarding CFQ if you have some pointed questions i am sure their are guys who would help you out
<hakkav> thanks mate
<Twigathy> hey all, can anyone shed light on why this bug is happening: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/377937
<ubot3> Malone bug 377937 in linux "SiI3726 port multiplier breaks under Karmic" [Undecided,New] 
<apw> Twigathy, hrm.  if possible it would be good to get the messages seen when it fails in the bug
<apw> also an lsmod and dmesg off the livecd, as it works there
<Twigathy> Tricky -- they flow past too quickly for me to scribble down :|
<Twigathy> I can do the lsmod / dmesg though :)
<apw> perhaps a digital photo would capture them
<Twigathy> Good plan :)
 * Twigathy will get to that later today, got a little work to do first
<Kano> hi, where is rtg?
<Twigathy> Typical - my camera decides its batteries are dead ...
<Twigathy> weird - that port multiplier issue seems to be a bit random... works 100% of the time in windows, but for ubuntu it'll hang the boot (either looping through trying to bring up SATA links, or some time shortly after it's done that)
#ubuntu-kernel 2009-05-19
<toabctl> hi all
<toabctl> question: what about openvz in jaunty and jaunty+1 ? there are no packages available. i use openvzwith 8.04 and i want to know if kernels with openvz will be available in the feature.
<zxguitar> hello.... is there any site or channel where i can get .config files for a specific machine/laptop???? anyone knows???
#ubuntu-kernel 2009-05-20
<Kano> hi, did somebody reset the karmic git?
<Kano> last change	Tue, 28 Apr 2009 22:56:52 +0000
<Kano> apw: did you set karmic master to wrong branch?
<Kano> could somebody fix it?
<Kano> hi apw, could you fix the karmic git head? it points to something really old
<okayzed> has anyone been following IMA development?
#ubuntu-kernel 2009-05-21
<warptrosse> hi
<warptrosse> whats the difference between rtentry and fib_node?
<warptrosse> or... whats the best way to manage routes: rt structures or fib frontend?
<earlmred> is there any documentation on how to prepare a PPA for a custom flavor?
<maxb> Surely you don't need to do anything to the PPA, just to the source package?
<lesshaste> hi
<lesshaste> is there a channel for low level questions? I want to find a way to limit the RAM usage of a single process. this will presumably require a kernel patch
<lesshaste> where is /proc/config.gz on ubuntu? Is it somewhere else or just missing?
<makke> there is /boot/config-`uname -r`
<lesshaste> makke: thanks
<earlmred> hmm ... tried to push my kernel packages up to PPA, and got this build error: EE: Missing modules (start begging for mercy)
<earlmred> but it compiles fine on my laptop...
<earlmred> http://launchpadlibrarian.net/27010983/buildlog_ubuntu-jaunty-i386.linux_2.6.28-12.43_FAILEDTOBUILD.txt.gz
<earlmred> any ideas what i'm doing wrong?
<xteejx> Hi guys, I'm having a problem with a users bug, specifically bug 114010, and I was wondering instead of subscribing the Kernel Team, if someone would have a look at it, it's a bug in ppp, and this is part of the kernel now isn't it?
<ubot3> Malone bug 114010 in ppp "pppd logs incorrect traffic stats" [Low,New] https://launchpad.net/bugs/114010
<johanbr> xteejx: there is a kernel PPP driver
<johanbr> But pppd is a userspace program.
<xteejx> johanbr: ok, so it could just be pppd itself and not the driver? no worries, i got him doing a gdb backtrace anyway but thanks :)
<johanbr> xteejx: a backtrace of what, exactly? this isn't a crash after all
<johanbr> it looks like a simple overflow in pppd
<xteejx> im new to triaging you see and someone on IRC told me to get a backtrace from him
<johanbr> in this case, that's unlikely to be helpful
<johanbr> you can ask if the traffic statistics reported by ifconfig also overflow
<johanbr> if they do, it's a bug in the kernel
<johanbr> if they don't, it's a bug in pppd
<xteejx> ok i'll ask for that then thank you :)
<johanbr> you're welcome
#ubuntu-kernel 2009-05-22
<Kano_vbox> hi apw 
<Kano_vbox> Host/Kernel/OS  "Kanotix" running Linux 2.6.30-6-generic i686 [ Kanotix Excalibur 20090522-06:09 ]
<Kano_vbox> CPU Info        Intel Core2 Duo E8400 @ clocked at [ 2979.166 MHz ]
<Kano_vbox> Videocard       InnoTek Systemberatung GmbH VirtualBox Graphics Adapter  X.Org 1.4.2  [ 1680x1050 ]
<Kano_vbox> Processes 111 | Uptime 17min | Memory 129.3/497.0MB | HDD Size unknown.. () | Client Konversation 1.1 | Infobash v2.67.1
<Kano_vbox> made a aufs2 update patch on my own. without hd it must be live mode, dont you think so ;)
<Kano_vbox> i see no reason to wait for adding aufs
<Kano_vbox> update aufs+ update squashfs-tools in karmic to 4.0 and your live images would work too
<Kano_vbox> no single line needs a change there...
#ubuntu-kernel 2009-05-23
<JanC> hm, I'm just reading http://blog.bofh.it/debian/id_267 and I'm wondering if something like the 'new_id' parameter works for other subsystem than USB too (e.g. PCI) ?
<infinity> JanC: I do believe that it works for PCI too, yes.
<JanC> that might be great to easily fix some "new hardware" problems
<JanC> or at least try to
<JanC> if I understand correctly, it might be possible to solve quite some hardware problems without needing a new kernel...
<JanC> and thus it shouldn't be too difficult to provide support for new hardware after the release
<schiggy> hi @all
<schiggy> i hope you can help me. i search the file, which starts the first user process. i must work with the 2.6.21.1 kernel
<jpoirier_> Hello
<jpoirier_> I have a question about compiling Ubuntu Jaunty
<jpoirier_> I am trying to build kernel version 2.6.28-12.43 but for some reason the version shows up as 2.6.28.9 when the build completes
<jpoirier_> Where does the kernel version get set?
<jpoirier_> Never mind, I see the version in the Makefile here.
<jpoirier_> Which I can change to match 2.6.28-12 of course, but really I think that given that I did checkout of a specific tag "Ubuntu-2.6.28-12.43", the Makefile should already have been updated to match the tag.
<jpoirier_> I think what I am building is the correct source for 2.6.28-12, given that git log shows the latest commit.
<jpoirier_> Thank you..
<echooo6> can someone point me to a howto for including a new kernel recompile + cd remaster?
<echooo6> I think I'm missing aufs, which refuses to build 
<franczena_> Hello
#ubuntu-kernel 2009-05-24
<schiggy> hi
<asif> hi all
<asif> any ubuntu techyys in here
<asif> could do with some help
<asif> anyone
<Notch-1> hi all, please check this out: https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902 
<Notch-1> this CONFIG_BLK_DEV_LOOP=y new setting is a huge problem for somebody, are there any chances to get back to CONFIG_BLK_DEV_LOOP=m ?
<ubot3> Malone bug 342902 in loop-aes-source "Build error: âstruct bioâ has no member named âbi_hw_front_sizeâ" [Undecided,New] 
<TheMuso> asif: I think most if not all kernel devs are not currently available, due to the Ubuntu Developer summit starting tomorrow, and everyone involved with kernel development is likely not at a computer right now.
<sp200606> hi, I'm trying to compile kernel 2.6.30-rc7. It works fine but doesn't build any modules. What I am doing wrong (make, then make modules: nothing happens)? thanks
<sp_> how can I build the modules?
#ubuntu-kernel 2010-05-24
<rafiyr> Anyone know off the top of your head head what sorts of stuff an hid driver should do before sending usb messages to tell the device to self calibrate?
<amitk> morning all
<cooloney> 'ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored.'
<cooloney> does anyone know this error when 'fdr binary-xxx'
<amitk> cooloney: I saw it too, but haven't nailed down the reason yet. Remove fakeroot from your command
<cooloney> amitk: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544471
<ubot2> Debian bug 544471 in fakeroot "cap_sys_nice on executable leads to ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored" [Normal,Open]
<cooloney> amitk: i am goting to 'sudo su' and build the image without fakeroot now
<amitk> cooloney: it's probably worth asking on #ubuntu-devel when rest of EU wakes up
<cooloney> amitk: https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/474004, comment #15
<ubot2> Launchpad bug 474004 in libavg (Debian) (and 1 other project) "Please sync libavg 1.0.1-1 from sid (affects: 2) (heat: 24)" [Unknown,Fix released]
<anoteng> Anybody familiar with git-bisecting the ubuntu kernel? I'm suspecting I keep producing the same .debs over and over againâ¦
 * apw yawns
 * lag tells apw to put his hand over his mouth
<apw> heh
<apw> gah its sooo hot here already today
<lag> Yep. I may have to dig the fan out from the garage in the not too distant future 
<apw> commit 6f12efee9e86b52193aa2e7e14ad013fc3153a8a
<apw> Author: Douglas Gilbert <dgilbert@interlog.com>
<apw> Date:   Sun Jan 3 13:51:15 2010 -0500
<apw>     skip sense logging for some ATA PASS-THROUGH cdbs
<apw> lag, so its that one in the stable tree
<apw> just tell smb that that one is linked to your bug
<apw> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git
<apw> lag, that is the remote i added to get the stable branch into my lucid repo
<apw> ogasawara, i see the kernel-janitor moving things Fix Committed, is that your doing?
 * apw waves to pgraner 
 * pgraner gives apw a shout out
<apw> man its quiet out here today
<apw> it must be the hear
<apw> heat
<popey> apw: public holiday in some regions AIUI
<apw> ahh yes in .eu some places, i'd forgotten thanks popey 
<amitk> ogasawara: When're you freezing for A1?
<amitk> I expect it will be based on 2.6.35-rc1?
<apw> amitk, the kernel has to be in the archive by the 1st of June, so I'd guess either 28th or 31st at the very latest
<apw> i would not be supprised if -rc1 has not yet gotten in by then
<apw> or to put it a different way, i might recommend that we stick with .34 than ship A1 with 35-rc1
<apw> as -rc1 is normally a crashy heap
 * amitk agrees, just wanted to confirm
<amitk> -omap mainline flavour is almost ready and I'd like it in A1
<apw> amitk, and i can see no issue with you being .34 and master .35-rc1 either
<apw> oh one branch ... doh 
<apw> so it has to be synced :)
<apw> you just add to the weight for .34 if yours is there and working :)
<lag> bug 584330
<ubot2> Launchpad bug 584330 in linux (Ubuntu) "hid-gyration does not support GYR4101US remote (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/584330
<lag> Am I within my limits to just okay this patch?
<lag> It looks harmless 
<apw> yeah that looks like a simple addition of an ID, hard to have real regression potential
<lag> I am, as yet, unsure of my bounties 
<apw> if its not had a test kernel done and published I would recommend you do that
<lag> boundaries 
<apw> then get it on the kernel-team list ... looks sane to my eye
<lag> Will do
<lag> Cheers apw
<amitk> apw: it boots with ogasawara's latest, needs some more cherry-picking to get all the goodness. But I think I could have something by tomorrow and then let mathieu/cooloney handle it from there..
<apw> amitk, i assume this is planned to be pulled into master?
<amitk> apw: yes
<apw> amitk, how big is the delta ?  i assume much of it will go away as .35 formed ?
<amitk> apw: a patch or two
<amitk> and yes, I only intend to cherry-pick from mainline. This kernel should strictly be the mainline version of omap
<apw> amitk, better than we could have hoped
<apw> amitk, we should start the dialog about .34/.35-rc1 for A1 wtth ogasawara when she wakes up
<amitk> apw: sure, I agree that it might be good for userspace folks if we stuck to 2.6.34 so they could start fixing up their stuff and we might even boot :)
<apw> it would be a rare thing that A1 boots for sure
<lag> How often is git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git updated? 
<apw> that is live
<apw> that is _the_ master
<apw> ie. it updates instantly when it changes, and that is manual, when smb et al push
<sconklin-gone>  /nick sconklin
<lag> So daily? weekly?
<lag> How do I find out the difference between my local repo and the remote one? git diff master origin/master? 
<lag> I'm guessing that will diff the HEADs
<amitk> git log master..origin/master should give your all the new commits IFF the origin tree hasn't been rebased.
<lag> Thanks amitk
<apw> lag, ?? lag> So daily? weekly?
<amitk> I think he was asking how frequently we push to the master repo
<apw> lag if its a bare repo, you only have 'remote things'
<lag> amitk: Correct
<apw> oh thats ust as needed
<apw> when there is change, when something is ready and becomes committed, that occurs by pushing
<lag> I'm looking for an average figure 
<apw> before then its just an experiemnt in 'my' local repo
<apw> its completely arbitrary, for development likely every day
<apw> for a stable release likely not at all for weeks and then big batches of stuff pushed over a few days
<lag> i.e. If I do a git log master origin/master 5 days after my last fetch and nothing's changed, I should be worried?
<apw> when security is coming silence for a while then blammo a complete release is pushed
<apw> origin/master is a just a copy of the remote side when you last ran fetch
<apw> so it provides no information on upstream
<lag> That's true
<apw> its possible git remote show origin may tell you more
<apw> but i tend to just git fetch
<lag> Okay
<lag> I'll work the rest out :)
<amitk> lag: as a working practice, if you add all the trees you care about as remote, then you can start your day with a 'git remote update' to see what changed
<lag> Now this is the stuff I need
 * lag writes down new commands
 * abogani just noticed than section_image parameter is totally ignored...
<lag> Oh, it doesn't list, it updates?
<lag> Is that like doing a fetch on all the branches?
<amitk> lag: right
<lag> And then to see what we just fetched we do a? git status, or git diff?
<amitk> just see the result of the command? It will print out stuff if things changed
<lag> Cool
<amitk> you can then choose to merge the remote branches into your local ones, or rebase your work on top of them.
<lag> or reset?
<amitk> yeah, sometimes that too :)
<JFo> pgraner, I just wanted to mention that I have yet to see a self-review in my allhands page.
<JFo> been looking since the e-mails came out
<pgraner> JFo: ack, lemme check with HR
<JFo> k, thanks 
<JFo> apw, yeah, I wasn't sure how to break those items out on the bug handling BP
<apw> JFo, sorry had to reformat them to get them on the list at all
<pgraner> JFo: you are due for one and HR is investigating :-)
<JFo> apw, no sweat
<JFo> pgraner, cool
<apw> hope that it makes sense how i've done it
<JFo> apw, it does
<lag> What's are the fundamental differences between 'fdr binary-generic' and 'fdr binary-arch'?
<apw> binary-generic only makes one flavour
<apw> and it doesn't make any ancillary things
<apw> like the per architecture linux-tools in later series
<lag> So, if I'm not building for server etc, I need to do generic?
<apw> generic is the common flavour for both i386 and amd64
<apw> so not a bad base choice, cirtianly i build -generic for both of those for a test kernel, thats the 90% case
 * apw lunches
<bjf> moin all
<manjo> bjf, gm
<amitk> moin bjf, manjo
<manjo> amitk, long time no hear buddy
<amitk> just busy slacking off :)
<manjo> heh
<bjf> amitk, that can be quite time consuming
<amitk> you bet, sometimes just doing the work is easier the pretending to
<vanhoof> pgraner: ping
<cnd> apw, ogasawara: do we want to try to pull in upstream multitouch changes for alpha 1, or would we rather just wait for them to be pulled when we update maverick to 2.6.35?
<pgraner> vanhoof: poing
<pgraner> pong even
<JFo> moin bjf 
<bjf> moin big guy :-)
<JFo> :)
<bjf> JFo, you didn't get to a point where you'd made any changes to the test ISO scripts did you? that's what I'm going to work on first this week
<JFo> no, I didn't change anything
<JFo> so they are still as-is
<bjf> cool
<pgraner> apw: can you look at bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/576601
<ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 58) (heat: 334)" [High,Triaged]
<apw> pgraner, whos complaining about that one now
<apw> never ever ever buy a new macbook, period.
<pgraner> apw: all the new mac book users
<apw> pgraner, so probabally about 10 people, is it really the highest priority bug we have?
<pgraner> apw: no, basically make sure its liked to upstream and have someone watch it in case a patch shows in the .35 window
<apw> pgraner, i have produced some test kernels in the past which popey ean for me
<apw> yeah it is already upstream
 * popey wakes up
<ogasawara> apw: yah I have a lp script to mark bugs fix committed as I pull patches in.  I should update my credentials to not be the janitor.
<ogasawara> amitk: I'm freezing for A1 on Friday
<ogasawara> amitk: you mentioned you might have something by tomorrow?
<apw> ogasawara, i quite like it i wonder if it should be the norm :)
<ogasawara> apw: cool, I'll leave it as it is then.
<apw> ogasawara, we were wondering about whether we should not go to 35-rc1 should it appear before then, as -rc1 are notorious crack
<ogasawara> cnd: will the multitouch changes you're wanting going to land in 2.6.35-rc1?
<apw> so that A1 has a higher chance of booting
<ogasawara> apw: yah, I'd be worried about rc-1 not booting if I rebased right before A1
<cnd> ogasawara: I would guess so
<amitk> ogasawara: I might have the -omap flavour done by tomorrow
<cnd> ogasawara: let me see if it's been merged already...
<apw> ogasawara, obviously its your call, not sure when -rc1 might drop anyhow
<ogasawara> apw: I'm leaning towards not going with 2.6.35-rc1 even if it lands in time to rebase
<bjf> when will we start producing daily live images for maverick? will that be alpha-1?
<cnd> ogasawara: all the MT stuff that's in Jiri Kosina's HID tree have been merged into 2.6.35
<bjf> "we" as in canonical
<cnd> ogasawara: however, they aren't earth shatteringly awesome, so they can probably wait until you merge -rc1
<ogasawara> cnd: ack
<bjf> apw, thanks for running the irc meeting
<apw> bjf, no worries.  i also wrote up a howto for running the meeting which you might be the right person to read over and correct
<bjf> apw, you didn't read my email to you? i already had a wiki page written up on how to run the meeting
<apw> ahh bottom
<bjf> https://wiki.ubuntu.com/KernelTeam/RunningTheIRCMeeting
<bjf> apw ^
<apw> bjf, mine is basically the same ... so please do zap it and point the link to yours
<bjf> apw, ack
<manjo> JFo, regression meeting yes/no ?
<apw> i note the email addresses arn't quite what you actually send to, you send it to ubuntu-devel and to kernel-team i think
<bjf> apw, will review that
<JFo> manjo, yes and no, we will be discussing possible changes to said meeting
<apw> JFo, sounds good, when ?  
<manjo> JFo, 12cdt ? 
<JFo> little under an hour 
<bjf> apw, i think i switched to ubuntu-platform because my email to ubuntu-devel gets moderated
 * manjo bleeping google calender 
<apw> though ubuntu-platform is an internal list
<JFo> yeah
<bjf> apw, ah
<apw> JFo, so 16:00 UTC ?
<manjo> JFo, my bleeping google calendar says its 2hrs from now 
<JFo> sounds about right
<JFo> manjo, mine could be wrong
<JFo> but I don't think it is
<manjo> why can't google have UTC calendar
<apw> manjo, it does
<apw> you just need to set it into that correctly, the entire calendar
<bjf> msg chanserv op #ubuntu-kernel
<JFo> need a slash :)
<JFo> <-captain obvious
<manjo> apw, I see only GMT in my settings 
<apw> manjo, that is UTC within a few microseconds
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - May-25 - 17:00 UTC
<apw> note GMT does not change in the summer, in the UK we move between GMT and BST (british summer time)
<cnd> JFo: apologies if you've already answered this, but is there a regression review meeting today?
<JFo> cnd, there is
<JFo> we are discussing the changes in the meeting
<cnd> ok
<JFo> in a little over 40 minutes
<cnd> JFo: where are we holding the meeting? (mumble, skype)?
 * apw votes for mumble, jfo you can make a new meeting room
<JFo> mumble shoud be fine
<apw> and infact you already have one
<JFo> :-D
 * JFo is ahead of the curve
<cnd> \o/
<awe> manjo: did the fix for PowerDVD land in an SRU kernel for karmic?
<awe> manjo: i.e. the ironlake buffering issue
<manjo> awe, yes that fix is already in karic 
<manjo> not sure what iron lake is
<awe> could you point me at the commit and/or kernel tag?
<awe> manjo: code name for arrandale integrated graphics
<awe> aka i915
<manjo> awe, karmic commit id is commit 78781dd5db00147ba99bb72eab1e6257b042aec8
<crocket> ubuntu!!!
<manjo> crocket, yeeayy!
<crocket> When I boot 2.6.32 lucid with KMS on, linux dies right after KMS turns on.
<awe> manjo, thanks!!
<crocket> It happens even under recovery mode with KMS on.
<crocket> I have to put "nomodeset" in every grub entry.
<crocket> My graphic card is ATI Mobility X1250.
<amitk> mpoirier: 2.6.34-based omap3 kernel - display and usb works, nand driver broken, but xubuntu works fine. Find it here -> http://people.canonical.com/~amitk/ti/
<crocket> With nomodeset, ubuntu lucid is better than 9.10
<amitk> mpoirier: I'll submit it for upload
<amitk> mpoirier: 2.6.34-based omap3 kernel - display and usb works, nand driver broken, but xubuntu works fine. Find it here -> http://people.canonical.com/~amitk/ti/
<manjo> crocket, yeah some of the older radeon cards have had isses 
<manjo> crocket, kms+compiz support might be flakey on some of the older radeons
<crocket> manjo, 3D games run perfectly fine in windows. I think linux needs much more driver supports than now.
<crocket> I can even run halo 2 in windows vista.
<crocket> manjo, compiz works fine while KMS kills linux.
<manjo> crocket, sure drivers need more work
<crocket> manjo, do you mean I have to buy a new laptop or a new desktop for that?
<crocket> Can I put a new graphic card in my laptop?
<crocket> KMS is the only pain in my ass.
<stenten> The maverick kernel (2.6.35) is planned to include a lot of improvements to the ati drivers. Should be fixed then. For now, it's not really that hard to add "nomodeset" to /etc/default/grub.
<crocket> stenten : I'm sad
<awe> manjo: ping
<manjo> awe, pong
<awe> don't think the referenced bug fixes the issue we saw with powerdvd
<awe> we were testing with the -18.55 kernel
<awe> looks like this commit was much earlier, so should've been included in -18.55
<awe> unless of course the commits for i915 that landed in -18.55 backed this out
<manjo> awe, crap. ok I will take a closer look, but you see the two bugs and they have the exact same errors in dmesg 
<crocket> Until 2.6.32-22, KMS used to kill linux.
<crocket> With linux 2.6.34-020634-generic, KMS doesn't kill linux but doesn't work anyway.
<crocket> I just see a distorted screen before I see a login screen.
<crocket> I should have seen plymouth
<crocket> Would KMS work on 2.6.35?
<crocket> I doubt it
<awe> manjo: don't bother...  the heat has been lowered on this one, as things work fine in lucid
<crocket> It's just 0.0.01 version upgrade.
<manjo> awe, there was a massive backport of s**t from 33 to karmic to fix a lot of these video related problems... 
<anoteng> Anybody familiar with git-bisecting the ubuntu kernel? I suspect I keep producing the same .debs over and over again. Anybody care to take a look at my commands and check if I'm doing something stupid? http://ubuntu.pastebin.com/Rfif04jx
<crocket> manjo, When do I need to use a graphic card sold since?
<awe> manjo: understood...  as I mentioned though, no need to dig any deeper.
<awe> thanks for your help
<crocket> Oops, it is a weird sentence.
<crocket> I don't know how to express it better
<manjo> crocket, can you try the mainline kernel build? http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
<crocket> manjo, Is it newer than 2.6.34-020634-generic?
<manjo> crocket, that is the latest mainline kernel ... and see if that kernel works for you, if it does then 10.10 might have those patches 
<manjo> right it is the latest upstream kernel packaged for ubuntu
<crocket> manjo, do you know a good download manager? FlashGot + cURL are awkward.
<manjo> wget ? 
<crocket> It is also a CLI.
<crocket> I want a GUI application that downloads flash videos easily so that I can use it with FlashGot.
<manjo> crocket, that is question for #ubuntu channel 
<crocket> Gwget and downloader for X hide in traybar readily.
<crocket> ok
<crocket> Jesus I have 4 kernels in my system
<crocket> manjo, mine is amd64 ubuntu
<manjo> crocket, amd64 is generic name for x64 
<manjo> crocket, we follow debian naming convention
<crocket> ubuntu surpassed debian, though.
<crocket> However debian still presents more control.
<manjo> its just legacy naming convention
<crocket> dpkg -i is more convenient than ubuntu GUI package installer when installing more than 2 packages at once.
<crocket> manjo, KMS looks in 2.6.24-999, but linux doesn't die.
<crocket> oops
<crocket> KMS looks worse in 2.6.24-999 than in 2.6.24-020634
<crocket> It means I still need UMS and uvesafb
<crocket> I specified video=1024x768-24 in grub.
<crocket> Should I omit it and try again?
<crocket> manjo!!!
<crocket> manjo, KMS worked briefly after I omitted "video=1024x768" option from grub entry.
<crocket> How can I change the resolution of KMS?
<crocket> plymouth showed for a second on 2.6.34-999.
<crocket> I should try on 2.6.34-020634, too.
<crocket> manjo, plymouth also showed for a second on 2.6.34-020634
<crocket> manjo, are you there?
<manjo> crocket, this is with the lucid kernel ? 
<Sarvatt> crocket: KMS doesn't work on RS600 in lucid, it'll work once 2.6.33.3 or higher drm is merged soon though
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
<ubot2> Launchpad bug 544590 in linux (Ubuntu Lucid) (and 1 other project) "[RS600] video freeze with KMS (X and plymouth) (upstream patches available) (affects: 3) (dups: 1) (heat: 32)" [High,Triaged]
<Sarvatt> i'm guessing you have a dell latitude XT since thats the only machine i've seen that chipset on, AMD pulled it from the market after the merger
<amitk> ogasawara: apw: omap flavour pull request sent
<amitk> mpoirier: ^
<crocket> hmm
<ogasawara> amitk-afk: thanks
<crocket> How can I make KMS appear early?
<crocket> I included "radeon" in /etc/initramfs-tools/modules, but I just see my monitor disconnected from computer for a while.
<Sarvatt> echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash then sudo update-initramfs -u
<Sarvatt> did you see what I said right before you left?
<crocket> Sarvatt : no
<Sarvatt> crocket: KMS doesn't work on RS600 in lucid, it'll work once 2.6.33.3 or higher drm is merged soon though
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
<ubot2> Launchpad bug 544590 in linux (Ubuntu Lucid) (and 1 other project) "[RS600] video freeze with KMS (X and plymouth) (upstream patches available) (affects: 3) (dups: 1) (heat: 32)" [High,Triaged]
<Sarvatt> i'm guessing you have a dell latitude XT since thats the only machine i've seen that chipset on, AMD pulled it from the market after the merger
<crocket> Sarvatt, I use 2.6.34-999 and -020634
<Sarvatt> well I'm just saying why the stock lucid kernel doesn't work :)
<crocket> Sarvatt, I installed linux 2.6.34-999 recently.
<crocket> Sarvatt, It's sudo update-initramfs -u -k all
<crocket> without -k all, initrd only for the most recent kernel is updated.
<crocket> kernel 2.6.34-999 has a bug.
<crocket> During installation of 2.6.34-999, I see this message http://www.pastebin.org/275287.
<JFo> ***Kernel/Tagging has been updated***
<crocket> 2.6.34-020634 doesn't have that weird messages
<crocket> JFo : what?
<JFo> that wasn't for you crocket :)
<amitk> mpoirier: yes, that is the request (omap-mainline for maverick) that I sent to the ML
<amitk> feel free to test it out and comment
<mpoirier> humm...
<mpoirier> what did you do exactly ?
<mpoirier> the same as me ?
<mpoirier> the rebase I mean.
<amitk> mpoirier: no, I took leann's tree and simply enabled the omap3 config
<amitk> we needed it ASAP
<mpoirier> ok
<amitk> Do you have HW now?
<mpoirier> i have a beableboard here next to my computer.
<amitk> cool, so I'll move over some lucid bugs for you to look at :)
<mpoirier> but hold on...
<mpoirier> I understand that leann's tree (maverick) is now enabled on beableboard after your intervention.
<mpoirier> correct ?
<amitk> correct, it will be after leann pulls my patches
<mpoirier> ok...
<mpoirier> So you started with Leann's tree correct ?
<amitk> yes
<mpoirier> interesting.
<mpoirier> I rebased against linus' tree 
<mpoirier> I was lead to beleive ARM was not in Leann's tree.
<mpoirier> Once done, I was going to rebase with Leann's to get the latest and greatest changes for Maverick.
<amitk> errm, what do you mean by "ARM was not in Leann's tree"
<mpoirier> I must have misunderstood something somewhere.
<mpoirier> I has a chat with apw
<jjohansen> mpoirier: perhaps the variety of topic branches?
<mpoirier> He suggested that I rebase ti-omap againts Leann's.
<jjohansen> mpoirier: some are is in leann's tree not all
<mpoirier> again, there must have been a misunderstanding somewhere.
<amitk> mpoirier: nevermind, it was still a good exercise to get familiar with the process (kernel compile, abi, etc.) and the tools (git, etc.). And you are going to maintain this going forward. :)
<mpoirier> well,,
<mpoirier> I'll probably scrap what I have and rebase ti-omap against Leann's.
<mpoirier> as an excercise.
<mpoirier> I will then compare my work with yours.
<mpoirier> unless you have something urgent for me to address.
<amitk> probably not worth it at this point, your time will be better spent making it work well. ATM, there is some flakiness in our USB support
<mpoirier> ATM ?
<amitk> at-the-moment
<mpoirier> ok.
<mpoirier> is the flakiness in Ubuntu code or community ?
<amitk> our configs
<amitk> + possibly upstream code (not sure)
<mpoirier> I assume you have bugs for this ?
<amitk> Just grab the kernel from my people page, and run it on your beagleboard
<amitk> mpoirier: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap
<mpoirier> that shouldn't  take long.
<mpoirier> then what ?
<amitk> mpoirier: feel free to assign to yourself whichever ones you like
<mpoirier> ok, i get it.
<mpoirier> one more thing.
<mpoirier> davidm is sending me some gumsticks ?
<mpoirier> are you aware of this ?
<amitk> no, but good. That way you'll have more that one omap3 platform to test the kernel on
<mpoirier> ok, sounds good.
<amitk> there are lots of people on #ubuntu-arm that want support for various omap3-based boards
<amitk> it might be worth it to see if we can help mainline some of those patches and get better board support
<mpoirier> ok
<mpoirier> I switched to private channel - did you get it ?
<crocket> Hi
<crocket> linux 2.6.34 apparently tries to acquire EDID from a monitor that doesn't exist.
<crocket> http://pastebin.org/275497
<crocket> Read this
<maks_> crocket: irc is not good for bug reporting.
<crocket> where do I report it?
<maks_> launchpad if it is an ubuntu bug
<maks_> upstream if you use vanilla bugzilla.kernel.org
<crocket> It's 2.6.34-020634
<crocket> It's linux kernel
<maks_> whatever this is a dev channel for support go to -> #ubuntu
<ogasawara> bdmurray: can you point us to your bug gravity web pages?
<bdmurray> ogasawara: I stopped running it since bug heat was rather close.  Are you looking for the linux one specifically or something else?
<ogasawara> bdmurray: we were interested in the linux ones, but we thought you had calculated gravity a bit differently than the bug heat.
<bdmurray> ogasawara: some points were assigned based on the reporter for gravity and are not for bug heat
<ogasawara> apw, JFo, cnd, manjo: ^^
<JFo> hmmm, I think that is useful
<bdmurray> Oh and actually bug tags too aren't used by launchpad
<manjo> JFo, we could use that script and add some kernel specific logic to make it work
<JFo> much like our thoughts on commenters.
<JFo> indeed
<JFo> what do you mean bdmurray?
<manjo> bdmurray, what does that mean ? 
<bdmurray> gravity also considered specific bug tags like regression-
<bdmurray> heat does not
<bdmurray> I seem to recall gravity being in arsenal...
<bjf> bdmurray, is there a "gravity" attribute for a bug_task?
<bdmurray> gravity was used on a per bug, not task, basis
<bdmurray> def gravity(self): in arsenal_lib.py
<bjf> bdmurray, don't see a gravity attribute for a bug object either
<bdmurray> bjf: gravity is not the in the API its my thing which bug heat was based on
<bjf> bdmurray, ah, so if we wanted something different, there isn't anywhere in a bug object that we could store a value
<bdmurray> bjf: and arsenal's gravity seems to not check the reporter afaict
<bjf> bdmurray, it's recalculated for each bug each time a script is run
<bdmurray> bjf: yes
 * manjo on coffee break
<jjohansen> -> lunch
<JFo> hmmm, that sounds useful
<bjf> JFo, what sounds useful?
<JFo> apw, I have moved bug reporting bits (both LP and upstream) to https://wiki.ubuntu.com/Kernel/Bugs
<bdmurray> bjf: you could check date_last_updated before calculating the gravity
<JFo> ogasawara, here is what I have in rough form so far: https://wiki.ubuntu.com/Kernel/BugReview
 * ogasawara reads
<JFo> going to step away and think about it for a bit and then come back and do some further cleanup/addition based on my notes
<JFo> that was an initial brain dump
<ogasawara> JFo: cool, I'll jot down any tweaks I might see
<ogasawara> JFo: at least run them by you before editing
<JFo> k, sounds good
 * JFo goes to get some water
<ogasawara> JFo: looks good as an initial start.  I'm sure you'll add more bits about what level 1, 2, 3 triage is and also maybe mention the bug load (ie when we go over 50 bugs) and how we may then use that as leverage to get more people working on bugs.
<JFo> yep
<ogasawara> JFo: should probably work in that link to the Tags page you had
<ogasawara> JFo: but looks good so far
<JFo> cool, thanks for looking
<ogasawara> JFo: I'm happy to do a second pass of it later, just ping me
<JFo> ogasawara, will do :)
<apw> jfo yeah i think it might make sense to have three sections one per triage level listing the things-to-do in each phase
<JFo> apw, yep, it is in the plan
<JFo> also want to do a further definition of each tag so that we can explain a bit further what is covered by a tag like kernel-core
 * ogasawara breaks for lunch
 * JFo noshes chips and salsa and gets it all over his keyboard
 * apw discovers he has done 5 hours of builds, and they are all wrong :/
<apw> JFo, you need a keyboard hoover, as do i
<JFo> indeed
<JFo> :-/
<JFo> ogasawara, I just remembered (from looking at my notes) that James Westby(?) asked if we want kernel oops turned back on?
<JFo> I meant to ask you that at UDS
 * JFo failed
<JFo> apw, ogasawara, here is the rough guide to Triage levels: https://wiki.ubuntu.com/Kernel/TriageLevels
<JFo> very brief, but can be added to
<JFo> I've also made some changes to the https://wiki.ubuntu.com/Kernel/BugTriage initial paragraphs to draw attention to a few of these pages
<apw> JFo, looks good, rough but has the right info ... good one
<JFo> cool
<JFo> apw, just put the header bar in and all
<JFo> so it looks a bit better
<apw> jfo coming together... i think we need a triage icon ...
<apw> will see if i can find something
<JFo> k
<apw> i think its important enough to have its own 'space'
<JFo> I agree
<JFo> and it will only grow, I'm afraid
<JFo> btw all, I am currently expiring bugs. apologies for the strain on your bugmail
<jjohansen> JFo: no apologies needed for expiring bugs
<JFo> heh
<bjf> JFo, sweet, they are starting to roll in
<JFo> yep, I like the verbose output too bjf 
<JFo> it is very informative
<bjf> JFo, i'm guessing you'll expire about 3500 from this first pass
<JFo> I suspect that as well
<JFo> at least that i mean :)
<apw> JFo, how does https://wiki.ubuntu.com/Kernel/ look
<JFo> love it
<JFo> my little bug :-)
 * amitk checks what changed...
<apw> i think they are in the wrong order, my mind says 'debug', 'triage', 'development', 'advanced' but that'll do for today
<apw> amitk, look at the menubar
<JFo> I see what you mean apw
<JFo> we can fix tomorrow
<amitk> aah, you added bug triage
<apw> yeah it is becoming pretty big area now
<bjf> apw, you may not need "Ubuntu Kernel Main" on the main page (but maybe you're going for consistency)
<amitk> bjf: it is a single menubar used across all pages
<bjf> amitk, ah
<akgraner> bjf, ping a ling a ling
<bjf> akgraner, pong
<bjf> akgraner, what can I do for your highness?
<akgraner> you write up your weekly kernel meetigns right?
<bjf> akgraner, correct
<akgraner> bjf, hehe
<akgraner> bjf, where all do you send those minutes?
<akgraner> I think the news team isn't picking it up
<akgraner> and I want to make sure it makes it to the right places
<bjf> akgraner, I send to the kernel team public mailing list and another internal list as well as posting them to: http://voices.canonical.com/kernelteam/
<apw> JFo, ok reordered them
<JFo> cool
<bjf> akgraner, however i'm having "issues" with the voices blog
<akgraner> bjf, ahh ok :-) I will make sure to snag them from the kernel ML then
<akgraner> :-)
<apw> bjf, i did not post last weeks to voices correctly
<apw> (or indeed at all)
<bjf> apw, no worries, no body reads it anyway :-)
<apw> :)
<apw> if its like my googley one, then you can backdate stuff anyhow
<JFo> ogasawara, do you still want to use the 'bitesize' and 'cherry-pick' tags?
<JFo> I have not been
<JFo> but i can
<amitk> apw: now the menubar should look much prettier (OCD!)
<akgraner> I love the new look of your wikis :-)
<amitk> akgraner: we should make it pink
<bjf> amitk, purple
<akgraner> purple
 * akgraner loves purple
<akgraner> amitk, did you see the NC wikis - Carolina Blue there :-)
<amitk> bjf: no brad, pink. we want to attract more women to ubuntu development :)
<akgraner> amitk, me sends a virtual kick your way! :-P
<amitk> ouch
<bjf> amitk, how can I properly respond to that without getting in trouble?
<akgraner> hehe :-)
<akgraner> you all rock - I love wikis so let me know if I can help ya - I can't write content, but I'll help where ever else I can
<JFo> akgraner, I may get you to look at the stuff I am working up 
<JFo> it would be a review from a user standpoint, but I welcome construction or setup fixes/suggestions too
<akgraner> JFo, just ping me..
<JFo> k
<JFo> pgraner, apologies for the delay, maverick-bug-handling is now pending approval
<JFo> all I can say is GOOD LORD!! bug 88746
<ubot2> Launchpad bug 88746 in linux (Fedora) (and 14 other projects) "ehci_hcd module causes I/O errors in USB 2.0 devices (affects: 64) (dups: 17) (heat: 620)" [Unknown,Invalid] https://launchpad.net/bugs/88746
<JFo> there are 500+ comments on that bug
<ogasawara> JFo: good luck with that one.  I think I tried killing it 3 times and then gave up.
 * JFo eyes WontFix :)
<JFo> the fun part will be getting it open with LP timeouts
 * JFo disables redirection
<JFo> ... and waits
<manjo> bjf, how did you get channel ops ? 
<bjf> god blessed me
<bjf> manjo, it's so i can change the channel topic, no other reason
<manjo> :)
 * JFo admires bjf's hat
<manjo> JFo, hat ? 
<bjf> JFo, ?
<JFo> ops hat
<manjo> oops hat ? 
<JFo> ops as in channel operations
<bjf> JFo, i'm trying right now how to take the hat back off
<JFo> heh
<JFo> think it is deop bjf 
<JFo> not sure though
<bjf> JFo, thanks
<JFo> np :)
<manjo> mumble sounds like we are in the same room... its fantastic!
<bjf> sometimes i'm such a curmudgeon that I even amaze myself
 * manjo looks up  curmudgeon
<bjf> manjo, you'll see my picture :-)
<manjo> bjf, I think " a crusty, ill-tempered, and usually old man " role is already taken 
<JFo> by bjf happily
<JFo> vanhoof, did you and I discuss bug 564984 before?
<ubot2> Launchpad bug 564984 in linux (Ubuntu) "r8169 fails to autonegotiate speed/duplex (affects: 5) (heat: 30)" [High,Triaged] https://launchpad.net/bugs/564984
 * manjo looks around and thinks he needs some food 
<bjf> ogasawara, that audio patch has not made it upstream, I'm inquiring why not
<ogasawara> bjf: ok thanks
<JFo> cnd, you hear from Jerone on bug 581312?
<ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/581312
<ogasawara> bjf: I'll add a note to that affect to the wiki, and mark your follow up as DONE
<bjf> ogasawara, ok, will let you know what I find out
<vanhoof> JFo: dont think so
<vanhoof> JFo: on a call atm
<JFo> k
<JFo> no sweat
 * achiang wonders if this tool might be helpful to folks: https://launchpad.net/laika
<JFo> just noticed it was assigned to me from QA
<JFo> achiang, not for me, that list would be huge
<achiang> JFo: yeah, i think you're an extreme edge case. most normal people aren't touching thousands of bugs every week. ;)
<JFo> heh
<achiang> JFo: although, if you can think of a way to make that script interesting for you, let me know.
<JFo> jjohansen, is OSCON at the same time as platform sprint/
<JFo> achiang, will do
<achiang> JFo: maybe there's a more intelligent way to slice the data rather than dumbly just saying, "durrr what did i touch?"
<JFo> maybe, but it will require a bit of thought
<jjohansen> JFo: yeah
<JFo> sucks
<jjohansen> JFo: July 19-23
<JFo> I thought so
<JFo> I'm debating not going to OLS since it would be that weekend before it looks like
<bjf> achiang, does your script use the launchpad api?
<achiang> bjf: yeah
<achiang> bjf: it's slow and probably buggy, but it's in the 'works for me' stage
<bjf> achiang, we do a lot of lpapi scripts, i'm looking at yours
<achiang> bjf: cool. i was pointed to bughugger earlier, but that doesn't really do what i want
<achiang> bjf: also, apologies in advance. i'm a C hacker, not a python guy, so i'm sorry if i make your eyes bleed
<bjf> achiang, np, i do both
 * JFo takes off for the day
<achiang> bjf: sample output: http://pastebin.ubuntu.com/439082/
<ogasawara> jjohansen: just want to re-touch bases with you. . . when 2.6.35-rc1 drops and I rebase, I'm gonna basically drop the apparmour patches we're currently carrying and go with what's upstream.  you'll then send me an updated pull-request with anything additional that we need correct?
<jjohansen> ogasawara: yeah, since AA isn't upstream it will be the AA version I am trying to push up stream
<ogasawara> jjohansen: ack
<jjohansen>  plus the compatibility patches I am currently revising
<jjohansen> ogasawara: when are you expecting to rebase?
<ogasawara> jjohansen: even if -rc1 drops before the Alpha1 freeze I'm thinking I don't want to push an rc1 kernel for Alpha1, because I'm worried it wouldn't boot for some.
<jjohansen> right
<ogasawara> jjohansen: so I'll likely rebase after Alpha1, and we can make this an Alpha2 work item
<jjohansen> sounds good
<jjohansen> ogasawara: also if you want I can't take pull your maverick rebase and drop the AA patches on it so you have pull requests against maverick instead of upstream, what ever is easiest for you
<ogasawara> jjohansen: yah, pull request against maverick would be easier for me if it's not too much trouble for you
<jjohansen> ogasawara: nope I'll be happy to do it
<ogasawara> jjohansen: awesome, thanks.  I'll let you know when I've rebased to 2.6.35-rc1
#ubuntu-kernel 2010-05-25
<kees> ogasawara: is aufs supposed to work in the .34 kernels?
<ogasawara> kees: I'd assume it should, we haven't touched it
<kees> ogasawara: hrm, it is misbehaving.  I will dig further and file an actual bug report.  :)
<ogasawara> kees: thanks. can you ping me or JFo with the bug # once you have it.
 * kees has to figure out how to use it in a non-schroot context first.  :)
 * bjf taking off for a bit
<kees> jjohansen: (from the other channel) yeah, aufs is in there, and it seems that manual usage works.  schroot doing it results in weird states... /me tries some more
<jjohansen> kees: yeah I know aufs is there, /me just wasn't sure if it needed updating to have it work properly on .34
<kees> # umount /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0
<kees> umount: /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0: device is busy.
<kees> fuser says:
<kees>                      USER        PID ACCESS COMMAND
<kees> /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0:
<kees>                      root     kernel mount /var/lib/schroot/mount/maverick-i386-58acab8c-28d3-4044-994a-403cc650acc0
<kees> no clue what that's about.
<vanhoof> JFo: yo
<vanhoof> back now
<vanhoof> JFo: on that bug, you looking for a home for it?
<kees> OH... getting kernel Oops.  hah.
<kees> [  360.979217] kernel BUG at /build/buildd/linux-2.6.34/ubuntu/aufs/f_op.c:84!
<jjohansen> kees: sadly not surprising
<kees> jjohansen: and aufs isn't upstream, right?
<jjohansen> correct
<jjohansen> and it never will be
<jjohansen> kees: that is one of the reasons we are reevaluating union mounts this cycle
<jjohansen> they look like they might finally go upstream soon
<kees> right, cool.  in the meantime, I've filed bug 585175
<ubot2> Launchpad bug 585175 in linux (Ubuntu) "kernel BUG at /build/buildd/linux-2.6.34/ubuntu/aufs/f_op.c:84! (affects: 1)" [Undecided,New] https://launchpad.net/bugs/585175
<lag> Morning :)
<cooloney> lag: good morning
<lag> cooloney: Hi ya
 * apw waves
<apw> smb, morning
<amitk> morning gentemen
<smb> apw, Morning
<smb> amitk, dito
<apw> moin amitk 
<cking> morning
<ikepanhc> good morning .eu
<smb> cking, Youare required to log in to mumble
<apw> moin .ap
<cking> smb, ok - firing up
<lag> Morning everyone
<jk-> hey peeps
<jk-> cnd: how come your mumble icons (muted & deafened) have blue crosses instead of red ones?
<jk-> oh, muted & deafened by the server?
<apw> jk-, muted by me instead
<jk-> ah
<ikepanhc> eh, is there any update on mumble server?
<apw> ikepanhc, shoul 
<apw> s
<apw> ikepanhc, should be working
<ikepanhc> apw: server tells me wrong password..
<apw> ikepanhc, the username is changed to be your launchpad accounts email address
<apw> note i said email address
<ikepanhc> apw: trying, thanks
<cooloney> smb: just sent you an email for omap4 branch in lucid
<smb> cooloney, No, actually you sent ogasawara that mail. I am not looking at things without a release in the topic that I care
<smb> cooloney, Darn
<smb> You had it at the end. I am not reading that far at that time of the day
<cooloney> smb: i did not send git pull email to ogasawara 
<cooloney> smb: i think amitk sent that for adding omap flavor in Maverick
<cooloney> smb: but mine is for adding omap4 branch in Lucid
<smb> cooloney, I was just bitching about not having a [Lucid][pull request]
<smb> cooloney, Is that a new topic branch or should replace the current ti-omap?
<cooloney> smb: ok, next time i will take care of that.
<cooloney> smb: oh, it is a new branch 
<cooloney> smb: won't replace ti-omap
 * apw watches smb cry
 * smb looks for something to strangle cooloney 
<apw> cooloney, whats its base version ?
<smb> .33 it seems
<cooloney> since ti-omap for omap3 machine
<cooloney> yeah, .33
<cooloney> apw: ^^
<amitk> cooloney: call it ti-omap4 (or something)
<smb> amitk, he has
<cooloney> yeah, it is ti-omap4
<apw> was ti-omap a .33 kernel too ?
<amitk> yes
<smb> amitk, Just that I am so very happy to take in yet another topic branch that needs care
<cooloney> rihgt.
<apw> smb, you can't take it till someone handles the MIR
<amitk> smb: I'm sure you are (Father Hen counting his chickens)
<apw> and the FFE, and all the other paperwork
<smb> cooloney, amitk Can't you guys get one tree per manufacturer
<amitk> smb: someday (hopefully before I lose all my hair)
<cooloney> smb: it is difficult. so we created 2 branches
<cooloney> even ti has 2 different git tree
<smb> cooloney, It is difficult to manage so maybe I just not take it...
<apw> just because they cannot maintain a tree doesn't make it right
<amitk> apw: they're working on it, we expect to have a single tree for M+1 for TI
<amitk> and with luck, it will all be in 'master'
<cooloney> right.
<cooloney> as amitk said, we are going to make M has omap flavor in master branch
<cooloney> and omap4 branch for those patches from ti but not in mainlien
<cooloney> but for lucid, i do think we can put them together easily
<cooloney> i don't think, sorry
<cooloney> smb: this lucid omap4 branch is for TI 10.07 release.
<amitk> smb: it only has to be supported until Jan
<cooloney> because of the time frame, i picked up our lucid code base for that release
<smb> cooloney, amitk I am _very_ reluctant about adding anything to the official repo just based on a pull request
 * apw wonders if amitk knows quite how far away january is
<cooloney> apw: yeah, it is july
<amitk> smb: apw: Perhaps, this isn't very clear, but cooloney doesn't want you to spin new kernels, the binary packages will be done in a PPA. He just wants the git tree in a single place.
<amitk> (in a branch)
<cooloney> amitk: right, that's point
<smb> amitk, Well it will be in the repo. And we were given trees like that before and suddenly there is need to put in security fixes and other generic fixes. And so it is suddenly a bunch of additional work
<smb> amitk, cooloney So I want something more official than just "here, pull it"
<amitk> ok
<amitk> cooloney: ask davidm to send email to u-k mailing list outlining the support requirements for this tree (which should be none)
<cooloney> amitk: ok, looks like i don't have any other choice, -:|
<apw> amitk, what is the support requirement on ti-omap itself ?
<amitk> apw: I'd like to say "standard release - 18months", but you should confirm with davidm
<amitk> 10.07 is a special release for TI, so they can ship ubuntu on their new HW. And we throw it away once omap4 is a first class citizen in maverick.
<smb> amitk, I hope you are aware that ti-omap currently will receive no stable updates. I have no common base for that and I do not apply .33 patches
<cooloney> apw and smb, i have to say the ti-omap4 is very special, so I would talk to guys eariler about that.
<smb> cooloney, That would have been a good idea
<amitk> smb: understood
<lag> Who is responsible for the filesystem in Ubuntu? 
<cooloney> lag: i guess it surhbi's area? but she is sick today.
<lag> cooloney: Thanks. 
<apw> smb that is the range right: 332d90de3fa1254dd49c71882e407a169efddb9e..8eb93181b49f13e241970c358be254d4df9c2419
<apw> Linux-2.6.32.11+drm33.2 -> Linux 2.6.32.12+drm33.3
<smb> c4176d0557f28a68846aa7de10197aed3d5f78a2..8eb93181b49f13e241970c358be254d4df9c2419
<smb> apw, You want to start were I branched
<smb> apw, That stable branch is based on last released lucid and has other things since then
<apw> 183, phew that sounds better <- smb
<smb> apw, Right, given that there are quite a few patches skipped compared to upstream (or replaced)
<smb> apw, Note, that I currently skipped the EC changes as we still have a slightly different approach there
<apw> ok
<lag> What are the different numbers called in linux version? I.e. 2.6.32-21.1 
<lag> Something like this perhaps? "version.series.release-abi-minor-flavour"
<ikepanhc> cooloney: do you know we shall use -march=armv7a or -march=armv7-a on lucid fsl-imx51 kernel?
<ikepanhc> seems cross compiler use v7-a...
<ikepanhc> but I dont know how about the native compiler
<cooloney> -march=armv7-a when i'm doing cross compiling
<ikepanhc> and armv7a for native compiler?
<cooloney> i never try on native compiler
<ikepanhc> I mean build server
<cooloney> right, i think it is the same
<cooloney> arch/arm/Makefile
<cooloney> arch-$(CONFIG_CPU_32v7)         :=-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
<cooloney> the CFLAGS is set in kernel Makefile
<ikepanhc> so, we shall use v7-a, not v7a?
<cooloney> yeah, v7-a not v7a
<ikepanhc> oh, I saw that, a freescale patch modify it. so I need to revert it, thanks
<cooloney> cool. i almost remember that patch, they wanna compile the kernel with old toolchain. 
<cooloney> so they modified that, 
<ikepanhc> ya, that's it
<lag> amitk: Is there a better way to push local/branch -> remote/branch than "git push <remote> HEAD" when the remote branch is currently checked out?
<amitk> lag: is the remote tree on zinc?
<lag> No, it's on a build-server
<lag> And has a working tree
<amitk> lag: I assume you have ssh access to that machine
<lag> When I do "git push <remote> HEAD", I receive a warning about the branch being checked out and I have to do a reset followed by a checkout on each of the remote branches
<lag> Yes
<amitk> in which case, have you setup you .git/config to push using ssh?
<lag> If that's the way to do it, then fine. I just thought there may be a better way
<amitk> [remote "zinc"] url = ssh://amitk@zinc.ubuntu.com/srv/kernel.ubuntu.com/git/amitk/maverick.git
<lag> Yes, I've done that
<lag> That's how my push works
<amitk> ok
<amitk> git push <branch name> should work
<lag> It's happy to do it, but because the branch is checked out on the remote server (as that's where I'm building), it complains 
<lag> Okay, I'll give it a go
<lag> Sounds simple enough
<amitk> perhaps I haven't understood the real problem, re-reading...
<lag> Same warning
<lag> warning: updating the current branch
<lag> warning: Updating the currently checked out branch may cause confusion,
<lag> warning: as the index and work tree do not reflect changes that are in HEAD.
<lag> warning: As a result, you may see the changes you just pushed into it
<lag> warning: reverted when you run 'git diff' over there, and you may want
<lag> warning: to run 'git reset --hard' before starting to work to recover.
<hrw> hi
<ogra> just use bzr 
 * ogra hides
<hrw> ogra: ;d
<ogra> hmm, was possibly not the best idea to make a bad joke right before asking the kernel team for a favour :P
<ogra> so hrw and me are here to make a feature request ... 
<amitk> lag: hmm, never see that
<ogra> we would like to autospawn a getty on serial consoles if console=ttyS,... is set
<amitk> ogra: Denied!
<ogra> for that hrw created an upstrat script we showed Keybuk for possible upstart upstream inclusion
 * abogani waves
<abogani> Please don't forget me https://lists.ubuntu.com/archives/kernel-team/2010-May/010707.html :-)
<hrw> ogra forgot to mention that enabling of autogetty has to be done by user first
<lag> amitk: Do you use build servers?
 * amitk points ogra, hrw to apw, ogasawara 
<amitk> lag: on occassion
<lag> I edit on my local machine, then push to my remote one (on the build server)
<ogra> during discussion Keybuk pointed out that the script would better operate on a kernel event i.e. in a way that you can use "start on" if the actual device is existent 
<amitk> ogra: possibly best to write email to the mail list
<ogra> currently the kernel doesnt expose such an event and we would need it to be added
<ogra> amitk, hmm, yeah, probably better
<amitk> lag: I only use bare repos to push stuff to
<amitk> lag: never done it with a 'checked-out' repo on the remote side
<lag> Okay
<lag> I think here lies my problem :)
<amitk> lag: you could setup a bare repo to push to and then clone it and checkout
<apw> lag, whats the issue?  i use non-bare upstreams commonly to build in
<Keybuk> ogra: not expose an event so much, as expose the value of console= ;-)
<ogra> Keybuk, indeed 
<Keybuk> we have the events anyway, we just don't know whether or not ttyS0 is the console
<ogra> but you wanted an even too for "start on", no ? 
<Keybuk> we have the event
<ogra> ah, k
<Keybuk> we want the "is ttyS0 the console" test in a form that is useful
<Keybuk> either as a payload to the event
<lag> apw: Look up
<Keybuk> or $console as environment variables or command-line arguments to init
<ogra> Keybuk, note that a serial console can have pleanty of names :)
<ogra> the only indicator we have is that its not tty[0-9]
<apw> lag, all it says is you push and build ... what am i to make from that, other than good
<ogra> everything with a letter is serial
<persia> But not everything that is serial is a console
<hrw> yep
<ogra> persia, i think we can safely assume that everything added to the console= cmdline option is a console ;)
<persia> Fair :)
<lag> apw: When I push it complains
<apw> did you read the complaint ?
<apw> and take the action it proscribed ?
<ogra> so we want both, the event (as Keybuk says that already exists) and handing over console= to upstart
<apw> if you set the thing it whines about to ignore, then you can do it
<ogra> the prob here is that you will likely have multiple console= args 
<lag> apw: It says that as the remote branch is checked out there will be issues
<apw> lag, as we discussed you have to push, then git checkout -f branch on the remote side before building
<apw> the 'issue' is the head and the working tree will not match
<lag> apw: When I do the push, I have to do a 'git reset' and 'git checkout <file>' for it to act sane again
<apw> the fix is to check it out
<apw> you should just have to git checkout -f <branch>
<lag> Every time?
<apw> every single time you push yes
<lag> That's annoying!
<apw> remember the push stuff is repository level
<apw> the working directory is not there
<apw> and not synced, hence the whine
<apw> but as you have to go to the copy to compile it you can simply make it part of your tooling
<lag> Okay
<apw> both smb and my tooling do that
<amitk> kteam-tools?
<lag> They do, but I'm not building just yet
<lag> As long as that's the definitive answer, I'm happy
 * smb sees a lot of stuff in the srollback
<smb> lag, apw I am not sure I could catch the problem and the answer exactly when skipping through the scrollback
<smb> lag, Is it the complaint about pushing to a checked out branch?
<lag> smb: Correct
<apw> yep
<lag> smb: I've been educated by apw to do a 'git checkout -f' on the remote to solve
<apw> you need a new variable set.  once set you already do the right thing by checking out -f 
<smb> lag, Ah yeah, so at the moment its a warning. Or you do what it tells you and set the variable
<smb> Long term the scripts should do that
<smb> Oh, it changed to an error with lucids version of git?
<lag> It's just a warning with mine
<smb> I believe the rune on the remote side was "git config receive.denyCurrentbranch ignore"
<lag> [receive]
<lag> 	denyCurrentbranch = ignore
<smb> So that is now set
<lag> Yup :)
<amitk> apw: was there a W-I for the omap-mainline kernel for maverick?
<apw> not that i've seen though there should be
<amitk> apw: it should probably be 2-3 W-I (given it wasn't a 2hr job)
<apw> a work item is meant to be a 2-3 day effort, but if you need one thats smaller then you need it, if it bigger then it should be split a bit
<amitk> apw: aah, for some reason i thought it was a 2-4hr effort
<amitk> where should it be added?
<amitk> what spec, I mean
<apw> its a new flavour right?  we discussed those on config-review i think, the remove -preempt should be on it
<amitk> new flavour, yes
<persia> Remove -preempt?  I thought the plan was only to split out -preempt into a separate package.
<cnd> smb: care to unmute and undeafen me?
 * ogra wonders why his touchbook kernel has a mailbox
<ogra> is that an addition to the in kernel httpd ? :)
<ogra> oh, hm, "interrupt driven messaging"
<amitk> ogra: are you referring to omap mailbox?
<ogra> yeah, never heard of it 
<ogra> i just saw the module in lsmod :)
<amitk> among other things it is used by the dspbridge
<abogani> Do you have some thought about https://lists.ubuntu.com/archives/kernel-team/2010-May/010707.html ?
<apw> abogani, not had a chance to look at it yet.  doing stable reviews first
<abogani> apw: Ok. Thanks in advance.
 * JFo yawns
<pgraner> JFo: yea keep yawning while you blow up my imap server... dude seriously?
<JFo> :-D
 * JFo has more mail for you today oh captain, my captain!
<pgraner> JFo: good thing this ain't like the the postoffice where you get charged by the piece....
<JFo> indeed :-/
<JFo> i can't imagine what the bill would be for all of this
<JFo> but I know i wouldn't want to pay it
<JFo> :0
<tgardner> JFo, are you filling my bug box? I haven't checked this AM yet
<JFo> tgardner, I am
<JFo> i am spreading the love to all with my bug expiration mails
<pgraner> tgardner: hope you have a fast connection to your mail server, he hit me with over 1k messages in bug spam
<JFo> and that is just for the expiring ones :)
<tgardner> maybe thats why it felt so slow earlier this morning. it took forever to get my inbox stuff.
<pgraner> JFo: you have my fetchmail process breathing hard, its never done that much work
<JFo> heh
<JFo> so pgraner, looks like I had the wrong objectives but alice has fixed them.
<JFo> they need your sign off so I can fix them up
<pgraner> JFo: ok give me 5
<JFo> k, thanks
<JFo> apw, in the grand tagging scheme, where would bug 324894 fit
<ubot2> Launchpad bug 324894 in linux (Ubuntu) ""Corrupted low memory at" kernel warning on resume (affects: 25) (dups: 6) (heat: 188)" [Medium,Triaged] https://launchpad.net/bugs/324894
<JFo> just wondering whenever you have time to look
<JFo> my money is on acpi maybe
<manjo> JFo, that bug can be quirked, but they need to send me the dmidecode info
<manjo> the quirk is in the core kernel 
<JFo> which manjo ?
<JFo> the one here or some other?
<manjo> jfo Corrupted low memory at
<JFo> ah
<manjo> JFo,  Corrupted low memory at
<apw> JFo, i would put it in kernel-core .. its biosy ick
<apw> what manjo said
<manjo> JFo, this one is a diff one from what I was looking at, but basically the same bug, like apw said bios issues, quirk is in the kernel 
<smb> apw, Dude, I wonder who is madder of the two of us. You doing all the 180 plus writing or me. But thanks! :)
<JFo> apw, k
<apw> smb, you made the t-shirt, who looked madder there ... i think its a draw
<apw> smb, i need a lie down i thkink
<smb> apw, It surely is. And yes I think you would have earned it
<JFo> vanhoof, yeah, I need a home for it
<amitk> mpoirier: you have new booogs assigned to you
<mpoirier> yes, just saw - thanks
<amitk> mpoirier: were you able to run my kernel?
<mpoirier> indeed but your .deb died in userspace.
<mpoirier> it could find the sd card.
<mpoirier> I check-out your tree
<mpoirier> recompiled and it all worked properly.
<mpoirier> i did not look for specific bugs/error
<amitk> ok
<JFo> look out for all the boogs!!!
 * JFo goes for coffee to escape the boogs
 * cking wrestles with evolutions junk filters
<amitk> ogasawara: will there be any more uploads before alpha-1, or just the one?
<tgardner> amitk, I was gonna ask her why she hasn't already uploaded. there are a pile of changes in  the pipe
<smb> apw, Hm I guess you have done ti-omap and qcm-msm uploads sort of recently. Should ti-omap have a orig.tar.gz?
<amitk> tgardner: I see that you'll press her to do it. My job here is done :)
<tgardner> amitk, yeah, I'll annoy her when she shows up this morning.
<smb> apw, Probably could only be a raw linus-2.6.33 tarball
<apw> smb, it should have had one, though i have the feeling i was remis in providing that one
<smb> apw, There is nothing on archive.ubuntu.com, but so I try whether it works with one
<bjf> moin all
<apw> smb, you can inject one at any time
<apw> bjf, moin
<smb> apw, Yeah, just sometimes the build explodes when you do it cause they need executable things or ...
<smb> but I will try
 * smb grows several new gray hairs over the lucid rebase mess
<apw> smb, i see, i think ti-omap is mostly upstream so the risk is lower than normal for an ARM nightmare branch
<smb> apw, Its mostly keeping 3 kernel versions and 6 topic branches somehow in memory without getting too confused
<ogasawara> amitk: was planning to upload this morning, just had one extra question for you before I do
<apw> yeah i have a checklist
<ogasawara> amitk: you mentioned you purposely didn't run updateconfigs after doing the -omap flavour
<ogasawara> amitk: I'm gonna have to run updateconfigs for other bits when I rebase, do you prefer that -omap config not be touched?
<tgardner> ogasawara, what I think he meant is that it will be easier for you to do it at the time of integration
<smb> apw, Mine is still brain based. That sort of worked before Lucid but I think this needs some external list now...
<apw> smb, ogasawara, the checklist i used for lucid development is on chinstrap in ~apw/CHECKLIST
<apw> you can see the form i used
<ogasawara> apw: thanks
<apw> smb, though if you put that together with all the releases on it you may kill self
<smb> apw, thanks. I will try anyway. Better that than try to keep all in mind
<bjf> ##
<bjf> ## Kernel team meeting today @ 17:00 UTC
<bjf> ##
<bjf> JFo, didn't see as many expired emails as I was expecting
<JFo> yeah, the script fell over on one
<JFo> but I am running it again so I can see what happens
<JFo> more expring now
<bjf> ogasawara, do you have a list of active blueprints that we should be reviewing in the irc meeting?
<ogasawara> bjf: primarily this is what I'm using for Alpha1 https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone maverick-alpha-1
<bjf> ogasawara, that's quite the list, i'll work on getting it into the meeting
<ogasawara> bjf: I was gonna mention it during the Maverick Release Status
<ogasawara> bjf: and remind those who still have open items
<bjf> ogasawara, so you want to do them all as a single meeting topic or do you want me to break them out as one blueprint per topic like before?
<ogasawara> bjf: actually, one blueprint topic like before might be good for accountability
<bjf> ogasawara, i'll work on that now
<ogasawara> bjf: thanks
<ogasawara> smb: just a heads up, the security-m-kernel-hardening blueprint had a work item of "review and consider security hardening patches for Stable Releases" but it was assigned to canonical-kernel-team
<ogasawara> smb: so I reassigned to you specifically else it'd likely get ignored
<smb> ogasawara, Ok, thanks. I saw it in the mail lp sent out when you changed it
<ogasawara> smb: it's currently an Alpha1 work item, but feel free to bump to Alpha2 if you haven't time to review before Alpha1
<ogasawara> smb: I realize I sorta dumped it to you last minute
<smb> ogasawara, Remind me when is alpha1? something june?
<ogasawara> smb: next Thurs, june 1
<smb> ogasawara, joy. :-P
<JFo> what the heck is pwmconfig? bug 475641
<ubot2> Launchpad bug 475641 in linux (Ubuntu) "pwmconfig does not work after upgrade to 9.10 on TYAN server (affects: 2) (heat: 12)" [Undecided,Triaged] https://launchpad.net/bugs/475641
<tgardner> ogasawara, I'm currently looking at the ptrace hack from kees
<ogasawara> smb: make that June 3, not june 1
<bjf> JFo, power management config
<JFo> ah hah
<ogasawara> tgardner: any thoughts yet?
<JFo> I was hoping it was that
<smb> ogasawara, two more day then :)
<tgardner> nah, still have to noodle around with it. I'll get to it this afternoon
<JFo> that the bug from last night tgardner?
<tgardner> JFo, dunno. what bug?
<smb> tgardner, let me know what you think, too. Somehow I remember two were sort of ok'ish and one was scary
<JFo> bug 585175
<ubot2> Launchpad bug 585175 in linux (Ubuntu) "kernel BUG at /build/buildd/linux-2.6.34/ubuntu/aufs/f_op.c:84! (affects: 1) (heat: 6)" [Undecided,Triaged] https://launchpad.net/bugs/585175
<tgardner> smb, I've already reviewd and ack'd the first 2
<JFo> ogasawara, ^^ that is the one kees filed last night
<smb> tgardner, Cannot remember which one was which. But I think the hardlink thing was something scary
<tgardner> smb, hardlink/softlink was straightforward and testable
<smb> tgardner, Hm from my memory hardlink might have some side effects. But testable could be
<tgardner> JFo, different bug
<ogasawara> JFo: can I add that to our 50 to review/discuss?  I know there is a new aufs we can update to but we're holding off on it till we finish the union mounts evaluation as an alternative to aufs
<JFo> ogasawara, you may indeed
 * JFo makes a note
<ogasawara> JFo: not that I'm sure the newer aufs would resolve it...
<tgardner> it'll just add new and different bugs
<JFo> ogasawara, it is on my paper list to add
<ogasawara> JFo: I'm still cleaning up the KernelBuglist script, I keep getting side tracked
<JFo> k, no sweat
<JFo> too much to do
<bjf> ##
<bjf> ## Kernel team meeting in 25 minutes
<bjf> ##
 * tgardner wonders what timezone in which bjf exists
<tgardner> bjf, never mind. can't read
<smb> Hm 17UTC is a bit more than 25 mins away in my world
<bjf> smb, according to my 'puter it will be 5:00 p.m. in london in 22 minutes, is that not 17:00 utc?
<smb> bjf, no london has daylight savings too
<bjf> smb, they switched to BST didn't they
<bjf> so that would be in 1 hr and 20 minutes then
<smb> yep I think so
<smb> cking, apw ?
<ogasawara> $ date --utc
<ogasawara> Tue May 25 15:40:32 UTC 2010
<ogasawara> I'm seeing 1hr 20min
<bjf> ##
<bjf> ## Kernel team meeting in 1 hour and 20 minutes  (time correction)
<bjf> ##
<apw> bjf, do you have the list of blueprints you will be asking about yet as the agenda just has the 'NEEDS LIST' in it
<bjf> apw, working on it, will update in 3 minutes
<JFo> I have a list of them bjf
<bjf> JFo, me too, i'll put mine on the meeting page and we can compare notes
<JFo> ah
<JFo> just blasted them to you in pw :-/
<JFo> will check the meeting page
<amitk> ogasawara: what tgardner said (regarding updateconfigs). Run it now that the patch is integrated.
<ogasawara> amitk: ack
<tgardner> apw, what was the reasoning for creating a new PPA for the LTS backports? Whats wrong with just using the well known kernel-ppa ?
<apw> tgardner, none if that PPA is not being used for anything
<bjf> apw, ogasawara, JFo, blueprint list on meeting page, let me know if you want more added, i just put on the ones with A-1 deliverables
<JFo> k
<apw> nominally i would use a named PPA for such a specific thing though
<tgardner> acht pht
<lag> Does anyone know what this means: <directory>/*[!~]
<bjf> lag, context?
<lag> bash
<lag> * = everything
<lag> Don't know what [!~] means
<tgardner> not $HOME ?
<lag> Not home?
<lag> Doh!
<smb> depends on how regex bash is. I thought there were limits
<smb> Maybe only something ending with ! or ~
<lag> It's actually /etc/pm/config.d/*[!~]
<manjo> If the first character following the â[â is a â!â or a â^â then any character not enclosed is matched
<blue_anna> can I get help getting i2c-core module for my build? it's not in my kernel and I don't see an alternative in the repositories
<tgardner> lag, um, I think that matches all files except those ending in '~'
<lag> That could work
<manjo> lag, If the first character following the â[â is a â!â or a â^â then any character not enclosed is matched
<lag> manjo: ack
<lag> Thanks :)
<JFo> apw, did we say KMS was core or graphics?
 * JFo is in forgettory mode
<kees> tgardner: if there's anything I can help with for the ptrace review, please let me know.
<tgardner> kees, ack
<bjf> apw, ogasawara, JFo, adding more BPs to the agenda, just a sec
<bjf> apw, ogasawara, JFo, meeting agenda updated let me know if you want changes
<JFo> k
<JFo> apw, nm I think that was KVM I was thinking of
<smb> JFo, KVM as in the virtualization engine?
<apw> JFo, KMS kernel-graphics, KVM kernel-core yea
<JFo> yeah
<JFo> that was it
<JFo> I was getting them tangled
<smb> apw, Wasnt there a KSM too
 * JFo slaps smb
<JFo> :)
<apw> heh maybe
<smb> Hey I am only the messenger :-P
<JFo> :-D
 * smb thinks of something with shared memory
 * JFo puts an action item to continue updating the Kernel Dictionary
<bjf> JFo, manjo, jjohansen, apw, tgardner, cnd, ogasawara, cking, smb, just a heads up, you are on todays meeting agenda for a blueprint
<jjohansen> bjf: yep thanks
<apw> bjf, ack ... am prepared
<tgardner> bjf, INPROGRESS
<bjf> :-)
<jjohansen> apw: why wouldn't all the items on my blueprints be showing up in https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
<smb> bjf, I did not see me on a complete blueprint but as subitems. apw Ithing in yours (misc)
<apw> jjohansen, which blueprint
<bjf> smb, sorry, your on for the usual reason :-)
<apw> smb, he prolly means for the stable update
<bjf> smb, we just love ya man!
<apw> jjohansen, there are many reasons, easiest to look at the source of the blueprint
<smb> heh, thanks a lot
<jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
<jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
<jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/security-m-apparmor
<jjohansen> https://blueprints.launchpad.net/ubuntu/+spec/security-m-apparmor-profile-packaging
<jjohansen> apw: okay, what am I looking for, some of the items are there, and some of the items there aren't reflecting status changes that were made friday
<apw> ok the DB was last updated my end about an hour ago
 * bjf notes it's going to be a balmy 60 degrees F today in Portland (and rain _all_ day)
<jjohansen> okay, so I will assume I broke the work item format, and check all those
<apw> pvops looks ok
<apw> jjohansen, bearing in mind 'inprogress' does not get seen
<apw> it appears as Todo 
<jjohansen> apw: oh?  For some reason I thought it showed up different
<apw> apparmor loos ok
<apw> sadly no, pitti's db squashes inprogress to 'not done yet'
<apw> jjohansen, as far as i can see they are all there
<JFo> cnd, any Jerone love coming for Big Daddy's bug 581312 ?
<ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/581312
<jjohansen> apw: hrmm, /me wonders why is browser tab isn't refreshing when reload is hit
<cnd> JFo: I haven't heard anything
<blue_anna> can I get help getting i2c-core module for my build? it's not in my kernel and I don't see an alternative in the repositories
<JFo> k
<blue_anna> I was directed here form ubuntu devel
<blue_anna> *from
<cnd> blue_anna: I'm guessing it's already built in
<jjohansen> apw: alright killing firefox fixed it, sorry and thanks
<cnd> blue_anna: yes, it's already builtin in Ubuntu kernels
<apw> jjohansen, la la la can't heard you
<cnd> CONFIG_I2C=y
<blue_anna> cnd: not in 2.6.32-21-powerpc64-smp
<smb> apw, Bah! Having one common enforcer file was probably not the most brilliant idea
<ogra> jjohansen, stop moaning, i'm trying to get mobile blueprints on our charts and fail miserably, you ate least have something more than one work item :) (http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html) 
<ogra> *at least
<apw> smb, that is already sorted in my ubuntu-debian replacement
<apw> it moves to being repository specific
<smb> apw, More reason to have that soon. *sigh*
<apw> smb, its waiting on your trees quiesing long enough to apply it
<apw> i know thats a difficult thing
<blue_anna> cnd: apt-file search i2c-core | wc -l | xargs -0 echo "results found " ==> results found 0
<jjohansen> ogra: wow I guess that means you have no work items for this ;)
<smb> apw, While its causing more trouble getting then quieting down. :-P 
<ogra> jjohansen, easy dev cycle this round :)
<apw> blue_anna, if its built-in there is no module file to search for
<blue_anna> apw: oo that kind of built in :)
<apw> blue_anna, yep, =y on a CONFIG_* item means make it part of the kernel image itself
<apw> ogra, heh got an example blueprint, i've been through most of the errors this week
<apw> (one thats missing i mean)
<ogra> apw, just catched pittin in -devel :)
<blue_anna> apw: so I can just behave as if it is already loaded as a module -- like I can do all the insmods without the modprobe at this instructions? http://ubuntuforums.org/showpost.php?p=4267018&postcount=7
<ogra> *pitti in
<blue_anna> apw & cnd thank you both
<ogra> apw, seems i always make the same mistakes of adding a blank line after "Work items" (it looks so ugly without)
<apw> ogra, hehe :)
<cnd> blue_anna: you should be able to ignore anything that tells you to insmod or modprobe i2c-core
<ogra> and since all our specs were discussed under ubuntu-arm they are all named wrongly as well
<ogra> its a total mess
<blue_anna> cnd: thanks again
<cnd> np
 * cking is going ACPI testing loopy
<achiang> cking: ah, is there anything from the bios testing blueprint i can help with?
<bjf> ##
<bjf> ## Kernel team meeting in 25 minutes
<bjf> ##
<manjo> bjf, wonder why I don't see it in the canonical calendar
<bjf> manjo, looking
<JFo> sounds like user error manjo :-P
<cking> achiang, I have a git repo now with my code on it - it may be worth occasionally giving it a test spin
<achiang> cking: ah, cool. pointer to the repo?
<cking> achiang, http://kernel.ubuntu.com/git?p=cking/ubuntu-firmware-test-suite/.git;a=summary
<bjf> manjo, it's on the calendar that i'm looking at
<achiang> cking: thanks
<manjo> bjf, strange... something wrong at my end 
<cking> achiang, check it out, ./configure and run ./src/testsuite --help ;-)
<achiang> cking: yep, maybe i'll get a chance to play with it today
<bjf> manjo, the calendar it's on is "Ubuntu Kernel Schedule"
<manjo> bjf, ah I am subscribed to it somehow... wonder what happened
<manjo> bjf, *not*
<manjo> bjf, can you add me to that calendar ? 
<bjf> manjo, i don't think so, probably has to be pgraner or tgardner 
<JFo> looks like the other meeting will run over bjf 
<bjf> JFo, when we all stomp into the channel, they may close up
<JFo> mayhap
<manjo> bjf, you need to get ops fro that one too
<bjf> ##
<bjf> ## Kernel team meeting in 5 minutes
<bjf> ##
<apw> they finished on the dot
<bjf> ##
<bjf> ## Meeting starting now
<bjf> ##
<achiang> cking: what's the git url to clone your test suite?
<achiang> cking: my guess of:  git://kernel.ubuntu.com/projects/cking/ubuntu-firmware-test-suite.git was unsuccessful
<cking> achiang, hrm, dunno why, let me check it out after the meeting
<apw> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/397845
<ubot2> Launchpad bug 397845 in linux (Ubuntu) "Thinkpad T30 backlight remains on during supend (affects: 1)" [Undecided,Expired]
<phunge0> hi i have a question
<phunge0> for pgraner possibly
<phunge0> i'm the submitter of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092
<ubot2> Launchpad bug 585092 in linux (Ubuntu) "tmpfs umount slowdown (affects: 1) (heat: 12)" [Undecided,Incomplete]
<phunge0> i have a ubuntu-lucid git fork with backports of mainline packages that i'd like to link on that bug
<phunge0> so i need to be able to host the git repo somewhere
<apw> phunge0, if the backport is big enough that you can't attach it, then its likely not going to be SRUable
<phunge0> it's 3 cherrypicked patches
<cking> achiang, try git clone  git://kernel.ubuntu.com/cking/ubuntu-firmware-test-suite
<phunge0> should i just attach 3 patches?
<apw> then simply putting the three headers from those in the bug
<phunge0> how do you mean headers? fyi the cherrypicking involved some merging
<JFo> apw: http://status.qa.ubuntu.com/qapkgstatus/linux
<achiang> cking: yep, that got it, thanks
<apw> then attach the full patches.  if they were just cherry-picks then the sha1's and description would have been enough ... else the whole patches are needed
<phunge0> k i'll do that tx
<cking> achiang, you need to do a git pull on that got pick up klog.h - then ./configure and run sudo ./src/testsuite --show-progress --results-output=achaing.log --stdout-summary
 * cking goes for food
<apw> Keybuk, yo ... SYSFS deprecated settings you wanted off, were there any other than the SYSFS_DEPRECATED* those ones ... 
<apw> cnd, http://people.canonical.com/~scott/daily-bootcharts/20100406-max-kernel.png that was from the 4th
<Keybuk> no, was just wanting to make sure they're all in the config checker
<Keybuk> they should be all off atm
<apw> Keybuk, ack ... thakns
<apw> Keybuk, do you need warning of getting all kernel command line options in upstart
<Keybuk> I'd like to know when that lands
<Keybuk> but I don't need to do anything first
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - June-01 - 17:00 UTC
<apw> bjf, is the topic here on the list to change page, and i note the link still points to my copy not yours and mine exists and shouldn't
<bjf> apw, ack, haven't fixed that yet, will do so now
<bjf> apw, which link are you refering to, i'm looking on the knowledgebase page
 * manjo going to a meeting on improving server testing with checkbox ... yaaay!
 * cking wonders if we should have an ignorancebase page for answers we don't have
<apw> bjf i added one to the top of the meeting page, as that is where i yearned to find the info
<bjf> apw, that's too obvious
<apw> sorry
<JFo> bjf, that topic probably needs to change to Home: https://wiki.ubuntu.com/Kernel/
<JFo> whoops
<JFo> nm
<JFo> I just finished reading back
<JFo> :)
<cking> achiang, any luck with the test tool?
<achiang> cking: trying to get my test machine up. :-/
<cking> ;-(
 * achiang learns a lesson about touching interesting BIOS knobs on proto hardware.
<achiang> luckily, pulling the CMOS battery did the trick
<cking> phew
<cking> achiang, well, when you get some results, email the log to me so i can sanity check the code
<cking> ..no rush
<achiang> cking: yep, i'm installing lucid now
<phunge0> JFo: i've updated my bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092 with the triage info, what needs to happen to get it out of incomplete triage land?
<ubot2> Launchpad bug 585092 in linux (Ubuntu) "tmpfs umount slowdown (affects: 1) (heat: 12)" [Undecided,Incomplete]
<JFo> phunge0, I need to get to it :)
<phunge0> thanks :)
<JFo> phunge0, done
<phunge0> JFo, thanks
<JFo> np
<jjohansen> -> lunch
<vanhoof> JFo: I grabbed that bug for now until I can divy it out
<JFo> cool, thanks bro :)
<JFo> sorry for all the confusion
 * ogasawara -> lunch
 * bjf -> lunch
<vanhoof> JFo: no worries, the whole thing is kinda screwed up
<JFo> yeah
<JFo> Can HAz bug servur dat stays available longer than 5 minutes? kthxbai
 * JFo kicks Launchpad in it's bad pants
<cwillu> is btrfs anybody's pet project here?
<pgraner> bjf: can you add ubuntu-news-team@lists.ubuntu.com to cc: list of the email you send out after the k-t meeting
<bjf> pgraner, sure
<pgraner> bjf: thanks that way it will make UWN
<pgraner> bjf: I sent them this weeks already
<pgraner> bjf: thanks
<bjf> pgraner, "the queen" was going to take care of it for me :-), but I'll do this as well
<bjf> JFo, I'm looking at your "Release Meeting Bugs", you have "fsl" and "mvl" listed though we don't have them in maverick
<JFo> hmmm, excellent point :)
<bjf> ogasawara, ^
 * JFo marks them for removal if that is the consensus
<bjf> ogasawara, what should we be tracking "Release Meeting Bugs" wise?
<ogasawara> bjf: we don't have fsl and mvl-dove for Maverick at the moment, so no need to track
<ogasawara> bjf: release meeting have yet to start, so nothing to track at the moment
<ogasawara> bjf: I'd just go with tracking any Alpha1 targeted bug at the moment
<bjf> ogasawara, ok
<svu> chrisccoulson, hi :)
<svu> chrisccoulson, who would be the person to talk to?
<vanhoof> what is the key for push to talk on mumble?
<vanhoof> anyone know off hand
<bjf> vanhoof, you set it yourself
<vanhoof> hmm ok
 * vanhoof looks
<bjf> vanhoof, configure->settings->shortcuts
<vanhoof> bjf++ thanks!
<kees> ogasawara: around?  I need rebase help.  :)
<ogasawara> kees: I'm here
<kees> ogasawara: okay, so I have a git tree that was a clone of ubuntu/ubuntu-maverick.  I've worked on it and comitted locally.  more changes have gone into the origin, so how do I carry my stuff forward to be at the "top"?
<kees> (if I do "git pull" I end up with a "merge" commit at the top)
<achiang> git fetch && git rebase origin
<kees> \o/ that worked.  thanks achiang :)
<ogasawara> kees: what achiang said :)
<kees> huzah, my git push even worked now.
<achiang> kees: in general, you almost never want to do a git pull
<achiang> since it'll more often than not add a merge commit on top
<kees> achiang: yeah, totally agreed.  :)
<achiang> git fetch will pull down the new metadata and then you can do a git rebase origin to move your patches to the end
<achiang> also, stacked git is way nicer than raw git
<kees> achiang: what is "stacked git" ?
<kees> ogasawara: here is my tree, is this in the right form for me to do a pull-request?  http://kernel.ubuntu.com/git?p=kees/ubuntu-maverick.git;a=summary
<achiang> kees: conceptually, it's quilt + git
<achiang> kees: but way nicer than either quilt or git by itself. :)
<kees> hunh, neat
<achiang> kees: basically, the problem it solves is, "how do i manage a patch queue on top of a git tree?"
<achiang> so here's a limitation in git: a commit is forever. so if you're developing a bunch of patches, say 1, 2, 3 ; have committed 1 and 2 and are now working on 3, then realize that you really wanted to do something different in 1, you are screwed
<cwillu_at_work> git pull --rebase
<achiang> you have to do ugly stuff like save off the patches manually, then reapply them
<achiang> in stacked git, you can just say: stg pop ; stg pop ; <hack hack hack> ; stg refresh ; stg push ; stg push
<ogasawara> kees: git request-pull Ubuntu-2.6.34-4.11 git://kernel.ubuntu.com/kees/ubuntu-maverick.git master
<kees> ogasawara: cool; I had most of that but not the final "master".  what is the convention for the email subject line?
<cwillu_at_work> achiang, why wouldn't you just branch off a to a'; hack hack hack; and then rebase b and c on a'?
<kees> ogasawara: but, I mean, it's sane for me to have the reverts followed by the updates?
<ogasawara> kees: subject line can just be "Maverick pull request for <insert blurb>"
<achiang> cwillu_at_work: in your example, what are b and c?
<ogasawara> kees: yep, sane to revert patches you want to drop and then apply the ones you want
<kees> perfecto
<cwillu_at_work> achiang, I meant your 1, 2, 3
<cwillu_at_work> the patches series
<achiang> cwillu_at_work: to keep a clean development history
<achiang> that's the simplest answer
<cwillu_at_work> I don't follow;  that's what rebase is for:  to keep a clean development history, no?
<kees> wheee, I did a pull request.  ;)
<achiang> cwillu_at_work: what if you want to edit the changelog of patch 1 and your HEAD is pointing to patch 3?
<ogasawara> kees: \o/
<kees> ogasawara: and I even did the sneaky interactive rebase merge thingy.
<ogasawara> kees: I'll get these applied and uploaded for Alpha1
<kees> ogasawara: oooh, cool, thanks.
<cwillu_at_work> achiang, I'm finding it difficult to come up with something different than "uh, rebase it?" as a response :p
<achiang> hm.
<achiang> so you commit patch 1.
<achiang> then, commit patch 2
<achiang> decide you want to change patch 1, so ... git branch <sha1 of patch 1 - 1>
<achiang> actually, i can't figure out how you would do what you propose with rebase
<achiang> each commit is atomic, so i fail to see how a rebase lets you change a commit
 * achiang shrugs, goes outside to hack at stubborn roots
<jjohansen> achiang: you can do an interactive rebase, tell it which commits you want to edit
<jjohansen> but I find guilt/stgit easier to work with than interactive rebase
<jjohansen> guilt/stgit also make it easier to shelve patches
#ubuntu-kernel 2010-05-26
<blue_anna> please help
<blue_anna> I gave up on my af9015 card, I've started a second time on a tv card that uses the em28xx drivers -- both drivers have built, but neither attach to their card when it is installed
<blue_anna> and I have the latest hardware -- but there's scant little, virutally no results for em28xx support. these are both dvb drivers
<blue_anna> ** firmware, not hardware
<blue_anna> I can't find any documentation for em28xx that's recent 
<blue_anna> the modules load if I modprobe them, and after I did that the administration->hardware drivers found a firmware for me to download for my card, but still I get nothing from my card with that firmware installed
<blue_anna> online I found something saying that a different firmware was needed but its not working either
<blue_anna> and I just tried removing the firmware that the system automatically installed and reloading the em28xx modules, but that didnt pick up either
<blue_anna> lsusb doesn't list any name for the hardware, like this is all it says right now: Bus 001 Device 029: ID 1d2c:1012  -- but there's like a million lines of output in lsusb -v for the device: http://pastebin.ws/6htngd
<reecefowell> Can anyone tell me if i am correct in my understanding that programs must request a kernel write to the hdd on its behalf and that programs usually dont have access to the hdd to write to it on its own?
<cooloney> morning guys
<vanhoof> ogasawara: you may be my new best friend ;)
<ogasawara> vanhoof: heh, I'm not sure if that's good or bad :)
<vanhoof> ogasawara: def good :)
<akgraner> ogasawara, be afraid if vanhoof is offering to be your bff....:-/  just sayin'
<vanhoof> lol thanks akgraner 
<akgraner> opps inside voice  - I mean vanhoof is awesome... yeah that's what I meant :-)
<greenfish> where would i locate the debug kernel image for lucid 2.6.32?
<jk-> greenfish: what debug info are you after?
<greenfish> vmlinux compiled with debug symbols
<jk-> not sure if there's a pre-built one; but most of the time you can get by with the symbol table & System.map
<pgraner> greenfish: http://ddebs.ubuntu.com/pool/main/l/linux/
<jk-> oh, cool.
<pgraner> greenfish: however the 2.6.32 ones broke for a long period
<pgraner> greenfish: so I don't see them there
<pgraner> greenfish: you might be outta luck
<greenfish> yeah. thats tough for a sysadmin who needs to profile things...
<greenfish> pgraner: i wasn't seeing them either
<pgraner> greenfish: I know the build system for some reason was broke and I don't think we can go back and recreate, the next SRU kernel should have one tho
<jk-> greenfish: what kind of profiling? 'perf'?
<pgraner> greenfish: what are you trying to debug, normally full symbols is overkill as jk was saying
<greenfish> pgraner: the tcp stack and memory management when certain applications in my stack are under extreme load
<pgraner> greenfish: perf is prob a better tool or ftrace
<greenfish> regardless of the tool, i'll need debug symbols to see what the kernel is doing
<pgraner> greenfish: are you familiar with perf or ftrace? You don't
<greenfish> perf might give me a call graph, but i'm much more familiar with oprofile
<pgraner> greenfish: not much we can do, as I said we can't recreate if its not urgent you can wait for the next SRU kernel and it will have ddebs
<greenfish> ahh. where are the backups? ;)
<pgraner> greenfish: they never got created, the build system was broke 
<greenfish> yeah. tough to back that up then ;)
<pgraner> greenfish: unfortunately we don't use ddebs that often and when we realized it was too late
<jk-> greenfish: so you're looking for hot functions in the kernel?
<greenfish> i see. there are 2.6.34 kernels in the ddebs pool. is that from maverick?
<greenfish> jk-: perhaps. i just need a full stack profile of the system under specific loads.
<greenfish> i'm not opposed to other tools, but i'd have to learn them before they would be useful to me
<pgraner> greenfish: yes those are maverick kernels
<pgraner> greenfish: if you install the maverick kernel and are experiencing the same issues you can use those ddebs to debug with the tools your familiar with
<pgraner> greenfish: I'm running the maverick kernel on the lucid userspace with no issues on both desktop & server so I'd give it a go
<greenfish> pgraner: terrific. can that be updated using apt with the right source and not interfere with non-kernel dependencies?
<jk-> greenfish: perf should suit; `sudo perf record -a -f -g` and `perf report --call-graph -i perf.data`
<greenfish> apologies for the silly question, ubuntu is not my primary distro
<greenfish> or, alternatively, where can i find the build process for the 2.6.32 generic kernel? while the resulting binary may not be exactly the same, if i do a full build of both vmlinux, and vmlinuz then things should line up with little to no differences from the ubuntu build
<pgraner> greenfish: https://wiki.ubuntu.com/KernelTeam/
<greenfish> thanks again
<pgraner> greenfish: then find the KnowledgeBase link and follow the link to build instructions
<pgraner> jk-: you got video conf working yet....
<jk-> pgraner: can set it up on my machine if you need
<jk-> but putting it on a .mills host would be cool
<pgraner> jk-: how much resource do you need, I can give you sudo on frylock if you want
<pgraner> jk-: I'd like to see how well it works
<jk-> pgraner: the server doesn't need much CPU
<pgraner> jk-: ok, lemme add you to the sudoers 
<jk-> yeah, happy to set it up for testing. it was just a hack for our virtual-coffee-machine calls though.
<vanhoof> jk-: what'cha working on?
<jk-> vanhoof: I hacked together a video conf server for our informal calls
<jk-> just getting it set up on pgraner's machine
<pgraner> vanhoof: this way I can see your ugly mug
<vanhoof> oh nice
<vanhoof> pgraner: dont make me drive west :)
<vanhoof> can skype do more than 1:1
<pgraner> vanhoof: bring it (and some friends)
<vanhoof> pgraner: if by friends you mean jess, and my dogs sure :)
<vanhoof> pgraner: http://hphotos-snc3.fbcdn.net/hs575.snc3/31375_389772562186_511662186_4512783_5162068_n.jpg
<vanhoof> ... a nightmare in the graner household lol
<pgraner> vanhoof: nope just something for murphy to play with
<vanhoof> pgraner: does he get along w/ women? :)
<pgraner> vanhoof: yep
 * jk- out for a bit
<amitk> cooloney: do you know anything about this on mx51? http://pastebin.ubuntu.com/439766/
<amitk> I'm trying to boot a mainline mx51 kernel
<amitk> it looks related to the mdio code you were hacking on?
<cooloney> amitk: i posted 2 patches to upstream
<cooloney> amitk: but Andy Fleming who is the phylib maintainer has some concern
<amitk> cooloney: patches to fix this issue?
<cooloney> i don't have hardware to do furthur development
<cooloney> amitk: i'm not sure about that. 
<cooloney> amitk: could you try my patch and test again
<cooloney> let me find the patch for you
 * smb yawns
<amitk> cooloney: l-a-k?
<smb> cooloney, Hi, just as info: boot is ok. If you can play around a bit, the better, but there is no real regression test plan for arm
<smb> amitk, Morning
<amitk> moin smb 
<cooloney> smb: ok, got it. GrueMaster will help to test it on his hardware
<smb> cooloney, Great, thanks!
 * smb goes back to his long checklist
<cooloney> amitk: i sent them out to netdev mailist
<cooloney> amitk: did you subscribe to that mail list?
<lag> Morning smb
<lag> Morning amitk
<amitk> hi lag 
<smb> lHey lag
<amitk> cooloney: I think not, but I'll find the archives
 * smb punches the backspace key harder
<cooloney> amitk: http://kerneltrap.org/mailarchive/linux-kernel/2010/5/7/4566895
<lag> smb: Has apw spoken to you regarding the new bug stuff yet?
<cooloney> amitk: i need rework on this patch, but don't have working hardware, so ......
<smb> lag, Nope. I assume neither to you then
<smb> lag, Guess we need to get back to him later
<lag> smb: Sure
 * apw looks blearly over his domain
 * smb and lag already wait in the shadows for apw to arrive
<amitk> apw: you make a poor warlord if your desk is your domain
<smb> cking, morning
<cking> hiya
<lag> smb: Speak for yourself ;)
<apw> amitk, heh indeed
 * apw notes that 12 hours on linux armel is still building
<amitk> I noted that, its surprising
<lag> amitk: It worked for Churchill  
<apw> amitk, why is it supprising?
<amitk> apw: I'd thought 5+5 hrs
<apw> it takes 6-7 hours to do 1 armel flavour, you added a new one yesterday
<amitk> ok, so it should be about done now
<apw> 5.5 for the build itself, plus packaging time, which is huge
<apw> its in the last 30-40 mins yes
<apw> this brings up an issue we need to consider, for when you do get all arm branches in the same image
<apw> we can't afford to have a ton of flavours
<amitk> by then (next 6 months), we will have ARM HW with 2GB RAM
<apw> oh the build is 'done' we ar in pkg*mangler
<apw> oh no, maybe not, seems to be back to linux-image now for versatile
<amitk> we're talking to vendors to give us faster disk though (sata connections)
<apw> we need some 64 way arm servers
<amitk> talk to Martyn @ Smoothstone
<apw> indeed
<apw> sadly adding omap probabally means we need to pull back all our freeze dates by a day
<apw> as now you can only do 1 arm build a day not two
<amitk> I wonder how hard it would be to hack our scripts to do cross-compile for testing automatically
<apw> i do armel builds using crossbuilds primarily, but those don't seem to be able to make the tools side
<apw> you need one of those real cross-buildy qemu thingies
<amitk> *automatic cross-compile for test-builds
<apw> you can do automated test builds using sbuild, though being qemu emulated its like 2:30 a flavour for me
<amitk> apw: just for arm
<apw> to tooling i am using for just building the linux-image, works using cross compilers for armel builds automatically
<apw> and i just found sbuild, so am thinking on letting that be a backend
<apw> its an interesting approach for all platforms, not tried it for performance on x86, though i assume its native speeds
<smb> lag, To reply to "pseaking for yourself". I meant the bug processing thingy. Though I completely trust you to speak for yourself there, too. :)
<apw> the nice thing about sbuild is it seems to be a pbuilder style 'auto install deps' kind of thing, and uses aufs to retain the virgin original chroot
<lag> smb: I was joking. I meant I wasn't cowering in the shadows awaiting the arrival of our overruling leader. ;)
<smb> lag, Ah you prefer the open attack. :-P
 * apw marshalls his forces
<lag> smb, apw: Full frontal! ;)
<cooloney> apw: how about using qemu running on x86
 * apw does not need any full frontal pictures at this time of day
<cooloney> and we native compile kernel for armel in qemu
<lag> apw: Are we going to chat today about the new bug processes? We didn't really get chance yesterday did we?
<apw> cooloney, that is what sbuilder does in this context.  2.5 hours a flavour still
<amitk> apw: 2.5 hrs on emerald?
<apw> that was on a local box, a 4 way
<apw> not tried on emerald as yet
<cooloney> and if the x86 is very powerful, we can running several qemu instance and use dist-cc to distribute the building tasks to several qemu builder
<amitk> cooloney: how many cores can qemu use effectively?
<apw> cooloney, yes i really was trying to say even there its not 'instant', yes much better than the real h/w
 * abogani2 waves
<abogani2> I'm wondering about ubuntu-debian.git. What it is useful for?
 * smb points to apw
<apw> though the performance on the real buildd is not guarenteed to be the same, not is the outcome
<cooloney> amitk: actually, i have no idea about that
<apw> abogani2, its a respository for the master copy of the debian build machinary
<apw> we are cleaning up the disparate copies in all our trees over the next few weeks
<smb> abogani2, But in general, it should become the source for what is in our debian directories
<apw> so that they all behave the same
<apw> the main trees will retain their own copied, but they will be regularly updated from the common copy
<amitk> abogani2: unified build policy across all releases
<apw> as most changes there affect all releases and should be pushed out to all
<apw> as they relate to archive behavour which is the same regardless of release age
<abogani2> amitk, apw: Understand thanks.
<lag> #ifdef DEBUG
<lag> #define pr_devel(fmt, ...) \
<lag> 	printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
<apw> amitk, i see the armel build is in its 14th hour
<amitk> still packaging?
<apw> yep, the dbg deps are bigger than the machine so it thrashes like  pig i am sure
<apw> they take many minutes on emerald
<apw> let alone a memory starved arm
<apw> i have been saying arm takes 6-7 hours per falvour, and noone believes me
<smb> always whining... :-P
<apw> amitk, what worries me, is now is the stage where it goes 'package foo not in control file, BANG'
<apw> and throws away everything its done
<amitk> yeah, I *hate* that
<apw> makes me want to cry
<ogra> hmm, there seems to be something weird in your package build scripts, omap4 didnt build because the code below only seems to detect omap but not omap4
<ogra> imagelist=$(cat /build/buildd/linux-ti-omap4-2.6.33/debian/build/kernel-versions | grep ^armel | awk '{print $4}')
<ogra> (thats right after "# unpack the kernels into a temporary directory")
<ogra> and results in: ls: cannot access ../linux-image-2.6.33-900-omap_2.6.33-900.1_armel.deb: No such file or directory
 * lag is ready to talk about 'moths in relays' with apw and smb
 * smb can join
 * apw gets tea
<cooloney> ogra: ok, thanks, i think i missed something in the debian script stuff
<cooloney> ogra: thanks, i forgot to replace omap to omap4 in debian.ti-omap4/d-i/kernel-versions.in
<cooloney> ogra: will upload and build again, although it will take 6hrs to build
<ogra> ah, perfect
<ogra> yeah, the babbage boards arent fast but reliable :)
<jjohansen> good night *
<amitk> apw: arm is done building
<amitk> apw: all flavours of a single arch are built on the same machine, right?
<apw> amitk, yes all flavours are built sequentially on one machine
<amitk> apw: could that be split up in debian/ ? Or is that buildd backend magic?
<apw> amitk, a source package is sequential per architecture, and single thread per architecture
<amitk> *sigh*
<apw> but the point of your work is to make one kernel for all so we won't have an issue right
<apw> amitk, i suspect if we end up with more than 2 arm flavours in 'master' we will have to do something like make two source packages out of the same master tree
<amitk> apw: that work is still a year away realistically
<apw> linux and linux2
<apw> amitk, yep, but of course until you win that battle the arm variants are likely to remain branches, and their own packages, and threfore buildable in parallel
<apw> amitk, so likely self limiting in a lot of senses
<amitk> true
<cooloney> guys, my upload to arm PPA build failed, 
<cooloney> it is ti-omap4 kernel package, 
<cooloney> i build it successfully in my local machine
<cooloney> but it failed in our build system
<cooloney> so i fixed it in my kernel pakcage and wanna to reupload, but it was rejected because of my initial upload is there
<cooloney> do you guys know how to change my package version without bumping my kernel ABI?
<cooloney> apw, amitk and smb-afk ^^^
<apw> add build2 to the end of the version number
<cking> apw, why does that help?
<cooloney> apw: which file contains that version number i can change?
<apw> cking, you have to increment version numbers in every upload
<apw> cooloney, in the debian.<branch>/changelog
<cooloney> apw: oh, sh*t, i know that. 
<apw> the complaint is about the literal and total version number which must increment
<cooloney> apw: thanks
<apw> so build2 is a common way, you can use build3 etc when it fails again
<apw> though as a general rule, where i am testing sometihng i will upload as -10.20 i use ~pre1 ~pre2 as i go and never use the real number
<apw> allowing that to only appear in the main archive.  that way someone running my test version is decernable as against the official build
<cooloney> apw: ok, understood. so normally, for this change, will you commit it into the kernel git?
<cooloney> apw: i think we just change the name for upload
<apw> cooloney, just for the upload yes
<cooloney> apw: thanks, man
<lag> apw: bug 569882
<ubot2> Launchpad bug 569882 in linux (Ubuntu) (and 1 other project) "Suspend Lenovo Thinkpad X61 with card in SD card reader (affects: 3) (heat: 24)" [Undecided,In progress] https://launchpad.net/bugs/569882
<apw> smb-afk, this looks to be a duplicate of your MMC card crashy on suspend bug ... 
<apw> bug #477106
<ubot2> Launchpad bug 477106 in linux (Ubuntu) "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware (affects: 76) (dups: 15) (heat: 526)" [Medium,Confirmed] https://launchpad.net/bugs/477106
 * pgraner yawns and blinks
<apw> morning pgraner 
<pgraner> apw: sup man?
<apw> just chilling ... nothing speical
<pgraner> apw: Updated my primary desktop Maverick... and well I'm bleeding a bit, not called bleeding edge for nothing!
<apw> pgraner, you are mad :)
<pgraner> apw: not bad, other than I loose my mouse about once an hour and I have to reboot. X is working fine, keyboard, just the mouse locks up unplugging shows in demsg but X never picks it up again
<pgraner> apw: and evolution keeps crashing on startup
<amitk> pgraner: switched back to evo?
<apw> mouse> interesting ... in lucid i am pretty sure i lose my mount and sometimes external keyboard but a USB unplug replug works there
<apw> mouse
<apw> pgraner, i actually use a VT switch to 1 and back to restore them too sometimes
<pgraner> apw: not here, I've even tried forcing a suspend/resume to see if that would shake it loose but nothing
<smb> apw, mcc thingy sounds similar, yeap
<smb> mmc even
<apw> smb sounds like lag has made some progess isolating it too
<apw> so perhaps you can palm it off on him :)
<smb> Oh he is always free to fix it. I can test if he has something. :)
<smb> Is there something in the scrollback (about what it could be)?
<lag> smb, apw: Okay, I'll crack on with it then
<apw> smb, he has identified a module that if you rmmod it on suspend and modprobe it on result it doesn't blammo <- about right lag ?
<apw> which probabally tells us which suspend/resume callbacks are broked
<smb> Hm, ok. I am not sure there is a rmmod in the case I looked at. But it might still be related.
<lag> It's not an rmmod per-say
<lag> You can tell PM to unload/reload modules on suspend/resume via a config file
<apw> i thought you added it to the pm-suspend list
<apw> right and that makes it rmmod on suspend and modprobe on resume
<lag> I did so and fixed the errors on my ThinkPad
<lag> Correct
<apw> right ... so its likely the suspend callback on that driver thats blowing chunks
<lag> I don't know the inner workings, but I would have thought so
<apw> as when the module is removed it does not blow chunks, which avoids that callback
<smb> or rmmoding adds another sync-wait point
<lag> Which is where my debug code is currently ;)
<apw> as the module is not there on suspend
<apw> smb, or indeed it may just slow down suspend enough
<apw> but i do suspect suspend based borkage
<apw> i suspect it panics
<lag> I'm in the middle of these theories currently - leave it with me :)
<smb> Chances for that are high. But I guess its in good hand with lag :) Just enlighten us when youre finished
<apw> yep
<lag> It doesn't look like it's even getting to the module's suspend function
<lag> It's dieing in the interrupt handler 
 * lag gets ready for a new debugging session :)
 * lag smiles
<cybrocop> Hi all. I'm having a permissions-related problem with qemu/kvm and I believe it is a kernel related issue (through process of elimination). I would really value insight from members of this group. 
<cybrocop> http://open.eucalyptus.com/forum/libvirt-operation-failed-failed-retrieve-chardev-info-qemu-info-chardev
<cybrocop> Both apparmor and selinux are disabled with kernel boot parameters... yet for some reason, kvm cannot get permission to open a simple file for logging the console.
<apw> cybrocop, which file is it, what filesystem type is it on
<cybrocop> apw: filesystem is ext4
<apw> is that inside or outside the KVM instance?
<cybrocop> Whenever I include this as part of libvirt.xml, kvm fails to start: http://slexy.org/raw/s20HiyArHA
<cybrocop> libvirt is unable to create the "serial" device and thus kvm fails to start.
<apw> gah xml, now i remember why i work on the kernel
<apw> what does ls -l on that file say, and on the containing directory?
<aquarius> apw, ping?
<apw> hi
<aquarius> pgraner said I should ping you :)
<aquarius> imagine I have a USB stick which, when plugged in, says lots of "device not accepting address 13, error -71" in dmesg, and doesn't mount
<apw> cybrocop, what generates that fragment
<cybrocop> apw: the file doesn't exist (wasn't able to be created).  here is "ls -al"    http://slexy.org/view/s2LWfnYhXw
<aquarius> (or get a device name or anything)
<aquarius> is there any way to get the data off it?
<apw> aquarius, well i would try it on a different machine, and on an older kernel to confirm its not s/w related, but generally i've foudn that behaviour to be 'bad'
<aquarius> apw, it's not s/w related; fails under Windows too (that's where it failed originally, so it was brought to an Ubuntu machine to see if that helped)
<apw> aquarius, that is assuming that at some point it has worked in the past of course
<aquarius> yeah, it used to work :)
<cybrocop> apw:  that fragment is part of the full libvirt.xml...  Eucalyptus generates teh XML file and that is supposed to launch a VM instance. It contains the definitions for the VM instance, to be used by libvirt. Here is the full libvirt.xml     http://slexy.org/raw/s2KPFinewG
<aquarius> I have given the owner a little lecture about not keeping your *only* copy of files on a usb stick.
<apw> aquarius, i would be suspicious it is sick at the h/w level then sadly ... as its refusing to take an address at the USB level
<aquarius> apw, so it's just broken and there's nothing that can be done about it? bah. That's what I thought, but I didn't know if there were Secret Things that could be done
<apw> i don't know of any way to talk to it if its really not having an address, thats kinda the first step
<apw> cking, know any magic to get a usb stick which is refusing addresses on both win and ubuntu to play ball?
<apw> cybrocop, ok the sensible debugging step would be to get an strace off the startup sequence to see what the open it tried did and said
<cybrocop> apw: Basically libvirt/kvm tries to create that file in order to map it to the serial port for the VM instance. I suspect it cannot create the file and thus KVM errors out... 
<apw> cybrocop, i have no idea whether you can get to it do do that or not, have you brought this up on #ubuntu-server, they are the ucalyptus experts
<apw> cybrocop, if not then we should move over there and get their input
<cybrocop> apw: I have spent many hours on #eucalyptus and they have tried to debug this with me to no avail.  #ubuntu-server didn't provide any insight. 
<apw> well i see nothing in the directory settings which is unusual.  if basic permissions didn't work on ext4 i think we would have noticed by now
<apw> cybrocop, so the next step is to get a trace off of the thing as it tries to start, normally i use strace for that -- strace -o /tmp/TRACE -f -e 'trace=open' <command which makes it happen>
<apw> something like that
<cybrocop> apw: The consensus (and I agree) is that Eucalyptus is not responsible for this as it tries to fire a KVM instance. Eucalyptus is eliminated as a culprit because I try to launch it manually using virsh and it fails.
<cybrocop> apw: Thank a lot, I'll try that.
<apw> cybrocop, use the very simplest command you can to start it for sure
<apw> and then the output should be all files opened, looking for the open which is to that file
 * lag 's new GIT book as arrived :D
<apw> $DEITY help us all
<lag> ;)
<jk-> soon you'll be commiting by editing .git/objects/** directly
<jk-> working trees are for chumps
 * apw imagines doing the sha1's in his head
 * lag is still confused, as he hasn't yet read the book and has no idea what they $PLACE_BAD_PEOPLE_GO you're on about!
<lag> the*
<cking> apw, no idea how to fix a misbehaving USB stick that looks dead
<apw> cking, yeah i think so too ... ouch
<cking> what does the kernel say when it's plugged in
<cybrocop> apw: Here's the output.. http://slexy.org/raw/s2FmLeuYdM  Is it possible that virsh is firing off another process which isn't monitored by strace?
<jk-> cybrocop: the other process could be started by the libvirtd daemon
 * jk- doesn't have much context
<cybrocop> jk: can I attach strace to a running proc?
<jk-> sure can, strace -p <pid>
<aquarius> cking, the kernel says lots of "device not accepting address 13, error -71" when the USB stick is plugged in
<cking> aquarius, tried the USB stick in a different machine just in case it's not the USB stick?
<jk-> -EPROTO ?
<aquarius> cking, yep -- failed under windows in one machine, failed under ubuntu in another
<cking> sounds like broken H/W to me
<ogra> you shouldnt use your usb keys as swap space ;)
<aquarius> cking, thanks :)
 * manjo says N900 got a maemo 5 update, disable extra-devel extra-testing before you do an upgrade, or you might not have enough space on rootfs
<ogra> manjo, bah, to late, already running 
<manjo> ogra, ota in the us was today
<ogra> here too
<manjo> :) you have some lead time on me 
<ogra> yeah, but only got around to click the button 1/2h ago
<manjo> ogra, :) N900 won't get the meego update 
<ogra> i dont want meego
<amitk> :)
<manjo> this is probably the last update to maemo
 * ogra is happy with maemo 
<cybrocop> jk / apw: it was indeed libvirtd that is starting it. Here is the command I used:  strace -o /tmp/TRACE -f -e 'trace=open' -p 945
 * ogra wishes the new arm project would take over maemo :)
<cybrocop> jk / apw: Then I ran this from another shell: http://slexy.org/view/s2jndz6OKP
 * manjo wants andriod 2.2 on N900
<ogra> bah
 * manjo want to dual boot 
 * ogra just wants ubuntu based maemo
<cybrocop> jk / apw: Then I detailed by Ctrl-C. Here is the output of /tmp/TRACE   http://slexy.org/raw/s2u2zWu5Ur
<cybrocop> detailed -> detached
<jk-> cybrocop: so libvirtd does not have access to console.log ?
<apw> cybrocop, right who is that daemon running as ?
<cybrocop> No, which is very puzzling... 
<cybrocop> root       945     1  0 14:48 ?        00:00:00 /usr/sbin/libvirtd -d
<jk-> does it drop privs at any point
<jk-> ?
<apw> need to know its real ids
<cybrocop> It should (according to the advertisement) drop privs to libvirt-qemu:libvirtd
<cybrocop> root@srv-uec-qa-node02:~# grep libvirt /etc/passwd /etc/group
<jk-> strace -e trace=open,setuid,seteuid [...]
<cybrocop> jk: let me try with those options.
<apw> cybrocop, you can tell from /proc
<jk-> apw: provided he can catch the spawned process in time :)
<cybrocop> apw: can you be more specific? Does it contain a history of setuid/setgid?
<cybrocop> jk: correct, the spawned process dies quickly.
<apw> cat /proc/945/status and grep for Uid and Gid
<apw> jk its possible it has d already
<apw> jk it is possible that it has dropped them already
<apw> cybrocop, if the docs are right then the permissions it runs them as doesn't have open right in there does it?
<cybrocop> root@srv-uec-qa-node02:~# cat /proc/945/status |grep -i -e "uid" -e "gid"
<cybrocop> Tgid:	945
<cybrocop> Uid:	0	0	0	0
<cybrocop> Gid:	0	0	0	0
<jk-> ok, so console.log (and the parent directories) need to be accessible by that user
<apw> yeah unless libvirt-qemu is in eucalyptus group then its not going to work is it\?
<apw> so check if its a member of that, if not then the permissions checks are working as expected
<cybrocop> jk / apw: I am running the command as root
<apw> and something is owned by the wrong person
<apw> cybrocop, but the docs tell you it demotese self to libvirtsomething didn't you just say
<cybrocop> jk: "that user"  uid=0 ?
<jk-> cybrocop: it doesn't matter who is running the command
<jk-> "that user" = the user that libvirtd is setuid-ing to
<apw> and the docs you just pasted told us who it was
<cybrocop> jk /awo:   this is from /etc/group   -   libvirtd:x:114:olm,eucalyptus
<apw> thats not the user you pasted above though
<apw> libvirtd-qemu you said
<apw> <cybrocop> It should (according to the advertisement) drop privs to libvirt-qemu:libvirtd
<cybrocop> apw: Let me do an strace and get the exact user. Sorry for the confusion. I thought i may be libvirtd-qemu, but I have to admit it is not from docs, just my memory.
<apw> cybrocop, ok
<cybrocop> jk: hmm... what am I doing wrong here
<cybrocop> jk: root@srv-uec-qa-node02:~# strace -o /tmp/TRACE -f -e 'trace=open,setuid,seteuid' -p 945
<cybrocop> strace: invalid system call `seteuid'
<jk-> my bad, remove seteuid
<cybrocop> jk: ok
<cybrocop> jk / apw: I don't see any setuid  http://slexy.org/raw/s21B2A4Dlo
<cybrocop> furthermore, I remember, that when I set the path of the file to be /tmp/console.log (in libvirt.xml) the owner of the file was root
<sokeman> does anyone have a touch screen running in lucid?
<apw> sokeman, yes
<sokeman> i think i know how you did it but i have a proble,
<sokeman> problem*
<apw> cybrocop, does chacl -l say anything on any of the paths ?
<cybrocop> acl package was not installed. Should I get it?
<sokeman> lol its not installed
<sokeman> i had it working (kinda)
<cybrocop> root@srv-uec-qa-node02:/var/lib/eucalyptus/instances/admin/i-37DA0723# chacl -l .
<cybrocop> chacl: cannot get access ACL on '.': Operation not supported
<sokeman> it was clicking where i touched but it also click at the same moment the top left hand corner
<cybrocop> apw: I downloaded the acl package and above is the output.
<cking> lag, If our instruction modifies memory in an unpredictable fashion, add "memory" to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction. We also have to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm. 
<cking> lag, http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
<sokeman> before i even installed anything it clicked the topleft hand corner when i touch it and know i have deleted everything it still does it
<cybrocop> jk / apw: I just changed the path to "/tmp/console.log" to be sure... and it is indeed running as root. 
<cybrocop> root@srv-uec-qa-node02:/var/lib/eucalyptus/instances/admin/i-37DA0723# ls -l /tmp/console.log 
<cybrocop> -rw-r--r-- 1 root root 36541 2010-05-26 17:55 /tmp/console.log
<sokeman> apw: how can i find the driver that is seeing the input from the touch screen?
<lag> apw: #define barrier() __asm__ __volatile__("": : :"memory")
<apw> sokeman, do you know what type of touch screen it is ?
<apw> bah where did cybro... go
<sokeman> no i dont 
<sokeman> how can i find out?
<sokeman> apw: is there a way to find out?
<apw> cnd, how does one find out which touch driver you are using
<apw> Keybuk, is there an easy way to tell what was passed to upstart
<apw> Keybuk, ignore me, of course i can check its cmdline and environ
<ogra> manjo, eeek, my n900 has a progressbar on boot now !
<manjo> ogra, yep I noticed that too 
<JFo> heh
<ogra> how ugly 
<manjo> which means its loading more s**t 
<JFo> did you guys see the slide to unlock bar?
<ogra> bah and i get an ovi ad in the face right after booting
<ogra> hrm, and my theme is blue now
 * ogra hates blue
<manjo> ogra, I use humanity theme
<JFo> what did you guys update with?
<JFo> mine is still the same
<manjo> JFo, he probably kept the default theme
<JFo> ah
<apw> an _ad_ sounds a bit off ?  
<ogra> manjo, nope
<manjo> JFo, were you able to get portrait mode working ? 
<JFo> what do you mean?
<ogra> i had something brownish/yellowish 
<manjo> ogra, probably the EU roms are different 
<manjo> JFo, the browser is supposed to have portrait mode
<JFo> interesting, I never tried it
 * JFo experiments
<amitk> ogra: how did you manage to get all of that? scratch install? I just upgraded...
<ogra> manjo, i was using the shipped digital nature theme but with a different wallpaper
<ogra> and apparently it switched back to the default blue theme after the upgrade
<amitk> you could do a "apt-get update; apt-get dist-upgrade" btw
<ogra> but keeping the wallpaper
<smb> bjf, Oh, other channel talk reminds me. I sent you a mail about the lbm alsa updates for lucid. Have I just missed it or did you not reply?
<ogra> switching back to the digital nature theme gets me the right widget color but i forgot how i changed the wallpaper :P
<manjo> amitk, how do I get portrait mode in the browser 
<JFo> oh hey lag you may have noticed that I set some tix you are assigned to In Progress
<amitk> manjo: Ctrl+Shift+R enable it
<lag> JFO: Yep, got those, thanks
<JFo> :-)
<amitk> manjo: in browser, you need to enable it in settings too
<lag> JFo: I removed "kernel-suspend" and added "suspend resume" and "kernel-power" - I think that is correct
<JFo> k
<lag> JFo: That's the way it's documented in any case
<lag> =:-)
<apw> Keybuk, hey ... am a bit worried about this passing everything to init patch.  although it makes sense to 'init' passing all that crap to bash will not make it happy
<cybrocop> apw / jk : Sorry, had a power outage and dropped off. Did you respond to me by any chance?
<JFo> lag, you are correct
<cybrocop> apw / jk : Last thing I tried was to do an strace and capture getuid, but there was no observed dropping of privs. effective uid is root it seems. 
<apw> cybrocop, did you get just a full trace ?  without -e, if you could get than and pastebin it so i can look that would help
<lag> Thanks for confirming JFo
<cybrocop> apw, I'll do that. Right now there is still no power so the servers are down, but should come back within 30 mins.
<apw> cybrocop, ok
<JFo> lag, my pleasure, but you already knew you were right ;-0
 * JFo fusses at his right shift key
<pgraner> jk-: did you get the conf stuff setup?
<cnd> apw: you can check Xorg.0.log and grep for evdev
<cnd> that will show you all the /dev/input/event* files that are used for input
<cnd> then you can correlate those with lsinput
<cnd> but I don't know if you want info on input drivers that don't use evdev
<lag> JFo: Not true, I was meaning to ask you about it (lag==newbie - JFo==old_hand)
<JFo> heh
<cnd> lag, back on my first week in february, I went up to JFo and started asking him questions, and after a few "I'm not sure..." answers, he said he had only been here for three weeks up to that point :)
<cnd> old hands means you've been here a few weeks, so you'll be old hand pretty soon :)
<JFo> heh
<JFo> yeah, I remember that cnd :-)
<lag> People age quick here eh?!
<lag> :)
<amitk> lag: hair is acceptable loss in the line of duty
<lag> I've noticed ;)
<amitk> lag: I am sure you're not referring to apw here, he joined that way ;)
<lag> *whistles*
 * lag whistles 
 * apw rounds up a firing squad
 * lag retires to the shadows with smb
<amitk> :)
<Fjodor> Quick question: Does anyone know what's up with the source packages at http://kernel.ubuntu.com/~kernel-ppa?
<cnd> RAOF: so what will happen if I try to upgrade my nouveau machine to a maverick kernel?
 * lag treats himself to a lunch break for a change
<lag> bbs
<cnd> will it just work (like tgardner's), or do I need to update libdrm as well?
<tgardner> cnd, just try the maverick .deb first
<cnd> tgardner: ok, I'll try it out
<apw> Fjodor, what is your issue with them?
<Fjodor> apw: Well, mainly that they are in the low kb size area, so I suspect them to be rather empty ;-)
<apw> JFo, i had a thought when reviewing my 'kernel-needs-review' bugs ... and tagged those i wanted as kernel-candidate
<apw> JFo, is we all did that you'd be able to find them easy and review of them by us on monday if needed would be easy
<apw> Fjodor, bah
<JFo> yep, sounds great
<Fjodor> apw: ?
<apw> Fjodor, bah
<apw> i hate the mainline builds, there is always something or other wrong with them
<JFo> I was actually thinking we could use the kernel-needs-review as a method for me to present the ones I think need to be looked at to the reviewers
<apw> JFo, that is indeed what i means isn't it ?
<JFo> apw, I saw a comment that they were empty in a bug yesterday
<JFo> apw, indeed
<apw> i look at -needs-review and convert them all to  either -reviewed or -reviewed and -candidate
<JFo> so the system seems to be working :)
<JFo> I like it
<JFo> want me to add -candidate to the tagging page|?
<apw> and then you take the -candidates and add them to the list and we discuss the overflow on mondays
<JFo> sounds good
<apw> that way random bugs can't put themselves on the list, cause you are in the middle, but its all simple other than that step
<JFo> apw, ogasawara got the script done, so I am testing it now
<JFo> apw, yep
<apw> JFo, awsome
<Fjodor> apw: Ah ok, that sort of "bah". It's just that I have run into the otherwise known problem of qemu vms running extremely slow, have seen that increasing the tick frequency might help, and would like to try out a kernel as close to mainline as possible with that as the only change. At any rate, the source packages still should be built correctly, even if you dislike them, shouldn't hey?
<apw> Fjodor, i didn't say anything about the problem, only that i hate the builds en toto because they create a lot of work for me keeping them working
<JFo> brb
<Fjodor> apw: Ah, ok, but my question, then, would be "Who is responsible for the builds, whom I can talk to to get the source packages built correctly?" :-)
<apw> Fjodor, the other problem is the source package there is not a source package which can be used to build a deb. it is a raw source tree
<apw> and so even when i fix them, the next complaint will be that they are not what you wanted
<apw> Fjodor, i look after them
<apw> Fjodor, i assume you actually want to be able to build a kernel deb for yourself
<apw> Fjodor, ?
<Fjodor> apw: Well, I know how to use make-kpkg and such, as I have done so extensively on earlier occasions - I just wanted to install the sources via a source package from you, since I then gather that the sources would be the same as the ones used to produce the image debs :-)
<apw> Fjodor, unfortuanatly a -source package is only the linus source
<apw> and the linus source is exactly as it is in linus tree, at the commit mentioned so you can recover that easily
<apw> it does not give you the build machinary however
<apw> the BUILD.LOG contains the exactly commit that was built from
<Fjodor> apw: Ok, thank you - so there aren't any ubuntu specific patches applied to the sources that it would be easier for me to get in one package via you, as opposed to pulling a vanilla linux tree?
<apw> Fjodor, nope, the point of the mainline builds for testing is that they have no ubuntu delta, the only thing they have is an ubuntu style config
<Fjodor> apw: Ok, great - still, I noticed that I'm not the only one asking about the source packages on the ml - just saying. Thank you, though, I'll pull a vanilla tree :-)
<apw> Fjodor, yeah i'll put it on my todo list, though i will get moaned at they are useless next
<apw> i suspect not making them would make more sense, and makeing either a real source uploadable package or a tarball of the clean build tree would be of more value space wise
<Fjodor> apw: Well, just the tarball would have been enough for me, and as for them being useless, well, that was not my understanding or the case for my specific wants, but thank you for the answers :-)
<cnd> tgardner: when setting the version for an update to the linux-firmware* packages in lucid-updates, I remember there being an issue where the version had to be bumped like 1.24 to 1.25.1
<cnd> is that correct?
<tgardner> cnd, nope, it should be 1.24.1
<cnd> I see that's what happened for linux-firmware-nonfree in karmic-updates, but the normal version incrementing took place for linux-firmware in karmic-updates
<Keybuk> apw: but the kernel already passes anything it doesn't know to bash
<Keybuk> so bash has to handle it
<apw> right but nominally that is nothing right
<Keybuk> if you do init=/bin/bash foo bar baz then you deserve to break it ;)
<Keybuk> ahh
<Keybuk> right, so when you do init= only the arguments *after* init are passed
<Keybuk> we want to preserve _that_ behaviour
<Keybuk> it's when you have no init= on the command-line, it passes everything it doesn't know - we want that to just pass everything
<Keybuk> so "default init" if you like
<apw> well actually i think all unknown ones are passed, but the majority of options are known
<Keybuk> apw: no, init= does limit it to only those after init=
 * ogra wants console= 
<apw> the problem is that the semantics change as you drop down
<ogra> :)
<apw> Keybuk, you sure, i haven't seen the code which does that anywhere
<Keybuk> apw: almost entirely positive
<apw> the real issue is that the behaviour changes as you fall down the list
<apw> we may want to pass 'all' to */init, but 'minimal' to /bin/bash and /bin/sh
<apw> Keybuk, ok found the code which does init=
<apw> Keybuk, and yes it does zap 'before'
<apw> but that doesn't work for the default case
<apw> Keybuk, one option might be to not pass them on the command line
<apw> but make them into environment variables
<apw> in the 'all' mode
<apw> so if there is no arg we do like 'quiet=true' in the environment instead
<Keybuk> apw: the default case will never be bash though
<apw> that would maintain the command line semantics
<Keybuk> I don't see the problem with the default case passing the "known" command-line options as well as the unknown ones
<Keybuk> right, I don't *want* to maintain the command line semantics
<apw> Keybuk, right but to allow fallback which will work i need to make and maintain _two_ command lines
<Keybuk> I want to change them
<apw> right but the semantics are compatible with /bin/bash and /bin/sh right now
<Keybuk> why the fallback?
<apw> so we can literrally do
<apw> exec '/sbin/inint'
<Keybuk> but you can't have /bin/bash as init= without passing init= which *changes* the semantics anyway
<apw> exec '/init'
<apw> exec '/bin/bash'
<Keybuk> yes, but that's a bash script
<apw> exec '/bin/sh'
<Keybuk> not /bin/bash
<Keybuk> so won't pass any of the arguments
<apw> yes but that is a different path
<Keybuk> if you copied /bin/bash *to* /sbin/init - then yes, it would cause unknown arguments to get passed to bash
<Keybuk> but nobody ever does that
<apw> if you say init= then we do bash semantics for everything
<apw> if you don't then we do run init, and fallback to bash using the same semantics
<Keybuk> if you say init= only the arguments on the command-line *after* init= should be considered
<Keybuk> what?
<Keybuk> we don't fallback to bash!
<apw> yes we do
<Keybuk> if the kernel doesn't see /sbin/init, it falls back to bash?
<apw>         run_init_process("/sbin/init");
<apw>         run_init_process("/etc/init");
<apw>         run_init_process("/bin/init");
<apw>         run_init_process("/bin/sh");
<Keybuk> oh, wow, I didn't know that :p
<apw> that has always be the way in unix world
 * ogra never saw that working
<ogra> it usually panicks before it gets there
<apw> and its that semantic which we break if we pass everythign on the command line
<Keybuk> apw: hmm, but that would break today anyway right?
<Keybuk> because the kernel would still pass "splash" to bash
<Keybuk> so would really run "/bin/sh splash"
<apw> that is possible yes
<Keybuk> and would break in recovery mode
<Keybuk> because it would run "/bin/sh single"
 * apw considers, it does appear so
<apw> unless single is known which i assume it cannot be
<apw> so the fallbacks are just useless
<ogra> apw, so why do i get a panic if i rm /sbin/init and dont end up at a shell 
<ogra> with the above i should never see a kernel panic caused by init missin
<apw> ogra, perhaps because you have splash on the command line, as Keybuk points out
<ogra> i dont think it tries to actually spawn the shell 
<Keybuk> apw: it can't be known, since otherwise init wouldn't see it ;-)
<apw> right
<apw> so its mostly useless
<apw> Keybuk, so it is possible we need an early_param to turn off this new behaviour just in case
<apw> no we have init= to fix everything
<Keybuk> right, init= fixes everything, no?
<Keybuk> you can always stick init=/sbin/sulogin on the end
<apw> Keybuk, yep that override makes me happy, thanks
<vanhoof> ogasawara: ping
<ogasawara> vanhoof: pong
<bjf> moin all
<JFo> moin bjf 
<vanhoof> ogasawara: lmk when you have a few to talk, i know its early for you
<ogasawara> vanhoof: I have time now
<JFo> aw lookit vanhoof trying to get some time with the release queen :)
<vanhoof> ogasawara: cool
<ogasawara> vanhoof: mumble?
<apw> i don't see him doing enough bowing
 * vanhoof bows
<vanhoof> apw: hey, ogasawara became my best friend last night ;)
<bjf> JFo, you going to expire some more today? I've done all I can for now
<JFo> yeah
<JFo> not sure how many though
<JFo> looks like I'm still hitting some vague limit on how many I can process
<bjf> JFo, just remove the limit and let it do all with the given params
<apw> JFo, where is that chart again ?
<bjf> JFo, http://status.qa.ubuntu.com/qapkgstatus/linux
<JFo> bjf, i have
<bjf> http://status.qa.ubuntu.com/qapkgstatus/alsa-driver
<apw> JFo, any idea why there is going to be a jump in triaged bugs ?
<bjf> JFo, are you running it on cranberry?
<JFo> bjf, no on my local machine
<JFo> apw, because I am setting some to triaged
<apw> JFo, heh ahh then that makes sense
<JFo> bjf, I wish the linux graph looked more like that :)
<JFo> apw, yeah, I have been trying to use triaged appropriately, but I need to define its role in our plans
<bjf> JFo, don't understand why the connected yellow line didn't connect
<JFo> it hasn't run it's daily yet
<cybrocop_> Hi apw, finally got the trace. Are you around?
<apw> yep
<apw> pastebin it
<cybrocop_> apw: Here  http://slexy.org/raw/s2I1ZYzm8k
<cybrocop_> search for console.log
<bjf> JFo, check out bug 466716 (the last comment after I expired the bug)
<ubot2> Launchpad bug 466716 in alsa-driver (Ubuntu) "No sound after upgrading to 9.10 desktop from 9.04 desktop. (affects: 16)" [Undecided,Expired] https://launchpad.net/bugs/466716
<cybrocop_> apw, let me change the location of the file to /tmp/console and you can compare it with a successful run.
<bjf> JFo, the username is "special" and the comment means nothing to me
<JFo> heh
<apw> cybrocop_, it think this is your issue, this is running as root yes, but it also capsets itself into a non-priviledged state
<JFo> well, I am out for a bit of lunch goodness away from the house. bbiab
<apw> 9600  capset(0x20080522, 9600, {0, 0, 0}) = 0
<cybrocop_> So it has something to do with cgroups?
<apw> no it has something to do with capabilities, it appears the server is deliberatly dropping its priviledges
<apw> which means that it run as uid with none of the advantages, so if root is not in the group it cannot write there
<apw>        CAP_DAC_OVERRIDE
<apw>               Bypass file read, write, and execute permission checks.  (DAC is
<apw>               an abbreviation of "discretionary access control".)
<apw> specifically it has dropped that capability, so root no longer has its 'all your files are mine' ability
<apw> cybrocop_, it seems like a bug in the way the services are owned to me
<apw> cybrocop_, i would tend to blame ecalyptus, where do they hang out
<cybrocop_> apw, hmm. they are on #eucalyptus
<cybrocop_> but kvm is not eucalyptus
<cybrocop_> It would be more of a kvm/qemu issue no?
<ogasawara> JFo: did that new buglist script run ok for you?
<cybrocop_> apw: All they're involved in is the creation of the libvirt.xml file, which tells the kvm instance what to do (what devices to have, etc...) 
<cybrocop_> apw: here is the libvirt.xml generated by them. http://slexy.org/raw/s2KPFinewG  They don't seem to include any directives that would limit a vm's capabilities
<apw> 9600  capset(0x20080522, 9600, {0, 0, 0}) = 0
<apw> 9600  execve("/usr/bin/kvm", ["/usr/bin/kvm", "-S", "-M", "pc-0.12", "-enable-kvm", "-m", "896", "-smp", "1", "-name", "i-46D20834", "-uuid", "fe3c868b-861b-bcad-18c6-e5f667c9"..., "-nographic", "-chardev", "socket,id=monitor,path=/var/lib/"..., ...], [/* 2 vars */]) = 0
<apw> cybrocop_, its not kvm's fault
<cybrocop_> I mean virsh
<cybrocop_> I use teh command: virsh start <domain>  ... this communicated with libvirtd... eucalyptus is not involved here.
<cybrocop_> apw: I thought libvirtd is the same as kvm... but I guess they're different packages.
<apw> ok then its libvirtd thats at fault
<cybrocop_> I know there is this new cgroup features (or maybe its called lxc).  Do you think it has something to do with that? Maybe there's a libvirtd config option that specifically limits it this way (I couldn't find anything in the libvirtd.conf).
<cybrocop_> apw: for security purposes maybe?
<apw> cybrocop_, you are beyond my knowledge of userspace.   all i can see is that the caller of KVM has dropped its creds, so the behaviour is correct, that file is not creatable for a nutered root process
<apw> i would think libvirt is under #ubuntu-servers perview
<cybrocop_> apw: Thanks a lot. You were very heplful. At least I'm a step closer to identifying the problem.
<cnd> cking: is it true that a laptop hanging on the second suspend is a bios bug?
<cnd> or is there potentially something we can do in the kernel?
<cking> cnd, it depends ;-)
<cking> cnd, it could be dodgy drivers or something deeper. 
<manjo> cking, can you make your programs exit/return 0 for pass 1 for fail ? 
<cking> manjo, 0 = ok, 1 = fail
<manjo> 0 for pass and errno for fail which ever makes sense 
<cking> manjo, yep
<manjo> will you have a situation where the result is unresolved ? 
<cking> manjo, don't think so - it's pass or fail
<manjo> ok
<cnd> cking: can you expand a bit on the suspend issue?
<apw> ogasawara, just updated the trend lines for maverick ... approximatly
<ogasawara> apw: we're actually below the line!
<apw> ogasawara, heh you did close about a months worth of work-items with your upload :)
<apw> i don't expect it to stay that way
<ogasawara> apw: true.  I suspect this will the the one and only time we're below :)
<apw> heh one reason i didn't get the history removed so we can see the work appearing
<ogasawara> apw: yah, someone just slammed a kernel config bug to the config blueprint, and it's got over 100 config request changes
 * ogasawara just about fell over when I read it
<apw> ogasawara, who the heck, whats the bug number ?
 * apw frootles about for his gun
<ogasawara> apw: don't know who it was, some random bug subscriber who sent me a heads up they linked it to the blueprint
<ogasawara> apw: bug 446480
<ubot2> Launchpad bug 446480 in linux (Ubuntu) "karmic kernel configuration gotchas... (affects: 2) (heat: 22)" [Medium,Triaged] https://launchpad.net/bugs/446480
<apw> ogasawara, karmic ?
<ogasawara> apw: originally was targeted for karmic, I'm inclined to rip it from the blueprint
<ogasawara> apw: was going to give it a quick once over first to see if the requested config changes are valid for Lucid
<cnd> brb, rebooting to a test kernel
<ogasawara> s/Lucid/Maverick
<apw> i had a look at the 'key critical' ones and they are already as specified
<apw> ogasawara, i'd tend to do no more than see which ones are as he has already asked for
<apw> and those which are not just ask for justification
<apw> i would only do it if you can do it as a script, no handy doing it
<ogasawara> apw: ack
<apw> ogasawara, and really the two he is bitching about are MCE and PAT i think
<apw> and they are as he says
<ogasawara> indeed
<apw> i recon you could justify saying 'X86_PAT and X86_MCE are both set now as expected.  As we are now two released furter on could you regenerate your list based on the current discrepancies"
<apw> "and provice justtification for each"
<apw> noting that he has done good justifications for the first two
<ogasawara> apw: agreed, I'll slam a comment in there
<apw> you have enough shit to do
<apw> ogasawara, we maybe below the line overall, we are above it for a-1
<anoteng> Anybody here familiar with git-bisecting a ubuntu kernel? I fear I keep building the same packages over and over... Anybody care to take a look at my commands and see if I'm doing anything stupid? http://pastebin.com/Rfif04jx
<apw> http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-1.html
<apw> anoteng, looks right to me
<apw> the version number won't change with each bisect i suspect
<ogasawara> apw: damn, just a few work items over for a-1.  wonder what I've got I can close.
<anoteng> that's what got me worried.. that, and the fact that I've only found good kernels too this point. Will continue like before then...
<anoteng> apw: thanksâ¦
<apw> we only change the version number at "start new release" a
<apw> and at "bump abi"
<apw> anoteng, ^
<anoteng> ok. thanks..
<bjf> cking ping
<manjo> smb, have the lbm updates happened ? 
<smb> manjo, Lucid, no due to missing bug references
<manjo> ok thanks 
<manjo> smb, any eta on when we can expect ? I need to update a bug with that info 
<smb> manjo, as tgardner had some wireless things to add and with current things going probably mid-next week
<manjo> ok thanks 
<stenten> is anyone here familiar with bug #404064?
<ubot2> Launchpad bug 404064 in linux (Ubuntu Karmic) (and 2 other projects) "KMS error message while intializing modesetting (during boot and resume) - render error detected, EIR: 0x00000010 [i915] (affects: 51) (dups: 3) (heat: 294)" [Medium,Fix released] https://launchpad.net/bugs/404064
<cnd> lag: as root:
<manjo> lag, https://rt.wiki.kernel.org/index.php/Ftrace
<cnd> echo 'function_graph' > /sys/kernel/debug/tracing/current_tracer
<lag> http://www.mjmwired.net/kernel/Documentation/trace/ftrace.txt
<cnd> then, as root or as normal user, cat /sys/kernel/debug/tracing/trace
<stenten> i have another bug (584475) that looks like a duplicate, but the original one i mentioned is already marked as "Fix Released", so I'm not sure how to triage it. Do I re-open the fixed bug?
<manjo> stenten, you could dup it 
<apw> cnd, fdr binary-perarch
<cnd> apw, thanks!
<cking> bjf, sorry, missed your ping, I was plowing through some email backlogs
<bjf> cking, np, i worked it out myself
<stenten> manjo: I've dup'd it and told them to add a comment that they were still affected, and include their kernel version. Thanks.
<bjf> cking, i'd just confused myself
<cking> bjf, happens to me all the time too when it comes to these webby tools
<cking-afk> back in 18
<cnd> JFo: ping
<kees> how do I create (and push) various topic branches?
<kees> more specifically, if I have a clone of linux-2.6, and I have 3 different sets of patches, how do I build up the 3 branches?
<cnd> kees: for the master kernel tree?
<kees> cnd: yeah.
<kees> cnd: I have this: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=summary
<kees> cnd: I want to have three branches with a subset of the 5 commits on top there spread out in them.
<kees> i.e. "master" would be real upstream master, and I'd have "nx-emu", "symlink", "hardlink" branches.
 * kees is such a git newb.  ;)
<cnd> kees: why do you want three separate branches? to test each patches individually?
<smb> kees, from master you would do a git checkout -b name 
<ogasawara> kees: git checkout -b nx-emu
<kees> but won't that branch from the current location (instead of HEAD minus 5)?
<ogasawara> kees: indeed, will checkout from the tip
<cnd> kees, if you want a branch from a specific location, you can "git checkout <sha id of commit> && git checkout -b <new branch name>"
<kees> how do I back up?
<ogasawara> kees: but once on the branch you could then git reset --hard HEAD~5
<kees> ah-ha
<smb> kees, I think you want to create the branches from before and then cerry pick
 * abogani2 agrees ^
<smb> git checkout -b name sha1
<cnd> kees: we're giving you three separate ways to do the same thing :)
<kees> \o/
<cnd> kees: but I still wonder, why do you need three separate branches?
<cnd> is it for testing each patch set isolated from the rest?
<smb> where sha1 is the sha id of the commit before you added the 5
<smb> but what ogasawara said works the same. too many choices. :)
<kees> excellent, yes.  working on it now
<smb> kees, for pushing you will just say git push repo branch. eg. git push origin version1 
<smb> whatever you named your branch
<cnd> tgardner: have you uploaded the new linux-firmware package to lucid-proposed?
<cnd> I'm going to check for the SRU procedure on the bugs it will fix
<tgardner> cnd, its in the queue
<cnd> tgardner: thanks
<kees> \o/ branch topics of my very own.  :)  thanks guys.
<kees> http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=heads
<tgardner> kees, now you can easily keep your master branch up to date by 'git checkout -f master;git fetch origin master;git reset --hard FETCH_HEAD', then update your branch thusly: 'git checkout -f hardlink;git rebase master'
<kees> tgardner: you anticipated my next question.  ;)
<kees> tgardner: why the "-f"?
<tgardner> kees, force, it overwrites any local changes.
<tgardner> kees, my clean sequence to ensure a pristine tree is 'git checkout -f;git clean -f -d;git ls-files --others --directory |xargs rm -rf;rm -rf .git/rebase*'
<kees> hm, I think I'll leave off the -f in case I'm a dork and forget something.  :)
<tgardner> kees, you can always check using 'git status'
<kees> true
<kees> oh! one more question... how do I set my "push" target to be ssh+git://zinc....  ?
<tgardner> kees, you can either specify the push repo directly, or you can add a remote in order to make it a bit simpler.
<kees> i.e. this is wrong:
<kees>   Fetch URL: git://kernel.ubuntu.com/kees/linux-2.6.git
<kees>   Push  URL: git://kernel.ubuntu.com/kees/linux-2.6.git
<kees> the "fetch" is fine, but the "Push" is wrong
<tgardner> git:// is read only.
<kees> right
<tgardner> add a remote like this 'git remote add rtg zinc.canonical.com:/srv/kernel.ubuntu.com/git/rtg/ubuntu-lucid.git'
<tgardner> then you can 'git push rtg branch_name'
<tgardner> alternately, you could also 'git push zinc.canonical.com:/srv/kernel.ubuntu.com/git/rtg/ubuntu-lucid.git' branch_name'
<kees> git remote set-url ?
<kees> yeah, I want to avoid the full URL every time I push.
<tgardner> kees, I've never used set-url
<kees> ah-ha, yes, that did it:
<kees> git remote set-url origin ssh+git://zinc/srv/kernel.ubuntu.com/git/kees/linux-2.6.git
<tgardner> kees, ok, now you can use a simple 'git push origin hardlink'
<tgardner> kees, note that after rebasing your branches against master you'll have to 'git push --force origin hardlink', etc
<smb> tgardner, don't teach him that dangerous stuff ;-)
<smb> kees, git push origin +branch does the same
<tgardner> smb, there is a reason I grant write access to only a few devs
<smb> :)
<tgardner> kees, with your ptrace patch, what is an example of a process taht I _should_ be able to strace? I'd have thought my login shell would be a child of sshd or bash
<JFo> cnd, sorry about that I am back now
<cnd> JFo: actually, I think I'm ok
<cnd> thanks for getting back to me though :)
<JFo> sure, sorry it took so long
<tgardner> kees, never mind, I figured it out.
<ilpuccio> hello
<ilpuccio> I'm on lucid, I'd like to installa kernel 2.6.34 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/linux-image-2.6.34-020634-generic_2.6.34-020634_amd64.deb
<ilpuccio> but installing nvidia drivers It said that kernel was compiled with gcc 4.2? Is it normal? I'm running 2.6.32 and I have installed nvidia's drivers without any problem
<cnd> ilpuccio: the mainline kernel should have been built with the same gcc as the 10.04 kernels are built with
<tgardner> ilpuccio, can you use the neoveau driver?
<ilpuccio> tgardner, not tried.
<ilpuccio> tgardner, is there a way to check the compiler used for the kernel ?
<tgardner> ilpuccio, the backported kernel is not intended to support the desktop, but I know for a fact that it still works with nouveau
<cnd> tgardner: heh, I just remembered that I'm booted on 2.6.34-4 with nouveau and lucid libdrm :)
<cnd> seems to be working fine
<ilpuccio> tgardner, I'll try but that are the opensource, right ? It sound strange to me the fact that nvidia detect a different compiler for 2.6.34
<tgardner> ilpuccio, you're running lucid, right?
<ilpuccio> tgardner, yes
<tgardner> the backport was built using the lucid toolchain
<manjo> have you guys seen the review on Lucid on toms hardware, it looks pretty good... http://www.tomshardware.com/reviews/ubuntu-10.04-lucid-lynx,2634.html
<Sarvatt> can I see your /var/log/Xorg.0.log cnd? :)
<kees> tgardner: basically you can ptrace anything that is a direct child, so "strace ls" or "gdb ls" will work.
<kees> tgardner: strace -p  and gdb "attach" won't (without sudo)
<kees> so, isn't "git push hardlink" the same as "git push origin hardlink" ?  due to the branch tracking?
<tgardner> kees, it might be, but its a form I'm unfamiliar with.
<ilpuccio> hey guys .... head /usr/src/linux-headers-2.6.32-22-generic/kernel/bounds.s is 4.4
<ilpuccio> head linux-headers-2.6.34-020634-generic/kernel/bounds.s is 4.2
 * bjf is done for now, his head feels like it's going to explode
<ilpuccio> dunno if matters
<cnd> mpoirier: https://wiki.ubuntu.com/KernelTeam/KernelBugFixing?highlight=(send\-email)|(git)
<ilpuccio> thanks bye bye 
<JFo> cnd, that looks like one that could be cleaned up and moved over under Kernel/
 * JFo whistles innocently :)
<cnd> JFo: heh, it's actually in pretty good shape, but it could use breaking up into sub pages
<JFo> :-D
 * JFo updates his n900
<cnd> JFo: weren't we going to divide up the pages and assign people to migrate them to the new wiki setup?
<cnd> I work better when I have tasks assigned to me :)
<JFo> yeah, I was just picking on you, but we do need to look at that
 * JFo assigns tasks to cnd :-P
<cnd> if you want to assign it to me, add a task on a blueprint or send me an email
<cnd> otherwise I'll forget :)
<JFo> nah, just picking on you
<JFo> I want to have some time to discuss it
<JFo> maybe tomorrow on mumble
<ogasawara> mpoirier: BugLink: http://bugs.launchpad.net/bugs/584920
<ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1) (heat: 6)" [Medium,Confirmed]
<ogasawara> mpoirier: and Subject I'd suggest "[Lucid] [PATCH] UBUNTU: Fixing ARM Lucid bug 584920"
<ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/584920
<RAOF> cnd: The chances are good that upgrading your nouveau machine to the maverick kernel will work; we've got an appropriate libdrm.
#ubuntu-kernel 2010-05-27
<cnd> RAOF: yep, I confirmed through testing earlier :)
<cnd> upgraded the kernel and it still worked
<Sarvatt> cnd: sure you aren't just using nv now?
<RAOF> I'm using nouveau.
<RAOF> I can tell, because my system both suspends *and* resumes.
<lifeless> lol
<bjf> akgraner, just saw that the kernel team meeting minutes showed up on The Fridge
<jk-> pgraner: ping?
<RAOF> cnd: Hm.  I was missing some important context there.  You mean to say that you're using the Maverick 2.6.34 kernel *on Lucid* and nouveau is working?  Can I get an Xorg.0.log?
<JFo> RAOF, Tim is using it too and it works
<JFo> rather tgardner
 * JFo heads off to bed
<cnd> RAOF: correct
<cnd> let me send you an email with my log
 * smb awakens
<cking> morning smb
<smb> morning cking 
<amitk> morning guys
 * smb waves to amitk 
<cooloney> smb: cking and amitk morning
<smb> Hey cooloney 
<cooloney> smb: GrueMaster tested lucid security kernel for imx51
<cooloney> it boots 
<smb> Ok, so I can tick that off
<cooloney> smb: but i just wander, is this security updates rebased on our lucid latest fsl-imx51 code?
<smb> cooloney, Just for completeness, though likely less important. Anything on the Kamric fsl-imx51. Think that needs different hw
<cooloney> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/fsl-imx51
<smb> cooloney, No there are some changes that were never uploaded in them (see one of the notes in the original email)
<smb> Those will need to wait until I do a rebase for proposed uploads
<cooloney> smb: ok, understood. hehe
<cooloney> smb: since GrueMaster said the eth0 ifdown issue is still there in the security kernel. 
<smb> So it certainly might be. :)
<smb> s/might/will/
<cooloney> smb: and GrueMaster will test Karmic kernel when he wake up 
<smb> cooloney, Ah ok, most excellent
<ikepanhc> apw: smb: I am going to submit a talk on Taiwan conference for open source coders. current plan is talking about how to packaging ubuntu kernel (ex:git,base,delta... etc), regression (and why we take it serious). You are the expert of this. Can you help me review after I finish the slide for it?
<smb> ikepanhc, Sure will do
<ikepanhc> smb thanks :D
<apw> ikepanhc, yep
<ikepanhc> apw: thanks :) it may take me 1 or two weeks
<kraut> hi
<kraut> anyone an idea what's going wrong while umounting cifs shares? http://pastebin.com/dvwnH51h
<kraut> it's reproduceable
<cooloney> ikepanhc: that's a great topic
<cooloney> ikepanhc: can you share your slide for me as well?
<ikepanhc> cooloney: sure, after I finish it
<cooloney> ikepanhc: maybe next time we can give this kind of speech in Shanghai or Beijing. 
<ikepanhc> cooloney: I plan to use it on COSCUP and UHS
<smb> kraut, Hm, I am not sure. Sounds a bit familiar. Have the feeling there might be something in latest stable. Let me look
<kraut> thanks
<kraut> searched in launchpad but found nothing. via google i found one entry but when i clicked on it, i got a 404
<kraut> really strange
<smb> kraut, commit 793c338bac6fa1fb94504a0346f43e87d24b5daa
<smb> Author: Jeff Layton <jlayton@redhat.com>
<smb> Date:   Tue May 11 14:59:55 2010 -0400
<smb>     cifs: guard against hardlinking directories
<smb>     
<smb>     commit 3d69438031b00c601c991ab447cafb7d5c3c59a6 upstream.
<apw> smb, YEEKS
<smb>     When we made serverino the default, we trusted that the field sent by the
<smb>     server in the "uniqueid" field was actually unique. It turns out that it
<smb>     isn't reliably so.
<smb>     
<smb>     Samba, in particular, will just put the st_ino in the uniqueid field when
<smb>     unix extensions are enabled. When a share spans multiple filesystems, it's
<kraut> +	 * uh oh -- it's a directory. We can't use it since hardlinked dirs are
<kraut> +	 * verboten. 
<kraut> rofl
<smb>     quite possible that there will be collisions. This is a server bug, but
<smb>     when the inodes in question are a directory (as is often the case) and
<kraut> denglish for runaways
<smb>     there is a collision with the root inode of the mount, the result is a
<smb>     kernel panic on umount.
<kraut> am i the only one who hits that bug!?
<smb> Maybe not, otherwise it would not have been fixed. But here, yes denke schon
<kraut> that must be verboten! ;)
<smb> Very much :)
<kraut> hmmm, i need the fsck a workaround
<kraut> aaah, i think i got it
<kraut> brb, rebooting
<cooloney> apw: will the local "fdr binary-omap" command  run d-i/udeb stuff?
<cooloney> apw: because i can use my cross compile to build a kernel package
<cooloney> but it still failed in our PPA native builder
<ikepanhc> cooloney: is PPA supported ARM arch?
<apw> cooloney, no it won't   fdr binary-arch does that
<apw> cooloney, and even then you might need to touch /CurrentlyBuilding in your chroot
<cooloney> ikepanhc: oh, yeah, it will send it to our ARM hardware builder because in our package arch=armel
<cooloney> apw: ok, this answer helps me a lot
<cooloney> so i can test it locally before i dput it to ppa for building
<apw> ikepanhc, in some PPAs it can be enabled, not generally
<cooloney> the ARM building will cost me 6 hrs to know the result
<apw> cooloney do you know about sbuild ?
<apw> that uses qemu to emulate arm in an arm chroot, so you use the native compiler
<apw> that takes about 2 hours a build for me
<cooloney> apw: wow, cool man, i just heard the name of sbuild or pbuild
<cooloney> apw: is there any wiki about that?
<cooloney> i really wanna to setup such environment
<apw> cooloney, not that i know about, i got pointed to it vaguly recently.  i installed 'ubuntu-dev-tools'
<kraut> smb: fixed it with using the mount-option "noserverino". thanks for that info
<apw> mk-sbuild --arch armel maverick
<apw> then that makes this special armel chroot
<apw> then you can make a the source package and build it with
<apw> sbuild -d maverick-armel *.dsc
<smb> kraut, Welcome. And the fix should get into one of the next updates
<apw> it does take about 2x the time it takes to do a crosstools build, but it really uses the arm compilers etc
<cooloney> apw: ok, let me try that. how's your build machine configuration? i guess it is very powerful
<cooloney> and it still needs 2 hrs?
<kraut> smb: that's fine
<apw> its a 4x
<apw> cooloney, you could do the build on emerald though
<cooloney> apw: but we might need ask for installing some package as root
<cooloney> sudo apt-get install ubuntu-dev-tools
<cooloney> in emerald
<apw> cooloney, that is possible
<apw> what you got to compile on locally ?
<cooloney> apw: normally, i cross compile the kernel for arm arch such as fsl-imx51 and ti-omap4
<cooloney> fdr clean && export $(dpkg-architecture -aarmel) && CROSS_COMPILE=arm-none-linux-gnueabi- fdr binary-omap4
<cooloney> apw: with this command
<cooloney> it will generate a kernel package in the parent dir
<apw> cooloney, yeah, but i've not found that works when you make the tools package etc, and as you found does not make the udebs
<apw> i've used that form myself for most of lucid
<cooloney> but i uploaded my source package to PPA, it failed to build because of d-i/udeb
<cooloney> right
<cooloney> apw: agree, 
<cooloney> apw: so sbuild is the solution maybe, right?
<apw> cirtianly it worked well for me, though its slower by some margin than crossbuilds, its some 3x the speed of a PPA for me
<apw> and on emerald it would likely be faster yet
<cooloney> apw: ok, i will try it. at least it is much faster than PPA
<cooloney> apw: what's kind of CPU and memory do you have in your build machine running sbuild
<apw> cooloney, emerald is on karmic and the tools don't exist
<amitk> smb: going to linuxtag?
<smb> amitk, Yep
<amitk> registered already?
<smb> amitk, Err, doh! nope
<smb> amitk, Is there actually need? I only see registration for those who want to exhibit
<amitk> smb: dunno. I am thinking if I should go. Some interesting talks...
<smb> amitk, Yeah, and its not too far from my place. :)
<smb> amitk, The hotel question was open, which reminds me to ask again
<cooloney> apw: thanks a lot, building in sbuild now
<apw> cooloney, awsome ... 
<apw> cooloney, hope its less than 6 hours
<amitk> cooloney: it's probably worth adding to kernelmaintenancestarter page for arm flavours
<cooloney> amitk: right, will do soon
<cooloney> apw: yeah, my machine is 4 core and 4G ram 1TB disk
<apw> cooloney, so i'd guess more like 2 hours max
<apw> which is a 3 builds a working day instead of one
<cooloney> apw: great, man. hehe
<ogra> dont forget that you build for lucid, not maverick ;)
<ogra> (mk-sbuild --arch armel lucid)
<cooloney> ogra: yeah, i am build for lucid
<cooloney> apw: did you see this before? building in sbuild stops at 'Unpack source', doesn't move on
<cooloney> http://pastebin.ubuntu.com/440341/
<apw> cooloney, nope
<cooloney> apw: need i setup gpg key in sbuild?
<apw> that will take a while but not more than minutes
<apw> i didn't no
<cooloney> ok, 
<cooloney> apw: so weird. it stops there for ever
<apw> there should be a process doing something
<apw> what does it seem to be doing
<cooloney> dpkg-source is eating my 100% cpu from my 'top'
<Kano> hi, how to DISABLE building perf tools?
 * cooloney reboots and try again.
<Kano> how about adding a ringbuffer patch?
<Kano> http://intellinuxgraphics.org/h264.html
<apw> Kano, do_tools=false i think
<Kano> will try
<apw> Kano, check debian/rules/0-*
<apw> you can add that to your amd64.mk and i386.mk
<apw> Kano, the kernel components are in maverick already according to that page
<Kano> hmm
<Kano> but for 2.6.34 rc5 you needed a patch
<Kano> and this does not fully apply now
<apw> hrm, i see, missread the stupid page. i suspect its aimed to .35, and we'll get it then
<Kano> basically the rejects could be fixed
<Kano> just you have to change a bit more, a workaround was active in one file
<apw> Kano, its a pretty massive patch, not something we'd be that interested in worrying about till we get to our base release
<apw> pgraner, we have a number of blueprints without priority, and none of us seems to have the touch to change them
<pgraner> apw: nice
<Kano> it would be an interesting patch for the edgers ppa
<apw> pgraner, any idea how we get the ability ?
<Kano> one thing i struggled last time was when i used
<pgraner> apw: no, in the LP context blueprints are a black art... I'll give you a call in a few and we can walk thru them and I'll set
<Kano> http://www.splitted-desktop.com/~gbeauchesne/libva/ironlake.patches/ubuntu.lucid/kernel/
<Kano> those patches are basically against lucid
<apw> pgraner, this view http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team.html has a good view into them
<Kano> i created the binary-headers too
<Kano> but
<apw> Kano, if X think they are of interest then there might be some point in doing them in edgers
<Kano> why do they still need a patch?
<Kano> like
<Kano> http://www.splitted-desktop.com/~gbeauchesne/libva/ironlake.patches/ubuntu.lucid/linux-libc-dev/
<Kano> this was not in the libc-dev
<apw> Kano, the split out headers are a subset and stuff not added in the correct way can go astray during stripping, indeed that is common with new stuff
<Kano> the same header is always shipped
<Kano> hmm
<Kano> most likely the patch should be updated
<Kano> to patch directly the source
<Kano> looks a bit weird
<apw> Keybuk, you about ?
<apw> Keybuk, think i have a clean-ish patch to allow setting the kernel arguements, my debugging says its doing the right thing
<apw> Keybuk, so what form do you want this to do testing
<ogra> apw, will it hand over console= options ? 
<apw> ogra, it hangs over literally everything on the command line
<apw> hands
<apw> no exceptions
<ogra> (arm and mobile are eagerly waiting for a way to autospawn gettys on serial consoles via upstart, thats a requirement for it)
<ogra> though its still not clear to me how to distinguish if you have multiple console= options, i wish the kernel would require enumeration for them
<ogra> apw, awesome :)
<apw> http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team.html
<ogra> geez, i didnt know devicetree was essential for maverick !
<ogra> "mounting /proc and /sys automatically" oh sweet, we wouldnt need fstab anymore !
<Keybuk> apw: kernel in a ppa is always good
<abogani2> cnd, apw: FIY I built lowlatency kernel on my PPA (https://launchpad.net/~abogani/+archive/broken) it is based on Lucid but for Maverick packaging is same. I can provide the patch (that is the contents of debian.lowlatency dir plus a little hack in debian/) or a git tree if you need. I hope that simplify your review work.
<pgraner> tgardner: ping
<tgardner> pgraner, yo
<apw> abogani2, sure if you can point me at a git tree that would be great
<apw> Keybuk, ack
<apw> ogasawara, i see your current tip is an abi bumper, but the abi is not bumpered
<apw> ogasawara, sorry not an abi bumper per-see, missing modules even
<abogani2> apw: Sure but consider that the package in actual form don't include linux full source code copy so a fresh just cloned Maverick git tree could be deceivingly. Moreover should I use your ubuntu-debian.git as base? At the moment I have implemented, what seem to me, the Lucid way: so there are three directories debian/, debian.master/ and debian.lowlatency/.
<apw> abogani2, don't worry about ubuntu-debian, i'll send you a pull request when thats ready to merge into there
<apw> abogani2, but seeing the tree is very helpfil
<abogani2> apw: Ok. Thanks.
 * abogani2 goes to prepare the git tree
<apw> Keybuk, ok, the init argument handling is building in my green PPA: https://edge.launchpad.net/~apw/+archive/green/+packages
<apw> Keybuk, and the union mount enabled kernel is still in purple: https://edge.launchpad.net/~apw/+archive/purple/+packages
<Keybuk> cool, can you mail me to remind me to test?
<cnd> apw: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide?highlight=(request\-pull)
<apw> Keybuk, email away
<pgraner> tgardner: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567681
<ubot2> Debian bug 567681 in btrfs-tools "please add -a to fsck.btrfs" [Wishlist,Open]
<cnd> Keybuk: do you know if we can remove the modalias for vga16fb now, or do we need to wait for some userspace changes?
<Keybuk> well, you _can_
<Keybuk> there will be consequences though
<Keybuk> a zillion screaming nvidia-glx users
<Keybuk> we haven't done the bit that goes in its place
<cnd> Keybuk: ok, then we'll wait, thanks!
<cnd> crimsun: will the hda powersave without popping fix be in maverick?
<cnd> just want to double check
<vanhoof> if we had to guesstimate, when will 2.6.35 be released to the wild?
<cnd> vanhoof: I think kernel cycles average three months?
<cnd> so I would guess middle of august
<vanhoof> cnd: cool
<vanhoof> thank you
<bjf> pgraner, just an fyi bug 586150 (comment #1)
<ubot2> Launchpad bug 586150 in blueprint "The "Whiteboards" section of blueprints should be given more space (affects: 2) (heat: 12)" [Low,Triaged] https://launchpad.net/bugs/586150
<tgardner> vanhoof, ogasawara estimated sometime in September
<vanhoof> tgardner: thanks
<JFo> can I just say, I love it when i tell someone that they failed to respond on a bug and I expire it only to have them reopen it, fuss about it being closed, then go test the issue and tell me "oops, this is fixed, please close."
<JFo> makes me crazy
 * tgardner wonders if jfo has noticed that half of all humans are below average
<JFo> I have, and most of that half file kernel bugs it seems
<JFo> :)
<JFo> cnd, wtf? re bug 581312
<ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed with Dell Latitude XT2 (affects: 1) (heat: 20)" [Medium,Triaged] https://launchpad.net/bugs/581312
<cnd> JFo: ummm, what?
<JFo> did you see the last comments
<cnd> yeah?
<cnd> JFo: what about them?
<JFo> apparently nothing
<tgardner> lag, git log --pretty=oneline $*
<JFo> amitk, you around?
<JFo> <pitti> JFo, asac: someone added https://wiki.ubuntu.com/UbuntuARMTeam/ReleaseStatus/MaverickTasks?action=raw to maverick.cfg; should't that rather get into ubuntu-arm.cfg?
<JFo> <pitti> it looks weird to distribute the ubuntu-arm WIs like that, but your call of course
<JFo> ^^ from #ubuntu-devel
<amitk> JFo: shoot
<JFo> amit, the above was what I wanted to show you
<smb> lag, To tell git the current top commit you could also use HEAD and HEAD~1 is the one before that and so on
<JFo> from pitti
<amitk> JFo: that'd be Jamie filing new stuff
<ogasawara> apw: bah, forgot about missing modules when I built in fbcon
<JFo> ah
<ogasawara> apw: will get it fixed up
<smb> ogasawara, Heh, yeah. Probably want to do a ignore.modules instead of a modules.ignore...
<tgardner> lag, for example, 'git request-pull HEAD~1 git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git' assuming you have one commit in your local repo that you'd like to be pulled.
<lag> Oh okay
<ogasawara> smb: yah, I did the same for the last upload due to all the config tweaks
<lag> Thanks smb, tgardner
<vanhoof> JFo: skype just told me about tomorrow ;)
<JFo> heh
 * bjf will brb
<kassah> What's the best way to load a proposed kernel (I was requested to load 2.6.32.13 from proposed)
<kassah> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/511066
<ubot2> Launchpad bug 511066 in linux (Ubuntu Lucid) (and 1 other project) "ModemManager: HP ev2210 Sierra MC5725 not detected (affects: 2) (heat: 18)" [Low,In progress]
<tgardner> kassah, 'wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.14-lucid/linux-image-2.6.32-02063214-generic_2.6.32-02063214_amd64.deb; sudo dpkg -i linux-image-2.6.32-02063214-generic_2.6.32-02063214_amd64.deb'
<kassah> thanks =)
<cking> manjo, you still around?
<manjo> cking, yeah
<manjo> cking, I think the problem is on my end 
<manjo> cking, let me restart mumble
<cking> manjo, its at your end
 * bjf is back
<cnd> anyone have any ideas why when I run the following as root, it works, but when run by pm-utils when power is disconnected, it errors out with error 1:
<cnd> setterm -blank 1 -powersave powerdown -powerdown 1 \
<cnd>         < /dev/tty1 > /dev/tty1 2>&1
<cnd> when run as root, I have to sudo su first, so maybe sudo is doing something extra?
<cnd> when pm-utils runs, it's running as root, no sudo
<cnd> it's driving me mad...
<jjohansen> cnd: environment variables?
<cnd> jjohansen: could be, I did a diff of the env output in each case
<cnd> nothing stood out as obvious
<tgardner> cnd, you might ask kees, but its possible sudo is not granting the right CAPs
<cnd> tgardner: it seems like in this case sudo may have more privs than root somehow
<cnd> I'm going to strace it to see if I can find out exactly why it dies
<jjohansen> cnd: that can happen, a root process doesn't necessarily get all caps
<cnd> jjohansen: tgardner: strace FTW
<cnd> write(2, "setterm: $TERM is not defined.\n", 31setterm: $TERM is not defined.
<cnd> though I had tried it without 2>&1 I thought, and I never saw this
<cnd> apw: yesterday you wondered if fdr binary-generic skipdbg=false would force generation of the ddeb without having to mess with touching /CurrentlyBuilding
<cnd> I can confirm that's correct
 * manjo heading out to get some lunch ... brb 1hr 
<jjohansen> ->lunch
<kees> where are local references stored in .git ?  i.e. I have an upstream linux-2.6 tree that I want to have as a --reference for a new clone.  but if I forgot to do that during the clone, I can add it later and do a git gc --prune, but I can't figure out where to add it...
<tgardner> kees, I doubt it, you'll likely have to reclone
<kees> tgardner: nah, smb showed me magic at the last sprint
<tgardner> kees, perhaps its more hassle then its worth
<tgardner> doh!
<kees> well, I have various topic branches now, so I want to manipulate the repo without throwing it away
<tgardner> push you topic branches to different repo (like the linux-2.6 repo)
<tgardner> you can always delete them later
<kees> ah-ha, .git/objects/info/alternates
<kees> okay, next up.... I have a remote, I've added a remote to it, how do I create a local branch for a remote master that isn't "origin"?
<tgardner> git checkout -b BRANCH origin/BRANCH
<tgardner> 'git branch -a' show all of the branches at remote repos
<kees> I said "remote" twice there, meant "branch" first time.
<tgardner> I figured it out from context :)
<kees> sounds like I want  "git checkout -b LOCAL-BRANCH-NAME REMOTE/REMOTE-BRANCH-NAME
<tgardner> kees, exactly
<kees> can I use "git log" to show other local branch logs?  (i.e. how do I find a commit id to cherry-pick without switching to the origin branch first?)
<ogasawara> kees: you can do a `git log <branch name>`
 * ogasawara -> lunch
<kees> ah! I was trying too hard
<achiang> kees: in git, just about every command works on a git identifier, whether it's a human readable name, or a sha1
<kees> achiang: seems like format-patch is an exception
<achiang> kees: eh?
 * ogasawara goes to lunch for reals this time
<tgardner> kees, I think format-patch works on a single SHA1, or a range of IDs
<kees> achiang: if I'm in a branch, and I want to use "format-patch" I can't specify an arbitrary sha1
<kees> tgardner: yeah, my mental problems with git seem to revolve around the "scope" of branches
<kees> I'm used to having a full working directory per branch (as with bzr)
<tgardner> kees, the syntax can be a bit dense
<achiang> kees: interesting. i haven't used format-patch in a long time, not since i switched to stacked git
<maks_> bzr is so bizarre
<maks_> poor you kees 
<maks_> format-patch <sha1sum>^..<sha1sum> kees 
<kees> maks_: ah-ha.
<kees> what does "^" mean in that syntax?
<maks_> the one previous
<maks_> you can also use ~1
<cnd> mpoirier: these two files (<flavour>.ignore and <flavour>.ignore.modules) tell the build process to ignore checking
<kees> neat, that worked.
<kees> so, it seems "scope" for git commands is really "all commits ever in any known branch".  only when one uses less specific arguments does it kick down using the current branch's view of commits.
<cnd> mpoirier: however, if you are just trying to build a kernel through fdr binary-omap, then you can add skipabi=true skipmodules=true to the command
<mpoirier> something like:
<lifeless> kees: I think its more 'reachable from reflog heads'
<lifeless> kees: vs any commit
<cnd> mpoirier: I just realized I forgot to link to the files: http://kernel.ubuntu.com/git?p=cndougla/hedley.git;a=tree;f=debian.mvl-dove/abi/2.6.32-204.16hedley6/armel;h=736bf1ef045abfab6e0930d8031ebdfc5453bfee;hb=HEAD
<mpoirier> fakeroot debian/rules binary-omap skipabi=true skipmodules=true ?
<tgardner> mpoirier, 'echo 1 > debian.master/abi/2.6.34-4.11/armel/ignore'
<cnd> mpoirier: correct
<kees> lifeless: ah, true, sounds right.  though I've never tried orphaning a commit and later tried to reach it
<achiang> kees: note that format-patch is weird, in that you give it the sha1 of the commit *before* the one you really want
<achiang> so that explains why you might be running into "scope" issues
<kees> achiang: right, that bit I'm kind of used to now.  but this week I've tried to switch to using multiple topic branches so my existing workflows are slightly confused.  :)
<achiang> if you're in master, and are trying to do a format-patch for a branch that has commits *after* master, then it looks like you can't simply specify a <since>
<achiang> again, stg ftw. ;)
<jjohansen> achiang: curious, have you ever used guilt, and if so how do you find it compares to stg
<achiang> jjohansen: i tried using guilt a long while ago and didn't quite like it as much as stg
<achiang> let me try and remember why...
<jjohansen> fair enough, I defaulted to it as its syntax was closer to quilt
<achiang> jjohansen: i think my complaint with guilt was that it followed the git model *too* closely, in that it was a PITA to be working on a patch series and attempt to modify an earlier patch
<achiang> but that was about 1.5 years ago, so maybe it's improved a lot since
<jjohansen> achiang: hrmm, no its just like quilt except better.  Just pop to the patch edit and refresh.  Better than quilt because any file under git control is automatically added, so no more quilt add/edit
<achiang> jjohansen: yeah, ok. then i can't remember why i liked stg better (it has the same model btw)
<jjohansen> I think there are a few things that stg probably handles better but, as I said I took a quick look at both an guilt was closer to quilt (which I used all the time)
<jjohansen> right, its bascially the same
<achiang> maybe it was the mailer? is guilt's send-email wrapper nice/easy to use?
<achiang> stg has a nice mail templating feature that i used heavily
<jjohansen> ah, that may be it, I have never gotten the mailer to work
<jjohansen> and have to fallback to git send-email
<jjohansen> of course I haven't tried it for a year
<achiang> heh.
<jjohansen> hrmm, looking at the current guilt there isn't even a mailer documented, though I am sure I tried playing with it in the past
<jjohansen> perhaps it was one of the features that never got completed
<tormod> is bug 585551 a udev or kernel bug, anyone?
<ubot2> Launchpad bug 585551 in udev (Ubuntu) "mainline kernel makes udevd spin on device removal (inotify event) (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/585551
<mrec> oh dear, since the last Ubuntu update my system randomly reboots
<mrec> intel's crap graphicdriver is still not fixed and I'm getting glitches all over the screen randomly
<tormod> mrec, update of what exactly?
<mrec> systemupdate there was not too much to update, is there any logfile available about system updates?
<tormod> dpkg.log
<mrec> libc was updated but not sure if that's the issue
<tormod> mrec, you have lucid + proposed?
<mrec> only lucid
<mrec> libc was the most critical update probably I have the list here if it happens again I will report it
<phunge0> achiang: hi, i've been having a WARNING in my linux-next kernel build
<phunge0> "sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:02.0/slot'"
<phunge0> googling showed a thread from a month ago http://lkml.org/lkml/2010/4/12/259
<phunge0> but it doesn't look like anything was done about it
<achiang> phunge0: yeah, i never really had a chance to debug that. :(
<achiang> phunge0: i'm going to ask jesse to drop that patch, i don't have hardware or time to fix it
<phunge0> i can help if you're interested, or maybe just revert the patch like you originally requested?
<achiang> hm
<achiang> phunge0: can you pastebin lspci -vt for me please?
<phunge0> achiang: http://pastebin.com/yECfYNZJ ... i'm on KVM, like the original submission
<achiang> oh!
<achiang> phunge0: you know, i didn't even see that eparis was using kvm the first time around
<phunge0> interesting
<achiang> the fact that kvm is involved actually makes a lot more sense. i was *really* scratching my head initially about how on earth we could have gotten duplicate slot entries
<achiang> phunge0: hm, weird. git grep sysfs_attribute_initialize returns nothing in my tree
<phunge0> achiang: yeah, cool... my kvm setup is completely vanilla if you want to try to reproduce
 * achiang does a git remote update ; git rebase origin
<phunge0> i know only a little about sysfs... sysfs_attr_init?
<achiang> oh perhaps that's it
<achiang> hm
<phunge0> # CONFIG_DEBUG_LOCK_ALLOC is not set
<phunge0> it's a noop in my build, so i doubt that'd be it
<achiang> i'm not sure that gregkh's email was correct. looking at the comment for sysfs_attr_init, it's talking about lockdep, which is completely unrelated to the warnings you're seeing
<phunge0> yeah
<achiang> phunge0: so you see that warning in the guest or the host?
<phunge0> guest
<tormod> why aren't the mainline daily builds, er, daily? :)
<JFo> because they build based on when there is an RC
<tormod> anyway I hope yesterday's drm-next has what I need from today's missing daily
<tormod> JFo, I think they are built more often than that?
<achiang> phunge0: can you please pastebin: for i in /sys/devices/pci0000:00/* ; do ls -l $i ; done
<achiang> in the guest
<phunge0> achiang: http://pastebin.com/rb26vUMW
<phunge0> and bus/pci/slots: http://pastebin.com/Se1TGyv7
<achiang> phunge0: sorry, one more pastebin please -- can you paste the entire dmesg from your guest so i can see the warnings?
<phunge0> http://pastebin.com/Vc1h75Eu
<achiang> phunge0: how do you feel about building kernels and testing patches?
<achiang> phunge0: if it's too hard, don't worry about it, but if you're able, i'd like you to apply a debug patch for me
<phunge0> achiang: i'm leaving work in around 20 minutes, gone until next tuesday :(
<achiang> phunge0: how about if i send you an email and you can just report results when you get a chance?
<phunge0> yeah absolutely
<achiang> phunge0: address? you can /msg me if you want
#ubuntu-kernel 2010-05-28
<pgraner> ogasawara: how tyler working out for ya?
<ogasawara> pgraner: good so far, I've started some builds on it already
<pgraner> ogasawara: yea I noticed all 12 cpus are pegged
<ogasawara> :)
 * maco wonders how much of this channel will show up in #ubuntu-meeting in a half hour to support your comrades
 * maco points at pgraner and manjo
<lifeless> komrades
<ogasawara> Ooo, is the ubuntu membership meeting happening?
<maco> yes
<maco> in 35 minutes
 * ogasawara will try to be there then
 * bjf done for today
<crimsun> cnd: the intent is, but I'm afraid we need to work on it more. The current wait is too short.
<crimsun> cnd: namely there are reports of it being worse with the newer driver snapshots, so it doesn't affect LTS currently.
<manjo> pgraner, membership meeting starts in 5mts ? 
<maco> manjo: oh so you ARE alive!
<maco> manjo: 4 minutes now :)
<manjo> ok
<manjo> :)
<pgraner> maco: yep
<maco> pgraner: if you werent online, i was going to call your house
<pgraner> maco: why?
<manjo> pgraner, you on ubuntu-meeting ? 
<pgraner> manjo: yep
<maco> pgraner: so you wouldnt miss the meeting?
<ogasawara> pgraner: tyler cranks out builds quick!
<pgraner> ogasawara: sweet... its dead quiet
<pgraner> ogasawara: once we get emerald redone I might send this one on to you
<ogasawara> pgraner: nice :)
<pgraner> ogasawara: you need it more than I do
<bjf> pgraner, is it like the one you are going to send me or is that yet another?
<manjo> ogasawara, pgraner I made it 
<ogasawara> manjo: yep, congrats!
<pgraner> manjo: congrats
<manjo> thanks yall
<akgraner> partah time for manjo!  \o/ \o/ woo hoo!!!
<manjo> akgraner, thanks for the wiki clean up ... owe you a drink of choice 
<manjo> akgraner, and the nice reco
<akgraner> :-)  you are most welcome! 
<jjohansen> back on later
<maco> pgraner: your wiki page makes me think ive only met half the kernel team. or at least only been introduced to half of them by name
<pgraner> maco: there are 27 now
<maco> WOW
<pgraner> ogasawara: your a whimp... tgardner had tyler at 35 load ave. today your at 13.75
<ogasawara> pgraner: damn.  I wonder what he was doing.
<pgraner> ogasawara: running stress and builds at the same time
<pgraner> ogasawara: :-)
<ogasawara> pgraner: that's cheating
<pgraner> ogasawara: if you ain't cheatin' you aint trying
<ogasawara> heh
<pgraner> ogasawara: and if you get caught you ain't trying hard enough :-)
<pgraner> ogasawara: awww I'm touched :-)
<ogasawara> pgraner: congrats!  /me goes to eat dinner
<pgraner> ogasawara: thanks :-)
<mrec> I figured out why my pc randomly reboots
<mrec> it's fvdr
<mrec> vdr
<mrec> why vdr does that I don't know
<cnd> crimsun: what do you mean by "it doesn't affect LTS"?
<cnd> Ubuntu 10.04 LTS?
<RAOF> Thanks for that Xorg.0.log; nouveau isn't working, but the fallbacks are successfully kicking in, which they didn't do earlier in the Lucid cycle.
<stenten> Am I correct in thinking that installing the two header files for the mainline PPA kernels will let you install restricted drivers through jockey?
<RAOF> stenten: Sometimes.
<stenten> i'm trying to troubleshoot someone's kernel problems :(. Should the lts-backport-maverick kernel Tim Gardner posted in kernel-ppa for the LTS Backport Kernel idea work?
<RAOF> It depends on whether or not the restricted driver's kernel component will build against the new kernel.  I know that fglrx doesn't, I'm unsure about nvidia.
<stenten> Ah, that makes sense. It's the Broadcom Wireless driver. I'm thinking they just didn't install the header files correctly, so it should be moot.
<stenten> Is there anything special in the ubuntu-specific (default) kernels that would affect restricted drivers, or is all that handled by the header files?
<Sarvatt> stenten: grab bcmwl-kernel-source from maverick
 * apw aches
<smb> apw, Hey morning. Before I forget this (because I did already many times), I got one interesting case of being unusually hot for an old thinkpad. Those things pretend to have a floppy drive even when not attached. And I noted it running quite hot. After blacklisting floppy its now down to a sensible temp on idle.
<amitk> heheh, overheating due to floppy driver hallucinations
<smb> Nearly. :) More to trying to access it over and over agai
<smb> Some part of the basic installation tried to find out what is on the non-existing floppy in the non-existing drive. And seemed not to take a nothing for an answer
<apw> smb, i wonder what the thing was doing
<smb> apw, Not sure it came from userspace (as cd polling used to be) or from the driver to check there is a media present
<smb> First thought its the lack of any frequency scaling (a quite old hw, T21 I think)
<smb> But wanted to get rid of this anyoing "read error on fd0" messages
<smb> and surprise, after blacklisting temp went down from 80 to 50C
<apw> smb, yeah ... 
<apw> smb, i am almost supprised if it was that busy that you could remove it at all
<smb> apw, I could not
<smb> blacklisted and rebooted
<smb> cking, \o
<apw> smb, ahhh interesting, i bet waiting for status or something from the interface chipset
<smb> apw, That would be my guess. But thats probably just something that happens not very often. I don't think any reasonably modern TPs will try to fake a floppy drive
<apw> smb, is it faking it for hot plug ?
<cking> morning, (yawn)
<smb> Yes, afaik. You were able to replace the cd drive with a floppy drive (after some magic to disable the ide bus) and on older models you could attach a floppy later
 * smb places a cup of coffee into cking 's hand
 * abogani2 waves
<apw> abogani2, moin
 * smb waves back
<apw> smb, nasty but must be the trigger ...
<abogani2> cnd, apw: http://kernel.ubuntu.com/git?p=abogani/ubuntu-lowlatency-maverick.git;a=summary lowlatency branch
<abogani2> cnd, apw: http://kernel.ubuntu.com/git?p=abogani/ubuntu-lowlatency-maverick-meat.git;a=summary lowlatency branch
<apw> cking, morning, its tooo hot here again
<abogani2> *meta
<smb> apw, cking You actually see this bright thing in the sky? Its magically bright here but enough clouds and only 15Â°C
<apw> yeah only 13c here so far, but its not going to stay cool for long i can feel it
<apw> smb, and where is your 'degrees' button on your keyboard
<smb> Above the ^ key :-P
<smb> which is left of 1
<apw> not something i would have expected you to have an actual key for, no such key for me
<apw> smb, so is that also the key which adds a flying circle over the top of vowels ?
<smb> Its not considered that useful to do it
<smb> I bet there is some magic to make it behave like ~
<smb> But now thats instant
<smb> apw, Probably amitk 's keyboard does that
<amitk> no flying circles on the finnish keyboard
<amitk> though there is a key for 'A' with the flying circle (used in norwegian, i think)
 * smb wonders whether abogani2 currently plays with his PPA
<abogani2> smb: No
<cking> man it's sunny today - and it's near a UK holiday
<smb> abogani2, Hrm, I just tried to get the sources for the linux-rt packages from it and the orig.tar.gz appears lost to me
<smb> cking, Its a trap. As soon as you go out there will be water
<cking> smb, I need the rain to water my garden, so it's no big loss ;-)
<smb> cking, Well no, but you don't want it on *you*, do you?
 * smb had his share of cold water from above yesterday
<abogani2> smb: Mhhhh
<abogani2> smb: I surely have did a mistake: apologize for this. It is my fault haven't did enough tests. So I have investigated and _seems_ that orig.tar.gz is the same of the previous version (if I don't recall wrong I almost sure to have used "debuild -S -sd"). In any case I'll upload again to an other PPA to be sure. Sorry again. :-(
<smb> abogani2, Ah, ok. In theory the orig.tar.gz would be a clean 2.6.31 linux tree, so I should also be able to use that. But I wanted to be sure. Just let me know when it has been uploaded. No need to wait for the build for me. :)
<abogani2> smb: Ok thanks. I'm _really_ sorry.
 * abogani2 doesn't like waste time of UKT members...
<smb> abogani2, Bah, compared to the time you had to wait on me thats nothing.
<abogani2> smb: I have found the files which I used to first upload. I have just re-uploaded and again orig.tar.gz is unavailable :-(
<smb> abogani2, Ok, cool. Some PPA as before, right?
<smb> err
<smb> I should open my eyes this morning
<abogani2> smb: No because same PPA don't accept to build the same version two times.
<abogani2> smb: Is it debdiff enough for you?
<smb> abogani2, I would want to try to extract in and look at things. Hm, have you an account on zinc?
<abogani2> smb: Sure.
<smb> abogani2, Then just dump the files there. :)
<abogani2> smb: Also orig.tar.gz ?
<smb> abogani2, Is that just a linux-2.6.31.tar.gz? (Like from kernel.org)? In that case probably just add a text file with the md5sum of it and I make one here.
<smb> I just want to be sure to take the same orig.tar.gz when playing with it
<abogani2> smb: It could be Karmic orig.tar.gz. In any case Zinc seems go fast now so I'm uploading it too,
<smb> abogani2, right, which is in turn just the plain Linus tree. But perfect. Seems you got a good uplink. :)
<abogani2> smb: I have just uploaded the classic triple (diff, dsc, orig), debdiff (only for safety) and the two files for meta. At the moment the only issue that I know is the section which is settled to "lucid" (I suspect "lucid-updates" should be used instead).
<apw> lucid-proposed probabally
<smb> abogani2, Make that 'lucid-proposed" 
<smb> yeah
<smb> after release (at least the packages we do) is uploaded to proposed and then later archive copied to updates
<smb> abogani2, I will have a look next and reply anything I think to your original email
<abogani2> smb: Ok. Thanks!
<michiel_e> hello
<michiel_e> is there a difference in module loading/features used between normal and recovery mode?
<michiel_e> because I have a server in here who is shutting down itself after 1 minute or so
<michiel_e> but in recovery mode it doesn't do that
<michiel_e> even when I manually go in recovery mode and then start runlevel 2
<michiel_e> so even when the same applications are running, it doesn't shutdown in recovery mode but does in normal mode
<michiel_e> so I try to pinpoint the problem
<michiel_e> could it be that a kernel module reacts on cpu fans not running (at least 0RPM in sensor data) but in recovery mode ignores that?
<kro> have a look at /boot/grub/grub.conf to see which kernel options differ in your case
<michiel_e> quiet splash in normal, and single without quiet splash in recovery mode
<michiel_e> even when I disable splash and quiet on boot it shutsdown
<kro> and no reason for the shutdown in the logs? is it really a shutdown or rather a crash?
<michiel_e> it could be a crash
<michiel_e> but I think a shutdown
<michiel_e> because I see, when running top, flush and mdadm stopping it's devices
<michiel_e> but I cannot find a shutdown reason in the logs
<michiel_e> the only error I can find, but I really thing that is not the problem, is: svc: failed to register lockdv1 RPC service (errno 97)
<michiel_e> using the nfs kernel server
<michiel_e> can I use some kind of verbose logging?
<michiel_e> more verbose then removing quiet
<kro> try replacing "quiet" with "debug"
<kro> and maybe stuff your logs into some pastebin and paste the link here :-)
<kro> that is, syslog and maybe dmesg
<michiel_e> ok
<michiel_e> udev-worker add_inotify failed couldn't be the cause now could it?
<michiel_e>  /var/log/messages, right?
<joaopinto> michiel_e, that was a bug during development on which a shutdown was performed because the fsck from mountall was running on the background, and the script was invoking the *after file system check* reboot when the system was running, that bug is expected to be fixed now, I am just wondering
<michiel_e> joaopinto, lucid-updates is set as repo as well as multiverse and universe
<michiel_e> and fully upgraded via dist-upgrade
<michiel_e> joaopinto, you know how I can confirm that is that bug?
<joaopinto> mv /etc/init/mountall-reboot.conf /etc/init/mountall-reboot.conf.disable
<michiel_e> or have a launchpad link?
<joaopinto> that would make sure the mountall rebook will not be invoked
<joaopinto> but this really a wild guess assuming it's a reboot and not a crash
<joaopinto> is
<michiel_e> yeah well, it looks like a crash, but looking at the processes it just flushes to the disk
<michiel_e> so I actually don't know
<michiel_e> the system doesn't give a shutdown message
<michiel_e> but it seems like the kernel knows it's shutting down
<apw> michiel_e, most fan control is bios level
<michiel_e> the mountall-reboot.conf doesn't get invoked
<michiel_e> so it's not that bug I guess
<michiel_e> apw, but Ubuntu is using the sensor limits, right?
<apw> michiel_e, and one minute seems a bit quick to overheat anyhow
<michiel_e> apw, yeah but it's not even overheating
<apw> michiel_e, you can find out what they are, but most actual control is done in the bios
<apw> i suspect its more likely something else, a panic or something
<apw> if you can see the console, then i would boot without quiet and without splash
<apw> and see if you see anything on the console to aid debug
<michiel_e> the sensor data: http://pastebin.com/3akr24m4
<michiel_e> I'm worried if the system reacts on the fan RPM's being 0
<michiel_e> this is the system information: http://pastebin.com/NUTt6T6W
<apw> michiel_e, i don't know of any support there that is not builtin, and therefore would behave the same
<apw> in recovery and normal modes
<michiel_e> I am going to test with recovery mode, going through normal boot process
<michiel_e> in debug mode
<apw> michiel_e, sounds like a sound plan
<kro> michiel_e: 2.6.34-020634-generic is that your own kernel? maybe try to compare if the same thing happens with the lucid kernel?
<apw> kro, thats a mainline 2.6.34 kernel from the archive (i suspect)
<abogani2> Cool! The ondemand governor freezes an old P4!
<apw> but yes, it would be good to know if the same issue appears with the stock lucid kernels as well
<apw> abogani2, is that in the stock kernel or -rt ?
<abogani2> apw: Stock kernel.
<abogani2> apw, Karmic and Lucid.
<apw> abogani2, lovely
<apw> abogani2, so does it freeze when we switch after login ?
<abogani2> apw: No. Randomly.
<apw> abogani2, not helpful, does it panic or just lock up hard
<abogani2> apw: Very hard lock up. No Sysreq keys works, Only removing the battery.
<apw> abogani2, woh, well i can only really say i've not heard of that before
 * abogani2 too
<apw> it is likely that freq control is different on P4 so i could imagine it being only broken there and few people even have them to notice now
 * abogani2 agrees
<apw> abogani2, i assume if you leave it in performance everything is fine?  other that it being a bad idea
<abogani2> apw: After a week it still runs.
<abogani2> No freeze at all.
<abogani2> No useful log neither through network nor through serial.
<abogani2> So a sort of magic :-)
<abogani2> apw: It is P4 _*_Mobile_ *_
<amitk> cooloney: thanks for the sbuild write
<amitk> up
<michiel_e> apw, same issue appears with stock kernel as well
<michiel_e> apw, which do you like I debug, 2.3.34-* (which is indeed from ppa archive) or the stock?
<cooloney> amitk: no problem, man. I think it is a good benchmark for our hardware machine.
<cooloney> amitk and apw, it still took me 3 hrs to build the whole package.
<cooloney> my server is not so powerful
<amitk> cooloney: 3 hrs is still better than 7 hr on buildd and then fail :)
<cooloney> amitk: aha, yeah, much better. 
<apw> michiel_e, likely matters not if the issue is in both
<apw> abogani2, hrm
<apw> cooloney, yeah and we'll get that put up on emerald once its rebuilt
<apw> amitk, bah he has gone
<abogani2> apw. I'm about to disable ACPI_CPUFREQ and enable P4 CLOCKMODE instead.
<apw> was going to say, and if its a local build you can 'continue it' by
<apw> removing the build stamps
<michiel_e> there is in the boot process something running /sbin/poweroff
<michiel_e> that's why it crashes
<michiel_e> saw it with ps aux
<michiel_e> although no parent process so hard to trace currently
<michiel_e> maybe still the mountall bug
<smb> Hm, somehow calling poweroff sounds like some sort of thermal emergency action. Unfortunately I am missing the details but I thought machine check events might be involved. On the other hand I don't see why things should be different in recovery mode (if there are no special options for the kernel in /boot/grub/grub.cfg). And in mine there only seems to be single instead of quiet splash...
<soren> ls -l
<soren> Yeah, that'll work :(
<smb> soren, It better does not. :)
<crocket> HI
<jessicaNatalie> hello guys. i am trying to recompile the ubuntu kernel because i need to add support to toshiba laptops. I cant find this option when make menucofig. some help please
<crocket> I want to file a bug report about recognition of my laptop keyboard by linux kernel.
<crocket> All versions of linux kernel don't recognize my LG E300 built-in laptop keyboard.
<crocket> It is a known problem.
<crocket> But there is no relevant bug report as far as I know.
<crocket> Where should I file a bug report about this?
<michiel_e> /sbin/poweroff -fp
<michiel_e> where the heck does that come from?
<michiel_e> it has no parent process
<Conficker-> bagaimana cara mendapatkan shell ya ?
<Conficker-> yes how do I get a shell ?
<crocket> michiel_e, "dpkg -S /sbin/poweroff" says it is included in upstart package.
<crocket> Conficker- : Is that english?
<michiel_e> this is my process list http://pastebin.com/neRdDPyi
<michiel_e> ah ok
<JFo> jessicaNatalie, what sort of support?
<crocket> michiel_e, problem solved?
<crocket> Somebody tell me about my problem
<michiel_e> crocket, not yet, I need to find out why it's running poweroff
<crocket> michiel_e, What's running it?
<Conficker-> I could not ask for his shell ?
<michiel_e> crocket, I think upstart, but not shure
<jessicaNatalie> JFo i mean, i am runnig toshset  and i am receiving this message "required kernel toshiba support not enabled."
<michiel_e> crocket, no parent process
<JFo> interesting, where do you see that jessicaNatalie?
<crocket> michiel_e, Does it appear no matter how many times you reboot?
<JFo> crocket, I'm not sure what you mean by where should you file it/
<jessicaNatalie> JFo: in console, when executing toshset
<crocket> I think of filing a bug in bugzilla.kernel.org
<crocket> I don't know which section of bugzilla.kernel.org I should file a bug in.
<jessicaNatalie> JFo the truth is that i am doing this because i am having a very weird behavior in this laptop: when i boot ubuntu, the cooler is always off, unless I put the laptop to sleep and awake it again...
<JFo> so the fans aren't working?
<JFo> hmmm
<Conficker-> why ?
<JFo> jessicaNatalie, do you have a bug I can take a look at?
<Conficker-> woy tahede
<jessicaNatalie> JFo a bug? you can look at all you want, but no idea what you mean... some log file or something?
<michiel_e> crocket, it appears al the time, but not in recovery mode
<michiel_e> crocket, I think upstart is just running /etc/rc0.d/halt or something
<michiel_e> crocket, but not sure though
<JFo> nou, I mean have you filed one that I can look at and provide the team to work on?
<JFo> jessicaNatalie, ^
<crocket> michiel_e, it doesn't have to be upstart that's running poweroff -fp
<michiel_e> crocket, indeed it doesn't
<michiel_e> crocket, maybe fgrep would give me some info
<jessicaNatalie> JFo mmm no i havent... sorry for my ignorance
<JFo> no problem :)
<JFo> I just need one before we can start looking at the problem in-depth
<JFo> jessicaNatalie, mind filing one?
<jessicaNatalie> JFo I understand. So i will do it
<jessicaNatalie> thanks a lot!
<JFo> jessicaNatalie, my pleasure :)
<JFo> Conficker, I'm not sure I understand what your questions are?
<JFo> do you have a bug i can look at?>
<JFo> crocket, I know you probably have already, but did you search against the kernel bugzilla for your laptop model to see if someone has already filed something?
<crocket> JFo : I just checked and nobody reported such a bug.
<JFo> ok
<crocket> What section of bugzilla.kernel.org should I file a bug report in?
<JFo> not sure what you mean by section
<crocket> There is no section assigned to keyboards.
<JFo> ah, right
<crocket> I mean
<crocket> a category
<crocket> There is no category assigned to keyboards.
<JFo> I think those are some sort of internal USB keyboard oddity from my conversation with smb
<JFo> are you able to run lsinput crocket?
<jessicaNatalie> JFo one last question: do you know where is this toshiba support option when recompiling the kernel???? I am sure I have seen it, but cant find it now... :)
<crocket> JFo : Is it a command?
<JFo> jessicaNatalie, I don't, unfortunately
<JFo> crocket, yes
<crocket> JFo : are you a kernel developer?
<JFo> crocket, do you have an LP bug open?
<JFo> crocket, I'm the bug triager
<crocket> What's an LP bug?
<jessicaNatalie> JFo mmm all right... I continue looking for it. thanks a lot!
<JFo> launchpad bug
<JFo> jessicaNatalie, my pleasure
<crocket> JFo : I filed that bug somewhere in launchpad years ago, but nobody cared.
<JFo> ah
<crocket> Maybe it was a wrong place to file a report.
<JFo> no it is, there are just so many that get opened
<crocket> I think bugzilla.kernel.org is the right place
<JFo> crocket, is the keyboard detected at all?
<crocket> or better
<JFo> is it misbehaving?
<crocket> Let me pastebin for you
<JFo> ok
<crocket> I already have a USB keyboard plugged in.
<JFo> I see
<crocket> An external USB keyboard works.
<JFo> but the internal doesn't at all?
<crocket> JFo, http://pastebin.org/288193 <-- the result of lsinput
<crocket> I don't know how to interpret the result.
<crocket> There are some USB devices that don't have human-readable names.
<crocket> "AT Translated Set 2 keyboard" may be the external USB keyboard.
 * JFo looks
<smb> No that seems to be the internal one
<crocket> smb : do you think "AT Translated Set 2 keyboard" is the internal keyboard?
<smb> Its connected to the i8042 controller, which is usually the internal one
<crocket> Damn
<smb> It might be that hid device
<smb> #
<smb> /dev/input/event6
<smb> #
<smb>    bustype : BUS_USB
<smb> #
<smb>    vendor  : 0x566
<crocket> If I add "i8042.nopnp i8042.dumbkbd" in kernel boot parameters of GRUB, the keyboard works, but Num Lock and Caps Lock toggle LEDs don't blink at all, so I can't check the status of Caps Lock and Num Lock.
<smb> #
<smb>    product : 0x3002
<smb> #
<smb>    version : 272
<smb> #
<crocket> smb : don't flood man
<smb>    name    : "HID 0566:3002"
<smb> #
<smb>    phys    : "usb-0000:00:13.0-2/input0"
<smb> #
<smb>    uniq    : ""
<smb> #
<smb>    bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP
<smb> gah
<JFo> hmmm
<smb> my bad
<JFo> wonder why it doublespaced
<crocket> JFo : How come does it get recognized and not work at all?
<JFo> crocket, good question
<smb> well, that points to that that
<JFo> I'm not sure
<crocket> ha
<JFo> the HID device smb?
<smb> The driver might try to communicate with it and fail at some point
<smb> I believe that is the usb keyboard
<crocket> i8042.nopnp & i8042.dumbkbd kernel options make it work
<smb> lsusb could verify that
<smb> mus be some device at 00:13.0-2
<JFo> crocket, mind running lsusb for us?
<JFo> more for smb than for me :)
<crocket> This is the result of sudo lsusb ---> http://pastebin.org/288208
<crocket> Why do I have to specify i8042.nopnp and i8042.dumbkbd?
<crocket> I didn't have those options myself. Others found them for me.
<smb> I need to check with those options
<smb> But my guess is
<smb> that the keyboard has some special ps2 protocol extensions variations
<crocket> smb : In windows vista, it's recognized as a PS2 keyboard.
<smb> and by telling it to use sumkbd the used commands on the protocol are more generic and simpler
<crocket> What driver should I install?
<crocket> or put in kernel?
<smb> the driver is in the kernel. i8042, its just that this keybard might need special treatment by it
<smb> dumbkbd: Do not try to control the state leds
<smb> crocket, Have you once tried with only nopnp?
<Kano> hi, could somebody add rt3090.bin
<smb> I mean i8042.nopnp
<crocket> smb : I tried, but don't remember the result now.
<Kano> rt3071.bin is missing too
<Kano> http://packages.debian.org/sid/firmware-ralink
<Kano> there it is already packaged
<crocket> I hate LG laptops.
<smb> From the docs the nopnp does not do any plug and play to detect the keyboard, I assume it brute force looks at the common io ports
<crocket> I called LG today, and the engineer there said no LG laptops have 64bit OS.
<smb> The other option will prohibit any commands that control the leds
<mjg59> The kernel will do that anyway if there's no pnp devices described
<smb> So no blinking, and so on
<crocket> no blinking, dumb keyboard
<mjg59> But Windows depends upon there being something in the PNP tables, so if the keyboard appears in Windows, requiring nopnp is a Linux bug
<pgraner> ***Notice*** All kernel team members, emerald is about be shutdown for upgrades at the top of the hour. Let me know if you need anything off of it. Thanks
<crocket> Is it a common practice to build a PS2 keyboard in laptops?
<mjg59> Yes
<crocket> pgraner : your english is confusing.
<smb> I have not yet seen anything else
<mjg59> The only people who don't are Apple
<smb> mjg59, you?
<smb> Ah ok, apple
<pgraner> crocket: how so?
<crocket> Why do other laptops' PS2 keyboards work fine?
<crocket> pgraner : "about to be shut down" may be correct, but I don't know what you tried to say.
<crocket> pgraner, Plus, emerald is a windows manager of compiz fusion.
<smb> crocket, To talk to it the ps2 protocol is used. You can make hardware that strictly uses the standard or not...
<pgraner> crocket: sorry if it confused you it was meant for the kernel team members, and emerald is our build server
<crocket> smb : what do you mean?
<smb> mjg59, Do you know of your head what category bz uses for the input layer
<crocket> pgraner, you just send commands to the server and the server build it?
<crocket> What's bz?
<pgraner> crocket: this is an internal canonical server
<smb> crocket, You tell pgraner his english is strange. The same can happen on a protocol
<smb> crocket, buzilla
<crocket> ha
<smb> bugzilla
<crocket> What category in bugzilla should I file a bug report in?
<crocket> I want the right people to see this
<crocket> This is as nasty as a real bug.
<apw> crocket, if those options you mentioned make it work, then a linux bug is appropriate
<apw> and make sure the report has that information in it
<crocket> Not just LG E300 but also Dell Vostro 1510, and other external PS/2 keyboards and mice don't work either.
<smb> crocket, I would boot with the usb keyboard attached, without nopnp and dumbkbd but with i8042.debug=1
<crocket> smb : And where's the debug information?
<crocket> how can I extract it into a text file?
<mjg59> smb: Not off-hand, sorry
<smb> then use dmesg  >dmesg.log and atach that file
<crocket> dmesg would print logs that date back to days or even weeks.
<crocket> I need to narrow it down to the last boot.
<smb> crocket, no dmesg is in memory
<crocket> ok
<smb> so only things since boot
<crocket> I just saw dmesg log file and it was way too large
<crocket> I thought it was cumulative
<smb> its a ring buffer in memory
<crocket> smb : Does it change even after I log in gdm?
<smb> crocket, yes
<crocket> smb : tell me the category where I should file a bug report.
<smb> Its the kernel log, it always changes as long as your machine is running
<crocket> I also posted a bug report in bugzilla
<crocket> https://bugzilla.kernel.org/show_bug.cgi?id=16065
<ubot2> bugzilla.kernel.org bug 16065 in Video(Other) "linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor." [Normal,New]
<crocket> what?
<crocket> Are you the smart bot?
<crocket> smb : Do you have no clue as to what category?
<JFo> we are looking now
<crocket> The severity must be "blocking"
<crocket> Since it paralyzes the computer completely.
<smb> crocket, I thing cat is drivers but not blocking
<smb> blocking would mean your project is blocked
<crocket> smb : You should look at the severity dropdown box.
<crocket> bugzilla.kernel.org -> New -> Severity
<smb> I see it, still blocking is the highest severity
<smb> crocket, you are not on fire, are you?
<crocket> If I was out without usb keyboard, I would be.
<crocket> ok
<crocket> Then I set it high
<crocket> Nobody seems to be looking
<smb> crocket, I would leave it at normal
<crocket> Why? It's a source of frustration for lots of people.
<crocket> Some would even think linux just doesn't work at all on their computers and abandon it.
<crocket> I was about to abandon linux when it happened.
<crocket> Normal problems should be something like https://bugzilla.kernel.org/show_bug.cgi?id=16065.
<ubot2> bugzilla.kernel.org bug 16065 in Video(Other) "linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor." [Normal,New]
<crocket> Linux keeps ranting, but I don't have to deal with it since it doesn't penetrate X window session and keeps ranting.
<crocket> dmesg is severely ridden with no EDID error messages.
<apw> crocket, there are many many bugs, 'my' bug isn't always the most severe that upstream has to look at.  i had my machine overheating for 3 months till i had time to fix it
<crocket> apw, what now?
<amitk> lag: great improvement idea to editconfigs. :)
<apw> lag, i think the layout of the change is a little odd and we can improve it, but the idea seems ok
<lag> amitk, apw: It doesn't work yet, but I'm working on it
<lag> I thought it did, but I came across problems
<apw> lag, i think you call out of the outer for arch in arch loop for editconfigs and run a for arch in arch loop in the function and exit
<apw> that seems odd.  i think you should just check before the outer loop
<apw> and go off into your function
<amitk> isn't it scary I actually understood this: "call out of the outer for arch in arch loop for editconfigs and run a for arch in arch loop in the function "
<crocket> smb, I have two candidate categories. One is IO/storage -> other and the other is Other -> other.
<lag> I exit too early
<smb> crocket, rather other
<lag> And don't do any of the code after the final arch loop
<crocket> other -> other?
<smb> crocket, input devices might be another candicdate, but sthey seem to only think of mice there
<crocket> all right.
<crocket> Then it's other -> other.
<crocket> I shoud reboot with i8042.debug=1 now.
<lag> apw: With regards to your arch stuff, that should be fine. It will just over-write the variable. This isn't a problem, as it's not used again.
<apw> yeah but its rather ugly flow wise
<apw> anyhow when you've reworked it and got it working i'll have anohter look
<lag> apw: No probs
<apw> in my mind i see you adding a preloop which asks which to do and which to skip
<apw> and use that result in the inner loop to skip running menuconfig for the ones we don't want
<apw> and leave the remainder of the processing in place and untouched
<apw> and to a large degree the split processing relies on all the configs being generated, even if in some cases you do not touch them
<apw> lag^^
<lag> apw: ack
<smb> tgardner, Have you already worked through your mail to my mail about compat-wireless-2.6.34 in lucid?
<tgardner> smb, I'm just looking at it now. it looks like I kinda screwed the pooch.
<smb> tgardner, It smelled like that. But good to know youre on it
 * cking wrestles with his PPA
<apw> cking, always fun
<crocket> hi
<apw> anyone know what in userspace might be touching the CPUFREQ, someone with kubuntu is reporting this error being tripped:
<apw> CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold
<crocket> I just posted a new kernel bug report --- > https://bugzilla.kernel.org/show_bug.cgi?id=16069
<crocket> https://bugzilla.kernel.org/show_bug.cgi?id=16069
<ubot2> bugzilla.kernel.org bug 16069 in Other "All versions of linux don't recognize LG E300 laptop built-in PS/2 keyboard." [High,New]
<apw> crocket, add the link to the launchpad bug, then it will get tracked
<crocket> apw, Actually I didn't file a bug report in launchpad, but somebody else did.
<crocket> I posted the report in ubuntu forum.
<apw> JFo, i have a bug which is not a linux bug but i have no idea yet where the bug belongs
<apw> JFo, do we have (or should we have) a tag like kernel-not-kernel which is for bugs we should be trying to get rid of ?
<JFo> we don't but we should apw
<JFo> got the bug number
<JFo> ?
<apw> JFo, kernel-not-kernel smacks of captain-my-captain and therefore appleas
<JFo> heh
<JFo> works for me
<apw> bug #585747
<ubot2> Launchpad bug 585747 in linux (Ubuntu) "CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/585747
<apw> its possible a patched kernel could tell us which process triggered the issue
<apw> but till then we have little to go on, unless someone just knows
<JFo> hmmm
<apw> JFo, i am liking the kernel-<subsystem> kernel-need-review process, lets me nibble at it
<JFo> yep, I think it will work well
<JFo> you always have the same place to go for things and the list is dynamic
<JFo> so there is minimal work to maintain it
<apw> even though i am reviewing two categories, its just two quick clicks from the Tagging page
<lag> apw: Do you know who wrote this script in the first place?
<JFo> smb, do you know if we are pulling the ATI 10.5 drivers into Lucid as SRU?
<JFo> I have a bug that it seems to fix several people in
<JFo> bug 574848
<ubot2> Launchpad bug 574848 in linux (Ubuntu) "Suspend-Resume Regression in 10.04 on Dell Studio 1555 with Radeon HD 4500 (affects: 25) (dups: 1) (heat: 154)" [Undecided,Confirmed] https://launchpad.net/bugs/574848
<amitk> mpoirier: regarding your email...
<smb> JFo, Pulling in complete driver replacements sounds rather unlikely for SRU ... But I don't know for real
<amitk> mpoirier: versatile is a different kernel flavour, nothing to do with omap
<mpoirier> amitk: hello
<mpoirier> amitk: ok will stay way - what is it for ?
<manjo> JFo, HBD!
<JFo> thanks manjo :)
<amitk> mpoirier: as kernel for an arm qemu environment (used for test building, rootstrapping, etc.)
<mpoirier> amitk: ok, will definitely stay away.
<amitk> mpoirier: well, it is useful at time
<mpoirier> amitk: how about udeb files ?
<amitk> s
<JFo> apw, the PPC port is no longer supported? or am i wrong?
<amitk> mpoirier: use Bryan's newly posted instructions to the wiki regarding sbuild to build the udebs
<JFo> I wonder if we need to change arsenal scripts to detect PPC bugs
<amitk> (you can subscribe to wiki pages)
<mpoirier> amitk: what is the link to Bryan's wiki ?
<amitk> mpoirier: http://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter?action=diff&rev1=49&rev2=50
<amitk> you should subscribe to all pages under KernelTeam
<mpoirier> Ok, I'll read his page.  
<mpoirier> yes, I'll subscribe - thanks.
<JFo> amitk, hopefully those pages will be moving over to Kernel/ soon
<JFo> so they will become archived
<amitk> JFo: right
<amitk> once we can break up kernel building into smaller steps
<bjf> mpoirier, to subscribe to all kernel wiki pages (even ones that don't exist yet) follow the "user preferences" link on any wiki.ubuntu.com page
<mpoirier> bjf: very well thanks.
<bjf> mpoirier, there is a "Subscribed wiki pages" box towards the bottom that will take regular expressions
<bjf> mpoirier, I have ".*KernelTeam.*" as one of my regexes
<mpoirier> bjf: let me look at it and I'll get back to you if need be.
<apw> JFo, ppc is now a 'ports' kernel, which as i understand things means its a community effort
<apw> that said we do maintain the config for it in lucid and later
<JFo> I see
<JFo> hmmm
<ogasawara> JFo: will we have a bug call Monday?  Just curious since it's a holiday for US.
<JFo> ooh, good point
<JFo> I'd rather not in that case :-P
<ogasawara> JFo: heh, I'd rather sleep in :)  but I can make the call if you have it.
<JFo> nah, I want to sleep too
<JFo> I think we should reschedule though
<JFo> can we fit it into Tuesday?
<ogasawara> JFo: I could do tues
<JFo> cool
<JFo> apw, cool with a Tuesday bug call?
<JFo> err apw smb manjo et Al that is
<JFo> cnd ^^
<manjo> JFo, yeah I am 
<JFo> cool
<apw> JFo, monday is a holiday in the UK also 
<JFo> cool, Tues good for you?
 * apw reminds you that the weekly #u-m meeting is then
<cnd> JFo: as long as it's not 10-11 am EDT
<JFo> right, wasn't planning on munging the meeting time
<JFo> is it ok to do it after?
<cnd> JFo: sure
<bencer> hi all, i was using custom-binary flavours to build a patched kernel with hardy, now i'm trying to upgrade this package to lucid but seems that custom-binary are not used anymore, do i have to build my own source package like linux-rt or linux-ec2 ?
<smb> bencer, yes. If  you look at the git repo and there at the ec2 branch this shows how this is relatively simply being done
<bencer> smb: ubuntu linux packaging git repo ?
<bencer> http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-lucid.git
<smb> The lucid kernel repo gti://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
<smb> bencer, yep the same
<smb> s/gti/git/
<bencer> smb: do you have any documentation on the workflow you follow ? or just the usual git packaging
<smb> bencer, trying to find something...
<smb> bencer, Hope this helps https://wiki.ubuntu.com/KernelTeam/AbstractedDebian
<smb> bencer, There might be slight deviations from when that was written, but hopefully still accurate enough
<pgraner> apw: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/502433
<ubot2> Launchpad bug 502433 in linux (Ubuntu) (and 1 other project) "Lucid: b43 fatal DMA error on Dell Mini 9 (affects: 23) (heat: 146)" [Medium,Triaged]
<JFo> <-need food brb
 * manjo lunch
<blue_anna> Can someone help me with the em28xx kernel module on lucid ?
<blue_anna> the version of the module packaged in lucid is a few years old apparently, and only in the ones in the apst 3 years does it support my card
<blue_anna> but the em28xx module doesn't compile on my system http://pastebin.ws/a020d9 -- I get those errors following instructions specifically for lucid
<blue_anna> http://odracirls.blogspot.com/2010/04/compilacion-y-instalacion-drivers.html
<blue_anna> I downloaded the em28xx source from launchpad just to be sure, and no, my card is not in there. only in the ones since 2007
<blue_anna> I'm thinking maybe I need to rebuild the kernel with i2c support modularized. but I don't entirely feel comfortable doing that -- its been agood while since I did a kernel compile by myself
<blue_anna> and then I'm alsooo going to have to rebuild the kernel again in a few months when 10/10 comes around
<bjf> mpoirier, https://edge.launchpad.net/ubuntu/+filebug
<ogasawara> mpoirier, bjf:  note that will file the bug against ubuntu as a whole, if you want it package specific, eg linux, https://edge.launchpad.net/ubuntu/+source/linux/+filebug
<bjf> ogasawara, thanks
<apw> ogasawara, i thought that page had the package box on it
<blue_anna> are kernel modules discussed here?
<bjf> apw, it does eventually ask which package to file against
<blue_anna> or just the monolithic part of the kernel
<ogasawara> bjf, apw: yah, I think it eventually asks, but most don't know so don't put anything and it gets lost in the black hole of bugs filed against ubuntu
<pgraner> blue_anna: all matters kernel are discussed here
<apw> ogasawara, heh yeah i bet
 * BenC wonders if he will be accepted for ubuntu-kernel-team membership
<ogasawara> BenC: heh, you're not already a member?
<BenC> ogasawara: I was surprised as well :)
<tgardner> BenCI'll bet it expired
<pgraner> BenC: ask tgardner he can do it
<BenC> probably, I only barely saw the notice of my ubuntu-core-dev membership about to expire
<blue_anna> pgraner: do you think you could help me with my question just a minute ago? I'm in need of some help with it from someone who has some familiarity with the ubuntu kernel in 10.04
<ogasawara> blue_anna: just ask what you're wanting, if someone knows the answer they'll speak up
<pgraner> ogasawara: its there in the scroll back
 * ogasawara scrolls back
<pgraner> ogasawara: we seem to have an old em28xx module
<BenC> blue_anna: just comment out the line in that file that sets i2c_driver.id
<BenC> should work
<BenC> blue_anna: line 728 in em28xx_i2c.c
<pgraner> ogasawara: what did we decide with the em28xx module for M? is it getting updated?
<ogasawara> pgraner: I don't think we discussed it so I'd assume it's not getting updated
 * pgraner was nodding off in ogasawara's riveting  kernel delta session
<BenC> blue_anna: and setting LANG=C would go a long way to getting help from en speaking ppl :)
<pgraner> ogasawara: we might need to look if its indeed that old
<bjf> ogasawara, pgraner looks like we have what is currently upstream
<blue_anna> BenC: sorry :P what in that make output wasn't in english anyway ?
<pgraner> bjf: then whats blue_anna talking about then?
<BenC> make[1]:Â se ingresa al directorio `/home/roberto/CÃ³digo/em28xx-new.de_launchpad/em28xx-new'
<bjf> pgraner, this driver seems to have a sordid past, disagreements between maintainers
<BenC> blue_anna: it didn't hurt in this case, but just a good note
<blue_anna> BenC: ooh ..ok -- I don't even see the make steppings output anymore, my mind just skips straight to the compiler :)
<BenC> tgardner: thanks
<bjf> pgraner, not sure what version blue_anna is trying to get to work or where they got it from
<tgardner> BenC: np
<blue_anna> BenC: 	if (client->driver->id == I2C_DRIVERID_TUNER && dev->has_inttuner == 1) { -- that's line 728
<BenC> blue_anna: if (dev->has_inttuner == 1) {
<BenC> blue_anna: no guarantee, but try that
<blue_anna> bjf: I have both versions on my system in source right now .. em28xx from launchpad, that's the current version , you know? .. that works just fine
<blue_anna> bjf: and em28xx-new, from 2007
<blue_anna> bjf:  that's the version that supports my card
<BenC> blue_anna: id may be embedded elsewhere, so that might not work correctly
<bjf> blue_anna, i'll look at launchpad
<blue_anna> it really trips me out that the instructions in em28xx-new go out of their way to say that this works for lucid, and it doesnt :)
<BenC> if em28xx-new still has problems with the i2c_device.id change, then it's not really maintained either
<blue_anna> bjf: well you can look there but that's not where there is an issue -- here let me get you the grep you'll need
<BenC> that change in the i2c subsystem is years old
<bjf> blue_anna, no, i want to look at the one in LP, you are saying the one we carry is very old
<blue_anna> bjf: yeah
<blue_anna> bjf: here, this is the USB_DEVICE line that was added in 2007: { USB_DEVICE(0x1d2c, 0x1012), .driver_info = EM2883_BOARD_EQUINUX_TUBESTICK_ATSC }
<bjf> blue_anna, do you have a link to the one in launchpad?
<blue_anna> thats in em28xx-cards.c
<BenC> blue_anna: if all you need is a new device line, I suggest just adding that to the current driver...maybe that will work
<pgraner> bjf: http://launchpadlibrarian.net/35049921/em28xx-new.tar.gz
<blue_anna> BenC: I tried, that's not defined in the .h either so I'd have to hack all the functionality into the driver
<bjf> pgraner, thanks
<blue_anna> bjf: hg clone http://linuxtv.org/hg/v4l-dvb I think should work
<blue_anna> I just canned my history and the only em28xx I have from launchpad is the em28xx-new that doesnt compile: wget http://launchpadlibrarian.net/35049921/em28xx-new.tar.gz
<blue_anna> so I must have clsoed my term before that
<blue_anna> ** scanned
<blue_anna> I *think* the problem with the em28xx not compiling is because i2c-core is not a module in 10.04
<blue_anna> it's monolithic
<BenC> blue_anna: no, that's not the problem
<BenC> blue_anna: I just looked at the source, make the change that I suggested and it should work
<bjf> blue_anna, the reason lucid is "older" is because none of that code has made it upstream
<bjf> blue_anna, i suggest trying what BenC is telling you
<blue_anna> bjf:  I just found a bug about this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/489353
<ubot2> Launchpad bug 489353 in linux (Ubuntu) "em28xx-new should be added to repository (affects: 1) (heat: 8)" [Medium,Confirmed]
<blue_anna> I didnt know I wasn't the only one :) I?ve been trying to get help on ubuntu forums and #ubuntu for the past month :P
<blue_anna> I'll consider it a crash course in ubuntu from the dev-side :)
<BenC> blue_anna: after I made that change, the driver(s) compiled just fine
<BenC> with no errors in missing symbols, so it should load fine as well
<blue_anna> BenC: I'll try it :) thank you
<blue_anna> I'm just worried that that will change the functionality quite a lot .. but still, it's completely worth it to try
<vanhoof> JFo: happy birthday :)
<JFo> thanks vanhoof :)
<JFo> I feel old
<BenC> blue_anna: it does not change it at all for you, since your device doesn't define has_inttuner, so that whole if statement is a no-op anyway
<vanhoof> JFo: another year wiser ;)
<JFo> I need more wisdom than one year alone could impart :)
<blue_anna> BenC: :) lolo , that works for me
<blue_anna> BenC: it compiles! and loads,  but it is misbehaving when I plug in the usb device: http://pastebin.ws/ahv11z
<blue_anna> BenC: and you were right about what you said before so that's a different problem in the driver :P
<BenC> blue_anna: you have some mix-matched modules being loaded
<BenC> blue_anna: make sure to install all the drivers from your build (./build.sh install)
<blue_anna> it did
<BenC> I would reboot then
<blue_anna> sudo make install said "running ./build.sh install"
<BenC> or manually unload all the modules
<blue_anna> ooo yeah
<blue_anna> good idea
<blue_anna> :) lol -- thank BenC, wish me luck
 * BenC holds his breath
<BenC>         #FIXME Why not just do make install here?
<BenC> the build script makes a good point...
<apw> heh ... don't you just love those sorts of comments
<BenC> and I feel sorry for blue_anna because that build.sh install just rm -rf'd a lot of stock modules from his system...hopefully nothing important
<BenC> s/his/their/
<apw> real name was roberto ... 
<blue_anna> BenC: same errors on boot :S
<BenC> blue_anna: find /lib/modules/`uname -r`/ -name em28xx\*
<blue_anna> can you explain to me your thinking on the conflicts? I want to understand why you thought that
<blue_anna> ok, just a sec
<BenC> blue_anna: it said it in your pastebin "disagrees about symbols"
<BenC> blue_anna: have you built new videodev modules on your system (v4l2/video4linux2)?
<blue_anna> BenC: http://pastebin.ws/8eprrl
<BenC> blue_anna: or do you have any weird header conflicts?
<blue_anna> BenC: the normal em28xx would load without these issues, just the nem28xx-new that is having troubles
<BenC> blue_anna: I know, but what it seems to show is that the videodev modules on your system do not agree with the headers that em28xx-new was compiled against
<blue_anna> I don't know that I built the v4l2 stuff, you can see in the output I do have some v4l loaded, which maybe is the conflict ?
<BenC> v4l has to be loaded since em28xx uses it
<blue_anna> my pastebin has my lsmod grepped to v4l
<blue_anna> there is both (??) v4l and v4l2 related modules loaded
<BenC> blue_anna: videodev is what you want to grep for
<blue_anna> thanks, I'll grep t
<blue_anna> *it
<BenC> blue_anna: and more importantly can you pastebin "ls -lR /lib/modules/`uname -r`/"
<blue_anna> that's a lot of output
<blue_anna> waiting for my webbrowsser to recover from the paste :)
<blue_anna> the only other videodev that loaded is videodev itself
<BenC> right, it appears to not match your kernel headers
<blue_anna> man that smashed firefox :P
<blue_anna> still at 100%cpu
<blue_anna> let me try oepra, it's less buggy
<BenC> hehe, I guess you could just do "ls -lR /lib/modules/`uname -r`/ | grep video"
<BenC> might be a bit easier
<blue_anna> ok :)
<blue_anna> http://pastebin.ws/5c08oc
<BenC> yeah, you definitely screwed up your system
<BenC> rm -rf /lib/modules/`uname -r`/empia
<blue_anna> what do you mean? 
<blue_anna> ok
<blue_anna> htat's scary but ok
<BenC> rm -rf /lib/modules/`uname -r`/kernel/drivers/media
<BenC> blue_anna: you've installed a new version of v4l, which is breaking your system
<blue_anna> that's more scary .. I'm going to move that instead
<blue_anna> ok
<BenC> apt-get --reinstall install linux-image-2.6.32-21-powerpc64-smp
<BenC> then rebuild and install em28xx-new
<blue_anna> ok, just a minute
<BenC> blue_anna: we could have saved a ton of time if you had told me you did that
<blue_anna> sorry, ..
<blue_anna> .. by my mind this hasnt been a ton of time, but I told you I've been working on this for a month so, to me it would take a few days before we got there :P
<BenC> well, by my time, we spent nearly 30 minutes tracking down a problematic symbol mis-match, and that's about 50% of the time I've spent helping you :)
<blue_anna> I am still getting a ton of warnings 
<blue_anna> but it built
<BenC> modprobe -r videodev
<BenC> then insert your usb device
<blue_anna> Ã§WOOOHOO!
<blue_anna> well it loaded, and it .. I'm getting messages like the device is being attached to the driver but MeTV didnt find it .. let me post you the log
<blue_anna> BenC: just tell me if the driver looks like it is working? I'll take on MeTv myself if it is :)
<blue_anna> http://pastebin.ws/g8t6fw
<BenC> blue_anna: looks good to me
<blue_anna> BenC: thank you that's the first time in a month I made progress .. and it happened all at once :)
<BenC> blue_anna: I'd try some basic v4l apps to see if you can get it working there before going to a specialized program
<BenC> blue_anna: vlc/mplayer perhaps
<BenC> blue_anna: glad I could help
<blue_anna> is there any general way that a kernel module finds the right firmware file to load?
<tgardner> blue_anna, request_firmware() looks first in /lib/firmware/`uname -r`, then in /lib/firmware
<blue_anna> tgardner: thanks
<tgardner> blue_anna, its a function of /lib/udev/firmware_helper
<blue_anna> can anyone tell me what good em28xx-dvb is in here: wget http://launchpadlibrarian.net/35049921/em28xx-new.tar.gz
<blue_anna> it looks like the dvb extension god garbled in this version of the source, its just a bunch of attributes now
<blue_anna> *got
<stenten> If I'm trying to triage someone's Kernel Oops, should I just tell them to install linux-crashdump and be done with it?
<stenten> There's all kinds of crazy oopses in kern.log, but they're all different and I'm not sure which one is responsible for the crash.
#ubuntu-kernel 2010-05-29
<blue_anna> how would I build just the drivers in /usr/src/linux-source-2.6.32/drivers/media/video/em28xx
<blue_anna> I only see .o objects in the Makefile, no .ko's
<blue_anna> anyone here just now?
<blue_anna> anyone ever build a kernel module from inside the kernel source tree?
<blue_anna> blue_anna: make M=dir modules 
<blue_anna> blue_anna: oo thanks
<fqh> Hi, can nvidia driver be used under custom compiled kernel?
<maks_> use nouveau fqh 
<fqh> nouveau seems be in kernel source.
<cao> does the kernel 2.6.34-5.12 (from ppa) include the latest (20th of may merged to mainline) pcie hotplug patches?
<Kano> apw: CONFIG_SND_PCM_OSS is not set?
<Kano> why did you disable the oss emulation?
<Kano> # CONFIG_SND_MIXER_OSS is not set
<Kano> # CONFIG_SND_PCM_OSS is not set
<Kano> # CONFIG_SND_SEQUENCER_OSS is not set
<Kano> i would enable those...
<pgraner-afk> Kano: they are deprecated and they were disabled on upstreams recommendation
<Kano> thats stupid for old games
<pgraner-afk> Kano: its not stupid, the rest of the userspace support is not there yet that will allow the older games to work. see the blueprint [1] or https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300   [1] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-config-review
<ubot2> Launchpad bug 579300 in linux (Ubuntu) "Please disable CONFIG_SOUND_OSS* and CONFIG_SND_*OSS* (affects: 2)" [Wishlist,Fix released]
<apw> Kano, those are disabled to allow userspace to emulate them instead, its possible that is not yet in place
<Kano> that does not work well
<apw> you are welcome to change it in your config, the plan currently is to use userspace emulation.  if there are issues we'll find out in testing
<Kano> kanotix users have problems because of it, will change it of course
<parren> I'm bothered by slow resume times on my MacBook Pro seemingly due to the battery driver. Likely a problem related to VirtualBox having trouble with sporadic hangs of Windows clients unless you remove the ACPI driver from the Windows client. See https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/575180.
<ubot2> Launchpad bug 575180 in pm-utils (Ubuntu) "PM: resume of drv:battery dev:PNP0C0A:00 complete after 59348.072 msecs (affects: 2) (heat: 12)" [Undecided,New]
<parren> Does anyone have a pointer as to how I could contribute to getting the root of this?
<crimsun> cnd: Intel+Sigmatel/IDT isn't affected
<crimsun> aren't, rather
#ubuntu-kernel 2010-05-30
<l3on> Hi all... I've some problem with 2.6.32-22. DVB does not work anymore.
<l3on> I looked at the debdiff, there are a lot of lines quoting "dvb"
<l3on> so.. I did this:
<l3on> cat debdiff | grep dvb | grep ^- > dvb-
<l3on> cat debdiff | grep dvb | grep ^+ > dvb+
<l3on> diff dvb- dvb+
<l3on> result is "null".
<l3on> But... my DVB-S card works fine in 2.6.32-21
<lapion> hello.
<lapion> Does anyone know what change from gutsy would require the use of noapic or nolapic to boot on a pentiumk 4 ?
<lapion> in gutsy the system booted with apic no problems whatsoever..
<lapion> gutsy onwards the system requires adding no noapic or nolapic on the command line..
<lapion> l3on, what dvb card do you have ./
<crimsun> lapion: there are many, many possible candidates
<crimsun> lapion: I recommend you file a bug if you haven't.
<lapion> the problem with the bug is that it's behaviour is very strange
<lapion> if I boot with a newer kernel and with apic, at a certain moment during boot the system freezes, unless I press a key, any key.. such as ctrl or shift or alt or any other key, 
<lapion> during keypress the system will continue booting, but as soon as I release the key the startup procedure slowly grinds to a halt again.. untill key is pressed again..
<l3on> lapion: 04:07.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
<crimsun> this is all a bit ridiculous. We need to flip the default DMA update method for HDA, because the blacklist is exploding. I've pushed fifteen fixes in the past month. :(
<l3on> lapion: what I see from my DVB client is that when I try to lock frequency I not receive the FE_HAS_LOCK
<l3on> that was defined in frontend.h:
<l3on> linux/dvb/frontend.h:	FE_HAS_LOCK	= 0x10,   /* everything's working... */
<l3on> lapion: I discovered that there are no changes between:
<l3on> diff -Nur linux_2.6.32-21.32/drivers/media/dvb/ linux_2.6.32-22.33/drivers/media/dvb/
<l3on> result is "null"
<l3on> So, is it a build problem ?
<m_gol> hi, why there is no kernel ppa repository and there's only the site? It would be easier if small updates (meaning "the fourth number" updates) for newer kernels could be performed automatically...
<pgraner> m_gol: the way ppa's are structured and they way the kernel is packaged make it impossible with out changes to the LP infrastructure
<m_gol> pgraner: I don't understand... You provide debs for kernels - what is exactly the problem with putting them into a repository?
<pgraner> m_gol: its the nameing and abi, if we don't bump abi it will overwrite the previous kernel in ppa which is not desired, we need to keep each build
<pgraner> m_gol: we don't bump abi unless we have to as it breaks 3rd party modules (aka vmware et al.)
<JanC> I'd say it's not that difficult in itself, but requires a LP change to special case the kernel packages?
<pgraner> m_gol: we use ppa's for scratch/test builds (ie. testing specific bug fixes)
<pgraner> JanC: correct LP needs to understand abi which it dosen't do now
<pgraner> JanC: since we have a workable solution and the change is only needed for the kernel its not high priority
<m_gol> OK, I see
<m_gol> anyway, if one day it was possible, I and many others would be grateful :)
<JanC> so as long as the ABI doesn't change between 2.6.X & 2.6.X+1, LP can't handle that?
<JanC> well, or maybe 2.6.X.Y & 2.6.X.Y+1
<m_gol> there are a lot of problems that often can be solved by kernel upgrade (drivers mainly), e.g. I had to keep old version of wine because of some signal-related bug that causes HoMM3 to hang with newer wine on kernels < 2.6.34...
<JanC> BTW: it was nice to have Steve Conklin(sp?) and his wife at LGM  :) 
<akgraner> JanC, the Conklin's are awesome!
<pgraner> JanC: yea steve is a great guy
<JanC> akgraner: I didn't know you knew his wife or actually she was related to ubuntu somehow until a day or so after her talk
<JanC> when you said so in #u-w or so
<JanC> LGM was really cool BTW
<akgraner> yeah - she does some great design work on clothes
<akgraner> and she has some great ideas for re-purposing t-shirts and stuff
<JanC> that's why I think LGM was so cool: a mix of artaists & developers & more "ordinary" users of "graphical" applications
<JanC> and "design" etc.
<stenten> Is seeing this in kern.log during suspend any cause for concern? "ACPI handle has no context!"
#ubuntu-kernel 2011-05-23
<ppisati> reboot
 * ogasawara back in 20
<diwic> bjf, latest update for c-o-t-d 2.6.38 seems to have been 2011-05-05 
<bjf> diwic, that was the first and only, was waiting feedback
<diwic> bjf, aha 
<bjf> diwic, i can fire off another if desired
<diwic> bjf, if it's simple, please do
<bjf> diwic, will do
<diwic> bjf, meanwhile I installed the package and it seems to work fine, so I think you're good to go for enabling daily builds for Natty as well
<bjf> diwic, just uploaded a new one, thanks for the feedback, will start doing them automatically
<diwic> bjf, thanks!
<bjf> diwic, added, if you see any issues with it now, don't hesitate to mention it/them
<JFo> bjf, how would I add that kernel call to my collection?
<JFo> I tried by the URL, but no joy
<JFo> and I am too stupid just now to figure it out :)
<bjf> um, one sec
<hggdh> bjf, sconklin: I do not see any pending karmic kernel to be tested. Am I missing something?
<bjf> hggdh, looks like someone went ahead and promoted the karmic kernel to updates
<bjf> skaet, ^
<skaet> bjf, hggdh,  looks like we have a process failure then.
<skaet> :P
<hggdh> well, we can still go ahead and validate it, just in case
<skaet> hggdh,  please do so.
<bjf> JFo, did you get some notice about that calendar? i just added you to the share list
<skaet> I'll take this up with pitti and see if we can figure out what happened.
<hggdh> k
 * JFo looks
<JFo> bjf, looks like it just showed up in my main calendar now. Thank you :)
<bjf> JFo, np
<skaet> hggdh,  please let me know if there's any problems with it, soonest.   
 * apw pops out to get a replacement hdmi cable
<bjf> ogasawara, we going to do a status meeting this week ?
<ogasawara> bjf: yep, that's the plan
<bjf> ogasawara, always good to have a plan, do we have a list of blueprints we are going to be tracking ?
<ogasawara> bjf: https://wiki.ubuntu.com/KernelTeam/Specs
<bjf> ogasawara, we're going to want all of them on the agenda or you want me to pick the ones I think are relevant?
<ogasawara> bjf: I'd only pick out the relevant ones.
<bjf> ogasawara, ack
<bjf> ogasawara, i've updated the meeting agenda, most of the blueprints are for you, let me know if there are others you think should be added
<ogasawara> bjf: ack
<ogasawara> bjf: I'm gonna move the one work item from the misc blueprint to the server-reqs blueprint and then we can just drop the misc blueprint from the agenda
<bjf> ogasawara, wfm
 * apw notes that plugging and unplugging hdmi outputs on intel leads to crashes :/
<jjohansen> apw: is that with the latest intel driver?
<apw> jjohansen, with whatever is latest in natty
<apw> now on a .39 kernel shall see if its any better
<jjohansen> apw: ah there where some hdmi improvements in the latest intel drm tree, not sure what made it into .39 though
<apw> jjohansen, ok will see how this pans out
<JFo> ogasawara, just saw your response :-)
<ogasawara> JFo: pick a time when you want to start your kernel patching and git-fu, I'll put it in my schedule.  not sure it'll require a full hour each week, but we should just start
<BenC> Any chance that bug #424142 will get fixed in lucid's kernel?
<ubot2> Launchpad bug 424142 in linux "Address Collision" [Undecided,Confirmed] https://launchpad.net/bugs/424142
<BenC> I've just had a couple customers get bit by it, upgrading them to maverick kernel fixed it
<JFo> ogasawara, right, my hope is that some of these will taper off and not be needed.
<JFo> just wanted to get them started and indicate how serious I am about them to everyone :)
<BenC> I suspect no, since linux-lts-backports-maverick is available
<ogasawara> BenC: if it came through the next 2.6.32.y upstream longterm release, it'd get applied to Lucid.  or use the backports kernel.
<BenC> ogasawara: No chance of someone actively searching for the fix? Isn't 2.6.32.y inactive? :)
<ogasawara> BenC: I thought 2.6.32.40 just came out, was that the last one?  /me hasn't been following
<BenC> wait, I didn't realize upstream was maintaining longterm kernels now, so hopefully they do a 2.6.32.y to fix it
<bjf> BenC, GregKH still maintains .32
<sforshee> BenC, ogasawara: looks like the fix was in 2.6.33 (commit 8c8def26) so it just never made its way to stable
<BenC> Right, I knew it was fixed in 2.6.33, was just hoping for some love in lucid, even if 2.6.32.y isn't getting it upstream
<sforshee> I'm just saying that if we wait for it to show up in .32 stable it's never going to happen
<BenC> That's exactly what I'm saying :)
<bjf> sforshee, you want to do an SRU for it?
<sforshee> bjf, sure, I'll try to get some testing on it first to make sure it really fixes the problem
<bjf> sforshee, that looks like a reasonable candidate
<bjf> wfm
<bjf> sforshee, looks like BenC might be able to help test :-)
<BenC> Customers gave me sudo access to the affected machine, so I plan to abuse it as much as possible...
<ogasawara> hehe
<BenC> if you get something testable, I'm happy to toss it on there
<sforshee> BenC, I'll post a kernel to the bug report shortly, then I'll submit it for SRU as soon as you can get it verified
<bjf> sforshee, not a rush, just information, if you can get a fix verified soonish, we are prep'ing kernels for the next cadence cycle
<sforshee> bjf, ack
<BenC> sforshee: ok, please ping me on here, launchpad traffic doesn't get through my usual filters
<sforshee> BenC, will do. If you tell me whether you'll use a 32-bit or 64-bit kernel for testing I'll make sure the one you need is built first.
<BenC> sforshee: Thanks, 32-bit
<BenC> sforshee: this patch doesn't affect ABI, correct?
<sforshee> bjf, would you be so kind as to accept the lucid nomination on bug #424142 ?
<ubot2> Launchpad bug 424142 in linux "Address Collision" [Undecided,Confirmed] https://launchpad.net/bugs/424142
<sforshee> BenC, it shouldn't
<BenC> if it does, I would need to get the headers to fully test against this module
<bjf> sforshee, you bet
<BenC> sforshee, bjf: a huge thanks for the effort on this as well
<bjf> BenC, np
<sforshee> BenC, I'll give you the headers, but as it only changes a function body it shouldn't affect the abi at all
<bjf> sforshee, done
<sforshee> bjf, thanks
<BenC> sforshee: I could have approved it for you :)
<sforshee> BenC, 32-bit test build is posted at http://people.canonical.com/~sforshee/lp424142/2.6.32-32.62~lp424142v201105231936/
<herton> bjf: can you approve nominations for bug 787145
<ubot2> Launchpad bug 787145 in linux-ti-omap4 "CVE-2011-1494" [Undecided,New] https://launchpad.net/bugs/787145
<bjf> herton, working it
<bjf> herton, done
<herton> thanks bjf
<bjf> np
<BenC> sforshee: ok, give me 30 minutes
<BenC> sforshee: not stalling...this box doesn't boot unattended so I'm just waiting for some one to kick it
<BenC> sforshee: I've at least smoke tested here locally, but not on a box that exhibits the problem
<sforshee> BenC, cool, I've got everything ready to go for once we know it fixes the problem
<BenC> sforshee: confirmed that it fixes the issue, and commented on the bug report
<shankara>  hi all, i'm having a weird issue trying to reboot with linux 2.6.38 (x86_64), ubuntu LTS 10.04, this is on atom D525 - dual core atom
<shankara> system hangs on restart with: "will now restart" and then "[<some varying number>] Restarting system"
<shankara>  i've tried recompiling a variety of kernels
<shankara> i've even compiled specifically for the atom, not using generic
<shankara> same issue. but soft halt works fine
<shankara> is this a known kernel support issue with atom dual core cpus ?
<BenC> shankara: It sounds like an issue with the kernel you are compiling, like a panic, maybe related to your root filesystem
<BenC> Sounds suspiciously like you are just compiling the kernel wrong
<BenC> shankara: And specifically, it sounds like an issue you just have to figure out through more generic channels #kernelnewbies perhaps?) since it isn't an Ubuntu issue
<shankara> BenC: i found this on the generic default kernel that  came with lts 10.0.4
<BenC> You said it was 2.6.38
<shankara> after a couple of binary kernels, i decided to compile my own
<shankara> same issue
<bjf> shankara, have your tried our lts-backport kernel?
<shankara> that's the most recent kernel i tested
<shankara> bjf: not yet, maybe i should
<shankara> i only  resorted to source compiles after all the binary kernels in the apt repo gave me the same  soft reboot issue
<BenC> shankara: Booting with single (so without quiet) would be more helpful
<BenC> The reason for the panic might give some clues to the real problem
<shankara> BenC: i'm inclined to the some clues to the real problem might provide a reason for the panic
<shankara> actually ... i wouldn't say it's a panic
<shankara> there's no "ooops"
<BenC> I would say it is a panic
<shankara> it jsut doesn't actually restart the hardware, just promises to
<BenC> The "will not restart" message comes right after a panic
<BenC> err "will now restart"
<BenC> shankara: If it fails to exec /sbin/init or similar, it will panic
<BenC> panic != BUG
<shankara> Benc: yes, sorry: "Will now restart"
<BenC> it means "oh crap, I don't know what to do next"
<shankara> BenC: it actually get's past stopping all system services, unmounting all filesystems ... then it jsut doesn't , so it seems init runs it's full course
<shankara> sorry "then it just doesn't restart the hardware"
<BenC> shankara: Do you mean it will actually boot, just not reboot?
<shankara> it'll boot, it'll even halt. Just it wil not soft restart
<shankara> ctrl-alt-delete has the same effect - no restart
<BenC> Oh, I misread "trying to reboot with.." as "trying to reboot into..."
<BenC> shankara: I have some tips for this problem...
<shankara> yeah, it's a weird one
<shankara> most people are trying to boot their boxes, I'm trying the opposite
<shankara> restarting is critical for remote support on appliances
<BenC> shankara: Try adding reboot=bios to your kernel command line
<shankara> BenC: let me try that and get back to you 
<BenC> shankara: reboot=acpi might be worth trying too
<shankara> ack.
<sforshee> BenC, just sent SRU patch to kernel-team list, thanks for testing
<BenC> sforshee: np, thank you for taking on the logistics to get it in an SRU
<broder> is there anything i can do to accelerate getting help with bug 784335? i don't really have any kernel debugging-fu, but the machine in question isn't my primary machine and doesn't have any data on it, so i can re-install or re-configure it 10 ways to sunday if that helps
<ubot2> Launchpad bug 784335 in linux "Heavy network utilization with r8169 leads to kernel panic" [Undecided,Confirmed] https://launchpad.net/bugs/784335
<BenC> broder: I would argue that r8169 is a horrid driver and would suggest you'd have better luck wedging an e1000 card in there :)
<BenC> but I'm not the official spokesperson, so I digress
<BenC> broder: a pic of the on-screen panic would help
<broder> BenC: is the core dump not good enough?
<BenC> broder: I'd have to set aside time to dig into that, perhaps later tonight
<broder> if i were to go and play the role of the apport retracer, would that get the bug more attention?
<shankara> BenC! you're a genius! reboot=acpi worked :D
<shankara> thanks!
<TheSeven> as some people seem to be awake currently, I'd like to re-ask my question from like a week ago: http://paste.ubuntu.com/612064/
<TheSeven> any hints?
<JFo> TheSeven, have you filed a bug?
<TheSeven> no, as i don't have a clue what to file it against
<TheSeven> this kinda seems to be an OMAP or ARM specific problem
<TheSeven> but it doesn't seem like the OMAP guys would know what's the cause for it
<TheSeven> so i'd like to check if there are any general hints for situations like this (some tunables maybe?)
<JFo> so you would file it against linux which encompasses all of them and then I would go about determining if it was specific to one of them.
<JFo> very simple process too... from a term run 'ubuntu-bug linux'
<TheSeven> the maximum throughput being at a sub-sector block size and the fact that it happens both with USB and SD makes me think that this can't really be coming from the MMC/USB controller, but must be coming from some generic I/O code
<JFo> presto! bug report! :-) How is that for the soul of ease? :)
<JFo> very possible
<JFo> but I would like to see the logging we collect from the bug report tool to dig a bit deeper.
<JFo> so when it is behaving thus, if you could file that bug it would be most helpful
<TheSeven> JFo: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/787246
<ubot2> Launchpad bug 787246 in linux-ti-omap4 "Slow SD card and USB HDD I/O for block sizes bigger than a couple of bytes" [Undecided,New]
<broder> BenC: does http://pastebin.ubuntu.com/612078/ look like it has the information you wanted?
<broder> i'm not super-familiar with digging around in vmcores
<hggdh> smb: there?
<jjohansen> hggdh: its pretty late in the day for smb to be here (00:47) for him
<hggdh> jjohansen: yeah, I had just remembered he is UTC+1 or 2...
<hggdh> jjohansen: perhaps you -- I am unable to boot the curretn maverick proposed on AWS, i386/m1.small
<jjohansen> ugh, I can have a look
<hggdh> jjohansen: what do you need?
<jjohansen> hggdh: hrmm, nothing just yet.  I will boot an m1.small and install a proposed kernel and try to duplicate, and go from there
<jjohansen> hggdh: actually, which region/zone, and even machine type if you can get that info
<hggdh> jjohansen: OK. What I did -- what I always do --: I booted the current AWS Maverick, then run a dist-upgrade with -proposed enabled
<jjohansen> hggdh: right, I think I will be a little more selective and just pull the kernel
<hggdh> jjohansen: ec2-run-instances ami-b21de3db --instance-type m1.small --region us-east-1
#ubuntu-kernel 2011-05-24
<jjohansen> hggdh: confirmed
<hggdh> jjohansen: should I open a bug for that?
<jjohansen> hggdh: no not yet, I'll poke at it or at the least poke smb when he comes on
<hggdh> jjohansen: thank you
<broder> so now that i've grabbed the stacktrace, is there anything i can do to help with the debugging of bug 784335?
<ubot2> Launchpad bug 784335 in linux "Heavy network utilization with r8169 leads to kernel panic" [Undecided,Confirmed] https://launchpad.net/bugs/784335
<jj-afk> back on later
<bAdGigabit> Dose the current kernel support packet injection?
<bAdGigabit> more specific. Will it support it for the ath9k drivers?
<bAdGigabit> sorry, did anyone reply?
<bAdGigabit> sorry, i kewp getting disconneted
<bAdGigabit> any awnsers that i missed?
 * apw yawns
<jk-> hey apw & smb
<apw> moin jk-
<smb> morning jk- 
<eagles0513875> morning apw :D 
<valorie> hi all, since I upgraded to 11.04, my mic jack no longer works
<valorie> I searched the bugs, but didn't find anyone else reporting this
<valorie> what do i need to do to report a useful bug?
<apw> eagles0513875, hi
<eagles0513875> how goes it apw
<apw> valorie, thinking
<valorie> eagles0513875 suggested I ask here
<apw> smb, can you remember what we file sound bugs against, alsa something something
<eagles0513875> apw: it was my suggestion to have her ask here as we thought it might be a kernel issue
<eagles0513875> me im kinda having a similar issue with usb webcam with mic and pulse audio
<valorie> mic doesn't work either, but it never has
<smb> apw, Something like that... could it be alsa-driver or so?
<valorie> I think
<apw> very likely a kernel issue, and reporting it against the right package is the key
<apw> and before my first coffee i can't think what its called
<eagles0513875> apw: should we have her try the proposed 38-9 kernel
<valorie> I'll be around for another hour or so
<awilkins> valorie, Do you know what sound hardware you're using?
 * valorie serves coffee around the chan
<apw> awilkins, i was just going to mention your fix
 * awilkins grins
<eagles0513875> im wondering if his fix woudl apply to usb webcams that have mics then again im not sure what that fix is 
<valorie> not off the top of my head
<awilkins> Probably not to a USB webcam with integrated mic
<valorie> what's the command to find out?
<eagles0513875> valorie: a simple lspci should tell ya 
<eagles0513875> mines a Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01)
<eagles0513875>  
<eagles0513875> valorie: lspci on command line and find the line that says audio :D
<eagles0513875> i think before it worked with my other motherboard which had a realtek audio chipset this has an intel one : (
<apw> valorie, i think its "ubuntu-bug audio"
<valorie> 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
 * apw thinks people have been chanigng things on us
<valorie> 01:05.1 Audio device: ATI Technologies Inc RS780 Azalia controller
<awilkins> Intel HDA... so that might be affected by that fix
<awilkins> Intel HDA is an abstraction for a bunch of different chipsets from what I can gather
<apw> awilkins, your change was to the codec side wasn't it ?  remember which one?
<awilkins> AD1988
<awilkins> valorie, Do us a   `dmesg | grep hda`
<awilkins> And tell us what the line with hda_codec says
<eagles0513875> valorie: did you check ur settings in the bios
<eagles0513875> if you dont have it set to use hd you need to 
<valorie> http://paste.ubuntu.com/612193
<valorie> no line with hda_codec
<valorie> how do I check the setting in the bios?
<valorie> I've done that before, but years ago
<awilkins> valorie, You'd have to play that by ear - reboot, watch your power up messages for the key for "setup", and hunt around in your menus
<eagles0513875> ya 
<awilkins> BIOS setup usually requires you to make an affirmative choice to save settings also
<eagles0513875> i checked my bios and i dont have any settings in mine 
<eagles0513875> this is hopefully a temp motherboard i have 
<eagles0513875> till i rma my higher end motherboard
<awilkins> But there are too many nonstandard variants for us to walk you through it, probably in the "PCI devices" area
<eagles0513875> actually im thinking my issue is more with skype itself
<valorie> well, this is my laptop/work/main computer
<eagles0513875> cuz i use mumble 
<eagles0513875> and my mic works just fine :( 
<valorie> oh weird
<eagles0513875> ya
<eagles0513875> i know 
<valorie> well, skype used to work
<eagles0513875> i know 
<valorie> now the mic doesn't
<eagles0513875> valorie: sme issue
<eagles0513875> same*
<valorie> but I don't remember if that was a different lappy or this one
<eagles0513875> apw: who would we need to contact to report this as skype is in the ubuntu partner repo
<valorie> BUT: soundrecorder doesn't work either
<valorie> eagles0513875: HA!
<valorie> like Microsoft will care
<eagles0513875> the funny thing
<eagles0513875> the older static libs on the skype site work just fine 
<eagles0513875> even the version in 10.10 worked
 * eagles0513875 needs to develop an alternative to skype before it gets destroyed
<awilkins> Skype works just fine on pulse now
<valorie> skype hasn't worked for me for at least the last 3 versions of kubuntu
<eagles0513875> awilkins: i have no mic input 
<valorie> but I've not had a problems with the headphones for a long, long time
<eagles0513875> it works fine but no mic
<eagles0513875> awilkins: how did you manage to get it to work
<valorie> jack worked until upgrade, and then it didn't
<awilkins> eagles0513875, Neither did I - previously suffered from #593018, then from #776964
<eagles0513875> skype says to go into the pulseaudio settings and i have no idea where those are
<valorie> veromix will do it
<awilkins> valorie, I had the same thing - but before I had to flip-flop the input selector to get the mic working, but then it stopped
<eagles0513875> awilkins: its saying i have to use the local mixer to adjust settings but kmix doesnt have my cam mic listed
<valorie> or pavucontrol
<valorie> eagles0513875: does alsamixer have it listed?
<awilkins> eagles0513875, Well, it sounds like the driver for your cam mic isn't working, or isn't present
<eagles0513875> in kmix my logitech quick cam is listed
<valorie> sec
<awilkins> valorie, Since your hardware previously worked, more chance of working out what's wrong
<eagles0513875> skype is bugged 
<eagles0513875> i installed pavucontrol and mic is picking up sound there 
<eagles0513875> skype for some reason isnt
<awilkins> Which version of Skype? I'm presuming latest
<awilkins> Specifically, I have 2.2 beta and it works fine with GNOME / Pulseaudio.
<awilkins> If you can record sound from your mic, eagles0513875, it's not really a kernel problem, and I would suggest you'd have more luck in a channel devoted to userland software.
<eagles0513875> ya
<eagles0513875> awilkins: version of skype taht is in the partner repo
<awilkins> eagles0513875, AFAIK that's the same as the one straight from the skype website. Mine says 2.2.0.25 in it's "About" box
<eagles0513875> ya
<eagles0513875> might uninstall it 
<eagles0513875> and use the static package from the site
<valorie> yay, you got your sound working though!
<awilkins> eagles0513875, Try cleaning out it's settings first, move the ~/.Skype folder out of the way, start it up, and try a test call
<valorie> I don't have time to restart tonight, but tomorrow when I start up, I'll look in the bios and see if I find anything suspicious
<awilkins> valorie, The other tool I found useful was  http://www.alsa-project.org/main/index.php/HDA_Analyzer
<awilkins> valorie, That lets you mess directly with the codec parameters
<awilkins> valorie, In my case, my mic input pin was not set up right - it needed it's VREF setting to be 80, but the driver wasn't initializing it correctly
<awilkins> See : https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bug/776964
<ubot2> Launchpad bug 776964 in linux "p5n32e-plus HDA Nvidia AD1988B microphone input not working" [Low,In progress]
<eagles0513875> awilkins: still nothing 
<eagles0513875> i dont have time to hack at this right now
<awilkins> valorie, We've not really discovered what your sound hardware is yet - HDA Intel hides a bunch of implementations and your dmesg didn't tell us what it was either
<awilkins> That tool will probably be more informative, at least
<valorie> any way to dig deeper?
<awilkins> http://www.alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA
<valorie> oh, hda analyzer
<valorie> which is a script to run
<awilkins> Yes, you have to run it as root
 * eagles0513875 wants my original motherboard back so badly
<awilkins> sudo python run.py
<valorie> not sure I can make heads or tails of it
<eagles0513875> my original motherboard works so much better then this one 
<eagles0513875> would probably require a linux reinstall though :( 
<valorie> I'm a writer, not a devel
<awilkins> valorie, It just gives you direct access to all those little switches that you see in a recording studio
<awilkins> valorie, Instead of one big volume knob
<eagles0513875> awilkins: usually i stick with the nvidia nforce chipsets 
<eagles0513875> those have realtek which i have never had any issues with 
<eagles0513875> not to mention i can use fully my 5.1 atm down to 2.1 with this motherboard
<awilkins> eagles0513875, I have an nforce, but my sound is an Analog Devices
<eagles0513875> would love to take advantage of the spdif the other motherboard has
<awilkins> valorie, If you have HDAAnalyzer running, what's the name on the first AUD_OUT device?
<apw> awilkins, this thing should be packaged and installed by default
<awilkins> apw, The HDAAnalyzer thing downloads components of itself, but I suppose you could install the bootstrap script. I would guess that
<apw> i think i would be happier if someone packaged the bits
<apw> as its a bit scarey to download some random stuff and run it as root
<awilkins> I would guess that HDA Intel is probably responsible for quite a few bugs because of the myriad of implementations
<awilkins> But the actual implementation inside seems to hide well
<awilkins> lspci for me does not reflect that the codec is an AD1988B, neither does HDAAnalyzer either, to be true
<awilkins> Apart from some of the node names
<diwic> for HDAanalyzer, just download snd-hda-tools from ppa:diwic/ppa and run "sudo hda_analyzer"
<awilkins> dmesg reports it, but valorie doesn't seem to have that so maybe there is an inconsistent level of logging in the various codec implementations in the drivers
<valorie> oh, rather that wgetting it?
<valorie> I was opening the /proc/asound/card0/ and looking at it
<diwic> valorie, yeah, I packaged it and a few other hda tools up
<diwic> (i e if you were asking me)
<awilkins> valorie, The first line of /proc/asound/card0/codec#0 seems to be the information we seek
<awilkins> At least, in my case
<valorie> Codec: IDT 92HD71B7X
<awilkins> On the plus side, that's marvellously specific
<awilkins> On the downside, it's not the thing we have recently fixed
<valorie> snd-tools is installing
<awilkins> So it worked in Maverick but not Natty?
<valorie> yes
<valorie> ok, what do you need from that analyzer?
<awilkins> valorie, I can't think of anything specific... but what you can do is try to find your Mic input pin
<awilkins> So you should have a bunch of PIN nodes
<valorie> in node editor, or text dump?
<awilkins> Node editor
<awilkins> On the left in the tree there are a bunch of PIN nodes
<valorie> oooh
<awilkins> If you look in the Config default section on the right, you will see some description of each node
<awilkins> Find the one your Mic is plugged into
<valorie> Press Detect
<valorie> Headphone Drive
<valorie> Output
<valorie> first pin
<awilkins> I found the "Jack color" and "Jack location" bits helpful locating it
<valorie> mic jack is pink!
<awilkins> e.g. mine is PIN 0x17  Jack type : Mic  Jack location : Ext Jack location2 : Rear
<awilkins> That's the one
<awilkins> What's it's Wiget control section say?
<valorie> boxes are all unchecked
<valorie> VREF HIZ below that
<awilkins> Ok, check "IN" and change the VREF to 80
<valorie> done
<valorie> I think that's the jack for an external mic
<awilkins> Now open Sound recorder or something with a VU meter (  `pavumeter --record` ) and try it out
<valorie> let me get one
<valorie> or I guess I can use my headphones
<awilkins> Ah, what' the input for the Mic you are actually using
<awilkins> That one was probably not initialized if you weren't using it on purpose
<awilkins> Esp. if it has "input sense"
<valorie> I was trying to get the internal mic working
<awilkins> Probably another pin
<valorie> Press Detect
<valorie> Input
<valorie> VREF_HIZ
<valorie> VREF_50
<valorie> VREF_GRD
<valorie> VREF_80
<valorie> but it would be cool to get this one working too
<apw> internal mics are sometimes on the same plug as the external and connected when the jack is not
<awilkins> True, you might want to try that VU meter anyway
<valorie> did, and nothing
<valorie> just dead
<valorie> ok, another pin
<diwic> valorie, btw, regardless if you get somewhere or not, will you file a bug (unless you already did) for it, e g "using ubuntu-bug audio"?
<diwic> thanks!
<awilkins> Pins are just the start, alas, the whole chain of things has to work.... I found the thing that draws an SVG diagram of your codec useful
<valorie> Jack connection: Fixed
<valorie> Jack type:       Mic
<diwic> awilkins, codecgraph is also packaged in snd-hda-tools
<valorie> Jack location:   Ext
<valorie> Jack location2:  Top
<valorie> Jack connector:  Digital
<valorie> Jack color:      Black
<valorie> No presence
<valorie> is another
<awilkins> And I was already reasonably familiar with the control set on my codec because I had to monkey around with the selectors to get it to work with Maverick
<valorie> well, I will file one, but I wanted decent details
<valorie> "it doesn't work" isn't very helpful
<awilkins> valorie, That one is probably an audio out
<valorie> Stereo
<valorie> Output Amplifier
<valorie> you're right
<awilkins> You want ones that have the PIN cap "Input"
<diwic> valorie, that's great although "ubuntu-bug audio" will include some relevant files that can help us analyze the problem
<apw> diwic, do you use hda analyser ?
<diwic> apw, sometimes, yes
<apw> diwic, next time we are in the same place, you have to show us how to interterpret its output
<valorie> Jack connection: Jack
<valorie> Jack type:       HP Out
<valorie> Jack location:   Ext
<valorie> Jack location2:  Front
<valorie> Jack connector:  1/8
<awilkins> Headphones out
<valorie> Jack color:      Green
<valorie> is headphones
<valorie> Headphone Drive
<valorie> Output
<diwic> apw, maybe it's time for another audio triaging session 
<valorie> widget control has nothing selected
<diwic> apw, I saw JFo wanted more of that as well
<awilkins> valorie, Paste the contents of your /proc/asound/card0/codec#0 file to the pastebin
<apw> diwic, yeah i'd like to listen in on one again, there is more tooling now than i remember
<diwic> apw, we could do one hda driver specific 
<apw> yeah, as that is our primary pain point
<valorie> http://paste.ubuntu.com/612205
<awilkins> valorie, I think node 0x18 is your baby
<awilkins> valorie, Select node 0x18 and check the VREF value
<valorie> Jack connection: Fixed
<valorie> Jack type:       Mic
<valorie> Jack location:   Ext
<valorie> Jack location2:  Top
<valorie> Jack connector:  Digital
<valorie> Jack color:      Black
<valorie> No presence
<valorie> there is none
<valorie> in is checked
<valorie> but no vref value
<awilkins> Hmm, from this file, node 0x18 should be "Internal Mic Capture Volume"
<awilkins> But no VREF
<valorie> yes, that's the name
<awilkins> Bah
<valorie> but no vref
<diwic> awilkins, digital mics usually don't have VREF_80 and that stuff because the connection between the dmic and the codec is digital
<valorie> maybe it never DID work
<valorie> sec, gotta take the old dog outside
<awilkins> diwic, Thanks... I'm just an amateur
<diwic> awilkins, and we need more helpful amateurs :-) and help them become more qualified
<awilkins> Gah, I had that codec grapher somewhere
<valorie> blind, deaf, and when he's gotta go, he's gotta go
<apw> diwic, if you haven't met awilkins hes definatly a potential contributer on the debugging audio side
<diwic> nice! 
 * diwic shakes hands with awilkins 
 * awilkins shakes hands back
<apw> awilkins, meet diwic our sound expert
<diwic> awilkins, the codecgraph utility is packaged and ready in the snd-hda-tools package in ppa:diwic/ppa 
<awilkins> diwic, Yup, installed
<diwic> (or ppa:diwic/maverick for 10.10)
<diwic> awilkins, so what I would do in this case is to take the codec a ride through hda-emu and see if the automuting does what it should
<diwic> auto-switching between int and ext mic
<diwic> valorie, when you posted that codec file, was anything plugged into the mic?
<diwic> awilkins, potentially try a newer alsa-driver as well
<valorie> hmm
<valorie> I don't think so
<valorie> I plugged in to test
<awilkins> I think the relevant nodes are ...  nodes   0x18 (the mic pin)  0x1c (audio selector)  and 0x12  (audio input)
<valorie> and then just now, plugged in earphones to test
<valorie> earphones are really why I'm here
<valorie> as it is unknown whether or not the mic ever worked
<valorie> laptop isn't that old, but
<valorie> don't know
<diwic> awilkins, hmm, I /think/ it is 0x18 - 0x1d - 0x13 because that's stream 0, but better double-check in hda-emu
<valorie> so the headphones textdump is at http://paste.ubuntu.com/612209
<awilkins> diwic, What's the significance of dotty lines over solid ones - I was tending to follow solid ones when I was debugging my own issue
<diwic> awilkins, dotty lines are generally unconnected but could potentially be connected if one changes that in the driver or hda-emu
<diwic> awilkins, or in hda-analyzer I mean
<valorie> and here is the codec#0 with definitely nothing plugged in: http://paste.ubuntu.com/612210
<diwic> awilkins, ok so it is 0x18 - 0x1c - 0x12 actually
<diwic> valorie, you don't happen to have an ATI controller, do you? 
<valorie> yes
<diwic> valorie, you might be suffering from bug 741825 then 
<ubot2> Launchpad bug 741825 in alsa-driver "ATI controllers [1002:4383] and [1002:4383] (rev 40): Intermittent record and jack sense failure" [Undecided,Incomplete] https://launchpad.net/bugs/741825
<valorie> gah!
<diwic> valorie, and if so the recommended solution is https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules as we think this was finally fixed a few days ago 
<awilkins> If your first one was plugged and your second one was not, then I would concur
<valorie> 01:05.1 Audio device: ATI Technologies Inc RS780 Azalia controller
<awilkins> Because they are identical
<diwic> apw, we should just see some more testing of this fix and then make it into a Natty SRU
<diwic> apw, I think it needs two different commits to fix
<apw> diwic, big and ugly ?
<diwic> apw, no, but potentially affecting a lot of machines, that's my only hesitation...but in this case I think it's worth it
<valorie> ok, installing
<valorie> and for this, I will restart
<jussi> o/
<jussi> I just had a major crash of the whole system, ended up with this: http://wstaw.org/m/2011/05/24/2011-05-24_11-37-17_362_Oulu.jpg
<jussi> any help ?
<diwic> apw, i e affecting all ATI HDA machines
<jussi> is there anything else I can get now (after a restart) that would help diagnose this? 
<apw> jussi, hmmm another cpuidle_idle_call explosion
<apw> what kernel is that?
<jussi> jussi@squirrel:~$ uname -a
<jussi> Linux squirrel 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
<diwic> ok I'll be away for lunch for a while, see you later!
<jussi> apw: Im aroundish with this PC for the next ~4 hours. If there is anything else you need, please ask. Ill go file a bug in the meantime. 
<eagles0513875> jussi: did you have your whole system lock up on u and freeze nastily
<eagles0513875> when you maximize konsole or certain other apps?
<jussi> eagles0513875: no. 
<eagles0513875> ok just checking cuz that is a super  nasty bug which boils down to an nvidia driver issue
<jussi> eagles0513875: given I dont have nvidia...
<eagles0513875> ahh 
 * eagles0513875 retreats to the amarok channel
<jussi> bug 787442
<ubot2> Launchpad bug 787442 in linux "Complete machine crash (kernel panic?) " [Undecided,New] https://launchpad.net/bugs/787442
<jussi> apw: ^^
<eagles0513875> jussi: i was having those with atheros wifi card in my netbook
<valorie> here goes nothing, restarting.....
<eagles0513875> gd luck valorie
<apw> jussi, you had a photo, could you attach that pls
<jussi> apw: its attached - first attachment.
<apw> stupid launchpad, hiding the important one
<jussi> heh
<apw> jussi, i've updated the subject.  if this is reproducible you could try the -propsoed kernel which as a heap of stable updates (-9
<jussi> apw: I havent managed to reproduce :/
<apw> i think i've seen 3 reports of something ismilar, one was put in my hands at UDS, but nothing common about them
<eagles0513875> apw: there was my issue with kernel panicing and my atheros wifi card which is fixed in proposed
<jussi> apw: I had this bug earlier: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/775432 - I put it in someones hands at UDS. 
<ubot2> Launchpad bug 775432 in linux "rtl8169 kernel panic" [Undecided,Confirmed]
<valorie> thank you SO MUCH! 
<valorie> I now have earphones again
<valorie> if you give me that bug report, I'll comment on it if necessary
<apw> jussi, that one is definatly different
<jussi> apw: yeah. 
<jussi> apw: it was your hands (and Leann's) that I put it into iirc
<jussi> Anywya, If I manage to reproduce, Ill let you know. 
<apw> jussi, quite likely :)  i had a lot of machines put in my hands over the week its hard to keep anything striaght
<jussi> apw: :)
<smb> jj-afk, hggdh FYI: I am able to reproduce the maverick ec2 fail locally. The "close blk" is normal though. It seems to be a very early lockup though. As I see 100% cpu usage but no dmesg output at all.
<awilkins> valorie, bug 741825
<ubot2> Launchpad bug 741825 in alsa-driver "ATI controllers [1002:4383] and [1002:4383] (rev 40): Intermittent record and jack sense failure" [Undecided,Incomplete] https://launchpad.net/bugs/741825
<valorie> also, my mic seems to work now
<valorie> at least the volume meter is showing activity
<valorie> \o/
<valorie> and SKYPE WORKS TOO!
<valorie> y'all are miracle workers
<apw> valorie, one of the many advantages of open source ... one can fix it
<valorie> kub. packagers are working on some free alternatives
<valorie> I hope we come up with something as good
<valorie> or better
<eagles0513875> awilkins: could ur fix possibly fix my issue with my webcam mic if it fixed it for valorie
<awilkins> eagles0513875, An integrated webcam mic would be a USB driver problem
<eagles0513875> ok
<awilkins> eagles0513875, Mine didn't fix valories, she had a jack sensing issue, and my issue was a codec initialization issue
<eagles0513875> ahh ok
<eagles0513875> i guess ill have to take a look at the bios
<awilkins> valorie has been fixed by another patch though
<eagles0513875> ok 
<awilkins> I think if you can actually record sound from that mic it's not so much a kernel problem
<eagles0513875> ok
<eagles0513875> software as in skype issue 
<awilkins> eagles0513875, Don't know - you might consider trying a GNOME session (or Unity) to see if it works there
<awilkins> eagles0513875, I don't know enough about KDE / phonon / whatever to speculate
<eagles0513875> ok no worries
<diwic> what am I doing wrong if I try to boot from a live Natty USB stick and get the error "Unable to find a medium containing a live file system"?
<diwic> and dropped to a busybox shell
<diwic> ok; switched usb slot, that helped
<htorque> hello everyone! are there known boot problems with oneiric and intel hd graphics? my boot 'fails' 4 out of 5 times (i can ssh into the machine).
<htorque> i sometimes see the plymouth text theme (kms problem?), but most of the time it's just a black screen with a blinking cursor. not happening with nvidia on the same notebook.
<apw> htorque, nothing known, i use the kernel on my systems here and haven't seen that myself
<apw> but i am not using oneiric userspace with them
<htorque> apw, thanks. the only weird thing i noticed when ssh'd into the machine, was the short output of lsmod: http://paste.ubuntu.com/612274/
<apw> htorque, does lsmod complete ?
<htorque> i got a new prompt, so i guess yes (i didn't check the return value)
<apw> a prompt is enough for me
<apw> so i'd say we're only half booted
<htorque> apw, would you say that looks like a kernel issue? i would then try to bisect
<apw> very hard to say, i would try with the last natty kerenl on your userspace
<apw> and see if the problem is resolved, if so then kernel it is
<htorque> apw, thanks, will do.
<dmarkey> hmm.. is there a known issue where xen network/block modules arent automatically modprobe'd
<dmarkey> in 11.04
<apw> dmarkey, in the virtual kernel ?
<smb> dmarkey, Hm, not really aware of that. Seemed to have worked for me at least...
<smb> (virtual kernel)
<dmarkey> i'm using the pae kernel
<smb> dmarkey, as domU (just to be sure)
<dmarkey> Yes :)
<dmarkey> i'll install the virtual kerne
<htorque> apw: also happening with the natty kernel
<apw> htorque, and you didn't have this i assume on natty itself?  so that implies it is something else
<smb> dmarkey, I have not tried generic-pae but at least with the virtual I don't remember any problems when starting an instance
<apw> given you have almost nothing running/loaded, i am worried about upstart
<htorque> apw: no, natty was working fine
<htorque> apw: "init: udev-fallback-graphics main process (...) terminated with status 1" - could this be the cause?
<apw> yep, that could easily be the cuase
<apw> as things wait for that to complete before starting X
<htorque> i just wonder why this doesn't happen with nouveau
<dmarkey> smb: do you have a installer initrd with the -virtual kernel
<apw> htorque, well that one only does something if the drm driver doesn't load
<apw> so its possible its telling you that the drm driver didn't load
<apw> and that behaves different for each
<apw> now why that has stopped working as normal is another question
<apw> from your lsmod you also don't have much of anything else loaded, so it could be a udev issue
<smb> dmarkey, not really. I sort of cheat and start of the cloud images (ripping the cloud out) most of the time.
<dmarkey> i see. is I assu,e its udev thats dropping the ball here?
<dmarkey> assume*
<smb> dmarkey, those would be at http://uec-images.ubuntu.com/ (but probably won't help you). Hm, a sec
<htorque> apw: "udevd: error binding udev control socket" sounds serious - had to use a camera to capture it, not sure if i get something similar in the nouveau case (it's just scrolling away too fast)
<dmarkey> hmm.. how are these bootstrapped?
<smb> dmarkey, ah wait. At least for virtual those are built-in... I guess not for the other flavours. So you probably need to add them to /etc/modules
<dmarkey> but will that make it into the initrd?
<smb> dmarkey, Right, modules, for generic-pae and built-in for virtual. Let me check...
<smb> dmarkey, Maybe /etc/initramfs-tools/modules is better
<dmarkey> but the modules are in my initrd at the min.. the problem is they're not getting modprobed!
<smb> dmarkey, At least the comment in initramfs-tools/modules says that they should get loaded if listed there
<dmarkey> ah i see
<htorque> apw: it boots fine with natty's udev
<apw> htorque, sounds like the place to file a bug then
<apw> can you pasge the number here as well
<htorque> apw: yeah, thanks! will do.
 * ogasawara back in 20
<htorque> hm, that's similar to the messages i see: bug 712026 -> comment #14 by smoser
<ubot2> Launchpad bug 712026 in udev "cloud-init.conf never runs, instance not reachable via ssh" [High,Fix released] https://launchpad.net/bugs/712026
<apw> htorque, that is a very different bug, could you file a new one, and indicate in smosers one that there is a separate bug
<apw> htorque, is this a real machine or a VM for you
<htorque> apw: real machine
<htorque> apw: bug 787610 (sorry, took some time)
<ubot2> Launchpad bug 787610 in udev "System fails to boot with Intel HD graphics" [Undecided,New] https://launchpad.net/bugs/787610
<hggdh> smb: ping -- maverick ec2
<smb> hggdh, pong, yes broken
<JFo> heh
<JFo> quickest conversation ever
<hggdh> smb: will we regen the whole thing? In other words, should we keep on and test maverick on hardware?
<hggdh> JFo: but I insist ;-)
<JFo> heh, of course :)
<smb> hggdh, I'd probably go on while I try to find what broke it
<hggdh> smb: roj
<smb> hggdh, Maybe start with 32bit to see if it breaks real hw too
<hggdh> smb: heh. Nothing like beating on a piece of hot iron. Will do
<smb> hggdh, I saw the same hang with the current master-next so at least not fixed in there. 
<hggdh> things get more exciting, I see
<smb> hggdh, Now I am trying to bisect or make crash work for me...
<herton> smb, ogasawara: bjf told me about Finalise() vim for kernel changelog, where it comes from?
<smb> herton, IT some vim file magic
<herton> I was using dch on my test builds, but seems more practical to use this directly in vi
<ogasawara> herton: smb taught me that bit of magic
<smb> Though it needed enabling tings sometimes. If it works for you there is even more magic that came from apw to make it a two keystroke
<ogasawara> yah, I've got a vim shortcut for it
<smb> herton, can send you the relevant vimrc thing
<herton> smb: yes please do
<apw> yeah i use a couple of bindings
<apw> to those vim functions, which are only loaded when the file is called changelog
<smb> herton, file is on the way
<herton> received here, thanks, will try it
<herton> where you define Finalise(), is it from some plugin like package?
<herton> ok seems to come from /usr/share/vim/vimcurrent/ftplugin/debchangelog.vim, just wonder why it didn't find it
<smb> herton, As I wrote there is also the plugin enable switch. I remember this had to be turned on at some point
<smb> So enable filetype plugins and the file must be named changelog
<smb> otherwise it is not there
<herton> smb: it is what filetype plugin on is supposed to do right? will figure this out later, lunch here, bbl
<ppisati> don't we have the meeting in an hour? i think i didn't see brad email
<JFo> yep, we do
<apw> sconklin, bjf, FYI the lts-backport-natty is now up to date, and should be included in the matrix
<bjf> apw, thanks, we were talking about it just a little while ago
<apw> i talked to cjw and we don't need to do anything other than get it copied to -proposed 
<apw> no process is required.  so i've pulled it forward and uploaded it to ckt PPA, hopefully I did it right :)
<bjf> ppetraki, you are correct and i'd completely forgotten about it
<apw> the brnaches are all pushed into lucid repo as normal
<apw> branch and tag even
<bjf> apw, i'll bet you didn't add a tracking bug :-)
<JFo> we have a seeming conflict with some app dev board?
<JFo> bjf ^^
<ppetraki> bjf, what am I right about? (happens alot)
<JFo> at 5 in the -meeting room that is
<bjf> JFo, looking
<JFo> k
<JFo> bjf, I'm looking at http://www.ubuntu-news.org/calendars/fridge/
<JFo> just FYI
<apw> bjf, heh nope, though when i uploaded it i was building it to get it into universe for a MIR, which is not required, so i forgive me ... feel free to blow it up and replace it
<bjf> apw, we appreciate any and all help, np
<smb> bjf, sconklin Btw, I had been questioned about "when goes lucid from proposed to updates". As the calendar shows this week prep for next cycle I was not really able to answer. ;)
<apw> yeah been wondering of those 'yellow' things had been updated since the 2w to 3w transition
<sconklin> smb: it is out of our hands.
<bjf> smb, basically, qa is behind schedule so we're not sure
<bjf> ppetraki, about the meeting
<smb> Ah. Somehow I had the illusion for lucid it was done.
<JFo> ppetraki, he meant that for ppisati 
<JFo> :)
 * JFo directs traffic
<bjf> JFo, i see what you are talking about, any thoughts on who i talk to about it
<JFo> no idea
<ppetraki> I figured :)
<JFo> one sec...
<bjf> ppetraki, sorrry for the noise :-)
<ppetraki> np
<JFo> bjf, looks like allison
<JFo> as per https://wiki.ubuntu.com/AppReviewBoard/Agenda
<bjf> JFo, thanks, i'll ping her
<JFo> k
 * JFo is fully caffeinated today. imagine what I coulod accomplish on Jolt Cola ;)
<JFo> could*
<JFo> I still wouldn't be able to spell all of the time
<smb> JFo, Imagine all the trippple keypressses. :)
<JFo> heh
<JFo> then you could call me JittersFo
<smb> JFo, Or "Zip" (If you ever played Fallout 3 ;))
<JFo> heh, I do
<bjf> JFo, they are moving, thanks for the heads up
<JFo> bjf, my pleasure
<bjf> ppisati, am going to be looking for you for ARM status from now on, you are on the agenda
<JFo> be ready, we hate slow meetings ;-)
<bjf> ppisati, i can let it go this time, but be ready next time
<ppisati> bjf: ack
<apw> bjf, am i on the hook for anything today
<bjf> apw, NO! but i can find something if you like :-)
<bjf> apw, or if ogasawara would like me to
<apw> heh, that'll be just fine, i assume its at now +00:35
<JFo> smb, do I need an EC2 item vor my metrics in the meeting?
<JFo> for*
<bjf> ##
<bjf> ## Kernel team meeting in 34 minutes
<bjf> ##
<smb> JFo, Hm do we do special metrics for any arm stuff?
<JFo> I did have items for them in case they were needed
<bjf> smb, you are on the hook for one agenda item
<JFo> I don't put them unless you guys tell me to
<smb> JFo, Yeah, I am not sure (maybe yet) I need one... I'll come and whine whenever I find out I do
<JFo> sounds good
<JFo> I'll leave it off for now
<smb> bjf, Guess I should look at it then...
<bjf> jfo, ogasawara, sconklin smb all have agenda items, just a heads-up
<smb> ta
<JFo> I'm ready
<apw> sconklin, did i see you applied both vesafb patches?  i think i was expecting only the first to apply to older releases
<sconklin> apw: well, I've deleted the email now, but I thought that the 0/0 listed all the series. Probably my mistake
<apw> I am proposing the first patch for Oneiric, Natty, Maverick, and Lucid
<apw> as a clear bug fix.  The second sounds like something we could apply in
<apw> Oneiric only and see what falls out.
<sconklin> They all applied. Whether that's correct or not is a reasonable question
<sconklin> I'll redo it after the meeting
<apw> sconklin, ack, the risk for the older releases is too high imo
<apw> for the small gain its likely to give
<sconklin> apw: ack, I trust that judgement
<sconklin> at least it's just a one patch reset unless something else has been pushed ;-)
<dmarkey> Anyway, i'm going to file a ticket for this xen-blkfront not being modprobe'd
<sconklin> apw: all fixed, thanks for letting me know
<JFo> wow, my typing skills fail
 * ppisati -> gym
<jjohansen> ogasawara: agree with doing config review at the sprint, I don't think there are any critically big changes to come out of it
<ogasawara> jjohansen: cool, I'll mark your work item as done then :)
<jjohansen> hehe :)
<ogasawara> jjohansen: and add an item to our agenda for the rally
<jjohansen> thanks
<JFo> <-need food, back soon
<jjohansen> ogasawara, apw, rtg: actually there was one config that I thought worth discussing now.  CONFIG_HZ
<jjohansen> for our i386 and ppc kernels it is 250, but for our amd64 kernels it is 100.  I think desktop should be 250
<apw> jjohansen, ok whats your reasoning .... (i tend to agree but)
<ogasawara> jjohansen: hrm, I thought bjf had sent a patch for that.
<jjohansen> apw: well for desktop we would like a better latency, 250 is a nice compromise between 100 and 1000
<bjf> ogasawara, no, i bumped the number of cpus
<ogasawara> ah, I stand corrected
<jjohansen> it also what we settled on for the i386 desktop
<apw> jjohansen, i tend to agree its odd they are not consistant
<jjohansen> apw: I don't have any figures, I could go and generate some, but that is one difference that really stood out
<apw> i think we moved cause NO_HZ was supposed to make the number meaningless anyhow
<jjohansen> apw: no NO_HZ is only for tickless sleep
<jjohansen> apw: hrm, no I stand corrected, from the current Kconfig
<jjohansen>          This option enables a tickless system: timer interrupts will
<jjohansen>           only trigger on an as-needed basis both when the system is
<jjohansen>           busy and when the system is idle.
<jjohansen> so it for busy as well, now I don't remember that change happening
<apw> which should mean a higer HZ is cheaper, but cking's number says not ... hrm
<apw> i am inclined to agree that without numbers that they should be consistant, 250 desktop, 100 server
<apw> and work from there
<jjohansen> apw: I think we should add a work item to generate some numbers and review at the sprint
<apw> jjohansen, ack, you got time to do the work, or should i finger cking as he is off :)
<JFo> heh
<jjohansen> apw: since I brought it up, I'll take it as part of my prep for the config review
<JFo> also, it would be awesome if you guys could spare me some skills training at platform
<JFo> I'm trying to narrow some stuff we could work on in a few blocks
<JFo> will send e-mail once I have more written down
<JFo> going to see about getting some of graphics/sound/hardware enablement time as well
<bjf> ogasawara, should i pull the config review from the meeting agenda until post Rally ?
<ogasawara> bjf: sure
<apw> jjohansen, if you have time thats great else just assign it to [canonical-kernel-team] and it'll stay on my radar
<jjohansen> apw: lets assign it to me for now and if I don't get to it with in the next week or two we will reevaluate
<apw> jjohansen, works for me
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - May-31 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * apw wanders off to get some dinner ... laters
<JFo> ogasawara, are you aware of a change like the one described in bug 787671 ?
<ubot2> Launchpad bug 787671 in linux "Starting with 2.6.39, EBS volumes start at /dev/xvde" [Undecided,New] https://launchpad.net/bugs/787671
<JFo> seems like something that should be easy to confirm if I had the requisite volumes :)
<JFo> and where would I look to determine if there was a change? obviously git log would help, but anything  more than that?
<manjo> how do I determine which upstream tree I cloned my tree from ? 
<manjo> thanks found it 
<JFo> what was it manjo 
<JFo> ?
<manjo> .git/config has the info 
<JFo> cool, thanks
 * JFo grabs oneiric branch while he is thinking about it
<ogasawara> JFo: I'm not aware of changes, maybe smb or jjohansen could confirm?
<jjohansen> JFo: I haven't follow the ebs volume changes to closely this last kernel, but there were xen patches that went into to 2.6.39, I have a look
<JFo> yeah, I initially thought of smb, but after hours for him. :)
<JFo> k, thanks jjohansen 
<JFo> my oneiric branch fetch is taking longer than I thought
<jjohansen> JFo: so there is a patch that affects the xen-blkfront driver device id numbering, I haven't looked at it to much but I suspect it is the cause
<bjf> kees, is there a way (other than uploading a package) to see if my upload rights have been granted in LP?
<JFo> jjohansen, ok, thanks
<kees> bjf: that's an excellent question. I don't know where that information is held, actually. I'll see if cjwatson knows.
<kees> bjf: looks like you still don't have it. who else on the team has those rights, just so I can compare?
<bjf> ogasawara, 
<bjf> kees, ogasawara would have them
<kees> all these irc nick vs LP nicks ;)
<kees> yeah, I see her perms, so it looks like whoever needs to do that hasn't done it.
<bjf> kees, thanks for checking
<kees> https://launchpad.net/~ubuntu-kernel-uploaders/+members  is it just this list?
<kees> bjf: who from the DMB is supposed to update that?
<bjf> kees, that looks like the right list, i don't know who is supposed to update it
<kees> (for reference, lp:~ubuntu-archive/ubuntu-archive-tools/trunk/ has edit_acl.py which I'm using as "./edit_acl.py query -p brad-figg" and "./edit_acl.py query -p leannogasawara")
<kees> bjf: maco says she has added you now.
<kees> and the edit_acl.py output seems to agree
<bjf> kees, i just popped onto the list
<bjf> kees, you want to remove me from ubuntu-drivers ?
<kees> bjf: sure, let's try that again....
<kees> bjf: okay, I've deactivated you there. can you still do bug task nominations?
<bjf> kees, I'll give it a twirl and get back to you if i have any problems, thanks for the help
<kees> bjf: okay, cool. thanks for testing! :)
<avinashhm> Hi friends , i am trying to compile ubuntu kernel .. got the sources via 'apt-get source linux-image-$(uname -r)' .. i don't want to use fakeroot to compile ... want to use general make with some configs .. was looking on info to build which config .. any pointers will help 
<bjf> avinashhm, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel documents how we suggest you do it
<bjf> avinashhm, if you want to find another way, google is your friend :-)
<hggdh> smb: maverick i386 is OK on KVM
<avinashhm> bjf, sure ... ;-) .. i ll go over the link .. thanks buddy ..
<JFo> jjohansen, was the one you were thinking it was the "xen-blkfront: handle Xen major numbers other than XENVBD" one?
<avinashhm> Hi bjf , just curious ... i need only info abt the config used ... is it 'i386_defconfig' ? which is used for regular ubuntu ...(arch/x86/configs/i386_defconfig ?
<manjo> ogasawara, who is looking at Ubuntu delta this cycle ? 
<ogasawara> manjo: it's been farmed to different individuals
<ogasawara> manjo: anything in particular you're interested in?
<bjf> avinashhm, cp /boot/config-`uname -r` /usr/src/linux/.config
<manjo> ogasawara, omnibook module needs a refresh its been oopsing since natty
<ogasawara> manjo: we've disabled it
<manjo> ogasawara, ok.. looks like the project is dead ... 
<ogasawara> manjo: discussed it at UDS and decided to turn it off and see who screams
<manjo> ogasawara, Satellite and Tecra and some HP users 
<manjo> ie tohsiba & HP 
<manjo> toshiba rather 
<mjg59> It's really not the right interface for any modern hardware
<manjo> sure its a crappy module 
<manjo> ogasawara, we introduced it in karmic coz some people requested it ... good to know we got rid of it 
<jjohansen> JFo: yep
<JFo> cool, found it here https://patchwork.kernel.org/patch/567891/
<JFo> no idea what all is going on, but I understand a large part of it
<JFo> going to look at it a bit tomorrow, my brain is almost fried for today
<avinashhm> bjf, thanks very much
<bjf> avinashhm, you may not want to actually copy it where i indicated, but it shows you where to find it
<avinashhm> bjf, correct ... i downloaded src ~/git/ .. i ll copy to this root ..
<kees> hmpf, how do I fix the "Author" when working on git patches?
<sforshee> kees, git commit --author="..."
<ogasawara> kees: git commit --author ?
<kees> what if I'm working on a rebase?
<ogasawara> kees: hrm, could you use rebase -i, mark the commit as an 'edit', and then use git commit --author ?
<kees> ah! good, yes
<kees> ogasawara: yes! it worked. :) git commit --amend --author ...; git rebase --continue sweet
<ogasawara> kees: nice
<sconklin> http://lwn.net/Articles/444336/ Interesting argument against prefetch
 * JFo takes notes
<JFo> stepping away for a bit. I need to run an errand
 * jjohansen steps away for some lunch
 * herton --> eod
<jjohansen> hallyn: have you seen https://lkml.org/lkml/2011/5/24/502
<hallyn> no
<hallyn> jjohansen: have you pursued it?
<jjohansen> hallyn: just to the apparmor, first poke level, /me is planning to get back to it later tonight
<jjohansen> I want to finish up with some other stuff first
<hallyn> jjohansen: ok, thanks
<hallyn> i dunno, but 'cred' is NULL at cap_capable() too.  THis looks like memory corruption
<jjohansen> hallyn: yeah I wasn't sure what was going on there, I want to try replicating myself
<hallyn> ditto
<hallyn> bbl
<hallyn> thanks for the tip
#ubuntu-kernel 2011-05-25
<doctormo> What should I do to fix a known kernel issue to do with a net driver? information follows...
<doctormo> I have 10 client machines, each with the same e1000 network card
<doctormo> The e1000 driver has a bug which doesn't allow the machine to be shutdown once it's been booted using wakeonlan.
<doctormo> See bug:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/691479
<ubot2> Launchpad bug 691479 in linux "HP Computer won't shutdown after WOL" [Undecided,Confirmed]
<doctormo> The problem I have is how to apply the linked patch to client machines without manually going to each machine and breaking their upgrade path.
<bjf> doctormo, hold one
<doctormo> I thought about using dkms, but trying to fit e1000 into a dkms package has been a challenge that I can't beat yet. bjf, yes, holding...
<bjf> doctormo, ok, looking at that "patch", it's not something we'd take because it's obviously just a hack
<doctormo> bjf: Yes, I can understand that. But there is no known fix otherwise.
<bjf> doctormo, do you know if this has been fixed upstream
<doctormo> OK, so I've tested with 2.6.38 so far, I can't test beyond that yet.
<bjf> doctormo, and .38 has the same issue?
<doctormo> yes
<bjf> doctormo, there have been changes to that driver since .38 so it's possible it got addressed, however I don't see anything that really jumps out as a fix for that issue
<bjf> doctormo, have you opened an upstream bug on it or sent email to the maintainer?
<doctormo> I don't know how to do that.
<bjf> doctormo, so looking at the email thread on e1000-devel, it looks like the upstream tried to help the bug reporter but the bug reporter wasn't able to test much
<bjf> doctormo, also, they may not have been able to reproduce the issue in-house
<bjf> doctormo, i'd suggest either adding to that thread with your own report and offer to help test, or try a new email to that mailing list
<bjf> doctormo, other than that, yes, a DKMS driver is a lot of work
<bjf> doctormo, also the upstream suggested making sure you are running the latest BIOS version
<doctormo> bjf: Yes I looked at the latest bios, they say nothing about fixing the wake on lan.
<bjf> doctormo, but did you test the latest BIOS, they may not have documented that fix
<doctormo> bjf: I will test it and bare a grudge if it works :-)
<bjf> doctormo, heh, i'd really suggest an email to the development mailing list
<doctormo> thanks for your help bjf
<bjf> doctormo, np, didn't really do anything
<doctormo> bjf: Your time is worth at least my thanks.
<bjf> doctormo, your welcome and don't be afraid to come back
<bjf> doctormo, if you can find a real fix, let us know and we can spin a test kernel for you pretty quickly
<doctormo> bjf: Heh, an entire kernel.
<doctormo> I had an idea that we should somehow force kernel developers to have dkms packages for every single non-core driver ;-)
<doctormo> Email sent to mailing list.
<azop> doctormo: so a kernel upgrade would take ~2 hours to compile all of the DKMS packages?
<hallyn> jjohansen: i can't get a kernel with his config to boot in qemu.  it just scrolls constantly looking like it's finding devices but never finishes booting
<hallyn> jjohansen: and a stock natty image doesn't reproduce the claimed bug
<hallyn> jjohansen: gah, i can't reproduce with my userns tree, or with natty (which doesn't have my patchset), but can with our daily ppa
<jjohansen> hallyn_afk: hrmm, okay.  I'll take a peek at it in a couple hours
 * apw yawns
<cooloney> apw: morning man
<apw> cooloney, morning, how you ? 
<cooloney> apw: very good, working on my Irish visa.
<apw> heh, so very many visas required, and i bet they all last 6 months so they are out of date by next time
 * smb is glad he has not to do so every journey
<cooloney> i need apply visa every time when i'm travelling to EU
<cooloney> next time, i will try to apply 1 year multi entry schegen visa 
<cooloney> but Ireland is not Schegan states
<apw> bah what a pain
<smb> cking, morning old man
<cking> smb, morning, I'm not *that* old ;-)
<smb> cking, At least you should now be wise and know the answer. :)
<cking> heh
<smb> apw, cking Hows the view up there? Seems there is a volcano remembrance event going on. :-P
<apw> smb, sky is clear and blue where i am
<htorque> apw: morning! bug 787610 - i'm pretty sure i've found the commit that's responsible for the hangs. should i report this upstream?
<ubot2> Launchpad bug 787610 in udev "System fails to boot with Intel HD graphics" [Undecided,New] https://launchpad.net/bugs/787610
<smb> Not that we would have seen much last time (even more being away)
<jussi> Good morning alll
<apw> htorque, is it reported in out bug too ?
<jussi> Just had a total freeze of the PC, even reisub didnt help. Anyone feel like helping me diagnose this ?
<apw> htorque, and which commit it is?  kernel or udev ?
<htorque> apw: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=ff2c503df091e6e4e9ab48cdb6df6ec8b7b525d0
<jussi> apw: is it possible the bug I reported yesterday can manifest itself without dropping to the console as it did then? 
<apw> htorque, oh man, they have changed socket type .... and rewritten the code completely ... bah
<apw> and from the error i guess its when we restart udev across the chroot into / from the initramfs that we hit adrr in use
<cking> smb, all clear here, blue sky, no dust
<smb> cking, Yeah, did not really expect something to see. There have been two airports affected in the north last time I looked.
<smb> cking, Three by now it seems
<mnemoc> hi, for this sort of crash http://dpaste.com/546289/ resuming an pure-efi laptop (thinkpad x120e) after suspend, what sort of bug report should I do? (natty/64)
<apw> htorque, so have you backed that one out to confirm?
<mnemoc> usually it just locks up, this time magically resurented after some minutes with the panel black
<apw> mnemoc, that tells you your resume was slow and nothing more, the bits before that in the log are the key information
<mnemoc> 1m
<apw> mnemoc, do you have the preceeding lines?
<mnemoc> yes, let me post it
<mnemoc> apw: http://dpaste.com/546291/
<htorque> apw: i rebooted the revision before that commit ten times without a problem where the offending commit failed 6/10 times
<apw>  htorque ok thanks, just checking something, as i have a theory
<mnemoc> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/769812 is related to freezes with the wifi driver, but comments imply they are also experiencing freezes on resume
<ubot2> Launchpad bug 769812 in linux "X120e crashes randomly (wireless?)" [Undecided,Confirmed]
<apw> mnemoc, from that log i'd guess its one or more usb devices.  i think a camera and maybe some kind of storage got borked.  possibly the controller got lost in the d/r
<apw> s/r
<apw> mnemoc, anyhow file a bug against linux (ubuntu-bug linux) and attach that entire log
<mnemoc> apw: thanks a lot, i will now
<jussi> Nobody interested to help me get this reported :/
<apw> htorque, ok i think i see a possible bug ... not sure why the old version is not also susceptable though
<mnemoc> apw: done, thanks :) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/787980
<ubot2> Launchpad bug 787980 in linux "thinkpad x120e freezing on resume" [Undecided,New]
<apw> mnemoc, did you say this is an efi machine ?
<mnemoc> apw: yes, it's in pure-efi mode
<mnemoc> apw: should I attach the output of something else?
<apw> mnemoc, nothing i know of, but i am no efi expert
<apw> mnemoc, is this a sandy bridge machine ?
<mnemoc> apw: amd e-350 "fusion"
<apw> which graphics drivers are you using mnemoc ?
<mnemoc> currently fglrx, not sure if I was getting freezes with the radeon
<apw> well that is a good test to know the answer to
<mnemoc> apw: ok, i'll uninstall fglrx
<apw> binary drivers don't have a good record with suspend/resume
<mnemoc> lovely, blank screen.... but I have ssh in
<apw> mnemoc, after s/r ?n
<mnemoc> no, reboot after uninstalling fglrx, same after a second reboot
<apw> mnemoc, try nomodeset on the kernel command line
<apw> damn amd and their lack of specs
<apw> (or drivers that work)
<mnemoc> but 12s since `sudo reboot` to ssh is nice :)
<apw> heh thats something i guess, make a nice little server perhaps
<mnemoc> mnemoc: nomodeset worked
<apw> mnemoc, ok could you file a second bug against xserver-xorg-video-radeon saying you need nomodeset as well
<apw> and get me the number of that one too
<apw> mnemoc, then pls do test s/r in this combination and see if that works, and report on that in the first bug
<mnemoc> apw: 2m an still hasn't returned from s/r :(
<mnemoc> and*
<apw> so likely the issue is not graphics related
<apw> as you changed the drivers and its still there
 * mnemoc nods
<apw> (binary drivers related should i say)
<apw> did this ever work for you or is natty the first install on it
<mnemoc> apw: yes, was natty is the first install
<mnemoc> btw, I do get beeping when connecting/disconnecting the power, so "something" is alive
<apw> thats likely the EC which is outside the OS
<mnemoc> ok
 * mnemoc powercycling
<mnemoc> apw: btw, what's the right place to `dmesg -n8` on init?
<mnemoc> (for a netconsole)
<apw> mnemoc, hmn  no idea
<apw> mnemoc, the next thing to try probabally is taking the latest maverick kernel and install that and see how that behaves
<mnemoc> from the last boot I only received one line on the netconsole :-/ "[drm:drm_mode_getfb] *ERROR* invalid framebuffer id"  ... pretty useless for debugging
<apw> mnemoc, oh and of course you can try the latest oneiric kernel, if we can find one which works we have some hope of fixing one or other of these bugs
<mnemoc> apw: do you suggest to go forward or backward first?
<mnemoc> apw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/788021
<ubot2> Launchpad bug 788021 in xserver-xorg-video-ati "Radeon HD 6310 (amd e-350 zacate) needs nomodeset" [Undecided,New]
<apw> cking, your fwts blueprint has no work-items yet ...
<apw> cking, and tommorrow is feature definition freeze, when we're meant to have work defined :)
<apw> actually cking are these ACTIONS meant to be work items ?
<cking> apw, thanks for the prod, I'm onto it in a mo
<soren> https://lists.ubuntu.com/archives/ubuntu-server/2011-May/005676.html  <--- This looks like something for you guys
<apw> cking, if those actions are meant to be work-items i can convert them
<cking> apw, I need to work through it and break it up into some sane steps
<apw> soren, as far as i know his cpu won't be able to run userspace either
 * apw lets smb reply as he is likely subscribed to that list
<soren> apw, smb: I can let it through the moderation queue if you're not subscribed.
<mnemoc> hi, i've totally failed to find what's the "right way" (tm) of installing oneric's kernel in natty? is there is ppa I've failed to find? or I must use git and build manually?
<mnemoc> or just take the .deb from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-oneiric/ ?
<apw> mnemoc, use the official build from the launchpad librarian:https://www.launchpad.net/ubuntu/+source/linux
<mnemoc> apw: but how? :( fetching and installing all .deb manually?
<apw> mnemoc,yes there is no automated way
<mnemoc> ok
<smb> apw, The same mail was cross posted to the kernel-team mailing list. :P Ok, I have not replied (neither did anyone else). But I probably would not have remembered that userspace might be compiled differently too. Though it may be a processor feature which is not relevant for userspace.
<mnemoc> apw: what does the '-di' mean in https://launchpad.net/ubuntu/+archive/primary/+files/kernel-image-2.6.39-3-generic-di_2.6.39-3.9_amd64.udeb
<mnemoc> ?
<mnemoc> .oO(this should be on a ppa :'( )o
<apw> mnemoc, thats the wrong one, thats the unstaller, ignore the .udeb forms
<mnemoc> ok
<apw> mnemoc, no cause then everyone would install it and get themselves into an unsupported combination
<apw> mnemoc, it needs to be sufficiently hard to reduce that
<mnemoc> so only linux-headers-2.6.39-3-generic_2.6.39-3.9_amd64.deb and linux-image-2.6.39-3-generic_2.6.39-3.9_amd64.deb ? or linux-libc-dev and linux-tools also?
<apw> you want the first two and the _all headers package as well
<smb> soren, apw, Ok, I replied (likely not making new friends there)
<mnemoc> apw: http://dpaste.com/546354/ might be useful for future
<soren> smb: I don't see your reply (neither in my inbox, in the ml archive nor in the moderation queue).
<smb> soren, I did reply to the mail (which looked identical) that was posted to the kernel-team ml (sorry, forgot to add a crosspost)
 * smb forwards it to server
<soren> smb: Oh, I didn't spot the original mail on the kernel ml, so didn't even realise he had crossposted. Weird.
<soren> Ah, there it is.
<smb> soren, Not crossposted in that sense. Just sent it twice I guess
<smb> soren, Shall I still push the reply to ubuntu-server?
<soren> smb: That would probably be a good idea, yeah. He's probably not alone with this question.
<soren> smb: Thanks!
<smb> soren, Ok, will do... and maybe I should subscribe to server... *sigh* more mail
<soren> smb: meh.
<soren> smb: I can just bug you if there's kernel stuff on there.
<soren> It's rather low traffic, though.
<smb> soren, Yeah, I should not complain. There is always the del-button
<soren> Oh, I can totally relate to e-mail overload.
<soren> Accepted through the moderation queue and added you as a nomail subscriber. This means you can post without getting caught in the queue.
<smb> soren, Bah, thats the reason I got that strange mail when I actually subscribed. :-P I was starting to question my sanity... Oh well.
<soren> smb: Heh, sorry :)
<smb> soren, Maybe you could change it to a withmail subscription. I still can filter it into a folder that I can ignore...
<smb> Sorry for the mind-changes. It is getting warm and I like to complain...
<soren> smb: Sounds only fair enough since I caused the confusion. Hang on.
<soren> smb: Done. Thanks for following up!
<smb> soren, Thanks as well. Hope it is helpful to some degree. Not good news probably...
<hallyn_afk> jjohansen: good morning.  did you get any time to look into that capable() null deref?
<hallyn_afk> jjohansen: my complete guess is that the recent rcu_free() changes exposed something,
<hallyn_afk> jjohansen: but i'll have to do some bisecting, unless you've started that?
<ogasawara> cking: was going to pull in your suspend debugging patch to oneiric but didn't know if you were planning on sending a v2 of it taking into smb's and jj's comments about hardcoding some numbers?  I'm indifferent either way so am happy to apply it as is or wait, just let me know.
<cking> let me reply on the list, but the hardcoded numbers are in the original code (it's kinda lame), so I just extended it, hence it's just as equally bad
<ogasawara> cking: ack
<cking> put it this way, I'm not planning on sending a v2 of the patch
 * ogasawara goes ahead and applies it then
<jjohansen> hallyn: no, I didn't end up getting that far before bed
<hallyn> ok
<hallyn> i guess i'll try bisecting
<schizoschaf> hi. i have issues with my newly installed 64bit natty system freezing after short usage. might this be a kernel issue? is there anything known for 2.6.38?
<cking> thanks ogasawara
<tgardner> apw, so the Natty MIR into Lucid went OK? I see you've marked it done.
<apw> tgardner, yes talked it through with master watson and he decided there was no need for do any hoop jumping, and we should just upload it, so i've uploaded it to ckt PPA and stable has ownership of it now
<apw> it'll go through the normal testing into -proposed etc
<tgardner> apw, I saw build failures. those are resolved ?
<apw> tgardner, those are normal, as in we only build for amd64/i386
<apw> we likely should be cleaning more of the control file to prevent builds going there
<tgardner> right
<apw> i'll add that to my list to check into
<tgardner> ogasawara, can you read bug #787740 ? I get the 'Lost something?' page.
<ogasawara> tgardner: same here
<tgardner> ogasawara, ok, then I'm not insane.
<ogasawara> tgardner: well, that's debatable :)
<tgardner> hmm, well the amount of email that I've received in 3 days off _is_ driving me insane.
 * vanhoof emails tgardner 
 * ogasawara back in 20
<vanhoof> ogasawara: sorry I can't read well ;)
<ogasawara> vanhoof: heh, no worries
<hallyn> jjohansen: think the bug's been found.  thanks again for the pointer
<apw> sconklin, bjf, wondering if this is any use: http://people.canonical.com/~apw/cve/pkg/combo.html
<sconklin> It might interest kees ^^
<jjohansen> hallyn: good to hear, sorry I didn't get to it last night but I didn't manage to get my three year old to sleep until after midnight
<hallyn> jjohansen: i should've looked at the top of his exploiter program from the start, it was obvious once i did
<hallyn> jjohansen: and please don't apologize for not getting to it at 9pm :)
<jjohansen> hallyn: oh, /me goes to take a look
<hallyn> i was just freaking out since i'm about to disappear for awhile, so taht would look bad if i didn't figure it out first :)
<jjohansen> hallyn: /me just looked at the top of his exploiter, wtf :)
 * jjohansen should have caught that earlier
<hallyn> :)
<smb> sconklin, Darn, I just realized that we got the same patch that broke ec2 on maverick in the current lucid proposed as well. I just won't break ec2 because thats different xen code. But we are delayed there anyway you said. So I may have time to create a test install to be sure.
<hallyn> smb: (just when you get a chance)  does bug  785668 ring any bells for you?
<ubot2> Launchpad bug 785668 in linux "bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM" [Medium,Confirmed] https://launchpad.net/bugs/785668
<sconklin> smb: delayed for -proposed? Check with QA, and should I send a message to everyone to NOT publish it for ec2?
<sconklin> and what about Maverick, is it still in -proposed and not published? Do we need to hold publishing?
<sconklin> (looking)
<smb> hallyn, Not really
<hallyn> smb: ok, thanks
<smb> sconklin, maverick proposed would need one patch reverted
<hallyn> smb: for all i know it's by design
<hallyn> (after all, if you're doing round robin over each ethX, maybe you want separate macs?  nah, that doesn't make sense)
<sconklin> smb: ec2 only, correct (I'm remembering now)
<smb> hallyn, I have not read into the bug, but from what I remember about the bonding it will spoof the mac of one of the real nics
<sconklin> well, ec2 branch only for Lucid, Maverick is all in one
<smb> sconklin, for maverick yes and only affecting that but as we use the virtual flavor there needs the kernel to be respun (master)
<bjf> sconklin, there is nothing in the natty tracker from either cert. or QA
<bjf> sconklin, same with maverick
<hallyn> smb: right, it only starts to fail when you put the bond0 into a bridge with another device
<smb> sconklin, For lucid it would be slightly different as for ec2 we use a different kernel and code. But people tend to run the generic kernels under xen too. I have not verified this yet (need to create an installation first)
<bjf> sconklin, for lucid we have cert testing done but nothing from qa
<sconklin> bjf: right, but I want to avoid having QA test it and perhaps miss this problem, and then having it published
<smb> bjf, I doubt a bit that we cover that exact scenario. Usually we say xen and mean ec2...
<smb> hallyn, I would need to draw myself some picture and actually spend a bit of time reading the bug. Just meant it does not ring a bell cause I it did not ring. :)
<hallyn> smb: yup, that's all i was asking for right now, thanks :)
<hallyn> smb: well, i shoudl ask - do you prefer tha ti go to the bonding m-l, or that i wait for someone on your team to look at it?
<smb> hallyn, team? do I have one? ;-P I guess only tgardner may have played with bonding (network!) before...
<hallyn> tgardner: are you a NIC bonding pro?
<smb> I guess he got enough stale email to trouble him
<sconklin> smb: I'm not sure I understand this completely. Is this correct? - We have a patch that was intended to fix a bug but it introduced new problems. We must revert that patch but we have no fix for the original bug yet.
<smb> sconklin, Nope... /me takes breath
<smb> That patch came through upstream stable. At least for later kernels (natty) it seems ok and I think there was a problem it fixes.
<bjf> smb, when did you discover this issue and why wasn't the tracking bugs updated to reflect an issue?
<smb> But it applied to earlier kernels too. And at least for .35 there seems to be badness. I just saw it could be in .32 as well. But I have not tested whether it really causes issues there
<smb> bjf, hggdh brought it up Mon and I have been posting to the sru list. I probably should have also added to the tracking bug but forgot
<bjf> smb, well, hggdh should have put something in the tracking bug, he found the issue
<bjf> smb, not that i'm trying to point a finger, but these issues need to get raised right away
 * sconklin is sending email now
<tgardner> smb, hallyn: no bonding experience here. Steve Hemminger is the upstream expert IIRC
<smb> tgardner, thanks
<smb> sconklin, bjf Generally the question would also be whether we want to add the combination server installation (at least) running under xen as opposed to run the ec2 kernel on ec2 to the verification matrix
<sconklin> smb: everything we support should be in the verification matrix. That's my position.
<smb> sconklin, Yeah, not sure we support it really...
<bjf> smb, i agree with sconklin
<smb> Its just what people do
<smb> sconklin, bjf But let me do the lucid server install for xen and test first. Maybe its nothing and all the panic was without reason. Just wanted to warn you about it
<apw> move to /public_html/cve/pkg/
<sconklin> smb: so status is that we know Maverick is bad, but we're not sure about Lucid?
<apw> moved to http://people.canonical.com/~apw/cve/pkg/ALL-linux.html
<smb> sconklin, right
<hggdh> bjf: when I contacted the channel Monday I asked about posting it, and was suggested to wait
<bjf> hggdh, thanks, really wasn't trying to find someone to blame, we just need early notification so folks get a heads-up that something might be broken
<bjf> hggdh, i'm thinking that if issues are seen, they should go into the tracking bugs right away
<hggdh> bjf: I agree. I would rather add a link to a bug in the results matrix (as opposed to "fail to boot")
<bjf> hggdh, we can always add a follow on comment that "it was nothing"
<hggdh> yes
<hggdh> bjf: from now on it will be there, with a link in the results matrix
<sconklin> smb: do we know completely what it required for Maverick? Is it simply to revert the patch or is there another fix that will be required? I'm trying to understand how long this will take.
<apw> sconklin, bjf, you have built lts-backports-foo in ckt PPA bebfore, did it error on none x86 for you on those do you remember?
<bjf> apw, not that i recall
<sconklin> apw: I do not know
<smb> sconklin, bjf hggdh I think I misunderstood the posting part back then.
<sconklin> dont recall any failure
<apw> ok, then its new in the natty one, leave those failures with me and i'll try and get rid of em
<hggdh> smb: not really -- *I* should have posted it, after all I was the one running the test
<smb> sconklin, Reverting the patch enables boot again. I am currently discussing with the author about it. So to fix it there is maybe a different approach
<bjf> smb, was suggesting that as soon as any issue is found with a kernel, a comment should be added to the tracking bug
<apw> is not the appropriate thing to do just to revert the broken commit and release ?
<hggdh> bjf: in cases like this, would it be better if a new bug is entered?
<bjf> smb, if necessary, a follow up can always be added that says something like "was just a test issue" or some such
<smb> bjf, Totally agree. I meant when being asked (or when I saw it) I did not connect posting something to add a comment to the tracking bug 
<bjf> hggdh, probably, however, since the tracking bug is used for a particular kernel release, that needs to be updated as well
<hggdh> bjf: what I propose: (1) new bug; (2) comment in the tracking bug, linking to the new bug; (3) link in the results matrix
<bjf> hggdh, that matches my thinking as well
<hggdh> bjf: perfect
<tgardner> apw, I think the Maverick LTS build doesn't fail because I stripped out all non x86 arch support.
<apw> tgardner, odd as i made the support from that support, but i must have missed something ...
<apw> easy enough to compare though so ... i'll do that
<tgardner> apw, I was just looking at the abi directory. only i386 and amd64 are present
<hggdh> bjf: this new bug, should we pre-assign it to the kernel team? Also have it as born high-importance?
<bjf> hggdh, sure, let smb know and he'll probably assign it to himself
<apw> tgardner, from what i can see on the branch it seems to be correct, i think i borked making the source package
<smb> hggdh, Or assign it directly to me 
<JFo> smb, I am almost done with your server bugs report
<JFo> just FYI
<JFo> testing/tweaking now
<smb> JFo, Sounds awesome. Though I am a bit scared to find out how much I did not see...
<JFo> heh
<apw> bjf, if i wanted to re-upload this lts-backport-natty, i'd want to add the tracking bug, whats the proceedure for that
<hggdh> smb: ok, you are the lucky winner ;-)
 * smb feels so ... special
<bjf> apw, from within the git clone, "create-release-tracker"
<bjf> apw, this will create the tracking bug and add a line to the changelog
<smb> Anyway I will have a sort of early eod today. There is some liquid waiting for me...
<JFo> mmmm
<smb> sconklin, Just to be sure and out of interest, you got mails I sent to the sru list about maverick bisected?
<bjf> smb, i got the emails as well, i just didn't recognize them for what they were, my bad
<sconklin> smb: yes, but the implications were not clear to me, and the tracking bugs were not changed. The tracking bugs are the definitive record of problems, so I did not realize the magnitude of the problem
<smb> bjf, Ah ok. No I was just wondering whether I sent them to myself or somethign
<bjf> sconklin, we need to make sure that the new workflow handles this case really well (bells, lights, sirens, etc.)
<JFo> smb, I am only seeing 4 bugs
<JFo> are there any other tags you'd like included?
<smb> JFo, Four sounds good... though a bit unlikely. There should be more actually with those two tags... For some the main task may be fixed though
<smb> or invalid
<JFo> could be
<JFo> I'll verify
<smb> JFo, Well if you mail me some list/link I could check and report at least the ones I find missing 
<JFo> ok, will do. I hadn't added the ec2 one yet. doing that now
<JFo> I see 18 tagged ec2-images
<sconklin> bjf: we're going to need the equivalent of a big red button on the workflow process
<smb> That sounds possible. Maybe I just did not add the other tag often enough yet.
<smb> JFo, Anyway, I hate to leave like that... but there is reason. :)
<JFo> no problem
<apw> bjf, AttributeError: class Kernel has no attribute 'series'
<apw> from create-release-tracker
<bjf> apw, huh
<bjf> apw, thanks for trying, i'll run that down
<bjf> apw, don't worry about it for now
<apw> bjf, i am told that its likely that its an inconsistancy archive wise, that triggered the erorrs on the natty backport and we should worry about it, for now i suggest we only worry about it after its been uploaded once to the archiive
<bjf> apw, i'm thinking i've not checked in a change, i have something in my local repo that i've not pushed
<apw> and we should not worry about it
<bjf> apw, it's in my code
<jonpry> i have serious acpi troubles on lenovo y560p. i am a semi experienced kernel hacker on arm platforms, but no idea about how acpi works
<mjg59> With magic
<jonpry> yeah i get that impression
<mjg59> Got a bug number?
<jonpry> https://bugzilla.redhat.com/show_bug.cgi?id=699156
<ubot2> bugzilla.redhat.com bug 699156 in kernel "Large amount of acpi interrupts on lenovo y560p with 2.6.38+" [Unspecified,New]
<mjg59> Huh it's even assigned to me and everything
<jonpry> yeah i have been stalking you
<mjg59> Could you attach lspci -vvvxxx (run as root) to the bug?
<jonpry> sure thing
<jonpry> i put up the lspci
<jonpry> i tried the simple stuff like turning off the gpe's but it doesn't seem to stick. pcie compat is no help. acpi off does the trick but kills smp
<jonpry> whats really cool is that there is GPE storm in dmesg. but all gpe are still running in interrupt mode. that seemed like the most obvious attack point to me
<mjg59> jonpry: Looks like I'll need acpidump output as well
<jonpry> any options?
<mjg59> Nope
<jonpry> mjg59: posted
<mjg59> Thanks
<jonpry> no thank you
<JFo> <-lunch back soon
 * tgardner --> lunch
<sforshee> BenC, for the machines you were working with affected by bug #424142, were there any symptoms beyond the "address space collision" messages?
<ubot2> Launchpad bug 424142 in linux "Address Collision" [Medium,Fix committed] https://launchpad.net/bugs/424142
<BenC> sforshee: yes, the collision kept the affected device from working (since ioremap would fail)
<BenC> other than that, no
<sforshee> BenC, thanks
 * JFo stepping away to run an errand
<bjf> apw, i believe i have fixed the problem you were seeing with create-release-tracker (just fyi)
<sconklin> apw: but create-release-tracker has also been changed to the new version, which likely requires you to be a member of the canonical-kernel-sru-team, I have added you
<jjohansen> gah, /me is suffering from wonderful graphical corruption again, making the display unreadable.  Time for a reboot, fsck, and lunch
<moodaepo> Folks are there plans to ship 2.6.39 with transparent_hugepage enabled? I was quite disappointed it couldn't get shipped as enabled in 2.6.38 but am hoping the i386 crash is fixed in the next release. Cheers
<broder> wait, transparent hugepages was finally merged? awesome
<jjohansen> broder: yeah
#ubuntu-kernel 2011-05-26
<smb> morning
<abogani> smb: morning
 * apw yawns
 * smb pats apw 
 * apw waves to jk- 
<jk-> hey apw
<ikepanhc> good morning folks
<smb> ikepanhc, hey Ike
<ikepanhc> :)
<apw> moin
<TeTeT> cking: hi there, I've used the suspend-resume script you provided in some util on a Lenovo T520 and now it's no longer returning from sleep at all - is it possible that setting the wakealarm messed something up? I checked the script, but cannot see anything ill in it
<cking> TeTeT, I recommend using fwts to test this. install fwts and run the wakealarm test to sanity check this first.
<cking> run "fwts wakealarm -"  to do the wakealarm test
<cking> oops, I meant "sudo fwts wakealarm -"
<TeTeT> cking: right now when it is sleeping, I press power button, the hd icon flashes for a split second, system goes back to sleep
<TeTeT> cking: ok, will give that a try
<cking> and then "sudo fwts s3 -" to do a suspend/resume tests
<_ruben> is there any documentation on how to use the linux-meta sourcepackage (or something else) to create the equivalent of the linux-(image-)server packages for a custom flavour?
<TeTeT> cking: bummer, I'm  stuck on Lucid due to customer requirement - any PPA for fwts?
<TeTeT> cking: nevermind, trying to build it myself
<cking> yep, ppa:firmware-testing-team/ppa-fwts-stable
<cking> I've never heard of a system that seems to wake and the goes back to sleep. most unusual
<TeTeT> cking: wakealarm tests passed, now onto suspend
<TeTeT> cking: same symptom, hd icon blinks, then system goes back to sleep, only hard power off will restart it. Any idea what to do next? Weird is, that I've seen this system doing suspend/resumes before. The new behaviour only appeared when trying the automated suspend/resume test
<apw> _ruben, no documentation no, but its a fairly straight forward meta package relationship
<apw> _ruben, there are examples in the mvl-dove etc branches in the lucid meta package
<_ruben> apw: no experience with metapackaging though
<_ruben> will have a look
<cking> TeTeT, so, do a clean boot and from the command prompt run "sudo pm-suspend" and see if you can wake it successfully
<TeTeT> cking: no success, tried it from console and gnome-terminal, even unplugged power and battery one time
<cking> TeTeT, any idea when this stopped working then?
<TeTeT> cking: yes, after I run sus-res.sh, let me pastebin it here: http://pastebin.ubuntu.com/613108/
<apw> OMG we have cd images
<cking> TeTeT, so, just to clarify, S3 worked, but *after* running that script it no longer works?
<TeTeT> cking: sort of worked, suspend worked fine, resume was shaky at best, at times graphics were utterly distorted, at times it resumed just fine
<TeTeT> cking: I'm completely lost on what could have broken the resume completely
<cking> TeTeT, lots of things - like misbehaving drivers or hardware, perhaps a newer kernel?
<cking> so has this machine run S3 reliably at any point in it's past?
<apw> or just phase of the moon, as its unrelaible to start with
<TeTeT> cking: from what I've seen - unreliably from the start, though our customers engineer said it worked reliably for him
<TeTeT> cking: I did a successful run of 3 manual suspend resumes this morning, but had failures before that
<apw> TeTeT, so we need to know if it worked before, if so where
<TeTeT> cking: so I thought it would be good to gather some metrics through an automated sus/res test and used the script you provided me a year or so ago
<TeTeT> apw: tested it via hotkey fn-f4, suspend through menu
<TeTeT> cking + apw : noteworthy is, that it is a laptop (T520) with Natty kernel and Lucid userland, due to customer requirements
<cking> TeTeT, the problem is that if it's "randomly" locking up we need to get some debug out to see where it's hanging. This could be tricky if it's failing in the early resume path
<TeTeT> the kernel comes from the backports ppa though
<cking> ah, I'm not sure if we guarantee lucid userland working sanely with natty kernels
<apw> https://wiki.ubuntu.com/DebuggingKernelSuspend
<apw> TeTeT, from where ?  we don't have a backports PPA
<TeTeT> cking: I'm quite sure we don't really support it, but it's an important customer and they'd like to demo the system tomorrow. Long term we need to find something supportable though
<apw> TeTeT, which exact version of the kernel are they running
<cking> apw, won't we have issues with X and drm with a lucid + natty combo?
<TeTeT> cking: it also runs xorg-edgers, otherwise only framebuffer is available
<jpds> Does anyone know what could be causing this error? http://pastebin.ubuntu.com/613113/
<apw> so an untested combination then
<TeTeT> apw: https://launchpad.net/~kernel-ppa/+archive/ppa
<TeTeT> apw: linux-lts-backport-natty
<apw> which VERSION
<TeTeT> apw: sorry, 2.6.38-8.42~lucid1
<mnemoc> so there is a ppa for oneric's kernel on natty...
<apw> mnemoc, nope
<apw> mnemoc, i was suggesting he takes the one in the oneiric release pocket
<apw> just to test
<mnemoc> ic
<mnemoc> will adding dmesg -n 8 to /etc/init/dmesg.conf help me to get detailed netconsole since the begining?
<mnemoc> /etc/default/rcS :)
 * ppisati -> out 4 lunch
<mnemoc> when trying to debug locks up on resume, does a "Magic number:" without any "hash matches" worth anything?
<apw> mnemoc, not that i know of
<mnemoc> thanks :-/
<mnemoc> [    2.913282]   Magic number: 11:37:579
<mnemoc> [    2.925935] pci_bus 0000:00: hash matches
<mnemoc> [    2.938883] rtc_cmos 00:04: setting system clock to 2011-05-26 10:33:30 UTC (1306406010)
<mnemoc> :'(
<apw> ppisati, i note that the maverick to-omap4 is really old, is that on your list to rebase to master ?
<mnemoc> apw: is the "beep" on resume from the EC, the kernel or ubuntu? the times my thinkpad resumes correctly it always beep, when it doesn't resume it doesn't beep either
<mjg59> mnemoc: The EC
<mnemoc> mjg59: does that imply my problem is on how the suspend is registered and not on a driver causing troubles on resume?
<ppisati> apw: we don't rebase omap4
<ppisati> apw: i only cherry pick CVEs IIRC
<mjg59> mnemoc: Difficult to know
<apw> really ? hrm i thought that was only the .38 one
<ppisati> apw: wait, i can be wrong, let me check...
<tgardner> apw, ti-omap4 has so much cruft in it that I don't think we can rebase it.
<apw> tgardner, on maverick ?
<ppisati> https://wiki.ubuntu.com/Kernel/Dev/Flavours
<ppisati> the matrix in the low part says "no rebase"
<ppisati> yep, never rebase an omap4 after midnight :)
<apw> heh ok, then it also needs some love if this matrix is anything to believe
<apw> http://people.canonical.com/~apw/cve/pkg/linux-ti-omap4.html
<tgardner> apw, you have to cherry-pick stable and CVE updates, which makes it kind of a pain in the ass
<apw> tgardner, ok ... well its not been done since Feb, so we need to get that done again
<tgardner> apw, thats what we have ppisati for :)
<apw> its lagging a lot ... ppisati another one for you :)
<apw> needs cves and any stable updates on that one :)
<ppisati> as for cves, i already have them in my tree on zinc, waiting for the master tree to hit -updates
<ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<ppisati> about the stable update, well, i usually follow: if it's not broken, don't touch it :)
<ppisati> i mean, if no one complains about a particular problem, i usually don't cherry pick from master
<ppisati> e.g. the pci prefetch patch i saw yesterday
<apw> ppisati, the problem with that approach is we get a lot of our CVEs via those stable updates, and they arn't marked as CVEs in our tree as a resul
<ppisati> shall i really aplly it?
<tgardner> ppisati, I think ti-omap4 only needs CVEs and perhaps some select stable updates.
<apw> which is fine, as long as we are moniroting http://people.canonical.com/~apw/cve/pkg/linux-ti-omap4.html and applying any missing ones
<ppisati> apw: ok
<apw> as i say we get a lot of our cves unmarked via stable these days
<ppisati> so i'll better follow that pages
<apw> ppisati, more fun :)
<ppisati> in fact, some of the imx51 are only on that page
<apw> http://people.canonical.com/~apw/cve/pkg/ALL-linux.html ... has all of them
<apw> tgardner, ^^ has a complete view of all our open ones
<tgardner> apw, hmm, pretty colors
<apw> tall piles of orange up the page == bad :)
<tgardner> apw, what is the difference between yellow and orange?
<apw> priority of the bug
<apw> i think orange is more important
<apw> of course we expect the arm branches to lag where they are rebases until the rebases are pushed
<JFo> that was interesting. machine froze and nothing I had done today was saved. For instance; e-mail that I read, documents I had changed and saved, etc.
<JFo> very odd
<charlie-tca> oh, I know that one, too. 
<charlie-tca> I did that yesterday and had to force the hard restart
<JFo> yeah, me too
<JFo> had to softswitch the machine off
<JFo> but the mouse pointer was still working
<sconklin> tgardner: I'm going to apply upstream stable to Natty master-next today unless you've already started working on it
<JFo> was like the background froze
<charlie-tca> and I even ssh'd in and ran top and ps, none of my applications on the desktop showed up anywhere
<tgardner> sconklin, go ahead
<sconklin> ack
<JFo> <-lunch and errands.
<bjf> sbeattie, has there been any thoughts on breaking up qa-regression-testing so it's not a 650MB pull just to get the scripts?
<sbeattie> bjf: yes. if you have the tree locally, the scripts/make-test-tarball will pull together just the bits for a specific test script.
<sbeattie> bjf: it's less than ideal, but for some use cases it works okay.
<bjf> sbeattie, but that means i have to pull down the 650MB so i can create a smaller tar file ?
<sbeattie> bjf: yes. Like I said, it's less than ideal. OTOH, once it's down, a bzr pull or bzr up will keep it up to date, and you won't need to pull over and over.
<sbeattie> (that's one thing I miss from subversion, the ability to just check out part of a tree)
<bjf> sbeattie, i understand that once i have it it's easier to keep updated, but I'm thinking of how to get the tests onto systems to be re-imaged and tested
<sbeattie> bjf: right. we've tended to have the test-driver generate the specific tarball(s) from a cached copy of the bzr tree, rather than shove the entire tree onto the test system.
<bjf> sbeattie, sure, i just worry that you now have a snapshot that "someone" needs to be diligent about keeping refreshed with the latest changes, and that's sure to bite us in the ass now and then
<sbeattie> bjf: what's annoying is, of that 650MB, 300MB of it is sitting in .bzr
<sbeattie> bjf: understood.
<hggdh> bjf, sbeattie: this is the approach I did on the current kernel SRU tests -- I have a helper build script that grabs all updates needed from a local branch of the QRT, and rebuilds the test tarball
<hggdh> bjf, sbeattie: another thing to keep in mind is the QRT is continuously tinkered with -- updates, corrections, etc
<bjf> hggdh, that's why i don't like taking snapshots
<hggdh> bjf: I understand, but given the QRT is continuously updated, there is not much options (and also given the limitations on bzr)
<bjf> hggdh, if i understand you, you are saying you need to snapshot because QRT is also where open development is happening at the same time
<hggdh> bjf: indeed. 
<bjf> hggdh, well, to my thinking, that's broken, we should be using "releases" of QRT, how do you know that the snapshot you just took is in a state to be used?
<hggdh> bjf: this is a chicken-and-egg problem... most of the (current) updates that affect kernel testing were done _because_ of the kernel testing; also, QRT is updated to add new tests
<hggdh> bjf: and -- on my view -- we need them. For standard -- non-security-related -- we do not need to update (and I have been using the autotest.kernel.org pretty much stable
<hggdh> for example
<bjf> hggdh, i disagree but this isn't the right place to have that discussion
<hggdh> bjf: OK
<sbeattie> bjf: we try hard to ensure commits to QRT are complete and don't break things. We don't always succeed...
<bjf> sbeattie, i understand
<jdstrand> bjf: 'open development' is, while true, somewhat mischaracterized. for example, the kernel tests are updated when regressions are found, when there are new reproducers for CVEs, when the test is wrong on an older release. the scripts are also coded with release specific items and commits should not be made to qrt without verifyingon all releases
<jdstrand> of course, things do change, but generally speaking, the tests are supposed to become better, more accurate and more comprehensive for *all* releases, not just devel, for example
<sbeattie> jdstrand: do you know if there's anything we can do to better pack the tree? .bzr is 300MB locally.
<bjf> jdstrand, i care about all kernel releases, stable as well as devel. i just think that there are problems with the process
<jdstrand> we've talked about 'releases' of qrt, but that ends up being a lot of overhead. eg, we have a test case for a new cve that affects hardy - oneiric. we can update in a bunch of trees or just one
<jdstrand> sbeattie: I do not, though I think a fresh checkout should reduce that
 * jdstrand is not sure
<sbeattie> bjf: we also care about all the releases; if anything where QRT can lag is in the devel release.
<jdstrand> I pulled out the vm that was in there
<jdstrand> I also just now gzipped the stuff in install/get_file_info_results/
<sbeattie> jdstrand: yeah, saw the commit, thanks.
<jdstrand> bjf: I wasn't implying you didn't care about other releases, I was making the point that commits we make must work on all of them
<jdstrand> but, people will always have to pull from somewhere, if for no other reason than to get the latest reproducers
<jdstrand> so I'm not sure how to fix that other than with scripting
<jdstrand> as for the size, that is a problem, but creative 'mirroring' can help there
<bjf> jdstrand, yes, people will always have to pull from somewhere
<jdstrand> so, fwiw, I just branched it fresh and it is now 563M. still huge, but slightly better
<bjf> jdstrand, the problem i'm most having here, is if all ubuntu projects worked they way you believe QRT is working and should continue to work, we'd never have anything in a state to ship
<ubuser> can someone help me
<apw> bjf, who did we liase with in -security over dapper bugs ?
<jdstrand> sbeattie: I was wrong, .bzr is still 305M
<ubuser> i cant get my pc to boot, i tried installing grub2, now it is giving me error 15 
<ubuser> is there a way around this?
<bjf> apw, probably kees to start with
<bjf> apw, you have one you think should go in?
<jdstrand> bjf: I understand your point, but qrt isn't 'shippable'. we don't want it in a frozen state, because we want the new tests (unlike saw hardware cert)
<apw> bjf, do you know what we are meant to do with dapper entries?  as we're not planning another uplaod ?
<jdstrand> there are always new SRU bugs and CVE reproducers, etc that we want to ship
<bjf> apw, i think "ignored" is acceptable state
<jdstrand> apw: oh, that was me
<apw> bjf, and we have carte-blanc to apply those to anything that open ?
<ubuser> please help me get past the grub menu!!! im stuck at boot screen
<apw> jdstrand, ^^
<jdstrand> apw: I went through all the dapper ones and gave a list of what was important to fix and what wasn't. I forget where I sent it, but iirc it was all 'done'
<apw> ubuser, what do you see ?
<jdstrand> that was last month
<ubuser> i see grub error 15 at boot screen
<apw> jdstrand, since then there are new ones added, are you going to sort through those as well or do we just wack them
<ubuser> escape button to bypass this error would pwn
<sbeattie> bjf: in particular, if you're testing a kernel update, we may have just committed reproducers for a specific issue that that kernel is intended to address.
<bjf> sbeattie, ack
<apw> ubuser, it seems that Error 15: means file not found, so something it needs is missing
<apw> ubuser, were you using grub beforehand ?
<ubuser> yes
<[7]> ubuser: "error 15" means that whatever is running there is not grub2
<jdstrand> apw: new ones ask kees about. that said, if they are 'low' priority, ignore for sure. if they are 'high' then fix. 'medium' is a more pragmatic approach that I you and kees can decide on. eg, if it is in a driver that no one uses, ignore. if it is something on everyone's machine, maybe fix (but still, maybe not)
<ubuser> i tried to install it again, i wanted to fix my video settings, and everyone in the ubuntu channel kept telling me to update
<ubuser> and i updated, b4 i went to sleep
<jdstrand> s/that I you/that you/
<ubuser> but i had my video working, now i got screweedddd
<apw> so what exactly did you type to install grub
<broder> is there anything in particular i can do to get more attention for bug #784335? i'm no kernel debugger myself, but i'm happy to mangle the machine in question in any way that would be helpful
<ubot2> Launchpad bug 784335 in linux "Heavy network utilization with r8169 leads to kernel panic" [Undecided,Confirmed] https://launchpad.net/bugs/784335
<jdstrand> apw: fyi, kees will be online in a little while
<[7]> ubuser: also, your question isn't really related to the kernel, right?
<ubuser> mine is
<apw> jdstrand, thanks dropped him an irc asking him to deal with it :)
<ubuser> but im so far screwed it aint funny
<jdstrand> hehe
<ubuser> no luck for m3 yay
<ubuser> im having video errors, but that doesnt matter.
<ubuser> im stuck without a pc
<[7]> ubuser: no, it isn't. it's related to grub, not to the kernel. anyway, try this: https://help.ubuntu.com/community/Grub2#Reinstalling%20from%20LiveCD
<apw> yeah, thanks [7]'s suggestion is the first step
<ubuser> kernel = radeon.new-pll=0
<ubuser> thats the trouble im having with kernel
<ubuser> i need to add it
<ubuser> but i cant, cuz i cant get on my pc
<ubuser> i need to delete grub
<ubuser> idk how
<[7]> no, you need to install grub2
<ubuser> i cant no cd
<jdstrand> bjf, sbeattie: the size of qrt is a long-standing issue that has always bothered me
<apw> ubuser, you cirtainly don't need to delete grub ... thats what boots your system
<apw> ubuser, you could use a memory stick instead
<[7]> as apparently your boot partition contains grub2 files but your mbr contains grub 0.97
<jdstrand> bjf, sbeattie: I just tried bzr co --lightweight ./qa-regression-testing/ qrt-test and qrt-test is 259M
<sbeattie> jdstrand: me too, as someone at the end of a slow dsl line.
<ubuser> how can i install the new grub easily then?
<[7]> by booting a live system on that box
<jdstrand> bjf, sbeattie: ymmv, I've not ever used --lightweight before just now
<ubuser> i got a ubuntu 5.10 cd, but idk if thatll work
<apw> 5.10 ... heh what the heck was that warty ?
<jdstrand> du -sh ./.bzr
<jdstrand> 476K	./.bzr
<ubuser> i am currently on 10.04
<ubuser> i updated...
<ubuser> i jus have that cd..
<[7]> it should be doable with 5.10 as well, but there probably aren't instructions for it
<[7]> another option would be a grub rescue disk
<ubuser> okay so put the cd in and click repair maybe? ill brb
<sbeattie> jdstrand: I wonder if  bzr pack --clean-obsolete-packs would help
<[7]> ubuser: it's not as simple as that
<sbeattie> jdstrand: also, another experiment would be to try bzr export
<ubuser> great..
<ubuser> i wish u could hit escape, thats mad lame
<jdstrand> sbeattie: I think the other big opportunity is scripts/mysql/employees_db/*
<[7]> you'll need to rewrite the mbr from the command line, or use a more recent ubuntu version and follow the instructions i linked
<jdstrand> sbeattie: 164672 ./mysql
<[7]> hm, or you could temporarily drop some grub0.97 files on the /boot partition using 5.10, that might work
<jdstrand> sbeattie: those are all text files and could be compressed-- but we would need to adjust test-mysql.py
<ubuser> im not downloading another gig, i will throw it in the streets
<jdstrand> sbeattie: could probably shave another 150M off right there
<jdstrand> sbeattie: iirc, I tried pack --clean-obsolete-packs once and it didn't do as much as I had hoped
<jdstrand> sbeattie: before updating mysql, it might be worth talking to mdeslaur, since he might not have compressed for a reason
<jdstrand> sbeattie: after that, it is conceivable we could split out data/-- it is <40M and I'm not sure the benefit would outweigh the pain of having to deal with that change properly
<sbeattie> jdstrand: I'm dubious of splitting out data/ as well.
<sbeattie> jdstrand: realistically, scripts and data is 110MB (with mysql/ compressed), that's better than the current situation.
<jdstrand> totally!
<sbeattie> jdstrand: I could be convinced to split out results tracking to a different tree, but even as it is, I forget to update that part of the tree.
<jdstrand> 650M+ to 110M is pretty good :)
<jdstrand> well, results is only 9M
<apw> the sha1 to the cve-tracker ... want to see what the update script does
<jdstrand> sbeattie: fyi, in some cases I would have a tarball for a directory to unpack. you could theoretically create employees_db.tar.gz, add a bzrignore and a line or two of code and by done with it (there are likely other ways to handle it)
<jdstrand> s/and by/and be/
<jdstrand> anyhoo, my 2 cents. I'm moving along now :)
<kees> apw: no, because we talked about creating a new bug and duping the old one.
<bjf> kees, you know where the bug-opening script live? you can run it thus: "create-cve-tracker --staging --cve=2011-????" and it will create a bug on the qastaging server and give you a url to it to look at
<kees> apw: but I don't know where to find the new bug creator tool
<bjf> kees, it is in the kteam-tools git repo
<kees> bjf: okay, one sec....
<bjf> kees: git://kernel.ubuntu.com/ubuntu/kteam-tools.git
<apw> kees, yeah thats the rigth thing to do, but presumably that would end up updating the cve tracker to have an extra upstream sha1
<apw> and as we don't ahve the sync i wanted to add it manually to see if my scripting will revoke the complete status
<kees> right, I want to get the steps in the right order
<apw> as it should
<kees> ImportError: No module named lpltk.service
<kees> is that part of arsenal?
<tgardner> kees, launchpad API I think
<kees> hm, no, I have all the upstream LP bits installed, afaik. I use it for the QA and Security tools
<bjf> kees, new arsenal lpltk
<kees> bjf: do you have the bzr location of that handy?
<bjf> kees, getting it
<bjf> kees, bzr+ssh://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/
<kees> thx
<tgardner> bjf, is there a way to automate that? or at least indicate whats missing? I'll sure as hell forget next time I'm on  a new machine.
<bjf> tgardner, that's why we want to make "kteam-tools" a package with "lpltk" a dependency
<bjf> tgardner, but in the mean time, i'll think about it
<tgardner> bjf, ok, packaging is likely fine.
<kees> eeeeww, it's using desktop auth?
<kees> bryce: I thought you fixed arsenal to not do this. :)
<apw> kees, is the cve-tracker going to have the bug number in it, i assume so
<kees> apw: one sec
<bryce> kees, yes
<kees> bryce: maybe it doesn't do it for the qastaging server?
<kees> I just got prompted for "desktop integration"
<doko> rtg, apw, ogasawara: uploaded gcc-4.6, no linaro changes, only fsf updates, currently building
<ogasawara> doko: ack, thanks
<bryce> kees, it's fixed in LaunchpadService, but some script use lpltk.service
<apw> doko, thanks for the heads up
<bryce> which I think brad means to be a symlink to the former but maybe not?
<bryce> bbiab
 * kees doesn't know, but ./create-cve-tracker is just hanging.... digging...
<apw> kees, it takes some minutes to run and says nothing
<kees> oh, whoa, I bet it's the linear CVE search!
<kees> work-around for that is to just add a CVE comment, and that will link to the CVE even if LP doesn't know about it.
 * apw has to wander ... kees let me know when the cve tracker has the bits and i'll see what my tooling does
<kees> apw: okay
<kees> bjf: that's weird, the script told me it created 718952 on staging, but that's not the right bug.
<bjf> kees, looking
<bjf> kees, https://qastaging.launchpad.net/ubuntu/+source/linux/+bug/718952   looks good to me!
<ubot2> Launchpad bug 718952 in grub2 "no longer boots because ext4 /home lost its UUID" [Undecided,New]
<kees> bjf: it's not reported by me, not a kernel bug, doesn't have the packages, nominations, etc.
<kees>  ** Error: An exception was thrown after creating the bug, therefore, one should have been created. And you may have to fix it up by hand.
<kees> https://bugs.staging.launchpad.net/bugs/718952
<bjf> kees, i'm looking at it right now, it's by you, is a kernel bug, and has the nominations
<bjf> kees, you are not looking at qastaging
<kees> oh, well, that's the url the script reported. heh
<bjf> kees, look at the url i just posted
<kees> yeah, that one looks okay.
<bjf> kees, ah! will fix that
 * kees adjusts too
<kees> *sigh* thanks LP OOPS-1972QASTAGING77
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=1972QASTAGING77
 * kees tries again
<bjf> kees, fixed that bug, thanks
<kees> np, I've got a few other updates too... but I want to actually finish one bug creation without it failing...
<kees> AttributeError: 'Bug' object has no attribute 'newMessage'
<kees> wtf??
<kees> (my addition, but it's part of the API!)
<kees> https://edge.launchpad.net/+apidoc/1.0.html#bug
<bjf> kees, let me run it and see
<kees> bjf: that's a change I made
<kees> I replaced the linear CVE search with:
<kees>                     # Link the appropriate cve to the bug.
<kees>                     # Cannot safely use 'linkCVE' due to LP: #439470
<kees>                     print "Linking to %s ..." % (title)
<kees>                     bug.newMessage(content=title)
<bjf> kees, where did you make that change?
<kees> http://paste.ubuntu.com/613387/
<bjf> kees, bug is an instance of an lpltk Bug class
<kees> oh, so it is. :)
 * kees swaps to add_comment
 * kees is not used to using lpltk :)
<kees> I've done too much raw LP API coding
<kees> \o/ https://qastaging.launchpad.net/bugs/718955
<ubot2> Launchpad bug 718955 in beat-box "icon for currently playing song doesn't make sense" [Low,Fix released]
<bjf> kees, timeout error :-(
<kees> me too... trying again and again. qastaging sure is useful
<kees> but at least the script completed without error
<bjf> kees, when it's up, and working, yes
<bjf> it doesn't know that lucid is not supported
<bjf> sorry, that should be karmic
<kees> I can fix that. the cve tracker has all that logic.
<bjf> kees, i just depend on LP that way I don't get out of sync with what is really supported and what my db says is supported
<bjf> kees, note, qastaging is different from staging, qastaging is yet another, different snapshot of the LP db
<bjf> kees, the staging server was just too unreliable for dev work and the LP folks said to use qastaging (it's marginally better)
<kees> ah! I see now. the .active test. nice.
<kees> qastating is just out of date.
<bjf> yes
<kees> bjf: how do you want me to send update to kteam-tools? [PATCH] to kernel-team list?
<kees> *updates
<bjf> kees, yup, that works
<kees> bjf: okay, sent
<vanhoof> do we have a max recommended amount of memory on amd64 flavours (maverick/natty/oneiric) ?
<vanhoof> I know the theoretical limits of x86_64, but are there any practical limits that are recommended?
<bjf> vanhoof, nothing that i'm aware of
 * jjohansen -> lunch
<mak_ubu10> hey... my computer takes 25 mins to boot...
<mak_ubu10> can anybody help me....
<mak_ubu10> it waits for a long time.... after showing "Loading hardware drivers"
<ubuser> sound for ubuntu plz
<ikonia> ubuser: stop joining random channels and asking, we are dealing with your problem elsehere
#ubuntu-kernel 2011-05-27
<ogasawara> apw: just fyi, I'll cover us at the release meeting tomorrow.  gcc should just about be done building by then so I plan to do one last kernel upload to pull in what we have in master-next for Alpha-1.
<open-nandra> hi
<open-nandra> after upgrading to ubuntu 11.04 (for 10.10) i have troubles with my SD card reader integrated in acer extensa 5635
<open-nandra> simply put SD card in usb device (some realtek reader ) is recognized but then after some seconds is disconnected
<open-nandra> very strange
<open-nandra> works fine with 2.6.35
<open-nandra> any ideas or it is known pb?
<apw> open-nandra, nothing i've heard about no
<apw> pls file a bug against linux
<smb> morning
<jjohansen> morning smb
<ppisati> morning
<apw> morning
<jjohansen> morning: ppisati, apw
<apw> jjohansen, late one for you
<jjohansen> heh yeah, Ian had a late nap, so he will be up for at least a couple more hours so I am writing
<smb> code or documentation?
<jjohansen> smb: documentation after a fashion, its a paper
<apw> anyone else running natty with an external monitor, and if so, are the indicators on the external monitor creaping off the right slowly over time?
<smb> apw, Well I run it on my desktop...
<apw> this is over days i am noticing it moving off, the power button me menu and clock have gone now, and a few pixels of the envelope now
<jjohansen> apw: I get indicators being half drawn/covered and indicators disappearing, not seen going off the right
<smb> But the indicators stay I think (if they show up at all, though that could have been because when booting there was an external networking issue)
<apw> yestrerday i only had the date, no time from the time app, now the date is gone as well
<ohsix> are any of the migration applets in the empty space
<jjohansen> apw: fun, have you tried killing compiz, and or unity to see if it restores them
<smb> Hrm, only got the time there ... and the settings thre brings up ... nothing
<ohsix> er if it's unity then it's not a real panel and nevermind me :]
<soren> apw: I do have an external monitor, but I switch between it and the laptop's LCD a couple of times a day, and I don't see this happen at all.
<RAOF> apw: That's an *awesome* bug.  That I've not experienced with my external monitor and oneiric.
<apw> soren, yeah i suspect if i unplug and replug it'll get fixed 
<soren> apw: If only there was a way to find out...
<apw> the one on the LCD is fine, its just my external
<soren> :p
<smb> Great, no changing time and date settings today... at least not with the ui
<c2tarun> My kubuntu's performance is getting poor when I try to run my laptop on battery. Is there any way to improve it. I tried everything from power management and everywhere but, its not improving. I think its a kernel issue. Can anybody please help?
<jjohansen> c2tarun: that is rather vague, you need to collect more information
<c2tarun> jjohansen: what kind of information?
<jjohansen> c2tarun: well, some firm performance figures showing how things are slower would be good
<jjohansen> a bug with logs, etc
<jjohansen> maybe some runs with powertop, latencytop, ..
<c2tarun> jjohansen: hmm... how can I get log for getting system slow? I can feel it, opening any window and closing it, switching workspaces, openening widgets, everything is getting slower. :(
<jjohansen> c2tarun: right, but your feel of things getting slower isn't something we can debug against
<jjohansen> filing a bug, that collects the logs and system information gives some basic information to start from.
<c2tarun> jjohansen: yeah, you are right, actually I was looking for something that can enhance my system's performance and not fix a bug.
<ohsix> c2tarun: do you see intel_idle in the output of lsmod?
<c2tarun> ohsix: nope here is pastebin for my lsmod http://paste.kde.org/75217/
<jjohansen> g'night
<apw> ppisati, how goes your cve fun
<ppisati> apw: it goes :)
<ppisati> apw: i'm piling up the patches
<apw> ppisati, heh, how far through are you?
<smb> apw, If you do not hear us you are buggy
<apw> arrg
<apw> now i hear
<smb> yep
<ppisati> apw: down 15, i'm applying all of them now
<apw> ppisati, nice ... that'll help out stats
<ppisati> apw: yep
<ppisati> apw: i really didn't know of the existence of that page...
<apw> ppisati, heh no worries, that page is really the stable teams input for cves
<apw> and until karmic went dead fsl-imx51 at least was a rebase onto that, now its not we need some other solution
<apw> and you are the solution there, so its a new requirement just since release
<apw> so you not knowing isn't supprising
<ppisati> kernel is compiling
 * ppisati rushes out to het some food
<ghostcube> hi friend of mine has a 10.04 lts server with ecc ram and gets spammed by edac mc0 errors is there any solution
<smb> ghostcube, Yeah, better RAM
<ghostcube> heh
<smb> But really, had the same and had to find the module that was faulty. 
<smb> Those messages tell you that there is a problem. Usually like correctable ecc errors. There is some hints about the location too, but it can be a bit tedious to map them to the physical slots
<ghostcube> seems to be an edac bug
<ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/367774
<ubot2> Launchpad bug 367774 in linux "EDAC spam in dmesg, edac-utils shows no erros" [Undecided,Expired]
<ghostcube> his ram isnt faulty he testet it
<apw> ghostcube, in that bug all of the users seem to have indicated that quick boot was not clearing the memory out leading to the eec errors
<apw> somone has to write to all of ram before eec can be safely enabled
<ghostcube> yeah he tried this, but its still spamming errors its strange 
<ghostcube> one hint is just to blacklist edac modul
<apw> yep stops reporting but they are still there i am sure
<ghostcube> nope, he tried debian 6 hdd and bootet in slow boot now no more errors
<ghostcube> hmm
<apw> and does that kernel even have the edac module for his h/w ?
<apw> they are quite new in some cases
<ghostcube> its a asus pb5v
<ghostcube> p5bv
<ghostcube> http://buttersideup.com/edacwiki/Uninitialized_ECC_bits  found this
<ghostcube> https://bugzilla.redhat.com/show_bug.cgi?id=564274  and this
<ubot2> bugzilla.redhat.com bug 564274 in kernel "fake EDAC errors on i3210" [High,Closed: notabug]
<ghostcube> ok seems to be a bios prob
<apw> ghostcube, thats what it sounds like
<cjwatson> could somebody advise me on what to do about bug 785394?  reserving 128MiB of RAM seems like an awful lot, and I wonder why the kdump kernel is taking quite so much memory to boot
<ubot2> Launchpad bug 785394 in grub2 "Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux is insufficient" [Undecided,New] https://launchpad.net/bugs/785394
<cjwatson> It looks like it's OOMing while unpacking the initramfs ... hmm
<cjwatson> $ zcat /boot/initrd.img-2.6.38-9-generic | wc -c
<cjwatson> 44324864
<apw> cjwatson, the kernel en-toto is pretty huge, initramfs coming straight out of ram, both compressed and uncompressed
<apw> cjwatson, do we use a standard kernel for the kexec kernel?  ie. do we not strip the initramfs at all
<cjwatson> I was hoping one of you lot would know
<apw> i can have a look
<cjwatson> it does have to mount the rootfs, so it seems to me that it would have many of the same requirements
<apw> cjwatson, and the complaint there is that it won't fit into 64M in that bug
<cjwatson> though maybe we could use MODULES=dep for the kdump initramfs, if it's possible for it to be different
<apw> which with a 40M initrd, ... its not going to i suspect
<apw> cjwatson, right that was what i was thinkng, you kexec initrd really doesn't need to be portable
<cjwatson> I don't know if it's possible for it to be separate, though
<apw> cjwatson, me either, shall i take a look ?
<cjwatson> if you could, that'd be great
<ppisati> lucid -proposed is stuck due to ec2 bug, right?
<ppisati> i mean linux (2.6.32-32.62)
<ppisati> https://launchpad.net/ubuntu/lucid/+source/linux/+changelog
<herton> ppisati: yes, was put on hold because of ec2 issue
<ppisati> herton: i see
<apw> cjwatson, so its is a simple configuration to change which kernel kdump uses, defaulting to the current kernel, whats not so obvious is how we might maintain more than one initrd for a kernel via the normal mechanisms.   i don't know if we could consider having on fixed kernel for kdump, as using the likely crashing one to dump itself is a little scarey
 * apw pops out to collect a bag
<ppisati> what was the script that updated the changelog?
<herton> ppisati: debian/rules insertchanges ?
<ppisati> herton: i mean, the kteam tools
<ppisati> herton: i think it's startnewrelease
<JFo> I'm going to take a bit of an extended lunch. need to run some errands and check on my truck in the shop.
<JFo> may not be gone very long, but wanted to let you know anyway :)
<herton> ppisati: ah sorry, should be maintscripts/maint-startnewrelease
<ppisati> herton: yes, that one
<ppisati> herton: but it doesn't update the changelog
<ppisati> uhm
<herton> ppisati: yep, it just adds a boilerplate and insertchanges updates it after you commit your changes
<ppisati> so...
<ppisati> the process is
<ppisati> startnewlrelease
<ppisati> debian/rules insertchanges
<ppisati> and then a commit UBUNTU: Ubuntu-2.6.X-Y.Z
<herton> yep, from what I read from KernelMaintenance page in wiki
<ppisati> ah, the wiki... :)
<herton> ppisati: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<herton> but it seems to me we should always use maint-startnewrelease instead of startnewrelease rule, correct? (at least that is the procedure on stable proposed releases)
<ppisati> herton: yep
<ppisati> herton: maint-startnewrelease
<ppisati> herton: apply stuff
<ppisati> herton: and then close it
<ppisati> i will tatoo these steps on my right arm so i won't forget it anymore
<herton> hehe
 * herton --> lunch
<smb> herton, ppisati maint-startrelease also gets you the abi files and applies them to the commit
<ppisati> sorry, but still can't get my changelog updated
<ppisati> e.g. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=538abd32e3b8b1fb152927c9dfbd7b43f301e377
<ppisati> i miss the modification to changelog that this commit has
<ppisati> i know, i did it in the past
<ppisati> but i don't remeber how i got the stuff there
<ppisati> is there some magic script? or what else?
<bjf> ppisati, i can walk you through it
<ppisati> bjf: ok
<ppisati> i know i did it
<bjf> ppisati, did the "maint-startnewrelease" do the right things?
<ppisati> yep
<apw> ppisati, thats the fdr insertchanges  t
<bjf> did you do a "fdr insterchanges" ?
<apw> that makes those changes
<apw> -  CHANGELOG: Do not edit directly. Autogenerated at release.
<apw> -  CHANGELOG: Use the printchanges target to see the curent changes.
<apw> -  CHANGELOG: Use the insertchanges target to create the final log.
<ppisati> yes
<apw> the key lines are those and need to be there
<ppisati> that's what i get
<apw> also does fdr printchanges print anything
<ppisati> nothing
<ppisati> empty
<apw> as that is what gets inserted instread
<ppisati> printchanges i mean
<apw> ok then that likely means your previous commit has the wrong format
<apw> printchanges looks backwards for the UBUNTU: Ubuntu-xxxx line
<apw> and if thats not formatted right in the previous version it breaks
<ppisati> the tree is this one:
<ppisati> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/fsl-imx51
<apw> commit 861bf6eb84e2b72966a881ce523661ae850b43ef
<apw> Author: Tim Gardner <tim.gardner@canonical.com>
<apw> Date:   Thu Mar 10 01:57:49 2011 -0700
<apw>     Ubuntu-2.6.31-608.25
<apw> and indeed its wrong
<ppisati> shall i... amend it?
<apw> it is missing the UUBNTU: prefix
<apw> i would ammend it yes
<ppisati> ok
<ppisati> let me try...
<apw> bjf, you have a script for checking a tree tip has been correctly closed i think?
<bjf> apw, yes, "verify-release-ready"
<apw> ppisati, ^^ that is a good thing to use
<ppisati> ok
<ppisati> any way to amend the -16 commit?
<apw> w
<apw> ppisati, which one ?
<ppisati> the broken one
<apw> oh you mean the one which is 16 back from HEAD
<ppisati> yes
<apw> git rebase -i HEAD~16
<apw> then change the first line to edit
<apw> then git commit --ame
<apw> then git rebase --cont
 * ppisati tries...
<bjf> ppisati, is that commit on master branch and was it in a release?
<smb> sconklin, Hey Steve, you still need me to write a request to revert that max_pfn_mapped patch for Lucid and Maverick or will it be done just based on the failure
<apw> bjf, its on an fsl-imx51 branch
<bjf> apw, yes, but if that commit was part of a release, that history shouldn't be re-written
<sconklin> smb I already reverted it for both
<smb> sconklin, Ah ok good
<apw> bjf, that specific commit is safe as it is now in a tag
<bjf> ok
<apw> and all of our arm kernels are rebase anyhow
<apw> so that having a non-linearaity isn't a big deal
<ppisati> everytime i close a release
<ppisati> i need a tracking bug?
<ppisati> i mean
<ppisati> since there's a big pile of cve
<ppisati> i wanyed to do it in steps
<ppisati> so, now i'm doing this
<ppisati> with some cves
<ppisati> and i'll ask for a pull
<ppisati> but i don't want an upload
<apw> well we don't have to close the release to do a pull of it
<ppisati> cool :)
<apw> so just do the startnewrelease, add gthe patches
<apw> and then just ask for a pull
<ppisati> ok
<apw> just leave it open
<ppisati> k
<ppisati> so, everytime we close, we upload and thus i need a tracking bug
<apw> yeah thats a pretty accurate
<bjf> ppisati, https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication
<bjf> ppisati, that explains all the steps
<apw> ppisati, but for the meantime we can leave it not closed,
<apw> we often don't have it closed in the repo
<apw> with things sitting there waiting for more before the release gets closed
<ppisati> ok, so let's see it the other way around
<ppisati> i have a backlog of...
<ppisati> 50? 60? patches waiting to be applied
<ppisati> whats' the best policy?
<apw> well you are applying about 15 a day
<ppisati> s/policy/strategy/
<ppisati> yes
<apw> i would apply them as i go, pushing the branch to zinc in my public repo ready for pulling
<apw> then say weekly ask for it to be pulled
<apw> when _all_ are applied we can close it and give it stable for handling out
<ppisati> so the there will be just one big test session at the end
<apw> yeah most of these cves are 1) generic and 2) already tested
<apw> so the chance of regression for any which are just cherry-picks is pretty low
<ppisati> ok
<ppisati> deal
<apw> i would test them at the end and cross my fingers :)
<ppisati> actually i don't have the hw
<ppisati> so from time to time i compile a kernel and "ship" it to someone to do, at least, a boot
<apw> i would probabally produce one weekly as i went and ask #arm to test it
<ppisati> k
<apw> as it takes hours to build :(
<ppisati> well
<ppisati> i do it in about 15/20 minutes
<ppisati> i cross compile
<ppisati> all the other arm guys do native compilation
<ppisati> but it's really too slow
 * ppisati start a new recompilation...
 * apw wanders off to the pub
 * smb wanders off into the weekend
<JFo> <-jealous :)
<kees> apw: so, what happened with CVE-2010-3880 and maverick, exactly?
<ubot2> kees: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)
<bjf> kees, it's in the changelog as having been fixed, will look at the commit
<bjf> kees, the commit is there, it points at bug 711865
<ubot2> Launchpad bug 711865 in linux-fsl-imx51 "CVE-2010-3880" [Undecided,In progress] https://launchpad.net/bugs/711865
<bjf> kees, do you believe there is an issue with the commit?
<kees> bjf: I don't know, apw's script flipped it from released to "pending" with no version
<bjf> kees, _that_ i have no idea about
<kees> bjf: yeah, I'm scratchin' my head too :) it was the only thing I saw in the latest merge that looked funny
<Quintasan> Um, hi there. I'm running Kubuntu Natty and I'm experiencing strange freezees (seemingly at random but mostly occur when playing a video). The video stops, I can kill the player, but if I try to type someting in for ex. konsole it doesn't respond, then everything stops responding (can't run anything, can't close anything) so I can only do SysRq + RSEIUB -> http://paste.ubuntu.com/613947 <- kernel log from before the freeze, what is 
<Quintasan> exatcly going wrong there?
#ubuntu-kernel 2011-05-28
<Crabrom> Hello
<Crabrom> I have a quick question, is TRIM only available in 2.6.33 onwards? 
<apw> Crabrom, cirtainly around that sort of time frame yes
<Crabrom> seeing as how 10.04 is LTS
<Crabrom> would it be unreasonable to ask for trim support in the 2.6.32 kernel for 10.04?
<apw> if it was after the lts there is little likelyhood of something so big being pushed back the lts
<Crabrom> Ah, ok then
<apw> kees, that one is not released is why in maverick ... upstream fix is 9f69eef42993952b7685bdb80a0fdc8724805e02 which is sitting on master-next as 9f69eef42993952b7685bdb80a0fdc8724805e02, which is not closed and uploaded yet ... the definition of pending without a version no?
<apw> bjf ^^
<Quintasan> I'm running Kubuntu Natty and I'm experiencing strange freezees (seemingly at random but mostly occur when playing a video). The video stops, I can kill the player, but if I try to type someting in for ex. konsole it doesn't respond, then everything stops responding (can't run anything, can't close anything) so I can only do SysRq + RSEIUB -> http://paste.ubuntu.com/614347/ <- kernel log from before the freeze, what is exatcly going wrong
<Quintasan>  there?
<ohsix> did you look at /var/log/Xorg.0.log (or .old after a restart of X/the computer)
#ubuntu-kernel 2011-05-29
<Quintasan> ohsix: Nothing really interesting
<Quintasan> [ 85807.926]  ddxSigGiveUp: Closing log
<Quintasan> That repeats twice in all logs on my system
<Quintasan> s/all logs/all X logs
<SubCool> Hey, i was hoping someone could help me fix my webcam. It was working before i upgrade to 11.04, now all i get is a black screen. I dont see any error message when i run skype in konsole
<funnylookinhat> I'm trying to find out what kernel is being using is OO - my goal is to request a feature to support the Optimus graphics chipsets that are supported in this patch: http://www.phoronix.com/scan.php?page=news_item&px=OTQzMA
#ubuntu-kernel 2012-05-21
 * smb yawns
 * apw looks blearily at smb
<smb> apw, Sounds as awake as I am
<apw> hardly i suspect
<Kano> hi, is 3.4 final already triggered to compile?
<apw> depends what happend to the build server on friday
<Kano> and what happend?
<apw> they were shifting the disk as root was too big
<Kano> and that disabled the autobuilds?
<apw> if the machine doing the autobuilds is down, yes
<Kano> can you check?
<smb> If we got enough coffee and we can log in
<Kano> btw. could you add a litte patch that just adds a 0 size header to fix build of some drivers?
<Kano> it does not matter if it is the "correct" file, but it has to be there
<Kano> http://paste.debian.net/170399/
<Kano> something like that
<Kano> that would be enough
<apw> cking, ??
<Kano> apw: whould you add that when attached to the bug report?
<cking> apw, you referring to my audio beiong broken
<apw> cking, rather unsubtly
<smb> he does
 * cking gives it a whack
<apw> Kano, i am working on your first question, and a cup of tea
<Kano> ah
<Kano> well i work on many things the same time ;)
<apw> cking, we can hear you
<apw> Kano, as can i, my other three threads are working on getting my laptop working
<apw> cking, we are talking to each other
<Kano> whats up with your laptop?
<apw> Kano, catastrophic disk failure
<apw> cking, nope, tempting though it is we are talking
<smb> cking, Right we all muted ourselves... :-P
<Kano> replace it?
<apw> Kano, now that is a good idea, why didn't i think of it
<cking> I think apw needs to glue all loose the oxide back on the platter
<apw> cking, oh another good idea
<Kano> dont worry my 40 gb ssd died last week
<cking> Kano, which model? (so I won't buy one)
<Kano> cking: corsair f40
<cking> ah
 * cking reboots
<acapemont> quick question: my site works when you go to https://site.site.com but not http://site.site.com (loads HTML without a stylesheet) 
<apw> acapemont, hmmm ... the config for those two are differernt arn't they?  effectivly different sites.  though you'd find better understanding from the server folks, on #ubuntu-server
 * ppisati -> goes for more coffee...
<acapemont> will check in there
<acapemont> thanks
<ohsix> browser might not like a css reference from an ssl page to a non ssl resource too :p
 * ppisati -> reboots
<cooloney> morning, EU folks
<smb> cooloney, evening 
<apw> cooloney, yo
<apw> cooloney, hows it going... having fun with lxc ?
<cooloney> interesting, a chinese linux os vendor called YlmfOS includes uksm in their kernel
<Kano> anybody going to berlin this week?
<apw> cooloney, uksm ?
<cooloney> apw: http://kerneldedup.org/
<cooloney> too bad, all of them are in Chinese
<apw> yeah chinese only it seems, my reading isn't quite up to that
<cooloney> UKSM might be developed by some Chinese kernel developer, which support to kill data duplication so it will get more free memory in the system
<cooloney> data deduplication
<apw> oh universal kernel shared memory or something
<cooloney> apw: ultra ksm, heh
<cooloney> apw: but you can watch the video, 
<cooloney> apw: looks like it's a competitor for KSM 
<apw> its cirtainly an impressive looking video
<apw> cooloney, is a shame i cannot read the sub-titles
<cooloney> apw: it claims it's much better than KSM.
<apw> its cirtainly doing something
<apw> assuming the video is real
<cooloney> apw: and it targets for virtualization, VPS market.
<apw> cooloney, yeah those guys must love all of those sharing things
<cooloney> but allo docs are in Chinese, and they don't have manpower to push code to upstream. heh
<apw> there is always the problem, lack of manpower.  when they get sick of forward portging it all the time they will learn, they don't have the manpower not to upstream it
<cooloney> apw: they provide kernel for our 12.04, maybe we can try it.
<apw> i think you should read the docs, and see how massive it is before we get excited about it
<cooloney> apw: yeah, i'm reading their doc
<cooloney> apw: at least, http://buyvm.net/ and ylmf OS 5.0 are using it.
<alexbligh> Is there a simple way to get the changesets from stock kernel 3.2 (or whatever the upstream Precise is based on) and the source package to build the Precise kernel (i.e. incl debian & debian.master directories)?
<apw> alexbligh, our kernel is in git on kernel.ubuntu.com ... all the changes are there as commits
<apw> the source package it was built from you can either get from launchpad, or regenerate it from the tag in the same repo
<ppisati> apw: when you have some free cycle, can you tell me where to find you config review scripts?
<apw> ppisati, sure ...
<Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/942569
<ubot2> Launchpad bug 942569 in linux "binary headers packages are missing include/generated/compile.h" [Low,In progress]
<Kano> now added there
<ppisati> i should fill the expenses...
<cking> ppisati, definitely
 * ppisati -> lunch
<alexbligh> apw, oops, missed your reply. Are you saying that kernel.ubuntu.com is rebased onto the 3.2 release? I'd assumed (quite possibly wrongly) that it was based on the Oneiric release, with the commits to bring the kernel up to date being imported.
<apw> alexbligh, we rebase for each release, so that we know what we are carrying
<alexbligh> apw, ah cool (I think). So in theory, if I had an extensively modified 3.2 kernel prepared by a.n.other (SUSE in this case), I should be able to apply your commits on top and get something with precise-like drivers and configuration.
<apw> alexbligh, all depends how modified, but yes
<alexbligh> 100 patches (patches.xen - oldstyle xenlinux). I've tried the other way around (take Precise kernel, apply 100 patches, and compile) but it's got lost in some has_fpu nastiness that I don't feel confident about fixing. Looks like SUSE and Ubuntu both took different approaches from mainline.
<apw> alexbligh, patches.xen, those are for xen host integration right ?
<apw> alexbligh, as we expect all the xen goodness to be in 3.2
<alexbligh> apw, oldstyle xenlinux support so you can run xen3.3 (as opposed to xen4).
<apw> alexbligh, as in we are not carrying anything for xen at all
<apw> smb, ^^ ?
<alexbligh> apw, yes you do - you carry all the Xen4 stuff.
<alexbligh> apw, at least it works fine with Precise as domU and Oneiric as dom0
<smb> Referring to lucid (10.04)?
<alexbligh> smb, no Precise
<smb> That is just mainline (having not read the hole backlog yet)
<alexbligh> we have some customers who want to run Xen3 rather than Xen4
<apw> smb, we don't have any xen patches for either dom0 or domU do we ?
<apw> (in precise)
<alexbligh> smb, yeah, mainline is just fine for Xen4
<smb> apw, no
<alexbligh> patches.xen is SUSE's patch set to support Xen3 (not Xen4) on 3.x
<apw> hmmm, sounds like fun... /me declines to ask why someone would chose to run and old hypervisor
<alexbligh> so my masochistic task for the week is to produce a kernel as close to Precise as possible (packaging and drivers) which does this too
<smb> apw, You get what you get on ec2
<alexbligh> apw, because Xen3 HVM guests do not in general run well on Xen4
<alexbligh> apw, and what smb says :-)
<apw> smb, but we don't run dom0 on ec2, so that at least is ok
<alexbligh> (though it's the former for us, as we use PV-on-HVM rather than full paravirt).
<apw> alexbligh, well that sounds like some fun :)
<smb> apw, If having all sorts of hyervisors is ok... yes
<apw> alexbligh, so normally their patches are a royal pain as they apply to a second set of source files
<smb> There might be at least two issues I know of, but apart from that we run mainline on ec2 since maverick at least
<smb> I believe Maverick was the one that still had the oxsave hack which now seems to cause problems with newer hypervisors
<apw> smb, yeah alexbligh's problem is host support
<alexbligh> apw, yes the patches are a PITA. I have actually got all the patches to apply on top of Precise. Compilation is a different matter though. I got this working for Natty rather more easily. Hence the different approach (take what SUSE has and Ubuntu-ify)
<apw> (dom0 support)
<apw> alexbligh, you are going to have sooo much fun
<alexbligh> apw, well, tbf, the Natty kernel I built worked first time (and I nearly fell off my chair). Precise appears to be a bit harder.
<smb> The suse set had a lot of staged things (xen_compat) which also makes you decide how far backward you want to go. Which in turn is hard to say on ec2
<alexbligh> smb, it's not so much EC-2 as I need. Technically the requirement is "to run Xen 3.3.x like Centos 2.6.18-xenified did"
 * smb wonders what exactly are the issues running native guest kernels...
<alexbligh> smb, and it's also easier to take ALL the SUSE stuff (either by importing the patches, or by just starting off with the fully patched source) than bits and bobs.
<smb> alexbligh, But you are aware that they rebase their set? Meaning future changes will sort of require a re-do-from-start
<alexbligh> smb, the issue is that our licensees have customers, and they don't want to futz with customer machines. And (for instance) if the end-user has a VM running on Xen 3.3.x, with a modern kernel, and they move to Xen4, then Xen4 will helpfully unplug emulated disks which will cause the end user machine not to reboot. So we have people not wanting to move to Xen4.
<alexbligh> smb, every Xen3 mod I have ever done means a redo-from-start.
<alexbligh> smb, in an ideal world, I would organise a neutron ray which erased every trace of existence of Xen3. However, this technology is still in alpha.
<alexbligh> smb, (but that's partly why I am looking to Ubuntu-ise a SUSE kernel, rather than patches.xen-ify an Ubuntu kernel, so they do all the hard work of rebasing not me).
<smb> alexbligh, Well yes the unplug. Though at least for newer kernels it should be ok as we build in the pv drivers. And older are not causing it
<smb> (newer meaning maverick to Precise (iirc)) probably only leaving natty in a mess
<alexbligh> smb, the issue is they have (for instance) customers with (say) /boot mounted on /dev/sda3 (not /dev/xvda3). /boot is hardly ever used, so no one notices the drop in performance. They are running on a modern kernel (let's say Precise). You change the hypervisor underneath them, and their /boot disappears. Another completely separate problem is that the images we have built for these people with old kernels on with xenlinux pv driv
<alexbligh> ers may or may not work under Xen4. The main problem is that the list of posisble changes (reordering of ethernet i/fs etc.) is so long, customers throw their hands up and day "noooo".
<alexbligh> apw, OK I think I am being dumb here. So I am looking at kernel.ubuntu.com, at ubuntu/ubuntu-precise.git. Should I not expect to see somewhere a series of commits that adds debian, debian.master, and some drivers? All I can see is stuff that changes Makefile and changelog!
<alexbligh> apw, ignore me, I am an idior
<smb> alexbligh, Yeah, the naming. Though of course upstream Xen always discouraged the use of sd? in the config. Unfortunately did not disable it to force people off. FS labels seems to be the simplest way around that but I understand one does not want to change all customer images.
<alexbligh> So when do you rebase against mainline? I can see a rebase against v3.2.14, but no rebase (or at least not commit with the word 'rebase' in) against 3.2.15 (though 3.2.15 tag is there)
<smb> What is more of a worry are those host side problems that are worked around in the patchset. Like the OSXSAVE or some broken hv call in earliest 3.x Xen
<smb> alexbligh, Either it is still in progress or has no commit. A rebase itself is invisible. Just normally one makes a comment when fixing up configs or changelogs...
<alexbligh> smb, but won't I get them anyway by taking SUSE's entire patch set? I mean won't Jan have done the hard work for me? Or do you mean he may only be bothered about domU stuff...
<smb> alexbligh, No it would be in there. It can have unexpected results sometimes. Like the fix for this broken hv poll call would turn ticket spinlocks into normal ones.
<smb> That one was only needed for earlier than xen 3.2 (iirc) and it seems that ec2 slowly got away from those...
<apw> alexbligh, we rebase against mainline/mainline stable until release, after release we cherrypick stable onto the top
<alexbligh> smb, right, but I'm not going to use the resultant ugly chimera of a source tree to compile anything other than Xen dom0 kernels. So if you mean 'it will impact performance/sanity' then fine; if you mean 'it's not actually going to work', though...
<apw> alexbligh, so there is a combination of techniques
<alexbligh> hmmm.... perhaps I am better just copying over debian & debian.master and using a SUSE kernel, packaged as a debian kernel. Yuck. Are there many additional drivers in precise I'm going to miss?
<apw> alexbligh, no idea what they have, we have little other than the union file systems that you may care about ... a lot of our delta is enablement for laptops and the like which is suspect is not your concern in a dom0
<smb> alexbligh, You mean only use it for guest kernels (sorry need more coffee for multilevel negation). I would expect it to only impact performance. If you pick the right compat setting
<apw> alexbligh, i wonder did you consider just merging the two tips, the suse and ubuntu ones, to see what happens
<apw> ppisati, do i see we now have a Q ti-omap4 ?
<tgardner> apw, I have not uploaded it yet. I thiugh I'd wait on ogasawara 3.4 rebase, and then have another look at the tools build failure.
<apw> tgardner, right but we have an official branch already ?
<tgardner> apw, yes
 * apw fixed up the cve-autotriager to use it ...
<ppisati> apw: yep
 * ppisati is trying to make audio work on it...
<ogasawara> hrm, can anyone else get to gomeisa?
<ogasawara> I keep getting a permission denied
<tgardner> ogasawara, still working on LDAP access
<apw> ogasawara, waiting on IS
<ogasawara> ah
<apw> tangerine should be ok
<cking> it is
 * ogasawara gets ready to abuse tangerine
<smb> fans start wailing
<alexbligh> apw, no particular interest in xen3 dom0 on a laptop :-). I meant we will only be using it for dom0 (host). Problem with merging the two tips is that for reasons I do not fully understand some, but not all, of the patches.xen are in git on SUSE (i.e. the patches are in their kernel source archives as individual git files, but they do not appear to all be applied, or more accurately there is no arch/x86/include/mach-xen directory (
<alexbligh> even though patches.xen contains changes for it); I am a bit lost as to why that is.
<apw> they prolly get copied from the originals, when the build is running
<apw> as i think they are copies of the existing files of the same names
<smb> At least this was some headache with that patchset (which we have in lucid ec2)
<smb> You basically end up with two parallel universes of Xen in the same source tree
<tseliot> apw, cking: my nvidia card is acting up with both nouveau and nvidia. It's a new card, I'm wondering if it's dying: http://paste.ubuntu.com/999086/
<smb> tseliot, At least something seems to decide to use interrupts no driver is expecting...
<tseliot> smb: would irqpoll help?
<tseliot> the only change I made was the graphics card...
<smb> tseliot, Not sure. This is probably not immediate. Where there any suspends in between? I would check /proc/interrupts after boot to see which interrupts where used by what
<smb> And when it happens whether it was a previously owned one that is reported to be not cared about
<tseliot> smb: no, I don't use suspend on the desktop
<smb> Somehow first irq#24 and then irq#16 triggered that and at least #24 was disabled... 
<tseliot> smb: irq24 is used by nouveau
<cking> what is irq16 used by?
<smb> and what type they are? msi?
<tseliot> cking: IO-APIC-fasteoi   ahci, uhci_hcd:usb3
<tseliot> 24 is IO-APIC-fasteoi   nouveau
<cking> tseliot, is the card seated in the slot correctly?
<smb> Hm, so for some reason there was an interrupt triggered on #24 which nouveau (or nvidia) driver did not think came from the card ...
<tseliot> cking: I think so but I'll double check this
<alexbligh> smb, apw, aaarrrggghhh. I am completely confused then, as the ubuntu kernel /does/ have a mach-xen directory.
<smb> alexbligh, The mach-xen is the upstream xen code... If the patchset is what I remember then you have xxx-xen.h header files in the arch/x86
<apw> apw@dm:~/git2/ubuntu-precise$ find . -name mach-xen
<apw> apw@dm:~/git2/ubuntu-precise$ 
<apw> alexbligh, ?
<smb> oh oops.. was it the other way...
<alexbligh> apw, find . -name 'mach-xen'
<alexbligh> ./arch/x86/include/mach-xen
<alexbligh> that's AFTER applying the suse patches
<smb> Yeah, sorry, mach-xen is the suse patchset
<alexbligh> (mm, phone)
<smb> arch/x86/include/xen is upstram
<apw> alexbligh, must be suse, its not in my tree
<Cimi> I noticed bcmwl-kernel-source doesn't build in quantal, thus leaving users without wifi (like on my macbook)
 * ogasawara back in 20
<Cimi> I think there's a simple patch for it, let me try having it
<smb> apw, alexbligh ,This is what I so much not like about the patchset. It makes obvious xen code not being used at all. And then some things used by both...
<tseliot> apw, cking, smb: some nasty traces from the blob: http://paste.ubuntu.com/999116/
<Cimi> well, patch is here https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/994255
<ubot2> Launchpad bug 994255 in bcmwl "bcmwl-kernel-source 5.100.82.38+bdcom-0ubuntu6.1: bcmwl kernel module failed to build [fatal error: asm/system.h: No such file or directory]" [High,Confirmed]
<tseliot> Cimi: what kernel?
<Cimi> tseliot, ciao alberto, 3.4.0 quantal
<tseliot> Cimi: ok, I think we have the same problem with Nvidia. I'll take care of it
 * sforshee leaves to take a car to the shop, back in 30 minutes
<ppisati> any experience with the alsa trees? i'm looking for a patch, but i can't find it in any tree they have
 * tgardner thinks ppisati should consult with david
<ppisati> diwic: ^^
<apw> tsimpson, Cimi, many fine system.h's have been removed P->Q
<diwic> ppisati, how can I help?
<ppisati> diwic: any experience with the git alsa tree?
<diwic> ppisati, yes
<ppisati> diwic: there's a patchset, composed of two patches
<ppisati> diwic: the first one was not commited, but the second one was
<ppisati> diwic: http://comments.gmane.org/gmane.linux.alsa.devel/96316
<ppisati> diwic: i can't find the first one
<ppisati> diwic: do you know where they ususally commit?
<diwic> ppisati, you might be looking for http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=summary
<diwic> ppisati, with the asoc subtree http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=summary (look for the tags/heads as master is not updated in this tree it seems like)
<ppisati> diwic: ok, found in the asoc tree, thanks
<alexbligh> smb, yes, mach-xen is in the SUSE patch set, but is not in the git tree which is the patched version of the kernel, as far as I can tell. Perhaps someone forgot to do a git add :-)
<smb> alexbligh, Looking at their source rpm some time ago, patching was part of the rpm build (at least for xen)
<alexbligh> smb, it is, but they have two kernel repos, one 'kernel-source' which is just the patches, and one called 'kernel' which is, I think, meant to be a git repo with all the patches applied. It appears to have every patch applied I can find, but missing mach-xen.
<alexbligh> (unless I've misunderstood). I think I should be asking this on #suse-kernel!
<smb> alexbligh, They likely should know better... :)
<smb> herton, bjf, Hm, does this look ok to you?
<smb>      linux | 3.2.0-24.37 | precise-updates | source
<smb>      linux | 3.2.0-24.38 | precise-security | source
<smb> oh...
<smb> nm, seems rmadison just got an intermediate state since the publishing was recently
<herton> smb, seems -updates is missing the latest
<herton> hmm ok
<apw> check thats true in the real archive, it may be rmadison
<smb> apw, yep
<smb> After lp was kind enough to return the history it should be ok
<henrix> smb: yeah, the kernel has just been copied to proposed
<apw> yeah think thats just cause -security is done first
<apw> but if it stayed like that security.u.c gets a caning
<smb> funy enough it says updates was done 2m before the other
<smb> oh no 
<tgardner> herton, I noticed that precise is still at 3.2.16. Are you gonna do 3.2.18 before the next upload ?
<smb> other way round
<herton> tgardner, I think we can update it, precise update being prepared now only have apw's hv fix, after that goes we will do with what we have in master-next
<herton> if we were going to use master-next today I would say to wait and update later, but that's not the case
<herton> I'll take care of it
<tgardner> herton, I kind of like to get stable updates applied to master-next as soon as they are released so we can start smoke testing them in the dailies. I generally boot 'em on at least a couple of boxes.
<herton> tgardner, yep, makes sense
 * ppisati -> brb
<jsalisbury> cking, Interesting bug.  Wireless performance drops off when running on battery vs AC power: bug 991232
<ubot2> Launchpad bug 991232 in linux "14e4:432b Regression in wireless performance when on battery power" [Medium,Incomplete] https://launchpad.net/bugs/991232
<cking> jsalisbury, I will attend to that one
<jsalisbury> cking, cool, thanks
<cking> jsalisbury, so I don't think that was caused by any of the precise pm changes, it looks like a wl binary module issue to me
<jsalisbury> cking, ok
<cking> but I will add some notes just to sanity check my assumption :-)
<ogasawara> tgardner: I think there were unwanted affects to amd64 after the collapsing of virtual
<tgardner> ogasawara, do tell
<ogasawara> tgardner: it looks like we're missing modules, eg like the extra's modules are not included
<tgardner> apw, ^^
<apw> ogasawara, not included in what>
<tgardner> ogasawara, yeah, there should be 2 packages, right ?
<ogasawara> tgardner, apw: right, for i386 we should have 2 packages, amd64 only 1.  however that 1 package for amd64 seems pretty bare.
<apw> no there should be two for both
<tgardner> ogasawara, why wouldn't we have 2 for amd64 ?
<apw> generic is two halfs, one half effecticly -virtual, and both together -generic
<ogasawara> tgardner, apw: oh? well that probably explains what I'm missing
<ogasawara> for some reason I had it in my head we only had virtual for i386
<tgardner> ogasawara, yeah, there should be an -extra- package for both arches
<tgardner> I believe in symmetry
<ogasawara> tgardner, apw: just fyi, I've pushed the 3.4 rebased bits to master-next.  it's basically what I intend to upload.  Am just going to do some meta package testing before pulling the trigger.
<apw> ogasawara, ack
<tgardner> ogasawara, having a look now...
<apw> tgardner, i take it you merged the fix for the udebs into my patches ?
<tgardner> apw, yep
<tgardner> apw, IIRC it was just a simple check to see if -extra- existed and to unpack it if so.
<apw> yeah i see it now
<smoser> smb, around?
<smb> smoser, wassup?
<smoser> on ec2 (precise)
<smoser> $ echo /dev/disk/by-*
<smoser> /dev/disk/by-label /dev/disk/by-path /dev/disk/by-uuid
<smoser> absent is 'by-id'
<smoser> i think we talked about this one, but dont remember, and only found https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/604335 as a reference for it (it was also broken for virtio)
<ubot2> Launchpad bug 604335 in grub2 "grub-pc.postinst script fails to detect virtio vda disk in KVM guest" [High,Triaged]
<smoser> i'm fine to open a bug on this, but wanted to know if you knew something right away. i'd open against udev, but it seems maybe kernel related (or xen even)
<smb> smoser, Hm, one of those things missing may point to some udev race. Not really remembering to have talked about this. May be the same thing... 
<smoser> its not race
<smb> About opening a new bug, depends on how busy the other already is...
<smoser> well the other is fix-released.
<smoser> (it was a grub bug dealing with the issue, and virtio is fixed now)
<smoser> i'll open a new bug, against kernel, let you figure out if that is where it should be, or if it is valid at all.
<smb> smoser, Hm, the bug still is triaged only...
<smoser> hm... interesting
<smb> smoser, But ok, cannot hurt to open a new bug
<smoser> hm.. wait.
<smoser> let me check to see if virtio is fixed
<smb> smoser, Just wondering a but that I should have had this when installing pv-on-hvm guests...
<smb> a bit...
<smoser> http://askubuntu.com/questions/80224/does-grub2-require-an-optional-scsi-feature
<smoser> that calls serial numbers (which are used for by-id) a "optional feature"
<smoser> and it seems that for vda it was at least not implemented at some points
<smoser> and might also not be implemented for xen
<smoser> verified that in 12.04 guest on 12.04 host (launched via openstack) there is no /dev/by-id
<smb> That could be quite likely. Though my machine here it seems also possible to use other "ids" like model name and serial... Not necessarily this would be there for emulated disks either...
<smb> smoser, But the real question is whether you also saw the failure they talk of...
<smoser> well, i have seen the grub failure.
<smoser> which is why i knew of this bug in the bakc of my head.
<smoser> but the grub issue is worked around
<smb> smoser, I did quite a few installs on hvm using the pv drives...
<smoser> somehow, not sure how.
<smb> Ah ok...
<smb> smoser, Not sure why grub would need the by-id, I thought we use the by-uuid (which is fs based)
<smoser> smb, but for identifying where to install aboot loader, block device is important
<smoser> (ie, most likely its installed onto /dev/sda, not /dev/sda1 ... the MBR)
<smb> smoser, Right, but how would your decision be made simpler by knowing any id? (not knowing exactly what grub2 does but usually tending towards the lowest major/minor it seems)
<smoser> smb, my desire for id is not related to grub2
<smoser> (and actually, not related to ec2).
<smb> Probably you can find /boot and then just drop any partition from the name
<smoser> i was thinking of making openstack's "attach volume" able to take a serialnumber input.
<smoser> and then it would attach the device with the given serial
<smoser> so that outside and inside could agree on which disk was which
<smoser> as it is right now, if you attach 2 block devices, there is no way of being certain which device is which.
<smb> I guess not without giving it any fs before...
<smoser> right. or if you dont know the contents of the block device. (ie, it *has* no fs)
<smb> smoser, Ok, so you basically want a new feature. And for that the vendor model method does not work as the disk inside would have a different one (as it can or cannot be a real one). And that said of you have a disk image you would have no by-id usable from outside
<smoser> smb, hm...
<smb> The more I think about it the less I am positive you can do what you want. I suppose an openstack volume can also be a disk, partition, lv, image file on the host. Having the same id would only be valid for passing on whole disks.
<smoser> i think we're misunderstanding each other.
<smoser> kvm does support this.
<smoser> i just verified.
<smoser> vm -m 256 -drive file=disk.img,if=virtio,serial=FOOBAR123 -drive file=seed.img,if=virtio -curses
<smoser> kvm -m 256 -drive file=disk.img,if=virtio,serial=FOOBAR123 -drive file=seed.img,if=virtio -curses
<smoser> then, inside, i get: virtio-FOOBAR123 -> ../../vda
<smoser> so its not really a new feature. but in xen it might be.
<smb> Ok, so you assign some serial when creating the guest (at that time but I think I remember libvirt allows to save it persistently) 
<smoser> well, libvirt does support this, yes. and yeah, it would also keep that with the libvirtxml for that domain
<smoser> but anyway.
<smoser> so i guess that my only question for you at this point is whether or not xen block has a 'serial' for the block device
<smoser> and the, if it did, if we appear to be correctly handling it .  ie, its possible that ec2 is just not providing one.  when none is provided in kvm, none is found in the guest.
<smb> So ok, it depends on the abilities of qemu-dm used by xen, the meta data stored for a domain and the xen-blkfront. I cannot say either right now. 
<smb> I don't remember seeing a serial in example guest configs for xen... but that may be inclomplete
 * ppisati -> bails out
<smb> smoser, Hm, checking some xen-unstable docs about the disk specification even for xl there does not seem to be any serial like option.
<smoser> smb, thanks for looking.
 * cking notes that bjf is working tangerine hard
 * henrix realised that some time ago :)
<bjf> load avg. 2300+
<cking> trying for a new record?
<bjf> i'm trying to see if i can make it catch fire
<cking> it's kinda unproductive to run so many things in parallel isn't it?
<cking> swapping a bit
 * cking tootles off, back later
<bjf> cking, i killed off all my builds, the load avg is still kind of high (1200+)
<cking> bjf, it's dropping now, thanks ;-)
<_ruben> 2300+ .. heh, nice :)
 * jjohansen is afraid he is partly to blame
<achiang> jsalisbury: ping
<jsalisbury> achiang, pong
 * tgardner  -> EOD
<achiang> jsalisbury: hi. re: #956845
<achiang> jsalisbury: did you write your latest comment by hand or did some bot do it?
<achiang> jsalisbury: because i don't think that comment is accurate or relevant
<jsalisbury> achiang, looking
<jsalisbury> achiang, I posted that due to the request in comment #28 to test the mainline(At the time) kernel.  Comment #29 reports the bug is in the upstream kernel as well.  However, just noticed your comment #36
<jsalisbury> achiang, so you think this bug is firmware related and not kernel?
<achiang> jsalisbury: right. i think the bug is due to the fact that ubuntu does not distribute proprietary broadcom firmware, and that jockey isn't/can't do the right thing to download it
<achiang> jsalisbury: for me, if i extracted the firmware as per my comments, then i get no more lockups
<jsalisbury> achiang, ahh, ok.  thanks for the feedback.  I'll update the bug and ask the bug reporter to test your suggestion in #34 again
<achiang> jsalisbury: thanks. arguably there's a jockey bug in there, but i don't think it's necessarily related to the kernel.
<jsalisbury> achiang, right.  thanks again!
<achiang> jsalisbury: ok, thanks. one last thing, the fix Worked For Me, but no clue if it'll be 100% reliable for the other guy
<jsalisbury> achiang, ok.  I'll await feedback from him.  If the fix works for him, do you think this is a bug in firmware-b43-installer?
<achiang> jsalisbury: perhaps. basically, i've never had luck getting firmware-b43-installer to do the right thing. i don't know if it is supposed to download the firmware i need, or if it is supposed to call the other meta-package, firmware-b43-lpphy-installer
<jsalisbury> achiang, ok, thanks
<achiang> jsalisbury: only firmware-b43-lpphy-installer seems to download the proper firmware. and even then, it only seems to work if the card is inserted into the machien
<achiang> jsalisbury: however, if inserting the card into the machine locks it up... well, you can see the problem there
<jsalisbury> achiang, yeah, right
<achiang> jsalisbury: it checks to see if the card is inserted before downloading the firmware. if it can't find the card, it refuses to download it. so even if you're plugged into wired ethernet, you can't get the firmware you need
<achiang> jsalisbury: the fix then, is to manually (ugh!) download and install the firmware. then you can insert the card without a complete lockup
<jsalisbury> achiang, hmm, sounds fun
<achiang> jsalisbury: hopefully you can feed this info back to the proper upstream
<jsalisbury> achiang, will try to do that
<jsalisbury> achiang, thanks for all the info
<achiang> jsalisbury: sure. and if you need more clarification via email or something, let me know. i have the hardware for a few more days (before i give it away to someone ;)
<jsalisbury> achiang, ok, thanks!
<achiang> jsalisbury: in summary, this could be fixed if firmware-b43-lpphy-installer were patched to allow firmware download/installation without the card being inserted. then it would be a quite simple process. 1) connect machine to wired ethernet. 2) apt-get install b43-fwcutter firmware-b43-lpphy-installer 3) insert card and enjoy wifi
#ubuntu-kernel 2012-05-22
 * apw yawns
<cooloney> morning, folks
<apw> cooloney, yo
 * cking waves to cooloney
<smb> cooloney, Morning
<smb> cooloney, Hows the lxc tests thing going?
<cooloney> smb: it got some testing error on both panda and my desktop
<smb> Nice, problems with the test code or the containers? If you can already tell...
<cooloney> smb: did you try that before?
<cooloney> smb: the testcase form serge
<cooloney> lp:~serge-hallyn/+junk/lxc-test
<smb> cooloney, No, did not hear of them before UDS
<smb> calling the ppa that way does not really give an impression of quality
<cooloney> smb: yeah, did you get serge's email. 
<cooloney> namespace attach (setns) patches
<smb> cooloney, I believe that was to the mailing list so yes
<smb> (not that I can remember the contents) But any way... it would be good to talk to Serge about it in some way. Given your distance from each other it may need to be email...
<cooloney> smb: yeah, i plan to email out, heh
<cooloney> smb: or maybe ping him later tonight
<smb> cooloney, can you keep me on cc on any emails. then I can follow a bit along
<cooloney> smb: sure, np.
<cooloney> smb: from serge's email, those ns patches from Eric is quite old but still out of mainline
<smb> cooloney, Yeah he said he wanted to submit some for -next into 3.5. Though that sounded a bit over-optimistic
<cooloney> smb: ok, got it. if they can 3.5, that's good for us
<cooloney> ppisati: moring, man
<apw> smb, bear in mind if its not in there already _now_ its too late
<smb> cooloney, I would not hold my breath for it
<apw> smb, as the merge window is already open and things coming in
<smb> apw, I do bear that in mind a lot
<cooloney> apw: yeah, after 2 weeks later, we will know the status of 3.5 
<ppisati> cooloney: ciao :)
<smb> cooloney, Hm, ok, there seem to be some patches for userns on linux-next right now...
<cooloney> smb: that's good
<cooloney> ppisati: any omap3/omap4 related bug, you need me to take a look?
<ppisati> cooloney: well, nothing special
<ppisati> cooloney: there's one bug that IMO is a user problem (either hw or power supply problem)
<ppisati> cooloney: and then there's another one that's related to the cpu/freq scaling and if i would be in you, i would stay away from that
<ppisati> bug 971091
<ubot2> Launchpad bug 971091 in linux-ti-omap4 "Pandaboard ES freezes with the default CPU scaling governor ondemand" [Medium,Confirmed] https://launchpad.net/bugs/971091
<ppisati> and
<ppisati> bug 994368
<ubot2> Launchpad bug 994368 in linux-ti-omap4 "linux-ti-omap4 kernel panics on pandaboard ES" [Undecided,Incomplete] https://launchpad.net/bugs/994368
<ppisati> if you want to take a look
<ppisati> cooloney: ^
<cooloney> ppisati: thx, looks like it's a long story 
<ppisati> cooloney: yep :)
<apw> apw@dm:~/git2/ubuntu-lucid$ cat /etc/dpkg/dpkg.cfg.d/multiarch
<apw> foreign-architecture i386
<ma1> Hi
<ma1> #uname -r: 3.1.0-1282-omap4
<ma1> I want to compile the ubuntu kernel for the above version on my pandaboard es
<ma1> any step by step guide/tutorial available?
<ppisati> ma1: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
<ppisati> ma1: btw, that's not an ubuntu kernel
 * ppisati -> lunch
<ma1> ppisati: Thanks...but i want to build the kernel natively
<ma1> http://www.omappedia.com/wiki/Ubuntu_kernel_for_OMAP4
<ma1> what about this link???
 * henrix is going out for a drink later today to enjoy the sun!!!
<cking> henrix, that makes me feel thirsty
<henrix> cking: i'm afraid there's only one thing to do...
<cking> buy a beer?
<henrix> :)
<tgardner> you guys gotta stop talking like that. I've barely started my work day.
<henrix> tgardner: heh! it's just that we *do* have sun here, which is something rather unusual :)
<tgardner> my weather is gonna suck for the next few days, but it was nice yesterday.
<tgardner> ogasawara, apw: I see  a new version of kernel-wedge just got uploaded. we'd better try a Quantal rebuild as soon as it propagates in the archive.
<apw> tgardner, sigh
<ogasawara> tgardner: ack
<ogasawara> tgardner: I also uploaded meta, so we should be good to start also uploading to the backports PPA
<tgardner> ogasawara, I saw that
<tgardner> ogasawara, starting a precise backports meta package is on my todo list for the day
<tgardner> or maybe just use the master package and add something...
<ogasawara> hrm, armhf chroot problem.  I've never seen that error before...https://launchpadlibrarian.net/105801887/buildlog_ubuntu-quantal-armhf.linux-meta_3.4.0.3.3_CHROOTWAIT.txt.gz
 * ogasawara will investigate more in 20min
<tgardner> ppisati, just pushed Quantal ti-omap4 Ubuntu-3.4.0-201.2. Y'all should prolly have a look before I upload to make sure I didn't screw the pooch.
<tgardner> perhaps build it and make it still boot.
<tgardner> make sure it still boots*
<jsalisbury> apw, Speaking of builds, is it possible to get the 3.4 and newer mainline builds to use the Quantal kernel config instead of Precise?  If it's something I can learn to do, I'd be more than happy to take it on.
<jsalisbury> apw, it will help with bug 996075
<ubot2> Launchpad bug 996075 in linux "Enable CONFIG_DVB_USB_AZ6007" [Medium,Confirmed] https://launchpad.net/bugs/996075
<jsalisbury> apw, When I say mainline builds, I'm referring to the ones at: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<apw> jsalisbury, ahh yes, thats on my todo, perhaps now is a good time as any
<jsalisbury> apw, no rush if your busy with other stuff
<apw> jsalisbury, its an easy chan ge
<apw> i presume we want to build everything p and later in precise chroots too
<jsalisbury> apw, even q?  in precise chroots?
<apw> we build l->o in lucid chroots cause you might want to test them back to there
<apw> makes the deps simpler when shoveing them on to do bisects on older releases
<apw> jsalisbury, probabally we should be making them actually in both the right release and the lts to which they apply too
<jsalisbury> apw, ah oh.
<jsalisbury> s/oh/ok/
<apw> jsalisbury, ok i have just updated the mainline poop to do things 'right' for quantal (i hope), i have kicked a v3.4 off with the new quantal/precise combo to see what happens, you may wish to see if it resolves that bug when it pops out the other end
<jsalisbury> apw, awesome.  thanks for the help, andy!
<apw> jsalisbury, np
<ogasawara> jsalisbury: for the meeting today, can we add back the section where I nag about work items :)
<jsalisbury> ogasawara, ack
<jsalisbury> ogasawara, Is this the right page to add to the meeting agenda for work items:
<jsalisbury> http://status.ubuntu.com/ubuntu-quantal/milestones.html
<ogasawara> jsalisbury: I'd actually suggest status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team
<ogasawara> jsalisbury: it's more specific to our team
<jsalisbury> ogasawara, ok, I'll make the change
<jsalisbury> ogasawara, What would you like for the Quantal equivilent page for https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Precise
<jsalisbury> ogasawara, this:
<jsalisbury> https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Quantal
<ogasawara> jsalisbury: yah use that, I'll make the page right now
<jsalisbury> ogasawara, cool, thanks
<kees> sweet, sweet API stability. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=259e5e6c75a910f3b5e656151dc602f53f9d7548 upstream PR_SET_NO_NEW_PRIVS will, in fact, continue to match what is in 12.04. *whew*
 * ppisati -> brb
<ogasawara> infinity: we're seeing buildd chroot problems with nihal, eg -> https://launchpad.net/ubuntu/+source/linux-ti-omap4/3.4.0-201.2/+build/3509520/+files/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.4.0-201.2_CHROOTWAIT.txt.gz
<ogasawara> infinity: we've seen this twice now
<jsalisbury> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&
<jsalisbury> field.subscriber=&field.tag=quantal&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.upstream_target=&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_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_n
<jsalisbury> o_blueprints=on
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
 * ppisati run to the gym
<ogasawara> smb: http://status.ubuntu.com/ubuntu-quantal/canonical-kernel-distro-team-quantal-alpha-1.html
<cking> kinda handy to recall what I had to do :-)
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 29th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<ogasawara> smb: I think I missed it when I did my copy and paste for the meeting
<smb> cking, Yeah, exactly the reason I wanted to look at it
<smb> ogasawara, Ah! /me already feared starting blindness
<cking> burndown is hopefully not a synonym for burnout
<cking> somtimes the only east way to fix a problem is with a screwdriver..
<dantti> Hi, I've manually downloaded and installed 3.4 kernel from some mainline url, I have made a patch that went into rc7 but it's not working on the 3.4, is there better place to get new packaged kernels?
<dantti> IÇe also tried the xorg-edgers package but weirdly that doesn`t recognize any kind of hw I have even keyboard...
<dantti> ogasawara: hay you tried your last kernel update? built just finished I installed and nothing worked :P
<ogasawara> dantti: can you be more specific?  I've got it running here just fine.
<ogasawara> dantti: did you make sure you installed the extra's package?
<dantti> ogasawara: hmm sorry, all I saw was some amd microcode errors.. should I install the extra package?
<ogasawara> dantti: with the latest 3.4.0-3.7 upload, the extra's package is necessary 
<dantti> I didn't installed those for the 3.4.0-2 package and it worked
<dantti> ah right that's why the -2 worked
<dantti> I'll install that then, thanks :)
 * henrix is going to enjoy the sun for an hour or so. will be back later...
<ogasawara> henrix: I think you should enjoy the sun for more than an hour and don't come back till tomorrow
<henrix> ogasawara: yeah, but i have only an hour left of sunshine :)
 * cking follows henrix idea
<infinity> ogasawara: Thanks for the heads-up.
<ogasawara> infinity: wasn't sure if it was a known issue.  retrying the builds till they landed elsewhere seems to work around it.
<infinity> ogasawara: It's a known issue.  Machine needs to be rebooted and tidied up.  Unsure precisely what's breaking it, and not keen on debugging it, since they're running natty...
<dantti_laptop> ogasawara: using extra did make the boot detect stuff, but still my patch isn't available there  if I don't see HID_BATTERY_STRENGTH on the /boot/config it means it disabled?
<ogasawara> dantti_laptop: which patch?  and yes, HID_BATTERY_STRENGTH looks to be disabled
<ogasawara> ubuntu-quantal/debian.master/config$ grep -rn "HID_BATTERY_STRENGTH" *
<ogasawara> config.common.ubuntu:2055:# CONFIG_HID_BATTERY_STRENGTH is not set
<dantti_laptop> ogasawara: I've made a patch that probes the battery of hid devices it's upstream since 3.4-r7... can you enable it then?
<dantti_laptop> I thought default would be y
<ogasawara> dantti_laptop: can you file me a quick bug in lp for it and I'll get it on the todo list
<dantti_laptop> ogasawara: ok, thanks :)
<ogasawara> dantti_laptop: looks like the default was n
<ogasawara> config HID_BATTERY_STRENGTH
<ogasawara>         bool
<ogasawara>         depends on HID && POWER_SUPPLY && HID = POWER_SUPPLY
<ogasawara>         default n
<dantti_laptop> hmm right, I'll poke people if it should be y
<ogasawara> dantti_laptop: what's it provide exactly?  not much of a description in the Kconfig
<dantti_laptop> ogasawara: well for example I have an Apple keyboar and magic track pad, both blue tooth and battery operated, this patch provides a power_supply interface to know the battery strength
<dantti_laptop> it should work for all HID devices that conform to the HID standard, but we already have quirks :P
<ogasawara> tgardner: hrm, I think we were a little too aggressive by completely removing the generic-pae meta package.  we still need it, but just need to have it redirect to the generic meta package.  without it we've completely orphaned generic-pae users in Precise from upgrading.
<dantti_laptop> ogasawara: I'm always lost on launchpad, where do I report a new bug? :P
<tgardner> ogasawara,  think thats where update-manager comes into play. we orphaned the -pae flavour on purpose.
<tgardner> ogasawara, I'm still awaiting a response from Michael Vogt. I'll bug him on IRC in the morning.
<ogasawara> tgardner: I though update-manager-core was only handling the package reaping?
<tgardner> ogasawara, nope, the archive handles reaping. update-manager handles upgrades from release to release.
<tgardner> ogasawara, now that you've uploaded the Quantal meta package I can experiment with upgrades from Precise to Quantal.
<ogasawara> tgardner: ack
<tgardner> using the upgrade-manager
<ogasawara> dantti_laptop: run ubuntu-bug linux from a terminal, or alternatively bugs.launchpad.net/ubuntu/+source/linux/+filebug
<ogasawara> dantti_laptop: that's for kernel specific bugs
<dantti_laptop> thanks
<dantti_laptop> ogasawara: done https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003090
<ubot2> Launchpad bug 1003090 in linux "Please enable HID_BATTERY_STRENGTH on xorg-edgers and quantal packages" [Undecided,New]
<dantti_laptop> the cmd line tool complained about the package not being official...
<infinity> tgardner: We don't want logic like this in update-manager, if we can avoid it.
<infinity> tgardner: generic-pae should depend on generic until the next LTS, IMO.
<infinity> tgardner: Special logic in update manager should be seen as a way to work around packaging bugs, not an excuse to not have packages upgrade cleanly.
<tgardner> infinity, what will change at the next LTS ? AFAICT the update-manager will (by default) install the default kernel in the installer iff there is no valid kernel choice.
<infinity> tgardner: Nothing changes at the next LTS, except that we get to reset the upgrade paths we support.
<tgardner> infinity, well, we still have to support LTS->LTS upgrades, and I'd still have the problem of upgrading generic-pae to generic.
<infinity> tgardner: The goal should be for "apt-get dist-upgrade" to actually function.  update-manager/do-release-upgrade can have workarounds for when that's not true, but we shouldn't *expect* to clean up in update-manager when there's a perfectly viable solution at the packaging level.
<tgardner> infinity, everything I've read suggests that the recommended upgrade mechanism is via the upgrade-manager
<infinity> tgardner: Err, yes, which is why I said "until the next LTS".  As in, up to and including 14.04, generic-pae should depend on generic, for smooth upgrades.
<infinity> tgardner: It's the recommended way to upgrade, that doesn't mean ignoring package relationships.
<infinity> tgardner: The less smart update-manager needs to be, the better off we all are.
<tgardner> infinity, lemme experiment with what it actually does.
<infinity> tgardner: I'd rather you experiment with what apt-get does.
<ohsix> upgrade-manager didn't account for the netbook remix upgrades on my netbook a few releases ago, and i only just realized last night that is why it's broken now :P
<tgardner> infinity, I already know what apt-get does.
<infinity> tgardner: Ultimately, update-manager is a thin wrapper around apt, with hacks and workaround for when we screw up.  If we don't screw up, we don't need workarounds.
<infinity> Let me put it differently.  I'll ship a linux-generic-pae-meta myself to smooth the upgrade process if you don't. :P
<infinity> Cause that's saner than upgrade hacks.
<tgardner> infinity, there has to be an elegant way to orphan a package.
<infinity> tgardner: Yes, and in our case, it's on LTS boundaries.
<infinity> tgardner: The kernel isn't a special snowflake here.
<infinity> (We did the same thing with openoffice->libreoffice, with metapackages that lived to upgrade from A to B until precise)
<infinity> Besides, it's only a transitional meta package.  You *are* orphaning the actual kernels.
<tgardner> infinity, I don't see what the LTS boundary has to do with it. I'm still stuck with generic-pae when 14.04 releases.
<infinity> Eh?
<tgardner> the generic-pae meta package still exists. I'm trying to reduce the number of them.
<infinity> No, you have each of linux-*-generic-pae depending on linux-*-generic, and you make all the linux-generic-pae stuff be labelled as transitional packages.
<infinity> You're no longer stuck with the kernel.  You might be stuck with an empty package, but that's a big who cares.
<infinity> (We also have tools that can deal with this, including update-manager itself)
<tgardner> infinity, well, lemme see how transitional works.
<ohsix> from what i understand of how package names are changed, it's basically what infinity is saying, at least in debian
<apw> infinity, a transitional package is just a normal meta type package deping on the replacement, with the text saying its transitional, right?  there is nothing speicial about them is there?
<ohsix> right
<ohsix> and it generally stays there for a "long" time, between the largest expected upgrade distance (like across one release or 3)
<infinity> apw: That's it, yes.  And, in Debian (and we should pick up this convention), they also now live in Section: metapackages, I believe.
<infinity> apw: The key is that they need to exist (in Debian) from stable to stable, and (in Ubuntu) from LTS to LTS.
<infinity> Then you drop 'em like a hot potato, and no one cares.
<infinity> apw: Oh, and the real reason I popped my head in here wasn't to have a hissy fit about metapackages.  It was to ask what's up with the weird diff for -24.39 in your PPA.
<apw> infinity, point me at it
<infinity> apw: AIUI, linux-3.2.0/drivers/ata/ata_piix.c is meant to be the only change, I'm trying to sort out if I should care about what the diff says about linux-3.2.0/arch/x86/kernel/reboot.c, or if that's just some bogon.
<infinity> apw: https://launchpadlibrarian.net/105734948/linux_3.2.0-24.38_3.2.0-24.39.diff.gz
<tgardner> infinity, so, if you have this transitional meta package in 14.04, how can you get away with orphaning it in 14.10? don't you create the same apt upgrade issue as we have currently ?
<apw> infinity, i think we should be not expecting that diff indeed
 * apw will poke as i didn't see it in the git diff
<ohsix> in 14.04 it would install the other package, and in 14.10 it would cease to exist
<infinity> tgardner: No, cause of linux-image-generic-pae depends on linux-image-generic (note, it's the meta depending on the meta), then dropping generic-pae post-14.04 harms nothing, the user is upgraded.
<infinity> s/of/if/
<apw> tgardner, by making linux-image-generic-pae depend on linux-image-generic, we know they have linux-image-generic on their system
<apw> tgardner, so they are good going forward
<tgardner> apw, doh. that makes sense
<apw> tgardner, we likely can do something clever in 14.10 to make linux-image-generic-pae uninstall itself, a Conflicts: or something
<tgardner> ok, I'll update Quantal meta
<apw>  debian.master/changelog                            |   14 +
<apw>  drivers/ata/ata_piix.c                             |    7 +
<ohsix> you could do a conflict, but generally kernels are left behind (there are exclusions in aptitude and stuff for "important" base packages too)
<infinity> apw: The conflict really isn't necessary, but you could do so, if the metapackage really offends you.
<apw> infinity, ^^ ok thats the diff between the two at the git tag level ... wtf
<infinity> apw: Weird.  Could just be debdiff doing something silly.  I can unpack source A and source B and compare the actual files.
<apw> infinity, if you don't mind ... its very odd to my eye
<infinity> (That said, we should have a certain amount of auto-tidying for things that claim to be transitional anyway.  And if that's not working, we should fix it... But either way, it's a few wasted bytes for a smooth upgrade, not a huge deal)
<infinity> apw: Yeah, let me grab the original sources here and see if debdiff's just being brain-dead.
<apw> interdiff impossible; taking evasive action
<apw> any idea what the heck that means in the diff ^^ infinity 
<infinity> Yeah.  Whatever "evasive action" means.
<infinity> I'm as puzzled as you. ;)
<apw> infinity, also does kernel-wedge use random hash order for the control file?  the diff there seems mad too
<infinity> If I had to guess, I'd say maybe your origs don't match, which would mean your diffs don't either.  But I'd like to think you're more careful than that. ;)
 * infinity is checking anyway.
<apw> infinity, you can (no longer) upload with bad orig's can you ?
<infinity> apw: k-w, the way you guys run it, ends up pretty system-dependent.
<infinity> apw: Okay, so the origs are the same.  Weird.  Checking the sources now.
<apw> infinity, i know we managed it in 2.6.24 but only there cause there really were two orig's in the launchpad database by then already
<apw> infinity, and i know smoke poured out of several heads until they editied the db by hand to fix it
<apw> but i thought now it was no longer possible, and we'd even tripped the error on it
<infinity> apw: You can upload to a PPA with any orig you want.
<infinity> apw: Which is where the PPA->archive thing can be a bit of a headache.
<infinity> (In this case, though, it's the correct orig, so I dunno what debdiff is on about)
<infinity> Has the same conniption locally, though.
 * infinity falls asleep waiting for diff -urN.
<infinity> apw: Okay, a proper diff is clean.  This is clearly a bug in debdiff. :P
<apw> infinity, well spotted anyhow
<infinity> apw: Crisis averted.  I'll be accepting this into -proposed for you in a bit, and seeing about fast-tracking the process.
<infinity> apw: Oh, and someone went and created tracking bugs for rebasing derivatives.  That may not be necessary for, say, ARM machines that don't (I'd go so far as to say can't) use that driver. :P
<infinity> s/bugs/tasks/
<apw> infinity, indeed, the derivative people are meant to use their noggings and close them 'invalid' when its not needed
<infinity> Oh.  I didn't realise you expected noggin use.  That's just crazy talk.
<apw> ikepanhc, ppisati, you likely have rebase requests for precise which don't need doing, as its an x86 only fix ... do check before doing it
<infinity> bjf: Let the QA machine roll on that precise SRU.  I'm prepared to fast-track it once some minimal verification and sanity checking is done; see the tracking bug.
<tgardner> ogasawara, please review pushed ubuntu-quantal-meta. infinity convinced me I had my head up my ass.
<ogasawara> tgardner: hehe, ack
<vanhoof> apw: would these have hit armadaxp as well?
<tgardner> ogasawara, I checked that all of the amd64 packages are installable. If you're happy then I think you should package up Quantal meta and upload.
<bjf> apw, infinity would like confirmation that the one commit on the precise kernel in -proposed does indeed do what you expect (don't need to test it tonight)
<ogasawara> tgardner: yep, it looks good here.  I'll get it uploaded.
<infinity> tgardner: Except, weren't the changes to i386 packages? ;)
<infinity> apw: bjf would like you to know that I'm incapable of talking to you directly (I didn't realise you'd be QAing your own upload)
<tgardner> infinity, they were. I suppose I should do the whole test. grumble,
<ogasawara> tgardner: I was gonna test for you.  but if you want to, I won't fight you over it :)
<infinity> tgardner: Eh, if Leann says it looks sane, I believe her.  She's smarter than us.
<tgardner> ogasawara, I;vev got it built. gimme 5 min
<ogasawara> tgardner: ack
<tgardner> ogasawara, tested i386 packages, packaged and uploaded. now I'm really EOD.
<ogasawara> tgardner: sweet, thanks
<apw> infinity, bjf, ok queued for first thing in the am
<bjf> apw, thanks
#ubuntu-kernel 2012-05-23
<smb> morning
<ikepanhc> smb: good morning
 * smb waves to ikepanhc 
<ikepanhc> smb: usually how long it takes you to review config for new flavour?
<ikepanhc> smb: I feel I lose lots of hair these two days
<smb> ikepanhc, I cannot say anything about "usual" as I usually do not add new flavours. But just look at apw who does config reviews a lot... :)
<apw> ikepanhc, new flavour configs suck, i usually use that scripting we discussed before, make the table and see what all goes purple
<ikepanhc> apw: lots go purple....
<smb> breath!
 * ikepanhc tries breathing
<ikepanhc> apw: btw, how is the policy in that script generated?
<apw> ikepanhc, i tend to take whole swathes and shove them over othe top.  like we know that HID all needs to to match so thats easy
<ikepanhc> apw: that will be awesome
<apw> the script implements a policy which is our 'written' policy.  we discuss the policy at UDS each year and then apply it, the script just implements my interpretation of those rules
<ikepanhc> some config, e.g. CONFIG_NET_DSA, policy shows m, but y in all flavour
<apw> with any exceptions documented
<apw> ikepanhc, some of those are indeed wrong still, that one we mentioned at uds and determined we wanted it built-in cause it is a network protocol and we have a standing exception for those
<apw> so that just needs annotating in the tool and i have a WI for that
<ikepanhc> WI? wiki?
<apw> WI == work-item on a blueprint
<apw> ppisati, how does it request it
<ppisati> [ 2267.022766] soc_bind_dai_link::865 dname: snd-soc-dummy-dai lname:omap-hdmi-audio-dai
<ppisati> [ 2267.031005] omap-hdmi-audio omap-hdmi-audio: CPU DAI omap-hdmi-audio-dai not registered
<ppisati> [ 2267.039581] omap-hdmi-audio omap-hdmi-audio: snd_soc_register_card failed (-517)
<ppisati> [ 2267.047515] platform omap-hdmi-audio: Driver omap-hdmi-audio requests probe deferral
<ma1> Hi
<ma1> I am using ubuntu 11.10 on pandaboard es with kernel version 3.1.0-1282-omap
<ma1> i want to recompile the kernel
<ma1> i downloaded the kernel source code using git
<ma1> but the problem is the kernel version is different
<ma1> the kernel version of downloaded code is 3.0.30
<ma1> but i need 3.1.0-1282-omap
<ma1> so, how to get the desired kernel version?
<ogra_> you surely dont use a kernel called -omap on the panda (thats for omap3) 
<ogra_> but rather -omap4 ;)
<ppisati> and we never released a 3.1.x kernel
<ppisati> btw
<ma1> sorry
<ma1> its 3.1.0-1282-omap4
<ppisati> is it a debian packaged or a vanilla kernel?
<ogra_> yeah, i bet that kernel comes from a PPA
<ppisati> in the fist case
<ppisati> fdr debian/rules clean binary-$something
<ppisati> in the second:
<ppisati> make $something_defconfig
<ppisati> make uImage
<ma1> ppisati: ogra_: sorry, i didn't understand
<ma1> i think the 3.1.0-1282-omap4 came from TI PPA
<ogra_> right, so talk to the PPA owners where to find the kernel source ;)
<ogra_> the guys in here only maintain kernels that are in the official ubuntu archive 
<ogra_> the TI PPA kernel is maintained by TI 
<ma1> ogra_: sorry for disturbance...but i am newbie in this area 
<ma1> so lots of mistakes on my side
<ogra_> yeah, its not easy to understand 
<ogra_> well, is it a mistake to not understand an overly complex setup ? 
<ogra_> :)
<ogra_> dont worry ;)
<ma1> orga_: sorry...i didn't got you?
<ma1> ogra_: i will talk to TI PPA owners about the kernel source......can you tell me one thing more???
<ogra_> i said its not a mistake on your side, there are just way to many kernels for omap4 which makes it complex
<ma1> oh...
<ogra_> (there is the TI PPA kernel, then there is a linaro kernel package as well and there is the official package in the ubuntu archive)
<ma1> ogra_: Thanks...just one thing more?
<ogra_> shoot
 * ogra_ will answer if he can :) 
<ma1> I want to recompile the kernel for debugging a buggy kernel module?
<ma1> any suggestions? 
<ma1> like what options should i enable?
<ogra_> for the official kernel there should be a package with debug symbols builtin ... but i have no idea if TI builds such a package
<ma1> as i told you that i am newbie....so really don't know that recompiling a kernel to debug the module is the right way or not?
<ma1> what you say?
<ogra_> not with official ubuntu kernels, there you can just install a ddeb (debug deb package)
<ogra_> these usually have all debugging enabled ... 
<ma1> hmmmm....
<ma1> so i think it is much better to ask this about TI Kernel guys?
<ogra_> ask them if they have a ddeb for their kernel before thinking about recompiling
<ma1> hmmm
<ogra_> that will save you hours :)
<ma1> orga_: Great Great Thanks
<ma1> for your time and help
<ogra_> np :)
 * ppisati -> brb
 * ppisati -> out to get some food
<apw> ogra_, i don't think PPAs buildd ddebs by default
<ogra_> apw, no, but i know that TI was looking for a solution for this
<apw> ogra_, not renaming them to ddeb would work
<ogra_> (hosting a ddeb somewhere else or getting an exception for thier PPA etc)
<cking> bah, overheated again
<apw> ogra_, there is a special in the kernel to move it to .ddeb in the first place, they could just comment that out
<ogra_> well, i'll tell ndec :)
<ogra_> they might even have that package already somewhere
 * cking --> food
<apw> bjf[afk], infinity, i have verified that hyper-v patch and updated the bug to indicate that (good) testing
 * henrix reboots
<tgardner> apw, prolly outghta send out an announcement with that ti-omap4 meta package upload ?
<ogra_> did you break something ?
<tgardner> ogra_, its the first Quantal 3.4 uplaod
<apw> tgardner, ahh those normally go out with the linux-ti-omap4 upload, so i'd assumed it was done
<tgardner> apw, so I don't get that. I think the announcement should go out with the meta package, 'cause tahts when the kernel is actually referenced.
<ogra_> tgardner, well i would say it is expected that we get a newer kernel version with a new dev release 
<tgardner> ogra_, its mostly to let the installer guys know to change the ABI
<ogra_> do you announce the first x86 uploads to a new cycle ?
<ogra_> ah
<tgardner> ogra_, yep
<apw> tgardner, though the announcement is for the installer team as they have to handle the number change and dont use the meta, and for the release team so they know to watch for it and accept it
<tjaalton> hm, overlayfs is not something that's in mainline kernels?
<apw> tjaalton, correct
<tgardner> apw, why isn't the installer build smart enough to use the meta package rather then having to hard code the ABI into the build process ?
<tjaalton> apw: ok, can't sbuild with one then :P
<apw> tjaalton, nope, nor if you were using aufs3 either :)
<apw> tgardner, i have had it explained, but cannot recall
<apw> tgardner, i suspect it has something to do with the udebs and finding them
<tjaalton> apw: just testing if this would fix displayport hangs with ivb, but then I realized there should be a quantal kernel bacport on a ppa already
<tgardner> tjaalton, I uploaded one yesterday to the X backport PPA
<tjaalton> tgardner: indeed, picking it up now
<apw> tjaalton, ahh ... fun :)
<apw> tgardner, all announced up the wazoo
<tgardner> apw, 'tanks
<tgardner> apw, so while our pre-inst test for non-pAE works, its way late in the process. by the time it is detected most of the dist-upgrade has already been performed.
<apw> henrix, how are you generating the contents of the changelog in the lts backports ?
<henrix> apw: they are generated automagically with the update-from-<serie>-master script
<apw> henrix, ok cool
<henrix> apw: i just need to update a few fields after that (bug tracking #, timestamp, )
<tgardner> apw, actually, the changelog is copied from the master branch IIRC
<apw> tgardner, right got it, its not actually a rebase. ... great
<henrix> tgardner: correct, that's why some of the fields need to be updated i believe
<tgardner> henrix, the  release pocket at least
<henrix> tgardner: i believe that's handled by the script, but would need to double check
<tgardner> henrix, yes, it is.
<apw> ah when git cannot figure out you have a common commit of a sensible location you do get a lot of commits
<tgardner> apw, prolly all of them
<apw> 713k of them today
<apw> 400MB worth .. sigh
<tgardner> apw, does that put the hurt on your little bitty laptop ?
<apw> tgardner, my poor link is whining
<tgardner> apw, BT will be cutting you off at any moment
<apw> tgardner, heh luckily i am not with the same people as cking else they would be
<cking> it's not so bad, I just have to share a link with kids and video-on-demand
<cking> at least I will be running at 20Mbit/sec soon ;-)
<tgardner> cking, FIOS ?
<cking> just bog standard cable
<tgardner> cking, huh. the best I get is 15MB down on bog standard cable
<cking> well, they *promise* 20Mbit, but I will see when they upgrade me
<apw> cking, what do you have now, 10?  and what do you get with that?
<cking> apw, 10 all the time until I reach 8GByte of downloads in a day
<apw> they must hate you :)
<cking> that's the bonus of living in the sticks
 * apw wonders if he can download that much in a day
 * cking sends apw a magnetic tape full of downloads by FedEx
<apw> cking, in theory i can get the 80Mb service from infinity
<cking> that would be nice
<ogasawara> tgardner: have you shared with QA about the q kernel is ready for testing in the backports PPA?
<ogasawara> tgardner: if not, I will
<cking> apw, pity your wifi is so clogged up in your neighbourhood
<tgardner> ogasawara, not yet. it had not finished building when I left for the day yesterday.
<tgardner> ogasawara, I did let bryce know
<apw> cking, yeah i'd finally be unable to saturate my link over wifi
<tgardner> ogasawara, I need to bug apw to get it into the daily upload process.
<cking> apw, you need to relocate your office
 * apw listens to the cops chase some crims using a copter ... damn they are noisy
<cking> or get some wifi proof wallpaper
<apw> henrix, ok i have no tag in the master repo for the previous release Ubuntu-lts-2.6.38-15.59 release ... any idea what happened there ?
<henrix> apw: hmm... let me check
<apw> henrix, perhaps whoever looked it over failed to make one ?
<henrix> apw: most likely :)
<apw> can you add it to your checklist to check that it gets made by whoever in the future
<henrix> apw: that's odd... i do have that tag
<apw> henrix, you have the tag ?
<henrix> apw: yep
<apw> who made it
<henrix> apw: have you git fetch --tags ?
<apw> yes but only from origin
<tgardner> henrix, maybe you forgot to push it ?
<apw> tgardner, he can't push it, someone has to pull his changes
<tgardner> apw, oh, right. I did that on purpose didn't I ?
<henrix> heh
<apw> yep this is working well, means we review things, and i am sure i'll get bored soon enough
<apw> hense i have noticed the missing tag for the prev one
<apw> henrix, so did you make the tag you have or someone else
<apw> henrix, i'd expect whoever pushed it in to have signed the tag
<herton> apw, I pushed it I think, it should be there, let me check
<henrix> apw: i usually tag it, push it into my tree and my sponsor will push the tag to main repo
<tgardner> henrix, herton or bjf doing that ?
 * apw feels that actually as there is no other trail of the approval that the approver should sign the tag
<henrix> tgardner: well, most of the times herton... but need to check specifically that one :)
<apw> but either way it isn't upstream right now in the repo as far as i can see
<herton> tgardner, apw, yep, not tagged. I'm not sure now who pushed it
<apw> herton, ok will sort it out using his tag
<tgardner> apw, hmm, I thought we _had_ to sign the tags lest the check scripts kick it back.
<apw> once git has lost it mind and downloaded 100M to give me his tag
<apw> we can't push unsigned tags, but no tags
<apw> they arn't detected
<tgardner> apw, we can likely enforce that in a maintenance script somewhere.
<apw> tgardner, herton, i expect shankbot can tell if there is no tag for the upload and refer the source task back to the creator
<henrix> tgardner: or on the git hooks, when pushing into master...?
<apw> henrix, yeah we might be able to get that to work too, though then you'd have to do them in the right order
<tgardner> henrix, as apw pointed out, its difficult for the git hooks to detect that lack of tag, signed or not.
 * apw quite likes shankbot not moving things to -proposed if its missing
<herton> apw, right now the prepare task is a manual process on the tracking bug, not sure if shank bot would be the better place for a check, but could be done
<apw> herton, well the promote to proposed task waits for it to build etc, it could also wait for the tag as well
<apw> "tag found waiting on binaries" "binaries found waiting on tag"
<apw> or somethign
<herton> yes, that would be ok too
<tgardner> herton, we'll trust your judgment on that, but it seems like a test that should be performed somewhere.
<apw> the worry here for instnace is if i hadn't 
<apw> noticed it, we would have lost the head, as it is a rebase head and i am about to slam over it
<tgardner> yeah, the next garbage collect cycle would have lost it irrevocably
<ogra_> tgardner, apw, is it intentional that we only build the omap4 kernel for armhf ?
<ogra_> https://launchpad.net/ubuntu/quantal/+source/linux-ti-omap4/3.4.0-201.2 doesnt show an armel build
<apw> i thought we didn't support armel for q any more
<tgardner> ogra_, I thought we were dropping armel for Quantal ?
<ogra_> not decided yet 
<herton> apw, tgardner: before we push, we have a script that checks for some things, with the missing tag, I guess it was forgotten to be run (kteam-tools/maintscripts/verify-release-ready)
<ogra_> and if we keep it we indeed want a kernel 
<herton> *s/with/like
<apw> ogra_, well then someone needs to communicate better, as it was off until the decision as i'd heard
<tgardner> ogra_, so what is the story for armel in Quantal ?
<ogra_> see the other channel
<apw> tgardner, either way though i think we have made some armel meta-packages with no binaries
<tgardner> apw, hmm, maybe.
<herton> nm, the script will not check if things were not pushed... I'll try to add a check to shank bot
<henrix> apw: since you'll be pushing into natty lts, can you please add the missing tag?
<apw> henrix, oh i am working on it feaverishly
<apw> just git keeps thinking that 300M of stuff is new each time
<henrix> apw: heh
<apw> henrix, ok ... pushed both tags and pushed the lts-backport-natty branch too (all for lucid of course)
<henrix> apw: ack, thanks. will build the src pkgs in a minute
<apw> tgardner, do we use the 'abi-*' files in /boot for anything else other than the abi comparions ?
<tgardner> apw, not even sure we use 'em then. I think they are purely informational AFAIK
<apw> tgardner, well i think thats where we pull 'em to get them into the repo, ok
<tgardner> apw, perhaps for dkms builds ?
<apw> tgardner, don't think i've ever seen anything reference them
<apw> tgardner, just wondered ... cool ...
<tgardner> apw, neither have I
 * apw wonders how long his firewall will survive at the current 52c its running at
<apw> perhaps putting my machines at the top of the shelves is not the best idea
 * apw gets it down to 47 by standing the machine upright
<ogra_> open a window !
<ogra_> and the door :) 
 * dileks has a cold but tries to aspirates some air through IRC... pfff pfff
 * ogasawara back in 20
<apw> ogasawara, everything is already oen
<ogra_> dileks, OMG ... use a virus scanner please !
<cking> apw, put it in the fridge
<dileks> ogra_: hehe
<apw> cking, cables arn't long enough sadly
<cking> apw, move the fridge then ;-)
<ogra_> ++
<apw> its builtin to the kitche
<apw> its builtin to the kitchen
<cking> move the kitchen then
<ogra_> ++
<apw> hmmmm
<cking> simple
<apw> *slap*
<cking> owhc
<cking> alternatively relocate to a nice cool pub
<apw> oh oh oh, yes
<apw> damn the wires don't reach that far either
<ogra_> buy wireless wires then
<apw> i am already being zapped by three APs
<dileks> any ventilator in the house?
<apw> i may have to add fannage
<ogra_> to wind up the cables ?
<cking> put a bag of frozen peas on the firewall
<apw> one of those freezer packs might work
<cking> passive cooling win
<jsalisbury> Just shut it off, the Internet is a safe place now a days
<apw> jsalisbury, who the heck do you work for really :)
<jsalisbury> heh
<cking> I suspect he uses windows ;-)
<apw> ha one of _those_
<jsalisbury> windows, nah, os/2
<cking> half decent OS then
<apw> cking, i don't know abuot my firewall, but shoving the freezer block up my jumper has improved my mood
<cking> glad you shoved it up there rather than somewhere else
<apw> *slap*
 * cking wonders why apw is wearing a wolly jumper in the summer heat
<apw> knew you'd say that
<apw> i should have said my geeky t-shirt
<apw> its having a nice cooling effectg anyhow, well recommended
<cking> until the skin peels off with frost damage
<apw> cking, looks like raising the front of the machine by 2in has improved cooling a lot
<cking> amazing what a bit of air flow can do
<henrix> anyone with a few idle cycles to give some suggestion on bug #1003309 ?
<ubot2> Launchpad bug 1003309 in linux "Boot fails after installing updates, error: âcryptsetup: evms_activate is not available"" [High,Confirmed] https://launchpad.net/bugs/1003309
<henrix> it looks like some initramfs thing, not a kernel issue
 * henrix may be wrong
<apw> henrix, ok
<apw> henrix, so ... when they installed the new kernel the initramfs would have been built then, the initramfs for the older kernel would have been built when it was installed most likely
<apw> so if any of the tools which are in there such as encryption stuff it would be older, so it could also be a
<apw> bug in ecryptfs-tools as well
 * smb grumbles over the installers idea to select every single piece of storage looking like swap as a desired target for a swap partition...
<apw> we cuold prove that by rebuilding the old initramfs but would likely kill their good kernel
<henrix> apw: yeah, it could be
<henrix> hmm... right. so, he would need to boot from a CD, manually decrypt the fs and install the old version
<smb> noo, please update-grub, don't add an entry for every single vm I have on that server...
 * cking thinks smb is having a bad install day
<smb> cking, I fear that will be repeatable everytime I will try to have an additional install on that... Unfortunately the whole installation does not only detect the contents of partitions but also those of the disk images placed into LVs... argl
<cking> that's a fail
<smb> The listing of "other" OSes in grub seem to be 10 pages...
<tgardner> ogasawara, just tested generic-pae -> generic precise to quantal dist-upgrade. appears to work fine.
<apw> anyone remember who it was who has the Pulsbough, the one with the handoff problems ?
<tgardner> apw, bug vanhoof
<vanhoof> tgardner: =P
<vanhoof> apw: I believe that bug impacts older machine and not the newer ones we've been working with
<apw> vanhoof, so 1) do you have a amchine with the issue you could test a package, 2) can you tell me which PCI ids are and are not affected ?
<vanhoof> 1) don't believe so, 2) sure
<vanhoof> apw: i'll check quickly, I may have been thinking about another bug 
<vanhoof> apw: gimme a few
<ogasawara> tgardner: nice
<apw> smb, how do you update your -source chroots?  got a script or something, or a link to one?
<smb> apw, not yet a script. working on it (to exclude non-srource) but got distracted
<smb> apw, If you go the other way round (saying I know which ones there should be) there was something on the wiki posted
<smb> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
<Eimann> https://eimann.etherkiller.de/nmz/gre-tunnel
<Eimann>     1 root      20   0  128m 106m 1308 R   81  1.4   4:58.36 init
<Eimann> fun :)
<apw> Eimann, are those related ?
<Eimann> yes
<Eimann> 60% sys-time (20% on each core)
<Eimann> I expected more havoc ;)
<apw> heh not supprised
<apw> just how many tunnels do you have there, and am i reading this right that you are pointing them all at yourself ?
<smb> bjf, FWIW, the 3.2.0-24.39 kernel came up on a kvm vm with emulated disk
<bjf> smb, thanks
<tgardner> bjf, also works fine on my Lenovo x120e
<bjf> tgardner: thanks
<ikepanhc> bjf: around?
<bjf> ikepanhc: yup
<ikepanhc> bjf: I saw a proposed kernel uploaded, this week is kernel prep?
<ikepanhc> bjf: checked Ubuntu kernel schedule, it says regression testing and on wiki.u.c/QQInterlock, it says kernel prep.
<bjf> ikepanhc: yes, you can ignore that. it's a kernel with just a single commit in it which won't matter to you. we will have a kernel with a larger set of commits soonish
<bjf> ikepanhc: this is a kernel prep week
<bjf> ikepanhc: the start of our next cycle
<cking> bjf, boot-test works on a Lenovo x220i with btrfs
<bjf> cking: thanks
<cking> bjf, any more kind of tests required?
<ikepanhc> bjf: so, for next sru cycle, when will the proposed tag be made?
<bjf> cking, not at this time
<ikepanhc> bjf: I need to draw a deadline for highbank enablement patch
<tgardner> ikepanhc, its in master-next, so itl go up in the next cycle
<tgardner> it'll*
<bjf> ikepanhc: i'm trying to get the 3.2.0-24.39 Precise kernel out of proposed asap. i've just asked henrix to start turning the crank on the next Proposed. 
<bjf> ikepanhc: the git repo should be ready in a few hrs.
<ikepanhc> tgardner: understood. I would like to check more before first highbank deb built
<tgardner> ikepanhc, so you don't _know_ that what you sent me was correct ?
<ikepanhc> tgardner: that's correct
<ikepanhc> tgardner: but I am not 100% sure after config changed
<tgardner> ikepanhc, well, thats kind of a fail. are you gonna be able to test that before the next upload ?
<ikepanhc> tgardner: that's why I am asking when is next upload
<ikepanhc> tgardner: to be precise, the patch in master-next is fine and the config has been reviewed by calxeda engineer, I've built it and it runs well.
<tgardner> ikepanhc, well then, whats the issue ?
<tgardner> it sounds like what you send _is_ correct.
<tgardner> sent*
<ikepanhc> but the highbank config in master-next disable lots of function and cause config.common.ubuntu reduce length by 500 lines
<ikepanhc> so I tried to re-enable those non-SoC related function
<ikepanhc> I am not 100% sure on that re-enabling
<Eimann> apw: this will be ~20k Tunnels between a Cisco ASR Router and a linux machine, and this two times
<tgardner> ikepanhc, but you haven't sent that patch yet. the configs that are currently in master-next are what is gonna get tested.
<Eimann> I'm trying to figure out how many mGRE and GRE tunnel the ASR can handle
<ikepanhc> tgardner: that's correct
<tgardner> ikepanhc, or rather, you sent the patch but told me not to pull it.
<ikepanhc> tgardner: so, I wonder if I have time to verify it and send it
<tgardner> ikepanhc, so, you've got time. you can always send another patch in a week or 2 ...
<tgardner> ikepanhc, I suggest we go with what we know works right now. you can consolidate the configs later.
<ikepanhc> tgardner: ACK
<ikepanhc> sounds a fine plan for me
 * apw reboots for a new kernel
 * cking grabs some more food, back in a short while
<apw> tgardner, this 
<tgardner> apw, sentence fragment ?
<apw> tgardner, this kernel, i assume you want it rebuilt and uploaded whenever we tag quantal ?
<tgardner> apw, ack
<apw> bjf, argle, this is a new install and doesn't have -propposed enabled ...
 * apw tries that atgain
<apw> bjf, apw@dm:~$ cat /proc/version_signature 
<apw> Ubuntu 3.2.0-24.39-generic 3.2.16
<apw> everything looksing fine here other than my typing
<bjf> apw, cool, thanks
<cking> tyhicks, I've sent you the ecryptfs benchmarks with a forward port of that chromium patch set
<kirkland> cking: is that helping?
<cking> oh yeah, I'll cc you too
<cking> sent
<kirkland> cking: thx
<cking> kirkland, I'll do more rigorous testing on friday
<cking> I suspect real I/O will swamp the savings, but we will reduce CPU load, which is a win
<tyhicks> cking: Did this round of testing include your hack to always force the use of "__driver-cbc-aes-aesni"?
<cking> tyhicks, nope, no dirty hacks
<cking> I need to see what encypt core is used to sanity check this, so that will take a little bit more effort
<cking> ..and I'd like to thoroughly soak test this patch as it is quite a change
<tyhicks> cking: Ah, ok. So that somewhat explains the lack of difference between aes-ni and aes-generic in the test results.
<tyhicks> cking: Yeah, it scared me. Which is why I was always waiting to see actual performance improvements before I even considered it.
<cking> tyhicks, I think so, however the sub 2 TSC ticks per byte is quite an improvement
<cking> anyhow, I'm going to mull over this and get back to some digging to see if we can shave some more cycles off (if we are not using the correct AES-NI path) on friday
<tyhicks> cking: Right. So between the async patch and correcting the AES-NI issue, eCryptfs may see a huge performance boost.
<tyhicks> cking: Nice job!
<cking> well, if not, just with this patch it seems to be a big win that needs to be now thoroughly soak tested
<cking> anyhow, /me is calling it a day
<tyhicks> bye cking!
<henrix> tgardner: i am currently working on precise linux-meta pkg. have you referred something about checking/testing your changes on this package some time ago?
<henrix> tgardner: do you remember anything about this?
<tgardner> henrix, I'm not really understanding your question. are you wondering about the highbank additions ?
<henrix> tgardner: well, actually herton told me he remember you had some concerns about some changes you made
<henrix> tgardner: so, i'm not sure if that's about the highbank :)
<herton> tgardner, henrix, it has the hwe and current new meta, I took a look now too and seems ok
<tgardner> henrix, not that I can remember. I'm usually gloriously ignorant of any mistakes that I've made.
<henrix> heh
<tgardner> henrix, I've recently added highbank and the hwe meta packages.
<henrix> tgardner: right, so i took a look and i seems fine to me as well.
<henrix> tgardner: thanks
<bjf> jsalisbury: what is the correct url for the reports on cranberry?
<jsalisbury> bjf: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/index.html
<bjf> jsalisbury: thanks, that was confusing, went to http://reports.qa.ubuntu.com and that wasn't where i wanted to be
<jsalisbury> bjf, hmm, seems there is no way to navigate to our reports from http://reports.qa.ubuntu.com
<bjf> jsalisbury: is that something you feel like working on with ursinha?
<jsalisbury> bjf, sure, I'll ping her about it
<bjf> jsalisbury: maybe it's fodder for the arsenal mailing list
<jsalisbury> bjf, good thinking ;-)
 * tgardner -> EOD
<jjohansen> sconklin: so I picked up the change for CVE-2010-2525, however CVE-2011-4086, and CVE-2012-1090, want to go from released (2.6.38-15.59~lucid1) to pending (2.6.38-15.59~lucid1) which is wrong since 2.6.38-15.59~lucid1 is the currently released kernel
<ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2525)
<ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4086)
<ubot2> jjohansen: The cifs_lookup function in fs/cifs/dir.c in the Linux kernel before 3.2.10 allows local users to cause a denial of service (OOPS) via attempted access to a special file, as demonstrated by a FIFO. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1090)
<jjohansen> I have reversed those changes, but I think you are going to have to update them in your tree as well
<sconklin> jjohansen: ok, thanks
#ubuntu-kernel 2012-05-24
<goldphish> Any Ubuntu kernel people around that could take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911064 ?
<ubot2> Launchpad bug 911064 in linux "Apple Bluetooth Keyboard Fn key not working" [Medium,Triaged]
<goldphish> That bug had been open for a very long time and has a rather simple fix. You just need to patch a commit from 3.3 or 3.4 into Ubuntu's 3.2 tree.
<RAOF> goldphish: Has that patch gone to -stable?
<goldphish> The patch mentioned in bug 942184 was for an older 2.6.x kernel. The commits I reference in comment #25 are in mainline trees but for 3.3.x and 3.4.x series kernels.
<ubot2> Launchpad bug 942184 in linux "The Fn key of my Apple keyboard doesn't work" [Medium,Fix released] https://launchpad.net/bugs/942184
<goldphish> mainline 3.2.x kernels do not have the commits backported
<RAOF> The reason I ask is that anything that gets sent to the 3.2 stable kernel will get folded into the Ubuntu kernel (pretty much) automatically. Is there a reason it *hasn't* gone to 3.2 stable?
<goldphish> I'm guessing nobody has bothered to submit a duplicate patch.
<goldphish> I'm not familiar with the backporting process or I would initiate that route.
<goldphish> Reading the code I can't see any reason why it would not work.
<RAOF> Generally when there's a small patch that fixes a bug it gets CCd: to stable, and the stable kernel process picks it up.
<goldphish> Hmm not sure why the original contributors did not do that. 
<goldphish> It doesn't feel right for me to copy their work and submit to 3.2 stable
<RAOF> No, that's perfectly fine. You don't claim its your own work, just that it's (a) safe, and (b) should be fixed in stable. See also https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
<goldphish> oh nice, that doc is very helpful!
<goldphish> Sadly my google searching for ubuntu kernel processes did not turn that up :/
<RAOF> âsite:wiki.ubuntu.com kernel devâ should get you useful pages pretty quickly.
<goldphish> indeed will do that next time :-)
<goldphish> So I'll prepare a patch, submit upstream and update the existing bug.
<RAOF> That would be a good way to proceed.
<goldphish> thanks
<ppisati> moin
<ppisati> http://www.engadget.com/2012/05/22/via-technologies-outs-49-apc-android-barebones/
<ppisati> another inexpensive arm board
<ppisati> unfortunately it's an armv6 chip
<yo> hola
<cooloney> ppisati: is that armv6, i assume it is an x86 board
<_ruben> it's arm iirc
<tjaalton> the quantal backport kenrel to precise hangs immediately after X has started, mainline 3.4 works fine
<tjaalton> this on ivybridge
<tjaalton> but the quantal one should be based on v3.4 as well, so wondering how that's possible
<RAOF> tjaalton: The main quantal kernel works fine on my ivybridge, but that's not the backport kernel.
 * smb is tired
<tjaalton> RAOF: hmm, ok
<RAOF> Possibly toolchain fun?
<tjaalton> could be
<tjaalton> oh, i've got quantal mirrored locally.. i'll just try that one then :)
<tjaalton> nah, hung with that one too.. the lightdm login prompt cursor was blinking, mouse & keyboard didn't work but was able to ssh in. nothing suspicious, then it hung after a minute or so..
<tjaalton> and why the heck is it using vesa
<tjaalton> the hang is probably related to vesafb then, stopped lightdm and it's working fine so far
<tjaalton> mainline 3.4 gets drm set up normally
<tjaalton> duh, hung with that one too
<RAOF> Ah. Well, then.
<tjaalton> trying 3.3.7 next
<jpds> http://people.canonical.com/~jpds/64-bit_x68_kernel.png
<jpds> Is that 64-bit x86 PAE kernel a known typo issue?
<jpds> bug #992414, I see.
<ubot2> Launchpad bug 992414 in linux "linux-image-* package title and descriptions have packagers architecture rather than the contained architecture" [Medium,Fix committed] https://launchpad.net/bugs/992414
<tjaalton> 3.3.7 is fine, but i want my overlayfs :)
 * apw yawns
 * apw watches his firewall upgrade ... while routing his traffic
<smb> bzz
<apw> yean, i didn't consider that during upgrades one might want to use the thing, nor did i consider the number of hours it would take
<apw> and its not the fastest box in the world either
<smb> Very true, it is amazing it works. I think I have to do the same but wanted to do it during the weekend.
 * apw notes google won out on the patent infringment case with oracle
<smb> We should trademark "patent infringement"... 
 * smb wonders: how many months will it take for is, until they have fixed gomeisa...?
<apw> man
<smb> Guess, the answer my friend is blowing through rt...
<jk-> heh
<apw> smb, i've jollied the rt along we shall see
 * apw notes he has finished his router upgrade and rebooted, and well i am still here
<smb> apw, Thanks and congrats :)
<henrix> doh
<henrix> i just realised i dput'ed a precise package with -u kernelteam:lucid :-/
<apw> henrix, ok that is probabally very bad
<henrix> apw: yeah, probably it was a bad idea...
<henrix> apw: i realised that because it failed to build
<apw> if my experience is anything to go by we may have to delete the ppa and recreate it to allow us to upload lucid again
<apw> which package is it
<henrix> linux-backports-modules-3.2.0_3.2.0-25.9
<apw> that said it is more recoverable than if you had done that to the archive itself, thats fatal forever
<henrix> who shall i ping to help me sort that out?
<apw> henrix, looking now ... i think we may have been lucky cause its LBM
<apw> cause it is a version specific package so i think i can just delete it 
 * henrix is surprised the impact of that is *that* bad!
<apw> well if you upload a higher version of a package the version number can never go down
<henrix> hmm... i see the problem
<apw> so if you'd made this mistake with linux then we'd never be able to upload linux at a lower version number than the error version again
<henrix> yeah, got it
<apw> but as its lbm its linux-backports-modules-3.2.0 so actually even if the PPA remembers we likely don't care
<apw> you may find you cannot upload it into precise either though, but lets first delete the erroring one
<henrix> so, after sorting out this mess my next task will be to write a script that makes sure uploads will go always to the correct place!
<henrix> and stop using dput directly :)
<apw> henrix, its an annoying issue as normally you let the dput use whats in the package but there are no -proposed pockets in PPAs hense you need to type it, hense you can mess it up
<apw> henrix, ok i've removed the bad pacakge, it takes a full publisher run to clear out
<apw> then you may or may not be able to upload the package you have into precise.  it may claim the version number is already present.  but we'll worry about that if it happens
<henrix> apw: ok, thanks. will try to upload it again later on
<Caribou> apw: howdy : any reason why the -dbgsym packages would suddently disappear from http://ddebs.ubuntu.com/pool/main/l/linux/
<apw> give it half an hour and then see
<henrix> apw: ack
<apw> Caribou, they are removed from there 14 days after the package in the main archive is deleted
<Caribou> I found the pristine Natty kernel there last week (2.6.38-8-server #42)
<Caribou> apw: ^
<apw> Caribou, right, thats still in the archive
<apw> Caribou, becasue its in the -release pocket, so its still held in the pool, and so the ddebs are held also
<apw> Caribou, i thought arges was already mirroring these cause of this behaviour
<Caribou> apw: yes, but unless I'm blind, they are no longer there : http://ddebs.ubuntu.com/pool/main/l/linux/
<Caribou> apw: I'm working on this with arges
<apw> ok which version are you looking for which isn't there ?
<Caribou> apw: 2.6.38-8-server
<diwic> Caribou, hmm, I think there was a UDS session about the ddebs, where they said they deleted some ddebs to free up disk space
<diwic> Caribou, but I don't know how the selection was made
<Caribou> diwic: I hope not
<diwic> or don't remember, rather
<apw> diwic, hmmm ...
<apw> Caribou, hmmm, i concur it seems to be gone, asking pitti now if they have done something different or its 
<apw> whether its broken
<Caribou> apw: I'm sure it was there last week, I got a copy from there
<apw> Caribou, ok they ran out of space and nuked them
<Caribou> apw: luckily, I still have the extracted ddeb on a local machine
<apw> its not clear what use hte ddeb from a natty -release kernel is, as noone in their right mind should need it
<apw> but yes, it was that or lose the latest ones for the latest kernels it seems
<apw> cooloney, smb, vv
<apw>     Pull user namespace enhancements from Eric Biederman:
<apw>      "This is a course correction for the user namespace, so that we can
<apw>       reach an inexpensive, maintainable, and reasonably complete
<apw>       implementation.
<apw>     
<cooloney> apw: hmmm, not sure about what's the enhancements from Eric.
<cooloney> apw: any URL or email? smb told me some of Eric's patch were landed in linux-next
<apw> cooloney, this is in linus master tree, merged overnight by the looks of it
<apw> the beginning is worrying
<apw>       Highlights:
<apw>        - Config guards make it impossible to enable the user namespace and
<apw>          code that has not been converted to be user namespace safe.
<apw> in my version of english that implies usernamespaces are broken and off
<apw> lets hope thats not what it means
<apw> /git2/linux$ git log --oneline dd775ae2549217d3ae09363e3edb305d0fa19928..4b06a81 | wc -l
<apw> 46
<apw> smb, can you remember how many patches we were seeing in the userns branch serge was pointing us at ? ^^
<cooloney> apw: does that mean new kernel with the patches from Eric will break our userspace namespace?
<apw> cooloney, to be honest i have no idea, his english isn't very accurate so i cannot fathom the meaning with cirtainty
<apw> i am suspecting i am going to be asking you and smb to work that out sharpish :)
<apw> cooloney, i think he is saying that the bits which arn't converted will be impossible to turn on or build, but i am not clear
<cooloney> apw: no problem. i can dig into it
<cooloney> thanks for pointing out this
<cooloney> you know merging window sometime is crazy
<apw> cooloney, and it may not be complete yet, as in there may be more to merge sometimes they do that
<apw> though it does sound about the size he was suggesting might be merged in 3.5
<cooloney> apw: totally 46 patches
<apw> yeah so about 1/3rd if my memory is complete
<apw> bjf, hey i see your PPA is nearly full ... i assume we can always delete the 'newer version available' ones right ?
<apw> diwic, henrix is having terrible trouble with mumble, with pulse
<apw> diwic, oh typically he has sorted himself perhaps
<diwic> apw, for the wrong device being selected, did you try mumble from my ppa?
<apw> i did some time back and i seem to remember it didn't change anything
<apw> or was there a second attempt ?
<diwic> apw, well, there was one bug in g-c-c and one in mumble, IIRC. And the g-c-c one should be fixed by now
<henrix> diwic: i may try that ppa actually 
<apw> diwic, oh yeah there was the volumn not beeing tracked right on mics, that is deffo fixed
<diwic> henrix, if your problem is that you select "default device" in mumble, and it does not update when you select a default device in the sound settings, that's what it's supposed to help against
<apw> diwic, and there was the mumble using default device, but i tried your PPA for that and it didn't work
<apw> as in it was still wrong, though i have mumble bolted to my snowball now
<apw> so i don't notice it
<diwic> apw, did you test it with the latest g-c-c that was released nine  days ago into precise-updates?
<diwic> 1:3.4.1-0ubuntu2 to be exact
<apw> henrix, i so need the system to know that the d in your name is optional
<henrix> apw: what you mean by 'd'?
<henrix> ouch! just took a look at the new bugs, and it looks like there's something really bad going on on initramfs generation
<apw> henrix, hendrix is what my fingers type when i type your name ... call me old
<apw> henrix, on the 24 hours jobbie ?
<henrix> apw: ah! right! :D
<henrix> apw: yep, the 24 hours thingy
<apw> henrix, this may not be a new issue more than a lot of people upgrading right now of course
<apw> dammit why does it report bugs in the native language ... 
<henrix> true. but it does look like these reports were already running precise
<smb> apw, There were many... 30 ... 46 all is many to me
<smb> apw, And yeah we will find out at some point
<smb> apw, And I believe deletion in the ppa is a manual job
<apw> smb, yeah its manual, and i am pretty sure we don't need 'em in there either
<smb> No anything superseded in any way is rather useless
<Caribou> apw: any luck with rebuilding natty's dbgsym pkg ?
<smb> deleting can be a pain as you need to not exceed too many in one request
<Caribou> apw: I have a copy of the other one, so no rush, just so I can test yours
<apw> Caribou, actually yes
<Caribou> apw: want me to test it ?
<apw> Caribou, just copying them now, this is not quick
<apw> Caribou, http://people.canonical.com/~apw/ddeb/
<apw> tgardner, can you add a WI to the backports thingy for me to get that automation done
<tgardner> apw, there is a backports thingy ?
<apw> security-q-kernel-backports
 * apw saw you updating it
<tgardner> ah, taht one. too many blueprints
<Caribou> apw: got the one I needed
<apw> Caribou, ok cool ... let me know if they work as i can then make you any others you need i guess
<Caribou> apw: works fine ! just complain about kernel version diffs but nothing to worry about
<Caribou> apw: this one in particular was a problem. I was able to rebuild the -14 myself.
<Caribou> I'll work with arges to build a local mirror
<Caribou> apw: thanks for your help, at least now I know that I wasn't doing something wrong when I tried to build it
<arges> apw, Caribou what happened with the build?
<Caribou> arges: looks like apw was able to fix things
<tgardner> apw, this one ? https://blueprints.launchpad.net/ubuntu/+spec/security-q-kernel-backports - I don't think its the right one for an automation WI.
<apw> Caribou, yeah that was definatly a "kernel version running on the build system" error
<apw> tgardner, ok ... erm perhaps just shove it on the versions and flavours then, just so i don't forget
<tgardner> apw, yeah, that one is more like it
<apw> arges, yuo can't build the very early natty kernels on a machine running 3.x the make fails
 * apw waits to find out if Caribou can use the rebuilt ddeb or not, useful to know if they are regeneable
<Caribou> apw: yes it works fine, I think you missed me mentioning it
<arges> apw, i though the builds were done in a fakeroot
<arges> but i guess the kernel version would be the same still
<Caribou> apw: crash just complains about version discrepancy but nothing to worry about
<apw> Caribou, ahh yes i should have built it without a version suffix, silly me
 * apw will likely rebuild and get you to retest, just so i have the process down pat
<Caribou> apw: it's not a problem really. actually, I prefer it that way
<apw> oh ok, then i wont :)
<tgardner> apw, added to https://blueprints.launchpad.net/ubuntu/+spec/hardware-q-kernel-version-and-flavors
<apw> tgardner, thanks
<Caribou> apw: this way we can know if they were 'rebuilt' or coming from the original build
<apw> Caribou, yeah a point indeed
<apw> Caribou, is there any others you need while i am in the process ?
<arges> apw, are you just building from scratch or using scripts?
<Caribou> apw: no, all the crashes I have are from the same kernel, thanks
<Caribou> apw: but yeah, might be a good idea to tell arges how you did it, in case we need to rebuild some later
<apw> arges, just doing a full build on our builders so i get ddebs and udebs
<apw> arges, so literally just building using 'full_build=true' on the command line
<arges> gotcha
<apw> its good to know they are at least vagluly usable when made that way
<Caribou> apw: I would have been surprised of the contrary : I spent hours rebuilding SLES9 kernels because SuSE never made the debuginfo kernels available
<apw> Caribou, i would have hoped, and even assumed they would be, but knowing is so much nicer
<Caribou> apw: :)
<Caribou> apw: arges now back to trying to identify the KSM corruption
<dileks> hi
<dileks> if I rebuild a package destinated for quantal on a precise host, to which distribution I shall assign it? precise | precise-proposed | precise-backports | etc.?
<tgardner> dileks, it hardly makes any difference unless you intend to upload it to a PPA
<jsalisbury> tgardner, Is someone free to take a look at bug 1003793
<ubot2> Launchpad bug 1003793 in linux "broadcom wireless does not work with quantal-backport-kernel" [High,Confirmed] https://launchpad.net/bugs/1003793
<tgardner> jsalisbury, hmm, seems like a dkms issue.
<jsalisbury> tgardner, I added it to the hot list due to the "Reported by"
<tgardner> jsalisbury, I happen to have the same HW. lemme explore it a bit.
<jsalisbury> tgardner, cool, thanks!
 * ppisati -> brb
 * apw finds his dhcp server got deconfigured on upgrade
<apw> so everything broken an hour after
<apw> bug #1003971
<ubot2> Launchpad bug 1003971 in isc-dhcp "on upgrade lucid -> precise /etc/default/isc-dhcp-server is not migrated" [Undecided,New] https://launchpad.net/bugs/1003971
<tgardner> apw, that seems pretty  serious
<apw> tgardner, yeah, a point, will bring it up on #ubuntu-server
<apw> i assume we want these sorts of things resolved for .1
<tgardner> apw, you'd think so
<tgardner> apw, maybe you should target that milestone lest skaet miss it.
<apw> tgardner, done ... so
<apw> hmmm it went confirmed already someone metoo'd it
 * ogasawara back in 20
 * apw notes that we are now anonymising ipv6 addresses outgoing ... cool
<dileks> privacy extensions?
 * ppisati -> gym, before the rest of the world goes there too...
<apw> dileks, yeah somthing like that, random addresses as primary on the interfaces
<apw> ahh now my ipv6 is unreliable
 * tgardner grows old whilst watching a Dell mini-10 install 12.04
<jsalisbury> tgardner, bjf, I've been seeing allot of apt-get bugs today like bug 1002388  
<ubot2> Launchpad bug 1002388 in linux "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: subprocess installed post-installation script returned error exit status 17" [Medium,Confirmed] https://launchpad.net/bugs/1002388
<jsalisbury> tgardner, bjf The common error is:
<jsalisbury> Setting up linux-image-3.2.0-24-generic (3.2.0-24.38) ...
<jsalisbury> Running depmod.
<jsalisbury> Failed to symbolic-link /boot/initrd.img-3.2.0-24-generic to initrd.img: File exists
<jsalisbury> dpkg: error processing linux-image-3.2.0-24-generic (--configure):
<jsalisbury>  subprocess installed post-installation script returned error exit status 17
<jsalisbury> Errors were encountered while processing:
<jsalisbury>  linux-image-3.2.0-24-generic
<henrix> jsalisbury: yeah, i saw that too... i guess there's something really wrong with the initramfs generation. didn't had a chance to take a closer look yet
<jsalisbury> henrix, yeah.  or maybe the install script changed?  
<henrix> jsalisbury: maybe
<henrix> jsalisbury: but there are a bunch of bugs
<ogasawara> apw: you've got a netbook with broadcom wifi?  Could you test the 12.10 lts kernel from the PPA https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<tgardner> ogasawara, working on it.
<apw> ogasawara, using which driver ...
<apw> tgardner, i assume you are talking about the brcm ?
<tgardner> apw, yep. I have the exact same dell mini-10
<apw> ack
<ogasawara> tgardner: ah cool, thanks
<tgardner> apw, I've just now gotten precise installed. took nearly 2 hours
<apw> tgardner, heh then it'd be rude for me to just test it
<tgardner> apw, if you've got one installed, then feel free.
<apw> tgardner, oh but ... i have a Q kernel on that machine already
<apw> tgardner, and i am noticing i have to modprobe brcmsmac before it does anything
<apw> tgardner, is that the complaint ?  i wonder if its that option you turned on ogasawara for the non-overlapping ids
<ogasawara> apw: rickspencer3 is dogfooding and claiming jockey vomits if he tries to active the driver
<apw> god, he used jockey, is that wise with a newer kernel
<tgardner> ogasawara, as it should. we're not backporting dkms drivers, so perhaps this is a jockey bug ?
<apw> tgardner, but as i say there is also something stopping brcmsmac working right with that kernel
<apw> tgardner, which i bet is why he is running jocky in the first place
<tgardner> apw, I'll have a look at the overlap config
<tgardner> apw, according to the bug he didn't try jockey until after his wifi wouldn't work
<apw> right which would fit the symtoms i am reporting
<apw> i have to run sudo modprobe brcmsmac with mine
<apw> after reboot each time, not had a chance to track it
<tgardner> apw, I'll bet there are some modalias issues then
<apw> right, and i remember ogasawara turngin somethign off recenting for brcm something perhaps its wrong
<tgardner> apw, CONFIG_B43_BCMA_EXTRA
<sforshee> apw, is bcma being loaded?
<apw> tgardner, hmmm i am finding brcmsmac works well for me, but doesn't autoload
<apw> tgardner, so i'd say its not that then, but we do need to find out why its not autoloading at all
<ogasawara> apw: I thought we had another brcmsmac sauce patch regarding autoloading, /me digs back through the git logs
<apw> hmmm maybe we lost it then, that would expalin a lot
<apw> ogasawara, i have a test bed for that one if you find it
<sforshee> apw, bcma should be loaded for the pci device, it will create a bcma: device that brcmsmac should match
<sforshee> so first thing to check is that bcma is loading
<apw> sforshee, rebooting now
<sforshee> ogasawara, apw, tgardner: fwiw brcmsmac autloads okay for me with BCM43224
<ogasawara> bug 1003793
<ubot2> Launchpad bug 1003793 in linux "broadcom wireless does not work with quantal-backport-kernel" [High,Confirmed] https://launchpad.net/bugs/1003793
<sforshee> the autoloading changed from 3.2 -> 3.4, brcmsmac used to match pci ids but now matches on bcma devices
<apw> sforshee, so no brcma
<sforshee> apw, bcma, no r
<apw> sforshee, not that either
<tgardner> sforshee, its still got 'MODULE_DEVICE_TABLE(bcma, brcms_coreid_table)'
<apw> if i manually load that should brcmsmac load then ?
<sforshee> apw, likely
<sforshee> what's the modalias for the pci dev?
<sforshee> tgardner, in 3.2 or 3.4?
<tgardner> shadeslayer, 3.4
<tgardner> sforshee, ^^
<shadeslayer> huh? oh .. ok
<sforshee> tgardner, right. In 3.2 it was a PCI device table
 * shadeslayer was surprised for a moment there, having done no kernel work and being highlighted in #ubuntu-kernel
<tgardner> sforshee, still waiting for this dell mini-10 to update. then I can look at the module aliases for Quantal 3.4. I'm suspecting that is the root of the issue, especially since things work OK after manually probing.
<ogasawara> apw: scratch my comment about a sauce patch for autoloading, it was a sauce patch to allow brcsmac and b43 to both build
<sforshee> tgardner, all the pci ids that were in brcmsmac are in bcma, so I don't know why bcma wouldn't be loading
<sforshee> apw, you don't have bcma blacklisted, do you?
<tgardner> sforshee, 'cause the brcmsmac IDs are for a bcma device, not PCI.
<sforshee> tgardner, but apw says bcma isn't loading, and it should match the id
<sforshee> then bcma creates a device that brcmsmac matches
<tgardner> sforshee, yeah, bcma should load.
<apw> sforshee, ahh yes i do ... cause i have wl installed
<sforshee> apw, that's your problem then :)
<apw> and i bet that is also ricks problem, i bet he has wl installed so everything is disabled
<tgardner> sforshee, so with 3.2 bcma loads b43.
<apw> but i bet wl doesn't compile ... so he has nothing
<sforshee> tgardner, I think what happens is that brcmsmac probes before bcma and thus matches on the device first
<apw> sforshee, ok will reboot witht hat and see if it resolves
<apw> sforshee, but i bet he has wl installed, we should ask
<sforshee> tgardner, because both match on that pci id in 3.2
<apw> sforshee, ok that worked, bcma and brcmsamc are now both loaded and i have wifi.  so that is just a me config cause i wanted wl installed to i know if it blows up, but not being used so i test the real version
<apw> but as i say i bet this is a wl not working and installed iss
<apw> issue
<ogasawara> apw: what's the package name again that provides the wl driver?
<tgardner> bcmwl-kernel-source
<tgardner> ogasawara, ^^
<ogasawara> thanks
<apw> yep that thing
<tgardner> apw, we should write a patch for module-init-tools that blacklists on a per-kernel basis
<apw> tgardner, yeah and we have a WI for that, but in this case its carried by wl so it still would mess us up
<sforshee> tgardner, to fully explain the situation: b43 will still match the same bcma ids as brcmsmac if CONFIG_B43_BCMA_EXTRA is enabled, which is why we want it disabled
<sforshee> it was racy before, but in a way that worked out in brcmsmac's favor
<tgardner> sforshee, I think it is disabled.
<sforshee> when brcmsmac moved to matching on bcma it worked out in b43's favor
<sforshee> tgardner, yes, I sent a patch for that last week
 * apw thought i saw it applied
<apw> no idea if its uploaded mind
<tgardner> # CONFIG_B43_BCMA_EXTRA is not set
<tgardner> this is from the LTS backport kernel
<sforshee> yep, I think it went in with the last upload
<tgardner> lsmod|egrep ^b
<tgardner> b43                   351462  0 
<tgardner> bnep                   17790  2 
<tgardner> btusb                  17888  0 
<tgardner> bluetooth             185648  24 bnep,btusb,rfcomm
<tgardner> bcma                   26123  1 b43
<tgardner> rtg@m10:/boot$ uname -a
<tgardner> Linux m10 3.4.0-3-generic #7~precise1-Ubuntu SMP Tue May 22 20:22:09 UTC 2012 i686 i686 i386 GNU/Linux
<tgardner> 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)
<tgardner> sforshee, so, this is doing about what I would expect.
<sforshee> tgardner, brcmsmac probably doesn't support that one
<tgardner> right
<tgardner> apw, what model do you have ?
<tgardner> sforshee, incidentally, b43 on this machine doesn't work for shit.
<sforshee> tgardner, performance, reliability, or both? My experience is that b43 reliability is fine, but performance sucks
<tgardner> sforshee, doesn't even scan a beacon
<sforshee> tgardner, what machine? It's not a macbook, is it?
<tgardner> dell mini-10. its a few years old
<sforshee> okay, no ideas then
<tgardner> sforshee, huh, could be I need firmware.
<apw> tgardner, ahh yes, mine loaded b43 (the dell mini 10) and that bitched about firmware
<sforshee> tgardner, is firmware loading failing? now that you mention it I recall seeing a thread on linux-wireless about that in the past few days...
<apw> tgardner, as i am not using it on there, i rmmod'd it
<apw> (just noticed half an hour ago when tyring to work out why my network kept stopping)
<apw> and now i know, its cause my firewall reneabled 'suspend on lid close' on upgrade ... POS
<sforshee> tgardner, http://article.gmane.org/gmane.linux.kernel.wireless.general/91341
<tgardner> sforshee, I just read that one this AM, but its more of a load race then anything. I simply didn't have the firmware on disk.
<sforshee> tgardner, oh yeah, that's a problem
<tgardner> apt-get install linux-firmware-nonfree
<tgardner> sforshee, now it connects.
<tgardner> ok, back to loading the LTS kernel
<ogasawara> tgardner: keep me posted how the lts kernel goes after installing linux-firmware-nonfree.  I think rick's running into the same hurdle but he's gotta drop off and will pick back up tomorrow morning.
<tgardner> ogasawara, it seems to work fine. wl would definitely screw things up
 * sforshee -> lunch
<ogasawara> jsalisbury: for bugs coming in against the 12.10 kernel in 12.04, can you make sure they are tagged 'qa-kernel-lts-testing '
<ogasawara> jsalisbury: in the future, once apport is fixed to allow bug reporting when running the backport kernel, you should be able to edit our bug processing scripts to grep for ~precise in the version string and have it add the tag automatically
 * smb -> beer
<jsalisbury> ogasawara, will do
<jsalisbury> ogasawara, Do you know if there is an apport bug opened to allow bug reporting when running the backport kernel?
<ogasawara> jsalisbury: there isn't
<ogasawara> jsalisbury: or at least none that I'm aware of
<jsalisbury> ogasawara, should I open one, or is there already a work item somewhere to add that functionality 
<ogasawara> jsalisbury: I was going to add a work item to one of our blueprints so it stays on our radar.  If you want to open a corresponding bug for it, feel free
<jsalisbury> ogasawara, cool, thanks
<jsalisbury> ogasawara, opened a corresponding bug 1004101
<ubot2> Launchpad bug 1004101 in apport "[RFE] Allow Bug Reporting When Running Backport Kernel" [Undecided,New] https://launchpad.net/bugs/1004101
<ogasawara> jsalisbury: thanks
<jsalisbury> ogasawara, np.  It's just a skeleton, since I didn't add many details.
<arges> tgardner, started to look at pad.lv/669641  , anything you need help with to get that one fixed?
<arges> or rather i was going to, but just saw you assigned it to yourself
<tgardner> arges, huh, I guess I forgot about it. UDS likely got in the way. feel free to take it over.
<arges> tgardner, sure. was at the end of my to-do list and just got to it
<jsjgruber-x-p> Where's the browsable kernel git repo? The one mentioned on the kernel wiki page seems to be gone-- kernel.ubuntu.com/git
<ogasawara> jsjgruber-x-p: which specific Ubuntu kernel are you interested in?  http://kernel.ubuntu.com/git still looks valid to me
<jsjgruber-x-p> ogasawara, I'm trying to help someone on askubuntu. He wants to know where to look to see where apparmour patches were dropped from the kernel. When I go to that url . I just tried it again and it came up. Sorry for the bother.
 * tgardner -> EOD
<hggdh> question: will the LTS backports always have a meta-package ending in 'lts-backport-<version>'? like linux-image-lts-backport-quantal?
<jMCg> Let's go to
<jMCg> O_o interesting. I think that ended up in the wrong channel.
<jMCg> Anyway, hey folks o/~ I'm debugging a problem with a Ubuntu 10.04 VM not booting in KVM. All I can see in the VNC is this:
<jMCg> init: ureadeadahead main (372) terminated with status 5
<jMCg> So, if someone has an idea what this is, or how to properly debug it, how to get more info out of it, Ihmmmm.. Have I configured stuff for serial console properly, I wonder..
<RAOF> hggdh: We don't know yet; it's planned to rename (as *-backports-* is associated with danger by some customers), but I don't know to what.
<hggdh> RAOF: k, thank you. I will base my scripts on the current naming; I do hope you folks give me some advance notive when it changes ;-)
<hggdh> s/notive/notice/
#ubuntu-kernel 2012-05-25
<HungryMan> Hey, is this a good place to make a feature request/ suggestion? I was brought by the wiki =p
 * apw yawns
<smb> apw, needs more loudness
<smb> ... and listening caps
<smb> apw, you are loud now (or where) but could not hear me
<apw> right ... so normal 'mic adjusting to my level' thing
<apw> and pulse being broken
<diwic> of course it's the kernel that's broken
<smb> diwic, That is a dangerous thing to say here
<apw> diwic, heh probabally
<diwic> smb, my point was that pulse is often being blamed for problems elsewhere in the stack
<apw> diwic, especially by people who maintain other bits of it
<smb> diwic, Its cannot ever be our lovely kernel... :-P
<apw> s/lovely/near perfect/
<apw> s/near perfect/near angelic/
<diwic> I find it strange that mumble/murmur does not have an echo service, like skype test call.
<smb> diwic, It does, its called colleagues...
<apw> diwic, that would be nice
<apw>     Merge branch 'perf-uprobes-for-linus' of git://git.kernel.org/pub/scm/linux/
<apw>     
<apw>     Pull user-space probe instrumentation from Ingo Molnar:
<apw> smb, who was asking for uprobes ?
<smb> apw, someone... cannot remember
<apw> ogasawara,        - The seccomp work from Will Drewry
<apw> seems we should expect that to fall out in v3.5
<ppisati> brb
 * ppisati -> out for lunch
 * apw lunches
<ogasawara> apw: cool, I'll make a note for the 3.5-rc1 rebase
<jsalisbury> henrix, tgardner, just curious if someone had a chance to review bug 1002388 ?  There are several new duplicates today.
<ubot2> Launchpad bug 1002388 in linux "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: subprocess installed post-installation script returned error exit status 17" [Medium,Confirmed] https://launchpad.net/bugs/1002388
<jMCg> OH YEAH! I know where it's stuck!
<jMCg> Finally! Good Afternoon ladies and gentleman. And welcome back to my favourite most bug!
<tgardner> apw, very sensible
<jMCg> http://dpaste.com/752116/
<apw> jMCg, ?
<jMCg> apw: that's where it's stuck. It's not moving on from that point on.
<jMCg> That's what I see in the serial console - and it's not answering on any of the IPs I configured so I'll assume it's dead, Jim.
<apw> jMCg, does this happen reliably ?
<apw> if you add --verbose to the kernel command line (yes with the --) it will tell upstart (init) to tell us more about what it is doing as it goes, and may tell us what is stuck
<jMCg> apw: currently I'm booting Lucid with the kernel from Host which is running Precise.
<jMCg> But, yeah, I'll add --verbose and see what happens.
<jMCg> I have a feeling I'm doing this debugging every six or so months.
<jMCg> apw:  http://sprunge.us/aRZA
<xnox> As part of 'backport kernels back to precise' are fs-tools backported as well (e.g. btrfs, ext4, etc)?
<xnox> if yes, how/where/by whom/?
<apw> xnox, hmmm, not currently, tgardner i wonder if we should be pulling fsck et al back as part of hwe-server conceptually
<tgardner> apw, only if there are significant improvements. Even then, they can come in via the -backports pocket and work for all kernels.
<xnox> ok.
<apw> tgardner, seems reasonable
<jMCg> apw: I may add --debug too, for more verbosity.
<xnox> After uploading updated btrfs-tools, almost immediatly I get a followup "can we have it in precise please?"
<apw> jMCg, i have been offered this "http://upstart.ubuntu.com/cookbook/#establish-blocking-job" as maybe helpful
<apw> xnox, heh ... now thats not a supprise
<apw> jMCg, can you pastebing the --debug output pls
<apw> tgardner, so this symlink thing do we want to figure it out or just avoid id
<apw> tgardner, as if i unlink it, its gone and we'll never know about the error
<jMCg> apw: probably more easily that finding the blocking job.
<tgardner> apw, we likely have to figure itout 'cause it may impact LUKs installs, etc
<apw> tgardner, ok then just the fixed errors so we can tell which went wrong then
<tgardner> apw, right. we can get cjw and infinity to have a look as well. they likely have the institutional knowledge to advise us.
<jMCg> apw: it's just 40 lines longer..  http://sprunge.us/iGaU
<apw> jMCg, it feels like mountall has started and not finished
<apw> can you check the UUIDs from fstab, that they match both the swap and /
<jMCg> apw: I don't use UUIDs in /etc/fstab
<apw> missing device then, are all the device names right
<jMCg> apw: it's hard to get them wrong /dev/vda for / - /dev/vdb for swap, /dev/vdc for /var, /dev/vdd for /opt
<jMCg> But I'll check again.
<apw> smb, didn't we change the device names for virtual disks somewhen between lucid and precise ?
<apw> jMCg, did you say you had lucid userspace and precise kernel ?
<smb> apw, yes for xen
<apw> smb, was vda xen ?
<jMCg> Yeah, the software I need to run doesn't support prceise yet :-/
<apw> so was the precise kernel just the HOST or in the VM as well
<smb> apw, It was hacked to sda for pv disks but shouold always have ben xvda
<smb> apw, vda sounds like kvm
<apw> smb, ok not that then
<jMCg> KVM it is.
<jMCg> Sorry, I'm pretty and sure I mentioned that. Yesterday.
<apw> be assured none of us can remember more than 10m ago, let alone yesterday
<jMCg> Which reminds me, I made tea.. a while ago.
<apw> see, you didn't remember your tea.  heinus crimb
<apw> tgardner, top of quantal i386 generic is pae right ?
<tgardner> apw, that doesn't make sense to me. the _only_ i386 flavour is generic (which is PAE)
<apw> tgardner, thats what i was asking ... making sure i was building the flavour i watned
<jMCg> I think last time I had this problem i fixed it by upgrading to whatever came before what we have now.
<jMCg> 11.10, probably.
<jMCg> But I cannot do that in this case, because zimbra.
<apw> so disks matches for both fss and swap
<apw> jMCg, whats in your fstab
<jMCg>  http://sprunge.us/MfYW
<jodh> jMCg: try adding '-v' to mountall in /etc/init/mountall.conf, and then creating a job like this:http://paste.ubuntu.com/1006452/
<jMCg> cool.
<jodh> jMCg: ... and try commenting those 2 remote mounts out of /etc/fstab :)
<jMCg> jodh: pfft ;)
<apw> jodh, do we do those at the same time, not later in a second mount pass ?
<jMCg> apw, jodh - while adding -v might have done something, I don't think the job I created did:  http://sprunge.us/ggIV
<jodh> apw: it seems to tag remote mounts "nowait" so they will get processed after the rest, yes.
<jodh> jMCg: so did you comment out those 2 mounts? Can you boot to runlevel 1 btw?
<jMCg> jodh: yes, I did comment them out, and no, apparently not.
<jodh> jMCg: so you've tried an explicit "1" on the command-line?
<jMCg> jodh: no, I haven't - I never new you could do that!
<jMCg> "virsh destroy mail"
<jMCg> I'm glad it's actually harmless.
<jMCg> jodh: nope, 1 odesn't do a thing :-/
<jodh> jMCg: ? it hangs still attempting to boot to runlevel 1?
<jMCg> jodh: yes
<jMCg> I might add that I don't see anything in either VNC or the serial console.
<apw> tgardner, i am conflicted about putting a buglink in this fix for the grub errors, as we are almost cirtainly going to want to sru it to try and get more information from these failures, but i don't want the bug to close really ... sigh
<apw> tgardner, i feel i am right to put it in regardless
<apw> jsalisbury, bug #1002388 this is your master bug right ?
<ubot2> Launchpad bug 1002388 in linux "package linux-image-3.2.0-24-generic 3.2.0-24.38 failed to install/upgrade: subprocess installed post-installation script returned error exit status 17" [Medium,Confirmed] https://launchpad.net/bugs/1002388
<jsalisbury> apw, correct
<jodh> jMCg: has this system ever booted correctly? I came in late to the conversation. Have you put any non-default jobs in place? If so, disable them. Maybe try booting with "init=/bin/bash" then "mount -oremount,rw /" and have a sniff around.
<apw> jsalisbury, so when these debug fixes drop into quantal, and likely later into precise we need to move the bug back to 'in progress'
<jodh> jMCg: err - hold on. I think mountall is getting SIGTRAP - indicating dodgy hardware.
<jsalisbury> apw, will do.  How will I know when the debug fixes land? 
<apw> well quantal i have pushed it in already so on the next upload, we'll see if the world explodes and if not then we'll push it back
<jMCg> jodh: it's a VM!
<jsalisbury> apw, ok, thanks
<apw> jsalisbury, not ideal, sigh, i could file a separate bug for the debug i guess, would that be less confusing?
<jsalisbury> apw, nah, I understand ;-)
<jMCg> Right.
<apw> jsalisbury, thanks ... i will forget :)
<jMCg> jodh: this is a KVM starting up a Lucid, and I'm booting it with Precise kernel because I dunno.. Grub doesn't quite boot it either..
<jodh> jMCg: hmm. well waitid() appears to be returning SIGTRAP for mountall looking at your log. So has this system ever booted??
<jMCg> jodh: it's KVM - it's booting many other other (Precise) VMs
<jodh> jMCg: that's not what i asked - has the vm we're talking about ever booted correctly? I came into this issue half way through.
<jMCg> jodh: nope.
<jMCg> Well, it has - with a grml ISO.
<jodh> jMCg: and going back to the other question - have you installed any additional jobs over the default set?
<jMCg> jodh: yes: ttyS0.conf
<jMCg> jodh: and the one you told me to install
<jMCg> http://paste.ubuntu.com/1006452/
<jMCg> I think it was you. Something about 10 minutes memory.
<jodh> jMCg: what does your ttyS0 do exacly? I can guess, but I'd rather see it.
<jodh> jMCg: and have you tried booting with init= yet?
<jMCg> 16:02:10 < apw> be assured none of us can remember more than 10m ago, let alone yesterday
<jMCg> jodh: not this time around. I was actually just getting ready for dinner, because sugar levels gone down and concentration out the window and stuff.
<jodh> jMCg: right - can this wait until Monday then?
<jMCg> probably I got enough other things to do.
<jMCg> jodh: which timezone are you?
<jMCg> I should probably pass init= an init..
<jodh> jMCg: BST
<jMCg> otherwise you get: http://dpaste.com/752152/ !
<jMCg> jodh: excellent. I'm in CEST.
<jMCg> Target filesystem doesn't have requested /bin/zsh.
<jMCg> ooops.
<jMCg>     <cmdline>root=/dev/vda ro serial=tty0 console=ttyS0,38400 init=/bin/sh</cmdline>
<jMCg> still gets stuck at: Begin: Running /scripts/init-bottom ... done.
<jMCg> Anyway, off for dinner now.
<jodh> jMCg: try init=/bin/bash as I said.
<jMCg> 17:37:52 < jodh> jMCg: and have you tried booting with init= yet?
<jMCg> ;)
<jodh> jMCg: that was the reminder - look further up.
<jodh> jMCg: :)
<jMCg> Begin: Running /scripts/init-bottom ... done.
<jMCg> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
<jMCg> bash: no job control in this shell
<jodh> jMCg: that's expected - and you now have a shell.
<jMCg> jodh: headache, cold, and running nose all do prevent me from looking further up.
<jMCg> jodh: \o/
<jMCg> Also, hunger. gaaaahnmpfzd. I'll leave the shell where it is, and see if I can get this thing booting itself after dinner.
<jMCg> And I need to restock hankie supply.
<jMCg> So, happy Towelday, and read you later o/~
<tgardner> apw, is this right for the enforcer ? "arch amd64 & value CONFIG_XEN_ACPI_PROCESSOR y"
<cking> kirkland, more eCryptfs results heading your way
<apw> tgardner, checking
<apw> tgardner, do we care about the value in the other arches ?
<apw> tgardner, i worry it will be invalid on non-amd64, give me a sec to test
<apw> (arch amd64 & value CONFIG_XEN_ACPI_PROCESSOR y) | !arch amd64
<apw> tgardner, ^^ 
<kirkland> cking: woohoo!
<kirkland> cking: dude, you're tearing this up :-)
<kirkland> cking: really excited to have you on this :-)
<cking> kirkland, well, lets see what the results are on normal laptops - I don't want to get too excited yet ;-)
<kirkland> cking: heh
<kirkland> cking: i'm excited already
<cking> kirkland, yep, I'm pleased with the SSD results - it certainly is a positive step forward
<tgardner> ogasawara, even if we don't upload a 3.5-rc1 kernel for A1, we should consider uploading whats in master-next right now since it'll fix some AA problems.
<ogasawara> tgardner: was thinking the same and was gonna shove up an upload this afternoon
<tgardner> ogasawara, I like the way you think :)
 * cking grabs some food
<splnet> How do I enable the kernel crashdump utility? I ran apt-get install linux-crashdump; reboot ; Then after rebooting, I experienced a kernel panic.. but it didn't reboot into the crash kernel. 
<splnet> Is this what is supposed to happen?
<tgardner> Caribou, haven't you been working on this ? ^^
<ppisati> herton: new P/omap4 "released" (1414.19), 1413.18 invalidated
<herton> ppisati, ack, will upload once the previous one QA and releases
<herton> previous one == .17
<ppisati> herton: ack
<ogasawara> dchroot -c quantal-amd64
<ogasawara> em: Access not authorised
<ogasawara> ia: You do not have permission to access the schroot service.
<ogasawara> ia: This failure will be reported.
<ogasawara> tgardner-lunch: ^^ when you get back, seeing this on gomeisa
<apw> ogasawara, i think i've added you to sbuild
<apw> if you could logout, in and retest
<ogasawara> apw: ack
<ogasawara> apw: ah much better, thanks
<apw> ogasawara, hopfully i got everyone
 * apw relocates to a comfy chair
<jMCg> So! I'm back. From dinner. And I have bash as init.
<tgardner> ogasawara, I know whats going on. gimme a sec
<ogasawara> tgardner: apw got me sorted
<tgardner> apw, did you run the install_kernel_devs.sh script ?
<apw> tgardner, nope, i thought that'd been done already
<tgardner> hmm, he must have.
<apw> i just sorted the groups
<tgardner> apw, you can run it repeatadly
<apw> i just sorted the groups
<apw> bah ... ok you should prolly do that
<tgardner> apw, its ok, on these LDAP machines that  is about all the script accomplishes
<apw> ahh right
 * cking -> EOD
<jjohansen> bjf: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971685, for the Quantal nomination is there in reason that is marked In Progress
<ubot2> Launchpad bug 971685 in linux "CVE-2012-1601" [Medium,In progress]
<jjohansen> bjf: the fix is in the commit logs
<bjf> jjohansen: no reason i can think of
<jjohansen> bjf: okay, I'll change it then, thanks
<bjf> jjohansen: maybe i clicked on the wrong task and didn't notice
 * ogasawara lunch
<HungryMan> Is this the proper area to make a feature request? 
<ogasawara> wow, he didn't stick around long.  and I was just about to tell him to file a bug
<jsalisbury> heh
<apw> heh he was in yesterday for a bit, again with noone about
<tgardner> ogasawara, pushed a couple of config changes before you pacvkage and upload
<ogasawara> tgardner: I saw the IWLWIFI_EXPERIMENTAL_MFP change.  I was gonna hold it till the next upload as I'd already prepped the package and test built
<tgardner> ogasawara, thats fine. I'm just grinding through the config blueprint
<ogasawara> tgardner: ack, thanks for doing that
<tgardner> ogasawara, its mostly mindless, which is where I'm at this time of the week.
<tgardner> apw, CONFIG_CIFS_EXPERIMENTAL seems to have disappeared out of all Kconfigs, so why doesn't it get elided on an updateconfigs ?
<apw> tgardner, looking
<apw> tgardner, indeed, and its not in the generated configs either ... will poke its a thinko somewhere
<tgardner> apw, it'll wait until next week. I think I'm done for the day.
<apw> tgardner, its on my todo :)
 * tgardner -> EOW
<hallyn> say, should 'apt-get install linux-headers-virtual' install linux-headers-3.2.0-23-virtual ?
<jMCg> hallyn: it should instll linux-headers-$latest-virtual, yes
<hallyn> ideally :)
<hallyn> doesn't seem to be happening though
<hallyn> (i'd have to fire up a new instance to debug more)  this is on ec2
<hallyn> basically after i do apt-get install linux-headers-virtual, i can't yet apt-get install --reinstall openvswitch-datapath-dkms
<hallyn> but after installing linux-headers-`uname -r` i can
<arges> sforshee, hey still around?
<sforshee> arges, hey
<arges> sforshee, hey, was going to bug you about a bug, but its too close to EOD. : )
<sforshee> arges, sorry I didn't notice your ping earlier, I was off playing with a different machine
<arges> sforshee, yea no problem. 
#ubuntu-kernel 2012-05-26
<jMCg> http://www.zimbra.com/forums/241267-post4.html <<< hohum.. Why not?
#ubuntu-kernel 2012-05-27
<ohsix> can i run http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ on natty without huge problems? i've been instructed to see if my acpi problems happens on a newer kernel and sometimes it takes forever to show up
<pac1> I want to set up a kernel build environment as described in https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam%2FKernelGitGuide.    It notes: "If you plan on working on more than one kernel release you can save space and time by downloading the upstream kernel tree. "   Which kernel tree should I download for ubuntu-precise-git and 
<pac1> s/and//
<pac1> I may have missed an answer to "I want to set up a kernel build environment as described in "
<pac1> is there a log for this irc channel?
<pac1> sorry for the noise. My friend google says yes there is a log.
<popey> !logs
<ubot2> Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too; for older LoCo channel logs, see http://logs.ubuntu-eu.org/freenode/
<popey> ^^ pac1 
<martman> i just updated my 12.04 system, so my running kernel is 3.2.0-24. i just pull the ubuntu-precise repo and i dont see that version in the tag list
<bjf> martman, i see Ubuntu-3.2.0-24.38 and Ubuntu-3.2.0-24.39
<martman> bjf: from runninf git tag?
<martman> ?
<bjf> martman: yes
<bjf> martman, i just cloned a new copy of the repo and did "git tag"
<martman> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
<martman> that repo bjf?
<martman> git tag | grep v3.2.0
<martman> gives me nothing
<bjf> martman, what does 'uname -a' return ?
<martman> Linux m1 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<bjf> martman, the tag for that is Ubuntu-3.2.0-24.39
<martman> http://pastebin.com/q3YXj9xA
<martman> thats the output of git tag | grep v3.2
<bjf> martman, i thought you were trying to find the tag for the version you have installed
<martman> i am
<bjf> martman, then quit putting a 'v' before the 3.2
<bjf> martman, grep for the string i told you
<martman> ooooooooook, gotcha
<martman> was wondering what was going on
<martman> i scrolled for alittle while and thought they always started with v
<martman> thanks
<bjf> martman, upstream tag may, but ours do not
#ubuntu-kernel 2013-05-20
 * apw struggles into the land of the living
<infinity> apw: It's an overrated land.
<apw> infinity, seemingly so indeed
 * ppisati -> reboot
<rbasak> Have you guys seen: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037134.html ?
<rbasak> Seems like a reasonable question - should he be directed to the kernel-team list?
<infinity> rbasak: Mainline kernel builds aren't (quite) the same as Ubuntu configs.  I assume the bump to 3.10 will also involve a config review and turning on all the new shiny.
<infinity> rbasak: But I don't speak for apw/rtg on this one, so perhaps bouncing it to the kernel list would be helpful.  *shrug*
<apw> rbasak, yep bounce that to the kernel-team and we can answer it, i would likely find it on u-d eventually
<apw> for clarity the reason it is off is that our saucy hasn't got the functionality turned on, so the config which carries over won't have it.  when we move saucy to 3.10-rcN then we'll turn it on no doubt there and the mainline kernels will get it
<apw> basically it is hard to enable everything
<apw> we ask the build system to take the defaults for everything new, and the default for that must be N
<apw> so it it probabally untested crap :)
<apw> it appears to not indicate a default so i would expect that to default off
<apw>   Block device as cache (BCACHE) [N/m/y/?] (NEW) 
<apw> yeah, it defaults off so we default it off
<rbasak> apw: I'm going to need moderation on both lists so will cause other people effort if I try to stick my nose in. Would you mind replying to him as appropriate, please?
<rbasak> apw: or just C&P this channel if you're feeling nosy :)
<rbasak> nosy?
<rbasak> lazy.
<davmor2> Morning all.  I upgraded from Raring to Saucy last week and it broke secure boot. I'm running a couple of things that cjwatson suggested but feel free to fire off suggestions here too :)
<rtg_> henrix, how about a pull request for your CVE patches ?
<rtg_> I assume you have them all in one place.
<henrix> rtg_: yep, i have. i'll send the request
<rtg_> henrix, thanks, saves me some typing, something I'm wretchedly bad at.
<henrix> rtg_: heh, sure no prob
<henrix> is anyone else receiving an annoying email from naver.com after sending an email the the kt mailing list?
<henrix> looks like someone from that domain subscribed the ML and that email was deleted from the domain
<henrix> *really* annoying
<rtg_> henrix, why are you getting it ?
<henrix> rtg_: i believe its because my 'Reply-To:'
<henrix> rtg_: in the email header
<henrix> it started last week
<rtg_> I'm the admin, lemme check.
<henrix> here's a sample: http://paste.ubuntu.com/5683555/
<henrix> it contains the email address, so maybe you can just unsubscribe it...?
<rtg_> henrix, thats what I'm gonna do
<henrix> rtg_: cool. thanks. but am i the only one seeing this?
<rtg_> henrix, I haven't seen it, but then I have not sent anything since about thurs
<rtg_> henrix, that email address is now unsub'd
<henrix> rtg_: thanks
<diwic> I haven't seen it either
<henrix> yeah, it started late last week. let me check...
<henrix> ok, first time i saw that was last friday, when i spammed the ML with the 3.5.y emails
<diwic> henrix, maybe that overflowed the relevant email inbox or something, causing the error 
<henrix> diwic: yep, its possible :)
<rtg_> apw, thought I'd start on maguro today. seems like grouper/manta/mako have all settled a bit.
<apw> rtg_, great
<ogra_> yay
 * rtg_ bounces tangerine for kernel update
<rtg_> cking, 'wipe' is estimating 5 years to clean this USB 2.0 disk. is there something else I can use to test this disk ? I was getting some random failures and haven't been able to pin down where.
<cking> rtg_, no immediate idea for fast exhaustive exercising such devices
<cking> how about plain old dd'ing to it to see if that easily trips the issue?
<rtg_> cking, maybe just writing withh dd will trigger it
<rtg_> :)
<cking> indeed
<cking> just make sure bs = something large :-)
<rtg_> cking, yeah, block size makes a giant difference
<infinity> rtg_: What sort of failures were you seeing?
<infinity> rtg_: Be warned that if you were seeing random *read* failures, dding over the disk will magically paper over that, as attempts to *write* those sectors will trigger auto-remapping magic.
<infinity> rtg_: Though, that's still an interesting datapoint.  If you can convince something like smartmontools to spew out disk info before and after a full dd, if your remap count goes up, your disk is dying.
<rtg_> infinity, random failures to read from the file system resulting in hung threads.
<rtg_> apw, the linux 3.9.0-2.7 build for i386 is busted whilst some doc-utils carnage is being fixed.
<apw> rtg_, ook, ok
<rtg_> apw, I think the release team will just restart the build once that is fixed
<apw> rtg_, ahh that kind of carnage, ok
<rtg_> apw, they ointed out that our build chroots should have -proposed enabled, but I'm kind of unwilling to do that on tangerine/gomeisa lest it impede everyone because of some silly archive inconsistency.
<rtg_> point*
<apw> rtg_, indeed, i have two chroots for sbuild, well a special frig that allows one to ask for -proposed to be enabled when sbuilding things
<apw> which i use for this very reason.  if we have those kind of chroots too, you could at least confirm finally with an sbuild that it was a chroot issue
<rtg_> hmm
<apw> but for the statuc c
<apw> static chroots we have, not so easy
<rtg_> it happens so seldom that i wonder if its worth it.
<apw> probabally not in my opinion, i should publicise the other ones, and make them consistently across the buildders
<apw> so people can at least go 'ummm, i wonder, -proposed, lets see'
<rtg_> apw, _we're _ the only people interested in -proposed I think.
<apw> yeah prolly, then i'll tell you :)
<apw> rtg_, ahh crap you applied luis' pull request; but didn't mention it on the patches, so i have reviewed them needlessly
<rtg_> apw, yeah, I just used his pull request and ACK'd that
<rtg_> I guess I just assumed ...
<apw> ahh well, you have a second ack, even if it is not in the applied commits
<henrix> apw: sorry, i guess i should have sent the pull request as a reply to the patches...
<rtg_> they all looked pretty straightforward
<apw> yep tey all are indeed
<apw> henrix, rtg_, *shrug* noones fault
<rtg_> cking, the Q/A folks were talking about using lttng as a general mechanism for tracking some stuff. do you know of they received your results about lttng overhead ?
<cking> rtg_, I did send a copy to gema
<rtg_> cking, cool
<cking> not heard any reponse yet 
<cking> *response even
<apw> jsalisbury, yo ... you were working on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1112652, did you confirm that those two patches in stable were the fix ?
<ubot2> Ubuntu bug 1112652 in linux (Ubuntu Raring) "[raring] no ethernet with "auto" default power option with 82579LM" [High,In progress]
<infinity> E: linux source: build-depends-on-essential-package-without-using-version build-depends: util-linux
<infinity> rtg_, apw: ^--- Really?
<infinity> Evidently, no one ever runs lintian on the kernel.
<cking> or nobody ever looks at the lintian errors
<infinity> Hey, I never lintian the kernel either. :P
<infinity> Just saw that in passing while helping some poor sod who's trying to build a patched kernel.
<apw> infinity, heh, you know us, cowboys the lot of us
<apw> cowpersons
 * rtg_ didn't know he was supposed to care
<apw> i think that is somewhat his point :)
<rtg_> apw, well, I _do_ know someone that would like to fix all the lintian warnings.
<infinity> It's mostly harmless, but {Build-,}Depends on essential packages can cause some resolver oddities and other messes.
<apw> infinity, has that changed to be essential, or have we always been bust
<apw> rtg_, shhh he will hear
<infinity> apw: It's always been essential.
<apw> oops
<apw> rtg_, i'll go zap it in saucy at least
<rtg_> infinity, so you're saying it shouldn't be in build-depends list at all ?
<infinity> rtg_: Right.
<rtg_> well, tats an easy one
<infinity> rtg_: Unless, of course, there was a reason to have a versioned build-dep, but you don't have such, so that seems unlikely. :P
<apw> infinity, its not recent, so any version would be balls by now anyhow
<rtg_> infinity, the last versioned build dep was for file-utils IIRC
<rtg_> I'm sure we can drop that by now as well
<rtg_> findutils
<infinity> Oh, you mean that build-conflict?
<rtg_> yeah, its a conflict, not a depends
<rtg_> apw, fix the Vcs-Git whilst you're mucking about
<apw> yep
<infinity> rtg_: Given that that version predates lucid, you're probably safe dropping the build-conflict, yeah. :P
<rtg_> apw, ^^
<apw> ack ^2
<infinity> It also never shipped in any release.
<apw> nice
<infinity> It was only in karmic for 3 days. :P
 * apw bets it was infinity's fault ...
<infinity> Don't look at me, I didn't work here during the karmic release.
<infinity> I don't think.
<rtg_> we'll blame it on Ben
<infinity> He didn't work here either.
<cking> he did
<infinity> *cough*
<cking> ah
 * apw remembers why we don't run lintian very often on this package ... omg it takes a long time
 * cking wonders if that's because it's gone off and committed suicide because of the quantity and type of errors it's found
<apw> i think perhaps the machine i ran it on has ... sigh
<apw> W: linux source: unknown-architecture armhf
<apw> W: linux source: unknown-architecture arm64
<apw> oh come on ... i hate lintian
<infinity> That'd be an old lintian.
<apw> yeah, and ... well just ... and ..
<manjo> hey you guys seen this with 13.04 ? 
<manjo> [    5.710629] BUG: unable to handle kernel paging request at ffff8804075a3fe0
<manjo> [    5.710659] IP: [<ffffffffa04ac820>] patch_generic_hdmi+0xe0/0x550 [snd_hda_codec_hdmi]
<infinity> apw: http://paste.ubuntu.com/5684150/
<apw> manjo, yep, that should have been diwic's fix i think
<infinity> apw: The only one there (other than the one you fixed) that looks potentially scary is they unsafe symlink one.
<rtg_> manjo, yes, the fix is in the pipeline
<infinity> manjo: That should be fixed in the -proposed kernel.
<manjo> apw, cool thanks ... I lost sound as well ... 
<apw> infinity, there is 2 or 3 there that diserve a wiggle, i'll get the sorted out
<apw> infinity, these binary-control-... ones are they something we do wrong, or something ubuntu does diff to debian
<infinity> apw: Note that P (pedantic) and I (informational) ones aren't really errors, per se.
<infinity> apw: But it's hinting that binaries that don't declare section/priority inherit from the source stanza, so it's a waste of effort to declare it every time.
<infinity> apw: Due to the way you build your control files, being overly declarative is likely not a bad thing, since the snippets live on their own and it's easier to keep track of them as self-contained units.  *shrug*
<apw> infinity, i actually suspect it is kernel-wedge in that case
<infinity> apw: Nah, it's all your kernel image packages from control.d
<infinity> apw: (It does list the binary stanza at the end of each of those lines)
<apw> infinity, so it does...
<infinity> apw: Now, you can blame the pedantic spew on kernel-wedge.
<infinity> apw: The xc-package-type-in-debian-control thing.
<infinity> apw: Oh, the duplicate description thing is entirely valid too.  linux-image-extra really should mention that it's addon modules or something, not claim to be a kernel image.
<apw> infinity, already fixed that last one
<apw> infinity, as indeed it is just wrong
<infinity> (And the gfdl test is a no-op for Ubuntu, we consider the GFDL "free enough", while Debian doesn't)
<apw> ahh
<apw> infinity, to be clear the lintian errors about the symlink would have to be talking about a specific file in the source package, rather than a binary package
<apw> lrwxrwxrwx 1 apw warthogs    33 2013-05-20 16:05 ./arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts
<apw> which as far as i can see is a false positive
<infinity> apw: Yeah, that's supposed to warn on symlinks that escape the source tree, but that one doesn't seem to.  Weird.
<infinity> apw: liintian bug, I guess.
<apw> yep ... /me looks at standards version, we have ignored it too long
<ppisati> brb
<apw> infinity, you will be pleased to know we can move to the latest standards version.
<apw> like it matters any
<apw> infinity, ok i have pushed up some fixes, seems to cover the egregious ones, and leaves the ones you indicated were benign or debian eske
 * rtg_ -> lunch
<jsalisbury> apw, re: bug 1112652 I didn't identify the specific patch that fixed the bug.  Many people affected by the bug reported 3.8.13 fixed the bug, so I was going to ask for confirmation once Raring gets those updates
<ubot2> Launchpad bug 1112652 in linux (Ubuntu Raring) "[raring] no ethernet with "auto" default power option with 82579LM" [High,In progress] https://launchpad.net/bugs/1112652
<apw> jsalisbury, there are two likely sounding patches to the e1000e driver in .13 (well at least one sounds believable as it talks about power management)
<apw> jsalisbury, sounds good, thanks.  we nom'd it to raring and closed out saucy based on the testing done 
<jsalisbury> apw, cool, thanks
<bjf> manjo, since you have -proposed enabled (you _do_ don't you?) you should have picked up the change for that issue
<manjo> bjf, yes got it though proposed 
<bjf> manjo, so you are running the -proposed kernel *and* you saw the hdmi issue your reported above?
<bjf> manjo, i'm trying to find out if the bug you saw is in the -proposed kernel
<manjo> bjf, no proposed fixed it for me. I was not running proposed when I hit the bug 
<bjf> manjo, ok, good to hear, thanks
<manjo> cool np 
 * rtg_ -> EOD
#ubuntu-kernel 2013-05-21
<diwic> cking, ping
<psivaa> apw: curious if there is an ETA for the patch you mentioned in bug 1100386
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
<apw> psivaa, hmmm, that rings a bell, but i suspect i have lost track of that
<cking> diwic, pong
<diwic> cking, hi! I've heard you've done some system debugging in your days ;-)
<psivaa> apw: the issue (the apparent hang) can be seen in saucy as well, so when ever you could find some time .. :)
<apw> psivaa, i think it was smb who had the setup to confirm the fix, i will circle with him on it
<psivaa> apw: ack, thanks
<diwic> cking, in short, I'm testing some code but for some reason it causes the i915 module (I think, not sure) to hang for ~50 seconds on boot
<diwic> cking, is there a way to figure out *where* it's stuck in those 50 seconds?
<diwic> cking, I've done some attempts with "perf top" and "operf" but I can't get them to run properly at boot time
<diwic> cking, perf top seems to require an ncurses thing and operf just does not seem to want to start, don't know why
<cking> diwic, so at least you have init up and running, hrm.. let me think
<diwic> cking, so far, I was able to use tracing, I enabled tracing/events/module/* and the last entry before the 50 second delay is "load_module i915"
<apw> diwic, have you tried taking a boot chart, and have you tried enabling initcall_debug (kernel command line option) as this also gives you begin end of initcalls for module loads regardless of when
<cking> diwic, or maybe seeing what the kernel is doing with LTTng
<apw> diwic, finally have you got a dmesg of a boot which suffered this pause
<apw> we may see something in it
<diwic> cking, LTTng requires a special kernel, right?
<apw> "in flight recorder mode" ?
<cking> diwic, you may get by using lttng-modules-dkms
<cking> s/get/get by/
<diwic> apw, hmm, next attempt will be "drm.debug=0xf initcall_debug=1", that could indeed give something
<apw> i think it is is just initcall_debug no =1
<cking> diwic, so when did this start going wrong?
<apw> yeah what does your change do
<diwic> cking, it's development of new code
<apw> in the kernel, in ?
<diwic> cking, apw in short, Intel/we are trying to build bridges between the i915 and snd-hda-intel driver for better power saving
<cking> diwic, maybe finding out what bit of new code breaks it would be useful to see why it's triggering the hang
<apw> diwic, are you adding new deps between the two modules, could we have some kind of udev loop here ?
<diwic> cking, well, I know that module_request("i915") is causing the hang, now to trying to understand why
<apw> diwic, you might want to install pitti's new udev and see if the issue is still there before trying to hard
<apw> in case it is one of those things the new udev avoids in its cleverness
<cking> diwic, perhaps for deeper tracing use http://lwn.net/Articles/365835/
 * diwic tries the function tracer too
<cking> apw, i use http://www.speedtest.bbmax.co.uk/
<diwic> okay, so the function tracer gives too much data, so I don't see the actual hang, because it's being overwritten by later data
<apw> diwic, when it hangs do you have any other modprobes running, it could be a deadlock that way
<diwic> apw, yeah, I'm thinking something like that
<apw> you should be able to see that with ps pretty easy
<apw> or in the udev log it keeps during boot maybe, perhaps pastebin /var/log/udev and dmesg so we can look
<diwic> apw, what determines if two modprobes can run in parallel or not?
<apw> diwic, that is a good question, there used to be some periods during which only one could run, but i did think they got rid of most of them now
 * apw wonders if diwic is even here
<diwic> apw, I am
<diwic> apw, indeed there are modprobes in parallel
<apw> can we see the udev log and dmesg, would give us something to look at, and the ps please
<apw> what are they
<diwic> apw, I'm using this as a method to learn kernel debugging, that's why I'm trying to analyze it myself, but in short
<diwic> apw, udev kills the i915 modprobe after ~50 s with a syslog message (or was it dmesg)
<apw> cool for learning, if you show us those things we promise to tell you what we find and why it is relevant :)
<apw> what was the other modprobe ?
<diwic> apw, snd-hda-intel is in a modprobe itself, and it tries to load i915 from its own modprobe
<diwic> apw, which starts a new modprobe
<apw> ok, did you add that yourself ?
<apw> ie does your _init do like a request_module ?
<diwic> apw, it's the .probe that does a request_module 
<apw> it that occurs in the context of the _init (and from the hang i assume it does) i think that is not allowed (tm)
<apw> you presumably want to load that module to run things in it, i wonder if you can just reference them directly
<apw> so that the module dependancy loader figures it out ... or are you trying to make it independant ?
<apw> s/independant/dependant on h/w found 
<diwic> apw, maybe switch to a private channel as this is prerelease hw
<apw> diwic, ack
<ppisati> FYI: http://lists.randombit.net/pipermail/cryptography/2013-May/004225.html
<ppisati> [cryptography] skype backdoor confirmation
<ppisati> ok, this one has more details:
<ppisati> http://lists.randombit.net/pipermail/cryptography/2013-May/004224.html
<caribou> quick question : has kexec been disabled on secureboot kernels ?
<caribou> well, signed kernels
<apw> caribou, not deliberatly, it doesn't need to be because before we get to that point we have closed boot services
<apw> caribou, that said it is not clear that kexec can work as well in that environment as we have close boot services so you can only have a normal style boot from there
<caribou> apw: ok, I vaguely remembered a discussion where kexec wouldn't work 
<caribou> apw: but maybe this is done in kexec itself, not a kernel build option
<apw> caribou, well it cannot call the 'efi secure mode' entry point, so we cannot do all the same quirking you might use in the normal run of the boot
<caribou> apw: just testing kdump on Quantal on a vmlinuz...signed
<caribou> apw: ok, thanks
<apw> np
<psivaa> jsalisbury: i've updated bug 1181315 with the result of using the upstream kernel that you asked to test
<ubot2> Launchpad bug 1181315 in linux (Ubuntu) "unregister_netdevice: waiting for lo to become free. Usage count = 2' is reported and causing kernel hang when floodlight tests are run using utah" [Medium,Confirmed] https://launchpad.net/bugs/1181315
<jsalisbury> psivaa, great, thanks.  I'll take a look shortly.\
<psivaa> jsalisbury: ack, thanks
<apw> jsalisbury, is that a base issue that smb has looked at, i have a real feeling of deja-vu with that symptom, and a feeling smb was looking at something related to it in the past (some time ago)
<rtg_> apw, I had trouble with this when entering and exiting containers, but that was a few versions ago
<jsalisbury> apw, hmm, it could be. I'll check with smb when he's online
<apw> there looks to be some openvswitch in the mix here, so ick
<apw> [  480.492344]  [<ffffffff815b490c>] copy_net_ns+0x8c/0x130
<apw> so it is entirely possible they are using namespace containers here
 * apw lunches
<apw> jsalisbury, do we have any specific wiki docs on disabling the abi checks ?
<jsalisbury> apw, not that I know of off the top of my head
<bjf> apw, we do but i think they are buried on one of the pages
<bjf> apw, looking
<bjf> apw, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance   ABI section
<bjf> apw, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
<apw> bjf, ahh thanks
<apw> bah why do kernel questions get asked on #ubuntu-devel more often than on here
<rtg_> apw, uploaded linux_3.10.0-0.1 to ppa:kernel-ppa/pre-proposed for DKMS testing
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> http://reqorts.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_stable_hot_.html
<apw> jsalisbury, hrm i assume my fookage occured at just the right time to miss this
<apw> jsalisbury, 1100386 -- Server installations on VMs fail to reboot after the installations -- that one is one i am actually working on today
<jsalisbury> apw, heh, yeah.  Don't worry, only one bug was assigned to you 
<apw> jsalisbury, anyhow i hope to have fixes out for that today, just having some "fun" because we have just today shifted from udev to systemd packaging for udev binaries
<jsalisbury> apw, cool,thanks
<apw> jsalisbury, just put an update in the bug and nomed it all over the shop
<jsalisbury> ##    
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> apw, thanks, nom nom
<henrix> jsalisbury: i'm confused, are you sure its already 17:00 *UTC*?
<jpds> henrix: 1600 UTC.
<jsalisbury> henrix, sorry, I'm daylight savings challenged
<henrix> jpds: yep, that's what i thought. thanks :)
<jsalisbury> The meeting is in an hour
<jpds> jsalisbury: o/
<rtg_> jsalisbury, just uploaded pciutils for saucy. try installing saucy on that SDP in awhile to see if lspci recognizes the Broadcom gizmo.
<jsalisbury> rtg_, will do
<jsalisbury> rtg_, Will pciutils be included if I just build the latest Saucy tree?
<rtg_> jsalisbury, it is a separate package from the kernel
<apw> jsalisbury, i think he is saying you can just upgrade pci-utils once it is built
<jsalisbury> rtg_, apw, ahh right
<jsalisbury> rtg_, my external usb keyboard/mouse breaks on that system with 3.10-rc1 and rc2, but works on 3.9, so I'll also bisect that
<jsalisbury> <jsalisbury> ##    
<jsalisbury> <jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> <jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 28th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * rtg_ -> lunch
<infinity> BenC: *nudge*
<infinity> BenC: So, all that's left to do on #1181305 is for you to do some install/reboot smoketesting with the binaries in -proposed on a couple of machines and let me know if they're horrificially broken.
<infinity> BenC: I'll test powerpc64 on my POWER5.  Not sure I want to disrupt my firewall to test powerpc32, but if 3 out of 4 flavours are good, we're probably in good shape.
<infinity> BenC: Then we twiddle the regress-testing task, and wait patiently for master to pass its more extensive testing.  Once master is ready to promote, the bot with automagically mark ppc ready too (if we've done all our bits).
<infinity> s/with/will/
<apw> rtg_, ogasawara, i have just merged kernel-wedge from debian, minimal changes, but just in case fyi
<rtg_> apw, ack
 * apw relocates to a more comfy location
<BenC>  infinity: works for me on ppce500mc
<marvin24> hi
<marvin24> does anything speak against enabling ARCH_TEGRA in 3.10?
<marvin24> it has been converted to multiarch
<rtg_> marvin24, can't see why not.
<marvin24> well, it could harm, but there is still plenty of time to test ...
<rtg_> looks like there are plenty of tegra models supported
<marvin24> yes, all reference boards and some others also
<marvin24> so we get tegra2/3 and 4 support and ~10 boards
<marvin24> or 15
<infinity> BenC: Kay.  I'm doing a glibc build on my POWER5 to look for testsuite regressions, I figure that's a reasonably sane kernel test. :P
<rtg_> marvin24, I does not appear that you can enable CONFIG_TEGRA with trashing CONFIG_ARCH_MULTIPLATFORM
<rtg_> without*
<marvin24> rtg_: urg
<marvin24> rtg_: will check
<chiluk> Hey guys I've been working on https://bugs.launchpad.net/ubuntu/+source/ncpfs/+bug/1035226
<ubot2> Ubuntu bug 1035226 in ncpfs (Ubuntu) "Can't remove directory from NCP server" [Undecided,Confirmed]
<chiluk> which is actually an upstream kernel bug as well.
<chiluk> I've bisected the commit using lucid to 1d2ef5901483004d74947bbf78d5146c24038fe7
<chiluk> using mainline-build-one 1d2ef5901483004d74947bbf78d5146c24038fe7 lucid.
 * rtg_ -> EOD
<chiluk> however when I run mainline-buildone 1d2ef5901483004d74947bbf78d5146c24038fe7 precise, and test on precise rmdir works, but rm -rf fails with device busy.
<hallyn> i have /proc/locks showing me 1: FLOCK  ADVISORY  WRITE 20035 00:12:10525 0 EOF.  task 20035 which locked inode 10525 no longer exists.  how can i tell which task is holdign that fd open?
<chiluk> hallyn  task 20035
<chiluk> but it no longer exists.
<chiluk> locks need to be unlocked.
<chiluk> iirc
<hallyn> but whenthe task exits the fd should be closed, and then (flock manpage claims) flock is released
<chiluk> unless the process gets killed or exits badly.
<hallyn> so long as it isn't stickign around as a zombie, i would expect the cleanup gets done int he kernel no matter how the task dies...
<hallyn> or does flcok cleanup happen in userspace?
 * hallyn goes rooting through fs/locks.c
<chiluk> the lock release should probably get initiated from userspace.
<chiluk> or even the close for the at matter
<chiluk> so anyone have any clue why building the same commit id for lucid works where building it for precise fails?
<josepht> jsalisbury: bug 1180513 has been updated
<ubot2> Launchpad bug 1180513 in linux (Ubuntu) "lid close actions are ignored laptop always suspends" [Medium,Confirmed] https://launchpad.net/bugs/1180513
<chiluk> hallyn does lsof or fuser return anything useful?
<hallyn> chiluk: oh, i think i've found it.  debootstrap seems to be firing off a running udev
<hallyn> stgraber: ^ this is bad.  presumably due to the saucy udev change...
 * hallyn does one more run to verify...
<stgraber> hallyn: hmm, yeah, that could have been triggered by the new udev, blame pitti :)
<hallyn> stgraber: trivial to reproduce now:  ( flock -x 200; debootstrap saucy xxx; ) 200>/tmp/zzz
<hallyn> stgraber: markd it as affecting udev.  as per usual, i expect to get smacked over it before it's all over :)
#ubuntu-kernel 2013-05-22
<enseven> Hi all! I am trying to hotplug USB disks automatically to a KVM virtual machine. What I found is: I get a lot of trouble, when a USB disk has been attached to the VM, because it is not accessable from the hypervisor any more. What I see is, that it is added to the SCSI subsystem "lsscsi" and that tries continuously to access it generating error messages in "dmesg" and "syslog". One solution I found is: Prevent the loading of the  "us
<enseven> b_storage" module on the hypervisor.  But that's not the way I'd like to handle it, because this prevents the use of USB disks in general. Is there a way to prevent the kernel from adding particular USB disks (recognized by VendorID and ProductID) to the SCSI subsystem? Where can I find some documentation about these mechanisms?
<enseven>  Thanks & best regards! :-)
<apw> NikTh, ok your build issue there is you have added new components via your patches
<NikTh> Yes apw 
<apw> and not updated the configuration with the new options
<apw> run this and answer the questions, and commit the result: fakeroot debian/rules updateconfigs
<NikTh> I have running make xconfig and saved the .config .. what else I must do after this ?
<NikTh> apw: The command gave an error. See : http://pastebin.com/gKFSizE9
<apw> NikTh, you must run: fakeroot debian/rules updateconfigs
<apw> NikTh, ahh you are using the .dsc package not the git repo
<apw> NikTh, you need to chmod +x debian/scripts/misc/*
<ogra_> apw, bug 1182829 ...
<ubot2> Launchpad bug 1182829 in initramfs-tools (Ubuntu) "initramfs-tools should allow building module-less generic initrds" [Undecided,New] https://launchpad.net/bugs/1182829
<NikTh> apw: http://pastebin.com/kc6tEjms (the overrides messages are too many, I did't copy-paste them all, if you need them all tell me). Now I have not a debian/rules file at all.. LoL
<NikTh> Is so F...ing difficult to build a custom-kernel onsite (Launchpad) and so easy to build it locally.. dmn :P 
<apw> you can ignore the overrides issues
<apw> you need to make config-check executable it seems, chmod +x debian/scripts/* debian/scripts/misc/*
<apw> it is much easier to use the git tree than a source tarball, as that is how we do all of ours
<apw> and threfore any wrinkles like this are covered off
<apw> making a local kernel just for oneself is easy indeed, doing it 'right' so that the archive can grok it is always going to be much harder
<apw> NikTh, remember the source pacakge you are producing produces binaries for all supported architectures, not just the local one as you get when you do a local build
<apw> it is a much more complex animal than just a build
<NikTh> I have no debian folder at all right now. Only debian.master.. I thing it purged out (rm -rf ) . Any documentation for git ? or just git clone <tree> and then the same procedure ?
<smb> NikTh, Have you seen this? https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<NikTh> Well, you know what? I will try one more time with tarball , because so many times I have done this procedure I remember it without read anything.. LoL. When I get to the point of chmod +x .... I will update here.
<NikTh> smb: Thanks. Really I don't remember , probably not. I have read so much these 2-3 days that my mind blown. 
<apw> the kernel is one of the more esoteric packages in the archive, it has to produce so much junk to let us make bootable CDs and the like
<NikTh> Ok, to be sure I ran the command twice. The first time itÂ  did the checks with questions, the second did the checks without questions. Which means that the update was done properly (if I'm not mistaken)
<NikTh> I'm speaking about fakeroot debian/rules updateconfigs
<NikTh> I didn
<NikTh> I didn
<NikTh>  I did not run fakeroot debian/rules editconfigs (I prefer the graphical make xconfig instead) . No problem with that.. (?)
<smb> Many problems with that. Main one being that this creates .config in the top level dir which is not used at all by the debian build
<NikTh> smb: So I must first run fakeroot debian/rules editconfigs and then fakeroot debian/rules updateconfigs ? 
<smb> NikTh, With a new option that has no default, no. It will (or should) just ask you how to set things when running updateconfigs
<NikTh> Ok. I did that. I answered Yes to questions. 
<smb> If you want to change things from current values you had to either run editconfigs or edit the files in debian.master/config
<NikTh> It seems to work now.. I will cross my hands for Launchpad Builder.. We will see.. :P 
<smb> So it should be ok but just make xconfig is unneeded the least
<smb> Rule of thumb with debian packages: calling anyting with make directly is bound to be wrong
<NikTh> Last question smb : If I want to change something in current configuration (eg: Processor Type and features to point to AMD or Intel ) which command is better ? make xconfig or fakeroot debian/rules editconfigs
<smb> NikTh, Isn't the answer to that obvious from what was said above? ;)
<NikTh> I guess the second , but don't ask me why. Locally always I used make xconfig to change the configuration.. 
<NikTh> Yes it is obvious. 
<smb> The thing is whether you just use the kernel make infrastructure or the debian packaging
<smb> when you run fakeroot debian/rules it will always use what is in debian.master/config to create new config files per flavour in debian/build/... 
<smb> Whatever "make xconfig" has done to .config is ignored
<NikTh> per flavor . Yes, I think that's the secret key here. It would be better for a newbie (like me) to learn ONE procedure either locally or onsite to build a custom kernel.. but differences are small as I can see.. small but important
<NikTh> Well, thanks for all the help guys.. I'm not here to learn , I don't ask for a teacher , I must read more docs I guess and make more mistakes to learn actually.  We'll see how it goes. 
<smb> For that I would point back to the BuildYourOwnKernel wiki. This is the documentation we can control. Unfortunately there is plenty of instructions we cannot.
<apw> amen to that
 * henrix -> lunch
<marvin24> rtg_: yesterday you said: "marvin24, I does not appear that you can enable CONFIG_TEGRA with trashing CONFIG_ARCH_MULTIPLATFORM"
<marvin24> do you mean that some config options get also changed
<rtg_> marvin24, based on some quick testing, CINFIG_TEGRA is mutually exclusive with MULTIPLATFORM
<marvin24> I enabled it on the Ubuntu-3.10.0-0.1 branch and it worked without problems
<rtg_> I'll look into it a bit more today. if tegra can be enabled in the multiplatform kernel, then we should
<marvin24> only minimal changes to the config 
<marvin24> I don't know if nr_gpios is important though ...
<rtg_> marvin24, cool, send a patch to the k-team list.
<marvin24> ok
<rtg_> I'm pretty sure I only tried it on 3.9
<marvin24> ah, multiplatfrom was only enabled in 3.10
<marvin24> (I mean for tegra)
<rtg_> marvin24, I'll switch saucy over to 3.10 around rc3 or 4. its still a bit steamy...
<marvin24> rtg_: np, there is still plenty of time ... I also need to test 3.10 on my ac100 first
<marvin24> but it would be great if I could boot the default ubuntu kernel on it
<rtg_> biab
<enseven> I got the solution: If you attach the USB disk by udev to the VM, it is done so quickly that the SCSI subsystem cannot catch it. The problem only occurs if you attach it manually, when the SCSI subsystem has already caught it.
 * ppisati goes out to run an errand, brb
 * henrix -> back in 15
<NikTh>  waiting
<apw> NikTh, waiting for what ?
<NikTh> apw: nothing. This message was a mistake of mine when I tested some commands on IRC (on another channel). It seems that /AMSG sends the message to all channels. LoL
<NikTh> apw: Actually I'm waiting for building the binary packages on Launchpad. :-) 
<sconklin> apw: I see some weirdness in the CVE tracker status changes this morning. CVEs have switched the pending version from the kernels in -proposed, to one which was already released.
<apw> from and to ?
<apw> are they from the new -22 to the old -20 ... or whatever, from the version which is pending now to the one which didn't make it out ?
<apw> sconklin, ^^
<sconklin> CVE-2013-3076:
<sconklin> -raring_linux: pending (3.8.0-22.33)
<sconklin> +raring_linux: pending (3.8.0-20.31)
<apw> so how did the -22 get in there i wonder
<sconklin> yes
<sconklin> -22 is in proposed now
<apw> i am trying to understand how the autotirager would ever have said -22
<apw> the issue is that the first release they are in _is_ -20, just it didn't release
<apw> so i would have epxected it to make that error always, so wondering why it
<apw> went to -22 first, then changed its mind, that seems wron
<apw> odd
<sconklin> agree
<apw> anyhow ... so the issue here is we have a tag for 3.8.0-20.31 which the autotriager sees, which is actually not really a valid tag
<apw> sconklin, i am going to have a think about it, as really we should only consider the version which have been in the -release/-updates pocket, not all tags
<apw> sconklin, don't accept its changes fro the moment, they are clearly balls
<sconklin> apw: ok, I won't push this back up
<sconklin> This is why we have a human in the loop
<apw> sconklin, thanks ... i will prolly just hack it so we can exclude tags to start with, but we ought to get launchpads idea of them
<apw> sconklin, so very very true
<henrix> sconklin: its probably due to some manual fixes jj has done for the emergency kernel
<apw> henrix, yeah that all makes sense, i'll do something to the tool to make it do the right thing; so it doesn't undo his bits
<henrix> apw: ack, thanks. sconklin ^^
<apw> sconklin, which releases did this happen on ? 
<apw> sconklin, i thought we wern't going to commit these changes?  it seems we have, at least when i pull i get the -20 version
<rsalveti> <sergiusens> rsalveti: ok, manta is now using the saucy ubuntu kernel (after a repo sync ;-) )
<rsalveti> apw: rtg_: ^
<apw> rsalveti, nice 
<rtg_> rsalveti, thats pretty funny. I _just_ sent an email about kernel status.
<rsalveti> so mako + manta should be using the ubuntu kernel starting next build
<rtg_> rsalveti, grouper too, right ?
<rsalveti> rtg_: I'll test maguro later today, but grouper is not yet in a good shape
<rtg_> ah
<rsalveti> it's booting and working with the ubuntu kernel now
<rsalveti> but it seems I cannot open apps with it
<rsalveti> and I don't have the hardware anymore, so would need help from the kernel team
<rsalveti> might be a config issue still
<rsalveti> probably related with binder
<rtg_> rsalveti, I have an N7
<rsalveti> rtg_: mind flashing our latest N7 image and then updating to our kernel?
<rtg_> rsalveti, yeah, was just gonna do that
<rtg_> saucy, right ?
<rsalveti> rtg_: first give it a shot with the default kernel from our image, see if the shell is working as expected (opening apps properly and such)
<rsalveti> rtg_: yes
<rtg_> ack
<rsalveti> abootimg -u /dev/block/platform/sdhci-tegra.3/by-name/LNX -k <vmlinuz>
<rsalveti> you probably know already, but just in case
<rtg_> rsalveti, I didn't, so thatnks. that save me some time
<rtg_> mmm, may have to wait for battery charge
<apw> rsalveti, can you get the old one off the saem way, so you can put it back ?
<rsalveti> apw: yup, but you'd need to extract the boot.img file
<rsalveti> with abootimg itself
<apw> rsalveti, well i would be happy with 'give me blob i can give you back' for when i brick it again
<rsalveti> right, but the easier way to restore a broken kernel is by flashing the boot.img via fastboot
<apw> ahh
<rsalveti> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/20130522/raring-preinstalled-boot-armel+grouper.img
<rsalveti> for example
<rsalveti> boot into fastboot
<rsalveti> fastboot flash boot raring-preinstalled-boot-armel+grouper.img
<rsalveti> apw: rtg_: it seems there's a crash when opening the camera app with manta
<rsalveti> it reboots right after opening the app (which starts the camera hal)
<rtg_> rsalveti, we should be able to start opening bugs in LP against these kernels.
<rsalveti> yeah
<rsalveti> need to dig a bit further, not sure if the kernel is actually the culprit here
<rtg_> apw, how about something like linux-generic-lts-raring-to-14-04
<apw> rtg_, heh other than the nasty mixture of raring and 1404
<apw> especially if it was 14.05 or something which is 'slightly' possible
<apw> lts-generic-lts-raring-upgrade
<rtg_> apw, ok, how about linux-generic-lts-raring-to-the -next-lts
<apw> lts-generic-lts-raring-autoupgrade
<apw> they are alll so very long and not ver obvious
<apw> very
<rtg_> autoupgrade isn't very specific
<apw> nope, no better indeed
<apw> what does it mean ... we want ... -upgrade-at-end-of-support
<rtg_> but actually, its not that bad either.
<apw> which is hard to fit in a short word
<apw> -eol-upgrade
<rtg_> apw, autoupgrade is kind of growing on me. eol-upgrade isn't too bad either
<apw> we need X to do the same of course
<rtg_> apw, not my problem :)
<apw> yeah :)
<rtg_> though it would be nice if they used the same scheme
<arges> smb: hello
<smb> arges, Hey, just was wondering 
 * rtg_ always wonders when arges shows up
<arges> don't worry... no bad news
 * rtg_ -> work
 * rtg_ just received an 8 bay RAID cabinet.
<marvin24> rtg_: so you can use the saved time to answer questions  ...
<marvin24> do you see __bad_udelay during kernel compile?
<rtg_> marvin24, on 3.10-rc2 ?
<marvin24> nsp32.c and nouveau use udelays > 2000, which fails on tegra
<marvin24> rtg_: yes
<rtg_> marI haven't compiled for armhf yet
<rtg_> marvin24, ^^
<marvin24> it should be the same for all arm socs
<marvin24> I think I've seen this in 3.8 also
<rtg_> I've been distracted by Ubuntu touch kernels
<marvin24> at least I disabled these drivers because of this
<marvin24> rtg_: yes, ancient versions ...
<marvin24> I'm happy not to deal with 3.1 kernels anymore
<kees> ogasawara: say, how receptive would you be to taking an ARM-only patch to enable seccomp-bpf on precise? The changes are relatively minor (since it just calls into the existing seccomp-bpf infrastructure that was put in place for x86)
<ogasawara> kees: I don't think I'm personally opposed, send it on over.  bjf, rtg_: ^^ thoughts?
<bjf> kees, ogasawara first thought is I don't see any issue
<rtg_> no patch, no opinion
<kees> heh, fair enough. I'll spin it up so you guys can look at it. thanks!
 * rtg_ -> EOD
<rsalveti> apw: just sent 2 config-related patches to make the camera to work with nexus 10
<rsalveti> seems that is the only remaining regression with this kernel
<rsalveti> going to test maguro now
<apw> rsalveti, ack thanks
<rsalveti> the second one is just to enable /proc/net/wireless, requested by the sdk folks
<NikTh> Here I am again. You will never get rid of me :P 
<NikTh> New build error. As I guess I must add something in debian/rules, but what ? 
<NikTh> Error here: https://launchpadlibrarian.net/140487585/buildlog_ubuntu-raring-amd64.linux_3.8.0-21.32ubuntu1~bfsbfq0_FAILEDTOBUILD.txt.gz
<NikTh> Ohhh ! Boing ! This was an old message (e-mail) . Now I saw the package version. It seems that we had a delay in delivering.  Sorry !! Ignore all above. At Launchpad page (my PPA) seems that is currently building (still)
<NikTh> But no. As I refreshed the Launchpad page says "1 failed , 1 pending to build" . So I guess that is the report is correct. Dmn ! Forgive me, because this is the 5th failure and I'm little bit confused. Anyone who knows why build failed ?
#ubuntu-kernel 2013-05-23
<melkor> How does it happen. 3.8, no microphone. 3.9 microphone but no usb camera.
<smb> infinity, Do you happen to be awake? 
<apw>     activation/volume_list configuration setting not defined: Checking only host tags for datavg/smarm-s32
<apw>       datavg/smarm-s64 is active exclusive locally
<apw>       Locking LV grYo1SGxtnZW9nKNg12eDppfJtGHwsZecfziYaHzn4KqomE8EJcIrmMxBJRjRHgK (R)
<apw> smb, ^^
 * smb scratches his head
<ppisati> seems like i've to update my email cfg... uh...
<apw> ppisati, oh crap, that means i have to too
<ppisati> apw: if you didn't opt-out, then yes, you have too
<ppisati> FWIW, i took 5mins, everything seems to be ok here
<apw> ppisati, care to /msg me any pointers you have :)
<ppisati> apw: i just had to change imap server/pwd
<apw> ppisati, was your email moved over, your old email ?
<ppisati> apw: yep
<apw> ppisati, bugger
<ppisati> but i don't new emails... uhmm...
<ppisati> *don't get
<ppisati> apw: are you using offlineimap? if yes, i hit this: http://docs.offlineimap.org/en/latest/FAQ.html#what-is-the-uid-validity-problem-for-folder
<ppisati> apw: i'm redownloading all my emails right now
<apw> ppisati, i am assuming i will not move mail email across now as a local cache anyhow
<ppisati> apw: i see
 * ppisati -> workout
<apw> smb, remembered to file that bug: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1183346
<ubot2> Ubuntu bug 1183346 in lvm2 (Ubuntu) "vgcahnge -a n removed dm mappings but they come back immediatly" [Undecided,New]
<smb> apw, Ah cool. Now we only need to find out whom to annoy about that whole plumbing thing
<apw> yeah
<apw> i would think slangasek would know best who knows the lvm/udev interactions best
 * smb suspects lvm2 as package is not right but anyway
<smb> him or maybe xnox ...
<xnox> smb: apw: sounds like a dupe.
<apw> apport didn't offer me any to choose from, though i guess that might be my spelling
<apw> xnox, got a reference to the original
<xnox> a long time ago keybuk & pitti (?! or possibly someone else from kernel/security from that time) actually came up with how it should properly behave.
<xnox> imho - we shouldn't trigger activation on change event (which is emitted in addition to the removed event)
<xnox> apw: yeap, let me look it up.
<xnox> but I'm not certain, what would be the consequence of removing such trigger.
<apw> no indeed
<apw> xnox, but early in saucy is a perfect time to test such scarey changes
<smb> xnox, apw Experimenting with a precise userspace + quantal kernel it seems that back then I do only get remove events
 * smb wonders when and why the change event comes from
<smb> apw, IIRC you said the change event is for the now free underlying /dev/sd??
<xnox> apw: marked as duplicate of bug 1088081
<ubot2> Launchpad bug 1088081 in lvm2 (Ubuntu) "udev rules make it impossible to deactivate lvm volume group with vgchange -an" [High,Confirmed] https://launchpad.net/bugs/1088081
<apw> smb, that is correct, i believe as the sda2 is closed a change is generated telling you it is no longer locked exclusivly
<apw> xnox, ta
<apw> smb, though that begs the question what does dmsetup remove do different that stops that happening
<smb> Ah, interesting. That dupe bug rather seems to indicate that udev is creating the change event and not the kernel (which was not completely clear to me)
<smb> Yeah, good question
<apw> it does the same stuff looking at udev, but we get no sda2 event, so there is a subtlty
<apw> i bet this is a bug in the libdm in lvm2
<smb> apw, One difference seems to be that lvm2 depends on libdevmapper-events (which the same source produces) while dmsetup does not
<apw> hmmm
<stgraber> hallyn: hey, are you running an up to date saucy kernel with the stock lxcbr0?
<hallyn> stgraber: no, not yet
<hallyn> will probably upgrade everything this weekend
<stgraber> hallyn: ok, I think the current kernel breaks dhclient
<hallyn> hm.  i've got a canonistack instance set up, lemme try it
<marvin24> rtg: 3.10 needs several patches so it compiles on arm (broken non-arch related drivers)
<stgraber> hallyn: not sure if you're familiar with the dhclient UDP checksum offloading issue that affected virtio, basically the kernel tries to be clever and not compute the checksum when on a virtual device
<stgraber> hallyn: then dhclient gets a DHCP packet without checksum and ignores it
<marvin24> rtg: most of them are already published on linux-kernel ml
<rtg> marvin24, I imagine they'll get hoovered up sometime before Linus releases
<hallyn> stgraber: yeah...
<stgraber> hallyn: that used to be limited to virtio and libvirt has been working around it for a while by using a mangle rule, but now cjwatson just reported the same happening with veth devices (and I reproduced it here quite easily)
<hallyn> why the hell would veth do that?
<marvin24> rtg: it seems to me that some got lost
<marvin24> rtg: I'll try to trigger the relevant people ...
<stgraber> hallyn: my assumption being that this breaks LXC containers that runs anything earlier than quantal
<stgraber> hallyn: it looks like something that changed with 3.9 (just managed to reproduce this with 3.9.0-0-generic)
<cjwatson> 3.9 would be roughly consistent with my experience, yeah
<stgraber> hallyn: so I think what I'll do is upload the remaining two SRUs for this (lucid and precise) adding the needed code to dhclient to deal with the missing checksums.
<hallyn> stgraber: flaky internet at home, heading out, will be back in a bit.
<hallyn> stgraber: sounds good.
<psivaa> infinity: just to let you know the regression testing for linux-ti-omap4: 3.5.0-225.36 is still going on. 
<psivaa> i've had to re-run them a couple of times due to lab maintenance 
<psivaa> for bug 1180204 that is 
<ubot2> Launchpad bug 1180204 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.5.0-225.36 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1180204
<slangasek> apw: I thought you were the expert on lvm/udev ;)
<apw> slangasek, i am fingering smb (phnar) for this
<smb> apw, phnar?
<ppisati> robher_: do you know that cpu hotplug doesn't work on highbank?
<ppisati> robher_: i saw the support was committed together with the initial platform support in 3.2
<ppisati> robher_: but it didn't work and it's still broken
<hallyn> stgraber: so with those SRUs done, openstack can drop the special iptables rules?
<ppisati> robher_: http://paste.ubuntu.com/5693960/
<stgraber> hallyn: as long as you don't run any guest that doesn't have the patches (like Debian)
<hallyn> right
<arges> hey guys noticed something about a patch in 3.5:
<arges> git tag --contains f56d0eed546c83bbc5ad3052a809077341ce28f3
<arges> shows this patch is in 3.5.0-225.36 / 29.49 / 31.52
<arges> but it seems to not be in 3.5.0-30.51 ? why would it have been dropped in an inbetween release? (its a linux-stable patch)
<arges> maybe this is a henrix question ^^^
<henrix> arges: let me have a look...
<henrix> arges: oh, i got it.
<henrix> arges: we had an emergency kernel and that kernel was prepared in a branch
<henrix> arges: while there was another kernel prepared in master that contained that commit
<henrix> if you use gitk to visualise the branches its easy to understand this ;)
<stgraber> cjwatson: turns out porting a patch for isc-dhcp 4.2 to dhcp3 3.1 is a real pain ;)
<cjwatson> stgraber: heh, not surprised
<infinity> smb: I was awake when you pinged, but not at a computer, apparently.
<smb> infinity, That was the other possibility. It was just my routine of trying to push forward with the Xen updates business. If possible.
<infinity> smb: Has your pet Andy failed to review and sponsor your stuff?
<smb> infinity, I try to not neglect my favourite sponsor
<smb> or the other one
<infinity> And you refuse to say which is which, right? ;)
<smb> Of course. :)
<smb> infinity, Somehow it more or less ends up in a split of xen you and the rest apw. That may result in a slight imbalance currently
<smb> But then this update is a bit special so it might end up in your judgement anyway
<n0yd> Hi, I know this isnt ubuntu support per se. But I have already asked in two support channels, and waited quite awhile. And no one can answer me
<n0yd> So, my issue is this:  I have installed a custom kernel and headers that I am using. It works perfect
<n0yd> but I would like to completely remove the default ubuntu kernels from the repos
<n0yd> I know how to just simply remove them via apt, but there seems to be a meta package that causes them to reinstall when I do an upgrade
<n0yd> I dont know which meta package it might be, or even how to find it.  I figured you since a lot of you test kernels often, someone might know how to stop the default kernels from installing themselves
<n0yd> Its not a huge issue, I just dont like the clutter on my grub list
<rtg> n0yd, its gonna be something of the form linux-image-{server,generic}
 * rtg -> lunch
<bjf> n0yd, dpkg -l | grep linux-image-
<n0yd> ahg ok, i never tried the generic image pkg
<n0yd> So that must be it
<n0yd> I just removed the normal image pkg and the two header packages
<n0yd> bjf: thank you very much for the help, gonna try it now
<n0yd> bjf: well, I just tested it.  Works fine. Much thanks
 * henrix -> EOD
 * rtg -> EOD
<chiluk> is there a way to make fakeroot debian/rules only rebuild what's needed to be rebuilt?
<chiluk> I've been using fdr binary-generic flavours=generic      for development builds, but waiting 40 minutes between spins is slow!
<infinity> plars: *poke*
<plars> infinity: hi
<infinity> plars: How long would it take to get the regression-testing task closed out for the last three SRU kernels (ti-omap4/precise, lts-quantal/precise, lts-raring/precise)?
<plars> looking
<plars> that would be...
<plars> https://launchpad.net/bugs/1181023
<ubot2> Ubuntu bug 1181023 in Kernel SRU Workflow "linux-lts-raring: 3.8.0-22.33~precise1 -proposed tracker" [Medium,In progress]
<plars> https://launchpad.net/bugs/1181071
<ubot2> Ubuntu bug 1181071 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-31.52~precise1 -proposed tracker" [Medium,In progress]
<plars> and, don't see the other one, but I'm not looking in the best place, one sec
<infinity> And http://launchpad.net/bugs/1180358
<ubot2> Ubuntu bug 1180358 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.2.0-1432.41 -proposed tracker" [Medium,In progress]
<plars> right
<plars> was just about to paste
<plars> ok
<plars> so on 1180358, I hit a problem, pinged bjf[afk] and jdstrand about it
 * infinity finds http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html is about the best place to keep track of where things are hung up.
<plars> I'm not sure if I've heard back yet, still trying to deal with the chaos of mail filters today
<plars> will dig for that in a moment
<infinity> Ahh.  What was the problem?
<plars> infinity: a few failures, looked to be timeout related stuff in qrt
<plars> I suspect it just didn't cope with timing properly on the panda, but wanted some confirmation from one of them
<plars> the other two seem to have just arrived, I'll get those kicked off right now
#ubuntu-kernel 2013-05-24
<infinity> plars: (If there's anyone you can hand off those regression-testing tasks to, I'd like to be able to release those kernels tonight to clear the road for more, if possible)
<plars> infinity: good timing, one of them *just* finished, the other is still in progress
<infinity> plars: Kay.  Those would be the LTS ones?  What's the continuing story with ti-omap4?
<plars> infinity: the omap4 one was done much earlier, but we had a couple of failures
<infinity> Were all the failures just whacky timing issues?  Reproducible (or haven't had time for a second test run)?
<plars> infinity: https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1181023 is the one that just finished
<ubot2> Ubuntu bug 1181023 in Kernel SRU Workflow "linux-lts-raring: 3.8.0-22.33~precise1 -proposed tracker" [Medium,In progress]
<infinity> plars: Lovely.
<plars> infinity: on omap, reproducible, two runs were done (they take 8+ hours each)
<infinity> Hrm.  Curious.  Do you have output anywhere that I can try to digest?
<plars> infinity: I can set it up with the previous kernel and run it there and see if we get the same result
<infinity> Or that.
<plars> if so, it wouldn't be a regression for sure
<plars> infinity: but won't know anything until morning
<plars> infinity: because it will take that long to run
<infinity> Well, testing if it really is a regression would be good, but I'm also curious what the exact failures are.
<plars> infinity: I can forward you the mail, one moment
<infinity> (If we release everything except omap4, that won't hurt my feelings much either)
<plars> infinity: sent
<plars> infinity: because those other two were in parallel, this other one for quantal lts has a few hours to go because it was waiting on system. So far it has all passed though
<infinity> Hrm, that log is curious.
<infinity> Did you reboot between the first and second test run?
<infinity> And does dmesg show anything weird?
<plars> infinity: yes, I did reboot
<plars> infinity: what was changed in this sru?
<infinity> plars: Same as was changed on every other arch, if that's helpful. :P
<infinity> (I'm looking now to see if there was anything ARM-specific and obviously scary)
<plars> infinity: if it helps, the test description is only         '''ptrace allowed only on children or declared processes'''
<plars> infinity: not horribly familiar with what these tests are trying to do though I'm afraid
<plars> this is all stuff from the security team
<infinity> plars: Yeah, I'm fairly sure I know what the test will be trying to do, but I'm not seeing any obvious reasons why it would be failing all of a sudden.
<infinity> plars: I guess we'll wait on your results tomorrow, and if it's broken the same way, dig deeper.
<plars> infinity: ok
<plars> I'll get this set back up with the old kernel
<infinity> plars: But the whole "tar no can read files, HALP" thing afterward, after a "sudo chown -R" points more the "maybe the system just got very confused and pooped itself" or similar. :P
<infinity> s/more the/more to/
<plars> infinity: the " Cannot stat: Permission denied" on the tar?
<plars> infinity: I think that's just a missing sudo
<infinity> plars: That makes little sense, given the line directly above.
<plars> I've heard that's not new, so I'm ok with that one. It needs to be fixed though
<infinity> plars: We explicitly chown all those files first.
<infinity> ("We" being the test, I have nothing to do with this testsuite)
<plars> infinity: well, as it stands on the system post-testing, the file doesn't exist
<plars> yes, nor do I except to run it
<plars> I'd like to dig into it a bit though
<infinity> plars: ETA on lts-quantal?  Or did you abandon me for, like, having a life? :)
<plars> no, just lying here in a puddle of drool
<plars> infinity: it's running, I would have thought it to be done by now, there are only two systems left, but all the others look ok with the exception of a "out of space" error on one test that seems to have been seen before. Will check the lab set up to see if that's something like a too small disk, or just a buggy test not cleaning up previous messes
<plars> ok, one just finished, one more left
<infinity> \o/
<plars> infinity: it's done, all good
<infinity> plars: Yay, thanks.
<plars> infinity: the panda (prev kernel) test is running too
<plars> infinity: I'm going to go pass out now, good night
<apw> chiluk, if you remove the build stamp from debian/stamps (it has build in its name) then in theory it 'continues' rather than restarting
<NikTh> Hello.
<NikTh> Question: Can someone tell me why the "~" character is not allowed in package name ? Read here another build failure of mine. https://launchpadlibrarian.net/140581585/buildlog_ubuntu-raring-amd64.linux_3.8.0-999~bfsbfq1_FAILEDTOBUILD.txt.gz
<NikTh> I have already uploaded a package with this.. tilda (I think is the name) character inside and I had no problem. 3.8.0-21.32nikth1~bfsbfq1
<NikTh> But this time I have a problem. I changed the ABI number because I didn't want users who add my PPA to upgrade the Official Ubuntu kernel with mine. I want to install (if they  want) a new kernel version manually.
<apw> NikTh, indeed ~ is valid in a version not in a package name
<apw> NikTh, that is a debian dpkg limitiation.  the kernel copies the version before the first - in the version into the binary package names, which means you cannot have a ~ before the first - in a version in the kernel packages
<NikTh> apw: sorry but I need to understand this little better. This pacakge name is correct: 3.8.0-21.32nikth1~bfsbfq1. This package name isn't correct : linux_3.8.0-999~bfsbfq1 . What is the major difference here? And how can I set up a correct name that will indicates a completely different version.
<NikTh> A completely different version so when a user add my PPA this will not upgrade the Official Ubuntu kernel. But if he/she want to install my kernel he/she must do it manually.
<apw> it is actually everything to the first . following the first - that is copied out of the version into the package names
<apw> therefore you cannot add a ~foo to the ABI number
<apw> and anyhow 999~foo would sort higher than any version we would use 
<apw> so you would still upgrade the kernel regardless
<apw> i cannot see why you would care if your package upgrades their kernel
<apw> surely the point of adding you PPA would be to get the kernel and you
<apw> want that to be automatic.  if the PPA has other things in it, you might really want
<apw> a new PPA for this kernel alone
<apw> you can have more than one iirc
<NikTh> Ohh.. so I miss a dot here ? Correct name would be: 3.8.0-99.9.1~bfsbfq1 ?
<NikTh> sorry I meant : 3.8.0-999.1~bfsbfq1
<NikTh> apw: Yes, I don't have a problem to create a new PPA for this propose. I just consider this upgrade thing as .... dangerous ? Better would be to install new kernel Insead of upgrade the current one.
<NikTh> I screwed up ABI number. And the builder thought this 999~bfsbfq1 was the ABI ? Am I correct ?
<apw> NikTh, right, you cannot have a ~ in the name of a package, which includes the ABI number, which you set to 999~b...
<NikTh> apw:  Do I must edit the debian/control file in order to create a new custom name ? For example the name : linux-nick 3.8.0-23.foo.32 I think is correct and also I will achieve my goal (not upgrade ubuntu's kernel), but of course it conflicts in debuild -S 
<apw> NikTh, in principle that would be ok, but in practice the kernle produces prodigious numbers of ancillary packages which also would need to be changed to prevent their kernel being replaced
<apw> NikTh, using your own ABI number which is high like 500 or whatever (but without any text in it) would at least keep it separate and non-overlapping
<apw> NikTh, _but_ it will be preferred over all of our kernels regardless of version
<NikTh> apw: So if anyone add my PPA, he/she will install a custom-kernel and Ubuntu kernels will not be replaced, BUT he/she will not receive any updates in future from Ubuntu official kernel because of ABI number. No, this is not good (IMO). I want a separate package, a package that not effect or defect the original Ubuntu kernels  in any case.
<apw> NikTh, anything you install which places a bootable kernel in a place where grub will use it, will trigger that kernel to either be so new it is always new, or so old it is never the default boot.
<apw> NikTh, if you want people to have to select it each time in grub then you could make the ABI number much lower than all of ours, so they would get our updates; but that would mean they have to take action at the grub menu to get your kernel
<NikTh> apw:  Is this allowed ? I mean to upload a version older than the current  ? 
<apw> nope, a ppa will reject that
<apw> bah, what you want to do is hard
<Adri2000> hi
<Adri2000> the -22 kernel in raring has a regression over -21. it's not that critical (brightness control), but thought it might be useful to let you know
<Adri2000> this is bug #1163720
<ubot2> Launchpad bug 1163720 in Linux "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Incomplete] https://launchpad.net/bugs/1163720
<maxb> Adri2000: The bug title disagrees with what you said (about versions)
<apw> Adri2000, yeah what maxb said; if that bug is not your bug I would file a new one for your machine and add a comment mentioning the other one
<apw> kamal, was the XPS13 the one your kernel was for ?
<Adri2000> maxb, apw: see the last two comments of the bug report. it's the right bug, that was fixed at some point, and reappeared with the -22 kernel
<maxb> If you're *strongly convinced* it's the same bug exactly, update the bug title - otherwise, consider whether it would be appropriate to open another bug report (mentioning the previous one, of course, but tracking the new occurrence)
<maxb> Oh, actually, having just read the comment just before those two, *definitely* open a new bug
<apw> Adri2000, it is good to get the exact h/w you have etc, in case there is a subtlty etc.
<Adri2000> looking at the kernel changelog I see the the fix has been explicitely reverted: "SAUCE: (no-up) drm/i915: revert PCH_PWM_ENABLE quirk for XPS13-FHD", mentioning another bug report
<apw> jsalisbury, ^^
<Adri2000> yeah, I'll try to investigate a bit, but any more information would be welcome as well :)
<apw> Adri2000, ahh ... then yes that is expected, and in that case it probabally should have been reopened when we reverted the patch
<jsalisbury> apw, ack
<apw> henrix, ^^
<apw> jsalisbury, ta
<jsalisbury> Adri2000, I'll take a look at the bug report
<henrix> apw: looking
<apw> henrix, it seems we reverted the fix explicitly but it is implied here the bug remained closed
<henrix> apw: yep, looks like we need to either re-open or create a new bug.
<henrix> apw: maybe its better to wait for kamal to be around, both bugs have been handled by him. lets see what are his thoughts on this
<henrix> looks like the patch to fix the bug breaks something else
<apw> henrix, yeah, when we revert we need to remember to move things back from Fix Released so they do not get lost ... shame LP has no syntax for it
<henrix> apw: yep, that would help. i'll move it back to Confirmed and ping kamal on this
<apw> henrix, great, that seems safest
<rsalveti> rtg: were you able to test the grouper kernel?
<rsalveti> that's the only one pending still
<rtg> I have not yet. too many other distractions.
<rtg> I can get to it today
<kamal> Adri2000, apw, jsalisbury, henrix: fyi, that "revert" commit did not actually revert the brightness fix for bug #1163720 ...  the original fix commit applied the quirk to both the original XPS13 and the newer XPS13-FHD, but ...
<ubot2> Launchpad bug 1163720 in linux (Ubuntu Raring) "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Confirmed] https://launchpad.net/bugs/1163720
<kamal> we then determined that it actaully broke brightness control on the XPS13-FHD (brightness control seemed to work on the -FHD without any additional fix needed), so ...
<kamal> the commit "SAUCE: (no-up) drm/i915: revert PCH_PWM_ENABLE quirk for XPS13-FHD" actually just removed the application of the quirk for the XPS13-FHD.
<kamal> at that point (3.8.0-21), all of the XPS13{,-FHD} users seemed satisfied.   so . . . .
<henrix> kamal: ok, so do you think its worth building a test kernel reverting that revert?
<kamal> if its broken again in 3.8.0-22 (arrrghghgh!) then we'll need an all new bug report -- not a reopen of 1163720
<kamal> ... and the information:  is this on an XPS13, or an XPS13-FHD ?
<kamal> henrix, first thing:   I'll test 3.8.0-22 on my (non-FHD) original model XPS13 as a sanity check
<henrix> kamal: ok, cool. just a detail: i moved back the bug to 'confirmed'. you already said that's probably not the right thing to do, so...
<kamal> henrix, I'll fix it
<kamal> :-)
<henrix> kamal: ok, cool. but maybe we want a new bug # first to add the comment before changing?
<kamal> henrix, let me test -22 (will do momentarily) then we'll sort it out
<henrix> ack
<kamal> henrix, Adri2000: on my (non-FHD) original model XPS13, the brightness control still works fine for me with 3.8.0-22.33, so ...
<kamal> Adri2000, is yours the new XPS13-FHD model, perchance?   I'm now not sure if the issue here is that the quirk *does* need to applied to some -FHD's but not others, or if something else in the i915 driver changed out from under me again . . .
<rtg> ogasawara, remind me again, when does Raring LTS kernel go EOL ? when 14.04 LTS is published ? (which is longer then the 9 month support window for raring). I get so confused.
<kamal> Adri2000, fyi, bug #1169376 is the one where we determined that applying the quirk broke the XPS13-FHD, hence the "revert" commit to remove the -FHD from the quirk list.
<ubot2> Launchpad bug 1169376 in linux (Ubuntu) "XPS13 backlight stopped working after update 3.8.0-18.28" [Undecided,Confirmed] https://launchpad.net/bugs/1169376
<ogasawara> rtg: 14.04.1 time frame
<ogasawara> rtg: we wanted some baking time of the official 14.04 HWE kernel in Precise before we EOL'd the previous stacks
<ogasawara> rtg: and indeed it'll be longer than the natural Raring support window of 9mo
<rtg> ogasawara, we have a wiki page on this right ? I should start embedding that URL into the descriptions of the meta packages.
<ogasawara> rtg: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<bjf[afk]> rtg, ogasawara if 14.04 follows a similar schedule to 12.04 then 14.04.1 would come out around the 3rd week in Aug. of 2014
<rtg> which gives raring 14 months of support
<bjf> rtg, the raring kernel anyways, yes
<rtg> right
<Kalidarn> i can confirm 3.8.0-22 panics 100% of the time 3.8.0-21 works fine though
<bjf> Kalidarn, do you have a bug # ?
<Kalidarn> pretty sure it is bug 1182038
<ubot2> Launchpad bug 1182038 in linux (Ubuntu) "kernel panic fatal exception in interrupt" [High,Confirmed] https://launchpad.net/bugs/1182038
<Kalidarn> i see that: VFS: Cannot open root device "UUID=<uuid>" or unknown-block(0.0: error -6
<Kalidarn> it must be a nasty regression because i booted -22 3 times failed on all 3 times, then i booted -21 and it worked.
<bjf> Kalidarn, can you start tracking that bug and contribute to the testing?
<Kalidarn> sure
<Kalidarn> hmm not sure if it is the same thing
<Kalidarn> it seems to load module verification cerificates right.
<bjf> Kalidarn, go ahead and open a new bug and we can worry about it being a dupe later
<Kalidarn> "please append a correct "root=" boot option; here to the available partitions:
<Kalidarn> i haven't edited my grub configs.
<bjf> Kalidarn, did you open a new bug?
<Kalidarn> bjf: bug 1183912 i filed is probably a duplicate but i don't really knwo
<ubot2> Launchpad bug 1183912 in linux (Ubuntu) "Kernel 3.8.0-22 fails to boot." [Undecided,New] https://launchpad.net/bugs/1183912
<Kalidarn> *know much more
<Kalidarn> if anyone has any specific things they want me to test just ping my name, i really must be going to bed :)
<Kalidarn> no doubt im not the only one effected
<Kalidarn> though i suppose it could be a specific hardware configuration
<bjf> Kalidarn, i'll add a test request to the bug
 * rtg -> lunch
<bjf> bjf -> lunch
 * rtg -> EOW
<bjf> i'm back
<infinity> plars: Did we come to any conclusions about ti-omap4?
<plars> infinity: sbeattie was looking at it, said he has a patch for the test
<plars> infinity: but it did *not* fail on the older kernel
<plars> ...
<plars> <plars> sbeattie: and I did see it on two separate runs with the sru kernel
<plars> <plars> sbeattie: now, 3 runs not sufficient to say it's not still a random occurrence, but I found it a bit odd
<plars> <plars> works fine on 3.2.0-1430-omap4 #39 the problem happened on 3.2.0-1432-omap4 #41
<plars> infinity: ^
<infinity> plars: Could still be a fluke.  Or could be that the new kernel changed something entirely unrelated just enough to tickle a weird race in the test?
<Adri2000> kamal: I don't know how can I reliably check what version of the XPS 13 I have (is it somewhere in the output of lshw or dmidecode?); but I know it has a full hd screen (aka I'm using 1920x1080 resolution)
<plars> infinity: I think both sbeattie and I are at a loss, I've not been able to reproduce this timout when running the test in isolation
<plars> infinity: but unless sbeattie disagrees, I think the risk is low because a) we know the test *can* pass because it works when I run it standalone, and b) it's not an explicit failure, just a timeout
<infinity> plars: Yeah, I'm not fussed about it, especially if it's not breaking in isolation.  It may well just be a fluke that you tripped it twice.
<plars> yes, known possibility
<plars> I'll comment on the bug, but call it passed
<infinity> plars: Odds are that you could trip it in isolation if you ran it a few thousand times (for i in `seq 1 3000`; do test.py; done), but meh.
<plars> infinity: I suspect it may have something to do with previous tests getting the system slowed just enough
<infinity> Could be coming out of swap death from the previous test(s), yes.
<infinity> Restoring your entire system's RAM over a USB link isn't quick.
<plars> indeed
<sbeattie> plars, infinity: no objection from me.
<infinity> sbeattie: Good deal, cause I already released it based on jjohansen's say-so. ;)
<sbeattie> hehe
<sbeattie> phew, I was worried for 30 seconds that my opinion might actually be important.
<infinity> And the ABI checker is too quick.  It caught the LP OOPS that made the kernel/meta updates span a publisher cycle. :/
<infinity> Oh well, should be all fixed now.
#ubuntu-kernel 2013-05-25
<NikTh> I want to thank all of you guys your time and effort to solve a newbie's problems (mine). Fortunately I achieved my goal to upload a custom-kernel in a PPA of mine and it is a separate version (it not replace the official Ubuntu kernel). 
<NikTh> https://launchpad.net/~nick-athens30/+archive/precise-optimized if you want to test. For the record, the secret here is the ABI . If you completely change this, then apt will recognize this kernel as a separate package. linux-image-3.2.0-440-generic :) 
<ohsix> that's becasue it is, the ABI number is there for a reason :p
#ubuntu-kernel 2013-05-26
<jackbrown> Could anyone help me about this bug ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1006145
<ubot2> Ubuntu bug 1006145 in linux (Ubuntu) "Logitech Mouse not recognised on boot in 12.04 & later" [Medium,Confirmed]
#ubuntu-kernel 2014-05-19
 * apw yawns
<RAOF> Time for the bees!
 * RAOF will be able to deliver them in person next week.
<apw> oh bees yes please
<kees> rtg: heads up on a kernel SRU patch: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=754733ee8a82832b6dbd784facbe12dedd303f5e
<kees> I'll have mdempsky open a bug and send the patch to the kernel-team list.
<systest> how can I track which changes are incorporated in to the latest packages?  specifically, I'm trying to determine if/when an upstream patch gets applied to fix https://lkml.org/lkml/2014/4/1/14
<bjf> systest, the "easiest" way is to look at our git repo
<bjf> systest, that commit is in the trusty release version
<systest> thanks, I'll clone a copy of the repo  just to take a look.  re being in the release version, thanks for looking that up
<bjf> np
<bjf> systest, in our trusty repo it's : f974c74cfa24b0872009d1cbab78f743c2535570
<systest> ty
<infinity> install: cannot stat './tmp/generic_netboot/tree/lib/firmware/3.15.0-1-generic/device-tree/apm-mustang.dtb': No such file or directory
<infinity> rtg: ^-- Did that move, or get dropped, or...?
<rtg> infinity, its still there as far as I can tell. debian.master/rules.d/arm64.mk: dtb_files_generic += apm-mustang.dtb
<infinity> The binary packages disagree with you.
<rtg> hmm, checking.
<infinity> Or, rather, my d-i build disagrees.  Let me have a look at the binary packages.
<rtg> firmware/3.15.0-1-generic/device-tree/apm-mustang.dtb
<rtg> its in the linux-image package
<rtg> infinity, the mustang firmware was never in a udeb. I wonder how dannf actually installs this beast.
<infinity> rtg: It's not in the udeb anymore, and it used to be.
<infinity> rtg: From trusty: http://paste.ubuntu.com/7490386/
<infinity> Though, a bit sketchy that the udeb doesn't contain *all* the same DTs that the linux-image deb contains.
<infinity> Must have been some APM-specific hack there.
<infinity> rtg: Note that on armhf, the kernel-image udeb appears to have all the DTs.
<infinity> rtg: So, this is an arm64-specific oops.
<rtg> infinity, dang, you're right. dunno what happened in the transition to utopic. I'll figure it out.
<infinity> rtg: Ta.  Whatever armhf does, that seems to be "the right thing to do" for arm64 too.
<apw> rtg, well at least after the last upload its not a 'debian/*' issue as they diffed null
<rtg> this line disappeared: debian.master/d-i/firmware/kernel-image:device-tree/apm-mustang.dtb ?
<infinity> rtg: So, I'd argue the list should probably be expanded, but that's enough to make d-i happy, I think.
<infinity> rtg: Since that's all that was shipped in trusty.
<infinity> -rw-r--r-- root/root      4669 2014-05-18 19:33 ./lib/firmware/3.15.0-1-generic/device-tree/foundation-v8.dtb
<infinity> -rw-r--r-- root/root      7782 2014-05-18 19:33 ./lib/firmware/3.15.0-1-generic/device-tree/rtsm_ve-aemv8a.dtb
<infinity> -rw-r--r-- root/root      6985 2014-05-18 19:33 ./lib/firmware/3.15.0-1-generic/device-tree/apm-mustang.dtb
<infinity> rtg: Those are the three that are in linux-image.deb, probably makes sense to mirror that to kernel-image.udeb.
<infinity> rtg: And maybe to automate keeping them in sync too (I just noticed it's a manual list for armhf too, which seems crazy)
<rtg> infinity, yup
<infinity> rtg: But a quick turnaround of just the manual fix would do me for now if you'd like to see d-i build and your kernel migrate. :)
<rtg> infinity, gimme a bit
<hallyn> hm, migration/[0-3] are taking up a combined 90% cpu time
<hallyn> though it's probably my punishment for cp'ing a large file on btrfs
<infinity> rtg: Let me know when you're uploading, so I can give you sagari for ppc.
<rtg> infinity, fire in the hole
<infinity> rtg: Ta.  I'm doing a test build of d-i PPC to see if I have more things to yell about, but I think my failure there was just the removal of e500.  I hope. :P
<infinity> And look at that, you got sagari without my help.
<rtg> luck of the draw
<infinity> rtg: Nice commit message. :P
<rtg> infinity, keep it sime, don't confuse people
<rtg> simple*
<infinity> rtg: You could have just shortened that to "WTF?"
<rtg> infinity, I think what happened is that APM got added during the trusty dev cycle after the utopic repo was opened and I forgot to forward port all of the mustang build bits.
<infinity> Curse rebases and the lack of useful history. :/
<infinity> 'git log debian.master/d-i/firmware/kernel-image' is the most useless thing ever.
<infinity> Anyhow, I guess that will be building all evening on armhf, so I'll get you a d-i upload late tonight.
<rtg> infinity, thanks
<infinity> rtg: Had to fix three other arches anyway. :P
<infinity> rtg: I had 4 failing failing arches for 3 different reasons, I suspect this is a new record for me.
<rtg> infinity, kind of sucks to be you
<infinity> Sure does.
 * rtg goes back to reefing on a power supply....
<infinity> You shouldn't smoke those.
#ubuntu-kernel 2014-05-20
<AndChat467409> Hey, I am getting the "Alert! /dev/disk/by-uuid/######### does not exist. Dropping to shell!" After trying to install windows on a empty part of my drive. Now nothing will boot, not even live CDs. Anybody know what's up? I'm beginning to think if bricked my computer.
<lamont> has anyone seen a situation where traffic passing through a linux firewall (precise in this case) fails for win8 clients talking to a variety of far-side destinations, while it works (1) through a cable modem, and (2) if handed to a squid on the lan which then goes through the very firewall.  traffic looks sane on the firewall, haven't caught traffic yet in the working case
<lamont> firewall nats, of course
<infinity> lamont: I saw that on my friend's network for a while, but every attempt at diagnosis never allowed us to make any sense of it.
<infinity> lamont: And upgrading to trusty made it go away, so we gave up caring.
 * apw yawns theatrically
 * ogra_ throws a single bee
<niluje> hi
<niluje> how can I debug this kernel panic? http://blackhole.brmzkw.info/2014-05-20/panic.txt
<niluje> # uname -a
<niluje> Linux vtydc2-p10cp-c01b16n12 3.14.4 #1 SMP Tue May 13 16:27:33 CEST 2014 armv7l armv7l armv7l GNU/Linux
<niluje> # mount
<niluje> /dev/nbd0 on / type ext4 (rw)
<niluje> # ps auxw | grep nbd-client
<niluje> root      1041  0.3  0.0   1312    72 ?        Ss   00:00   0:00 /sbin/nbd-client 172.16.1.22 4448 /dev/nbd0 -persist
<niluje> I get this kernel panic when running : mkdir /root/toto && chmod 777 /root/toto && strace bonnie++ -d /root/toto -r 2048 -u nobody
<apw> 3.14.4 ... does it occur with the 3.15 series ?
<xnox> niluje: do you have a picture?
 * xnox has kernel panics on ext4 with 3.15 package
<apw> xnox, yeah i had a look at your picture, you mentioned the fs is dirty ?  is that just i hard powered off, or is it in serious trouble
<apw> xnox, niluje's is http://blackhole.brmzkw.info/2014-05-20/panic.txt (3.14.4)
<niluje> apw: didn't try with 3.15
<xnox> apw: it's as dirty as it gets under systemd. As far as i can tell, because we are missing whole bunch of init-scripts (removed as not needed under upstart) systemd just hold the fs open and kills the power.
<apw> xnox, quality error handling for the win
<xnox> thus on next boot, either systemd/mountall do the "reboot required" thing and auto-reboot
<xnox> then you get fsck
<xnox> and then can finally boot again.
<xnox> .... or not boot with 3.15.
<apw> you are asking to not have a root doing that, i hope you don't have data on there you care about
<niluje> (my real question is "how can I debug this?" and not "what is the problem?" :-))
<xnox> i have little clue about niluje jibberish in the log.
<xnox> but last line indicates that a reboot is required....
<apw> niluje, well firstly i would read the source for n_tty_receive_buf_common to see what it might be memcpying, and then i'd be asking (as indeed i did) what versions do not have this issue
<xnox> niluje: is this on powerpc? or an ARM board?
<apw> niluje, to see what might have changed there to trigger this
<niluje> xnox: an ARM board
<niluje> apw: ok, I'm gonna try to setup a kernel 3.14 with the minimal set of options then I'll try to see if 3.15 fixes the problem or not
<niluje> thanks
<apw> niluje, i had a quick look at changes to n_tty since 3.14.4 but cannot see anything interesting, there is the output panic CVE thing but nothing input related
<apw> niluje, unless in some what that could be the other side perhaps of the transaction which corrupted the tty
<niluje> apw: I'm currently trying with a 3.2.34
<apw> henrix, do i assume that netfilter bpf fix for the "lastest two cves" are coming down the stable route ?
<henrix> apw: yep, that's correct
<apw> henrix, great, then i can ignore them :)
<zequence> infinity: So, only precise and quantal needed to be updated this time?
<zequence> infinity: Reason why I'm asking is that the saucy bug report was handled differently from the rest, making the new unversioned one a duplicate of the original one
<zequence> Never mind, I updated saucy. Seems it was like the rest
<zequence> Well, a new ABI for saucy, in fact. Anyway, all uploaded now.
<infinity> zequence: A new ABI for saucy?   That seems unlikely.
<mlankhorst> infinity: can you review xorg-lts-trusty in precise?
<infinity> zequence: Err, oh.  You rebased against the wrong one, that's why. :/
<infinity> zequence: 22.38 is the one we're trying to catch up with.  But if you want to skip it and go straight to 23.39, that works too.
<zequence> infinity: I don't rebase manually, so I don't get to control that :)
<infinity> Oh.  I assume you picked a tag to rebase against or something.
<apw> by default it updates against the latest master tag
<apw> though you can "fix" that manually
<infinity> Kay, well, nevermind then.  Easy enough to just let lowlatency skip the mess that this last cycle was and skip ahead to next cycle. :P
<zequence> Cool. Less brainwork for me.
<infinity> mlankhorst: I can after I've napped a bit.  I'm on the wrong end of night right now.
<mlankhorst> ok
<GortiZ> I've question about bug #1318531
<GortiZ> It has been marked "triaged" without any comment and tagged as "cherry-pick reverse-bisect-done".
<GortiZ> Does it means that the fix will be backported on the current LTS kernel (3.13) so that in future I'll only need to update to the latest KUbuntu 14.04 to make it work on my pc?
<apw> oi ubottu
<apw> GortiZ, no idea if penalvch is going to continue the hunt, but the next logical step is reverting that commit against tip and testing there
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<lamont> infinity: that is good to hear.  I have a trusty upgrade in my week.
<GortiZ> apw: that commit doesn't need to be reverted but to be integrated (the newer works the older doesn't) anyway thanks for the answer. I'll wait and if nothing new happens I'll ask to penalvch :) (I was just wondering which of the two things falls in the "Triaged" definition)
<apw> Triaged just means there is enough info for someone to progress it
<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 3rd, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
#ubuntu-kernel 2014-05-21
<gioele> I got an oops while using a mainline kernel. Is there a tool in Ubuntu to report oops to kerneloops.org?
<smb> gioele, There is the kerneloops package. Though the setup by default reports through apport. But iirc you can run it manually and modify the options then. 
<smb> apw, rtg Hm, am I looking the wrong place or could it be that the generic inclusion list in utopic lost some elements? Just saw someone complaining about virtio_scsi and it indeed appears to be missing (compared to trusty)
<apw> they do sound like things we did very recently, so ... i could believe they have not been syncd
<rtg> smb, maybe it never acquired then.
<rtg> them*
<rtg> I've been known to forget to forward port. we haven't done a resync in awhile.
<smb> Yeah there is a certain diff...
<apw> i did only debian when i did the emergency one at the weekend
<smb> Guess I should send a diff then... :)
<rbasak> ppisati: your post sounds reasonable, but could you also post it to cross-distro please?
<ppisati> rbasak: yep, i'll do
<ppisati> rbasak: i was waiting for some other answer just to hear what the general consensus was
<rbasak> ppisati: thanks. I think we'll probably want to get consensus on cross-distro. I think it's fine to not yet have consensus but still have a discussion there.
<apw> start_line_y = weechat.infolist_integer(infolist, "start_line_y")
<wilhelm1> apw: Does building a 64bit kernel on 32bit software require cross compiling?
<apw> wilhelm1, "kinda" the tool chain generally can build both 32 and 64 bit in the case of x86
<apw> wilhelm1, i would normally not cross build, but build in a 32bit chroot on a 64bit box
<apw> oh .. you said the other way round, interesting ...
<apw> i think in theory the compiler has -m64 avaialble, though if the package knows how to trigger that
<wilhelm1> apw: Are the 64bit linux softwares cross compiled or built from 64bit toolchains?
<apw> wilhelm1, we build them all "nativly" in a chroot of teh appropriate type, in some cases we can share the builders, for example a 64bit x86 builder can build either 32 or 64 bit chroots
<wilhelm1> So apw is it built on a 64bit machine on software that was written and compiled for it?
<apw> we nativly compile the kerenls yes
<apw> people do cross them, but not for the archive
<wilhelm1> Where do we get the code from is it always forked from debian?
<apw> for the kernel we work mostly directly against mainline, as we are generally versions ahead of debian
<wilhelm1> apw: That is kernel.org or vger?
<apw> linus' releases
<wilhelm1> apw: Where are linus' releases found?
<apw> we get them from his git tree, but they are also released as tarballs on kernel.org
<wilhelm1> Share with me the link to his git tree.
<apw> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
<wilhelm1> Do we use any security measures to verify the authenticity of what is taken from git?
<apw> wilhelm1, yes, we use only signed (and verified) tags as base
<wilhelm1> apw is we defined as canonical?
<apw> we is defined as those of us in the kernel-team who pull in new upstream versions, be it mainline or stable
<wilhelm1> apw: How many times has the signing key changed since the last in person meeting with linus?
<apw> wilhelm1, i only know of it changing once
<wilhelm1> once too many?
<apw> we have strong web of trust connections to both of the keys he has used
<wilhelm1> apw: What is linus' email?
<apw> he has various emails, but he is using Linus Torvalds <torvalds@linux-foundation.org
<wilhelm1> signing off now
<wilhelm1> The bots could deliver fresh baked bread daily.
<wilhelm1> Is there a goal?
<wilhelm1> fresh baked bread daily
#ubuntu-kernel 2014-05-22
<xnox> apw: i think, that maybe my 3.15 woes are related to me using an Ideapad, since in 3.14 yoga-specific device support landed.
<rtg> apw: woot. 3.15-rc6 builds, lets upload it.
<psivaa> hello, we see some issues in the smoke testing of today's images with the new 3.15 kernel (i think 3.15.0-1-generic):
<psivaa> server installations reboot into grub rescue mode with
<psivaa> error: file /grub/i386-pc/normal.mod not found 
<psivaa> install log says:
<psivaa> hw-detect: modprobe: ERROR: could not open builtin file '/lib/modules/3.15.0-1-generic/modules.builtin.bin'
<psivaa> cjwatson: assume that's not an installer issue but fyi too
<psivaa> http://paste.ubuntu.com/7501602/ is the full install log
<cjwatson> I don't think that hw-detect message is relevant
<cjwatson> It's present in successful runs too
<cjwatson> grub-pc/install_devices seems to be getting set to empty
<cjwatson> Doesn't appear to be preseeded, which seems odd?
<psivaa> cjwatson: we haven't changed the preseeds recently
<rtg> sforshee, please have a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322067 - it should be right up your alley these days.
<rtg> hmm, maybe he's gone today.
<sforshee> rtg: I'm here for a couple more hours today
<rtg> sforshee, no problem. 
<rtg> this'll give you something to bisect on the endless flight to Malta
<sforshee> until my battery dies, which won't take long if I'm doing builds
<rtg> sforshee, some of those flights have power. Airbus frames generally do.
<xnox> with a socket connection one doesn't have adaptor for..... =)
<apw> mostly us power sockets these days, 2 between three
<apw> which is a bit odd, and why i carry an splitter :)
<bullgard4> Is the article http://lwn.net/Articles/326552/ serous or an April 1st's fool attempt?
<bullgard4> +i
<apw> sounds real i recon, but that is anchient history as well ... the patches referred are merged
<apw> bullgard4, ^
<hallyn> hm, as of today it seems i can't, as unprivileged user, do 'btrfs subvolume delete myvol' even if i created and own myvol
<hallyn> previously that worked
<hallyn> oh,
<hallyn> nm, i know what happened
<hallyn> i had forgotten to update my /etc/fstab to allow it.  d'oh
#ubuntu-kernel 2014-05-23
<ben-8409> hi there! i filled a bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1321421) because sound on my new mb with intel h97 chipset was unusable. i turns out there where just some device ids missing and a patch is lined up for linux 3.15 as of today https://kernel.googlesource.com/pub/scm/linux/kernel/git/tiwai/sound/+/77f07800cb456bed6e5c345e6e4e83e8eda62437%5E!/#F0. As this is a 3 line change, any chance that could be backporte
<ben-8409> d for 14.04? 
<apw> ben-8409, that doesn't look impossible indeed
<ben-8409> apw: would be great. i am currently compiling the ubuntu kernel myself to verify. anything else i could do?
<apw> ben-8409, i see it hasn't made it as far linus' tree yet, it is always nice for it to make it there before we'd pull it in; limits the chance it will change again
<ben-8409> apw: sure, makes sense.
<apw> but i cannot see it changing, it is pretty small, and likely to be in 3.15-rc7 or 3.16-rc1
<apw> so if you could confirm in the bug you have tested with that patch applied to the ubuntu latest
<apw> whihc you can build, or i can if you cant
<apw> and then poke us again when the commit hits linus' tree, then we cna sru it i'd say
<ben-8409> i am trying currently (something is building) but i noticed there are different ways to build the ubuntu kernel refered in the wiki. i simply used apt-source , applied the patch and build with debbuild
<ben-8409> as  described here: https://help.ubuntu.com/community/Kernel/Compile
<ben-8409> apw: should i do anything in the bug report? LP:1321421
<ben-8409> and stupid question: how do i know the commit hits linux tree?
<apw> ben-8409, yeah that will work i am sure
<apw> ben-8409, just record your testing in the bug, so someone else reading it can tell you did that
<apw> and doens't ask you to do it agian
<apw> you can tell if it is in linus tree via the gitweb interface for kernel.org, or via cloneing
<apw> ben-8409, or, come back and poke us in about a week when linus' releases the next -rc and ask me :)
<ben-8409> ok, thanks a lot!
<ben-8409> my build is done, i will reboot and see what happened 
<ben-8409> apw: thanks again and bye
<greearb> anyone know if standard upstream 3.14 kernel will work as a live-cd boot kernel?
<greearb> ie, I want to build a live-cd based on Ubuntu with customized kernel, but would rather use standard upstream kernel as base instead of ubuntu kernel.
<apw> greearb, i believe that a live image needs an overlay filesystem to work, and there is not one upstream
<greearb> ahh, I was afraid of that
#ubuntu-kernel 2014-05-24
<shipy> how many socil workers does ubuntu have?
<shipy> 138
<shipy> do you know how to count?
<shipy> Satan enticed david to count israel
<shipy> did what was evil in the sight of the LORD
<shipy> HOW MANY FUCKING SOCIAL WORKERS?
<shipy> you want to play counting games
<shipy> come on omar
<shipy> dont play fucking games with me
<shipy> they are 'social workers' for the final social order
<shipy> you fucking peices of shit
<shipy> like those jackasses in #mises 
<shipy> fraud
<shipy> theft
<shipy> drugs
<shipy> wirefraud
<shipy> are there still 80,000 users on freenode?
<shipy> are you hearing voices?
<shipy> do you shoot a crystal diode dart into them?
<shipy> how many points do you have?
<shipy> you all gamers?
<shipy> the source code is bullshit never matches what is distributed
<shipy> fucking bullshit
<shipy> jono 
<shipy> jono: why was there an extermination order against mormons?
<shipy> Could it be that they did not obey the authority of Jesus Christ?
<jono> shipy, ?
<shipy> Ask Hannah Volmar if she has unpaid vow.
<shipy> property
<apw> shipy, this channel is for discussions on the ubuntu kernel not religion
<shipy> from where texas?
<shipy> Which ubuntu kernel
<shipy> How many mormons in texas?
<shipy> Start fucking counting then.
<apw> shipy, your language is not appropriate for this channel
<shipy> How many police.
<shipy> How many 'psychiatrist'
<shipy> count it up
<shipy> computers everywhere
<apw> shipy, don't make me eject you
<shipy> apw talk to me
<jono> shipy, please leave
<jono> shipy, this is a channel for discussing Ubuntu and the kernel, this is off topic and inappropriate
<shipy> jono: What is to discuss about the ubuntu kernel?
<shipy> I asked about the keys already
<shipy> flawed policy
<jono> shipy, many things to discuss, but my point is that we expect respectful and on topic discussion here
<shipy> jono: lead by example
<shipy> we expect more than we give is that it?
<shipy> jono: get started then
<jono> shipy, I have nothing to discuss
<jono> my point is, be respectful and collaborative
<shipy> then why are you on the channel?
<apw> he is a lurker, someone to listens and absorbs the discussion not necessarily involved in it
<shipy> like computer activate audience
<shipy> the kernel needs to be secure
<shipy> I need to interact with the sourcecode.
<shipy> ANd then rebuild it.
<shipy> I can 'throw the dice' for security.
<shipy> Just with a thought.
<shipy> See programs dont have thought.
<shipy> That is where it all comes from.
<shipy> ALl of the rand comes from thought.
<shipy> The ancients sand to the LORD to ask for the work of their hands to remain saying 'we' are like dust in the wind or a vapour.
<shipy> And youns just want to let everything get robbed from you?
<shipy> Before even passing watch the work disappear in front of your eyes.
<shipy> Then whats left?
<shipy> ALl of you computer programmers working for nothing when it gets changed.
<shipy> The layers underneath.
<shipy> co-operate
<shipy> Cannot even somethin g sustainable be done.
<shipy> Why do not youns JOYINME
<shipy> Linux wants to be a secure multiuser operating system.
<shipy> I can make it so.
#ubuntu-kernel 2014-05-25
<bullgard4> I wonder what Linux kernel file defines the kernel process bdi-default? I am using Linux kernel version 3.2.
<[[asimov]]> Are the kernels built from new software or built from previous systems?
<[[asimov]]> So is the compiler built fresh or is it built on the last releases system?
<[[asimov]]> apw
<[[asimov]]> apw: 
<[[asimov]]> The bugs can carry over if it is built on the same system that has the bugs.
<[[asimov]]> apw: 10:02:10 PM - [[asimov]]: Are the kernels built from new software or built from previous systems? So is the compiler built fresh or is it built on the last releases system? The bugs can carry over if it is built on the same system that has the bugs.
<[[asimov]]> no response?
#ubuntu-kernel 2015-05-18
<pkern> Hi. What's the timeline for 3.16.0-38.52~14.04.1 to be pushed to trusty proper?
<henrix> pkern: that kernel is currently under testing/verification. if everything goes according to the plan, it should be out of -proposed by the end of this week
<henrix> (we're currently on the 3rd week of the 3 weeks SRU cycle)
<infinity> It actually just needs a security sign-off, and it could go out today.
<infinity> jjohansen: Any chance you'll get around to kernel security signoffs today?
<dileks_webchat> hi
<dileks_webchat> I have a hdd in a notebook and want to deactivate hdd-scan when using a recent ubuntu live-system. do you happen to know if there is a boot-option for that?
<dileks_webchat> I checked <http://wiki.ubuntuusers.de/Bootoptionen?redirect=no> (German)
<dileks_webchat> cannot see a suitable boot-option
<apw> dileks_webchat, i don't think i know what you are referring to when you say hdd-scan
<apw> exactly what are you trying to prevent occuring ?
<dileks_webchat> the hdd is defect and should not be considered for installation or whatever. handled as non-existent
<dileks_webchat> hdd is full of s.m.ar.t errors
<dileks_webchat> hardware-detection on boot-up results in a restart of the live-system. hdd cant be deactivated in bios.
<apw> dileks_webchat, ok makes sense, i am supprised it would trigger a restart, i would expect it to just take longer to boot
<apw> dileks_webchat, as i have used live images often to get what is still readable off broken laptop drives in the past
<apw> dileks_webchat, it is possible something like libata.force=disable might do what you want
<apw> you might need to limit it to the device whihc is in error if that also gets rid of your usb stick
<dileks_webchat> how do I limit to the device - which parameter do I pass?
<apw> dileks_webchat, never done it, it just says [ID:] in front of the disable;
<apw>         libata.force=   [LIBATA] Force configurations.  The format is comma
<apw>                         separated list of "[ID:]VAL" where ID is
<apw>                         PORT[.DEVICE].  PORT and DEVICE are decimal numbers
<apw>                         matching port, link or device.  Basically, it matches
<apw>                         the ATA ID string printed on console by libata.  If
<dileks_webchat> hehe, I was looking at that :-)
<dileks_webchat> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-parameters.txt#n1745
<dileks_webchat> apw: thanks for the quick answer!
<dileks_webchat> bye
<mickkelodeon> hi
<mickkelodeon> I don't know if this is the best place for asking about low-latency/real-time kernels with ubuntu and ec2 instances...
<apw> mickkelodeon, without knowing the question that is hard to say
<mickkelodeon> I have more than 100 processes working in real time, and the latency is killing me 
<mickkelodeon> I want to change the kernel for another with better performance for this purpose
<mickkelodeon> I was taking a look to the lowlatency kernel, but when I installed it I got "Ignoring non-Xen Kernel on Xen domU host: vmlinuz-3.2.0-82-lowlatency"
<smb> iirc that is keyed on some CONFIG_XEN ... could be the default options for lowlatency differ there
<mickkelodeon> because the realtime kernels seem outdated
<apw> smb, i would be supprised if we changed xen in lowlatency
<apw> smb, unless it is somehow contra-indicated of course for the other options
<smb> The realtime patchset was a big effort to maintain and nobody cared to fund it. I believe I remember vaguely that there was some recent decision to bring it upstream
<smb> apw, Yeah, I am not sure where lowlatency came back then
<apw> smb, yeah thats my memory that RT is going to die either by merging or dissappearnig
<smb> then it also could be the way the special update-gub checks. That also has changed over time from checking kernel names to kernel options... 
<smb> If I could remember all those dates... :/
<smb> Hrm, the responsible package also changed name and place. Used to be grub-lecacy-ec2 (part of cloud-init source) and now might be pv-grub-menu since Trusty
<mickkelodeon> so, smb apw what is the best way in my case?
<pkern> henrix: Thanks!
<smb> mickkelodeon, I am looking at update-grub-legacy-ec2 which comes via grub-legacy-ec2 in Precise. If I cannot find a nicer way, maybe fiddling with is_xen_kernel could work for you... though probably a bit of a pita if it needs doing for multiple installs/instances
<smb> Its bascially a bash script and as I suspected it keys on the -virtual part of the kernel filename back then
<apw> smb, ug
<mickkelodeon> smb , but do you think this could be a substantial change in terms of performance for my case?
<smb> Hm, maybe one could even define the shell function seperately as it checks for it to exist
<apw> audio peoiple claim it helps latency significantly for their use case, but ymmv
<smb> Yeah... there is a catch maybe for in P -virtual may have had more essential things build in for running under Xen than generic
<apw> smb, ugg
<smb> apw, Yeah... with lucid gone now we went from quite different to subtly different which is hard to remember
<apw> smb, yeah
<trippeh> I doubt a realtime kernel would make much difference on AWS/ec2
<trippeh> on public clouds you often have to build your system to be tolerant to some extra latency
<smb> with the addition of vcpu scheduling its hard to predict ... i guess
<smb> So it might be that lowlatency improves a little by being preemptive and setting a higher HZ because it lowers a single tasks effect but still a vcpu can stall or cause latency outside the kernels control
<jjohansen> infinity: yes
<cyking> i've been asked to fully commit bisect the kernel. can someone help walk me through the process. thanks.
<cyking> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1453391
<ubot5> Launchpad bug 1453391 in linux (Ubuntu) "Very slow Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)" [Medium,Incomplete]
<cyking> seems that I should focus on one of these comnits http://pastebin.com/WwVjC02W but the instructions are not so clear to me.
<cyking> trying to build kernel but debian.master and debian folders do not exist. what to do ?
#ubuntu-kernel 2015-05-19
<apw> cyking, it is hard to truly bisect against a distro tree because we are carrying so much delta and that delta gets moved forward version to version
<apw> cyking, but if you know that the two versions you mention in your pastebin are the good and bad ones (one or other way round), and its just those 10 commits, then you could just revert them manually
<apw> cyking, and again if i is just those that are the affecting commits, then at least 4 of those sound like tidying up that wouldn't change the code any
<nessita> jsalisbury, hello! so I'm still running kernel 4.1-rc3, and seems like LXC does not work with that (nor does nvidia drivers). Would you need me to test anything else in this kernel (re audio playblack broken) or is it OK to uninstall?
<apw> nessita, he most likely needs to know whether your symptoms are present or absent in that kernel
<nessita> apw, right, already confirmed that, so thanks
<nessita> apw, is it known that LXC does not work with kernel 4.1? shall I file a bug?
<nessita> same question for nvidia drivers
<apw> nessita, it isn't necessarily known, but will be before we upload a real kernel to the archive for that version
<apw> nessita, they are on our acceptance criteria for a new kernel
<nessita> apw, ah, great, thanks
<mnaser> i had a server crash yesterday, i know it's a stretch but the only thing that changed on it was cgroup related stuff
<mnaser> does anyone know of anything on linux-image-3.16.0-33-generic that might have caused anything like that?
<mnaser> it's an openstack compute host, the only difference was a daemon which was changing cfs_{quota,period}_us for VMs from time to time
<mnaser> in the cgroup
<apw> i don't think we specifically know of anything no
<mnaser> ill keep looking then, i have linux crashdump on this node but i had to cut it off (taking a really long time, it was a 256gb node)
<mnaser> 256gb memory that is
<mnaser> i have an incomplete 24gb file which im trying to see if i can fish anything at all otu of it
<jsalisbury> nessita, Yes, you can uninstall 4.1-rc3 now.
<nessita> great, thanks!
<cyking> ls
<cyking> oops ;)
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<cyking> Is there anyone that can assist me with a kernel bisect / bug report?  Please?
<jsalisbury> cyking, sure, is this for an open bug?
<cyking> yes
<cyking> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1453391
<ubot5> Launchpad bug 1453391 in linux (Ubuntu) "Very slow Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)" [Medium,Confirmed]
<cyking> thanks :D
<jsalisbury> cyking, I can build the test kernels for you and post in the bug where they are for download.  
<cyking> that would be great.
<jsalisbury> cyking, I'll post links to the first kernels to test.  We first need to identify the last 'good' kernel and the first 'bad' one
<cyking> Understood
<cyking> I got Ubuntu-3.13  working
<cyking> but the bisect process was confusing for me. 
<jsalisbury> cyking, I don't mind helping at all.  I just posted in the bug the first few kernels to test.
<cyking> jsalisbury, thank you kindly. will test. should i post results on launchpad or on irc ?
<jsalisbury> cyking, in the launchpad bug is best, that way we can keep track of where we are in the bisect.
<cyking> all installed now testing. thanks.
<cyking> jsalisbury, i posted the results. 
<jsalisbury> cyking, great.  I'll review and post the next kernels to test
<jsalisbury> ##
<jsalisbury> ## Ubuntu Kernel Team Meeting - in 15 minutes - #ubuntu-meeting
<jsalisbury> ##
<cyking> jsalisbury, thanks again. good luck with your meeting. the kernels are installed and will test now.
<jsalisbury> ##
<jsalisbury> ## Meeting starting now
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 26th, 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/
<cyking> jsalisbury, i posted the results. 
<jsalisbury> cyking, thanks
<cyking> jsalisbury, i posted the results. thanks again.
#ubuntu-kernel 2015-05-20
<sbeattie> bjf: Hi. I just looked at the apparmor failure log in http://kernel.ubuntu.com/testing/onibi__3.13.0-53.88__2015-05-18_17-33-00/console_output.txt.html ; it looks like it pulled in the apparmor packages in trusty-proposed, which means you shouldn't see the apparmor apport hook failure anymore (yay!), but it it looks like the trusty-proposed deb-src line wasn't enabled in apt's sources.list.
<sbeattie> bjf: that may be the cause of the different failures seen this time, as part of the apparmor qrt test script downloads the source package and runs make check in it.
<bjf> sbeattie, ack, i'll look at it tomorrow. thanks
<sbeattie> bjf: no worries, thanks.
<sbeattie> ah, yep, I've reproduced the the failures with the sources from apparmor 2.8.95~2430-0ubuntu5.1 while binary packages from 2.8.95~2430-0ubuntu5.2 are installed.
<FourDollars> sforshee: Hi, did you remember the patch you made for Dell New XPS 13? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-multitouch.c?id=2c6e0277e1eab3df5db81c59e408b7b1c14b1b72
<FourDollars> sforshee: Does it fix any problem?
<pkern> The new 3.13 contains "tcp: make connect() mem charging friendly" but doesn't seem to contain "tcp: Fix crash in TCP Fast Open", is that intentional?
<pkern> I didn't check if it crashes in the same way as 3.16 did, but it's somewhat concerning that the fixup wasn't picked up if it's needed. |:
<pkern> Yeah, it's dead on arrival for us.
<apw> pkern, new 3.13 stable or new 3.13 in -updates in trusty ?
<pkern> 3.13 in -updates in trusty.
<apw> henrix, ^
<pkern> Of course it relies on things to use fast open. Which probably just Google does? I don't know.
<apw> yes, you are likely the only people in the world advertising that feature sadly
<pkern> And using it in clients, I guess.
 * henrix goes have a look
<apw> that patch shows applied across the board (as it was a cve) but it was behind the other releases in trusty
<apw> but i had assumed that meant the introducing commit was also not released either ... hmmm
<henrix> ugh
<henrix> yeah, that's correct
<henrix> pkern: thanks for spotting that!  i'll go work on fixing that ;)
<infinity> henrix: Hrm.  Should we do a single-commit respin to pick that up?
<pkern> henrix: ta!
<infinity> According to Ben's commit message, it should only affect 3.13 and 3.16.
<infinity> And it was fixed in 3.16 already, so just 3.13.
<apw> yeah somehow we paired it up in 3.16 and not in 3.13
<henrix> infinity: yeah, i believe a quick respin will be needed.  i go finish the V respin and start with fixing T
<infinity> henrix: +1 from me for a single-commit resping of T and lts-T.
<infinity> respin, too.
<infinity> Typing hard.
<infinity> pkern: Since you seem to be a pro at reproduction, can I get you to test henrix's kernel when he does the deed, so we can turn it around ASAP?
<pkern> infinity: Sure.
<genkgo> infinity: last week you helped me out with getting cloud tools for kernel 3.19. we switched to this kernel for our problems with creating vss snapshots on our hyperv machine.
<genkgo> infinity: unfortunately, it did not solve the issue. our vps goes read-only sometimes while creating these vss snapshots. now we have switched to a new kernel, the error is different than before.
<infinity> genkgo: You want apw, not me.
<genkgo> blk_update_request i/o error, dev sa, sector xxx
<infinity> genkgo: I was just helping with the packaging mysteries, not the hyperv madness.
<genkgo> infinity: ok :)
<genkgo> apw: i still have some hyperv madness :)
<apw> genkgo, ok add that info to the bug, and the new dmesg, and remind me of the bug number, and i'll see if we can get someone to reproduce it
<pkern> henrix: Just drop me a mail at $nick@google.com if you have something to test for me. I take it that a respin would likely be released earlier than next Sunday? :)
<henrix> pkern: yeah, for sure before Sunday :)
<henrix> pkern: i hope to have it uploaded and building later today, i'll email you once we have a test kernel
<pkern> henrix: Thank you :)
<genkgo> apw: i did not report a bug before, because we thought it was related to the kernel version. if i run "ubuntu-bug linux" i get "This is not an official Ubuntu package. Please remove any third party package and try again." (*** Problem in linux-image-3.19.0-17-generic)
<infinity> pkern: If all goes well, I'd expect to release it in < 24h.
<genkgo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
<ubot5> Launchpad bug 1456985 in linux (Ubuntu) "Filesystem goes read-only while creating VSS snapshot on HyperV" [Undecided,New]
<genkgo> apw: While browsing through other bugs related to Hyper-V in the Ubuntu kernel, I found this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1445195. These patches will solve my problem. The reported problem here https://social.technet.microsoft.com/Forums/windowsserver/en-US/8807f61c-565e-45bc-abc4-af09abf59de2/ubuntu-14042-lts-generation-2-scsi-errors-on-vss-based-backups is an exact copy of the problem we are having.
<ubot5> Launchpad bug 1445195 in linux (Ubuntu Wily) "[Hyper-V] Kernel patches for storvsc" [High,Triaged]
<infinity> genkgo: Ahh, lovely, thanks.
<infinity> apw: Bonus points if you can get those on to all the master-nexts before the next SRU cycle happens. :)
<genkgo> infinity: for me this also great news. i had the feeling i was on my own with this problem. now fortunately i see there are many others that have the problem. and there is already a patch it.
<infinity> genkgo: Always nice to see that it's ultimately not our fault, too. :P
<genkgo> hehe, i totally understand that!
<apw> sigh, i believe we are waiting on some testing for those from microsoft, will chace that up
<genkgo> apw: if there is any testing we can do: please let me know. i'd love to help.
<apw> genkgo, yep, will make sure you get some test kerenls
<genkgo> apw: wonderful, thanks for the good work
<jsalisbury> genkgo, Should have test kernels for each release in about 15 to 20 minutes
<genkgo> jsalisbury: wonderful!
<genkgo> jsalisbury: should build a kernel myself then or is it apt-get install? i am not extremely familiar with building a kernel.. :)
<jsalisbury> genkgo, I'll have the kernels as a .deb file, then you can dpkg -i them
<genkgo> jsalisbury: aight, that would be no problem :)
<jsalisbury> genkgo, there is already a vivid kernel here: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/  Building the other releases now
<genkgo> jsalisbury: we are on trusty with vivid kernel, so i can use those already
<genkgo> jsalisbury: i am still working on something else now, but will make sure to install today. last time it took 36 hours before we had a machine crashed on backup, and then we were creating backups every hour.
<jsalisbury> genkgo, great.  You just need to install the linux-image and linux-image-extra .deb packages.
<jsalisbury> genkgo, ok, thanks
<genkgo> jsalisbury: great, thanks for the work
<jsalisbury> genkgo, np
<jsalisbury> genkgo, thanks for offering to test!
<genkgo> jsalisbury: sure, we would like to get rid of the problem asap. i am going to run the tests on a production machine. on machines with not enough activity (test machine) we were not able to reproduce the bug. or we did not wait long enough (4 days, backup every hour).
<sforshee> FourDollars: that patch gets INPUT_PROP_BUTTONPAD set for the xps 13 touchpad in i2c mode, though 015fdaa9f8edd89a456b3331088e1b77ebdad9d0 does as well
<genkgo> jsalisbury: could you say which patches are applied to that build?
<jsalisbury> genkgo, yes, they are the following:
<jsalisbury> scsi: storvsc: Increase the ring buffer size
<jsalisbury>   scsi: storvsc: Size the queue depth based on the ringbuffer size
<jsalisbury>   scsi: storvsc: Always send on the selected outgoing channel
<jsalisbury>   scsi: storvsc: Retrieve information about the capability of the target
<jsalisbury>   scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
<jsalisbury>   scsi: storvsc: Don't assume that the scatterlist is not chained
<jsalisbury>   scsi: storvsc: Set the tablesize based on the information given by the 
<genkgo> jsalisbury: thanks, how about this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454758?
<ubot5> Launchpad bug 1454758 in linux (Ubuntu Wily) "[Hyper-V] storvsc: Set the SRB flags correctly when no data transfer is needed" [Critical,Triaged]
<jsalisbury> genkgo, that particular commit is not in that test kernel.  It was cc'd to upstream stable and should come down through the normal stable process. 
<jsalisbury> genkgo, I can build a test kernel the that commit and the previous 7 I posted
<genkgo> jsalisbury: i am not able to qualify whether the particular bug we are having (backups with hyperv) is related to that one, or to the storvsc onw. can you?
<jsalisbury> genkgo, I don't believe it is related to eh backups bug, which is why it was requested in a seperate bug report
<genkgo> jsalisbury: just to be sure: the build you created fixes a.o. the backup bug, right?
<jsalisbury> genkgo, correct
<genkgo> jsalisbury: lovely :)
<jsalisbury> genkgo, I'll be building Utopic and Trusty test kernels as well, the commits are requiring a little backporting, so taking a little longer than expected.
<genkgo> jsalisbury: ok, but i need the one you already have builded, so that is no problem
<jsalisbury> genkgo, cool
<genkgo> jsalisbury: at least, i do not see a reason why i should go back to 3.13 kernel
<FourDollars> sforshee: So what's the difference between yours and the original one? I mean if there is no your commit, what's going to happen?
<sforshee> FourDollars: basically they arrived on the list at about the same time, and they went ahead and took both. For the xps 13 the results are identical; possibly for some other touchpads one or the other might not work.
<FourDollars> sforshee: I see
<FourDollars> sforshee: Thanks for your explanation.
<sforshee> FourDollars: obviously I like my approach better ;-)
<FourDollars> sforshee: haha
<genkgo> jsalisbury: i am having dependency problems
<jsalisbury> genkgo, I now have test kernels for Trusty and Utopic if your willing to test?  All the test kernels are available from: http://kernel.ubuntu.com/~jsalisbury/lp1445195/
<jsalisbury> genkgo, Can you post any errors you are seeing
<genkgo> jsalisbury: http://paste.ubuntu.com/11247594/
<genkgo> jsalisbury: while runing sudo dpkg -i *.deb
<jsalisbury> genkgo, try only installing one package at a time.  First the linux-image package then the linux-image-extra package
<genkgo> jsalisbury: no difference
<genkgo> jsalisbury: could it be the same dependency errors that i was having before?
<genkgo> apw: could this be the same dependency problem?
<genkgo> jsalisbury: there is only a problem with tools and cloud tools
<genkgo> image headers and extra are doing fine
<jsalisbury> genkgo, you won't need linux-tools or linux-cloud for this testing, only linux-image and linux-image-extra
<jsalisbury> genkgo, So these two .debs:
<jsalisbury> linux-image-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
<apw> jsalisbury, yes if you are installing a "standard" kernel, not lts-foo, then you need to switch to the default linux-tools-common things
<jsalisbury> 	linux-image-extra-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb	
<genkgo> jsalisbury: those are installed
<jsalisbury> apw, is linux-tools needed for testing these hyper-v commits?  I didn't think so
<genkgo> jsalisbury: microsoft is saying they are required
<genkgo> jsalisbury: they are required, in which sense (backuping or otherwise) is unknown
<genkgo> jsalisbury: http://paste.ubuntu.com/11247689/
<genkgo> jsalisbury: so i still have the linux-lts-vivid-cloud-tools-common package
<jsalisbury> genkgo, Hmm, I wonder if we need to remove that first.  Is this on a non-production system, so we can remove it first.  Then run:
<jsalisbury> sudo apt-get install -f
<jsalisbury> sudo apt-get clean
<jsalisbury> sudo dpkg -i linux-tools-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
<genkgo> jsalisbury: this is production :)
<genkgo> jsalisbury: not working, same error: linux-tools-3.19.0-17-generic depends on linux-tools-3.19.0-17; however: linux-tools-3.19.0-17-generic depends on linux-tools-3.19.0-17; however:
<jsalisbury> genkgo, let me see if I can install it locally
<apw> i think you need to remove the lts-foo versions of the common tools packages, which in fixed packages wont exist
<apw> and then you ought to get the appropriate ones installed instead, the ones that got removed last time when installing lts-vivid
<jsalisbury> genkgo, so remove this one:  linux-lts-vivid-cloud-tools-common 
<genkgo> jsalisbury: already did
<genkgo> no differece
<jsalisbury> genkgo, can you run the dpkg -l command again, to see what else is there
<genkgo> jsalisbury: 
<genkgo> jsalisbury: http://paste.ubuntu.com/11247908/
<jsalisbury> genkgo, can you purge all of the linux-tools pacakges then reinstall just linux-tools-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
<jsalisbury> sudo dpkg --purge PACKAGENAME
<genkgo> jsalisbury: sorry, but same issue
<genkgo> http://paste.ubuntu.com/11247941/
<genkgo> you can see, all purged, won't install
<genkgo> hmm
<jsalisbury> genkgo, It looks like it did install, see line 586
<jsalisbury> iU  linux-tools-3.19.0-17-generic       3.19.0-17.17~lp1445195              amd64        Linux kernel version specific tools for version 3.19.0-17
<genkgo> no, it got errors while installing
<jsalisbury> genkgo, same dependency error:
<jsalisbury> ?
<jsalisbury> genkgo, hmm, I wound if it's because I added ~lp1445195 onto the package name.  It doesn't cause issues with the kernel, but maybe the tools package doesn't like it
<jsalisbury> genkgo, let me build one more kernel without that extra text
<genkgo> jsalisbury: ok, i will wait for that, my system is pretty clean now: http://paste.ubuntu.com/11248013/.
<jsalisbury> genkgo, ok, building now, it should only take 15minutes or so
<genkgo> jsalisbury: i just got a reply from microsoft on my bug report
<genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
<ubot5> Launchpad bug 1445195 in linux (Ubuntu Wily) "duplicate for #1456985 [Hyper-V] Kernel patches for storvsc" [High,Triaged]
<genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
<genkgo> jsalisbury: he is telling we also need https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454758, which is not included in your build
<ubot5> Launchpad bug 1454758 in linux (Ubuntu Wily) "[Hyper-V] storvsc: Set the SRB flags correctly when no data transfer is needed" [Critical,Triaged]
<jsalisbury> genkgo, Ok, I'll add it to my next build.  
<genkgo> jsalisbury: ok, thanks a lot
<genkgo> i will wait for that before testing, thanks for the stuff you have already done
<jsalisbury> genkgo, np
<jsalisbury> genkgo, I have an updated kernel available at: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
<infinity> pkern: The trusty kernel with that fix should be hitting -proposed on mirrors over the next 15-30 minutes (it just hit disk on ftpmaster).
<genkgo-> jsalisbury: still have dependency problems: Package linux-cloud-tools-3.19.0-18 is not installed.
<genkgo-> Same for the tools package
<jsalisbury> genkgo, I'll have to investigate further.  We may be able to just use the --ignore-depends with dpkg since this is only a test kernel.
<genkgo-> apw: can this be related to dependency problems we had before?
<infinity> No, it's not related to the previous issue, it's that jsalisbury builds his test kernels a bit differently from how they're built in the archive, I'd guess.
<infinity> Oh, and it's a vivid kernel, not an lts-vivid kernel, which changes things somewhat.
<infinity> Hrm.  That tools package is indeed useless. :P
<infinity> Just a bunch of symlinks into the missing package that you don't have built.
<jsalisbury> genkgo, we might get away without installing tools just to test this bug, but I'll test locally to see if I can get it to install.
<infinity> jsalisbury: AFAIK, he needs the tools for the backup thingee to work.
<infinity> jsalisbury: And your build didn't produce all the right packages.
<genkgo-> infinity: that is what i believe too
<infinity> jsalisbury: Did you just do a binary-generic build instead of a full build?
<genkgo-> i dont know how ignore depends works
<infinity> genkgo-: Don't bother, ignoring deps will just leave you a bunch of dangling symlinks.
<jsalisbury> infinity, I used this:
<infinity> No actual binaries.
<jsalisbury> fakeroot debian/rules clean && fakeroot debian/rules binary-headers && fakeroot debian/rules binary-generic
<jsalisbury> so thats probably it
<infinity> jsalisbury: Yeah.  Do a full build instead.
<infinity> jsalisbury: THen you'll get the common packages, etc.
<jsalisbury> infinity, ack, thanks.  First time someone needed the tools package from me :-)
<jsalisbury> infinity, do you happen to know the option for a full build off hand?  If not, I'll dig it up
<apw> jsalisbury, to make the tools you need binary-tools as well
<jsalisbury> apw, got it, Thanks!
<jsalisbury> genkgo, I should have an updated tools package for you shortly
<genkgo-> jsalisbury: aight, i will make sure to go ahead with it right away, thanks again!
<jsalisbury> apw, doing a 'fakeroot debian/rules binary-tools' produced an error:
<jsalisbury> dpkg-gencontrol: error: package linux-image-3.19.0-18-tools not in control info
<jsalisbury> dh_gencontrol: dpkg-gencontrol -plinux-image-3.19.0-18-tools -ldebian/changelog -Tdebian/linux-image-3.19.0-18-tools.substvars -Pdebian/linux-image-3.19.0-18-tools returned exit code 255
<jsalisbury> debian/rules.d/2-binary-arch.mk:407: recipe for target 'binary-tools' failed
<jsalisbury> make: *** [binary-tools] Error 2
<flexiondotorg> infinity, I've had a few sponsor requests turned down.
<flexiondotorg> infinity, Please take a peek at this - https://bugs.launchpad.net/ubuntu-mate/+bug/1456591
<ubot5> Launchpad bug 1456591 in ubuntu-mate-artwork (Ubuntu) " ubuntu-mate-artwork 0.4.8 bug fix release [debdiff attached]" [Wishlist,Incomplete]
<flexiondotorg> infinity, I'm just wanting to know if this is standard practice?
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1456597
<ubot5> Launchpad bug 1456597 in ubuntu-mate-settings (Ubuntu) " ubuntu-mate-settings 0.4.5 release [debdiff attached]" [Wishlist,Incomplete]
<flexiondotorg> sorry. Wrong channel.
<jsalisbury> apw, ah ha.  This what is needed to build the tools: fakeroot debian/rules binary-perarch
<jsalisbury> genkgo, There is a new tools package called linux-tools-3.19.0-18_3.19.0-18.18_amd64.deb at the URL: 
<jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
<garrettr> I'm working on building Ubuntu kernels w/ grsecurity
<garrettr> The command I use to build the kernel is make-kpkg --initrd --overlay-dir=../ubuntu-package kernel_image kernel_headers
<garrettr> Where ubuntu-package is a copy of /usr/share/ubuntu-package from an up-to-date version of Ubuntu trusty (currently running 3.13.0-53)
<garrettr> I have seen other guides recommend download the ubuntu-trusty git repo from kernel.ubuntu.com, and replace some of the Debian control scripts from /usr/share/kernel-package with the ones in the git repo
<garrettr> My questions are: 1. why do this? 2. why don't the control scripts in ubuntu-trusty/debian/control-scripts match those in /usr/share/kernel-package/{image,headers}?
<bjf> sbeattie, i'm following up on the apparmor tests
<bjf> sbeattie, i'm looking at: http://kernel.ubuntu.com/testing/dagmar__3.13.0-53.89__2015-05-20_21-43-00/ubuntu_qrt_apparmor/results/ubuntu_qrt_apparmor.test-apparmor.py/debug/ubuntu_qrt_apparmor.test-apparmor.py.DEBUG.html
<cyking> jsalisbury, let me know when/if you have time to assist with that bug report. thanks :)
<jsalisbury> cyking, sorry, I got side tracked today, I'll have the next kernel built shortly.
<cyking> jsalisbury, all good! thanks.
#ubuntu-kernel 2015-05-21
<arges> cyking: why is there a y in your nick
<cyking> Cy King
<arges> cyking: ah, sorry thought you were cking : )
<sbeattie> bjf: if you look at http://kernel.ubuntu.com/testing/dagmar__3.13.0-53.89__2015-05-20_21-43-00/console_output.txt.html you'll see apt-get update pulling trusty, trusty-security, and trusty-updates Sources, but not for trusty-proposed.
<sbeattie> which tells me that there's no deb-src line in apt sources.list for trusty-proposed.
<pkern> infinity: Thanks. I'll have a look this morning.
<henrix> pkern: please let me know too if that kernel looks ok ;)
<genkgo> jsalisbury: that new build is doing better
<genkgo> jsalisbury: could tools was installed, but to install tools, i need binutils >= 2.25
<genkgo> i am still on 2.24 (i guess because i am on trusty with 3.19 kernel)
<genkgo> perhaps i can still with --ignore-depends
<genkgo> jsalisbury: just ran sudo dpkg --ignore-depends=binutils -i linux-tools-3.19.0-18*.deb and the package was installed
<genkgo> apw: could you confirm that it is alright to ignore binutils dependency in this case?
<apw> genkgo, i think you should be ok indeed
<genkgo> apw: well wonderful, then i can start testing the patches
<genkgo> :)
<infinity> pkern: As soon as you can get me some positive "yay, it fixes the bug" results on that trusty kernel, I can unleash it on the masses.
<niluje> what's the difference between the UIO and the VFIO drivers?
<pkern> infinity: Yeah, I'm in the office now to test. :)
<infinity> pkern: \o/
<infinity> pkern: Looks like we'll just barely make my 24h turnaround guess, then. :)
<pkern> infinity: lgtm, thanks :)
<pkern> henrix: ^^
<henrix> pkern: ack, thanks!
<infinity> pkern: Ta.  Releasing them all, then.
<cyking> good morning!
<cyking> 3.19.0-18-generic botched my AMD video driver (fglrx)
<apw> cyking, what version did it work with before that ...
<apw> cyking, and ... what does "botched" mean to you
<cyking> checking,
<cyking> Linux Main-PC 3.19.0-031900-generic
<apw> cyking, ok that is a mainline kernel, did it work with any of our official kernels
<cyking> apw: yes -worked with the last official kernel
<apw> cyking, which is the last one you actually tested, which version number
<apw> as -17.17 and -18.18 are mostly identical in the video arena iirc
<cyking> all these kernels worked - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1453391  
<ubot5> Launchpad bug 1453391 in linux (Ubuntu) "Very slow Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)" [Medium,Confirmed]
<cyking> checking my /var/log/apt  I believe it was linux-image-extra-3.19.0-16-generic
<apw> ok, so that is more believeable as there are actully some changes from -16 to -18
<apw> cyking, now can you describe botched for me
<cyking> apw: i get the radeon driver instead of the fglrx driver.  and radeon doesn't let me work with multiple displays.
<apw> did fgrlx build against -18 for you ?
<cyking> apw, i really just did a gui update and did not have any errors.  is there a log i can check for you?
<cyking> does help:  /var/log/apt:  http://pastebin.com/bea9Ck6a
<apw> cyking, there is a log in /var/lib/dkms, like here i have this for nvidia dkms package i happen to have installed: /var/lib/dkms/nvidia-340-updates/340.76/3.19.0-16-generic/x86_64/log/make.log
<apw> obviously subsitute in the versions you have installed of radeon
<cyking> apw, http://pastebin.com/7VEixiZn
<apw> cyking, so that seemed to build ok, if that was the right kernel version
<apw> /var/lib/dkms/nvidia-340-updates/340.76/3.19.0-16-generic/x86_64/log/make.log
<apw> grrr
<apw> so
<apw> DKMS make.log for fglrx-updates-core-15.200 for kernel 3.19.0-16-generic (x86_64)
<apw> that is the log for -16 which worked we want the one for -18
<cyking> apw: should i boot into -18 and try to force reinstall the dkms driver?
<cyking> there is no log for -18
<apw> cyking, can you list the packages with 3.19.0-18.18 in their version ...
<apw> dpkg -l | grep 3.19.0-18
<cyking> http://pastebin.com/J0ZT5TZX
<apw> cyking, you don't have the headers installed for that kernel, so dkms cannot build fo rit
<apw> cyking, do you have the right meta package installed for the kernel?  linux-generic ?
<cyking> strange. if i have linux-headers-3.19.0-16-generic and linux-headers-3.19.0-16 installed wouldnt apt-get update automatically install the latest?
<cyking> *dist-upgrade
<apw> cyking, headers are pulled in by linux-headers-generic
<apw> whihc is a dep of linux-generic
<apw> i assume you have lost some of your meta packages somewhere along the line
<cyking> thanks apw: installing now. must of gotten removed accidental with all my kernel testing with my other bug im trying to deal with.
<apw> cyking, very likely it got removed when you jammed something else on, apt loves to do that for you
<apw> and although it is right there in front of you, i find one never notices it
<cyking> how do i rebuild now ?
<apw> shoving the headers on should trigger the dkms build automatically
<apw> you should see it in the output when you apt-get install linux-generic or whatever
<cyking> is it doing it here:   run-parts: executing /etc/kernel/header_postinst.d/dkms 3.19.0-18-generic /boot/vmlinuz-3.19.0-18-generic
<cyking> i see the  log now. thanks
<apw> that looks believeable, once you get a prompt back you should be able to see the log
<apw> so then a reboot should use that driver i'd say
<cyking> is there an idiots guide on doing a kernel bisect ?  
<apw> there is a wiki guide, but i normally ask joe, he is a bisect speciialist
<apw> jsalisbury, ^
<cyking> jsalisbury seems pretty busy :)
<cyking> i use to kernel hack in 2.4 days but so much has changed.
<jsalisbury> cyking, I actually started a bisect for your bug
<cyking> jsalisbury, thanks
<jsalisbury> cyking, there was a build failure so I had to skip some sha1s.  I should have a kernel ready soon
<jsalisbury> cking, actually the next kernel is ready.  I'll upload it and post a link in the bug
<cyking> jsalisbury, you are a star!
<jsalisbury> :-)
<cyking> and you too, awp, thanks
<cyking> jsalisbury, ill install the *rc3.201505211629_all.deb ?
<jsalisbury> cyking, You should just need: linux-image-3.13.0-031300rc3-generic_3.13.0-031300rc3.201505211629_amd64.deb
<jsalisbury> cyking, just run: sudo dpkg -i linux-image-3.13.0-031300rc3-generic_3.13.0-031300rc3.201505211629_amd64.deb
<jsalisbury> cyking, then reboot
<cyking> yup understood
<cyking> sudo make internet faster ?
<cyking> ;)
<jsalisbury> heh
<cyking> jsalisbury, worked fine.
<jsalisbury> cyking, great.  I'll update the bisect and build the next kernel
<cyking> wish i could see a screen cast of what you were doing ;)
<bjf> sbeattie, i think the trusty apparmor testing is fixed
<bjf> sbeattie, it worked once :-) ... we'll see for sure next week (new kernel SRU cycle)
<sbeattie> bjf: hehe
<sbeattie> bjf: the trusty apparmor sru should fix https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1304447 so please do comment on that bug report
<ubot5> Launchpad bug 1304447 in apparmor (Ubuntu) "apport-bug crashing on server install" [Medium,Fix released]
<bjf> sbeattie, comment added
<dsmythies> Somewhere between kernel 4.0 and kernel 4.1RC1 "perf record" became broken. Actually the list of available "Tracepoint event"s become very much smaller. My concern is with "power:pstate_sample", which is now missing. I have started to bisect the kernel, but thought to ask here also, as I really don't have 2 days to waste. Anybody know what is going on with this?
<rtg> dsmythies, are you booting vanilla or ubuntu kernels ? ubuntu does carry some ftrace patches.
<dsmythies> I only compile the mainline kernel, using the Ubuntu kernel config.
<rtg> dsmythies, nothing springs to mind.
<dsmythies> I'll continue my bisection (my second one for the 4.1RC series...)
<nessita> jsalisbury, hi there, are you around?
<nessita> jsalisbury, just wanted to sync about the bisect we're doing for LP: #1201528, since I'm now in 3.8.13.1 and audio died with the underrun error. So I re-read all the comments and noticed that in commnet #39 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1201528/comments/39) I reproduced the issue with kernel 3.8.0-27-generic
<ubot5> Launchpad bug 1201528 in linux (Ubuntu Vivid) "[INTEL DP55WG,Realtek ALC889] - Audio Playback Unavailable" [Medium,Confirmed]
<nessita> I'm now installing latest 3.7 from http://kernel.ubuntu.com/~kernel-ppa/mainline/ which is 3.7.10 and see if audio breaks, will report in the bug
<jsalisbury> nessita, ack, thanks for the info
<nessita> jsalisbury, so 3.7.10 works (used skype heavily, and hangouts), and in theory 3.8.0 did not work (from comment #39). Which kernel shall I try next?
<nessita> want me to re-test 3.8.0? I guess that'll be v3.8-raring?
<jsalisbury> nessita, probably 3.7 final, then we can bisect between 3.7 and 3.8.  3.7 final is avaiable at:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/
<jsalisbury> nessita, it might be a good idea to test 3.8 final as well to confirm it has the bug.  3.8 final is avaiable at:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-raring/
<nessita> jsalisbury, ah, hum, I always thought that 3.7.0 (from the link you just gave me) is "older" than 3.7.10. Am I mistaken? 
<jsalisbury> nessita, yes you are correct.  But we can't bisect between 3.7.10 and 3.8 because the tree splits as of 3.7.1.  
<nessita> ah! that makes more sense :-)
<nessita> I will them test both finals, 3.7.0 and 3.8.0 and report back
<nessita> jsalisbury, kernel 3.7.0 is frozen on boot when showing the message "Loading initial ramdisk", can not reboot with ctrl+alt+del nor with alt+petsys+b, doing hard reboot, but wondering if it should boot OK
<jsalisbury> nessita, it should boot ok.  We can skip to trying v3.8-rc1 if there are issues with 3.7 final.  3.8-rc1 is available here:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc1-raring/
<nessita> jsalisbury, hum, there may be something broken in my computer now, because 3.8.0 freezes the same as 3.7.0
<nessita> may boot without quiet and see where it freezes
<jsalisbury> nessita, ok
#ubuntu-kernel 2015-05-22
<genkgo> apw: did you finish building the new kernels regarding the hyperv problem or did jsalisbury?
<apw> genkgo, i don't know, i left that with him sorry
<genkgo> apw: aight, then i will contact him when he returns here
<Taloth> Is there a specific release planning for trusty 3.13.0-53 or just "when it's ready?". I'm anxious for -54 :)
<henrix> Taloth: 3.13.0-53.89 has been released, right?
<henrix> Taloth: at some point next week you should have the -54 in -proposed (a new SRU cycle begins next week)
<Taloth> Yeah, didn't check the repo... oops there. Hopefully that means... Yup -54 is what I was after. 
<Taloth> Tnx.
<Taloth> Guess I can finally get some users to test those fixes next week.
<cyking> Good morning!
<mnaser> If I ran into a bug in the current Ubuntu Kernel, should I report that to upstream or report it Ubuntu?
<mnaser> I have the full dmesg and dumps from linux-crashdump which I hope would help resolve it
<LocutusOfBorg1> mnaser, can you reproduce with an upstream vanilla kernel?
<LocutusOfBorg1> also testing debs from here http://kernel.ubuntu.com/~kernel-ppa/mainline/
<LocutusOfBorg1> might be useful to understand if the bug is still there
<smirnoff_> Hello. Weâre hitting data corruption issues on ext4 under heavy load, introduced in 3.13.0-49 release, pinpointed it to 74fb93abc863b9ff5d1a28c3d9d729e29fd570af in ubuntu-trusty
<smirnoff_> I saw bunch of ext4 commits going to 3.16 and 3.19 releases - are there any plans to merge them to 3.13?
<ePirat> hello
<ePirat> I have Linux 3.19.0-16-generic (shipped with ubuntu vivid vervet) installed, what would be a previous versions and other previous versions of that kernel and where to optain them?
<ePirat> (doing kernel bisect and want to make sure to choose everything correct this time)
<ePirat> unfortunately links on wiki are all not helpful at all
<awreece> I'm trying to debug a perf issue in my application, so I'm trying to collect user space stack traces for calls to ftrace that take more than 10s. I've successfully managed to get ftrace to print a probe for calls to `SyS_futex` that take longer than 10s using `set_filter_function`, but this whole space is pretty confusing to me.
<awreece> I see the `trace-cmd` sets `set_filter_function:stacktrace:unlimited` when it records kernel stack traces, but setting the equivalent for userstacktrace doesn't work
<awreece> looking at `ftrace_trace_userstack` in ` kernel/trace/trace.c`, I see a couple of ways to abort early
<awreece> is there a way to verify that the correct bits are set in `trace_flags`, or that this funciton is being called, etc?
<awreece> (also -- hi -- if this is the wrong channel to be discussing in, I sincerely apologize -- could you point me in the right direction?)
#ubuntu-kernel 2015-05-23
<sfsdfgh> apw: awake?
<sfsdfgh> installing build deps didn't work for the required ncurses to run the config command you wrote on the buildyourownkernel page
<sfsdfgh> several ncurses packages are installed ncurses-devel is not a package 
<ePirat> Hello
<ePirat> Already asked yesterday and got no answer, soâ¦
<ePirat> I have Linux 3.19.0-16-generic (shipped with ubuntu vivid vervet) installed, where to find previous versions of that kernel? 
<ePirat> (preferably already packaged so I can install them easily)
<genkgo> http://packages.ubuntu.com/vivid/i386/linux-image-3.19.0-15-generic/download
<genkgo> i guess you will have to download the specific needed packages seperately
<genkgo> ePirat: and install with dpkg -i *.deb
<genkgo> ePirat: but honestly, i am far from experienced in ubuntu kernels
<ePirat> how to find older ones? I need a list of them as I need to install many
<ePirat> going back to 3.18
<ePirat> (as I need to find in which version a special bug was introduces)
<ePirat> *introduced
<genkgo> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<genkgo> ePirat: does that help?
<ePirat> Ah yes
<ePirat> thanks
<fprietog> Hello, I got a problem with HDMI sound in 3.19.0-18-generic kernel under Ubuntu 15.04 64bits
<fprietog> I'm sure problem is with the kernel because the previous kernel 3.19.0-18-generic doesn't have it
<fprietog> But I don't knowwhere to open a bug and what is the info needed to have it checked
<fprietog> Here are some screenshots I took
<fprietog> This is the sound config with kernel 3.19.0-16-generic. You can see there is HDMI sound device available (and works):
<fprietog> http://rt002nf0.eresmas.net/Temp/FPGLINUX%203.19.0-16-generic_01.jpg
<fprietog> This is the same creenshot with newest kernel 3.19.0-18-generic. HDMI device doesn't appears:
<fprietog> http://rt002nf0.eresmas.net/Temp/FPGLINUX%203.19.0-18-generic_01.jpg
<fprietog> Can anyone, please, point me where to open a bug and the info needed? Thanks :)
<cyking> fprietog, https://help.ubuntu.com/community/ReportingBugs
<fprietog> Thanks cyking
#ubuntu-kernel 2015-05-24
<stevecam> would anyone have a build log for a kernel just laying around, and recent one will do
<apw> stevecam, all the main launchpad builds for the archive retain full logs
<apw> which can be found on the +source page
#ubuntu-kernel 2016-05-23
<wget> Hi guys. Wrt a question I posted here during the week-end, but as you were absent, let me ask it again.
<wget> Guys: I had a discussion ages ago with one of your kernel maintainer about this topic, and it's still not resolved and still impacting Ubuntu (while haven't tested 15.x nor 16.x series).
<wget> https://bugzilla.kernel.org/show_bug.cgi?id=75381
<wget> that bug is related to this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883?comments=all
<wget> DO you have any news about this?
<ubot5> bugzilla.kernel.org bug 75381 in Network "Several disconnections that could lead to kernel panic" [High,New]
<ubot5> Launchpad bug 1269883 in linux (Ubuntu) "0b95:1790 [Asus N55SF] Bad performance of Asix Ethernet-to-USB device on USB3 port" [Medium,Incomplete]
<davmor2> wget: is it using kernel mod alx by any chance?
<davmor2> wget: I ask due to this issue http://askubuntu.com/questions/616182/alx-on-ar8191-does-not-appear-to-be-working-15-04/620489#620489
<wget> davmor2:  lsmod |grep alx doesn't report anything when the adapter is connected
<wget> so I assume it isn't using that mod
<wget> the device is not a quallcomm atheros
<davmor2> wget: ah okay no worries 
<wget> mine is an Asix ax88179_178a
<wget> like all USB3.0 to Ethernet you can find in Europe
<TJ-> I've got a live issue here right now with 16.04, wonder if anyone has some ideas? GUI user with $HOME/.Xauthority file, which is subsequently "mount --bind /dev/shm/user/.Xauthority $HOME/.Xauthority" .. "xauth -f ... list" shows the MIT_MAGIC_COOKIE on both 'sides' identical... but then, after doing "xauth -f /dev/shm/user/.Xauthority generate :0 ." the cookies on each side of the bind mount differ
<TJ-> and a hash of the file confirms the actual files are different - the 'target' doesn't reflect the content of the updated 'source'. Is this a weird kernel issue?
<apw> TJ-, you are bind mounting a file ?
<apw> TJ-, it looks like so, if so, it could well be linking the new name to the original inode
<TJ-> apw: yes, correct, ahhhh and xauth (I read the source!) does a hard-link rename!
<TJ-> apw: THANK you!! This has been causing some automation bugs that have been very annoying
<apw> you can prolly prove that by linking the original file to a temp name before you replace the auth
<TJ-> so, need to figure out a workaround
<apw> and then catting into the extra name, and see if the one on the real home then changes
<TJ-> yeah, that makes sense now. OK, so we just need to take care of the timing of the --bind 
<apw> symlink the .Xauthority into a like .config/Xauthority/.Xauthority
<apw> and bind mount the .config/Xauthority perhaps ?
<apw> or .config
<TJ-> apw: that did it, thanks :)
<spice> Hi all! I have to following issue: I develop a Linux network driver. The driver compiled and worked without any issues. After I upgraded the gcc package on my Ubuntu 14.04.4 LTS machine, the kernel module produces paging bugs.
<god> spice, what did you upgrade from, to?
<spice> that is a good question ... I think it was a rahter minor gcc upgrade
<spice> right now it is:  4.8.4-2ubuntu1~14.04.3 Before it might have been 4.8.4-1ubuntu.... or so.
<spice> Is there any way to reinstall previous version of packages to make sure my claim is correct?
<apw> spice, yes, all old versions are available via the launchpad librarian
<apw> https://launchpad.net/ubuntu/+source/gcc-4.8/+publishinghistory
<spice> okay, i will try that and see if this is definitely the culprit of my problem. Thank you for now!
<apw> spice, it is not uncommon for a gcc upgrade to expose existing bugs through changes in optmisation, the -fpie becoming default in yakkety is finding all sorts of latent bugs
<tseliot> rtg: all the nvidia drivers should be fixed in 16.10 now
<tseliot> mamarley: ^
<rtg> tseliot, thanks, I'll get the kernel ADT tests re-ran
<tseliot> rtg: yes, as soon as the nvidias are published
<rtg> right
<tseliot> (I've just uploaded the fixes)
<mamarley> \o/
#ubuntu-kernel 2016-05-24
<kdarknight> how can i report to system about a mouse event?
<kdarknight> like what function should i call to tell my system that mouse right button is clicked?
<kdarknight> from a driver? i think i have to use input_report_key(); somehow but unable to made it work till now
<kdarknight> input_report_key(dev, BTN_RIGHT, 1);  this is what i am calling
<apw> kdarknight, that sounds about right to me
<kdarknight> http://pastebin.com/GLjBtTpZ this is what i have done so far
<kdarknight> its a small mouse driver
<kdarknight> i am trying to controll mouse events by writing to a dev file
<kdarknight> but looks like system doesn't detect those events
<kdarknight> apw, there is no error, everything works except those events. Don't know what i am doing wrong here :/
<apw> kdarknight, can you see your new channel on lsinputs and does input_events show them
<kdarknight> apw, what should i look for in lsinput? I can see 0-7 event list
<kdarknight> 7th one is null 0x0
<apw> you are attempting to register a new input stream, lsinput shows you all valid ones
<apw> does your new one appear there when the driver is loaded
<kdarknight> let me rmmod and insmod again to compare results
<apw> if so, input_events against the number for it, will show you what events if any you are generating
<kdarknight> oh yeah, when i removed my mod and did lsinput, event 7 was removed
<kdarknight> and it came back after insmod
<kdarknight> but all the values are null except bits ev
<kdarknight> let me pastebin the result of last event
<kdarknight> http://pastebin.com/i4Mg4dfA apw
<apw> kdarknight, that might be ok
<apw> so what does input-events 7 show
<apw> when you run your thing
<kdarknight> it detects all the events there
<kdarknight> like ev key pressed, released and all
<apw> so the issue is what?  that your cursor doesn't move ?
<kdarknight> yes, nor does right click
<apw> so the x-server choses which input streams to watch based on their capabiilties
<apw> so ... you might wnat to compare those to a real mouse
<kdarknight> is it possible that i am doing in virtualbox, that might be the problem?
<apw> kdarknight, no idea, sorry
<kdarknight> okay thanks anyway. Where can i go from here to make this work?
<apw> kdarknight, have a look at the X log to see what it thought our your mouse appearing
<apw> kdarknight, tail /var/log/Xorg.0.log as you insert the module
<apw> and compare that to a real mouse, maybe you arn't enough like a mouse for the x-server to like you
<kdarknight> awp here http://pastebin.com/AvH1ifJK
<kdarknight> how can i compare with real mouse? :/
<apw> kdarknight, you'd need to plug one into something which has usb
<apw> kdarknight, but it is clear that your device is making X unhappy
<apw> kdarknight, as it tried to "query" it and failed
<apw> you'll prolly have to get the xorg source and find out what that means
<kdarknight> plug one which has usb?
<kdarknight> i can't understand
<apw> kdarknight, i am saying you need to find any machine anywhere which has X on it, and take the mouse out and put it back
<kdarknight> i have ubuntu installed in virtual box
<kdarknight> i can take out usb and plug it in again
<kdarknight> mouse
<kdarknight> is that what you are saying?
<apw> anyhow, you know its X rejecting the thing, becuse it says so, so it doesn't matter
<kdarknight> oh
<apw> the next step is to find out what that X error means, what it tried to do to your input device
<apw> so you can make your device do someting it likes
<kdarknight> Okay! thanks for your help
<manjo> rtg, can you install gdb on xenial-amd64 chroot in tangerine ?
#ubuntu-kernel 2016-05-25
<seb128> hey
<seb128> we have reports of upower being delayed on usb enumartion issues xenial which leads to unity-settings-daemon segfaults
<seb128> which seems fixed in https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/include/linux/usb.h?id=feb26ac31a2a5cb88d86680d9a94916a6343e9e6
<seb128> can anyone tell me if that commit is going to naturally land in the next kernel SRUs or that needs a bug to track the change?
<apw> seb128, that is marked for stable, so i would hope it would come down that route
<seb128> apw, any idea when? can we get it in the next update?
<apw> seb128, as it is in the 4.7 merge window it won't be considered until -rc2-3 is released 
<seb128> seems to hit quite some users
<apw> seb128, most likely, so if it is urgent, then a bug with that info in it requesting it be SRUd is good
<apw> seb128, and if you drop the bug# here i can ask jsalisbury to shepherd it
<seb128> thanks
<jsalisbury> seb128, apw I'll dig into it
<seb128> jsalisbury, thanks
<kamal> gerow, fyi, the new Trusty kernel version to fix bug 1582864 is available now in -proposed (3.13.0-87.133)
<ubot5> bug 1582864 in linux (Ubuntu Wily) "use after free of BOS in usb_reset_and_verify_device" [Medium,Fix committed] https://launchpad.net/bugs/1582864
<seb128> apw, jsalisbury, bug #1565292 seems about that issue
<ubot5> bug 1565292 in linux (Ubuntu) "usb 3-2: device descriptor read/64, error -71" [Medium,Incomplete] https://launchpad.net/bugs/1565292
<seb128> you can probably use it for SRU
<gerow> kamal: wonderful, looking at it now. Thanks!
#ubuntu-kernel 2016-05-26
<pixel6692> Hello, can I use http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/ on 16.04 Willy?
<pixel6692> *xenial
#ubuntu-kernel 2016-05-27
<rbasak> jsalisbury: FYI, I just reassigned bug 1584042. Looks credible.
<ubot5> bug 1584042 in linux (Ubuntu) "Hyper-V NIC cannot pass IPv6 UDP packets by default until protocol offload is disabled" [Undecided,New] https://launchpad.net/bugs/1584042
<rbasak> I don't know what kernel version he's using though. I guess I'll let the bot handle that.
<jsalisbury> rbasak, thanks, I'll look into it.
<mamarley> ricotz: So did you see that message someone just posted on the graphics-drivers mailing list?  Some peopleâ¦
<mamarley> Oh wait, sorry, wrong channel.  I meant to put that in #ubuntu-x.
<ricotz> mamarley, hi, no, haven't seen it
<mamarley> Some guy just made a post ranting about how the NVIDIA drivers had never worked properly without giving any useful details and in general being an unappreciative loser.
 * ricotz reads
<ricotz> hmm, yeah, this isn't helpful at all, no real information as you said
<ricotz> I can't say much since I don't have a system with both intel and nvidia gfx
<ricotz> does the zenbook really have a nvidia card? the support for the latest skylake graphics was a bit unfortunate as well
<djs> is a v4.6-wily kernel going to appear in the mainline kernel ppa? I see all the rc's [1234567] and v4.6-yakkety
<apw> djs, that extension is about which configuration was used as a base to build it, yakkety's is a more appropriate one than wily
#ubuntu-kernel 2016-05-29
<quietone> can't boot 16.04, gets this error: tpm_crb MSFT0101:00: can't request region for resource
<quietone> a search didn't help me, but did find this, https://lkml.org/lkml/2016/4/18/893
<quietone> more details: https://askubuntu.com/questions/778832/16-04-wont-boot-after-latest-updates
<Guest51562> is vfio-pci built in to the kernel?
#ubuntu-kernel 2017-05-22
<Guest88565> I tried to add hardware sensors monitor to top panel from the "add to panel" list and the display froze badly.  ubuntu MATE 16.04.  I reinstalled, and I am afraid to try it again.. 
<niluje> who creates the file /run/net-<iface>.cfg?
<ogra_> wasnt that klibc's ipconfig ?
<niluje> ogra_: probably, thanks
<hallyn> sforshee: i have a phone which, when in hotspot mode, can be connected to by a windows laptop and a (linux harmattan) nokia n9, but not my thinkpad with 4.4 or 4.8.  Can that be an intel driver issue, or do i look at wpa_supplicant?
<sforshee> hallyn: could potentially be either
<sforshee> hallyn: do you see it in scan results, but it just fails to connect when you select the network?
<hallyn> yeah,
<hallyn> it seems to connect but immediately get dropped
<hallyn> nl80211: Failed to set interface 0 to mode 10: -22 (Invalid argument)
<sforshee> if you give me your syslog I'll take a look at it
<hallyn> ok - don't think there's much there, i do also have the wpa verbose output, not sure if that's helpful to you;  
<hallyn> i *think* http://paste.ubuntu.com/24624452/   is the relevant portion, and http://paste.ubuntu.com/24624453/ is the wpa output
<sforshee> wlan0: a4:e4:b8:17:e9:7c denied association (code=12) - that's a new one to me
<sforshee> hallyn: it looks like the hotspot is denying the association request and giving back a "reason unspecified" status code, so that's not very helpful
<sforshee> I think that's probably more of a supplicant-level issue, not 100% sure though
<hallyn> ok thx, i'll dig into that then and assum eit's not the intel
<hallyn> \o
<sforshee> np, good luck!
<hallyn> hm.  wel linterestingly the n9 linux phone which manages to connect does not run wpa.  really thinking wpa-supplicant is the miscreant here
<hallyn> tried running wpa_supplicant from trusty (bc there were rumblings about 2.3 -> 2.4 breaking things) but no go
#ubuntu-kernel 2017-05-23
<hallyn> cyphermox: sforshee: i built wpa 2.6-4 from debian experimental on xenial and installed on my laptop- success.  2.1 and the default 2.4 fail to connect (to my blackberry hotspot phone as hotspot)
<hallyn> thanks to that assine ci train crap polluting my laptop i had to build ina container, else i'd consider trying to bisect or something
<ricotz> hello, please take notice of this upload failure https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/12622891
<apw> ricotz, *expletive deleted*
<apw> ricotz, how did you get informed of that
<ricotz> apw, I am using the hwe-edge kernel
<apw> ahh
<ricotz> while the i386 turned up the amd64 didnt, so I have looked
<ricotz> apw, I assume you deleted the conflicting package and going to retry this amd64 build?
<apw> ricotz, i am going to do something
<ricotz> alright
<apw> ricotz, the conflicting package has already gone, but there is some nbs in teh PPA i think
<steven> oi guys, is there a log of sorts for canonicals live patch service?
<refeaime> Hello
<refeaime> Does ext4 devs are here?
<steven> try #ext4 and #linuxfs refeaime 
<apw> Beret, 
<apw> bbcmicrocomputer, s
 * apw hits his keyboard with a large stick ... sorry
<ogra_> just remove the tab key ;)
<Beret> steven, - canonical-livepatch status --verbose
<apw> xnox, hey ... cgroup2 /sys/fs/cgroup/unified ... is that something we turned on in artful in systemd ?
 * apw boggles that B-eret happend to the be right person for that
 * Beret boggles at andy's lack of aith
<Beret> faith
<apw> Beret, heh, no i mean i hit B<tab> by accident, nothing to do with the preceeding lines, and in attempting to hit <del> i hit <ret>
<Beret> hah
<apw> so that you might know the answer was just complete bonus
<steven> the bin doesnt exist on my system Beret 
<steven> only /snap/canonical-livepatch/22/canonical-livepatchd
<xnox> apw, yes
<Beret> steven, you don't have /snap/bin/canonical-livepatch ?
<xnox> apw, there are a few things that need fixing still, but so far it's working ok. What did you notice?
<xnox> https://github.com/systemd/systemd/blob/master/NEWS#L15
<steven> ah I dont have snap in my PATH that was it :D
<steven> Beret: can I see the last time it did patch?
<steven> I just see last checked
 * Beret looks for a machine that isn't freshly rebooted
<cyphermox> hallyn: if you send debug logs for wpa (working and not working), maybe we can tell from that what patch you'd be missing.
<cyphermox> or if you tell me what hardware, maybe I have something close enough that it will fail as well
<steven> backstory, my server crashed big time last night. was unable to use it so I had to hard reset it (pull the plug) and that shit never happened
<steven> the only thing I did was enable live patch a week ago or two
<Beret> apw, can you grab a colleague who's working on CLP?
<Beret> bjf, awake?
<apw> ben_r, ^
<hallyn> cyphermox: well the laptop is thinkpad t440s with Intel Corporation Dual Band Wireless-AC 7260 nic;  hotspot is blackberry passport phone.  the bad wpa logfile is at  http://paste.ubuntu.com/24624453/ , i'll generate a new good one in a bit
<hallyn> cyphermox: the logfile when it works (wpa 2.6)  http://paste.ubuntu.com/24634013/
<cyphermox> hallyn: cool, I'll look
<cyphermox> I would start to be suspicious of whatever your blackberry does for an accesspoint though
<hallyn> yeah, but like i say a nokia n9 (linux) and a windows laptop have no issue.
<sforshee> tseliot: I have some updates for the nvidia drivers to fix build issues with 4.11 - bug 1691839 and bug 1691841
<ubot5> bug 1691839 in nvidia-graphics-drivers-304 (Ubuntu) "nvidia-graphics-drivers-304 304.135-0ubuntu1 ADT test failure with linux 4.11.0-3.8" [High,Confirmed] https://launchpad.net/bugs/1691839
<ubot5> bug 1691841 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-graphics-drivers-340 340.102-0ubuntu3 ADT test failure with linux 4.11.0-3.8" [High,Confirmed] https://launchpad.net/bugs/1691841
<cyphermox> hallyn: that doesn't mean much, they could be just as "broken", but since there's a patch somewhere we can apply...
<tseliot> sforshee: cool, thanks, I'll have a look at them soon
<cyphermox> hallyn: I think I see a hint to find the right patch; there's that cmd 20 there that happens before authenticate in the broken case, and before deauth in the working case. It might be nothing but it gives me something to look for
<hallyn> cyphermox: cool.  what's cmd 20
<cyphermox> del_station
<cyphermox> something I'd expect to see "more" when deauthenticating than when authenticating
<cyphermox> but I'm no wifi expert
<cyphermox> sforshee: halp, could use your input as well :)
<sforshee> cyphermox: when I looked yesterday it looked like the hotspot didn't like the association data for some reason, which caused the kernel to send that cmd 20
<cyphermox> ja
<sforshee> cyphermox: I'd need to refresh my memory to make sense of what those supplicant logs add to the picture
<cyphermox> it doesn't seem to add much to what you've just said
<sforshee> but there's nothing that really tells us _why_ it didn't like it
<cyphermox> at least not to me to try to find what patch might be missing
<cyphermox> right
<cyphermox> the status is rejected, unspecified.
<sforshee> I guess if hallyn sniffed the on-air frames from both a successful connection and a failed one we could see what's different
<hallyn> can i tcpdump -i wlan0 on the laptop itself or will that miss them?
<sforshee> hallyn: you might need to have a monitor interface to get the wlan frames, I can't remember for sure. /me tries.
<hallyn> (gonna be in meetings for awhile so won't be able to try for awhile)  
<hallyn> i wish i could get logs from the bb itself.  if only i had a purely open source modern phone ...
<sforshee> hallyn: I'm only seeing higher-level frames that way
<sforshee> http://pastebin.ubuntu.com/24634952/ will get the wlan frames
<sforshee> didn't show this, but don't forget to use -w to actually capture the frames to a pcap
<hallyn> and you want to see the result of that with the broken wpasuplicant?
<sforshee> hallyn: oh, is there a supplicant that works? I must have missed that part. What would be most useful is to see a working and non-working association to compare them.
<hallyn> sforshee: yeah, when i take 2.6 from debian experimental, and install it in xenial (built in a xenial container), that works
<hallyn> (2.4 from zesty does not work)
#ubuntu-kernel 2017-05-24
<Sargun> Why does each distro have its own git repo: https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide 
<Sargun> er, release
<Sargun> How do I build linux-tools from the vanilla kernel tree
<apw> Sargun, they are in their own repos to reduce size of any one clone (old releases are not included) and to some degree minimise risk of damage to any one series.
<apw> Sargun, don't really understand what you mean by "vanilla tree" in the tools context
<anpok> I am using 4.10.0-21 on two intel machines one is a i7 and the other is a dual xeon. on both I frequenty run into soft lockuk - usually related to firefox: https://paste.ubuntu.com/24641800/
<anpok> I am curious how much of that is a firefox problem.. or really a kernel problem.. killing firefox does not help after some time other sys calls get stuck i.e. fork stops working..
<apw> anpok, soft lockups normally are a kernel side issue, expecially if they do not self resolve
<apw> anpok, ie does that "stuck for" increase
<anpok> let me look through the logs
<anpok> oh I should have scrolled further up .. it starts with something else:
<anpok> http://paste.ubuntu.com/24642183/
<anpok> looks like bug #1674838
<ubot5> bug 1674838 in linux-hwe-edge (Ubuntu) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [Undecided,In progress] https://launchpad.net/bugs/1674838
#ubuntu-kernel 2017-05-25
<tseliot> sforshee: uploaded. Thanks for your help!
<sforshee> tseliot: awesome, thanks!
#ubuntu-kernel 2017-05-26
<Orphis> Hey there
<Orphis> I've been having issues for ages with sound output and I know that using the kernel 4.2.0-35 from a previous release (even with current userspace) just works
<Orphis> So I'm trying to bisect the kernel git to find the faulty change
<Orphis> It appeared somewhere between the release using 4.2 and the one that moved to 4.4
<Orphis> My problem is that git bisect tries to test some changes in 4.1 and for some reason, that kernel won't boot (stuck at loading init ram image)
<Orphis> Do you have any guesses why it would do that? I'm testing random commit manually now since I can just "skip" commits with bisect :(
<Orphis> And there are like 349 commits left...
<Orphis> Oh, and basically, my problem is that sound doesn't work properly anymore as in some sound sources will work, some won't. The device seems to be stuck in some kind of exclusive mode since I can't play multiple sounds together
<Orphis> And since this is an HTPC running Kodi, it's easy to check if a kernel works or not: I don't have sounds in the menus but *some* medias will play sound fine (not all)
<apw> jsalisbury, ^
<jsalisbury> apw, ack.
<jsalisbury> Orphis, do you happen to have a bug opened in Launchpad for this issue?  I could help you bisect and build kernels for you to test.
<Orphis> jsalisbury: I haven't, I hoped to find a similar one, but it looks like I can't
<Orphis> So I figured a single user haveing an issue with maybe some hardware that isn't that common isn't going to help resolving it
<jsalisbury> Orphis, we can try.  you can open a bug by running the following in a terminal: "ubnutu-bug linux"  or you can do it thoght the web interface
<Orphis> I bisecting right now, but since I couldn't boot 4.1 kernels apparently, I just picked a random 4.2 version from the git bisect visualize list, tried it (it works) and now I have more revisions to test :-/
<Orphis> I guess I should do it from a bad kernel
<Orphis> The problem is that it just takes forever to rebuild the vanilla kernel with the ubuntu options
<jsalisbury> Orphis, it's good that 4.2 is good, you can now work forward until you find the first bad version.
<jsalisbury> Orphis, we have pre-built mainline kernels.  It might be worth testing these ones:  
<Orphis> It just weird, git describe shows 4.1rc and 4.2rc changes
<Orphis> From what bisect is trying to test
<jsalisbury> 4.2 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.2-wily/
<jsalisbury> and 4.3 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.3-wily/
<jsalisbury> Orphis, if 4.3 final has the bug, you could try some of the 4.3 release candidates from the same page:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<Orphis> What's the commit granularity?
<jsalisbury> Orphis, once those are narrowed down, I can build kernels for you
<Orphis> I can build kernels too, the HTPC is a 3 year old i5, it's quite decent :)
<jsalisbury> Orphis, between 4.2 final and 4.3 there are like 13K commits
<Orphis> Though, it's no 24 core machine :P
<Orphis> jsalisbury: Do you know a way to automatically trim down unused modules from my kernel config based on what I'm currently using?
<Orphis> That would cut down the build times considerably probably
<jsalisbury> Orphis, you could run dmesg and lspci and see what's being used and remove what's not being used.  That might run the risk of other errors though.
<Orphis> Yeah, I know... Not easy
<Orphis> Or consistent
<Orphis> I'll try this revision that bisect suggest then try your kernels
<Orphis> Still compiling so it will take a bit
<Orphis> jsalisbury: Should I use the 4.3 mainline or skip to rc1 directly?
<Orphis> jsalisbury: I can provide you with a bisect log if you are interested
<Orphis> https://pastebin.com/cYThEiag
<jsalisbury> Orphis, maybe try -rc1 to start with.  If it is good, try rc2 or later like rc3/4
<Orphis> jsalisbury: So, 4.3-rc1 doesn't work
<jsalisbury> Orphis, ok, it looks like we shoudl bisect between 4.2 and 4.3-rc1
<Orphis> Yup, that's what I've been doing :p
<jsalisbury> Orphis, it might also be worth while to test current mainline to see if the bug was already fixed
<Orphis> Well, it's not fixed in 4.10, from latest release
<jsalisbury> Orphis, that's available here:
<jsalisbury> http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc2/
<Orphis> I can try that too though
<jsalisbury> Orphis, ack.  If it is fixed in 4.12-rc1, it's probably best to perform a "Reverse" bisect to identify the fix
<Orphis> Well, if it's fixed in 4.12, I'll just use that until Ubuntu releases a new version I guess
<Orphis> So much faster to download a kernel than building it...
<Orphis> Nop, doesn't work
<Mehul> Does Ubuntu 16.04.0 GA kernel ensures stable kabi for its lifetime?
<mdeslaur> Mehul: quite the opposite
<Orphis> jsalisbury: How should I test kernels when it's stuck at "Loading initial ramdisk..."? Is there any way to get debug output on screen for this step?
<Orphis> Even though I edit the boot parameters and remove quiet and splash, I still don't see anything :-/
<jsalisbury> Orphis, yeah, those can be difficult to get around.  sometimes you have to just "git bisect skip"  or review commits to see if there is a fix in later versions
<Orphis> I have no idea of what's going on at all
<Orphis> I can't get any output
<jsalisbury> Orphis, I can build you a test kernel if you send your latest bisect log
<Orphis> jsalisbury: https://pastebin.com/NCScMejM
<Orphis> I'm trying commits manually now since skip only stays in the 4.1 branch
<Orphis> Well, not really 4.1 but that's what describe says
<Orphis> The "git bisect visualize" output in gitk isn't easy to grasp, a lot of tangled merges
<Orphis> I'm thinking it could be an issue with gcc-6 that I have on my system or something similar
<Orphis> Compiling v4.2-rc7-648-g3be66711b6 now to eliminate a few changes...
<sforshee> b ubuntu-kernel
#ubuntu-kernel 2017-05-27
<Mehul1> I have a question regarding 16.04 Ubuntu Kernel ABI compatibility. I recently ran into an issue while using "get_user_pages_locked" API. I have an out-of-tree kernel module integrated with DKMS which uses this API and was working fine on 16.04.0/1, however when i switched to 16.04.2 (desktop ISO, kernel version 4.8), I found that API signatures wer
<Mehul1> e changed and I had to fix the code in prod environment
<Mehul1> My question is If I stick to 16.04.0/1 GA kernel version and never explicitly opt for HWE kernel, would Ubuntu ensure that all patch releases on GA kernel don't break existing kernel surface?
<Mehul1> I understand that new APIs might be added, but I am more concerned about existing APIs being used by my module.
#ubuntu-kernel 2017-05-28
<hkg-secTeam> hi
<hkg-secTeam> anyone can help?
<teward> ask a real question then maybe
<teward> !anyone
<teward> oh shut up bot
<kralisec> hello
<kralisec> I put informations with BUG #1690796, I would like to have some guidance if I need to make a bug report
<ubot5> bug 1690796 in linux (Ubuntu) "Swap pagefault is hanging paged processes with kernel BUG assert in include/linux/swapops.h" [High,Incomplete] https://launchpad.net/bugs/1690796
<kralisec> I would like to be sure to give all what is expected
#ubuntu-kernel 2018-05-21
<ph88^> thx tomreyn 
<walac> hi there, is there any doc on how to build a custom kernel for bionic? I need to enable v4l2
<tomreyn> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<tomreyn> walac: ^
<tomreyn> this is a topic for #ubuntu, though
<walac> tomreyn: I was following it, but editconfigs seems to not be an option anymore
<tomreyn> walac: okay, sorry, i'm not sure when
<walac> ok, thanks anyway
 * apw wonders what is wrong with editconfigs ?
<tomreyn> walac: thereS also https://help.ubuntu.com/lts/installation-guide/s390x/ch08s06.html
<walac> I tried with apt-get source, let me try with git clone
<walac> tomreyn: let me check it, thanks
<tomreyn> if the latter is wrong, i guess this would be considered a documentation bug. it also refers to newer kernel versions so i guess you could succeed there.
<walac> it feels like https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is still valid for the git clone path
#ubuntu-kernel 2018-05-23
<RetardedOnion> Hi there! I couldn't find a list of changes of Ubuntu-Kernel vs Mainline. Is there a list for someone who is not interested in studying the source?
<apw> RetardedOnion (N,BFTL), that info is most broadly represented in the changelog for the package
<s10gopal> jsalisbury, can i test the SRU ?
<jsalisbury> s10gopal, I'll check if the fix made it to proposed yet.
<jsalisbury> s10gopal, so the fix is now in proposed.  The bug will automatically get updated asking you to test.
<jsalisbury> s10gopal, however, it you want to test before you can enabled -proposed
<jsalisbury> s10gopal, let me get a link to show you how to do that.
<jsalisbury> s10gopal, See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. 
<s10gopal> jsalisbury, what is the package name to test ?
<jsalisbury> s10gopal, the kernel, so linux-image-generic
<s10gopal> jsalisbury, http://kernel.ubuntu.com/sru/kernel-sru-workflow.html dont have any package named linux-image-generic
<jsalisbury> s10gopal, I wouldn't use that web page.  Use the page I posted to enable -proposed or follow the testing request comment when it's added to the bug.
<s10gopal> jsalisbury, i have enabled -proposed
<jsalisbury> s10gopal, great, so now just update the kernel and reboot.
<jsalisbury> s10gopal, you shoudl get kernel version:
<jsalisbury> s10gopal,  4.15.0-23.25 for bionic
<jsalisbury> s10gopal, or 4.13.0-44.49 for artful
<s10gopal> jsalisbury, no update  available
<jsalisbury> s10gopal, Oh, it looks like that kernel hasn't been promoted to proposed yet.  You just have to wait a little longer.
<jsalisbury> s10gopal, You should get an update in the bug when it's ready for testing.
#ubuntu-kernel 2018-05-24
<steven> morning guys, my NIC's stopped working. over the weekend and I managed to verify that its not an HW issue. now since the box was up and running just fine for the last couple years (ubuntu 16.04) and I didnt update anything manually the only idea I have is that a kernel patch broke it
<steven> I am using canonicals live patch, so was there a new patch over the weekend or is there any issue that could explain the issue with a recent patch?
<apw> ben_r, ^
<apw> steven, there should be logging somewhere to say when if any patches were applied
<ben_r> apw, I didn't see the original message?
<steven> "somewhere"?
<apw> ben_r, steven has a machine which was up for a very long time, he believes his nic stopped working and that this is not h/w
<steven> somewhere in a web UI or on the server?
<apw> ben_r, and was asking if a livepatch was released over the weekend
<apw> i assume we log application locally somewhere ...
<apw> as i am running cosmic i am not using it
<ben_r> steven: if you're looking for if a livepatch is applied, there would be logs in /var/log/syslog, or dmesg if this was recent enough, and if the system is accessible, you can look in /sys/kernel/livepatch for entries there
<ben_r> ahhhhh, ok
<steven> I booted into live systems and those saw the NIC's so its definitely not a HW failure
<steven> I have a (very shitty) serial console 
<ben_r> over the weekend no, there was one on monday, the bionic patch did include a wifi fix
<steven> sounds about rightd
<steven> well depending on the TZ that is, but I was using the server on sunday and monday it stopped working
<steven> so somewhere between sun/mon somehing must have happened
<steven> ben_r: I dont ahve /var/kernel/syslog
<apw> /var/log/syslog
<ben_r> it's /var/log/syslog
<steven> ah ok
<steven> so lemme check
<steven> anything I can grep for?
<ben_r> steven: grep -i livepatch will turn up what time a patch was loaded
<ben_r> steven: for the record the wifi fix was in mac80211_hwsim, to plug a memory leak...
<apw> ben_r, that doesn't sound like something one would be using on a server nic
<steven> ok so livepatch did something on may 21st
<apw> steven, does the nic claim to be up in system config, if you ask it to cycle for instance
<steven> ok so if I lspci it seems to be listed, broadcom corporation NetXtreme BCM 5720 ghigabit ethernet PCIe
<steven> apw: not quite sure what yuou mean 
<apw> steven, was asking if the nic still claimed to have an address etc
<steven> claimed it where?
<steven> the system doesnt see the NIC :D
<steven> from ubuntu/network configuration perspective it doesn't exist apw ben_r, I can't configure it, ip link show/ifconfig dont list it. its gone.
<steven> lspci seems to list the hardware at least
<apw> steven, has this system been rebooted since or did it just dissappear with the system up
<apw> i guess we ought to see it going away in syslog if it has not rebooted
<steven> yes ofc, had to verify the HW was still available. by booting a live system
<apw> so can you see anything in syslog regarding the livepatch being applied and between that and the reboot regarding the nic ?
<apw> when you rebooted, did you get the kernl base or are you upgraded to the main kernel with the fixes applied
<steven> a sec, going thru the log right now looking for the  moment it threw errors
<steven> apw: how can I check that?
<steven> I only have one entry
<steven> in grub that is
<steven> so there is something I guess could be of interest, on may 21st, some modules load log "inserted module iscsi_tcp" and ib_iser
<steven> and then I get hundred of lines of log for that very same second and the next thing u know it cannot bring up the eno1 
<steven> apw: ben_r ^
<ben_r> steven: can you pastebin the messages?
<steven> I actually can't, will a sceenshot do? (its a real shit serial console
<ben_r> steven: sure, just so we can read it, preferably the beginning where the errors start
<steven> gimme a couple minutes, I host images on the server. need to upload stuff on dropbox instead :D
<steven> https://www.dropbox.com/s/zlaqmcnffj5gg30/Screenshot%20at%2015-44-27.png?dl=0
<steven> ttps://www.dropbox.com/s/6e3z2m2wt6a85ej/Screenshot%20at%2015-44-43.png?dl=0
<steven> second 47, now hundred of systemd and kernel lines 
<steven> and eventually
<steven> ttps://www.dropbox.com/s/ion6uoxgvqbma9e/Screenshot%20at%2015-47-05.png?dl=0
<steven> and thats it ben_r 
<steven> now its just a bunch of network error logs cos it cannot find the eno1 
<ben_r> steven: I don't see anything odd here kernel-wise. You said it could see the device in lspci right? any chance this server has a BMC in it with a shared network port? eno1 would be the builtin port, so the BMC might have stolen it
<steven> I don't know what a BMC is
<steven> and lspci lists it, yes. 
<ben_r> steven: it's the controller for the server, lets you remote power on/off, probably manages that serial console too
<steven> oh its an HP server, it has this iLo which is a thing on its own
<steven> unrelated to the actual nic's
<ben_r> hmm
<steven> its really dumb, I simply dont know where to look or what to present to figure out whether this indeed is a kernel issue or not.
<steven> it would make sense tho since it stopped working right around the time the live patch was released
<steven> and every other os has no issue with it
<ben_r> steven: the next thing I'd do is grep on eno1, make sure that the driver you're using grabbed the device and nothing else renamed it
<ben_r> if you can reboot it again, right after you boot a 'dmesg | grep eno1' might turn something else up too
<steven> ah right, bout that
<steven> the serial console for some reason won;t accept |
<steven> so I can't even pipe.
<ben_r> oh wow
<steven> I know, ok so Imma have to leave the house right now
<steven> I appreciate your help, do you mind if I ping u later again?
<ben_r> sure, feel free
<steven> thank you! ttyl.
<steven> ben_r: I am back for a bit, you happen to be around?
<ben_r> steven: yep
<steven> nice! so like. I am not a kernel guy and don't really now much about driver stuff in general, but if I know lspci lists the HW is there a way to see what happens in the kernel
<steven> like whether it loads a driver or errors out?
<steven> and that without using a pipe :D
<ben_r> steven: are you using the driver provided by ubuntu or broadcom's driver?
<steven> all stock ubunti
<ben_r> I *think* that card uses tg3
<steven> I didn't install/compile anything nor used a custom ppa
<ben_r> so lspci -v should show a "kernel driver in use" line for each device
<ben_r> give that a try first...
<steven> https://paste.ubuntu.com/p/gZT4s23Kmy/
<steven> it even says NIC 2
<ben_r> try it again with sudo, but I'm pretty sure you can see drive in use without that
<ben_r> *driver
<steven> dammit
<steven> console is not big enough
<ben_r> try 'sudo lspci -v -s 03:00.1', that should do just your card
<steven> https://paste.ubuntu.com/p/4MtzgYTfqY/ ben_r 
<ben_r> steven: yeah, I don't see a driver...
<ben_r> hmm
<steven> https://paste.ubuntu.com/p/YCkBgbFdRP/ ip link show, just to show that it really doesnt show up
<ben_r> yeah, no surprise there, no driver == no device :) you could try to load the driver with 'sudo modprobe -v tg3'
<steven> ah look at this
<steven> ï¿½ modprobe -v tg3                                                               
<steven> modprobe: FATAL: Module tg3 not found in directory /lib/modules/4.4.0-81-generic
<apw> steven, do you have -extra installed ?
<steven> whats the pkg name?
<apw> linux-image-extra-4.4.0-81-generic i assume
<steven> not installed
<steven> but I didnt install nor remove anything 
<steven> ok so I do have the tg3.ko file in a folder for 4.4.0-66
<ben_r> try the modprobe again
<steven> I mean I could just cp it into the currents kernel folder and hope for the best?
<steven> still, fatal. module not found]
<ben_r> after you install extras it should appear in the right place
<steven> I can;t install anything ;D
<ben_r> well, the 4.4.0-66 one won't work
<ben_r> presumably you have 4.4.0-66 kernel installed?
<ben_r> if you can reboot into that kernel, the driver should load and you'll get the network back. 
<steven> ok so.. can I instruct grub to load a specific kernel?
<steven> I never actually told a system what kernel to boot]
<steven> but I do have the 66 installed
<steven> still
<ben_r> I think the iLO gives you a boot console right? if you hold shift during boot GRUB should pop a menu up and let you pick the older kernel
<steven> sure. lemme reboot it
<ben_r> you want the second entry, "Advanced options for Ubuntu" then pick the 66 kernel from there
<steven> press or hold?
<ben_r> hold it while it boots
<steven> it takes a couple minutes cos it does some hp init stuff before it actually loads grub
 * ben_r nods
<steven> so what happended? the driver got removed from the kernel and was moved into extra and the live patch upated the kernel?
<apw> steven, livepatch doesn't change the installed kernel on disk, if the kernl didn't have extras there it was not installed
<steven> booted to the previous kernel, now it works!
<steven> gosh thank you ben_r and apw, probably not the right channel for this but I highly appreciate it!
<ben_r> steven: one more thing
<steven> sure?
<ben_r> please make sure to update your kernel to something recent, those kernels are old and there have been manditory reboots, so they are not receiving livepatches
<ben_r> make sure you get -extras along with it
<ben_r> :)
<steven> I wanted to update to 1804 but iirc its not safe to update yet
<ben_r> that's an even bigger jump, yes. the safest thing to do is move up to the current 16.04 kernel
<steven> at what point is the dist upgrade considred safe? wasnt it the first .1 release?
<ben_r> steven: as a dev I'm not really the right person to ask, all of my systems are 18.04 with latest of everything :) you'd have to consider your own needs there. 
<steven> ok, did you just run dist upgrade?
<steven> I am not a total linux noob, I know my way around it (except interals/kernel stuff)
<steven> but last time I upgraded from 14.04 to 16.04 something went real bad and some person told me I did it too early (after the release ofc)
<ben_r> steven: well, again I am not telling you what you should do, this is my experience with it - I went from 16.04 to 18.04 beta using do-release-upgrade, and had no issues on 3 systems
<ben_r> it's not supposed to break ;)
<ben_r> but like always, make sure you have a good backup before whatever you choose to do
<steven> sure, data is stored some place else anyway
<ben_r> :)
<steven> ok did an update, upgrade, isntalled extra, now rebooting.
<steven> awesome, up and running! Again, thank you. appreciate the help
<ben_r> :)
<ben_r> my pleasure :) glad to help!
<s10gopal> jsalisbury, can you please tell how to install -proposed manually ? i am not able to get the update through update manager
<jsalisbury> s10gopal, The steps are all on this wiki:
<jsalisbury>  https://wiki.ubuntu.com/Testing/EnableProposed
<s10gopal> jsalisbury, i have enabled them , and tried some command told on #ubuntu , but not able to get it
<s10gopal> told by hggdh, 
<jsalisbury> s10gopal, did you look at that wiki?  I would just copy and paste what on there to here.  Are you seeing an error when following the wiki?
<s10gopal> jsalisbury, in software & update -> developer option -> i have tick pre realease update and running software update says system is upto date
<s10gopal>  https://paste.ubuntu.com/p/M5c6z2XNpc/
<s10gopal> and the log by manually running command 
<jsalisbury> s10gopal, did you reboot after that?  If so, what does uname -a return?
<s10gopal> yes
<s10gopal> 4.15.0-22-generic
<hggdh> I can see, in the proposed pocket, a linux-generic version 4.15.0.23.24
<jsalisbury> s10gopal, What does your /etc/apt/sources.list look like?  Does it have '-proposed' instead of '-updates'?
<jsalisbury> s10gopal, so bionic-proposed instead of bionic-updates?
<hggdh> s10gopal: what command, exactly, did you run to update the kernel?
<s10gopal> http://paste.ubuntu.com/p/Jh9pk8srZF/
<s10gopal> hggdh, sudo apt update && sudo apt full-upgrade
<s10gopal> also created the file /etc/apt/preferences.d/proposed-updates with this content:
<s10gopal> and changed xenital to bionic too
<hggdh> s10gopal: this is quite strange. I just enabled proposed, and ran update && full-upgrade, and I DO SEE kernel 4.15.-=23 being noted as going to be installed
<s10gopal> hggdh, how can i install it manually ?
<jsalisbury> s10gopal, you could download the kernel as a .deb directly from: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/14927311
<s10gopal> even this is not working sudo aptitude -t bionic-proposed   sudo: aptitude: command not found
<hggdh> ...
<hggdh> why are you trying to use aptitude?
<s10gopal> it is on the link
<s10gopal> sudo apt-get upgrade -s , says everything is upto date
<hggdh> s10gopal: if you are using apt-get you NEED apt-get dist-upgrade, *not* just a apt-get upgrade
<hggdh> if using apt (NOT apt-get) you need apt full-upgrade
<hggdh> I have no idea on aptitude
<s10gopal> sudo apt update && sudo apt full-upgrade says everything is upto date
<hggdh> s10gopal: dpkg -l linux\* | pastebinit, and give us the link
<s10gopal> http://paste.ubuntu.com/p/dG2bJ3X7WH/
<hggdh> OK, so you do not have the proposed kernel installed. Now, please run again sudo apt update && sudo apt full-upgrade, and give us ALL the output on a pastebin
<s10gopal> hggdh, http://paste.ubuntu.com/p/cqPN53S2Hg/
<hggdh> s10gopal: this is not what I asked for
<s10gopal> hggdh, https://paste.ubuntu.com/p/kjVmVbCjDh/
<hggdh> s10gopal: OK, so what is going on is your repository mirror (in.archive.ubuntu.com) is not yet up-to-date. Nothing we can do.
<hggdh> s10gopal: you may try another mirror, or wait.
<s10gopal> hggdh, how ?
<hggdh> how what?
<s10gopal> hggdh, change download from india to main server ?
<hggdh> run software update, and select a different mirror
<hggdh> then you MUST apt update && apt full-upgrade again
<s10gopal> hggdh, even http://archive.ubuntu.com/ubuntu says it is uptodate 
<s10gopal> hggdh, which server you are using ?
<hggdh> s10gopal: see https://paste.ubuntu.com/p/j7ZRcpKBxS/
<hggdh> s10gopal: works for me on the main repository. You are certainly doing something wrong
<s10gopal> hggdh, i am typing the command you gave me
<hggdh> s10gopal: then please type it as you issued it here
<s10gopal> hggdh, https://paste.ubuntu.com/p/qnndDcSjT5/
<s10gopal> jsalisbury, linux-image-unsigned-4.15.0-23-generic_4.15.0-23.25_amd64.deb (7.5 MiB) , only need to install it ?
<jsalisbury> s10gopal, If you want to try that route, you should install the linux-modules, linux-modules-extra and linux-image-unsigned .deb packages.
<jsalisbury> s10gopal, you should try to get your system back to a point where you can use the GUIs at some point.
#ubuntu-kernel 2018-05-25
<krakrjak> I'm wanting to test out some kernel patches I'm authoring and I can't seem to get a build. My patches are not applied yet, I updated the debian/changelog and now can't get a build.
<krakrjak> I think this has to do with using the linux-signed package. Any pointers?
<bjf> krakrjak, have you looked at: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<krakrjak> bjf: yes, that's what I was following. It says to update the debian/changlog to inclue a +test1 version so I won't get confused when I install the patched version.
<krakrjak> When I do that I get KeyError: 'linux-libc-dev: package version not found'
<bjf> krakrjak, show me what "head -1 debian.master/changelog" looks like
<bjf> krakrjak, which sries are you building? i assume bionic
<krakrjak> bjf: I am building bionic, using the apt method not the git method.
<krakrjak> bjf: here are the two changelog entries that matter, mine at the top and the extant one below it https://paste.ubuntu.com/p/M5TdMRdRVN/
<bjf> krakrjak, yes, it's the change to linux-image that it's not pointing at the signed package that is making it impossible for those instructions
<bjf> krakrjak, the best thing is to use the git method
<krakrjak> bjf: ok, will try that.
<krakrjak> bjf: does the apt method work then? what would it still be good for if you can't do local version bumps? just curious
<bjf> krakrjak, looks like you can also try "apt-get source linux-image-unsigned-$(uname -r)"
<krakrjak> bjf: worth a shot. I'll try that too :) thanks for the tip!
<bjf> krakrjak, with the git method you can easily get to your current version, past versions and possibly the next version. you use git tags to build the one you want.
<krakrjak> bjf: yeah, it's just super heavy on disk for the small patch I want to test. starting with the packaged version is much better for me to play with in this situation.
<krakrjak> bjf: I'll have to do the git method eventually anyway, I just wanted to start playing with the code right away to see if I'm no the right track and I'm still at 2% cloning while I can get a test build before that even completes.
<bjf> krakrjak, you can also play with --depth with git. that doesn't grab quite so much
<krakrjak> bjf: In the end it will be fine. I do want the whole git tree...
<krakrjak> bjf: Thank you for your help, I'm able to apply my patches and build the linux-image-unsigned packages with the proper version bump. I'll test with that for a bit.
<krakrjak> What do I need to do to get code upstreamed if I do get something going well? In particular I'm extending the caiaq usb sound driver.
<krakrjak> Any pointers on what to do to play nicely with the process would be really helpful.
<bjf> krakrjak, you want to subscribe to the linux kernel mailing list (kernel.org)
<bjf> krakrjak, and then probably start googing for "how to contribute to the linux kernel"
<krakrjak> bjf: I'm trying to find the team that is responsible for this driver and I'm coming up empty... If you have any suggestions I'll take them, but if not I'll just keep digging.
<krakrjak> thanks again for all your help! I'm well on my way :)
<bjf> krakrjak, look in the MAINTAINERS file in the root of the kernel sources
<krakrjak> bjf: thank you. I will poke through that in more detail.
<krakrjak> so I build a kernel with an updated changelog entry, but it didn't seem to add my +test1 version to the deb packages. Am I editing the wrong file?
<krakrjak> is it right to edit the debian/changelog or debian.master/changelog when using the linux-image-unsigned binary package?
<lokus> hi- (u16.04.4) i installed kernel 4.15.0-13-generic, and had a kernel crash which produced a vmcore for me in /var/crash. i installed package linux-image-4.15.0-13-generic-dbgsym to be able to go through the kernel dump, but crash utility is telling me this when i go to view it: "crash: /usr/lib/debug/boot/vmlinux-4.15.0-13-generic and vmcore.201805251123 do not match!" <--- how could 
<lokus> this be?
<cascardo> what's the output of file vmcore.201805251123 ?
<lokus> vmcore.201805251422: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style
<lokus> turns out i had 4.15.0-13.14 and not 4.15.0-13.14~16.04.1 for dbgsym, to match my kernel. i found the right matching dbgsym and i no longer get that mismatch error.  instead in its place i get 'crash: cannot resolve "init_level4_pgt"' . i'll keep googling
<lokus> ah looks like i just need crash 7.2.
<cascardo> don't you have a dump file?
<cascardo> if you are running xenial, you certaily need a newer crash
<lokus> yes i have a dump file. see vmcore.201805251422 output above
<cascardo> the one from bionic should work
<lokus> thanks
<cascardo> there is a backport in ppa:cascardo/kdump2
<lokus> nice, i'm in business :) thank you
<cascardo> you are welcome
<cascardo> so, you don't have a compressed dump because you were using an old makedumpfile
<cascardo> the one in that ppa should help with that as well
<cascardo> let me know if you find any problem with those tools
<lokus> cheers.
<cascardo> I hope those packages hit xenial-proposed next week
#ubuntu-kernel 2019-05-20
<arighi> morning
<TJ-> just a heads-up the recent Intel updates may be preventing the kernel from starting at boot: Bug #1829620
<ubot5> bug 1829620 in linux-hwe-edge (Ubuntu) "cryptsetup stuck at loading initramfs" [Undecided,Confirmed] https://launchpad.net/bugs/1829620
<alkisg> Thankfully cryptsetup isn't preinstalled
<TJ-> the report has nothing to do with cryptsetup, I think, just the user reports that since they're expecting to be prompted for LUKS pass-phrase and aren't
<alkisg> AFAIK cryptsetup only gets installed if the users selects "encrypt disk" at ubiquity
<alkisg> Which isn't the default
<alkisg> So if it only affects encrypted setups, we're fine here :P
<TJ-> Nope, this affects unencrypted systems too
<alkisg> Ouch. I'll keep an eye open.
<apw> TJ-, that people seem to be unbroken by removing and reinstalling cryptsetup makes me wonder if it could be an initramfs contents issue
<TJ-> apw: yes, that was my other thought... my next Q in that bug will be "has /boot/ run out of space"
<apw> if it was disco i also had a bug where grub didn't initialise the terminal at all; which was nasty
<TJ-> apw: my reason for thinking Intel microcode is it is added to the early_initramfs isn't it? therefore it could be the cause
<apw> TJ-, entirely possible too yes
<TJ-> We're watching #ubuntu for similar reports, we've had 1 so far
<apw> TJ-, the 'how you get it working again' is going to be key to working out what
<apw> TJ-, or perhaps there is a bug in rebuilding initramfs's when microcode changes; which would account for 'rebuilding my initramfs for another package' fixing it
<TJ-> apw: indeed :) you noticed the additional reporter and colleague in that bug says they aren't using LUKs either, so I guess they got to the bug due to the last messages on-screen being from GRUB
<apw> TJ-, or an ordering bug when getting a new kernel and a package which needs to rebuild initramfs'
<apw> TJ-, which is entirely possible
<TJ-> apw: what is weird is every ubuntu kernel broke
<apw> they all share microcode, they mostly all share 'update ordering issues'
<TJ-> a new kernel would only create the initrd.img for itself, whereas I *guess* a microcode update might apply itself to all initrd.imgs ?
<apw> TJ-, a microcode update likely triggers all initramfs' for all installed kernels to be rebuilt
<apw> to get that microcode included 'in' the initramfs image
<TJ-> indeed, which would explain all Ubuntu kernels having the same problem
<TJ-> apw: confirmed it is the ucode updates 
<apw> TJ-, ugg
<TJ-> disabling loading of the ucode at boot-time solved it, and it appears to be model specific, not packaging
<apw> sigh
<tyhicks> TJ-, apw: unless something has recently changed, an update to intel-microcode only gets injected into the newest initramfs (as well as any future initramfs's)
<tyhicks> sbeattie: ^ note bug #1829620 (you'll likely see the bug mail now that you've been assigned to the bug)
<ubot5> bug 1829620 in linux-hwe-edge (Ubuntu) "intel-microcode on ASUS makes kernel stuck during loading initramfs on bionic-updates, bionic-security" [Undecided,Confirmed] https://launchpad.net/bugs/1829620
<tyhicks> sbeattie: I did test the whole stack of updates, with an encrypted root partition, on an old laptop running Cosmic and Disco (I upgraded the system while we were testing) but didn't see an issue
<tyhicks> that machine is very old but did a corresponding microcode update
<sbeattie> tyhicks: ugh, okay, thanks.
<tyhicks> sbeattie: I don't have a good feeling for what's going on there
<sbeattie> tyhicks: me either, I'm confused by the report that things work with the linux-hwe-edge kernel
<sbeattie> tyhicks: I *think* if I have mapped things properly, the cpuid is 0x000806ea (so microcode 06-8e-0a)
<sbeattie> (but waiting on confirmation on both)
<tyhicks> sbeattie: it would be interesting to know if the updated microcode and kernel (the combo that doesn't boot) can boot with mds=no
<sbeattie> oh yes, that's a good question, too.
<tyhicks> sbeattie: I think that would help us understand if it is a kernel issue (seems unlikely since this isn't a widely reported issue) or something specific to the VERW related changes in the microcode update
<tyhicks> sbeattie: I wasn't very clear... if it boots with mds=no, then it could mean that it is a kernel issue OR an issue with the VERW microcode changes
<tyhicks> (rather than a general microcode issue...)
#ubuntu-kernel 2019-05-21
<alkisg> Hi, we're netbooting over nbd, and a few schools reported that 4.15.0-50 made it very unstable for a few selected clients, so much that they don't finish booting; any related bug reports that I could see if it's what they experience?
<alkisg> Temporarily they reverted to the previous kernel and it's working fine again
<alkisg> Sample screenshot, http://alkisg.mysch.gr/steki/index.php?action=dlattach;topic=7795.0;attach=5066;image
<tomreyn> alkisg: persoanlly, i can't reach alkisg.mysch.gr (194.63.235.156, 2001:648:2302:fc79::22) via grnet-ias-grnet-gw.mx2.ath.gr.geant.net
<alkisg> tomreyn: could you try f5? it had some hiccups a few minutes ago
<tomreyn> should it respond to pings?
<tomreyn> http still times out for me.
<alkisg> pings seem blocked currently; it's the greek school network, they play with it frequently; i'll upload to some other site, moment
<alkisg> https://prnt.sc/nrk3bm
<tomreyn> works. locally, there are no network issues, though, right? since i assume those could cause i/o errors on nbd's, too.
<tomreyn> alkisg: ^
<alkisg> Reverting to .47 works fine, so I don't suspect cabling,
<alkisg> yet the teacher there didn't try a local installation, to see if networking would work there..
#ubuntu-kernel 2019-05-23
<LocutusOfBorg> sforshee, I uploaded a new virtualbox 6.0.8-dfsg-6build1 in the archive... can you please check again?
<sforshee> LocutusOfBorg: sure, when it's done building I'll give it a try
<LocutusOfBorg> sforshee, i386 is already good
<LocutusOfBorg> sforshee, you now have your binaries!
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/virtualbox/6.0.8-dfsg-6build1/+build/16837271/+files/virtualbox-guest-dkms_6.0.8-dfsg-6build1_all.deb
<sforshee> LocutusOfBorg: ack, will test
<sforshee> LocutusOfBorg: that one builds with 5.2, thanks!
<LocutusOfBorg> nice thanks to you
#ubuntu-kernel 2019-05-25
<int3l> hi everyone, does anyone know if the kmodsign tool still works? I tried to sign 3rd party modules with it, but when I try to insmod them, i get error: "... Bad message"
<int3l> I managed to use the Perl script sign-file, but kmodsign is mentioned in the offical Ubuntu documentation
<CarlFK> I want to verify this driver code works with current: https://github.com/shenki/linux/tree/vizzini-4.13    - where should I get current from?  
<CarlFK> I'm following up on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804350#20  "Perhaps you could check whether that works (with Linux 4.3)?"
<ubot5> Debian bug 804350 in wnpp "RFP: vizzini -- Kernel driver for Exar XR21V1414 USB UART" [Wishlist,Open]
#ubuntu-kernel 2019-05-26
<CarlFK> how can I tell what dkms is trying to build?    http://paste.ubuntu.com/p/4JSDG7rxHY/
<alkisg> CarlFK: dkms status
<CarlFK> alkisg: thanks.  
<alkisg> np
