#ubuntu-kernel 2005-04-18
<fabbione> yay
<fabbione> lamont: should we start branching 2.6.12?
<fabbione> i have the orig and a few changes ready for it
<lamont> fabbione: works for me
<lamont> probably should start with --mainline--2.6.10 and branch to --mainline--2.6.12
<fabbione> ok.. what policy do you suggest?
<lamont> policy?
<fabbione> sorry.. s/policy/way to proceed/
<lamont> hrm...
<lamont> baz switch kernel-team@ubuntu.com--2005/kernel-debian--mainline--2.6.10
<lamont> baz branch kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.90
<lamont> and make it 2.6.12_2.6.11.90-1
<lamont> then the actual ship of 2.6.11.90-1 becomes a baz branch  ....--mainline--2.6.11.90
<lamont> and if we get bulky enough to roll another .orig.tar.gz, it becomes 2.6.11.91, etc.
<fabbione> hmm sounds about right
<fabbione> are you going to do it? or should I?
<dilinger> 2.6.11.90?
<fabbione> dilinger: aka 2.6.12rc2
<dilinger> is that a -bk snapshot or something?
<dilinger> ah
<fabbione> just to keep some space before 2.6.12
<dilinger> right
<fabbione> since we are going to switch to gcc4, it is completely pointless to keep working on 2.6.10
<fabbione> much better to get ready with .12
<fabbione> break it early > *
* dilinger nods.  hooray for breaking stuff.
<lamont> fabbione: either way, if you haven't already done it, I'll do it now
<fabbione> no i didn't
<lamont> doing it now
<fabbione> i am fixing the last debian/rules glitches
<lamont> where are we going to put the orig.tar.gz then?
<fabbione> major and wrong assumption is that linux-source-$(pkgnameversion) ($(debversion)) are the same
<fabbione> lamont: i will put it on people as soon as it is ready
<fabbione> that will take like 20 seconds
<fabbione> right now i am working on getting debian/rules to understand that there is a difference
<lamont> right
<fabbione> otherwise there is no way you can even get to edit a patch
* ..[topic/#ubuntu-kernel:lamont] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre35--2.6.10 playground: kernel-debian--pre1--2.6.11.90 | There are no kernel bugs.. only broken hardware | bk is dead
<fabbione> dpkg-deb: building package `linux-image-2.6.12-1-386' in `../linux-image-2.6.12-1-386_2.6.11.90-1_i386.deb'.
<fabbione> and no..
<fabbione> it's not .12rc2 yet
<fabbione> just fixing the debian/rules insanity adding more mess
<T-Bone> ola!
<T-Bone> fabbione : ping?
<fabbione> hi T-Bone 
<T-Bone> howdy!
<fabbione> pretty busy
<T-Bone> fabbione : ok, might discuss that later then. Just wanted to let you nkow in case you haven't noticed we've had some discuss with dholbach and lamont yesterday about universe kernel images
<fabbione> T-Bone: no, i haven't read the scrollback
<fabbione> and i need to do something for the next hour or so
<T-Bone> ok np
<fabbione> bbl
<T-Bone> fabbione : btw, i got my hands on a bunch of sparc and ultrasparc systems, i might give a shot at Ubuntu sparc this week end (and maybe provide build power if needed :)
<T-Bone> fabbione : you see, i don't hate you 8)
<fabbione> T-Bone: there is no way to install sparc atm. sparc.u.c is out of sync (but not due to the buildd). i will explain later
<fabbione> i have to run
<dholbach> bye fabbione 
* Lathiat has several sparcs also
* T-Bone watches hppa getting even closer to 94% up-to-date, curses kde-poopie for screwing 1 or 2 more %
<fabbione> re
<T-Bone> re
* T-Bone is reading the lengthy article on kerneltrap aboug RCM in Linux
<fabbione> the problem with sparc are multiple
<T-Bone> shot
<T-Bone> +o
<fabbione> one I need to able to give you access to w-b
<fabbione> or move w-b somewhere that all can access
<Lathiat> w-b?
<T-Bone> if you want me to participate to the build effort, yeah
<fabbione> my sparc is special cased.
<Mithrandir> does sparc have trouble keeping up?
<fabbione> it's the only external buildd allowed to upload binaries
<fabbione> Mithrandir: not for main
<T-Bone> i have a Ultra30, a SS20 and potentially a U5
<fabbione> but for breezy we will need more than one.. that's for sure
<T-Bone> maybe more will come up in the next few days
<fabbione> the major issue would be to sign the packages and upload them to archive
<fabbione> since none of you is allowed to
<Mithrandir> I have two U5s I could use.
<T-Bone> ?
<T-Bone> fabbione I am
<Mithrandir> T-Bone: no, not binaries.
<fabbione> T-Bone: you are not allowed to upload binaries
<fabbione> only sources
<T-Bone> Mithrandir : i have a key that is
<T-Bone> s/is/will be soon/
<T-Bone> for hppa binaries
<fabbione> the sparcbuildd has a specially blessed for sparc
<fabbione> T-Bone: yes.. and only hppa
<Mithrandir> fabbione: didn't Mark say we would buy buildds for arches which were maintained properly?
<fabbione> Mithrandir: that's where i was going now
<fabbione> Mark already agreed on buying sparc buildd's
<T-Bone> fabbione : then if i can do hppa, i guess it's a matter of turning the right knob to do sparc as well :)
<fabbione> given that there is enough community interest
<fabbione> so my plan was to get sparc announced immediatly after hoary
<T-Bone> fabbione : tell him to sell ia64 ones and buy sparc/hppa instead ;] 
* T-Bone ducks swiftly!
<fabbione> *no comments*
<T-Bone> fabbione : amusingly enough, lamont and I plan to do the same for hppa :}
<fabbione> if there will be enough hits on sparc.u.c 
<fabbione> than i will ask Mark to give the final green light for the buildds
<Mithrandir> fabbione: so we should set up a box to continously reinstall and upgrade and stuff?
<fabbione> Mithrandir: that would be perfect
<fabbione> d-i has received only my love
<fabbione> and it works here
<fabbione> but i have no idea if X does for example
<fabbione> since my machine is headless
<Lathiat> i have a monitor for mine
<Lathiat> and i can steal a keyboard from the UCC
<T-Bone> fabbione : if you need help to build hoary's universe, i can probably do something quite similar to what I've done for hppa: build all binaries, make them available for you somewhere and let you do the bad upload thing...
<fabbione> Lathiat: problem is (as i wrote before) that sparc can't be installed atm
<Lathiat> right
<Lathiat> why is that?
<T-Bone> fabbione : please explain that, you told me the installer was working...
<fabbione> T-Bone: there is very little point in doing it
<fabbione> yeah the problem is that the server where sparc.u.c is hosted
<fabbione> is too overloaded
<T-Bone> fabbione : your call. I'm offering CPU power that's all ;)
<Mithrandir> fabbione: you host sparc.u.c home?
<Lathiat> perhaps that can be rectified
<fabbione> and basically the sparc packages are built, uploaded but not integrated into that archive
<Mithrandir> s/home/at &/?
<fabbione> Mithrandir: no. it's at the DC
<fabbione> T-Bone: there is more than that. Once sparc is approved, lamont will have to rebootstrap it from scratch anyway
<fabbione> T-Bone: like for hppa
<T-Bone> ?
<fabbione> simply because all the binaries must come from the DC
<fabbione> it's a rule dude...
<T-Bone> a stupid one
<Lathiat> i disagree
<fabbione> both of you can disagree as much as i did
<Lathiat> (i mean i disagree that its a stupid rule)
<fabbione> Lathiat: ah ok
<T-Bone> i know why it's there
<Mithrandir> *shrug*, it's a rule and we play by it.  It's not like it really matters much anyhow.
<T-Bone> there are other ways to achieve what's intended
<T-Bone> thus a stupid rule. My call.
<fabbione> Mithrandir: well it does to a certain degree
<fabbione> T-Bone: and what is intended?
<T-Bone> fabbione : security
<T-Bone> i suppose
<fabbione> that is only one of them.
<Mithrandir> fabbione: it matters somewhat security and buildability-wise, but it doesn't matter for the port per se.
<Mithrandir> it's just a rebuild.
<T-Bone> the other being buildd system not being exportable yet
<T-Bone> fabbione : that might cahgne at some point
<fabbione> Mithrandir: our buildd's compile with different options
<T-Bone> lamont had a hope for that, given how we plan to deal with hppa
<fabbione> T-Bone: whatever.. until that part is not exported, we need to play by the rule
<fabbione> so the rebuild is mandatoru
<fabbione> mandatory
<T-Bone> fabbione : maybe you shouldn't try too hard for now then
<T-Bone> fabbione : lamont told me he had good hope to get it changed *soon*
<fabbione> T-Bone: eh? 
<T-Bone> given i host 99% of the hppa build power...
<T-Bone> and given lamont's attachment to hppa ;)
<fabbione> T-Bone: well.. when it will change we will take appropriate actions.. right now i am happy as it is
<fabbione> also
<fabbione> a rebuild at the DC is way faster than what you do at home/uni
<T-Bone> ?
<fabbione> so if they decide to rebuild sparc i am not going to say no..
<fabbione> i simply can't care less :)
<fabbione> T-Bone: i have one sparc one cpu
<Mithrandir> T-Bone: the buildds at the data centre are way faster than any U5s we can muster
<T-Bone> fabbione : ah sure. I was talking about hppa there :)
<fabbione> if Mark buys the buildd there will be at least 4 boxes with 8 CPU, GIGS of RAM and tons of disks
<T-Bone> yum ;] 
<T-Bone> though
<fabbione> so basically.. rebuilding a port is a breeze
<T-Bone> what's the point of 8CPU when the autobuilder does single threaded build?
<T-Bone> unless... yours do multithreaded ones... :P
<Mithrandir> it can run 8 sbuilds
<fabbione> T-Bone: sbuild can fork....
* T-Bone sighs
<fabbione> T-Bone: time to RTFM?
<T-Bone> fabbione : i'm sorry, default setup can't simply fork
<T-Bone> for you need several chroots to do that
<fabbione> T-Bone: yes it can :)
<T-Bone> and it's quite a pain to setup
<fabbione> and no.. you don't need more than one chroot
<T-Bone> oh? And how do you manage builddeps?
<fabbione> afaik it doesn't attempt to build packages with build-dep in conflicts
<T-Bone> that's not the point
<fabbione> what is the point than?
<T-Bone> you have package A with set a of build deps, package B with set b
<T-Bone> you build both packages at the same time
<fabbione> yes
<T-Bone> if package A uses some in set b without declaring it, it'll build fine anyway
<T-Bone> and that's the least of the worst examplse i can come with
<fabbione> the cases that something like this will happen is very low
<T-Bone> i think such an example would already be enough to make lamont go nuts
<T-Bone> fabbione : this breaks the whole point of sbuild/chroots
<T-Bone> which is: build package in an isolated environment with the exact set of build-deps they need
<fabbione> T-Bone: see.. that's why you don't fork always
<T-Bone> that's why you *never* fork
<T-Bone> that's why RTFM won't help. Such a feature, if existing, shouldn't be used :P
<fabbione> T-Bone: wrong
<Mithrandir> T-Bone: sbuild isn't a tool for checking build-deps, pbuilder is.
<T-Bone> Mithrandir : builders don't use pbuilder
<fabbione> T-Bone: so?
<T-Bone> Mithrandir : we're talking about buildd/sbuild setup here
<Mithrandir> T-Bone: I know, but the buildds are there to build packages, not catch all kinds of random errors.
<fabbione> give me a reference in Debian policy that says that buildd should be used to verify Build-Dep
<fabbione> and i will agree with you
<T-Bone> anyway, you have your views and i have mines, and unless lamont tells me i'm wrong i wont change my mind, for i'm French and stupid (which is the same, heh? :)
<T-Bone> Mithrandir wrong
<Mithrandir> T-Bone: reference?
<T-Bone> fabbione : if it wasn't the case, we would use sources-dependencies on ubuntu, and we don't
<fabbione> T-Bone: well if you don't even bother to see other people truth.. just wait for lamont next time
<fabbione> source-dependecies?
<T-Bone> fabbione : lamont made it very clear that we want to *fix* invalid sourcedeps, not *workaround* them
<fabbione> ok i am not going to discuss this anylonger
<T-Bone> neither do i
<T-Bone> i take my info from the guy running the buildds, i think that's authoritative enough :P
<T-Bone> so back to topic, i can offer sparc cpu, and maybe some help to the extent of my limited time.
<fabbione> ok thanks
<fabbione> i will keep that in mind
<fabbione> i want to see input from the community before start building a big sparc infrastructure
<T-Bone> certainly the best thing to do
<Mithrandir> are newer sparcs quieter than the old ones?
* Lathiat laughs
<T-Bone> fabbione : on a different topic, i've been reading the posts about patches on the k-t m-l, why would we move away from dpatch?
<fabbione> because it's hutter crap
<T-Bone> huh?
<T-Bone> can you illustrate?
<fabbione> dpatch is ok when you handle one source/one build
<fabbione> in our situation where we might need to start building different sets of packages with different patches, is a royal pain in the ass
<T-Bone> ah
<T-Bone> i thought we aimed at building all kernels from the same source?
<fabbione> yes we do
<T-Bone> of course if it's no longer the case i understand dpatch is a mess
<fabbione> but not all kernels get the same set of patches.. like *cough*hppa*cough*
<T-Bone> that should be fixed in breezy
<fabbione> and when i started working on xen packages
<T-Bone> s/should/will/
<Mithrandir> dpatch could fairly easily be extended to use a arch-specific list of patchs if that exists.
<fabbione> i realized how bad it is to add per image patches
<fabbione> Mithrandir: it does already, but not like we need it
<fabbione> Mithrandir: that would require more work from us
<T-Bone> and it would break "one source to rule them all", if i get it right
<fabbione> T-Bone: no.. it won't break that, but it gets messy to maintain afterwards
<fabbione> T-Bone: just checkout the experimental branch i did for xen
<fabbione> and look at it
<fabbione> you will understand yourself what i mean
<T-Bone> fabbione : err, so you consider that building different kernels with different patchsets doesn't break "build all on the same source" ?
<T-Bone> ok will do
<fabbione> we need to redesign the build system from scratch in a more neat way
<T-Bone> like, *again*? ;o)
<fabbione> T-Bone: no. because you grab one source and build everything out of it
<fabbione> T-Bone: it is still the same source
<T-Bone> fabbione : ah ok. My understanding was that we wanted all kernels to be exactly the same
<fabbione> T-Bone: that is not possible due to kernel upstream
<fabbione> if i had to apply to your concept, hppa wouldn't exist
<fabbione> so better you accept my view of it :)
<T-Bone> fabbione : well, not really: take for example the hppa mess, if you build everything but hppa on the current package set, then add the hppa patches to build hppa images, hppa kernels have several *major* changes in them
<T-Bone> fabbione : yeah you're right ;)
<fabbione> T-Bone: that's because hppa is not fully merged upstream
<T-Bone> fabbione : my understanding is that we would only work on fully merged architectures :)
<fabbione> baz rm debian/*/hppa/*
<T-Bone> but i can see this is wrong in the long run
<fabbione> ah shit.. wring window
<T-Bone> lol
<T-Bone> fabbione : our current patchset to upstream is <200k now
<T-Bone> uncompressed
<fabbione> T-Bone: no.. the issue of having one source is for security related reasons
<T-Bone> fabbione : yeah i got that as well
<fabbione> one upload will trigger the rebuild everywhere
<fabbione> it is just to be more practical
<T-Bone> fabbione : but then, if we differentiate patches accross kernel builds, it's gonna be quite painful to track this, no?
<T-Bone> s/this/security changes/
<fabbione> T-Bone: can you please checkout the branch, look at it and read again what i said?
<fabbione> security changes go in for everybody
<T-Bone> i'd love to, i'm at work atm... :P
<fabbione> if there is a security patch specifically for hppa
<fabbione> it is not my business to get it in...
<fabbione> there are porters for a reason
<T-Bone> eww
<fabbione> that should take care of it
<T-Bone> nogood
<fabbione> + usually security fixes are upstream the same day
<fabbione> so
<fabbione> i don't really see this problem you are trying to create
<T-Bone> if there isn't one guy knowning everything about security fixes, this is likely to cause issues in the long run
<fabbione> really.. this is not a problem
<T-Bone> right
<T-Bone> agreed
<T-Bone> my idea was that some arch-specific patches might introduce security issues. But then again it's a porter's issue
<fabbione> exactly
<fabbione> plus..
<fabbione> our kernel is already doomed in that direction
<T-Bone> and i bet that with an efficient patching system in the kernel build, this should be easy to track down :)
<T-Bone> so yes, let's have such an efficient patching machine :)
<fabbione> already the fact that we apply an external patch for an i386 driver, it will make the i386 kenrel different from the others
<T-Bone> right
<fabbione> introducing a security problem for i386
<T-Bone> so we don't mind this. Ok, i'll keep that in mind
<fabbione> so it's take or leave it basically :)
<T-Bone> indeed
<dilinger> anyone particularly good w/ sparc asm?
<T-Bone> i was really confused by what i thought was an attempt to build all kernels from the exact same bits ;)
* T-Bone needs to wander off for food for a while, bbiah
<fabbione> dilinger: meh.. no
<fabbione> and i need to grab some food...
<fabbione> bbl
<dholbach> what shall i do about the broken powerpc-kernel-2.4?
<dholbach> if we don't have any alternative, i'll ask elmo to remove it from the archive
<dholbach> please note: i feel *very* uncomfortable with kernel issues/decisions in universe :-/
<Mithrandir> did we end up with a kernel that supports i2o stuff on amd64 now?
<T-Bone> dholbach : i think this hasn't been discussed enough, unfortunately
<T-Bone> (re kernel in universe issues)
<dholbach> we should discuss it in the next TB meeting
<T-Bone> hmm, i thought there was none before hoary releases?
<fabbione> Mithrandir: we did add it a while ago
<dholbach> yes... but i'm not sure if we can have a complete consensus in the next 15 hours
<Mithrandir> fabbione: hm, ok.  So it should be in the d-i images?
<fabbione> dholbach: remove it
<dholbach> fabbione: thanks
<fabbione> Mithrandir: yes. in the scsi udeb
<T-Bone> fabbione : what about all other images then?
<fabbione> T-Bone: they will stay
<T-Bone> fabbione : what for?
<fabbione> T-Bone: read the backlogs in the channel
<T-Bone> fabbione : is that the "some users need them" argument?
<T-Bone> fabbione : why should i do that when you don't do it yourself, btw?
* T-Bone has no handy backlog, being at work as he is
<fabbione> T-Bone: because it has been discussed to death, and for once that i didn't read the backlog yet, you are making a tragedy
<T-Bone> i'm not
<fabbione> T-Bone: people.ubuntu.com/~fabbione/irclogs/
<T-Bone> yeah looking there right now
<fabbione> <T-Bone> fabbione : why should i do that when you don't do it yourself, btw?
<T-Bone> could you just point me a the right date please?
<fabbione> T-Bone: it has been discussed 2/3 times.. i can't remember the date
<T-Bone> fabbione : if you happen to find yourself some time to read yesterdays backlog, you'll notice signficant concern has been raised, not only by me, for a change
<T-Bone> one of the biggest being "these kernel are in the hands of MOTUs, and won't be supported"
<T-Bone> anyway, i guess i'm lacking crucial elements, reading the logs
<fabbione> T-Bone: at what time you and lamont had the talk?
<T-Bone> fabbione : just a 2cents btw, when such a decision is made, it'd be nice to state it on k-t, so that everyone involved is aware of it. Not everybody can follow irc, you see...
<fabbione> was i here in logged in the chan?
<fabbione> T-Bone: clearly you miss 2 points here
<fabbione> 1) kernel-packages -> universe
<fabbione> 2) MOTU's are searching advice
<fabbione> i expressed my wishes
<fabbione> motivating them
<T-Bone> at the time your logger was mostly offline. I only see the end of the discussion at 8:16 in april 06's log
<fabbione> i don't rule MOTU's decisions
<fabbione> and universe is not kernel-team problem
<T-Bone> fabbione : your "wishes" are blessed as god's decision, in case you haven't noticed
<dholbach> and i'm glad you're giving us the advices, it's just i'm not clever enough to judge
<fabbione> T-Bone: yes, i was offline, together with ubuntulog
<fabbione> T-Bone: i am not god..
<fabbione> i never stated to be.. probably joking...
<fabbione> but that's it
<T-Bone> i expressed my wishes, have been significantly backed up by lamont and kyle, dholbach agreed to some of my concerns, yet *you* rule... (not that i'm bitter) :P
<fabbione> ok if everybody has agreed to kill 2.4
<fabbione> go ahead
<dholbach> i will gladly put in universe what people want and what works
<fabbione> it's fine with me
<fabbione> dholbach: kill them
<dholbach> NO
<fabbione> KILL THEM ALL!
<fabbione> KILL THEM ALL!
<fabbione> KILL THEM ALL!
<dholbach> that's not what i said
<dholbach> !
<T-Bone> fabbione : look at 08:45
<fabbione> YEAH BURN THEM IN THE FLAMES OF HELL!
<dholbach> fabbione: calm down :-)
<fabbione> dholbach: i am kidding man :)))
<dholbach> i know :-)
<T-Bone> fabbione : actually you may have the most interesting part in the logs, between 08:22 and 08:45
<dholbach> it's just: i feel VERY uneasy about judging kernel stuff
<fabbione> T-Bone: yes i read that bit, and still users can't claim support from us, if the packages are in universe
<dholbach> i hope our MOTU team will grow soon and much cleverer people can work on that
<T-Bone> fabbione : my point is that 1) i see no reason of keeping these in universe (on the ground of point 08:45) and 2) they will confuse our users (same grounds) and 3) if we don't need them let's remove them. Including 2.6 btw
<fabbione> dholbach: once we kill 2.4 there will be almost nothing left of kernel stuff in universe
<T-Bone> now i'm really open to suggestions, it's just bad that question rises 24h before the release
<fabbione> T-Bone: i told dholbach to kill 2.6 the same morning
<dholbach> MorgueCandidates is what elmo is processing atm
<T-Bone> fabbione : well, then we all agree, what the fuck are we fighting for then? ;o))
* T-Bone cheers fabbione ;)
<fabbione> T-Bone: my point one and simple. some users (like me btw) can't run 2.6 everywhere
<fabbione> leaving a couple of packages in universe might be handy for the user
<T-Bone> fabbione : i tend to think that kind of user will build their own kernel anyway
<fabbione> and give him time to evaluate transition to 2.6
<fabbione> T-Bone: not really
<Lathiat> T-Bone: alot of people don't anymore
<T-Bone> fabbione : in that view, leaving just source is enough, my guess
<fabbione> T-Bone: that's a bad assumption
<T-Bone> fabbione : ok describe why youo can't run 2.6?
<fabbione> T-Bone: yes, but in out archive there cannot be source without binary afaik
<T-Bone> ah
<dholbach> i agree: keeping the images might be handy
<T-Bone> sure that's a problem :P
<fabbione> T-Bone: lvm/lvm2 issues
<T-Bone> dholbach : this is a *bad* idea for the reason i explained yesterday...
<T-Bone> fabbione : that's a server issue, right?
<T-Bone> fabbione : on servers, usually you want fine tuned kernels, don't you?
<fabbione> T-Bone: yes, that is my specific problem
<fabbione> T-Bone: you are assuming again
<fabbione> look at RH
<T-Bone> fabbione : in every company i've been working at, as well as univ, on sensitive servers, home brewed kernels are being run
<fabbione> if you touch the kernel, they don't provide support anymore
<T-Bone> fabbione : ok you got a point. Yet we're not RH :)
<fabbione> T-Bone: i didn't run home made kernels at work
<fabbione> i couldnt
<T-Bone> fabbione : that's irrelevant for us (support): we don't support universe anyway...
<fabbione> T-Bone: i really don't understand why you need to assume what people wants
<fabbione> i have a tech issue upgrading to 2.6
<fabbione> other people might have to
<T-Bone> i'm not assuming. I'm hypothetising
<fabbione> <T-Bone> fabbione : on servers, usually you want fine tuned kernels, don't you?
<fabbione> mp
<fabbione> n
<fabbione> NO
<fabbione> i don't
<fabbione> i just need a kernel that works
<T-Bone> fabbione : so instead of having users use their home brewd kernels, you want to let them use untested, unreviewed, unsupported kernels randomly built (and not security updated) by the buildds?
<fabbione> and 2.6 doesn't on my machine
<fabbione> (sorry for the CAPS)
<fabbione> T-Bone: dude.. do you realize that 99% of the people outthere don't even know what the kernel is?
<T-Bone> fabbione : excuse me if i'm rude, but asking for something for our users based on *your* needs looks much like an assumption to me, if not worse :P
<T-Bone> fabbione : hell yes. those should be running supported kernels
<T-Bone> fabbione : if they can't, either they have very specific hardware, and know what kernel is (otherwise they're fucked up), or we have a problem with our kernel, and shuold fix it. Don't you agree?
<fabbione> T-Bone: dude.. you clearly 1) can't get a general picture 2) keep indicating me as the only one in this world, given that i explained to you that i have one specific problem, likewise other people do
<fabbione> T-Bone: you are making assumptions again. Having specific hw doesn't give you kernel knowledge and viceversa
<fabbione> and this discussion is not going anywhere
<dholbach> i want to end the discussion for me and state: 1) it's ok for me to include something, somebody else needs and has tested 2) i just have to trust, since i'm not clever enough
<T-Bone> fabbione : you have answered none of my two arguments: 1) the un-everything-ness of the universe kernels, 2) our need of supporting our users
<fabbione> dholbach: kill all kernel from universe please
<fabbione> T-Bone: you keep asking nonsence questions.. therefor you get no answers
<T-Bone> fabbione : how comes lamont and kyle both understood my concerns and answered them then?
<dholbach> fabbione: honestly: i'll keep it and have NO problem with that
<T-Bone> fabbione : do we have an italian/french communication issue? Please send me some wine! :)
<fabbione> dholbach: the kernel-team has agreed on killing them and it is fine by me
<dholbach> fabbione: elmo is just killing a HUGE amount of packages - i will have a look at what's left later, ok?
<fabbione> T-Bone: i did write some reasons why we can keep unsupported kernels in universe. tho you didn't get them trying to circunventing them with other arguments.
<T-Bone> fabbione : i'm not cicumventing, really not.
<T-Bone> +r
<fabbione> dholbach: if something is left, please kill it
<T-Bone> at least this is not my goal
<T-Bone> i'm really trying to either understand your point or try to make you understand mine, so that we can reach an agreement. Which is the base of "discussion", as Socrates means it ;] 
<fabbione> dude.. i understand your point to a certain degree
<fabbione> packages in universe have NO support
<T-Bone> that's it
<fabbione> so what is your problem to have a 2.4 source/binary around to help transitions and users like me?
<T-Bone> and i should add: if a user can install his box with install cds, he *shouldn't* (in the best and ideal case) need the other kernels
<T-Bone> fabbione : because how are you going to manage to have these users upgrade?
<fabbione> T-Bone: you are assuming that people always install from scratch :)
<T-Bone> fabbione : i'm assuming that those who don't know what they do (and they'd really better do :)
<fabbione> i have my server running on experimental for almost 5 years now
<T-Bone> fabbione : of course, but that kind of attitude isn't Mr Foo's one... :)
<fabbione> T-Bone: we do support upgrades from woody.. you know that, don't you?
<T-Bone> and you were telling me about users who don't know what kernel is. These don't run experimental, i hope
<T-Bone> i do
<T-Bone> i'm just wondering:
<T-Bone> if someone keeps using a debian kernel on ubuntu,
<T-Bone> when/how will s/he move to the Ubuntu supported kernel?
<fabbione> IF (and i am assuming now)
<T-Bone> have we tested such a transition?
<fabbione> i was an almost clueless user
<fabbione> T-Bone: yes i did test it with warty
<fabbione> first i would have upgraded to warty/hoary
<fabbione> and see what was there
<T-Bone> fabbione : dude, is your testing really enough to make sure it works? we're talking about corner case users who can't run stock kernel off hands, right? :P
<fabbione> noticing the 2 or more new entry in the boot menu
<T-Bone> go ahead
<fabbione> i would have ask for help/suggestion or something
<fabbione> (note i am considering the average luser here)
<T-Bone> ("average user" is such an interesting concept ;] )
<fabbione> and i would have been told: hey dude.. test 2.6.. if it doesn't work file a bug and keep using 2.4
<dholbach> ok, here goes MOTU decision: people who want to have such a 2.4-kernel will have to 1) enable universe, 2) know what a kernel is - i assume at that stage they know how to select the 2.6 kernel in lilo to get everything back -- we trimmed the source package count down to 5-6 kernel source packages (patches, images) in universe and i feel comfortable, if they make 1-2 users on the planet happy
<T-Bone> fabbione : and please tell *where* in your process are universe kernels needed?
<T-Bone> fabbione : upgrading means you can keep the debian one
<T-Bone> fabbione : it will show in "orphaned/removed" in aptitude,
<T-Bone> which is a *very good hint* the user should try to move away
<dholbach> i think our user-base is too diverse to make general decisions
<fabbione> that is exactly why you don't want them to disappear
<fabbione> if they purge them by miskate
<fabbione> and the new kernel doesn't work for them
<fabbione> bam
<fabbione> you are doomed with a user: "Hey ubuntu destroyed my machine"
<dholbach> with packages like kudzu on the loose, a 2.4 kernel doesnt hurt
<T-Bone> i think they do, but i know some may think otherwise and ack it
<fabbione> T-Bone: exactly.. someone might notice.. others won't
<fabbione> we don't know
<T-Bone> fabbione : i must confess not knowing aptitude enough to figure out how easy it is to purge something by mistake
* dholbach passes some tea and cookies to everyone
<fabbione> T-Bone: i think synaptic has it by default...
<fabbione> dholbach: thanks for the info :)
<T-Bone> fabbione : purging orphaned package??!
<fabbione> dholbach: btw.. for breezy we can kill the rest..
<dholbach> fabbione: i feel comfortable with that
<fabbione> T-Bone: i have no clue really.. i still play dpkg -i
<T-Bone> fabbione, dholbach : please confirm that all 2.6 kernels are removed from universe (i want to make that clear)
<dholbach> T-Bone: elmo is processing the list
<fabbione> T-Bone: but when i dist-upgraded from warty i THINK  i saw a bunch of purges
<dholbach> T-Bone: i will confirm after that
<T-Bone> fabbione : i really doubt that's the case. Truth told, I think your example doesn't hold ;)
<T-Bone> fabbione : wow, that'd be very new to me, and a good thing to know :P
<dholbach> do you think we can discuss the academic arguments in the breezy release cycle?
<fabbione> T-Bone: houneslty... i used synaptic 2 times in my life
<T-Bone> fabbione : i use apt-get ;)
<fabbione> dholbach: i don't think there will be any need
<T-Bone> dholbach : that would certainly be a better time i guess
<Mithrandir> oh fun.
<Mithrandir> 14:15 < Ueland> error: unknown bus, please report to
<Mithrandir>                 <linux-hotplug-devel@lists.sourceforge.net> 'i2o'
<T-Bone> as fabbione said though
* Mithrandir kicks hotplug in the head
<fabbione> our libc6 will not support 2.4
<T-Bone> lol
<T-Bone> fabbione :so how are you going to help users transitionning, dude? ;o)
<fabbione> so the users had 1 year / 2 releases to upgrade
<fabbione> or learn how to build their kernels
<T-Bone> or trash their buggy hardware ;)
<fabbione> seriously.. it's not only question of hw :(
<fabbione> i did a mistake creating my lvm/raid setup 5 years ago
<fabbione> inexperience mainly
<T-Bone> ah... shit happens :P
<fabbione> and i landed with something i can't move to 2.6 easily, due to the requirements i have from the server
<T-Bone> what kind of mistake, so that i know how to avoid it? :)
<fabbione> T-Bone: yeah...
<dholbach> http://people.ubuntu.com/~james/paste/001.txt
<fabbione> T-Bone: now you cannot make it anymore
<fabbione> since they changed the default for vgcreate
<T-Bone> dholbach : all these should be killed
<T-Bone> straight and hard
<dholbach> any ++ from anybody else?
<T-Bone> i can detail why if needed
<T-Bone> dholbach : do you want me to argument? :)
<dholbach> no, but if 2 of you say: go, kill, it's ok for me :-)
<T-Bone> boot-floppies was used on woody (the installer): pointless.
<T-Bone> i rule ia64, i say linux-kernel-di-ia64 must die ;)
<T-Bone> and the others are a bunch of deprecated packages not used anymore
<dholbach> ok, they go
<T-Bone> they are all supplementary to some (arch-specific) 2.4 packages
<T-Bone> (mostly i386, afaict)
<T-Bone> given we just agreed to kill those... ;] 
* T-Bone ducks
<fabbione> dholbach: i finished the review of the 2 packages
<fabbione> meh 3
<dholbach> fabbione: added a note to MOTUNewPackages?
<fabbione> dholbach: yes
<dholbach> fabbione: thank you so much!
<fabbione> no problem
<T-Bone> btw, to those of you interested in the recent RCM issues in linux kernel community, here's an interesting article: http://kerneltrap.org/node/4966
<fabbione> T-Bone: 2 days old news kid :)
<T-Bone> fabbione :depends on your TZ
<T-Bone> fabbione : but yeah, sorta :)
<fabbione> T-Bone: we are in the same TZ
<T-Bone> well it's 1 day and 14h old then ;)
* T-Bone ducks
<dholbach> http://people.ubuntu.com/~james/paste/002.txt
<zul> hey
<dholbach> hey zul
<zul> whats up?
<fabbione> hey zul
<dholbach> opinions on: http://people.ubuntu.com/~james/paste/002.txt and http://people.ubuntu.com/~james/paste/003.txt
<dholbach> elmo is just _trying_ to remove stuff from universe
<dholbach> and i'll need your input
<zul> just reading the backlog now
<T-Bone> dholbach : i don't know these. My guess is they need to be reworked to work with our kernel system. and linux-kernel-di-i386 can be removed
<T-Bone> dholbach : they won't probably work without some love, so maybe they're best removed?
<T-Bone> as of xen, you want to ask fabbione 8)
<zul> ah...i see fabbione hasnt taken his pills today
<zul> 	fabbione	KILL THEM ALL!
<zul> 01:50	fabbione	KILL THEM ALL!
<zul> 01:50	fabbione	KILL THEM ALL!
<zul> 01:50	dholbach	that's not what i said
<T-Bone> zul : LOL ;)
<dholbach> other views?
<zul> still reading
* T-Bone curses more broken packages :P
<zul> i have to read with like moving my mouth
<dholbach> zul: try it... if it works better... :-)
<lamont> T-Bone: don't confuse my answers with agreeing with you.
<lamont> the kernel isn't special
<fabbione> linux-source-2.6.12 (2.6.11.90-1) breezy; urgency=low
<fabbione>   * New upstream release (based on 2.6.12rc2):
<fabbione>     - Update debian/control.stub.
<fabbione>     - Modify debian/rules in several sections to cope with a version different
<fabbione>       from the one specified in the package name.
<fabbione>     - Add empty ChangeLog-2.6.11.90.
<fabbione>     - Remove ChangeLog-2.6.10.
<fabbione>     - Clean up debian/patches/00list*. 00list-1{,.hppa} are pristine copies 
<T-Bone> lamont : i didn't say you agreed, did i? I said you understood
<fabbione>       from the previous release.
<fabbione> this is the first cut
<zul> sweetness i can start working again ;)
<fabbione> zul: not yet.. i will need a few more commits and to publish the orig for you to start working
<T-Bone> lamont : FYI, we're getting very close to 94% ;)
<zul> For the universe stuff couldnt we just leave the kernel-source for 2.4 and say to the user if it doesnt work compile it yourself (as a compromise)
<T-Bone> zul : you haven't read backlog hard enough :P
<dholbach> what about the lists (http://people.ubuntu.com/~james/paste/002.txt and http://people.ubuntu.com/~james/paste/003.txt)?
<zul> T-Bone: meh...i just got up like an hour ago
* T-Bone whacks zul to wake him up better ;] 
<zul> T-Bone: i see where you are coming from and i see where fabbione is coming from im just trying to think of a compromise
<T-Bone> zul : i already mentioned that compromise and it can't be done: fabbione explained we can't distribute source without binaries
<zul> heh...this can obviously be killed linux-kernel-di-i386/universe
<zul> okie dokies 
<T-Bone> zul : anyway, please don't interfere with the agreement fabbione and i have reached 8))
* T-Bone hides!
<lamont> zul: that's what we do for universe right now
<dholbach> killed cpqarrayd, gfs-kernel and gnbd-kernel as well
* zul smacks T-Bone 
* T-Bone dodges
<fabbione> gfs?
<T-Bone> http://buildd.slashdirt.org/logs/mkhppa3/lkcdutils_6.0.0-2_20050407-0834 <- i love this one
* zul kicks T-Bone between the legs
<fabbione> what version is that?
* T-Bone dodges and counters this time ;)
<fabbione> well nevermind.. i can grab it from debian
<fabbione> if it is global filesystem from rh, we want it
<T-Bone> "mkdir: cannot create directory `/home/micah': Permission denied"
<T-Bone> that DD must have been on *very hard crack*
<fabbione> i am preparing the orig now zul...
<fabbione> it might take sometime before it's up
<zul> fabbione: no probs im at work so i havent to concentrate on work stuff today..how am i dong so far? ;)
<T-Bone> syntax error in zul's statement all over the place ;] 
<zul> i havent loaded the punctunation module yet..
<zul> need...to...wake..up
* T-Bone buttkicks zul
<T-Bone> zul : HOW'S THE HEAD? 8)
<zul> fine...but still not awake..
<zul> oh my team made the finals of the league im in
<T-Bone> zul : that had to happen when you were asleep, right? 8)
<zul> nope...the other team didnt show up
<T-Bone> lol
<T-Bone> erm, joining #u-motu right now isn't very easy :(
<T-Bone> oops
<T-Bone> wrong window
<zul> heh...do you need a tutorial on how to use irc?
<T-Bone> zul : no. But i'd make good use of a tutorial on how to properly kick your nuts 8)
<zul> just make sure you hit them fair and true
<T-Bone> oh i will, believe me 8)
<zul> fabbione: just let me know when they are up
<T-Bone> you sick-psycho ;)
<zul> you sick perv :)
<fabbione> zul: yeah, i am cleaning up the last bits
<zul> what does your gf have to say about that
<T-Bone> my last gf said i was a perv, but she found it nice and normal, seemingly 8)
<zul> T-Bone: last no current?
<T-Bone> i don't have a regular current one. I'm not an old married geezer you see? ;)
<zul> ah...just bring it out im making my shitlist today :)
<T-Bone> tssks
<fabbione> fabbione@gordian:/usr/src/wartydevel/kernel/crack$ scp linux-source-2.6.12_2.6.11.90* rookery.warthogs.hbd.com:public_html/.
<fabbione> it's on the way
<fabbione> zul: do you know what is the next step?
<fabbione> no i will tell ya :)
<fabbione> you are too sleepy :)
<zul> gee would it be this linux-source-2.6.12_2.6.11.90-1.diff.gz 
<fabbione> nah it's copying diff.gz, dsc and orig
<fabbione> you will need them together with the debian/ from baz
<zul> ok cool
<zul> ill try it this afternoon dpending on how this goes here
<fabbione> if you don't want to end up spending another day trying to understand why a make clean will wipe debian/
<fabbione> zul: and don't run a make clean..
<zul> k
<fabbione> there is more stuff that needs to be done before that
<zul> ls
<zul> bah
<fabbione> yeah right :)
<fabbione> ok.. the orig & co are on people.u.c/~fabbione/
<fabbione> REMEMBER NOT TO USE THE CLEAN TARGET
<zul> sweet..
<zul> yep..
<fabbione> next step is:
<fabbione> disable all the patches from 00list-1
<fabbione> and slowly start checking one at a time
<fabbione> some of them are upstream
<fabbione> and needs to be killed
<fabbione> other updated
<fabbione> other rediffed
<fabbione> now.. i suggest that you kill all the known patches that come from documented external drivers
<fabbione> they are all mostlikely obsoleted
<fabbione> that will reduce the number of a few zillions
<zul> heh
<fabbione> after that check what is left that has been applied upstream
<fabbione> and stop there
<zul> ok will start this afternoon then
<fabbione> it's already a lot of work
<fabbione> that we cannot fork unfortunatly
<fabbione> not without a good coordination
<fabbione> zul: also.. your archive was offline a few days back...
<fabbione> do you plan to put it back online?
<zul> yeah..we had a lot of power outages the past couple of days
<zul> should be up now
<fabbione> ok
<zul> frig...
<zul> stupid dyndns
<zul> uh...it should be up today :)
<fabbione> zul: ok.. tomorrow i will be online later than usual
<fabbione> if you can either add your archive to the topic
<fabbione> or send me a mail
<fabbione> or do in such a way that somebody here can tell me where to merge from :)
<zul> sure..
<fabbione> i need some rest now...
<fabbione> it's like 10 hours that i am here no stop
<fabbione> bbl
<zul> k...sleep tight :)
<fabbione> nah.. i am not going to sleep
<fabbione> i just need to rest
<zul> or have some french wine
<T-Bone> i'm sure that'd help ;)
<zul> heh this is funny we have a contractor who is on  a six day contract and whose boss is not in this week
<zul> so she "worked" from home yesterday, and not in today
<fabbione> ehhe
<T-Bone> is she good? ;)
<zul> no everybody hates her like crazy..
<T-Bone> LOL
<zul> the people who work with her dont want to work with her
<T-Bone> schweet
<T-Bone> and she's not "physically intelligent" to help that a bit, i suppose? :)
* T-Bone will be deemed sexist again, he fears 8)
<zul> there are no women kernel developers for ubuntu ;)
<zul> heh..its an old boys club :)
<T-Bone> gosh, i can breathe then ;-)
<zul> unelss fabbione hasnt told us something
* T-Bone looks left and right, looks good, nobody noticed ;)
<T-Bone> LOL
* T-Bone is working on such a boring and ugly code he's almost turning crazy. Besides, sun is shining outside :(
<zul> fabbione: my site is back up i just have to put stuff there
<fabbione> ok
<fabbione> no there are no women here.. that i know off..
<T-Bone> woot! lamont: 94.06% ;o)
<fabbione> T-Bone: is that phase1 or 2?
<fabbione> http://kecy.roumen.cz/roumingShow.php?file=architectural_geekery.jpg
<fabbione> aahaha
<T-Bone> fabbione : what are you calling "phase"? :)
<fabbione> first build on top of debian or the second rebuild of hoary on top of hoary?
<T-Bone> that's hoary on top of hoary
<fabbione> ok so you are making golden debs... 
<T-Bone> fabbione : lol at the pic ;)
<fabbione> good good
<fabbione> daniels: for some reason xorg doesn't detect my monitors :)
<fabbione> ops
<zul> i like the other pictures on that site..especially the cracks
<T-Bone> lamont : we're basically left with kde cruft, ghc6 cruft, and a bunch of broken packages. roughly 250 ones
<zul> fabbione: i think im in love http://kecy.roumen.cz/roumingShow.php?file=ridder.jpg
<fabbione> zul: i didn't browse the site at all
<fabbione> ehehhe
<T-Bone> zul : LOL, *that* is ugly ;)
<fabbione> looks like T-Bone
<T-Bone> fabbione : no way, i can prove it ;)
<T-Bone> fabbione : i'm french, remember? I'm not some kind of Viking of the past ;)
* fabbione thinks about Asterix and Obelix....
<T-Bone> lol
<zul> its xena
<T-Bone> this is completely different. Where do you see a Mehnir here? :)
<T-Bone> Menhir, even
<zul> asterix and obelix rocks hard
<T-Bone> zul : in my memories, xena looked much nicer on TV :)
<zul> by belinos and toutatis
<T-Bone> tssks
<T-Bone> Belenos
<T-Bone> you numnuts ;)
* zul drinks some magic potion and kicks T-Bone's ass
<zul> these french are crazy
<T-Bone> lol
<T-Bone> these ROMANS are crazy
* T-Bone points zul at fabbione ;)
* fabbione doesn't have the power to fight today
<T-Bone> zul : see, fabbione is overwhelmed already by our number of 2 ;)
<zul> hehe
<fabbione> oh shut up you two little piece of choaked meat...
<T-Bone> lol
<zul> hmmm...i guess linus has stopped used bk
* fabbione summons the power of the Grey Skull! and becomes He-Man
<fabbione> zul: yeah apparently
<zul> he man sucks
<fabbione> uh why?
<zul> because he just does 
<fabbione> so does T-Bone .. but there is a reason at least.. he is french
<zul> that is so true
<T-Bone> zul : he stated on lkml that he would immediately cease to use bk
<zul> i didnt see that
<T-Bone> zul : that's because you don't see everything (read: you're blind): http://article.gmane.org/gmane.linux.kernel/293914
<zul> i dont have to take this :)
<T-Bone> fabbione : i will not even bother responding with due slappyness to such a low kick ;)
<kylem> zul, http://marc.theaimsgroup.com/?l=linux-kernel&m=111280216717070&w=2
<T-Bone> kylem : too late already ;)
<kylem> heh.
<fabbione> T-Bone: have you already finished your ideas?
<kylem> question... what are all these odd directories i get when i 'baz update'? ,,changes.1111166685.18992.95/
<kylem> more to the point, can i just delete it... :)
<fabbione> kylem: did you have some local uncommitted changes?
<kylem> fabbione, nope.
<fabbione> did you interrupt any operation?
<T-Bone> fabbione : which ones? Don't you know i *never* run out of ideas? :)
<fabbione> but yes you can delete them safely
<kylem> fabbione, don't think so...
<T-Bone> kylem : ',,' prefixed files are temp files, iirc
<kylem> ok.
<fabbione> kylem: for example a baz undo would create a ,,undosomething
<T-Bone> fabbione : am i correct in my remembering that ,, files are temporary ones?
* T-Bone is often confused with the various types of files from baz
<fabbione> T-Bone: TTBOMK yes
<T-Bone> i don't know that acronym ;l
<fabbione> to the best of my knowledge
<T-Bone> ah ok :)
<T-Bone> ithought this was some kind of displeasing saying of yours... ;)
<T-Bone> i feel martyrised ;)
<fabbione> T-Bone: you still don't know me..
<T-Bone> fabbione : i guess i'd rather not 8)
<fabbione> you haven't seen my worst side yet
<T-Bone> eww
<T-Bone> you're my father?
<T-Bone> ;)
<T-Bone> you speak through a black breathing mask
<T-Bone> and can use the Force?
<fabbione> T-Bone: please.. please. you are really pushing me to say stuff i don't want t o:)
<T-Bone> of course I am ;)
* fabbione turns on his light saber
* T-Bone ROTFLHAO
<T-Bone> i'll make the fortune file available tonight i guess. Gonna be fun :)
<kylem> the parisc fortunes file is great.
<T-Bone> i have some updates for it :)
<T-Bone> i'm actively maintaining it, you see :)
<zul> ooh...am i in them?
<T-Bone> zul : sure
<T-Bone> in the ubuntu one that is
<zul> cool...its my contribution to open source 
<fabbione> i am sure i am there too
<zul> besids some other stuff...
<T-Bone> 170 Ubuntufortunes
<zul> where can i see them?
<T-Bone>  grep fabbione Ubuntufortunes | wc -l
<T-Bone> 57
<fabbione> zul: you can get that on your tomb: "in my life i contributed to opensource with a fortune file's line"
<zul> hehe
<T-Bone> zul : you can't yet, i said i'll publish them tonight :)
<zul> but i want them now..
* zul pouts
<fabbione> come on T-Bone 
<fabbione> put them out now
<fabbione> otherwise i won't be able to see them before tomorrow or monday
<T-Bone> tssks
<T-Bone> ok, i'll make the raw (yet unedited, and not featuring today's fortunes) file online
<T-Bone> that'll be my friendly action toward both of you A-holes of the day ;o))
<zul> seet...more stuff to slack off with
<zul> T-Bone: i didnt start it..you did..
<T-Bone> lol
<T-Bone> kylem : are we having issues with palinux.e.h.c ? I can't connect...
<kylem> i can connect...
<T-Bone> ah yes, here it goes. Strange, i got bounced twice
<T-Bone> http://parisc-linux.org/~varenet/Ubuntufortunes
<zul> maybe its trying to tell you something no french kniggits
<T-Bone> can be fed to strfile
<T-Bone> zul : when i'm world emperor, i'm going to make you suffer such a pain, you'll beg for being killed ;0)
<zul> T-Bone: you forget im married
<T-Bone> zul : i can live with that, and make it worse ;)
<zul> i can take it
<T-Bone> zul : you don't really know me, mind you =] 
<zul> well you are going to have to meet my wife when its that time of month...and dont put that in your fortunes file she has the internet as well
<T-Bone> LOL
<T-Bone> you said that on a publicly logged chan, dude. You're doomed already, fortuning can only help it ;)
* T-Bone thereby fortunes 8)
<zul> im screwed anyways you have a short attention span dont you
<T-Bone> a varying one ;)
<T-Bone> kylem : just updated theparisc one, enjoy.
* T-Bone heads home, bbiah
<zul> heh...Mandriva
<lamont> zul: as opposed to Womandriva?
<zul> www.mandrakesoft.com
<zul> even better http://www.mandrakesoft.com/company/press/pr?n=/pr/corporate/2551
<lamont> lol
<T-Bone> looks like french companies have a taste for sucky (and often expensive) names post-merger :P
<zul> mmm...skittles
<jbailey> North American skittles aren't vegan.
<zul> they still gimme a buzz though
<lamont_r> "Jbailey says sugar not vegan (when mixed with animal fat).  Film at 11."
<lamont_r> sorry - couldn't resist
<zul> hehe
<jbailey> lamont_r: Actually the sad part os that most white sugar is not vegan for the most strict case (which I'm not when I'm out in public)
<jbailey> Although in this case I was refering to the gelatine. =)
<lamont_r> ah, ok
<lamont_r> what's in white sugar in the strict case?
<T-Bone> lamont: ROTFL
<T-Bone> jbailey: if you take into account that most vegetables are finding nutriments in decompositing bodies, they are not vegan :P
* T-Bone ducks and laughs
<jbailey> lamont_r: Usually ground animal bones to use as a filter.
<jbailey> lamont_r: That's the processes that whitens the sugar.
<jbailey> T-Bone: I don't know where you garden.  MY garden has no bodies buried in it.
<T-Bone> lol
<jbailey> T-Bone: The cops look there first...
<T-Bone> lol
<T-Bone> silly you. Are you looking for every dead bug, rodents, bird and the like? :)
<T-Bone> are you cultivating vegetables in actual soil? :)
<jbailey> Ah, different class of 'bodies' =)
<T-Bone> hohoho
<jbailey> download finished, time to start rsync.
<T-Bone> compromising heh?
<T-Bone> trying to find valid excuses? You pitiful pseudo-vegan of my b*llocks ;}
* T-Bone uses newly learnt swears, thanks to jbailey ;] 
* T-Bone guesses jbailey can be of very good advice when it comes to (vegan or not) books 8))
<jbailey> *lol*
<T-Bone> jbailey: you *really* handed me the stick to slap you, on that one ;o)
<T-Bone> I owe you a [vegan]  beer for that ;)
* T-Bone wanders off for a bit (playing guitar whilst time allows it), bbiab
<zul> heh so tomorrow i would be running stable...cant have that can we?
<zul> later..
#ubuntu-kernel 2005-04-19
<T-Bone> http://buildd.slashdirt.org/logs/wnn6-sdk_1.0.0-12_20050407-1249 <- that one might be looking for libwnn6.so.1.0.0 (at the end of the build)
<T-Bone> oops
* T-Bone is glad zul ain't here :)
<lamont_r> T-Bone: it's ok... he reads the logs
<T-Bone> lol
<T-Bone> i hate you :)
<zul> hey
<zul> hey again
<zul> me thinks im the only one here..
<fabbione> morning guys
<zul> hey fabbione crap its late :)
<fabbione> no.. it's earlier than usual
<zul> late for me 
<fabbione> the other for me
<zul> yeah..
<zul> whats up?
<fabbione> have to catch an airplane for london :)
<zul> ah...
<fabbione> i am going to join the others for today's party
<zul> cool...im just going through the 00list
<fabbione> did you do any work on the patches?
<zul> yeah im going through them now, dropped a couple so far
<zul> besides the drivers
<fabbione> ok
<fabbione> did you commit stuff in your branch already?
<zul> not yet...i thought i would get through most of it tonight
<fabbione> ok
<zul> since you guys are going to be partying anyways while im at work...*grumble*bastards*grumble*
<fabbione> zul: ok.. just give me the name of the patches and i will kill them here..
<fabbione> ah well no
<fabbione> you killed the drivers too
<zul> yes since we are going to be updating them as well
<zul> i can send you my 00list without the drivers
<fabbione> nah.. just commit before you go to sleep
<fabbione> i will merge when i am in london
<zul> sure
<fabbione> btw. you can also kill the patches if you want
<zul> how long is the flight?
<fabbione> not just from 00list
<zul> ill get to that :)
<fabbione> i will be there in approx 4 hours
<fabbione> it takes 2 hours of flight + 2 hours of house <-> airport
<zul> cool..copehagen to heathtrow or something?
<fabbione> gatwick
<zul> ah
<fabbione> or whatever is called
<zul> heathrow is nice last time i was there
<fabbione> heathtrow was twice as expensive
<zul> heh
<fabbione> yeah because it is more central than the other one
<zul> yeah we always landed there when i was living in africa heathrow
<fabbione> yeah
<zul> fuck...i cant believe i just did that
<zul> i need to go to bed..
<zul> later
<sataere> !ping
<fabbione> sataere ?
<sataere> Yes?
<fabbione> <sataere> !ping
<sataere> :)
<zul> wtf? arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<fabbione> zul: did you interrupt a commit?
<fabbione> btw... since you forgot to commit i went forward
<fabbione> i need to revert the last commit
<fabbione> it's bong
<zul> i probably interrupted the commit
<zul> what did you change?
<fabbione> i started cleaning the patches
<zul> k
<zul> are you in london yet?
<fabbione> yup
<fabbione> i am already
<zul> cool
<zul> i take it you are drinking tonight ;)
<fabbione> ok you can sync from now
<zul> ok
<zul> im just trying to put my changes into baz now
<zul> ill sync after
<fabbione> zul: it's not easy to fix that problem
<fabbione> you need to change some stuff in the archive manually
<zul> ok..bleah..frigging baz.
<zul> fuck...now i know why its bailing on me
<zul> /dev/hda11            4.6G  4.5G     0 100% /var
<fabbione> doh
<zul> hmmm...PANIC: conflict applying patch in arch_build_revision
<spanglesontoast> ?
<lamont> spanglesontoast: is conversation in another channel
<zul> bbl lunch
<spanglesontoast> what you on?
<fabbione> guys we are going to face a real problem with 2.6.12
<fabbione> apparently they changed something in the evdev driver that changes numbering of some input devices
<Mithrandir> uhm
<fabbione> like mouse0 -> mouse1
<Mithrandir> that's _very_ bad, isn't it?
<fabbione> yes, it s for us
<fabbione> i need to see if i can find the code change
<fabbione> and revert it
<fabbione> i am not sure 100% tho...
<Mithrandir> sounds easy enough per se
<fabbione> it's only one report
<Mithrandir> but why have they changed it?
<fabbione> i dunno.. we will need to check
<fabbione> given that what i was told is true
<jbailey> lamont: Around?
<lamont> yeah
<jbailey> How much of a pain in the arse is it to do a throwaway build of the archive?   I know you suggested that we done one after the toolchian updates, but if it's only a days work on a machine, it might be tempting to do it a few times so that we know if something is seriously broken before we get to the finish line.
<jbailey> I just have no concept of what the resource requirements are.
<lamont> jbailey: for main, it's the matter of a day or 2, if all 3 buildds are on it.
<lamont> it's those really slow gcc-* packages that hurt the most
<lamont> :-)
<lamont> as for actual work, it's a matter of deciding  what wants to be in the chroot, etc, etc. and then having elmo populate the tree, and periodically flush it
<zul> hmmm..conflict...
<zul> lamont: how do you resolve a conflict with baz?
<lamont> zul: you edit the file, look at the conflicts, and fix them
<lamont> just like every other revison control system. :-)
<jbailey> lamont: Cool thanks.
<lamont> then baz --resolved filename
* jbailey grabs food.
<lamont> or baz --resolved --all
* lamont back in a few also
#ubuntu-kernel 2005-04-20
<T-Bone> howdy lamont :)
* T-Bone lags a bit 
<zul> fine just leave then 
#ubuntu-kernel 2005-04-21
<fabbione> morning
<zul> hey
#ubuntu-kernel 2005-04-22
<fabbione> morning
<jbailey> g'm Fabio!
<fabbione> hey jeff
<T-Bone> ola
<fabbione> hey T-
<T-Bone> ola fabbione!
<T-Bone> fabbione : i like your mails: 45% text, 65% gpg key ;o] 
* T-Bone ducks!
<fabbione> it is still worth 100% of the data
<T-Bone> not for me ;)
<fabbione> you are special
<fabbione> but that's not my fault
<T-Bone> 1) because most of the time i don't read gpg signs, and 2) because i know how to fetch a gpg key ;)
<fabbione> :)
<fabbione> T-Bone: my MUA just tells me if the gpg sig is valid or not
<T-Bone> well, it depends on which side you stand. from my PoV, *you* (damned Italian) are special ;o)
<fabbione> i don't read all the gpg crap
<fabbione> T-Bone: that works the otherway around with french
<T-Bone> fabbione : when i use a MUA that can do gpg it does the same, yet it doesn't need to have the key in the message ;) And from work i'm bound to webmail, so gpg ain't much useful there ;)
<T-Bone> fabbione : i knew you'd say that ;)
<T-Bone> fabbione : so, how's the sparc port going? ;)
<fabbione> T-Bone: fine.. hoary main is all built and installable
<T-Bone> lucky bee ;)
* fabbione starts dropping hppa from l-s-2.6.12
<T-Bone> lol
<fabbione> no i am not kidding :)
<T-Bone> that'd be fairly unfair, given the *very* reduced size of the patch
<fabbione> i need to rediff the patches
<T-Bone> ah, you mean the old bloated patch?
<fabbione> yes.. but i got you anyway :P
<fabbione> that was good enough for me
<T-Bone> yeah sure that one can be ditched. The new one shouldn't be more than a few 10s KB
<T-Bone> you are so nasty with me :^P
* T-Bone sad
<fabbione> no i still love you
<T-Bone> no you don't
<T-Bone> you hate me
<T-Bone> i know you do
* T-Bone sighs
<T-Bone> =)
<T-Bone> and that's all my parents' fault. I didn't choose to be born french, you know 8)
<fabbione> still not my problem :)
<T-Bone> you insensitive fool! What would ya've said if ya were born french? 8))
<T-Bone> (and don't tell me you'd commit suicide, i wouldn't believe that ;)
<fabbione> i would probably be bashing other french :)
<T-Bone> lol
<T-Bone> you are sick in your head ;)
<fabbione> no, really???
<T-Bone> yeah, reeaaaaally 8)
<dilinger> so are you guys not planning on turning on DMA for cdroms and dvds?
<dilinger> (drives, that is)
<fabbione> no way
<dilinger> :/
<fabbione> i rather prefer a user that complains about slow performance than people that can't use their CD/DVD at all
<fabbione> dilinger: or do you have good arguments on how to do it in a sane way?
<dilinger> but the number of people that can't use their cd/dvd at all due to dma is relatively small, and those devices should simply be blacklisted as not supporting DMA
<dilinger> the kernel has the functionality to do that already; people w/ nonworking cdroms should report them, so that we can add more to the blacklist
* T-Bone concurs
<fabbione> hmmm
<fabbione> dilinger: i am afraid of landing in the a huge list to maintain outside the kernel
<fabbione> + i always had the feeling that DMA is way too much binded by chipset/cdrom combo
<fabbione> not just one or the other
<dilinger> it should be fairly easy to get patches to add blacklisted devices accepted upstream
<fabbione> we will take a look to it @ UDU
* dilinger nods
<fabbione> i really don't want to take too many decisions right now
<fabbione> specially when we are 2 weeks far from it
<dilinger> i would recommend it as a breezy thing, certainly
<fabbione> and we are still far away to have a kernel for breezy :)
<fabbione> The God Father theme is amazing
* fabbione will make an offer to T-Bone he can't refuse
<T-Bone> hoho
* T-Bone gets scared
<T-Bone> a contract on my head? ;)
* T-Bone watches fabbione play Don Corleone
* fabbione reminds T-Bone that he has been living in sicily for a bunch of years
<T-Bone> this isn't what scares me the most. What scares the hell out of me is that you've been living in sicily for so long and have moved to .dk. Yet, you're still alive. Means you've got strong connections ;o)
<God_Father> T-Bone: picciriddu
<T-Bone> lol
<T-Bone> I knew you were nuts but i didn't figured out how much ;)
<fabbione> T-Bone: you still don't know me enough...
<T-Bone> fabbione : one of these i'll have you pay for treating me like a bambino ;)
<fabbione> this is still all inside my standards
<fabbione> T-Bone: you are a kid
<T-Bone> if you say so ;)
<T-Bone> you must be fsckin old geezer to "kid" me whilst i'm about a quarter century old ;)
<fabbione> i 1/3 century old kid
<T-Bone> wow. Talk about a difference ;)
<fabbione> dude.. when i was turning on my first computer, you were still a dream in your father's testicles
<fabbione> no offence to your father :)
<Mithrandir> fabbione: you played with computers before you were eight?
<T-Bone> i wonder
<T-Bone> you've been turning on your first computer at the age of 5 or somethign? ;)
<fabbione> Mithrandir: i got my first zx81 when i was 6
<fabbione> yes..
<fabbione> i started learning basic at that time
<Mithrandir> fabbione: old man.  I started playing with computers at the age of 1.5 :P
<fabbione> since it was almost impossible to find tapes with games :)
<T-Bone> fabbione : pfff, spoiled child ;)
<fabbione> Mithrandir: ehehe
* T-Bone is *glad* not to have fallen into computers too early
<fabbione> T-Bone: well yeah.. kinda
<T-Bone> that's why i can enjoy *other* things in life ;)
<fabbione> T-Bone: so.. why are you spending time on hppa???
<T-Bone> fabbione : because i can
<T-Bone> ;)
<fabbione> instead of going out scoring chicks?
<fabbione> <T-Bone> that's why i can enjoy *other* things in life ;)
<fabbione> i find difficult to consider hppa *other* things in life <-
<T-Bone> fabbione : nonono, you don't get it. I'm the one being dated by chicks. I have little effort to do 8)
<fabbione> T-Bone: and do you wake up all swet in the morning after these dreams?
<T-Bone> fabbione : lol; dude, you see, i may be a kid, yet i can enjoy some freedom you can no longer feel ;o)
<T-Bone> (that was a proper lart! ;o)
<fabbione> T-Bone: are you so sure? :)
<T-Bone> i do
<T-Bone> ;)
<T-Bone> and other things in life == guitar, sport (funboard, horse riding, ski, moutain climbing, etc), readings, do-it-yourself, parties, and girls dating ;)
<T-Bone> (and that's only the major stuff)
<T-Bone> actually you can s/guitar/music/ cause i'm diversifying in that area ;)
<fabbione> how can you be sure that i didn't elevated my way of pleasures to another level?
<T-Bone> fabbione : i'm sorry, but i'm french. I have to live up to my country's expectation, wrt chicks. That may be the other point Italian and French are always arguing about: who are the most handsome?. My answer is "I am" ;o] ] 
<fabbione> hmmm
<fabbione> i was actually talking to a more general level
<fabbione> not just chicks
<T-Bone> i know
<fabbione> but still.. sometimes there is no need to score chicks to elevate your sexual pleasure
<fabbione> thinking of three-some.. orgies...
* fabbione needs 5 minutes break
<T-Bone> ewww
<T-Bone> and you do that whilst married? ;)
<T-Bone> what an surprising spouse you must have 8)
* T-Bone contemplates good fortune material, btw =] 
<dilinger> fabbione: are you a sopranos fan?
<fabbione> dilinger: nah.. just a mafia's fan :)
<dilinger> hehe
<fabbione> hmm 12rc2 is coming up nice and clean
<fabbione> specially now that i managed to track all the external drivers in details
<dilinger> it's kind of upsetting that linus is wasting his time working on yet another SCM instead of spending it on 2.6.12
<fabbione> i read that thread.. but well i think he is only using it as PoC to see what he really wants/needs
<fabbione> i don't believe he will ever release a SCM
* T-Bone wanders off for lunch, bbl
<fabbione> food... it's almost a good idea
<dilinger> fabbione: i dunno, i'd still much rather see him pick a SCM that he likes the concept of, and help bring the code up to speed
<fabbione> dilinger: yes i agree... but still....
<fabbione> goodie goodies....
<fabbione> all the non external-* patches are done (missing 2 to check that should be upstream)
<fabbione> all the external-* documentation is updated
<fabbione> from now on it will be almost a breezy
<wido> moin guys
<wido> is reiser4 supported by the current kernel?
<fabbione> nope
<wido> couldn't find any reference on the homepage
<fabbione> it's too unstable to be shipped with ubuntu
<fabbione> perhaps for breezy
<T-Bone> reiser4 is still a mess atm, indeed
<wido> ah, ok. then i have to figure uot a way how to backup my mp3s in order to install ubuntu
<wido> btw, reiser4 worked without problems on my gentoo box
<mjg59> reiser4 will be included when it's included in Linus's kernel
<mjg59> The patch is likely to apply to the Ubuntu sources though, so you can probably build your own
<T-Bone> mjg59 : sounds like a wise word ;)
<fabbione> wido: for my experience with reiserfs4... it will enter ubuntu when Linus will bless it upstream
<wido> currently i don't care which filesystem i use. the only question was, if i could reuse my existing partions, or if i have to convert them in order to install ubuntu
<T-Bone> fabbione : that's yet another point i won't discuss, for i agree ;o)
<fabbione> T-Bone: ahhaha
<T-Bone> fabbione : see, we can tag along! ;)
<fabbione> wido: well it depends how you system is partitioned, but that's more #ubuntu question
<fabbione> T-Bone: die young kid! :P
<T-Bone> lol
* fabbione needs more coffee
<fabbione> we are looking good for 12rc2
<T-Bone> you rotten old geezer, i'll watch you burn to ashes =] 
<fabbione> at least.. up till now
<fabbione> T-Bone: sure.. remember to vacuum clean afterwards...
<fabbione> i hate cleaning :)
<T-Bone> LOL
<wido> ok guys. thanks for your answers
<T-Bone> i think we scared him 8)
<fabbione> he is not the first.. won't be the last :)
<T-Bone> probably not ;)
<T-Bone> lamont : ping whenever you're around...
<T-Bone> hey jbailey!
<jbailey> Heya Thibaut!
<fabbione> hey jbailey 
<jbailey> Fabio!
<T-Bone> gaah. My work is sooooooo boring :P
<T-Bone> jbailey : btw, you're late. We've been talking about chicks n' sex a bit earlier. I'm sure you'd have had something to say 8)
* jbailey blinks innocently.
<jbailey> *moi*?
<T-Bone> oui!
<T-Bone> fabbione was expressing some unappeased sexual fantasy 8)
<fabbione> T-Bone: fortune this: ..|..
<T-Bone> given he's an old geezer, he can't do much nowadays 8-D
<fabbione> T-Bone: i have a big reserve of viagra
<T-Bone> fabbione : that's the difference man: i don't need viagra =] 
* T-Bone larts and larts more ;)
<fabbione> T-Bone: you will.. one day..
<fabbione> you can't escape.. as much as i did
<T-Bone> fabbione : maybe, when i'm an old geezer as you are, but i expect this to happen far later than it did for you ;o)
<fabbione> T-Bone: that because i managed to burn myself faster and better
<T-Bone> because, you see, i'm french. Genes are helping ;o)
<T-Bone> lol
<T-Bone> no
<T-Bone> that's because you lacked the potential to last longer =)
<fabbione> i doubt...
<fabbione> anyway.. i need to go out for a while
<fabbione> keep your larting queued for later :)
* T-Bone suggests fabbione turn the other cheek so that he can do symetrical slapping ;)
<fabbione> i haven't finished with you little french punk
<T-Bone> fabbione : i have a huge *pile* in the larting queue. Everything will come in time, i promise ;o)
<fabbione> T-Bone: be carefull.. you are close to shit out of the toilet.. on no .. wait.. you still wear diapers...
<T-Bone> fabbione : neither have i with you, you damned italian clown ;)
<T-Bone> LOL
<fabbione> ,.
<fabbione> later
<T-Bone> cya
<zul> hey
<zul> i been offline most weekend since my computer f'cked up
<jbailey> zul: Yeah yeah, admit it - you wanted to enjoy the weather.
<T-Bone> lol
<zul> and that..but soccer season ended for me on saturday we won the play-offs
<zul> meaning...im not sure
<zul> so which scm is linus using now?
<zul> fabbione: this is a brand new tree with a base-0 and im getting this error ... 1 conflicted items in this tree
<zul> how the hell do i find out what is conflicted?
<T-Bone> arg. sometimes hacking ugly code on buggy material is hell of a pain :P
<jbailey> fabbione: Ping for when you're back?
<fabbione> jbailey: pong
<jbailey> fabbione: Where's the place to babble about initrd-tools hooks in the kernel package?  I'd like an option in kernel-mg.conf to be able to choose a different initrd handler.
<fabbione> jbailey: probably kernel-package
<jbailey> As in, you'd like an enh filed on bugzilla?
<fabbione> jbailey: no, i had like a tested patch
<jbailey> Right.  But do you want discussion around it first?
<fabbione> jbailey: sure.. we can either do it here or on kernel-team.. up to you
<fabbione> first explain me the problem
<fabbione> and what we need to achive
<jbailey> The idea is that I want to test my initramfs replacement.  I can hack around the package all I want for now, but when it comes time to do a call for testing, I'd like to be able to give people 2 lines to add to their kernel-img file to hook to the initramfs generation stuff.
<jbailey> Same way as we do for grub and friends.
<fabbione> works for me....
<fabbione> i don't see any problem with that
<fabbione> "break it early" works perfectly fine for me
<fabbione> + we can help testing it, if you can explain what this initramfs hack should do
<jbailey> fabbione: It's a complete rework of the initrd system that uses udev instead of devfs, and uses hotplug to detect the modules that need to be loaded rather than having all the ugly magic of trying to detect it at install time.
<jbailey> fabbione: There are some other clever bits, but those are the particularily important ones.
<fabbione> jbailey: hmm interesting...
<fabbione> jbailey: i think you want to look at kernel-package
<fabbione> it has the postinst files that gets smashed in the final linux-image
<fabbione> and that generates the initrd
<fabbione> now
<fabbione> the best way would be to modify such a best in a way that "if [ -e /etc/breakmehard ] ; then generate_initramfs; fi
<fabbione> so that you can add the changes even now
<fabbione> but they will be enabled only on demand
<jbailey> Hmm.  I had been thinking of doing it the same way grub is handled:  do_bootloader = no , posthook = update-grub
<jbailey> Rather than hardcode another constant idea in.
<fabbione> i know that make-kpkg has a bunch of hooks that can be installed at kernel build time
<fabbione> so perhaps you want to explore that option too
<fabbione> the most important thing for me are:
<fabbione> a) don't fork kernel-package
<fabbione> b) keep compatibility with the old stuff during development
<fabbione> if you can't respect b) you will block us on working/testing the kernel
<fabbione> a) it's a bit less important, but if you fork, you will also maintain in the future :)
<fabbione> so it's up to you :)
<zul> crappers..
<fabbione> hi zul
<zul> hey fabbione, good weekend?
<fabbione> zul: yeah great
<fabbione> had big fun in London :)
<zul> good to hear...i hardly  touched a computer this weekend
<zul> so im ready to get back to the grind ;)
<fabbione> zul: just gimme another 10/15 minutes
<zul> sure
<fabbione> i have a couple of interesting commits pending :)
<fabbione> we are almost ready to start the build orgy :P
<zul> like what?
<fabbione> all the patches are cleandup
<fabbione> missing a few bits here and there
<fabbione> all the external-drivers have been documented
<fabbione> but they still need updates
<zul> cool...i can update the drivers tonight once i get baz working again
<zul> shiney new hard drive this weekend :)
<fabbione> zul: that's an option
<fabbione> right now the only external that doesn't apply is inotify
<fabbione> so i was thinking to update inotify
<fabbione> and start the build orgy on i386
<zul> yeah 0.22 is supposedly suppose to work
<fabbione> and update the drivers after we know that the core kernel can atleast compile
<zul> but that is what they said about 0.21
<fabbione> zul: yes. they talk by revision numbers
<zul> are you going to try compiling it with gcc 4.0
<fabbione> but i can reproduce the problem here so it will be easy to check
<fabbione> no.. we need to wait the greenlight from doko
<zul> ok..
<fabbione> he said that the actual gcc-4.0 pre6 in ubuntu cannot compile the kernel
<zul> heh
<fabbione> so he was asking us to wait for pre7 or a ping from him
<fabbione> both ways work fine with me
<fabbione> we need to do much work before we can really switch to gcc-4
<fabbione> like getting the new upstream working with the actual gcc
<zul> there are alot of warnings when compiling with gcc-4
<zul> i think most of them have been cleaned up upstream
<fabbione> yeah well.. we are tracking upstream now :)
<zul> heh...we were always were...i was trying to at least ;)
<fabbione> ehehe
<fabbione> we are more bleeding edge now :)
<zul> just have to wait for linus to get his ass in gear ;)
<fabbione> yeah
<zul> heh..http://internetnews.com/dev-news/article.php/3496541
<fabbione> old news
<fabbione> zul: do a baz update now
<fabbione> and tell how sexy 00list-1 looks like :)
<fabbione> zul: btw that article was posted on an ubuntu ml :)
<zul> heh so shoot me..i been stuck outside all weekend ;)
* fabbione shoots zul
<zul> not literally
<zul> fabbione: not bad ;)
<fabbione> zul: sexy eh?
<zul> yeah i think you are missing a patch for inotify though
<fabbione> the first one that will break the name convention will be pubblically cross burned on top of the eiffel tower
<fabbione> zul: nope
<zul> so it will be t-bone since he is the closest to the eifel tower
<fabbione> zul: all the patches are there
<fabbione> inotiify = external + alpha sort = last one
<fabbione> but i am updating it right now to 0.22
<zul> the disable inotify patch by default?
<fabbione> zul: i will drop it for now
<zul> ok
<fabbione> i will keep the source around, but we will not apply it
<fabbione> also because it will need rediff anyway
<fabbione> let see how my tests go
<zul> true...
<fabbione> and we can still stick it back
<zul> fsck...it says i have a conflict but its a pristine copy
<fabbione> zul: ?
<fabbione> is that baz?
<zul> 1 conflicted items in this tree. Please resolve each conflict with baz 
<zul> yeah
<fabbione> WEIRD
<fabbione> let me check out
<zul> i should only need 2.6.11.90 in my arch should i?
<fabbione> zul: are you using baz from ubuntu or from the daily baz build?
<zul> baz from ubuntu
<zul> Bazaar version 1.2 (thelove@canonical.com/dists--bazaar--1.2[bazaar--devo.cfg] )
<fabbione> i am testing
<fabbione> deb http://bazaar.canonical.com/packages/debs/ ./
<fabbione> i use this one
<fabbione> but let me check
<zul> 1.3?
<fabbione> yeah
<fabbione> works fine here
<fabbione> try to get the tree again...
<fabbione> baz get kernel-debian--pre1--2.6.11.90 debian/
<zul> hmm...no default archive set
<fabbione> zul: sorry.. 
<fabbione> i use the kernel archive as default
<fabbione> baz get kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.90 debian/
<zul> getting it
<fabbione>   Enable full-sized data structures for core (BASE_FULL) [Y/n/?]  (NEW) 
* fabbione grins
<zul> hmm?
<fabbione> Preemptible Kernel (PREEMPT) [Y/n/?]  y
<fabbione>   Preempt The Big Kernel Lock (PREEMPT_BKL) [Y/n/?]  (NEW) ?
<fabbione> This option reduces the latency of the kernel by making the
<fabbione> big kernel lock preemptible.
<fabbione> Say Y here if you are building a kernel for a desktop system.
<fabbione> these are the new options for 2.6.12rc2...
<zul> ah
<fabbione> doesn't it ring a bell?
<zul> okies...nope it doesnt
<zul> fudge..PANIC: conflict applying patch in arch_build_revision
<fabbione> hmmmm
<fabbione> try to update baz and see if that fixes
<zul> tree already up to date
<zul> baz is really starting to get to me
<fabbione> sorry.. i was busing updating the config
<zul> not probs
<fabbione> try to use baz from the archive i pasted before
<fabbione> they might have broke compatibility or something
<zul> ill update my baz tonight then
<fabbione> zul: ok
<fabbione> i am building here :)
<fabbione> just for fun
<zul> :P
<T-Bone> lamont : ping...
<fabbione> T-Bone: of the 3 hppa patches... 
<T-Bone> ditch them all
<fabbione> can i kill all of them and just grab the new one from cvs?
<T-Bone> correct
<fabbione> ok
<fabbione> but only after i will have sparc kernels...
<T-Bone> LOL
<fabbione> right now i am owning hppa :)
<fabbione> MUHA MUHA MUHA
<T-Bone> i hate you, you silly little kernel caporal of my bollocks ;)
<T-Bone> fabbione : in any case, this won't bring universe to sparc ;o)
<T-Bone> jbailey : i'll have to bug you for hppa installer, btw ;)
<zul> "i hate you, you silly little kernel caporal of my bollocks ;)" i thought you said buttocks
<T-Bone> lol
<T-Bone> you psycho-perv
<jbailey> T-Bone: Erm, for Ubuntu or Grub2?
<T-Bone> jbailey : for ubuntu. Grub2 is none of my concerns ;o)
<T-Bone> we have palo... ;o)
<jbailey> Right.  And I don't know enough about hppa stuff to port grub2 to that yet.  Perhaps that can be an autumn project.
<jbailey> I'm more likely to do ia64 first.
<T-Bone> you're the SM type, right? :)
<jbailey> Sure.  Now decided if I'm a top or a bottom...
<T-Bone> LOL
<jbailey> ;)
<T-Bone> given the palo hack, i doubt it'll be easy to port something else to hppa :)
<T-Bone> s/the// s/hack/hackyness/
<fabbione> i am impressed.. it's compiling the modules!
<jbailey> Dude, can anything be uglier than booting on ia32?
<T-Bone> hackery even. Call it whatever you like
<fabbione> without any failure.. yet
<T-Bone> jbailey : fair enough ;)
<T-Bone> fabbione : that's sparc? :)
<jbailey> fabbione: At some point I want to talk to you about sparc and glibc. =)
<fabbione> T-Bone: not yet
<fabbione> jbailey: anytime...
<fabbione> even now.. if you want to
<jbailey> In an hour would be better for me.
<fabbione> hmm in one hour i might be off...
<jbailey> Okay, now then makes as much sense as any other time. =)
<fabbione> T-Bone: in anycase i would kid too much about sparc and universe.. because hoary it's building pretty fast and breezy isn't open yet
<jbailey> I have 2.3.5 packages up here.  I haven't finished pushing all the Ubuntu modifications to it yet, but a question I have for each arch is which threading libraries to enable.
* T-Bone contemplates SM-glibc-bondage on the way
<zul> is there a meeting this week?
<fabbione> jbailey: well is it only question to try to build and test or to do something specific?
<T-Bone> fabbione : yeah yeah. Thing is, we're about 95% up to date on hppa, and could get maybe 1 more point with KDE building ;)
<fabbione> zul: 2
<fabbione> T-Bone: see... i have kde builded :)
<zul> 2?!
<jbailey> I have a bias towards moving people to nptl online on as fast of a schedule as they can cope with, since: 1) LinuxThreads is considered deprecated by upstream.  2) The hacks to make both LT and NPTL are not supported by upstream and keep breaking in subtle ways. 3) It's far nicer to only have one threading library to support, especially considering that otherwise it automagically detects which one it should
<jbailey>  use.
<fabbione> zul: one tomorrow for the CC/TB and one in 2 days TB/CC
<T-Bone> fabbione : i'd be glad to ask a few questions about that then. What i'm facing looks mostly like a circdep issue
<fabbione> can't remember the order :)
<zul> bleah..
<fabbione> jbailey: i see.. but what can i do to help?
<zul> hmmm...im might not make them..oh well
<zul> fabbione: yeah it was the baz verison i was using
<jbailey> The biggest blocker against NPTL is usually commerical software.  Folks with precompiled binaries that either make assumptions about threading layout, or use extern int errno, which nptl can't support (#include <errno.h> good)
<fabbione> T-Bone: well i kept kicking back the packages
<jbailey> fabbione: Tell me what the right thing for your pet arch is. =)
<fabbione> jbailey: well afaik there are not many binary only drivers for sparc
<jbailey> Not drivers, applications.
<fabbione> so i think it is pretty safe to move
<fabbione> i mean applications sorry
<fabbione> at least not that i am aware of
<T-Bone> fabbione : that's waht i'm doing. Yet, it complains that kdelibs aren't installed (which they are), and looking at config.log, it seems that the culprit is some QT lib missing
<fabbione> usually companies that produce applications for sparc, run on slowlaris
<jbailey> 'kay.  I should receive a sparc box later this week, I can do some testing.
<jbailey> I don't know how iBCS interacts with the threading system.
<fabbione> T-Bone: /var/cache/apt/archives is your enimy
<T-Bone> fabbione : it's being regularly cleaned by me and the autobuilder.
<jbailey> I think it's just a syscall wrapper, isn't it?  In which case Solaris emulation shouldn't be affected.
<Mithrandir> T-Bone: is nekkid up?
<fabbione> jbailey: to be hounest, i love sparc, but i don't know enough to play with libc and stuff like that
<fabbione> it's too deep for me
<fabbione> T-Bone: well.. do you ever update the chroot?
<jbailey> fabbione: It's more the how prevalent is commercial applications.  The Free software world has already figured out generally how to cope.
<fabbione> T-Bone: and apt-get update && apt-get dist-upgrade must be done regularly
<fabbione> jbailey: tbh for ubuntu we can switch as test platform
<fabbione> we are not even officially released with sparc
<fabbione> go ahead and do your changes
<jbailey> fabbione: That would be lovely.
<fabbione> we can still be the drive arch for it
<T-Bone> fabbione : i do that too :P
<jbailey> Thanks.  I'll test it enough to make sure that you at least have bash and apt working ;)
<fabbione> i really don't mind to kill proprietary applications
<fabbione> jbailey: i can test in a chroot.. can't i?
<jbailey> fabbione: Sure. =)
<fabbione> jbailey: plus i have an extra partition where i can isntall and run "natively"
<jbailey> But I mean before I hand it to you, I'll make sure of that.
<zul> heh someone broke the naming scheme
<zul> parisc-irq.dpatch
<fabbione> zul: right!
<T-Bone> fabbione : give me a few secs, i'll show you the error
<fabbione> let's burn T-Bone !
<fabbione> T-Bone: no no.. you are the hppa porter.. go figure it yourself :P
<fabbione> T-Bone: or now is time to call the oracle because of the experience?
<T-Bone> zul : that's an *old* patch, when there was no such a thing a a naming scheme. Besides, if you have issues with that patch name, i suggest you discuss it with lamont.
<zul> heh...
<fabbione> ahhaa
<zul> maybe i will..frog :)
<T-Bone> zul : bear in mind that lamont is an pyrotechnist and expert in all kinds of explosives ;)
<T-Bone> fabbione : you're so overconfident ;o)
<zul> yeah i have to wear my flap jacket around him
<T-Bone> fabbione : i'll call you the oracle if you can *actually* help me ;)
<fabbione> T-Bone: you talk like if you can convince lamont to bomb us....
<T-Bone> fabbione : i think it's pretty easy to convince lamont to bomb anyone getting in the way of Ubuntu hppa ;o))
<fabbione> T-Bone: well fire the error log somewhere
<zul> T-Bone: is lamont in michigan?
<T-Bone> fabbione : generating it as I speak :)
<fabbione> T-Bone: i guess you don't want a kernel anymore.. do you?
<T-Bone> zul : lamont is everywhere ;)
<T-Bone> fabbione : you can't do that. I'll put a contract on your feet (your head ain't worth it) if you do that ;o)
<fabbione> yes i can :)
<T-Bone> (on the feet, one can always grab a pair of shoes, if anything ;)
<fabbione> oh hell
<fabbione> fTBFS
* Mithrandir prods T-Bone 
<fabbione> and you know where?
<fabbione> right on one of this retarted external drivers
<T-Bone> lol
<T-Bone> Mithrandir : lol don't tempt me too much ;o)
<Mithrandir> T-Bone: 16:48 < Mithrandir> T-Bone: is nekkid up?
<T-Bone> Mithrandir : it'll be in 1h
<Mithrandir> ok
<Mithrandir> I need to trash her around a bit
<T-Bone> (too bad i haven't hooked the serial cable, i could have powered it up now)
<T-Bone> sure
<Mithrandir> I'm doing a new ia32-libs, which is so horrible you can't imagine
<T-Bone> i can
<T-Bone> i've seen the old ones ;)
<Mithrandir> this is worse
<T-Bone> ewww
<T-Bone> this must be *really* scary then ;}
<Mithrandir> more ugly, actually
<Mithrandir> since it supports both ubuntu and debian
<Mithrandir> which puts libs in different places
<T-Bone> yum!
* T-Bone is amazed at the number of SM-psycho on this chan ;)
<T-Bone> aah. Iron Maiden is good to hear when hacking ;)
<fabbione> T-Bone: iron maiden ++
* T-Bone is glad to be allowed to use his iPod at work ;)
<T-Bone> fabbione : hehe ;)
<fabbione> but right now i am in love with the God Father theme :)
<T-Bone> lol
<fabbione> * committed kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.90--patch-21
<fabbione> given this version.. you should be able to compile 2.6.12rc2
<T-Bone> ain't "peachy" enough :)
<fabbione> no config updates yet
<fabbione> no hppa patches
<T-Bone> (re GodFather theme)
<fabbione> T-Bone: eeheh
<fabbione> note: none of the external drivers (other than the one documented as | ok | are guarenteed to work)
<fabbione> simply because they are obsoleted
* T-Bone switches from Iron Maiden to Morcheeba. Quite a hop ;)
<zul> Maiden rocks..
<T-Bone> heh. There ain't only Maiden in life. You'd be quite surprised at the range of music i enjoy. Eg, i'm now listening to "A Man Called Adam / Eastern Song", which could be classified as "ambient dub" probably ;)
<T-Bone> s/Eastern/Easter/
<zul> i listen to a vaiety as well: punk, metal, celtic, and classical 
<zul> mostly system of a down right now though
<T-Bone> fabbione : http://buildd.slashdirt.org/kde/ if you want to take a look
<T-Bone> zul: I like Aerials quite much :)
<zul> T-Bone: same..
<T-Bone> and Boom does rock
<zul> i been listening stuff from their new album ;)
<T-Bone> hehe
<fabbione> T-Bone: it looks to me like qt3-free-something has been miscompiled on hppa
<fabbione> the UIC thing is not from kdelibs
<fabbione> the error is bogus
<fabbione> usr/share/qt3/bin/uic                                       devel/qt3-dev-tools
<fabbione> qt3-dev-tools
<T-Bone> fabbione : yeah the error is definitely bogus, that's what i think too
<T-Bone> qt3-dev-tools-compat_3.3.3-7ubuntu3_hppa.deb
<T-Bone> qt3-dev-tools-embedded_3.3.3-7ubuntu3_hppa.deb
<T-Bone> qt3-dev-tools_3.3.3-7ubuntu3_hppa.deb
<T-Bone> these are the packages i have available
<fabbione> T-Bone: i would check the qt3-dev-tools build log and compare it with another arch
<fabbione> T-Bone: yes.. same versions as the one used to build ia64
<fabbione> but perhaps something in the log is different and worth checking
<T-Bone> ok
<fabbione> dpkg-deb: building package `linux-image-2.6.12-1-686' in `../linux-image-2.6.12-1-686_2.6.11.90-1_i386.deb'.
<fabbione> YAY
<T-Bone> thx for the hint, i'll look at that
<fabbione> ok.. i am off
<fabbione> cya tomorrow fellas
<T-Bone> cya
<zul> toodles
<zul> lunch..
* lamont breakfasts
<T-Bone> hey lamont!
* T-Bone heads home, bbiab
<fabbione> hey lamont 
<fabbione> uname -a
<fabbione> Linux gundam 2.6.12-1-686 #1 Mon Apr 11 16:35:21 CEST 2005 i686 GNU/Linux
<fabbione> impressive!
<fabbione> it even boots!!!1
<fabbione> lamont: if you can get around today to update the hppa patches, it would be very nice
<lamont> fabbione: I'll make some time to work on that \
<lamont> first I need to really do some mail to kernel-team for UDU, etc...
<fabbione> lamont: sure.. don't worry.. if you don't get around it before i wake up tomorrow, i will do it
<fabbione> mdz was also talking about setting goals for breezy
<fabbione> and have a preliminary discussion done before
<fabbione> including sabdfl 
<fabbione> so perhaps you want to CC him?
<fabbione> i don't think he is subbed to the mailing list
<fabbione> there was also another thing.. who is actually moderating the mailing list?
<fabbione> i keep receiving the mails about posts/subscription
<fabbione> but i don't have the admini passwd
<zul> me either
<T-None> Mithrandir: nekkid is booting, all yours. Might want to update it...
<Mithrandir> cool
<lamont> fabbione: 2.6.11.90 is based on rc1 or rc2?
<zul> rc2
<zul> but im not fabbione :)
<zul> you know those president bush masks we should make one a fabio mask
<lamont> zul: hehe
<T-Bone> Mithrandir: seems that nekkid is having issues
<T-Bone> with hotplug, for a change
<T-Bone> and since there ain't no kbd driver in the kernel, i'm fucked up
<T-Bone> jbailey: wouldn't it be possible to have usb drivers loaded on the ramdisk? (that applies for ppc btw, and imho to any machine that has usb-only keyboards)
<jbailey> T-Bone: Yup.  Just include them in /etc/mkinitrd/modules for now.
<jbailey> T-Bone: I do that on my ppc64 box for testing initrd stuff.
<T-Bone> jbailey: i don't understand why this has been changed again. I already had that problem, already pointed out how *stupid* it was not to have kbd working at that point, and IIRC the default was changed to something more coherent. I guess the change has been reverted at some point
<T-Bone> jbailey: i'd love to include them, but for that to happen i'd need to have control over my machine, which i haven\t
<jbailey> T-Bone: As far as I know, it's never been included in the initrd.
* T-Bone wonders why everytime he needs to use that fucking ia64, he has to get utterly pissed off by it
<jbailey> T-Bone: It gives use insufficient sex.
<jbailey> s/use/you/
<T-Bone> jbailey: no. I think they were builtin
<jbailey> Oh, I see.
<jbailey> I can see not wanting them built-in when you're trying to get consistant configs.
<T-Bone> (which wasn't very good, but at least much better than the present case, for i'll have to burn an ia64 cd, go into rescue mode and toy around
<jbailey> But there's no reason to need them built-in.  The right thing is that your initrd should always include those bits.
<T-Bone> of course it should
<T-Bone> i'm glad i'm not the only one to think that way :P
<T-Bone> this is so pissing me off: it's a simple matter of ctrl-C'ing the fucker, and i can't do that :(
<T-Bone> i *hate* hotplug when used in stupid ways :P
<T-Bone> btw that's a poorly designed script: it should have timeout mechanisms :P
<T-Bone> Mithrandir: i'm sorry, you'll have to wait or find yourself another ia64. I don't plan to fix that tonight :P
<jbailey> Mithrandir: What do you need?
<Mithrandir> jbailey: root on a ia64 debian and ubuntu box.
<jbailey> T-Bone: I will provide you with some initramfs love after UDU.  I told Fabio earlier that I would give him a tested patch to kernel-package to do the hooks I need.
<jbailey> Mithrandir: my ia64 box is Debian running, although I think I have a hoary chroot.
<Mithrandir> jbailey: would you mind lending me root and abusing your network connection?  (The source package is 250-ish MB)
<jbailey> That's fine.  It's colo'd at a university, so you might even have a decent connection between you.
<Mithrandir> yay.
<jbailey> Mithrandir: Put your ssh key on chinstrap or something?
<Mithrandir> jbailey:  chinstrap:tfheen-err.no.ssh.dsa.pub
<T-Bone> jbailey: heh cool. BTW, i don't have sex with machines or borgs. I prefer chicks ;P
<ogami1972> hello room- Q. whta is best kernel choice for an amdk6 (building is not an option at this stage)
<ogami1972> ?
<T-Bone> jbailey: and the day i'll consider ia64 for sex, i'll grant you full clearance to erase me from the surface of the Earth ;0)
<ogami1972> oooooookkkkk......
<T-Bone> ogami1972: that's a question for #ubuntu
<ogami1972> ok - thanks
<Mithrandir> uhm, what's a decent place to point apt to?  Seems like ia64 is removed from hoary?
<zul> heading home...later
<jbailey> Is it completely removed?  I thought that they were just not building CDs for it.
<Mithrandir> I get 404s, at least.
<Mithrandir> and http://archive.ubuntu.com/ubuntu/pool/main/o/openjade/ (random sample) doesn't show any ia64 debs.
<Mithrandir> jbailey: yay, this seems to work.  I think it'll work for ia64 in Hoary too.
<jbailey> Mithrandir: Cool.  Are you running i386 binaries?
<Mithrandir> jbailey: ldd on libc worked. :P
<jbailey> Wow, crazy.
<jbailey> I didn't know that the kernel was setup to allow that to work. =)
<Mithrandir> it's a kinda weird situation, since I want to get it working for {amd64,ia64} {Ubuntu,Debian} where amd64+Ubuntu and ia64+Debian is supported, but not amd64+Debian or ia64+Ubuntu
<Mithrandir> oh, it doesn't work since I removed ia32-libs. :P
<Mithrandir> yay:
<Mithrandir> ia64:/# ~tfheen/ls  -d b*
<Mithrandir> bin  boot
<Mithrandir> ia64:/# file ~tfheen/ls
<Mithrandir> /home/tfheen/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
<jbailey> Crazy.
<Mithrandir> (unstable_tfheen)tfheen@ia64:~/ia32-libs$ du -sh .
<Mithrandir> 207M    .
<Mithrandir> this seems to work, so I'll upload
* Mithrandir hopes bdale won't kill him too badly.
<Mithrandir> I'm off to bed; I'll clean up tomorrow morning
<jbailey> *lol*
<jbailey> Run away from ther terminal so he can't find you? =)
#ubuntu-kernel 2005-04-23
<lamont> fabbione: you around?
<zul> mmmm....slurpee
<lamont> hrm... tempting
<kylem> zul, what part of the city are you in?
<zul> kanata
<kylem> oh. sorry.
<kylem> :)
<zul> ok..enough with the kanata jokes i get enough of those at work :)
<kylem> hehe.
<zul> we arent that psycho
<kylem> i can understand why it's a desireable place to live, it's just far. ;-)
<zul> well its close to the corel center so when they turn on their power full blast we get blackouts
<kylem> do you work downtown?
<kylem> yikes.
<zul> yep albert at bank...
<zul> i rather work downtown then in kanata
<kylem> we should meet up for a keysigning sometime. i hear you and willy met up befoe.
* lamont smacks the hppa rc2-pa1 patch into 2.6.12
<zul> kylem: sure..
<zul> i should be at the next oclug meeting as well though
<kylem> cool. that works.
<kylem> lamont, heh.
<zul> freaking pinteric
<kylem> i'm just relieved he didn't get elected.
<lamont> kylem: mind you, it failed to apply :-(
<kylem> lamont, ouch. i blame fabbione.
<zul> heh
<lamont> kylem: well, the fact that it applies on top of all the other patches, makes it really unsurprising
* lamont keeps the directory this time. :-)
<kylem> lamont, lol.
<lamont> kylem: turns out this one belongs completely to the parisc crowd
<lamont> EXTRAVERSION, specifically
<kylem> how so?
<lamont> well, the file says 'EXTRAVERSION = ' and the parisc patch says 'rc2' -> rc2-pa1
<lamont> or rather tries to
<lamont> E: linux-source-2.6.12_2.6.11.90-1_source.changes: bad-distribution-in-changes-file breezy
<lamont> hrmpf
<zul> miss usa is on tonight
<lamont> building... time to wait for it to finish.
<fabbione> morning
<kylem> lamont, heh, not removing the extraversion hunk is your fault. ;-)
<lamont> kylem: herh
<lamont> morning fabbione 
<lamont> hppa testbuild running, fwiw
<fabbione> lamont: rocking.. the EXTRAVERSION needs to be set to =
<fabbione> unfortunatly this is the 2nd hack required to build these version asymmetric kernels
<lamont> fabbione: yeah
<fabbione> and if you notice is the 2nd file modified in the .diff.gz
<fabbione> because we can't patch it only at build time
<fabbione> lamont: do you have the kernel-team admin passwd?
<lamont> yes
<fabbione> lamont: ok, are you administering it?
<lamont> no worries here
<fabbione> because i noticed a lot of subscription notifications
<fabbione> but i can't do anything..
<zul> hey fabbione 
<fabbione> hey zul
<zul> for external drivers that are not a patch i take i create the directory and all the config file goodiness
<zul> er Kconfig
<lamont> fabbione: I don't see that I have to actually _do_ anything with the subscriptions...
<lamont> or is that not true, and I'm just clueless?
<fabbione> lamont: no idea..
<fabbione> lamont: you didn't commit anything for hppa, did you?
<zul> fabbione: new arch for me is at http://zulinux.homelinux.net/arch
<fabbione> lamont: i did update the sparc buildd to handle hoary-security and hoary-updates
<fabbione> lamont: would you mind to double check with me if i did something horribly stupid?
<fabbione> zul: ah ok
* zul applied for another job today..
<fabbione> actually.. i can't find how to deregister the old archive
<zul> couldnt you remove it from your ~/.arch-params?
<fabbione> nah found it
<zul> cool
<fabbione> baz register-archive -d
<fabbione> baz register-archive http://zulinux.homelinux.net/arch
<fabbione> it hangs there....
<zul> frig..
<zul> hmmm...maybe i should install apache
<fabbione> maybe? :)
<zul> perhaps
<zul> are you running 2.6.11.90 now?
<zul> hmmm....the domain is not resolving..
<fabbione> yes.. on 2 machines
<lamont> fabbione: you want me to check in the abi files for -1 as well? :-)
<zul> and how is it running?
<fabbione> lamont: keep them handy for -2 yes
<fabbione> zul: i don'y really know.. i just installed it yesterday evening and it still didn't crash..
<lamont> fabbione: I could just check them into -1, and then they'd be there, no?
<fabbione> zul: have to test idiotify later
<zul> heh good luck
<fabbione> lamont: nope.. they will be wiped away at the first make clean
<fabbione> amd64 building
<fabbione> ppc and ia64 starting now
<fabbione> guys i was thinking to add a precompiler for control.stub
<zul> why?
<lamont> fabbione: yeah
<fabbione> if [ -e debian/experimental ] ; then add_very_long_experimental_note_in_description; fi
<fabbione> zul: to be able to add or remove something from all the descriptions without having to manually edit it
<zul> ah ok good idea
<lamont> yeah - I guess it's forgivable
<zul> right new version of cpad..ill put it my arch tomorrow...im off to bed
<zul> later..
<fabbione> lamont: anyway this is only a prebuild to see if the main kernel compiles
<fabbione> abi files will be useless
<fabbione> we still need to update all the drivers
<fabbione> and add the new ones we want in
<fabbione> like ipv6 statefull firewall
<lamont> yes
<fabbione> that will bring new config options and stuff like that
<fabbione> go ppc it's your birthday!
<fabbione> i hate that arch
* lamont decides to go to bed
<fabbione> good night lamont
<lamont> fabbione: btw, arch-hppa_pa1.dpatch sound good to you? (yeah, it's the megolith patch, but...)
<fabbione> yeah sure :)
<fabbione> since it touches a lot everywhere you can keep calling it pariscpa :)
<fabbione> or whatever you prefer
<fabbione> i really don't minf
<fabbione> mind
<fabbione> i want to keep a strict naming for the generic patches
<lamont> is already committed as arch-hppa_pa1
<fabbione> ok fine for me
<lamont> lamont@ubuntu.com--2005/kernel-debian--pre1--2.6.11.90
<lamont> and currently mirroring
<lamont> done
<lamont> will commit back to the main branch in the morning after I verify that the builds succeeded, and maybe even boots
<fabbione> sure
<fabbione> works for me
<fabbione> we are not going to release this kernel anytime soon anyway
<fabbione> good night dude
<fabbione> cya later
<fabbione>     Specialix DTR/RTS pin is RTS (SPECIALIX_RTSCTS) [N/y/?]  (NEW) 
<fabbione> AH GREAT
<fabbione> one of this options that can be object of endless fights
<fabbione> i guess we will have to modify the driver to accept a boot option
<T-Bone> oy!
<fabbione> hey T-Bone 
<T-Bone> hi fabbione 
* T-Bone builds conserver on his ubuntu box, wishes it was in the archive :P
* lamont boots 2.6.11.90-1 on hppa
<fabbione> hey lamont 
<lamont> morning fabbione 
<fabbione> is it booting?
<lamont> is booting
<lamont> s/ing/ed/
<fabbione> neat
* lamont merges back to the trunk
<lamont> fabbione: dch changed it to my changelog entry - I'm assuming you'll change it back before upload or some such
<lamont> actually, looks like I'll get a conflict out of the merge, you busy boy you
<fabbione> lamont: it depends a lot what you changed :)
<fabbione> i am committing a lot
<lamont> no conflict.. very odd
<fabbione> nah.. it's not odd
<fabbione> i didn't touch anything in hppa
* lamont was thinknig debian/changelog
<fabbione> did you do a baz update?
<lamont> si
<fabbione> ok
* fabbione updates too
<lamont> but I did the work on my branch several hours ago
<fabbione> baz update 
<fabbione> * tree is already up to date
<fabbione> it's not on main yet.. is it?
<lamont> commit is _now_ finished
<fabbione> ok
<fabbione> it's grabbing
<fabbione> yup
<fabbione> no conflicts at all
<fabbione> but we will have to rebuild other times
<fabbione> at least after i finish to update all the external drivers
<lamont> fabbione: sure
<fabbione> i suggest that while we work on 2.6.11.9X we just ignore all the abi stuff
<fabbione> it is enough not to upload l-r-m
<fabbione> do we want to allign the configs across arch before this release or after?
<fabbione> we have time for breezy anyway
<T-Bone_> lamont : have you fetched all of archive.slashdirt.org btw?
<T-Bone_> lamont : was considering that i could rebuild (parts of) main if needed. The autobuilder is idle
<zul> hey
<lamont> T-Bone_: not recently, so I assume the answer is probably no
<lamont> fetching now
<T-Bone_> lamont : ok. I've built everything that could be relatively easily built. 94.77% up to date
<T-Bone_> there's the kde mystery though
<fabbione> YAY for ipw2200 and ipw2100!
<fabbione> they are out of sync at upstream!
<T-Bone_> lamont : in any case, if you want me to build whatever's missing in main with a builder that has only main in sources.list, i can do that. In anycase, i'll be finishing rackmounting the new machines tomorrow at school, and I'll wait for your input to set them up
<fabbione> T-Bone_: ah you didn't use the ogre model?
<T-Bone_> fabbione : given the *very* limited input i had, i used what i could setup by myself, mostly
* fabbione sends T-Bone_ back to debootstrapping phase
<T-Bone_> fabbione : you see, i'm not a buildd guru and that thing is not so well documented, so to speak
<T-Bone_> fabbione : ..|..
<T-Bone_> ;)
<fabbione> uhuhuh
<zul> oh behave
<fabbione> hppa is d00m3d
<T-Bone_> fabbione : it doesn't matter for universe
<fabbione> it does for main
<T-Bone_> that's why lamont is only letting his 'main' packages in
<T-Bone_> and that's why there's my 'unofficial' (ugly) archive that has everything in it
<zul> holy crap fabbione you been busy
<T-Bone_> fabbione : truth told, given we are now 3 people having hppa ubuntu running, we don't care much that our build-deps are not what they should be
<fabbione> zul: i haven't finished yet...
<fabbione> i am in the middle of ieeee ipw2100 and ipw2200 updates
<fabbione> that are almost like circular build-deps
<T-Bone> fabbione : now if you wanna write docs for the ogre model, i'd gladly read and use it :P
<zul> i updated cpad last night and a ppp-mppe 
<fabbione> zul: ok
<fabbione> good.. do they compile+
<fabbione> ?
<zul> was going to try this morning
<fabbione> T-Bone: it's way too easy to get you.. it's not even funny
<T-Bone> if you say so
<fabbione> zul: anyway right now the build will fail on ipw2200
<zul> and afs
<zul> how come?
<fabbione> afs ?
<zul> amiga fs
<fabbione> zul: because ieeee ipw2100 and ipw2200 depends on each other and i just finished ipw2100
<fabbione> i need to ipdate ipw2200
<zul> ah
<fabbione> asfs <-
<zul> thats what i meant
<T-Bone> fabbione : truth is there are a couple of things that are *really* pissing me off. ia64 is one of them, wasting time because of lack of info is another, and being slapped because I haven't done something right *because of said lack of doc* is probably the biggest one ;P
<fabbione> T-Bone: the latter is the funniest :P
<fabbione> well right.. it was a long time i didn't bitch about ia64
<zul> T-Bone: do you want the new S.O.A.D mp3?
<fabbione> T-Bone: mind to update the config for 2.6.12?
<fabbione> :P
<T-Bone> for you maybe. It's really getting on my nerves, given the *huge* amount of time i've spent/wasted in the process
<fabbione> T-Bone: nah.. i already did it
<fabbione> ia64 is up and runnign with 2.6.12
<fabbione> i would be more glad to get the installer working on it
<fabbione> but there is nothing i can do for it
<T-Bone> since last time i tried ia64 it was b0rken, i don't care much
<fabbione> since i don't have racks and racks of ia64
<fabbione> T-Bone: that's the point.. you need to fix it as ia64 porter...
<fabbione> not expecting that everybody will fix it for you
<fabbione> but anyway it is not my arch / not my choise..
<T-Bone> i don't have racks and racks, i have a rack, that's different. I can provide access. But I won't do anything without community backup, that i've been unable to get so far
* T-Bone contemplates bashing a few instutions on public m-ls btw
<fabbione> instutions ?
<T-Bone> fabbione : let me enlight you: I'm *NOT* an ia64 porter
<T-Bone> if there are evidences that I am, they should be fixed
<T-Bone> oh yeah, like Gelato for instance
<T-Bone> aka "the guys that say 'yeah go for it we'll follow' and then watch you do the job"
<fabbione> https://www.ubuntulinux.org/community/teams/ia64/view?searchterm=ia64
<T-Bone> ic
<fabbione> and no...
<T-Bone> well, if i'm to fix it, my 'fix' will be deletion
<fabbione> i didn't write that page it overnight :)
<T-Bone> (of said page)
<T-Bone> i know you didn't. It's remnant of some glorious past era
<T-Bone> (being cynical)
<T-Bone> this is quite a sensitive subject for me, since I didn't cover my ass, I'm the one in frontline
<fabbione> zul: updating the ipw2200 now..
<fabbione> ipw2100 is done
<zul> cool..im just trying to compile my stuff from last night
<fabbione> so i am at 66.666666666666666666666666666666666666%
<T-Bone> this has told me the hard way that one should cover his ass before doing anything, and has drastically reduced my faith in the "process"
<zul> fabbione: have you fixed debian dir from being deleted?
<fabbione> zul: of course....
<fabbione> that's the first thing i do on each major upstream
<fabbione> zul: but i guess you still have to understand where the fix is :P
<zul> :P
* fabbione grins
<fabbione> zul: you will notice that in all our kernel releases there is one file in the kernel tree that is patches from outside debian/patches
<fabbione> there is a reason for that :P
<fabbione> and that's the same reason why i told you need to get all the stuff from people AND only after to replace the debian dir from baz
<fabbione> lamont said that i was evil not telling you
<fabbione> but you have been warned the day before ;)
<fabbione> i couldn't spoil the fun
<zul> figgers..
<fabbione> brb
<zul> must...kill...
* T-Bone hands zul his pocket-sized bazooka
<lamont> hrm... could kernel-team use USD 275M?...
<lamont> nah - I'll drop that email
<zul> kernel-versions?
* T-Bone reads some very interesting article quoted on ubuntu-devel ml
<fabbione> lamont, T-Bone: does hppa have some kind of HT?
<T-Bone> no
<T-Bone> all SMPness
<fabbione> HT like in HyperThreading
<fabbione> ok
<zul> i still suck
<T-Bone> (ie: dual core CPUs are seen as 2 CPUs)
<fabbione> T-Bone: never mind how the OS looks at them
<T-Bone> (assuming you're talking about CONFIG_HT)
<fabbione> i am talking if it has HT in hardware
<fabbione> with dual core and so on
<T-Bone> it has dual cores yeah
<fabbione> ok thanks
<T-Bone> in pa8800
<T-Bone> (latest CPUs)
<fabbione> T-Bone: ok thanks
<T-Bone> fabbione : where comes that sudden interest for PA-RISC features? ;)
<fabbione> T-Bone: curiosity mainly
<fabbione> i don't know much about hppa hw
<fabbione> other than the 9100 is a huge empty piece of crap
<zul> ok...i give up
<T-Bone> fabbione : hehe. Well, just to reassure you: yeah, SparcSucks4 sucks, as the name suggest ;)
<fabbione> zul: ?
* zul bows at the mercy of fabbione 
<fabbione> zul: can you explain me the problem?
<T-Bone> SparcsSuxtyFour, even
<zul> the debian deleting 
<zul> there is kernel-versions and package-list outside the debian directory
<fabbione> zul: did you grab the .diff .dsc from people.u.c when i published it?
<zul> yep
<fabbione> did you unpack it with dpkg-source -x .dsc ?
<fabbione> no
<zul> uh..
<fabbione> you unpacked the orig
<zul> yeah
<fabbione> and sticked the debian dir in that
<T-Bone> bwahahaha
* T-Bone larts zul 8)
<fabbione> you know.. the diff.gz..
<fabbione> ok just for the sake of simplicity
<fabbione> kill everything
<fabbione> if you don't have the .diff.gz .dsc do the following:
<fabbione> unpack the orig
<T-Bone> as in 'rm -rf /' ? ;)
* zul smacks T-Bone 
<fabbione> cd whatever dir
<fabbione> vi Makefile
* T-Bone dodges, points zul and laughs ;)
<fabbione> and set the EXTRAVERSION =
<fabbione> instead of rc2
<fabbione> the next is scripts/packaging/Makefile
<fabbione> or packages
<fabbione> search for the only instance of debian
<fabbione> and comment it out
<zul> ok..
<fabbione> you MIGHT notice that the instance of debian is inside a clean target rule
<zul> frigging christ..
<fabbione> blame upstream
<fabbione> AHAHHAHA
<zul> i blame the french
* T-Bone takes back the pocket bazooka, aims at zul, fires
<T-Bone> ah. That's a good thing done ;)
* fabbione powers up the sodomotron and inserts T-Bone's coordinates
* zul T-Bone in his lower colon
* T-Bone listens to "Arena di Verona / Verdi - Nabucco / Va Pensiero", has a thought for fabbione ;)
<zul> back to work..
<T-Bone> fabbione : dude. You're so utterly scatological perv, to say the least... ;P
<lamont> fabbione: switch to using the colostomizer
<T-Bone> lamont : weird, i'd have thought you'd suggested some practical highly explosive matterial instead ;] 
<T-Bone> -t
<lamont> T-Bone: I just love that word, taht's all
<lamont> thank you simpsons
<fabbione> ehhee
<T-Bone> heh. you perv ;)
<T-Bone> yeah. Simpsons perv, should i have said :)
<T-Bone> OTOH, fabbione is stupid enough to blow himself with explosives, instead of blowing his target (me). That'd be nice though ;)
<zul> hmmm...the compile fails with gcc 4
* T-Bone figures a TexAvery-like blown-fabbione-face, has a laugh ;)
<T-Bone> zul : heh, what a surprise, my dear :P
<zul> its one of our patches
<T-Bone> "And radio buttons look like they were drawn in the dark by a drunk with a broken pencil."
<T-Bone> how cute ;)
<zul> whats this?
<T-Bone> http://mpt.net.nz/archive/2005/04/11/ubuntu
<T-Bone> (point 52. I *love* point 45, fwiw ;)
<zul> holy crap..
<T-Bone> (and point 37 is unsurprising to me)
<fabbione> ok update for the ipw2200 committed
<fabbione> the kernel should be able to build again
<fabbione> zul: what drivers did you update?
<fabbione> i am planning to stop now..
<fabbione> if so.. are you also updating debian/external-drivers ?
<zul> ppp-mppe and cpad so far
<fabbione> zul: ok
<fabbione> just use external-drivers to keep track
<zul> and i have a couple of bugs about external drivers in bugzilla as well
<zul> thats what i have been doing
<fabbione> zul: yeah we have a bunch in bugzilla
<zul> and fixing some gcc4 stuff..
<fabbione> but before dragging in 30984 external drivers we should decide if we want them or not first
<fabbione> gcc4 is not a priority right now
<fabbione> we need to get our tree updated first
<zul> im running gcc4 at home
<fabbione> otherwise it will keep failing somehere
<fabbione> anyway i need a break
<T-Bone> fabbione : i might have some time to toy around on my ppc later today, if that can help
<fabbione> later guys
<fabbione> T-Bone: boot the kernel :)
<T-Bone> kay :)
* T-Bone baz get topic archive
<zul> oh and dont do what i did
<T-Bone> zul : i'm much smarter than you are ;)
<T-Bone> Teeheeheehee
<zul> T-Bone: if you could see the finger im showing you right now you wouldnt be impressed
<T-Bone> no i wouldn't
<T-Bone> ;)
<T-Bone> hmm
<T-Bone> zul : would you please point me at the place where fabbione's diff/orig live? :}
<T-Bone> (you can use whatever finger for that, i don't care ;o)
<zul> let me use my middle finger and i can point you to http://people.ubuntulinux.org/~fabbione
<T-Bone> hmm
<T-Bone> i must have looked at the wrong place there, can't find it :P
<zul> hmmm..he must have deleted them
<T-Bone> there's the orig
<T-Bone> not the diff
<T-Bone> fsck
<zul> gimme a sec.
<T-Bone> there's an ugly picture of his hacking area too ;)
<zul> because i like you ill help you up
<zul> http://zulinux.homelinux.net/
<T-Bone> zul : duuuuuuuude, you're so keen on me. Thaaaank you ssooooooo muuuuuuch (figure out the voice of Britney Spears playing hooker, as usual) ;)
<zul> eww
* T-Bone fetches
<T-Bone> zul : since i like you too, i'm fetching the orig from p.u.c, to avoid hogging your bw ;)
<zul> thanks
<T-Bone> it also saves me some time ;)
<zul> bastard
<T-Bone> thoug p.u.c is *slow* dog ;)
<T-Bone> there it is. I have them all, thx
<zul> no probs
<T-Bone> ewww
<T-Bone> i've just been looking at d-private mail. Damn, yet another GFDL flamewar ;P
<zul> are you surprised?
<T-Bone> hell no
<zul> gfdl?
<T-Bone> let them provide useless free tools with no doc at all :P
<zul> lol
<T-Bone> Gnu Free Doc License
<zul> debian-devel is who has the biggest balls 
<T-Bone> afaik, Ubuntu won't go that way. Though i guess it'll be interestingly painful to merge back what debian will remove ;P
<zul> heh..
<T-Bone> zul : not the biggest balls, far from it. The biggest mouth, at best
<T-Bone> or the most time to spend replying
<zul> gentoo is kind of the same way but people are trying to make money off it
<T-Bone> huh?
<zul> gentoo has it share of flame wars but there are alot of developers trying to make a profit from their work
* T-Bone tries to remember how to get a pristine (eg: without baz cruft) copy of a baz tree
<zul> and that gentoo also sold their souls to the devil
<T-Bone> zul : i don't fully understand what this is about. I guess i'm not involved enough in gentoo to figure out ;)
<zul> T-Bone: good thing to :)
<T-Bone> heh
<kylem> sold their souls?
<zul> working with sun
* T-Bone fires dpkg-buildpackage, just for fun
* zul kicks T-Bone 
<T-Bone> and we'd really need a way to build only a given flavour (better one than hacking rules)
<zul> i totaly agree
<T-Bone> zul : that's the first step to see what's wrong, mind you (dpkg-buildpackage) :)
<T-Bone> and it builds so fast...
<T-Bone> especially now that i have added some ram to the box
<T-Bone> yet it doesn't use CONCURRENCY-LEVEL, sigh :(
<zul> im debating to go to 64bit soon
<T-Bone> heh
<T-Bone> i find 64bit rather useless for my workflow
<T-Bone> unless i need loads of RAM and I use scientific apps, which doesn't happen everyday ;)
* T-Bone tries to figure out why his build doesn't use C_L := 3
<T-Bone> maybe 3 isn't enough
<T-Bone> huho
<T-Bone> it uses it in modules and not in builtin
* T-Bone larts fabbione, digs in rules
<T-Bone> make[6] : *** [drivers/net/wireless/ipw2100/ipw2100.o]  Error 1
<T-Bone> huhu. "Fixed" says he
<T-Bone> and "ewww i don't like that one": include/acpi/platform/aclinux.h:59:22: asm/acpi.h: No such file or directory
<lamont> T-Bone: building ppc?
<T-Bone> yeah
* lamont considers building the kernel on his G3, shudders
<T-Bone> forget it
<T-Bone> looking at the code, this can't work
<lamont> yeah
<T-Bone> linux/acpi.h unconditionnaly includes asm/acpi.h
<T-Bone> hmm
<T-Bone> assuming this is right, i suppose the driver should only include linux/acpi.h if CONFIG_ACPI is enabled...
<T-Bone> given only x86, X86_64 and ia64 have asm/acpi.h :P
<T-Bone> i get it
<T-Bone> looks like it should include <acpi/acpi.h> instead of <linux/acpi.h>
<T-Bone> maybe not
<T-Bone> duh
<T-Bone> come to thinkof it
<T-Bone> ipw2x00 familly should only be useful on x86 machines, right?
<T-Bone> which makes it then normal it assumes acpi is available :P
<kylem> the ipw driver depends on acpi?
<T-Bone> kylem : my 2cents is that it doesn't build without it
<kylem> groan.
<T-Bone> either poorly designed conditionnal build, or poorly designed driver
<kylem> i've a little `embedded' x86 board i need to build it on later.
<T-Bone> given what i see in the code, i'd bet on the former
* T-Bone tries adding a couple #if 0 around #include <linux/acpi.h> to see whathappens
<T-Bone> that works
<T-Bone> i find it strange include/linux/acpi.h doesn't have a check for CONFIG_ACPI
<T-Bone> yet i know *nothing* about ACPI
* T-Bone doesn't know what the proper fix is
<T-Bone> s/fix/way of fixing this/
* T-Bone rotfls at Gunnar Wolf's mail
<T-Bone> zul : i'm about to leave. Can you check with fabbione/whoever what the proper way of "fixing" the ipw2100 driver is? Basically all it needs is "not to include <linux/acpi.h> on non ACPI enabled kernels"
* Mithrandir guesses #ifdef CONFIG_ACPI\n#include <linux/acpi.h>#endif
<fabbione> yeah i didn't check portability of the new code yet
<fabbione> right now i am only updating it
<fabbione> anyway dinner time
<fabbione> cya later for the meeting
<T-Bone> meeting?
<zul> now?
<zul> 20:00 utc
<T-Bone> no i just figured out fabbione was talking about TB
<zul> ah...sorry i just have a wicked headache
<T-Bone> there are no kernel-related stuff on the agenda so i think i can safely ignore it
<zul> dont worry ill be there
<T-Bone> zul: and that's supposed to reassure me? :)
<zul> if you dont want me to kick your ass
<T-Bone> i'm not quite sure this makes a difference :)
<zul> you right it doesnt
<T-Bone> lol
* T-Bone contemplates booting his newly built 2.6.12 kernel
<T-Bone> but since i haven't built the initrd...
<jbailey> Then you would probably have a sad experience. =)
<T-Bone> my bet
<T-Bone> hence not booting it :)
<T-Bone> (and playing guitar instead ;)
<T-Gone> bbl
<fabbione> re
<zul> hey fabbione 
<fabbione> yo
<zul> yoyo
<fabbione> zul: did you merge any patch?
<zul> nope still at work
<fabbione> ok
<zul> will do some work tonight though
<fabbione> what was your archive again?
<zul> http://zulinux.homelinux.net/arch
<fabbione> unable to access URL: /arch/.listing
<fabbione> webdav error: 404 Not Found
<zul> fuckers..
<fabbione> i am going to update some more stuff in the meanwhile
<zul> how do you create a listing file again?
<fabbione> we need ask lamont.. i really don't know
<zul> lemme check my logs
<zul> doh..
<fabbione> where is T-Gone when we need him
<zul> fabbione: try now
<zul> well i dont need him :)
<fabbione> still 404
<fabbione> ok.. time to update ndiswrapper :)
<fabbione> i remember this one to be a bitch
<zul> better you than me
<fabbione> zul: die bitch
<kylem> damn, you ubuntu guys are harsh.
<kylem> ;-)
<fabbione> kylem: ahaha
<fabbione> kylem: see..
<zul> fabbione: i know what you are but what am i 
<kylem> don't you have a code of conduct? :)
<fabbione> this is the only chan in which we can really express ourself
<zul> not in this channel
<fabbione> kylem: yes we do.. but we override it in this chan
<fabbione> actually
<kylem> haha.
<fabbione> we should rename it
<kylem> that's amusing. :)
<fabbione> s/-kernel/-psycoslutskernelmaintainers
<zul> -psychocrazykernelmaintainers
<fabbione> whatver
<fabbione> DIE DIE DIE MY DARLING!
<zul> lay off the mafia movies :)
<fabbione> that's from Metallica dude
* DonCorleone makes an offer to zul that he can't refuse
<zul> heh metatica sucks
* kylem throws a horse head in fabbione's bed.
<zul> metalica even
<fabbione> metaLLica
<kylem> zul, third time the charm? :)
<fabbione> i wonder who registered DonCorleone :)
<fabbione> i swear i didn't
<zul> shaddup im writing documentation
<fabbione> to do what? print it on a 4 layers toilet paper for further use?
<zul> pretty close..
<zul> how to install a windows app
* fabbione kicks zul
<zul> its not my fault!!
<zul> stupid crown corporation
<zul> fabbione: try now
<kylem> zul, for whom do you work? NavCan? (trying to guess based on location)
<zul> kylem: IDRC
<kylem> ah.
<fabbione> zul: still 404
* zul kicks baz
<zul> its a TB meeting tonight?
<crimsun> yep
<zul> heh everyone get their shots
<fabbione> ah now i remember all the pile of crap behind ndis
<fabbione> hmm
<fabbione> we need to decide how deep we want to go with ndis for breezy
<fabbione> because it supports amd64 now
<fabbione> but there is an issue
<fabbione> it generates a bunch of headers at build time
<fabbione> that is not really someking kbuild likes
<fabbione> let's stick with i386 for now
<fabbione> we will see in future :)
<dilinger> er
<dilinger> what generates a bunch of headers?
<fabbione> dilinger: ndiswrapper
<fabbione> it has a target called make gen_exports
<fabbione> without _exports file = FTBFS
<fabbione> but they are generated dynamically according to the arch
<zul> we could always split it out of the kernel
<fabbione> and they are different between i386/amd64
<fabbione> even if they have the same names
<fabbione> zul: uh?
<zul> actually what was i thinking
<dilinger> fabbione: i'm so confused
<dilinger> the headers are autogenerated during build
<dilinger> and used during build
<dilinger> and that's all
<dilinger> i've gotten reports of the ndiswrapper in sid working for amd64
<fabbione> dilinger: yes.. but that's ok when ndiswrapper is compiled outside the kernel tree
<dilinger> ah
<fabbione> when we apply it as patch inside the kernel
<fabbione> ...
<dilinger> right
<fabbione> so I need to find a way to deal with that
<fabbione> brb
<dilinger> ndiswrapper needs to go away, and be replaced by something shipped in the kernel that's a bit cleaner..
<T-Gone> fabbione: i'm digging in your ass ;] 
<dilinger> oh my
<T-Bone> dilinger: your what? ;o)
* T-Bone ducks
<fabbione> T-Bone: hell...
<fabbione> that's almost disgusting...
<fabbione> that's probably why it was hitching
<T-Bone> fabbione: yeah. Unless you were sitting on the sodomotron...
<T-Bone> =] 
<T-Bone> fabbione: let's cut the crap (where it is btw), why were you looking for me? :)
<fabbione> T-Bone: you are really asking me.. aren't you?
* T-Bone ponders answering affirmatively 8)
<fabbione> T-Bone: it was for a driver update on a what used to be a french only site, but they translated it in a sane language
<T-Bone> fabbione: huh?
<T-Bone> which one is that?
<fabbione> T-Bone: the eagle-usb
<fabbione> but they translated the site in english
<T-Bone> ok
* fabbione pats his sparc
<fabbione> it munged almost 300 pkgs
<T-Bone> wow
<fabbione> only 10 FTBFS
<T-Bone> in how much time? :)
<fabbione> from this morning at 5am
<T-Bone> sweet
<fabbione> yeps
<fabbione> it won't manage to build universe before breezy
<zul> hmmm...http://zulinux.homelinux.net/arch/zulcss@gmail.com--2005
<fabbione> but it might get pretty close
<T-Bone> lol
<fabbione> unable to access URL: /arch/zulcss@gmail.com--2005/.listing
<fabbione> webdav error: 404 Not Found
<fabbione> zul: does it work for you?
<zul> im using sftp
<fabbione> well.. hell.. try it in http to?
<fabbione> T-Bone: universe has tons of small packages.. that's why
<T-Bone> yeah i know
<fabbione> all the big ones are in main anyway
<T-Bone> at some point one of my autobuilders was processing 1000+ packages a day
<fabbione> between kernel, glibc, gnome, gayde and ooo
<fabbione> T-Bone: yeah i am not surprised
<fabbione> oh.. hold on.. 300 + i had a parallel build running with the kernel
<T-Bone> heh
<fabbione> ndiswrapper updated
<zul> im off...later psychocrazycocainecrazykernelpeople
<T-Bone> that's twice crazy
<T-Bone> you're screwd ;)
<kylem> is it just me, or is that a system of a down lyric.
<zul> maybe
<zul> i was listening to them all day...well most of the day
<zul> toodles
<T-Bone> fucking X kill :P
<lamont> fabbione: --listing when you create the archive
<fabbione> lamont: ok :)
<lamont> or create a non-empty file called ${archive}/=meta-info/http-blows
<fabbione> ahah
<fabbione> if elmo doesn't flush the incoming queue soon, it will be full of sparc changes
<lamont> fabbione: you're assuming that he's still going to take hoary uploads...
<lamont> (I'm just hoping he willl)(
<fabbione> lamont: well they are sparc binaries
<fabbione> nothing changes the source
<fabbione> i see no reason for rejecting them
<lamont> fabbione: exactly
<fabbione> lamont: we need to send out that mail to kernel-team with mdz and sabdfl in CC
<lamont> it's just a question on how one interprets "no more hoary uploads"
<lamont> fabbione: right
<lamont> will be working through that toady
<fabbione> lamont: yes.. i see the point :)
<lamont> today, even
<fabbione> lamont: thanks.
* T-Bone wonders what mail this is about
<fabbione> hmmm
<fabbione> i didn't know that prism2 has pci and some firmware stuff...
<fabbione> well nobody complained.. so i guess the usb driver is enough
<T-Bone> prism2 is used with some pci wifi cards as well as some pcmcia/cf ones, iirc
<fabbione> yeah but we ship only the usb driver
<T-Bone> we suck ;)
<fabbione> nah probably nobody uses it anymore
<kylem> 0000:01:02.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01)
<T-Bone> i thought we enabled *EVERYFUCKINTHING* in our kernels? :)
<fabbione> otherwise we would have get reports about it
<T-Bone> kylem: ^5!
<kylem> of course, i don't run your crappy kernels. ;-)
<T-Bone> LOL
<fabbione> kylem: ahhaa
<kylem> or your os, for that matter. cough. why am i here again?
<T-Bone> kylem: i love you! (in all platonic ways of course ;)
<fabbione> kylem: do you know if the pci version requires firwmares?
<kylem> fabbione, it doesn't.
<fabbione> so which one does?
<kylem> fabbione, the firmware is upgradeable.
<fabbione> ah ok
<fabbione> so it is only required for upgrades
<kylem> fabbione, is this hostap you're talking about?
<kylem> or some other prism2?
<fabbione> kylem: nope.. linux-wlan
<kylem> oh, puke.
<fabbione> i will get to hostap later...
<T-Bone> fabbione: some USB dongles need the fw iirc
<kylem> don't bother shipping linux-wlan prism2 pci/pcmcia... hostap is way better.
<fabbione> T-Bone: you are french... and i don't trust you... + they might sell crappy hw there
<fabbione> kylem: it is already there.. i am only updating it
<T-Bone> fabbione: may i show you the finger and point you at the linux-wlan website?
<kylem> fabbione, then there's no problem.
<T-Bone> they list which devices need the fw there
<fabbione> kylem: ok + i don't ship pci/pcmcia.. only usb
<T-Bone> fabbione: I know for sure since i've been working on supporting one of said supported USB device on an embedded arm board
<fabbione> T-Bone: aren't you part of the kernel team?
<kylem> fabbione, that makes sense, i don't think hostap supports usb
<fabbione> T-Bone: send me patches :)
<fabbione> kylem: ok
<fabbione> thanks
<T-Bone> sometimes i wonder
* kylem loves his prism2. :P
<fabbione> i have my cisco airnoet
<fabbione> aironet
<fabbione> it's UPSTREAM
<lamont> fabbione: X question for you...
<kylem> prism2 is supported by orinoco too...
<fabbione> you and your crappy hw
<fabbione> lamont: go ahead..
<kylem> fabbione, bet you can't run in master mode... ;-)
<fabbione> (if i can answer
<lamont> so I just swapped out my CRT for an LCD display....
<lamont> dpkg-reconfigure fontconfig
<fabbione> kylem: i don't need to. i have a cisco AP :)
<lamont> now how do I get X to get with the program?
<lamont> or is it reset time?
<kylem> fabbione, heh, fair enough, i guess.
<fabbione> lamont: uh.. i think it needs a reset
<lamont> bummer.
<lamont> brb
<fabbione> kylem: i really don't use wlan a lot
<kylem> lol. i don't use anything but.
<fabbione> i still like my pure 100Mb cisco switches
* fabbione hugs the fiber that cross the house
<T-Bone> fabbione: http://www.linux-wlan.org/docs/wlan_adapters.html.gz <= PCMCIA/CF are listed as using proprietary fw. that's all i can tell so far
<fabbione> T-Bone: as you can see.. the usb doesn't
<fabbione> and we don't ship pcmcia/cf
<fabbione> so i was right
<fabbione> we do NOT need firmware
<fabbione> =
<fabbione> T-Bone sucks
* T-Bone wonders why we don't ship pcmcia/cf
<fabbione> probably because we can't redistribute the firmware
<T-Bone> that doesn't prevent us from enabling the driver and let the user load the firmware, does it?
<T-Bone> not to mention all devices that work without the firmware
<T-Bone> but heh
<T-Bone> i don't care
<T-Bone> i don't run silly kernels ;)
<fabbione> neither do i
<fabbione> i don't have crappy hardware
<T-Bone> fabbione: oh, the kernel boss doesn't care about his baby?
<T-Bone> *interesting*
<fabbione> nobody asked for it = less code = the better
<T-Bone> heh
<T-Bone> i doubt anybody has asked for ipw2x00 support on ppc but i'm being nitpicking i suppose ;)
<kylem> how could they?
<kylem> unless you can get it on a full size pci card...
<lamont> ew.  still pixlelated
<T-Bone> kylem: exactly what i'm asking. Yet we build it on ppc ;)
<kylem> none of the laptops have minipci slots (cause apple sucks and stuff...)
<T-Bone> kylem: tssks. Don't be so bitter because the machines are beautiful but unaffordable 8)
<kylem> T-Bone, they're plenty affordable.
<kylem> T-Bone, cheaper than my thinkpad...
<T-Bone> lol
<kylem> T-Bone, only the >15" powerbooks have pcmcia, and none of them have minipci. Top Kwality.
<fabbione> aren't there any ipw2x00 pcmcia cards?
<kylem> fabbione, i've never seen one.
<fabbione> well this is argument for config allignment between arches
<fabbione> that reminds me so much of dilinger and zul
<kylem> what about things that won't build on one arch?
<kylem> like, lots of the isdn stuff is #error broken on big endian
<fabbione> kylem: that's the whole point of it
<fabbione> we need to allign the core config options
<fabbione> across all arches
<fabbione> and ban the shit that is not needed on arch foo
<kylem> hmm.
<fabbione> the point is that nobody really knows all the details for each arch/subarch
<fabbione> there are simply too many
<fabbione> so we need to team up and clean up as much as we can
<fabbione> possibly with a tool (dilinger?) to keep track of these kind of things
<T-Bone> kylem: truth told i don't really see the point of minipci on a laptop. imho, laptop != desktop, but that's another topic ;)
<kylem> T-Bone, you're kidding?
<kylem> T-Bone, my minipci wireless hooks up to the internal antenna in my laptop.
<kylem> can't do that nicely with pcmcia...
<T-Bone> fair enough, but you see, we've got airport... ;)
<kylem> only on ancient machines xor in Mac OS X...
<T-Bone> fabbione: i don't understand what you're trying to do. Whaddya mean "core config options"?
<T-Bone> kylem: huh?
<kylem> airport is only on old machines, airport extreeme is only supported in mac os x.
<T-Bone> err
<T-Bone> can't airport extreme be driven like regular airport?
<kylem> no.
* T-Bone needs to check that out again on his g5
<kylem> it's a broadcom chip
<T-Bone> ah
<T-Bone> sweetness ;)
<fabbione> T-Bone: stuff like HIGHMEM or PREEMPT
* kylem smacks T-Bone 
<kylem> :)
<T-Bone> kylem: let's rev-engineer that ;)
<kylem> T-Bone, i started trying to.
<T-Bone> fabbione: mostly what is to be found in 'General setup' i suppose then
<kylem> same chip, but in the wrt54gs access points. (broadcom ships a binary wl.o)
<T-Bone> fabbione: so we don't care about syncing drivers between archs no more?
<kylem> T-Bone, reverse engineering a chunk of binary sucks arse.
<T-Bone> kylem: huhu! I might want to help you doin that :)
<fabbione> T-Bone: yes we do dude.. be elastic in your mind
<kylem> T-Bone, heh. :)
<kylem> we've all established i'm insane re-VisFX etc... :\
<T-Bone> fabbione: then i don't see the point. "we do for some but not for all"?
<fabbione> T-Bone: if arch foo supports USB we are going to buidl all the usb modules on it
<fabbione> something that we do not do now
<T-Bone> kylem: no, you're moderately wicked. Being insane would involve getting SuckyIO to work ;)
<kylem> what's wrong with SuckyIO?
<kylem> it's only slightly stupid.
<T-Bone> fabbione: nice. What if a given module doesn't work/build on the arch?
<T-Bone> kylem: everything?
<T-Bone> 8)
<fabbione> T-Bone: oh christ.. what is not clear about me writing: "<fabbione> and ban the shit that is not needed on arch foo"
<kylem> i wish ad1889 would work
<T-Bone> fabbione: not much. I'm just getting on you. Revenge, you see? :)
<T-Bone> (because I can)
<T-Bone> kylem: dreaming doesn't hurt. Until you wake up ;)
<fabbione> T-Bone: do you realize that it is almost 20 hours that i am awake of which 17 here?
<T-Bone> fabbione: not my problem 8)
<T-Bone> fabbione: do you realize that you often get on me while i'm *hardly* awaken, or in the middle of a *very boring and idiotic work*? I guess that makes us quite equal ;o)
<T-Bone> fabbione: besides, who said there were anything like *rules* between us? 8)
* T-Bone kicks fabbione between the legs, for good measure =] 
<lamont> fabbione: we could kick-ban him for a few minutes... :)
<T-Bone> Teeheehhee
* fabbione lanches the sodomotron to T-Bone 
<T-Bone> lamont: too bad i passed the passwd over you, heh. That day i shot myself in the foot ;o)
<lamont> hrhe
<T-Bone> me notices that fabbione *is* anal, points him at http://spamusement.com/view.php?id=223
* T-Bone runs!!
<T-Bone> hmm
<T-Bone> thinking of whic
<T-Bone> h
* ..[topic/#ubuntu-kernel:T-Bone] : Ubuntu kernel development discussion (rated PG-13) | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre35--2.6.10 playground: kernel-debian--pre1--2.6.11.90 | There are no kernel bugs.. only broken hardware | bk is dead
<T-Bone> lets warn everybody ;)
<lamont> T-Bone: you do realize that the code-of-conduct applies here too, yes>
<lamont> ?
<T-Bone> ?
<lamont> politeness and family-consumable type stuff, you know
<T-Bone> ah
<T-Bone> so i'm being moralized for merely behaving as the ops do on this chan?
<T-Bone> i was mostly kidding but if it's unsuitable i'll shut up
<T-Bone> not like i care
<lamont> nah, was more referring to the PG13 comment.. :-)
<T-Bone> well, since we're using *rough* words to say the least... :}
<lamont> since that could tend to accellerate the kidding....
<T-Bone> and given Ep III has been PG-13'd
<T-Bone> i think we're a tad worse than Ep III ;}
* ..[topic/#ubuntu-kernel:T-Bone] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre35--2.6.10 playground: kernel-debian--pre1--2.6.11.90 | There are no kernel bugs.. only broken hardware | bk is dead
<fabbione> lamont: i am raelly not conviced at all about this gcc4 transition
<fabbione> lamont: are you running any buildd test?
<T-Bone> all hail the CoC
<T-Bone> (i said "the") =] 
<fabbione> baz commit -s'Update prism2 and wlan-ng'
* T-Bone quickly hides
<fabbione> good.. this one is go to
<lamont> fabbione: not yet - need to have a statement on what they want, and elmo needs to flush me a distro
<T-Bone> lamont: lemme know if there's stuff that needs building in main
<T-Bone> now that universe is built, getting back on some main packages ain't difficult
* T-Bone calls it a night
<dilinger> fabbione: heh
<dilinger> fabbione: right, i started that, just never finished
<dilinger> and atm, i'm busy ebaying my possessions :)
<fabbione> dilinger: well.. i think it's almost time to take away the dust from it :)
#ubuntu-kernel 2005-04-24
<zul> i take it the meeting is over
<davidj> Where's a good place to find a comparison between Opterons and Xeons?
<qman> davidj: tomshardware.com or anandtech.com might be a start
<davidj> qman: Thank you.
<qman> yup
<zul> wtf
<fabbione> morning
<fabbione> i guess zul didn't put up his archive yet
<fabbione> lamont: i am going to parse bugzilla for external drivers requests and see how much we can include in the first shot
<lamont> cool
<fabbione> i am sure some of them are ok to go right away
<lamont> btw, the arch-hppa_pa1 patch (probably?) contains some newer-than-upstream driver changes, esp in the sym58xx driver, iirc.
<fabbione> lamont: well the sym58xx is upstream.. isn't it?
<lamont> since willy likes to use the parisc tree as his personal testing ground before pushing them into linux (he's upstream for that driver)
<fabbione> ah i see
<fabbione> well we can wait for willy to push it upstream
<lamont> exactly
<fabbione> or otherwise you need to split the patch out of parisc
<lamont> yeah, and I'm just not all that motivated to do that...
<fabbione> i don't mind to coordinate with willy and use ubuntu as test bed
<fabbione> neither am i :)
<fabbione> let see if willy has it splitted already :)
<fabbione> baz commit -s'Update acpi_sony'
<fabbione> ssh: sftp: Name or service not known
<fabbione> kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.90: not a valid archive name or url.
<fabbione> baz 1.4 is broken
<lamont> that's why I stick to what we ship our customers (aka hoary)
<fabbione> lamont: yeah.. i know..
<lamont> hehe
<fabbione> baz commit -s'Update atmel firmwarez'
<fabbione> whoops :)
<T-Bone_> booh
* fabbione larts T-Bone to start a good day
<T-Bone_> cool
<T-Bone_> http://sloss.free.fr/gallerie/index.php?gal=5 <- have you been posing for that? ;}
<fabbione> ehehe
<T-Bone_> =)
<fabbione> i did pose for warthogs :)
<T-Bone_> lol
<fabbione> the warthogs suites me better in shape and size :P
<T-Bone_> rotfl
<T-Bone_> what an ugly person you must be 8)
<T-Bone_> Teeheehee >:-)
* T-Bone_ contemplates UDU agenda, doesn't quite agree with all items, but heh
<T-Bone_> hu. Breezy uploads are open, heh
* T-Bone_ contemplates uploading a bunch of hppa fixes
<fabbione> yeah but there are no binaries
<fabbione> not until they will decide what to do with the ToolChain
<T-Bone_> k
* T-Bone_ grumbles at kernel developers that return a bare struct allocated within the function :P
<T-Bone_> Mithrandir : I think it's wouldn't be the first time RMS shows signs of mental disease ;P
* T-Bone_ ducks
<Mithrandir> T-Bone_: -private?
<T-Bone_> yeah
* T-Bone_ wanders of for lunch, bbl
* fabbione waits for the turtles to finish the kernel build
<Mithrandir> T-Bone_: if you could test the ia32-libs from Debian and make sure I haven't broken anything, I'd appreciate
<T-Bone_> Mithrandir : you mean testing Debian unstable's package on a Debian box, right?
<Mithrandir> and on Ubuntu, yes
<T-Bone_> the same package?
<Mithrandir> yes
<Mithrandir> please
<T-Bone_> ok
<Mithrandir> I want to sync it
<T-Bone_> will do, though I can't tell you when yet (i'll be doing some handwork in my DC this evening, and I might be a bit tired when I'm done ;P
<fabbione> ok
<fabbione> theoretically -1 is ready to go
<fabbione> all our arches builds/boots
<fabbione> at least.. to the best of my knowledge
<T-Bone_> eww. That doesn't mean much then 8)
* T-Bone_ ducks
* fabbione kills hppa from the kernel.. forever
<T-Bone_> bwahhaha
<fabbione> sparc wins on i386 and ppc
<fabbione> it took less time to build the kernel than the other 2 arches
* T-Bone_ watches lamont preparing plastic sticks to blow up fabbione's house 8)
<T-Bone_> fabbione : let me guess: there's nothing enabled in that kernel, you're building half as much flavours as these archs have, or what? :)
<fabbione> no.. you can just branch and maintain separate packages
<fabbione> T-Bone: same configs as before...
<T-Bone_> fabbione so you've got your hands on some awesome hardware?
<fabbione> but when ccache hits, sparc I/O > (ppc | i386) I/O
<T-Bone_> huhu
<fabbione> T-Bone: same as yesterday
<Mithrandir> fabbione: I/O doesn't matter when you've all in RAM. ;)
* T-Bone_ ^5s Mithrandir ;)
<fabbione> Mithrandir: it matters when it goes to ccache
<fabbione> all the arches didn't have the kernel in RAM
<Mithrandir> fabbione: then you have too little RAM. :P
<fabbione> Mithrandir: ppc has 2GB.. davis
<fabbione> i386 1GB
<Mithrandir> and then memory bandwidth/latency wins, which means: AMD64!
<fabbione> sparc 512Mb
<Mithrandir> :)
<T-Bone_> ewww
<fabbione> Mithrandir: i didn't mention concordia dude!
<T-Bone_> hppa has 4 to 8GB ;)
<fabbione> Mithrandir: that one beats everything
<T-Bone__> gaah, fsckin laggy connX
<fabbione> Riktig gjetta, detta er en homsekanal!
<Mithrandir> fabbione: er?
<fabbione> ahaha
<fabbione> j/K
<fabbione> doesn't that mean something like: "that's right, this is a gaysex channel!"
<Mithrandir> does
<T-Bone__> reminds me of that French teacher when i went in England during a student exchange program, who asked me the best insults he could teach his students. They were barely be able to ask for food, yet he thought swearing was more important ;P
<fabbione> Oui, vous l'avez devin. c'est un cannal de sexe homosexuel.
<T-Bone__> s/sexe//
<T-Bone__> err, s/de sexe//
<fabbione> whatever.. i don't speak french anyway
<T-Bone__> that's a chance for us ;)
<fabbione> Sonotoori.. Koko wa geisekkusu suru channeru nandayo~
<T-Bone__> LOL
<T-Bone__> not that bad
<fabbione> i know
<fabbione> we have a bot that has the same sentence translated in like 100 languages
<T-Bone__> you're copy/pasting, aren't you? You don't know japanese? ;)
<T-Bone__> you pityful l4m3 ;P
<fabbione> when somebody joins it randomically send out that sentence in the proper language according to the connecting ip
<T-Bone__> lol
<T-Bone__> am i to assume you're running a gay chan? :)
<fabbione> it's not my chan...
<fabbione> otherwise i would have written "in MY chan"
<T-Bone_> yet you're hanging on it. I wonder what your wife has to say about that ;)
<T-Bone_> you said "we". I could assume there are others like you (what a disgusting thought, though =] )
<fabbione> it's not a gaysex chan either...
<fabbione> or a sex chan :)
<T-Bone_> lol
<T-Bone_> i thought everychan was about sex somehow? :)
<fabbione> it's like somebody enters here and we say that this isn't a kernel chan
<fabbione> T-Bone_: no really.. you can't make me hot
<T-Bone_> that's ok. I don't have the IQ of an oyster you know. No need to explain me things more than once ;P
<T-Bone_> fabbione : i'm glad i can't, actually 8)
<fabbione> time for a nap
<fabbione> bbl
<fabbione> all arches are greenlight, but no upload yet
<zul> http://zulinux.homelinux.net/Archives/zulcss@gmail.com--2005/
<zul> of course the power has to go out again at home when im at work!
* zul ottawa hydro
<zul> kills even
* T-Bone_ contemplates 450 days uptime on his home MTA machine, laughs at zul ;)
<zul> fuck im cursed this week
<T-Bone_> as long as you're not coursed, everything's ok ;)
<zul> well at least im going to a hockey game tonight
* T-Bone_ is mostly doomed with buggy hardware to drive, lately. Fsckin PITA
<zul> heh
<T-Bone_> sometimes hw designers should be brought together in a psychiatric hospital to get their brains fixed :P
<zul> with a very large bat?
<T-Bone_> if nothing else's available... I was more thinking of an atomic bomb or the like...
<zul> thats a bit too harsh
<T-Bone_> i'm not quite sure it's enough, actually ;P
<zul> fabbione: ping
<T-Bone_> zul : he's having a nap ;)
<zul> ooo..
* T-Bone_ heads to uni's DC for racking-fu
<T-Bone_> see yall
<fabbione> re
<zul> hey fabbione sorry about the arch stuff i had it working last night but a power outage knocked it out this morning and i have no way of rebooting
<zul> but i see you updated it anyways
<fabbione> zul: well i had to update anyway
<zul> yeah i saw
<fabbione> because i couldn't wait any longer
<zul> yeah thats fine
<zul> but there shouldnt be any more problems from me..
<zul> but anyways how is it going?
<fabbione> it's going good
<zul> good
<zul> im going out with my mother in law tonight ;)
<zul> and i dont know why i said that
<zul> so what drivers have you not updated?
<fabbione> they are all updated
<zul> ok
<fabbione> we need to start to look at bugzilla and make a list of the ones we can import
<zul> we should have a todo list and split it up amongst ourselves 
<zul> ttps://bugzilla.ubuntu.com/buglist.cgi?query_format=specific&order=bugs.resolution%2C+relevance+desc&bug_status=__all__&product=&content=driver
<zul> this is a quicklist pass through of the drivers requested with the above url:
<zul> sk98lin    - 8937
<zul> spca5xx usb  - 2624
<zul> Wacom - 2396
<zul> acx_pci - 7160
<zul> azx audio driver - 6629
<zul> linksys wusb11 - 1534
<zul> uli526x - 3618
<zul> perc 4e - 8817
<zul> qc-usb webcam - 6145
<zul> ralink rt2500 -2570
<zul> acer hotkeys - 8628
<zul> pscax50x - 4500
<zul> wlb2011pcm - 8152
<zul> audigy 2 NX - 9068
<fabbione> zul: kernel-team@
<zul> ov511 - 8745
<zul> belkin f5d6051 - 2652
<zul> driver - bug #
<zul> ok
<kylem> spam spam spam.
<kylem> spam spam eggs & spam.
<zul> yeah so? :)
<kylem> sorry, i've a final i'm going to fail in a couple hours.
<kylem> so i'm kind of nutty. ;-)
<fabbione> ov511 and 9068 are upstream.. probably only buggy
<zul> send an email to kernel-team
<zul> now i can go back to my regularily scheduled program
<zul> holy crap its 11:30 already?
<Lathiat> zul: where do you live?
<zul> Canada
<Lathiat> am or pm?
<zul> am
<Lathiat> ah
<zul> almost time for lunch
<Lathiat> heading towards midnight here :)
<zul> signapore?
<Lathiat> perth, western australia, australia
<zul> ah
<fabbione> zul: you are lazy
<fabbione> the list is far to be completed
<fabbione> we need to go trough buzgilla manually
<zul> fabbione: it was a quick overview
<zul> no way complete
<fabbione> zul: i understand, but we need to go trough all of them :)
<zul> duh :)
<kylem> i wonder how divergent aacraid is...
<zul> fabbione: do you have a todo list or something we can have a look at?
<fabbione> zul: nope.. we need to go trough the list of all requested external/update drivers
<fabbione> and evaluate which ones to include or not
<fabbione> and get the ok once in before the first upload
<fabbione> s/once/ones
<zul> spam..
<zul> https://bugzilla.ubuntu.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=linux&component=linux-kernel-headers&component=linux-meta&component=linux-wlan-ng&component=UNKNOWN&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&resolution=DUP
<zul> LICATE&resolution=---&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
<kylem> holy crap.
<Lathiat> zul: www.tinyurl.com dudde
* fabbione larts zul
<zul> heh...this is not a good week for me ;)
<zul> http://tinyurl.com/4kn2e
<Lathiat> much better :)
<zul> via has relased some drivers for their video cards as well
<fabbione> drm?
<zul> think so
<zul> http://www.via.com.tw/en/resources/pressroom/2005_archive/pr050412_driversource.jsp
<fabbione> ENOCARE :)
<fabbione> via sucks anyway
<zul> yeah but some users still use via
<fabbione> time for them to change to some sane hw
<fabbione> :)
<zul> heh
<Mithrandir> hm
<Mithrandir> what generates the pci maps?
<fabbione> something at buildtime
<fabbione> it uses the pci_table thingy
<Mithrandir> fabbione: damn, you're useful. ;P
<fabbione> if i knew it, i was not going to ask for a patch :)
<Mithrandir> you're supposed to be the kernel god
<fabbione> i delegate some of my allmighy duties to the others
* fabbione hides
<fabbione> brb
<zul> god my ass :)
<zul> whoops...said the quiet part outloud
<fabbione> hhahaha
<Mithrandir> bah, I need more memory for my amd64 box.
<Mithrandir> only half a gig is useless for compiling shit.
<Mithrandir> a bit more than 100E for a gig more.. hmm
<fabbione> Mithrandir: keep in mind you are going to be married.. buy as much hw as you can NOW!
<Mithrandir> fabbione: nah, I don't buy hardware, I just end up with it.
<fabbione> ehehe
<zul> Mithrandir: she wont let you buy hardware anymore you have to sneak it in
<Mithrandir> zul: she's a geek too.  It's me stopping this place from overflowing ATM. :P
<zul> hehe..wanna trade? :)
* fabbione starts to take a look at GFS
<zul> nfs v4
<fabbione> zul: that is already part of our kernel..
<fabbione> at least.. we build it
<zul> bleah...nm
<fabbione> impressive.. the patches did apply without any problem
<fabbione> i wonder if it compiles :)
<Mithrandir> with the kerberos patches?
<fabbione> Mithrandir: plain GFS from RH CVS
<Mithrandir> nah, the kerberos 4 stuff
<fabbione> Mithrandir: meh.. why?
<Mithrandir> because kerberos and nfs4 is love.
<fabbione> nah...
<fabbione> GFS > *
<fabbione> nfs is boring
<Mithrandir> nfs4 is interesting
<fabbione> well i heard some stuff about it.. but never got around to actually test it
<fabbione> + i don't think it supports clustering as GFS does
<fabbione> and i am looking at the latter
<Mithrandir> I though GFS was just a good way to deadlock your kernel?
<Mithrandir> have you gotten any further on the xen stuff, btw?
<fabbione> Mithrandir: xen at the moment is no GO
<fabbione> and probably we won't be able to package images
<fabbione> not with 2.0.5 at least
<fabbione> i was talking with mjg59 and another guy in london
<fabbione> basically 2.0.5 is way to sensitive to the hw
<fabbione> it uses a microkernel to boot the real kernel
<fabbione> and they realized that it is *BAD*
<fabbione> so now they are changing the implementation
<fabbione> making the normal kernel to boot first
<fabbione> (that it is know to work)
<fabbione> and taking over at a later stage
<Mithrandir> ok
<Mithrandir> do you have any idea on ETA for it?
<fabbione> nope
<fabbione> also because they have their tree in bk :)
<fabbione> http://xen.sf.net/
<fabbione> CONFIG_FS_GFS?
<fabbione> m
<Mithrandir> hmm, the map file is made by depmod
<fabbione> yeah and it uses infos from the modules
<zul> you know what would be nice a arguement that will build only one kernel without removing the configs
<fabbione> zul: uh?
<zul> say that i only want to build a 386 kernel, so i would do something like 
<zul> dpkg-buildpackage -rfakeroot -uc -us -b 386
<fabbione> rm debian/config/{686,k7}*
<zul> and then the rules file in the debian directory would only build 386
<zul> i know but without removing debian/config/{686,k7}*
<fabbione> i know :)
<zul> something like export FLAVOUR="386" dpkg-buildpackage or something
<fabbione> zul: patch debian/rules to support it
<fabbione> i don't mind to add this stuff
<zul> or even export IMPATIENT
<fabbione> just be sure to use an ENVVAR that is not common
<zul> oh i will
<zul> i just have to figure it out
<zul> wha...
<fabbione> bah
<zul> bla
<fabbione> gfs requires another set of kernel modules just to build....
<zul> hah hah
<fabbione> at least it's all there
<fabbione> just need more crack :)
<dilinger> mm, crack
<fabbione> dilinger: you got mail
<Mithrandir> fabbione: seems like i2o_block needs to grow something like:
<Mithrandir> static struct pci_device_id i2o_block_ids = {
<Mithrandir>   { 0x1044 0xa511, PCI_ANY_ID, PCI_ANY_ID, 0x10400, 0, 0, 0, },
<Mithrandir>   { 0, }
<Mithrandir> }
<Mithrandir> MODULE_DEVICE_TABLE(pci, i2o_block_ids);
<fabbione> Mithrandir: cool.. send me the patch please :)
<fabbione> or in an email
<Mithrandir> that's a patch. :P
<fabbione> and i will add it immediatly
<Mithrandir> I'll put it in the bug report
<fabbione> Mithrandir: just an email please :)
<fabbione> ok
<Mithrandir> but my gf forces me to pack for LCA and UDU now, so I'm off
<T-Bone_> fabbione, ping?
<zul> hey T-Bone 
* T-Bone_ guesses it's too late. May Mithrandir could help, having trouble installing an U30 :] 
<T-Bone_> hey zul
<zul> too much perl can kill you
<dilinger> perl made me sterile
<zul> im pretty damn close
<Mithrandir> perl is good for you
<zul> i thought you were packing
<Mithrandir> I am
<Mithrandir> actually, I think I'm fairly done.
<Mithrandir> son now I just need to think
<Mithrandir> about what I've forgotten
<Mithrandir> good thing I'm not leaving until saturday, my luggage is only half-full so far
<zul> when is udu again?
<zul> oh you wacky italians
<fabbione> T-Bone: i doubt can be installed at the moment. we will have to wait for breezy
<fabbione> you damn Short
<fabbione> bbl
<fabbione> gotta see some wedding pics with my wife
<zul> cool...it will suck the life out of you though
* T-Bone_ guesses he'll install the U30 another day, too much a pain. Maybe the box is b0rken, even
<fabbione> zul: you are asking for it, don't you?
<zul> i was just reading about the juventus liverpool game
<T-Bone_> fabbione, actually i was planning to install debian meanwhile
<zul> right...im out of here
<zul> c ya later
<fabbione> cluster/cman/cnxman.c:1092: error: structure has no member named `sk_zapped'
<fabbione> doh!
<T-Bone_> could anyone tell me what i should put in my ia64 sources.list file; btw?
* T-Bone_ is currently at uni; finishing racking some material
<kylem> T-Bone_, http://ftp.fr.debian.org/debian unstable main
<kylem> ;-)
<T-Bone_> lol
<kylem> T-Bone_, let me grep my log to see if someone's mentioned it here.
<T-Bone_> thx
<fabbione> s *.ko
<fabbione> gfs.ko
<fabbione> crack!
* T-Bone_ is almost done. machines are up, SCSI arrays are up, needs some cable cleansing love and it'll be done
<T-Bone_> too bad i can't get that U30 to work ;)
#ubuntu-kernel 2006-04-17
<bitwiseshiftleft> question: on amd64 emulating i386, is there a sigaction syscall?
<jbailey> all the i386 syscalls should be emulated.
<bitwiseshiftleft> ok.  so i should #define __NR_sigaction to... what?
<bitwiseshiftleft> 67?
<bitwiseshiftleft> (I'm trying to compile wine and it's failing for lack of an __NR_sigaction
<bitwiseshiftleft> )
<bitwiseshiftleft> well, anyway, thanks
<zul> heylo
<BenC> lamont: I thought we fixed the elilo prompting
<lamont> BenC: dunno - it's because of the existance of /etc/$LOADER.conf (grub doesn't have one...)
<lamont> that was a fresh dist-upgrade from breezy+security to dapper
<Keybuk> BenC: ping
<fabbione> Keybuk: it's like 2 am in BenC's land .)
<fabbione> :)
<Keybuk> bah :p
<fabbione> you are up early today...
<Keybuk> trying to get back to a sensible sleep pattern
<dilinger> 2am :(
<fabbione> ** Warning: "spi_populate_ppr_msg" [drivers/scsi/aic7xxx/aic7xxx.ko]  undefined!
<fabbione> *** Warning: "spi_populate_width_msg" [drivers/scsi/aic7xxx/aic7xxx.ko]  undefined!
<fabbione> *** Warning: "spi_populate_sync_msg" [drivers/scsi/aic7xxx/aic7xxx.ko]  undefined!
<fabbione> *** Warning: "spi_populate_ppr_msg" [drivers/scsi/aic7xxx/aic79xx.ko]  undefined!
<fabbione> *** Warning: "spi_populate_width_msg" [drivers/scsi/aic7xxx/aic79xx.ko]  undefined!
<fabbione> *** Warning: "spi_populate_sync_msg" [drivers/scsi/aic7xxx/aic79xx.ko]  undefined!
<fabbione> BenC: ^^ this is today's git
<fabbione> (i386)
<fabbione> BenC: please pull from my branch when you can
<fabbione>   Changes by Fabio M. Di Nitto
<fabbione>   * Pull updates from David S. Miller sparc branch to fix some smp issues.
<fabbione>   * Make IOSCHED deadline default on -server* configs (x86 and x86_64).
<zul> heylo
<zul> BenC: ping you havent updated the git tree in a while im afraid i might be out of sync.
<BenC> zul: you're right, I'll push in just a bit
<zul> okie dokie thanks
<fabbione> hey BenC 
<BenC> hey fabio
<fabbione> BenC: mind to pull from me and push?
<fabbione> i have the same issue as zul
<BenC> ok
<fabbione> i did config changes that i fear are going to conflicts
<zul> heylo
#ubuntu-kernel 2006-04-18
<dholbach> it'd be nice if some of you showed up in #ubuntu-bugs - so people having questions for kernel bug triage have somebody to ask
<dholbach> hey masters of the kernel!
<dholbach> it'd be nice if some of you showed up in #ubuntu-bugs - so people having questions for kernel bug triage have somebody to ask
<zul> heylo
<dholbach> hey zul - happy hug day!
<zul> heh has anonyone from the kernel team showed up?
<dholbach> benc is there now
#ubuntu-kernel 2006-04-19
<sn9> where is everybody?
<crimsun> asleep; Good Friday/Easter; etc.
<sn9> um, nobody was here through most of Thursday, either
<crimsun> are you referring to [bh] ug day?
<crimsun> the team is fairly decentralised and doesn't keep regular hours
<sn9> nah, just noticed no activity in the channel since i looked in. seems a little unusual even for this channel
<crimsun> nah, it's actually fairly normal :)
<sn9> i was in here for long periods before, and it's never been this quiet
<sn9> have there been more mentions of powermac sound driver problems with the tumbler chipset
<sn9> ?
<crimsun> aside from the usual bugs being filed, no
<crimsun> commit 4a15236e94cddd33c96b829b3b1722c62c453b89
<crimsun> Date:   Wed Apr 5 12:49:02 2006 -0400
<crimsun> [UBUNTU:sound/ppc]  Revert tumbler portions of my patch.
<sn9> hmm. has this fix made it into the daily kernels?
<crimsun> it's already committed; I don't know if he has additional ones in his local tree
<sn9> ok, so a -21 kernel will definitely have it, right?
<crimsun> (2.6.15-20.31) UNRELEASED;
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: I have a bug report where ACPI-PNP is grabbing ioports belonging to an SATA controller, and breaking things in -20 (works in -19)
<BenC> pnpacpi=off fixes it
<BenC> any ideas what to look for?
<mjg59> Uhm.
<mjg59> Which ports?
<mjg59> And which driver ends up grabbing them?
<BenC> https://launchpad.net/malone/bugs/38688
<BenC> pnpacpi is claiming them cold, no driver, marking them as some sort of resource
<BenC> output of ioports is near the bottom
<BenC> dmesg snippets are in comments
<mjg59> Hrm.
<mjg59> The contents of /sys/bus/pnp/devices/00:06/ would be helpful
<BenC> ok
<zul> heylo
<jbailey> zul: Enjoying your day?
<zul> jbailey: yeah went to see a movie with the wife, and trying to upload stuff to universe but doesnt seem to be working, how is yours going?
<jbailey> zul: Good.  I've been playing with Minix the past week, and am now submitting things and askign questions.  THey claim they want to work with the community, let's see if they're telling the truth. =)
<zul> hehe..
<zul> scarey movie 4 was ok btw
<zul> i had a nap as well today
<zul> uh oh...my wife is on a cleaning binge
<Yagisan> zul: mine is also acting odd this easter
<zul> Yagisan: it must be something in the air
<Yagisan> zul: or hormonal
#ubuntu-kernel 2006-04-20
<zul> heh...yeah...i have to go help now...bbl
<zul> heylo
#ubuntu-kernel 2006-04-21
<zul> heylo
#ubuntu-kernel 2006-04-22
<zul> heylo
<zul> that ipw3945 driver is a pain in the ass
<fabbione> better your than mine ;)
<fabbione> (ass)
<zul> heh...thanks...how was your easter..
<fabbione> zul: okish
<fabbione> i had fever so i didn't do really much
<fabbione> just a bit of hacking around
<zul> cool..i had the anti-catholic easter...i did everything you are not suppose to do
<zul> friday didnt go to church, forked(), and went to a movie, saturday casino, sunday did go to church though
<fabbione> ehhehe
<BenC> FYI, kernel upload later today
<zul> okie dokie...ipw3945 is a pain in the ass
<BenC> yeah, that's why I haven't touched it yet :)
<zul> i have...and its a pain the ass..
<zul> did you include the patch i sent yesterday to the kernel-team list?
<BenC> yeah
<mjg59> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=582b6edc5ed531456a9cd2f88c53ba7c4da44fea looks really wrong
<mjg59> F.12 is a BIOS revision
<mjg59> It's just the 12th revision for a machine
<mjg59> Which means several different BIOSes will hit that
<zul> thats from upstream
<mjg59> Still sounds massively wrong
<mjg59> Did it come up on LKML?
<zul> actually it was from 2.6.16 in linus tree
<mjg59> Hm
<mjg59> Crack
<zul> gimme a a sec i can find it in his git tree
<mjg59> Thanks
<zul> that f.12 was me
<zul> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8c4b2cf9af9b4ecc29d4f0ec4ecc8e94dc4432d7
<mjg59> Heh, ok
<mjg59> A better looking patch for this stuff turned up on lkml last week
<mjg59> Hang on
<mjg59> http://lkml.org/lkml/2006/4/14/45
<mjg59> ^ that one seems to be a better solution
<zul> ok ill see what i can do tonight
<zedd_> I have dapper drake (flight 5) installed and I want to recompile the kernel image that was originally installed.  Which kernel package should I get:  linux-source  or linux-source-2.6.15?
<zedd_> sorry -  I meant Flight 6 is installed.
<crimsun> zedd_: linux-source-2.6.15
<zedd_> crimsun, I've got that, but when I copy /boot/config-2.6.15-20-amd64-generic to /usr/src/linux/.config and do 'make oldconfig', the compile breaks on a USB WLAN driver
<crimsun> you enabled a/the usb wlan driver?
<zedd_> no. I am just using the base config that dapper drake came with...  
<zedd_> for 2.6.15-20-amd64-generic
<zedd_> i want to re-create the kernel that was installed
#ubuntu-kernel 2006-04-23
<BenC> zedd_: apt-get build-dep linux-source-2.6.15
<munzir> Hi, I downloaded http://cdimage.ubuntu.com/dvd/20060411/dapper-dvd-amd64.iso and it gave me a root prompt after this error: kernel direct mapping tables upto ffff810100000000 @ .... can't access tty; job control turned off.
<munzir> can I do anything other than downloading another image?
<jmg> hi all
<jmg> https://launchpad.net/distros/ubuntu/+source/kernel-package/+bug/39948/+index
<jmg> straight to the top
<jmg> :)
<jmg> hi ppd
<ppd> hi! If somebody could give me a hint for what package I should file a bug for, I'd be very thankful: Whenever I record TV (bttv -> Leatek Winfast TV2000 XP) via streamer it may happen that the xserver simply restarts oder even the whole system freezes. I got several segfaults in other programs after that. the xserver runs with nvidia. May this be bttv related?
<ppd> hi jmg
<jmg> ppd: could be, are you using v4l?
<jmg> oh bttv... hmm
<ppd> I think so
<jmg> ppd: probably userspace.. kernel panic?
<ppd> overlay mode worked once but doesn't anymore. another mystery
<jmg> bizarro
<jmg> possibly best to file against nvidia-glx? does it happen with nv?
<ppd> that streamer issue?
<jmg> yeah
<jmg> segfault sounds fun
<jmg> any kernel panic/oops?
<ppd> panics? no. just either a freeze or a xserver restart
<ppd> the whole tv watching/recording thing doesn't work well
<jmg> can you sysrq?
<jmg> or ssh in form another machine?
<jmg> from*
<ppd> sysrq?
<jmg> magic sysrq key
<jmg> sysrq-k 
<ppd> ok
<ppd> If I get that freeze again I'll use that key combination. But what shall I do if only the xserver restarts?
<jmg> read the log output, dmesg
<jmg> try and get debugging info from the xserver
<jmg> strace output
<ppd> ok.
<ppd> hi jmg
<ppd> I had a complete freeze after having set zapping to overlay mode
<ppd> I was completely unable to save the dmesg output
<fabbione> ppd: remove nvidia and check if it is still aproblem.
<fabbione> a tained kernel with binary drivers is undebuggable
<ppd> ok. back in a minute
<fabbione> jmg: could you please stop posting bugs in here..?
<fabbione> do you know that our kernel-package already had xen?
<jmg> fabbione: did you know that it needs to be updated to support 3.0.2? ARCH=xen is no longer a valid target
<fabbione> and that the new series in debian (10.X) was almost rewritten from scratch and that what they are doing is readding things from 0?
<fabbione> ah ok
<jmg> i was afraid of that.
<fabbione> well anyway dapper+1 business
<jmg> manoj did it for me for etch
<jmg> i'll compare his approach with ubuntus
<fabbione> it's still a wishlist..
<jmg> tbh when i looked at it my first instinct was to rewrite the whole thing in rake
<jmg> fabbione nonsense
<fabbione> we can't sync kernel-package from Debian
<jmg> ill support it myself if i have to
<jmg> ok
<jmg> thanks
<fabbione> kernel-package is specific to the kernel build system
<jmg> i know what kernel-package is
<fabbione> and we can't rework our build system to just use debian one
<jmg> okay
<fabbione> so a sync is not doable
<fabbione> but
<jmg> the xen stuff is doable
<fabbione> if you can workout a patch on top our kernel-package
<jmg> yeah thats what im looking at tomorrow
<fabbione> then it is easier to get it in
<jmg> but i hate makefiles
<jmg> and i want to rewrite it all to rake
<jmg> rather than deal with makefile voodoo
<fabbione> have fun with that
<jmg> no
<jmg> it is a horrible task
<jmg> a meaningless task
<jmg> makefiles are just such rubbish
<jmg> i suppose i could start from scratch though
<jmg> :-)
<jmg> yay
<jmg> ...
<zul> heylo
<makx> fabbione: you once added an klibc sparc patch patch
<makx> he has no desc and no changelog entry
<makx> i would like to get it pushed upstream
<makx> if you can remember which bug you were hunting that would be great
<makx> fabbione: speaking of 03-sparc-fix-paths.diff
<makx> in klibc source
<ppd> hello again.  nvidia-glx seems to cause my problems
<ppd> with nv overlay mode works perfectly and the recordings are far better
<ppd> no error so far
<jmg> what needs to happen is we need to support a subarch of i386 called xen
<jmg> ppd: i knew it, post about it in nvidia forums..
<zul> mmmm.....placenta http://www.mirror.co.uk/news/tm_objectid=16958010%26method=full%26siteid=94762%26headline=exclusive--tom-chews-name_page.htm
<jmg> make-kpkg --arch i386 --subarch xen
<jmg> --arch i386 target is not affected
<zul> isnt it a bit late in the release cylce for xen?
<jmg> zul: yes but i want to support it seperately when dapper comes out (not in main)
<jmg> not even when dapper beta comes out :)
<zul> still i dont think there is much you can do about it right now
<jmg> zul: not in the main make-kpkg it sounds like :(
<jmg> zul: i will provide an alternative to make-kpkg
<jmg> zul: since ubuntu-kernel are not willing to support xen at this time
<jmg> thanks a
<jmg> thanks all*
<zul> jmg: knock yourself out
<jmg> zul: converting the makefiles to rake seems like a good waste of time to me
<jmg> zul: and a pointless rdepend of rake sounds like fun too
<jmg> http://arch.debian.org/cgi-bin/archzoom.cgi/srivasta@debian.org--etch/kernel-package--devel--9.0--patch-143?log
<fabbione> makx: i don't remember.. let me check
<fabbione> makx: oh that one.. man dude... if you need an explanation for that one...
<fabbione> but yes.. it should go upstream
<fabbione> assuming new upstream still need it
<fabbione> BenC: what can we do to help you hunting down #34065 ?
<BenC> fabbione: I need some sort of scsiparm or smart output on these things so I can see what I am looking for
<fabbione> BenC: sure...
<fabbione> tell me exactly what cmd line you want 
<fabbione> or otherwise send me your ssh key :)
<makx> fabbione: yeah bash me :-P
<makx> ;)
<BenC> hdparm -I /dev/sda > hdparm.txt
<BenC> Also: hdaparm -C /dev/sda
<BenC> Also, see if "hdparm -S 0 /dev/sda" disables the spindown
<fabbione> BenC: people.u.c/~fabbione/hdparm.txt and hdparm2.txt
<fabbione> yes i can try that too
<fabbione>  setting standby to 0 (off)
<fabbione> and disks did spin up again
<fabbione> i will be able to see if they stop again later
<BenC> your sda is in standby mode
<BenC> and hdh is active/idle
<BenC> standby may be a default mode
<BenC> this may require that the ubuntu-server metapackage (or whatever it is) sets -S 0 for all drives
<fabbione> hdh is not idle because i am downloading stuff on it :)
<fabbione> and we need to get this fixed n the kernel
<BenC> makes sense :)
<fabbione> it's a regression from .12 
<fabbione> i can't even think of how much time it would take to my system to boot if i had to issue hdparm -S 0 /dev/ for the 34 scsi disks in the SAN
<fabbione> because i got a SAN up and running..
<zul> a couple of minutes :)
<Mithrandir> you can probably do that in parallell though?
<fabbione> well we know what's the IOCTL
<fabbione> can't we just check why the default has been changed in the kernel? or why it did start spinning down all of a sudden?
<fabbione> Mithrandir: yes but come on.. 
<fabbione> what about hotplugged devices
<fabbione> this has to be something more dinamyc than just boot
<BenC> fabbione: One thing you can test is -21, since it pulled in some libata-acpi stuff that might help with this
<BenC> does it only affect sata?
<fabbione> nope also normal ATA
<Mithrandir> fabbione: udev rule, then
<fabbione> it's kind of scary to hear a raid5 spinning down and up
<BenC> fabbione: doing it at boot wont take that long since all the disks will be spun up already
<BenC> guessing it will take all of 5 seconds at most
<fabbione> why don't we just fix where it should be fixed? :)
<fabbione> also
<fabbione> there is one major thing
<fabbione> how do we tell the boot that it is a server install?
<fabbione> or server boot?
<fabbione> such a change will go into desktop too
<BenC> isn't there a -server metapackage?
<fabbione> nope
<fabbione> there is no need of one
<BenC> there should be :P
<zul> Yippe Skippe... https://lists.ubuntu.com/archives/dapper-changes/2006-April/009446.html
<infinity> zul: Is that your first upload to the archive?
<zul> yep..
<infinity> Congrats.
<zul> thanks..
<zul> you love me you really love me ;)
<fabbione> zul: now... move your bottom on -motu and starts to fix universe instead of pretending to be a kernel hacker. kthxbye.
<zul> :P
<zul> yes mommy
<fabbione> makx: i was just waiting for hpa to show up on irc :)
<fabbione> but that will do too
<makx> fabbione: ok thx, sorry have no idea about those sparc assembly so my desc was stumble-stumble
<fabbione> makx: it's fine. it's nothing to do with sparc asm.. just Kbuild that required a kick
<makx> fabbione: yup, looked like not building it. :)
<ath> hi everyone
<ath> i'm asking for some help in resolving a kernel bug in dapper
<ath> malone bug 31527
<ath> it affects the kernel side of DRI and it results in a complete system crash
<ath> a vanilla 2.6.15 works fine
<makx> fabbione: sam has a better fix, i would appreciate if you give it a build shot, otherwise i just push into the next debian upload
<fabbione> makx: i just powered down all the sparcs for the evening
<fabbione> makx: well he is also commenting on the chmod that's not coming from our patches...
<fabbione> but yeah i can give it a shot
<ath> well, thanks anyway
<makx> fabbione: yes he reworked the sparc/Makefile.inc
<fabbione> yes i saw the patch
<makx> patch will not apply to unstable klibc due to s/ARCH/KLIBCARCH/
<fabbione> yes i need to test it on git
<allen> Would this be the proper place to ask a question regarding the latest kernel on amd64. 2.6.15-19-amd-k8 worked fine for me but my system doesn't boot with 2.6.15-20-amd64-k8. 
<allen> I've been running Dapper for a while and it seems every 2nd or 3rd kernel doesn't boot on my system, I end up running an older version until a newer one starts working.
<mjg59> BenC: We still don't seem to have the 3945 driver?
<BenC> mjg59: working on it right now
<mjg59> BenC: Rocking
<BenC> ok, ipw3945 is in git now
#ubuntu-kernel 2007-04-16
<rpereira>  Hi, I updated my desktop with Feisty RC and I'm getting on booting: "Error 17: Cannot mount selected partition". What can I do?
<crimsun> which kernel is this?
<rpereira> I updated 2 hours ago.
<crimsun> so, -15.27? Can you verify?
<rpereira> I know is 2.6.20-15
<rpereira> How can I verify if it isn't booting at all?
<crimsun> boot from a desktop cd, chroot, dpkg -l linux-image-2.6.20-15-generic
<rpereira> OK.
<rpereira> I will do it.
<rpereira> Which version is working?
<crimsun> -15.27 WFM, but I don't have affected hardware
<rpereira> OK.
<rpereira> I will keep my notebook kernel for security reasons.....
<rpereira> I'm burning the CD, so wait some minutes please.
<rpereira> crimsum: 2.6.20-15.27
<rpereira> crimsun: 2.6.20-15.27
<rpereira> crimsun: kernel 2.6.20-15.25 works with this computer.
<crimsun> which mass storage controller(s) do you have?
<rpereira> If I install on chroot, will I have a problem?
<crimsun> at this point, the regression from -15.25 is what's interesting.
<rpereira> OK. Mu mass storage controller is: product: 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE
<rpereira> Driver:  driver=ata_piix
<rpereira> Do you need another info?
<crimsun> lspci -vvn
<crimsun> should be identical to mine
<kylem> dmesg is what we need
<rpereira> kylem: how do I get dmesg with the defectuous kernel?
<kylem> photograph it or something?
<rpereira> But when I use the defectuous kernel, my computer get stucked on grub with message: "Error 17: Cannot mount selected partition"
<crimsun> I've resorted to writing dmesg in the past. Not fun, but certainly feasible.
<rpereira> I think that I found the error....
<rpereira> At least my computer error.
<rpereira> When I'm installing a kernel with my CD using chroot and dpkg -i linux-image.... I got the error:
<rpereira> findfs: Unable to resolve 'UUID=XXXXXXXXXXX...XXXXXX'
<rpereira> Cannot determine root device. Assuming /dev/hda1
<rpereira> This error is probably caused by an invalid /etc/fstab
<rpereira> That was the error... Sorry for so much pasting...
<rpereira> My sda1 is my /home
<rpereira> The UUID printed is correct, but my / partition is hda3.
<rpereira> So my /etc/fstab is corrected.
<rpereira> I just had to manually change the root on "/boot/grub/menu.lst" from (hd0,1) to (hd0,2).... And I don't hava any problems anymore with kernel 2.6.20-15.27.
<rpereira> s/hava/have
<rpereira> Summarizing: The problem is with the auto generation of grub menu.lst file.
<pokoko> rpereira, why use UUID in the first place ?
<pokoko> rpereira, just delete the UUID
<pokoko> is there donkey kong available for ubuntu. :P
<rpereira> I do not use it. Some time on updating Ubuntu change from /dev/sdaX to UUID...
<pokoko> ok ok.
<pokoko> :)
<lamont> so if I have a generic headless P2-233 machine doing server-esque stuff, do I want -server or -generic or -686, I wonder?
<rpereira> crimsun: did you got my messages?
<crimsun> rpereira: sorry, was away. Yes, I just read scrollback.
<crimsun> so the kernel is fine, which is a relief, but the upgrade somehow broke?
<rpereira> Yeap.
<rpereira> Maybe it is the post-instalation script or grub (if it was upgraded).
<rpereira> crimsun: Please report this to kernel team (if you're not part of kernel team), my battery is dying.... :-) Thanks for your help.
<kylem> lamont, a p2? -generic
<lamont> kylem: yeah - iz glorified printer server
<lamont> state of the art about the time you were born... :-)
<lamont> oops.  ECHAN
<rajlinux> Hi, I am searching for any article describing the serial driver layer changes from Linux kernel 2.4 to 2.5..can anybody help me?
<crimsun> please see LWN.net archives.
<rajlinux> I cant find there
<rajlinux> is there any other place to search?
<rajlinux> there was one serial.c file in 2.4 and now there is one drivers/serial directory with more than 10 files.. I want to how it was divided..
<drago> Hi, does anyone working on bug abt /proc/kcore ?
<cjwatson> Nafallo: being unable to sync with Debian is unfortunate, but not a totally overriding concern
<cjwatson> and if we ask nicely it's possible that Debian might add the epoch too
<Mithrandir> morning, Colin
<heno> Any views on bug 106864? It was reported during testing of 20070415, the latest images. It's different from the sata_nv problems that were fixed, but still looks like a regression.
<heno> bug 106864
<Mithrandir> ubotu isn't in here
<cjwatson> heno: too little information to be able to diagnose; I've posted a message requesting more information
<heno> cjwatson: ok, thanks. almost seems like a bad disk, but ideally the kernel should cope, no?
<cjwatson> I see no reason to infer a bad disk from that
<zul> g'day
<gortiz> hi zul
<mdz> kylem: this VMWare performance issue has now been confirmed by Keybuk
<mdz> kylem: I'm guessing it's something to do with the PIIX driver changes
<kylem> hmm, bug #?
<kylem> i'll take a look
<mdz> kylem: hadn't reported it yet since I thought it was a problem with this PC
<mdz> kylem: installing current dailies in vmware with ubiquity takes much, much longer than it did before
<kylem> any idea which day it changed? :\
<kylem> (approximately)
<mdz> kylem: yes, I mentioned it in this  channel
<mdz> let me find the log
<mdz> kylem: first noticed 12 April ~16:56 BST
<kylem> ok, thanks.
<kylem> could i get a dmesg from one of the booted vmware instances?
<mdz> kylem: yep
<kylem> awesome.
<mdz> kylem: http://people.ubuntu.com/~mdz/temp/dmesg
<kylem> thanks.
<mdz> default vmware config for Ubuntu (SCSI disk, ATAPI CD-ROM)
<Keybuk> mdz: http://people.ubuntu.com/~scott/dmesg.vmware-live
<Keybuk> (booting the Live CD)
<mdz> Keybuk: 403
<Keybuk> fixed
<mdz> Keybuk: is not
<Keybuk> err
<Keybuk> fixed harder
<cjwatson> pkl_: can you help kyle with this? kyle has been doing pretty long hours lately. :)
<pkl_> Ok
<pkl_> Keybuk: fixed for me (403 err)
<kylem> hm, do you recall offhand if prior to the slow down it was using libata for the cdrom (so it would have been scd0?)
<cjwatson> pretty sure vmware was using ata_piix before
<mdz> kylem: no, I don't
<Keybuk> let me grab a beta CD and compare
<kylem> Keybuk, thanks.
<Keybuk> downloading...
<kylem> i don't see how this could drop the performance though, this driver is what would have been using for years pevious
<mdz> I have a beta install in vmware already
<mdz> kylem: maybe the new driver made things much faster?
<kylem> hrm.
<mdz> I can see the difference just booting the live CD
<mdz> comes up much quicker
<mdz> kylem: do you not have vmware locally?
<mdz> kylem: yes, beta used scd0 and ata_piix
<mdz> kylem: is it possible to force ata_piix in current feisty to test?
<Keybuk> how come we reverted from libata to ide for that driver?
<mdz> Keybuk: because the new one was fucked
<kylem> no, we reverted for pata_amd...
<mdz> keybuk: bug 96857
<pkl_> Pre-moving over to libata (-12 kernel), the cdrom driver would resumably have been this driver?
<pkl_> s/resumably/presumably/
<kylem> mdz, oh.
<Keybuk> so we broke vmware to fix qemu?
<cjwatson> as kyle says, vmware probably used to use piix
<cjwatson> can somebody boot dapper and/or edgy to test? my vmware box is doing other things at the moment
<cjwatson> Keybuk: weren't you seeing ATA errors in vmware too?
<cjwatson> that was one of the rationales for reverting IIRC
<Keybuk> cjwatson: I was seeing lots of messages, yeah -- but it did at least work
<cjwatson> if it worked, why was it being brought up as an issue near release time?
<pkl_> keybuk: it works now, but slowly?
<Keybuk> I brought it up quite a long time before release time :)
<pkl_> before libata, the piix driver would have been used for both CDROM and hard-disks?  Now libata is being used for hard-disks, and piix for CDROM.  If I understand correctly?
<kylem> in the case of vmware, we're using a virtual scsi disk for hard disk
<kylem> argh, Stanislaw and Dmitry hijacked that bug with an unrelated issue.
<mdz> pkl_: we're using SCSI hard disks, which is the default
<cjwatson> pkl_: vmware gives you the option of selecting SCSI (BusLogic or LSILogic) or IDE
<Keybuk> http://people.ubuntu.com/~scott/dmesg.vmware-beta
<mdz> cjwatson: the error messages were sufficiently scary that it didn't seem wise to ignore, even if it appeared to work
<mdz> I don't see the errors with beta, and performance is good there
<pkl_> OK.  I've never used vmware :)  So the virtual scsi disk isn't handled by libata anyway?  Just the CDROM that was handled by piix, then libata, and now piix again?
<mdz> pkl_: that's my assumption, yes
<cjwatson>     - 96857: Broken PIIX support, mostly showed under emulation. This
<cjwatson>       affected qemu, kvm and vmware. All of which have an emulated PIIX
<cjwatson>       IDE chipset. The disk would work fine, but CDROM support would
<cjwatson>       not. Resolved by reverting back to piix.ko (IDE) for Intel PIIX
<cjwatson>       pata chipsets. Piix.ko is much more tested and stable.
<mdz> if all we did was switch to the same driver we were using before, I have no explanation for the performance regression
<cjwatson> as a reminder, that was Ben's rationale
<mdz> cjwatson: yes, Ben said he had reports of it actually not working
<pkl_> Could the slow down be completely unrelated?
<mdz> though we weren't able to reproduce them in our setups
<cjwatson> he also explained by phone that it affected some older hardware
<mdz> pkl_: there is always that possibility, yes
<Keybuk> pkl_: SCSI doesn't need to go through libata ;)
<mdz> pkl_: do you know of any other changes which may have caused it?
<Keybuk> beta was using ata_piix, today is using piix
<mdz> pkl_: did we pull a libata update post-beta?
<mdz> Keybuk: yeah, just pondering that
<mdz> so beta had neither performance problems nor errors with ata_piix
<cjwatson> this suggests that piix has regressed seriously since dapper/edgy/whatever, and that we just haven't noticed it since not enough people are using piix any more
<mdz> yet we reverted to piix to fix the errors?
<Keybuk> mdz: confirmed
<Keybuk> cjwatson: regressed since *beta*, not edgy or dapper!
<mdz> Keybuk: beta used ata_piix, it may have had this piix problem
<cjwatson> beta was using ata_piix so the piix module's behaviour is not known
<pkl_> mdz:  I don't know of any changes.  I'll check when the Squashfs update went in, though that shouldn't be causing any issues.
<cjwatson> libata update went in post-beta
<Keybuk> ah, good point
<Keybuk> sorry
<mdz> pkl_: this problem began around 12 april
<cjwatson> pkl_: squashfs update didn't make final
<Keybuk> brain was unsuccessfully on two tracks there
<cjwatson> it's in git head but not in the branch that actually landed for release
<Keybuk> errors in ata_piix was regression between feisty beta and today
<pkl_> cjatson: there was an update from Squashfs 3.1 to 3.2-r2 that did go in...
<Keybuk> speed of piix is regression between dapper/edgy and unknown before today
<pkl_> this keyboard is playing up... missing characters.
<cjwatson> oh, right, I thought you meant squashfs setpageerror
<cjwatson> fair point, that could be implicated
<cjwatson> can we get lspci -vvnn from vmware, qemu, kvm, parallels?
<cjwatson> it would be useful to know if vmware has different pci ids from the others, in which case the adjustment will be obvious
<mdz> http://people.ubuntu.com/~mdz/temp/lspci-vmware
<mdz> cjwatson: ^^
<mdz> 00:07.1 IDE interface [0101] : Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111]  (rev 01) (prog-if 8a [Master SecP PriP] )
<cjwatson> ok, that's PCI_DEVICE_ID_INTEL_82371AB
* cjwatson grabs the qemu source to xref
<Keybuk> when did the reversion happen, btw?
<cjwatson> -15.23
<Keybuk> my laptop is running 15.27 and has ata_piix loaded, not piix
<mdz> BenC: good morning
<BenC> mdz: hey
<BenC> rough weather here last night...power went out like 6 times
<cjwatson> Keybuk: yes it's only for a few pci ids
<kylem> mdz, can you past the next line? (the subvendor line)
<cjwatson> five, I think
<mdz> kylem: URL above
<pkl_> parallels (MBP) 00:1f.1 IDE interface [0101]  Intel Corporation 82801BA IDE U100 [8086:244b] 
<kylem> sorry, missed that, thanks mdz
<BenC> did I wake up in the middle of a kernel crisis?
<kylem> ok, we want to match on subvendor/subdevice if this is something we want to fix.
<cjwatson> qemu is 8086 7010 I think
<cjwatson> which is PCI_DEVICE_ID_INTEL_82371SB_1
<pkl_> subsystem: Intel corporation unknown device [8086:4541] 
<cjwatson> so qemu and vmware at least are using different piix drivers, which offers an obvious possibility
<mdz> BenC: at least a potential crisis
<cjwatson> BenC: serious cdrom performance regression in vmware apparently since the ata_piix to piix reversion
<mdz> BenC: do you remember when I mentioned I had slowdown problems in vmware, and was trying to blame it on the host machine or vmware itself?
<cjwatson> I'm wondering if we blatted back more than we needed to
<mdz> BenC: Keybuk reproduced it in his vmware as well
<Mithrandir> how about we just roll a test image with that single re-re-re-reverted?
<cjwatson> I don't like just reverting this because it fixed several potential problems
<BenC> the bad thing about ata_piix was the exceptions on the cdrom
<cjwatson> has anyone checked qemu lately?
<cjwatson> or kvm, with current images?
<BenC> cjwatson: I had several people confirm qemu working
<BenC> I can test kvm real quick
<mdz> BenC: we discovered that those appeared sometime after beta
<mdz> BenC: beta works with ata_piix just fine without errors and with good performance
<BenC> mdz: right, they happened after the drivers/ata/ sync with libata-dev stable
<cjwatson> the libata updates weren't done for fun though - they fixed other problems, right?
<BenC> right
<BenC> mainly they enabled DMA for pata
<BenC> which I believe is the source of the exceptions on ata_piix for ATAPI devices
<Mithrandir> mdz: check if dma is enabled on your emulated cd drive?
<BenC> but disabling DMA for ATAPI in ata_piix would probably get us the same problem that you are experiencing now
<mdz> Mithrandir: it is, in both cases
<mdz> checked that
<BenC> note, we've got near zero changes to drivers/ide/ compared to stock 2.6.20
<BenC> only thing of note is ide-acpi
<cjwatson> BenC: it's sounding like piix performance has regressed compared to 2.6.17 or so, whenever we were last using piix for vmware systems
<BenC> you can disable that with a module param, I can find it if you want to test it
<mdz> BenC: when did we switch from piix to ata_piix?
<BenC> mdz: for some PCI id's we've been using it since dapper, I believe
<BenC> edgy a few more were moved, and for feisty we ended up switching all of them, all based on what upstream was doing
<cjwatson> BenC: 8086:7111 is the ID in question
<BenC> so it's been a gradual change
<BenC> that one would be one of the last to change
<BenC> that's why it was part of the 5 moved back to piix during our Great Kernel Fixing Extravaganza
<BenC> let me copy a feisty image over and test kvm real quick
<BenC> also need to disconnect my generator so I can switch power back to the barn for possible builds
<poningru> quick question
<poningru> why does the kernel get symlinked to /?
<poningru> and the init image as well
<cjwatson> historical
<poningru> any particular historical reason?
<poningru> like sysv spec or something?
<cjwatson> it's been like that forever on certain architectures (NOTE not all) and we've never got round to the faff of moving it
<poningru> ah hmm
<poningru> does deb also follow this?
<cjwatson> yes, we inherited it from Debian
<poningru> cool thanks mate :)
<cjwatson> specifically arm, hppa, powerpc, s390, and sparc put it in /boot instead
<cjwatson> it also depends somewhat on the boot loader
<poningru> hmm I know grub can load from any place
<poningru> oh right ppc have their own dont they
<poningru> ok I see what you are saying
<cjwatson> there are lots and lots of complications particularly when a separate /boot is involved
<cjwatson> so moving the symlink must be done carefully
<BenC> poningru: also /etc/kernel-img.conf is what tells it to do so
<cjwatson> right, set up by base-installer (d-i) or the live filesystem build script (ubiquity)
<poningru> hmm ic
<poningru> assuming kpkg will do this for you automagically?
<Keybuk> herd-1 took 1:32.6
<mdz> BenC: you have a local vmware, right?
<BenC> ws6
<BenC> I'll try it and kvm
<Keybuk> herd-2 took 1:59.3
<Keybuk> herd-3 took 1:22.1
<Keybuk> herd-4 took 1:29.2
<BenC> cool, I have -15.27 images rsync'd already
<mdz> BenC: do you see the same problem with ws6, or no?
<BenC> getting ready to test
<BenC> had to copy it to the laptop
<Keybuk> herd-5 took 1:28.7
<Keybuk> (all of those were using piix)
<Mithrandir> and current is ?
<mdz> hmm, so it switched between herd-5 and beta
<Keybuk> Mithrandir: current is booting ;)
<Mithrandir> ok
<Keybuk> mdz: we switched to ata_piix between herd-5 and beta, afaict
<Keybuk> and switched back between beta and today
<mdz> Keybuk: that's what I just said
<mdz> BenC: so what changed in piix since beta, if anything?
<BenC> mdz: nothing
<mdz> weird
<pkl_> what kernel rev did Herd5 use?
<BenC> 2.6.20 stable, from what I remember
<BenC> wait, I might be wrong about piix changes from upstream...
<Keybuk> current is 3:02.7
<Keybuk> piix clearly changed between herd-5 and current
<mdz> something affecting it did, at least
<BenC> nope, there isn't
<BenC> piix is exactly the same as 2.6.20 except out PCI id allocation
<BenC> s/out/our
<Keybuk> beta (with ata_piix) booted in 1:59.5
<mdz> interesting, so still slower
<mdz> ata_piix was slower than the old piix, and new piix is slower than that
<BenC_> that was ugly
<BenC_> ws6 locked me up solid
<cjwatson> me> the host?
<BenC> yeah
<BenC> no caps lock, no ping, nothing
<BenC> let's give qemu a try
<Keybuk> beta booting with piix
<mdz> BenC: what about ide-cd? anything different there?
<BenC> -#define VERBOSE_IDE_CD_ERRORS 1
<BenC> +#define VERBOSE_IDE_CD_ERRORS 0
<BenC> that's our only diff between upstream
<BenC> and that patch has been in since dapper
<BenC> or even breezy
<Keybuk> beta (with piix) booted in 1:57.1
<BenC> Keybuk: what kernel is in herd 5 and beta?
<Keybuk> beta with piix is notably quite perky
<BenC> ah, so piix isn't broken in beta?
<Keybuk> icons appearing instantly
<Keybuk> etc.
<BenC> what kernel is in beta?
<BenC> cat /proc/version_signature
<Keybuk> (I'd put down the slightly slower boot to lack of readahead update before it, since hal/gdm were reordered)
<Keybuk> 1.5x isn't "bad" ... 3m is bad
<Keybuk> 2.6.20-12-generid
<Keybuk> BenC: Ubuntu 2.6.20-12.20-generic
<mdz> Keybuk: did you try current with ata_piix?
<BenC> ok, thanks
<Keybuk> BenC: would a new_id force current with ata_piix ok?
<BenC> Keybuk: yes
<Keybuk> it should just modprobe though, right?
<mdz> BenC: how can I generate a diff from 2.6.20-14.22 to current using git?
<Keybuk> (ie. claim if I just load the driver, without needing to force)
<BenC> The ONLY changes from 2.6.20-12.20 and our current code in ALL of drivers/ide/ is the piix PCI id moving we've done
<BenC> mdz: git-diff-tree -p Ubuntu-2.6.20-14.22..HEAD [paths]  > foo.diff
<BenC> if you exclude a path, you'll get everything
<BenC> mdz: drivers/ide has changed since before beta
<BenC> except for the PCI id's
<cjwatson> has changed => has not changed?
<BenC> has not
<BenC> correct
<Keybuk> BenC: err, doesn't seem to be forcing it
<BenC> Keybuk: did piix load already?
<BenC>  generic.c |    5 -----
<BenC>  piix.c    |   19 ++++++++++++-------
<BenC> that's the diffstat for beta to now in drivers/ide
<Keybuk> no
<BenC> the generic.c change  was actually to revert it back to stock (jmicron bug that delayed beta)
<BenC> err, that should have delayed beta :)
<BenC> we missed it for that milestone
<BenC> Keybuk: I can't see how it wouldn't
<pkl_> does anyone want me to test parallels for the slowdown?
<pkl_> I don't think parallels got the piix reversion? BenC?
<BenC> pkl_: it should have
<Keybuk> I tried echo -n 0000:00:07.0 > bind as well, that didn't go either
<BenC> shouldn't it be "ven dev", not ven:dev?
<Keybuk> that's bind
<Keybuk> I did echo 8086 7111 > new_id
<BenC> oh, right, I get those mixed up
<Keybuk> it don't like binding :)
<Keybuk> maybe I need to force libata instead?
<BenC> ata_piix is the one that has the PCI probe callbacks and device table
<Keybuk> ah right
<Keybuk> isn't playing anyway
<Keybuk> mdz: NOT A CRISIS: http://lwn.net/Articles/229690/
<mdz> Keybuk: thanks
<BenC> I'm going to give ws6 a try again...wish me luck
<Nafallo> BenC: gl
<Nafallo> :-)
<BenC_> wont be trying this again
<BenC_> maybe my 64-bit vmware doesn't like 32-bit CD's
<pkl_> BenC: with the latest kernel (built Sun Apr 15), parallels is still using libata for hard disk.  CDROM gets exception Emask blah blah
<BenC_> maybe I should disable it from using vmx too
<BenC_> pkl_: ven/dev for your chip?
<pkl_> BenC: how do I get the exact kernel version (rather than the Uname 2.6.20-15-generic).  Is there a Debian package query?
<kylem> pkl_, /proc/version_signature
<BenC_> pkl_: cat /proc/version_signature
<pkl_> Thanks, -15.27.  I put the ven/dev earlier, but I'll paste it again
<pkl_> parallels (MBP) 00:1f.1 IDE interface [0101]  Intel Corporation 82801BA IDE U100 [8086:244b] 
<pkl_>  subsystem: Intel corporation unknown device [8086:4541] 
<BenC> pkl_: Boot with break=top, at the prompt, modprobe piix
<BenC> exit, and see if things continue along happily
<pkl_> OK
<mdz> cjwatson: do we have any dailies from before 20070412?
<mdz> any isos at all?
<Keybuk> (you'll get some dmesg after the modprobe if it worked)
<mdz> BenC: if this isn't a piix regression, do you have any theories?
<BenC> mdz: let me check drivers/block/
<BenC> nope, nothing there either
<kylem> BenC, check block/ too
<BenC> ah, right
<BenC>  0 files changed
<pkl_> BenC: yeah, that worked fine.  Cdrom recognised okay (obviously).
<mdz> drivers/block has only ps3_storage.c changed
<BenC> pkl_: can you check the apparent performance?
<cjwatson> mdz: not unless they got released
<cjwatson> we simply don't have disk space to keep them - in fact I've been pondering keeping them for one fewer day for a while
<mdz> cjwatson: are you aware of any other changes which could have affected this?  toolchain?  livefs build process?  buildd machines?
<BenC> http://people.ubuntu.com/~bcollins/since-beta.diff
<BenC> that's the diff of the entire tree since beta
<mdz> I've looked over that
<pkl_> OK
<mdz> as has Keybuk
<mdz> we didn't spot anything out of sorts
* Keybuk is reading -changes atm
<mdz> except that it's enormous, of course
<cjwatson> the only close-to-relevant CD build change I know of is that I dropped the hw-detect/start_pcmcia=false workaround
<cjwatson> doesn't affect the live CD at all though
<BenC> Keybuk, mdz: either of you tried vmware under windows host, to make sure the slow down isn't host side?
<Keybuk> the host didn't change between the tests though?
<Keybuk> and I've seen this on widely different hosts
<BenC> ok, I'm going to have to go on the assumption that this isn't IDE/libata/DMA/piix/ata_piix related
<BenC> so that leaves general performance problems
<mdz> BenC: my host has been running dapper
<BenC> the only way to prove otherwise is to bisect the kernel, always using piix driver, and see if that makes any difference
<mdz> any other theories? anyone?
<BenC> my vmware seems busted at the moment, but I guess I could get a ws5 image/lic real quick and start testing
<mdz> anything goes at this point
<Mithrandir> BenC: or run an old kernel in a new image.
<mdz> BenC: that would be a good idea
<Keybuk> what's this "ACPI Drive" stuff?
<Keybuk> oh, it's in ata/
<BenC> anyone tried disabling ide acpi yet?
<BenC> hold a sec...
<Keybuk> is i810 relevant?
<BenC> hmm...what video is it using?
<BenC> have all these tests been done with livecd, or any alternate testing?
<Keybuk> just livecd
<BenC> well, any video it's using most likely isn't using agp/drm, so there's no changes that should affect it
<Keybuk> I'm installing a beta image, to test pure CD IO performance
<Keybuk> was wondering whether the video dma changes could've mucked up IO dma
<BenC> ide=noacpi is something else to try
<BenC> break=top, modprobe ide-core ide=noacpi
<mdz> +Starting balanced_irq
<Keybuk> BenC: no particular acpi changes
<mdz> BenC: what's that?
<BenC> probably has to be done that way
<BenC> mdz: acpi is the only notable things in our drivers/ide/ that is not in upstream
<mdz> BenC: what's balanced_irq?
<BenC> mdz: it balances irq's on SMP systems
<BenC> so other than just the first CPU can handle IRQ's
<BenC> there was some updates to it to handle multi-core/shared cache a lot better
<BenC> but I thought it was in universe
<kylem> it is
<kylem> i never put it in a MIR for it.
<kylem> (since it was post-beta)
<mdz> so it does nothing without the userspace bits installed?
<BenC> anyone have a quick download for ws5 so I don't have to do this email song and dance?
<mdz> (apart from mentioning itself in dmesg)
<mdz> BenC: I have a copy here
<mdz> can upload it to the DC quick
<BenC> mdz: ah, balanced IRQ in kernel, it does some trivial balancing, but nothing major
<mdz> BenC: ~mdz on chinstrap
<mdz> ETA 5 seconds
<BenC> mdz: thanks
<BenC> need coffee and a smoke, and few minutes to ponder things at this point
<BenC> afk for about 10
<Keybuk> hmm, beta is STILL installing!
<BenC> one thing I didn't check is changes in pci quirks that might affect piix
<mdz> I can't get anything approaching reproducible numbers by timing raw /dev/hdc or /dev/scd0 reads in vmware
<mdz> so far our only test cases are booting the live CD and installing in ubiquity
<BenC> hmm, changes in combined mode
<BenC> but that affects only Intel SATA I think
<BenC> splits the pata drive off the combined sata/pata chipset into a separate func
<BenC> then  there's MSI, and toshiba/sis quirks
<BenC> let me do this ws5 install and try to reproduce so I'm at least working with you guys
<BenC> mdz: do you have fixed tarballs for the module source for vmware?
<BenC> or do these build ok?
<mdz> BenC: not on me
<mdz> they wo'nt build, the fix is all over google though
<BenC> I forget the name of the update file, do you remember it?
<BenC> got it
<Keybuk> whatever the line that fails, comment it out
<BenC> I can't get the key I pulled from wiki to work
<Keybuk> did you pull it from the new page, instead of the old?
<Keybuk> it was under Montreal/VMware or something
<BenC> yes, the ones marked March 2007 + 180
<BenC> one of the keys didn't work, another one did
<BenC> I'll not it on the wiki
<BenC> ffs, the any-any gave me bad modules versions
<mdz> BenC: is this the same machinew here you have ws6 installed? maybe they can't coexist peacefully
<BenC> I uninstalled ws6 first
<BenC> any-any was too old for this ws5
<BenC> so fixing the module source manually
<Keybuk> ok, beta is STILL copying off the damned CD
<Keybuk> (that's with ata_piix ...)
<kylem> Keybuk, can you disconnect a fucked cdrom by booting the installed image in vmware and trying to do heavy i/o off another cd?
<kylem> er, discount, not disconnect
<Keybuk> how do you mean?
<Keybuk> we can't get useful timings from the real cd
<BenC_> dear vmware, please stop crashing my system
<Keybuk> since vmware's clock invents numbers
<Keybuk> and a stopwatch gives different answers too
<BenC> anyone tried switching the cd to SCSI instead of IDE to see if that makes a difference?
<Keybuk> not yet, am still waiting for this one to install
<Keybuk> at which point I can have the VM back for a bit <g>
<BenC> I'm going to install vmware on this other machine to see if I can get it to work
<cjwatson> has bug 106864 come up on this channel already?
<cjwatson> it's unfortunately not too clear what's going on, only fragments of error messages
<cjwatson> the comments from Arjan Kon are probably a different bug, but have more detailed results
<kylem> looks like he fell to initramfs.
<BenC> looks like the exceptions are ata_piix related
<Keybuk> "oops, I tripped, and fell, and landed initramfs"
<BenC> same as we saw in vmware
<Keybuk> yeah they are the same
<cjwatson> exceptions> Arjan's, right?
<Keybuk> so, err
<BenC> cjwatson: yeah
<Keybuk> how do you get vmware to boot off an emulated scsi cd-rom?
<BenC> Keybuk: the CDROM pref page for the VM should let you select IDE or SCSI
<BenC> it did for me at least
<Keybuk> yes
<Keybuk> but how do you boot off it?
<Keybuk> the bios doesn't seem to support that
<BenC> uh, it should I guess
<Keybuk> why?
<Keybuk> you normally can't boot off scsi cdroms
<Keybuk> not if there's a boot image on a scsi drive with a lower id
<BenC> Keybuk: doesn't vmware have a Boot menu in bios?
<Keybuk> yes
<Keybuk> PC BIOS can only boot off things like IDE, remember
<Keybuk> so "SCSI" tends to be a boot option :p
<Keybuk> (booting current with piix and ide=noacpi didn't help)
<BenC> if the SCSI controller does the right BIOS setup, then the BIOS shouldn't care that it's a SCSI drive
<BenC> s/drive/cdrom/
<pkl_> BenC: I got the requested performance figures for LiveCD booting for a number of daily build vintages.  No apparent slowdown in performance in Parallels from 20070301 builds to latest 20070415 build off hard-disk and real CD.
<pkl_> tested 20070301, 20070313, 20070411 and 20070415 :)
<mvo> could some please check https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/103050 ? if its valid, it looks rather serious
<BenC> mvo: what is module wfb?
<mvo> BenC: I have no idea, but it seems that the report claims that "nvidia-glx-config enable" adds it and its part of the nvidia binary package
<mjg59> It's an X module, not a kernel one
<mjg59> Is it in the package? If not, is it in the source package?
<BenC> looks legit, so we may need to add it as part of the nvidia-glx-new package
<BenC> mvo: I've taken it on
<mvo> BenC: thats great, thanks a lot!
<BenC> Keybuk: weird that they let you make it a SCSI device and don't let you boot from it
<BenC> so what's our guage for this bug?
<BenC> I just got to desktop after power on in less than 2 minutes with current livecd
<pkl_> Parallels takes 1:01 (iso on hard disk), no performance problems.
<pkl_> with latest livecd
<Keybuk> BenC: try and install
<BenC> starting an install for a more thorough test
<BenC> system is using piix right now
<BenC> note I'm on a 64-bit intel core2duo install, 32-bit vmware ws5
<BenC> oh wait, no, it's a 64-bit Turion x2
<Keybuk> I've seen the same on a dual 64-bit athlon x2, sata_nv etc.
<Keybuk> BenC: what can we do to help you debug this
<Keybuk> since performance in vmware is our prime feature for Ubuntu Server 7.04, this is of showstopper grade
<BenC> ahci on the host
<Keybuk> ?
<BenC> my host for vmware is using achi, was just checking that
<BenC> guest is using piix
<pkl_> BenC: vmware running on what?
<BenC> Keybuk: At the moment, I'm unable to reproduce any real performance issue
<Keybuk> both mdz and I are
<BenC> Turion x2
<Keybuk> it took well over an hour to install here
<BenC> Keybuk: what's your host you've been testing with now?
<Keybuk> ICH7
<Keybuk> intel core duo
<BenC> piix or ata_piix for disk?
<BenC> I assume the latter
<Keybuk> ata_piix
<BenC> is a 1 hour install really that bad for a virtualized install?
<mvo> here is another nvidia-glx releated error: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/106518/ (not sure we can/should do anything, seems to be caused by the "envy" tool
<Keybuk> BenC: yes, given we've specifically press released that we have improved performance in vmware! :)
<BenC> mvo: Nope, reject that one, we can't do anything about people clashing local installs with package installs
<mvo> BenC: will do, thanks
<BenC> Keybuk: how long does edgy take to install?
<Keybuk> BenC: 10-15 mins max
<pkl_> BenC: you said vmware is prime feature for Ubuntu Server 7.04... But, what vmhost host oses are you concerned with.  I was going to try vmware under MacOS X (in Beta), but if vmwarte host on Linus all you're concerned with, I won't bother.
<BenC> I don't recall ever getting an install that fast
<Keybuk> feisty took 60-90 mins (I got so bored I did other things)
<Keybuk> BenC: I can appreciate that you can't replicate the problem
<BenC> pkl_: we are promoting our guest speed, so any host should be good
<Keybuk> so what can mdz do to help you understand it?
<Keybuk> mdz and I
<BenC> Keybuk: I can't replicate your 10-15 minutes installs with edgy is the problem :)
<Keybuk> BenC: how long do they take for you?
<BenC> Keybuk: and besides, our "speed feature" is only in relation to ws6 and related products where paravirt is enabled
<BenC> Keybuk: about an hour
<Keybuk> the press release doesn't say that :-/
<BenC> the press release is quite lacking in information that I've provided then
<Keybuk> what kind of VM did you use?
<BenC> "Improved performance with as a guest under VMware using paravirtual ops"
<BenC> Keybuk: I've been using ws6 for quite some time, in beta
<Keybuk> this is 256MB / 8.0GB ide / CD-ROM bound to file / 2 processors
<BenC> haven't used ws5 in awhile...I think I have edgy around here I can test on now that I have a ws5 install
<Keybuk> didn't you just say you tested on ws5?
<BenC> Keybuk: I did all default, so 256Meg, 8G, CDROM to file, single CPU
<BenC> Keybuk: I just tested a feisty RC on ws5
<Keybuk> and it booted in around 1m30?
<Keybuk> with no noticeable lag drawing the desktop?
<BenC> yep
<Keybuk> weird
<BenC> the install is 15 minutes in, and at around 47% copying files
<BenC> ruh roh
<BenC> power may be going
<BenC> if I drop, it may be 20-30 minutes before I get gen up and running
<BenC> Keybuk: let's get some info out here to compare why things are slow for you and mdz and not for me
<BenC> mdz is running on a dapper host
<BenC> mdz: what sort of machine is it?
<BenC> video, hd, etc.
<BenC> Keybuk: one thing I didn't do on my VM was setup networking...so that's a datapoint right now
<BenC> Keybuk: have you tried single cpu yet?
<BenC> for guest
<Keybuk> doing a dapper install now
<Keybuk> to test
<Keybuk> yeah, single cpu was same problem
<Keybuk> I tried double to see whether that fixed it
<cjwatson> I'll give you a third data point at some point after dinner
<BenC> is nvidia-glx-new on the CDs?
<mdz> BenC: I've only been able to test on this dapper amd64 box
<BenC> mdz: is it running 32-bit or 64-bit on host?
<mdz> BenC: did you compare with beta, or with ws6?
<BenC> and are you testing 32-bit or 64-bit guest?
<Keybuk> 32-bit guest on 32-bit host for me
<mdz> BenC: it's running a 32-bit kernel
<mdz> 32-bit guest
<Keybuk> (same problem seen with 32-bit guest on 64-bit host)
<mdz> just happens to be a 64-bit cpu
<BenC> I have 64-bit host, but 32-bit ws5 and 32-bit guest
<BenC> so it _should_ be the same
<Keybuk> I assume my 64-bit host was a 64-bit ws5, since it can host 64-bit images
<BenC> mdz: can you really get 10-15 minute installs of edgy?
<mdz> BenC: and were you able to measure a difference from beta->rc?
<Keybuk> (how does one tell?)
<Keybuk> BenC: I'm half way through a dapper install, 9m gone, 9 to go
<mdz> BenC: I can do one right now and time it...
<BenC> Keybuk: I think guest support is only limited by kernel/vmmon, so it might still be a 32-bit vmware
<BenC> Keybuk: file /usr/local/bin/vmware
<BenC> see if it's elf 32 or 64
<BenC> let me get an edgy iso to see if I can get this super speed install
<Keybuk> 54%, 6:08 remaining
<mdz> (edgy boots the live CD in 1:07 fwiw)
<Keybuk> /opt/vmware/vmware: Bourne shell script text executable
<Keybuk> <>
<BenC> can you guys check your bogomips between edgy and feisty?
<Keybuk> /opt/vmware/lib/bin/vmware: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
<Keybuk> ok
<Keybuk> BenC: inside vmware or outside?
<BenC> Keybuk: ok, same as me then
<BenC> Keybuk: in vmware
<Keybuk> that's in dmesg right?
<BenC> or /proc/cpuinfo
<Keybuk> [   18.818982]  Calibrating delay using timer specific routine.. 2403.75 BogoMIPS (lpj=4807513)
<Keybuk> ^ cupprent
<Keybuk> [   49.406032]  Calibrating delay using timer specific routine.. 2380.15 BogoMIPS (lpj=4760307)
<Keybuk> ^ beta
<mdz> ubuntu@ubuntu:/mnt/var/log/installer$ sudo grep ubiquity syslog |head -1
<mdz> Apr 12 13:11:25 ubuntu ubiquity[6131] : Ubiquity 1.2.5
<mdz> ubuntu@ubuntu:/mnt/var/log/installer$ sudo grep ubiquity syslog |tail -1
<mdz> Apr 12 13:27:11 ubuntu ubiquity: Purging configuration files for libglibmm-2.4-1c2a ...
<mdz> ^^^ 6.10 final
<Keybuk> [17179573.224000]  Calibrating delay using timer specific routine.. 2406.73 BogoM
<Keybuk> IPS (lpj=4813470)
<Keybuk> ^ dapper
<mdz> ubuntu@ubuntu-desktop:/var/log/installer$ sudo grep ubiquity syslog |head -1
<mdz> Apr 16 09:46:25 ubuntu ubiquity[8750] : Ubiquity 1.4.11
<mdz> ubuntu@ubuntu-desktop:/var/log/installer$ sudo grep ubiquity syslog |grep glibmmApr 16 10:11:20 ubuntu ubiquity: Removing libglibmm-2.4-1c2a ...
<mdz> ^^ current feisty
<mdz> so 16 minutes vs.  25
<BenC> mdz: so feisty took 25 minutes to install and edgy took 16?
<mjg59> What's the difference on real hardware?
<mdz> unknown, I just had those numbers around
<mdz> the real difference I saw was between the 11th and 12th
<mdz> both in vmware
<mdz> unfortunately we've deleted those isos
<BenC> mdz: was that perhaps when we went from piix to ata_piix?
<mdz> BenC: yes
<mdz> er
<mdz> no, the other way around
<mdz> from ata_piix to piix
<Keybuk> dapper install finished: 21 mins
<BenC> how could you notice a problem when ata_piix wasn't even working for you?
<BenC> s/problem/slow down/
<BenC> wasn't working for atapi at least
<BenC> or did you notice a general problem in an existing system when we did the switch
<BenC> existing VM that is
<BenC> Ok, edgy iso booted in about the same amount of time for me
<BenC> starting the install
<BenC> wow, I think my guest clock just went backwards
<Keybuk> they do that
<BenC> I could have sworn I saw it go 1:48 to 1:47, then to 1:48 again
<Keybuk> I like mdz's demo that sleep 10 sleeps for an amount of time that will never equal 10s
<BenC> I'll watch the host clock
<Keybuk> a watched clock never boils
<BenC> hopefully, neither does an unwatched one :)
<mdz> BenC: the clock is very funny, I don't really trust those numbers in syslog
<mdz> BenC: ata_piix was functional for me, it just spewed a huge volume of scary errors while it worked
<BenC> mdz: even for atapi it worked?
<mdz> I'm open to the idea that Keybuk and I are both hallucinating
<mdz> BenC: yes, I was only using it for atapi
<BenC> hmm
<mdz> I use the standard default ubuntu config in vmware, which is a SCSI (LSI) HDD and ATAPI (PIIX) CD-ROM
<mdz> but while I'm open to the idea, someone needs to independently demonstrate that we're crazy
<mdz> because so far our results are consistent with each other
<BenC> my boot times for edgy/feisty under vmware are only off by a few seconds...they are virtually (heh) the same
<BenC> the install times I'm checking now
<Keybuk> which feisty?
<mdz> BenC: booting the CD or booting from HDD?
<BenC> latest ISO, 15.27 kernel
<BenC> mdz: booting the live CDs
<mdz> BenC: ok, that's very interesting
<Keybuk> so, I'm trying a random test
<BenC> this clock skew on vmware really worries me
<Keybuk> booting different livecds and moving 8GB from a SCSI disk to an IDE disk and back again
<BenC> it's already 6 minutes ahead of my host
<mdz> BenC: I see that too, though I think I probably always have
<BenC> mdz: I'd say the syslog times you pasted are probably bad data points for this
<Keybuk> maybe vmware is going so fast, it's slowing down time
<Keybuk> (and thus installs)
<BenC> mdz: any chance you can do installs and check your host times for comparison?
<mdz> BenC: I agree
<mdz> but Scott's are wall clock timings
<cjwatson> I'm going to do a test in a second
<Keybuk> ie. I timed it with a stopwatch
<cjwatson> however this is on a Debian host as I've never migrated that vmware install
<mdz> cjwatson: my host has been neutral throughout; I don't suspect any problem on the host side
<cjwatson> Keybuk: from pressing enter at the CD boot prompt, or from vmware boot?
<BenC> cjwatson: hard to muddy the water any more than it is  :)
<BenC> cjwatson: I did CD prompt to icons showing up
<Keybuk> cjwatson: from pressing ^D at break=top after manually loading piix and making sure it was bound
<cjwatson> FWIW, I'm on 5.5.1
<BenC> Keybuk: on -15.27 kernel feisty, piix most certainly is bound
<BenC> for beta iso's, you need the break
<BenC> for installs, I'm timing from the last screen in ubiquity to the "restart" dialog
* BenC watches vmware go back 9 minutes in time
<mdz> 5.5.2 build-29772 here
<kylem> amd64?
<mdz> and BenC's using my tarball
<mdz> kylem: amd64 running 32-bit kernel/userland/guest
<cjwatson> feisty boots in 1:28
<kylem> sorry, i should say "athlon64"
<kylem> i mean, is it an amd chip
<mdz> yes
<BenC> see, colin's getting what I'm getting for feisty
<kylem> dual core amd has unsynched tsc.
<mdz> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
<cjwatson> will take a few minutes for edgy to copy across from my server
<kylem> so if vmware is using the tsc to get the clock, it will flip back and forth and lose (or gain) ticks
<BenC> mine is turion x2 as well
<Keybuk> my vmware clock always runs slower than my host clock
<cjwatson> mine is single-core Athlon64
<Keybuk> and it's a dual-core Intel
<cjwatson> fairly old, summer 2004 I think
<BenC> Keybuk: weird, on this box, mine always runs faster :)
<BenC> so Keybuk is the only one testing on an Intel host right now
<kylem> hmm
<BenC> but we have UP and SMP covered
<BenC> ok, wall clock time on my edgy install was 15 minutes
<cjwatson> that's from pressing Install button on summary page to final dialog appearing?
<pkl_> Ubuntu in Parallels also runs slower than the host clock.
* Keybuk is still waiting for the feisty CD to book
<Keybuk> boot too
<BenC> cjwatson: yes
<cjwatson> (feisty took a weirdly large amount of time to get to usplash, btw - maybe 20 secs)
<pkl_> which is Intel obviously.
<cjwatson> edgy boots in 0:52
<cjwatson> unfortunately I don't have feisty beta handy - will take c. 2 hours to download
<BenC> so noticeably slower, but possibly due to more services?
<cjwatson> kicked off a download
<cjwatson> I think most of that was the pre-usplash delay
<BenC> I need to do these boot tests on a real machine between edgy/feisty
<cjwatson> which could easily have been something kooky in initramfs
<BenC> unless someone else wants to do it
<cjwatson> why don't I kill the beta download to avoid stray i/o and do install time tests
<mdz> there's really no need to mess with edgy
<mdz> the difference can be seen from beta->rc
<BenC> I don't  have beta handy
<cjwatson> yes, but I have edgy here and not beta
<BenC> but I guess I can download it
<cjwatson> the need to mess with edgy is getting results now instead of in two hours
<mdz> but the results may not be particularly meaningful
<cjwatson> absence of regressions from edgy is meaningful enough to me
<Keybuk> mdz: ish, beta does take a long time to install for me :-/
<Keybuk> edgy is worth testing
<Keybuk> and is equally worthwhile
<Keybuk> if we can get a definitely reproducible useful test, we can track forward
<Keybuk> more than "boot time"/"install time"
<cjwatson> anyone tried bonnie++ or similar?
<cjwatson> pre-usplash delay> oh, I bet that's console-setup
<Keybuk> BenC: interesting timing here
<cjwatson> though it should be working with pregenerated files
<Keybuk> hdparm -t on an IDE disk in vmware
<Keybuk> dapper: 1800 MB/s
<cjwatson> so I don't quite get why it would be so slow
<Keybuk> current: 750 MB/s
<BenC> oooh
<BenC> Keybuk: is it reproducible many times?
<Keybuk> yes
<Keybuk> the numbers are pretty consistent
<BenC> worry about the guest clock skewing things
<mjg59> hdparm -T is probably more realistic
<Keybuk> yeah, given the guest clock skew, that's unconfirmed
<cjwatson> -T doesn't measure throughput to the disk though?
<Keybuk> mjg59: 75 MB/s vs. 35 MB/s
<cjwatson> it's a more realistic system test, but the disk controller driver is the suspect component here ...
<mdz> cjwatson: it's been difficult to do benchmarking inside the VM because the clock is fucked
<BenC> there's gotta be a way to do this
<cjwatson> something that took a stopwatch-measurable amount of time to do each test would be good enough
<BenC> vmware was doing micro and macro benchmarks reliably
<mjg59> cjwatson: -t is also testing the vm system
<Mithrandir> cjwatson: for i in `seq 20`; do dd if=/dev/hda; done and using a stopwatch should work.
<Keybuk> mjg59: "performance problems in vmware" could also be the vm system, though I doubt it
<cjwatson> -T does buffer cache which doesn't seem especially useful or relevant
<Keybuk> Mithrandir: dd to where?
<Mithrandir> Keybuk: /dev/null?
<cjwatson> in particular it explicitly says "without disk access"
<mjg59> Oh, sorry - I had those the wrong way round
<mjg59> Though the timings would seem more consistent with them being the way I thought...
<cjwatson> mm
<mdz> cjwatson: I believe that means 'without physical disk reads' not 'without communicating with the disk'
<mdz> oh, I'm wrong
<cjwatson> mdz: in context, it's talking about buffer cache and says it deliberately avoids measuring disk performance
<mdz> "This displays the speed of reading directly from the Linux buffer cache without disk access."
<cjwatson> comparison from my laptop:
<cjwatson>  Timing cached reads:   814 MB in  2.00 seconds = 406.48 MB/sec
<cjwatson>  Timing buffered disk reads:   84 MB in  3.01 seconds =  27.89 MB/sec
<kylem> that would make sense.
<cjwatson> edgy installs in <9:47 (I wasn't looking at the screen and that's when I noticed; it wasn't much less)
<Keybuk> Mithrandir: 3:41.1 in feisty current
<Mithrandir> Keybuk: ugh.
<Keybuk> oddly enough, vmware's clock matches stopwatch there
<Mithrandir> hmm
<cjwatson> Keybuk: how big a disk?
<Keybuk> 8GB
<cjwatson> oh, and fragmented or solid?
<cjwatson> (whatever you call the non-fragmented thing - single-file?)
<Keybuk> 2GB chunks
<Mithrandir> preallocated?
<cjwatson> yeah
<Keybuk> not actually allocated though
<Keybuk> since the disk is "empty"
<Keybuk> so this shouldn't touch the host disk hardly at all
<cjwatson> I have limited disk space so I always use chunks
<BenC> feisty install is definitely noticeably slow for me than edgy
<BenC> 12 minutes into it, and it's only at 50%, still copying files
<cjwatson> will tell you my result there in a moment
<BenC> guess I better get beta
<BenC> mdz, Keybuk: so beta was ok, and current is slow, that's your test case right now?
<Keybuk> BenC: I have my doubts about beta
<Keybuk> current is definitely slow
<BenC> ah, right, beta was still slow for you
<mdz> I don't get consistent results from hdparm at all, which is unsurprising to me given the clock skew
<mdz> BenC: beta is better here
<Keybuk> wall time on dapper for the dd test, 02:39
<mdz> I installed dailies in vmware all last week, and noticed the difference on thursday
<mdz> but I am at a loss to provide particularly believable numbers
<BenC> mdz: do you have the same dailies around?
<mdz> BenC: nope
<mdz> they were deleted over the weekend, while I was dealing with my hosed laptop
<BenC> mdz: given a kernel image just before the ata_piix/piix switch, can you regen an ISO from current using that image?
<mdz> BenC: that should be possible, yes
<kylem> http://www.vmware.com/vmtn/resources/238
<BenC> 14.22 was just before the switch
<BenC> damnit, the .deb's are gone from lp
<cjwatson> err, shouldn't be
<kylem> for the broken one they were nuked, no?
<cjwatson> I'll find them
<cjwatson> not from the librarian, no
<kylem> ah.
<cjwatson> they're just hard to find
<cjwatson> you have to go to the "builds of" portlet
<cjwatson> http://librarian.launchpad.net/7122345/linux-image-2.6.20-14-generic_2.6.20-14.22_i386.deb
<BenC> great, ws5 killed my other box now
<BenC> flashing led's
<cjwatson> feisty installs in 8:44 (I think, pressed the wrong stopwatch button)
<BenC> a lot faster than mine
<cjwatson> not willing to say it's definitely faster than edgy, but given the lack of attention in my experiment it's definitely within experimental error
<cjwatson> I'll try the dd test with fresh disks in a moment
<mdz> BenC: they still seem to be there to me: https://launchpad.net/+builds/+build/315769
<cjwatson> I think Ben was following the links from linux-source-2.6.20/2.6.20-14.22 to the individual binaries rather than to the builds
<BenC> yeah
<BenC> anyone have the piix dev id for vmware handy?
<cjwatson> Keybuk: how many dd iterations was your 3:41.1 timing above?
<cjwatson> BenC: 8086:7111
<BenC> thanks
<kylem> 06:31 < mdz> http://people.ubuntu.com/~mdz/temp/lspci-vmware
<kylem> BenC, you'll want subvendor/subdevice too if you're going to blacklist it from one of the modules.
<BenC> force probing ata_piix with new_id
<Keybuk> cjwatson: just one
<BenC> see if the install is any faster
<cjwatson> about 2:50 for the dd test, 50.6 MB/s according to vmware's clock which seems more or less right
<cjwatson> Keybuk: did you try dd from the cdrom?
<Keybuk> cjwatson: that's what I'm trying now
<Keybuk> still waiting for current to boot
<cjwatson> 'cos my timing is not all that far off yours
<heno> FWIW, I just did a virtualbox install here that too 11 minutes total, the CD-HD copying phase was just 7 minutes; will do Edgy next
<cjwatson> feisty dd if=/dev/hdc of=/dev/null: 33 seconds
<Keybuk> 1430344+0 records in
<Keybuk> 1430344+0 records out
<Keybuk> 732336128 bytes (732 MB) copied, 115.963 seconds, 6.3 MB/s
<Keybuk> (hdc -> null on dapper, 5x that one's pretty representative, there wasn't much deviation)
<cjwatson> quite a lot slower
<cjwatson> oh, dapper? hmm
<cjwatson> unused to your machine just sucking compared to mine ;-)
<Keybuk> it's only a laptop
<cjwatson> ah
<cjwatson> thought it was the 10-second booter or whatever it was
<Keybuk> nah, that's at home
<Keybuk> far too heavy to lug on skates
<cjwatson> edgy dd hda: 1:23, twice as fast as feisty
<mdz> cjwatson: wallclock time?
<cjwatson> yes
* BenC kicks new_id
<Keybuk> I must admit, that my wall clock and my vmware clock match
<cjwatson> mine too
<mdz> Keybuk: you're uniprocessor
<Keybuk> I've worked out why vmware's clock is different, it ran ntpdate ;)
<mdz> both of you are
<Keybuk> mdz: dual core
<Keybuk> just intel not amd
<cjwatson> edgy dd hdc: 28 seconds, smidge faster than feisty
<cjwatson> that explains why install tests showed no difference, the CD hasn't changed much
<Keybuk> ok, that was interesting
<Keybuk> let me just repeat that test before I say about it
<cjwatson> mm, I'm going to repeat my dd tests too
* cjwatson stops bothering with the stopwatch
<Keybuk> I just stopped bothering
<Keybuk> and then noticed something
<Keybuk> in feisty my wall clocks *are* different to vmware's clocks
<Keybuk> in dapper they matched
<BenC> bah, ata_piix doesn't support hotplug of controllers
<BenC> wish there was a way to atomically add new_id during module init
* BenC considers binary patch the driver in initramfs
<Keybuk> hmm, dd giving comparable results for me too
<heno> complete Edgy install on virtualbox: ~7.5 minutes, the CD->HC copying phase less than 5 minutes. So Edgy is significantly faster than Feisty on virtualbox too
<BenC> heno: what's the time for feisty on vbox?
<dholbach> BenC: <heno> FWIW, I just did a virtualbox install here that too 11 minutes total, the CD-HD copying phase was just 7 minutes; will do Edgy next
<BenC> those times can be accounted for by things other than a kernel bug, I think
<BenC> interesting, but still inconclusive
<mdz> heno: which driver is used for the CD-ROM there?
<BenC> heno: thanks for the testing
<BenC> IIRC, it's piix as well, probably same 8086:7111
<BenC> is it at all possible that these times could be squashfs related?
<heno> mdz: can you tell me how to find out?
<mdz> heno: lspci -vvnn | grep IDE
<mdz> BenC: the squashfs update was much earlier, no?
<mdz> pkl_: any reasonable potential for a performance regression there?
* Keybuk is trying if=/dev/hdc of=/dev/sda1
<pkl_> the squashfs update was checked in on 16th Mar.  It doesn't appear in the debian/changelog and so I don't know what daily first had it.
<BenC> how can it not show in the changelog?
<BenC> it's automated :)
<BenC> that's odd
<BenC> if we go by dates, then it had to be either in -12.19 or -12.20
<Mithrandir> you don't have it tagged in git?
<cjwatson> (speaking of which, can we lose the GIT-SHA lines from debian/changelog in gutsy? anyone who needs them can get them from git log)
<mdz> BenC: it's not there
<mdz> cjwatson++
<cjwatson> commit 01c7ecb34704df7feae2532006169786642f8fdd
<cjwatson> Author: Phillip Lougher <phillip@gandalf.(none)>
<cjwatson> Date:   Fri Mar 16 14:02:58 2007 +0000
<cjwatson> UBUNTU: Squashfs: update to 3.2-r2
<cjwatson> Signed-off-by: Phillip Lougher <phillip@ubuntu.com>
<mdz> makes it much harder to scan the changelog
<BenC> yes, I can that :)
<Keybuk> ok, interesting
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/linux/ubuntu-feisty>$ gzip -9c debian/changelog | wc -c
<cjwatson> 79301
<cjwatson> (also)
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/linux/ubuntu-feisty>$ grep -v GIT-SHA debian/changelog | gzip -9c | wc -c
<cjwatson> 63093
<Keybuk> dd if=/dev/hdc of=/dev/sda1, wall time was 11:50, clock time was 543s
<BenC> It was in -12.19
<pkl_> Grep the changelog for Squashfs... first entry 26 Oct 2006
<cjwatson> and yet the tree clearly shows that the diff is applied
<BenC> pkl_: I'm not sure how it got left out of the changelog, but it was definitely in the 2.6.20-12.19 upload
<BenC> git-log Ubuntu-2.6.20-11.18..Ubuntu-2.6.20-12.19
<BenC> shows it
<heno> mdz oddly lspci -vvnn didn't give me that info, but Device Manager tells me PIIX_IDE
<BenC> it would be nice if there was a quick way to see what kernels were in what milestone
<cjwatson> BenC: is it possible the scripts didn't like Phillip's (none) hostname?
<cjwatson> although later changes from pkl do show up
<BenC> cjwatson: it should never drop any changes...all "unknown" ones that don't parse as an ubuntu change should show up under "Upstream Changes:
<pkl_> cjwatson: previous commits show up, even though the hostname had the same problems.  But, I noticed the none hostname and fixed that.
<heno> we should do some timings of copying the content of an entire alternate ISO to the HD in Edgy and Feisty (in vmware) to isolate CD driver vs. sqashfs issues
<BenC> git-log  --pretty=short Ubuntu-2.6.20-11.18..Ubuntu-2.6.20-12.19 | perl -w -f debian/bin/git-ubuntu-log
<BenC> cjwatson: that command misses his entry, so I'll have to check why
<pkl_> Squashfs 3.2-r2 does have some performance improvements over Squashfs 3.1 in the main data-path.  None of the changes should have caused problems (quite the opposite).
<pkl_> I'll have a look at the code...  It's probably worth pointing out Squashfs 3.2-r2 was released in January, and no-one else has reported any speed regressions (such a major drop in performance would be immediately noticed by quite a number of liveCDs).
<cjwatson> yeah, I think chances are thet squashfs is a red herring myself
<cjwatson> that
<BenC> pkl_: we're having problems pointing the finger at anything, so squashfs got dragged in
<BenC> pkl_: is there an easy test we can do from livecd to see squasfs performance comparisons?
<BenC> like find /usr | time xargs cat > /dev/null ?
<pkl_> Ah, I don't mind.  Squashfs is an obvious candidate, and I've been trying to think of potential issues all day :)
<pkl_> Yes, there's two potential cases.  Dentry performance is slower, or readpage performance is slower... or both.
<pkl_> Doing a find with an option requiring a stat of each inode (i,e, -type f), will test dentry regressions.
<cjwatson> find | xargs has the problem that it also stresses CD seek times
<cjwatson> might not matter in vmware of course
<BenC> only a virtualized ISO, probably not much of an issue
<cjwatson> maybe read a big file out of the squashfs instead
<pkl_> All the metadata is packed together at the end of the disk...  Just doing metadata operations (no file reads) will not seek the head too much.
<pkl_> no file data reads, that is.
<cjwatson> biggest file on the squashfs is /usr/lib/libgcj.so.70.0.0 - only 30MB though
<cjwatson> ("only". damn gcj.)
<BenC> I keep thinking we need a sane way to go back and forth between piix and ata_piix using the same CD
<Keybuk> doesn't openoffice have one bigger?
<cjwatson> this is from "find /rofs -type f -printf '%p %s\n' | sort -k2 -nr | head"
<cjwatson> so no
<BenC> ata_piix doesn't support new_id
<BenC> piix does though
<cjwatson> OOo doesn't come in until no. 7
<BenC> I'm going to build a 2.6.20-15.27 that defaults to ata_piix, and we can override it easily to piix
<cjwatson> TBH, this is all pressing my "release-critical" buttons less and less convincingly
<mdz> cjwatson: agreed
<cjwatson> though I think it is still worth the detailed investigation
<cjwatson> I'm just a bit worried that we're focusing so much on this that we may not be paying attention to other testing information coming in
<cjwatson> anyway, speaking of focusing, it's 8:30pm and I'm off to play Lego Star Wars or something :)
<Keybuk> heh
<pkl_> Doing a large file read will test readpage regressions.  There's three major changes between Squashfs 3.1 and Squashfs 3.2-r2.  Once affects dentries only, one affects dentries and readpage, and one only affects readpage.  If it was Squashfs, it would be uselful to isolate it.
<cjwatson> pkl_: is 30MB likely to be large enough, or would we need a custom squashfs?
<BenC> cjwatson, mdz: I do need to make an lrm upload to fix nvidia-glx-new
<cjwatson> dd tells me 27.2 MB/s first time round, and thereafter c. 200
<BenC> It doesn't affect linux-restricted-modules-* at all
<pkl_> I'm not sure, but looking at the slowdown, it should be measurable over 30MB.
<cjwatson> (feisty
<cjwatson> )
<BenC> just that one package (so doesn't bother CDs)
<BenC> pkl_: given vmware's clock fuckage, it may not be enough to be reliable :/
<pkl_> Yeah, that's why I abandoned Parallels and Vmware for Squashfs development.
<pkl_> Couldn't reliably tell why affect changes had made ....
<pkl_> why -> what
<BenC> I would be interested in why my laptop is crashing with ws5 and ws6 though
<mdz> BenC: beg pardon?
<mdz> BenC: what's wrong with it?
<BenC> mdz: nvidia-glx-new is missing a file that wasn't in the other versions of nvidia
<BenC> xorg module
<mdz> BenC: so it's non-functional?
<mdz> sounds like an SRU candidate if so
<Mithrandir> BenC: isn't nvidia-glx-new on the CDs?
* Mithrandir thought it was
<BenC> I don't know if nvidia-glx* is on the CDs
<BenC> I didn't think they were
<BenC> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/103050
<BenC> there's the bug
<Mithrandir>   Adding nvidia-glx to CD 1 ...
<Mithrandir> not -new, it seems, though
<cjwatson> nvidia-glx is explicitly seeded, but not -new
<BenC> is -legacy?
<mdz> not an issue for installs or upgrades -> -updates
<cjwatson> -legacy was deliberately unseeded at one point
<Mithrandir> BenC: doesn't look like it, no.
<Mithrandir> cjwatson: because we can't even pretend to give security support for it.
<Mithrandir> AIUI
<cjwatson> indeed
<cjwatson> supported: * Extra-Exclude: nvidia-glx-legacy-dev # nvidia-glx-legacy is unsupportable
<BenC> we can't for nvidial-glx{,-new} either :)
<Mithrandir> we should probably invent a better name for nvidia-glx now that the package isn't maintained any more either. :-/
<Mithrandir> BenC: we can pretend for -new
<BenC> according to ATI it is
<BenC> at least that
<BenC> 's what they keep posting on the forums
<Mithrandir> uh, ATI?  You mean nvidia?
<mdz> I'm going to find food and then go home
<BenC> err, I mean nvidia, yes :)
<mdz> I have a functional laptop now though, so I should be back
<Mithrandir> I'd be very surprised if ATI supported nvidia-glx. :-P
<BenC> mdz: have a good evening
<BenC> hehe
<BenC> Mithrandir: well, my stink raised all kinds of responses from nvidia, basically saying "of course this package that isn't on our main download page is going to be supported"
<Mithrandir> BenC: but, sure -new is fine since it doesn't touch the CDs.
<BenC> though I've seen no indication other than hot air
<BenC> Ok, upload should be quick and painless
<cjwatson> Mithrandir: an l-r-m upload would create skew though
<Mithrandir> cjwatson: ugh, true. :-/
<Mithrandir> BenC: iirc -legacy at least has known root holes?
<cjwatson> if that concerns you for update-manager ...
<zdzichuBG> vmware-tools should mitigate clock skew
<Mithrandir> cjwatson: it does.
<Mithrandir> but if want to respin anyway..
<cjwatson> I think I'm with mdz if it doesn't affect new installs or upgrades from dapper/edgy
<BenC> Mithrandir: I don't think so anymore...although they have been release non-frequent updates to that line of the driver
<Mithrandir> BenC: ok
<BenC> cjwatson: which way is that, SRU?
<cjwatson> yeah
<Mithrandir> cjwatson: what about the update-manager one?
<BenC> works for me
<cjwatson> Mithrandir: no opinion yet, haven't read enough of it
<cjwatson> BenC: if so, the bug should be milestoned later so we don't forget
<Mithrandir> ok, tell me if you need anything for it.
<cjwatson> er, "later"
<Mithrandir> which is an edgy milestone.  LP should grow the ability to either move milestones between releases or have distro-wide milestones.
<BenC> We have one Ubuntu:later
<BenC> is that edgy?
<Mithrandir> yes, but just use that one.
<BenC> ok, done
<Mithrandir> only LP cares that it's edgy.
<heno> Copying the contents of an alternate CD to HD (virtualbox) on Edgy: 1:15, on Feisty: 1:10 
<heno> so if anything, slightly better CD performance of Feisty
<BenC> heno: Contents as opposed to dd'ing the device image, right?
<heno> BenC: right, nautilus copy+paste
<BenC> sounds reasonably close then
<Mirrado> Hi, where is the write place to submit a error with the last proposal to final version of the Feisty kernel? 
<mjg59> Mirrado: launchpad.net/bugs
<Mirrado> I already created the bug in launchpad (bug #75935). That is enough?
<mjg59> Yes
<Mirrado> mjg59: thanks
<cypherdelic> feisty wont beat 2.6.21, right?
<mjg59> Feisty will be shipping 2.6.20
<cypherdelic> so 2.6.21 will never be available for feisty?
<MrNOKIA> i'm sure you'll find a tutorial on ubuntuforums to get a running .21 kernel pretty soon
<MrNOKIA> so that would'nt be an issue
<mjg59> We'll probably be skipping to .22 for gutsy
<MrNOKIA> right
<MrNOKIA> i meant untill gutsy kicks the shelves :)
<cypherdelic> yes that would best, 6 month, hmm maybe ,23
<mjg59> .23 is unlikely
<mjg59> Given that .21 isn't out yet
<cypherdelic> its rc7, torvalds doesnt want a rc7
<cypherdelic> its nearly released
<MrNOKIA> it might be nearly released
<MrNOKIA> but it's not tested enough to get to a stable april release, IMO
<BenC> 99% chance we'll be .22
<MrNOKIA> that's why i said it could catch a nice compilation tutorial on the forums
<BenC> 0.05% chance of .23, and 0.05% chance of .21
<mjg59> BenC: Dude, that's 99.1%
<MrNOKIA> BenC, so you're saying another kernel update is upon us ?
<BenC> ok, 0.9% that we'll move to a hurd kernel
<mjg59> MrNOKIA: For gutsy
<BenC> MrNOKIA: for feisty, there are no more kernels
<mjg59> Well, other than updates
<BenC> except for security and maybe some driver updates
<MrNOKIA> i was pretty sure of that :)
<MrNOKIA> it seems there's an (minor ? ) issue with ati detection on the RC, according to the thread
<cjwatson> what thread?
<cypherdelic> yes yes more nvidia bug fixes
<BenC> mjg59: looks like most of the ide/libata crack we have in feisty is upstream, except for libata-hpa...that look right to you?
<MrNOKIA> http://ubuntuforums.org/showthread.php?p=2464356#post2464356
<MrNOKIA> post #12
<mjg59> BenC: And the ACPI stuff, but yes
<BenC> mjg59: the "extended" acpi...
<BenC> for just libata...ide-acpi is all good?
<mjg59> Yeah
<BenC> MrNOKIA: almost no info there...don't know if he's using ati or fglrx
<cjwatson> don't know how it breaks either
<BenC> likely not a kernel bug, so my stress level is constant (still high, but level)
<BenC> cjwatson: I know rtg had some weird ati bug with the dell 1505 he has
<rtg_> cjwatson: Still do.
<BenC> install wouldn't work even for vesa graphics on the livecd, but after an install with alternate it went ok
<BenC> rtg_: was yours a 200M?
<rtg_> BenC: Not true. I had to install fglrx.
<BenC> ah, that's right
<rtg_> ATI X1300
<BenC> we killed colin
<rtg_> poor guy.
<MrNOKIA> :)
<MrNOKIA> there's one thing i don't get
<MrNOKIA> are there instances where it might work beryl on a live cd ?
<BenC> 945/965 graphics will work out of the box...some older ati cards work with xorg driver
<MrNOKIA> i try to understand why it has been included on the livecd
<MrNOKIA> mine is ati x1400 on my laptop
<MrNOKIA> it doesn't work at all
<BenC> "some older ati cards"
<MrNOKIA> same for an nvidia 5500 card
<MrNOKIA> i got it
<BenC> obviously most laptops wont work
<BenC> a lot of mine do, because I've preferred intel graphics lately
<BenC> I don't get 23 billion fps with glx gears, but it runs nicely :)
<MrNOKIA> i found my dell to be a best buy when it appeares
<MrNOKIA> appeared
<MrNOKIA> the only issue is the ATI card
<BenC> if I buy anything right now, it's going to be core2duo with intel graphics
<BenC> ipw3945 wireless
<BenC> best platform for open source right now...only drawback is the ipw3945d userspace daemon
<MrNOKIA> but i hope someday ATI will realize tha it has to consider linux 
<MrNOKIA> have a friend who worked there in the driver departament
<MrNOKIA> he says linux doesn't matter for them very much :(
<BenC> doesn't matter what the driver guys want...it's who's buying the cards that matters
<MrNOKIA> i know...
<BenC> I don't think ATI's going to come out well in the graphics area unless they start making some sweeping changes in how they handle their dwindling market share
<MrNOKIA> maybe AMD will have a say in the matter
<MrNOKIA> let's hope for the best :)
<MrNOKIA> it seems there's more kernel trouble on reiserfs
<MrNOKIA> here http://ubuntuforums.org/showthread.php?p=2464356#post2464356
<MrNOKIA> what output could be helpfull in this situation ?
#ubuntu-kernel 2007-04-17
<BenC> if 2.6.20-14 works for him, then there's no reason 2.6.20-15 shouldn't
<BenC> mjg59: is the dont_disable_c3 patch still needed for ipw2100?
<BenC> mjg59: I don't recall any bug reports that benefited from it
<mjg59> It was never a bug-fixing measure
<mjg59> It was a "I'm willing to accept some packet corruption in return for better battery life" one
<BenC> do we really want it in there?
<mjg59> I find it useful
<mjg59> By default it does nothing
<BenC> Can you get it upstream?
<mjg59> I'll try to, when I push the other ipw2100 stuff I have
<BenC> Great, thanks
<kylem> win 23
<BenC> I hate when laptop manufacturers use 2x512Meg for 1G of mem, means you can't just add another 1G stick to get 2G
<kylem> pretty common cost saving measure...
<BenC> my gateway came with 1G stick
<BenC> or wait, maybe it was the HP
<BenC> one of them did anyway :)
<jdong> BenC: ping
<jdong> Can someone look at bug https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/101984
<jdong> "firegl_public.c: Ubuntu modification uses obsolete __syscall_return"
<mjg59> jdong: Given that it's all a huge hack in the first place, what's the impact of this?
<jdong> I'm not sure what the impact is
<jdong> that's why I asked
<jdong> some user bugged me about it....
<mjg59> Why?
* jdong shrugs
<jdong> he referred to it as an 'annoying bug'
<mjg59> Yeah, but how?
<BenC> from what I can tell it means people have a harder time using custom kernels and fglrx-kernel-source
<BenC> which means I don't care
* jdong shrugs
<jdong> oh well :)
<BenC> the patch we applied came from fglrx source, so it's not a patch we created
<BenC> s/from/for/
<BenC> nm, I meant from
<BenC> mjg59: the dongle_id = 0x9 patch for IBM0071 in nsc-ircc, is that a patch you authored?
<mjg59> Yeah
<BenC> mjg59: Can I send it upstream with your signed-off-by?
<mjg59> My experience is that all the IBM ones have that dongle type
<mjg59> So sure - I don't /absolutely/ guarantee that it's correct, but I think it's better than autodetection
<BenC> mjg59: what do you think we should do with the raw keycode patch for input.c, was there ever any discussion about that on lkml or something?
<BenC> we've been carrying it around for several releases now
<mjg59> Oh, to pass through whether it was in the filter or not?
<mjg59> Can't remember. I think it came up on lkml at some point, but I'll look into it.
<BenC> mjg59: right, that one...thanks
<kylem> moo.
<rushfan_> BenC is .27 supposed to have the sata_nv fix in it ?
<rushfan_> I'm [g2] 
<BenC> yes
<rushfan_> BenC I was running .27 and I think I had a sata command response failure on my NForce4 board
<rushfan_> with regard to the command time outs
<rushfan_> I just loaded your .26 kernel and it seems to be working so far
<rushfan_> unfortunately this is my pvr box and the .26 kernel doesn't have the ivtv drivers
* rushfan_ fires up bonnie++
<BenC> it has the drivers, just not the firmware
<BenC> copy the firmware
<BenC> rushfan_: my .26 kernel is _exactly_ the same as the archive's -15.27 kernel
<BenC> brb, doing some hw juggling
<dholbach> good morning
<saispo> hi
<zul> is there still a meeting going on today?
<Keybuk> so
<Keybuk> you remember that "VMware takes an hour to install feisty" thing?
* Keybuk can replicate that every time
<Keybuk> AND I can make it take only 15-20 min
<kkubasik> there all in a meeting right now
<mjg59> Keybuk: Oh?
<Keybuk> let me just reverse the change, and make sure this goes back to 1h+ installs
<mjg59_> Keybuk: Sorry, missed the last few lines. What was the change?
<Keybuk> I increased the amount of memory I gave to the VM
<Keybuk> from 256MB to 512MB
<Nafallo> mjg59_: no you didn't miss anything :-)
<mjg59_> So, uh. Ubuntu installs slowly in 256MB of RAM. This is unsurprising, surely?
<Keybuk> no, it's very surprising
<Keybuk> it's a very recent change
<Keybuk> the LiveCD is almost unusable in 256MB
<Keybuk> where as beta is fine
<mjg59_> Well, it certainly doesn't sound like a kernel issue...
<Keybuk> unless it's caused by the squashfs change using more memory?
<Keybuk> (or it could indeed be completely unrelated)
<mjg59_> Well, how much free ram do you have after boot, compared with beta?
<Keybuk> that's what I'm about to look at
<Keybuk> our original thought was that this was an atapi problem
<Keybuk> but pure I/O seems fine
* Keybuk is still waiting for current to boot
<mjg59> Hey wow -powerpc still actually boots Mac hardware
<mjg59> Reassuring
<cjwatson> 256MB was fine with edgy
<cjwatson> not exactly stellar or anything, but not crushing
<Keybuk> free doesn't return bad numbers, 128MB free before page cache
<kylem> argh.
<kylem> i'm a muppet.
<Keybuk> cjwatson: did you revert your system to a snapshot before you tried your test install?
<cjwatson> Keybuk: I think it was clean boot + install
<cjwatson> certainly no snapshot involved
<Keybuk> was the drive clean though?
<Keybuk> casper mounts any swap partition it can find on boot, remember
<Keybuk> so if you already had an install, you would've had some swap
<cjwatson> Keybuk: that VM is set to 700MB ...
<cjwatson> I suspect it doesn't matter ;-)
<Keybuk> ahh
<Keybuk> mdz and I both leave ours at 256MB as a matter of course
<Keybuk> could you try with 256 and see how it boots/installs?
<cjwatson> that may well explain it
<cjwatson> sure
<cjwatson> wah, none of my shift keys work any more
<cjwatson> hang on while I sort this out ;-)
<cjwatson> boots in 2:13
<cjwatson> subjectively, the slowness is primarily after X starts
<Keybuk> agree
<Keybuk> right when GNOME hauls its fat, bloaty arse into memory
<cjwatson> free after cache is 155MB
<Keybuk> cache includes loaded apps though
<Keybuk> iirc
<Keybuk> ie. mapped bits of .so files, binaries
<cjwatson> ubiquity is liable to eat at least 50MB, possibly more
<cjwatson> most of which I think is debconf
<Keybuk> I get 104MB plus cache with ubiq
<cjwatson> what's the c-a-f1 rune in vmware again?
<Keybuk> c-a-space-f1
<Keybuk> ie, hold ctrl alt, press space, then f1
<Keybuk> I think
<cjwatson> thanks
<cjwatson> 129MB right after starting ubiquity
<Keybuk> 97MB once install begins
* Keybuk just hit zero
<cjwatson> ubiquity itself has 24MB res 10MB of which shared
<Keybuk> so now it's swapping to the same disk it's installing *to* to unpack the squashfs of the disk it's reading *from*
<cjwatson> debconf-communicate has 15MB res
<cjwatson> can you look at top and see what's using memory?
<Keybuk> u6y with 10.3%
<cjwatson> growing as files are copied?
<Keybuk> no
<cjwatson> 10.3% sounds like about baseline
<cjwatson> that's similar to the 24MB I had above right after starting it
<cjwatson> so what's using MORE memory?
<cjwatson> I'm around 90MB+ free after cache, copying files
<cjwatson> if anything, it's growing slightly
<Keybuk> right
<Keybuk> nothing's growing in userland
<Keybuk> how do I find out how much memory the kernel is hogging for itself?
<cjwatson> where are you getting your zero number?
<Keybuk> free
<Keybuk> it hit zero free after cache, and sat and swapped for a few seconds
<cjwatson> yeah, see I'm not getting zero free after cache
<cjwatson> this is the -/+ buffers/cache: ... (free) column?
<cjwatson> that's settled down at 106MB
<Keybuk> it only hit it once
<Keybuk> then it swapped a huge amount and has stayed around 70MB since
<cjwatson> maybe I should look at this in gnome-terminal rather than a console
<cjwatson> just worried about g-t's own bloatiness
<cjwatson> I'm not seeing your memory problems, but I do have to agree that this isn't fast
<cjwatson> it's 5+ minutes in by vmware's clock and only at 29%
<Keybuk> I can't see why the memory is a problem
<Keybuk> all I know is that if I increase the memory available to it, it's not slow anymore
<Keybuk> I'm trying to work out what is using that extra memory
<pkl_> Keybuk: increase the memory available to what? the vmware VM?
<Keybuk> yes
<pkl_> if the VM is low on memory, it will be shrinking the caches - dentry cache, inode cache and the buffer/page-table caches.  If it shrinks the dentry/inode cache and gets rid of inodes subsequently needed, this will cause a lot of extra seeking in the Squashfs image
<Keybuk> what I can't see is why it needs to shrink it that much
<Keybuk> free says it rarely goes below 100MB
<pkl_> there's a parameter which controls whether the kernel prefers to shrink caches or prefers to move stuff out to swap.
<pulkit> BenC ping
<BenC> pulkit: yes
<BenC> Keybuk: squashfs, tmpfs, etc..
<pulkit> BenC: are you free..I wanted some advice on my rejected Google SOC application
<pkl_> the policies relating to when and what get shrunk, or swapped are a bit of a black art, and are constantly being tweaked between kernels.
<BenC> pulkit: I don't handle the SoC stuff
<Keybuk> BenC: 100MB of them?!
<BenC> Keybuk: then there's the whole desktop thing running :)
<pulkit> BenC: O sorry, I just saw your name for a project, and wanted to ask what mistakes I had made...Thanks nevertheless
<Keybuk> BenC: was I right that the page cache figure includes mapped portions of binaries and libraries?
<BenC> Keybuk: increasing mem allows for more things to stay cached
<BenC> of there's not enough memory, then the kernel will spend a lot of time dumping cached pages for disk reads, and so almost any page read will result in an actual IO op to the device
<BenC> *if
<BenC> I think 256meg is the bare minimum for livecd installs, but could do with a suggested min of 384M or even 512M
<pkl_> squashfs doesn't use a lot of memory itself, but it will be asked to re-read anything dropped from the page-cache and/or dentry/inode caches.
<cjwatson> yeah, I think that's really a bit ridiculous though
<cjwatson> we have a *lot* of users on 256MB (subjectively, from bug reports)
<pkl_> the big question is does the installer (Ubquity?) re-access files it previously accessed?  Especially files which it read sometime ago and which may have been removed from caches on low-mem systems-  and can this be improved?
<pkl_> In general as far as the installer is concerned, it is better to swap anonymous memory to hard-disk rather than delete cached data/metadata from the Squashfs filesystem, because it is more expensive to re-read from the Squashfs image than the swap file (on slower processors anyway).  But I doubt the kernel does this.
<BenC> pkl_: we have no swap in the installer
<BenC> unless the installer could use the swap it is setting up for the installed system early
<pkl_> BenC: that's good to know.  So, on a low-memory system the kernel is going to be aggresively shrinking the caches for data it thinks can be re-read.  Very bad for Squashfs performance.
<BenC> it would seem so
<BenC> and there's like a million possible things that could cause an increase in memory pressure on the feisty livecd as opposed to the edgy one
<pkl_> and, as I said, the policies on what and when stuff gets deleted can have changed between the kernels.
<pkl_> A lot of installers (obviously not Ubuntu) on low-memory systems immediately create swap and mount it.  Could that be done?
<BenC> I don't know that we could do it immediately, but maybe once the user goes through the setup process and creates the partitions, the installer could use the one the user defined
<BenC> that would be just before the actual install process starts
<mdz> BenC:  the installer does activate swap as soon as it's available
<BenC> oh does it?
<mdz> BenC: (after it's been partitioned and mkswap'd)
<BenC> ok, then there goes that idea
<mdz> pkl_: by far the lion's share of the I/O done by the installer is copying the contents of the squashfs to the hard disk
<mdz> pkl_: i.e., mostly reading files once and never touching them again
<BenC> mdz: what program is used to copy those files? Is it cp, rsync, or some custom thing?
<mdz> something like O_STREAMING would be appropriate if it were available in python
<mdz> BenC: python
<pkl_> this is one of my annoyances with the kernel, it doesn't have any concept of relative costs of I/O from difference devices/filesystems, at least the time I looked.
<BenC> ok
<tuxmaniac> pkl_, what do you mean by relative costs ofI/O?
<cjwatson> pkl_: while it's copying files, it basically just goes straight through in os.walk() order
<cjwatson> Keybuk: hmm, just out of interest, did you create swap in your test install
<cjwatson> ?
<mdz> I almost always do erase disk, which last I checked created swap
<pkl_> tuxmaniac: it rather more expensive, for example, to re-read a block off CDROM than the hard-disk.  Once the page goes into the page-cache this knowledge isn't there.
<BenC> tuxmaniac: like the kernel should be less likely to drop page caches for a squashfs filesystem on cdrom that it would for ext3 fs on a hd
<Keybuk> cjwatson: yes
<cjwatson> although I did create swap, and it was still 44 minutes by vmware's clock versus the more usual 9 or so
<cjwatson> mdz: yes, it does
<cjwatson> BenC: it's shutil.copyfile() in python
<cjwatson> which is basically read()/write() slurping in 16K chunks
<BenC> I wonder if python is doing anything whacky that would cause extra IO
<Keybuk> http://people.ubuntu.com/~scott/meminfo.png
<BenC> decent strace would probably find something out
<pkl_> cjwatson: probably because the kernel is preferring to shrink caches than swap.
<cjwatson> last time I straced I think it was just read()/write(), though I could check
<cjwatson> I really doubt it's python
<BenC> not so much the read/write, but maybe interim things that it may do between files or something, like reread dentry or something dumb like that :)
<tuxmaniac> BenC, is that available on BSD? I mean the page cache drops depending on the FS
<BenC> tuxmaniac: no idea, just explaining pkl's statement :)
<tuxmaniac> aah ok :-)
<cjwatson> I can certainly have a look
<Keybuk> so whatever the two cyanish lines are, they bounce around between 250MB and 300MB during install
<Keybuk> (that's with 512mb btw)
<cjwatson> BenC: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-copy.trace.bz2
<cjwatson> the chmod/utimes/stat etc. stuff in between files is mostly ubiquity
<cjwatson> I wonder if mmapping would be faster than reading
<cjwatson> wonder what the mmaps it does do are for
<cjwatson> oh, maybe just memory allocation
<BenC> lstat64("/rofs/bin/uname", {st_mode=S_IFREG|0755, st_size=14000, ...}) = 0
<BenC> stat64("/target/bin/uname", 0xbf9f17d8) = -1 ENOENT (No such file or directory)
<BenC> stat64("/rofs/bin/uname", {st_mode=S_IFREG|0755, st_size=14000, ...}) = 0
<BenC> stat64("/target/bin/uname", 0xbf9f14f8) = -1 ENOENT (No such file or directory)
<BenC> open("/rofs/bin/uname", O_RDONLY|O_LARGEFILE) = 3
<BenC> fstat64(3, {st_mode=S_IFREG|0755, st_size=14000, ...}) = 0
<BenC> open("/target/bin/uname", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
<BenC> fstat64(4, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
<BenC> fstat64(3, {st_mode=S_IFREG|0755, st_size=14000, ...}) = 0
<BenC> lot of stats going on in there
<BenC> it fstats the source twice after opening it, and twice before opening
<BenC> just normal stat before open, but you get what I mean
<cjwatson> I'll cough to the inefficiency (the first is in shutil.copyfile, the second must be somewhere in python I think), but is it likely to be triggering this slowdown?
<cjwatson> surely one stat or two is much the same, goes to the dentry cache either way
<pkl_> if the dentry and inode caches have been shrunk, they'll go to the filesystem again.
<cjwatson> they'd have to be shrunk so that they could only hold one item
<cjwatson> seems like pretty serious shrinkage
<cjwatson> the stray fstats shouldn't go to the filesystem
<cjwatson> shouldn't stat information on open files be accessible without that?
<pkl_> ok, so the multiple stats are stat file, stat file again, rather than stat the entire filesystem (or a substantial part), and then stat the entire filesystem again.
<cjwatson> (this is where pkl tells me I know nothing about filesystems)
<pkl_> stat info on open files will never go to the filesystem.
<cjwatson> pkl_: right, it's two files (source and target; the source on squashfs, the target not) but a pair at a time rather than the whole filesystem, yes
<cjwatson> it's "does the source file exist? what is it? does the target file exist? are they the same thing already? copy"
<cjwatson> the logic is obviously a bit more competent than that but you get the idea
<cjwatson> I suppose it's possible that memory pressure forces /rofs/bin out of the dentry cache while /rofs/bin/umount is being copied and before starting on /rofs/bin/uname
<cjwatson> (e.g.)
<cjwatson> is there any reasonable way to test a hypothesis like that?
<pkl_> A hook in Squashfs (a printk in the Squashfs lookup and readdir routines) would show that happening, or hooks into VFS.
<BenC> cjwatson: I had to do stat caching in dpkg to fix a test case I had created so that it took 30 seconds to install a package instead of 30 minutes
<BenC> granted it was a huge test case, much more stat's than the install case we're talking about
<BenC> but they do add up, so I was just pointing them out
<pkl_> Doing find with and without -noleaf is an easy way to see how file stating slows things down...
<BenC> I also don't know if there's negative cache for the ENOENT case
<BenC> no idea if an ENOENT has much of a performance inpact
<BenC> *impact
<BenC> internally a stat() on non-existent file has to get dentry for every dir leading up to the last component, right?
<pkl_> BenC: yes, and on the leaf directory the directory has to be searched for the non-existent entry.   Depending on the filesystem this can be quite expensive.
<BenC> right, even on ext3, that can consume a good chunk of cache, especially in a dir like /usr/share/doc/
<pkl_> Squashfs uses directory hashing, and the impact is much lower than otherwise (searching the entire directory).
<BenC> mdz, cjwatson: I just did another feisty x86 install in vmware, this time with a 512M VM, and start to finish was 9 minutes
<BenC> in fact, even the initial boot to to livecd took less than 1 minute
<BenC> so it definitely looks like we have memory issues
<cjwatson> for feisty, my inclination is to document this as best we can (e.g. change the memory threshold below which releases.ubuntu.com advises using alternate)
<cjwatson> but for gutsy I would really like to get the threshold back down
<BenC> going to be a very thorough investigation to get this nailed down
<cjwatson> yeah, that's why I don't want to rush it into feisty now
<mdz> cjwatson: agreed, can you add it to FeistyKnownIssues?
<mdz> I'm quite happy to chalk it up to memory usage changing in subtle ways
<mdz> we should see if we can't get it down again for gutsy, rather than increase the standard requirements
<cjwatson> added
<cjwatson> seems like a good developer sprint topic if we don't nail it before then
#ubuntu-kernel 2007-04-18
<defendguin> all the bugs are squashed?
<kylem> no, but the list is reasonable.
<defendguin> no big regressions left?
* ..[topic/#ubuntu-kernel:Mithrandir] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | 2.6.20-15.27 Uploaded
<gnomefreak> what kernel version is out?
<gnomefreak> .27?
<Mithrandir> yes
<gnomefreak> ty
<bdmurray> howdy
<mvo> hm, what is the reason that udev throws "permission denied errors?". I get quite a few when trying to make isdn work here: localhost udevd-event[10750] : udev_node_mknod: mknod(/dev/capi/0, 020660, 191, 0) failed: Operation not permitted
#ubuntu-kernel 2007-04-19
<holycow> hi guys
<holycow> i'm running ubuntu on a core duo laptop and i'm getting intermittent freezes
<holycow> i'm trying to track down the issue and so far syslog seems to have some stuff about ata2 port being slow and then doing some reinitializing
<holycow> that might explain it but just curious if there is anything more i can do to track down this issue before posting a bug?
<holycow> oh look there it is again
<holycow> ata2 too slow to respond
<holycow> soft resetting port
<holycow> *hmm*
<holycow> tips?
<fabbione> BenC, kylem: please take a look at 197619
<fabbione> ops
<fabbione> 107619
<BenC> fabbione: I've been rejected
<BenC> "Not allowed here"
<fabbione> BenC: ops.. 
* fabbione fixes
<fabbione> sorry about that.. just one sec
<fabbione> BenC: you should be good now
<BenC> fabbione: looks like something for kyle, but he's sick today
<BenC> fabbione: Can you email him a reminder?
<fabbione> yeps.. ok.. i did check already and the code didn't change from release
<fabbione> yes of course
<pkl_> and you'll have to add kyle to the users allowed to access it, but whatever you did, didn't allow me in.
<pkl_> but -> because
<fabbione> pkl_: already done with kyle
<pkl_> can I have a look at it, or it too secret
<fabbione> pkl_: sure.. what's your LP id?
<pkl_> plougher
<pkl_> no, phillip-lougher
<fabbione> make up your mind :)
<fabbione> done
<zul> congrats guys
<BenC> dpkg-deb: building package `linux-image-2.6.22-1-generic' in `../linux-image-2.6.22-1-generic_2.6.22-1.1_i386.deb'.
<BenC> first step of the new build system...done
<Nafallo> nice :-)
<BenC> it's going to be so sweet, instead of setting flavours=, you just do things like "fakeroot debian/rules binary-arch-FLAVOUR" where FLAVOUR is like generic or whatever
<BenC> there's {prepare,build,install,binary}-arch-% targets for each flavour
<Nafallo> will I get 22 when gutsy opens? :-)
<BenC> Probably wont show up for a week or two
<Nafallo> feels odd running something stable :-)
<bdmurray> BenC: ping
<BenC> bdmurray: yo
<bdmurray> Maybe this should be a kernel team discussion but I was curious about setting the importance of network adapter bugs as medium
<BenC> do you have an example?
<bdmurray> Not a specific one, but the general rule is to set network adapter ones as medium.
<BenC> it all depends on the bug
<bdmurray> makes sense
<BenC> for ethernet adapters, the issue is that even if a specific model is broken, it's easy for users to toss another $5 10/100 adapter in there
<BenC> if we're talking about bringing down the system (data loss, total lockups) then we can mark it high
<BenC> IMO, things like wireless adapters on laptops not working should get high, but that's because most times they can't easily fix it (plus for wireless laptop cards, a bug in the driver affects a lot of ppl)
<BenC> there's only like 6 major drivers for wireless, but there's like over 100 ethernet drivers
<bdmurray> The wireless makes sense
<jb-home> bdmurray: I'm avoiding the feeling of running something stable by not doing the last apt-get upgrade. =)
<jb-home> I'll wait until gusty opens.
<Nafallo> jb-home: :-)
<jb-home> Err, Nafallo.  Wichever of you spoke.
<jb-home> I should *really* be asleep now.
<jb-home> =)
<Nafallo> :-)
<bdmurray> BenC: do you think it is worth qualifying at https://wiki.ubuntu.com/Bugs/Importance
<BenC> bdmurray: Not sure...maybe something more specific in KernelTeam wiki?
<jb-home> BenC: We have a good chunk of an hppa/feisty archive, except you need to use a non-Ubuntu kernel (binutils trouble)
<jb-home> It builds but won't boot.
<jb-home> BenC: What's your box?
<jb-home> If it's an a500 I have a kernel that will work for you, if you dont mind keeping it building as part of your tests.
<BenC> jb-home: we have a fix for hppa in ubuntu-feisty.git
<BenC> jb-home: I do have an a500, I just need to boot it so I can start building again
<BenC> jb-home: first post-release upload we do, hppa will get fixed up
<jb-home> BenC: http://people.ubuntu.com/~jbailey/hppa/a500/linux-2.6.21-rc2_2.6.21-rc2_hppa.deb
<jb-home> BenC: That's build with make deb-pkg from Kyle's merge tree.
<BenC> jb-home: ok
<jb-home> Right, the fix you have there allows it to build, but not to boot.
<jb-home> The boot failure is a binutils bug.
<jb-home> But that way at least we'll have update linux-libc-dev and such.
<jb-home> I'm going to work on getting it booting pretty quick.  We're getting the userspace bits sorted out so that at least that can go on with a minimum of fuss.
<jb-home> Also, you now probably need linux32 when building things, like on sparc/ppc.
#ubuntu-kernel 2007-04-20
<penguin42> hi, I filed a bug - 106665 that got fixed by the -27 fix; what's the best way to close it?
<gnomefreak> penguin42: mark it fix released with comment says fixed in ....-27 kernel
<gnomefreak> or restricted-modules or whatever it was fixed in
<penguin42> ok will do
<penguin42> main kernel - it's an amd pata hanging the machine solid
<holycow> hey guys
<holycow> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/107271
<holycow> anyone have a clue why ata2 interface would be acting slow?
<holycow> the system seems to be restarting it every so often and locking up the entire laptop for about 30 seconds at a time or so
<penguin42> After the rush of the initial release is out of the way can we expect updates to fix low priority bugs if the fix is already committed but not released? (#92171 unusuably quiet sound on Intel chipsets affects me)
* Starting logfile irclogs/ubuntu-kernel.log
<holycow> hey guys
<holycow> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/107271
<holycow> would anyone know what subsystem talks to the ata2 interface and why it might be responding 'slowly'?
<holycow> is there anything i can do to test further and help the bug hunt?
<crimsun> err, ubuntu-feisty.git has a completely different EXTRAVERSION from release
<poningru> so I had a quick question
<poningru> re: Intel's pat
<poningru> is that open?
<poningru> does amd implement that in their mem controllers?
<fabbione> BenC: ping?
<BenC> fabbione: yo
<fabbione> BenC: hey dude... usual question of doom... generic kernel up to 8 CPU? server up to X??? and bigiron up to 64?
<fabbione> BenC: preparing some slides.. brain is melting /me can't remember
<kylem> rgrep NR_CPUS debian/config/amd64
<kylem> debian/config/amd64/config.generic:CONFIG_NR_CPUS=8
<kylem> debian/config/amd64/config.server:CONFIG_NR_CPUS=64
<BenC> 8, 8, 64 (generic, server, bigiron)
<fabbione> ok thanks
<BenC> for i386
<kylem> we should probably bump .generic to 16.
<fabbione> and sparc to 64 at least
<BenC> there was a problem with sparc being set to 64
<BenC> I forget what it is
<BenC> maybe davem remembers
<fabbione> BenC: it was the amount of CPU structs allocated at boot, but i think that was solved
<fabbione> in any case that needs to be fixed for N2
<fabbione> amd64/config.server:CONFIG_NR_CPUS=64
<fabbione> i386/config.server:CONFIG_NR_CPUS=8
<fabbione> i386/config.server-bigiron:CONFIG_NR_CPUS=64
<fabbione> hmmm
<fabbione> perhaps we should allign those too
<BenC> the only bad thing about i386 server is that some people might want to use it on 64-bit hw
<BenC> but the usual there is 2xquad-core, so 8 is fair enough...I think i386 server-bigiron should probably go away
<BenC> we have zero testing with it
<kylem> maybe if you ask nice, for christmas... ;-)
<BenC> most people are doing dual/quad core stuff with x86_64 anyway
* fabbione dresses kylem as Santa
<BenC> kylem: are you going to be my secret santa? :)
<kylem> sure.
<kylem> parisc cpus for everyone!
<kylem> ho ho ho
<BenC> haha
* BenC wants an e10k for Christmas
<fabbione> ahah
* kylem wants a t2000.
<fabbione> BenC: no you don't.... you want a N2
* kylem looks longingly at fabbione 
<BenC> and a colo room built in my barn for it
<fabbione> it's faster than an e10k
<fabbione> kylem: i have a phone call with our pusher on monday and ask for updates
<kylem> nice.
<BenC> fabbione: no, I really want a computer the size of fridge
<BenC> size does matter :P
<fabbione> BenC: dude.. the e10k is much bigger than a 19" rack
<fabbione> it's like 40x45" or something
<kylem> if it arrives over uds i'll have to teach my sister to hook it up in my new house.
<BenC> ok, an industrial fridge
<thom> i want an M9k
<fabbione> and you need something 10kW to power it on
<fabbione> BenC: 10kW from at least 5 different 2kW lines 
* zul wants peace on earth for christmas....
<fabbione> your cows can't bike that fast to produce all that energy
<BenC> fabbione: the bulls might if I taunt them with the heffers
<fabbione> ehhee
<thom> some kind of bungee cord and treadmill arrangement
<kylem> fabbione, WOOT
#ubuntu-kernel 2007-04-21
<mjg59> BenC: Why is EDD turned off?
<BenC> remind me what the hell it is
<mjg59> It's used to let the OS know what the BIOS thinks about attached drives
<mjg59> Which lets us work out which drive corresponds to 0x80, which to 0x81 and so on
<BenC> it also totally borks a whole class of system to where it can't boot
<mjg59> Then we need to fix that
<mjg59> But, uh, wasn't it built as a module?
<BenC>   * 33939: Disable CONFIG_EDD. Causing problems, and not needed anyway.
<BenC>     Symptons were seemingly locked up after grub jumped to kernel, but
<BenC>     actually would boot after 2 minute delay.
<BenC> EDD enables things in arch/ or something
<BenC> disabled over a year ago
<BenC> so was disabled for dapper release
<BenC> left disabled in edgy
<mjg59> Well, we're going to need it to fix a class of bugs
<BenC> rgrep CONFIG_EDD arch/i386/boot/
<BenC> it does some junk in the boot wrapper it seems
<BenC> maybe we can just disable that part
<mjg59> Hm. Yeah, I guess it has to do the call at boot time.
<mjg59> However, there's no other way of working out whether sda or sdb is the boot drive
<BenC> is that because of libata not working as well as ide drivers for getting that info?
<BenC> or was it like hda == 0x80 always?
<mjg59> hda was /usually/ 0x80
<mjg59> But there's no way of guaranteeing that
<BenC> hmm...I think I might have a machine that hung with EDD enabled
<mjg59> Now that ide and scsi drives are in the same namespace, there's more risk of collisions
<mrec> BenC: do you know about any issues with uvc webcams?
<BenC> mrec: I don't know about uvc at all, just that I put the module in there :)
<mrec> I wonder because I received such a device and the linux-uvc driver (usb video class) just crashes it
<mrec> the company which sent the cam to me told me it will work with 1 gig ram (most of it will be used for the driver)
<mrec> with video4linux/dvb regarding support for the 60 additional devices we had several discussions on the ML now
<mrec> code will be merged regardless of what some people say since they aren't willing to help either
<mrec> (well just 2 people were against it :)
<BenC> ok
<defendguin> still working on feisty bugs?
<jb-home> defendguin: Critical ones only.
<defendguin> my touchpad is critically broken after suspend 
<defendguin> very very annoying if you forget your mouse
<defendguin> bug 82860
<jb-home> If there's a bug filed, I'm sure it'll be triaged and such.
<jb-home> Given that the release just happened, I wouldn't expect to hear from anyone this weekend though.
<defendguin> i've been very proactive about the bugs that i have and can help with
<mjg59> defendguin: In most cases, the only ways you can be helpful are to test patches or fix the bug yourself
<mjg59> These things are very hard to track down without access to the hardware
<defendguin> providing timely access to information?
<defendguin> i'm sure i could test patches
<steb> how do i boot to install a new kernel if none of my kernels work?
<jb-home> steb: #ubuntu is better for these types of questions.
<jb-home> steb: But I'd suggest a known-working livecd.
<vimalg2> can anyone explain why the power management on ubuntu reduces my laptop's battery life by half. Aren't APM and ACPI industry standards?
<poningru> yes and no
<poningru> acpi is the modern industry standard
<vimalg2> oh ok.
<poningru> the only trouble is that most laptop manufacturers implement it 
<poningru> poorly
<vimalg2> why do some lapt-top installation guides reccomend turning off acpi during installation?
<poningru> whether this is malicious or not is not known
<poningru> vimalg2: because other wise you cant install it at all
<vimalg2> poningru: thanks . 
<poningru> but those cases have been mostly removed... but BenC or cjwatson are better candidates to answer that particular question
<poningru> vimalg2: for example there are many many scripts for acpi that are setup for specific laptops
<vimalg2> poningru: oh. I've never had to do the acpi=off setting ever for debian-based distros. I've had trouble getting it on my buddies notebooks
<BenC> vimalg2: battery life is probably more to do with your cpufreq than acpi
<BenC> never do acpi=off on a laptop...then you have pretty much a desktop on a battery
<BenC> no suspend, not battery reporting, no nothing
<vimalg2> BenC: I'm on Nehemiah. The associated kernel module is langhaul I believe for cpu-scaling.
<BenC> vimalg2: then check your cpu state in /sys/
<vimalg2> Is it in a usable state in Feisty.(I'm still downloading the ISO's)
<BenC> check the freq, scaling governor, etc.
<vimalg2> Via nehemian CPUID 0698
<vimalg2> BenC: i'm still figuring out how to get internet access to my hone(It doesnt have a PPP dial-up profile) Ironically the cell phone runs a 2.4.x moontavista kernel. So i have to play with NAT and the route command to get the traffic into Ubuntu/*nix. 
<vimalg2> So i'm stuck with et access in windows
<vimalg2> *net
<BenC> you're actually getting into #ubuntu type questions and topics here
<BenC> most of this stuff can be answered in the wiki, or from folks in that channel
<vimalg2> BenC: thank you for your time. I was just curious about the state of power management and cpu-scaling for CMOV instruction enabled Nehemiah procesors
<vimalg2> I'll just poke around i guess. thanks :)
<BenC> vimalg2: we've enabled everything the kernel supports :)
<BenC> np
<\sh> guys, anyone has a clue how to replace linux/config.h with something which is in linux-headers?
<\sh> (feisty 2.6.20-15-generic image) just trying to compile cisco vpn client
<jb-home> \sh: Just don't include it and hardcode the defines.
<jb-home> The use of config.h is trying to detect what's in your current kernel.
<jb-home> It's generally just a Bad Idea(tm)
<jb-home> If you're compiling something for distribution, it's always better to do a runtime check for features.
<\sh> jb-home: well, I found a patch already
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Gutsy tree opened, new build system started.
<maks_> congrats for the release :)
<kylem> thanks maks.
<BenC> well, guess I'm going to give this 2.6.21 build a test run...brb
<BenC> well, it booted :)
<maks_> dynticks?
<BenC> $ grep NO_HZ /boot/config-2.6.21-1-generic 
<BenC> CONFIG_NO_HZ=y
<kylem> woot.
<BenC> not running it right now...I've got to get lrm compiled with it
<penguin42> Can anyone suggest anything for checking my kernels idea of timing? movie player is playing way faster than real time and I've got a 'Your time source seems to be instable or some driver is hogging interrupts' error - so I wonder if something is going odd (on Feisty)
<penguin42> it's a laptop so I also wonder if something is trying to be too clever and then not coping with varying cpu clocks
<BenC> penguin42: is it an AMD cpu?
<penguin42> no, core2 duo (in 64 bit mode)
<BenC> I've not heard of those issues
<BenC> have you tried in 32-bit?
<BenC> to be honest, 64-bit mode really doesn't buy you a whole lot, and it keeps you from being able to use things like flashplayer
<penguin42> no I haven't yet - most stuff seems to be running fine; but as I say movie player is odd (which I've not seen before)
<penguin42> I've got flash going using nspluginwrapper - that is reasonably good
* penguin42 just wondered if there was a test program anywhere that ran the ALSA/old-fashioned/HPET/any other timers off against each other
<jb-home> penguin42: Ah nice.  I had no luck with nspluginwrapper.
<jb-home> penguin42: Is it hard to build?  It would be really nice to have that in the archive.
<penguin42> jb-home: I got a prebuilt one - there is a bug filed somewhere asking for it to be packaged
<penguin42> jb-home: It's not perfect (e.g. I see errors in the logs about some plugin trying to use the gnome theme engine and of course it's trying to pick up the 64bit one); and I've got a couple of flash issues I've never seen on a native flash
* penguin42 has this quaint belief that I've got 64 bits and I'm going to use them :-) (even if it's slower and a pita!)
<BenC> penguin42: have you installed ia32-libs-gtk?
<penguin42> BenC: Yep
<BenC> penguin42: also, you may be able to disable HPET in your BIOS and see if that helps
<BenC> I've seen problems with it before
<penguin42> I wouldn't bet that the BIOS can disable it - I assume there is a kernel param?
<BenC> hpet=off
<BenC> I know for sure at least 3 of my boxes can disable hpet in BIOS
<penguin42> ok, I'll give that a go on my next reboot
<penguin42> Thanks
<BenC> np
<penguin42> hmm I suspect HPET isn't used anyway - I found a test program in Documentation/hpet.txt  and whenever it tries to do anything there is an error in dmesg 'IRQ handler type mismatch for IRQ 8   current handler: rtc' and a backtrace
<BenC> penguin42: actually, that looks more like it is used, since rtc module is already grabbing the IRQ
<BenC> or not, hard to tell from that
<penguin42> there are so many timer related messages in dmesg it's difficult for me to know - there is mention of APIC timer,then Using 14.318180 MHz WALL HPET GTOD HPET timer, ah then there is mention of hpet0 (3 timrs with IRQs 2,8,0) so I guess it is used
<BenC> yay, lrm builds against 2.6.21 without a hitch
<kylem> good work old bean.
<kylem> :)
<BenC> time to reboot and really give this a test
<BenC> cheerio chap
<BenC> Linux cunning 2.6.21-1-generic #1 SMP Sat Apr 21 13:37:35 EDT 2007 i686 GNU/Linux
<simira> BenC: do you know if the laptop/hibernate/acpi problem were solved before release?
<dade`> BenC: !!!
<dade`> where are you ?
<dade`> i can try now if you remember me that command.
<dade`> for piix
#ubuntu-kernel 2007-04-22
<dade`> az
<owh> Has anyone got any suggestions on where I go to learn more about how iocharsets work? Specifically, I'm trying to learn how it relates to file system mounting.
<owh> I have a bug that I'm trying to determine if it's related to the kernel or dosfstools and I don't want to map it to the kernel until I know for sure that it belongs there.
<zul__> BenC: ping...fancy pants
<BenC> zul__: yo
<zul__> just looking at the debian/ directory for gutsy
<BenC> it's pretty much 100% now
<zul__> cool
<zul__> im just trying to wrap my head around it
<BenC> feel free to ask questions
<zul__> oh I will ;)
<BenC> zul__: basically you can do things like "fakeroot debian/rules binary-generic", "debian/rules build-generic", etc.
<zul__> I was just trying to figure out how the cp debian/vannilla debian/xen idea would work
<zul__> er debian/build/xen
<zul__> then patch debian/build/xen
<zul__> but anyways
<zul> I thought we didnt have 386 as a flavour anymore?
<lbci_irc> after updating to feisty im missing tda9887.ko for tv tuner/fm radio... has it been moved/obsoleted/replaced/forgotten?
<BenC> wow, I had a gig of space taken up by all the extra kernels I had on this one machine from the entire feisty devel cycle
<BenC> apt-get --purge remove linux-image-2.6.20-{2,4,5,6,7,9,10,11,12,13,14}-powerpc64-smp
<BenC> gotta love it
<dade`> how can i exclude a module from initrd ?
<simira> BenC: do you know if the laptop/hibernate/acpi problem were solved before release?
<dade`> BenC: ?
<BenC> dade`: ?
<dade`> i tried to add piix to initrd as you suggested but changes nothing
<BenC> I thought you said piix was being used already?
<dade`> older kernels
<dade`> not in the newer
<BenC> you could try break=top in older kernel cmdline, at the prompt "modprobe piix" then exit and let it continue
<BenC> not sure if that will work
<dade`> i don't have older kernel anymore, i only have feisty one.
<dade`> see query
<dade`> brb
<dade`> re
<simira> BenC: do you know if the laptop/hibernate/acpi problem were solved before release?
<BenC> simira: that's a very generic question
<BenC> suspend/hibernate works for most cases
<simira> BenC: a bunch of hp laptops had a problem with fan not starting after hibernate
<BenC> there are some issues, but they range from acpi to driver problems
<simira> BenC: I am ego enough to think that's the most important one ;)
<BenC> simira: that's a little more specific
<BenC> simira: well, I'm certain I applied all the patches I was asked to for that bug
<BenC> simira: but, some of the patches wouldn't apply, and I asked someone to get me better changesets to pull, and I believe that never happened
<BenC> since I don't have the hw to test, I had to rely on someone having the bug to do the grunt work
<simira> BenC: great, I'll test on final, at least. I don't know enough to fix it but Tollef might.
<dade`> BenC: did you see the query ? does it make sense if i try -386 kernel ?
<BenC> dade`: sure, give it a go, but I'm pretty sure it's a piix issue, and it's unlikely to be resolved unless you can do some kernel builds and testing in (like with git-bisect to find where the problem came from)
<dade`> [    2.437697]  ICH7: not 100% native mode: will probe irqs later 
<dade`> is this a ata_piix module message ?
<BenC> no, that's piix
<BenC> if the drive shows as hda, it's piix, if it shows as sda, it's ata_piix
<BenC> same with cdrom, hdc, scd0
<dade`> ok but, if i don't insert piix in initrd, it's not loaded, and cdrom works, isn't it ?
<BenC> I've no idea, you should be able to tell this since you are the one with the system in question :)
<dade`> i'll be able next boot
<dade`> piix.ko is not loaded
<dade`> and cdrom works
<dade`> piix.ko is not useful anymore
<dade_> even -386
<dade_> does not sleep
#ubuntu-kernel 2008-04-14
<Ng> rtg: I've been using the iwl4965 from lbm and I think there's a problem with it, but it's a bit of a puzzler. I get an oops on suspend, but we remove network modules on suspend, and removing it by hand doesn't generate an oops
<Ng> hmm, unfortunately it doesn't seem to be in logs. I'll try and capture it with a camera or something
<Ng> the lum iwl4965 seems fine, so it's hardly the scariest of issues :)
<Blinny> I was told in #ubuntu+1 to mention this here:  I'm running an updated Hardy Beta right now, with 8GB RAM. Unfortunately, after a recent kernel update (to 2.6.24-16-generic) my kernel is only seeing 3GB. I had understood that Ubuntu was no longer separating 32 and 64-bit kernels, hence the -generic. I haven't found a bug report about this, but wanted to check here before filing, as I know everyone is really busy right now. Is this a known issue
<amitk> Blinny: contents of /proc/mtrr?
<Blinny> amitk: http://www.pastebin.ca/984739
<amitk> Blinny: have you tried adding 'mem=8192M' to the kernel command line?
<Blinny> amitk: Sorry it took so long - this is a hardware RAID that takes along time to initialize. kernel boot option mem=8192M  does not make a difference in total memory.
<amitk> Blinny: I have to step out for a bit, will look at the mtrrs when I get back
<Blinny> amitk: No worries. Cheers.
<amitk> Blinny: please file a bug
<Blinny> amitk: Will do.
<Blinny> amitk: https://bugs.launchpad.net/ubuntu/+bug/217309
<Blinny> Booting into both 2.6.24-16-generic and 2.6.24-12-generic finds only 3GB RAM.  Using i386 Hardy Beta LiveCD found all 8GB. Gutsy x86_64 LiveCD found all 8GB
<cradek> fwiw, the new x86_64 2.6.24-16-server finds all 16GB on my machine
<Blinny> I thought i386 and x86_64 installs use the same kernel now.
<cradek> Filename: pool/main/l/linux/linux-image-2.6.24-16-server_2.6.24-16.30_amd64.deb
<cradek> Description: Linux kernel image for version 2.6.24 on x86/x86_64
<cjwatson> cradek: they share the same package description, but it's a different build
<cjwatson> -server_*_amd64.deb != -server_*_i386.deb
<blueyed> Is /sys/devices/system/cpu/cpu0/cpufreq/ expected to have gone for powernow_k8 recently?
<blueyed>  /sys/devices/system/cpu/cpuidle/current_driver says "acpi_idle", for amd64 and amd64x2
<blueyed> bug 209632
<ubotu> Launchpad bug 209632 in linux "[Hardy] CPU freq scaling does not work anymore with the newest kernel" [Undecided,New] https://launchpad.net/bugs/209632
<blueyed> or rather bug 205087
<ubotu> Launchpad bug 205087 in linux "cpufreq dirs in /sys don't show up" [Undecided,New] https://launchpad.net/bugs/205087
<blueyed> Another bug that would be nice to have fixed: bug 210672
<ubotu> Launchpad bug 210672 in linux "linux-image-2.6.24-13-openvz refuses to boot" [High,Fix committed] https://launchpad.net/bugs/210672
#ubuntu-kernel 2008-04-15
<jdong> hmm bug 86457 seems to have creeped back on Hardy :(
<ubotu> Launchpad bug 86457 in linux-source-2.6.20 "(maemo-on-ubuntu) Scratchbox does not work with latest Feisty kernel image" [Medium,Fix released] https://launchpad.net/bugs/86457
<crimsun> amitk: has there been movement on the "offer a 'reset' button via gnome-media/mixer_applet2 for sound issues" idea tossed about some months ago?
<blueyed> How are hardware specific kernel modules meant to be loaded? There's a autoload block in acpid's init script, but it does not match e.g. drivers/misc/fujitsu-laptop.ko.
<blueyed> Would be nice, if you could provide a hint at bug 196683. Thanks.
<ubotu> Launchpad bug 196683 in linux "fujitsu_laptop not loaded automatically on lifebook p7010" [Undecided,Fix released] https://launchpad.net/bugs/196683
<amitk> crimsun: it will be considered for intrepid, nothing for hardy
<kraut> moin
<tseliot> a quick question: which one of these kernels is realtime and/or xen-enabled? 'server', 'openvz', 'virtual'
<abogani> tseliot: 'rt', 'xen'
<tseliot> abogani: I would like to know more about the kernel flavours which I mentioned above
<alex_joni> might be OT: is there going to be an upgrade path from dapper to hardy?
<tseliot> abogani: since the nvidia driver and/or the fglrx driver can have problems with rt and xen-enabled kernels
<abogani> tseliot: not with -rt.
<alex_joni> abogani: maybe the other way around
<alex_joni> abogani: having nvidia drivers interfering with -rt
<tseliot> abogani: nvidia works well with -rt here however I'm not sure about fglrx
<abogani> tseliot: fglrx should be work too but performance aren't good as like nvidia one.
<pepie34> kool madwifi svn trunk seems to work again with -16 kernel build
<pepie34> (this was not the case with -14 et -15)
<pepie34> thanks for having corrected this regression
<bigcx2> hey all
<bigcx2> i don't know if this is the appropriate outlet for this
<bigcx2> but i read the livecd customization guide on the wiki
<bigcx2> and it says to replace the kernel you just have to build a custom .deb and link it properly
<bigcx2> it seems like there has to be more to it than this
<bigcx2> do you have to mess with the udebs or anything like that?
<BenC> bigcx2: udeb's are for alternate cd install, not livecd
<BenC> bigcx2: so no
<bigcx2> ok
<bigcx2> well i'm trying this in feisty...and i've compiled a stock 2.6.20 kernel with the normal ubuntu live cd config...and i can get it to boot, etc. but it hangs on mounting the root filesystem
<bigcx2> and then it drops me into a busybox shell
<bigcx2> i have no clue why it would be failing there
<bigcx2> i figured i was missing some steps after i read this:
<bigcx2> http://dsplabs.utt.ro/~juve/blog/index.cgi/01147559232
<bigcx2> mentions udebs and such
<abogani> bigcx2: I suppose that you should rebuild lum also
<abogani> BenC: Good Morning, Sir.
<bigcx2> lum?
<amitk> bigcx2: did you build a initramfs?
<bigcx2> yes
<amitk> lum=linux-ubuntu-modules - it contains modules that are not yet part of the kernel
<bigcx2> hm
<amitk> bigcx2: what error did you get? any missing modules?
<BenC> abogani: good morning
<bigcx2> i get up to the splash screen where it says: loading essential drivers [ok]
<bigcx2> running init-premount [ok]
<bigcx2> mounting root filesystem   
<bigcx2> and then it waits for about 10 seconds before dropping the splash screen and spawning a busybox shell
<bigcx2> i don't understand though -- i'm using squashfs and ext3 and i have both of those compiled in properly
<amitk> bigcx2: might be better if you remove the "quiet splash" from the kernel command-line to follow what is happening.
<amitk> bigcx2: squashfs is in LUM
<abogani> bigcx2: AFAIK Squashfs and unionfs modules are live and kicking in LUM but are required to be in initramfs file for boot livecd.
<bigcx2> i compiled it with all those ubuntu extras in
<bigcx2> hm
<bigcx2> well
<bigcx2> here's my steps
<bigcx2> compile default config (no mods) 2.6.20
<amitk> bigcx2: did you make sure that the initramfs contains squashfs? 'update-initramfs -u -v' will tell you
<bigcx2> make-kpkg
<bigcx2> amitk: no, thanks for the tip
<bigcx2> brb
<bigcx2> hey! looks like it's not in initrd
<bigcx2> does that mean i'm missing a make-kpkg option or such?
<amitk> bigcx2: I don't know how to work with make-kpkg, sorry. I use Ubuntu's built-in build system
<johanbr> bigcx2: make-kpkg is not a supported method of building Ubuntu kernels anymore. Try https://help.ubuntu.com/community/Kernel/Compile
<johanbr> Should be okay for 2.6.20, though.
<bigcx2> mk
<bigcx2> hey all
<bigcx2> thanks for your help
<alex_joni> hmm, that is an old page.. should have said it's for breezy (it's outdated even for dapper..), but now bigcx2 is gone
<rtg> smb_tp: your patch in https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/212960/comments/22 is definitely the right thing to do, regardless if it fixes the cx88 bug. Please commit that to the LUM repo.
<ubotu> Launchpad bug 212960 in linux-ubuntu-modules-2.6.24 "Hardy: cx88 NULL pointer dereference" [High,In progress] 
<smb_tp> rtg: Ok, I will commit that ASAP
<rtg> BenC: we need a LUM upload today, before the RC is built.
<rtg> BenC: perhaps that was more declarative then I intended. I think we need a LUM upload. What do you think?
<smb_tp> rtg: He might be recovering from his trip
<rtg> smb_tp: ok, I'll check back later today. If it hasn't been done, then I'll package it up sometime late this afternoon.
<smb_tp> rtg: Ok, I make sure to commit the change to the makefiles
<amitk> jayc_: hi, good morning
<amitk> inuka_desk: good morning
<jayc_> amitk:Hi
<amitk> jayc_: do you have any thing else coming in the next 7-10 days?
<amitk> and is inuka around?
<jayc_> For kernel I will have to check with China team if they are planning to make any changes
<jayc_> For now there is just one config change USB_PERSIST which is not yet in out BUILD
<jayc_> I will check with Alek (PRC) and let you know if he is planning to make any change 
<jayc_> let me check if Inuka is around, it's lunch time here though
<inuka_desk> amitk, morning.. sorry wasnt paying attention to irc.
<inuka_desk> amitk, pushed libdrm...  will push x driver.
<amitk> jayc_: we already have PERSIST enabled. I am pushing a patch for it later today/tomorrow that will allow classmate to work too.
<jayc_> cool
<amitk> inuka_desk: great... i'll push LUM to PPA if we don't upload a new one today.
<mo__> amitk, ok. any ideas which logs to consider for debugging? maybe an dmesg output after skipping the "loading device drivers" with Ctrl+alt+del !?
<amitk> mo__: What is the output of 'apt-cache  policy linux-ubuntu-modules-2.6.24-16-generic'
<mo__> amitk,  Installiert:2.6.24-16.22
<amitk> jayc_: inuka_desk: anything you guys want in hardy needs to come within this week. After that it will only go to PPA
<jayc_> amitk: got it :-)
<amitk> mo__: very strange indeed. smb_tp: mo__ here still sees symptoms similar to those caused by your cx88 patch...
<amitk> mo__: Could you go to /lib/modules/<kernel ver>/kernel/sound and move soundcore.ko out of the way. See if that fixes your 'hang'
<mo__> amitk, brb
<amitk> k
<smb_tp> amitk: my cx88 patch? you mean the one with the mutex problem? was not from me. but what prooblem lockup during boot?
<amitk> smb_tp: right.. the same. I meant the one you are looking at..
<smb_tp> amitk: right. though -16.22 should be without that. Could also be some other hardware. Do we have output without splash and quiet?
<alex_joni> alt-f1/f2 works early in the boot
<amitk> smb_tp: he's gone for a reboot after removing soundcore.ko. That'll confirm if it is the same problem or not..
<smb_tp> amitk: Ok, lets see what happens
<mo__> amitk, it fixed the hang
<amitk> mo__: you can restore soundcore.ko now. Are you sure that you see the hang with -16 though?
<mo__> amitk, yes it occured with -14 and -16, an now i've booted with -16 and it did'nt hang ... but without sound now ... of course!
<smb_tp> Hm, sorry I am not completely up to date. So, it hangs with kernels between -14 and -16 and is related somehow to sound. Now it would be nice to have vm debugging... what sound hardware is there? something beside one soundcard?
<mo__> amitk, sorry i've been occupied
<mo__> amitk, any further ideas ?
<amitk> mo__: smb_tp's questions ^^^
<mo__> amitk,  ok then, thank you so far
<mo__> smb_tp, i still got the soundcore.ko problem with the new linux-ubuntu-modules
<smb_tp> mo__: Sure, I did catch that from your discussion with amit
<mo__> smb_tp, ok sorry, i didn't see that. Is there any output that might help?
<smb_tp> mo__: Yes, generally what audio hw is there. More than one card/device? If booted without "quiet" and "splash" is the anything sticking out when the system is hanging
<mo__> smb_tp, i'v got an pci soundcard (audigy 2) and an onboard via rs780 sound chipset 
<mo__> smb_tp, i'll try to disable (though i thought it is allready) the onboard card in the bios and report if there is anything during boot without quiet, brb
<smb_tp> mo__: This or without those both options, maybe the last printed message does give some hint about which card is currently set up
<alex_joni> is it "normal" to have tons of "udevd" messages flashing by during boot?
<alex_joni> (they don't show up in dmesg or syslog)
<mo__> smb_tp, so: it does hang if the onboard soundcard is DISABLED in bios. It hangs with "loading hardware drivers..."
<smb_tp> mo__: This generic message comes even if you remove quiet and splash from the grub options line?
<smb_tp> mo__: There actually two quiets: one single word somewhere and one on a line which specifies the initrd, kernel etc. 
<mo__> smb_tp, yes yes i know, got some problems with the power supply atm
<smb_tp> mo__: Sure, take your time
<mo__> smb_tp, i got some weird output: lot's of "call trace" with snd_pcm registers
<smb_tp> mo__: That would be interesting. Can you save that and send it to me? Or if a bug report is open attach that?
<mo__> smb_tp, can i mail a dmesg output to you?
<smb_tp> mo__: Sure stefan.bader@canonical.com
<mo__> german?
<smb_tp> mo__: JanC
<smb_tp> mo__: Oops command completion
<mo__> smb_tp, no sorry i just thought stefan bader might me a german name
<smb_tp> mo__: Ist es auch :)
<mo__> smb_tp, achso .. ja
<mo__> smb_tp, so hab dmesg lspci uname und asound outputs angehÃ¤ngt
<smb_tp> mo__: Ok, danke. Lets see...
<mo__> smb_tp, ich hab zu danken :-)
<mo__> smb_tp, er hÃ¤ngt bei 37.813198 , vor dem loop: module loaded
<smb_tp> mo__: Just so that others (as amit) can understand too: there have been kernel oops involved. And the saa7134 driver. Which is one of those I suspect to have been compiled without the right headers
<mo__> smb_tp, ok. i do understand exactly nothing at that level :)
<smb_tp> mo__: Could you try the lum version in my ppa? https://launchpad.net/~stefan-bader-canonical/+archive
<mo__> smb_tp, sure. just a moment..
<amitk> smb_tp: interesting...
<smb_tp> amitk: what?
<amitk> smb_tp: regarding the saa7134 drivers...
<amitk> now I am down to a few more git bisects to find our problem child patch that kills classmate suspend :)
<mo__> smb_tp,  with ur modules, it now really freezes :)
<smb_tp> mo__: Any dying messages?
<mo__> smb_tp, yeah just the same ones, at [end trace ....]
<mo__> smb_tp,  i did not really freeze, its just the same error
<smb_tp> mo__: Hm, ok. Pity, it just sounds like a good trail. Seems I have to think a bit more.
<mo__> apt-cache policy linux-ubuntu-modules-2.6.24-16-generic says "Installiert: 2.6.24-16.23ubuntu1" ... so i did correctly instal ur version !?
<smb_tp> mo__: Sound like it did. Well, I am out of here for a while...
<mo__> smb_tp, ok. strange :-) thank u bb
<mo__> if i should test smth, mo@uberhost.de
<greearb> Hello.  Anyone know how to create udebs for a standard kernel.org kernel using Ubuntu 7.10 or 8.04-beta?
<greearb> I'm trying to remaster a live cd with a modified kernel and having no luck figuring out the udebs portion...
<alex_joni> greearb: you working on an alternate install cd?
<greearb> yes
<alex_joni> I have some older info.. maybe it helps: http://dsplabs.cs.utt.ro/~juve/blog/index.cgi/01147559232
<alex_joni> (I used that back on breezy, when the default cd had udebs too..)
<greearb> heh, found that already..but it seems linux-kernel-di-* doesn't work on the latest ubuntu
<greearb> someone said the udebs were built automatically when the kernel is built..but I surely can't figure out how and can't find them anywhere when I build with make-kpkg
<alex_joni> well.. that depends how you build it
<alex_joni> if you build it with make-kpkg, you won't get udebs
<alex_joni> if you build it using debian/rules then you can get them
<greearb> ahhh, how to build it then?
<alex_joni> but for that you need to start with the ubuntu kernel source
<alex_joni> apt-get source linux-source-..
<greearb> ok, I can try that
<alex_joni> (or grab it from git..)
<alex_joni> greearb: it's past 1am here.. I won't be around long..
<greearb> no problem
<alex_joni> good luck though ;)
<greearb> let me reboot back into 7.10, I had already backported my changes to their 2.6.22 kernel
<alex_joni> I used a custom flavour for the stuff I did
<greearb> you wrote that blog?
<alex_joni> that way I don't collide with ubuntu version numbers & all
<alex_joni> greearb: yeah, a while ago :)
<greearb> ok, ignore my email if it ever gets to you..I tried to bother you earlier today :)
<alex_joni> ok, I will
<alex_joni> seems it was in 2006 when I wrote that
<greearb> do you happen to know if I need any arguments to the debian/rules command ?
<alex_joni> yeah, you surely do
<alex_joni> I used: DEB_BUILD_OPTIONS=parallel=2 NOEXTRAS=1 fakeroot debian/rules custom-binary-rtai
<alex_joni> (because I only wanted the custom flavour I added, called rtai, and only the binary package)
<alex_joni> but you probably want: ... debian/rules binary-udebs
<greearb> no rule to make that target
<alex_joni> which one?
<greearb> binary-udebs or binary-udeb
<alex_joni> greearb: look in debian/rules, over here it includes debian/rules.d/5-udebs.mk
<alex_joni> you maybe want to create debian/control first..
<greearb> what version of kernel source?  there is a debian/ruleset/ dir in my .22 kernel
<alex_joni> hmm.. I'm looking at .24 (from hardy)
<greearb> ok, I can forward port if needed, let me reboot back into hardy
<greearb> it's surely easier to port kernel code than figure out how to build live-cds :)
<greearb> hrm, nothing at all in the debian/ dir after 'apt-get install linux-source' and tar -xvjf ...
<alex_joni> I said apt-get source linux-source
<alex_joni> not apt-get install linux-source
#ubuntu-kernel 2008-04-16
<greearb> er, ok..trying again
<greearb> this is just a small little package?
<greearb> linux-meta-.... ?
<amitk> greearb: you need to get 'apt-get source linux-image-2.6.24-16-generic'
<greearb> ok, sorry for my confusion...never used debian so much...downloading that now
<alex_joni> amitk: you wouldn't be familiar with the livecd by any chance?
<amitk> greearb: it is confusing even to me sometimes :)
<alex_joni> I'm looking for the list of packages which get installed by default.. and I can't seem to remember where that was
<amitk> alex_joni: not particularly and definitely not at 2am :)
<alex_joni> amitk: same TZ as here ;)
<amitk> alex_joni: you want to catch cjwatson when he is online
<greearb> ok, that rules.d looks correct now.  It'll take me a few hours to port my patch forward probably...
<alex_joni> greearb: if you have a single patch file it's not that complicated
<alex_joni> I would still create a custom flavour (call it greearb)
<greearb> heh, I have a large number of patches to various parts of the kernel
<alex_joni> then look at debian/binary-custom.d
<greearb> ok
<alex_joni> create a new folder called greearb ;) and put the patches in there..
<alex_joni> there's a README which will guide you further
<greearb> ok, will look at all that...I first need to get the patches so that they will apply to this kernel.
<alex_joni> (not particularely sure it works with udebs for custom flavours.. but it should afaik)
<bigcx2> hey all
<bigcx2> i was in here this morning asking about squashfs
<bigcx2> i've selected squashfs inside my kernel config
<bigcx2> and i've run  make-kpkg --append-to-version -squashfs --revision r1 --initrd --config oldconfig kernel_image
<bigcx2> but...
<bigcx2> when i run update-initramfs -u -v i don't see that it's getting compiled into the kernel
<bigcx2> any clues?
<cjwatson> alex_joni: given a live CD, the simplest way is to look at /casper/filesystem.manifest-desktop
<alex_joni> cjwatson: I just figured that out.. thanks a lot anyway
<alex_joni> btw.. I read about 20 minutes of sources (ubiquity) until I reached that conclusion :D
<cjwatson> alex_joni: of course that's several steps down the chain; in general, it's the dependency-expansion of a bunch of "seeds"
<alex_joni> cjwatson: short question though.. if I have a package I'm interested in.. I only need to put it in there, not it's dependencies too.. right?
<cjwatson> no, you need to put everything in there
<alex_joni> is it me, or the older manifest-desktop didn't have versions?
<cjwatson> there are ways to automate it (which we use in our own build processes) but they're probably overkill for a one-shot deal
<alex_joni> yeah, sure.. I only have 1 package + dependencies
<cjwatson> alex_joni: it's you; the livefs manifests have had versions since they were created
<cjwatson> (the keyword for the automation in question is "germinate")
<alex_joni> huh.. germinate? sounds fun
<cjwatson> sample dependency-expanded lists of packages for Ubuntu are at http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.hardy/
<cjwatson> germinate: vt. to cause seeds to grow
<alex_joni> cjwatson: cool.. probably extends my knowledge absorbing atm
<cjwatson> yeah, it's only if you care about how we maintain it
<cjwatson> very much designed so that ordinary Ubuntu developers can forget about the process and not have to edit lists of packages every time a dependency changes
<alex_joni> cjwatson: I do this once every couple of years/versions
<alex_joni> and each time it's more complex (and automated)
<alex_joni> so I'm not sure if anything I know now will be valid by 10.4 or whatever the next LTS will be :D
<alex_joni> cjwatson: it looks like quite a lot of work
<cjwatson> this particular bit of it has not changed a whole lot since 6.06
<cjwatson> also, I documented the manifest handling in ubiquity/doc/README a while back
<cjwatson> yeah, manifest-desktop was created while ubiquity was still called espresso, so pre-release dapper
<alex_joni> yeah, I noticed a couple of things are the same since dapper
<alex_joni> (most of the customization part of the LiveCD - squashfs, etc)
<alex_joni> cjwatson: I notice the docs on the wiki tell one to regenerate the filesystem.manifest then cp that as filesystem.manifest-desktop
<alex_joni> so I guess that takes care of things
<greearb> alex_joni, I think I have all of that documented, except for the new kernel...I'll be happy to email it to you...
<alex_joni> greearb: feel free if you think I can do anything with it :)
<cjwatson> alex_joni: unwise to cp, would need to cp and remove stuff
<cjwatson> I'm afraid I haven't been able to keep track of what people have been writing in the wiki - that didn't come from me
<greearb> there are about 10 wikis, at least, related to this :)
<alex_joni> cjwatson: well.. they do remove ubiquity
 * alex_joni meant https://help.ubuntu.com/community/LiveCDCustomization
<greearb> most similar to others...and most slightly wrong it seems, depending on your version and what you are trying to do.
<cjwatson> alex_joni: I would be inclined to manually add the things you want to both, rather than trying to duplicate the list that's removed
<cjwatson> occasionally I do try to dive in and clean stuff out, but labours of Heracles etc. :-)
<alex_joni> cjwatson: how about after doing an apt-get update && upgrade.. which just pulled another 450 packages in?
 * alex_joni doesn't want to think about updating that list by hand
<alex_joni> cjwatson: I'll do the cp right now (only temp. version for testing), then after the final hardy CD is released, I'll be careful to add only a couple of packages
<cjwatson> alex_joni: in that case diff the manifests beforehand and take account of what's removed
<cjwatson> alex_joni: ubiquity doesn't actually care about the versions in the manifest files - the versions there are just informational
<cjwatson> so if you literally did upgrade and not dist-upgrade, then it won't actually matter
<cjwatson> (except cosmetically)
<alex_joni> heh, ok.. good to know
<alex_joni> btw, whoever did parallel makesquashfs is my hero
<alex_joni> Parallel mksquashfs: Using 2 processors
<greearb> yeah, it only takes maybe 10 minutes now :)
<alex_joni> cjwatson: thanks again, I'm off to bed now
<jdong> alex_joni: yeah, multithreaded squashing is my best friend too
<bigcx2> anybody have any clues about the squashfs stuff?
<greearb> like what?
<bigcx2> i'm trying to compile squashfs into a 2.6.20 (ubuntu'ized) kernel
<bigcx2> and it works but it never makes into the ramdisk?
<bigcx2> doing an update-initramfs -u -v doesn't show it in there
<bigcx2> this is for a livecd
<bigcx2> so whenever i boot
<bigcx2> it fails on mounting the root filesystem
<bigcx2> which is obviously squashfs
<bigcx2> i'm using make-kpkg with --initrd
<bigcx2> if that helps at all
<bigcx2> i'm not sure what else to try?
<greearb> it seems a big pain to get a kernel updated on a live cd image...I'm trying to do the same myself.
<bigcx2> apparently
<bigcx2> have you gotten it to boot completely?
<greearb> I'm hacking my patch set now..when it compiles, hopefully I'll get a bit further...  I'll write it up then and post it somewhere
<greearb> not with a custom kernel, but I did with an updated ubuntu kernel
<greearb> ie, something you can get with apt-get install ...
<bigcx2> ahh -- what k version, what ubuntu version?
<greearb> 7.10 (er, current stable..whatever that is), and 8.04-beta is what I'm working on now.
<bigcx2> i c
<bigcx2> yea i'm hacking on feisty, which sucks -- the rest of the world has moved on lol
<greearb> I'm guessing it will all be similar..but will be more sure when I actually get something working :)
<bigcx2> hah yea
<greearb> I got the debian/rules custom-binary-foo to build, but that didn't do udebs.  There is a binary-udebs target that seems to be compiling everything from scratch again...  Do I need to somehow tell it that it's part of the 'foo' build?
<bigcx2> i talked to someone in here this morning that said udebs were only for the alternate install cd
<greearb> well, I'm trying to build an alternate install cd, so that's probably want I want
<bigcx2> oh lol
<bigcx2> in that case this might point you in the right direction
<bigcx2> http://dsplabs.utt.ro/~juve/blog/index.cgi/01147559232
<greearb> yep, found it already..it's for an older release, but some of it might still work
<bigcx2> yea..isn't that what you were hoping for earlier :)
<kraut> moin
<TomJaeger> Hi.  What's the status on bug #124406?
<ubotu> Launchpad bug 124406 in linux "Keyboard keys get stuck and repeat (Feisty, Gutsy)" [Unknown,Confirmed] https://launchpad.net/bugs/124406
<TomJaeger> more specifically, the issue Helge and I are seeing
<TomJaeger> Also, feel free to try and reproduce it, I don't think it's tied to any particular hardware
<alex_joni> short question on linux-meta.. trying to build debs for my custom flavour, but somehow the deps are twisted
<alex_joni> debian/control holds this dependency: linux-headers-$(kernel-abi-version)-rtai
<alex_joni> however, after the package gets generated I see only linux-headers-2.6.24--rtai (missing the abi '16')
<alex_joni> (looks the same for the traditional stuff I didn't touch.. like -rt)
<alex_joni> hmm.. crap.. n/m me.. was missing gawk
<TomJaeger> bug #124406 anyone?
<ubotu> Launchpad bug 124406 in linux "Keyboard keys get stuck and repeat (Feisty, Gutsy)" [Unknown,Confirmed] https://launchpad.net/bugs/124406
<TomJaeger> I should say that there is a patch and it just needs to be applied
<alex_joni> what's a reason for an ABI bump?
<thom> the ABI changing
<jdong> thom: you have just made my day :D
<alex_joni> thom: funny..
<alex_joni> is it supposed to happen on released versions (e.g. hardy after it's shipped out) ?
<cjwatson> it can happen, yes
<cjwatson> security fixes can change the module ABI from time to time
<cjwatson> thom's response is actually pretty accurate, but if you want something more detailed, the ABI in question is the interface between the kernel and modules; simplifying massively, if exported functions change their signatures such that modules need to be rebuilt to cope, that's an ABI change
<alex_joni> cjwatson: I was vaguely familiar with what ABI stands for.. probably my question was bogus :)
<cjwatson> we've had to change the ABI after release in almost every Ubuntu release so far
<cjwatson> gutsy has been lucky so far
<cjwatson> but all of dapper, edgy, feisty have had post-release ABI bumps
<alex_joni> yeah, but in dapper it wasn't that problematic for me
<infinity> alex_joni: What are you finding problematic about ABI bumps, post-dapper?
<alex_joni> infinity: having a custom flavour is what makes it problematic
<alex_joni> and having to deal with lum, lrm, lbm and meta packages for all that
<alex_joni> infinity: don't understand me wrong.. what you guys have in place is a great infrastructure.. but it's a bit overengineered for my own needs...
<infinity> Automation is key. :)
<alex_joni> infinity: I understand.. but atm I'm doing the automation by hand.. step by step :)
<infinity> "Oh look, new kernel"; fetch-sources; apply-local-patches; push-big-red-build-button; go-for-coffee.
<alex_joni> infinity: yeah, but the thing started as a livecd/install environment for our app (which contains kernel modules, and thus kernel-ver dependent)
<alex_joni> so when ABI changes, and new kernels come out (which through git is quite easy to track), I still have to push a new release on our own software
<greearb> ok, back to trying to install a custom kernel on a live-cd.  Turns out the whole 'udeb' thing was a red herring, it doesn't build initrds for the live-cd.
<greearb> I do have some good notes for anyone who wants to do that though....
<greearb> now, my problem is that I need to compile the headers for my custom kernel.
<greearb> I got the source:  apt-get source linux-ubuntu-modules-2.6.24
<greearb> then attempted to build them:
<greearb> akeroot debian/rules binary-arch arch=i386 flavours=foo
<greearb> however, the auto-generated debian/control is still relating to generic and not foo.  I tried setting debian/d-i/kernel-versions to something with 'foo' in it, but it still does not fully work.
<greearb> Since the debian/control file is regenerated each time, I can't even run 'sed' tricks to force it right.
<greearb> suggestions are welcome :)
<alex_joni> greearb: you need debian/rules debian/control first
<alex_joni> but that assumes you changed the needed places 
<greearb> can you be any more specific?  That doesn't make so much sense :)
<alex_joni> control.stub
<alex_joni> you need to add descriptions for you flav
<alex_joni> then you need to add you falvour to at least rules.d/i386.mk:custom_flavours
<alex_joni> and to rules.d/0-common-vars.mk:all_custom_flavours
<greearb> ok, will try that in a sec..
<alex_joni> btw, back on breezy I needed two things
<alex_joni> one is kernel + initrd (you can get those from /boot/ from you regular machine)
<alex_joni> and the other is the udebs which get loaded lateron
<alex_joni> brb
<greearb> don't think I need the udebs, seems that is only for non-live CD builds
<alex_joni> cjwatson: any ideas why I would get "/init: .:  159: Can't open /scripts/casper" ?
<alex_joni> (I'll dig for it, but thought you might know without looking..)
<greearb> seems control.stub might be auto-generated from control.stub.in ?
<alex_joni> greearb: you're getting warmer :P
<greearb> no luck
<greearb> building with:  fakeroot debian/rules binary-arch arch=i386 flavours=foo
<greearb> is that right?
<alex_joni> nope
<alex_joni> I use fakeroot debian/rules custom-binary-arch=rtai iirc
<greearb> for the headers as well?
<greearb> I'm not building the kernel here...just the headers package
<alex_joni> I use fakeroot debian/rules custom-binary-rtai
<greearb> ok
<alex_joni> that builds image & headers too
<alex_joni> brb
<greearb> bleh, I mean modules, not headers.  I need the cramfs modules and such
<greearb> will try poking some more
<alex_joni> cjwatson: changing boot option "boot=casper" to "boot=local" makes it go a bit faster .. but it hangs furtheron
<alex_joni> cjwatson: I also get _tons_ of udevd messages so anything usefull is lost somewhere..
<greearb> ahh, by hacking debian/rules to add a fixup script after the debian/control is generated, I seem to be making progress
<greearb> got udebs for free, too :)
<greearb> got it to boot!  But, seems the gnome toolbar died, so no way I can find to open a bash window to check things in more detail.
<greearb> not sure if it's a qemu issue or something else
<alex_joni> cjwatson: probably didn't update initramfs (mkinitramfs -o /initrd.gz 2.6.24-16-rtai)
<cjwatson> alex_joni: you forgot to install casper before running update-initramfs -u?
<cjwatson> (or other mkinitramfs method)
<alex_joni> cjwatson: probably just borked the initramfs (used the install one, not the live-cd generated one)
<cjwatson> oh, don't do that :)
<greearb> any idea what the apt-get package for the 'install' desktop icon on the live-cd is called?  I managed to uninstall mine somehow...
<cjwatson> greearb: the desktop file is in ubiquity, but casper is what's responsible for getting it onto the desktop
<cjwatson> see scripts/casper-bottom/10adduser in the casper source package
<greearb> ok, I removed a bunch of things...looks like I lost it to a dependency..will try re-adding, or if necessary, start over and be more careful.
<alex_joni> cjwatson: I just booted the live cd I made :)
<alex_joni> (this is from the live .. so it works :D)
 * alex_joni is happy
<greearb> congratz!
<greearb> here are my notes.  This worked for me, though I've yet to run it all from a clean install, so I might be missing a few things yet.
<greearb> http://www.candelatech.com/oss/ubuntu-live-notes.txt
<greearb> feel free to link to them from any of the wiki pages and/or use this in any manner (including outright copying it somewhere else)
<alex_joni> greearb: you missed an 'e' on welcome.
<greearb> fixed :)
<TomJaeger> What does the kernel team think about the patch attached to bug #124406?
<ubotu> Launchpad bug 124406 in linux "Keyboard keys get stuck and repeat (Feisty, Gutsy)" [Unknown,Confirmed] https://launchpad.net/bugs/124406
<TomJaeger> ping
<smb_tp> TomJaeger: Hi Tom, sorry I did not have much time today to look at it. I also would like to discuss this with the others.
<TomJaeger> cool.  I should mention that patch fixes a different (but nevertheless very annoying) problem than the original report was about.
<smb_tp> TomJaeger: I am not sure I can promise much. If I look (not very thouroughly, I admit) at the patch it seems to change the scheduler and feels not like something to do that late in teh cycle. 
<smb_tp> s/and feels/and taht feels/
<smb_tp> s/taht/that/ (can't type any more)
<TomJaeger> That's why I bisected the issue right when I noticed how I could reproduce it.
<TomJaeger> This has been fixed upstream for almost two months now, and it's not like it makes some fundamental changes to the scheduler
<cjwatson> can I suggest that it might be worth considering this for 8.04.1 rather than 8.04?
<cjwatson> then there'll be time to find out if it breaks the world when applied to Ubuntu
<cjwatson> assuming that it goes in early in the 8.04.1 period
<smb_tp> That would be something I personally would feel better with. But surely I'd like to ask the others, too.
#ubuntu-kernel 2008-04-17
<greearb> I just saw this when trying to compile the latest 2.6.24-16 kernel,  Looks like a typo got introduced:
<greearb> /usr/src/ben/linux-2.6.24/debian/build/custom-source-lanforge/drivers/net/usb/asix.c:742: error: stray '\35' in program
<greearb> possibly something I did..but I don't think so.
<cjwatson> don't see that here
<cjwatson>         .get_eeprom             = asix_get_eeprom,
<cjwatson> ^- line 742
<greearb> ok, then maybe I had some glitch here
<greearb> easily fixed at any rate
<kraut> moin
<Jeeves_> Hello there.
<Jeeves_> I've got a question about https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/58170
<ubotu> Launchpad bug 58170 in linux-source-2.6.15 "Kernel race condition if nfs mounts present on real or virtual nodes [kernel BUG at lib/radix-tree.c]" [Undecided,Confirmed] 
<Jeeves_> That one, indeed. Thank you ubotu :)
<Jeeves_> I was wondering what the fix should be for Dapper users.
<rtg> smb_tp: good job on the cx88 NULL pointer bug. Do you think https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/212271 is likely the same issue?
<ubotu> Launchpad bug 212271 in linux-ubuntu-modules-2.6.24 "2.6.24-15-generic: saa7134-alsa makes HAL to fail" [High,In progress] 
<smb_tp> rtg: Yes, I spoke with one owning that hardware and he had hal failures as a follow up. Those were fiexed with the ppa version as well
<rtg> smb_tp: cool. I'll see about getting LUM uploaded today.
<smb_tp> rtg: That would be great. Luckily saa7134 and cx88 were the only drivers in lum (except for btsco which Colin fixed before) to include alsa
<LifeHacker> hi folks. I would want to know whether I can use ipw3945 with the latest 2.6.24 
<maks_> use iwlwifi
<maks_> ipw3945 is dead
<LifeHacker> the newer iwl3945 is miserable and googling confirms. I just upgraded to hardy.
<LifeHacker> maks_, and I am unable to conect to the network
<maks_> did you upgrade your firmware?
<maks_> very happy on iwlwifi - no stupid binary daemon
<maks_> needs only sometimes to be unloaded
<LifeHacker> maks_, no. I just upgraded to hardy from gutsy. and I find ipw3945 missing. instead the iwl3945 loaded. does that mean the firmware might not have got upgraded?
<maks_> boah you are mixing things
<maks_> LifeHacker: #ubuntu is user support, thanks.
<LifeHacker> thanks maks_ 
<mo> smb_tp, good evening :)
<smb_tp> mo: Or afternoon, as it is here. ;-)
<mo> smb_tp, sure, whereever u are 
<smb_tp> mo: yup
<mo> smb_tp, i don't know if this is related to the problem you solved for me, but the fglrx module is not loading properly
<smb_tp> mo: No I would say this is a different story. No audio driver involved there.
<mo> smb_tp, ok so this was only related to the audio driver,
<mo> smb_tp, still, i got no idea y the fglrx module is not loading under -16 :)
<smb_tp> mo: Yes, or to be more precise to the ones used by tv cards. Can't be a generic problem since it loads on my machine.
<smb_tp> mo: But there might be other problem. Have you looked at launchpad bug, whether there is something similar to your probs
<smb_tp> ?
<mo> smb_tp, i'm on that right now, but i didn't find anything by now
<smb_tp> mo: Do you see any error messages in dmesg, when trying to load?
<mo> smb_tp, fglrx is not loaded at bootime, modprobe just throws an "FATAL: Error running install command for fglrx" and dmesg tells me exactly nothing :)
<smb_tp> mo: And you tried to activate it via the restricted drivers manager?
<mo> yes, it was installed under the -12 kernel and doesn't showup anymore under the restricted driver dialogue. i'll reboot just to be sure. brb
<mo> smb_tp, still the same, an no dmesg output
<smb_tp> mo: To check whether the packages are there: is there something installed for linux-restriced-modules-generic and linux-restricted-modules-common? (with apt-cache policy <name>)
<mo> smb_tp, sure 16.18 and .12-16.34
<smb_tp> Ok, same as I got
<infinity> mo: Try "sudo sh -x /sbin/lrm-video fglrx" and see if it works manually.
<infinity> mo: (The "sh -x" is the get the shell to spew debug info)
<mo> smb_tp, module is still not loaded
<smb_tp> mo: no debug info? but maybe you should discuss with infinity. 
<mo> smb_tp,  yes and i don't want to waste your time
<mo> smb_tp, sorry for disturbing you
<smb_tp> mo: It's not as much wasting my time. I rather think I might not be able to help you as much
<mo> smb_tp, ok thank you :-) well that's strange, there is really no debug info apart from the script
<infinity> "apart from the script"...?
<infinity> The script is what's failing here, seeing why would be nice. :)
<mo> indeeed
<infinity> So, really, what does "sudo sh -x /sbin/lrm-video fglrx" do/say?  Pastebin it if it's large.
<mo> it's just pasting the commands executed by the lrm-video script
<infinity> Yes... And the final conclusion of those..?
<mo> all output in your query
<cazo66753> <param name="nick" value="ClaudioC">
<mo_> thank you again, bye
<sioux> all sleaping?
<alex_joni> BenC: hi
<BenC> hey...brb
<alex_joni> wb :)
<alex_joni> BenC: was wondering if -16 will be the final one?
<BenC> alex_joni: we may have another upload coming, but I'm hoping the ABI will remain the same
<alex_joni> sounds good :)
<bewst> I'm desperately trying to address https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/121653 before the release and was hoping to get some attention from the devs.  Any takers?  It seemed to be fixed but recent updates broke it again.
<ubotu> Launchpad bug 121653 in linux-restricted-modules-2.6.22 "[gutsy] fglrx breaks over suspend/resume" [Wishlist,Confirmed] 
#ubuntu-kernel 2008-04-18
<DB42> to whoever fixed the usb quirk for the "microsoft sound system 80" thanks, it works perfectly now
<Johninky> hello all
<Johninky> Can I ask a quick question please, might take a long answer
<Johninky> How can I take .inf file and create a driver for ubuntu 8.04
<Johninky> or would it work, I have tried ndisgtk and  ndiswrapper
<mjg59> Johninky: You can't
<Johninky> I can what
<Johninky> cant^^
<Johninky> oh never mind I was a little slow on that one
<Johninky> sorry
<kraut> moin
<DB42> i moved from 7.10 to 8.04 in my laptop and now i have no wifi and no ethernet
<DB42> can i downgrade to ipw3945 ? 
<DB42> ipl is giving me lots of errors and isn't working
<DB42> is there a ipw3945 .deb i can d/l for 8.04 ?
<DB42> is there an IPW3945 PACKAGE for UBUNTU 8.04 ??
<rtg> DB42: install linux-backports-modules in order to get iwlwifi 1.2.25
<DB42> ok i've submitted bug report with my problem: https://bugs.launchpad.net/ubuntu/+bug/219268
<ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New] 
<DB42> rtg: hmm
<rtg> DB42: support in 1.2.25 for the 3945 is a little better.
<DB42> rtg: which one is for the -generic ?
<DB42> rtg: is there a way to revert to ipw /
<DB42> for the time being ?
<DB42> (without moving to 2.6.22)
<rtg> DB42: ipw is gone.
<DB42> no .deb package ? :|
<DB42> i tried compiling it, no go
<DB42> rtg: which backports do i need to install for 2.6.24-16-generic ?
<rtg> DB42: try 'sudo apt-get install linux-backports-modules-hardy'
<DB42> installing now
<DB42> rebooting laptop, let's hope for the best
<DB42> i need to do anything after instaling and before rebooting ?
<rtg> DB42: nope
<DB42> btw this is a backport from what ? 8.10 ?
<DB42> :( same error
<DB42> problem still there
<DB42> it's 1.2.25
<DB42> rtg: any other idea ?
<rtg> DB42: looking...
<DB42> btw, using wicd as network manager if it's of any use
<rtg> DB42: what kind of AP connection are you trying to make? WPA Enterprise? Add that to the LP report as well as any noise from /var/log/syslog. Attach it to the LP report, not pastebin. I'll make sure Intel sees the bug report.
<DB42> WPA yes
<DB42> hmm.. i'll try an unsecure one, and see if it works
<rtg> DB42: personal or enterprise?
<DB42> personal
<mdz> BenC: is it possible to do sysrq-like actions programmatically, e.g. through sysfs or proc?
<DB42> rtg: another problem
<DB42> my ethernet card isn't working in 2.6.24-16-generic as well ...
<mdz> there's /proc/sysrq-trigger...
<DB42> hwlist -C networ tells me it's disabled
<BenC> mdz: probably, but if the hang is "system", then I'm not sure that would help
<mdz> BenC: yeah
<rtg> DB42: the rt8139 is well supported. Is this an HP laptop?
<mdz> is it possible to serially debug our kernel without modifications?
<BenC> I'm getting a base install so I can run the erase command from command line
<DB42> rtg: check the bug report, lenovo 3000 n100
<DB42> it's an 8139too driver
<DB42> i connect a ethernet cable and i don't get in dmesg "link up or down" but the module for 8139too is loaded
<rtg> DB42: i see it now. Is the cable plugged in (since you've been using wireless) ?
<DB42> yeah
<rtg> DB42: never mind
<DB42> it's plugged in, but doesn't apear in ifconfig
<DB42> and nothing in dmesg
<BenC> cjwatson, soren: does blockdev-wipe run on the physical drive, or on the encrypted lvm?
<mdz> BenC: the former
<rtg> DB42: 'ifconfig -a' ?
<BenC> So the fact that this happens for encrypted is just that blockdev-wipe gets run when it normally doesn't
<mdz> BenC: well, it runs on the device underlying the encrypted one, AIUI
<DB42> rtG: i see eth0 and eth1
<mdz> not the physical drive but an unencrypted block device
<BenC> mdz: so the wipe isn't being encrypted, right?
<rtg> DB42: eth0 is likely the realtek controller.
<DB42> yeap
<BenC> ok
<DB42> check my dmesg on the bug report
<mdz> BenC: I think not, but I don't have it in front of me
<DB42> it has the RealTek anme there
<mdz> alt+f2 during the erase and ps
<rtg> DB42: what happens if you 'sudo ifconfig eth0 up'
<DB42> rtg: i need to go to a place with ethernet connection and check :)
<DB42> sec
<mdz> BenC: lib/crypto-base.sh:crypto_wipe_device in partman-crypto
<mdz> BenC: seems to say it is in fact writing through dm-crypt when it does the wipe
<DB42> rtg: thanks, eth works now
<rtg> DB42: so, pluggin it in to a switch fixed it?
<DB42> no
<DB42> ifconfig eth0 up did
<rtg> DB42: hmm. Are you running NetworkManager?
<DB42> no, as i said i'm using wicd
<rtg> DB42: wicd only works on wireless, right?
<DB42> NM didn't work well with my wireless card in 7.10
<DB42> nop, wired as well
<rtg> DB42: you ought to try NM again. maybe it'll work better with the i3945.
<DB42> rtg: i'm trying to conect unencrtyped now and see if it's ok
<DB42> how so ? the problem is in the microcode..
<DB42> and when i boot to 2.4.22 for wifi now (on 8.04) i still need the wicd
<DB42> and i can't have them both
<rtg> DB42: indeed, but it could be a function of the kind of packets being transmitted. who knows.
<BenC> mdz: so does d-i call blockdev-wipe for this progress?
<mdz> BenC: yes
<rtg> DB42: you could boot with the lice-cd and try it. that way you don't have to re-install.
<rtg> s/lice-cd/live-cd/
<DB42> rtg: i rather d/l it when the final is out :|
<mdz>         /bin/blockdev-wipe -s 65536 $dev > $fifo &
<DB42> also don't have media to burn it on
<mdz> [...]        while read x <&9; do
<mdz>                 db_progress STEP 1
<rtg> DB42: the RC was announced an hour ago.
<DB42> btw, i reported a bug in my sound card and did a system update 2 days after, and the bug disappered :)
<DB42> that was pretty cool
<rtg> DB42: probably a function of updated ALSA in LUM.
<BenC> mdz: I can't get blockdev-wipe to reproduce from command line
<DB42> the model i had needed to be added to usbquirks.h or so
<DB42> (it worked ok in 7.10, but not in 8.04)
<mdz> BenC: soren was trying that as well
<BenC> The fact that blockdev-wipe output is useless after 24 lines doesn't help either
<BenC> wonder if I can easily wrap it in some shell script to put the asterisks on a single line instead of separate
<CYREX> I see that the release candidate includes the 2.6.24-16.30 of Ubuntu but will the final version include Kernel 2.6.25 since it came out yesterday
<mdz> BenC: | grep -n --line-buffered ''
<DB42> CYREX: how so ?
<rtg> CYREX: no
<DB42> CYREX: 8.04 is freezed already
<CYREX> is frozen mean no kernel changing
<DB42> mean no change at all besides bug fixes
<DB42> mean no change at all besides bug fixes
<CYREX> oki thank you
<BenC> mdz: not particularly supported by busybox grep
<BenC> :)
<mdz> oh, you're in d-i
<BenC> figure that's the best way to repro it
<mdz> BenC: |while read x; do date; done ?
<mdz> or similar
<DB42> rtg: i'm trying a manual connection, how do i list SSIDs ?
<rtg> DB42: sudo iwlist wlan0 scanning
<DB42> i get "Failed to read scan data: Resource temporarily unavilable"
<rtg> DB42: probably because the firmware has crashed.
<DB42> tried removing / reloading the iwl, didn't help ..
<DB42> i'll try restarting with no wifi, seing if it helps
<DB42> how do i blacklist auto-loading of iwl3945 @ boot ?
<DB42> (in kernel boot lie)
<BenC> mdz: | while read x; do echo -n "$x"; done
<rtg> DB42: add it to /etc/modprobe.d/blacklist
<BenC> that worked
<DB42> rtg: yeah i wanted it in boot though (since i already reboot)
<DB42> but nm, i did a check
<DB42> it happens as soon as i type in CLI "iwlist eth1 scan" without even using a network manager
<DB42> i updated my bug report to reflect it
<DB42> https://bugs.launchpad.net/ubuntu/+bug/219268
<ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New] 
<DB42> welp for now i guess i'll go back to 2.4.24
<DB42> i mean 2.6.22 ... :)
<DB42> rtg: no .deb package no backport no nothing for ipw ? :|
<rtg> DB42: nope. the regulatory daemon is gone.
<DB42> what is "LBM" and "LUM" ?
<rtg> linux-backports-modules, linux-ubuntu-modules
<DB42> k
<DB42> now for the big test, checking if hibernation is fixed in 8.04 for my laptop :)
<DB42> yippy
<DB42> cool, the cpu fan seems to work after hibernation
<DB42> it didn't in 7.10
<DB42> so rtg need anything else for my report ?
<DB42> will the intel people respond on the bug report itself ?
<rtg> DB42: they might, but I think they are losing interest in 3945 in favor or more recent adapters (4965)
<DB42> ouch :(
<DB42> well if this isn't a specific case of mine, there are still lots of people with 3945 out there (the lenovo 3000 n100 is popular i belive)
<DB42> i also think it might be tramuatic for some users that load ubuntu and won't have wifi
<rtg> DB42: it doesn't fail for everyone, but I have seen the microcode issue before.
<DB42> is there any documentation of the chipset that can tell me what is that specific error ?
<rtg> DB42: not that I'm aware of
<BenC> mdz: I'm starting to wonder if this is a blockdev-wipe issue...from one run to the next, it goes at different speeds
<BenC> like now I'm at 47%, and it would have been done by now on the run before this
<mdz> BenC: what are you using for the source? urandom?
<mdz> BenC: there's some debugging available if you recompile it, but it's pretty dead simple
<BenC> mdz: the stock d-i one, so it's /dev/zero
<BenC> mdz: does d-i use default /dev/zero, or does it -f=/dev/urandom?
<mdz> BenC: urandom, I believe
<BenC> where is the d-i log kept nowadays?
<mdz> BenC: oh, nm
<mdz> it's using /dev/zero, but writing through a random cryptoloop
<BenC> ok
<mdz> so blockdev-wipe writes zeros, but what gets written to the device should be random
<BenC> ok
<mdz> maybe the intervening cryptoloop is what's getting hung up
<mdz> are you setting that up in your test environment?
<BenC> well, what gets written isn't really random, just encrypted 0's
 * BenC chuckles at encrypted 0's
<rtg> BenC: maybe it would go faster with unencrypted zeroes :)
<BenC> -f=/dev/unencrypted-zeroes
<BenC> ENODEV
<BenC> mdz: I'm using the devices setup by d-i
<BenC> switching to console
<BenC> ...after partman runs
<mdz> BenC: well, it's encrypting with a random key from /dev/urandom, so it should be pretty random
<mdz> I wonder why it does it this way rather than just writing random data to the device
<BenC> Ok, I just got a completely different hang
<mdz> straight from /dev/urandom to whatever without going through device-mapper
<BenC> during dhcp...keyboard started it up again...
<BenC> wonder if that's a red herring, or for real hang like we are seeing otherwise
<BenC> whoope, nope, same hang repeated
<BenC> mdz: Ok, this isn't blockdev-wipe related then
<BenC> I got network dhcp screen to hang twice in a row
<BenC> stayed at 100% until I hit shift key
 * BenC starts to blame kvm
<BenC> and note that even though nothing in d-i uses the mouse, the kernel and kvm both pay attention to it, so that would explain the kickstart from it as well
<mdz> BenC: others (including jdstrand) have reported hangs in other parts of the installer
<BenC> 3 times dhcp hung...
<mdz> even before partitioning
<BenC> shift key reliably starts it back up
<mdz> there is, as far as I know, only one unconfirmed report of this happening outside of KVM
<BenC> right, so I'm thinking these are two separate bugs
<BenC> One in kvm (dunno if it's userspace or kernel), and one on that specific bit of hardware
<BenC> I'm going to try this -server install on some hardware to try and reproduce
<mdz> BenC: dendrobates said that mathiaz experienced some mysterious unreproducible hangs on real hardware when doing server enablement, but I have no information
<BenC> Bringing dendrobates here, hopefully hash this out a bit more
 * BenC summons the frog
<mdz> I pasted him a log excerpt
<dendrobates-> BenC: here
<mdz> dendrobates-: I can always tell when you're here because my xchat-gnome window resizes to accomodate your nick
<mdz> kirkland: are you able to reproduce this easily?
<kirkland> mdz: I have not reproduced this at all
<kirkland> mdz: I've only tried on real hardware
<mdz> ah, I see
<BenC> dendrobates: I reproduced the hang...but, I was able to reproduce it during dhcp as well as during crypt erase
<kirkland> mdz: and with a 300G drive, the device zero'ing takes FOREVER
<mdz> Ben and I are starting to think that the primary bug here is kvm-specific
<mdz> and there may be a separate issue or two which are hardware-specific
<mdz> kirkland: you can manually adjust the size of the device to mitigate that; I did it yesterday
<BenC> dendrobates: so this isn't specific to blockdev-wipe usage...which leads to believe even more than what we are seeing in kvm is not likely the same bug as what was reported on real hw
<kirkland> BenC: have you given any thought to the empty entropy suggestion one commenter gave?
<dendrobates> even in kvm it is not limited to blockdev-wipe.
<BenC> kirkland: blockdev-wipe uses /dev/zero, and a key, so there's no entropy involved
<BenC> kirkland: plus, it's not just during that operation
<kirkland> BenC: right, my question is probably more d-i specific...  anywhere else in the installer that might rely on /dev/random?
<mdz> kirkland: not on a recurring basis
<dendrobates> both jdstrand and I are seeing it appear at various places during the install, but it always occurs during blockdev-wipe.
<kirkland> particularly something that might have been introduced in hardy, since this is looking like a regression since gutsy
<mdz> I think the encryption aspect is a red herring
<dendrobates> mdz: I do as well.
<mdz> the installer just spends a lot of time (and makes a lot of system calls) there
<dendrobates> All I know for sure is that it is easy to reproduce with lvm+crypt.
<BenC> I'm going to try and reproduce under kvm on gutsy
<BenC> that should give us a reliable answer
<dendrobates> we have already tried to reproduce it installing Gutsy on a Hardy kvm, with no success.  That seems to point to someting in Hardy.
<BenC> dendrobates: Ok, I'll try the other way (install hardy on gutsy)
<BenC> dendrobates: but yeah, that's an interesting point too
<dendrobates> I am going to try a pre-beta hardy image.
<dendrobates> I have a daily build from dec-5
<BenC> All I have are 32-bit 7.10 CD's
<BenC> Where are the gutsy live cd's?
<mdz> BenC: http://releases.ubuntu.com/7.10/
<dendrobates> BenC: can't you reproduce it in 32bit?
<BenC> thanks
<BenC> dendrobates: I'm sticking with what soren told me...haven't tried 32-bit yet :)
<BenC> well, I did on my laptop, but it wouldn't repro there
<dendrobates> BenC: OK, it does not seem to matter though.
<BenC> That's an interesting regression
<BenC> hardy nv driver only does 800x600 on my plasma screen, while gutsy starts up at 1280x1024
<BenC> Ok, I happen to have 32-bit handy, so I'll try that
<dendrobates> I was not able to reproduce it with an older hardy iso, but,  the hardy daily from Dec does not do the erase on lvm+crypt, which is the most reliable way I have found to reproduce it.
<dendrobates> mdz: do we have an archive of the daily builds somewhere?
<dendrobates> or the alpha releases?
<mdz> dendrobates: slangasek would know
<mdz> I'm sure we do, but I don't know where
<mdz> (of milestones at least)
<BenC> hmm
<BenC> This might not be possible to test
<BenC> Gutsy kvm doesn't support the gfx boot it seems
<JanC> BenC: there is a sed line to "fix" the gfxboot issue
<JanC> (if that's useful)
<BenC> Sure
<dendrobates> B$ sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < ubuntu-7.10-server-amd64.iso > ubuntu-7.10-server-amd64-nogfxboot.iso
<BenC> dendrobates: thanks
<dendrobates> a little brutish, but it works.
<BenC> can I hexedit it instead? :)
<JanC> it's documented on https://wiki.ubuntu.com/KvmVirtManagerEtc#head-80f0e334a1de270252f62ac69183da2ed58edf3f 
<JanC> (the sed line)
<JanC> BTW: does anybody know when vmware server & which version will be available for hardy?  (question from someone I know who uses it professionally)
<BenC> yep, hexedit is much faster, it solved it, thanks
<arcticpenguin380> what processor is ubuntus kernel optimized for?
<JanC> arcticpenguin380: depends on which kernel you mean  ;)
<arcticpenguin380> hardys.
<JanC> hardy has several kernels included
<JanC> but -generic kernel is optimized for 686 IIRC
<arcticpenguin380> are all hardys kernels 2.6.24?
<JanC> yes
<arcticpenguin380> oh and is ext4dev compiled?
<JanC> I don't think so
<JanC> well, /proc/filesystems doesn't list it
<BenC> soren: is there supposed to be a way to make kvm emulate 64-bit when running under a 32-bit kernel?
<BenC> otherwise, I gotta download a 32-bit -server CD :/
<soren> BenC: No can do.
<BenC> Ok, I'm off, and will return in a few hours to continue tracking this down (and over the weekend)
<DB42> rtg: here ?
<DB42> rtg: http://ubuntuforums.org/showthread.php?p=4612681 fixes the problem
<sn9> is anybody actively working on Bug #88746? if so, i'm willing to provide needed info
<ubotu> Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [Undecided,Invalid] https://launchpad.net/bugs/88746
<sn9> having usb2 broken in feisty, gutsy, _and_ hardy is a bit much
<sn9> for perspective, i've had the very same issue on a different machine with a different chipset, a different usb device, and a different distro
<sn9> the common element appears to be multifunction usb devices
<crimsun> do any of the workarounds ... work for you?
<sn9> modprobe -r ehci-hcd
<crimsun> so in the absence of a fix that works for everyone, you at least have a viable workaround
<sn9> the rest are a bit hard to keep track of
<sn9> and that workaround is NOT viable, just like the bug comments say
<sn9> after all, apparently that workaround _does_ work for _everybody_
<crimsun> that's precisely what I mean.
<crimsun> /you/ have a viable workaround.
<sn9> huh?
<crimsun> I asked if any of the workarounds work for /you/, and you responded with "modprobe -r ehci-hcd"
<crimsun> (obviously it's not preferable)
<sn9> but you said "in the absence of a fix that works for everyone" -- either there's no such absence or there's no such fix
<sn9> there's a reason ehci-hcd isn't just blacklisted by default
<crimsun> as we're both well aware, and I have no interest in arguing
<sn9> so far, i have not encountered any machine with an amd cpu where ehci-hcd works with a multifunction usb device
<sn9> strangely, it seems ok on p4's
<sn9> what i'm interested in is contributing to whatever efforts to fix this issue once and for all
<tjaalton> crimsun: any fix on the horizon for snd_hda_intel suspend/hibernate issue (needs to be removed after resume, otherwise no sound)?
<crimsun> tjaalton: I don't head up sound anymore (and haven't for a year).  What's the issue?
<crimsun> tjaalton: meaning, I need to know what HDA codec/model is affected
<tjaalton> crimsun: oh sorry.. let's see..
<tjaalton> crimsun: 8086:293e I guess
<crimsun> need the line afterward.
<crimsun> (`lspci -nv|grep -A1 0403')
<tjaalton> Subsystem: 1043:829f
<crimsun> I can guess that's a Realtek, but can you confirm by looking in /proc/asound/card0/codec#0?
<tjaalton> yeah.. Realtek ALC883
<tjaalton> shame on intel..
<crimsun> tjaalton: ok, please pastebin that codec spew.
<tjaalton> crimsun: http://pastebin.ubuntu.com/7440/
<crimsun> thanks, looking
<tjaalton> does it need some hal/suspend quirk?
<sn9> hmm, i just tried a suspend, and no more sound...
<sn9> ALC885
<crimsun> interesting, there's no unmute for autoconfig
<crimsun> tjaalton: I presume you're not passing a model= in /etc/modprobe.d/* ?
<tjaalton> crimsun: nope
<sn9> i know i'm not -- it gets config from the bios
<crimsun> tjaalton: ok, I'll ping you.  Looking closer.
<tjaalton> crimsun: excellent, thanks
#ubuntu-kernel 2008-04-19
<Kano> hi, is there something known about autoneg problems with 3c59x? that devices always detects only 10mbit half duplext not 100 mbit full
<sleepster> does the ubuntu kernel diverge from the mainstream linux kernel 
<|DuReX|> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/209971
<ubotu> Launchpad bug 209971 in linux "[Hardy Regression] cx22702 no longer works" [Undecided,Incomplete] 
<|DuReX|> could this get fixxed before hardy release ? :)
<|DuReX|> the solution is posted ...
<|DuReX|> and tested :)
<|DuReX|> and working :)
<alex_joni> |DuReX|: this link doesn't work for me: http://linuxtv.org/hg/~stoth/v4l-dvb/rev/67b7ef217867
<|DuReX|> http://linuxtv.org/hg/~stoth/v4l-dvb/rev/e55d97ff8bba
<|DuReX|> this ?
<alex_joni> no, I took the one from launchpad
<|DuReX|> ye indeed
<|DuReX|> try the one I pasted :p
<alex_joni> I suggest adding it to launchpad
<alex_joni> yours opened just fine
<|DuReX|> posted
<|DuReX|> :P
<|DuReX|> would be nice if it was added :)
<|DuReX|> I added those 4 lines to the source of 2.6.24-14/15/16 ubuntu kernel :)
<|DuReX|> and worked on all of them
<|DuReX|> with the patch
<blueyed> bug 188226 starts to get comments from real users who tracked it down to this.
<ubotu> Launchpad bug 188226 in linux "Kernel should use CONFIG_FAIR_CGROUP_SCHED" [High,Triaged] https://launchpad.net/bugs/188226
#ubuntu-kernel 2008-04-20
<zul> BenC: ping
<sn9> zul: he's been idle for a day; i don't think he's near his computer
<BenC> zul: ?
<sn9> irc-tag...
<sn9> BenC: well, as long as you're here, remember Bug #88746? i did some testing, and i think i found what sets it off
<ubotu> Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [Undecided,Invalid] https://launchpad.net/bugs/88746
<sourcemaker_> is there a good book to understand the Linux Kernel. (Architecture, Development.. and so on)...
<sn9> just look at the o'reilly catalog and pick something
<timing> hey
<sn9> ho
<timing> at my install, audio is working in an older 2.5.24 build. but not in the versions from -7 till -16
<sn9> why 2.5?
<timing> 2.6.24-5 and before is where audio is working very good
<timing> uhh sorry 2.6
<timing> confused with the -5 I wanted to type later on
<sn9> do you by any chance have a realtek audio chipset?
<timing> And now i'm wondering what those -5 -7 things mean
<timing> just a difference in compile flags?
<timing> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
<sn9> there is a changelog in /usr/share/doc/linux-image-2.6.24/
<timing> thanks
<timing> but could it be in modules as well?
<timing> or somewhere total different?
<sn9> yes
<timing> but it could've changed in -6? But I don't have that version
<sn9> the changelog is a log, so it includes older versions
<timing> ok
<timing>   * hda_intel suspend latency: shorten codec read
<timing>   * config: Re-enable snd-hda-intel
<timing> hmm
<timing> o the latter one is way before -5 already
<sn9> it's in reverse-chronological order
<timing> uhm
<timing> it's date \n changes?
<timing> or changes \n date ?
<timing> the first line is from 2.6.24-5.8
<timing> no idea if i have 2.6.24.7 .1.2.3.4.5 or so
<sn9> version, changes, date
<timing> the susped latency is changed in:
<timing> linux (2.6.24-5.8) hardy; urgency=low
<timing> sn9: the -5 -7 -8 numbering is changing compile flags? or different patches against 2.6.24 on kernel.org ?
<sn9> it's the changes you see in the log
<timing> OKay so that's like a lot :-)
<timing> So how can I help developers with fixing this?
<timing> a guy in #alsa said he fixed this already
<timing> but there is no bug number or no revision number for the fix he made
<sn9> did he say what version of alsa he fixed it in?
<timing> he said see the changelog, couldn't find it
<timing> he is very busy
<timing> so that's too bad
<sn9> did he remember how long ago he fixed it?
<timing> I can check my irclogs
<sn9> ok
<timing> where he said, 'okay fixed it'
<sn9> oh, so he fixed it while you were on irc?
<timing> yeah think so
<timing> i grepped on crimsun on my logfiles. these are 4 lines:
<timing> 02/Sat-23-02-#alsa.log:17:30:28< crimsun_> hmph, I think the patch_analog updates broke it
<timing> 02/Sat-23-02-#alsa.log:17:30:34< crimsun_> it's alsa-related
<timing> 02/Sat-23-02-#alsa.log:17:30:46< crimsun_> I'll try to update alsa-source today for it
<timing> 02/Sat-23-02-#alsa.log:17:32:13< crimsun_> because I'm looking at the changes.
<timing> o he is here as well!
<timing> haha didn't know that
<sn9> so, this was Feb 23?
<timing> yeah
<timing> and then I went back later:
<timing> 03/Mon-31-03-#ubuntu+1.log:22:44:33< crimsun> timing: that's already fixed upstream.
<timing> 03/Mon-31-03-#ubuntu+1.log:22:44:41< crimsun> (and has been for some time, I might add)
<timing> 03/Mon-31-03-#ubuntu+1.log:22:44:52< crimsun> not in Ubuntu yet.
<timing> then i stumbled upon him in #ubuntu+1
<timing> He is everywhere :-)
<timing> o this is the bug btw: https://bugs.launchpad.net/bugs/209047
<ubotu> Launchpad bug 209047 in linux "Sound did work in 2.6.24-5 but not in 2.6.24-7 till 2.6.24-16" [Undecided,Incomplete] 
<timing> going to sleep now, bbl
#ubuntu-kernel 2009-04-13
 * Kamping_Kaiser sticks his head in
* You're now known as ubuntulog
<genady12lap> hey I am having a problem with ubuntu 9.04 with freq scaling
<genady12lap> can some one help me?
<randompie> Unable to boot kernel shipped with Jaunty Beta on an Nvidia RAID1 mirror. See: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358255
<ubot3> Malone bug 358255 in linux "[jaunty] Root on nvidia raid 1 mirror does not boot" [Undecided,New] 
<wamty> anyone know what direction memcpy_tofs or memcpy_fromfs works ?
<manjo> randompie, can you try with kernel option rootdelay=60 ? 
<randompie> manjo: what else to try and how to get more information to post here. Will need to reboot system
<randompie> Also how to know what is the exact kernel package?
<manjo> ?? uname -a should tell you what kernel you are currently running 
<randompie> uname -a only says 2.6.28-11. Current package is 2.6.28-11.38. How do I get those last 2 digits - the "-38" part.
<manjo> randompie, for me uname -a 
<manjo> Linux hungry 2.6.28-11-generic #41-Ubuntu SMP Wed Apr 8 04:39:23 UTC 2009 x86_64 GNU/Linux
<manjo> randompie, also cat /proc/version
<manjo> Linux version 2.6.28-11-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #41-Ubuntu SMP Wed Apr 8 04:39:23 UTC 2009
<rtg> manjo: 'cat /proc/version_signature'
<manjo> proc/version
<randompie> Thanks. It now says: cat /proc/version_signature 
<randompie> Ubuntu 2.6.28-11.40-generic
<randompie> manjo, rtg: so what is the latest? and how to install it?
<manjo> randompie, for jaunty ? 
<manjo> randompie, I updated on the 8th and its 41, I dont have any updates yet for amd64
<manjo> randompie, were  you able to reboot with the kernel option I mentioned ? did the hdds come up ? 
<SEJeff> I'm writing up a rough howto help you guys troubleshoot guide to a guy seeing deadlocks on an ubuntu nfs server (on the ubuntu-hardened ML)
<randompie> so, I should file bug against #40 only. The wrong initrd drops me to a busybox sheel. How can I gather information from there to help people debug this. Also, has the ubuntu kernel made changes  as to what gets modularized and what not?
<randompie> No, I haven't tried re-booting yet.
<SEJeff> I'm going to suggest he go through the setups to setup crash like installing the crash package and add "crashkernel=128M@16M" to his kernel commandline
<SEJeff> How do you install kernel debuginfo packages in ubuntu?
<randompie> manjo: signing off to reboot.
<manjo> k
<rtg> SEJeff: I started a page at https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe. At last test, 32 bit still has some issues.
<SEJeff> rtg, Oh wow I was basicly going to write up something very similar
<SEJeff> Hopefully we can get this user to create a vmcore and attach it to a bug report. Thanks
<rtg> SEJeff: feel free 'cause that page needs serious help.
<SEJeff> rtg, I'm guessing linux-crashdump is intrepid+ ?
<rtg> SEJeff: its a meta package taht also exists in Jaunty
<SEJeff> Right but this is a "production" server in hardy
<SEJeff> Too bad that packages isn't in hardy
<SEJeff> The user sees the server panic/deadlock when an nfs client accesses it.
<SEJeff> Kind of a big deal in an LTS release I'd think
<rtg> SEJeff: yeah, it may not exist for Hardy
<SEJeff> rtg so what needs to be installed other than crash?
<rtg> SEJeff: kexec-tools
<SEJeff> thanks. Most of my crash experience is on RHEL boxes. With crash and kexec-tools installed on a vanilla hardy install will it save the vmcore to somewhere like /var/crash?
<SEJeff> Or will we need to fudge with the kernel.core_pattern sysctl
<rtg> SEJeff: I'm not as familiar with Hardy, but that is the way Intrepid and Jaunty work.
<SEJeff> Ok
<SEJeff> thanks for the help tim
<randompie> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358255 no chnage with rootdelay=60
<ubot3> Malone bug 358255 in linux "[jaunty] Root on nvidia raid 1 mirror does not boot" [Undecided,New] 
<deshantm_laptop> randompie: rootdelay=60 might not be long enough (for some things i have worked with it is not)
<deshantm_laptop> not sure about the raid case
<randompie> It works fine with a 2.6.27-13 initrd
<deshantm_laptop> randompie: did you cat /proc/modules when you were dropped to the (initramfs) prompt?
<randompie> yes. no mapper modules. incidentally, the mirror code is compiled into 2.6.28-11. These are modules in 2.6.27-13
<deshantm_laptop> did the modules require any arguments? would the kernel command line need any arguments?
<randompie> nope. no argument needed. the old initranfs boots out of the box. Actually, currently running a 2.6.28-11 kernel but with the old initramfs. The dm* modules are not loaded in this kernel.
<deshantm_laptop> i am pretty sure that kernel version and modules version need to match for the initramfs to work
<randompie> deshantm_laptop: then why does it work? What is the difference between the two scenarios? What I could dig out was that 2.6.28-11 compiles in a lot of stuff that 2.6.27-13 made modules - a simple comparison of the config shows that. The size of the initrd is also a pointer in this direction - there is a 1 MB size difference between the 2 initrds.
<randompie> manjo: the rootdelay=60 did not work :(
<manjo> randompie, did u try to upgrade to the latest kernel and make sure the initrd and kernel matches ? 
<manjo> randompie, waht version are you running ? hardy/intrepid/jaunty ? 
<randompie> I am running Ubuntu 2.6.28-11.40-generic. I did an update-initramfs multiple times to no avail. Jaunty-Beta
<manjo> randompie, waht is your bug #  
<randompie> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358255
<ubot3> Malone bug 358255 in linux "[jaunty] Root on nvidia raid 1 mirror does not boot" [Undecided,New] 
<manjo> randompie, can you remove the quiet splash option from your boot command line and report what boot messages you see ? 
<randompie> will do. If I gain get dropped to an initramfs, how can I copy the dmesg stuff out so as to look at it/post it here?
<manjo> randompie, you can take a photo of the boot screen with your cell ? 
<manjo> attach to the bug 
<randompie> manjo: nothing more hi-tech than that?
<manjo> heh that is acceptable hi tech debugging tool :)
<manjo> randompie, and oh! reduce your screen font size
<manjo> so that you get all the messages
<manjo> randompie, setfont /usr/share/consolefonts/Uni1-VGA8.psf.gz
<randompie> how do I reduce screen font size?
<manjo> sorry
<manjo> you may not be able to do that .. 
<manjo> n
<manjo> never mind
<manjo> just remove quiet splash and reboot ... and see what messages you get 
<randompie> so setfont is persistent across re-boots, right?
<manjo> no
<manjo> I was wrong 
<randompie> Yes, I think the compiled in font takes precedence at boot time. Will get back to you. Just uploaded 1 photo taken earlier. Please check.
<manjo> randompie, I think there is a vga=XX option for the kernel
<SEJeff> manjo, randompie, yes it depends on the resolution you want the console fonts to be
<manjo> SEJeff, I think he left 
<SEJeff> manjo, Unless you know the resolution he should set it to you can tell him to put "vga=ask" for a mini-menu to select the resolution
<manjo> SEJeff, k .. I think he is rebooting now will ask him when he returns
<SEJeff> cool
<SEJeff> manjo, http://www.linuxforums.org/forum/misc/2244-how-do-i-set-command-line-screen-resolution-rh9.html#post13498
<SEJeff> There is a good start
<manjo> so highest resolution -- smallest font ? 
<manjo> or vice versa ? 
<SEJeff> manjo, Correct
<SEJeff> Depending on the display device he is using, if it is too high (for an lcd) it won't display. It will just say something like "resolution out of range"
<SEJeff> And for a CRT it would just be unreadable
<SEJeff> Generally just set it to the native resolution of the display and that should be good.
<manjo> k thanks for the link 
<SEJeff> np
<SEJeff> vga=791 is generally a safe bet though
<manjo> I suspect he might be hitting a casper bug
<SEJeff> yuck
<genady12lap> hey
<genady12lap> heyhey I am having a problem with ubuntu 9.04 with freq scaling
<randompie> manjo: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358255 updated with photos
<ubot3> Malone bug 358255 in linux "[jaunty] Root on nvidia raid 1 mirror does not boot" [High,Triaged] 
<genady12lap> someone here?
<genady12lap> why SpeedStep compiled into the kernel?
<t|tp> Is this the correct channel to ask questions about make-kpkg?
<SEJeff> rtg, I'm not sure if the kdump stuff will work on hardy without some manual hackery. What do you think of adding an init script like on RHEL to save cores on boot to /var/crash/$DATEHASH?
<SEJeff> And how does jaunty do it? I've not got a jaunty box here in the office to play with and the dsl at home is down
<rtg> SEJeff: Jaunty just drops them in /var/crash, but won't over write an existing crash dump
<SEJeff> rtg, Ok is there an init script somewhere on boot that does that?
<SEJeff> Like there is in RHEL/centos?
<rtg> SEJeff: for Jaunty its called 0_kdump and gets dropped into the /usr/share/initramfs somewhere
<SEJeff> Ah ok
<SEJeff> So none of that is done in hardy. The user will have to manually do it. Would it be difficult to backport the latest crash and linux-crashdump metapackage to hardy-backports?
<rtg> SEJeff: it shouldn't be too hard. You'll probably want to run those patches through the k-t list, directed to Stefan Bader (smb)
<SEJeff> Alright I'll try to setup a hardy vm and do it sometime this week. Thanks again
<rtg> SEJeff: in the kexec-tools package, debian/rules installs debian/kdump.initramfs as /usr/share/initramfs-tools/scripts/init-bottom/0_kdump
<SEJeff> ok
<Nozelf> Hi, I'm trying to boot backtrack on my laptop from my flashdrive, but when I exec ./bootinst.sh i recieved Fatal: Cannot open /dev/loop: No such file or directory
<Nozelf> Is a flashdrive problem?
#ubuntu-kernel 2009-04-14
<geek1> hi, this may sound dumb, but can someone tell me what the kernel is for?
<geek1> hello?
 * nturner wonders where the linux-image-debug-2.6.27-11-generic package is hidden...
<dandel> 0o' last set of updates on jaunty just knocked out the windows based install i had ><;
<genady12lap> no one here?
<Kamping_Kaiser> kees, is it possible the package(s?) we were talking about a few day s ago will require linux-image-* meta packages to get rebuilt? eg, http://packages.ubuntu.com/search?keywords=linux-image-386 has different versions for hardy and hardy-updates. all other releases have the same versions in the release and security pockets
<apw> smb_tp, this thread may be relevant to you for the press-a-key-to-boot bug: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg240281.html
<smb_tp> apw, hm, interesting. thanks.
<apw> no idea if its already in our kernel etc, just hit it by accident
<smb_tp> I don't think is is disabled currently with our kernels
<genady12lap_> apw, ping
<apw> genady12lap_, hi
<genady12lap_> hey
<apw> smb_tp, reading that thread the wisdom seems to be 'you can use hpet=force' and things just work
<genady12lap_> I am having problem with speedstep
<apw> genady12lap_, ok, what sort of problems, with what cpu
<smb_tp> apw, that would imply hpet is not used somehow... hm, I have to get to that thread... later...
<apw> smb_tp, there is an implication that it might not be for sure
<smb_tp> apw, ok, definitely something to look at... thanks for the pointer
<genady12lap_> apw, bug 360192
<ubot3> Malone bug 360192 in linux "speedstep (cpufreq in PIII) not loaded in the kernel" [Undecided,Incomplete] https://launchpad.net/bugs/360192
<apw> smb_tp, i happen to be looking at bugs which complain about issues with tickless and C!E in combination and that was Ingo's recommendation as a solution rathter than any other fix
<smb_tp> apw, It would be interesting whether it is possible to check whether hpet is only partially active (or whatever the implications are)
<apw> smb_tp, agree its not at all clear what is and is not being used
<genady12lap_> apw, what do you think?
<apw> genady12lap_, i'd say its likely that its not enabled because it provides no benefit on cpu's which don't change voltage when they change frequency
<genady12lap_> but it worked some time ago
<apw> some time ago?
<genady12lap_> I dont remember when, but it works now on windows
<apw> there has been much debate on power saving, just because windows does something though is no indicator it is sensible
<apw> if i remember the argument correctly, then if your cpu has C2 power saving mode, and CPU frequency but no CPU voltage scaling then there is exacly 0 benefit from changing the frequency
<apw> as the benefit of going into C2 is exactly the same as it would be in the states inserted into the cpu to 'slow' it down
<apw> ie. it will consume the same number of active cycles, its just the idle cycles are spread differently.
<genady12lap_> oh
<apw> https://bugs.edge.launchpad.net/ubuntu/+source/powernowd/+bug/177646
<ubot3> Malone bug 177646 in linux "Celeron M530, no frequence scaling" [Medium,Invalid] 
<apw> there is much write up on that bug in this area
<genady12lap_> apw, so what can I do to save more power?
<apw> i assume you have used powertop and followed its advice
<genady12lap_> btw I tried the hibernation script and I have problems. (If you are the person who needs to hear them)
<apw> suspend_test ?  if so did it get you to file bugs?
<genady12lap_> the problem it wont resume automatically
<genady12lap_> and I should disable rt61pci module
<genady12lap_> powertop is cool
<apw> genady12lap_, make sure there is a bug filed which says that for sure
<kees> Kamping_Kaiser: I'm not sure what you mean.
<manjo> I am seeing an issue where on suspend/resume after an AC power transition the ATA taskfile status register is set to 0xd0 (invalid value), any ideas ? 
<apw> smb_tp, was there a wake-on-lan bug hanging about, something to do with a bios setting to make it work
<smb_tp> I do not remember a wol not working one. The one I looked at was rather _always_ working after an update
<smb_tp> But ask for ehttool output, that should tell whether wol should be active from the drivers perspective
<smb_tp> ethtool even
<apw> smb_tp, thanks
<mdz> apw: do you want help writing that bugpattern for bug 359864, or is it not worth it at this point?  I just noticed you marked another dupe
<ubot3> mdz: Error: Could not parse data returned by Malone: The read operation timed out
<mdz> apw: er, 352178
<apw> so far we don't have a huge pile of dups for it, i believe apport is now going off so i suspect its a non-issue
<apw> though it would be useful to learn that skill for sure
<awe> apw: ping
<apw>  awe hi
<awe> thanks for the debugging tip.  looks like it's a panic in the uvcvideo driver's suspend function
<apw> very nice
<awe> apw: how do i get a copy of the stack trace to add to the bug?
<apw> did you get the whole stack?
<apw> normally we take a photo
<apw> if the top of the panic is missing there is a setfont command on that page which can make the page longer
<apw> then get a photo
<awe> apw: modern tech @ it's best eh?
<apw> sadly yes
<awe> apw: i see Call Trace: so I think that's the top
<apw> you can use a usb setrial dongle, and another one, and a cross over
<apw> call trace is normally a few lines down, whats the first
<apw> but get a photo off that one regardless, and then redo it with the other font
<awe> ok
<manjo> apw, I think I found a work around to the suspend resume causing ATA errors on the samsung NC10 finally
<awe> apw: no setfont command found...  it's either not part of 8.04, or was removed from the core netbook derivative
<smb_tp> awe, For Hardy the magic runes are: consolechars -f /usr/share/consolefonts/Uni1-VGA8.psf.gz
<awe> smb_tp: thanks!
<awe> smb_tp: when i run that command i get: set_kernel_font: Invalid argument
<smb_tp> awe, did you run it on a text console?
 * awe feels dumb
<awe> i just opened a gnome-terminal
<smb_tp> Yeah, unfortunately it won't work there. :)
<awe> smb_tp: ok, i think i know how to do it now... i need to switch to a virtual console right?
<smb_tp> awe, Oops, sorry I thought you found out. Err, yeah, best use vt1 for that
<cody-somerville> sconklin, Hi. I was wondering if there was any progress on bug #352615?
<ubot3> Malone bug 352615 in linux "Please provide squashfs-modules udeb" [Medium,Triaged] https://launchpad.net/bugs/352615
<sconklin> cody-somerville: no, I have had more urgent bugs, and won't be able to look at that one this week
<awe> smb_tp: so i managed to change the font, and when i hit the crash now, i get gibberish...looks like i get the top 40% of each line, and then it's overwritten by the line below it.
<smb_tp> awe, Hm, strange. Would ls and stuff work correctly after changing the font? For me here it is working ok (normal use without a crash)
<awe> hmmm... i know what i did.  i switched back to the normal ui.  duh. lemme try again.
<smb_tp> Though even that works here on my laptop
<awe> yea, but this is dennis the menace.  ;)
<smb_tp> heh :)
#ubuntu-kernel 2009-04-15
<Kamping_Kaiser> kees, could the changes to linux-ubuntu-modules-2.6.24-23-386 mean linux-image-* meta packages (such as linux-image-386) need to get rebuilt? http://packages.ubuntu.com/search?keywords=linux-image-386 has different versions for hardy and hardy-updates. all other releases have the same versions in the release and security pockets
<infinity> Kamping_Kaiser: Looks like they need a copy, yes.
<infinity> kees: Do you want me to copy linux-meta from updates to security?
<infinity> kees: (Assuming you've verified that's a good idea...)
<Kamping_Kaiser> thanks.
<kees> infinity: it's already there, isn't it?
<kees> infinity: is that what's still missing?
<infinity> kees: linux-meta on hardy still points at -22
<infinity> kees: (in security, that is)
<infinity> kees: updates has the -23 bump.
<infinity> kees: Assuming all of LUM, LBM, etc are happily published, we should copy -meta, yes.
 * kees facepalms
<kees> infinity: yes please.
<kees> aaaargh
<infinity> (copying)
<Kamping_Kaiser> \o/
<infinity> kees: There.  Just pending a publisher run now.
<kees> infinity: thanks.  this is actually a serious error on my part.  :(
<kees> this means that only really vigilant hardy admins have been running an updated kernel on hardy.
<Kamping_Kaiser> infinity, thanks :)
<infinity> kees: Well, it'll all resolve itself shortly...
<infinity> kees: And if you choose me for a peer reviewer on the next performance review cycle, I'll try not to mention it. :P
<kees> infinity: yeah, and hit the datacenter too
<Kamping_Kaiser> how often does the publish run happen?
<infinity> Next one's at :03
<infinity> You should see it mostly pushed to mirrors and such in about an hour and a half.  Ish.
<Kamping_Kaiser> ok. Then i'll give it a few hours before trying.
<Kamping_Kaiser> tyvm both.
<kees> infinity: well, actually, this just means nearly no-one runs with -updates.
<infinity> kees: Yeah, almost everyone uses -updates, so it shouldn't be a big deal.
<Kamping_Kaiser> gNewSense doesn't officially support -updates, hence I've been chasing this issue here
<infinity> Kamping_Kaiser: Oh, that linux-meta thing should be long fixed on pretty much all mirrors by now.
<Kamping_Kaiser> infinity, thanks, i'll kick the mirrors here and see if they've picked it up yet
<Superdweeb> hey guys, do you know why my system hangs for about .8 seconds and tells me  "IO APIC resources could not be initialized" ?
<Superdweeb> I've got my system booting in about 9 seconds now :-D
<mvo> smb_tp: re bug #353534 - I can add code in update-manager to transition people, but I need to know for what /proc/cpuinfo values its safe to move to -generic and which ones need to stay on the old kernel
<ubot3> Malone bug 353534 in update-manager "dapper->hardy->intrepid upgrade path leaves user with unsupported kernel" [Undecided,New] https://launchpad.net/bugs/353534
<smb_tp> mvo, Good question. Everything 586 can go generic... A sec...
<smb_tp> mvo, The problem is I cannot say which flags this would be. From the config option everything AMD K5, Cyrix 5x86, Pentium Pro/MMX and newer would be good.
<mvo> smb_tp: is there a way to figure that out from the cpu familty or the model number? I would rather not want to do string matching there :) ideally would be the flags I guess, but you said this is problematic
<smb_tp> As there is a special option M586TSC for the Pentium-Classic and M586MMX for Pentium-MMX one could thing mmx and tsc might be something, but still would leave the other cpus outside. And I got no 486 / 586. Well not completely true, I got a Pentium-90 laptop but with 64MB memory it is hard to get somehing running...
<lamont> rtg: heh
<rtg> lamont: dude
<lamont> told you you'd be back. :-p
<lamont> doing your chowns now
<rtg> thanks, you're a pal :)
<maco> I know it's not the right time in the release to worry about this bug, but it's one that I'm getting pretty confused by so maybe someone else who understands these things better can help.  Bug 272530
<ubot3> Malone bug 272530 in linux "64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory" [High,Triaged] https://launchpad.net/bugs/272530
<maco> It's something that occurs only with 4GB of memory.  noacpi gets rid of it. BIOS update gets rid of it, and oh now someone just interjected that in older versions of CentOS it didn't exist at all, so maybe something changed in the kernel to make certain newer kernels incompatible with the BIOS?
<dtchen> quite possibly, but you'll need to walk the kernels trees
<ogasawara> rtg: fyi https://bugs.edge.launchpad.net/ubuntu/+bug/330824/comments/95
<ubot3> ogasawara: Error: Could not parse data returned by Malone: timed out
<rtg> ogasawara: I've been following it. In fact, I'm building his config right now
<ogasawara> rtg: ok cool
<rtg> ogasawara: you could do it as well :)
 * ogasawara fires up a build
<rtg> ogasawara: I compared it against 32 bit -generic. There are only 4K+ lines different.
<ogasawara> heh, only
<rtg> ogasawara: hmm, maybe thats because its based on -server since I see PAE is set.
<rtg> but, there are only 67 lines between config.generic and config.server that are unique
<rtg> ogasawara: do you have a 32 bit installed machine? Everything I have is 64 
<ogasawara> rtg: I have a 32 bit, just finished cloning the jaunty tree
<rtg> ogasawara: at least that worked. I just changed the privs on zinc
<lamont> zinc rebooting, sorry about that
<macli> hi, how do I use git to check out latest kernel tree? git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git ?
#ubuntu-kernel 2009-04-16
<dtchen> macli: that's one way, yes
<macli> dtchen: I ran git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git , but got fatal: serious inflate inconsistency1)
<maxb> window level all
<setuid> Question: I'm working on some firewire drivers, and noticed that the kernel I'm using doesn't support large volumes on the target device. I've seen some of the recent commits and wanted to roll a new kernel... so I built one using make-kpkg, after oldconfig and friends...
<setuid> ..and it seems the new kernel (2.6.29+) has renamed the SATA devices back to /dev/hdX. Is there some way I can get an *EXACT* match of the working 2.6.18 kernel's config into a working 2.6.29 kernel? It seems there's some subtle difference I can't nail down. 
<amitk> setuid: options get moved around or renamed or removed quite a bit. It is very hard to get an exact match on two kernels that are this far apart.
<setuid> I would think that an oldconfig, making sure .config is the same (modulo additions in the .29 kernel), that it would work 
<setuid> Why /dev/sdX got renamed to /dev/hdX and now refuses to boot from SATA drives, boggles me
<setuid> Even passing root=/dev/sda2 fails, because there _are_ no /dev/sdX devices. It's weird. 
<rtg> its not altogether surprising. you are straddling the whole libata transition which happened about 2.6.24
<setuid> Ok, is there a way to get firewire devices to recognize an 8TB volume with .18? Or is that simply not possible? 
<trichobezoar> What has to be done to get the fix mentioned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275120/comments/5 
<setuid> Everything after .18 seems to be a mess, with anything I've thrown at it. Some supports booting, others fail on some devices, it's all random and de-evolved after .18
<ubot3> Malone bug 275120 in linux "Atheros WLAN AR242x LED doesn't work" [Undecided,Fix released] 
<trichobezoar> part of the ubuntu kernel?  I upgraded to the beta but the rfkill/led dont work as specified
<setuid> ahhh, I think I see the issue... .18 has a bunch of lib/modules/drivers/scsi/sata*ko modules that aren't in .29
<setuid> hrm, I don't remember SATA being called out specifically in the config... maybe that's the issue. 
<setuid> amitk, Where would those be stashed? 
<setuid> ah... here we go 
<levonshe> Hello all, I am trying to use vanilla 2.6.26 kernel instead of ubuntu's 2.6.24-23-generic, but sd module does not use ide modules, any clues?
<setuid> modules don't use modules
<amitk> setuid: sure they do, they depend on other modules
<levonshe> _setuid_, you wrong. Modules just expose API for any interested party, look for example modules.dep or lsmod - the count more than 0 shows module used.
<setuid> modules rely on interfaces provided by other modules, of course, but they do not "use" them. Semantics, I know. What is your question? Because sd no longer uses the ide modules? 
<levonshe> _setuid_, the boot process does not detect IDE disk, giving me "waiting for a root file system process" and then resolving to Busybox, I saw also that udev cannot do pre-mount scripts snf indeed, nor /dev/hda1. nor /dev/sda1 is created although I stated all possible ide and scsi modules while cre4ating initramfs
<setuid> levonshe, Looks like a similar problem I'm dealing with 
<setuid> sata moved to libata, and it's disabled by default in the default kernel source
<levonshe> _setuid_, the question is general one  - could smb replace ubuntu kernel and stay alive ? what is a procedure ?
<infinity> levonshe: Enabling libata in your kernel build should make it happy.
<setuid> here goes... 
<levonshe> _infinity_ Thanks, I am dowing it right now but still I am not conviced that I can replace ubuntu kernel with vanilla kernel
<smb_tp> generally I would say one should try to use the ubuntu config as starting point. there probably are not all modules present but it should work
<setuid> yep, looks like Linux still can't handle large volumes (8TB in my case) 
<setuid> http://rafb.net/p/aTdy0G86.html
<setuid> That's what I get with 2.6.29.1
<setuid> This seems to be related: http://lkml.org/lkml/2009/4/10/361
<setuid> It works fine over USB2 (at 600k/sec. speeds, ugh!), but not Firewire
<levonshe> One more problem puzzles me. I made installation from alternative cd (kernel 2.6.24-23-i368) and several very basic symbols (like irq_restore) were absent comparing to generic kernel for x86 ?why ..
<setuid> hrm, sg_readcap indicates that this device DOES support RC16... something is fishy here. 
<setuid> I wonder if I pull Linus' tree if the results will differ
<setuid> read capacity (16): transport: Host_status=0x05 [DID_ABORT]
<setuid> Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]
<Fundlefroop> ?
<macli> hi, I git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git, cd ubuntu-karmic and git tag | grep Ubuntu*, but it shows nothing
 * setuid boots 2.6.30 and hopes for the best
<rtg> macli: none too surprising since I've have not created any tags yet
<macli> rtg: thanks, I thought I could try the latest kernel like 2.3.30 for ubuntu using ubuntu-karmic.git
<rtg> macli: its a bit steamy yet, so beware. your best bet is one of the kernels in http://kernel.ubuntu.com/~kernel-ppa/mainline
<macli> rtg: so I could simply download the kernel image from the link and boot from it, no need to compile
<rtg> macli: yep. wget http://kernel.ubuntu.com/~kernel-ppa/mainline/SOMEKERNEL.deb; sudo dpkg -i SOMEKERNEL.deb
<z_existence> anyone know about rfkill handling ? i get XF86WLAN key pressed when I press the switch, but nothing is actually DONE 
<setuid> Can someone tell me why Linux is de-evolving so fast? It's becoming more and more unstable as the months and years go on. 
<setuid> Stuff that used to work, now no longer does, and when someone fixes that, they break something else, and it just cascades. 
<z_existence> anyone working on linux-backports-modules-jaunty ?
<macli> I git cloned ubuntu-jaunty.git and ran AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
<macli> but get ld: BFD (GNU Binutils for Ubuntu) 2.18.0.20080103 internal error, aborting at ../../bfd/merge.c line 865 in _bfd_merged_section_offset
<rtg> macli: why don't you just build it normally the first time, e.g., 'debuild -b'
<macli> rtg: I followed https://help.ubuntu.com/community/Kernel/Compile#Install%20the%20new%20kernel, it does not mention 'debuild -b' and I typed the debuild -b , it found so such command
<smb_tp_> macli, probably "debuild -b -uc -us" otherwise it wan't to sign the packages
<rtg> macli: apt-get install devscripts build-essential fakeroot
 * setuid has a howto on my blog for this
<setuid> http://blog.gnu-designs.com/building-custom-kernels-for-ubuntu
<rtg> this is a good page for vanilla Ubuntu builds: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Performing builds
<setuid> Anyone know of a good > 4 bay SATA enclosure? I'm trying to replace my Drobo2 with something that'll work with Linux/LVM
<popey> setuid: edge10
<setuid> No kernels support the Drobo over 1394b and the Linux kernel that is on the firmware of the Drobo itself, doesn't support RC16
<alex_joni> setuid: there's a lan thingie for drobo
<popey> droboshare
<setuid> alex_joni, Right, but it too, is just a Linux embedded target, doesn't support RC16 either
<alex_joni> setuid: bummer
<setuid> Drobo is limited to 2TB partitions on Linux (mine is 8TB, works with Linux, but not over 1394)
<popey> setuid: edge10 DAS or NAS devices are v nice
<setuid> And I'm limited to ext3, no optimizations... can't use XFS, geli, or cryptfs either
<setuid> popey, Looking now
<setuid> The DAS801t looks nice
<setuid> The TS-809 Pro is nice too, but cost-prohibitive (126MB/sec. reads and 111MB/s. writes) 
<setuid> $2,300+ for that little device
<setuid> Anyone happen to know if I can LVM multiple external eSATA enclosures together into one logical volume? 
<dtchen> rtg: i've been waiting for the pcm_lib and mid-layer changes to settle a bit. looks like a should be able to push a patch in a day or so.
<dtchen> looks like i*
<erle-> the topic is not up to date?
<erle-> i would like to discuss a bug i filed a few days ago:
<erle-> https://bugs.launchpad.net/ubuntu/+source/linux-ports-meta/+bug/361222
<ubot3> Malone bug 361222 in linux-ports-meta "kernel 2.6.28-11 boot fail with dm-crypt" [Undecided,New] 
<dtchen> erle-: well, 2.6.28-11.42 has been tagged
<z_existence> anyone familiar with acer_wmi
#ubuntu-kernel 2009-04-17
<trichobezoar> What do I have to do to get the improperly mentioned fix in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275120/comments/5 looked at and hopefully put into the ubuntu kernel?
<ubot3> Malone bug 275120 in linux "Atheros WLAN AR242x LED doesn't work" [Undecided,Fix released] 
<pgraner> trichobezoar: That fix will prob never make Intrepid, it doesn't meet the SRU requirements
<mjg59> Hm. Is bug #357760 restricted access?
<ubot3> mjg59: Bug 357760 on http://launchpad.net/bugs/357760 is private
<mjg59> Right
<trichobezoar> It's accepted into the main kernel iirc
<pgraner> mjg59: yep, it is for custom engineering work
<pgraner> trichobezoar: IIRC is in Jaunty but won't make Intrepid
<trichobezoar> Oh.  I'm using jaunty but as of last update it's not working.  I guess there's nothing that needs to be done - just wait?
<pgraner> trichobezoar: it didn't make the release kernel but should be in the first update. We have lots of stuff queued up
<pgraner> trichobezoar: on a 2nd look it is in the current kernel if its not working for you, you'll need to open a new bug. There are various models that didn't work with that patch.
<trichobezoar> You're talking about 2.6.28-11-generic #41?
<trichobezoar> If that's the right version, I assumed that it wasnt included because I do not have any /sys/class/rfkil/rfkillX/state, and I have a NC10 with the 168c:001c (rev 01) ar242x card
<trichobezoar> Could be a config issue.  Says CONFIG_ATH5k_RFKILL has to be enabled
<trichobezoar> I want to know if I need to make a bug for this to be included or not.  
<jbuncher> apw:  Sorry it took a while, but last week or so I finally got around to testing the ubuntu-modules package you posted in Bug #327431.  Let me know if you need me to test anything else.
<ubot3> Malone bug 327431 in linux "iwl3945 cannot connect to hidden ssid WPA enterprise with Hardy 2.6.24-23 - Regression" [High,Incomplete] https://launchpad.net/bugs/327431
<randompie> Anyone who can help me with: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358255?
<ubot3> Malone bug 358255 in linux "[jaunty] Root on nvidia raid 1 mirror does not boot" [High,Triaged] 
<randompie> Pointers to where I could download the Ubuntu Jaunty specific kernel source and build it?
<TheMuso> randompie: Do you have the dmraid package installed?
<randompie> yes - dmraid 1.0.0rc15-ubuntu1. And, let me clarify - I am typing this on the same machine running "2.6.28-11-generic #41-Ubuntu". The only thing is that while booting I used the 2.6.27-13 initrd
<TheMuso> Right.
<TheMuso> randompie: I have added to the bug.
<randompie> TheMuso: sudo dmraid -s:
<randompie> /dev/sdb: "sil" and "nvidia" formats discovered (using nvidia)!
<randompie> /dev/sda: "sil" and "nvidia" formats discovered (using nvidia)!
<randompie> *** Active Set
<randompie> name   : nvidia_gdcfaafd
<randompie> size   : 312581760
<randompie> stride : 128
<randompie> type   : mirror
<randompie> status : ok
<randompie> subsets: 0
<randompie> devs   : 2
<TheMuso> randompie: please put that in the bug
<randompie> spares : 0
<randompie> TheMuso: will you be online for the next 15 minutes? If so, I can reboot and tell what the output of "dmraid -ddd -ay" is. Bug is updated
<TheMuso> randompie: yes I will be online.
<randompie> ok. will catch you later. thanks.
<TheMuso> randompie: np.
<randompie> TheMuso: I am back. Have updated: bug 358255
<ubot3> Malone bug 358255 in dmraid "[jaunty] Root on nvidia raid 1 mirror does not boot" [High,Incomplete] https://launchpad.net/bugs/358255
<TheMuso> randompie: thanks
<randompie> TheMuso: it seems the core is "device-mapper:	table: 252:7:	mirror: Device lookup failure" so I guess your reasoning about dmraid is bang on target :) 
<TheMuso> randompie: thanks for that.
<randompie> are dmraid userland different in the two cases: 2.6.27-13 and 2.6.28-11? Ifo so, how can I update the initrd for 2.6.28-11 to use the dmraid tools of working initramfs and test it out - if it works - dmraid is the bad boy ...
<TheMuso> randompie: the version of dmraid in the 2.6.27 initrd is older than the one in 2.6.28-11-generic and the only way you can fix them both up is if you downgrade the dmraid packages to the ones in intrepid.
<TheMuso> randompie: once you do that, you will have to pin the dmraid packages to stay at those versions, however I don't know how to do that.
<randompie> TheMuso:  Based on what you said about dmraid on Intrepid and Jaunty being different - my system is using 2 different versions of dmraid - at boottime the one in Intrepid which allows it to mount the RAID array and post boot-up the one in Jaunty which allows it to continue working. Now that I think about it, there is an issue with Jaunty's dmraid - I created an updated initramfs for 2.6.27-13 which also failed. So, I am using the older (intrepid)
<TheMuso> randompie: right
<randompie> so, is there a way to change just parts of the initramfs?
<TheMuso> randompie: I think the problem could be that your system has more than one lot of dmraid metadata on the hard disks. What I think you would need to try is to firstly back up data, erase dmraid metadata, re-create in BIOS, and re-install from a fresh jaunty CD.
<TheMuso> the multiple lots of dmraid metadata is confusing dmraid I think
<randompie> TheMuso: why is it confusing the Jaunty version
<TheMuso> randompie: I don't know yet
<TheMuso> randompie: can you run this command for me? "sudo dmraid -R"
<randompie> TheMuso: The Intrepid one works fine. Also, its picking up the correct set: "/dev/sda:	"sil" and "nvidia" formats discovered (using nvidia)". The seciond version of metadata is because I had used a SIL controller earlier - I didn't even remeber it till I saw today's messages
<randompie> what will "sudo dmraid -R" do?
<TheMuso> randompie: right
<randompie> sudo dmraid -R will rebuild the RAID array - how destructive is that?
<TheMuso> randompie: sorry, sudo dmraid -r
<randompie> we had better be careful about case here - guess we should avoid such options :)
<TheMuso> randompie: how about we go to private chat, so we don't clutter a channel thats not really for this sort of thing?
<randompie> ok
<macli> I am compiling kernel on hardy, followed https://wiki.ubuntu.com/KernelTeam/KernelMaintenance, but still get /bin/bash: makedumpfile: command not found
<macli> debuild -b: dpkg-checkbuilddeps: Unmet build dependencies: makedumpfile xmlto docbook-utils gs transfig sharutils
<smb_tp> macli, makedumpfile? is this a intrepid or jaunty kernel you try to compile?
<smb_tp> Cause makedumpfile does not exist for Hardy. You would need a compile chroot for that. See https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter
<macli> smb_tp: thanks for the info
<eagles0513875> hey guys im having issues compiling the kernel i have the image source and it doesnt seem to be compiling right 
<eagles0513875> i did it using apt-get source but im still haveing issues trying to install it
<vadi21> I need to package an updated madwifi snapshot for intrepid - where should I be looking to create a package? It doesn't seem that the madwifi drivers themselves haven't been packages for ubuntu previously
#ubuntu-kernel 2009-04-18
<bjoern_>  I have built the new 2.6.29 kernel, but the generated debian packages are too big. I used the following command: make-kpkg --initrd --revision atl1c binary
<maxb> Hi, can someone point me to whereever it is defined that some wifi channels are not allowed for IBSS ?
<hmh> Guys, I am the upstream kernel maintainer for the thinkpad-acpi driver, and users are asking me to produce patches for the ubuntu kernels for the testing releases...
<hmh> which kernels are these, and what are their git trees?
<hmh> That would allow me to release patches for ubuntu kernels as well as for mainline (since you guys already include some backports, including of thinkpad-acpi, the mainline patches often don't apply on top of regular ubuntu kernels)
<mjg59> hmh: The git trees are all on kernel.ubuntu.com/git
<hmh> mjg59: yeah, that I know :)
<mjg59> Oh, right. karmic is the next release.
<hmh> what I don't know, being no Ubuntu user, is which ones are the ones for the official kernel releases for the active ubuntu versions...
<mjg59> (well, following the one that's out this month)
<hmh> I suppose I could get the best effort/value ratio if I worked only with whatever is being used most by the power users, that would be whatever is your latest stable desktop version...
<mjg59> hmh: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=summary for the one that's in RC, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=summary for the new development cycle
<hmh> and what is the stable one?
<hmh> I will produce patches for the stable and RC.  Users of devel version can feel free to merge from my tree if they want.
<mjg59> -intrepid is the current stable release
<hmh> ok, thank you
<hmh> mjg59: do you guys want to coordinate something re. thinkpad-acpi backports, or are you following what is upstream nowadays?
<mjg59> hmh: I'm not one of the relevant guys any more :)
<hmh> :)
<hmh> any of them around?
 * hmh finds https://wiki.ubuntu.com/KernelTeam/KernelGitGuide and bookmarks that
<mjg59> Given that next week's the release, I suspect they're having a quiet weekend in preparation
<hmh> heh, I can relate to that
<hmh> hrnf, git is taking forever to fetch intrepid, sending megabytes of crap too instead of just pulling data. I wonder WTF is it doing, that it can't find easily the merge point...
<hmh> I have never seen it do that before!
<zorbo> anyone alive in here?
<dtchen> sure, but the people you seek may not be (weekend and all)
<zorbo> :/
<dreamon> Hello, My notebook doesnt shutdown 100%.. The display is on.. i can see white display, an how the digits lose lightning. But notebook keeps turned on. So i have to press powerbutton for a few seconds du stop runnig.
#ubuntu-kernel 2009-04-19
<RainCT> Hi
<RainCT> Is there a 2.6.29 kernel or something other than the default one packaged for Jaunty?
<amitk> RainCT: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<RainCT> amitk: thanks
<amitk> RainCT: these are not officially supported, but are packaged for your convenience. They are strictly upstream kernels and we will not accept any bugs filed against them.
<RainCT> Uhm.. Is there some way to remount / without restart if Â«sudo mount -o remount,rw /Â» tells me that the device is write-protected?
<Rnemo> hi, may i ask a question on a kernel module here?
<nodeboy> i'm wondering if someone could give me a comentary on the following when im running vbox with default swapiness a large amount of page file is used if i set swapiness to 0 then a small amount is used (well ok thats kinda obvious i guess) what i'd like to know is there anything to stop the vbox process being swapped or is there some sort of page hint that could be assigned to the vbox memory to prevent them being swapped 
<savvas> hello, I was just wondering if there was a discussion about setting kernel's timer frequency to 1000 for desktop kernels? Does it actually optimize the system in speed? Would there be any downsides if this was implemented in -generic?
<savvas> I'm not very keen on kernel compiling, I was just wondering about the 1000hz on a desktop system, as it is the recommended one as far as I can see: http://cateee.net/lkddb/web-lkddb/HZ_1000.html - and of course, why is 250hz favoured?
#ubuntu-kernel 2010-04-19
<VinceN> Good Evening everyone
<VinceN> persia : I ran the latest CD.  The fans seemed to work ok so I went ahead and installed it.  Bad idea.  They work but only intermittently it seems.  I'm still trying to see a rhyme or reason too it.  That being said I want to say congrats to you guys.  Lucid is VERY nicely done otherwise from what I can see
<VinceN> I also did some more research, There looks like there might be a firmware update to the laptop that might fix the issue but the update is supposed to be run from inside a windows environment.  There is a DOS bootable CD that supposedly works that someone put up but iI'm hesitant to try it as if I bork the firmware update my laptop is pretty much hosed.
<persia> I'm sorry to hear your issue isn't perfectly addressed.  Good luck with the firmware update.
 * hyperair heard of a windows livecd or other, but it isn't free, or legally free, in any case.
<Sarvatt> apw: regarding the multibyte EC problems, look familiar? - https://bugzilla.kernel.org/show_bug.cgi?id=15749 fix is released upstream
<ubot3> bugzilla.kernel.org bug 15749 in EC "bisected 2.6.34-rc3+git EC regression - can't boot after fix from bug #14667" [High,Closed: code_fix] 
<apw> Sarvatt, that is indeed equivalent to the fix we had homed in on.  and would be in lucid now if the macbook pro tester didn't have other unrelated but simultaneously appearing issues which masked its success
<RAOF> apw: Good morning.
<apw> mornig
<apw> RAOF, anything exciting occuring in your world?
<Sleep_Walker> hi
<Sleep_Walker> AceLan: please, is kexec broken in 2.6.28-araneo?
<Sleep_Walker> what 'araneo' means? it's kernel branch for some set of devices?
<AnAnt> Hello, can I build the kernel package (linux) using pbuilder ?
<amitk> AnAnt: we only support debuild
<AnAnt> good
<AnAnt> amitk: that doesn't necessarily mean that the answer to my question is 'no', right ?
<amitk> AnAnt: right, I just don't know how and why I would use pbuilder.
<AnAnt> ok, thanks
<hyperair> amitk: build-depends!
<AnAnt> as for why, because I don't want to install -dev packages on my system
<AnAnt> hyperair: exactly
<hyperair> AnAnt: you do realize how thin the build-depends of a kernel are, right?
<hyperair> Build-Depends: dpkg (>= 1.13.19), debhelper (>= 3), gawk
<AnAnt> hyperair: no I didn't know actually, I just saw stuff that aren't on my system
<hyperair> hmm?
<AnAnt> hyperair: binutils-dev, libelf-dev
<hyperair> AnAnt: heh? i don't remember needing those..
<AnAnt> hyperair: http://packages.ubuntu.com/source/lucid/linux
<AnAnt> I look at {a,i}dep: lines
<hyperair> AnAnt: maybe something changed. i use make-kpkg. don't need any of those =p
<apw> hyperair, they are new for the perf tools
<tgardner> apw, hmm, mumble ain't gonna work too well unless I can find a microphone 
<apw> tgardner, heh yeah its not the most useful without that
<apw> though with push to talk many people use it with a lid mike
<apw> one of your dells prolly has one of those
<hyperair> apw: perf tools?
<hyperair> apw: what perf tools?
<apw> the kernel source has started to carry tightly coupled tools like perf
<apw> so we now have a new linux-tools package which carries these version locked tools
<hyperair> oh interesting
<apw> progress progress
<achiang> ugh, last night, i suggested a workaround for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374
<ubot3> Malone bug 532374 in oem-priority "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,In progress] 
<achiang> didn't work though because i was looking at an upstream tree, not the ubuntu tree
<achiang> i suspect backporting d7f0eea9 will resolve the issue
<apw> achiang, that just adds a command line option for sci something somtthing, doesn't add any blacklists
<achiang> apw: well, right -- i wanted to verify it actually helped before adding a quirk
<apw> damn these machines are a mess
<achiang> apw: let me forward you a mail from jerone that suggests it is the correct workaround ; i guess i'm sniffing about for a way to do a test kernel for these folks to try to see if it helps
<apw> achiang, the bug is currently closed against linux, cause lenovo thinks the issue is their bios?
<achiang> apw: yes, the issue is a BIOS bug, but windows works because it essentially does that sci_force_enable quirk. it would be nice if our kernel did that too so people wouldn't be forced to upgrade BIOS
<apw> windows is such a pain, if only we didn't have to overlap with it
<apw> 'it works with windows' makes me want to scream
<achiang> be that as it may, that is the de facto standard for Linux/ACPI
<apw> nominally you can't have a defacto standard where there is an actual published standard
<apw> all you can have is compiant or _broken_ bioses
<achiang> well, that is de facto vs de jure. ;)
<achiang> apw: on a more practical note, upstream Linux/ACPI including maintainer explicitly state windows bug-for-bug compatibility is the policy. so in that sense, ubuntu shouldn't deviate from upstream
<apw> well de facto has "without being officially established in it"
<apw> then they really should just turn on that bit no?
<apw> if thats what doze does
<achiang> well, they do, but as a quirk... i mean -- you're right -- official standard says, "that's BIOS's job, not OSPM" so i think it would be dangerous to categorically turn it on all the time, punishing the BIOSes you point out that *are* compliant
<apw> if the definition is "it must be on on return" then its not clear we can get it wrong
<apw> seems lucid only has quirks for HP for this issue
<achiang> that bit is owned by BIOS, not the OS, so it's dangerous for the kernel to set that bit unconditionally
<achiang> unless it's for a known broken platform
<achiang> at least that's the impression i got from reading the comment added by the commit i named above
<apw> though the description says it _must_ be on on resume, so it not being would mean we should set it to my eye
<achiang> hm, i see quirks for mac platforms in lucid
<apw> there are other quirks in the table, not all for that one item
<achiang>         .callback = init_set_sci_en_on_resume,
<achiang>         .ident = "Apple MacBook 1,1",
<apw> oh not really old old old macs yes
<achiang> am i looking at the wrong tree?
<apw> trust macs to be broken, they are more broken than windows boxes mostly
<apw> achiang, anyhow if i am reading this right that command line patch is the next one against that file so it should apply triviallu
<achiang> apw: nod, i'm trying to convince someone here to make that patch and do a test kernel. i don't want to overstep my bounds since i'm on the OEM team, not platform
<apw> overstep your bounds?  slap it on and build it, its a community distro
<apw> its not like most of us have anything to test it with
<achiang> heh, ok. guess i need to go figure out how to build / release a kernel the ubuntu way. i'm a new hire too and just ramping up on process here. ;)
<apw> heh i could do it for you, but its a good learning experience
<apw> all my resources are tied up building other things right now, its a busy time
<achiang> sure, ok
<achiang> apw: do you still consider https://help.ubuntu.com/community/Kernel/Compile to be accurate?
<tgardner> achiang, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
<achiang> ah, ok
<tgardner> achiang, we also have a meta page with links to lots of topics: https://wiki.ubuntu.com/KernelTeam
 * achiang bookmarks
<achiang> thanks tgardner 
 * apw suspect you will find many inaccuracies that we can no longer see for doing it too much
<tgardner> achiang, feel free to correct said inaccuracies
<apw> achiang, feel obligated to fix them :)
<achiang> project creep! ;)
<achiang> but ok, will do. ;)
<crazybyte> jjohansen, hello. may i take up a bit of your time?
<jjohansen> crazybyte: sure
<crazybyte> jjohansen, i read your comment on the oops related issue. what is strange is that those oopses happened sometime before suspend and now i'm on the lucid kernel and i'm running it since yesterday after several suspend/wake up cycles without any issue.
<jjohansen> crazybyte: ? Maybe I misinterpreted what you said but I thought the crashes were coming post suspend
<crazybyte> jjohansen, mostly
<crazybyte> that is what i observed
<crazybyte> but when i started having those issues i remember that sometime they happened before suspend
<crazybyte> but then i was using the karmic kernel
<crazybyte> now they happened after wake ups
<crazybyte> until yesterday
<crazybyte> nothing since than
<jjohansen> hrrmm, that doesn't really make sense, did you run an update?
<crazybyte> no. at least not in the case of the kernel because it's the main lucid kernel installed in karmic so i can't update it by usual means
<crazybyte> jjohansen, i will keep my eye on this because it's pretty strange
<crazybyte> also could you have a suggestion how to find out what resides at that particular address when the oops happens
<crazybyte> i'm very curios about what is there when they happen because the addresses repeat themselves sometimes
<jjohansen> crazybyte: hrmm, well you can look at /proc/<pid>/maps
<jjohansen> and also the boot messages
<crazybyte> jjohansen, could ksymoops help me better somehow i didn't thought of?
<crazybyte> ok
<jjohansen> crazybyte: hrmm I can't see what more you are going to get from ksymoops
<crazybyte> i see
<crazybyte> ok
<crazybyte> thanks
<apw> most oops addresses are kernel side and so only vagely categorisable into a few simple categories
<jjohansen> crazybyte: well it might if you can hit it right after the oops, and use /proc/kallsyms but since these are freezes I don't see that happening
<crazybyte> yeah
<lool> hey folks
<lool> My kernel is doing stuff but I dont know what
<lool> and my machine is dying under background IO load
<lool> I tried sudo perf top, iotop, regular top, and can't tell what's happening
<lool> see bug #549428
<ubot3> Malone bug 549428 in apparmor "Triggers permanent high i/o load after upgrade" [Undecided,Fix committed] https://launchpad.net/bugs/549428
<lool> I get this regularly, but not daily
<lool> I will have to reboot the system pretty soon given that it's almost unusable now; anything I can do?
<lool> I don't know whether that's expected, but cat /sys/kernel/debug/dri/64/vma returns
<lool> cat: /sys/kernel/debug/dri/64/vma: Cannot allocate memory
<lool> sudo cat i915_ringbuffer_data
<lool> cat: i915_ringbuffer_data: Ne peut allouer de la mÃ©moire
<lool> that sounds bad
<smb> At least like something went crazy requesting memory
<lool> oddly, meminfo lists plenty of cached stuff
<lool> Oh I know
<lool> So I'm using ecryptfs
<lool> and I use unison in the background
<lool> Every so many days, this starts happening
<lool> I bet it's not giving back some memory to the OS
<lool> smb: How could I track memory down?
<lool> http://paste.ubuntu.com/418779/ < meminfo
<lool> Cached:          2492220 kB
<smb> Maybe one could keep tracking memory allocation while running
<smb> apparently you cannot even look right now
<lool> smb: Well my system still runs for some rason
<lool> reason
<smb> A high cached value is normal
<lool> I suspect the background load is swapping
<lool> Except I dont have any hmm
<lool> smb: Yes, but I mean this should be reclaimable to allocate memory
<lool> smb: I would expect that if my kernel used all available mem, this value would be small
<lool> VmallocTotal:   34359738367 kB
<lool> VmallocChunk:   34359353372 kB
<lool> that's.... too much
<lool> I don't have 34 TB of vm
<lool> Hmm apparently that's normal
<lool> it matches another host
<lool> probably some addressable range
<smb> I would believe so
<smb> lool, The thing is that you seem to be unable to start new tasks which sounds like shortage of allocable memory
<lool> smb: I can actually start other tasks
<lool> Could at least
<lool> smb: I could open an xterm for instance
<lool> albeit slowly
<smb> I wonder whether iotop could help here or whther it only will show that swapper is on  duty
<AnAnt> Hello
<AnAnt> I am downloading linux source package
<AnAnt> I wanted to know which file should I edit if I wanted to change the configuration for the -generic package 
<smb> AnAnt, Depends a bit. The linux-source package is not that useful
<smb> AnAnt, apt-get source linux-image-... or git is more useful
<AnAnt> smb: well the source package for linux-image-... is linux
<smb> AnAnt, In that case it is in debian.master/config/(i386|amd64)/config.generic
<smb> AnAnt, Unfortunately the is also a package called linux-source
<smb> which is only the general parts without the debian directories
<AnAnt> linux-source was in dapper
<AnAnt> according to:http://packages.ubuntu.com/search?searchon=sourcenames&keywords=linux-source
<smb> AnAnt, In Dapper the source package was named linux source. But later linux (as the source package) also creates a binary package called linux-source
<AnAnt> aha
<smb> Its a bit confusing and often people get tricked into installing the architecture independend binary package because it has source in its name. Thats why I usually try to make sure that you have the real source package
<AnAnt> which is 'linux' , right ?
<smb> right
<smb> Just looked, the flavour package seems to be config.flavour.generic now
<smb> err I mean the config file
<smb> But its a stacked approach you got a top level config.ubuntu.common a config.i386(or amd64).common
<smb> and the flavour specic
<AnAnt> where's that ?
<smb> AnAnt, You will find everything when you descent into debian.master/config
<peterz> apw: can you fix this messed up kernel-list@ubuntu to not send bounces for each msg?
<peterz> apw: or educate folks to not cross post to lkml
<achiang> anyone have a lenovo x201 and can send me dmidecode | grep Version ?
<apw> peterz, bah sorry man ...
<apw> i'll get my cluebat out
<peterz> apw: thanks mate! :-)
<kyanardag_> hi, i'm using Karmic right now and I noticed at http://kernel.ubuntu.com/~kernel-ppa/mainline/  kernel version 2.6.34.rc3 is available. If I download and install .deb file for linux-source will I be good to go with that kernel version? (no compiling, no configuring, no boot-image generating)
<kyanardag_> also, i added the kernel-ppa repository by sudo add-apt-repository ppa:kernel-ppa/ppa but i get error "Failed to fetch http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu/dists/karmic/main/binary-amd64/Packages.gz  404  Not Found"
<abogani> kyanardag_: No it is generally used to try bugs against the latest linux kernel version so 1) It isn't tested at all by us 2) It don't contains Ubuntu patches 3) We don't provide any type of support on it.
<abogani> kyanardag_: AFAIK It isn't available in PPA you should click and install from kernel.ubuntu.com.
<kyanardag_> abogani, i see.. it's just vanilla kernel? thanks..
<abogani> kyanardag_: Exactly.
#ubuntu-kernel 2010-04-20
<JohnFlux> Hey all
<apw> hi
<JohnFlux> I'm the author of the KDE task manager program
<JohnFlux> and I can't find any one who would know how to kill a zombie process with a subtask that is using up 100% cpu
<JohnFlux> subtask meaning a process thread
<apw> you can't kill it cause its already dead
<apw> as by the time its a Z it shouldn't have any context to run in, its not a combination which should be possible
<JohnFlux> apw: heh you replied to the email as well
<apw> either its truly stuck in the kernel or or the accounting is lying
<JohnFlux> apw: please read what I'm saying though :-)
<apw> just tell me here which bit you think i am miss understanding
<JohnFlux> The problem is that the task has process threads.  ls /proc/pid/tasks  has two entries
<JohnFlux> the pid of the main process and the pid of the sub process
<JohnFlux> the main process is a zombie but the other is not
<JohnFlux> so top etc see it as a zombie process using cpu
<apw> so they are broken :)
<JohnFlux> why?  it's saying the correct thing
<JohnFlux> the kernel reports the process as a zombie using cpu
<apw> one thread on the process is 'z' one is not so the overall unit of the process is neither R nor Z it is a combination
<JohnFlux> which is correct.  /proc/pid/status  etc give the status of the main thread
<apw> to represent it as either is wrong
<JohnFlux> so, question is, how to kill such a beast?
<apw> ps -T here shows they also have their own SPID, their own thread pid
<apw> i would have expected that to be a killable id also
<apw> and indeed those appear as first class PIDs in /proc/
<JohnFlux> apw: I would have thought that too, but nope :-/
<JohnFlux> ls /proc/5728/task/
<JohnFlux> 5728  5810
<JohnFlux> kill -9 5810
<JohnFlux> but it's still there
<JohnFlux> still using 100% cpu
<apw> JohnFlux, an what state is that subtask in
<JohnFlux> State:  R (running)
<apw> consuming user of system time?
<apw> and what did kill -9 say when you did it?
<JohnFlux> apw: it says nothing - it doesn't say invalid pid or anything
<JohnFlux> apw: how can I see if it's user or system time?
 * apw looks
<apw> also can you attach strace to it to find out what it is actually doing?
<JohnFlux> ah
<JohnFlux> apw: it's 100% system time
<apw> does strace tell you which syscall its in?
<apw> and which kernel is this?
<JohnFlux> strace doesn't say anything :-/
<apw> so it may be stuck in the kernel somewhere
<JohnFlux> 2.6.33-020633-generic
<JohnFlux> it's ubuntu's kernel
<JohnFlux> it's ubuntu+1 kernel
<apw> its a mainline kerenel, without any ubuntuness
<apw> i suspect its probabally broken
<apw> you may be able to find out what if anything that thread is doing, as its likely stuck on the CPU
<apw> is there anything in dmesg about CPU lockuips?
<JohnFlux> [  289.396260] ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 256
<JohnFlux> I have lots of these
<JohnFlux> lots = about 25
<apw> failing that you may need to use the 'running process stacks' option from sysrq
<apw> to see if you can get a stack off it
<apw> those are debugging from the staging driver for wireless i believe
<AnAnt> Hello, I get this error when compiling kernel:
<AnAnt> II: Checking modules for generic...previous or current modules file missing!
<amitk> AnAnt: add a skipabi=1 before your build command
<AnAnt> amitk: I did that
<amitk> or rather skipmodules=1
<AnAnt> ah
<AnAnt> skipmodules=1 didn't change the situation
<amitk> AnAnt: try skipmodule (w/o 's')
<AnAnt> amitk: ah, thanks
<AnAnt> amitk: what's the ABI & modules check for ?
<amitk> AnAnt: ABI is to announce to external modules that the kernel interfaces have changed (so recompile) and module check is so we don't lose some modules during config changes
<AnAnt> neat
<AnAnt> so how can I get the previous ABI & <flavor>.modules files ? are they present somewhere in the installation ?
<cnd> kamalm: great patch!
<cnd> are you familiar with signed-off-by and similar tags?
<bjf> **
<bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> **
<kamalm> cnd: thanks!  I'm aware of Signed-off-by but feel free to share advice and/or wiki pointers -- I'll take all the help I can get.
<cnd> kamalm: so when we write patches, which I assumed you did in this case, we add the signed-off-by tag
<cnd> actually, now that I think of it, that applies to any patches you submit
<cnd> it says you've tested it, it looks good, and it appears to be freely licensed for us to use
<cnd> the other thing we tend to do is keep notes in a separate email
<apw> it says you believe it is submittable to an OSS project
<apw> or that the person who gave it to you said it was and you haven't changed it
<sconklin> cnd: my understandint is that author is enough for a patch that was written by the submitter
<cnd> so the header you put on the email usually goes in a preceding email
<kamalm> cnd: yes, I did write it -- sconklin suggested that I should *omit* any Signed-off-by: tag at this stage -- ah here he is -- fight it out boys!
<cnd> hmmm, I really do not know
<cnd> I was just going by what I thought other people were doing
<cnd> is there some docs somewhere about this?
<sconklin> I suppose that there's no harm in using author AND SOB, but that may imply an independent ack that doesn't exist
<sconklin> for the case where you are applying someone else's patch - it's clear - they are the author, and you should sign off.
<apw> sconklin, no the sign off is more than a author line, it says its applicable to the project, its yours to do that with
<cnd> sconklin: kamalm: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD
<sconklin> apw: ok, I stand corrected, and kamalm looks like you should add SOB
<cnd> line 286
<apw> pretty much the only time you might not, would be to stop someone applying it if you know you don't want it applies
<kamalm> cnd, sconklin, apw: ok, thanks for that -- I'll examine the doc.
<cnd> kamalm: so then with the extra notes at the top
<achiang> if you are in the patch delivery path, you need to add an SOB
<cnd> generally what I do is I edit the patch subject so it says [PATCH 1/1]
<cnd> then I use --compose with git-send-email
<cnd> and write my notes in the editor that comes up
<cnd> and use the same subject but with [PATCH 0/1]
<cnd> that way it's easy to separate what is the patch, with the full commit message
<cnd> and what's a note to go along with it, like a testcase
<kamalm> cnd: so wait ...  the [PATCH 0/1] message is the "extra information" message, yes?
<cnd> yes
<cnd> however, in this case, all the info you provided should be in the commit message anyways
<achiang> kamalm: a "cover letter" isn't always needed especially when you're sending out a singleton patch
<cnd> so I don't think you need a separate 0/1 cover letter here
<kamalm> cnd, achiang: okay that was my exact next question.  :-)
<achiang> kamalm: typically i write a cover letter when i'm writing a series of patches ; the cover letter explains the high-level goal of the series ; but each patch within the series has a standalone commit log that makes sense to an outsider even if not in-context of the overall series
<kamalm> So now there are two "known problems" with my patch as submitted:  1. needs my SOB.  2. i should not have included debian.master/changelog in the diff.    So should I now correct those issues and re-submit?   Or is this one good enough as it stands now?
<kamalm> achiang: re cover letter -- very good, thanks.
<achiang> kamalm: other appropriate info for a cover letter: testing that may have happened, a changelog of the series (typically a complex series needs several revisions, so it's nice to say: v1 -> v2, and list the changes)
<achiang> etc.
<achiang> kamalm: just read lkml for a while and you'll figure it out. ;)
<kamalm> cnd, sconklin: So should I now correct those 2 problems (^^) and re-submit the patch, or leave it as is?
<sconklin> kamalm: correct and resubmit
<kamalm> sconklin: ok, and do I need to do anything to "rescind" the one I submitted already?
<sconklin> nah, you can put "resubmit" in the subject of the next one
<kamalm> sconklin: ok, will do!
<kamalm> cnd, achiang: thanks for the help!
<achiang> np
<cnd> kamalm: often when people resubmit they change the subject to be [PATCH v2] instead of just [PATCH]
<kamalm> cnd: good tip, thanks!  (I'm studying the SubmittingPatches doc now).
<apw> kamalm, keep it up
<kamalm> apw: thanks, will do!
#ubuntu-kernel 2010-04-21
<AStachowski> Hello guys. Could anyone point me in the right direction when it comes to build a recent Lucid kernel for my ppa? I tried it with debuild -S, -S -sd and -S -sa. But none of these seem to work. Is there a special script I need to prepare it?
<tgardner> AStachowski, have you read https://wiki.ubuntu.com/KernelTeam/KernelMaintenance ?
<AStachowski> I think I've forgotten that part if it is necessary: dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*' -sa
<AStachowski> Though I thought it was only necessary for git pulled releases.
<AStachowski> I think I already read https://wiki.ubuntu.com/KernelTeam/KernelMaintenance and thought it would only apply to GIT. Guess I'll try it this evening. ;)
<JFo> AStachowski, how did you get your source?
<JFo> did you not use git to pull it?
<AStachowski> nope
<AStachowski> I got it by apt-get source linux-image-$(uname -r)
<AStachowski> if git pull is the way to go I don't mind, too.
<JFo> ah, I see
<JFo> AStachowski, whatever works for you
<JFo> but I think I see a need for another set of instructions for folks wanting to pull from there
 * JFo adds a note to his 'wiki improvements' doc
<AStachowski> ;D
 * peterz fixed /sbin/installkernel and uses make install form the kernel tree ;-)
<peterz> all this package nonsense is just that ;-)
<JFo> :-)
<AStachowski> I thought I'd finally give something back to the community by building a subflavor of linux-image-generic for SCST -> SRP Target for the Infiniband folks.
<JFo> AStachowski, a noble gesture ;)
<persia> Are drivers for that not generally available, or just not built-ins?
<AStachowski> Infiniband sadly is a bit more complicated than that.
<amitk> peterz: don't we all wish that all users could compile their own kernels :)
<AStachowski> there is a standard target daemon in alls linux distros but it genuinely sucks when it comes to larger setups.
<JFo> amitk, I don't :-D
 * JFo looks at the bug volume as it is
<AStachowski> too many cooks spoil...you know the deal ;)
<JFo> yep
<JFo> great minds AStachowski 
<MTecknology> I thoguht apparmor was in the mainline kernel now
<abogani> peterz: What is the fix for /sbin/installkernel?
<peterz> abogani: add to the tail: mkinitramfs -o /tmp/initrd.img ${ver}; updatever initrd.img /tmp/initrd.img; update-grub
<peterz> sometimes I need to hack update-grub too, depending on the crazy ass ideas it gets
<achiang> peterz: nice. i figured out that i could issue a 'make deb-pkg' from kernel directory, install the deb, and then issue a mkinitramfs, but your way seems much nicer
<peterz> achiang: make sure to do 'make INSTALL_MOD_STRIP=1 modules_install' if you use modules 
<peterz> because for some reason mkinitramfs doesn't strip the modules
<peterz> and you end up with a 100M+ initrd
<peterz> of course the sane thing to do is not use modules :-)
<MTecknology> peterz: That REALLY hard to do sometimes though
<peterz> MTecknology: nah, just don't do silly things like use lvm/crypto/raid root paritions
 * MTecknology grumbles at one particular module
<MTecknology> peterz: I need moduel support for vbox but having module support forces another config to be module instead of built-in
<achiang> peterz: eh?
<achiang> achiang@aspen:/boot$ ls -l initrd*34-rc5* | awk '{print $5}'
<achiang> 3381926
<MTecknology> 34 hates my computer it seems
<achiang> peterz: hm, maybe part of the make deb-pkg magic strips the modules for me, since i don't issue make modules_install directly
<peterz> MTecknology: ah, out of tree stuff, I don't acknowledge the existance of such
<peterz> achiang: yeah, I figure it would, also you of course need to start out with CONFIG_DEBUG_INFO=y
<achiang> peterz: heh. achiang@aspen:~/kernels/linux-2.6$ grep DEBUG_INFO .config
<achiang> # CONFIG_DEBUG_INFO is not set
<MTecknology> peterz: that would be awesome if they could have their modules in there
<peterz> MTecknology: not a chance, the code is alike waaaay ugleh
<MTecknology> probably
<cnd> peterz: sorry about the kernel-team list bounces
<cnd> I think we've got that taken care of, so it shouldn't happen in the future
<peterz> cnd: awesome
<cnd> peterz: btw, any more thoughts on the ILB load avg implementation?
<peterz> cnd: right, so the reason I wante dto share infrastructure with the ILB is because people were looking at making the ILB scale better and its all about NOHZ muck, so it seemed like a nice fit
<cnd> ahh, ok
<peterz> cnd: just need to get a spare cycle to sort through all the details, hopefully somewhere later this week
<cnd> peterz: ok, thanks
<osmosis> running fresh lucid daily build, I get random lockups. Can't drop to a terminal or anything.
<osmosis> Im getting an hard freeze on two different laptops. one with 64, other x86. Both running fresh installs of lucid daily builds.
<bjf> osmosis, please file a _new_ bug against the issue
<osmosis> bjf, im not sure how to gather any info about the cause of the lockups.
<bjf> osmosis, will it stay up long enought to run ubuntu-bug on it?
<osmosis> bjf, cursor stops moving and spinning.  CTRL-ALT-F1 for a terminal doesnt work either.
<bjf> osmosis, had you been running a previous daily build?
<osmosis> bjf, i had beta2 installed briefly, but did a full format clean install of lucid daily build yesterday.
<osmosis> bjf, i thought maybe the crash was hardware specific...but I installed on two separate laptops and they both are getting the same issue. And they are very different hardware.
<bjf> osmosis, what graphics do the two systems have?
<bjf> osmosis, was beta2 running ok?
<osmosis> bjf, both are ati ...thought different models.
<osmosis> bjf, ATI Radeon Express 200  and   ATI Mobility Radeon HD 4670
<bjf> osmosis, have you tried booting without "quiet" or "splash" on the kernel boot line?
<osmosis> bjf, machines come up and are usable. The crash is a randomly triggered lockup...occurring on average every hour or two.
<bjf> osmosis, then they are up long enough to run ubuntu-bug on and capture the hardware information
<bjf> osmosis, ubuntu-bug will capture everything you need
<osmosis> bjf, ok
<bjf> osmosis, do two separate bugs, one for each system and then let me know the bug numbers
<bjf> osmosis, thanks
<cnd> osmosis: you might want to try booting with "pci=nomsi" on the kernel command line
<cnd> that has fixed some ATI instabilities, and we can add quirks in the kernel for your motherboard if it helps
<anoteng> Where can I find a detailed list of changes between ubuntu kernels? I'm trying to locate the source of a bug..
<osmosis> bjf, here is one, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/568103
<ubot3> Malone bug 568103 in xorg "Xorg freeze lucid daily build ATI Mobility Radeon HD 4670" [Undecided,New] 
<bjf> osmosis, did you see the comment from cnd about booting with "pci=nomsi" ?
<osmosis> bjf, yah
<bjf> osmosis, that would be good to try
<osmosis> bjf, cnd: im gonna see if i can get the crash to occur a couple more times first.
<osmosis> bjf, here is the second, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/568111
<ubot3> Malone bug 568111 in xorg "Xorg freeze dell vostro 1000 lucid daily build ATI Radeon Xpress 200" [Undecided,New] 
<bjf> osmosis, thanks for those
<osmosis> bjf, was previously on karmic with no such issue.
<osmosis> on both laptops
<bjf> osmosis, lots of changes to graphics drivers this round
#ubuntu-kernel 2010-04-22
<Sarvatt> Keybuk: did you ever have a bug filed about your RS600 problem?
<Keybuk> Sarvatt: RS600 ?
<Keybuk> that sounds like a kind of bike
<Sarvatt> latitude XT?
<Keybuk> oh, the Radeon thing?
<Sarvatt> yeah
<Keybuk> no, I don't think I ever filed a bug
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
<ubot3> Malone bug 544590 in linux "[RS600] video freeze with KMS (X and plymouth) (upstream patches available)" [High,Triaged] 
<Sarvatt> was that commit I linked in there the same one that they put together for ya to fix it?
<Sarvatt> drm/radeon/kms: initialize set_surface_reg reg for rs600 asic
<Keybuk> not sure, the laptop and my notes are 5000 miles away
<Keybuk> but it sounds familiar
<Keybuk> I don't think I ever actually got around to testing it
<Sarvatt> ahh ok
<Keybuk> got distracted by the nvidia which needed more active help from me
<Keybuk> remind me when I'm not in SF
<Sarvatt> that GPU is like the rarest of the rare of ATI's, they pulled them from the market during the AMD/ATI merger 
<Sarvatt> (and it's unusable with lucid without nomodeset at the moment)
<Sarvatt> it's ok, got 2 testers to build kernels for to be sure the fixes work :)
<Keybuk> yeah, that's what I was told upstream
<RAOF> Sarvatt: That's the GPU with GTT issues where it'll eventually corrupt all your ram, isn't it?
<Sarvatt> yup
<artnay> any chance to include new files into linux-firmware? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/560306
<ubot3> Malone bug 560306 in linux "[lucid] ATI hd5xxx cards wrongly doing kms?" [Undecided,Confirmed] 
<apw> artnay, whats the issue?
<artnay> apw: there are several setups (seems like affected are only i5/i7 and 5xxx users) which don't even boot using live CD. https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/560306 has the details and links.
<ubot3> Malone bug 560306 in linux-firmware "[lucid] ATI hd5xxx cards wrongly doing kms?" [Undecided,Confirmed] 
<artnay> if you compare the output of "dpkg -L linux-firmware | grep radeon" and http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=radeon;h=3dc32482fcf179c43e2fcc0b30303f231774820a;hb=HEAD it seems that 5xxx series is missing firmware files (which probably would help with the boot issue)
<artnay> I could be totally wrong but that's the only way I see it at the moment.
<artnay> the bug was filed against linux but I moved it against linux-firmware (where it belongs AFAIK)
<apw> artnay, ta
<tgardner> apw, I synced with dwmw2/linux-firmware before I left. Seems that he's added a few new files.
<tgardner> apw, here it is: 'radeon: add evergreen family microcode.'
<apw> yeah looks like a rebase may be in order before release
<apw> _if_ we can confirm it doesn't change any files at least
<apw> otherwise selective picks at least
<tgardner> apw, I'm thinking I'll on;y add the evergreen stuff. there are lots of other changfes, but we should SRU them after the fact
<apw> fair enough
<mjg59> Is Jerone around?
<mjg59> I've just sent a patch for the Lenovo USB resume problem
<mjg59> Thinko in the PCI resume code
<apw> mjg59, to kernel-team@ ??
<apw> or upstream, or :)
<mjg59> apw: Upstream
<mjg59> Should be on -acpi and -pci
<apw> cool ... thanks for the heads up
<apw> kamalm, your patch was miss categorised cause i missed removing the SRU: prefix
<apw> i'll fix that up and repush it
<kamalm> apw: thank you sir.   I must admit that I was^Wam confused about which [TAGS] and TAGS: to add or not add, and what purpose they all serve
<apw> kamalm, yet another thing which is not well documented.  we tried to clean up the templates, and they are a hell of a lot better but they are not right still
<kamalm> apw: well, we have in debian/commit-templates:  sauce-patch and upstream-patch  (but no just "patch" as the wiki claims).   I think I added [Lucid] and SRU: manually, following examples I'd seen, but I felt like I was mostly just guessing (and hoped some kindly human would fix it before a script got its mitts on it).
<apw> putting things in [] are good as they get stripped automatically on applicaiton and [SRU Lucid] is probabally an appropriate prefix
<apw> but yes its all a bit broken and i've added it to our next sprint agenda for review
<apw> tgardner, do i remember correctly that you were looking at the radeon firmware issue?
<tgardner> apw, yep, I uploaded a PPA linux-firmware this morning for the Evergreen series and asked for test results.
<tgardner> bug 560306
<ubot3> Malone bug 560306 in linux-firmware "[lucid] ATI hd5xxx cards wrongly doing kms?" [High,Confirmed] https://launchpad.net/bugs/560306
<apw> excellent, then i can forget about it :)
<kamalm> cking: around?  I still get no joy from the acpi_osi workaround for bug 539477
<ubot3> Malone bug 539477 in gnome-settings-daemon "Video out hot key sends super + p + return on many upcoming Dell & HP systems" [Undecided,Confirmed] https://launchpad.net/bugs/539477
<cking> kamalm, care to send me your DSDT again and I will see why it fails
<kamalm> cking: again?  I never sent it to you before (but will be happy to do so) -- lets make sure I'm even using the workaround correctly.  I've tried booting with acpi_osi="Windows 2006" and acpi_osi="!Windows 2009" but neither helps -- is that syntax proper (i.e. the quotes and the !) ?
<cking> kamalm, my fail, try this acpi_osi=\"!Windows 2009\"
<cking> kamalm, if that fails, send me your dmesg output
<kamalm> cking: okay, that *does* work (yay!)
<kamalm> cking: perhaps you would like to post a comment to the bug with this new and improved workaround?  The last post on the matter suggest using "Windows 2006".
<cking> kamalm, well !Windows 2009 will work until a new version appears and the kernel picks it up, then it will fail again
<kamalm> cking: it'll do for now anyway -- I note that jerone's comment #20 in that bug recommends acpi_osi="Windows 2006" (with no backslashes) so it would not get processed correctly -- but I find that \"Windows 2006\" isn't helpful anyway.
<cking> kamalm, the Windows 2006 method may/may not work depending on the order and how the OSI probes are handled in ACPI. It's ugly and broken 
<cking> I've update the bug
<kamalm> cking: thank you (for the update, and for the workaround!)
<cking> kamalm, thank ppetraki for this one
<cking> I like comment 
<cking> oops, I like the penultimate comment on the bug report
<kamalm> thank you ppetraki :-)
<kamalm> cking: yup. I call first swing with the bat!
<cking> I'm scared of them getting back to me
<cking> ;-)
<cnd> xrandr
<cnd> oops
<cnd> wrong kb
#ubuntu-kernel 2010-04-23
<h00k> I think I'm having a kernel problem in Lucid and I figured this be the qualified place to ask, can I post my dmesg where I started to have problems?
<h00k> It may be related to the current x problem, but I'm using the proprietary driver
<persia> hook: You'd do best to file a bug with all the info, and then ask about the bug.
<persia> saves fussing with pastebints for a selection of commonly-required information.
<h00k> persia: I'll try to get as much info as possible, thanks.
<h00k> persia: if I can get this usable enough, I may have to restart
<h00k> persia: well, what would be useful at this time if it's locking up?
<h00k> if I restart, I have a feeling it'll take a few hours to get it like this again
<persia> `ubuntu-bug linux` usually sends a decent default set of data.
<h00k> I'd like to try and grab as much as I can atmoment
<h00k> right, I'll try to grab a copy of my free mem, too, because I think it's mem related, the kernel doesn't seem to be able to allocate anything and that's why it's severely thrashing
<h00k> is there anything special that would be needed when it's in the 'thrashing' stage? I was able to get $ free from an ssh session I opened
<jk-> h00k: might be https://wiki.ubuntu.com/X/Testing/GEMLeak
<h00k> jk-: I considered that, but I am using the proprietary nvidia driver
<jk-> ah! it
<h00k> and the GEM leak does not apply, apparently
<jk-> 's probably not that then :)
<h00k> but this is most-definitely reproducable on this machine
<h00k> I wrote up a nice descriptive report but edge decided to lose it. *sigh* so I'm writing it up with edge redirection disabled.
<h00k> now to see if it saved all the other information ubuntu-bug grabbed. Yes.
<h00k> cool.
<h00k> bug 56818
<ubot3> Malone bug 56818 in ubiquity "Installer Crashed (dup-of: 55019)" [Undecided,Confirmed] https://launchpad.net/bugs/56818
<ubot3> Malone bug 55019 in ubiquity "Edgy installer crashes when installing on VMWare" [Undecided,Fix released] https://launchpad.net/bugs/55019
<h00k> bug 568818
<ubot3> Malone bug 568818 in linux "Lucid memory leak, proprietary driver" [Undecided,New] https://launchpad.net/bugs/568818
<h00k> turns out I need sleep.
<h00k> In there, I see 'Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 free buffers remaining.'
<h00k> So, I guess we'll see what happens. Thanks for your time.
<amitk> ericm__: Yes things that appear in only one config also show up in common, That was something apw implemented
<amitk> ericm__: so to start a new flavour, it is best to copy the config of an existing flavour and the make changes
<apw> you can also put a complete config at the leaf and fdr genconfigs and the right thing will happen
<ikepanhc> apw: sorry missing some messages, you just talk about put the complete config on the leaf, do you mean put them on debian.xxx/configs/<arch>/config.<flavour>?
<apw> smb, so i assume you are back in your normal location?
<smb> apw, For the moment, yes
<apw> ikepanhc, yeah if you put a complete config there it will get merged in correctly
<ikepanhc> thanks a lot :)
<apw> generally not a good idea as you won't get the common overrides that way
<apw> so it needs thought
<amitk> apw: how so?
<apw> if you put a complete config in the leaf it will ensure the config as merged will generate exactly that config
<apw> so if you take a vendor defconfig it still won't have 'CONFIG_UBUNTU_NEEDS" things turned on 
<amitk> apw: starting from a vendor config is painful from the POV of ubuntu'ification
<amitk> vendor configs are very sparse
<cooloney> can I talk here
<amitk> I typically start from the closes in-tree config we have
<EricMiao> amitk, that's true, usually without most drivers, only necessary
<cooloney> perfect
<amitk> cooloney: no you can't :-p
<ikepanhc> cooloney: I heard you
<apw> indeed
<EricMiao> amitk, and those drivers are mostly built-in
<apw> just trying to make it clear what putting it there means
<apw> it means 'make the config exactly this' not 'base the config on this'
<amitk> so for omap, I picked mvl or fsl config, copied it to omap
<amitk> and then changed the fsl-specific to omap-specific stuff
<apw> amitk, what we should have done really is work out which items we must have and put those in a list
<apw> so that you could put a vendor config in there, shove the must have list at the bottom, and run updateconfigs
<apw> and have a half way sensible starting point
<amitk> apw: agreed. That is not very obvious (shoving at bottom overrides previous settings) but useful
<apw> there is now actually an debian.foo/config/OVERRIDES file now, which if you add things there they get forced into the config
<apw> (something like that need to check)
<amitk> apw: so all the enfore stuff should be there then
<apw> which lets you set a few options for all configs when doing updates
<apw> its not intended for long term use, but perhaps it should be
<apw> no it can't be as some are 'programatic' ... different per arch
<apw> though we could generate it from the enforce perhaps ... i'll add that to the config thinking list
<amitk> apw: to me, enforce is more intuitive. It warns me about missing stuff and forces me to fix my configs.
<amitk> OVERRIDES will do so behind my back
<amitk> we just need to populate enforce a bit better
<persia> I'd like to see some set of forced defaults that match the core userspace requirements (mountall, udev, installer, etc.): that would save a number of per-arch (or per-kernel) bugs we encounter.
<apw> amitk, OVERRIDES is not for use in the general case it is for the updates case
<apw> 'i want to change foo' 
<apw> if you put it in OVERRIDES and run updates configs it gets set everywhere
<apw> otherwise you have to add it to all leaf files and run update
<apw> which is harder
<amitk> apw: so you don't 'commit' changes to OVERRIDES?
<EricMiao> apw, so it's actually something common to all flavors?
<apw> persia, if people can tell us those linkages we have a way to record them
<EricMiao> or enforced to all flavors
<apw> amitk, right its purley a convienience for doing global changes, and is used by the mainline builds for that
<amitk> persia: we have an 'enforce' script now, that checks for some of these settings. We're populating them as we find more stuff
<apw> i use it when i do rebases for example
<amitk> understood
<persia> apw: Heh, well understood.  I'll see if I can get a partial list.  Too many folks seem to assume the i386/amd64 configs apply everywhere.
<apw> EricMiao, its designed to let it be easy to override a setting to something when we need to change it, nothing more it should not have any content on commit ever
<apw> persia, yep
<apw> but yes the config enforcer is for exactly this.  it contains the list of options we must have, and human commentry as to WHY so that we don't lose them over time
 * amitk suspects we need a README in our buildsystem now
<apw> amitk, yeah i suspect so
<amitk> apw: to your paper notes
<amitk> :)
<apw> heh they are all on the sprint wiki now
<apw> i'll add that too
<amitk> http://paste.ubuntu.com/420890/ <--- another enforce apw
<persia> I'm thinking http://launchpadlibrarian.net/45034888/buildlog_ubuntu-lucid-powerpc.qemu-kvm_0.12.3+noroms-0ubuntu8_FAILEDTOBUILD.txt.gz might be a kernel config/patch issue.  Anyone able to confirm that it is/isn't? (missing prototype: when I search for the prototype, I get mail archives with kernel patches)
<apw> amitk, yes i was literally just opening an editor to add that
<apw> please push it to kernel-team@ and i'll get it applied
<apw> persia, depends if that is a kernel function ... /me looks
<apw> persia, does that build for other arches?
<persia> Yep.
<persia> Works on i386/amd64/armel
<persia> Note that there might be a missing patch that never got upstream: I just wanted someone more familiar to confirm if it was a kernel thing.
<apw> does powerpc even spport kvm
<persia> Uhh, sometimes.
<persia> Depends on the chip.  440s and 970s work fine.
<persia> real POWER processors have something else, and kvm upstream doesn't target those.
<persia> And qemu works on a variety of stuff even when KVM isn't available.
<apw> kvm_arch_handle_exit doesn't seem to be a kernel thing at all
<apw> so i assume it is a local arch specific thing which is missing
<persia> Then just false-positive based on mail-threads.
<persia> Thanks.  I'll go hunt it somewhere else.
<apw> i suspect you should find it defined in the package for other arches
<apw> smb, i am seeing people complaining about sd cards as root and not working on reboot, do you see that on your card based installs?
<smb> apw, That was one of the things I wanted to test today, after having upgraded to the latest code base (including the official kernel)
<smb> apw, Oh wait. Slightly different problem. Ok, I can check that too. But I think that has worked
<apw> sounds good
<apw> smb, yesterday i put together some code to upload pre-proposed kernels automatically from the tree tips ... enabled for lucid only right now
<smb> apw, Ah, thats why there are these uploads I noticed
<apw> yeah ... the ones with the huge preNNNN numbers are the automated ones
<apw> well 'one' so far
<smb> Right, there was another one with a more manual number.
<apw> yeah that was me, starting to do them manually
<apw> as i decided we would have caught the EC: issue if there was a lucid pre-proposed 
<apw> so i think its worth having and worth being automatic if we can
<apw> hense the experiment
<smb> We definitely want such a thing soon / after release
<apw> well i have lucid doing it 'now'
<apw> basically if the tip is UNRELEASED and it changes, it gets uploaded
<apw> i assume if its is released that its in the release pocket
 * apw wakes smb up
<soren> persia: The problem isn't the missing prototype.
<soren> persia: That's just a warning.
<persia> soren: Ah, but ->-server :)
<amitk> EricMiao: was the kexec fix a backport from 2.6.33?
<EricMiao> amitk, I think so - some of them are already upstreamed
<amitk> anybody know why I don't need fakeroot to build a kernel anymore in lucid?
<amitk> I get the error shown here: http://www.mail-archive.com/debian-glibc@lists.debian.org/msg37588.html
<amitk> if I do use fakeroot
<apw> amitk, i do all my kernel builds with fakeroot
<apw>                         fakeroot debian/rules clean &&
<apw>                         fakeroot debian/rules "$build" ||
<amitk> i wonder if it has to do with my cross-compiles then?
<amitk> CROSS_COMPILE=arm-none-linux-gnueabi- debian/rules binary-omap
<persia> apw: Does `debuild -b` not just work for you?
<amitk> persia: debuild -b will build _everything_. debian/rules are useful to do only a single flavour build
<persia> Ah, $build is a flavour.  Yeah, that makes sense :)
<apw> persia, right else it takes several hours to make a kernel, nightmare
<persia> Yeah.
<AStachowski> Hi guys. Just wanted to thank you for your hints for preparing a custom ppa kernel. https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
 * AStachowski was to stupid to read properly (bash debian/scripts/misc/getabis)
<tgardner> smb, 544254 has been maked fix released
<smb> tgardner, Oh, hm. Somehow I had the impression there were replies about still having problems but maybe I dreamt
<smb> tgardner, I must have been dreaming about that one. Well better that way.
<tgardner> smb, np
<achiang> so, i have two bugs that i think are SRU candidates for lucid.
<achiang> https://bugs.launchpad.net/oem-priority/+bug/532374
<ubot3> Malone bug 532374 in oem-priority "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,In progress] 
<achiang> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/566149
<ubot3> Malone bug 566149 in linux "Lucid: No USB after resume on Thinkpad X201, T410, T510, W510" [Undecided,New] 
<achiang> the second one has a patch that has been accepted by maintainer ; not yet pushed to linus but will be soon ; and already got a verbal ack from gregkh about taking it into -stable
<achiang> should i wait until landing in -stable before sending a patch to ubuntu-kernel-list?
<achiang> and the first one is likely in the same boat, but the maintainer is AWOL for a bit. :-/
<smb> achiang, When they land in stable (and I think I saw some) they will just get pulled from there
<achiang> smb: huh -- i was under the impression that even with -stable, we still cherry-picked from that tree
<achiang> iow, not everything in -stable goes directly into lucid?
<achiang> smb: is that incorrect?
<smb> achiang, yes
<smb> achiang, We will pull everything from stable in 
<achiang> smb: ok, so lucid is a superset of stable, thanks
<achiang> great, that helps me avoid SRU process. ;)
<smb> achiang, If you can, then have BugLink keywords referencing the LPs in them. This helps closing the right bugs automatically when those things come in via stable. ;-)
<achiang> smb: sorry, not fully following you. you mean BugLink in the upstream patch commit?
<smb> achiang, Yes, if you are the one sending a patch upstream, and you put it in, then its still visible when it comes back via stable. And also it allows people to look at associated bugs too
<achiang> smb: ok, too late for the 2nd one, but i can fix up the 1st one since i have to resubmit anyway
<smb> achiang, That would be cool. Its quite hard to keep the related bugs up to date otherwise. If you know about something and you see a mail about pulling stable in, I welcome any feedback about which patches might close what bugs, too. :)
<achiang> smb: will keep an eye out for the future. for this time, i just assigned both bugs to myself, and will close them when -stable gets pulled into lucid
<smb> achiang, Great, thanks.
<achiang> smb: BugLink keyword can appear anywhere in commit message? or does it need to be near the top?
<achiang> smb: i put it in column 0, but near the bottom of the commit log
<smb> achiang, It can be anywhere. It just must be at the start of a line
<achiang> great, thanks
<smb> Some place it right above the signed-of-by area
<achiang> yup, that's what i did
<smb> achiang, Thats perfect then
<apw> JFo, this bug #496093, am i right in thinking that the backport that the Ricardo's kernel has in it is a 2.6.31 backport?  would not that mean that an LBM install should be as good?
<ubot3> Malone bug 496093 in linux "[lucid] rt2860 frequently fails to connect to mixed mode WPA/WPA2 secured wireless networks" [Unknown,Confirmed] https://launchpad.net/bugs/496093
<tgardner> apw, bug #567016
<ubot3> Malone bug 567016 in linux "Wireless won't work on Lenovo Thinkpad T510" [Undecided,New] https://launchpad.net/bugs/567016
<apw> tgardner, good as long as we arn't looking at the same thing
<tgardner> apw, its a wretched vendor driver
 * apw sighs ... we get so panned for this crap, and its not even in our control
<tgardner> I'm gonna try and update it. lots of changes wince we incorporated it
<apw> is that an ubuntu driver or something?
<tgardner> apw, yep - ubuntu/rtl8192se
<apw> damn
<apw> tgardner, don't suppose you have one to test on
<tgardner> apw, no - that would be too easy
 * apw notes it is beer + 1 o'clock
<tgardner> apw, get lost. I'll see you Monday
<bjf> apw, what's that synchronization software you use to keep your home dirs in sync?
<apw> bjf, unison
<apw> tgardner, yeah see you then for some catchup beering
<bjf> apw, right! got to go figure that out
<apw> let me know when you are getting in
<tgardner> apw, I'll be at Millbank mid-afternoon
<apw> just in time :)
#ubuntu-kernel 2010-04-24
<phillw> hi folks, sorry to bother you, but could someone point me in the general direction to answer this?
<phillw> what's a scheduler and what's the difference between a CFQ one and a deadline i/o one?
#ubuntu-kernel 2010-04-25
<crazybyte> jjohansen, hello. may i bother you for a bit?
<dupondje> Is it possible to get somewhere an older kernel version? I suspect regression between -18 and now
<BenC> crimsun: ping, you around on this fine sunday evening?
#ubuntu-kernel 2011-04-18
<michaelh1> Hi there.  Natty 2.6.38-8 panics on me about once a day.  Where should I report this?
<RAOF> Launchpad.
<michaelh1> Yes, but where abouts?
<RAOF> And, I guess you've reported it here, too.  Does apport not pop up suggesting you file a bug?
<michaelh1> No, the machine dies and there's no apport dialog when it comes back up.
<RAOF> âubuntu-bug linuxâ is the requisite incantation for bug reporting if apport's not catching it.
<michaelh1> Ah, ta.  Running now...
<michaelh1> I have a photo of the panic backtrace.  How can I attach it?
<michaelh1> Ah, I see there's a browser window opening up...
<RAOF> Once the bug report is on launchpad, attach the file :)
<jk-> now we just need to "close the loop" and get LP to fix the bug
<RAOF> I'm all for creating a sentient bug-fixing launchpad.
<RAOF> Chop chop!
<lifeless> but does the strong anthropic principle apply?
<RAOF> That a sentient bug-fixing launchpad would only exist in a world filled with bugs?
<jk-> sentient? I propose RAOF gets the job of holding his hand over the big red killswitch in case LP goes all skynet on us
<RAOF> Any sufficiently advanced AI malevolent enough to require use of the killswitch is malevolent enough to remove the ability to press the killswitch :)
<jk-> your job with the killswitch includes monitoring the killswitch
<jk-> :D
 * apw yawns
<RAOF> Want some more bees to gargle? :)
<apw> i like my women like i like my coffee covered in bees
<apw> RAOF, hows things looking for release from your point of view
<RAOF> By and large, pretty good.
<apw> there are some bugs out there, even some nasty ones, but not a huge heap of them
<RAOF> There are some nouveau crazies, but for some reason laptop manufacturers like to put totally insane bioses on nvidia systems.
<RAOF> There's one big bug involving compiz freezing that I thought we'd fixed on Friday, but sadly not.
<apw> that is so helpful of them, you'd think that the nvidia would specify the bios really
<RAOF> It might be in the kernel (missing vblank events) or it might be in libx11.
<apw> hrm
<apw> which grphics?  or is it all of them?
<RAOF> intel!
<RAOF> No one uses it.  It's pretty obscure :)
<apw> yeah minor corner case
 * apw shakes head
<RAOF> Oh, and btrfs remains molasses-slow, but that's hardly news :/
<apw> yeah, that one has yet to live up to its billing, though that is the common case of all new filesystems
<apw> they are really quick until the data loss bugs are gone
<RAOF> Heh.
<apw> ext4 and ext3 went trhough being as fast as anything, but your data was on a knife edge
<RAOF> Which is a pity, because btrfs has some all sorts of awesome in it.  Once it's fast enough for regular use, I guess.
<apw> yeah, it has a nice model if it can ever be made performant
<apw> great for rollback and the like
<RAOF> Hot data migration for ssds would be nice, too.
<RAOF> And nice schroots and such.
<apw> so there doesn't seem to be anything for i915 at all in either 2.6.38.3 (which is pending for the first SRU) or in the stable queue
<RAOF> Yeah, I don't think there's anything anywhere for it.  I'm not yet sure it *is* an i915 bug.
<apw> today is our last window for an upload really, and right now there is nothing pending which warrents the risk of actually doing one as far as i can see
<apw> RAOF, ^^
<RAOF> apw: I concur.
 * smb waves to apw
<apw> smb, moin, hows you
<apw> smb, do we still use the cve bzr thingy?
<smb> apw, Good, just slow to get to work. :)
 * amitk read that as CVS bzr thingy and shivered...
<smb> apw, I guess we use the bzr branch but more on a manual approach
<apw> amitk, hehe
<apw> smb, ok so will update the branch then
<smb> apw, I must admit I have not done much cve lately. Too much time spent on other things
<apw> me also, just was updating the awsome tracker with some new cves was all
<smb> *sigh* there is always new
<smb> The cking is back. :) Was it next week when you are on vacation?
<cking> smb, no vacation as yet
<smb> Ah ok, saw it somewhere and was for some reason believing it would be this week
<smb> As this Fridays is a Good Friday. :-P
<cking> smb, yep, may take wednesday off - electrician is doing the final wiring 
<smb> cking, Good idea. Not good to have computers running while someone pokes around with a screwdriver
<smb> So You can move around Easter?
<cking> still got to decorate the office - got to wait 5 weeks for the plaster to dry before I can apply paint
<smb> 5 weeks!? That is so close to torture... :-P
<cking> smb, well it's dry-ish now, but if put modern paints on it now it the pain will trap in moisture forever
<smb> cking, Understandable, though it feels very hard to have an office place that is connected and all but you have to wait for some plaster to dry.
<Daviey> apw, Can you confirm that bug 747090 fix, will land in the next kernel upload?
<ubot2> Launchpad bug 747090 in linux "wrong return address sometimes pushed for INT in kvm (not qemu)" [High,Fix committed] https://launchpad.net/bugs/747090
<apw> yes that fix is committed and will be in the first SRU upload
<apw> Daviey, ^^
<Daviey> apw, ah, super - thanks!
<eagles0513875> what about bug 762496 what will happen if compiling the vanilla kernel fixes the issue
<ubot2> Launchpad bug 762496 in linux "atheros wifi cards cause kernel panic when connecting to wpa2 secured wifi networks" [Undecided,New] https://launchpad.net/bugs/762496
<apw> eagles0513875, if 2.6.38.3 fixes your issue then that is going to be released as the first sru for the kernel
<apw> which is normally 1-2 weeks after release
<eagles0513875> ok there were some patches released to fix that issue for 2.6.38.3 
<apw> eagles0513875, and have you tested that they fix your issue?
<eagles0513875> working on it as we speak
<apw> well thats good feedback if you can indicate which patches fixed the problem we can tag them and the bug will close out automatically when the SRU releases
<eagles0513875> apw: any chance to get it in before the first sru release 
<eagles0513875> as there are going to be tons of disgruntled people
<apw> very unlikely now, if this was raised a week ago before the freeze we might have gotten it in, though the fix was only available friday i believe
<eagles0513875> ya i was talking to someone about that friday as it has been plaguing me big time
<apw> that is the problem with people waiting till the last minute to test, its all too late to do anything about
<eagles0513875> no chance to file a freeze exception
<apw> unless someone in the kernel team happens to have the h/w we simply don't find out
<apw> the problem is timing, a kernel rebuild takes close to 24 hours, and it has to be done before 9am tommorrow
<apw> which is basically impossible now
<eagles0513875> ahh
<eagles0513875> 24 hrs O_o
<eagles0513875> im suprised canonical doesnt have a dedicated high end machine to cut down the kernel packaging and compilation time
<apw> and then we have to respin the installer etc
<apw> eagles0513875, there are no such things as high end armel boxes
<apw> which is why our freezes are loudly advertised, and pretty much hard
<apw> and why testing early is sooo important
<eagles0513875> then in that case whats the earliest one can get in on upgrading to the next dev release
<eagles0513875> that isnt part of the canonical staff
<apw> eagles0513875, from the moment the archive opens,
<eagles0513875> which is usually how long after
<eagles0513875> release
<apw> there is no special treatment for canonical staff
<apw> usually less than a week
<apw> but even testing the alphas would be good
<apw> those appear very early in the cycle
<eagles0513875> ya the problem for me is time atm :( 
<eagles0513875> apw: mind if i pm ya a sec
<apw> eagles0513875, yep, a problem for a lot of people, but it means you'll likely have to wait a couple of weeks longer than the rest to upgrade
<apw> eagles0513875, ok
<eagles0513875> im already on natty i just cant use the wifi at home
<apw> eagles0513875, you might want to test the kernel which is in the pre-proposed archive
<apw> https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<eagles0513875> i was gonna recompile as there are some default things which on a netbook i dont need 
<apw> that should be similar to the SRU kernel and contain the .3 fixes
<eagles0513875> :) will give that a shot. is it possible if that has the fixes to get that pushed today before release
<apw> that is simply built from the tip of our tree, that is what is committed for the next upload
<apw> i will discuss it, but i suspect we are unlikely to be uploading before release now
<eagles0513875> the biggest prevention you have here is disgruntled users
<eagles0513875> upon release
<apw> eagles0513875, i have to balance risk, known breakage for you and the (relativly) small number of atheros users against the risk of making any change which can affect all other users
<eagles0513875> true
<apw> as esentially any change now invalidates all of the testing we have done to now
<apw> now in theory its low risk, but ... non-zero and we have been bitten by just recompiling breaking things
<apw> i will try and get a specific kernel with those atheros patches today for you to test at least
<eagles0513875> im trying the preproposed as you mentioned above if that containes the 38.3 fixes
<eagles0513875> i dont think kde 4.6 is ready for prime time though im getting crashes left right and center
<apw> you are 64 bit yes ?
<eagles0513875> all im noticing right now somethign is seriously up with networking stack all of a sudden here :-/
<eagles0513875> yep
<eagles0513875> maverick 64bit is rock solid
<eagles0513875> is the pre proposed up or down?
<eagles0513875> i ran apt-get update and im getting an error no address associated with hostename
<apw> eagles0513875, was there when i looked just now
<eagles0513875> ok let me reboot im having some connectivity issues
<eagles0513875> now for the moment of testing truth
<eagles0513875> apw: what i did find funny in testing 
<eagles0513875> if i leave my wired network plugged in and then connect to wpa2 connection it doesnt kernel panic
<apw> eagles0513875, odd indeed
<eagles0513875> now knetworkmanager is crashing non stop for me
<eagles0513875> woohoo
<eagles0513875> apw: ill keep working on this later im off for lunch for now
<apw> eagles0513875, can you test http://people.canonical.com/~apw/lp762496-natty/ and report back
 * apw drops for a bit
<M_gerorge> hi.. i have written code to copy data from kernel to user space.. But its not showin the required output.. :(  code is on http://paste.ubuntu.com/595486/       ..... please suggest..
<fairuz> M_gerorge: hmm.. to copy from or to user space you should use write and read function
<fairuz> module_init will only be called once when you insert the module using insmod
<M_gerorge> fairuz: ok.. but i have written these copy_[to/from]_user functions in read and write but they are still not called..
<fairuz> you have to have a write and read function in kernel space too!
<fairuz> it's not magic :D
<M_gerorge> fairuz: :D.... but copy_to/from_user are inbuilt or not?
<M_gerorge> :p
<fairuz> M_gerorge: Yes, but how you will call it from user space?
<M_gerorge> fairuz: yes.. this is the basic which i am not getting. can you please tell me how can i explore about this more?
<fairuz> M_gerorge: For me, a simple module needs to have at least 4 functions
<fairuz> init, exit, write and read
<fairuz> hmm and also, open and release functions
<M_gerorge> fairuz:yes..  as i am running the scull driver example it is simply loaded and exited.. but how can i use the functions scull_read and scull_write?
<fairuz> You need to have a device nod
<M_gerorge> fairuz: is this the dev_t *dev?
<fairuz> M_gerorge: no.. something like /dev/mydevice
<fairuz> it's a file that you create with mknod
<M_gerorge> fairuz: ok .. i can do this.. then what to do next?..
<M_gerorge> :P
<fairuz> hmm.. wait, I give a link
<fairuz> http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C0
<fairuz> follow the tutorial here and come back if you encounter some problems :D
<M_gerorge> fairuz: thanks a lot and i used this tutorial also. but not get my answer.. :(
<M_gerorge> fairuz: in this the dev/memory is created
<M_gerorge> but how to use the memory_read and memory_write function?.. :(
<fairuz> Ok, I'll explain. (but remember that I'm not an expert myself and maybe it's a bit off course) :D
<M_gerorge> fairuz: it wil be my pleasure to be taught by you..:)
<fairuz> M_gerorge: Are you sure you followed the tutorial? I dont see any major number in your code
<M_gerorge> fairuz: yes.. actually thats is the normal code i wrote myself to use copy_functions
<M_gerorge> fairuz: can i paste the other codes? :p
<fairuz> to pastebin, sure :D
<M_gerorge> thanks.. let me do this
<M_gerorge> fairuz: please see http://paste.ubuntu.com/595492/
<fairuz> M_gerorge: if you are new to device drivers, I afraid that's maybe a little bit complicated?
<M_gerorge> fairuz: i will try my best to understand
<fairuz> M_gerorge: Can you follow the memory device driver tutorial I gave you?
<M_gerorge> fairuz: yes.. 
<fairuz> Come back to me if there are something that you don't understand
<M_gerorge> fairuz: i read it and understood it completely.. :p.. but it doesnt gave how to access the memory_read and memory_write functions.. :(..  while doing "echo -n abcdef >/dev/memory" and "cat...." these commands doesn't use these memory_read and write too... :(
<fairuz> of course it does :D
<fairuz> when you create a module, you associated a major number to it
<fairuz> let say 70
<M_gerorge> yes
<fairuz> And apart from that
<M_gerorge> yes
<fairuz> you need to create a device nod using the same major number
<M_gerorge> yes
<fairuz> let say /dev/mydev
<fairuz> so in your module, normally you specify the file operations struct
<M_gerorge> yes
<fairuz> e.g struct file_operations pmnc_fops = {
<fairuz> 	write:  pmnc_write,
<fairuz> 	open:	pmnc_open,
<fairuz> 	release:pmnc_release,
<fairuz> 	unlocked_ioctl: device_ioctl
<fairuz> };
<fairuz> so from user space
<fairuz> when you write to the device nod, it's like you call the write function in the module
<fairuz> e.g when you do echo "123" > /dev/mydev
<M_gerorge> fairuz: ok.... :p
<fairuz> in the backend, it will call the write function of your module with "123"'s pointer as it's buffer
<M_gerorge> ok..
<M_gerorge> yes
<M_gerorge> and same with the "
<M_gerorge> "cat ..." it calls the read function
<M_gerorge> :P
<fairuz> for read, it's the same principals
<fairuz> yes
<fairuz> that is in command line
<fairuz> but if you want to use it user space program
<M_gerorge> yes
<fairuz> you can open /dev/mydev like normal files
<fairuz> that use fread and fwrite functions
<M_gerorge> ok...
<M_gerorge> fairuz: now one issue i found that i added printk lines for debugging.. and they dont get printed.. 
<M_gerorge> so i concluded that these functions are not called.. :P
<fairuz> if you do dmesg | tail
<M_gerorge> yes
<fairuz> you will found them :D
<M_gerorge> means in "/var/log/message"
<M_gerorge> ?
<fairuz> or tail /var/log/messages
<M_gerorge> yes.. i dint find them in that.. :p
<M_gerorge> but i may be wrong.. i will check once more
<M_gerorge> fairuz: let me check once more this
<M_gerorge> printk commands
<fairuz> M_gerorge: ok
<fairuz> use pr_info instead
<fairuz> :D
<M_gerorge> ok. thanks.. :).. let me try
<M_gerorge> :P
<M_gerorge> fairuz: it's called and shown too..
<fairuz> nice
<M_gerorge> fairuz: thanks a lot for giving me your precious time... :p
<M_gerorge> fairuz: will come back to you if i will have more problems.. :D..
<M_gerorge> fairuz: good bye...
<JFo> rebooting for updates... brb
<tgardner> ogra_, linux-meta-ti-omap4 2.6.38.1208.7 accepted
<ogra_> tgardner, awesome !
<JFo> there may be an issue with either apport or ubuntu-but (I assume this is apport too?) as shown in bug 764341 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/764341
<ubot2> Launchpad bug 764341 in linux "WARNING: at /build/buildd/linux-2.6.38/net/sched/sch_generic.c:256 dev_watchdog+0x213/0x220()" [Medium,Incomplete]
<ubot2> Launchpad bug 764341 in linux "WARNING: at /build/buildd/linux-2.6.38/net/sched/sch_generic.c:256 dev_watchdog+0x213/0x220()" [Medium,Incomplete] https://launchpad.net/bugs/764341
<JFo> oh good, the bot is back :)
<cking> who feeds and tends the bot?
<charlie-tca> nobody, apparently. Thus it goes off on its own? ;-)
<JFo> tgardner, ever seen this? bug 764273
<ubot2> Launchpad bug 764273 in linux "WARNING: at /build/buildd/linux-2.6.38/ubuntu/aufs/plink.c:450 au_plink_put 0x4c/0xa0 aufs " [Undecided,New] https://launchpad.net/bugs/764273
<tgardner> JFo, I'm wondering why aufs is even loaded?
<JFo> *shrug
<JFo> unless he needs it for whatever he is building (mozilla maintainer)
<JFo> I confess I know next to nothing about aufs
<JFo> tgardner,: <JFo> micahg, that plink error you reported against the kernel... it happens every time the chroot is destroyed?<micahg> JFo: yes, but I think it might be related to being in /dev/shm
<tgardner> JFo, well, that makes two of us. apw is a bit more familiar with it.
<JFo> heh
<tgardner> JFo, he's not even running our bits: aufs 2.1-standalone.tree-38-rcN-20110207
<JFo> hmmm
<tgardner> JFo, the file that the WARNING is coming from is only 396 lines in our version
<JFo> tgardner, <micahg> JFo: well, jdstrand added a way to use sbuild in /dev/shm, so I thought I'd try it
<JFo> he says he is using the latest kernel: <micahg> JFo: 2.6.38-8.42
<jdstrand> uhh, I certainly am not using any other code. all I do is put the sbuild overlay in /dev/shm somewhere
<JFo> but where would he have gotten that aufs?
<JFo> jdstrand, I think the aufs may be the issue
<JFo> but no more than I know... that is like saying the stars are made of really hot cheese
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 (Kernel is Frozen) || Ubuntu Kernel Team Meeting - April-19 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw_> eagles0513875: did that kernel work?
<apw_> bah got bounced
<JFo> dang, where has the day gone?
<JFo> <-lunch
<apw_> it's hiding in the shadowes
<tgardner> apw: I was just checking our aufs bits. The SHA1 in the BOM doesn't appear to be valid in the upstream repo.
<apw_> will cjeck it out shortly, there is an algo, and two repos to che k
 * smb imagines apw_ trying to hit the softkeys while humping along...
<cking> the mind boggles
<apw_> yep not as easy as it could be, br in front of a stationary one shortly
<tgardner> apw: are you someplace weird?
<cking> he was in France earlier
<tgardner> cking, oh, a train?
<smb> I guess a british trains counts as weird...
<apw_> on a train for the next half or so
<tgardner> apw: ah, well it can wait.
<apw_> yep woll look shortly 
 * tgardner --> lunch
<eagles0513875> apw: hey quick question where can i download a newer version of knetwork manager
 * bjf -> lunch
<apw> JFo, that bug is mean to be removed from our kernel
<apw> (as in the message)
<JFo> apw, which?
<apw> JFo, the plink one
<apw> unless i messed up the kernel update last time
<JFo> ok, anything in particular I need to do to it? 
<JFo> or wait and see?
<apw> JFo, oh its a different one, hrm
<JFo> :)
<JFo> I'm on a full pot of coffee it could have been anyth.... OMG pwnies!
<apw> JFo, heh i bet
<JFo> :)
 * jjohansen -> lunch
<JFo> the sad part is, I didn't realize I drank the whole thing until I went for another refill :-/
<apw> ok tgardner this version of aufs seems to be the one in the tree i have; it seems to be a few commits behind which i can look over for sru but it does correspond
<tgardner> apw: you're looking at bug #764273 ?
<ubot2> Launchpad bug 764273 in linux "WARNING: at /build/buildd/linux-2.6.38/ubuntu/aufs/plink.c:450 au_plink_put 0x4c/0xa0 aufs " [Medium,Incomplete] https://launchpad.net/bugs/764273
<apw> well i was answering your previous comment that the BOM commit id didn't exist
<apw> (which i contend it does) and that WARN_ON seems to be on that line in the natty source
<tgardner> apw: hmm, then one of us is doing drugs.
<apw> COMMIT: 65835da20b77c98fb538c9114fc31f5de1328230
<apw> is in the BOM
<tgardner> apw: agreed.
<tgardner> rtg@lochsa:~/proj/linux/aufs2-standalone$ git log -p 65835da20b77c98fb538c9114fc31f5de1328230
<tgardner> fatal: bad object 65835da20b77c98fb538c9114fc31f5de1328230
<apw> commit 65835da20b77c98fb538c9114fc31f5de1328230
<apw> Author: J. R. Okajima <hooanon05@yahoo.co.jp>
<apw> Date:   Thu Feb 3 04:46:48 2011 +0900
<apw>     aufs: possible bugfix, exclude the freeing file
<apw> ahh yes, its not a direct commit id in that tree
<apw> its the commit id as listed in the Changelog
<apw> which is the id in the aufs main tree that the commit in the standalone tree was made from
<tgardner> apw: ok, I'll take your word for it. the real issue is that I don't think he's running _our_ version of aufs. 'WARNING: at /build/buildd/linux-2.6.38/ubuntu/aufs/plink.c:450 au_plink_put+0x4c/0xa0 [aufs]()' references a line number that doesn't exist.
<apw> tgardner, the problem is that the primary tree is increadibly slow
<apw> tgardner, in my tree here this is the plink.c:450 which look plausable
<apw>         WARN(verbose && !list_empty(plink_list), "pseudo-link is not flushed");
<apw> and the panic information looks like its 8.42
<tgardner> apw: ya know, I might have been on the wrong branch. shit.
<apw> heh happens to the best of us
<cking> more coffee required methinks
<apw> maybe soo indeed
<JFo> none for me thanks... 
 * JFo has the jitters
 * apw slaps JFo ... 
 * JFo jumps 10 feet in the air
<JFo> :)
<apw> now that i want on youtube
<JFo> heh
<cking> dear bisected kernel, please don't misbehave, it makes bisecting very difficult...
<apw> cking, i hate those days
<cking> just when you think you've cornered it, it jumps out of reach
<JFo> do we care about bug 763656 or should that go to skype?
<ubot2> Launchpad bug 763656 in linux "general protection fault: 0000 [#1] SMP " [Undecided,New] https://launchpad.net/bugs/763656
<JFo> since they were installing skype when it happened
<apw> well there is little we can actually do about it
<JFo> I thought that might be the case
 * JFo needs a bit of a break: bbiab
<bjf> JFo, i've submitted a merge request for apport changes which remove all the user-input from the linux source package-hooks
<bjf> pgraner, ^
<bjf> JFo, pgraner bug #765178
<ubot2> Launchpad bug 765178 in apport "remove user-input questions from linux source package hooks" [Undecided,New] https://launchpad.net/bugs/765178
<pgraner> bjf, ack
<bjf> pgraner, by the way *I HATE BZR*
<pgraner> bjf, :-D
<JFo> ok
#ubuntu-kernel 2011-04-19
<bryceh> apw, you about by chance?
<bryceh> apw, ok will email
<apw> cking, hey morning ... you got any aarandale h/w with external monitor ports ?
<cking> apw, lemme check my inventory
 * cking rummages around
<cking> apw, no, afraid not
<apw> cking, shame, ok ... i wonder who if anyone does these days, i am hearing reports that external monitors are not working on those chipsets
<cking> hrm, best ping the guys in lexington
<apw> cking, yep, will do, you are just a little better aligned timewise
<cking> unfortunately I've sent quite a bit of kit back lately
<apw> that or drown in the stuff
<apw> i sh
<apw> i should have got you to send me a sample of aarrandale, and a sample of ironlake
 * apw goes get some breaky
<cking> apw, perhaps you should ask lexington to ship you some kit
<apw> cking, might be a plan
<eagles0513875_> hey apw  :) got ur msg with an updated kernel going to try and confirm sru kernel update fixes the issue which i hope it does. atm dealing with a crashing netowork manager which seems lots of people are having that issue as well
<apw> ta
<eagles0513875_> ?
<apw> ta == thanks
<eagles0513875_> ahh  ok guessing ur up in the uk apw 
<apw> based in the uk yes
<eagles0513875_> nice nice :) 
<eagles0513875_> isnt canonical up there as well
<apw> eagles0513875_, sort of, canonical is mostly distributed, but there is an office in the uk
<eagles0513875_> im wondering if they would support a game distro version of ubuntu
<eagles0513875_> honestly doubt it though
<apw> not really sure what support would mean, there are a number of vairiants, kubtuntu, ubuntustudio etc who at least get CDs spun etc
<eagles0513875_> ya but those people that i have spoken to why not create a meta package
<eagles0513875_> the problem wiht meta package is the amount of stuff that is still avialable in the repos 
<eagles0513875_> i want to provide repos with specific software geared towards this particular market
<apw> why would you want to stop people also installing other things?
<eagles0513875_> to help them save time hunting for what they are looking for
<amitk> eagles0513875_: while you're welcome to do that and provide your own repos and so forth that mirror only certain packages, why restrict your potential users?
<eagles0513875_> amitk: im trying ot target a niche market which has yet to be exploited in the linux world
<apw> eagles0513875_, making it easy to find the s/w you want/need is good, restricting me so its hard to use the machine for other things seems wrong
<amitk> yeah, I wouldn't use such a software system, but then I suspect we don't fall into eagles0513875_ 's target audience :)
<eagles0513875_> humm 
<eagles0513875_> amitk: what other software would you install besides games on a game distro 
<apw> whatever i wanted to
<eagles0513875_> you got me thinking if i do anythign i might rework the repositories
<apw> are you trying to make a ps3, else let me use my machine for what i want to 
<amitk> eagles0513875_: that is like asking the original WRTG54 router hackers what they could want besides the buggy Linksys firmware :)
<eagles0513875_> hehe
<apw> amitk, nicly put
<eagles0513875_> amitk:  apw  im still in the brain storming stage
<apw> i feel erring on the side of openness will win you more adopters
<apw> and likely should mean that you cna leverage the existing infrastructure at low effort from yourself
<apw> win all round
<eagles0513875_> ya i see where your coming from 
<apw> behaving like m$ will not win you friends
<eagles0513875_> i guess i can create non gaming repos which users can enable if they want to install other software 
<eagles0513875_> or just enable all my repos and leave a very basic desktop environment
<eagles0513875_> im still in brain storm stage atm 
<eagles0513875_> apw: guessing best place ot start would be with the installer and kernel?
 * apw is sligntly unsure where you think you are going
<apw> why is a dekstop env no good for gaming, works for windows
<eagles0513875_> im not saying its not but where should one start putting this together 
<eagles0513875_> at the kernel installer level 
<eagles0513875_> or desktop environment etc
<eagles0513875_> apologies i might not have made that very clear 
<apw> i would ask that question on #ubuntu-devel, i suspect you need to put together a seed for the collection you need
<apw> which i think is basically a big meta-package which pulls in all the things you definatly want, and the rest comes via dependancies
<amitk> eagles0513875_: start with ubuntu-server which is probably the minimum seed at present, uninstall the server bits, add desktop bits you need. That should be the starting point for your own seed
<Kano> hi, why is no rfcom in .39 kernel?
<Kano> would be good if rc4 has it enabled...
<apw> Kano, no idea
<Kano> it was in .38
<apw> Kano, what driver are you missing
<apw> and from what kernel
<Kano> .39 mainline, RFCOMM
<Kano> for bt connections
<Kano> maybe more are missing, but this is definitely not there..
<apw> the config for it is turned on, which driver .ko is missng
<Kano> well i wanted to modprobe rfcomm, it is not there
<Kano> it is not in the final config too
<Kano> http://www.gentoo.de/doc/de/bluetooth-guide.xml
<Kano> grep -i rfcomm /boot/config-2.6.39-*
<Kano> no output
<Kano> i could not even connect a bt mouse
<Kano> but thats noother module most likely
<apw> Kano, bluetooth is known broken in lots of ways in early 39-rc
<Kano> because it is not even enabled?
<apw> no cause it is broken
<Kano> without a module it can not work
<apw> not in our builds, in generall
<Kano> i use your build
<Kano> the mainline ones
<apw> and those come with no guarentees even to boot
<Kano> they boot, they are good for benchmarking oss drivers, but bt modules are missing
<apw> ogasawara, are you building oneric anywhere?
<apw> Kano, might be fixed for -rc4, won't know till it builds
<Kano> ok
<ogasawara> apw: I'm not building oneiric anywhere, I didn't plan to until the archive officially opened.  Anyone wanting to run an oneiric kernel at this point has to be savy enough to build on their own.
<tgardner> ogasawara, we could be uploading as a daily build into the natty pocket for now
<ogasawara> tgardner: to the kernel-ppa?
<tgardner> ogasawara, I suppose. it doesn't make a lot of difference. the archive will be open in a few weeks anyways.
<ogasawara> tgardner: I assumed that would then override the tip builds of the current natty tree.  meh, I'm indifferent as I don't think there are a heck of a lot of oneiric consumers anyways.
<ogasawara> for the ones that do exist, I've been building them a kernel when asked.  so far I've only had 1 request.
<tgardner> ogasawara, I was gonna start trying out on some of my servers, but I can do the builds myself. are you about to rebase for -rc4 ?
<ogasawara> tgardner: yep, gonna do the rebase right now
<ogasawara> tgardner: I'll ping ya when I've got it pushed
<tgardner> ogasawara, thanks
<apw> ogasawara, the tip builds are in pre-proposed
<apw> the kernel-ppa/ppa only has natty backports to lucid
<apw> i think tgardner did natty in there before upload to the archive
<ogasawara> apw: ah, that'd make sense then.  I'll upload the -rc4 rebase to there then.
<apw> you get to find out that none of the d-i stuff works and fix it before the archive chews on it :)
<ogasawara> that'll be fun
<tgardner> bjf, sconklin-gone: linux-lts-backport-maverick has been baking in -proposed for 4 weeks. any chance of getting it promoted?
<tgardner> apw, https://launchpad.net/ubuntu/+source/gcc-4.5 uploaded 24 hours ago. is this gonna scrog dkms packages?
<apw> tgardner, i think it might, let me see if any are complete and then i can test
<apw> its about time we knew for sure if dkms cares
<tgardner> apw, yeah, I've never been sure just how naive the version test is.
<apw>   * For Linaro based builds, do not turn on -fshrink-wrap by default on armel
<apw> so that means that new code that shat all over us is now disabled for all architectures
<apw> wtf
<tgardner> sounds like a failed experiment
<apw> tgardner, grrr
<tgardner> apw, good thing its close to beer thirty for you lest you pop  a gasket :)
<cking> what does -shrink-wrap do - it's some kind of ARM function epilogue optimisation isn't it?
<sforshee> can someone accept my nominations on bug 745304 ?
<ubot2> Launchpad bug 745304 in linux "Graphics corruption after hibernate with Intel GMA 3150 chipset" [Medium,In progress] https://launchpad.net/bugs/745304
<tgardner> sforshee, done
<sforshee> tgardner, thanks!
<tgardner> what library does one link against for a cc program, e.g., g++ evil-clock-test.cc -lc -o evil-clock-test
<apw> tgardner, -lc is the the standard c lib, you also get impliciltly linked against libgcc
<tgardner> apw, here we go: g++ evil-clock-test.cc -lc -lpthread -lrt -o evil-clock-test
<apw> smb, can you remember what used to go wrong, and thus who complained when the compilers in -security and -updates didn't match and we shoved kernels out ?
<apw> i rememeber bugs filed for it in the past
 * apw notes that dkms doesn't seem to care in my experience
<apw> <apw> smb, can you remember what used to go wrong, and thus who complained when the compilers in -security and -updates didn't match and we shoved kernels out ?
<apw> <apw> i rememeber bugs filed for it in the past
<tgardner> apw, you were able to load a dkms created module?
<apw> tgardner, i believe so yes, just confirming i have the right compiler
<ogasawara> tgardner: oneiric -rc4 rebase pushed.  my test builds are finishing up but look good so far.
<tgardner> ogasawara, what did you do about the kexec patch ?
<ogasawara> tgardner: I dropped it, an official fix was in -rc4
<tgardner> ogasawara, good, thats pretty much what I did though I didn't really research it much
<eagles0513875> hey apw
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<apw> eagles0513875, yes
<eagles0513875> still havent tested yet waiting on network manager fix :( 
<apw> tgardner, did i see you installing vmware recently?  how does that carry its kernel modules (if any)
<tgardner> apw, builds 'em on the fly
<apw> tgardner, do you have that setup on a natty machine, wonder if we can test if that cares
<tgardner> apw, I don't. Its a lucid host. lemme think about what I might test it on.
<tgardner> bjf, did you ever get any feedback from the LP dudes on what happened to bug emails ?
<bjf> tgardner, i've not raised the issue with them
 * ogasawara back in 20
<tgardner> bjf, ok, I'm gonna tilt at the windmill.
<bjf> where at ?
<tgardner> that windmill*
<bjf> email or irc ?
<jjohansen> apw, tgardner: I have vmware here, I can test on natty
<tgardner> I'll get on their irc channel.
<tgardner> jjohansen, its the compiler version that apw wants tested. what happens to vmware modules after the compiler has been updated, but the kernel hasn't
<bjf> tgardner, they've been pretty responsive on #launchpad
<tgardner> bjf, a'int nobody there. do they hang o some other channel?
<jjohansen> tgardner: ok
<bjf> tgardner, on freenode
<tgardner> jjohansen, we're wanting to make sure vmware can load its modules after having been compiled with aq different compiler version then the kernel.
<tgardner> bjf, ah, thats more like it
<jjohansen> tgardner: I have a maverick kernel on a natty box, I can test against that kernel
<tgardner> jjohansen, I don't think that'll trigger the scenario we're worried about.
<jjohansen> tgardner: hrmm, okay.  I also have earlier natty kernels I can test again
<apw> yeah an older kernel  whcih was built with a different comp should show the issue if any
<tgardner> jjohansen, the version skew I'm worried about is because the natty kernel thats going out in the release was built with gcc 4.5.2-8ubuntu3, but the version of the compiler in the archive will be 4.5.2-8ubuntu4. will vmware recompile actually be able to load their modules given the version skew.
<jjohansen> tgardner: ah, got it.  Okay will test that one
<sconklin> smb: would you like the lucid ec2 package in our PPA copied to -proposed?
<smb> sconklin, yes please! :)
 * smb thought he had written some mail to the sru-list about that...
<sconklin> tgardner: pitti says he's holding off copying the lts-backports-maverick package because there's been no feedback on the bug https://bugs.launchpad.net/ubuntu/+source/linux-lts-backport-maverick/+bug/737728
<ubot2> Launchpad bug 737728 in linux-meta-lts-backport-maverick "linux-lts-backport-maverick: 2.6.35-28.50~lucid1 -proposed tracker" [Undecided,Fix committed]
<bjf> tgardner, maybe you should light a fire under the QA mgr. ? :-P
<tgardner> sconklin, aren't the LTS backports a regular part of their test cycle ?
<bjf> tgardner, they are, but due to natty testing they have no cycles for stable
<sconklin> tgardner: -ENOCLUE
<tgardner> bjf, gotta be careful about hassling the Q/A manager. he's got a big stick.
<smb>  /o\
<tgardner> maybe some of that stuff will shake out this week.
<bjf> ogasawara, JFo I seem to recall there is a wiki page that tried to explain how to make changes to apport, do either of you remember such a page? (am i dreaming?)
<ogasawara> bjf: I vaguely remember, let me see if I can find it
<ogasawara> bjf: https://wiki.ubuntu.com/Apport this is what I remember
<tgardner> JFo, what are the URLs you use to report the latest new bugs?
<bjf> ogasawara, thanks, was thinking there was one that talked specifically about kernel package hooks
<ogasawara> bjf: hrm, I don't remember such a page but that doesn't mean it doesn't exist.  /me tried searching but didn't find anything
<bjf> ogasawara, thanks, i'll try to write one up
<apw> jjohansen, how did the vmware testing go?
<skaet> apw, ping?
<apw> pong
<skaet> am a bit concerned about subtle interactions from that recent compiler change.
<jjohansen> apw: I haven't been able to successfully build the modules yet.  They need to be patched, /me is trying to update vmware but not having much luck finding the account login yet
<apw> jjohansen, tgardner may have the info
<apw> skaet, well in theory its only affects armel
<apw> or are you saying you feel armel needs rebuilding
<jjohansen> apw: err its a personal account, /me just got in
<apw> ih dih
<apw> oh doh
<skaet> apw,  patch seems localized to armel.    Concern is on the rebuilding of kernel for armel.
<apw> skaet, do we have any information as to the nature of the failure?
<skaet> do you have access to that test that broke things before when they switched over, and are you convinced that that case will still work, with this new default.   I'm worrying about subtle implications of the prolog code not being where expected.
<tgardner> why don't we just avoid the 'noid and do a no-change upload?
<apw> all our breakage was due to bugs in the implementaiton which lead to it being switched back off for non-armel
<apw> cirtainly we could upload and rebuild, its 24 hours turn round
<apw> tgardner, i wonder if we would want to put anything in there with it, the ath9k patch or the bluetooth one which is worrying cnd
<tgardner> apw, neither of those patches are particularly risky.
<skaet> apw,  re armel default switch, don't know there will be a failure or not.   just a bit worried, about something breaking that will be very hard to track down with this change, so late in the release.
<tgardner> its up to you.
<apw> well the safest safest course is a no change rebuild, to get the latest compiler
<JFo> bjf, I remember the one ogasawara posted
 * JFo scrolls down
<apw> and if you have time in your schedule we can cirtainly do that
<bjf> JFo, thanks
<JFo> tgardner, you mean the incoming bugs numbers?
<JFo> or just new status bugs?
<apw> skaet, what do you think about pulling in some fixes
<tgardner> JFo, the new bugs in the last 24 hours, etc
<JFo> hmmm, I have been using the reports bjf wrote for that
<JFo> what I report is the change in the overall number
<tgardner> JFo, right, thats what I want.
<JFo> tgardner, I use https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=natty+kernel-natty&field.tags_combinator=ANY
<skaet> apw,  not thrilled,  but pragmatic.   What will improve, and what's the risk?   
<JFo> and change the tag per release
<JFo> then I do what we have currently versus what there was
<JFo> there isn't much to it
<JFo> is that what you wanted tgardner?
<tgardner> JFo, I think its bjf's report that I want.
<JFo> ok one sec...
<JFo> tgardner, http://people.canonical.com/~kernel/reports/1-day-new.html
<tgardner> JFo, ah, thanks.
<JFo> no problem
<smb> jjohansen, So I think it is done more or less. It even boots. I am thrilled. :)
<jjohansen> smb: nice
<sconklin> http://www.ndpsoftware.com/git-cheatsheet.html
 * JFo bookmarks
<JFo> that is pretty cool
<apw> skaet, ok there are a couple of fixes which we could consider
<apw> there is an ath9k panic which triggers on connecting to a WPA2 access point
<jjohansen> apw: I couldn't trigger it in my testing
<apw> there is a fix for some bluetooth devices which only work for 3s and then stop
<bjf> ##
<bjf> ## Kernel team meeting in 10 minutes
<bjf> ##
<jjohansen> apw: that is ath9k
<apw> jjohansen, ok so perhaps that one is not as wide spread and we can leave it till later
<jjohansen> apw, tgardner: vmware is running here now
<tgardner> jjohansen, and its fine with compiler version skew ?
<jjohansen> tgardner: actually haven't tested that, yet.  Had problems getting it running and had to update, do to compile failures
<jjohansen> tgardner: the 7.1.4 package didn't seem to compile the modules which means they existed for my current kernel
<jjohansen> that or I missed it compiling them
<tgardner> jjohansen, I think you just missed them  getting compiled. I assume you installed VMware from scratch?
<jjohansen> tgardner: yep fresh install
<jjohansen> I am looking in its logs now
<jjohansen> tgardner: so it built them
<jjohansen> so it is working
<anonymity> hello
<tgardner> jjohansen, right. so the next step is to make sure you've booted the kernel from the archive, and that gcc is updated to the next version beyond what was used to build the kernel. then remove and reinstall VMware.
<jjohansen> apw: re ath9k yeah I think its safe to leave it to later
<jjohansen> tgardner: is there a version beyound gcc-4.5 4.5.2-8ubuntu4
<tgardner> jjohansen, thats the version that was uplaoded 28 hours ago.
<tgardner> jjohansen, /proc/version should have  gcc-4.5 4.5.2-8ubuntu3 for the archive kernel
<bjf> JFo, just noticed you have a workitem "update apport-hooks verbage" which is POSTPONED, does the work i did on apprt constitute a DONE for that ?
<JFo> indeed, I put it postponed pending the outcome of that
<JFo> is that bug solved?
<jjohansen> tgardner: yep it does.  vmware built modules and is running with
<jjohansen> Linux version 2.6.38-8-generic (buildd@allspice) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011
<jjohansen> gcc-4.5        4.5.2-8ubuntu4
<jjohansen> so the skew doesn't seem to be a problem
<tgardner> jjohansen, hmm. Its insmod that does the version comparison I think. Guess I'll have to look in the source to see how it does it.
<cking> bjf, that meeting was rather swift today
<JFo> bjf, do you have that apport bug number handy?
<bjf> JFo, that merge has been accepted and pitti uploaded a apport package with the change in it so i think you can mark it done
 * JFo can't seem to find it 
<JFo> sweet
<JFo> will do
<tgardner> cking, so swift that I completely missed it.
<cking> just way too efficient
<JFo> bjf, blueprint adjusted
 * smb waits until the instant meeting notes are available before the meeting
<JFo> heh
<JFo> going to step away for a bit and eat something... back soon
* bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 (Kernel is Frozen) || Ubuntu Kernel Team Meeting - April-26 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<apw> bjf, sorry was so terse on the meeting, was on the phone to kate about the compiler change
<bjf> apw, np, was bugging me more that you were taking so long :-P
<apw> i know, typing is so slow
 * tgardner --> lunch
 * apw drops for an hour-ish ... will be back to do the upload -- pending the decision
 * cking --> back later
<skaet> apw,  hold off on doing the upload to rebuild.  We'll go with the kernel we have for now unless we find a specific bug.   Most of the ecosystem is already known to work with this kernel.   We've been existing with some applications compiled with the flag, and some without for quite a while. 
<Kano32> apw: the only diff is CONFIG_HIBERNATE_CALLBACKS=y with rc4 kernel
<Kano32> still no bt
<JFo> ogasawara, want to start on these release team bugs?
<ogasawara> JFo: sure
<JFo> I'm still going through to weed out the ones we don't have to look at
<JFo> want to mumble?
<ogasawara> sure
<JFo> https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/634487
<ubot2> Launchpad bug 634487 in linux "t1.micro instance hangs when installing java" [High,Confirmed]
<tgardner> JFo, I asked upstream whats going on with the dev_watchdog timeout on natty. there are a couple hundred dups as far as I can tell.
<JFo> yeah, tons
<JFo> any idea what is causing it?
<tgardner> JFo, not yet
<JFo> ok, thanks for the head's up
<JFo> :)
<apw> skaet, ok will do
<skaet> apw,  or not do, in this case actually.  ;)
<apw> skaet, ok will not do :)
<JFo> ogasawara, ok, I only have a handfull I'll follow up on tomorrow
<ogasawara> JFo: ack
<JFo> so bjf I have about 355 bug mails in the last 24 hrs
<bjf> JFo, i have 33
<JFo> hmmmm
<bjf> JFo, only one of them is from a "NEW" bug
<JFo> interesting
<JFo> I have no clue what could have changed
<JFo> I see at least 50 NEW bugs
<bjf> that's what i'd expect to see also
<JFo> plus a metric ton of updates
<JFo> frankly, I'm baffled
<ogasawara> JFo: not that I know what you guys are talking about, but I see you're subscribed to get bugmail for every bug against the linux kernel package, I don't see bjf subscribed though
<bjf> ogasawara, am i not via the canonical-kernel-team ?
<JFo> well, that is likely it
<ogasawara> bjf: I don't think the canonical-kernel-team is subscribed
<JFo> bjf, I don't think the kernel team gets ALL bug mail
<ogasawara> bjf: so you wouldn't inherit a subscription
<JFo> just the ones the team is subbed ot assigned
<JFo> or*
<bjf> ogasawara, but then I don't understand why i'm getting the bug email that i am getting
<ogasawara> bjf: likely a combo of bugs being assigned to the canonical-kernel-team, bug's which you've specifically subscribed to, or bugs which your a member of a team which is subscribed to the bug
<ogasawara> bjf: https://launchpad.net/ubuntu/+source/linux/+subscribe
<ogasawara> bjf: ^^ if you want to see all changes to public bugs against the linux package
<bjf> ogasawara, sure, i could do that, however what tgardner and i have been talking about is that recently our bug mail has dropped by a great deal with no action on our part
<bjf> ogasawara, and we are wondering why
<ogasawara> bjf: hrm, no idea there
<bjf> ogasawara, is it because the canonical-kernel-team was subscribed to all linux email and it no longer is, or is that some other reason... we just don't know
<bjf> bug 625364
<ubot2> Launchpad bug 625364 in pm-utils "lenovo/thinkpad R500/T6x/T400[s]/T500/W500/W700/X60/X200 suspend fails" [Undecided,Confirmed] https://launchpad.net/bugs/625364
<ogasawara> bjf: I don't think the ckt was ever subscribed to get all linux bug mail, so I think it's some other reason
<bjf> i got the last comment from jfo on that bug, but I'm still trying to figure out why
<JFo> likely it was because ckt was assigned?
 * JFo guesses
<bjf> ah brad->canonical kernel team->ubuntu bug control->ubuntu bugs
<tgardner> ogasawara, I think the most telling change in behavior is that I've stopped getting project email.
<bjf> so by that trail, anything that "Canonical Kernel Team", "Ubuntu Bug Control" or "Ubuntu Bugs" is subscribed to, i should be getting email from
<bjf> that would seem like a few bugs
 * bjf believes that ogasawara is now sorry she said anything
<ogasawara> heh
 * ogasawara is actually wondering if that is true, ie ckt is indirectly subscribed to all ubuntu bugs?
 * JFo has hidden
<JFo> :)
<bjf> Canonical Kernel Team is a member of ubuntu-bugcontrol
<bjf> Ubuntu Bug Control is a member of Ubuntu Bugs
<tgardner> bjf, the ubuntu-bugs project page says you should be subscribed to https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs if you wanna see them all.
<tgardner> bjf, maybe bdmurray could answer some of these questions.
<bjf> tgardner, so being a member of a team does not automatically get you all the email for bugs that team is subscribed to
<tgardner> bjf, you find a reference for that somewhere?
<bjf> tgardner, no, just extrapolating from the comments on the Ubuntu Bugs team page
<bjf> tgardner, it's not what I expected, that's for sure
<tgardner> bjf, so, does that mean you have to subscribe to every team's mailing list?
<bjf> tgardner, that just doesn't make sense
<tgardner> bjf, yeah, I don't want to be on the Ubuntu Bug Control team list, most of which isn't relevant to me.
<bdmurray> Is there a question I can answer?
<bjf> tgardner, i have the attention of lifeless on #launchpad
<tgardner> bdmurray, bjf and I were just wondering why the volume of email has dropped so drastically in the last couple of weeks.
<bdmurray> tgardner: and you are complaining? ;-)  the thing that would probably help the most is knowing a bug you aren't getting email for and think you should be
<tgardner> bdmurray, any bugs against the linux source package for example. I _used_ to get them because I'm in the canonical-kernel-team which is indirectly a member of a bunch of other teams.
<bjf> tgardner, is bug 759176 an example ? (it's private but it had a comment added just yesterday)
<bjf> tgardner, we are a subteam of one of the teams that is subscribed
<tgardner> bjf, yep, I never received anything about it
<bjf> bdmurray, ^
<bdmurray> IIRC kernel-bugs used to be subscribed to all linux bug reports and had the mailing list set to kernel-bugs@lists.ubuntu.com.  However, this is not what is currently set.
<bdmurray> It looks like it changed around 11/2010.
<bjf> tgardner, lifeless is asking me to file a bug against launchpad and he will have someone look at it
<tgardner> bjf, yep, been lurking
<bjf> tgardner, cool
<tgardner> bjf, I'm EOD, catch you tomorrow.
<bjf> tgardner, l8r
<bdmurray> bjf: I can't see that sample bug
<bjf> bdmurray, i'll subscribe you if you like
<bdmurray> bjf: when did this slow down happen?
<bjf> bdmurray, approx. 2 weeks ago
<bdmurray> bjf: do you have a bug mail from 2 weeks ago I could look at?
<bjf> bdmurray, i'll look but I keep my bug email pretty much cleaned up, it kind of gets out of hand if I don't
 * ogasawara back on later
<bjf> bdmurray, i found one and have forwarded the email to you
<pmcenery> Any chance of this fix making it into natty? https://bugzilla.kernel.org/show_bug.cgi?id=31232
<ubot2> bugzilla.kernel.org bug 31232 in IPV6 "/proc/sys/net/ipv6 has two neigh folders" [Low,New]
<pmcenery> Bacially anything that does sysctl in an LXC container never completes.
#ubuntu-kernel 2011-04-20
 * RAOF intrepidly wonders whether he can lock up his GM45 gpu as easily as his Q965
<jk-> RAOF: I have a tool that might help
<jk-> ls -l libflashplayer.so
<jk-> -rw-r--r-- 1 root root 12127284 2011-04-18 09:46 libflashplayer.so -> /usr/lib/libfreezemyGPU.so
<RAOF> jk-: I've got a better one - âwhile true ; do xset dpms force off ; sleep 5 ; xset dpms force on ; sleep 5 ; doneâ
<jk-> oh awesome
<RAOF> Of course, in order to get that to hang the GPU I need to get *compiz* to stop freezing first :)
<RAOF> What?  And *now* I can crash the X server by playing with the screensaver?
<RAOF> Oh, no.  That's because I got compiz to freeze.
<fairuz> morning
 * apw yawns
<RAOF> apw: Are you aware that drm-intel-next has been failing to build for a while? (one of the staging drivers is breaking the build)
<apw> RAOF, nope :)
<RAOF> Consider it reported!
<apw> la la la can't hear you
<RAOF> I wanted to test an easily reproducible GPU hang against drm-intel-next before reporting upstream.
<RAOF> I'm now a sad panda.
<apw> did drm-intel-next-proposed build
<RAOF> Do we even build that?
<RAOF> http://kernel.ubuntu.com/~kernel-ppa/mainline/ doesn't think so.
<apw> yeah we do, doesn't work either by the look of it, grrr
<Sarvatt> RAOF: i386?
<Sarvatt> i've got a drm-intel-next-proposed from 2 days ago built
<RAOF> Yes, as it happens, i386
<Sarvatt> http://kernel.ubuntu.com/~sarvatt/drm-intel-next-proposed/
<Sarvatt> got the intel 2011Q1 release kernel too if you want to try that http://kernel.ubuntu.com/~sarvatt/2011Q1/
<RAOF> drm-intel-next-proposed will do nicely.
<apw> RAOF, ok i think i have the problem isolated, and possibly fixed ongoing, i'll let you know when zinc grinds out a build
<RAOF> I've got sarvatt's drm-intel-next-proposed build that looks like it might not suffer from the same problem.
<apw> nice
<apw> RAOF, and manline v2.6.38-rc3 (ish) is affected?
<RAOF> You mean 2.6.38.3ish?
<apw> i meant 2.6.39-rc3 ish ...
<RAOF> Ah.  I'll check that, too.
<apw> as -proposed is presumably based on that
<RAOF> At least, âwhile true ; xset dpms force off ; sleep 5 ; xset dpms force on ; sleep 5 ;doneâ hasn't caused the GPU to fly through the case yet.  And seems like it might also help with the missing vblank problems.
<apw> RAOF, have you also tried drm-intel-backport ?
<RAOF> No, I have not.
<RAOF> I'll leave dpms cycling while I make dinner.  Once this has demonstrated it's really not going to blow up, I'll start going backwards.
<apw> RAOF, sounds good, i am considering adding backports to the builds list
<apw> ogasawara, on the config summary, how are you generating that, i have the scripts here that i used last year
 * apw is dropping to shift locations (again), will be a couple of hours
<tgardner> apw, have you upstreamed your frame buffer locking patch?
<tgardner> apw, see on LKML: [2.6.39-rc2, framebuffer] use after free oops
<smb> tgardner, note he is currently on the move
<tgardner> smb, oh, I thought he was finally back home
<ogra_> tgardner, wrt bug 766764, do we have all triggers and postinst scripts in the omap4 package ?
<ubot2> Launchpad bug 766764 in linux-ti-omap4 "flash-kernel not run during kernel upgrade" [Undecided,New] https://launchpad.net/bugs/766764
<smb> tgardner, He is, sort of
<ogra_> (i havent confirmed the bug here yet, might be a red herring)
<tgardner> ogra_, as far as I know it should be identical
<ogra_> hmm
<tgardner> wrt postinst, etc
<tgardner> ogra_, it is, however, somewhat complex _and_ written in perl (not my best language)
<ogra_> yeah, i just looked at it ... still rubbing my hurting eyes
<ogra_> someone should reimplement that in shell some day
<ogasawara> apw: I hacked together some scripts to generate it.  care to point me to your scripts?  I wouldn't mind running them to make sure we got the same output.
<tgardner> JFo, what tag do you use for a bug that only applies to a specific release? verification-done or verification-done-maverick ?
<JFo> I believe the latter
<JFo> I haven't been using them, but I know the SRU team does
<JFo> but for bugs that affect multiple releases the latter jogs a memory
<tgardner> JFo, oh, well then I should be able to find it in a wiki. (famous last words)
<JFo> heh
<JFo> indeed :-/
<JFo> I have a plan to update the /Tagging page once all of that is nailed down and reviewed
<tgardner> not that it isn't there. I just won't be able to find it
<JFo> same problem I always have
<JFo> we need a google appliance
<tgardner> bjf was talking about an external wiki site just for kernel info
<JFo> that actually sounds like a great idea
<JFo> tgardner, another bug with many duplicates: bug 766550
<ubot2> Launchpad bug 766550 in linux "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x36f/0x3e0 [radeon]()" [Undecided,New] https://launchpad.net/bugs/766550
<JFo> did we ever hear anything on the other?
<tgardner> JFo, remember that LP bug bjf and I were complaining about yesterday? where you don't get bugmail even though you're on the right teams? turns out its a real regression.
<JFo> wow
<JFo> so they added something that broke that?
<JFo> to LP I mean?
<tgardner> yep
<JFo> it was inevitable that you guys would notice given the sheer amount of bugmail we generate
<tgardner> even though I don't read it all, I do kind of watch the flow.
<JFo> yeah, it is a rather good health indicator
<tgardner> JFo, hmm, I'm not seeing any fixes for bug #766550
<ubot2> Launchpad bug 766550 in linux "WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x36f/0x3e0 [radeon]()" [Undecided,New] https://launchpad.net/bugs/766550
<JFo> not sure exactly when it popped up
<JFo> looking now
<JFo> me slaps LP search
<JFo> bjf, did you replace markAsDuplicate with something else in the arsenal scripts? /me forgets
<JFo> I'm trying to 'put new tires' on the suspend test finish script :-)
<JFo> brb, some one is knocking on my door
<bjf> JFo, nope
<JFo> hmmm
 * ogasawara back in 20
<GrueMaster> ppisati: ping.  You around to discuss bug 588243?
<ubot2> Launchpad bug 588243 in linux "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! " [High,Fix released] https://launchpad.net/bugs/588243
<tgardner> sconklin, whats up with ara's email on the SRU list? are there other packages blocking its promotion?
<sconklin> tgardner: it lacked the certification-done tag, but I don't think that's the hold up. I think that Pitti has just been waiting to be asked before publishing packages.
<sconklin> tgardner: afaik there's no reason it shouldn't have been published. I just added the cert tag, but I don;t think that matters
<tgardner> sconklin, that is something Brendan should have added? the cert done tag?
<sconklin> tgardner: it's a little ambiguous. Pitti was adding them when he saw comments indicating completion. I would like for the teams completing the work to do it. But - as soon as we roll out the workflow manager scripts this will all be moot. And I'm hoping to test that during the next cycle.
<tgardner> sconklin, ah. I thought the workflow stuff was already in place
<eagles0513875> hey apw as this is a kernel specific issue im having how can one trace a kernel loop
<apw> i presume you mean kernel oops
<eagles0513875> ya 
<apw> apport should report a bug with the relevant information
<eagles0513875> i let it report it but it failed to report it cuz it said isnt a valid kernel package
<eagles0513875> and i had to switch to gnome and gdm as i kde and kdm arent working for me
<apw> eagles0513875, is that with my test package ?
<eagles0513875> no with the 2.6.38-9 kernel in the ppa would you like me to try the test package
<apw> ahh thats why then, its too new a package, not an official one
<eagles0513875> well wifi is working fine on gnome
<eagles0513875> with the kernel in the ppa
<eagles0513875> :) 
<eagles0513875> now to swear at kde and kdm
<apw> you should have the error in your dmesg or /var/log/syslog
<eagles0513875> ya ill take a look there trying to wrap my head around unity
<eagles0513875> nothing odd in dmseg
<eagles0513875> dmesg
<ppisati> GrueMaster: yep
<GrueMaster> ppisati: Did you see my email & ogra_'s reply?
<eagles0513875> and nothing out of the ordinary in syslog either apw
<ppisati> GrueMaster: just read it, fine
<GrueMaster> ok.
<ppisati> GrueMaster: then i'll write some stuff about kexec in the bug report but i'll leave it there
<ppisati> GrueMaster: since lucid/ti-omap is dead
<GrueMaster> Ok.
<GrueMaster> Are you going to be helping with Oneiric armel kernel issues as they come up?  I hope so, as you have been doing a great job on backlog armel stuff.
<ogra_> ppisati, dont get me wrong, its a nice to have but there are far more important things to manage atm and we dont have the resources for doing QA on unsupported releases
 * ogra_ agrees with GrueMaster 
<ppisati> GrueMaster: sure, point me to some stuff and i'll look at it
<GrueMaster> Well, we aren't there yet.  :P  We do have some natty kernel bugs that will probably be SRU candidates at this point.
<ppisati> i just thought we were still supporting lucid/ti-omap since it'll be alive till $somewheninthefuture
<GrueMaster> Like I said, lucid omap was a tech-preview.  The image work wasn't started until after the Lucid platform sprint (actually iirc it was only 10 weeks of work).
<GrueMaster> For Lucid Armel, we only support Dove & Babbage.
<ppisati> fine
<GrueMaster> Armel is kind of a tricky issue, as it is mainly contract generated.
<GrueMaster> And we don't have LTS rules for armel.
<GrueMaster> So 18 months is tops.
<ppisati> ok, so, i'll pick some stuff from linux-ti-omap4 and see what i can do
<GrueMaster> Cool.
<JFo> <-lunch
<bdmurray> bjf: I was looking at the apport-package hook for linux and report['Title'] = '[STAGING] ' + report.get('Title', '')
<bjf> bdmurray, looking
<bdmurray> bjf: bug titles with staging drivers end up always being [STAGING] as 'Title' doesn't exit
<bdmurray> er exist
<bdmurray> well or doesn't exist if people use 'ubuntu-bug linux'
<bdmurray> https://bugs.edge.launchpad.net/ubuntu/+source/linux?field.searchtext=STAGING&orderby=-datecreated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<bjf> bdmurray, i was seeing some of those before making my change, though I will concede that I may have made it much worse
<bdmurray> bjf: no I think that bit hasn't changed
<bjf> bdmurray, so, you are pointing out a bug that existed prior to my latest hackage? 
<bdmurray> bjf: yes, because I'm not certain what the kernel team wants to do here and you seem interested in the package hook
<bdmurray> bjf: I'm guessing people figure [STAGING] is enough of a title and don't add anything else.
<bdmurray> if [STAGING] wasn't there they'd have to enter something and staging might be best as a tag
<bjf> bdmurray, good point
<bdmurray> bjf: actually they are already tagged staging so I'd just remove the title bit
<bjf> bdmurray, i'm thinking that as well
<bdmurray> bjf: if it helps to have staging in the title you could have some bot preprend it then
<bjf> true
<bdmurray> bjf: I'm happy to do this is there someone I should check with though?
<ogasawara> apw: you're away Fri ya?  If so, I'll handle the release meeting.
<apw> ogasawara, oh yeah ... hrm
<apw> thanks ;)
<ogasawara> I suspect it'll just be a final bug scrub type of meeting
<JFo> yeah, skaet said she was doing a final sanity check of the bugs :-)
<JFo> speaking of which...
<ogasawara> JFo: yet get all the bugs we went over updated?
 * JFo goes off to check the cleanup bugs
<JFo> most of them
<JFo> only ones left are waiting for an answer from the OR
<JFo> gonna look at them now
<JFo> apw, any idea if a fix will be coming for bug 751689 before release?
<ubot2> Launchpad bug 751689 in linux "Thinkpad x201* overheats due to slow fans when on 'auto'" [Critical,Confirmed] https://launchpad.net/bugs/751689
<apw> we are not plannign on any updates before release
<apw> everything on that one points to a bios bug, and anything we do would be a work around
<JFo> thought as much, just wasn't sure if there was any patch needed
<JFo> thanks :)
<apw> its not a regression as maverick was also affected
<JFo> ok
<JFo> apw, were you ok with me closing as Won't Fix for natty but adding a comment saying that we are only closing this for Natty and we will re-evaluate for SRU if a fix comes through?
<apw> i would have though just leaving it open and milestoneing for natty-later ?
<JFo> can do that
 * JFo adjusts
<JFo> smb, you around?
<JFo> was looking at bug 539467
<ubot2> Launchpad bug 539467 in linux "SATA link power management causes disk errors and corruption" [Medium,Confirmed] https://launchpad.net/bugs/539467
<JFo> guess not :-)
<apw> JFo, that one is fixed in userspace, and i'd say mark it -updates too
<JFo> ok, thank you sir :)
<JFo> apw, have we still been seeing PowerPC build failures? bug 733805
<ubot2> Launchpad bug 733805 in linux "[powerpc] ftbfs (ql4_nx.c:788:3: error: implicit declaration of function)" [Medium,New] https://launchpad.net/bugs/733805
<apw> not recently
<JFo> that is the last one I will pester you with :-)
<JFo> ok
<fred__> what is the most efficient process to request a bugfix to be backported from 2.6.39 to natty's kernel? 
<ogasawara> fred__: open a bug since it'll need SRU, post a reference to the patch in the bug, let us know the bug #
<fred__> k
<ogasawara> fred__: do you know if the patch was CC'd to upstream stable?
<ogasawara> fred__: if so, we'll get it automatically eventually
<fred__> ogasawara, don't understand your question precisely. But the patch did not get into linux 2.6.38.x if that is your question
<ogasawara> fred__: sorry, that's what I wanted to know
<fred__> ogasawara, oh yes, it is now in 2.6.38.3: "Btrfs: Fix uninitialized root flags for subvolumes"
<ogasawara> fred__: cool, 2.6.38.3 is already queued for the first kernel SRU
<ogasawara> fred__: so you don't need to do anything :)
<fred__> ogasawara, ah good news! do you know when it'll be released: as soon as possible, or after the natty's release only ?
<ogasawara> fred__: it'll be after natty releases, as we'll currently frozen
<ogasawara> fred__: but let me get you the details to run from our pre-proposed ppa which will have the fix
<JFo> most of the regression-proposed for natty I am seeing are the sch_generic bug
<ogasawara> fred__: https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<fred__> ogasawara, oh yes, I'll wait 12 hours to get these details!
<ogasawara> fred__: install the linux-2.6.38-9.43~pre201104180902 kernel package from that ppa
<fred__> ogasawara, is a -server kenel also included ?
<ogasawara> fred__: yep
<ogasawara> fred__: do you need i386 or amd64?
<fred__> ogasawara, I guess I need that one for amd64, right ? linux-image-2.6.38-4-server_2.6.38-4.31~pre201102160903_amd64.deb 
<ogasawara> fred__: yep that should be it
<ogasawara> fred__: wait, that's not it
<fred__> ogasawara, indeed, I need the -9 one..
<ogasawara> fred__: https://launchpad.net/~kernel-ppa/+archive/pre-proposed/+files/linux-image-2.6.38-9-server_2.6.38-9.43~pre201104180902_amd64.deb
<fred__> ogasawara, yep got it thanks
<fred__> ogasawara, thanks a lot... 10 VMs will be able to restart tomorrow :)
 * tgardner --> lunch
<yhager> How can I upgrade my (maverick) kernel to latest? Are there binaries of latest kernels from kernel.org for ubuntu?\
<jjohansen> yhager: you can either upgrade your whole OS to natty or you can choose to just upgrade your kernel.
<yhager> jjohansen: I just want the kernel
<jjohansen> you can download ubuntu kernels from packages.ubuntu.com (search for linux-image)
<jjohansen> or mainline kernels from our ppa
<jjohansen> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<jjohansen> yhager: install with dpkg -i
<yhager> "mainline" means vanilla?
<jjohansen> yhager: you may need to hold down the left shift key on boot to get to the grub menu to switch between kernels
<jjohansen> yhager: yep, vanilla upstream
<yhager> so I guess that apt-get update'
<yhager> so I guess that 'apt-get update' takes the latest kernel for maverick, but if I want a later ubuntu kernel, I should remove 'maverick' from my search, right?
<jjohansen> yhager: apt-get will use your sources from /etc/apt/sources.list
<yhager> so what has better chances to work with maverick (no guarantee, I know) - mainline or natty?
<jjohansen> yhager: they should both work, natty has the ubuntu extras like aufs enabled etc.
<yhager> jjohansen: ok, I'll try. Thanks!
<jjohansen> I would say go natty unless you really want to mess with mainline
 * jjohansen -> lunch
<njin>  hello guys, many times, expecially with overheating pc, I found this 'ACPI: BIOS _OSI(Linux) query ignored' , so i'm asking myself if it is not the case to have a tag for this particular branch of bioses?
<mjg59> It's legitimate for a BIOS to ask that and it's legitimate for us to ignore it. It doesn't tell you anything about the machine.
<cking> apart from it implements _OSI(Linux) :-)
<mjg59> Well, the spec allows that
<mjg59> So, ok, it doesn't tell you anything *useful* about the machine
<pmcenery> Hi. Can this fix be included in Natty? https://bugzilla.kernel.org/show_bug.cgi?id=31232
<ubot2> bugzilla.kernel.org bug 31232 in IPV6 "/proc/sys/net/ipv6 has two neigh folders" [Low,New]
<pmcenery> Its apparently been merged v2.6.38-8876-g036a982
<tgardner> pmcenery, it might be coming via stable already.
<pmcenery> Is there a PPA that I can try? I've tried the 2.6.39-rc4 which is broken in some other way... get kernel panic
<tgardner> pmcenery, hang on, still checking
<pmcenery> tgardner: thanks. I'm running latest natty as of not so long ago... which has this kernel: linux-image-2.6.38-8-generic
<pmcenery> not so long ago as in 30 minutes ago update...
<tgardner> pmcenery, hmm, its not marked for stable. I'll see about getting it included.
<pmcenery> This one may be marked as low, but it borks lxc in a big way
<pmcenery> Bacially, any software in lxc doing sysctl check gets stuck in an infinite loop
<tgardner> pmcenery, do you have a Launchpad bug yet, or just the bugzilla one ?
<pmcenery> I've just found the kernel bugzilla one, not created a lp one yet?
<sforshee> tgardner, looks like it's already in greg-kh's stable queue to me: https://lkml.org/lkml/2011/4/19/392
<pmcenery> Should I create one?
<tgardner> pmcenery, nope, looks like it won't be necessary. it'll show up in stable soon
<tgardner> pmcenery, point your apt repo at https://launchpad.net/~kernel-ppa/+archive/pre-proposed and you'll get it as soon as we commit it.
<pmcenery> tgardner: thanks.
<pmcenery> tgardner: how soon after commit in stable does the PPA get updated?
<tgardner> pmcenery, I generally get 'round to it within 24 hours.
<tgardner> kind of depends on when he releases.
<pmcenery> tgardner: thanks. I'll keep an eye on it. Thanks for the help
<kees> ogasawara: random note for ubuntu-cve-tracker and upstream "released" versions: can you use "~" instead of "-" when specifying an rc release? i.e. 2.6.39~rc1 instead of 2.6.39-rc1
<tgardner> kees, like we'll all remember that.
<kees> tgardner: ah, sorry. she was last to touch it. it's just regular debian-style versioning, so 2.6.39-rc1 > 2.6.39 which isn't the intention.
<tgardner> kees, but upstream kernel rc versioning _isn't_ debian compliant.
<kees> tgardner: right, which is why I was asking, since u-c-t expects package versions.
<ogasawara> kees: yep, smack me again if I forget in the future.
<ogasawara> apw: ^^ just fyi since I saw you also making changes this morning
 * tgardner is off to imbibe 2 or more mildly alcoholic beverages. cheers.
<ogasawara> I've added a blurb to https://wiki.ubuntu.com/Kernel/Dev/FixingCVEs about the above, not that anyone cares.
<bjf> "Thank you for your attention to detail"
<ogasawara> heh
<akgraner> Hi all you kernel teams folks - guess who is looking for a non-developer/non-technical session (you know for end users like me) on the Ubuntu Kernel...it's for open week...any takers...  I'll email the list as well, buth thought I would start here?
<akgraner> s/teams/team even
<akgraner> s/buth/but   jeez I suck at this typing thing today....
<akgraner> man I'm hearing the faint sound of crickets...:-D  if you think of anything else you or anyone else would like to share with new users about 11.04 let me know  - thanks y'all
<bjf> akgraner, no habla
<ogasawara> bjf: don't make eye contact
<akgraner> bjf, haha, no big kid table for you...
<akgraner> ogasawara, why does everyone say that..;-)
<ogasawara> heh
<bjf> akgraner, i think manjo is interested
<akgraner> bjf, something about a bus is coming to mind as I read that...
 * sconklin whistles
<akgraner> sconklin, ham radio with Ubuntu :-) yes!?
<sconklin> akgraner: someday, after you show me how to capture screen video with audio commentary
<lifeless> bjf: FYI the mail bugfix is deploying now
<akgraner> sconklin, you got it at UDS will take less than 10 minutes...
<bjf> akgraner, i think our mgr. told us not to talk to you, can't remember exactly why right now
<bjf> lifeless, sweet!
<akgraner> bjf, well there is that...o.O
<sconklin> akgraner: and especially not to drink from any jars you offered. 
<sconklin> or maybe that's my own memory
<akgraner> that's your memory...
 * akgraner goes away but if y'all think of some sessions that would rock to help end users become even better, more efficient users especially since we now have Unity...just let me know - I'll start hunting people down :-)
<bjf> akgraner, users are not supposed to notice that a kernel even exists
<akgraner> bjf, yeah but when they do they think is awesome they just aren't sure why...that's where you all come in..:-)
<bjf> ogasawara, i was pushing lucid master-next possibly the same time you were, I didn't see your cve on it so i hope i didn't stomp on it
<ogasawara> bjf: I don't think so, I'd only pushed the CVE's to branches in my personal repo
<bjf> ogasawara, cool, i've just made it more difficult for you when you do go to push
<ogasawara> heh
 * ogasawara back on later
#ubuntu-kernel 2011-04-21
 * jjohansen back on later
<pmcenery> I'm trying to rebuild the source package linux-image-2.6.38-8-generic using sbuild
<pmcenery> I get the following error EE: Previous or current ABI file missing!
<pmcenery> I have read you need to define the following environment varibale before the build AUTOBUILD=1
<pmcenery> Does anyone know how to do this with sbuild?
<cooloney> apw: hey, andy
<apw> cooloney, s'up
<cooloney> apw: yeah, i am trying to merge master ubuntu -8.41 and -8.42 patches on our ti-omap4
<cooloney> apw: but got lots of conflicts
<apw> i thought you already did that
<apw> or more correctly, i thought tim pulled in your previous pull-request for that
<cooloney> right, tim pull my previous one
<cooloney> which is just -7.39 based 
<cooloney> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
<cooloney> apw: so i try to merge those patches like you did 
<cooloney> apw: but face too many conflicts, i'm not sure i did right command
<apw> well to do the merge i reconstructed your base tree to be merges
<apw> to avoid all the conflicts having patches on both sides causes
<apw> that version is pushed up to my tree on zinc if you want to look at/use it
<apw> cooloney, ^^
<cooloney> apw: yeah, i am looking at it.
<cooloney> http://kernel.ubuntu.com/git?p=apw/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
<cooloney> apw: is this one ^^
<apw> cooloney, yep thats the one, what i did was dropped all the commits which would have come from .40 and merge that instead, then applied your local delta for the branch, then compared that to your original tree, and it was the same
<apw> (well other than some spacing changes in aufs, so you had to use git diff -b to confirm its a null diff)
<cooloney> apw: looks like we need to reconstruct the tree again.
<apw> cooloney, why ?
<cooloney> apw: i mean change some commints which are in ti-omap4 ubuntu branch, 
<cooloney> not just merge patches on it
<apw> which commits need changes ?
<apw> you mean you also want to add some new patches ?
 * bryceh waves to apw
<apw> bryceh, hii
<apw> cooloney, i am not quite understanding you
<bryceh> apw, thanks for the new kernel dailies; I put them to good use today
<cooloney> apw: i found this http://kernel.ubuntu.com/git?p=apw/ubuntu-natty.git;a=commitdiff;h=d7faeb2d5c3c7d126add877f2ca450a225a02272 in your tree
<apw> bryceh, oh did they actually rebuild, good
<bryceh> apw, indeed, and at least a few reports so far of issues solved by it
<cooloney> so we need try this firstly and applied ti-omap4 delta, and merge .41 .42
<apw> cooloney, but that is exactly what is on my tree ?
<cooloney> looks like we need to replace the ubuntu ti-omap4 with a new branch now
<cooloney> not just try to put .41 .42 patches on top
<apw> cooloney, right ... let me make a ti-omap4 which matches exactly your tip
<apw> and you can base off that for your next pull, and you can do the merges
<cooloney> apw: awesome, since I can merging patches from linaro guy without any conflicts
<cooloney> apw: so i try to creat a ti-omap4 like this
<apw> cooloney, ok give me a few mins, to pull out the base, as i have it here
<cooloney> 1208.11 + merging linaro patches + merging ubuntu master patches + 1208.12/1209.12
<cooloney> apw: thanks a lot, man
<apw> cooloney, also reember when you do a merge (or a rebase) you need to use debian/scripts/misc/insert-ubuntu-changes to copy over the changelog fragments
<apw> i note that you have not been doing this before, and that makes tracking bugs and cves hard
<cooloney> apw: oh, got it. yeah, it is my first time to do merging 
<apw> cooloney, ok you should find a new branch ti-omap4-40 which represents the latest upload but in merge form
<apw> you should find you can pretty simply merge into that from the Ubuntu-2.6.38-8.42 tag for instance 
<cooloney> great, let me fetch it
<apw> then you would do debian/scripts/misc/insert-ubuntu-changes debian.ti-omap4/changelog Ubuntu-2.6.38-8.40 Ubuntu-2.6.38-8.42
<apw> to get the changes copied over, then commit that as 'merge in Ubuntu-2.6.38-8.42'
<apw> then you can merge in linaro or apply local patches or whatever
<apw> then fdr insertchanges as normal and you are good to make a pull request
<apw> cooloney, when you are done, push it up and i can review it
<cooloney> apw: yeah, no problem
<cooloney> oh, how about just run 'fdr insertchanges'
<cooloney> before that i normally try fdr printchanges'
<apw> sensible, but not required, printchanges just displays what will go in
<cooloney> yeah, just take a look at that
<cooloney> then use fdr insertchanges
<apw> you would expect to see just two merges one which is the real merge, and one which is the commit containing the changelog update
<cooloney> got it.
<cooloney> i saw your branch contains those merging commits
<apw> yeah, i was experiemtning, though you released between so it is stale now
<apw> cking, did you electrician turn up in the end?
<tgardner> apw, did you catch in scroll back yesterday where I bugged you about upstreaming the fb dev locking patch?
<apw> ahh no i didn't
 * apw adds it to his todo
<tgardner> apw, I saw a discussion on LKML where someone else was hitting the same problem
<apw> ahh right, thanks, got a pointer to the thread ?
<tgardner> apw, yeah, right. snort...
<apw> tgardner, :)
<tgardner> apw, it would have been too handy if I'd have written it down at the time
<apw> heh yeah, i never do that either, and annoy myself often
<cking> apw, yep, now waiting for the certification process to kick in
<apw> cking, that sounds mad, if its not cirtified do they burn your house to the gruond ?
<cking> it means I can sell the house if I want to
<ogasawara> apw: the delta config scripts you have, can you point me to them?  I hacked together scripts of my own to generate the output on the wiki, but I wouldn't mind double checking our scripts produced the same data.
<apw> ogasawara, i have more experimental options changing than you i think
<apw> i think you have none
<apw> i think i have two or something
<tgardner> sforshee, lemme know when you're done on tangerine. it needs a reboot for a kernel update.
<apw> ogasawara, am looking at sucking it all up together
<ogasawara> apw: that'd be good.  maybe we can check it into kteam-tools.
<apw> ogasawara, yeah will do that now
<apw> then you can fix it :)
<ogasawara> heh
<sforshee> tgardner, that's weird, I'm not using tangerine, don't know what those jobs are
<sforshee> go ahead and reboot
<smb> /me should have paid attention to tgardner as he *was* using tangerine. Meh...
<tgardner> smb, it'll be back in 5 minutes
<smb> tgardner, good enough
<tgardner> apw, you're audio is totally scrogged now
<tgardner> smb, tangerine is back
<smb> tgardner, yup, I know. :) Thanks
<tgardner> updating natty schroot
<apw> ogasawara, you do not want to run this script on a slow computer :)
<ogasawara> apw: heh, good to know
<apw> its been running for about 20 mins on my netbook :)
<tgardner> apw, why wouldn't you do it on one of our servers?
<apw> tgardner, oh that would have been much more sensible, and once its in kteam tools -- it'll be easy too
<apw> i am just confirming it is disconnected from my home directory
<tgardner> apw, hmm, last I noted you still had commit rights :)
<apw> yep, i thought i'd just run it quick before committing it, to make sure i'd done it right
<apw> it might have been quicker to push it, then do it
<ogasawara> apw: just fyi, kees asked us yesterday that when we update the ubuntu-cve-tracker if we could switch "-" for "~" if we note something is released.  eg.  released (2.6.39~rc1) so that it conforms to debian versioning.
<ogasawara> apw: only reason I mention it is it looks like the atuo triage tool you have might need tweaking
<JFo> <- grabbing food
<bdmurray> bjf: the staging bug title change made it into apport
<bjf> bdmurray, sweet! thanks for handling that
<bdmurray> bjf: your question change should probably be SRU'ed too I'd think
<bjf> bdmurray, i did a bug with SRU text in it
<cprofitt> tgardner: I am trying to make heads or tails of the iwlagn issue and it looks as though things might be getting around to solved based on the latest reports on LP
<cprofitt> I was curious if you could help clarify if that is correct for the 5300 and 6300 series of the cards
<tgardner> cprofitt, well, sort of. I think there are still likely issues with 802.11n
<tgardner> cprofitt, Intel claims they should be working
<tgardner> in fact. they are only focused on newer cards. 3945 and 4965 are in community maintenance mode
<cprofitt> does Natty B2 have the Intel fixes -- should I work on testing that?
<cprofitt> I have a 5300 and was debating getting a new laptop with the 6300 in it...
<tgardner> you could be running from https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<cprofitt> hey... there is the other key person involved with the Intel iwlagn
<cprofitt> I do appreciate the work you guys are doing
<bjf> bdmurray, bug 765178
<ubot2> Launchpad bug 765178 in apport "remove user-input questions from linux source package hooks" [Undecided,New] https://launchpad.net/bugs/765178
<cprofitt> tgardner: I have been following bug 630748 -- is that the correct one to follow or is there another for the issue?
<ubot2> Launchpad bug 630748 in linux "iwlagn degrades quickly during normal wifi session" [High,Confirmed] https://launchpad.net/bugs/630748
<tgardner> cprofitt, that is pretty much the uber-bug for this particular issue.
<cprofitt> tgardner: alright -- if you need testing on anything let me know. I will take a look at the PPA when I get home tonight
<tgardner> cprofitt, ack
<cprofitt> tgardner: are the 6300 series cards ok, or do they also suffer from the issue?
<tgardner> cprofitt, dunno for sure. I've no personal experience with them.
<cprofitt> k... will have to see if i can find a person who has one for testing prior to making a purchase.
<cprofitt> thanks for taking the time to answer the questions
<JFo> bug of note: bug 759213
<ubot2> Launchpad bug 759213 in linux "[HP Compaq 6005 Pro] Suspend does not resume" [Medium,New] https://launchpad.net/bugs/759213
<JFo> apw, tgardner didn't we remove the ability to hibernate?
<tgardner> JFo, its still in the kernel, but its been removed from the user space choices AFAIK
<JFo> hmmm
<JFo> bug 760036
<ubot2> Launchpad bug 760036 in linux "[Dell Inspiron 580] Hibernate unable to resume properly" [Medium,New] https://launchpad.net/bugs/760036
<JFo> cert blocker
 * JFo goes to verify on his natty machine
<tgardner> ick
<JFo> yeah
<ohsix> you can't hibernate anymore? D:
<bdmurray> tgardner: if its removed the menu should it really block certification then?
<tgardner> likely not, but we should check that its really gone from the menu
<ohsix> i'm on natty and i still see menu entries for it
<bdmurray> ohsix: with unity or classic?
<ohsix> and i've not seen any changelog or release change notices that say that's being removed
<ohsix> classic
<JFo> sorry, had to boot it first
<JFo> it is still there in my netbook
<JFo> tgardner, ^
<cking> hrm, my natty install with unity has a hibernate option
<JFo> see cking I told you :-P
<ohsix> if it's being considered for removal consider this my official request that it's not :D
<tgardner> well, I thought it was the result of our rally discussions in Dallas
<JFo> same here
<ohsix> in fact i would have been SOL just yesterday without hibernate
<JFo> I distinctly remember it having been decided
<cking> hibernate on the natty kernel is much improved now it uses compression
<jjohansen> JFo: I remember it being decided, and wasn't even there
<JFo> jjohansen, :-)
<JFo> so I guess someone un-decided it and deglected to tell us
<apw> ogasawara, ok i've pushed the scripts to kteam tools, new subdir devel, the one of interest is devel-config-summary ubuntu-natty ubuntu-oneirc ... note it will do lots of futsing in your repos which will end up being reset hard to their current HEAD (which you'd want to be master-next)
<apw> the report is straight to stdout, so i normally | tee SUMMARY
<apw> an example which looks right against te current tips is in zinc:~apw/SUMMARY
<ogasawara> apw: cool, i'll test it out when i get back
 * ogasawara bails for a bit
 * tgardner --> lunch
<JFo> stepping away for a while. I have errands to run before some places close for tomorrow and I have some early dinner plans. be back on later
 * apw calls it a day .. have fun
<tgardner> apw, have a good weekend
 * bjf[afk] -> lunch
<godber> hi, is it unusual for a kernel to be in both updates and proposed, as 2.6.32-31.61 is here: https://launchpad.net/ubuntu/+source/linux
<njin> hello, can someone tell me if the bcm 4331 driver is shipped ? thanks
 * jjohansen -> lunch
<pmcenery> Hi. I'm trying to apt-get source linux-image-2.6.38-8-generic, apply a path, bump the version and recombile with sbuild. I noticed there is a debian and debian.master folder. Which one do I bump the version in?
<komputes> Can someone from the kernel team please have a look at Bug #768497 - It seems the card reader on a Acer Aspire 5943G ignore PCI bus 4 unless the system is booted with an SD card present.
<ubot2> Launchpad bug 768497 in linux "[STAGING] " [Undecided,New] https://launchpad.net/bugs/768497
<komputes> JFo: ^
<komputes> bbl
<sconklin> pmcenery: the recommended way to build an ubuntu kernel is from the git repo, see this page: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<sconklin> pmcenery: and you would change the version in debian.master/changelog right before you do the fakeroot debian/rules clean
<bjf> komputes, nice drive-by
<eruditehermit> hello
<eruditehermit> is anyone here an Ubuntu kernel developer?
<eruditehermit> I have a request for the kernel
<eruditehermit> to enable laptops with multiple GPUs to boot properly, CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY must be set in Kconfig. The kernel developer for X Dave Airlie is going to enable it by default in upstream kernels from now on but it would be nice if Ubuntu could activate it for current kernels as it makes some laptops boot properly.
<eruditehermit> brb
<bjf> eruditehermit, please file a bug and then come back here and tell us what the bug number is
<eruditehermit> bjf, ok
<eruditehermit> bjf, is there a way to file bugs through the web or is it ubuntubug?
<bjf> eruditehermit, the kernel is frozen, it will take a SRU (stable release update request) for a fix
<bjf> eruditehermit, https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<jjohansen> rebooting
<eruditehermit> bjf, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768645
<ubot2> Launchpad bug 768645 in linux "CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY should be SET in kernel config" [Undecided,New]
<bjf> eruditehermit, thanks
<bjf> JFo, ^ can we get that added to the list ?
<eruditehermit> bjf, someone mentioned that ubuntu has build servers for ppas?
<eruditehermit> can I build a kernel on it with that enabled if I get a ppa?
<bjf> eruditehermit, does that config option already exist ?
<eruditehermit> yes
<eruditehermit> its just not set
<eruditehermit> in natty
<eruditehermit> bjf, cat /boot/config-2.6.38-8-generic | grep CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
<bjf> yes, i'm looking at it now
<bjf> eruditehermit, are you looking for an amd64 or i386 kernel ?
<eruditehermit> I am using amd64
<bjf> eruditehermit, give me a sec and i should have a kernel for you
<eruditehermit> bjf, nice thanks =)
<bjf> eruditehermit, to answer your previous question, yes we do have build resources available via ppa, however, it's kind of a slow way to go
<eruditehermit> whats the fastest way to go
<eruditehermit> I have to install all the dependencies on my machine to build anything because its my daily use laptop
<bjf> eruditehermit, for me to do it for you :-), though it will be more than a second, it shouldn't be very long
<eruditehermit> ok
<eruditehermit> thanks
<bjf> eruditehermit, i have access to a very big build server
<bjf> eruditehermit, np
<eruditehermit> well let me restart
<eruditehermit> I am currently on software rasterizer
<eruditehermit> brb with intel
<eruditehermit> hello again
<eruditehermit> bjf, so do you think this will get in sometime for natty? even if its an update shortly after release?
<bjf> eruditehermit, it's building now, shouldn't take too long
<bjf> eruditehermit, i'd guess so, but without digging in more to understand what enabling that config option also drags in and the impact on other code, i can't say for sure
<bjf> eruditehermit, if Dave Airlie can it to the default config and get that in as a stable upstream commit, it would have more weight behind it
<bjf> eruditehermit, is this a laptop that has multiple gpus or a desktop ?
#ubuntu-kernel 2011-04-22
<eruditehermit> bjf, laptop with intel sandybridge GPU and radeon discrete GPU
<eruditehermit> bjf, airlied is in #radeon
<bjf> bryceh, ^^ does this request seem reasonable to you ?
<bjf> eruditehermit, do you have a make and model for that ? I can see if we have one in the company
<eruditehermit> sony viao S 2011 just released
<eruditehermit> VPCSB
<bjf> eruditehermit, what are the symptoms right now without this enabled ?
<bjf> eruditehermit, nevermind, read the bug report :-)
<eruditehermit> right
<eruditehermit> I have to blacklist radeon manually
<eruditehermit> for it to work normally with just the sandybridge GPU
<eruditehermit> but for a new user who doesn't know how to blacklist modules its not fun
<bryceh> bjf, multi-gpu setups seem to be pretty boned at the moment, so if that config change helps, I'm +1 on it
<bjf> bryceh, cool, i almost have a kernel for him to test
<bjf> bryceh, will add the results to the bug
<bryceh> bjf, typical problem seems to be you have intel and radeon|nvidia, you plug monitor into latter card, and kernel comes up with both i915 and some other driver, and i915 starts throwing up
<bryceh> dunno if that corresponds to eruditehermit's issue but that's one I'm seeing quite a bit of
<eruditehermit> bryceh, bjf: <airlied> eruditehermit: well I'm forcing it on upstream and in stable
<eruditehermit> <airlied> fedora has had it on for years
<eruditehermit>  and RHEL
<eruditehermit> <airlied> I'll send the patch to dri-devel
<eruditehermit>  so they can see it before I push it
<bryceh> heh, a "we'll make linux work only on redhat" patch, fun
<bjf> eruditehermit, http://people.canonical.com/~bradf/lp768645/
<bryceh> eruditehermit, would you mind posting a dmesg from one of the failure modes you've seen?  I'd like to try to connect this to other bugs I've seen reported.  If I can, that may help lend additional weight to getting the SRU approved.
<eruditehermit> bryceh, sure It'll take a few mins to reboot and collect info
<eruditehermit> bjf, thanks I'm downloading and installing
<eruditehermit> brb
<eruditehermit> hey guys
<bjf> eruditehermit, well ?
<eruditehermit> I still have problems with my setup
<eruditehermit> I am debugging them with airlied
<eruditehermit> but I still think that kernel config option might help others
<eruditehermit> bryceh, here is my dmesg http://pastebin.com/AjkiQ9WC
<eruditehermit> in any case airlied will make that option the default in stable and upstream from now
<bjf> eruditehermit, can you attach that to the bug?
<eruditehermit> bjf, sure
<bjf> eruditehermit, did you confirm that i got the config option turned on ?
<eruditehermit> bjf, yes
<eruditehermit> i'll send my kconfig to airlied to see if there is anything else
<bryceh> eruditehermit, sweet thanks; that OOPS definitely looks familiar...
<bjf> eruditehermit, i'll be around for a bit longer if you need another kernel turned
<eruditehermit> bjf, talking to airlied about it. He says that it seems like it is trying to init radeon before the card is powered up.
<bryceh> bjf, fwiw what I've gathered is that getting multi-gpu setups to "work" will require a number of different changes and a lot of testing
<bjf> bryceh, too bad, was hoping we could fix a few with a minor change
<bjf> bryceh, sounds like natty will have plenty of sru business
<jjohansen> yeah
<bryceh> bjf, yeah
<eruditehermit> bjf, would you be willing to patch a kernel module and build it for me?
<bjf> eruditehermit, you have the patches ?
<eruditehermit> http://fpaste.org/Z8pu/
<eruditehermit> patch for radeon module
<bjf> eruditehermit, just the one line ?
<eruditehermit> looks like it
<eruditehermit> supposedly it will check for GPU power on before it inits the card
<bjf> eruditehermit, building
<eruditehermit> bjf, thank you so much
<bjf> eruditehermit, that doesn't compile 
<bjf> eruditehermit, error: âhandleâ undeclared (first use in this function)
<eruditehermit> hrm
<eruditehermit> http://fpaste.org/28SP/
<eruditehermit> bjf, new patch
<bjf> eruditehermit, building
<eruditehermit> bjf, apparently on multi GPU setups there is a power switch for the card that doesn't exist on single GPU machines. This patch turns the GPU on. If bryceh has seen this a lot this might be why
<eruditehermit> apparently linux doesn't do multi GPU setups well
<bjf> eruditehermit, seems to have compiled, still building
<eruditehermit> bjf, cool thanks =)
<bjf> eruditehermit, new kernels are there, same directory, you want the "b02" ones
<eruditehermit> bjf, thanks =)
<eruditehermit> bjf, this is what I have http://www.sonystyle.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=10551&storeId=10151&langId=-1&productId=8198552921666318656
<bjf> eruditehermit, nice looking
<eruditehermit> I wanted something light and powerful
<eruditehermit> 3.8lbs
<eruditehermit> not many people making lightweight laptops for some reason
<bjf> i've got a lenovo thinkpad x301 that i really like
<eruditehermit> lenovo mousepads and keyboards annoy me
<eruditehermit> apple has the best touchpad
<eruditehermit> I was going to get a macbook pro
<eruditehermit> but its slightly heavier
<bjf> i really like the keyboard, except where they put the escape key
<eruditehermit> the fn key
<eruditehermit> annoys me
<eruditehermit> its to the left of control
<bjf> you can't get that sony with an ssd?
<eruditehermit> yeah you can
<eruditehermit> it just costs more
<eruditehermit> it also has a sheet battery for $99 extra
<eruditehermit> sheet extended battery
<eruditehermit> that clips on
<eruditehermit> screen viewing angle sucks though
<eruditehermit> but then I think a lot of laptop screens suck
<eruditehermit> it doesn't reflect as much as the macbook but it isn't as bright
<eruditehermit> I have a macbook in the house too
<eruditehermit> ok
<eruditehermit> rebooting to test
<eruditehermit> brb
<bjf> eruditehermit, what's the word ?
<eruditehermit> bjf, still having problems =(
<bjf> eruditehermit, i'm kind of done for today, will be checking back periodically though
<eruditehermit> bjf, ok thanks
<eruditehermit> bjf, will you be around tomorrow?
<bjf> eruditehermit, i'm west coast US, yes, will be around all day tomorrow
<eruditehermit> ah me too
<eruditehermit> thank you so much for all your help
<bjf> ericm|ubuntu, np
<bjf> ogasawara, there is no ports branch in natty-meta, does that get added post release or are there no ports now ?
<ogasawara> bjf: hrm, dunno.  would have to take a look.
<ogasawara> bjf: so in the past, luke would hand off the ports trees to us at release.  But I want to recall that with the Natty cycle we took back maintainership.  powerpc is the only one left.
<ogasawara> bjf: I'll need to check with apw what the plan is
<bjf> ogasawara, but it would seem that we've not been doing powerpc during the dev cycle, is that normal ?
<ogasawara> bjf: it's been building, just no meta
<bjf> ah
<bjf> ogasawara, can anyone install it without a meta ?
<ogasawara> bjf: sure, you can grab the deb
<bjf> ogasawara, wonder if anyone has been testing it
<ogasawara> bjf: I'm unsure of our userbase for powerpc and I suspect it gets little to no testing in the dev cycle
<komputes> JFo: ping
<bjf> ogasawara, a cynical person would wonder then why we bother :-)
<ogasawara> bjf: we only found out around Beta1 or Beta2 that it completely failed to boot
<ogasawara> bjf: yep, so it looks like we pulled it back into the master branch, so it's handled by linux-meta
<ogasawara> bjf: so no ports branch needed
<bjf> ogasawara, cool, that's nice
<JFo> komputes, hi, sorry, was grabbing food. :)
<jj-afk> running errands
<ogasawara> bjf, sconklin: I forget, for the stable patch sets do I still need 2 Ack's or can I just push to master-next
<bjf> ogasawara, just push
<sconklin> ogasawara: what he said
<ogasawara> sweet, thanks
<bjf> ogasawara, which tree? lucid ?
<ogasawara> bjf: natty
<ogasawara> bjf: 2.6.38.4
<bjf> ogasawara, ah
<bjf> ogasawara, steve and i are making plans on doing getting natty into the next SRU cadence cycle
<bjf> it's good to have a plan
<ogasawara> bjf: indeed
<komputes> JFo: re-ping
<komputes> JFo: I was wondering if you could have a quick look at Bug #768497 and let me know if the issue is know if if you need further information to triage it.
<ubot2> Launchpad bug 768497 in linux "Acer Aspire 5943G JMicron devices not seen unless system boots with SD card inserted" [Undecided,New] https://launchpad.net/bugs/768497
<JFo> komputes, looking now
<komputes> JFo: cheers
<JFo> komputes, :)
<kees> JFo: hi! what's the right way to make sure LP: #455067 gets included for a lucid kernel update? (it's already been fixed in maverick and natty)
<bjf> bug 455067
<ubot2> Launchpad bug 455067 in linux "[113818.216022] BUG: scheduling while atomic: dosemu.bin/12814/0x10000004" [Undecided,Confirmed] https://launchpad.net/bugs/455067
 * JFo looks
<bjf> kees, you could always submit an sru patch to the mailing list
<kees> bjf: in theory, it's in the stable upstream kernels.
<bjf> kees, still looking, did it go in recently ?
<kees> bjf: so I'm trying to figure out the best way to get it included without creating additional work if it overlaps with the stable upstream updates
<bjf> kees, we should be seeing it soon from upstream stable, gregkh is maintaining that tree
<kees> bjf: I haven't looked at the stable upstream updates yet; in linus's tree, it's 6554287
<bjf> kees, i'm looking now
<kees> Date:   Thu Sep 23 13:16:58 2010 -0400
<JFo> kees, bjf I've got it headed to the hot list and I milestoned it for lucid updates so it is on our radar
<kees> JFo: okay, thanks!
<JFo> kees :-)
 * JFo waits to see what bjf finds
<kees> bjf: no need to jump on it if you're at all busy; I just wanted to get it on the radar since it's already fixed on maverick and natty and I've seen some people hit it with lucid
<bjf> kees, np, it's kind of a slow friday
 * JFo is going blind on bugs again.
<JFo> as an aside, has anyone else not been getting notified by xchat when pinged?
<JFo> doesn't happen all of the time, but it has happened to me twice today
<bjf> JFo, could be a natty osd issue
<JFo> hmm, could be
<bjf> jfo, http://people.canonical.com/~kernel/reports/
 * JFo <3
<JFo> that page is my favorite now
<JFo> I'm even going to get tons of use from the package versions page
<bjf> kees, i see where that patch hit the stable mailing list but i don't think it got any attention
<bjf> kees, also, based on the comments in the commit, it was likely to take a backport which didn't get done
<bjf> kees, but i'll dig a bit more
<kees> bjf: ah, so it's not a straight fix? yeah, I was worried about that, given the commits listed in it. :( I'm trying to get a reproducer for the issue, hopefully that will help for QA.
<bjf> kees, the patch to arch/x86/kernel/vm86_32.c:handle_vm86_trap() looks like it might just apply, but the patch to arch/x86/kernel/traps.c:do_debug() won't that code changed a bit
<kees> yeah, I figured some historical analysis of all the commits mentioned in the upstream commit is needed. there are like 4(?) or so that change the code. O_o
<komputes> JFo: mainline again? Have we improved instructions or the testing process. We use this line so much we should just make a LiveCD with the mainline kernel to simplify testing.
<bjf> komputes, downloading and installing a kernel takes a little less bandwidth than a full LiveCD
<komputes> bjf: I agree, but it's complicated for average user to understand
<bjf> JFo, reading over that page (https://wiki.ubuntu.com/Kernel/MainlineBuilds) it's a little dated and could use some love
<komputes> a lot of it IMO
<komputes> we have to remember that we have experience doing this, average users do not
<bjf> komputes, it shouldn't be complicated, if it reads that way, the wiki page should be fixed
<komputes> why not just put a "mainline" metapackage in the repos for testing purposes
<bjf> komputes, that's an interesting idea
<komputes> This is what happens to most bugs, they get reported against linux, Triager asks for the user to test mainline. At this point many users give up and do not follow up causing expired bugs
<bjf> komputes, feel free to suggest it on the mailing list
<komputes> which one?
<JFo> bjf, yep. it needs updating
<bjf> komputes, the kernel team mailing list
<komputes> should we talk about this at UDS?
<bjf> komputes, we could, but if we like the idea, we could have it implemented by then, and we'll be the ones that need to implement it
<komputes> bjf: Wew you talking about the "kernel-team" mailing list?
<bjf> komputes, the ubuntu kernel team list
<bjf> komputes, https://lists.ubuntu.com/mailman/listinfo/kernel-team
<komputes> bjf: JFo: sent the proposal to the kernel-team list, thanks for your help with this.
<bjf> komputes, thanks
#ubuntu-kernel 2011-04-23
<jj-afk> back on later
<Thedemon007> Hello
<Thedemon007> On the new Siragon ML-6200 netbook I have noticed that some of the function keys do not work.
<Thedemon007> http://pastebin.ubuntu.com/597709/
<Meep> Hi, anyone here will/interested in confirming regression point in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760131 ?
<ubot2> Launchpad bug 760131 in linux "Power consumption raised significantly in natty" [Undecided,Confirmed]
<ohsix> that's a good one, you know you can disable the turbo modes; but it raises an important point
<ohsix> i don't think mav's kernel cared or knew about turbo modes
<ohsix> ugh phoronix
<ohsix> how did they waste so man god damned words and not hilight the problem
<Meep> ohsix:  Isolating the git commit is underway.  The Linus' tree commit has been identified. Looking to find someone who can reproduce it.
<ohsix> nice
<ohsix> theres probably something in Documentation/ about the turbo logic; i don't know how it interacts with cpu governors but you'd think it'd just be another p-state
<Meep> I've worked with Phoronix on getting details analyzed for other issues.  Working with three different projects (Ubuntu/QEMU/KVM) with all of them pointing fingers at each other.
<Meep> So reporting issues visibly is sometimes the best approach.
<ohsix> gpu turbo is new post-mav too
<Meep> Anyway, if there are people who can confirm the power delta between two commits in LInus' tree, we can confirm the merge that caused the regression. 
<ohsix> just running powertop and looking at changelogs will find the problem
<Meep> The change is looking at being in the merge of the hugetable.
<Meep> So it's unlikely that powertop will isolate the issue.
<ohsix> so you suspect that's what's keeping the cpus in turbo, burning battery
<ohsix> the cpu governor should be keeping it out of turbo if there isn't actually anything to run
<Meep> Okay.  There are two general approaches to identifying regressions.  1) prod and work through the problem directly as thought it's a new issue.  2) bisect blindly back to the cause of the problem and unwind the issue.
<ohsix> or make a lot of noise
<ohsix> it looks like pcc can pump up the cpu speed regardless of the governor
<Meep> I assume then that you are not interesting in actually confirming the regression point?
<ohsix> the BIOS decides to do that outside of the OSPM methods
<ohsix> you're a strange one, i'm telling you where it is
<ohsix> or not
<Meep> Can you post your analysis to the bug then?
<ohsix> sure
<ohsix> they've got a crack team at phoronix though, they'll have it in no time
<Meep> For the record though, we're tying to find ways that random users who are not domain experts can assist in finding regression points more than just posting bugs.  That means that they won't be able to do the direct debugging, and they won't understand all the nuances of a subsystem.
<ohsix> an elimination process is prudent; minimize where you actually have to look
<ohsix> reading the commit messages usually directly hilights a related thing
<Meep> usually.  But require domain understanding.
<Meep> A bisect can go through 1000 commits in 10 or so build/reboot cycles.
<ohsix> well if you suspect the hugetbl patches you can look at commits just to that directory or file
<Meep> So it's cheap.
<Meep> Again, you are assuming domain expertise.  Do you have ways that users can assist without the domain expertise?
<ohsix> it's cheap as long as your time is worthless; and the good/bad determination needs to be made, and expensive
<ohsix> i'm assuming they can read
<ohsix> you really don't need to know much to follow them, it rarely gets to that
<Meep> I'm assuming you want bug reports that say "Hi, I've found a problem with this subsystem.  I've isolated it to this change."
<ohsix> i'm not want for anything
<ohsix> aside from less phoronix
<Meep> Yes you are :).  You want users to be able to parse a changelog and provide a good bug report.
<Meep> Phoronix is a website you can avoid.
<Meep> Bug reports you can't.
<ohsix> i want people that have the time and effort to use so many words saying nothing, the ability to read even the slightest about what their problem is
<ohsix> if something changed between x and y, first place to look is the log of chances, with respect to the problem you are having
<Meep> The problem (as per the bug report) was maverick to natty.
<ohsix> but you suspect the kernel already, and their versions aren't unknowable
<Meep> It's clear we have different approaches to this.  Post your thoughts on the bug, and we'll see where it ends up.
<ohsix> i'd be too interested in solving it, i'm not a fan of forums or the mindless speculation
<ohsix> anyways my utter outrage! is offtopic here, best of luck with what you're doing
<ohsix> but one last thing, there was a workqueue or thread added for the hugepage migration, if you also supect that; you could investigate there
<ohsix> i'm only informed by the commit messages fwiw, kernelnewbies has good summaries if you like a quick peek
<Meep> We'll isolate it to a change, and then the kernel guys can dissect it as to the impact and resolution.
<ohsix> sounds like an expedient use of someones time, whoever we is; not looking directly at the information that excludes 99% of what they'll be traipsing over
<Meep> I'm assuming that you understand bisection.  You've suggested half a dozen areas that could be contributing.  The effort to analyze and test that analysis is covered by a blind bisection across the changes.  With a fast machine, you can go from bisection point to point within 10 minutes.  That's not too much time for analysis and trawling through changelogs.
<ohsix> i'm very familiar
<Meep> (FWIW, each has it's own.  I use "trawling through changelogs" you use "triapsing over 99% of changes".
<ohsix> but that assumes you can determine good/bad; and as you mentioned, that assumes an operator that knows more than nothing, as you seemed to imply was unreasonable
<jorge> Please, I need some help with this... I have to modify some parameters of the WiFi MAC level, like ContentWindow min/max (CWmin/CWmax), TXOP, etc.
<jorge> I think the way to go is with iwpriv, with some driver that support those params
<jorge> am I right?
<jorge> if so... which kernel modules and drivers are tested for that? MadWiFi perhaps? (I'm trying with a ar9170usb in a D-Link DWA-160, and this one definitely DOESN'T support this, so...)
#ubuntu-kernel 2011-04-24
<ohsix> hah you know, that Meep guy is probably onto something; and it's a problem i noticed as well, the cpu temperature in my laptop has gone up a steady 2 degrees since the last kernel update
<ohsix> strike that, system temperature is way up; hard drive temperature has risen a steady 2 degrees because of it
<Guest81253> Anybody familiar with Kernelcheck?
<pmcenery> sconklin-gone: thanks. got it running.
#ubuntu-kernel 2012-04-16
<Mahesh> was hoping if someone could provide an insight into this:
<Mahesh> http://askubuntu.com/q/55138/45659
 * apw gets his machine back together ...
<smb> apw, What did you do to it?
<ppisati> moin
<apw> smb, heh, put it back together after a parental visit ...
<apw> ppisati, moin
<apw> Nahesh, done
<smb> apw, Ah, so sort of putting the office back together. :)
<apw> smb, that indeed
<apw> smb, but nowadays I have so much stuff plugged into my machine I think the only empty port is the firewire one
<smb> Can see that happen. Maybe time for a docking bay. :)
<apw> smb, i wonder if this heap has one ... its pretty old so perhaps they are nice and cheap now
<smb> apw, That is one of the things, that ThinkPads seemed to be good at. At least those seemed to have an additional docking connection. Most other seem to only offer a usb attachment.
<apw> smb, yeah don't see no stinking connector on it ... sigh
 * apw waits for his machine to update to the frozen archive
<apw> only 89 updates
<ppisati> 237 here...
<apw> ppisati, you are just not trying hard enough
<ppisati> curiosly just 76 on my panda... uhmm...
<apw> lots of universe installed perhaps on the 237 box
<diwic> is there a name for Q yet? 
<apw> diwic, not that i have seen yet no?
<diwic> ok
<apw> i assume we really need to know before long though
<diwic> yeah I feel so too
<apw> diwic, its normally on markshuttleworth.com when its there
<smb> diwic, While you are here and I remember...
<apw> right before i get all settled in for the day i am going to reboot into todays 'fun'
<smb> diwic, I know its probably not the main target thing... but do you know who would be interested / responsible for encoding into mp3 (from rhythmbox or other applications)
<diwic> smb, who as in person or application?
<diwic> smb, not understanding the question really
<smb> diwic, In person (I sort of know its done trhough gstreamer stack)
<smb> The problem I see is a) its not working correctly b) all visible ways of modifying the used gstreamer chain have gone
<smb> https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/945987
<ubot2> Launchpad bug 945987 in rhythmbox "No Settings are available in "Preferred format", only preset defaults are used" [Undecided,Confirmed]
<smb> That bug report is about b) but also (without knowing so) complains about a)
 * diwic reads bug
<smb> diwic, The settings dialog is purely a UI thing I guess... Not sure why it was seen as not needed anymore... The other problem seems to be that something seems wrong with the chain and I am not sure where the heck it would be found nowadays...
<diwic> smb, hmm, can it export to ogg just fine, only mp3 is the problem?
<smb> diwic, Right, ogg seems ok
<smb> diwic, In essence the produced mp3 is vbr but has no xing header
<smb> So bitrate and length displayed are way off
 * ppisati -> reboot
<diwic> smb, ah, so it *can* export to mp3, but the result is broken?
<smb> diwic, right
<smb> And without the dialog there is no way to verify or modify the way it does the encoding 
<smb> (eg. have a different quality setting)
<diwic> smb, I know a few gstreamer people, but not sure if any of them are into mp3
<diwic> smb, gstreamer-devel could be a place to ask
<smb> diwic, I think a good first step would be to get the dialog working
<smb> apw, You cannot hear us anymore
<diwic> apw, if your having mumble trouble, can you please pastebin me the output of "pacmd ls" 
<smb> diwic, Ok, I will try it there then
<apw> diwic, i am having 'not using the damn connector that is marked selected in the g
<apw> gnome thingy' trouble at the moment
<diwic> apw, IIRC the mumble audio wizard allows you to select a device there as well
<diwic> apw, maybe it overrides gnome/pulseaudio's default setting?
<apw> diwic, well it didn't before the last reboot, wtf, i hate hate hate pulse
<apw> open letter to pulse "do what i say or get deinstalled"
<diwic> apw, you can file a bug for it, against pulseaudio. Then I can spam you with requests to try newer versions and open bugs in upstream bug trackers. ;-) 
 * apw cries
<diwic> apw, seriously though, I *do* want to fix it. 
<apw> diwic, yep i know, and i want it to work
<apw> diwic, its just every bloody morning ... every bloody time ... its broken somehow, i hate it
<apw> diwic, what against bugness fun
<apw> diwic, and compared to the utter hideous complexity of pulse the kernel seems easy
<smb> apw, At least its not you disk or raid that is not working...
<apw> smb, heh ... at least that
<apw> diwic, pus
 * apw fails to use his keybaord as well ... sigh
<diwic> apw, pulseaudio is far from perfect; but we're left with two options 1) be patient and try to resolve the bugs that still are there or 2) replace it with something else.
<ppisati> ok, seems i've some mumble/pulse audio prob too
<ppisati> i can hear you
<apw> diwic, heh understood indeed... its just an ongoing torture ;)
<ppisati> but you can only hear my music! :)
<smb> ppisati, We only hear your music
<diwic> ppisati, the output of "pacmd ls" please?
<ppisati> diwic: a mumble restart fixed it :)
<apw> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/982886
<ubot2> Launchpad bug 982886 in pulseaudio "selected input in the gnome input selector is not the input that mumble uses" [Undecided,New]
<apw> diwic, ^^
<ppisati> diwic: pulse didn't pick the correct input (mic vs $somethingelse)
<diwic> apw, thanks
<apw> diwic, i have the 'default' selected in mumble, and its stubbonly the 'inbuilt audio' and not the usb mic
<diwic> apw, hmm, maybe it has something with the "media-role:phone" that mumble identifies itself with
<diwic> apw, I guess that if you run "pacmd stat" it would show the snowball mic as default source?
<apw> Default source name: alsa_input.usb-BLUE_MICROPHONE_Blue_Snowball_201111-00-Snowball.analog-stereo
<apw> diwic, ^^
<diwic> apw, yep. So the analog input is either because of an media-role override or application override.
<diwic> apw, how reproducible is this?
<apw> diwic, its the first i've seen this i think, where its not possible to change it
<apw> diwic, i updated today and rebooted, from fridays archive to todays
<apw> diwic, i have tried moving mumble to the blue and that works and when i put it back to 'default' it goes back to the wrong one
<diwic> apw, ah, interesting. Can you execute this command "pacmd set-log-level 4". Then switch back to 'default'. Then pastebin me "grep pulseaudio /var/log/syslog"
<apw> grep pulseaudio /var/log/syslog
<apw> diwic, http://paste.ubuntu.com/932257/
<diwic> apw, thanks. PulseAudio says "not guilty": "Apr 16 09:55:02 dm pulseaudio[2964]: [pulseaudio] module-stream-restore.c: Not restoring device for stream source-output-by-media-role:phone, because already set"
<diwic> apw, let me dive into the mumble source code to see how it opens the pulseaudio device. It'll take a little while so use whatever workaround you prefer if you need audio.
<apw> diwic, ok thanks
<apw> diwic, oh and just for completeness i have restarted mumble following those being attached and made the defaults; to be in this position.  plus audio output changes approriatly just fine ... i also have usb speaker fun
<jorgesuarez_> hi, is there some place where is explained the removal of -server flavour for 12.04? there are no technical implications? i find the release notes too brief
<apw> jorgesuarez_, there were no configuration differences which could not be done in userspace
<apw> jorgesuarez_, therefore there was no point in building two identicle binaries
<jorgesuarez_> so, preemption and timer interrupt can also be switched? didn't know
<apw> jorgesuarez_, no but they had the same settings
<jorgesuarez_> i thought based on https://help.ubuntu.com/10.10/serverguide/C/preparing-to-install.html#intro-kernel-diffs that preemption and timer interrupt were different on -server
<jorgesuarez_> maybe something has changed since 10.10?
<apw> that was back in 10.10 thats practically the jurassic :)
<jorgesuarez_> but i can't find non-jurassic docs ;)
<apw> decisions to change things like that are discussed at UDS and would be in theory at least documented in the write up of those
<apw> on the blueprints for each release since
<jorgesuarez_> the blueprints on launchpad, you mean?
<apw> the one and only
<jorgesuarez_> i'll take a look then, thanks!
<jorgesuarez_> (sorry, i'll be afk now but come back later)
<diwic> apw, it's mumble's fault. It explicitly sets the wrong device to be used. See comment #2 in your bug for some explanation.
<apw> diwic, bad piece of junk ... did you shove it over to mumble ?
<apw> diwic, i vote for (1) so it moves correctly
 * cking rummages around for some old SSD H/W
 * ppisati -> reboot again
<ppisati> cool
<ppisati> so now my lcd doesn't recognize the output from my motherboard anymore
<ppisati> but works with my panda
<ppisati> i'm officialy sad now...
<apw> ppisati, since you did what, rebooted ?
<ppisati> apw: nope, tested a new linaro patch
<ppisati> apw: attached the panda to the right lcd
<ppisati> apw: spent some time with it (kernel hanged, paniced, etcetc)
<ppisati> apw: decided it was not worth it, reattached the lcd to the hdmi output of my desktop and now it doesn't sync anymore with it
<ppisati> but it works with another source...
<ppisati> uhmm
<apw> physical problem, connector perhaps
<apw> or the cable, slightly dammaged at the connector
<ppisati> apw: i don't have another cable to test, but connectors look good
<apw> ppisati, don't know what to think, as you didn't change th s/w on the desktop it has to be physical no ?
<ppisati> apw: definitely, i'm already buying a cheap discrete graphics card
<ppisati> apw: my video output was mobo integrated (intel dvi + vga)
<apw> ppisati, how annoying
<apw> ppisati, i can see that that will work soooo well :/
<apw> ppisati, does the vga output work on it?
<ppisati> yep
<ppisati> IMO it's the motherboard that is dying
<ppisati> btw, gfx card bought
<apw> you are not having the highest luck right now are you
<apw> what make did you get?  nvidia/radeon/?
<ppisati> ati $something
<ppisati> 30 bucks with 3 output
<ppisati> vga + dvi + hdmi
<ppisati> anyway, i hope i get by tomorrow (but i doubt it)
<ppisati> going from dual to single screen sucks
<ppisati> and yes, it seems i don't have so much luck with video related things lately
<apw> yeah i bet it would ... i guess one day be livable, pretend one is travelling
<ppisati> anyway
 * ppisati -> lunch
<henrix> apw: remember the fsam7400 driver thing i was looking at last week?
<apw> henrix, yep
<henrix> apw: the new driver does not support the bug reporter system
<henrix> apw: bug #979253
<ubot2> Launchpad bug 979253 in linux "BUG: unable to handle kernel paging request at c00fdd20" [Medium,Triaged] https://launchpad.net/bugs/979253
<henrix> so, i guess we still need to keep the old driver anyway
<apw> henrix, now lovely ... i think you said benh was maintaining the new driver ?
<henrix> yep, he's the commiter
<henrix> shall i ping him?
<apw> henrix, might be worth approaching whoever is doing that and see if you can make it support it
<henrix> apw: ack, i'll try that
<apw> henrix, yeah i would indeed
<henrix> apw: thanks
<brendand> herton - hi
<herton> brendand, hi
<brendand> herton - any -proposed kernel news for today?
<herton> brendand, oneiric finished verification, will go today for testing, you can start testing it. Lucid we are reverting one unverified patch, packages should be in proposed tomorrow I expect
<tgardner> herton, which Lucid patch has failed to be verified ?
<henrix> tgardner: the reverted patch was 73ae7483541a7e5e90cc4ce09a08763d86945486.
<henrix> tgardner: "USB: EHCI: go back to using the system clock for QH unlinks"
<tgardner> henrix, I think Ming Lei broke his hand and is gonna be out for a few days. Lemme see if I can reproduce and/or verify this patch before you get too crazy. Otherwise we'll have crackheads coming out of the woodwork in a few days complaining that their USB is too slow.
<herton> tgardner, ok, the bug number: 624510, no one said anything despite several pings for testing there at least
<tgardner> herton, yeah, I see that. gimme an hour or so....
<herton> sure, no problem
<desrt> i guess it's beyond hope for https://bugs.launchpad.net/bugs/956046 in precise?
<ubot2> Launchpad bug 956046 in linux "intel driver fails to use dual-link LVDS if lid is down at boot" [Medium,Confirmed]
<tgardner> desrt, is the patch referenced in the bug report merged in Linus' repo yet ?
<desrt> no.  it's on the to-merge-in-next-version repo
<desrt> intel-drm-next iirc
<tgardner> desrt, it seems like it might qualify as  a bug fix for the 3.4 merge window, though I haven't actually looked at the code. Have you asked upstream about it ?
<desrt> upstream has taken it
<desrt> the freedesktop.org bug is marked FIXED
<tgardner> desrt, no, I meant have you asked them to get it into the 3.4 merge window ?
<desrt> oh.  i have no idea.
 * desrt has no idea how the kernel works
<tgardner> desrt, you don't necessarily have to know how it works. just ask them to merge that specific patch because it fixes your problem. you never know, they might listen.
<desrt> i'd guess that drm-intel-next is what will go into the next release?
<tgardner> yep, 3.5
<desrt> tgardner: so i think it's already slated to be merged (along with a bunch of other things)
<desrt> ah
<tgardner> which is months away yet
<desrt> so you mean a 3.4.x stable release
<tgardner> desrt, 3.4 isn't in the can, so it could still make it as a bug fix
<desrt> i guess i can ping on the freedesktop bug...
<tgardner> desrt, right
<desrt> okay.  done
<desrt> how does that affect ubuntu?  aren't we on 3.2?
<tgardner> desrt, our policy is that we typically only pull fixes from upstream, either 3.2 stable or Linus' repo.
<desrt> gotcha
<desrt> so if they're willing to land it on a stable branch then you'll take it
<tgardner> desrt, correct, but it _first_ has to get merged in Lunus' repo
<tgardner> Linus*
<ogasawara> tgardner: speaking of 3.4, I've rebased q to 3.4-rc3, just gonna do a test build and boot then push
<tgardner> ogasawara, ack
<apw> RAOF, Sarvatt ^^ any thoughts on the dual-lane stuff above ?
 * apw may be unreliable for a bit, some network reconfigs about to get to t
<apw> to the 'oh crap' stage
 * henrix can't find out how to add a release note task to a bug
<apw> henrix, i am sure i know
<apw> henrix, give me the bug # and i'll use it to remember ;)
<henrix> apw: yeah, i guess i just need to add the bug to the "Release Notes for Ubuntu" proj
<henrix> apw: but can't figure it out how :(
<apw> yeah its something like that indeed
<henrix> apw: the bug is 979253
<apw> throw me the number and i'll figure it out and let you know :)
<henrix> thanks
<apw> bug #979253
<ubot2> Launchpad bug 979253 in linux "BUG: unable to handle kernel paging request at c00fdd20" [Medium,Triaged] https://launchpad.net/bugs/979253
<henrix> btw, benh replied. no plans of adding support in the amilo-rfkill
<henrix> i may give it a try
<apw> henrix, ok its 'also affects project', then near the top '(Choose another project)' and then ubuntu-release-notes
<apw> henrix, if you want to write some proposed words you can add them in the top of the description
<henrix> apw: i've looked at that, but then it asks for an URL
<apw> seemed to work for me, it has a box for a url but higher up you can change the thing from linux to something else and it goes away
<apw> the 'Choose another project' thing
<apw> henrix, anyhow its on there now
<henrix> apw: ah, got it! haven't seen the "choose another project" thing
<henrix> apw: thanks, i'll add a small description to that
<apw> henrix, put like "Release Notes:" at the top of the description bit, so it is nice and obvious
<henrix> apw: ack
 * ogasawara back in 20
<henrix> tgardner: any luck reproducing the lucid bug?
<tgardner> henrix, I have not observed the original bug to the extreme taht some of the reports have. dd times for a 4.6GB iso went from 18:57 to 18:42.
<tgardner> so, at least it didn't regress.
<henrix> tgardner: you tried with or without the patch?
<tgardner> henrix, both. I'll add the info top the bug
<tgardner> to*
<henrix> tgardner: ok. so i guess we can just revert it, right?
<tgardner> henrix, actually, I think we should leave it in for now. its not regressing as far as I can tell, plus it might help the folks that have affected HW
<henrix> tgardner: ok, thanks. let me just ping bjf
<bjf> henrix, i'm watching
<bjf> lurking
<henrix> bjf: yeah, i though so. just referred you name to make sure you would get the notifications :)
<tgardner> henrix, bjf: one thing I should do is rerun with the generic kernel since I think it uses a different I/O scheduler in lucid.
<bjf> tgardner: ack, i'm going to stare at the code a bit
<tgardner> henrix, started the ISO copy with -generic. will let you know the outcome in 20 mins or so.
<henrix> tgardner: ok, thanks
<bjf> tgardner, henrix, this same patch has been in Oneiric since 3.0.0-8.10 (Aug. 5)
 * apw might be sorta back
<tgardner> henrix, bjf: bug #624510 marked verification-done-lucid. see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/624510/comments/64
<ubot2> Launchpad bug 624510 in linux "Copying To USB Is Very Slow" [Undecided,Fix committed] https://launchpad.net/bugs/624510
<ubot2> Launchpad bug 624510 in linux "Copying To USB Is Very Slow" [Undecided,Fix committed]
<bjf> tgardner: ack
<apw> tgardner, any idea what 'tx aggregation enabled on ra = xxx:xxx:xxx:' means?  this is from an iwlwifi
<tgardner> apw, I think is 'high throughput' aggregating packats.
<apw> t
<apw> tgardner, i am unsure if i am any the wiser
<tgardner> apw, it seems like its just an informational blurb
<sforshee> apw, it means acking a block of packets rather than each individual packet
<apw> sforshee, oh so reducing the slots on the channel for ack use, interesting
<tgardner> sforshee, what does it say when it aggregates multiple PDUs into one ?
<sforshee> tgardner, who is "it"? iwlwifi?
<tgardner> sforshee, that, or the mac802.1 stack. is there any indication that HT mode is in effect ?
<sforshee> tgardner, I don't know that there's anything in dmesg, but I think you can query with iw
<tgardner> apw, anymore feedback on your __ticket_spin_lock patch set ?
<apw> tgardner, looks like henrix has also successfully tested it, so i'll ship 'em to the list so you can all weep
<tgardner> apw, ack
 * apw recons on getting fed ... see you tommorrow
<tgardner> ogasawara, how do we target a bug for release noting ? See https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/969304/comments/29
<ubot2> Launchpad bug 969304 in linux-firmware "Regression: Missing Firmware Files phanfw.bin and nx3fwct.bin (precise 12.04 beta)" [Undecided,Incomplete]
<ogasawara> tgardner: nominate for precise and milestone for 12.04 final
<tgardner> ogasawara, but its really an invalid bug
<tgardner> the fix is to update the NIC BIOS
<tgardner> I wanna make the solution gets in the release notes
<ogasawara> tgardner: ah, there's a release notes team, lemme see if I can remember it
<tgardner> ogasawara, apw was teaching henrix how to do it just this AM, but I wan't paying close attaention
<tgardner> ogasawara, maybe skaet knows off-hand how to do it
<henrix> ogasawara: just pick the "also affects project"
<ogasawara> henrix: and then I thought it was ubuntu-release-notes?
<henrix> ogasawara: yep, just "choose another project"
<henrix> ogasawara: and use the ubuntu-release-notes
<ogasawara> henrix: ah, thanks.  I was clicking "also affect distribution"
<henrix> ogasawara: yeah, i spent some time trying to figure out how to do it
<henrix> ogasawara: at the end apw did it for me :)
<ogasawara> tgardner: ok, should be added
<ogasawara> seems odd that it's not a subset of the Ubuntu project, but oh well
<tgardner> ogasawara, hmm, so I should just add something to the comment block ?
<ogasawara> tgardner: I usually update the bug description to contain the release notes text
<tgardner> ogasawara, k, will do
<tgardner> jsalisbury, looks like bug #908279 has a good reproducer and known good/bad kernel versions. since it appears to be a Precise regression, would you care to work with the reporter to bisect the kernel ?
<ubot2> Launchpad bug 908279 in linux-lts-backport-oneiric "vm.dirty_bytes should be set to something sane" [Undecided,New] https://launchpad.net/bugs/908279
<jsalisbury> tgardner, sure thing
<tgardner> jsalisbury, wrong bug, see bug #980279
<ubot2> Launchpad bug 980279 in linux "BUG: soft lockup - CPU#5 stuck for 22s! [xfce4-sensors-p:1873]; EIP is at generic_exec_single+0x66/0x80" [Medium,Triaged] https://launchpad.net/bugs/980279
 * tgardner -> EOD
<jsalisbury> tgardner, that is the same bug :-)
<jsalisbury> tgardner, oops, nevermind
<jcastro> jsalisbury: hey so you responded before I was able to report, but the last test kernel was working and only bailed on me last night, it just took way longer than usual.
<jsalisbury> jcastro, ahh, ok.  thanks for the update.  I'll see if I can bisect further.
<jcastro> ok should I try running the vanilla kernel like you asked?
<jsalisbury> jcastro, it wouldn't hurt to test the lastest precise kernel
<bjf> ogasawara: did pgraner get anywhere on that kernel hang he was getting on friday ?
<Sarvatt> hmm i can only modinfo vesafb on i386, not amd64
<apw> Sarvatt, that makes sense i think ... is vesa valid on 64bit ?
<apw> Sarvatt, actually, i can do it on my 64bit system
<Sarvatt> so just something borked on this one machine, sorry for the noise, thought it might explain why i get text splashes for the past few releases with the blobs :)
<bryceh> would someone be able to roll a kernel build of http://cgit.freedesktop.org/~danvet/drm-intel/?h=drm-intel-next-queued?
<bryceh> (I also emailed apw that this is apparently the new drm-intel-* branch of the month, that would be worth auto-building)
#ubuntu-kernel 2012-04-17
<apw> bryceh, those people are maddening, can't they keep their branch still for one day ?
<bryceh> apw, I know it seems like we set up these auto builds, we use them twice, and then Intel's off on some new branch
<smb> morning
<apw> bryceh, so this replaces drm-intel-next as we call it
<apw> smb, moin
<RAOF> What, there's *another* drm-intel-next?
<bryceh> apw, essentially.  There is still a drm-intel-next branch, but I gather that it's more of a stable snapshot of the drm-intel-next-queue thingee
<bryceh> RAOF, tis the season
<apw> bryceh, i guess the question i am asking is what do you want it called :)
<bryceh> RAOF, you might have noticed our drm-intel-* mainline builds became stagnant
<RAOF> I did, in fact.
<bryceh> RAOF, daniel vetter now maintains them, but in some new branches
<RAOF> :)
<bryceh> apw, what would you think if we just called these as 'drm-intel-experimental' henceforth?  And then just map that to whatever branch-of-the-month Intel is pointing folks to?
<apw> bryceh, sounds like a plan to me, as they cannot make a common name we'll have to do it for them
<ppisati> moin
 * smb proposes drm-intel-toad
<bryceh> I expect we'll have to tinker that when they get new maintainers, but hopefully that's not more than once every year or two
<apw> drm-intel-ygiagam ?
<smb> ppisati, ciao
<smb> apw, tml
<apw> bryceh, ok we have three at the moment:
<apw> drm-intel-next: git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel drm-intel-next
<apw> drm-next: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 drm-next
<apw> drm-intel-fixes: git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel drm-intel-fixes
<bryceh> the second should still be valid
<bryceh> the other two need changed.  maintenance was handed from ickle over to daniel vetter.  Use the git links from my email.
<bryceh> so, we should have a new drm-intel-next, the existing drm-next, and a new drm-intel-experimental.
<bryceh> technically, drm-intel-fixes still exists; it's maintained by keithp now, however I think it's not of very much interest for our purposes.
<apw> bryceh, so now there are 4 ?
<bryceh> yes
<apw> bryceh, the list you have sent me has a drm-intel-fixes ?
<apw> also with danvet
<bryceh> apw, yeah just ignore that.  drop drm-intel-fixes, add drm-intel-next-queued (as drm-intel-experimental)
<apw> ok
<apw> bryceh, ok i think they are building now ... we'll know in an hour what it built
<bryceh> apw, excellent thanks
<bryceh> apw, meantime, I've posted a handful of gpu lockup reports that have mainline kernel patches pointed out as fixes
<apw> bryceh, remind me of that tag agin
<bryceh> apw, bugs are tagged 'kernel-handoff-graphics', and should show up on the report at http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_graphics_bugs_.html, but they're not there yet
<bryceh> apw, they'll all be titled like "GPU lockup blah IPEHR: 0x7....."
<bryceh> I spot checked half of them and the patches seem to be upstream in linus' tree so hopefully should be ripe for picking.
<apw> bryceh, can we not just stop supporting sandybridge it cannot need any more patches, really it can't :)
<bryceh> true, it's getting long in the teeth, we might be able to just declare it obsolete
<bryceh> I wish they showed their work for going from the i915_error_state to a given patch.  But at least they're responding quickly.
<ohsix> you can ask them :]
<ohsix> #intel-gfx
<ohsix> but basically it's in the documentation, except when it's not; they find out an opcode that interlocks or something and locks up one of the rings
<ohsix> and races
<apw> bryceh, fix for bug #982410 seems to have come down via stable already
<ubot2> Launchpad bug 982410 in xserver-xorg-video-intel "[sandybridge-gt1] False GPU lockup render.IPEHR: 0x7a000003" [High,Confirmed] https://launchpad.net/bugs/982410
<bryceh> apw, hmm, I wondered about that
<apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/ <-- bryceh 
<bryceh> yay, thanks apw!
<apw> smb, unity ... again ?
<smb> apw, ?redo from start?
 * apw is getting about his 4th unity update of the week, some freeze
<smb> Ah
<smb> Could it be that this time the glibc/gcc nochange upload caused everything to no-change rebuild?
<ohsix> freezes are fiction for superfeatures!
<apw> its a good job the kernel isn't important
<ohsix> did sam ever sort out that whole post .8 being poopy thing
<apw> ohsix, e-no-parse :)
<ohsix> compiz .8 -> .9 was horrific
<ohsix> i still can't look at it or it will crash on me
 * apw tries not to notice compiz is running
<ohsix> i utilize it pretty good, adjusting was tough; there's still some broken stuff, aside from teh crashes
<ohsix> edge snapping and stuff is broke, some of the plugins don't even work right anymore, windows wobble on focus changes
<ohsix> the preference migrator never worked either, had to manually translate the settings, a lot of them were plain gone
<ohsix> never worked = "x has encountered a problem", and compiz apoplexy
<apw> bryceh, ok the ones i can find on this list, there are actually three fixes, one we already have and two others which i have/am producing test kernels for
<apw> bryceh, ok drm-intel-next has also updated ... so i think they are all working
<apw> sforshee, bug #934707 seems to be another one of those affected by the backlight changes; i think you had some of those on your plate ?
<ubot2> Launchpad bug 934707 in linux "emachine e725 boots to valid display with no backlight" [High,Confirmed] https://launchpad.net/bugs/934707
 * ppisati -> lunch
<sforshee> apw, sounds like yet another broken bios. I'll take a look.
<apw> sforshee, thanks
 * ogasawara back in 20
<apw> diwic, ok just tested that mumble.  it seems to not change still
<diwic> apw, mumble mumble...in both meanings
<apw> diwic, hehe
<apw> diwic, seems to be using the snowball whatever i do now with it on Default
<diwic> apw, I will run some tests here and see if I can confirm what's happening
 * ppisati -> out for some grocery, back in~30
<bjf[afk]> ogasawara: did pgraner get anywhere on that kernel hang he was getting on friday ?
<ogasawara> bjf[afk]: I don't believe so, and I wasn't able to get in.
<pgraner> bjf, no you said you were going to work on it, I was traveling remember
<bjf> pgraner: ogasawara, have not been able to get to the console, tried *many* times
<pgraner> bjf, let me try
<bjf> pgraner: am trying again right now
<ogasawara> apw, bjf, cking, herton, jsalisbury, henrix, ppisati, sforshee, smb: fyi, top ten mumble call is mandatory today (ie 15min from now)
<smb> ogasawara, k
<apw> ogasawara, heh ... such notice :)
<ogasawara> apw: the calendar event somehow went to /dev/null
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<bjf> pgraner: "Error while getting the list of open Targets, please try again in a few seconds."
<pgraner> bjf, same for me
<pgraner> bjf, I'll power cycle it and see if that helps
<bjf> pgraner: ack
<pgraner> bjf, no joy for me you try
<bjf> pgraner: trying ...
<bjf> pgraner: same error
<pgraner> bjf, precise?
<bjf> pgraner: yes
<pgraner> bjf, did icedtea get updated recently?
 * pgraner don't know
<bjf> pgraner: there was an upload on 4/10
<pgraner> bjf, hmmm I've used it since then
<pgraner> bjf, it works on my precise laptop but not on my desktop
<bjf> pgraner: sweet
<bjf> pgraner: i'm trying a different system, can you release the console
<bjf> pgraner: got a console up but "No video from target server"
<pgraner> bjf, that means its powered down, just kick with with the pdu
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 24th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<bjf> pgraner: i've power cycled it twice, no change. i'm using: http://192.168.22.5/main.html?1,1  outlet: A5
<pgraner> bjf, hmmm
<pgraner> bjf, that the right PDU & Port
<pgraner> bjf, let me try and get in over the IPMI bmc
<bjf> pgraner: ack, i've close the console
<pgraner> bjf, I think that box might be dead
<pgraner> bjf, try connecting to node1 you should see stuff on the screen
<bjf> pgraner: that sucks
<pgraner> bjf, just to make sure your config is indeed working
<bjf> pgraner: yup, it's working
<pgraner> ok, let me go have someone hit the pwr switch 
<ppisati> bug 984180
<ubot2> Launchpad bug 984180 in linux-ti-omap4 "ext2 module missing from fs-core-modules udeb." [High,Triaged] https://launchpad.net/bugs/984180
 * jsalisbury curses at thunderbird
<ogasawara> ppisati: I assume the fix you sent for 984180 needs uploading asap?
<ppisati> ogasawara: yes, if possible
<ogasawara> ppisati: I'm also going to fixup the commit to insert the BugLink
<ppisati> ogasawara: ouch, right
<orated> Hello! I tried Canonical/Ubuntu image for running Ubuntu11.10 on Beagleboard B4. The image I used was - http://cdimage.ubuntu.com/releases/11.10/release/ubuntu-11.10-preinstalled-desktop-armel+omap.img.gz - and followed https://wiki.ubuntu.com/ARM/OmapNetbook but I see a blank screen on gtkterm. Is there anything I'm missing?
<ppisati> orated: uhm, strange
<ppisati> orated: that's an old release
<ppisati> orated: what do you see on the terminal screen?
<orated> I tried booting the SD card and I could see nothing on gtkterm or any other serial terminal. The ports are configured right
<ppisati> orated: then chances are you dd-ed wrong on the sd
<ppisati> orated: or the sd has problems
<ppisati> zcat $imgfile | sudo dd of=/dev/$sdX bs=64k
<ppisati> orated: try like that
<ogasawara> ppisati: uploaded
<ppisati> ogasawara: thanks
<orated> ppisati: The command I used was - gunzip -c ubuntu-11.10-preinstalled-desktop-armel+omap.img.gz | sudo dd bs=4M of=/dev/mmcblk0-
<ppisati> orated: dd bs=4M of=/dev/mmcblk0  ?!?!?
<ppisati> orated: ls -la /dev/mmcblk*
<orated> Yes, my SD card is detected like that - Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes.
<orated> brw-rw---- 1 root disk 179, 0 2012-04-18 00:42 /dev/mmcblk0
<orated> brw-rw---- 1 root disk 179, 1 2012-04-18 00:42 /dev/mmcblk0p1
<orated> Sorry, one moment
<orated> ppisati: http://pastebin.com/x1ChZWKQ
<orated> .. is the correct one. 
<ppisati> orated: what do you see when you turn on the board?
<orated> Nothing, just a blank screen. I switched on the board with both reset and User1 depressed
<orated> I mean turning on while holding User1 button
<ppisati> orated: beagle look for the bottloader in the internal flash IIRC
<ppisati> orated: wait
<orated> You mean the bootloader of the board is required to be reflashed?
<ppisati> orated: http://code.google.com/p/beagleboard/wiki/BootingBeagleBoard
<ppisati> orated: if you don't see anything when you turn on the board, then yes
<orated> nand erase won't work?
<orated> ah, got it. Thanks ppisati
<orated> ppisati: Are you still there?
<bryceh> apw, moar gpu lockups.  #982251 looks worth tending on the kernel side.
<bryceh> apw, surprised none of these are showing up still on http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_graphics_bugs_.html
<ogasawara> Ooo, german
<ogasawara> bryceh: I think apw is probably away at the moment, or at least he should be.  I'll get a test kernel posted.
<ogasawara> bryceh: I believe jsalisbury mentioned issues with reports on cranberry (running out of space).  likely explains why the report is not getting updated as I think they've been turned off for the time being.
<jsalisbury> bryceh, ogasawara, correct.  cranberry is out of disk space.  I opened an RT ticket a week ago.  The reports on people.canonical.com should still work.
<bryceh> ogasawara, jsalisbury ah
<jsalisbury> bryceh, This one should be up to date:
<jsalisbury> http://people.canonical.com/~kernel/reports/_kernel_graphics_bugs_.html
<bryceh> aha that looks better
<jsalisbury> This is the top level for all the reports:
<jsalisbury> http://people.canonical.com/~kernel/reports/
<bryceh> 982415 also looks worthwhile to do a kernel for, if there isn't already one with this patch
<ogasawara> bryceh: ack, will investigate
<ogasawara> bug 982415
<ubot2> Launchpad bug 982415 in linux "[i915gm] False GPU lockup render.IPEHR: 0x3f800000" [Undecided,Confirmed] https://launchpad.net/bugs/982415
<bryceh> ogasawara, thanks
<balloons> can someone confirm/deny pae kernel for precise?
<balloons> right now it seems I can't install the current daily iso on non-pae hardware.. I thought we kept non-pae support for this cycle
<ogasawara> balloons: we kept support, but the installer was changed to default to the pae kernel.  there's a few alternative options... you could use the mini.iso which I believe uses the non-pae kernel by default, also I think Xubuntu does as well.  Or you could install Oneiric and upgrade to Precise.
<balloons> ogasawara, thanks for the response.. the only discussion I had seen on it was we were keeping support for it
<balloons> so I was surprised to find it not working
<ogasawara> balloons: there was a long thread on ubuntu-devel I think.  lemme see if I can find it for you
<ogasawara> balloons: and it was raised on the tech board as well
<ogasawara> balloons: tech board minutes -> https://wiki.ubuntu.com/TechnicalBoard/TeamReports/11/December
<ogasawara> balloons: ubuntu-devel thread -> https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034399.html
<balloons> ogasawara, awesome.. I'll go read
<ogasawara> balloons: the tech board minutes highlight the outcome and is more digestible than the mailing list thread
<balloons> thank you much
 * ogasawara wanders off for a bit
#ubuntu-kernel 2012-04-18
<brendand> apw - hi
<brendand> can someone have a look at this bug? https://launchpad.net/bugs/984387
<ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [Undecided,Confirmed]
<brendand> potential -proposed regression
<brendand> probably a duplicate of this: https://launchpad.net/bugs/974412
<ubot2> Launchpad bug 974412 in linux "System fails to boot after kernel upgrade to 3.0.0-18" [High,Incomplete]
<ppisati> moin
<smb> brendand, The second bug report does not really have useful information (like the stack trace), the first one has though the top part is missing and the question marks in the stack trace indicate that the locations printed may not be reliable. If they were it would look like a failure in the ite-cir (infrared dongle) driver.
<smb> ppisati, morning
<brendand> smb - by the second one, you mean the second one i pasted (i.e. the original?)
<smb> yes
<brendand> smb - right, yes the second one was raised agains the 3.0.0-18 kernel by someone from the community. it seems he was asked if he could test with 3.0.0-19 but didn't give a reply. we're still seeing it in 3.0.0-19
<smb> brendand, Does this Dell have a infrared receiver built-in?
<brendand> smb - i imagine so. we avoid using peripherals at all in our testing if possible
<smb> brendand, If it could be disabled in bios it might be a way to verify the crash is related to that (or blacklist the ite-cir module)
<brendand> smb - i'll ask the lab engineer to do that. we'll get an answer later today
<ppisati> brb
<pgraner> apw, ping
<pgraner> sforshee, they look like this
<pgraner> Apr 18 08:34:43 slickback kernel: [37846.980171] mei 0000:00:16.0: unexpected reset.
<pgraner> Apr 18 08:35:13 slickback kernel: [37877.030615] mei 0000:00:16.0: unexpected reset.
<pgraner> Apr 18 08:35:43 slickback kernel: [37907.081084] mei 0000:00:16.0: unexpected reset.
<smb> pgraner, Out of interest, what would be pci 16.0? The generic chipset or something else?
<pgraner> smb, here you go
<pgraner> 00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller
<pgraner>  #1 (rev 01)
<pgraner> 00:16.3 Serial controller: Intel Corporation Panther Point KT Controller (rev 01
<pgraner> )
<smb> pgraner, Thanks, so coming out of the management controller. Still could be a result of something else
<cking> pah, my AP needs some attention.. monthly reboot methinks
<apw> cking, monthly ... i wish
<brendand> smb - blacklisting ite-cir does stop the XPS 1340 from crashing
<ogasawara> brendand: just commented to bug 984387, can you confirm if you see the same issue in Precise?
<ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [Undecided,Confirmed] https://launchpad.net/bugs/984387
<smb> brendand, So its is coming from there... I did not see a change in drivers/media thoug some in staging/media/lirc... 
<ogasawara> smb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/972723/comments/11 different bug, but looks like the same issue but seen on Precise
<ubot2> Launchpad bug 972723 in linux "linux 3.2.0-18 - 22 kernel panic on boot, Alienware m17x, Dell xps 1340" [Medium,Confirmed]
<smb> ogasawara, True, just reading trhough them
<brendand> ogasawara, ok, turns out we've been seeing it in precise before
<brendand> what are we going to do about oneiric though?
<ogasawara> smb: analysis from an affected user there indicates it's a race in the ite-cir driver which seems to be triggered more frequently due to a fix from upstream stable
<smb> ack
<ogasawara> brendand: well, considering Precise it about to go out the door in 1 week, I'd like to get it fixed there asap.  Oneiric possibly has more wiggle room.
<brendand> ogasawara, ok, i meant in terms of the SRU. the problem is only present in -proposed it would appear
<smb> ogasawara, The analysis sounds quite likely
<ogasawara> brendand: for Precise, I'd propose rather than backing out the patch from upstream stable, we temporarily disable the broken driver.
<ogasawara> brendand: for Oneiric, I'd want to consult with herton, henrix, and bjf
<brendand> ogasawara, sounds ok. the ir reciever is not something we certify anyway so it won't block certification
<ogasawara> brendand: how many other systems in the lab does this affect on Precise?
<brendand> ogasawara, no others that i know of. to be honest we haven't done a full test across all systems for precise yet
<ogasawara> brendand: you haven't?  I assume it's going to happen between now and final release though yes?
<brendand> ogasawara, no - not for every system until final release next week
<ogasawara> brendand: hrm, seems there's an error in the process, as how are we going to be aware of any issues if it isn't tested until after the release goes out?
<ogasawara> brendand: anyways, would you guys be able to do a test of a Precise test kernel if I built one for you?
<brendand> ogasawara, yes
<brendand> ogasawara, we have a tool which attempts to calculate the best coverage for us with as few systems as possible. it of course has some weaknesses so we can discuss it at UDS using this case as an example of why it might not be entirely effective
<ogasawara> brendand: ack.  I thought at the previous UDS we did indeed agree that testing a subset of systems was reasonable through the Alpha's and even Beta-1.  But I thought that you'd at least start doing to a full run of tests against all systems as of Beta-2.
<brendand> ogasawara, maybe there was some confusion there. bring it up at the UDS session about 12.10 testing
<ogasawara> skaet: ^^ fyi 984387 also affects Precise.  I can get a fix and have brendand test asap, but it would then require an upload.
 * skaet looking
<skaet> ogasawara,  prep it up and test it - add to zero day SRU set.     So we have the option to react quickly,  prefer not to change the kernel at this point.
<ogasawara> skaet: ack
<skaet> if at all possible.
<ogasawara> skaet: alternative solution would be to blacklist the driver for now in module-init-tools
<ogasawara> skaet: but I'd prefer to keep it to the kernel if possible
<skaet> ogasawara,  that might well be worth considering.
<pgraner> smb, http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/DOCS/Implementation%20and%20Reference%20Guide/default.htm?turl=WordDocuments%2Fconnectingwiththeintelmeidriver.htm
 * ogasawara back in 20
<brendand> bjf, herton - have you been informed of the ir driver bug affecting the oneiric -proposed kernel?
<henrix> brendand: yeah, we're looking at it atm
<bjf> brendand: did the tracking bug get updated with the info ?
<brendand> bjf - i was just waiting for some feedback, i'll update it now
<ogasawara> brendand: Precise test kernel -> http://people.canonical.com/~ogasawara/lp984387/i386/
<ogasawara> bjf: just fyi, patches -> http://people.canonical.com/~ogasawara/lp984387/
 * cking reboots
<henrix> ogasawara: have you seen the comment #5 in bug #972723?
<ubot2> Launchpad bug 972723 in linux "linux 3.2.0-18 - 22 kernel panic on boot, Alienware m17x, Dell xps 1340" [Medium,Confirmed] https://launchpad.net/bugs/972723
<henrix> ogasawara: i was looking through the driver code and it makes perfect sense
 * ogasawara looks
<henrix> ogasawara: the driver is installing an isr *before* being ready to serve an irq
<henrix> this means the bug was there since the begining
<henrix> oh, btw: all the other ir drivers seem to follow the same pattern
<henrix> if you think its worth, i can build a test kernel (oneiric or precise, or both) moving the isr initialisation to a later stage
<ogasawara> henrix: go for it
<henrix> ogasawara: ack
<ogasawara> henrix: we at least have access to the hardware to get it testec
<ogasawara> s/testec/tested/
 * bjf wonders how many other drivers this impacts
<henrix> ogasawara: which one would you prefer to go 1st? oneiric or precise?
<ogasawara> henrix: if we could get precise first, I'd appreciate it
<henrix> ogasawara: ack
<ogasawara> henrix: seems like we have a more urgent time crunch for precise
<henrix> :)
 * ppisati -> goes out for a bit
<brendand> bjf, herton, ogasawara, henrix  - can i assume this is going to result in a respin of oneiric?
<bjf> brendand: it's likely to, yes
<henrix> ogasawara: i have the 32bits test kernel here: http://people.canonical.com/~henrix/lp984387-postponeirq/i386/
<henrix> ogasawara: the amd64 version is still compiling
<ogasawara> henrix: ack, thanks.  I'll get it posted to the bugs.
<ogasawara> hrm, no brendand
<henrix> ogasawara: ah, ok. i though you would ask the guys to test it
<henrix> ogasawara: ah, right :)
<roadmr> hi folks! any way to load a blacklisted module? I pass ite_cir.blacklist=yes on the command line, and after the system boots I'd like to try loading the module, how to undo the blacklist/parameter setting?
<henrix> roadmr: have you tried modprobe ite_cir ?
<roadmr> henrix: yes, it says "error inserting - unknown symbol in module, or unknown parameter"
<roadmr> henrix: dmesg says "ite_cir: unknown parameter 'blacklist'"
<roadmr> henrix: so it looks like the blacklisting works but not for the expected reason :)
<henrix> roadmr: what was the exact command you used?
<henrix> roadmr: i'm not familiar with the 'ite_cir.blacklist=yes' thing...
<roadmr> henrix: sudo modprobe ite_cir
<henrix> roadmr: where did you used 'ite_cir.blacklist=yes'? in grub?
<apw> henrix, he has made an invalid option and that aborts the load
<roadmr> henrix: on the kernel command line I appended ite_cir.blacklist=yes
<apw> henrix, he has mad the option on the kernle command line
<roadmr> henrix: my reference is potentially outdated (8.04): https://help.ubuntu.com/8.04/installation-guide/sparc/boot-parms.html
<roadmr> ah, and sparc. Yes, I suck :(
<henrix> heh
<henrix> right, so better reboot without that option
<roadmr> henrix: the 11.10 i386 guide still says the same, though I'm on Precise so it *may* have changed
<roadmr> https://help.ubuntu.com/11.10/installation-guide/i386/boot-parms.html
<apw> roadmr, i can find no documentaiton on stopping modprobe using the kernel command line overrides once you have added them
<henrix> apw: nice, i didn't new that invalid options would prevent modules from being loaded
<roadmr> henrix: yes, well I'm doing some diagnostics for a crash related to this module, so it's not a big deal, was just curious about how to do this. 
<henrix> roadmr: yeah, i'm aware of it ;)
<roadmr> apw: hmm, thanks for looking into it! as I said, it's not a big deal :) rebooting is OK to "undo" the blacklisting
<roadmr> apw, henrix : thanks :)
<henrix> roadmr: anyway, *in general* the modprobe thingy should work
<henrix> roadmr: i wasn't aware the invalid kernel param would prevent modprobe from loading it
<henrix> roadmr: now we both know that :)
<roadmr> henrix: yes, it works but for the wrong reasons I think :D
<apw> roadmr, you may be able to insmod directly to avoid the issue
<roadmr> apw: yay! ok, I'll try that
<ogasawara> bjf: could I get a second Ack from you for henrix's patch he sent to the mailing list for the ite-cir driver
<ogasawara> skaet: fyi, got positive test feedback for a proper fix for bug 984387.  roadmr also did a quick test against 83 systems in the lab and confirmed 3 variants of Dell XPS's were affected.
<ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [High,Confirmed] https://launchpad.net/bugs/984387
<ogasawara> skaet: no other Dells crashed, nor did any of the Lenovos, Toshibas and assorted others (some Sonys, a few Asus, the odd Sylvania or Samsung)
<skaet> ogasawara, good news.   Thanks.   :)
<bjf> ogasawara: done
<ogasawara> bjf: thanks
<bjf> ogasawara: did he get testing feedback?
<ogasawara> bjf: he did from roadmr
<bjf> cool
<ogasawara> bjf: roadmr also was able to do a quick test against all systems he had access to
<Guest11589> Evening
<Guest11589> Is someone around for a module compiling question?
<Guest11589> I C :-(
<roadmr> Guest11589: feel free to ask, if someone knows / can help, someone will
<Guest11589> Ok, first thing: 3.4 ppa kernels miss one module: DVB_USB_AZ6007 - who's the right person to speak to to enable it for the future?
<Guest11589> Second thing: I tried to enable it myself but I fail compiling it - here's what I did:
<Guest11589> * wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.4-rc3.tar.bz2
<Guest11589> * wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/0001-base-packaging.patch
<Guest11589> * wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/0002-debian-changelog.patch
<Guest11589> * wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/0003-default-configs.patch
<Guest11589> * tar xfvj linux-3.4-rc3.tar.bz2
<Guest11589> * patch -p0 <0001-base-packaging.patch
<Guest11589> * patch -p0 <0002-debian-changelog.patch
<Guest11589> * patch -p0 <0003-default-configs.patch
<Guest11589> * cp /usr/src/linux-headers-3.4.0-030400rc3-generic-pae/.config .
<Guest11589> * make menuconfig
<Guest11589> * make -C /usr/src/linux-headers-3.4.0-030400rc3-generic-pae M=/usr/src/linux/drivers/media/dvb/dvb-usb KBUILD_SRC=/usr/src/linux modules
<Guest11589> It compiles all other modules in that directory fine but not AZ6007. Not even when I copy .config to that headers directory.
<Guest11589> I guess I waited long  enough to know noone in here, who's online, knows something about that.
<JanC> Guest11589: just be patient  ;)
<JanC> Guest11589: most people aren't in here 24/7 (they have a job, social life, need to sleep, etc.), but they might answer if you stay around
<Guest11589> As I've said "...who's online..."
<JanC> well, "being online" doesn't equal "checks #ubuntu-kernel every 15 minutes"  :P
<Guest11589> hehe :-)
<roadmr> Guest11589: I assume you enabled the module in the "make menuconfig" step?
<roadmr> Guest11589: I think the right procedure to get the module enabled in future kernels would be to file a bug in launchpad.net - but kernel changes are approached with a lot of caution, so it can be expected to take a while.
<sforshee> Guest11589, I'd assume that it's using the .config file from /usr/src/...
<Guest11589> working directory has been /usr/src/linux
<Guest11589> yes, I enabled it then
<sforshee> make -C /usr/src/linux-headers-3.4.0-030400rc3-generic-pae
<sforshee> it will use .config from that directory
<Guest11589> That's what I thought, but that .config had my module enabled
<Guest11589> "Not even when I copy .config to that headers directory."
<sforshee> so you copied the .config from your 'make menuconfig' invocation over to that directory?
<Guest11589> yup
<Guest11589> cp /usr/src/linux/.config /usr/src/linux-headers-3.4.0-030400rc3-generic-pae/
<sforshee> oh, wait, that's not enough
<sforshee> because the stuff generated from the .config probably isn't regenerated
<sforshee> that really isn't the way I'd recommend you do it anyway, modifying stuff in the linux-headers package install directory
<sforshee> the shortcut would be to modify the makefile in that directory to use obj-m instead of obj-$(CONFIG_DVB_USB_AZ6007)
<Guest11589> that's the latest: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/dvb/dvb-usb/Makefile
<Guest11589> line 91 needs to be changed to?
<sforshee> obj-m += dvb-usb-az6007.o
<Guest11589> I'll try that... thank you
<sforshee> that will force it to be built as a module no mater what the config says
<dlynes> Is this the correct channel to ask about a problem with a proposed backported kernel?
<cnd> bjf, ogasawara, jjohansen: do you know how to check if a module that is not loaded should be loaded because it handles hardware connected to the machine?
<cnd> I want to load bcm5974 after resume, but only if the trackpad is present in the machine
<cnd> actually, I can get around this a different way
<cnd> hmm... maybe not
<jjohansen> cnd: you mean like a file in /etc/pm/config.d ?
<cnd> sorta
<cnd> I want to rmmod bcm5974 at suspend
<cnd> and modprobe it at resume
<jjohansen> cnd: right, you remove and add by specifying stuff in /etc/pm/
<cnd> what I want is basically SUSPEND_MODULES functionality, but I don't want to add to /etc/pm/config.d from a package
<jjohansen> cnd: hrmm
<cnd> maybe instead of adding a config through xserver-xorg-input-synaptics I should really add it to pm-utils directly
<cnd> since it's not exactly specific to X
<cnd> but I can't see any simple way of making it work without an ugly hack in /usr/lib/pm-utils/sleep.d/75modules
<ohsix> is this related to trackpads going nuts when the display is almost closed?
<cnd> yeah
<ohsix> neat, i knew it wasn't the magnet! :D
<cnd> oh, pm-utils is somewhat careful about things
<cnd> you can add multiple files with their own SUSPEND_MODULES lines
<cnd> and it will concatenate them together
<ohsix> so the device has to be removed entirely? what networkmanager already does on suspend isn't sufficient?
<cnd> ohsix, the easiest way is to remove the device
<cnd> no matter what you do it will be a work around
<ohsix> hm, maybe; has anyone tracked down what the device is actually doing when it's supposed to be inactive? since it's inactive it might be able to be told to stop doing that :]
<cnd> ohsix, I don't know what you mean
<cnd> the device is active
<cnd> and that's part of the problem
<ohsix> i thought networkmanager disassociated and disabled it on suspend
<cnd> this has nothing to do with NM
<ohsix> i'm not saying it does, i'm saying networkmanager already has a role during suspend, what it does with the device should already deactivate it, if the driver still does it when it's deactivated that could be fixed
<cnd> ohsix, how does nm have anything to do with your trackpad?
<ohsix> you proposed to remove the module on suspend, networkmanager disassociates a device and deactivates it on suspend, how much different is that from rmmod'ing the driver?
<ohsix> or. is the broadcom the touchpad driver
<cnd> bcm5974 is the touchpad driver
<ohsix> hurrrrrrrr, ok
<ohsix> i had thought someone had discovered that it's the wifi antenna proximity that messes with the touchpad
<cnd> no
<cnd> it's the screen
<ohsix> ok, that's what i'd suspected
<ohsix> everyone i was talking to insisted it was the magnet, they didnt' belieeeeeeeeve me
<ohsix> is it spread spectrum on the link or something? i think you can still disable that with a module option
<ohsix> the bandwidth and mode is adjustable so if someoen found out that it was, it could probably be massaged for those models
#ubuntu-kernel 2012-04-19
<smb> morning
<ppisati> moin
<ppisati> 204pkgs... uhm...
 * ppisati -> brb
<apw> bryceh, how did things go
<apw> ppisati, 30 for me
 * apw yawns
<bryceh> apw, well jesse recognized the problem as a legitimate kernel issue
<bryceh> apw, but no advice towards a solution so far
<apw> bryceh, is this on irc or on email, shall i submit the patch to start some discussion?
 * ppisati -> reboot
<bryceh> apw, https://bugs.freedesktop.org//show_bug.cgi?id=48894
<ubot2> Freedesktop bug 48894 in libdrm "plymouthd crashed with SIGABRT in __assert_fail_base()" [Major,New: ]
<bryceh> apw, submitting patch upstream would probably be a step forward
<apw> bryceh, is this something you can reproduce?  i could try making it stay in the kernel to see if it papers over it in the short term
<bryceh> apw, none of us X guys have repro'd it afaik
<bryceh> I think it takes "special" hardware that's fast in one part and slow in the other
<apw> i used to be able to repro the open panic way back when i was doing the flicker free boot stuff, on a mini 10, like in lucid, but i've only ever then seen the occasional drop to 'text splash' as a result
<bryceh> I imagine we could rig up some contrived synthetic reproduction
<apw> nothing spectacular every happened.  anyhow, i'll get this shit together as an email submission, as an RFC with request for a cleaner handling of the wait
<apw> i should have done it a year ago ... sigh
<apw> bryceh, so jesse asks us to file a separate bug for the drm core issue here, the crashing on open, did you make one so i can refernece it in the submission?
<apw> bryceh, or are you repurposing this original one.  i suspect you might be, but from an upstream point of view they may prefer a nice clean one
<bryceh> apw, yes, rather I reassigned the bug over to DRM/libdrm
<apw> bryceh, ok i'll use that one to start with.
<apw> smb, moinn
 * apw reboots to get todays crack
<smb> apw, morning
 * ppisati -> out for lunch + post office
<Kano> hi
<Kano> did anybody try the EFI stub on 3.3+? it is disabled in mainline builds
<Kano> i think there was a tool to change the root device of a compiled kernel, but i do not remember it
<Kano> maybe rdev,but this is not available anymore...
 * apw goes splash
 * ogra_ hands apw a towel
<brendand> herton, any news on a respin?
<herton> henrix, ^
<henrix> brendand: we're still waiting for positive feedback on oneiric
<brendand> henrix - anything i can help with?
<henrix> brendand: the patch has been queued into precise
<brendand> henrix - aha, so you'll use the same patch in oneiric. of course
<henrix> brendand: well, if you can reproduce the issue in oneiric, you could test the kernel i posted
<brendand> henrix - i think we have. this is the patch that actually fixes the problem, rather than just avoiding it, right?
<henrix> brendand: yep
<henrix> brendand: if you can test oneiric, cool. if not, maybe we can wait a little bit more and then... that's bjf's call
<brendand> henrix - is there an oneiric kernel with the patch?
<henrix> brendand: yes, let me give you an url...
<henrix> brendand: http://people.canonical.com/~henrix/lp984387-postponeirq-oneiric/
<henrix> brendand: its in comment #13 bug #984387
<ubot2> Launchpad bug 984387 in linux "[Dell Studio XPS 1340] Kernel panic with 3.0.0-19 on boot" [High,Confirmed] https://launchpad.net/bugs/984387
<bjf> moin
<roadmr> henrix: morning! Just tested your fix for the ite_cir problem on Oneiric (kernel 3.0.0-19) - updated on the bug report (it works!)
<henrix> roadmr: great news
<henrix> roadmr: thanks for testing
<roadmr> henrix: no prob :)
<roadmr> brendand: installed wireless drivers on 5575, it's now rebooting to retest
<brendand> henrix - so there you go
<henrix> brendand: :)
<henrix> brendand: thanks.
<jwi> henrix: if you're doing a respin for oneiric, consider picking 'drm/radeon/kms: fix the regression of DVI connector check' from lkml (or reverting the broken patch from current -proposed)
<henrix> jwi: do you have a bug # ?
<jwi> henrix: nope
<henrix> jwi: hmm... so i don't think it will make it into this cycle. what's currently broken on -proposed?
<jwi> henrix: from the patch description, no output on DVI-I to VGA setups
<Kano> hi apw , can you set: CONFIG_EFI_STUB=y
<Kano> apw: just copied it to my boot partition, then: linux.efi root=/dev/sda2 
<Kano> and it booted
<Kano> will try to set this with efibootmgr
 * ppisati -> dinner out tonight, see you tomorrow
 * cking -> EOD
<ogasawara> skaet: when would you like for us to upload our day-0 kernel SRU to precise-proposed?  I was thinking of waiting until Tues in case anything else comes in that would need to be included.  And I didn't want to unnecessarily waste current build resources.
<skaet> ogasawara,  Tuesday sounds like a good point to me.
<ogasawara> skaet: ack
<skaet> Thank you.
<jsalisbury> herton, thanks for updating 968016
<herton> jsalisbury, np, I just got an email that the patch is queued for 3.0 and 3.2 stable, so at least for oneiric/precise we will get it through stable updates I expect
<jsalisbury> herton, great news.  Thanks again!
 * ogasawara lunch
<carli2> hi
<carli2> I need hdmi-sound support in 12.04
<carli2> is there a way to get it in a mainstream way?
<bjf> ogasawara: i just saw greg's announcement of the last 3.2
<bryceh> on bug 974830, kernel patch sounds validated.  
<ubot2> Launchpad bug 974830 in xserver-xorg-video-intel "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x78170003 using Oracle SQL Developer" [High,Fix released] https://launchpad.net/bugs/974830
#ubuntu-kernel 2012-04-20
<smb> morning
<apw> moin
<apw> ogasawara, there is something slightly odd going on on precise master-next.  we seem to have both the disable of ite-cir and what appears to be the fix for it.  noticed cause the config one causes a module loss abi failure (which i've fixed and pushed over), but it likely needs review
<ogasawara> apw: oops, indeed the config disablement shouldn't be in there
<apw> ogasawara, ok well rather than making the push part true when this build finishes i'll let you drop it :)
<apw> ogasawara, and what the heck are you doing awake
<ogasawara> apw: ack, I'll push over the top and get it fixed up
<smb> apw, ogasawara really should be in that padded cell called bed... not only in the mumble channel of that name... ;)
<apw> smb, indeed ...
<ogasawara> apw, smb: I was tending to kai and while sitting in the rocking chair I realized I forgot to mute mumble...
<apw> ogasawara, luckily we tend to dump lurkers in the cell for their own protection
<ogasawara> apw, smb: and so here I am :)
<smb> Indeed we do or put protective gear over the virtual heads
<ogasawara> apw: ok, fixed up master-next and pushed
 * ogasawara checks her day-0 branch
<apw> ogasawara, thanks ... saves me messing it up ...
<apw> ogasawara, oh is that in the repo ?
<orated> ppisati: There?
<ogasawara> apw: only local, although I should push it now that you mention it
<apw> yeah i'd say publish it indeed
<ogasawara> apw: day-0 branch pushed.  basically everything on master-next sans v3.2.15 patches
<apw> ogasawara, presumably we can just rebase the master-next on that and it'll reorder things
 * apw gives it a go
<ogasawara> apw: yep, that's what I'd assume
<ogasawara> apw: we technically don't need the ABI bump, but I threw it on the day-0 just for fall back purposes
<apw> ogasawara, right there _always_ should be an abi bump in the first upload, thats the law
<ogasawara> apw: yep
<ppisati> orated: yep
<apw> ogasawara, ok that rebase just worked
<apw> -linux (3.2.0-24.37) UNRELEASED; urgency=low
<apw> +linux (3.2.0-23.37) UNRELEASED; urgency=low
<apw> leaving that as diff between my new master-next and the origin, so that sounds about right
<ogasawara> apw: cool
<apw> ogasawara, i may as well push it up?
<ogasawara> apw: yah, go ahead
<ogasawara> apw: if we end up throwing anything else on day-0, we can just rebase master-next again and push over the top
<apw> ogasawara, indeed and this is more accurate to the consumer ... pushed
 * apw throws a build test on gomeisa for completeness
<orated> ppisati: Hi, last time you suggested to try zcat $imgfile | sudo dd of=/dev/$sdX bs=64k if ubuntu/cacnonical images for beagleboard is not working. Why bs=64k?
<ppisati> orated: because that's the usual sector size on sd card IIRC
<orated> ppisati: I've seen some wiki suggesting bs=4m like - https://wiki.ubuntu.com/ARM/OmapNetbook 
<ohsix> or a multiple of it, which is way faster than the default bs, 512
<orated> ah-ok
<orated> I still get blank screen on terminal. I have set the gtkterm port configuration BAUD RATE - 115200, DATA - 8 bit, PARITY- none, STOP - 1bit, FLOW CONTROL - none. I'm not sure what I'm missing.. 
<ppisati> orated: do you see the bootloader?
<orated> ppisati: Even for erasing the nand on the BB, I should be able to get something on gtkterm like uboot... It gives nothing
<orated> uboot countdown*
<ppisati> orated: if you erase the flash, then you need to reflash the bootloader before you get something
<ppisati> orated: did you do that?
<ppisati> orated: without a bootloader, the board is not initialized and thus ubuntu won't boot
<orated> ppisati: Yes, I tried that. I followed http://code.google.com/p/beagleboard/wiki/BootingBeagleBoard and the hardware setup to perform Booting u-boot on NAND Flash  but there was nothing on gtkterm/screen like shown in the link for me to able to even start the process
<ppisati> orated: uhm
<ppisati> orated: let me see if i can dig up my beagle
<orated> ppisati: Sorry, pinged out
<ppisati> orated: i've a beagle c4 here, let me see if i can guide you
<orated> Sure ...
<orated> I noticed something different on new attempt now. Apart from having D5 PWR LED, D6,7,12 also glowed for a moment
<ppisati> orated: so, did you fat32 format the sd card and put u-boot on it? 
<orated> yep
<ah-> wc
<ppisati> orated: do you have the sd card mounted now?
<orated> ppisati: I got D6,7 and 12 blinking continuously. Do you want me to remove it from BB now?
<ppisati> orated: yes please, i want to see it's content
<orated> sure
<orated> ppisati: initrd.img  MLO  tools  u-boot.img  uEnv.txt  uImage  uInitrd  zImage -- contents of boot FAT
<ppisati> orated: and it's the result of a cat $img blablabla, right?
<ppisati> orated: which image did you try?
<orated> ppisati: Sorry, that was another card. The output of ls in boot is - boot.scr  MLO  u-boot.bin  uImage  uInitrd and the image tried was - zcat ubuntu-11.10-preinstalled-desktop-armel+omap.img.gz | sudo dd of=/dev/mmcblk0 bs=64k
<orated> command* 
<ppisati> orated: ok, let me get that image so i can try it
<orated> ppisati: Is there a way to test beagleboard to eliminate hardware issues?
<ppisati> orated: there's a validation image somewhere
<ppisati> orated: http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnosticsNext
<orated> ah, I tried http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnostics and http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
 * apw wanders to get hiself shawn
 * ppisati -> goes to pick a package, brb
<pgraner> http://pastebin.ubuntu.com/938244/
<pgraner> apw, http://paste.ubuntu.com/938259/
<smb> apw, I guess it is somewhat clear that udisk triggered a blkid and that got stuck waiting on the bd_mutex. Just not so clear why it happened while a dd was running and whether it was the dd holding the mutex while writing...
<apw> smb, indeed, clear that blkid is looking at the partition in lock step with the dd doing someting ... not sure why it would get stuck tho
<smb> apw, Interestingly it were two blkid tasks getting into that problem and then got killed... And yes, bd_mutex should not be claimed by anything so long... Wonder whether something left it in a claimed state by accident...
<apw> smb, or perhaps there is a mutex orering issue.  can we tell if they are on the same partitions?
<smb> apw, Both seem to be for /dev/sdc
<apw> hmmm.  odd indeed.  i wonder if it bounced
<apw> like inserted, came out, reinserted perhaps triggered a scenario like your suspend one
<apw> i wish udev kept a log always
<smb> Yeah, well one other thing may be: dd starts and creates a new partition table, <something> looks at the disks and decides "oh lets run rereadpt on that"
<apw> BAH this damn update has eaten my keyboard config and now i can't find the backslash key
<smb> apw, ctrl-alt-Ã won't help you there...
<apw> smb, i though partition re-read was an ioctl, something you had to initate, i'd be supprised if we detected that
 * apw doesn't have a 'shhhh' key...
<smb> apw, its a ss key... ;)
<smb> apw, yes, rereadpt it an ioctl... but then as we learned there is a lot of things running and looking at our devices behind our backs... :/
<smb> usually it would be the other way round... rereatpt causes events which cause blkid to be called
<apw> ahhh ... /me finds it .. on a US keyboard in UK mode with no actual |\ key .. there are backup | and \ keys on altgr-backtit and altgr--
 * apw likely has to logout to fix this ... grrr
<apw> smb, i even have a Ã key it seems
<apw> wild
<smb> apw, Maybe you got a de keyboard now
<smb> is your z at the right place?
<apw> heh ... no its a UK layout .... just it has some extra altgr's for .eu things it seems
<apw> ~~~~~
<apw> Ã£
<apw> Ã£
<smb> apw, Aynway hm, dpending how quick pgraner was maybe the blkid's running are remainders of the initial detection which udev still was processing ...
<apw> i even have a compose thingy ... how useless for me
<apw> smb, two on the same device sounds wrong
<smb> apw, They came after each other
<smb> blkid (blocked) .... killed , next out (blocked) ... killed
<smb> apw, Something else, now that we both got our acks, who is gonna commit first? :)
<apw> smb, you can commit both if you like
<smb> apw, all three you mean :)
<apw> or i can commit both, thats the logical one
<apw> ... you are clearly the one in the know ... i nominate you
 * smb profoundly thanks apw
 * ogasawara back in 20
<apw> ppisati, when we make arm branches for Q we need to garbge collect the numbers back to -100
<apw> ppisati, else we'll hit like 10000000 
<ppisati> apw: version number overflow? :)
<apw> ppisati, in a year or two :)
<ppisati> -EVERSIONNUMTOOBIG
<bjf> Quasimodo
<cking> bjf, your Q namespace will run out soon
<gema> ppisati: are you around, I have a pandaboard making lights at me that I am not sure how to interpret
<gema> ppisati: what does it mean when led D1 does two quick flashes and then repeats ad infinitum the same thing
<GrueMaster> gema: It means the system is running.  It is just the led_heartbeat driver.
<gema> GrueMaster: but the system is not running, it is stuck on uncompressing the kernel
<GrueMaster> Which image?
<gema> desktop
<GrueMaster> Do you have a monitor plugged in to the HDMI port?
<gema> I have a monitor and the serial
<gema> both working fine
<GrueMaster> Has it worked with the panda on previous images?
<gema> GrueMaster: last thing the serial said before dying was: Uncompressing Linux... done, booting the kernel.
<gema> which is why I was asking ppisati :D
<gema> GrueMaster: I have installed it yes
<gema> it went through the install fine, it is on reboot that's stuck
<GrueMaster> That is a very generic kernel message that all platforms spit out.  You could enable the serial console to see if there are kernel issues.
<gema> well, that is (I thought) the serial console
<GrueMaster> The process is on the wiki.
<gema> the wiki doesn't document error situations
<GrueMaster> The serial console is not enabled by default on the desktop images.  Never has been.
<gema> and I believe I am on an error situation
<gema> so what comes through by default on the desktop images through the serial?
<GrueMaster> U-boot messages.
<gema> that makes sense
<gema> how do I enable the serial console then?
<gema> whenever I manage, to boot, I guess
<GrueMaster> You can strip the u-boot header from the boot.scr and edit it.  Then use mkimage to put it back.
<GrueMaster> I am looking through the wiki.  The instructions seem to have been buried.
<gema> I am only looking at instructions linked from the iso tracker
<GrueMaster> They were on wiki.ubuntu.com/ARM/<somewhere>
<gema> now I 've got a disco, both lights are jumping up and down
<GrueMaster> But I haven't updated them in months.
<gema> GrueMaster: ack
<GrueMaster> Well, since I can't seem to find the wiki, I'll just start typing.
<GrueMaster> First, on your desktop with SD inserted and first partition mounted, type "dd bs=72 skip=1 <SD>/boot.scr boot.script".
<GrueMaster> Then add "console=ttyO2,115200,n8 console=tty0" to the boot cmdline.
<gema> GrueMaster: found it somewhere else: They are just programmable LEDs, named STATUS1 and STATUS2. By default, the kernel assigns trigger 'heartbeat' to the STATUS1 LED and trigger 'mmc0' to the STATUS2. This means that STATUS1 will blink twice per second, and STATUS2 will indicate activity on the SD card
<GrueMaster> Yes.  That is correct.
<GrueMaster> I thought you were having boot issues though?
<gema> I am
<gema> but the lights are not really helpful
<gema> :D
<GrueMaster> Do you want the rest of my instructions on adding serial console output?
<gema> GrueMaster: I'd like them better on a wiki
<gema> cos here I will lose them
<gema> GrueMaster: sorry I am multitasking a bit
<GrueMaster> Well, I had them on a wiki for a long time.  Someone else either deleted them or moved them.  I don't currently have the time or motivation to re-edit the wiki.
<gema> GrueMaster: no worries, I will find them if they've been there, thanks
<GrueMaster> gema: https://wiki.ubuntu.com/ARM/EditBootscr
<gema> GrueMaster: thanks
<GrueMaster> btw:  Desktop is running fine here.  Now booting today's image.
 * cking runs a bunch of updates and then puts his server into deep soak test for the weekend..
<jsalisbury> Anyone else having an issue getting into tangerine?
<ogasawara> apw: just fyi, I'm beginning to add stub blueprints and wiki page specs -> https://wiki.ubuntu.com/KernelTeam/Specs
<ogasawara> apw: I figure we can fill in the actual content next week-ish
<ogasawara> jsalisbury: same here (for both tangerine and gomeisa)
<apw> ogasawara, sounds good to me
<jsalisbury> ogasawara, thanks for confirming.  I'll open a RT ticket
<apw> ogasawara, fyi all gomeisa and tangerine are mia right now
<apw> jsalisbury, ahh yes, i am talking to them now on #is
<apw> jsalisbury, there is some cabling going on or something and we should not be affected but are
<jsalisbury> apw, ahh, ok.
 * cking --> EOD
<ogasawara> jsalisbury: for the scripts which were running on cranberry, did you guys just temporarily disable your cron jobs?
<aboSamoor> Hi, can someone help me with this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986321?
<ubot2> Launchpad bug 986321 in linux "READ/Write FPDMA QUEUED failures" [Undecided,Incomplete]
<herton> jjohansen, hi, there is some lucid tracking bugs awaiting for security-signoff, I think they are on the way to be checked?
<apw> aboSamoor, i think we'd need at least a dmesg from teh system to have any idea what we are looking at
<aboSamoor> apw: does the logs have the dmesg. I generated the logs using ubuntu-bug
<aantoon> hi, will 12.04 alternate support ssd+trim+luks out of the box or do I have to do some tweaking
<jjohansen> herton: okay, give me a bit I have been revising the scripts so, I am behind on the security-signoff
<aantoon> knock knock
<aantoon> I would love an answer 
 * ogasawara lunch
<aantoon> hi, will 12.04 alternate support ssd+trim+luks out of the box or do I have to do some tweaking
<bjf> aantoon, have you tried a daily-live image ?
<bjf> aantoon: i believe that it should have that support but if you want to know for sure you need to test
<aantoon> last test (ubuntu 11.10) i lost my partition table and could not recover using testdisk so i lost all my data
<jsalisbury> ogasawara, no, the scripts are still running, the reports just are not accurate.
<aboSamoor> jsalisbury: I updated bug 986321 with apport-collect
<ubot2> Launchpad bug 986321 in linux "READ/Write FPDMA QUEUED failures" [Medium,Confirmed] https://launchpad.net/bugs/986321
<jsalisbury> aboSamoor, thanks.  I'll take a look.
<aantoon> I have a new computer that has an Intel SSD. I have some questions about using Ubuntu with an SSD that I hope ubuntu developers can answer for me. I've researched online but do not know how best to proceed as there seems to be differing advice. I see it mentioned online that I should mount with DISCARD. But an article from OpenSUSE says DISCARD is not good to use. 
<aantoon> http://opensuse.14.n6.nabble.com/SSD-detection-when-creating-first-time-fstab-td3313048.html
<aantoon> Here are my questions
<aantoon> 1.) are there any issues I should be aware of if using ubuntu on an SSD? Is ubuntu primarily intended to be used on HDD and not recommended for SSD?
<aantoon> 2.) do you recommend TRIM be used for SSD with ubuntu?
<aantoon> 3.) If you do recommend TRIM be used, how should TRIM be setup? Automatic wiping, or manual wiping? FITRIM, FSTRIM, or DISCARD?
<aantoon> I really don't understand any of this in depth, so I'm very thankful for any direction/guidance you can provide
<aantoon> i copyed this from archives/ubuntu-devel-discuss and it is the same questions i have
<aantoon> the mail was not answered so i thought i'll ask it here
<aboSamoor> jsalisbury: do you have an idea what does the flags NCQ and pcie_aspm mean?
<jsalisbury> aboSamoor, pcie_aspm has is replated to power management.  Here's a good blog about it:
<jsalisbury> aboSamoor, http://smackerelofopinion.blogspot.com/2011/03/making-sense-of-pcie-aspm.html
<jsalisbury> aboSamoor, NCQ is "Native Command Queuing"
<jsalisbury> aboSamoor, your running a server correct?  If so, changing pcie_aspm may not help.
<aboSamoor> jsalisbury: I am running ubuntu server 12.04
<aboSamoor> jsalisbury: this bug report, mentions two solutions https://bugzilla.kernel.org/show_bug.cgi?id=32682
<ubot2> bugzilla.kernel.org bug 32682 in Serial ATA "libata freeze randomly hangs disk I/O" [High,New]
<aboSamoor> jsalisbury: it seems that NCQ has something to do with the problem. testing more to confirm that
<jsalisbury> aboSamoor, thanks for the info and update.
<jsalisbury> aboSamoor, I saw a discussion on LKML on an issue similar to this.  I'll post a link in the bug.
<aboSamoor> jsalisbury: echo 1 > /sys/block/sdX/device/queue_depth helps with small loads as copying hundreds of MiBs but not with large copying
<jsalisbury> aboSamoor, Does changing the queue_depth reduce the number of errors or help improve performance?
<aboSamoor> jsalisbury: it reduces the number of errors I see in syslog
<jsalisbury> aboSamoor, Hmm, that may be due to less I/O actually being performed
<aboSamoor> looking at the queue depts in my ~30 hard disks, I find half of them with the value 31 and others with the value 1!
<jsalisbury> aboSamoor, Would it be possible for you to test some earlier kernels to see if this bug is a regression, or if it always existed?
<aboSamoor> jsalisbury: point me to the kernels that you want me to test
<jsalisbury> aboSamoor, sure thing.  I'll post links in the bug 
<aboSamoor> jsalisbury: do I have to do anything other than adding that line to the file http://ubuntuforums.org/showpost.php?p=9684933&postcount=12 ? how can I test that it took effect?
<jsalisbury> aboSamoor, You need to run sudo update-grub and reboot as well
<jsalisbury> aboSamoor, You can then look at /proc/cmdline after rebooting to see if it took effect
#ubuntu-kernel 2012-04-21
<orated> Hello! I would like to know what exactly does it mean to have an OS ported to another machine/instrument?
<hyperair> it depends on the machine.
<hyperair> on a machine with a completely different instruction set, it could mean that you need to implement all the handwritten assembly, and fix cross-platform issues.
<hyperair> otherwise it could just mean getting hardware to work
<hyperair> writing drivers that don't exist, for example
<orated> Gotcha. Could you give an example when there comes a case where the application/OS is required to is not cross-platform?
<wrostek> Is there anyway to set wifi power management off ( without using iwconfig )?
#ubuntu-kernel 2012-04-22
<wrostek> Anyone know how to disable wifi power management?  On my card, DWA 552 ATH9K, when I use iwconfig wlan0 power off , I just get the error Error for wireless request "Set Power Management" (8B2C) :
<skaet> bjf, ogasawara, jsalisbury - bit worried about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986797 (and related) that just showed up on the tracker.    Any preliminary thoughts?
<ubot2> Launchpad bug 986797 in linux "package linux-image-3.2.0-23-generic 3.2.0-23.36 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 2" [Undecided,Confirmed]
<ogasawara> skaet: looking at VarLogDistupgradeApttermlog, I'm seeing the following:
<ogasawara> run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
<ogasawara> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
<ogasawara> run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
<ogasawara> Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.2.0-23-generic.postinst line 1010.
<ogasawara> dpkg: error processing linux-image-3.2.0-23-generic (--configure):
<ogasawara>  subprocess installed post-installation script returned error exit status 2
<ogasawara> skaet: which looks to actually indicate something going wrong with grub-probe
<skaet> ogasawara, probably best to comment on it, and mark it as a duplicate of https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/986791 then?   (which came in at same time) ?
<ubot2> Launchpad bug 986791 in grub2 "package grub-pc 1.99-21ubuntu3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<skaet> or maybe not....
<ogasawara> bug 916077
<ubot2> Launchpad bug 916077 in grub-installer "grub-install - /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?)." [Undecided,Confirmed] https://launchpad.net/bugs/916077
<ogasawara> skaet: ^^ that seems a better master bug
<skaet> ogasawara,  agreed. 
<ogasawara> skaet: am posting a comment to 986797
<skaet> ogasawara,  thanks. :)   Can you set the priority too?
<ogasawara> skaet: yep
<skaet> :)  ta
<ogasawara> skaet: I have to drop off for a bit (lil guy is getting up).  I see you've already brought it up in ubuntu-release.  Will check back in later.
<skaet> Thanks ogasawara   :)   l8r
<uzf> How do I check to see if Video4Linux is enabled in my kernel?
<johanbr_> uzf, grep V4L /boot/config/$(uname -r)
<uzf> it appears that everything is
<uzf> is there like a v4l setup tool?
<uzf> my dvb card any idea why my dvb card only shows "[   28.195941] saa7146: register extension 'dvb'." when I issue dmesg|grep dvb ?
<johanbr_> uzf, setup is done in the applications
<uzf> my card doesn't show up in lspci and there is no /dev/video or /dev/dvb.. hmm
<dileks> yay!
<dileks> http://nopaste.snit.ch/134321
#ubuntu-kernel 2013-04-15
<zequence> apw: lowlatency kernels ready
<apw> zequence, ta
<zequence> apw: Are we doing the same procedure for S? I wouldn't mind rebasing the development version of the kernel too.
<apw> zequence, we could indeed ...
<ppisati> brb
 * ppisati -> out for lunch
 * rtg -> coffee. back in 10
 * Gaudasse -> went to poop, back soon
<Kano> hi, does anybody like to update unstable-3.9 branch? i get that pae pagefault error with chrome relatively often with rc6
<Kano> [91923.928016] Bad pagetable: 000f [#4] SMP 
<Kano> Process chrome (pid: 11475, ti=cd36a000 task=e7188000 task.ti=cd36a000)
<Kano> i left out some lines
<rtg> ogasawara, looks like the N4 kernel is accepted into the archive. Mayhap we should get the touch image builder to incorporate that kernel first since it appears to work (as opposed to the N7 which still has a touchpad issue)
<ogasawara> rtg: ack, I think all we need to do is ping rsalveti 
<ogasawara> rsalveti: ^^
<rsalveti> ogasawara: cool, was planning on doing that later today to be able to use lttng
<rsalveti> right timing 
<rtg> ogasawara, I got stalled on flash-kernel last Friday after bricking my N4 3 times. still haven't quite figured out why.
<ogasawara> rsalveti: sweet, thanks.  let us know when you have an image and I'll have my guys with an N4 test it.
<rsalveti> rtg: do you know if all the configs used by the android tree is still marked as built-in?
<rsalveti> just to know if we'd also need to make the modules to work right during the boot
<rsalveti> until we flip the container model
<rsalveti> ogasawara: sure, thanks
<rsalveti> can check later as well
<rtg> rsalveti, there is likely still some config work yet to be done. which ones are you concerned about in particular ?
<rtg> ppisati, have you been able to get back to the N7 touchpad issue yet ?
<rsalveti> rtg: none in particular yet, just to see if I should expect issues
<ppisati> rtg: nope :(
<ppisati> rtg: still on highbank
<rtg> rsalveti, I've been able to install the vmlinuz by hand on the N4. everything seeems to work OK
<rsalveti> rtg: cool, then we should be good
<ogra_> yeah but that wont work if you have an abi bump
<ogra_> the modules lve in the android image
<ogra_> and we have no way to regenerate that on the fly in a running system
<rtg> ogra_, well, if I could get flash-kernel working....
<ogra_> (or do we ?)
<ogra_> rtg, flash-kernel wont help the modules
<ogra_> you need to re-roll the system.img and flash it 
<rtg> I thought abootimg flashed both vmlinuz and the initrd ?
<ogra_> rtg, but not the android rootfs :)
<ogra_> you want /system/lib/modules/ to be filled with the right modules for your abi
<ogra_> we load the modules from android, not from ubuntu atm
<rtg> ogra_, so, the Ubuntu N4 kernel must have enough stuff built-in that modules aren't a problem (yet)
<ogra_> thats why rsalveti said above we need to wait for the container model flip
<rtg> ok, I get it now
<rsalveti> yeah, the default from the original config is enough already
<rsalveti> at least from what I saw at nexus 4
<ogra_> (currently nearly everything is stucvk on that ... )
 * ogasawara back in 20
 * ppisati -> EOD
<popey> jsalisbury: yo, wrt bug 1167019 which exact raring kernel should I test on precise?
<ubot2> Launchpad bug 1167019 in linux (Ubuntu) "wifi packet loss on intel Centrino Wireless-N 1000 " [High,Confirmed] https://launchpad.net/bugs/1167019
<jsalisbury> popey, The latest would be good.  You can get the .debs from: https://launchpad.net/ubuntu/+source/linux/3.8.0-18.28/+build/4486060
<popey> super, thanks
<popey> jsalisbury: i am confused... http://paste.ubuntu.com/5711280/
 * popey removes headers and expects all to be fine anyway
 * popey reboots into raring kernel
<popey> 3.8.0-18-generic
<popey> \o/
 * popey sets a ping going and pops to the shops
<jsalisbury> popey, thanks for testing
<popey> np
<popey> updated the bug report
#ubuntu-kernel 2013-04-16
<jussi> Hi peoples. Im on Raring and my kernel wont install - is it known? and are you fixing it? :D
<jussi> http://paste.ubuntu.com/5712775/
<smb> gzip: stdout: No space left on device
<smb> jussi, That you have to fix on your own ;)
<ogra_> smb, nah, its your fault, make smaller kernels !
<ogra_> :)
<smb> ogra_, :-P
<ppisati> apw: so, given the same hw but two different kernels, the two kernels generate different uuids for the same partition
<ppisati> apw: what could it be?
<ogra_> are you sure its the kernel ? UUIDs are usually a userspace thing, no ?
<ogra_> tied to the filesystem
<ppisati> ogra_: same hw but two different kernels
<ppisati> ogra_: if the kernel is the only variable to change, and uuids change
<ppisati> ogra_: it must be kernel related
<ogra_> well, then i would look at the filesystem code 
<ogra_> theoretically it cant be since the UUID is stamped into the filesystem though 
<ppisati> eh
<ppisati> but truste me it just happened to me :)
<ogra_> heh, yeah, i dont deny that :)
<ogra_> so if you see them differently with i.e. the blkid command, looking at what this calls  and then crawl into the kernel might help
<ppisati> ls -la /dev/disk/by-uuid/
<ppisati> show same partitions, but different uuids
<ogra_> and blkid does the same ?
<ogra_> iirc it asks the kernel directly
<ppisati> ogra_: 99% i think it does the same
<ppisati> ogra_: didn't strace it yet
<apw> ppisati, those are often calculated from disk serial numbers and the like, if there was a change there it could change the uuids
<apw> ppisati, it would be highly undesirable of couse
<ppisati> apw: yeah
<ppisati> apw: never mind anyway...
<apw> ppisati, did you suss it out ?
<ppisati> apw: yes, and it wasn't a kernel config... don't let me say anything... :)
<apw> heh ok :)
<apw> zequence, your uploads are reviewed and sponsored into the kernel ppa, sorry for the delay
<apw> ogra_, we have a specifiic initrd configuration for the nexus images, what makes that different
<apw> ogra_, (i am assuming you were involved :)
<ogra_> apw, the size limit and plkymouth bugs
<ogra_> the combo of kernel and initrd cant be bigger than 8M ...
<ogra_> and plymouth halts the system if console-setup didnt tun before it starts
<ogra_> *run
<ogra_> apw, the code for that  is in ubuntu-defaults-nexus7 and in ac100-tarball installler 
<apw> ogra_, great ... i want to see if we can elide the filesystem modules we know we do not need
<ogra_> well, keep them but use MODULES=list for the initrd (and indeed dont supply a list)
<ogra_> so you end up without modules in there but have them on the fs
<ogra_> (we should probably just patch initramfs-tools one day to accept MODULES=none for such cases)
<apw> ogra_, i was thinking the same, move to list, and don't specify any
<ogra_> i do that since years for arm stuff :)
<ogra_> the android based devices usually have a limited partition for kernel/initrd
 * ppisati -> out for lunch
<zequence> apw: Thanks
<apw> ogra_, so i think you are saying that something like this would be reasonable for the n7 images: http://paste.ubuntu.com/5712980/
<apw> ogra_, not of course that that helps any with how the phablet images are built yet
<ogra_> COMPRESS=lzma helps too 
<ogra_> and FRAMEBUFFER=Y in case we will ever use plymouth (we dont currently)
<ogra_> but yeah, MODULES=list is essential 
<ogra_> note that ac100-tarball-installer puts that in place during the nexus7 install
<apw> ogra_, we seem to have FRAMBUFFER=y in another, file, COMPRESS=lzma sounds like a good plan
<ogra_> ogra@anubis:~/Devel/packages/ac100-tarball-installer-0.45$ cat conf.d/ac100-installer 
<ogra_> MODULES=list
<ogra_> BOOT=installer
<ogra_> COMPRESS=lzma
<apw> ogra_, it does, it is not on my image, but perhaps it is too old, 
<ogra_> thats what we use during install
<apw> ogra_, it does? was what i mean
<ogra_> oh
<ogra_> no it *should* but it doesnt 
<apw> ogra_, or am i conflating this with ac100 and n7
<ogra_> it does it for ac100 ... no idea why i didnt add it for nexus7 too
<apw> ogra_, ahh, so i'll let you fix that :)
<ogra_> i'm sure it is somewhere in the install 
<ogra_> let me dig 
<ogra_> else our initrd wouldnt work 
<apw> ogra_, i see modules getting sucked up into my initramfs's
<ogra_> k
<apw> ogra_, it is only that the n7 kernel has a lot turned off we don't get too big
<ogra_> then soemthing is wrong 
<apw> indeed when i harmonize the filesystems it immediatly is too big
<apw> but my image might be older, if you have recent install you could check
<ogra_> i dont
<apw> ok
<ogra_> hmm, yeah, seems to be no code for it at all
<ogra_> so yeah, add yours :)
<ogra_> though probably not to /etc
<ogra_> use /usr/share/initramfs-tools/conf.d/  for packaged configs ... /etc is for admins to override
<ogra_> (or for hacks that arent properly packaged) 
<apw> ogra_, ok
<rtg> ogasawara, yesterday I realized that the module config work on the N[47] kernels is next to impossible to test on the touch image until rsalveti swaps Ubuntu with Android to run as the boot O/S. Android cannot use the Ubuntu /lib/modules.
<ogasawara> rtg: ack, I'll just push them out a bit
<rtg> I think the initrd works OK since it gets flashed along with the kernel
<apw> rtg, do we know if they are going to definatly do that even ?
<rtg> apw, I think he's qorking on it
<rtg> working*
<apw> rtg, actually is that true in the sense at least the kernel outside if taken from our source is built outside too
<apw> obviously from an update point of view it is true
<rtg> apw, huh? cannot parse.
<apw> in the image generation, if the builder takes our deb as 'source' and takes the binaries from there, they would be outside in the android world so modules would be ok there i think
<apw> but ... on update from us, the modules are trapped so it _is_ a problem then
<rtg> apw, only those in the initrd
<apw> nasty
<rtg> apw, oh, I see what you're saying. perhaps that might work but we'd have to craft an update that works under Android
<apw> right and we don't have that now for sure
 * rtg -> bbias
<apw> though, if you are root in our chroot, what stops you probing the chroot modules into the kernel
<rtg> apw, nothing stops you, but it is not currently automatic. the ubuntu chroot is not started by default.
<ogra_> rtg, the android initrd (As we use it now) doesnt contain any modules ... its only a few bytes big .... the current prob is that we would need to update the android one and cant use the ubuntu one ... 
<ogra_> and its still not clear that we can actually flip the container models
<rtg> ogra_, ack
<ogra_> in the worst case scenario we need to come up with a way to actually update the android initrd from the ubuntu side ... and accordingly install our modules into the android paths 
<ogra_> (on the rootfs)
<ogra_> i dont think android even uses modprobe ... they usually insmod the modules from init.rc
<rtg> ogra_, ick, what a hack.
<ogra_> with full path and options 
<ogra_> yeah, its awful ... better pray that the flip works :)
<ogra_> i guess installing the modules is easy by adding some symlinks ... though it might be that /system is readonly which could cause probs 
<apw> ogra_, it is not clear why it would not be possible, we have pure ubuntu on the N7 desktop images
<ogra_> apw, the question is if androids HW layer is still functional if you put it into a container
<rtg> apw, doesn't the N4 do some sort of signing thing ?
<ogra_> we need the drivers ... and they are not only linked against bionic instead of libc, but also all armel :)
<apw> rtg, hmmm dunno maybe, but we are signing whatever crap we put on there now don't we ?
<apw> it is good to see this is all resolved well before freeze
<rtg> apw, not as far as I knwo, but I guess we _are_ booting our kernel so maybe signing isn't an issue.
<ogra_> haha
<apw> rtg, yeah thats my assumption
<ogra_> on nexus signing sholdnt be an issue ... 
<ogra_> on all other platforms it might become one
<ogra_> even on one we will be preinstalled on
<ogra_> but thats 13.10 material i guess
<apw> ogra_, well we do at least have precident with the win8 poop
<ogra_> :)
<apw> so we know how to do it 'safely'
<ogra_> yeah, but yu might have to rely on hackish solutions the vendor picked
<ogra_> there isnt a standard like UEFI on android 
<ogra_> its usually some fastboot based loader ... 
<ogra_> and you cant replace the bootloader since it is usually signed with a factory key 
<ogra_> (else we could switch to arm-grub or u-boot and life would be easier)
<ogra_> the fastboot based loaders can even contain a hardcoded and signed GPT so you cant ever resize the boot partition for example 
<apw> quality and no mistake
<ogra_> :)
<ogra_> well, if you measure quality by "lock out the users effectively" they surely did a good job here 
<apw> almost as good as raring daily qualit
<ogra_> (and i think thats what carriers are usually after)
<sforshee> ppisati, have you been looking into the nexus 4 ftrace problems?
<ppisati> sforshee: nope, i'm stuck with calxeda :(
<ppisati> sforshee: i wish i can give it a look
<sforshee> ppisati, ack. I just wanted to be sure we weren't duplicating effort
<sforshee> did you have any ideas about the email I sent?
<ppisati> sforshee: nope, really
<ppisati> sforshee: i din't look at the code closely
<cking> sforshee, I've not had a chance to look at this yet today either
<sforshee> ppisati, I guess I'll start digging into the code today. The write that's failing for me seems to be smack in the middle of the kernel text, so I have no idea why it fails
<sforshee> when so many before it succeed
<sforshee> ppisati, do you know if there's some way to dump the arm page table attributes?
<ppisati> sforshee: not really
<ppisati> sforshee: btw, when i turned on ftrace, my kernel refused to boot
<sforshee> ppisati, my kernel boots, however the screen stays blank
<ppisati> sforshee: do you have a cgf diff?
<ppisati> *cfg
<sforshee> ppisati, I can generate one, just a sec
<sforshee> ppisati, http://pastebin.ubuntu.com/5713232/
<ppisati> sforshee: i'll give it a try later, thanks
<sforshee> ppisati, the test options are completely unnecessary, the failure happens during ftrace initialization when DYNAMIC_FTRACE=y
<jussi> smb: I thought there was some preinstall script that cleaned up old kernels so this didnt happen ?
<rtg> jjohansen, need to reboot tangerine for the openssl update
<smb> jussi, I would not know of any pre-install script (probably also depends on whether one uses updatemanager or dist-upgrade). For Raring, running apt-get autoremove seems to result in some housekeeping
<jussi> smb: yeah, unfortunately autoremove isnt really nice to me - it removes lots of things I still want. anyway, Ill remove an old kernel or 2. Frustrating though
<jussi> (and yes, I should have read the error message properly... :P )
<smb> It sometimes helps. ;)
<rtg> cking, henrix: need to reboot gomeisa for SSL update
<rtg> ogasawara, we definitely need to upload 3.8.7 before final. it fixes a Thinkpad suspend regression.
<rtg> I suspect its 'Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"' 'cause I saw a bunch of ACPI noise in my log
<ogasawara> rtg: ack, lets try to get it in today since final freeze is Thurs.
<ogasawara> rtg: well, I guess we could give it another day too in case something else lands
<rtg> ogasawara, 3.8.8 is gonna release by tomorrow
<ogasawara> rtg: so lets wait
<rtg> ack
<rtg> jsalisbury, 3.8.6 appears to have fixed some Raring suspend regressions, at least on my Thinkpad. you might keep that in mind as you're processing bug reports.
<jsalisbury> rtg, ok, thanks
<jsalisbury> rtg, I'll ask for testing of some of the existing reports as well
<rsalveti> rtg: ogra_: ogasawara: I tested the n4 kernel and it worked fine, have a pending mr to replace the kernel from boot.img to the one provided by the package
<rsalveti> regarding modules, as long we have the core part as built-in, we're good
<ogra_> will you autosync into phablet.u.c ?
<rtg> rsalveti, sort of, until someone wants to plug in a USB gizmo, or mount a stange file system.
<rsalveti> rtg: ogra_: sure, but the problem is that we don't have different raring images per device
<rsalveti> so we can't yet install the kernel package at the image by default
<ogra_> yeah
<rsalveti> in case the user wants to use a module, he would need to install the package by hand
<rsalveti> and then it should work, as the kernel is the same, so binary compatible
<rsalveti> ogra_: my idea is to disable the kernel build part of the android image
<rsalveti> and just use a pre-built image, and try to keep that in sync
<rsalveti> at jenkins we have a script that will download the latest every time
<ogra_> well, as long as youo dont add more sources for me to pull from while building the android layer :P
<rsalveti> no, it's easier actually
<rsalveti> and will reduce the build time as well
<ogra_> i'm just concerned about more holes in the firewall to the livefs builder 
<rsalveti> rtg: ogasawara: there's only one extra requirement now from the app dev team, which is to support lttng
<rsalveti> and for that we'd need working kernel packages for maguro and manta (galaxy nexus and nexus 10)
<ogra_> since each of these changes delays me waiting for IS
<rsalveti> ogra_: right, they will be available via phablet.u.c
<ogra_> great
<rsalveti> rtg: ogasawara: and also a backport of the latest apparmor patch set used 
<rsalveti> as they will still be used as dev target 
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<rtg> rsalveti, ogasawara: prolly ought to get those listed as work items so we don't forget.
<rsalveti> rtg: yup, indeed
<rtg> rsalveti, doesn't lttng use ftrace ?
<rsalveti> rtg: I think it lttng is trying to reuse some pieces from ftrace
<rsalveti> but they still need external modules
<rsalveti> which is provided via dkms at ubuntu
<rtg> rsalveti, seems like sforshee and cking were having problems with ftrace on the Nexus kernels
<rsalveti> rtg: hm, interesting
<rsalveti> well, lttng provides both user and kernel tracing, so at least some part should work
<sforshee> rsalveti, yeah there's a problem with dynamic ftrace atm on the nexus 4
<rsalveti> sforshee: is that specific to this kernel or for the upstream 3.4 one as well?
<sforshee> rsalveti, I was told that it worked in generic 3.4, but I'd have to refer you to cking and ppisati for confirmation of that
<rsalveti> sforshee: right, but good to know
<cking> i believe that's what ppisati concluded
<rsalveti> will give that a test later today to see if it works at least enough for lttng
<sforshee> rsalveti, the problem is that dynamic ftrace inserts calls to a function named mcount at the start of just about every kernel function, then at boot overwrites those calls with noops
<sforshee> at some point writing the noop fails, and ftrace disables itself as a result
<rsalveti> rtg: should I put the WIs for you there?
<rtg> rsasure
<rtg> rsalveti, sure
<jdstrand> rsalveti, rtg: hey, where is that apparmor work item being tracked?
<rtg> jdstrand, Blueprint foundations-1303-phablet-kernel-maintenance] I think
<rtg> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance
<rsalveti> jdstrand: we can probably track it at https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-phablet-kernel-maintenance
<jdstrand> ok, thanks. /me subscribes
<jdstrand> oh, I already am :)
 * henrix -> back in 15
<jdstrand> jjohansen: fyi, I also subscribed you to ^
<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 April 23th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
 * ppisati -> EOD
 * rtg -> lunch
 * cking EOD too
 * rtg -> EOD
#ubuntu-kernel 2013-04-17
<ppisati> moin
<smb> wiki
 * apw yawns
<czajkowski> apw: morning to you too
<apw> he
<apw> heh
<ppisati> brb
 * ppisati -> out for an early lunch
 * henrix starts to think it was a bad idea to try to bring the efi patches into 3.5.y
<rtg> apw, ogasawara: just pushed Ubuntu-3.8.0-19.29 w/v3.8.7 and v3.8.8. gonna build and smoke test for a few hours on various bits of kit before uploading.
<ogasawara> rtg: ack
<ogasawara> rtg: lemme know when you have a test build and I can throw it at some of the kit I have here too
<rtg> ogasawara, will do. that reminds me, I should update some chroots since we have a new binutils.
<ppisati> rtg: i just sent a fix for R/master-next, and then i've another one coming today
<rtg> ppisati, ok
 * rtg reboots for kernel update
 * cking can't ack patches quick enough today
 * henrix -> back in 15
<ogasawara> ahh the joys of a 2yr old crashing a meeting
 * ogasawara back in 20
<rtg> ogasawara, I guess you were done, huh? whether you wanted to be or not.
<ppisati> rtg: last fix sent to the ml, with this applied, i'm done with R.
<rtg> ppisati, ack. good timing.
<ppisati> :)
<rtg> bjf, do you remember if we have some wiki info on kernel versioning ?
 * rtg is too busy listening to Rush to be bothered to look for himself.
<bjf> rtg, not that i know but it would be a good thing
<rtg> bjf, seems like we have to explain our versioning scheme every so often
<robher> rtg, ppisati: I've got a fix for the highbank reset issue. I'll be sending it out to lakml soon as I can write a decent commit msg. It's heavily tested to work 3 out of 3 times.
<rtg> robher, I thought that was the PL310_ERRATA_769419 thingy ?
<ppisati> rtg: that was a workaround
<ppisati> rtg: in case the fix didn't make for the release
<rtg> ppisati, well, I think we'll stick with the workaround until after release, OK ?
<ppisati> rtg: i'm good with it
<rtg> robher, you too ?
<robher> rtg: That's not the real problem. It just makes the issue 100% reproducible. It is still possible to hit it on reset or cpu hotplug.
<rtg> *sigh* - we're getting kind of close to the wire
<robher> Errata 769419 is the fix for that USB performance issue on Panda that Canonical spent a long time root causing.
<rtg> thats why it looked familiar
<bjf> rtg, i'm working on that version wiki "problem"
<rtg> huh :) imagine that.
<bjf> rtg, read https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2BAC8-FAQ.2BAC8-GeneralVersionMeaning.What_does_a_specific_Ubuntu_kernel_version_number_mean.3F and the following 3 sections
<bjf> rtg, i don't think this matches your email though i believe your email is correct
<rtg> bjf, perhaps we could add some of that email to the section 'What differentiates the Ubuntu Kernel from the upstream Linux Kernel?'
<bjf> rtg, i don't think the other sections are exactly correct either since 3.0 but i can start with your suggestion
 * cking --> back later, car stuff to do
<rtg> robher, can I set CONFIG_PL310_ERRATA_769419=y after applying your patch 'ARM: highbank: fix cache flush ordering for cpu hotplug' ?
<ppisati> robher: ok, saw the patch
<rtg> ppisati, you gonna test a kernel with this patch and PL310_ERRATA_769419=y ?
<bjf> rtg, i didn't change much from your email ... https://wiki.ubuntu.com/Kernel/FAQ/GeneralUbuntuDelta
<rtg> bjf, looks good. thanks.
<ppisati> rtg: ok, patch sent as a followup
<rtg> ppisati, I repushed master-next. have a look to make sure I have it correct
<ppisati> rtg: yes it is
<wolfgang8741> I was asked to test an upstream version for 3.9-rc7, but no amd64 build is listed in the directory.  Are the mainline kernel building of 3.9-rc7 complete (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc7-raring/)? I saw the release announcement saying the building is complete (https://lists.ubuntu.com/archives/kernel-team/2013-April/027614.html), but not all architectures display on the site.
<rtg> apw, ^^
<bjf> psivaa, all kernels are through verification. i know you folks are going to be pretty busy next week so if you wanted to get a jump on them you can
<psivaa> bjf: ok, thanks for the info. one of our servers is down. will get going once that comes up
 * ppisati -> out for the usual routine
<ppisati> back later
 * rtg -> lunch
<apw> wolfgang8741, if there are no binaries for an arch it likely did not complete
<apw> kamal, it is all your fault :)
<apw> rtg, it is the new module dependancies checker
<rtg> apw, which is why mainline isn't building ?
<apw> it is aborting the amd64 build
<apw> rtg yes
<rtg> apw, why are you building an extras package ?
<apw> WARNING: /home/apw/COD/linux/debian/linux-image-3.9.0-030900rc7-generic/lib/modules/3.9.0-030900rc7-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko needs unknown symbol ptp_clock_index
<apw> WARNING: /home/apw/COD/linux/debian/linux-image-3.9.0-030900rc7-generic/lib/modules/3.9.0-030900rc7-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko needs unknown symbol ptp_clock_register
<apw> WARNING: /home/apw/COD/linux/debian/linux-image-3.9.0-030900rc7-generic/lib/modules/3.9.0-030900rc7-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko needs unknown symbol ptp_clock_unregister
<apw> EE: Unresolved module dependencies in base package!
<apw> make: *** [install-generic] Error 1
<apw> rtg, it builds wahtever the primary would build, which is split in that release
<kamal> apw: my fault?  what'd I do!?
<rtg> apw, the LTS kernels only build one package. maybe mainline should do the same ?
<apw> i suspect i need to find this new check and wack it in mainline builds
<apw> rtg, yeah i think i can just wack do_extras_package=false
<apw> and be happy
<apw> kamal, wasn't this your doing:
<apw> EE: Unresolved module dependencies in base package!
<rtg> apw, I think that was an smb patch, not kamal.
<kamal> apw: I don't think so -- I'm not the droid you're looking for
<apw> kamal, :)
<kamal> apw: but hey, thanks for thinking of me, man!  ;-)
<apw> kamal, i always do ... always do
<wolfgang8741> apw, thanks knew something might have broke
<rtg> ogasawara, uploaded raring. I'm outta here to recycle some HW.
<ogasawara> rtg: ack, thanks
 * rtg -> EOD
<smallfoot-> Linux 3.8.8 released today
<jsalisbury> bjf: File "/usr/lib/pymodules/python2.6/launchpadlib/launchpad.py", line 28,
<jsalisbury> in <module>
<jsalisbury> from lazr.uri import URI
<jsalisbury> ImportError: No module named uri
<bjf> jsalisbury, http://pastebin.ubuntu.com/5716959/
#ubuntu-kernel 2013-04-18
<smb> apw, Yup it was me. 
<diwic> apw, you still have broken sound, right? Or did it resolve itself?
<apw> smb, heh ... ok
<apw> diwic, i think that the condition my system is in now it is not happening
<apw> diwic, i am suspicious it is power related, being on battery or some such, but not being able
<apw> diwic, to get fully updated easily is hampering my efforts to exclude cause
<diwic> apw, anyway, I saw two more bugs related to hdmi audio this morning. One was an oops and I'm about to write a patch for it
<apw> sounds good, i'll assume my issue is unreproducible till it isn't
<apw> diwic, get the patches out, they can go in the first SRU
<diwic> apw, I just posted it to the list
<apw> diwic, always ahead of me, heh
<diwic> apw, but sigh, maybe I need to do the the SRU essay too
<apw> diwic, yep after kernel freeze one needs that anyhow basically
 * ppisati hates pollen
<apw> ppisati, pollen already?
<ppisati> apw: yes, pollen f***ing pollen!
<ppisati> apw: i'm sneezing like there's no tomorrow
<apw> sounds lovely
<apw> more drugs for you
<ppisati> nope
<ppisati> i don't like to mess pills :)
<ogra_> ppisati, http://www.snopes.com/science/stats/sneeze.asp
<apw> heh i think if i was alergic to the world around me i'd be popping them
<ppisati> "it's the time for the sneezin' of love"
<ppisati> oh my...
<ohsix> a histamine reaction isn't fun, you don't have to mess with many pills to get it back to normal :p
<ppisati> ohsix: i was kidding dude...
<ppisati> ogra_: weren't you talking about modules on N4?
<ogra_> was i ?
<ogra_> what do you want to know ? 
<ppisati> why don' we use the new N4 kernel in the phablet img?
<ogra_> i think that still needs some changes to the android build system ... 
<ogra_> i know rsalveti committed something already, but i'm not sure thats enough yet
<ogra_> also there is work going on to flip the containers which means we'll use an ubuntu initrd, i guess that needs to be done as well before we can change 
<ppisati> ogra_: i'm reading irc logs
<ogra_> oh, and there needs to be some way of ugrading the kernel ... we'll need to research if flash-kernel really makes sense (if we dont flip the containers it will be better to use abootimg directly)
<ppisati> no containers flip? doesn't sound good to me
<ogra_> well, we dont know if it will work yet 
<ogra_> ChickenCutLass is still exploring
 * henrix -> food
<apw> ogra_, what are we using from android other than the kernel anyhow
<ogra_> apw, HAL, binary drivers, the input and media layers ...
<ogra_> pretty mich everything that talks to HW directly
<amitk> ogra: which would dictate more or less an Android API for app developers?
<ogra_> amitk, nope, there is libhybris in android and the ubuntu platform-api sitting on top of it
<ogra_> so devs need to use the api
<ogra_> s/api/ubuntu api/
<rsalveti> ogra_: ppisati: I sent a patch yesterday to allow reusing the kernel available in ubuntu
<rsalveti> and also enabling that for nexus 4, waiting sergio to review & apply it
<ppisati> rtg: apw ^
<rtg> ppisati, yep, saw that.
<apw> ppisati, good news indeed
<henrix> sconklin: do you think its worth starting bisecting the Q bug in parallel?
<sconklin> henrix: I think we need to find an in-house reproducer machine
<sconklin> I can't see any commonality in the hardware in the various bugs
<sconklin> except that they are all filed against the 64 bit kernel
<bjf> sconklin, henrix i think some of the people in bug 1140716 are having the same problem
<ubot2> Launchpad bug 1140716 in linux-lts-quantal (Ubuntu Precise) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed] https://launchpad.net/bugs/1140716
<apw> whats the bug
<henrix> apw: bug #1167114 and bug #1169380
<ubot2> Launchpad bug 1167114 in linux (Ubuntu) "Ubuntu Kernel 3.5.0-27 does not boot" [High,Confirmed] https://launchpad.net/bugs/1167114
<ubot2> Launchpad bug 1169380 in linux (Ubuntu) "Alienware M11x fails to boot with 3.2.40 upgrade" [High,Confirmed] https://launchpad.net/bugs/1169380
<bjf> henrix, sconklin, actually i won't be surprised if we are looking at multiple issues here
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1169304
<ubot2> Launchpad bug 1169304 in linux (Ubuntu) "3.2.0-40-generic hanging Lenovo T420 on boot" [High,Confirmed]
<sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1168961
<ubot2> Launchpad bug 1168961 in linux (Ubuntu) "Linux kernel 3.2.0-40-generic update causes regression, does not boot anymore" [High,Incomplete]
<henrix> bjf: yep, i'm almost sure we are due to different feedback from different users
<sconklin> 1168961 has only one graphics card
<ogra_> kamal, oooh, congrats for the new job ... !
<sforshee> apw, is there any reason to try and keep our enforcer rules in sync between the phablet kernels and the others?
<apw> sforshee, it is less sensible where the base versions do not match
<apw> where they do we should be trying to make a set of rules representing what we intend
<apw> sconklin, henrix, i note that at least one has a call trace starting right after a failure to initialise the GART
<sforshee> apw, thanks. The base versions don't match, so now I can take the easy route and just delete the rule I don't want :-)
<sconklin> apw: that helps, let me dig through the pile of graphics patches in the last stable update
<apw> sforshee, do you know anything about what bumblebee actually changes
<apw> as peple on the same bug are saying that installing that is sorting them out, and there is a definate theme of sandybridge (integrated intel graphics) + a-n-other card in these machines (first bug at least)
<sforshee> apw, not a clue, sorry
<sforshee> apw, I suppose it's likely to power on the secondary graphics device at least
<calc> anyone happen to know where the fix for 957298 is supposed to be? it doesn't appear to be in 13.04 (3.8.0-18)
<calc> and the workaround stopped working after 12.10
<bjf> calc, looking
<calc> it mentions that 3.9 should help resolve the issue, but the bug was closed out as fixed already
<bjf> calc, 3.8.0-19.29 has the latest upstream stable commits in it. that's in -proposed you could try that to see if it fixes your issue. you will want to just grab the .debs for the kernel and not enable -proposed for raring as that may pull in other packages that are not ready 
<calc> bjf: ok thanks i'll that now, when losing interrupts like a few seconds ago i can't even type, heh
<calc> er i'll try that now
 * calc brb rebooting
<henrix> sconklin: i give up trying to reproduce the bug. tried *every* x86 box i have around with both 3.2.0-40.64 and 3.5.0-27.46. no luck
<sconklin> I just posted another bisection to the one bug that had a reported failure from the first bisection, and I'm looking at some patches in that first bisection result range
<sconklin> henrix: thanks for trying
<henrix> np
<sconklin> incidentall, that is bug #1169380
<ubot2> Launchpad bug 1169380 in linux (Ubuntu) "Alienware M11x fails to boot with 3.2.40 upgrade" [High,Confirmed] https://launchpad.net/bugs/1169380
<henrix> sconklin: yep, seen it. lets wait and see...
<calc> bjf: working atm, will watch it and see if it starts eating cpu again
<bjf> calc, ack, good luck :-)
<calc> bjf: thanks for the help :)
<sconklin> henrix: there are two patches having to do with graphics transition from grub2 to kernel. One clears all buffer attributes, and I wonder if it's perhaps breaking the dual display case. But that's speculation
 * calc leaving going to do suspend/resume testing, etc, bbl
<henrix> sconklin: also, there are a few regression fixes in the -proposed kernels (both P and Q).
<sconklin> I found a suspicious patch
<sconklin> http://kernel.opensuse.org/cgit/kernel/commit/?id=e93a9a868792ad71cdd09d75e5a02d8067473c4e
<sconklin> that's the upstream one
<sconklin> henrix: but there are several others, which touch fb driver, or have to do with grub2->kernel graphics transition
<henrix> sconklin: ah, interesting. and that commit is on both kernels
<sconklin> any patch with "band-aid" in the description is suspect immediately
<henrix> heh, true :)
<sconklin> the patches I found are pretty spread out through the commits between known good and bad, so I don;t think we can do much better than just letting the bisection run its course right now. After one or two more we may be able to tell.
<henrix> sconklin: fortunately, the bug reporters seem to be quite responsive
<sconklin> small miracles
<calc> bjf: seems that doesn't fix the issue :-\
<bjf> calc, sorry to hear that
<calc> bjf: is there an ppa for testing newer kernels? i could try one of those to see if it helps
<bjf> calc, the -proposed is the newest
<sconklin> henrix: I'm going to start bisecting for quantal bug #1167114 also
<ubot2> Launchpad bug 1167114 in linux (Ubuntu) "Ubuntu Kernel 3.5.0-27 does not boot" [High,Confirmed] https://launchpad.net/bugs/1167114
<henrix> sconklin: ack
<calc> bjf: ok
<Jope> hello.. I joined to inquire whether you guys have considered enabling config_chromeos_laptop in your 3.9.0 builds? 
<rtg> Jope, CONFIG_CHROMEOS_LAPTOP=m is in our git repo, but apw's mainline build may not have it turned on.
<Jope> ok, that's nice.. so just that I don't misunderstand, does this mean it will eventually make it to the mainline too?
<apw> 3.9 is built against raring, so if the config is in master-next it would likely get turned on in a mainline build; unless they moved it or somethig dumb
<apw> rtg, when did it get turned on in raring ?
<rtg> apw, not asure if it exists in raring
<rtg> apw, in fact it didn't appear until 3.9
<apw> rtg, "CONFIG_CHROMEOS_LAPTOP=m is in our git repo," ... which one
<apw> oh unstable-3.9 ?
<rtg> apw, unstable-3.9
<apw> so yeah when you cut SS repo we would start building using that, and it would be on in later mainline builds
<rtg> yep
<apw> i wonder when we will know what it is goibng to be called
<Jope> ok, cheers :-)
<Jope> hopefully I don't have to build too many kernels of my own then
<rtg> where has the morning gone ? /me -> lunch
<apw> where has my broadband gone, oh, i know that
<calc> bjf: it appears to be fixed in 3.9rc7 and I updated the bug report noting that. I'm willing to test any kernels in the effort to get it fixed properly for 13.04 as well, otherwise the bug report probably should stay open until 13.10.
<rtg> sforshee, uploaded the N4 kernel with your FTRACE config changes.
 * rtg -> EOD
#ubuntu-kernel 2013-04-19
<lamont> who knows swraid enough to tell me if a RAID built on i386 can be used on amd64?
<ppisati> moin
<smb> moin
<smb> lamont, In theory I would be disappointed to the point of grabbing pitch fork and torch to visit some developers if not. Practically one never knows. But should be easy to verify with some test-vms. 
<ppisati> bah
<ppisati> mail.google.com doesn't work for me this morning
<ppisati> 'You cannot perform this step unless you first disable OpenID on your account.'
<ppisati> then you click on 'disaple OpenID', but nothing changes
<ppisati> TGIF
<smb> ppisati, That was one of the reasons I took the delay of migration as a chance to put myself on opt-no
<ppisati> :(
<ppisati> can't check my personal email now
<ppisati> ufff
<smb> Hm, seems to arrive on the phone for me still
<smb> at least the spam
<ppisati> maybe if i delete some cookies, cache, bookmarks, the entire internet, etcetc
<ppisati> no no
<ppisati> it works
<ppisati> it's just the web mail that is borked
<smb> ppisati, You are sure you have logged out of the Canonical google account
<ppisati> smb: i can't
<ppisati> smb: there's no logout thing
<ppisati> wait
<smb> ?
<ppisati> the 'logout' click to link
<ppisati> wasn't there
<ppisati> and if access any google service (e.g. finance)
<ppisati> it say 'Sign in'
<ppisati> so i'm logged in ATM
<ppisati> *i'm not
<ppisati> ok
<ppisati> ah
<ppisati> ok, going trhough ww..google.com
<ppisati> www
<ppisati> i saw i was still logged in as *canonical
<ppisati> and switching account didn't work
<ppisati> i first had to logout
<ppisati> and then relogin with my private account
<smb> yeah, that sounds like my experience. I usually go to either main google page or g+ and log-out-in to switch
<ppisati> account switching usually worked
<smb> maybe a "feature" of migration
<brendand> henrix, hi - i see the certification-testing task was marked Invalid for Lucid
<henrix> brendand: hmm, ok. so the bot hasn't been fixed yet. can you please fix it manually?
<henrix> brendand: i'll go fix the bot for next cycle
<brendand> henrix, it seems we might be too late?
<henrix> brendand: to be honest, i don't actually know in which fase of the sru we are currently... sconklin is driving this cycle
<brendand> henrix, already in -updates
<henrix> brendand: oh
<henrix> brendand: ouch
<henrix> bjf: ^
<henrix> brendand: the cert task creation for lucid kernels has been explicitly removed from our scripts due to comment #9 in bug #1095350
<ubot2> Launchpad bug 1095350 in linux (Ubuntu Lucid) "linux: 2.6.32-45.102 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/1095350
<brendand> henrix, yeah - that changed later on though
<henrix> brendand: ok, i'll revert that then
<brendand> henrix, anyone it's not a huge problem, let's just get it reverted and we'll resume testing from next cycle
<henrix> brendand: ack, will do. thanks
<rtg> ogasawara, we need to develop a firmware delivery mechanism for Precise LBM. cw-3.6+ and up have support for wifi drivers that also need new firmware.
<arges> tjaalton: hi
<rtg> ogasawara, FYI - I'm updating your patch in bug #1068751 that never got applied for some reason.
<ubot2> Launchpad bug 1068751 in linux-backports-modules-3.2.0 (Ubuntu Precise) "Add Conflicts: for compat-wireless stacks" [Medium,In progress] https://launchpad.net/bugs/1068751
<ogasawara> rtg: ack and ack
<tjaalton> arges: hey
<arges> tjaalton: re: bug 1157678. I have the patch already there, and I thought bryce had put it into the xserver-xorg-video-intel.git tree
<ubot2> Launchpad bug 1157678 in xserver-xorg-video-intel (Ubuntu) "[ffe] unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,Fix committed] https://launchpad.net/bugs/1157678
<tjaalton> arges: he didn't push anything
<tjaalton> -0ubuntu2 is the latest on git
<arges> tjaalton: so you are pushing it into the ubuntu package as an FFE for raring?
<tjaalton> arges: if bryce doesn't beat me to it, yes
<tjaalton> doesn't matter who pushes the button
<arges> tjaalton: ok. I'm not entirely sure about the procedures for X stuff, so as long as it gets fixed
<tjaalton> right
<arges> cool thanks
 * henrix -> back in 20
<bjf> henrix, ack
<bjf> brendand, you an still test kernels that are in -updates, no?
<brendand> bjf, we can if you'd like. testing can't start until monday though because our lab engineer is in Portland for the OpenStack summit
<bjf> brendand, more testing es never a bad thing
<bjf> breandan, that statement is kind of confusing. you only have 1 person that can do the testing and he can't kick the jobs off remotely?
<bjf> brendand, next week is testing week anyway
<brendand> bjf, well we can do 80% of it remotely. there are a couple of systems that won't obey a wakealarm so need a push to resume from suspend
<bjf> brendand, like i was saying, next week will be fine. if you find anything just let us know.
<ogasawara> ppisati: I've probably missed hearing of any updates, but have we gotten any feedback for the nexus7 kernel from the X guys about the touchscreen issue?
<ppisati> ogasawara: no updates so far
<ogasawara> ppisati: do we have an eta?  maybe we should just upload, it'll really force the issue then (or confirm nothing else needs to be done).
<ppisati> ogasawara: i agree
<ppisati> tjaalton: ^
<tjaalton> it's not a kernel issue
<tjaalton> um, what issue? :)
<ppisati> tjaalton: we are carrying a patch in our nexus7 tree
<tjaalton> ok
<ppisati> tjaalton: to make X (and the desktop img) work with  the touch screen
<tjaalton> oh just that, ok
<ppisati> tjaalton: the problem is that the same exact kernel has a broken touchscreen when used on the touch img
<ppisati> tjaalton: and that touchscreen patch is the culprit
<tjaalton> ah
<ppisati> tjaalton: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-nexus7.git;a=commit;h=58245f54a897f928a6c86f30a599b461e96cd23a
<ppisati> tjaalton: it's the bad patch (but we need it for the desktop img)
<tjaalton> I guess you want jani then
<tjaalton> hmm
<ppisati> tjaalton: ogra told me you were working on a fix
<ppisati> ogra_: ^
<tjaalton> not the same thing
<tjaalton> that's the touch grab hang bug
<ogra_> ppisati, only jani can tell 
<tjaalton> on X
<ogra_> and yeah, different issues
<ogra_> i think the patch from jani simply makes X aware of the device 
<ogra_> turning it into an ev dev
<tjaalton> right
<ev> o/ ;)
<ppisati> ok so,. 2 questions:
<ppisati> 1) if we upload, do touch img get atutomatically it?
<ppisati> 2) is there a way to distinguish i'm running in an android env?
<ogra_> not easily since the android definition is just in the process of completely being changed 
<ogra_> and in the end the andripd bits will likely run *in* ubuntu
<ogra_> ppisati, waht touch image do you refer to with 1)
<ppisati> ogra_: really? yesterday i heard a completely opposite story
<ppisati> ogra_: the phablet nexus7
<ogra_> i think rsalveti was working on something that pulls the binaries into the image build, yeah
<ogra_> ppisati, for now we will start with an android container ... but i belive the whole set of android bits will eventually just end up in packages in the normal system
<ogra_> i think the final implementation will only be decided at the sprint though
<ogra_> its all in flux
<ogra_> ppisati, what did you hear yesterday ?
<ogra_> :)
<ppisati> ogra_: that we weren't switching containers
<ogra_> right, thats the first step
<ppisati> ogasawara: anyhow, it seems we cannot upload because it would break the touch img
<ogra_> but the android linker uses  its completely own path ... so in the end having the bits just packaged and installed as normal debs will be easier
<ppisati> ogasawara: i'll try to come up with a patch to make it work in both worlds
<ogasawara> ppisati: ack
<ogra_> ppisati, if you could make it check for the android gadget being enabled and make it use the patch only if that isnt, i guess that could be a good distinction
<ppisati> ogra_: that's what i wanted to do: if (!$android) touch_patch(); 
<ogra_> the phablet image needs adb, adb needs the android gadget ... while the desktop image is completely built around the compositre gadget 
<ogra_> err, wait ... 
<ogra_> do you actually apply two differnt configs  and build two different binaries ?
<ogra_> dekstop *needs* g_composite builtin ... while phablet *needs* g_android
<ppisati> ogra_: builtin? no modules?
<ogra_> i guess there are a good bunch of other options the different systems need set/unset
<ogra_> builtin, yeah
<ppisati> ogra_: to get a system running with wifi/usb/screen/etcetc not that much
<ogra_> well, g_android could be a module but it wouldnt load if g_composite is builtin
<ogra_> and g_composite or g_serial builtin is essential atm 
<ogra_> we need some access to the initrd to make the container flip work ... currently i'm actually abusing the desktop kernel for this
<rsalveti> ogra_: ppisati: the mako related patch should land today
<rsalveti> and with that it'll grab the kernel automatically from the archive
<ogra_> yeah, mak is fine
<ogra_> grouper isnt 
<rsalveti> same will happen with nexus 7 once we get a blessed kernel
<ogra_> rsalveti, thats the problem 
<rsalveti> and so on
<rsalveti> ogra_: why?
<ogra_> we need quite different config options for both images
<rsalveti> not necessarily
<ppisati> ogra_: i unserstand we need g_android in phablet, but i don't understand we need g_composite in desktop
<ppisati> *understand
<ppisati> *why we
<ppisati> etcetc
<ogra_> we have quite some users depending on it, using it to access the initrd etc 
<ppisati> ogra_: ?
<ppisati> ogra_: what you mean? i probably never used this feature
<ogra_> it provides net access and serial access 
<rsalveti> but they are modules, not sure if they exclude each other
<rsalveti> do we need them built-in?
<ogra_> in fact i'm just working with ChickenCutlass on the container flip completely depending on exactly that feature
<ogra_> rsalveti, for initrd access we do
<rsalveti> why?
<rsalveti> we could get the module inside initrd 
<ogra_> the initrd cant carry a single module ... 
<ogra_> it gets to bg for the boot partition
<ogra_> we have only a few bytes free 
<rsalveti> why? how large is the boot partition?
<ogra_> 8M ...
<rsalveti> right, wonder why the kernel is so big for nexus 7
<ogra_> the kernel is  around 5
<ogra_> no idea
<ogra_> i didnt make the config 
<rsalveti> that can probably be fixed 
<rsalveti> but I'd like to have them in modules and fix whatever uses it to load that at runtime
<ogra_> iirc rtg looked into that a while ago
<ogra_> or apw ... i dont remeber whom i talked to 
<ogra_> its really a while agio
<rtg> ogra_, apw was doing the config review
<ogra_> cant we just wait a week and start using the grouper kernel with S ?
<ogra_> ripping out features a week before release doesnt seem sane 
<ppisati> ogra_: are these workitems still valid for S?
<ogra_> especially in the light that we have a hard frozen archive since yesterday
<ogra_> ppisati, workitems are nowadays on a monthly base :)
<ogra_> so yes, sure
<ogra_> i'll happily even drop the desktop n7 image in S 
<rsalveti> ogra_: we can wait S, for sure
<ogra_> so we dont have that issue at all anymore
<ppisati> ogra_: do you mind collecting all of them (touchscree patch, usb config $g_things, kernel size, etcetc) in a blueprint?
<ppisati> ah, if we want to drop the desktop img then...
<ogra_> ppisati, well, how about we hold back for a week and just let the desktop image die (or leave it up to the users to live with the changes/breakages)
<apw> ogra_, cirtianly it was me doing configuration reviews.  there i was basically not moving anything y->m
<apw> and therefore the kernel was still fat for android, which doesn't load modules
<ppisati> Ubuntu's archive are more hostile than the Death Valley, you can get easily killed if no one cares for you
<ppisati> and that being said...
 * ppisati -> workout -> beer -> chinese food -> evening -> EOW
 * smb skips the workout and chinese food
<jsalisbury> smb, no hurry, but when you have a chance, can you review bug 1168350  There is a fix available, but it seems fairly large to be considered for SRU
<ubot2> Launchpad bug 1168350 in linux (Ubuntu Precise) " arch_trigger_all_cpu_backtrace() results in Oops on virtualized guest" [Medium,Confirmed] https://launchpad.net/bugs/1168350
<smb> jsalisbury, I think I heard about that in the past, but back then the proposed changes were not even upstream
<jsalisbury> smb, they are upstream now in commit f447d56
<smb> jsalisbury, Hm that seems to be one. Somehow I thought to remember two or even three
<smb> anyway, will maybe put that off to next week
<jsalisbury> smb, sounds good.  thanks for looking.
<jsalisbury> smb, oh and pass some of that Chinese food over here ;-)
<smb> jsalisbury, Thats ppisati, not me
<smb> :)
<jsalisbury> :)
<jsalisbury> rtg, apw if you have a chance, can you take a look at bug 1170150
<ubot2> Launchpad bug 1170150 in linux (Ubuntu) "vmlinuz/initrd.img symlinks do not point to signed versions on kernel updates of secure boot UEFI machines" [Medium,Confirmed] https://launchpad.net/bugs/1170150
<rtg> jsalisbury, hmm, I'm having a hard time caring about that one. I guess I'm not groking the real problem.
<jsalisbury> rtg, cool, thanks for looking
<rtg> jsalisbury, lets get apw's opinion
<jsalisbury> rtg, sounds good
<rtg> jsalisbury, though we may have missed him for the day. make a note to annoy him on Monday.
<jsalisbury> rtg, will do, thanks
<apw> rtg, though i am drinking a beer ... i am still about
<apw> rtg, i am not sure we can trivially fix that for R, we have talked about wacking the non-signed version in general but ... hmmm
<rtg> apw, if you're drinking beer then you should just get lost. come back to work on Monday :)
<rtg> kamal, how about 'UBUNTU: SAUCE: (no-up) drm/i915: partially revert PCH_PWM_ENABLE quirk on Dell XPS13 SandyBridge' ?
<kamal> rtg: no, that's not really right
<rtg> kamal, right, I just read it myself
<kamal> rtg: revert PCH_PWM_ENABLE quirk for Dell XPS13-FHD
<cjwatson> Hi.  There are a load of kernel source packages still in the archive which only build for armel.  Can I remove them from raring?  linux-linaro-mx51 linux-linaro-omap linux-linaro-shared linux-linaro-vexpress linux-meta-linaro linux-meta-qcm-msm linux-n900 linux-qcm-msm
<rtg> bjf, ^^
<cjwatson> I finally have a script to detect this kind of thing ...
<bjf> cjwatson, i don't see anything there we want/need
<ogra_> do we have a vexpress kernel from our generic build ?
 * ogra_ would appreciate having a kernel for qemu system usage in the archive ... even if its old 
<cjwatson> Well, you don't right now if you're relying on linux-linaro-vexpress :)
<cjwatson> (Except in <= quantal)
<rtg> ogra_, raring has CONFIG_ARCH_VEXPRESS=y but I've never tested it using QEMU
<ogra_> isnt it just a rotten binary ?
<ogra_> rtg, well, thats enough 
<cjwatson> ogra_: It won't be referenced in any raring Packages files
<ogra_> ah
<cjwatson> It'll still be in the pool until all series containing armel are obsoleted
<ogra_> well, if we have a generic flavouor that potentially works with qemu thats enough 
<ogra_> the advantage of vexpress was that we had a netboot image for it so you could just grab vmlinuz from the archive without having to fiddle with packages
<ogra_> but yeah, armel isnt an option anyway 
<rtg> ogra_, I guess we should add the vexpress DTB to the build. otherwise I don't think that kernel will work. There are several dts files in the kernel tree. Any idea which is the right one ?
<ogra_> heh, nope ... i'm a dtb virgin :)
 * ogra_ was at all the planning discussion from day one in brussels ... never used a dtb though ...
<rtg> ogra_, as am I mostly
<bryce> tjaalton, I'll handle arges' patch, I had thought he was going to prepare a more minimalist patch so was waiting on that.
<tjaalton> bryce: ok, thanks
<tjaalton> from what I heard it should actually be fixed in the kernel, but that'll wait :)
<arges> bryce: I posted a patch
<arges> bryce: which was a backport of that earlier patch
<arges> bryce: not sure how much more minimalist you'd like it, I tried to keep it as close to upstream as possible
<arges> tjaalton: re-assigning myself to this, as I think the patch is good to go.  bryce let me know if there are any other actions you need from me
 * rtg -> lunch
 * apw beer, have a good one
<tjaalton> bryce, arges: right, it's from upstream so what choice do we have :)
 * henrix -> SIGBEER
<bryce> pshaw
<tjaalton> indeed, barely made it to the store in time to get a refill ;)
<bryce> I'll post the unrefactored in a sec; just checking it still builds.
<tjaalton> the commit from upstream doesn't even apply, the last hunk fails
<tjaalton> so you need to adjust it
<arges> tjaalton: that patch I posted in the bug adjusts the one line
<tjaalton> arges: yep
<arges> it should apply with 'git am'
<arges> ok
<tjaalton> we use quilt
<arges> i think its worth fixing cause once everybody installs raring and plugs into a projector they may get bit
<tjaalton> of course
<tjaalton> I'd have uploaded it immediately :)
<tjaalton> cause I happened to hit it myself
<arges> Ok so there is a git tree git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-intel
<arges> but since its so close, you need a debdiff
<tjaalton> yes
<arges> with the path
<arges> patch
<tjaalton> bryce is on it
<arges> ok
<arges> coool. let me know if you all need help
<tjaalton> it's trivial, drop the patch in debian/patches, update series and changelog and go
<bryce> the reason I want the minimal patch is mainly to get through sru.  If we'd gotten this in a week ago we could have just slammed it in.  But now we need to get it signed off by non-X.org people, so for their sake I want to provide as easy-to-review patch as possible
<tom231t6> hi, anyone online?
<tom231t6> in http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc7-raring/ you forgot to upload the extra debs!
<tom231t6> or do I miss something?
<tom3356> lost connection
<tom3356> I'm testing nvidia 319.12 on raring for optimus support and I need kernel 3.9
<arges> tom3356: i e-mailed the maintainer of that build script.
<^Mike> I've been asked to test this kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc7-raring/) but when I try to boot it, the kernel panics with "cant find init, try passing init=". My system has encrypted LVM set up. So, /boot is on an unencrypted partition, and then it needs to decrypt and mount / in order to continue. I figure it is trying to use the boot partition as the root partition, which would explain why it can't find init.
<Sarvatt> looks like -extra was removed a few days ago in the mainline builds so its not needed
<^Mike> As far as I can tell, the entries that got added in /boot/grub/grub.cfg are correct. At least, they look like the entries that work... same "set root=" line, same "--set-root" option on the search line, same "root=" on the linux line
<Sarvatt> tom3356, arges: ^
<arges> Sarvatt: ack
 * rtg -> EOW
<bryce> arges, it got accepted
#ubuntu-kernel 2013-04-20
<lamont> [   19.518293] Oops: 0000 [#1] SMP 
<lamont> [   19.518415] Pid: 675, comm: udevd Tainted: GF            3.8.0-19-generic #29-Ubuntu Gigabyte Technology Co., Ltd. P55A-UD3/P55A-UD3
<lamont> is that worth a bug?
<lamont> :(
<ohsix> it's at least worth looking it up, but yes
<_PanzerSajt> Hy! I have an omap4460 based tablet and I would like to install Ubuntu on it. So far I was able to compile and boot 3.9-rc6 mainstream kernel but it lacks a lots of needed drivers. I was trying to run and compile ubuntu kernel for it but it gave me this error: http://pastebin.com/CqPrgLKf If somebody could take a look at it and give me some guideance where to search I would be more than happy! Thanks :)
<yofel> Hi, if someone wanted to use the ubuntu kernel package/packaging in another debian derivative (Tanglu) is there anything in the package that one would have to remove for license/trademark/whatever reasons?
<yofel> except changing the respective fields in the control file
#ubuntu-kernel 2014-04-14
 * apw yawns
<jpds> Can someone take a look at this bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1307109
<ubot2> Launchpad bug 1307109 in linux (Ubuntu) "Alcor Micro AU9540 keeps powering down when card is inserted" [Undecided,Confirmed]
<apw> jpds, does that bit at the bottom of current dmesg repeat each time it comes and goes ?
<jpds> apw: Let me get a more current dmesg.
<jpds> apw: Attached.
<kdeuser56> where are the dbgsym packages of http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc1-trusty/ ?
<kdeuser56> or why are there no dbgsym packages for the mainline builds? generating debugsymbols would make perfect sense ... 
<kdeuser56_> I mean generating dbgsym for kernels that are not yet meant to be stable would be really helpful ...
<apw> jsalisbury, i take it you saw i had a poke at that ppc64el cmd line thing
<apw> jsalisbury, seems that the upstream code is bonkers, and doesnt use the ppc variable at all dispite having one
<jsalisbury> apw, heh, yeah.  I was just reading that.  I sent a patch upstream, but it only had the one define change.  
<apw> jsalisbury, so i'll bodge the fix we have to fix the default, and we can let you circle with upstream on it
<apw> jsalisbury, you might copy anton blanchard on it when you do, as he was involved
<jsalisbury> apw, ok, will do.  
<jsalisbury> apw, where is the correct change for the define?  Is it in one of the generic setup.h files?
<apw> "correct" yeah the one it uses is that one.  so i suspect the right fix for this is to make that actually a config option
<jsalisbury> apw, ahh, ok.
<apw> so one can make the default whatever you want on every arch, but it needs some upstream discussion
<jsalisbury> apw, thanks for digging into this
<apw> jsalisbury, np, it was being difficult to say the least, and remote debug is more than difficult in this case
<jsalisbury> apw :-)
#ubuntu-kernel 2014-04-15
<pmatulis> how do i prevent a kernel from being upgraded?  all the tricks i found via google do not work
<pmatulis> (cli please)
<bandit63> building 3.15rc1 on ubuntu 14.04 ideas getting error ... /etc/kernel/postinst.d/apt-auto-removal: 84: /etc/kernel/postinst.d/apt-auto-removal: cannot create /etc/apt/apt.conf.d//01autoremove-kernels.dpkg-new: Permission denied run-parts: /etc/kernel/postinst.d/apt-auto-removal exited with return code 2 
<bandit63> using both  make-kpkg --rootcmd fakeroot --initrd --revision=`date +%m%d%Y` --append-to-version=-`date +%m%d%Y` kernel-image kernel-headers
<bandit63> and time fakeroot make-kpkg --initrd --revision=`date +%m%d%Y` --append-to-version=-`date +%m%d%Y` kernel-image kernel-headers
<tseliot> apw: hey, have you tried the brcmsmac driver in Linux 3.11? Any advantages over the proprietary driver?
<tseliot> I'm looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1306928
<ubot2> Launchpad bug 1306928 in ubuntu-drivers-common (Ubuntu) "Broadcom STA driver gets autoinstalled on BCM4313, where it's no longer needed" [Medium,Triaged]
<apw> tseliot, i find for my h/w the wl doesn't work properly, and 'smac is my only option
<apw> saucy and later i guess
<tseliot> apw: ok, so I guess it wouldn't be such a bad idea to default to the open driver then
<tseliot> and to stop autoinstalling the proprietary one
<apw> tseliot, for my h/w indeed
<tseliot> apw: ok, thanks
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 22th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<miseria> "el soÃ±ador no es quien sueÃ±a un futuro mejor; el soÃ±ador es aquel que  descubre que la vida es un lindo sueÃ±o" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<FlacBean02> I'm bisecting a kernel bug at the moment. I just wanted to know if I finish bisecting all commits from Ubuntu-3.11.0-19.33 to Ubuntu-3.11.0-18.32, Am I going towards a new release or older release now?
#ubuntu-kernel 2014-04-16
<arges> ppisati: hey. testing trusty on my pandaboard, dmesg is getting spammed with "gic_timer_retrigger: lost localtimer interrupt" have you seen this before?
<ppisati> arges: nope
<ppisati> arges: flag@panda:~$ dmesg | grep "gic_timer_retrigger" | wc -l
<ppisati> 0
<ppisati> 3.13.0-24-generic #46-Ubuntu
<arges> ppisati: this is on ES Rev B 
<arges> and i have same kernel version
<arges> oh wait
<ppisati> panda es rev b1
<arges>  3.14.0-armv7-x3 
<bjf> jsalisbury, bug #1285723
<ubot2> Launchpad bug 1285723 in linux (Ubuntu Precise) "cifs: connect: dfs doesn't work where servers using package signing are mixed with servers which don't use package signing" [Medium,In progress] https://launchpad.net/bugs/1285723
<bjf> jsalisbury, is this person testing the kernel that is in -proposed or not?
<jsalisbury> bjf, His comment suggests that he is.  He didn't indicate if the -proposed kernel fixes the original bug or not.  Just that both have this new signature issue.
<jsalisbury> bjf, maybe I need to clarify my comment.
<jsalisbury> bjf, s/new signature issue/required key not available issue/
<bjf> jsalisbury, yeah, can't tell if this helped his issue or not or if he's moved on to another issue
<jsalisbury> bjf, I just added another comment to see if he'll respond.
<apw> xnox, http://people.canonical.com/~apw/lp1308685-trusty/
<rtg> hallyn, are there any unprivileged container gotchas or limitations that we should mention in our release notes ?
<hallyn> rtg: not that I can think of.  stgraber ^ ?
<hallyn> rtg: I'm heading out righ tnow, will be on later if there's any more qs
<rtg> hallyn, ack. thanks
<stgraber> might be worth mentioning the apparmor bug?
<stgraber> dmesg getting flooded
<rtg> stgraber, do you know that bug number off hand ?
<stgraber> jdstrand, jjohansen: what's the bug number for that apparmor_unix_may_send flood?
<rtg> stgraber, tough to do any LP searches when it keeps timing out
<jjohansen> stgraber: hrmmm, I'm not sure I can't find it in the bug lists
<stgraber> jjohansen: mind filing one then since I guess you know exactly what this is all about? :)
<jjohansen> stgraber: yeah, I need it anyways so that I can send the patch for it
<jjohansen> stgraber, ogasawara: bug#1308761
<jjohansen> ogasawara: I'll send a patch for it along with some other patches to the list today
<ogasawara> jjohansen: ack, thanks
#ubuntu-kernel 2014-04-17
<tjaalton> if it proves working, would something like https://git.kernel.org/cgit/linux/kernel/git/johan/usb-serial.git/patch/?id=cec285642a121069e9c05cfb4189871043d8c39c qualify as SAUCE?
<tjaalton> my youngest daughter has type1 diabetes, and sending data off the insulin pump for the doctor needs this damn device
<ogasawara> tjaalton: I'd consider that patch saucy worthy.  looks like it was undergoing some review/testing upstream on the linux-usb list
<tjaalton> yeah
<rtg> ogasawara, it is deeply disturbing to me that you and tjaalton are considering patches for a released kernel that have not been exposed to the Ubuntu community. poke, poke.
<ogasawara> rtg: heh, well I'm assuming tjaalton will send a patch to the mailing list when he's ready :)
<tjaalton> sure :)
<tjaalton> not assuming you to pull it from there
<tjaalton> actually, I'm hitting that enumeration issue with superspeed ports
<tjaalton> but it happens regardless of the patch
<tjaalton> yeah seems to work on usb2, now I need to figure out how to get the data from it..
<tjaalton> looks like there are no tools for it yet, so I'll check out the situation and get back to you when there's something to use with it
<tjaalton> some background in http://www.diabetesmine.com/2013/01/the-ethical-imperative-of-diabetes-interoperability.html
<tjaalton> bewest is the guy who emailed linux-usb about the enumeration issue
<bjf> tjaalton, saucy doesn't have a lot longer on support
<tjaalton> bjf: yeah I meant as sauce patch
<tjaalton> it's not upstream yet, maybe for 3.16
<bjf> tjaalton, still... best be upgrading to trusty :-)
<tjaalton> that's what I use
<tjaalton> ogasawara probably just typoed it :)
<tjaalton> sauce/saucy
<ogasawara> tjaalton: oops, yes, that was a typo.  I did mean sauce
<tjaalton> :)
<smoser> rtg, you have trusty on your x120e ?
<rtg> smoser, yup
<smoser> rtg, does it resume from suspend ?
<smoser> because i dont. 
<smoser> it dies, to the point where i have to pull the battery out on next reboot
<rtg> smoser, actually, it has _never_ failed. I'll go update it andmake sure.
<smoser> rtg, well, its only ever worked really well for me (suspend/resume). but just did fresh install last night (which is a pita because of the UEFI issue bug 1040320).
<ubot2> Launchpad bug 1040320 in ubiquity (Ubuntu) "Lenovo x120e install fails when in UEFI mode" [Undecided,New] https://launchpad.net/bugs/1040320
<smoser> rtg, well, ijust filed bug 1309112
<ubot2> Launchpad bug 1309112 in linux (Ubuntu) "x120e does not resume from suspend" [Undecided,New] https://launchpad.net/bugs/1309112
<rtg> smoser, mine is still updating
<rtg> ppisati, looks like some of the arm configs just turn off stack size warnings. 'git grep CONFIG_FRAME_WARN'
<ppisati> rtg: i can see it's in our config _at least_
<ppisati> (trusty-amd64)ppisati@tangerine:~/ubuntu-trusty$ grep -Ri FRAME_WARN debian.master/config/
<ppisati> debian.master/config/powerpc/config.common.powerpc:CONFIG_FRAME_WARN=1024
<ppisati> debian.master/config/armhf/config.common.armhf:CONFIG_FRAME_WARN=1024
<ppisati> debian.master/config/amd64/config.common.amd64:CONFIG_FRAME_WARN=1024
<ppisati> debian.master/config/arm64/config.common.arm64:CONFIG_FRAME_WARN=1024
<ppisati> debian.master/config/i386/config.common.i386:CONFIG_FRAME_WARN=1024
<ppisati> debian.master/config/ppc64el/config.common.ppc64el:CONFIG_FRAME_WARN=2048
<rtg> ppisati, yup, which I why I noticed it. OK, looks like an upstream patch.
<rtg> which is*
<rtg> ppisati, hmm, must be an artifact of building that module for powerpc. on armhf the frame size is only 472 bytes.
<rtg> I am assuming wireless/ti/wlcore can only be loaded on arm
<ppisati> yep
<rtg> ok, guess I'll leave it alone
<ppisati> rtg: you got 8k usage for wlcore on ppc?
<rtg> ppisati, 9172
<cking> stack scribbler then
<rtg> cking, except that wlcore will never get loaded on powerpc
<cking> ah
<ppisati> rtg: well, i don't know if TI relicensed it's wifi IP for a discerete chip/company
<ppisati> rtg: but i doubt
<ppisati> rtg: and in any case it would be another driver
<smoser> rtg, upgraded  yet?
<rtg> smoser, uh, yeah. works fine.
<smoser> really?
<rtg> would I kid you ?
<smoser> i think you have that rtl wireless.
<smoser> i dont knw what could be different.
<smoser> other than i put a ssd in yesterday
<rtg> smoser, what is your wifi ? I haven't looked at the bug yet
<rtg> I have an SSD
<rtg> rtl8188ce
<smoser> https://launchpadlibrarian.net/173032656/susres.2014-04-17_12%3A45%3A58.004375.crash
<smoser> rtg, you dont boot with UEFI do you?
<rtg> smoser, not that I recall. I'm pretty sure I don't have grub-efi installed.
<rtg> smoser, actually, I _do_ have grub-efi-amd64 installed.
<smoser> i could not get bios to recognize anything the installer laid down.
<smoser> i let it do auto once
<smoser> and did it myself another.
<smoser> i wonder why i'm unlucky.
<smoser> apw, your name is on /usr/share/apport/apportcheckresume
<smoser> that runs after my system fails to resume. and i think it crashes.  *it* causes a dialog (i think). but maybe i'm misunderstanding something.
<apw> smoser, it is meant to cause an apport report when resume fails indeed
<apw> smoser, its job is to work out that we have booted but that the last thing we did was suspend not shutdown; in that case it files a bug report
<smoser> well... hm.. its confusing.
<smoser> what you're saying makes perfecdt sense. and thats what i thought
<smoser> but then
<smoser> the dialog that comes up says
<smoser> "Sorry, the application apportcheckresume has stopped unexpectedly"
<smoser> ExecutablePath /usr/share/apport/apportcheckresume
<smoser> whiich made me think *it* crashed when something else ran it.
<smoser> am i just not reading the dialog right?
<apw> it may well have does it wrong, can you let it file a bug, and send me the name
<apw> number even
<smoser> well, on that system it never gets there.
<smoser> the dialogs just go away
<smoser> i say "continue", then nothing.
<apw> well that is quality, ok, i'll try and reproduce it, could you email me direct and remind me, as i will forget by tuesday
<smoser> happy easter.
<smoser> i'll try to remember too.
<apw> smoser, you too :)  /me blames it on p itt i or someone :)
#ubuntu-kernel 2014-04-18
<hallyn> say, how come CONFIG_MEMCG_KMEM is diabled in trusty?  
<hallyn> (i'm sure there's a good reason, but i can't recall, or never knew)
<BjoernC> moin moin
<ypwong> s
<ypwong> oops
<hallyn> apw: hey, we were wondering how come CONFIG_MEMCG_KMEM is disabled in trusty?
<rtg> hallyn, you might be wondering until Tuesday if you're gonna depend on apw to answer
<rtg> hallyn, frankly, I'm not sure why CONFIG_MEMCG_KMEM is not enabled. Likely an oversight 'cause no body howled ?
<hallyn> rtg: hm, ok, thx
<hallyn> rtg: mainly it's the upstream-recommended way to prevent forkbombs,
<hallyn> the reason they refuse to allow a 'ntasks' cgroup
<rtg> hallyn, it kind of looks like something we should have enabled. how about starting a bug for it ?
<hallyn> rtg: will do, thanks
<wedgwood> I've been doing some testing to see about moving to Trusty from Debian and I'm seeing odd performance characteristics.
<wedgwood> Seems that memory throughput is considerably slower on Ubuntu than anything else I've tried, but only for allocation sizes <512K
<wedgwood> as measured with sysbench --test=memory
<hallyn> rtg: filed bug 1309586
<ubot2> Launchpad bug 1309586 in linux (Ubuntu) "enable CONFIG_MEMCG_KMEM" [Undecided,New] https://launchpad.net/bugs/1309586
<rtg> wedgwood, slub v.s. slab ?
<rtg> hallyn, ack
<wedgwood> rtg: I don't know what those are :(
<rtg> memory allocators
<wedgwood> is that dynamically tunable?
<rtg> nope, they are configured at compile time.
<wedgwood> rtg: whichever comes in the stock generic kernel. Is that something I can see with getconf?
<rtg> wedgwood, egrep "SUB|SLAB" /boot/config-3.13.0-24-generic
<wedgwood> # CONFIG_SLAB is not set
<wedgwood> CONFIG_SLUB=y
<wedgwood> The CentOS kernel I'm comparing with is SLAB. I'll check the debian one too
<wedgwood> the debian kernel is SLAB, same as Ubuntu
<wedgwood> so that doesn't seem to be the differentiator
<wedgwood> *SLUB for debian, I meant
<hallyn> rtg: thanks :)
<caglar10ur> could any one why trusty comes with CONFIG_MEMCG_KMEM disabled? Was talking with hallyn yesterday about it and he suggested me to ask here
<hallyn> caglar10ur: rtg has posted a patch to change that :)
<caglar10ur> hallyn: ah nice :)
<hallyn> see pad.lv/1309586
<hallyn> caglar10ur: i suspect it's something i should have noticed two months ago
<caglar10ur> hallyn: great, Iâm a happy person now
<caglar10ur> hallyn: thatâs also my fauly, Iâve been using trusty kernel for months and never mentioned that before :)
<caglar10ur> hallyn: I was changing the config and repacking it
<hallyn> heh
#ubuntu-kernel 2014-04-19
<xnox> apw: i am pretty sure i've mailed my patch wrong. i guess that's common for 1st timers.
<xnox> (got wrong combinations of to/cc... twice...)
#ubuntu-kernel 2014-04-20
<miseria> "vamos por el mundo, odiando y rechazando, aspectos que creemos despreciable de los demas y de uno mismo" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
#ubuntu-kernel 2015-04-13
<FourDollars> Hi, http://people.canonical.com/~kernel/info/kernel-version-map.html is not up to date. Could someone help to update it?
<apw> FourDollars, hmmmm, i'll stick it on my list, thats just strange
<FourDollars> apw: thx
<apw> FourDollars, ok, seems we lost a cronjob somewhere along the line, i've fixed that up and re-run it, it should now be up to date
<FourDollars> apw: It works now. Thx a lot.
<ogra_> apw, do you happen to know who defines the autopkg tests for initramfs tools ? 
<ogra_> looking at why migration of my last initramfs-tools upload takes so long i see that one of its tests seems to be to build the amd64 and i386 kernel binaries from source ... that seems quite overkill (and i'm not sure what it is supposed to test)
<apw> ogra_, that is a limitation of the dep-8 autorunners, that test is there to ensure that things like compiler updates and the like don't stop the kernle from buildnig
<ogra_> but why initramfs-tools ? 
<apw> ogra_, however, there is no way as things stand to tell which dpeendant package is triggering the testing
<ogra_> ah :/
<apw> it is interdependant on the kernel, so it triggers the kernel tests
<apw> and we can't tell "why" so we can only do "all of them"
<ogra_> yeah, understood ... quite awkward 
<apw> pitti can tell you more about what would be needed to make it better, better than i can, but we basically need the adt interface into the tests to have the concept of "why"
<apw> as we also rebuild the kernel as a result of buiding the kernel when testing the kernel itself, which is as dumb as a large bag of hammers
<ogra_> right, yeah, i just wanted to know whats triggers it ... (why it also triggers boot tests on a device where it cant replace the initrd is another thing ... (phones))
<apw> ogra_, yes ... adt is pretty lame at these kinds of time.  it is building a kernel you don't even run too
<ogra_> well, lookin at this boot test stuff it seems to seriously do something ... even with reboots and all ... i just dont get how you can test it if you have no way to actually use the binary initrd 
<apw> ogra_, it is curtinaly not tied to initramfs-tools intentionally and thoughtfully, so do not be suprised if it makes no sense, looking for sense in the behavoiur will make your head hurt in spades
<apw> it is the price of doing business with britney
<ogra_> lol
<ogra_> ok
<apw> having a way for the adt tests to know the context of their triggering so they can be more selecting in what any why they test should be on CIs backlog if it isn't already
<ogra_> yeah
<ogra_> this all-new "agile" development is pretty slow :)
<jdstrand> ogasawara: hey, what is the status of the snappy 15.04 kernel-- is it frozen? apparently arm64 seccomp is not (enabled/available) on the snappy kernel and was wondering if we should pursue trying to get this in: http://lwn.net/Articles/623201/
<ogasawara> jdstrand: checking, one sec.  I'm sitting right next to ppisati.
<jdstrand> awesome, thanks!
<ogasawara> jdstrand: sooo, we believe it is enabled already for arm64
<jdstrand> hmm
<jdstrand> maybe we just need a rebuild for the snappy package
<jdstrand> err
<jdstrand> seccomp package
<jdstrand> let me try that
<jdstrand> ogasawara: I seem to need 2.2.0. thanks for checking that
<ogasawara> jdstrand: np
<igalic> so! i've asked this queestion already in #ubuntu-server, but nobody was able to answer it :( so i'm asking here again!
<igalic> i've updated my cobbler setup with the ubuntu 14.04.2 server iso (was .1), using its initrd and kernel https://gist.github.com/igalic/769087e09c049e225665 to pxe install virtual machines. The result, however, is: http://i.imgur.com/9aQFmdz.png
<igalic> found, and updated this bug, https://bugs.launchpad.net/maas/+bug/1302158 not sure it's the exact one i'm hitting.
<ubot5> Ubuntu bug 1302158 in MAAS "Default Installer: No kernel modules were found" [Undecided,Invalid]
<igalic> hrmâ¦ it appears that my isp's mirrir is lagging behind.
#ubuntu-kernel 2015-04-14
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<cristian_c> jsalisbury, can I steal you some seconds?
<cristian_c> missing few minutes
<jsalisbury> cristian_c, sure
<cristian_c> sorry
<cristian_c> quickly
<cristian_c> jsalisbury, I'd like to know if there are news about the wireless bug
<cristian_c> about build failure.... etc..
<cristian_c> *revert
<cristian_c> sorry
<jsalisbury> cristian_c, I still haven't been able to get the kernel to build sucessfully yet.  Ill dig into it some more to make some more progress
<cristian_c> ok
<cristian_c> jsalisbury, thanks
<jsalisbury> cristian_c, np.  I should have an update shortly
<cristian_c> ok
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minute##
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting is actually canceled today due to most of the team sprinting
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 21st, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/
#ubuntu-kernel 2015-04-15
<hallyn_> arges: hey, so regarding the gdb+qemu, did cjwatson talk to you yesterday?
<arges> hallyn_: briefly, just recapped what you said to me
<hallyn_> arges: when i talked to him he was wondering about your workload - i.e. could it have been booting kernel still in real mode when it failed,
<hallyn_> and he mentioned using the multi-arch version of gdb
<arges> hallyn_: I was already booted when I attached gdb
<arges> hallyn_: and I'm running all 64-bits L1/L0 etc
<arges> and i've even tried to manually set arch with no luck
<hallyn_> ok, thx
<grkvlt> hi. is kernel.ubuntu.com down for maintenance? when will it be available again? cannot connect right now...
<ppisati_> chiluk: https://www.raspberrypi.org/xenon-death-flash-a-free-physics-lesson/
<arges> hallyn_: for bug 1392176 is this waiting on a kernel patch: https://lkml.org/lkml/2015/4/10/515?
<ubot5> bug 1392176 in linux (Ubuntu) "mounts cgroups unconditionally which causes undesired effects with cpu hotplug" [Medium,Confirmed] https://launchpad.net/bugs/1392176
<arges> grkvlt: we are having some server issues, its a known problem and we are actively trying to fix it. 
<grkvlt> arges: thx. any idea on an ETA or just wait and see ;)
<arges> grkvlt: no idea when it will be fixed, but we are all hoping soon
<grkvlt> arges: np. i think i can work around it. its a requirement for a demo i'm giving ;(
#ubuntu-kernel 2015-04-16
<FourDollars> Does anyone know how to use S0ix on Ubuntu?
<infinity> zequence: Your changelog for precise lowlatency is a bit weird, you lost the 3.2.0-80.82 entry, and you also accidentally included cruft at "debian.lowlatency/changelogn"
<zequence> infinity: Really? Ok, I'll have another look at that.
<zequence> infinity: We
<zequence> Sorry
<zequence> We're going EOL with Precise this April, with the rest of the flavors (or at least Xubuntu)
<zequence> So, I'm considering also stopping maintenance for linux-lowlatency, all though it's not flavor specific
<infinity> zequence: Assuming you were the only flavour that shipped lowlatency on images and/or offered to install it, dropping support for it with the rest of your packageset seems fine to me.
<infinity> zequence: OTOH, if you want to maintain it for another 2 years to be a Nice Guy, you can too.  But from my POV, you have no obligation to do so.
#ubuntu-kernel 2015-04-17
<noob_rpi>  Hi, I am trying to cross compile a kernel for raspberry pi 2. The deb-pkg build generates an armel.deb instead of armhf.deb. How do I generate the armhf deb?
<RAOF> noob_rpi: Build with the armhf cross compiler, rather than the armel one?
<noob_rpi> RAOF, using that... still generating the el deb 
#ubuntu-kernel 2015-04-18
<HiGregS> I have 
<HiGregS> xps13 (new), looks like 15.04 has the updates and patched kernel for mic and sound. will the fixes likely be back ported to 14.04 or 14.10, or should I expect the next LTS (16?) to contain those and NOT 14?
<HiGregS> I'm not totally familiar with terms like "upstream" and have been substantially away from Linux since 1.0 kernel days...
<HiGregS> (first I think I recall is 0.98, can that be right??!!)
<infinity> zequence: Oh, but it would still be nice for your current lowlatency update to not be crufty, expecially if it's going to be the last.
#ubuntu-kernel 2015-04-19
<legal> help my - command patch - auto YES?
<iseon> When building the ubuntu kernel (generic target) from mainline ubuntu repositorie on a Debian box I get the following error at the end of the build:
<iseon> dpkg-shlibdeps: error: syntax error in debian/control at line 13: first block lacks a source field
<iseon> is it because I am building on a debian box?
<iseon> Followed the step here https://help.ubuntu.com/community/Kernel/Compile under Build the Kernel(s)
<iseon> it seems so --- debian/control files for debian packages all seem to have a Source: field
<iseon> I am wondering how I can avoid this error and build the ubuntu kernel on debian..
<iseon> perhaps simply adding the field will fix it :) i'll give it a shot.
#ubuntu-kernel 2016-04-18
<denlud> Hey Guys
<denlud> Can somebody tell me why the Option CONFIG_MMC_UNSAFE_RESUME cant be set in new kernels? (4.0+)
<denlud> I want to bind my sd card as /home, but then my laptop cant use suspend. The solution for people with an older kernel was this Option. Now it doesnt exist anymore.
<apw> denlud, well from the name UNSAFE does not sound that positive
<apw> denlud, did you have some kind of kernel command line override to enable that mode ?
<denlud> It declares a SD Card as unremoveable.
<denlud> Its only unsafe, if you change your sd cards.
<ogra_> i think yoiu can enforce that from userspace somehow
<amitk> denlud: that behaviour became the default IIRC from chatting to the MMC maintainer and so the option went away
<apw> as being allowed to be, but ... does the option have an override to opt-in, otherwise that is a risky proposition
<denlud> It becomes default?
<denlud> But my /home isnt working after suspend....
<apw>    - CONFIG_MMC_UNSAFE_RESUME=y is now default behavior
<apw> cirtianly the changelogs imply the option became the default which fits amitk's memory
<amitk> yes
<amitk> denlud: and here is a line from his his weekly report to me:
<amitk> * Submitted a new version of the patchset that makes MMC_UNSAFE_RESUME
<amitk> default behaviour.
<denlud> Ok, but it isnt working....
<denlud> What should i try anymore....i already tried alot :(
<amitk> denlud: try talk to ulfh on #linaro-kernel
<ogra_> https://www.kernel.org/doc/menuconfig/drivers-mmc-core-Kconfig.html
<ogra_> This option sets a default which can be overridden by the
<ogra_> module parameter "removable=0" or "removable=1".
<apw> i think that may no longer exist
<ogra_> (now dont ask me how to set it if there is no module :P )
<denlud> But that was my Question.....:D
<ogra_> did you dig in sysfs ?
<denlud> dig in sysfs? Sorry i am a Linux Beginner...
<ogra_> find /sys -name '*removable*'
<ogra_> check if there is anything mmc related
<ogra_> aha ... so it seems there is a cmdline option:
<ogra_> mmc_core.removable=0
<ogra_> add that to youir kernel commandline 
<ogra_> and see if that fixes it
<denlud> yes that could be the solution!!
<denlud> If that fixes my Problem, i love you ogra_ :D You dont know what i already make to get my /home work...
<apw> denlud, that option no longer exists in later kernels
<apw> it was removed when the option was set to =y and removed
<denlud> really?
<apw> yes
<ogra_> how mean
<apw> not really, i think your sysfs thing is worth persuing
<apw> as the kernel behaves different depending how the card is marked removable/not
<apw> but the unsafe toggle for all cards is gone
<apw> as many machines using it have two slots one inside which is not-removable and one outside which is
<apw> so they need both semantics, different per card
<apw> whether you can lie to the kernle and say your external card is "not-removable" less easy to tell
<apw> on quick inspection
<apw> it's you arm types who have made this this way :)
<denlud> I dont get why my SD Card isnt working, and my internal space is working. They are both MMC's.
<denlud> Oh ok, apw...
<ogra_> ubuntu@localhost:~$ find /sys -name '*removable*'|grep mmcblk1
<ogra_> find: â/sys/kernel/debugâ/sys/devices/platform/soc/7864900.sdhci/mmc_host/mmc1/mmc1:1234/block/mmcblk1/removable
<ogra_> so seems on systems with mmc i have such a sysfs node
<denlud> dennis@Yoda:~/kernel/linux-source-4.4.0$  find /sys -name '*removable*'|grep mmcblk1
<denlud> find: "/sys/kernel/debug"/sys/devices/pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable
<denlud> : Keine Berechtigung
<ogra_> find the equivalent on your system and make sure the content is "0"
<ogra_> well, if mmcblk1 is your mmc device ... else your command needs to filter "mmcblk0"
<denlud> my working mmc device is mmcblk0 (the internal space)
<ogra_> so:  find /sys -name '*removable*'|grep mmcblk0
<apw> shoving a card in mine it is marked non-removable ... so i'd kinda expect that work be ok
<apw> would
<apw> but perhaps that is a lie from my bios or something, hmmmm
<denlud> find: "/sys/kernel/debug"/sys/devices/pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable
<denlud> how can i lie to my kernel now, and say its non removeable?
<denlud> I dont get it sorry...
<ogra_> why do you look at mmcblk1 ?
<ogra_> (you said above it is mmcblk0)
<denlud> No, the already working mmc is mmcblk0
<denlud> home "is" mmcblk1
<apw> denlud, what sort of machine is this ...
<denlud> Its a Lenovo 100s
<denlud> and it only has 32Gb internal space. 14" version
<apw> denlud, and is the mmcblk0 "inside" and mmcblk1 a removable slot ?
<denlud> Yes.
<apw> and when you s/r what happens to your card goes into error or something ?
<denlud> https://forum.ubuntuusers.de/topic/sd-karte-home-wird-falsch-behandelt/
<denlud> Here I posted all outputs.
<denlud> Dont want to post It here, its very much...
<apw> yep
<apw> well on a cursory examination i cannot actually see a way to override the behaviour, it seems to be defined
<apw> by the machine definition telling the slot whether it is removable, and if it is, it gets zapped on s/r
<denlud> My second output I posted there was after suspend, when my /home isnt working anylonger. And the programs are already crashed
<denlud> So I must try a flipping of the bios removeable bit?
<apw> denlud, i am not sure you would even have such a setting, you might, but ...
<apw> though the description implies the card should be handled as if the old UNSAFE is set, so i am not sure
<apw> why this is not working as one would expect, i guess some later change
<denlud> http://apple.stackexchange.com/questions/113202/can-i-mark-a-sd-card-as-permanent-storage
<denlud> Oh, that is for apple. I thought if it would be for windows. I can install Windows. flipping the bit in the BIOS, install Linux and be happy.
<denlud> Seems like I have to give my Laptop back...
<denlud> Or should i try flipping the BIOS non removeable bit? pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable
<apw> denlud, i have no idea if that is even the right kind of bit as that is marked non-removable already ... right, it is 0
<denlud> dennis@Yoda:~/kernel/linux-source-4.4.0$ cat /sys/devices/pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable
<denlud> 0
<apw> this descrption still says that the kernel should be behaving as it was with unsafe set, which should work
<apw> ie the card should just be being s/r as well
<denlud> You think the problem must be somewhere else?
<apw> it feels like the card is not handling s/r well
<apw> i wonder if i can confirm that here somehow ...
<denlud> Can i send you a pastebin link, i make some orders after suspend. And there some I/O Errors I think.
<denlud> *?
<denlud> http://pastebin.com/FwzhraHt
<denlud> This output is after suspend. Maybe you can take a look at it.
<denlud> (At the moment when /home isnt working)
<ogra_> because it becake readonly obviously
<ogra_> *became
<denlud> ...can I do something against that bevior?
<apw> denlud, ok i just added an sd card in my external sd slot, which i believe is marked removable
<apw> denlud, and after a s/r it is still there and working, no errors
<apw> denlud, what kernel version are you using 
<denlud> I tried 4.2, 4.4.0-12 and 4.4.0-18 and 4.4.6
<apw> so i am using 4.4.0-20 and it worked there for me, but i would expect -18 to be the same for mmc things
<apw> so that for me suggests it is machine specific in some way, but i am not really sure what to suggest as mine works
<apw> or at least not affecting everyeone
<denlud> Maybe I try another SD Card
<denlud> What datasystem are you using FAT?
<apw> denlud, ext4, so something which cares if the media is ripped out
<denlud> Ok, so i try another SD Card now and thats all i can try or?
<apw> i am out of obvious ideas at this point
<denlud> Ok, but thank you and ogra_ for your help.
<denlud> And sorry for my english, I dont write in english very often.
<apw> np
<apw> your english is perfectly understandable
<fg__> cking: any news about pkg-zfs/pkg-spl packaging repositories? the one at git://kernel.ubuntu.com/cking/pkg-zfs.git is still very much out of date, and the zfs user space source packages don't reference anything..
<fg__> also are there any plans to include ZFS support in the ubuntu installer? couldn't find anything in the beta 2 iso that would allow me to setup zfs as root fs
<cking> fg__, i will get onto that, just I'm buried in some other higher priority tasks at the moment
<cking> fg__, no, it's not going to be supported in the 16.04 installer
<fg__> I figured you would have other stuff on your plate with the nearing release, but figured asking would not hurt ;) thanks!
<smb> apw, So fwiw I dug out an old aspire one that got mmc card reader and I neither can see any attempt (4.4.0-18) to eject the card and can suspend/resume even with an ext3 mounted and cd'ed into the path on a terminal window to keep it occupied
<cpaelzer> Hi, I've analyzed bug 1570195 down to an issue in DPDK (not clear what it is exactly yet) and the kernel (can drive virtio into an infinite loop)
<ubot5`> bug 1570195 in linux (Ubuntu) "Net tools cause kernel soft lockup after DPDK touched VirtIO-pci devices" [Medium,Confirmed] https://launchpad.net/bugs/1570195
<cpaelzer> smb: arges: ^^ the bug holds a lot of debug info, but I'll give you the tl;dr and ask you a few important questions for confirmation before I go out to the dpdk and kernel community
<cpaelzer> the most important open question to me would be - "what would need to happen" in the virtio protocol/host/guest-implementation so that the loop at the end of virtnet_send_command becomes an infinite loop
<cpaelzer> it seems the buffers never change/refill again - but that is my assumption
<cpaelzer> look at this for the loop http://lxr.free-electrons.com/source/drivers/net/virtio_net.c#L1011
<smb> cpaelzer, maybe you allow me/us a bit to read into the bug
<cpaelzer> oh absolutely - I'm happy about a few more eyes trying to reinterpret
<arges> yea what smb said : ) lots of data
<cpaelzer> I might have diverged from the right way several times
<smb> cpaelzer, There is rarely "the" right way anyway
<arges> cpaelzer: without reading the entire bug, have you been able to eliminate any variables causing this bug? dpdk/ovs/virtio/multiqueue ; does it work with newer kernel version, etc
<cpaelzer> yes
<cpaelzer> ovs is out of the scope
<cpaelzer> also dpdk doesn't need to run traffic, just initializing the devices is enough
<cpaelzer> anything that goes through virtnet_send_command seems to block
<arges> and upstream dpdk also fails with the same issue?
<cpaelzer> I didn't check an upstream kernel yet, but can do that along you are reading this
<smb> cpaelzer, with initializing you mean let the app grab the devices not bound to a linux driver
<cpaelzer> smb: this is virtio - dpdk grabs the device even while bound with a linux driver
<cpaelzer> that is part of the problem as it leaves it behind in a broken state
<cpaelzer> arges: I can test upstream versions of both over the next hour and let you and the bug know - a good test for sure
<cpaelzer> not that I would have seen anything in the dpdk commits, but one can never be sure
<arges> cpaelzer: yup
<smb> cpaelzer, Hm, imo that should not be possible and probably is the problem. While the virtio network driver is bound to the device dpdk should not be able to directly access it. But thats right now a high level opinion (without much research)
<cpaelzer> smb: it does work and it is how the people use it
<cpaelzer> smb: which doesn't counter your opinion at all - I wondered myself at first
<cpaelzer> smb: I asked on the DPDK channel what the opinion of the DPDK Maintainers to that is
<cpaelzer> e.g. do they epxect people to reinitialize devices ?
<cpaelzer> or even not to use them while bound to virtio-pci in general (but what would the PMD driver be for then)
<smb> cpaelzer, I could imagine that being bound there, though there is also the virtio bus involved and there the virtio-net driver. But with the whole stack set up I can imagine that virtio-net could make certain assumptions which may be messed up by something else touching the lower level protocol
<cpaelzer> smb: thanks, that is like a +1 to my theory
<cpaelzer> still in general we would like to protect the kernel by e.g. detect too much retries in that loop and bail out right?
<cpaelzer> I'll later on once confirmed on latest upstream of kernel and dpdk send mails to their mailing lists
<smb> cpaelzer, heh... well the question is a bit whether virtio protocol should ever be in the situation to have a loop. The answer from that side might be that should never happen so one needs to fix the loophole of getting there.
<cpaelzer> IMHO the kernel should get a protection to return an error instead of hanging
<cpaelzer> and DPDK should more clearly state to either not do it this way OR add something like "after you touched it it is broken, you need to reinit"
<cpaelzer> smb: yeah, but so far I con only point at the end of the loophole and can't clearly say which part breaks it :-)
<smb> If the virtio nic would behave like a physical one you would get an error when trying to access it without rebinding to some userspace io driver, wouldn't you
<cpaelzer> smb: yes
<cpaelzer> smb: also a lot of people ran into trouble by dpdk (by default) grabbing all virtio-pci devices (usually shutting your ssh connection down)
<cpaelzer> unfortunately so far no one responded on the DPDK IRC chan
<smb> cpaelzer, Oh I know... 
<cpaelzer> but if nothing gets back the mail will do
<cpaelzer> you have to blacklist/whitelist things to go on with virto-pci
<cpaelzer> ah you mean you ran into that smb?
<smb> Yeah... not sure that was even with real hw and accidentally forgetting the blacklist ...
<smb> back in 2.0
<smb> at least some state of kiss your network connectivity good bye after trying what happens when I run testpmd...
<cpaelzer> smb: ha - the dpdk maintainer responded
<cpaelzer> smb: the admin is supposed to reinitialize
<cpaelzer> known deficiency
<cpaelzer> I'll submit patches for the docs of dpdk and our readme in packaging and our serverguid doc about it
<cpaelzer> yet I think the kernel should protect itself in some way and will start the discussion on that later as well
<smb> cpaelzer, yeah somehow it should be similar to real hw. I just cannot really say how this all should interact together...
<cpaelzer> smb: there is a patch that it no more initializes when bound to virtio-pci
<cpaelzer> smb: just discussing with the DPDK maintainer - I'll try to backport that
<cpaelzer> that would mean a user would have to unbind it from virtio-pci before using it in dpdk
<cpaelzer> and to use it in the normal linux world would have to rebind it
<cpaelzer> that would reinitialize and all is good
<smb> cpaelzer, I think that would make it behave "normal" so much better 
<cpaelzer> ack
<jsalisbury> lamont, I pinged upstream regarding you bug again.  I cc'd you on the mail, so you can stay in the loop.
<lamont> woot
<denlud> Heey whats up?
<denlud> I have a Problem with my diskspace, would be great if someone can i help me. I have downloaded to much porns, now my home memory is full. How can i expand it with an external drive?
#ubuntu-kernel 2016-04-19
<hggdh> sfilter
#ubuntu-kernel 2016-04-20
<mercutio> i noticed that ubuntu trusty seems to have the xenial lts kernel available already.  is this already considered stable?
<mercutio> it seems that options are to have a kernel that's only supported until August, or use xenial kernel?   and there seems to be an unpatched bug in 3.13...
<apw> mercutio, 3.13 is the release kernel so has 5 years of support ...
<mercutio> but it's not an upstream lts support version so only vulnerabilities are fixed?
<mercutio> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1423672
<ubot5`> Launchpad bug 1423672 in linux (Ubuntu Trusty) "ext4_mb_generate_buddy:756: group N, block bitmap and bg descriptor inconsistent: X vs Y" [High,Confirmed]
<mercutio> i was looking at that bug which doesn't seem to be fixed
<apw> mercutio, lts-xenial i would not normally suggested until the .1 release of the lts, it is considered an early preview before then
<mercutio> so would 4.2 be recommended for something to use for a long time?
<mercutio> having file system corruption bug of course is not really desired
<apw> kamal, ^
<arges> mercutio: looks like there was a patch (7dec560e) identified that fixes that issue, so that seems like a reasonable thing to fix in 3.13 as well
<mercutio> arges: yeah, there was a short patch identified
<mercutio> but i checked gitweb and it wasn't in
<arges> mercutio: this is our kerenl SRU process: https://wiki.ubuntu.com/KernelTeam/KernelUpdates 
<arges> mercutio: so I could submit this as an SRU and then when the update comes into 3.13 someone would need to test it and verify it does fix the issue, then eventually it is released
<mercutio> arges: what kind of time frame is there for that?
<arges> 3-6 weeks
<arges> if it is verified quickly and causes no regressions
<mercutio> i see
<mercutio> yeh i think i waant to change kernels quicker than that personally
<arges> well this is probably worth fixing it for other users too, I'll post a test kernel on the bug regardless
<mercutio> yeah it's definitely worth fixing
<arges> mercutio: ok commentd on the bug with a test kernel
#ubuntu-kernel 2016-04-21
<fg___> #ubuntu-devel
<fg___> would this be a potential candidate for one of the next xenial kernel SRUs once the release has settled? when the affected corner case occurs, the kernel unnecessarily spews stack traces that look very serious which tends to confuse users.. (tcp_fragment() has the same length check wrapped in WARN_ON)
<fg___> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d88270eef4b56bd7973841dd1fed387ccfa83709
<fg___> (bad timing - I know)
<jtaylor> hi, just pinging bug 1248289 again
<ubot5`> bug 1248289 in linux (Ubuntu) "Missing libunwind support in perf" [Medium,Confirmed] https://launchpad.net/bugs/1248289
<jtaylor> I do think perf is an incredibly useful feature of linux, and not having it work for many applications is quite annoying
<jtaylor> its just a missing build depend and maybe the one line patch from the bug
<jtaylor> still broken in 16.04
#ubuntu-kernel 2016-04-23
<mcphail> Hello. I think there is a regression with the xpad driver in 16.04
<mcphail> I'm experiencing the symptoms outlined in https://github.com/paroj/xpad/issues/27 . If I compile an older version of the xpad driver, I don't get the same issues
<mcphail> I presume this chap's driver changes have been upstreamed into the Ubuntu kernel? How would I check?
<mcphail> srcversion of the Ubuntu driver is 8286D39D8E84C7C57EB2220
<mcphail> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574102
<ubot5> Ubuntu bug 1574102 in linux (Ubuntu) "Regression (constant vibration of device) in xpad driver in Ubuntu 16.04" [Undecided,Confirmed]
#ubuntu-kernel 2016-04-24
<Guest22775> hi. i need some help with btrfs
<Guest22775> 16.04 do not support to mount an sd-card formated in btrfs under xbian. i get an error, something like missing option 10 ... any idea?
<Guest22775> someone here?
<apw> Guest22775, i think we'd need to see more of the message than that, probabally there is information in dmesg when it fails
<apw> Guest22775, i'd recommend filing a bug "ubuntu-bug linux" and adding the details
<Guest22775> btrfs "features 10" is missing
<Guest22775> sorry, not option ...
#ubuntu-kernel 2017-04-17
<kees> ogasawara, apw: what's the state of the raspi2 port in ubuntu?
<kees> (or raspi3)
<kees> I note some config things aren't synced (like missing SW_DOMAIN_PAN on raspi2)
<ogasawara> kees: heya, it's getting active security support and maintenance, so if something is missing or broken we should get that fixed
<kees> ogasawara: ah, okay. I saw it in universe, so I wasn't sure.
<kees> ogasawara: are there plans for an arm64 kernel for the raspi3? (and is there a hwe-edge for it, or is it just tracking the current LTS kernel?)
<ogasawara> kees: ah, so I think arm64 landed in yakkety and zesty, but not in xenial
<ogasawara> kees: and there isn't an hwe-edge for it unfortunately
<ogasawara> kees: the linux-raspi2 package name is misleading too, since it does have support for raspi3
<ogasawara> kees: was there any other configs of concern you had noticed?
 * ogasawara will file a tracking bug for SW_DOMAIN_PAN
<kees> nothing that jumped out yet (it's a 4.4 kernel, so most of the stuff I'm looking for is in later kernels) :)
<ogasawara> ack
<kees> ah-ha, i see the arm64 build now. cool.
<kees> is there an install path for an arm64 image? all I can find is the 32-bit stuff...
<ogasawara> kees: that one I'd have to check...but maybe slangasek knows off the top of his head?
<ogasawara> slangasek: ^^
<slangasek> "install path"?
<kees> like... where do I find the raspi arm64 server sdcard image for zesty?
<slangasek> oh, are you asking whether we have an rpi3 image w/ 64-bit userspace?
<kees> yes
<slangasek> no
<kees> ah-ha, okay :)
<slangasek> :)
<kees> is there a blocker for that? i.e. should it work in theory?
<slangasek> it's not one of the reference images we're committed to providing
<slangasek> rpi2/rpi3 are armhf reference; dragonboard is arm64 reference
<kees> okay, understood. I've been mentally classifying arm as a dead arch like i386. :)
<slangasek> now, should it work?  you might be able to put together an ubuntu-core model assertion that takes the 64-bit userspace and combines it with the rpi3 ref kernel
<slangasek> + gadget
<slangasek> but we're not going to produce that image because we don't have the capacity to QA it
<kees> gotcha
<kees> oh, but just to be clear: there _is_ an arm64 userspace and there _is_ an arm64 kernel. :P so I should be able to make it work...
<slangasek> kees: yeah, we have both of those pieces :)
<kees> now I just have to figure out why apt doesn't talk on the network in a qemu-static-user chroot... :P
#ubuntu-kernel 2017-04-18
<kees> ogasawara: hrm, all the configs from ubuntu's 4.8 new defaults seem to be missing. e.g. CONFIG_HARDENED_USERCOPY=y CONFIG_SLAB_FREELIST_RANDOM=y CONFIG_DEBUG_LIST=y CONFIG_DEBUG_CREDENTIALS=y
<kees> maybe that kernel doesn't go through the normal config verification?
<apw> kees, missing?  CONFIG_HARDENED_USERCOPY seems to be =y in our 4.8 kernels
<kees> apw: I was looking at the raspi2 kernel -- it seems out of sync with the main kernels
<apw> kees, oh ... ogasawara ^
<ogasawara> apw: it's looking like we may need to do a config review for raspi2
 * ogasawara cries
<ogasawara> apw: but I will talk to ppisati
<apw> ogasawara, i'll make a card
<kees> it seems like it can just be an arm64 flavor. the config.common.ubuntu is out of sync -- fixing that solved my missing configs
<kees> er, well, armhf and arm64
<kees> I'm still using the armhf...
<ogra_> kees, arm64 on developer boards is insanity (all binaries eat about twice the ram) ... 
<kees> ogra_: only things that are very pointer-heavy. I can easily run servers with less than a gig of RAM, and the raspi3 has a gig. *shrug*
#ubuntu-kernel 2017-04-19
<dmj_s76> sforshee: So, we may be seeing linux-firmware issues for iwlwifi-8000C again.  A few reports from Zesty customers.
<dmj_s76> sforshee: Yep, iwlwifi-8000C-22.ucode breaks wifi on certain machines with the intel 8260 that have 64GB of memory installed.
<sforshee> dmj_s76: okay ... I thought you had tested that before and found the problems were fixed?
<dmj_s76> sforshee: I thought so too, but missed one specific part of the hardware config.
<dmj_s76> It only affects some RAM combinations.  Should've made sure to test 4x16GB when I checked it out.
<sforshee> dmj_s76: I'll remove it again. Does intel know about this problem?
#ubuntu-kernel 2017-04-20
<jjohansen> cking: congrats once again
<jjohansen> or perhaps nice job is better
<cking> jjohansen, it's just simple fixes, nothing amazing, really. 
<cking> thanks :-)
<jjohansen> cking: sure, but it nice to see the contribution happening, Canonical even made it into the top 20 for 2nd time since well forever
<cking> i've got another 60+ lined up for the next merge, so hopefully it may happen again :-)
<jjohansen> cking: well likely not for 4.12 but get another 50 or 60 lined up for 4.13 and we should
<cking> fingers crossed. mind you, it is a meaningless index of productivity
<jjohansen> sure, but still its some visibility, and a bit of a counter to the common refrain of us doing nothing
<hallyn> is there any fast kernel build host (shell access) for ubuntu community use?
<hallyn> oh yeah i saw that, nice :)
<hallyn> ugh.  people who define "struct wahtever\n{" really mess with my searching
 * hallyn lines up a big gce instances, but doesn't expect it to perform very well
<hallyn> is a kernel build automatically parallelized to ncpu when doing a fakeroot debian/rules binary-generic, or are there env variables worth setting?
<xnox> DEB_BUILD_OPTIONS=parallel=8 ./debian/rules <target>
<xnox> hallyn, would be Debian Policy compliant....
<xnox> hallyn, https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options
<hallyn> oh, i thought that was obsoleted long ago, but i guess not.  thanks, i'll try that and see if it makes a difference :)
<hallyn> thanks
<hallyn> i think last i asked about this was like 6 years ago with kees
<xnox> hallyn, debhelper 10 finally defaults to parallel by default, but we are not using that level of compat widely enough yet.
<xnox> i think it about 4 years time, things will finally build parallel by default
<hallyn> xnox: thanks
<hallyn> xnox: heh, yeah so fwiw no change in time with that option so i guess kernel debian/rules must dtrt
<apw> hallyn, the kernel self parallelises if you don't tell it
<hallyn> apw: and that's appreciated :)
<xnox> ah interesting
#ubuntu-kernel 2017-04-21
<tmus> is there a place where I can get an overview of ubuntu kernel modifications in an easy way? I've cloned the zesty kernel git repo, but I can't seem to find patches or list of changes anywhere...
<ivan> look at the SAUCE commits to get a list of recent Ubuntu fixes? look for a "Linux X.Y.Z" commit and diff some upstream tag to an Ubuntu tag?
<ivan> are you looking for something in particular?
<tmus> ivan, there's an ongoing bug about some CPU lockup that appears to only happen on Ubuntu kernels (not mainline), so I thought I'd see if I coule make any sense of it
<ivan> tmus: try applying ubuntu's kernel configuration to mainline and see if it locks up then?
<tmus> ivan, so mainline does not use the same config as the ubuntu kernel?
<ivan> nope
<tmus> can I find the mainline config for amd64 somewhere without installing? i think i know what causes the difference then
<tmus> have a good idea anyway
<ivan> a combination of debian.master/config/config.common.ubuntu and debian.master/config/amd64/*
<tmus> ivan, awesome - that's the resulting ubuntu config, right? Is there a way to find the mainline config?
<ivan> yes and sure but I forget where
<ivan> find . | grep -i config
<tmus> hmmm... no luck - lots of *config files, but haven't found one that looked right
<ivan> tmus: "You can get a full set of these and call it "100% pure vanilla" if you generate a config using a kernel from kernel.org and run make config or make menuconfig (without making any changes)." https://unix.stackexchange.com/questions/17534/is-there-a-vanilla-kernel-configuration
<ivan> but as mentioned that might not result in a config you want
<ivan> maybe use the config from your existing mainline kernel that works for you?
<tmus> ivan, right - i'll have the people with the mainline kernel install check that
<tmus> thanks a lot
#ubuntu-kernel 2017-04-22
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<zx2c4> hey I think you guys missed a stable patch for your HWE kernel, and things are as a consequence broken on Google Cloud Platform -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1685416
<ubot5> Ubuntu bug 1685416 in linux (Ubuntu) "Virtio Fixes Not Backported --> Google Cloud Platform Drops Packets" [Undecided,New]
#ubuntu-kernel 2017-04-23
<edbordin> If I run a full kernel build with "fakeroot debian/rules binary-headers binary-generic binary-perarch", then modify a header file in a driver, then run the same build command again, is there any reason why the modified header might not be included in the second build?
<apw> ed
#ubuntu-kernel 2018-04-16
<sforshee> jjohansen: is that fix release critical? Judging by the information on the bug I'd think not
<sforshee> jjohansen: we can oportunisticly pull it in if something that is release critical comes up, I'm just not seeing that as something that is likely to affect installation
<sforshee> so if it is otherwise please tell me so
<jjohansen> sforshee: well, it was to the snappy people friday but it appears they have changed their mind since. So unless they raise it as release critical it isn't
<leitao> how do I know if a device driver (.ko) will make the udeb that will be used by the d-i?
<sforshee> leitao: if it's listed within debian.master/d-i
<leitao> sforshee, how do I see what is the set of device drivers that are part of the basic initrd.gz provided by d-i?
<leitao> sforshee, because I understand that d-i has two stages, load the drivers that are part of the initrd.gz, get access to the internet for stage-2 and get the extra udeb ko files.
<leitao> if the above is correct, we probably want to put ipr.ko (ppc64el sas controller device driver) into this very first stage.
<leitao> This is what I found looking at 1751813
<leitao> xnox, ^
<sforshee> leitao: hmm it's been a while since I've had to do that, can't recall off the top of my head. Will try to look but I have to run soon.
<leitao> sforshee, no worries. I am trying to discover what is causing this bug here, and this is my understand at this time
<sforshee> leitao: I think it's initramfs-tools
<sforshee> leitao: in hook-functions
<leitao> sforshee, ok, let me check that
<xnox> sforshee, no, we are talking about d-i no? thus anna install and udebs, not initramfs-tools.... unless things fail to boot.
<xnox> leitao, the ipr.ko is in scsi-modules-4.15.0-15-generic-di_4.15.0-15.16_ppc64el.udeb which is loaded as part of disk detection.....
#ubuntu-kernel 2018-04-18
<alkisg> Hi, I've been using https://launchpad.net/ubuntu/+source/linux-raspi2 version 4.15.0-1005-raspi2 in a raspberry pi2 for weeks, it's fine.
<alkisg> Question: why is it still in proposed? Is feedback needed from users?
<alkisg> (ubuntu-mate 18.04)
<apb1963> ubuntu 16.04 I changed the video driver through system settings but the proprietary driver crashes, therefore I'm unable to login through the standard GUI and only have VT access. I of course want to revert to the original open source.  I tried reinstalling xserver-xorg-video-nouveau but it didn't help.
<apb1963> Ideas?
<alkisg> apb1963: the command to manage them from the command line is "ubuntu-drivers"
<alkisg> It has parameters like install/uninstall etc, check its man page
<apb1963> alkisg, Thanks!  Yeah I did ubuntu-drivers drivers but it didn't occur to me that it might have other options/commands.  I will give that a try... have to reboot to do it though... Thanks again!
<Daegalus> Posted this in #ubuntu also: If anyone can help me with what I think is a kernel or kernel module regression in 18.04 beta. I updated recently and my USB-C port no longer works when plugging something in. bunch of PCIe and xHCI errors. Here are my dmesg logs and I can provide other info. the system is a Dell XPS 13 9360 with intel Sunrise PCIe Root. 
<Daegalus> Dmesg from replugging the cable: https://gist.github.com/Daegalus/db500035b76298db86d0031af5a94310 and 
<Daegalus> full dmesg from boot: https://gist.github.com/Daegalus/bf3b67645dd38e6a9ac2c942505637d8 
<Daegalus> Totally willing to file a bug but need help diagnosing what the true problem is and the best place to file the ticket.
<Daegalus> I upgraded from kernel 4.15.0-13 to -15 and i tried downgrading the kernel, no dice
#ubuntu-kernel 2018-04-19
<s10gopal> apw, jsalisbury why Rafael is not accepting that his commit is causing the problem?
<jsalisbury> s10gopal, He just wants more "Proof".  I'm working on a new test kernel for you to do that.  Should have something ready soon.
<s10gopal> jsalisbury, if git bisect result is not correct then it is used ?
<s10gopal> why it is used ?
<JimBuntu> s10gopal, this is the kernel. Please don't expect one of the devs to blindly accept pretty much anything. They take things pretty seriously and the last thing they want is the blame for fixing something for 3% of the users that then inadvertently causes issues for some other group. They generally also try not to only side-step an issue and would rather figure out the root cause and fix that, or give that person/group time to do so.
<Daegalus> Hi, I just wanted to heck if anyone that knows more about kernels saw my USB-C/PCIe/TBT issue from yesterday that I posted?
<apw> Daegalus, probabally best to post your ubuntu bug number
<Daegalus> Well, I was asking for advice on where to put it/classify it because I wasn't 100% sure it was a kernel/module but i can post it and then link it @apw
<apw> the kernel is as good a guess as any with that kind of "none of my usb-c works now" kind of bugs
<Daegalus> cool, I will then post the bug and link it here in a bit
<Daegalus> @apw https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1765496 is that sufficient?
<ubot5`> Ubuntu bug 1765496 in linux (Ubuntu) "USB-3/PCIe Root/Thunderbolt fail to load" [Undecided,New]
<Daegalus> @jsalisbury did as you instructed for the bug, its still a problem in upstream.
<jsalisbury> Daegalus, ok, thanks.  Does booting back into the prior kernel make the bug go away?  It should if the regression was introduced by the kernel.
<Daegalus> i am double checking now, im installing the one from the kernelMainline folders as i might have confused 4.15.0-13 with 4.13
<jsalisbury> Daegalus, ack.  It should actually still be selectable from the GRUB menu, I would think.
<Daegalus> 4.15.0-13 4.15.0-15 and 4.16.0-041600 are the only versions in my /boot folder
<jsalisbury> Daegalus, ok.  If we can identify this as a regression, we can bisect to find the commit that caused it.
<Daegalus> should i get 4.13 or 4.13.16 ? 
<jsalisbury> Daegalus, you shouldn't have to, if you were on 4.15 when the bug didn't exist.
<Daegalus> already did it, same problem on 4.13, so its not the kernel, could it be a module? its why i originally posted in here asking for help on figuring out the best place to file the bug
<jsalisbury> Daegalus, Hmm, kernel modules are tied to specific kernel versions, so it probably is not the kernel.
<jsalisbury> Daegalus, could it be a HW or cabel problem?
<Daegalus> damn, ok, sorry for the mistake then. Just by the errors in dmesg it seemed like one. Ummm, not sure, it was working on Friday evening when i left, I shut off my computer, started it on monday, no external monitors and errors in my dmesg. I had upgraded the kernel on Friday, but didn't reboot and figured my shutoff/start will take care of upgrading that for me. So its why i thought it was a kernel problem
<Daegalus> I'll go see if i can get a new cable and see if thats the issue
<jsalisbury> Daegalus, The cable is worth checking.  Just to confirm, are you running uname -a from a terminal to confirm your booted into the prior kernel?
<Daegalus> Yes
<Daegalus> @jsalisbury just got a cable from IT, no go. im gonna boot into the original windows partition on this and see if i can figure something out from that side. Definitely seems to be something either in the firmware or the bios. Imma do some digging, but thank you for helping out with the kernel part. I will close the ticket in a little while after I check some stuff
<jsalisbury> Daegalus, thanks.  If you think it's still the kernel, just post to the bug and I'll follow up. 
<Daegalus> @jalisbury found the problem I think. Dell released a thunderbolt firmware update that failed to install. I jumped into windows to force reinstall it And hoping that fixes it but it's definitely on my end. Thought I'd give you an update
#ubuntu-kernel 2018-04-20
<FurretUber> Hi, I'm using the kernel 4.16.3 from the mainline and when I try to remove the 4.16.2 linux-image this error happened: Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-4.16.2-041602-generic.postrm line 330.
<apw> FurretUber, can you pastebin that /var/lib/dpkg/info/linux-image-4.16.2-041602-generic.postrm for me so i can see what your postrm looks like
<FurretUber> https://paste.ubuntu.com/p/8wD8tR92WF/
<apw> FurretUber, and what is in /etc/kernel/postrm.d ?
<FurretUber> Found the issue, it was with the grub configuration
<FurretUber> Strange it did not pointed to grub. When using sudo update-grub it gave the following errors: erro: memÃ³ria insuficiente. erro: syntax error. erro: Incorrect command. erro: syntax error.
<tomreyn> FurretUber: "memÃ³ria insuficiente" sound slike your /boot file system may have run full?
<FurretUber> I think the issue was with grub configuration: it was lacking a "}"
#ubuntu-kernel 2018-04-22
<LocutusOfBorg> folks, do you think we can add this one line patch to linux kernel?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766054
<ubot5`> Ubuntu bug 1766054 in linux (Ubuntu) "Acer Swift sf314-52 power button not managed " [Undecided,Incomplete]
<LocutusOfBorg> I asked my colleague to submit upstream, but it might take longer
<bjf> jsalisbury, ^ that looks reasonable to me
<LocutusOfBorg> I don't get why nobody at acer submitted a patch to add the handle of such key 87
<LocutusOfBorg> :/
<LocutusOfBorg> (or why they didn't map it to another same power key  button)
<LocutusOfBorg> but fact is that people won't be able to use that power button without that patch
<LocutusOfBorg> apw, ^^
<apw> LocutusOfBorg, yep and i am sure js will be looking it over
<LocutusOfBorg> thanks, I would appreciate some guidance to get it mainline, I asked my colleague to do some git send-email, but this is the first time we submit a patch to the kernel upstream folks
<LocutusOfBorg> this is the message https://lkml.org/lkml/2018/4/20/890
#ubuntu-kernel 2019-04-19
<neyder> Hi is here a good place to get help to compile ubuntu kernel for an specific HW as of OLPC xo 1.5 ?
