#ubuntu-kernel 2005-05-16
<fabbione> morning
<fabbione> bah
<fabbione> 12rc4 is out
<crimsun> they sure are taking their time for 12final ;)
<fabbione> crimsun: nah.. i think the delay is all due to bk -> git transition
<fabbione> the development is going pretty fast
<fabbione> rc3 -> rc4 was only 2 weeks
<crimsun> ah
<fabbione> i am not sure i want to go out tomorrow with rc3
<fabbione> i will need to check how much effort is the merge
<fabbione> imho you are good to go for 2.16
<fabbione> ops
<svenl> hi fabbione ...
<zul> hey
<zul> hey jeff how goes?
<jbailey> zul: Good.  I'm looking forward to going home soon, though.
<zul> cool
<zul> im already at home...did you call your mother today?
<jbailey> You?
<zul> just getting over the flu again
<jbailey> Ugh.  Angie had some variation of a cold.
<jbailey> A good chunk of the folks at UDU got sick too.
<zul> yeah this is like the second time in the last 2 weeks i was sick
<jbailey> Yuck.
<zul> maybe a bunch of debian folk were trying to poison you so they could play catch up ;)
<Lathiat> haha
<jbailey> ROFL
<jbailey> No, that would've required a succesful GR...
<zul> hehe
<jbailey> I have one more batches of fixes to do to lkh and then I'll be able to upload klibc.
<jbailey> This is my goal for today. =)
<zul> neat...im just doing some compile warning fixes
<Lathiat> jbailey: have you uploaded that int64 fix yet?
<jbailey> Lathiat: No, and that likely won't be in this upload.
<Lathiat> ok
<jbailey> Lathiat: It would definetly be int he next one, though.
<jbailey> Lathiat: The problem is that we're handling a different case than before.  It's easy enough, I just need to think through it.
<jbailey> I think it should be.
<Lathiat> righto
<Lathiat> as long as it works for me i dont care. :)
<jbailey> if C99 or (gnuc and not strict ansi)
<Lathiat> heh
<fabbione> hey guys
<jbailey> And then write a testsuite pass that makes sure that I don't break it again in the future.
<jbailey> Fabio!
<fabbione> jbailey: if you want to look at another l-k-h fucks up...
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/b/binutils/2.15-5ubuntu3/binutils_2.15-5ubuntu3_20050507-0838-powerpc-failed
<Lathiat> your popular jbailey ;)
<jbailey> binutils?
* jbailey looks
<jbailey> Why would binutils use lkh in any way?
<fabbione>  /usr/include/sys/procfs.h:57: error: syntax error before 'elf_vrreg_t'
<fabbione> that's only on ppc
<fabbione> no idea.. don't ask me
<fabbione> me know notting
<zul> hehe...
<jbailey> Yes, manuel.
<fabbione> 12rc4 is out
<zul> meh..
<fabbione> btw i started using git
<fabbione> it's very simple for the use we need to do of it
<zul> release 12rc3 on monday and then we can work on rc4
<jbailey> And it kicks baz's ass? =)
* jbailey hides.
<Lathiat> haha
<fabbione> jbailey: yes... it's way faster and easier to use
<fabbione> zul: yes i agree
<fabbione> zul: there is 11.92.orig.tar.gz in the usual place
<fabbione> zul: but no diff.gz or .dsc yet
<zul> okie dokie
<fabbione> neither i did branch baz
<zul> im just doing some kj stuff right now
<zul> ....and throwing stuff at my wife
<jbailey> Yup, this looks like an lkh bug.
<jbailey> Strange that this is only defind in ppc, though.
<jbailey> defined, even.
<fabbione> jbailey: did you look at util-linux for sparc?
<jbailey> I have not.  I spent yesterday at a wedding.
<fabbione> oh ok.. no big rush, but if you are planning a l-k-h upload, it would be nice if you could look at it
<zul> bbl
<jbailey> 'kay.  I'll ping you when I get closer to that.  My first goal is getting klibc in, I had wanted to upload it for last Friday and encoutered a couple more bugs than I had expected.
<fabbione> klibc?
<fabbione> brrrrr
<fabbione> just the name is scary :)
<jbailey> Yeah.
<jbailey> Well the intention *is* to bundle it with the kernel.
<fabbione> jbailey: is this a breezy goal?
<jbailey> fabbione: The bundling?  No, it's upstream.
<fabbione> yeah i know the upstream story.. i was wondering if you wanted it done for breezy
<jbailey> fabbione: It's the c library that al viro, greg k-h and them want for all the early userspace stuff.
<jbailey> Doesn't matter to me.  As long as upstream is making separate releases, I'll cheerfully package it seperately.
<jbailey> I don't see any reason to make the kernel packaging more complicated just for this.
<jbailey> If upstream bundles it before breezy, then we can figure it out then.  I don't expect it'll be that quick.
* fabbione thanks
<fabbione> ahaha neat
<fabbione> cg-log -c
<fabbione> outputs all the kernel changelogs in nice colors :)
<fabbione> time to cook dinner
<fabbione> cya tomorrow or later fellas
<jbailey> g'n Fabio
<jbailey> Wow, a friend is unexpectedly in town.
* jbailey runs
#ubuntu-kernel 2005-05-17
<fabbione> morning
<svenl> hi fabbione 
<svenl> fabbione: i tried to build mplayer yesterday, and it failed because of some altivec includes.
<svenl> fabbione: and the existing powerpc packages seem to lack the actual binary.
<fabbione> ok ladies and gentlement
<fabbione> we need a new kernel release name/series
<fabbione> votes are open :)
<fabbione> JaneW: since when you are interested in the kernel? :)
<crimsun> hmm, as in "Bite the Dildo" names?
<crimsun> oh wait, that was probably inappropriate
* fabbione introduces crimsun to JaneW
<dilinger> fabbione: still going for food names?
<fabbione> dilinger: well we can do whatever we like
<fabbione> i was considering some kind of flexibility
<crimsun> 'lo JaneW 
<fabbione> like hurricanes name for unstable releases
<fabbione> and something else for stable releases
<fabbione> or whatever..
<fabbione> i am really open to suggestions
<fabbione> i think 91-1.1 is ready to go out of the door
<JaneW> hi crimsun
<JaneW> fabbione, just browsing
<JaneW> fabbione: besides I am interested in all things ubuntu related ;)
<fabbione> JaneW: be aware.. this is the channel of the truth of death :P
<crimsun> 2.6.11.90-1 is working great
<fabbione> crimsun: good to know
<fabbione> 91-1.1 will hit the archive today
<fabbione> 92 is already a work in progress
<crimsun> ooh!
<fabbione> i just need the name for 91-1.1
<crimsun> it'll be the stable branch, right?
<fabbione> nope
<fabbione> this is unstable
<crimsun> oh, 9x
<fabbione> 91 = 12rc3
<crimsun> right
<fabbione> 92 =12rc4
<fabbione> so whatever
<fabbione> we need something cool tho
<fabbione> nobody is going to read a 200 lines changelog anyway
<crimsun> what about ferocious predators for the unstable branch and docile animals for the stable?
<fabbione> hmmmmm
<dilinger> how about ornery kernel hackers for the unstable branch and huggable ones for the stable branch? :)
<dilinger> you could start w/ al viro for the first unstable
<fabbione> dilinger: examples? :)
<fabbione> hmmm i am afraid that using people names might create political issues
<fabbione> people might not like it
* dilinger nods
<crimsun> funny, I was thinking Al, too ;)
<fabbione> The "Phantom Mance" Release
<fabbione> Menace
<dilinger> crimsun: when i think of kernel hackers who put the fear of god into me, i think of al
<dilinger> and that's saying a lot, since i'm an atheist :p
<fabbione> i have an idea
<fabbione> let's use the weirdest sex positions, md5sum encoded
<fabbione> and see who is going to guess them :)
<fabbione> kinda of a contest ;)
<dilinger> i'd recommend that w/out the md5sum encoding ;)
<fabbione> dilinger: pig! :P
<crimsun> yeah, the md5sum would be even worse than the current numbering scheme ;)
<crimsun> we could just rot13 'em
<Lathiat> that would be evilly cool
<fabbione> Lathiat: the md5 or the rot?
<Lathiat> rot
<fabbione> do we have a cmd line tool to rot encode?
<dilinger> fabbione: give the people what they want!  the reverse cowgirl kernel release..
<Lathiat> yeh |rot13
<Lathiat> i think its in bsdgames
<Lathiat> or
<Lathiat> just use the tr command
<Lathiat> theres a string for tr somewhere
<Lathiat> i dont know it
<Lathiat> google should
<fabbione> dilinger: ahhaa
<crimsun> yeah, straightforward and simple
* Lathiat grins
<fabbione> sexy_rodeo == Put your woman doggie style, grab her by her tits and penetrate her. When you are in, tell her "did you know this is the position your sister likes most?" then you have to stay up for at least 8 seconds
<dilinger> yea, i wouldn't recommend including the explanations.  or including words with sexual connotations.
<fabbione> dilinger: clearly :)
<Lathiat> heh
<fabbione> it was only an answer to the cowgirl thingy :)
<dilinger> hehe
<fabbione> ok.. we must get a name
<dholbach> will there be silly animal names for the kernel as well? ;-)
<fabbione> dholbach: any proposal is good :)
<fabbione> go ahead with your
<dholbach> i'd love to have SneezySnail somewhere ;-)
<crimsun> hmm, speed is another good idea
<crimsun> could even combine that with the ferocious/docile thing
<dholbach> but i'll think of something else
<fabbione> dholbach: i would like to avoid name clashes with releases
<dholbach> of course
<dholbach> but SneezySnail will hopefully never be a release name ;-)
<Lathiat> sneezysnail would be a nice release name :)
<dholbach> i think it was keybuk's idea :)
<dholbach> see you
<fabbione>   The "amok" Release.
<fabbione> what about this one? :)
<jbailey> Bah, I'm going to bed.
<jbailey> Too tired to finish the lkh bits tonight.
<fabbione> jbailey: good night dude :)
<jbailey> g'n. =)
<fabbione> JaneW: you here?
<JaneW> fabbione: yes - on phone
<fabbione> sure.. take your time
<JaneW> fabbione: ok done, - how can I help?
<fabbione> JaneW: we need a release name for the kerenl
<fabbione> kernel
<fabbione> something that indicates that it is pure crack :)
<JaneW> hehehe
<JaneW> gimme examples of what you;ve had...
<fabbione> or something with a "pink" touch.. but than you will commit to find names for the whole breezy release cycle :)
<fabbione> JaneW:   The "Succulent Strawberries" Release.
<JaneW> ;)
<fabbione>   The "Radioactive Radish" Release.
<fabbione>   The "Atomic Artichoke" Release.
<fabbione> now.. we reserved veggie for hoary
<JaneW> ok
<fabbione> but food is limited
<fabbione> so we need to get a new cathegory too :)
<JaneW> ice-cream flavours...?
<JaneW> can get orett outrageous
<JaneW> pretty even
<fabbione> JaneW: that would work too...
<JaneW> Pecan Swirl
<fabbione> fire some  :)
<fabbione> PS <- ???
<fabbione> we use a similar convention to release names
<fabbione> like Hoary H.
<fabbione> so same first letter
<fabbione> that's what make it a bit harder ;)
<JaneW> ok
<JaneW> Rocky road
<JaneW> Praline pecan
<fabbione> something like that...
<JaneW> Chocolate chip
* fabbione needs to picture these icecream flavours...
<fabbione> http://www.recipesource.com/desserts/ice-cream/00/rec0095.html
* JaneW is not loving the idea
<JaneW> thinks harder
<JaneW> being a kernel... how about types of nuts?
<JaneW> a bit of a play on the kernel think?
<fabbione> sounds good..
<JaneW> Happy Hazel
<fabbione> let see how many flavours we have
<JaneW> Perky Pecan
<JaneW> Batty Brazilian
<JaneW> Almond (the adjectives are hard)
<JaneW> Pistacio (but starts with same letter as pecan and peanut)
<JaneW> Crunchy Cashew
<fabbione> http://waynesword.palomar.edu/ecoph8.htm
<JaneW> Wacky Walnut
<JaneW> PInnut
<JaneW> Pinenut
<fabbione> ok you convinced me
<JaneW> Walnut
<JaneW> etc
<fabbione> which one would you like to see as first?
<JaneW> happy to help
<JaneW> Chestnut, Macadamia
<JaneW> plus Badgers eat nuts
<JaneW> I think
<JaneW> first one er...
<fabbione> eheh i think so too
<JaneW> Hazel - like the one in ice age
<JaneW> oh no that was an acorn ;)
<JaneW> sort of the same
<fabbione> done
<JaneW> yay
<fabbione> now you will be doomed for the whoile breezy process in reminding us nuts names ;)
<JaneW> so can I put 'contributed to Ubuntu Kernel' in my CV now? ;)
* JaneW starts a nut name DB
<fabbione> JaneW: sure:
<fabbione> linux-source-2.6.12 (2.6.11.91-1.1) breezy; urgency=low
<fabbione>   The "Happy Hazel" Release.
<fabbione>   Welcome to JaneW as our new name release manager that kindly offered
<fabbione>   volunteer to find nuts names for our kernel.
<fabbione>   Changes by Fabio M. Di Nitto:
<fabbione> this will appear shortly on ubuntu-changes...
<JaneW> heehee
* fabbione does some baz dance and uploads
<Seveas> Is the next one going to be "Mad Macadamia"?
<svenl> here is maybe more appropriate.
<svenl> Is DVD burning supposed to work on the ppc kernel ?
<svenl> # growisofs -Z /dev/hdc=archive.iso
<svenl> Executing 'builtin_dd if=archive.iso of=/dev/hdc obs=32k seek=0'
<svenl> :-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h] : Input/output error
<svenl> seems not to be the case.
<fabbione> i got that error with a broken burner
<svenl> fabbione: well, the burner worked fine under mac os X, so ...
<svenl> and the exact same brand of media.
<svenl> will try building cdrecord with the DVD patch.
<fabbione> svenl: i had really weird issues with my burner
<fabbione> like it was partially working with windows
<fabbione> but not in linux
<svenl> fabbione: and on amd64, my burner still doesn't want to do DMA burning, and is thus very very slow.
<fabbione> and sometimes viceversa
<fabbione> 2 or 4 burns didn't really show the problem
<svenl> fabbione: well, as this is the default powerbook burner, i guess lot of people, like maybe Kamion or benh, have been using it.
<fabbione> svenl: that's not the point.. if your specific burner is broken...
<fabbione> i had a lite-on
<fabbione> that is very well known brand
<svenl> well.
<fabbione> probably i was the only one with that problem
<svenl> yep.
<svenl> but in this case, chances are good that it is a software problem, especially given the history of it.
<svenl> Mmm, cdrtools broken patch number 40 didn't get fixed for hoary :/ 
<svenl> I am sure i reported this one months ago.
<svenl> damn, cdrecord fails too.
<zul> hey
<svenl> hi zul 
<zul> hey svenl 
<fabbione> hey zul
<zul> hey fabbione 
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ stable: kernel-debian--pre1,1--2.6.11.92 | There are no kernel bugs.. only broken hardware
<fabbione> meh
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,1--2.6.11.92 | There are no kernel bugs.. only broken hardware
<zul> heh shouldnt that be pre1.1
<fabbione> it was i typo when i did the branch
<zul> ah ok
<zul> at least i can close a whole bunch of bugs today
<fabbione> yeah go ahead
<fabbione> i didn't process bugzilla
<fabbione> zul: mind to close mine too?
<zul> sure
<fabbione> or did you close all of them?
<zul> ill just go through the changelog :)
<fabbione> thanks
<fabbione> or search for linux/PENDINGUPLOAD
<zul> yep
<zul> need to go potty
<fabbione> zul: orig/dsc/diff.gz in the usual place
<fabbione> for 92 i mean
<zul> ok...
<fabbione> sorry.. dsc and diff are still on the way
<zul> not a problem...i just woke up :)
<fabbione> that's why i am trying to be more detailed
<fabbione> ok they are up now
<zul> see this is what is bad about source base distros look at this guys CFLAGS http://bugs.gentoo.org/show_bug.cgi?id=74072
<fabbione> hahahaha
<fabbione> i am going off line for a while
<fabbione> 92 is building everywhere
<fabbione> i still need to commit the config changes
<fabbione> but they are trivial
<zul> yeah i noticed :)
<fabbione> i am at patch5 :)
<zul> im building it as well with some of my patches
<fabbione> it has a fix for ia64
<fabbione> rocking
<fabbione> i will be back later
<zul> k
<fabbione> and if you are ready i can start merging from you
<zul> ill let you know :)
<zul> argh..
<fabbione> argh what?
<zul> that external driver that was in bugzilla doesnt build
<fabbione> no shit...
<fabbione> is that the dxr3+ driver?
<zul> yep
<fabbione> hmmmm
<fabbione> it depends how it fails
<fabbione> probably the fix is easy
<zul> i might have found a fix already i2c.h changes
<fabbione> ok
<zul> er...i2c.h changed 
* dilinger yawns.   work + 5 hours of sleep == productivity
<zul> hey dilinger how goes it?
<fabbione> dilinger: started the new work?
<dilinger> not bad.  i really need a place to live
<dilinger> fabbione: yea, last week
<fabbione> is it any good?
<dilinger> it's work :)
<dilinger> it's not too bad
<dilinger> i spent friday getting comfortable w/ openafs source
<dilinger> it's impressively ugly
<fabbione> amen...
<fabbione> is it worth the inclusion in the kernel?
<dilinger> i don't think it's license allows it
<dilinger> i brought it up on the list
<fabbione> isn't it gpl now?
<dilinger> s/it's/its/
<dilinger> ibm public source
<dilinger> pity, it would be nice to have it in the kernel (once it's cleaned up a bit)
<fabbione> i can't find the licence on the page
<dilinger> http://openafs.org/frameset/dl/license10.html
<fabbione> scary
<fabbione> i need a shower :)
<fabbione> bbl
<fabbione> even the most hardcore developer does wash once a month
<dilinger> heh
<dilinger> needs some performance tuning..
<dilinger> dilinger@furious13:~ $ time cp openafs-1.3.82-src.tar.gz  foo
<dilinger> real    3m9.146s
<dilinger> 13MB file
<dilinger> i wonder how well kafs performs
<fabbione> why...
<fabbione> why...
<fabbione> why PPC IS SO RETARDED?
<Lathiat> it has a personal vendetta agianst you fab	
<zul> i blame T-Bone
<fabbione> it's because i don't own one.. yet
<fabbione> drivers/built-in.o(.pmac.text+0x2d10): In function `pmac_wakeup_devices':
<fabbione> : undefined reference to `pmac_tweak_clock_spreading'
<fabbione> drivers/built-in.o(.pmac.text+0x3548): In function `pmac_suspend_devices':
<fabbione> : undefined reference to `pmac_tweak_clock_spreading'
<fabbione> this is 12rc4
<zul> no idea..
<fabbione> every fucking release is the same story
<zul> drop ppc support :)
<fabbione> that would be sane
<zul> yay...something im actually qualified to do
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/l/linux-source-2.6.12/2.6.11.91-1.1/
<fabbione> yay
<fabbione> they start to appear :)
<Lathiat> woo
<Lathiat> you guys rock.
<zul> we do
<fabbione> let say we suck less than other teams :)
<Lathiat> haha
<zul> damn i have to clean the house today
<fabbione> i can do the patch for you
<fabbione> ops
<zul> you can patch it? :)
<zul> lol
<fabbione> zul: just run make clean
<fabbione> make -f zul clean
<zul> dist-clean more like it
<zul> yay it builds
<fabbione> hey jeff!
<jbailey> Heya Fabio! (and everyone)
<jbailey> When is linux-headers-2.6.10-5 going away?
<jbailey> I want to upload klibc this morning.  the lkh network bits all assume that glibc is present on the system, and I want to make sure that the upstream guy agrees with what I'm doing before I revert a pile of his changes.
<fabbione> jbailey: after we will make 2.6.12 the default kernel
<fabbione> in not too long i think
<jbailey> 'kay, so I have a week, probablyl
<fabbione> if not more....
<fabbione> we don't know when .12 final will be out
<fabbione> and 12rc4 is not encouraging atm
<jbailey> Ugh, really?
<fabbione> ppc is broken
<jbailey> I thought I had seen decent reports for rc3.
<fabbione> when right this morning benh told me that 12rc4 is perfect on ppc
<fabbione> well it doesn't even compile...
<jbailey> Compiler skew between you and benh?
<fabbione> drivers/built-in.o(.pmac.text+0x2d10): In function `pmac_wakeup_devices':
<fabbione> : undefined reference to `pmac_tweak_clock_spreading'
<fabbione> drivers/built-in.o(.pmac.text+0x3548): In function `pmac_suspend_devices':
<fabbione> : undefined reference to `pmac_tweak_clock_spreading'
<fabbione> this is just bad code
<fabbione> nothing to do with the compiler
<jbailey> Right. =)
<fabbione> since benh is working on G5
<fabbione> everything else is broken
<fabbione> and unsupported
<fabbione> at this speed rate i will have to ask either for an official ppc porter
<fabbione> or get rid of ppc as supported arch
<jbailey> Hmm.
<jbailey> I wonder if I have the skills to get into ppc porting at all.
<fabbione> ppc is the post problematic arch i have ever seen
<fabbione> you fix power3 and you break power4
<jbailey> Right, that's the scary part.
<jbailey> I have a newworld and a g5.
<fabbione> you change a line for powerpc and you break power3-smp
<fabbione> it's really fucking annoying
<jbailey> ah, nice.  the linux-headers /usr/src/linux-headers-2.6.10-5/include/asm seems to be pointed right per-arch.
<fabbione> http://drunkendelight.com/content/picture/02213994.jpg
<fabbione> AHNHAHAHA
<fabbione> jbailey: yes, it's per arch
<jbailey> Yeah, I just remember that last time I looked at the package (a year or two ago in Debian) it was not.
<jbailey> fabbione: Oh dear.
<jbailey> =)
<zul> aw man..
<zul> bbl
<fabbione> jbailey: in anycase i wouldn't base anything on 2.6.10 for breezy
<fabbione> just start using 2.6.12
<fabbione> even if it is in universe
<jbailey> Is it in universe?
<jbailey> I saw that 2.6.11 is in there.
<fabbione> it is on the way to universe
<fabbione> only amd64 is there
<fabbione> buildd are working on it
<fabbione> unfortunatly the kernel takes ages to build without (shared) ccache
<fabbione> r/wind goto 5
<fabbione> ops
<lamont> fabbione: ppc is on #5/6, i386 #5/5 (but has arch: all).  ia64, should anyone care, is on #2/4
<fabbione> lamont: goody...
<fabbione> what about hppa?
<fabbione> lamont: i already opened the dances for 12rc4
<lamont> fabbione: hppa is waiting for glibc
<fabbione> ha
<fabbione> i thought that was solved
<lamont> s/solved/known/
<lamont> and solution available.
<lamont> it's a matter of time to add it
<fabbione> ok
<lamont> and that's due sometime soonish
<fabbione> rocking
<fabbione> lamont: btw.. don't get crazy to grab the ABI files from 91-1.1
<lamont> heh
<fabbione> it's pointless in the middle of RC's
<fabbione> lamont: argh.. why did the kernel failed on i386????
<fabbione> i DID BUILD ARCH ALL!
<fabbione> openjade:/build/buildd/linux-source-2.6.12-2.6.11.91/debian/build/linux-source-2.6.12/Documentation/DocBook/wanbook.xml:3:61:E: error connecting to "www.oasis-open.org" (Connection timed out)
<fabbione> there is something broken somewhere else
<lamont> openjade:/build/buildd/linux-source-2.6.12-2.6.11.91/debian/build/linux-source-2.6.12/Documentation/DocBook/wanbook.xml:3:61:E: error connecting to "www.oasis-open.org" (Connection timed out)
<lamont> fix openjade
<fabbione> oh f**k
<lamont> fabbione: and for future fun and joy, build in a chroot on a machine that is blocked from internet access
<fabbione> I HATE THIS CRAP
<fabbione> it was working before...
<fabbione> it works from concordia....
<fabbione> so that means that concordia has inet access
* fabbione files a bug.. somebody will have to take care of it
<fabbione> 10567
<zul> heylo
<fabbione> bah
<fabbione> all this work to get the kernel in
<fabbione> and some retarded build-deps are broken
<zul> xmlto?
<fabbione> openjade
<zul> stupid..
<fabbione> lamont: can't we give one buildd net access to fetch that file in the meantime?
<lamont> no
<dilinger> [NETLINK] : Fix infinite loops in synchronous netlink changes.
<dilinger> fun
<fabbione> yeah i saw that
<fabbione> lamont: ok
<fabbione> dilinger: i started using git
<fabbione> it's preatty nice.. i like it
<fabbione> cg-log -c > baz diff
<dilinger> is that related to Xu's netlink vuln fixes?
<dilinger> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2a0a6ebee1d68552152ae8d4aeda91d806995dec
<fabbione> dilinger: let me check
<dilinger> fabbione: i'm not overly excited to use git, but for 2.6.12 i want to start up -as again.. which is going to require me to either use git, or write scripts to pull git stuff
<dilinger> hopefully it's a bit more sane in the way it handles new changesets
<fabbione> author David S. Miller <davem@sunset.davemloft.net> Tue, 03 May 2005 15:30:05 -0700
<fabbione>     [PKT_SCHED] : netetm: trap infinite loop hange on qlen underflow
<fabbione> there is also this one that is pretty neat :)
<dilinger> i like the colored diff output from git's web interface
<dilinger> purty ;)
<fabbione> yeah that one is nice too
<dilinger> looks like they are related
<lamont> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
<lamont>         "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [] >
<dilinger> -		while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL) {
<dilinger> +		while (qlen--) {
<dilinger> +			skb = skb_dequeue(&sk->sk_receive_queue);
<lamont> hrm... maybe it's kernel related....
<dilinger> in xu's patch
<dilinger> -		while (qlen--) {
<dilinger> +		for (; qlen; qlen--) {
<dilinger>  			skb = skb_dequeue(&sk->sk_receive_queue);
<dilinger> in davem's
<dilinger> heh, i never did end up meeting xu
<dilinger> vibe out was too comfy :)
<fabbione> dilinger: i did send him to you :)
<dilinger> oh?
<fabbione> dilinger: but he promised to be back on sat.. and he didn't show up
<fabbione> lamont: i can try to build again arch all
<fabbione> but i did it all the times on concordia
<lamont> fabbione: I'll upload a new linux-source that fixes the problem, after I fix it...
<lamont> unless you want to...
<fabbione> lamont: do you know what the problem is?
<lamont> well, given that openjade doesn't reference www.oasis-open.org, but the templates do in the kernel source, I'm betting that a patch is in order...
<fabbione> hmmm
<lamont> specifically, build-depend: docbook-xml and then change the URL to file:///usr/share/xml/docbook/schema/dtd/4.1.2/docbookx.dtd
<fabbione> let me check if it is fixed upstream
<lamont> note that they may consider it a useful thing to depend on net access to build...
<fabbione> there is no difference upstream
* lamont tests his fix
<fabbione> the question is why it fails only on that one
<lamont> ??
<fabbione> a lot of others have references to oasis
<lamont> because after it fails on the first one, it stops trying???
* lamont guesses
<fabbione> if you look at the build log other docbook stuff are built before the wanbook
<lamont> ok
<fabbione> hmmm
<lamont> nfc
<fabbione> no it builds DocBook/man
<fabbione> and they have no reference to oasis
<fabbione> bah this thing is so complicate
<fabbione> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[] >
<fabbione> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
<fabbione>         "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [] >
<fabbione> this is the change from 2.6.10 to 2.6.12
<fabbione> so clearly they did the right thing
<fabbione> but that breaks our buildd
<fabbione> and it is done on all documents
<fabbione> you are right that it stops at the first one
<lamont> right - but we have that file in the archive, if we want it...
<fabbione> exactly
* lamont will make a patch
<fabbione> so we need to patch all the documentation files
<fabbione> brb for the meeting
<zul> hmm...meeting?
<zul> there is  a meeting today? sheesh i thought it was tomorrow
<lamont> meeting
<lamont> breezy kickoff
<zul> meh
<lamont> fabbione: so this means I get to make -1.2, eh?
<lamont> should I just touch all the ignore-abi-changes files?
<JaneW> zul: MONDAY, that's today ;)
<zul> JaneW: im on "holiday" ;)
<lamont> JaneW: isn't it already tuesday for you, though??? :-)
<JaneW> lamont: nope it's almost 9pm
<lamont> fabbione: building something to test on my net-restricted hppa buildd.
<fabbione> lamont: ok.. no rush
<lamont> fabbione: yeah, but would be nice to have i386 there for rc3
<fabbione> i still believe the right fix should go in openjade that should always prefer a local copy and in case the net if the local is not available
<lamont> or will rc4 be ready for  upload shortly?
<fabbione> lamont: rc4 is FTBFS on ppc and i have no clue why
<lamont> fabbione: well, the kernel source _told_ it to use the net copy....
<jbailey> fabbione: Is it the type of thing I could be useful to you at all for?  I don't have a ton of time, though.
<fabbione> jbailey: i need somebody that can be there and it is not overloaded
<jbailey> fabbione: Yeah, that's not me at the moment.
<fabbione> jbailey: exactly
<jbailey> fabbione: Maybe draft me once the toolchain transition and early userspace are finished.
<jbailey> So in a month or so.
<fabbione> jbailey: don't worry
<fabbione> zul: just go for it
<zul> i will
<fabbione> merge it in .92-1.1
<zul> yep just need to read up on it
<fabbione> we also need to check if there is a unionfs that can actually build on ppc
<fabbione> lamont: how is it going with the kernel test?
<zul> wouldnt know...dont have access to ppc
<fabbione> zul: yeah i know that :/
* zul smacks T-Bone
<zul> where is he btw?
<zul> any particular version of squashfs?
<fabbione> the latest?
<lamont> fabbione: well, it's about a 2 hour build to just let it run, so I was, um, letting it run.
* lamont scream
<lamont> s
<fabbione> lamont: ehehe
<fabbione> ok
* lamont grabs the '-' and the 'A', and beats sbuild with them.
<fabbione> you didn't build arch: all, did you?
<lamont> STFU
<lamont> :-)
* fabbione goes and sits in a corner
* lamont will just build build-indep this time
<fabbione> that won't help anyway
<fabbione> iirc that part of the build is hairy
<lamont> won't?
<lamont> grumble
<lamont> ok
<fabbione> try... it might need to build some arch-dep stuff
* lamont relaunches an sbuild
<lamont> or will in a minute
<lamont> fabbione: sbuild -A started now.
<fabbione> ok
<lamont> linux-source-2.6.12:    02:37:30 (9 entries, sigma 01:29:45)
<fabbione> yeah.. no ccache...
<lamont> that's with ccache
<zul> ok...doing a first pass with squashf
<fabbione> oh
<lamont> last build was 1:48:29
<zul> er..squashfs
<lamont> the average has been steadily declining
<fabbione> lamont: because we switched compiler
<fabbione> from gcc-3.3 to 3.4
<lamont> right.
<fabbione> so the cache has been invalidated
<fabbione> + we added a few tons of lines of code
<lamont> otoh, was that in -1.1 as of 0505-1343 DCtime
<lamont> ?>
<lamont> that was the last time I built -1.1
<fabbione> lamont: the gcc-3.4 transition?
<fabbione> yes
<lamont> and then this time, of course, I built 3/4 of it...
<lamont> then the cache should be reasonably valid
<fabbione> yes
<fabbione> given that doko didn't upload another gcc-3.4
<lamont> cache hit                         365530
<lamont> cache miss                        465420
<fabbione> not that bad
<lamont> well, actually, I'm building against hoary right now, so it's pretty stable wrt toolchain... .:-)
<fabbione> considering how many times gcc has been updated in the last 3 days
<fabbione> oh
<lamont> my breezy chroot (hppa) is still a bit in flux.  And I don't have an i386 buildd in that DMZ
<lamont> files in cache                    269272
<lamont> cache size                           9.1 Gbytes
<fabbione> 192.168.1.1:/mirrors/sparccache
<fabbione>                        20G  9.0G  9.8G  49% /opt/sparcbuildd/chroots/kernel/home/sparcbuildd/.ccache
<zul> heh...i was going to say something stupid but im not now
<zul>  CC [M]   fs/squashfs/inode.o
<zul>   LD [M]   fs/squashfs/squashfs.o
<lamont> cache hit                         366420
<lamont> cache miss                        465428
<lamont> not bad for a delta
<fabbione> lamont: there are only few files that needs rebuild on date/time change
<lamont> fabbione: right
<lamont> hence this build should scream along to indep in < 2 hours or so.
* lamont must go fetch kid from school
<fabbione> and i am going to sleep soon
<fabbione> lamont: if the patch works, mind to upload and merge it where is needed?
<lamont> fabbione: will do.
<lamont> fwiw, I added *.ignore to the abi directory.. :-)
<fabbione> cool
<lamont> anyway, back in around 90 min
<fabbione> good night
<fabbione> zul: did you already open a new branch?
<zul> fabbione: yep
<zul> infinity: you are doomed now
<infinity> Probably.
<infinity> You're Canadian?
<zul> yep
<zul> there is several of us here
<infinity> Rogers has the most hideous hostnames.
<zul> i know..
<zul> there squashfs added
#ubuntu-kernel 2005-05-18
* lamont is back
<lamont> building #4/4 for the arch-all tst
<lamont> test
* lamont gets a request for REISER4
<zul> again?
<lamont> doesn't seem to be there yet, or is it?
<zul> nope
<zul> makes me nervous :)
<lamont> well, it's released now, at least...
<lamont> arch-dep build done, working on arch-indep now
<lamont> finally
<zul> hmm?
<zul> reiserfs4 has been released?
<lamont> that's what the guy who asked how hard it would be to make a hoary install CD supporting it said...
<zul> ok he might be on crack..
<zul> oh...well according to their website.
<zul> it has been released but still hasnt hit linus's tree and he is on vacation :)
<dilinger> wait
<dilinger> people *want* reiser4?
<zul> apparently
<dilinger> you'd think they would've learned their lesson w/ reiser3..
<zul> *cough* https://bugzilla.ubuntu.com/show_bug.cgi?id=10506
<dilinger> heh
<dilinger> The Great Ubuntuists respond: "you don't really want this.  you really really don't want this."
<crimsun> "and because you really really don't want it, you won't get it" =)
* zul plays a jedi mind trick
<infinity> dilinger : The only lesson users seem to learn is "a new upstream version number will surely fix everything!"
<zul> works for me :)
<dilinger> i like how he says it's supported by hans reiser
<dilinger> as if that's a mark of quality one would want to strive towards
<infinity> Sure, if we pay a support contract to him.
<zul> dilinger: wheres this?
<dilinger> These patches apply cleanly, they are supported by Hans Reiser & company
<zul> meh..
<zul> well...time to go spend time with my wife...bbl
<crimsun> cya
<infinity> Right from the horse's mouth:
<infinity> "We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3."
<infinity> If they claim reiser4 is less stable than reiser3, I'm frightened.
<lamont> lol
<lamont> Processing blk_stop_queue
* lamont yawns
* lamont pounds head on desk
<lamont> arch:all adds about 2.5 hours to the build process, before it dies because brilliance here forgot to add the build-dep.
<lamont> anybody home? (/me is looking for someone who was at the keysigning in UDU)
* infinity raises hand.
<zul> fabbione: merge if you wish, new rt2500, rt2400, squashfs, and some bugfixes
<dilinger> right
<dilinger> keysigning
<dilinger> i should do that now
<zul> grr...some poeple piss me off
<fabbione> morning
<zul> hey fabbione 
<zul> how goes it?
<fabbione> just woke up
<zul> nifty
<zul> im just about to go to bed :)
<fabbione> why did you split the rt2x00 driver?
<zul> because i was asked to by a user...
<zul> against my better judgement
<fabbione> but is there a tech reason for it?
<zul> no
<fabbione> lamont: are you still awake?
<zul> night
<zul> the heat is starting to get to me
<fabbione> night zul
<Drako60> anyone awake?
<fabbione> yes
<Drako60> i'm curious as to why initrd seems to be loading all my modules and not /etc/modules
<fabbione> Drako60: this is not a channel where we do general support. only kernel development related topics
<fabbione> you can ask in #ubuntu
<Drako60> ok someone suggested i ask here a few days ago
<fabbione> initrd loads all the modules that it believes to be required to boot the system
<fabbione> etd/modules is parsed at a later stage
<fabbione> (short answer)
<jbailey> Drako60: If you need to add stuff to that list, use /etc/mkinitrd/modules
<jbailey> Drako60: You then need to regenerate your initrd, though.
<fabbione> this documentation build thingy is a total fuckage
<fabbione> ahhhhh
<fabbione> got it
<Lathiat> heh
<Lathiat> wheres my kernel! ;)
<fabbione> i am waiting ppc to finish the build
<fabbione> and i will be able to upload
<Lathiat> what machines do you have backing the ppc builds on buildd?
<fabbione> only one porting machine and 3 buildds
<Lathiat> porting machine?
<fabbione> well i need a machine where i can test build the kernel
<fabbione> that one is called a port machine
<Lathiat> right
<Lathiat> and then 3 that do the actual building into the archives?
<fabbione> right
<Lathiat> what kinda machines?
<fabbione> can't remember
<fabbione> g5 i think
<jbailey> cc: Hey!
<jbailey> cc: You've come to visit us again, does this mean we did drag you over to the dark side? =)
<Mithrandir> hiya jeff
<jbailey> Heya Tollef.
* Mithrandir already feels the craving for an X2.
<jbailey> X2?
<Mithrandir> dualcore AMD CPU
<jbailey> *lol*
<Mithrandir> I wonder when we'll see x40-style laptops with them.  mmm..
<jbailey> Hopeflly soon.
<jbailey> That way the old amd64 laptops will be driven down in price even further.
* jbailey is eying an HP with an amd64 cpu, and a 15" screen.
<cc> jbailey: i'm usually idling here ;-)
<Mithrandir> the current set of amd64 laptops are "media center" laptops.
<Mithrandir> hi cc
<cc> but no, haven't been dragged, per se
<cc> hi Mithrandir 
<fabbione> humpf
<fabbione> i did something half stupid
* ..[topic/#ubuntu-kernel:fabbione] : Ubuntu kernel development discussion | http://www.ubuntulinux.org/wiki/KernelTeam | There are no kernel bugs.. only broken hardware | http://people.u.c/~lamont/Archives/kernel-team@ubuntu.com--2005/ playground: kernel-debian--pre1,2--2.6.11.92
<fabbione> jeee too many branches!
<horms> yes
<fabbione> yeah i got lost in branching the release and tags :)
<thom> i may as well accept my fate...
<fabbione> UHAAAA
<fabbione> yay
<fabbione> welcome dude
<fabbione> and here is the second one
* chmj looks around, looks behind him
<chmj> :P 
<zul> hey
<lamont> fabbione: testbuild finished at 0251 my time... 
<lamont> doing the dance now
<fabbione> hey lamont 
<fabbione> lamont: meh i already uploaded 92-1.1 with a fix
<fabbione> i didn't find anything here in the logs...
<lamont> fabbione: great - saves me the merge time. :0)
<fabbione> eheh
<lamont> committed kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.91--patch-39
<lamont> A  patches/documentation_docbook-net.dpatch
<lamont> fabbione: the penultimate test build was missing the build-depend on docbook-xml
<fabbione> lamont: the real fix was adding xmlto as build-dep
<fabbione> i did purge docbook-xml
<lamont> fabbione: even better
<fabbione> and removed the default gw
<fabbione> it was asking for xmlto
<fabbione> added that one
<fabbione> btw
<fabbione> FYI
<lamont> kewlness
<fabbione> thom is getting the "welcome to kernel team bug that kills my debian/ dir"
<fabbione> ahah
<fabbione> now.. zul took 2 days to figure it out
* fabbione starts the clock on thom
<thom> heh
<fabbione> thom: i can give you an hint
<zul> you are all bastards
<fabbione> grabbing the debian/ dir from baz is not enough
<fabbione> zul: this is so true!
<lamont> thom: zgrep ^diff linux-source_<oldversion>.diff.gz
<zul> i know...its obvious
<zul> and once now that you all know that you are bastards...im happier
<fabbione> thom: who sais that debian/ is the only thing contained in the diff.gz :)
<lamont> thom: s/^diff/^---/
<zul> oh...so you help thom out right away :P
<lamont> zul: I was sleeping while you were working on it.
<zul> hehe
<fabbione> anyway i am off
<fabbione> i will be back tomorrow
<fabbione> i still don't feel super 100%
<fabbione> and i am supposed to be spending time with my wife today
<fabbione> it's her bday
<lamont> fabbione: you better go then.
<fabbione> yeah
<zul> bbl...i have to run errands today
<fabbione> lamont: how are the buildd going on kernel?
<fabbione> amd64 is done
<fabbione> i am more worried about i386
<lamont> i386 is building the last flavor
<mvirkkil> zul: Just popped in to say thanks for the hollywood+/dxr3 support :-) Haven't tried it yet though.
<Drako60> hmm i wish i could figure this problem out
<fabbione> mvirkkil: difficult to try.. it's not in the archive yet :)
<fabbione> i am off
<fabbione> cya guys
<mvirkkil> fabbione: I just read that zul had marked the bug as fixed in bugzilla. 
<zul> when the next upload goes through
<mvirkkil> Not familiar with the process. Any etA?
<zul> today i think not 100% sure
<mvirkkil> Cool. I was thinking along the lines of weeks :-)
<zul> nope
<mvirkkil> Must say that that was one of the quickest fixes for an rfe I've filed.
<zul> i was home at the time
<Drako60> can i ask a question no one in #Ubuntu seems to be able to clarify this for me
<thom> grah, you guys all suck :-) that's a truely silly patch 
<lamont> thom: yeah
<lamont> Drako60: go ahead and ask another question....
<fabbione> now.. this is scary.. my wife and i were supposed to go shopping.. she decided to go to sleep
<chmj> hahaha
<Drako60> ok well i get an error from Nforce3-250 durring boot saying BIOS didn't set cable bits correctly, and i can't figure out where this error is coming from other then related to DMA, which has lead me to believe its A. the motherboard. B the bios. or C. the module being loaded
<fabbione> or simply a combination
<fabbione> or the IDE cable is not the correct one (mostlikely)
<thom> hrm, we should totally teach dp-e-p to build hardlinked trees, too
<fabbione> i am not sure you can
<fabbione> specially because you can have source in  partion A and /tmp on B
<fabbione> that will break hardlinks
<zul> fabbione: wll it is her bday
<Mithrandir> cp -al should work fine.
<fabbione> zul: ???
<zul> gah...well it is your wife's birthday
<fabbione> yeah but there are NO women in this world that can resist to shopping
<thom> fabbione: i don't think that's a particular problem; you could just make dpep build the tree in the same parent dir if it turns out to be a problem
<zul> fabbione: i think you found one 
<Drako60> ok thanks fabbione thats what i was thinking but i wasn't sure, and i wanted to know if i could check in what order initrd was loading the modules, i don't know if lsmod shows the order loaded or not
<fabbione> zul: nah...
<fabbione> Drako60: reverse order.. yes it does
<fabbione> top is the most recent
<fabbione> but it has nothing to do with the modules
<Drako60> well i'll deal with the cables tomorrow, atleast that will narrow the issue down
<fabbione> baz commit -s'Update amd64/ia64/sparc abi files'
<fabbione> YAY
<fabbione> first set of abi files...
* thom goes to get lunch while this kernel builds
<fabbione> yay
<fabbione> i386 successful
<chmj> :-) 
<Lathiat> woo
<zul> meh...console_macros.h changed
<zul> or doesnt exist anymore
<fabbione> zul: ah no i rememeber.. the rt2500 doesn't build on ppc anymore
<fabbione> the one before the split did
<zul> how come?
<fabbione> the last one doesn't
<fabbione> different code?
<zul> probably
<fabbione> it was ranting about some endian things
<fabbione> + other stuff
<zul> frig..
<thom> bonus, skge actually compiles ;-)
<fabbione> thom: on all 6 arches?
<thom> just amd64-generic so far
<fabbione> thom: there might be light at the end of the tunnel :)
<thom> i just want to test it first :-)
* fabbione declares the end of the day
<fabbione> cya tomorrow guys
<zul> todles
<thom> guys, can you have a look at http://people.ubuntu.com/~thom/arch/thom@ubuntu.com--fandango/ kernel-debian--pre1,2--2.6.11.92--patch-2
<thom> and check i've not done anything *stoooopid*
<chmj> did you just remove that patch ?
<dilinger> thom: like, UHF stupid?
<thom> uhf?
<dilinger> it's a movie.  i'm guessing that's a no
<lamont> dilinger: funny movie, too
<dilinger> it and family guy are the only dvds i own (uhf was $5 in some bargain bin.  i couldn't pass it up)
<zul> doh...i forgot about the cc today..
<zul> thom: did you get somet to check your patch?
<zul> real funny..weird al and michael richards
<zul> ok i had enough of oprah
#ubuntu-kernel 2005-05-19
<zul> hey horms
<jbailey> Ugh.  Anyone here know alsa well?  I'm curious of there will ever be software mixing as part of /dev/dsp.  Annoying to have sounds just work right on some machines and not on others.
<zul> ask crimsun 
<jbailey> zul: Cool. Hopefully that'll trigger his nick highlight. =)
<lamont> fabbione: do we have ipv6 -m state iptables yet?
<zul> TheMuso: so you got the speakup patches working?
<TheMuso> I got the patch applied to the kernel cleanly, but it won't build. This is bebecause speakup puts hooks in vt.c. However I don't think it is using the right variable to reference the current console.
<TheMuso> If I knew what the variable for referencing the current console was, I could change it. I have noticed this change a few times in recent kernel versions thorough 2.6.9-2.6.12
<zul> TheMuso: it probably isnt..console_map.h was removed between 2.6.11 and now so speakup stuff probably has to reflect that to get it to  work
<TheMuso> I will have a look.
<TheMuso> According to the source, console_map is not referenced. The latest version is able to be applied cleanly against 2.6.11 final.
<zul> the cvs version?
<TheMuso> Yes, and the 2.0 tarball.
<TheMuso> CVS hasn't changed since that was released.
<zul> meh...where did i see it
<zul> cvs tar ball is refering to 2.6.11
<TheMuso> Yes thats right.
<zul> sorry..i meant console_macros
<TheMuso> But much has changed in the kernel between then and 2.6.12rc4
<zul> console_macros.h have been removed and now i belived its a struct
<TheMuso> Right.
<TheMuso> Have you got a copy of speakup there?
<zul> so you have to check what is changed with console_macros with drivers/char/speakup
<zul> yep
<TheMuso> I don't really know what I am looking for.
<zul> but im also going to bed soon
<TheMuso> np.
<TheMuso> The speakup hooks use the currcons variable to refer to the console that they are giving Speakup the data from. What should this be changed to?
<zul> not sure yet..
<zul> i only had a brief look at it
<zul> currcons remains unchanged i think
<TheMuso> Well the kernel wouldn't build if that was referred to in the Speakup hooks for vt.c
<zul> i was going to look at it tomorrow :)
<TheMuso> No problem.
<TheMuso> I'll see what I can come up with in the meantime.
<zul> sure..
<zul> night
<TheMuso> Later.
<fabbione> morning
<fabbione> thom: the patch looks good, there is only thing i need to check...
<fabbione> lamont: no, not yet.
<fabbione> lamont: that would be something i should so asap
<fabbione> lamont: but the point is that we also need a brand new iptables package probably
<fabbione> thom: ok.. the patch as it is can work.
<fabbione> generally we need to pay more attention when pulling in drivers update
<fabbione> the main issue are the PCI IDS that they claim to handle
<fabbione> in this specific case your skge driver claims the same pci ids as the sk86ge driver
<fabbione> so there are 2 ways to handle it
<fabbione> either you deconfigure the old driver from being compiled
<fabbione> or you maintain the new driver as patch on top of the old one
<fabbione> either way it's fine by me.
<fabbione> the cleanest is to disable the old one imho
<fabbione> and make the new one live somewhere else
<fabbione> also.. updating the changelog is a good idea :)
<fabbione> i didn't check the configs, but these needs to be updated too 
<Lathiat> what version of ipw2200 is in the 2.6.12 in the archives?
<fabbione> ipw2200            | 1.0.3                      | ok     | 12/04/2005   | http://ipw2200.sourceforge.net/
<Lathiat> thanks fabbione 
<lamont> fabbione: btw, I dropped in the new hppa patches
<fabbione> yup.. i saw that ...
<fabbione> something is wrong with portmapper
<fabbione> cvs checkout from linux-ipv6 is slow to death
<thom> fabbione: yeah, i did the configs; i'll turn off sk98lin when i'm happy with it
<fabbione> thom: the problem of having 2 drivers exporting the same PIC Ids, can confuse hotplug
<fabbione> and the wrong driver being loaded
<thom> nod
<fabbione> food :)
<thom> fabbione: well, skge seems to _work_ anyway
<fabbione> thom: ok.. i think you have write access to lamont archive.. 
<fabbione> go ahead and merge :)
<fabbione> i will check it tomorrow
<fabbione> just remember to disable the old driver
<thom> yeah, i'm gonna do that now
<thom> well, i'm gonna check the pci ids first, then disable it
<fabbione> i already did
<fabbione> (the pci ids)
<fabbione> they conflicts
* fabbione larts the rh cluster suite with a cluebat
<thom> ok
* fabbione goes offline for a while
<thom> fabbione: hrm, skge is doing the same thing as sk98lin; there's something wackier going on
<zul> meh..
<thom> May 11 14:37:53 localhost kernel: [ 4488.615253]  skge eth0: disabling interface
<thom> May 11 14:37:53 localhost kernel: [ 4488.625044]  skge eth0: enabling interface
<thom> often
<dilinger> fabbione: have you got rc4 working?
<zul> thom: do you have the linux *.92 stuff available i blew away my stuff by mistake and fabbione took it down from his webpage
<thom> zul: it's in the archive, isn't it?
<zul> nope not the *.orig *.dsc 
<thom> zul: it so is :-) http://archive.ubuntu.com/ubuntu/pool/universe/l/linux-source-2.6.12/
<zul> meh...so it is :)
<TheMuso> zul: I haven't had much luck with speakup. I expect that once 2.6.12 comes out, Kirk the author of Speakup will make changes in CVS to work with that kernel version. Unless getting speakup sorted is a priority for you, I am not going to worry about it till 2.6.12, maybe longer.
<zul> TheMuso: thats what i figured as well
<TheMuso> zul: As it is however, I am going to continue examining the code as I want to add some enhancements for better multi-user environment interoperability, to hopefully interface with a userspace daemon I am currently planning to write.
<zul> TheMuso: go ahead...you might want to work upstream with it though
<TheMuso> zul: I was certainly thinking that. I have to work out how to add the enhancements though, sa the author doesn't take too kindly to helping people so much, in a few words he says "Figure it out yourself, and I am happy to accept patches."
<zul> sounds familar :)
<TheMuso> Does it ever. :)
<TheMuso> Speakup doesn't work properly on PoewrPC either. I have debugged it, but can't work out a sollution yet either. I think I know what it is, but since it is to do with the hooks that are put into v.c, things are a bit hairy.
<lamont> moo
<TheMuso> s/v.c/vt.c/
<zul> hey lamont 
<lamont> morning
<zul> how goes it?
<TheMuso> zul: Anyway, I am off for the night.
<zul> TheMuso,: toodles
<lamont> zul: well, I suppose.  No more 9-year-old.
<lamont> is 10 now.
<zul> oh that makes it sooo much better ;)
<lamont> yeah.  something like that.
<lamont> breakfast time
<fabbione> re
<fabbione> dilinger: it's in the archive...
<fabbione> as 2.6.11.92
<fabbione> thom: are you sure it did load the right driver?
<fabbione> lamont: is there something wrong with the buildd????
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/l/linux-source-2.6.12/2.6.11.92-1.1/
<fabbione> has like 3 ppc builds?
<fabbione> thom: are we 100% sure it is a driver problem?
<fabbione> i remember the driver from sk to be much bigger than just 2 files...
* fabbione is still doing a cvs co from linux-ipv6
<fabbione> that cvs server is the slowest i have ever seen
<fabbione> BREAKING NEWS
<fabbione> The U.S. Capitol and White House are being evacuated. Details soon.
<fabbione> cnn.com
<fabbione> wtf is happening?
<thom> fabbione: i'm not at all sure it's a driver problem
<thom> fabbione: HUH?
<thom> ah, all clear given now
<zul> fabbione: some plane flew over the capital.
<fabbione> zul: ahaha
<thom> fabbione: and yes, definitely skge not sk98lin - i deleted the sk98 stuff manually
<fabbione> thom: ok
<fabbione> i wonder if it is something they did not update
<fabbione> like mii-tools interface
<thom> yeah, that was my thought
<thom> i'm gonna dig through now
<fabbione> thom: ok
<thom> (i've been asleep - i feel like death currently)
<fabbione> UdUFlu?
<thom> probably, yeah
<fabbione> yeah i have been sleeping a bit too
<fabbione> this morning i was coughing blood
<zul> lovely
<zul> bravo in fact
<thom> fabbione: ouch dude
<fabbione> yeah that was lovely.... blood is tasty...
<zul> try it with milk
<zul> arrgh...need job...going crazy..
<zul> fun...macauley culkin is on the stand today in the freako case today
<zul> hey jeff
<jbailey> Heya Chuck
<fabbione> hey jb
<fabbione> what's the status with l-k-h?
<jbailey> fabbione: I'm planning an upload today.  I haven't looked at the sparc stuff yet (will do today), aside from that am fixing the C99 long long bug and the ppc binutils bug.
<jbailey> fabbione: BTW, We started #ubuntu-toolchain yesterday.  Should I email you to get it logged?
<fabbione> jbailey: i can do it right away
<jbailey> That would be lovely.
* #ubuntu-kernel  [freenode-info]  why register and identify?  your IRC nick is how people know you.  http://freenode.net/faq.shtml#nicksetup
<dilinger> paul starzetz is awesome
<dilinger> his advisories are non-embargoed, explained fully in proper english, provide POC, and are never boring
<fabbione> dilinger:  i am still waiting the nice crack from pitti
<dilinger> fabbione: it should be a simple fix
<dilinger> if (len < 0) return EIO; or something similar (haven't looked at the source yet, just the advisory, so i'm not sure what the proper return should be)
<dilinger> how nice
<dilinger> that's in fill_psinfo()
<dilinger> elf_core_dump calls that, but doesn't check the result
<dilinger> fabbione: if you haven't already seen it
<dilinger> http://mouth.voxel.net/~dilinger/core_dump_vul.patch
<dilinger> and the rumor is, it's CAN-2005-1263
<fabbione> dilinger: no i don't...
<fabbione> mind to send it via email to me and pitti?
<dilinger> done
<fabbione> thanks
<zul> fabbione: https://bugzilla.ubuntu.com/show_bug.cgi?id=7808 did you miss this one?
#ubuntu-kernel 2005-05-20
<lamont> anyone know which driver provides rtc on amd64?
<zul> there...quickcam and spca5xx playing together like two peas in  a pod
<zul> bleah...i cant sleep
<fabbione> morning
<zul> hey fabbione 
<fabbione> zul: 7808 is d-i related. we still need todo thed-i cleanup in the kernel
<fabbione> see debian/TODO
<zul> updated?
<fabbione> Verify debdiff with previous kernel and add new drivers to d-i.
<zul> okie dokie printk stuff...what do you want to cut down?
<fabbione> there are a couple of printk during the boot that are marked as _ERRO or _CRIT
<fabbione> the audit thing
<fabbione> and the swsup wrong partition id
<zul> ok i can look into that
<fabbione> they should be changed to _INFO
<fabbione> we don't want to lose them
<fabbione> just make them less noisy
<zul> so the audit: <blah blah>
<fabbione> yes
<fabbione> and the swsups one
<zul> okie dokie
<zul> so something like this? http://zulinux.homelinux.net/kernel-power-swsusp_shutup.dpatch  
<fabbione> except you diffed it the wrong way yes
<fabbione> but not all of the messages
<fabbione> only the one that shows at startup
<zul> ok...then it might be time get some sleep then
<zul> ok
<fabbione> some of them are important to have
<zul> ill see you guys tomorrow
<fabbione> night zul
<zul> i added some more external drivers from the list but ill put them in my baz archive when i get up tomorrow
<zul> late
<zul> later even
<fabbione> ok
<fabbione> lamont: ping me when you are around again
<lamont> ack
<fabbione> lamont: i was wondering if we can integrate sparc build logs on people
<lamont> yeah - that's on my list of things to ponder.
<lamont> specifically, now to integrate them.
<fabbione> i guess you have somekind of script that scp them from the buildd's to people
<fabbione> we might just adapt it
<fabbione> you probably have to change the permissions on the tree so that i can write there
<lamont> actually, the copy on rookery is a mirror of the master, that lives elsewhere
<fabbione> ah
<fabbione> hmmm
<fabbione> that makes it more complicate
<Lathiat> mmm the ipw2200 driver has gone from crashing requiring a module reload to crashing requiring a reboot :\
<fabbione> Lathiat: complain with upstream
<fabbione> it's the latest version of the driver
<Lathiat> yeh i know was just saying
<Lathiat> is it hard to debug kernel drivers?
<fabbione> pretty much yes
<fabbione> how much do we care about the abi in 2.6.11.9* serie?
<fabbione> there.... rh cluster suite updated
<fabbione> lamont: i am still checking out linux-ipv6
<fabbione> unbelievable
<fabbione> more than 24 hours co
<Lathiat> ouch, which project is that from?
<fabbione> linux-ipv6/usagi
<lamont> fabbione: I don't think we care about the abi version until 2.6.12-1.1
<fabbione> ipv6 statefull firewall
<Lathiat> yeh usagi
<fabbione> lamont: yeah
<lamont> esp since if we did, we'd be something like 2.6.12-22.1
<fabbione> lamont: exactly :)
<fabbione> lamont: btw.. why the kernel did build 3 times on ppc buildds???
<fabbione> at least... there are 3 logs reported
<lamont> fabbione: most likely situation was those wonderful SIGILL's that ppc likes to throw on big builds
<lamont> it's also possible that I gave it back in the middle of a build
<fabbione> ah ok
<fabbione> hey
<fabbione> doko, svenl: can we take a look to PPC64 kernel?
<fabbione> i need to understand a few things
<fabbione> right now we have 6 ppc flavours
<fabbione> power3{,-smp}
<fabbione> power4{,-smp}
<fabbione> powerpc{,-smp}
<fabbione> which one of these need to become 64bit?
<fabbione> or do we need to add a complete new set of flavours?
<fabbione> for me all this ppc magic is kinda unknow
<fabbione> and i need to understand what needs to be done
<doko> hmm, don't know, if I can help ...
<fabbione> doko: well you were asking for a ppc64 kernel
<fabbione> so where can i build a ppc64 kernel in the first plave
<fabbione> place
<doko> davis, breezy-ppc64 chroot
<fabbione> ok.. 
<doko> using gcc-3.4 -m64
<fabbione> ok we are already using gcc-3.4
<fabbione> i think the -m64 is added by the kernel automatically when exporting ARCH=ppc64
* fabbione checks
<fabbione> yes
<fabbione> that is done automatically...
<fabbione> so now.. i need to understand what flavours need to be built that way
<fabbione> GCC_BROKEN_VEC  := $(shell if [ $(GCC_VERSION) -lt 0400 ]  ; then echo "y"; fi ;)
<fabbione> interesting :)
<svenl> fabbione: basically, the only thing you need to do is to add ARCH=ppc64 when building.
<svenl> fabbione: i guess for symetry purpose, you would need to do :
<fabbione> svenl: yes.. i know that, but i am more interested to know what flavours i need to build
<svenl> ARCH=ppc for powerpc flavour, and ARCH=ppc64 for the ppc64 flavours.
<svenl> well.
<fabbione> yeah i get that :)
<svenl> both power3 and power4 are now called pseries.
<svenl> so i would have pseries and iseries.
<svenl> that is : powerpc/ppc, pseries/ppc64, iseries/ppc64
<fabbione> ok from the actual mapping:
<svenl> but it is also possible to build a power4 and beyond optimized pseries version, so i would add a : 
<fabbione> powerpc{,-smp} -> ARCH=ppc, no name change
<svenl> pseries-power4/ppc64.
<svenl> fabbione: ok.
<fabbione> how do i map power3 and power4?
<svenl> fabbione: for power3/power4, just add new versions.
<fabbione> so something like:
<fabbione> ppc64-power3
<fabbione> ppc64-power6
<fabbione> meh
<fabbione> ppc64-power4 <-
<fabbione> and of course build them with ARCH=ppc64
<svenl> one moment.
<fabbione> sure
<svenl> fabbione: forget the old mappings.
* fabbione scraps the notes
<svenl> Ok, am back.
<fabbione> no rush....
<svenl> fabbione: i don't have it in my mind right now, but basically, for all ppc/ppc32, the configs should be almost similar.
<svenl> with a little modifications.
<fabbione> svenl: right now i need only the name schema
<svenl> fabbione: ok.
<fabbione> forget about the contents of the configs
<svenl> so, i would do :
<svenl> ARCH=ppc -> powerpc{-smp}
<svenl> ARCH=ppc64 -> pseries{-smp}
<svenl> ARCH=ppc64 -> pseries-power4{-smp}
<svenl> ARCH=ppc64 -> iseries{-smp}
<fabbione> where is power3 in this schema?
<svenl> as for the actual difference between the 3, iseries is the iseries variant, and pseries is the pseries one.
<svenl> and pseries-power4 is the power4 optimized version of pseries.
<svenl> fabbione: pseries now support both power3 and power4.
<svenl> fabbione: but you can enable power4 and beyond only optimization, which bring a performance gain, but drop support of the power3.
<svenl> This is pseries-power4.
<fabbione> so what is the iseries?
<fabbione> i am sorry if these questions are lame
<fabbione> but i am trying to understand the best i can
<infinity> AS/400.  I didn't think they were shipping with different CPUs than the pseries, just different gear under the hood...
<svenl> fabbione: iseries are IBM/power big iron, not previous supported by the ppc32 kernels.
<fabbione> oh
<fabbione> so that means generating heaps load of images
<svenl> fabbione: not really.
<fabbione> of the old power3/power4 images.. is there something we can actually drop safely?
<infinity> For the installer, we should be able to cut back to two images.
<infinity> A very generic ppc32 and a very generic ppc64.
<svenl> it will only be 8 images compared to 6 previously.
<svenl> fabbione: we can indeed only keep powerpc and pseries for the installer.
<infinity> Unless the ppc64 generic images wont boot on AS/400 kit for some reason, and that would be silly.
<svenl> or maybe powerpc and pseries-smp
<fabbione> ok
<svenl> fabbione: i would build iseries as netboot only.
<fabbione> let me try to summarize
<fabbione> svenl: netboot will still require an image
<svenl> but this means enabling the mkvmlinuz build.
<fabbione> powerpc stays as it is
<svenl> fabbione: sure, but you don't need to put it on the CD.
<fabbione> power4{,-smp} -> pseries-power4
<fabbione> power3 -> vanish
<svenl> mmm, come to think of it, mkvmlinuz needs fixing for ppc64.
<svenl> fabbione: nope.
<fabbione> we introduce iseries and pseries
<svenl> power[34] {-smp} -> pseries{-smp}
<fabbione> ok
<fabbione> roger that
<svenl> pseries-power4{-smp} is an optimized version of the pseries for power4 and beyond.
<fabbione> how big is the performance gain?
<svenl> like you have normal -386 and -k7 and such.
<svenl> fabbione: not sure.
<svenl> fabbione: 20-40 % maybe ? 
<infinity> I'd question that 40.. :)
<infinity> 20 would be generous.
<svenl> need to ask the IBM guys.
<svenl> infinity: i don't know.
<fabbione> i think no more than 5%
<svenl> but it is an important gain.
<svenl> fabbione: how much would be the gain from -i386 to -k7 ? 
<infinity> It's a measurable gain, but it's not massive.
<svenl> anyway.
<fabbione> svenl: minimal :)
<infinity> Especially not from the point of view of userspace.
<svenl> infinity: the ppc64 guys told me : please don't cripple the ppc64 kernels.
<svenl> but well.
<svenl> fabbione: if you want to gain space, you can drop the non-smp power3 variant.
<infinity> Can't we pull tricks to optimise for power4, without using new ops?
<fabbione> why that?
<infinity> (This can be done in intel systems, slowing down older CPUs, but allowing them to still work)
<infinity> Also, I question the value of any non-smp kernels, but that's something we still need to test more, I suppose.
<svenl> power3 boxes are few indeed, and the majority of those are smp variants, and the smp kernel should work on up.
<svenl> so i would do :
<svenl> powerpc, powerpc-smp, pseries-smp, pseries-power4, pseries-power4-smp, iseries
<svenl> (i guess it makes no sense to have non-smp iseries :)
<fabbione> so it would be:
<svenl> which leaves us at exact the same amount of kernels as today.
<fabbione> powerpc, powerpc-smp, pseries-smp, pseries-power4, pseries-power4-smp, iseries-smp
<fabbione> just to keep the name schema coherent
<svenl> fabbione: yep.
<infinity> There are single CPU iseries machines, but the only people who use them are hackers writing software for the big iron, generally.
<svenl> infinity: so they can live with the 5% or whatever performance drop, or use their own stuff.
<fabbione> hackers don't use precompiled kernels
<svenl> infinity: do you know what those iseries machine use for booting ? 
<infinity> Not sure.  I've only seen one, and it was running AIX.
<infinity> AndErm, OS/400.
<infinity> Brain fart.
<infinity> But, yeah.  I didn't ever hit the little white switch to reboot it.
<infinity> It was happy on its own.
<svenl> infinity: do you think yaboot will work on them ? 
<infinity> It's possible.  I'd like to get my hands on one for testing.
<svenl> And those are the ones which don't do funny partitioned computing stuff.
<infinity> A single CPUU iSeries can still run VM, but I'm not sure why one would want to. :)
<infinity> (It's a possible use case, though)
<infinity> But unless we have some people at IBM who want to help out, this is all "I played with one a couple of years ago" experience.
<svenl> i will investigate about this.
<svenl> fabbione: will you build an 2.6.12-rc4 kernel packages ? Or still go with 2.6.11 ? 
<svenl> 09:58 < mpee_> svenl, a non SMP kernel won't boot on iSeries so don't bother
<infinity> Oh, they actually market single CPU iSeries stuff to end-users now.
<infinity> And yes, they're running VM by default.
<fabbione> svenl: 2.6.12rc4
<svenl> so i guess that solves it. I would drop the -smp name of it though.
<svenl> fabbione: cool.
<fabbione> i am not spending time on .11
<infinity> (Which allows them to ship them with Linux and OS/400 installed, in two seperate partitions)
<svenl> do you have something i can try on my powerbook already ? benh said that 2.6.12-rc4 will solve all power management and sleep issues.
<infinity> Which would also explain why the non-smp kernels won't work, cause I think all the VM magic is tied to SMP.
<fabbione> svenl: not for ppc64
<fabbione> svenl: the 32 bit images are in the archive already
<fabbione> universe -> linux-source-2.6.12/
<svenl> 10:01 < benh> svenl: pmac/pseries/everybody else can be a single image
<svenl> fabbione: no prebuilt kernel though.
<svenl> fabbione: you think my powerbook G4 will like ppc64 kernels ? 
<fabbione> yes.. they are in that dir
<fabbione> svenl: no idea.. i am not a ppc guy :)
<fabbione> that's why i keep asking ppc stuff around
<svenl> fabbione: :)
<fabbione> svenl: what does benh mean?
<svenl> fabbione: the G4 is ppc32.
<svenl> 10:01 < benh> svenl: drop UP kernels on ppc64
<svenl> 10:01 < svenl> benh: :)
<svenl> 10:01 < benh> svenl: I don't think they make any sense
<svenl> 10:01 < benh> svenl: iseries ... oh well, yes, they still need a specific kernel
<svenl> 10:01 < benh> svenl: pmac/pseries/everybody else can be a single image
<svenl> 10:01 < benh> svenl: I'm not sure about the performance impact of doing the CONFIG_POWER4 option there
<svenl> 10:01 < svenl> benh: even on pseries-power4 ? There are a bunch of single CPU G5 pmac about, don't they would lose in
<svenl>                performance.
<svenl> 10:02 < svenl> benh: do you know who might know ?
<svenl> 10:02 < benh> svenl: maybe they would ...
<svenl> 10:02 < benh> dunno
<svenl> 10:03 < svenl> ok, so i guess we should keep them in the first run, and then drop them after a bit of experimentation.
<svenl> fabbione: basically, he is advocating having only 2 ppc64 kernels, pseries and iseries, both of the smp variant.
<fabbione> ok
<fabbione> and one ppc32 kernel
<svenl> but 1) no idea what the performance drop will be for single cpu powermac G5s.
<svenl> and 2) no idea if the power4 optimization is worth it.
<fabbione> ok we can start with the minimum
<fabbione> and see if people will request other kernels
<infinity> Shame about iseries needing its own kernel.
<fabbione> so we will still have 6 kernels :(
<svenl> fabbione: i would do :
<fabbione> no.. actually less
<infinity> 3?
<svenl> 32bit : powerpc, powerpc-smp
<fabbione> powepc{,-smp}
<infinity> Oh.
<fabbione> pseries-smp
<svenl> 64bit : pseries, iseries
<fabbione> iseries-smp
<svenl> optional 64bit optimized kernels : 
<svenl> pseries-power4
<svenl> pseries-power4-up
<infinity> I'd scrap those two, but whatever.
<fabbione> me too
<fabbione> we need to reduce the amount of images
<svenl> so, we keep 4 and put them on CD, and build the two others, and keep them on the net.
<svenl> fabbione: well.
<svenl> fabbione: i would like them to be present in the first round, so we can do performance tests, and then decide.
<svenl> fabbione: but as said, you don't need to put them on the CDs.
<fabbione> svenl: i prefer the other way around :)
<infinity> Has anyone done recent tests to see how much it hurts to run smp on up?
<svenl> fabbione: not build them, and then make performance tests ? 
<svenl> infinity: i think not.
<svenl> fabbione: maybe we could inverse the situation : 
<infinity> powerpc-smp should be the only powerpc kernel, if we can help it.
<svenl> powerpc, powerpc-up, pseries, iseries.
<infinity> (And I'm saying this as  aman who owns a ppc32 up machine)
<svenl> We can then drop to 3 : powerpc, pseries, iseries.
<fabbione> svenl: no that would be confusing to death
<svenl> and then 3 set of optimized kernels : powerpc-up, pseries-power4 and pseries-power4-up.
<svenl> fabbione: why ? 
<fabbione> because the actual schema is -smp
<fabbione> change it to -up and users will get confused
<svenl> fabbione: so what ? 
<svenl> fabbione: users should not know about this.
<svenl> fabbione: have the powerpc/pseries/iseries provide the -smp version and everyone will be happy.
<fabbione> svenl: they do and they ask questions about stuff like that
<svenl> fabbione: so what ? That is what the long description is all about.
<fabbione> + it breaks coherency with the other arches
<svenl> fabbione: so what ? 
<svenl> fabbione: if we are gonna default to smp versions, let's make it logical. The users will thank you in the long run.
<fabbione> svenl: i want to be able to keep things coherent even across arches
<svenl> infinity: BTW, how do you make up vs smp kernel performance tests ? I could do those on my powerbook.
<infinity> svenl : <shrug>... Pick a benchmark you like, compile two kernels, identical except for CONFIG_SMP, see how it performs?
<infinity> svenl : Benchmarking isn't an exact science, since everyone will want to test different things.  Just pick something that should give reasonably consistent numbers.
<infinity> I should do this on my amd64 machine when I get it back up, too.
<svenl> infinity: ok, my question would be of the kind : what kind of benchmark stress the kernel and not userland ? 
<infinity> svenl : SOmething that shoves a lot of RAM around for no good reason?.. Filesystem tests... Make something up? :)
<infinity> svenl : The real answer is "who cares?.. It's userland performance people see"
<svenl> infinity: ok, i will look around.
<svenl> infinity: :)
<infinity> If a different kernel doesn't appear to affect userland by more than 5%, I say it's "good enough"
<fabbione> svenl: can a pseriers kernel boot on g5?
<infinity> Yes.
<infinity> Same CPU.
<fabbione> infinity: Xu said that the main issue with SMP on UP is the locking mechanism at net layer
<infinity> Well, sort of.
<fabbione> but that's due to:
<svenl> fabbione: sure.
<fabbione> a) crappy code
<fabbione> b) very very high load on cpu and net (~1GB)
<fabbione> so it is for sure NOT the common case
<svenl> fabbione: notice that the power3 sym53c8xx driver did lock in up mode, and worked fine in smp mode on a dual power3 machine.
<infinity> Which brings us to: Thee are shitty Mac-specific drivers for older macs (like my Beige G3) that may suck on SMP, because that hardware just doesn't get used with more than one CPU.
<infinity> But it's not hard to put out a call for testers for that sort of thing.
<infinity> Most of those driver bugs would surface immediately as oopses or panics, nothing subtle.
<svenl> infinity: you default to smp early in the release cycle, and wait for bug reports :)
<infinity> People doing constant updates of breezy don't think to upgrade kernels.
<infinity> You call for testers, or risk the wrath of a broken installer at release time. :)
<svenl> 10:21 < olaf> svenl: running 64bit smp vs. 32bit up on single cpu systems cost 2%
<infinity> fabbione : Any objections to dropping the product names (powerpc, pseries) completely from the generic kernels, and just naming them like the hppa kernels?
<svenl> 10:23 < olaf> I did not benchmark that. but noone cares. large enterprise thingies run with power4=n and they dont care
<fabbione> nope
<infinity> (2.6.12-32{,-smp}, 2.6.12-64{,-smp})
<svenl> 10:24 < olaf> I did that 64bit smp vs 32bit up on a G5
<infinity> Then for the iseries flavour, you'd have 2.6.12-64-iseries
<infinity> Still pretty clear.
<fabbione> it is just important for me to keep -smp in
<fabbione> to be coherent with the other arches
<infinity> Right.  Well, I always found the hppa kernels to be nice and intuitive.. And clean.
<infinity> It was obvious what kernel I actually wanted. :)
<fabbione> exactly
<infinity> And Kamion's point about "who would install a kernel called 'pseries' ona G5 Mac?" is a good one.
<fabbione> yup
<fabbione> chmj, thom: you around?
<infinity> Mac users aren't known for being able to extend their thought processes terribly far.
<thom> yep
<fabbione> chmj, thom: please start to get familiar with git/cogito
<chmj> yep 
<fabbione> there are deb packages around announced on debian-devel mailing list
<fabbione> or install it from http://www.kernel.org/git/
<fabbione> checkout the relevant trees
<fabbione> linux/kernel/git/torvalds/linux-2.6.git linux/kernel/git/gregkh/stable-queue.git linux/kernel/git/gregkh/linux-2.6.11.y.git 
<fabbione> we have some crack to deal with
<fabbione> get used on how to grab a single patch out of the tree
<fabbione> it's pretty simple
<infinity> fabbione : Oh, BTW, I sign a lease tomorrow and move my amd64 somewhere where I can actually plug it in, so I will become more useful at that point.
<fabbione> you use a combination of cg-log and cg-mkpatch
<fabbione> infinity: rocking :)
<svenl> fabbione: i disagree with the -smp part of it.
<svenl> fabbione: you will only get questions from people asking where the -up version went.
<svenl> fabbione: did you see the info from olaf ? 
<svenl> fabbione: i would guess just keeping the smp version of powerpc, pseries, iseries would do it.
<svenl> as -32, -64 and -64-iseries.
<svenl> infinity: you could even do -32 -64 -iseries, as i guess anyone with an iserie machine will know he needs a 64 bit kernel.
<fabbione> svenl: yes i saw the msgs from olaf
<svenl> fabbione: so we are down to 3 (4 if we keep the up 32bit kernels) and add one full subarch.
<svenl> infinity: the only problem with your naming scheme would be if you where to support stuff like apus or nubus, which are not yet integrated in the main kernel, as debian will do.
<svenl> but then you could have -32, -64, -iseries, -nubus, -apus.
<svenl> Would also work fine.
<fabbione> the only thing i need basically is to be able to recognize a 64bit kernel from a 32bit one from the name, without hardencoding anything in debian/rules
<fabbione> so something like -64- or ppc64 has to be there
<fabbione> for the sake of simplicity
<fabbione> so that given a regexp match i can set the proper arch
<svenl> fabbione: just have a flavour file, which gives you the right arch for a given flavour, and parse it from debian/rules.
<svenl> fabbione: see how i do it in the 2.4.27 debian powerpc package.
<fabbione> there is no kernel-image-2.4.7-ppc
<fabbione> 27 even
<svenl> kernel-patch-powerpc-2.4.27
<svenl> fabbione: well, it is overkill for your needs, but the basic format is : 
<svenl> arch: <list of archs>
<svenl> subarch <arch>: <list of subarches for that arch>
<svenl> flavour <subarch>: <list of flavours for that subarch>
<fabbione> yeah i see
<svenl> so you could either have two subarches, ppc and ppc64, and a couple of flavours for each.
<svenl> or have only subarch, and use a field to get it.
<svenl> something like subarch-arch <subarch> : ppc64
<svenl> i extract them by grep/sed, which may not be the more astute way of doing it.
<svenl> but i believe it is better to have a explicit list, than to try to do some implicit detection like you plan to do.
<svenl> and you could even have : 
<svenl> arch : powerpc
<svenl> subarch powerpc : apus nubus ppc32 ppc64
<svenl> flavour ppc32 : 32 32-smp
<svenl> flavour ppc64 : 64 iseries
<svenl> or whatever.
<fabbione> i don't need that kind of complexity
<svenl> fabbione: bah.
<fabbione> flavour[iseries] =ppc64
<svenl> fabbione: remember, we spoke of unifying the kernel package with debian, and debian will most decidedly need it.
<fabbione> that's all i need
<svenl> for now.
<fabbione> yes but i still don't need to make things more complex that they need to be
<svenl> how do you think that debian will handle something like the subarch specific patches mips has ? 
<fabbione> svenl: the same way as i do? checking for a per arch patchlist to apply?
<fabbione> per arch and per flavour
<fabbione> because that it is easy to implement
<fabbione> what we need to address now is:
<fabbione> given flavour foo, what arch is that?
<fabbione> for our case:
<fabbione> arch[iseries-smp]  = powerpc64
<fabbione> source that array
<fabbione> and you are done with an export
<fabbione> clearly the array can be built in a clever way
<fabbione> to handle more things
<svenl> ok.
<svenl> so you loose the subarch/flavour distinction, and have only two levels ?
<svenl> you could build multiple flavours for a given subarch specific patch. And notice that i didn't mention a arch-specific patch, but an subarch specific one.
<fabbione> svenl: i think we are using 2 different meanings for subarch/flavour
<fabbione> because for me flavours are 386 686 k7
<fabbione> or power3 power4 powerpc
<fabbione> what are flavours for you?
<fabbione> and what is subarch for you?
<fabbione> (just that we can talk at the same level of terms)
<infinity> Flavours are turning features on or off ina subarch.
<infinity> Like, -xfs kernels in the good ol' days.
<svenl> fabbione: i have a concept where there are three levels.
<svenl> fabbione: there is the arch, and we all know what those are.
<fabbione> yeah
<svenl> fabbione: then there are the subarches, which i myself define as those who need incompatible patch sets.
<svenl> fabbione: example of those on powerpc (2.4) are nubus, apus and main powerpc.
<fabbione> make an example
<fabbione> ok
<svenl> fabbione: this is a prerequisite for misp i hear from ths.
<svenl> fabbione: the subarches generate the main kernel-header package (may dissapear though in favour of a flavour one), and the subarch specific kernel-patch package.
<svenl> fabbione: then flavours are individual config options inside an arch/subarch.
<svenl> the subarch level could be dropped, as happens on x86.
<svenl> altough you may consider that 64bit and 32bit are two subarches of the x86 arch.
<fabbione> ok we are on the same level now...
<fabbione> i think
<fabbione> there are several things that need to be addressed
<fabbione> clearly an array can do
<svenl> yep.
<fabbione> given that you build images from what you have in config/
<fabbione> each of these config files have a unique name
<svenl> you could simply have a subdir in config.
<fabbione> and they can identify all the info you need
<fabbione> there is no need
<fabbione> that's what i mean
<svenl> how is the ubuntu config layout ? 
<svenl> a single level ? 
<svenl> or a per arch sublevel ? 
<fabbione> debian/config/$arch/$configfile
<fabbione> per arch
<fabbione> but config names are unique
<fabbione> so there is no need for us to stick the $arch in the array
<svenl> ok.
<fabbione> and that somehow eliminates one level of complexity
<svenl> how do you handle debian/config/powerpc/32 and debian/config/x86/32 or whatever ?
<fabbione> now.. to apply my array to your view
<fabbione> there is no name duplication
<fabbione> you cannot find 32 in x86 AND ppc
<fabbione> for your example
<svenl> fabbione: this will break infinity's naming proposal.
<fabbione> svenl: right.. but Kamion already killed it anyway :)
<svenl> fabbione: huh, i did miss that.
<fabbione> it was on u-d
<fabbione> anyway
<fabbione> the point is
<fabbione> once you can get a unique name for each config file
<svenl> ok.
<fabbione> the array can carry all the info you need
<fabbione> that can be ARCH=ppc64
<fabbione> or patch list to apply
<fabbione> or whatever
<fabbione> it doesn't matter because the name is unique
<fabbione> so arch[pseries-smp] =ppc64
<fabbione> will tell me everything i need
<fabbione> or
<fabbione> patchlist[foo] =00list-1.2.21.foo.bar
<fabbione> or whatever
<fabbione> but you get the idea
<svenl> indeed.
<svenl> so we are back to powerpc, pseries, iseries ? 
<fabbione> infinity: what did you agree with Kamion?
<svenl> fabbione: but i would drop the -smp bit.
<svenl> :)
<JaneW> fabbione: no new kernels yet?
<fabbione> JaneW: nope.. working on them
<chmj> JaneW, I surppose you have a name already 
<JaneW> fabbione: can I take the 'affects kernel' column out of the Breezy Goals wiki page, mdz feels it doe not have enough general interest or relevance...
<JaneW> chmj: of course ;)
<fabbione> JaneW: well the point is that a bunch of bofs ended with "we need this in the kernel"
<fabbione> if the people that will implement stuff are going to tell me in a decent time, i am ok with removal
<fabbione> otherwise i would rather have all of them to update that field
<JaneW> fabbione: ok lets leave it for now, once the field is filled will you save to a speadsheet? Then we can remove, allowing us space for more info.
<fabbione> works for me
<thom> go cogito; it's your birthday
<thom> aka, ftbfs on amd64
<fabbione> fix it :)
<fabbione> i think i had to build it with gcc-3.3
<fabbione> i can't remember tbh
<thom> ah, just scary signedness warnings; error was just masked a bit
<thom> built ok with gcc 4.0 in the end
<fabbione> eheh
<thom> (and i just uploaded to breezy ;-) )
<fabbione> nice
<thom> oh. should i be merging skge onto kernel-debian--pre1,2--2.6.11.92 or kernel-debian--mainline-2,6,11,92-1,1--0 ?
<fabbione> pre1,2
<fabbione> mainline are basically tags
<thom> okidoke
* fabbione -> foods
<thom> fabbione: ok, committed
<fabbione> cool
* fabbione updates
<pitti> Hey
<fabbione> i am here, but i am eating
<fabbione> so slow answers
<pitti> fabbione: enjoy your meal
* fabbione shows the "changelog entry clue bat" to thom
* chmj -> food 
<thom> fabbione: hrm?
* fabbione grins
<thom> oh, you want - add externel-driver-net-skge.dpatch ?
<fabbione> thom: don't worry.. i am changing the bits to my standard
<fabbione> so you can see them without getting crazy
<fabbione> from where did you download the driver?
<thom> http://developer.osdl.org/shemminger/skge/
<fabbione> oh you didn't get the one from sysconnect?
<fabbione> that's why it was so small
<fabbione> and probably buggy
<thom> eh?
<thom> skge != sk98lin update
<fabbione> yes
<fabbione> but there is the driver done by sysconnect
<fabbione> that is the one supposed to work :)
<thom> yes, that's sk98lin
<fabbione> oh ok
<fabbione> i tought you wanted to update sk98lin
<thom> it's big, bloaty and nasty
* fabbione understands now
<thom> if it's really broken we can back it out and run away later, but let's see :-)
<thom> i think stephen runs ubuntu anyway :-)
<fabbione> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
<fabbione> WTF IS WRONG NOW
<pitti> mind the last words of the petunia bowl
<fabbione> thom are you in the middle of a commit?
<thom> nope
<fabbione> hmm i think i know
<fabbione> thom: what is your umask on roockery?
<pitti> ah, that one :-/
<thom> default, blah
<thom> fixed
<fabbione>    4 -r--r--r--    1 thom     warthogs      125 May 12 11:16 .listing
<thom> (and i've fixed the rev lock, too)
<thom> fixed that, too
<fabbione> no it's will 444
<fabbione> fabbione@rookery:/home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.92/patch-9$ 
<thom> -rw-rw-r--    1 thom     warthogs       89 May 12 11:16 .listing
<fabbione> it still shows as 444 here!
<thom> the .listing in the patch dir doesn't matter
<thom> they're all 444
<fabbione> oh right
<thom> anyway, i've fixed the revlock, which is the pertinent point
<thom> the directory .listing one i've fixed
<fabbione> sftp status: Permission denied
<fabbione> and now all the archive is fucked
<fabbione> FUCK
<thom> status on which dir?
<thom> tree, rather?
<fabbione> pre1,2 patch-9
<fabbione> it started moving shit around during the commit
<fabbione> than i got the sftp error
<fabbione> BUM
<fabbione> so now we have a patch-9 without revision lock
<pitti> you can create one manually
<pitti> baz lock-revision <lastrevision> doesn't work?
<thom> baz lock-revision  kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.92--patch-9
<thom> lock-revision: error locking revision kernel-team@ubuntu.com--2005/kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.92--patch-10 -- internal error in archive-pfs.c(pfs_lock_revision)
<pitti> thom: is there a ++revision-lock-held-by-crack in the base directory (that with all the patch-* dirs)?
<fabbione> hold on guys
* thom holds
<fabbione> ok fixed
<thom> what did you do?
<fabbione> well i removed the bad lock
<fabbione> and inside the patch dir
<fabbione> mkdir -p ++revision-lock/+contents
<fabbione> i missed +contents at the first attempt
<thom> arh
<fabbione> arch is insane
<thom> yes
<pitti> baz should just get "baz unfuck-archive"
<thom> i've fixed my umask
<Lathiat> heh
<fabbione> baz commit -s'DIE YOU MOTHERFUCKER!'
<fabbione> it did work...
<fabbione> thom: you can merge from it now
<fabbione> there are basically 3 changes
<fabbione> a more detailes log
<fabbione> an entry in debian/external-drivers to keep track of what we add from wheree
<fabbione> and the patch naming is like:
<fabbione> <path>-<to>-<dir>_<file>.dpatch in your case
<fabbione> horms:
<fabbione> <path>-<to>-<dir>-<file>_<fix-this-or-that>.dpatch
<fabbione> meh
<fabbione> s/horms:/or
<fabbione> ok now.. let's talk about more serious stuff
<fabbione> pitti is here because we have a bunch of public security issues to deal with
<fabbione> elmo is going tomorrow to the DC to play rebootorama
* chmj stops eating 
<fabbione> so we should try to give him at least a set of patches
<fabbione> and start working on both warty and hoary kernels
<fabbione> chmj: what is your email?
<chmj> charles@ubuntu.com 
<chmj> @canonical.com 
<chmj> @rootcore.co.za
<fabbione> one is enough
<chmj> preference order 
<chmj> :-)
<fabbione> you both got mail :)
* pitti syncs mail
<fabbione> pitti: not you..
<fabbione> i did forward your mail :)
<mvirkkil> What kernel has the holliwood+/dxr3 module?
<fabbione> mvirkkil: 2.6.12 version 2.6.11.92-1,1
<mvirkkil> fabbione: thanks
<fabbione> np
<fabbione> so the first thing is to collect all the patches from the differnt trees
<fabbione> chmj: did you install git?
<fabbione> or cogito?
<chmj> cogito 
<fabbione> ok
<fabbione> chmj: the few patches that are missing, are in the gregkh tree
<fabbione> stable-queue.git
<fabbione> please start collecting them
<chmj> ok 
<fabbione> thom: do you want to start looking at warty and i will start looking at hoary?
<fabbione> with the patches that we already have
<thom> ok
<fabbione> pitti: mind to confirm with elmo what version of the kernel he needs?
<pitti> sure
<fabbione> if we can skip one distro for such a short time, it will be better
<fabbione> thom: warty is not in baz..
<fabbione> so it's freestyle :-)
<thom> yeah, i guessed
<fabbione> ehhe
<thom> fun fun
* thom builds a quick warty chroot
<pitti> fabbione: hoary kernel is priority for elmo, he does not have warty any mroe
<pitti> more, even
<fabbione> ok
<fabbione> perfect
<fabbione> baz is still munging on the tree....
<fabbione> i have the feeling that the first vulnerability will change the ABI
* fabbione fires up some heavy music
* thom goes to get tea
<zul> which group?
<zul> hey btw
<fabbione> metallica :)
<zul> old or new...
<fabbione> marylin manson is for the build orgy
<fabbione> St. Anger
<fabbione> new
<fabbione> but old-style
<zul> meh...i like old..
<fabbione> i like old too
<zul> ok you can merge from me if you want
<fabbione> zul: later or tomorrow.. we need to do some security today :)
<zul> cool...
<fabbione> zul: did you already merge from me?=
<zul> i just did
<fabbione> ok
<zul> now i have conflicts :(
<fabbione> no! really?
<fabbione> :)
<zul> bitch
* fabbione turns on CONFIG_BITCH=y
<fabbione> pitti: do you confirm that i only have one missing CAN from hoary changelog?
<pitti> CAN-2005-0977, yes
<fabbione> ok
<fabbione> added..
<pitti> fabbione: btw, are the git patches web-published somewhere? so that one can refer to them with an URL?
<fabbione> pitti: did you see the mail from XU?
<fabbione> pitti: yes.. kernel.org/git/
<pitti> cool
<pitti> no, I didn't
<fabbione> it just arrived here
<pitti> fabbione: ah, I saw
<pitti> well, do you want to do the warty kernels now?
<fabbione> pitti: i am not sure what is the situation with Xu
<fabbione> pitti: i had say to wait for mdz
<pitti> fabbione: me neither, mdz couldn't speak to him, and me neither
<fabbione> thom is already looking at it
<fabbione> i did speak with Xu, for 40 minutes
<fabbione> than he vanished in thin air
<thom> so i should continue, or is xu doing it?
<fabbione> thom: please keep doing it
<thom> i take it there's no way to check abi for warty kernels?
<fabbione> thom: not easily
<fabbione> but since we are going to apply the same patchsets, i am confident that if it doesn't break for me, it won't for you
<thom> ok
<fabbione> otherwise see how it is done in hoary
<thom> i'll just blame you for everything; it'll be great
<fabbione> you will need to rebuild the warty kernel to get the current ABI file
<fabbione> and build the new one to compare
<thom> right
<thom> building the abi stuff now
* thom installs ccache first ;-)
<fabbione> tsk.. you have an amd64!
<fabbione> chmj: how is it going to find the patches?
<thom> fabbione: the kernel still takes ages :P
<fabbione> thom: not on concordia dude...
* Mithrandir pats his fx53.
<thom> heh
<thom> concordia is a slightly different beast to my poor amd64 3000+
<Mithrandir> we're getting some 275s for hardware.no now.  That'll be nice.
<fabbione> we will need to test build on ppc/i386
<fabbione> oh poor..
* fabbione doesn't have amd64
<Mithrandir> (dualcore 250s)
<thom> fabbione: sure; but for the purposes of this i can test quite happily on just amd64
<thom> Mithrandir: shurrup
<Mithrandir> :)
<fabbione> Mithrandir: send a few in this direction :)
<thom> Mithrandir: seems they're not gonna be released to the public till Q4 :/
<Mithrandir> fabbione: we're talking directly with AMD to get them, since they're totally unavailable still.
<fabbione> thom: the reason for that might be related to the next undisclosed advisory :)
<fabbione> that should actually happen in hmmm 1 hour and 52 minutes
<thom> fabbione: doh
<fabbione> pitti: do you still confirm?
<thom> guess i'll get firefox 1.0.4 built while this rumbles on
<pitti> fabbione: well, there is no patch whatsoever for the issue that is disclosed today
<fabbione> pitti: ok..
<fabbione> FUN
<Mithrandir> is there any patch for the elf parser bug yet?
<fabbione> Mithrandir: can?
<fabbione> Paul Starzetz found an integer overflow in the ELF binary format
<fabbione> this one?
<Mithrandir> CAN-2005-1263
<fabbione> yes
<fabbione> dpatch-edit-patch: * Applying current stolen-from-head_CAN-2005-1263.dpatch for editing.
<Mithrandir> nice
<chmj> fabbione: I still have to learn git properlly, I'm currently doing some CXX transition stuff 
<fabbione> exaclty
<fabbione> ops
<fabbione> chmj: we need the patch asap.. can you do it right away?
<fabbione> otherwise i will
<chmj> fabbione: I'm not properly clued up yet, I think you should for now 
<chmj> provided you show me how 
<fabbione> chmj: ok
<fabbione> pitti: there is also a scsi tape security fix in 2.6.11.x
<fabbione> do you know anything about it?
<pitti> uh, no?
<fabbione> i found the patch for the keyboard
<fabbione> i am searching for the other one
<fabbione> ah here it is
<fabbione> thom: patches are on the way to you
<thom> ta
<fabbione> i need to teach this kernel fuckers on how to write a changelog and use a proper patch name
<thom> fabbione: what naming scheme do you use for security patches?
<fabbione> on warty i have none...
<fabbione> for hoary/breezy is stolen-from-head_CAN-*
<fabbione> or something sensible that matches the fix and the proper CAN entry in the changelog
<thom> nod
<fabbione> breezy actually is sth-*
<fabbione> sfh-*
<fabbione> well you got it
<thom> ok, my disk io is totally rammed, i'm going for lunch
<thom> heh, yup
<fabbione> ahha
<fabbione> buy more ram :)
<thom> firefox and kernel building at once
<fabbione> you crazy...
<fabbione> or buy more amd64's
<fabbione> distcc the kernel
<thom> heh
<fabbione> and firefox on local
<thom> more ram is next on my list
<Mithrandir> I'd go for the "buy more amd64s", just on general terms.
<fabbione> Mithrandir: we are not all rich as you are :)
<Mithrandir> fabbione: I just have my priorities right. :)
<fabbione> you will understand after...
<fabbione> ..after you will get married i mean
* Mithrandir wonders when the X2 will be available at a non-cutthroat price.
<fabbione> X2 ?
<Mithrandir> dualcore amd64
<fabbione> ah ok
<thom>  1  1   8124  84284   4284 227340    1    1   472   793  473   258 25 10 59  6
<thom> definitely lunch time
<thom> (that's vmstat)
<svenl> Mithrandir: 2006 i guess.
<Mithrandir> svenl: given that we had one for test last weekend, I doubt it.
* svenl wonders when the dual core G5 will be available :)
<Mithrandir> 2010 :P
<svenl> Mithrandir: "at a non-cutthroat price:
<fabbione> never...
<Mithrandir> well, 750E is the current price they're talking about ATM.
<svenl> Mithrandir: Mithrandir i read that massification will be during 2006, so i guess a year from now.
<svenl> Mithrandir: but then intel's dual core is ways cheaper, so ...
<svenl> Mithrandir: that said, dual core power4 and beyond are available since a couple years, so i think the dual core G5 will be available this year yet.
<Mithrandir> svenl: well, Intel doesn't _have_ a dual core yet.  At least none I've seen.  And their 64 bit CPUs suck royally compared to AMD's.
<thom> Mithrandir: the current top of line p4 EEs are dual core i thought
<svenl> Mithrandir: but they start at 250$, or so the review says, while amd's base offering starts at 550$, but you are right.
<Mithrandir> hm, they are?
<thom> could well be wrong though
<svenl> Mithrandir: i read a review about them yesterday somewhere, and i think so.
<svenl> Mithrandir: they where saying that intel dual head didn't give such a speed advantage, because they already ate their smp bread with HT.
<Mithrandir> hm, you're actually right
<Mithrandir> apart from the fact that nobody is actually able to sell you one ATM.
* svenl wanted to buy a dual power5 2u server recently :)
<Mithrandir> thom: yup, looks like it, but I'd rather have a opteron 265 than a P4 EE 840 :)
<svenl> Mithrandir: is it true that the X2 will top out at >130W or something such ? 
<Mithrandir> we had a full system with the top-of-the-line X2 and it drew 168W.
<Mithrandir> (1G memory, Radeon 9800 pro/x700 single hard drive)
<thom> Mithrandir: definitely
<Mithrandir> thom: though, if I got a P4 EE I could probably get rid of my stove and just use the cooler for the CPU instead.
<thom> heh
<fabbione> thom: apparently there are no ABI changes
<thom> score
<fabbione> but the i386 chroot on concordia hates me
<fabbione> there must be some x86_64 leaking somewhere
<thom> you did "linux32 dchroot ...", right? :-)
<fabbione> thom: i hate you
<thom> you hate me because i'm right? :-)
<fabbione> because i didn't know!
<fabbione> amd64 is stupid
<thom> heh
<fabbione> that's because nobody have sent me one
<fabbione> see..
* fabbione is a poor kernel developer with no hw
<zul> shesh you have more hardware than i do
<fabbione> than you must suck even more than i do
<zul> yes i think you  know that already
<fabbione> eheh
<chmj> heh
<fabbione> thom: why did you upload cogito 0.8 ?????
<fabbione> there 1.0 out
<fabbione> or at least 0.9
<thom> really? ber
<thom> i'll update it soon then
<fabbione> thom: www.kernel.org/git :)
<zul> i just love the log for patch-10 ;)
<fabbione> yeah
<dilinger> speaking of cogito
<dilinger> is there a way to diff changesets or files?
<dilinger> or see your last few commits?
<fabbione> diff changesets?
<fabbione> you mean to get a patch from a changeset?
<dilinger> right
<dilinger> in baz speak, i want to baz diff base-0 patch-1
<dilinger> or do the same but for a single file (which i'm not sure is possible in baz)
<dilinger> or baz logs -s
<dilinger> s/or/and/
<dilinger> i was playing around w/ cogito yesterday, but didn't see any way to do those
<dilinger> but i haven't looked at the newly announced packages, which apparently include documentation
<thom> there is not a lot of docs in 0.10
<fabbione> dilinger: i use cg-log to get the log history
<fabbione> and cg-mkpatch -r $commit_num_from_cg-log 
<fabbione> to get the patch
<zul> im out of here for a bit...back later
<dilinger> fabbione: neat, thanks
<fabbione> dilinger: what is our use, we don't really need more than that :)
<dilinger> fabbione: i want to update my bitkeeper helper scripts to use cogito (or git, if cogito doesn't provide the functionality)
<fabbione> eheh
<fabbione> lamont: you won't believe it.. i am still doing the checkout for linux-ipv6
<fabbione> if i did travel to the server, pluged a disk, copy and fly back, i would have been faster
<lamont> fabbione: wth??
<fabbione> it's SLOOOOOW
<lamont> I originally parsed that as itanglish for 'investigating' - was wondering what was so complicated...  this makes much more sense, given you, etc, etc...  but holy hell...
<thom> right, so the abi check stuff seems to work correctly with the warty build system, so that's good
<fabbione> did you port the abi checker to the warty kernel?
<thom> i think so :-)
<thom> i'll find out when i finish with dpatch and run it again
<fabbione> ehehhee
<fabbione> i am not 10000% sure mdz will like to see that in warty...
<fabbione> but we all know that baz sometimes merges wrong bits and pieces...
<fabbione> ok i am off
<thom> well, it's only like 10 lines of shell; i'll try it on all arches and see
<thom> ciao
<fabbione> amd64/ppc/i386 hoary is build
<fabbione> elmo is going to test it tomorrow at the DC
<fabbione> and we are good to go
<pitti> thom: would be cool, though :-) I mean, it doesn't actually change any source code, does it?
<fabbione> cya either later or tomorrow
<pitti> see you fabbione, thanks so far
<fabbione> pitti: nope.. not a single line
<fabbione> it's all in the build system
<thom> no, it changes no source
<pitti> yeah, it's more or less only an ultra-clever grep over the sources, isn't it?
<thom> yep
<zul> meh
* dilinger supresses the urge to vomit
<dilinger> i just discovered we're using reiserfs on a few machines here
<thom> ewww
<thom> have the responsible parties been slapped
<thom> ?
<dilinger> i've only been here less than 2 weeks, i'm not allowed to slap people for at least another few weeks
<lamont> dilinger: but btrees are _KEWL_ doncha know...
<lamont> or are those production machines?
<zul> dilinger: the probably didnt know better....
<dilinger> lamont: they're production
<zul> ok now you can shoot them
* thom fucking hopes that ccache is gonna do it's thing
<dilinger> aw
<dilinger> no search love on kernel.org/git :/
* thom dies of old age whilst the warty kernel builds patchsets
<zul> heh
<thom> huh. This Morn' Omina is great hacking music
* dilinger discovers cg-log -c and chuckles.  awesome.
* thom continues to die of old age (realised i was trying to build a warty kernel on breezy *sigh* )
<dilinger> thom: a watched kernel never compiles.  something i learned very early on :)
<dilinger> i usually kick off a build before bed or something
<thom> ber
<zul> i have naps
<thom> i watched blade trinity
<zul> meh
#ubuntu-kernel 2005-05-21
<Lathiat> hey horms 
<horms> hi Lathiat
<fabbione> morning
<fabbione> dilinger: cg-log -c is so cool :)
<dilinger> geghehe
<ercxy> how one can increase stack size for a process ? is it need to be done thorugh kernel compilation?
<fabbione> ercxy: it depends how big you want the stack size
<fabbione> also.. check the user enviromnet with ulimit
<ercxy> not more than 64Mb
<ercxy> :~$ ulimit
<ercxy> unlimited
<fabbione> the stack is big enough for that
<fabbione> the "unlimited" kernel limit is 2GB on i386
<fabbione> what is the problem you have exactly?
<ercxy> i wrote a code which does some recursive function calls
<fabbione> and?
<ercxy> it works without problem when the matrix size is smaller than 300
<ercxy> if I increase matrix size above 300 
<ercxy> it gets killed immeditaely 
<fabbione> killed how?
<ercxy> number of recursive fucntion calls are increases with matrix size
<ercxy> segfault
<fabbione> is there anything in dmesg after the segfault?
<fabbione> like a kernel message telling you that it has been killed for some reasons?
<ercxy> not checked .. iwiil doit right now
<ercxy> i checked with valgrind
<fabbione> that's mostlikely a bug in your code
<fabbione> either it's leaking memory
<fabbione> or you are trying to access a wrong segment of ram
<ercxy> i don't do dynamic memory allocation.. is it still possible to have memory leaks
<ercxy> i mean i defined one global array and do all stuff on it
<fabbione> are you calculating the amount of ram properly?
<fabbione> did you check with a strace where the code dies?
<ercxy> yes.. i checkhed ram usage from "top".. it is never reached above %50
<fabbione> did you compile it with -g and run gdb on it?
<fabbione> top is not fast enough
<ercxy> no did no tuse strace
<ercxy> tried gdb and vlagrind
<ercxy> the program stops random places
<fabbione> it really depends what you are doing
<fabbione> i seriously doubt it is a kernel problem
<ercxy> ok .. it is abt confuding for me 
<ercxy> as far as i know
<fabbione> ?
<ercxy> there is one limit set for kernel 
<ercxy> like 64mb
<fabbione> nope...
<ercxy> and there is default size 8mb
<fabbione> that's something you control via ulimit
<ercxy> for a process
<fabbione> stack size            (kbytes, -s) 8192
<fabbione> ulimit -a
<fabbione> set that one
<ercxy> do i need to be root
<fabbione> no
<fabbione> it's per user
<ercxy> ok thanks trying 
<ercxy> ulimit -a  tells me it                 =     stack size            (kbytes, -s) 8192
<ercxy> but segfaults
<fabbione> yes.. increase that value
<fabbione> you can change it
<ercxy> how
<fabbione> man ulimit
<Lathiat> you cant increase it if your a user but
<ercxy> i tried that,
<ercxy> it gave error
<Lathiat> You can only decrease it (because obviously if it was set by a login profile you coudl just override it if you want up)
<ercxy> standard input>:15: realpath on `bash.1' failed: No such file or directory
<ercxy> BASH_BUILTINS(1)                                              BASH_BUILTINS(1)
<ercxy> i found man page on google 
<ercxy> reading
<fabbione> it's somewhere in /etc that you can set the system default
<fabbione> in any case this is offtopic here
<ercxy> ok.. thanks.. where should i ask this
<fabbione> #ubuntu
<ercxy> i will try there
<fabbione> dpatch-edit-patch: * Applying current external_usagi.dpatch for editing.
<fabbione> http://www.big-boys.com/pictures/picture1009.html
<fabbione> lol
<fabbione> Mithrandir, smurfix: ping?
<smurfix> pong
<smurfix> , even
<Mithrandir> fabbione: pong
<fabbione> guys what is the status with Xen & benno?
<fabbione> if we need to break the kernel, it needs to be asap
<Mithrandir> I haven't gotten around to mailing him; been looking for him on IRC for a while
<Mithrandir> I'm inclined to just go ahead with xen for the time being.
<Mithrandir> but didn't we agree not to break the normal kernel for it?
<fabbione> Mithrandir: yes, for the beginning, but if it needs to be a standard feature we can't wait too long
<Mithrandir> sure
<smurfix> fabbione: Any news on the xen/L4 virtualization stuff you explored in Sydney? (I can't remember that project's name at the moment :-/ )
<fabbione> smurfix: that's the project you 2 are supposed to track :)
<Mithrandir> smurfix: afterburning.  That's what benno is doing, but he seems to have disappeared off the face of the earth.
<smurfix> ah, sorry, I disassociated that name and that project...
<fabbione> http://www.voresoel.dk/
<fabbione> AHAHAH open source beer
<fabbione> (there is an english link too)
<thom> fabbione: dude, i need to throw the warty stuff back at you. it's all patched and builds fine on amd64, but not had chance to test on ppc/x86 and need to go help elmo
<fabbione> thom: ok
<zul> i have an interview on monday
<zul> hey btw
<TheMuso> hey zul.
<zul> hey TheMuso 
<zul> bbl...have to go bone up on w2k
<jbailey> fabbione: Could not connect to trider-g7.fabbione.net: No route to host.
<jbailey> fabbione: Is that a problem on my end or yours? =)
<zul> bleah..
#ubuntu-kernel 2005-05-22
<lamont> moof
<zul> hey lamont how goes it?
<lamont> pretty well.
<zul> good
<zul> hmmm....er...no...https://bugzilla.ubuntu.com/show_bug.cgi?id=10093
<zul> dilinger: are you awake?
<lamont> gnight all
* infinity stares at fabbione.
<infinity> fabbione : If you point jade at a DTD it can't read (one on an inaccessible network), then refer to elements defined in that DTD, how do you expect it to work?
<infinity> fabbione : (that would be bug #10567)
<infinity> fabbione : The solution is to include the DTD in the package, and point to the local copy, not to make openjade psychic.
#ubuntu-kernel 2006-05-15
<BenC> yeah, I've thought about that too
<zul> there was a patch like that by dave jones but i dont think it got anywhere
<lifeless> is sourcepackage the right granularity for you ? I think it is 
<BenC> hopefully for edgy we can get the failsafe kernel with kexec :)
<BenC> lifeless: yeah
<zul> maybe add something like this to the wiki http://www.parisc-linux.org/faq/kernelbug-howto.html
<mdz> ok
<mdz> zul: good point, there are surely existing resources we can draw from
<mdz> where's the document in our wiki?
<zul> ill try to merge a couple of resources that ill look for
<BenC> dholbach did it, so check under his bug stuff
<BenC> another thing we need to do is coordinate better with kernel.org bugzilla
<zul> agree
<BenC> the more of our bugs that we can link with there, the better chance someone else will fix it
<lifeless> https://wiki.ubuntu.com/DebuggingKernelProblems <- ??
<lifeless> is that the page ?
<mdz> it's not linked from https://wiki.ubuntu.com/Bugs/Teams
<mdz> which is where I looked
<lifeless> if so, its a little vestigial
<BenC> yep
<sfllaw> Apparently, davej looks through Malone every once in a while...
<BenC> it is pretty thing
<zul> ill try to add some more information 
<BenC> thin
<mdz> BenC: between you and sfllaw, make sure we have a solid "how to make sure a kernel bug is useful to the kernel team" document
<BenC> needs stuff about oops capturing and such
<lifeless> bug 43893
<sfllaw> mdz: I think it's linked from DebuggingProcedures
<lifeless> ah, no ubugtu
<lifeless> https://launchpad.net/products/launchpad/+bug/43893
<sfllaw> BenC: If you could add stuff to DebuggingKernelProblems, that would be ace.
<sfllaw> Even if it's just point form.
<sfllaw> I can expand on it.
<mdz> sfllaw: I think it should be possible to make the same document useflu to reporters and the bugsquad
<mdz> sfllaw: I suggest that you and BenC have a phone call later today and hash this stuff out over a higher-bandwidth link
<mdz> lifeless: maybe you'd be interested in the conf call as well?
<lifeless> mdz: yep
<mdz> ok
<BenC> ok, but someone else will need to setup the conf call
<BenC> I can only do single line :)
<mdz> BenC: I'll see if I can dig up that info, unless sfllaw is set up for 3-way calling at home
<sfllaw> I'm not.
<lifeless> though given timezones,and three way difficulties ... my primary interest is to get a feel for the challenges you are running into
<sfllaw> I haven't even setup long distance yet.  ;)
<mdz> I have the passcode and will set it up for you
<mdz> what time?
<BenC> any time during work hours is good, I can do outside work hours given notice
<lifeless> anytime from now for the next 12 hours works
<mdz> sfllaw: how is nowish for you?
<zul> BenC: ill try to find some resources as well
<sfllaw> Nowish is good, as long as we have a direct meeting.
<mdz> BenC: is now close enough?
<sfllaw> I don't want to waffle and take up forever.
<mdz> sfllaw: what we want out of it is a plan to a) get the wiki page into shape as discussed, b) prepare an announcement explaining how to help (with URLs both to a custom report for the right set of bugs, and the instructions for what to do)
<BenC> now is fine
<mdz> BenC: do you have any documentation on the daily builds?
<mdz> the documentation could explain how to use those to isolate regressions
<BenC> not really
<BenC> other than an email that got sent out awhile back
<mdz> ok, I'm tracking down the PIN for the confcall system
<sfllaw> Give me five minutes, and I'll be ready for the phone call.
<mdz> do you all have the dialin info?
<BenC> not handy
<lifeless> same
<zul> http://mbligh.org/linuxdocs/Kernel
<zul> ok i have to head off to my parents
<mdz> I'll get that
<sfllaw> Back.
<sfllaw> I also have no idea what the dialin info is.
<mdz> lifeless,sfllaw,BenC: sent you email
<mdz> conference is in progress
<sfllaw> What's the PIN?
<lifeless> whats the code ?
<sfllaw> mdz: Ping?
<lifeless> mdz: we need a 'conference code'
<BenC> what is the code?
<mdz>  /msg
<lifeless> thanks
<lifeless> thanks mdz, that was good
<mdz> lifeless: sorry I couldn't join; just got off with mark
<mdz> and kiko has been waiting all day to talk
<lifeless> heh
<lifeless> sfllaw will be mailing us after he eats
<lifeless> with minutes
<lifeless> I still want to chat with you :)
<lifeless> can we make an appointment ?
<mdz> lifeless: sorry, didn't see your message
<mdz> lifeless: I have a few minutes now
<zul> heylo
<BenC> sweet, I just noticed that bcm43xx now supports signal strength and other stats in iwconfig
<BenC> so now my network status applet actually looks like a wireless status :)
<mjg59> BenC: Oh, yeah, that's a point. Any chance of pulling 43xx updates?
<BenC> yeah, I can do that
<mjg59> (And then reapplying the Mac stuff)
<mjg59> Uh, PCI-E stuff
<BenC> PCI-E and a few other things
<mjg59> I'm also wondering if we should modify it so it tries to load the firmware on modprobe, and gives -ENODEV otherwise
<mjg59> That would stop it showing up in the installer
<mjg59> BenC: I sent you a couple of patches (one for avoiding pci=assign-busses, one for Sony hotkey support)
<BenC> looks like it should be easy
<BenC> ah, almost forgot about the pci= one
<BenC> good thing is bcm43xx has a seperate function for loading the firmware from disk, and pushig it to the card
<BenC> mjg59: I'll update to latest code and implement that
<mjg59> BenC: Ta
<BenC> mjg59: Do we have any bug reports related to the yenta fix?
<mjg59> BenC: Nope
<mjg59> Oh, yes
<mjg59> elmo filed one yesterday
<BenC> 43881, got it
<BenC> note to self, it's bad to type a number in vim when not in insert mode, then enter insert mode, type the same number and exit insert mode
<BenC> especially a number like 43881
<BenC> badness
<BenC> latest bcm43xx doesn't seem to like my G4...doesn't even create an interface
<mjg59> BenC: Anything in dmesg?
<BenC> mjg59: "bcm43xx driver" and that's it :)
<mjg59> BenC: Suggests it's not binding to the PCI device
<BenC> or it's failing some test of the device
<BenC> the PCI id's are listed
<BenC> I'm going to add some printk's to see what's up
<mjg59> Hm. I'd expect output in that case
<BenC> I checked the source, it fails silently in a few cases :/
<mjg59> Oh, suck
<BenC> oh, and the firmware bit wont work, there's not enough information at init_one to do the actual load
<BenC> would require a lot of chip probing to get it right
<mjg59> Suck
<zul> hey
#ubuntu-kernel 2006-05-16
<lamont> so I'm using git-bisect to find this ia64 kernel annoyance... and the bisected place is FTBFS... how do I tweak it one version to the left or right?
<lamont> heh... RTFweb-page
<lamont> BenC: ping
* lamont would love to know where the debian/ directory went...
* lamont decides to just blame it on 64-bit isms in git
<lamont> master source tree to do the git bisect commands in, then rsync --delete it to the other machine to build and test.  simplicity in its finest
<zul> BenC: ping https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/41284
* #ubuntu-kernel  [freenode-info]  why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
<lamont> git bisect good
<lamont> Bisecting: 90 revisions left to test after this
<lamont> woot!
<lamont> otoh, make -j4 on the faster box is nice.
<lamont> and ccache is love
<lamont> cluster stuff, or acpi... now there's a trivial-seeming question
<lamont> 1.5% ccache miss rate.
<lamont> You already have a ELILO configuration in /etc/elilo.conf
<lamont> Install a boot block using the existing /etc/elilo.conf? [Yes]  
<lamont> grumble.  I thought we'd fixed that
<lamont> and git-bisect bad
<lamont> 18 minutes. not bad
* lamont gets to play with reverted reverted acpi patches
<lamont> oh joy
<lamont> BenC: any chance you're around?
* lamont rolls the dice again
<infinity> Keybuk: Still around?
<Keybuk> infinity: yup
<infinity> Keybuk: Does udev create tape devices?
<Keybuk> dunno, know anyone who's got one?
<infinity> (From #ubuntu-server):
<infinity> 19:22 < IRCsloth> anyone using an adaptec 29160 and a Seagate DDS4 drive?
<infinity> 19:23 < IRCsloth> in 2.4 based kernel distros without udev I get a /dev/st0 device but on hoary i
<infinity>                   see the device in dmesg but a /dev/ device doesn't get loaded.
<infinity> Err, "but on hoary"... Nevermind.
<Keybuk> get them to try a dapper CD
<infinity> Somehow I missed that bit.
<Keybuk> I assume it does
<Keybuk> I can't believe the kernel people would have driver-core'd scsi and missed of tapes
<Keybuk> I've got a rule in there to put them in the "tape" group too
<infinity> Does seem unlikely.
<Keybuk> SYSFS{type}=="1",                       RUN+="/sbin/modprobe -Qba st"
<Keybuk> yeah, I do that too
* Keybuk just checked
<lamont> neato.  4900 lines of diff -u, and the patch break in the middle of the two fails in a completely different manner.
<Keybuk>                 st_class_member =
<Keybuk>                         class_device_create(st_sysfs_class, NULL,
<Keybuk>                                             MKDEV(SCSI_TAPE_MAJOR,
<Keybuk>                                                   TAPE_MINOR(dev_num, mode, rew)),
<Keybuk>                                             &STp->device->sdev_gendev, "%s", name);
<Keybuk> looks ok to me
<infinity> Keybuk: Kay, cool.  Thanks.
<Keybuk> that's far too much research
<Keybuk> this SoC list is soul destroying
<lamont> Keybuk: udevplug shouldn't spew a series of visit_entry: error stat '/sys/devices/pci0000:a0:0000:a0:04.0/////////////////////////////re': No such file or directory
<lamont> right?
<lamont> I don't think I've ever seen "Begin: Waiting for the root file system... ..." before.
<Keybuk> lamont: no, it shouldn't do that :p
<Keybuk> that sounds like rr sysfs gone bye-bye
<Keybuk> lamont: initramfs-tools does that if you enter mountroot() without the root file system device existing
<Keybuk> it'll wait up to three minutes for it to show up, on the basis you may have a slow scsi/usb device that hasn't caught up yet
<lamont> yeah... so now I have a diff to stare at.
<lamont> I just wish it were shorter.
* lamont wonders if  drivers/acpi/tc1100-wmi.c actually gets used on ia64
<lamont> sadly, that's not part of the diff though
<lamont> but it does have an ia64-fatal bug
<lamont>   CC [M]   drivers/pci/hotplug/acpiphp_glue.o
<lamont> drivers/pci/hotplug/acpiphp_glue.c: In function ioapic_add:
<lamont> drivers/pci/hotplug/acpiphp_glue.c:633: warning: gsi_base may be used uninitialized in this function
<lamont> there's a candidate
<lamont>                 acpi_bus_generate_event(device, event, (u32) wmi->state);
<lamont> neato
<dapp-live-macmin> mjg59: around ?
<crimsun> dapp-live-macmin/g2: he's most likely asleep, as he's in the U.K.
<dapp-live-macmin> crimsun: thx
<dapp-live-macmin> crimsun: I guess the dapper livecd kernel only runs one processor, correct ?
<Keybuk> incorrect
<Keybuk> dapper kernels are SMP
<dapp-live-macmin> Keybuk: then it's a bug
<Keybuk> what is?
<dapp-live-macmin> or acpi only reports 1 processor for a duo
<Keybuk> pastebin /proc/cpuinfo
<dapp-live-macmin> http://pastebin.ca/54982
<Keybuk> and uname -a ?
<dapp-live-macmin> 2MB cache size ... yummy 
<infinity> LiveCD uses -386 doesn't it?
<dapp-live-macmin> nod
<infinity> Which is the only non-SMP kernel.
<Keybuk> ahh, I thought -386 was SMP as well now?
<infinity> (To support some sketchy old ISA drivers that aren't SMP-able, IIRC)
<dapp-live-macmin> uname -a
<dapp-live-macmin> Linux ubuntu 2.6.15-21-386 #1 PREEMPT Fri Apr 21 16:43:33 UTC 2006 i686 GNU/Linux
<Keybuk> yeah, infinity's right, that isn't an SMP kernel
<Keybuk> sucky
<dapp-live-macmin> Is there a different livecd ?
<infinity> Given the nasty hardware requirements of a livecd in general, I'd be all for taking a vote to change the livecd to -686, but that would be for Edgy.
<infinity> Now way we want to make that sort of change 3 weeks before dapper.
<dapp-live-macmin> or can I roll my own kernel and rebuild the livecd ?
<dapp-live-macmin> s/my/ubuntu's/
<infinity> dapp-live-macmin: Is it really important that the livecd use both cores?
<dapp-live-macmin> infinity: well actually I'm looking to have a macmini based ubuntu
<dapp-live-macmin> so I'll want that kernel for the install
<Keybuk> dapp-live-macmin: the fact the CD isn't bootable on a Mactel will hit you first ;)
<dapp-live-macmin> umm I'm booted on it now
<infinity> dapp-live-macmin: Anyhow, you could take the squashfs from the livecd, mount it, "cp -a" the contents to a directory, chroot into it, "apt-get --purge remove linux-image-2.6.15-21-386 && apt-get install linux-686", exit, and resquash the FS.
<Keybuk> oh, did someone make mkisofs support HFS+ thingy now?
<dapp-live-macmin> Keybuk: no, boot camp can boot to ISO CDs
<infinity> dapp-live-macmin: But what's on the livecd doesn't matter for the install.  You boot the livecd, install to the real system, install another kernel.
<Keybuk> oh, you boot-camped it
<Keybuk> that's cheating, anyway :)
<dapp-live-macmin> Keybuk: well for now
<dapp-live-macmin> dapper can't see the hfs fs
<dapp-live-macmin> I'm planning on having a dual Mac OSX/ Ubuntu environment anyway
<dapp-live-macmin> I think with refit, and lilo/elilo I might be able to install Dapper now
<dapp-live-macmin> and have refit default to ubuntu
<dapp-live-macmin> My pal did an install from the livecd and it trashed Mac OS
<dapp-live-macmin> it's confused about the real MBR
<Keybuk> elilo
<dapp-live-macmin> that issue needs to be worked out
<dapp-live-macmin> Keybuk: does elilo build with dapper ?
<infinity> Yes, it's in dapper.
<dapp-live-macmin> infinity: that's the binary right ?
<infinity> -EPARSE
<infinity> Of course the binaries are in dapper.  Doesn't make much sense to just ship the source. :)
<Keybuk> although, if we only shipped the source, we wouldn't need anyone to feed the buildd hamsters
<dapp-live-macmin> infinity: wel my question was does it build with dapper
<infinity> The hamsters are doing well today anyway.
<infinity> I gave them 3000 packages to eat, and they've not choked much.
* infinity finds some wood to knock on.
<infinity> dapp-live-macmin: Yes.  Does build and is built.
<Keybuk> the ia64 port kinda relies on it
<infinity> Keybuk: Well, to be fair, we had to hunt a few obscure bugs to make it stop breaking on i386/MacTel.
<infinity> But yes, we've been building it for ages on ia64, and it works fine.
<infinity> (And by "we", I mean mjg59, who did most of the hunting and irritating us on IRC until it worked)  :)
<Keybuk> he gave up before he finished though :)
<Keybuk> once all the difficult bits were done, he got bored
<infinity> Well, the only blocker is the hfs+ thing.
<Keybuk> yeah, and that's "trivial"
<infinity> If so, please fix it on Saturday in your copious spare time. :)
<dapp-live-macmin> Keybuk: great, so I'll play clean up
<Keybuk> heh, I did look at it actually
<Keybuk> and it's in my todo list if nobody beats me to it
<Keybuk> but haven't yet reached any spare time
<Keybuk> mostly just plodding through the Apple HFS+ spec and cargo-culting the existing HFS code in mkisofs to match
<infinity> I need new hardware.
<Keybuk> you do?
<Keybuk> what's wrong with the hardware you have?
<infinity> No ipw3945, no ATI X1xxx, no MacTel, I had nothing "obscure" for this release cycle to test on.
<Keybuk> heh
* Keybuk hugs his X2
<infinity> Last cycle, I was all about "new and broken" with my PCIe laptop, which is now old-hat. :)
<Keybuk> nothing particularly obscure, except nothing in Linux supports SLI
<infinity> nVidia SLI?
<Keybuk> aye
<infinity> The craptastic binary driver can do it, no?
<Keybuk> it claims to yes
<infinity> Its claims are false?
<Keybuk> I have to use that anyway, as the even-crapper source driver goes "is that an nVidia? doesn't look like one to me!"
<Keybuk> dunno
<Keybuk> glxgears -iagreethatiamanaadvark gives me 300000 FPS
<infinity> Ouch.  New PCI IDs, or are we programming the card wrong?
<Keybuk> so I guess that could be an indication that it works
<Keybuk> infinity: not sure
<Keybuk> they're pretty new cards
<Keybuk> 7800 GLX
<infinity> Could just be PCI IDs, then.  If you could test adding your IDs to nv, that would be awesome.
<Keybuk> could be supported now, but weren't earlier
<dapp-live-macmin> is dma for disks turned on in this kernel ?
<infinity> 7900 and some 7800 stuff were pretty shiny just recently.
<Keybuk> dapp-live-macmin: probably
<Keybuk> we turn dma on if it looks like it won't bring the world down in pieces around you
<Keybuk> infinity: it's sufficiently shiny that lspci just says "Unknown device"
<infinity> Oh, lord.  You wouldn't believe the number of users who think installing an X driver should change the PCI database.
<Keybuk> hmm, PCI id is listed in the nv driver now
<Keybuk> it might work
<Keybuk> I've got a reboot coming up for new kernel anyway, will try it then for kicks
<infinity> I've triaged SEVERAL bug reports that say something like "I installed fglrx, but lspci still says 'Unknown Device' for my video card, does that mean it doesn't work?"
<Keybuk> *giggle*
<Keybuk> yeah, it's amazing how down-trodden people look when you explain it's just a text file that somebody gets round to updating some time each century
* infinity nods.
<infinity> I guess it wouldn't hurt to have that text file have some sort of include functionality, and let upstreams ship updated ID/description pairs, but that's certainly not done now.
<Keybuk> I like how each PCIe card appears numbered as if it were an entire bus all to itself
<Keybuk> I also like how the PCIe subsystem is busted, and just numbers everything pcie00
* dapp-live-macmin likes how PCIe has BW
<infinity> They are a bus to themselves.
<Keybuk> 0000:01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0090 (rev a1)
<Keybuk> 0000:02:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0090 (rev a1)
<infinity> PCIe guarantees dedicated bandwidth, unlike PCI.
<Keybuk> . o O { one would have thought I'd've patched that by now to actually say the right card }
<Keybuk> but given it's a "standard" file, probably best just to leave it alone
<infinity> <shrug>... It'll be out of date a month after release anyway, so whatever.
<Keybuk> what's wrong with this picture? :)
<Keybuk> quest scott% ls /sys/bus/pci_express/devices
<Keybuk> pcie00@  pcie00@  pcie00@  pcie00@  pcie03@  pcie03@  pcie03@  pcie03@
<Keybuk> -- 
<infinity> The same thing that's wrong with mine? :)
<Keybuk> readlink /sys/bus/pci_express/devices/pcie00 ... which one?
<infinity> I just love how sysfs doesn't have to follow any of the usual rules of a sane filesystem.
<infinity> "Bah, duplicate filenames are FINE"
<fabbione> Keybuk: 
<Keybuk> it's _supposed_ to follow the usual rules
<Keybuk> the pci_express bus is just busted
<fabbione> i was almost close to point the sodomotron towards you this morning when i saw "Waiting for nfs /path/to/nothing/real"...
<Keybuk> (in-kernel implementation that is)
<fabbione> ;)
<infinity> Anyhow, all my duplicate links all go to the same duplicate target, so it's harmless, just ugly.
<Keybuk> infinity: that's a bug too
<Keybuk> oh grr @ paste
<Keybuk> /sys/devices/pci0000:00/0000:00:0e.0/pcie03
<Keybuk> /sys/devices/pci0000:00/0000:00:0e.0/pcie00
<Keybuk> /sys/devices/pci0000:00/0000:00:0d.0/pcie03
<Keybuk> /sys/devices/pci0000:00/0000:00:0d.0/pcie00
<Keybuk> /sys/devices/pci0000:00/0000:00:0c.0/pcie03
<Keybuk> /sys/devices/pci0000:00/0000:00:0c.0/pcie00
<Keybuk> /sys/devices/pci0000:00/0000:00:0b.0/pcie03
<Keybuk> /sys/devices/pci0000:00/0000:00:0b.0/pcie00
<Keybuk> -- 
<Keybuk> supposed to be different devices
<Keybuk> fabbione: I could do with a go on the sodomotron, bf isn't around for a couple of weeks :-/
<Keybuk> what was it?
<fabbione> Keybuk: ehhe stop fixing bugs than :P
<Keybuk> fabbione: was it the "keybuk uploaded the debugging version of that script which happily looked inside comments" one? :)
<fabbione> Keybuk: yes...
<fabbione> Keybuk: it took a while to boot up ;)
<Keybuk> bah, it only waits 90s
<fabbione> cat /etc/fstab | grep ^# | wc -l
<fabbione> 34
<Keybuk> dude, wtf do you have in your fstab ?!
<fabbione> most of them are old nfs mount points to shared chroots
<fabbione> oh i am not that upset...
<Keybuk> aww
<[g2-macmini] > Keybuk: any idea how fast the GigE is on the mini duo ?
<Keybuk> [g2-macmini] : probably about 1,024Mb/s
<[g2-macmini] > Keybuk: you think it's do line rate ?
<Keybuk> I've got no idea
<Keybuk> the answer appears to be in the question though
<Keybuk> "how fast is this 300 baud modem?"  ...  "300 baud"
<Keybuk> "how fast is this GigE network card?"  ...  "gigabit"
<[g2-macmini] > my AMD64 does 400+Mbs and which is limited by the SATA disk
<[g2-macmini] > it'll do 600+ over the wire from memory
<[g2-macmini] > and 2.4Gbs through the IP stack
<[g2-macmini] > real numbers measured
<Keybuk> SATA should be faster than that
<Keybuk> isn't it 300MB/s ?
<[g2-macmini] > no hdparm returns around 60MBs
<[g2-macmini] > and I get about 57-58MBs over the wire
<fabbione> Keybuk: well the speed of the bus != speed of the disk :)
<[g2-macmini] > so it's disk limited
<Keybuk> fabbione: true
<[g2-macmini] > when I pull from memory it goes 600+
<fabbione> Keybuk: when i pull from my SAN i get around 200MB/sec from the disks
<fabbione> but then i hit the switch 2Gb bottle neck
<[g2-macmini] > I haven't RAIDed the disk as 28 seconds for a Gigabyte transfer was fast enough
<Keybuk>  Timing cached reads:   3660 MB in  2.00 seconds = 1829.36 MB/sec
<Keybuk> 8GB/s should be more than enough to saturate a GigE
<[g2-macmini] > fabbione: you should be able to do 256MBs on the 2G no ?
<[g2-macmini] > 128MB will saturate a GigE
<fabbione> [g2-macmini] : never heard of protocol overheads?
<Keybuk> hell, my laptop can saturate it's gige
<fabbione> when you start encapsulating scsi over fc-hba over raw fiber...
<[g2-macmini] > fabbione: yes I was talking relative not absolute
* [g2-macmini]  used to write NPU firmware
<fabbione> [g2-macmini] : raw = 2Gb..
<fabbione> once you get to the data i get around that
<[g2-macmini] > well nice chatting guys
<[g2-macmini] > time to reboot this mini and build elilo on another boxen
<[g2-macmini] > cheers all
<Keybuk> "build" ?
<Keybuk> is he a Gentoo person, do we think?
<crimsun> (no, he uses Debian, and he works with the openwrt guys. he's from my LUG.)
<lamont> BenC: btw, 7e856098daf7275030504b7f149f49e27010e887 or the one before it is the patch that broke ia64
<Keybuk> infinity: got a second?
<infinity> Depends.  Will my second be useful to you?
<Keybuk> all the blah-22-* in anastasia are due to an ABI change, right
<Keybuk> in the seeds they're still -21-*
<Keybuk> should those be updated now, or is there some reason they haven't?
<infinity> The seeds should be updated to 22, now that d-i has been.
<infinity> Apparently, someone forgot, assuming that someone else would do it. :)
<infinity> I can do the seeds now, if you'd like.
<Keybuk> I have the seeds open now
<Keybuk> was making other changes
<infinity> Kay.  Do everyone at once.
<Keybuk> yup
<infinity> (For this change, anyway)
<Keybuk> quest dapper-seeds% grep " * Kernel-Version" *
<Keybuk> installer: * Kernel-Version: 2.6.15-22-amd64-generic
<Keybuk> installer: * Kernel-Version: 2.6.15-22-hppa32 2.6.15-22-hppa64
<Keybuk> installer: * Kernel-Version: 2.6.15-22-386
<Keybuk> installer: * Kernel-Version: 2.6.15-22-itanium-smp
<Keybuk> installer: * Kernel-Version: 2.6.15-22-powerpc 2.6.15-22-powerpc64-smp
<Keybuk> installer: * Kernel-Version: 2.6.15-22-sparc64
<infinity> Right, so merge that to kubuntu/edubuntu/xubuntu, so we can all be happy about the CDs not being broken.
<Keybuk> this will cause a whole bunch of stuff to want to move to universe, right?
* infinity suspects this is the cause of lamont's earlier lament that his kernel didn't match his modules on a recent daily CD.
<Keybuk> how do you tend to merge?  just pull the lot?
<infinity> Keybuk: Should cause all of the -21- stuff to want to go to universe, but we just want to remove it anyway, since it's NBS.
<Keybuk> right
<infinity> Keybuk: I just merge the single revision.  I keep all the seeds sitting next to each other, so I can just do "bzr merge -r15..16 ../ubuntu/" in the other seeds.
<Keybuk> yeah, never changed the others before
<Keybuk> just copying and reverting them now
<Keybuk> ... I made a 1-line change, why does push take a metric week?
<lamont> sigh.  -g kernel machine checks
<Keybuk> . o O { I should be able to bind these checkouts now, right? :p }
<infinity> I'm mostly bzr illiterate, so I dunno.
<Keybuk> right, gonna try that reboot and nv driver
<lamont>   CC [M]   drivers/media/video/stradis.o
<lamont> drivers/net/skge.c:108:25: error: h/skversion.h: No such file or directory
<lamont>   CC [M]   drivers/media/video/cpia.o
<lamont> bad kernel
<fabbione> BenC: can you please pull from my archive before next upload?
<fabbione> changelog: add inotify syscalls to syscall_table.S for parisc
<zul> heylo
<fabbione> hi zulighno
<zul> heh...hey fabiomassimo
<zul> how is it going?
<fabbione> zul: as usual and you?
<zul> just winding stuff down at work
<zul> how is x going?
<fabbione> it's going... another day and it will be done (my side)
<zul> cool
<BenC> fabbione: yeah, pulling now
* BenC notices this morning he forgot about the distro meeting
<fabbione> BenC: thanks dude.. any ETA for the upload?
<BenC> hopefully over the weekend
<fabbione> ok
* fabbione is getting ready for holidays
<zul> staying home?
<zul> BenC: i dont think you got back to me last night about my noapic question 
<BenC> zul: "yes"
<zul> okie dokie
<fabbione> zul: nope...
<zul> or i didnt see the anwser
<fabbione> flying to italy for 4 days
<BenC> I think we are having a dmi blacklist issue with some IBM laptops though
<fabbione> and 2 days at home
<BenC> fabbione: have a relaxing time
<fabbione> BenC: i hope so.. i need it
<mjg59> IBM laptop dmi blacklist?
<BenC> I think there are some IBM laptops that are broken because some blacklist is too vague
<mjg59> BenC: Whereabouts?
<BenC> problem is right now that my guess about this is very vague aswell :)
<BenC> the guy at IBM doing our abat stuff can't boot his laptop with dapper
<BenC> I need to catch him when he has some time
<mjg59> Urgh. What hardware?
<BenC> can't remember, he pasted this info in /msg while I was asleep last week
<mjg59> Heh
<mjg59> I didn't think we had any Thinkpad DMI lists, except for apm
<zul> BenC: where is the list btw?
<BenC> I can't recall where off hand, but I remember adding some R30 stuff over the course of dapper
<mjg59> BenC: Oh, yes. R40.
<mjg59> But all that does is disable CPU low-power states.
<[g2] > Keybuk I'm a build from source kinda guy, my company does embedded linux distros
<[g2] > I did a couple year tour with Gentoo, but for the past couple years it's be OpenEmbedded and Debian/Ubuntu
<[g2] > would this be the place to chat about an EFI network installer or #ubuntu+1 ?
<[g2] > #ubuntu-boot ?
<BenC> EFI or PFE?
* BenC has done EFI on an ia64
<[g2] > EFI
<BenC> what does it need?
<[g2] > BenC let's back up a minute... what's PFE ?
<BenC> maybe it's PFX, but it's the intel network boot protocol
<BenC> for x86
<zul> PXE isnt it?
<BenC> yeah, that's it :)
<BenC> too many stupid acronyms
<[g2] > heh
<zul> heh...pxe is easy to do..i have done it before
<[g2] > well the MacIntel already has network booting as an option
<BenC> I thought EFI would be even easier, just create a kernel+initrd image
<[g2] > I haven't tried network booting dapper
<zul> BenC: same thing with PXE
<[g2] > so there are 2 scenarios
<BenC> PXE is easy, but the lilo pxe stuff isn't straight forward to setup
<zul> true, but I used syslinux
<[g2] > 2 scenarios I can see for the MacIntel
<[g2] > 1) your replacing Mac OSX and it doesn't matter your taking over the machine
<BenC> g2: ia64 is EFI, and we support network booting from it, so I suggest just duplicating what it does
<[g2] > 2) you want to co-exist
<[g2] > or tri-boot
<BenC> g2: well, those are installer issues, handled at install, irregardless of the boot method
<BenC> and I am pretty sure we handle them in some way
<BenC> not sure that the x86 installer is pivvy to MacOSX being a possible alternate OS though :)
<[g2] > BenC well Dapper trashed my OSX rootfs last night when updating the 3rd partition
<[g2] > so while in theory it doesn't matter at all, there are in practice issues to be worked out
<BenC> definitely an issue for #ubuntu-boot or whatever channel
<[g2] > ok I'll take that up over there
<[g2] > that leaves the issue of building the kernel to run from EFI
<[g2] > i'ts a kernel config option for running from EFI that doesn't have legacy support from my understanding
<BenC> EFI is enabled in the kernel
<BenC> not sure what else would be needed, if anything
<infinity> Our kernels are already MacTel-ready, afaik.
<infinity> We're just lacking a tiny bit of mkisofs magic to get our install CDs to boot sanely, so we can go from there.
<infinity> And no, booting with bootcamp doesn't count, since that then doesn't give us an EFI-ish system to work with, and sucks in ways we'd rather not deal with.
<[g2] > infinity so basically it's Ubuntu or the highway ?
<infinity> Err, no...
<infinity> Basically, it's "we need to fix our mkisofs to create HFS+ magic, then we can worry about the installer working right"
<infinity> Cause B won't ever happen without A.
<[g2] > infinity can we work on both issues in parallel ?
<[g2] > I've got 2 mini's one is the target
<[g2] > so from EFI we can do many things to the disk
<infinity> Can you boot the install CD from EFI?
<[g2] > I do with boot camp
<infinity> If not, it's a bit tough to test the install CD as booted from EFI.
<infinity> You see what I'm saying here?
<infinity> bootcamp provides you with some extra layers of hardware abstraction we don't want to deal with, aiui.
<infinity> (like giving us a fake VGA BIOS we don't want to deal with, etc, etc)
<[g2] > right, no need to re-invent the wheel twice
<[g2] > I'm fine with that, I'm asking more about compatibility
<[g2] > if I understand you, having an HFS+ based livecd allows the CD to boot from EFI by just holding down the "C" or Apple C key
<[g2] > that's the place you want to start from, correct ?
<infinity> It's not the filesystem on the livecd that matters, but the tiny little boot filesystem that the bootloader is read from.
<[g2] > stick in the CD/DVD, hold the C/Apple C key down, wake up in Ubunutu
<infinity> But yes, essentially, we need HFS+ on the CD, so we can bless it, so the braindead MacTel version of EFI will boot it.
<[g2] > correct
<[g2] > my point was we can bless the disk image that will result from the install and potentially start testing and debugging that now
<[g2] > you are absolutely correct, that for the process to work straight from CD/DVD other things need to happen 1st for the final product
<[g2] > I'm just suggesting a different way of debugging the process which may be totally off base
<\sh> moins
<\sh> dpkg-gencontrol -isp -pkernel-source-2.6.15.6-ubuntu1 -Pdebian/tmp-source/
<\sh> dpkg-gencontrol: error: package kernel-source-2.6.15.6-ubuntu1 not in control info
<\sh> is it just me? or is the latest kernel package somehow not buildable 
<mjg59> [g2] : If you boot in boot camp, you don't have access to EFI
<mjg59> [g2] : Our kernels have about as much mactel support as they're going to have (other than a couple of bugs which I've just submitted patches for)
<mjg59> [g2] : I've been testing the Ubuntu installer. We know what bugs there are for mactel installs, and they're pretty easy to fix. The booting is the fundamental issue
<\sh> ok...apt-get source and apt-get install is totally different...problem is sitting in front of the keyboard
<lamont> BenC: ping
<lamont> \sh: -22.34?
<\sh> lamont: yeah...just installed the source package of the source package of the linux kernel  .. totally wrong
<zul> \sh: its easier if you install git and get the git tree
<lamont> and it sounds like you installed kernel-source instead of linux-source...
<BenC> lamont: pong
<\sh> lamont: yeah I did:)
<[g2] > mjg59 ok so let's talk about the booting
<mjg59> [g2] : As far as the booting goes, you can either boot with bootcamp (loses access to EFI) or from EFI (for booting off CD, this requires an HFS+ filesystem on the CD to contain a blessed elilo)
<[g2] > ok timeout right there
<[g2] > booting with bootcamp to the current Dapper 2 beta works
<[g2] > clearly, the install is the issue IMHO
<[g2] > as that standard image _could_ just install and bless and HFS+ fs on the disk, no ?
<[g2] > I can fully understand ubuntu may want to release a _next gen_ EFI i32/i64 release that utilized EFI
<[g2] > I think your second scenario is that instance on an HFS+ fs
<[g2] > does that make sense ?
<mjg59> [g2] : No
<[g2] > mjg59 Ok
<mjg59> We don't have anything for producing HFS+ filesystems
<mjg59> (We won't distribute APSLed stuff)
<[g2] > is HFS+ under some Apple souce license ?
<mjg59> Yes
<[g2] > Ok, so two issues with that are:
<mjg59> But if you're booting with boot camp, then there's no point in creating extra HFS+ partitions
<mjg59> Since you've almost certainly got MacOS anyway, and it comes with one
<[g2] > right
<mjg59> The biggest drawback with bootcamp is that dealing with the partition table is very very difficult
<mjg59> Because you have two partition tables that have to be kept precisely in sync
<[g2] > so you are saying we put elilo on the 3rd partition and format that in a sane way
<mjg59> No
<mjg59> elilo can live happily in the FAT partition
<mjg59> But you need to be able to set EFI variables to make it bootable
<[g2] > well bootcamp already creates a FAT partition that's bootable no ?
<mjg59> No
<mjg59> Not in any useful way
<mjg59> It's not about whether partitions are "bootable" or not
<mjg59> In the Mac universe, there's no such thing
<[g2] > this is all EFI stuff
<[g2] > and apple's implementation of it
<mjg59> No
<mjg59> Macs do not boot in the same way as EFI does normally
<mjg59> Apple have wedged their own boot system into EFI
<mjg59> EFI can boot off any partition it can read files off
<[g2] > right as it's "open" more so in the BSD sense
<mjg59> I have absolutely no idea what you're talking about, I'm afraid
<mjg59> The mactel boot system is basically a slight modification of the way Macs have booted since the blue and white G3s
<[g2] > I mean the EFI code apple is using is probably based on the EFI code release as a reference by Intel
<mjg59> In order to get EFI to boot a file, you need to have access to EFI
<mjg59> But Apple have provided no mechanism for doing that
<[g2] > the EFI boot loader is read in off the SPI right ?
<[g2] > a question is how locked down that SPI is
<[g2] > my boards ship with a JTAG header to be able to reflash the bootloader
<[g2] > I'm sure there's some equivalent on the Mini's
<mjg59> Well, the question here is what are you trying to do?
<[g2] > that's easy -- dual boot dapper and os x
<mjg59> If you just want to run something yourself, this can all be done without JTAGing
<mjg59> There's a couple of bugs in the installer that you'll have to work around, but other than that all you need is a USB stick
<[g2] > Ok, usb stick/ external usb drive ?
<mjg59> Yeah
<mjg59> That's the easiest way
<[g2] > I've got plenty of those
<mjg59> Make an HFS+ partition on it, copy the kernel and initrd off an install CD, put elilo on there, write an appropriate elilo.conf (it just has to pass the same kernel options as isolinux would), bless elilo, reboot, hold down alt, select the USB drive
<mjg59> And make sure the install CD is in the drive
<[g2] > Ok... what about creating another partition that has the squashfs or the whole contents of the CD inside and pass an option th the kernel that elilo is booting ?
<[g2] > that way the booting kernel doesn't need to deal with HFS+ which is the issue at hard, but the media doesn't need to be CD either
<mjg59> There's no requirement for the media to be CD
<mjg59> It's just handy
<mjg59> You can put it on a USB device or whatever if you want
<[g2] > ok, so mounting on the network would work too
<mjg59> I believe so, yes
<mjg59> In that case you might need the netinstall images rather than the ones on the install CD
<mjg59> But at that point it's fairly unrelated to the kernel, so not really on-topic here
<[g2] > right
<lamont> BenC: if you happen to upload a new kernel before I finish tracking down 40286? (ia64 oops), please change ia64 config to have CONFIG_ACPI_DEBUG=y
<lamont> that at least masks the problem.
<mjg59> crimsun: I think we need a combined headphone/mute LED quirk
<[g2] > mjg59 infinity THX for the time discussing the EFI/kernel issues
<crimsun> mjg59: commit http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=2de01f5ad849fae75ea6339a7c8e9d08b49178e0 was originally the combined headphone/mute LED quirk, which was the state in -21- that bug 44066 reports. If we revert that, we break what was fixed in bug 41015. Apparently we have identical sub{vendor,device} ids with different behaviour :/
<cjb> crimsun: I've wondered whether that's possible.  Oh dear.  :/
<crimsun> I'll double-check our 2.6.12 later this afternoon.
<BenC> lamont: ok
<mjg59> crimsun: I wasn't clear on what the bug in 41015 was
<mjg59> Surely that's just asking for the nc8220 to have hp_only set?
<mjg59> Which is what the combined quirk did
<mjg59> BenC: I've just sent you a patch that saves/restores MSI interrupt state over suspend/resume - can we get that in as quickly as possible? It's probably why some machines are b0rked
<BenC> yeah
<mjg59> Cool, thanks
<BenC> np
<chninkel> hi
<chninkel> I have a package which need the kernel headers to be built
<chninkel> on which package should I build depend ?
<crimsun> linux-headers-$(uname -r) | linux-headers
<crimsun> although the latter is arguably frowned upon
<crimsun> chninkel: are you working on lirc?
<crimsun> chninkel: if so, are you merging Debian experimental's 0.8.0-1?
<BenC> chninkel: then you need to build depend on all the headers for each arch you support with that package
<BenC> chninkel: just like linux-restricted-modules does
<BenC> because it needs to be built for all the linux-image packages that could be installed
<chninkel> crimsun: I was thinking about it, I just noticed the experimental yersterday
<chninkel> crimsun: I don't know if I should better drop the updated lirc package I did or if I should try the experimental one
<crimsun> chninkel: I would merge 0.8.0-1, frankly, and drop Ubuntu bits if/when they conflict
<crimsun> chninkel: the exception being nomenclature like "linux-" vs. "kernel-" in debian/control*
<chninkel> crimsun: ok I will try the experimental one
<chninkel> crimsun: I just wondered if if was a good idea at that time
<chninkel> BenC: thanks for your answers
<BenC> chninkel: np, I would really suggest checking out l-r-m's build system to help get the module targets right
<chninkel> l-r-m ?
<BenC> linux-restricted-modules-2.6.15
<zul> heylo
#ubuntu-kernel 2006-05-17
<crimsun> mjg59: (RE: #41015, #44066) yes, that's what I thought as well, since that's what the source in ac97_codec.c does, which is how -21- functioned. Note that the reporter of #41015 says that -21- has the bug whereas -22- fixed it. On the other hand, #44066 reports that -21- worked fine, but -22- broke the LED. And for kickers, they all have /identical/ sub{vendor,device} ids.
<mjg59> crimsun: Right, but what change was there between -21 and -22?
<mjg59> The only thing I can think of is that my magic quirk was broken and didn't do the headphones properly
<crimsun> mjg59: I replaced AC97_TUNE_HP_MUTE_LED for 0x103c0934 with AC97_TUNE_HP_ONLY (which clearly explains #44066)
<mjg59> crimsun: Right, but why was TUNE_HP_MUTE_LED not sufficient?
<mjg59> HO_MUTE_LED is supposed to do what TUNE_HP_ONLY does
<mjg59> If it's not, then that's the bug
<crimsun> mjg59: that's what I can't figure out, since the code in ac97_codec.c clearly indicates that things _should_ work
<mjg59> If there's no difference between them, then the submitter is on crack
<crimsun> mjg59: right, I've reopened #41015 and asked for more information
<mjg59> Ok, thanks
<mjg59> It's known that over suspend/resume recent HPs seem to stop running the speakers
<mjg59> I don't /think/ that's due to the TUNE_HP_MUTE_LED thing
<crimsun> no, I'm pretty certain it's not
<mjg59> The headphones still work, but, well
<mjg59> And the ac97 registers are identical
<mjg59> Which makes debugging it pain
<crimsun> BenC: #44283 is legitimate, please merge http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=820fd69dc0f3a57236c7c7942cbd28a4bb9eae19;style=gitweb
<BenC> crimsun: ok
<crimsun> BenC: thanks!
<zul> heylo
<zul> wq
<zul> damn
<zul> BenC: having fun writing documentation?
<BenC> not really :)
<BenC> mjg59: ping
<mjg59> BenC: Hi
<BenC> mjg59: You have a Core Duo macbook, right?
<mjg59> BenC: Nope
<mjg59> I have a core duo Sony
<mjg59> And an imac
<BenC> ok, core duo is all I need
<BenC> can you see if you can confirm https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/43281 somehow?
<BenC> according to the report, core duo's hmm at low power state because of CONFIG_HZ=1000
<BenC> hum
<mjg59> It's nothing to do with core duos
<BenC> it claims Core Duo Mac's and Core Duo Dell's
<mjg59> It's poor quality capacitors
<mjg59> Well, poor quality power regulation
<BenC> should I bother with it?
<mjg59> Do you want the overhead of supporting another binary? :)
<BenC> no, not really :)
<mjg59> Then I wouldn't bother
<BenC> mjg59: Seems the problem with the latest bcm43xx isn't that it doesn't detect my chip, it's that it isn't initializing it correctly
<BenC> hw addr is showing up as FF:FF:FF:FF:FF:FF
<BenC> thought it might be some change in fw, but re-ripping fw with latest fw-cutter didn't help
<BenC> bringing up the interface didn't help either
<mjg59> BenC: Ah. There was a patch that was supposed to improve the mac address detection - it may have collided with the pcie patch
<mjg59> Which could lead to it never setting the mac address at all. Hang on, I'll take a look
<BenC> ok
<BenC> there was some collision with your patch and current code, I thought I had made things proper
<mjg59> BenC: Yeah, it loks ok
<mjg59> I'd look around line 3488 or so
<mjg59> Can you dump the different sprom macs and see which one it ought to be picking?
<mjg59> Oh, does the interface come up at all (just with a silly mac address)
<BenC> well, I didn't try much further after I saw the mac hosed
<BenC> I wouldn't expect it to work well in that state anyway
<mjg59> Well, that elts us know whether it's just the mac address or whether the entire card is hosed
<BenC> let me see what this shows
<BenC> mjg59: Well, it lets me set all the wireless opts I have, and it sees the ap's mac address, but no link
<mjg59> BenC: Ok, so it sounds like it's just the mac address
<BenC> it uses the first eth address (et1macaddr)
<mjg59> Is that valid?
<BenC> I need to print it out, because if is_valid_ether_addr() returns ok, then that should not be FF's
<mjg59> Yeah
<BenC> disconnectiont coming...
<BenC> ok, is_multicast_ether_addr() was broken
<BenC> so is_valid_ether_addr() was returning true for FF's
<mjg59> Ah
<BenC> I copied is_multicast_ether_addr from 2.6.16.13 and now bcm43xx works
<mjg59> Yes, that would explain things
<mjg59> Cool
<alex_joni> hello
<alex_joni> need some help running debuild on a linux-source source package
<alex_joni> I added an ADEOS patch to debian/patches/ , and debuild started working ok, compiled most (all?) it needed, but then errored out:
<BenC> which linux-source are you trying to build?
<alex_joni> linux-source-2.6.12 from breezy
<alex_joni> hello BenC, I was the one mailing you the other day.. :)
<BenC> what's the error?
<alex_joni> can I paste the error in here? or should I use pastebin (4 lines)
<BenC> 4 lines is ok
<alex_joni> +vmlinux zone_table 0x00000000
<alex_joni> make: *** [build]  Error 1
<alex_joni> debuild: fatal error at line 765:
<alex_joni> dpkg-buildpackage failed!
<BenC> you have an ABI bump
<alex_joni> got advice what I should do?
<BenC> echo "Yes" > debian/abi/i386.ignore
<alex_joni> then run debuild again?
<BenC> mjg59: If I make a kernel-acpi team in lp, can I make you head honcho? :)
<BenC> alex_joni: yeah
<alex_joni> BenC: thanks
<mjg59> BenC: Heh
<mjg59> BenC: Sure
<BenC> I'm trying to create some teams related to kernel bugs
* lamont has sparc questions
<zul> ooh...i wanna be on a team ;)
<lamont> BenC: pretty please on the CONFIG_ACPI_DEBUG=y for debian/config/ia64/config?  and when will a new kernel hit the archive?
<lamont> BenC: and then I have a stupid sparc question for you...
<BenC> lamont: Yeah, I'll do that...hopefully be upload in the next day or so
<lamont> given a CD in the drive, and an 'ok' prompt on the serial console, how do I boot from the CD?
<zul> boot cdrom
<lamont> danke
<BenC> yeah, that was a stupid sparc question :)
* lamont hasn't booted sparc before, you see..
<BenC> lamont: this acpi thing you are working on for ia64, is that related to the ACPI oops I see at every boot where it disables the ACPI irq?
<lamont> BenC: the specific issue for ia64 is that udevplug dies opening the acpi event sysfs file (kernel oops), so you don't boot
<BenC> what I get is an IRQ unhandled event, and it disables the IRQ that ACPI is on, so ACPI is disabled
<BenC> crimsun: ping
<lamont> BenC: ouch.  that might be happening earlier in the boot, dunno.. which arch for you?
<BenC> itanium
<lamont> ah, ok.  malone 40286, iirc.
* lamont brb
<BenC> it happens very early in boot, prior to initramfs actually
<alex_joni> BenC: got 2 minutes to look at http://pastebin.com/713846 ? , I'm compiling for the xth time today.. hope I didn't forget anything ..
<lamont> neet.  sparc box powers itself off if you leave it at that 'ok' prompt long enough.
<crimsun> BenC: pong
<BenC> crimsun: can you add ubuntu-kernel-team as a member of ubuntu-audio?
<BenC> do you have admin for that team?
<crimsun> sure
<BenC> thanks
<BenC> alex_joni: looks good
<alex_joni> BenC: ok, thanks..
<lamont> grumble
<lamont> so after I type 'boot cdrom' it says "ok "
<zul> thats should work
<zul> unless there is something wrong with the openrom
<BenC> lamont: It doesn't spit out a message?
<BenC> What type of sparc is it?
<lamont> Sun Blade 1000 (2 X UltraSPARC-III) , No Keyboard
<lamont> screen not found.
<lamont> keyboard not found.
<lamont> Keyboard not present.  Using ttya for input and output.
<lamont> Sun Blade 1000 (2 X UltraSPARC-III) , No Keyboard
<lamont> OpenBoot 4.0, 8192 MB memory installed, Serial #16453963.
<lamont> Ethernet address 8:0:20:fb:11:4b, Host ID: 80fb114b.
<lamont> {0} ok boot cdrom
<lamont> Boot device: /pci@8,700000/scsi@6/disk@6,0:f  File and args: 
<lamont> SILO Version 1.4.10
<lamont> Fast Data Access MMU Miss
<lamont> {0} ok 
<lamont> mind you, it could be a broken SB1000... or loose cables, or ....
<zul> i think i have seen that before there was a bug in launchpad
<lamont> something like yesterday's daily
<lamont> ok.. how do I tell it to boot from 1.2.3.4?
<zul> not sure :(
<BenC> you can netboot a tftp image
<BenC> boot net
<BenC> just need to setup rarpd and tftp
<maswan> BenC: btw, out of curiosity, how far away would a debug package with vmlinux for oprofile, etc, be away for the distribution kernels?
<BenC> probably something for edgy
* maswan nods
<BenC> if you are interested in seeing it happe, write a spec for it in lp so it can be discussed at the distro sprint in June
<maswan> Well, looking forward to se it, so I guess. :)
* lamont sets up rarpd
<lamont> no dhcp/bootp eh? feh.
<BenC> you'll need the ether address in /etc/ethers
<BenC> and the filename will need to be the ip address in hexformat, plus SUN4U
<BenC> actually, no SUN4U
<BenC> mine is: C0A80117
<BenC> you can usually just do the netboot and watch /var/log/daemon.log for the filename it is requesting
<lamont> hrm... how do I get stop+a on a serial console?
<BenC> send a serial break
<BenC> ^A f
<BenC> in minicom
<lamont> and there is booting.
<lamont> hardware shut off just short of finishing the download... hrm.. wonder if it has overtemp issues....
<BenC> sounds like it...the "power off at ok prompt" isn't usual of ultrasparc either
<BenC> could be a loose power plug or something too
<lamont> CPU casings seem rather warm...
* lamont wonders how it picks the filename, since C0A82306 bears little resembance to 8:0:20:fb:11:4b
<BenC> lamont: preference of the ubuntu hppa team being ubuntu-hppa or ubuntu-parisc?
<alex_joni> lamont: what's the mac of the eth ?
<lamont> hppa
<BenC> lamont: it's the IP address in hex, not the mac
<lamont> oh, doh
<cjb> lamont: Silly you.  People represent IP addresses in hex all the time, I don't know how you could possibly have missed that.  ;-)
<BenC> hehe
<lamont> local mirrors are nice for installs.
<lamont> hrm... 2 ea 9.1 GB hard drives... to raid, or not to raid.
<BenC> not to raid
<BenC> silo is very fickle about raids :)
<lamont> ah, good point
<lamont> does it need a silo partition or such?
<BenC> nah
<alex_joni> BenC: got another error from debuild, it was building udebs I think, and it complained that 'fan' the module is missing
<BenC> lamont: just make sure not to delete the 3rd partition (Whole Disk)
<lamont> so just give it a nice / and toss /home on sdb, eh>?
<lamont> uh...
<BenC> it's needed for Sun Disk Label foo
<BenC> yeah
<lamont> in the partitioner, told it to wipe the disk
<lamont> was that bad?
<BenC> nah, that should be good
<BenC> it knows
<BenC> alex_joni: just do debian/rules binary-debs
<alex_joni> BenC: the patch I installed is not compatible with ACPI, so those modules are turned off
<BenC> alex_joni: a full debuild isn't going to be useful unless you need the udeb's to create a bootable CD or something
<alex_joni> BenC: that's exactly what I am after, the udebs
<lamont> BenC: is there a debian/rules invocation to just build one flavor?  (besides just nuking the unwanted arch/config.flavor?
<alex_joni> is there a way to see what modules it expects?
<BenC> alex_joni: otherwise edit files in debian/d-i/
<alex_joni> ok.. looking
<BenC> lamont: debian/rules binary-debs flavours=686
<lamont> ah, ok
<BenC> that leaves the debs in debian/build/
* lamont wonders if maybe the plastic knife was loose.
<alex_joni> BenC: any way to run debian/rules binary-debs or udebs without having it recompile all?
<BenC> alex_joni: don't use debuild :)
<alex_joni> OK, thx
<BenC> or pass -nc so it doesn't do a full clean/build
<BenC> it will just start the build from where it left off (atleast dpkg-buildpackage does)
<alex_joni> debuild -nc ?
<alex_joni> or debian/rules -nc ?
<lamont> debuild
<BenC> lamont: You get the distinct privledge of owning two kernel arch teams :)
<lamont> I feel so proud
<BenC> will make it easier to assign bugs during the upcoming kernel hug day
<lamont> thanks
<lamont> note that I need that ia64 "fix" before I can do much with ia64...
<BenC> I'll have it in the next kernel upload
<lamont> anyone actually finding the bug is welcome to provide a real fix...
* lamont will be away from hardware at debconf for the next week
<BenC> almost wish I could reproduce it, but maybe with the debug enabled I can atleast fix my acpi bug aswell
<alex_joni> BenC: any idea what 'find: lib: No such file or directory' means?
<BenC> no idea
<alex_joni> :( debian/rules binary-udebs fails with that message
<lamont> hehehe... it wants to know what xorg driver to use on this headless box
* lamont picks ati, since that's the most likely card to get plugged in
<lamont> eventually
<lamont> maybe.
<alex_joni> did you guys ever use module-assistent ?
<zul> nope
<alex_joni> I meant module-assistant
<lamont> why would SIOCSIFADDDR return EPERM, I wonder
* lamont decides to finish the dist-upgrade before blaming too many things
<zul> i blame foobared
<alex_joni> anyone knows where the debian-installer package is?
<alex_joni> nm, found it..
<lamont> hrm.. and here I thought 3GB was a good amount for /...
<lamont> fabbione: if you poke your nose in, machine is happy
#ubuntu-kernel 2006-05-18
<crimsun> BenC: sent more patches :)
<zul> heylo
<crimsun> 'lo zul 
<zul> hey crimsun how is it going?
<crimsun> not bad, yourself?
<zul> good..
<ecoergi> i have a usb smartcard reader. they have given me a patch to use with the linux-2.6.16 kernel. i have breezy. is there a howto for this situation somewhere?
<ecoergi> i believe patch will apply to 2.6.12 kernel in breezy. need .config for this and instruction to rebuild initrd and such things
<crimsun> config is in your /boot/config-$(uname -r)
<crimsun> apt-get source linux-image-$(uname -r)
<crimsun> patch it and use devscripts to build it
<crimsun> [apt-get build-dep linux-image-$(uname -r)] 
<ecoergi> thanks crimsun 
<kimo> My toshiba laptop does NOT turn off at all using the new 22 kernel!! This is really irritating ...
<alex_joni> kimo: sounds like acpi problems
<mjg59> kimo: Please file a bug
<kimo> already filed ..
<mjg59> kimo: Which number?
<kimo> one second
<kimo> 31993
<kimo> it used to be 50%/50%, now it seems it doesnt turn off at all
<mjg59> Right, so it's not just -22
<kimo> talking to me? what's -22 ?
<mjg59> 12:20 < kimo> My toshiba laptop does NOT turn off at all using the new 22 kernel!! This is really irritating ...
<ivoks> kernel revision
<mjg59> What hardware?
<kimo> toshiba A105 S361 laptop
<kimo> kernel 2.6.15-22.34
<mjg59> What wireless chipset?
<kimo> ipw2200
<mjg59> If you do sudo modprobe -r ipw2200, does the machine shut down?
<kimo> hmm .. never done that 
<mjg59> Can you try?
<kimo> well. yeah but I am on that machine 
<mjg59> That just makes it easier :)
<ivoks> :)
<kimo> ok .. I can try that now
<kimo> I will just modprobe -r ipw2200
<kimo> then proceed with a normal poweroff
<kimo> ok?
<ivoks> mjg59: i'm having problems with hibernate since the begining of May (it worked before and I didn't touch anything)
<ivoks> kimo: yes
<kimo> one minute
<mjg59> ivoks: What's the problem?
<ivoks> mjg59: it doesn't shut down... hibernate starts and then disk led is on, but nothing happens for 10 minutes
<ivoks> mjg59: then it dies
<ivoks> mjg59: on AC and battery... same thing
<ivoks> on the other hand, sleep works
<mjg59> ivoks: Can you edit /etc/default/acpi-support and disable DPMS
<mjg59> Then move /etc/acpi/suspend.d/90-framebuffer-stop out of the way
<mjg59> Then try hibernation and tell me what output there is?
<ivoks> ok
<ivoks> by the way... there isn't restart function for /etc/init.d/acpi-support
<ivoks> i hope i'll be back :)
<kimo> Hi .. I'm back
<kimo> modprobe -r ; poweroff => NO POWEROFF
<ivoks> :)
<kimo> reboot then 'modprobe -r ipw2200; poweroff => CORRECT POWEROFF'
<ivoks> bad results here, too
<kimo> reboot then ' poweroff => CORRECT POWEROFF'
<ivoks> kimo: modprobe -r won't do anything
<kimo> It always seemed to me, that when I use my laptop for some time, it doesnt poweroff. If I immediately poweroff after booting , it works
<kimo> ivoks: yeah I meant 'modprobe -r ipw2200'
<ivoks> ok
<kimo> do u think I can just stick in Suse10.1 kernel in dapper, & it would work ?
<ivoks> no
<kimo> why is that 
<kimo> I mean a kernel provides an interface right ..
<mjg59> Because our kernel is somewhat modified
<mjg59> Ok. So what happens when you try to power off?
<kimo> the last thing .. it says 'will now halt' I think I hear the hard-disk tick like it's turning off, and that's it, the power button is still lighting. I have to press it for 4 seconds to manually turn off
<mjg59> Does the screen stay on?
<kimo> yes
<mjg59> Ok
<kimo> I would be happy to help u test patches & such 
<mjg59> if I have any, I'll let you know
<ivoks> kimo: do you boot with noacpi?
<mjg59> Oh, yes, that's a point. What does /proc/cmdline say?
<kimo> no .. I tried 2 tricks before 'acpi=force'& 'reboot=h'
<kimo> same result
<kimo> root=/dev/mapper/Kubuntu--VG-Kubuntu--LV vga=0x361 selinux=0 resume=/dev/sda6 splash=silent reboot=h acpi=force
<mjg59> Ok
<ivoks> bye
<mjg59> ivoks: How did yours fail?
<kimo> mjg59: so I hope I was helpful with this poweroff problem. Let me know if I can be helpful... (I really wish this gets fixed before Dapper)
<mjg59> kimo: Sure, I'm looking into it
<kimo> mjg59: ok .. just to keep in touch .. feel free to email me on email.ahmedkamal AT gmail.com
<mjg59> kimo: Can you try something for me?
<mjg59> kimo: Get the kernel, go to drivers/acpi/sleep/poweroff.c, search for acpi_power_off and then make the first line of that function:
<mjg59> acpi_sleep_prepare(ACPI_STATE_S5)
<mjg59> ;
<mjg59> I think the comment is wrong
<kimo> mjg59: I think I must have linux-source or something right ?
<mjg59> Yes
<mjg59> apt-get source linux-image-2.6.15
<kimo> then I'd recompile it ? :)
<mjg59> Oh, hang on a minute please
<kimo> ok ..
<kimo> not that I couldnt, but I wouldnt trust the results especially that I'm very new to debian systems
<alex_joni> I get a weird error when running debuild on the linux-source:
<alex_joni> find: lib: No such file or directory
<alex_joni> this is on linux-source-2.6.12 (breezy)
<alex_joni> this comes from the 'kernel-wedge check' from debian/rules -> binary_udebs
<kimo> mjg59: I'm still here ... lemme know when u need me to test somthing
<kimo> mjg59: Hi ... any findings about the 'poweroff' problem ?
<alex_joni> got a question about a freshly build d-i kernel, during bootstrap it complains that it can't find modules.dep
#ubuntu-kernel 2006-05-19
<alex_joni> guys: thanks again for all the help & info, I reached my goal
<MarkShark> Does anyone know why Ubuntu universe doesn't have the kdb package that is in Debian?
<MarkShark> Or to put it another way, what's the best way to build a kdb-enabled version of the Ubuntu kernel?
<MarkShark> Sorry, accidentally exited. Did I miss any the kdb advice I was looking for?
<jkakar> MarkShark: There were no messages during your absence.
<crimsun> MarkShark: it'll be ugly merging upstream kdb with our source
<MarkShark> Right...so what is the common practice for Ubuntu kernel debugging? i.e. anything beyond oops and printk?
<crimsun> pretty much.
<crimsun> I'd love to have kdb merged, but it's /hairy/ with our kernel
<cjb> MarkShark: systemtap!
<MarkShark> Thanks for the info...Systemtap looks useful. Any known gotchas to using it on a breezy system?
<cjb> Haven't tried, but I think it's reasonably portable. 
<TheMuso> c
<crimsun> BenC: many thanks for fixing the (mis)merges
<BenC> crimsun: no problem
#ubuntu-kernel 2006-05-20
<zul> heylo
<jbailey> BenC: Around?
<BenC> jbailey: yeah
<jbailey> BenC: Awhile ago I had bugged you about the machine freezes on the G5.  I don't know if we ever settled whether it was a kernel issue or an X issue.
<jbailey> We had talked abotu disabling the radeon kernel driver on ppc64 to solve the problem for dapper if we didn't hit a better solution.
<BenC> ah, I think the next kernel might interest you :)
<BenC> care to test a ppc64 kernel from current git?
<jbailey> Ah?  Okay.  I won't automatically do a sudo find /lib/modules -name radeon.ko -exec rm '{}' \; when it shows up then. =)
<jbailey> Sure.  Is it hard to build?
<BenC> I have one already built
<jbailey> \o/
<BenC> let me upload it somewhere
<jbailey> If all you need is a tester, I'm always yours dude.
<BenC> I had forgotten about that problem, but there are definitely changes in this kernel to the drm/accel that might help
<jbailey> All good.  Deleting radeon.ko has just become automatic, and it occured to me that probably it shouldn't have become. =)
<BenC> -rw-r--r-- 1 bcollins bcollins 23751558 May 15 09:01 linux-image-2.6.15-23-powerpc64-smp_2.6.15-23.35_powerpc.deb
<BenC> it will soon be at p.u.c/~bcollins/linux-image-2.6.15-23-powerpc64-smp_2.6.15-23.35_powerpc.deb
<jbailey> What's your uplink speed over the bird?
<BenC> looks like it will take about 9 minutes
<Mithrandir> BenC: does that mean you're trying to do a kernel ABI transition before flight 8?
<BenC> like 256kbit/sec
<BenC> Mithrandir: when's flight 8?
<jbailey> Ah, so not horrible.
<BenC> I planned on upload this today
<Mithrandir> BenC: freeze thursday morning, release on friday's the plan.
<Mithrandir> BenC: ahkay, that should work fine then.
<BenC> ok, we should be good then
<mjg59_> BenC: Have you stopped doing daily builds?
<BenC> mjg59_: daily builds stopped themselves
<BenC> I'm hardly ever in a buildable state when the auto run went through
<mjg59_> BenC: Ah :)
<BenC> so I just stopped it for now
<BenC> jbailey: it's done
<jbailey> BenC: Thanks, fetching.
<jbailey> BenC: Trying it.
<zul> heh...lupins
<jbailey> BenC: Running it, I'll let you know how it goes.
<jbailey> BenC: Although your changelog entry says taht you twiddle radeon on everything except ppc... ;)
<BenC> jbailey: it sort of likes right now :0
<BenC> plus, I actually updates to drm from 2.6.16
<BenC> *updated
<jbailey> Ah, hadn't noticed that part.
<jbailey> We'll see how she goes.  It usually hangs within a day or so.
<airlied> BenC: you might want to pull DRM from my tree, the radeon memmap changes are in it...
<airlied> the only worry I hve with the 2.6.16 tree in 2.6.15 is compound page stuff..
<airlied> jbailey: you running the latest xorg-driver-ati from dapper?
<jbailey> Aucun paquet ne correspond  xorg-driver-ati.
<jbailey> airlied: No such package, sorry.
<zul> damn quebecers ;)
<airlied> jbailey: hmm can't remember the package name xorg-x11-driver-ati maybe..
<airlied> ...
<airlied> xserver-xorg-driver-ati
<jbailey> ii  xserver-xorg-driver-ati                      6.5.7.3-0ubuntu7               X.Org X server -- ATI display driver
<jbailey> I should have current Dapper on here, yes.
<airlied> jbailey: cool that will probably fix ati problems quicker than the kernel :-)
<airlied> gotta run zzzz.
<jbailey> airlied: I don't think I'v'e tried with the drm bits enabled since may 1st.
<jbailey> So we'll see about the combo of them.
<jbailey> airlied: ISTR benh saying that it was some sort of mmap misalignment between the two, though, so if there's fixes for that, it might be worth getting in.
<allee> Should todays AMD64 netboot.tar.gz expected to work with modules in archive? d-i 'Download installer components
<allee> tells me no kernel modules found
<allee> BenC: reading channel title .. would be nice to get this fixed in dapper: [Bug 37452]  Re: fusion mpt sas driver does not find a RAID1 disk during installation(Sun Galaxy X4200 and X4100)
<allee> BenC: latest comment states that it's fixed in 2.6.16.16
<BenC> saw that, I was planning on syncing to that
<BenC> I have it marked important in my bug mbox
<allee> BenC: great, thx.  I keep a box with RAID1 down for now so I can test
<mdke> hi there.
<mdke> I see there is an rt2570 driver in the kernel, and I've been trying to talk my brother into getting his wifi usb card to work over the phone
<mdke> the module wasn't inserted and after inserting it, the device didn't show up in ifconfig -a. Any hints for debugging to put in a bug report?
<mdke> ah, sounds like he has been lucky, looking at bugs #34845, #34902, #34845, #39227 (are these dups?)
<jbailey> Wow klibc made it into the mm tree.
<mdke> well, PM me if you have any ideas
#ubuntu-kernel 2006-05-21
<CarlFK> where can I get the .config that is is used to buiild the normal ubuntu kernel?
<crimsun> CarlFK: debian/config/
<CarlFK> all I want to do is update a wifi driver using http://acx100.sourceforge.net/
<CarlFK> thanks
<crimsun> CarlFK: barring that, there's a copy in /boot/config-$(uname -r)
<CarlFK> how handy
<CarlFK> should it be called .config or .configure or ?
<crimsun> depends, are you copying it to $source/. ?
<crimsun> if so, $source/.config
<crimsun> it actually depends how you're going to compile it
<CarlFK> I was going to type make ;)
<CarlFK> juser@dhcp36:~/src/ubuntu-2.6$ cp debian/config/i386/config.686 .config
<CarlFK> make
<CarlFK> few lines, then # using defaults found in .config
<crimsun> ah, no
<CarlFK> are there any building instructions somewhere?
<crimsun> sorry, my wifi connection died
<crimsun> erase all the configs you're not going to use from debian/config/
<crimsun> copy the one you want to use there
<crimsun> then debuild binary
<CarlFK> into  debian/config/ ?
<crimsun> yes
<CarlFK> so this: juser@dhcp36:~/src/ubuntu-2.6$ cp debian/config/i386/config.686  debian/config/i386/.config
<CarlFK> hmm, not exacly what you said...
<crimsun> CarlFK: nah, you can just erase everything save config.686
<crimsun> err
<crimsun> sorry, I forgot you're not using your /own/
<CarlFK> ah, otherwise it would build one for each config?
<crimsun> you'll just want to erase config.{k7,server*}
<CarlFK> yeah, I want to get a vanilla build to work before I start hacking on it
<CarlFK> -bash: debuild: command not found
<crimsun> devscripts
<CarlFK> should that be part of linux-kernel-devel  ?
<crimsun> (no)
<crimsun> you could ``fakeroot debian/rules binary'', too
<CarlFK> this is a form of "hack comfortably on the kernel." that I am not familiar with ;)
<CarlFK> http://paste.foxshare.net:8888/732  - dpkg-checkbuilddeps: Unmet build dependencies: debhelper
<crimsun> you'll need that, too.
<CarlFK> @#$@$
<CarlFK> Can't exec "fakeroot": No such file or directory at /usr/bin/debuild line 845.
<crimsun> right, install that, too.
<CarlFK> couldn't exec fakeroot debian/rules:
<CarlFK> do I need to sudo debuild binary ?
<CarlFK> http://paste.foxshare.net:8888/733
<CarlFK> something is still missing
<CarlFK> I have 10 min to get to the3 bank... be back in 30
<crimsun> CarlFK: it's recommended that you install fakeroot and use that instead of using sudo
<CarlFK> back
<CarlFK> I did install fakeroot
<CarlFK> I didn't use sudo
<CarlFK> but I didn't use fakeroot either 
<CarlFK> guessing I am building a kernel.deb?
<crimsun> linux-image-foo.deb
<CarlFK> is this what I should do? juser@dhcp36:~/src/ubuntu-2.6$ fakeroot debuild binary
<crimsun> just ``debuild binary'' should suffice
<CarlFK> http://paste.foxshare.net:8888/733
<CarlFK> ah
<CarlFK> I rm'ed archmap
<CarlFK> basically
<CarlFK> this fixed it: juser@dhcp36:~/src/ubuntu-2.6$ cp debian/config.all/archmap debian/config/
<CarlFK> (should be obvious what I did...)
<CarlFK> arg!
<CarlFK> it is still prompting me for .config options 
<CarlFK> Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [N/y/?]  (NEW)
<CarlFK> do I need debian/config.all/i386/config.386 also?
<crimsun> yes. config and config.386 /unless/ you just copy your existing /boot/config-$(uname -r) over as config.686
<crimsun> then you'll probably want to trim archmap
<CarlFK> is this really the recommend way for someone to tweak there kernel?
<crimsun> there is no "recommended way" that I know of
<CarlFK> I'm surprised. 
<CarlFK> not totally - just a little ;)
<CarlFK> dpkg-checkbuilddeps: error: syntax error in control file debian/control at line 0: empty file
<CarlFK> yup
<CarlFK> -rw-r--r-- 1 juser juser 0 2006-05-15 18:30 debian/control
<CarlFK> who's problem is that? 
<CarlFK> btw - if I ever get a clean build, Ill do it all again and make a wiki page
<crimsun> -rw-r--r--  1 crimsun crimsun  39016 2006-05-12 12:44 control
<crimsun> -rw-r--r--  1 crimsun crimsun  39016 2006-05-12 12:44 control.stub
<CarlFK> -rw-r--r-- 2 juser juser 39016 2006-05-15 17:47 ./debian/build/build-686/debian/control
<CarlFK> sh: line 2: cd: debian/build/build-386: No such file or directory
<CarlFK> @#$@#$@
<CarlFK> found some docs: https://wiki.ubuntu.com/KernelCompileHowto?highlight=%28CategoryKernel%29
<CarlFK> "At this point, you need to change your kernel's configuration to statically include your bus, disk, and filesystem drivers. This can be rather difficult if you don't know what you're doing. Use "make menuconfig" (or "make xconfig", gconfig, etc.) to change the config."
<CarlFK> why is that?
<crimsun> that's if you don't want to muck with initramfs
* Keybuk wonders whether dapper boots without an initramfs
* lifeless doubts it
<cjb> Keybuk: Not for me, given my IDE driver's on it.  :)
<CarlFK> hmm, my goal  may not be needed at all
<CarlFK> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/22238
<CarlFK> hmm, last Changelog change is 2005 12 02, but there are a few 2006 versions in http://www.cmartin.tk/acx/
<CarlFK> I am going to rebuild the box and follow https://wiki.ubuntu.com/KernelBuildpackageHowto
<CarlFK> see ya tomorrow 
<CarlFK> thanks for the help
<Keybuk> man, I need a "bashing initng" channel
<crimsun> there's always ubuntu-users.
<crimsun> ooh, oops. Probably not. :-)
<Keybuk> this thing is seriously scary
<Keybuk> the fact people rely on it to boot their computer
<Keybuk> for a start, it's totally backwards
<Keybuk> rather than "begin with startup, and work your way through the list of things one by one until you run out of things to run"
<Keybuk> it's "here's the last thing to run, now work out everything you need to get there"
<zul> eww
<Keybuk> I like the fact that you just get a flashing cursor on tty1 too
<Keybuk> it doesn't bother spawning, say, getty
<Keybuk> the author clearly decided that was "too hard"
<Keybuk> (it spawns it on tty2 through tty6 just fine)
<zul> lol
<jbailey> Keybuk: WEll, it's a dependacy based init system.
<Keybuk> it's a crack based
<Keybuk> no, it's worse
<Keybuk> it's cornflour based :p
<jbailey> Dude, it's no worse than coding in Prolog ;)
<jbailey> And a frightening amount of stuff is written in prolog. =)
<zul> jbailey: try cobol
<Keybuk> it just seems very strange to me to have a "goal" for booting
<jbailey> goal: gdm.
<jbailey> Do what it takes to get user to gdm.
<Keybuk> everything I've learned suggests that you want the exact opposite; booting is just a state of mind
<Keybuk> right
<Keybuk> so what do you do about the stuff that's not in gdm's critical path? :p
<Keybuk> do you run it, or do you not run it?
<Keybuk> (initNG chooses not to run it <g>)
<jbailey> Don't run it.
<jbailey> It's not something you've said you're interested in.
<Keybuk> yeah
<jbailey> How much cruft would we have saved from our bootup over the years if we did that?
<Keybuk> it means you have to set a *huge* list of goals
<Keybuk> indeed, initNG comes with a shell script that just sets the list of goals to the list of init scripts
<Keybuk> simply because it doesn't work otherwise
<Keybuk> I think the opposite is better
<Keybuk> "right, we've started -- does anything care?"
<Keybuk> "a network device just got plugged in -- did anything need one of those?"
<jbailey> Autconfiguring every network device that shows up isn't necessarily a secure system.
<jbailey> On a user based system that might be more correct.
<jbailey> On a server based system it's arguably not.
<Keybuk> a network device showing up kinda implies physical access :p
<jbailey> True, and trusted armed guards are the final line of defense.                                                                                                                                                                                                         True,
<jbailey> wtf?
<Keybuk> *giggles*
<Keybuk> oh, wow
<Keybuk> initNG includes a kernel patch
<jbailey> Eh?
<Keybuk> to allow you to attach gdb to process 1
<Keybuk> *gawp*
<zul> ummm...okie dokie
<Keybuk> there's a REASON the kernel doesn't let you do that!
<cjb> Keybuk: cap_ptrace will stop you doing that.
<cjb> So they'd have to be taking out chunks of security/.
<Keybuk>         /*
<Keybuk>          * You may not mess with init
<Keybuk>          */
<Keybuk>         if (pid == 1)
<Keybuk>                 return -EPERM;
<Keybuk> it's not so much just security ... it's the fact the kernel relies on being able to attach processes to init and have them reaped
<Keybuk> if init is stopped in ptrace, you'd dead lock the kernel
<cjb> also seclvl.c:   * Explicitely disallow ptrace'ing the init process.
<Keybuk> sweet
<Keybuk> I like it when people not only imitate djb's coding style, but also even his lack of web page design
<Keybuk> oh, and this replacement init is written in scheme!
<Keybuk> proof that initNG isn't the most crackful thing in its field
<Keybuk> jbailey probably likes this one :p
<jbailey> Hmm?
<zul> hehe
<jbailey> Oh dear.
<jbailey> Tell me they compiled it?
<Keybuk> it says it's intended for the Hurd
<Keybuk> which explains a lot :p
<jbailey> Oh, haha.
<jbailey> Is that the one written by Jeroen?
<Keybuk> Wolfgang Jhrling
<jbailey> Ah, I met him at LinuxTag a week ago finally.
<jbailey> Anyhow, I need to clean up.  houseguests in two days.
<BenC> jbailey: ping
<CarlFK> shouldn't linux-kernel-devel be somewhat related to one of the https://wiki.ubuntu.com/KernelCompileHowto pages?
<CarlFK> apt-get source linux-source-2.6.8.1
<CarlFK> is there a meta package for 'current version' ?
<cjb> linux-source-2.6.
<CarlFK> thanks
<bluefoxicy> I forgot, how do I build a kernel package from source again?  apt-get source ...?
<CarlFK> pick one of these https://wiki.ubuntu.com/KernelCompileHowto
<CarlFK> I am using  https://wiki.ubuntu.com/KernelHowto 
<CarlFK> sudo apt-get install linux-source
<CarlFK> that got me the source in /usr/src
<jbailey> BenC: Pong, but about to head to bed.
<jbailey> BenC: 'sup?
<BenC> hey
<BenC> jbailey: any crashes?
<jbailey> Not so far.
<jbailey> I've done the usual things today, I think.
<BenC> cool, just wanted to check in
<BenC> I'm about to upload
<jbailey> Congrats if you've licked this one. =)
<jbailey> I've reenabled the screensaver for overnight, too.
<jbailey> It didn't stop the crashes before, but  who knows.
<jbailey> That way it'll get a bit of a GL workout, too.
<bluefoxicy> alright
<bluefoxicy> going to try patching this http://people.redhat.com/mingo/exec-shield/exec-shield-nx-2.6.15.patch
<bluefoxicy> Into ubuntu's kernel via https://wiki.ubuntu.com/KernelBuildpackageHowto
<bluefoxicy> If it works I'll make note on https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap and I guess we'll see what happens in Edgy or such.
<bluefoxicy> the patch itself needs testing; other softwares' reactions to this is thoroughly tested already, as i386 ubuntu on any architecture with a real NX bit already turns the NX bit on and signifies the PROT_EXEC protection
<bluefoxicy> Not enough time to get a good thorough test cycle in before Dapper though.
<bluefoxicy> ah screw it, I'll get it tomorrow or something
<bluefoxicy> need to sleep now.
<kimo> I'm still having problem powering of my toshiba A105-S361 laptop (Bug 31993). It's very irritating every time I turn off my laptop. I am willing to help anyone by testing any fixes on my machine..
<jbailey> BenC: ping when you're awake.  Interesting twist to the bug this time.
<airlied> jbailey: radeon bug?
<jbailey> airlied: I *think* so.
<jbailey> But different than it's ever been.
<airlied> different bug then :-)
<airlied> what does it do now?
<jbailey> Usually either my machine is locked solid, or X is pushed to 100% utilisation and ssh;ing in to kill it can take 15 minutes.
<airlied> yeah, that more like a real hang.. anything in  particular cause it?
<jbailey> No.  That's the problem.
<jbailey> I can't force it to reproduce, although it does so consistantly within a day or so, and often within an hour.
<jbailey> When the bug first started happening it could be when I was typing.  Now adays it's more likely when I'm idle.
<airlied> jbailey: what chip is it? the M10?
<jbailey> I had disabled the screensavers and stuff to see if it was GL triggered, but that hadn't stopped it.
<jbailey> 0000:f0:10.0 VGA compatible controller: ATI Technologies Inc RV350 AR [Radeon 9600]  (prog-if 00 [VGA] )
<jbailey> This time what happened what that I cam back to my machine and tapped my mouse.  Black screen.
<jbailey> Went to the other machine, and ssh'd in.  on of the glx screensavers was running, 60% utilisation.  Nothing big.
<jbailey> kill worked fine.
<jbailey> (didn't even need kill -9)
<jbailey> like I usually do with X
<jbailey> Came back to my machine and the keyed up C-M-F1 to switch consoles had taken effect.
<jbailey> When I switched back to my graphical session, I noticed that my IRC sessions had all hung at the time when I'd moved the mouse.
<jbailey> So a bunch of them, the last traffic I saw was 06h58.
<jbailey> and then disconnected.
<jbailey> reconnected at 06h59 when I killed the screensaver.
<jbailey> I have no conclusions as to what the problem is, only that it's now different.
<airlied> so the X server didn't crash out .. wierd..
<jbailey> Right, like I'm still on that session now.
<airlied> do you have DRI working? i.e.does glxinfo give Direct Rendering: Yes
<jbailey> direct rendering: Yes
<jbailey> I do get a strance warning as well,. though:
<jbailey> *********************************WARN_ONCE*********************************
<jbailey> File r300_state.c function r300Enable line 456
<jbailey> TODO - double side stencil !
<jbailey> ***************************************************************************
<jbailey> And glxgears doesn't print frame rates.  It just prints that warning as well.
<airlied> ah gears has fps disabled.. do you remember what screensaver it was?
<zul> heylo
<jbailey> BenC, airlied: Had my first full machine hang.
* zul decides to take the rest of the week off
<CarlFK>   CC [M]   drivers/usb/net/zd1211/zdmic.o
<CarlFK>   DEVLIST drivers/usb/net/zd1211/zddevlist.h
<CarlFK> make[4] : *** [drivers/usb/net/zd1211/zddevlist.h]  Error 1
<CarlFK> that was from linux-source-2.6.15.tar.bz2
<CarlFK> #error "Error in source file, line 35"
<CarlFK> huh?
<BenC> jbailey: suckage
<BenC> crimsun: ping
<BenC> Mithrandir: ping
<BenC> CarlFK: Install the linux-source-2.6.15 build-deps
<Mithrandir> BenC: pong
<Mithrandir> BenC: flight 8 is cancelled due to the sudden leave on Friday.
<BenC> Mithrandir: ah, answers my question...I'll be doing a kernel upload today then
<Mithrandir> BenC: please do go ahead
<zul> sudden leave?
<BenC> zul: Canonical employees and have been forced to take Friday off :)
<zul> ah...ok..
<Mithrandir> zul: the distro team was told to take Friday off.  Anybody who is active on ubuntu work that day and detected by mdz gets to buy mdz a drink in Paris
<zul> i thought it was something catastropic
<zul> hehe...i have friday off as well
<BenC> I'm going to make a small git push on Friday just to see if he's watching
<Mithrandir> heh
<BenC> the catch is, if he notices, then he didn't take off either, so he'll owe me a drink too :)
<maswan> BenC: think I could talk you into accepting a couple of patches? in launchpad on 4478[23] , a couple of bugfixes (one applied in 2.6.16 even) that are quite significant to us.
<BenC> maswan: got both of them already
<maswan> BenC: excellent!
<CarlFK> BenC: what is "the linux-source-2.6.15 build-deps" ?
<BenC> CarlFK: apt-get build-deps linux-source-2.6.15
<BenC> or maybe it's just build-dep
<maswan> BenC: Should I update launchpad status, or do you want to fiddle with that yourself?
<CarlFK> BenC: build-dep
<infinity> BenC: When are you planning the kernel upload?
<infinity> BenC: I wanted to make one last small tweak to vga16fb timings, but if I'm too late and miss the release, it's not the end of the world.
<BenC> infinity: I'm getting ready to start my last build cycle before upload
<BenC> so you've got about an hour or two
<infinity> (since it more-or-less works for more people than it more-or-less worked for in breezy, I'm not fussed about fixing it for the last 2 or 3 people it's broken for)
<BenC> maswan: I'll get it in a few minutes, thanks
<maswan> BenC: Awesome. Thanks for the great work!
<infinity> BenC: Og, an hour or two isn't long enough to test the changes I wanted to make and get 'em in, so don't worry about it.
<infinity> s/Og/Oh/
<BenC> infinity: ok, I'm sure there will be one more upload before release, so there's be another chance
<infinity> BenC: Alright, if I find the free time.  It's currently prioritised below more important stuff, but it's been something I was "meaning to do before release" and never got to.
<infinity> BenC: I suspect I'll have a lot of those left over on June 1st, though. :)
<BenC> probably :)
<bluefoxicy> wow
<bluefoxicy> I might have almost passed linear algebra, I think.
<bluefoxicy> I counted 126 points on my final, I need 126 to pass.  o_o
<BenC> bluefoxicy: Relying on your counting abilities to guess if you passed a math related exam seems counter intuitive :)
<CarlFK> if all I want to do is build a module, I just need the kernel headers, right?
<zul> yes
<CarlFK> thanks
<CarlFK> Is there a ubuntu package that is the kernel source without any patches?
<CarlFK> (I don't want it, just trying to see how it is described)
<bluefoxicy> BenC:  heh.
<BenC> CarlFK: no such package, since kernel.org has all that stuff
<CarlFK> would that be called "the Vanilla Kernel?" 
<zul> yes...
<jbailey> Mmm.  vanilla.
* jbailey wants icecream now.
* zul is having lunch
<CarlFK> what is the difference between kernel-source-2.6.11 and  kernel-tree-2.6.11 ?
<CarlFK> nm
<CarlFK> tree = source + patches
<CarlFK> wait.. source =  "Linux kernel source for version 2.6.11 with Debian patches"   http://packages.ubuntu.com/breezy/devel/kernel-tree-2.6.11
<CarlFK> so what is the point of tree?
<infinity> There is no more tree, so you can stop worrying about it. :)
<CarlFK> good answer
* CarlFK thinks "there is no spoon'
<jbailey> SPOOOON
<jbailey>  - the tick
<zul> hehe...
<zul> spooooooooooon
<crimsun> BenC: pong
<BenC> crimsun: The one-liner patch failed to build
<crimsun> guh
<crimsun> BenC: what is the error message?
<mjg59_> BenC: Line 608 of drivers/acpi/asus_acpi.c - can you remove the "Asus ACPI: Error reading LCD status" printk?
<mjg59_> It doesn't work on some machines and they spew errors
<BenC> crimsun: The member of that struct doesn't exist
<BenC> mjg59_: ok
<mjg59_> Ta
<mjg59_> saves me sending you a patch :)
<BenC> mjg59_: done
<crimsun> BenC: (just taking a sec to update here)
<crimsun> BenC: I see the proper fix, I'll push out a patch ASAP (ETA: 10 mins)
<crimsun> BenC: sorry about that
<BenC> ok
<BenC> np
<CarlFK> if I build a module using linux-headers-2.6.15-22-386, what happens when a new kernel package is released?
<infinity> You get to rebuild your module to match the new kernel.
<CarlFK> thats what I thought. thanks
<infinity> (Assuming the ABI changed, which we try very hard to avoid during stable releases)
<zul> i have an rem song in my head
<zul> make it stop!!
<CarlFK> what is the difference between: 
<CarlFK> apt-get install linux-source-2.6.15 
<CarlFK> and 
<CarlFK> apt-get source linux-image-2.6.15-22-386
<BenC> the actual source is the same
<BenC> just one way installs the package, and the other downloads the files that actually build the images
<CarlFK> so just the location ?  
<CarlFK> ah
<zul> later...im on my way home
<crimsun> BenC: sent.
<jbailey> BenC: Just had the screensaver hang agian.  I think it might've been gleidoscope both times.
<BenC> crimsun: wow, one-liner went to a pretty hefty patch :)
<BenC> jbailey: Damn, there goes the hope for updated DRM fixing things :/
<crimsun> BenC: yeah, I dunno what crack I was smoking the first time w/ grep struct
<jbailey> BenC: Yeah.  I'll probably take it out on next reboot.
<airlied> BenC: you still only have 2.6.16 DRM, the radeon changes are only in my tree and 2.6.17..
<BenC> airlied: You haven't provided me with any info on how to obtain that, or a patch to update my tree
<airlied> BenC: okay I'll do a patch later, my tree is is the drm-2.6 one on kernel.org..
<BenC> is it possible to pull from it without getting anything past 2.6.15?
<airlied> BenC: probably not...
<airlied> BenC: I'll cook a patch later when I'm actually awake as opposed to no when I should be asleep..
<CarlFK> can someone review  https://wiki.ubuntu.com/KernelHowTos  - it is a summary of what I have learned here over the last day
<BenC> might be too late to get it in, but I'll try
<CarlFK> http://acx100.sourceforge.net is a wifi nic module - it's README says I need to build it with the rest of the kernel: http://dev.personnelware.com/carl/temp/May16/a/README
<CarlFK> shouldn't I be able to do it with just the headers?
<BenC> yes
<BenC> you do know we have acx100 in our kernels, right?
<CarlFK> yes - but it is about 8 updates old
<CarlFK> current is v0.3.35
<CarlFK> acx_config.h:#define ACX_RELEASE "v0.3.21"
<CarlFK> .21 came from rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
<zul> heylo
#ubuntu-kernel 2007-05-14
<MrNOKIA> hello again :)
<MrNOKIA> i'm a little bit puzzled: could anynone please explain the "your processor does not support long mode, use a 32bit version" error ? i got it twice, once on gentoo 2007 and also on feisty fawn, when trying to boot a dell inspiron 6400 centrino dual core box
<MrNOKIA> what is more strange, is that on a dell inspiron 6400 intel dual core 2 the error doesn;t appear
<MrNOKIA> both distros, however, are puzzled by the ATi x1400 vga, which is very strange, at least from ubuntu point of view: both dapper and edgy detected it flawlessly
<MrNOKIA> but not feisty...
<crimsun> MrNOKIA: tell me the output from `grep ^flags /proc/cpuinfo |uniq` in #ubuntu, please.
<johanbr> crimsun: Don't know if you remember, but I asked you about my USB phone a few days ago. I couldn't get audio over USB to work, so I tried bluetooth instead and I can reliably get the Feisty kernel to panic.
<crimsun> johanbr: snd-bt-sco or a2dpd plugin?
<johanbr> crimsun: snd-bt-sco
<crimsun> johanbr: the latter is preferred.
<johanbr> I didn't realize they were functionally equivalent. I'll give a2dpd a try, thank you.
<BenC> crimsun: where is a2dpd?
<crimsun> BenC: alsa-lib plugin distributed by bluetooth-alsa.sf.net.
<Amaranth> that's an odd name for a module
<BenC> crimsun: should I ditch snd-bt-sco?
<crimsun> BenC: I can't say at this point (I don't have enough feedback to provide an answer).
<johanbr> I assume that then you'd have to package bluetooth-alsa?
<crimsun> johanbr: adding the plugin to our alsa-lib source is not difficult.
<crimsun> A lot of people are having problems with snd-bt-sco, but that's with older code.  I don't know offhand (no local equipment) if updating it resolves the issues.
<crimsun> johanbr: I'm trying to hold off updating the alsa-* source until 1.0.14 final is released, since there are so many fixes.
<johanbr> crimsun: I see. I should have some more time in a week or so, then I'll do some experimenting with a2dpd and maybe a newer snd-bt-sco. I'll let you know if I find anything interesting.
<crimsun> johanbr: many thanks.
<johanbr> I'm happy to contribute what little I can. :)
<johanbr> Well, gotta go...
<MrNOKIA> thanks crimsun, meanwhile i found out with stupefaction that intel's centrino duo hasn't x64 support
<crimsun> correct.
<Mithrandir> duo 2 has
<Mithrandir> duo 1 does not.
<crimsun> gotta love core duos.
<MrNOKIA> only trouble is, the dell with centrino is mine, the dell with core 2 duo is not :(
<MrNOKIA> speaking of core 2 duo inspiron, it has 2 problems, one being very strange
<MrNOKIA> first of all, it seems to lack support for the BCM... bluetooth card
<crimsun> it would be useful for the kernel team if you can point to a detailed wiki page with the components, dmesg, and lspci -nvv .
<MrNOKIA> on the other hand, the ATI x1400 doesn't work with official ati drivers
<MrNOKIA> pastebin is ok ?
<MrNOKIA> it would be best to have a comparison between dell inspiron 6400 centrino duo and dell inspiron 6400 core 2 duo
<MrNOKIA> they are 95% similar
<MrNOKIA> and i have them both right now on feisty and feisty_x64
<crimsun> MrNOKIA: a more ... permanent page on the Ubuntu wiki under the LaptopTestingTeam hierarchy is arguably more helpful.
<MrNOKIA> ok, let me see what i can do. never done that before :)
<zdzichuBG> is it safe to install gutsy kernel on feisty?
<crimsun> I don't recommend it, but some people report it works dandy.  And I presume you mean 2.6.22-2, because the "gutsy kernel" still is feisty's 2.6.20-15.
<zdzichuBG> crimsun: thanks. And yes, I mean latest  upload, with dyntics, timerstats and other good stuff.
<zul> hey
<elmarco> FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol 'pagefault_disable'
<elmarco> any idea what I can do to override this for private use?
<mjg59> Change EXPORT_SYMBOL_GPL(pagefault_disable) to EXPORT_SYMBOL?
<zul> BenC: is there a meeting tomorrow?
<DBO> is there anyone on the kernel team that wouldn't mind answering a couple quick questions?
<mjg59> Depends how quick
<mjg59> But go ahead :)
<DBO> are you guys aware of the considerable stability issues many people are having with the feisty kernel?  (i dont mean to be offensive)
<DBO> also, thank you =)
<DBO> and if so can we expect a fix?
<mjg59> If there are bugs filed, then we're aware of them
<DBO> the problem is nobody knows how to file this one
<DBO> its just... "it hangs while in X"
<mjg59> Well, it's clearly not generic
<mjg59> So there'll be some degree of commonality
<DBO> there is a large thread on the forums about it
<DBO> nobody seems to be able to find it...
<DBO> nvidia, ati, intel all find it (so not video card)
<mjg59> If there's no commonality across all the reports, then it's unlikely to be the same bug
<mjg59> To a first approximation, computers are deterministic
<DBO> some people claim its the ralink, but I dont have that chipset... others find the -386 kernel
<DBO> thats the other weird thing
<DBO> there doesnt seem to be an obvious trigger for it
<DBO> I cant trigger it with any degree of consistency, nor can anyone else.  It just happens everywhere from 5 minutes to 6 hours after boot
<DBO> =/
<DBO> Im just worried it wont get fixed, so I figured I would come and ask
<mjg59> The only thing I can suggest is hooking up a serial console
<DBO> *looking to see if I got one*
<DBO> =/
<DBO> nope
<zdzichuBG> BTW, when is feisty kernel update planned?
<mjg59> No clue. Ben should know.
<zdzichuBG> thanks
<DBO> mjg59, is there any other way I can get the message from the kernel panic?
<DBO> I want to help... I'd mail you the machine if I could afford to lose it
<mjg59> DBO: Netconsole may be another option
<DBO> mjg59, would you like a link to the ubuntu forums thread on the matter so you can see what people are saying?
<mjg59> DBO: If you've summarised it recently, I'm afraid it's unlikely to be much help
<DBO> =/
<DBO> is there anyone else I should contact, or will filing an admittedly generic launchpad bug report be helpful?
<mjg59> Without any diagnostic information, without any indication as to what's triggering the problem and without any common drivers, then I'm afraid it's unlikely to be helpful
<DBO> last one then, would the gutsy kernel be worth a try? (provided I can swing getting the packaging to work without doing a full upgrade to gutsy)
<mjg59> It's certainly worth a go
<mariah>  I'm debugging a problem I've had with my Sony Laptop and the generic kernel. The machine runs really slow just after finishing initrd.
<mariah>  The i386 kernel doesn't do this.
<maks_> wow colors
<mariah>  Anyone familiar with initrd process in Ubuntu?
<maks_> maybe 
<maks_> mariah: this a dev channel the support is in #ubuntu afaik
<maks_> unless you are running latest g thing you should ask there
<maks_> also colors put people off usually :P
<mariah>  for kernel problems as well
<maks_> _support_
<mariah>  only if your english lol
<racarr> I keep on thinking you are pinging me. And wonder why I would be pinged in #ubuntu-kernel. Red color == bad choice.
<mariah>  especially from the north!
<Mithrandir> mariah: Please turn off colours.
<stgraber> racarr: switch back to a classical hilight color :), say yellow :)
<racarr> Well. It actually is yellow. But I used to use Konversation, which was red.
<mariah> No help there just a lot of noise
<mariah> So anyone here wish to assist me. This is a dev level issue.
<mariah> I'm probably going to need to modify the initrc.img
<mariah> Plus I turned of colors
<mjg59> mariah: Is there a bug number?
<mariah> I need to identify it as a bug 1st.
<mariah> You wish me to report something unvalidated?
<mjg59> If you install Ubuntu, does it work properly? If yes, it's not a bug. If it doesn't, it's a bug.
<BenC> part of a bug is the validation process
<mariah> I would like to be sure first rather then wasting others/my own time.
<mjg59> mariah: Dealing with a bug takes exactly the same amount of time as asking people here
<mariah> It isn't live
<mariah> Or is there another irc ch I'm not familiar with?
<mariah> normal ubuntu channel is very noisy right now. Lots of flooding going on.
<BenC> mariah: bug report
<mjg59> mariah: If the distribution doesn't work, then just file a bug report
<mariah> I can see this is going nowhere.
<mariah> Ok. Enjoy your talk about how you used Konversation which was red. I'm sure that is a dev issue.
<mjg59> mariah: If you haven't filed a bug, then I'll agree
<maks_> she left
<maks_> i guess ide-generic does nothing good for her
<maks_> but that is a wild guess
<BenC> rtg_, mjg59: I'm about to upload a -rc1 based kernel for gutsy with timer stats enabled
<maks_> BenC hmm i just wanted to check if fedora has timer stats enabled
<BenC> unless they have 2.6.21+, they wont
<BenC> have to have NO_HZ enabled too
<maks_> git-iwlwifi.patch
<maks_> sure they are 2.6.21 based, they always almost track latest
<maks_> yup enabled on -generic
<mjg59> BenC: Thanks
<mjg59> BenC: They do
<mjg59> Have NO_HZ, that is
<BenC> just NO_HZ alone improved my battery life noticably
<BenC> mjg59: is that ipw2200 patch upstream?
<mjg59> BenC: No
<mjg59> Also entirely untested
<BenC> ah, the powertop site seemed to make it sound golden :)
<mjg59> Haha
<mjg59> The ipw2100 one is tested
<mjg59> The 2200 one should be equivalent - Arjan was going to test it today
<BenC> ah, it is 2100
<mjg59> Oh, right
<mjg59> Ok
<mjg59> The only thing that should be done with the 2100 one is to release the IRQ on close and allocate it on open
<mjg59> Shouldn't make any difference
<mjg59> But slightly tidier
<mjg59> Also, there's a tidier version of the appletouch patch
<mjg59> http://www.codon.org.uk/~mjg59/tmp/appletouch.diff
<BenC> mjg59: would make my life a lot easier if these got sent to linus
<mjg59> No point in sending the ipw stuff until the Intel people ack them
<mjg59> Should get some progress with that today
<mjg59> appletouch has been sent to -input
<mjg59> Oh, and lkml
<BenC> I just today tainted my tree with source patches, but only to get rc1 out :)
<BenC> couple of one-liners for sparc
<mjg59> There's no point in me sending these direct to Linus, as far as I can tell - they're all going to have to go through the maintainer trees
<BenC> which probably means we've missed the window
<mjg59> Yeah
<rtg_> BenC: 2.6.22 is closed.
<BenC> well closed for major syncs, but not for fixes
<rtg_> right.
<BenC> IMO, some of these can be considered fixes
<rtg_> Since when does our opinion count :)
<BenC> saving my Li lifetime is a fix, IMO :)
<mjg59> Anyone here have a late-generation G4 Powerbook?
<mjg59> The ones that have USB touchpads
<Mithrandir> mjg59: cjwatson maybe?
<BenC> I have a 17: pb
<BenC> 17" I mean
<mjg59> BenC: USB input devices?
<BenC> I think, but I'd have to check
<mjg59> BenC: If so, I could do with you testing something :)
<mjg59> Basically, I need to know whether the first touch on the touchpad sends a button down event
<BenC> my wife has to go to a doctor appointment later, so there's a small point of opportunity to get it and install a small feisty partition :)
<BenC> fabbione: ping
<mjg59> Oh, and also spend some time figuring out whether it has the same behaviour as the geyser 3 does
<BenC> fabbione has the same PB I have
<mjg59> I'll sort a quick diff
<zul_> BenC: evil..my wife would kill me
<maks_> zul_ did you ever try?
<BenC> mjg59: are you going to take care of the hit list on linuxpowertop.org for the apps we have in gutsy?
<BenC> lot of patches we could probably user, I need to do the one I did for gaim against pidgin
<BenC> time to reboot
<BenC> uhci/ehci and ipw3945 are killing my battery :/
<zdzichuBG> usb is bad, but ipw?
<BenC> that's on an idle system
<BenC> probably network-manager doing scans
<zdzichuBG> or regulatory daemon doing voodoo
<zdzichuBG> maybe iwlwifi will be nicer
<mjg59> If you have a wireless interface up, it'll spew stuff for an extended period of time
<BenC> it's not reg daemon, it's definitely network-manager making it do bad stuff
<rtg_> How about the signal strength monitor?
<BenC> rtg_: that's network-daemon
<BenC> err, network-manager
<BenC>   42.4% (100.0)       <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5 
<BenC>   12.5% (29.4)       <interrupt> : ipw3945 
<BenC>    5.3% (12.6)      S20powernowd : queue_delayed_work_on (delayed_work_timer_fn) 
<BenC> I have no idea what the S20powernowd thing is
<mjg59> BenC: What hardware is this?
<mjg59> BenC: powernowd is due to ondemand waking up too often
<Mithrandir> S20powernowd is the cpufreq daemon
<mjg59> That's /supposed/ to be fixed in git
<BenC> mjg59: Dell XPS 1710, core2duo
<mjg59> BenC: Bluetooth?
<BenC> mjg59: yeah
<mjg59> If so, hciconfig hci0 down
<BenC> mjg59: wow, that killed half the wakeups, so most of uhci/ehci
<BenC> it's not even in my top 10 list anymore
<mjg59> We need to improve bluetooth in that respect
<BenC> definitely
<BenC> 40% of my wakeups come from ipw3945 now
<BenC> ondemand, mixer_applet2 and firefox seem to be the worst offenders now
<BenC> besides 3945 that is
<mjg59> I've uploaded fixes for mixer_applet2
<maks_>  20.8%        <interrupt> : i8042
<maks_> what's that biest?
<mjg59> maks_: You're moving the mouse or typing
<maks_> thanks mjg59
<mjg59> i8042 is the keyboard/mouse controller for ps/2 systems
<mjg59> BenC: How recently did you pull from Linus?
<maks_> update-notifier is also always shown
<BenC> this is -rc1
<maks_> 4.8%    update-notifier : schedule_timeout (process_timeout)
<mjg59> BenC: Hm.
<BenC> maks_: on a fresh boot, that probably means it is downloading updates
<BenC> or checking for them
<maks_> fresh boot since 30 min
<maks_> 0.42.12-3
<fabbione> BenC: pong
<BenC> fabbione: is your touchpad on your PB connected via USB?
<fabbione> BenC: yes like your
<mjg59> fabbione: Any chance you can test something for me at some point?
<fabbione> mjg59: can it be done on a LiveCD?
<mjg59> fabbione: No
<mjg59> (Well, yes, but I'll need you to build a kernel as well, so not really)
<fabbione> mjg59: then no.. sorry.. i removed Linux from this machine.
<mjg59> No problem
<BenC> guess I can test it later
<mjg59> Ok
<mjg59> I'll generate a diff shortly
<BenC> fabbione: thanks anyway fabio
<BenC> mjg59: have you done the mixer_applet2 10-HZ patch already?
<mjg59> BenC: 10-HZ?
<BenC> it has a 10hz timer
<mjg59> Oh, yes, that's gone
<BenC> guess I should selectively pull in some gutsy stuff
<mjg59> 2.18.0-3ubuntu2 and the latest gstreamer0.10-plugins-base
<fabbione> BenC: no problem at all
<BenC> -3ubuntu2 doesn't appear yet...but I did update ipw3945, so I'll check later if that helps
<mjg59> BenC: Yeah, gucharmap is fucked and has broken the build
<BenC> libnss appears kind of fucked too
<BenC> yay for merge weeks :)
<BenC> powertop is my new best friend though
<BenC> mjg59: Have you met our new guy Amit yet?
<mjg59> Nope
<BenC> he was at UDS, wont be starting for another month though
<rtg_> How do you get S20powernowd to slow down? Was that supposed to be fixed in -rc1?
<mjg59> rtg_: Just chatted to the cpufreq people
<BenC> he's got crap loads of power savings experience
<mjg59> rtg_: It's effectively a false positive
<mjg59> BenC: Surname?
<mjg59> rtg_: ondemand will opportunistically schedule whenever another interrupt appears
<BenC> Kucheria, but I may have mispelled it
<Amaranth> does the -2.7 kernel have the options on powertop needs or do i have to build myself?
<mjg59> Looks like he's done wireless hacking as well?
<BenC> mjg59: appears so
<mjg59> Sweet
<BenC> your search probably shows where he came from :)
<mjg59> Haha
<BenC> he met Keith(?) at UDS, and they are working on a power savings spec for gutsy
<BenC> revolves around this powertop thing, and getting patches in for stuff like gnome to aggregate timers (there's a kde patch that does the same there)
<mjg59> I'm fixing stuff that pops up here
<BenC> basically does the same thing for gnome that round_jiffies() does for the kernel
<mjg59> Yeah
<mjg59> I think glib support for that exists
<BenC>    3.3% ( 8.0)          modprobe : usb_hcd_poll_rh_status (rh_timer_func) 
<BenC> any idea what the hell that is?
<mjg59> USB host controller
<mjg59> Got any USB devices?
<mjg59> If so, and if they don't support runtime suspending, there'll be some housekeeping interrupts
<BenC> hard to say...I thought my keyboard and touchpad were...then I also have a usb mouse connected
<BenC> weird that it shows as modprobe
<mjg59> If it's a module, it'll show as whatever userspace task started it
<BenC> ah, gotcha
<mjg59> And yeah, if you have a USB mouse that'll do it
<mjg59> There should be some patches for runtime HID suspend appearing soon
<BenC> dhcdbd still has a 5hz timer
<mjg59> Yeah, need to chase Keith about a patch for that
<BenC> brb
<BenC> ok, ipw3945 is just horrible
<BenC> just loading the driver causes 16 wakeups/sec
<BenC> up/down leaves it doing 50-70/sec
<mjg59> I've just uploaded dhcdpd
<BenC> wonder why 3945 would need to do 16 interrupts/second when the iface hasn't even been brought up
<mjg59> Wouldn't surprise me if it's chatting to ipw3945d
<BenC> which would make it unfixable at this point :/
<BenC> should test iwlwifi see if that has the same issue
<BenC> I actually had it working at UDS, but always showed 100% for strength, and broke suspend
<mjg59> BenC: If you could test http://www.codon.org.uk/~mjg59/tmp/appletouch.diag.diff, that would be great
<mjg59> Two things I want to know: (1) does the first time you touch (not tap) the trackpad result in it printing an "Appletouch: button" message, and (2) when not touching it, does it generate "Received a packet" messages constantly?
<mjg59> The first time you touch being the very first time after loading the driver, that is
<BenC> mjg59: Ok, I'll let you know how it goes
<mjg59> BenC: Where does the ubuntu-modules tree live?
<BenC> until we get kernel.ubuntu.com, it's on rookery
<mjg59> Is it a public URL/
<mjg59> ?
<BenC> no, but I can tar it up real quick for you
<mjg59> That'd be good
<BenC> uploading to http://people.ubuntu.com/~bcollins/linux-ubuntu-modules-2.6.22.tar.gz
<BenC> give it about 2 minutes
<BenC> let me push ubuntu-gutsy.git while I'm at it
<BenC> all ready
<mjg59> Ta
<mjg59> Just updating the 945 machine
<mjg59> BenC: Have any of the 2.6.22-2 builds actually hit the archive?
<BenC> doesn't look like it
<mjg59> Ok, not just me then :)
<BenC> but it's about to be obsolete
<BenC> I'm about to upload -3 in less than an hour
<BenC> this should get us successful builds and lum/lrm/linux-meta close behind
<mjg59> Hey, I may finally have got gnome-applets uploaded successfully
<BenC> cool, got my first real vmcore
<mjg59> BenC: What's the right incantation to invoke the build with -j3?
<BenC> CONCURRENCY_LEVEL=3 fakeroot debian/rules binary-generic
<BenC> you can just export that too
<mjg59> Ah, cool
<Gadi> does anyone here know:  if a NIC module creates the NIC as "eth1_ifre" what is the problem?
<Gadi> the module in question here is e1000, but I'm not sure if the module is changing the name or a udev rule
<Gadi> as it appears that the device is unconfigurable
<BenC> Gadi: udev and ifrename
<BenC> Gadi: probably just want to edit /etc/iftab
<Gadi> can I edit iftab without specifying a dev by MAC - I want to use this OS image cloned on multiple machines
<stgraber> Gadi: you can keep it empty, this way the interface names will be the order of detection
<Gadi> great
<Gadi> thx
#ubuntu-kernel 2007-05-15
<DBO> BenC, just a follow up on what we talked about yesterday.  In a spurt of amazingly horrible luck... its not panicing...
<BenC> lol
<DBO> if I didnt have bad luck, I wouldnt have any
<DBO> Im sure it will go eventually, when I first installed I went about 3 days before it started locking
<BenC> Ok, just let me know when :)
<crimsun> is this the snd-pcm-oss freeze, or...?
<DBO> no
<crimsun> ok.
<DBO> its a more generic issue, im sorry I been running in circles
<DBO> to be honest crimsun, I am getting very frustrated, but I want to thank you for the help you provided earlier.  We are using kexec tools (with bens help) to fiqure out the exact cause of the panic now.  Only thing is... its not doing it...
<DBO> Sods law
* Starting logfile irclogs/ubuntu-kernel.log
<flukebox_> hi
<flukebox_> anybody here ??
<dade`> BenC: i think that the gutsy kernel sould have CONFIG_TIMER_STATS enabled by default
<dade`> to use linuxpowertop
<elmarco> I have a T60, when I dock it, the serial interface (ttyS0) is not working anymore 
<elmarco> should I file a bug in kernel.org, or launchpad?
<elmarco> or is it a non-bug?
<elmarco> (dock/undock)
* elmarco +1 for dade` comment
<maks_> mjg59 if you have an ipw2200 patch i can test it on my x41
<maks_> preferably against 2.6.21, but otherwise fine too
<Keybuk> http://linux-ata.org/shutdown.html
<Keybuk> ^ so that explains *those* bgs
<kylem> yeah.
<kylem> grumble.
<kylem> want me to fix upstart?
<Keybuk> nah, it's ok, I'll tackle it -- I want to sort out the ide bits while in there
<Keybuk> actually, this description is wrong, so I'm going to write to the author
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-3.9 | Latest news: -rt and -xen kernels removed, failures in patch. Linux-meta coming today.
<Keybuk> kylem: could I borrow you for a moment
<kylem> ys.
<Keybuk> so, ide_device_shutdown()
<Keybuk> this is called during the reboot() syscall, right?
<kylem> looks like it.
<Keybuk> kernel_power_off -> kernel_shutdown_prepare -> device_shutdown -> *.shutdown -> ide_device_shutdown
<Keybuk> this would appear to just flush the cache on everything except power off
<Keybuk> for power off, it calls suspend() on the bus? is that right?
<kylem> hrm.
<kylem> looks like it, yeah.
<Keybuk> that would appear to be generic_ide_suspend()
<Keybuk> which pushes the state machine into flushing the cache and powering down the drive
<Keybuk> kylem: have mailed linux-ide, that page is particularly unclear to me
<Keybuk> it seems to refer to workarounds that other distros (not us) have done
<Keybuk> and penalises us for never having broken things in the first place
* kylem nods.
<Keybuk> at least that explains the clicking noise bugs we've had for ages
<Keybuk> (for the ide subsystem, not libata:
<kylem> yup.
<Keybuk>  - reboot standbys the drive
<Keybuk>  - calls reboot()
<Keybuk>  - which flushes the cache, spinning the drive back up
<Keybuk>  - and standbys the drive again
<Keybuk> )
<Keybuk> it doesn't explain why we should have to touch libata, since we never tried anything with those
<Keybuk> and since I'm going to have to write code for libata, allegedly, I'd rather get an answer *why* we have to, if there's code to be written, it's just as easy to write it in the kernel
<BenC> Keybuk: but it would be specific to our kernel :/
<BenC> since they obviously know they can't put the real fix in the kernel because other distros already fucked up, it means we'll be carrying around a patch just for us
<Keybuk> actually, I mean for the case where halt/reboot still apparently has to issue the commands on a per-disk/driver basis
<Keybuk> if it's "a few drivers haven't been fixed yet", then it's easier for us to fix those drivers than halt/reboot, no?
<BenC> ah, true
* Keybuk has no problem writing 0 to compat_shutdown, and not *needing* any code in halt/reboot
<Keybuk> my concern is that even after writing 0, I might need that code
<Keybuk> and since I'll have to write that code, is there more useful code I could write instead?
<ogra> BenC, i did some measurements for the ltsp slowness comparing tcp and udp based nfsroot ... and found very intresting numbers ... 
<BenC> ogra: udp is faster?
<ogra> would you agree that udp should be faster ? 
<BenC> I would think so, but depends I guess
<ogra> using the classmate as client:
<ogra> udp 10.9M/s , real: 9.420s
<ogra> tcp 11.6M/s , real: 8.887s
<ogra> using the slow e2300 jim tested with as client:
<ogra> udp 2.4M/s , real: 42.763s
<ogra> tcp 3.6M/s , real: 28.656s
<mjg59> This is on 100MBit?
<BenC> wow
<ogra> thats always dding a 100M file from the nfsroot to /dev/null
<ogra> mjg59, yep, a gigabit card in my lappie which acts as server dmegs tells me it negotiates 100M FD
<BenC> so it's a direct cable too, no switch/hub?
<kylem> nfs sucks, news at 11.
<mjg59> I think the classmate figures are close enough together for the difference not to be terribly meaningful
<ogra> i would expect some significat difference between udp and tcp
<mjg59> On a duplex connection?
<ogra> yeah
<mjg59> Why? The overhead isn't going to be that great
<BenC> I think the more important numbers are the 2.4M/s on the e2300 compared to the 10.9M/s on the classmate :)
<mjg59> The e2300 figures are much more interesting
<ogra> hmm, but udp is even slower .... i would expect a connectionless thing to be always faster
<mjg59> ogra: On the Classmate, the figures are close enough that they're probably effectively identical
<ogra> well, the e2300 has a 200Mhz CPU
<ogra> the classmate is a celeron 900
<ogra> *celeron M
<mjg59> The Classmate is clearly limited by the network
<ogra> yeah
<mjg59> The question is what the limiting factor on the e2300 is
<mjg59> What does top look like during that?
<ogra> where ? on the server 
<ogra> i cant run top wile booting
<ogra> *while
<ogra> (on the client)
<mjg59> You're dding a file
<mjg59> To /dev/null
<mjg59> If you can do that, you can run top :)
<ogra> ah, that yeah
<ogra> indeed, i'm into bootspeeds etm, sorry
<ogra> *atm
<ogra> let me reboot to get to a shell ... 
<ogra> takes 3 min ...
<ogra> oh, btw i'm using busybox mount for udp atm as opposed to klibc nfsmount for tcp ...
<mjg59> Should make no difference
<ogra> dd takes 90% CPU
<ogra> 95 now
<ogra> 3% for rpciod
<ogra> intrestingly i also seem to get no caching ... running the dd command a second time should give faster results, no ?
<mjg59> Not if the file is approximately all your memory, no...
<ogra> well i have 128M
<ogra> oh, wait
<ogra> why does top only show 64 ?
<ogra> hmm
<mjg59> ...
* ogra looks in the BIOS
<ogra> ok, 64M videoram and 64M shared mem ...
<ogra> switched that to 8M each
<ogra> ok, that looks different ... 118M now
<ogra> ok, caching seems to work ....
<ogra> dropped from 24 sec to 12
<ogra> on the second run
<BenC> ogra: oooh...64Megs of mem, that'll do it
<BenC> I accidentally booted to gnome desktop with 64Megs of mem while doing kdump stuff
<BenC> was horrible
<ogra> well, it didnt help much
<ogra> still 24sec for that file 
<ogra> and still 3min bootimes
<ogra> 3min+
<ogra> while ltsp 4.2 stays below a minute
<mjg59> ogra: And top while dding it (for the first time, avoiding caching)?
<BenC> 4.2 is the one that doesn't do nfsroot, but does nfsmount and symlinks, right?
<ogra> dd eats all CPU it can
<ogra> BenC, right, we tried that in our initramfs ... smae results
<mjg59> Ok. So you're CPU limited, not network limited.
<ogra> right
<mjg59> Can you try an older kernel?
<ogra> but there is still that significant difference between 4.2 and 5
<ogra> yeah
<mjg59> Try the 4.2 kernel
<ogra> i tried the edgy one already (4.2 uses 2.6.18) 
<mjg59> And?
<ogra> no difference
<mjg59> Then this would seem to be the wrong place to be bringing the issue up :)
<ogra> no difference between our kernels i mean
<mjg59> And with the LTSP kernel?
<Mithrandir> have you tried ltsp 4.2 with the feisty kernel too?
<ogra> not yet
<ogra> i'll poke around with both today ... but clearly something is different with our nfsroot ...
<ogra> debians kernel isnt much faster btw
<Mithrandir> all this is pointing towards this being a userspace problem, then.
<ogra> we tried their chroot as well
<mjg59> Either there's a difference between the ltsp 4.2 kernel and our kernel
<ogra> well, i thought i found the magic bullet when i saw the 4.2 is only faking nfsroot with tmpfses ... but that didnt change anything for us
<mjg59> Or it's a userspace issue
<ogra> hmm
<mjg59> So, test performance with the 4.2 kernel
<ogra> will do
<mjg59> If it's three times better, then we have a kernel issue
<mjg59> If not, it sounds like a userspace one
<ogra> ok
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-3.9 | Latest news: -rt and -xen kernels removed, failures in patch. Linux-meta coming today. | Kernel Team meeting in #ubuntu-meeting, today at 16:00 UTC
<zul> BenC: whats on the agenda?
<BenC> basically just recap of UDS
<zul> cool
<ogra> oh, i just noticed ... CPU: Vendor unknown using generic init ....
<ogra> but according to jammcq that shows up in 4.2 as well
<maks_> BenC: do you disable CONFIG_IRQBALANCE ?
<maks_> "The in-kernel irq balancer is obsolete and wakes the CPU up far more than needed."
<maks_> says powertop
<BenC> disabled in last kernel upload
<maks_> thanks for info :)
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-3.9 | Latest news: -rt and -xen kernels removed, failures in patch. Linux-meta coming today. | Kernel Team meeting in #ubuntu-meeting, today at 15:00 UTC
<BenC> sorry for time change, meeting is scheduled for 1 minute from now
<zul_> ack..
<Mithrandir> UTC is hard. :-P
<racarr> I'm even more confused by the fact that it's supposed to be a kernel meeting but they seem to be confirming new members.
<zul> well obviously its not a kernel meeting just yet
<Mithrandir> it's because the previous meeting used too much time
<Mithrandir> they're rounding up now
<maks_> heya
<BenC> everyone here that needs to be?
<BenC> pkl_, rtg, kylem, cjwatson, zul: ping?
<zul> yep
<pkl_> BenC: here
<rtg> BenC: hmm?
<BenC> Ok, so basically this meeting was just to go over some things from UDS
<BenC> I'm late getting a real agenda up, so please bare with me
<BenC> Some of the topics we discussed at UDS (and kernel team, feel free to plug things I forgot):
<BenC> * Wireless
<BenC> * Power savings
<BenC> * Ceashdumps
<BenC> crashdumps I mean
<BenC> * Ubuntu Mobile and Embedded
<BenC> * Virtualization (lightly)
<BenC> So we'll go from the top
<BenC> rtg: do you want to give us a summary of wireless stuff?
<rtg> I spent a day with Luis Rodriguez, Marcel Holtmann, and Anaky Perez Gonsales designing a frequency broker.
<rtg> Also much activity regarding software designed radios and regulatory compliance.
<BenC> that's the one announced to kernel-team@ that I've still to read :)
<rtg> mac80211 development is proceeding briskly.
<rtg> I', lookingat adding support for ntl80211 in wpa_supplicant.
<rtg> I guess thats the big 3 items for me.
<BenC> Sounds good
<rtg> thats all...
<BenC> I know Luis said that mac80211 in 2.6.22 isn't doing to be complete, but I was able to compile iwlwifi against it without problems (except an sk_buff change)
<rtg> I haven't quite figured out how to actually use it. 
<rtg> That was why I got distracted by wpa_supplicant 
<BenC> Might be some docs on it somewhere
<rtg> Its in the source :)
<BenC> Ok, power savings, unfortunately Amit isn't with us yet
<BenC> But we now have NO_HZ in the kernel, and TIMER_STATS, so we are able to use powertop to see what is waking up our CPU so much
<BenC> mjg59 is already working on getting patches into userspace programs which heavily show up in powertop output
<BenC> we have some drivers on the hitlist too, so we'll be addressing that during gutsy cycle
<maks_> bluetooth is really bad afais
<BenC> yeah, it's the worst offender on my laptop
<pkl_> there was some discussion of various patches to glibc and other user-land libraries to aggregate timer ticks.
<BenC> and ipw3945 follows behind it
<BenC> pkl_: gnome is the main one, from what I can tell
<BenC> not sure if it makes sense to patch up sleep in glibc to aggregate things
<BenC> there's a spec for all this, so we can add the main issues in there
<pkl_> there seems to be couple of patches floating around doing the samething, but diferently.
<rtg> Intel has some kernel patches that also consolidate wakeups.
<BenC> yeah, we'll be checking into those as well
<rtg> http://www.linuxpowertop.org/powertop.php
<BenC> gutsy should be a nice release for laptops, and we'll probably add powertop to our normal testing to keep from having regressions on stock desktops
<rtg> I believe you referred to gutsy as 'a laptop users wet dream' :)
<BenC> yes, that's a direct quote :)
<BenC> Ok, crashdumps...
<BenC> I've uploaded a kexec-tools that includes an init script and an initramfs script to actually grab vmcore on dumps
<maks_> i'd be interested in merging that
<BenC> I plan on making a simple linux-crashdump-{generic,server,...} meta package to install all the right things (kexec-tools, linux-debug-image, etc) and automatically setup grub menu to do all this
<BenC> maks_: remind me and I'll send you the scripts
<BenC> So the only stopper right now is that the crash program cannot process 2.6.22 vmcore's
<maks_> ok will do, thanks
<BenC> but I expect that will come as 2.6.22 gets closer to release
<BenC> I want it sooner, so we can actually make use of it though
<BenC> probably work on patching crash soon
<BenC> Martin(pitti) is working on apport integration so we get nice automated bugs from vmcore dumps
<BenC> and with crash we can analyze bugs that before we couldn't even see (panic's during X that locked up the system)
<BenC> Ubuntu MaE, not a lot of discussion for this in regards to the kernel
<BenC> we're going to have a special kernel just for this project, and will be mostly integrating patches for drivers and optimizations
<BenC> * Virtualization, seems to be no better than it was in feisty
<BenC> zul: any word on xen+2.6.22?
<BenC> I'd be happy with just domU support, especially since we have a bug that says even the one kernel where xen existed, didn't support being booted as dom0 anyway :)
<zul> BenC: updating it to xen-3.1 is going slowly, dumped suse's patch in favour of redhat's again
<zul> as usual its going slowly again,
<zul> oh and someone else will probbaly need to take care of openvz or I will suffer a nervous breakdown
<BenC> I know your quite busy nowadays, perhaps checking the lists for help would be a good idea?
<zul> yep already talking to the redhat folks
<BenC> openvz we'll be leaving to openvz, so don't worry about that
<zul> sweet
<BenC> zul: there has to be some ubuntu users that are interested in xen...maybe try the ubuntu devel or kernel-team lists?
<zul> sure Ill do that when I get home
<BenC> I know we have vendors interested in xen on our lists, so maybe they can pitch in
<BenC> I could give you a list of ones, but I think it's best they speak for themselves :)
<zul> heh...actually im talking to quintela right now
<BenC> that's the end of my list...any additional topics anyone wanted to bring up
<BenC> ?
<zul> he is the redhat xen kernel maintainer
<BenC> cool
<zdzichuBG> when feisty kernel update is planned?
<BenC> good question
<BenC> pkl_: how's feisty looking for an upload?
<BenC> pkl_: could you send the current output of "debian/rules printchanges" to kernel-team for review?
<pkl_> good, I just need to get someone to test the latest patch tifm driver
<Keybuk> kylem: we win
<pkl_> yeah, there's mostly security and sparc changes.
<BenC> could probably do a i386 -generic build for the folks on the tifm bug report
<zdzichuBG> pkl_: thinkpad sound after suspend bug?
<BenC> pkl_: did the kvm changes in latest git get reverted to match the released kernel?
<BenC> zdzichuBG: is there a patch?
<pkl_> BenC: yes
<zdzichuBG> BenC: yes, and testes kernels: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/80893
<BenC> pkl_: ok, do you know if current feisty git has an ABI change or not?
<Keybuk> http://article.gmane.org/gmane.linux.ide/18846
<pkl_> yes, ABI bumped
<BenC> zdzichuBG: since you're interested, can you post the patch to kernel-team@, and CC Phillip Lougher <phillip.lougher@ubuntu.com>?
<pkl_> one of the security patches, can't remember which one off-hand
<BenC> pkl_: Ok...let's get the tifm thing tested asap, get an upload ready, and we'll do some builds for a first round of testing with distro folks
<pkl_> OK.
<zdzichuBG> BenC: will do
<BenC> zdzichuBG: it wont make this upload, but we'll see about queuing it up for next one, or -updates
<pkl_> I was looking into a Unionfs bug, but is not urgent.
<BenC> Any other issues to speak of?
<pkl_> this indirectly affects whether we go for Unionfs 2.x or Unionfs 1.x in Gutsy.
<pkl_> nope.
<BenC> Ok, thanks everyone
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-3.9 | Latest news: -rt and -xen kernels removed, failures in patch. Linux-meta coming today.
<Keybuk> oops, sorry for interrupting the meting there
<BenC> Keybuk: np, we had to move from #ubuntu-meeting because CC meeting ran long
<maks_> BenC i've some initramfs-tools fixes that might be interesting to sync
<maks_> i'll ping you once 0.88 is fine in sid
<BenC> maks_: ok
<BenC> pkl_: if you could look at the unionfs I have in linux-ubuntu-modules-2.6.22, and let me know if it's suitable for at least our livecd, I'd appreciate it
<BenC> it's 1.x
<Keybuk> BenC: so, the good news is, remember we talked about the whole ide spin down thing?
<Keybuk> well, the ide subsystem is right by default - we can drop the scary ioctl shit from /sbin/reboot
<BenC> Keybuk: yeah, I read the backlog with kyle
<Keybuk> and the libata subsystem is in the process of being fixed; and it turns out we're getting it fixed better than the patch in 22-rc1
<BenC> so 2.6.22 will be good?
<Keybuk> currently there's an odd compat_shutdown patch in there, which requires us to update shutdown, blah blah blah
<Keybuk> all this to not break one or two distros that tried to shutdown libata stuff in /sbin/halt/reboot
<Keybuk> so the author is reworking the patch to favour distros like us by default that never broke things in the first place
<Keybuk> yup, looks like 22 will be sweet
<Keybuk> our /sbin/reboot can be a wrapper around reboot() :p
<BenC> nice, I can mark the "my hd makes a horrid noise on shutdown" fixed in gutsy
<Keybuk> it makes a nice "drive head thunking against the side of the can" noise? :p
<BenC> yeah, some reporters even claim it flicks their laptops off the table ;)
<Keybuk> I suspect they may be exaggerating a little
<Keybuk> for my next mission, I will attempt to find out whether sync() is needed or not <g>
<heno> random question: How many modules do we ship and how many of those are not in Linus' tree?
<mjg59> Many, lots
<heno> 10, 50, 100?
<BenC> heno: for x86, stock kernel is about 1900 modules
<mjg59> heno: find /lib/modules/`uname -r`/kernel | wc
<mjg59> will give you the total number
<mjg59> find /lib/modules/`uname-r`/kernel/ubuntu | wc
<heno> ok, thanks
<BenC> heno: we provide about 20
<mjg59> will give you the ubuntu specific count
<BenC> -type f might be a good idea there
<BenC> lots of directories :)
<mjg59> Oh, yeah
<smurf> or even "-name \*.ko"
<mjg59> BenC: I still make it 80 or so that we provide
<heno> (I'm having a discussion about the removal of speakup on a list)
<mjg59> Though several of those are conceptually linked
<mjg59> Oh, not as many in gutsy
<BenC> speakup is a good chunk there
<mjg59> (so far)
<heno> any idea how many of those are  from far outside the most common trees?
<heno> (Linus and 2-3 others)
<BenC> heno: a good chunk for modules we provided in feisty wont show up in gutsy because they are either obsolete, or crap
<BenC> a lot of the wireless modules we provided in feisty we're to gain mac80211 features
<heno> right, so it's a common life cycle for good features to actually go into mainline eventually
<BenC> oh, definitely
<BenC> there's a lot of overhead in maintaining those out-of-tree
<heno> Are they often pushed in by us, or more often by other kernel folks?
<mjg59> Other people, usually
<mjg59> And there's some stuff we ship that's never going mainline in its current form
<BenC> very rarely by us, where us is Ubuntu
<mjg59> Like that gspca or whatever webcam monstrosity
<BenC> right, and ndiswrapper
<heno> right, I see the pattern, thanks
<isidoro> hi
<isidoro> sorry guys... help I can't mount my usb NTFS disk. I installed ntfs-config but a gnome pop up says mount_point cannot contain the following characters, newline G_DIR_SEPARATOR (usually /)
<BenC> isidoro: sounds like your NTFS partitions has '/' in it's label name
<BenC> relabel it
* Keybuk wonders what happens if you don't sync() before reboot()
<Keybuk> I can't see any explicit call for that in the kernel code yet
<isidor1> BenC: can I force in some way the mount via shell??
<BenC> isidor1: sure, use the mount command :)
<isidor1> BenC: can you post it form me?
<BenC> mount /dev/XXX /mnt
<BenC> XXX all depends on what device it is
<isidor1> sudo mount /dev/sdb1 /home/usbdisk
<isidor1> says it not exsist
<isidor1> impossibile trovare /dev/sdc in /etc/fstab o /etc/mtab
<isidor1> impossibile find
<isidor1> dmesg says sd 3:0:0:0: Attached scsi generic sg4 type 0
<Keybuk> ...bad things; important lesson learned
<isidor1> ?
<isidor1> :-(
<isidor1> what can I do???
<mjg59> isidor1: #ubuntu is a much better place to ask this
<mjg59> This isn't a support channel
<isidoro> guys fixed!
<isidoro> google is really a great friend
<zul> BenC: I got a vanilla 2.6.21 booting with xen-3.1 ill start merging in 2.6.22-rc1 tonight
<BenC> ok
* BenC uploads pain and suffering
<BenC> I mean linux-meta
* ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-3.9 | Latest news: -rt and -xen kernels removed, failures in patch | linux-meta uploaded for gutsy 2.6.22 kernels.
<Spec> What's the ETA for fixing a bug like this: BUG #90902
<Spec> oh, ubugtu isn't here, well, that bug is just a wrong version of firmware bug and it's basically fixed, is there anything i can do to speed along the fix?
<defendguin> BenC, you got a moment?
<BenC> defendguin: sure
<defendguin> could you look at this bug someone submitted https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/114312
<defendguin> I have this laptop and obviously i'm concerned but i have been using feisty since herd 3 and i have not noticed any fan or overheating issues
<BenC> the bug report needs dmesg, and output from cat /proc/acpi/thermal_zone/*/temperature
<BenC> until then it's just hand waving
<defendguin> right
<defendguin> would you like me to note that in the ticket?
<BenC> yes, please
<defendguin> Thanks Ben
<BenC> np
<defendguin> this guy also reported his thinkpad was over heating
<defendguin> maybe he just needs to turn on the AC
<BenC> or find a better place than his stove to work from
<defendguin> oh nevermind i guess he just posted to the end of a different ticket the same issue
#ubuntu-kernel 2007-05-16
<defendguin> BenC: do you know what the typical operating temperature of a intel dual core processor is?
<BenC> defendguin: mine shows 44C
<BenC> it's pretty idle though
<defendguin> how many mhz?
<defendguin> its clocking down to 1ghz or 800mhz?
<defendguin> BenC: how should i record this?   i opened up this friend of mine's myspace page with about 50 slide shows and it gets the processor up half way and sends both cores to full speed and the fan begins to kick in and blow some air out of the side of the laptop and the temp gets up to about 71 degrees 
<BenC> it's a 1.8Ghz
<BenC> so it's probably clocking down to 1
<BenC> defendguin: sounds like you can blame firefox...not sure if that's a bug
<defendguin> i blame my friend
<defendguin> the page is hideous 
<JanC> IIRC those CPUs are safe up to 100 C or something?
<defendguin> i have no idea
<JanC> maybe not really good for CPU lifetime though  :)
<defendguin> but it certainly seems like the fan is whirring and working properly
<JanC> depends on where you measure too of course
<defendguin> BenC: i guess this guy just has different hardware because the fan seems to be very responsive to the processor here.  Anywhere from silent at idle to noticeable when the processor was being used heavily 
<defendguin> BenC: the guy pretty much gets the same results as me temp wise.   is 49C really too hot for a mostly idle processor?
<BenC> not really
<defendguin> i guess i could boot back into edgy and see if it is the same
<defendguin> damn i guess i remove those options from grub :-(
<defendguin> I am reading the technical specifications and typically they use a range of anywhere between 50 and 100C in these documents 
<defendguin> any time they list anything below that the processor is in one of several sleep states
<BenC> defendguin: sounds like a non-bug to me then
<BenC> defendguin: I can get mine up to 75C doing a compile
<BenC> then there's this:
<BenC> critical (S5):           126 C
<BenC> if critical trip point (instant power off) is 126C, then 70, even 80, doesn't sound so bad
<Amaranth> 75C? damn, i get to 88C
<panduwana> hello, i'm new, is there any tutorial about making kernel module for ubuntu?
<BenC> panduwana: you really want #ubuntu
<panduwana> oh ok sorry
<Ivan_> probably an annoying questions by now, but ps3 wifi, how?
<BenC> Ivan_: not
<BenC> only ethernet is supported on ps3
<BenC> otherwise use a USB wireless dongle supported by linux
<mjg59> BenC: Hm. So, we're almost certainly going to want the code to forcible enable the HPET on ICH systems
<mjg59> Which is, unfortunately, unlikely to make it in for .22
<mjg59> But we should have what's approximately the final patch before then
<BenC> mjg59: Ok
<mjg59> So I don't think it's going to be a long term merge issue, but it may represent a divergence from upstream
<mjg59> The issue is that the PIT has a minimum useful tick rate of around 40Hz, but there's the potential for us to get lower than that
<mjg59> So HPET is useful, and most hardware from the past couple of years supports it. But BIOSes didn't start turning it on until fairly recently
<mjg59> So it's a potentially very useful patch for power conservationm
<BenC> Sounds useful, definitely give it a good once over
<mjg59> Right. There's a possible suspend regression at the moment, which is why I'm not pushing it right now
<mjg59> I'll see if I can find hardware to duplicate it on
<mjg59> But then, I get the feeling that there may be regressions in that field in .22 in general right now, so...
<BenC> mjg59: how big is the patch?
<mjg59> Erm.
<mjg59> Hang on a sec...
<mjg59> 14K
<Amaranth> lines or file size?
<mjg59> File size
<mjg59> 540 lines of diff (including context and headers)
<mjg59> So not really /too/ bad
<mjg59> It is, irritatingly, more of an hpet update rather than just the force-enabling
<mjg59> But large parts of it are tied together
<BenC> mjg59: any chance the hpet update gets into 2.6.22? :)
<mjg59> Doesn't seem likely
<mjg59> I've been talking to upstream about it
<Edulix> hi
<Edulix> I compiled my own ubuntu kernel, it was linux-source-2.6.22_2.6.22-2.7.tar.gz
<Edulix> but it created 2.6.21 packages! how's that? wasn't it a 2.6.22? I'm confused
<farion> can someone explain me, howto compile the source of linux-ubuntu-modules-2.6.22?
<BenC> farion: sudo apt-get build-dep linux-ubuntu-modules-2.6.22; apt-get -b source linux-ubuntu-modules-2.6.22
<farion> BenC: Okay, thx i'll try
<ogra> BenC, i did the initramfs measurements -ltsp vs. -i386 ... -ltsp is finishing 11secs faster if i add a break=bottom ...
<BenC> ogra: so from pxe finish to busybox is 11 seconds different?
<ogra> yep
<ogra> we take 55sec they 44
<BenC> what about break=top?
<ogra> i'll try with break top as well
<ogra> hee beaten me
<ogra> *heh
<BenC> hehe
<BenC> would be nice to know how much of that is initial kernel and how much is driver loading and initramfs scripts
<ogra> yep
<BenC> maybe take out the hibernate script in initramfs...you guys don't need that, right?
<ogra> im not a big fan of stopwatching though ... 
<BenC> hehe
<ogra> right
<Mithrandir> you should just install bootchart and work from that.
<ogra> Mithrandir, well, jammcq refuses to use bootchart ... and on this 200Mhz client it takes nearly 1h to generate the final image ... 
<ogra> to keep some consistency with the ltsp guis i resrted to use their "hit powerbutton and stopwatch" method for now
<mjg59> 11 seconds seems like a fairly irrelevant difference when the complaint is an extra three minutes
<ogra> *guys
<ogra> yeah
<ogra> it is
<Mithrandir> ogra: just copying the tar.gz somewhere else and generating the image there should work fine.
<ogra> sadly we have many of these 11 seconds in various places ... it stacks up
<ogra> break top gives me 32secs for i386 and 23 sec for -ltsp
<ogra> so their vmlinuz is already faster
<maks_> well non-generic kernel
<BenC> our vmlinuz should be pretty stripped down
<BenC> what kernel is ltsp's?
<zul> gah...I dislike it when things change
<mjg59> ogra: That accounts for almost the entirity of the 11 seconds, so if you want to reduce it that's clearly what you should be looking at. However, it's still going to make almost no difference overall. 
<ogra> yeah
<ogra> i'm still trying to find the big switch i just need to flip to loose 2mins
<mjg59> ogra: If you want to actually improve things, I think yo're going to have to figure out why stuff is actually slower. Did you do the NFS benchmarking with an ltsp kernel?
<ogra> but it seems its just the stacked up amount of all these little things
<ogra> yes, no big difference
<ogra> one thing i assume will make a big difference is to use the ltsp initramfs script ... but thats to hackish that i even want to think about using it 
<ogra> instead of a real nfsroot they use tmpfses and load all stuff into ram before going on with booting the real thing
<ogra> so the actual bootsequence is done from ram ... not from the nfsroot
<mjg59> So they transfer over a large file and then run from that?
<ogra> the create tmpfses and move or bind mount particular nfs dirs into that
<ogra> we do the same to gain rw access to crtain files on the readonly nfsroot ... but only in the booting system, not in the initramfs
<BenC> well the initramfs is alreayd all in ram
<mjg59> Right, but where are the binaries that they're actually executing?
<BenC> doesn't read much from the nfsmount as far as I know
<ogra> no, we just plainly mount / 
<ogra> http://www.mcquillansystems.com/init.txt
<ogra> thats their initramfs creator script
<mjg59> ogra: That doesn't give a lot of insight
<mjg59> But by the looks of it, the binaries they execute still come from the nfs mount, right?
<ogra> right
<mjg59> So I can't see why that would make any difference to startup times
<ogra> ah, sorry, they dont bindmount, they link
<mjg59> The only obvious difference is that their /tmp is on tmpfs
<mjg59> Where does /tmp come from on the edubuntu systems?
<ogra> ours as well, but later in the loop
<ogra> from ltsp-client-setup, the firt initscript we run on ltsp clients
<ogra> *first
<ogra> which bind mounts various other stuff to ram as well
<mjg59> Ok. So in that case, I can't see any reason why that would explain any speed differences
<ogra> but only wih the writeabilty in mind, no speed thoughts involved
<ogra> well, their stuff is earlier in ram than ours thats the only difference i see 
<ogra> if you access anything the second ime you might be lucky to get it from ram instead of the nfsroot
<mjg59> ?
<mjg59> It doesn't execute anything from ram
<ogra> if your /bin is on a ramdisk ? 
<mjg59> It's not!
<mjg59>  /bin is just a symlink into an NFS mount
<ogra> hmm
<ogra> right
<ogra> you would have to copy it instead ... which would slow down even more ... weird ...
<farion> howto do i recompile my ubuntu standardkernel - i only want to change two items?
<ogra> i'm really runing out of ideas wher else to look
<mjg59> farion: This isn't a support channel - #ubuntu is a better place to ask questions like that
<lamont> 09:25:18.548890 IP 15.238.4.198.42014 > 10.0.0.2.80: S 4194244240:4194244240(0) win 5840 <mss 1460,sackOK,timestamp 93976 0,nop,wscale 5>
<lamont> 09:25:18.549337 IP 10.0.0.2.80 > 15.238.4.198.42014: S 1534251669:1534251669(0) ack 4194244241 win 5792 <mss 1460,sackOK,timestamp 833213942 93976,nop,wscale 7>
<lamont> 09:25:18.549382 IP 15.238.4.198.42014 > 10.0.0.2.80: . ack 1 win 183 <nop,nop,timestamp 93976 833213942>
<lamont> so why do we pick a window size of 183??
<lamont> and then why does the far side send 638 octets of data to that 183 window?
<BenC> Anyone have any thoughts on enabling SLUB vs SLAB in gutsy?
<BenC> I've been reading it, and it actually fixes some bugs, so I'm considering it for next upload
<BenC> http://lwn.net/Articles/229096/ in case anyone wants to read up on it
<lamont> any reason I can't run a gutsy kernel on a feisty box?
<lamont> BenC: any chance you have a machine with the current top-of-tree kernel on it?
<BenC> yeah
<BenC> lamont: you can run gutsy kernel on feisty...I am
<BenC> in fact, I'm running it on edgy in a few places too
<lamont> could you capture the 3-way handshake for a wget of some random web page for me?
<lamont> tcpdump, that is
<lamont> BenC: rebuilt, or just drop the deb in and go?
<BenC> if you can give me commands, I can do that
<BenC> lamont: dpkg -i, and reboot
<lamont> tcpdump -ni eth0 host 64.233.167.99
<lamont> and in another window: wget 64.233.167.99
<BenC> lamont: nvidia/fglrx support is a different story
<lamont> then grab the first 3 lines of output
<lamont> specifically, I'm looking at the number after 'win' :)
<BenC> lamont:  does it matter than I'm behind a firewall?
<lamont> 01:00.0 VGA compatible controller: nVidia Corporation NV25GL [Quadro4 900 XGL]  (rev a3)
<lamont> no matter
* lamont is running stock kernel/etc - haven't  played with getting fglrx working better or such
<lamont> so as long as it stll works, no 3d/etc is fine
<BenC> yeah, it'll still work
<BenC> 12:19:33.762854 IP 192.168.1.130.59038 > 64.233.167.99.80: S 2512816493:2512816493(0) win 5840 <mss 1460,sackOK,timestamp 36801128 0,nop,wscale 7>
<BenC> 12:19:33.799159 IP 64.233.167.99.80 > 192.168.1.130.59038: S 2499560590:2499560590(0) ack 2512816494 win 8190 <mss 1460>
<BenC> 12:19:33.799215 IP 192.168.1.130.59038 > 64.233.167.99.80: . ack 1 win 5840
<BenC> this is stock 2.6.22-rc1
<BenC> well, it's gutsy kernel, but it's stock
<lamont> 10:20:43.051400 IP 15.238.4.198.44514 > 64.233.167.99.80: . ack 1 win 183 <nop,nop,timestamp 426415 23137170>
<lamont> that's the feisty kernel
<lamont> note the tcp receive window size of 183...
<lamont> whatever fixed that bug would be good to get back into feisty
<BenC> could be affected by sysctl stuff
<lamont> 'twould make my coworkers happy
<lamont> mine started with a window of 5840 as well
<lamont> it just drops dramatically on the final ack
<BenC> what win do you get back from remote?
<BenC> win/scale stuff is weird
<BenC> I've seen where certain windows machines work badly with linux when scaling is turned on
<lamont> 65535 from google
<lamont> can I force it to not scale?
<lamont> 10:20:43.051551 IP 15.238.4.198.44514 > 64.233.167.99.80: P 1:102(101) ack 1 win 183 <nop,nop,timestamp 426415 23137170>
<lamont> 10:20:43.136797 IP 64.233.167.99.80 > 15.238.4.198.44514: P 1:1431(1430) ack 102 win 65535 <nop,nop,timestamp 23137170 426415>
<lamont> so does it violate RFC to send 1430 octets when the other end advertised a window of 183?
* lamont reboots into the current gutsy kernel.  brb
<lamont> BenC: fixed in 2.6.22-1-server_2.6.22-1.5
<BenC> lamont: there's a scaling setting in /proc/sys/ somewhere
<lamont> thanks
<lamont> BenC: hrm... actually, 2.6.22 shows the same issue, turning off window scaling makes it go away
<lamont> --> bug in other vendor's stuff, not linux.  kthxbye
<BenC> lamont: yeah, sounds about right
<ogra> if i monitor an nfsroot thats mounted via udp with -o nolock with wireshark, why do i still see sunrpc noise over tcp ?
<AnAnt> Hello, will there be a kernel fix for Feisty ?
<zul> probably when it is ready
<AnAnt> zul: do you know about that bug regarding MMC cards ?
<Amaranth> you mean the broken tifm driver?
<AnAnt> Amaranth: so it is broken ?
<AnAnt> Amaranth: hello ?
<Amaranth> yes
<AnAnt> Amaranth: ic, no fix for it yet ?
<Amaranth> you could use gutsy ;)
<zul> its being worked on according to the bug reports
<AnAnt> hmmm
<AnAnt> zul: what is bug report # ?
<zul> 53923 
<AnAnt> zul: thanks
<mjg59> BenC: Did you have a chance to check the appletouch thing?
#ubuntu-kernel 2007-05-17
<cjwatson> pkl_: did you get anywhere with looking into the memory pressure issue on feisty live CDs?
<cjwatson> pkl_: I'm likely to be asked for more information on that in a phone call shortly ...
<pkl_> not yet, no time since UDS.  There always appears to be higher priority tasks...
<pkl_> My intention was to continue with it as soon as I get a Feisty kernel update finished and uploaded, which will hopefully be this week.
<ivoks> what's with dapper's updates?
<ivoks> any plans for it?
<zul> eh?
<ivoks> at least 3ware driver? :)
<ivoks> and e1000 :)
<ivoks> zul: latest 3ware sata controllers and intel's revisions of gigabit cards don't work with dapper
<zul> ivoks: have you opened a bug about it?
<ivoks> i've sent patches couple of months ago
<zul> where?
<ivoks> mailing list
<zul> check git to see if it got included 
<ivoks> https://lists.ubuntu.com/archives/kernel-team/2007-February/001262.html
<ivoks> eh... ok
<ivoks> hm.. looks i didn't sent one for e1000
<pmjdebruijn> will Gibbon have the qemu kernel accelerator compiled my default as a module
<pmjdebruijn> so I don't have to compile it for each kernel update?
<cjwatson_> (the short name is "Gutsy")
<cjwatson_> we did discuss that in the virtualisation session at UDS; sounded like it would be doable. Ben?
<zul> i thought feisty already had that?
<ivoks> zul: nope
<BenC> pkl_1, kylem: #ubuntu-meeting
<mrec_> maybe someone is interested in that list http://mcentral.de/wiki/index.php/Linuxtv#Partly.2FFully_supported_Hardware
<mrec_> this work is currently not included in the kernel
<dkulchenko> hey guys, i can't start up Ubuntu after a clean install
<dkulchenko> here's lspci -vvnn: http://paste.ubuntu-nl.org/21334/
<dkulchenko> here's dmesg: http://paste.ubuntu-nl.org/21333/
<cjwatson> dkulchenko is using the pata_sis driver, and it's throwing ATA bus errors all over the show when trying to read the partition table
<cjwatson> he came to me since obviously that makes the installer fall over in a heap
<dkulchenko> yeah, i was told that this is an installer bug
<dkulchenko> thanks for clarifying, cjwatson
<dkulchenko> sob, i'll probably have to switch back to Fedora
<dkulchenko> hey, ivoks, can you help?
<cjwatson> dkulchenko: easy
<cjwatson> dkulchenko: people have other things to do and won't necessarily answer immediately; you need to have patience
<cjwatson> asking random people who join the channel is not the best strategy
<dkulchenko> ok
<dkulchenko> it's impossible to talk on #ubuntu
<ivoks> :)
<ivoks> afaik, this isn't support channel?
<dkulchenko> cjwatson: would you be surprised if i told you i am 11
<cjwatson> on the internet, no-one knows you're a dog
<dkulchenko> whaddya mean?
<cjwatson> old joke. if you don't say, nobody will know ;-)
<kylem> nobody really cares that you're a dog either.
<kylem> dkulchenko, can you take a photo of the messages?
<cjwatson> http://www.epatric.com/funstuff/dog/
<cjwatson> kylem: the dmesg on the pastebin there has the ATA error messages in it ...
<kylem> oh, i only saw that lspci.
<dkulchenko> cjwatson: heh. you don't find many 11-year-old sysadmins that have their own website (portools.com), do you now?
<dkulchenko> p.s. and that are at an advanced level of perl? :)
<wmat> i always assume sysadmins are under 12 ;)
<dkulchenko> wmat: :)
<BenC> [  546.696000]  VFS: Can't find ext3 filesystem on dev sda.
<BenC> is there supposed to be a filesystem on the whole disk, as opposed to on a partition?
<dkulchenko> there is a filesystem on each partition, not each disk
<BenC> dkulchenko: so the install went fine, but now the reboot doesn't work?
<dkulchenko> yah
<BenC> does booting the install CD again allow you to mount your drives?
<ivoks> maybe he removed disk before installation and returned it after
<ivoks> that's common thing people do
<ivoks> (/me didn't see that error about sda :)
<cjwatson> BenC: he said that it was intermittent on the live session too
<cjwatson> 20:44 <dkulchenko> that's a problem to figure out. I'm running on the liveCD right now, and the past 2 runs i was able to access the disk, now I can't
<cjwatson> so I figure it's intermittent read errors
<BenC> sounds like hw to me
<BenC> trying the -386 kernel may be a good idea
<dkulchenko> so, will the alternate cd make any difference?
<dkulchenko> than the LiveCD installer?
<dkulchenko> never mind, question answered on other channell
<BenC> if the answer was "no", then they were correct :)
<davef> Which channel should I try for help compiling the kernel (using git and fakeroot debian/rules)?
#ubuntu-kernel 2007-05-18
<BenC> davef: best to just read the stuff on the wiki (URL in topic)
<davef> BenC: Keep trying that.  The compile bombs out on not having vboxdrv, after 9hours :-(.  I think I need to remove it from /boot/config-2.6.20-15-generic. Was hoping not to have to go through that cycle again.
* #ubuntu-kernel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
<knewt> hmm, wierd. thought i'd try ubuntu-gutsy.git again, and now getting "fatal: unexpected EOF // fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-gutsy.git' failed."
<BenC> knewt: git://kernel.ubuntu.com/ubuntu/ubuntu-gutsty
<BenC> just moved last night
<knewt> BenC: thanks. any idea how to work around the -headers package dependency on a non-existant package?
<mjg59> If you only generate a single flavour, it won't build the base headers package
<knewt> i did this "AUTOBUILD=1 fakeroot debian/rules binary-debs", but it only generated the linux-headers-2.6.22.2-* stuff, not linux-headers-2.6.22.2. if i remember correctly, anyway. it certainly wouldn't install :)
<BenC> knewt: fakeroot debian/rules binary-headers
<BenC> that will get you the package you want
<knewt> ah, cool. BenC++
<knewt> may still not be 2.6.21, but guess i can live with that *g*
<BenC> I still need to update the wiki for the gutsy build system
<BenC> what does 2.6.21 have to do with it?
<knewt> 2.6.21 was what i really wanted, but i couldn't find any ubuntified trees of it anywhere
<BenC> knewt: we don't do trees for versions we aren't planning on releasing...you do realize that it's sort of a waste to use our tree just to build a kernel package
<BenC> knewt: getting linux-2.6.21.tar.bz2 from kernel.org and using make-kpkg would be a lot easier
<knewt> how much of a difference is there nowadays between a ubuntu kernel and a kernel.org kernel?
<knewt> also, how would i get make-kpkg to strip the modules such that i don't actually have a half-gig /lib/modules directory at the end of it?
<BenC> sed 's/.*CONFIG_DEBUG_INFO.*/# CONFIG_DEBUG_INFO is not set/' .config
<knewt> hmm. i used the /boot/config* file as the base for the build. how come it produces different results?
<BenC> it doesn't...we strip the modules after our build is done
<BenC> we keep the debug vmlinux image for the linux-image-debug packages
<BenC> vmlinuz is automatically stripped
<BenC> code wise, they are exactly the same though
<knewt> ah
<knewt> ok, i'll try a kernel.org build again then, thanks
<cjwatson> BenC: a few people have asked the same question - maybe one for https://wiki.ubuntu.com/KernelTeam/FAQ ?
<BenC> yeah
<cjwatson> or maybe better https://wiki.ubuntu.com/KernelCustomBuild
<BenC> CustomBuild is for building our of our tree, so they wouldn't be exposed to this
#ubuntu-kernel 2007-05-19
* #ubuntu-kernel  [freenode-info]  if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
<salty-horse> when removing the old linux-image-2.6.20-13-generic package, I got this warning: "You shouldn't call /sbin/update-grub. Please call /usr/sbin/update-grub instead!"
<maks_> check your /etc/kernel-img.conf
<maks_> if there is a grub path there around
<maks_> anyway better ask on #ubuntu
<salty-horse> yup - it's set to /sbin/update-grub 
<salty-horse> do you know what package generates it?
<salty-horse> (I upgraded from edgy so maybe it's a leftover)
<maks_> edit it to /usr/sbin/update-grub :)
<maks_> it won't be needed for gutsy anymore afaik
<salty-horse> just did. thanks!
* jbailey images BenC saying "Bah!  That -4 kernel is at least *minutes* old!  Get a new one!"
<jbailey> =)
<BenC> hehe
<BenC> jbailey: I uploaded -5 just defer working on your bug :)
<jbailey> BenC: I believe you, it's not even in the archive yet. =)
<jbailey> I had to remember how to fish such things out of Launchpad directly. =)
<BenC> it's compiled, just not processed yet
<BenC> ah, resourceful
<harkonnnen_> hi
<harkonnnen_> !
<jbailey> THE SUPPORT PERSON CANNOT BE THWARTED! MWAHAHAHAHAHAHA
<harkonnnen_> can somebody  help me ?? 
<jbailey> BenC: If it's useful, I suppose I could do a bisect backwards.
<harkonnnen_> i have a problem tryng to install a module
<harkonnnen_> in ubuntu 
<harkonnnen_> can somebody  help me ?? 
<harkonnnen_> can somebody  help me ?? 
<BenC> jbailey: yeah, that would actually be very helpful
<jbailey> 'k.  Since the failure was between -1 and -3, it hopefully shouldn't take too long.  I'll try and do that over the course of the weekend.
<BenC> jbailey: FYI, you should bisect the v2.6.21 and v2.6.22-rc1 tags, which wont include the ubuntu build, but you can use make-kpkg just as easily
<BenC> -1 was 2.6.21 and .3 was .22-rc1
<kylem> what's the failure?
<jbailey> BenC: So just use pristine linus?
<BenC> -3 even
<BenC> yeah
<jbailey> bug 11596
<jbailey> Oh, no ubugtu in here.
<jbailey> 115596, rather and 115597
<shawarma> harkonnnen_: You'll get a much better response if you ask your question rather than asking if someone can help you. We don't know what your problem is, so it's kind of hard to know if we can solve it..
<jbailey> kylem: Sound problems and "badness" on your future G5 ;P
<harkonnnen_> i have a problem trying to install this module ...
<harkonnnen_>  1 #include <linux/init.h>
<harkonnnen_>  2 #include <linux/kernel.h>
<harkonnnen_>  3 #include <linux/module.h>
<harkonnnen_>  4 #include <linux/sched.h>
<harkonnnen_>  5 #include <linux/mm.h>
<harkonnnen_>  6
<harkonnnen_>  7 static int pid_mem = 1;
<shawarma> Stop!
<harkonnnen_>  8
<harkonnnen_>  9 static void print_mem(struct task_struct *task)
<harkonnnen_> 10 {
<harkonnnen_> 11         struct mm_struct *mm;
<harkonnnen_> 12         struct vm_area_struct *vma;
<harkonnnen_> 13         int count = 0;
<harkonnnen_> 14         mm = task->mm;
<harkonnnen_> 15         printk("\nThis mm_struct has %d vmas.\n", mm->map_count);
<harkonnnen_> 16         for (vma = mm->mmap ; vma ; vma = vma->vm_next) {
<shawarma> harkonnnen_: Stop it!
<harkonnnen_> 17                 printk ("\nVma number %d: \n", ++count);
<harkonnnen_> 18                 printk("  Starts at 0x%lx, Ends at 0x%lx\n",
<harkonnnen_> 19                           vma->vm_start, vma->vm_end);
<harkonnnen_> 20         }
<harkonnnen_> 21         printk("\nCode  Segment start = 0x%lx, end = 0x%lx \n"
<harkonnnen_> 22                  "Data  Segment start = 0x%lx, end = 0x%lx\n"
<harkonnnen_> 23                  "Stack Segment start = 0x%lx\n",
<harkonnnen_> 24                  mm->start_code, mm->end_code,
<jbailey> shawarma: Is there actually a way on IRC clients to stop a paste once it's going?
<harkonnnen_> 25                  mm->start_data, mm->end_data,
<harkonnnen_> 26                  mm->start_stack);
<harkonnnen_> 27 }
<harkonnnen_> 28
<harkonnnen_> 29 static int mm_exp_load(void){
<harkonnnen_> 30         struct task_struct *task;
<harkonnnen_> 31         printk("\nGot the process id to look up as %d.\n", pid_mem);
<harkonnnen_> 32         for_each_process(task) {
<harkonnnen_> 33                 if ( task->pid == pid_mem) {
<harkonnnen_> 34                         printk("%s[%d] \n", task->comm, task->pid);
<harkonnnen_> 35                         print_mem(task);
<harkonnnen_> 36                 }
<harkonnnen_> 37         }
<harkonnnen_> 38         return 0;
<shawarma> jbailey: Probably not. Proper clients ask if it's really ok to paste a bunch of lines before doing so.
<harkonnnen_> 39 }
<harkonnnen_> 40
<harkonnnen_> 41 static void mm_exp_unload(void)
<harkonnnen_> 42 {
<harkonnnen_> 43         printk("\nPrint segment information module exiting.\n");
<harkonnnen_> 44 }
<harkonnnen_> 45
<harkonnnen_> 46 module_init(mm_exp_load);
<jbailey> shawarma: Sure, but he's presumably said yes by the time you've told him to stop.
<harkonnnen_> 47 module_exit(mm_exp_unload);
<harkonnnen_> 48 module_param(pid_mem, int, 0);
<harkonnnen_> 49
<shawarma> You could probably hurry and close the window and open it again.
<harkonnnen_> 50 MODULE_AUTHOR ("Krishnakumar. R, rkrishnakumar@gmail.com");
<harkonnnen_> 51 MODULE_DESCRIPTION ("Print segment information");
<harkonnnen_> 52 MODULE_LICENSE("GPL");
<harkonnnen_> its finis
<harkonnnen_> sorry
<harkonnnen_> !
<shawarma> We still don't know what your problem is.
<harkonnnen_> i insmod the module and i get an error message
<shawarma> We still don't know what your problem is.
<harkonnnen_> invalid module format
<shawarma> Which error message?
<harkonnnen_> i'm trying to read the format of the modules and it's seems correct as i could learn
<kylem> you want #kernelnewbies.
<harkonnnen_> i execute dmesg and i found 
<harkonnnen_> [17200516.632000]  printk: 8 messages suppressed.
<shawarma> harkonnnen_: What kylem said. #kernelnewbies is the right channel for this.
<harkonnnen_> it's ok
<harkonnnen_> thank you very much
<kylem> shawarma, hey, how was your trip back home?
<shawarma> kylem: Long.
<kylem> same here. :/
<shawarma> kylem: Not as long as your's, probably, but considering that I really wasn't going that far, it was way too long.
<kylem> :)
<jbailey> shawarma: Where do you live?
<shawarma> jbailey: Denmark.
<jbailey> Ah, handy.  You can go beat on Fabio for us ;)
<shawarma> Sure. :)
<shawarma> Beating up immigrants *is* popular. :)
<jbailey> Oh dear. =)
<jbailey> The only person i've ever met actually from Denmark lived in Vancouver and was famous for things like shooting his compter screen when it pissed him off.
<kylem> LOL
<shawarma> Heh.
<nimbo> hey, i want to compile my own kernel module, but i get some error messages ( http://rafb.net/p/6EuqWZ63.html )
<nimbo> hey, i want to compile my own kernel module, but i get some error messages ( http://rafb.net/p/6EuqWZ63.html )
<shawarma> nimbo: Try #kernelnewbies
<nimbo> hm ok, i'll try that
<micahcowan> Does the kernel package not use a patching system?
<micahcowan> If I wish to prepare a debdiff, do I just modify the source directly, alter the changelog, and go?
* Starting logfile irclogs/ubuntu-kernel.log
<micahcowan> Why do all entries in the kernel changelog for non-upstream changes have "GIT-SHA" lines, and what are they hashes for?
<crimsun> micahcowan: don't use debdiff.  Use git-format-patch(1) [hopefully you've installed git-core] .
<crimsun> micahcowan: the GIT-SHA lines no longer appear in gutsy.  The hashes refer to git commits.
<micahcowan> crimsun, thanks. If I've made changes to fs/ncpfs/file.c, fs/reiserfs/file.c, and /mm/filemap.c, should the changelog entry start with "* fs,mm:" ? And what else might I need to know about special formatting for changelog entries?
#ubuntu-kernel 2007-05-20
<crimsun> I don't recommend doing it that way.  Are you familiar with using git-core or cogito [or other git-core frontends] ?  If not, I'll walk you through git-core in #ubuntu-motu.
<micahcowan> Then, the changelog entry is done automagically?
<micahcowan> crimsun
<crimsun> what tool(s) are you using?  just plain diff, or git-core?
<micahcowan> til now, just plain diff.
<micahcowan> I'll switch to #ubuntu-motu.
<crimsun> ok.
<johanbr> Hmm. 2.6.22-4-generic on amd64 doesn't seem to be tickless. Is that intentional?
<kylem> 2.6.22 doesn't have x86-64 tickless.
<johanbr> Oh, I see, thanks. Do you know why?
<johanbr> Is it just that the 64-bit kernels are intended more for desktop/server use?
<kylem> the code hasn't been merged yet?
<johanbr> I guess that's a good reason. :) And here I was hoping to get a little more battery life out of my laptop. Oh well...
<shawarma> mbieb/win 38
<shawarma> Whoops
<mrec__> hi, would it be possible to add an extra kernel to the apt-sources?
<defendguin> I'm trying to install feisty but i've run into this bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106864  the suggested work around adding break=top to the kernel options when booting causes my usb keyboard not to function when the terminal comes up.  What way may i work around this?
* Starting logfile irclogs/ubuntu-kernel.log
<pepie34> is someone wha package the fglrx driver here?
<pepie34> who has packaged
* BenC waves
<pepie34> OK BenC
<pepie34> I've got a problem i'm trying to package the latest driver from ATI
<pepie34> but the dh_shlibdeps return paths to libs install in /usr/i486-linux-gnu
<pepie34> http://paste.ubuntu-nl.org/21721/
<BenC> pepie34: Can't help you there, never seen that problem
<pepie34> (forgot to mention i follow this tuto : https://help.ubuntu.com/community/BinaryDriverHowto/ATI#head-796aa4d6d0477c8ed722acef1878cc5626855ae3-2)
<BenC> I didn't write that either :)
<pepie34> any idea so?
<defendguin> BenC: your the one who posted the work around to this issue bug 106864  why would adding break=top  break my usb keyboard when i get to the busybox prompt?
<BenC> defendguin: doesn't break it, it just stops before loading usb drivers
<BenC> defendguin: use break=premount instead
<defendguin> thanks 
<defendguin> nope still didn't load 
<defendguin> BenC: what else can i try setting break to?
<Mithrandir> you can try top
<Mithrandir> as in, break=top
<defendguin> Mithrandir: usb devices wont work with that option 
<defendguin> and i have no ps2 keyboard
<Mithrandir> oh, sorry, didn't read enough of backlog.
<BenC> works for me with break=premount
<defendguin> just to be very clear when booting the CD i choose the F6 option for other options and append break=premount to the end of that line?
<BenC> right
<defendguin> nope no worky 
<defendguin> as soon as the kernel loading bar goes away the usb devices are dead usplash shows for less than a second and goes to the busybox prompt  
<defendguin> i guess i'm just stuck 
<defendguin> booting from the mini.iso seems to be working 
* Starting logfile irclogs/ubuntu-kernel.log
#ubuntu-kernel 2008-05-12
<abogani> rtg: Hi Tim, sorry to bother you. Is it a well-done SRU bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/229499 ?
<TheMuso> .c
<mcella_> We're backporting kvm-68 from intrepid to hardy since we're experiencing some problems with stock kvm (62) in hardy 
<mcella_> I've got three packages, kvm, kvm-data and kvm-source
<mcella_> the stock hardy kernel installs kvm modules inside /lib/modules/2.6.24-16-server/kernel/arch/x86/kvm
<mcella_> what's the proper way to upgrade these modules to a new kvm release?
<mcella_> here /usr/share/doc/kvm/README.Debian it's suggested to use module-assistant auto-install
<mcella_> I've done it and got a new kvm-modules-2.6.24-16-server package
<mcella_> but this package installs kvm modules in /lib/modules/2.6.24-16-server/misc
<mcella_> so modprobe -l | grep kvm gives me the old modules
<mcella_> /lib/modules/2.6.24-16-server/kernel/arch/x86/kvm/kvm-amd.ko
<mcella_> /lib/modules/2.6.24-16-server/kernel/arch/x86/kvm/kvm-intel.ko
<mcella_> /lib/modules/2.6.24-16-server/kernel/arch/x86/kvm/kvm.ko
<rtg_> mcella_: try installing them in  /lib/modules/2.6.24-16-server/updates. the depmod order is controlled by /etc/depmod.d/ubuntu.conf
<mcella_> is there a way I can tell module assistant where to install them?
<mcella_> rtg_: tnx btw
<rtg_> mcella_: dunno, I've never used module assistant.
<mcella_> ok, tnx
<rtg_> soren: ^^^
<munckfish> Hi. I need some advice - I'm working on the PS3 Port, I've sent a couple of messages to the kernel team mailing list recently but no one is talking back. Can anyone tell me what if anything I'm doing wrong or could do get dialog started?
<rtg_> munckfish: I keep thinking BenC will reply. He's the ps3 dude.
<munckfish> rtg_: worth pestering him direct then? ok
 * BenC is here, but on call right now
<munckfish> BenC: ok I am around just ping when you have a moment
<mcella_> rtg_: what about make-kpkg?
<rtg_> mcella_: uh, what about it? Are you thinking it has options for where to direct the installation of the kvm modules?
<mcella_> dunno, just noticed it inside kvm readme
<mcella_>  - Using the make-kpkg(1) command provided by the kernel-package Debian
<mcella_>    package. This will produce a corresponding kvm-modules package for
<mcella_>    the Debian kernel-image package that you are using. This is "the Debian
<mcella_>    way". See the "modules_image" section of the make-kpkg(1) man page.
<mcella_> someone told me in ubuntu-virt that today Soren is on holiday
<mcella_> I will try to catch with him tomorrow maybe :-)
<rtg_> mcella_: your best bet is to get soren's attention. I get all of the kvm updates from him.
<mcella_> ok, tnx a lot anyway
<lacostej_> Is there a channel where I can get kernel help ? I've been (sporadically) on #ubuntu for 4 weeks and noone seems to be able to help me investigate bug #216927. It's actually happening right now: my keyboard and mouse are stuck, and firefox is stuck switching tabs indefinitely (causing 100% CPU on the machine). 
<lacostej_> If someone knows if there's a Hardy kernel with kgdb backported, feel free to post that information on the aforementionned issue page. (and sorry for bothering this channel)
#ubuntu-kernel 2008-05-13
<fran2> hello
<fran2> help in this bug
<fran2> #ubuntu-kernel
<fran2> http://bugzilla.kernel.org/show_bug.cgi?id=10394
<abogani> rtg_: Hi Tim, sorry to bother you. Is it a well-done SRU bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/229499 ? Or should i sent sru justification at kernel-team ml? Thanks!
<rtg_> abogani: It wouldn't hurt to send the SRU argument along with the pull request.
<rtg_> abogani: also, the SRU bug report looks good.
<abogani> rtg_: Is it necessary a pull request?
<rtg_> abogani: it makes it easy for me to cut and paste the git path, and it lets everyone subscribed know what is going on.
<abogani> rtg_: Mailed. Thanks you very much and sorry again for bother.
<rtg_> abogani: np. Are you going to UDS in Prague?
<abogani> rtg_: Unfortunately, no.
<abogani> :-(
<Xtreme_Great> hi everybody..
<Xtreme_Great> Kernel programming is great.
<amitk> Xtreme_Great: most people on this channel tend to agree ;)
<eradicus> any good books on kernel programming?
<Xtreme_Great> eradicus: Try the GNU's book on linux module programming
<Xtreme_Great> amitk: :)
<Xtreme_Great> amitk: I thought so... ;)
<Xtreme_Great> can anyone refer me to some makefile tutorial?
<Xtreme_Great> I need 'em for the module making..
<eradicus> Xtreme_Great: what's the complete title of the book?
<Xtreme_Great> eradicus: Linux Kernel Module Programming Guide
<abogani> LDD3
<Xtreme_Great> eradicus: This one here.. tldp.org/LDP/lkmpg/2.6/lkmpg.pdf
<alex_joni> LDD might also help.. http://lwn.net/Kernel/LDD3/
<eradicus> thanks
<eradicus> Xtreme_Great: yes
<alex_joni> hey abogani 
<abogani> alex_joni: Hi
<munckfish> BenC: Hi, any news on the creating a repo for the PS3 team to publish changes to? And .. any opinion on whether the PS3 kernel should be a cust flavour?
<xtreme> hi all
<sunilsivan> how to install for nvidia gforce driver
<foka> Hi again!
<foka> Is it a known issue that 8.04 fails to start on nVidia nForce 730a/720a/710a (MCP78, MCP77) due to kernel SATA AHCI (?) driver issues?
#ubuntu-kernel 2008-05-14
<Keybuk> who's maintaining the openvz patch set in our kernel?
<jepler> can someone tell me why debian/control and debian/control.stub are in the git?  arent't they generated files (created by debian/rules control)?
<scrash08> Does ubuntu's current kernel paravirt-ops implementation support Xen PCI-passthrough in DomU? i just learnerd Fedora9's does not, and am searching for an alternative ...
<zul> scrash08: no it does not
<scrash08> zul: well, rats. thx!
<zul> maybe for interpid
<scrash08> zul: assuming "I" for intrepid is release after Hardy?
<zul> scrash08: yes
<scrash08> you beat me to "the Google" ... got it.
<scrash08> zul: offhand, do you know where in ubuntu-space the paravirt_ops discussion is had?  particular mailing list? wiki somewhere?
<nolan> Is there anything more I could usefully do to debug the libata switch beyond filing: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220493
<nolan> I am full of lies.  I meant: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/224506
<abogani> BenC: Sorry to bother you: Could you update my SSH key on Zinc, please? I have already updated my launchpad profile with my new SSH key (https://launchpad.net/~abogani). Thanks!
<cking> abogani: it may be quicker to email Ng with a signed copy of the public key(s)
<abogani> cking: Yes. Thank you!
<abogani> cking: By the way any news about "Rescheduling interrupts" bug? 
<cking> abogani: I suggest looking at the bug report, I've create a wiki page https://help.ubuntu.com/community/ReschedulingInterrupts to help corner the specific reasons for this problem.
<abogani> cking: Ok thanks!
<abogani> bye
<laga> yay. i'm also affected by the rescheduling interrupts problem. i'll take a look.
<Keybuk> so
<Keybuk> who cares about openvz?
<Keybuk> sorry, think-o
<Keybuk> who cares /for/ openvz? :-)
<blueyed> This appears to be quite an important fix: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=607bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723
<blueyed> => bug 230456
<Xtreme_Great> I installed the 2.6.24.3 kernel from ubuntu. Now I am unable to install the restricted drivers.
<Xtreme_Great> Can anyone help?
<mariusz> be more specific
<mariusz> what does it mean i cant install ?
<mariusz> what version of Ubuntu ?
<Xtreme_Great> 8.04
<Xtreme_Great> I downloaded it from apt-get..
<mariusz> what was the exact name of package you installed
<Xtreme_Great> I don't remember I saw it in the ubuntu's website..
<Xtreme_Great> https://help.ubuntu.com/community/Kernel/Compile
<Xtreme_Great> I did exactly as was said
<mariusz> Xtreme_Great: are you still there 
#ubuntu-kernel 2008-05-15
<jayc> amitk: ping
<juliank> Just a short info: Patch unionfs to use do_splice_{from,to} instead of vfs_{splice_from,to}. The kernel is already patched to export these do_splice* functions, as they are needed by aufs.
<foka> BenC, Hi!  It's been over a week, and https://bugs.launchpad.net/bugs/223656 is still a "private" bug.  Should I file a new bug report so I can post dmesg logs and other details?
#ubuntu-kernel 2008-05-16
<legend2440> !paste
<legend2440> after clean install of hardy i get this error http://paste.ubuntu.com/12366/ would compiling kerne with via82cxxx module help?
<emgent> morning
 * lamont` wonders if the ati restricted driver believes in suspend, or if it's just nvidia that hates life?
#ubuntu-kernel 2008-05-17
<holycow> higuys
<holycow> are intel 5100 chipsets supported in the kernel yet?
<lifeless> rtg: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/99755
<lifeless> rtg: this is the symptoms I was describing
<emgent> heya
<ErmesDJ> buongiorno qualcuno mi puÃ² dare una mano per piacere ? sono disperato grazie 
<laga> do you speak english? :)
<ErmesDJ> so so
<ErmesDJ> italian is better for me i'm sorry
<tseliot> ï»¿ErmesDJ: qual'Ã¨ il problema?
<ErmesDJ> ho comprato un toshiba satellite per me ottimo....ha una Ati hd2600
<ErmesDJ>  ho installato ubuntu
<ErmesDJ> utto perfettament
<ErmesDJ>  ieri sera un mio amico ha spento il pc col tasto senza kiudere la sessione
<ErmesDJ>  e ora al riavvio del pc 
<ErmesDJ> mi kieme initramfs
<ErmesDJ>  e non so andare avanti mi potreste aiutare a risolvere il problema per favore ?
<tseliot> Questa non Ã¨ una chatroom per il supporto tecnico. Prova a chiedere sul forum italiano: http://forum.ubuntu-it.org/
<ErmesDJ> d'accordo scusatemi 
<tseliot> translation: this is not a support chat-room . Try asking on the italian forum
<Xtreme_Great> hi all...
<Xtreme_Great> Can someone tell me where to get the kernel module programming manpages...
<Xtreme_Great> for functions like init_module and the like?
<Xtreme_Great> hwilde: Can you tell where I can get manpages for the kernel module functions like init_module
<maks_> ~
#ubuntu-kernel 2008-05-18
<defendguin> i am having a problem returning from resume.  after upgrading to hardy when i return from resume the hard drive light flashes  the sleep light goes off and then the display turns off 
<defendguin> i really don't see anything obvious in the kernel log
<defendguin> in fact i can't find anything between the time i suspended the computer and the messages for when the computer was turned back on
<CescoAiel> Hi, I have a weird issue with a Broadcom BCM5722 NIC and the TG3 driver... 
<CescoAiel> When I reboot the machine, the NIC thinks it is active, but no data passes
<CescoAiel> when I unload tg3, remove the cable, modprobe tg3 and then reconnect the cable it works fin
<CescoAiel> If I leave the cable in it doesn; t
<CescoAiel> I could not find anything specific to this using google...
<emgent`UDS> heya
#ubuntu-kernel 2009-05-11
<trimeta> soren: Thanks.
<Sydero> Anyone know the minimum version of gcc required to compile kernel 2.6.28?
<dtchen> Documentation/Changes lists 3.2
<Sydero> thanks
<Kano> hi rtg , there are several issues with your 2.6.30 kernel
<Kano> first
<Kano> drivers/staging/Kconfig b/drivers/staging/Kconfig
<Kano> why on earth did you disable 3 drivers?
<Kano> funnyly you even patched one of those disabled drivers
<Kano> rt2870 got an added id
<Kano> but it never was compiled
<Kano> that added id conflicts merging with 
<Kano> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9ed12e5c149b05adf13bea5f1e96d68c2127faf
<Kano> thats after rc5,but add it, then you could add the added it you have in your tree
<Kano> i hate to resolve it everytime
<Kano> next
<Kano> i found the issue why the kernel did not boot on my systems with saa7136 tv card
<Kano> the error was s626 module
<Kano> can be solved when you do disable CONFIG_COMEDI, which is useless for me anyway
<Kano> last thing is
<Kano> if you want to be able to use fglrx with all tricks then you need
<Kano> http://kanotix.com/files/excalibur/linux-2.6.30-generic/source/2.6.30-export-flush_tlb_page.patch
<Kano> and if you do not want to use a very huge patch then use
<Kano> http://kanotix.com/files/excalibur/linux-2.6.30-generic/source/2.6.29-ubuntu-copy-headers-for-fglrx.patch
<Kano> Host/Kernel/OS  "Kanotix" running Linux 2.6.30-4-generic i686 [ Kanotix Excalibur 20090506-17:27 ]
<Kano> CPU Info        (1) Intel Core2 Duo E8400 @ clocked at [ 2999.000 MHz ]
<Kano>                 (2) Intel Core2 Duo E8400 @ clocked at [ 1999.000 MHz ]
<Kano> Videocard       ATI Mobility Radeon HD 3450  X.Org 1.4.2  [ 1680x1050 ]
<Kano> Processes 140 | Uptime 1:03 | Memory 438.3/1977.9MB | HDD Size 1000GB (6%used) | GLX Renderer ATI Radeon HD 3450 | GLX Version 2.1.8591 | Client Konversation 1.1 | Infobash v2.67.1
<Kano> with those patches it is possible to run fglrx
<Kano> the export is absolutely required
<soren> Kano: Why exactly is it that you don't report this on Launchpad? IRC is a horrible, horrible bug tracker.
<soren> Horrible.
<Kano> soren: there is no 2.6.30 in launchpad
<Kano> as it is only git
<Kano> or where are the packages
<soren> a) yes, there is.
<soren> b) that does not make IRC a better bug tracker.
<apw> Kano, you are reporting issues with karmics kernel... as you say 'your 2.6.30'
<Kano> soren: not my problem, i fixed the issues, fix em or leave it
<apw> therefore there is a package to report it against
<Kano> apw: i use git
<Kano> as i require changes
<Kano> which are not that important for u
<apw> i use keyboards that doesn't mean that there isn't a bug tracker
<Kano> fix it or not
<ogra> fun
<soren> Aw.
<apw> there really are packages of the karmic kernel in the karmic release pocket
 * TheMuso reads the above exchange, and finds himself thinking that if were on the kernel team, he'd ignore kano's "bug reports" out of spite. :)(
<apw> heh, no we just tend to lose things that are only in irc
<TheMuso> apw: I know that. kano refuses to use a bug tracker period. I've seen some things fixed that he's brought up in here, but I am sure there are many that aren'
<TheMuso> apw: I know that. kano refuses to use a bug tracker period. I've seen some things fixed that he's brought up in here, but I am sure there are many that aren't.
<apw> smb, can you remind me what was triggered when libusual was enabled
<smb> apw, With libusual enabled this would try to handle registration of usb storage devices, which would try to load usb-storage rather early as it was built in
<apw> ahh yes, usb storange, thanks
<smb> no worries :)
<apw> cking, your machine which is showing the bad sound ... what kernel is it running?
<cking> 2.6.28-12.43
<cking> apw: I don't think it's a kernel issue. The error I get is a pulseaudio big. "The CPU load limiter only becomes active as result of PA entering an
<cking> endless loop of some kind. It's only symptom of a bug somewhere, but
<cking> gives no hint where it actually is."
<apw> i think that means you have the appropriate 'fixes' for the pointers stuff as i understand it, which might be triggering confused pulse
<cking> I suppose I can roll back to an earlier kernel and test
<cking> I've just spotted: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
<apw> rtg this FIRMWARE_IN_KERNEL config change, do we know how much other firmware this may bring into the kernel other than the keyspan stuff?
<rtg> apw: I think you have to selectively pick the drivers that get firmware. I think the option just enables those selections
<apw> there appears to be a few other things which use fw-shipped-* in the Makefiles, which would be changed by it, as as soon as this option is turned on we longer put any firmware for any device which is =y into the firmware module from the kernel
<apw> s/module/result blob/
<apw> so i assume all of that firmware must go into the kernel image as well
<apw> it doesn't look like _that_ much, just making sure its what you expect
<apw> mod-fw := $(fw-shipped-m)
<apw> # If CONFIG_FIRMWARE_IN_KERNEL isn't set, then install the 
<apw> # firmware for in-kernel drivers too.
<apw> ifndef CONFIG_FIRMWARE_IN_KERNEL
<apw> mod-fw += $(fw-shipped-y)
<apw> endif
<apw> installed-mod-fw := $(addprefix $(INSTALL_FW_PATH)/,$(mod-fw))
<rtg> apw: shit. I would not have expected that enabling the option would adversely affect other drivers. 
<rtg> apw: so, should we put it in the linux-firmware package instead?
<apw> rtg, risk wise perhaps so for sru ... a difficult call.  what happens to the firmware blob that the kernel builds during build of the kernel
<apw> i wonder if that should be making its way wholesale into the firmware package
<Kano> rtg: when do you merge aufs2?
<Kano> rtg: http://aufs.sourceforge.net/README.aufs2
<rtg> apw: dunno, lemme look at it again.
<Kano> in the test live image is even squashfs 3.1 used, that will never work
<Kano> you need a cvs snapshot
<Kano> user space of course
<Kano> as squashfs 4 is in the kernel since .29
<Kano> hmm you are lucky,there is even a final 4.0
<Kano> in sid
<Kano> when i build my .29 test image i had to use cvs
<Kano> well merge aufs2 (it is already .30 compatible) + update squashfs-tools in karmic, then you can hope ;)
<Kano> rtg: do you want to update jaunty to 2.6.28.10 today?
<apw> jaunty is released now so anything like that would be an sru
<apw> that said i thought .28 was already in git
<Kano> apw: i mean the jaunty branch
<Kano> i do not use precompiled kernels
<apw> the jaunty git tree has .10 in it
<apw> commit 8bdd945b77faa2d7c63ad669d2d8b1a623c57e67
<apw> Author: Greg Kroah-Hartman <gregkh@suse.de>
<apw> Date:   Sat May 2 11:54:43 2009 -0700
<apw>     Linux 2.6.28.10
<Kano> ok
<Kano> will compile it now
<Kano> or do you want to add some more fixes soon?
<apw> there are always commits in the pipeline
<apw> as for aufs, that pending a decision on how live cd's will be done for karmic
<Kano> you can have it the kernel even if you dont use it ;)
<Kano> as you can use it without a live system too
<apw> no point in carrying delta for something we don't use
<Kano> so how do you want to create live images? anything new in casper yet
<apw> no decision that i am aware of no
<Kano> well i create live images, you talk about em ;)
<Kano> apw: did you rebase jaunty today? or since when is there .10?
<apw> jaunty doesn't rebase its released.  the commits for .10 went in about the 2nd
<Kano> ok, then i have it already
<Kano> so all i have to try now is aufs2... bbl
<cluk> Hi
<cluk> I am trying to provide linux-vserver kernel packages based on the ubuntu kernel in my ppa at:
<cluk> https://launchpad.net/~christoph-lukas/+archive/ppa
<cluk> the vserver kernel image for jaunty is working fine, the vserver functionality is also working fine
<cluk> but I get an kernel oops when I try to load the nvidia module 180.44 build via dkms for this kernel.
<cluk> could anybody help me debugging this issue?
<cluk> the oops is here: http://paste.ubuntu.com/169897/
<cluk> my linux-headers package seems to be broken which seems to break the nvidia module.
<cluk> sorry for the noise.
#ubuntu-kernel 2009-05-12
<apw> cluk what is broken about it?  was it mising the asm directory, that was an issue triggered by a bad find upload
<apw> smb, you have a thinkpad with hardy, can you check if the thinkpad/thinkvantage key produces an X keysym.  using xev you should see that key produce XF86Launch1
<apw> all, today is one of our regular kernel bug days ... come play with our fun bugs, free erm karma to those who help :)  https://wiki.ubuntu.com/KernelTeam/BugDay/20090512
<smb> Just returned
<smb> apw, the key does not produce events by default
<smb> apw, The problem, iirc, is that the acpi events arrive but are mapped to a keyboard key that is normally not existent (with fakekey) So the keyboard driver ignores is
<smb> it
<apw> smb, ok so that is officially still broken in hardy
<smb> apw, Yeah, and it actually was some deliberate change from upstream to ignore non-existent keys. This is where fakekey has its limit and the drivers in general should use input-events
<smb> But thats probably a too big change for hardy
<apw> yeah ... fair enough ... 
<andresmujica> morning
<andresmujica> we need a topic update..
* amitk_ changed the topic of #ubuntu-kernel to: "KERNEL BUG DAY 12-May-2009 | Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.28-12.43 based on 2.6.28.10 final"
<apw> smb, on this thinkpad, does the command 'setkeycodes e073 148' sort out your thinkpad key thing?  so its seen in Xev ?
<smb> apw, confirmed
<apw> smb so we have a work around for hardy and intrepid
<apw> no point in updating those two to fix something we have a simple work around for imo
<smb> apw, Yeah, as it is long ago I am not sure I remember correctly, there had been some notes that this keycode you set might be in use by another key. But in general, yes
<apw> when you say its visible, is it visible carrying the XF86Launch1 key symbol?
<apw> smb, ^^
<smb> Hm, don't see it:
<smb> KeyPress event, serial 30, synthetic NO, window 0x4800001,
<smb>     root 0x88, subw 0x0, time 25518768, (110,79), root:(1400,134),
<smb>     state 0x0, keycode 159 (keysym 0x0, NoSymbol), same_screen YES,
<smb>     XLookupString gives 0 bytes: 
<smb>     XmbLookupString gives 0 bytes: 
<smb>     XFilterEvent returns: False
<apw> smb, what does 'xmodmap -pk | grep Launch1' say
<smb> ""
<apw> hrm
 * apw notes that the current rate he will finish his 20 bug day bugs by about 2 am
<apw> how are other people doing?
<smb> apw, similar
 * apw has reached 6 after 8 hours ... not good
<apw> ok 7 hours
 * apw actually gets to the bottom of his list of bugs
 * apw pokes a couple of community ones for 'fun'
<smb_tp> apw, Hrmpf, how did you do that?
<apw> smb_tp, once you get to the Incompletes if they have been asked for feedback like a year ago by leann i felt happy closing them asking for a reopen if it stille xisted
<apw> and most of my incompletes were like that
<apw> the highs near killed me
<smb_tp> maybe I should jump to the incompletes and get back to the highs later...
<devel0> hi , i have a small problem related to initrd and I was hpoing someone could shed some light
<devel0> Im looking to change the usplash theme but I cant exactly do an update initramfs -d becauyse I have separated ubuntu because im doing a pxe boot
<devel0> when I say separated
<devel0> I mean one part is vmlinuz and initrd , the other part is a squashfs file downloaded via http
<devel0> when I simply replace the .so file , ubuntu moans at boot up that it cant find a usplash theme 
<devel0> that will work with my resol
<devel0> however with the default .so file , it doesnt complain
<devel0> I changed the file , repacked initrd with cpio and gzip , but still im missing something to make it all work
<devel0> any ideas someone ?
<devel0> please ? :O
<sladen> names
<devel0> filenames you mean ?
<sladen> devel0: the /etc/alternatives/usplash-artwork.so symlink is used to select which .so to pack into the initramfs cpoio
<devel0> I was aware of that but why cant i just have the default usplash-artwork.so in /usr/lib/usplash/ ?
<sladen> I'm stil not completely following the problem, can you try explaining it in a different way (what's "resol") ?
<sladen> btw, for future reference, usplash doesn't have anything to do with the kernel.  It runs entirely in userspace
<devel0> yeah i know , i just thought that maybe since this is a boot issue I could get a helping hand from you guys
<devel0> basically I have initrd.gz outside the distro and i use pxe to boot it with vmlinuz (ubuntu's kernel), then I have a squashfs file which contains the root filesystem
<devel0> I cant do an update-initramfs on my initrd.gz file , I can only pack it again with cpio and gzip
<devel0> or maybe I can via the live boot
<devel0> hmmm
<devel0> brb
<devel0> :D
<layer8> hi there
<layer8> can someone help me with a self compiled kernel? i have an error like "sata link down" during boot
<devel0> sladen
<devel0> I cant get round it
<devel0> I was wondering if you could help
<devel0> is there someone that can explain what integration the usplash .so file has with the initrd archive ?
<devel0> beyond the fact that it sits inside it
<layer8> hello?
<layer8> noone here, who can help me?
<sladen> devel0: no integration, other than getting copied in there by /usr/share/initramfs-tools/hooks/usplash
<sladen> devel0: initramfs is flexible enough that the same initramfs should do you for PXE and non-PXE boot IIRC.
<devel0> im boggled as to why it complains only by replacing the .so
<sladen> devel0: best place to ask would be the LTSP / Edubuntu people
<devel0> when i replace the .so file , i get a failed to init screen init thingy
<devel0> oh
<sladen> devel0: where did you get this new .so from?
<devel0> i tried many
<devel0> i tried kubuntus for example
<devel0> edubuntus , and a few others
<devel0> even custom ones from the net
<devel0> i dont get it , seriously im puzzled , i just went through the script in the initramfs tools that is used to copy usplash
<devel0> I do the same thing but manually
<devel0> this is crazy :)
<sladen> remember that the theme is a loadable executable file. Is it built to the same version as the usplash itself.
<sladen> this is why my query about "where did you get it"
<sladen> exactly how did you install this other usplash theme?
<devel0> omg does the so file have to match the libusplash.so ver ?
<sladen> did you compile it yourself.  Does it work with the test script
<sladen> devel0: uh huh.
<devel0> brb :)
<devel0> is there a way to know what ver was used to build an so ?
<sladen> dpkg -l | grep usplash
<sladen> and  apt-cache show usplash-theme-ubuntu  says that it depends (it's compiled for)   usplash (>= 0.5.30)
<devel0> im trying something i didnt before
<devel0> the simplest of things
<devel0> making the so executable
<devel0> hoping it might work
<devel0> im not too sure the usplash version makes much of a difference
<devel0> ok making the file exec didnt work
<devel0> leme sync the versions
<sladen> *blinks*
<sladen> devel0: put simply if usplash and the library (theme) it is dlopening are not speaking the same language (the same ABI) then it's not going to work
<sladen> devel0: just  sudo apt-get install kubuntu-artwork-usplash   if you want something else
<devel0> just recompiled an .so
<devel0> worked like a charm
<devel0> :)
<devel0> How can I thank you ?
 * devel0 dances 
<vertix> anybody knows about boot sequence in a mixed IDE/SCSI situation at the point where root filesystem is loaded?
<vertix> mounted that was
<vertix> at least it is not insane as on #ubuntu
<vertix> but looks quiet like in a grave
<vertix> anybody alive here?
<vertix> maaaaan, linux is a trip, i tellya
<vertix> oki doki
<devel0> yeah i know what you mean
<devel0> when you say "linux is a trip"
<devel0> :D
<devel0> sorry I cant help
#ubuntu-kernel 2009-05-13
<[HU]gnanet> Hi i have this repeating in my kern.log on Ubuntu Hardy Kernel 2.6.24-24: http://pastebin.com/m24f9631b , it also happens with apache, what i can think of there is a paging problem what is related to networking, but i cannot find any solution. i only found a clue to raise /proc/sys/vm/min_free_kbytes to 8192
<elmo> [HU]gnanet: if you run slabtop, how many 'files_cache' objects do you have?
<elmo> [HU]gnanet: also, which architecture?  i386 or amd64?
<[HU]gnanet> i386
<[HU]gnanet> never knew slabtop
<[HU]gnanet> OBJECTS column shows 240
<[HU]gnanet> i have to add i am using ocfs2 on these 3 machines 
<[HU]gnanet> elmo: OBJECTS column shows 240, on i386
<elmo> [HU]gnanet: ah, ok, different problem to mine then
<[HU]gnanet> elmo: maybe yes. 
<gorgonzola> hello. i'm having issues with libata's ahci controller, s i had blacklisted it in previous kernle versions... since in newer kernels libata mods are built-ins, how can i disable ahci, apart from recompiling the kernel ?
<mnemo> can I install kernel debug symbols using apt-get ?
<Sebboh> Hi.  I'm compiling a kernel and got a failure at the debian/rules updateconfigs step. It failed with permission denied around splitconfigs.pl .. see: http://pastebin.ca/1421927 (sorry, I only got the tail of the output.) What am I doing wrong here?
<Sebboh> I checked out line 65 of that file.  It's a single right curly brace. :P (And I don't speak perl.)
<Sebboh> nevermind, cheers.
#ubuntu-kernel 2009-05-14
<tjaalton> ddebs.u.c doesn't have l-i-debug for 2.6.28-11, is there a way to build it myself?
<tjaalton> (I'd like to use oprofile to find out what causes the extra load every ~15min)
<vertix> vertix: for developers: check out http://cppgoldmine.uuuq.com programmer's goldmine library to find the answers on any of your issues or problems in C++
<vertix> btw, no marketing or any other adds on those collections. it is totally clean site containing only articles in 100+ categories, nothing else
<Kano> hi, still no aufs2 in there yet?
<Kano> every other live cd is created via aufs(2) nowadays...
<apw> Kano, heh, nope as strangly we have not yet had the UDS discussions on this matter, as they occur in a week
<Kano> and you expect another result, do you
<amitk> Kano: probably not, but who knows :)
<Kano> thats basically impossible
<amitk> Kano: but you welcome to attend the session at UDS where we discuss the issue
<amitk> you can even dial in
<Kano> the thing is, when you add aufs2 in the kernel + squashfs 4 userspace then your tools would already create working test images 
<tjaalton> how can I build just the debug debs from the kernel source? been trying to do that, since there's no ddeb for 2.6.28-11
<rtg> tjaalton: you pretty much have to build the whole damn thing in order to get the debug debs
<tjaalton> rtg: right, so changing 0-common-vars.mk so that it doesn't skip ddeb's should be enough?
<tjaalton> and then debuild -b?
<rtg> tjaalton: you could just 'sudo mkdir /CurrentlyBuilding' as well
<tjaalton> heh, ok
<rtg> then 'debuild -b'
<rtg> either way should work
<tjaalton> ok, let's see
<BenC> rtg: I think /CurrentlyBuilding is just a file, not a dir
<BenC> but probably will still work
<rtg> BenC: I think it can be either, make just looks at the wildcard, doesn't it?
<BenC> rtg: yeah, I think it's just an existence test
<awe> rtg: are then good pointers on the kernel team's wiki pages for debugging crashes / restarts?  my machine (mbpro3 / amd64 ) reboots an awful lot after updating to jaunty.
<awe> s/then/there/
<rtg> awe: cold boots with no warning?
<awe> yea
<awe> usually re-sizing windows, but not always
<rtg> those are tough. 
<rtg> awe: i915 ?
<awe> nvida
<awe> geforce 8600M GT
<rtg> there is a section on debugging in https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<awe> all i could find was the suspend/resume debugging page, but i'll look again
<BenC> awe: using nvidia proprietary driver, or open source one?
<awe> prop
<rtg> awe: --> screwed
<BenC> awe: best bet is to see if nvidia can help...I'd try switching to open source driver for a bit to see if it still happens though
<awe> well, it's not like i wasn't told "it's recommended". ;)
<awe> i'll switch back and see how that works...
<rtg> awe: I've had to switch back to 2d before. the 3d driver was flickering and getting real annoying.
<awe> alright, i'll give it a whirl
<tjaalton> hmm, so my kernel (karmic) spends most of the time in read_hpet
<infinity> rtg: It's definitely a file, not a directory.
<rtg> infinity: the rule is 'ifeq ($(wildcard /CurrentlyBuilding),)'
<infinity> rtg: Yeah, should work for anything, then.
<infinity> rtg: Just pointing out that it's a file, should you ever do something with it in shell (say -f or -d)
#ubuntu-kernel 2009-05-15
<Squideshi> Can the kernel that ships with Jaunty be replaced with a newer kernel?
<Squideshi> I've read some about building a mainline kernel, but it also talks about mapping to a close match.
<Squideshi> In my situation, there is a bug in the kernel, which is fixed in later versions.
<Squideshi> I guess I would also like to know how upstream fixes like that eventually work their way into Ubuntu.
<Squideshi> I just spoke with Anholt, one of the Intel graphics driver developers. He says the page allocation table (PAT) code in the kernel is a mess--there have been a ton of bugfixes, but there is indication that not all of them have been fixed even in the most recent version. This is preventing xorg from starting properly for those affected using the Intel graphics driver.
<Squideshi> They think the best solution is just to disable PAT by default, using the "nopat" kernel option via GRUB.
<Squideshi> My concern is that affected users are simply going to find that they aren't able to start xorg after upgrading to Jaunty.
<Squideshi> The guys over on #intel-gfx are telling me that Jaunty disables PAT by default; but I am finding that, in my case, it is NOT disabled unless I manually add the "nopat" kernel option in GRUB.
<rtg> apw: grub2 bricked my xps1710.
<apw> rtg how did it fail?
<apw> unrecognised device?
<rtg> apw: fails at the chain command line. I'll get theerror message in a bit, but when you attempt to boot a selection it always says the same thing, something like 'Unidentified device string'
<apw> rtg yes thats a known issue
<apw> boot it to there, and edit the entry and change the word root to uuid
<rtg> how helpful :)
<apw> i have a fix building for it now
<apw> known in the sense we found it acouple of hours ago, rather than known for a long time!
<rtg> apw: I'm pretty sure I tried root --> uuid
<apw> hmm that should work, cirtainly worked here for me and cking
<rtg> apw: well, its on a different floor in the mansion. I'll go back up there and mess with it while I make some coffee.
<apw> heh ok ... hope it is the same issue
 * cking too
<rtg> biab
<apw> cking, heres hoping.  sounds too like what we both saw to not be ... 
<apw> i have the full fix building in my PPA now
<cking> lemme know when it's cooked
<apw> waiting on a publisher run right now
<apw> cking, ok it should be there now ~apw3
<cking> OK
<apw> installing on my crashy too
<apw> bugger its too clever
<cking> mm.. did not seem to work for me
<apw> hrm .. really
<apw> what didi it do?
<apw> was this a downgraded system of a virgin
<apw> hrm yes seems flawed... will recheck it
<cking> it was clean install
<apw> k, same result here... yet i tested it ... /me returns to the source
<apw> apw@dm$ /bin/bash foo "123-412121"
<apw> uuid
<apw> apw@dm$ /bin/bash foo "123412121"
<apw> uuid
<apw> apw@dm$ /bin/bash foo "(hd0,1)"
<apw> root
<apw> it is supposed to make the right choice!
<cking> whitespace perhaps?
<apw> perhaps ... am checking
<apw> i picked the check straight out of grub 1 ... so its a little confusing
<apw> ooooo, its got a #! /bin/bash on it, but if you test it with /bin/sh it doesn't work ... i wonder
<rtg> apw: I managed to get the root --> uuid thingy correct, so it at least boots.
<apw> rtg excellent.  sorting the converter script as we speak
<apw> are you following the testing page?
<rtg> is there a grub2 menu.lst where I can make that change permanent?
<apw> you are in chainload mode (if you are seeing this)
<apw> so that is in the real grub one, in menu.lst
<apw> if you do the next step, switching to it completely
<apw> then its irrelevant
<apw> https://wiki.ubuntu.com/KernelTeam/Grub2Testing
<cking> I kind of think the buggy BIOS where grub2 won't work are very few and far between - and new users should be very rare to hit BIOS weirdness in the boot loader nowadays
<apw> as grub hasn't had to change for an age
<cking> for aeons
<apw> so any new bugs are compatible with old ones :)
<cking> when did we last see a BIOS bug where the bootloader failed?
<apw> they are all hotkeys, and fan control and things after boot
<cking> yep - but early bootloader issues are nuts'n'bolts BIOS flaws and that is rare (anyhow there is just as much voodoo in isolinux)
<apw> for sure
<apw> rtg can you put your results on the testing page for us
<rtg> apw: yep, I just got distracted assembling my road show. gotta leave crack 'o dawn tomorrow
<apw> woh, nasty ... u carry on
<tjaalton> umm, so installing grub2 removes the old grub, expected?
<tjaalton> though it does leave the installed bootloader in place.. so, why yess!
<apw> tjaalton, its odd, it replaces your grub with a legacy grub of its own
<apw> also right now is bolloxes up your menu.lst
<apw> i've finally just fixed the transition script
<apw> uploading the fix to my ppa for those who want to test it ...
<tjaalton> it did work here without modification
<cking> apw, will do
<apw> interesting
<cking> whatsup?
<apw> cking, i'll yell when its done building
<apw> cking, it worked for tjaalton unexpectedly
<cking> ?
<apw> oh he may have just told it to install
<apw> tjaalton, did you skip the chainload mode?
<tjaalton> apw: no, it chainloaded from grub1
<apw> !
<tjaalton> this was the version in karmi
<tjaalton> c
<apw> and you didn't have to change the root -> uuid
<tjaalton> no
<apw> karmic and jaunty are the same package
<tjaalton> in which file would that be?
 * cking is mystified
<apw> so do you have uuid or root specifiers in your menu.lst?
<apw> in each entry?
<tjaalton> root=UUID=bleh
<apw> in /boot/grub/meu.list
<apw> the other one, the one in each entry
<tjaalton> ah
<tjaalton> root (hd0,5)
<apw> there is normally a 'uuid fooo' or 'root foo' in each entry
<apw> ok so that makes sense then, no idea why its not a uuid, but its not using uuid
<apw> so you would be fine
<tjaalton> probably because it's an older installation
<tjaalton> maybe since gutsy or hardy
<cking> that makes sense - upgrades don't get the UUID
<tjaalton> yeah
<apw> yeah something like that.  uuid wern't normal for grub itself
<apw> good understood
 * cking is no longer mystified
<apw> tjaalton, are you following the test page, ie are you going to update the test page with your results (pretty please)
<tjaalton> I'll try to boot vista (yeah..)
<tjaalton> apw: sure
 * cking crosses fingers
<apw> heheh
<cking> apw: I've got a 2.5GB USB flash based bootable full installation with grub2 for peeps to try out at UDS
<tjaalton> oh it was xp, and works. then there's the factory vista installer
 * cking cheers
<cking> Nice to know XP and Vista now work
<tjaalton> I'll try that one too, just for the kicks
<apw> cking, ok this one tests ok locally built, the ppa is on the go.  tested it both ways and things come out right for a change
 * cking goes and checks
<apw> the ppa will take a few more minutes to complete ... ~apw5 is the working version
<tjaalton> hmm, no 'update-from-grub-legacy' here
<tjaalton> argh
<tjaalton> *upgrade
<tjaalton> ok, done
<apw> yeah its very confusing
<cking> takes a while for it to be published ...
<apw> yeah it sure does.  the publisher runs on a half hour
<apw> cycle or something
<maxb> ppa publisher is 0, 20 and 40 minutes past the hour
<apw> not far off then :)
<apw> i like the fact it tells you its not published now, thats new
<apw> and that it now show you which are published with the green tick
<apw> ie those which are not published yet are there
<apw> cking, its published, and ready to test
<apw> looking good here
<cking> looks good to me
<cking> sweet
 * apw goes get it uploaded
<rtg> apw: your ppa?
<apw> yeah its in my ppa ~apw5 version
 * apw goes jump hoop
<cking> apw, good work!
<akk> Hi, all! I'm trying to understand why my kernel.org (non ubuntu, non modular) kernel won't boot on jaunty.
<akk> It worked fine on hardy and intrepid, but on jaunty it panics, "VFS: Unable to mount root fs on unknown-block(0,0)"
<pgraner> apw: can you assist akk pls?
<apw> hello
<akk> I'm using UUID= everywhere so I don't think it's a libata vs. old ide problem.
<apw> hmmm ... well i would try using root=/dev/sdxxx sort of boot to confirm its not a uuid issue
<apw> but in general that is done in initramfs, so your kernel shouldn't be an issue for that i'd think
<akk> I've tried root=/dev/sdaX and root=/dev/hdaX both
<apw> what kernel config did you use to build you kernel
<pgraner> apw: akk build a custom upstream kernel
<pgraner> akk: initramfs creation prob?
<akk> No initrd
<akk> non modular kernel, it's never needed an initrd
<apw> if its non-initrd, you won't have any support for UUID period
<apw> as that is done in userspace in ithe initrd
<apw> if its panicing then that implies you don't have the driver for your disk controller enabled
<akk> interesting! I could have sworn I'd done that before.
<apw> (if its panicing with the /dev/sdXN or hdXN specifiers)
<apw> i would boot the regular kernel and see which driver reports as finding the disks
<apw> and track that back to ensure its enabled in your config
<akk> That's in dmesg?
<apw> should be around where it find those disks
<akk> With the jaunty kernel, "Driver 'sd' needs updating - please use bus_type methods" 
<apw> yeah normal 
<akk> then a lot of confusing messages about sata (which I don't think this board has) and ata. It does mention scsi2: pata_via, scsi3: pata_via
<akk> are those what I'm looking for?
<akk> (it is a via chipset)
<apw> akk very likely, you could push the whole dmesg to a pastebin, and we could check
<akk> http://shallowsky.com/tmp/dmesg.out
<akk> brb, changing irc machines so I can do boot tests
<apw> akk, yeah you seem to be using pata_via and sata_via, so you need to make sure they are enabled
<akk> This same kernel was working under intrepid, so I figured I had all the right drivers
<akk> but I'm checking that
<apw> the exact same kernel or the same .config
<akk> exact same kernel
<apw> hmmm
<akk> same file in the shared /boot partition
<apw> well that is mytifying as the kernel is loaded in the same way, and from the same bootloader
<apw> and the kernel doesn't even know its loading the jaunty userspace as it cannot mount it to find out
<apw> so its not at all obvious how the kernel can work under intrepid
<apw> are you saying if you put the root spec for the intrepid userspace on this machine it loads?
<apw> in the same entry?
<apw> are both the intrepid and jaunty userspace on the same drive?
<akk> That's a good point. Let me double-check my menu.lst entries and make sure they're really identical.
<akk> Same drive, different partitions.
<akk> ah, actually if the menu.lst entries are the same, the error is different
<akk> it gets a little past mounting the root and hangs after loading the usb devices
<apw> how can that be
<apw> can you paste bin them both please
<apw> the entries
<akk> sure, just a sec ...
<akk> btw, "setting the system clock" is the next step (after where it hangs) if I boot into intrepid
<akk> blah, it decided to fsck this time so it'll be a little while before it's back up
<apw> hit escape?
<akk> escape doesn't stop it
<apw> hmm, odd.  normally does for me
<akk> nor does ^C
<akk> 12%
<akk> I keep meaning to put these fscks onto some sort of user warning so I can run them manually and they can't hold me hostage at boot time.
<apw> on all my systems using usplash you can hit esc, and they do it next time
<akk> ah, I like seeing the boot messages so I'm not using usplash
<apw> a downside is you can't stop the fsck it seems
<akk> yep!
<akk> I didn't know usplash did that
<apw> the other trick is to reboot with the power out which prevents it occuring
<akk> With which power out?
<apw> the power cord, if it has a batter of course
<akk> oh, cool! It doesn't fsck on battery?
<akk> (This is a desktop, so I don't have that option, but that's great to know for the laptop)
<apw> nope puts it off to next time, if its a '30 boot is enough' type check
<akk> yeah, this is a 29 times check
<akk> I've been superstitious about booting on battery power, because some past ubuntu version set performance to low for the duration of the session when I did that.
<akk> Probably with laptop-mode and so forth, that's no longer a problem and I should try it again.
<jjohansen> you could just edit your fstab and then you will never get an fschk on boot
<akk> jjohansen: That's what I've been meaning to do -- but only after I put a check and warning somewhere else, otherwise I might forget to ever do it.
<akk> I've heard assertions that really there's no point in fsck'ing ext3 anyway and it's safe to go without, but I'm not sure whether to believe it.
<akk> yay, done. Now what was I checking? :) oh yeah, pasting the menu.lst lines
<akk> http://shallowsky.com/tmp/grublines.txt
<akk> oh, the static /dev is screwed up on that jaunty partition, so I am indeed doing something stupid
<akk> yeah, that was it
<akk> it boots with root=hda5 ... so my problem was not realizing that root=UUID= required an initrd.
<akk> Thanks for the help!
<apw> akk you are welcome
<DGMurdockIII> any chance to get this fixed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/277749
<JanC> DGMurdockIII: you didn't provide the info that Chris requested yet?
#ubuntu-kernel 2009-05-16
<Kano> hi, could somebody merge 2.6.30-rc6
<Loco> Hi. I just upgraded to Ubuntu 9.04. Now my MP3's play verry fast most of the time. It does not matter what app I use to play them or what size or bitrate they were made at..Any help would be apreciated.
<Nafallo> mode +c would be appreciated as well :-)
<vertix> i am having a hard time with booting 8.10 because of mixed drive configuration. I have IDE and SCSI (sata) drive. BIOS is set for IDE to be 1st drive. But when I boot from livecd, it becomes 2nd drive and when i regenerate grub and put it on MBR, it thinks it is 2nd drive (hd1) for grub. So, when you boot from grub and escape to commmand line, you are seeing that / partition as drive 1, not 2
<vertix> and so all other partitions are on the wrong drive and fsck exits with error, because it is trying to check the wrong partition type, because what it is checking is not on the right drive
<vertix> basically, what it boils down to is this: looks like you need to change the drive order in bios before you boot from livecd. then, do grub>find /boot/grub/stage1, specify kernel and do a setup, but before you start booting it, you need to go to bios and change drive order, else you won't be able to boot because what grub/kernel think of drive/partition order when you were generating grub, is not the same as when you BOOT
<vertix> btw, i am talking about the case when you already had 8.10 installed and are trying to fix the MBR that was wiped out by windows install after ubuntu, in which cause you already have your system, except your MBR needs fixing
<vertix> and interesting thing is that even if you refer to drives via guid (in grub's menu.lst), it still does not help
<mjg59> I suspect you're misdiagnosing this
<mjg59> The kernel ignores bios drive order
<vertix> could be
<mjg59> Whereas grub pays attention to nothing other than bios drive order
<mjg59> So either you don't get a kernel or you don't get a root filesystem
<vertix> unfortunately that is not what i am seeing
<mjg59> If you get a kernel then grub works fine and it's not a bios drive order issue
<vertix> what i see is grub seeing the same drive order as in bios ONLY when you get a grub> prompt. after that, at some point, the drives are swapped and if you manage to boot, your drive order is going to be different than what bios says
<mjg59> The kernel doesn't care about bios order
<mjg59> If you see any output from Linux then your issue has nothing to do with that
<vertix> well, but the thing is, i get an error at the point when root partition is attempted to be mounted
<mjg59> The kernel sees all disks and will use the appropriate uuid
<vertix> yes, i saw some of that, except in my case, my ide drive was addressed not as guid because it had old grub from old redhat and i don't recall it being addressed as guid, but lemme see here
<vertix> well, what i am seeing is menu.lst is not addressing the ide drive as guid. i don't remember exactly now, but it could be that i just copied the grub sections from ide drive (where redhat is installed) to the sata drive (where ubuntu is installed, just to be able to boot any one of them. could this cause some problem?
<mjg59> menu.ls tis only parsed by grub
<vertix> btw, do you know at what exact point in the boot sequence the grub's device.map goes into effect?
<mjg59> In grub
<mjg59> If grub can see your kernel then device.map is fine
<vertix> grub CAN see my kernel, but it is on the wrong drive. becasue when that grub was generated, the drive order was different. What i am seeing is this:
<vertix> when you boot and escape from grub, the drive order is the same as bios
<vertix> but at some point in booting sequence, drive order is swapped, and if you manage to boot, then what bios says as drive 1, actually becomes drive 2
<vertix> so, at some point, the drive switching happens
<vertix> the question is exactly when and why?
<mjg59> I have no idea what you mean
<mjg59> The kernel doesn't use the BIOS drive order
<mjg59> There's no swapping
<mjg59> Kernel drive order has never had anything to do with BIOS drive order
<vertix> well, but this is not what i am seeing
<mjg59> So 0x80 may end up has hdc
<vertix> there IS swapping and it is even discussed in GNU's grub documentation somewhere
<mjg59> Or sdb
<mjg59> Or whatever
<mjg59> But if grub is reading the kernel then BIOS drive order is entirely not what you are having a problem with
<vertix> you see, grub comes up from MBR of the drive that is set to be drive 1 in bios, doesn't it?
<mjg59> Either grub is reading the wrong configuration file or your uuid entry in the grub config is wrong
<mjg59> No
<vertix> or "active partition"
<mjg59> grub is launched from whatever partition the BIOS boots
<vertix> correct
<mjg59> The rules for that depend on the BIOS
<vertix> yep
<mjg59> grub then reads stage 1.5 and stage 2 off the disk
<mjg59> If that works then grub and the bios agree on drive ordering
<mjg59> Which means devices.map is correct
<vertix> yep, i am asking about that device.map. at what point that device.map is being looked upon or takes effect in boot sequence?
<mjg59> Neve
<mjg59> r
<mjg59> It's only read when grub is being installed into the boot sector
<vertix> assume my 1st drive (in bios is ide), 2nd drive is sata. after kernel comes up, the sata drive shows as sda, not sdb, and ide shows as sdb. why?
<vertix> oh, i see
<mjg59> Because the kernel enumerates in PCI order, not BIOS order
<vertix> so, i need to change the drive order in .map file and THEN regenerate the grub?
<mjg59> No
<vertix> cause what i am seeing is drives swapping around
<mjg59> If grub is running then devices.map is correct
<mjg59> The drives are *not* swapping
<mjg59> BIOS order has nothing to do with kernel order
<mjg59> You can't make them consistent
<vertix> then i don't follow it? why do i see different drive order when just starting to boot and when i am booted?
<mjg59> You don't
<soren> Well, that's exactly *because* BIOS and kernel disk ordering are completely unrelated.
<mjg59> Right
<mjg59> You can't change the BIOS order
<mjg59> And you can't change the kernel order
<mjg59> devices.map exists just to tell grub how to get from kernel order (which it can read) to BIOS order (which it can't)
<vertix> ok, assume i start booting. i escape from grub and do grub> find /boot/grub/stage1
<Nafallo> ehrm. my laptop have two devices in their... I must have installed with the external plugged in :-P
<Nafallo> s/eir/ere/
<vertix> what I am seeing is stage 1 is not on the same drive as when i was booted from live cd and generated the mbr
<mjg59> That's not what you were saying
<mjg59> It's helpful if you explain your problem rather than what you think your problem is
<mjg59> So grub is reading the wrong config file?
<vertix> mjg59, basically, my question is simple: how do i make it boot? are you saying that when i generated grub, i should have done something different?
<mjg59> You're not saying what's going wrong
<vertix> kernel can not mount root partition because it is on the wrong drive
<vertix> and when it does fsck, it says one of partitions is bad, because again, it is looking at the wrong drive
<vertix> could it be because of initrd?
<mjg59> If the kernel is booting then your problem is unrelated to grub
<vertix> you see, i was able to get it booting at some point
<mjg59> It could be the initrd
<vertix> kernel is not booting. it can not, because it can not mount the / 
<mjg59> If you manage to end up with an initrd that doesn't contain drivers for your filesystem then you'll see that
<mjg59> If the kernel didn't boot then you wouldn't get that message
<mjg59> The kernel has loaded. It's executed. The initrd has then failed.
<mjg59> eAnyway. 1:40AM here, so I'm sleeping.
<vertix> well, the boot sequence started. because grub was told the actual correct root partition, but when boot process tried to mount /, it complained. it could be that driver for sata was not loaded. i don't argue that
<vertix> k, thanx for your time
<pong> Hi
<vertix> my box got infected with rootkit and it looks like it progressed pretty far and now my cdrom drive does not work as advertised
<vertix> looks like bios is infected and when i insert the rw+ disk into it, it starts doing something with the disk and, after a while, reboots the box
<vertix> but when i insert the blank CD, then I see the message from ubuntu saying: blank disk is inserted
<ikonia> how is this anything to do with a kernal ?
<vertix> I am not sure it is a good idea to write anything to that disk, cause there is no guarantee that it is not going to add some viruses to the image
<ikonia> this is a.) nothing to do with ubuntu-kernel b.) interesting to hear as you said you couldn't boot ubuntu 
<vertix> well, I am curious if someone knows that in case bios is infected, will it percolate to kernel?
<ikonia> nothing to do with ubuntu-kernel
<vertix> ikonia, why are you following me around and provoking some ugly stuff?
<vertix> what does it have to do with YOU?
<vertix> what is YOUR problem?
<ikonia> I'm not following you, I was here in this channel when you joined, please read the /topic
<vertix> and I know enough about kernel level issue to see what does it have to do with what
<vertix> Yes, you ARE following me
<vertix> here, than on #linux
<vertix> what is that you want froim me?
<ikonia> I was in this channel before you joined as I was in ##linux before you joined also 
<vertix> What is this ugly spying trip you are involved in?
<ikonia> vertix: if your bios is infected with a virus is nothing to do with #ubuntu-kernel, plus I can't see how this is anything to do with ubuntu as you explained you can't boot ubuntu 
<vertix> ikonia, I am not interested in your opinions
<ikonia> vertix: the topic is "ubuntu kernel development only" 
<vertix> you can just do all other exciting things you normally do
<ikonia> please check the /topic
<vertix> ikonia, one more time: I am not interested in YOUR opinion? Is that clear enough?
<vertix> I have seen one of your opinions and it is totally off the wall
<ikonia> vertix: one more time - respect the channels topic
<LjL> vertix: please stay on topic.
<vertix> I never had a single chance to work
<vertix> and I would have to spend half a day doing the most stupid thing in the world
<vertix> so, could you stay away from me and mind your own business?
<ikonia> thats not our problem, follow the channels topic, please. 
<vertix> the topic is this:
<ikonia> the topic is displayed in /topic 
<vertix> can virus potentially affect the cdrom drivers
<vertix> kernel level
<LjL> No, the topic is: "KERNEL BUG DAY 12-May-2009 | Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest news: Released 2.6.28 kernel for Jaunty/9.04. | Kernel git trees: http://kernel.ubuntu.com/git | Latest kernel upload: 2.6.28-12.43 based on 2.6.28.10 final"
<vertix> k, I see, thanx anyway, I guess you have better things to do in your life
<ikonia> thanks, 
#ubuntu-kernel 2009-05-17
<SEJeff_home> What would it take to build the Creative X-fi kernel module against Hardy/Intrepid/Jaunty kernels and put them in a ppa? Much like the kmod-* rpms in fedora.
<dtchen> i'm working on that
<SEJeff_home> dtchen, On this? http://mailman.alsa-project.org/pipermail/alsa-devel/2009-May/017332.html
<dtchen> dkms-izing unstable and stable git snapshots, yes.
<dtchen> it should be done by the end of UDS
<SEJeff_home> dtchen, Fantastic! If you need any help let me know.
<dtchen> well, there will be a call for testers, of course
<SEJeff_home> Great, I can test Hardy and Jaunty with real hardware
<SEJeff> Oh and will that be in the ubuntu-kernel ppa?
<dtchen> no idea; that will be discussed at UDS
<dtchen> it's a bit tricky, since alsa-driver is increasingly relying on additional hints that necessitate udev-extras and alsa-utils
<SEJeff_home> dtchen, Understood. Please keep the world posted
<dtchen> hmm, we should also bump the HDA buffer from 64 kB. at least openSUSE's and Fedora's kernels do so.
<dtchen> $ cat /proc/asound/card0/pcm0p/sub0/prealloc*
<dtchen> 64
<dtchen> 32768
#ubuntu-kernel 2010-05-17
 * apw waves
 * smb waves back
<apw> bah this UDS-lag sucks
<smb> Like a week of travel. :)
<apw> LOl
 * apw pokes lag
<smb> apw, lag?
<smb> apw, Or you look for naga
<smb> Which seems to be the same
<smb> Doh!
 * apw watches the cogs turn
<lag> apw: I thought you called me =:-(
<lag> apw: Oh, you did!
<lag> Hello all
<smb> lag, Indeed he did. Hello
<lag> smb: Hello yourself :)
<apw> called is a little overstated, i more jiggled the cage to see if you lived
<lag> I assumed you were reminded of my existence by your UDS comment 
<apw> heh, no, it was on my mind anyhow... after t
<lag> Yes, I've been here since 7:30hrs (ish)
<apw> the discussion at UDS of how hungover we all will be after UDS
<apw> the week which follows is always low energy
<lag> I had a similar week on my holiday 
<lag> This week will be de-tox 
 * apw needs a cuppa ... this is going to be hard day
<amitk> welcome lag 
<lag> amitk: Thank you - It's good to be here
<lag> all: How did UDS go?
<apw> lag, a log hard slog, but i for one thought i had a very productive week
<smb> Hey amitk and cking 
<apw> if you are interested in the sessions you can see the schedule: http://summit.ubuntu.com/uds-m/
<cking> morning!
<apw> cking, lag (lee), lag, cking (colin troll)
 * apw does intros
<apw> not so easy to grok without the hand to wave about
<lag> I believe we've met
<lag> (I called him eking =;-) )
<apw> heh
<lag> cking: Good morning 
<cking> lag, good morning! and welcome!
<apw> lag, you'll be interested in the stuff on the Kernel track and Ubuntu_on_ARM tracks i be reconing
<amitk> hey smb, apw, cking
 * apw smiles at amitk 
<apw> (thats about the only bit of me which is working)
<lag> apw: Looking at the schedule now
<cking> lag, you got the necessary info to get up and running?
<lag> cking: Not yet - waiting on IS
<cking> lag, that sounds familiar
<amitk> they're probably backed up because of UDS
<apw> lag, the root of our team documentation is (currently) here https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
<apw> if you run out of things to do/read on your list you can start reading on there
<apw> we try and get all new people to learn the basics so they know why we do things
 * lag thanks apw
<cking> ..and please ask us questions!
<lag> "A very good place to start..."
<lag> cking: Don't fear. I am not adverse to asking (stupid) questions 
<apw> yep.  our docs are crap, you are expected to not find the information you need, and ask for help, and _required_ to update the docs to fix them
<apw> it being a wiki and all
<Daviey> apw: Talking of things to do.. :)  At UDS i spoke to you about Bug #576601, it's got 24 "me too's" and would like to try and get it moving - but not sure how to proceed.
<ubot3> Malone bug 576601 in linux "mcp89 sata not detected" [Undecided,New] https://launchpad.net/bugs/576601
 * lag shudders at the thought of documentation 
 * apw curses apple under his breath
 * Daviey curses louder.
<apw> Daviey, does this machine work on Lucid ?
<Daviey> apw: no
<Daviey> apw: Boooting via non-SATA works.. ie USB.. 
 * apw dropships you a fast usb stick :)
<Daviey> The COMRESET in the BootDmesg seems the interesting part.
<Daviey> apw: Yeah.. that sucks :)
<apw> Daviey, yep, looks a lot like a broken sata chipset
<apw> [   61.181006] applesmc:  - Model with 12 temperature sensors
<apw> what a waste of h/w
<Daviey> and a light on the lid isn't a waste of electricity either! :)
<apw> and you bought this bundle of joy why?
<Daviey> IBM/Lenovo annoyed with aftersales of my current laptop, Dell wouldn't deliever until June, and a friend told me it would be the BEST descision i had ever made..  Oh, and it's shiny!
<Daviey> Doesn't mean i'm sold on the idea. :)
<cking> Daviey, tried libata.force=1.5Gbps?
<Daviey> cking: purely that option?
<cking> it's just a guess
 * apw suspects the friend needs a macbook sepository
<apw> cking, didn't know you could do that, interesting
<apw> smb, rember those ones which do something similar, where 'waiting for a bit' makes the issue go away
<apw> Daviey, i think we saw that if you waited long enough you get to a busy box prompt
<apw> we have found in some cases that simply asking the machine to boot from there sometimes works, and it would be good to try that test
<Daviey> apw: i tried rootwait and rootsleep=260  , however it was
<smb> apw, You mean the rootdelay stuff?
<apw> smb, yeah
<Daviey> oh yes, rootdelay, not rootsleep
<smb> 260 "should" be long enough
<cking> hrm, another heck to remember
<cking> s/heck/hack
<Daviey> ok, i'll try the speed force.
<apw> cking, i suspect that is not going to work as we claim to be doing after a bit
<apw> [ 56.122620] ata1: COMRESET failed (errno=-16)
<apw> [ 56.122680] ata1: limiting SATA link speed to 1.5 Gbps
<Daviey> cking: no dice on the speed limit.
<cking> rats
<Daviey> apw: I do get a busybox.. but no sata
<apw> busy box just means no disks in this context
<apw> how is the disk controller described in lspci (if busy box has it)
<Daviey> bah.. i just crapped out of it.. /me reboots
<apw> man this machine is a living nightmare h/w wise, how much closed unsupported components can you put in one box
<apw> shiney or not
<Daviey> apw: booting via usb, everything does seem to work except sata
<Daviey> lspci isn't in busybox :(
<lag> daviey: Is this any good to you? ftp://ftp.kernel.org/pub/software/utils/pciutils/
<lag> Sorry "Daviey" - Is the nick alert case sensitive? 
<Daviey> nah :)
<lag> Daviey: It's not good to you, or nick alert isn't case sensitive? 
<apw> Lag ...
<lag> apw: Nothing
<Daviey> nick alert not case sensative
<lag> again
<Daviey> apw: networking isn't up, is BusyBox gaining me anything that i wouldn't get in a live enviroment?
<Daviey> apw: Sorry, i went afk
<apw> Daviey, probabally not no
<Daviey> apw: In that case, isn't lspci the same as the one on the bug report?
<apw> Daviey, maybe maybe not, you didn't put it in right?  i don't trust your two apples to be one and the same
<Daviey> apw: Hmm.. ok. I'll compare it with mine today, and upload it if it diff's
<apw> i have learned not to trust any vendors to tell us when they skew a machine
 * smb is slowly waking and congratulates cking for having no critical mass incidents on his way home
<Daviey> apw: I do know someone else bought one on the same day, from the same supplier.. so we can certainly prove them identical.. Unless one of them includes special Jobs fairy dust. :)
<cking> smb, we had a delay of 50 mins, but no asteroid strike or earthquake - so it was a good return trip
<smb> cking, Good to hear.
<smb> (actually knew since apw was home by the time I was)
<apw> heh, i could have been home, though i was out at a pub as it was a friends hen-do
<cking> smb, thanks again for driving us to the station
<smb> apw, Isn't that "sort of" home :-P
<apw> yeah much appreciated, specially the 1.40 beers
<apw> *slap*
<smb> cking, apw No worries. Was a good time, too. :)
<smb> apw, I was hiding. Not sure who you hit. ;-)
<amitk> apw: hen-do?
<apw> amitk, womans stag-do
<smb> amitk, Don't ask. It will certainly involve funny dressing and lots of beer
<cking> that's infinitely clearer
<amitk> lol
<apw> celebration/commisseration of the upcoming lack of freedom engendered by marriage.  generally as indicated by playing games and getting very drunk and falling over
<apw> yay the ask is back
<jk-> morning
<jk-> .. or something
<cking> apw, the ask?
<smb> jk-, Definitely .... something
<cking> jk-, good [morning|aftenoon|evening]
<amitk> more like, good whatever
<jk-> or maybe good `warning: enumeration value not handled in switch`
<apw> cking, ash
<apw> jk-, erm, what you doing up at this time
<apw> jk-, heh
<jk-> apw: so UK hen's dos include men too?
<apw> jk-, not commonly, but this one did include all her friends
<smb> jk-, Or apw is honours woman (or whatever thats called)
<apw> honary woman
<smb> apw, Ah ok. :) At least there now should be enough wigs around, too. 
<apw> smb, and boobies
<smb> There is no limit on what one does for free beer. :-P
<popey> Daviey / apw I do have my mbp with me here, so if there's anything I can do to test, lemme know :)
<Daviey> popey: fancy seeing what freebsd are doing differently? :)
 * popey looks for a live freebsd iso
<popey> livecd-1.2.4.tar.gz (24.2KB) <- looks like a very heavily optimised kernel they have there.
<Daviey> popey: try your left coat pocket.
 * apw wonders whether these machines have bios modes for the sata controller, AHIC and something else?
<Daviey> apw: it's EFI, which means that bios modes are a PITA to change.. /me is an EFI n00b, so i may be mistaken.
<apw> this is a tricky one, the co
<Daviey> from my reading, i wanted to change the SATA compatability mode.. but nfi if you can.
<popey> Daviey: learn FORTH :)
<apw> the controller appears to be an early one in the series, and supported for some time
<apw> so its somewhat enexpected it doesn't work
<apw> smb, is there a general way to disable MSI ?
<Daviey> apw: yeah.. i understand some COMRESET issues were introduced after 2.6.24, so i tried hardy.. but i don't think hardy supported the chipset yet.. so rock and hard place.
<smb> apw, nomsi I believe
<apw> apple are the pits
<apw> Daviey, may be worth booting nomsi to see if that changes thigns
 * Daviey checks his notes
<Daviey> hmm, that is one i haven't yet tried.
<Daviey> popey: If you have a few moments, fancy doing that?  Booting with the kernel line, s/quiet splash/nomsi/ ?
<popey> sure
<Daviey> cool
<popey> hold C to boot from CD, then press something at the accessibility prompt?
<popey> still getting the COMRESET failed 
<popey> and then it still can't find /dev/sda sadly
<Daviey> popey: ah well... worth a try
<popey> yup
<apw> Daviey, popey what you running bits wise?  32/64?
<popey> that was a 32-bit official shipit cd
<apw> Daviey, you have a USB install i think yes?
<popey> i do, but it wont boot on this machine
<popey> due to it needing refit / efi stuff
<Daviey> apw: yes.. can boot to a live enviroment via usb
<popey> hmm, could I use the cd and usb together?
<Daviey> popey: yes
 * popey needs learning how to do that
<popey> root=something initrd=something? 
<Daviey> popey: insert usb pendrive, insert cd.. boot from CD and select Try Ubuntu without installing.
<popey> that it? :)
<Daviey> yeah, when the cd fails, it'll hand over to the USB... ugly but easy.
<popey> seriously, no interaction required, just boot off cd with usb attached?
<Daviey> popey: yes
<popey> blimey
<apw> normally in this kind of mess i install from the CD to the USB, so that whats on the USB is a bootable real root image, that then lets you replace the kernel and test
<apw> as the next step is going to be test kernels me thinks and someone has to be able to test them for them to be of use
<popey> if i can get it to boot off usb then i can certainly do that testing
<apw> i've turned on ata debug and added some specfic debug for the EBUSY that is being reported, hope that can provide some clues to someone
<popey> Daviey: I'm just getting a blinking cursor after choosing try ubuntu. no flashing on the usb stick.
<popey> ah, spoke to soon, patience
<Daviey> apw: yeah, in order to have a non-casper usb.. would need to sort of the UEFI stuff; which i haven't yet done
<apw> Daviey, how much spondoolies does this heap cost ?
<Daviey> apw: don't ask :)
<apw> cking, do you have any uefi platforms for testing?
<Daviey> apw: around Â£1k
<apw> ouch
<popey> indeed
<cking> apw, I have an intel box with reference UEFI firmware
<Daviey> "Best decision you'll ever make".. still pondering that statement.
<popey> Daviey: jfo tweeted me saying he's building a usb stick of this type :)
<apw> "beacuse you will be forced to run Mac OSX, and we will get you" perhaps
<Daviey> apw: Lucid might LOOK like OSX.. but you shouldn't confuse the two :P
<cking> apw, the Mac has non standard firmware that'sfor sure
<apw> Daviey, if it boots from a USB install of the live CD, could you not make the USB real-root on another machine?
<apw> cking, so no value in you having one then
<apw> and damned expensive either way
<cking> apw, indeed
<Daviey> apw: yeah, but the hack i was using to get a live env', was the cd failing - and happening to find the casper on the usb stick by luck.
<Daviey> so, i could be wrong; but i think booting real root USB requires EFI support.
<popey> yup, i believe so too
<Daviey> dunno why it supports legacy CD, but not legacy USB from boot.
 * apw tries to understand ... there is no 'F12' to chose where to boot?
<Daviey> correct
<popey> you hold down C to boot from CD
 * apw puts this machine in the 'not suitable for purpose' bucket
<Daviey> apw: to set a "bios password", you need to use a graphical app in the OS!
<popey> or learn FORTH :)
<apw> in the 'other' OS i assume
<apw> well forth is pretty easy
<Daviey> yeah..
<apw> its just reverse polish
<Daviey> i am pretty new to this EFI voodoo tbh.
 * popey decides not to teach his mum FORTH
<apw> i had a reverse polish calculator once
<Daviey> apw: That is on my xmas stocking list, for sure.
<cking> doesn't everone do math in reverse polish?!
<apw> intelligent people only of course
<apw> Daviey, popey, so its not clear you are going to be able to test a kernel will your current 'access' to this h/w
<popey> well, jfo said he was making an efi bootable usb image for kernel testing
<popey> which would help
<Daviey> apw: Given a kernel, i can either re-create a casper image, or learn EFI support... either i'm keen to do if it helps speed a resolution.
<Daviey> or what popey said.
<apw> we have next to no information other than the links are deemed not up, so i've turned on all the debug there is and added some for the errors you are reporting
<apw> we'll have to see what that produces if anything
<Daviey> apw: For the kernel autobuild?
<apw> i am building a i386 kernel with those modifications now, and will hope you can test with it
<Daviey> super
<Daviey> popey: any news on jfo's build?
<Daviey> i'd rather dd, than do it myself :)
<popey> Daviey: http://twitter.com/jeremyfoshee/status/14135364460 is all i know
<eipi-1> how long does it take until the new kernel 2.6.34 is in the kernel ppa?
<amitk> eipi-1: probably by tomorrow if the automated scripts don't fail
<eipi-1> amitk, thx
<tgardner> eipi-1, it'll likely be Wednesday. ogasawara is out today.
<cking> the post UDS TZ changes are killing me ;-)
<tgardner> cking, my sympathy is limited. I made it all the way until 0430 today.
<cking> owch
<apw> eipi-1, are you talking about the mainline kernel builds ?
<apw> if so they will be about another 8 hours as there are a heap of other ones building
<eipi-1> apw, yes
 * apw blames smb for all the 5 digit ones
<eipi-1> apw, perfect thx
<smb-afk> apw, Not that I have changed that much. Must be you automation. :-P
<apw> hey lag whats your launchpad id ... we'll need that to get you on the right groups
 * apw pokes lag
<lag> Oh, hello
<lag> 2 secs
<lag> Is there any way to change it to one that's already taken? 'lag' is used by someone who signed up in 2006 and hasn't logged on since.
<amitk> don't think so, unless they delete their accounts
<lag> That sucks
<lag> In which case, I'm ljones
<lag> :(
<smb> lag, In theory it is possible but requires to convince certain people and then might mess up some other things.
<smb> lag, So probably now or never.
<lag> Now would be good
<lag> I don't have anything else to do 
<lag> Still waiting on IS for other things
<amitk> lag: you could try writing to them..
<lag> Okay
<lag> They have an IRC channel
<JFo> so... btrfs in Lucid... we don't support it, yes?
 * smb wonders whether that was a question or statement
<smb> JFo, no
<apw> it hink he wants it to be a stement
 * apw orders some keys up for his keyboard
 * JFo has a bug report on btrfs
<JFo> I want it to be :)
<smb> apw, I meant lag but was too slow
<apw> whats the report
<JFo> bug 578742
<ubot3> Malone bug 578742 in linux "Btrfs device balancing does not work" [Undecided,New] https://launchpad.net/bugs/578742
<apw> JFo, hrm, thats a kernel panic on a userspace command, not wonderful
<pgraner> JFo: punt to cjwatson
<smb> apw, I am not aware that btrfs is enabled at all
<JFo> pgraner, will do
<apw> debian.master/config/config.common.ubuntu:CONFIG_BTRFS_FS=m
<apw> smb, from lucid
<smb> apw, That much for having experimental stuff not turned on. :/
<apw> i suspect we got asked to add that one, just so people could experiment with it, we should ahve a list of 'EXPERIMENTAL but on and NOT supported' features
<JFo> and I had a nice "HA! but no." message all queued
<pgraner> apw: sounds like a good topic for a wiki page
 * pgraner ducks
 * JFo giggles
<smb> We finally have a volunteer. >.-)
<JFo> :-P
<apw> sounds like something the kernel release manager would produce as part of a new release
<pgraner> apw: just kneecapped ogasawara
 * apw hums innocently
<pgraner> apw: thats cold bloooooded
<JFo> UNITY!!!
<apw> i have my moments :)
<tgardner> JFo, btrfs in Lucid was a technology preview. we are not supporting it officially until Maverick
<apw> unison ?
<JFo> right
<JFo> I just wanted to make sure before I spanked the OR
<JFo> :)
<apw> smb, i would think an appropriate response to that problem might be to disable the ioctl it uses in the kernel :)
<smb> apw, Rather remove the whole module. Or mark it as taint crap
<JFo> so cjwatson says thusly: "not too bothered yet, assuming that it can be forwarded upstream and fixed in maverick; at this point, given the lack of userspace support, I only care about problems that would make it difficult for us to implement that support"
<amitk> tgardner: we're supporting btrfs in maverick? I thought it was optional at install time...
<apw> if its not EXPERMIMENTAL its supported at the kernel level right?
<smb> amitk, Have you listened to the wrap up talks at UDS? ;-)
<tgardner> amitk, right, its not going to be the default FS, but it _will_ be an option.
<tgardner> at least that is the plan, unless its so shite that its unsupportable (which is unlikely)
<amitk> smb: yes, with the alertness of a sloth
 * JFo throws up his hands
 * apw wonders what jfo will use to catch them
<amitk> :)
 * JFo calls the whole thing off
<JFo> :)
 * amitk relocates to the balcony
 * smb would freeze if he did that
 * amitk relocates back to the office, damn screen is unreadable in the glare
<eipi-1> can someone explain me why linux-headers-generic depends on linux-headers and how to resolve it? (I downloaded it from the mainstream kernel-ppa)
<apw> eipi-1, ?
<apw> there are two headers packages normally
<apw> one flavour specific and one common one, you need both
<smb> apw, He might refer to the meta packages
<apw> we don;t 
<apw> we don't have meta in the mainline builds tho.
<eipi-1> apw, stupid, i missed that. sorry
<smb> ah right, missed the kernel-ppa part
<apw> pgraner, i noted that ogasawara seems to have some additional blueprint foo to set goals and the like on our blueprints, i wonder if thats something we can spread around the planners
<apw> anyhow, we have one blueprint with no owner, seems someone should own: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-arm-single-zimage
<ogasawara> apw:  I thought that one was ericm's?
<apw> it maybe, but isn't his at the mo
<ogasawara> apw: and I actually thought I assigned him to be the owner
<apw> so we'd better shove it to either him or to jk imo
<apw> ogasawara, its not taken if you did
<ogasawara> apw: I'll follow up with them to get an owner assigned
<apw> yay leanns problem, i like those kind
<apw> ogasawara, arn't you off today?
<ogasawara> apw: I am, but I woke up early and no one else is awake yet
<ogasawara> apw: so I figured I'd check email etc.
<smb> ogasawara, keybaddict! :)
 * apw slaps ogasawara 
 * ogasawara slowly steps away from the keyboard
<smb> apw, Next we get told "I can stop anytime... if I want to" :-P
<ogasawara> heh
<cking> gotta pick kids up from school, back in 35-40 mins
 * psurbhi steps out for a while to run some errands
 * apw pops out to get a new flus
<apw> flush ... yes he does
<JFo> interesting: bug 574462
<ubot3> Malone bug 574462 in linux "udisks-probe-ata-smart causes HSM violations" [High,Confirmed] https://launchpad.net/bugs/574462
<tgardner> JFo,  I've been sort of poking at that one. I think its drive or host controller related.
<manjo> apw, what is a flush?
<apw> the bit in your loo which makes the flush occur
<JFo> tgardner, sounds interesting 
<tgardner> JFo, I guess thats one way to put it.
<JFo> heh
<pmatulis> on the generic kernel in lucid, what is the limit on recognized memory?
<tgardner> pmatulis, 32 bit?
<pmatulis> no, this is a 64-bit system
<tgardner> pmatulis, I'm not aware of any practical limit. apw?
<pmatulis> system is supposedly seeing 16 GB but has a lot of random crashing.  was thinking it might be a limitation of generic
<pmatulis> it's a desktop
<tgardner> pmatulis, no, thats well within the norm for RAM quantity
<pmatulis> oh well, thanks
<tgardner> pmatulis, have you had them run the memory test? or this generic across multiple machines?
<tgardner> is this*
<pmatulis> tgardner: funny that, memtest *fails*, the test doesn't run
<pmatulis> tgardner: i think it's a separate problem involving the BIOS
<tgardner> that sounds a bit strange to me
<pmatulis> tgardner: to me too.  userspace memtest binary works however
<pmatulis> (memtester)
<pmatulis> it's a HP Z600 Workstation
<apw> tgardner, no limits i am aware of no
<apw> if there was a limit i would expect you to miss memory not to have crashes
<apw> pmatulis, ^^
<apw> do you have a boot dmesg from it, you can tell how much ram and where it is from that
<pmatulis> apw: https://pastebin.canonical.com/32340/
<cking> cnd, does ftrace work reliably over S3 suspend/resume cycles?
<cnd> cking: I would assume so, but I've not tried
<cking> cnd, it seems to fail on a box I'm working on - can you sanity check that it generally works for you?
<apw> pmatulis, well its showing around 16GB of ram
<pmatulis> apw: alright, thanks
<cnd> cking: how urgent do you need a response by?
<cking> sometime today if poss
<apw> cking, does virtualbox use any kernel support for virtualisation?
<cnd> cking: ok, I'll get back to you in a bit
<cnd> JFo: no regression review today right?
<manjo> JFo, are you going to have the regression call ? 
<JFo> nope
<cnd> cool
<JFo> giving you guys a break, plus we will be changing the meeting around a biot
<JFo> errr bit
<JFo> so I will need some time to communicate that
<manjo> JFo, k thanks
<JFo> my pleasure
<vanhoof> JFo: been up since 3am working? ;)
<JFo> heh
<JFo> feels like it
<vanhoof> JFo: looks like we made it out just in time
<vanhoof> JFo: ash cloud is back in action
<JFo> vanhoof, yeah, I am thankful
 * vanhoof is not ;)
<JFo> lol
<JFo> well, you know what I mean :)
<apw> JFo, smb, !ogasawara, apw (!), ... are we doing the regression call?
<JFo> we are not
 * smb wonders where apw has been the last few minutes
<JFo> he was dreaming of trays bangign together
<smb> lol
<apw> i was buying a new flush
<apw> so ner
<cnd> ppetraki: on the psmouse reset fix, the easiest way to get it into releases of Ubuntu is to send it to stable@kernel.org
<smb> cnd, When it has hit upstream
<cnd> it will end up in one of the stable releases for 2.6.32, and the change will get merged into our kernel when it's released
<cnd> smb, ppetraki just sent out an email saying it's been merged upstream
<apw> didn't it just hit upstream according to ppetraki 
<cnd> smb: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef110b24e28f36620f63dab94708a17c7e267358
<apw> so i recon send it to stable yes, but also send it out to kernel-team as it fixes something real for (pre-stable) treatment
<smb> I guess, if it i urgent. Would even have been better if Dmitry would have added cc: stable...
<smb> s/i/is/
<apw> smb, i suspect its one of those OEM things that will run us down like a train
<smb> apw, Likely. Maybe even one of those things were they _should_ tell us if it is already used in some way
<apw> smb, heh yeah
<apw> smb, btw when did you do the 13.3 and 13.4 tags for your tree
 * apw is trying to work out why they are both pending together
<smb> apw, During UDS. Maybe a bad idea
<apw> explains it then ...
<apw> i had cod-execute down for a bit for maintenance
 * apw notes zinc has 7 more hours of builds to complete
<smb> apw, Oh, you meant why they both are new. Not some badness as being on the same commit
<apw> yeah, i was supprised you did both at the same time roughly
<smb> apw, Mind that there is a commit on top of the tags as Greg had this crazyness too
<smb> apw, Doing them together is rather normal in my workflow
<apw> so you do like 12.3 -> 13.3, and 13.3 -> 13.4 as separate steps?
<apw> hense two tags at 'once' there
<smb> Right, I usually update the .32 part first but follow up with the .33 drm immediately after
<apw> smb, ring ring
<smb> (at least as long as upstream/Greg makes updates at the same time)
<cnd> cking: I traced the psmouse module through a resume
<cnd> it worked fine, though the timestamps sot screwed up (like the TSC warping) and then eventually settled back to 0
<cnd> so the timestamps seem relative to the last resume
<cking> cnd, thanks, something is screwy then with my tracing
<cnd> cking: what are you trying to do?
<cking> cnd, just measure func calls thru a S3
<cking> s/measure/capture
<cnd> cking: what happens?
<cnd> do you just lose trace data after the suspend?
<cking> cnd, yep, any idea why it evaporates?
<cnd> hrm, unfortunately no...
<cnd> cking: sounds like you should just throw the machine in the dumpster and get a new one :)
<cnd> that's how I solve my sw problems
<cking> cnd, any idea of how many func calls can be captured in one test
<cnd> blame the hw
<cnd> cking: what do you mean by that?
<cking> cnd, that's why the H/W is on my desk :-(
<cnd> how many func calls before some start to get deleted in favor of new ones?
<cking> cnd, any idea of how many func calls can be captured before the internal buffer gets full
 * cking notes that "no idea" is perfectly valid answer ;-)
<cnd> so first, it operates in flight recorder mode meaning that new events overwrite old events (contrary to how perf drops events if the buffer gets full)
<cnd> however, I don't really know how many events it can store
<cnd> it probably depends on the size of the events
<cnd> and function calls
<cnd> it's all stored as binary data
<cking> yeah, oh well, I will try one more time and then fall back traditional methods aka printk etc
<manjo> cking, are you trying tracepoints in suspend/resume code ?
<cking> manjo, just tracking using ftrace
<cnd> cking: you can check whether it's been turned off somehow
<cnd> by loocking at trace_enabled and trace_on
<cnd> maybe dmesg will give a hint?
<cnd> and check that current_tracer is what you set it to
<cnd> if it's nop, then no functions will be traced
<cking> it's set to "function"
<manjo> vanhoof, ping 
<vanhoof> manjo: pong
<ppetraki> cking, apw, so what else do I need to do to close the loop on 551234?
<apw> bg 5512334
<apw> bug 551234
<ubot3> Malone bug 551234 in oem-priority "touchpad doesn't reconnect after resume: Synaptics ps2" [High,In progress] https://launchpad.net/bugs/551234
<apw> i say submit it to stable, and to kernel-team, the final form patch
<smb> ppetraki, The mail has been sent. We will look at the patch and then possibly take it pre-stable
<ppetraki> smb, cool
<smb> ppetraki, When you ask for this patch to be considered upstream stable, can you cc kernel-team along with dmitry?
<ppetraki> smb, sure, I can do that, anyone else to copy? I saw stable... mentioned earlier
<smb> ppetraki, You will send it to stable@kernel.org (==Greg) and need to cc all on the signed-off-by list (in that case only dmitry). The mail should contain the reference to the upstream patch and saying that this is a bug fix you think should go into .32, .33 (.34?)
<manjo> ppetraki, scripts/get_maintainer.pl should help ?
 * abogani waves
<smb> manjo, ppetraki That helps too in doubt but can be over the top for stable.
 * apw waves back to abogani 
<smb> Hi abogani 
<abogani> apw, smb: Hi :)
<ppetraki> manjo, I'll take a look at it for future reference. Thanks.
<abogani> I would want bother you with one of my usual stupid questions :-D
<abogani> I'm just wondering if in the Lucid life-cycle management you will ever update kernel with a more recent version (that is > 2.6.32).
<abogani> If I don't recall wrong there are time ago a blueprint about it (about updating kernel into a LTS). Sorry i don't have the link.
<abogani> *is
<pgraner> abogani: we will have the Maverick kernel avail when its ready for server only
<smb> abogani, There will be kernels bckported, but only supported for server
<apw> abogani, the default kernel will not change, the backports will be an elective install only
<smb> abogani, MAybe pgraner is also quicker in finding the link to the blueprint
<abogani> smb: That kernel will be available in -backports?
<cking> cnd, how does one clear the trace log?
<apw> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
<pgraner> smb: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-new-kernel-on-lts
<cnd> cking: I believe changing the current_tracer will do the trick
<apw> the kernels will be in main as separate packages
<cnd> cat'ing trace_pipe will too
<pgraner> abogani: no main archive
<smb> apw, wins over pgraner 
<smb> abogani, But will start in a ppa before maverick is released
<abogani> Last thing (I promise :) Why kernel packages not present "Supported: 3/5y" line in apt-cache output?
<apw> abogani, is that something they _can_ report?
<abogani> apw: I meant: If I don't recall wrong there are time ago a blueprint about it (about updating kernel into a LTS). Sorry i don't have the link.
<abogani> Urgh
<abogani> apw: apt-cache show linux-image-2.6.32-22-generic | grep -i supported
<apw> abogani, right but that was definatly the predecessor blueprint to the one i pasted.  we always planned to do elective installs for those
<manjo> cking, have you seen http://lwn.net/Articles/290277/ ? article on ftrace has detailed info 
<apw> abogani, hrm, that supported thing is odd
 * apw investigates
<abogani> apw: I would want let you notice than:
<abogani> apt-cache show linux-image-2.6.32-21-generic | grep -i supported
<abogani> Supported: 5y
<cking> manjo, cheers
<abogani> apt-cache show linux-image-2.6.32-22-generic | grep -i supported
<abogani> No Supported line at all
<apw> nnnng
<apw> will ask
<smb> abogani, Just that for -generic it would be 3y
<abogani> I wrong something?
<smb> abogani, I think we don't know if that ever was possible
<apw> smb, i think the information is coming from outside the packages too
<apw> am asking where it comes from now
<apw> as we've not changed our packaging between -21 to -22 yet one has it and the other not
<apw> i bet its cause -21 was -release and the later packages do not have it...
<smb> apw, Strangeness. But if you find out let me know. I'd really like to see that change to 3y and only to be 5y for -server, too
<apw> seems mvo is the man to talk to, but that there is bugs handlng -updates stuff at the mo
<Sarvatt> yuck, theres one intel pci id that is flickering in lucid because of FBC that is fixed in the maverick kernel, need to track down the commit that fixed it because it seems to be happening to all 8086:2a42 devices
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/538648
<ubot3> Malone bug 538648 in xserver-xorg-video-intel "[Intel GM45] Irregular sync flashes on 8086:2a42 (Needs i915.powersave quirk)" [Medium,Triaged] 
<abogani> pgraner, smb, apw: Thanks!
<apw> Sarvatt, we could just disable FBC for that ID right?
<apw> we have support infrastructure for that ... rather than try and fix it i mean
<apw> Sarvatt, can put that together for testing if that would help
<Sarvatt> we don't though, theres more than one pci id in that generation so i'm not sure how to disable it
<Sarvatt> can't just remove has_fbc from that generation's struct without affecting all of the others, thats why I'm trying to find where it was actually fixed in .34
<apw> Sarvatt, yeah we could, we could clone that ones entry to a new structure and drop it there
<apw>         INTEL_VGA_DEVICE(0x2a42, &intel_gm45_info),
<apw> change that to:
<apw>         INTEL_VGA_DEVICE(0x2a42, &intel_gm45_nofbc_info),
<apw> and copy the structure and drop .fbc=1 ... no?
<pgraner> JFo: damn! Your blowing up my mailbox dude...
<apw> Sarvatt, and anyhow thats the only id using that specific structure
<JFo> pgraner, sorry :-/
<apw> JFo, you expiring bugs?
<Sarvatt> it is?! awesome
<pgraner> JFo: I can tell you're so tore up about it
<JFo> :-D
<JFo> apw, not yet
<apw> Sarvatt, at a cursory look yes it is, even if not we could make that one id use a new one
<JFo> need to check that the fixes are in so I can
<apw> Sarvatt, so 2a42 is the one yes?
<Sarvatt> yeah
<Sarvatt> wish i had one so I could bisect it down
<apw> so that seems to be the only one which uses that structure
<apw> drivers/gpu/drm/i915/i915_drv.c:const static struct intel_device_info intel_gm45
<apw> drivers/gpu/drm/i915/i915_drv.c:        INTEL_VGA_DEVICE(0x2a42, &intel_gm45_inf
<apw> so i recon we can just rip it out for now
<apw> you want me to spin a test kernel for the bug with it torn out?
<Sarvatt> it's still setting up the fbc registers and stuff for all is_i965 (or whatever it is, dont have it open) though, not sure if thats a problem
<Sarvatt> if you could that'd be great
<Sarvatt> quite a lot of people are hit by that problem since thats one of the more common devices these days
<JFo> need food, bbiab
<apw> Sarvatt, no worries
<apw> Sarvatt, building now, will update the bug when they are available
<Sarvatt> thanks a bunch apw!
 * cking enters a new level of S3 weirdness. /me thinks it's time to call it a day
<apw> cking, its time to call it a day
<cking> apw, yeah, made some progress, but it's just gonna have to wait 'til tomorrow now
<cking> yawn
<JFo> k, back
<apw> Sarvatt, those kernels are uploading now, i've updated the bug asking for testing
<Sarvatt> awesome, thanks apw!
<Sarvatt> need to find out if the people saying it was fixed in 2.6.34 were still using powersave=0..
<popey> Daviey: dont suppose you have a guide to respinning an iso with a modified kernel do you?
<popey> or indeed if anyone has such a guide, for bug 576601
<ubot3> Malone bug 576601 in linux "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected" [Medium,Triaged] https://launchpad.net/bugs/576601
<manjo> popey, ping bjf for a script that does that
<manjo> jfo, might know  if it is publicly available 
<JFo> popey, I don't have any docos written, but I plan to wikify the script manjo is talking about
<JFo> manjo, it isn't yet
<JFo> there are some bugs in it
<popey> ok
<JFo> and I need to hash them out
<JFo> sorry popey, but it is on my list much like the uEFI one
<popey> :) no worries
<Daviey> popey: it's on the wiki
<popey> o rly? ou est la?
<Daviey> popey: potted guide, https://help.ubuntu.com/community/LiveCDCustomization
<Daviey> ie, the cheats way :)
<popey> heh
<JFo> mmmm
 * JFo bookmarks for a review :)
 * popey tries this magic
<JFo> bug 581312
<ubot3> Malone bug 581312 in linux "Unknown key fee[x] pressed" [Undecided,Incomplete] https://launchpad.net/bugs/581312
<cnd> apw: thanks for the broadcom fix!
<popey> apw: are you about? I've got the mac booted to your new kernel and could open an ssh port to it if you want to poke it with a stick?
<popey> apw: ran an apport-collect for bug 576601 :)
<ubot3> Malone bug 576601 in linux "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected" [Medium,Triaged] https://launchpad.net/bugs/576601
<achiang> ugh, can't figure out how to remove tags from a LP entry
<achiang> notably, i want to remove the needs-upstream-testing tag from bug 578138
<ubot3> Malone bug 578138 in linux "Thinkpad T400 (model 2765-TDG) fails to resume after second suspend" [Undecided,Incomplete] https://launchpad.net/bugs/578138
<kamal> achiang: I have a pencil icon at the end of the Tags: list I think I can remove it -- want me to?
<kamal> s/list I think/list, therefore I think/
<kamal> achiang: I suppose this is because I'm a member of ubuntu-bugcontrol
#ubuntu-kernel 2010-05-18
<cwillu> mfedyk in #btrfs has just updated the btrfs wiki with instructions for setting btrfs to build from git via dkms in ubuntu and debian;  anyone care to proofread?
 * smb sips some coffee
 * jk- remembers that he started making a coffee about 30 mins ago, and goes to finish it
<RAOF> That's the worst kind of morning tiredness :)
<smb> Too true
<jk-> unfortunately, it's 3:20pm :)
<smb> Just a hell of a long morning then. :-P
<jk-> heh, "for large values of 'morning'"
 * abogani waves
 * apw yawns
<apw> morning lag
<lag> Morning
<lag> I have my Launchpad set-up now :D
<amitk> lag: I see you muscled-out the inactive user :)
<lag> Damn tootin'
<lag> How do you lot keep tabs on everything that happens on all these channels and keep up with your work?
<smb> lag, You don't
<lag> smb: Phew
<jk-> smb just tells us all to shut up until he has time to read IRC
<smb> You can set up a few words that trigger highlighting (potentially with sound) so it gets your attention. But otherwise you normally can only pay attention to one thing.
<smb> jk-, No I am telling you I ignore you most of the time. :-P
<jk-> good advice.
<smb> lag, Except your name is apw, which means you are present and chatting in all channels 24hrs a day. (joking)
<apw> smb, no that is master wats-o-n who will still detect his nick dispite heavy stealthing
<amitk> lag: you ignore the channels unless they are pings to you. And once in a while you scan all of them if you care...
<smb> apw, This has the sound of you-know-who. :)
 * persia notes that several clients allow advanced regexes for highlighting
<amitk> not everyone is cjwatson and can hold 12 simultaneous IRC conversations
<smb> No he said the name. *panic*
<apw> though it is claimed that irssi highlight window is the way
<RAOF> The irssi highlight window *is* made of awesome.
 * persia has started to prefer the quassel "Chat Monitor" window
<apw> persia, is that something in addition to your normal irc client, or do you use quassel
<persia> apw: Right now, I'm only using two clients (my laptop power switch broke), but I usually use several simultaneously to provide the views I prefer.
<persia> The trick is to have some proxy (irssi can do this, and there are many others) so you can have single identity with multiple clients.
<abogani> smb: May I disturb you for a minute?
<smb> abogani, sure
<apw> persia, ahh, i use a bip proxy in general too
<persia> bip+quassel+/bip blreset leaves something to be desired, but ... :)
<abogani> smb: I have placed an update -rt kernel package for Lucid at https://launchpad.net/~abogani/+archive/broken. How I should proceed now? Should I write a SRU justification?
<lag> apw, persia: I was told XChat was the way to go =:-S
<apw> s'what a lot of us use, its one of the easier ones to get going in IMO, it may not be the most powerful
<apw> your irc client is like your editor something you grow into
<persia> lag: I like xchat a lot myself, but the key is to find the client that works best *for you*.  if you set up a proxy, you can try them all with relatively low interference.
<lag> I think emacs does IRC *dribbles*
<smb> abogani, I guess this can be treated a bit like the arm or ec2 packages. In that case I would welcome a short mail to kernel-team list to tell the rational for this change and point to the place on launchpad. Then its possible to discuss it and proceed.
<smb> abogani, Being not the "main" kernel package, the SRU policy can be less strict
<abogani> smb: The problem as you surely know is that a kernel update can contains a lot of commits so it is very hard to write a justification for each of these. :-/
<abogani> smb: In particularly when the packaging is maintained by one only person...
<smb> abogani, Yeah. Having a less-strict policy means, you should get away with general improvement and lots of bug fixes
<smb> abogani, Just generally describe what you have done. Like updated to the latest rt patchset, included the latest stable patches, ...
<abogani> smb: Could I ignore commits introduced by you (in Karmic kernel which are used as base for rt) ?
<smb> abogani, I'd at least say that you rebased (from?) to Ubuntu-2.6.x-y.z whatever. You don't need to go into details. But it is good to know the fact which is the new base of the kernel.
<abogani> smb: Ok, thanks.
<smb> abogani, no problem
<apw> smb, abogani, we should remember that the update should be applied in maverick 'first' according to the rules.  i assume linux-rt is the same in maverick
<smb> apw, abogani As long as it is the same maybe. The kernel package was always problematic with that. If you have individual fixes yes, but the whole package...
<abogani> smb: I would want update -rt kernel in Maverick with 2.6.33 (the latest release by Gleixner).
<apw> in which case its all moot and you can ignore it
<apw> abogani, if you are going to base off of .33 then we should consider using the .33 based ogasawara did during maverick roll forward
<apw> smb, and stable needs to think about how we could maintain that base for ti-omap and this perhaps
<smb> apw, The package in the repo abogani mentioned seems 2.6.31 based (for lucid)
<smb> We may speak of two different versions
<apw> smb, yeah i mean that we will have an updated ti-omap and we'd like that to be on a real ubuntu 2.6.33, and any .33-rt for maverick would like to be on the same base to get all the ubuntu goodness.  seems like an oppotunity to share the base should we do it right
<smb> apw, I partially understand. Though 2.6.33 is sort of a lost thing right now. I have not looked how far that got with upstream stable releases and from now or soon its off for normal updates.
<apw> smb, yeah its not all clear right now
<apw> ericm|ubuntu, https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick perhaps ?
<apw> or http://people.ubuntu.com/~pitti/workitems/canonical-kernel-team.html
<ericm|ubuntu> apw, exactly these two URLs
<apw> ericm|ubuntu, in that case i have no idea :)h
<ericm|ubuntu> apw, both are useful
<apw> :)
<ericm|ubuntu> though the color "green" is making my eyes bleeding
<apw> ericm|ubuntu, its not the best colour
<apw> ericm|ubuntu, if you are adding blueprint work items remember that the work items section and the items themselves are computer readable and have a specific format
<ericm|ubuntu> apw, so once blueprint is modified to a correct format, the work items will be automatically updated?
<apw> ericm|ubuntu, thats right, they will move to those summary pages by magic
<ericm|ubuntu> apw, cool - thanks
<ericm|ubuntu> apw, so for a new item, it should be something like: [eric.y.miao] xxxxx: TODO?
<apw> yep
<apw> and in a section
<apw> Work items for maverick-alpha-1:
<apw> item
<apw> item
<apw> <blank>
<ericm|ubuntu> apw, I see - and I don't need to delete the original descriptions in the whiteboard, sections/workitems in such format will be scanned right?
<apw> that is correct
<apw> one section per milestone though
<ericm|ubuntu> apw, I see
<ericm|ubuntu> apw, but we can first target for alpha-1, postpone it for alpha-2 right?
<apw> yep, you can move then around as you see fit yes
<apw> though try and be realistic
<ericm|ubuntu> apw, OK
<apw> you can have sections for many milestones, see https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-misc as an example
<ericm|ubuntu> jk-, mind if I assign the common clock framework in blueprint kernel-maverick-arm-single-zimage to you?
<ericm|ubuntu> apw, got you
<jk-> ericm|ubuntu: I already have that line item in the ARM blueprint
 * psurbhi eyeballing the btrfs tools code
 * cking does yet another S3 cycle
<jk-> ... but we can track it in two places, if that helps
<ericm_> jk-, ok - let's track it in two places, what's the milestone target then?
<jk-> ericm_: well, when are you looking to have the blueprint completed?
<amitk> ericm_: I could take a look at some items on that blueprint
<ericm_> amitk, let me know which items you are interested
<ericm_> jk-, possibly end of this week - that was what Leann suggested
<jk-> oh, i mean the actual items on it :)
 * cking suffering from the uds-flubug
<ericm_> jk-, could be any time you think appropriate, maybe target at 10.10 and postpone it? I understand it's quite a long term thing
<jk-> cking: i'm sorry, you can't have the flu unless you have it assigned to you in a blueprint :)
<cking> jk-, now that's amusing!
<jk-> ericm_: target it at 10.10 if you like, I hope to have something upstreamed before then. However, I think that there are much larger items on the blueprint that will take longer.
<ericm_> apw, how do you think about some kernel items both in kernel-maverick-arm-kernel-as-bootloader and arm-maverick-softboot-loader
<ericm_> jk-, yeah I fully understand
<apw> ericm_, there is no point in having the same item in two places
<ericm_> apw, mmm.... just wondering which side to delete them from
<apw> you could easily make arm-maverick-softboot-loader point to kernel-maverick-arm-kernel-as-bootloader
<apw> if it makes sens you can also just close off the kernel one and consolidate onto the other one
<apw> if its really a single subject
<apw> or just add a note in one saying that the kernel items are on the kernel one
<apw> but duplicating them will just confuse
<ericm_> apw, ok - I'd prefer to make softboot-loader point back, I'll talk with NCommander on that later
<apw> ericm_, if they are items on us, feel free to put them where they make sense
<ericm_> apw, ok
<apw> just leave him a note in the whiteboard saying where they are
<ericm_> apw, and I noted that the work items should be placed in the front of the whiteboard, yeah?
<apw> ericm_, there is no requirement, i tend to put them there to make them more obvious when there is lots of text
<ericm_> apw, got you
<jk-> ericm_: so do you want to remove the clk stuff from the single-zimage bp then?
<ericm_> jk-, yes I'll do that later, and point it to your DT blueprint then
<jk-> cool :)
<apw> jk-, can't see your blueprint on the list ?
<jk-> apw: yeah, it seems to be somewhat invisible, want a link?
<apw> yep
<apw> want to know why its not on my list yet
<apw> well leanns list, but hey
<jk-> because it's an arm- one?
<apw> does it have work items on you?
<jk-> yup
<apw> then it should appear, unless its wrong :)
 * jk- guesses the latter
<jk-> https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-using-device-tree-on-arm
<apw> link ?
<jk-> 'work items' -> 'workitems' ?
<apw> nope
<apw> maybe that you need it to have a series goal of maverick
<jk-> hm
<jk-> "m-release"
<jk-> or "trunk"
<jk-> those crazy arm people.
<ericm_> jk-, heh :-)
<jk-> apw: will either of those suit you?
<apw> jk-, mine are pointed to maverick i think
<jk-> i don't get a "maverick" option :/
<apw> but i can't point them to find out :)
<sunnydrake> hi anyone can provide a tip how to configure udev (udisks/create_floppy_devices (default floppy creation in ubuntu 10.04) to pass codepage=866,iocharset=utf8 parameters to correctly mount floppy?
<apw> http://patchwork.ozlabs.org/project/ubuntu-kernel/list/
<jk-> apw: you're coming a close second behind dave miller :)
<jk-> http://patchwork.ozlabs.org/project/netdev/list/
<apw> jk-, heh ... joy
<apw> jk-, see how this one has 'accepted for maverick' in the series goal section
<apw> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-easy-wayland-testing
<apw> i suspect yours needs that
<jk-> i just don't have that option though
<jk-> only "ubuntu-arm m-release" and "ubuntu-arm trunk"
<jk-> i guess becuase this blueprint is for the "ubuntu-arm" project instead of the "ubuntu" one
<jk-> i could "retarget" it maybe?
<persia> Unfortunately, that's incredibly difficult, because of how LP works.
<jk-> but then the arm folks might miss it
<persia> So it's kinda stuck where it is (when we decided to never use "ubuntu-mobile" we copied the specs that seemed interesting)
<apw> jk-, hrm thats a bit crap, work to be done by our team really should be visible.  perhaps we can make a dependant blueprint and put that in ubuntu
<apw> there is the concept of a depeancy tree of blueprints, persia do you know if an arm one could depend on an ubuntu one?
<persia> I don't know, sorry.  The conclusion of the experiment with the "ubuntu-mobile" project was to try to forget it ever happened.  Unfortunately, it seems we were successful.
<apw> jk-, do you have an 'add dependancy' button on your blueprint details view?  if so try adding kernel-maverick-misc
<Deem> hi. ive got an very curios problem with my logitech g15 keyboard. after a few minutes or sometimes hours my keyboard dies. i cant type anything. power's still there and the display works fine, too. i use the 2.6.32-22 kernel with lucid
<apw> Deem, is that an external keybaord?
<smb> Deem, As I have no idea what a g15 keyboard is (certainly I could look). But I assume it might be connected via usb. If you can remotely log in if that happens maybe you see some messages in dmesg
<smb> ... removing "quiet" from the kernel command line could potentially show more info
<smb> Deem, But as apw says, if you can tell us what kind of keyboard this is. Internal, external (connected via ps2 or usb)?
<Deem> smb: its connected via usb
<Deem> and its an external keyboard
<apw> so does it come back if you pull it out and re-plug it in ?
<Deem> apw: no. it still keeps dead
<smb> One other thing to test might be any other usb device. see whether thats dead as well
<smb> (in the same port)
<Deem> smb: its only happen to my keyboard... if i plug it in another port it got dead too
<Deem> ive plugged my external hdd in the first port and it works fine
<apw> Deem, does the cursor look different when the issue occurs?
<Deem> it seems like lucid doesnt like my keyboard
<Deem> apw: no. it all looks like always
<smb> Ok, that rules out the usb subsystem generally
<apw> smb, remember those cases where you had to press all the modfieres to sort out the keyboard
<apw> but in that case the cursor was a the normal text cursor i think, but didn't change on window boundaries any more
<apw> smb, its not obvious how the keybaord could not recover on removal and insertion into a different usb port and yet be ok on a reboot ...
<smb> apw, The cases I saw would at least resolve by unplugging. And usually its not dead but repeats some keystrikes
<Deem> maybe its the special on my keyboard. i have such keys that ae called "g"-key and ive got an switch to disable the windows key... maybe its one of this
<smb> apw, I could only think that there is one input device created and this might stay open... not sure
<apw> dmesg at the time of the failure might say something, worth checkng
<smb> yeah
<Deem> apw: how should i type dmesg if i cant type anything? :D
<smb> Deem, ssh? Assuming there is another computer arround
<Deem> smb: sry. no second computer
<apw> well if its only the keyboard presumably you open a terminal in advance and pre-type 'dmesg | tee -a DMESG'
<smb> Deem, I guess you are neither blessed with a second keyboard for emergencies. ;--)
<apw> and then cut-n-paste a newline into the window to trigger the command
<apw> after the keyboard is dead
<smb> Deem, but if the computer does not lock up completely there might be something in the /var/log/syslog after reboot...
<Deem> smb: ok. ill take a look. just a sec
<smb> or actually as apw sais
<smb> says even
<lag> On-screen keyboard?
<smb> Or even tail -f /var/log/syslog
<apw> is entiryly possible, that if you can use mouse to reboot that the logs already contain the informaiton
<smb> apw, Not sure I got this right but in my mind the stack is somewhat like usb->hid->input device->X with a lot of places to consistently go bonkers
<Deem> smb: cant find anything in the syslog file
<smb> Deem, then I'd try two terminal windows
<Deem> smb: how do you mean that?
<smb> in one do a tail -f /var/log/syslog and in the other
<smb> tail -f /var/log/Xorg.0.log
<smb> Deem, In X open two windows from applications->accesoiries->terminal
<smb> And then run one of both tail commands in one of them
<smb> Then wait until the keyboard goes doead
<smb> dead i mean
<Deem> smb: ok. i'll write again. if it happens
<smb> Deem, Sure. Hopefully one of them contains something
<apw> tgardner, seems we can nolonger make git directories on zinc, who do we hastle?
<tgardner> apw: lamont
 * apw waits :)
<tgardner> apw, 3.1G available. getting pretty close
<apw> heh yay
<apw> tgardner, smb, how far back do you think we need 'daily' builds for linus ?
<tgardner> apw, I don't think they are of much use once he's released an official version.
<smb> tgardner, apw Dunno, somehow it feels anything between 2.6.25 and 2.6.30 could go...
<smb> at least
<apw> so i could do some hybrid of that, everything before say 'lucid' release version
<tgardner> apw, we cold certainly drop the 2.6.27* kernels.
<tgardner> could*
<JFo> so apw or smb or tgardner I have a bossman bug 581312
<ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 8)" [Undecided,Triaged] https://launchpad.net/bugs/581312
<ubot3> Malone bug 581312 in linux "Unknown key fee[x] pressed" [Undecided,Triaged] https://launchpad.net/bugs/581312
<ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (dups: 1) (heat: 8)" [Undecided,Triaged]
<smb> apw, True. Cannot think of a reason to have anything beside the rc levels of something released
<ubot2> ubot3: Bug 581312 on http://launchpad.net/bugs/581312 is private
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> ubot3: Error: I am only a bot, please don't think I'm intelligent :)
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> ubot3: Error: I am only a bot, please don't think I'm intelligent :)
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> ubot3: Error: I am only a bot, please don't think I'm intelligent :)
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> ubot3: Error: I am only a bot, please don't think I'm intelligent :)
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> ubot3: Error: I am only a bot, please don't think I'm intelligent :)
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<ubot2> ubot3: You've given me 5 invalid commands within the last minute; I'm now ignoring you for 10 minutes.
<ubot3> ubot2: Error: I am only a bot, please don't think I'm intelligent :)
<sconklin> fail
 * smb slaps JFo 
<JFo> wtf
<JFo> bot fight
<JFo> somebody kickban one of those
<smb> Gosh, before we were happy to have one, now there are two trying to fight each other
<tgardner> who is the channel op? bjf? 
<amitk> apw
<smb> now
<tgardner> I see that now
<apw> i would but the chanserv is mute
<apw> oh finally ... stupid thing
<amitk> lol
<tgardner> apw, so, you're gonna dump all the -rc candidates except maverick?
<apw> get the hell off of my channel you argumentative bot
* apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - May-17- 17:00 UTC
* apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - May-18 - 17:00 UTC
<smb> tgardner, I thought we keep the rc candidates but get rid of the dailies
<tgardner> smb, what good are the rc's for released kernels?
<apw> yeah tend to keep the recent -rcNs for a couple of releases in case they are useful for regression-release bisect
<apw> and drop the dailies
<smb> tgardner, Rough bisecting if something got introduced then
<tgardner> I disagree. only the vanilla stable kernels are useful _after_ the release
<tgardner> we don't have unlimited storage
<smb> tgardner, There might be bugs introduced during 2.6.32 timeline...
<smb> tgardner, Thats why we likely could dump most of pre-lucid
<apw> tgardner, ok back to 21G
<apw> dropped the last years dailies and some of the very old -rcNs we had
<apw> we can now argue more sedatly abuot where the boundary should be
<tgardner> apw, how about v2.6.31-rc*
<tgardner> ?
<smb> Guess those could go
<apw> probabally 31-rcN are now lower usefuless, on the cusp as far as i am concerned
<smb> ??? parse error
<tgardner> longer*
<apw> i think 32 is deffo useful, 30 is deffo not useful, and 31 is hard to say you could convince me either way
<apw> is intrepid off support now ?
<smb> Yes
<tgardner> apw, as of Lucid release
<apw> and if so, that was .27 right ?
<smb> Reminds me to move the git trees
<apw> so i could zap most of those
<tgardner> yep
<JFo> vanhoof, you around?
<smb> tgardner, Will I step on you when I go to do that?
<tgardner> smb, archinving intrepid? dunno
<apw> ok 24GB available
<smb> tgardner, I guess no, if you are not just doing the same. ;-)
<tgardner> smb, no, I'm not messing with it right now. go ahead
<tgardner> apw, are you cleaning stuff out of /home/kernel-ppa/public_html/mainline ?
<apw> tgardner, yes
<smb> apw, tgardner Ok, gone to ubuntu-archive now
<tgardner> apw, you still plan on dumping *2.6.27* kernels?
<tgardner> that'll free up a bunch more space
<apw> yeah i had previous reaped back to just every 5 of the stables, but as its dead
<apw> i recon the last one maybe 
<achiang> kamal: sorry i missed you yesterday. yeah, if you could clean up that tag for me, it would be great
<kamal> achiang: I've lost the bug number
<kamal> achiang: found it 578138
<kamal> achiang: done
<achiang> kamal: heh, you're faster than me.
<achiang> thanks. 
<kamal> achiang: np :-)
<achiang> -ENOCAFFEINE
<smb> JFo, Re bossman bug: might be useful to ask for "sudo lsinput" to see what shows up as an input device. lsinput is from input-utils iirc
<kamal> achiang: yeah I need another cup too
<JFo> smb, cool
<JFo> how do we feel on importance?
<smb> JFo, Normally low to medium but...
<JFo> ok
<JFo> just wanted to check
<smb> apw, Would you know magic to let an input stream be ignored?
<apw> ignored in what sense?
<smb> Like ignore all key comming from this
<apw> i don't know of a way no, now that X handles devices direclty i suspect there might be a way there
<smb> But probably this is just incorrectly detected as keyboard. If _his_ guess is right. It sounds reasonable
<JFo> request sent
<JFo> do we use linux-ports (Ubuntu) package anymore?
<JFo> I haven't been watching it and someone changed a but to that
 * JFo plans to change it back if we don't
<smb> JFo, Not an explicit. The ports are build from the main package
<smb> (lucid)
<JFo> yeah, apparently there are 25 bugs against the package
<JFo> that I was unaware of
<smb> JFo, From my feeling it would be Luke and ncommander that would need to be aware. apw ?
<apw> linux-ports would be old releases no?
<apw> for karmic on they probabally are meaningless
<smb> apw, Was it already Karmic when the sources were combined again. Drat, were do you buy your brain extensions?
<JFo> heh
<apw> heh
<JFo> I'm up for doing whatever. just need to know what that is
<apw> yeah karmic has ports in it
<apw> and jaunty does not
<apw> so they can only apply to hardy and jaunty i think
<apw> dapper had them built in too right>
<JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ports
<JFo> there are some old ones in there
<smb> So reports on linux-ports package likely is Jaunty or Intrepid. For hardy the ports were part of support
<apw> https://edge.launchpad.net/ubuntu/+source/linux-ports
<smb> Dapper too, though maybe slightly different archs
<apw> heh look its only jaunty now
<apw> so any bugs which arn't jaunty can be closed outright
<JFo> ok
<apw> JFo, you could apply the tagger thing to linux-ports and zap all that pre jaunty can go, any later than jaunty are likely on the wrong package, and move to linux
<JFo> then my next Q is. who owns this packages bugs? I assume me
<JFo> ok
<smb> apw, And bugs on jounty, if not killer bugs won't quilify either
<JFo> k
<apw> well i'd say, anything left is not our problem, and can be stuck from our stats
 * JFo writes some notes
<JFo> apw, I'm not sure they are currently on there anyway
 * JFo makes a note to check
<apw> ahh good
<apw> but yeah agressive closing seems also ok
<JFo> k
 * smb desperately tries to remember which clever note he was about to write before
<JFo> apologies smb :-/
<smb> JFo, No worries. Maybe apw reveals where he gets his brain extensions from, then I can increase my stack size. :-P
<vanhoof> JFo: sure, whats up
<JFo> let me know, maybe we can get a bulk discount
<apw> smb, i make space by dropping useless information like names and birthdays
<JFo> vanhoof, hey man, qa is pinging me about OEM escalations
<abogani> smb: Please don't forget me! :-)
<JFo> think we need to come up with a good flow for now on them
<smb> apw, Good plan, beside of girl friends...
<JFo> on where they go so they don't get dropped
<apw> JFo, i think those bugs belong to architecture teams by the looks of it
<JFo> the ports ones apw?
<vanhoof> JFo: sounds like a plan
<vanhoof> JFo: give me 5, ill ping you
<apw> yeah, looking at a few, they often are subscribed to like 'powerpc team'
<JFo> vanhoof, cool
<JFo> apw, ok
 * cking-afk visits local hospital, back later
<JFo> cnd, you around?
<cnd> JFo: yep
<JFo> care to take a look at bug 580305?
<cnd> you better not give me any work :)
<ubot2> Launchpad bug 580305 in linux (Ubuntu) "Version of hid-quanta in Lucid kernel is broken (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/580305
<JFo> looks like quick review/fix maybe
<JFo> cnd :-)
<JFo> it is opt-in
<cnd> JFo: I'm actually caught up with oem work right now
<JFo> cool! :)
<JFo> but I won't bug you
<JFo> just saw this and wondered if you were interested
<cnd> JFo: hopefully there's some resolution soon
<cnd> so I can start working on other things
<cnd> but not quite yet
<JFo> yeah
 * apw has to run do an errand ... paperwork, shmaperwork
<JFo> well, there is hope
<JFo> enjoy apw 
<apw> where did the day go i wonder
<cnd> apw, it came over to the US apparently...
<cnd> I wouldn't have minded it staying across the pond for a while ...
<JFo> same here
<JFo> i feel very bad
<JFo> may take off in a bit
<cnd> I was feeling great until I got a new code drop to slog through :(
<JFo> I've been quite sick since yesterday
<JFo> nothing seems to help
<JFo> smb, tgardner are we having a meeting today/
<smb> JFo, Yes,
<JFo> k, thanks
<Deem> smb: it happend again, my keyboard dies and these are the msg from the syslog http://paste.pocoo.org/show/215273/
<smb> Deem, Looks useful. If there is a bug on it that should ggo in. g15daemin, hm. Not heard of that before...
<Deem> smb: the g15daemon is for the display, that in integrated in my keyboard. it shows time and date and other things
<smb> Deem, While I cannot tell what exactly happens this very likely causes the keyboard to go dead
<Deem> smb: with 9.10 it works perfectly
<Deem> and there i used the g15daemon,too
<smb> Deem, That is a good data point to know. Still either the code there or the infrastructure around it can have changed
<Deem> smb: the package g15daemon is also in the universe repo
<Deem> maybe its one of the extensions for the daemon that causes the problem
<Deem> i dont have installed all off the plugins for it under karmic. now i have all plugins integrated... i'll try without the extensions and only with the daemon, mybe it solves the problem
<Deem> smb: if i start the g15daemon with debug ill get this http://paste.pocoo.org/show/215281/ maybe theres a problem with the library under lucid
<smb> That sounds like a useful debugging step. I am not sure whether the usb_kill_urb in the backtrace is called as a part of the lockup or as a result of it. Overall it sounds like some usb communication locks up and probably because the daemon keeps the device open it will be reused whenever it is re-connected and still stays in the locked state
<Deem> erm.. ok.. sudo helps :D
<Deem> now the daemon runs in debug
<Deem> i'll do the same like a few hours ago. if it dies again i look what the debugging says and tell it to you, ok?
<smb> Deem, Is the old one (PID 911) still hanging around?
<smb> Deem, Ok, also answers sort of my last question. :)
<Deem> smb: it was there, yea. i killed it with "sudo g15daemon -k"
<Deem> smb: it happend again, but nothing in the debugging msg of the g15daemon
<smb> Deem, *sigh* probably not expected that it can tell when it is about to get locked up.
<smb> Deem, Was this with the new plugins removed?
<Deem> smb: yes. its only the daemon
<smb> Deem, So its either changes in the daemon (if there were any) or maybe something changed around the used ioctls in the kernel. I wonder whether stracing the daemon would reveal anything...
<Deem> stracing?
<Deem> sry, my english is not so good =)
<smb> sudo strace g15daemon
<smb> its producing  a lot of output
<Deem> yes. "lot" is the right word :D
<smb> but the last line(s) when it hangs would be what syscall locks up
<Deem> you mean "socket" "connect" and "sendto" ?
<Deem> i think i just paste it http://paste.pocoo.org/show/215295/
<smb> Deem, already locked up again?
<Deem> erm.. no
<Deem> should i do this when its looked up? =)
 * JFo goes to try and eat
<smb> Heh, actually it might be good to attach to its pid after it has gone into the background. Doh!. That would be sudo strace -p <pid>. And then, yes wait what would be the last thing when the keyboard locks.
<Deem> maybe its an issue if the daemon is running by the user "nobody" ?
<smb> imo that would either be an immediate fail or does not matter
<lamont> apw: or any of the other sysadmins for zinc dir-fixing
<JFo> ogasawara, not sure what they are asking for here, but thought I'd show you: bug 493156
<JFo> even though it is "WONTFIX"
<ubot2> Launchpad bug 493156 in linux (Ubuntu) "Please enable CONFIG_TASK_DELAY_ACCT (affects: 26) (dups: 3) (heat: 70)" [Wishlist,Won't fix] https://launchpad.net/bugs/493156
<ogasawara> JFo: I'll take a look
<tgardner> JFo, this config option has run time impact which we deemed unacceptable
<JFo> tgardner, I was sure there was a reason, but I didn't want their complaint to go unanswered
<JFo> and I have no idea what the config is for
<JFo> :)
<JFo> thanks for giving it a quick once over ogasawara 
<tgardner> IIRC the code does some math for each task switch
<manjo> I think my calendar is messed up for some reason, how many hrs do you have on your calendar for the meeting? so that I can fix it... 
<smb> manjo, how many would be one. start is 5pm UTC (whatever that means for you)
<lag> Trying to create KERNEL/debian/control with kernel-wedge, but it dies with: kernel-versions: No such file or directory at /usr/share/kernel-wedge/commands/gen-control line 22
<lag> Do I need to setup some environment variables or such?
<tgardner> lag, do you have kernel-wedge installed ?
<lag> Yes :)
<lag> Half way there
<jjohansen1> morning
<tgardner> lag, try 'fakeroot debian/rules clean' first
<lag> Same error
<lag> This kernel comes from a brand new clone
<tgardner> lag, lucid ?
<lag> *and branch
<lag> Yes
<lag> ti-omap branch (or head)
<apw> kernel-versions minssing classically means you didi not clean the tree with fdr clean
<apw> if you think you did fdr clean, then could you see if you have a kernel-versions file anywhere in debian*
<tgardner> apw, he's doing armel, so you also need to specify an arch IIRC
<tgardner> fdr clean arch=armel
<apw> hmmm
<smb> never did that
<tgardner> _and_ have the cross compile tools installed.
<lag> ./debian.ti-omap/d-i/kernel-versions
<apw> i prolly always build in a chroot, and fdr clean in the chroot 
<Deem> smb: and now it happend again, bit i cant strace the deamon cause i cant type in my sudo password :D
<tgardner> apw, what chroot has arch==armel ?
<apw> lag, where did you try and build it
<apw> tgardner, i use an i386 chroot, with some env mangling
<lag> I don't have the fdr script yet
<apw>         echo "Setting environment for armel cross-compile"
<apw>         export CROSS_COMPILE=arm-none-linux-gnueabi-
<apw>         export PATH=$HOME/toolchains/arm-2009q1/bin:$PATH
<apw>         export DEB_BUILD_ARCH=armel
<tgardner> apw, bad boy
<apw>         export DEB_HOST_ARCH=armel
<lag> I haven't tried to build anything yet
<lag> Does the kernel-wedge command insinuate a build?
<tgardner> lag, fdr is an alias that we all use as shorthand. it refers to 'fakeroot debian/rules'
<lag> k
<apw> clean insinuates a lots of building of required files
<tgardner> kernel-wedge is used when processing the debian installer bits under the d-i directory
<apw> but if you arn't trying to build, what produces the error
<smb> tgardner, apw I don't use any armel chroot for the source package processing. And it used to work
<lag> I guess I'd better install my cross-tools at some point then
<apw> yeah i just use the i386 chroot to do source builds normally
<apw> never had any issues that i know of
<smb> And lucid does not sufffer from stabe debian/debian.env that used to cause some trouble
<lag> I'm just trying to create the 'control' directory 
<lag> I'm not at the compile stage yet
<apw> debian/control is made by fdr clean
<smb> control should be a file, no?
<apw> or do you mean something else
<apw> #
<apw> # ONE HOUR TO TEAM MEETING IN #ubuntu-meeting
<apw> #
<lag> smb: A directory I think?
<smb> Deem, Naturally I meant attach to the daemon _before_ it hangs... :-P
<Deem> smb: thats the problem i dont know when the daemon is going to hanf
<Deem> hang*
<smb> Deem, You can just let the strace run and wait. Ok, the output is a bit mind blurring but you could minimize the window
<JFo> crap apw, I don't have the metrics pulled together
<apw> good job you have an hour then :)
<smb> JFo, I haven't prepared either. Yet
<Deem> smb: i cant let the strace run. it terminates always
<JFo> sigh
<smb> Deem, Even if using the -p <pid> variant?
<lag> apw: Do we have cross-tools available, or should I build my own?
<apw> smb i bet its a deamon so you need to use the follow thing, strace -f
<Deem> smb: ive only got this Process 1273 attached - interrupt to quit
<Deem> pause(
<apw> Deem, try starting it strace -f
<smb> apw, Or isn't pause jaust the daemon waiting
<Deem> apw: with -f it gives allways the same output
<apw> pause would be wait8ing for a signal, which implies its waiting for a child i suspect
<Deem> again and again
<apw> which is probabally the child being a piece of crap and polling all the time
<smb> Deem, That is called polling. :P
<Deem> polling?
<apw> Deem, what does the g15 daemon do, just allow you to update the screen part of the keyboard?
<apw> ie if its not running can you type?  if so have you tried running without it for some time to see if that is the trigger?
<Deem> apw: its for the plugins. it makes an clock on my lcd :D
<tgardner> smb, where are you link KernelTeam/StableHandbook/UpstreamStableReview from?
<Deem> an no. i doesnt tried without it
<tgardner> gonna link*
<apw> well first test should be to turn that off and confirm its that that breaks things
<apw> then at least we can file a bug on the right thing
<smb> tgardner, To the non-existent-yet StableHandbook and that somewhere into Team docs
<tgardner> smb, good, just so long as I can find it without having to search the name space
<Deem> apw: ok. i killed the daemon.
<apw> it seems likely this will be the cause
<smb> tgardner, No, its just that I started sort of bottom up
<apw> you don't happen to have another keyboard lying about do you?  a usb one?  you could add and see if that one continues past the failure mode -- a next step once confirmed that no hangs without daemon
<Deem> apw: maybe. but then something should be different from lucid to karmic. because on karmic it works properly
<Deem> apw: sry. got no other keyboard
<apw> Deem, right, yuo have about 20k differences between the two
<apw> knowing exactly which bit cuts it down
<apw> Deem, you may find you need to find a friend either to borrow a keyboard or to borrow their machine to login from to diagnose this further ... but do confirm the daemon not running works
<Deem> apw: but, when the daemon is the problem. how would you find out, which difference will harm the daemon?
<apw> well the daemon itself has changes from karmic to lucid, so that is suspect one
<apw>  g15daemon |  1.9.5.3-3 | karmic/universe | source, amd64, i386
<apw>  g15daemon | 1.9.5.3-8ubuntu1 | lucid/universe | source, amd64, i386
<smb> Deem, That was the intention of letting it follow the trace
<abogani> smb: Did you read my email? :)
<smb> Deem, It should at least give a hint what the daemon did last
<smb> abogani, email, I guess no
<smb> Oh, actually yes
<smb> darn
<smb> abogani, the answer is looks good
<Deem> smb: but when i start a strace with -f it attaches 6 processes
<smb> abogani, sorry
<abogani> smb: Don't mention it! Thank you instead!
<apw> smb, i wonder if he could boot back to the karmic kerenl if its still there as a test later too
<smb> Deem, This would be 6 childs that the daemon has forked (or threads)... If this are real childs, you see multiple g15daemons in "ps ax|grep g15daemon" ?
<Deem> smb: no, theres only 1 g15daemon
<smb> then I guess those are threads oly
<smb> only
<apw> Deem, ps -efT | grep g15daemon
<smb> Well I guess first running without the daemon. This will prive it is the daemon
<apw> how many does that list
<apw> right, that has to be the first test, can you get 5x the normal time without it
<apw> Deem please record everything you test and the outcome clearly in the bug
<Deem> apw: what bug? o.O
 * apw suggests we ignore you until you have one :)
<smb> Deem, The one you will open
<apw> file one against g15daemon i recon
<Deem> ah... ok. then i will do this. but i think i should wait if it happens again without the daemon, then its not the daemon who causes the error =)
<apw> you can move the bug from g15daemon to something else once you find out it is something else no problem
<apw> but with a bug there you can record these facts as you discover them, i bet you have forgotten the first ones already ... i know i have
<Deem> apw: no. i dont think i forgot it :D im logging all channls so i have the msg from tail :D
<apw> #
<apw> # meeting in 30 mins in #ubuntu-meeting
<apw> #
<Deem> apw: smb: do you want the bug id?
<apw> Deem, sure
<Deem> 582352 
<apw> bug 582352
<ubot2> Launchpad bug 582352 in g15daemon (Ubuntu) "keyboard dies when using g15daemon (affects: 1)" [Undecided,New] https://launchpad.net/bugs/582352
<apw> smb, have a look at the syslog, did you know about these backtraces :
<smb> apw, If those are the same I saw them earlier. It is obvious that the daemon is stuck. Did not seem to be obvious where and whether its the only problem
 * psurbhi quitting for today.. have to run to a dr
<apw> #
<apw> # 5 mins to meeting in #ubuntu-kernel
<apw> #
<kamal> apw: is the meeting here or #ubuntu-meeting then?
<apw> #ubuntu-meeting 
<apw> <- tool
<smb> !apw /query location meeting
<ubot2> smb: Error: I am only a bot, please don't think I'm intelligent :)
<apw> smb: i am only a tool, expect nothing useful
 * JFo is gonna go to sleep now. I need to take some meds and rest methinks
<jjohansen> JFo: take care, that ubuflu sucks
 * ogasawara tucks JFo into bed
<manjo> smb, if you have a wiki on sru policy can you please add a link to the https://wiki.ubuntu.com/KernelTeam/KnowledgeBase ?
<JFo> thanks ogasawara :)
<JFo> thanks jjohansen 
<JFo> this sucks
 * cking thinks JFo burnt himself singing at the end of UDS
<JFo-afk> I think so too cking 
<smb> manjo, There is one I will point to you as soon as I find it again
<manjo> smb, sure I can add a link to the https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
 * cking grabs some food and ponders on a msleep() hang
<manjo> cking->food->msleep()
<ogasawara> apw: bug 571980 confirms that re-enabling KMS for i855 allows the reporter to boot successfully once again.  I presume we're suggesting these reporters use the workaround rather than us backing out the blacklist patch.
<ubot2> Launchpad bug 571980 in linux (Ubuntu) "crash on boot with kernel 2.6.32-21 (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/571980
<jjohansen> apw: when doing work items is there a way to do conditional items.  ie. only do this item if investigation/testing of item X fails?
<apw> no there is no way to express that, i would say just add them and they go DONE if they arn't needed
<smb> manjo, Its is linked though not obvious. https://wiki.ubuntu.com/KernelTeam/KernelUpdates And probably needs more explicitely mention bug fixes at the beginning
<smb> manjo, But its contained in the "make it available in upstream stable"
<manjo> smb, probably needs a new wiki 
<manjo> ie cut & paste info
 * smb hands manjo the task
<smb> manjo, But serious, yes. I already thought of that being part of the new things I do
<smb> Especially as I need minutes to dig through to it everytime
<manjo> smb, I can put together a page from the 2 pages you pointed me to and you can fix it up ? 
<manjo> smb, coz it really bugs me everytime I look at a bug and I need to figure out if will make sru or not ... if not what I need to do ... if it does what is the process .. 
<manjo> often I am wrong .. 
<cking> cnd, can one make ftrace start tracking function calls once it's hit a specified function?
<cnd> cking: yep!
<cking> woot
<cnd> say the function is "blah"
<cnd> echo ":blah:traceon" > /sys/kernel/debug/tracing/set_ftrace_filter
<cnd> I think that's right
<cking> sweet
<cnd> you can cat set_ftrace_filter and it will tell you if it set it properly
<smb> manjo, Thanks. Though atm I only remember me pointing you at one. And probably I should rework it better and not only merging two pages. 
<cnd> cking: it's an undocumented functionality, but I sent a patch upstream to add it to the docs, and I assume it will make it into .35
<smb> manjo, Assume for the moment SRU is allowed for real bugs which have a lp report. And the preferred way if not critical is to go via stable
<cking> cnd, no wonder I could not see it in the docs
<cnd> cking: this is where I tried to send a patch upstream to turn off tracing when you hit schedule_bug and other bugs
<cnd> and I got smacked down when it was pointed out that the functionality already exists
<cnd> though no one bothered to note how to find the functionality
 * smb feels a little flu-ish too, atm. Guess I call it a day
 * cnd feels like the last man standing...
<cnd> time for some lunch me thinks
<cking> cnd, I'm getting Invalid argument on that, does it work on 2.6.32?
<cnd> cking: it should
<cnd> let me find the upstream docs :)
<cnd> cking: http://git.kernel.org/?p=linux/kernel/git/rostedt/linux-2.6-trace.git;a=blob;f=Documentation/trace/ftrace.txt;h=557c1edeccaf72535464298743cddd3c8eb01bea;hb=refs/heads/tip/tracing/core-6#l1830
<cnd> cking: looks like it should be: 'blah:traceon'
<cking> cnd, yep - that matches the docs and works too
<cking> ta
<cking> cnd, seems to fail on my kernel when coming out of S3 with the console still blank. Oh well, you never know until you try
<cnd> cking: rats...
<cking> cnd, no worries - I will fall back to my devious tricks
 * cking calls it a day
<braintorch> Hello. I can't find any lucid packages of kernel sources with ubuntu patches applied on http://kernel.ubuntu.com/~kernel-ppa/mainline/ . There is just dummy package (size 2.2Kb). Where can I get 2.6.34 kernel source with ubuntu patches applied?
<ogasawara> braintorch: do you need lucid (ie 2.6.32 based) or maverick (ie 2.6.34 based) ?
<ogasawara> braintorch: you can find the git repo's for either at http://kernel.ubuntu.com/git
<braintorch> oh. Thank you. I completely forgot about git.
<ogasawara> braintorch: I should clarify maverick is currently 2.6.34 based but we'll be rebasing to 2.6.35 for final
#ubuntu-kernel 2010-05-19
<papachaotica> moinmoin
<kees> who should I poke to review my three kernel hardening patches?
<jjohansen> kees: I'll take a stab at them, and then probably apw, rtg or smb
<kees> jjohansen: okay.  I figured everyone was busy during UDS last week, but thought I'd ping on it this week.
<jjohansen> kees: yeah, and this week everyone is recovering from last week :)
<kees> \o/ uds hangover
<lapion>  is there any patch for a modules for the i915 kms that does a burn-in test of most basic functions of older chipsets ?
<lapion> *module
<lapion> btw if you warm-reboot a system from linux into memtest, you are going to find a lot of errors, all due to memory locking
<lapion> anyone in here ?
<lapion> I just got a i915 on a i855 xorg abort while I was ssh-d into it, so I took control when I saw the console screen on the display and I did a reboot in the ssh, and the ubuntu splash appeared, which make me think the problem is either xorg-centric, or the hangcheck code has a bug in it.
<lapion> or am I mistaken to think that the splash screen is also part of kms ?
<RAOF> lapion: Have you seen the i8xx GPU hang wiki page?
<lapion> okay tht page was not known to me
<RAOF> You've found it?
<lag> Morning :)
<lag> I still don't have permissions to create a directory on zinc =:-(
<amitk> lag: group?
 * abogani waves
 * amitk waves back
 * smb waves
<cooloney> amitk: we are going to use -omap4 package name for our 10.07 release
<smb> lag, Where do you want to create it? In your home?
<apw> smb, no in git export
<cooloney> amitk: need i change the branch name from ti-omap to -omap4 or ti-omap4
<apw> seems to have changed ownership for some reason
<cooloney> lag: nice to meet you, 
<cooloney> smb: apw morning
<lag> cooloney: Likewise 
<smb> apw, to kernel-ppa most interestingly...
<apw> yeah, not sure why that would be done, and i think i could partly pull it back, but i want to know why in case there is a reason
<smb> Yup, umderstanably
<amitk> cooloney: we won't *replace* the existing ti-omap since that is a supported flavour.
<amitk> cooloney: just create a new branch, ti-omap4 for all the omap4 patches
<cooloney> amitk: ok, so i need copy over all the debian.ti-omap to debian.ti-omap4
<cooloney> amitk: then fix something in the dir and generate our package
<amitk> cooloney: yes
<cooloney> amitk: ok, working on this. thx
<apw> dchroot -c lucid-i386
 * popey wonders if there's anything else he can do for bug 576601 :)
<ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 31) (heat: 190)" [Medium,Triaged] https://launchpad.net/bugs/576601
<apw> popey, fix it :)
 * apw feels like moving it to a Low priority for the arrogance that mac users are showing in it ... "a large proportion of ubuntu users affected" yeah right
<apw> [   60.975812] [Firmware Bug]: ACPI(IGPU) defines _DOD but not _DOS
<apw> quality apple as always
<RAOF> Who needs standards when you produce the entire stack!
<apw> RAOF, i so wish you were wrong
<RAOF> I mean, at least Apple isn't *deliberately* messing with us here.
<RAOF> They could do something totally ridiculous, like encrypting the partition tables or something.
<popey> :)
<cking> the good thing about standards is that there are plenty to chose from!
<popey> apw: would it help if I put the machine online for one of you guys/gals to ssh into and poke about?
<apw> it may, i'll need to read that debug and try and add stuff to it to get more infor and get those boot tested, so likely its easier for you to do that
<popey> ok, no worries, if you need access just let me know.
<ericm|ubuntu> apw, you know how comes vga16fb being always loaded even with a valid drm fb?
<smb> ericm|ubuntu, its a fallback and iirc there is no better way to tell its needed, but it should back off when it detects another fb
<ericm|ubuntu> smb, I don't see any vga16fb in modprobe.d somehow?
<ericm|ubuntu> how's that being requested to load?
<smb> as part of the startup scripts I believe
 * psurbhi takes  a lunch break
<ericm|ubuntu> smb, yeah - /usr/share/initramfs-tools/hooks/framebuffer:manual_add_modules vga16fb
<ericm|ubuntu> smb, ok - thanks
<cking> ericm|ubuntu, why the long irc nick?
<ericm|ubuntu> cking, ericm is occupied
<cking> ahah
<apw> ericm|ubuntu, its loaded cause it matches the VGA* 
<apw> via modaliases, that will go away with maverick
<ericm|ubuntu> apw, ah right - manual_add_modules only copies the ko itself
<ericm|ubuntu> apw, where's modaliases?
<smb> modinfo vga16fb
<smb> filename:       /lib/modules/2.6.32-22-generic/kernel/drivers/video/vga16fb.ko
<smb> alias:          pci:*bc03sc00i
<ericm|ubuntu> smb, so it's /lib/modules/2.6.32-22-generic/modules.alias?
<smb> That is generated from the info the modules carry
<ericm|ubuntu> smb, so every graphics card matches pci:*bc03sc00i ?
<smb> You normally have tha VGA compatible controller part
<apw> the alias meas VGA CARD
<ericm|ubuntu> smb, ok I see
<smb> The bc03 and sc00 
<smb> not sure what bc exactands for again
 * ericm|ubuntu reading http://wiki.archlinux.org/index.php/ModaliasPrimer - seems to be a good reference
<ericm|ubuntu> apw, smb, the module list for modules.alias is maintained by the kernel debian build scripts?
<ericm|ubuntu> or somewhere else?
<smb> ericm|ubuntu, The source _are_ the modules
<ericm|ubuntu> smb, yet I found no vga16fb info in karmic kernel?
<amitk> ericm|ubuntu: all the ids registered with the drivers are the source of the modaliases
<smb> ~/src/ubuntu-lucid/kernel$ grep ALIAS drivers/video/vga16fb.c 
<smb> MODULE_ALIAS("pci:*bc03sc00i*");
<smb> In the karmic kernel there wwasnt this
<smb> I think there it might be actually being loaded by the startup script somewhere
<ericm|ubuntu> smb, I think commit http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commitdiff;h=efc4c46c0d0aba445226f86898b7aed7a0642d05 changed the alias and make a wider match of VGA
<ericm|ubuntu> smb, I see modules.alias and vga16fb.ko in karmic kernel, how comes it doesn't show up in modules.alias?
<smb> ericm|ubuntu, Because in Karmic the module does not define an module alias?
<ericm|ubuntu> smb, I think MODULE_ALIAS should be already introduced?
<smb> ericm|ubuntu, But you _can_ write a module without using it
<ericm|ubuntu> smb, ah right - checked again, vga16fb doesn't have a MODULE_ALIAS in karmic kernel
<smb> Exactly
<ericm|ubuntu> ok, I think I can sleep tonight now :-)
<apw> right we added it for the boot performance work, as we can then wait for any FB to come live as one definatly will
<ericm|ubuntu> apw, that makes sense
<jpds> Does anyone know what could be causing this error? http://pastebin.ubuntu.com/436071/
<ericm|ubuntu> jpds, make V=1?
<jpds> ericm|ubuntu: Curious: http://pastebin.ubuntu.com/436074/
<ericm|ubuntu> jpds, it doesn't look to compile anything - maybe a make clean + make?
<jpds> ericm|ubuntu: Same result.
<ericm|ubuntu> jpds, how's the Makefile look like?
<jpds> ericm|ubuntu: http://pastebin.ubuntu.com/436076/
<ericm|ubuntu> jpds, but it looks like nothing is being built - not even those $(MODULE_NAME)-objs :=  rtmp_main.o mlme.o connect.o rtusb_bulk.o rtusb_io.o \
<ericm|ubuntu> 			sync.o assoc.o auth.o auth_rsp.o rtusb_data.o \
<ericm|ubuntu> 			rtmp_init.o  sanity.o rtmp_wep.o rtmp_info.o \
<ericm|ubuntu> 			rtmp_tkip.o wpa.o md5.o rt2x00debug.o
<ericm|ubuntu> jpds, tried explicitly 'make modules'?
<jpds> ericm|ubuntu: There's no modules target, but 'module' returns the same error.
<ericm|ubuntu> jpds, tried explicitly 'make -C /lib/modules/$(uname -r)/build M=$(pwd) modules?
<ericm|ubuntu> i.e. skipping the module phony
<jpds> ericm-afk: That appears to only do: http://paste.ubuntu.com/436083/
<Deem> hi. im the one with the diying keyboard. i only want to say, that its not the g15daemon who causes the error. this time i stopped the daemon and the keyboard dies. so it must be something different.
 * psurbhi someone at UDS infected me with their cold and cough :( .. and i had just finished my previous dose at UDS.. when is this cold going away! i want to work without being bogged down by it.. :(
<apw> cking, hey ... do we expect uefi bios'en to boot a lucid image ok ?
<apw> psurbhi, thats why we all try and work from home as much as possible, keep the lurgies away
<apw> cking, about ?
<cking> apw, sorry, was distracted for a mo
<cking> apw, I got a lucid alpha2 to boot on an Intel based dev platform a while ago - but there were issues in setting the video modes.
<apw> cking, so this thing also has a WIN-P button ... i am starting to think we should just bind the thing to the appearance applet in gnome
<cking> apw, the Win-P issue needs resolving in userspace IMHO
<apw> we're never going to get the bios people to do something sensible
<cking> especially when pressured to do insane hot-key weirdnesses based on pressure from Microsoft
<apw> cking, so should i risk turning on the efi bios ticky?
<cking> apw, as long as you can turn it off ;-)
<apw> cking, do i expect it too boot?
<cking> you will have probs booting it though - I can send you the magic to config up the boot 
<apw> cking, hrm ... not sure i want that level of pain
<cking> it's not too painful - honest!
<smb> it just hurts a little
<apw> cking, i added the sensors applet, i have about 20!
<cking> looks like it's a sensitive soul
<cking> apw, hacky notes email'd to you
<apw> cking, nothing so far, temps remaining constant
<apw> cking, nope
<cking> ..got a freezer handy?
<apw> oh, one fan just went off
<cking> yay
<apw> cking, i installed 64 bit, thinking of reinstalling 32 bit to see if that helps
<cking> apw, 64 bit will twiddle more transistors that's for sure
<apw> yeah hard to know how much worse/better, but i can test at least
<cking> apw, I suspect a few degrees C
<apw> i wouldn't be supprised, its not turned the fans back on since i got it back out, interestingly
<cking> apw, worth looking at the power consumption when idle for both 32 and 64 installs
<apw> yeah i guess i'll install both side by side for testing
<apw> cking, fans came on when the machine touched 54, and even though they got it down to 51, they arn't getting it any further, and i suspect their hyterysis is lower than they achieve
<JFo> cking, just sent you some scripties and info
<cking> JFo, much appreciated!
<JFo> my pleasure :)
<cking> apw, well, wonder what it's like with Windoze for idle temp
<apw> windows is gone, the installer ate it
<cking> lovely
<apw> yeah
<apw> it was their fault... they used up all the four primary slots, for the first 30 and last 10GB of the disk
<cking> apw,  I normally dd the entire drive to some backup before faffin' around on this kit
<apw> and installer just heaped itself
<apw> you are more troll like than i :)
<cking> once bitten and all that
<apw> woner if its has a recovery paeriio
<apw> partition
<cking> that's some typo
<apw> indeed
<cking> i suspect you totally nuked it
 * cking spots a 75000+ jiffy delay in S3 resume - looks like the mysterious 5 minute delay to me
 * abogani waves BenC
<JFo> apw, this appears to be a quick answer type of deal, bug 289087
<ubot2> Launchpad bug 289087 in linux (Ubuntu) (and 1 other project) "Missing linux-image-debug packages and metapackages since Intrepid (affects: 22) (dups: 4) (heat: 182)" [High,Triaged] https://launchpad.net/bugs/289087
<abogani> smb: Hi! How should I proceed to see updated linux-rt package uploaded into Lucid archives?
<smb> abogani, sadly wait. I have a look next. But there is other stuff I need to do first
<abogani> smb: No problems. I would want only know that I haven't other things to do. Thanks (in advance).
<smb> abogani, No, the ball is on my side I guess. 
<abogani> smb: Ok. Thanks again.
<BenC> abogani: hey
<apw> JFo, what is there to answer, they are where the first comment says they are?
<JFo> apw, do we provide them?
<JFo> it seems as if there may be some confusion on the part of the bug commenters
<apw> have you read pitti's answer in comment #1 which point to where they are
<apw> other than the oens which are missing cause of the reaper of course, but most are there
 * smb is dropping off irc. need to concentrate
<apw> smb ack
<apw> JFo, there is no reasoning with people who do not read what is in front of them, i have added a yet furhter explanation and i think we should close it fix released
<JFo> ok, thanks apw
<JFo> done
<apw> JFo, ok i've put in a closing comment and closed it
<JFo> cool
<apw> ahh we overlapped, in just the right order
<JFo> heh
<amitk> apw: ogasawara: Since we're going to have two omap flavours for maverick, do you have a preference for the naming?
<amitk> apw: ogasawara: omapmainline and omap4bsp ?
<apw> amitk, is the current one not already omap ?
<apw> i don't see any need to rename the current flavour no ?
<amitk> apw: still cloning the maverick tree, I don't know what current is.
<apw> amitk, existing is omap
<ogra> amitk, cant you call them like the packages ? 
<ogra> -omap and -omap4
<ogra> amitk, cooloney already builds -omap4 and -omap exists in lucid
<ogra> once we can merge 3 and 4 we can easily switch back to -omap for everything, that saves a lot of upgrade transition stuff
<apw> amitk, are these two _new_ falvours or related to the existing omap and omap4 work we know about
<ogra> omap is the one we already have in lucid (omap3, just newer upstream version)
<ogra> omap4 will be new with the 10.07 release and we should provide a proper upgrade path to 10.10
<apw> ok and those are one and the same as the ones amitk is talking about?
<ogra> (since 10.07 will only be supported for a very short period)
<apw> if so then yes, omap is already called -omap and -omap4 seems approriate for the new one
<ogra> apw, -omap is todays lucid omap3 flavour ... apart from using a newer mainline i wouldnt expect any changes to it 
 * apw wonders where 10.07 is going to exist
<amitk> apw: 10.07 is mostly PPA work
<amitk> apw: ogra: omap and omap4 sounds good
<JFo> apw, mind having a look at bug 512192
<ubot2> Launchpad bug 512192 in linux (Ubuntu) "Can't configure Elan tech touchpad on Dell Inspiron 11z, Asus K7I0C and maybe also Dell Mini 10 (not V), Asus k40in, Asus U81A, Asus UL80-VT, and Asus N61Jq. (affects: 63) (dups: 3) (heat: 410)" [Undecided,Triaged] https://launchpad.net/bugs/512192
<ogra> amitk, great
<JFo> If I'm to have arm devs kicking around in my bugs they will need to follow the process
<JFo> as far as status goes that is
<apw> cking, this heap is staying 50% in C2/50% in C4 when 'idle' that sounds wrong to me
<JFo> sconklin, want to take a look at bug 564508 it has a git SHA in it
<ubot2> Launchpad bug 564508 in linux (Ubuntu) "Add USB_DEVICE Sitecom WL-349 to rtl8192su (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/564508
<apw> cking, in both 32 and 64 bit, its about the same
<sconklin> JFo: wilco
<apw> JFo, seems to be nothign to do on that than wait, unless you are proposing we take those four patches
<apw> i'd think we'd want the autodetect as well with it to be any use, and thats not till the next merge window
<apw> with all five we could test and consider them for lucid, depends how huge they are
<JFo> apw, no... it looks like one of the 'arm' people is working it, but had it set to In Progress and unassigned
<JFo> was my last comment too much?
<JFo> that is my main concern
<apw> no its fine, you said its not inprogress without an assignee, and you arn't assigning it to someone
<JFo> right
<JFo> cool
 * JFo moves on ;-)
<lag> smb: ping
<apw> smb is offline as he is working on some critical updates which are getting urgent
<lag> apw: No problem, I'll touch base with him tomorrow instead
<JFo> ogasawara, bug 582555 appears to be a heads up on some coming changes that we will need to remain aware of :)
<ubot2> Launchpad bug 582555 in linux (Ubuntu) "ndiswrapper has issues working under kernels 2.6.33 or greater (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/582555
<JFo> cnd_swap, if you are available, mind having a quick look at bug 581312
<ubot2> Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/581312
<JFo> so on that one that we were looking at the other day for Mark ^^
<JFo> something appears to be detected twice as separate input devices
<tgardner> ogasawara, I jumped on -virtual 'cause its causing me a PITA for the LTS backport.
<ogasawara> tgardner: it's all yours :)
<ogasawara> tgardner: I've dropped it from my todo list as I saw you've already started on it in the misc blueprint
<tgardner> ogasawara, yep - saw the wiki update which reminded me to get in touch with you
<ogasawara> JFo: am following up on 58255, thanks for the heads up
<JFo> certainly :)
<cking> apw, what's it doing when it's idle?
<apw> nothing as far as i can see.  in 64bit its even  98% n C4
<apw> and still on fire
<apw> i have the feeling its not using something it should to control itself
<cking> i assume you are using the powers of powertop to see whats happening
<apw> yep, it says its ok basically
<apw> but its not
<cking> "it's not == the fan is out of control"?
<apw> any idea waht the contents od /proc/acpi/processor/CPU/throttling means
<apw> cking, no i mean the machine is hot, over 50c at 'rest'
<cking> apw, not off the top of my head
<cking> apw, have you disabled compiz?
<apw> yes
<cking> that's one sick puppy then
<cking> apw, if it's 98% in C4 and still hot, then it sounds broken to me
<sconklin> ogasawara, when reviewing stable patches for SRU, how far do you go? Do you just see if they look sane? Do you try to apply them to see if they need fiddling? Build? Test?
<ogasawara> sconklin: all of the above
<apw> cking, my take on it too
<sconklin> ogasawara: ok, so how can you process 20 a day? :)
<ogasawara> sconklin: first I'd apply them, which usually goes quickly and cleanly
<ogasawara> sconklin: then I use the meld script to give them a once over
<ogasawara> sconklin: then a build, and test
<cking> apw, I'd still install another OS on it and see how that behaves.. just in case...
<ogasawara> sconklin: but I could only get through like 60-80 patches a day before my head would expload
<sconklin> ogasawara: ok, cool. I think I'm used to some of the driver backports, which often don't apply cleanly
<tgardner> sconklin, they don't make into the stable kernel _unless_ they apply cleanly.
<sconklin> tgardner: yeah, that's pretty obvious in hindsight
<tgardner> sconklin, do you have this? git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
<ogasawara> sconklin: do you have the cherry-pick.sh script and the git-compare-all script?  makes the applying and reviewing steps less painful
<sconklin> tgardner: no, I thought we worked from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git (or whatever the appropriate kernel is)
<apw> cking, dispite this machine claiming to have C1,2 and C4, the states in the kernel do not appear t match
<cking> apw, in what way don't they match?
<tgardner> sconklin, linux-2.6-stable.git has branches for each stable kernel
<sconklin> ogasawara: I think they are in stefan's scripts, haven't looked yet
<sconklin> tgardner: awesome
<apw> cking, /proc/acpi/processor/CPU0/power has this:
<apw> states:
<apw>     C1:                  type[C1] promotion[--] demotion[--] latency[001] usage[00003440] duration[00000000000000000000]
<apw>     C2:                  type[C2] promotion[--] demotion[--] latency[020] usage[00169577] duration[00000000004419124999]
<apw> note C1/C2
<apw> on my atom i get C1/C2 and C3 mentioned
<apw> (other atom)
<sconklin> tgardner, ogasawara sorry, dealing with lots of inbound phone calls - my son wrecked the car last night
<apw> sconklin, man oh man, that one needs locking up
<sconklin> tgardner: he claims that it was the toyota "unintended acceleration" problem, and the marks on the road sort of back him up, so I'm trying to keep an open mind
<ogasawara> sconklin: hope he's alright
<tgardner> sconklin, shit!
<sconklin> yeah, he's fine. Put it into a ditch and slid over about 50' of large rocks, completely destroyed the bottom.
<cking> apw, send me the acpi tables and I will poke around and see wassup
<mjg59> apw: What's exposed in /proc/acpi will depend on your BIOS - they often change from AC to battery, and the CPU states they map to may be entirely different again
<sconklin> he actually made some pretty good decisions about how to handle it
 * apw cries
<apw> cking, how do i get those for you
<achiang> an opportunity to improve arsenal scripts, perhaps?
<cking> apw, sudo acpidump > acpi.info and send it to me...
<apw> cking, hrm its quite big
<apw> cking, i emailed it to you, and also put it on chin
<cking> apw, yeah, lots of ACPI goodness - not
<apw> mjg59, thanks you've made my day
<mjg59> C3 in the bios will typically be C6 on modern CPUs
 * kees looks around for smb
<cking> mjg59, as in "C6 appears to be C3" in powertop?
<mjg59> To make matters worse, it may be of ACPI type C2 depending on the precise system
<ogasawara> kees: I think he's on holiday today?
<kees> ogasawara: ah-ha, thanks.
<apw> ogasawara, kees no he is offline doing some updates for kees without interuption
<mjg59> cking: Yeah, powertop has some knowledge of the actual CPU states that are used
<kees> apw: hah, seriously?
<mjg59> On my laptop, BIOS C2 corresponds to CPU C4
<apw> kees, if its related to your updates i may be able to get 
<apw> hold of him
<mjg59> Unless I'm on battery, in which case BIOS C2 corresponds to CPU C2
<mjg59> And BIOS C3 corresponds to CPU C6
<kees> apw: no, nothing there; he just wanted to get some help with bzr and I offered to help
<mjg59> And I don't get CPU C4 at all
<apw> kees, i suspect he will be back later when he is done with the work he is on, just couldn't concentrate with us wittering at him
<kees> apw: heh, okay
<JFo> apw, do we need to move postponed items from Lucid blueprints to some new blueprint?
<apw> jfo potentially yes
<JFo> k, was just looking over the lucid bug handling
<JFo> will add those items to the maverick one
<apw> ok
<JFo> so they can be reviewed
<JFo> done, want me to subscribe you to it?
<sconklin> ogasawara: the kernel team tools repo has git-compare-all but not cherry-pick.sh, want to send it to me and I'll add it?
<ogasawara> sconklin: sure, just a sec
<ogasawara> sconklin: sent
<sconklin> ogasawara: thx
 * JFo goes for some lunch
<kamal> cking: Hi -- at UDS you mentioned that you might have some pointers for debugging a laptop I'm working on where the system runs insanely slow after installation (but seemed fine when booted from a live-boot USB stick and during install) -- as if its being hammered by interrupts or something -- thoughts?
<apw> kamal, /proc/interrupts has the counts in it
<sconklin> kamal: check and see if bug #555595 looks related at all
<ubot2> Launchpad bug 555595 in linux (Ubuntu) (and 1 other project) "Intel graphics performance regression in 2.6.32-19 lucid kernel update (was: Firefox Slows Down Compiz) (affects: 8) (heat: 56)" [Medium,Triaged] https://launchpad.net/bugs/555595
<cking> yep
<kamal> apw: oh beautiful -- that looks like it will be very useful -- I'll boot the thing up and check it (in an hour when its done booting!)
<kamal> sconklin: this laptop seems like its just crawling, even long before X starts up -- does that exclude the bug you mentioned?  Either way, how can I disable i915 completely with a boot option?  (seems like a good thing to know how to do).
<tgardner> sconklin, the latest pull request from Dave Airlie includes Intel Cougarpoint support
<apw> kamal, i think u can add single to the boot command line to stop the rest of booting
<sconklin> kamal: it's probably not the same, since the bug referenced is apparently related to compiz
<kamal> apw: ah yes, that'll do.  thanks
<kamal> sconklin: got it
<sconklin> kamal: have you tried i915.modeset=0 ? just to isolate KMS
<apw> ogasawara, i boot tested the amd64 version of your .34 based kernel and it worked
<ogasawara> apw: woot!
<kamal> sconklin: I haven't tried it, but will do.
<abogani> tgardner: Hi Mr Gardner, May disturb you with a single question?
<sconklin> kamal: the otehr thing you can do is tell the kernel to use vesafb, don't remember the command line - that will be slower but shouldn't crawl
 * apw notes that abogani has used up his single question
<ogasawara> heh
<sconklin> tgardner: Yeah, I knew that support was going in but had heard that it was still the basic plumbing parts, I have not looked at it
<apw> ogasawara, yeah didn't fix my issues but did at least boot
<abogani> apw: ;-)
<kamal> sconklin: i'll find the switch if I don't get joy from the lower level investigations -- I think I'll be able to reproduce the problem with 'single' even.
<ogasawara> apw: what issues is that?
<apw> abogani, its always best to ask the original question out right, as we can say no to the question as much as say no to the request to ask
<tgardner> abogani, ask apw, he's got all the answers today.
 * apw quits
<apw> ogasawara, i have a fan issue on a new bit of kit here
<apw> .34 didn't fix it
<ogasawara> apw: ah.  I'll cross my fingers for .35 to magically fix it :)
<abogani> apw, tgardner: Is there a chance to have -preempt kernel on i386 in Maverick? I would want use it a default kernel for Ubuntu Studio.
 * persia notes that many Studio users still use i386, for all they have been advised to use amd64 many times.  Some cite HW issues.
<c^rl> mdomsch: does dell-firmware working on lucid?
<tgardner> persia, won't those folks having 64 bit compatibility issues get screwed anyway with the recent toolchain change to i686?
<persia> No.  I can purchase a new computer in the shop today that runs i686 and not amd64.
<tgardner> atom based I assume
<persia> or VIA, but yeah, it only happens for special chips.
 * persia is kinda happy the C7M is now "old", as it didn't do all of i686
<tgardner> abogani, I've been trying to limit the number of flavours (though I'm in the process of converting the virtual sub-flavour into a regular flavour)
<tgardner> besides, I thought the studio folks were using the -rt kernel anyways
<amitk> abogani: do you mean that with all the  -rt stuff that has gone into mainline, you won't need an -rt kernel anymore?
<abogani> tgardner: Is the problem that you don't want offer more flavours? So could I put an universe package (like -preempt2) and it would be OK for you?
<persia> Not since hardy, since -rt hasn't been able to match kernel versions well, and most folk don't really need -rt for their stuff.
<persia> amitk: Not all of it is mainline yet, although it's getting close.
<abogani> amitk: For almost all multimedia users HZ=1000 and PREEMPT =ycould be suffice.
<amitk> persia: i didn't mean all of it went in, but all that did go in :)
<tgardner> abogani, right. more flavours mean more build time and more maintenance.
<tgardner> a universe package is fine with me
 * tgardner notes that ogasawara has been busy.
<amitk> wasn't cnd_swap going to look into PREEMPT? Perhaps we should add HZ=1000 to his study list :)
<persia> abogani: If you do a universe package, please make it from the same source tree so that we don't get out of sync.  I'd like to be able to use --preempt for the default installer, but would prefer to avoid i386/amd64 bug skew.
<apw> 'for the default installer' ??? persia ?
<persia> apw: For the Studio flavour, yes.  A significant majority of Studio users need lower latency, as opposed to Desktop users.
 * apw idly wonders what the heck they could need it for
<persia> Similar to how Server users have a different kernel flavour, do to different usage.
<persia> multiple audio generators being kept in sample-accurate sync, mostly.
<abogani> persia: What is exactly the "i386/amd64 bug skew" which you would want avoid?
<persia> So if one is generating at e.g. 90kHz, one needs to run *each* tone generator and get the output each 10us.
<apw> well only if you don't think gneerating ahead is a good idea, but hey
 * abogani sound odd to have an amd64 -preempt kernel in main and a similar kernel in universe....
<persia> abogani: My worry is that if amd64 -preempt is build from one package, and i386 -preempt is build from a different package, we might end up with issues.
<apw> that does sound unhelpful
<persia> apw: You can't generate ahead if some of the tone generators depend on the others for input.  Consider a filter and needing to adjust wet/dry mix.
<amitk> ogasawara: why is ONDEMAND turned off in maverick?
<tgardner> amitk, its enabled, its just not the default
<abogani> persia: Sorry I'm stupid: Why ever we should use two different source packages?
<amitk> $ grep -r CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND debian.master/config/*
<amitk> debian.master/config/config.common.ports:# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
<apw> abogani, if you are uploading a separate paackage to universe its a separate source package
<amitk> debian.master/config/config.common.ubuntu:# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
<amitk> tgardner: ^^
<apw> amitk, thats the default
<apw> our default is not ondemand
<tgardner> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
<amitk> tgardner: aah, sorry, I'm blind
<persia> abogani: If there aren't two packages, ignore me :)
<abogani> if someone put a new package in Universe it should rename it completely so now way to have an amd64 -preempt (in main) and a i386 (in universe).
<persia> To me it makes sense to only have *one* -preempt flavour.  I don't think main/universe matters (and really, unless it ends up on some main-only flavour's images, the binaries will be in universe anyway)
<abogani> Can we move all -preempt stuff in universe adding i386 in the same time?
<apw> abogani, the issue for us is just how long a build takes if we add loads of flavours
<apw> it already takes nearly 6 hours to build
<tgardner> abogani, you mean drop the preempt flavour in amd64 ?
<tgardner> I mean, move it from main into your universe kernel?
<abogani> tgardner: Move it to (not mine) universe for provide both i386/amd64 binary packages.
<sconklin> ogasawara: I renamed the script to drop the ".sh" for consistency with the rest of the tools, and it's now in the maintscripts directory of the kteam-tools repo
<ogasawara> sconklin: awesome, thanks
<tgardner> abogani, I'm fine with that. I don't think --prempt is main is getting much use anyways.
<tgardner> s/is/in/
<apw> tgardner, + [rtg] drop sub-flavour processing in favor of making virtual a regular
<apw> i think that that is already on the config blueprint
<tgardner> apw, too many places to keep track of stuff. my feeble mind is overwhelmed.
<apw> ogasawara, did i see the -virtual cleanup stuff there too ?
<ogasawara> apw: -virtual cleanup bit moved to the misc blueprint
<apw> ok cool then we are good
<abogani> So if I propose to you a new -preempt packaging (which reuse linux-source-2.6.xx for build for avoid to insert again linux kernel source code) that support i386 and amd64 you could stop to build yours?
<abogani> tgardner, persia, apw ^
 * persia is happy with that model, as long as there are udebs
<tgardner> abogani, I think I understand that. You want me to remove -preempt from the main pocket build?
<apw> abogani, if you are going to do that we could give you some help making it like the other branches
<apw> abogani, so that it can be easily rebased onto the current master as that progresses so you get the goodness for near no effort
<mdomsch> c^rl: firmware-addon-dell  and firmware-tools?  for BIOS updates for most systems, yes.
<abogani> tgardner: Yes.
<tgardner> abogani, I'm fine with that.
<persia> near no effort sounds like a bonus :)
<tgardner> apw, agreed?
<abogani> persia: Could you help me in that case (I never supported *udebs in my kernel packages)?
 * persia knows little about them, but expects that what apw describes can handle most of it.
<apw> abogani, if we do it just as a derivative it should support udebs too
<apw> as it should be the real packaging
<apw> tgardner, i am good with pulling it out
<apw> i could put together an example tree for it from whats in ours, and show you how to maintain it
<tgardner> apw, ok, I'll take care of it as part of the -virtual flavour rework
<apw> tgardner, ack, want to action me on that blueprint to mock this up for abogani 
<apw> abogani, i think it makes sense for me to mock it up, as i've done a number already
<tgardner> apw, eh? I can't even figure out where to mark up my task list, much less yours
<persia> abogani: apw: tgardner: Thanks a lot!  This should give us a much better story to tell for Studio.
<apw> tgardner, never mine, i'll do it
<ogasawara> tgardner, apw: I'll get the blueprint work items added
<apw> ogasawara, ok thanks
<tgardner> see, if I whinge enough ....
<apw> abogani, so i'll try somethign mocked up within the week, with a write up on how it works
<abogani> apw: Ok Thanks.
<apw> tgardner, when you are switching out the virtual stuff, if we arn't going to do that back in older releases
<apw> it would be best not to remove the support yet, just stop using it for maverick
<apw> else we'll diverge 'debian' and have more maintenance of it to worry about
<tgardner> apw, thats why I'm hustling to get it done. I think we _should_ backport sub-flavour removal to older releases. it was a wart to begin with.
<apw> ok then thats fine
<tgardner> apw, I agree we should have a common debian across all releases
<apw> w
<apw> when do you think you'll poop out the -virtual changes ?
<tgardner> today or tomorrow.
<apw> oh right ... cool
<tgardner> I've got it basically complete, but need to whittle down the config.
<tgardner> I could release it as is, its just a bit larger then need be.
<apw> no thats fine
<abogani> apw: Should I preserve the same kernel configuration?
<abogani> apw: For -preempt I meant
<apw> abogani, i think thats a sensible starting point
<apw> abogani, let me get you a basic tree together in the right form
<apw> that should come out in the wash me thinks
<apw> then i can hand it off to you once its working
<apw> tgardner, on the subject of the debian commonisation, i think the enforcement file is proobabally going to be release specific ... what do you think?
<tgardner> apw, likely, some features will appear and disappear according to kernel version
<apw> i was th
<apw> tgardner, in that case i was thinking it should move to debian.master
<apw> the enforcement list
<tgardner> makes sense
<apw> so its 'master' bracnch specific ... cool ... will do that
<sconklin> tgardner: bug #564508 is for lucid and/or karmic and has a trivial patch attached, but also requires a new firmware blob rtl8192sfw.bin. What's the process for getting that all sent up for acks and applied in a synchronized way?
<ubot2> Launchpad bug 564508 in linux (Ubuntu) "Add USB_DEVICE Sitecom WL-349 to rtl8192su (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/564508
<tgardner> sconklin, the firmware blob needs to be properly licensed, then added to linux-firmware and SRUd. The ID updates also need a trivial SRU
<tgardner> sconklin, cnd_swap has been handling firmware updates
<sconklin> tgardner: ok, I'll walk through it with him tomorrow, thanks
<cking> yawn
<pgraner> apw: you about?
<cnd_swap> JFo: I'll try to look into that key issue from Mark tomorrow
<JFo> thanks cnd_swap 
<JFo> I figured you'd either see that at some point or I'd ping you on it tomorrow
<JFo> so, no worries
<apw> pgraner, hi
<tgardner> apw, just dropped you a note about bug #563156 which is what I think he wanted to talk to you about.
<ubot2> Launchpad bug 563156 in linux (Ubuntu) "laptop runs hot, shorter battery life, fan always on - lucid (affects: 17) (heat: 80)" [High,Triaged] https://launchpad.net/bugs/563156
<pgraner> apw: rtg is spot on
<apw> clearly two or three different bugs conflated in one
<apw> one appears to be radeon drivers are less good with power than fgrlx on lucid
<apw> another seems to be late fan start on some machines with intel graphics
<apw> and possibly one report which was the EC issue
<pgraner> apw: yea, I was talking to rtg about having a wiki page for the "issue" with how to debug and report explaining that everything in one bug is bad
<pgraner> apw: and we can get jfo to put a automated message in the bug pointing at the wiki page
<apw> ok
<JFo> yep
<tgardner> sure would be nice to have editorial ability and just delete the crack
<pgraner> apw: much like bryce does for X bugs that go nuclear
<pgraner> tgardner: yea we can keep wishing
<Deem> apw: i think it might interest you, that the g15daemon doesnt cause the error so my keyboard dies. its maybe something other.
<apw> Deem, are there stack traces in your logs whne it breaks
 * JFo makes a note on automated processing of specific issues
<apw> JFo, i'll get something together in the am on the wiki and we can get it out there tomorrow
<JFo> coolness
<apw> pgraner, i think the dell mini 10v is a herring rouge.  i updated and never saw the issue
<apw> the others look to be a combination of victims of the EC: bug which is likely fixed if we ask them to test and a real issue with ATI powersaving
<pgraner> apw: you know I have it as you saw it on my machine but I will get hard data from karmic & lucid 
<vanhoof> grrr
<vanhoof> note to self: there are other places besides walmart that can make a passport photo :)
#ubuntu-kernel 2010-05-20
<MTecknology> Is it possible to see what kernel driver is being used for something being listed in lsusb but not in lspci?
<paultag_> cnd_swap, poke -- you around?
<paultag_> cnd_swap, I've been having a kernel issue with rt2500pci -- reported LP#456977 -- any chance I could bribe you with a few beers to look into it?
<jjohansen> paultag_: he isn't around right now, should be in tomorrow
<paultag_> jjohansen, cheers, thanks
<cnd_swap> paultag_: heh, rt2500pci has some real issues
<paultag_> cnd_swap, lucky me, I had it lying around, haha
<cnd_swap> I've looked at some of them before, but it seems to be an issue more upstream
<paultag_> cnd_swap, aye, well no biggie. I'll work that hack into my init script
<paultag_> scripts *
<cnd_swap> if you find it works better in the maverick or some mainline kernels, then we could look into getting a fix into lucid
<paultag_> cnd_swap, I think it's just a driver issue. This one looks like a power saving mode issue
<cnd_swap> but we don't really have anyone on hand with tons of wireless driver experience
<paultag_> cnd_swap, yeah, I can understand that for sure
<cnd_swap> paultag_: yeah, if you find a patch upstream, we'll definitely take a look
<cnd_swap> unfortunately, I'm kinda swamped in the short term with other work
<paultag_> cnd_swap, I'll be on the lookout -- thanks Chase :)
<paultag_> cnd_swap, don't sweat it
<cnd_swap> maybe someone else on the team could take a look?
<cnd_swap> paultag_: but I'd recommend testing out the maverick kernel
<cnd_swap> just to see if it helps at all
<cnd_swap> kamal: you still around?
<kamal> cnd_swap: yes, hiya
<paultag_> cnd_swap, I'll pull it down and give it a go
<cnd_swap> kamal: save me!
<cnd_swap> kamal: actually, lets chat on #hwe
<paultag_> cnd_swap, shall I join you guys?
<ribo> hi guys, I'm having a problem that is killing all my md arrays and generally causing a lot of pain that is fixed here: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=91b25002bd58f55207e4662a611a6cded4ef9834
<ribo> I'm using lucid server, and it's not backported in, apparently
<ribo> people here: https://bugzilla.kernel.org/show_bug.cgi?id=13594 say it's fixed in .34
<ubot2> bugzilla.kernel.org bug 13594 in SCSI "SMART responses for SATA disks on SAS get interpreted as errors" [Normal,New]
<pgraner> ribo: that won't be in Lucid since its a .34 commit, you can open a LP bug and send an email to the kernel-team@lists.ubuntu.com mailing list with the commit id and request that it be added as an SRU along with the LP bug number and it will be considered
<pgraner> ribo: https://wiki.ubuntu.com/KernelTeam/StableKernelMaintenance#SRUs/bugs
<ribo> ok, thanks; just filed the LP bug
<ribo> I guess I'll build from source as a stopgap
<jjohansen> ribo: another option is to use the maverick kernel which is currently .34 based
<panda|x201> jk-, ping
<jk-> hi panda|x201
<jk-> so there are two options for fixing 557742 - we either get a fix into the kernel package, or update the alsa code in linux-backports-modules
<jk-> updating the kernel package will probably mean that the patch has to go into the upstream stable tree
<panda|x201> jk-, what's linux-backports-modules package for? we will stick on current version 2.6.32? so we need to backport from new kernel?
<jk-> that's right, it's stuff backported from newer kernels to work with the currently-release .32 kernel
<panda|x201> so "updating the kernel package will probably mean that the patch has to go into the upstream stable tree", so upstream here means upstream of ubuntu kernel repository?
<jk-> yes
<jk-> if you can identify a small non-intrusive fix, then we may be able to use that in the main kernel package - see https://wiki.ubuntu.com/KernelTeam/KernelUpdates
<panda|x201> jk-, we put all the audio drivers - alsa code into a separate package linux-backports-modules?
<jk-> that's correct
<panda|x201> jk-, we always rely on DKMS package to deal with backported module?
<jk-> no, DKMS is only used in certain cases, generally only by the OEM team
<panda|x201> jk-, em, looks like audio drivers are not part of the kernel package, but they are actually stored in the same repository, but just build separately?
<jk-> the audio drivers are part of the kernel package.
<jk-> the *backported* audio drivers are in the linux-backports-modules-alsa-$VERSION package
<jk-> so the version of the alsa tree in the current linux-backports-modules is 1.0.22.1, but the fix for that bug has gone into 1.0.23
<panda|x201> jk-, sounds confusing, then shall we upgrade alsa tree as well on 10.04? or you prefer back port a patch from alsa 1.0.23 to 1.0.22.1?
<jk-> we will not upgrade the alsa tree in the main kernel
<jk-> depends what the backported patch looks like
<jk-> if it is small and unintrusive, it may be able to go into the 10.4 kernel
<panda|x201> jk-, ok, so which team take care of alsa? let's forward such a backport requirement to foundation team?
<jk-> no, the kernel team maintains the alsa modules
<jk-> (the userspace stuff in the alsa-* packages is not related to this bug)
<panda|x201> jk-, OK, so not upgrade the alsa tree in the main kernel is because this upgrade might cause other driver stop working?
<jk-> it could cause all sorts of other stuff to stop working :)
<panda|x201> jk-, well, I will first start from a general diff between two version of alsa-driver and then focus on what have been modify on X201 driver
<panda|x201> jk-, if we can figure out a easy-to-fix patch against 1.0.22.1 to fix, then that's our first choice?
<jk-> I would suggest looking at Jerone's DKMS file, to see if you can create a small patch based on that
<panda|x201> jk-, BTW: think-acpi is also maintained by kernel team?
<jk-> it's a kernel module, so yes :)
<panda|x201> jk-, OK, let me check with Jerone's DKMS file.
<CoolAcid> Good Day - A quick Q (Hope I'm in the right place) regarding a fix to the kernel - specificly getting a PCI device ID added to a driver. I already attempted (last year) to talk the the maintainer but didn't get very far. So I'm looking for 2 things - 1, Get the update into Ubuntu Kernel, 2 get it into mainline stream. 
<jk-> panda|x201: there's a few changes in that patch to the patch_conexant.c file, they look interesting
<jk-> CoolAcid: try 2) first, then 1) should happen automatically :)
<CoolAcid> jk-: Sigh.. I was afraid of that ;)
<jk-> CoolAcid: you shouldn't be afraid of that :)
<ribo> jj-afk: thanks, I'll do that
<CoolAcid> which means I need to build a ubuntu kernel to get working, and then a new kernel for upstream... :)
<CoolAcid> Oh - git isn't my friend..
<CoolAcid> actually, the patch *should* work on vanila once I build it from ubuntu.. so maybe i'll try that.. 
<CoolAcid> any good docs on submitting patches to the tree?
<jk-> yeah, I don't think there should be many changes between the two if it's just a PCI ID.
<jk-> to the upstream tree? try the Documentation/SubmittingPatches file
<CoolAcid> sigh - its been so long since I hacked @ kernel..
<jk-> panda|x201: https://patchwork.kernel.org/patch/92496/ looks interesting
<jk-> panda|x201: upstream commit here: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=7b2bfdbc0dee5a321b5c02febe157adebd33ab3a
<panda|x201> jk-, yeah, thanks, but seems those patches are not submitted from Lenovo themselves?
<jk-> panda|x201: that's correct
 * panda|x201 start to pull ubuntu-kernel slowly ...
<jk-> brb, reboot
 * apw waves
 * lag moons apw
<smb> mmorning
<jk-> smb!
<lag> Hey smb :)
<jk-> apw!
<smb> woha
<amitk> :)
 * smb brings his comm channels online
<amitk> lool: Can the versatile flavour use general drivers or only the specific ones the qemu supports? I'm wondering if we should enable all other drivers as modules?
<lool> amitk: I think I had enabled a lot of crack in the lucid config already
<amitk> lool: well, lots of drivers are disabled. But I'm wondering if it makes sense in a virtual environment
<amitk> apw: Meego will use btrfs by default: http://lwn.net/Articles/387196/
<apw> yeah a lot of things are going that way amitk 
<lool> amitk: I thin kI had enabled a bunch of USB drivers
<apw> it cirtainly will be an option for us, depending on how the grub support goes, ie how quick we get it it may yet be default for us
 * apw shouts at the wiki ... faster dammit
<tankenmate> top - 10:00:18 up 79 days, 20:07, 16 users,  load average: 2293.53, 867.84, 311.58
<tankenmate> now... that's a load averge...
 * lag shouts at the wiki ... start working search
 * lag has been conned by his ISP
 * lag is calling his ISP to moan about his outrageously slow internet connection 
<amitk> lag: don't judge your ISP too harshly against wiki.ubuntu.com and launchpad.net speeds
<lag> amitk: I'm not: http://www.speedtest.net/result/820427581.png
<lifeless> check your wifi too
<lifeless> can easily cripple things if you have interference
<lool> amitk: If you need any change either because you need the driver or because it makes maintenance easier, go for it; in lucid, I did try to enable things which remotely made some sense to me, but I didn't enable buses which versatile didn't have for instannce
<amitk> lool: I mostly noticed it while enabling the mainline version of the omap kernel, lots of differences between the versatile and omap configs due to drivers being disabled in the former
<popey> JFo: when you get a moment, could you look at bug 572868 . Is it a kernel bug or some other part of the stack?
<ubot2> Launchpad bug 572868 in ubuntu (and 1 other project) "Lucid Live CD/USB freezes shortly after start (affects: 19) (heat: 82)" [Undecided,Confirmed] https://launchpad.net/bugs/572868
<amitk> lag: that is definitely slow, call the ISP :)
<lag> amitk: Yup!
<cking> lag, your connection to the internet is it over copper or a wet piece of string?
<cking> ;-)
<lag> cking: You're meant to dampen the string?
<lag> cking: That could be my problem 
 * lag fetches the watering can
<lag> No joy! Now it just looks like I couldn't make it to the toilet in time, and left a trail 
<cking> the mind boggles
<lag> Quite
<apw> https://wiki.ubuntu.com/Kernel/Debugging/HighTemperatures#preview
<apw> smb, cking ^^
<amitk> apw: do you know if perf userspace works with arm now?
<apw> i do not yet know, i have it on my list for this week to get it enabled and find out, i should know today
<apw> lag, git clone --bare /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-lucid.git ubuntu-lucid.git
 * lag copies, pastes and closes eyes
<apw> lag so you want something like the following locally where you are going to push from:
<apw> git remote add zinc ssh+git://ljones@zinc.ubuntu.com/srv/kernel.ubuntu.com/git/lag/ubuntu-lucid.git
<cking> lag, http://smackerelofopinion.blogspot.com/2009/08/git-version-control-books.html
<lag> apw, cking: git config push.default nothing
<apw> cking-afk, the images in that lin arn't working, well one is one not
 * smb seems to listen to the soundtrack of it :-P
<cking-afk> apw, ta, will fix it
<smb> apw, You want to mention sensors and its setup or you think that gets too complicated. Not all ACPI exports a usable thermal zone
<smb> apw, Re: wiki previeww
<apw> smb, if you have amchines where there is a benefit sure it can be an option
<apw> its much more complex and requires s/w installed tho
<smb> unfortunately yes
<cking> It may be worth adding the sensors info as as foot note
<smb> There is the dreaded aa1, though probably that had not any issues
<cking> smb, what's the aa1?
<smb> cking, acer aspire one
<cking> acer awful one
<smb> apw, Beside of that it looks good to me
<cking> +1 from me too
<cking> s/scratch re-install/clean re-install/ perhaps?
<smb> Maybe lag needs to review. I am too much used to anglish, I just correct it in my mind. :-P
<apw> cking, perhaps full reinstall
<apw> smb, cking et al, do any of you remember manjo talking about the new firewire stack and what the outcome was
<smb> apw, I remember darkly
<apw> dimly or vaguely :)
<smb> I believe to remember some note saying its in Maverick
<smb> apw, both. :-P
<apw> :)
<pgraner> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/583099
<ubot2> Launchpad bug 583099 in linux (Ubuntu) "Netbook runs hot with Lucid (affects: 1) (heat: 6)" [High,Confirmed]
<apw> pgraner, so what was the outcoming
<apw> sudo apt-get install ubuntu-desktop^
<JFo> pgraner, crap! only 2 features?! we need like 12. :)
<smb> lag, Heres JFo. JFo heres lag. He wants to know whats hot in the bug world. :)
<JFo> heh, everything ;-)
<JFo> lag, what is your specific interest subsystem wise?
<JFo> graphics, video, wireless?
<lag> JFo: Break me in gently 
<JFo> something like that 
<JFo> lag, I'll see what I can do ;)
<lag> JFo: It's all just code
<lag> I'm more interested in the procedures of BUGFIX atm
<lag> So something light would be appreciated 
<JFo> ok
<JFo> so anything you have looked at that interests you?
<JFo> you want to do bugfix rather than triage?
<tgardner> JFo, sic him on bug #583128
<ubot2> Launchpad bug 583128 in linux (Ubuntu) "SMART responses for SATA disks on SAS get interpreted as errors (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/583128
<smb> JFo, I guess bugs with patches might be a good training ground
<lag> Excuse my ignorance, but what's the difference?
<JFo> tgardner, will do :)
<lag> Patches == good
<JFo> and I think you are right smb, we can do that next :)
<JFo> so lag, take a look at the bug tgardner dropped in
<JFo> and let us know your questions
<smb> lag, Triage is battle with users to get information. bugfix is getting an upstream patch and let it test. ;-P (put a bit over simplified)
<lag> Oh, you'll get questions ;)
<JFo> heh, I look forward to it
<JFo> smb, I think that was perfectly described
<apw> pgraner, from the machine as it is in the lucid-upgrade it is looking 'good' ie as good as the lucid-fresh
<cking> http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=commit;h=257d32b05f6dad8c2a1a0726ae2b66aa6f636b9e
<apw> Geeqie 1.0beta2, This is an alpha release.
<apw> !?!
<jk-> soooo, what's the policy on l-b-m? should I poke someone to get alsa upgraded to the latest release?
 * smb hides
<apw> jk-, lbm for which release
<smb> I guess the one of Lucid
<smb> The one I have not uploaded yet
<jk-> apw: lucid
<apw> thats stuck wiating for a preceesding update to go out i think
<jk-> smb: so you have an update pending?
<jk-> oh, cool
<smb> Ok, Given that there seems to be no abi bumper I could prepare and upload now
<smb> jk-, Yes there is one pending
<tgardner> smb, lucid lbm also needs a compat-wireless update
<tgardner> luis announced a 2.6.34 stable yesterday
<smb> tgardner, Is there some pull request in the mail? Oh ok maxybe not :)
<tgardner> smb, maybe not :)
<jk-> smb: is that including alsa 1.0.23?
<smb> tgardner, Should I wait for you then? 
<smb> jk-, So it says in the log
<jk-> smb: you rock
<smb> jk-, Nah, I am just the librarian. :)
<tgardner> smb, I'm not gonna get to it for a couple days yet. I wanna finish this LTS backport stuff
<smb> tgardner, Ok, I guess then I put the current form into proposed. One upload more or less should not matter for lbm
<jk-> smb: to prevent future questions, is there a way I could have checked that for myself?
<tgardner> jk-, look at the lbm repo?
<JFo> apw bug 6290
<smb> jk-, You could log at the git web on kernel.ubuntu.com
<ubot2> Launchpad bug 6290 in kino (Ubuntu) "DV capture over Firewire is broken (no rights for /dev/raw1394) (affects: 17) (dups: 10) (heat: 226)" [Low,Triaged] https://launchpad.net/bugs/6290
<jk-> ok, so is the git repo is synced with what's in the archive manually?
<tgardner> jk-, the git repo is the source of what goes into the archive, just like the kernel
<jk-> sure, but there may be a delay between stuff hitting the repo and stuff hitting the archive, right?
<smb> jk-, As tgardner says. I am just using that content to create the upload package for proposed
<jk-> riiiight.
<smb> jk-, It hits the repo first
<tgardner> jk-, there can be a substantial delay between repo updates and the source package upload. 
<apw> JFo, i have a reply in my editior now for that, that i will copy to ubuntu-kernel-team
<apw> tgardner, i am replying on the firewire thingy
<JFo> apw, cool
<JFo> do I need to watch whatever 'kino' packages?
<JFo> because as it stands, I have no clue what that is :)
<JFo> there are apparently 32 bugs opened on it. Most of them are new
<JFo> or rather in the new state
<jk-> and is that just the time between the commit and smb uploading the package? or is there some queue in the process there, after smb has done the upload?
<apw> JFo, kino is a userspace tool, so no
<JFo> ok
<apw> jk-, lbm is typically uplaoded in lock step with the kernel and the kernel uploads take time and testing
<tgardner> jk-, it mostly has to do with smb's workload, -security updates, etc. its non-deterministic
 * JFo moves on :)
<apw> and if we have things like security for example in the way it can take much longer
<smb> jk-, yep. and there is also the delay between proposed and updates
<smb> jk-, If there are other things pending which might lead to require another upload to lbm as well I can decide to delay
<jk-> the non-determinism is fine, just wanting to know what's coming without bugging smb :D
<smb> jk-, Look in proposed and look into the repo. Everything else requires you bugging me 
<jk-> ok
<ogra> apw, geeez ! you plan to fix firewire ?!? what are our users supposed to complain about then ?
<jk-> ptrace
<ogra> ah, k 
<ogra> phew
<apw> manjo, hey ...
<pgraner> JFo: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
<manjo> apw, hi
<apw> manjo, do i recall correctly that you were championing the idea of using the new firewire stack for Maverick
<manjo> yes
<apw> good, i've added a task to the misc blueprint to cover that
<manjo> I had created a blueprint
<apw> if we are going to make such a large change it needs to really be in place for apl
<apw> alpha-1
<apw> manjo, whats the blueprint name
<apw> i've not seen it on our lists anywhere
<manjo> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack
<manjo> I created this and pointed ogasawara to it 
<apw> hrm why is this not on the list
<apw> manjo, ok thats casue the format was wrong... think i've fixed it up, we'll see in an hour
<manjo> ok
<apw> manjo, i thought we had both stacks enabled in the kernel already, that it was purely a userspace decision which was in use
<manjo> currently the default is old stack, we need to enable the new stack and blacklist the old one , it does not involve much effort todo
<manjo> apw, it should take all of 5mts todo this item
<apw> i beleive the new is already enabled kernel side
<apw> and hidden by modprobe blacklists
<apw> so i think the switch is all userspace from our point of view
<JFo> pgraner, do you want me to create a blueprint for the Launchpad stuff we discussed with jml since he seemed to think they may not get to everything this cycle?
<JFo> or rather since there are only 2 features we can request as a team
<apw> manjo, we are on mumble for vcm
<manjo> apw, ack
<manjo> my mic does not work
<cking> http://cgi.ebay.co.uk/PC-Computer-USB-Single-Action-Foot-Switch-Pedal-HID-NEW-/280505820192?cmd=ViewItem&pt=LH_DefaultDomain_3&hash=item414f732420
<cking> apw ^^
<jk-> new modifier key for emacs?
<lag> cking: :D
<lag> jk-: Push-to-talk on chatting software :)
<jk-> ah :)
<manjo> hehe
<smb> manjo, You will probably need to remind me of the bug number and subject of the email for your sru
<manjo> smb, will do.. just a sec 
<smb> manjo, best do it in email. my irc brain is limited
<manjo> smb, yep will email reminder you 
<cwillu_at_work> I don't suppose anyone has a lucid kernel with CONFIG_DEBUG_PAGE_ALLOC enabled kicking around?
<cwillu_at_work> I've been running btrfs as the rootfs on a couple of my machines for 10 months or so;  after updating one of them to lucid and recompiling btrfs from their recommended repo (-unstable), I get instability in that machine
<ogasawara> apw: I see alpha1 is nearing (june 3).  how many days before the milestone did you typically do the final kernel upload for the milestone? 2 days minimum?
<apw> ogasawara, we are on mumble
 * ogasawara joins
<cwillu_at_work> cmason in #btrfs suggested that as a next step of debugging it
<ogasawara> apw: hrm, mumble doesn't like my password now
<apw> ogasawara, switched to SSO instead, change your username to your launchpad _email_
<smb> ogasawara, Your email address and launchpad pw
<apw> and use that password
<ogasawara> ah, thanks
<tgardner> ogasawara, be sure to leave your speakers on so we can annoy everyone in your house
<ogasawara> heh
<JFo> <-lunch
<jj-afk> hey smb
 * jjohansen is looking for his mike
<apw> heh
<jjohansen> apw: nope
<jjohansen> my wife cleaned up the desk while at uds
<jjohansen> hehe :)
<jjohansen> hrmm I have lost dns
 * jjohansen goes to reboot the router
<pmatulis> smb: howdy, any movement on bug 513848 (fix released for jaunty and karmic)?
<ubot2> Launchpad bug 513848 in linux (Ubuntu Karmic) (and 1 other project) "[karmic] CPU load not being reported accurately (affects: 1) (heat: 14)" [Low,Fix committed] https://launchpad.net/bugs/513848
<smb> pmatulis, Jaunty?
<pmatulis> smb: well the bug says nominated for jaunty
<smb> pmatulis, I think I have commited something to Karmic. Must check
<pmatulis> smb: and then only fix committed for karmic, not released
<smb> pmatulis, Give me a second to look, I don't know right out of my head
<smb> So from the log I think it is in updates for Karmic
<smb> pmatulis, I would not do it for Jaunty if there is not a really pressing reason
<pmatulis> smb: so the status should be 'Fix Released' for Karmic
<smb> pmatulis, The effect is not really critical
<smb> pmatulis, it is
<smb> pmatulis, oh bugger
<pmatulis> smb: why does it show 'Karmic  Fix Committed' ?
<smb> pmatulis, sorry
<smb> My fault
<smb> I got confused
<smb> pmatulis, Ok so it is only committed for Karmic
<smb> pmatulis, I did not upload fresh as there is a securtity upload in progress
<smb> pmatulis, As soon as that is out I will upload the missing things
<smb> pmatulis, Its hard to give a good ETA but hopefully the week after next week
<pmatulis> smb: thanks for the update.  just trying to mop up these support cases that are all over the floor here
<smb> pmatulis, No worries, there is a lot of stuff lying around after several travels
<tgardner> kees, whats a good default group to use when migrating dchroot to Lucid schroot ?
<manjo> apw, https://ieee1394.wiki.kernel.org/index.php/Juju_Migration
<manjo> apw, did I read the news about suse rebasing their kernel to latest for SLES ?
<manjo> SLES 11 SP1, Novell is rebasing the kernel on the Linux 2.6.32 version. 
<jjohansen> manjo: where did you see that?
<manjo> http://www.serverwatch.com/news/article.php/3883226/Novell-SUSE-Linux-Enterprise-11-Updates-Kernel-Virtualization.htm
<jjohansen> manjo: not really all that surprising, the plan a year ago was that they would roll out new kernels for hwe and if certifications required older kernels that they would run them virtualized under the newer kernel
<jjohansen> there used to be an awful lot of work backporting features to older kernels which would endup breaking the kernel abi anyway
<manjo> ie custom kernel per app :) 
<jjohansen> well, just for those whose certifications require it
<jjohansen> :)
<popey> lastlog popey
<popey> bah
<popey> JFo: when you get a moment, could you look at bug 572868 . Is it a kernel bug or some other part of the stack?
<ubot2> Launchpad bug 572868 in ubuntu (and 1 other project) "Lucid Live CD/USB freezes shortly after start (affects: 19) (heat: 82)" [Undecided,Confirmed] https://launchpad.net/bugs/572868
<JFo> looking
<JFo> sorry for the delay, was trying to have some chicken soup
<JFo> popey, looks like they are affected by several issues
<JFo> the nomodeset indicates a potential kernel issue
<JFo> but the other issues are something else
<JFo> and what is a 'keyboard equals human' icon?
<cnd> who has the ability to set blueprint priorities?
<cnd> the drafter, the approver, or someone else?
<cnd> I'm the assignee for a bp, but I can't change it
<JFo> probably ogasawara or pgraner cnd
<JFo> more likely pgraner 
<cnd> JFo: this is actually a dx bp
<JFo> hmmm
<JFo> not sure then
<cnd> https://blueprints.launchpad.net/ubuntu/+spec/dx-m-multi-touch-and-kernel
<cnd> I'll just send a note to both the approver and the drafter then
<JFo> pgraner, should still have the authority
<JFo> k
<ogasawara> cnd: I might have the magic power, what fields do you want set and to whom?
<cnd> ogasawara: prio just needs to be set to something reasonable, maybe medium?
<ogasawara> cnd: ack, done
<cnd> ogasawara: thanks!
<cnd> ogasawara: can you set https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-tracing-support to low?
<ogasawara> cnd: done
<cnd> awesome
<ogasawara> cnd: it's odd that you as the assignee can't change those fields
<ogasawara> seems like a flaw
<cnd> ogasawara: odd that I myself can't for some reason, or odd that launchpad doesn't let assignees in general do it?
<ogasawara> cnd: that launchpad in general doesn't allow assignees to change it
<cnd> yeah...
<apw> its also odd that ogasawara can do it to some degree
<ogasawara> apw: agreed, not sure what special privilege I picked up along the way 
<ogasawara> apw: as you should also have the same, if not more than I
<apw> ogasawara, and i cirtainly don't
<JanC> JFo: the "keyboard equals human" icon is a somewhat undecipherable image the live CDs shows to tell users that they need to press a key to get to the bootloader menu where they can change boot options, etc.  ;)
<kees> tgardner: I'm not sure I understand what you mean.  which group?  (I've never set up dchroot...)
<tgardner> kees, ok, never mind then.
<kees> tgardner: heh okay.  :)
<kees> tgardner: I just use mk-sbuild to create all my schroot chroots.  generally really fast if you have a local or cached mirror.
<tgardner> kees, ok, I'll look into that
<apw> tgardner, did you have a recipie for the armel chroot magic using qemu ?
<tgardner> apw, yeah, I got that working, but I'm also messing around with the dchroot to schroot migration
<tgardner> whilst these damn LTS backport builds are running.  there are no shortcuts when you're mucking with control files
<kees> apw: https://wiki.ubuntu.com/ARM/RootfsFromScratch  <- has some notes
<kees> apw: but the easiest by far is just "mk-sbuild --arch armel maverick" etc
<apw> kees, were does mk-sbuild live
<tgardner> ubuntu-dev-tools
<ccheney> when updating the kernel and the abi bumps say in a security release, we also need the meta packages updated, right?
<ccheney> ogasawara, ping
<ogasawara> ccheney: yep, when a security update bumps the abi, the linux-meta package will also get an abi bump
<ccheney> ogasawara, ok
<wyatt> hi
#ubuntu-kernel 2010-05-21
 * lag waves
<cking> lag, morning!
<lag> cking, Hi ya!
<lag> You're up early
<cking> lag, you up early too!
<lag> cking: I'm always up at this time. I like to start early - finish early
<lag> Although I haven't been very good at finishing :s
<cking> lag, me neither
<lag> cking: I'll have to change that soon - I don't want to burn myself out
<cking> lag, indeed
 * abogani waves
<cking> hi abogani
<lag> cking: How's your scripting?
<abogani> cking: Good morning!
<cking> lag, scripting? please elaborate?
<lag> What does "cat <<EOD" mean/do?
<cking> lag, it will write out the text upto but not including the EOD marker
<lag> Oh, excellent!
<lag> :)
<lag> Can EOD be anything? Or is it defined?
<cking> technically called "here strings", can be any terminal word, man bash, look for "Here Strings"
<cking-afk> back in 10
 * abogani is wondering if exist a way to temporarily turn off Ubuntu kernel bugs email notifications...
<abogani> Sorry for my English: it is usually horrible but today I'm moreover particularly sleepy...
<cking> abogani, no idea - it would be good to stop the incoming deluge!
<abogani> cking: Perhaps Leann could know that.
<abogani> ogasawara: ^
<abogani> cking: It is very easy to have a full mailbox it you left your pc for a couple of days...
<cking> abogani, too right
 * abogani is wondering why embedded youtube video don't work anymore...
 * apw ywans
<cking> morning apw
 * lag waves at apw
<apw> morning all
<abogani> apw: morning
<abogani> I would want rename two kernels. -preempt to -lowlatency and -rt to -realtime. Why? Because -preempt and -rt sound really geek names. Those are totally meaningless for "human beings" :-) So -lowlatency and -realtime are better self-explained words. That sounds reasonable to you?
<apw> i guess i have no real objection to those new names, though i suspect anyone who has any understanding that there are multiple kerenls and indeed that you have a choice and why you might want to make such as choise, is going to be unfazed by the current names
<cking> more explicit the naming the better in my opinion as long as it does not involve much more typing
<abogani> cking: Normal users use GUI so no matter how long the name is.
<cking> abogani, true
<abogani> I also think renaming is right because we have -server not -srv and -generic not -gen so I think than "align" name conventions.
<abogani> Moreover when someone speak about -preempt we'll know immediately than he are talking about the kernel which is in Lucid into main component. 
<apw> though any report without version numbers is useless and those would tell us, plus any apport reported bug should get filed against the correct source package name
<lag> Okay, I'm working on bug583128
<lag> I think I have fixed it
<lag> Who to I commit it with the commit messages in debian/commit-templates?
<lag> How*
<lag> do*
<lag> Blimey! Start as you mean to go on lag!
 * cking thinks lag needs more coffeee
 * lag thinks he needs to get off the water and start drinking coffee
<apw> lag, what sort of fix is it
<jk-> i believe that is in the New Starter document
<apw> jk-, what how much coffee to drink :)
<jk-> .. and apw will tell you how much beer to drink
<apw> good point
<jk-> we have quotas to meet
 * lag looks for the New Starter document 
<jk-> lag: oh, i meant about the coffee, no the commit details :)
<jk-> *not
<lag> Phew!
<jk-> I think the Packaging guide has those details?
 * jk- looks
<jk-> lag: https://wiki.ubuntu.com/PackagingGuide/Complete is a good reference in general
<apw> but basically the form is common pretty much, its the prefixes on the subject line which differ based on source of the fix
<lag> Woo, another Wiki - joy!
<lag> ;)
<apw> if its an upstream cherry pick we do it one way, if its a local only patch we do it another, there are about 5 categories
<jk-> lag: https://wiki.ubuntu.com/KernelTeam/KernelBugFixing#Commit%20the%20Patch
<lag> jk: That's the badger 
<lag> jk-: Thank you
<jk-> lag: no problem
<apw> BAH its out of date already
<jk-> it does mention the "hardy tree" :)
<apw> heh i think i might have written it given the s-o-b
<lag> apw: Does it need changing before I use it?
<apw> you should be using -F debian/commit-templates/sauce-patch ... if its that template
<apw> that has the up to date version of the contents, indeed as the page there tells you
<apw> i've updated the example to make it right
<apw> gah the wiki is as slow as hell, all those stooopid emails being synchronous
<persia> lag, apw: Would you guys like a quick outline of how to set up auto-emulating chroots?
<lag> persia: Can't hurt :)
<jk-> yes
<lag> persia: I'm currently hacking smb's remote-scripts to work
<persia> Do you already use mk-sbuild to set up the schroots you use to build?
<lag> persia: Nope
<lag> I use smb's scripts
<lag> To start the builds remotely
<lag> They're good
<persia> Right, but what's the source of your chroots?
<lag> Fire and forget
<persia> How do they get created in the first place?
<lag> They already exist on emerald 
<lag> dchroot -l
<lag> Available chroots: doko-lucid, doko-lucid32, hardy-amd64, hardy-i386, hardy-lpia, intrepid-amd64, intrepid-i386, intrepid-lpia, jaunty-amd64, jaunty-i386, karmic-amd64, karmic-i386, karmic-lpia, lucid-amd64 [default], lucid-i386, maverick-amd64, maverick-i386
<persia> You're still using dchroot!  That's been obsolete for years!
<persia> You so want to migrate to schroot.
 * persia has been using schroot since feisty with happy results
<apw> persia, i think i inadvertantly got a pointer to the 'arm emulation way' last night from kees
<apw> i used mk-sbuild --architecture=armel maverick
<apw> and then used sbuild *.dsc
<apw> and ... hours later i got a native-ish arm build ...
<apw> persia, about right ?
<persia> Yep, that's the way it works.
<apw> man it was slow, and made my build box scream in agony for the whole time
<persia> The hours later bit happens on native hardware too, except if you have a RAM intensive build (like the kernel), it's even more hours.
<apw> yeah was about 2 hours i would guess for a flavour, so about 3x quicker than a native one
<persia> Mostly a matter of RAM.  Stick 8G on a native box, and it would be that fast too.
<apw> yeah its not got quite that much unfortuantly, though it seemed to be CPU bound from the groaning from the fans
<persia> heh.  Emulation isn't cheap :)
<apw> no, but at least it did build so i could 'test' the userspace
<apw> persia, the resulting chroot, is that setup to be arm-like should you just schroot into it?
<persia> You can, if you like.
<apw> apw      16963 16904  0 10:44 pts/2    00:00:00 /usr/bin/qemu-arm-static /bin/bash
<apw> apw      16980 16963  0 10:45 pts/2    00:00:00 /usr/bin/qemu-arm-static /bin/ps -ef
<apw> euuuwwwww :)
<persia> The way it works is through a binfmt-misc hook, that then uses the static qemu as an interpreter for any foreign binaries.
<persia> You don't like that?  Do yo have a better suggestion?
<lifeless> hardware!
<lifeless> get an ia-64 personality for arm into the next rev of the chips
<apw> persia, no i think its an amazing abuse of the world order to make it work
<persia> lifeless: Um, there's not enough bits (although I'm hoping to get qemu working on/for ia64 this cycle)
<lifeless> not enough bits ?
<lifeless> for cpu personality ? I'd need to review the spec
<persia> But, yeah, hardware is always better (although I often find local schroots more convenient than remote schroots on real hardware, for some reason)
<lifeless> I'm sure they had room for expansion earmarked
<persia> lifeless: armel is 32-bit: can it handle a 64-bit personality?
<lifeless> eys
<persia> Interesting...
<lifeless> http://en.wikipedia.org/wiki/Itanium#Architectural_changes
<lifeless> as originally conceived it ran ia-64, ia-32 and (IIRC) sparc
<lifeless> I may be misremembering the third instruction set
<persia> Indeed, but that went away.  As far as I understand, Ubuntu doesn't even run well on that generation (without customimsed kernels)
<lifeless> nothing does ;P
<persia> No, some stuff does.  stgraber has a couple of them running Ubuntu, and then using LXC to run x86 stuff.  It just requires some extra effort.
<lifeless> 'well'
<lifeless> the key word
<lag> apw, persia: So what conclusion did we come to? Am I sticking with the scripts?
<persia> But I *don't* think there's any way to get armel hardware to run ia64 code without using an emulation layer, and I don't expect that to be working cleanly until maverick+1 (and not even then unless someone decides to do the integration work after qemu-static-ia64 works properly)
<apw> for me i am continuing as i am, but i am adding this new armel thingy to my arsenal
<persia> lag: There wasn't a conclusion.  We briefly discussed how foreign schroot works.  Making this work with your scripts means minimally migrating from the long-deprecated dchroot (which is implemented as a compatibility layer in schroot these days), and then setting up a schroot.
<apw> its far to slow for test builds, but for when you need to know if linux-tools will build its invaluable
<apw> and tgarder was looking at the migration i think himself
<lag> I think I'm mainly interested in test builds?
<persia> Probably.  It's near native-speed on test builds, but that's still slow.
<persia> That said, it actually exercises the toolchain, whereas some cross-build doesn't provide any assurance that something will actually build with the native toolchain.
<persia> (although it's usually 95+% similar)
<apw> persia, right, there is always a risk of differences tehre
<apw> it is definatly the righter way forward compared to native cross compilers
<persia> Well, I'd be less against cross-compilers if we were building clean cross-toolchains from the same sources in the archive.
<persia> My big objection is about using some random cross-toolchain (even if well-respected) and expecting it to magically work.
<persia> That said, I agree with lifeless that the real solution is hardware.
<persia> (for all that I'm often too lazy to dispatch a remote build, and end up doing it locally in emulation)
<lag> apw: If a local repo is on branch x and a remote one is on branch y and a 'git push' is actioned, what happens?
<apw> you are only changing where the branch points to, not what the working directory contains
<apw> ie the remote x changes to be the same as the local one, but Y and the checkout of Y in the working directory are unaffected
<apw> indeed if remote is on X and you allow overwriting, then X on remote will change, but the checkout will not
<apw> you need to reset it to get the working directory in sync
<lag> But in my case the remote hasn't even checked out x yet - so what happened in the push? Nothing?
<lag> apw: ?
<apw> no the remote branch now is the new version
<lag> doh
<lag> :)
<apw> that is it is not the checked out one is unrelated
<lag> apw: Playing with git again
<lag> I've checked out master on both local and remote repos
<lag> Then did a "git push --dry-run <servername>"
<lag> And received this:    f0819aa..eb33bb9  lp583128 -> lp583128
<lag> Neither repos are on branch lp583128?
<apw> well you asked ti to push _all_ branches right
<lag> Then why doesn't it attempt to push master or ti-omap?
<apw> are they arready the same ?
<apw> it may be only telling you about the changes it would make, not the checks it checked
<lag> Ah, because it is the only with commits?
<apw> because the local and remote are identicle perhaps ?
<apw> you could test by commiting something to one of the others
<apw> and see if it then appears
<lag> k
<Amarendra> can any body tell me how to install usb modem in ubuntu?
<Amarendra> is anybody there in this room??
<popey> yes, but this probably isnt the right place for your question Amarendra 
<Amarendra> where should i go?
<popey> #ubuntu probably
<cking-afk> food
<apw> lag, target-scripts/run-clean:               git checkout -f "${BRANCH}"
<lag> apw: ack
<tgardner> apw, is mumble up? I keep getting rejected.
<apw> tgardner, yes we are on it
<apw> check it remembered your new username
<tgardner> apw, it did, but I'm not sure it saved the certificate. I'll keep messing with it
<apw> tgardner, i think it asks me for my password every time
 * apw tries
<apw> hrm, not its remembered something somwhere
<cking-afk> fail
<apw> cking, fail ?
<cking> apw, mumble passwd recall
<apw> yeah need to find its brain and move it into Private
<apw> cking, ahh it has a certificate recorded it is using in the stead of password
<apw> tgardner, it seems to record everything in .config/Mumble, so if you get desperate removing that may help
<tgardner> apw, gosh, thats so handy having to delete that file every time.
<apw> not had to do that yet myself, but if it helps :/
<vanhoof> pgraner: tgardner: ping
<vanhoof> can either of you set ~ayan up in c-k-t and u-k lp groups?
<tgardner> vanhoof, can do. gimme a bit
<vanhoof> tgardner: thanks, just helping him get setup :)
<tgardner> vanhoof, whats his LP ID? There are a bunch of ayan's
<vanhoof> tgardner: https://edge.launchpad.net/~ayan
<TeTeT> tgardner: Hi Tim, I've queried you on 5 May on a module for 3g connection on x201, can this be included in a Lucid kernel?
<tgardner> TeTeT, that was on the k-t list, right?
<TeTeT> tgardner: nope, private email
<TeTeT> tgardner: subject: Lenovo x201 WWAN module in Lucid kernel
<tgardner> TeTeT, send it on the list please.
<TeTeT> tgardner: list address is?
<tgardner> TeTeT, my private  email SPAM muncher likely ate it
<tgardner> kernel-team@lists.ubuntu.com
<TeTeT> tgardner: it's customer related, I'm not sending it to a public list, sorry
<tgardner> TeTeT, then I'm not adding it to a public
<tgardner> public kernel
<TeTeT> tgardner: fair enough, thanks
<tgardner> you don't have to explain for whom the request is submitted
<TeTeT> tgardner: ok, I've anonymized the email, that shall do
<tgardner> TeTeT, ok, we'll take a look
<cnd> ogasawara: how do you want to handle stuff as we move to maverick where the lucid patch isn't what ended up upstream:
<cnd> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commitdiff;h=0d843425672f4d2dc99b9004409aae503ef4d39f;hp=ee60ece93253a9c202e31672e37c513e9ff2d917
<cnd> vs
<cnd> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=74f5187ac873042f502227701ed1727e7c5fbfa9;hp=09a40af5240de02d848247ab82440ad75b31ab11
<cnd> the upstream will hit in .35
<cnd> so do you want to just handle it when it hits, or should I send a revert for it now?
<ogasawara> cnd: I'll try and remember to drop it when I rebase to .35
<cnd> actually, it's already landed in upstream, so you'll hit it as soon as you do your next merge
<cnd> ogasawara: ok, I'll let you handle it all then, and that's the end of my patch upstreaming work :)
<ogasawara> cnd: sweet
<ogasawara> cnd: just so I don't forget, maybe I'll just revert it now and cherry-pick the upstream patch
<cnd> there are other changes to upstream sched.c though, so you may hit conflicts if you pick it now
<cnd> but if you plan to pull in upstream before the next drop anyways, you can just revert it now and everything should be fine
<cnd> pull in upstream before the next maverick release that is
<ogasawara> cnd: just depends when -rc1 drops
<shawncm217> I've Googled and looked all over the Ubuntu website. What is the RAM limitation for 64-bit desktop Ubuntu 10.04?
<tgardner> shawncm217, there is no practical limit
<cnd> shawncm217: should be beyond the limits of hw
<cnd> technically, amd64 has 48 bits of memory addression I think, so 2^48 bits :)
<cnd> oops, bytes :)
<TeTeT> tgardner: thanks for the swift answer
<tgardner> TeTeT, np
<jjohansen> cnd: yeah but that is just a current implementation limit to the virtual address space, the spec allows for an implementation to do 64 bits of virtual address space
<cnd> jjohansen: ahhh, didn't know that
<vanhoof> apw: sconklin: tgardner: if you guys have a chance, any thoughts on my email to you all would be appreciated
<shawncm217> Thanks for your help.
<vanhoof> I'm going to start putting something more official tog this weekend
<sconklin> vanhoof: you mean the "SRU policy wrt . . . "?
<vanhoof> sconklin: sugar bay email from last evening
<sconklin> vanhoof: ok, see - I'm already ignoring HWE type email :). I'll have a look
<vanhoof> sconklin: lol!
<vanhoof> sconklin: i was nominated for this one, not by choice ;)
<tgardner> vanhoof, thats 'cause you're the new guy and don't know what you're getting into.
<sconklin> vanhoof: as it turns out, I do have some opinions about this :) I'll compose a response
<jjohansen> hehe: http://www.google.com/
<jjohansen> and its playable
 * cnd just beat lvl 1
<cnd> ogasawara: JFo-swap: ogasawara is still the bug overlord for the "linux" package (not the "linux (ubuntu)" package)
<cnd> I assume that probable should be swapped as well?
<JFo-swap> more than likely
<vanhoof> sconklin: i assumed you would :)
<ogasawara> cnd, JFo: hrm, I'm not even sure how to swap myself out :)
<kamal> jjohansen: wow, that's awesome
<jjohansen> :)
<JFo-swap> ogasawara, I've no clue how linux(
<JFo-swap> Ubuntu) was changed
<ogasawara> JFo-swap: yah, I'm a bit confused too as both packages show the Ubuntu Kernel Team as being the maintainer
<JFo-swap> hmmm, that also begs the question, Does it really have to be just me.
<JFo-swap> or is it ok that it is the team
<JFo-swap> I am not sure what the benefit of being the sole bug supervisor would be
<ogasawara> JFo-swap: you're name is listed as being notified in some stock reply
<JFo-swap> hmmm
<ogasawara> JFo-swap: but if you want to subscribe to the bugmail https://edge.launchpad.net/linux/+subscribe
<JFo-swap> I think I already am
<JFo-swap> oh, that is the capital L one
<JFo-swap> yeah
 * ogasawara back in 30min
<eagles0513875> hey guys can any one let me know the status of this bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/578210 
<ubot2> Launchpad bug 578210 in ubiquity (Ubuntu) "ubiquity fails to install kubuntu on lucid 64bit (affects: 1) (heat: 6)" [Undecided,New]
<eagles0513875> ikonia:  helped me determine that the bug is due to the gpt not being compiled into the desktop kernels. i can confirm that using ubuntu server kernel fixes the issue that i was having trying to get lucid installed on a 2tb hard drive
<tgardner> eagles0513875, what is a gpt?
<tgardner> ginormous partition table?
<eagles0513875> tgardner: no gpt = guid partition table
<tgardner> eagles0513875, what is the config option?
<eagles0513875> tgardner: what do you men
<eagles0513875> mean
<tgardner> 'the bug is due to the gpt not being compiled into the desktop kernels'. That requires a config option.
<shadeslayer> eagles0513875: he means if there are any compile time arguments to be passed while compiling
<eagles0513875> shadeslayer: tgardner from what i have seen its a module that needs to be compiled with it
<shadeslayer>  /whois tgardner 
<shadeslayer> whopps :P
 * shadeslayer thinks tgardner is probably doing the same thing back right now :P
<tgardner> eagles0513875, there are no differences between the desktop and server kernel configs that would affect partition tables or sizes.
<eagles0513875> tgardner: thing is only recently large hard drives over 1tb are becoming more main stream in desktops
<eagles0513875> its compiled into the server kernel as server have had drivers over 1tb long before desktop use
<eagles0513875> the desktop doesnt have it compiled into it
<eagles0513875> and with out it i was running into some super nasty issues 
<tgardner> eagles0513875, 'it' being specifically what?
<eagles0513875> gpt
<tgardner> apw, do you know what gpt is 'cause I'm not finding it ?
<eagles0513875> tgardner: look up guid partition table = gpt
<cnd> tgardner: apw: what are we doing about arm branches in maverick?
<cnd> will there be any?
<tgardner> cnd, not yet
<apw> there will be omap in a branch probabally
<tgardner> only omap3 in master
<eagles0513875> tgardner: http://en.wikipedia.org/wiki/GUID_Partition_Table
<apw> eagles0513875, is that uefi related ?
<tgardner> perhaps omap4
<cnd> tgardner: apw: ok, I will want to check their ftrace config, but I suppose that will have to wait
<eagles0513875> apw: i dunno but it already exists in the kernel
<mjg59> efi requires gpt, but gpt doesn't inherently require efi
<cnd> I've found an issue with the mvl-dove config right now
<cnd> and it prevents ureadahead from working
<eagles0513875> apw: thing is its not compiled into the desktop versions of the kernel
<apw> whats the confiuration option for that
<eagles0513875> apw: i dunno take a look at ubuntu server kernel 
<eagles0513875> as its already in there 
<apw> or i could wait for you to tell me
<eagles0513875> apw: im not a kernel expert never really messed with the kernel
<eagles0513875> apw: the bug is 578210 and i have the backing of ikonia to get an updated kernel for lucid that has it in it as well as included for future releases
<mjg59> CONFIG_EFI_PARTITION
<eagles0513875> ?
<apw> mjg59, man they didn't try to make it easy did they
<tgardner> debian.master/config/config.common.ubuntu:CONFIG_EFI_PARTITION=y
<apw> eagles0513875, that config option is the same in gneric and server
<eagles0513875> apw: without gpt compiled into the generic kernel i was getting shared object errors with ubiquity
<eagles0513875> using ubuntu server i didnt have that issue what so ever
<apw> CONFIGS/amd64-config.flavour.generic:CONFIG_EFI_PARTITION=y
<eagles0513875> gpt seems to be listed under partition types on the 
<apw> CONFIGS/i386-config.flavour.generic:CONFIG_EFI_PARTITION=y
 * eagles0513875 goes to download kernel source code
<apw> well its truned on and compiled in on both of them
<apw> so i suspect its not that that is triggering its lack for you
<apw> perhaps its a CD generation related thing
<eagles0513875> well i have ikonias backing on this as he is saying its not compiled into the kernel as well if you look at the bug i filed
<apw> bug 578210
<ubot2> Launchpad bug 578210 in ubiquity (Ubuntu) "ubiquity fails to install kubuntu on lucid 64bit (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/578210
<mjg59> eagles0513875: The errors you're reporting have nothing to do with gpt
<eagles0513875> mig read down though
<eagles0513875> ikonia:  posted something and his recommendation
<mjg59> eagles0513875: The errors you're reporting have nothing to do with gpt
<vanhoof> May 10 10:46:34 ubuntu ubiquity: WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
<vanhoof> would the server installer use parted by default?
<eagles0513875> vanhoof: it must have cuz thats what i used to install no problem
<eagles0513875> then proceeded to install kubuntu-desktop
<apw> well from the kernel point of view both kernels you site have the same configuration options for GPT
<mjg59> sda has a gpt partition table
<mjg59> So the fact that you have sda2 means that the kernel supports gpt
<mjg59> Otherwise the kernel wouldn't have found the partitions
<eagles0513875> mjg59: ok so the problem lies with the installer not using the right program
<eagles0513875> mjg59: feel free to make comments on the bug
<apw> I've pasted in the configuration options too
<mjg59> eagles0513875: You got an input/output error when ubiquity was trying to read the CD
<mjg59> eagles0513875: Your CD is bad
<eagles0513875> mjg59: i was using a live usb 
<eagles0513875> used cd as well
<eagles0513875> when i used the ubuntu server cd i didnt have tha tissue
<mjg59> It's also nothing to do with the installer using the wrong program
<mjg59> partman supports gpt fine
<eagles0513875> mjg59: what doesnt make sense is why even after check summing and making sure the cd was fine which it was 
<eagles0513875> of kubuntu then why on earth didnt i have the same issues with an ubuntu server cd
<mjg59> There may be some other kernel issue that causes corrupted reads
<mjg59> But I can't see any way for it to be related to gpt
<eagles0513875> mjg59: what my digging dug up originally was that it wasnt compiled into the kernel 
<mjg59> eagles0513875: It is compiled into the kernel
<eagles0513875> ok 
<eagles0513875> ill talk to apachelogger in offtopic about it 
<eagles0513875> thanks guys
<jjohansen> heading into portland back on in a bit
<kees> tgardner: thanks for the acks.  heheh "I ... can find no obvious signs of carnage."  :)
<kees> tgardner: any verdict on the ptrace stuff?  it will cause a few surprises for developers, so I want to "announce" it a bit more widely when it does finally land in maverick.
<tgardner> kees, well, I never really saw any compromise between you and Scott so I was waiting on that a bit. you seem to be at loggerheads.
<kees> no, no, it's simple, he's wrong.  ;)
<tgardner> ok :)
<kees> like I said in the thread, I acknowledge there will be some pain, but I think the safety of the distro as a whole will improve in the general case.
<tgardner> kees, I'm still catching up a bit from UDS. gimme a few days to tinker with it.
<kees> tgardner: sure thing, no rush
<bladernr> This might be a stupid question, but... is there some way I can, programmatically (in python or shell) set power-management policies without relying on window-manager focused tools?  I was just wondering how to go about setting things like "Sleep after 20 minutes on battery" without needing tools like PowerDevil or GConf
 * bladernr is trying to write a test tool that can set idle timeouts on Xubuntu, Ubuntu and Kubuntu without having to rely on tools that are specific to each one individually
<kees> bladernr: power management policy is implemented in gnome-power-manager, so gconf is the way to tweak it. the are commandline tools to manipulate gconf
<bladernr> kees:  but gnome-power-manager doesn't work in Kubuntu :( at least not without installing it (and potentially other GNOME specific things)
<kees> yup :(
<bladernr> I guess I was just hoping there was something central in /sys or /proc that gnome-power-manager and KDEs version both touch in the kernel to set these things
<kees> it sue seems like something freedesktop should standardize
<kees> *sure
<bladernr> Honestly, I'm really surprised that it isn't... I was sure that this was going to be a trivial test case to write... now not so much :(
<kees> ultimately something needs to determine what "idle" means, and that's what not common to each windowing system
<bladernr> kees:  yeah... good point.  
<jjohansen> ogasawara: can you change priority on a couple blue prints for me
<ogasawara> jjohansen: sure, which ones
<jjohansen> ogasawara: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
<jjohansen> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
<ogasawara> jjohansen: what priority do you want me to set for em?
<jjohansen> ogasawara: I not sure, medium or high for a couple of the items best the rest are low
<jjohansen> can we reset the priority after alpha-1
<ogasawara> jjohansen: sure, I'll just set to medium for now
<jjohansen> ogasawara: thanks
#ubuntu-kernel 2010-05-22
<Laibsch> I think we're lacking a wiki page or something like it to explain the meaning of tags such as regression-potential, regression-release, etc.
<Laibsch> Is there a tag that denotes a regression from mainline?
<dhillon-v10> Laibsch: I am pretty sure there's a page that explains those topics, I remember reading aobut them somewhere but don't exactly know where :)
<kamal> Laibsch: https://wiki.ubuntu.com/QATeam/RegressionTracking
<Laibsch> I see, thanks
<Laibsch> I search for that page with the keyword "regression-potential" but it didn't show up
<Laibsch> I hope my comments got through, I'm currently in and out of tunnels
<dhillon-v10> kamal: thanks :)
<xelister> hi guys
<xelister> the swapoff performance is bad,  swap gets freed with speeds like 5 MB/s instead expected 50+  why so?
<xelister> i.e. when you do  swapoff /somedev then it takes really long to execute, slowly freeing swap (seen in swapon -s)
#ubuntu-kernel 2010-05-23
<MTecknology> Is there any way to easily make a kernel in a PPA? only one version of the kernel, only one .config?
#ubuntu-kernel 2011-05-16
<jk-> hey
<ppisati> morning
 * ppisati upgrades to Natty
 * apw yawns ... sooo very tired
 * jk- waves
<apw> moin jk- back ok ?
<jk-> heya apw. yeah, all went well.
<jk-> just need to not be sleeping on the keyboard
 * smb drags himself in
<ppisati> doh! mumble recalibration...
<smb> ppisati, At least I heard you
 * apw has to rebuild his office, bah
<smb> apw, Was it "cleaned up"?
<apw> yep, nice and shiney
<smb> ...and nothing to be found anymore. :-P
<ppisati> you lucky, i should clean mine :)
<apw> not a thing, including my headphones
<smb> ppisati, If you do it yourself you tend to know where tings are after the process. On the other hand... ;)
<apw> ... once everything is gone you don't have to worry
<Luca> Hi! I'm trying to figure out why my system, which has an ATI with opensource drivers installed, cannot boot the kernel 2.6.38 without having to set the nomodeset parameter. The same happens when I try to use USB pendrive with fresh installation of 10.04. Is there anyone who knows anything about this issue?
<ppisati> smb: actually i developed an efficient loosing stuff algorithm, so even if i tidy by myself, i tend to loose stuff :)
<tjaalton> yawwn^2
<tjaalton> Luca: what happens without nomodeset, black screen?
<Luca> On my notebook with kernel 2.6.38 I have a screen screwed up (I see some violet on the screen) and the boot stops there, shortly after grub. With a USB pendrive black screen (the USB pendrive is working with 10.10).
<tjaalton> is it 32 or 64bit?
<tjaalton> installation
<Luca> 32bit
<Luca> On the same system, the old kernel 2.6.35 is working ok.
<tjaalton> you could try a mainline build: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-rc7-oneiric/
<tjaalton> install linux-image-2.6.39...deb and boot it without nomodeset
<Luca> ok, I'll try this
<Luca> thanks
<tjaalton> Luca: btw, is there a bugreport about this?
<Luca> I've been trying to find something already filed and I found many things similar, but I don't know if those are the same or not. I don't even know whether this is related to the kernel or to the graphics drivers. I'm experiencing other issues as well with the new 11.04.
<tjaalton> best to file a new bug
<Luca> Sorry, I've never installed a kernel without apt-get. Is there anyway a guide on what I should do to boot the kernel installed from .deb?
<_ruben> installing a kernel via apt-get or dpkg doesn't make a difference really
<apw> tjaalton, another radeon modeset regression ... sigh
<tjaalton> apw: this one? looks like it yeah
<tjaalton> could be the grub handoff code messing it too?
<tjaalton> Luca: dpkg -i linux-image..deb
<apw> tjaalton, good point ...
<tjaalton> hmm, /etc/default/grub should really have the GRUB_GFXPAYLOAD_LINUX= commented out, I keep forgetting what the option is called :)
<tjaalton> Luca: so you could try adding 'GRUB_GFXPAYLOAD_LINUX=text' to /etc/default/grub, run 'update-grub' and boot the default natty kernel without nomodeset option
<Luca> thanks, I'll try this as well. Sorry, I'm quite slow cause I'm at work as well :-)
<tjaalton> you can do work later ;)
<Luca> :-) Can I add that line wherever? Or is the order important?
<apw> Luca, it should already be there commented out
<tjaalton> it should? ok, maybe my version is old then
<Luca> In /etc/default/grub? I don't have it there...
<tjaalton> Luca: would be nice to know if the .39-rc kernel worked out-of-the-box
<tjaalton> if not, then try adding the grub option
<Luca> Ok, I'm trying that as well.
<Luca> I'm removing that line.
<tjaalton> nomodeset I hope?
<Luca> I mean GRUB_GFXPAYLOAD_LINUX=text
<tjaalton> ah you added it already, k
<Luca> Ok, see you soon, rebooting now.
<Luca> seems very good now!
<Luca> uname -r confirms I'm running the 2.6.39...
<tjaalton> oh good
<tjaalton> and without nomodeset?
<Luca> I assume yes. I don't see the parameter set in grub.cfg.
<tjaalton> cat /proc/cmdline would confirm that
<Luca> And I'm running Unity, which I saw it wasn't possible with nomodeset.
<tjaalton> alright
<Luca> BOOT_IMAGE=/boot/vmlinuz-2.6.39-020639rc7-generic root=UUID=4635bd6c-8c24-4f5f-b2f6-02c1bd5d5ec8 ro quiet splash vt.handoff=7
<Luca> seems ok!
<tjaalton> yep
<Luca> Thanks for your help!
<tjaalton> not so fast :)
<Luca> yes
<tjaalton> i'd like to have the kern.log or dmesg output from when you boot the stock natty kernel
<Luca> so, I have to reboot with 2.6.38 and send you that right?
<tjaalton> yes
<Luca> no problem
<tjaalton> do the VTs work?
<Luca> should I remove the current ones I have?
<Luca> sorry, what's VT
<Luca> ?
<tjaalton> or can you log in remotely (ssh)
<tjaalton> virtual terminal (ctrl-alt-F[1-6])
<Luca> Sorry, not following you... :-) Yes, those are working.
<Luca> Oh, OK, now I get it.
<tjaalton> but they probably don't work with the broken kernel
<Luca> If I boot with 2.6.38 VTs are not working and I already tried ssh as well.
<Luca> is kern.log removed in the following reboot?
<tjaalton> ssh isn't working either, and you have openssh-server installed?
<Luca> I have a ssh server yes.
<tjaalton> no, /var/log/kern.log is rotated, so it could be renamed but not removed
<tjaalton> and ssh doesn't work while it's in the "state"
<tjaalton> ?
<Luca> I remember I tried once but I couldn't connect.
<tjaalton> ok, maybe it crashed hard then
<tjaalton> anyway, boot that kernel, try ssh and if it doesn't work, boot the good kernel and find the /var/log/kern.log.* that has the information from the bad kernel..
<Luca> ok, no problem.
<tjaalton> then file a bug by running 'ubuntu-bug xserver-xorg-video-ati' and attach the logfile after you've filed it
<Luca> very good
<tjaalton> even though it's a kernel bug this will gather more information of the machine
<tjaalton> i think..
<Luca> anyway, I was having some other troubles I've never had with graphics drivers. I don't know if those were related. I'll test this new kernel and see if those are still there.
<tjaalton> ok
<Luca> I'll file the bug as soon as I get home. Thanks for the help!
<tjaalton> ok, good
<Luca> oh, and I asked for help on askubuntu as well for this issue, no answers. Can I report there I solved with this new kernel?
<tjaalton> sure
<Luca> very well! Thanks again!
<ricotz> hi, is someone having problems using intel 4965agn wlan-adapter with 2.6.39? 
<apw> i've not heard any specifici reports no, but not many would be running that
<ricotz> it seems to recognize everything, but while trying to connect it timesout
<ricotz> it is working on 2.6.38, it is seems to be related to the driver split in iwl-legacy and iwl-*
<smb> Hm, someone had intel wireless on UDS and similar issues, but I cannot say exactly which model and which exact kernel
<smb> But I believe it was Natty, so it would be .38...
<smb> dmesg would show some authentication going on the then something with disconnect reason 6... 
<ricotz> smb, it could be the hardware connection can be established, and maybe the wpa_suppliciant fails
<smb> Yeah, in that case it was on a conference. So a lot of (wireless)-noise going on. Which could be hinting to the callibration there...
<ricotz> http://paste.debian.net/117092/
<ricotz> hmm, could be the same here
<ricotz> so *.39 changed some condition which breaks it totally
<smb> While the symptoms sounds similar I am pretty sure the other case was .38 and the message looked different to yours. 
<ricotz> this is with network-manager 0.9rc, but it was same with 0.8.4
<apw> ricotz, if we know it works in .38 and not 39-rc might be worth checking the mainline builds between to see where it broke
<smb> Roughly the problem looks like to be the kernel driver 
<ricotz> apw, i build
<ricotz> oop
<ricotz> s
<apw> you could try the ones in the mainline archive
<ricotz> apw, i built the kernel regulary since rc4 and the problem was there already
<ricotz> apw, i checked the build from yesterday
<ppisati> ok so, about oneiric/ti-omap4
<ppisati> i'm going to pull the same tree that we have in natty
<ppisati> just as a placeholder
<apw> ppisati, i am unsure if it matters or not to have that until we upload (here i am assuming you mean to push into the ubuntu-oneiric repo)
 * apw finally realises why git seems so slow in the morning ... relatime
<ppisati> yeah, i mean push
<ppisati> but i didn't get your comment
<apw> pretty much the first commit i do reads every time, and triggers a write to the inode for every single one
<apw> ppisati, i was just saying as the tree is identcle to that in natty, there is no advantage to having it in the oneiric repo, till it changes
<ppisati> ah ok
<apw> thats not to say that you can't do it, just its not obvious to me what we gain by your effort there
<apw> any idea when we might get some updated bits?
<apw> (mumble if its sensitive info)
<ppisati> i'm trying to figure it out
<ppisati> have you ever tried to switch to text console while playing music?
<ppisati> i have audacious running and playing some stuff
<ppisati> ctrl+alt F<something>
<apw> ppisati, not sure it continues does it ?
<ppisati> and the music stops!
<ppisati> no!
<ppisati> and when i went back, once i got _all_ the audio (skype, audacious, etcetc) cracking
<apw> yay
<ppisati> a couple more switch and it got fixed
<apw> quality software for the masses
<ppisati> dunno if it's: audacious, pulseaudio, kernel, etcetc
<jk-> I think it's the audio stuff trying to be clever; does the same on my myth box
<jk-> (which doesn't use PA)
<jk-> what layer of the "audio stuff", I don't know
<diwic> ppisati, if you switch to a console, music should stop
<diwic> ppisati, at least IIRC. Because you're not currently logged into the system, you don't have access to the sound card.
<diwic> ppisati, as for the cracking thing, I've seen more than one bug report about "distorted sound with pulseaudio" so I think we have a natty regression here; I'll try to reproduce it later this week 
<ppisati> diwic: actually my session and all my stuff it's still there, so i'm logged
<diwic> ppisati, just as your screen stops showing your current X applications, your sound card stops playing your music. 
<ppisati> uhm
<ppisati> sounds a bit strange to me
<ppisati> is it the same with tty[0-9]?
<ppisati> whatever, anyway...
<diwic> ppisati, however if you log in as the same user, you got access to your sound card again and it starts playing :-)
<diwic> (just tried it)
<apw> diwic, i assume we know that banshee has no quit window button now
<apw> diwic, not that its your problem, just i am assuming you hear about this kind of thing
<diwic> apw, eh?
<tjaalton> it quits if you stop the playback first
<apw> i am fishing to know if you know it has been filed as a bug so i don't have to file a new one ...
<diwic> apw, Banshee has three buttons in the top corner here.
<apw> oh i am trying to get rid of the window without stopping the music
<diwic> apw, no I don't but I'm more into the layers below
<apw> as its then 'in my sound indicator'
<apw> yeah i'll hastle someone on desktop :)
<tjaalton> yes, the window-close button does get rid of the window here, and playback continues
<diwic> apw, aha, it has a quit button but it doesn't quit when you press it?
<apw> tjaalton, really ?  hrm
<tjaalton> apw: yeah, so it just stays there for you? weird..
<apw> tjaalton, oh no, it quits but the playback stops
<tjaalton> apw: ah :)
<tjaalton> maybe the indicator plugin is disabled?
<apw> and ^W has gone away
<apw> tjaalton, hmmm maybe
<tjaalton> it was buggy during natty
<apw> tjaalton, ahh i do see an -appindicator package which is not installed
<apw> upgrade fail again
<tjaalton> banshee-extension-soundmenu?
<tjaalton> that's what I have installed
<tjaalton> and -ubuntuonemuiscstore
<tjaalton> *music
<apw> there is also banshee-extension-appindicator i think
<apw> but am updating so have lost the ability to check
<apw> i have soundmenu installed though
<tjaalton> ah right, I actually meant the soundmenu extension :)
<tjaalton> but do you have it enabled?
<apw> bah no, it was disabled, upgrade FAIL
<apw> tjaalton, heh now ^Q doesn't work and ^W does!
<apw> thanks
<tjaalton> :P
 * ppisati food + new power supply for panda/beagle
 * apw reboots to get a new broken unity
 * smb tries whether a third cup of  coffee finally helps...
<apw> smb, not a hope
<apw> ogasawara, when you disable ubuntu/ drivers its simpler (collission later wise) to shove a # in the ubuntu/Makefile on the sourcel l
<apw> line, that way we don't have to rebuild the config later when it comes back
<apw> ogasawara, and i think i have a building aufs update ready ... just going to see if it works
<ogasawara> apw: ack
 * ogasawara back in 20
<apw> *giggle*
<smb> apw, Stop thinking too much about it. :-P
<apw> there is little in the way of thinking going on over here today
<smb> heh, well yeah. neither here
<tgardner> apw, smbwhat are you guys whining about ? its not like you had a 26 hour trip home.
<smb> tgardner, Nah, that _is_ the annoying part. No idea why
<apw> tgardner, i think you are allowed to whine _more_, but i feel entitled to some ammount of whining, after 10 days of mental abuse
<tgardner> apw, yeah, I did forget about summit.
<cking> all apw's work is mental
 * apw slaps cking
<cking> owch
<smb> The truth hurts... :-P
 * tgardner is sure glad to get back to 21" monitors. that 9" screen was killing me.
<smb> So true
<smb> Even with a 12"
<cking> a week on an Atom with 1GB of memory is a killer with evolution + firefox.
<tgardner> cking, yeah, slow as hell
<cking> funny that once upon a time a 66Mhz 486DX + 4MB seems powerful
<smb> cking, Though I think we did not run more than one program at once then...
<smb> Well actually we did
<ogasawara> apw: I'm thinking of taking a swap day on Friday, you ok holding down the fort as tgardner and I would both be away
<apw> sure thing, do we have a release-meeting, seems unlikely this early
<ogasawara> apw: no meeting that I know of
<apw> even easier :)
 * cking suspects we need all the CPU cycles for interpreted code, Python, javascript, java, ACPI AML, etc..
<smb> ...and the additional eye candy
<cking> and gwibber + mumble ;-)
 * cking kicks mumble
<apw> ogasawara, i've just pushed a couple of small updates to clean up the updater and document its use, perhaps you could review the text and see if it makes any sense what so ever.
<apw> ogasawara, see ubuntu/aufs/BOM.UPDATING
<apw> tgardner, i have cleaned up the aufs-updater to record the real SHA1 of the standalone tree, as well as the log one it used to hold
<apw> (so its less confusing when you find the BOM in the furture)
<tgardner> apw, ack
<ogasawara> apw: ack
<apw> tgardner, finally figured out why git is so damn slow for me, in the morning.  seems tis relatime ... seems it updates atime if its 24hours since it last did, so it happens every day first thing!
<tgardner> apw, huh, I've been having the same issue.
<tgardner> first thing takes forever.
<apw> yep, so its one of those pathalogical cases.  you don't use it for a while
<apw> say a weekend, then you do a git commit first thing in day
<tgardner> apw, any workaround ?
<apw> and it reads every file, and you wait a long ass time
<apw> from there you are syched
<apw> and its every morning first thing
<jk-> updatedb still pushing everything out of the page cache?
<apw> well now i know i will be doing a git-status before i make my morning tea
<apw> jk-, its not page cache, its the atime updates.  basically they are really expensive, one read makes one write, and alogged one at that
<apw> so we use relatime, which says if the atime > ctime we don't bother until its 24 hours old
<apw> but git is introducing pathological behaviour as it reads the whole tree
<apw> tgardner, you could go noatime on the partition, but mutt may not behave as you expect
<apw> on a server it would be just fine though
<tgardner> apw, hmm, since I'm not using mutt...
<apw> you can also increase the time via systl
<apw> now i know why its so violently slow in the morning, i can take mitigating action
<apw> a partition for my source code with atime off would have been good
<jk-> ah
<apw>         if ((long)(now.tv_sec - inode->i_atime.tv_sec) >= 24*60*60)
<apw> tgardner, no actually its not configurable ... anyhow there is the reason it sucks in the morning every morning
<mjg59> apw: Now just remember that until that went in it would have been violently slow *all the time*
<apw> mjg59, yep, its cirtainly better, just taken me a long time to work out why its always in the morning
<mjg59> You need an SSD
<mfilipe> hi! I want download the kernel-2.6.39 through "apt-get source". Is there any way in 11.04? 
<tgardner> mfilipe, 'apr-get source linux'
<tgardner> apt*
<smb> err .39?
<tgardner> smb, oneiric isopen
<mfilipe> tgardner, no, it will download .38
<smb> tgardner, Was just not sure whether you can get a .39 with apt-get from within natty
<mfilipe> I want .39 to apply this patch: https://bugs.freedesktop.org/attachment.cgi?id=46702
<tgardner> smb, indeed you cannot. Iassumed this command was being executed from with an oneiric chroot or installation
<tgardner> can't fr*&*%^%g type this mornign
<smb> Yeah, so either this, or to use the git repo directly would be the way to go
<smb> tgardner, Had similar issues in mine.
<tgardner> mfilipe, use 'dget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.39-2.7.dsc'
<smb> Somehow my fingers managed to find the keyboard shortcut for undo all the time
<mfilipe> I want the .config and source code of 2.6.39-generic-pae
<mfilipe> devscripts installs many things that I don't want :( 
<apw> th
<smb> aaargh?
<apw> yep
<lag> apw: When are the dates due to be released for UDS-P?
<apw> they may already be set, though i have no clue myself
<lag> apw: That's good news (as I'd like to bring Sophie over)
<lag> apw: Do you know where I might look?
<apw> i suspect i have seen dates mooted in email
<tgardner> lag, Oct 24 in Orlando
<lag> tgardner: Great, thanks :)
<lag> How about Plumbers? 
<lag> I thought it was after?
<lag> Conference: 7-9 September 2011 in Santa Rosa, CA, USA
 * lag is confused
<tgardner> lag, what is there to be confused about?
<lag> tgardner: For some reason I thought Plumbers was at the same time as last year
<tgardner> ogasawara, rebased for yama patches and pushed said crack to oneiric +master-next
<ogasawara> tgardner: cool, thanks
<tgardner> ogasawara, its still pushing.
 * ppisati -> gym
<apw> tgardner, you got a pointer to the previous MIR for LTS backports, it is proving hard to find it seems
<tgardner> apw, hmm, are you sure I wrote one? 
<apw> tgardner, yeah pretty sure you did actually, i have also found refrences to you saying you would file one
<tgardner> wouldn't the bug number be in the changelog ?
<tgardner> apw, MIRs are always associated with a bug IIRC
<apw> you'd think but the backports are generated from our main kernel, so it doesn't appear to be in there
<tgardner> apw, unwind it to the very first commit
<tgardner> I likely added it by hand.
<apw>   [ Tim Gardner ]
<apw>   * First upload according to https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS
<apw> seems to be what was in the first real upload
<tgardner> apw, I'm hunting for the MIR in wiki.ubuntu.com
<tgardner> apw, have you stumbled on this page yet? https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<mjampala_> guys need help on setting my KEXE on ppc Board
<mjampala_> not sure why and how to setup the crashkernel kernel boot param
<mjampala_> anyone care to explain please?
<apw> that parameter ensures there is a hole in memory to contains a second kernel to recover and record the first one on a crash
<apw> not required if you arn't using kexec for crash dumps
<mjampala_> I need to use for crash dumps so I need it
<apw> i seem to remember on my system that parameter got added automatically when i installed kexec
<mjampala_> how do find the hole
<mjampala_> integreated
<apw> one normally is made by the option
<mjampala_> sorry, interesting ...
<mjampala_> my box is an embedded solution 
<apw> tgardner, thansk seems i have a lot of bits there
<apw> though i am struggling to find either the MIR bug or checklist wiki page
<mjampala_> not sure if that will work for me
<tgardner> apw, I have not been able to find it, but I'm pretty sure I wrote one.
<tgardner> google is not my friend today
<smb> mjampala_, That is how it looks on a 64bit x86 (though not sure it helps ppc) crashkernel=384M-2G:64M,2G-:128M
<smb> Think it means for memory between 384 and 2G use a 64M hole and for 2G and more 128M
<apw> smb, yep thats my understanding
<mjampala_> smb, but who devices where that 64 or 128 gets allocated 
<mjampala_> which part of memory
<apw> tgardner, never mind, think this wiki will guide me thorugh
<mjampala_> can you check your /proc/meminfo and see if there is a crash kernel entry in it 
<smb> As I understand it the kernel decides it
<tgardner> apw, still, it would be handy to be able to clone the maverick MIR and just make some minor edits.
<smb> mjampala_, not really in meminfo but "Reserving 128MB of memory at 32MB for crashkernel (System RAM: 33280MB)"
<smb> in dmesg
<mjampala_> As per the docs, there should be some entry in meminfo in /proc/meminfo
<mjampala_> may be it is named with a different name
<mjampala_> smp,  crashkernel=384M-2G:64M,2G-:128M
<mjampala_> is that for you r grub menu
<smb> mjampala_, At least my meminfo has only sizes, not locations, so it would not help. Yes, that is from grub.cfg to be passed as kernel command line
<mjampala_> yeah, thats fine, does your meminfo have an entry for crashkernel which mentions the size 
<mjampala_> how does it look
<smb> mjampala_, Nothing in there saying crash or being something of only 128M
<mjampala_> hmm, thanks smb
<mjampala_> wonder how it not accounted
<mjampala_> I think the crashkernel memory that is allocated at boot time is not used for anything else. 
<smb> It could be accoounted, but it may be part of some other thing
<mjampala_> one of the start up scripts should just load the kernel and be ready if a crash occurs 
<mfilipe> git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git has the last source-code of natty linux-image? what is the version? 
 * tgardner --> lunch
 * apw wanders off to prepare for guests ... see ya tommorrow
<SpamapS> morning folks. Question about the -server kernels.. is there a page pointing out thd differences w/ -generic?
<smb> SpamapS, I am not aware of one, but in git debian.master/config/amd64/config.flavour.server is only the config options not the same as for other flavours
<jjohansen> SpamapS: not currently, it is largely the same, just a few config diffs
<jjohansen> I have a server, -generic config diff that I can throw into a page quickly
<jjohansen> give me 30 min and I'll have a basic wiki page up
<smb> jjohansen, or you just pastbin the server config
<smb> Its only a few kines too
<smb> lines even
<jjohansen> smb: true enough
 * smb stops interrupting and goes afk... 
<SpamapS> jjohansen: thank you!
<kees> tgardner: do you (or anyone else) have a Lenovo T400 in your stacks of laptops?
<tgardner> kees, not me. perhaps cert has one ?
<kees> tgardner: cool; I'll ask around. thanks!
<jjohansen> SpamapS: https://wiki.ubuntu.com/Kernel/FAQ/KernelFlavourDifferences
<eruditehermit> bjf, hey
<SpamapS> jjohansen: Perfect! Thanks! :) (but aren't we supposed to delete things? ;)
<jjohansen> SpamapS: yeah now I need to delete six pages :)
<SpamapS> FAIL
<SpamapS> One thing thats not mentioned, that might be good to mention, is that there is no longer difference in the HZ setting, and that all of the kernels are tickless (thats true right?)
<jjohansen> SpamapS: hrmm that is not true, /me will have to investigate.  They are indeed all tickless NoHZ when sleeping but not when running
<jjohansen> SpamapS: natty are all at 250 Hz
<jjohansen> that is why it doesn't show as a difference
<jjohansen> I'll add the info
<SpamapS> the -virtual is CONFIG_HZ_100=y and CONFIG_NO_HZ=y and CONFIG_HZ=100 ..
<SpamapS> in natty I mean
<SpamapS> but I have no idea how to interpret those
<jjohansen> SpamapS: no its stranger than that, 64bit kernels are 100Hz and 32bit are 250Hz
<jjohansen> I just checked them all
<jjohansen> SpamapS: NO_HZ=y means that the kernel is tickless when idle
<jjohansen> CONFIG_HZ_100=y means that the kernel has a tick of 100 Hz, but in this case only when not sleeping because of config NO_HZ
<jjohansen> ogasawara,apw: we will want to look at our HZ in the config review later in the week, it is odd that 64bit kernels are all 100 Hz and 32 bit are all 250Hz.  One would think -generic would be 250Hz and -server 100Hz
#ubuntu-kernel 2011-05-17
<eruditehermit> hey, does anyone know why amd64 versions are no longer being built in the kernel ppa?
<eruditehermit> hey
<eruditehermit> does anyone know why the ubuntu kernel ppa doesn't have amd64 builds for the newer kernels?
<BenC> ericm|ubuntu: could be a build failure
<BenC> eruditehermit: ^^
<eruditehermit> BenC, how do I check?
<BenC> The buildd reports for the latest package in the ppa
<apw> eruditehermit, which kernel specifically is missing the build
 * apw yawns loudly
<jk-> hey apw
<apw> jk- hey, hows it hangng
<jk-> sleepy
<jk-> you?
<apw> always sleepy ... UDS is a killer
<ohsix> hm what sort of pages exactly are these page allocation warnings about; i get them a lot when running perf while swapping
<apw> ohsix, nominally they are reported against a process which is consuming them
<ohsix> is it fatal to that process or is it just advisory
<ohsix> perf doesn't die or seem to malfunction; neither does any other thing thats warned about
<apw> most cases unless we see the oom killer stepping in you are fine, though they are telling you the kernel is struggling to get what people are asking for
<apw> it is probabal that perf is falling back to smaller available blocks in that case
<apw> and reducing efficiency of reporting to userspace or similar
<ohsix> hm i'll have to check how much overcommit there is next time it happens; i know there was swap space still available in all cases that i saw
<ohsix> i thought it was waiting for some sort of special pages but it's pretty agnostic with respect to what it is, happens to perf a lot though
<ohsix> ooh found one, http://paste.ubuntu.com/608856/
<apw> ohsix, perf is likely to put demands on real memory which cannot be paged
<apw> May 15 17:43:36 krang kernel: [491791.506159] perf_2.6.38-9: page allocation failure. order:4, mode:0xc0d0
<apw> so perf is asking for large allocations, 16 pages at a time and being denied
<ohsix> okie dokie, i'll look more closely at the report it generates next time it's not perf; thanks for the info
<ohsix> i have one other but its from the intel gpu dump tool running, might be similar situation to perf
<apw> yeah probabally needs a big buffer to get the state
<ohsix> http://paste.ubuntu.com/608862/ happened in quick succession as apport was trying to report a render error
<ohsix> i see some suggestions about tweaking min_free_kbytes, i thought with overcommit stuff could sleep until allocations succeeded? and stuff could be ejected to satisfy it
<apw> ohsix, yes at order 3 and below that occurs, above that there is no likelyhood of success of the eviction
<ohsix> whats the "hi: " on per-cpu? all my reports have 186 and so do the ones i can see on google; fixed size area right?
<apw> anyone wanting to allocate at that size is expected to handle failure gracefully
<ohsix> ahh
<ohsix> interesting
<apw> hi: is the high watermark on the per node page allocation caches
<apw> so when you free the 186 order 0 page on a cpu a batch will be given back to the global pool
<ohsix> so where it's expected to be seen it shouldn't be a problem, unless it is and the tool needs to be fixed to accomodate the error?
<apw> right, and you are seeing no symptoms other than the failures i think, perf keeps working so it must be moving to smaller buffers
<ohsix> i'll have to see why it raises the error; i don't know how an app would get a chunk of memory or vm without __NOWARN ono it
<ohsix> __GPF_NOWARN
<ohsix> ok night; thanks for the info
<apw> ohsix, yeah it is probabaly they should have that if they know they are coping
<apw> smb, are we expecting any work items on your other-kernel-o-server-requirements blueprint
<smb> apw, We could place them there though the discussion happened in the other session(s)
<smb> I have not yet checked what is visible where
<apw> seems reasonable to pull them onto that one, and you can own the delivery of them
<smb> So I probably should go over things you put into your blueprints
<apw> https://blueprints.launchpad.net/ubuntu/+spec/tr-oneiric-kernel-team
<apw> smb, the above blueprint seems to have been made with the sole purpose of attaching all kernel blueprints to it, useful to find out blueprints though
<smb> apw, neat. yeah I think there might be some workitems I would be adding to the server-requirement blueprint if those are not already somewhere else
<apw> smb, where items belong on that once do move them, i moved one from config to delta cause it was more appropriate there
<smb> apw, ok, will do
<ogra_> hmm, is there something like skipabi=1 for the aliases check ? my custom package always dies in that part 
<apw> cking, didn't you have some blueprints on fwts ?
<smb> ogra_, aliases? Not sure I know what you mean. There would be skipmodules=1 for the modules check
<ogra_> with an s ?
 * ogra_ has skipmodule=true on his cmdline
<smb> ogra_, maybe without. It is usually so long time between usages I look into the code
<cking> apw, minimal one
<apw> cking, i don't see it at all on our list, whats it called ?
<cking> lemme recall..
<smb> ogra_, Ok, it is without the s
<apw> cking, also do you have a launchpad team for your team ?
<ppisati> ogra_: watch out, sometimes it's skipmodule, others skipmodules
<ogra_> damned, i though i had simply typoed 
<cking> https://blueprints.launchpad.net/ubuntu/+spec/hwe-o-fwts-enhancements
<ogra_> ppisati, sometimes ? 
<cking> apw,  a LP team for my team??
<ppisati> ogra_: wait
<ogra_> debian/rules suggests it is without s
<cking> apw, https://launchpad.net/~canonical-hwe-team perchance
<apw> cking, was trying to work out whi i can't find the thing
<smb> ogra_, Yep, that is right
<apw> or more why it cannot find you
<ppisati> watch out
<ppisati> [flag@newluxor ubuntu-natty]$ git co ti-omap4
<ppisati> Switched to branch 'ti-omap4'
<ppisati> [flag@newluxor ubuntu-natty]$ grep -Ri skipmodule debian.*
<ppisati> debian.master/rules.d/ppc64.mk:skipmodule       = true
<ppisati> debian.master/rules.d/powerpc.mk:skipmodule     = true
<ppisati> debian.master/rules.d/armhf.mk:skipmodules      = true
<ppisati> it bite me once already
<smb> ppisati, that looks a bit like arm sets it wrong...
<ogra_> that seems to be a bug in the armhf port 
<ogra_> which we dont use yet
<ppisati> dunno, but yes, it's not consistent
<smb> ogra_, Which sort of brings us back to what exactly is the failure?
<ogra_> Checking for dupe aliases in ac100...
<ogra_> Could not open /home/ogra/kernel/linux-ac100-2.6.37.6/debian/linux-image-2.6.37.6-1-ac100/lib/modules/2.6.37.6-1-ac100/modules.alias at debian/tests/check-aliases line 10.
<ogra_> run-parts: debian/tests/check-aliases exited with return code 2
<ogra_> what would create modules.alias ?
<ogra_> seems there is no skip option for it 
<apw> isn't that a depmod output
<smb> That was what I was thinking too
<apw> that is very fatal, we don't want any kernels with bad aliases, so i am not supprised there is no skip for it
<apw> without the module.aliases your package is likely no good regardless
<ogra_> weird, why wouldnt it be called then ... i copied my debian dirs from another package and the compile runs fine up to that point
<apw> i think we'd need the whole log to know much more
<smb> And probably know what exactly "copied the debian dirs from another package" means. Somehow I have a bad feeling there...
<ogra_> bah
<ogra_> ogra@isis:~/kernel/linux-ac100-2.6.37.6$ ls debian/linux-image-2.6.37.6-1-ac100/lib/modules/
<ogra_> 2.6.37-1-ac100  2.6.37.6-1-ac100
<ogra_> the latter dir is empty ... the former has the missing bits
<apw> cking, ahh you were only proposed for oneiric
<cking> what should it be then?
<apw> ogra_, thats a version problem
<apw> what is the version number in your changelog
<ogra_> yeah i guessed as much now
<ogra_> 2.6.37.6-1.1
<apw> i am not sure you can have the .6 in there
<apw> don't think that works
<ogra_> k
<smb> ogra_, maybe missing clean run
<ogra_> upstream builds use it
<smb> to update the control files 
<ogra_> i'll drop it and re-run 
<apw> ogra_, do you mean the mainline ones ?
<ogra_> apw, the tree i'm building from 
<ogra_> its a chromeos based branch with ac100 stuff on top
<ogra_> with the last mainline merge the .6 appeaderd
<apw> not sure how it ever built for them
<apw> .6 in Makefile is fine, its in debian.*/changelog that its not
<ogra_> *appeared
<ogra_> k
 * ogra_ starts over
<diwic> a quick question, how do I skip building the pae kernel?
<smb> diwic, I don't know whether you can skip individual kernels, but you can only build one flavour
<diwic> smb, right, that's the semantic I meant to say
<smb> diwic, with "fakeroot debian/rules binary-<flavour>"
<smb> diwic, You may want to additionally run binary-headers once to get the generic headers part
<smb> I mean general
<diwic> hmm. I mistakenly thought that the backport modules shared the same infrastructure, but probably they don't (No rule to make target binary-generic)
<diwic> Anyway I'll build both then
<smb> diwic, No, that tends to be a bit more painful
<diwic> argh
<smb> First you have to get the headers from the kernel build and extract them somewhere, and then you would run the build with binary-modules-<flavour> and also need to set KDIR (I believe) to the dir where the headers are
<diwic> I'll build the entire kernel, that's probably simplest
<diwic> I'm making patches to the include stuff as well
<smb> It is a bit simpler in a chroot where you can install packages. Then you can install the headers package from the kernel build
<smb> apw, So I added some workitems to my blueprint. The target may move and I need to speak to  jjohansen about him being assigned to one
<apw> heh you are in charge of server for the kernel, so feel free to abuse him :)
<smb> He seemed to be more on the task there anyway. So I hope it is not really abuse. :)
<ogra_> dpkg-deb: building package `linux-image-2.6.37-1-ac100' in `../linux-image-2.6.37-1-ac100_2.6.37-1.1_armel.deb'.
<ogra_> ...
<ogra_> dpkg-deb: building package `linux-headers-2.6.37-1-ac100' in `../linux-headers-2.6.37-1-ac100_2.6.37-1.1_armel.deb'.
<ogra_> ...
 * ogra_ hugs apw
<apw> ogra_, yay
<ogra_> btw, that build took 70min locally on the tegra 
<apw> thats pretty quick
<ogra_> i guess even if i do a complete build in chroot it will beat out builders
<ogra_> by hours
<amitk> ogra_: -ac100?
<ogra_> amitk, yep
<ogra_> rolling an image in oneiric :)
<amitk> ogra_: congrats!
<diwic> gaah...what's the fakeroot target for changing config options?
<apw> glad to see you are past a .31 kernel
<ogra_> well, the kernel is far from being done, but having an upgardeable package will help a lot to get more people working on it 
<diwic> fdr target 
<apw> diwic, i normally just add the option to the leaf i want it in and run fdr updateconfigs
<apw> i think there is an fdr editconfigs but thats rather boring
<ogra_> and david has some secret plans to equip more people with ac100's
<smb> which is probably not so secret anymore now. :-P
<ogra_> hehe :)
<ogra_> LOL
<ogra_> http://bellard.org/jslinux/ finally i can emulate x86 on arm 
<soren> Fabrice is nuts.
<ogra_> soren, well, that will solve all virtualization issues we have on arm ... we can just set up a webserver now *g*
<soren> ogra_: You don't even need that, afaict. Just a javascript engine.
<apw> ogra_, this thing eats CPU :)
<ogra_> apw, we'll just add a "dont-eat-CPU" CSS :)
<soren> It's an emulator written in javascript. What did you expect? :)
<apw> soren, i expected it to be a fake ...
<apw> heh even the compiler works
<soren> apw: This is Fabrice Bellard, we're talking about.
<soren> He does not have a sense of humour we're aware of.
<soren> If he says he wrote an emulator in javascript, he means it :)
<apw> :)
<ogra_> apw, do you usually call debsign ../*.changes manually or are my debian dirs broken ? my package doesnt ask for a passphrase here
<ogra_> (during source package build)
<apw> dpkg-buildpackage -S -rfakeroot -I.bzr -I.bzr-builddeb -I.git -I.gitignore -i'\.git.*'
<apw> ogra_, i use that and it does ask yes
<apw> though in my common cause it fails cause i don't have the keys where i build and then i debsign -r anyhow
<ogra_> dpkg-buildpackage -rfakeroot -S -sa -kogra@ubuntu.com
<ogra_> thats what i use (no git bits in my source)
<apw> so yes i would expect it to ask, cirtainly asked me last time i maked one
<ogra_> weird
<ogra_> it doesnt with the n900 debian dirs i used as template 
<apw> isn't asking a something you can turn on/off by default in your personal config
<apw> ogra_, do you have gpg installed ?
<apw> as it won't ask you to sign unless you have gpg or pgp installed where you make the package
<ogra_> yes, indeed i do, i use this machine for development regulary
<ogra_> though let me check
<apw> then i am stumped
<ogra_> BAH !
<ogra_> ogra@isis:~/kernel/linux-ac100-2.6.37$ LANG=C ls ~/.gnupg
<ogra_> ls: cannot access /home/ogra/.gnupg: No such file or directory
 * ogra_ hangs his head in shame
 * ppisati -> lunch
<Q-FUNK> could anybody help me with bug #783989   ?
<ubot2> Launchpad bug 783989 in linux "spurrious EXT4 errors remount /home read-only" [Undecided,New] https://launchpad.net/bugs/783989
<Q-FUNK> the end of dmesg seems to indicate what the cause might be, except that I don't know ext4 error codes.
<ogasawara> kernel dudes, did we want to resume our weekly IRC meetings today?  If so, I'll prep the agenda in bjf's absence.  If not, we'll defer and start back up next week.
 * ogasawara back in 20
<tgardner> ogasawara, I think next week should be fine.
 * smb does not object to push to next week
<apw> ogasawara, yeah we have no idea whats what till the blueprints settle down
<sconklin> tgardner: do you want to see whether you have any opinions on this before I revert the patch? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735171
<ubot2> Launchpad bug 735171 in linux "driver ath9k is too slow or not responding" [Undecided,Fix committed]
<sconklin> The Natty commit is 0ce260b37b523766f7fa0dc33b6981f0d85de9e2
<sconklin> no huge hurry, I'm about to go to the dentist and it may be tomorrow before I actually rip it
<tgardner> sconklin, looking
<tgardner> sforshee, can you have a look at bug #735171 ? I'm running out of time today, and sconklin thinks the patch should be reverted. '(pre stable) ath9k_hw: partially revert "fix dma descriptor rx error bit parsing' - but it may already be upstream stable.
<ubot2> Launchpad bug 735171 in linux "driver ath9k is too slow or not responding" [Undecided,Fix committed] https://launchpad.net/bugs/735171
<sforshee> tgardner, will do
<jcastro> jjohansen: here's our bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/782127
<ubot2> Launchpad bug 782127 in linux "RTL8192CE causes a lockup on a Thinkpad X120e" [Undecided,Confirmed]
<jcastro> jjohansen: I am trying with an oneiric kernel now, it hasn't frozen yet.
<jjohansen> jcastro: yeah but your home again, the real test is a noisy environment
<jjohansen> jcastro: that said I installed an oneiric kernel too :)
<jcastro> jjohansen: I will endevaour to find a noisy spot.
<jjohansen> :)
<jjohansen> smb: re sever work item, I had assumed I was doing that anyways as I have an apparmor work item for it from the security side of things :)
<smb> jjohansen, I was assuming that, so I felt less guilty when volunteering you to the task. :)
<ppisati> guys, do we have a list of options that should be turned on to make a vanilla kernel happy with an ubuntu userland?
<apw> ppisati, nothing definative i know of
<apw> ppisati, things we absolutly require are added to the enforce file, but thats only things we have added more recently
<ppisati> uhm
<ppisati> k
<sforshee> sconklin, re bug #735171, the patch is already in the .38.5 stable release, and a couple of testers reported that the kernel in proposed fixed their problems, so I'd think we should keep the patch
<ubot2> Launchpad bug 735171 in linux "driver ath9k is too slow or not responding" [Undecided,Fix committed] https://launchpad.net/bugs/735171
<sforshee> probably a case of similar symptoms with different causes
<mfilipe> will kernel-2.6.39  be released in natty?
<apw> mfilipe, there are no plans for that no
<mfilipe> hum...
<mfilipe> thanks
<apw> mfilipe, we only backport kernels to the previous LTS and only then after release
<mfilipe> I want solve a problem with my intel graphic-card but the ickle releases patch to only 2.6.39 upstream :S
<apw> mfilipe, we do do unsupported builds of mainline
<apw> and if you can find the fix, we can try and get that fix into the natty kernel
<mfilipe> https://bugs.freedesktop.org/show_bug.cgi?id=36599
<ubot2> Freedesktop bug 36599 in Driver/intel "[i915 VGA] VGA output blurred" [Normal,Resolved: duplicate]
<mfilipe> I tried apply the patch in kernel but the intel_bios.c is out-of-date 
<apw> mfilipe, is there an ubuntu bug yet?
<mfilipe> yeah... I one second that I will get the link in launchpad
<mfilipe> apw, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/671921
<ubot2> Launchpad bug 671921 in xserver-xorg-video-intel "External monitor using VGA has sync issues with KMS" [Undecided,New]
<ogra_> apw, so i'm using your patch to lower the console loglevel ... if i set it to 2 as you do, i still get a lot of messages, only setting 1 quietens it, am i missing any additional bits you use with loglevel 2 ?
<ogra_> or is my kernel just a noisy beast ?
<apw> likely the latter i am afraig ogra_ 
<ogra_> ok, i'll just patch it to 1 then
<apw> heh
 * ogra_ is really proud, the first kernel package i ever created and it builds *and* even works on first go
<ogra_> if one looks into the build stuff its actually easier than it appears on first sight 
<apw> ogra_, its a hairy beast, but it gives good hugs if you are nice to it
<ogra_> hehe, well put
<bryceh_> apw, fugly console in oneiric @ 784217
<jjohansen> bryceh_: now that is some nice corruption
<lamont> did 2.6.37 make getrlimit() privileged such that a non-$foo process cannot determine, among other things, it's open file limit?
<jjohansen> lamont: not that I know of, there was some rlimit work to rework how its done in the kernel, change the locking and move around where the security check is done but getrlimit shouldn't be privileged
<lamont> jjohansen: so bugs.debian.org/626928 (and 627026) should be referred to the kernel there?
 * jjohansen looks
<jjohansen> lamont: commit fc832ad3645f0507f24d11752544525a50a83c71 at least at first glance seems to be the fix
<jjohansen> so yeah forward to their kernel with that commit #
<jjohansen> lamont: or it might be commit aa5bd67dcfdf9af34c7fa36ebc87d4e1f7e91873 that fixed it
#ubuntu-kernel 2011-05-18
<eruditehermit> hey
<eruditehermit> is there a ubuntu kernel guy around?
<ppisati> morning
<eruditehermit> morning
<smb> morning
<test___> abogani: ping
<fairuz> Hi
<fairuz> kernel modules are preemptable?
<fairuz> i mean is it possible to have half of function done by cpu0 and the other half by cpu1?
<apw> fairuz, only if there is a lock in the path, otherwise no
<fairuz> apw: ok thanks
<fairuz> hm wait, should the lock make sure only cpu do the job?
<apw> unless you specifically turn on PREEMPT which noone does, then a kernel therad only gives up the CPU when it is reday
<apw> ie, when it sleeps or calles cpu_relax or simila
<fairuz> apw: ok understood now
<fairuz> Hi, is there any equivalent of sched_setaffinity in kernel space?
<fairuz> or it doesn't make sense at all
<apw> fairuz, i believe there is indeed such a thing no idea what its called, as process contexts are process contexts
<fairuz> I don't if this an appropriate question but I try nevertheless. On SMP processors, if we write to a coprocessor register of a CPU, the value will not disappear as long as the CPU is online right?
<tjaalton> when will the -9 ABI kernel get pushed to natty-updates?
<smb> tjaalton, There seem to be two patches that might have been reverted (though I think in the end at least the ath9k may stay) and sconklin was looking into that. So I would expect it to be soon (about next week maybe)
<smb> Or wait
<apw> tjaalton, i think we've moved to 3 week cycle now so 3 weeks after it first appeared
<smb> reverting would mean first week is over so it might be before the verification week...
<tjaalton> smb: ok thanks, I think it should fix the radeon regression that Luca reported here earlier this week
<tjaalton> I'll ask him to confirm
<smb> Yeah. I am not so sure anymore. :-P
<smoser> is it expected that 2.6.32-32.62  will flow soon from -proposed to -updates ?
<smb> smoser, That would be expected sooner. And probably I get through with the latest ec2 kernel change into the same as that contains the tsc fix
<smoser> smb, ?
<smoser> there is a -proposed kernel thats been there for 3 weeks (also a -ec2 varient)
<smoser> i would not expect that new changes would get in at this point.
<smoser> or maybe i just dont understnad the kernel sru process.
<smoser> i'd surely be happy if your tsc fix would get in soon.
<smb> Only because it is very simple, Steve was in a good mood and I did some regression testing. It should not be the normal flow
<smb> I will have to take any beating too if anything goes wrong. :-P
<smoser> smb, so what would be time frame for getting into -updates then?
<smb> smoser, That sounded like being just about to (probably this week). But I cannot promise that the updated ec2 kernel goes through. I have to talk with Steve first.
<jjohansen> sconklin: for what its worth, I am with smb on the new ec2 kernel sooner is better, and I kicked off an instance for testing too
<smb> jjohansen, You found the kernels on tangerine?
<jjohansen> smb: uh no didn't look, I built one
<smb> jjohansen, Works the same. Just I could have saved you that effort. :)
<jjohansen> smb: but where is the fun in that? :)
<smb> I got a finalized git tree locally and the source package ready to upload. But I wanted sconklin s ok first
 * jjohansen has to run to an appointment, back in a bit
 * ogasawara back in 20
<sconklin> smb: just arrived - sure, go ahead and upload. I didn't realizer that the patch was only on the ec2 branch, so it won't even affect the certification that's already taken place, and we should get these kernels out this week. I'm going to respin Natty with one revert today.
<smb> sconklin, Ok, so I push out the git tree (finalizing) and upload to our ppa
<sconklin> smb: good deal
<smoser> smb, great.  I will push to get refreshed images out as soon as kernel enters -updates.
<smb> smoser, Sure, cool. Shall I ping you when it happens or do you track that
<smoser> smb, i really wish i had something that tracked that.
<smoser> the ultimate scenario would be for something to be notified (or poll) for new kernel in -updates, build an image, automated test it... then send me an email with the changes so i could just sign and forward it on.
<smoser> did you want to write that for me ?
<smb> smoser, Apart from probably needing some "how do I build those images" tuition, the tracking part maybe can be padded together from rmadison and some shell glue
<smoser> yeah, there isn't anything technicall difficult, just tying together lots of bits.  i have a start at a program that gets the changes between two images.
<smb> smoser, I try to come up with something that can be run from a cronjob and maybe we can try the rest in Dublin
<smoser> but it doesn't realize kernel changes because of the package name change.
<bjf> moin y'all
<ogasawara> bjf: welcome back!  hope you've recovered.
<smb> welome o bjf. How is life?
<JFo> moin bjf 
<bjf> i'm much better, though dealing with a bit of a head cold i brought back from uds
<bjf> the other issue seems to be completely resolved
<JFo> glad to hear it
<smb> good news
<JFo> oh btw bjf, the regression-potential report doesn't seem to be updating. is there something I need to do to it?
<bjf> JFo, i'll look into it
<JFo> thank you sir, not critical, just wanted to mention. :-)
<bjf> JFo, http://people.canonical.com/~kernel/reports/regressions-potential-report.html looks right to me, or are you referring to another report ?
<JFo> bjf, yep, that is the one, but the numbers are wrong. I removed the tag from the first few before UDS and the number is still the same.
<JFo> and those bugs are still showing
<bjf> hmmm, will force an update
<JFo> ok
<JFo> like I said, not critical, the LP search will work for me too if you have other fish to fry
<JFo> just wanted to mention it in case it was supposed to be updating regularly
<bjf> JFo, it is, there is probably a bug in there somewhere
<JFo> cool :)
<herton> bjf: what you do about embargoed CVEs? I mean, how to identify it etc., so not end up putting accidentaly before time a backport/patch at ubuntu-kernel open mailing list
<bjf> herton, so, for embargoed CVEs, you will get plenty of warning that a CVE is embargoed and we can discuss that then, but really you don't do anything different except maybe not send the patch email to the mailing list
<bjf> herton, the two that i pointed you at, CVE-2011-1593 and CVE-2011-1169, neither are embargoed
<ubot2> bjf: Multiple integer overflows in the next_pidmap function in kernel/pid.c in the Linux kernel before 2.6.38.4 allow local users to cause a denial of service (system crash) via a crafted (1) getdents or (2) readdir system call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1593)
<ubot2> bjf: Array index error in the asihpi_hpi_ioctl function in sound/pci/asihpi/hpioctl.c in the AudioScience HPI driver in the Linux kernel before 2.6.38.1 might allow local users to cause a denial of service (memory corruption) or possibly gain privileges via a crafted adapter index value that triggers access to an invalid kernel pointer. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1169)
<herton> ok
<bjf> herton, note that you do not need to do dapper
<herton> yep, steve told me too, seems dapper has his own magic that everyone hates :)
<herton> and it's going EOL
<bjf> herton, really it's because it's going EOL and we've identified the CVEs that were required, hopefully, we've done the last dapper kernel
<herton> bjf: I requested access to the CVE spreadsheet, not sure who approves that
<bjf> herton, looking
<bjf> herton, should be open to all "canonical" people
<bjf> sconklin, ^ this ring any bells with you ?
<kapare> Hi there! I have weird dmesg that keep poping ups since upgrade to 11.04:::::::
<kapare> type=1400 audit(1305730611.637:128211): apparmor="DENIED" operation="exec" parent=5778 profile="/usr/sbin/libvirtd" name="/usr/local/bin/qemu-system-x86_64" pid=5903 comm="libvirtd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<herton> bjf: hmm strange, here I got that I must be approved, may be because my openid/primary email is herton@gmail.com
<sconklin> herton: I'll look but make sure that you were logged into google with your canonical address not a personal one
<jdstrand> kapare: you need to add /usr/local/bin/qemu-system-x86_64 /etc/apparmor.d/abstractions/libvirt-qemu
<jjohansen> kapare: that means the libvirtd profile is prevent the access
<jjohansen> kapare: the best way to deal with that is ubuntu-bug apparmor
<jdstrand> kapare: you probably did it before the upgrade, got prompted during the upgrade for the conffile change, and accepted the defaults
<herton> sconklin: yeah, I think it's because I'm logged also on gmail, hang on
<jdstrand> jjohansen: I doubt I would fix that bug tbh
<tgardner> herton, I've found the same issue. I generally have to do a complete flush first.
<bjf> sconklin, nice catch, i miss the obvious 
<jdstrand> jjohansen: /usr/local path for qemu. I mean *maybe*, but that is a local change
<jjohansen> jdstrand: right, but in general denied messages should be filed as a bug
<sconklin> That CVE spreadsheet will die soon when new processes are in place.
<jjohansen> jdstrand: yep
<herton> sconklin: worked now, so seems was the gmail logged in
<sconklin> ok
<kapare> jdstrand, thx what specific access requires these files? I may have click default by mistakes but doesn't remeber that part ;)
<jdstrand> jjohansen: sure
<jdstrand> kapare: you can model it after what is already in there. eg: '/usr/local/bin/qemu-system-x86_64 rmix,'
<herton> my launchpad account is tied to gmail account too, so this adds to the confusioin...
<herton> *confusion
<kapare> jjohansen: you mean the irc channel or enter a bug un lauchpad? about the ubuntu-bug apparmor
<jdstrand> kapare: jjohansen is right that in general you would want to file a bug. in this case, I happen to know there was already a bug filed on this, and you know how to proceed, so I don't think it is required. for next time, 'ubuntu-bug apparmor'
<jjohansen> kapare: enter a bug in launchpad, by opening a terminal and typing "ubuntu-bug apparmor", that will collect the denied messages etc and automatically attach them to the bug report
<jdstrand> hehe
<jdstrand> jjohansen: we really should get on the same page here
<jdstrand> jjohansen: there is already a bug on this
<jjohansen> kapare: jdstrand, is right, just clarifying the use of ubuntu-bug
<jjohansen> jdstrand: yep, sorry just trying to clarify the process, not saying to open a bug
<jdstrand> no worries
 * jdstrand slowly backs away from #ubuntu-kernel
<jdstrand> thing is-- really hit the sweet spot for me-- libvirt *and* apparmor, how could I resist? ;P
<herton> bjf, sconklin: ok, for start I'll take CVE-2011-1593
<ubot2> herton: Multiple integer overflows in the next_pidmap function in kernel/pid.c in the Linux kernel before 2.6.38.4 allow local users to cause a denial of service (system crash) via a crafted (1) getdents or (2) readdir system call. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1593)
<sconklin> herton: ok, please feel free to ask about anything
<JFo> food... bbiab
<kapare> jdstrand,  /usr/local/bin/qemu-system-x86_64 is already there I searching on lauchpad but did found yet the bug associated to it ...
<kapare> jjohansen, didn't know about the terminal part will try this right away
<jjohansen> kapare: please don't, or at least try it and abandon it half way through before the bug actually gets created
<jdstrand> kapare: the bug is 510213
<jjohansen> kapare: as jdstrand said he actually already has a bug on this particular one, so it won't help
<jjohansen> kapare: but in general please do as its the best way for us to track, and the best way to get a response about your problem
<jdstrand> kapare: I forgot you also have to add the path to /etc/apparmor.d/usr.sbin.libvirtd
<jjohansen> kapare: dropping into the channel is hit or miss as it depends on who is online at the time
<kapare> jjohansen, ;) will abandon it but nice report it generates
<jjohansen> kapare: yep, its real useful
<jdstrand> kapare: see the bug I mentioned for details
<kapare> jdstrand, I'm reading it right now
<jdstrand> kapare: incidentally, since this is not a kernel issue, it should probably be moved to #ubuntu-security
<jdstrand> (if more discussion is needed)
<jjohansen> jdstrand: err you mean #ubuntu-hardened?
<jdstrand> jjohansen: one or the other redirects to the other
<jdstrand> I forget which
<jdstrand> we try to promote #ubuntu-security though in general, since it is easier to find
<jjohansen> jdstrand: #ubuntu-security requires an invite it seems
<kapare> jjohansen, jdstrand thx will try to add /etc directories and see if message disappear do I need to restart apparmor?
<jdstrand> it might if you are already in #ubuntu-hardened
<jjohansen> jdstrand: oh, hadn't thought of that
<jdstrand> kapare: I think you mean /usr/local/bin/..., but no, you don't need to restart apparmor. just do 'sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd'
<jjohansen> jdstrand: yep that is what was happening
<jdstrand> jjohansen: incidentally, while the parser is technically userspace, since it is actually a plumbing layer/kernel interface type thing for the tools, I moved parser stuff to 'Kernel'parser' rather than 'Userspace' in the bp
<jjohansen> jdstrand: makes sense
<jdstrand> jjohansen: I think that more accurately conveys what is happening-- ie, kernel changes require parser changes
<jdstrand> and vice versa
<jjohansen> yep
<jdstrand> (well, not always, but you know what I mean)
<jjohansen> hehe yeah
<jdstrand> so that should make the distinction between the work items and who does what a little more clear hopefully
<herton> bjf: https://bugs.launchpad.net/bugs/784727 (nominations need to be set)
<ubot2> Launchpad bug 784727 in linux-ti-omap4 "CVE-2011-1593" [Undecided,New]
<bjf> herton, working it now
<herton> And if a nomination after approved is not applicable, the thing to do is set to invalid right?
<bjf> yes, though for karmic, i declined it
<bjf> i should have done that for dapper as well, but you can just mark it "invalid
<bjf> herton, should be good to go
<herton> ok, thanks. Where create-cve-tracker gets the list from releases (karmic, natty, etc.)? Didn't look, but may be we should remove karmic already
<jjohansen> running an errand, back in a bit
<bjf> herton, it gets that information directly from LaunchPad, so LaunchPad still thinks karmic is supported
<Qwc> *knock knock*
<Qwc> Hi m8s, does a kernel ppa exist for 10.10 with the latest 2.6.38 or 2.6.39rc ? because i've got a serious problem with my xeon E5420, the kernel shipped with natty panics at boot or on starting kde
<jjohansen> Qwc: natty is pretty much the latest 2.6.38 kernel
<jjohansen> Qwc: there are mainline build kernels for 2.6.39
<tgardner> not to mention the 2.6.39 kernel. see https://launchpad.net/ubuntu/+source/linux
<Qwc> hmm, wtf? my apt refuses to install ... *gaa* ... okay checking that again (trice now)
 * tgardner --> lunch
<Qwc> okay, well got the 2.6.39rc5 now ... bbl, after reboot and some testing ;)
<Qwc> just a little question, which is the latest kernel the nvidia proprietary driver plays with ? o.O
<jjohansen> Qwc: probably most recent natty kernel, I know .39 breaks the ati fglrx driver and I suspect it is the same for the nvidia proprietary driver as well
<Qwc> ah k, i suspect the kernel from the 10.10 repo doesn't understand both of them, huh?
<Qwc> -kernel +nvidia
<Qwc> hope i'll get not too much dependencies when i download the .deb from natty -.-
<Qwc> i could update the complete dist straight away from a running .39 kernel but working nvidia driver is essential. 
<Qwc> dammit, my gentoo years are too far ago now... 
<Qwc> m8s! please keep your fingers crossed, that the .38 kernel does not panic on my damn machine! ;)
<herton> hardy master-next is failing to build, probably is the last applied ldm patch:
<herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c: In function 'ldm_parse_vmdb':
<herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c:256: error: 'FALSE' undeclared (first use in this function)
<herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c:256: error: (Each undeclared identifier is reported only once
<herton> /home/herton/kernels/ubuntu-hardy/fs/partitions/ldm.c:256: error: for each function it appears in.)
 * jjohansen -> lunch
<Kano> hi, why is not rc7 build for 64 bit?
<Kano> but daily has 64 bit
<bjf> herton looking
<bjf> herton, doing a test build, this will take a bit
<herton> bjf: no worries, I reverted the two ldm patches here for now to test build my backport
<Qwc> well m8s, the kernel paniced ... btw. where can i find the "panic-log", does it exist?
<Qwc> dmesg doesnt log that ...
<Qwc> well, then i have to wait for 11.10... -.-
<bjf> herton, same error here, will investigate and get it fixed up
<herton> ok
<apw> Kano, probabally cause someone fixed the compiler failure in -rc7
<bjf> herton, hardy master-next is fixed
<herton> bjf: nice. Other thing now, about FixingCVEs text, should I care about item 9. Update the Security Team's CVE tracking... ?
<bjf> herton, lets hold off on that until you have that CVE applied to all the kernel trees
<herton> ok
 * herton --> eod
#ubuntu-kernel 2011-05-19
<eruditehermit> hi
<eruditehermit> if anyone around is in charge of the mainline kernel ppa, please can you look into why the amd64 kernels are not building?
<eruditehermit> hi
<eruditehermit> anyone from the kernel team about?
 * ppisati -> out to take care of some stuff, be back in a hour or so
<jpds> Is there a way I can tell a PCI ID to use a specific kernel module?
<jpds> I have a Broadcom wireless card which is not being detected in jockey: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/765839
<ubot2> Launchpad bug 765839 in linux "Kubuntu installer not finding Wireless [bcm 4331 needs driver]" [Undecided,Confirmed]
<apw> jpds, normally modules list which things they support
<jpds> apw: Aha, so I guess I need to hack up the broadcom-sta-source package?
<apw> for jocky i think there is a list of things which trigger wl to be loaded (for broadcom stuff)
<soren> jpds: You can make it work without patching anything.
<soren> jpds: Find the relevant /sys/bus/pci/drivers/<whatever> dir.
<soren> jpds: In there, there's a new_id "file".
<soren> jpds: You can write a vendor/product id pair to it, and the driver will take attempt to use any devices that match.
<soren> jpds: I forget the exact format, but I think it's just "1234 6789". If not, try "0x1234 0x6789".
<jpds> soren: Cool, thanks.
<soren> jpds: Sure thing.
<_ruben> is there a trick to compile a kernel in a pbuilder other than pbuilder login and going from there?
<apw> _ruben, sorry not familiar with using pbuilder, though i'd expect the kernel to be the same as any other package
<_ruben> apw: well, pbuilder takes a .dsc as "input", a kernel build tends to be more complex than a "standard" source package
<apw> _ruben, well you can cirtianly make a source pacakge out of our tree
<_ruben> let me rephrase: how does one usually do a kernel build in an as clean as possible env? clean chroot? clean server/vm?
<apw> _ruben, i do all my test builds before upload in clean chroots yes
<apw> as there i can do partial builds
<_ruben> apw: made with debootstrap?
<apw> _ruben, yep basically so
<ogasawara> Oooo, 2.6.39 final came out.  /me rebases
<apw> ogasawara, have at it :)
<amitk> ogasawara: do we have 2.6.41 for O then? ;)
<amitk> (.39 came earlier than expected)
<ogasawara> amitk: :)  it might make it an interesting call towards the end of the release
<apw> i suspect .41 will appear very late, which will make getting arm ports up to .41 hard, they may actually make .40
<amitk> apw: who cares about ARM?!
<apw> :)
<ppisati> apw: you mean omap4?
<apw> ppisati, including omap4 yes
<ppisati> apw: we are discussing it, and tomorrow i hope to know who is going to carry the landing tree
<ppisati> because the situation is a bit fuzzy right now
<apw> ppisati, does not supprise me.
<apw> ogasawara, let me know when there is a rebase to play with, i have some patches i want to pull up
<ogasawara> apw: cool, should be just a sec
<bdmurray> bug 765082 looks like a good cherry pick for natty to me
<ubot2> Launchpad bug 765082 in linux "[ips-monitor] is in state 'D'" [Undecided,Confirmed] https://launchpad.net/bugs/765082
<bdmurray> ogasawara: ^
<ogasawara> apw: rebased and pushed to master-next
<apw> ogasawara, sounds good to me :)
<ogasawara> bdmurray: cool thanks, will take a look when I get back
 * ogasawara bails to appt
<apw> ogasawara, when we uploading agian?  wondering about cd support
<ogasawara> apw: I uploaded tues so we have your aufs bits
<ogasawara> apw: will likely upload again tomorrow to get v2.6.39 final in
<apw> ahh ncie, will see if there is a disk
<apw> you are off tommorrow
<ogasawara> apw: I know, but it'll only take a few min to prep the upload
<ogasawara> apw: unless you want to volunteer to do it :)
<apw> if you want me to spin it just say
<ogasawara> apw: spin it
<apw> ack
<ogasawara> apw: doko mentioned he might be uploading a new gcc towards the end of the week, but not sure we really need to worry about it considering our new stance
<apw> ogasawara, only in that we want to compile everything with the same one
<apw> will ask him now ... thakns for the heads up
 * ogasawara really bails now
 * ppisati has just tried to rebase sebjan tree on top of natty's master and got around 2.6k patches...
<firewave> ppisati, you gonna have good time :-s
<ppisati> firewave: throwed the towel after the Xth conflicts
<firewave> ppisati, :-/ I understand...
<apw> ppisati, have you tried just merging that tip with the natty master instead
<apw> df
<ppisati> apw: i'm re-reading your (you, bryan, npitre, etcetc) about the handling methods
<ppisati> s/your/your thread/
<apw> yep
<ppisati> nope, but i'll try later
<ppisati> btw, i have an email from cooloney from...
<ppisati> 23/3/2001
<ppisati> 2011
<ppisati> [Natty] [ti-omap4] [Pull-request]: TI OMAP4 2.6.38 updates
<ppisati> where he mentiond he was able to do a rebase against master
<ppisati> but, really, 2,6k patches are a bit too much
<apw> ppisati, though i think he did t th opposite, he didn't rebase branch aganst master, he rebased master against his branch
<apw> which isn't the same at all, but he called it that anyhow
<ppisati> ah
<apw> now i personally think as i said in the thread, if we are using the linaro base, then we should just merge that with master
<ppisati> so he got the latest ubuntu sauce/cve/sru/etcetc
<ppisati> actually sebjan tree was supposed to be based on mainline + BSP
<apw> ppisati, either way if its a major pile of patches, i am inclined to suggest a merge may be less mind dammaging for us, and its not hard to maintain if we know that is what it is
<ppisati> uhm k
<ppisati> anyway, i keep reading...
<apw> anyhow, thats what i tried out in my thread, so perhaps speak again when you have read
<ppisati> ok
<JFo> lunch... bbiab
<jjohansen> rebooting
<ppisati> apw: i didn't faint, it's just that i'm trying to get a sane set of patches from sebjan
<ppisati> apw: and i'm down to 453 now
<apw> ppisati, heh
<ppisati> still after 10 of them i start getting all kinds of conflicts
<apw> that was my experience ... very hard to merge and i am not sure its worth it
<ppisati> anyway, i'm off to the gym now
<ppisati> but i'll keep trying a bit more
<ppisati> we can discuss about it monday
<JFo> ok, I am tired of looking at bugs for one day
 * JFo goes back to planning 
<ogasawara> JFo: just fyi, I posted all the action items from your UDS bug handling session to the blueprint and assigned them to milestones
<ogasawara> JFo: there were some Alpha1 items to knock out
<JFo> ogasawara, you rock! thank you very much. :-)
<JFo> Pete fussed at me for getting action items
<JFo> apparently I wasn't supposed to incur any as this cycle will be almost solely focused on the defect analysis definition
<JFo> so we can get it solidified before the next LTS
<JFo> :-/
<ogasawara> JFo: well now is the time to go through the current items and pull out any you know you need to defer then
<JFo> I thought he meant 'don't get action items from anything OTHER than the bug handling bp
<JFo> right, will do that
<JFo> but thank you so much for taking the notes and noting the actions. I really do appreciate it.
<cnd> ogasawara, do you know why the mainline builds aren't generating amd64 packages?
<cnd> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-rc7-oneiric/
<cnd> not since .39-rc5
<ogasawara> cnd: hrm, not sure.  best to nudge apw since he's been caring for the mainline builds for the most part.
<cnd> ok
<apw> cnd i am told the dailies are now
<apw> and if you look back its cause amd builds are broken
<cnd> where are the dailies?
<cnd> nm, found them
<apw> in the daily sub dir, not that i've checkeed my self
<cnd> they look good
<apw> and it looks like v2.6.39 worked too, so i assume upstream fixed the bug
<apw> if someone finds out which commit fixed it i can rebuild the earlier ones with it
<njin> hello, why is detected as ethernet controller? Ethernet controller [0200]: Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01)
<mjg59> njin: Because its PCI class header says it's an ethernet controller
<njin> mig59: and isn't detected as wirless device then ?
<mjg59> There's no PCI id for wireless
<mjg59> Only ethernet or generic network controller
<mjg59> It makes no difference to anything
<njin> ops, the wireless driver is used but don't work
<njin> mig59: thanks for the explicaton
<cking> mjg59, very amusing patch comment:  https://lkml.org/lkml/2011/5/19/377 - how many more UEFI screwups await us?
<mjg59> Dell laptops with 4GB or more don't boot, but they seem to be dying in grub so that's probably not my problem
<mjg59> Several machines have just appeared with screwed up video setup, but again that's something the bootloader's going to have to deal with
<mjg59> So with luck we're ok in the kernel for now?
<mjg59> I obviously don't actually believe that when I say it
<mjg59> But I'm hoping that maybe we'll catch a break
<cking> I can see we are going to have many more years of dumb UEFI issues in the pipeline
<jjohansen> cking: well if how buggy bioses have been is any indication ...
<mjg59> Let's solve the BIOS problem by making it even more complicated
<jjohansen> hehe, yeah that sums it up nicely
 * jjohansen -> lunch
<jjohansen> running an errand
<mfilipe> sforshee, thanks a lot for your support with kernel http://people.canonical.com/~sforshee/lp614238/linux-2.6.39-020639rc7.201105192014~lp614238/
<mfilipe> I will test it tonight or tomorrow 
<sforshee> mfilipe, no problem, hopefully the fix does the job
<bdmurray> ogasawara: that test kernel worked for me
<ogasawara> bdmurray: cool, thanks for testing.  I'd pinged nessita too to test.
<ogasawara> bdmurray: I'll probably send it to upstream stable
#ubuntu-kernel 2011-05-20
 * jjohansen steps away for a bit
<sdhasu> !ops
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<sdhasu> !ops
<sdhasu> ban me
<ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
<eruditehermit> anyone around?
<awilkins> Hi there, have just fixed a kernel bug and had a few questions
<awilkins> Is there a way to get Soyuz to build a kernel image to a PPA?
<apw> awilkins, you can upload modified kernles to PPAs yes
<apw> awilkins, if you need a quick test kernel it may be quicker to do a manual build, as that only builds fewer flavours
<awilkins> apw, Can you just upload debs, or do you need to upload source differences?
<awilkins> apw, I've got it built and running
<apw> awilkins, PPAs are identicle to the main archives
<apw> so you can upload source packages there too
<apw> awilkins, whats the bug, anything interesting?
<awilkins> bug #776964 
<ubot2> Launchpad bug 776964 in alsa-driver "p5n32e-plus HDA Nvidia AD1988B microphone input not working" [Undecided,Confirmed] https://launchpad.net/bugs/776964
<apw> awilkins, if you just want some semi-official kernels with the patch i can spin some and shove those on people and link them to the bug
<apw> awilkins, is that of use ?
<awilkins> apw, I've got the amd64 one built here, but that would be useful to the other chap in the comment thread, I think. I'm not sure how many people have noticed this one... we can't be the only three people running Ubuntu on that motherboard though, and from the code, the bug may affect anyone with a AD1988 variant
<apw> awilkins, well the norm is to get testing on the bug ... for which i can provide kernels, and then push the patch into the kernel if it fixes things
<apw> i see you say the patch is accepted by alsa upstream?  got a link to that
<awilkins> apw, I just got a mail from Takashi Iwai, not sure he's pushed his tree yet though
<apw> arggg bug trackers which need a login to _look_ at bugs ... no thanks you
<apw> awilkins, can you forward me the patch you sent him
<apw> and i can spin with the right patch then
<awilkins> Done
<awilkins> A variant of this problem has affected the kernel for several releases, but until now it was workaroundable
<apw> awilkins, well its good to get it fixed if its broken
<awilkins> That provoked me into actually looking at it... nothing like breaking something to make a geek try to fix it
<awilkins> bug #593018 Is the older variant of this bug that has a workaround
<ubot2> Launchpad bug 593018 in alsa-driver "nvidi p5n32e-plus Analog Devices AD1988B soundmax microphone only works after switching to another input setting and back" [Undecided,Confirmed] https://launchpad.net/bugs/593018
<awilkins> It only worked by coincidence, reading the code from Maverick, it has a similar logic fault (comparing a type constant to an array index instead of the type value)
<awilkins> I don't know the policy for what constitutes an SRU worthy thing though
<apw> awilkins, small obvious and fixing a real user problem, generally those are valid
<apw> if they come via stable all the better, and if we get lots of testing we can help that happen too
<awilkins> I pulled the alsa-driver bzr branches for maverick and natty - they were useful for reference, do they actually get used to make the builds, because I get the impression the git repositories are the real sources?
<apw> awilkins, our master source is our git tree also, we make source packages from that and upload them
<awilkins> apw, Link to actual patch on mailing list http://thread.gmane.org/gmane.linux.alsa.devel/85204  # just in case that's helpful
<apw> awilkins, indeed so
<apw> awilkins, where are you testing, which release
<awilkins> apw, I'm on natty, testing on my normal working machine. I patched the tip of git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<apw> awilkins, cool
<awilkins> apw, maverick and lucid would need a slightly different patch
<apw> awilkins, we can worry about those later
<apw> awilkins, if you feel inclined you could port the patch and attach it to the bug for those releases
<awilkins> apw, :-)   Also think this bug is replicated in some of the other patch-panel modules
<awilkins> There are quite a number of "my mike doesn't work" bugs in Launchpad, I was trolling through them to see which ones were AD1988 related
<apw> awilkins, good plan, once the test kernels are there we can perhaps get some testing on those other ones and pull the duplicates in
<awilkins> apw, Bah,  I take it back, this is not the same problem as #593018, the code looks all right in <= maverick, on inspection.
<apw> awilkins, well thats good to know anyhow
<apw> awilkins, ok test kernels are in the bug
<awilkins> As expected, nothing has exploded and my mic still works.
<apw> indeedd, hopfully some of the other testers will chime in
<LinkRage> here it says: 'NMI: PCI system error (SERR) for reason %02x' in traps.c (http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob;f=arch/x86/kernel/traps.c)
<LinkRage> how do I find what's the reason (%02x)
<LinkRage> in my case dmesg shows a5, sometimes b5 for %02x e.g.: NMI: PCI system error (SERR) for reason a5 on CPU 0
<apw> awilkins, could you comment in your own bug that you tested my kernels, that helps with the processing
<apw> LinkRage, at first glance (without looking) i'd say they sound like bus produces numbers, ie intel defines them
<apw> SERR#
<apw> System Error is for reporting address parity errors, data parity errors during a Special Cycle, or any other fatal system error. SERR# is shared among all PCI devices and is driven only as an open drain signal (it is driven low or tri-stated by PCI devices, but never driven high). It is activated synchronously to CLK, but when released will float high asynchronously through a pull-up resistor.
<apw> LinkRage, ^^ seems to imply a hardware error being reported
<LinkRage> looks like
<LinkRage> well I'm testing now...
<LinkRage> the issue is caused by brand new (tested) pci sound card
<LinkRage> I think I fixed it by disabled ECC error detection, PCI error detection and disallowed plug & play OS to touch the BIOS settings
<LinkRage> now I'm booting ubuntu again to see what happens
<apw> well disabling error detextion on PCI likely will get rid of the SERR reports, but they are telling you something bad is occuring
<LinkRage> hm, I guess you're right
<LinkRage> I'm also thinking of removing all the other PCI component (HW raids etc - it old server from 2002)
<_ruben> server with soundcard? :P
<LinkRage> yep, I'm going to give it to my father, since he's desktop is even older :)
<LinkRage> ubuntu worked fine this time, now I enabled ECC and PCI detection, but left the plug & play OS: Disabled in BIOS, so let's see...
<LinkRage> huh, PCI error checking is causing the issue when enabled
<apw> that makes sense as SERR is a PCI thing
<LinkRage> :)
<mjg59> LinkRage: More likely that something else is causing it, but you only notice when you have PCI error checking turned on
<LinkRage> I have 2 options here - either remove all the pci raid stuff, and try again, or disable error checking, I've no clue about third option :)
<LinkRage> mjg59, good point
<apw> its not likely things are going to work well with that disabled, its trying to tell you something, something urgent enough that an NMI is warrented
<apw> kees, about?  need to talk to you about a possible bug in Yama
<LinkRage> well, I'll remove all the other PCI devices since I'm not sure if they are in so working condition
<LinkRage> thanks for your advices btw :)
 * apw bounces to test a kernel
<kees> apw: sure, what's up?
<apw> kees, hiay, the yama path check
<apw> it uses generic_permissions()
<apw> which in turn uses i_uid etc and those do not seem to be guarenteed valid
<apw> in the case where the filesystem supplies a permissions() op
<apw> i'll email you the patch i think yama needs
<apw> kees, ok dropped you a dirty copy ... see what you think
<kees> apw: ah, interesting, perhaps this is the origin of 729338 ?
<apw> bug #729338
<ubot2> Launchpad bug 729338 in linux "yama hardlink restriction misbehaves under aufs" [Undecided,New] https://launchpad.net/bugs/729338
<kees> I had been stratching my head over that one
<apw> kees, heh that likely is so, as its under overlayfs which tickles the same issue
<apw> i have a kernel here with aufs in and the patch so i could test
<kees> apw: why doesn't generic_permission do the i_op->permission check itself?
<apw> thats not what its for
<apw> generic_foo in general are for use as implementations when you don't have a foo op
<apw> if you wern't a security op i'd expect you to be using inode_permissions
<apw> but that in itself calls security which sounds loop tastic
<apw> kees, ^^
<apw> kees, testing aufs for the same issue now
<apw> kees, is the hardlink stuff new in oneiric ?
<apw> kees, ok the same test case does not tickle aufs, but the error is the same
<apw> in your report as to what i was seeing in mine
<apw> kees, ahh ok managed to reproduce on aufs at least
<kees> apw: no, hardlink restrictions have always existed in Yama
<apw> odd that we've not seen th
<apw> this more often, or indeed that it only afffects the one case not all that affects overlayfs
<kees> not a lot of people use stacked FSes
<kees> Yama was first in 10.10
<apw> kees, we use them all the time on all liveCDs
<kees> right, but with very few hardlinks :)
<kees> anyway, was the aufs issue the same thing? I wasn't clear on what you had said
<apw> kees will know shortly
<apw> have to reboot to confirm
<apw> kees, ok so this does not fix the aufs interaction
<apw> kees, the debug i have is useful however
<kees> apw: geh, bummer.
<apw> kees, i may as well have a look at it while i ma in the zone
<esmaeil> hi how can i install gcc 3.4 in ubuntu 11.04
<hallyn> Does anyone here closely follow netdev@?  I'm trying to figure out if the patch whose discussion appears to end here http://kerneltrap.org/mailarchive/linux-netdev/2010/5/6/6276530  ever got picked back up in a new form
<apw> hallyn, tim would be your man, but he is away
<hallyn> apw: ok, thanks.
<JFo> <-food time, back soon
#ubuntu-kernel 2011-05-22
<mardy> how should a driver report the screen orientation (that is, which of the 4 sides is currently at the bottom)?
<mardy> via the input subsystem, or with some file in /proc?
<eagles0513875> hey apw
<apw> eagles0513875, s'up
<eagles0513875> nm 
<eagles0513875> has the 2.6.38-9 kernel been released for natty?
<apw> eagles0513875, its only in -proposed, so depends how you define released
<eagles0513875> released as in updat
#ubuntu-kernel 2012-05-14
<waltermundt> O
<waltermundt> oops
<waltermundt> I just upgraded my desktop computer from 10.04 to 12.04, and have started running into frequent but unpredictable "scheduling while atomic" kernel panics.
<waltermundt> I found https://wiki.ubuntu.com/Kernel/DebuggingSchedulingWhileAtomic
<waltermundt> and have just installed the linux-crashdump package and rebooted
<waltermundt> can I afford to just turn all those tracing flags on and go about my day until the system crashes, or will that produce too much tracing data to sort through?
<ohsix> what does sysctl kernel.tainted say
<waltermundt> kernel.tainted = 4097
<ohsix> ok, can you post the entire output of "dmesg" and lsmod to a pastebin
<waltermundt> will do
<waltermundt> ohsix: http://pastebin.com/XKMYa0HK
<waltermundt> fwiw, jockey-gtk lists "Broadcom STA wireless driver" as being loaded, in case that's related.
<ohsix> yea, it may be; does the device work without it?
<waltermundt> I already switched from fglrx to the open radeon video driver in case that was inflicting flakiness, but all that bought me was the ability to see the kernel panic in a text console when it happens
<waltermundt> I don't think so, but I can try; I can also arrange alternate connectivity even if disabling it breaks the wifi card and see if the crashes subside
<ohsix> line 189 might be worth looking into, i haven't seen that before
<waltermundt> Thanks, will search around.  So, here's the plan: I'll disable the proprietary driver, and stick to a wired network connection if necessary.
<waltermundt> If the crashes stop, I may turn it back on and see if I can get a trace, if only to report to the mfgr.  If they continue, then at that point I should be on the stock Ubuntu kernel and will come back here to consult about next steps.
<ohsix> ok, check out the iommu option in the bios too, theres' no reason it shouldn't be enabled afaik
<malaverdiere> Hello. I am running the latest upstream kernel packaged by you guys :) I am getting this when I boot: May 13 13:12:24 redemption kernel: [    7.482877] sdhci-pci 0000:02:00.1: Invalid iomem size. You may experience problems. 
<malaverdiere> Would that be related to some crashes I got randomly?
<ohsix> it would be hard to say if it was related, but crashing is a problem, you could try blacklisting the module and see if the crashes stop
<malaverdiere> I am not able to narrow down the source of the crash much
<malaverdiere> it is a case of suspend-will-not-resume
<malaverdiere> I was told to upgrade my kernel on launchpad, which I did, and it helped - but the telltale log message is goners
<malaverdiere> :(
<ohsix> ah, that's tough
<malaverdiere> I know !!!
<malaverdiere> All I can tell is that I had a non-crashy system on F16, and I now have a crashy system on Ubuntu 12.04 :( :( :(
<malaverdiere> ohsix: which log files may have hints? I looked at syslog, kern.log and dmesg
<malaverdiere> is there a way I can crank up logging orsomething?
 * malaverdiere is not a kernel guy
<ohsix> i had to setup netconsole to debug the last problem i had with suspend, you need ethernet and another computer for that
<ohsix> what does sysctl kernel.tainted say?
<malaverdiere> sysctl kernel.tainted 
<malaverdiere> kernel.tainted = 1024
<ohsix> post the output of dmesg to a pastebin
<malaverdiere> http://paste.ubuntu.com/986445/
<malaverdiere> I can tell you that the problem happened at 18:55 local time. That's when there is a gap in the log file
 * malaverdiere is not sure how to correlate dmesg time stamps with wall clock time
 * malaverdiere holds back a lot of cursing
<malaverdiere> just had a system freeze
<malaverdiere> in the middle of typing!!!
<malaverdiere> ohsix: you've got fresh log files... ask anything you want :D
<ohsix> malaverdiere: the only thing i see is that rc6 is enabled, you could try disabling it; and you'd probably want to ask #intel-gfx if it might be a problem, i don't remember which way it goes on snb
<malaverdiere> I am not sure I am getting you. Are you suggesting I rever to RC5?
<malaverdiere> s/rever/revert
<ppisati> moin
 * ppisati syncs th hdd laptop with my desktop, rsync FTW
 * smb synced ... and tired
<ppisati> smb: morgen Stefan! :)
<smb> ppisati, Ciao Paolo :)
 * ppisati -> goes out to get some food
<dileks> hi
<dileks> since which version of ubuntu 'umask 0022 ...' is required?
<dileks> apw: overlayfs-v13 :-)
<smb> dileks, umask required for what? and apw is only a bot for today. ;)
<dileks> I need that when cloning a source-dir and doing make thingies
<dileks> as an example: http://nopaste.snit.ch/140848
<smb> Hm, umasking the group should only be required if you want to be able to change things later by another user with a different group...
<smb> also umask takes only one argument...
<smb> So "umask 0022" will cause all files created after this to be only writable by the user itself... That is actually more restrictive, but I cannot see what would make it requried
<dileks> lemme look into the src-code
<awilkins> Hello ; I have a kworker process periodically consuming high CPU which is causing annoying pauses, like keyboard lag and skips in music ; is there any way I can diagnose this a bit more thoroughly?
<awilkins> It's fairly regular and periodic, every ~ ten seconds I have a burst of activity on the same kworker process, accompanied 
<awilkins> by keyboard lag
<smb> ... and he is gone...
<awilkins> Ok, I still have a kworker process that's eating CPU every 10 seconds or so, but no more lags ; I'm presuming that before it had CPU affinity with the same process that runs the keyboard IO and other stuff but now it doesn't because I've rebooted
<awilkins> Any way I can find out what a given kworker process is doing?
<smb> awilkins, Not sure how successful that will be but maybe perf (from linux-tools) is can show what functions are called (and which cuase the biggest delays)
<awilkins> Looks like something to do with the nvidia hardware
<awilkins> calling nv50_i2c_getscl
<awilkins> But most of the CPU is in ioread32
<awilkins> I didn't even think I was using the nvidia hardware in this laptop, it's an Optimus
<smb> Are you using nvidia or the nouveau driver
<awilkins> nouvea
<awilkins> The list of functions look like it's polling the hardware for information every 10s
<smb> ok, so that sounds a bit like maybe nouveau is acessing the card a lot... hm
<awilkins> i2c functions, `nouveau_bios_embedded_edid`
<smb> yeah
<smb> Hm, that would be monitor info
<awilkins> Theory : the i2c bus is slow and it's spending a lot of CPU in the ioread32 function because it's waiting for data transfers to finish
<smb> Would make sense. i2c is bit banging... just why it is done all the time
<awilkins> The reason this causes keyboard lag etc when the process affinity is shared with the keyboard IO process is that these IO routines block (note, I am not a regular kernel hacker so that's a guess)
<awilkins> I was under the impression I was using the Intel GPU anyway
<awilkins> The "additional drivers" dialog does not offer me the nvidia driver if I open it
<awilkins> I could add the nouvea module to my modules blacklist and reboot and see if things still work
<smb> It could be those use the same worker or maybe similar locks. Hard to say without looking at code for a while. The additional drivers only offers the binary ones if supported.
<smb> Can be that nouveau supports that model but not nvidia (I've seen this once for ati)
<awilkins> smb, It's not lagging anymore so I'm guessing that the keyboard IO has been allocated to a different kworker this time around
<awilkins> There seems to be 2 kworker processes for each CPU core 
<awilkins> I suspect the keyboard IO was on the same core last time around
<awilkins> This is a Quadro 3000M so it's not your normal GPU card
<smb> iirc there are different general purpose default work queues. Cannot remember which there were though...
<smb> awilkins, Just to be clear, the lag has gone without any reboot?
<awilkins> No, had to reboot
<awilkins> Still have the CPU consumption every 10s
<ppisati> ok, this is about systemd but is still cool: desktop boot time in ~2s
<ppisati> http://freedesktop.org/wiki/Software/systemd/Optimizations
<smb> awilkins, Ah, ok. So maybe the keyboard processing is still on the same type of queue but handled by the other core/thread by luck
<smb> so at least thy kb does not lag
<awilkins> smb, That's my guess
<awilkins> It's an 8 core machine so my odds should be good ...
 * lag is starting to regret his choice of pseudonym
 * smb waves to lag
<smb> lag, there is also a good deal of samba discussions going on for me to notice... ;)
 * lag waves back :)
<lag> smb: Yes, I can imagine :)
<awilkins> Recent nvidia drivers claim to support this card (Quadro 3000M), so I'm still guessing that the "Additional Drivers" thing is not offering them because I'm using the Intel
<smb> awilkins, So still the question for you that remains is why the edid info is read all the time
<smb> Well if nouveau functions are causing this you seem to be running the nvidia part.
<apw> smb, its probabally scanning to see if the connector has anything in it, which it does not as its 'off'
<apw> smb, can you remember the sysfs incantations to turn that other card off, it may help
<awilkins> smb, I have both i915 and nouveau modules running
<lag> smb: I'm thinking the_kernel_is_running_perfectly_take_the_rest_of_the_month_off_paid, would be a better choice
 * smb ignores apw. he is off today
<apw> smb, roaf may know ... and that is why i am telling you :)
<lag> apw: Are you standing?
<smb> apw, Yeah thanks. He may or may not be asleep now
<apw> lag, lying fown
 * awilkins does `sudo rmmod nouveau`
<lag> apw: :D
<awilkins> Ok, so i) my desktop is still here
<smb> awilkins, But yes, RAOF may be the one we need to ask about the nouveau part
<Daviey> i think there is lag behind in the brain department.. oh hai lag.
<awilkins> ii) No more CPU peakings
<awilkins> RAOF?
<smb> awilkins, irc nick of the one "knowing" the gpu parts best
<awilkins> Ah.
<apw> i am pretty sure for optimus, there is a sysfs thing to physically power of the unused nvidia part, stopping these issues and saving power
<apw> awilkins, though you should file a bug against the kernel for the kworker thing if its really slow when doing it
<smb> awilkins, Though he normally is on Australian time zone (if you got back there by now)
<smb> apw, I don't think the kernel can do much more when it is asked to read edid stuff
<awilkins> It's noticeable enough to be *really* annoying
<apw> smb, we shouldn't be causing lags in anything else when bit banging i2c really
<tgardner> apw, unless the i2c serial I/O is really stupid
<awilkins> And the CPU time it's eating will probably drain the battery somewhat as well
<smb> apw, guess it would help if the driver did create its own queue then...
<apw> tgardner, heh indeed and that in itself would be a bug :)
<awilkins> The only other thing that had eaten as much time was my Eclipse instance
<awilkins> Which tells you how obnoxious it is...
<apw> smb, the last time we had this, there was a bug in the intel i915 port scanning too ... and that got resolved
<lag> apw: You heard much from Daviey? I heard he was run over by a parked car.
<awilkins> I wouldn't be surprised if the i2c IO was really dumb
<awilkins> It's not like it's really critical performance stuff
<smb> awilkins, Likely yes. Though two things, it seems stupid to do it that often and then it should be done independently to not cause the generic work queues to delay other things
<apw> lag, ?
<tgardner> lag, how about the guys that had a bird strike leaving SFO? they had to turn around and spend another night.
<smb> Those where going the other way though... 
 * awilkins does `modprobe nouveau`
<apw> smb, i'd suspect its locking for the iobus rather than the workqueues myself, but hey, needs poking, and a bug
<lag> tgardner: Wow! That's something to tell the kids
<awilkins> And it goes back to hitting ioread32 a lot
<apw> tgardner, bird-stike -- that must be exciting
<lag> tgardner: Did it take out an engine?
<tgardner> lag, Bryan and Eric were on the plane. both got diverted
<smb> awilkins, Right, so yes, we should look at that via a bug report
<awilkins> smb, Just getting back that perf table for it
<apw> tgardner, lucking both we on it together
<lag> tgardner: Interesting stuff - I wonder if the passengers heard the strike
<smb> apw, -EDOESHARDLYPARSE
<tgardner> lag, dunno. we'll have to the details from Bryan some time
<apw> smb, in the i915 case it was something dumb like not clearing the por needs checking interrupts so we just did it over and over
<apw> smb, and it only didn't kill us completely cause we were doing i2c in it so it was slow
<smb> apw, The description here sounds really very like that
<awilkins> smb, which package should I file the bug in?
<smb> awilkins, start with linux, we can add other taks/packages later
<smb> awilkins, oh and use "ubuntu-bug linux" if it is not too late alreadya
<awilkins> ? https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
<davmor2> guys I hit an interesting powersaving issue on precise trying to watch the UDS live video stream.  If I unplug the laptop with the offending wifi module in slows right down, plug it back into the mains and it was fine, I'm going to do some experiments to see that it is reproducible what is the useful info you would want for a good bug?
<smb> awilkins, Running "ubuntu-bug linux" creates the bug and collects some log files
<awilkins> Ah, ok then
<ogasawara> tgardner: have you started the -rc7 rebase yet?  If not, I will.  I want to get it upload today.
<tgardner> ogasawara, no, I was pondering sending out an email about conference attendance.
<awilkins> I'm wondering if this might be contributing to the moments of crashiness I've had from my Intel GPU when doing fancy things in Compiz (usually linked to the workspace switcher)
<awilkins> Because I hear that the Intel drivers are very stable
<awilkins> Bug sent : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/999125
<ubot2> Launchpad bug 999125 in linux "nouveau module constantly polls i2c, consumes CPU, on unused nvidia / Optimus" [Undecided,New]
<tgardner> lag, are you attending linaro connect ?
<lag> tgardner: I am, will you be there?
<tgardner> lag, no, but bryan wants to attend. was just looking through the schedule
<smb> awilkins, I would say stability varies especially with newer gpu hw being added. Not sure whether using them both at the same time is really supported right now (and if to which degree)
<awilkins> smb, Oh, I have no expectation of both being used
<lag> tgardner: Is he still doing lots of ARM stuff?
<awilkins> smb, I just rmmod-ed the nouveau again
<lag> tgardner: If so, there's no better conference on the planet 
<awilkins> smb, I'll blacklist it, I don't need a graphics workstation, just a working-station
<smb> awilkins, Right, seem an appropriate work-around for now
<tgardner> lag, well, he's just started back on the distro team, but as you know ARM is definitely one of our focus items.
<lag> tgardner: I certainly don't think it would be the worst use of him time
<lag> tgardner: And it's right by him too
<tgardner> lag, that makes it attractive for him I'm sure :)
<lag> tgardner: Right :)
<dileks> smb: I found this... <http://freetz.org/browser/trunk/Makefile#L110>
<smb> dileks, So (for whatever reason) the makefile checks for it. I suspect Ubuntu rather uses 0002 because the default user is created with its own exclusive primary group. So files writeable by group are less open.
<Daviey> smb: Hey, i thought linux-server was dropped in precise, is this correct?
<smb> Daviey, as a linux flavour yes
<Daviey> smb: good 'o.
<Daviey> thanks
<apw> dileks, -v13 nice
<brendand> Daviey, smb - thanks
<dileks> unfortunately, I was helping my parents as my father got his 3rd apoplectic stroke last week, so I ended in re-packing an up2date precise chroot. but could not test with including my own kernel.
<tgardner> apw, rtg@gomeisa:~$ sudo hdparm --fibmap /boot/grub/grub.cfg
<tgardner> /boot/grub/grub.cfg:
<tgardner>  filesystem blocksize 4096, begins at LBA 4096; assuming 512 byte sectors.
<tgardner>  byte_offset  begin_LBA    end_LBA    sectors
<tgardner>            0  550336976  550336983          8
<tgardner>         4096  553970912  553970919          8
<tgardner> I think its time to rebuild gomeisa
<apw> tgardner, or perhaps just go into my account a zap one of my build/* directories
<apw> and then run it again
<tgardner> apw, it needs to be a bit more deterministic, don't you think ?
<apw> tgardner, where is our swap ?
<apw> tgardner, any chance we could make a /boot with it; i guess its in just the wrong place
<tgardner> apw, its got a GPT partition. so I'm thrashing around trying to rememebr how to figure it out.
<tgardner> rtg@gomeisa:~$ sudo parted -l
<tgardner> Model: Intel Logical Volume (scsi)
<tgardner> Disk /dev/sda: 2392GB
<tgardner> Sector size (logical/physical): 512B/512B
<tgardner> Partition Table: gpt
<tgardner> Number  Start   End     Size    File system     Name  Flags
<tgardner>  1      1049kB  2097kB  1049kB                        bios_grub
<tgardner>  2      2097kB  2318GB  2318GB  ext4                  boot
<tgardner>  3      2318GB  2392GB  74.0GB  linux-swap(v1)
<apw> damn
<tgardner> apw, I'll see when next someone is in the DC and just have'em plug in a CD.
<dileks> apw: http://paste.ubuntu.com/987187/
<apw> tgardner, i thought you could connect a local CD to it via the kvm thingy
<tgardner> apw, hmm. lemme explore that.
<apw> tgardner, no idea how bad the performance would be of course
<tgardner> apw, that would be too handy.
<smb> at least my board would allow (once you get byond the find-the-right-java hurdle)
<apw> smb, yeah ... and tgardner is closer to the thing than me
<tgardner> apw, damn. gomeisa got moved and nobody updated the wiki
<apw> tgardner, really ... try the IS one i asked them to make sure they were on there so IS could find them
<apw> tgardner, so he may not have updated our one, but only theirs
<tgardner> ah, found it
<tgardner> apw, doesn't look like we have the right gizmos hooked to gomeisa in order to simulate a CDROM
<apw> tgardner, when we did tyler, they did a netboot install for us and we configured it, is that an option here
<tgardner> apw, likely not since there is no orchestra server that we can address from tangerine/gomeisa
<tgardner> they are on their own vlan
<apw> tgardner, not one of ours, but theirs.  indeed but they could remote flip it to another vlan, install it, and flip it back
<tgardner> apw, ah, I see. perhaps. I'll chat up Sean when he's back in the office.
<tgardner> apw, actually, I'll see if I can get larry to do it
<Daviey> tgardner: does it currently have an OS?
<tgardner> davyep
<tgardner> Daviey, yep
<tgardner> Daviey, the problem is that grub.cfg is allocated somewhere about the 32 bit LBA block limit on a 2.4 TB disk
<Daviey> oh.. nice.
 * ogasawara back in 20
<apw> Daviey, we'd ideally want to shift the start of root up and shim in a /boot
<apw> Daviey, actually this is something you might want to think about this cycle, that you default to /boot config when there is moer than 2T of /
<tgardner> apw, isn't the issue a bit more generic then that? If the LBA value exceeds 32 bits, then it wraps. I don't hink it makes a difference how large the file system or partition is.
<tgardner> seems like its a decision the installer needs to make.
<apw> tgardner, right the issue is that either grub or the bios is doing the wrong thing in the long-lba calls, but the /boot configuration drop /boot below root i believe
<tgardner> apw, right. you just gotta make sure /boot is in the first part of the disk
<Daviey> that sounds horrid.
<tgardner> apw, is this reasonable perl ?
<tgardner> system ("grep -q pae /proc/cpuinfo");
<tgardner> if ($?) {
<tgardner>         print "This kernel does not support a non-PAE CPU.\n";
<tgardner>         exit 1;
<tgardner> }
<tgardner> apw, I see your overlayfs patches got hoovered up by miklos
<apw> tgardner, i think i'd want to search for ' pae ' or something to make sure we don't match the wrong thing
<tgardner> apw, seems reasonable
<apw> tgardner, otherwise it looks about right
<apw> tgardner, overlayfs> yeah 2 weeks after i sent them, but _yay_ 
<apw> tgardner, i hope we can get a better reln there now
<Daviey> tgardner: is that perl, or wrapped shell? :)
<tgardner> Daviey, its perl in the pre-inst for the kernel
<ppisati> how do you push a pkg to a ppa without a .changes? e.g. the kernel build done in the canonical-kernel-team ppa don't have .changes (at least the arm one)
<tgardner> ppisati, the .changes file only says _what_ to push, but it is not included in the upload.
<ppisati> tgardner: so do i need a .changes or not? because otehrs ppa/pkgs have this file while kernel's ppa do not
<tgardner> ppisati, when you create a source package, one of the files created is .changes. so, dput uses that to decide what files to upload, e.g., the .diff, the orig tarball, the .dsc , etc
<tgardner> ppisati, but I guess that doesn't completely answer your question
<ppisati> tgardner: ah, actually debuild created it but i didn't see it... nevermind
<dileks> apw: http://anonscm.debian.org/gitweb/?p=d-i/base-installer.git;a=blob;f=kernel/i386.sh
<tgardner> ogasawara, hows the Quantal rebase going ?
<ogasawara> tgardner: it's done.  just finishing up powerpc test build and boot testing.  but I'll push it.
<tgardner> ogasawara, cool, I've got a couple of patches to jam in
<ogasawara> tgardner: ah, did you want them in the upload, or can the wait till the next?
<tgardner> nah, they can wait
<ogasawara> s/the/they/
<pgraner> sconklin, ping
<sconklin> pgraner: whassup?
<pgraner> sconklin, whats the link to the OpenHW wiki?
<pgraner> sconklin, me and google are not getting along today
<sconklin> https://wiki.ubuntu.com/OHW
<pgraner> sconklin, great so frickin' obvious
 * pgraner kicks himself
<sconklin> discoverability is not a strong point of our wiki
 * tgardner considers an understatement
<tgardner> that an*
 * ppisati -> gym/workout
<herton> manjo, any news on bug 980965?
<ubot2> Launchpad bug 980965 in linux "[11.10/12.04] Broadcom [0489:e042]bluetooth does not work." [High,Fix committed] https://launchpad.net/bugs/980965
<herton> it's simple and could be marked verified may be...
<manjo> Applied to both bluetooth.git and bluetooth-next.git.
<manjo> herton, what do you want me to do? change status to verified ? 
<manjo> herton, or add a comment ? 
<herton> manjo, I need a confirmation the -proposed kernel works for you
<herton> the oneiric one in this case
<manjo> herton, let me track down the system 
 * herton -> errand, back in 1h and a half
<tgardner> bjf, your 2012Calendar show UDS as Nov 8, but I think it starts Nov 5 (which is a Monday)
<bjf> tgardner: all dates are thursdays
<bjf> tgardner: i just stole the release calendar to use
<tgardner> bjf, so, today is a thursday ?
<bjf> tgardner: all dates on the calendar are thursdays
<bjf> tgardner: may 3, 10, 17,24, 31 are all thursdays
<tgardner> bjf, I think everyday should be Friday. It would be just like Groundhog Day. We'd never achieve the weekend.
 * tgardner bails out for some errands
<jjohansen> ogasawara: would you prefer the fixes for apparmor's net and mount patches be done as patch refreshes or just a patch on top of the existing patches
<ogasawara> jjohansen: refreshes would be good
<jjohansen> ogasawara: okay
#ubuntu-kernel 2012-05-15
<snadge> jerusalem
 * smb mornings
 * apw yawns
<smb> apw, sync;sync;sync
<apw> reboot
<apw> oops
<smb> heh
<ppisati> bloody jetlag...
 * dileks thinks if there where a hwclock.service for internal human clock
<ppisati> bug 985354
<ubot2> Launchpad bug 985354 in ubiquity "Lubuntu 12.04 20120418 install fail" [Undecided,Confirmed] https://launchpad.net/bugs/985354
<apw> cking_, did we decide to enable ALPM for Q ?
<cking_> apw, it was not discussed, but it probably should be to see what fall out we hit
<apw> Bryan Wu (1):
<apw>       MAINTAINERS: add maintainer for LED subsystem
<apw> cooloney, congrats
 * cking notes that there is only so much coffee the brain can handle to try to overcome jetlag
 * ppisati -> goes looking for food
<tgardner> apw, hows it coming on collapsing generic and virtual ?
<apw> just looking at those patches now
<tgardner> apw, I promised the preempt guy that we'd add his flavour only if we could collapse virt and generic
<apw> tgardner, yeah ... we should add an item for that, then i can follow through when this is done
<tgardner> apw, to the blueprint ?
<apw> yeah
<tgardner> apw, I started the lts-backport-quantal branch in precise yesterday. still a bit of messing around to do.
<apw> tgardner, ok cool.  do we have a PPA for that yet?
<tgardner> apw, not yet, thought I'd get the kernel building first.
<apw> i more meant have they decided where the combo ppa will land
<tgardner> apw, I think we can just use an existing PPA, can't we ?
<apw> we probabally want another team which holds it
<apw> as its gonna be for us and X
<tgardner> oh, right, forgot about X
<apw> we need to poke bryceh about what might work
<tgardner> apw, I'll hassle byrce when I've got it building
<Gup> hi, issue with networking/suspend since kernel update.  details: http://pastebin.com/VdMVRWQb  anyone recognise the symptoms, or have an idea what to try next?
<apw> Gup, sounds like you have a known working and known not working kernel version, so get a bug filed and let us know the number, we would want to then to a bisect between the two to work out whats bust things
<apw> Gup, there is a page on doing bisects if you want to attempt it yourself
<apw> jsalisbury, can you point us to the bisect guide ?
<Gup> i'll certainly file a bug.  i'll have a look at the bisect guide and see what it involves
<Gup> i tried to find a changelog to get an idea but it looked like it contained lots of changes that might have been the cause
<apw> Gup, probabally a stable update or similar
<Gup> i'm not overly familiar with the kernel and its workings, i did compile one a couple of times, but thats been a few years
<apw> smb, ok you'll be pleased to know all of the patches in that intel-idle branch you pointed me to are now in mainline
<apw> smb, is this something we can test works ?
<apw> smb, with the quantal kernel, before i commit removing this thing :)
<Gup> the link to the bisect guide on here is broken :s https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
<apw> jsalisbury, you have been doing a number of these, would you be able to fix the docs :)
<apw> https://wiki.ubuntu.com/Kernel/KernelBisection
<apw> Gup, have you seend the above one ??
<Gup> ahha thanks apw, i hadn't found that yet, i will have a go
<tgardner> apw, I see that the hv folks are getting traction with the Debian kernel community
 * tgardner bounces for quantal kernel backport to precise
<ogasawara> hrmph, https://launchpadlibrarian.net/105081769/buildlog_ubuntu-quantal-amd64.linux_3.4.0-2.4_BUILDING.txt.gz
<ogasawara> bah, https://launchpadlibrarian.net/105086088/buildlog_ubuntu-quantal-i386.linux_3.4.0-2.4_FAILEDTOBUILD.txt.gz
<tgardner> ogasawara, puny little buildds
<tgardner> ogasawara, I have a patch in master-next to fix the perf build problem
 * ogasawara fetches
<tgardner> ogasawara, I thought the erro you were pointing at was because the buildd ran out of disk, but I see that its really a packaging error
<ogasawara> tgardner: I was confused as why it would fail on i386 and not amd64, but seeing your patch explains it
<tgardner> ogasawara, it seems its a change from precise
<tgardner> ogasawara, I had at least one build trace that failed within the perf makefile, so I can only assume its a concurrency level issue.
<smb> apw, About those patches, I can confirm on intel and on my amd that it enables the cpufreq in xen. There were no bad effects. 
<apw> smb, ok cool.  so as all of them are in quantal things should be good.  i'll clean up and get this merger in
<smb> To see whether it gains something, one needs to check performance
<apw> yeah not expecting it to be better, just not worse
<smb> In theory it should be better at least on intel as it should allow usage of turbo mode.
<jsalisbury> apw, I'll review and fix up the kernel bisection docs.
<apw> jsalisbury, thank
<jsalisbury> tgardner, ogasawara, Do you still want to have the top ten meeting today, since all the top ten bugs are currently precise bugs?
<ogasawara> jsalisbury: anything new for precise on the list?
<jsalisbury> ogasawara, nothing yet, but I'm still catching up from pre-uds.
<ogasawara> jsalisbury: if there's nothing new atm, we can probably skip it.  just ping us if anything does pop up that need discussing
<jsalisbury> ogasawara, sounds good.  Thanks.
<tgardner> jsalisbury, yeah, what she said.
<jsalisbury> tgardner, ack
<cooloney> apw: sorry for missing your msg
 * cooloney is still in jetlag,
<apw> cooloney, heh, when i heard you had fun with a bird in SFO i assumed you would be off
<cooloney> apw: yeah, it's really fun. hah, we heard a very loud crashing noise in the air. 
<apw> cooloney, man that must have been a fright and no mistake
<ogasawara> cooloney: heh,  I wouldn't call hearing a crashing noise while in flight "fun"
<cooloney> apw: after a while, pilot said our engine was hit by a bird. OMG, I just sat close to the engine
<tgardner> cooloney, shit, thats just the kind of noise you _never_ want to hear on a plane.
 * apw bets that the engine does not enjoy eating birds
<cooloney> so we flew back to SFO. 
<cooloney> i saw some dirty liquid in the engine when I was getting off the aircraft
<cooloney> so we had to stayed in SFO for one more night
<apw> cooloney, sounds awful.  especially staying another night
<cooloney> apw: actually i was upgraded to economic comfort classed in first flight
<cooloney> apw: after a bird hitting, i had no chance to upgrade 
<apw> double buggeration
<smb> ... another ass hurting...
<cooloney> smb: heh, any wiki or lp link for lxc stuff? i intend to try the testcase on my pandaboard.
<smb> cooloney, test cases, we do have test cases? ;-P
<smb> cooloney, But joke aside. I am not sure...
<apw>  cooloney, hallyn is probabally the right person to talk to about how we are using it and so what to test
<smb> He and stgraber 
<smb> For a quick test, I just installed the package, made sure the cgroup fs is mounted (which should be automatic now) and tried running some of the quick examples from the man page
<hallyn> cooloney: I'm in the middle of an update that i haven't tested yet, but lp:~serge-hallyn/+junk/lxc-test has my testcases
<hallyn> (high-level ones mostly, besides the reboot ones)
<smb> cooloney, There is also a chapter in the server guide https://help.ubuntu.com/12.04/serverguide/lxc.html
<cooloney> smb: yeah, i heard hallyn mentioned that during that lxc session.
<cooloney> hallyn: thanks for pointing out this. i will try that
<cooloney> and i believe arm server folks already run them on arm server
<hallyn> cooloney: yup, that's what ahs3 said.  But thanks, the more people running it the better
<hallyn> i guess this means i better go test my changes :)
<apw> hallyn, cooloney soon will :)
<hallyn> heh, good point, on to my next work item :)
<cooloney> hallyn: sure, 
 * cooloney setting up pandaboard
<hallyn> j/k.  i couldn't test at end of uds bc of bandwidth.  need to try it out
<hallyn> jsalisbury: did we pick kernel-kvm as the tag for fwded bugs?  or kvm-kernel?  :)
<gema> tyhicks: ping
<gema> tyhicks: can you please fix the work items for the ecryptfs blueprint?
<gema> tyhicks: it seems not to want to take my changes and it is messing up the work items ... sorry
<apw> herton, does shank-bot make bugs for linux-lowlatency ?
<herton> apw, no, just for our kernels at the moment
<apw> herton, are we doing linux-amardaxp ?
<bjf> apw, yes
<herton> apw, we should be on next cycle, bjf added the code there
 * apw notes lowlatency is lagging severely already ...
<apw> herton, bjf, cool stuff
<bjf> apw, that's a "community" kernel is it not?
<apw> bjf, yes currently so, wondered if it would make sense to make bugs for them
<bjf> apw, we don't for ports kernels either
<apw> bjf, there are no ports kernels which arn't in master are there?
<bjf> apw, ah, true
<apw> so we may be being lucky there more than anything
<tyhicks> gema: Hey - what changes would you like me to make?
 * apw will chat to abogani about it, and maybe ask you again
<bjf> apw, ack
<herton> bjf, btw, armadaxp lacks a entry for the meta-package on ubuntu.py. I was wondering also if we should make Ike the owner of prepare-package on workflow.py
<apw> abogani, your lowlatency kernel is lagging, who am i meant to poke about that, you ?
<apw> herton, for now ike is on the hook for everything armada related
<bjf> apw, wasn't tgardner considering us picking up lowlatency (uds session)
<tgardner> bjf, preempt in Quantal
<apw> bjf, it may become portlike in Q yes
<bjf> herton, yes, we should hadd the meta package. i thought there was a LP "team" that got assigned, that should be used
<bjf> tgardner: you are correct as always
<smb> bjf, herton Just happened to notice that the vcs-git line of precise linux-meta refers to Karmic... Wonder whether  fixing this should require a bug report and all the fun...
<bjf> smb, lol
<apw> smb, you might file 'one bug' and use it for all the releases, cause i bet its wrong in all of them
<herton> bjf, I think the team thing never flied, I'm not sure Ike is on ubuntu-armel-kernel and watches it
 * apw says stike ike on, he'll soon ask you to change it to a team once he starts drowning
<smb> apw, Likely at least between karmic and now... :)
<bjf> herton, lets coordinate with ike. i want it to be a team and not a person
<herton> bjf, ok
<vanhoof> bjf: +1 
<bjf> herton, even if it's a team of one right now
 * apw suggests we make a team with just vanhoof on it
<vanhoof> bjf: we have a few teams now, would you like something trimmed down in size?
 * vanhoof *hides*
<herton> yes, it's better being a team
 * ogasawara back in 20
<smb> bjf, herton opened bug 999726 for tracking
<ubot2> Launchpad bug 999726 in linux-meta "Fix Vcs-Git in linux-meta" [Undecided,New] https://launchpad.net/bugs/999726
<bjf> smb, ack and thanks
<bjf> henrix: ^
<henrix> bjf: ack
<smb> bjf, Was just about to ask whether I should do something about it ... :) But this wfm2
<bjf> smb, nah, we'll take it
<kirkland> tyhicks: I reckon I probably didn't take notes in the modern work-item manner
<kirkland> tyhicks: apologies
<kirkland> tyhicks: behind on the times
 * bjf will brb
<jsalisbury> hallyn, yes, kernel-kvm is the tag
 * tgardner biab
<hallyn> thanks, written down :)
<jsalisbury> ogasawara, whould you like me to change "[TOPIC] Status: Precise Development Kernel (ogasawara)" to Quantal?
<apw> jsalisbury, makes sense
<jsalisbury> apw, sounds like a plan then
<apw> tell me we don't already have a meeting today ... yawn
<jsalisbury> apw, yup.  Top Ten is canceled, but the IRC meeting is still on, for 17:00 UTC
<apw> good grief do we get no time off
<jsalisbury> heh
 * bjf is back
<tyhicks> gema: I *think* that I fixed the work items according to the comment you left. Let me know if it still isn't right.
<ogasawara> tgardner: was reviewing https://wiki.ubuntu.com/Kernel/Release/Rolling, the 14.04 section, should that be linux-image-<flavor> will reference the current supported kernel, not linux-image-<version>-<flavor> ?
<tgardner> ogasawara, prolly
<tgardner> ogasawara, feel free to correct that
<ogasawara> tgardner: ack
<gema> tyhicks: looks good to me, as long as you are sure you haven't lost any other task, I am happy
<tyhicks> gema: I'll take a second look at the notification emails to ensure that nothing was lost. Thanks!
<gema> tyhicks: ack
<tyhicks> (everything looks good)
 * cking punches fwts json logging into submission
<smb> O_o lucid pointing at karmic
<henrix> smb: yeah, a couple of branches had that problem too :)
<smb> Somehow I would have understood them pointing at something earlier but forward is confusion
 * henrix is confused... isn't karmic earlier than lucid?
<smb> err yes
 * smb needs to get his letters right...
<henrix> smb: btw, i tried to add lucid to the bug you filled... but couldn't figure out how to do that :-/
<smb> henrix, No you cannot by bad design
<henrix> smb: ah, cool!
<smb> henrix, its approved now
<henrix> smb: thanks
<smb> hm, and to make this small thing really big, I probably should add the topic branch packages, too..
<smb> henrix, Oh, but fsl-imx51 and mvl-dove not relevant anymore...
<henrix> smb: yeah, i was not sure if all of them were relevant... so you can just NACK those two
<smb> henrix, yup, oh seems natty/ti-omap4 is pointing at maverick
<apw> ogasawara, i just did a test build and it failed with the same (i think) perf thing even with the top of master-next (inc tims fix)
<apw> install: cannot stat `/home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools/tools/perf/perf': No such file or directory
<ogasawara> apw: bah, my test build passed.
 * ogasawara holds off on the upload
<ogasawara> apw: that was indeed the same failure.  were you using one of out build machines or something local?
<apw> ogasawara, that was a gomeisa build, doing a 'full_build=true' build to test dropping -virtual
<smb> henrix, Ok, I hope I have added all the tasks you would need for that bug
<ogasawara> apw: I'll try to reproduce
<tgardner> apw, so wtf is going on with perf ?
<henrix> smb: ok, cool. i missed the natty/ti-omap4, as i just grep'ed for karmic. i should have manually checked everything
<apw> well the base error says perf wasn't built, or it got removed before we made the package i guess
<henrix> smb: will check them all again
<tgardner> apw, thats different then the intermediate failure
<tgardner> apw, how could it get removed?
<apw> tgardner, yeah and i think its what leann saw
<smb> henrix, topic-branch madness. Looks like all ti-omaps like maverick
<apw> tgardner, reading the logs now, hopefully i can see where it broke
<henrix> smb: ok, i'll edit the bug description so that it's a little bit more generic
<smb> henrix, Cool, thanks
<henrix> smb: i'll replace the "karmic" in the desc by something else
<apw> tgardner, ogasawara, ok it looks like when we build the indep version the manual build is now wacking it
<apw> rm -rf /home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools
<apw> ...
<smb> Yeah, can now be Vcs-Git is wrong just about anywhere in linux-meta... :-P
<apw> make[1]: Leaving directory `/home/apw/build/ubuntu-quantal/ubuntu-quanta
<apw> l/debian/build/tools/tools/perf'
<tgardner> apw, hmm, wonder why ?
<herton> smb, you know, copy & paste everywhere :)
<apw> rm /home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools/tools
<apw> install -s -m755 /home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools/tools/perf/perf \
<apw> so i think we build and prep the mans and the tools binaries in the same directory
<apw> so depending which order we do them depends on which we have to package
<tgardner> apw, that seemsl ike a bad thing
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<smb> herton, sure. :)
<apw> tgardner, indeed it does
 * apw pokes ...
<apw> tgardner, this has almost cirtainly come out of our paralellisation work, and likely in P we were just lucky
<tgardner> apw, it has been bugging me for awhile
<tgardner> it  just hasn't happened enough to got to the top of my list
<apw> tgardner, its just wrong, we do two things which can be done in parallel on i386 on the same tmp dir... just working out which is easier to move
<ogasawara> I'm surprised we were lucky all of Precise to not get hit by this
<tgardner> apw, seems simple in retrospect
<tgardner> ogasawara, -j1 on the buildds
<apw> ogasawara, i think we do more parallelism now that we did
<tgardner> apw, we could just serialize tools packaging. its not like it takes that long
<apw> tgardner, its not tools which need serializing, they need serialising wrt 'indep' in general, which isn't reasonable.  they should be in differnet places
<tgardner> apw, which is gonna be a bit of churn. I think Leann is OK to upload given the buildds are at most -j2, don't you think ?
<apw> tgardner, it looks trivial to move the perarch indep, so i'd say give me an hour to work it and decide after
<tgardner> apw, ack
<apw> tgardner, the bid buildds are -j16 arn't they ?
<tgardner> apw, whats a bid buildd?
<apw> tgardner, big ... there are two which are monsters relativly speaking
<tgardner> apw, ah, didn't realize we had anything other then the -j1 xen instances
<apw> tgardner, oh is this going to a PPA, then yes
<apw> tgardner, in that case shove it in
<tgardner> apw, no, she's gonna upload it to the quantal archive
<ogasawara> apw: I'm not uploading to a PPA
<apw> so it all depends on the buildd then that it hits
<tgardner> apw, we could clamp it to -j1 just for the buildds, but thats kind of a hack.
<ogasawara> apw:  I think we want the patch rather than rolling the dice on buildd's
<ogasawara> apw: or we could have infinity or someone retry the current i386 build on a more susceptible buildd
<apw> yeah you could just put it back and see what happens
<apw> i think i have a fix so will go test build it to confir
<apw> tgardner, ogasawara, we may be simply hitting it more on quantal cause of a make change for instance
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 22nd, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
<tgardner> apw, its certainly been annoying me more of late
<apw> tgardner, we have be going more and more parallel and releasing the bits which stop it going fast, so we should be hitting it more really
<tgardner> apw, indeed, that is my empiracal experience
<apw> tgardner, and possibly depending how you build it you could make it happen, i think the act of building it with dpkg-build package, the make build-foo; fakeroot make foo; ought to near guarentee it happens i think
<apw> well i suspect we either lose the binaries or the manuals, but the manuals we don't install by name we just take * so we'lll only notice one way round perhaps
<tgardner> bjf, just pushed some cruft onto ubuntu-precise-meta master. please review prior to uploading.
<bjf> tgardner, ack
<bjf> henrix, herton ^
<herton> ack
<henrix> bjf: ack
<LightScry> Hi, I'm trying to implement "syscall" and having trouble.  My code looks like this: http://cl.ly/3Q2n12113a2X3737191R
<LightScry> It always returns -1.
<apw> tgardner, that seems to only refer to generic and server, but we have generic-pae on i386 and only that right ?
 * henrix will be back in ~30mins
<tgardner> apw, since its a meta package its abstracted by one level. it should refer to -pae in i386
<bjf> cking: https://chrome.google.com/webstore/detail/bcjindcccaagfpapjjmafapmmgkkhgoa
<apw> tgardner, plus there are only linux-image ... shouldn't there be linux-headers-* as well
<tgardner> apw, not sure if we wanna propogate that level of complexity, do we ? do we need the headers ?
<cking> bjf, I'm using: http://jsoneditor.net/
<apw> tgardner, anyone needing dkms needs a meta package for their headers
<apw> tgardner, so either make them linux-hwe-<flavour> and dep on both headers and image, or you need both me thinks
<tgardner> apw, they can always reference the header meta-package directly. I don't think we should support automatic dkms upgrades from release to release.
<apw> tgardner, but then they update their kernel automatically and any dkms they have just stops building even if its compatible
<tgardner> I think dkms is guaranteed to break. look at nVidia.
<apw> tgardner, well we should be testing those before we inject the new kernels if they are supported if thats going to be the only kernel in a while
<apw> tgardner, especially for binary drivers for graphics
<apw> as those are no longer opting in really are they, they are getting updated
<tgardner> apw, well, I guess I'm OK with depending on the headers from the -hwe- and -current- meta packages. I just didn't want the combinatorial explosion.
<apw> we might want to take out 'image' to make it clear if we do that
<tgardner> apw, yeah, I'll update it in a bit. need fuud first
<apw> tgardner-lunch, i can see why my builds never see this normally as i build the indep and dep parts separatly always
<apw> ogasawara, have you been able to reproduce the perf thing locally, you would have to build 'binary' to see it i think ... as it requires a perarch and an indep run to be in parallel
<apw> ogasawara, anyhow if you are, i have a patch which seems to resolve it ... shall i shove it
<ogasawara> apw: go ahead and shove it.  I have not been able to reproduce yet
<tgardner> yeah, its kind of tweaky
<apw> building binary-gneeric will never show it, nor will indep, but for me a binary always tiggers it at -j256 
<ogasawara> apw: lemme try that.  In the mean time I did kick off a re-build for i386.  It landed on aatxe.
<apw> ogasawara, ok pushed.
<ogasawara> apw: I'll clean up the tree since I never did officially upload 3.4.0-2.5
<apw> ogasawara, i also have an overlayfs.v13 update pending, but don't want to throw that in if you are struggling to build
<ogasawara> apw: ack
<tgardner> apw, repushed ubuntu-precise-meta
<apw> tgardner, so i wonder if the package is going to bring image and headers should it be just linux-hwe-generic
<apw> as 1) its different and 2) if we ever do need them separate for some reason, like for the CDs we have space to put them
<tgardner> apw, ah, forgot that. will fix.
<tgardner> apw, fixed
<tgardner> now I need to fix the descriptons as well
<apw> tgardner, i wonder if the linux-generic references should be linux-image-generic
<tgardner> apw, why?
<apw> tgardner, we were talking aboue making linux-gneeric be both perhaps, or removing them, so it might be nice to miss the double indirect
<apw> tgardner, either way right now they are just a double indirect, do we want that
<tgardner> it seems simpler form a conceptual viewpoint, but its really 6 of one, half dozen of another
<apw> ie we'd have linux-hwe-generic -> linux-generic -> linux-image-generic -> linux-image-xxxx-generic
<apw> and linux-hew-generic seems same as linux-generic in the hierachy, so perhaps we should point to l-i-generic
<apw> matters not much at this point as its not affecting any new names or anything
<tgardner> apw, ok, repushed again
<apw> tgardner, so the only thing i find confusing now is that we have -generic and not -generic-pae at the top level for i386
<tgardner> apw, you mean linux-hwe-generic ?
<apw> yeah i'd expect that to be amd64 specific i think, and have a -pae i386 specific
<tgardner> apw, I think -pae will disappear on our way to 14.04. this is supposed to be an abstract meta-package name
<tgardner> apw, frankly, I;d like to change Quantal so that -pae disappears
<apw> tgardner, i almost want to it be -desktop and -server or something, but thats probabally reaching bikeshedding
<tgardner> apw, quantal should have _just_ a generic flavour (that also happens to be the PAE kernel)
<tgardner> then we've homogonized across i386 and amd64
<apw> yeah makes sense, and we should do that rsn
<tgardner> apw, I can make that happen :)
<apw> tgardner, it will conflict heavily with my -virtual work, so perhaps i should do it on top of that
<tgardner> as soon as ogasawara is done faffing about
<tgardner> apw, when you do that, remember to go back and fix ubuntu-precise-meta lts-backport-quantal
<apw> ACK
<tgardner> and ubuntu-precise lts-backport-quantal
<apw> tgardner, *cough* lts-hwe-12.10 surely
<tgardner> apw, its a branch name
<tgardner> who cares
<apw> :)
<tgardner> apw, am wondering, given your builddirpa patch, if perf build really is parallel safe.
<apw> tgardner, it may well be, i have not tested it reverting your change to -j1 yet
<apw> i figured you'd probabally re-test once this upload was up and we could revert
<tgardner> apw, yep. I'm backporting it to older releases, so it'll get some good testing. tangerine is gonna get worked
<apw> tgardner, i assume the issue is somewhere back to O in theory, not really sure why we've never noticed before
<apw> tgardner, so you are doing the backport for the tools build bit yes ?
<tgardner> apw, dunno, but it is pretty racy
<tgardner> apw, yep
<apw> then i can crack a beer and let these virtuals build
<tgardner> thats common all the way back to lucid
<apw> la la la ...
<tgardner> apw, I'm also thinking this is bogus: install-tools: install-source $(stampdir)/stamp-build-perarch
<apw> there are two linkages there, install-source to get source done at all, and stamp-* to build the perarch tools
<apw> i think its odd but right, the build-arch (ish) which has install-tools on it, should have install-source i think, but i'd be less keen to fix that back to L
<tgardner> apw, its the stamp-build-perarch dependency that is unorthogonal
<apw> ahh ... we wen't through that phase of getting rid of the direct build-xxx things forgetting that they were used to allow make build-foo; fakeroot make foo
<apw> tgardner, so it should be build-tools and build-tools: stamp-* with the @; to make make happy thing we see elsewhere ... probabally
<apw> but we optimised a number out, that was inserted after that optimisaiton
<tgardner> apw, yeah, lemme noodle on it for awhile. you go have a beer.
<apw> ogasawara, i've done two test builds with that perf fix 'full_build=true' stylee on gomeisa and no problems, i was 2/2 bad before
<ogasawara> apw: I just reproduced here as well w/o the patch, am going to redo with it.  assuming it's successful I'm going to upload.
<ogasawara> apw: I've pushed the proposed upload to master-next
<apw> ogasawara, nice ... fingers crossed, its pretty blatently wrong
<ogasawara> apw: the re-build for i386 on the buildd failed with the same error
 * tgardner -> EOD
#ubuntu-kernel 2012-05-16
 * abogani waves all!
<abogani> apw: I don't take care of it anymore, you have to speak with one of the Ubuntu Studio kernel Team members...
<apw> abogani, oh ok, any idea who they are ?
<apw> abogani, or more likely what the team is called in LP
<smb> mumble seems jetlagged, too
<abogani> apw, https://launchpad.net/~ubuntustudio-kernel-team
<apw> abogani, thanks
<abogani> apw, Thanks to you!
<dileks> abogani: isnt renaming from lowlatency to preempt a reason to maintain it :-)?
<abogani> dileks: lowlatency turn off tickless and enable thread irqs by default. So no preempt isn't enough.
<dileks> thanks for the update, was thinking this is a renamed -rt kernel-flavour
<ohsix> disable tickless huh, wasn't there a tool that measured wakeup jitter? :D
 * ppisati -> brb
 * ppisati -> rush out for lunch and some grocery - later
<apw> dileks, right ... there never is a -rt patchset close to the version we are releasing on to even consider
<tgardner> apw, did you get this bug report from rick about azure ?
<tgardner> apw, nm, I see you commented recently
<apw> tgardner, yep, at 95 reboots without reproducing ... so ...
<tgardner> apw, ah, this one could be a pain in the ass
<tgardner> apw, kind of wish he'd have come talk to us last week.
<apw> tgardner, yeah ... they are obviously doing something different ... so ...
<apw> tgardner, yeah i did talk with him, and there was no real mention of any urgency
<tgardner> cking, what is the expected string from 'uname -m' on an i386? would it be "x86_32" or just "x86" ?
<cking> tgardner, not entirely sure, /me looks it up on some old kit
<ppisati> tgardner: right, there's even ppc
<tgardner> ppisati, right, so I think we need to change your patch to look for x32 before checking on PAE
<ppisati> tgardner: yep, better
<tgardner> I should have thought of other arches when I wrote it originally
<cking> tgardner, uname -m on a 32 bit atom returns 'i686'
<tgardner> cking, thanks
<tgardner> cking, so, searching on "*86" should be a good reg-ex ?
<cking> tgardner, i think so, but make sure it doesn't match x86_64
<tgardner> cking, how about 'uname -p' on your atom ?
<cking> uname -p --> i686
<cking> uname -i --> i386
<tgardner> cking, ok. given that we're qualifying the search based on 'pae', I think the general "*86" reg-ex is OK, even for AMD etc
<cking> tgardner, perhaps checking uname -i is better
<tgardner> cking, yep
<tgardner> ppisati, you wanna respin using 'uname -i' and checking for "*86" ?
<ppisati> tgardner: will do
<ppisati> tgardner: actually i would prefer to avoid using any regexp
<ogasawara> tgardner, ppisati: I haven't uploaded meta yet, do we want to respin an upload before I do?
<ppisati> ogasawara: yep, doesn't install on arm/ppc
<ogasawara> ppisati: ack
<tgardner> ogasawara, probably cause this'll break armhf
<apw> tgardner, as the builds worked with the tools split, it may be worth you testing backing out the -j change you did for tools (as you can repro it pretty easy)
<tgardner> apw, I think I did already
<apw> ahh ok
<tgardner> apw, its still in quantal, but I dropped it from the other releases
<apw> tgardner, you did the backport a bit different, should we standardise on your version
<tgardner> apw, I'm almost positive that it was releasted to the perf binaries being removed
<tgardner> related*
<apw> tgardner, it would cirtainly look similar indeed
<tgardner> apw, yeah, we could standardize. its a bit simpler.
<apw> tgardner, ack, please do
<tgardner> apw, will do
<apw> ogasawara, is quantal 'good' ie can i punt some more crack into it?
<ogasawara> apw: built fine, just holding off on meta till we get the pae check correct and will re-upload.  feel free to shove any other crack in for the upload.
<tgardner> apw, ogasawara: I'm gonna reorganize master-next a bit and cleanup some of our (my) mistakes. 
<ogasawara> tgardner: cool, I wanted to rebase some bits out of existence too, you go first.
<apw> tgardner, ogasawara, when you are done yell and i'll rebase the bits i have onto the top
<apw> (they are re-build testing now)
<tgardner> ogasawara, pushed
<ogasawara> tgardner: ack
<apw> top - 10:06:32 up 14 days, 17:01,  1 user,  load average: 450.34, 296.49, 165.35
 * apw whistles quietly
<tgardner> apw, tangerine ?
<apw> goemeisa
<tgardner> I built every release yesterday on tangerine. I imagine it was heating the room.
<apw> heh ... i bet ... i am being utterly mean to it, -j512, just to see whether it copes
<apw> and its amazingly still up
<ppisati> tgardner: i noticed that :)
<apw> top - 10:08:08 up 14 days, 17:03,  1 user,  load average: 511.94, 359.70, 200.68
<tgardner> apw, pgraner and larry will be at 1SS on Friday at which time I will unf*ck /boot
<apw> tgardner, a perfect time to scare the crap out of them by playing tunes on the fans
<apw> tgardner, think you can shift the root up a bit, or will you just zap it
<tgardner> apw, like they'd be able to hear an individual fan in that place.
<tgardner> apw, I'll see if I can shift things around, but failing that I'll just rebuild from scratch.
<apw> tgardner, ok then i should make sure the crack builds are pulling off their state properly like they are meant to
<apw> tgardner, so i can put it back after
<tgardner> apw, yeah, be prepared for total destruction. you _know_ how skilled I am at sys admin :)
<apw> tgardner, it all designed with fungible machines in mind, just i've never funged it
<apw> i should really kill it all off on gomeisa and just move it to tangerine
<apw> to prove it works and is documented
<tgardner> apw, well, here is your chance. you could switch to tangerine for awhile.
<apw> tgardner, ok friday you say ?
<tgardner> apw, that was the last I heard
 * apw adds it to his list
<dileks> does sth like snapshots.u.c exist?
 * dileks wants to downgrade resolvconf
<xnox> dileks: it's called launchpadlibrarian
<ogasawara> apw: pushed my changes, she's all yours
<ppisati> ogasawara: tgardner: patch sent to the ml - in the end i used a =~
<tgardner> ppisati, ack
<apw> ogasawara, ok pushed overlayfs.v13 update
<ogasawara> apw: ack
<tgardner> ogasawara, I'll pick up ppisati pae fix
<ogasawara> tgardner: ack
<ogasawara> apw:  you sure you pushed it?
<ogasawara> apw: I'm not seeing it
<apw> ogasawara, i failed due to incompetance, try now
<ogasawara> apw: much better
<tgardner> ogasawara, get your whip out
<ogasawara> tgardner: I dunno, he might actually enjoy that
<tgardner> kinky englishman
<apw> might, how little you know me
<ogasawara> hehe
<tgardner> ogasawara, ok, I'm gonna whack master-next yet again to cleanup the PAE patch. OK ?
<ogasawara> tgardner: ack
<arges> ppisati, hello. is there a wiki for pandaboard setup? just got one in the mail, so probably be setting that up sometime
<tgardner> ogasawara, pushed. now we should be able to start build and boot testing.
<tgardner> ppisati, I assume you've tested your patch on arm ?
 * cking upgraded to quantal and sees no breakages
<ppisati> tgardner: yep, that
<ppisati> s why it took me so long
<ppisati> arges: uhm
<ogasawara> tgardner: cool, will get things kicked off
<ppisati> arges: don't think so...
<arges> ppisati, ok just pandaboard.org... read through that?
<ppisati> arges: no no, wait
<tgardner> ogasawara, yeah, I've got my hoover moaning as well
<ppisati> arges: https://wiki.ubuntu.com/ARM/OmapDesktopInstall
<ppisati> arges: just dd the img, and you are done
<arges> ppisati, perfect thanks
<apw> arges, yeah if its harder than dd image -> sd card, insert and power on, you are doing it wrong
<dileks> xnox: and how do I get the diverse sources? as "http://librarian.launchpad.net/ is a file repository used by Launchpad. "?
<tgardner> cking, do you have a non-PAE atom in your collection ?
<arges> apw, yea much easier than the other embedded boards i've played with
<cking> tgardner, yep, I can dig one out of the pile
<tgardner> cking, it would be good to test the upgrade path from precise -generic  to quantal. 
<tgardner> i wanna make sure it fails.
<cking> tgardner, just checked, all my old atoms are N270s, which by default run -pae
<tgardner> cking, ok
 * cking wonders if there is another way to test, how about in virtual box?
<tgardner> cking, dunno, I've not used VB
<tgardner> ogasawara, I'm still getting build failures in perf, so it looks like it may really not be parallel build safe.
<smb> Hm, I think with kvm you can influence the cpu emulation...
<cking> looks like VB has PAE enable/disable mode in the config
<tgardner> ogasawara, I pushed master-next with a patch to disable $(conc_level) when building perf.
<smb> cking, Using virt-manager with kvm seems to allow to set some cpu type and you can change cpu flags... Never tried that, though
<xnox> dileks: you need to manually work through http://launchpad.net/ubuntu/+source/package find the binary build you want and download individual debs
<dileks> hmm
<dileks> https://launchpad.net/ubuntu/precise/amd64/resolvconf
<dileks> looks like this gives me an overview of all versions
<cking> hrm, can't seem to install precise-i386 with pae disabled in virtualbox
<apw> cking, heh you won't be able to, the CD is pae
<apw> i think the only official way to get there is to install oneiric i386 and upgrade
<cking> doh, yep, /me downloads oneiric -i386 and tries
<jsalisbury> apw, just let me know if you want me to help bisect bug 994870
<ubot2> Launchpad bug 994870 in linux "kernel panic on boot with hyper-v" [Critical,Confirmed] https://launchpad.net/bugs/994870
<apw> jsalisbury, ack though it needs some special patch handing i think and as we have nothing to test on right now ...
<jsalisbury> apw, ok.  I'll keep a close eye on it.
<ogasawara> tgardner: ack
<tgardner> ogasawara, ok, mine built OK this time
<ogasawara> tgardner: will re-kick off my builds here
<tgardner> ogasawara, I'm bisecting a backlight regression on my Dell 1710 that occurred somewhere between -rc5 and -rc7. Once I know what it was I'll work with upstream to get it fixed.
<ogasawara> tgardner: ack
 * ogasawara back in 10
<apw> ogasawara, man he can eat fast some days
<tgardner> apw, its these new management techniques she's been learning
<cking> parallel processing perhaps?
<apw> cking, shoving half in each end perhaps
<cking> apw, one can only speculate...
<apw> cking, its likely illegal to do more
<cking> :-/
<smb> One can speculate about some rolling on the floor going on somewhere... :)
<tgardner> ogasawara, quantal build succeed ?
<ogasawara> tgardner: looking good so far... powerpc is always the longest to get confirmation
<tgardner> ogasawara, thats likely to be OK. I don't think we changed any arch specific stuff, did we ?
<ogasawara> tgardner: only big changes were the overlayfs bits but I don't believe that has anything arch specific
<ogasawara> tgardner: have we been able to get any test confirmation for non-pae hardware?
<tgardner> ogasawara, I think cking is working on a VB test
<cking> yep, it's taking a while to install and upgrade in VB :-(
<smb> afternoon went where the morning did do just before...
<tgardner> smb, I'm gonna add you as s-o-b or acked-by on these xen-acpi patches, then push 'em
<smb> tgardner, I should be as s-o-b on those I pushed already
<tgardner> smb, right
<cking> hrm, "About 4 hours remaining" on the upgrade does not bode well
<tgardner> smb, several are cherry-picks from Konrad
<smb> tgardner, Ah right, I did not change the s-o-b unless I meddled with one since the version you had
<smb> So yeah, feel free to add me to the remainder
<tgardner> smb, I'll make sure you're in the chain of responsibility :)
<smb> tgardner, I am sure you do :)
 * smb really likes the 20W less power usage on idle for his AMD box...
<cking> smb, calculate how power is saves and turn it into beer money
<cking> s/how/how much/
 * smb looks at one additional pint a month...
<smb> If my maths are not too much influenced by desire
<tgardner> ogasawara, re: backlight regression, -rc5 good, -rc6+ bad
<ogasawara> tgardner: anything obvious from the changes between the two?
<tgardner> ogasawara, not really. I'm gonna start a real bisect
<tgardner> there are a half dozen gpu patches, but I'm not gonna make any assumptions
<sforshee> tgardner, have you determined which backlight interface is being used on the machine? That might help limit your bisection
<tgardner> sforshee, haven't looked
<tgardner> that would require some assumptions
<sforshee> how so?
<tgardner> sforshee, it assumes the regression is under drivers/gpu right ?
<tgardner> it might be a platform issue
<sforshee> tgardner, not necessarily
<sforshee> you have to check which of the /sys/class/backlight/*/brightness files is changing when you change the backlight
<sforshee> it might not be a gpu backlight driver
<sforshee> in which case looking under drivers/gpu is pointless
<tgardner> sforshee, which is why I'm doing an unrestricted bisect
<tgardner> sforshee, acpi_video0 is the backlight class
<sforshee> tgardner, nothing in your range from drivers/acpi or drivers/platform/x86 looks related, so I guess the unrestricted bisect probably is your best bet
<sforshee> I have a hard time imagining what caused the regression
 * ppisati -> gym/workout
<tgardner> sforshee, looks like its homing in on nouveau, which is not really surprising
<arges> tgardner, hey tim. if i want to test wireless-n performance, is iperf a good tool to use?
<tgardner> arges, tahts what I use to sort of smoke test it
<tgardner> to smoke*
<arges> tgardner, ok just default flags/window size?
<tgardner> arges, yep. to make it really whine, though, try a bi-directional test
<arges> tgardner, ok i'll give that a shot.. i just can't seem to get more than 50Mb/s on 802.11n using iperf on a couple of machines
<arges> both are 2x2s, and I think the router is also a 2x2..but need to make sure
<apw> herton, where are we in the precise SRU process
<herton> apw, testing week
<tgardner> sforshee, I bought a copy of the 802.11-2012 spec for $5 from IEEE. I think its got all of the amendments applied, so its a lot more readable.
<herton> apw, new kernels should be prepared next week
<apw> herton, i am likely to have a patch which needs to be out as soon as humanly possible
<herton> bjf, henrix ^
<arges> tgardner, going in the other direction (wired to wireless computer) results in a higher bandwidth reading, not sure if that's normal
<apw> ok that sounds ok then i think, this one should be out before we have confirmation
<tgardner> arges, I typically use only one wireless station and a wired server
<apw> herton, i may ask you to slide out a very thin kernel update in between this and next cycle, so lets circle before you build the next one if thats ok
<tgardner> arges, remember that its a half duplex medium
<apw> hallyn, hopefully it won't be necessary, and your normal cycle will be quick enough
<apw> herton, ^^
<arges> tgardner, yea need to probably shut off other devices
<apw> herton, so see this as just a head up for now
<herton> apw, ok, we still have this precise kernel on testing, bug 991925
<ubot2> Launchpad bug 991925 in linux "linux: 3.2.0-24.38 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/991925
<apw> herton, cirtinaly yell if you are respinning for anyting on this update
<herton> apw, so we will have to see how to do it if it doesn't get to updates in enough time
<apw> herton, indeed.  i think we have time, but we can evaluate before you next cycle
<tgardner> sforshee, bisected to b99da31ed8521eb78d5d6930f3128f8ecdb75fae drm/nv10/gpio: fix thinko in mask for gpio lines 2-9
<tgardner> am reverting to confirm
<greearb> hello!  Back to hacking on casper & USB persistence...anyone around that might know why /cow isn't found once booted?
<arges> tgardner, ok yet another wireless question. Running lucid with backported kernel . it needs the broadcom sta wireless restricted driver (bcm4321) . is there a package i need to install, or repository i need to enable?
<tgardner> arges, I doubt that is a configuration taht is supportable. you'll need the dkms driver from the backport release.
<arges> tgardner,ok thanks
<tgardner> ogasawara, commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes my regression. email sent upstream.
<ogasawara> tgardner-lunch: ack
<tgardner> arges, re bug #953494 - in which releases do you want linux-firmware-nonfree uploaded ? Lucid and Precise ?
<ubot2> Launchpad bug 953494 in linux-firmware-nonfree "bcm_wimax module hangs when Sierra Wireless 250U Data Card removed" [Undecided,New] https://launchpad.net/bugs/953494
<arges> tgardner, yes lucid and precise would be best
<tgardner> arges, ack
<arges> tgardner, thanks
<sforshee> tgardner, I just saw your comment about the 802.11 spec in my backscroll. $5 is cheap, I'm going to pick up a copy too.
<tgardner> sforshee, thought you might be interested
<HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
<mjg59> I'm not sure I can easily enumerate the number of things that have just gone wrong here.
<tgardner> kind of makes your head hurt
<tgardner> arges, upload linux-firmware-nonfree for Lucid/Precise. Feel free to annoy an AA at your leisure. Without doing so the multiverse approval queue may not get examined for awhile.
<arges> tgardner, whats an AA in this context
<tgardner> archive admin
<arges> ok ok...
<arges> thanks
<tgardner> arges, the list of folks to annoy are in https://wiki.ubuntu.com/ArchiveAdministration
 * tgardner -> EOD
#ubuntu-kernel 2012-05-17
 * apw is having a bad day
 * apw listens to his main home disk go 'der-der-der der-der-der'
<dileks> die-die-die... das-das-das... then you have all 3 German pronouns (male, female and neuter)
<apw> my disk is more neuter i think
<dileks> depends... I always loved my hardware, gave them mostly female names
<cking> apw, you should have asked Intel for a SSD while at UDS...
<apw> dileks, heh i more meant it has been neutered
<apw> cking, that'd have been nice ... now i get to test my backups i guess
<cking> be interesting to see what the SMART data says about the HDD
<apw> cking, the bios says "disk failure"
<cking> :-(
<ppisati> it compiles... almost...
<Kangarooo> hello. mainline means upstream?
<Kangarooo> https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelMainlineBuilds is written to install B & C kernels for 32bit ubuntu. 
<Kangarooo> so from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc6-precise/ i take
<Kangarooo> whitch one>?
<Kangarooo> *image*.deb ?
<Kangarooo> if my laptop has pae then i need pae?
<Kangarooo> ill check chat log
<dileks> if you use x86-32 and your cpu has pae flag supported... yes
 * apw looks out from a new machine ... hmmm not bad
<ppisati> apw: did you manage to recover everything?
<apw> ppisati, in the process ... though i need to source new rust before i can move back to my machine
<apw> tgardner, it has taken me so long to get into the directory i have forgotten who i am looking for :)
<tgardner> apw, not sure I can help you there :)
<apw> tgardner, network manager dude
<tgardner> apw, hang on a sec
<tgardner> apw: MathieuTrudel
<apw> tgardner, perfect thanks... question away
<tgardner> apw, what is the rt meta package in precise called ? its not preempt.
<apw> you meant the lowlatency kernel ?
<apw> tgardner, ^^
<tgardner> apw, that one.
<apw> its called linux-lowlatency i think
<henrix> yep, i guess that's the one
<dileks> bfs :-)
<apw> that reminds me i need to push out that -virtual update once i have it back
<tgardner> apw, yep, we need to get those collapsed soon.
<apw> lest we collide hideously and me scream
<apw> tgardner, i have it done, just needs re-build testing on top of the current tip
<tgardner> apw, I'm mapping the plan for meta package upgrades which depends on being able to drop virtual
<apw> tgardner, yep makes sense
<apw> tgardner, as far as i can tell from the testing smb has done, we should be able to apply it and things just work
<apw> tgardner, its all there, making a -generic in split mode
<apw> tgardner, and we were going to rename generic-pae at the same time yes ?
<tgardner> apw, I don't understand split mode
<tgardner> oh, extras
<apw> tgardner, the merge relys on having ... yes extras as well
<apw> tgardner, so the meta package will need to be modded to pull in both for -generic and one for -virtual
<tgardner> apw, I'm just writing that up. we write the meta package for what we need in Quantal. we use upgrade-manager to manage the transition to Quantal.
<tgardner> rather, update-manager-core
<apw> tgardner, won't we also need transitional package linkage too ?
<tgardner> apw, not if we can do it programmatically
<apw> tgardner, i though we had to handle the update/dist-upgrade side too 
<tgardner> apw, we don't have to support 'apt-get dist-upgrade' if its not convenient.
<apw> ok
<tgardner> apw, as far as I can tellm the re is no combination of Provides:, Replaces: or Depends: that will get us where we wanna be
<tgardner> the upgrade janitor is the way to go
<tgardner> apw, remember that gomeisa is going away tomorrow
<apw> tgardner, grrrr
<apw> tgardner, yep thanks
 * apw will rsync the stuff to tangerine as a backup
<ogasawara> tgardner: have we set up the PPA yet for QA to be able to start testing the 12.10 kernel in 12.04?
<tgardner> ogasawara, dunno, I have not hassled byrceh yet
<tgardner> guess I ought to do that today
<tgardner> got sidetracked by the hv mess yesterday
<tgardner> ogasawara, I'll send him an email
<ogasawara> tgardner: ack, can you CC me on it?
<tgardner> ogasawara, no, I plan to keep you in the dark. (just kidding)
<ogasawara> :)
<tgardner> ogasawara, I just Cc'd the k-team list
<ogasawara> tgardner: cool, thanks
<arges> ogasawara, good morning. I was wondering what git tree the daily kernel ppa builds being built from?
<ogasawara> arges: it should be pulling from the latest tip of our usual trees
<arges> ogasawara, ok. essentially what I want to do is bisect between two versions that i've tested on lucid 2.6.33x which i've tested using the daily ppas... was wondering if i just need to find the commits in ubuntu/ubuntu-lucid or if there was another tree that has these patches.
<tgardner> arges, the dailies are built from the master-next branch. I don't understand the source of your confusion. wtf is lucid 2.6.33x ?
<arges> tgardner, so i noticed the daily builds have a newer version than the release for lucid, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.1-lucid/   
<tgardner> arges, ah, those are mainline builds, not dailies.
<tgardner> vanilla stable
<arges> tgardner, ah. ok so essentially vanilla with the debian.* folders added in?
<tgardner> arges, yep
<tgardner> no ubuntu cruft
<arges> tgardner, ok and which tree is that?
<tgardner> arges, right from upstream stable updates
<tgardner> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
<arges> tgardner, ok so just copy and paste the debian folders from ubuntu-lucid if I want to build a lucid-ish kernel
<tgardner> arges, why not just use the deb-pkg target ? 'make deb-pkg INSTALL_MOD_STRIP=1'
<arges> tgardner, ok i can try that
<tgardner> arges, I assume you're bisecting something ?
<arges> tgardner, yes
<tgardner> arges, then you wanna use a linear tree. If you try to bisect between Ubuntu tags you could get all confused.
<tgardner> a linear tree being upstream stable
<arges> tgardner, yup did that yesterday, and the bisect landed on a commit that didn't make much sense.  ok i'll use the stable upstream 
<tgardner> arges, take the config from Lucid and start with that.
<arges> tgardner, ok will do. 
<apw> arges, make configs will generate you some in CONFIGS
<arges> apw, yea the vanilla defconfigs
<apw> arges, i meant to say 'fakeroot debian/rules makeconfigs'
<apw> will make you ubuntu configs in CONFIGS/*
<arges> ah
<herton> bjf, jsalisbury, I was looking again at bug 1000355, since it's a drbd issue on Lucid (drbd was not in the kernel yet), who we should ping to fix/push the update, there is a patch for the package there now
<ubot2> Launchpad bug 1000355 in drbd8 "[SRU] drbd fence-peer breaks when using kernel 2.6.32-41" [Medium,Confirmed] https://launchpad.net/bugs/1000355
<bjf> herton, not sure, will think on it
<jsalisbury> herton, i'm not sure either
<arges> apw, don't see 'fakeroot debian/rules makeconfigs' i see a genconfigs, but that doesn't seem to work. in the ubuntu-lucid tree
<henrix> arges: i guess apw meant genconfigs
<apw> he did, *tard
<arges> henrix, ok
<henrix> arges: but i believe you need to run fakeroot debian/rules clean before that
<apw> it is not my finest hour
<apw> waht henrix says
<arges> apw, henrix : thanks guys got it now
<apw> repeat after me, i have reliable backups and a clue how to restore them
<arges> seths awesome build script has made me lazy
<arges> uh oh
<henrix> apw: i'm considering setting up bacula one of these days... but for now a cron with rsync has been doing the job
 * cking was wondering why his dev box was running so slow and just realised it was running an instrumented kernel, doh
<bjf> herton, looking at that drbd bug ... the user is using a drbd dkms package. as far as i know that isn't our package. the fix must be applied there (as i understand it)
<herton> bjf, yep, seems ivoks also is already preparing for the usual SRU process for drbd8, so I think we are good. I removed the linux task from the bug
<tgardner> bjf, I'm just looking at it. I can do the patch and upload.
<tgardner> since I'm the one that implemented the original carnage in the kernel
<tgardner> or applied, rather.
<tgardner> bjf, drbd went mailine in 2.6.33, so I'm wondering why we're still carrying the dkms package
<herton> tgardner, it's lucid, 2.6.32
<bjf> tgardner: was thinking the same thing
<bjf> tgardner: though herton is correct that the user is running .32
<tgardner> herton, right, lucid is the last release for which anyone should be compiling drbd8
<tgardner> bjf, herton, bug #1000355 is now fix committed
<ubot2> Launchpad bug 1000355 in drbd8 "[SRU] drbd fence-peer breaks when using kernel 2.6.32-41" [Medium,Confirmed] https://launchpad.net/bugs/1000355
<bjf> tgardner: thanks
<herton> tgardner, ack, thanks
<apw> cking, so my networking issues are all nm being bust, and all triggered by misshanding of RDNSS record expirey... essentially the broadcast ipv6 DNS servers are timing out and NM then craps itself and disconnects
 * ppisati -> rush out to do some stuff, back in a while
<apw> every 10m
<apw> and its much worse when the network is slow
<cking> gah, that's badly behaving userspace app
<apw> yeah. very ... the debug is informational from it i guess so thats something
<apw> its says "i need to refresh this info which lasts another 610s" then tries to, times out at 5, and pulls the eject cord
<cking> guess it has never been tested against IPv6
<apw> cking, its a new issue for sure, i used ipv6 for all of O pretty much without any issues, only on P is it plopping
<apw> cking, though i am unsure if it used the ipv6 dns servers correctly before, as i'd prolly never know
<apw> cking, can you remember where skype comes from ?
<cking> apw, skype comes from the pits
<cking> http://www.skype.com/intl/en-us/get-skype/on-your-computer/linux
<ogasawara> cking: were you able to get around to test installing the latest 3.4.0-2.6 kernel on your atom kit you were updating yesterday?
<cking> ogasawara, oops, completely forgot
 * cking goes to try
<apw> cking, seems its in s/w center if you wait long enough
<ogasawara> cking: http://launchpadlibrarian.net/105256001/linux-image-3.4.0-2-generic-pae_3.4.0-2.6_i386.deb
<cking> ogasawara, ta
<cking> ogasawara, just sent you the results
<cking> (email)
<ogasawara> cking: thanks
<ogasawara> cking: hrm, that's not what I was expecting
<cking> me neither
 * cking needs to grab some food - back in 15
<ogasawara> cking: when you get back, can you let me know what your /proc/cpuinfo output is?
<apw> ogasawara, it let him install it, erp
<ogasawara> apw: it appears so
<ogasawara> apw:  It had one error about missing the linux-headers package as I'm assuming he's got some DKMS package involved
<ogasawara> cking: ok if I pastebin your email?
<ogasawara> bah, I think the check is wrong
<ogasawara> +       system ("grep -q ' pae ' /proc/cpuinfo");
<ogasawara> +       if ($?) {
<bjf> ogasawara: that's what happens when you let tgardner write perl code
<ogasawara>        -q, --quiet, --silent
<ogasawara>               Quiet;  do  not  write  anything to standard output.  Exit immediately with zero status if any match is found, even if an
<ogasawara>               error was detected.  Also see the -s or --no-messages option.  (-q is specified by POSIX.)
<tgardner> ogasawara, hmm, I ran this snippet by hand. maybe the -q option is hosing things
<ogasawara> tgardner: I think our if ($?) is wrong as $? is 0
<tgardner> ogasawara, maybe it should be system ("grep ' pae ' /proc/cpuinfo > /dev/null")
<ogasawara> tgardner: but then I'm baffled as to why it would have worked with ppisati's testing
<tgardner> yeah, me too
<tgardner> apw, push your virtual -> generic patches before you go on holiday
<apw> tgardner, ack on my list, first ... will do
<tgardner> or gimme a branch and I can finish 'em up
<apw> one or t'other indeed
<tgardner> bjf, can you help ogasawara sort out this perl shit since I'm clearly incompetent ?
<ogasawara> tgardner: I don't think we need to change the grep options, just the check of $?
<apw> ogasawara, it may make sense to just read it in perl
<apw> open(FOO, "<xxx>") || die "broken"
<apw> while (<FOO>) {
<tgardner> ogasawara, apw does know perl pretty well :)
<apw>  if ($_ =~ / pae /)  {
<apw>    $found = 1;
<apw>    last;
<apw> }
<apw> close(FOO);
<apw> something like that
<ogasawara> apw: yah, I'll give that a go.  something is obviously wrong because when I think about it now, if colin's test passed, then mine should have failed.
<apw> fair point
<cking> that makes sense
<ogasawara> apw: I can probably test all the scenarios here myself by giving it some bogus check like =~ / paefoo / for one test
 * apw gets close to completing his recovery ... phew ... my backups appear to work
<apw> ogasawara, yep indeed so
<cking> apw, how much data do you need to restore?!
<apw> or making it use /tmp/cpuinfo when testing
<ogasawara> yep
<apw> and copy the file off of ckings machine
 * cking sends ogasawara /proc/cpuinfo
<ogasawara> cking: thanks
<bjf> perl -lane 'if ($_ =~ / pae /) { exit(0); } else { exit(-1); }' /proc/cpuinfo
<bjf> something like that
<cking> hold on, why are we looking at /proc/cpuinfo - weren't we looking at uname -i or something like that?
<tgardner> cking, we're looking for the PAE flag
<ogasawara> cking: uname -i is the initial check
<ogasawara> cking: +$arch = `uname -i`;
<ogasawara> +if ($arch =~ m/86/) {
<cking> bother - my N270 is pae capable
<ogasawara> cking: oh
<cking> so, it wasn't a valid test
<cking> let me re-run it on the virtual box image
 * cking slaps himself
<ogasawara> heh, so does anyone have a non-pae machine?
<cking> my virtual box install is non-pae, so I can test that right now
<cking> ..once it eventually boots...
<herton> apw, do you think a patch for precise is coming, or for tomorrow? (the one from discussion yesterday) I was thinking in taking a swap day tomorrow, and bjf is taking a half day, so I may need to be around.
<apw> herton, there is a patch available already, which i will email out today, the tip i built for them is now in your tree (the hyperv1 tag) for precise.  i don't think i needs rushing out before monday, we can decide then if we want to spin just that or to let it run in the next sru round
<apw> i am leaning to the latter at this moment
<cking> yay it works!
<cking> Unpacking linux-image-3.4.0-2-generic-pae (from linux-image-3.4.0-2-generic-pae_3.4.0-2.6_i386.deb) ...
<cking> This kernel does not support a non-PAE CPU.
<cking> dpkg: error processing linux-image-3.4.0-2-generic-pae_3.4.0-2.6_i386.deb (--install):
<cking>  subprocess new pre-installation script returned error exit status 1
<cking> cat /proc/cpuinfo | grep pae --> empty
<bjf> herton, i'm still pushing on QA and cert. lets shoot for early next week
<ogasawara> cking: thanks!
 * ogasawara goes to upload meta
<herton> apw, bjf, ack, I'm going to be off tomorrow then, but will be around on irc
<tgardner> herton, dude, if you're taking a day off then get the hell away from your computer.
<ogasawara> herton: yah, I think you should disconnect completely
<herton> hehe, actually I'm going to be away on the weekend, going to watch a rally with some friends in south of brazil
<cking> a day off is a day off
<herton> but preparing for the travel tomorrow
<tgardner> herton, and takes more then 30 minutes ?
<ogasawara> I do understand the separation anxiety though, but that all goes away once you have a margarita in your hand
<tgardner> oh, now there is a plan
<herton> tgardner, it's 600km far away, but want to rest before this, and I'll go tomorrow afternoon/night
<tgardner> herton, thats a fair drive even by Montana standards
<cking> that's like halfway across the UK
<herton> ops, it's 500km actually, but yes, you know, living in a large country, everything is far...
<bjf> here's one that actually works: perl -e 'while(<>) { if ($_ =~ / pae /) { exit(0); } } exit(-1); ' < /proc/cpuinfo
<apw> does exiting a negative number have meaning ?
<bjf> apw, doesn't that set the exit status? for checking $?
<apw> as far as i know yes, but exit status is only 8 bits and only positive isn't it?
<brendand> i've got one system here that after it installs it seems the wireless is soft blocked
<brendand> seems strange
<brendand> i don't *think* it was happening with the released version of precise
<brendand> checking now
 * cking wonders what soft blocked means in terms of wireless
<bjf> apw, ] echo $?
<bjf> 255
<brendand> cking, yeah - it's not possible to do that except via rfkill itself, right?
<bjf> apw, so 0 or non-zero
<brendand> cking, if i 'rfkill unblock 1 (wifi)' then it of course works again
<brendand> cking, i'm assuming we haven't gone and certified it where you need to run rfkill to get the wifi to work
<cking> assume nothing in this world
<cking> bjf, I suspect the 255 the bottom 8 bits returned from WEXITSTATUS() on an exit of -1
<brendand> cking - is this a bug we've got before? where a system has the wireless soft-blocked by default?
<cking> brendand, no idea, sorry 
<greearb> just out of curiosity, any reason CONFIG_IP_MROUTE_MULTIPLE_TABLES isn't enabled by default?  It's rarely used (cept by me, probably), but it seems most other advanced networking stuff is enabled....
<apw> greearb, i think it was marked as dangerous or something when we last looked
<greearb> ok, it shouldn't be that dangerous now...it has been reasonably well tested by us, of nothing else.
<greearb> it is rarely used, however...and I need to change some other things when rebuilding the kernel for my own purposes, so no big deal if it's left disabled...just wanted to make sure it wasn't an oversight.
<dileks> apw: had a look into lp #988183 ?
<ubot2> Launchpad bug 988183 in network-manager "Logs full with "ICMPv6 RA: ndisc_router_discovery() failed to add default route"" [High,In progress] https://launchpad.net/bugs/988183
<dileks> its not only spamming log-files, periodic dis-/re-connects (wlan, IPv6)
 * cking now got reliably ecryptfs encryption benchmarks.. -> /me --> EOD
<tyhicks> cking: Nice!
<cking> had to turn off the turbo MSR to make it reliable + consistent
 * henrix --> EOD
<apw> tgardner-lunch, ok gomeisa has been sucked off to tangerine in theory, so we should be safe against loss
<tgardner> apw, ack
<apw> tgardner, ok this -virtual thing has a wrinkle, the udebs seem to be being built from the main kernel image package contents, which aren't there ... cause they are in the other package
<tgardner> apw, want me to clean it up? you should be getting done for the day
<apw>   dpkg -x $(ls ../linux-image-$i\_3.4.0-2.7~virtualgenericmerge201205171935_i386.deb) \
<apw> tgardner, so that bit there likely needs to be taught to extract both halves
<tgardner> apw, right
 * ogasawara lunch
<tgardner> simple enough
<tgardner> apw, push a branch and I can finish it up. you're outta here tomorrow, right ?
<apw> tgardner, yeah, probabally should finish rebuilding this machine, i am pushing waht i have now to my repo; will send you a link in pm when t'is done
<apw> tgardner, ^^
<tgardner> apw, drop an email if I'm gone. gonna bail here in a bit for awhile.
<apw> tgardner, in pm now
 * tgardner -> EOD
#ubuntu-kernel 2012-05-18
<hrw> hi
<hrw> linux/quantal contains debian/stamps/ directory but /usr/src/linux-3.4.0/debian/ from linux-source-3.4.0 does not
<hrw> which patch will be more acceptable:
<hrw> 1. add 'install -d $(stampdir)'
<hrw> 2. add 'debian/stamps/' into linux-source-3.4.0
<hrw> ?
<hrw> reported as bug 1001172
<ubot2> Launchpad bug 1001172 in linux "linux-source-3.4.0 does not contains debian/stamps/ directory" [Undecided,New] https://launchpad.net/bugs/1001172
<tgardner> arges, linux-firmware-nonfree accepted into lucid and precise with the Beceem wimax firmware.
<arges> tgardner, great. do I need to talk to the archive admins or do verification now?
<tgardner> arges, nope, its a done deal
<arges> tgardner, cool! thanks a ton
<ogasawara> tgardner: can you refresh my memory, I thought there was a script which would help update the lts-backport-<release> branch.  what was it called again?
<tgardner> ogasawara, I started the quantal one and pushed to precise
<tgardner> looking...
<henrix> ogasawara: are you looking for debian.oneiric/etc/update-from-oneiric-master ?
<tgardner> ogasawara, ubuntu-precise/debian.quantal/etc/update-from-quantal-master in the lts-backport-quantal branch
<ogasawara> tgardner, henrix: thanks
<ogasawara> tgardner: was thinking that an additional step to uploading a new kernel to Quantal would be to run that script and shove the resulting backport kernel into the PPA bryceh pointed to
<tgardner> ogasawara, I'm thinking Andy's daily build scripts will pick that up.
<ogasawara> tgardner: ah, that's even better
<tgardner> ogasawara, though I don't think we should turn on that machinery until the meta package and flavour carnage has settled.
<cking> tyhicks, ping
<tgardner> ogasawara, I'm finishing up with the quantal kernel mess, then I'll do the meta package. should have it all done today.
<ogasawara> tgardner: ack
<tyhicks> cking: hey - just picking my chin up off the floor after reading your email :)
<cking> tyhicks, we could restructure the code so that the fp flags are stashed and restored outside the loop, but I think before I go any further I will contact intel
<tyhicks> cking: I had just cracked open the code, so I don't have a good feeling for what is best yet
<tyhicks> cking: Contacting intel is probably the thing to do though
<cking> tyhicks, yep, will do, and while I am waiting for a response I will tweak the code to see if I can "improve" things ;-)
<tyhicks> cking: When you say "outside of the loop", which function are you referring to?
<tyhicks> cking: nvm, I see it in aes_encrypt() now
<cking> tyhicks, crypto_cbc_encrypt() iterates over the data in 16 byte blocks, and each block wastes cycles doing the kernel_fpu_begin/end calls :-(
<cking> it's just a problem to do with the way it has been abstracted
<tyhicks> cking: I'm following along now. :) Nice find!
<cking> just needed a little bit of digging and some accurate instrumentation
<cking> tyhicks, I expect the userspace version of the code rocks because it does not have to mess around with the fpu state, hence the benchmarks on the code look good but nobody has instrumented it in-kernel
<tyhicks> cking: Ack - I think you're right
<arges> cking, this was it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1000913
<ubot2> Launchpad bug 1000913 in linux "K43SA hangs on suspend" [Medium,Incomplete]
 * ogasawara back in 20
<tgardner> ogasawara, just sent an email explaining Quantal meta package carnage. please review.
<ogasawara> tgardner: ack
 * tgardner goes back to working on highbank and lowlatency
 * ogasawara head just exploaded with meta packages
<tgardner> ogasawara, but they are so orthogonal now
<ogra_> the heads ? or the explosions ?
<cking> tyhicks, it looks like restructuring the code means I add extra overhead to the non arch specific generic code, which is not going to be acceptable. I will see what Intel say 
<tyhicks> cking: I'm a bit confused because some of aesni-intel_glue.c seems to be doing the right thing by putting the fpu restore on the outside of the loop
<tyhicks> cking: cbc_encrypt(), for example
 * cking looks
<tyhicks> cking: I'm wondering if eCryptfs flows through a different path than dm-crypt, which may be why dm-crypt benefits from aes-ni
<cking> tyhicks, aesni-intel_glue.c saves the fp state, does 16 bytes and restores the fp state
<tyhicks> cking: I agree regarding aes_encrypt() in aesni-intel_glue.c, but that doesn't look to be true for cbc_encrypt() in aesni-intel_glue.c
<tyhicks> cking: note that there are different drivers in aesni-intel_glue.c
<cking> tyhicks, OK - I can see what you are getting at, I will re-examine this
<cking> twisty maze of callbacks :-/
<cking> [  509.765572] Call Trace:
<cking> [  509.765574]  [<ffffffffa05e214c>] aes_encrypt+0x2c/0xf0 [aesni_intel]
<cking> [  509.765577]  [<ffffffff812e80ef>] crypto_cbc_encrypt+0xcf/0x190
<cking> [  509.765579]  [<ffffffffa05e2120>] ? aes_decrypt+0xf0/0xf0 [aesni_intel]
<cking> [  509.765582]  [<ffffffff8126eed3>] encrypt_scatterlist+0xd3/0x1b0
<cking> [  509.765585]  [<ffffffff8126f643>] ecryptfs_encrypt_extent+0x103/0x190
<cking> [  509.765588]  [<ffffffff8126fc5d>] ecryptfs_encrypt_page+0xcd/0x190
<cking> [  509.765591]  [<ffffffff8126d962>] ecryptfs_writepage+0x32/0x90
<sforshee> ogasawara, I'm going to send a patch to disable CONFIG_B43_BCMA_EXTRA in quantal as it causes conflicts between b43 and brcmsmac. Do I also need to add a check in the enforcer?
<ogasawara> sforshee: that'd be good so we don't accidentally flip it back on.  it also ensure's it get annotated in our config review for why it doesn't adhere to policy.
<sforshee> ogasawara, ack. Guess I get to learn how to write enforcer rules :)
<tyhicks> cking: Ok, so the question is how to get the crypto api to give us the "__driver-cbc-aes-aesni" driver rather than the "aes-aesni" driver
<cking> tyhicks, that's what I'm trying to figure out right now, it's most curious
<tyhicks> cking: The "aes-aesni" driver has a higher priority value, so it would obviously be selected first... but is it supposed to then use the "__driver-cbc-aes-aesni" driver if aes with cbc is used? Hmm...
<cking> looks iffy to me
<tgardner> tyhicks, cking: isn't some of this link order dependent? the most CPU specific drivers are supposed to register first.
<tgardner> IIRC thats why we started building them in
<tyhicks> tgardner: Yeah, that's right. But the highest priority driver for the aesni-intel code does the wrong thing. :)
<tyhicks> tgardner: Then there's a lower priority, generic software-based driver that is next in the priority list. Then, there's *another* aesni-intel driver that is priority 0, but it does the right thing.
<cking> unless I shove a load of debug in, it really is unclear to me at the moment why it is doing the wrong thing
<tgardner> I assume you've looked at how dm-crypt registers ? (just flapping my gums here)
<cking> that's a worthy point to pursue
<tyhicks> tgardner: It has been a while since I've looked at that. But the way that one registers is just by registering the "cbc(aes)" driver. The crypto api is supposed to be smart enough to pick the best option.
<tgardner> right,, thats what I remember
<cking> evidently it isn't
<tyhicks> cking: From your analysis, what it supposed to be the best option may just be poorly written :)
<tyhicks> (or just a victim of a code refactoring that screwed things up)
<cking> indeed, it's getting late in my day and I'm still foggy a bit from jet lag, so I will focus on this next week 
<cking> i'm sure it be very evident once I work through the code methodically
<tyhicks> cking: Understandable. I'll try to take a closer look in a couple hours. I'll email you if I come across anything useful.
<cking> cool
<cking> gotta go
<tyhicks> bye cking
 * cking -> EOW
<sforshee> ogasawara, does this look right? seems to trip the config enforcer at least
<sforshee> # Ensure CONFIG_B43_BCMA_EXTRA is disabled if CONFIG_BRCMSMAC is enabled. 
<sforshee> # Otherwise b43 and brcmsmac will overlap in the hardware they claim to 
<sforshee> # support. 
<sforshee> (!exists CONFIG_BRCMSMAC | value CONFIG_BRCMSMAC n) | \ 
<sforshee> ((value CONFIG_BRCMSMAC y | value CONFIG_BRCMSMAC m) & (value CONFIG_B43_BCMA_EXTRA n | !exists CONFIG_B43_BCMA_EXTRA)) 
 * ogasawara parses
<ogasawara> sforshee: looks correct
<sforshee> ogasawara, thanks! I'll send the patch after lunch.
<ogasawara> sforshee: ack
<hggdh> tgardner-lunch: when you are back -- I have been getting hardlocks on my laptop (precise, realtek SE wireless). Seems to be the realteck, and I have the backports-cw package installed
<hggdh> tgardner-lunch: Pete asked me to ping you, it seems you would have a more up-to-date package to test
<tgardner> hggdh, I've been runnign the Quantal kernel. seems to be working OK
 * bjf has swapped out
<hggdh> tgardner: I will upgrade to quantal, then and try. Thank you
<tgardner> sforshee, why don't we blacklist b43 instead of not building it ? It may still work well for some folks (or be their preferred option).
<tgardner> hggdh, you don't have to upgrade completely. we'll have a PPA soon from which you can pull the Quantal LTS backport kernel
<hggdh> tgardner: ack, I will wait, then. Thank you again :-)
<tgardner> hggdh, in the meantime, you could pull the linux-image deb from the archive and install it by hand to see if it works any better.
<hggdh> roj. Even better, I can check on it now
 * ogasawara lunch
<tgardner> ogasawara, I'm guilty of hoarding my bits, pull quantal master-next again
<ogasawara> tgardner: ack
<tgardner> ogasawara, also just pushed precise lts-backport-quantal. I'll finish it up next week when next you upload. waiting on a response from Michael Vogt to make sure we've not dome something we can't recover from.
<ogasawara> tgardner: ack
 * tgardner -> EOD
#ubuntu-kernel 2012-05-19
<martman> is there anyway to specify where the packages should be placed when you run the command: fakeroot debian/rules binary-headers binary-generic
#ubuntu-kernel 2012-05-20
<alexbligh> Is there a simple way to get the changesets from stock kernel 3.2 (or whatever the upstream Precise is based on) and the source package to build the Precise kernel (i.e. incl debian & debian.master directories)?
#ubuntu-kernel 2013-05-13
<ppisati> moin
<smb> morning
<ppisati> compiz is sucking ~29% of my cpu time
<ppisati> and i'm not doing anything
<infinity> ppisati: Try doing even less.
 * infinity hands ppisati a breakfast mimosa.
<ppisati> with just an open terminal and top running in it, it goes down to ~15%
<infinity> ppisati: Is mx53 included in the multiplatform kernel, or just mx6?
<infinity> ppisati: (And, if not, can it be, or does upstream only support mx6 for multiplatform?)
<ppisati> infinity: it's not supported because no one has the hw to test it, but everything is there, just a config away
<infinity> ppisati: I have the hardware to test it, and some other people who'd like me to enable it in the installer, hence the question. ;)
<infinity> ppisati: If it's as simple as flipping a CONFIG_ or two, please do, and I'll test when I get a chance.
 * apw yawns
<infinity> apw: Morning, sunshine.
<apw> i have morning and sunshine indeed
<apw> i may even get to sit outside today, and find out if my interwebs work there
<smb> You mean you actually have this sunshine thing
 * ppisati reboots
<ppisati> infinity: http://people.canonical.com/~ppisati/linux-image-3.8.0-20-generic_3.8.0-20.31~imx53_armhf.deb
<ppisati> infinity: and tell me if  it workr
<ppisati> *worked
<infinity> ppisati: I'll try to get to it this week.  Need to hook a hard drive up to my mx53 first (the last one died).
<ppisati> infinity: ack
 * ppisati goes out for an early lunch
<gema_> cking: ping
<cking> gema_, pong
<gema_> cking: we are observing some changes on the test cases
<gema_> cking: power for amd64 / i386
<gema_> cking: things seem to have improved in most of them except the idle one
<gema_> cking: I wondered if you have an explanation or theory for that
<gema_> cking: eom
<cking> gema_, I need to study the data first
<gema_> cking: ack: http://reports.qa.ubuntu.com/power/hardware/arch/i386/
<gema_> cking:  I will ask the lab guys if they've made any changes later today
<cking> gema_, surely its because 3.9 is being used now
<gema_> cking: makes sense
<cking> gema_, it's hard to tell - it is not trivial to easily spot which packages are different between runs
<gema_> cking: that's a change in utah we discussed and we should implement, list of packages and versions installed on a particular system
<gema_> cking: making a note
<cking> would me most useful, otherwise it takes a lot of effort to figure our which image was used and which packages were installed
<gema_> cking: ack
<smb> :q
<apw> henrix, yo
 * ppisati notes that the R update made skype disappear from the top bar (task bar? indicator bar? $whatever)
<apw> ppisati, from the indicator area (top right)
<ppisati> apw: yes, the systray bar
<apw> ppisati, it is there for me, with an up to date raring
<ppisati> apw: same on my laptop
<ppisati> apw: but not on my desktop...
<apw> odd indeed
<user_> im having major wireless connection drops and low power issues. AR9485 ath9k - 3.2.6kernal
<bjf> apw, is this you? https://launchpad.net/~kernel-ppa/+archive/pre-proposed
<apw> bjf, i upload things there indeed.
<bjf> apw, is that the master-next branch from our ubuntu-<series> trees?
<apw> bjf, yeah should be
<bjf> apw, so, can we get raring kernels now?
<apw> oh
<apw> hmmm
<apw> bjf, looking
<bjf> :-)
<apw> bjf, L P Q R are the only ones we have left right ?
<bjf> apw, yes
<apw> bjf, ok ... gomeisa is on the job
<bjf> apw, thanks
 * apw adds a todo item to put together a 'release checklist' for all this shit
<apw> bjf, ok they are in and should remain in for the forseeable
<apw> bjf, not that that will build for a few hours yet
<bjf> apw, good enough
<apw> they build a lot better if they hit at the normal time, 9ish UTC
<infinity> zequence: lowlatency is getting behind on SRUs again.
<infinity> apw: ^
<apw> oh that is my fault
 * apw will sort it out now
<infinity> apw: And, while we're at it, do we need to have a chat with Ben about linux-ppc SRUs, or shall we JFDI on our end?  Preference?
<apw> i guess we ought to mention it to him at least
<infinity> BenC: *poke*
<apw> :)
<BenC> infinity: aye
<infinity> BenC: Did you have a plan/commitment/urge regarding linux-ppc SRU/security rebases for raring and beyond?
 * BenC hasn't been getting any notifications of needed ppc builds
<apw> bjf, are we making bugs for linux-ppc for raring when we spin srus ?
<BenC> infinity: anyway I can get something automated so I don't have to remember to keep checking git/launchpad/archive?
<infinity> BenC: If bjf's scripts created workflow bugs for you like https://bugs.launchpad.net/kernel-sru-workflow/+bug/1177550 would you use them?
<ubot2> Launchpad bug 1177550 in Kernel SRU Workflow "linux-lowlatency: 3.8.0-20.14 -proposed tracker" [Medium,In progress]
<BenC> I can sync it today, but in the future...
<BenC> Yes, most definitely
<infinity> bjf: Can we add linux-ppc to the derivative bug magic for raring+ ?
<infinity> BenC: We might want to follow the same workflow lowlatency does (they prepare in their own PPA, and then Andy copies to the kernel PPA), since the kernel PPA is not built against updates, thus guaranteeing a clean build for security.
<infinity> BenC: (As opposed to you uploading directly to -proposed, which does build against updates)
<infinity> s/Andy copies/Andy does a source-only copy/
<apw> yep else we canot use them into -security
<BenC> Is there some better explanation of this workflowâ¦do I even need to interact with it, or is the automation able to take my git tree and handle it from there?
<infinity> We might need to explain the testing tasks, and how we plan to use them.
<infinity> We'll fiddle with that the first time we go through it. ;)
<BenC> Ok, if who ever handles low latency could point me at some bullet list of how they handle this work flow, I'll be more than happy to join inâ¦anything that makes it easier between me and your guys work
<infinity> But the initial "upload" bit would be you prepping it either in git or git and a PPA upload, and then setting "upload-to-ppa" to "Confirmed".
<BenC> Or walk me through it once :)
<infinity> (And a comment pointing at where the rebase lives, PPA or git URL)
<infinity> But the testing bit, we'll just walk you through how to use the tasks once we have a tracking bug for you on the next cycle.
<infinity> Unless bjf wants to make one for you now.
<infinity> But coaxing the bot to make just one derivative bug is hard, I believe. :P
<bjf> BenC, maybe i'm wrong but i thought we were doing that and you asked us to disable it, i see a comment that the tracking bugs for linux-ppc were not being used
<infinity> BenC: In a nutshell, though, the way we've been doing lowlatency is to mark Cert and Security invalid (the former being Canonical Cert testing, the latter is inherited from the master branch)
<infinity> BenC: And then for Verification-testing, if it has no changes beyond the rebase, just mark it done, if it has its own changes and bugs, verify those first.
<BenC> bjf: I don't believe I was ever askedâ¦and if I was, I don't believe I understood what was being asked and why :)
<infinity> BenC: And for regression-testing, some boot-testing on hardware is nice. :P
<infinity> BenC: But we'll walk through it larer.
<infinity> bjf: I think it was disabled when you started using tracking bugs for *development* releases.
<infinity> bjf: For SRUs, though, they're monumentally helpful.
<infinity> BenC: Though, that said, some sort of linux-ppc 3.9 for saucy would be neat some day.  No pressure. ;)
<BenC> I'll get that done this week too :)
<infinity> bjf: If you can do a one-off linux-ppc tracking bug for the current cycle, that would be cool, and I can walk Ben through vaguely what we do for lowlatency.
<infinity> bjf: If that's serious hassly to coax the bot into doing that properly with the right inheritance and such, just turn it on for the next cycle, please. :)
<bjf> infinity, BenC the script is updated
<BenC> Thanks
<infinity> s/serious hassly/a serious hassle/
<infinity> No idea what my fingers were doing when I typed that.
<bjf> infinity, BenC looking at creating a tracking bug by hand .. will let you know when ready
<infinity> bjf: Will it have the proper attachment/ancestry with the master bug (so security/promote tasks follow, etc), or will it be "orphaned"?
<infinity> bjf: If the latter, possibly not worth the hassle, and we can just wait for the next automagic one.
<bjf> infinity, orphaned
<infinity> Yeah, that's less cool for teaching him how it all works, then.
<infinity> We can probably just by-hand this set entirely and skip the bug.
<infinity> Less effort for you this way, too. :P
<infinity> BenC: In fact, given that there have been no drastic changes to toolchain or other rdeps in raring yet, I'm perfectly fine with you just doing a rebase and throwing it directly at the raring(-proposed) queue for this one.
<infinity> BenC: And we'll work on doing it "the SRU kernel way(tm)" for the next cycle.
<BenC> infinity: Ok, so treat it just like during development cycle for this one?
<infinity> BenC: Yeahp.
<BenC> Will do
#ubuntu-kernel 2013-05-14
<henrix> apw: yo! my irc logs say you've tried to contact me in last few days
<henrix> (i was off yesterday and friday)
<apw> henrix, heh yeah ...err
<henrix> apw: do you still remember what you wanted from me? :)
<smb> Such a long time to remember. :-P
<apw> henrix, yeah i was wondring if it was you who did the fixes for CVE-2013-3076, and if lucid being missing was deliberate or an application error
<apw> (if you can remember :)
<henrix> apw: give me a min to check...
<apw> no rush ... yawn
<henrix> apw: ah, got it. yes, i prep'ed the patchs for that CVE but not for lucid because it doesn't seem to be affected
<henrix> apw: i haven't updated the cvetracker file yet (its in my TODO) because you were messing with the CVE scripts at that time
<apw> henrix, ahh great, i am all done with them, so cool
<henrix> apw: ok, i'll update the cvetracker today then
<apw> no rush as long as it is in hand i can forget about it
<henrix> apw: yep, i'll take care of that. thanks
<smb> apw, There seems to be the unpleasant business of framebuffer replacement sticking to our heels. Or so I would read the latest comment on bug 1100386
<ubot2> Launchpad bug 1100386 in linux (Ubuntu) "Raring server installations on VMs fail to reboot after the installations" [High,Confirmed] https://launchpad.net/bugs/1100386
<apw> smb, sigh ... you had some sync patches for that didn't you ?
<apw> though i thought that they did some more upstart work to avoid that ... hmmm
<smb> apw, I had something long long time ago. But as you say I / were told that that would not be the place to do it. And I am not sure it really worked well then. 
<smb> Remember vaguely that there is not much the kernel can do when plymouth hold its clutches to the buffer
<apw> i am pretty sure i saw some upstart work from slangasek to avoid the overlap
<smb> Yeah, guess we need some investigation. Might depend on certain hw (speed) too.  Unfortunately I am using Xen most of the time and that does not "suffer" yet from a drm drivers support
<apw> smb, i cannot see these changes in upstart, but they could be somewhere else
<smb> apw, Probably best to try to get in touch with slangasek 
<apw> smb, ok the work was from tjaalton and at least in part in plymouth
<apw> smb, it was also only in -updates
<apw> so it missed the release
<smb> apw, Ah. Doh! So probably have to ask for trying ssh in and updatign
<tjaalton> hmm it was only on desktop, needed changes to both plymouth & lightdm
<smb> plymouth is in server (sadly imo)
<smb> but not lightdm
<tjaalton> so it's not the same race
<smb> As far as we saw (and if I remember correctly) it is something with plymouth rendering that dotty screen while kernel modeset tries to replace the efi fb with cirrusfb
 * cking reboots
<apw> bah ... it seems that one need to charge laptop batteries, go figure
 * apw is getting issues with 'dig' showing format errors when everything else works with its results
<apw> apw@agent57:~$ dig www.google.com
<apw> ;; Got bad packet: FORMERR
<apw> 139 bytes
<apw> anyone else seen it?
<ogra_> i get a proper reply here
<cking> apw, works ok for me
<apw> always works the first time, and not the 'rest', so someone is caching it
<apw> i think it is my BT home hub ... hmmm
<hrw> hi
<hrw> bug 1178847 - does someone has it with other devices?
<ubot2> Launchpad bug 1178847 in gcc-4.8 (Ubuntu) "chromeos 3.8 kernel fails to boot when compiled with gcc-4.8" [Undecided,Confirmed] https://launchpad.net/bugs/1178847
 * henrix -> lunch
<psivaa> hello, bug 1179509 is impacting the daily smoke tests, would be helpful for some feedback on it. i.e. any more logs needed etc,
<ubot2> Launchpad bug 1179509 in linux (Ubuntu) "'unregister_netdevice: waiting for lo to become free. Usage count = 2' is reported and causing kernel hang when floodlight tests are run using utah" [Undecided,Confirmed] https://launchpad.net/bugs/1179509
<slangasek> smb, apw: there have been no changes to plymouth regarding fb driver replacement races.  I still think it's a kernel bug that something from userspace having the fb open can break the kernel's fb replacement
<slangasek> and I don't think we can ever reliably solve this from the userspace side
<apw> slangasek, there is a change in plymouth that adds a new event which i htink is specifically to allow us
<apw> slangasek, to ensure that we have let plymouth unsplash before X starts or something
<slangasek> that has nothing to do with the bug you're talking about
<apw> i thought that was to ensure we closed the DRM driver before we opened it again
<slangasek> I know about the new event in plymouth, I helped tjaalton implement it - that's entirely to do with a race where lightdm can start before plymouth has shown its splash screen, and is unrelated to the kernel drivers
<apw> that either is going to fix most of it, or maybe allow the fixes that smb was trying to do, to work
<slangasek> no
<apw> slangasek, sounds liek there is some confusion and i would like (when not in sessions) to get you, smb, and me together
<apw> as i think smb had a handle on the main issue, which is frambuffer rippage, but we needed plymouth to let go
<smb> slangasek, apw ack would be a bit to much to follow
<apw> and i think plymouth may be guanreteed to do so now or something
<smb> In my memory I had something that waited till the fb resource in the kernel would be free but that would not happen until userspace (plymouth) released (closed) it
<apw> smb, right ... i think it was not waiting, just doing it, but if you made it do it, then it just sticks
<ppisati> FYI: just came out of the X session, and got to know that there'll be an S omap4 desktop img, thus we need to keep the Q/omap4 kernel around (as we did in R)
<ppisati> rtg_: ^
<rtg_> ppisati, is that just a pocket copy from Quantal ?
<ppisati> rtg_: right
<rtg_> ppisati, nm, just read for content
 * rtg_ -> lunch
<ara> ogasawara, sorry, the lag was terrible, so our questions came like 5 minutes later :D
<ara> ogasawara, I asked about the 12.04.3 HWE stack, is that happening?
<apw> ppisati, rtg_, for completeness the omap4 will be so far behind, that X will be doing a h/w enablement stack of old bits for the omap install ... this will likely make it break more :)
<ara> there was some conversations about keeping the same stack as in 12.04.2
<ppisati> ...
<rtg_> apw, I wonder why we are bothering with the omap4 desktop image ?
<bjf> ara, yes
<apw> i think there was some new generation intel stuff which needed it at a minimumm
<ogasawara> ara: yes, we will have a 12.04.3 enablement stack using the kernel from 13.04
<bjf> ara, 12.04.3 will have the raring kernel
<ppisati> perhaps you missed it in the foudnation channel but...
<ara> thanks
<ara> the lag was terrible :)
<apw> rtg_, cause it is our only arm desktop image
<ppisati> 21:14 < ppisati> AFA arm is concerned, 3.11 is way better if we want to ad exynos5 support to -generic
<ara> so our questions came in when the session had already finished
<ppisati> *add
<ppisati> ogasawara: ^
<apw> ppisati, yeah, newer is pretty much always better for us
<apw> all round
<ogasawara> ara: ah shoot, will have to remember the lag in the next meeting
<ppisati> in 3,10 we can have as a separate flavour, but there're a lot of bits missing
<ogasawara> ppisati: ack, I'm in favor of 3.11 myself
<ppisati> just FYI
<apw> ogasawara, the lag is very very variable, i find if you reload anyhow, it gets pretty near instant
<apw> having done notes for a number of sessions i cirtainly wasn't more than seconds behind
<apw> it may of course depend on where the originator of the channel is physically 
 * ppisati gets some food
<apw> when cjwatson was doing them i had good lag, but then we are relativly proximate in the world
 * cking pops his kids to bed
<cjwatson> I have no intuition on what it depends on
<cjwatson> I don't think it can be mainly bandwidth since I have ridiculously little of it
<cjwatson> but I suppose there could be some kind of spiralling latency effect
<apw> yeah
 * rtg_ -> EOD
<bjf> jsalisbury, can we mark bug 1089818 Fix Released ?
<ubot2> Launchpad bug 1089818 in linux (Ubuntu) "kernel crash when mounting encrypted (device mapped) ext4 partition" [High,Fix committed] https://launchpad.net/bugs/1089818
<jsalisbury> bjf, sure 
#ubuntu-kernel 2013-05-15
<infinity> BenC: D'oh.
<BenC> infinity: ?
<infinity> BenC: Your linux-ppc ended up being based on a kernel we're dumping from -proposed.
<BenC> infinity: Errgâ¦I took the latest Ubuntu tag
<infinity> BenC: There are new ones in the PPA right now, but you may as well just wait a day and rebase tomorrow when we do another SRU round.
<BenC> Ok
<infinity> BenC: (Today's is an emergency security update, but that will be rolled into what you just rebased on tomorrow for the bigger SRU cycle)
<BenC> infinity: So are the PPA kernels tagged in ubuntu-master git?
<infinity> I'd assume so.
<infinity> 21.32
<BenC> Ok
<infinity> Or, maybe 21.32 is a mess right now.
<infinity> I'd just wait for 22.33 tomorrow, unless you're desperately keen on turning around this security fix tonight.
<infinity> BenC: The upshot is that you'll get a tracking bug this time, unless bjf messed that up. ;)
<infinity> Oh, which he did:
<infinity> It was not possible to create or handle the tracking bugs for the following packages (their tracking bugs based on this update must be handled manually):
<infinity> linux-ppc
<infinity> bjf: ^--- shankbot fails at linux-ppc tracking bugs.
<BenC> Bummer
<infinity> BenC: I'll make sure that gets fixed. :P
<infinity> BenC: Anyhow, you can either attempt to rebase on the 21.32 floating tag and get in on this emergency SRU bandwagon, or just wait a couple of days and get back into rhythm with 22.33.  Up to you.  The latter's probably less effort, if you're not desperately concerned.
<BenC> infinity: Not desperately concerned...
<infinity> BenC: Alright, I'll just poke you in a day or two when we get all our ducks in some sort of row, then.
<BenC> infinity: Works for me, thanks
<lag> apw: ogasawara: Damn lag!
<cking> smb, perhaps c902ce1bfb40d8b049bd2319b388b4b68b04bc27 addresses that  bug
<smb> cking, Hm, yeah. Sounds suspiciously familiar...
<Laney> is bug #1157880 on somebody's radar?
<ubot2> Launchpad bug 1157880 in bcmwl (Ubuntu) "bcmwl-kernel-source 6.20.155.1+bdcom-0ubuntu6: bcmwl kernel module failed to build on kernel 3.9 [wl_cfg80211.c:2025:3: error: too few arguments to function âcfg80211_put_bssâ]" [Undecided,Confirmed] https://launchpad.net/bugs/1157880
<infinity> Laney: tseliot, perhaps?
<infinity> HAH
<infinity> TIMING
<Laney> EXCELLENT
<Laney> I did try to tab complete him at the time
 * Laney gives a bug #1157880 shaped cookie to tseliot
<ubot2> Launchpad bug 1157880 in bcmwl (Ubuntu) "bcmwl-kernel-source 6.20.155.1+bdcom-0ubuntu6: bcmwl kernel module failed to build on kernel 3.9 [wl_cfg80211.c:2025:3: error: too few arguments to function âcfg80211_put_bssâ]" [Undecided,Confirmed] https://launchpad.net/bugs/1157880
<tseliot> :)
<tseliot> Laney: right, it was on my todo list. I already have a patch for that
<infinity> tseliot: Dude, you joined the channel literally two or three seconds after I invoked your name.  It was creepy.
<tseliot> infinity: hehe :)
<Laney> he said it five times while facing a mirror
<tseliot> it usually works that way ;)
<tseliot> apw: have you ever tried bcmwl 6.30.223.30?
<apw> hmm probabally not, brcmsmac has been pretty good for me
<apw> tseliot, tseliot oh it isn't in the archive, where is it
<tseliot> apw: here (it works with kernels up to 3.8 for now) https://launchpad.net/~albertomilone/+archive/broadcom
<tseliot> apw: or you can get one that should work with 3.9 here: https://launchpad.net/~eugenesan/+archive/ppa
<rtg_> cking, can you create a bug for your raring nexus4 patch 'Enable lttng-modules-dkms to build' ?
<cking> rtg_, yup, doh, I forgot to do that
<rtg_> cking, it is for raring, right ?
<rtg_> the repo organization is a little chaotic wrt nexus4/make and nexus7/grouper
<rtg_> nexus4/mako*
<cking> rtg_, urm, well it's for the nexus4 mako, currently raring, but won't we be moving to saucy with the same kernel?
<rtg_> cking, we will, but I'm going to add lttng as part of the kernel under the ubuntu directory. see ubuntu-manta for example.
<cking> rtg_, that's going to be fun - more bloat - and will lttng work OK if it's built-in? 
<rtg_> cking, its modular, so the bloat issue is less of a problem. I'm assuming it'll work if the dkms package does.
<rtg_> cking, Q/A would like to use lttng as a standard logging method. I've added it to the saucy distro kernel.
<cking> rtg_, yup, I'm having issues with in on the nexus4 - the output seems to not work with babeltrace and I'm trying to profile it on these devices to see how expensive it is
<rtg_> cking, is the dkms package from tip on the lttng repo ?
<cking> rtg_, i've tried the default package + the tip of the lttng repo
<cking> btw, bug is 1180394
<rtg_> cking, see if you can see that same issues with the saucy distro kernel.
<cking> rtg_, so, saucy + x86 it works fine
<rtg_> cking, shit
<cking> and 3.4 + x86 it works fine, but not  3.4 nexus4 
 * cking tested x86 + saucy a couple of days ago, not sure about latest saucy kernels
<rtg_> cking, no change wrt lttng
<rtg_> only stable updates
<cking> rtg_, ok, if you are going to integrate lttng into the n4 kernel I will give it is spin to see if that fixes the babeltrace issue
<rtg_> cking, I think I'll leaving raring as is, but will build it in for saucy and newer. the touch dudes are going to stop raring development as soon as they flip the container model.
<cking> rtg_, ok - any idea when that saucy kernel will be available?
<rtg_> cking, I'm working on it today.
<cking> ok, cool, let me know when it's ready and I will get crackin' on it - I'm keen to benchmark it to see how much overhead it adds on these small ARM devices
<rtg_> cking, and whether it works at all :)
<cking> rtg, that would be a bonus ;-)
<rtg_> cking, I assume your second patch is an ABI bumper ?
<cking> rtg_, bother, yes, i overlooked that
<rtg_> cking, s'alright
 * cking wonders if this bug fix is kinda academic if the saucy kernel does the trick and that's what we will be using
<rtg_> cking, its hard to know. I've only done it for manta thus far, and have yet to try to boot it on the N10.
 * cking tempted to forget it for now unless anyone screams for it on the raring N4 kernel
<rtg_> cking, I'll get back to you when the N4 saucy kernel is ready
<cking> ack
<apw> cking, that second patch, isn't that just checking a CONFIG_* variable and therefore could we not just change the config? (for the N4 lttng)
<cking> apw, true, but it means the N4 kernel deviates from our standard Ubuntu kernels for no reason
<apw> hmmm
<cking> i just wanted to re-align it because one of the earlier patches adds in features to the makefile that is not what we normally have
<henrix> rtg_: are you rebooting gomeisa/tangerine? my session just broke and can't reconnect
<rtg_> henrix, nope
<henrix> hmmm
<rtg_> I seem to have lost my connection as well
 * rtg_ -> lunch
<zequence> Did you change the workflow for how kernel sources are updated or something?
<zequence> master is not containing the commits for the latest versions
<zequence> Seems those are in master-next instead
<zequence> hmm, wait
<zequence> The tags are there, but where are the commits (am I just being stupid?)
<henrix> sconklin__: you're probably still fixing the branches? ^^^
<sconklin__> zequence: I'm going to fix the branches today, but the CVE release from last night will never appear in the linear history for the kernels, it will only be a tag
<sconklin__> zequence: because we made the security fix on the last released kernel and not the one we had in -proposed, it's impossible to represent everything in th elinear history, including both the security release and the -proposed kernel
<zequence> sconklin__: Ok, but once you've fixed the branches, I can just pull to get the latest version, right? I'll do that tomorrow in that case (update the -lowlatency kernels)
<sconklin__> zequence: yes, and that will include the security fix
<zequence> ok, thanks
 * rtg_ -> EOD
<infinity> psivaa: *poke*
<FroMaster> I was provided a VMware VM that has Ubuntu 12.04.1 LTS as its base and kernel 3.2.0-30-generic. VMware only provided VMware-Tools for 3.2.0-23/3.2.0-29 not the one I have. The VM is an appliance and thus has unnecessary components removed. Trying to get the Kernel-headers & build-essentials is not possible. I'm trying to find the difference between 3.2.0-30-generic & 3.2.0-29-generic to 
<FroMaster> see if I can upgrade the kernel and apply the vmware-tools packages via apt-get. 
<rsalveti> apw: pushed flash-kernel support for mako, so we can enable that at the kernel package already
<tyrog> Hi fellaz. Is there a fix for HDMI audio not working coming for Ubuntu 13.04? thanks
<infinity> tyrog: We've had a couple of emergency security fixes get in the way of pushing that out, but the fix will be in the next SRU kernel (landing in -proposed todayish, and in -updates in a week or two).
<infinity> tyrog: Assuming your bug is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1169984
<ubot2> Launchpad bug 1169984 in linux (Ubuntu Raring) "3.8.0-18 HDMI audio regression: Either oops or opening device fails with -ENODEV" [High,Fix committed]
<tyrog> infinity: so right now with -20 the fix is not included yet?
<infinity> tyrog: It's in -20-, and backed out in -21-, and will reappear in -22-
<infinity> tyrog: The vagaries of emergency security updates trumping long QA cycles for other bugs. :/
<tyrog> infinity: But I tested -20 and I still dont have my hdmi audio in the sound menu
<tyrog> and why is it being taken out from -21?
<infinity> tyrog: Then you might, potentially, have a different bug.  Do feel free to file one ('ubuntu-bug linux') and include as much info as you can, including what you've tested.
<infinity> tyrog: -21 is -19 with exactly one small patch on top, urgent security release.  -20 was never released (as in, didn't pass QA and other such things yet), so we couldn't base -21 on -20.
<tyrog> infinity: From what I've seen, it will go directly from 19 to 21 for people without proposed right?
<infinity> tyrog: Right.
<infinity> tyrog: If you're okay with running -proposed kernels, -22 should land today/tomorrow, and will basically be a merge of -20 and -21.
<tyrog> good, thanks :)
<ohsix> what's the small patch/bug?
#ubuntu-kernel 2013-05-16
<dape8708> hello
<dape8708> anyone ever seen these with ipv6 traffic over a gre tunnel? http://i.imgur.com/Tx5DFIH.jpg http://i.imgur.com/HXDJybV.jpg
<robert_ancell> Hi, I was wondering if anyone is planning on maintaining the LTT-ng userspace packages in Ubuntu? We're probably going to take a dependency on them for Mir, so will have to do a MIR. Want to check if someone else is planning on doing that
<infinity> robert_ancell: (Note that rtg probably won't be around for a few hours, at least, and he was the one who was keen enough on lttng to include the kernel module in the saucy kernel)
<robert_ancell> infinity, ok, I'll resort to email :)
<psivaa> infinity: hello
<infinity> psivaa: Hey, I've long since forgotten why I pinged you.  Was probably about helping to test the emergency SRU kernels, but the security team ended up smoketesting the lot for me.
<psivaa> infinity: ok, i saw raring regression testing for  -21.32 already done. thanking them :)
<psivaa> infinity: btw, you could also ping plars for any urgent regression testing, one of us will pick them up depending on the timing
<infinity> psivaa: Sure.  In this case, it was literally a 3-char patch and the effect of it was fairly obvious, so we just did some ghetto boot smoketesting of all the images, and verified the exploit no longer worked.
<psivaa> infinity: ack
<plars> infinity, psivaa: I looked yesterday at all the ones that were marked ready for us yesterday afternoon, did a lucid sru one but that's the only one I saw at the time... was this something that came in since I guess?
<psivaa> plars: yea QA regression testing tasks were not marked confirmed for those raring and lts kernels but the kernels were in -proposed
<apw> what a thoroughly misserable morning i am having
<apw> it has taken me about 3/4 of a hour to fix my network ...
<ogra_> as long as your coffee machine isnt network depending thats still ok i'd say
<apw> ogra_, thankfully not!
<ppisati> apw: i can hear you, can you hear me?
<diwic> At what point will saucy switch from 3.9 to 3.10 ?
<rtg_> diwic, probably not for a couple of -rc releases.
<diwic> rtg_, so around rc4 - rc6 somewhere? I don't have an immediate need, just curious.
<ogra_> who cares anyway ... the important 13.10 arches are stuck at 3.2 or 3.5 :P
<rtg_> diwic, whenever it seems stable enough that it doesn't kill any kittens
<diwic> ogra_, heh, I have quite a few "fix committed" bugs I want to close as "fix released" which I can do when we go to 3.10, so that's the reason :-)
<ogra_> :)
<diwic> rtg_, can't we sandbox the kittens? They like pooping there.
<diwic> or in our garden, sigh
 * diwic has no idea where this analogy will lead.
<rtg_> I've created an unstable branch in the saucy repo so you can see what I'm doing.
<diwic> rtg_, ack
<plars> bjf: psivaa is working with the saucy jobs and getting a kernel mismatch between what's on the netboot iso and the kernel version, psivaa: can you give him the exact error?
<plars> he told cobbler to update right before, but maybe just bad timing?
<psivaa> plars: bjf: 'No kernel modules were found. This is probably due to a mismatch between the kernel version used by this version of the installer and the kernel version available in the archive' is the message
<psivaa> this i used to get in iso installation when a new kernel version being updated
<tyrog> Hi, is the kernel -22 arriving on proposed today?
<bjf> psivaa, when i got that before i bugged retoaded to re-sync the cobbler isos
<bjf> tyrog, that's the plan though they may not actually reach -proposed until tomorrow depending on how quickly everything builds
<tyrog> bjf: good, thanks
<psivaa> bjf: ok, I updated the cobbler iso's though. I'll ping retoaded about it, thanks
<tyrog> bjf: it comes with the fix for hdmi audio right?
<bjf> tyrog, correct
<zequence> New but reports out for the SRUs, ABI bumbs, but no new ones for lowlatency. Since lowlatency SRU bug reports aren't versioned, I'm thinking I can just use the ones that exist, even if they were based on the previous version
<apw> bjf, ^^ ?
<rsalveti> apw: rtg_: so, tested the manta kernel and it didn't work =\
<rsalveti> 2 issues, one is that our config, even when used with the default android kernel as part of the android build system, breaks adb
<rtg_> rsalveti, do you know what config is breaking adb ?
<rsalveti> and the second one is that building the exactly the same kernel without any extra patch, with the original config, is already enough to get a broken system, don't know why
<rsalveti> rtg_: not yet, the diff is quite big
<apw> rtg_, is manta building with v4.8 ?
<rtg_> 4.7 I think
<rsalveti> I was cross building with 4.7 here
<apw> not that then
<rsalveti> but it seems we got a compiler or something related with that, because even when I build the original tree with the original config but with our gcc it's already enough to have a broken kernel
<rsalveti> it keeps rebooting after loading the shell
<rtg_> rsalveti, what compiler does android use ?
<rsalveti> the weird part is that there's no module at all
<rsalveti> so not sure if there's a binary complaining about something
<rsalveti> pre-built 4.6
<rsalveti> arm/arm-eabi-4.6/bin/arm-eabi-
<bjf> zequence, we generated new bugs for the master kernels, the bot will generate new bugs for the derivitives as well at what it determines the appropriate time. you may choose to use the old bugs or the new ones, it's your call.
<rtg_> rsalveti, when you say original tree, are you referring to the stock cyanogenmod repo ?
<zequence> bjf: ok, thanks
<rsalveti> rtg_: yeah, the one we were using before available at phablet.u.c, which you guys used as base
<rtg_> rsalveti, and that clearly works with gcc-4.6, but not gcc-4.7 or higher ?
<ogra_> did you try with the 4.6-armhf cross compiler too ?
<rsalveti> rtg_: just tested with 4.7, I'm now cross building it with our gcc-4.6 to see
<ogra_> ah
<ogra_> :)
<rsalveti> right :-)
<rsalveti> need to reboot first, going back to 3.8 as 3.9 is kind of broken regarding my iwlwifi driver
<rsalveti> http://paste.ubuntu.com/5670944/
<rsalveti> not sure if it's the firmware though
<rsalveti> brb
<ogra_> G+ seems to be full of poeple having issues with 3.9 and wlan
<ogra_> (on saucy)
<rtg_> ogra_, iwlwifi, or wlan in general ?
<ogra_> dunno, i just noticed several peole moaning about broken wifi 
<ogra_> since a day or two
<rsalveti> yeah, 3.8 is way more stable regarding wifi =\
<rsalveti> it was kind of locking my kernel at every firmware flush
<JayF> I'm running a set of Lucid boxes with the linux-lts-backport-oneiric kernels (linux-image-3.0.0-32-server) installed and running. The recent local root CVE seems like it should impact that kernel. I was wondering 1) If it's vulnerable (I think yes?) and if so, 2) Is a security updat scheduled for it.
<rtg_> bjf, ^^
<JayF> Thanks :)
<bjf> jjohansen, ^ ?
<jjohansen> JayF: Oneiric is end of life and no updates are coming
<JayF> Then can you pull the vulnerable kernel from the Lucid repo to prevent people from getting compromised via it? 
<jjohansen> JayF: I don't believe oneiric is vulnerable, the git log shows us skipping b0a873ebb
<bjf> jjohansen, should have caught that
<JayF> jjohansen: I'm explicitly running https://launchpad.net/ubuntu/lucid/+package/linux-image-3.0.0-32-server -- the backported lucid version
<JayF> so if it's not vulnerable, that's great!
<bjf> JayF, as jjohansen pointed out, we are no longer supporting oneiric nor lts-backport-oneiric. you might consider upgrading.
<jjohansen> JayF: hrmm, actually I am wrong it looks like it is vulnerable
<jjohansen> I miss read the log
<JayF> Thanks for the update. I'll either have to roll my own kernel now or package a couple of drivers for the standard lucid kernel. Shouldn't be too rough. Thanks for the info.
<henrix> apw: who do i have to pay a beer in order to have the 3.8.y-queue/review branches being built daily, as we do for the 3.5 branches?
<jjohansen> JayF: we don't generally pull eol packages from the archive, there are only a few exceptional cases where we do that
<JayF> jjohansen: Just worrisome to know there's a vulnerable kernel image-type (i.e., the lts-backport-oneiric will be dead forever) in the main repos for a still-supported LTS :/. I worry about people getting locally rooted over it, but you guys do all the work and thereby get to make decisions about it ;)
<JayF> ty for the help
<rtg_> jjohansen, is there a way to emit an motd in Lucid if you're running an obsolete kernel ? we should be messaging this kind of loudly. ogasawara has suggested that we're gonna do that for precise when 14.01.1 is released.
<jjohansen> JayF: yes it is a problem, and we have it with several other desktop applications still in the lucid archive. The options where weighed and a choice made (not my choice)
<rtg_> 14.04.1 (doh!)
<jjohansen> rtg_: it is possible, our current planning requires some changes
<rtg_> jjohansen, perhaps lucid would be good practice
<jjohansen> I will discuss it with jdstrand
<JayF> That sounds pretty awesome. #ubuntu-kernel++
 * rtg_ -> lunch
<apw> henrix, heh ... i'll have a look, i always need more beer
<henrix> apw: :)
<henrix> apw: thanks. i'm not sure if you set it up for the 3.5 or herton did
<apw> henrix, i think i did some of it at least :)
<apw> henrix, ok, seems to be pretty easy ... initial review branch building now
<henrix> apw: cool, thanks.
<JayF> jjohansen: would you guys accept a patch to add the security fix to that backported kernel? I'm going to do it in my env anyway, and I'm more than willing to contribute it back if it would make it to the repo.
<jjohansen> JayF: generally speaking once its eol we don't accept new patches for a package
<jjohansen> JayF: it should be possible for you to set up a ppa and build/publish your kernel in there
<JayF> Thanks. I'll look into doing that.
<bguthro> Any i915 experts in the house? I've tried the intel-gfx list, but have never had any luck getting any response to any of my questions
 * rtg_ -> EOD
<JayF> bjf: jjohansen: Unless I'm reading the kernel source wrong, it looks like linux-lts-backport-oneiric latest is *not* vulnerable.
<JayF> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8176cced706b5e5d15887584150764894e94e02f should be the fixing commit, and the offending line is already updated in the source
<jjohansen> JayF: the oneiric kernel contain commit b0a873ebbf87bf38bf70b5e39a7cadc96099fa13 which is the commit fingered as introducing the bug
<JayF> jjohansen: my comment was that it appears to also have the commit fixing the bug
<jjohansen> hah, so it does
<jjohansen> I didn't even bother looking for that
<JayF> Cool. Glad to have confirmation :).
<jjohansen> JayF: wait, it shows up when I do git show on my tree but not in the log
<JayF> jjohansen: I just unpacked the kernel source tarball I got from http://packages.ubuntu.com/source/lucid/linux-lts-backport-oneiric went to the function in question, and checked
<JayF> and it's showing the u64 vs the int
<JayF> line 5433 in kernel/event/core.c in that copy vs line 5331 in the kernel git log... but the line and function are idential and appears to be nonvulnerable
<jjohansen> JayF: I'll take your word for it, its possible my copy of the tree didn't get the last update. and the repo has been removed
<jjohansen> that is the oneirc repo
<jjohansen> the lucid repo has the backport kernel but is log just shows which oneiric kernel is backported
<JayF> Cool. Well I'll let at least my twitter followers know :)
#ubuntu-kernel 2013-05-17
<jjohansen> JayF: I dug into the oneiric-lts-backport kernel and the fix is not there, I am not sure what you are seeing
<infinity> jjohansen: I'm guessing he was looking at sw_perf_event_destroy instead of perf_swevent_init?  Maybe?
<infinity> jjohansen: Yeah, he referenced line 5433, which is in the declaration of the previous function.
<infinity> JayF: ^^
<jjohansen> yeah
<bjf> smb, bug 1164739
<ubot2> Launchpad bug 1164739 in linux (Ubuntu Quantal) "Can not mount cephfs in VM from cloud image" [Medium,Fix committed] https://launchpad.net/bugs/1164739
<bjf> smb, do we need to verify it or is it trivial enough to just mark it verified ?
<bjf> smb, can you verify or have someone verify it?
<henrix> bjf: iirc smb is off today
<rtg_> bjf, try hassling james Hunt. I think he's the ceph cloud dude
<bjf> jodh, ^ ?
<jodh> bjf/rtg_: you have the wrong guy. I've never used ceph :)
<bjf> jodh, interested in learning ? :-)
<bjf> jodh, i think rtg probably meant james page
 * cking takes a short break, back in 15
<rtg_> henrix, cking: bouncing gomeisa for kernel update
<cking> rtg_, ack
<rtg_> when henrix build is done
<henrix> rtg_: can you wait 5 mins? just finishing a build
<henrix> rtg_: thanks, shouldn't take long
<henrix> rtg_: gomeisa is now free
<tseliot> apw: are you around?
<apw> tseliot, sort of, not so good today
<psivaa> bjf, just managed to saucy jobs for kernel regression tests
<psivaa> bjf, there is this, http://pastebin.ubuntu.com/5674186/ with 3.9.0-2.6 in almost all the saucy regression kernel tests.
<rtg_> jjohansen, is that your test ? ^^
<stgraber> cking: heya. You may want to s/14.10/13.10/ in your lttng blog post :)
<stgraber> (spotted by the #lttng guys)
<cking> stgraber, bah, I'm in a time machine mode again
<cking> thanks :-)
<stgraber> ;)
<bjf> psiva, let me look. i may have to update a file on my end for saucy
<psivaa> bjf: ack
<bjf> psivaa, jjohansen indeed, this looks like my issue
<psivaa> bjf: ack
<bjf> psiva, just sent out a new release email that should address this issue.
<psivaa> bjf: ack, got it. thanks
<JayF> infinity: TYVM for that update. Do you have a better link for a full patch than what I was looking at then so I can ensure my kernel is properly patched?
 * henrix -> back in 15
<rbasak> ogasawara: any objection to documenting the DKMS situation with the HWE stack on https://wiki.ubuntu.com/Kernel/LTSEnablementStack? Or would you prefer that somewhere else? It would be nice to have something to point bug reporters to.
<ogasawara> rbasak: you mean about the point I mentioned for trying to ensure we test DKMS packages against the HWE stacks
<ogasawara> rbasak: I'm leaning towards that residing somewhere else at the moment, as it's not a hardened policy/procedure
<ogasawara> rbasak: I'm thinking it'll reside in a blueprint somewhere first, just not sure which one yet
<ogasawara> rbasak: likely as a work item for me
<rbasak> ogasawara: I'm not sure. I'm prompted by a bug report for a DKMS build failure on an HWE stack. I'd just like to document that some failures are known to exist right now, and that users who don't need the HWE stack but got it by default, and who need a particular DKMS module that is failing can use the old kernel for now.
<rbasak> A bug tag might be useful too. How about hwe-dkms?
<ogasawara> rbasak: definitely a meaningful tag to use across those types of DKMS bugs would be good
<ogasawara> rbasak: hwe-dkms works for me
<ogasawara> rbasak: let me give some more thought about where to document the use of that though and how to effectively communicate to anyone affected
<rbasak> ogasawara: OK. Thanks!
<rtg_> rbasak, are there reasons we shouldn't carry some of these packages in the kernel ? (though I'm not interested in binary blobs)
<rbasak> rtg_: I think there are individual reasons for them not being in the upstream kernel. open-vm-tools is in multiverse, for example.
<rtg_> rbasak, no, I meant in _our_ kernel tree.
<ogasawara> rtg_: I'd prefer out kernel not becoming a dumping ground for drivers which have the ability to be DKMS'ified
<rbasak> rtg_: what I mean is that if they aren't upstream, then the same reason might apply for not wanting them in our tree.
<rtg_> ogasawara, I'm not implying we should take everything, but there are a couple of server drivers that might be of benefit.
<ogasawara> rtg_: and if we (ie I) can get the proper QA in place so that DKMS package maintainers are notified of any breakage, it would have the same affect
<rbasak> And for the ones that are not in main, would that cause an additional maintenance burden?
<rtg_> dkms has the side effect of requiring compilers and such, something that many server operators are not fond of.
<rbasak> openvswitch is probably the module that we care about the most. I'll ask jamespage about it.
<rtg_> rbasak, it also solves the backport issue with the LTS kernels
<rbasak> rtg_: it's around the same amount of work though, right? Either the DKMS package is forward-ported or someone finds upstream support and backports it, or your team does it by maintaining our tree?
 * henrix -> eow
<rtg_> rbasak, I'm kind of assuming its a one-time integration effort per release. for example, once done for saucy then the backport is free.
<rtg_> rbasak, I'm only proposing this for high value, slow moving targets.
<rtg_> hyper-v doesn't fall into taht category :)
<rbasak> :)
<rbasak> I'm guessing openvswitch does though. jamespage will know better.
<rbasak> I'm probably just an extra cook to spoil this broth though. I should step out and let jamespage discuss it here. I've updated him in #ubuntu-server since he's not on this channel, and I'll step out now. Thanks for discussing this!
 * rtg_ should never let LKML get to over 5500+ unread emails
 * rtg_ -> lunch
 * rtg_ -> EOW
<sscorrea> /echo $version
#ubuntu-kernel 2013-05-18
<infinity> BenC: Want to rebase to 3.8.0-22.33 and close #1181305 in your changelog?
<infinity> BenC: You might have to then give me a debian package (or a git tag) to sponsor to the kernel PPA.
<BenC> infinity: working on itâ¦should be about an hour
<infinity> BenC: Shiny.
<infinity> zequence: You have three more lowlatency tracking bugs.  The fun never ends:
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1181103
<ubot2> Ubuntu bug 1181103 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1181062
<ubot2> Ubuntu bug 1181062 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1181021
<ubot2> Ubuntu bug 1181021 in Kernel SRU Workflow "linux-lowlatency: <version to be filled> -proposed tracker" [Medium,In progress]
<infinity> zequence: When you get those up in your PPA, I can sponsor the copies if Andy's not around.
<zequence> infinity: cool. I'll have the kernels built sometime today. I'll ping you
<infinity> zequence: Awesome, thanks.
<BenC> infinity: whoopsâ¦fell asleepâ¦tag is PPC-Ubuntu-3.8.0-10.16
<BenC> Give it a sec to sync...
<BenC> infinity: done
<BenC> infinity: for meta, just use linux-meta-ppc master
<BenC> infinity: Hope I'm doing the workflow bug correctly
<zequence> infinity: all lowlatency have been uploaded to the PPA now
<lifeboy> Anyone here over the weekend that can give advice on loading the latest rc kernel on 12.04 to get a patch?
<lifeboy> I run 12.04 64bit server with libvirt and QEMU-KVM and have run into the bug 1071322 and need to patch it, but don't quite see how.
<ubot2> Launchpad bug 1071322 in linux (Ubuntu) "Quantal kernel for precise: starting KVM VM causes 'vmwrite error'" [Medium,Confirmed] https://launchpad.net/bugs/1071322
<lifeboy> The patch has been applied to kernel 3.7-rc6 and upwards.  Is there a way in which I can easily install that kernel?  Or could I apply a patch for it?  If so, where do I find the patch?
<lifeboy> Reading through the kernel team's MainlineBuilds page at https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelTeam%2FMainlineBuilds I installed the amd64 3.7.7-999-generic debs from  http://kernel.ubuntu.com/~kernel-ppa/mainline/prestable/linux-3.7.y/2013-02-13-raring/ which allows me to boot my server and the bug mentioned has been fixed.
<lifeboy> That's all fine, but it means that I will have to apply future kernel updates manually now, or will the the update manager install new kernel updates post 3.7.7-999 when 12.04 has reached that kernel version?
<infinity> lifeboy: You might consider installing linux-generic-lts-raring if you're happy running newer kernels on precise.
<lifeboy> infinity: Would the lts refer to long term support?
<infinity> lifeboy: lts-raring, lts-quantal, etc refer to it being "the raring kernel backported to the LTS release".
<lifeboy> Maybe I should ask, is the bug I refered to a problem or can I just ignore it and stay with the stock kernel?
<infinity> I have no idea.  I know lots of people run KVM on precise (including us, in production).
<lifeboy> I don't really want to run newer kernels.  Something's bound to break at some stage... 
<infinity> Well, if you're already running lts-quantal, you're already on the HWE track anyway.
<infinity> At least, the bug report is on 3.5.0, were you as well?
<lifeboy> I'm really just testing to see if I can make that error go away and will roll back to stock standard once I've tested
<infinity> Yes, but what is "stock" to you?
<infinity> Like I said, the bug report was on 3.5.0 (ie: lts-quantal), what were you running when you ran into it?
<lifeboy> Whatever the kernel is that ubuntu installs via update manager
<infinity> That depends on how you installed.
<lifeboy> I was on 3.5 yes
<infinity> Okay, right.  So, you're on the HWE track anyway.
<lifeboy> I did a server install from an ISO
<lifeboy> HWE?
<infinity> (The "stock" precise kernel is 3.2.0)
<infinity> HardWare Enablement.
<lifeboy> Oh wait, sorry, I got confused.  My desktop is on 3.5 (quantal), the server was 3.2 (precise) before I installed 3.7.7.
<infinity> Kay.  Well.  The way forward is one of three things: 1) Ingore the error, maybe it doesn't matter too much, 2) comment on that bug report that you've seen the error on 3.2 as well, and include logs, and suggest pulling the fix back to the 3.2 kernel, 3) use the lts-raring (3.8) kernel and wash your hands of it.
<zequence2> infinity: Seems like I've made a mistake with providing the correct version for the build. Sorry, didn't double check before uploading
<lifeboy> Infinity: I need advice then. This is an LTSP server for an office which we are re-installing (on 12.04).  I don't want to play with stuff that will cause problems later, so if I go for lts-raring (3.8), would that be considered risky?
<infinity> zequence2: Hrm?  What mistake?  I reviewed it all before I copied, and it looked fine to me.
<infinity> zequence2: (Well, other than you feeding the wrong '-v' to genchanges and getting enormous .changes files, was that what you meant?)
<zequence2> infinity: Yeah. two of them had too long changes
<infinity> zequence2: Yeah, I noticed that but oh well.
<zequence2> Was baby sitting a 4 year old, and was kind of in a hurry, but I still should have double checked. 
<lifeboy> infinity: Would that be considered risky?
<infinity> lifeboy: Are you sure you saw the exact same bug on 3.2?
<infinity> lifeboy: The commit that introduced this bug happened after 3.2 was released.
<lifeboy> Let me check my logs
<infinity> zequence2: No big deal.  Wasn't worth me asking you to reupload for.  A few big emails to -changes won't kill anyone. :)
<infinity> zequence2: The sources looked fine, which is what matters.
<lifeboy> infinity: Dang! I was wrong about being mistaken...
<lifeboy> May 17 08:20:32 parow kernel: [28030.165662] vmwrite error: reg 401e value a023a000 (err 12)
<lifeboy> May 17 08:20:32 parow kernel: [28030.165670] Pid: 25778, comm: kvm Not tainted 3.5.0-28-generic #48~precise1-Ubuntu
<lifeboy> So I'm on HWE, so would it be safe to install lts-raring 3.6 then?
<infinity> lifeboy: Okay, so.  If that's a server that isn't running X, doesn't need fancy drivers, etc, the simplest solution might be for you to switch to the 3.2 kernel.
<lifeboy> s/3.6/3.8/
<lifeboy> No, it's running X!
<lifeboy> LTSP runs X in each session
<infinity> ... not locally.
<lifeboy> And if I have users connecting via nx to that server, that's a local X session, not?
<lifeboy> Or do you mean X on the console?
<infinity> Unless it's rendering on the server's video card (it's not), it's not a local session from the POV of what I was referring to.
<lifeboy> Ah, I'm with you.
<infinity> The HWE stack is specifically about hardware drivers, after all.
<lifeboy> So if go back to 3.2 and but a hold on the linux kernel package that it doesn't want to upgrade to a later kernel version all the time, it should work fine?
<infinity> No reason to hold it.
<lifeboy> Will it stay on 3.2?
<infinity> Yes, if you remove the 3.5/3.7 kernels you installed.
<infinity> But if that was installed with 12.04.2 media and has the HWE X stack, you'll want to switch that too.
<lifeboy> It unfamiliar territory for me: How do I switch away from the HWE X stack then?
<infinity> Something like: "apt-get --purge install linux-generic xserver-xorg-lts-precise"
<infinity> And then you'll also need to purge all the 3.5.0 and 3.7 kernels you installed.
<infinity> "dpkg -l linux\*3.[57]\* | awk '/^i/ {print $1}' | xargs dpkg -P"
<infinity> Ish.
<lifeboy> Ah, ok, no rocket science then.  For some reason the media I used for this server is different, probably the alternative CD instead of the standard server... :-(
<infinity> Err.
<infinity> "dpkg -l linux\*3.[57]\* | awk '/^i/ {print $2}' | xargs dpkg -P"
<lifeboy> thanks infinity.  Let me see how it goes.
<lifeboy> infinity: For a server with LTSP & libvirt which kernel is better to run generic, server or virtual?
<infinity> lifeboy: It's all the same kernel.
<lifeboy> So it's just the tools that get install with it that differ?
<infinity> lifeboy: No, it's just that in the previous LTS, they were different kernels, so we provided transitional metapackages.
<infinity> lifeboy: Installing "linux-server" gets you the linux-generic kernel.
<lifeboy> So if install linux-image-generic I'll be fine
<lifeboy> ?
<infinity> Or linux-generic, if you want headers too.
<infinity> But yes.
<lifeboy> It will install linux-image-3.2.0-43-generic  or linux-3.2.0-43-generic then.
<infinity> linux-image-3.2.0-43-generic and linux-headers-3.2.0-43-generic if you install "linux-generic", and just linux-image-3.2.0-43-generic if you install "linux-image-generic"
<infinity> Either way, having the metapackages installed will keep you up-to-date.
<infinity> You want the headers if you also build out-of-tree modules (via dkms, for instance).
<infinity> Like nvidia/fglrx.
<lifeboy> There were quite a few thing broken running 3.7.7  Firefox couldn't find its profiles amongst others...
<lifeboy> No, I don't need special modules
<infinity> zequence2: All built and copied to -proposed.  Should hit mirrors in ~1h.
<zequence2> infinity: thanks
<infinity> BenC: FWIW, the "prepare-package*" tasks auto-complete when the package is built successfully in the PPA.  Confuses the bot a bit if you set them Fix Released. ;)
<infinity> BenC: Anyhow, cloning git and such to do a quick review, and if it's all good, I'll upload.
<infinity> BenC: *poke*
<infinity> BenC: Your changelog looks suspect.  It's missing the last two master revisions (sure, I realise those end up being a no-op, but having the CVE and bug refs there is nice), and you should have a bit with your tracking bug at the top.
<infinity> BenC: See the bit above [ Ubuntu: 3.8.0-22.33 ] in this changelog: https://launchpadlibrarian.net/140174115/linux-lowlatency_3.8.0-22.15_source.changes
<BenC> infinity: I/m not sure what you mean
<BenC> I did add the tracking bug to the top (I'm pretty sure)
<BenC> infinity: Make sure you check debian.ppc/changelog and not something else
<BenC> linux-ppc (3.8.0-10.16) raring; urgency=low
<BenC>   * Release Tracking Bug
<BenC>     - LP: #1181305
<BenC> etc...
<ubot2> Launchpad bug 1181305 in Kernel SRU Workflow prepare-package-meta "linux-ppc: 3.8.0-10.16-proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1181305
<infinity> Hrm.
<infinity> Crusty tag issue?
<BenC> infinity: Hold on, maybe I didn't --force when I pushed --tags
<BenC> # git push --force --tags
<BenC> Everything up-to-date
<BenC> Nope, should be good
<infinity> Possibly not.  Of course, that doesn't help if I already had the old tag.
<infinity> There's no way to ask git to force others to update tags.
<BenC> git fetch --tags >
<BenC> ?
<infinity> This was a fresh clone anyway, though...
<infinity> So it should be right.
<BenC> Yeah, because I pushed it last night
<BenC> github tag perusing is less than optimal
<BenC> https://github.com/benmcollins/ubuntu-raring-powerpc/blob/PPC-Ubuntu-3.8.0-10.16/debian.ppc/changelog
<BenC> That definitely doesn't match what I pushed
<infinity> Matches what I have here, though.
<BenC> infinity: Fixedâ¦my commit --amend didn't pick up my changelog revision
<BenC> Other than that, the tree is essentially the same
<infinity> BenC: Fixed where? :P
<BenC> infinity: tag PPC-Ubuntu-3.8.0-10.16
<BenC> Fixing ppc branch now, but use the tag
<infinity> Ahh, yeah, it wasn't on the branch, hence my confusion.
<infinity> Floating tags drive me batty.
<infinity> Anyhow, testbuilding here out of paranoia, but will upload to the PPA later today.
<BenC> Ok, thanks
<BenC> infinity: floating tag fixed for your sanity's sake
<infinity> \o/
<infinity> Now I just need to wait 5 hours for this test build.
<infinity> I need a machine like sagari in my bedroom.
#ubuntu-kernel 2013-05-19
<infinity> Man, adare and ross really are festering heaps.  My dinky little PowerStation builds linux-ppc in 3.5h, (compared to ross's 13.5h ...)
<lifeboy> infinity: Just some feedback. I'm running 3.2 kernel now and all is working like it should.  Thanks for your help!
<infinity> lifeboy: Good to hear.
#ubuntu-kernel 2014-05-12
<one> Talk to me
<one> What do you want
<one> Make it quick
<one> I did not ask you to fuck with my cell phone towers.
<one> Are you on a top secret mission from a supa dupa spy
<one> Talk to me
<one> Make it quick
<one> liars do not enter Zion
<one> not by beaming cell phone towers and banging on the floor either
<one> Talk to me
<one> Make it quick
<one> say something useful
<one> quit bugging
<one> Hi dayangkun 
<one> Is that linode working out well?
<hans109h> RE: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1313981 I need some help understanding why I loose keyboard and mouse (both USB) when using a previous kernel version
<apw> hans109h (N,BFTL), ok i see you found which 3.13 kernel was the first one which breaks, and that one includes an interesting change to PNP handling; which considering the debug output my last kernel produced is rather suspicious.  i'll try a new test kernel with that reverted, and with some more debug
<one> Where is the confige file used by dpkg -buildconfig?
<apw> one, i think i've seen that answers probabally 3 times already ... they are in debian.master/config
<one> it never made it to my screen
<one> theives and thugs for a neighborhood watch
<one> they watch out for the feds
<one> steal mail
<one> What is an acorn parition?
<mlankhorst> maybe from acorn computers?
<apw> indeed a partition table format used on old acorn systems, which might potentially be on an USB drive
<one> What is the most compatible way to edit the config for use with the dpkg -buildpackage?
<apw> debian/rules editconfigs
<apw> or change the config in the config fragment and run debian/rules updateconfigs
<one> Does that include editing the localversion label?
<one> The enforce file says auto adding localversion will cause package failure
<apw> setting localversion breaks the build which relies on the form of the version number
<apw> jibel, hey ... what triggers the dkms test builds against the CKT PPA
<apw> and indeed how can i tell if it has done :)
<smb> apw, Reminds me, not sure you saw the email, I managed to give iscsitarget a basic test in utopic. So whatever you did seems to work
<apw> smb, yeah i did thanks.  that is more than i know how to do
<apw> i guess that is something you should teach us
<apw> the basic concepts and bits needed for that to work
<smb> yeah, I suppose I could do it in 2 weeks when we are in the same location
<apw> smb, sounds good indeed
<apw> i assume VMs will do
<one> Looking at the config in place and comparing with lsmod it looks like the config fragments have things set as y so they are supposed to not be compiled as modules but the lsmod is showing them as loaded modules, there must be something else changing the configs, any idea what that is?
<apw> one, give us an example and i can look
<one> kvm
<one> wait that is seperate from config_have_kvm
<one> Is there not an ncurses package in the repo?
<one> The menuconfig gives explanations.
<one> Does kconfig or xconfig also give a summary?
<one> The package system calls for ncurses if selecting y to modify the config before build
<jibel> apw, a new version of the kernel in the PPA or a new version of a dkms module in proposed. In this case only this module will be tested.
<apw> jibel, in the case a new kernel dropped, it is not easy to tell from jenkins if it has been redone, is tehre something else somewhere to tell me it has
<apw> jibel, i believe it has in this case, as i opened one of the latest builds and checked, but from the dashboardy thing i couldn't tell
<jibel> apw, from jenkins it is not easy to tell indeed. On http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/U%20KT-PPA%20-generic/ you'll see that all the tests have run 9h30 ago, and if you open one you'll see the version of the kernel.
<jibel> apw, I'll check with the CI team because apparently something changed in jenkins. Previously the version of the kernel and dkms modules was displayed in the list, but it is not there anymore.
<jibel> and I cannot find a way to add it
<apw> jibel, great thanks, i am late to this party so i have not seen the live one before now to know it has gone :)
<jibel> apw, it should like https://jenkins.qa.ubuntu.com/view/DKMS/view/Trusty%20Release%20Kernel-Team-PPA%20-generic/
<apw> jibel, and i can't see it on that one either, or i am stupid, possibly the latter
<jibel> apw, ah right, the version is just "generic" in the list called 'test statistics grid'. not really useful. 
<rtg> tjaalton, bug #1317865 looks like it might be yours
<tjaalton> rtg: thanks
<tjaalton> I have other stuff to push too
<tjaalton> ffs, dropbox..
<tjaalton> oh right, the one smb reported earlier
<rtg> smb, sforshee: this one looks interesting: bug #1317811
<smb> bug 1317811
<smb> Hm, might be something that sforshee had been lookig at
<rtg> ok
<smb> Not completely the same. His was the ride the rocket message and finally ending in a bugon fragments spannign a compound page or so
<rtg> perhaps related
<smb> I guess the basic question is why buffers get so big in general. IIRC this is trying to transfer a packet where the skb is more than they can fit into 19 slots (where I had to check again how big a slot is but I think a page)
<rtg> that makes sense since the workaround is to restrict MTU to 1500
<smb> right... hm, has the default really gone up? maybe some negotiation
<one> apw: there is no updateconfigs in that directory
<one> that autocomplete , so rules is a script and updateconfigs is an argument for it?
<apw> one yes
<apw> smb, bigger than 19 pages !?
<one> Is there a package that provides ncurses so that the editconfigs may be run?
<smb> apw, Yes, it counts the number of pages the frags in a skb need and anything above 17 results in that rides the rocket message and a drop of that package
<one> Or does ubuntu allow for kconfig or other config apps?
<apw> one, the package for ncurses, is libncurses-dev
<one> It looks like updateconfigs does run kconfig and it is now looping is it safe to ctrl+c it?
<apw> it can make a mess if it is stopped
<apw> it shouldn't look forever
<one> What is the proper way to clean the kernel source directory I am working on building the kernel a second time removing some unnecisarry things from the config and the dpkg-buildpackage exits with errors and a lot of complaints about not being able to represent changes.
<one> unrepresentable changes to source
<one> Is it due to not being able to create a hash diff for nonexistant modules given that there is removal of modules in the new config?
<apw> debian/rules clean
<apw> it will likely fail later unless you fix the ABI as well, adding removed modules to "modules.ignore" in the abi directory
<one> And what about .. where the package shall go does it append to filename or overwrite considering appending localversion breaks the process?
<apw> the package will be whatever version you have at the top of debian.master/changelog, it is common to add like apw1 to the end of the version to indicate this is your version
<apw> smb, have you configured an openvsiwtch bridge like we did a normal one for xen
<one> So what reads the symbols to make it happen?
<apw> one, "it" ?
<one> Whatever the symbol represents.
<one> Now, how is this build system used to build only one of the supported archs the last time it produced a package labled _all
<apw> one, what symbols are we talking about?  i don't see you mention them before and that sentence is context free
<apw> one, _all is the architecture independant packages, common to all architectures
<apw> -b says build the arch independant and arch dependant packages for "this" architecture
<one> It was said that it builds for the arch it is built on however it says building for i386.
<one> This is not a 386.
<apw> is it a 32bit machine?
<one> I did have a 386 in the past not sure where it went.
<one> 64
<apw> and does it have 32bit ubuntu installed on it
<one> Yes it is running 32bit ubuntu.
<apw> then your architecture is "i386" which is a debian architecuture name for the 32bit x86 Os
<one> The symbols are in the abi directory conscerning the modules.
<one> No your architechture is not 386
<apw> ok, believe what you want
<one> no
<apw> but it is a fact that the "i386" debian architecture is 32bit ubuntu on x86, "amd64" is the debian arch for 64bit ubuntu on x86
<one> Do you call Jesus a carpenter like the religious leaders?
<apw> an interesting non-sequitor, i have no reason to call him anything
<one> If I can do something lesser that is not the sum of my architechure
<one> In the same way computers are reflections of a mind.
<one> With a great latency.
<tseliot> apw: can you remind me where 3.15 is? (the ppa)
<tseliot> please
<apw> tseliot, the utopic pocket of ppa:canonical-kernel-team/ppa
<one> apw: both hardware and software
<tseliot> apw: thanks
<apw> tseliot, np, good luck with the testing :-p
<tseliot> thanks :)
<tseliot> well, with test-building
<tseliot> build testing...
<one> computer is a physical representation of thoughts a mind had in the past.
<rtg> tseliot, don't forget the wl driver. its got some serious problems as well.
<tseliot> rtg: that's the driver I'm working on
<rtg> oh, cool.
<apw> tseliot, did you find the channel somewhere to steal, i found two places you could but who knows if they are sufficient, sigh
<tseliot> apw: I get it right before sending the variable, so that I'm sure nothing else messed with it. I only need to test the patch
<apw> tseliot, oh nice, be interested to see where you got it from :)
<one> apw: how is a more advanced arch specified?
<one> apw: do not run from the truth
<apw> one, that doesn't make sense, the arch is just a piece of text representing the architecture
<apw> it is rather stupidly called "i386" but it is not even compatible with a 386 machine
<apw> tseliot, i thi
<one> apw: I see the robots interrupt when I begin to reveal
<one> yupanakernel wants to live forever
<apw> tseliot, i think i have a POS with some of that h/w in it, if you want to throw me a package
<one> does apw?
<tseliot> apw: sure, that would help
<one> such timing! it is to be expected. cross empty or occupied I live forever.
<one> That anything is here shows that JESUS CHRIST is the FATHER in the flesh.
<one> our report
<one> is this the 'we' that apw suspects
<one> our report
<tseliot> this is not the right channel to discuss such topics...
<one> apw: do you accuse me of fault?
<tseliot> it's #ubuntu-kernel
<one> share your logic template then
<tseliot> :)
<rtg> bjf, how long does that last ?
<bjf> rtg, i don't know
<tseliot> apw: my patch seems to build. What architecture do you need the packages for?
<apw> tseliot, i think that machine is 32bit
<tseliot> apw: ok
<apw> tseliot, or throw me the debdiff, and i can build it here
<tseliot> apw: http://people.canonical.com/~amilone/bcmwl_6.30.223.141+bdcom-0ubuntu3.debdiff
<tseliot> I'm also creating a 32 bit chroot
<tseliot> apw: and here's the package http://people.canonical.com/~amilone/bcmwl-kernel-source_6.30.223.141+bdcom-0ubuntu3_i386.deb
<apw> tseliot, thanks, machine is upgrading, i do not run it often enough it seems
<tseliot> :)
<smb> apw, Not sure I ever completed to use opevswitch in replacement
<apw> smb, ok thanks
#ubuntu-kernel 2014-05-13
<one> What is GPIO?
<one> Under what menu label is the shpchp driver?
<one> Under what menu label is the shpchp driver?
<one> Hi
<one> Gnome disks isn't working
<one> I want to save the build tools to disk.
<one> Why is module 1 ignored by the build system?
<jarkko> guys you should really do something about RALINK wifi device, it spams constantly dropping packets
<jarkko> reported issue, done that since 3.8 series
<apw> spams that it has dropped a packet it has dropped or ones it has not
<apw> and whats the bug #
<one> hy is the module '1' ignored by the debian build system?
<one> Cr. why
<lstargz> Hi guys, how to load a custom kernel module for usb keyboard (I have written the module) or in other words how to prevent usbhid or hid-generic taking over usb drive ?
<amitk> lstargz: assuming usbhid is a module, you could blacklist it
<lstargz> I blacklisted the module (yes they are not loading). My module loads, but it does not show any message in dmesg
<lstargz> While i custom load it, it works
<amitk> lstargz: you mean manual insmod'ing works, autoloading doesnt?
<lstargz> yes
<rtg> depmod -a ?
<lstargz> depmod -a gives blank output
<rtg> use the modules_install target for your build. I think it does the right thing
<lstargz> do you mean, i put it in kernel source and build the whole kernel and install ?
<lstargz> I can only use one of these: depmod / kmod / udev / mdev / systemd, depending on distro)
<rtg> lstargz, no, I'm assuming you have a kbuild compatible Makefile.
<lstargz> This is my make file:
<lstargz> obj-m += task05.o
<lstargz> all:
<lstargz> 	make -C $(KERN_ROOT) M=$(PWD) modules
<lstargz> clean:
<lstargz> 	make -C $(KERN_ROOT) M=$(PWD) clean
<rtg> try adding 'sudo make -C $(KERN_ROOT) M=$(PWD) modules_install'
<lstargz> In which target (all or new something like install)
<lstargz> Anyways, I have already copied task05.ko into /lib/modules/`uname -r`/kernel/drivers. Is this required after that ?
<one> What command specifies the architechure to build?
<one> Also is a 32bit userspace going to still run if a 64 bit kernel is built?
<lstargz> rtg: Thanks it worked (after adding install).
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<coolman_bg84> hello to all
<coolman_bg84> i'm new in linux kernel
<coolman_bg84> but i wanna copile kernel
<coolman_bg84> and have this error
<coolman_bg84> make[1]: *** No rule to make target `/usr/src/linux-headers-3.13.0-24-generic/arch/x86/syscalls/syscall_32.tbl', needed by `arch/x86/syscalls/../include/generated/uapi/asm/unistd_32.h'.  Stop.
<coolman_bg84> make: *** [archheaders] Error 2
<coolman_bg84> can a help me plsss
<apw> coolman_bg84, what source are you using, and what exactly are you trying to build
<apw> the error there looks like you are missing the headers package
<coolman_bg84> sudo make menuconfig
<coolman_bg84> and make -j 4
<coolman_bg84> i have headers package
<coolman_bg84> apw, linux-headers-3.13.0-24-generic
<bjf> coolman_bg84, have you looked at: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<coolman_bg84> bjf, no  
<coolman_bg84> bjf, i will look 10x :)
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<jsalisbury> ##
<jsalisbury> ## Meeting starting now - #ubuntu-meeting
<jsalisbury> ##
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 20th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
<coolman_bg84> ok the meeting start and what about kernel 
<apw> coolman_bg84, it happened over on #ubuntu-meeting
<coolman_bg84> apw, ok
<coolman_bg84> Which editor is good for writing c code?
<coolman_bg84> vi?
<infinity> vim
<apw> coolman_bg84, whichever editor you know well, i use vim
<ogra_> all editors work ... as long as they are vim
<ogra_> :)
<antarus> I write kernel code in wordstar
<antarus> like a boss
<antarus> (and like George R. R. Martin, apparently)
<infinity> antarus: Can you still obtain wordstar for any modern operating systems, or is GRRM using a Tandy CoCo3?
<antarus> no idea
<infinity> Wikipedia seems to imply it's been dead since the Win3.x port.
<antarus> he uses DOS
<antarus> according to the internet
<infinity> The Internet wouldn't lie.
<ogra_> i assume you can run it in dosemu or dosbox 
<ogra_> or however these dos emulators are called today
<apw> ogra_, on your phone
<ogra_> ++
<ogra_> :)
<infinity> And possibly in cmd.exe on NT, though that's iffy, depending on what it does.
<ogra_> my next project 
<infinity> So, he may be using a computer from 1994.
<ogra_> a click package with a statically built dosbox and wordstar included
<infinity> ogra_: Hah.  And ship a sample phone to GRRM?
<ogra_> yeah !
<infinity> Ubuntu: Helping to kill your favourite fictional characters since 2014.
<ogra_> not bad ... after we rendered avatar already ... thats the next big thing 
<antarus> thats gross
<bjf> infinity, that's hostile and probably against the CoC
<infinity> bjf: Heh.
#ubuntu-kernel 2014-05-14
<one> What keys does the in kernel keys hold ssl keys or something else?
<one> Why is pappy shut down?
 * apw yawns
<one> Hi apw 
<one> [D
<one> ;5C
<ppisati> ogra_: any reason why "link_in_boot = yes" in /etc/kernel-img.conf for ARM?
<ppisati> infinity: ^
<ogra_> define "for ARM" :P 
<ogra_> i think we disabled it on the arches that didnt support it 
<ppisati> ogra_: arm boards and servers (i checked on calxeda) have that variable set that way
<apw> ogra_, does our installer/image side for ARM pre-create /etc/kernel-img.conf at all do you remember, i have a feeling it might
<ogra_> well, depends how you set them up ... on pandas we always treated the uboot partition separately so it doesnt matter if there is a link in /boot or not ... on ac100 it was the same ... the fastboot partition was not mountable 
<ogra_> if you actually want to mount a vfat under /boot instead of handling that bit via flash-kernel separately you need to modify that 
<ogra_> (but we never defaulted to such nonsense)
<ogra_> apw, i thought the kernel postinst does it ... 
<apw> ogra_, it does, but doesn't appear to put the specific values ppisati finds in his
<ogra_> hwo did ppisati install than ? 
<ogra_> *then
<ppisati> ogra_: i check an ubuntu-core+manual kernel installaion, an old panda installation and a calxeda server
<apw> ppisati, did you find the file in ubuntu-core without the kernel?
<apw> if not then it clearly must be us 
<ogra_> well, whatever creates it needs to be depending on the fact if someone was crazy enough to mount a vfat under /boot ... 
<ogra_> though the link wont break anyway ... simply because it breaks long before it can create it ... when unpacking the kernel package 
<ppisati> ogra_: nope, ubuntu-core doesn't have it
<ogra_> if flash-kernel is involved the setting is moot anyway btw ... it uses the full version string and wont use a link (unless that changed recently)
<ppisati> right
<ppisati> i'm playing around with the new uboot
<ppisati> and they have two nice fatures:
<ppisati> *features
<ppisati> 1) they can read file from ext4 and can boot from regular zImage
<ppisati> 2) a function that, given a couple of env cars, can detect which dtb this boards needs
<ppisati> so, actually 3 features
<ppisati> :)
<ogra_> nice
<ppisati> anyway
<ppisati> i was able to put together a uEnv.txt that can exploit all those three
<ppisati> and if we can make a symlink (that's where that variable came into play...) to the dtbs directory
<ppisati> like:
<ppisati> /lib/firmware/$kernel-version/device-tree/blabla -> /dtbs
<ppisati> we can:
<ppisati> 1) drop flash-kernel as a dependency when installing kernel (since we load the zImage directly)
<ppisati> 2) always load the correct and most up to date dtb for the specific board
<ppisati> e.g.:
<ogra_> right 
<ogra_> but only for platforms that fully support the new uboot 
<ppisati> ogra_: yep, talking about arm boards here
<ppisati> paste.ubuntu.com/7462048/
<ogra_> and for platforms that dont use a dedicated flash partition (that would finally make flash-kernel again what you expect from its name :) )
<ppisati> here is the uEnv
<ppisati> dedicated flash partition?
<ogra_> ppisati, well, there are still plenty arm boards that need/use mtd devices for their booting etc 
<ppisati> all the boards i have: panda, beagle, beaglebone, exynos5, imx6, etc
<ogra_> for these you will still need to use flash-kernel 
<ppisati> we don't support them
<ppisati> so it's not a problem
<ppisati> even the exynos i received boot from sd
<ppisati> first partition u-boot, etcetc
<ppisati> anyway, my main point is that the board can choose which dtb to load
<ppisati> using the findfdt() function that it has
<ppisati> so i was trying to add a symlink (the /dtbs above)
<ppisati> and that's when i notced that x86 do all the symlinks in /
<ppisati> while arm does it in /boot
<ogra_> right 
<apw> is it because /boot is separate ?  is /boot separate ?
<ppisati> apw: /boot has never been separated, they probably added that option to hanlde that case, but we never separated /boot
<apw> not that then
<ogra_> but if you use d-i you are allowed to 
<rtg> apw, what dkms packages are missing for the transition to 3.15 ? Anything particularly important ?
<apw> rtg, i think we are still waiting on actual testing of the two graphics ones, ie do they do anything
<apw> rtg, otherwise i think the package set was there, but let me double check the testing results
<apw> tseliot, did you get a chance to modprobe the graphics stacks yet ?
<rtg> apw, ok, I think I can test nvidia at least, perhaps fglrx as well
<apw> rtg, ack
<rtg> apw, if those drivers basically work, then it feels like its time to introduce 3.15
<apw> rtg, yeah i know what you mean, i assume we'll fork 3.16 onto unstable when it comes 
<rtg> apw, or just drag our feet about uploading much like we've done with 3.15
<apw> or that
<tseliot> apw: no, I haven't tested those drivers yet
<bjf> jsalisbury, can you see if the person that wrote comment #19 on bug 1305522 is willing to bisect?
<jsalisbury> bjf, sure 
<bjf> jsalisbury, thanks
<tjaalton> so I need to provide a test kernel for an oem image build, but what version number to use that is newer than the next kernel and such that it builds? tested -26.48foo1 and it failed, now testing -26.48.1 but will it fail too?
<apw> tjaalton, -26.48foo1 should work just fine, i use similar shapes often
<apw> tjaalton, what was the failure
<smagoun> bjf: Hi, I verified bug 1305133 - the fix does what's expected but it's not really complete. There is another related patch upstream but not in our kernel. Rather than fail verification of 1305133, I filed bug 1319457 as a follow-up. 1319457 has a link to the upstream patch we need
<tjaalton> apw: II: Checking modules for generic...previous or current modules file missing!  /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-26.48tja1/amd64/generic.modules  /build/buildd/linux-3.13.0/debian.master/abi/3.13.0-26.48/amd64/generic.modules
<tjaalton> make: *** [module-check-generic] Error 1
<apw> tjaalton, so did you add a new version on the top of the changelog ?
<apw> if so you need to update the ABI files in those directories, or what most of us do
<apw> is to just change the version of the latest entry rather than making a new one
<tjaalton> d/r clean isn't enough?
<tjaalton> I added a new entry after 3.13.0-26.48 yes
<rtg> tseliot, apw: no joy with nvidia-304 and 3.15 kernel
<rtg> does not compile
<tseliot> rtg: ok, I'll have a look at it
<apw> tjaalton, so best to just change the version of the last one, and then go for it
<jsalisbury> bjf, Looks like we have an answer for bug 1305522 in comment #29.  It appears the two HID: rmi: SAUCE patches are what caused the touchscreen to regress.  Reverting them allows the touchscreen to work again.
<infinity> ppisati / apw: link_in_boot = yes is the "right" setting for pretty much everyone who doesn't use lilo, IMO.  So, anyone !x86 !ia64, or x86 from the last decade.
<infinity> ppisati / apw: The fact that it's probably still the inverse on default x86 installations doesn't mean ARM is wrong (why does anyone care, BTW?)
<jsalisbury> rtg, if you have a chance, can you take a look at bug 1319471 ?  I'm not sure if I should ping the HWE folks about this?
<lesshaste> hi.. how can you boot into single user mode in 14.04? It seems "sudo telinit 1" doesn't work and nor does adding "single" to "ro quiet splash $vt_handoff
<lesshaste> in the grub options
#ubuntu-kernel 2014-05-15
<one> How is a system backed up to remake the install cd?
<one>  say backed up and remake the install cd, they are nearly the same thing.
<one> I say backed up and remake the install cd, they are nearly the same thing.
<one> If the install cd installs a clone of the system it is also a backup.
<one> Hi e11bits 
<one> ;5C
<one> ;5C
<one> What are the packages required for the dpkg build system again?
<one> I want to save them but it looks like apt-get is autocleaning the cache or else a remote prompted it.
<GortiZ> Hi I'm trying to bisect the kernel between 3.15 and 3.14 to find the commit which fixes a but I've on my laptop. I think I'm doing something wrong due to the "git log" reporting strange dates per the last commit between the bisects.
<GortiZ> I've marked the 3.14 as good and 3.15 as bad following the guide, then each kernel which is working is marked bad and each which is not working is marked good. Is this the correct path? (I'm just trying to check if I understood properly the guide since each steps takes half a day and git tells me that I need about 15 steps)
<apw> GortiZ, a bisect can show commits from a merged branch which can be older than your oldest step, it sounds like you are doing a reverse bisect correctly.
<GortiZ> apw: thanks, so I'll go on and I hope to complete it before the end of the week. :)
<tseliot> apw: I'm wondering why the tests didn't catch the failure with nvidia-304
<apw> tseliot, /me will check
<apw> tseliot, the tests did find it, but they also say it is as broken on trusty, therefore it is not a regression
<tseliot> apw: I've just pushed a fixed nvidia-304. Apparently I had forgotten to patch it to build with 3.14
<tseliot> apw: err... it should build in trusty
<tseliot> (it does in my chroot here)
<apw> tseliot, sorry ... as broken on utopic with the trusty kernel, but not with the trusty kernel in trusty ... odd
<apw> tseliot, oh not, the disaster we call jenkins has just failed both the 32 and 64 bit builds due to hudson
<tseliot> apw: it works fine here in my utopic chroot with the 3.13 kernel (i.e. what we have in the repository)
<tseliot> :)
<apw> dammit it all, this testing is USELESS if you cannot rely on the red/ggree blobs
<tseliot> hehe
<apw> jibel, ^^ like 30-40% of the DKMS builds i have had to rerun because jenkins, if i have to read the logs for every single build every time, we may as well remove the red/green blobs
<infinity> apw: jenkins must die, this isn't news. :/
<jibel> apw, what do you mean "because of hudson" ? 
<apw> no "because hudson", meaning "some random and different hudson error"
<jibel> apw, http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/U%20KT-PPA%20-generic/job/dkms-utopic-release_canonical_kernel_team_ppa-generic-nvidia_304/lastBuild/ARCH=amd64,label=wazn-adt/artifact/results/nvidia-304/304.117/build/make.log show a buld failure and the status is red
<jibel> apw, ah sorry, hudson was the former name of jenkins :)
<apw> yeah, in a lot of cases the top level job was red because it failed to get the two good greens from underneath; i've rerun all those
<apw> and in the 307 case both the jobs exploded in the middle with a random error like "unable to delete file" in hudson land
<apw> i've rerun them as well, but this level of baby sitting is just ass
<jibel> apw, hm I see, jenkins lost the connection to the slave. I'll check if it's possible to restart the build in that case.
<apw> if they could be made more robust all the better indeed
<jibel> apw, I can just concur with infinity. I'll workaround by retriggering the tests that failed due to jenkins. 
<apw> jibel, thanks :)
<cking> what happens in jenkins keeps on failing, won't it just spin forever re-doing the tests?
<infinity> cking: I'm sure there could be a fail counter if a slave explodes N times in a row.  Though, honestly, if jenkins spins indefinitely, we sort of got what we paid for there.
<infinity> (PS: jenkins sucks)
<cking> yep, just wanted to ask the obvious question, kind of sucks of jenkins was spinning on those tests forever
<cking> s/of/if/
 * apw notes that the rerun of those nvidia ones shows they should have been green, and there is/was a regression that tseliot fixed :)
<north> Hi, where can I get the Ubuntu-touch kernel to build for Nexus4 ?
<apw> north, "get" what binaries source ?
<north> sorry apw didn't understand that ?
<apw> north, read it as "north, i don't think i understand what you are asking for?"
<north> apw, I would like to know where I can find the kernel-sources for Ubuntu-touch ?
<apw> they are in our git repos, on branches by the target device, start with the trusty repo.  git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
<north> I use git behind corporate proxy, is there any way, I can download sources using http ? I mean are they hosted anywhere else by which I can clone using http protocol apw ?
<apw> http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-trusty.git i think
<north> no such file
<apw> looks ok in my browser
<infinity> That URL certainly seems to be cloning fine here.
<apw> yeah starts to clone ok here too
<apw> north, ^
<infinity> Except for the shocking lack of verbosity when cloning over http...
<apw> yeah its utterly crap isn't it
<apw> and the immense slowness
<north> yeah gotcha
<north> forgot to export http variables :p
<one> apw: any tips on how to get this onto an omap device?
<tjaalton> does the kernel packaging allow building only changed bits when bisecting?
<tjaalton> like, I've built a package, now I want to test another commit without building the whole kernel
<tjaalton> packaging is not committed, using upstream branches
<apw> tjaalton, "support" is probabally too strong
<apw> i think you can remove the build stamp and it'll do the right thing
<apw> debian/stamps/something *build*
<apw> but don't let it clean
<tjaalton> ah, ok
<apw> then agian if you build more than one flavour you lose i think
<tjaalton> just binary-generic
<tjaalton> but that target takes roughly 30min to compile on my box
<tjaalton> or a bit less, but still
<apw> tjaalton, so that should be compatible with the stamp thing, remove stamp redo binary-generic
<tjaalton> ok cool
<rtg> tjaalton, when bisecting I always just use the deb-pkg target (which is mostly a native kernel build). Its much better about rebuilding with incremental changes.
<tjaalton> rtg: alright, I'll try that too
<rtg> tjaalton, make sure you turn off debug in the config else you'll end up with a giant deb
<tjaalton> good point..
<rtg> tjaalton, CONFIG_DEBUG_KERNEL I think
<rtg> make deb-pkg INSTALL_MOD_STRIP=1
<tjaalton> yeah seems that removing the stamp didn't result in a diff build, seems to build everything
<tjaalton> and then fails later
<rtg> tjaalton, 'fdr clean prepare-generic' then copy that config and use the deb-pkg target. without really deep knowledge of the Ubuntu packaging, bisect is an enormous pain in the ass.
<tjaalton> right :)
<tjaalton> hum, make -j 8 much better
<tjaalton> git bisect seems to assume that I'm bisecting a regression, when in fact it's the other way around.. how to reverse the logic?
<tjaalton> so I'm trying to find when a bug got fixed, but marking an earlier commit bad makes it barf
<tseliot> the man page says "git-bisect - Find by binary search the change that introduced a bug"
<tjaalton> ok then, just reverse the meaning of those and it's fine :)
<tjaalton> so cheating works
<josepht> http://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find-the-first-good-commit
<tjaalton> yeah, found that
<tseliot> nice
<tjaalton> just need to be careful when marking commits.. argh :)
<apw> tjaalton, you can make aliases "worked" and "failed
<apw> wich point to the right "good" "bad"
<tjaalton> yeah
<tjaalton> nice that deb-pkg bumps the package revision too
<tjaalton> on each build
<rtg> tjaalton, yup, it just seems to DTRT
<tjaalton> very handy
<bjf> jsalisbury, in the precise tree: 9b33bf99915d39bbf699facefacfbd391289162e
<jsalisbury> bjf, that is still in proposed, correct?  3.2.0-62
<jsalisbury> well now up to 3.2.63.94
<bjf> jsalisbury, yes
<jsalisbury> bjf, ok.  I'll ask him to test proposed first
<bjf> jsalisbury, where was that revert of that patch targeted? the one that you just recently sent to the mailing list.
<jsalisbury> bjf, It was not a revert request, it was a new patch.  It was requested for the lts-backport-raring kernel and lts-backport-quantal
<jsalisbury> bjf, but it looks like regular precise got it as well, which is fine.
<bjf> jsalisbury, wasn't your new patch effectively a revert? it undid that setting of mac->link_state
<jsalisbury> bjf, oh wait, that is right.  commit 9b33bf99915d39bbf699facefacfbd391289162e adds that line and my patch removes it
<bjf> jsalisbury, and that "bad" commit is in precise, quantal, saucy, trusty
<jsalisbury> bjf, right.  And the bug report says 3.2.0-63 is bad, which would have that commit and 3.2.0-61.93 would not.
<jsalisbury> bjf, so let me build a test kernel with a revert of that commit in 3.2.0-63 in precise and have him test that.
<bjf> jsalisbury, i'm thinking that commit should be reverted in all our kernels
<jsalisbury> bjf, ack
<jsalisbury> bjf, I have a Precise test kernel building now with a revert.  I'll ask the bug reporter to test it and confirm it fixes the bug.
<one> jsalisbury: for the NST?
<bjf> i'm beginning to wonder if we should even release this set of kernels and just start the next SRU cycle on monday
<jsalisbury> one, ?
<jsalisbury> bjf, test kernel is built and posted for bug 1319735.  I'll let you know if it fixes the bug.
<one> compile kernel for NST
<one> include drivers
<one> provide sources
<bjf> jsalisbury, you got a possitive test result on that kernel test
<jsalisbury> bjf, just looked, and yes it does
<one> Does philipballew need a task?
<questor_> Hi. I have a crashing linux-kernel during startup of a laptop. it's all the time in an interrupt, but always a different callstack. how can I get more information to find out what is going on? (when I can get to the desktop it's working fine for many hours, but getting there is difficult)
<questor_> system is linux-mint16 with kernel 3.14.4-031404-generic
<one> questor_: check the logs
<one> philipballew: compile kernel for NST
<one> philipballew confirm receipt of task
<bjf> one, please don't make me ban you. if you keep pestering people i will do so
<apw> questor_, those are only debug kernels made from pure upstream source not really intended for production use
<apw> questor_, does this occur with the release kerenls?
<questor_> I had issues with the default 3.11 from mint and upgraded in the hope of a fix
<questor_> I'm inspecting kernel-logs and it seems that when the system does not boot there are (besides others) messages like "ACPI.... CPU4: failed to get CPU APIC ID." 
<questor_> when it's booting I can't see this messages in the log
<questor_> and ACPI warnings: "SystemIO range conflicts"
<apw> questor_, sounds lovely indeed, i would file a bug against the kernel in linux-mint for that indeed
<apw> and add those bad logs to it, they may make more sense en-toto
<questor_> when the kernel crashes it's always in an interrupt (nmi), but always different callstack. and most of the time the nmi takes much too long to be processed
<questor_> okay. will do that
<questor_> thanks
<apw> questor_, you might try the latest 3.11.0-22.37 from ubuntu on there and see if that helps; you never know
<questor_> apw: had the same issue with the the 3.11-kernel
<apw> questor_, what version was that though, was it the latest
<questor_> I had mint 16 installed with the default kernel, so I think it was based on the ubuntu-stable, mom, I will try to find it out
<questor_> 3.11.0-19-generic seems to work, now I will test 3.11.0-20-generic
<questor_> 3.11.0-20 seems also to work. okay, will downgrade and test.
<questor_> thanks!
#ubuntu-kernel 2014-05-16
 * apw yawns widely
<rtg> tseliot, how are nvidia and fglrx dkms packages coming along for 3.15 support ? It is time to get 3.15 into the wild.
<apw> henrix, the cve tracker may be in a heap right now, quantal just got zapped, so ignore it for the near term, will let you know when its all happy
<henrix> apw: ack, thanks
<tseliot> rtg: I fixed nvidia-304. the other nvidia drivers (except for 173) should work. fglrx should also work (although I haven't tested it yet)
<rtg> tseliot, cool, then I'll get it uploaded to the utopic archive
<tseliot> good
<rtg> apw, ^^ do you agree ?
<apw> rtg, if the nvidia, fgrlx, wl and iscsitarget are there, i think we have our "core set"
<apw> (and i beleive that we do indeed)
<rtg> apw, I believe infinity said we should upload the first time as opposed to doing a pocket copy.
<apw> rtg, i'd say do that anyhow as it makes the overrides work right
<rtg> apw, yup.
<apw> assuming it has a release tracker in it :)
<rtg> apw, :) yeah, I'll get it wrapped and uploaded, then babysit it all weekend.
<apw> heh :)  no snow then ?
<rtg> apw, driving to Beaverton this afternoon. 11+ hours.
<apw> i wish my afternoons were 11 hours long sometime [sic]
<rtg> apw, I might get another day or so of back country in before mid-July. There are some north facing steep gnarly chutes that hold snow until late in the summer.
<apw> snow in july, does-not-compute, i am used to the kind which is "no snow by mid afternoon" kind
<rtg> One called "pencil dick" is truly terrifying. thats this one: linux.tpi.com/~rtg/bridger-bowl-Apr-29-2014/IMGP0021.JPG_index.html
<apw> rtg you are insane, truly
<rtg> apw, well, thats not my track in it :)
<apw> rtg, gads it actually has a ski track down it, *gibber*
<rtg> apw, we'd likely have done it that day, but its a fair walk/climb and we were getting short on time.
<rtg> it had an unusual amount of snow, but we are at 150% of snow pack for the year.
<rtg> apw, pushed utopic master-next, starting test build. I didn't bump the ABI since everything was packaging except for CONFIG_FSL_PAMU=n 
<apw> rtg, also the only people with it are you and me; and if we can't cope with that ... shoot us now
<rtg> apw, isn't the CONFIG_FSL_PAMU=n patch for powerpc ? I ain't got one 'o dose.
<apw> rtg, yeah i think so, i meant to say, we don't care if it is a bumper or not, noone has the old -1 in the wild so a new -1 is just fine; though it prolly isn't a bumper anyhow
<apw> might be nice to bump the upload number so we get upgraded
<apw> (but i am sure you were going to do that anyhoo)
<rtg> apw, Ubuntu-3.15.0-1.3 is an upload number bump
<apw> henrix, ok the cve tracker seems to have healed itself
<apw> rtg, cool, that'll do it in deed
<henrix> apw: indeed! thanks
<spideyman> jsalisbury Hi, for CVE-2014-0196, which precise kernel will contain the fix? I want to be sure I have the right one
<jsalisbury> spideyman, let me double check
<spideyman> jsalisbury thanks so much
<rtg> apw, fire in the hole
<apw> rtg, ack ... will keep a weather eye out for it migrating :)
<jsalisbury> spideyman, 3.2.0-63.94
<spideyman> jsalisbury awesome, thx again
<infinity> zequence: Everything got respun for a 1-line revert. :/
<infinity> zequence: Do you have time to do the quick rebase?
<zequence> infinity: Ah, sure. np
<infinity> zequence: You rock.
<infinity> BenC: Out of curiosity, did you verify that pulling in grub-ieee1275 on your systems doesn't flip out due to the lack of a PReP partition?
<BenC> infinity: Yep. Weâve actually been running with that on our system since day 1
<infinity> BenC: Ahh, cool.  Just wanted to make sure.  So, grub-install is basically just a no-op on your systems?
<BenC> Just to generate grub.cfg. grub-common could do it alone, but we donât get all the snazzy âUbuntu XXXâ naming, it would just say âLinux xxxâ
<BenC> infinity: Well, grub-install wouldnât workâ¦if it makes more sense, then at the least, grub-common is needed, but grub-ieee1275 includes all the extra naming (we just need update-grub run to generate grub-cfg)
<BenC> *grub.cfg
<infinity> Though, there could be an argument for wasting a few MB for a useless PReP partition anyway, so your filesystem is also bootable (well, with a different kernel) in qemu/slof.
<BenC> Well, grub-ieee1275 has zz-update-grub for kernel post inst/rm
<infinity> BenC: I'm sure grub-install won't work, my point was that I hope it doesn't also FAIL, cause then you've just broken the kernel upgrade. :)
<BenC> infinity: If weâre just talking about installing kernels, then no problems there at all
<infinity> But hopefully the platform detection stuff just sees yours as one it knows nothing about and skips along.
<BenC> grub-install doesnât run for that
<BenC> Installed-Size: 186
<BenC> Itâs pretty small
<infinity> BenC: It runs in grub-ieee1275.postinst and you've made the kernels depend on that.  That's what I'm driving at.
<infinity> BenC: But if you've not seen it explode, then we must have (accidentally?) gotten the detection, or lack thereof, right. ;)
<BenC> grub-ieee1275 has never failed to install or upgrade on our system, so I suspect itâs all fine :)
<infinity> \o/
<infinity> BenC: On a not entirely related matter, when you do qemu/kvm on your machines, do you emulate pSeries with SLOF and, confusingly, an FSL CPU, or do you emulate some sort of FSL platform?
<infinity> (And, if the latter, how does that boot?)
<BenC> FLS platform (e500-generic, uses host cpu detection)
<infinity> BenC: Maybe I should get you to send me one of your 64-bit systems sometime, so I can ask these questions from the hardware. :P
<BenC> You can either boot a vmlinux/initrd directly, or use our platform kernel+initrd to boot the same way the native hardware boots (with grub)
<BenC> We suggest the later and it works just like the grub on kvm x86 systems
<BenC> *latter
<BenC> IOW, you can boot the kernel+initrd on your system rather than a hard passed one on the command line
<BenC> s/on your system/on your disk image/
<infinity> Righto.  That's what I prefer too.  Was just curious where the firmware comes from.  I guess you ship that outside the archive.
<infinity> (For pSeries, it uses qemu-slof, which is in the archive, though qemu doesn't currently depend on it, which is a mistake)
<infinity> Or does it pull some tricks to actually read it from the host system's firmware and reuse it without needing a copy in the filesystem?
<infinity> Which would be somewhere between clever and awful, and probably both.
<BenC> It requires you to download them from our public archive
<BenC> Maybe one day weâll be that clever :)
<infinity> BenC: I suspect that would tip closer to "awful" than "clever", but certainly shipping your "firmware" in the archive might be nice.
<infinity> BenC: Probably moot, though, I imagine your customers can figure it out.
#ubuntu-kernel 2014-05-18
<johnstamosrisc> What are the packages needed to build the kernel again it looks like apt-get is deleting the cache and I want to save the packages locally.
<dasGnu> Hello, I was asked to file a bug report while booted into a Ubuntu repository kernel (not a mainline one). Could someone give me a hint how to boot this repsitory kernel, please.
<KernelCoder> Hello, I was trying to compile a Hello World module. I edited the Makefile and Kconfig in drivers/block. But when I ran make under the source tree, the new module is not compiled and no .ko file was generated. Any ideas?
#ubuntu-kernel 2015-05-11
<laza> Is there a kernel boot parameter that prevents the message "ACC PCI Probe failed" to show up during boot?
<apw> laza, is that error causing you an issue, or you jsut want to silence it
<laza> apw,
<laza> just silence it
<apw> laza, i am strtuggling to even find the error, can you paste the whole line from dmesg
<laza> apw: just a sec
<laza> Ok, sorry for the confusion. It's indeed "ACPI PCC probe failed."
<cking_> that message is annoying noise for most users at the moment
<cking_> commit efd756daf4ddae3cec2404c4e0b does turn it from pr_err to pr_debug
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 12th, 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/
<laza> cking: Thanks for the info
#ubuntu-kernel 2015-05-12
<genkgo> Hello. We have a huge problem with Ubuntu 14.04 VPS inside a Hyper V platform. Running Windows Server Backup (VSS) changes the filesystem into a read-only filesystem. It is not a specific VPS problem: all three Ubuntu machines have exactly the same problem. In the same cluster we have a CentOS machine that is not having any problem at all. The Ubuntu machines are all on 3.13.0-52-generic. Because the machines are in production, our
<apw> genkgo, is there a dmesg error at the time of the switch to read-only ?
<genkgo> apw: no, there is no log at time the machine switches to read-only. That is exactly what it makes so hard. The problems occur randomly (at least I am not able to see a pattern). During some backups we have these logs: http://pastebin.com/MvGuDyRL. But also during other backups we have these logs: http://pastebin.com/sExsZKhV.
<genkgo> apw: but we never see any log before the machine goes into read-only filesystem. those logs only occur during backups that finish successfully do not cause the filesystem switch. they maybe (and I guess so) an indication of other problems.
<apw> genkgo, and then what happens, the filesystem reports a full error and moves the filesystem r/o ?
<genkgo> apw: no errors, the filesystem is in read-only mode. so every service that tries to save files is down.
<genkgo> apw: it is a simple webserver: nginx + apache + php-fpm. our http requests cannot be delivered.
<genkgo> apw: we have tried multiple backup strategies: all fail. and the weird thing is: the centos inside the cluster is doing very fine.
<genkgo> apw: i now see that there is a difference between centos and ubuntu. the ubuntu machine is using etx4 while centos uses xfs.
<apw> genkgo, could you file a bug against linux for me, and i will ask someone who has a hyper-v system to see if they can reproduce the behaviour
<apw> "ubuntu-bug linux"
<genkgo> apw: will do. is there anything you can advise me?
<genkgo> apw: to fix the problem temporarily?
<apw> genkgo, when you say it goes read-only what makes you say its read-only if we have no diagnostics saying that ?
<genkgo> apw: ok, when I was logged in to the machine, certain commands fail due to read-only filesystem.
<apw> genkgo, and yet the end of dmesg output does not indicate it going read-only ?
<apw> genkgo, could the filesystem be frozen for the backup, i know some of the backup bits do that on hyper-v
<apw> because /boot being ext2 and it not supporting freeze was an issue for a while
<genkgo> apw: hmm, now I am having doubts. I believe I did not look at dmesg while the system was in read-only mode, but only after the reboot. And then there was nothing on read-only.
<apw> genkgo, right, if you just reboot it won't get flushed to a permenant file, if it had gone read-onoly
<genkgo> apw: alright: so while being in the read-only I should immediately run dmesg
<genkgo> apw: I will do that and see what the logs say.
<apw> genkgo, for sure, as the end of that might indicate something kernel side triggering read-only
<genkgo> apw: I do not know Hyper V well enough to know whether it freezes the filesystem.
<genkgo> apw: I will not file the bug untill I have the dmesg output
<apw> genkgo, no, i think our best bet is that there is a kernel diagnostic at the end of dmesg, if you have a dev environment or something you can tickle this in
<genkgo> apw: will try to do that. the problem is the randomness. it is hard to reproduce the issue. last time (last night) the system went into read-only after the last machine was finished with backup.
<apw> genkgo, odd indeed
<genkgo> so there were 4 machines in the backup sequence, no problem at all during backup. when last one finished, another machine got into read-only filesystem.
<apw> genkgo, that sounds pretty odd doesn't it
<apw> the one doing the work is ok, and another is collateral dammage
<genkgo> apw: sounds extremly crazy to me.
<genkgo> apw: I think the Hyper V host sends a signal to the guest machines after backup, other something like that.
<genkgo> apw: thanks for the help anyway. lets see what dmesg has to say during read-only filesystem.
<apw> genkgo, yeah, that is one reason i am wondering about the freeze bits, but yes, lets gets a dmesg and cat /proc/mounts as well
<apw> genkgo, also make sure we know what kernel version we are talking about in the report
<genkgo> apw: yes, at the moment is is 3.13.0-52-generic
<apw> genkgo, i would also look at whether the backup is requesting fs freeze, as there is definatly a hyper-v interface to ask the kernel to freeze and unfreeze filesystems
<genkgo> apw: what does /proc/mounts tell us
<genkgo> ?
<genkgo> hmm I see :)
<apw> genkgo, lots of things
<apw> including whether we think it is read-only or not
<genkgo> apw: regarding the freeze bit, we tried multiple backup strategies, all failed
<apw> sadly i know next to nothing about VSS backup
<apw> genkgo, how long does the backup take btw, across all the nodes 
<genkgo> 1 hour and a few minutes
<apw> and everything is working in parallel with that until the last second when the backup ends, and sometimes one of the members breaks
<apw> well indeed we need to see if there is anything in that dmesg when it occurs, as i suspect your ext4 filesystems are mounted to go r/o on any error
<apw> why xfs wouldn't have the same hissy fit at a failed IO is an interesting question, assuming it sees them too
<genkgo> apw: the backups are not simultaneously, it takes 1 hour to backup all 4 machines in a row
<lifeless> genkgo: do you have a VSS agent running in Ubuntu ?
<genkgo> lifeless: yes, I believe so.
<genkgo> lifeless: /usr/lib/linux-tools/3.13.0-52-generic/hv_vss_daemon is running
<lifeless> genkgo: does it log anything?
<lifeless> also https://msdn.microsoft.com/en-us/library/aa384589(v=vs.85).aspx is a little terrifying
<genkgo> lifeless: let me check that, I have not found any logs of the vss daemon before
<genkgo> lifeless: that picture frightens me too!
<genkgo> lifeless: I do not see any hv daemon logs
<apw> genkgo, i do not believe that forms separate logs, it should log to syslog
<apw> i also cannot see how this daemon guarentees it is able to run if for instance it gets paged out during the backup
<apw> nor does it seem to report anything on thaw failures, hrumph, not helpful
<genkgo> apw: we have planned to replicate one of the machines today (we do not want anymore downtime) and backup that machine hourly until things go wrong
<genkgo> apw: hopefully i can give additional information afterwards
<genkgo> apw: anyway, thanks a lot so far!
<apw> genkgo, sounsd purfect
<genkgo> apw: INFO: task rs:main Q:Reg:605 blocked for more than 120 seconds. What could that mean?
<apw> genkgo, that implies a task is unable to finish in the kernel
<genkgo> afw: during boot I see also the following message: init: plymouth-upstart-bridge main process (298) terminated with status 1
<genkgo> and scsi scan: INQUIRY result too short (5), using 36
<genkgo> afw: would it make sense to dump the complete output of one of the machines?
<genkgo> complete output of the boot sequence (/var/log/syslog)
<genkgo> afw: http://pastebin.com/zGqiMkAc that's the complete syslog of one of the Ubuntu VPS machines since it booted this morning (07:45 local time).
<genkgo> oh, I did |grep kernel |grep -v UFW
<nessita> jsalisbury, hello again. Regarding LP: #1201528, I reproduced the issue by playing a youtube video. Audio is completely lost, no way to recover unless I reboot. Added to the bug debug logs from pulseaudio. Anything else I can do to help?
<ubot5> Launchpad bug 1201528 in linux (Ubuntu Saucy) "[INTEL DP55WG,Realtek ALC889] - Audio Playback Unavailable" [Medium,Won't fix] https://launchpad.net/bugs/1201528
<jsalisbury> nessita, thanks for the update.  I'll review the bug again
<nessita> jsalisbury, thank you!
<jsalisbury> nessita, Just to confirm, you reproduced the bug on Vivid?
<jsalisbury> **
<jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<jsalisbury> **
<nessita> jsalisbury, yes, vivid and kernel 3.19.0-16-generic
<jsalisbury> nessita, thanks 
<cristian_c> jsalisbury, hello
<cristian_c> jsalisbury, are there any news about build of that kernel you told me?
<jsalisbury> cristian_c, not as of yet, but should be soon
<hallyn> jjohansen: apw: danwest reports https://bugs.launchpad.net/apparmor/+bug/1408833 appears to be back in 14.04.2
<ubot5> Ubuntu bug 1408833 in AppArmor "broken postinst test for uvtool-libvirt on utopic" [Undecided,Confirmed]
<cristian_c> jsalisbury, ok
<jsalisbury> ##
<jsalisbury> ## Kernel team meeting in 5 minutes
<jsalisbury> ##
<apw> hallyn, how long has .2 been out there ?
<hallyn> not a clue
<hallyn> danwest: could you (or whoever ran into that bug) do an 'apport-collect 1408833' on the affected host?
<hallyn> that should save apw/jjohansen some time (assuming it works)
<apw> hallyn, danwest, the fix we applied still seems to be applied at least
<infinity> apw: It was never fixed on 3.13, afaict, maybe danwest's seeing it on the trusty kernel, not the hwe-u kernel.
<infinity> apw: At least, the bug log implies it was only fixed in 3.16 (and I hope carried forward), no indication that it was backported to older kernels.
<apw> infinity, but .2 had the utopic kernel on ?
<apw> no ?
<smb> apw, the server iso but who knows about cloud-image which maybe they use
<infinity> apw: Well, that depends on how you define ".2", doesn't it?
<infinity> apw: lsb_release on any up-to-date trusty host will tell you it's 14.04.2
<apw> infinity, ahh good point
<infinity> apw: What kernel you have installed is irrelevant.
<apw> heh ... yay for useless monikas
<infinity> 14.04.2 isn't useless, it's just wrong for people to claim it relates to the HWE stack we happen to release at the same (ish) time.
<infinity> But I stopped fighting that battle a while ago.
* jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 19th, 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/
<infinity> smb: Cloud images typically don't use HWE kernels, until a cloud requires it for some reason (like, the Azure precise images moved to lts-s because they had to, and then lts-t)
<smb> infinity, Yeah. I was just thinking about it for the reasons you said for naming that 14.04.2 as well. But forgetting that upgrade also results in the same
<infinity> smb: Yeah, 14.04.2 is a point in time in the archive, the only relation it has to HWE stacks is the ISOs.
<infinity> Whcih does make it confusing when people talk about it, but the whole HWE stack thing is confusing in general.
<smb> True. More reasons to insist on bug reports with proper data (or it never happened) ...
<hallyn> danwest: ^  so looks like we need data;  thx
<danwest> infinity, HWE is confusing - I still don't truly get it - not obvious what it is (just a kernel??), where and how I get it, etc...
<danwest> hallyn, what data? that apport-collect tries to open a browser which turns out to be something text based like lynx
<danwest> apw, infinity, hallyn: 3.16.0-30-generic is my current kernel
<infinity> danwest: Knowing which kernel is a big help already, yes.  If you could at least include that in the bug report.
<danwest> infinity, will do 
#ubuntu-kernel 2015-05-13
<tomti> What is the easiest way to find the latest official kernel version for a particular ubuntu release? I tried apt-cache show|madison|showpkg but none give what I want
<genkgo> afw: We spoke yesterday on the read-only filesystem issue with ubuntu (3.13/ext4) vs centos (3.10/xfs) inside a HyperV platform. We created a new VPS and started to backup the machine hourly. This machine just went into read-only state and I grabbed info from dmesg: http://pastebin.com/48CK60Hi and /proc/mounts http://pastebin.com/WwLej7r7 as you told me.
<genkgo> afw: the machine is still in read-only mode, so if you need more info, please let me know.
<infinity> genkgo: Nothing earlier in dmesg before that?   Looks like the (fake) disk driver exploding.
<genkgo> infinity: yes, http://pastebin.com/DTmvZgHS
<genkgo> infinity: the lines I just added happen during every VSS backup
<genkgo> infinity: I explained yesterday to afw that I have four machines, three ubuntu 3.13.0-52 with ext4 and one with centos 3.10.0-123 with xfs. The Ubuntu go into read-only mode randomly while the CentOS machine is doing fine.
<genkgo> infinity: Sorry, go randomly into read-only while HyperV is creating a backup of the four machines (in a row, not simultaneously). That could be during a backup of the specific is created but also at the end of the complete backup process.
<genkgo> * of the specific machine
<xnox> .... hyperv backup does freeze on to the filesystems and devices.
<xnox> and expects the freeze & unfreeze to work...
<genkgo> lifeless showed me a picture of the HyperV VSS process: https://msdn.microsoft.com/en-us/library/aa384589(v=vs.85).aspx confirming information is exchanged between the hyperv cluster and the guest machines at the end of a backup
<genkgo> xnox: yes, that is confirmed on the link I just pasted
<genkgo> but why do the ubuntu machines go into read-only mode while the centos is doing fine?
<genkgo> xnox: and what does the dmesg http://pastebin.com/48CK60Hi output tell me?
<genkgo> except from being in read-only: we knew that, I cannot find a cause in the message.
<xnox> writting journal was aborted, then time jumps 200ms, journal is attempted to be read and is incomplete.
<genkgo> ok, and this means filesystem inconsistency and therefore ubuntu kernel switch the filesystem to read-only?
<xnox> imho that smells like "sync" did not complete, yet "freeze" returned and backup kicked in thus expoding at "thaw" and remounting ro
<genkgo> xnox: do you have any advice what to do? I have machines in production that are affected by this, causing downtime.
<genkgo> afw asked me yesterday to file a bug if I knew what was going on (dmesg). Now I have that information. Is it a bug? Is it Ubuntu Kernel related?
<xnox> dunno, i would have asked cking to stress test freezing/unfreezing vms under I/O workload to figure out what's going on.
<xnox> it should be reproducible outside hypervm
<xnox> not sure who afw is, you mean apw?
<genkgo> xnox: sorry, I mean apw indeed :)
<apw> genkgo, well you have a pretty clear disk error there
<apw> end_request: I/O error, dev sda, sector 65127256
<apw> that IO failed so the filesystem wen't offline
<genkgo> apw: ok, so you guess bad hardware?
<apw> genkgo, i would like to see more of the dmesg before that
<apw> genkgo, it is a VM so it is likely not actual h/w failure, it presumably is talking about a virtual disk
<xnox> also it would be interesting to know how hyperv initiates vm freeze... given that we probably lack fsfreeze and xfs_freeze userspace tools in 14.04
<genkgo> apw: http://pastebin.com/DTmvZgHS contains the other lines (I also showed you yesterday). Would you like me to include boot sequence too? Because there is nothing more in between.
<apw> genkgo, if you showed afw yesterday, then i'd have not noticed
<xnox> genkgo: use pate.canonical.com and show everything =)
<genkgo> hehe :)
<xnox> genkgo: also paste.ubuntu.com works nicer with pastebinit utility ;-)
<apw> genkgo, remind me of the kernel version again 
<apw> genkgo, and do the ones which do not fail also report those changed operating definition
<genkgo> apw: yes, they do
<genkgo> http://paste.ubuntu.com/11112285/
<apw> i see you are using 3.13 kernels on these hyper-v guests, we are mostly producing images with HWE kernels installed for hyper-v
<apw> because the hypervisor interface is evolving so very fast at the moment
<apw> genkgo, that one also shows an aborted journal
<apw> [66392.076569] end_request: I/O error, dev sda, sector 65127256
<apw> [66392.076610] Aborting journal on device sda5-8.
<genkgo> apw: correct, this is is full output of dmesg
<genkgo> of the same machine
<apw> or is that a change for each backup, and only the last output if the only one which failed
<genkgo> yeah, we replicated a machine as test machine yesterday, started backup hourly until the system went into read-only, which just happened
<genkgo> this is the full output from boot yesterday untill now
<genkgo> apw: we are using 3.13 kernels for all ubuntu machines (the centos one is using 3.10)
<apw> genkgo, is the centos running the same workload as the ubuntu machines in the backup set ?
<xnox> genkgo: ....  centos is xfs which always had freeze support, e.g. ext2 only gained freeze support in 3.19 kernel.
<genkgo> yeah, every machine has other purposes and therefore other services, but yeah, I think there is no difference in load
<xnox> genkgo: plus centos version numbers are a bit pointless, as 3.10 can have eons of cherrypicked patches.
<apw> genkgo, i mean are they doing the exact same things?  i'd say the one which has failed had an IO in flight when the change request popped out and that has made it go pop
<xnox> and we default to mounting ext2 filesystems with the ext4 driver. so logs are different.
<genkgo> xnox: I noticed we are on version 3.10.0-123 so yeah I imagined the pataches
<xnox> imho you should _only_ be using hwe kernels on hyperv.
<genkgo> apw: no, in that case they are doing really different things
<xnox> apw: centos is usind different filesystem type....
<genkgo> centos is doing mail (imap and smtp)
<xnox> as in no IO at all...
<genkgo> while two ubuntu machines are handling http requests
<xnox> which logs all the time to disk...
<genkgo> the final ubuntu is helper machine with all kinds of services (tomcat / libreoffice converter etc.)
<genkgo> xnox: so you are saying we should switch filesystem?
<xnox> genkgo: no.
<xnox> genkgo: i am saying it's uneven comparison with centos. oranges and apples.
<genkgo> xnox: ok
<xnox> genkgo: you should switch to our hwe kernels, and check if you can reproduce this with 3.19 - vivid's kernel.
<xnox> genkgo: and azure people want ubuntu to use 3.19 kernel and better... to get the ext2 freeze support
<xnox> cause default server config uses ext2 + lvm volume group and they can't freeze that for backup across the board.
<xnox> on other clouds we default to hwe kernels. e.g. on ec2 and similar.
<genkgo> xnox: ok, I will do that. switching to xfs makes no sense?
<xnox> genkgo: we cannot do that, no.
<xnox> genkgo: we are talking about all ubuntu vms launched in azure, not just your three vms.
<genkgo> xnox: allright, I never meant to talk about all ubuntu vms
<genkgo> xnox: so I leave to fs to ext4 and upgrade to HWE kernels
<genkgo> being 3.19
<genkgo> xnox: this page does not indicate there is a 3.19 https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<genkgo> xnox: is this the ppa ppa:canonical-kernel-team/ppa I should use?
<xnox> https://launchpad.net/ubuntu/+source/linux-lts-vivid
<xnox> it's in proposed
<genkgo> xnox: thank you very much for helping me out
<genkgo> I will install it and see what happends
<apw> genkgo, if this is a test box, i would suggest that you run a test using the linux-lts-utopic 
<apw> as in theory that is what is being tested in majority in azure
<genkgo> apw: I am already installed 3.19 on the test machine, using sudo add-apt-repository ppa:canonical-kernel-team/ppa, sudo apt-get install linux-generic-lts-vivid
<genkgo> hmm, now I am into dependency troubles
<genkgo> hmm, this dependency issue is harder than I had before
<genkgo> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<genkgo> while trying to install tools and could tools
<genkgo> trying to overwrite '/usr/bin/perf', which is also in package linux-tools-common 3.13.0-52.86
<genkgo> I see this was a problem before
<genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1410278
<ubot5> Ubuntu bug 1410278 in linux (Ubuntu) "package linux-cloud-tools-common 3.16.0-29.39 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Confirmed]
<genkgo> I cannot remove reinstall 3.19
<genkgo> xnox: how should I install hv-kvp-daemon-init in combination with vivid kernel?
<genkgo> if I just do apt-get install I asks me to install the cloud tools of the older kernel
<genkgo> 3.13
<genkgo> I now have 3.19 + tools + cloud tools
<genkgo> but no hv-kvp-daemon-init
<apw> linux-cloud-tools-lts-vivid perhaps ?
<genkgo> apw: that is already installed
<genkgo> apw: http://paste.ubuntu.com/11113627/
<genkgo> And I am currently on 3.19.0-17-generic.
<genkgo> xnox: apw: There is no current release of this source package in The Vivid Vervet (hv-kvp-daemon-init).
<apw> genkgo, hv-kvp-daemon-init should not be needed
<apw> those are carried in the kernel now
<genkgo> ah alright, perfect
<apw> and /usr/sbin/hv_kvp_daemon  should start it, and it should be being started automatically from upstart
<genkgo> apw: there is a binary over there
<apw> did it start correctly thought
<apw> though
<genkgo> apw: it is not in the list of processes, I only see hv_vmbus_con hv_vmbus_ctl
<genkgo> apw: I do see some additional errors in dmesg when booting
<genkgo> visorutil: module is from the staging directory, the quality is unknown, you have been warned
<genkgo> and some visorchannel errors
<apw> genkgo, what does "initctl status | grep hv" sat
<apw> say
<genkgo> initctl: missing job name
<apw> sorry initctl list | grep hv
<genkgo> empty
<apw> this is trusty right?  so it is running upstart ?
<genkgo> apw: this is vivid
<apw> oh now we are getting confused, i thought it was trusty with lts-vivid installed ?
<genkgo> this 14.04 with vivid
<apw> so trusty right
<genkgo> :) yes
<apw> with the hew vivid kernel
<genkgo> yes
<apw> hwe
<apw> and "initctl list | head" has jobs listed
<genkgo> apw: yes, there are jobs
<apw> ls -l /etc/init/hv-*
<genkgo> and I installed the kernel by sudo add-apt-repository ppa:canonical-kernel-team/ppa, sudo apt-get install linux-generic-lts-vivid
<apw> and do you have the hv- init configuration ?
<genkgo> ls: cannot access /etc/init/hv-*: No such file or directory
<genkgo> apw: I guess not, before I just install cloud tools and tools together with the hv daemon
<genkgo> http://apt-browse.org/browse/ubuntu/trusty/main/all/linux-cloud-tools-common/3.13.0-24.46/file/etc/init/hv-kvp-daemon.conf
<genkgo> apw: should I add that file?
<apw> well if you have linux-cloud-tools-lts-vivid installed you should have linunx-cloud-tools-common installed as a dependancy
<genkgo> apw: I have linux-lts-vivid-cloud-tools-common installed
<genkgo> not linux-cloud-tools-common
<genkgo> if I do, it tries to install the 3.13.0 one
<apw> i don't believe i expect there to _be_ an linux-lts-vivid-cloud-tools-common
<apw> and yes i expect it to use the 3.13 common one, as it is common to _all_ versions
<apw> it only carries the wrapper scripts which are common
<apw> and the same between them all
<genkgo> http://paste.ubuntu.com/11113627/
<apw> well that seems bust to me
<genkgo> apw, so I should remove the linux-lts-vivid-cloud-tools-common
<genkgo> an install the common one again
<apw> if it will let you yes, as i think the vivid one is empty.  it should also not exist
<apw> if it is a depenency of linux-cloud-tools-generic-lts-vivid or whatever you installed, then it is broke
<genkgo> ok, so now I have common tools and cloud tools (3.13.0-52.86) and the vivid kernel
<genkgo> hv-kvp-daemon stop/waiting
<apw> it think this kernel may have broken tools dependancies
<genkgo> same for vss and fcopy daemons
<apw> i am looking at it
<genkgo> apw: I changed the linux-lts-vivid-cloud-tools to the common one
<genkgo> http://paste.ubuntu.com/11114346/
<genkgo> but the hv daemons are not starting
<apw> yep, and it has deinstalled the actual daemons
<apw> i think this is just broken
<apw> and i am not sure the utopic one is any better
 * apw checks properly
<genkgo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1410278
<ubot5> Ubuntu bug 1410278 in linux (Ubuntu) "package linux-cloud-tools-common 3.16.0-29.39 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Confirmed]
<genkgo> apw: is it broken indeed?
<smoser> hey... wonder if someone could confirm my suspicion / conclusion in bug https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1443542
<ubot5> Ubuntu bug 1443542 in curtin (Ubuntu) "curtin race on vivid when /dev/sda1 doesn't exist" [Undecided,Confirmed]
<smoser> maybe, wonder if there is a way to acheive what i want there, without monitoring udev hooks myself or somethingto that effect.
<apw> smoser, welll i can say whne you do the reread ioctl the udev message has been queued before we return to you
<apw> whether udev would include pending ones it has not yet read in its idea of pending is still in the air
<smoser> hm..
<smoser>    udevadm settle [options]
<smoser>        Watches the udev event queue, and exits if all current events are
<smoser>        handled.
<smoser> what else would be the point, apw ?
<apw> smoser, i'd say it ought to see them, to my reading of that english, which is of course not the source code
<apw> smoser, all i can really for sure say is if you did the reread ioctl, and that returned 0 then it will have completed the:
<apw>         kobject_uevent(&disk_to_dev(disk)->kobj, KOBJ_CHANGE);
<apw> that is that that has been queued to all listeners
<smoser> apw, k. thanks.
<smoser> now i'm back to not knowing what was wrong.
<smoser> i think you shot my theory
<smoser> rbasak, ^ just fyi.
<apw> smoser, and from what i can see in udev that even it we got out of the kernel and into udevadm settle before udev is woken to read the event, we will read the event before checkign if we are idle and responding
<apw> to the settle
<smoser> apw, so i think you're saying that it should work like i originally expected / coded for.
<smoser>  a.) echo "2048," | sfdisk /dev/sda
<smoser>  b.) blockdev --rereadpt
<smoser>  c.) udevadm settle
<smoser>  d.) expect /dev/sda1 to exist
<smoser> right?
<apw> smoser, though i guess it depends if more than one is produced
<apw> smoser, and whether you are waiting for the second one
<smoser> more than one?
<apw> yes, the event i listed was the "device has changed" for i assume sda in this case
<apw> is it sda1 you are waiting for ?
<smoser> yes.
<smoser> so are you saying that the kernel would emit "device_has_changed(sda)", then return from blockdev, then subsequently emit "device_has_changed(sda1)" ?
<smoser> that would seem unfortunate.
<apw> smoser, oh ... but ... actually the interface for settle is a bit odd, it is actually using a file in /run
<apw> smoser, no it queues them all i believe before returning 0
<smoser> and then udevadm settle *should* wait until it has processed the entire queue
<smoser> at least it says it will.
<smoser> (or 120 seconds, but i dont htink thats the issue here)
<apw> so i think although it is using a file, it is interlocking with udevd by pinging it, so they at least think they are doing the right thing
<apw> do you get the events in the end in your scenario ?  
<apw> smoser, ^
<smoser> well, all i have to go on is the bug at this point.
<smoser> and the code i pointed to
<smoser> apw, thanks for your help.
<rbasak> smoser: I think beisner said he can reliably reproduce it?
<smoser> yeah, but i can't have access at the moment.
<rbasak> I guess maybe the next step is to log udev events and compare the timing of those to the timing of the commands
<smoser> yeah... given apw's assesement, i think maybe we're in a different path than i originally thought. 
<rbasak> <apw> that is that that has been queued to all listeners
<rbasak> apw: does that definitely mean that it's visible to udev in userspace by that point?
<apw> rbasak, to my understanding of the netlink code yes
<rbasak> I know that's what you're saying; just want to eliminate the possibility of there being some other queue in kernelspace in the way
<rbasak> OK, thanks.
<rbasak> Then I wonder if there's a race in udev between reading that and handling "settle".
<apw> rbasak, there may be, but it is at least claiming to handle the proposed race
<rbasak> Understood
<apw> rbasak, but i also don't think we have any proof the right thing was actually done yet ... ie that the do appear
<apw> (the events)
<rbasak> I am curious enough to dig into udev's source, but I'm busy this evening
 * rbasak should go
<smoser> rbasak, apw http://paste.ubuntu.com/11119254/
<smoser> i can get that to fail.
<smoser> like:
<smoser> BLKRRPART: Device or resource busy
<smoser> waitfor after partition2 failed
<smoser> i think that the script is doing all sane things.
<apw> what says BLKRRPART: De...
<smoser> blockdev
<smoser> i thikn
<smoser> but i can patch to make sure
<apw> so the wait is bound to fail, as you didn't actually do the partition reload
<apw> which might indicate something has one of the partitions open
<smoser> tomomrrow.
<smoser> ?
<apw> if the blockdev failed, then it didn't change anything
<apw> and didn't emit anything to wait for
<smoser> sorry. i have to run. oi'll look more tomorrow.
<nessita> jsalisbury, hi, quick question, in the audio bug you mention kernel /v4.1-rc3-vivid/ but I only see v4.1-rc2-vivid in http://kernel.ubuntu.com/~kernel-ppa/mainline/
<nessita> jsalisbury, shall I try v4.1-rc2-vivid or v4.1-rc3-unstable
<jsalisbury> nessita, I would suggest v4.1-rc3
#ubuntu-kernel 2015-05-14
<genkgo> apw: i am really sorry to bother again, but i just wont succeed in installing cloud tools generic for 3.19. apt only wants to install 3.13 cloud tools. what ppa or source should i add to install this package http://packages.ubuntu.com/vivid/main/linux-cloud-tools-generic.
<genkgo> the one i added now is ppa:canonical-kernel-team/ppa
<infinity> genkgo: You're running utopic, right?
<infinity> Err, trusty.
<infinity> Brain not here.
<apw> genkgo, yes they are deffo not well, i have submitted fixes for
<infinity> genkgo: If you're running the lts-vivid kernel on trusty, you shouldn't be adding vivid sources to your sources.list.
<genkgo> infinity: yes, i am running trusty with 3.19 (installed by ppa:canonical-kernel-team/ppa)
<genkgo> apw: ok, so that means, at the moment I have to wait for the release of those fies, right?
<genkgo> *fixes
<infinity> One would think, with the current state of things, "apt-get install linux-cloud-tools-lts-vivid-generic linux-cloud-tools-common" would do the trick.
<infinity> Or is that generic-lts-vivid?  Whatever.
 * infinity looks.
<rbasak> apw, smoser: could it be a udev hook somewhere that has a partition device file open in that case?
<infinity> Yeah, linux-cloud-tools-generic-lts-vivid
<genkgo> infinity: linux-cloud-tools-generic-lts-vivid : Depends: linux-cloud-tools-3.19.0-12-generic but it is not installable
<genkgo> infinity: i guess that is what apw means with broken
<infinity> Er, wat?
<infinity> No, that's not what he meant by broken.
<infinity> That's your sources.list being broken.
<infinity> Since you should be at -17, not -12
<genkgo> infinity: you are right
<infinity> genkgo: If you have any vivid sources in your sources.list, you really shouldn't.  It should all be trusty.
<genkgo> infinity: i removed the ppa:canonical-kernel-team/ppa before and replaced it with ppa:canonical-hwe-team/ppa to see what happened
<genkgo> infinity: now I reverted it that
<infinity> Bad things, I assume. :P
<genkgo> and it will be installed
<infinity> So, yeah.  You want linux-cloud-tools-generic-lts-vivid and linux-cloud-tools-common
<infinity> The bug apw was referring to is that linux-cloud-tools-generic-lts-vivid doesn't depend on linux-cloud-tools-common, but installing it manually should work.
<genkgo> infinity: what ppa should i use anyway? the hwe-team or the kernel-team? is there a difference?
<infinity> genkgo: You shouldn't use either, ideally.
<infinity> genkgo: But if you must use one, the kernel team's PPA is the source of goodness and light, and it's what feeds the Ubuntu archive.  The HWE PPA has no such guarantees.
<genkgo> infinity: ok, i will use the kernel team then
<genkgo> infinity: still things go wrong
<genkgo> /var/cache/apt/archives/linux-cloud-tools-common_3.13.0-53.88_all.deb
<genkgo> apt still tries to install some 3.13 packages 
<infinity> genkgo: It's supposed to.
<infinity> genkgo: 3.13 (or, rather, the master branch, which is 3.13 in trusty) provides the One True tools-common package.  Everything else is meant to depend on it.
<infinity> genkgo: That's why I told you to explicitly install it, because tools-lts-vivid doesn't currently depend on it, like it should.
<infinity> genkgo: If that's all that went wrong, then everything went right.
<genkgo> infinity: ok :)
<genkgo> cool, now my hyperv daemon are running
<genkgo> daemons
<genkgo> hmm, they were, i rebooted to see if they would start automatically
<genkgo> apw: no i am back to where i was yesterday: my hv daemons are not running
<genkgo> initctl list | grep hv is empty
<genkgo> there is no /etc/init/hv*
<infinity> genkgo: Did you at any point delete them by hand?
<genkgo> nope
<genkgo> infinity: i just feel my cloud tools generic is still not installed right
<infinity> Are you positive?  Cause linux-cloud-tools-common ships them.
<infinity> But they're conffiles.
<infinity> So, if you delete them, they don't come back.
<genkgo> infinity: i never deleted those files
<infinity> genkgo: dpkg -l linux-cloud-tools-common && dpkg -L linux-cloud-tools-common
<infinity> genkgo: pastebin those for me.
<genkgo> infinity: dpkg-query: package 'linux-cloud-tools-common' is not installed
<infinity> genkgo: ...
<infinity> genkgo: apt-get install linux-cloud-tools-common
<infinity> genkgo: That was the 3.13 package you complained about apt trying to install.  It really should be installed.
<infinity> genkgo: Install it, verify that /etc/init/hv* are there, reboot, and rejoice.
<genkgo> infinity: i just remove everything related to cloud tools, run sudo aptitude purge '~c', now my systems looks as follows http://paste.ubuntu.com/11129000/
<genkgo> now i repeat the steps you told me
<infinity> genkgo: Not sure why you did that, but okay...
<genkgo> infinity: because I was pretty lost
<infinity> genkgo: "apt-get install linux-cloud-tools-generic-lts-vivid linux-cloud-tools-common"
<infinity> genkgo: That's all it should take.  Those two packages installed.
<infinity> (And whatever deps they pull in)
<genkgo> Errors were encountered while processing: /var/cache/apt/archives/linux-cloud-tools-common_3.13.0-53.88_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
<genkgo> same as last time
<infinity> I'll need more than that line.
<genkgo> it just wont install
<genkgo> trying to overwrite '/usr/share/man/man8/hv_kvp_daemon.8.gz', which is also in package linux-lts-vivid-cloud-tools-common 3.19.0-17.17~14.04.1
<infinity> Ah-ha.
<infinity> apw: Okay, remove my ACK from your patch.  Your lts packages are NOT empty. :P
<infinity> apw: You need a Conflict/Replace on them from the master one.
<infinity> genkgo: dpkg -i --force-overwrite /var/cache/apt/archives/linux-cloud-tools-common_3.13.0-53.88_all.deb
<infinity> genkgo: Should get you going for now.
<infinity> genkgo: We'll fix things up here for the next versions.
<apw> infinity, bah what is in them
<infinity> apw: Looks like manpages, at least.  See above.
<apw> and the patch for those is right no?  it is linux which needs to fix them
<infinity> apw: Your patch for lts-* is right, yes, just incomplete without also fixing master.
<infinity> apw: In the same SRU cycle, being the important part.  So the upgrade is smooth.
<apw> yep
<apw> gotcha
<genkgo> infinity: rebooted, and see the daemons running :)
<genkgo> wonderful: now hopefully, 3.19 wont get my system in read-only during vss snapshot
<genkgo> infinity: thanks a lot for the help
<genkgo> apw: and of course your help too, much appreciated
<genkgo> infinity: during boot i still see these message [storvsc] Sense Key : Illegal Request [current] and [storvsc] Add. Sense: Invalid command operation code.
<genkgo> any idea what that means?
<apw> genkgo, i think those are pretty normal on there
<genkgo> apw: ok, thanks
<genkgo> apw: just to be sure, my boot process also contains init: plymouth-upstart-bridge respawning too fast, stopped and scsi 3:7:1:1: scsi scan: INQUIRY result too short (5), using 36
<genkgo> i just want to see as less errors as possible to just mitigate every possibility that it can cause the read-only problem
<genkgo> hm  there is already a bug report for plymouth error: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1309617
<ubot5> Ubuntu bug 1309617 in plymouth (Ubuntu) "plymouth-upstart-bridge main process (189) terminated with status 1 at boot" [Medium,Confirmed]
<infinity> Yeah, the plymouth thing isn't anything to worry about.
<apw> the inquiry too short is also common on those images
<genkgo> apw infinity: ok i will stop worrying :) and just hope hyperv vss problems are resolved with the 3.19 kernel. i will report back to you, if you are interested
<apw> infinity, ok those package _should_ be empty, but an interaction with another bug fix has made them contain something .... bah
<apw> infinity, so at least i know why now ...
<infinity> apw: Ahh, well.  Comedy of errors.  Keeps us employed, right? :P
<apw> infinity, yeah i guess it does that ... 
<infinity> apw: Just make common Conflicts/Replaces lts-{utopic,vivid}-common, and life's good.
<apw> infinity, and i am going to fix the bug that prevents the packages being empty like they should have been, ie preventing puking lots of errors about unknow packages
<smoser> apw, http://paste.ubuntu.com/11130592/
<smoser> does that seem sane? as i'm seeing failures in it.
<apw> smoser, what failure are you seeing with it though
<smoser> BLKRRPART: Device or resource busy
<smoser> failed[1]: ptwrite/blockdev: partition 1
<smoser> [90432.37]
<smoser> more commonly i think i'm seeing the partition 2 blockdev failing
<smoser> but that one just failed
<smoser> it runs seemingly forever on utopic
<smoser> i'm pretty sure its udev thats letting go early.
<rbasak> smoser: just been looking at the udev source. I'm pretty sure it's racy. Not sure if what we're trying to do is supported behaviour.
<rbasak> I believe there's a race in that "udevadm settle" can return before udevd sees an event that the kernel has queued.
<smoser> rbasak, continue in #ubuntu-server. apw you too if interested. as strikov and i talking there too.
<rbasak> ack
<apw> smoser, right that just tells you you oculdn't change the partitiont table because one of the parititons was busy
<smoser> apw, right.
<cmagina> question: what is the best way to get an upstream commit cherry-picked into an ubuntu kernel version? i have a couple upstream commits with SRU bugs already created in lp, one I submitted a request-pull for, but that doesn't seem like the correct way to handle this.
<apw> cmagina, submitting them to the kernel-team@ list is the right way to do it
<cmagina> apw: is there any special format for that e-mail? i've been using request-pull for my own submissions, but those are modified upstream commits or applied patches type deal
 * cmagina just submitted an upstream commit in that manner, thus the question of how i should do this properly :)
<apw> i'd just send the upstream patch from format-patch
<cmagina> ok
<cmagina> thanks
#ubuntu-kernel 2015-05-15
<jmarcom> jsalisbury What's the latest stable kernel git tag for precise? Ubuntu-lts-3.13.0-53.87_precise1? For 12.04.5
<jsalisbury> jmarcom, that is correct, for the hardware enablement kernel
<jsalisbury> 12.04.5 like you say
<jmarcom> thanks!
#ubuntu-kernel 2015-05-16
<genkgo> infinity: Yesterday you helped me upgrading to 3.19 kernel. This solves the problem that my VPS does not switch to read-only while running VSS snapshots. However, yesterday suddenly there are no more VSS freeze and thaw logs. There is no reason why I do not see them anymore. The VSS daemon appears to running (ps -aux |grep vss). The only additional log I have is "Clocksource tsc unstable (delta = -75591956 ns)".
<genkgo> Fortunately, my vps is doing well. At least there are no read-only troubles and I believe other processes are running fine.
<kenjo> So is the removal of /dev/mem in 4.x intentional ??  demidecode needs this to work.
#ubuntu-kernel 2016-05-16
<zkanda> Hey guys, I installed linux4.6 today for some fixes on my laptop that got upstreamed. However I cannot start docker because of missing aufs driver which I assume would be in linux-image-extra-4.6.0-040600-generic but it's not available.
<zkanda> Anyone knows how can I get/compile this myself? Thanks in advance.
<apw> zkanda, there is an upstream aufs repo, not sure if that is up to date with 4.6 as yet
<zkanda> apw You mean this? https://launchpad.net/ubuntu/+source/aufs-tools I would have thought I still need the linux-image-extra. Hmmm
<apw> zkanda, no i mean we get the code from a separate upstream: https://github.com/sfjro/aufs4-standalone.git
<apw> zkanda, aufs would normally be in linux-image-extra, but the 4.6.0 you are talking about is a mainline build so only has what is available in linus' tree
<zkanda> apw: Oh I see, got it. So manually compiling/installing this mainline should theoretically solve my issue? :)
<apw> zkanda, in theory
<SpamapS> Hi! We've been pulling from git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git for a while as part of a CI system that adds patches on top of it, but since sometime yesterday, it has been refusing to let us pull. Anybody know if that's temporary, or if we're maybe doing something to perturb the sysadmins?
<SpamapS> $ git fetch ubuntu-trusty
<SpamapS> fatal: read error: Connection reset by peer
<TJ-> $ git fetch ubuntu-trusty
<TJ-> remote: Counting objects: 177302, done.
<TJ-> that was just now
<SpamapS> write(5, "0032have 26d55d1aae4ecdbd4ed5f1f"..., 309) = 309
<SpamapS> read(4, 0x7fffc9158740, 4)              = -1 ECONNRESET (Connection reset by peer)
<SpamapS> 4 is the socket
<TJ-> SpamapS: are you going through a proxy, transparent or otherwise?
<TJ-> SpamapS: which protocol is the remote configured to use?
<SpamapS> git://
<SpamapS> no proxy
<TJ-> same here, maybe monitor the connection with tcpdump see if that reveals anything
<SpamapS> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
<SpamapS> connect(4, {sa_family=AF_INET, sin_port=htons(9418), sin_addr=inet_addr("91.189.94.216")}, 16) = 0
<apw> SpamapS, as far as i know nothing is menat to have changed
<SpamapS> 14:27:04.284963 IP 192.168.0.6.42270 > 91.189.94.216.9418: Flags [P.], seq 70:229, ack 82172, win 1278, options [nop,nop,TS val 34334039 ecr 1879947210], length 159
<SpamapS> 14:27:04.467288 IP 91.189.94.216.9418 > 192.168.0.6.42270: Flags [R.], seq 82172, ack 229, win 122, options [nop,nop,TS val 1879947267 ecr 34334039], length 0
<SpamapS> RST with prejudice.
<SpamapS> They do exchange quite a few other packets first.
<TJ-> SpamapS: what ubuntu release is the host?
<apw> SpamapS, let me pass the issue to someone ... might be our end
<SpamapS> TJ-: 16.04
<SpamapS> have tried 14.04 as well
<TJ-> SpamapS: wondering if a git version difference might be at issue
<SpamapS> same issue on both
<SpamapS> apw: my hero. Thanks for looking into it. :)
<TJ-> SpamapS: yeah, looks like the server took a dislike to you :)
<apw> SpamapS, also the primary repositories are now in launchpad, so you might want to switch over to using that
<SpamapS> while I have your attention.. is history rewritten on that repository ever?
<SpamapS> apw: Oh, I did not know that. What's the url for those?
<apw> SpamapS, on those older repositories, it is possible, highly unlikely but possible in the face of embargoed cves
<SpamapS> apw: ok, we saw one instance of it so wasn't sure if it was the norm
<apw> SpamapS, https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/trusty
<apw> ^ would be the trusty repo
<apw> SpamapS, very rare, but i wouldn't rule it out occuring ... 
<SpamapS> apw: thanks, the launchpad git servers are in fact working
<apw> SpamapS, there is a number of them i believe, so you ought to have better luck with them, particularly today it seems
<SpamapS> could of course be faster...
<SpamapS> Receiving objects:  21% (71741/337062), 39.46 MiB | 228.00 KiB/s    
<SpamapS> but.. I can live ;)
#ubuntu-kernel 2016-05-17
<cagmz> is it safe to statically allocate 256k bytes in my kernel module?
<cinch> where can i get a CK enabled kernel for 16.04?
<cinch> with the BFQ scheduler
<TJ-> anyone around? got a sysadmin 'on the line' with a server that is failing to install the kernel package for ubuntu-server 16.04, we're in the /target/ and have managed to narrow it down to a problem with the linux-image-4.4.0-21-generic postinst script
<DJVG> Hi :-)
<TJ-> DJVG: now we know we can manually cause the initrd.img to be generated, it makes it possible to remove it and rerun the postinst script with -x and try to capture the error. Let's wait 5 minutes see if apw or timg or someone is interested in this. If you want to set up the ssh shell in the meantime that'd be really useful
<DJVG> TJ-: Do you prefer a shell inside or outside the chroot?
<TJ-> DJVG: outside :)
<cinch> TJ-, any idea what might cause the problem?
<cinch> odd that a kernel fails to install
<TJ-> cinch: yes, the postinst script is calling the initrd script with incorrect arguments. 
<cinch> a-ha!
<TJ-> DJVG: its 20:30 here and I need to go to dinner. I'll return in ~20 minutes if you want to wait around. If not, no worries, I can still write up a bug report although we won't have an identified cause
<DJVG> TJ-: I've got the time, no worries!
<DJVG> TJ-: Took me a while to put this machine in a different vlan and compile dropbear static but it's working now :)
<DJVG> TJ-: You can ssh as root to 91.148.253.252 without a password (I know dangerous but it's a tmp solution) :-)
<DJVG> And ofcourse I monitor haha
<cinch> oh cool ill login ;)
<DJVG> cinch: Seeing anything interesting? ;)
<cinch> i see systemd and a debian installer ^.^
<DJVG> cinch: Great! ;) Hopefully the kernel devs can figure out later why the installer does not pass the right parameters to update-initramfs
<cinch> the kernel sources are unpacked in /usr/src
<TJ-> I'm back. DJVG you could relay me through a shared tmux if you wanted :)
<DJVG> TJ-: Meh, I know, but this way you can do whatever you want. This machine is not in production and has no data on it
<DJVG> TJ-: So it's fine
<DJVG> TJ-: I had to compile dropbear anyway
<TJ-> DJVG: I was thinking more along the lines of 'more eyes' 
<TJ-> I thought dropbear was in the repos :)
<DJVG> TJ-: Maybe it is but I'm sure I had to change my PATH to get the libs etc...
<DJVG> To be able to run it outside the chroot
<TJ-> ahhh, yes it is DLed, I thought it was static. Must have been thinking about busybox for initrd
<TJ-> Right, I'll connect now
<DJVG> TJ-: 10-4
<TJ-> ok, little problem... dropbear seems to be limiting what I can get. no "which" no "chroot" :D
<TJ-> oh, PATH :)
<DJVG> Yeah
<TJ-> I'm in a chroot now, will mess with the installer postinst script now
<DJVG> TJ-: Go ahead, she's all yours ;)
<TJ-> interesting! since we generated a good initrd.img it won't fail
<TJ-> So, some flag is expected to exist but doesn't on first install, breaks it
<DJVG> TJ-: If you want I can re-run the install to the point it fails and give you access again
<TJ-> DJVG: I'm just reading the postinst Perl script, see if I can spot anything obvious
<cinch> reading perl 
<DJVG> TJ-: Quite funny to see it fails in a virtualbox machine too with the same error
<cinch> perl -> deobfuscator -> brain
<TJ-> going to focus on the core error from the original syslog: "mkinitramfs: failed to determine device for /" 
<DJVG> TJ-: I'm getting the idea that there's something wrong with the installer itself. Not sure though, I'm not really into the inner workings of the installer
<TJ-> looking at /usr/share/initramfs-tools/hook-functions:386:          echo "mkinitramfs: failed to determine device for $dir" >&2
<cinch> let's say i want to log each process that was started (with its command line parameters), how would i go about it
<TJ-> damn! the UUIDs are different
<TJ-> see http://paste.ubuntu.com/16481625/
<DJVG> TJ-: That's interesting
<TJ-> and the code in hook-functions:dep_add_modules_mount() relies on the /dev/disk/by-uuid/ symlinks 
<TJ-> which explains why it failed with the error "failed to determine device for /"
<cinch> why is the uuid different?
<DJVG> TJ-: Yes, it was trying to use the old(?) UUID
<DJVG> TJ-: That's quite weird
<DJVG> TJ-: Wasn't it refreshed after a mkfs?
<TJ-> DJVG: there were existing partitions on /dev/sda and you replaced them?
<TJ-> DJVG: were they the same (3 parts, same size) ?
<DJVG> TJ-: It might be possible yes, I can't be entirly sure because I tried to install it multiple times and it's possible I didn't re-init the part. table
<TJ-> but whatever, if you repartitioned then partprobe should have been called, and that should have triggered udev to re-do the symlinks
<TJ-> let me see if there's a hidden udev dlog file
<TJ-> hmmm, nothing I can find, so that doesn't help. I wonder if there's some clue in syslog though
<TJ-> when it booted: 17:32:31 kernel: [    2.576702]  sda: sda1 sda2 sda3
<DJVG> TJ-: It's possible that I didn't remove the part. table and only assigned the right mountpoints + mkfs on thos part's
<DJVG> parts*
<TJ-> right, but if that's all you did then the UUIDs would be correct. This looks as if there were partitions on sda, udev creates the symlinks, the installer re-partitions and/or re-formats the file-systems in sda1 and sda2 but udev doesn't get informed and therefore the /dev/disk/by-uuid/ symlink names are not updated
<TJ-> so, when allocating existing partitions/file-systems for mountpoints maybe if you set to 'format' it doesn't cause/trigger the symlinks to be updated
<TJ-> that sounds like a scenario that could be reproduced easily, too
<TJ-> I'll pull in the -server ISO and try it in a VM here
<DJVG> TJ-: Yes, if you want me to do anything let me know. I might need to grab some sleep soon but I can keep this machine running if you want. Again, no important data on that thing
<TJ-> the bit that has me stumped right now though, is why it now works since the UUIDs are the same
<TJ-> DJVG: if you could keep it as-is that would be great, I can hopefully pull some more diagnostics off it into a bug report
<DJVG> TJ-: I don't know how how the installer performs the kernel thing but I can suspect a change in behaviour if you want to run it inside or outside the chroot
<TJ-> DJVG: and I'll try to reproduce here in a VM too, once its reproducable you can get on with completing the install on that machine :)
<DJVG> TJ-: That's fine, I can keep it up as long as you want :)
<TJ-> DJVG: let me open a bug report now and give you the ref. so you can check on progress if you need to go sleep
<DJVG> TJ-: If I get disconnected from this you can alway reach me at djvg@djvg.net (pgp: 213FEC83)
<DJVG> Sure
<cinch> so why didnt initrd get its params
<cinch> what was the issue, uuids not matching?
<TJ-> bug 1582899
<ubot5> bug 1582899 in base-installer (Ubuntu) "in-target: mkinitramfs: failed to determine device for /" [Undecided,New] https://launchpad.net/bugs/1582899
<cinch> so the installer failed to detect new UUIDs
<TJ-> well that's udev's job, when a device is added/changed
<cinch> kinda obvious bug... could have been easily avoided
<TJ-> but the reformat didn't repartition so presumably it needs triggering manually to update the UUID link names
<TJ-> Still got to be able to reproduce it to be sure this is the cause, it's only a hypothesis for now
<TJ-> DJVG: I've copied off syslog and partman and attached them to the bug report. I'll look for other useful logs that might help
<DJVG> TJ-: Sure, no problem. I'm going to get some rest now. Thanks for all your help and I've subscribed to the bug to keep me posted. Thanks again!
<DJVG> TJ-: Btw, if you want to le me know something just touch something in /tmp or you can always contact me by e-mail (like if you're done with the server).
<TJ-> DJVG: I'll use the email if it's none public none-bug related
<DJVG> TJ-: Perfect!
<TJ-> DJVG: I've added your key to my keyring
<TJ-> Time for a strong coffee I think :)
<TJ-> great time for launchpad to start generating errors - can't attach files now
<cinch> strong coffee? what timezone, we sleep here
<TJ-> UK here
<cagmz> for character device modules, what does the file * in ssize_t (*read) (struct file *, char *, size_t, loff_t *); refer to? i see calls to these methods with an file descriptor to the device file itself
<apw> cagmz, right, they should have a kernel file descriptor which points to the chacter device
<cagmz> why does the device need to be referenced, though? does the kernel find the device using the fd given in read(), write(), etc?
<apw> cagmz, because these are file operations against a file, passed file* representst the kernel view of teh file
<apw> that file* is pointed to by the fd numbers given in read/write
<cagmz> ah!! because the kernel doesn't differentiate between devices and files, right? i keep making them distinct but linux treats them the same
<apw> the are "files" in the strictest sense in the kernel view
<cagmz> im supposed to be writing a device that reads/write to an internal data structure in the kernel using IOCTL(). so far, I have created a struct that is passed from user space to kernel space with the # of bytes to write, but I also need to pass the actual string to write. would it be ok to use 2 separate ioctl calls? 1 to set the control register for the device (with # of bytes to write), and ioctl() with a pointer to th
<cagmz> e actual string?
<mjg59> Why not include all of that in the struct?
<cagmz> ah, true! I have a control struct with * of bytes to write/read. I could use a union to store a pointer to the message. but if I do this, will the kernel be able to access the char *?
<mjg59> It'll need to do copy_from_user()
<mjg59> You can't directly dereference userspace pointers in the kernel
<cagmz> for example, in user space, i could have char msg[] = "cat". then I do ctrl.data.message = &msg. if I use copy_from_user, will the kernel copy the message or just a pointer to it?
<mjg59> The kernel will get a pointer
<cagmz> ah ok, so I would need to use strcpy to store the message in teh struct first, right?
<mjg59> No
<cagmz> how about passing in ctrl.data.message = &msg, using copy_from_user to copy that whole struct, then using copy_from_user on cmd.data.msg ptr to copy to the module?
<mjg59> Yes
<mjg59> That'll work
<mjg59> But remember that someone could submit a structure with an invalid length
<mjg59> Don't assume that the length passed in corresponds to the real length of the string
<mjg59> You'll want to null terminate it yourself before doing anything with it
<mjg59> Also probably set some upper bound on the size, otherwise someone can DoS you by just allocating huge quantities of kernel memory
<cagmz> the data structure inside the device is 256k bytes, so I will check that the ctrl.num_bytes < 256k. and while writing to teh device, I will stop before 256k. this is just academic though
<cagmz> mjg59: do you think something like this would work? https://bpaste.net/show/6b4b9ff894e8 can i declare a char * alongside bits in a struct?
#ubuntu-kernel 2016-05-18
<mwhudson> apw: is there an eta on the fix for https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1574982 ?
<ubot5> Launchpad bug 1574982 in dkms (Ubuntu) "Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler" [High,Confirmed]
<mwhudson> (it looks like it will be fixed in the kernel?)
<apw> mwhudson, yes, that is already fixed in the unstable kernel and will be fixed in the curretn xenial sru kernel. when that copies out it will hit yakkety too
<apw> mwhudson, it got delayed some by anembargoed cve
<mwhudson> apw: ta
<apw> mwhudson, applying the fix locally by hand is eminently doable if you are blocked by it
<mwhudson> apw: it's causing an autopkgtest failure so that wouldn't be very helpful :-)
<apw> mwhudson, yeah we ahve a very large pile of those cause red on a lot of my packages, its been a huge pain to fix and deploy due to timing
<mwhudson> apw: https://bostongazette.files.wordpress.com/2014/02/the-lego-movie-awesome-e1392309318427.png?w=600
<apw> mwhudson, oh so very true
<tjaalton> ideas why self-built drm-intel-next kernel (for bisecting) fails to boot on a machine where the mainline build boots fine. same .config used, the new build built on xenial
<tjaalton> it just hangs at "loading initrd"
<tjaalton> dropping quiet et al does nothing
<tjaalton> it's a rather old mainline checkout (3.18-rc5+), newer kernels built on this machine boot fine there
<rtg> tjaalton, disable splash screen ?
<tjaalton> nope
<tjaalton> hmm I could try a chroot build on trusty
<TJ-> tjaalton: kernel or initrd.img corrupt? the message "Loading initrd" comes from GRUB; next step is the kernel starts spewing messages to console
<TJ-> tjaalton: is it booting with GRUB in GFX mode? if so, try changing it to text mode
<tjaalton> I've done a number of builds, thought it was my config that failed to work on this (baytrail) machine
<tjaalton> guess it's gfx mode
<tjaalton> the default
<TJ-> tjaalton: also is it UEFI? I've seen some weirdness with UEFI GOP causing no video output
<apw> tjaalton, cirtianly we build the mainline builds in a chroot, the BUILT file tells you which
<tjaalton> TJ-: efi
<tjaalton> apw: right, it's actually vivid
<manjo> apw, did you guys decide after uds what kernel version 16.10 might end up being ? 
<manjo> ogasawara, ^ ? 
<apw> i am assuming 4.7/8 most likely 4.8, though its early to be deciding on the version in a non-LTS release
<manjo> apw, ack thank for confirming 
<manjo> apw, I guess when we get close to freeze dates we might have a better idea 
<manjo> apw, I needed a ballpark for advising cust on what they should target wrt upstream patches .. I think we should tell them 4.7
<apw> well they need to be pushing their patches a week ago to hit 4.7 anyhow right ?
<manjo> yeah and they are for the most part 
<manjo> apw, but there are a lot of acpi bindings that might not make 4.7 but 4.8 instead .. probably I will need to sru those when the time comes 
#ubuntu-kernel 2016-05-19
<rtg> tseliot, have you built nVidia against a 4.6 kernel yet ? we've got one for you in the yakkety pocket of https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa
<tseliot> rtg: I have built 361 with a patch for 4.6, and I'll use that kernel for testing now, thanks
<rtg> tseliot, great!
<tseliot> rtg: ok, the patch seems to need more work. I'll let you know when it's ready
<rtg> tseliot, ack
<Laney> anyone know of a guide that'll tell me how to make dkms sign modules it builds?
<apw> Laney, sign them with what
<Laney> this key that I made
<Laney> and then added to the mok thingy
<apw> Laney, i know of no existing mecahnaism for that
<Laney> wl.ko is now signed so I'm at least online :)
<Laney> but the next kernel will I guess not have that
<apw> no indeed, but having the signing key on the machine seems like a lawed security position
<Laney> it's at least root only
<Laney> I haven't thought about this *that* much
<rtg> Laney, https://docs.google.com/document/d/1Z1_jR3MmxuvqolQH4PORkJCgENkb2Tlw4FVA-sHqdMw
<apw> rtg, i think he has done the equivalent of that
<Laney> yeah
<rtg> I think cyphermox is working on the user space components for DKMS signing
<Laney> okay, so not there yet
<apw> is there any sane configuration where you have the signing key on disk?  if you do you might as well just turn secure boot of at MOK ?
<Laney> I should read aout the arguments around this signing stuff
<Laney> I suppose it's something like -
<Laney> The key database is 'secure' even in the face of the system being rooted
<Laney> and so an attacker that has root wouldn't be able to make the kernel load things if they don't have the signing key
<apw> in theory, the practice is much less clear
<Laney> then you have to never let the private key touch the machine
<apw> right and that part is what makes the dkms side difficult
<Laney> quite an interesting problem
<Laney> would be keen to see the spec cyphermox is working to if there is one
<Laney> also I managed to get upgraded to a kernel which refused to load wl.ko
<apw> i am unclear of the bigger picture inthe plan
<Laney> without knowing that it was going to happen in advance, so I rebooted and had no network
<Laney> that was a bit sad
<apw> yes, out of tree drivers are not first class citizens in a lot of ways,secure boot is one of them
<apw> thoughyou should have been told to turn off secure boot because dkms was installed
<apw> but perhaps that is only done as we transition from no dkms -> dkms installed
<apw> hmmm
<Laney> perhaps update-manger or the release upgrader would have done that
<apw> the dkms asking you to disable secureboot via mok happens as part of dkms installing even at the command line
<apw> but perhaps not on upgrades or something
<Laney> I can't rule out that I missed or ignored it either
 * Laney checks dkms
<rtg> Laney, I've gotten a couple of reports of basically the same thing happening
<Laney> rtg: Hmm
<Laney> It's confusing now because cyphermox moved to a new script in yakkety
<Laney> and I didn't have a new enough shim-signed to have the "update-secureboot-policy" thing installed
<Laney> so I wouldn't have been prompted to disable it
<Laney> *however* I should have seen the old debconf questions
<rtg> Laney, I think upgrading Wily to Xenial definitely has issues
<Laney> which have now been unregistered by the new dkms
<Laney> so probably out of luck to find out what happened to me
<apw> Laney, man its a minefiled
<Laney> warrants some testing for sure
<Laney> get that davmor2 on it
<Laney> apw: Be glad you're not on the front line of this one :)
<cyphermox> Laney: what's the issue?
 * cyphermox reads backlog
<Laney> hey cyphermox 
<Laney> I may not have been asked to disable SB but can't prove it any more
<Laney> and also was wondering if there's a story about signing for dkms
<cyphermox> Laney: you're not the first to mention it; I remember Steve pinged me a few weeks ago about not being prompted on upgrade, but being prompted afterwards when it probably should not, but that was also unreproducible
<cyphermox> Laney: tbh I don't know how to sign the modules, do we have a userland too to do that?
<Laney> There's some script shipped by the kernel
<cyphermox> well, I suppose we do, the question is more, do we ship it and is it usable by the common mortal
<cyphermox> right
<Laney> sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /lib/modules/4.4.0-23-generic/updates/dkms/wl.ko
<rtg> apw has update sbsign to include the module signing tool
<apw> sbsigntool includes kmodsign in the versions in -proposed
<cyphermox> I haven't really looked into that yet -- the story to start with was to either have free things and all signed with our kernel package, or have third-party drivers and disable shim validation
<cyphermox> ah, great
<cyphermox> Laney: the SB disabling should only prompt if it can see that you're booting with secure boot enabled and that it's not already disabled
<Laney> yeah I am in that situation
<Laney> right chaps
<Laney> thanks for educating me a bit while I was cooking me dinner
<Laney> it is now ready - ttyl :)
<cyphermox> Laney: ping me later and we can chat more about it
<Laney> sure
<Laney> see you!
#ubuntu-kernel 2016-05-20
<davmor2> Laney: you can keep your suggestions of testing to yourself, can you image what would happen if I broke the kernel that would block everything ;)
<davmor2> Laney: but on a serious note what are the steps is there a bug I have a kvm setup that allows uefi and secureboot I can have a play with it next week
<Laney> hi davmor2 
<Laney> you're supposed to be prompted to disable SB if you try to install a dkms module and have it on
<Laney> that started with xenial
<Laney> we were wondering if that prompting happens correctly in all cases
<Laney> for example if you upgrade from wily
<davmor2> Laney: it did with nvidia and broadcom, the intel and amd microcodes don't trigger dkms and amd didn't from trusty to xenial because the driver is downgraded to the free one till the binary version lands
<Laney> background is somehow I ended up without wifi because of that
<apw> davmor2, i thought that the amd was going native from 16.04 out
<davmor2> apw: so there are 2 parts still it's just the rewritten binary wasn't ready for 16.04
<apw> davmor2, you make me sad
<davmor2> apw: amdgpu and amdgpu-pro iirc
<apw> so we will get a new dkms package sometime "later" ?
<davmor2> apw: as I understand it everything that can be free is free in the amdgpu driver but there are some bits that can't be and will be in the pro bit
<davmor2> apw: yeap but the gfx guys can fill you in more I'm sure
<apw> davmor2, thanks for the background 
<jtaylor> why is it so difficult to get bug 1248289 fixed? its been more than 2 years with a patch and its imo very important functionality
<ubot5> bug 1248289 in linux (Ubuntu Yakkety) "Missing libunwind support in perf" [Medium,Triaged] https://launchpad.net/bugs/1248289
<apw> jtaylor, there are any number of reasons, things are more likely to get in when they are clear an unambigious, and yet more so if someone pulls the patches needed together, tests them and submits them to our mailing list directly
<apw> jtaylor, we have a lot of bugs out there and finding nuggets like this with fixes is non-trivial
<apw> jtaylor, that said, didn't we apply that just recently ?
<jtaylor> yes the second time you said you did but the buildlog says no
<apw> jtaylor, confusing, i know i reviewed the proposed patch and sent the submitter to check that in the test builds
<jtaylor> apw: just checked the source, no binutils-dev in b-d also nothing in changelog
<jtaylor> apw: did it maybe not make it into the proposed kernel?
<apw> jtaylor, something did ... the moral equivalent to the patch in comment #17 to my reading
<apw> jtaylor, so it looks like rtg got the wrong end of your stick here
<jtaylor> yes that seemed to have worked according to the buildlog
<jtaylor> but its still missing binututils-dev
<apw> jtaylor, which is utterly why he originally asked you to submit the patch ... as you understand the issue at hand and the mess that this bug has become
<apw> jtaylor, so yes the anwser to your question is, yes we applied the patch in that bug
<apw> jtaylor, unfortuanatly that patch only has half the story, and i can't find another patch in there
<apw> jtaylor, so i think we cna forgive his getting it wrong
<apw> jtaylor, are you saying all we need is to add binutils-dev to the build-deps too ?
<apw> jtaylor, and if i do that and spin you a test kerenl, can you test perf from it for me to confirm it is enough for your purposes ?
<jtaylor> apw: adding binutils-dev should be enough
<jtaylor> apw: the build log is enough, but I can also test it
<jtaylor> apw: which debian folder do you modify for the kernel? debian or debian.master?
<apw> jtaylor, debian.master
<jtaylor> apw: the log also says its missing libperl-dev but I don't know what that is actually used by, missing gtk and numa is likely less important
<apw> jtaylor, d/r clean rebuilds the debian/* ones
<apw> jtaylor, i am hopefully building the tools with that enabled now, and will get you a log
<jtaylor> apw: the interesting part is when building tools/perf, "Auto-detecting system features:"
<apw> ...                     libunwind: [ on  ]
<apw> ...            libdw-dwarf-unwind: [ on  ]
<apw> those two ?
<apw> jtaylor, no that isn't enough as the built one has that
<apw> ...                        libbfd: [ on  ]
<apw> that a
<jtaylor> apw: libbfd is the one
<apw> jtaylor, that appears to have changed, is that what we are trying to achieve here ?
<jtaylor> libunwind was missing which is fixed by the makefile patch
<jtaylor> in current proposed
<jtaylor> apw: yes that is what we want
<apw> jtaylor, and indeed is what the bug claims to want, no wonder this went wrong ...
<jtaylor> apw: in the old log it said, add libbfd-dev to gain symbol demangling
<jtaylor> apw: yes the original bug report was reporting this but it turned out there was a second issue that broke it, missing libunwind due to lzma
<jtaylor> apw: I should have summarized the issue ... the bug is a little confusing
<apw> i've put a clarification in the bottom
<apw> do you want to test the perf this makes ?
<apw> or are you happy that is sufficient for this bug
<jtaylor> apw: I can test it if you send me the binaries
<apw> jtaylor, 32 or 64 bit ?
<jtaylor> but I'm confident it will work now so I can also wait for the update
<jtaylor> 64 bit
<apw> jtaylor, i'd rather not be SRUing a fourth fix for lack of testing
<cking> testing is paramount to ensuring quality
<cking> *ensure
<jtaylor> sure just send me the files, I can test trusty and xenial
<jtaylor> fwiw you can also test it by running perf top next to e.g. gcc compiling stuff
<jtaylor> if you have demangled names it works :)
<apw> jtaylor, ok http://people.canonical.com/~apw/lp1248289-xenial/
<apw> jtaylor, should have the bits you need to test, i presume you can run that perf against the current installed kernel if you try :)
<apw> hard enough
<apw> without installing the kernel i mean
<jtaylor> apw: it works :D
<apw> jtaylor, ok suplemental patch submitted, i expect it'll be a little while grinding unless we get a respin
<jtaylor> apw: its not really urgent, people have been dealing with it since 13.04, a few weeks more won't matter :)
<apw> jtaylor, fair point indeed
<tseliot> rtg: nvidia 361 should be fixed now (I've just uploaded the fix). I'll look into the other two in a bit
<rtg> tseliot, thanks
<mamarley> tseliot: The graphics-drivers PPA has a 340 package that is patched for 4.6.  I have been testing it for several days on two boxes and have had no issues.
<tseliot> mamarley: right, I'll review that one then . Is there a patch for 304 too?
<mamarley> tseliot: Not directly, but the 340 one will probably be pretty close to what you need for 304 too.
<tseliot> mamarley: ok, thanks
<manjo> apw, will you be around 20mts from now? I really need your help .. 
<gerow> Hi folks, qq wrt to <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1582864> (which jsalisbury is handling) about how long should I expect to wait until the fix is released in a new package?
<ubot5> Launchpad bug 1582864 in linux (Ubuntu Wily) "use after free of BOS in usb_reset_and_verify_device" [Medium,In progress]
<gerow> I don't need an exact date, just trying to figure out if I'll need to build a fork for my users before that happens or not
<jsalisbury> gerow, the current sru cycle is 27-Apr through 17-Jun.  With a targeted release to -updates on June 20th.  
<gerow> jsalisbury: thanks sounds like a yes that I'll need a fork :)
<gerow> thanks for the update
<jsalisbury> gerow, yes, that might be best, until the fix is releaed via updates.  
<gerow> Is the SRU cadence documented somewhere? So I don't have to bother you all next time I need to know?
<jsalisbury> gerow, it's can change at times.  The most up to date schedule is published in the weekly newsletter.  The newsletter is emailed to the kernel-team mailing list, and can be seen here:
<jsalisbury> https://wiki.ubuntu.com/KernelTeam/Newsletter/
<gerow> great, thanks again
<jsalisbury> np
<TJ-> Why would "Failed to connect to Mir: Failed to connect to server socket: No such file or directory" be reported when executing an X application from the terminal, launched by another (sudo) user, with e.g. "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/<user>/.Xauthority xclock" - do we need to copy more of the target users' native environment? any in particular? presumably this is some kind of
<TJ-> fall-back if an X session isn't located?
<TJ-> oh drat! wrong channel!
<gerow> jsalisbury: another question about that bug :), is there any process for potentially speeding that up? We'd like to avoid a fork if at all possible and we're seeing this bug hit about 200 of our hosts per day.
<jsalisbury> gerow, I'm not sure off hand, but I can look into it.
<gerow> jsalisbury: cool, I'd appreciate that
<pkern> jsalisbury: That bug was hitting us pretty nastily in terms of USB3 stability, i.e. scrambling for a few months tracking this down while users kept complaining that they can't get their work done because the memory corruption propagated down to process hangs. \:
<pkern> jsalisbury: So thanks for the consideration. :-)
#ubuntu-kernel 2016-05-22
<wget> Guys: I had a discussion ages ago with one of your kernel maintainer about this topic, and it's still not resolved and still impacting Ubuntu (while haven't tested 15.x nor 16.x series).
<wget> https://bugzilla.kernel.org/show_bug.cgi?id=75381
<ubot5> bugzilla.kernel.org bug 75381 in Network "Several disconnections that could lead to kernel panic" [High,New]
<wget> that bug is related to this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269883?comments=all
<ubot5> Launchpad bug 1269883 in linux (Ubuntu) "0b95:1790 [Asus N55SF] Bad performance of Asix Ethernet-to-USB device on USB3 port" [Medium,Incomplete]
#ubuntu-kernel 2017-05-15
<doob> hi, I have a question regarding the state of perf in the xenial ubuntu kernel source 
<doob> While looking for the append option of the `perf record` command I noticed that this is missing in the current ubuntu kernel source of perf (I'm running 4.4.0-78-generic #99~14.04.2-Ubuntu SMP Thu Apr 27 18:49:46 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux)
<doob> This is surprising to me since the official sources seam to have this since version 2.6.31 https://github.com/torvalds/linux/commit/abaff32a03e26e5d6674cb2a26ad882efe7493a3
<doob> Is there anyone at the ubuntu kernel team especially responsible/taking care of maintaining `perf` to ask about why this is and whats the general state of perf in ubuntu?
<apw> doob, hmmm, well noone speific looks after it.  if it has an issue that needs investigating do file a bug against the kernel
<apw> doob, as that is produced as part of the kernel build
<doob> I was just wondering if it has just been forgotten somehow or if there is reason to patch away or not include this compared to the main kernel tree
<doob> ok 
<apw> doob, we do not carry any patches for perf
<doob> but do you compare/sync with the upstream kernel tree at some point regulary or does it mean you never ever get upstream code for perf as long as nobody files a bug report? 
<doob> I'm not sure if I got you right with "we do not carry any patches for perf"
<apw> doob, perf is kernel version specific and carried without modification as far as i recall
<doob> Ok. This is what I was always thinking how it is. This is why I'm supprised to not find the code in the ubuntu tree that is in the upstream tree since 2.6.31. 
<apw> doob, the source for 4.4 has the append option
<doob> Am I looking at the wrong place? http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/tools/perf/builtin-record.c
<apw> doob, oh no i am wrong, that is an append option in another command
<apw> doob, the -A was removed a long time ago
<apw> commit 563aecb2e63a16f86c7daabfdcfee23f3e7c5955
<apw> Author: Jiri Olsa <jolsa@redhat.com>
<apw> Date:   Wed Jun 5 13:35:06 2013 +0200
<apw>     perf record: Remove -A/--append option
<apw>     It's no longer working and needed.
<apw>     Quite straightforward discussion/vote was in here:
<apw>     http://marc.info/?t=137028288300004&r=1&w=2
<apw> (the commit's words)
<doob> Ok. Thx. In the meantime I also noted I did a mistake. I think I grabbed some very old commit message from GH and was misleaded by the branch information saying that it is in all the current branches. But of course the commit will stay there for ever even if the code has been removed. Sorry for the confusion. 
<apw> np
<dmj_s76> sforshee: I was able to test the package for bug1686815 for the bluetooth issue.  It fixes the bug.
<jjohansen> sforshee: sorry for the dely on this, I finally tracked down the memory corruption, this passes the regression tests, except for long_path which is deliberately broken atm, and will have to be fixed in some follow on patches
<jjohansen> http://paste.ubuntu.com/24583768/
<jjohansen> sforshee: I have included the fixes that are on 4.12, so it should be a clean rebase to the 4.12 kernel
#ubuntu-kernel 2017-05-16
<dmj_s76> sforshee: bluetooth works in that 16.04 package for bug 1686815
<ubot5> bug 1686815 in linux-firmware (Ubuntu Xenial) "Missing Bluetooth firmware for intel 8265 on Ubuntu 16.04" [Medium,Incomplete] https://launchpad.net/bugs/1686815
<sforshee> dmj_s76: thanks, I'll try to get that uploaded today
#ubuntu-kernel 2017-05-17
<rbasak> Running 4.10.0-20-generic on Artful, I got a suspend failure for a PCI device 8086:15b5 which appears to be a USB controller. I haven't used it on this boot. I found "remove" inside /sys/devices, removed it, and now I can suspend.
<rbasak> Not sure what to do about it, if anything.
<rbasak> I don't think my kernel has changed or anything. I doubt it'll reproduce on next boot.
<rbasak> But I can suspend now at least.
#ubuntu-kernel 2017-05-18
<loganaden> hoi
<loganaden> Hello
<apw> loganaden, hi
<dmj_s76> sforshee: linux-firmware 1.157.10 doesn't have the bluetooth fix, right?
<sforshee> dmj_s76: no that one was already sitting in proposed, was waiting for that to get pushed out so now I'll upload .11 with that fix
<dmj_s76> great, thanks.
#ubuntu-kernel 2017-05-19
<Kompliziert> hello guys
<manjo> ppisati, around ? 
#ubuntu-kernel 2018-05-14
<mamarley> apw: Just as a heads up, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ssb?id=882164a4a928bcaa53280940436ca476e6b1db8e causes b43 and b44 support to break again in the 4.17 mainline builds as it prevents SSB_DRIVER_PCICORE_POSSIBLE from being enabled if SSB=m, as it is in Ubuntu.
<apw> mamarley, upstream ....
<apw> sforshee, ^
<sforshee> ack
<sforshee> cascardo: ^
<mamarley> Sorry, I didn't know whether it was an upstream bug or something that needed to change in the Ubuntu kernel config.
<cascardo> ok, this came in 4.17-rc1
<cascardo> mamarley: was it reported upstream already?
<cascardo> I recall seeing something about ssb breaking before
<mamarley> cascardo: No idea; I'm not even sure it is an upstream bug.
<cascardo> ah, well, not a bug
<cascardo> this just means that we are probably need to set SSB=y
<femme> jsalisbury: I tested rc4 yesterday, is there anything relevant that changed?
<femme> (it didn;t work with rc4)
<jsalisbury> femme, no, it was worth checking though.  The backport of the patch posted in the upstrem bug was never accepted upstream.  I just wanted to confirm some other commit didn't fix the bug.
<jsalisbury> femme, I just need to work on the backport some more and I'll have a test kernel to test
<teward> anyone on the kernel team want to handle a question that should've been sent to the Kernel team directly that was posted over on Ask Ubuntu?  You know, if you aren't busy.  The question is specific to Kernel-team operations within the kernel PPA, so only a kernel team member can really answer the question...
<teward> (https://askubuntu.com/questions/1036216/why-are-linux-kernel-images-missing-from-the-ubuntu-kernel-ppa-for-4-17-rcx-ubis the specific question)
<apw> teward, yeah
<teward> apw: thanks, hope you don't mind my dropping in and asking for the kernel team to give attention to such questions every once-in-a-while when it's something only the kernel team can answer :p
<apw> nope
<apw> teward, and done
<teward> thank you kindly :)
#ubuntu-kernel 2018-05-15
<icee> Anyone know who owns mainline builds?  Any chance we can get "one more patch" into the set of things that are applied so we can get linux-perf packages for the mainline builds?
<icee> er, linux-tools with perf, etc
<apw> icee, mostly that is me ... we don't produce tools generally for those, because we cross build many of the architecutes
<icee> apw: aw :(  would be really nice for x86-64
<icee> i understand it's a bit niche, but there's a few times it'd have really helped me
<icee> (basically i have a habit of ending up with machines that the dist kernel just barely runs on and i have to leap to mainline and then measure stuff that's going on)
<White_Light> icee, it's pretty quick to build perf
#ubuntu-kernel 2018-05-16
<aegiap> Hello, I have an issue on kernel 4.15.0-20-generic with Ubuntu 18.04 in a Xen environment. When I detach a network interface, the task hangs (see https://gist.github.com/aegiap/2cd469f3eb72903f97952473d329905e).
<aegiap> The patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2d2e6738a209f0f9dffa2dc8e7292fc45360d61 seems to fix the issue. I was wondering if there is plan to backport it in a new release of the Ubuntu kernel for 18.04 ?
<apw> aegiap, do you have a bug filed in ubuntu about this, with these details in it ?
<aegiap> apw: not yet, I will create one.
<femme> jsalisbury: the kernel logs dont seem to say anything about mooting the mainline kernel /without/ iommu=soft. Should I include the iommu=soft kernlog? Or is there another way to get the relevant logw
<jsalisbury> femme, no logs needed.  We just needed to confirm to upstream that we tested mainline and it still had the bug.
<femme> Done
#ubuntu-kernel 2018-05-17
<caribou> Good morning gents, I was wondering if you were aware of LP: #1766851
<ubot5> Launchpad bug 1766851 in linux-base (Ubuntu) "Missing `linux-update-symlinks` causes Linux package installation to fail" [Undecided,Confirmed] https://launchpad.net/bugs/1766851
<caribou> my guess is that it should be targeted to linux as this affects the package. I've just ran into this installing linux-image-generic-hwe-16.04-edge
<caribou> you'll tell me "that's what you get from living on the edge"... :)
<caribou> (oh arm64 btw)
<smb> caribou, there is awareness: bug 1767133 (in -proposed)
<ubot5> bug 1767133 in linux (Ubuntu Bionic) "linux-image-4.15.0-20-generic install after upgrade from xenial breaks" [Undecided,Fix committed] https://launchpad.net/bugs/1767133
<caribou> smb: good thanks!
<caribou> & happy to 'see' you :)
<apw> caribou, linux-base was released to -security quite recently so you should not see this if you are up to date
<caribou> apw: lemme check
<caribou> apw: indeed apt -y install linux-base fixed it, thanks!
<apw> caribou, later kernels are starting to have the right deps to make that self upgrade, but -edge is a bit of a mess still
<caribou> apw: that's fine, Just need -edge to test if makedumpfile doens't bail out on me because of KPTI
<s10gopal> when cfcadfaad7251d8b640713724b388164d75465b2 will be added in ubuntu 18.04 ?
<s10gopal> bug 1745646 is fixed in upstream
<ubot5> bug 1745646 in linux (Ubuntu Cosmic) "Battery drains when laptop is off (shutdown)" [Medium,In progress] https://launchpad.net/bugs/1745646
<apw> jsalisbury, ^
<s10gopal> apw, it will be fixed in ubuntu 18.04 or it will be available in 18.10 ?
<bjf> s10gopal, looks like that just got applied to the git repo 
<bjf> s10gopal, that should mean that it comes out in the next SRU update in 3-4 weeks
<s10gopal> bjf, before adding patch in sru  , it also require testing ? can i test it ?
<bjf> s10gopal, there will be testing required during the SRU process when it hits -proposed
<rbasak> https://askubuntu.com/q/1033616/7808 sounds like a bug to me. Related to hwe-support-status and update-motd
#ubuntu-kernel 2018-05-18
<fabriciojardim> Hi. Linux Kernel 4.15 introduced AMD Raven Ridge support but many fixes came with kernel 4.16. Does Ubuntu team backports those fixes to the 4.15 LTS Kernel before the release of the HWE kernels? If so where can I check for this? Thanks very much, I'm just a user, not a dev.
<fabriciojardim> Hi. Linux Kernel 4.15 introduced AMD Raven Ridge support but many fixes came with kernel 4.16. Does Ubuntu team backports those fixes to the 4.15 LTS Kernel before the release of the HWE kernels? If so where can I check for this? Thanks very much, I'm just a user, not a dev.
#ubuntu-kernel 2018-05-19
<hggdh>  had not really done
<hggdh> oops. keyboard ranaway, sorry
#ubuntu-kernel 2018-05-20
<ph88^> when is the 4.16 kernel coming out for ubuntu 18.04 ?
<tomreyn> !mainline | ph88^ 
<ubot5> ph88^: The kernel team supply continuous mainline kernel builds which can be useful for tracking down issues or testing recent changes in the Linux kernel. More information is available at https://wiki.ubuntu.com/Kernel/MainlineBuilds
<tomreyn> ph88^: i bet 4.16 or a higher version will be made available as a hwe-edge package in 18.04 once cosmic got a newer one.
#ubuntu-kernel 2019-05-13
<alkisg> (03:57:03 PM) sforshee: alkisg: the first time you install a dkms module while booted under secure boot you should get prompted about creating a MOK and given further instructions
<alkisg> ==> https://termbin.com/p82v ==> I'm supposed to be seeing a whiptail menu but I don't! I guess some stdio descriptor has been redirected and it only works when updating from GUI?!
<alkisg> It did show up later on with `dpkg --configure -a`... dunno, maybe `apt --yes` breaks stdin :/
<alkisg> Meh, failed not open \efi\boot\max64.efi: not found => won't boot
<alkisg> It should be looking in ubuntu\mmx64.efi instead, copying the file...
<alkisg> OK that worked. I wonder if these 2 bugs affect everyone, or just my installation.
<tomreyn> hmm, "max64.efi" sounds like a typo to me.
<tomreyn> also ubuntu uefi boot code is usually installed to /efi/ubuntu/ rather than /efi/BOOT/, i think
<alkisg> tomreyn: true, my first line there was my own typo; but the fact that it looks in boot rather than ubuntu wasn't a typo
<tomreyn> thanks for clarifying.
<sforshee> cyphermox: ^ alkisg is seeing some issues with setting up the MOK for dkms
<cyphermox> alkisg: no; it's expected; we largerly install in both locations because some systems are busted and don't record the BootEntry for ubuntu
<cyphermox> as for the upgrade issue, that's a known bug that someone is working on. headers redirect output for dkms
<alkisg> cyphermox: thank you; I only had mmx64 in one location; I had to manually use cp; maybe it's been resolved after I installed that system
<tomreyn> are there some rough plans on a 5.x kernel backport (HWE) to 18.04?
<tomreyn> i know there's one in proposed, but it's been there for a while
<tomreyn> i was hoping to see it on hwe-edge at least
#ubuntu-kernel 2019-05-15
<tomreyn> i previously asked this in -hardened, but it may be more suitable here:
<tomreyn> There are "new" (2019) AMD microcodes available according to MCExtractor's DB (<https://github.com/platomav/CPUMicrocodes/commits/master/AMD>). is there any chance we'll see those in ubuntu via amd64-microcode?
<amurray> tomreyn: sbeattie would be the best one to ask - he mentioned to me earlier that we track the upstream kernel tre for amd64-microcode https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode
#ubuntu-kernel 2019-05-16
<tomreyn> thanks, amurray.
<tomreyn> sbeattie: do you know how amd microcodes (not) end up at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode then?
#ubuntu-kernel 2019-05-17
<alkisg> Hi, ubuntu is the only distro that I know of, that ships vmlinuz with mode=600 instead of e.g. 644.
<alkisg> So if we want to export a $CHROOT/boot via tftp, we need to run dnsmasq as root, making our systems unsafer.
<alkisg> Was this done for security reasons? But isn't vmlinuz publicly available anyway? Is the rationale documented anywhere, or, could I send a message and discuss it in some mailing list?
<alkisg> (and initrd that may actually contain local sensitive information is world-readable...)
 * alkisg reads through https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725 ...
<ubot5`> Ubuntu bug 759725 in linux (Ubuntu) "The kernel is no longer readable by non-root users" [Medium,Won't fix]
<alkisg> I don't agree but the decision seems to be crystallized. Oh well. :)
#ubuntu-kernel 2019-05-18
<alkisg> Hi, can anyone imagine why the netconsole module works properly early in the boot process, yet it stops broadcasting when systemd services start, at about the point when systemd-journald starts? (maybe that's when networking starts too...)
<alkisg> UDP traffic isn't blocked, e.g. sending messages with `nc` works fine; it seems like the netconsole module just stops sending; it even loads successfully with no errors, yet it sends nothing
<alkisg> Example commands to test with: server: nc -l -u 6666; client: modprobe netconsole netconsole=@client-ip/enp0s3,@server-ip/
<alkisg> These work at e.g. init=/bin/bash, but not on "recovery" or later
<alkisg> I tried downloading netconsole-setup from 19.04; this manages to send a single test message, and then nothing more
<alkisg> It works in Ubuntu 4.10, fails on Ubuntu 8.04. Hehe, first time trying Warty.
<jeremy31> alkisg: Why mess with unsupported versions?
<alkisg> jeremy31: to see when it broke, to help in finding why it broke
<alkisg> (netconsole isn't working in ubuntu since at least 10 years now)
<alkisg> (while it still works fine in buster and all the rest distros)
<alkisg> 6.06.1 is broken too, so it broke sometime between 4.10 and 6.06.1
<alkisg> So, it works on 4.10 and fails on 5.04 and up to now. Ancient bug. :)
<alkisg> ip a
<alkisg> Got it; it needed `dmesg -n 8` to actually transfer the messages in 5.04+
<alkisg> ...or, echo '4 3 1 7' > /proc/sys/kernel/printk, or loglevel=8 in /proc/cmdline etc; but it appears that this only lasts up until journald is started
<alkisg> Something resets the log level, so one needs to manually run it again after the system completes its boot process
<TJ-> alkisg: "grep LogLevel /etc/systemd/system.conf" 
<alkisg> TJ-: thanks; I tried settings that to "debug", I rebooted, but /proc/sys/kernel/printk is again reset to "4 4 1 7"
<alkisg> What I want is to have "4 3 1 7" or "5 4 1 7" after the system boots, so that a simple "date > /proc/kmsg" reaches the server,
<alkisg> So, I start with passing "loglevel=5" in the kernel cmdline, and that works up until journal starts, where it's reset to 4.
<TJ-> alkisg: how about a sysctl setting?
<alkisg> Do you think journald will respect that? I can try...
<alkisg> loglevel is supposedly the kernel parameter that is equivalent to kernel.printk...
<TJ-> alkisg: check out journald.conf, it's man-page shows options MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=
<alkisg> Those sound interesting, let me try...
<TJ-> alkisg: see "man journald.conf"
<alkisg> I tried these in the cmdline, but no joy so far: systemd.journald.max_level_kmsg=5 systemd.journald.max_level_console=5
<alkisg> I'll try again after a small nap. Ty, later... :)
<alkisg> TJ-: I put init=/bin/bash, I run `systemctl mask journald; exec /sbin/init`, and the level is still reset to 4. So it's probably some other component that resets it, not journald...
<TJ-> alkisg: it does sound like a sysctl thing
<alkisg> Oh, I see sysctl.d/10-console-message.conf has 4 4 1 7, maybe it's that one, looking...
<TJ-> I did mention that earlier
<alkisg> Yup that was it. Sorry I didn't realize you said "maybe it's a setting in sysctl.d", I thought you meant "maybe you can set the one you want in sysctl.d"
<alkisg> And since I already set it in the cmdline, I didn't look into it more
<TJ-> well, it took you as long to find that as it's taken me to find a missing managed switch on my network!
<alkisg> Haha, I had a nap too :D
<alkisg> It took me all Friday to find a loop in the cabling a school though... a teacher removed a utp cable from a pc, put it to his laptop, and when he was done, he put it back to... the switch, creating a loop
<alkisg> The school lost networking for a week :D
<TJ-> arghh!
<TJ-> well in my case I have a netgear GS748TP, used for labs, so it is powered off most of the time. It should be on the management vlan on 10.254.0.253, but I couldn't find it despite all manner of permutations of looking for it on both the management and default vlans, and trying alternate (inc. default) IP addresses, different ports, and so on
<TJ-> eventually downloaded the Netgeat SmartWizard windows software, ran it under wine, it found the device instantly and confirmed I had the correct IP address... so at that point I added the management subnet to the default vlan and there it was! so it had forgotten it was supposed to be on the management vlan
 * alkisg got a headache just reading about it :D
